[Discussion] Cross-Chain Synchronization for Multi-sig Wallets
Authors:
- Vadim Makovsky (vadim.makovsky@gmail.com, telegram: @vadimicus, x: @vadimicus)
- Nikita Kaskov (mail.nikita.kaskov@gmail.com, telegram: @nkaskov)
- Mikhail Voronov (michail.vms@gmail.com, x: @vms11)
Created: 2024-08-28
Abstract
This proposal introduces a new approach to creating and managing multi-sig wallets across different Layer 2 (L2) networks, enhancing the user experience. When the configuration of the master wallet on the Ethereum blockchain is changed, the corresponding changes of the owners set are automatically across all dependent wallets on the L2 networks. The update process requires a valid zk-proof to confirm the new signers.
The final solution will include a ready-to-use safe module, along with full-cycle integration into the proving protocol, covering proof building and verification.
Proposal types
Other SEPs
Proposal details
Purpose and Background
This proposal aims to enhance the user experience in managing cross-chain multi-sig accounts. Currently, when users want to change a signer in such a wallet, they must manually create, sign, and approve the same transaction across all blockchains or rollups where the wallet exists. This process requires the presence and action of all signers throughout and incurs gas fees on each blockchain or rollup.
This initiative proposes using a zero-knowledge proof approach to propagate updated signers across all protocols with a single action.
Effects and Impact Analysis
Pros:
- Provides a reliable synchronization method that improves user experience.
- Reduces the risk of human error.
- Advances in the development of omni-chain architecture.
- Requires less or the same amount of gas.
Cons:
- Requires an additional module.
Risks:
- The Modules allowed to modify Owners set have the highest access level to the Safe account, so a proper audit is crucial.
- Implementation complexities due to the different configurations of the Safes.
Implementation
In the context of the interchain sync, there is a master chain (the preferable options are the Gnosis Chain and the Ethereum Mainnet) and several follower chains (such as Arbitrum, Polygon, and others).
The trustless sync mechanism will consist of several parts:
- The off-chain indexer of the master chain
- The off-chain zk-proving part (includes the multi-sig verification circuit)
- The endpoints on the follower chains
Integration with the Safe contracts
The integration with the Safe contracts will be done through a Safe module that will manage the zk-proof verification and trigger Safe’s OwnerManager to apply the verified changes in the multi-sig configuration.
Open Questions
We can implement the module in three different ways, and each will require a different amount of resources.
-
Separate module
We can implement our module as a separate app, with its GUI and repository inside our Github org. This is the most resource-demanding option since it requires us to build an additional UI part of the module.
-
A Zodiac module
The module can be implemented as part of Zodiac library. In that case, it will become a standalone repository in the Gnosisbuild Github org. This approach will allow simple integration with different DAO instruments implemented by Gnosis Guild.
-
A Safe module
The module can be implemented as part of the Safe Modules repository. This approach will allow integration with Passkeys-based modules in the same repository.
Funding Request
Separate module
$45,000 = $35,000 core functionality + $10,000 UI part
A Zodiac module
$35,000
A Safe module
$35,000
Upfront Funding
Ideally, 100% in order to fund the audit. Can do in installments of 50% as well.
Metrics and KPIs
We are working on Dune visualization and are going to add it in this section before the start of voting for the proposal
- Number of manual transactions changing the Owners set on follower networks
- Number of Successful Account Synchronizations
- User satisfaction rating
- Security incidents reported
Timeline and Milestones
Phase I. Proving in testnets
- 7 weeks: Design and implementation of the threshold multi-sig verification circuit
- 4 weeks: Implementation of indexers and provers. Provers management CLI development.
- 2 weeks: Deployment of testnet follower chains verifiers. Integration of verifiers with the testnet Safe contracts.
Phase II. Distributed proving in testnets
Duration of this phase depends on how the module will be presented to the end users.
- 3 weeks: Implementation of intermediate verification strategies and fault-tolerance algorithms of proof aggregation.
-
Separate module
- 4 weeks: UI for the module.
-
A Zodiac module
- 2 weeks: integration with the Zodiac library
-
A Safe module
- 2 weeks: integration with the Safe Modules repository
Phase III. Distributed proving in mainnet
The timelines of this phase will depend significantly on the security audit, so for now, we will only describe the intermediate steps.
TBD (est. 5 weeks): Deployment of the mainnet follower chains verifiers and integration of
the verifiers with the mainnet Safe contracts.
Team
- Vadim Makovsky
- Email: vadim.makovsky@gmail.com
- Github: @vadimicus
- Telegram: @vadimicus
- x: @vadimicus
- Nikita Kaskov
- Email: mail.nikita.kaskov@gmail.com
- Github: @nkaskov
- Telegram: @nkaskov
- Mikhail Voronov
- Email: michail.vms@gmail.com
- Github: @mikevoronov
- x: @vms11
Copyright
Copyright and related rights waived via CC0. Code open source with MIT license.