The ceremony ends, the committee doesn't

Distributed key generation is written up as a one-time event. Every real deployment is a committee whose membership changes — and the second ceremony, resharing, is the one nobody budgets for.

Not yet scoped — run an off-the-shelf DKG at n=7, t=5, then remove one participant and check whether the group public key survives. Measure operations, not cryptography. First thing to go looking for: a live deployment that has actually reshared in production, not one that documents it could.

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

Output	Who holds it	Note
The private key	Nobody, ever	Exists only implicitly, as the interpolation of shares
The public key	Everyone; published	This is what other systems bind to
Share i	Participant i	Useless alone below the threshold
The transcript	Should be public	The evidence that the key was generated as claimed

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

Event	What has to happen	The question that decides it
An operator leaves	Reshare to n−1, or replace in place	Does the group public key survive?
An operator joins	Reshare to n+1	Who authorises it, and can the incumbents veto?
A share is lost	Recover from ≥ t others, or reshare	Is recovery distinguishable from theft?

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:

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

Output is one table nobody publishes and every operator needs:

Event	Rounds	Online quorum required	Downtime	Public key preserved

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

Card	The key that is nailed down elsewhere	Consequence
`dvt`	Validator pubkey registered on the beacon chain	Changing operators means exiting and re-depositing
`encrypted-mempool`	Key provider ID and key ID, in the plaintext envelope	A committee change invalidates references already broadcast
`fisheries-receivable-rail`	The custody address a customer saved	"Rotate the operator set" becomes "move the assets"

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.

← All Dev Notes · Workspace Index · Top ↑

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

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

아직 범위 미정 — 기존 라이브러리로 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가 실제로 만들어 내는 것

산출물	누가 갖나	비고
개인키	아무도, 한 번도	지분의 보간으로만 암묵적으로 존재
공개키	모두, 공개됨	다른 시스템이 묶이는 대상
지분 i	참여자 i	임계치 미만에서는 단독으로 무용
트랜스크립트	공개되어야 함	주장한 대로 키가 생성됐다는 증거

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

구성원 변경 세 가지

사건	무엇이 일어나야 하나	성패를 가르는 질문
운영자가 떠남	n−1로 리셰어, 또는 자리 교체	그룹 공개키가 살아남나?
운영자가 들어옴	n+1로 리셰어	누가 승인하고, 기존 구성원이 거부할 수 있나?
지분 분실	t개 이상에서 복구, 또는 리셰어	복구와 절도가 구별되나?

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

측정 — 작습니다

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

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

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

사건	라운드	필요한 온라인 정족수	다운타임	공개키 보존

n이 n이기를 멈추는 지점

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

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

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

카드	다른 곳에 못 박혀 있는 키	결과
`dvt`	비콘 체인에 등록된 검증인 공개키	운영자 교체 = 出금 후 재예치
`encrypted-mempool`	평문 봉투 안의 key provider ID·key ID	위원회 변경이 이미 브로드캐스트된 참조를 무효화
`fisheries-receivable-rail`	고객이 저장해 둔 수탁 주소	"운영자 집합 교체"가 "자산 이전"이 됨

열린 질문

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

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