Feature to consturct and verify post-stateRoot for stateless clients

[g11tech]

Basically for a stateless clients there are 3 verifications which are crucial:

1. Pre State is valid with regard to previously accepted valid stateRoot of the parent
   a. In context with VKT implementations this involves verifying the currentValues and the proof nodes can be used to construct a valid partial VKT with the root as the parent's stateRoot
2. Validate block's STF (state transition function) i.e. run EVM on prestate and verify you get exactly the post state thats in the execution witness, nothing less nothing more (and gas/receipts/logs match)
3. Validate that the pre State partial VKT can be updated with the post state to form the post state partial VKT with the root matching the block's stateRoot, which is when you can accept the blockState root as valid and corresponding to the block.

Now currently this library provides 1. and this feature request is also to provide 3 via possibly the single interface because both pre and post state for the block is available right at the start in the execution witness and can be used to validate that they represent valid pre/post block execution VKTs

Afterwards (or in parallel) a stateless client like ethereumjs can execute the block with its evm using the pre-state in execution witness and validate it gets the exact post state i.e. point 2.

With 1 & 3 verified by the VKT crypto lib and 2. verified by the client EVM, the stateless clients will get a good interface to work with without even dealing with the VKT layer which can act as a blackbox for them. This will surely make the dev cleaner, easier and more maintainable.

cc @holgerd77 @gabrocheleau @kevaundray @gballet @jsign

[holgerd77]

Thanks, this is a great write-up and helps me to sort out the different verification parts! 🤩

I am not into the library's API possibilities enough to give an answer what can/could possibly exposed, that's likely rather to be answered by Kev.

Just to note in case it might be helpful: the old_api.rs file (currently deactivated by renaming to old_api.rs.backup) is still working/compiling, just tested by renaming back and run the ./scripts/rust-buildsh shell script.

This file is exposing the following two methods:

pub fn pedersen_hash(address_tree_index: Uint8Array) -> JsValue
pub fn verify_update(js_root: Uint8Array, js_proof: Uint8Array, js_key_values: &Map) -> JsValue

So we could reactivate that, even if it might be only a temporary solution for something.

Side note: also to mention that this file also contains relatively extensive tests which likely took a lot of work to write. I am not 100% sure yet in what context these tests are run, but we should likely still leverage those if still possible the minimum, would be a pity if these just get forgotten.

[holgerd77]

(I tested going into src/rust-wasm and running cargo test and cargo test src/old_api.rs, but both ran with 0 tests executed. Maybe @kevaundray can side-shed some light on this how this would be executed (just out of interest and for eventual future use cases, independently from the question if this part of the API is reactivated or not))