Security Architecture
Last updated
Last updated
When we consider creating an OnChain wallet, the first thing we need to be clear about is who our users are and what problems we need to solve. Although blockchain technology has developed for many years and has gained a certain degree of popularity, it is still far from reaching the general public. The fundamental problem lies in the lack of a secure and user-friendly wallet entrance to facilitate people's access to the web3.0 world anytime and anywhere.
Q: Who are our users?
A: Our target users are ordinary people who are blocked by the blockchain threshold due to a lack of professional skills.
Q: What problem do we need to solve?
A: To answer this question, we must be clear about the greatest pain point of OnChain wallets, which is the management of private keys or mnemonic phrases. In the blockchain world, private keys control everything. Once lost or stolen, it means the permanent loss of assets, which is difficult for ordinary people to bear. We hope to create a product that is decentralized, secure, and easy to use, providing an experience similar to web2.0, without worrying about the security of private keys. Users only need to log in to the website to enjoy the blockchain.
Based on the above considerations, we chose the MPC (Secure Multi-Party Computation) technology, which can achieve TSS (Threshold Signature Scheme), i.e., distributed key generation and transaction signing.
There are several benefits to doing this:
No single point of failure for private keys: each participant only has a partial private key fragment. From creating an account to signing a transaction, the complete private key has never existed throughout the entire lifecycle, completely eliminating the risk of private key theft.
Higher security: TSS supports private key rotation, and the corresponding public key and address on the blockchain can be updated without changing them. This structure adds a temporary dimension to security, and a single private key loss or leakage can be reset and recovered, while the attacker must simultaneously attack multiple private key devices before the private key rotates.
Disadvantages of traditional MPC:
The private key is split into several fragments, and each fragment is kept by someone.
For example, the 5-8 structure requires all five participants to be online and interact in real-time each time they sign, which greatly reduces usability and performance. On the other hand, fewer splits will decrease security.
For example, the 2-2 structure requires both parties to make sufficient backups. Once lost, only the other party cannot reset and recover it.
More fragments will lead to longer waiting times for users to initiate transactions, which reduces the experience.
Fewer allocations will reduce security. For example, the popular 2-2 and 2-3 structures:
The 2-2 structure cannot recover the key if one party loses it, and there is a risk of user transactions being audited.
The 2-3 structure usually stores one of the recover keys in a third-party trusted party, and when lost, the user goes to recover it and rebuild the key. There is still a risk of user transactions being audited.
Based on the above pain points and the shortcomings of existing solutions, we have released the EIP4337 Wallet based on the Sodium MPC Network. The MPC fragments are maintained by the PoSA consensus-driven validator committee. Based on the Sodium Network, users can achieve high security and usability while being far away from the biggest pain point of wallets.
On the Ethereum-compatible chain, we will maintain an MPCManager smart contract for users, which is used to store the current MPC public key of the Sodium network.
When a user requests to log in to the wallet, the following events will occur:
Based on the threshold set by the user, OAuth provider (google, twitter, facebook...) is requested for verification. Obtain OAuthToken.
(We support user-set OAuth thresholds to prevent the risk of wallet theft due to a single social media account being stolen.)
For example, a user can bind the wallet to three social media accounts, Google, Twitter, and Facebook, and set that two of them must be verified. This can prevent the risk of a single social media account (lost, being audited by a single social media, or stolen) leading to the theft of the wallet.
Secure session key is generated on the user's local device and saved in secure storage on the device.
OAuthToken is signed with the session key and sent to the Sodium network.
This step is to prevent node operators or network gateways from stealing your OAuthToken and impersonating you for verification.
Request MPC signature from the Sodium network using the session key and the real OAuthToken.
At this time, the Sodium network will perform traditional OAuth verification. Only when 2/3+1 nodes pass the verification, can the signature be obtained.
Submit the MPC signature and session key public key to the EIP4337-wallet to complete log in.
We use governance token say YToken for example and similar Ethereum Casper consensus. When initiating an MPC signature, the validator must stake a certain amount of Y tokens to perform MPC signature. The signature result may be passed, in which case most nodes pass, or rejected.
When passed quantity ≥ 2/3+1, passed nodes receive inflation rewards, and rejected nodes can only reclaim a portion of their staked Y tokens.
When passed < 2/3+1, rejected nodes will receive inflation rewards, and passed nodes can only reclaim a portion of their staked Y tokens.
According to the above situation, we divide the nodes into three types:
Attack nodes that attempt to make malicious signatures (malicious rejection or agreement)
Their behavior will cause their YToken to be reduced. Each attack will bring high costs.
Honest network guardians
Will receive network rewards
Nodes that are inactive (do not participate in any signatures)
Will not receive any rewards or punishments, but their YToken will be subject to inflation depreciation.
Will be expelled every 130,000 blocks.
FAQ:
Does requesting an MPC signature from the Sodium network require gas?
We will provide users with 2 free opportunities per month. If exceeded, they need to pay a certain amount of gas fees. This helps the Sodium network resist malicious DDOS attacks.
What if a validator stops working or does not sign?
The Sodium chain will execute a Rotation every 130,000 blocks, which will eliminate inactive validators and ensure the vitality of the network