Private account decentralization

[vlopes11]

Use case

Consider the following requirements:

• The operator will have full access to the state of the private account (some delay is tolerable).
• The clients of the account will have the ability to view transactions in which they act as either the recipient or sender.
• The clients of the account will be able to submit transactions even in case the operator is temporarily offline.

Problem statement

At present, concurrent modifications of a private account's state by different actors are not supported if they don't have the complete state of that account. Even if they had the complete state, this would generate race conditions.

Centralized model

In this simple example, Bob generates a note and shares with both the Operator and the recipient, Alice. The Operator then generates a zero-knowledge proof for verifying the state transition, which can subsequently be submitted to the network, to update a private account. Carol cannot read the contents of this transaction from the public state of the chain.

This model is centralized, with the operator maintaining the off-chain state of each private account and receiving transactions for subsequent inclusion in a Zero-Knowledge (ZK) proof (check 0xPolygonMiden/miden-vm#222).

In certain applications, decentralization becomes essential due to the necessity to maintain the complete account state as well as ensuring service availability, thus preventing a system-wide shutdown in case the operator is offline. One possible approach to accomplish this is by employing multiple operators who can submit ZK proofs, provided they all possess and maintain synchronized full states of the system, and have a consensus mechanism to synchronize transaction execution.

Decentralization

To achieve decentralization, we require a consensus mechanism in place and for all clients to possess a complete account state. However, this contradicts our requirements as each account is only allowed to hold transactions where they are involved.

In theory, if we could produce ZK transition proofs from a partial state managed by the operator, individual account clients could maintain such partial states and submit ZK proofs of the transitions. These proofs could be directly submitted to the network or aggregated by the operator.

Centralized storage of entire state data in private accounts impedes efficient partial state updates due to the necessity of having the full state for each transition witness computation. Even if an account's state is represented as Merkle trees, synchronizing partial states with associated sibling nodes to ensure valid proofs necessitates locking the entire account until a client can produce a transition proof. This centralized coordination defeats the decentralization principle by introducing complex synchronization issues with numerous race conditions.

Discussion

A potential solution could involve partitioning a single hash representing private accounts into multiple hashes. By implementing this functionality, each partitioned hash can serve as a root of a Merkle tree, corresponding to a partial state of the account. This structure allows individual clients to produce independent proofs of their transactional history. These clients can continue to transmit transactions to the operator for maintenance of the global state, and any discrepancy between the anticipated state root of a client's sub-account and the current state hash would indicate an incorrect submission of transactions, potentially leading to penalties such as blacklisting the account until the state is reconciled.

This setup ensures that the operator consistently possesses the valid full state of clients and empowers them to generate proofs for their respective accounts.

[bobbinth]

Thank you for the detailed write-up! A few preliminary thoughts/comments:

The operator will have full access to the state of the private account (some delay is tolerable).

In a centralized setting this is pretty straight-forward (i.e., the user just sends the state deltas together with the transaction to the operator) and we are planning to do this as a part of mainnet launch.

In a decentralized setting, this is still an open question. Could potentially be solved using something like threshold decryption, but not sure if that's a good idea.

The clients of the account will have the ability to view transactions in which they act as either the recipient or sender.

For sender, this is already true today. But for recipient this is tricky - though, depends on what exactly we mean by "transaction" here. If we mean the Transaction object, then I'm not sure this is doable as the recipient can only detect notes that were sent to them, but may not have visibility into of which transaction generated these notes (they would know who the sender was, though).

The clients of the account will be able to submit transactions even in case the operator is temporarily offline.

If the operator is offline, who are we submitted the transactions to?

At present, concurrent modifications of a private account's state by different actors are not supported if they don't have the complete state of that account. Even if they had the complete state, this would generate race conditions.

It is not clear to me how this ties to the requirements described above this paragraph. But generally-speaking, we should avoid designs where account ownership is ambiguous, specifically to avoid the need for concurrent state updates. If we do need to support multiple account owners, potential solutions could be:

• Users coordinate updates amongst themselves (works if the number of users is small).
• Introduce some synchronization entity which needs to sign off on sequential state updates.
• Probably something else.

But again, it is not clear to me why this is needed/desirable. Could you elaborate on the context for this?

[Dominik1999]

At present, concurrent modifications of a private account's state by different actors are not supported if they don't have the complete state of that account. Even if they had the complete state, this would generate race conditions.

Do you need concurrent modifications or simply multi-party ownership of a private account?

One way might be what that oracle team has built: There is a top-level account that reads multiple other account states in its transaction. Each sub-level account can be modified independently and thus concurrently. Then, sequentially, the top-level account can be updated, let's say, every other blocks or so.

Happy to find a solution together with you, but currently I am not 100% sure which use case you are targeting.

Regarding your requirements (as Bobbin already pointed out):

The operator will have full access to the state of the private account (some delay is tolerable).
This is given in the current design (that we aim to have for mainnet)

The clients of the account will have the ability to view transactions in which they act as either the recipient or sender.
The sender always knows the contents of the transaction. The recipient can always know the note. But a transaction is defined as the state transition of a single account (e.g., the sender). Why do you need the recipient to view the transition of the sending account?

Note: You need two transactions to facilitate an asset transfer (A changes it state and produces a note, B changes it state and consumes that note)

The clients of the account will be able to submit transactions even in case the operator is temporarily offline.
You can (optimistically) consume notes if the operator is temporarily offline. But there is no way to prevent double-spending. In a centralized model it will be hard to continue the blockchain if the operator is offline. Miden will be decentralized in the future.