Forms of Usage
SilentShard is essentially enabler for brining multiples parties/nodes/devices/endpoints which can engage in distributed signature generation.
A. Institutional Assets: Silent Shard is poised to support institutional assets with high configurability on signature curves, participating nodes and signing policies.
B. Mobile Based Wallets: Mobile wallet enterprises can decide on which parties to engage in the distributed signature generation. Silent Shard SDKs and APIs can be accordingly deployed based on the agreed architecture. In general, wallet enterprises prefer engaging mobile and a cloud node for generating TSS-based signatures.
Design Choices for Structure of Key Sharding and Sharing:
{2,2} TSS MPC: During registration of the 2 nodes which will participate in the signature processes, distributed shares are generated between two parties using Silent Shard’s DKG protocol. Silent Shard proposes to adopt either of these possible pairs of nodes based on the business needs and user adoption choice:
A.1 User’s phone (wallet) holds one shard, and another shard is stored at an enterprise server (Enterprise or SL to hold the second shard as per discussions ahead). During the signature process, the phone wallet communicates with the server node and generates a signature on the phone, which is further pushed to the blockchain.
A.2: The user registers the wallet using two phones: The key shards are held by a regular phone wallet and a support phone (extra phone or a backup phone depending on the user’s comfort).
A.3: {t, n} TSS MPC: {t, n} threshold signature scheme defines a quorum where if t out of n registered parties/nodes can participate in a signature generation process, they would be able to generate a valid signature, equivalent to having the actual private key.
For adopting {t, n} structure in the case of the phone wallet, Silent Shard enables the generation of distributed keys between the phone wallet and other nodes. Other nodes can be cloud-hosted instances by the enterprise or a hybrid set of cloud and other mobile devices.
Interestingly, and necessarily, Silent Shard adopts Hierarchical Threshold Signature and additive sharing-based algorithms to ensure that involvement of the phone wallet is guaranteed for a valid signature and other nodes with key shards cannot collude.
In general, we have seen appetite and interest for 2/3 and 3/4 quorum.
C. Browser Extension/Plugin-Based Wallets: A plugin is one of the dominant forms of crypto-wallet. Typically the private keys are stored in the local storage of the browser. Silent Shard integration enables such wallets to distribute the signing process between the plugin and a token device (smartphone) in the simplest of the integration (2,2 TSS).
In the most general case, MetaMask wallet for example, suppose a user is trying to transfer coins from her wallet. During signature, the browser wallet’s screen suggests user to bring the phone in proximity, or perform some very naive and light interaction (to prove the possession). Once proofs are met, signature validations are initiated as per the communication and checks of TSS.
Design Choices for Structure of Key Sharding and Sharing:
B.1: {2,2} TSS MPC: Contrary to the current design, where private keys are stored locally in the local storage of the browser, Silent Shard enabled Plugin Wallets to transition towards a much more secure and resilient distributed shares-based architecture.
During registration of the wallet or during the addition of MPC support, users would be able to add a phone as holder of the second shard. The phone can be the one with the phone wallet of the same enterprise that designed the Plugin Wallet or a universal authenticator of Silence Laboratories.
During signature, the plugin initiates the signature generation with the phone wallet through a challenge-response protocol embedded in TSS.
As such user just needs to approve a push notification on the phone to kickstart the signature generation. The final signature is generated on the plugin side and pushed to the chain.
In the most general case, MetaMask wallet for example, suppose a user is trying to transfer coins from her wallet. During signature, the browser wallet’s screen suggests user to bring the phone in proximity, or perform some very naive and light interaction (to prove the possession). Once proofs are met, signature validations are initiated as per the communication and checks of TSS.
B.2: {t, n} TSS MPC: Similar to the case of adopting {t, n} TSS, Silent Shard, for phone wallet, we have a design choice to add multiple nodes in the quorum. Other nodes can be hosted on clouds or user devices.
In general, we have seen appetite and interest for 2/3 and 3/4 quorum for {t, n} TSS.
Last updated