Skip to content

Commit 3f6fe55

Browse files
[docs] The Carnot Bound (#3436)
1 parent 9d697fc commit 3f6fe55

8 files changed

Lines changed: 254 additions & 1 deletion

File tree

docs/blogs/carnot-bound.html

Lines changed: 201 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,201 @@
1+
<!DOCTYPE html>
2+
<html lang="en">
3+
4+
<head>
5+
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
6+
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1" />
7+
<link rel="preload" href="/style.css" as="style">
8+
<link rel="preload" href="/shared.js" as="script">
9+
<link rel="icon" href="/favicon.ico" type="image/x-icon">
10+
11+
<title>commonware > The Carnot Bound</title>
12+
<meta name="description" content="Recently, we released a paper
13+
called The Carnot Bound, which investigates the fundamental limits and
14+
possibilities for bandwidth-efficient consensus. The paper establishes a
15+
tight lower bound on coding efficiency for protocols with fast finality,
16+
and shows that an additional round of voting breaks the barrier.">
17+
<meta name="author" content="Andrew Lewis-Pye">
18+
<meta name="keywords" content="commonware, open source, common goods, software, internet, ownership, trust, blockchain, decentralization, crypto">
19+
20+
<meta property="og:url" content="https://commonware.xyz/blogs/carnot-bound" />
21+
<meta property="og:type" content="article" />
22+
<meta property="og:site_name" content="commonware" />
23+
<meta property="og:image" content="https://commonware.xyz/imgs/carnot.png" />
24+
<meta property="og:title" content="The Carnot Bound" />
25+
<meta property="og:description" content="Recently, we released a
26+
paper called The Carnot Bound, which investigates the fundamental limits
27+
and possibilities for bandwidth-efficient consensus. The paper
28+
establishes a tight lower bound on coding efficiency for protocols with
29+
fast finality, and shows that an additional round of voting breaks the
30+
barrier." />
31+
<meta property="article:author" content="Andrew Lewis-Pye" />
32+
<meta property="article:published_time" content="2026-03-20T00:00:00Z" />
33+
<meta property="article:modified_time" content="2026-03-20T00:00:00Z" />
34+
35+
<link rel="canonical" href="https://commonware.xyz/blogs/carnot-bound" />
36+
37+
<meta name="twitter:card" content="summary_large_image" />
38+
<meta property="twitter:domain" content="commonware.xyz" />
39+
<meta property="twitter:url" content="https://commonware.xyz/blogs/carnot-bound" />
40+
<meta property="twitter:title" content="The Carnot Bound" />
41+
<meta property="twitter:description" content="Recently, we released
42+
a paper called The Carnot Bound, which investigates the fundamental
43+
limits and possibilities for bandwidth-efficient consensus. The paper
44+
establishes a tight lower bound on coding efficiency for protocols with
45+
fast finality, and shows that an additional round of voting breaks the
46+
barrier." />
47+
<meta property="twitter:image" content="https://commonware.xyz/imgs/carnot.png" />
48+
<meta property="twitter:site" content="@commonwarexyz" />
49+
<meta property="twitter:creator" content="https://x.com/AndrewLewisPye" />
50+
51+
<link rel="stylesheet" type="text/css" href="/style.css">
52+
53+
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.16.0/dist/katex.min.css">
54+
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.0/dist/katex.min.js"></script>
55+
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.0/dist/contrib/auto-render.min.js" onload="renderMathInElement(document.body);"></script>
56+
</head>
57+
58+
<body>
59+
<div id="logo-placeholder">
60+
<div class="logo-line">
61+
<span class="edge-logo-symbol">+</span>
62+
<span class="horizontal-logo-symbol">~</span>
63+
<span class="horizontal-logo-symbol"> </span>
64+
<span class="horizontal-logo-symbol">-</span>
65+
<span class="horizontal-logo-symbol">+</span>
66+
<span class="horizontal-logo-symbol">-</span>
67+
<span class="horizontal-logo-symbol">+</span>
68+
<span class="horizontal-logo-symbol"> </span>
69+
<span class="horizontal-logo-symbol">-</span>
70+
<span class="horizontal-logo-symbol">+</span>
71+
<span class="horizontal-logo-symbol">-</span>
72+
<span class="horizontal-logo-symbol">~</span>
73+
<span class="horizontal-logo-symbol">~</span>
74+
<span class="edge-logo-symbol">*</span>
75+
</div>
76+
<div class="logo-line">
77+
<span class="vertical-logo-symbol">|</span>
78+
<span class="logo-text"> commonware </span>
79+
<span class="vertical-logo-symbol"> </span>
80+
</div>
81+
<div class="logo-line">
82+
<span class="edge-logo-symbol">*</span>
83+
<span class="horizontal-logo-symbol">~</span>
84+
<span class="horizontal-logo-symbol">+</span>
85+
<span class="horizontal-logo-symbol">+</span>
86+
<span class="horizontal-logo-symbol">-</span>
87+
<span class="horizontal-logo-symbol"> </span>
88+
<span class="horizontal-logo-symbol">~</span>
89+
<span class="horizontal-logo-symbol">-</span>
90+
<span class="horizontal-logo-symbol">+</span>
91+
<span class="horizontal-logo-symbol"> </span>
92+
<span class="horizontal-logo-symbol">-</span>
93+
<span class="horizontal-logo-symbol">*</span>
94+
<span class="horizontal-logo-symbol">-</span>
95+
<span class="edge-logo-symbol">+</span>
96+
</div>
97+
</div>
98+
<div class="content">
99+
<h1>The Carnot Bound</h1>
100+
<div class="meta">
101+
102+
<div class="author">By <a href="https://x.com/AndrewLewisPye">Andrew
103+
Lewis-Pye</a></div>
104+
<div class="date">March 20th, 2026</div>
105+
</div>
106+
<p>Recently, we released a paper called <a
107+
href="https://arxiv.org/abs/2603.11797">The Carnot Bound</a>,
108+
which investigates the fundamental limits and possibilities for
109+
bandwidth-efficient consensus. The paper establishes a tight
110+
lower bound on coding efficiency for protocols with fast
111+
finality, and shows that an additional round of voting breaks
112+
the barrier. Here’s the idea.</p>
113+
<p>In leader-based consensus, the leader is the throughput
114+
bottleneck. Every block the leader proposes must be sent to
115+
every other processor, and the time this takes is governed by a
116+
key parameter: the <em>data expansion rate</em>. If a block
117+
payload has size <span class="math inline">\(\beta\)</span>, and
118+
the leader must send a total of <span class="math inline">\(d
119+
\cdot \beta\)</span> bits across all processors, then <span
120+
class="math inline">\(d\)</span> is the data expansion rate. The
121+
closer <span class="math inline">\(d\)</span> is to <span
122+
class="math inline">\(1\)</span>, the closer maximum throughput
123+
gets to the raw network bandwidth.</p>
124+
<p>Erasure coding is what makes <span class="math inline">\(d
125+
&lt; n\)</span> possible. Rather than sending a full copy of the
126+
block to each of the <span class="math inline">\(n\)</span>
127+
processors, the leader encodes the payload into <span
128+
class="math inline">\(n\)</span> fragments, each much smaller
129+
than the original, from which the full payload can be
130+
reconstructed once enough fragments are collected. The question
131+
is: how small can <span class="math inline">\(d\)</span>
132+
actually get?</p>
133+
<h2 id="a-wall-at-2.5">A wall at 2.5</h2>
134+
<p>The answer depends on how many rounds of communication your
135+
protocol needs to finalise a block. Protocols with <em>2-round
136+
finality</em>—one round for the leader’s proposal, one round of
137+
voting—include <a
138+
href="https://arxiv.org/abs/2508.10862">E-Minimmit</a> and <a
139+
href="https://arxiv.org/abs/2505.08771">Kudzu</a>. These
140+
protocols achieve data expansion rates of roughly <span
141+
class="math inline">\(2.5\)</span>. In the paper, we prove this
142+
is optimal: no protocol with 2-round finality can do better. The
143+
bound is tight.</p>
144+
<p>The impossibility is established via an indistinguishability
145+
argument. In a protocol with 2-round finality, if the leader
146+
crashes immediately after sending fragments to a subset of
147+
processors, those processors must still be able to determine the
148+
leader’s proposal. This forces enough redundancy in the leader’s
149+
messages that the data expansion rate cannot drop below <span
150+
class="math inline">\(2.5\)</span>.</p>
151+
<h2 id="breaking-through-with-a-second-vote">Breaking through
152+
with a second vote</h2>
153+
<p>Protocols with <em>3-round finality</em>—one proposal round
154+
and two rounds of voting—can circumvent this bound entirely,
155+
pushing the data expansion rate arbitrarily close to <span
156+
class="math inline">\(1\)</span>. The key insight is that the
157+
second voting round provides a recovery mechanism. A leader can
158+
<em>attempt</em> an aggressive erasure code, and if some
159+
processors fail to reconstruct the payload, the second round
160+
detects this and allows the protocol to nullify the view and
161+
retry. With only one round of voting, a failed reconstruction
162+
attempt can leave the protocol in an unrecoverable state. With
163+
two rounds, it cannot.</p>
164+
<p>We present two protocols realising this approach, both
165+
building on <a
166+
href="https://link.springer.com/chapter/10.1007/978-3-031-48624-1_17">Simplex</a>.
167+
<strong>Carnot 1</strong> assumes <span class="math inline">\(n
168+
\geq 4f+1\)</span> processors and achieves a particularly clean
169+
design: processors echo their fragment once upon voting, and no
170+
further fragment dissemination is ever required.</p>
171+
<p><img src="/imgs/carnot-algo-1.png" /></p>
172+
<p><strong>Carnot 2</strong> operates under the optimal
173+
assumption <span class="math inline">\(n \geq 3f+1\)</span>, at
174+
the cost of additional fragment dissemination when Byzantine
175+
processors interfere.</p>
176+
<p><img src="/imgs/carnot-algo-3.png" /></p>
177+
<p><img src="/imgs/carnot-algo-4.png" /></p>
178+
<p>Under favourable conditions—correct leaders and few actual
179+
faults—both protocols allow data expansion rates approaching
180+
<span class="math inline">\(1\)</span>. When conditions
181+
deteriorate, they revert to safe rates of roughly <span
182+
class="math inline">\(1.33\)</span> and <span
183+
class="math inline">\(1.5\)</span>, respectively. Both rates are
184+
well below the <span class="math inline">\(2.5\)</span> wall for
185+
2-round protocols.</p>
186+
<p>Both protocols can also incorporate stable leaders and
187+
optimistic proposals, eliminating the gap between consecutive
188+
block proposals and allowing throughput to approach the
189+
underlying network bandwidth.</p>
190+
<p><img src="/imgs/carnot-algo-2.png" /></p>
191+
<p>The paper is available on <a
192+
href="https://arxiv.org/abs/2603.11797">arXiv</a>. The name is
193+
inspired by the Carnot heat engine, which achieves the
194+
theoretical maximum efficiency for converting heat into work.
195+
Similarly, our protocols aim to approach the theoretical maximum
196+
efficiency for converting network bandwidth into throughput.</p>
197+
<div id="footer-placeholder"></div>
198+
<script src="/shared.js"></script>
199+
</body>
200+
201+
</html>

docs/blogs/carnot-bound.md

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
---
2+
title: "The Carnot Bound"
3+
description: "Recently, we released a paper called The Carnot Bound, which investigates the fundamental limits and possibilities for bandwidth-efficient consensus. The paper establishes a tight lower bound on coding efficiency for protocols with fast finality, and shows that an additional round of voting breaks the barrier."
4+
date: "March 20th, 2026"
5+
published-time: "2026-03-20T00:00:00Z"
6+
modified-time: "2026-03-20T00:00:00Z"
7+
author: "Andrew Lewis-Pye"
8+
author_twitter: "https://x.com/AndrewLewisPye"
9+
url: "https://commonware.xyz/blogs/carnot-bound"
10+
image: "https://commonware.xyz/imgs/carnot.png"
11+
katex: true
12+
---
13+
14+
Recently, we released a paper called [The Carnot Bound](https://arxiv.org/abs/2603.11797), which investigates the fundamental limits and possibilities for bandwidth-efficient consensus. The paper establishes a tight lower bound on coding efficiency for protocols with fast finality, and shows that an additional round of voting breaks the barrier. Here's the idea.
15+
16+
In leader-based consensus, the leader is the throughput bottleneck. Every block the leader proposes must be sent to every other processor, and the time this takes is governed by a key parameter: the *data expansion rate*. If a block payload has size $\beta$, and the leader must send a total of $d \cdot \beta$ bits across all processors, then $d$ is the data expansion rate. The closer $d$ is to $1$, the closer maximum throughput gets to the raw network bandwidth.
17+
18+
Erasure coding is what makes $d < n$ possible. Rather than sending a full copy of the block to each of the $n$ processors, the leader encodes the payload into $n$ fragments, each much smaller than the original, from which the full payload can be reconstructed once enough fragments are collected. The question is: how small can $d$ actually get?
19+
20+
## A wall at 2.5
21+
22+
The answer depends on how many rounds of communication your protocol needs to finalise a block. Protocols with *2-round finality*---one round for the leader's proposal, one round of voting---include [E-Minimmit](https://arxiv.org/abs/2508.10862) and [Kudzu](https://arxiv.org/abs/2505.08771). These protocols achieve data expansion rates of roughly $2.5$. In the paper, we prove this is optimal: no protocol with 2-round finality can do better. The bound is tight.
23+
24+
The impossibility is established via an indistinguishability argument. In a protocol with 2-round finality, if the leader crashes immediately after sending fragments to a subset of processors, those processors must still be able to determine the leader's proposal. This forces enough redundancy in the leader's messages that the data expansion rate cannot drop below $2.5$.
25+
26+
## Breaking through with a second vote
27+
28+
Protocols with *3-round finality*---one proposal round and two rounds of voting---can circumvent this bound entirely, pushing the data expansion rate arbitrarily close to $1$. The key insight is that the second voting round provides a recovery mechanism. A leader can *attempt* an aggressive erasure code, and if some processors fail to reconstruct the payload, the second round detects this and allows the protocol to nullify the view and retry. With only one round of voting, a failed reconstruction attempt can leave the protocol in an unrecoverable state. With two rounds, it cannot.
29+
30+
We present two protocols realising this approach, both building on [Simplex](https://link.springer.com/chapter/10.1007/978-3-031-48624-1_17). **Carnot 1** assumes $n \geq 4f+1$ processors and achieves a particularly clean design: processors echo their fragment once upon voting, and no further fragment dissemination is ever required.
31+
32+
![](/imgs/carnot-algo-1.png)
33+
34+
**Carnot 2** operates under the optimal assumption $n \geq 3f+1$, at the cost of additional fragment dissemination when Byzantine processors interfere.
35+
36+
![](/imgs/carnot-algo-3.png)
37+
38+
![](/imgs/carnot-algo-4.png)
39+
40+
Under favourable conditions---correct leaders and few actual faults---both protocols allow data expansion rates approaching $1$. When conditions deteriorate, they revert to safe rates of roughly $1.33$ and $1.5$, respectively. Both rates are well below the $2.5$ wall for 2-round protocols.
41+
42+
Both protocols can also incorporate stable leaders and optimistic proposals, eliminating the gap between consecutive block proposals and allowing throughput to approach the underlying network bandwidth.
43+
44+
![](/imgs/carnot-algo-2.png)
45+
46+
The paper is available on [arXiv](https://arxiv.org/abs/2603.11797). The name is inspired by the Carnot heat engine, which achieves the theoretical maximum efficiency for converting heat into work. Similarly, our protocols aim to approach the theoretical maximum efficiency for converting network bandwidth into throughput.

docs/imgs/carnot-algo-1.png

206 KB
Loading

docs/imgs/carnot-algo-2.png

258 KB
Loading

docs/imgs/carnot-algo-3.png

166 KB
Loading

docs/imgs/carnot-algo-4.png

125 KB
Loading

docs/imgs/carnot.png

78 KB
Loading

docs/index.html

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -132,7 +132,13 @@ <h3><a href="https://docs.rs/commonware-sync">sync</a></h3>
132132
<p>Synchronize state between a server and client.</p>
133133

134134
<h2>Blogs</h2>
135-
<h3><a href="/blogs/its-a-grind.html">It’s a Grind</a></h3>
135+
<h3><a href="/blogs/carnot-bound.html">The Carnot Bound</a></h3>
136+
<div class="meta">
137+
<div class="author">By <a href="https://x.com/AndrewLewisPye">Andrew Lewis-Pye</a></div>
138+
<div class="date">March 20th, 2026</div>
139+
</div>
140+
<p>Recently, we released a paper called The Carnot Bound, which investigates the fundamental limits and possibilities for bandwidth-efficient consensus. The paper establishes a tight lower bound on coding efficiency for protocols with fast finality, and shows that an additional round of voting breaks the barrier.</p>
141+
<h3><a href="/blogs/its-a-grind.html">It's a Grind</a></h3>
136142
<div class="meta">
137143
<div class="author">By <a href="https://x.com/roberto_bayardo">Roberto Bayardo</a></div>
138144
<div class="date">February 27, 2026</div>

0 commit comments

Comments
 (0)