目前TON完全缺乏开发人员社区,而Fift(TON的智能合约语言)与通用语言的底层方法大不相同。
项目竞赛是吸引新开发人员和建立社区的好方法,也可以解决缺少文档和案例的问题。我们决定从比赛的角度总结比赛期间和比赛后发生的所有事情。
技术文档缺乏
(FunC)没有funC(类似于C的智能合约语言)的文档。 这是一个问题,因为大多数TON竞赛任务都要求您编写智能合约。 FunC —是将使用的主要语言,可用于编写智能合约。
使用它比使用Fift要容易得多。 但是由于缺乏相关技术文档(根本没有文档),每个人都需要去分析并尝试理解使用funC。
crypto/smartcontract
其实并没有那么难,但是需要花上几天的时间去学习就可以毫无困难地开始使用funC编写了。
(基本知识)使用funC编写智能合约时-您需要了解如何部署和编译智能合约以及如何使用自变量调用函数-基础知识。有趣的是,没有关于此的任何详细信息,也没有完整的步骤案例。
我们感谢TON给出的一个小小的指导方针,它确实帮助了我们,但它仍然是相当具有挑战性的。
关于竞赛任务
我们要突出显示5个任务中的两个。异步支付通道和同步支付通道。 那么什么是支付通道?
支付通道-一种在链外(区块链之外)在2个交易方之间发送交易的方法,以使其更快、更便宜、更个性化。双方在区块链上都有自己的帐户。
此外还有一个特殊的智能合约,可以在支付通道开放时存储两方的存款。您可以彼此之间以您存入的金额发送交易。
当您需要提款时-您将使用特殊数据调用智能合约,这将在下面讨论。
代理商A和代理商B向智能合约发送硬币,进行存款以在它们之间建立支付通道。
打开付款通道时-您需要从双方将资金存入智能合约。
A向B发送交易并将付款通道的状态从(a,b)变更为新的
如果付款通道已打开-您可以开始以每秒超过10万笔交易的速度相互发送交易。
重要的是要了解所有事情都是在链下发生的,有一天您将需要与交易对方达成协议并从智能合约中提取资金。
(在同步支付通道上从A到B的练下交易的可视化表示)
我们假设各方都可以作弊以撤回所有资金。 因此各方都需要证明自己要提取的款项属于他们。
为了证明这一点-他们将需要发送每个伙伴的签名,以正确证明状态(sum A,sum B和其他一些信息)。如果我们在谈论同步支付通道-我们有一个状态。
A无法连续向B发送多个交易。每个新状态都需要双方(A和B)的签名。 因此当A向B发送交易时,A需要创建一个状态,该状态将更改属于A和B的金额,使用私钥对该状态进行签名,然后将新的状态和签名发送给B。此状态并将签名发送回A。
仅在确认交易状态之后。 之后A不能在B之前发送另一笔交易。 A需要等待B创建新状态。 因此它称为同步通道。
(在异步支付渠道上从A到B的链下交易的可视化表示)
在异步支付通道中,每个交易对手都有自己的状态组。每个状态包括A从B接收的数量,A发送给B的事务数量,B发送给A的数量,B发送给A的事务数量。
在这种情况下,A和B无需等待确认 他们只需要发送一个已签名状态。
这两个通道中最困难的部分是提款过程。智能合约需要检查各方是否提供了正确的数据以提取资金。
我们需要检查状态的签名,而且状态是最新的。 可能是各方之间的冲突,并且智能合约需要根据规则(最新状态)进行解决。 必须防止将相同的数据发送到不同的支付通道,并且如果参与者之一不提供任何信息,我们也需要解决这种情况。
所有这些都必须用funC编写并经过充分测试以确保安全。听起来很有挑战性。
解决方案和竞争对手
大多数提交内容都是多签名钱包和DNS解析器。 但是其中有几个具有支付通道。 显然支付通道是最复杂的任务,因此解决方案将更少,并且提供这些解决方案的大多数团队将比其他团队更强大。
下一步是什么?
目前大约有10至20个具有足够技能和知识的团队可以开始构建TON的基础架构。 我们认为大多数成功的ETH解决方案将由这些团队转移到TON。TON竞赛确实可以改变与TON合作的团队数量,从而改变了现状。
责任编辑;zl
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)