Copy English

Why

The old inclusion-list designs asked the censor to police himself. One proposer wrote the list, and that proposer could be exactly the party leaving the transaction out — the watchman and the watched were the same seat. FOCIL's committee is not primarily about redundancy; it is about separating those two roles, and it buys a specific and unusually cheap trust assumption: 1-of-N honesty. One member out of sixteen reflecting their own mempool is enough to force inclusion. That is the whole design, and everything argued about it is downstream of that one line.

The enforcement is the real change, and it is a change of category rather than degree. Today, excluding a transaction is not a protocol violation — it is a choice a builder makes, and the only pressure against it is social. Putting the check into fork choice means attesters simply do not vote for a block that ignores the list, and a block without votes never becomes canonical. There is no route around it — not through a relay, not through a builder — because the thing being changed is not who builds but what counts as a block.

The cost lands in two places, and both are worth more than the headline. First, safety now depends on a timing parameter: lists arriving after the view-freeze deadline are ignored for that slot. Set it late and an honest block can be rejected over propagation luck; set it early and a censor only has to delay list gossip slightly to win. That is protocol security resting on network latency, which is a physical property, not a cryptographic one. Second, enforcement is conditional — roughly "include the list's valid transactions while block space remains" — because an unconditional rule would make honest proposers fail when the list overflows the block. And a conditional rule always creates its own evasion: the moment "if there is space" appears, consuming the space becomes the new censorship. FOCIL answers that by separating the gas accounting so the attack is expensive, which is the right answer and does not repeal the principle: unconditional rules fail honest participants, conditional rules turn the condition into the attack surface, and the quality of a design is how narrowly and verifiably the condition is written.

How it works

What moves where

The slot has to hold three things in order

1. Committee members build lists from their own mempool view and gossip them on a dedicated subnet.
2. The builder or proposer assembles a block having seen those lists.
3. Attesters compare the block against the lists they saw — and different attesters can have seen different sets.

Step 3 is why a view-freeze deadline exists at all: lists arriving after it are not counted for that slot.

The freeze deadline is a two-sided failure

There is no setting that is safe in both directions, only a setting matched to observed network latency — which is why this parameter is the spec.

Unconditional versus conditional, as a general rule

• Unconditional: safe to state, but it can make an honest participant unable to comply.
• Conditional: protects the honest participant, and hands the attacker the condition.
• Therefore: design quality lives in how narrow and checkable the condition is — here, separate gas accounting so filling the block to deny space costs real money.

The part that is actually yours

Censorship resistance in a prediction market is not philosophy, it is settlement accuracy: an order at the close, a dispute, an oracle update. FOCIL does not promise "cannot be censored"; it promises the cost of censoring becomes explicit. What you write in a design doc is not FOCIL — it is the number of slots each time-sensitive path can absorb.

Where it lands in Jayverse

• Verex: write down the slot-absorption number for each time-sensitive path. For an order at the close, a dispute filing, and an oracle update, list how many slots of delay each can absorb before the outcome changes — the page's own exercise, applied to the real settlement pipeline.
• Devnet: the view-freeze deadline is a network-latency parameter, not a crypto one. When Devnet moves toward an OP-Stack L2, the same two-sided failure (too early lets a censor win, too late rejects an honest block) applies to sequencer confirmation windows and needs its own measured value, not a borrowed default.
• OFA / Auditor: narrow the condition, don't remove it. FOCIL's inclusion rule is conditional ("while space remains") and defends against evasion by pricing the condition separately (its own gas allowance); OFA's solver commitments and the Auditor's methodology should each state their condition as narrowly and checkably.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

검열저항이 규범이기를 그만두고 포크초이스 규칙이 된다

FOCIL 은 인클루전 리스트 작성을 프로포저 한 명에서 무작위 위원회로 옮기고 — 진짜 중요한 부분 — 강제를 포크초이스 안으로 옮깁니다. 어테스터가 집계된 리스트를 무시한 블록에 투표를 주지 않으므로, 검열하는 블록은 정본이 될 수 없습니다. 보장의 범주가 바뀝니다 — "넣어 주세요" 가 아니라 "빼면 당신 블록이 안 세어진다" 입니다.

만드는 일이 아니라 두 절을 읽고 숫자 하나를 적는 일입니다. EIP-7805 에서 Rationale 과 파라미터 절만 읽습니다 — 위원회 크기가 어떻게 정당화되는지, 그리고 관점 동결(view freeze) 시각이 어떻게 정해지는지. 이 두 선택이 설계 전체를 떠받칩니다. 그다음 진짜 내 몫을 합니다 — 내 시스템에서 한 슬롯 지연이 결과를 바꾸는 모든 경로를 적고(마감 직전 주문, 분쟁 제기, 오라클 갱신), 각각이 견딜 수 있는 슬롯 수 N 을 옆에 적습니다. 산출물은 그 숫자이지 FOCIL 지식이 아닙니다. 여기의 수치(프로포저 + 16명 규모 위원회, 슬롯별 가십 서브넷, 리스트 전용 가스 한도)는 2026-08-28 기준 독해이며, 아직 움직이는 스펙이므로 원문 확인이 필요합니다.

왜

