Copy English

Why

The instructive move is the one that looks like a downgrade. Today the deposit contract knows what a validator credential is: 48 bytes of public key, 96 bytes of signature metadata. Those constants are the contract holding an opinion about a cryptographic scheme it does not own, and every future scheme is blocked by it. The draft does not answer that by teaching the contract a second scheme — it makes the field variable-length and moves validity elsewhere. The contract stops understanding credentials and becomes transport for them. That is the generalisable technique, and it is counterintuitive precisely because the instinct in a migration is to add knowledge rather than remove it.

The retirement mode is the other half, and its irreversibility is the feature, not the risk. A one-way system call reads like danger — no rollback, no undo, no second chance. But consider the reversible version: if BLS retirement could be lifted, then no new BLS deposits, ever is not a guarantee, it is a current setting, and anyone who captures the switch restores the old scheme. The property being bought is exactly the impossibility of restoration. A switch that can be flipped back does not retire anything; it pauses it.

Which relocates the whole design problem to before the flip. A reversible change can be tested in production, because the cost of being wrong is a revert. An irreversible one moves every test in front of the switch and leaves nothing behind it, so the real question is never how do we build the switch — it is what evidence would be sufficient to flip it, and can that evidence be gathered on the live system without flipping. That is a specification problem wearing a smart contract's clothes, and it is why this draft is worth reading even by someone who will never touch BLS.

The reason variable-length is hard is aggregation, and it is worth naming. BLS12-381 gave the consensus layer more than a size: it gave aggregation. Hundreds of thousands of attestations per slot are tractable because n signatures still occupy 96 bytes and verification finishes in a pairing. Most post-quantum candidates — hash-based, lattice-based — either do not aggregate or aggregate far more expensively, so this draft is not proposing a migration. It is proposing something more modest and more useful: clear the deposit contract out of the way now, so it is not the obstacle on the day a migration is actually decided.

And the change that needs an EIP is a type, not an algorithm. bytes48 pubkey becomes bytes pubkey plus a scheme identifier. That one line is large because the deposit contract is the only execution-layer contract the beacon chain reads, and its log format is hardcoded into every client, every staking service and every indexer. The hardest code to change is not complex code — it is widely-read code, and nothing in the diff tells you which kind you are touching.

The line to this project is direct. A settlement contract accumulates opinions the same way: a signature format, an oracle payload shape, a resolution encoding, token decimals. Each one is a constant today and a migration problem later, and the day a scheme underneath has to change, the only two options are the ones in this draft — make the contract variable-length and let something else judge validity, or build a one-way door and be certain before walking through it. storage-collision-admin-takeover is the reminder of what a switch is when nobody is watching it: an admin power, and the invariant that guards it belongs in the same commit as the switch.

How it works

Two mechanisms, and what each one actually buys

Three modes, and the draft's actual status

Status as reported: draft, awaiting editor review, with contract address and activation timing undecided. And 8,192 bytes reads generous until you price hash-based signatures — for a SPHINCS+-class scheme it is headroom, not abundance. Meanwhile EIP-8141 opens opt-in quantum-safe signatures at the execution layer while this opens the same door at the consensus layer: two layers moving the same direction at once.

The pattern worth stealing

Do not teach the contract the new thing. Stop it knowing the old thing. A contract that validates a specific format must be changed for every new format; a contract that carries opaque bytes and defers judgement never needs changing again for that reason. The trade is explicit: the judgement does not vanish, it relocates — and wherever it lands inherits the security weight the constants used to carry.

Note the residue, too. Variable up to 8,192 bytes is still an opinion, just a looser one. Every migration of this shape leaves a bound behind, and the bound is the next generation's constant.

Designing a one-way door

The inventory this project can build today

Every constant in a settlement path that describes something the contract does not own is a future migration:

Producing that table costs an afternoon and is useful even if no migration ever happens, because it is also the list of assumptions a second chain would violate. Reads with quick-slots-10s, which is the same exercise for time.

Review clarification

Protocol proposal first, design principle second

The immediate subject is an Ethereum protocol migration affecting the execution layer, consensus clients, validator onboarding, staking services and indexers. The reusable lesson is not an official Ethereum policy: a contract should understand only what it needs to enforce its own invariants. The current deposit path is already closer to transport than to a full BLS verifier, so the direction is better described as BLS-shaped transport → scheme-neutral transport. Complexity moves to the consensus or verifier layer; it does not disappear.

Split at trust and change boundaries

MarketFactory → EventMarket → fixed IResolver
                              ├─ ChainlinkResolver
                              ├─ CommitteeResolver
                              └─ TLSProofResolver

