Skip to content

The smart contracts and reference client behind the Keep network

License

Notifications You must be signed in to change notification settings

rumblefishdev/keep-core

 
 

Repository files navigation

keep-core

CircleCI Build Status Chat with us on Discord

The core contracts and reference client implementation behind the Keep network, a privacy, interoperability, and censorship-resistance toolkit for developers on Ethereum.

What’s a keep?

The network offers application developers keeps, small off-chain data containers for private storage and computation that can be opened, closed, and managed by smart contracts autonomously.

Keeps are maintained by stakers, actors who run nodes and have skin in the game, and collect fees for operating the network. When a new keep is opened, the requisite number of stakers are chosen via a BLS-based random beacon to maintain the keep, using a process called sortition.

The first type of keep launching with the network is the BondedECDSAKeep, allowing smart contracts to generate private keys and sign messages without endangering key material. ECDSA keeps mean decentralized signing, cross-chain applications, and new tools for custodial applications — from Solidity. This capability is used heavily by tBTC.

To learn more about ECDSA keeps, check out keep-ecdsa.

Getting Started

A good place to start is the the docs directory.

Running a Node

To run your own node in the Keep network, follow the run Random Beacon doc. Feedback on this process and the documentation is appreciated!

dApp Developers

dApp developers will be most interested in the smart contracts exposing Keep’s on-chain facilities.

The core contracts can be found in the solidity/ directory. They can be used to request miner-resistant random numbers, as well as creating and managing keeps. To generate new ECDSA key material and request signatures, the contracts can be found in keep-ecdsa.

Client Developers

Client developers will be most interested in the reference Keep Go client and CONTRIBUTORS file, as well as the RFCs and repo directory structure 👇

Directory structure

The directory structure used in this repository is very similar to that used in other Go projects:

keep-core/
  Dockerfile
  main.go, *.go
  docs/
  solidity/ (1)
  cmd/ (2)
  pkg/ (3)
    net/
      net.go, *.go (4)
      libp2p/
    chain/
      chain.go, *.go (4)
      ethereum/
        gen/
          gen.go (5)
    relay/
      relay.go, *.go
  1. While the Keep network only uses Solidity at the moment, the directory structure allows for other contract languages.

  2. Keep client subcommands are implemented here, though they should be minimal and deal solely with user interaction. The meat of the commands should exist in a package fit for the appropriate purpose.

  3. All additional packages live in pkg/.

  4. The high-level interfaces for a package mypackage live in mypackage.go. net and chain are interface packages that expose a common interface to network and blockchain layers. Their subpackages provide particular implementations of these common interfaces. Only cmd/ and the main package should interact with the implementations directly.

  5. When a package requires generated code, it should have a subpackage named gen/. This subpackage should contain a single file, gen.go, with a // go:generate annotation to trigger appropriate code generation. All code generation is done with a single invocation of go generate at build time.

About

The smart contracts and reference client behind the Keep network

Resources

License

Security policy

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Go 57.0%
  • JavaScript 28.6%
  • Solidity 10.4%
  • Less 1.8%
  • HCL 1.2%
  • Shell 0.7%
  • Other 0.3%