以太坊把数据摊平给所有人看，Solana 让每个验证者都看全部交易，而 NEAR 的 Nightshade 走的是另一条路：把链切成多个分片，每个分片由一小撮节点负责，最后由区块生产者把它们拼成一个区块。这条路的难点不在切，而在排班——谁在什么时候负责哪一片，如果还要临时协商，分片本身就会成为瓶颈。nearcore 官方协议文档给出的答案是：完全按高度提前定好。
区块里装的不是交易列表，而是一排 chunk
NEAR 的区块结构与常见链不同：一个区块为每个分片各携带一个 chunk，交易和执行内容都住在 chunk 里。可以粗略地把 chunk 理解为”该分片在这个高度上的那一小块区块”。这意味着一个 NEAR 区块天然是多个分片产物的容器，谁的 chunk 能进块、谁的 chunk 被引用，就是分片层面的出块权。负责拼装区块的叫区块生产者（block producer），负责生产某一分片 chunk 的叫 chunk producer——同一个人可以身兼二职，职责却是分开定义的。
排班规则：每个高度、每个分片，恰好一个负责人
官方文档对分配的表述很干脆：在一个 epoch 内验证者集合固定，分配基于区块高度——每个高度有一个区块生产者，每个高度与分片的组合有一个 chunk producer。分配算法要同时满足几条设计目标：被选中的频率与质押量成正比；每个入选者在一个 epoch 内至少排到一个任务；并且任何人给定高度都能以常数时间算出该由谁出块或出 chunk。最后一条意味着排班表不是一个需要广播的名单，而是一个可以由协议参数重新推导的函数——观察者不需要信任任何信息源，自己算就能核对这个高度收到的 chunk 是不是该出的那个人出的。
还有一条容易被忽略的衔接规则：高度 h 的区块生产者，应当是高度 h 减一的某个分片的 chunk producer。这样做纯粹是为了网络效率——他刚参与传播上一轮的 chunk，与这些 chunk 生产者有现成的连接，拼装新区块时不需要冷启动新的链路。
两种角色的分工：全看的人与只看一片的人
nearcore 文档把角色分成两类。区块生产者跟踪所有分片，也就是要验证全部交易后才拼装区块；另一类叫 chunk-only producer，只跟踪一个分片、只生产 chunk，永远不生产区块。这种”有人全包、有人专精”的折中，目的是让大量只跑得动单分片资源的参与者也能进入生产端，同时靠跟踪全部分片的区块生产者守住安全底线。需要说明的是，这份文档成文于 2021 年 3 月，描述的是名为 Simple Nightshade 的过渡阶段——当时分片挑战机制尚未完整实现；多年演进后主网的具体参数与角色边界，应以当前版本的官方文档和链上参数为准。
epoch：固定名单与提前换班
排班的周期单位是 epoch。官方文档写明：主网的 epoch 长度为 43200 个高度差，按约一秒一块折算约 12 小时。epoch 内验证者集合不变，轮换只发生在边界上。有两个细节值得注意。第一，epoch 的结束条件挂在前最新确认块上——只有当某个确认块的高度推进到预期起点附近，epoch 才算结束；如果链迟迟无法出确认块，epoch 会被拉长，超过名义长度。第二，处理完 epoch T 的最后一个区块后，协议立刻开始计算 epoch T+2 的验证者集合，也就是说名单永远提前一个 epoch 就定好了。这正是按高度查排班能”提前算到未来”的根基：你查询当前时刻，就能知道下一个 epoch 每个高度的负责人。
对使用者意味着什么
这套机制解释了几个常见现象。NEAR 上不同账户、不同合约的拥堵可以彼此独立——因为它们落在不同分片、由不同 chunk producer 负责，单个分片负责人掉线影响的只是那一个分片的吞吐。开发者按账户名哈希定位分片，也就间接定位了排队队列。对节点运营者，排班可推导意味着监控可以直接回答”下一个轮到我们的时刻”，提前预热；对观察链的人，任何 chunk 的签名者是否在其位，都是可离线验证的事实，不需要听任何人转述。
风险提示：本文内容为区块链协议机制的科普性介绍，不构成任何投资建议、收益承诺或买卖时机判断。链上操作涉及资产安全，跨链与提现流程受协议版本、网络状态与合约升级影响，操作前请以官方文档和链上实际状态为准，并通过小额测试验证路径。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。