达成一致
交易在 Sumeragi 在一个区块中提出之前进入队列.验证者独立验证和执行该提案,然后只签署他们可以复制的状态过渡.要求验证人数组同意该结果后,区块承诺并提供匹配的有效载荷.
所有 Iroha 3 网络都使用数据可用性和可靠的广播路径. 这些是共识要求,而不是可选部署功能.
Sumeragi
Sumeragi 是 Iroha 的拜占庭错误耐受共识引擎.它从队列中取出交易,让验证者同行同意同一条订单的块,并在足够的验证者复制相同结果并签署承诺证书后才完成该块.
提议和承诺途径
Sumeragi 一次运行本书一块高度.每一个高度,一个验证者作为当前视图的提议者.提议者从队列中取消符合条件的交易,构建一个候选区块,并向活跃的验证器集合宣布该提案.
同一个 Sumeragi 管道用于授权和指名证据 (NPoS) 的部署:
- 一个验证者提出了排队交易的阻止.
- 验证者通过对同一个世界国家进行交易来验证该提案.
- 验证者对当前的高度和视图交换了投票和定制证书.
- 一旦达成合同定数, 同龄人会阻止和更新他们的世界状况.
验证器只签署他们可以本地复制的数据. 在投票之前,验证者检查该提案是否属于预期链路,高度和视图;交易签名和限制是否有效;轨道路由和执行者的验证是否确定性;如果本地结果不同,验证者将拒绝该提案,而不是投票支持.
投票是小签名的共识信息.它们指的是拟议的块,高度,视图和验证器身份.收藏者将这些投票集成到一个定数证书或提交证书. 证书是足够的验证者对同一块观察到同样的结果的持久证明.
团队,收集者和观察员
投票验证人数量 n 对于至少有4个验证器的网络,预算为 f = floor((n - 1) / 3) 委托人数是: 2f + 1. 一到三个验证器,所有验证者都需要承担,这对开发有用,但没有实际的离线宽松性.
而不是每一个验证器向其他验证器发送每个投票, Sumeragi 可以选择一个或多个收集器为高度.收藏者收集投票,公布定数进展和减少重复投票流量.通过 GET /v1/sumeragi/collectors暴露有效收藏器设置; CLI 的 ops sumeragi telemetry快照报告了当前收藏器计数.
观察员同行可以同步承诺的区块,但它们不会提出,投票,收集票数或计入提交定制组.在部署需要本地查询能力,索引,监测或区域区块复制的情况下使用观察员,而不会增加投票验证者的数量.
查看变化和恢复
一个视图是 Sumeragi 试图通过特定的提议者和时间计划完成一个高度.如果提案,有效载荷,投票或执行进步摊位,心脏计时器可以将高度转移到更晚的视图.视图改变不会重写承诺的块.它改变了验证者试图完成未承诺的高度的方式,将已知的最高数量推进或提交证据,以便同龄人不会最终完成矛盾的块.
一个同行可能在获得完整的区块实用负载之前收到定数或承诺证书.同行使用可靠的广播 (RBC) 或区块同步来恢复有效载荷,对广告的哈希进行验证,然后才将区块应用到世界状态和 Kura.
共识方式
选择的模式控制了验证器集是如何形成和运行的.它通过 consensus_mode在基因中被声明,并通过 sumeragi.consensus_mode在同等配置中被宣布.视为整个网络状态:验证器需要相同的签署基因,拓学,可靠的同行数据和有效的 Sumeragi 参数.
| 模式 | 最适合的 | 验证器设置 | 运营重点 |
|---|---|---|---|
| 允许 | 私人,联盟和运营商管理的网络 | 验证器来自部署同意的可靠同行拓学 | 保持所有验证器相同的签名基因,可信的同行,同行键和 Sumeragi 参数. |
| 公共服务局 | 公共或 Nexus- 核准后的指名和股权政策 | 验证器是根据NPoS资料选择的,通常在各个时代之间,并且需要 BLS 键加上拥有证明. | 在整个网络中保持分局快照,时代参数,验证器 PoPs 和NPoS阶段时间排列 |
允许的模式
在验证器名单是明确的操作选择时使用允许模式.这是自主托管 Iroha 网络的通常起点,因为会员变更是故意的治理或管理者行动.重要操作规则是,每个验证器必须以相同的基因观,可信任同行,BLS 所有权证明和 Sumeragi 参数运行.具有不同的拓或签名基因的单个同行可以防止网络进行承诺.
NPOS模式
使用NPoS模式,当部署配置预计验证者的参与由提名和投资状态驱动时. SORA Nexus 部署使用NPoS,其生成的资料包括: BLS 验证人身份,拥有权证明,时代设置,以及 Sumeragi 在启动时需要的NPoS参数. 年代变化可以取代在定义高度设置的活跃验证器,因此,运营商需要监测共识的健康状况以及接下来的名单的参与或提名状态.
多边共识
Iroha 的多行共识路径通过 Nexus 车道和数据空间配置实现.它不会为每个车道启动一个单独的共识实例.Sumeragi 仍然完成一个订单的区块流; 轨道描述了交易如何在该流中路由,计划,计量和存储.
运行时间配置构建了三个车道状态:
lane_catalog:配置的行径,每个行列都有一个数字的LaneId,别名,数据空间,可见性,存储资料,证明方案和元数据.dataspace_catalog:配置的数据空间,每个区域都有一个数值DataSpaceId和用于继电委员会尺寸的故障耐受值.routing_policy:默认行径/数据空间对和可匹配账户或指令路径的顺序路由规则.
当一个交易进入队列时,车道路由器将其解决为 RoutingDecision { lane_id, dataspace_id }.在单车道模式下,这总是车道 0 和通用数据空间.在 Nexus 模式下,配置的路由器应用数据空间范围规则,结算路由,账户规则,明确路由规则,最后是默认路线.已解决的行径和数据空间必须存在于它们的目录中,并且该行径必须与已解决的数据空间联系在一起;否则交易在排队之前被拒绝.
排队将这个路由决定与交易哈希保持在一起,以便后期阶段不需要再推断它.后者以两种方式使用车道元数据:
- 它将交易分隔一条车道,所以一个车道不占据区块,仅因为其交易是排队的.
- 它适用于每条车道交易执行单元 (TEU) 的限制.超越车道配置容量的交易会被推迟和排队,除了可以允许第一个车道过度权重交易以避免活.
在可靠的广播中, Sumeragi 按车道和数据空间整合了拟议的有效载荷.记录的总数包括交易计数,广播块,有效载荷字节和 TEU.提交后,这些总数成为通过 Sumeragi 状态曝光的轨道和数据区域承诺快照.如果区块包含车道结算收据,则区块处理还会创建车道结账承诺和连接包裹,绑定区块标题,提交证书,数据可用性承诺哈希,结账证明以及车道有效载荷大小.
可靠的广播 (RBC)
可靠的广播 (RBC) 是 Sumeragi 的有效载荷传播和恢复路径. 它帮助验证者和观察员获取属于提案的块体或承诺证书,特别是当一个 BlockCreated消息,区块同步更新或直接的有效载荷转移延迟或丢失时.
RBC 在有效载荷级别上运行. 提出者宣布 RBC 会议为区块高度,视图和有效载荷哈希,然后将有效载荷块发送到提交拓度中.同行追踪部分收件,验证恢复的有效载荷与广告的哈希和交换 READY 和 DELIVER信号一旦有足够的验证者会议被限制在 TTL,零件, fanout,悬而未决的存储和持久的存储限制,因此恢复流量不能无限增长.
RBC 不是单独的共识决定,也不取代承诺证书.当同行有有效的承诺证书和本地相匹配的实用负载时,一个区块仍然会完成.RBC 提供强制性可用性证据和有效载荷回收,而承诺进展是由提交证书加上本地有效载荷驱动的.如果证书在有效载荷之前抵达,同行可以通过 RBC 或区块同步恢复有效载荷,然后承担.
在操作上, RBC 对于诊断缺失有效载荷和数据可用性瓶有用:
iroha --output-format text ops sumeragi telemetry显示总可用性投票,当前收藏人数和正在进行的 RBC 会议.GET /v1/sumeragi/rbc和GET /v1/sumeragi/rbc/sessions披露详细的综合数据和活动会议数据 Torii, 包括零件进展,准备性,交付状态以及车道或数据空间后载;见 Torii 终点.- 预测信号如:
sumeragi_rbc_store_pressure,sumeragi_rbc_backpressure_deferrals_total, 和每条路线或每条数据空间 RBC 后载量度仪有助于分离网络损失,零件恢复和存储压力;见 绩效和指标.
Kura 用于存储布局的衍生车道配置.每条车道都获得blocks/lane_000_core和merge_ledger/lane_000_core_merge.log等确定性存储名称;车道生命周期变化可以在不改变全球区块顺序的情况下提供,退休或重新标签这些段落.