2.6 业务问题回顾

riyad

本帖最后由 riyad 于 2025-3-6 22:25 编辑

📝 您还将了解到

在哪些情况下，我们可以应用我们的可扩展合约设计原则？
: }% \+ F0 ?4 A3 W5 u

在这里，我们将通过三个例子来了解合约设计原则如何应用于各种应用程序，以及 TON 平台如何帮助您构建可扩展的安全应用程序。

代币

在以太坊甚至非区块链中，通证是作为账户的简单分类账来实现。

您有一个列表，程序控制着这个账户列表，列表中的每个项目实际上就是参与者的地址及其余额。这非常简单，但不幸的是，在区块链环境下它无法扩展，因为你的智能合约必须随着用户数量的增加而不断增长，而且每个用户的交互成本也会越来越高。

❓ TON 的方法是什么？

在 TON 中，代币通证是作为不同的合约实施的。每个用户一个合约，外加一个单独的矿工合约，为创建新的通证单位提供接口。

每个用户的合约被称为 Jetton 钱包，这些 Jetton 钱包的工作是为每个用户保存代币余额。每当用户想把代币从一个账户转到另一个账户时，他们首先会向自己的钱包发送一条外部信息，然后这个钱包会解开这条外部信息，并通过内部信息向该用户的 Jetton 钱包发送 "请把钱发送到某个地址"。然后，Jetton 钱包将其余额减去必要的金额，并将消息发送给代码完全相同但所有者不同的兄弟合约，消息中写道："请将您的余额增加相同的金额。

🍞 这里使用 DNA 校验是因为 jettons 的代码是相同的。

多重签名合约。

📖 多重签名合约的概念在 TON 中得到了体现，在 TON 中，多方通过对用户发起的请求进行标记来共同授权行动。

用户不会直接处理信息，而是接收封装其请求和投票的令牌。这些代币通证归用户所有，简化了跟踪工作，防止恶意用户压垮合约。忠诚用户在临时请求令牌上收集投票，一旦达到阈值，多重签名合约就会在验证请求的真实性后执行操作。这种通证化简化了流程，重点关注的是系统的临时状态，而不是单个合约的份额或价值。

订阅支付。

👀 自钱包第 4 版起，钱包支持能让人们创建订阅付款的插件。

这是一个非常强大的功能，由于用户可以控制这个插件列表，因此它的扩展性相对较好。但我们可以想象出更好的方法。

🔥 很酷的想法是，您可以列出这些插件的不同实现代码，而不是列出特定的插件地址。如果它们共享相同的代码，那么您拥有的任何数量的订阅插件都将只有一条记录。

" N- V8 a- h5 K' p! K9 Z

2.6 业务问题回顾

riyad LV4