Comments (8)
MMR will most likely contain a tuple of 3 elements:
Option<MerkleRootOfBeefyPublicKeys>
- all BEEFY public keys for upcoming epoch, merkelized. Only present for set transition blocks.MerkleRootOfParachainHeads
- a merkle root hash of either a latest header for every registered parachain or for every parachain that made some progress in current relay chain block (depends on how expensive rebuilding the entire tree is going to be)ParentBlockHash
- a parent hash of the current relay chain block
So if you want to prove to a BEEFY light client that something happened on a parachain you'll need:
ParachainSpecificProof
- either a storage proof, a transaction inclusion proof, or a bridge-specific datastructure proof.ParachainHeader
- a full version of parachain headerParachainInclusionProof
- a proof that the parachain head is part ofMerkleRootOfParachainHeads
for some relay chain blockX
MMRProof
- MMR proof for blockX
, containing the full leaf (specificallyMerkleRootOfParachainHeads
is important to be proven).
We can obviously require a bunch of more bridge-specific changes from parachains - for instance the MMR could only contain some output of bridge-specific data structure living on the Parachain, so that the full head data is not necessary in the proof, but it has quite significant consequences in generality.
But don't we require these validator set changes in the digest for light clients?
That's only partially true, we need some information that will allow Light Clients to verify the new validator set. Returning the entire set is the simplest and most straightforward way, but it would be totally fine if the digest only contained a merkle root of the keys and the full tree would be provided externally.
AFAIU most of the external apps requiring stuff from parachain will rather depend on GRANDPA finality proofs of the relay chain instead of tracking block production on a parachain itself, so for parachain heads these details are most likely redundant.
from grandpa-bridge-gadget.
Why will it be expensive to proof for parachains?
from grandpa-bridge-gadget.
Assuming 1024 validators * 32 bytes = 32KB of just validator set data directly inside the header. To verify anything about a parachain (i.e. storage proof, transaction inclusion proof, etc) you will need to provide the full header content to prove it's actually the one.
We could do some pre-processing on the relay chain side to remove this data before inserting to Merkle Tree (which root ends up in the MMR), but this would change the header hash for instance.
from grandpa-bridge-gadget.
But don't we require these validator set changes in the digest for light clients?
And I don't understand, what ends in the MMR? The hash of the parachain header or the hash of the relay chain header?
from grandpa-bridge-gadget.
it would be totally fine if the digest only contained a merkle root of the keys and the full tree would be provided externally.
Right so this would mean that authorities would have to be signaled a diff way, inherents perhaps?
from grandpa-bridge-gadget.
A signal is already there - that's the digest item (containing a root hash). But then when you have the signal you'd need to figure out the validator set from some other place (for instance by querying the state). Inherent could be used for that, but it feels complicated (i.e. the block author would need to add the inherent in case they predict that the rutnime would generate the runtime item in that block. Every block with the digest item and without inherent would need to be considered invalid).
from grandpa-bridge-gadget.
A signal is already there - that's the digest item (containing a root hash)
Yeah i get that, but we need some other way to produce the full list of authorities.
for instance by querying the state
yeah this makes sense, so i guess only changes needed is to change BABE/AURA/Grandpa from depositing full authority set in digests to just depositing merkle roots of this data. There's already storage items that track the next validators, we'd also have to modify the babe/aura/grandpa worker if they rely on that information in the headers.
How would the network handle changes to the header like this? Just out of curiosity
from grandpa-bridge-gadget.
The main challenge with this issue is to make sure that Polkadot and Cumulus are able to handle that, cause AFAIU currently we rely on the full validator set to be in the header digest item.
from grandpa-bridge-gadget.
Related Issues (20)
- Provide well-formed `ValidatorSet` HOT 1
- MMR leaves in off-chain storage can be overwritten by forks HOT 7
- Integrate BEEFY with Rialto & Millau runtimes HOT 1
- Deploy BEEFY to Rococo HOT 2
- Update `on_initialize` weight calculations HOT 1
- Alternative MMR library implementation
- Merkle Mountain Belt implementation HOT 1
- Box<> large call arguments to avoid increasing runtime `Call` size HOT 1
- Do proper round life-cycle handling HOT 3
- Stalled BEEFY report HOT 1
- Re-enable `clippy` checks
- Use ABI Encoding for BEEFY? HOT 4
- Optimize gossip
- Persist public key used to vote - avoid double voting HOT 1
- Add customizable providers for validator-set and payload (for tests) HOT 1
- BEEFY voter should have "non-authority light mode" HOT 3
- Allow pluggable BEEFY payload constructors HOT 2
- Ensure mandatory BEEFY block for each session HOT 2
- Validate votes using the right authority set HOT 1
- Buffer votes for not yet finalized blocks HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from grandpa-bridge-gadget.