跳到正文
研踪PaperTrail
← 研踪 PaperTrail

arXiv:2607.21021 · v6

Multimmit: Extending Blocks for Faster Finality

Multimmit:扩展区块以实现更快的最终性

首次提交 2026-07-23 16:05
版本更新 2026-11-13 00:52
雷达观测 2026-11-13 14:15
arXiv ↗PDF ↗

摘要

To meet the throughput demands of blockchain systems, protocols for State Machine Replication increasingly have many processors disseminate transaction blocks in parallel. Certified designs require availability certificates before blocks enter the ordering process, which is robust but adds latency. BlueBottle, the leading uncertified design under n≥5f+1n\geq 5f+1 (nn processors, at most ff Byzantine), reduces latency in favourable conditions but can put fetching missing data on the critical path. Raptr, the state of the art under n≥3f+1n\geq 3f+1, avoids fetching on the voting path, but transactions wait for a leader's proposal and two voting rounds, and the leader controls the proposed sequence. We prove that strengthening the resilience assumption alone cannot remove Raptr's second voting round. We present Multimmit, a protocol for n≥5f+1n\geq 5f+1 that builds on Raptr's approach and finalises leader blocks after a single round of voting, improving latency by at least one message delay. Extension votes let voters endorse fresh transaction blocks omitted from the leader's proposal: once a leader block finalises, every fresh, well-circulated block of an honest chain enters the total ordering by the next finalised leader block, even if that block's leader is Byzantine. Producer chains are interleaved by a prescribed rule, not in a leader-chosen sequence. Payments are final within a single round trip, once the producer assembles n−fn-f acknowledgments into a transferable receipt. With fifty validators across thirteen regions, Multimmit's median latency to placement in the total ordering moves from 383 to 411 ms as the offered rate rises from 100k to 1M transactions per second. At 100k, it is essentially unchanged under 0.1% message loss and rises by a factor of 1.4 with nine validators crashed; these conditions slow BlueBottle and Raptr, respectively, by more than an order of magnitude.

AI 论文解读

基于摘要 · 非全文审阅

Multimmit 在 n≥5f+1 下基于 Raptr 实现单轮投票最终确定领导者区块,并通过扩展投票纳入被遗漏的新鲜交易区块,从而降低延迟。

正在读取账号与研究记录…

版本差异

本站首次收录为 v6,暂无更早版本可对照。

观测到的版本

相邻记录可能跳过中间版本;首次发现 v2 及以上也会标为版本更新。

v6 · 2026-11-13 00:52 · 最新观测版本

Multimmit: Extending Blocks for Faster Finality

To meet the throughput demands of blockchain systems, protocols for State Machine Replication increasingly have many processors disseminate transaction blocks in parallel. Certified designs require availability certificates before blocks enter the ordering process, which is robust but adds latency. BlueBottle, the leading uncertified design under n≥5f+1n\geq 5f+1 (nn processors, at most ff Byzantine), reduces latency in favourable conditions but can put fetching missing data on the critical path. Raptr, the state of the art under n≥3f+1n\geq 3f+1, avoids fetching on the voting path, but transactions wait for a leader's proposal and two voting rounds, and the leader controls the proposed sequence. We prove that strengthening the resilience assumption alone cannot remove Raptr's second voting round. We present Multimmit, a protocol for n≥5f+1n\geq 5f+1 that builds on Raptr's approach and finalises leader blocks after a single round of voting, improving latency by at least one message delay. Extension votes let voters endorse fresh transaction blocks omitted from the leader's proposal: once a leader block finalises, every fresh, well-circulated block of an honest chain enters the total ordering by the next finalised leader block, even if that block's leader is Byzantine. Producer chains are interleaved by a prescribed rule, not in a leader-chosen sequence. Payments are final within a single round trip, once the producer assembles n−fn-f acknowledgments into a transferable receipt. With fifty validators across thirteen regions, Multimmit's median latency to placement in the total ordering moves from 383 to 411 ms as the offered rate rises from 100k to 1M transactions per second. At 100k, it is essentially unchanged under 0.1% message loss and rises by a factor of 1.4 with nine validators crashed; these conditions slow BlueBottle and Raptr, respectively, by more than an order of magnitude.

查看此版本解读 →查看此版本原文 ↗