本次探讨具有很强的技术代表性，特此记录
kering：@xinwang @王帅 关于上链的问题：是否可以
1. 前段表单数据 先到数据库
2.同步前段调用metamask 将gas 费 转账到合约中
3.submit 触发 提交数据库，触发合约上链
上链都做成后台异步的，如果一次失败了 这样可以循环上链， 直到成功。同时前端继续 调用meatask ，将gas费 打到合约中 作为上链费用
这样 ：用户前段不需要 等待 ，操作比较友好
大家看看哈，目前 第一个版本迭代 很重要，咱们也是第一次磨合，架构之类的压力都在这里了，后面的就顺了
王欣：合约调用时间一般是比较长的，一般也是使用异步的方式
王帅：但这样和中心化有什么区别？
王欣：差别在于数据上链后，不可篡改。留下某一时刻的证明。而普通数据库，数据是什么时间记录的，之后有没有修改过，都不确定。上链前的数据，同步异步差别不大。如何保证上链前数据正确?没有绝对的答案。
kering：我是这样理解的，不知道对不对哈：
1. 异步和同步上链，都是上链的手段，目标都是最大概率 最高效的上链
2.一旦上链了，后面及时没有 我们提供的前端交互，例如 链上有投票地址，有合约地址 等，用户可以直接绕过我们提供的前端，直接跟 链上交互
3.实现了2，基本也就摆脱了 中心化
王帅：异步我是赞同的，数据不可窜改也是共识。但是上链的方式由后端发起。这个后端在这个交易里不是也充当了管理者的角色，也充当了一点钱包的角色。是否相当于在一个去中心化的网络里建了一个中心。
kering：异步上链是这个流程吧？
唯羽：有个问题，交易实在哪里构造的，前端还是后端？
王帅：kering说的是两笔交易
kering：如果是异步上链：应该就是后端构造的，如果是同步，应该就是前端构造的 吧
唯羽：异步也可以前端构造，前端把交易构造好，由后端去上链
kering：如果是 异步前端构造的情况下，是否解决了 王帅的问题 ？ 好像是解决了，我画的图 异步 中后端的合约 是王帅说的 ：是否相当于在一个去中心化的网络里建了一个中心。 对吧？这个合约就是你说的 这个中心
如果唯羽的方案，是否解决了这个问题？没有这个中心了
王帅：
唯羽：前端把交易构造好，后端拿去广播，不用等结果，交易hash是不会变的，或者前端直接通过别的节点广播也行，后端定时任务自己更新广播状态
kering：@xinwang @王帅 请二位研究下，唯羽说的 方案，还有其他 的 ，咱们尽快解决这个问题哈 ，这个貌似是我们所有上链的问题，解决了一次就一劳永逸了
@王帅 帅神，你上面的流程图，是在哪里构造的交易呢？
王帅：前端，后端确认交易，状态值可以前端主动更新也可以再后端确认后更新
kering：那就是前端只要构造好交易，生成了hash 值，广播出去，就不可更改了 ，这样后端 执行上链就行 ，唯羽说的 那种？
王帅：这样状态值的显示上会有变化
中心化和去中心化好像是一个永远存在的问题，这次讨论的记录不是为了表示问题是如何解决的，而是想告诉大家项目开创性的不易，一些问题虽然用旧的办法可以即时解决，但是解放完之后呢？
我们不是为了单纯的做一个产品，而是想通过产品向世界宣告我们的理念，假如遇到问题不去克服而是选择用折中的办法，那么开创性来自哪里？这虽然是一件看似正常的技术探讨，但是能够反映出开发者小伙伴们始终保持初心，同时也反映出第一个版本的不易，这些宝贵的思考和建议不是单纯可以量化的，这里凝聚着大家最纯粹的愿景。
若有收获，就点个赞吧
0 人点赞
