部分读者可能对于几年前 Telegram 的发币计划有些印象，当时准备上线的区块链叫做 Telegram Open Network，原生代币则为 Gram。然而， 美国证交会 SEC 对 Telegram 的指控使其不得已放弃了这条区块链的开发，并将收到的投资退还给了投资人。
回顾：Telegram 与 SEC 和解！需付 1850 万美金罚款，三年内发任何币都要告知
后来 Telegram 将这条链的程式码开源，让许多团队和社群都可以接续开发。其中最为知名的便是「NewTON」也就是今天的 The Open Network 及其背后的 TON 基金会。目前 TON 的原生代币 TONCOIN，市值已经接近第 10 名。Telegram 也已支援 TON 的加密货币钱包已被整合进 Telegram APP 中。
相关内容：Telegram推出数位资产拍卖平台Fragment，可用TON代币竞标用户名
不只是区块链
TON 这个名字所代表的其实不仅是一条区块链，而是更庞大的一个 WEB3 生态系。其中包含了：
- TON Blockchain 区块链
- TON Payment 闪电网路
- TON Storage 分散式储存网路
- TON Network（ADNL 协定）原生加密网路协定
- TON DNS 去中心化网域名称系统
而上述这些基础建设，皆已于 2022 年全数上线，本文将介绍这些 TON 生态系的基础建设有什么特别之处，并着重在这些架构对于用户及应用的影响。
TON 区块链
共识机制与质押
TON 区块链采用的是 POS 共识机制，除了传统上自建节点与透过第三方服务参与质押外，用户也可以透过 TON 基金会推出的 Nominator 去中心化质押合约加入公开的质押池，赚取 POS 收益。
TVM 与开发语言
在 TON 区块链上用于执行智能合约的虚拟机称为 TVM，与 EVM 在设计理念上有诸多不同且并不原生的互相兼容。TVM 上开发智能合的原生语言为 FunC，而在管理、除错、开发智能合约方面，则有独特的 Fift 语言。不过，在绝大多数情况下 JS 和 TS 都可以代替 Fift 完成任务，而如果觉得 FunC 太难写则可以选择更高阶的 Tact 语言。
虽然是新的语言，但目前已经有不少 SDK 和 API 可供开发者使用。另外，在代币标准方面，同质化代币（TEP74） 、非同质化代币（TEP62）、 灵魂绑定（TEP85）和版税（TEP66）等等常见的标准，也在很早期就被提出。
Actor 架构
借鉴了 Web2 当中大型应用的设计架构，TON 的设计哲学认为我们不该强迫用户为所有服务付费。这就如同 Instagram 或 Twitter 不会要求用户在每次发文、点赞时都支付一笔伺服器费用一样。因此，在 TON 区块链的世界里面，任何人都可以直接跟向智能合约互动，用户并不一定要有一个「帐户」来支付手续费才能发出讯息。
TON 采用了 Actor 的概念，所谓的 Actor 指的是下列的行为模式：
- 用户发出讯息
- 智能合约按照自身的程式码处理收到的讯息
- 智能合约基于收到的讯息，变更自身的属性（例如余额）或对外再发出讯息
因为交易手续费可以是由接收讯息的智能合约支付，所以这里用户就可以不是一个帐户。这样的设计架构有利于后面会提到的一些应用，比如说原生的 AA 钱包，或是更安全简便的自动付款机制等等。
手续费与通缩机制
在 TON 的世界里，智能合约的部署并不是一劳永逸的事情。为了要让智能合约随时能够被呼叫，它将会需要一直被储存在链上，这对整条链而言会是一个持续的负担。因此， TON 在设计上把部署智能合约的手续费设计成租金的形式，合约需要一直保持足够的余额以支付租金，若是余额被扣完了，那么这个合约将会被从网路中移除。（但不用担心，只要补充手续费就可以复原）这样的设计可以让网路不会被过多长期闲置或弃用的智能合约拖垮。
另外值得一提的是，在 2023 年中的投票通过后，目前 TON 区块链中的交易手续费将会有一半被销毁。截至撰稿时，已经销毁了共 63,000 枚 TONCOIN。
交易的非同步及非原子性
在 EVM 的世界里面，合约之间的互动是具有原子性的（atomic ）。也就是说，一笔交易里面的所有的动作，在某种程度上被视为一个整体。只要其中的任何一个动作发生错误，则这笔交易里面的所有动作都会失败，就像没发生过一样。这在 DeFi 场景里面可以有很多用处，例如 DeFi 交易操作中经典的闪电贷，就是透过把借款、交易及还款塞在同一笔交易内，降低了在执行策略时价格或其它因素发生变动所造成的风险。
然而 TON 对于这种作法的可扩展性保持怀疑的态度，因为让所有的交易都具有原子性虽然方便，但是在概念上就像是把所有合约放在同一台「机器」里执行。TON 为了追求更高的扩展性，在设计上把每一个合约当作一台独立的伺服器，而不同的伺服器之间在执行工作时，当然不会互相等待，更不会因为其它伺服器在执行上发生错误而回朔自己已经处理完的交易。因此这样的设计虽然被称为非同步（asynchronous），但实际上却可以让区块链同时的执行多个动作，增加可扩展性。
可修改的智能合约
多数人对于区块链的印象都包含了「不可篡改」（Immutable）的特性。然而这并不符合应用开发的现实，程式码完全不能「篡改」也意味着无法升级或更新。因此有不少的 DAO 和 DeFi 项目都透过 Proxy （代理）合约的方式来间接达成修改合约内容的目的。
作为新一代区块链的 TON 在设计时就思考到这个现象，既然大家都知道也默许智能合约可以被修改，那么再硬性预设智能合约不可修改并没有意义。故而在 TON 区块链上，智能合约是可以被修改的，不可修改的特性成为了一种选项。
原生的帐户抽象、智能合约钱包
每一个钱包/帐户都是合约
在 TON 区块链上，钱包并不是在链下生成一组公私钥并产生出地址后就能用，因为用户的钱包也是一种智能合约，需要自己撰写和部属才能用（实务上这些当然都是透过钱包软体代劳）。在部属钱包合约前，用户能先透过自己的公钥预览钱包地址，并用这个地址进行收款。当要动用资产时，用户就必须把钱包合约部属上链，再依据自己部属的合约规则来管理资产。
以太坊将钱包的管理规则直接被写进了协议内，无须自己部属合约来管理，但同时也法变更。对于 TON 的用户而言，他们对于钱包的管理有完整的控制权。因为每一个钱包都是一个智能合约，所以用户当然也可以在部属时设定自己想要的规则，例如自动转帐、多签、锁仓等等。
换句话说，在 EVM 生态系中热门的帐户抽象及智能合约钱包，在 TON 区块链上是再平凡不过的，每一位用户的钱包都是智能合约钱包。之所以能够这么做，是因为 TON 的 Actor 模型有办法让用户在还没有钱包之前就能与区块链互动，完成钱包的部属。
公钥不再等于钱包地址
多数区块链中的钱包地址都是直接用公钥计算得出，因此公钥和地址是一对一的关系。但 TON 的钱包地址是透过公钥加上钱包合约的内容产生，也就是说同一把公钥搭配上规则不同的钱包合约，所产生的地址就会是不同的。当然，用户也可以只是在同样的合约里面额外加上一个识别用的序号，借此以一个公钥生成多个地址。这么做，在某些比较单纯的情境下，可以取代复杂的 HD （分层确定性）钱包，更直观的用同一组公私钥管理多个地址。
钱包功能的扩展
基于智能合约钱包的自由度，开发者们对于 TON 钱包使用场景的想像持续的在推陈出新。截至 2023 年 10 月份，主流的钱包合约共经过了四次的迭代，目前已从 V1 版本发展至目前最多用户采用的 V4R2 版本。V1 版本已经包含了接收和发送所有资产的基本功能，V2 和 V3 钱包则增分别增加了「让交易具有时效性」和「单一公钥管理多个地址」的功能。而各版本的 R2 更新，主要的差异则是在于是否能够以 get-method 从合约取得该钱包的公钥。
至于从 2022 年沿用至今的 V4 版本，则更大程度的体现出 TON 区块链的特色。用户能够为自己的 V4 钱包合约安装「插件」，也就是模组化的为自己的钱包添加额外的「功能」或「规则」。举例来说，用户可以安装一个订阅扣款插件，允许指定的服务提供商按照一定的规则向自己的钱包收费。因为钱包也是一个智能合约，所以第三方的伺服器可以直接跟这个合约互动进行请款，用户就不再需要手动的定期付款了（或为了实现自动付款将资金转移到另一个合约内）。
此外，TON 基金会及其他社群开发者也提供了诸如具有多签、线性解锁等功能的钱包合约。其中也包含了「高流量」钱包的范本，供交易所等大型机构使用，该合约在一次呼叫内可以接收最多 254 笔交易，并且可以同时接收多笔呼叫，因此理论上最多能够在一秒内进行上千笔交易。