Disclaimer: Nothing in this article is financial advice. When referring to modern blockchains or “Ethereum,” I am referring to Ethereum following “the merge,” where it will operate a proof-of-stake consensus mechanism.

Let’s get real here. Crypto is not intuitive. And people interested in the space want and NEED a straightforward explanation of how the technology works. No buzzwords, no acronyms, just a simple ELI5 … well maybe ELI15.

This article is intended for that group — the people just entering the space looking for an introduction into how modern blockchains function. You’ve likely heard “why” blockchain tech is important, but you want the “how.” I can’t promise it will be a short read, but I’m going to do my best to break this down into simple mental models to equip you with enough to be dangerous.

What is a public blockchain?

A public blockchain, like the one underpinning Ethereum, is a database that tracks and updates info stored in individual accounts.

But unlike traditional databases, entries cannot be changed/reversed, and instead of being owned by one, centralized, entity, blockchains are maintained by a decentralized group of individuals. This is a significant difference, and really, it’s the key difference to explore. Because being decentralized means there’s no single point of failure. There’s no central entity that can unilaterally change the data or add/remove authorized users. And actually, Ethereum is what we call “permisionless,” meaning anyone can read from it or write to it. But this article isn’t about the implications, it’s about the “how.”

The best way to understand blockchain tech, imo, is by starting at the beginning. It’s a database — we get that — but how is it different than you average, centralized, database?

Blockchains vs. Centralized Databases

Imagine we own a bank that manages a bunch of safety deposit boxes. The average bank has many responsibilities, but we’re different. The ONLY thing we do is manage these boxes. If someone wants to add/remove to their box, or even transfer to another box, we can do that.

One of the first things we need to do is set up a database to store information on these boxes (i.e, who owns what, where). I realize banks don’t actually track the contents, digitally — but stay with me here.

At this point, we have a single, centralized, database where we have complete control over the underlying data. And that’s great — but one database doesn’t always cut it. Let’s say our small operation gets traction and we open up new locations across the region. We now have a lot sensitive data on hand and we need backups in case the original server fails. So, we buy a couple more hard drives. Now we have backups, and — as a bonus — we can spread queries across these new databases to avoid congestion on the master server. As a double bonus, we can co-locate these new servers next to our customers to serve data to them even faster.

But more databases bring more problems. The only database that can make changes to the underlying data is the original, master, database. All other servers are what we call “slaves.” This doesn’t work very well because if the master goes down, well, we can’t make updates.

Let’s say someone managing our Berlin server (we’ve gone international) needs to update the contents of a deposit box. Right now, he/she would have to reach out to whoever manages the master server, and if the master server goes down — you guessed it, we have a problem. To fix this, we give all of our databases (also known as “nodes” ) the ability to both read and write. Now, any database can make changes directly to the master data set.

Problem solved? Well, not exactly. This introduces a new complexity. With multiple nodes submitting changes, we need a way for these nodes to agree on things — to ensure that one change doesn’t conflict with another. The nodes need to reach consensus on every change.

This may sound abstract, but think of it like this: if our business continues to grow, and we have hundreds/thousands of servers all of the world, we need a way for all these servers to stay in sync. Each time a change needs to be made to the underlying data, all nodes need to first agree on the change, and then update their copy of the data set. Imagine Joe has $50 in his box, calls up the Ohio branch and asks to transfer that money to Lisa. Moments after that, he calls the Osaka branch and asks to send that same $50 to Amanda. If the databases didn’t communicate with each other and sync their data after every transaction, it might be possible for Joe to fool the system and spend that $50 in two different places.

This model, where a network of nodes talk (or gossip) with each other, is the foundation of modern blockchains. This is what is happening under the hood when you submit a transaction on the Ethereum network. But there’s more to it, and our database has not yet reached the “decentralized” status of Ethereum.

Time for a change. As the owner of this bank, we make a radical decision. We decide to relinquish our “master” status over the data. No longer can we make unilateral edits that get immediately implemented. Rather, we are just another node that needs to submit updates to our fellow nodes, who will subsequently vote on whether the change should be approved/rejected.

In this scenario, every node has the same power, and collectively, they manage the underlying data by fielding requests and proposing changes. And this is conceptually how a modern blockchain is organized.

Connecting it all together

Circling back to our thriving safety deposit box chain — we now have:

• A bunch of customers
• A bunch of nodes who field customer orders and who then update our--
• Database, which tracks--
• All the assets stored in our safety deposit boxes

And this isn’t too different than Ethereum. If we replace our safety deposit boxes with digital accounts, we now have something pretty similar.

Now that we get the gist, it’s time to dig deeper. To truly understand how modern blockchains function, it helps to follow the lifecycle of a transaction. If I submit a transaction, what happens to it? How does it get into a “block?”

This lifecycle can be broken down into the following six phases:

• Phase 1 | Initiation: What are wallets and accounts (and WTF is a smart contract)?
• Phase 2 | Transmission: How are changes (i.e., transactions) sent and received?
• Phase 3 | Collection: How are transactions collected, organized, and validated?
• Phase 4 | Execution: How are transactions proposed to our fellow nodes?
• Phase 5 | Consensus: How do nodes agree on the the changes (i.e, future state)?
• Phase 6 | Settlement: How do we implement / finalize the future state?

If you’ve gotten his far, and you’re interested in reading the breakdown of the six phases please feel free to drop a comment. I would welcome any suggestions as I continue to deploy the series. Until next week!