입금은 빠른 확인을 믿고, 출금은 롤업 자신의 증명을 기다린다
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 제공자 의존).