Zkipper

Problem Statement

Our solution builds upon the new EIP-7702 standard to create a flexible smart account. When a transaction needs to be signed, tx is rated on its criticity, in order to be signed either by admin, or user. The flow is:Role Identification: At entrance of contract, transactions are designed a role for the signature, according to their criticity.ZkSafe: The governance model is hidden by a ZkProof Verification of the ARX wrist signer.Wristband Interaction for low crit tx: The wristband's ARX chip securely generates a signature using its embedded key, it is used to generate the witnesses of the zkProof (ECDSA over k1).Post-Quantum Signing for admin tx: The signature is then processed with the FALCON post-quantum algorithm (via JavaScript integration).The sudo account is protected by FALCON signatures, while standard commands are signed by ecdsa. At the entrance of Zkeeper, an analyzer estimates the level (sudo, standard) of the transaction. Then it is forwarded to be signed by the right role. Looking at Bybit and top 2024 hacks, separating user from admin cmd would have prevent them.

Solution

Preexisting pieces: The project relies on the gnark proving library by Consensys, the ETHFALCON post quantum library by ZKNOX (us), and the HALO NFC library by ARX (the wristband chip provider).Accomplished workmopro-gnark: gnark circuits have been binded in rust, and are used for the zkSafe module EIP7702: the smart Account integrates ZKNOX FALCON verification and the above verifier for the RBACMocked partsThe analysis of transactions is mocked by a simple analysis of the amount of the transaction. In the future, a service like blockAID or similar, instead of being limited to Go/noGO shall provide the role required to execute the transaction. For instance any delegate call could be detected and require admin (sudo) rights. The ZK verifier only takes one signer, in the future any k out of m circuit can be used instead.