Torus Network: a Decentralized Key Management System (DKMS) (DRAFT NOT FOR RELEASE)

--- tags: spec --- # Torus Network: a Decentralized Key Management System (DKMS) (DRAFT NOT FOR RELEASE) ## Introduction With the growth of cryptographic applications, key management has become increasingly important. Mismanagement of private keys often results in considerable [financial loss](https://www.wsj.com/articles/a-fifth-of-all-bitcoin-is-missing-these-crypto-hunters-can-help-1530798731), and as usage of private keys become increasingly mainstream through applications like DeFi, P2P messaging and Decentralised IDs (DIDs), key loss and misuse will become even more prevalent. Many existing self-custodial key management solutions present users with trade-offs between security, convenience, and redundancy. For example, with [Metamask](https://metamask.io/), backing up your key increases redundancy during key loss, but reduces security if that backup is stolen. Multisig wallets provide a balance of all three, but often have limited functionality in terms of permissions. Moreover, wallet front-ends are still a central point of failure that is vulnerable to exploits or censorship. Lack of interoperability between wallets also increases vendor lock-in and reduces user control. The ideal model for key management should be one that's extensible to arbitrary access structures, authentication methods, and permissions. In that regard, smart contract wallets like [Argent](https://www.argent.xyz/) have done a great job at making Ethereum-based asset management flexible for users, through introducing mechanisms like Guardians. We posit that not all cryptographic applications will be on Ethereum (or blockchain for that matter), and that these benefits can be made available for any cryptographic wallet / dapp / app by introducing an open platform for decentralized key management with the following properties: * **Usability:** Users can have security and redundancy without compromising on convenience. Users with no experience in key management should be able to utilize the system efficiently. * **Incremental security:** Users can easily upgrade the security of their keys with more factors of authentication or scoped permissions. * **Interoperability:** Keys should be usable across systems with minimal vendor lock-in. * **Self-custodial:** Users have full control over their keys and how they are managed. At any time they should be able to leave the system. ## Preliminaries In this section we review the necessary facts and results about secret sharing and peer-consistency, which we use later to demonstrate applications/extensions of these methods that are applicable to our use cases. ### Shamir Secret Sharing (SSS) Shamir's secret sharing scheme is a polynomial threshold $(t,n)$ secret sharing scheme where a dealer divides a secret into $n$ multiple shares and each participant is given a share by evaluating a polynomial of order $t$. To reconstruct the secret, $t+1$ shares are required. ### Distributed Key Generation (DKG) Distributed key generation was introduced by Pedersen, and the key idea involves using $n$ parallel runs of SSS to ensure that there is no dealer who knows the secret. Improvements to security, verifiability, and synchrony assumptions have been made in more recent DKG constructions. ### Proactive Secret Sharing (PSS) Proactive secret sharing allows participants to "refresh" shares, so that all participants receive new shares, but the secret remains unchanged. This allows the secret sharing to be secure against mobile adversaries who may be able to compromise all participants over the lifetime of the secret (eg. adversary hacks a random participant's server every month). We refer the user to a [proactive secret sharing scheme](https://eprint.iacr.org/2002/134.pdf) that supports dynamic sets of participants, which we use for share refresh. ### Threshold Signature Scheme (TSS) Assuming secret shares, TSS allows each participant to participate in a joint process that outputs a regular signature over a message on the secret. In particular, we refer the reader to recent work on [fast ECDSA threshold signature schemes](https://eprint.iacr.org/2019/114.pdf), which we use. ### Cross-domain Non-Interactive Zero Knowledge Proofs Existing legacy attestation systems utilize standards like OAuth2 and OpenID Connect, run on RSA cryptographic pairs. With the recent emergence of efficient zero-knowledge proofs for general circuits, while efficient zero-knowledge proofs of algebraic statements have existed for decades, it is a challenge to combine algebraic and non-algebraic statements. Recent work by [Chase et al. (CRYPTO2016)](https://eprint.iacr.org/2016/583.pdf) tackles this problem, showing RSA/DSA signatures on a message m with respect to a publicly know Perdersen commitment was possible in their system. Following [Backes](https://eprint.iacr.org/2019/063.pdf) utilizes their work with by Giacomelli et al. (USENIX 2016) ZKBoo/ZKB++ to construct a non-interactive version. We utlize their work to ensure that attestation preserves the privacy of its participants.  ## Definitions The key management stack can be split into two parts -- *key storage* and *key access*. Note here that in the literature (and also in this document), access structures refer to the qualified sets of agents who hold a share (*key storage*) and can reconstruct the private key. We define *key access* to be the process in which a user is able to use his/her private key (i.e. access rights / user authentication). One of the design goals of Torus v2 is to enable flexible access structures to private keys and to specify a framework for access rights. We also want to ensure that these access rights are backed by incentive-compatible mechanisms, such that during normal operation, threshold assumptions are not required for safety, only liveness. The framework should be flexible for users/implementers and composable with existing systems. In most secret sharing schemes, users rely on a threshold honest assumption for safety of their private keys. Although this may seem acceptable initially, once we model the set of agents as rational agents instead of honest/malicious agents, threshold honest behavior cannot be an equilibrium since it is profitable to deviate and steal user funds. A similar problem exists for on-chain oracles. MakerDAO price feeds and ChainLink oracles rely on the threshold honest assumption for accurate information. Some prediction markets also rely on threshold honest majority assumption among their token holders for arbitration. These on-chain oracle solutions often improve on this by using a subjectivocracy fallback mechanism -- if there is an irreconciliable disagreement, the system forks and anyone can pick the side they believe in. Malicious oracles are also penalized by being slashed for misbehavior. We borrow these ideas from on-chain oracles to achieve similar guarantees for key management. It is clear that subjectivocracy is impossible if key storage follows a simple threshold access structure where the shares are held by external agents (i.e. not the user). When a coalition of threshold agents who are malicious recover the user's private key, it is impossible to "fork" and choose a different set of agents, since the private key is irrecoverably lost. Moreover, if the user generated the shares (as a dealer) for the agents, it is also impossible to set up slashing conditions since the user knows the shares that were held by each agent and there is no way for any form of fraud proof to distinguish between the user and the agent. We now introduce a key access structure called Hierarchical Threshold Secret Sharing (HTSS) that resolves these issues. ### Hierachical Threshold Secret Sharing Unlike normal threshold secret sharing where all shares have equal "weight" and any $t+1$ out of $n$ shares can be used to reconstruct the private key, in hierarchical threshold secret sharing, participants in the secret sharing are split into different "levels" and shares at a higher level are more important in the reconstruction threshold than shares at a lower level. This type of secret sharing has been studied extensively since the seminal work of [Tassa](https://link.springer.com/chapter/10.1007/978-3-540-24638-1_26), and since then many variants of hierarchical threhsold secret sharing have been introduced. In particular, we provide a simple adaptation of [Pedersen-VSS](https://link.springer.com/chapter/10.1007/3-540-46416-6_47) below for a $(t,n)$ secret sharing where one of the shares is further sub-shared under a $(t',n')$ secret sharing, such that the secret sharing is linear, and adaptable for use as a subprotocol in an existing [DKG](https://link.springer.com/article/10.1007/s00145-006-0347-3) and [TSS](https://eprint.iacr.org/2019/114.pdf) scheme. Wlog, we assume that the $n^{th}$ share in the $(t,n)$ sharing is sub-shared. #### $HTSS-(t,n,t',n')$ - Dealer $D$ performs a secret sharing of a secret $z$ - D chooses 2 random polynomials $A(z),A'(z)$ over $\mathbb{Z}_q$ of degree $t$: $A(z)=a_0+a_1z+...+a_tz^t,A'_i(z)=a'_0+a'_1z+...+a'_tz^t.$ such that $z=a_0=A(0)$ $D$ broadcasts $C_{k}=g^{a_k}h^{a'_k}\bmod{p}$ for $k=0,...,t$. $D$ computes the shares $s_i=A(i),s'_i=A'(i)\bmod{q}$ for $i=1,2,3,n-1$ and sends $s_i,s'_i$ to party $P_i$ - D also chooses 2 random polynomials $B(z),B'(z)$ over $\mathbb{Z}_q$ of degree $t'$: $B(z)=b_0+b_1z+...+b_tz^{t'},B'(z)=b'_0+b'_1z+...+b'_tz^{t'}$ such that $b_0=A(n)$ and $b'_0=A'(n)$. $D$ broadcasts $C'_{k'}=g^{b_{k'}}h^{b'_{k'}}\bmod{p}$ for $k'=0,...,t'$. $D$ computes the shares $u=B(i),u'_i=B'(i)\bmod{q}$ for $j=1,2,3,n'-1$ and sends $u_j,u'_j$ to party $P_j$ - Each party $P_i$ verifies the shares he received from D by checking if: $g^{s_i}h^{s'_i}=\displaystyle\prod^t_{k=0}(C_k)^{i^k}\bmod{p}$ - Each party $P_j$ verifies the shares he received from D by checking if: $g^{u_i}h^{u'_i}=\displaystyle\prod^t'_{k'=0}(C'_{k'})^{i^{k'}}\bmod{p}$ - All parties $P_i,P_j$ also verify that $b_0=A(n)$ and $b'_0=A'(n)$ by checking if: $C'_0=\displaystyle\prod^t_{k=0}(C_k)^{n^k}\bmod{p}$ - If a check fails for $P_i$ or $P_j$, they broadcast a *complaint* against D. - D then reveals the share for $P_i$ or $P_j$, and if it does not pass the check D is disqualified. - **Correctness** - For any set $\mathcal{R}$ of $t+1$ parties $P_i$, $z=\sum_{i\in\mathcal{R}}\gamma_i.s_i\bmod{q}$, where $\gamma_i$ is the appropriate Lagrangian coefficients for $\mathcal{R}$ - For any set $\mathcal{R'}$ of $t$ parties $P_i$ and $t'+1$ parties $P_j$, $z=\sum_{i\in\mathcal{R'}}\gamma_i.s_i+\gamma_n.\sum_{j\in\mathcal{R'}}\gamma'_j.u_j\bmod{q}$ where $\gamma_i$ and $\gamma'_j$ are appropriate Lagrangian coefficients for $\mathcal{R'}$ - Note that since the reconstruction of the secret from the shares is a linear mapping, the HTSS scheme is linear - **Secrecy** - No information on $z$ can be learned by an adversary who does not satisfy the specified $(t,n,t',n')$ access structure. We consider an adversary who corrupts the maximal non-qualified set $M$, which is $t$ parties in $P_i$ and $t$ parties in $P_j$. For any $z'\in\mathbb{Z}_q$, we can use $\{z',s_i\}, i\in M$ to interpolate $\bar{A}$, a polynomial of degree $t$, and evaluate $\bar{b}_0=\bar{A}(n)$. We can then use $\{\bar{b}_0,s_j\}, j\in M$ to interpolate $\bar{B}$, a polynomial of degree $t'$. So there always exists a set of two polynomials, $\bar{A},\bar{B}$ for any $z'\in \mathbb{Z}_q$ that include the shares in the maximal non-qualified set, so it is not possible for the adversary to find $z$. #### HTSS-DKG We construct a DKG from HTSS-(t,n,t',n') using ideas from [New-DKG](https://link.springer.com/article/10.1007/s00145-006-0347-3). - We denote $P_i$ as a participant who belongs to the $(t,n)$ level and the $P_j$ as a participant who belongs to the $(t',n') level. - Let $H=(n-1)+n'$, wlog we index participants such that $i\in \{1,...,n-1\}$ and $j\in \{n,...,H\}$. - Each party $P_h$ performs a HTSS-(t,n,t',n') of a random value $z_i$ as a dealer, dealing out shares based on the (t,n,t',n') access structure. - Each party $P_h$ then verifies the shares received from other parties $P_d$, if the checks fail, $P_h$ broadcasts a complaint against $P_d$. - Each party $P_d$, upon receiving a *complaint*, broadcast the shares for $P_h$ that satisfy checks. - Each party $P_h$ marks as *disqualified* any party $P_d$ that either - received more than $t$ complaints - answered a complaint with an shares that fail checks - Each party then builds a set of non-disqualified parties $QUAL$ - Each party sums up the shares received from all other parties that are in $QUAL$. $xh=\sum_{d\in QUAL}s_{dh}\bmod{q}$ and $x'h=\sum_{d\in QUAL}s'_{dh}\bmod{q}$. The distributed secret is $x=\sum{d\in QUAL}z_{d}\bmod{q}$. - To extract $y=g^x$, we have all parties $QUAL$ generate $NIZKPK(g^{x_{i_d}},g^{x_{i_\delta}}h^{x_i'},x_{i_d}=x_{i_\delta})$ and broadcast it. The parties can then interpolate in the exponent with appropriate Lagrange coefficients to retrieve $g^x$. A full description of this technique can be found [here](https://eprint.iacr.org/2012/377.pdf). For correctness, by the linear properties of HTSS, the resulting sum of shares $x_i$ for each party $P_i$ is also a HTSS. Full simulation proofs are omitted here for brevity, but informally for every adversary $\mathcal{A}$, there exists a simulator $\mathcal{S}$, such that on input an element $y$ in the subgroup of ${Z_p}^{\ast}$ generated by $g$, produces an output distribution which is polynomially indistinguishable from $\mathcal{A}$'s view of a run of the HTSS-DKG protocol that ends with $y$ as the output. This is done by having the simulator $\mathcal{S}$ who controls the honest particiapnts follow the HTSS-DKG protocol for all but one of the honest participant, and then choose values for the last honest participant so that the resulting public key is $y$. #### TSS We show that HTSS admits a simple conversion protocol that satisfies the requirements for using [TSS](https://eprint.iacr.org/2019/114.pdf). Note that for any set of of $t+t'+1$ participants with shares generated by HTSS-(t,n,t',n'), they can locally map their shares into a $(\bar{t},\bar{t})$ secret sharing scheme by using appropriate Lagrangian coefficients, where $t\leq\bar{t}\leq t+t'$. In particular, for $\lambda_{i,S}$ in [TSS](https://eprint.iacr.org/2019/114.pdf), we replace it with $\lambda_{n,S}.\lambda_{j,S}$ for each $P_j$. The rest of the TSS protocol remains unchanged as this is now a $(\bar{t},\bar{t})$ sharing. #### Subjectivocracy By ensuring that external agents only hold a non-threshold number of shares, it is possible for a user to "fork" and choose a different set of external agents if there is detected malicious behavior from the external agents, without losing the original private key. In addition, by using HTSS-DKG and TSS, aside from improving security since the private key is never reconstructed, the user also does not get access to the individual shares of the external agents at any point in time, which means the user cannot forge fraud proofs against these external agents, and the existence of the agent's shares being used "in the wild" can be used for slashing the agent's stake. We leverage these two features to implement an incentivised system where external agents are rewarded for following protocol, but in the case of irreconciliable disagreements, the protocol can fork and the user can decide which fork to be on. ### On-chain oracles Most existing oracles, such as [Augur](https://www.augur.net/) and [UMA](https://umaproject.org/),: work in roughly the same way: initial reporting $\rightarrow$ escalation $\rightarrow$ voting $\rightarrow$ forking, with each subsequent step being more and more expensive. Most oracle systems today still rely on some form of honest majority assumption for initial reporting. However, having stronger guarantees at each step reduces the "churn" for that step (thus reducing costs). As of late, many improvments have been made to peer-consistency mechanisms which could contribute to a more efficient reporting setup. We refer the reader to the work by [Goel et al](https://arxiv.org/pdf/1908.10258.pdf) for more information.  ## Protocol Fundamentals The foundation for the Torus v2 protocol consists of functionality built either on or into a consensus layer defined by three main extensions; Secret Variables, MPC Outputs and Oracle Variables. The extensions can be integrated on a smart contract layer or in a VM and in this section we describe the criteria required for the consensus layer/VM, and the extensions individually. ### Secret Variables Torus enables users of its system to distributedly generate or import secrets into a select subset of nodes. Because of this, Torus nodes hold both public states, as well as local states that are verifiable through commitments on the VM. These secrets can be completely or partially held by nodes in the network based on user-defined specifications, giving end users flexibility in its access structure where necessary. This functionality called $SSStore$ (Secret Storage Store) is defined below: Given a pool of node operator addresses, $N_{\sigma}$, the user address, $\sigma_{user}$, selects public keys $S_n = \{\sigma_0,\sigma_1...\sigma_n\}\in N_{\sigma},\sigma_{user}$ to store the secret $z$. $S_n$ engage in DKG (or HTSS-DKG) defined above and assigns it to a specified index, $l$ and smart contract address, $\sigma_{context}$, resulting in the storage of $z_0,z_1...z_n$ with the members of $S_n$ respectively. This functionality accrues a one-time cost to the caller for the computation $G_{DKG}$ involved and rent derived by the sum of charges specified by the selected nodes ahead of time. The stored secrets are used as a foundation to compute outputs in an MPC manner with its privacy-preserving, correct, and independent properties, as described [here](https://eprint.iacr.org/2020/300.pdf). ### TSS and other MPC outputs With the stored secrets, users of Torus can operate a suite of functions that result in MPC outputs. These include, but are not limited to, the [various](https://people.csail.mit.edu/devadas/pubs/scalable_thresh.pdf) [TSS](https://eprint.iacr.org/2019/114.pdf) [schemes](https://link.springer.com/chapter/10.1007/3-540-47719-5_33), proactive secret sharing and basic attestation. In this section, we use Threshold ECDSA as an example, without loss of generality. MPC outputs are callable for the secrets within their context spaces and calling its function runs a predefined execution instruction. $ECDSA$ can be defined as: $$Given\space\sigma_{context} \space|ECDSA(l,msg)\Rightarrow sig(r,s)\space on\space z$$ When $ECDSA$ is specified to be run within $\sigma_{context}$ it takes the secret reference , $l$, and $\sigma_{context}$ resolving it to the shared secrets of $z$ held by participants $S_n$ as well as a message and uses TSS ECDSA[] to output an ECDSA signature on $z$. The corresponding cost of the function equates to the price of computation charged from $S_n$. ### Oracle Variables Torus employs the usage of outputs from peer-consistency incentive mechanisms to update variables and import offchain data. On creation an $OVAR$ is initialized with an API endpoint and a claim to the result of the endpoint. On the processing of deployment of an execution context with an $OVAR$ we proceed with an implementation of an protocol level oracle with three phases, similar to other oracle models such as [Augur](https://www.augur.net/) and [UMA](https://umaproject.org/): 1. Reporting 2. Escalation 3. Forking #### Reporting We start by randomly selecting nodes $S_n = \{\sigma_0,\sigma_1...\sigma_n\}\in N_{\sigma}$ as described to query the endpoint, reporting either that the claimed result is true or invalid. Participating nodes are incentivised via an additional $G_{OVAR}$ payment which scales inversely to nodes availiable in the node set vs expected griefing value. We expand more on the usecases of Oracle Variables in the following sections. Once the result of the survey is concluded, the result is deemed pending until the end of a parameterized time $t_0$. On-chain contracts can read information about the pending state as well as the reports. #### Escalation During the pending state, any entity that disagrees with the result can choose to stake on an opposing result, transitioning us to an escalation phase. Disagreements extend the pending timeout by $t_\delta$, and similarly, any entity can choose to disagree with this disagreement, by staking. If the timeout comes to pass, the final result with the most stake is declared valid and all stake that is inconsistent with the final result is rewarded to stakers who voted on the final result. Note that escalation only happens in the unlikely event of a majority collusion. #### Forking In the case that the escalation phase results in a scenario where a large percentage of total stake is on a single outcome, the protocol forks and users/nodes can choose to be on either one of the forks depending on their preference. This can be conducted out of band, or specified as a parameter in-protocol. ### Non-interactive Zero-Knowledge Proofs for RSA/DSA verification on JWTs Existing generic circuit implementations of ZKPs of RSA signatures have been benchmarked to only take [<700ms for verification](https://github.com/akosba/jsnark/blob/master/JsnarkCircuitBuilder/src/examples/tests/rsa/RSASignature_Test.java), without significant [optimisations](https://eprint.iacr.org/2019/063.pdf), and tradeoffs in terms of proof systems can be done in order to generate proofs with faster verification time. For efficiency reasons, we intend to make this available on-chain as a precompile, with support for more precompiles over time to accomodate for different types of credentials. In addition, during normal operation, users can opt not to submit it on-chain, and only generate and submit these ZKPs when the nodes are not responding with valid shares in order to slash the node's deposits, which should improve overall throughput of the system. ## Decentralised Key Management System In this section we present a practical implementation of decentralized key management, that fufills the properties and design goals and provide the arguments/proofs towards its guarantees. The system is designed around the incentives and relationships between stakeholders in the existing ecosystem today, which we outline below: * User - an individual or entity that utilises the system * Applications - front-ends to crypto applications (i.e. wallets, dapps) * Nodes - node operators of Torus v2, which are assumed to be rational and economically incentivised The overall architecture consists of application-specific contracts that define the access definitions for the user (eg. OAuth / custom email-password login), the mappings of users to secret variables, and the usage policies (eg. restricted signing).  ### Application-Specific Contracts Apps on Torus v2 deploy contracts that contain three parts: verification definitions, and output specifications. These contracts are assigned Secret Variables, and verification rules are evaluated before securely generating specified outputs. We proceed with a description of a contract that enables Google logins to threshold ECDSA signatures on user's share. #### Verification via OAuth and other methods Whilst contracts are generalizable to arbitrary verification methods, [OAuth](https://tools.ietf.org/html/rfc6749) is one of the main protocols employed for authentication by legacy systems. It consists of an RSA signed JWT token which can be verified on the consensus level, the verification is done against Google's publicly shared RSA key. If legitimate, we proceed to validify the token's fields, including email address. Utilizing a user's email address as the Secret Variable index, $l$, we call the MPC output function $ECDSA(l,msg)$ where $msg$ is arbitrarily provided in the transaction call to the contract. The result is a portion of the ECDSA signature required on a transaction. #### Zero knowledge proofs on JWTs In order not to [leak information](https://eprint.iacr.org/2020/934) about the JWT token beyond what is necessary, the application can choose to replace this authentication mechanism with a user-generated ZKP on the JWT token instead, that only reveals certain fields. Verification is extensible to include most OAuth providers and can even be based on signatures of different types, multiple factor authentication and even DID specfications (WebAuthn). We forsee interesting applications of the verification context beyond simple key management, to perhaps escrow payments, private data attestation, and more. #### Flexible permissions Its easy to see that generalizable nature of verification here allows us to implement further permissions on what is a legitimate transaction. This could include restrictions on spending (i.e. spending limits), restrictions on type of messages signed (eg. messages with a specific prefix), or even oracle variable based permissions (e.g. do not sign transaction if gas fees are higher than a threshold). Aside from just using verifications to enable customizable permissions, we expect to see developers use this for more interesting applications like data attestation or even cross-chain interactions. Given the nature of mainstream users, gas abstraction will be enabled at the protocol level to allow applications or even other users to pay for a user's transaction fees on their behalf. #### Updatability and convenience of variables Legacy systems today are not designed for decentralized setups in mind, and because of that it is often necessary to update/validate variables that are arbitrary or cannot be verified on-chain. For example, for certain providers, RSA public keys for JWT verifications may rotate spontanously over time. Here we use Oracle Variables to update outdated endpoints for verification. The requirements for updating endpoints fit the constraints described for PTSC, and additionally can be used for other simple verification values. ### User Sovereign Keys When first engaging with the Torus ecosystem, a user utilizes an application to hierachically generate their key with the network via $SSTORE$. The split of the secret $z$ is $t/n$ where $t>1,n > t$ and the nodes hold only ever 1 share. For later references, let $z_1$ in the set of shares $\{z_1,z_2...z_n\}$ be the share allocated to nodes. Nodes further hold a subshare of the share, represented by $\{z_{11},z_{12}...z_{1m}\}$ where $m$ is the number of nodes. User's in the network should never reconstruct their actual private key scalars in an application, but all interactions are done via MPC outputs with/out the network of nodes. We define the property of self-custodiality as no one entity but the user has access to her private key. With Torus, user's, and no one else, have full control of their keys, we present the proof, arguments and tradeoffs. Moreover, we also prove that in any case Torus disallows nodes from griefing a user from accessing his/her share. For the following arguments we assume all nodes are rational actors incentivised by economic gain. #### Self-custodiality In the case of $t<n$ its easy to see the self-custodial properties of the access structure. In 2/3 for example, in the event of malcious action, at most the nodes only ever do get access to one share and it is always possible for the user to access his/her key. However, in the case of a loss share, or just inconvenience in standard operation we need to ensure that a node does not grief. To address this we introduce a mechanism to slash stake. There are two ways a node could grief, simply exposing a user's share and refusing to sign MPC outputs. Let us analyse the former in the context of $t = n$, a 2/3 split $\{z_1,z_2,z_3\}$, and a further split of 3/5 of subshares $\{z_{11},z_{12}...z_{15}\}$ between the holding nodes. As stated in the result of HDKG, the shares are respective to two polynomials that when reconstructed regenerate the $z$ and $z_1$. With this configuration we are able to slash on: 1. A node on exposed user's subshare $\{z_{11},z_{12}...z_{15}\}$ allocated to them 2. The full set of holding nodes if $z_1$ is found exposed, as this indicates collusion of threhold of the set. (Note, need to edit to future construction) We now address griefing of MPC outputs. As verification of application contracts are verifiable we can expect to be able to enforce MPC outputs. Whilst this allows us to punish non-conmplient operators, this does create a requirement of capital proportional to the amount of value caused by the inconvenience, which is roughly constant and inverse to number of nodes. $$Node\space capital\space required \propto \frac{Value\space of\space inconvenience}{Num\space of \space Nodes}$$ #### Convenient base UX Many wallet service providers have streamlined user access to a point where private key retrieval has become indistinguishable from Web2.0 logins. This has greatly improved user experience in this space, and Torus v2 does not detract from this goal. By using user device storage for one of the shares in a 2/3 base setup, the main user flows for existing a new user remain unaffected and a user can continue to use any form of attestation/authentication to access their account. #### Keyless enterprise grade security and reducing lockin Users of Torus v2's key management architecture never actually reconstruct a user's key on any front-end. From the initial generation, to the usage of a user's key, is conducted via DKG[], TSS[] and other forms of MPC - jointly participated by the user's client-side and network nodes. Due to the keyless nature of the key management style, user's can choose to never reveal their key to any front-end. Allowing them to port their key over to different front-ends more freely and reducing lockin in one particular front-end, chain or ecosystem. #### Progressive access control At any point in time users can refresh shares into a different threshold structure. From 2/3 to 3/4 for example, adjusting and incrementing the number of points required for node reconstruction. #### Improvements to key recovery In the event of a lost device/share, there is redundancy built into the share threshold such that a user can still recover their key. It is also possible to refresh shares such that lost shares are revoked. This is an improvement over writing down a seed phrase on a piece of paper, since losing the seed phrase gives complete access to the private key. Losing a share, however, is acceptable as long as the user does not lose more than one share without refreshing his existing shares. ### Nodes Torus runs as a permissionless network where any individual or entity could run a node which conducts the base operations defined above. We use nodes as a loose terminology of constantly online participants of the protocol. There are three types of nodes which are defined by their level of participation in the protocol, operators can choose one or all to operate: 1. Standard node 2. Peer prediction node The leveling between the nodes are designed to incite different levels of participation from the stakeholders of the protocol. Both types of nodes are incentivised for the work they do, proportional to the computational resources demanded. #### Standard node Standard nodes run all of the main operations required for the Torus Protocol. They store secrets and provide MPC outputs when the contracts are run. In operating these base functions the node is incentivised through user fees paid by applications and users proportional mostly to the resources provided. Each node has a set constant amount of stake equivilent to the one time griefing punishment for [], a later determined parameter. Stake is utilized to guarantee liveness and deter griefing attacks described in [] from the nodes. After the commitment of stake, a new node is allocated a portion of the network's secrets through the network's balancing mechanism. The number of secrets allocated can be directly determined through: $$Num\space of\space allocated \space shares = \frac{\sum^z n_z }{Num\space of\space nodes}$$ Where $n$ is the number of nodes holding a particular secret $z$. Nodes are required to maintain an uptime of these secrets, and in the event they are not they risk a portion of their stake. In this way, we can derive an economic guarentee to a user that their secrets will not be lost through $Secret\space liveness\space guarentee=(n-t)*Stake\space at \space risk$. Whilst a strictly positive economic incentive should already suffice to guarentee liveness, in practical implementation unexpected technical issues and unforeseen circumstances exist and the guarantee will be a parameter to balance against these mishaps. Incentives of node operation are proportional to the demand for key mangement and inversly so to the resources available and thus number of nodes operating. If the network is highly demanded, costs would increase and thus incentives - with the expectation that operators would run more nodes to accomodate for the increase. Vice versa, if demand falls, we expect nodes to be able to leave after offboarding. #### Validator node This is a lightweight validator node that also participates in the peer prediction mechanism, and has very low staking requirements. Validator nodes have to be registered on-chain ahead of time before they can start submitting reports. Increasing the number of validation nodes strengthens the guarantees of the overall reports since the PTSC scaling factor scales with number of participants. Its designed that almost any device with an internet connection can operate as a peer prediction node, and thus earn incentives from the peer prediction. ## Token usage The Torus token is native to its network. It is utilised to incentivise the stakeholders in the Torus ecosystem and/or secure its consensus. The three main mechanisms its used in are the following: * Gas and transactions fees * Stake against griefing attacks for standard nodes * Stake against griefing attacks for validator nodes * Consensus security This portion highlights an overview of the main mechanims that the token is utilized in. Many of these paramenters are to be determined as benchmarks and development proceeds on the core protocol. ### Gas and transaction fees Torus operates a smart contract layer that allows users to deploy contracts with the primary function of verifying attested information (eg. JWTs) to allow access to secrets (eg. private key). This is similar to other existing blockchains, such as Bitcoin, Ethereum, and Filecoin, where deploying and calling functions on these smart contracts cost gas/transaction fees. In order to operate accounts and store secrets on the blockchain, rent also needs to be paid as a transaction fee for the cost of storing and accessing data. A small portion of the transaction fees are paid (tip) to node operators for their work done and most of the transaction fee is burned as a base fee (basefee). The mechanism is heavily inspired by [EIP 1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) to address inefficiencies in prior first price auctions and to address long-term transaction fee instability. The mechanism inadvertently ties a token's value to its utility and creates a slight deflationary aspect for it. This removes tokens from the ecosystem. As the usage of the network grows to handle even more types of complex operations such as different types of credentialed logins, attestation on attributes of private data, and even identity management, we expect transaction fees to increase proportionally. ### Stake against griefing attacks for standard nodes As users require constant access to their keys, uptime and data availability are important metrics for the network to uphold. Service and computation on secrets held by the network is guaranteed through a constant amount of stake provided by each node. This parameter is expanded on and explained in the operation of a standard node. Standard nodes are part of the selection set for distribution of shared secrets, and although our model doesn't allow these nodes to recover the user's final secret, nodes can *withold* the shares, and thus grief the user. In order to prevent this, the user can generate a ZKP of a valid OAuth JWT, associate it with a randomly generated temporary session private key, and submit them on-chain. The standard nodes can then respond on-chain with shares, encrypted with the temporary session private key. If this is not submitted within a timeout, the user gets portion of the node's stake, and the majority of the node's stake will be slashed. In terms of token supply, this is net-neutral, and has no impact on token supply unless slashing occurs. ### Stake against griefing attacks for validator nodes Since we make use of a set of peers for validation of oracle variables, it is necessary for there to be some kind of incentive built into the protocol to ensure that these validator nodes are incentivised to answer honestly. Validator nodes are required to check an endpoint for information and validate if matches what is stated on-chain by the oracle variable owner. This is done periodically, and if the validator node is shown to be submitting an incorrect value, during the escalation phase if there is no further escalation by this validator node, their stake will be slashed. If further escalation occurs, with no clear predominant consensus, the chain will fork. Assuming a binary decision criteria, with two forks, validator nodes who voted true will have their stake slashed on the "false" fork, and vice versa. This extends to multi-decisional forks. Such a slashing mechanism disincentives voting on more than one outcome. In terms of token supply, this is net-neutral, and has no impact on token supply unless slashing occurs ### Consensus security Similar to other protocols, Torus Network secures itself via Proof of Stake (PoS). Node operators validate blocks in the chain, contributing to the security of the network. The node validating the block is chosen each time via a random algorithm and in doing so is remunerated for their work in tokens. Like other PoS protocols, in order to incentive correct behavior, the network needs to reward standard nodes for correctly verifying the transactions in each block by offering block rewards. This adds new tokens to the ecosystem and increases token supply. ## Conclusion The Torus Network is a first step towards laying the foundation for a scalable key management infrastructure that makes no compromises on security, flexibility, and self-custodiality for users. By introducing better tools for key management in an incremental way, we aim to slowly ease in a globally accepted standard for how private keys can be secured for the next wave of crypto users.