#entropy #threshold-signature #user #testing #store #tss #protocols

no-std bin+lib entropy-tss

Entropy threshold signature scheme (TSS) server

2 unstable releases

new 0.1.0-rc.1 May 15, 2024
0.0.0 Jan 4, 2024

#2290 in Magic Beans

Download history 2/week @ 2024-02-15 6/week @ 2024-02-22 3/week @ 2024-02-29 9/week @ 2024-03-28 8/week @ 2024-04-04

78 downloads per month
Used in 2 crates (via entropy-testing-utils)

AGPL-3.0-or-later

605KB
8K SLoC

entropy-tss

The threshold signature server which stores keyshares and executes the Entropy protocols.

Running integrations tests for the JS bindings to the entropy-protocol private user API

cd crates/protocol
make build-nodejs-testing
cd nodejs-test
yarn
cd ../../..
cargo test -p entropy-tss --release -F wasm_test test_wasm

If you have issues when re-running these tests following changes, remove nodejs-test/node_modules before re-running yarn.


lib.rs:

Server

The Threshold Server which stores key shares and participates in the signing protocol.

Overview

This exposes a HTTP API.

The HTTP endpoints

Some endpoints are designed to be called by the user, some by the entropy chain node, and some by other instances of server:

For the user

Most user-facing endpoints take a SignedMessage which is an encrypted, signed message.

/user/sign_tx - POST

[crate::user::api::sign_tx()]

Called by a user to submit a transaction to sign (the new way of doing signing). Takes a [UserSignatureRequest] encrypted in a SignedMessage.

The response is chunked response stream. If the UserSignatureRequest could be processed, a success response header is sent. Then the signing protocol runs. When the it finishes, a single message will be sent on the response stream with the result.

If everything went well, the message will be a JSON object with a signle property "Ok" containing an array which contains two strings.

For example:

{"Ok":["t7Mcxfdigds3RoT6OO/P+uMFE+XigRjUpn72E1cRU4Q2u7cVxZlsNRYhnahA+DvSNHBddj0HRz5u/XPlJT9QOQE=","32d7c0bfd90b546993d1ad51c542e1fc9dd1706c7bca395c8bd7f9642ae842400769488404dabd25d438cf08785a6750f95e7489245b8760af115f450d5f0a83"]}

The first string is a base64 encoded signature produced by the signing protocol. This is a 65 byte signature, the final byte of which is a recovery ID.

The second string is a hex encoded sr25519 signature of the signature made by the TSS server, which can be used to authenticate that this response really came from this TSS server.

In case signing was not successfull, the message will be a JSON object with a signle property "Err" containing an error message, for example:

{"Err":"reqwest event error: Invalid status code: 500 Internal Server Error"}

Curl example for user/sign_tx:

curl -X POST -H "Content-Type: application/json" \
  -d '{"msg" "0x174...hex encoded signedmessage...","sig":"821754409744cbb878b44bd1e3dc575a4ea721e12d781b074fcdb808fc79fd33dd1928b1a281c0b6261a30536a7c0106a102f27dad1bc3ef475b626f0e57c983","pk":[172,133,159,138,33,110,235,27,50,11,76,118,209,24,218,61,116,7,250,82,52,132,208,169,128,18,109,59,77,13,34,10],"recip":[10,192,41,240,184,83,178,59,237,101,45,109,13,230,155,124,195,141,148,249,55,50,238,252,133,181,134,30,144,247,58,34],"a":[169,94,23,7,19,184,134,70,233,117,2,84,242,135,246,95,159,14,218,125,209,191,175,89,41,196,182,96,117,5,159,98],"nonce":[114,93,158,35,209,188,96,248,85,131,95,237]}' \
  -H "Accept: application/json" \
  http://127.0.0.1:3001/user/sign_tx

For the blockchain node

/user/new - POST

[crate::user::api::new_user()]

Called by the off-chain worker (propagation pallet) during user registration. This takes a parity scale encoded entropy_shared::types::OcwMessageDkg which tells us which validators are in the registration group and will perform a DKG.

For other instances of the threshold server

  • /user/receive_key - recieve a keyshare from another threshold server in the same signing subgroup during registration or proactive refresh.

    Takes a [UserRegistrationInfo] containing the users account ID and associated keyshare, wrapped in a crate::validation::SignedMessage.

  • /ws - Websocket server for signing and DKG protocol messages. This is opened by other threshold servers when the signing procotol is initiated.

  • /validator/sync_kvdb - POST - Called by another threshold server when joining to get the key-shares from a member of their sub-group.

    Takes a list of users account IDs for which shares are requested, wrapped in a crate::validation::SignedMessage. Responds with a list of crate::validation::SignedMessages each containing a serialized synedrion::KeyShare.

  • /version - Get - get the node version info

  • /heathlz - Get - get if the node is running

  • /hashes - Get - get the hashes supported by the node

For testing / development

Unsafe has additional routes which are for testing and development purposes only and will not be used in production. These routes are only available if this crate is compiled with the unsafe feature enabled.

  • unsafe/get - POST - get a value from the key-value store, given its key.
  • unsafe/put - POST - update an existing value in the key-value store.
  • unsafe/delete - POST - remove a value from the key-value store, given its key.
  • unsafe/remove_keys - GET - remove everything from the key-value store.

Pieces Launched

  • Axum server - Includes global state and mutex locked IPs
  • kvdb - Encrypted key-value database for storing key-shares and other data, build using sled

Dependencies

~86–125MB
~2M SLoC