• 🔭Motivation
• 🔒 Decentralized Access Control
• 📐 Democratizing threshold cryptography
• 💼 Applications of a threshold network
• ⚠️ Problems with current constructions
• ✨ Medusa
• 🔓Decentralized Onchain Access Control
• 📺Demo
• 🌐 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.

🔭Motivation

🔒 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

Scalability

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 $O(n^2)$ 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.

Weight compatible

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.

✨ Medusa

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

See here for a presentation on Medusa and this application and here for a demo of the application.

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.

📺Demo

We are working towards a demo which should be released very soon (early June 2022). See the next page for more information:

🪀Medusa Demo : DEPLOYED ! demo.medusanet.xyz

🌐 Website

Website is live at medusanet.xyz

📚 Documentation

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)

Status: 20%

🏗️ Path to production

These are the steps we need to achieve with documentations about them in order to get it to production

🔬 Research

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.

👥 Team/Hiring

For this project to become a reality, we need to bootstrap a small team. @Deleted User is to be the technical lead of the project. Then we need at least the following:

→ Note this is the topmost priority to hire

🔥 Competitors

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