DKG-tDec Ritual Specification

# DKG-tDec Ritual Specification ### High-level components - Initiator - Sampler - samples nodes using an economically-related weighting mechanism - produces ***n + buffer*** nodes that successfully perform an network uptime check - Coordinator - Coordination layer uses a general a modular backend that supports smart contracts ans well as other persistence systems. - Eager validation and early failure to prevent unproductive rituals - The status of a DKG ritual can be determined using the coorindation layer - Emits signals - Round 0: `StartRitual` - Round 1: `StartTranscriptRound` - Round 2: `StartConfirmationRound` - Stores transcripts and… - Nodes - Listener - listens for signals from the coordination layer and initiates node participation in a DKG round. - nodes will poll DKG status from coordination layer (e.g., listening for events) - Storage - private key fragments indexed by `ritual_id` - nodes have long-term “blinding keypair” (`ek_i, dk_i`) - Verification - verification of cohort transcripts ### Key Generation Procedure - **Before Round 1** - Initiator selects the group of nodes they want to use, by whatever logic the want to (it can be random sampling, or it can be based on additional criteria like if they're running tbtc nodes or have pre-existing agreements) - **Round 1 - Transcripts:** - Coordination send the `StartTranscriptsRound` signal to initiate the first round - Nodes receive round 1 signal and produce a DKG transcript - Nodes post transcripts to coordination layer (this makes publicly available their transcripts) - Once `N` transcripts are received the round is ended, or when ceremony `TIMEOUT` happens. - Coordination layer will signal the end of first round and the start of the second round with the `StartAggregationRound` **END STATE**: N nodes have submitted transcripts ```mermaid sequenceDiagram participant COORDINATOR participant NODES COORDINATOR->>NODES: sends "StartTranscriptsRound" signal NODES->>NODES: receive "StartTranscriptsRound" signal NODES->>NODES: produce DKG transcript NODES->>COORDINATOR: post transcripts to coordination layer COORDINATOR->>NODES: signals end of first round ``` - **Round 2 - Aggregation:** - Nodes will aggregate all transcripts and validate the end result. - Each node gets the blinded private share `Y_i` from the aggregated transcript. Then using their unblinding key `dk_i`, they can compute their private key share `Z_i`. - Once `N` aggregations are received the round is ended, or when ceremony `TIMEOUT` happens. - The only successful case is when the `N` aggregations are the same. - Coordination layer will signal a succesful DKG round only in said case; otherwise it's a failed result. **END STATE**: N validated transcripts ```mermaid stateDiagram-v2 state dkg_ended <<choice>> [*] --> AWAITING_TRANSCRIPTS: Ritual initiated AWAITING_TRANSCRIPTS --> AWAITING_AGGREGATIONS: N transcripts received AWAITING_TRANSCRIPTS --> TIMED_OUT: Ritual time out AWAITING_AGGREGATIONS --> TIMED_OUT: Ritual time out AWAITING_AGGREGATIONS --> dkg_ended: N aggregations received dkg_ended --> FINALIZED: Identical aggregations dkg_ended --> INVALID: Aggregations mismatch ``` - **After Round 2:** - Initiator/Encryptors can get the encryption public key from the aggregated transcript. **END STATE**: public key aggregation from validated transcripts, each node stores private key share from validated transcripts #### State Machine ```mermaid sequenceDiagram participant COORDINATOR participant NODES NODES->>NODES: Aggregate transcripts NODES->>NODES: Compute private key share NODES->>COORDINATOR: Posts aggregated transcript COORDINATOR->>NODES: Signals success/failure of ritual ``` ### Design principles - Coordination layer should be pluggable - We want to fail earlier if possible - It should always be possible to check the status of a DKG ritual using the coordination layer - We can implement different types of rituals, we don't need one-size-fits-all ritual. E.g., we can implement an optimistic/no-fault-tolerance ritual, but also a pessimistic/with-buffer ritual. - We can use failed rituals as evidence for slashing. ### Serializible entities - DKG transcripts ### Terminology Node: Cohort: A group of nodes Transcript: A public byte string containing information that can be used to verify the validity of the DKG protocols execution for a given node. Coordinator: An abstract layer that provides synchronization and storage for nodes that participate in DKG protocols. ### API **Coordination Layer** The coordination layer API provides the following operations for reading and writing data related to the Distributed Key Generation (DKG) rituals on-chain: *Read operations* - `getRitualState(ritual_id: str) -> str`: This operation returns the current state of the specified DKG ritual. The state can be one of the following: `INITIATED`, `WAITING_FOR_TRANSCRIPTS`, `WAITING_FOR_CONFIRMATIONS`, or `FINALIZED`. - `getRituals(ritual_ids: List[str]) -> List[Rituals]`: This operation returns a list of DKG rituals specified by the `ritual_ids` list. Each element in the list is an instance of the `Rituals` class, which contains information such as the ritual ID, the addresses of participating nodes, and the transcripts submitted by each node. - `getAggregatedTranscript(ritual_id) -> bytes` - `getEncryptionPublicKey(ritual_id) -> bytes` - Question: Do we need the whole aggregate transcript of the public key is enough? *Write operations* - `initiateRitual(m-of-n, node_list) -> str`: This operation initiates a new DKG ritual and returns its ID. The initiator provides the desired m-of-n configuration for the cohort, and the list of nodes that will participate. - TBD: Buffer? - `check-in(ritual_id: str, address: str)`: This operation allows a node to check-in for a specific DKG ritual. - `submitTranscript(ritual_id: str, address: str, transcript: Transcript)`: This operation allows a node to submit its transcript for a specific DKG ritual. The transcript argument is an instance of the `Transcript` class, which contains the node's contribution to the DKG process. - `validateTranscripts(ritual_id: str, address: str, validations: List[bool])`: This operation allows a node to validate the transcripts submitted by other nodes for a specific DKG ritual. The `validations` argument is a list of Boolean values, where `True` indicates that a node's transcript is valid and `False` indicates that it is invalid. - `postConfirmation(ritual_id: str, nodeIndex: int, confirmedNodesIndexes: List[int])`: This operation allows a node to post its confirmation for the transcripts submitted by other nodes for a specific DKG ritual. The `nodeIndex` argument is the index of the node in the list of participating nodes, and the `confirmedNodesIndexes` argument is a list of indexes of nodes whose transcripts have been confirmed as valid. **Node (Ursula)** The Node API provides operations for participating in DKG rituals as a node. - Keypair Initialization - generate blinding keypair `dk_i` - `generate_ferveo_keys()` - store this keypair in persistent storage - Coordination Layer Signal Processing - `node.listen_for_rituals(dkg_contract_address)` - start listening to ritual events on the contract address - `node.handle_ritual_event(ritual_event)` - `if event|state == NewRitual|INITIATED` (Round 0) - `if node.address is in ritual_event.addresses` - `check-in(ritual_id, address)` - `node.active_rituals.add(ritual_event.ritual_id)` - `if event|state == StartTranscriptRound|WAITING_FOR_TRANSCRIPTS` (Round 1) - `if event.dks_id is in node.active_rituals` - `transcript = generate_transcript()` ←ferveo - `store_transcript_and_material(ritual_id, transcript)` - `node.storage[ritual_id] = (transcript)` - `submitTranscript(ritual_id, node_index, transcript)` - `if event|state == StartConfirmationRound|WAITING_FOR_CONFIRMATIONS` (Round 2) - `ritual = getRituals([ritual_id])` - `for ritual in ritual.transcripts` - `validate_transcript(ritual.addresses[i], ritual.transcripts[i])` - if all transcripts are valid - `node_index = ritual.addresses.index()` - `confirmedNodesIndices` = indices of valid nodes - `postConfirmations(ritual_id, node_index, confirmedNodesIndices)` - `node.finalize_ritual(ritual_id, transcripts)` - *aggregates transcripts and computes the blinded private share `Y_i`* - `aggregated_transcript = aggregate_transcripts(transcripts)` - *Then using their unblinding key `dk_i` compute private key share `Z_i`* - `kfrag = compute_key_fragment(aggregated_transcript, unblinding_key` - *store the private key share `Z_i` indexed by `ritual_id`* - `store_dkg_fragment(ritual_id, kfrag)` - `node.storage.persist(ritual_id, kfrag)` *Initialization* - `ferveo::generate_keypair() -> ferveo::Keypair`: This operation generates a new keypair for use in the DKG protocol and returns the keypair. The generated keypair consists of a public (blinding) key and a a private (unblinding) key. - `nucypher::store_keypair(keypair: ferveo::Keypair)`: This operation persists a keypair for later use. *Coordination Layer Signal Processing* - `nucypher::listen_for_rituals(dkg_contract_address: str)`: This operation starts listening for DKG ritual events on the specified Ethereum contract address. - `nucypher::handle_ritual_event(ritual_event: Event)`: This operation handles a DKG ritual event. The following steps are taken: - If the state of the event is `NewRitual` - `ferveo::Dkg::new(ritual_id: int, shares_num: int, threshold: int, validators: List[ExternalValidator], me: ExternalValidator)` - `ferveo::Dkg::generate_transcript(rng): Transcript` - `ferveo::Dkg::validate_transcript(transcript): Boolean` - `ferveo::Dkg::aggregate_transcripts(messages: List[(ExternalValidator, Transcript)]): AggregatedTranscript` - `ferveo::AggregatedTranscript::validate(dkg: Dkg): Boolean` - `ferveo::AggregatedTranscript::create_decryption_share(dkg: Dkg, ciphertext: Ciphertext, aad: bytes, unblinding_key: PrivateKey): DecryptionShare` **Potential Optimizations** - optimize boundary conditions of rounds. Simpler way is just timing, but we can optimize maybe. - on-chain mechanism to track finalization of a DKG ritual - coordinator trustlessly finalizes the ritual (onchain) - Nodes resume/recover a ritual upon reboot, interruption, etc. ### Questions - Are nodes stateles/stateful? - stateful (blinding keys, decryption fragments, transcripts, …) - Coordination layer signals: push vs pull? - Smart contract PoC assumes rounds are defined by time. - Can a node recover from a fault during/after the DKG? - Are blinding keys changing on every DKG round or not? - constant for the lifetime of the node? - derive from seed/salt? - “semi-trusted revoke” by destruction of fragments? - selection buffer size? - Decide if we want to introduce another role just for validation. Probably not, but just in case. - coordinator trustlessly finalizes the ritual? (onchain finalization/aggregation) - Are `ritual_id` and policy identifier the same? (implication on Bob and ursula retrieval) - Open an issue to track the feasibility of on-chain aggregation of the public key. - What is the primary way to get the public key of the DKG? onchain? - Undesign onchain checkins / coordinator checkin / network availabilty checkups - Preserve initiator as a smart contract? - Blinding keypair --> - Do we want a single key pair per node, or a different keypair for each cohort they participate in? - How is the public blinding key discovered by other nodes? Maybe just announce it P2P like stamps. - How to prevent a collusion of nodes and initiator to frame an honest node? - Can we somehow reuse the optimistic verification to prevent malicious aggregate/transcript posting? - What other alternatives do we have? Feldmans/KZG commitments? - Only validate transcripts when slashing? ### Share Renewal/Refresh > TODO: Decide on terminology ### Share Recovery ### Share Reproduction > TODO: Ew.... Not sure if this is a great name ## DKG Protocols ## Sampling ### Green Path Analysis ```flow st=>start: Start op=>operation: Initiator samples M = N + buffer nodes cond=>condition: Has >N responses e=>end st->op->cond cond(yes)->e cond(no)->op ``` ----- ### Key Generation Procedure - **Round 0:** - Selection of *N + buffer* nodes - Check for network availability (check-in, ping, heartbeat) - Return *N + buffer* “alive” node addresses - Alice initiates new DKG ritual is initiated by signaling to the coordination layer. - Coordination layer emits the `NewRitual` signal - The signal includes the *******ritual ID******* and addresses to be used in this ritual - Nodes receive the `NewRitual` signal and submit a "check-in" - Node is actively listening for signals - Node filtrates signals that do not pertain to itself - Coordination layer can evaluate if a ritual is still in progress - `INITIATED` - (i.e., still waiting for check-ins), - `WAITING_FOR_TRANSCRIPTS` - if it was successful (*N + buffer* check-ins) - `WAITING_FOR_CONFIRMATIONS` - or if it failed (otherwise) - `FINAL` - `TIMEOUT` - timed out **END STATE**: (N + buffer) nodes have checked-in ```mermaid sequenceDiagram participant INITIATOR participant COORDINATOR participant NODES INITIATOR->>COORDINATOR: initiates a new DKG ritual COORDINATOR->>COORDINATOR: emits "NewRitual" signal COORDINATOR->>NODES: emits "NewRitual" signal NODES->>NODES: receive "NewRitual" signal NODES->>NODES: check-in NODES->>COORDINATOR: check-in COORDINATOR->>COORDINATOR: determine ritual state ``` - **Round 1:** - Coordination send the `READY` signal to initiate the first round - Nodes receive round 1 signal and produce a DKG transcript - Nodes post transcripts to coordination layer (this makes publicly available their transcripts) - Coordination layer will signal the end of first round and the start of the second round **END STATE**: (N + buffer) nodes have submitted transcripts ```mermaid sequenceDiagram participant COORDINATOR participant NODES COORDINATOR->>NODES: sends "Ready" signal NODES->>NODES: receive "Ready" signal NODES->>NODES: produce DKG transcript NODES->>COORDINATOR: post transcripts to coordination layer COORDINATOR->>NODES: signals end of first round ``` - **Round 2:** - Transcripts will be verified and validated transcripts will be marked on the coordination layer - All nodes in a DKG will validate each other - Coordination layer will signal the end of second round - After second round, cooridnation layer stores the validation state for each transcript, and it should be publicly discernible and verifiable if the outcome of the DKG was successful or failure. **END STATE**: N validated transcripts ```mermaid sequenceDiagram participant COORDINATOR participant NODES NODES->>NODES: Verifies and validates transcripts NODES->>COORDINATOR: Posts transcripts COORDINATOR->>NODES: Signals end of second round ``` - **After Round 2:** - Initiator can aggregate the public key component of each transcripts and compute the DKG aggregated public key (i.e… the encryption key) - Each node has to aggregate their private key component of each transcripts to compute the blinded private share `Y_i`. Then using their unblinding key `dk_i`, they can compute their private key share `Z_i`. **END STATE**: public key aggregation from validated transcripts, each node stores private key share from validated transcripts ```mermaid sequenceDiagram participant INITIATOR participant NODES Note over INITIATOR,NODES: Encryption with DKG public key INITIATOR->>INITIATOR: aggregates public key component of each transcript INITIATOR->>INITIATOR: computes DKG aggregated public key Note over INITIATOR,NODES: Threshold decryption with shared secret NODES->>NODES: aggregate private key component of each transcript NODES->>NODES: compute blinded private share NODES->>NODES: compute private key share # DKG Refresh specification ```mermaid sequenceDiagram participant COORDINATOR participant NODES Note over COORDINATOR,NODES: 1st Round COORDINATOR->>NODES: sends "Ready" signal NODES->>NODES: Build random polynomial NODES->>NODES: Compute polynomial deltas NODES->>COORDINATOR: Submit deltas COORDINATOR->>NODES: Signals end of first round Note over COORDINATOR,NODES: 2nd Round NODES->>NODES: Collect own deltas NODES->>NODES: Compute new private key share ``` As written so far in `ferveo`, the protocol would end here. However there are outstanding questions: - Have all nodes submitted correct deltas? - Have all nodes correctly built their new private key share? We need validation to happen again. There are a couple of options: - Nodes submit new transcripts and Initiator computes the DKG aggregated public key and checks it matches the original - Nodes submit new transcripts and all nodes validate each other (similar to original DKG ritual) I also have one outstanding question: - **what entities are able to initiate a Refresh?** and does this expose us to DOS attacks? ### Other notes - Refresh needs knowledge of the original DKG ritual. A refresh can only occur if the original DKG ritual is in state `FINALIZED`.

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.