Adds first version of validate_block
#3
Conversation
| type HashOf<B> = <B as BlockT>::Hash; | ||
|
|
||
| /// Abstract the storage into a trait without `Block` generic. | ||
| trait StorageT { |
There was a problem hiding this comment.
a bit weird to call it StorageT. why not just Storage?
There was a problem hiding this comment.
Because I have a struct that is called Storage in the same module 😅
| self.overlay.get(key).cloned().or_else(|| { | ||
| read_trie_value( | ||
| &self.witness_data, | ||
| &self.storage_root, key |
There was a problem hiding this comment.
key should go on new line.
| } | ||
| } | ||
|
|
||
| unsafe fn ext_set_storage( |
There was a problem hiding this comment.
i would prefer to extract these to a submodule where we can be a bit more sure about invariants
There was a problem hiding this comment.
Hmm, this is already its own module and you are sure about the invariants. This function is only usable by validate_block. I would not put this into another file.
|
|
||
| use hash_db::HashDB; | ||
|
|
||
| static mut STORAGE: Option<Box<StorageT>> = None; |
There was a problem hiding this comment.
eep. still not a fan of the static mut. Why not at least a RefCell?
There was a problem hiding this comment.
TBH I see no reason why, with native-runtime optimization, this is guaranteed not to be used from multiple threads
There was a problem hiding this comment.
This will never be callable by the native side. First we don't support replacing the functions on native, second register_validate_block! resolves to nothing on native.
| struct Storage<B: BlockT> { | ||
| witness_data: MemoryDB<<HashingOf<B> as HashT>::Hasher>, | ||
| overlay: hashbrown::HashMap<Vec<u8>, Option<Vec<u8>>>, | ||
| storage_root: HashOf<B>, |
| storage_root: HashOf<B> | ||
| ) -> Result<Self, &'static str> { | ||
| let mut db = MemoryDB::default(); | ||
| data.into_iter().for_each(|i| { db.insert(&[], &i); }); |
There was a problem hiding this comment.
what does the &[] mean here?
There was a problem hiding this comment.
I don't really know. I copied this code from substrate. I think that &[] is the prefix. Maybe @cheme can help us here?
There was a problem hiding this comment.
That is the prefix for the MemoryDB, I believe here if MemoryDB is used from substrate trie crate, there is no key transformation with the prefix so it is safe to put nothing (a variant called PrefixedMemoryDB does insert the prefix before the key when inserting/querying the keyvaluedb to avoid collision in trie with unhashed value).
There was a problem hiding this comment.
hm, maybe we need this when using a chain with child tries
There was a problem hiding this comment.
there is the key conflict with child trie, but this way of doing things cannot solve it directly (for two identical child trie there is the sametrie related prefix). I was also wondering about exposing this key transformation trait to insert a child trie specific prefix with a specialized implementation (paritytech/trie#12 last comment), but using a hashdb specific implementation would achieve the same thing.
There was a problem hiding this comment.
I assume that we then need to adapt this? This is basically the functionality I use to generate the proof. I assume we would need to extend the proof with the prefix somehow?
There was a problem hiding this comment.
If you use child trie I think you need paritytech/substrate#2209 (I should split it in two has I believe the api change would not be merged or at least requires some consensus but the proof side of the pr seems ok).
But otherwhise the prefix thing should only apply to avoid reference count in db, so the Recorder of trie does not use the prefix so it should not matter (that is the good thing about the way Arkadiy solves the issue).
| Some(mut value) => { | ||
| *written_out = value.len() as u32; | ||
| let ptr = value.as_mut_ptr(); | ||
| mem::forget(ptr); |
There was a problem hiding this comment.
what's the purpose of forgetting ptr (which is copy) and then using it right after?
There was a problem hiding this comment.
Was incorrect and is fixed now.
| "substrate-trie/std", | ||
| ] | ||
| wasm = [ | ||
| "hashbrown/nightly", |
There was a problem hiding this comment.
is this wasm feature something native or something that require some feature declaration?
(I remember that I wanted to use hashbrown but use hasmap_core in trie because it felt easier to manage with 'std' substrate feature, just thinking let's wait for hashbrown to be std and see if at some point it makes it to alloc).
There was a problem hiding this comment.
This requires a feature declaration.
…ion-fix Feature/new session fix
Depends on: paritytech/substrate#1926