Skip to content

Latest commit

 

History

History
194 lines (149 loc) · 6.21 KB

rfc-12-keep-network-interface.adoc

File metadata and controls

194 lines (149 loc) · 6.21 KB

RFC 12: Keep Network application interface

1. Proposal

This document specifies how applications interact with Keep Network.

1.1. Terminology

Application

Application is an external smart contract or a set of smart contracts utilizing functionalities offered by Keep Network.

a keep

A keep is a smart contract used by an application to perform some work. It is a privacy primitive enabling secure storage and usage of secrets.

sMPC cluster

A keep can have off-chain clients executing work for a keep. Off-chain clients serving a keep together form an sMPC cluster. An sMPC cluster observes state of a keep and reacts appropriately.

Keep Network

The Keep network consists of all stakers, all keeps and associated sMPC clusters, and the random beacon.

KEEP

KEEP is an ERC-20 work token used to stake in the Keep network. A minimum staked value is required for operator to join sMPC cluster.

Keep Core

Keep Core consist of a set of on-chain contracts and off-chain sMPC cluster providing the functionality of random beacon and KEEP token along with all stake management interfaces.

tECDSA

Threshold Elliptic Curve Digital Signature Algorithm.

Bond

A bond is collateral provided by a keep operator that disincentivizes collusion and misbehavior. Bond may get slashed or seized in case of malicious behaviour of the operator.

1.2. Goal

The goal of this proposal is to specify the interface between an application and the keeps atop which the application is built. This proposal specifies the mechanism of creating and registering keeps. This proposal introduces two types of keeps: tECDSA keep and Bonded tECDSA keep. Those keeps are just the first two types of keeps which are going to be offered by Keep Network. All components described in this proposal meet the requirements described in the RFC 9 addressing upgradeability mechanics.

1.2.1. sMPC cluster requirements

Each off-chain client of sMPC cluster should be a separate process. Keep Core client should be a separate client than Keep tECDSA client:

./keep-core
./keep-tecdsa

(The above snippet is just an example for the first keep type)

Each staker is required to run Keep Core client. Running Keep tECDSA client is optional. Eventually, we hope other developers will build their own clients.

1.2.2. Bonding requirement

Some applications requires a bond to be provided by stakers. Stakers who want to participate in the given protocol need to opt-in and provide the required bond. A bond can be provided in ETH or ERC-20 token specific to the application.

1.3. Types of keeps

There are two first types of keeps that are going to be offered by Keep Network: tECDSA keep and bonded tECDSA keep.

tECDSA keep

tECDSA keep is a type of a keep allowing to sign data with a uniquely generated private key for each new keep instance. Key generation and signing are based on trustless, threshold protocols executed by groups of signers forming an sMPC cluster for this type of a keep.

bonded tECDSA keep

bonded tECDSA keep is a tECDSA keep with an extra bonding logic over a vanilla tECDSA keep. Each staker being a part of sMPC cluster for this type of keep needs to provide an extra bond required for each new instance of bonded tECDSA keep. The bond can be slashed as a result of inactivity or misbehaviour during tECDSA key generation or signing.

1.4. Implementation

1.4.1. Keep factory

Keep factory is a smart contract used to create instances of a keep of a certain type. Each type of keep has a separate keep factory. Each keep factory is an operator contract and has to be sanctioned by stakers as such. Application developers may interact with factory directly if they decide to. The network can not guarantee that old factories will be still backed up by enough stakers, though.

1.4.2. Vendor

A vendor is a smart contract with which the application interacts to obtain the new instance of a keep of the given type backed by enough stakers so that all operations on the created keep can go smoothly. Vendor interacts with keep factories choosing the one most recent if it is backed by enough stakers. Each vendor is a service contract and does not have to be sanctioned by stakers. Each vendor can operate on several versions of keep factory to allow for a smooth upgrade process.

1.4.3. Keep registry

The keep registry serves the role of the master list (see RFC 11 for more details) and tracks sanctioned staking contracts, operator contracts (including keep factories) and vendors. It ensures that only approved contracts are used. A new type of keep can be added without upgradeable registry.

1.5. Pseudocode

1.5.1. ECDSA keep vendor

contract ECDSAKeepVendor {
    address[] internal _factories;

    function openKeep(
        uint256 threshold,
        uint256 groupSize,
        address owner
    ) returns (address) {
        address factory = selectFactory()
        return ECDSAKeepFactory(factory).openKeep(
            threshold, groupSize, owner
        )
    }
}

1.5.2. ECDSA keep factory

contract ECDSAKeepFactory {
    function openKeep(
        uint256 threshold,
        uint256 groupSize,
        address owner
    ) returns (address) {
        address keep = new ECDSAKeep(
            selectGroup(threshold, groupSize),
            owner
        );

        return keep;
    }
}

1.5.3. ECDSA keep

contract ECDSAKeep {

    function sign() {
        require(msg.sender == _owner, "Only keep owner can ask to sign");
        // (...)
    }
}

1.5.4. Keep registry

contract KeepRegistry {

    function getKeepVendor(string keepType) address {
        // (...)
    }
}

1.5.5. Application

contract Application {
    address internal _keepRegistry;

    function openDeposit() {
        address vendor = KeepRegistry(_keepRegistry).getKeepVendor("ECDSA")
        vendor.openKeep(
            threshold,
            groupSize,
            bond
        );

        // (...)
    }
}