Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Private validators #4637

Open
mversic opened this issue May 22, 2024 · 8 comments
Open

Private validators #4637

mversic opened this issue May 22, 2024 · 8 comments
Assignees
Labels

Comments

@mversic
Copy link
Contributor

mversic commented May 22, 2024

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

@mversic mversic changed the title Permission validators Private validators May 22, 2024
@dmitrivenger
Copy link

@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
Copy link

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
Copy link
Contributor

Erigara commented May 23, 2024

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

@Erigara
Copy link
Contributor

Erigara commented May 24, 2024

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

@Mingela
Copy link
Contributor

Mingela commented May 24, 2024

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
Copy link
Contributor

s8sato commented May 24, 2024

  • 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
Copy link
Contributor

Erigara commented May 24, 2024

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
Copy link
Contributor

Mingela commented May 24, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants