keep-network / keep-ecdsa Goto Github PK

After receiving unsigned BTC raw transaction we need to:

• calculate a signature for the transaction's input
• produce a witness containing the signature
• add the witness to the transaction
• publish the signed transaction to a chain

Migrate to go modules feature to manage dependencies.

Start with a mock throwaway implementation while a proper design is drawn up (ticketing? Fully on-chain?), then implement the real thing.

Refs: keep-network/tbtc#335

Estimate:

• mock: 2pt
• design: 4pt
• implementation: 8pt
  Total: 14pt

So far transactions are signed with CLI tool (see #2). This issue aims at exposing on-chain contract interface for publishing signature requests and implementing client code serving those requests.

Implement group teardown (destroying private key material, etc).

Question:

• How crucial is doing this “right” vs just cleaning up? No design if it's just cleanup.

Refs: keep-network/tbtc#335

Estimate:

• design: 2pt
• implementation: 4pt
  Total: 6pt

Once BTC transaction hash is signed (see #2), it should be published to the BTC network.

Tasks:

• send a raw transaction to electrum - #10
• send a raw transaction to one of exposed public APIs - #11

Temporary solution for the first milestone.

Expose a temporary function for keep client to register in the factory. When creating keeps, factory will randomize which members are in the keep (temporary solution). Already registered clients will not be registered again. We don't add any client shutdown/removal feature now. All clients registered are supposed to run forever.

--
Implementer: @nkuba
Feature buddy: @pdyraga

Implement unit tests for solidity contracts.

So far single ECDSA signer is created based on CLI request (see #2). This issue aims at exposing on-chain contract interface for publishing group generation requests and implementing client code serving those requests.

• on-chain contract with a stub implementation - #21
• off-chain code serving requests - #19
• smoke test validating on-chain and off-chain integration - #22

From: #46 (comment):

Refactor how clients attach to OnSignatureRequested. Newly started keep client should read the information about the keeps its member of from disk and attach toSignatureRequestedEvent. It should not happen inside OnECDSAKeepCreated callback.

--
Implementer: @nkuba
Feature buddy: @liamzebedee @pdyraga

Currently, in a factory, we select a hardcoded address as a keep member. We need to register a member (off-chain client) on chain and pass it to the keep.

--
Implementer: @nkuba
Feature buddy: @pdyraga

Add integration test execution to the CI process.

--
Implementer: @liamzebedee
Feature buddy: @nkuba

Implement keep formation and DKG messaging with libp2p.

Refs: keep-network/tbtc#335
Estimate: 4pt

Implement key generation stage execution. This task covers key generation (Phases 1-3) of the protocol with tss-lib library.

Refs: keep-network/tbtc#335
Estimate: 2pt

Integrate protocol executor with ECDSA keep client.

Depends on: https://github.com/keep-network/tbtc/issues/351
Refs: keep-network/tbtc#335
Estimate: 4pt

Implement a smoke test to be able to sanity check ECDSA keep client and tECDSA protocol execution. The test should be executable via the command line.

Refs: keep-network/tbtc#335
Estimate: 4pt

We need to figure out how to integrate keep-core chain contract Go code generators and chain-specific interfaces into keep-tecdsa to avoid code duplication.

This card covers all the work required to remove code duplication and to refer to the same codebase.

Based on: #46 (comment)

A bit off-topic but I wonder if this code should live in tecdsa/tecdsa.go. I know it's a pattern we incorporated from keep-core but when I look at it now, with a fresh view, I'd expect to have tECDSA protocol related code in this file and to have client initialization code living in e.g. client/tecdsa.go.

--
Implementer: @nkuba
Feature buddy: @pdyraga

In the ECDSA keep contract we need to emit an event about the signature request. This event should be caught by clients later.

On-chain:

• emit an event from ECDSAKeep contract

Off-chain:

• add a function to register a callback on the event in chain interface (eth/chain.go)
• implement the registration function in ethereum package
• register a callback in client initialization in tecdsa.go - print a received event
• local chain implementation of OnSignatureRequested function - discussion

Test:

• manual test event emission and catching the event in the client

See: https://github.com/keep-network/keep-tecdsa/blob/master/solidity/contracts/ECDSAKeep.sol#L29

--
Implementer: @liamzebedee
Feature buddy: @nkuba

Investigate Binance's implementation of Multi-Party Threshold Signature Scheme for ECDSA.

Analyze [GG19] protocol coverage, audit results and the possibility to use the lib for our needs.

[GG19]: Fast Multiparty Threshold ECDSA with Fast Trustless Setup, R. Gennaro, S. Goldfeder, https://eprint.iacr.org/2019/114.pdf

Refs: keep-network/tbtc#335
Estimate: 4pt

Deploy keep-tecdsa client along with smart contracts to private testnet.

• Deploy contracts
• Update config.toml with contract addresses
• Deploy off-chain client

https://github.com/keep-network/tbtc/blob/master/implementation/demo/README.md#keep-tecdsa

Disclaimer: private key of signer is hardcoded in the toml file. We know about that and it is fine for now. We deploy it to testnet only. We'll alter it later with a proper solution.

Closes #48

Configure linters for Solidity and JS.

Implementer: @liamzebedee
Feature buddy: @nkuba

In truffle.js:

require('@babel/register');
require('@babel/polyfill');

In package.json we've got babel-polyfill as a dependency. Simple change, npm i @babel/polyfill to fix.

(base) ➜  keep-tecdsa git:(master) ✗ yarn build  yarn run v1.17.3
$ truffle compile
Error: Cannot find module '@babel/polyfill'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Module.require (internal/modules/cjs/loader.js:690:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (/Users/liamz/go/src/github.com/keep-network/keep-tecdsa/truffle.js:10:1)
    at Module._compile (internal/modules/cjs/loader.js:776:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Module.require (internal/modules/cjs/loader.js:690:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Function.Config.load (/Users/liamz/go/src/github.com/keep-network/keep-tecdsa/node_modules/truffle/build/webpack:/packages/config/index.js:163:1)
    at Function.Config.detect (/Users/liamz/go/src/github.com/keep-network/keep-tecdsa/node_modules/truffle/build/webpack:/packages/config/index.js:148:1)
    at Object.run (/Users/liamz/go/src/github.com/keep-network/keep-tecdsa/node_modules/truffle/build/webpack:/packages/core/lib/commands/compile.js:53:1)
    at Command.run (/Users/liamz/go/src/github.com/keep-network/keep-tecdsa/node_modules/truffle/build/webpack:/packages/core/lib/command.js:141:1)
    at Object.command.command (/Users/liamz/go/src/github.com/keep-network/keep-tecdsa/node_modules/truffle/build/webpack:/packages/core/cli.js:52:1)
    at __webpack_require__ (/Users/liamz/go/src/github.com/keep-network/keep-tecdsa/node_modules/truffle/build/webpack:/webpack/bootstrap 4db1b0bede5830219203:19:1)
    at /Users/liamz/go/src/github.com/keep-network/keep-tecdsa/node_modules/truffle/build/webpack:/webpack/bootstrap 4db1b0bede5830219203:65:1
    at Object.<anonymous> (/Users/liamz/go/src/github.com/keep-network/keep-tecdsa/node_modules/truffle/build/cli.bundled.js:71:10)
    at Module._compile (internal/modules/cjs/loader.js:776:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
Truffle v5.0.38 (core: 5.0.38)
Node v10.16.0
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Update architecture to reflect propsal from RFC 12.

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.

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.

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.

Pseudocode

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
        )
    }
}

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;
    }
}

ECDSA keep

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

Keep registry

contract KeepRegistry {

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

Application

contract Application {
    address internal _keepRegistry;

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

        // (...)
    }
}

Implementer: @nkuba
Feature Buddy: @pdyraga

Implement signing stage messaging with libp2p.

Refs: keep-network/tbtc#335
Estimate: 4pt

Goal is to have a fully functional economics complete random beacon integration. This is the final step of the integration.

8 pts

Implement an execution mechanism for tECDSA protocol.
Include tss-lib setup.

Refs: keep-network/tbtc#335
Estimate: 4pt

As mentioned in last paragraph of tss-lib: How To Use This Securely:

Timeouts and errors should be handled by your application. The method WaitingFor may be called on a Party to get the set of other parties that it is still waiting for messages from. You may also get the set of culprit parties that caused an error from a *tss.Error.

Refs: keep-network/tbtc#335
Estimate: 4pt

Ensure the security of contracts with appropriate ACL for communication between ECDSAKeep, owner, and members.

• submit public key
• submit signature
• sign

Test how it works with tBTC - call from Deposit contract.

--
Implementer: @NicholasDotSol
Feature buddy: @nkuba

Store and read information about keep membership and private key on disk in an encrypted form.

Preferably, use the same code as in keep-core extracting persistence package to keep-common.

--
Implementer: @nkuba
Feature buddy: @pdyraga

Transport layer should fulfill requirements mentioned by Binance:

• broadcast and point-to-point communication
• end-to-end encryption
• enforce session ID handling
• reliable broadcasts

When you build a transport, it should should offer a broadcast channel as well as point-to-point channels connecting every pair of parties. Your transport should also employ suitable end-to-end encryption (TLS with an AEAD cipher is recommended) between parties to ensure that a party can only read the messages sent to it.

Within your transport, each message should be wrapped with a session ID that is unique to a single run of the keygen, signing or re-sharing rounds. This session ID should be agreed upon out-of-band and known only by the participating parties before the rounds begin. Upon receiving any message, your program should make sure that the received session ID matches the one that was agreed upon at the start.

Additionally, there should be a mechanism in your transport to allow for "reliable broadcasts", meaning parties can broadcast a message to other parties such that it's guaranteed that each one receives the same message. There are several examples of algorithms online that do this by sharing and comparing hashes of received messages.

Some of the above are covered out of the box by libp2p.

Refs: keep-network/tbtc#335
Estimate: 8pt

Implement ETH and ERC20 distribution to a keep members from IKeep interface.

// Allow sending tokens to a keep group
// Useful for sending signers their Tokens
// The Keep contract should call transferFrom on the token contract
function distributeERC20ToKeepGroup(uint256 _keepID, address _asset, uint256 _value) external returns (bool);

function distributeEthToKeepGroup(address _keepAddress) external payable returns (bool){
    //TODO: Implement
    return false;
}

Publish a generated signer's public key to the chain. Store it in keep.

• on-chain contract update - #33
• off-chain publication handling - #32

Once the requested transaction is signed, we should publish signature to the chain so that anyone can broadcast this transaction to BTC network.

--
Implementer: @nkuba
Feature buddy: @liamzebedee @pdyraga

Having a separate contract to collect rewards might be a better option. If we can maintain linear time complexity it should be the cheapest option per capita (after a certain amount of accumulated reward) and generally more secure as it follows the pull model.

Chain functions should return promises. To generate promises we should use keep-common library as per example in keep-network/keep-core#1049.

Code and CLI command for a single ECDSA signer. Should accept transaction hash and produce an ECDSA signature over that hash.

• use logger

  Based on suggestion from #46 (comment) use logger defined in keep-core.

  That said, you already transiently depend on the relevant bits via keep-core, and a shared library probably would as well. Worth noting that, for the packages themselves, keep-core doesn't add anything---we just directly use the IPFS logger, typically declaring one logger per package and then using it as needed.

  The place where we've got custom code is around managing the logging: https://github.com/keep-network/keep-core/blob/master/logging.go . This will need to be pulled out to a common lib of some sort, as it's not even publicly exposed right now.

• fix messages

  We should also review logged messages (as per #46 (comment)) and make them respect rules defined in keep-network/keep-core#917:

  <action> <content>: [<error>]
  

  e.g.:

  "failed while creating directory [%v]: [%v]",
   <action>        <content>           : [<error>]
  

  When there is no error, there may not be a trailing colon. These are not
  complete sentences, and they are neither capitalized nor do they end
  with periods.

Implement signing stage execution. This task covers signing (Phases 1-5 of the protocol) with tss-lib library.

Refs: keep-network/tbtc#335
Estimate: 2pt

Beacon is hooked up instead of stub randomness. -> may need some extra support from the beacon team.

4 pts

In GitHub action for solidity contracts package publication in a package registry, we bump up the package version and Mr. @thesis-heimdall commits the changes. This automatic commit is unsigned right now. We need to configure it to be signed.

Upgrade version of used libp2p and adapt the code.

This task requires cooperation with @pdyraga and the beacon team.

Refs: keep-network/tbtc#335
Estimate: 8pt

It does not have to be solved in this PR but... why don't we do btc.Interface exactly as we have eth.Interface and make PublicKeyToWitnessPubKeyHashAddress a part of btc.Interface? This way we'll avoid passing chaincfg.Params to initialize function which is ugly.

Originally posted by @pdyraga in https://github.com/keep-network/keep-tecdsa/pull/24/files

TBTC Deposit contract forwards value for Keep creation. TECDSA Keep should handle the payment

Currently, ethereum account private key is expected to be provided as plaintext in the config file. We need to replace this solution by reading the key from a file.

--
Implementer: @nkuba
Feature buddy: @pdyraga

Read and understand Fast tECDSA paper by R. Gennaro and S. Goldfeder.

Refs: keep-network/tbtc#335
Estimate: 4pt

Main questions here:

• Do we maintain keep-tecdsa as separate?
• Do we plug directly into keep-core?
• If separate, how do we manage the dependency?

Refs: keep-network/tbtc#335
Estimate: 4 pt

Rename keep-tecdsa repository to keep-ecdsa. The keep will be called ECDSAKeep so repository name should reflect that.

Instead of a CLI tool, tECDSA Keep should now work as a client. It should be started with ./keep-tecdsa command.