Copy English

Why

The advice not to build an L2 is right, and the reason is sharper than time against utility. An L2's sequencer, data availability and proof system are precisely the layer an application developer is renting. choosing-a-chain-is-a-lease argues that picking a chain is signing a lease whose terms — who runs the sequencer, who can reorder, what leaving costs — are the part nobody markets. That framing sets the study depth exactly: learn enough to read the lease, not enough to construct the building. Sequencer, batcher, state root and output proposal, L1 to L2 messaging, and the difference between optimistic and validity finality are lease terms. Operating them is a different job, and the four cases where it is the right job — rollup protocol engineer, modifying OP Stack or Orbit, building a sequencer, DA layer, bridge or fault proof, running a company appchain — share one property: all four operate the layer rather than rent it.

Then the part worth building a card around, because it is where the surprise lives. "Supports EIP-7702" reads as a single fact and is three: the protocol defines the authorization and its semantics; the chain has activated the fork so a node will accept the transaction; and the wallet can present the authorization to a human and get a signature. They are produced by different people on different schedules, and each can be true while the others are false.

Anvil gives you the first, a testnet gives you the first two, and only a wallet gives you the third — which is the one that decides whether anybody can use the thing. This is the same shape as pick-a-signer-not-a-brand, where one brand name turned out to be four independent supply chains, and the layer that fails is never the one being audited.

The third layer is also the one you do not control, and that is not incidental. share-the-code-you-write puts it as a rule: you can share the code you write and not the code you must obey. A wallet's signing UX is somebody else's product decision, shipped on their release schedule, and no amount of correctness on your side moves it. Which means the honest output of this work is not "7702 works" but a list of wallets where it works and a decision about the ones where it does not — fall back, block, or wait.

For an authorization specifically the failure mode is worse than refusal. The authorization is a new object the user is asked to sign, and a wallet that does not understand it can do something worse than reject: render an opaque blob and ask for a signature anyway. That trains users to approve what they cannot read, which is the habit every phishing flow depends on. agentic-intent-veto makes the same argument about spending caps — the check that passes is not the check that matters — and here the check is a human being asked to authorise a delegation they were shown as hex.

And the general rule underneath all of it: "works on my chain" is the blockchain form of "works on my machine." The environment that decides the outcome is the one you do not own, and the whole purpose of the second and third passes is to reach it early rather than at launch.

How it works

One phrase, three independent facts

Each can be true while the others are false, and the last row is the one that decides adoption — and the one you do not control.

What Anvil structurally cannot show you

The first three are why the second pass exists. The fourth is why the third pass exists, and it is the one teams skip.

The matrix, which is the actual deliverable

The middle column is the one that matters most and gets scored least. A wallet that refuses is an inconvenience; a wallet that shows hex and asks for a signature anyway is teaching the user the habit that phishing runs on.

When building an L2 is the right call

Four cases, and they share one property: all of them operate the layer rather than rent it.

• Becoming a rollup protocol engineer
• Modifying OP Stack or Arbitrum Orbit
• Building a sequencer, DA layer, bridge or fault proof
• Running a company appchain in production

Outside those, the sequencer and proof system are lease terms rather than components, and the return on studying them is knowing what to ask — which choosing-a-chain-is-a-lease already turns into a four-row term sheet.

← All Dev Notes · Workspace Index · Top ↑

Copy 한국어

Anvil 은 프로토콜을, 테스트넷은 체인을, 지갑만이 사용자를 증명한다

L2 를 직접 만드는 것은 응용이 운영하는 층이 아니라 빌려 쓰는 층을 배우는 일이라, 공부 깊이는 "임대 조건을 읽을 만큼" 이면 됩니다. 대신 만들 값어치가 있는 것은 지원 매트릭스입니다 — "EIP-7702 를 지원한다" 는 서로 독립된 사실 셋을 한 문장으로 말한 것이고, 사용자가 실제로 할 수 있는지를 정하는 것은 세 번째뿐이기 때문입니다.

아직 범위 미정이고, 한 번의 빌드가 아니라 세 번의 통과입니다. 첫째, 올바른 하드포크로 띄운 Anvil — 필요하면 공개 체인을 fork 해서 실제 컨트랙트 상태를 끌어옵니다. authorization 튜플, 위임, 해지, 그리고 같은 authorization 을 다른 chain id 에서 재생하면 무슨 일이 생기는지를 돌려 봅니다. 이 통과의 결과물은 데모가 아니라 제품이 기대는 의미론을 고정하는 테스트 스위트입니다. 둘째, 그 포크가 들어간 공개 테스트넷에서 실제 RPC 로 같은 트랜잭션을 보냅니다 — 그리고 Anvil 이 구조적으로 만들 수 없는 숫자 둘을 기록합니다: 수수료 중 L1 데이터 몫, 그리고 "포함됨"과 "확정됨" 사이의 실제 시간. 셋째, 그리고 제품을 결정하는 것은 이것입니다 — 지갑 × 체인 매트릭스에 네 칸: 지갑이 authorization 을 애초에 받는가, 무엇을 위임하는지 보여주는가, 위임 대상 주소를 표시하는가, 사용자가 나중에 해지할 수 있는가. 스크린샷을 남기십시오 — 실패는 버그 리포트가 아니라 제품 결정입니다. 7702 에 대한 지갑 지원은 주 단위로 바뀌므로, 이 표를 포함해 어떤 표든 원문에서 다시 확인해야 하는 것으로 다루십시오.

왜