기존 인클루전 리스트 설계는 검열자에게 자기 자신을 감시하라고 요구했습니다. 프로포저 한 명이 리스트를 썼고, 그 프로포저가 바로 그 트랜잭션을 빼는 당사자일 수 있었습니다 — 감시자와 감시 대상이 같은 자리였습니다. FOCIL 의 위원회는 일차적으로 중복성이 아니라 그 두 역할을 분리하는 장치이고, 그 대가로 이례적으로 싼 신뢰 가정 하나를 삽니다 — 1-of-N 정직성. 16명 중 한 명만 자기 멤풀을 정직하게 반영하면 포함이 강제됩니다. 이게 설계의 전부이고, 이 설계를 둘러싼 모든 논쟁은 그 한 줄의 하류입니다.

진짜 변화는 강제 방식이고, 그것은 정도가 아니라 범주의 변화입니다. 오늘 트랜잭션을 빼는 것은 프로토콜 위반이 아닙니다 — 빌더의 선택이고, 그에 맞서는 압력은 사회적인 것뿐입니다. 검사를 포크초이스에 넣는다는 것은, 어테스터가 리스트를 무시한 블록에 그냥 투표하지 않는다는 뜻이고, 표를 못 받은 블록은 정본이 되지 못합니다. 우회로가 없습니다 — 릴레이를 통해도, 빌더를 통해도 — 바뀐 것이 누가 만드는가가 아니라 무엇이 블록으로 세어지는가이기 때문입니다.

대가는 두 곳에 떨어지고, 둘 다 헤드라인보다 값이 나갑니다. 첫째, 안전성이 타이밍 파라미터에 걸립니다 — 동결 시각 이후 도착한 리스트는 그 슬롯 평가에서 빠집니다. 늦게 잡으면 전파 운 때문에 정직한 블록이 탈락하고, 이르게 잡으면 검열자가 리스트 전파를 조금만 늦춰도 이깁니다. 프로토콜 보안을 네트워크 지연이라는 물리 현상 위에 올려놓는 설계입니다. 둘째, 강제가 조건부입니다 — 대략 "블록에 공간이 남아 있는 한 리스트의 유효 트랜잭션을 넣어야 한다" — 무조건 규칙이면 리스트가 블록을 넘칠 때 정직한 프로포저가 규칙을 못 지키기 때문입니다. 그리고 조건부 규칙은 언제나 자기 회피 경로를 만듭니다 — "공간이 있으면" 이 붙는 순간, 공간을 없애는 것이 새로운 검열 수법이 됩니다. FOCIL 은 가스 회계를 분리해 그 공격을 비싸게 만드는 쪽으로 답했고, 그건 옳은 답이지만 원리를 폐기하지는 않습니다 — 무조건 규칙은 정직한 참여자를 실패시키고, 조건부 규칙은 조건을 공격면으로 만들며, 설계의 질은 그 조건을 얼마나 좁고 검증 가능하게 썼는가에서 갈립니다.

동작 방식

무엇이 어디로 옮겨가는가

한 슬롯 안에 세 가지가 순서대로

1. 위원들이 자기 멤풀 관점으로 리스트를 만들어 전용 서브넷에 가십.
2. 빌더·프로포저가 그 리스트를 본 상태로 블록 조립.
3. 어테스터가 자기가 본 리스트 집합과 블록을 대조 — 어테스터마다 본 집합이 다를 수 있습니다.

3번이 관점 동결(view freeze) 시각이 존재하는 이유입니다 — 그 이후 도착한 리스트는 그 슬롯에서 세지 않습니다.

동결 시각은 양쪽으로 실패한다

양방향으로 안전한 값은 없고, 관측된 네트워크 지연에 맞춘 값만 있습니다 — 그래서 이 파라미터가 곧 스펙입니다.

무조건 vs 조건부, 일반 규칙으로

• 무조건: 진술은 안전하지만 정직한 참여자가 지킬 수 없게 만들 수 있습니다.
• 조건부: 정직한 참여자를 보호하고, 조건을 공격자에게 넘깁니다.
• 따라서: 설계의 질은 조건이 얼마나 좁고 검증 가능한가에 있습니다 — 여기서는 가스 회계 분리로 공간을 없애는 공격에 실제 비용을 물립니다.

진짜 내 몫

예측시장에서 검열저항은 철학이 아니라 정산 정확성입니다 — 마감 직전 주문, 분쟁, 오라클 갱신. FOCIL 이 주는 것은 "검열 불가" 가 아니라 "검열의 비용이 명시적이 된다" 입니다. 설계 문서에 적을 것은 FOCIL 이 아니라 — 시간 민감 경로마다 견딜 수 있는 슬롯 수 입니다.

Jayverse에서의 위치

• Verex: 시간에 민감한 각 경로의 슬롯-흡수 숫자를 적어둔다. 마감 시점의 주문, 분쟁 제기, 오라클 업데이트 각각에 대해 결과가 바뀌기 전까지 몇 슬롯의 지연을 흡수할 수 있는지 나열한다. 페이지 자체의 연습을 실제 정산 파이프라인에 적용한 것이다.
• Devnet: 뷰 프리즈 마감은 암호학적 파라미터가 아니라 네트워크 지연 파라미터다. Devnet이 OP-Stack L2로 옮겨갈 때, 너무 이르면 검열자가 이기고 너무 늦으면 정직한 블록이 거부되는 같은 양방향 실패가 시퀀서 확인 창에도 적용되므로, 빌려온 기본값이 아니라 자체 측정값이 필요하다.
• OFA / Auditor: 조건을 없애지 말고 좁힌다. FOCIL의 포함 규칙은 조건부("공간이 남아 있는 한")이고 그 조건에 별도 가스 할당을 매겨 회피를 비싸게 만든다. OFA의 솔버 커밋과 Auditor의 방법론도 각자의 조건을 그만큼 좁고 검증 가능하게 명시해야 한다.

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