Question about the Collator

[XiangyueMeng]

I have a question about the mechanism of the Collator. Does the Collator report all the transactions of the parachain to the main chain? Or the Collator need to filter those informations itself and report only part of the info?

[burdges]

We require the collator provide a proof that the parachain state evolved correctly. We expect this proof may be large, so we handle it without it going onto the relay chain.

A mimblewimble collator would apply cut-through, reducing the size slightly. We'll eventually do some zero-knowledge parachains that use the ZEXE Cocks-Pinch curve to provide a small zero-knowledge proof of checking all those zero-knowledge proofs, but this still requires tracking the nullifer database, so maybe not so tiny sadly.

[XiangyueMeng]

We require the collator provide a proof that the parachain state evolved correctly. We expect this proof may be large, so we handle it without it going onto the relay chain.

A mimblewimble collator would apply cut-through, reducing the size slightly. We'll eventually do some zero-knowledge parachains that use the ZEXE Cocks-Pinch curve to provide a small zero-knowledge proof of checking all those zero-knowledge proofs, but this still requires tracking the nullifer database, so maybe not so tiny sadly.

I am still confused. To be more specific, If Alice and Bob want to have a trade that Alice send Bob 1 BTC and Bob give Alice 20 ETH. In that case how this transaction works?

[Satoshi-Kusumoto]

@burdges I am also confused. For a chain that can offer a succinct proof of the state transaction, this is cool. But as I know, most current blockchains (e.g. Bitcoin), do not have such a proof system. So how to deal with a Bitcoin (or Ethereum) like parachain? In many places it is said that, once you can provide a light client, then it's fine. But a light client of Bitcoin can only prove that your tx is included in a block, but not that the state transaction is valid (e.g. it can not detect double spending)

[burdges]

Accounts based chains provide Merkle proofs for all transactions, so the proof is actually the block size times the log of the chain size. There is example UTX0 parachain code somewhere, or being developed, but not sure about how it works. We do not afaik have an implementation of any techniques for compact UTX0 nullifier proofs yet, like sparse Merkle trees.

I suspect the harder question is adapting zk tricks for compression of sparse Merkle trees or whatever. It's too slow for block producers to build these proofs, so clients must do so. Any UTX0 chain should be zero-knowlege though, well why else would you do UTX0s, so users should expect slow transactions.

[Satoshi-Kusumoto]

Accounts based chains provide Merkle proofs for all transactions, so the proof is actually the block size times the log of the chain size. There is example UTX0 parachain code somewhere, or being developed, but not sure about how it works. We do not afaik have an implementation of any techniques for compact UTX0 nullifier proofs yet, like sparse Merkle trees.

I suspect the harder question is adapting zk tricks for compression of sparse Merkle trees or whatever. It's too slow for block producers to build these proofs, so clients must do so. Any UTX0 chain should be zero-knowlege though, well why else would you do UTX0s, so users should expect slow transactions.

OK. Then the question becomes that, will Cumulus (or Substrate, or any other Web3 projects) are going to provide a tool for generating such a proof, or parachain developers have to design and implement their own proof generation logic for their collator node?

[burdges]

We'll implement a zero-knowledge parachain that does this eventually, but not this year. I think https://github.com/scipr-lab/zexe has the required curve crusted by Cocks-Pinch.

Anything SNARK based is highly bespoke to the specific logic, but the ZEXE paper gives some directions for safer building blocks. One day.. :)

[rphmeier]

@burdges The zero-knowledge and mimblewimble parachain stuff is super cool and on the roadmap but a little beyond the scope of what's being asked, I think :)

@Satoshi-Kusumoto

will Cumulus (or Substrate, or any other Web3 projects) are going to provide a tool for generating such a proof, or parachain developers have to design and implement their own proof generation logic for their collator node

Indeed, and this is the main point of Cumulus -- to transform Substrate codebases into parachain-ready collator nodes without friction. There is a PR open now for exactly the feature you've described: https://github.com/paritytech/cumulus/pull/11

@XiangyueMeng

Essentially, any blockchain that can prove to a light client that a block has been executed correctly can be turned into a parachain. Typically, this is possible because every block header commits to the root of a merkle trie that holds all the state necessary to verify the transactions of the next block.

Parachain Validation WASM functions are basically on-chain Stateless Clients. The collator node simply provides the all the nodes of the parent block's state trie necessary to verify the the state transition of the collated block.

What @burdges is referring to is the idea that rather than actually sending those trie nodes to the validation function for them to be checked, the collator instead produces a succinct proof that there exists such a set of trie nodes and transactions such that the collated header represents a valid state transition. But we'll need the state-of-the-art for ZK proving systems to advance a bit before that can be used for meaningful computations...