Introduction
A failed transaction inside a Base block left dirty journal state behind it. The next valid transaction in the same block executed against that residue and was charged a mismatched amount of gas, producing an invalid state transition. Base’s validators recomputed the receipts root independently, got a different answer, and refused the block. On June 25, 2026, the chain stopped for 116 minutes. A second, unrelated race condition in engine reset slowed recovery and produced a repeat halt of 20 minutes the following day. Per Base’s own postmortem, no funds were lost and nothing invalid was finalized. The chain did the correct thing available to it, which was to stop.
Base’s stated remediations are operational: fuzz testing, load testing, and graceful recovery in base-consensus. Base does not propose decentralizing its sequencer, and the postmortem does not mention based sequencing, preconfirmations, or any architectural alternative. That is a defensible engineering position. The halt came from a software defect, and software defects are addressed with tests and better recovery paths.
What the fix does not change is the structural property that turned a defect into a chain halt. Base runs an active/passive sequencer cluster performing consensus-layer sync, distinct from the execution sync its validators perform. One logical sequencing pipeline produces every block. When that pipeline emits something the network will not accept, there is no second producer to take the slot.
An alternative has been under construction since late 2023 and is now partially live: give the sequencing right back to Ethereum’s own proposers, and use slashable promises to recover the confirmation speed that arrangement would otherwise cost. Taiko Alethia runs a permissioned version of this on mainnet today. The mechanism works well enough to ship. What remains unpriced is the economics underneath it, specifically who pays for a promise, who posts the collateral backing it, and what a promise is worth when the proposer holding it also holds block-building optionality worth more.
What the sequencer role actually holds
A rollup sequencer holds three distinct powers that are easy to conflate. It decides transaction ordering. It issues the soft confirmation that wallets and applications treat as settlement for user-facing purposes, well before anything reaches Ethereum. And it captures the priority fees and ordering value generated by that ordering right, which for most large L2s is the primary revenue line funding the chain.
None of those powers include the ability to steal. A rollup’s safety comes from posting data and proofs to L1, where a fraud proof or validity proof constrains what state transitions can ever be finalized. Base’s outage demonstrated the boundary precisely: the sequencer produced an invalid block, and the rest of the network simply declined it. Integrity held.
The exposure is liveness and ordering, and it is not symmetric with safety. Most rollups include a forced-inclusion path on L1, letting a user submit a transaction directly to the rollup’s inbox contract and compel its inclusion after a delay. That escape hatch is real and it matters for censorship, but it is measured in hours or longer, not in the minutes a trader needs when a lending position is approaching liquidation. For a 116-minute halt, forced inclusion is a solvency backstop, not a usability one.
So the single-sequencer model is a bet with a specific shape. Users accept a liveness dependency on one operator’s software and infrastructure in exchange for confirmation latency that no L1 slot schedule can match, and the rollup accepts responsibility for keeping that operator running. Base’s postmortem is a report on the cost side of that bet. The remediations reduce the probability of a repeat without changing the payoff structure.
Based sequencing takes the opposite side. It removes the operator, accepts Ethereum’s slot cadence as the default, and then tries to buy latency back with a separate mechanism.
Collapsing the sequencer into the L1 proposer
In a based rollup, there is no elected sequencer set and no sequencer election. The right to sequence the L2 for a given interval belongs to whoever is already Ethereum’s proposer for that slot, or to a party the proposer has delegated to. The rollup stops maintaining its own liveness assumption and inherits Ethereum’s, which is the one assumption every participant in the system is already making.
The removal is genuine. There is no active/passive cluster whose failure stops block production, because the next Ethereum slot arrives with a different proposer regardless of what the previous one did. A missed slot is a missed slot, not a halt. Ethereum’s validator set is large, geographically distributed, and running multiple client implementations, so a defect in one operator’s block-building code does not propagate into a network-wide stop the way it did on Base.
Two costs come with that. The first is cadence. Absent additional machinery, a based rollup’s confirmation rhythm is Ethereum’s rhythm, roughly 12 seconds per slot with finality much later. That is the baseline Taiko was operating against before preconfirmations, and it is uncompetitive with a purpose-built sequencer tuned for latency.
The second cost is revenue, and it gets less attention. Sequencing value that a single-operator rollup captures and directs to its own treasury flows instead to Ethereum’s proposers, who have no obligation to the rollup. The sources in front of us do not quantify this transfer for any live based rollup, and it should not be asserted as a number. Structurally, though, a based rollup that gives away ordering value is choosing a different funding model, and the choice constrains what it can subsidize.
| Single operator | Based, no preconfs | Based with preconfs | |
|---|---|---|---|
| Confirmation cadence | Operator-chosen, independent of L1 slots | Tied to the L1 slot schedule | Promise latency targeted at ~100ms in the original design |
| Liveness depends on | One sequencing pipeline | Ethereum’s proposer set | Ethereum’s proposers plus the opted-in preconfer subset |
| Ordering value accrues to | Rollup operator | L1 proposers | L1 proposers, plus preconf tips |
| Characteristic failure | Full halt on an unacceptable block | Missed slot; next proposer continues | Equivocation or missed slot, both slashable |
Preconfirmations exist to fill the top-left cell of that third column. The analytical question about based rollups is whether that fill is credible.
What backs a preconfirmation promise
Justin Drake’s based preconfirmations proposal, published on ethresear.ch on November 8, 2023, is the canonical statement of the mechanism, and it names two onchain prerequisites without which the rest does not function.
The first is proposer slashing. A validator opts in, through restaking-style infrastructure, to slashing conditions that do not exist in Ethereum’s base protocol. That opt-in converts a proposer’s statement about a future block into something with a cost attached. Nothing in Ethereum consensus penalizes a proposer for saying one thing and building another, so the penalty has to be constructed on top.
The second is forced inclusion via inclusion lists. A promise to include a transaction is worth little if a subsequent proposer, or a builder serving one, can simply drop it. Inclusion-list infrastructure gives the promise a path to the chain that does not depend on the goodwill of whoever builds the next block.
A validator that opts into both slashing conditions becomes a preconfer, and gains precedence in the proposer lookahead according to its slot position. Users acquire promises from the preconfer whose turn is nearest, paying a preconf tip in exchange.
Liveness faults and safety faults are not the same instrument
The proposal separates two failure modes and prices them differently, which is the design’s most consequential detail.
A safety fault occurs when the preconfer does not miss its slot but the block it produces is inconsistent with the promise it sold. An honest preconfer running correct software never triggers this condition, so the proposal treats safety faults as fully slashable. There is no accident story that produces equivocation.
A liveness fault occurs when the preconfer’s slot is missed and the promised transaction is not otherwise included. Here accidents are real. Hardware fails, networks partition, and clients crash for reasons unrelated to intent. The proposal accordingly leaves liveness slashing amounts to mutual negotiation between the user and the preconfer, scaled to accidental-fault risk and to the size of the tip being paid.
That asymmetry has a direct consequence for what a preconfirmation is. A safety guarantee is close to categorical, since the penalty for breaking it is unbounded relative to any plausible gain from a small promise. A liveness guarantee is a priced insurance contract, and its strength varies with how much the user paid.
Ordering the transactions that did not buy a promise
Preconfed transactions are not simply included, they take execution precedence. Transactions without promises queue behind promised ones until a preconfer slot is not missed. This makes a promise about resulting state, rather than mere inclusion, achievable: the preconfer can commit to an execution outcome because it controls what executes ahead of the promised transaction.
The proposal treats promise type as open design space, listing state-root promises, state-diff promises, intent-based promises, and inclusion-only promises as distinct products with different parallelizability. Inclusion-only promises are the cheapest to make and the least useful for anything price-sensitive. State promises are the opposite. Which of these a production system sells determines whether a preconfirmation matches a centralized sequencer’s soft confirmation or only approximates it.
Bootstrapping and the lookahead
The mechanism has a participation floor. If no validator in the visible lookahead has opted in as a preconfer, there is nobody to buy a promise from and the rollup falls back to L1 cadence. The proposal offers a worked example: at roughly 20% validator opt-in, the probability of at least one preconfer appearing in a 32-slot lookahead is approximately 99.92%. That is a probability calculation, not an adoption measurement, and no figure in our sources describes actual preconfer opt-in on Ethereum mainnet today.
Design targets include point-to-point promise acquisition on the order of 100 milliseconds, distinct from block inclusion latency, and a liveness fallback in which a user acquires parallel promises from several preconfers in the lookahead rather than relying on one. Several sub-mechanisms remain explicitly unresolved in the source proposal, including replay protection, single secret leader election for preconfer privacy, and the fair exchange problem discussed below.
Preconfirmations do not simplify the trust model. They replace a single operator with an opt-in slashing layer, a restaking dependency, an inclusion-list dependency, and a promise-acquisition network. That is more machinery, not less. The argument in its favor is that the machinery is permissionless and the operator was not.
The sidecar that makes opting in survivable
A validator that wants to sell preconfirmations has an operational problem before it has an economic one. It already runs MEV-Boost. Adding a preconf protocol means running a second piece of software that also wants to influence what the validator signs, and adding inclusion lists means a third. Each bespoke integration is a new way to miss a slot, and missing slots is exactly the fault a preconfer is now slashable for.
Commit-Boost addresses that layer. It is a modular validator sidecar that standardizes what its authors call the last mile between validators and third-party commitment protocols, letting an operator opt into multiple proposer-commitment protocols through one interface rather than one integration each. MEV-Boost, preconfirmations, and inclusion lists are named as protocols the sidecar is meant to carry. On the developer side it exposes a single validator-facing API against which commitment protocols can be built and distributed, with support for hard forks handled centrally rather than per-protocol. It has been audited by Sigma Prime, and release artifacts are signed and verifiable through Sigstore cosign.
Preconfirmation economics only close if the marginal cost of becoming a preconfer is low. A validator weighing a slashable commitment against a modest tip stream will not accept a bespoke integration and an elevated missed-slot rate on top of the slashing risk. Standardization is the lever that moves opt-in toward the participation levels the lookahead math requires.
What we cannot establish from the available sources is adoption. The Commit-Boost repository documents software, not deployment. There is no figure here for how many validators run it, which networks use it in production, or which preconfirmation protocols have shipped modules against its API. The repository excerpt does not mention Taiko, UniFi, or Spire.
That gap extends further. The UniFi and Spire stack is frequently discussed as productized preconfirmation infrastructure, and it belongs in a full account of this design space, but nothing in our source set describes what either system does, how it handles collateral, or whether it interoperates with Commit-Boost. We do not characterize it without documentation. Whether the preconfirmation ecosystem converges on one validator-facing standard or fragments into several non-interoperable stacks remains an unresolved empirical question.
Taiko Alethia Phase 1 as the production datapoint
Taiko, an EVM-equivalent ZK-rollup, has activated preconfirmations on Taiko Alethia Mainnet. Per a report on ethdaily.io, the effect is transaction confirmation roughly 20 to 30 times faster, giving approximately 2-second effective block times against a prior baseline of about 12 seconds inherited from Ethereum’s slot schedule. Preconfirmers issue economically backed commitments of inclusion in the next block and face slashing for failing to deliver.
Those figures carry an attribution caveat. They come from a secondary news aggregator, not from primary Taiko documentation or an independent benchmark, and the report does not state an activation date. Contextual placement in the source suggests mid-2025, which is approximate. No independent latency measurement, tip data, or slashing record appears anywhere in our sources.
The rollout is Phase 1, and its defining constraint is that only whitelisted partners may act as preconfirmers. Permissionless preconfirmation and block building are deferred to a Phase 2 with no published date or criteria in the material available.
Phase 1 establishes that the pipeline runs end to end in production: promises are issued, users receive confirmations decoupled from L1 slot timing, and a based rollup delivers a cadence in the same range as sequencer-operated L2s. Before this, the claim that based rollups must be slow was an open empirical question. It is now resolved for at least one implementation.
What Phase 1 does not establish is the decentralization claim that motivates based sequencing. A whitelisted preconfer set is a committee. Its failure modes resemble a small permissioned sequencer set more than Ethereum’s validator set, and a correlated fault across the whitelist has no obvious reason to behave better than Base’s cluster did. Nor does Phase 1 test adversarial preconfer behavior, slashing execution against an actual equivocation, or a tip market clearing without a coordinating party choosing the participants.
Taiko has demonstrated the latency mechanism rather than the trust-minimization property. Those are distinct claims with separate evidence requirements, and only one currently has production data.
Who pays the tip and who eats the slash
The design specifies that users pay preconf tips to preconfers in exchange for promises. In practice the identity of the payer is unresolved, and it determines whether the market has depth.
Retail users do not price 100-millisecond commitments. Whatever they pay will be embedded in a wallet or RPC provider’s fee display, meaning the entity negotiating tip levels is an intermediary buying promises in bulk. Searchers and arbitrageurs are a different class of buyer with genuine willingness to pay, because a promise about resulting state removes execution risk from a directional trade. The original proposal explicitly flags that transaction types carrying higher MEV risk, such as DEX trades, present harder tip-pricing problems. Nothing in our sources reports realized tip levels from any live deployment.
There is a structural cost on the seller’s side that the proposal identifies but does not resolve. Selling a promise early forecloses block-building optionality later. A proposer who commits at second two to a specific execution outcome has constrained what it can do at second eleven, when it knows more about the order flow available to it. For a preconfer also selling blockspace through MEV-Boost, the tip has to compensate for both slashing risk and the option value surrendered. The proposal raises the possibility of negative tips, where the promise itself is valuable enough to the preconfer that the pricing inverts. The available excerpt cuts off before that idea is developed, and we do not extrapolate it.
The fair exchange problem is an acknowledged weak joint. A preconfer can accept a tip and never deliver the promise, and the user has no atomic way to condition payment on receipt. Proposed mitigations include streaming promises publicly, so that non-delivery is observable, and routing through trusted relays that arbitrate. Neither provides a cryptographic solution covering all cases, and both reintroduce a coordinating party into an architecture designed to remove them.
Collateral allocation compounds this issue. The proposal accommodates delegated preconfing, where a validator lacking the bandwidth or compute to run the role hands it to a specialist. In that arrangement the delegated preconfer can front collateral for safety faults, while liveness faults become a shared responsibility between validator and delegate, arbitrable by a relay. The guarantee a user receives on safety is backed by the specialist’s balance sheet, not by the broad economic weight of Ethereum’s staking set. If a small number of specialists front safety collateral for a large share of preconfers, preconfirmation credibility concentrates in the manner based sequencing was meant to prevent. Our sources contain no data on how many such operators exist or how much collateral any of them has posted.
What a permissionless preconfer market would have to show
The fundamental operational question is whether users want decentralized sequencing. Nothing in the available material demonstrates end-user demand for it. The demand signal visible here is entirely supply-side: a 2023 research proposal, a standardization effort in Commit-Boost, and a rollup roadmap. Users notice a 116-minute halt. There is no evidence in our sources that they notice, or pay for, the identity of whoever sequences the chain during the other 525,000 minutes of the year, and no measurement of migration away from single-sequencer L2s following any outage.
That leaves a set of observable conditions rather than a verdict. Taiko has published no criteria for moving from a whitelisted preconfer set to a permissionless one; Phase 1’s latency result and its decentralization claim require separate evaluation. Preconfer opt-in among Ethereum validators determines whether the lookahead math holds outside a curated set; the proposal’s 20% example is a threshold nobody has reported clearing. The first production slashing of a safety fault will reveal whether the collateral backing these promises is deep enough to matter, and whose collateral it was. And whether Commit-Boost becomes the common validator-facing interface, or one of several competing stacks, decides whether a validator can sell preconfirmations at a marginal cost low enough to justify accepting a new slashing condition.
Base has not entered this debate. Its postmortem proposes fuzz testing, load testing, and better recovery, treating the sequencer architecture as sound. If the operational fixes hold and halts do not recur, the based-sequencing argument loses its most vivid piece of evidence and must win on economics instead. Those economics currently lack production data.
References
서론
Base 블록 내부에서 실패한 트랜잭션 하나가 정리되지 않은 저널 상태를 남겼다. 같은 블록의 다음 정상 트랜잭션이 그 잔여 상태를 대상으로 실행되면서 가스 요금이 잘못 부과되었고, 결과적으로 무효한 상태 전이가 발생했다. Base의 밸리데이터들은 각자 리시트 루트를 재계산했고, 서로 다른 값을 얻은 뒤 해당 블록을 거부했다. 2026년 6월 25일, 체인은 116분간 정지했다. 다음 날에는 엔진 리셋 과정에서 발생한 별개의 경쟁 조건(race condition)이 복구를 지연시켜 20분짜리 재발 정지를 일으켰다. Base 자체 포스트모템에 따르면 자금 손실은 없었고 무효한 상태가 파이널라이즈된 적도 없다. 체인은 할 수 있는 올바른 조치, 즉 멈추는 것을 택했다.
Base가 밝힌 개선책은 운영적 성격이다. 퍼즈 테스트, 부하 테스트, 그리고 base-consensus의 정상 복구 경로 마련이다. Base는 시퀀서 탈중앙화를 제안하지 않았고, 포스트모템에는 based sequencing이나 프리컨퍼메이션(preconfirmation), 혹은 다른 아키텍처적 대안이 전혀 언급되지 않는다. 이는 방어 가능한 엔지니어링적 입장이다. 이번 정지는 소프트웨어 결함에서 비롯되었고, 소프트웨어 결함은 테스트와 더 나은 복구 경로로 대응하는 것이 맞다.
이번 수정으로 바뀌지 않는 것은 결함을 체인 정지로 전환시킨 구조적 속성이다. Base는 밸리데이터가 수행하는 실행 동기화와는 별개로, 컨센서스 레이어 동기화를 수행하는 액티브/패시브 시퀀서 클러스터를 운영한다. 하나의 논리적 시퀀싱 파이프라인이 모든 블록을 생성한다. 이 파이프라인이 네트워크가 받아들이지 않을 무언가를 내놓았을 때, 그 자리를 대신할 두 번째 생산자는 없다.
2023년 말부터 구축되어 현재 부분적으로 가동 중인 대안이 있다. 시퀀싱 권한을 이더리움 자체 프로포저에게 되돌려주고, 슬래싱 가능한 약속을 통해 그런 구조에서 잃을 수밖에 없는 확정 속도를 되찾는 방식이다. Taiko Alethia는 오늘날 메인넷에서 이 메커니즘의 허가형 버전을 운영 중이다. 이 메커니즘은 실제로 배포할 만큼 잘 작동한다. 아직 가격이 매겨지지 않은 부분은 그 밑에 깔린 경제학이다. 구체적으로는 약속(promise)의 비용을 누가 지불하는지, 그 뒷받침 담보를 누가 예치하는지, 그리고 그 약속을 쥔 프로포저가 더 값나가는 블록 빌딩 옵션도 함께 쥐고 있을 때 그 약속의 가치가 얼마인지다.
시퀀서 역할이 실제로 쥐고 있는 것
롤업 시퀀서는 서로 혼동하기 쉬운 세 가지 권한을 쥐고 있다. 트랜잭션 순서를 결정하고, 지갑과 애플리케이션이 사용자 관점의 결제로 취급하는 소프트 컨펌을 발행하며 - 이는 이더리움에 무언가 도달하기 훨씬 전에 일어난다 - 그 순서 결정권에서 발생하는 우선순위 수수료와 오더링 가치를 포착한다. 대다수 대형 L2에서 이 마지막 항목은 체인 운영 자금을 대는 주된 수익원이다.
이 권한들 어디에도 탈취 능력은 포함되지 않는다. 롤업의 안전성은 L1에 데이터와 증명을 게시하는 데서 나오며, 여기서 사기 증명(fraud proof)이나 유효성 증명(validity proof)이 파이널라이즈될 수 있는 상태 전이를 제약한다. Base의 정지 사태는 이 경계를 정확히 보여줬다. 시퀀서가 무효한 블록을 만들어냈고, 나머지 네트워크는 단순히 그것을 거부했다. 무결성은 지켜졌다.
노출되는 것은 라이브니스와 오더링이며, 이는 안전성과 대칭적이지 않다. 대부분의 롤업은 L1에 강제 포함(forced-inclusion) 경로를 두어, 사용자가 롤업 인박스 컨트랙트에 직접 트랜잭션을 제출하고 일정 지연 후 포함을 강제할 수 있게 한다. 이 탈출구는 실재하며 검열 저항성 측면에서 의미가 있지만, 그 소요 시간은 수 시간 단위이지 대출 포지션이 청산에 근접할 때 트레이더에게 필요한 몇 분 단위가 아니다. 116분짜리 정지 사태 앞에서 강제 포함은 솔벤시(지급능력) 백스톱이지 사용성 백스톱은 아니다.
결국 단일 시퀀서 모델은 특정한 형태의 베팅이다. 사용자는 어떤 L1 슬롯 스케줄도 따라올 수 없는 확정 지연시간을 대가로 단일 운영자의 소프트웨어와 인프라에 대한 라이브니스 의존성을 받아들이고, 롤업은 그 운영자를 계속 가동시킬 책임을 진다. Base의 포스트모템은 이 베팅의 비용 측면에 대한 보고서다. 개선책들은 손익 구조 자체를 바꾸지 않고 재발 확률만 낮춘다.
Based sequencing은 정반대 편에 선다. 운영자를 제거하고, 이더리움의 슬롯 주기를 기본값으로 받아들인 다음, 별도의 메커니즘으로 지연시간을 되사려 한다.
시퀀서를 L1 프로포저로 흡수하기
based 롤업에는 선출된 시퀀서 집합도, 시퀀서 선출 과정도 없다. 특정 구간에 L2를 시퀀싱할 권리는 그 슬롯의 이더리움 프로포저에게, 혹은 그 프로포저가 위임한 당사자에게 있다. 롤업은 자체 라이브니스 가정을 유지하는 것을 그만두고 이더리움의 가정을 물려받는데, 이는 이미 시스템 내 모든 참여자가 전제하고 있는 가정이다.
이 제거는 실질적이다. 액티브/패시브 클러스터의 장애가 블록 생산을 멈추는 일은 없는데, 이전 프로포저가 무슨 짓을 했든 다음 이더리움 슬롯은 다른 프로포저와 함께 도착하기 때문이다. 슬롯을 놓치는 것은 그저 슬롯을 놓친 것이지 정지가 아니다. 이더리움의 밸리데이터 집합은 규모가 크고, 지리적으로 분산되어 있으며, 여러 클라이언트 구현을 동시에 돌리고 있기 때문에, 한 운영자의 블록 빌딩 코드 결함이 Base에서처럼 네트워크 전체의 정지로 번지지 않는다.
여기에는 두 가지 비용이 따른다. 첫 번째는 확정 주기다. 추가 장치가 없다면, based 롤업의 컨펌 리듬은 이더리움의 리듬을 따르게 된다. 대략 슬롯당 12초이고, 파이널리티는 훨씬 뒤에 온다. 이것이 프리컨퍼메이션 도입 전 Taiko가 갖고 있던 기준선이며, 지연시간에 맞춰 튜닝된 전용 시퀀서와는 경쟁이 안 된다.
두 번째 비용은 수익이며, 이는 덜 주목받는다. 단일 운영자 롤업이 포착해 자체 트레저리로 돌리는 시퀀싱 가치가, 대신 롤업에 아무 의무도 지지 않는 이더리움 프로포저들에게 흘러간다. 지금 참고 중인 자료들은 실제 가동 중인 어떤 based 롤업에 대해서도 이 이전 규모를 수치화하지 않으며, 숫자로 단정해서도 안 된다. 다만 구조적으로 보면, 오더링 가치를 넘겨주는 based 롤업은 다른 자금 조달 모델을 선택한 것이고, 그 선택은 무엇을 보조금으로 지원할 수 있는지를 제약한다.
| 단일 운영자 | Based, 프리컨퍼메이션 없음 | Based + 프리컨퍼메이션 | |
|---|---|---|---|
| 확정 주기 | 운영자가 결정, L1 슬롯과 무관 | L1 슬롯 스케줄에 종속 | 원 설계상 목표는 ~100ms 수준의 약속 지연시간 |
| 라이브니스 의존 대상 | 하나의 시퀀싱 파이프라인 | 이더리움 프로포저 집합 | 이더리움 프로포저 및 opt-in한 preconfer 부분집합 |
| 오더링 가치 귀속 | 롤업 운영자 | L1 프로포저 | L1 프로포저, 그리고 preconf 팁 |
| 특징적 장애 양상 | 수용 불가능한 블록에 의한 전면 정지 | 슬롯 미스, 다음 프로포저가 이어감 | 이중서명(equivocation) 또는 슬롯 미스, 둘 다 슬래싱 대상 |
프리컨퍼메이션은 이 표의 세 번째 열, 왼쪽 위 칸을 채우기 위해 존재한다. based 롤업에 대해 분석적으로 던져야 할 질문은 이 채움이 신뢰할 만한가다.
프리컨퍼메이션 약속을 뒷받침하는 것
Justin Drake가 2023년 11월 8일 ethresear.ch에 게시한 based preconfirmations 제안은 이 메커니즘을 규정하는 정본이며, 이것 없이는 나머지가 작동하지 않는 두 가지 온체인 전제조건을 명시한다.
첫 번째는 프로포저 슬래싱이다. 밸리데이터는 리스테이킹 유형의 인프라를 통해, 이더리움 기본 프로토콜에는 존재하지 않는 슬래싱 조건에 opt-in한다. 이 opt-in이 프로포저의 미래 블록에 대한 진술을 비용이 따르는 것으로 바꾼다. 이더리움 컨센서스 자체에는 프로포저가 한 가지를 말하고 다른 것을 만드는 데 대한 벌칙이 없으므로, 그 벌칙은 그 위에 별도로 구축되어야 한다.
두 번째는 inclusion list를 통한 강제 포함이다. 어떤 트랜잭션을 포함시키겠다는 약속은, 다음 프로포저나 그를 서비스하는 빌더가 단순히 그것을 빼버릴 수 있다면 별 가치가 없다. Inclusion-list 인프라는 그 약속에, 다음 블록을 누가 만들든 그 선의에 의존하지 않는 체인 도달 경로를 부여한다.
두 슬래싱 조건 모두에 opt-in한 밸리데이터는 preconfer가 되며, 프로포저 룩어헤드(lookahead) 내 슬롯 위치에 따라 우선순위를 얻는다. 사용자는 순번이 가장 가까운 preconfer로부터 약속을 사들이며, 그 대가로 preconf 팁을 지불한다.
라이브니스 위반과 안전성 위반은 다른 종류의 도구다
이 제안은 두 가지 장애 유형을 구분하고 서로 다르게 가격을 매기는데, 이것이 설계에서 가장 결정적인 대목이다.
안전성 위반은 preconfer가 슬롯을 놓치지 않고 블록을 만들었지만, 그 블록이 판매한 약속과 불일치할 때 발생한다. 올바른 소프트웨어를 정상 실행 중인 정직한 preconfer는 이 상태를 절대 유발하지 않으므로, 제안은 안전성 위반을 완전히 슬래싱 대상으로 취급한다. 이중서명을 만들어내는 사고 시나리오는 존재하지 않는다.
라이브니스 위반은 preconfer의 슬롯이 놓쳐지고 약속된 트랜잭션이 다른 방식으로도 포함되지 않을 때 발생한다. 여기서는 사고가 실제로 일어난다. 하드웨어는 고장 나고, 네트워크는 분단되고, 클라이언트는 의도와 무관한 이유로 크래시한다. 그래서 제안은 라이브니스 슬래싱 액수를 사용자와 preconfer 간 상호 협상에 맡기고, 우발적 위반 위험과 지불된 팁 규모에 비례해 조정하도록 한다.
이 비대칭성은 프리컨퍼메이션이 무엇인지에 직접적인 결과를 낳는다. 안전성 보증은 거의 절대적인데, 이를 어겼을 때의 벌칙이 작은 약속에서 얻을 법한 이득에 비해 무제한이기 때문이다. 라이브니스 보증은 가격이 매겨진 보험 계약이며, 그 강도는 사용자가 지불한 금액에 따라 달라진다.
약속을 사지 않은 트랜잭션의 순서
프리컨펌드 트랜잭션은 단순히 포함되는 것이 아니라 실행 우선권을 갖는다. 약속을 사지 않은 트랜잭션은, preconfer 슬롯이 놓쳐지지 않는 한, 약속받은 트랜잭션 뒤로 밀려서 대기한다. 이는 단순한 포함이 아니라 결과 상태에 대한 약속을 실현 가능하게 만든다. preconfer는 약속된 트랜잭션 앞에서 무엇이 실행될지를 통제하므로, 실행 결과 자체를 약속할 수 있다.
이 제안은 약속의 유형을 열린 설계 공간으로 다루며, 상태 루트(state-root) 약속, 상태 차분(state-diff) 약속, 의도 기반(intent-based) 약속, 그리고 포함 전용(inclusion-only) 약속을 병렬화 가능성이 서로 다른 별개의 상품으로 나열한다. 포함 전용 약속은 만들기 가장 쉽지만 가격에 민감한 용도에는 가장 쓸모가 없다. 상태 약속은 그 반대다. 실제 시스템이 이 중 무엇을 파는지에 따라, 프리컨퍼메이션이 중앙화된 시퀀서의 소프트 컨펌과 대등한지, 아니면 근사치에 그치는지가 갈린다.
부트스트래핑과 룩어헤드
이 메커니즘에는 참여 하한선이 있다. 보이는 룩어헤드 내에 preconfer로 opt-in한 밸리데이터가 하나도 없다면, 약속을 살 곳이 없어 롤업은 L1 주기로 되돌아간다. 제안은 예시 계산을 제시한다. 밸리데이터 opt-in 비율이 대략 20%일 때, 32슬롯 룩어헤드 내에 최소 한 명의 preconfer가 나타날 확률은 약 99.92%다. 이는 확률 계산이지 실제 채택률 측정이 아니며, 오늘날 이더리움 메인넷에서 실제 preconfer opt-in 비율을 기술한 수치는 참고 자료 어디에도 없다.
설계 목표로는 블록 포함 지연시간과는 별개로 약 100밀리초 수준의 점대점(point-to-point) 약속 획득, 그리고 하나의 preconfer에만 의존하지 않고 룩어헤드 내 여러 preconfer로부터 병렬로 약속을 획득하는 라이브니스 폴백이 있다. 원 제안에는 재생 공격 방지(replay protection), preconfer의 프라이버시를 위한 단일 비밀 리더 선출(single secret leader election), 그리고 아래에서 다룰 공정 교환(fair exchange) 문제를 포함해 몇몇 하위 메커니즘이 명시적으로 미해결 상태로 남아 있다.
프리컨퍼메이션은 신뢰 모델을 단순화하지 않는다. 단일 운영자를 opt-in 슬래싱 계층, 리스테이킹 의존성, inclusion-list 의존성, 그리고 약속 획득 네트워크로 대체한다. 장치는 줄어드는 게 아니라 늘어난다. 이를 지지하는 논리는 이 장치가 허가 없이(permissionless) 작동하는 반면, 기존 운영자는 그렇지 않았다는 것이다.
opt-in을 지속 가능하게 만드는 사이드카
프리컨퍼메이션을 팔고자 하는 밸리데이터는 경제적 문제 이전에 운영상의 문제를 안고 있다. 이미 MEV-Boost를 돌리고 있는데, 여기에 프리컨퍼메이션 프로토콜을 추가하면 밸리데이터가 서명할 내용에 영향을 주려는 소프트웨어를 하나 더 돌려야 하고, inclusion list까지 더하면 세 번째다. 각각의 맞춤형 통합은 슬롯을 놓치는 새로운 경로가 되고, 슬롯을 놓치는 것은 지금 preconfer가 슬래싱 당할 바로 그 위반이다.
Commit-Boost는 이 계층을 다룬다. 개발진이 밸리데이터와 서드파티 커밋먼트 프로토콜 사이의 “라스트 마일”이라 부르는 부분을 표준화하는 모듈형 밸리데이터 사이드카로, 운영자가 프로토콜마다 하나씩 통합하는 대신 하나의 인터페이스를 통해 여러 프로포저-커밋먼트 프로토콜에 opt-in할 수 있게 한다. MEV-Boost, 프리컨퍼메이션, inclusion list가 이 사이드카가 다루도록 의도된 프로토콜로 명시되어 있다. 개발자 측에서는 커밋먼트 프로토콜을 구축하고 배포할 수 있는 단일한 밸리데이터 대면 API를 노출하며, 프로토콜별이 아니라 중앙에서 하드포크를 처리한다. Sigma Prime의 감사를 받았고, 릴리즈 아티팩트는 Sigstore cosign을 통해 서명 및 검증 가능하다.
프리컨퍼메이션 경제학은 preconfer가 되는 한계 비용이 낮을 때만 성립한다. 슬래싱 가능한 약속과 소박한 팁 수익 흐름 사이에서 저울질하는 밸리데이터는 슬래싱 리스크 위에 맞춤형 통합과 높아진 슬롯 미스율까지 얹는 것을 받아들이지 않을 것이다. 표준화는 룩어헤드 수학이 요구하는 참여 수준으로 opt-in을 밀어붙이는 지렛대다.
참고 자료로 확인할 수 없는 것은 채택 현황이다. Commit-Boost 저장소는 소프트웨어를 문서화하지, 배포 현황을 문서화하지 않는다. 몇 명의 밸리데이터가 이를 실행 중인지, 어느 네트워크가 프로덕션에서 이를 사용하는지, 어떤 프리컨퍼메이션 프로토콜이 이 API에 맞춰 모듈을 출시했는지에 대한 수치는 여기 없다. 저장소 발췌문은 Taiko, UniFi, Spire를 언급하지 않는다.
이 간극은 더 넓다. UniFi와 Spire 스택은 상용화된 프리컨퍼메이션 인프라로 자주 논의되며, 이 설계 공간을 온전히 다루려면 마땅히 포함되어야 하지만, 참고 자료 어디에도 두 시스템이 무엇을 하는지, 담보를 어떻게 처리하는지, Commit-Boost와 상호운용하는지에 대한 설명이 없다. 우리는 문서화되지 않은 것을 성격 규정하지 않는다. 프리컨퍼메이션 생태계가 하나의 밸리데이터 대면 표준으로 수렴할지, 아니면 상호운용되지 않는 여러 스택으로 파편화될지는 여전히 실증적으로 미해결된 질문이다.
프로덕션 데이터포인트로서의 Taiko Alethia Phase 1
EVM 동등성 ZK-롤업인 Taiko는 Taiko Alethia 메인넷에서 프리컨퍼메이션을 활성화했다. ethdaily.io의 한 보도에 따르면, 그 효과는 트랜잭션 확정이 대략 20~30배 빨라져, 이더리움 슬롯 스케줄에서 물려받은 기존 기준선 약 12초 대비 약 2초의 실질 블록 타임을 만들어낸다. Preconfirmer들은 다음 블록 포함에 대한 경제적으로 뒷받침된 약속을 발행하고, 이를 이행하지 못하면 슬래싱에 직면한다.
이 수치들에는 출처상 유보 조건이 붙는다. 이는 Taiko 공식 문서나 독립적 벤치마크가 아니라 2차 뉴스 취합 매체에서 나온 것이며, 해당 보도는 활성화 일자를 명시하지 않는다. 자료 내 문맥상 배치로 미루어 2025년 중반쯤으로 추정되나 이는 근사치다. 독립적인 지연시간 측정, 팁 데이터, 슬래싱 기록은 참고 자료 어디에도 없다.
이번 롤아웃은 Phase 1이며, 그 핵심 제약은 화이트리스트에 등록된 파트너만이 preconfirmer 역할을 할 수 있다는 점이다. 허가 없는 프리컨퍼메이션과 블록 빌딩은 Phase 2로 미뤄져 있으며, 현재 확보된 자료에는 공개된 날짜나 기준이 없다.
Phase 1은 이 파이프라인이 엔드투엔드로 프로덕션에서 작동함을 입증한다. 약속이 발행되고, 사용자는 L1 슬롯 타이밍과 분리된 확정을 받으며, based 롤업이 시퀀서 운영형 L2와 같은 범위의 확정 주기를 낸다. 이전까지는 based 롤업이 필연적으로 느릴 수밖에 없다는 주장이 열린 실증적 질문이었다. 이제 적어도 하나의 구현에 대해서는 해소되었다.
Phase 1이 입증하지 못하는 것은 based sequencing을 정당화하는 탈중앙화 주장이다. 화이트리스트에 등록된 preconfer 집합은 위원회다. 그 장애 양상은 이더리움 밸리데이터 집합보다는 소규모 허가형 시퀀서 집합에 가깝고, 화이트리스트 전반에 걸친 상관된 장애가 Base의 클러스터보다 낫게 작동할 명백한 이유는 없다. Phase 1은 적대적 preconfer 행동이나, 실제 이중서명에 대한 슬래싱 집행이나, 참가자를 선정하는 조율 주체 없이 청산되는 팁 시장을 시험하지도 않는다.
Taiko가 입증한 것은 지연시간 메커니즘이지 신뢰 최소화 속성이 아니다. 이 둘은 별개의 주장이고 각각 다른 근거가 필요하며, 현재로선 한쪽만 프로덕션 데이터를 갖고 있다.
누가 팁을 내고 누가 슬래싱을 떠안는가
이 설계는 사용자가 약속의 대가로 preconfer에게 preconf 팁을 지불한다고 규정한다. 실제로는 지불자의 정체가 미해결이며, 이것이 시장에 깊이가 있는지 여부를 좌우한다.
일반 사용자는 100밀리초짜리 약속에 가격을 매기지 않는다. 그들이 무엇을 내든 그것은 지갑이나 RPC 프로바이더의 수수료 표시에 흡수될 것이고, 결국 팁 수준을 협상하는 주체는 약속을 대량으로 사들이는 중개자다. 서쳐(searcher)와 재정거래자는 진짜 지불 의사를 가진 다른 유형의 구매자인데, 결과 상태에 대한 약속이 방향성 트레이드의 실행 리스크를 제거해주기 때문이다. 원 제안은 DEX 거래처럼 MEV 리스크가 큰 트랜잭션 유형이 더 어려운 팁 가격 결정 문제를 안고 있다고 명시적으로 지적한다. 실제 가동 중인 배포에서 실현된 팁 수준을 보고하는 자료는 참고 자료 어디에도 없다.
판매자 측에는 이 제안이 짚어내지만 해결하지는 않는 구조적 비용이 있다. 약속을 일찍 판다는 것은 이후의 블록 빌딩 옵션을 포기한다는 뜻이다. 2초 시점에 특정 실행 결과에 커밋한 프로포저는, 자신이 가진 오더 플로우에 대해 더 많이 알게 되는 11초 시점에 할 수 있는 것을 스스로 제약한 셈이다. MEV-Boost를 통해서도 블록스페이스를 팔고 있는 preconfer에게는, 팁이 슬래싱 리스크와 포기한 옵션 가치 둘 다를 보상해야 한다. 이 제안은 마이너스 팁의 가능성도 제기하는데, 약속 자체가 preconfer에게 워낙 값진 나머지 가격 부호가 뒤집히는 경우다. 이용 가능한 발췌문은 이 아이디어가 전개되기 전에 끊겨 있으며, 우리는 이를 함부로 확장하지 않는다.
공정 교환 문제는 인정된 약점이다. preconfer는 팁을 받고도 약속을 이행하지 않을 수 있고, 사용자에게는 지불을 수령 여부에 원자적으로 결부시킬 방법이 없다. 제안된 완화책으로는 약속을 공개적으로 스트리밍해 미이행을 관찰 가능하게 하는 방법, 그리고 중재하는 신뢰받는 릴레이를 경유하는 방법이 있다. 둘 다 모든 경우를 포괄하는 암호학적 해법을 제공하지 못하며, 둘 다 제거하려던 조율 주체를 다시 아키텍처 안으로 들여온다.
담보 배분은 이 문제를 복잡하게 만든다. 이 제안은 위임형 preconfing을 수용하는데, 이는 역할을 수행할 대역폭이나 연산력이 부족한 밸리데이터가 그 역할을 전문 업체에 넘기는 방식이다. 이 구조에서 위임받은 preconfer는 안전성 위반에 대한 담보를 선지급할 수 있고, 라이브니스 위반은 밸리데이터와 위임 대상 간의 공동 책임이 되어 릴레이가 중재한다. 사용자가 받는 안전성 보증은 이더리움 스테이킹 집합 전체의 광범위한 경제적 무게가 아니라, 그 전문 업체의 대차대조표로 뒷받침된다. 소수의 전문 업체가 다수 preconfer의 안전성 담보를 선지급한다면, 프리컨퍼메이션의 신뢰성은 based sequencing이 애초에 막으려던 방식으로 집중된다. 참고 자료에는 이런 운영 업체가 몇 곳이나 있는지, 그중 누가 얼마의 담보를 예치했는지에 대한 데이터가 없다.
허가 없는 preconfer 시장이 보여줘야 할 것
근본적인 운영상 질문은 사용자가 탈중앙화된 시퀀싱을 원하는가다. 확보된 자료 어디에도 최종 사용자의 이에 대한 수요를 입증하는 내용은 없다. 여기서 확인되는 수요 신호는 전적으로 공급 측면이다. 2023년 연구 제안, Commit-Boost라는 표준화 노력, 그리고 하나의 롤업 로드맵이다. 사용자는 116분짜리 정지를 알아챈다. 나머지 1년 525,000분 동안 누가 체인을 시퀀싱하는지 그 정체를 사용자가 알아채거나 그 대가를 지불한다는 증거는 참고 자료 어디에도 없고, 어떤 정지 사태 이후 단일 시퀀서 L2에서 이탈이 있었는지에 대한 측정치도 없다.
남는 것은 판결이 아니라 관찰 가능한 조건들의 목록이다. Taiko는 화이트리스트 preconfer 집합에서 허가 없는 집합으로 옮겨가기 위한 기준을 발표한 바 없다. Phase 1의 지연시간 결과와 탈중앙화 주장은 별개로 평가해야 한다. 이더리움 밸리데이터 사이의 preconfer opt-in 비율은 룩어헤드 수학이 큐레이션된 집합 밖에서도 성립하는지를 결정하는데, 제안서의 20% 예시는 아직 누구도 넘어섰다고 보고한 적 없는 문턱이다. 안전성 위반에 대한 최초의 프로덕션 슬래싱은 이런 약속들을 뒷받침하는 담보가 의미 있을 만큼 두터운지, 그리고 그것이 누구의 담보였는지를 드러낼 것이다. 그리고 Commit-Boost가 공통의 밸리데이터 대면 인터페이스가 될지, 아니면 경쟁하는 여러 스택 중 하나에 그칠지가, 밸리데이터가 새로운 슬래싱 조건을 받아들일 만큼 낮은 한계 비용으로 프리컨퍼메이션을 팔 수 있는지를 결정한다.
Base는 이 논쟁에 뛰어들지 않았다. 그 포스트모템은 퍼즈 테스트, 부하 테스트, 더 나은 복구를 제안하며 시퀀서 아키텍처 자체는 건전하다고 취급한다. 이 운영상 수정이 유지되고 정지가 재발하지 않는다면, based sequencing 논거는 가장 강력한 증거 하나를 잃고 경제학만으로 승부해야 한다. 그리고 그 경제학은 현재 프로덕션 데이터가 부족하다.
참고 자료
はじめに
Base上のブロック内で失敗したトランザクションが、汚れたジャーナル状態を後に残した。同じブロック内の次の正常なトランザクションはその残留状態に対して実行され、不整合なガス量を課金され、無効な状態遷移を生んだ。Baseのバリデータは独自にレシートルートを再計算し、異なる結果を得て、そのブロックを拒否した。2026年6月25日、チェーンは116分間停止した。エンジンリセット内の別の無関係な競合状態が復旧を遅らせ、翌日には20分間の再停止も発生した。Base自身のポストモーテムによれば、資金の損失はなく、無効な状態が確定することもなかった。チェーンは取れる中で正しい行動、つまり停止を選んだ。
Baseが示した改善策は運用面のものだ。fuzzテスト、負荷テスト、base-consensus内での適切な復旧処理。Baseはシーケンサーの分散化を提案しておらず、ポストモーテムでもbased sequencing、プレコンファメーション、その他のアーキテクチャ上の代替案には触れていない。これは擁護できる工学的立場だ。停止の原因はソフトウェアの欠陥であり、ソフトウェアの欠陥はテストとより良い復旧経路で対処するものだからだ。
この修正で変わらないのは、欠陥をチェーン停止に転化させた構造的な性質だ。Baseはコンセンサス層の同期を行うactive/passiveのシーケンサークラスタを運用しており、これはバリデータが行う実行層の同期とは別物だ。1つの論理的なシーケンシングパイプラインが全ブロックを生成する。そのパイプラインがネットワークに拒否される何かを出力したとき、そのスロットを代わりに担う第2の生産者は存在しない。
2023年後半から構築が進み、現在部分的に稼働している代替案がある。シーケンシングの権利をEthereum自身のプロポーザーに戻し、スラッシング可能な約束を使って、その配置によって失われるはずの確認速度を取り戻すというものだ。Taiko Alethiaは現在メインネット上でこの仕組みのパーミッションド版を運用している。このメカニズムは出荷できる水準まで機能している。まだ価格付けされていないのはその根底にある経済性、具体的には誰が約束の対価を払うのか、誰がその裏付けとなる担保を差し出すのか、そしてプロポーザーがブロックビルディングの選択権(それが約束以上の価値を持つ場合)を同時に握っているとき、その約束はいくらの価値を持つのか、という点だ。
シーケンサーの役割が実際に握っているもの
ロールアップのシーケンサーは、混同しやすい3つの異なる権力を握っている。トランザクションの順序を決める権力。ウォレットやアプリケーションがユーザー向けの決済として扱うソフトコンファメーションを発行する権力(これはEthereumに何かが届くよりずっと前の話だ)。そして、その順序決定権から生じる優先手数料と順序価値を獲得する権力で、大半の大規模L2にとってこれはチェーンを支える主要な収益源になっている。
これらの権力に窃取の能力は含まれない。ロールアップの安全性は、データとプルーフをL1に投稿することから生まれ、そこでは不正証明または妥当性証明が、確定できる状態遷移を制約する。Baseの障害はその境界線を正確に示した。シーケンサーは無効なブロックを生成し、ネットワークの残りはそれを単に拒否した。整合性は保たれた。
露出しているのはライブネスと順序決定であり、これは安全性とは対称ではない。大半のロールアップはL1上にforced-inclusionの経路を持ち、ユーザーがロールアップのインボックスコントラクトに直接トランザクションを提出し、一定の遅延後にその取り込みを強制できる。この逃げ道は実在し、検閲対策として意味を持つが、その時間単位は時間かそれ以上であり、レンディングポジションが清算に近づいているときにトレーダーが必要とする分単位ではない。116分の停止に対して、forced inclusionはソルベンシーのバックストップにはなるが、ユーザビリティのバックストップにはならない。
つまり、単一シーケンサーモデルは特定の形をした賭けだ。ユーザーは、L1のスロットスケジュールにはとても追いつけない確認レイテンシと引き換えに、単一の運営者のソフトウェアとインフラへのライブネス依存を受け入れ、ロールアップ側はその運営者を稼働させ続ける責任を負う。Baseのポストモーテムはその賭けのコスト側についての報告書だ。改善策は再発の確率を下げるが、ペイオフの構造自体は変えない。
Based sequencingはその逆側に立つ。運営者を取り除き、Ethereumのスロットの周期をデフォルトとして受け入れ、そのうえで別のメカニズムでレイテンシを買い戻そうとする。
シーケンサーをL1プロポーザーに縮退させる
based rollupには選出されたシーケンサーセットも、シーケンサー選挙も存在しない。ある区間についてL2をシーケンスする権利は、その時点でEthereumのプロポーザーとなっている者、あるいはそのプロポーザーが委任した相手に属する。ロールアップは自前のライブネス前提を維持することをやめ、Ethereumの前提を継承する。これはシステム内の全参加者がすでに置いている前提そのものだ。
この除去は本物だ。active/passiveのクラスタでその失敗がブロック生成を止める、といった構造は存在しない。次のEthereumのスロットには前のプロポーザーが何をしたかにかかわらず別のプロポーザーが来るからだ。スロットの欠落はスロットの欠落であって、停止ではない。Ethereumのバリデータセットは規模が大きく、地理的に分散し、複数のクライアント実装で動いているため、1つの運営者のブロックビルディングコードの欠陥が、Baseで起きたようなネットワーク全体の停止に伝播することはない。
これには2つのコストが伴う。1つはケイデンスだ。追加の機構なしでは、based rollupの確認のリズムはEthereumのリズムになり、おおよそ12秒/スロットで、ファイナリティはさらに後になる。これはTaikoがプレコンファメーション導入前に運用していたベースラインであり、レイテンシに特化して調整された専用シーケンサーと比べると競争力を持たない。
2つ目のコストは収益で、あまり注目されない。単一運営者のロールアップが獲得して自らのトレジャリーに向けるシーケンシング価値は、代わりにEthereumのプロポーザーに流れる。彼らはそのロールアップに対して何の義務も負っていない。手元の資料は、実際に稼働しているどのbased rollupについても、この移転の規模を数値化していない。数字として主張すべきではない。ただ構造的には、順序決定価値を手放すbased rollupは異なる資金モデルを選んでいるのであり、その選択が何を補助できるかを制約する。
| 単一運営者 | based(preconfなし) | based(preconfあり) | |
|---|---|---|---|
| 確認のケイデンス | 運営者が選択、L1スロットから独立 | L1のスロットスケジュールに紐づく | 元の設計では約100msを目標とする約束のレイテンシ |
| ライブネスの依存先 | 単一のシーケンシングパイプライン | Ethereumのプロポーザーセット | Ethereumのプロポーザーとopt-inしたpreconfer部分集合 |
| 順序決定価値の帰属先 | ロールアップ運営者 | L1プロポーザー | L1プロポーザー、加えてpreconfのチップ |
| 典型的な障害モード | 受理不可能なブロックによる完全停止 | スロットの欠落。次のプロポーザーが続行 | 二重投票またはスロット欠落、いずれもスラッシング対象 |
プレコンファメーションは、その3列目の左上のセルを埋めるために存在する。based rollupに関する分析上の問いは、その埋め方が信頼できるかどうかだ。
プレコンファメーションの約束を裏付けるもの
2023年11月8日にethresear.chに公開されたJustin Drakeのbased preconfirmationsの提案は、このメカニズムの規範的な記述であり、これがなければ残りの仕組みが機能しないオンチェーンの前提条件を2つ挙げている。
1つはプロポーザーのスラッシングだ。バリデータは、リステーキング的なインフラを通じて、Ethereumの基本プロトコルには存在しないスラッシング条件にopt-inする。このopt-inによって、プロポーザーが未来のブロックについて述べる言明が、コストを伴うものに変わる。Ethereumのコンセンサスには、プロポーザーが一つのことを言って別のものを構築したことを罰する仕組みは何もないため、その罰則は上に積み重ねて構築するしかない。
2つ目はinclusion listによるforced inclusionだ。トランザクションを取り込むという約束は、後続のプロポーザー、あるいはそのプロポーザーに仕えるビルダーが単純にそれを落としてしまえるなら、大した価値を持たない。inclusion-listのインフラは、次のブロックを構築する者の善意に依存しない形で、その約束にチェーンへの経路を与える。
両方のスラッシング条件にopt-inしたバリデータはpreconferとなり、プロポーザーのlookaheadにおいてスロット位置に応じた優先順位を得る。ユーザーは最も順番が近いpreconferから約束を購入し、その対価としてpreconfのチップを支払う。
ライブネス違反と安全性違反は同じ手段ではない
この提案は2つの失敗モードを分け、それぞれに異なる価格をつけている。これがこの設計の中で最も重要な細部だ。
安全性違反は、preconferがスロットを外していないにもかかわらず、生成したブロックが売った約束と食い違っている場合に発生する。正しいソフトウェアを動かしている誠実なpreconferがこの状態を引き起こすことは決してないため、提案は安全性違反を完全にスラッシング対象として扱う。二重投票を生む「事故」というストーリーは存在しない。
ライブネス違反は、preconferのスロットが欠落し、約束されたトランザクションが他の手段でも取り込まれない場合に発生する。ここでは事故が現実に起こり得る。ハードウェアは故障し、ネットワークは分断し、クライアントは意図とは無関係な理由でクラッシュする。それに応じて、提案はライブネス違反のスラッシング額をユーザーとpreconferの間の相互交渉に委ねており、偶発的な違反リスクと支払われるチップの規模に応じて調整される。
この非対称性はプレコンファメーションとは何かに直接的な帰結をもたらす。安全性の保証はほぼ絶対的なものに近い。それを破った場合の罰則は、小さな約束から得られるであろうもっともらしい利益に対して無制限だからだ。ライブネスの保証は価格付けされた保険契約であり、その強度はユーザーがいくら支払ったかによって変わる。
約束を買っていないトランザクションの順序付け
Preconfされたトランザクションは単に取り込まれるだけではなく、実行の優先順位を得る。約束を持たないトランザクションは、preconferのスロットが欠落しない限り、約束されたトランザクションの後ろに並ぶ。これにより、単なる取り込みではなく、結果として生じる状態についての約束が実現可能になる。preconferは約束されたトランザクションより前に何が実行されるかを制御しているため、実行結果そのものにコミットできる。
この提案は約束のタイプを開かれた設計空間として扱い、state-root約束、state-diff約束、意図ベースの約束、取り込みのみの約束を、並列化可能性の異なる別個の商品として列挙している。取り込みのみの約束は作るのが最も安く、価格に敏感な用途では最も使い道が少ない。state約束はその逆だ。プロダクションシステムがこのうちどれを販売するかによって、プレコンファメーションが集中化されたシーケンサーのソフトコンファメーションに一致するのか、それを近似するだけなのかが決まる。
ブートストラップとlookahead
このメカニズムには参加の下限がある。可視のlookahead内にpreconferとしてopt-inしているバリデータが一人もいなければ、約束を買う相手がいないため、ロールアップはL1のケイデンスにフォールバックする。提案には具体例がある。バリデータのopt-in率が約20%の場合、32スロットのlookahead内に少なくとも1人のpreconferが現れる確率は約99.92%になる。これは確率計算であり、実際の採用状況を測定したものではない。Ethereumメインネット上での実際のpreconferのopt-in状況を示す数字は、我々の資料内には存在しない。
設計目標には、ブロックの取り込みレイテンシとは別に、約束の取得を約100ミリ秒台で行うというピア間の目標が含まれ、またユーザーが1人に依存する代わりにlookahead内の複数のpreconferから並行して約束を取得するというライブネスのフォールバックも含まれている。リプレイ保護、preconferの秘匿性のためのsingle secret leader election、後述するfair exchange問題を含む複数のサブメカニズムは、元の提案の中で明確に未解決のまま残されている。
プレコンファメーションは信頼モデルを単純化しない。単一の運営者を、opt-inのスラッシング層、リステーキング依存、inclusion-list依存、約束取得ネットワークに置き換えているだけだ。それはより多くの機構であり、より少ない機構ではない。それを支持する論拠は、その機構がパーミッションレスであり、運営者はそうではなかったという点にある。
opt-inを生存可能にするサイドカー
プレコンファメーションを販売したいバリデータには、経済的な問題の前に運用上の問題がある。すでにMEV-Boostを動かしている。preconfプロトコルを追加するということは、バリデータが署名する内容に影響を与えたい2つ目のソフトウェアを動かすことを意味し、inclusion listを追加すればそれは3つ目になる。個別対応の統合はそれぞれがスロットを外す新たな経路であり、スロットを外すことこそまさにpreconferがスラッシング対象となる違反そのものだ。
Commit-Boost はこの層に対処する。これはモジュール式のバリデータサイドカーで、開発者たちがバリデータとサードパーティのcommitmentプロトコルとの間の「最後のマイル」と呼ぶものを標準化し、運営者が個別統合を1つずつ行うのではなく、単一のインターフェースを通じて複数のproposer-commitmentプロトコルにopt-inできるようにする。MEV-Boost、プレコンファメーション、inclusion listは、このサイドカーが運ぶことを意図したプロトコルとして名前が挙がっている。開発者側には、commitmentプロトコルを構築・配布するための単一のバリデータ向けAPIが公開されており、ハードフォークへの対応もプロトコルごとではなく中央で処理される。Sigma Primeによる監査済みで、リリースアーティファクトはSigstore cosignを通じて署名・検証可能だ。
プレコンファメーションの経済性は、preconferになるための追加コストが低い場合にのみ成立する。スラッシング可能なコミットメントと控えめなチップの流れとを比較検討するバリデータは、スラッシングリスクに加えて個別統合とスロット欠落率の上昇まで受け入れることはしない。標準化は、opt-in率をlookaheadの数式が要求する参加水準へと動かすレバーだ。
手元の資料から確定できないのは採用状況だ。Commit-Boostのリポジトリはソフトウェアを文書化しているが、デプロイメントは記録していない。何人のバリデータがこれを動かしているのか、どのネットワークが本番でこれを使っているのか、どのプレコンファメーションプロトコルがそのAPIに対応するモジュールを出荷しているのか、その数字はここにはない。リポジトリの抜粋にはTaiko、UniFi、Spireへの言及はない。
そのギャップはさらに広がる。UniFi と Spire のスタックは、製品化されたプレコンファメーション基盤としてよく議論され、この設計空間の全体像を語るなら含めるべきものだが、我々の資料一式には、どちらのシステムが何をするのか、担保をどう扱うのか、Commit-Boostと相互運用するのかについての記述は何もない。文書がない以上、それについて特徴づけることはしない。プレコンファメーションのエコシステムが単一のバリデータ向け標準に収束するのか、相互運用しない複数のスタックに分裂するのかは、未解決の実証的な問いのまま残っている。
本番データ点としてのTaiko Alethia Phase 1
EVM等価なZKロールアップであるTaikoは、Taiko Alethia Mainnet上でプレコンファメーションを有効化している。ethdaily.ioのレポートによれば、その効果はトランザクション確認が約20〜30倍速くなることであり、Ethereumのスロットスケジュールから継承した約12秒という以前のベースラインに対して、実質的なブロックタイムは約2秒になる。Preconfirmerは次のブロックへの取り込みについて経済的に裏付けられたコミットメントを発行し、それを実行できなかった場合はスラッシングを受ける。
これらの数値には帰属に関する留保が付く。これらは一次的なTaikoの文書や独立したベンチマークではなく、二次的なニュースアグリゲーターからのものであり、レポートには有効化日が記されていない。資料内の文脈的な位置づけからは2025年中頃と推測されるが、これはあくまで推定だ。独立したレイテンシ計測、チップのデータ、スラッシング記録は、我々の資料のどこにも見当たらない。
このロールアウトはPhase 1であり、その決定的な制約は、ホワイトリストに登録されたパートナーのみがpreconfirmerとして行動できるという点だ。パーミッションレスなプレコンファメーションとブロックビルディングは、公開された日付や基準のないPhase 2に持ち越されている。
Phase 1は、このパイプラインが本番環境でエンドツーエンドに動くことを証明している。約束が発行され、ユーザーはL1のスロットのタイミングから切り離された確認を受け取り、based rollupがシーケンサー運用型L2と同程度のケイデンスを実現する。これ以前は、「based rollupは必然的に遅くなる」という主張は未解決の実証問題だった。少なくとも1つの実装についてはこれで解決した。
Phase 1が証明していないのは、based sequencingを動機づける分散化という主張だ。ホワイトリスト化されたpreconferのセットは委員会にすぎない。その障害モードは、Ethereumのバリデータセットよりも小規模なパーミッションドのシーケンサーセットに似ており、ホワイトリスト内で相関する障害が、Baseのクラスタで起きたことより良く振る舞う明確な理由はない。Phase 1は、敵対的なpreconferの振る舞い、実際の二重投票に対するスラッシングの執行、参加者を選ぶ調整役なしに成立するチップ市場のクリアリングもテストしていない。
Taikoが示したのはレイテンシのメカニズムであり、トラストミニマイゼーションの性質ではない。これらは別の主張であり、それぞれ別の証拠を必要とする。現時点で本番データがあるのはそのうち一方だけだ。
誰がチップを払い、誰がスラッシュを被るのか
この設計は、ユーザーが約束の対価としてpreconferにpreconfのチップを支払うと定めている。実際には、その支払者の正体は未確定であり、それが市場の深さを決める。
リテールユーザーは100ミリ秒単位のコミットメントに価格をつけない。彼らが払うものは何であれ、ウォレットやRPCプロバイダーの手数料表示に埋め込まれることになる。つまりチップの水準を交渉する主体は、約束をまとめて購入する仲介者だ。サーチャーやアービトラージャーは意味のある支払意欲を持つ別種の買い手であり、結果として生じる状態についての約束が、方向性のあるトレードから実行リスクを取り除いてくれるからだ。元の提案は、DEXトレードのようにMEVリスクの高いトランザクションタイプの方が、チップの価格付けがより難しい問題になると明示的に指摘している。実際の稼働環境で実現したチップの水準を報告しているものは、我々の資料には何もない。
提案が指摘しながら解決していない、販売側の構造的なコストがある。約束を早期に売ることは、後になってからのブロックビルディングの選択権を封じてしまう。2秒目に特定の実行結果にコミットしたプロポーザーは、11秒目に、自分に利用可能なオーダーフローについてより多くを知った時点でできることを、すでに制約されている。MEV-Boostを通じてブロックスペースも売っているpreconferにとって、チップはスラッシングリスクと放棄したオプション価値の両方を補う必要がある。この提案は、約束そのものがpreconferにとって十分価値があり、価格付けが逆転する「負のチップ」の可能性を提起している。手元の抜粋はこのアイデアが展開される前で切れており、我々はそれを外挿しない。
fair exchange問題は、認識されている弱い接合点だ。preconferはチップを受け取りながら約束を一度も果たさないことができ、ユーザーには支払いを受領に条件付けるアトミックな手段がない。提案されている緩和策には、約束を公開してストリーミングし未履行を観測可能にすることや、仲裁を行う信頼されたリレーを経由させることが含まれる。いずれも全ケースを網羅する暗号学的解決策ではなく、両方とも、それらを取り除くために設計されたアーキテクチャに調整役を再導入してしまう。
担保の配分がこの問題をさらに複雑にする。この提案は、帯域や計算力が不足しているバリデータがその役割を専門業者に委ねる、delegated preconfingを想定している。この配置では、委任先のpreconferが安全性違反に対する担保を前払いし、ライブネス違反はバリデータと委任先の間の共同責任となり、リレーによって仲裁可能になる。ユーザーが安全性について受け取る保証は、その専門業者のバランスシートに裏付けられており、Ethereumのステーキングセット全体の広範な経済的重みに裏付けられているわけではない。少数の専門業者が大部分のpreconferの安全性担保を前払いしているなら、プレコンファメーションの信頼性は、based sequencingが防ぐはずだったまさにそのやり方で集中してしまう。我々の資料には、こうした運営者が何社存在するのか、それぞれがどれだけの担保を差し出しているのかについてのデータはない。
パーミッションレスなpreconfer市場が示すべきもの
根本的な運用上の問いは、ユーザーが分散化されたシーケンシングを望んでいるかどうかだ。手元の資料には、それに対するエンドユーザーの需要を示すものは何もない。ここで見える需要の兆候は完全に供給側のものだ。2023年の研究提案、Commit-Boostにおける標準化の取り組み、そしてロールアップのロードマップ。ユーザーは116分間の停止には気づく。チェーンをシーケンスしているのが誰かということに、年の残り525,000分の間、ユーザーが気づいている、あるいはその対価を払っているという証拠は、我々の資料には存在せず、いずれかの障害の後に単一シーケンサーのL2から離脱する動きを測定したものもない。
これは結論というより、観測可能な条件の集合として残る。Taikoは、ホワイトリスト化されたpreconferセットからパーミッションレスなセットへ移行するための基準を何も公開していない。Phase 1のレイテンシの結果と分散化の主張は、別個に評価する必要がある。Ethereumバリデータのpreconferへのopt-in率は、lookaheadの数式が精選されたセットの外でも成り立つかどうかを決める。提案が示した20%という例は、誰もクリアを報告していない閾値だ。安全性違反に対する最初の本番スラッシングは、これらの約束を裏付ける担保が意味を持つほど厚いかどうか、そしてそれが誰の担保だったのかを明らかにする。そして、Commit-Boostが共通のバリデータ向けインターフェースになるのか、それとも複数の競合スタックの1つになるのかが、バリデータが新たなスラッシング条件を受け入れるに値する低い追加コストでプレコンファメーションを販売できるかどうかを決める。
Baseはこの議論に加わっていない。そのポストモーテムはfuzzテスト、負荷テスト、より良い復旧を提案しており、シーケンサーのアーキテクチャそのものは健全だとみなしている。運用上の修正が持続し、停止が再発しないなら、based sequencingの主張はその最も鮮明な証拠を失い、代わりに経済性で勝負しなければならなくなる。その経済性には現時点で本番データが不足している。
参考文献
引言
Base 某个区块内的一笔失败交易留下了脏的 journal 状态。同一区块中下一笔有效交易在这个残留状态上执行,被收取了不匹配的 gas 费用,产生了一次无效的状态转换。Base 的验证者各自独立重新计算 receipts root,得到了不同的结果,于是拒绝了该区块。2026 年 6 月 25 日,链停摆了 116 分钟。第二天,engine reset 中一个不相关的竞态条件又拖慢了恢复过程,导致又一次 20 分钟的停摆。根据 Base 自己的事后报告,没有资金损失,也没有任何无效状态被最终确认。链做了它能做的正确的事——停下来。
Base 提出的补救措施是运营层面的:模糊测试、负载测试,以及 base-consensus 中的优雅恢复机制。Base 并未提议将其排序器去中心化,事后报告中也没有提到 based sequencing、预确认或任何架构层面的替代方案。这是一个说得过去的工程立场。故障源于软件缺陷,而软件缺陷该用测试和更好的恢复路径来解决。
这次修复没有改变的,是把一个缺陷变成整条链停摆的那个结构性特性。Base 运行的是一个主备排序器集群,执行的是共识层同步,这与其验证者执行的执行层同步是两件事。一个逻辑排序管道产生每一个区块。当这个管道产出网络不会接受的东西时,没有第二个生产者能接手这个区块位置。
自 2023 年末以来,一种替代方案一直在建设中,现在已经部分上线:把排序权还给以太坊自己的提议者,并用可罚没的承诺来弥补这种安排本会牺牲的确认速度。Taiko Alethia 如今在主网上运行着这一机制的许可制版本。这套机制的可用性足以支撑上线运行。尚未定价的是其背后的经济学——具体来说,是谁为一个承诺付费,谁为其背后的抵押品买单,以及当持有承诺的提议者同时也握有价值更高的区块构建选择权时,这个承诺究竟值多少。
排序器角色究竟握有什么权力
Rollup 排序器握有三种容易被混为一谈的不同权力。它决定交易排序。它发出软确认,钱包和应用会把这当作面向用户的结算依据,远早于任何东西到达以太坊之前。它还捕获由排序权产生的优先费和排序价值,对大多数大型 L2 而言,这是为链提供资金的主要收入来源。
这些权力都不包括窃取资金的能力。Rollup 的安全性来自向 L1 提交数据和证明,欺诈证明或有效性证明约束了最终能被确认的状态转换。Base 的宕机事件精确地展示了这条边界:排序器产出了一个无效区块,网络的其余部分只是拒绝了它。完整性没有被破坏。
暴露的是活性和排序,而这与安全性不是对称的。大多数 rollup 在 L1 上都有强制包含路径,允许用户直接向 rollup 的 inbox 合约提交交易,并在延迟一段时间后强制其被包含。这个应急出口是真实存在的,对反审查也很重要,但它以小时甚至更长时间计,而不是交易者在借贷仓位快被清算时所需要的那几分钟。对于一次 116 分钟的停摆,强制包含是资金安全的后备手段,不是可用性的后备手段。
所以单一排序器模型是一种特定形态的赌注。用户接受对单一运营者软件和基础设施的活性依赖,以换取任何 L1 slot 时间表都无法匹配的确认延迟,而 rollup 则承担着让这个运营者持续运转的责任。Base 的事后报告是关于这场赌注成本一侧的报告。补救措施降低了重演的概率,但没有改变收益结构。
Based sequencing 走的是相反的路线。它移除了运营者,把以太坊的 slot 节奏当作默认值接受下来,然后试图用另一套机制把延迟买回来。
把排序器塌缩进 L1 提议者
在一个 based rollup 中,不存在被选出的排序器集合,也不存在排序器选举。在某个时间段内排序 L2 的权利,归属于当时恰好是以太坊该 slot 提议者的那一方,或者归属于该提议者委托的一方。Rollup 不再维持自己的活性假设,而是继承以太坊的假设——这恰恰是系统中每个参与者本就已经在做的假设。
这种移除是真实的。不存在一个失效就会导致区块生产停止的主备集群,因为下一个以太坊 slot 会到来,而提议者与上一个不同,无论上一个做了什么。错过一个 slot 就是错过一个 slot,不是停摆。以太坊的验证者集合规模庞大、地理分布广泛,并运行多个客户端实现,所以某个运营者构建区块代码中的缺陷,不会像在 Base 上那样传播成全网停摆。
这带来两个代价。第一个是节奏。如果没有额外的机制,based rollup 的确认节奏就是以太坊的节奏,大约每个 slot 12 秒,最终性还要晚得多。这就是 Taiko 在引入预确认之前所面对的基线,与专门为低延迟调校的排序器相比毫无竞争力。
第二个代价是收入,而这一点受到的关注更少。单一运营者 rollup 捕获并导向自己金库的排序价值,转而流向了以太坊的提议者,而这些提议者对该 rollup 没有任何义务。我们手头的资料没有为任何现存的 based rollup 量化这种转移,不应把它说成一个具体数字。但从结构上讲,一个把排序价值让出去的 based rollup,选择的是一种不同的资金模型,而这个选择限制了它能补贴什么。
| 单一运营者 | Based,无预确认 | Based 带预确认 | |
|---|---|---|---|
| 确认节奏 | 由运营者自行选择,独立于 L1 slot | 绑定 L1 slot 时间表 | 原始设计中承诺延迟目标约为 ~100ms |
| 活性依赖于 | 单一排序管道 | 以太坊的提议者集合 | 以太坊提议者加上参与的预确认者子集 |
| 排序价值归属于 | Rollup 运营者 | L1 提议者 | L1 提议者,外加预确认小费 |
| 典型故障模式 | 因不可接受区块而完全停摆 | 错过某个 slot;下一个提议者继续 | 双重承诺或错过 slot,两者均可罚没 |
预确认的存在,就是为了填补上表第三列左上方那个格子。关于 based rollup 的分析性问题在于,这种填补是否可信。
什么在为预确认承诺背书
Justin Drake 于 2023 年 11 月 8 日发布在 ethresear.ch 上的 based preconfirmations 提案,是这一机制的经典阐述,并明确指出了两个链上前提条件,少了它们其余部分都无法运作。
第一个是提议者罚没。验证者通过类似再质押的基础设施,自愿接受一些以太坊基础协议中本不存在的罚没条件。这种自愿加入,把提议者关于未来区块的一句声明,转变成了带有代价的东西。以太坊共识本身不会因为提议者说一件事、做另一件事而对其施加惩罚,所以这种惩罚必须在协议之上另外构建。
第二个是通过 inclusion list 实现的强制包含。如果后续的提议者,或为其服务的构建者,能够轻易丢弃某笔交易,那么关于包含这笔交易的承诺就没有多大价值。Inclusion-list 基础设施为这个承诺提供了一条通往链上的路径,这条路径不依赖于下一个区块构建者的善意。
同时接受这两种罚没条件的验证者成为预确认者(preconfer),并根据其 slot 位置在提议者 lookahead 中获得优先权。用户从轮次最近的预确认者那里获取承诺,支付预确认小费作为交换。
活性故障和安全故障不是同一种工具
该提案区分了两种失败模式,并对它们做了不同的定价,这是设计中最具决定性的细节。
安全故障发生在预确认者没有错过自己的 slot,但产出的区块与它出售的承诺不一致的情况下。一个运行正确软件的诚实预确认者永远不会触发这种情况,所以该提案将安全故障视为完全可罚没的。不存在能产生双重承诺的意外情形。
活性故障发生在预确认者错过了自己的 slot,而承诺的交易未能通过其他方式被包含的情况下。这里的意外是真实的。硬件会故障,网络会分区,客户端会因为与意图无关的原因崩溃。因此,该提案将活性罚没的金额留给用户与预确认者之间协商,依据意外故障的风险以及所支付小费的大小来调整。
这种不对称对预确认到底是什么有直接影响。安全保证近乎是绝对的,因为违反它的惩罚相对于任何来自小额承诺的合理收益而言都是无上限的。活性保证则是一份定价的保险合约,其强度随用户支付的金额而变化。
排序那些没有购买承诺的交易
预确认的交易不仅仅是被包含,它们还获得执行优先权。没有承诺的交易会排在有承诺的交易之后,直到某个预确认者的 slot 没有被错过。这使得关于结果状态的承诺(而不仅仅是包含承诺)成为可能:预确认者可以承诺一个执行结果,因为它控制着在承诺交易之前执行的内容。
该提案将承诺类型视为开放的设计空间,列出了 state-root 承诺、state-diff 承诺、基于意图的承诺以及仅包含承诺,作为具有不同可并行性的独立产品。仅包含承诺制作成本最低,但对任何价格敏感的场景用处最小。状态承诺则恰恰相反。生产系统出售哪一种,决定了预确认能否匹配中心化排序器的软确认,还只是近似于它。
冷启动与 lookahead
这套机制存在一个参与度门槛。如果可见 lookahead 范围内没有验证者选择加入成为预确认者,那就没有承诺可买,rollup 会退回到 L1 节奏。该提案给出了一个算例:在大约 20% 的验证者参与率下,32 个 slot 的 lookahead 中至少出现一个预确认者的概率约为 99.92%。这是一个概率计算,不是一个采用率测量,我们的资料中没有任何数字描述以太坊主网上当前实际的预确认者参与情况。
设计目标包括点对点承诺获取延迟在约 100 毫秒量级,这与区块包含延迟不同,以及一种活性后备机制,即用户从 lookahead 中的多个预确认者那里并行获取承诺,而不是依赖单一一方。原始提案中明确留有若干未解决的子机制,包括重放保护、用于预确认者隐私的单秘密领导者选举,以及下文讨论的公平交换问题。
预确认并未简化信任模型。它们用一个自愿加入的罚没层、一个再质押依赖、一个 inclusion-list 依赖以及一个承诺获取网络,取代了单一运营者。这是更多的机制,不是更少。支持它的论点在于,这套机制是无需许可的,而那个运营者不是。
让加入变得可持续的边车程序
想要出售预确认的验证者,在面对经济问题之前先要面对一个运营问题。它已经在运行 MEV-Boost。再加一套预确认协议意味着要运行第二个也想影响验证者签名内容的软件,再加 inclusion list 就是第三个。每一个定制集成都是一种新的错过 slot 的方式,而错过 slot 恰恰是预确认者现在会因此被罚没的过错。
Commit-Boost 就是解决这一层问题的。它是一个模块化的验证者边车程序,标准化了其作者所称的验证者与第三方承诺协议之间的“最后一英里”,让运营者通过一个统一接口就能加入多个提议者承诺协议,而不必为每个协议单独做一次集成。MEV-Boost、预确认和 inclusion list 都被列为这个边车程序旨在承载的协议。在开发者一侧,它暴露出一个单一的面向验证者的 API,承诺协议可以基于此构建和分发,硬分叉的支持由中心统一处理,而不是逐协议处理。它已经过 Sigma Prime 的审计,发布产物经过签名,可通过 Sigstore cosign 验证。
预确认经济学只有在成为预确认者的边际成本足够低时才能成立。一个权衡可罚没承诺与不算丰厚的小费收入的验证者,不会愿意在承担罚没风险之外,还接受一次定制集成和更高的错过 slot 率。标准化是把参与率推向 lookahead 数学所要求水平的杠杆。
我们从现有资料中无法确认的是采用情况。Commit-Boost 的代码库记录的是软件,不是部署情况。这里没有数字说明有多少验证者在运行它,哪些网络在生产环境中使用它,或哪些预确认协议已经针对其 API 上线了模块。代码库摘要中没有提到 Taiko、UniFi 或 Spire。
这个空白还在延伸。UniFi 和 Spire 这套组合经常被讨论为已产品化的预确认基础设施,理应出现在这个设计空间的完整叙述中,但我们的资料集里没有任何内容描述这两个系统各自做什么,如何处理抵押品,或是否与 Commit-Boost 互通。没有文档支撑,我们不对其做出定性描述。预确认生态最终会收敛到一个统一的面向验证者的标准,还是分裂成若干互不兼容的技术栈,仍是一个未解的实证问题。
Taiko Alethia 第一阶段作为生产环境的数据点
Taiko 是一个 EVM 等效的零知识 Rollup,已在 Taiko Alethia 主网上激活了预确认功能。根据 ethdaily.io 上的一篇报道,其效果是交易确认速度提升约 20 到 30 倍,相比继承自以太坊 slot 时间表的约 12 秒基线,实现了大约 2 秒的有效区块时间。预确认者(preconfirmer)发出经济上有担保的下一区块包含承诺,如果未能履约则面临罚没。
这些数字需要一个来源说明。它们来自一个二级新闻聚合站点,而不是 Taiko 的一手文档或独立基准测试,该报道也没有说明激活日期。资料中的上下文线索暗示是 2025 年年中,这只是大致推断。我们的资料中没有任何地方出现独立的延迟测量、小费数据或罚没记录。
这次上线是第一阶段,其决定性约束是只有白名单合作方才能充当预确认者。无许可的预确认和区块构建被推迟到第二阶段,现有资料中没有公布日期或标准。
第一阶段证明了这条管道能够在生产环境中端到端运行:承诺被发出,用户收到与 L1 slot 时序脱钩的确认,一个 based rollup 交付出与由排序器运营的 L2 相当的节奏。在此之前,“based rollup 必然缓慢”这一说法还是一个开放的实证问题。现在至少对一个实现而言,这个问题已经有了答案。
第一阶段没有证明的,是驱动 based sequencing 的那个去中心化主张。一个白名单预确认者集合就是一个委员会。它的故障模式更像是一个小型许可制排序器集合,而不像以太坊的验证者集合,白名单内的相关性故障没有明显的理由会比 Base 的集群表现得更好。第一阶段也没有测试对抗性的预确认者行为、针对实际双重承诺的罚没执行,或没有协调方挑选参与者的小费市场出清情况。
Taiko 展示的是延迟机制,而不是最小化信任的特性。这是两个需要不同证据支撑的独立主张,目前只有一个有生产环境数据。
谁付小费,谁承担罚没
该设计规定用户向预确认者支付预确认小费以换取承诺。实际上,付费方的身份尚未确定,而这决定了这个市场是否有深度。
散户不会为 100 毫秒的承诺定价。他们支付的任何费用都会被嵌入钱包或 RPC 提供商的费用展示中,这意味着真正协商小费水平的实体是一个批量购买承诺的中介方。搜索者(searcher)和套利者是另一类买家,他们有真实的支付意愿,因为一个关于结果状态的承诺能从一笔方向性交易中消除执行风险。原始提案明确指出,携带更高 MEV 风险的交易类型,比如 DEX 交易,带来了更难定价小费的问题。我们的资料中没有任何一个现存部署报告了实际的小费水平。
在卖方一侧存在一种结构性成本,该提案指出了它,但没有解决它。提早出售一个承诺,会关闭之后的区块构建选择权。一个在第二秒就承诺特定执行结果的提议者,限制了自己在第十一秒能做的事——那时它已经知道更多关于自己可用订单流的信息。对于同时通过 MEV-Boost 出售区块空间的预确认者而言,小费必须同时补偿罚没风险和放弃的期权价值。该提案提出了负小费的可能性,即承诺本身对预确认者的价值足够高,使定价发生反转。我们看到的资料片段在这个想法展开之前就中断了,我们不做延伸推断。
公平交换问题是一个被公认的薄弱环节。预确认者可以接受小费而从不交付承诺,用户没有原子化的方式将付款与交付绑定。已提出的缓解方案包括公开流式发布承诺,使未履约行为可被观察到,以及通过可信中继方进行仲裁路由。这两种方案都不能提供覆盖所有情形的密码学解决方案,而且都把一个协调方重新引入了本意是要消除协调方的架构中。
抵押品分配加剧了这个问题。该提案容纳了委托预确认(delegated preconfing),即缺乏带宽或算力来承担这个角色的验证者,将其委托给专业机构。在这种安排下,受托的预确认者可以为安全故障垫付抵押品,而活性故障则成为验证者与受托方之间的共同责任,可由中继方仲裁。用户在安全性上得到的保证,由这个专业机构的资产负债表背书,而不是由以太坊质押集合广泛的经济权重背书。如果少数几家专业机构为大量预确认者垫付安全抵押品,预确认的可信度就会以 based sequencing 本应防止的方式集中起来。我们的资料中没有数据说明存在多少这样的运营方,或它们各自垫付了多少抵押品。
无许可预确认者市场需要展示什么
根本性的运营问题在于,用户是否想要去中心化的排序。现有资料中没有任何内容证明终端用户有这种需求。这里可见的需求信号完全来自供给侧:一份 2023 年的研究提案、Commit-Boost 的标准化努力,以及一个 rollup 路线图。用户会注意到一次 116 分钟的停摆。我们的资料中没有证据表明,他们会注意到,或愿意为,在一年剩下的 525,000 分钟里究竟是谁在排序这条链而付费,也没有任何关于用户在某次宕机后迁离单一排序器 L2 的迁移数据。
留给我们的是一组可观察的条件,而不是一个结论。Taiko 没有公布从白名单预确认者集合转向无许可集合的标准;第一阶段的延迟结果和它的去中心化主张需要分开评估。以太坊验证者中预确认者的参与率,决定了 lookahead 数学在精选集合之外是否依然成立;该提案给出的 20% 算例是一个尚无人报告已经达到的门槛。第一次生产环境中针对安全故障的罚没,将揭示这些承诺背后的抵押品是否深厚到足以真正起作用,以及那是谁的抵押品。而 Commit-Boost 能否成为通用的面向验证者接口,还是会沦为若干竞争技术栈中的一个,将决定验证者能否以足够低的边际成本出售预确认,从而值得接受一项新的罚没条件。
Base 没有参与这场辩论。它的事后报告提出了模糊测试、负载测试和更好的恢复机制,把排序器架构本身当作是没有问题的。如果这些运营层面的修复能够站得住,停摆不再重演,那么 based sequencing 的论点就失去了它最有力的一份证据,只能转而靠经济学来取胜。而目前这些经济学还缺乏生产环境的数据。
参考资料
Introducción
Una transacción fallida dentro de un bloque de Base dejó tras de sí un estado de journal sucio. La siguiente transacción válida en ese mismo bloque se ejecutó contra ese residuo y se le cobró una cantidad de gas incorrecta, produciendo una transición de estado inválida. Los validadores de Base recalcularon la receipts root de forma independiente, obtuvieron una respuesta distinta y rechazaron el bloque. El 25 de junio de 2026, la cadena se detuvo durante 116 minutos. Una segunda race condition, no relacionada, en el reinicio del motor ralentizó la recuperación y produjo una repetición del corte al día siguiente, de 20 minutos. Según el propio postmortem de Base, no se perdieron fondos y nada inválido llegó a finalizarse. La cadena hizo lo único correcto que tenía disponible, que fue detenerse.
Las medidas correctivas que anuncia Base son operacionales: fuzz testing, pruebas de carga y recuperación controlada en base-consensus. Base no propone descentralizar su sequencer, y el postmortem no menciona based sequencing, preconfirmaciones ni ninguna alternativa arquitectónica. Es una postura de ingeniería defendible. El corte se originó en un defecto de software, y los defectos de software se resuelven con pruebas y mejores rutas de recuperación.
Lo que la corrección no cambia es la propiedad estructural que convirtió un defecto en una interrupción de la cadena. Base opera un clúster de sequencer activo/pasivo que realiza sincronización a nivel de consenso, distinta de la sincronización de ejecución que hacen sus validadores. Un único pipeline de secuenciación lógico produce cada bloque. Cuando ese pipeline emite algo que la red no acepta, no hay un segundo productor que ocupe el turno.
Desde finales de 2023 se viene construyendo una alternativa, y hoy está parcialmente en producción: devolverle el derecho de secuenciación a los propios proponentes de Ethereum, y usar promesas sujetas a slashing para recuperar la velocidad de confirmación que ese arreglo perdería de otro modo. Taiko Alethia ejecuta hoy en mainnet una versión permisionada de esto. El mecanismo funciona lo suficientemente bien como para lanzarse. Lo que queda sin tasar es la economía subyacente, en concreto quién paga por una promesa, quién aporta el colateral que la respalda y cuánto vale una promesa cuando el proponente que la sostiene también tiene la opcionalidad de construir el bloque, que vale más.
Qué contiene realmente el rol de sequencer
Un sequencer de rollup concentra tres poderes distintos que se confunden con facilidad. Decide el orden de las transacciones. Emite la confirmación blanda (“soft confirmation”) que wallets y aplicaciones tratan como liquidación de cara al usuario, mucho antes de que nada llegue a Ethereum. Y captura las priority fees y el valor de ordenamiento que genera ese derecho de ordenar, que para la mayoría de las L2 grandes es la principal línea de ingresos que financia la cadena.
Ninguno de esos poderes incluye la capacidad de robar. La seguridad de un rollup viene de publicar datos y pruebas en L1, donde una fraud proof o una validity proof restringe qué transiciones de estado pueden llegar a finalizarse. La interrupción de Base demostró ese límite con precisión: el sequencer produjo un bloque inválido, y el resto de la red simplemente lo rechazó. La integridad se mantuvo.
La exposición está en la disponibilidad (“liveness”) y en el ordenamiento, y no es simétrica con la seguridad. La mayoría de los rollups incluyen una vía de inclusión forzada en L1, que permite a un usuario enviar una transacción directamente al contrato de inbox del rollup y forzar su inclusión tras un retraso. Esa vía de escape es real e importa para la censura, pero se mide en horas o más, no en los minutos que necesita un trader cuando una posición de préstamo está a punto de liquidarse. Para un corte de 116 minutos, la inclusión forzada es un respaldo de solvencia, no de usabilidad.
Así que el modelo de sequencer único es una apuesta con una forma específica. Los usuarios aceptan una dependencia de disponibilidad respecto del software y la infraestructura de un solo operador, a cambio de una latencia de confirmación que ningún calendario de slots de L1 puede igualar, y el rollup asume la responsabilidad de mantener a ese operador funcionando. El postmortem de Base es un informe sobre el lado del costo de esa apuesta. Las correcciones reducen la probabilidad de que se repita sin cambiar la estructura del pago.
El based sequencing toma el lado opuesto. Elimina al operador, acepta la cadencia de slots de Ethereum como línea base, y luego intenta recomprar la latencia con un mecanismo separado.
Colapsar el sequencer dentro del proponente de L1
En un rollup based no existe un conjunto elegido de sequencers ni una elección de sequencer. El derecho de secuenciar la L2 en un intervalo dado pertenece a quien ya sea el proponente de Ethereum en ese slot, o a la parte a la que ese proponente haya delegado. El rollup deja de mantener su propio supuesto de disponibilidad y hereda el de Ethereum, que es el mismo supuesto que ya hace todo participante del sistema.
La eliminación es real. No hay un clúster activo/pasivo cuya falla detenga la producción de bloques, porque el siguiente slot de Ethereum llega con un proponente distinto sin importar qué haya hecho el anterior. Un slot perdido es un slot perdido, no un corte. El conjunto de validadores de Ethereum es grande, está distribuido geográficamente y corre múltiples implementaciones de cliente, así que un defecto en el código de construcción de bloques de un operador no se propaga hasta detener la red entera, como sí ocurrió en Base.
A eso le acompañan dos costos. El primero es la cadencia. Sin maquinaria adicional, el ritmo de confirmación de un rollup based es el ritmo de Ethereum, unos 12 segundos por slot, con la finalidad llegando mucho más tarde. Esa era la línea base contra la que operaba Taiko antes de las preconfirmaciones, y no es competitiva frente a un sequencer diseñado a medida y afinado para latencia.
El segundo costo es de ingresos, y recibe menos atención. El valor de secuenciación que un rollup de operador único captura y dirige a su propia tesorería fluye en cambio hacia los proponentes de Ethereum, que no tienen obligación alguna con el rollup. Las fuentes que tenemos no cuantifican esta transferencia para ningún rollup based en producción, y no debería afirmarse una cifra. Estructuralmente, sin embargo, un rollup based que cede el valor de ordenamiento está eligiendo un modelo de financiamiento distinto, y esa elección limita qué puede subsidiar.
| Operador único | Based, sin preconfs | Based con preconfs | |
|---|---|---|---|
| Cadencia de confirmación | Elegida por el operador, independiente de los slots de L1 | Atada al calendario de slots de L1 | Latencia de promesa apuntando a ~100ms en el diseño original |
| La disponibilidad depende de | Un solo pipeline de secuenciación | El conjunto de proponentes de Ethereum | Los proponentes de Ethereum más el subconjunto de preconfirmadores que optó por participar |
| El valor de ordenamiento se acumula en | El operador del rollup | Los proponentes de L1 | Los proponentes de L1, más las propinas de preconf |
| Falla característica | Corte total ante un bloque inaceptable | Slot perdido; el siguiente proponente continúa | Equivocación o slot perdido, ambos sujetos a slashing |
Las preconfirmaciones existen para llenar la celda superior izquierda de esa tercera columna. La pregunta analítica sobre los rollups based es si ese llenado es creíble.
Qué respalda una promesa de preconfirmación
La propuesta de preconfirmaciones based de Justin Drake, publicada en ethresear.ch el 8 de noviembre de 2023, es la formulación canónica del mecanismo, y nombra dos requisitos onchain sin los cuales el resto no funciona.
El primero es el slashing de proponentes. Un validador opta, a través de infraestructura de tipo restaking, por condiciones de slashing que no existen en el protocolo base de Ethereum. Esa opción convierte la declaración de un proponente sobre un bloque futuro en algo con un costo asociado. Nada en el consenso de Ethereum penaliza a un proponente por decir una cosa y construir otra, así que la penalización tiene que construirse por encima.
El segundo es la inclusión forzada mediante inclusion lists. Una promesa de incluir una transacción vale poco si un proponente posterior, o un builder que lo sirve, puede simplemente descartarla. La infraestructura de inclusion lists le da a la promesa una vía hacia la cadena que no depende de la buena voluntad de quien construya el siguiente bloque.
Un validador que opta por ambas condiciones de slashing se convierte en preconfirmador, y gana precedencia en el lookahead de proponentes según su posición de slot. Los usuarios adquieren promesas del preconfirmador cuyo turno esté más cerca, pagando una propina de preconf a cambio.
Las fallas de disponibilidad y las fallas de seguridad no son el mismo instrumento
La propuesta separa dos modos de falla y los tasa de manera distinta, y ese es el detalle más determinante del diseño.
Una falla de seguridad ocurre cuando el preconfirmador no pierde su slot, pero el bloque que produce es inconsistente con la promesa que vendió. Un preconfirmador honesto que corre software correcto nunca dispara esta condición, así que la propuesta trata las fallas de seguridad como enteramente sujetas a slashing. No hay ningún escenario accidental que produzca equivocación.
Una falla de disponibilidad ocurre cuando se pierde el slot del preconfirmador y la transacción prometida no se incluye por otra vía. Aquí los accidentes son reales. El hardware falla, las redes se particionan y los clientes se caen por razones ajenas a la intención. La propuesta, en consecuencia, deja los montos de slashing por disponibilidad a la negociación mutua entre el usuario y el preconfirmador, escalados según el riesgo de falla accidental y el tamaño de la propina pagada.
Esa asimetría tiene una consecuencia directa sobre qué es una preconfirmación. Una garantía de seguridad es casi categórica, porque la penalización por romperla es desproporcionada frente a cualquier ganancia plausible de una promesa pequeña. Una garantía de disponibilidad es un contrato de seguro tasado, y su fuerza varía según cuánto pagó el usuario.
Ordenar las transacciones que no compraron una promesa
Las transacciones preconfirmadas no simplemente se incluyen, toman precedencia de ejecución. Las transacciones sin promesa quedan en cola detrás de las prometidas hasta que un slot de preconfirmador no se pierde. Esto hace posible una promesa sobre el estado resultante, y no solo sobre la mera inclusión: el preconfirmador puede comprometerse a un resultado de ejecución porque controla qué se ejecuta antes de la transacción prometida.
La propuesta trata el tipo de promesa como espacio de diseño abierto, listando promesas de state-root, promesas de state-diff, promesas basadas en intents y promesas de inclusión únicamente, como productos distintos con distinta paralelizabilidad. Las promesas de solo inclusión son las más baratas de hacer y las menos útiles para cualquier cosa sensible al precio. Las promesas de estado son lo opuesto. Cuál de estas venda un sistema en producción determina si una preconfirmación equivale a la confirmación blanda de un sequencer centralizado o solo la aproxima.
Arranque y lookahead
El mecanismo tiene un piso de participación. Si ningún validador en el lookahead visible ha optado por ser preconfirmador, no hay a quién comprarle una promesa y el rollup cae de vuelta a la cadencia de L1. La propuesta ofrece un ejemplo trabajado: con aproximadamente 20% de validadores que optan por participar, la probabilidad de que aparezca al menos un preconfirmador en un lookahead de 32 slots es de aproximadamente 99,92%. Eso es un cálculo de probabilidad, no una medición de adopción, y ninguna cifra en nuestras fuentes describe la participación real de preconfirmadores en la mainnet de Ethereum hoy.
Los objetivos de diseño incluyen la adquisición de promesas punto a punto en el orden de 100 milisegundos, distinta de la latencia de inclusión en bloque, y un respaldo de disponibilidad en el que un usuario adquiere promesas paralelas de varios preconfirmadores en el lookahead en lugar de depender de uno solo. Varios submecanismos siguen explícitamente sin resolver en la propuesta original, incluyendo la protección contra replay, la elección de líder de secreto único para privacidad del preconfirmador, y el problema de intercambio justo que se discute más abajo.
Las preconfirmaciones no simplifican el modelo de confianza. Sustituyen a un operador único por una capa de slashing opcional, una dependencia de restaking, una dependencia de inclusion lists y una red de adquisición de promesas. Eso es más maquinaria, no menos. El argumento a su favor es que esa maquinaria es permisionless y el operador no lo era.
El sidecar que hace sobrevivible el opt-in
Un validador que quiere vender preconfirmaciones tiene un problema operacional antes de tener uno económico. Ya corre MEV-Boost. Añadir un protocolo de preconf implica correr una segunda pieza de software que también quiere influir en lo que el validador firma, y añadir inclusion lists implica una tercera. Cada integración a medida es una nueva forma de perder un slot, y perder slots es exactamente la falla por la que un preconfirmador ahora está sujeto a slashing.
Commit-Boost aborda esa capa. Es un sidecar de validador modular que estandariza lo que sus autores llaman la última milla entre validadores y protocolos de compromiso de terceros, permitiendo que un operador opte por múltiples protocolos de compromiso de proponente a través de una sola interfaz, en lugar de una integración por cada uno. MEV-Boost, las preconfirmaciones y las inclusion lists se nombran como protocolos que el sidecar está pensado para transportar. En el lado del desarrollador expone una única API orientada al validador contra la cual pueden construirse y distribuirse protocolos de compromiso, con soporte para hard forks manejado de forma centralizada en lugar de protocolo por protocolo. Ha sido auditado por Sigma Prime, y los artefactos de release están firmados y son verificables mediante Sigstore cosign.
La economía de las preconfirmaciones solo cierra si el costo marginal de convertirse en preconfirmador es bajo. Un validador que pesa un compromiso sujeto a slashing contra un flujo modesto de propinas no va a aceptar una integración a medida y una tasa elevada de slots perdidos, además del riesgo de slashing. La estandarización es la palanca que empuja el opt-in hacia los niveles de participación que exige la matemática del lookahead.
Lo que no podemos establecer con las fuentes disponibles es la adopción. El repositorio de Commit-Boost documenta software, no despliegue. No hay aquí ninguna cifra sobre cuántos validadores lo corren, qué redes lo usan en producción, o qué protocolos de preconfirmación han lanzado módulos contra su API. El extracto del repositorio no menciona a Taiko, UniFi ni Spire.
Esa brecha se extiende más. El stack de UniFi y Spire se discute con frecuencia como infraestructura de preconfirmación productizada, y pertenece a un relato completo de este espacio de diseño, pero nada en nuestro conjunto de fuentes describe qué hace cada sistema, cómo maneja el colateral, o si interopera con Commit-Boost. No lo caracterizamos sin documentación. Si el ecosistema de preconfirmaciones converge en un único estándar orientado al validador o se fragmenta en varios stacks no interoperables sigue siendo una pregunta empírica sin resolver.
Taiko Alethia Fase 1 como el dato de producción
Taiko, un ZK-rollup equivalente a EVM, ha activado las preconfirmaciones en Taiko Alethia Mainnet. Según un reporte de ethdaily.io, el efecto es una confirmación de transacciones entre 20 y 30 veces más rápida, dando tiempos de bloque efectivos de aproximadamente 2 segundos frente a una línea base previa de unos 12 segundos heredada del calendario de slots de Ethereum. Los preconfirmadores emiten compromisos de inclusión respaldados económicamente para el siguiente bloque y enfrentan slashing si no cumplen.
Esas cifras llevan una salvedad de atribución. Provienen de un agregador de noticias secundario, no de la documentación primaria de Taiko ni de un benchmark independiente, y el reporte no indica una fecha de activación. La ubicación contextual en la fuente sugiere mediados de 2025, lo cual es aproximado. No aparece en ninguna de nuestras fuentes una medición independiente de latencia, datos de propinas, ni un registro de slashing.
El lanzamiento es la Fase 1, y su restricción definitoria es que solo socios en whitelist pueden actuar como preconfirmadores. La preconfirmación y la construcción de bloques permisionless quedan diferidas a una Fase 2 sin fecha publicada ni criterios en el material disponible.
La Fase 1 establece que el pipeline funciona de punta a punta en producción: se emiten promesas, los usuarios reciben confirmaciones desacopladas del tiempo de los slots de L1, y un rollup based entrega una cadencia en el mismo rango que las L2 operadas por sequencer. Antes de esto, la afirmación de que los rollups based deben ser lentos era una pregunta empírica abierta. Ahora está resuelta, al menos para una implementación.
Lo que la Fase 1 no establece es la afirmación de descentralización que motiva el based sequencing. Un conjunto de preconfirmadores en whitelist es un comité. Sus modos de falla se parecen más a un conjunto pequeño de sequencers permisionados que al conjunto de validadores de Ethereum, y una falla correlacionada en la whitelist no tiene razón obvia para comportarse mejor de lo que lo hizo el clúster de Base. Tampoco la Fase 1 pone a prueba el comportamiento adversarial de un preconfirmador, la ejecución de slashing contra una equivocación real, ni un mercado de propinas que se despeje sin una parte coordinadora eligiendo a los participantes.
Taiko ha demostrado el mecanismo de latencia, no la propiedad de minimización de confianza. Son afirmaciones distintas con requisitos de evidencia separados, y por ahora solo una tiene datos de producción.
Quién paga la propina y quién carga con el slashing
El diseño especifica que los usuarios pagan propinas de preconf a los preconfirmadores a cambio de promesas. En la práctica, la identidad del pagador está sin resolver, y de eso depende si el mercado tiene profundidad.
Los usuarios retail no tasan compromisos de 100 milisegundos. Lo que paguen quedará embebido en la visualización de comisiones de una wallet o un proveedor de RPC, lo que significa que la entidad que negocia los niveles de propina es un intermediario que compra promesas al por mayor. Los searchers y arbitrajistas son una clase distinta de comprador con voluntad de pago genuina, porque una promesa sobre el estado resultante elimina el riesgo de ejecución de un trade direccional. La propuesta original señala explícitamente que los tipos de transacción con mayor riesgo de MEV, como los trades en DEX, presentan problemas de fijación de precio de la propina más difíciles. Nada en nuestras fuentes reporta niveles de propina realizados en ningún despliegue en producción.
Hay un costo estructural en el lado del vendedor que la propuesta identifica pero no resuelve. Vender una promesa temprano cierra la opcionalidad de construcción de bloque más adelante. Un proponente que se compromete en el segundo dos a un resultado de ejecución específico ha limitado lo que puede hacer en el segundo once, cuando sabe más sobre el flujo de órdenes disponible. Para un preconfirmador que también vende blockspace a través de MEV-Boost, la propina tiene que compensar tanto el riesgo de slashing como el valor de la opción cedida. La propuesta plantea la posibilidad de propinas negativas, donde la promesa misma es lo bastante valiosa para el preconfirmador como para que el precio se invierta. El extracto disponible se corta antes de que esa idea se desarrolle, y no la extrapolamos.
El problema de intercambio justo es un punto débil reconocido. Un preconfirmador puede aceptar una propina y nunca entregar la promesa, y el usuario no tiene forma atómica de condicionar el pago a la recepción. Las mitigaciones propuestas incluyen transmitir las promesas públicamente, de modo que la falta de entrega sea observable, y enrutar a través de relays de confianza que arbitren. Ninguna de las dos ofrece una solución criptográfica que cubra todos los casos, y ambas reintroducen una parte coordinadora en una arquitectura diseñada para eliminarlas.
La asignación de colateral agrava este problema. La propuesta admite la preconfirmación delegada, en la que un validador que carece del ancho de banda o del cómputo para cumplir el rol se lo entrega a un especialista. En ese arreglo, el preconfirmador delegado puede adelantar colateral para las fallas de seguridad, mientras que las fallas de disponibilidad se convierten en una responsabilidad compartida entre validador y delegado, arbitrable por un relay. La garantía de seguridad que recibe un usuario está respaldada por el balance del especialista, no por el peso económico amplio del conjunto de staking de Ethereum. Si un número reducido de especialistas adelanta el colateral de seguridad para una gran proporción de preconfirmadores, la credibilidad de la preconfirmación se concentra de la manera exacta que el based sequencing pretendía evitar. Nuestras fuentes no contienen datos sobre cuántos operadores de este tipo existen ni cuánto colateral ha depositado cada uno.
Qué tendría que demostrar un mercado de preconfirmadores permisionless
La pregunta operacional de fondo es si los usuarios quieren secuenciación descentralizada. Nada en el material disponible demuestra demanda de los usuarios finales por ella. La señal de demanda visible aquí es enteramente del lado de la oferta: una propuesta de investigación de 2023, un esfuerzo de estandarización en Commit-Boost, y una hoja de ruta de rollup. Los usuarios notan un corte de 116 minutos. No hay evidencia en nuestras fuentes de que noten, o paguen por, la identidad de quien secuencia la cadena durante los otros 525.000 minutos del año, ni ninguna medición de migración fuera de las L2 de sequencer único tras un corte.
Eso deja un conjunto de condiciones observables en lugar de un veredicto. Taiko no ha publicado criterios para pasar de un conjunto de preconfirmadores en whitelist a uno permisionless; el resultado de latencia de la Fase 1 y su afirmación de descentralización requieren evaluaciones separadas. La participación de preconfirmadores entre los validadores de Ethereum determina si la matemática del lookahead se sostiene fuera de un conjunto curado; el ejemplo del 20% de la propuesta es un umbral que nadie ha reportado haber superado. El primer slashing en producción de una falla de seguridad revelará si el colateral que respalda estas promesas es lo bastante profundo como para importar, y de quién era ese colateral. Y si Commit-Boost se convierte en la interfaz común orientada al validador, o en uno de varios stacks en competencia, decide si un validador puede vender preconfirmaciones a un costo marginal lo bastante bajo para justificar aceptar una nueva condición de slashing.
Base no ha entrado en este debate. Su postmortem propone fuzz testing, pruebas de carga y mejor recuperación, tratando la arquitectura del sequencer como sólida. Si las correcciones operacionales se sostienen y los cortes no se repiten, el argumento a favor del based sequencing pierde su evidencia más contundente y tendrá que ganar por la vía de la economía. Esa economía carece hoy de datos de producción.
Referencias
Read next다음으로 읽기次に読む继续阅读Leer a continuación
토큰은 이제 이렇게 출시된다: Echo, Legion, MetaDAO
출시 연도 평균 -54% 수익률이 포인트 메타의 신뢰를 무너뜨렸다. 거래소 소유 레일과 퓨타키 런치패드는 유통량과 FDV가 아니라 누가 배분받는지를 바꾼다.
[BTCFi 8] Clementine: 프로덕션 환경의 BitVM
Citrea의 2026년 메인넷이 최초의 BitVM2 브릿지를 출시했다. 1-of-N 가정이 요구하는 것과 이 모델이 스트레스 상황에서 무너지는 지점.
폭풍 이후의 연관 집합: 출구가 있는 프라이버시
프라이버시 풀, Railgun, 그리고 Storm 분리 평결과 2026년 10월 재심이 온체인 프라이버시 설계에 대해 실제로 무엇을 결론짓는가.
Follow the next market structure breakdown 다음 시장 구조 분석 받기 次の市場構造分析をフォロー 关注下一篇市场结构分析 Sigue el próximo análisis de estructura de mercado
New Steadyrain research is published several times a week across DeFi risk, BTCFi, stablecoins, and RWA. Steadyrain은 DeFi 리스크, BTCFi, 스테이블코인, RWA 분석을 매주 여러 차례 발행합니다. SteadyrainはDeFiリスク、BTCFi、ステーブルコイン、RWAの分析を毎週公開しています。 Steadyrain 每周发布 DeFi 风险、BTCFi、稳定币和 RWA 研究。 Steadyrain publica análisis sobre riesgo DeFi, BTCFi, stablecoins y RWA varias veces por semana.