Forem: yanjun qiu

A Brief Pause, and What’s Next in My 90-Day Web3 Learning Journey

yanjun qiu — Sat, 24 Jan 2026 08:55:44 +0000

A Quick Explanation

It’s been about nine days since my last post, so I want to be transparent about the pause.

During this period, I transitioned into a new role at a new company. While it’s not in the Web3 space, the onboarding process required a significant amount of focus — getting familiar with the codebase, internal tooling, and the team’s workflow.

Rather than rushing low-quality updates, I decided to temporarily pause publishing and give myself the space to properly settle in. That context switch took a bit longer than expected, but it was necessary.

Now that I’m back in a stable rhythm at work, I’m ready to continue this 90-day learning experiment.

I’m Back to the 90-Day Experiment

This pause doesn’t change the original intent of this series.

I’m still committed to the 90-day learning experiment and to learning Web3 in public — documenting what I learn, what I misunderstand, and how my mental models evolve over time.

That said, I want this journey to be sustainable. Instead of forcing updates just to keep a streak alive, my focus will remain on consistency and quality. Some days may go deeper than others, but every post will reflect real learning and hands-on understanding.

With that in mind, I’m officially back and continuing from where I left off.

What I’ll Focus on Next

Over the past few days of reading and exploration, I’ve become increasingly interested in the Solana ecosystem.

After covering the fundamental concepts of Web3 and blockchain — such as how blockchains work, trust models, and smart contract fundamentals — I plan to gradually shift part of my focus toward Solana-specific topics.

The reason is simple: Solana presents a very different set of design trade-offs compared to EVM-based chains. Its execution model, performance characteristics, and developer experience raise questions that are especially interesting from a systems and engineering perspective.

To support this direction, I’ll also start learning Rust, which is widely used in the Solana ecosystem. This will be a longer-term investment, and I’ll document both the conceptual learning and the hands-on challenges along the way.

If you’re curious about Solana, Rust, or how different blockchain architectures compare in practice, I hope this part of the journey will be useful to you as well.

What You Can Expect Going Forward

Going forward, I’ll continue sharing concise, hands-on learning notes as part of this 90-day experiment.

Each post will focus on understanding core concepts, building correct mental models, and connecting theory with practical implementation — whether that’s through code snippets, diagrams, or small experiments.

This series remains a learning log, not a set of polished tutorials. Mistakes, confusion, and course corrections are all part of the process, and I’ll document them honestly as they happen.

If you’re on a similar path, I hope these posts can serve as a useful reference — or at least a reminder that learning complex systems is rarely a straight line.

Day 3: Understanding L2 Caching and the Oracle Callback Pattern

yanjun qiu — Thu, 15 Jan 2026 08:41:04 +0000

Core Concept

In this stage of my learning, I have focused on organizing the most critical components of the blockchain's evolution from a "ledger" to a "world computer." These concepts are categorized into the Application Layer, the Architecture Layer, and the Connectivity Layer.

Application Layer: The Three Pillars of Web3

DeFi (Decentralized Finance): A set of financial protocols running on public blockchains, where the core principle is "Code is Law." It replaces traditional financial intermediaries like banks, stock exchanges, and brokers with smart contracts.
NFT (Non-Fungible Token): Unlike Bitcoin, which is divisible and interchangeable, every NFT is unique. It serves as the underlying proof of "scarcity" and "ownership" in the digital world, with use cases extending from artwork to in-game assets and Real World Assets (RWA).
DAO (Decentralized Autonomous Organization): A new form of collective organization. Members exercise voting rights by holding tokens, and the organization’s rules and treasury management are executed automatically by on-chain code rather than traditional administrative mandates.

Architecture Layer: The Evolution of L1 and L2

L1 (Layer 1 - The Base Layer): Refers to the primary blockchain network, such as Ethereum or Bitcoin. It is responsible for final settlement, security, and decentralization. However, due to performance constraints, L1s often face congestion and high transaction fees.
L2 (Layer 2 - The Scaling Layer): Secondary protocols built on top of L1 (such as Arbitrum or Optimism). L2s process thousands of transactions off-chain and then bundle the results to be sent back to L1 for verification. The goal is to achieve high scalability without sacrificing security.

Connectivity Layer: Oracle

