企业官网建设流程全解析

Linera 协议中的区块创建机制：提议与验证分离下的多类型链共识详解

【免费下载链接】linera-protocolMain repository for the Linera protocol项目地址: https://gitcode.com/GitHub_Trending/li/linera-protocol

本指南深入解析 Linera 协议中"新区块如何被创建"这一核心机制：区块**提议（proposing）与验证（validating）**是两项分离的职责，链的进展由链所有者的钱包（即linera客户端）主动驱动，而非依赖验证者之间的相互通信。读完本文，你将掌握 single-owner 链、multi-user 链、public 链的区别，理解一条新区块从提议、投票、达成法定人数到执行落地的完整生命周期，并能在源码层面定位到对应实现。

核心前提：提议与验证职责分离

在大多数区块链系统中，节点既负责打包新区块，也负责验证区块。而 Linera 协议做出了一个关键设计取舍：负责提议区块的角色，与负责验证区块的角色，是彼此独立的。

In Linera, the responsibility of proposing blocks is separate from the task of validating blocks.

从源码结构看，这一分离在代码组织上体现得非常直观：

• 提议逻辑集中在 linera-core/src/client/chain_client/mod.rs（链所有者客户端一侧）；
• 验证与投票逻辑集中在 linera-core/src/worker.rs（验证者一侧，如handle_block_proposal）；
• 区块数据结构定义在 linera-chain/src/block.rs，证书结构定义在 linera-chain/src/certificate/ 下。

所有链都以同样的方式被验证，但 Linera 协议根据新区块由谁、以何种方式产生，定义了若干种链的类型，每一种对应不同的共识轮次与出块者集合。

Linera 链的三种类型

• single-owner 链（单所有者链）：最简单、延迟最低的链类型。整条链只有一个所有者，由其客户端独占地提议新区块，这也是当前 SDK 主要支持的形态。
• multi-user 链（多用户链）：多个用户共享一条链，任何人都可以作为所有者提议区块。当前 SDK 尚未直接支持，属于未来规划能力。
• public 链（公开链）：链的记账权向更广泛的参与者开放。SDK 同样尚未支持（更多背景可参考 Linera 白皮书）。

对于绝大多数链类型（除 public 链以外），Linera 验证者之间无需互相交换消息。

这打破了传统 BFT 共识中"验证者节点彼此网络互联、协同出块"的直觉：在 Linera 中，驱动系统前进的引擎是链所有者的钱包（linera客户端）——它负责提议区块，并主动向验证者提供任何额外的必需数据。

客户端驱动的区块创建四步流程

以linera客户端上最典型的命令为例：transfer（转账）、publish-module（发布模块）、open-chain（开启新链）。这些命令表面上是一个操作，底层却都要执行同一套"追加一个区块"的多步骤流程，把对应的代币转账、应用发布或链创建操作写入区块：

第 1 步：客户端构造区块并广播给所有验证者

Linera 客户端创建一个新区块，其中包含：

• 用户期望的操作（operation）；
• 新的传入消息（incoming messages），如果有的话；
• 最近一个区块的哈希，作为父区块指针，从而把新区块挂到链上（区块高度 +1）。

随后客户端把新区块发送给所有验证者。

从源码看，这一步对应 new_pending_block 的实现：它组装一个ProposedBlock，字段包括epoch（当前纪元）、chain_id、transactions（操作与消息打包成的事务列表）、previous_block_hash（父区块哈希）、height（info.next_block_height，即下一个待用高度）、authenticated_owner（出块者身份）以及timestamp（由 next_timestamp 计算，取"本地时钟、传入消息时间戳、上一区块时间"三者的较晚者，保证时间单调）。区块构造完成后被暂存为PendingProposal，等待签名与广播。

第 2 步：验证者校验并投票签名

验证者校验区块，即检查它满足前文列出的条件（父区块哈希正确、高度递增、操作与消息合法等），随后向客户端返回一个密码学签名，表示"我投票支持追加这个新区块"——但前提是验证者此前没有在同一高度上为另一个不同的区块投过票。

这一步在 worker.rs 的handle_block_proposal中得到体现：验证者会先检查区块时间戳是否落在未来的宽限期（block_time_grace_period）内并做相应等待，然后进入链的写锁，由 chain worker 执行具体的提案处理（校验、记录投票意向、准备投票）。

第 3 步：客户端收集法定人数投票形成证书

客户端理想情况下会收到每个验证者的投票，但实际只需要一个**法定人数（quorum）**的投票（例如三分之二）即可。这些投票构成一个"证书"（certificate），证明该区块已被确认。随后客户端把证书发送给每个验证者。

证书的数据结构可在 linera-chain/src/certificate/confirmed.rs 中看到：ConfirmedBlockCertificate由一个"带签名的ConfirmedBlock投票法定人数"（quorum）加上一条"验证过的法定人数链"（justification）组成，后者是从落地轮次（grounding round）一路上升到当前轮次的完整证据链，使得证书成为可以追溯错误归属的自包含证据。

