Common Interest Protocol
What is it?
The Common Interest Protocol (CIP) for Stakehouse is the first application of dCommon’s programable MPC network dedicated to decentralized and trustless backup and recovery of a validator signing key.
An in-depth description of protocol mechanics can be found in the MPC as a service using Ethereum Registry Smart Contracts - dCommon CIP paper.
Architecture
The Common Interest Protocol for Stakehouse is composed of SafeBox and DKGRegistry smart contracts, an off-chain MPC solver network that runs a Cryptography client. Additionally, it utilizes Stakehouse protocol’s Collateralized SLOT Registry for user authentication for Key recovery and MPC solver registration. This allows the contract to tokenize ownership identity for key recovery.
SafeBox
SafeBox is a contract dedicated to orchestrating MPC solvers, driving decryption actions, and making decryption ownership decisions based on collateralized SLOT ownership (read about Collateralized SLOT registry).
The core functionality of the SafeBox smart contract is to ensure the iron rule of KNOT health (not slashed == has 8 SLOT balance at the time of the request). Subsequently the owner is authenticated (has more than 2 collateralized SLOT tokens), and no current decryption request for the specified KNOT is active. When the aforementioned checks are completed, the decryption request is broadcasted to the off-chain MPC solvers in the form of an Ethereum event.
Distributed Key Generation (DKG) Registry
DKG Registry is a contract to facilitate the Distributed Key Generation (DKG) for setting up a dedicated MPC solver network for Stakehouse CIP application. It only allows protocol users to become an MPC solver abiding by a unique rule of registration and continuous solver credential validation. The main function of the DKG Registry contract is to keep track of the initial set of participants and resulting solvers. It also enforces time boundaries for each round and ensures the key generation process is sequential.
Although in-depth discussion of the DKG process is outside the scope of this document, it is worth mentioning that the purpose of the process is meant to generate and hold a set of disjoint and distributed credentials. The purpose of DKG credentials is to form partial decryption solutions that are used to facilitate the validator signing key recovery process. It is worth noting that DKG credentials are individually insufficient for signing key recovery and the majority of the solvers (T out of N) need to participate in the recovery procedure in order to obtain the signing key.
Solver Client
The solver client is an off-chain piece of software meant to listen to broadcasted decryption requests via SafeBox smart contract. It computes a partial decryption solution for the requested validator. At no point do the solvers require the encrypted ciphertext of the validator signing key in order to perform their operations.
Additionally, the software is also used in the DKG procedure for the network initialization step to generate the shared credentials for solvers to perform MPC operations.
Cryptography Module
The cryptography module is an off-chain software package abstracting all important cryptographic and computational operations like Hybrid Key generation, NiZK (Non-Interactive Zero Knowledge) proof formation/validation, and Distributed Credential logistics.
The module is implemented in the form of a node js package, but can take the form of any software shape.
Collateralized SLOT Registry
Collateralized SLOT Registry is utilized as a sub-registry of SLOT registry representing ownership and management rights of a Stakehouse protocol KNOT. This portion of SLOT is non-transferrable and initially assigned to the user who registered the BLS Key during the staking. A detailed writeup of tier SLOT ownership can be found in the position paper; Collateralized SLOT’s unique characteristics and controlling rights forms the basis of identity in the CIP for Stakehouse application. It ensures sufficient resilience for the protocol with the high capital barrier being malicious. The key criteria to broadcast the key recovery request to the MPC solver network is having a minimum of 2 collateralized SLOT tokens for the desired KNOT. MPC Solvers will require ownership of 1 SLOT.
Signing key Recovery
A high-level overview of the signing key recovery is performed as follows.
First, the validator owner generates the hybrid key pair in order to establish a private communication channel with the solvers. Then, it posts the hybrid public key to the SafeBox smart contract. SafeBox contract then checks if the user has (more than 2) collateralized SLOT tokens for the validator and if the condition is satisfied, the decryption request is broadcasted to the MPC solver network.
Further, solvers independently compute a partial decryption solution and post the encrypted version to the SafeBox bulletin board. The user that requested recovery then fetches the encrypted partial decryption solutions together with the ciphertext from the blockchain, decrypts them using their recovery key, assembles the hybrid private key, and unlocks the ciphertext.
A high-level description of the recovery process can be seen below:
