DRI: @Deleted User
Started: March 2022
Status: in progress
This projects aims to code a MVP of a interactive DKG onchain, on a smart contract.
- MVP #0: No Byzantine, simple Deals using BN254
- MVP #1: EthDKG using BN254.
- Motivation
- Deliverables
- Smart Contract Implementation
- Node implementation
- Testing
- Expected challenges
- Smart contract writing
- Concurrency
- Resources & Timeline
- Tasks
- Notes
- 03/03/2022
MVP #0: No Byzantine, simple Deals using BN254
To get the project started, we should consider there is no byzantine actors first (only honest but curious) and consider the setting where participants simply post their deals onchain (with encrypted shares still) but there is no “Complaint” phase.
This will help bootstrap the threshold operations MVP much faster.
The next step is to move to MVP #1.
MVP #1: EthDKG using BN254.
Motivation
- EthDKG provides a nice way to remove the justification phase AND have a publicly verifiable dispute phase. This make the protocol semi verifiable, at least in the pessimistic case which is what is most interesting.
- BN254 is the only pairing curve supported currently on Ethereum. Pairing curve enables more “fancy” use cases and optimizations.
Deliverables
There are multiple parts here to deliver:
Smart Contract Implementation
The smart contract is responsible for:
- Handling the list of active participants
- Activating the DKG with its different phases
- Receiving the deals from participants, and keeping the hash of it
- Receiving the responses from participants and doing the actual verification of a valid complaint (EthDKG / Neji DKG)
- This entails cryptographic operations
Node implementation
The node is responsible for:
- Creating, keeping the private key and interacting with the blockchain
- Listening on events from the smart contract, publishing to it depending on the phase
- Implementing the actual cryptographic scheme (Pedersen with Neji trick to avoid justification phase)
- Sharing phase as Pedersen
- COmplaint phase accompanied by proofs that the complainer is actually revealing the shared encryption key so smart contract decrypts the key received and check if it is correct or not
- If not correct, evict player
- (LATER - not necessary in this MVP)
- Keeping communications with the other nodes via a networking layer for doing signing/encrypting
- libp2p probably ?
Testing
Even though this implementation is a MVP, it is the basis on which the rest of Medusa will take place, and therefore needs to be of high quality from the get go. A subsistant set of tests is part of the deliverables.
Expected challenges
Smart contract writing
‘s experience in smart contract is small so there needs to be a ramp up of developing smart contracts in a safe way avoiding usual traps
Concurrency
Special attention must be paid to concurrency in such an environment, especially with manual CLI ↔ blockchain interactions.
Resources & Timeline
At time of writing (07/03/2022), @Deleted User is the only allocated staff for this, so this would probably take until end of Q1 2022 to get a proper version of this MVP.
Tasks
Notes
03/03/2022
Blockers
We need to chose one solution from the solution space
- Which curve ?
- Which platform ? L1 ? L2 ?
- Do we even need to post the messages on chain ? SInce it’s interactive, what do we gain from posting the messages ?
- some answers found here https://github.com/PhilippSchindler/EthDKG/blob/master/paper/ethdkg.pdf