Contenu source (brut)
<p>Many thanks to <a href="https://x.com/__lostin__" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Matt</span></a>, <a href="https://x.com/nick_pennie" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Nick</span></a>, <a href="https://x.com/alessandrod" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Alessandro</span></a>, <a href="https://x.com/bw_solana" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Brennan</span></a>, and <a href="https://x.com/MaxResnick" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Max</span></a> for reviewing earlier versions of this work.</p><h2>Actionable Insights</h2><ul class="list-bullet"><li value=1>Constellation is the first formal, protocol-level proposal to implement Multiple Concurrent Proposers (MCP) on a production blockchain at scale.</li><li value=2>Constellation introduces two new roles (i.e., proposers and attesters) that constrain the leader’s discretion over block construction. Approximately 16 proposers operate concurrently on a 50ms cycle, assembling transactions into erasure-coded pslices distributed to 256 attesters. The attestation record cryptographically binds the leader to the set of transactions it includes. If a pslice is attested to by a sufficient number of attesters, then the leader cannot exclude the transaction without producing an invalid block that the network will reject.</li><li value=3>Constellation has the selective censorship-resistance property: either all fee-competitive transactions are included or none are in any given cycle.</li><li value=4>Content-visible ordering and timing-manipulation attacks still remain unsolved. Transactions under Constellation are visible to all proposers who receive the transaction at submission time. Because of MCP’s multi-proposer architecture, this may actually widen these attack surfaces instead of narrowing them. Time-based latency games are acknowledged as unpunishable under the current design.</li><li value=5>Constellation restructures existing fees—the inclusion fee maps to today’s base fee, and the ordering fee maps to the existing priority fee. The more significant economic shift is that activity currently flowing through out-of-protocol landing services and off-chain fee arrangements should return to the protocol. Stake-weighted role selection means existing concentration dynamics carry over, and the net impact on individual validators cannot be modeled until Constellation’s eventual SIMD.</li><li value=6>MCP increases sequence latency but decreases inclusion latency. The attester round, 50ms cycle window, and batch assembly all add time relative to today’s direct TPU submission path. Today, latency is higher for validators that immediately pack TPU transactions and lower for those who delay them. Under Constellation, valid transactions now have a bounded, protocol-enforced guarantee of inclusion.</li><li value=7>Constellation is explicitly incompatible with Proposer-Builder Separation (PBS) models. Once the attestation record constrains the leader’s discretion, there is nothing left for a specialized builder to sell. This approach represents a fundamentally different philosophy from Ethereum’s current approach to MEV.</li><li value=8>Empirical benchmarks under realistic network conditions do not yet exist. The single most important data point Anza can provide is comparative latency projections for 200ms slots under the current protocol versus 200ms slots under Constellation. Until this data is available, the community is debating tradeoffs it cannot quantify. </li><li value=9>Constellation builds on top of Alpenglow, which is targeting a Q3 2026 mainnet launch.</li></ul><h2>Introduction</h2><p>Despite a stunning lack of agave plants, Brennan Watt, CEO of Anza, <a href="https://x.com/anza_xyz/status/2036836554233000044?s=20" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">went to the California desert to unveil Constellation</span></a>—a proposal to bring Multiple Concurrent Proposers (MCP) to Solana. This is the most structurally ambitious upgrade and, arguably, the most consequential protocol-level MCP proposal any production blockchain has put forward thus far. It seeks to resolve the leader’s temporary monopoly over transaction ordering and the extractable value it creates. Constellation is the democratization of blockspace on Solana.</p><p>This article is a critical analysis of Constellation: what it solves, what it knowingly defers, and what remains genuinely unresolved. We introduce a three-layer framework for assessing censorship resistance, compare Constellation against the current MCP landscape, and examine whether the tradeoffs it introduces are compatible with the performance identity Solana has built.</p><p>Prior knowledge of <a href="https://www.helius.dev/blog/alpenglow" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Alpenglow</span></a> is assumed. </p><h2>The Problem Constellation Solves</h2><p>Transactions are the lifeblood of Solana. They are grouped together and written permanently to the network in the form of blocks. But the process of deciding which transactions make it into those blocks, and in what order, is not a neutral process. </p><h3>The Leader’s Monopoly on Block Production</h3><p>Block production rotates according to a leader schedule, in which one validator at a time is responsible for producing blocks in a given window. </p><p>During this time, transactions are <a href="https://www.helius.dev/blog/solana-gulf-stream" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">forwarded directly to the leader’s Transaction Processing Unit (TPU)</span></a>, where the leader typically receives them before anyone else. </p><p>The leader occupies a position of unusual power. That is, <em>they can observe incoming transactions before they are publicly visible</em>. </p><p>The leader can decide not to include some transactions, reorder them arbitrarily, or introduce their own. </p><p>This is a structural feature of how single-leader consensus currently works, and is present to varying degrees in virtually every production <a href="https://www.helius.dev/blog/proof-of-history-proof-of-stake-proof-of-work-explained#what-is-proof-of-stake" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Proof of Stake</span></a> blockchain today.</p><p>Solana’s absence of a public mempool sharpens this asymmetry rather than reduces it. Ethereum’s public mempool gives participants some visibility into pending transactions, creating a level playing field of sorts among sophisticated actors competing to exploit transaction ordering. </p><p>On Solana, the leader’s informational advantage is less contestable given the nature of transaction forwarding. </p><h3>Maximal Extractable Value (MEV)</h3><p>This power goes largely unexploited under normal conditions and with honest validators. However, the problem is that validators are rational economic actors. As Solana matures and financial activity continues to grow, the profit available from exploiting the leader’s temporary monopoly increases accordingly. A validator who chooses not to exploit this position is simply leaving money on the table. Correctly behaving nodes are left at an economic disadvantage—a disadvantage that incentivizes them to undermine the quality of the very system they participate in.</p><p>This extractable profit is known as <a href="https://www.helius.dev/blog/solana-mev-report" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Maximal Extractable Value (MEV)</span></a>, a term first formalized by Daian et al. in <a href="https://arxiv.org/abs/1904.05234" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">
