Really good piece by Moxie on web3.
- Web3 lacks
- By definition, infrastructure does not need to be rebuilt every time they are used. To ask people to throw away their infrastructure is rather stupid.
- Servers are infrastructure! Nodes are infrastructure! People won’t want to run these themselves. Until we reach a point where enough web3 platforms are able to provide this same level of infrastructure, we’re going to still end up with centralization.
- “If there’s one thing I hope we’ve learned about the world, it’s that people do not want to run their own servers. The companies that emerged offering to do that for you instead were successful, and the companies that iterated on new functionality based on what is possible with those networks were even more successful.”
Decentralization is not always good. The more I get involved with the space, the more I am certain that the main value add of
web3 is not decentralization but rather
- Decentralization also ends up making progress very difficult. See: Vanilla Ice Cream effect
- “This isn’t a funding issue. If something is truly decentralized, it becomes very difficult to change, and often remains stuck in time.”
trust. Crypto folks don’t necessarily trust the people but some just blindly trust the medium. If people don’t understand how the medium works to facilitate transactions, how can they trust it? Transparency also involves transparency into its inner workings.
- Similarly, “Almost all dApps use either Infura or Alchemy in order to interact with the blockchain.”
- We just rely on these two pieces of critical (centralized!) pieces of infrastructure to produce the correct results and not be bad actors.
- Degraded Blockchain problem
Levels of connecting to the blockcahin
- Use a Binance account.
- Run a piece of code that asks the Infura API endpoint what the blockchain state is, trust the answer. However, keys are still kept locally; the code signs transactions locally and sends them to the Infura API endpoint to be re-broadcasted.
- Same as (2), but the code also runs a light client to verify the signatures on the block headers and uses Merkle proofs to verify individual account and storage data.
- Same as (3), but the code talks to N different API endpoints run by N different companies, so only 1 of them need to be providing honest answers for the connection to be reliable.
- Same as (4), but instead of pre-specifying N API endpoints the code connects directly to a p2p network
- Same as (5), but the code also does data availability sampling and accepts fraud proofs, so it can detect and refuse to accept blocks that are invalid.
- Run a fully verifying node.
- Run a fully verifying node that also participates in mining/staking.