Potential Community Wallet on Polygon Miden

[Dominik1999]

Potential Community Wallet on Polygon Miden

I want to discuss a PoC of a community wallet on Polygon Miden. Miden is perfectly suitable for building wallets with all the features that Account Abstraction offers paired with privacy.

What is a community wallet?

A community wallet holds assets on a blockchain that can be used by several people, e.g., members of the same family. The wallet's contents are stored off-chain, so other users, including malicious actors, can not see them. The Miden blockchains and its overservers see only a hash, e.g., 0x131....
Different members of the community have different allowances to spend. Key rotation capabilities exist, so if key A is lost, B and some third backup key could rotate it. Sending to invalid addresses is protected by including a recall option to notes. The community could be a small group of founders in the crypto space or an astonishingly modern family.

Why are community wallets important?

Such a wallet could be interesting for many small communities. Today, there are multi-sig wallets in crypto, but their capabilities are not nearly as good as the community wallet described above. But multi-sig wallets are hard to handle and not private. Projects with crypto holdings as part of their business need safe and secure wallets. By safe, we mean being able to restore keys and having the ability to recall a transaction. By secure, we mean some protection against malicious attacks. At the same time, handling of those wallets should be user-friendly for all involved parties and even comply with some security standards as we see them in the financial sector.

Which features do smart wallets need?

• Ability to keep account contents private
• Ability to set spending limits
• Ability to remove keys and change allowances
• Ability to restore keys using social recovery
• Ability to recall transactions that are sent to the wrong address
• ...

Design ideas for a simple PoC

Most of the required features are built-in in Polygon Miden. However, we can define some neat features on top.

Ability to keep account contents private

In Miden, Accounts have two different storage modes. They can be with public or private state. When a private state is used, the Miden Operator and all other users or observers see only the account hash.

hash([account ID, 0, 0, nonce], [vault root], [storage root], [code root])

Together with Miden's asset model - all assets are stored in the account vault (not in publicly visible ERC20 contracts) - private accounts have the ability to keep the account's contents private.

However, if the account is private, then all owners of the account must still have access to the latest state to be able to update it. Miden provides several solutions for that.

Private state can be encrypted and stored onchain

One way to have the state available to all users of the wallet is to encrypt the state and store it on-chain. This will be possible in Miden; see here.

Private state can be encrypted and stored with a third-party

Another way is to store the latest state of the account on a server that everyone has access to, e.g., Google Drive. Even if this data is leaked, no external party can tamper with the funds without valid signatures. So, to get the latest state, a user (or the program he uses) could compare the local hash with the hash of the account on-chain. If that is different, the user needs to sync with Google Drive.

If all users can be trusted and no one "forgets" to update the Google drive, that should work. However, one party could censor the others by changing the state and not updating. So, the encrypted state on-chain might be preferable, depending on the type of community. There are different options to mitigate that risk:

• The third-party storage could be built in a way that it also needs to sign every state update. That way, we could ensure that the third-party storage always has the latest state.

• We could design the wallet in a way that other members need to sign the state update as well. In that case, we would be back into the multi-sig design.

Ability to set spending limits

This feature can be implemented because, in Miden, every account is a smart contract. In other words, every account has some code and an interface that exposes functions that can be called by note scripts.

So, in the community wallet, we can have a set of different keys to set different spending limits per user. It could look like this:

use std::collections::HashSet;

// Here we would define <PubKey, u64> which defines a user's public key and spending limit
struct UserLimits {
    alice: (PubKey, u64),
    bob: (PubKey, u64),
    charly: (PubKey, u64),
}

impl UserLimits {
    fn new(alice: String, bob: String, charly: String) -> Self {
        PublicKeyStore { alice, bob, charly }
    }

    fn change_key(&mut self, target: &str, new_key_and_limit: (String, u64), approvers: HashSet<&str>) -> Result<(), &'static str> {
        // Check if at least two persons agree
        if approvers.len() < 2 {
            return Err("Not enough approvers");
        }

        // Check that approvers have signed their message
        for &approver in &approvers {
            if !self.check_signature(approver) {
                return Err("Signature check failed");
            }
        }
        match target {
            "alice" => {
                self.alice = new_key;
                Ok(())
            }
            "bob" => {
                self.bob = new_key;
                Ok(())
            }
            "charly" => {
                self.charly = new_key;
                Ok(())
            }
            _ => Err("Invalid target"),
        }
    }
}

In this, two users can change the key and the limit of a third user. Every key and name could be linked to a spending limit.

Please note that this is a simplified example for illustrative purposes. In practice, you would need to consider additional security measures and error handling to ensure the contract's robustness and prevent unauthorized modifications.

Spending limits combined to create a multi-sig

In theory, we can think of all sorts of different spending limits. We could even add a function to mimic a multi-sig wallet. If a transaction is signed by Alice and Bob, they can spend their limits combined. And if all users sign a transaction, all funds can be spent.

Spending limits and non-fungible assets

Spending limits don't work with non-fungible assets. For those sorts of assets, we can define certain NFTs that can only be spent by certain users, e.g., Alice can spend the bored Ape 1 and Bob bored Ape 2.

