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.

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.

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:

There are several important applications that could arise from having a general threshold cryptographic network:

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.

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

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:

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:

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:

Website is live at medusanet.xyz

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%

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.

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 ✅

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% 🔨

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.

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

See the competitors matrix document for a rough analysis of the current related products available today.

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