Abstract

Our key concept is centered around the creation of a module for Safe multisig that ensures the anonymity of all its participants using ZK-SNARK technology.

We consider this idea significant as it can be beneficial to both regular users seeking to enhance their level of anonymity and large treasuries aiming to conceal key individuals and their votes.

Our research has led to several key ideas that we deem important to mention:

1. Using a Merkle tree for public keys of participants: We propose employing a Merkle tree where the leaves consist of the public keys of participants. The root of the Merkle tree is stored within the module's contract. To vote for the execution of a transaction, a candidate must prove that they possess a valid message signature such that the account with private key used for the signature is located within the Merkle tree.
2. Using a Merkle tree for "secrets": We also suggest an alternative approach, utilizing a Merkle tree for storing "secrets." These "secrets" could, for instance, correspond to specific signature standards (details provided in the full description). To vote for the execution of a transaction, a candidate must demonstrate knowledge of the relevant "secret" and its position within the Merkle tree.

These ideas will be elaborated upon in this proposal.

1. Using a Merkle tree for participants' public keys

Concept: Creating a Merkle tree where the leaves consist of the public keys of participants in the multisig. To vote "for" a transaction, a participant must prove that they possess a valid signature for the message and that their public key is within the Merkle tree.

Module Integration with Safe:

• Deploy Safe or use an existing one.
• Deploy the module.
• Connect the module to Safe.
• Initialize module via Safe, setting the Merkle tree root and the vote threshold for transaction execution.

Prove:

To provide proof, the prover must demonstrate that they know a valid message signature and that the corresponding public key is in the Merkle tree.

To ensure participant anonymity in the multisig, all parameters that could reveal their identity, such as the signature, public key, signer's address, and others, must be concealed.

A crucial element of the system is the use of ZK-SNARK technology, which allows proving the voting fact without disclosing sensitive data.

Our goal is to create a program (referred to as a "circuit") implementing ZK-SNARK to generate a proof for a specific message. To have a message with a fixed length, we use a hash function. Elements of the message:

1. address to, uint256 value, bytes memory data, Enum.Operation operation: These parameters represent the arguments of the execTransactionFromModule and execTransactionFromModuleReturnData API functions for module interaction with Safe. The data types of most elements are of fixed length, except for the bytes type, which we convert to fixed length using a hash function.