Key management

In our community wallet, we can have one key per user. That way, we can enforce different rights, e.g., spending limits per user. Most likely, there must still be a master key for the wallet itself.

Ability to restore keys using social recovery

If a key gets lost, there could be a mechanism to create a new one by 2/3 of the owners. There can be any other threshold as well.

Ability to remove keys

If a majority of users or certain users with special capabilities want to remove another user or key from the wallet, there could be a mechanism to remove keys. The wallet can be structured to reflect any process or social consensus.

Ability to rotate keys

In theory, we can also rotate keys. Alice could own a process for a month.

Ability to recall transactions that are sent to the wrong address

If a user makes a mistake and sends funds to an address that doesn't exist, the transaction can be recalled in Miden. Read the transaction blogpost or our docs for more details.

The community wallet could have a built-in feature that only P2IDR notes could be created. Those are scripts that can be reclaimed if not consumed up to a certain block height.

[bobbinth]

Thank you! A few comments/questions:

When private state is used, the Miden Operator and all other users or observers see only the account hash.

This is true, but we need to think through this in much more detail and address various pros/cons of this approach. The biggest issue with storing the state off chain is that to be able to execute transactions against an account one must know the state of that account. Thus, if an account has two owners (e.g., Alice and Bob), if Alice updates the state of the account, Bob must know how the state has been updated, otherwise, he is locked out of the account.

This issue could be addressed in a variety of ways:

1. Store the state on chain, but encrypt it (see here).
2. Store the state off chain, but require every owner to sign all state updates.
3. Store the state off chain, but rely on a trusted 3rd party to sign all state updates (either in plaintext or encrypted).
4. Store the state off chain, but rely on a DAC with certain threshold to sign all state updates (either in plaintext or encrypted).

All of these entail different types of trade-offs which might be good to spell out. These would also interplay in various ways with setting spending limits and updating keys, etc.

So in the community wallet we can have a set of different keys that have different spending limits.

I didn't quite get the example here. Would we set a spending limit per asset (i.e., different limit for ETH, MATIC, USDC etc.)? Are we creating a separate spend function per user? Maybe a better way is to describe capabilities (rather than specific functions), because if we go with the function approach we'd probably need to get much more detailed.

A couple of other questions:

• What about combined capabilities? For example, separately Alice can spend x per day, and Bob can spend y per day. But if they both sign a transaction, such a transaction can spend z where z > x + y.
• How could we protect non-fungible assets? Simple rate-limiting won't work here.

If a key get's lost, there could be a mechanism to create a new one by 2/3 of the owners.

We probably should flesh this out a bit more (unless you think this mechanism is good enough to cover some of the below):

• Removing keys.
• Rotating keys.

Ability to recall transactions that are sent to the wrong address

I think this is actually a separate capability not tied to a wallet design (or maybe only loosely tied). I'd probably separate it into a different discussion.

[Dominik1999]

Thanks a lot @bobbinth

This issue could be addressed in a variety of ways:

1. Store the state on chain, but encrypt it (see Expand account storage mode options miden-base#139).
2. Store the state off chain, but require every owner to sign all state updates.
3. Store the state off chain, but rely on a trusted 3rd party to sign all state updates (either in plaintext or encrypted).
4. Store the state off chain, but rely on a DAC with certain threshold to sign all state updates (either in plaintext or encrypted).

I addressed this issue and mentioned two ways now, encrypted onchain and encrypted off-chain. I don't understand why everyone needs to sign all state updates when we store the data off-chain. If this were necessary, the wallet would be much more like a multi-sig.

I didn't quite get the example here. Would we set a spending limit per asset (i.e., different limit for ETH, MATIC, USDC etc.)? Are we creating a separate spend function per user? Maybe a better way is to describe capabilities (rather than specific functions), because if we go with the function approach we'd probably need to get much more detailed.

In my mind, I would start with different spending limits per user. Since this is an example to show the capabilities, it should be obvious to the reader that other spending limits could be added as well. I rephrased it. I hope it's clearer.

To me, it's easier to understand when I see the pseudo-code. I would keep it for this discussion. But we can change that and only describe the features.

We probably should flesh this out a bit more (unless you think this mechanism is good enough to cover some of the below):

• Removing keys.
• Rotating keys.

Let me add this as well, very good point.

[bobbinth]

I don't understand why everyone needs to sign all state updates when we store the data off-chain.

This is one way to ensure that everyone knows the latest state. Basically, with off-chain storage, we need a way to make sure all owners can get the latest state somehow, even if they didn't execute the last transaction. This is actually one of the main challenges and we should address it in detail.

To me, it's easier to understand when I see the pseudo-code.

If we want to keep it as pseudo-code we need to update it and add detail. For example:

• For spend_alice() what are the inputs and why are we not passing the token type?
• Why spend_alice() is used for Bob as well? I'm guessing a typo?
• In general, as single function will probably suffice as we can look up a limit based on the user's key and it would be closer to how it will actually be implemented.
• For change_limit(), what is the purpose of singed_message and why do we need to pass in the old_limit?

[Dominik1999]

Very well, I changed it.