Privacy group management

[peterbroadhurst]

Work in progress

Scope

• Lifecycle management APIs for privacy groups
• Distribution of privacy groups as objects between Paladin nodes
• EVM transaction submission directly to privacy groups, as similar to eth_sendTransaction as possible

This is not the full scope of what privacy groups could evolve to being in Paladin, but it represents a very significant simplifying step for app developers. I believe it also takes us beyond the feature set for privacy group management provided in any previous generation of Privacy-group/Channel tech (particularly for managing huge numbers of privacy groups).

Deferred scope

In this scope I deliberately defer some key things that have been discussed as vision:

• Support for eth_sendRawTransaction semantics
  • Requires synchronous assemble - pushes on big picture items around externally managed keys / signing / proofs
• Support for eth_getTranasctionReceipt semantics
  • Requires nonce to be known at send TX time, so pulls in same challenges as eth_sendRawTransaction
• Support for eth_getBlockByNumber / eth_getLogs etc. semantics
  • Some bigger decisions to be made before we can treat these privacy groups like full EVM chains

However, this PR is a step towards all of the above.

Architecture

Filling in detail as I go here

Data model for Privacy Groups

I am proposing that each Privacy Group is identified by the ID of a state.
This means it has:

• A domain
• A schema ID
• A salt (inside the state)
• Arbitrary numbers of queryable properties, typed according to a schema
• A rolled up Hash-based ID for the state that is a factor of all properties - including membership

Due to the distributed nature of privacy groups, where they are generated by one party and shared with another, this has lots of really important characteristics around clash-prevention. We can't do something as simplistic as assuming a single common property called name can be made globally unique. We also can't assume any group of parties will have a single privacy group - there could be thousands/millions, if a new privacy group is used for each bi-lateral transaction for example.

It also means I do not need to re-write all the query semantics for generic indexable fields, as they are re-used from states.

But it does mean some restrictions on the API:

• To find a Privacy Group by a property (like name), you need to know the schema
• You cannot easily query across all schemas on a privacy group

It also means the ABI schema for a privacy group will need to be distributed with that privacy group, and we'll need a new domain API integration point to validate that a schema and privacy group is parsable by it.