PenZ's Space

万物归一

0%

TON 合约开发个人经历(1)

发表于 分类于 Disqus：

引子：因工作的原因接触Ton链的合约开发，遂埋头进入Ton链的学习，一个猛扎下去才发现水太深了

学习新技术肯定需要官方的文档：

  1. Ton的相关文档
  2. Ton的合约入门视频课程学习
    上述两个是我主要学习使用的文档

我的一个简单TON银行项目项目地址,后续的代码都在这个项目中。

接下来我阐述的是，我视角中如何理解和学习的过程：
首先，我具有evm链的合约开发经验和基础知识，那在TON链上很多东西完全不同可以说是一切都是新的，所以即使你没有接触过evm也没有关系。

TON 像一个万维网，每个账户是独立计算机，只能通过消息通信。
EVM 像一台超级计算机，每个账户是一个运行中的程序，可以直接访问共享资源。
这是我简单理解的对比概念

TON 账户里的余额会因为“存储费用”而逐渐减少，而这种费用可以类比为“租赁一台永远在线的计算机”的费用。(非常牛逼的设定)

当账户变成 inactive 状态时，账户的所有状态（合约代码、数据存储等）都会被删除，只保留一个“空壳”地址

TON架构 三层架构 使用共识机制采用pos(proof-of-stake)共识算法即验证者必须交纳保证金来确保行为合法。

  • 主链(Masterchain)：管理整个网络的“主链”，记录所有工作链和分片链的元数据、全局状态快照。
  • 工作链(Workchain)：工作链，是运行在 Masterchain 之下的“子链”，可并行存在多个，每条链可以有不同智能合约语言或规则。
  • 分片链(Shardchain0)：是 Workchain 动态分裂出来的多条“子链”，真正处理大量用户交易和账户状态
+----------------+
|  Masterchain  |
| (全局元数据)   |
+----------------+
         |
         v
+----------------+         +----------------+
|  Workchain #0 |   ...   |  Workchain #N  |
| (主工作链)     |         | (可定制规则)   |
+----------------+         +----------------+
      |   |                          |
      v   v                          v
+-----------+  +-----------+   +-----------+
|Shardchain0|  |Shardchain1|   |Shardchain0|
+-----------+  +-----------+   +-----------+
      |              |                |
      +------...-----+-------...------+
         （分片链动态增加或合并）

EVM 与 TON 多签合约的异同点

相同点

  1. 多签基本概念一致
    • EVM 和 TON 上的多签合约都旨在实现多个签名者共同授权交易，以提升安全性。
    • 都需要定义参与者（签名者）、签名阈值（例如 m/n，m 个签名者同意才能执行）以及交易执行逻辑。
  2. 去中心化执行
    • 两者都运行在区块链上，多签合约逻辑由智能合约在去中心化环境中执行，保证透明性和不可篡改性。
  3. 支持复杂逻辑
    • EVM 和 TON 都支持编写带有条件逻辑的多签合约，例如时间锁、权限管理等功能。

不同点

方面 EVM TON
编程语言 主要使用 Solidity 或 Vyper，语法类似传统编程语言（如 C++、JavaScript）。 使用 FunC（类似 C）或 Fift，语法更底层且专注于 TON 的异步特性。
合约模型 基于账户模型，合约是一个状态机，状态存储在区块链上。 基于 Actor 模型，合约是独立的“单元”（cell），异步消息驱动。
交易费用 Gas 费用统一计算，基于操作复杂度，需预估 Gas Limit。 费用分为存储费、计算费和消息传递费，需显式管理存储和资源。
状态管理 状态存储在链上，合约可以直接修改全局状态，适合同步操作。 状态分片存储，合约通过消息通信，适合异步和分片设计。
签名验证方式 使用以太坊的 ECDSA 签名算法，验证逻辑需在合约中手动实现。 TON 使用 Ed25519 签名算法，内置支持更高效的签名验证。
执行效率 单线程执行，依赖链的吞吐量（受限于以太坊或 L2 的 TPS）。 并行执行，得益于分片和工作链设计，理论上吞吐量更高。
开发复杂性 Solidity 生态成熟，工具丰富（如 Remix、Hardhat），但 Gas 优化较复杂。 FunC 学习曲线陡峭，生态较新，工具链（如 Blueprint）仍在发展中。
扩展性 扩展性依赖 Layer 2 或侧链，单链性能有限。 原生支持分片，扩展性内置于架构中，适合大规模多签场景。

总结

  • EVM 适合熟悉传统区块链开发的开发者，其生态成熟，但受限于 Gas 成本和单链性能，编写多签合约时需关注 Gas 优化和同步逻辑。
  • TON 强调异步处理和高吞吐量，适合需要高效并行处理的多签场景，但开发门槛较高，需适应其独特的分片和消息机制。

下一节将会开始TON的Func语言的初步合约开发