type
status
date
slug
summary
tags
category
icon
password
总结
在这个项目，我们完成了 FairTicket 项目，实现了公平抽票的一个 Dapp。不同于一般项目，它们往往由前端直接调用合约发起链上交互（当然，本项目缺少这一部分实践），而是通过与中心化的服务端进行交互，由服务端将数据上链，在中间隔了一层，将交互的复杂性留给中心化的后端服务，避免用户直接与链上交互从而引入的门槛以及学习成本以及资金成本（Gas费用），数据上链的Gas由服务端进行承担。并且合约不参与资金相关逻辑，只记录非常关键的数据，这有助于降低节点的存储成本，以及Gas费用。
FairTicket 的具体考量如下：
- 由于该抽票程序不依赖时间顺序，只需要保证链上链下重点数据的 最终一致性，因此留给服务端决定上链的时机，从而使Gas成本相对可控。比如用户在白天参与项目，服务商可以选择在晚上或者其他时间网络不拥堵时，将数据上链，只需保证在项目结束前将用户信息上链即可。
- 从商业角度，如果一个服务商能够提供这样公平的服务，从而使受众用户增多，那么受益方应当是服务商，由用户承担Gas是不合理的，应当由服务商支付Gas费用，以获取用户，从而得到更多的其他商业收入。并且如1. 所示，Gas费是服务商可控的（服务商优化合约函数以降低Gas，在空闲时上链，使用更低价的公链）。
- 避免用户直接操作钱包资金去调用合约，将钱包仅仅作为链上的一个账户，使用地址和签名与后端
api进行交互，防止操作钱包资金，还可以有效防止黑客攻击。（用户的唯一性可以在后续引入手机号等其他KYC手段，防止同一个真实用户用不同钱包多次参与）。支付问题可以使用传统金融中的支付体系，比如扫码支付等，只要有了KYC，一切都好办。
在代码实现中，我们经历了
- Solidity智能合约开发与测试。
- 后端主动调用合约，写入或查询数据。
- 后端监听合约，获取合约事件，做对应的操作。
- 前端页面编写以及钱包的接入，调用后端
api完成各个功能的交互，使用钱包签名作为权限验证。
展望
本项目只是作为一个Demo，以最小化的方式实现 FairTicket 的核心功能。如果想要真的将其在现实落地，还有 非常非常多的路需要走，以下是我可以想到的更进一步的展望。
- 丰富项目，参与人的信息状态。
- 记录每笔交易的
transaction hash，有助于反馈给用户以及反查确认交易信息。
- 保证链上链下的数据一致性。比如
- 发起的合约交易（写入）是有可能失败的（没上链），进行反查交易状态和对应补偿。
- 监听服务或者挂了一下，导致有些事件没被监听到或者没落库，导致链上链下信息不一致，进行补偿。
- 用户以何种方式进行身份绑定与验证，支付流程闭环，支持退票等常规商业需求。
- 项目可定时开启，定时结束。
- 对应的后台管理系统。
- 支持多合约，甚至多链，用不同版本号区分，对应的逻辑可能也不同。比如有的项目方使用
v1合约功能，有的想使用v2合约功能，它们的随机数生成逻辑，或者抽票逻辑可能不同，甚至整体的抽票逻辑可能是由数字正序，也可能是倒序。
- 其他（欢迎补充想法👏 ）
谢幕
希望这个小小的 Demo 可以带你初探 Dapp 全栈开发。
更希望的是能够带给你关于 Web2 和 Web3 如何各取长处，丝滑结合的更多思考与想法，探究更多可能。
Let's Think and Build ！
- Author:Ago
- URL:http://www.sunago.top/article/fairticket-conclusion
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
