- 🔒 Decentralized Access Control
- 📐 Democratizing threshold cryptography
- 💼 Applications of a threshold network
- ⚠️ Problems with current constructions
- ✨ Medusa
- 🔓Decentralized Onchain Access Control
- 🌐 Website
- 📚 Documentation
- 🏗️ Path to production
- 🔬 Research
- ⛩️ Holy Grail DKG
- 🗂️ DKG: Description of problems & potential solutions
- ⚡ Fast R&D Exploration
- 👥 Team/Hiring
- 🔥 Competitors
- 📡 Long term vision: MPC
Project Medusa aims to construct large & robust threshold networks onchain. These networks are able to sign and decrypt at will following onchain’s command and are dynamic. The first use case out is to implement a robust decentralized programmatic access control policy onchain.
🔒 Decentralized Access Control
Currently in web3 almost all of the activity is public, including transactions and smart contracts interactions. Privacy is where many major innovations will come into web3 to bring it to large scale usage.
Access control, private data management is a core component of many web2 services and it is not clear yet how to make the transition to web3. This where Medusa comes in.
Medusa’s threshold network can be the gateway between the delegator, the party giving access, and the delegatee, the party being granted access. Medusa’s network is decentralized and will only release access to the recipient according to some programmable rules onchain. No information is gained by the network nor by third parties as Medusa doesn’t have access to unencrypted information.
Medusa can enable private decryption as explained above where only the recipient learns of the resulting message but also public decryption where the decryption is public, for everyone (users and smart contracts) to consume.
📐 Democratizing threshold cryptography
Even though treshold cryptography used to not be realistic before because the trust assumptions were seemed to be too much of a blocker, it turns out it is now attracting a lot of attention from a practical perspective:
- CryptoNetLab is looking at generalized threshold network to allow smart contract to "have a secret" that can unlock many use cases (data management is one)
- Drand is using threshold cryptography to build a randomness beacon
- Axelar Network is a blockchain bridge project that uses threshold network as a gatekeeper of tokens between different platforms
- Anoma Network is a blockhain that uses threshold network to prevent front running attacks
- ConsensusLab is looking to use DKGs to pinpoints state of Filecoin on other blockchains (BTC)
- ConsensusLab is looking to use DKGs to checkpoint subnet's state into parents subnets
💼 Applications of a threshold network
There are several important applications that could arise from having a general threshold cryptographic network:
- Smart contracts with private data: encrypted data is unlocked if some on-chain condition is met (e.g. an on-chain vote, a payment, etc).
- Specialized Random beacons: randomness is released only on some events.
- Access Control and Key Distribution: encrypted data is re-encrypted to be accessed by new users (e.g. private newsletter, private forums, etc).
- Trusted signatures (a signed attestation can be produced based on a mix of secret and on-chain information "address x guessed the correct number")
- Threshold based L2 (?)
- (Miner Extractable Value) MEV Protection
- Distributed PKI (identity based system):
- Anyone with an ID can get his corresponding secret key from the threshold committee
- Anybody can encrypt stuff to an ID, without having the key, even without the recipient being aware of it
⚠️ Problems with current constructions
For all these use cases, ideally we need large set of participants: the larger the size is the more trust we can have in the system. However, doing a DKG (the setup phase) over a large set of participants is unpractical (because of complexity)
Compatible with existing schemes
Ideally we want DKGs to be compatible with schemes that are already existing on other blockchains so interopability is given. The natural use case for DKGs is threshold signature: if the signature is compatible with well known schemes then the network can act as a participant easily in these other blockchains
Many more criterias defined in the Holy Grail DKG page.
Off chain governance
Ideally we want DKGs to be spawn on demand from onchain mechanisms, and more generally the governance of the DKG to happen on chain. We can start by using regular DKGs but eventually having fully publicly verifiable DKG onchain would enable that in a seamless fashion.
In a permission-less environment participants are associated with weights, and the idea is to randomly sample participants such that the totality of the selected nodes have a weight superior to a given threshold
Doing weighted DKG is extremely impracticable as we usually "emulate" as many nodes as one's weight, which comes back to the scalability issue.
Note: Ferveo from Anoma (taken from Gurkan et al . paper) is maybe the first DKG that tackles this nicely. It is still open questions for us whether it is practicable and the trade offs they are making. One direct con is that it is not using signature / encryption schemes compatible with mainstream protocols.
Our goal is to propose a Generalized Threshold Cryptography Network where anyone can write threshold contracts where the network obeys to the contract for signing & decrypting operations.
See this document for an overview of the preliminary design we’re envisioning for the system.
The first main project Medusa is focusing on the decentralized access control policy
🔓Decentralized Onchain Access Control
The projects aims to use Medusa to enforce any policy on some ciphertexts. The policy is defined by the user, on its own (no coordination with Medusa needed), and since it is on a smart contract can be changed, can be programmed at will depending on the platform’s features.
Think of some use cases with private decryption, where only the enduser learns of the encrypted message:
- “Give access to this mailing list if user has shown it has a specific NFT”
- “Decrypt message for recipient Y if he has enough stake in the contract”
Only the recipient learns about the private information, not the smart contract or Medusa itself. Medusa is only the gatekeeper that allows access or not.
Medusa could also be used for public decryption where the decrypted message is published plainly onchain so it can be used by any applications:
- Sealed bid auctions where every players’s actions are decrypted plainly onchain after a cutoff time
- A deadman’s switch that is revealed automatically in case the creator did not notified the smart contract in time
Note at the beginning the predicates will be public (not the content itself, but the condition on which the content is released) but there are plans to make it private later on.
Many aspect of this project is based on the scientific research from the Calypso paper.
We are working towards a demo which should be released very soon (early June 2022). See the next page for more information:
We want to develop a high quality technical documentation of what Medusa is about, how does one setup a network and the cryptographic operations the network can do.
Note that the documentation is a never ending endeavour, but at least each milestones on the MVP→ Product path should be accompanied with a serious documentation.
Timeline: Use Cases: End of Q2
Deliverable: A public document containing Use Cases and FAQ, and a documentation website (a la gitbook)
🏗️ Path to production
These are the steps we need to achieve with documentations about them in order to get it to production
In order to Medusa to bring truly scalable and robust threshold network, we need to work on some advanced problems in the space, most notably for the setup phase.
⛩️ Holy Grail DKG
This project is defining what is the ultimate DKG we would like to build, all the properties that it has. Obviously having all these goals combined seem out of reach now but having these guidelines help directing the different items this project will build.
→ See the Holy Grail page for more information.
Timeline: Q1 2022
Deliverable: Document listing out ideal properties of the DKG
Status: Done ✅
🗂️ DKG: Description of problems & potential solutions
This is the exploration phase to trying to map out all the potential solutions that we can do now or later with some work on proof systems to achieve the holy grail. Each solution giving a different set of properties from the holy grail list.
→ See the DKG Problems & Solutions document for more information
Timeline: Q1 2022
Deliverable: Document listing out solutions with their properties
Status: 80% 🔨
⚡ Fast R&D Exploration
This project contains multiple sub-projects that aims to do fast R&D to implement some of the solutions described in the previous project, especially concerning non interactive DKG using SNARKs.
This project aims to build the whole operation a dealer in a DKG must do inside of a SNARK so it can be publicly verifiable. Using these special curves, we end up having a distributed key on a pairing based curve where we can use BLS signatures afterwards.
→ See the DKG on BLS12-377 document for more information
Timeline: Q1 2022
Deliverable: PoC implementation with blog post sharing knowledge
Status: 80% 🔨
This project aims to use Nova recursive proof system with the Bitcoin curves to make a non interactive DKG. The ability to be able to verify a Nova proof inside a smart contract is at reach now given the usage of the Bitcoin curve.
→ See the DKG in Nova document for more information
Timeline: Q2-Q3 2022
Blocker: on Nova recursion + aggregation of public inputs to be developed
This project contains ideas that needs more details and implementation to see if they can work out.
→ See this document for more information.
Timeline: Q3 2022
Deliverable: 2 write up of potential use case + implementation of the useful use cases
Being able to have different hierarchy between nodes can prove useful to have a hybrid security between permissionless and permissioned nodes in the network. Imagine 60% of the nodes are permissioned, and we require 50% of them to be honest. We could make the scheme such that these rules are enforced, and the rest of the nodes can come from permissionless rules and increase the security.
For this project to become a reality, we need to bootstrap a small team. @nikkolasg g is to be the technical lead of the project. Then we need at least the following:
→ Note this is the topmost priority to hire
See the competitors matrix document for a rough analysis of the current related products available today.
📡 Long term vision: MPC
That network will be specialized for signing, and encryption but once we have a running set of permissionless set of nodes, we can actually do more things such as generalized MPC !
Generalized MPC network would be a true game changer for the ecosystem as it can bring private computation onchain. For this, we need the network to coordinate a lot in preprocessing information.
Timeline: Q1 2023
Deliverable: PoC of onchain governance of a network to private compute a simple function using MPC
People: nikkolas, rosario