Private validators

[mversic]

Let's move the discussion from telegram here:

Let's tentatively call a national payment system "domestic chain" here.
The question is, how can a domestic chain be sure that a transaction sent to the hub chain has been committed?
There might be 3 ways:

1. A domestic node operator also operates a hub chain node, and there is some kind of local channel for verification between them
2. A hub chain node exposes block streaming endpoint and a domestic node subscribes to full block payload
3. A domestic node (verifier) requests a transaction inclusion proof and a hub chain node (prover) returns a merkle proof

I said "light client" in the context of an implementation for case 3.
The idea is to finalize a pending transaction in response to the inclusion proof

Reference

Chain itself would not communicate with the outside world.
Representations of outgoing transactions vary by protocol:

• escrow/burn (IBC)
• transfer to a mirror area (liquidity pool) for the other chain (TOKI)

And a third party called a relayer is responsible for reading the intention of the outgoing transaction from A chain and communicating it to B chain.
(It would be worth noting that both chains do not need to trust relayers)
The light client (a smartcontract) on B chain would verify and apply the intention of the incoming transaction

comments by @s8sato on telegram

[dmitrivenger]

@Erigara , @s8sato and @mversic Let's come up with a comprehensive list of questions here, before we'll call for another workshop with @takemiyamakoto.

[dmitrivenger]

Guys, I've got some info on Polkaswap parachains. I hope you can find find some useful info there:

https://paritytech.github.io/polkadot-sdk/book/protocol-overview.html
https://wiki.polkadot.network/docs/learn-parachains

[Erigara]

Review of approaches to cross chain interoperability, security risks and so on: Chain Interoperability, Vitalik Buterin, 2016.

[Erigara]

For now my main question is what use cases we want to support by connecting domestic chain and hub chain?

[Mingela]

From my notes:

Some domestic's chain data might be stored in Hub Chain (like wasm code, but not wsv), i.e. the Hub chain is the source of truth;
Private subnet (domestic 'chain') is not to maintain a blockstore, rather just the wsv;

So the data (proofs) published to the hub chain should be a somewhat lightweight transaction 'history'.

[s8sato]

• What identity the signatory of "omnibus account" will correspond to? Is it a chunk of domestic accounts?
  • Does it intend a clearing over domestic accounts to reduce transaction payload for the hub chain?
  • Does it intend to make individual domestic transactions untraceable in the hub chain?
• The approach 3. would be one for the most trustless situation. Depending on use case, a simpler architecture might be possible. Are there any components that may be trustful?

[Erigara]

Some domestic's chain data might be stored in Hub Chain (like wasm code, but not wsv), i.e. the Hub chain is the source of truth;

Afaik we discussed that private subnet could be just crash fault tolerant.
So what benefit gain this private subnet from storing commitment to it's data on chain?

[Mingela]

Afaik we discussed that private subnet could be just crash fault tolerant. So what benefit gain this private subnet from storing commitment to it's data on chain?

I could accept it being rather a political move to have this kind of binding/belonging, though there are still some consistent with the domestic chain operations possible on the 'omnibus' account in the hub chain. Maybe the hub chain could gain some verifiability in regards to such operation prerequisites.