EventMarket should keep positions, collateral, finality and payout invariants together so redemption remains atomic. A resolver converts vendor-specific evidence into a canonical {status, outcome, resolvedAt} and receives no arbitrary custody authority. Pin it when the market is created; approve replacements only for future markets.

Do not split because a function is long. Split when security authority, upgrade cadence, failure mode or implementation choice genuinely differs; otherwise use an internal function or library. Variable length must remain bounded for gas and denial-of-service safety. Design the core around stable economic invariants and place changing formats behind bounded, versioned interfaces.

Where it lands in Jayverse

• Verex: inventory every hardcoded settlement opinion. List every place Verex's settlement path hardcodes a fact it does not own — signature format and length, oracle payload encoding, resolution record shape, collateral decimals, address size — and mark each as variable-length-capable or not; that table is useful even if nothing ever migrates.
• Verex: keep the resolver a scheme-neutral transport. A resolver should convert vendor-specific evidence into a canonical status/outcome/resolvedAt struct with no arbitrary custody authority, pinned at market creation; approve a replacement resolver only for future markets, never retroactively.
• Auditor: require a flip criterion for any one-way admin switch. Before any irreversible switch ships (a BLS-retirement-style flag, a resolver lock), write down what evidence is sufficient to flip it and whether that evidence can be gathered without flipping — and land the invariant guarding the call in the same commit as the switch.
• Devnet/CI: bound every variable-length field. Any field that becomes variable-length to accommodate a future scheme must carry an explicit size bound, tested on devnet before it reaches Verex's settlement contracts, so a generalization never opens a gas/DoS hole.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

마이그레이션은 컨트랙트를 더 멍청하게 만들어서 성립한다

초안 EIP가 예치 컨트랙트에 하드코딩된 BLS12-381 치수를 가변 길이 자격증명으로 바꾸고, 시스템 콜로 한 번 넘기면 되돌릴 수 없는 BLS 은퇴 모드를 더합니다. 기법은 컨트랙트에 새 방식을 가르치는 것이 아니라, 옛 방식에 대해 갖고 있던 의견을 없애는 것입니다.

아직 범위 미정 — 첫 작업은 설계가 아니라 의견 목록 만들기입니다. 이 프로젝트의 정산 경로가 자기 소유가 아닌 방식에 대한 사실을 하드코딩한 자리를 전부 적습니다 — 서명 형식과 길이, 오라클 페이로드 인코딩, 정산 기록의 모양, 담보 토큰 소수점, 주소 크기. 각각에 대해 가변 길이로 바꾸고 유효성 검사를 다른 곳으로 옮길 수 있는지, 아니면 컨트랙트가 정말로 이해해야 하는지를 표시합니다. 그 목록이 마이그레이션 표면이고, 실제로 무언가를 옮기든 안 옮기든 이미 존재합니다. 출처: 2026-08-24 Kevaundray Wedderburn·Tom Wambsgans·Thomas Coratger 가 제출한 포스트퀀텀 예치 컨트랙트 EIP 초안 — 현재 공개키 48바이트·서명 메타 96바이트, 제안은 최대 8,192바이트 가변 자격증명, 그리고 시스템 콜로 발동되는 되돌릴 수 없는 BLS 은퇴 모드. 수치에 기대기 전에 초안 원문을 읽을 것.

왜

배울 만한 수는 다운그레이드처럼 보이는 쪽입니다. 지금 예치 컨트랙트는 검증인 자격증명이 무엇인지 압니다 — 공개키 48바이트, 서명 메타 96바이트. 그 상수들은 컨트랙트가 자기 소유가 아닌 암호 방식에 대해 의견을 갖고 있다는 뜻이고, 앞으로의 모든 방식이 그 의견에 막힙니다. 초안은 컨트랙트에 두 번째 방식을 가르쳐서 답하지 않습니다 — 필드를 가변 길이로 만들고 유효성 판단을 다른 데로 옮깁니다. 컨트랙트가 자격증명을 이해하기를 그만두고 그것의 운반 수단이 됩니다. 이것이 일반화 가능한 기법이고, 마이그레이션에서의 본능이 지식을 빼는 게 아니라 더하는 것이라서 직관에 반합니다.

