Threshold Signature Scheme
Implementing TSS node modules on L2 to minimize the trust risk of execution results
Mantle v2 Tectonic has been released, please move to the new documentation!
Background
Optimistic Rollups have a limitation in terms of imposing long waiting times for withdrawals in the form of challenge periods. In order to address the uncertainty problem of transaction validation during the challenge period, we implement a distributed signing scheme for the verification of block data.
This paradigm of distributed key generation combined with digital signatures is more popularly known as the Threshold Signature Scheme (TSS). It enables each party of the client network to generate a valid signature, and ensures the verifiability of distributed signature data as long as enough of them are honest. The private key also ceases to be a single point of failure now that every TSS client only holds a part of it.
Here multiple TSS nodes verify the block data sent by Sequencers and sign it, guaranteeing its correctness.
The process of computing digital signatures using TSS basically involves three steps:
Key Generation: The key generation function run by each TSS client generates a private key, and then generates a public key based off of the private key. It is designed such that the public key it generates the same public key for every client, and the private key is unique and never shared in any manner.
Signing: The signing function takes a public input available to all clients as the message to be signed, and then generates a signature using the private key.
Verification: A verification algorithm takes the signature data and verifies it with the public key.
TSS nodes stake a fixed amount of $MNT on Ethereum as part of the deployment process, and this stake gets slashed if there is malice or failure detected on their part.
For Mainnet Alpha
All TSS nodes will be permissioned by the Mantle core contributor team.
We assume TSS node honesty and operator performance are aligned with that of the Sequencer and Batch Submitter.
The TSS provides an additional check on State Validity prior to Batch Submission. Some third party applications may choose configure their finality requirements to TSS Verification (Batch Submission) instead of number of L2 blocks.
TSS Stake, Rewards, and Slashing mechanisms will all remain in place. However, as Stake, Rewards, and Slashing are provided by, or owed to, Mantle DAO under the administration of the Mantle core contributor team, these incentives do not affect the service uptime assumptions of the TSS.
Future Direction
The future direction of TSS will be a major decision for the next significant upgrade of Mantle Network, and TSS will be evaluated among other architectural choices such as Shared Sequencer, Decentralized Sequencer, Fraud Proofs, Zk Proofs, and other mechanisms that aim to enhance confidence in State Validity.
There is no plan to allow permissionless TSS nodes under the current architecture.
Architecture
The components of the TSS client network the signing mechanism are:
TSS Core: Uses an implementation of the tss-lib as our version of the TSS.
TSS Manager: The TSS Manager is responsible for managing the TSS nodes engaged in multi-party computation, and dispatching signing tasks to them.
TSS Nodes: A TSS node generates its own private key, and communicates with other nodes through a peer-to-peer network to generate signatures by signing messages with its private key.
Justification for a TSS Manager
In order to maintain coordination between TSS Nodes to accomplish signing tasks, there needs to be a component that assists with:
discovering nodes that are able to join a signing task at any given point of time
dispatching signing tasks to the TSS nodes
Our research determined it would be more efficient to create a TSS Manager versus having each node track the availability of all other node participants.
Functionality
The TSS Manager accepts WebSocket (WS) connections from TSS nodes and transmits messages to the nodes via these connections.
The signature process begins when the Batch Submitter sends a signature request to the TSS Manager. The signature request includes a state root that will be uploaded to L1 if verified.
The TSS Manager must now coordinate with the TSS nodes to verify that this state root is correct. This process that follows:
The TSS Manager determines which TSS nodes are willing to join the signing task
The TSS Manager dispatches the signing task along with block data to the active TSS nodes (along with data indicating which nodes joined)
TSS nodes generate signatures in an attempt to verify the state root
The TSS Manager receives and verifies the signatures from the respective TSS nodes
If valid, the TSS Manager sends the signature to the batch submitter
Every TSS node is obligated to actively participate in state root verification and signing. Their staked $MNT will be slashed in case of failure to fulfill any of these duties, i.e., not returning signed block data under any circumstances. All slashed $MNT will be distributed among the functioning TSS nodes.
Execution Result Signing
Because TSS nodes re-derive the state root, we alternatively refer to signed state roots generated by TSS nodes as the execution result.
When the execution result determines that the state root is valid — and can be uploaded to L1 — it is passed back to the Batch Submitter by the TSS Manager.
Each TSS client runs a Verifier (that sync data from Mantle DA) so it can execute transactions and arrive at the correct state root. This state root (the execution result) is used to verify the event data coming from the TSS manager.
Execution Result Diagram
TSS Node Election
The following process describes how TSS nodes are elected:
A user must stake $MNT on the Ethereum mainnet
The smart contract on L1 records the user's stake and locks the $MNT tokens
Mantle team determines which TSS nodes are to be included as a part of the TSS node cluster
Elected nodes run the TSS process offline, which manages private key shares and generates the cluster public key
The nodes submit the generated cluster public key to L1
The cluster public key is confirmed once it is submitted by all TSS nodes
TSS Node Slashing
Our system needs deterrents to prevent malicious behavior on part of TSS nodes. We identify two types of malicious behavior and their respective deterrents below:
Node Liveness
To create a deterrent against extended downtime for TSS nodes, the TSS Manager records which nodes are absent from every signing task. As the degree of absence increases, the TSS manager submits a proposition to slash an absent node's stake. If the proposition is signed by a proportional majority of the cohort (by stake), a portion of the absent node's stake will be slashed.
Malicious Signing
Another form of malicious behavior would be if an TSS node serves fraudulent data to the TSS cluster to disrupt the signing process.
In this event, other nodes will record the node's behavior and report it to the TSS Manager. The TSS Manager will then start a proposition to penalize this malicious node. If the proposition is signed by a proportional majority of the cohort (by stake), this node's stake will be slashed.
Last updated
