The First Milestone for COTI V2 Development has been Achieved!

Upgrading COTI to a privacy-centric L2 on Ethereum represents the most ambitious pivot the ecosystem has seen to date. With an intense development schedule and tight project deadlines, it’s crucial that COTI V2 meets every delivery milestone on its roadmap.

After months of development, we are pleased to announce the achievement of a pivotal milestone: the successful design and integration of the Multi-Party Computation (MPC) protocol of COTI V2.

In this article, we will provide an overview of the protocol’s architecture, elucidate its operational mechanisms, and detail the methodologies employed in its testing.

A (Very) Brief Introduction into Multi-Party Computation (MPC)

Multi-Party Computation (MPC) is a revolutionary field in cryptography, where cryptographic protocols enable a group of parties to collaboratively perform a computation on their private inputs without disclosing them to each other. This process is inherently designed to protect the confidentiality of each participant’s data throughout the computation phase. To put it succinctly, the essence of an MPC transaction involves participants contributing encrypted data to a designated MPC “black box.” The black box processes these inputs to produce a result that is then distributed among the participants. What makes MPC particularly compelling is its ability to assure that the computation’s output does not compromise any confidential data, thus maintaining privacy integrity even against third-party scrutiny.

By leveraging such encryption mechanisms, MPC ensures that the computation can be carried out without necessitating mutual trust among the involved parties. This characteristic is particularly advantageous in scenarios where sensitive data needs to be computed collectively but cannot be shared due to privacy concerns or regulatory requirements.

MPC Endpoints & Extended EVM

In the context of subsequent development milestones, each MPC entity will be referred to as an “MPC endpoint” and will be incorporated into an Extended-EVM execution module.

Extended EVM refers to the interaction between the Ethereum Virtual Machine execution module and the collaboration of various MPC Endpoints. The state of the Extended-EVM is composed of the normal (public) state of the EVM (Ethereum) as well as the extension (private) state that is managed by the MPC protocol. It is distinguished by its dual-state system: the conventional (public) state of the EVM, alongside an augmented (private) state, meticulously managed by the MPC protocol. This dual-state system enhances the EVM’s functionality, enabling it to support a wider array of decentralized applications (DApps) by providing both transparency and privacy where required.

The integration of MPC endpoints into the Extended-EVM architecture signifies a notable advancement in blockchain technology, offering enhanced security and privacy for complex computations. Such architectural innovations are pivotal as they lay the groundwork for developing more sophisticated, privacy-preserving blockchain applications, thereby expanding the potential use cases of Ethereum and similar blockchain platforms.

Architecture Workflow

The “black-box” managed by the MPC (as depicted below) is divided to three main parts: (i) the cryptographic key material associated with the users (top-left), (ii) the encrypted data received from users and maintained by the MPC as a data pool (bottom), and (iii) the pseudo-contracts to be run by the MPC, on demand (top right). We call them pseudo-contracts as they are written in the MPC bytecode rather than the EVM bytecode; nevertheless, these two have an equivalent functionality and will be merged in a later stage.

To be able to submit private data, the users must onboard first (Step 1), this means that they ask the system to generate their associated key material. Then, users submit their private data to the system in an encrypted state (Step 2). This is important as the part of the system that stores this Encrypted Data may be completely visible to anyone. Finally any user may submit a workload (Step 3) that will securely operate on the Encrypted Data and output the result (Step 4). The workload is submitted in the supported MPC bytecode format, which includes operations like adding, multiplying, and XORing on the secrets, but without revealing the secrets. The output resulting in Step 4 may be either public (a.k.a plaintext), which means that everyone can see the output, or encrypted under some user’s key, which means that only that user can see the output (by decrypting it using its own key).

Delving Into an MPC Endpoint

Let’s have a closer look at the contents held by the nodes by inspecting the internals of the first node. On the left side we have the internal of the node right before launching the execution of a workload. The top frame contains the key material associated with the users. Note that these pieces of information are only Shamir shares of the actual key belonging to each user. For instance, the hexadecimal string following appearing beside Alice’s name is just a random string that reveals no information at all about the actual key of Alice; only when combining the shares from all MPC endpoints should the actual key be exposed. Then, the middle frame contains encrypted data that is to be fed to the workload in the bottom frame. Each data item is accompanied with the type (in this example the data items only differ in their bit-length).

On the right we have the state of the node post-execution. Note that everything remains the same except the addition of the yellow frame, which contains three private variables, e,d, and gt, that are encrypted under the network key (a key that is secret shared and maintained by the MPC nodes). These three variables are defined to be output of the computation; they will be added to the updated private state of the system and be readily available for further workloads. All other variables that were generated during the execution of the workload are “intermediate” and are deleted right after the execution. Note that a contract may also define an output to be “owned” by one of the users, which means that this output will not be encrypted by the network key, rather, it will be encrypted under that user. This means that in order to get the plain output, that user only has to read the updated state from the system, retrieve this output and decrypt it using its own key.

The process above consists of multiple steps:

Deploying the MPC module on the Endpoints
Generating a simulated state with:

A list of clients (Alice, Bob, etc.) and their associated cryptographic keys.
A pseudo-contract — a text file containing a list of operations to be performed on encrypted and public inputs as well as the already existing system state.
A list of encrypted inputs belonging to the above clients.

3. Loading the generated state to the MPC module. The internal view of the MPC module by each endpoint is similar to what illustrated above (left side).

4. Triggering the MPC module to execute the pseudo-contract over the encrypted inputs (and saving the outputs, either encrypted or not). The internal view of the MPC module post execution is similar to what illustrated above (right side).

5. Retrieving all outputs such that each client is able to decrypt only the outputs intended to it (using its own decryption key).

On the Garbling Protocol

The submission of workload to the MPC module in fact triggers the collaborative generation of a cryptographic primitive called Garbled Circuit. This Garbled Circuit represents a function to run, or in our context, a pseudo-contract (also called workload above) to run. This procedure that translates from a pseudo-contract to a garbled circuit is called Garbling. We note that the garbled circuit representing one pseudo-contract cannot represent another pseudo-contract, and right after its execution it is deemed useless. A new garbled circuit has to be generated for the next execution. This fact is important for security, as honest MPC nodes will delete the already used garbled circuits, meaning that the system achieves forward and backward secrecy by design.

Once the garbled circuit generation is completed, the system is ready to be triggered and securely execute the pseudo-contract. This process is called garbled circuit evaluation. The evaluation process already returns the outputs mentioned above (variables `e’, `d’ and `gt’ in the illustration), either encrypted or not.

To elucidate, the garbled circuit, once utilized for executing a pseudo-contract, cannot be repurposed due to its design. The practice of garbling transforms the pseudo-contract into a one-time, executable cryptographic blueprint, ensuring that each transaction remains insulated from others. This architecture not only fortifies the system against potential security breaches but also establishes a protocol where privacy is inherently built into the computational process.

Everything Achieved in Milestone 1

The design and algorithms of the MPC protocol
The implementation of the MPC protocol
Demonstrate the successful input and output of secret data by users, which:

Includes the design/decision of the adequate encryption scheme.
Incorporates the ability to ‘onboard’ encrypted data by the MPC endpoints and to ‘offboard’ data to everyone or to a specific user. This includes the ability to perform special operations like encryption and decryption of values, using a distributed key that is unknown in its entirety to any single node.

One Milestone Down, More to Come!

The creation and implementation of a secure MPC protocol is the first of many development milestones we’ll reach throughout the year. Stay tuned for further COTI V2 updates as development continues.