Name of DAO
Simplicy - ZKP-Social-Recovery-Wallets
Proposal overview
Simplicy is a protocol that enables to generate a smart contract wallet and secure the wallet using ZKP social recovery system.
Securing the wallet using a social recovery system:
- There is a single “signing key” that can be used to approve transaction (user device)
- There are at least 3 (or a much higher number) of “guardians” of the wallet, which needs to reachs concensus to recover user funds.
If a user loses their signing key, that is when the social recovery functionality would kick in. The user can simply reach out to their guardians and ask them to sign a special transaction to change the signing pubkey registered in the wallet contract to a new one. Guardians can vote anonymous using MACI and reach consensus within the wallet contract.
Simplicy Overview
Steps guardians registration/recover wallet:
- a dApp that allows Guardians to register ZKP identities
- user select guardians, reputation service stores Merkle Roots to smart contract wallet
- guardians doesn’t know which wallets, the guardian registered to by users, to prevent fraud
- to recover wallet, the user will signal the guardians, guardians needs to vote anonymously using ZKP
ZKP Recovery steps voting using Minimum Anti-Collusion Infrastructure (MACI)
Guardian voters named Alice, Bob, and Charlie register to vote to a Smart Contract Wallet by sending their public key to a smart contract. Additionally, there is a central coordinator Dave (Simplicy Wallet), whose public key is known to all.
When Alice casts her vote, she signs her vote with her private key, encrypts her signature with Dave’s public key, and submits the result to the smart contract.
Each voter may change her keypair at any time. To do this, she creates and signs a key-change command, encrypts it, and sends it to the smart contract. This makes it impossible for a briber to ever be sure that their bribe has any effect on the bribee’s vote.
if Bob, for instance, bribes Alice to vote a certain way, she can simply use the first public key she had registered — which is now void — to cast a vote. Since said vote is encrypted, as was the key-changing message which Alice had previously sent to Dave, Bob has no way to tell if Alice had indeed voted the way he wanted her to.
Even if Alice reveals the cleartext of her vote to Bob, she just needs to not show him the updated key command that she previously used to invalidate that key. In short, as long as she had submitted a single encrypted command before her vote, there is no way to tell if said vote is valid or not.
EIP-2535: Diamonds, Multi-Facet Proxy
EIP-2535 Diamonds is a contract standard that standardised contract interfaces and implementation details to implement the diamond pattern. The standardisation makes integration with tools and other software possible.
The diamond pattern is a contract that uses a fallback function to delegate function calls to multiple other contracts called facets. Conceptually a diamond can be thought of as a contract that gets its external functions from other contracts. A diamond has four standard functions (called the loupe) that report what functions and facets a diamond has. A diamond has a DiamondCut event that reports all functions/facets that are added/replaced/removed on a diamond, making upgrades on diamonds transparent.
The diamond pattern is a code implementation and organisation strategy. The diamond pattern makes it possible to implement a lot of contract functionality that is compartmented into separate areas of functionality, but still using the same Ethereum address. The code is further simplified and saves gas because state variables are shared between facets.
Diamonds are not limited by the maximum contract size which is 24KB.
Facets can be deployed once and reused by any number of diamonds.
Diamonds can be upgradeable or immutable. They can be upgradeable and at a later date become immutable. Diamonds support fine-grained upgrades which means it is possible to add/replace/remove only the parts desired. Everything does not have to be redeployed in order to make a change. A diamond does not solve all upgrade issues and problems but makes some things easier and better.
Smart Contract Architecture
Application type
zkDAO
Proposal ask
The total proposal ask worth of $100k
The ZKP-Social-Recovery-Wallets is established to be community-driven and self-funded by the DAO in a bid to bring privacy to the DAOs. In order to get this up and running, I will be requesting the $15k/year stable basic income to take care of initial development, welfare and operations costs.
This ask will be in line with the laid down milestones as detailed below
- launching a feature-complete product on Harmony One testnet ($10K)
- forming a DAO with 5-out-of-9 multisig with our DAOs ($10K)
- launching on Harmony mainnet with audit ($10k)
- attracting 1k daily active users (with launch video, full PR promotion) ($10k)
- attracting 10k daily active users (with a detailed roadmap, governance process) ($10k)
Roadmap
| Objective | Date | Status | |
|---|---|---|---|
| - | Circuit design | June 6th | Done |
| - | Demo Week5 assignment | June 6th | in Progress |
| - | Testnet launch | June 30th | Pending |
| - | Demo PoC | TBA | Pending |
| - | DOA | TBA | Pending |
| - | Smart Contract Audit | TBA | Pending |
| - | Mainnet launch | TBA | Pending |
Use Cases
This (mobile) application will serve average users that have challenges to use cryptocurrency wallet.
Problems
Average users:
- How can I prevent funds for being lost of stolen?
- How can I recover my funds when my device is lost or stolen?
Guardians:
- How do we prevent guardians addresses and private information saved into wallet contract of user?
Solidity developer:
- How can I create a Modular smart contract systems that can be extended after deployment?
- How to write a smart contract wallet with virtually no size limit?
- How to separate Business Logic (Business process) from storage data?
Solutions for average user and guardians
To solve this issue user needs wallet that satisfies four key criteria:
- no single point of failure
- low mental overhead
- maximum ease of transacting
- guardians vote’s to reach consensus
I can solve above issues by:
- social recovery system using ZKP
- ZKP recovery steps using Minimum Anti-Collusion Infrastructure (MACI)
Solutions smart contract developer
Use Diamonds, Multi-Facet Proxy contract for the Factory contract
Competitive Landscape
There are other good implemented smart contracts wallet like, Loopring, Argent and Multisig Wallet like Gnosis.
There are main disadvantage of those wallets, mainly is that the addresses of the guardians or signer are publicly registered in Blockchain. So everyone see who your guardians are and guardians knows which wallets they registered to.
- To prevent fraud of the guardians or signers, we will need to create anonymous registration of the guardians and also guardians doesn’t need to know on which wallet there are registered to.
Metrics for success
| Milestone | Number of users | Status |
|---|---|---|
| Guardian registration | 5 | Pending |
| User wallet creation | 1000 | Pending |
| User wallet transactions | 10000 | Pending |
External links
Source code
Guardian registration
Guardians votes
ZKP-Social-Recovery-Wallet
Smart Contracts