Refactor backend

[enricobottazzi]

As described in the blogpost, the AddressOwnership part and the Round part should be two separate (and asynchronous) steps.

summa-solvency/backend/src/apis/snapshot.rs

Lines 25 to 29 in 90c4242

	pub struct Snapshot<const LEVELS: usize, const N_ASSETS: usize, const N_BYTES: usize> {
	mst: MerkleSumTree<N_ASSETS, N_BYTES>,
	proof_of_address_ownership: AddressOwnershipProof,
	trusted_setup: [SetupArtifcats; 2], // the first trusted setup relates to MstInclusionCircuit, the second related to SolvencyCircuit
	}

In particular, proof_of_address_ownership should be independent from a Snapshot.

EDIT: As I was reviewing #141 I noticed that Snapshot and SummaSigner are completely independent and do not talk to each other. Snapshot APIs was originally planned to be the entry point for a user of the backend, but actually, they cannot do much with that as they cannot interact with the contract!

Following the description and the naming in the blogpost, I think we should have two high-level classes: AddressOwnership and Round.

AddressOwnership should be used to submit proof of solvency to the Smart Contract

Round should be used to:

• Build a Snapshot (which is only composed by a Merkle Sum Tree and Assets)
• Submit proof of solvency to the Smart Contract
• Generate proof of inclusion to the user.

The goal should be to allow the user (exchange) of our library to fully complete the flow described in the blogpost

[sifnoc]

EDIT: As I was reviewing #141 I noticed that Snapshot and SummaSigner are completely independent and do not talk to each other. Snapshot APIs was originally planned to be the entry point for a user of the backend, but actually, they cannot do much with that as they cannot interact with the contract!

Yes, you are correct. The Snapshot API that follows the original plan largely mirrors the CLI app from the PoC - summa-playground.
Most of the functions in the CLI app can be used for the Snapshot API. Therefore, we can reshape those functions for the Snapshot API while renaming the current Snapshot to SnapshotData.

Following the description and the naming in the blogpost, I think we should have two high-level classes: AddressOwnership and Round.

Separating AddressOwnership makes sense to me, especially the optimistic approach that eliminates the need for verifying solvency based on addresses in the contract.

The term Round reminds me of its usage in the early design - Design Core components for API - Round.
However, I believe you're referring to something different: a single Snapshot instance existing within the Round like one below:

struct Round {
	snapshot: Snapshot,
	signer: SummaSigner,
}

struct Snapshot {
	mst: MerkleSumTree,
    trusted_setup: [SetupArtifcats; 2],
}

generic consts are ignored in above.

[enricobottazzi]

struct Round {
	snapshot: Snapshot,
	signer: SummaSigner,
}

struct Snapshot {
	mst: MerkleSumTree,
    trusted_setup: [SetupArtifcats; 2],
}

I like this. We can go ahead. Also, all the core methods run by the CEX should be on Round namely:

• build_snapshot
• submit_proof_of_solvency
• generate_proof_of_inclusion

AddressOwnership struct should also leverage the SummaSigner and expose the API submit_proof_of_address_ownership