This article includes an excerpt from that discussion, and represents my attempt at describing web3 — what it means, why it’s interesting, and what makes it such a fun paradigm to work in.

What Is Web3?

Web3 is a set of emerging tools and technologies for building decentralized, distributed applications. This includes tools for file storage, data storage, name resolution, identity, compute, and even code hosting — all the things you might think of that put together the building blocks of a web application.

Right now what we call web3 is mostly centered on public blockchains like Ethereum, Polygon, Cosmos, and Solana. Applications also leverage decentralized file storage solutions like IPFS and Arweave, and decentralized data storage tools like Ceramic and OrbitDB. There’s even an emerging app layer for web3, which would be something like ENS for name resolution, protocols like Ceramic for identity, and other types of more application-level protocols.

I would also add to this toolkit ZK tools, or zero-knowledge tools, which use cryptography in interesting ways that preserve user privacy.

Why Is It Interesting?

If you only know one thing about Ethereum, you probably think about it as a cryptocurrency. But broken down into its underlying technologies, it's a system composed of a few technologies that are common in different contexts, recombined to build a system that’s bigger than the sum of its parts. I will describe each of these components before showing how they fit together.

In addition to being a cryptocurrency and digital money, Ethereum is a peer to peer network. It consists of a few thousand individual interconnected nodes, all of which are Ethereum clients. They run all over the world, so they're geographically distributed.

Each of these nodes shares data with the others over a gossip protocol. So if you think of it this way, it’s kind of like BitTorrent. It's a cryptographic protocol, and the actors who are broadcasting messages on the network are identified by public private key pairs.

That means that when you send a message on the Ethereum network, you can use public key cryptography to authenticate who sent it and the content of the message itself. So in this way, it’s similar to SSH, PGP, or other public private key systems that we've used in the past.

Ethereum is also a distributed key value store. Every account and every node on the network can read and write data from this distributed key value store. Because each of those thousands of Ethereum nodes that are geographically distributed has its own copy of the data, we can say it is highly available. In this way, it's sort of like Cassandra, or another distributed KV database.

At the next level of abstraction, it's a state machine. When we make changes to that key value store, there's a set of consensus rules on the network that describe the state transitions that we can make from one state to another. There's a mechanism for deciding what state transitions are valid and coming to consensus on what the state of that data is at any time. So this is kind of similar to a consensus algorithm like Raft.

Ethereum also uses the data structure of a blockchain to synchronize and store those state changes. With each new block, the system transitions to a new state, and the full history of all the states and all those transitions is available and verifiable. In this way, it's kind of like Bitcoin, which was the technology that really pioneered this methodology of using a blockchain for this kind of system.

In another similarity with Bitcoin, Ethereum is a payment network. There’s not a great analogy for this one, because the concept goes deeper than a service like Visa or Paypal. Ether is a digital asset, and it’s the currency with which users pay for the storage and computation that you use on the network.

And once you add up all of these components, the network that users are paying to use is really a general purpose world computer. That idea is extremely interesting, fun to program, and unlike anything else.

What Makes It Fun?

The smart contract programming paradigm is unlike any other paradigm in which I've programmed in the past — and for me, that's really fun. In the same way that it’s interesting to learn Rust or Haskell, or move from an object-oriented paradigm to a functional paradigm, developing web3 applications has stretched me and challenged me to be a better programmer.

These properties also hold implications for buyers, the applications they want to build, and the limits of what’s possible. In 8th Light's Web3 Buyers' Discussion Guide, we briefly explore some of the fundamental properties and theory behind smart contract development that have helped me think about problems in new ways.

• Public. Smart contract code is deployed in public. It's replicated across each of these nodes on the Ethereum network. This helps assure that the code is doing what it’s expected to do, and it also means anyone can see the deployed bytecode of your contract — they can decompile it, they can inspect it, and interact with it. I’ve always really enjoyed looking through source code of an interesting website, popping open the dev tools in the browser to poke around and explore how it works, and now that property is kind of baked in.
• Permissionless. Anyone on the network can call the functions that you have exposed on your contracts at any time. They can read the underlying state data from storage. This property is sort of similar to a public API, where your application is always open to the world, but this paradigm stretches that property out to the extreme. Anyone can find your code, look at it, and interact with it in a permissionless way.
• Immutable. Once you've deployed a contract, you can't change it. This is a constraint that you have to think about, design around, and work around. Because if you're writing immutable contracts, that means your bugs will be deployed forever. You have to either get it right the first time, or you have to design around this property. It forces developers to create more modular systems, and find patterns that enable upgradability.
• Costly. The Ether asset is required to pay for storage and computation. So every state-changing interaction on the network and every computation that you perform on the network has an associated cost. Ether is measured in units called gas, and a gas-powered computer is a decent mental model for the way it works. It’s a clever defense against what’s called the halting problem, where you could write a program that could loop forever, and everyone would have to run my loop forever.
• Deterministic. This means that we can know, based on state at time zero, what the following state at time one is going to be. This is an interesting one because it means that a lot of the non-deterministic things that we do in general purpose programming are not possible from within the closed system of the EVM. For example, lots of applications will generate a random number, but you can’t generate a random number from inside the EVM because that randomness is just not possible in a deterministic closed system.
• Adversarial. This one combines all the previous properties in some ways, because the value you store in a smart contract is its own sort of bug bounty. Even the smallest vulnerabilities in the system will be found and exploited by adversaries. So it’s super critical to test your code, simulate unexpected things, and think very, very adversarially in this environment.

Conclusion

This is a fun paradigm for me, and I understand that these properties aren’t everybody’s cup of tea. I’ve found it challenging in ways that have made me a better programmer even outside of the EVM. Even if you don’t want to become a smart contract programming expert, spending a little time with Solidity in this interesting paradigm is a great way to stretch yourself and become a better programmer. Ultimately, this is why I believe that everyone should learn Ethereum.

Check out other articles about blockchain technologies and learn more about our web3 and blockchain services.