Ted Yin | What Will Blockchain Infrastructure Look Like in 2021?
TechFlow Selected TechFlow Selected
Ted Yin | What Will Blockchain Infrastructure Look Like in 2021?
Avalanche's Chief Protocol Architect and Co-founder Ted Yin sharing at BeWater DevCon 2021 Global Developer Conference.
Navigating Web3 tides with focused insights
On September 4, 2021, at the BeWater DevCon 2021 Global Developer Conference, Ted Yin, Chief Protocol Architect and Co-founder of Avalanche, and also the author of the consensus paper HotStuff for Facebook’s Libra/Diem project, joined via video link from across the ocean to deliver a presentation titled "Practice and Reflections on Avalanche."
This in-depth and systematic talk sparked thoughtful reflection among all attendees. Key takeaways:
1. What is blockchain infrastructure in 2021?
2. Evolution of the first two generations of blockchain protocols
3. Third-generation blockchains: The Snow / Avalanche protocol
· Blockchain performance cannot be measured by throughput alone; both "throughput + latency" are needed for a complete evaluation;
· The overhyped concept of “sharding” relates to practical applications but isn't a panacea;
· We can treat gossip networks as consensus itself!
4. Design of meta-platforms and subnet chains
Full text: 7011 words, reading time: 12 minutes
I. What Is Blockchain Infrastructure in 2021?
Hello everyone! I graduated from Shanghai Jiao Tong University, and I’m a co-founder and chief protocol architect of Avalanche.
The following slide was used once back in 2020. People said you’re being lazy, but no—actually, you’ll find some things remain unchanged. Especially transitioning from research to our mainnet launch last year, I’ve observed more academically and earlier than most that new projects emerge every year, yet the underlying infrastructure hasn’t evolved as rapidly as many assume. This may surprise you—there aren’t that many fundamentally different technologies out there.
So let's think: what exactly constitutes blockchain infrastructure?
Take all current elements—sharding, scalability, DAG, smart contracts—and mash them together into an “ultimate Frankenstein,” resulting in the diagram below.
This architecture won’t have just one true chain, but multiple chains acting as subsystems.
For example, a linear chain serves as the ledger. With a linear order established, we can encode computation and operations onto this log or ledger, enabling dApps or standard smart contracts—just like Ethereum’s dApps and smart contracts, where operations form a sequence.
Another example: using a Directed Acyclic Graph (DAG) based chain—DAGs offer useful optimizations in certain systems, allowing parallel execution of time-independent operations. For instance, if A sends money to B and then to C, as long as A has sufficient funds, it doesn't matter whether B receives before C—the order is irrelevant.
The key point is: isolated data structures alone are insufficient. They must be implemented through a consensus algorithm or consistency protocol to ensure not only that the network is distributed, but truly decentralized. Every machine shares the same log, and these logs must be compatible—no divergence allowed.
Blockchain technology enables remarkable achievements. We can’t imagine Alibaba or Tencent letting us run their payment systems at home because they could arbitrarily alter database balances—who would we trust? But with blockchain-based systems, anyone can run a node.
Between the chain and dApps lie agents or intermediaries like Infura. Developers typically don’t run full nodes themselves—they debug locally first, then deploy via a third-party full node.
II. Evolution of the First Two Generations of Blockchain Protocols
1. First-Generation Blockchains: The Satoshi Era
The first generation, Bitcoin, can be understood as a chain of git commits, each with its own hash value—so in a sense, git itself is already a kind of blockchain.
Git could even implement proof-of-work—for example, requiring that each commit represents a fixed number of coding hours with no shortcuts possible. Then whoever maintains the longest commit chain wins—this corresponds directly to the longest chain rule.
Proof-of-work cannot be forged, is easy to verify, and takes considerable time to generate across the system, giving rise toSatoshi Consensus. Eventually, the ledger collapses into a single main chain—this is the principle behind the longest chain.
Advantage 1: Proof-of-work doubles as an access mechanism—"Permissionless"
A powerful feature is that proof-of-work inherently acts as an access control mechanism—an often misunderstood point.
People often contrast consortium chains vs public chains, which fundamentally refers to access control: who gets to participate? Can anyone run a node? However, access mechanisms and consensus mechanisms aren't directly linked. Satoshi’s design happened to use proof-of-work, which also functions as an access mechanism—requiring no special committee or approval process. As long as you have computing power, you can mine. One cannot gain control by increasing node count since nodes don't represent computational power. This aspect of his design is particularly elegant.
Advantage 2: Graceful Security Degradation
Bitcoin features relatively graceful security degradation. In this protocol, security is probabilistic—if an attacker controls a significant portion of hash power, the protocol’s security degrades smoothly rather than catastrophically. It doesn’t suddenly become insecure when centralization crosses a threshold. While the well-known 51% attack exists, security deteriorates gradually as malicious power increases from 1‰ to 51%, forming a continuous, smooth function.
Advantage 3: Loose Membership Information
Bitcoin does not require precise membership information. Mining equals joining—there’s no need to know how many participants exist beforehand, nor any registration required for entry or exit.
Disadvantages: resource waste, low capacity, long confirmation times, poor security efficiency.
These are its advantages, but disadvantages are equally evident:
1. Proof-of-work wastes resources: Old 2018 data shows total network electricity consumption equaled that of Austria or twice Ireland’s annual usage;
2. Low load capacity: Only about 3 transactions per second;
3. Long confirmation times: Following the six-block confirmation rule requires waiting an hour—too long for small transactions.
Additionally, compared to second-generation systems, Bitcoin’s security efficiency is poor. Why?
Second-Generation Blockchains: PBFT — The Pharaoh’s Rebirth
Why call it the pharaoh’s rebirth? This idea has been studied extensively but remained outside mainstream awareness. In traditional large enterprises, those familiar with redundant systems like Paxos and Raft will recognize BFT—it was already commercialized around 2000 for redundancy during crashes or downtime.
If f machines fail, having 2f+1 remaining ensures system continuity—for example, Google typically uses five machines. These systems operate efficiently and highly available, creating the illusion of uninterrupted 24x7 cloud services.
In the early 2000s, websites often required weekly or monthly maintenance, but now zero-downtime maintenance is common. Fault-tolerant systems mask hardware failures. The entire system functions like a massive data center—so many machines that failures occur constantly, continuously replaced. From this perspective, it’s a robust system leveraging blockchain-like tech, albeit centralized under single-entity control.
Advantage 1: Extremely fast network
Back then, more radical ideas emerged: suppose several companies jointly operate the system, none able to directly control the machines. Failures wouldn’t just be power outages or disk crashes, but potentially malicious actors altering data causing reconciliation issues. How can stability be ensured under such weaker assumptions?
Extensive research followed, including the seminal 1999 PBFT (Practical Byzantine Fault Tolerance) paper—a correct and widely considered first practical protocol. It addressed first-gen limitations, achieving high speed in small-scale networks comparable to centralized services—TPS reaching hundreds or thousands, latency in milliseconds.
Advantage 2: Deterministic security
Under favorable network conditions, PBFT-type protocols offer deterministic security—if fewer than one-third of nodes are faulty, the network remains secure. No need to wait for six blocks; once confirmed, it’s final—unlike probabilistic first-gen algorithms.
The problem with second-gen protocols is that exceeding the threshold (more than 1/3 faulty nodes) immediately compromises security, making attacks trivial and rendering the system useless.
Advantage 3: Long-standing research history
Another advantage is its deep academic roots. Consider Satoshi’s approach—not built step-by-step for scientific purposes, but rather designed as an anarchist monetary system, accidentally yielding the Bitcoin system. Later analysis revealed he used computational power as a metric for measuring adversaries within the network.
Problem 1: Hard to scale
Many protocols rely on identities, risking Sybil attacks (one entity creating multiple identities). How to prevent this?
Hence access control mechanisms arise, leading to so-called Proof-of-Stake (PoS), stake-based protocols. Staking isn't inherent to the protocol’s operation, but a prerequisite for correctness. Such protocols face two issues: difficulty scaling; and inefficiency when voting collectively without a unified proposal, requiring extensive time and bandwidth to converge.
Having a leader propose first, followed by support or opposition—or impeachment—speeds things up significantly.
Leader-based BFT resembles the U.S. presidential system, while leaderless BFT mirrors congressional processes—both suffer inefficiencies. In PBFT networks, all nodes query the leader, overwhelming it like a DDoS attack. With 1,000 nodes, the leader faces 1,000 simultaneous requests—leading to scalability issues: how to increase node count without proportional performance decline?
Fully randomized voting BFT schemes perform even worse than leader-based ones.
Problem 2: Requires 100% accurate participant information
PBFT systems require exact knowledge of participants—real-world identity unnecessary, but IDs are essential. If participants are A, B, C, D, E, then the membership list is fixed. Fault tolerance depends entirely on this list—any discrepancy breaks the system. Everyone must possess identical lists, posing implementation challenges: in loosely connected networks, decision-making mechanisms must agree on the list—a solvable but complex task.
Problem 3: Rigid assumption about adversaries
The strict assumption is that faulty nodes must not exceed one-third of consensus nodes—even one extra compromised node renders the entire system insecure. Though the paper spans only a few pages, actual implementation proves extremely difficult.
These protocols are exceptionally complex—core ideas occupy just a few pages, described vaguely, making real-world implementation highly challenging.
Problem 4: Excessively complex core protocol
In 2013, someone complained about incomprehensibility: all they could grasp was a client sending a request, one server broadcasting "hello" to others, servers exchanging votes, maybe starting something, ending in gibberish, then definitively concluding—few in academia truly understand such algorithms.
Thus, we conclude: one-to-many or many-to-many broadcasts create terrible bottlenecks.
III. Third-Generation Blockchains: The Snow / Avalanche Protocol
For third-generation blockchains, we ask: is there a completely different consensus mechanism?
Can sharding solve the problem?
Before addressing this, let’s correct a misconception:
Many believe sharding is miraculous—like a savior: with advances in sharding, "scaling difficulties" are supposedly over.
Sharding is actually a common concept in distributed systems and databases. So if you discuss it with non-blockchain experts, you'll be "surprised to discover" you've been marketed to.
There's nothing wrong with the concept of sharding—it's simply overhyped because it doesn’t directly address consensus-layer scalability, offering only superficial fixes.
Why say it’s superficial? Because improvements come at the cost of reduced fault tolerance. Let’s conduct a thought experiment: if every node becomes its own shard, then each runs an independent system, eliminating redundancy. The more shards, the fewer nodes replicate state, synchronize chain data, and achieve consensus—this is inevitable: sharding and consensus sit on opposite sides of a balance.
Therefore, sharding works best when cross-shard consistency demands are low, e.g., separate payment systems in Shanghai and Beijing—most transactions occur internally, with occasional inter-city transfers requiring slower consistency protocols.
This example shows sharding’s applicability depends heavily on real-world use cases—it’s no silver bullet.
If the base protocol is poor, it's like starting with bad soup—adding chili crisp (laoganma) improves taste slightly, but no amount of laoganma turns bad soup into good soup.
But if the soup base is already excellent—like hotpot—you can still add spice to make it even better.
Third-Generation Protocol: Avalanche Protocol
“Third-generation” doesn’t imply superiority over previous generations—each has strengths. This protocol excels in specific application scenarios, delivering strong functionality and performance.
An Avalanche research paper was posted on IPFS in May 2018, authored collaboratively by our research team, inspired by epidemic models and gossip networks.
The third generation combines strengths of prior generations:
1) Graceful security degradation—the network doesn’t instantly collapse when adversary thresholds are crossed.
2) Loose membership information—minor inconsistencies in node counts or lists don’t impact overall functionality.
3) Sufficiently fast—performance doesn’t degrade linearly or super-linearly with network size; logarithmic degradation would be ideal.
4) Environmentally friendly
5) Intuitive—PBFT-style voting feels unnatural and overly complex; Nakamoto consensus is intuitive but too slow.
Another Misunderstood Concept—TPS Throughput
Other protocols claim high speed and throughput (TPS: transactions per second), but just as we shouldn’t buy phones based solely on benchmark scores,throughput is a misunderstood metric.
In computer systems research papers, especially distributed systems, evaluating performance based solely on throughput is considered dishonest. “Throughput” reflects only a system’s load buffering capability, whereas “latency” measures actual user response speed.
As a user, you don’t care about throughput—how many people the system serves per second. You care about when your transaction gets confirmed—after one second or one hour? That’s called “latency.”
Evaluating a system requires both metrics—throughput and latency are inseparable. A system might appear fast with low latency—like a bank with only one or ten customers—but that’s due to low load. Under heavy queueing, it fails. So given latency, you must examine throughput.
Ignoring latency while focusing only on throughput leads to another extreme in research.
Logistics companies boast internet-rivaling throughput—shipping a truckload of memory cards from Beijing to Shanghai, arriving in three days. Calculated per second, throughput is astonishing—but you can’t use it as a network or for real-time decisions. Ignoring latency while touting throughput is equally misleading.
Hence, both throughput and latency must be evaluated.
The above chart shows Avalanche’s throughput performance as node count doubles. Even with doubling nodes, throughput impact remains minimal—aided by other techniques like DAGs enabling concurrent transactions.
The above chart depicts Avalanche’s base protocol latency under ideal conditions with 2,000 nodes—excluding additional network delays. Even with 2,000 nodes voting, sub-second latency is achievable—the left side shows latency distribution.
Under realistic conditions—with nodes distributed across 20 global cities, full digital signatures enabled, using Bitcoin-standard UTXO model—results remain impressive: maintaining over a thousand TPS while achieving ~1-second confirmation times.
How Is This Achieved? — Gossip Networks as Consensus Itself
Time is limited today—I can’t walk through every detail. Let me explain intuitively the core idea and rationale.
Imagine N people discussing whether a celebrity rumor is verified. Treat truth/falsity as a decision—equivalent to on-chain or off-chain. Each person independently selects k others (e.g., k=10)—even nationwide, still picks only 10 individuals—to check whether they believe the rumor is confirmed or false.
Based on the responses from his k peers, Zhang San updates his confidence in the truth. His stance then influences others who later query him. Through random polling, belief credibility spreads across the network.
Compared to second-gen protocols, the third-gen advantage lies in not querying all nodes—only a randomly sampled subset, whose size relates to security but weakly to network scale. With 1 million nodes, k can still be 10 or 20.
Example:
In this example, each node is represented as a colored circle. Suppose blue means verified, orange means fake. Initially, Zhang San believes it’s fake. He randomly asks five people, three of whom say blue (verified). Li Si asks five others, getting conflicting opinions. The network may oscillate briefly, but minor perturbations quickly cause it to collapse from
an “oscillating state” into a “stable state”—where all nodes share the same color.
Here’s a demo of the Avalanche protocol:
https://tedyin.com/archive/snow-bft-demo/
We observe the protocol exhibits strong robustness.
Protocol Characteristics Summary:
1) Only a small sample needs repeated sampling—no proof-of-work or global voting required.
2) Speed matches network propagation—easy to scale to large node counts.
3) Supports loose membership.
4) Allows arbitrary access mechanisms, such as PoS.
IV. Meta-Platform and Subnet Chains
Our primary chain handles value transfer and transactions. Before NFTs became popular, our testnet already supported NFTs natively under the UTXO model—issuing NFTs requires no smart contracts.
Alternatively, for those preferring smart contract approaches, standard Ethereum-compatible smart contracts are supported. By modifying the endpoint, chain ID, and gas fee in the SDK, Ethereum contracts can be deployed unmodified on Avalanche.
Can we issue our own chains as easily as deploying smart contracts?
Developers wanting an ETH-compliant chain can launch their own. Those wishing to build a WASM-supported custom chain with unique syntax can develop further.
Our mainnet launched in September last year. Seventy percent of the maximum issuance cap is reserved for staking rewards and future ecosystem contributors—the team and investors hold a relatively small share. On day one of mainnet launch, the network was fully decentralized, currently operating over 1,000 decentralized nodes—our company lost control very early.
So consider trying hotpot—especially smart contract developers—consider adopting a faster system.
After a year of refinement, the smart contract chain runs exceptionally smoothly—feel free to try it out!
Q&A Session:
Question: Where does Avalanche’s advantage lie? Solana’s ecosystem seems relatively mature, slightly ahead of Avalanche—what’s your view?
We’ve examined Solana’s technology. They haven’t disclosed many technical details. Subjectively, I believe they aren’t as decentralized. Comparing Avalanche to all existing projects, I see no competitor matching our level of decentralization.To assess a project’s decentralization, examine how many nodes run on the mainnet and who operates them. Answering these two questions reveals the true picture.
I’ve seen projects saying “get on board first, pay later”—build first, raise capital, then gradually implement technology. But why not do it right from the start? We should earn money ethically. Registered in the U.S. and compliant, we invested significant effort upfront ensuring proper project development, translating rigorous academic research into tangible, functional systems. If you review our code, it aligns closely with algorithms proposed two years ago—minor adjustments aside, essentially the same.
From a market perspective—market cap or token price—we may temporarily lag behind so-called competitors. But we don’t see Ethereum or others as rivals. The industry hasn’t gained proper recognition yet—internal infighting is meaningless! The market pie is huge, yet we’ve barely served the appetizers. Why rush to steal others’ dishes when the main course hasn’t even arrived?
Solana is a fellow industry player—we should grow the pie together and share prosperity. Each chain has unique strengths, personalities, and user experiences. What matters most is diligently building solid products, achieving genuine decentralization, and delivering services as promised.
❤ BeWater DevCon 2021 concluded successfully—thank you all for your attention and support ❤
Speaker materials and videos will be released progressively—stay tuned~
-Event Registration-
Fourth private session: September 9 (this Thursday evening)
Scan the QR code below and fill out the application form
Join TechFlow official community to stay tuned Telegram:https://t.me/TechFlowDaily X (Twitter):https://x.com/TechFlowPost X (Twitter) EN:https://x.com/BlockFlow_News
![Axe Compute [NASDAQ: AGPU] completes corporate restructuring (formerly POAI), enterprise-grade decentralized GPU computing power Aethir officially enters the mainstream market](https://upload.techflowpost.com/upload/images/20251212/2025121221124297058230.png?x-oss-process=image/resize,p_50/quality,q_80)
