Anoma/Namada SSS Requirements

Cryptography Zoo Shielded State Sync
1

Since we want to have shielded state synchronisation for both Anoma and Namada, but they have quite different requirements, it makes sense to write the requirements down and keep track of them, so that we can more efficiently switch between contexts.

Namada Anoma
Transfer types Sender → Receiver Sender → Solver → Receiver
Transaction types Simple transfers Programmable transfers
Requires verifiable circuit-friendly FMD :x: :white_check_mark:

Primitive comparison

Namada Cairo-RM
Proving system Groth16 Cairo (STARK)
Note/resource encryption chacha20-poly1305 Poseidon
FMD encryption FMD-friendly FMD-friendly + circuit-friendly

The Namada version of SSS seems to be simpler: we don’t depend at all on other primitives used in Namada, the only thing we might want to bind to the existing Namada mechanisms is the detection key generation mechanism (sort of another branch in the imaginary key hierarchy). At the same time, we are somewhat limited by the fact that Namada is already live, so we can’t change too much (luckily, we don’t really need to).

For Anoma it is more complicated. Since we want FMD to be verifiable (for the same reasons we need encryption to be verifiable), we want to implement the verification in circuit, which implies some limitations on our choices. The key generation mechanism is also something to explore.

Another thing to remember is that while some things apply to Anoma generally, we essentially are working with a specific instantiation of the ARM, Cairo-RM. So we should be careful not to generalise our judgements about the Cairo-RM instantiation to the ARM interface.

This document is planned to be periodically updated

2 Likes
2

Another topic to consider for the Anoma case – perhaps not right now, but in the near future – is the “push-based” SSS method. Let me provide a bit of context:

  1. Currently, with FMD+TEE (and other approaches), we’re designing what I think could be called a “pull-based” method of shielded state synchronization, which has the following basic flow:
    a. The user knows state up to “block” B_n (“block” can be understood as a more general unit of network time, it could also be an epoch or reference multiple chains),
    b. The user wants to download state from B_n to B_{n+k}, in a way which:
    - does not require meaningfully compromising their privacy, and
    - requires work no more than linear in the state changes which are actually relevant to them.

    We will always need a “pull-based” method of SSS, but for Anoma at least we have another option, namely:

  2. Push-based shielded state synchronization, which has the following basic flow:
    a. A user A participates in an interaction (e.g. intent matching) with user B, and wants to ensure that user B gets notified of the interaction (which contains state updates relevant to B), in a way which:
    - requires work no more than linear in the state changes which are actually relevant to B, for both A and B,
    - can work even if B is currently offline (say, can work if B comes online within a certain time bound), and
    - does not require meaningfully compromising the privacy of A or B.

    We haven’t investigated methods here much at all yet, but for example, I could imagine that general approaches may be similar to approaches for network-layer privacy – e.g. an onion-routed mixnet with additional tolerance for longer duration store-and-forward.

In at least the near-term future, for Anoma, I think the optimal route will be some combination of pull-based and push-based SSS, where:

  • Users who come online reasonably frequently can mostly rely on push-based SSS to retrieve the state necessary for their immediate interactions, which has the potential to be extremely efficient, and
  • Users who come online less frequently can always synchronize with pull-based SSS, and
  • All users can periodically run pull-based SSS in the background to ensure no state updates were missed.

Push-based SSS is especially important for Anoma because there will be much more state, not just one chain – potentially an “infinite” amount of state (relative to computational capacity), nearly all of which is not relevant to any given user.

1 Like
3

Not sure what exactly you have in mind, but the use of mixnets reminded me of the following idea to mitigate the impact of leaking FMD detection keys.

Above, we may replace the entire pool of states with periodic batches, flag ciphertexts with actual user identities, and run the mixnet twice:

  • In the output of the first run, user identities are revealed but states are encrypted under the mixnet joint public key.
  • In the output of the second run, states for a given user are encrypted under the public key of the user.

The above may not meet the stated efficiency requirements, though. Also one may be reluctant to rely on mixnets for anonymity. (Just wanted to share.)

1 Like
4

Thanks @kike - I do think these ideas are relevant, there is a wide design space here. One note is that in general I do not think push-based SSS requires this concept of a single public shielded state pool BB_0 – or, at least, it doesn’t require that communication happens through BB_0. One could image, for example, that some sender places shielded state for a receiver in BB_0, and sends a separate message containing some index or way to look up that piece of shielded state through a store-and-forward mixnet addressed such as to reach the receiver, but where a third party would have no way to correlate any messages in the mixnet to a particular piece of shielded state. That property alone, in combination with some delays to frustrate timing attacks and perhaps occasional decoys, should give us pretty strong privacy guarantees, I think.

5

Just linking the relevant papers here for the context:

1 Like