How we built 180Protocol with Conclave to enable secure multi-party computation

This post is authored by Parth Shukla (180Protocol).

‍

180Protocol is building collaboration software for the next generation of enterprise. Our goal is to create a world with connected enterprises, powered by the exchange of data.

“Data is both a key driver for value creation and business performance, but also one of the most underleveraged and misunderstood assets corporations possess. It’s largely unmeasured, mismanaged, and underutilised. Its vast potential is not being realised”, says the World Economic Forum.

Our goal is to change that and create a world with connected enterprise, powered by the exchange of data. At 180Protocol, we believe that business data is of immense value, and especially so if aggregated. So, we are creating an infrastructure for creating enterprise data unions - networks of organisations that have come together for the purpose of sharing and aggregating sensitive data to enable enterprise.

Data unions will remove barriers and encourage data sharing amongst enterprises leading to increased business intelligence and commercialisation of data assets.

Why 180Protocol?

A significant portion of enterprise data is private and cannot be shared outside the organisation. There are strong intra-organisational controls preventing data misuse and access that help keep enterprise data secure. However, this means data is locked in silos causing value in private enterprise data to be underutilised.

Further, enterprises only collaborate when there is trust and they can control use of their private data and benefit fairly from its deployment. Hence, there is a need for governance around data structures, data access and the resulting value flows.

180Protocol solves for these needs by introducing the concept of enterprise data unions – enabling the creation of new applications leveraging new data insights and sharing the rewards from its consumption.

What is 180Protocol?

180Protocol is comprised of the following components:

• Aggregator SDK: – A developer toolkit that includes a set of configurable workflows to coordinate multi-party computations on private and public data and data analytics interface built upon a trusted execution environment (TEE) that can take flexible inputs from Data Providers and produce outputs for Data Consumers.
• 180Dashboard: A front-end application that allows Data Providers and Data Consumers to keep track of shared data and rewards for each data aggregation.
• Codaptor: A middleware that connects to the Corda RPC and generates OpenAPI bindings automatically for any CorDapp.

Confidential applications built with 180Protocol can leverage the power of DLT via R3 Corda and the security of confidential computing via R3 Conclave, alongside other core technologies.

Our journey to build 180Protocol

180Protocol’s vision is to create a toolkit that enables developers and enterprises to create unique data insights using secure multi-party computation. Our technology has –

• Configurability: It provides data input to output transformations and reward algorithms.
• Control: It gives governance over the use of data, membership, and rules of operation.
• Security: Our workflows to aggregate data handle private data securely.
• Modularity: Our SDKs support easy extensibility.

Since 180Protocol allows enterprises to collaborate securely, we require an audit and trust layer to record data sharing workflows and resulting rewards. 180Protocol utilises R3 Corda to fulfil this requirement. Corda is a private permissioned ledger that allows enterprises to transact immutably and securely with known actors.

We also built a toolkit to deploy application logic and communicate securely with the TEE, also called enclave. R3 Conclave is a good fit due to its secure and simple enclave messaging API called Mail, the ability to deploy native JVM code into the enclave. Other features like a local secure persistent file store, or its Key Derivation Service (KDS) also added to the appeal of Conclave as our first enclave messaging and deployment layer.

We started developing 180Protocol in December 2020 and we integrated it with Conclave since its 0.4 beta release in February 2021. We have been able to work with successive releases of Conclave from its beta to the current 1.2 release. After a year of development, we launched 180Protocol on our GitHub in January 2022.

Secure workflows powered by enclaves

We have utilised Conclave as a foundational technology for configurable multi-party computations (MPC). Several key features are worth highlighting:

• Dynamic serialisation: 180Protocol supports dynamic serialisation for getting data in and out of the enclave. Dynamic serialisation allows configuring input/output data structures to fit any use case. Developers can simply override the enclave data interface with rewards and output calculations logic. There is no need to rewrite any core workflows. We achieved this by abstracting away any data structure specifics in our workflows and using Apache Avro as the serialisation mechanism to get data in and out of the enclave.
• Mail API: We utilise the Conclave Mail API to manage secure communication between the clients and the enclave. Mail allows easy encryption and decryption of private messages between clients and the enclave, enabling security of the sensitive data in transit and only allowing the enclave to view sensitive data.
• Rewards engine: 180Protocol have developed a proprietary rewards engine that runs inside the enclave, evaluating the data shared by each data provider during data aggregation workflows. Provider data is decrypted only inside the enclave and scored on factors including completeness, uniqueness, amount provided and update frequency. This score is recorded on the Corda ledger for each provider and can be redeemed for rewards.
• Secure workflows: 180Protocol Aggregator SDK ships with a consumer aggregation workflow that allows data consumers to pull pre-approved data from data providers in the union. Developers simply need to configure input/output data structures and can start using our SDK with minimal configurations. All enclave specific actions like attestation, key management, encryption, and decryption are handled by our workflows making enclave development easy.
• Governance: 180Protocol allows members to govern the structure and behaviour of the union. Members can manage support for new kinds of data aggregations, manage memberships and roles, and support a variety of applications and use cases utilising the data aggregations. Governance is directly proportional to the number of rewards that members earn by sharing their data and participating in aggregations.
• Modularity for extension: 180Protocol is a modular toolkit for developers to build data unions. As described earlier, 180Protocol is composed of the Aggregator SDK, the Codaptor and the 180Dashboard. These can be decoupled and used by developers independently as per their unique needs. Further, the Aggregator SDK is modularized and composed of enclave, workflow, and contracts modules – each of which can be extended by developers to suit their unique use cases.
• Use cases: 180Protocol supports a variety of use cases like distributed analytics, or aggregated supply/demand landscapes, decentralized marketplaces, knowledge networks, give to get data sharing, and silent auction protocols.

There is an array of new features on our roadmap including integrating 180Protocol with Filecoin as our decentralized storage layer for input/output data, improving our rewards engine to be more intelligent (regression based), and integrating a layer 1 to enable a circular economy for rewards. Our roadmap is focused on making data unions scalable and incentive aligned.

We invite developers and enterprises to go to our GitHub page and utilise our SDKs to build the next generation of secure collaborative applications.