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父区块哈希、heightinfo.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常规所有者及其权重BTreeMapAccountOwner, u64权重决定其被选为轮次 leader 的频率first_leader首个单 leader 轮的指定 leader未设置则与其他轮次一样随机选取multi_leader_rounds允许所有所有者提议区块的轮数open_multi_leader_rounds多 leader 轮是否不受仅限链所有者限制仅应在应用层有严格的出块者选择机制时置为truetimeout_config各轮次的超时配置见TimeoutConfigfast_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Linera 协议中的区块创建机制：提议与验证分离下的多类型链共识详解
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父区块哈希、heightinfo.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常规所有者及其权重BTreeMapAccountOwner, u64权重决定其被选为轮次 leader 的频率first_leader首个单 leader 轮的指定 leader未设置则与其他轮次一样随机选取multi_leader_rounds允许所有所有者提议区块的轮数open_multi_leader_rounds多 leader 轮是否不受仅限链所有者限制仅应在应用层有严格的出块者选择机制时置为truetimeout_config各轮次的超时配置见TimeoutConfigfast_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考