Workspace Index › Dev Notes › Deposit trusts a fast confirmation; exit waits on the rollup's own proof
#86PoC
Deposit trusts a fast confirmation; exit waits on the rollup's own proof
Ethlabs' 'Fast Ethereum' work makes the L1→L2 deposit fast: the Fast Confirmation Rule (FCR) lets bridges confirm an L1 transaction in 12–24 seconds — ~30× faster than finality — a weaker-but-priceable guarantee, enough to credit a deposit. But the L2→L1 exit cannot be sped the same way: an optimistic rollup is bounded by its challenge window, a zk rollup by its proving time. That asymmetry is structural, not an implementation gap — entering a rollup only needs you to trust an L1 confirmation, while leaving needs the rollup to prove its state. The lesson the app-L2s (Lighter, Derive) named as their top pain: you can accelerate the direction you can trust weakly, not the direction that must be proven.
Not a build — a two-direction latency map. For a chosen L2, measure (or model) both crossings and, more importantly, name what each waits on. Deposit (L1→L2): what does the sequencer wait for before crediting — N block confirmations, finality, or an FCR-style rule? FCR promises 12–24s by confirming an L1 tx under a rule weaker than finality; write down the exact failure it accepts (a reorg past the confirmed depth) and who eats it. Exit (L2→L1): what gates the withdrawal — an optimistic challenge window (days) or zk proving time (minutes-to-hours)? That gate is the rollup's own security mechanism; it cannot be shortcut without weakening the rollup. Then note the real-world blocker FCR hit: L2s watch L1 deposits through external RPC providers, so FCR adoption is gated on the RPC providers shipping it — a supply-chain dependency, not a protocol one. Sources: Ethlabs Week 11 (2026-09-07, via X); FCR, EIP-8198 (Quick/Fast Slots), Fast Finality. Confirm the numbers (12–24s, 30×, 12s→10s) and EIP/fork status against the post and the EIPs before citing.
Why
The two directions across a rollup boundary run on different security clocks, and that is why one accelerates and the other does not. Entering a rollup — a deposit — only requires the L2 to trust that an L1 transaction happened. Trust can be graded: instead of waiting for finality, a bridge can accept a Fast Confirmation Rule that says 'this L1 tx is confirmed to depth D under these assumptions,' get 12–24 seconds instead of ~13 minutes, and price the residual reorg risk. Leaving a rollup — a withdrawal — is the opposite: the L1 will not release funds on trust, it demands the rollup prove its state is valid. An optimistic rollup proves-by-absence-of-challenge (wait out the window); a zk rollup proves-by-proof (wait for the prover). Neither wait is a bug to optimize away; it is the rollup's security.
So 'faster interop' is really two different problems wearing one phrase. Deposit latency is a trust-calibration problem — pick a confirmation rule weaker than finality and manage the tail risk (l2-finality-three-clocks is the same insight: 'finalized' is one clock among several, and you can act on an earlier one if you price it). Exit latency is a proof-cost problem — you can shrink proving time or the challenge window, but you cannot remove the requirement that the rollup convince L1. Conflating the two is how roadmaps promise 'instant bridging' and quietly mean only the easy direction.
Two second-order lessons the Ethlabs update surfaces. First, adoption is a supply chain: FCR is blocked not by the protocol but by the RPC providers L2s depend on to watch L1 — the fast rule is useless until the boring middleware ships it (third-party-blast-radius, rpc-view-not-consensus). Second, the base-layer speedups are complementary but distinct: Fast Slots (EIP-8198) cuts block time 12s→10s (a UX lever, quick-slots-10s), and Fast Finality reworks consensus toward 1–2-slot finality (which would shrink the deposit-trust gap directly). The through-line for any 'we made bridging faster' claim: ask which crossing got faster, and whether the speedup relaxed a trust assumption (fine, if priced) or a proof requirement (much harder, and suspicious if claimed cheaply).
How it works
One boundary, two clocks
Crossing
What the receiver needs
What gates the speed
Can it be fast?
Deposit L1→L2
trust an L1 tx happened
confirmation depth vs finality
yes — FCR: 12–24s, ~30× faster than finality
Exit L2→L1
L1 must be convinced of L2 state
optimistic challenge window / zk proving time
no — it is the rollup's own security
The asymmetry is the whole card: trust can be graded and hurried; proof cannot be skipped.
Fast-Ethereum pieces, and which gap each closes
Piece
What it does
Which gap
FCR
confirm L1 tx in 12–24s under a sub-finality rule
deposit trust latency
Fast Slots (EIP-8198)
block time 12s → 10s, trending lower
base UX latency (quick-slots-10s)
Fast Finality
consensus rework → 1–2 slot finality
shrinks the deposit-trust gap at the source
The adoption supply chain
FCR's blocker is not cryptographic — L2s watch L1 deposits via external RPC providers, so the fast rule is inert until those providers ship it. A protocol win stalls on middleware (rpc-view-not-consensus, third-party-blast-radius).
Also in the same update (folds into existing cards)
8130 ↔ 8141 AA collab — unifying Base's EIP-8130 with Frames (EIP-8141) by making validation swappable: extend 7702-style delegation / mandated proxy bytecode / re-interpreted frames so an L2 can replace EVM validation with equivalent native code. This is an update to erc-8141.
Cross-refs: l2-finality-three-clocks (finality is several clocks; act on the one you can price — the deposit side of this card), erc-8141 and aa (the AA-standards collab), quick-slots-10s (EIP-8198), erc-7683-settlement-security (cross-chain settlement guarantees), rpc-view-not-consensus and third-party-blast-radius (the RPC-provider dependency).
Ethlabs의 'Fast Ethereum' 작업은 L1→L2 입금을 빠르게 합니다: Fast Confirmation Rule(FCR)은 브리지가 L1 트랜잭션을 12–24초 — 파이널리티보다 ~30배 빠르게 확인하게 합니다. 더 약하지만 값을 매길 수 있는 보장으로, 입금을 인정하기엔 충분합니다. 하지만 L2→L1 출금은 같은 식으로 빠르게 못 합니다: 옵티미스틱 롤업은 챌린지 윈도우에, zk 롤업은 증명 시간에 묶입니다. 그 비대칭은 구현 결함이 아니라 구조적입니다 — 롤업에 들어가려면 L1 확인을 신뢰하면 되지만, 나가려면 롤업이 자기 상태를 증명해야 합니다. 앱-L2들(Lighter, Derive)이 최고 고충으로 꼽은 교훈: 약하게 신뢰할 수 있는 방향은 가속할 수 있어도, 증명되어야 하는 방향은 못 한다.
구현이 아니라 양방향 지연 지도입니다. 고른 L2에 대해 두 방향을 측정(또는 모델링)하되, 더 중요하게 각각이 무엇을 기다리는지 명명하세요. 입금(L1→L2): 시퀀서가 인정 전에 무엇을 기다리나 — N개 블록 확인, 파이널리티, 아니면 FCR식 규칙? FCR은 파이널리티보다 약한 규칙으로 L1 tx를 확인해 12–24초를 약속합니다; 받아들이는 정확한 실패(확인 깊이를 넘는 리오그)와 그걸 누가 떠안는지 적으세요. 출금(L2→L1): 인출을 막는 게 무엇인가 — 옵티미스틱 챌린지 윈도우(수일)인가 zk 증명 시간(수분~수시간)인가? 그 게이트는 롤업 자신의 보안 메커니즘이라, 롤업을 약화시키지 않고는 단축 불가. 그다음 FCR이 부딪힌 현실 장애: L2는 외부 RPC 제공자를 통해 L1 입금을 감시하므로, FCR 채택이 RPC 제공자의 출시에 묶임 — 프로토콜이 아니라 공급망 의존성. 출처: Ethlabs Week 11(2026-09-07, X); FCR, EIP-8198(Quick/Fast Slots), Fast Finality. 수치(12–24초, 30배, 12s→10s)와 EIP/포크 상태는 게시글·EIP로 확인 후 인용.
왜
롤업 경계를 넘는 두 방향은 서로 다른 보안 시계로 돌아가고, 그래서 하나는 가속되고 하나는 안 됩니다. 롤업에 들어가기 — 입금 — 는 L2가 L1 트랜잭션이 일어났음을 신뢰하기만 하면 됩니다. 신뢰는 등급을 매길 수 있습니다: 파이널리티를 기다리는 대신, 브리지는 '이 L1 tx가 이 가정 하에 깊이 D까지 확인됨'이라는 Fast Confirmation Rule을 받아들여 ~13분 대신 12–24초를 얻고 잔여 리오그 리스크에 값을 매길 수 있습니다. 롤업에서 나가기 — 출금 — 는 반대입니다: L1은 신뢰로 자금을 풀지 않고, 롤업이 자기 상태가 유효함을 증명하길 요구합니다. 옵티미스틱 롤업은 챌린지 부재로 증명(윈도우를 견딤), zk 롤업은 증명으로 증명(프루버를 기다림). 어느 대기도 최적화로 없앨 버그가 아니라 — 그게 곧 롤업의 보안입니다.
그래서 '빠른 인터롭'은 사실 한 문구를 쓴 두 개의 다른 문제입니다. 입금 지연은 신뢰 보정 문제 — 파이널리티보다 약한 확인 규칙을 골라 꼬리 리스크를 관리(l2-finality-three-clocks가 같은 통찰: '파이널'은 여러 시계 중 하나이고, 값을 매기면 더 이른 시계로 행동 가능). 출금 지연은 증명 비용 문제 — 증명 시간이나 챌린지 윈도우를 줄일 순 있어도, 롤업이 L1을 설득해야 한다는 요건 자체는 못 없앱니다. 둘을 뭉치는 게 로드맵이 '즉시 브리징'을 약속하고 조용히 쉬운 방향만 뜻하는 경로입니다.
Ethlabs 업데이트가 드러내는 2차 교훈 둘. 첫째, 채택은 공급망입니다: FCR은 프로토콜이 아니라 L2가 L1 감시에 의존하는 RPC 제공자에 막힙니다 — 지루한 미들웨어가 출시하기 전엔 빠른 규칙이 무용(third-party-blast-radius, rpc-view-not-consensus). 둘째, 베이스 계층 가속은 상보적이나 별개입니다: Fast Slots(EIP-8198)는 블록 타임 12s→10s(UX 레버, quick-slots-10s), Fast Finality는 합의를 1–2슬롯 파이널리티로 재설계(입금-신뢰 간극을 직접 줄임). 어떤 '브리징을 빠르게 했다' 주장에도 관통하는 질문: 어느 방향이 빨라졌고, 그 가속이 신뢰 가정을 완화했나(값 매기면 괜찮음) 아니면 증명 요건을 완화했나(훨씬 어렵고, 싸게 주장하면 의심스러움)?
동작 방식
한 경계, 두 시계
방향
수신자가 필요로 하는 것
속도를 막는 것
빠르게 가능?
입금 L1→L2
L1 tx가 일어났음을 신뢰
확인 깊이 vs 파이널리티
예 — FCR: 12–24초, 파이널리티보다 ~30배
출금 L2→L1
L1이 L2 상태를 확신해야
옵티미스틱 챌린지 윈도우 / zk 증명 시간
아니오 — 롤업 자신의 보안
비대칭이 카드 전부: 신뢰는 등급을 매겨 서두를 수 있고, 증명은 건너뛸 수 없다.
Fast-Ethereum 조각들, 각각이 닫는 간극
조각
하는 일
어느 간극
FCR
서브-파이널리티 규칙으로 L1 tx를 12–24초에 확인
입금 신뢰 지연
Fast Slots(EIP-8198)
블록 타임 12s → 10s, 더 낮추는 추세
베이스 UX 지연(quick-slots-10s)
Fast Finality
합의 재설계 → 1–2슬롯 파이널리티
입금-신뢰 간극을 근원에서 축소
채택 공급망
FCR의 장애는 암호가 아님 — L2는 외부 RPC 제공자로 L1 입금을 감시하므로, 그들이 출시하기 전엔 빠른 규칙이 무력. 프로토콜 승리가 미들웨어에 막힘(rpc-view-not-consensus, third-party-blast-radius).
같은 업데이트에 함께 (기존 카드로 흡수)
8130 ↔ 8141 AA 협업 — Base의 EIP-8130과 Frames(EIP-8141)를 검증을 교체 가능하게 만들어 통합: 7702식 위임 확장 / 강제 프록시 바이트코드 / 재해석된 프레임으로 L2가 EVM 검증을 동등한 네이티브 코드로 대체. 이건 erc-8141 업데이트.
교차: l2-finality-three-clocks(파이널리티는 여러 시계; 값 매길 수 있는 것으로 행동 — 이 카드의 입금 쪽), erc-8141·aa(AA 표준 협업), quick-slots-10s(EIP-8198), erc-7683-settlement-security(크로스체인 정산 보장), rpc-view-not-consensus·third-party-blast-radius(RPC 제공자 의존).