zdave-parity
commented
2 hours ago CE129 is primarily intended for warp sync. Warp sync of course isn't really possible without finality proofs; a protocol to retrieve these will be added when the GRANDPA stuff is added. In the meantime to implement warp sync you just have to trust the finalized blocks reported by other nodes.
CE129 is not intended for debug purposes. I don't intend to add any such protocols to JAM-SNP. Of course state introspection protocols may be useful for debugging, but these should be implemented separately, perhaps using something like JSON RPC. Whether it makes sense to have a standard RPC protocol for debugging I don't know.
We believe CE129 is entirely for debugging and should be adapted for JAM implementers to be as debugging friendly as possible especially well in advance of M5 production objective. As it stands now, (1) the 31-byte key (2) the lack of service id support making CE 129 not very friendly.
We understand that we can ignore the last byte of the key to compute the state root and use 31 bytes to encode the leaf (see this). But because all the other functions and mappings relate to the full 32-byte key, it would be strictly more powerful to have CE129 response contain the 32-byte key since other mappings require the full key -> (k,v):
Even more important is to have a human-friendly JSON format + CE129 response for key-value since the keys for service storage do not uniquely reveal what serviceID they relate to. The start of this is here in davxy but a dev-friendly response should be organized around the service id rather than a key range. Potentially CE129 could have a serviceID in the request for filtering. It does NOT have to be scalable to hundred of millions of keys until teams are on the toaster. Any claim is "premature" scaling, we believe -- we just need to debug services right now.