L2 를 직접 만들지 말라는 조언은 맞고, 이유는 "시간 대비 효용"보다 날카롭습니다. L2 의 시퀀서·데이터 가용성·증명 시스템은 정확히 응용 개발자가 빌려 쓰는 층입니다. choosing-a-chain-is-a-lease 는 체인을 고르는 것이 임대 계약에 서명하는 것이고 그 조건 — 누가 시퀀서를 돌리는가, 누가 순서를 바꿀 수 있는가, 떠나는 데 얼마가 드는가 — 이 아무도 마케팅하지 않는 부분이라고 주장합니다. 그 프레이밍이 공부 깊이를 정확히 정해 줍니다: 임대 조건을 읽을 만큼 배우고, 건물을 지을 만큼은 배우지 않는다. 시퀀서, 배처, state root 와 output proposal, L1↔L2 메시징, optimistic 과 validity 의 finality 차이 — 전부 임대 조건입니다. 그것을 운영하는 것은 다른 직업이고, 그게 맞는 직업인 네 경우 — 롤업 프로토콜 엔지니어, OP Stack·Orbit 수정, 시퀀서·DA·브리지·fault proof 개발, 회사 앱체인 운영 — 는 한 가지 성질을 공유합니다: 넷 다 그 층을 빌리는 게 아니라 운영합니다.

그다음이 카드를 세울 값어치가 있는 부분이고, 놀랄 일이 사는 곳입니다. "EIP-7702 를 지원한다" 는 하나의 사실처럼 읽히지만 셋입니다: 프로토콜이 authorization 과 그 의미론을 정의하고, 체인이 포크를 활성화해 노드가 그 트랜잭션을 받아들이고, 지갑이 그 authorization 을 사람에게 보여주고 서명을 받아낼 수 있어야 합니다. 서로 다른 사람들이 서로 다른 일정으로 만들고, 하나가 참인 동안 나머지가 거짓일 수 있습니다.

Anvil 은 첫째를 주고, 테스트넷은 첫째와 둘째를 주고, 셋째는 지갑만이 줍니다 — 그리고 누군가 실제로 쓸 수 있는지를 정하는 것은 셋째입니다. 이건 pick-a-signer-not-a-brand 와 같은 모양입니다 — 브랜드 이름 하나가 실은 네 개의 독립된 공급망이었고, 무너지는 층은 감사받는 층이 아니었습니다.

셋째 층은 동시에 내가 통제하지 못하는 층이고, 그건 우연이 아닙니다. share-the-code-you-write 가 규칙으로 적어 뒀습니다 — 내가 쓴 코드는 공유되고, 지켜야 하는 코드는 공유되지 않는다. 지갑의 서명 UX 는 남의 제품 결정이고 남의 릴리스 일정에 실려 나오며, 내 쪽이 아무리 옳아도 그것을 움직이지 못합니다. 그러므로 이 작업의 정직한 산출물은 "7702 가 된다" 가 아니라 — 되는 지갑의 목록과, 안 되는 지갑에 대한 결정입니다: 대체 경로를 두거나, 막거나, 기다리거나.

특히 authorization 에서는 실패 양식이 거절보다 나쁩니다. authorization 은 사용자가 서명하도록 요청받는 새로운 객체이고, 그것을 이해하지 못하는 지갑은 거절보다 나쁜 일을 할 수 있습니다 — 알 수 없는 덩어리를 보여주고 그래도 서명을 요구하는 것. 그건 읽을 수 없는 것을 승인하도록 사용자를 훈련시키는 일이고, 모든 피싱 흐름이 기대는 습관입니다. agentic-intent-veto 가 지출 한도에 대해 같은 논증을 합니다 — 통과하는 검사가 중요한 검사는 아니다 — 그리고 여기서 그 검사는 16진수로 보여준 위임을 승인하라고 요청받는 사람입니다.

그리고 이 모든 것 아래의 일반 규칙: "내 체인에서는 된다"는 블록체인판 "내 컴퓨터에서는 된다"입니다. 결과를 정하는 환경은 내가 소유하지 않은 환경이고, 둘째·셋째 통과의 목적 전체가 출시 때가 아니라 일찍 거기 도달하는 것입니다.

동작 방식

한 문장, 서로 독립된 사실 셋

하나가 참인 동안 나머지가 거짓일 수 있고, 채택을 정하는 것은 마지막 줄이며 — 그게 내가 통제하지 못하는 줄입니다.

Anvil 이 구조적으로 보여줄 수 없는 것

앞의 셋이 둘째 통과가 존재하는 이유이고, 넷째가 셋째 통과가 존재하는 이유이며 그게 팀들이 건너뛰는 것입니다.

실제 산출물인 매트릭스

가운데 칸이 가장 중요하고 가장 덜 채점됩니다. 거절하는 지갑은 불편이지만, 16진수를 보여주고 그래도 서명을 요구하는 지갑은 피싱이 굴러가는 그 습관을 사용자에게 가르치고 있는 것입니다.

L2 를 직접 만드는 게 맞는 경우

네 경우이고, 한 성질을 공유합니다 — 넷 다 그 층을 빌리는 게 아니라 운영합니다.

• 롤업 프로토콜 엔지니어가 되려 할 때
• OP Stack 이나 Arbitrum Orbit 을 수정할 때
• 시퀀서·DA·브리지·fault proof 를 직접 개발할 때
• 회사 앱체인을 실제로 운영할 때

그 밖에서는 시퀀서와 증명 시스템은 부품이 아니라 임대 조건이고, 공부의 수익은 무엇을 물어야 할지 아는 것입니다 — choosing-a-chain-is-a-lease 가 이미 그것을 네 줄짜리 term sheet 으로 만들어 뒀습니다.

← 전체 개발 노트 · 워크스페이스 인덱스 · 맨 위 ↑