结论先说
多数公链谈分片，先规划好“切几刀”，TON 走的是另一条路：官方文档称之为无限分片范式——分片的交易量超过阈值时，验证者决定把它一分为二；交易量降回阈值以下，再自动合并回去。整个过程发生在协议内部，用户不需要选边站队，同一工作链内分片数量可以随负载在 1 到 2^60 之间以 2 的幂动态变化。与这套机制配套的还有一个异步执行模型：TON 的一笔“交易”只对应单个账户处理单条消息的一次状态变更，在以太坊上一笔办完的业务，在 TON 上会展开成跨多个区块的一串交易。
分片为什么难：静态切法卡在哪
分片是什么？以太坊分片解决什么问题里讲过，分片的思路是让多组节点各处理一部分负载，但静态分片有两个老毛病：切多了，冷门分片空转、跨片协调成本高；切少了，热门分片照样拥堵，而且改分片参数往往要全体协调。TON 的答案是把“分几片”做成负载的因变量。哪个账户归哪片，完全由地址决定：每个分片用工作链编号加一段比特前缀标识，账户编号的高位比特以该前缀开头的就归这片。分裂时沿比特位把账户空间对半切开，合并是逆操作。账户不需要迁移——变的只是这张“账本归片地图”，不是数据本身。
消息怎么在片间路由
每个分片都独立、异步地计算，于是一个分片往外发消息、对面的分片一时消化不完是常态：塞不进当前区块的消息会滞留，等后续区块慢慢收。如果每个接收分片都要去检查所有其他分片有没有待发给自己消息，分片一多，检查时间就无法接受。TON 用超立方体路由收束这个问题：每个分片最多连接二百四十个相邻分片，消息沿超立方体的边逐跳转发，同一工作链内任意两个分片之间最多十五跳，跨工作链再加一跳。对用户而言，由此产生的直觉是：跨分片操作不是原子的——发送端先落定，接收端在其后某个区块才落定，中间存在一段“在路上”的状态。
用户视角：一笔业务变成一串交易
TON 官方文档在“Coming from Ethereum”页给了明确映射：在 TON 上，处理一条消息并改一个合约的状态才叫一笔交易；以太坊上的一次合约调用，如果触发多个合约的状态变化，到 TON 上就是一条由许多交易组成的“链路”（trace），要跑完好几个区块。文档甚至举了一个由单条消息引发、跨数千个区块才跑完上百万笔交易的例子作为对照。与 EVM 经验的另外几处差异也值得记住：交易执行期间合约不能同步调用另一个合约的 get 方法，因为等真去读时数据可能已经变了，所以读取一律放在链下或回执里；单个合约的存储有明确上限，官方文档标注为 65,536 个唯一存储单元（cell），因此想照搬 ERC-20 那样在一张合约里放无限增长的映射在 TON 上行不通，官方建议用合约分片技术把状态摊开。
边界与风险
第一，“动态”意味着你看到的网络拓扑一直在变，程序化查询不要写死分片结构，应按区块高度实时查询当前分片树。第二，异步消息带来最终一致窗口：跨分片的转账有在途状态，关心“到账没有”的场景要看整条 trace 是否落定，而不是只盯发送方那一笔回执。第三，分裂与合并的负载阈值属于协议配置，会随网络升级调整，以官方文档为准，不宜把文章钉死在某个数字上。第四，官方文档把典型出块与最终性描述在亚秒级，但那是典型情况描述，不是服务水平承诺，实际体验受节点与负载影响。
小结
TON 的分片思路是把网络形状交给规则而不是路线图：负载决定分裂与合并，地址前缀决定账户归属，超立方体路由把跨片消息面压缩成有限邻居与最多十几跳。从 EVM 过来的读者要更新三个观念：交易粒度更小、业务以 trace 形式展开、合约间不能同步读数据。本文为机制说明，依据官方文档整理，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。