普及 WTON 倡议以及我们如何共同让 TON 变得更好

Written by
Mark Okhman
Date published
January 7, 2023
image

大家好,自从我参与 Wrapped TON 计划以来已经一个多月了,我与大家分享一些概述以及我对此的想法。

如果您熟悉 FunC 编程或打算开始这条道路 - 从技术和社区的角度来看,这对您来说都将非常有趣。要了解 Universal WTON 的最新消息,请查看此 TEP:ton-blockchain/TEPs#102

我想向 TON 的新手以及经验丰富的开发人员发表这篇文章,因此议程如下:

  1. WTON 是什么?为什么还要费心去拥有它呢?
  2. 社区倡议如何在 TON 中发挥作用?
  3. 当前建议的通用 WTON 标准
  4. TON 核心团队对 WTON 的全新投入
  5. 号召大家采取行动参与讨论

你准备好了吗?让我们跳进去吧!

与不同类型资产的交互需要额外的条件逻辑。为了避免这种情况并统一 TON 和 TEP-74 和 TEP-89 标准的 jetton 之间的相互作用,我们引入了 WTON 的概念- 一个 jetton,它在薄荷上以 1 对 1 的方式锁定 TON,并在烧毁时释放 TON。

实施打包的 TON 合约并不需要太多的努力。事实上,已经存在多种实现方式。问题在于,由不同开发人员创建的众多不同的包装 TON(wTON、jTON 等)存在很多风险:

  • 财务风险:
  • 无法保证特定 WTON 不存在故意或错误留下的安全漏洞。对所有众多 WTON 进行相同质量的安全审核和认证是不现实的。

  • 生态系统碎片化且没有单一的 API:
  • 对于构建必须使用各种 WTON 的产品的开发人员来说,这是一个真正的问题。想象一下,一个钱包开发者想要正确显示 WTON 的总量,包括普通的和各种包装的。

  • 功能不对称:每个 WTON 都有自己独特的功能集,这将导致额外的支持问题。

在使用 Universal WTON 的过程中,我熟悉了许多出色的工具,这些工具使任何构建者都能发挥影响力。让我解释。

TEP(TON 增强提案)

TON 增强提案的主要目标是提供一种方便、正式的方式来提出对 TON 区块链的变更,并标准化生态系统不同部分之间的交互方式。提案管理是使用 GitHub 拉取请求完成的,该过程在TEP-1中进行了正式描述。

以下是使用 TEP 仪器的简单步骤列表:

  1. 首先与社区讨论您的提案,例如在 TON Dev 聊天 ( en / ru ) 中。
  2. 阅读TEP-1以了解提案管理流程并遵循指南。
  3. 提交拉取请求。

TON的足迹

TON Footsteps 是另一个很酷的工具,可以帮助您为您的计划提供资金。它的运行方式与 TEP 类似。您可以访问TON Footsteps官方存储库,根据指南提出您的倡议,并让社区在这条道路上支持您。

根据对您的倡议的分析以及社区的支持程度,TON Footsteps 委员会将决定是否接受并资助它。我觉得很酷,这样的举措让任何人都可以参与塑造 TON 并改进它。

综上所述,Universal WTON 计划由TON Footsteps资助,并通过官方TON 增强提案存储库运行

正如 TEP 使用的第一步所述,我们已经与社区讨论了 WTON 提案。在TON 基金会FS 实验室人员的帮助下,我们聚集了所有主要现有 DEX(去中心化交易所)开发人员的代表,并就如何以最有效的方式实施 WTON 展开了深入的讨论。以下是我们的想法。

您绝对应该考虑查看实际的 TEP Pull Request,因为它有更详细的解释以及规范、解决方案的缺点和替代方案。

如上所述,通用 WTON 具有单一来源,即部署的铸币者合约,没有所有者/管理员功能。

WTON 的两个核心功能是包装解开TON。

包装

为了包装 WTON,请发送mint带有消息的操作代码。WTON 铸币者将在铸币者合约上保留TON,并将其余的发送到消息内的amount + minimal_balance()WTON 钱包recipientinternal_transfer

最重要的事情之一是能够附加forward_amountforward_payload构建交易管道。

如果出现以下情况,则应拒绝该消息:

  • msg_value小于 amount + forward_amount + gas_fee
  • recipient与铸币者处于不同的工作链中

Unwrapping

为了将 WTON jettons 解包回 TON,burn应使用操作代码。

我们部署的实现依赖于现有操作burn(包括custom_payload),但使用新操作burn_notification_ext而不是burn_notificationburn_notification更换新的唯一原因burn_notification_ext是无法附加custom_payload

燃烧后,jetton钱包会发送burn_notification_ext给铸币厂。一旦 WTON 铸币者收到burn_notification_ext消息,它就会减少,保留total_supply并发送一条带有操作代码的消息,以附加 TON 的其余部分和可选的。amounttotal_supply + minimal_balance()releaseresponse_destinationcustom_payload

burn如果出现以下情况,则应拒绝带有操作的消息:

  • response_destination未指定
  • amount小于jetton钱包的jetton余额
  • msg_sender不是 jetton 钱包的所有者
  • msg_value不足以处理消息burnburn_notification_ext

在这里,我们体验了 TEP 工具的强大功能,因为核心团队定期审核所有提案,我们的提案也是如此。

经过一段时间的等待,我们收到了来自 Ston.fi 开发人员DarioEmelyanenkoK的全新想法,他们是核心团队开发人员之一,正如我们在对主要 TON monorepo 的提交中看到的那样。EmelyanenkoK实施了一份解决方案草案,可以帮助人们更好地理解整体想法。

我将在这里简要解释新的输入,但您绝对应该进入实际的 TEP Pull 请求并遵循讨论。

为了总结这个想法,我将引用EmelyanenkoK 在 PR 上的消息

我想强调 @dariotarantini 提案的一些方面: 1.每个 wTON 钱包本身都充当铸币者/燃烧器 - 不需要与铸币者进行额外的交互,这意味着一个甚至两个交易更短的路径 2.我们可以用以下术语重新制定该方案:在最初的提案中,当我们想要发送 TON 时,我们实际上发送 IOU jettons,它可以作为 TON 兑换,但在 Dario 提出的方案中,我们发送 TON 本身,但为了兼容性而伪装成 jetton 转账。

这个例子表明,通过合作可以产生一些伟大的想法。

因此,现在,在从核心团队和社区成员获得如此可靠的意见后,我们将继续讨论如何将其应用到 Universal WTON 的细节。

我想邀请您参加这次讨论。在我看来,这是更好地理解 TON 的最佳方式,因为它是社区驱动的,并且具有最佳工作解决方案的潜力。

本站所提供的所有资讯均仅供读者参考。这些资讯不代表任何投资建议、提供、邀请或推荐。读者在使用这些资讯时,应当考虑自己的个人需求、投资目标和财务状况。所有投资都伴随着一定的风险,在做出任何投资决策之前请多加留意。