Copy English

Why

Distributed key generation is the protocol by which n parties jointly produce one keypair such that the private key is never assembled anywhere, and any t of them can sign or decrypt with it. It is the primitive underneath four things this catalogue already has cards for: DVT validator keys (dvt), the keyper committees in threshold-encrypted mempools (encrypted-mempool), MPC custody (the custodian in fisheries-receivable-rail), and randomness beacons.

Every write-up states the same property — t-of-n, no single point of compromise — and it is true. What almost none of them state is what happens after the ceremony. A DKG is described as an event; every real deployment is a committee, and committees change. An operator leaves. A new one joins. One loses its share to a dead disk. Each of those needs a second ceremony — resharing — that has to be at least as trustworthy as the first, and it is the part that gets skipped in the documentation and, suspiciously often, in the deployment.

That matters more than it sounds, because of one property worth stating precisely: resharing can preserve the group's public key. Shares are re-randomised, membership changes, the public key stays. And the public key is usually the part nailed down somewhere else — a validator pubkey registered on the beacon chain, a deposit address a customer saved, a key ID baked into an already-broadcast encrypted transaction. If a deployment can reshare, changing the operator set is an operation. If it cannot, "change the operator set" quietly means "migrate everything that ever referenced the old key."

How it works

What a DKG actually produces

The last row deserves the hardest look. A threshold claim is only as good as the ability of an outsider to check that the ceremony really ran with the claimed participants and the claimed threshold.

The three membership events

That last question is the sharp one. A recovery procedure that lets t participants reconstruct a share for a member who lost theirs is, structurally, also a procedure that lets t colluding participants hand a share to anyone. Whatever separates the two is policy sitting outside the cryptography — which is the same boundary the aml-compliance card is about.

The measurement, and it is small

Run a real DKG locally — n = 7, t = 5, using an existing library rather than hand-rolling one — then measure the operations, not the cryptography:

1. Rounds and wall-clock for the initial ceremony.
2. Remove one participant. Does the group public key change?
3. Add one. How many rounds, and how much of the group must be online at once?
4. Kill a participant mid-ceremony. Does the protocol abort, restart, or exclude it?
5. Have an outsider verify the transcript using public data only.

Output is one table nobody publishes and every operator needs:

Where the n stops being n

Same shape as stake-concentration and aqua-shared-liquidity: a set that looks like n independent units while the real unit of independence is smaller. For a key committee the correlated axes are concrete — same cloud region, same client implementation, same jurisdiction, one operator running several nominally separate nodes.

The threshold t is arithmetic. The independence of the n is an empirical claim, and it is the one nobody measures. encrypted-mempool hit this from the other side — fewer than k honest keypers restores mempool-stage MEV — and third-party-blast-radius asks it about committee capture.

What breaks in each card if resharing turns out to be impossible

Open questions

• Does anyone publish the ceremony transcript? If not, the threshold is an assertion rather than a verifiable fact, and every downstream card is trusting a claim it cannot check.
• Which DKG is actually deployed — Pedersen with a complaint round (biasable, and one malicious participant can force a restart), GJKR, FROST for Schnorr thresholds, or a BLS variant. The choice determines abort behaviour, and abort behaviour is the operational property.
• Has any live deployment actually reshared in production, as opposed to documenting that it could? That single data point is worth more than any amount of spec reading, and it is the first thing to go looking for.

Where it lands in Jayverse

• Bridge: document whether the relayer committee can reshare. The Anvil↔Sepolia lock-and-mint relayer set is a committee; write down whether adding or removing a relayer preserves the registered bridge public key, or admit plainly that "rotate the operator set" currently means "migrate the bridge."
• Auditor: require a published ceremony transcript for any threshold setup. Any multisig or threshold component (the bridge relayer set, a future DVT-style validator group) should publish its ceremony transcript so the threshold is a verifiable fact, not an assertion nobody can check.
• Wallet: test the three membership events before trusting recovery. If wallet or bridge recovery ever uses a threshold scheme, run this page's three-event test on devnet first — operator leaves, operator joins, share lost — and check whether "recover a lost share" is distinguishable from "let t colluding operators hand a share to anyone."

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

의식은 끝나지만 위원회는 남는다

분산 키 생성은 일회성 사건으로 서술됩니다. 그런데 실제 배포된 것은 전부 구성원이 바뀌는 위원회이고, 두 번째 의식인 리셰어링은 아무도 예산에 넣지 않는 쪽입니다.

아직 범위 미정 — 기존 라이브러리로 n=7, t=5 DKG를 돌린 뒤 참여자 하나를 빼고 그룹 공개키가 살아남는지 본다. 암호학이 아니라 운영을 잰다. 가장 먼저 찾아볼 것: 운영 중에 실제로 리셰어링을 해 본 배포 — 문서상 가능하다고만 적힌 것 말고.

왜

분산 키 생성(DKG)은 n개 주체가 하나의 키쌍을 함께 만들되 개인키가 어디에서도 조립되지 않고, 그중 t개가 모이면 서명하거나 복호화할 수 있게 하는 프로토콜입니다. 이 카탈로그가 이미 카드를 가진 넷의 밑에 깔린 원시 기능입니다 — DVT 검증인 키(dvt), 암호화 멤풀의 keyper 위원회(encrypted-mempool), MPC 수탁(fisheries-receivable-rail의 수탁사), 그리고 랜덤성 비콘.

