Mustafa Al-Bassam
Mustafa Al-Bassam
Not sure then. I would suggest printing the response object received from eth_rpc_client and seeing what the non-JSON response is, this seems to be an issue specific to eth_rpc_client rather...
This may be because ethereum-rpc-client - the library Trustery uses to communicate with the local Ethereum node - is deprecated (https://github.com/pipermerriam/ethereum-rpc-client).
I assume that `Nodes` are the subtree roots?
In the case of a non-membership proof, the proven leaf value is nil. However, we also need a field for what the value of the leaf is that is found...
I'm not sure the number of samples has to be a part of the spec because clients can decide this for themselves, however the spec can make secure recommendations.
I consider the LL token app to logically be an optimistic rollup sidechain. Therefore validators can just download the latest state root for it and accept state transition fraud proofs.
(for example learn modular menu links don't have trailing hash. this is not the highest priority issue though)
This issue has appeared again in the latest version of the site
One thing that's worth noting is that most rollups today capture their own MEV (via their sequencers) rather than leak it to the base layer, as a way to accrue...