Moxie makes a really good point about authenticity of RPC responses Moxie Marlinspike >> Blog >> My first impressions of web3 and I encourage everyone who builds blockchains, tooling and apps to read it. I wonder if there is anything on your mind / roadmap where Tezos could do better?
The point is that we have sophisticated cryptography and consensus mechanisms at the P2P layer between nodes, but unauthenticated/unverified communication over RPCs and indexer APIs. Dapps, wallets and users have to blindly trust their public RPC providers. Whoever wants to censor or alter data can do so undetected.
I guess for full blocks and operations we can at least validate their hashes based on content after download (I haven’t tried yet, but will), but who tells us the block/op hash actually exists and wasn’t doctored? The node RPC doesn’t even let you query an operation by its hash. And what about responses from RPC context calls? AFAIK there’s nothing like a storage root hash per account and even if there was we would probably need some sort of a light client to follow/verify an account’s history. One simplistic solution would be to send each query to multiple providers and compare results. Moxie talks about this and I know Ethers.js does it this way. But is that enough?
Even worse in my mind are indexer APIs, especially because the underlying SQL databases can be easily altered. Don’t get me wrong, I’m building TzIndex myself for years and from day one I’ve been asking myself how to proof data correctness to clients in every API response. So far I haven’t found substantiated discussions about the topic. Maybe we can start one today.
AFAIK there’s nothing like a storage root hash per account and even if there was we would probably need some sort of a light client to follow/verify an account’s history. One simplistic solution would be to send each query to multiple providers and compare results.
In my opinion, comparing the result returned by several nodes run by independent parties increases confidence in the legitimacy of the answer a lot. If you still worry you can of course always run your own node or indexer (and contrary to Moxie’s claim that “People don’t want to run their own servers, and never will”, Baking Bad’s blog post on the network decentralization shows that many users actually do run their own nodes).
Great, thanks! I didn’t know about the light mode. My question is what would it take in terms of storage/messaging requirements to put similar functionality into a client-side SDK? In my mind, ideally, the light client sits inside a wallet, desktop/mobile app or webapp.
Tezos’ light mode security reduces to whether the client can obtain the correct context hash (or a correct block hash). If the client is sure about the hash, all the node data being queried can be authenticated.
In proof of work networks, there is a way of authenticating headers with some degree of confidence: if they match the difficulty there’s a good chance they’re part of the chain, otherwise this would be a very costly attack.
In proof of state networks, it’s more complicated. You can try and get something similar, by downloading a history of signed blocks. Celo notably compresses that history and creates such a light client proof using recursive zk proofs, but you still have to contend with weak subjectivity.
So do light clients make sense if users are still required to know the context hash? It’s certainly more convenient for a client to query several nodes to obtain a context hash, and then query a single fast RPC that will prove that the data retrieved is consistent with that hash, than to query multiple nodes for the data, but I’m not sure there is demand for this specific security model.