Oracle: Blockchain is a closed, deterministic system; it cannot perceive the outside world (such as tomorrow's weather or current stock prices). Oracles act as "middleware," securely feeding real-world data into smart contracts and breaking the "silo effect" of the blockchain.

Mental Model / Abstraction

To quickly grasp these Web3 concepts, we can draw analogies from traditional backend architectures:

L1 & L2: The Main DB and "Write-Back Cache"

L1 as the "Global, Single-Source Production Main Database": Think of L1 as an extremely expensive financial-grade database with very low write TPS but the highest levels of consistency and physical security. Every write (transaction) requires consensus across tens of thousands of nodes globally, making it costly and slow.
L2 as a "Write-Back Cache / Buffer with Batching": L2 acts like a high-performance caching layer sitting in front of the main database.
- Fast Response: User requests are first completed within the L2 cache, reducing response times from minutes to milliseconds.
- Asynchronous Submission: L2 does not write every single transaction to L1 immediately. Instead, it aggregates (Rolls up) and compresses thousands of transactions over a period of time, then performs an Asynchronous Batch Commit to the L1 main DB.
- Eventual Consistency: Just like syncing a cache to a database, L2 ensures that the final state recorded on L1—the "Source of Truth"—is verifiable and immutable.

Oracle: The "Deterministic Input Adapter" in Distributed Systems

Mental Model: Tainted External Data Sources and Consensus Consistency. In backend development, if we need to execute logic based on "weather," we simply call weather_api.get() in our code. In the "deterministic state machine" of a blockchain, however, this would be disastrous.
The Analogy: Imagine a distributed computing cluster with 1,000 nodes.
The Conflict Scenario: If a smart contract says "Refund if it rains," and every node calls a weather API at different times or from different locations, some might get "Sunny" while others get "Rainy." The cluster would never reach consensus, and the ledger would halt or fork.
The Solution: An Oracle acts as the cluster’s only authoritative, digitally signed "Deterministic Input Gateway." It packages a fact—such as "Temp in Shanghai at 12:00 is 25°C"—into a signed snapshot and feeds it onto the chain. This ensures every node sees the exact same input, thereby guaranteeing deterministic calculation results.

Day 2: Blockchain Basics | From Centralized DB to Distributed State Machine

yanjun qiu — Wed, 14 Jan 2026 07:48:31 +0000

The Paradigm Shift — From Centralized Databases to Decentralized Ledgers

As a backend engineer with nearly a decade of experience, I am accustomed to distributed systems, microservices, and ACID transactions. However, on my first day entering Web3, I realized that the core shift isn't about the language (Solidity vs. Go/Java), but rather a fundamental change in the underlying paradigm of data storage and trust.

1. Core Concept: What is Blockchain, Really?

In Web2 backend architecture, we talk about Databases. Whether it is MySQL or MongoDB, there is always an ultimate "administrator" who possesses CRUD (Create, Read, Update, Delete) permissions over the data.

In Web3, a blockchain is essentially a globally shared, deterministic state machine.

No more CRUD: On a blockchain, you only have "Read" and "Append" (changing state via Transactions).
Decentralized Network: There is no centralized AWS or IDC. Data exists across thousands of Nodes, each holding a complete copy of the ledger.

2. Mental Model: Web2 Database vs. Web3 Ledger

To better understand this, I have constructed a comparison model from a backend perspective:

Dimension	Web2	Web3
Data Consistency	Relies on Raft/Paxos or centralized Master-Slave sync	Relies on Consensus Mechanisms (PoW/PoS)
Source of Trust	Trust in DBAs or Cloud Providers	Trust in Math, Algorithms, and Open Source Code
Write Operations	Low latency, nearly free	High latency, requires Gas Fees (to incentivize nodes)
Transparency	Internal visibility; data can be modified/rolled back	Globally transparent; data is Immutable

My Understanding: If a Web2 database is like a private Excel spreadsheet within a company, then a blockchain is like a giant ledger placed in a busy town square—everyone can watch it, and you can only write to it with a permanent pen. It can never be erased.

3. Why Do We Need It? (The "Why")

As backend developers, we frequently deal with "third-party integrations" and "reconciliation" issues.

The Pain Point: In Web2, when two systems (e.g., Bank A and Bank B) interact, they must each maintain their own databases and then use tedious reconciliation processes to ensure data consistency.
The Web3 Solution: Everyone operates directly on the same state machine. Because the ledger is unique, transparent, and immutable, we no longer need expensive "trust costs" or "reconciliation costs."

The Core Challenge — Trust & Consensus

In Web2 systems, trust is typically centralized. You trust the data in a database because you trust the company operating it, the trained DBAs, and the firewalls. However, in the permissionless environment of Web3, where participants are anonymous to one another, how do we reach an agreement?

1. Core Concept: What is Consensus?

In Distributed Systems, consensus refers to how all nodes in a network reaching an agreement on a specific state.

Web2 Perspective: We commonly use algorithms like Raft or Paxos to solve "High Availability" issues. We assume nodes might go offline, but we generally do not assume nodes will "intentionally act maliciously."
Web3 Perspective: Blockchains face the much more extreme Byzantine Generals Problem. We must account for not only node crashes but also nodes being compromised by hackers to intentionally send fraudulent data (such as Double Spending attacks).

Consensus Mechanisms are a set of game-theory rules. they ensure that as long as the majority follows the rules, the ledger remains secure, even if there are bad actors in the network.

2. Mental Model: From "Seal & Stamp" to "Hash Power/Staking"

To understand the transformation of trust, we can build this model:

Traditional Trust (Proof of Authority): Similar to banking services, you trust the official seal. The bank, as an intermediary, endorses the authenticity of the transaction.
Web3 Trust (Proof of Work / Proof of Stake):
- PoW (Proof of Work): Trust originates from "physical energy." To act maliciously, one must possess over 51% of the network's total computing power, which requires astronomical electricity costs. The cost of an attack far outweighs the potential gain.
- PoS (Proof of Stake): Trust originates from "economic interest." To act maliciously, you must stake a large amount of tokens (e.g., ETH). If the system detects a violation, your collateral is "slashed" (confiscated).

My Understanding: Blockchains do not eliminate trust; they shift trust from "people/institutions" to "economic costs and mathematical algorithms."

3. 51% Attack: Where is the Security Boundary?

As engineers, we always focus on system boundaries. The so-called 51% Attack is the most famous security vulnerability in blockchain:

If an entity controls more than half of the network's hash power or stake, they can indeed modify transactions that haven't been fully confirmed, causing a "rollback."
The Reality: For massive networks like Bitcoin or Ethereum, the cost of launching a 51% attack reaches billions or even tens of billions of dollars. This "extremely high cost of malice" constitutes logical Immutability.

4. Problem Solved: Uncertainty & Friction (The "Unstuck" Moment)

Why do we go to such lengths for consensus?

Eliminating Settlement Latency: In traditional finance, cross-border transfers take 3-5 days because countless intermediaries are performing manual "trust reconciliation."
Irrevocable Contracts: Once consensus is reached, the transaction is written into the "permanent ledger." No CEO or government can unilaterally withdraw a confirmed on-chain transaction.

Where I got confused and how I got unstuck

Who deploys all these nodes? What if they all go down?
My Confusion: As a backend engineer, I’m used to servers being managed by a centralized DevOps team. In a blockchain with thousands of nodes, who is actually deploying them? Without a central authority, how can we ensure the network doesn't just collective crash?

How I got unstuck:

Decentralized Operators: Nodes are deployed by independent individuals or organizations (Miners or Validators). Anyone with the right hardware and software can join the network.
Incentive-Driven Maintenance: Nobody maintains the network out of pure kindness. They do it for Token Rewards. As long as the network processes transactions, nodes earn gas fees and newly minted tokens.
Redundancy over "Single Point of Failure": Blockchain doesn't guarantee that a single node won't fail; it guarantees the high availability of the entire network. While a Web2 service might go down if a specific AWS region has an outage, a blockchain stays alive as long as even a handful of nodes are running somewhere in the world.

Good resources for learning

Cyfrin: a good website has all the knowledges about web3, good for beginner.

A 90-Day Journey Into Web3: From Senior Backend Engineer to Smart Contract Developer

yanjun qiu — Tue, 13 Jan 2026 11:20:23 +0000

A bit of background: I have been a backend engineer for nearly a decade, including six years spent in the financial technology sector. Until a year ago, my knowledge of crypto was limited to Bitcoin and a few major exchanges. However, as I navigated platforms like Twitter, YouTube, and Reddit, one term became impossible to ignore: Web3.

Discussions around DeFi, dApps, NFTs, and DAOs piqued my interest. As I spent my spare time researching these concepts, I began to grasp the true potential of Web3. I felt a mix of curiosity and intimidation, coupled with a strong sense that I was arriving late to a massive technological shift.

I am deeply passionate about transitioning into a Web3 developer, with a specific focus on Smart Contracts and DeFi protocols. Rather than studying in isolation, I’ve decided to "Learn in Public." This approach will keep me accountable, maintain my momentum, and allow me to engage with the community while solving problems.

If you are also navigating the Web3 learning curve, I invite you to follow my journey. Let’s build, learn, and bridge the gap from Web2 to Web3 together!

The 90-Day Experiment

Here’s the commitment I’m making publicly:

Duration: 90 days.
Frequency: One Web3 concept or technical topic per day.
Distribution: Cross-posting on Dev.to, Medium, Reddit, and Twitter.
Engagement: Active participation in Web3 communities via Discord and Telegram.
Open Source: A dedicated GitHub repository to share all code samples and projects during my learning journey.

These articles are not intended to be “expert tutorials.” Instead, they are “learning logs” distilled into clear, actionable explanations. Each post will follow a consistent structure:

What I tried to understand today
How I would explain it to a non-technical friend
Why it actually matters in the real world
Where I got confused and how I got unstuck
Good resources I found for going deeper

By the end of this 90-day sprint, I aim to achieve three key goals:

A public portfolio demonstrating a mastery of Web3 fundamentals.
Documented evidence of my ability to simplify and communicate complex technical concepts.
A robust "Proof of Work" and technical foundation to confidently apply for Web3 Developer roles.

Who This Series Is For

The series is for you if:

The Curious: If you’ve heard about Web3, DAOs, DeFi, and NFTs and don't want to be left behind.
Web2 Developers: If you are a developer looking to pivot into the decentralized space.
Fellow Learners: If you’re on a similar path and seeking community and discussion.

This is also for the future hiring manager who might look at my resume and wonder, "can this person has the ability to build real things what we want?" Instead of answering that in a cover letter, I’d rather show them 90 days of consistent, public, practical learning.

What You Can Expect From Each Post

to keep things consistent(for you and for me), each posts in this serise will roughly follow this structure:

Core concept A precise definition of the Web3 concept I studied that day, using correct terminology and boundaries (what it is / what it is not).

Mental model / abstraction
How I model this concept from a system or engineering perspective (components, responsibilities, data flow, trust assumptions).

Practical implications
What this concept enables or restricts in real systems (performance, security, cost, UX, decentralization trade-offs).

Hands-on takeaway
Concrete outcomes such as:

code snippets
pseudo-code
contract examples
configuration samples
or interaction flows (e.g. wallet → contract → state change)

Common pitfalls and confusions
What initially confused me, incorrect assumptions I had, and how I resolved them.

References
Links to official docs, specs, repos, or high-quality technical resources used during learning.

The goal is to create a traceable record of what I learned, what I understood, and what I can actually do at that point in time.

What I’m Hoping to Get Out of This

Personally, I am aming to transition into a web3 developer, espically for defi and smart contract. so below is what I want after 90 days learning:

Know all the basic and advantage knowledges about web3.
Has the ability to develop the real production level code.

How You Can Use This Series

Here’s how you can get value from this:

If you’re new to Web3: Read along, ask questions, challenge things that don’t make sense.
If you’re already in Web3: Tell me what I’m missing, correct mistakes, suggest better resources.

What’s Coming Next

The next post in this series will be:

“Blockchain basic knowledge: Breaking Down the Basic tech knowledge”

That article will try to answer:

What is a blockchain, really, without buzzwords?
Why do we even need it when we already have databases and banks?
And how would you explain it to someone who doesn’t care about tech at all?

If that sounds interesting, you can:

Follow me here on Dev.to: @yanjun
Connect with me on Twitter, Medium if you’re on a similar path

This is Day 1 of 90.

Let’s see where this goes.