add a readme file #3
Conversation
README.md
Outdated
| Owner [20]byte `ssz-size:"20"` | ||
| } | ||
| ``` | ||
| *ValidatorPubKey*, *EncryptedShare*, and *Owner* are to identify information of the validator and the operator in SSV netwwork, the *SharePubKey* is computed by the operator after the DKG ceremony using the obtained secret share as the private key. |
There was a problem hiding this comment.
More information about proof and validation criteria is added. However, how proof helps to protect against attack is I think subject to more discussion and we may update the proof struct as well.
README.md
Outdated
| When a init message is sent to the operators, all operators participate and run a DKG ceremony to create key shares. A DKG ceremony asks each operator to verifiably share locally generated secrets with other operators, and combine secret shares from all operators to derive its own BLS key share. After the ceremony, each operator generates a **Result** with a **SignedProof** (see below) for verification. Proofs are referred to when an initiator asks for re-sign or reshare. | ||
|
|
||
| ### Re-sign | ||
| In the case where the nonces of a DKG ceremony is not correct, to prevent replay attack, the initiator sends re-sign messages for operators to create new signatures with correct nonces without generating new key shares. |
There was a problem hiding this comment.
It is creating new key-shares, though. The procedure only changes the signature part of the shares...but it does change the overall sharesData.
Re-phrase to "without generating a new validator key"? 🤔
There was a problem hiding this comment.
Also, the signature part is owner-nonce, so it could be that both were wrong...for whatever reason. Might be just more "complete" to clarify that both can be changed.
README.md
Outdated
| # SSV Distributed Key Generation Spec | ||
|
|
||
| ## Introduction | ||
| This repository contains spec of distributed key generation (DKG) used in SSV. Based on verifiable secret sharing, DKG allows a set of *n* operators to generate a **BLS** key share for each operator, such that a BLS private key can only be used when threshold *t* out of *n* operators agree. |
There was a problem hiding this comment.
provide a formula for "t out of n"?
where t is defined by the number of faults admissible:
n = 3 * f + 1
README.md
Outdated
| Owner [20]byte `ssz-size:"20"` | ||
| } | ||
| ``` | ||
| *ValidatorPubKey*, *EncryptedShare*, and *Owner* are to identify information of the validator and the operator in SSV network, the *SharePubKey* is computed by the operator after the DKG ceremony using the obtained secret share as the private key. |
There was a problem hiding this comment.
likely it's me failing to understand, but:
EncryptedShareis the operator's encrypted "portion" of the validator's share data, correct?SharePubKeyis derived fromEncryptedShare? the phrasing here speaks of "using the obtained secret", but...what secret?
README.md
Outdated
| *ValidatorPubKey*, *EncryptedShare*, and *Owner* are to identify information of the validator and the operator in SSV network, the *SharePubKey* is computed by the operator after the DKG ceremony using the obtained secret share as the private key. | ||
|
|
||
| **Proof**s are published by the initiator after the DKG ceremony. All **Proof** from a ceremony together validates the completion of this ceremony. they can make sure: | ||
| - Partial signatures of operators are publically verifiable using the *SharePubKey* in the **proof**. If an operator created invalid partial signatures, the network is able to identify and potentially take further action. |
There was a problem hiding this comment.
How could one verify this? I have a SharePubKey produced by an operator...what do I do with it, practically?
| ### Reshare | ||
| When the set of operators changed (including change of size and change of operators), a reshare is initiated to generate new key shares among the new operators. This process requires participation from *t* old operators and all new operators. | ||
|
|
||
| --- |
There was a problem hiding this comment.
Add the following here (or wherever you see fit)
Security Assumptions
All messages are authenticated using the initiator's and operators' public key.
Init
The initiator is fully trusted. Meaning it won't deviate from protocol. But it can have faults (go, up and down).
Re-sign
The initiator is not trusted. It may try to fool the operators into resigning with the wrong secret shares, owner and nonce. Also since in the resign operation the owner may change, and owner is used in the Proof, all
Reshare
The initiator is not trusted. It may try to fool the operators into resharing with the wrong secret shares. Or resharing without permission.
I thought we don't have owner's signature for init? |
|
@alan-ssvlabs |
No description provided.