---
# System prepended metadata

title: DKG Roadmap
tags: [nucypher]

---

# DKG Roadmap

[TODO] 
- Add a module diagram for combined version using https://excalidraw.com/
- Figure out how to fit this timeline into our product timeline
- Consider other rituals: key refreshing, key recovery; and their impact on DA
    - Do we even want to consider them on this timeline?
    - Are there simpler methods we could implement to avoid dedicating our capacity to implementing new rituals?
        - Rituals may be costly
    - Should cohort robustness be an opt-in feature?
    - Can we replace cohort refreshing with something else?

## Summary

- V1 is what we're working on now; we found some missing pieces (da, contracts); we should use it as an opportunity to flesh out the full scope of our MVP (client, nodes, contracts)
- Then, we can release V2 with a small, vetted cohort (absolute honesty assumption) and take it to market; sliver of security with a fail-over; it's not ideal in terms of quality of service, but it's sound and useful
- V3 has a lot of uncertanity related to transcript verification. If it doesn't play out, we can always switch to L1 etc. If it works, it will have production-grade security at this point


## Version 1

Naive DKG with no fail-over

- Goals
    - End-to-end tested, running locally, DKG implementation integrated with `nucypher` backend and `nucypher-contracts` DKG contract;
    - DKG contract performs a DKG ritual; doesn't perform transcript verification
    - Some sort of DA (sidechannel) for transcript sharing
        - Nodes perform verification off-chain
        - Use Polygon as DA
    - [TODO] Honest node assumption instead of transcript verification
        - [TODO] Should that be in v1 or v2?
        - Calculate transcript aggregate on each node
        - Each node posts the transcript aggregate (hash) on chain
        - If there is a difference between hashes, ritual fails
    - Local verification
        - Get transcripts from DA and verify the aggregate on the client before requesting decryption shares
    - A testnet for CBD
    - A rudimentary solution to Porter issues
        - aim for the least amount of work
        - e2e encryption between the browser and nodes
    - Contracts
        - Coordinator Contract
        - Sidechannel Contract
        - Simple Application Contract for CBD
        - Like a PRE contract: registry of operators etc.
    - Client
        - `nucypher`, `nucypher-ts`
        - Q: Are we going to seperate our clients? How do we maintain this codebase/product?
        - Q: Do we need seperate operators?
- Work items
    - [nucypher-contracts, DKG Coordinator V1](https://github.com/nucypher/nucypher-contracts/pull/59)
    - [ferveo, `ferveo-python`](https://github.com/nucypher/ferveo/pull/75)
    - [nucypher, DKG Ritual Prototype](https://github.com/nucypher/nucypher/pull/3054)
- Questions (from 23rd Feb sync)
    - [TODO] Some of these are product related, some of these are engineeringr related; divide, delegate, cleanup;
    - Does the "simple tdec" ferveo variant work in practice? @kieran
    - Identify rough areas to improve
    - Gas Costs and Efficiency (how much gas does it cost to run a node?; how much does it cost to run a DKG ritual?)
    - Parameterization options and best values (timeout and dkg size)
    - Success vs Failure rate of tdec
    - The bigger the group the more likely it is to fail?
    - Discern that certain cohort sizes work better than others
    - Inform future optimizations designs and research
        - How much fault tolerance do we really need?
    - How to integrate with threshold stakes?
        - CBD Application contract - considerations
    - Feasibility of slashing and identifying bad nodes?
    - Determine the technical viability of long-running nodes for operators
    - Gather clues about incentives and disincentives
    - How much do we need to pay to keep nodes running?
    - Are largo cohorts prohibitively expensive or unwieldy? 

## Version 2

Naive DKG with a fail-over

- Goals
    - Implement naive optimistic verification
        - Nodes perform p2p verification and every node can trigger a Ritual fail-over in the DKG contract
        - Implement DA for transcripts
            - [TODO] A research item (milestone) for specification 
            - P2P broadcast of transcripts so in the optimistic case everyone has a way to retrieve them
            - ipfs/arweave-based publication of transcripts (which can be supported by centralized or decentralized services)
            - specific data availability solutions
        - [TODO] Research and architect the final solution the Porter situation
    - [TODO] Other goals. What functional requirements do we put here?
    - [TODO] Changes in contracts
        - Integrate DA into coordinator contract

- Questions
    - Is there a time limit on the dispute period?
    - How do nodes obtain information about the common side-channel to use for transcripts? Is it a specific location parametrized by ritualId or something like that?
    - How are nodes notified that transcripts are available on the side-channel? Is this something akin to IPFS pubsub?
    - Do we currently have a sense of the feasibility (gas cost and speed) of the on-chain proof verification by the coordinator contract to settle the dispute?

## Version 3

Optimistic verification with on-chain dispute resolution

- Goals
    - Implement optimistic version with KZG: 
        - p2p verification, every node can trigger a dispute on-chain;
        - dispute can be settled by providing a proof (either an on-chain opening or a proof from a coprocessor)
            - [TODO] A research item on finalization of the verification
    - [TODO] Other goals. What functional requirements do we put here? Operations-related stuff?
    - [TODO] Changes in contract
        - CBD Application contract 
            - Here we can actually slash people
    - [TODO] Implement the final solution to the Porter problem
        - updating the browser-node networking stack

## Diagrams!

- Transitioning from one DA layer for transcripts (contract on Polygon) to another (IPFS)
- Logic related to handling DA is inside the node

![](https://i.imgur.com/8xoXaLf.png)
