Learning Web3 from the Ground Up: Encryption & Practical Byzantine Fault Tolerance

I'm still in the early stages of learning about Web3 (see my last two blog posts here and here!), and the deeper I go, the more I realize that the real magic of blockchain isn't just in the code—it's in the cryptography that secures data and the consensus algorithms that coordinate it. As I continue learning, two concepts stood out this week: public key encryption and Practical Byzantine Fault Tolerance (PBFT).

These may sound intimidating, but they’re the backbone of how blockchains protect data and reach agreement without a central authority. I explored them through Cardano Academy's Intro to Blockchain series, which continues to be a great entry point for breaking down these core concepts.

Here's what I learned—and how these two building blocks shape the infrastructure behind modern blockchain networks.

Public Key Encryption – Sending Secrets Without Sharing Keys

Encryption is the backbone of blockchain security. It allows us to send private messages, verify identities, and keep data safe—even across open, decentralized networks like the internet or blockchain itself. This is especially important in Web3, where blockchains are public by default—anyone can view the data, participate in the network, or run a node. At Midnight, encryption plays a key role in protecting sensitive data while still allowing it to live on a public chain. From shielded transactions to selective disclosure, Midnight builds on the principles of public key cryptography to enable privacy without sacrificing decentralization.

At a high level, encryption is just the process of turning readable data (called cleartext) into gibberish (ciphertext) so that only the right person can turn it back. But how do we do that without first sharing a secret key?

The Two Types of Encryption

There are two main types of encryption:

• Symmetric encryption: The same key is used to encrypt and decrypt the message. It's fast, but you need to share that key first, which can be tricky to do securely.
• Asymmetric encryption (also known as public key encryption): Uses a key pair—one public and one private. What one key encrypts, the other can decrypt. If you encrypt something with a public key, only the matching private key can unlock it and vice versa. They’re mathematically linked, but guessing one from the other is nearly impossible.

The key difference? In symmetric encryption, both people share one secret key. In asymmetric encryption, no shared secret is needed, just a matching key pair.

A Simple Analogy

Think of symmetric encryption like a shared locker: you and your friend have the same key. Anyone with that key can open the locker. The hard part? Making sure only the two of you have a copy. On the other hand, asymmetric encryption is more like giving everyone a padlock with your name on it (your public key). Anyone can lock a box and send it to you, but only you, holding the matching private key, can open it.

How It's Used in Blockchain

When Alice wants to send Bob a secure message:

1. Bob shares his public key.
2. Alice encrypts her message using Bob's public key.
3. Bob receives and decrypts the encrypted message using his private key.

Even if someone intercepts the message, it’s unreadable without Bob’s private key. Thanks to the math behind elliptic curves and RSA, it would take more time than the universe has existed to reverse-engineer a private key from a public one with today’s computers.

Why Not Just Use Public Key Encryption for Everything?

Public key encryption is powerful but computationally heavy. That's why, in practice, most secure systems (like HTTPS) use a hybrid model:

1. The client and server use public key encryption to securely exchange a temporary session key.
2. From then on, they use symmetric encryption with that shared key to communicate quickly and securely.

This is the same approach blockchains often use for performance and scalability—combining the strengths of both methods.

---

Practical Byzantine Fault Tolerance – How Blockchains Reach Consensus

Now that we've covered encryption, let's move to something that puzzled me at first: How do blockchains reach consensus without a central decision-maker? That's where consensus algorithms come in. This week, I learned about one of the earliest and most influential: Practical Byzantine Fault Tolerance, or PBFT.

First, a Quick Refresher on Consensus

Consensus is how distributed systems agree on a single truth, even if some participants are slow, offline, or actively trying to cause problems. It's what lets a decentralized ledger agree on who owns what, and it's essential for any blockchain to function.

The "Byzantine" part comes from a famous thought experiment called the Byzantine Generals Problem, in which generals need to coordinate an attack but can't trust their messengers. In blockchain terms, nodes must agree on a block, even if some are lying or malfunctioning.

What Makes PBFT "Practical"?

PBFT is designed to work in weakly synchronous systems—systems where messages might be delayed, but not indefinitely. It assumes that at most one-third of nodes can be faulty and uses cryptographic signatures to authenticate all messages. That means messages might be delayed, but will eventually arrive, unlike in totally unreliable (asynchronous) systems.

PBFT has a built-in process called view change, which automatically replaces a faulty primary when enough nodes detect issues. Here's how it works in broad strokes:

1. A client (like a user submitting a transaction) sends a request to a primary node.
2. That primary broadcasts the request to other replica nodes.
3. Each replica processes the request and responds.
4. The client waits for enough matching replies (2/3 + 1) to confirm the result.

Suppose the primary node is unresponsive or sends conflicting messages. In that case, replicas can vote to replace it and elect a new primary. This makes PBFT fault-tolerant and adaptive, critical for blockchains operating in the real world.

Real-World Analogy

Imagine you're on a group project. One person (the "primary") shares the final version of the project. Everyone else ("replicas") reviews it. If enough people agree it's correct, you submit it. But if someone thinks the leader messed up, they can flag it—and if enough people agree, the group picks a new leader.

PBFT formalizes this process with message signatures, vote thresholds, and fault limits.

Where PBFT Shines—and Where It Doesn't

PBFT excels in small, permissioned networks where all participants are known and vetted, such as enterprise or consortium blockchains. It offers fast and deterministic finality with fewer probabilistic assumptions than models like proof-of-work or proof-of-stake.

But there are trade-offs:

• It doesn't scale well to hundreds or thousands of nodes—it's communication-heavy.
• Nodes must know about each other ahead of time.
• It's less decentralized and potentially vulnerable to Sybil attacks if new nodes aren't vetted carefully.

That's why PBFT-inspired models are often combined with other mechanisms, like rotating leadership or staking systems, to improve scalability and resilience.

Conclusion

Encryption and consensus might sound like deep technical topics (and they are), but at their core, they solve very human problems: How can we keep secrets? And how can we agree on what's true when no one is in charge? Here's a quick overview of both concepts, what they solve, and what they're used for:

• Public Key Encryption: Secure communication over open networks. Used in Wallets, HTTPS, block signing
• PBFT: Reaching agreement in the face of faulty/lying nodes. Used in permissioned blockchains, early crypto projects

Learning about these two areas gave me a clearer view of the building blocks behind secure, decentralized systems like Cardano—and why consensus and cryptography are so tightly intertwined in Web3.

All of the material in this post comes from Cardano Academy, which continues to be a fantastic first stop in my Web3 learning journey. I'll be adding more resources over time and sharing what I learn along the way. If you're also getting started, check out the Academy, do some digging on your own, and browse through the Midnight docs and Dev Diaries if you want a glimpse of how these ideas show up in practice.

If you're learning along with me, which concepts have been most challenging to wrap your head around? Drop a comment. I’d love to swap resources! More foundational concepts are coming soon!