RFC-0004: Redesign RingLocation in host_account_create_proof

[filvecchiato]

RFC: Redesign RingLocation in host_account_create_proof

Summary

Replaces the current RingLocation struct with a junction-based addressing scheme to fix request invalidation from stale ring_root_hash and enable multi-ring pallet support.

Checklist

• Added docs/rfcs/0004-ringlocation-redesign.md with completed frontmatter
• Filled all RFC sections (Summary, Motivation, Detailed Design, Drawbacks, Alternatives, Unresolved Questions)
• Updated docs/rfcs/_index.md with a link to the new RFC
• Added labels: rfc, proposal

Motivation

Resolves #56. The current RingLocation relies on ring_root_hash which becomes stale when ring membership changes, and cannot address rings within multi-collection pallets.

[TorstenStueber]

@filvecchiato is this RFC still relevant?

[Zebedeusz]

The changes introduced here might help with the personhood check in products, although some modifications would be needed.

Since each product uses a derived user's address, they would not be able to benefit from the assignment of alias-account that could be done (it currently automatically is not done in the personhood acquisition flow) to the main user's address.
Thus the solutions we're proposing for this are https://github.com/paritytech/individuality/pull/878 and https://github.com/paritytech/individuality/pull/891.

To make 891 work, the Host API would have to generate proofs in a slightly different way though, something more like:

enum RingLocationJunction {
    Chain(GenesisHash),
    PalletInstance(u8),
    CollectionId(Vec<u8>),
}

type RingLocation = Vec<RingLocationJunction>;

struct RingVrfProof {
    proof: Vec<u8>,
    ring_index: u32,
    ring_revision: u32,
}

fn host_account_create_proof(
    domain: ProductAccountId,
    ring: RingLocation,
    message: Vec<u8>
) -> Result<RingVrfProof, CreateProofErr>;

so mostly moving ring_index from fn argument to fn output.
All that, so that the product (smart contract) can call the precompile from 891 personhoodInfoByProof.

I want to also highlight a few doubts: how will the product know all the ring location information (chain, pallet id and ring index)? Also, does it matter to them - why not abstracting it away?

[filvecchiato]

closing in favour of paritytech/truapi#18