Private state management solution

[Dominik1999]

TL;DR

Miden keeps private state (accounts and notes) off-chain, preserving user privacy and reducing on-chain data bloat. However, this architecture comes with two major challenges:

1. Loss of local state = permanent loss of access
2. Shared accounts (e.g. multisigs) require manual and insecure state sync

There are workarounds today (e.g. encrypted backups via Google Cloud), but we lack a canonical and user-friendly solution for both solo and shared state management. This discussion outlines the problems, proposes potential directions, and invites contributions for a robust and developer-friendly private state strategy.

---

Problem

1. State Loss

In Miden, private state lives locally on the user's machine. If users lose their local state (e.g., due to disk failure or device change), the state is gone forever — there’s no way to recover it from the chain or another party.

2. Shared State Synchronization

When multiple parties share control over the same account (e.g., in a multisig setup), they each need the latest state to generate valid transactions. This opens up two issues:

• Manual state exchange is required and error-prone
• Trust assumptions arise: a dishonest party can withhold or manipulate state updates, potentially invalidating others' actions or locking funds

---

Current Workaround

• The WebClient allows exporting/importing local state
• Users can manually encrypt their .mac state files (e.g., with a password or derived key) and upload them to a cloud provider like Google Drive
• State can then be re-imported on another device or restored in case of loss

However:

• There’s no standard backup format or strategy
• It’s not user-friendly
• It doesn’t solve the shared state problem

---

Vision

We envision a canonical private state management solution with the following properties:

• Automatic encryption + off-device storage (cloud, IPFS, Matrix, etc.)
• Seamless recovery on device loss
• Multi-party sync support for shared accounts, without relying on trust
• Optional delegation to “state guardians” who hold the latest encrypted state (and potentially co-sign all txs)

---

Proof of Concept Ideas

For Solo Users:

• Encrypt state client-side and store it:
  • On IPFS + pin via a gateway
  • On a cloud storage provider (Drive, Dropbox, S3)
  • On a Matrix room or secure peer channel
• Automatically retrieve latest backup on boot if keys match
• API to integrate solution for app developers

For Shared Accounts:

• Introduce a “state guardian” contract/account:
  • Guardian(s) receive state updates signed by the account controller
  • All multisig members can pull the latest state from them
  • Optionally require guardian co-signatures for tx validity
  • API to integrate solution for app developers

---

Final Product (Desired Outcomes)

• Miden Wallet and SDK offer:

  • Seamless encrypted state backup + restore
  • Pluggable backend (user-chosen cloud, IPFS, Matrix, etc.)
  • Intuitive UX for account recovery

• Shared account protocol:

  • Sync + trust-minimized coordination between multiple parties
  • Formalized support for “guardians” or sync servers

---

Timelines

Milestone	Target
PoC: Cloud-based encrypted backup	4 weeks
PoC: State guardians & sync	4 weeks
Canonical solution integrated into Wallet/SDK	2-3 month

---

Open Questions

• Where should state be stored? IPFS? Matrix? Centralized cloud? All of them?
• How can we ensure forward secrecy for backups?
• How do we coordinate state versioning between multiple users?
• What are the trade-offs between guardians vs. full p2p sync?

---

Feel free to suggest improvements, share ideas, or volunteer to prototype below! 👇

[bobbinth]

For state guardians, there are could bet two modes: encrypted and un-encrypted:

• In the un-encrypted mode, state guardians receive un-encrypted account deltas for every update, sign them, and return the signature to the user. Once the user has this signature, they can proceed with the transaction. This will be possible once we implement account delta tracking in the kernel.
• The encrypted mode would work similarly, but we'll also need to encrypt account delta in the kernel. This would require arithmetization-friendly encryption, but luckily most of the research on this is already done (see here)

[Dominik1999]

Can you elaborate again on the point, why we need to encrypt and decrypt inside the VM as opposed to outside the VM?

There might be an easy proof to ensure that the data was encrypted correctly be decrypting and hashing it and compare it against the on-chain commitment, right? But maybe I miss something.

[bobbinth]

There might be an easy proof to ensure that the data was encrypted correctly be decrypting and hashing it and compare it against the on-chain commitment, right? But maybe I miss something.

If the guardian is able to decrypt the data to verify that it is correct, then it would learn the contents of the data. So, the guardian needs to know that the data is correct without decrypting it, and I think for this we do need to encrypt the data in the VM.

[nuke-web3]

If the guardian is able to decrypt the data to verify that it is correct, then it would learn the contents of the data. So, the guardian needs to know that the data is correct without decrypting it, and I think for this we do need to encrypt the data in the VM.

Celestia has a solution for such that you can verify and "anchor" to plaintext properties without decryption: https://github.com/celestiaorg/pda-proxy/blob/main/doc/verifiable_encryption.md There is tons of room for pref and other improvements I am sure, quite happy to get any feedback you have as in issue on that repo or here. 🙏

Also Some rough research notes on VE with ideas for scope beyond the present impl: https://docs.google.com/document/d/1XZyuOxdMm5INcHwQZOZ8ALRk_YkvicNwQHSfOVs8hoM/edit?tab=t.0#heading=h.lj0dmmyi0xg5

---

We @celestiaorg are very interested in private user state management solutions, and starting forming a generalizable solution I for sure want to fit your needs!

For Solo Users:

• (Verifiably if needed) Encrypt user state client-side and store it on Celestia
  • Use a namespace per-user (or a psudo-random user client derived one, if trying to obfuscate where private user data exists)
• Automatically retrieve latest backup on boot if keys match
  • Done via app defined (possibly free to use) trusted RPC providers and/or user client integrated light node.
• API to integrate solution for app developers
  • Based on https://github.com/celestiaorg/pda-proxy/ or a yet-to-be-implemented specialized proxy for Celestia enabling Miden developers.

For Shared State Synchronization:

When multiple parties share control over the same account (e.g., in a multisig setup), they each need the latest state to generate valid transactions. This opens up two issues:

• Manual state exchange is required and error-prone
  • State exchange facilitated by coordination of all operations on Celestia.
  • (Optionally) This can be enforced at the protocol (Miden VM) level by a embedding a light client ala blobstream and requiring specific data to be available before approving state updates
  • If requiring VE to prove aspects of data w/o decryption, we could have a trusted "guardian" to process shared state, or perhaps use a MPC protocol to do it. We have basic examples of co-SNARK capability for VE using https://docs.taceo.io/docs/co-noir/ we could explore.
• Trust assumptions arise: a dishonest party can withhold or manipulate state updates, potentially invalidating others' actions or locking funds
  • Celestia was created to provide Data Availability that solves withholding attacks for rollups, it's a good fit here too.

---

I will follow up with a more formal proposal soon that we hope is applicable to user-centric private state management on Celestia. In the meantime, I would love any feedback on VE and the ideas above 😁