第 4 步：验证者执行区块

验证者"执行"区块：通过应用区块内全部消息与操作，更新自己视角下该链的最新状态；如果执行过程产生了跨链消息（cross-chain messages），验证者会把这些消息发送给对应的 worker（即目标链所在的节点）。

这一阶段对应 worker.rs 的handle_confirmed_certificate：收到确认证书后，验证者执行process_confirmed_block，把区块正式落到链上，并返回更新后的ChainInfoResponse与网络动作（如跨链消息投递）。

证书驱动的安全性：执行过的区块才能投票

为了保证一个区块里的每条传入消息确实是由另一条链发送的，验证者在第 2 步中遵循一条铁律：只有当它已经执行过"发送该消息的那个区块"时，才会投票支持一个收到该消息的区块。

然而，当验证者收到一个携带它尚未见过的消息的区块的合法证书时，它仍然会接受并执行这个区块。逻辑在于：证书本身就是"大多数验证者都已经见过该消息"的证明，因此该消息必然是正确的。这条规则在保证安全性的同时，避免了验证者之间同步消息的需求，这正是"无需验证者互通信"架构得以成立的根基。

深入源码：链所有者模型如何支撑"轮次化出块"

不同链类型（single-owner / multi-user / public）在实现上，最终都落到 linera-base/src/ownership.rs 中ChainOwnership这一结构上：

• super_owners：超级所有者集合，可在第一轮（fast round）提议快速区块，并可在任何轮次提议常规区块；
• owners：常规所有者及其权重（BTreeMap<AccountOwner, u64>），权重决定其被选为轮次 leader 的频率；
• first_leader：首个单 leader 轮的指定 leader，未设置则与其他轮次一样随机选取；
• multi_leader_rounds：允许所有所有者提议区块的轮数；
• open_multi_leader_rounds：多 leader 轮是否不受"仅限链所有者"限制（仅应在应用层有严格的出块者选择机制时置为true）；
• timeout_config：各轮次的超时配置（见TimeoutConfig：fast_round_duration、base_timeout、timeout_increment、fallback_duration，默认分别为None、10 秒、1 秒、MAX）。

而共识轮次Round也在此定义：Fast（快速轮，仅 super owner 可出块）→MultiLeader（多 leader 轮）→SingleLeader（单 leader 轮）→Validator（验证者轮）。first_round()会根据所有者配置自动选择起始轮次：存在 super owner 从Fast开始；只有常规所有者且multi_leader_rounds > 0则从MultiLeader(0)开始；否则从SingleLeader(0)开始；若既无 super owner 也无 owner，则退化为验证者轮Validator(0)（即接近 public 链的形态）。

ChainOwnership::single_super(owner)构造的正是 SDK 中最常见的single-owner 链：一个 super owner、multi_leader_rounds = 5，客户端通过is_owner/can_propose_in_multi_leader_round等方法判断自己是否有权在某一轮次出块。

单所有者链的注意事项：禁止同一高度冲突出块

single-owner 链虽然延迟最低，但客户端必须被谨慎实现，绝不能在同一高度上提议多个不同的区块。否则链可能被卡死：一旦两个冲突区块各自被足够多的验证者签名，就再也不可能为其中任何一个区块收集到法定人数的投票，链从此无法延伸。

这正是new_pending_block中会检查"客户端状态中是否已有 pending block"（若有则报错，提示先用linera retry-pending-block命令提交）的原因——从客户端状态机层面防止同一高度重复出块。而验证者侧，"同一高度只投一票"的约束由链状态机与投票记录共同保证（见handle_block_proposal所调用的 chain worker 逻辑）。

展望：multi-user 链的优势

可以预期，未来大多数用户即使独自拥有自己的链，也会倾向于使用multi-user 链：

• multi-user 链拥有两个确认步骤而非一个，代价是稍高的延迟；
• 但它从根本上避免了"不小心把链搞到不可延伸"的风险（不会因同高度冲突而卡死）；
• 它还允许用户把某些管理性任务委托给第三方，尤其是有助于处理纪元变更（epoch changes，即验证者被重新配置更换时）的场合。

当前仓库中，这一愿景在ChainOwnership的设计上已有所铺垫（super owner / owner / first_leader / 轮次机制的完整抽象），但 multi-user 与 public 链的完整出块与委托流程仍需后续版本落地（相关讨论背景参见 Linera 白皮书）。

小结

区块创建是 Linera 协议中"客户端主动驱动、验证者被动响应"这一设计哲学的集中体现：linera客户端负责构造区块并收集法定人数证书，验证者负责校验、投票与执行，二者通过ProposedBlock→ 投票 →Certificate→ 执行的四步闭环协作，无需验证者之间互相通信。理解这四步流程、ChainOwnership的轮次模型以及"同高度不冲突"的约束，是编写正确、稳健的 Linera 链上客户端逻辑的基础。

【免费下载链接】linera-protocolMain repository for the Linera protocol项目地址: https://gitcode.com/GitHub_Trending/li/linera-protocol