모든 글이 같은 성질을 말합니다 — t-of-n, 단일 침해 지점 없음 — 그리고 사실입니다. 그런데 거의 아무도 말하지 않는 것은 의식이 끝난 다음입니다. DKG는 사건으로 서술되지만, 실제 운영되는 것은 전부 위원회이고 위원회는 바뀝니다. 운영자가 떠나고, 새 운영자가 들어오고, 누군가는 디스크가 죽어 지분(share)을 잃습니다. 그 각각에 두 번째 의식 — 리셰어링(resharing) — 이 필요하고, 그것은 첫 번째만큼 신뢰할 수 있어야 합니다. 그리고 이 부분이 문서에서 빠지고, 수상하리만치 자주 배포에서도 빠집니다.

이게 들리는 것보다 중요한 이유는 성질 하나 때문입니다: 리셰어링은 그룹의 공개키를 보존할 수 있습니다. 지분은 다시 무작위화되고 구성원은 바뀌지만 공개키는 그대로입니다. 그리고 공개키야말로 대개 다른 곳에 못 박혀 있는 부분입니다 — 비콘 체인에 등록된 검증인 공개키, 고객이 저장해 둔 입금 주소, 이미 브로드캐스트된 암호화 트랜잭션에 박힌 key ID. 리셰어링이 되면 운영자 교체는 운영 작업입니다. 안 되면 "운영자 집합을 바꾼다"는 말은 조용히 "그 키를 참조한 모든 것을 이전한다"가 됩니다.

동작 방식

DKG가 실제로 만들어 내는 것

마지막 행을 가장 세게 봐야 합니다. 임계 주장은 외부인이 그 의식이 정말 주장된 참여자와 주장된 임계치로 돌았는지 확인할 수 있는 만큼만 값어치가 있습니다.

구성원 변경 세 가지

마지막 질문이 날카로운 쪽입니다. 지분을 잃은 구성원을 위해 t명이 지분을 복원해 주는 절차는, 구조적으로 공모한 t명이 아무에게나 지분을 넘겨줄 수 있는 절차와 같습니다. 둘을 가르는 것이 무엇이든 그것은 암호학 바깥의 정책이고, aml-compliance 카드가 다루는 바로 그 경계입니다.

측정 — 작습니다

로컬에서 진짜 DKG를 돌립니다. n = 7, t = 5, 직접 구현하지 말고 기존 라이브러리로. 그리고 암호학이 아니라 운영을 잽니다:

1. 최초 의식의 라운드 수와 실제 소요 시간.
2. 참여자 하나를 뺀다. 그룹 공개키가 바뀌는가?
3. 하나를 더한다. 몇 라운드이고, 그룹의 몇 %가 동시에 온라인이어야 하는가?
4. 의식 도중에 참여자 하나를 죽인다. 프로토콜이 중단되는가, 재시작하는가, 배제하는가?
5. 외부인이 공개 데이터만으로 트랜스크립트를 검증하게 한다.

산출물은 아무도 발표하지 않고 모든 운영자가 필요로 하는 표 하나입니다:

n이 n이기를 멈추는 지점

stake-concentration·aqua-shared-liquidity와 같은 형태입니다 — 겉보기엔 독립 단위 n개인데 실제 독립성의 단위는 더 작다는 것. 키 위원회에서 상관된 축은 구체적입니다: 같은 클라우드 리전, 같은 클라이언트 구현, 같은 관할권, 명목상 분리된 노드 여럿을 한 운영자가 돌리는 경우.

임계치 t는 산술입니다. n의 독립성은 경험적 주장이고, 아무도 재지 않는 쪽이 그것입니다. encrypted-mempool 카드가 반대편에서 같은 지점에 부딪혔고(정직한 keyper가 k 미만이면 멤풀 단계 MEV가 되살아난다), third-party-blast-radius는 위원회 장악에 대해 같은 질문을 합니다.

리셰어링이 불가능하다면 각 카드에서 무엇이 깨지나

열린 질문

• 의식 트랜스크립트를 공개하는 곳이 있는가? 없다면 임계치는 검증 가능한 사실이 아니라 주장이고, 하위의 모든 카드는 확인할 수 없는 주장을 믿고 있는 셈입니다.
• 실제로 배포된 DKG가 어느 것인가 — 이의제기 라운드가 있는 Pedersen(편향 가능하고, 악의적 참여자 하나가 재시작을 강제할 수 있음), GJKR, Schnorr 임계 서명용 FROST, 혹은 BLS 변형. 선택이 중단(abort) 동작을 결정하고, 중단 동작이 곧 운영 성질입니다.
• 운영 중에 실제로 리셰어링을 해 본 배포가 있는가 — "할 수 있다"고 문서에 적은 것 말고. 그 데이터 한 점이 어떤 스펙 독해보다 값어치가 큽니다, 그리고 가장 먼저 찾아볼 것입니다.

Jayverse에서의 위치

• Bridge: 릴레이어 위원회가 재분배 가능한지 문서화한다. Anvil↔Sepolia lock-and-mint 릴레이어 집합은 위원회다. 릴레이어를 추가하거나 제거해도 등록된 브릿지 공개키가 유지되는지 적어두거나, 그렇지 않다면 "운영자 집합 교체"가 사실상 "브릿지 마이그레이션"임을 명시한다.
• Auditor: 임계값 구성마다 공개된 세레모니 기록을 요구한다. 브릿지 릴레이어 집합이나 향후 DVT식 검증자 그룹 같은 멀티시그/임계값 구성은 세레모니 기록을 공개해야, 임계값이 아무도 확인할 수 없는 주장이 아니라 검증 가능한 사실이 된다.
• Wallet: 복구를 신뢰하기 전 세 가지 멤버십 이벤트를 테스트한다. 지갑이나 브릿지 복구가 임계값 방식을 쓴다면 devnet에서 운영자 이탈·합류·share 분실 세 이벤트를 먼저 테스트하고, "분실된 share 복구"와 "공모한 t명이 아무에게나 share를 건네주는 것"이 구분되는지 확인한다.

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