은퇴 모드가 나머지 절반이고, 되돌릴 수 없다는 성질은 위험이 아니라 기능입니다. 일방향 시스템 콜은 위험해 보입니다 — 롤백도, 취소도, 두 번째 기회도 없음. 그런데 되돌릴 수 있는 판본을 생각해 보세요: BLS 은퇴를 해제할 수 있다면 앞으로 BLS 예치는 없다 는 보장이 아니라 현재 설정이고, 스위치를 장악한 자가 옛 방식을 복원합니다. 사려는 속성이 정확히 복원 불가능성입니다. 되돌릴 수 있는 스위치는 아무것도 은퇴시키지 않습니다 — 일시정지시킬 뿐입니다.

그래서 설계 문제 전체가 스위치를 넘기기 전 으로 옮겨갑니다. 되돌릴 수 있는 변경은 운영 환경에서 시험할 수 있습니다. 틀렸을 때의 비용이 되돌리기니까요. 되돌릴 수 없는 변경은 모든 시험을 스위치 앞으로 옮기고 뒤에는 아무것도 남기지 않습니다. 그러니 진짜 질문은 스위치를 어떻게 만드나 가 아니라 — 무엇이 증거로 충분한가, 그리고 그 증거를 스위치를 넘기지 않은 채 살아 있는 시스템에서 모을 수 있는가 입니다. 스마트 컨트랙트의 옷을 입은 명세 문제이고, BLS를 평생 만질 일 없는 사람에게도 이 초안이 읽을 값이 있는 이유입니다.

가변 길이가 어려운 이유는 집계이고, 이름을 붙여 둘 값이 있습니다. BLS12-381이 합의 계층에 준 것은 크기만이 아니라 집계였습니다. 한 슬롯에 수십만 개의 attestation 이 감당되는 이유는 n개의 서명이 여전히 96바이트이고 검증이 페어링 하나로 끝나기 때문입니다. 포스트퀀텀 후보 대부분은 — 해시 기반이든 격자 기반이든 — 집계가 안 되거나 훨씬 비싸게 됩니다. 그러니 이 초안이 제안하는 것은 마이그레이션이 아닙니다. 더 겸손하고 더 쓸모 있는 것입니다 — 지금 예치 컨트랙트를 치워 둬서, 실제로 갈아탈 결정이 내려지는 날 그것이 걸림돌이 되지 않게 하는 것.

그리고 EIP가 필요한 변경은 알고리즘이 아니라 타입입니다. bytes48 pubkey 가 bytes pubkey + 스킴 식별자가 됩니다. 그 한 줄이 큰 이유는 예치 컨트랙트가 비콘 체인이 읽는 유일한 실행 계층 컨트랙트이고, 그 로그 포맷이 모든 클라이언트·모든 스테이킹 서비스·모든 인덱서에 하드코딩돼 있기 때문입니다. 가장 바꾸기 어려운 코드는 복잡한 코드가 아니라 많이 읽히는 코드이고, diff 안의 어떤 것도 지금 어느 쪽을 만지는지 알려주지 않습니다.

이 프로젝트로 이어지는 선은 직선입니다. 정산 컨트랙트도 같은 방식으로 의견을 쌓습니다 — 서명 형식, 오라클 페이로드 모양, 정산 인코딩, 토큰 소수점. 각각은 오늘은 상수이고 나중에는 마이그레이션 문제이며, 아래의 방식이 바뀌어야 하는 날 선택지는 이 초안의 둘뿐입니다 — 컨트랙트를 가변 길이로 만들고 유효성은 다른 것이 판단하게 하거나, 일방향 문을 만들고 지나가기 전에 확신하거나. storage-collision-admin-takeover 는 아무도 안 볼 때 스위치가 무엇인지를 상기시킵니다 — 관리자 권한이고, 그것을 지키는 불변식은 스위치와 같은 커밋에 들어가야 합니다.

동작 방식

두 메커니즘, 각각이 실제로 사는 것

세 가지 모드, 그리고 초안의 실제 지위

보도된 지위: 초안, 에디터 리뷰 대기, 컨트랙트 주소와 활성화 시점 미정. 그리고 8,192바이트는 넉넉해 보이지만 해시 기반 서명 크기를 대 보면 — SPHINCS+ 계열이라면 풍족이 아니라 여유 정도입니다. 한편 EIP-8141은 실행 계층에서 옵트인 양자 안전 서명의 문을 열고, 이 초안은 합의 계층에서 같은 문을 엽니다 — 두 층이 동시에 같은 방향으로.

훔칠 만한 패턴

컨트랙트에 새것을 가르치지 말고, 옛것을 알기를 그만두게 하라. 특정 형식을 검증하는 컨트랙트는 새 형식마다 바뀌어야 하고, 불투명한 바이트를 나르며 판단을 미루는 컨트랙트는 그 이유로는 다시 바뀌지 않습니다. 거래는 명시적입니다 — 판단은 사라지지 않고 자리를 옮기며, 옮겨간 곳이 상수들이 지고 있던 보안 하중을 물려받습니다.

