# 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