Re: Moxie on Web3
On decentralization, servers and cryptography
Respected cryptographer Moxie Marlinspike has written up some thoughts on Ethereum and the modern ‘crypto’ ecosystem. Although I was involved in Bitcoin right at the beginning, I’ve never been involved in Ethereum or Web3, don’t currently own any cryptocurrencies and I broadly agree with a lot of what he says. Nonetheless I disagree on a few critical points. In this essay I’ll summarize parts of Moxie’s argument, lay out a couple of disagreements and then provide some suggestions for a path forward.
Ethereum isn’t actually decentralized
I’ll start with a small technical disagreement before moving onto thoughts about servers and cryptography.
At the core of Moxie’s argument is the observation that Ethereum claims to be a decentralized ecosystem but isn’t. This is broadly true. He also observes that there are many excuses for this situation in circulation like “it’s early days” which, as someone who used Bitcoin in 2009, seems quite wrong. 12 years is sufficient to have solved these problems.
Unfortunately Moxie conflates Ethereum with all blockchain systems:
When people talk about blockchains, they talk about distributed trust, leaderless consensus, and all the mechanics of how that works, but often gloss over the reality that clients ultimately can’t participate in those mechanics. All the network diagrams are of servers, the trust model is between servers, everything is about servers. Blockchains are designed to be a network of peers, but not designed such that it’s really possible for your mobile device or your browser to be one of those peers.
With the shift to mobile, we now live firmly in a world of clients and servers — with the former completely unable to act as the latter — and those questions seem more important to me than ever. Meanwhile, ethereum actually refers to servers as “clients,” so there’s not even a word for an actual untrusted client/server interface that will have to exist somewhere, and no acknowledgement that if successful there will ultimately be billions (!) more clients than servers
I feel a need to respond to this because it’s only actually true for Ethereum. I should know because my first project when I joined the Bitcoin world was to work with Andreas Schildbach on a genuinely peer-to-peer mobile wallet app, which became Bitcoin Wallet for Android. It had/has a competitive UX and was able to grow a large userbase, despite being built in the most decentralized way possible.
We could do this because Satoshi thought very carefully about the untrusted client/server interface. From day one the Bitcoin protocol had a notion of a sort of lightweight client mode. Satoshi didn’t give this mode a clear name but the section of the paper that discussed it was titled “Simplified payment verification”, so I started calling apps that used it SPV wallets and the name stuck. Exactly how SPV mode works is fully explained elsewhere, but briefly, the client app bootstraps connections to the P2P network as normal but sends a special message saying “please don’t send me the contents of every block or transaction, I only want to see transactions matching a filter”. It then downloads the headers of every block from the peers, but not their contents, and does the necessary computations to select the block header chain with the highest total work. Transactions that match the filter come supplied with a Merkle branch linking them to the Merkle tree roots embedded into the headers. In this way a client can traverse a chain of blocks with fairly minimal bandwidth, storage and CPU requirements, whilst keeping the P2P network as an untrusted adversary. The filter in our implementation was a Bloom filter, so you could probabilistically hide what you were interested in (although in practice, real users cared much more about performance than this type of privacy).
Moxie observes that:
One of the surprising things to me about web3, despite being built on “crypto,” is how little cryptography seems to be involved!
I think the protocol just outlined does use cryptography in some interesting ways, or rather, ways that were interestingly new in 2011 when we built out the infrastructure.
This system was very complicated to implement but worked surprisingly well. We implemented lots of performance tricks like background wakeups to keep roughly synced, bandwidth adaptation, measuring peer latencies, syncing at night when plugged in to charge and so on. Whilst SPV wallets were never quite as fast as competitors that simply polled a centralized database, they were fast enough for many users.
from Hacker News https://ift.tt/3JSiz4p
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.