남는 것도 적어 둡니다. 최대 8,192바이트까지 가변 은 여전히 의견이고, 다만 헐거운 의견입니다. 이런 모양의 마이그레이션은 언제나 상한을 남기고, 그 상한이 다음 세대의 상수가 됩니다.

일방향 문을 설계하기

이 프로젝트가 오늘 만들 수 있는 목록

정산 경로에서 컨트랙트가 소유하지 않은 것을 서술하는 모든 상수가 미래의 마이그레이션입니다:

이 표를 만드는 데 반나절이 들고, 마이그레이션이 영영 없어도 쓸모 있습니다. 그건 동시에 두 번째 체인이 위반할 전제들의 목록이기 때문입니다. 시간에 대해 같은 작업을 하는 quick-slots-10s 와 함께 읽습니다.

검토 후 보완

먼저 프로토콜 제안, 그다음 설계 원칙

직접적인 주제는 실행 계층, 합의 클라이언트, 검증자 등록, 스테이킹 서비스, 인덱서에 영향을 주는 Ethereum 프로토콜 마이그레이션입니다. 일반 교훈은 Ethereum의 공식 정책이 아닙니다. 컨트랙트는 자기 불변조건을 집행하는 데 필요한 것만 이해해야 합니다. 현재 예치 경로도 완전한 BLS 검증기보다 운반 계층에 가까우므로 방향은 똑똑한 검증기 → 멍청한 운반보다 BLS 모양 운반 → 방식 중립 운반에 가깝습니다. 복잡성은 사라지지 않고 합의 또는 검증 계층으로 이동합니다.

신뢰·변경 경계에서 나눈다

MarketFactory → EventMarket → 고정 IResolver
                              ├─ ChainlinkResolver
                              ├─ CommitteeResolver
                              └─ TLSProofResolver

EventMarket은 포지션, 담보, 최종성, 지급 불변조건을 함께 보유해 상환의 원자성을 유지합니다. Resolver는 공급자별 증거를 표준 {status, outcome, resolvedAt}로 바꾸고 임의 보관 권한은 받지 않습니다. 시장 생성 시 고정하고 교체는 미래 시장에만 적용합니다.

함수가 길다는 이유로 나누지 않습니다. 보안 권한, 변경 주기, 장애 모드, 구현 선택이 실제로 다를 때 나누고, 아니면 내부 함수나 라이브러리를 사용합니다. 가변 길이도 가스와 서비스 거부 안전을 위해 상한이 필요합니다. 안정적인 경제 불변조건을 중심으로 코어를 설계하고 변하는 형식은 크기가 제한되고 버전이 있는 인터페이스 뒤에 둡니다.

Jayverse에서의 위치

• Verex: 정산 경로의 모든 고정 가정을 목록화한다. Verex 정산 경로가 소유하지 않은 사실을 하드코딩하는 모든 곳 — 서명 형식과 길이, 오라클 페이로드 인코딩, 정산 기록 형태, 담보 소수점 자리수, 주소 크기 — 을 나열하고 각각 가변 길이로 바꿀 수 있는지 표시한다. 이 표는 마이그레이션이 실제로 일어나지 않아도 유용하다.
• Verex: 리졸버를 스킴 중립 전송 계층으로 유지한다. 리졸버는 벤더별 증거를 status/outcome/resolvedAt 형태의 표준 구조체로 변환할 뿐 임의의 커스터디 권한을 가지면 안 되며, 마켓 생성 시 고정한다. 교체 리졸버는 미래 마켓에만 적용하고 소급하지 않는다.
• Auditor: 되돌릴 수 없는 관리자 스위치마다 전환 기준을 요구한다. BLS 은퇴 방식의 플래그나 리졸버 잠금 같은 일방향 스위치를 출시하기 전에, 어떤 증거가 있으면 전환해도 되는지, 그 증거를 전환 없이 모을 수 있는지 적어두고, 스위치를 지키는 불변식을 같은 커밋에 넣는다.
• Devnet/CI: 가변 길이 필드마다 상한을 둔다. 미래 스킴을 수용하려고 가변 길이가 된 필드는 명시적 크기 상한을 가져야 하며, Verex 정산 컨트랙트에 닿기 전 devnet에서 테스트해 일반화가 가스/DoS 구멍을 열지 않게 한다.

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