Mustafa Al-Bassam

>I'm thinking it might be possible if an attacker modifies the NMT code to simply process out-of-order leaves, and the Merkle proof is for a leaf whose neighbor isn't out...

>This mechanism isn't entirely predictable because it depends on state reads / writes. For example see [this image](https://celestiaorg.github.io/celestia-app/specs/resource_pricing.html#pfb-with-one-single-share-blob) which has pie chart segments for ReadPerByte, WritePerByte, etc. These are deterministic...

>I think this is because if the IVAL tree changes the amount of writes and reads changes. I see if this is the case, then yes it does make sense...

The table is pulled from http://mcc-mnc.com/, which only has 1.6k entries for some reason. On 15/09/2020 22:07, Wanderer wrote: > > First of all, I would like to thank you...

We could also do ZK fraud proofs of entire blocks at a time, which wouldn't require intermediate state roots, if feasible. On Wed, 21 Feb 2024, 10:56 Evan Forbes, ***@***.***>...

> Thinking out loud: given option 1, if a malicious validator includes an incorrect entry in the `SignerNamespace`, what does a fraud proof for this behavior look like? I infer...

Option 2 would involve making a new namespace version so wouldn't necessarily be breaking. As part of this, we may want to create a new and improved namespace version with...

They might put a fake signer.

This is for use cases that need some proof that the metadata is correct - eg it signed by the validator set. An API could lie about the correct metadata.

It would require extra ZK circuitry to parse the PFBs and verify those proofs for ZK rollups, which is one of the reasons why Sovereign Labs for example is advocating...