Web3 on Thanh HV's Blog

12 – So sánh tổng hợp

Sun, 19 Jul 2026 09:00:00 +0700

Các bảng so sánh khách quan, gom về một chỗ để tra cứu. Mỗi bảng đánh giá theo: hiệu năng, bảo mật, độ phức tạp, khả năng mở rộng, chi phí vận hành, use case phù hợp.

1. Bitcoin vs Ethereum vs Solana

Tiêu chí	Bitcoin	Ethereum	Solana
Mục tiêu thiết kế	Tiền tệ phi tập trung, bất biến tối đa	Nền tảng smart contract tổng quát	Hiệu năng cao, chi phí thấp
Model	UTXO	Account	Account (song song hóa)
Consensus	PoW Nakamoto	PoS Gasper	PoS + PoH + Tower BFT
Block time / Finality	~10 phút / probabilistic (~60’ quy ước)	12s / ~13 phút finalized	~400ms / ~13s rooted
TPS thực tế	~7	~15-30 (L1) + L2	~2.000-4.000 (thực tế, không tính vote)
Phí điển hình	$0.5-20+	$0.5-50 (L1), cent (L2)	~$0.001-0.05
Smart contract	Script rất hạn chế	EVM/Solidity — hệ sinh thái lớn nhất	Rust/SVM — nhanh, học dốc hơn
Yêu cầu node	Nhẹ (chạy được trên máy cá nhân)	Trung bình (2TB NVMe)	Rất nặng (256GB RAM, mạng lớn)
Độ ổn định lịch sử	Xuất sắc (15+ năm)	Rất tốt (finality stall ngắn 2023)	Nhiều lần outage toàn mạng 2021-22, cải thiện từ 2023
Phi tập trung	Cao nhất	Cao (lo ngại: Lido, MEV builder)	Thấp hơn (rào cản phần cứng)
Use case hợp	Store of value, settlement lớn	DeFi, tài sản hóa, hạ tầng tổng quát	Thanh toán nhỏ, DEX tần suất cao, consumer app
Cho backend engineer	Tích hợp đơn giản (ít tính năng)	Tài liệu/tooling tốt nhất, nhiều pattern chuẩn	Model khác biệt (không nonce tuần tự, blockhash hết hạn 60s, compute budget)

2. Account Model vs UTXO

(Chi tiết Level 1 §5.4 — bảng đầy đủ tại đó.) Tóm tắt quyết định: cần smart contract/state chung → Account; cần song song + đơn giản + privacy tốt hơn cho thanh toán → UTXO. Chi phí backend: UTXO đắt hơn ở ví (coin selection, change), Account đắt hơn ở gửi tx (nonce management).

11 – Blockchain System Design

Sun, 19 Jul 2026 08:50:00 +0700

Thiết kế 6 hệ thống thực tế, từ yêu cầu đến kiến trúc. Mỗi bài dùng lại các building block đã xây ở Level 5-8: RPC gateway, indexer, transaction service, signing service, outbox/Kafka. Đọc như tài liệu interview system design.

SD-1. Crypto Payment Gateway (nhận thanh toán crypto cho merchant)

Yêu cầu: Merchant tạo hóa đơn → user trả bằng crypto → gateway xác nhận và báo merchant (webhook), hỗ trợ nhiều chain + stablecoin; sai sót ghi sổ = mất tiền thật.

10 – Production Failure Cases

Sun, 19 Jul 2026 08:40:00 +0700

12 tình huống sự cố có thật trong vận hành hệ Web3. Mỗi tình huống: triệu chứng → root cause → thành phần ảnh hưởng → metric/alert → điều tra → khắc phục → phòng tránh. Định dạng gọn để dùng như runbook.

FC-01. Chain Reorganization sâu

Triệu chứng: Số dư user “tự giảm”; đơn nạp tiền đã credit biến mất khỏi explorer; indexer báo lỗi parentHash mismatch hoặc — tệ hơn — chạy tiếp êm ả với dữ liệu sai.

09 – Security cho Blockchain Backend

Sun, 19 Jul 2026 08:30:00 +0700

Bổ sung cho phần security rải rác ở các level: gom thành bức tranh threat model đầy đủ, từ key đến giao thức đến con người.

1. Threat model — nghĩ như kẻ tấn công

Hệ Web3 khác backend thường ở một điểm định mệnh: phần thưởng tấn công là tiền, thanh khoản ngay, không đảo ngược được, và thường ẩn danh được. Backend thường bị tấn công để lấy data (bán lại vòng vo); backend Web3 bị tấn công để rút tiền trực tiếp. Mọi quyết định bảo mật phải xuất phát từ đây: bạn đang vận hành một cái két, không phải một cái CRM.

Level 8 – Production Operations

Sun, 19 Jul 2026 08:20:00 +0700

Câu hỏi trung tâm: Vận hành hệ Web3 24/7: node, RPC, monitoring, DR — khác gì vận hành backend thường, và các con số cụ thể.

1. Node Deployment

1.1. Yêu cầu phần cứng (Ethereum mainnet, 2025-2026)

Thành phần	Full node	Archive node
CPU	8+ cores	16+ cores
RAM	32 GB	64+ GB
Disk	2 TB NVMe (TLC, không QLC/SATA — IOPS là nút cổ chai số 1)	16-20+ TB NVMe
Mạng	25+ Mbps ổn định, chú ý băng thông ra (peer serving)	tương tự
Sync ban đầu	~1-3 ngày (snap sync)	2-6 tuần (full/archive sync!)

Bài học vận hành đau nhất: thời gian sync. Node chết mất data = chờ nhiều ngày để có lại. Vì vậy: snapshot disk định kỳ (vd. mỗi 6-12h, dừng node hoặc dùng filesystem snapshot nhất quán), giữ ≥ 2 node để một chết vẫn còn một, và coi “restore từ snapshot + sync phần còn thiếu” là quy trình DR được diễn tập.

Level 7 – Backend Integration Patterns

Sun, 19 Jul 2026 08:10:00 +0700

Câu hỏi trung tâm: Ghép mọi kiến thức trước đó thành các pattern code cụ thể: auth bằng ví, gửi tx tin cậy từ backend, và pipeline event-driven chống reorg.

Đây là level “ứng dụng” — mỗi pattern dưới đây giải một failure mode có thật trong production.

Problem statement

Đăng nhập không cần password: user chứng minh sở hữu address bằng chữ ký. Sai lầm chết người của cách làm ngây thơ: cho user ký một message cố định → chữ ký bị replay (kẻ trộm được chữ ký cũ đăng nhập mãi mãi).

Level 6 – Scaling: Layer 2, Rollup, Sharding

Sun, 19 Jul 2026 08:00:00 +0700

Câu hỏi trung tâm: Vì sao không thể scale blockchain như scale backend (thêm server, thêm shard), và các giải pháp thực tế đánh đổi điều gì?

1. Problem Statement

Backend truyền thống scale bằng cách chia việc: thêm instance sau load balancer, shard database, mỗi node xử lý một phần. Blockchain L1 không làm vậy được, vì nguyên tắc nền tảng (Level 3): mọi full node thực thi lại mọi transaction để tự verify. Thêm node không tăng throughput — chỉ tăng số bản sao của cùng một công việc.

Level 5 – Blockchain Infrastructure

Sun, 19 Jul 2026 07:50:00 +0700

Câu hỏi trung tâm: Giữa chain và ứng dụng của bạn là cả một tầng hạ tầng. Tầng đó gồm những gì, và bạn nên tự vận hành hay đi thuê?

1. Problem Statement

Ứng dụng Web3 không nói chuyện trực tiếp với “blockchain” — nó nói chuyện với một node cụ thể qua RPC. Node đó có thể chậm, lệch (out of sync), nói dối (nếu là node của người khác), hoặc chết. Toàn bộ Level 5 là về tầng hạ tầng này: node, RPC, indexer, wallet service — nơi 80% công việc backend engineer trong công ty Web3 thực sự diễn ra.

Level 4 – Virtual Machine & Smart Contract

Sun, 19 Jul 2026 07:40:00 +0700

Câu hỏi trung tâm: Làm sao hàng nghìn máy tính không tin nhau chạy cùng một đoạn code và ra cùng một kết quả — và điều đó thay đổi cách viết “business logic” như thế nào?

1. Problem Statement

Bitcoin chứng minh có thể đồng thuận về sổ cái chuyển tiền. Nhưng logic nghiệp vụ thật (escrow, đấu giá, vay thế chấp) cần code tùy ý chạy trên state chung. Vấn đề: code tùy ý từ người lạ là code không tin cậy — có thể lặp vô hạn, phá state, hoặc cho kết quả khác nhau trên các máy khác nhau.

Level 3 – Blockchain Runtime: Transaction Lifecycle

Sun, 19 Jul 2026 07:30:00 +0700

Câu hỏi trung tâm: Từ lúc user bấm “Send” đến lúc backend dám ghi sổ, transaction đi qua những trạng thái nào — và có thể kẹt/chết ở đâu?

1. Problem Statement

Backend Engineer quen với vòng đời request: nhận → validate → xử lý → trả response, đồng bộ, trong vài chục ms, với kết quả nhị phân (thành công/lỗi).

Transaction blockchain hoàn toàn khác: bất đồng bộ, nhiều trạng thái trung gian, có thể kẹt vô hạn, có thể thành công rồi bị hoàn tác, và thất bại vẫn mất phí. Không hiểu vòng đời này là nguồn gốc của phần lớn sự cố production trong hệ thống Web3 (tx stuck, double credit, nonce conflict — xem file Failure Cases).

Level 2 – Distributed Systems & Consensus

Sun, 19 Jul 2026 07:20:00 +0700

Câu hỏi trung tâm: Hàng nghìn node không tin nhau, kết nối qua mạng không đáng tin, làm sao đồng ý về MỘT lịch sử transaction duy nhất?

1. Problem Statement

Level 1 kết thúc với replicated state machine: mọi node áp dụng cùng dãy transaction sẽ có cùng state. Vấn đề duy nhất còn lại — và là vấn đề khó nhất — là thứ tự (ordering).

Trong hệ tập trung, ordering miễn phí: single writer quyết định. Trong Raft cluster, leader quyết định và các follower tin leader. Nhưng khi node có thể nói dối (gửi block khác nhau cho các peer khác nhau, giả vờ chưa nhận message, tạo hàng nghìn identity giả), mọi giao thức consensus cổ điển sụp đổ.

Level 1 – Blockchain Fundamentals

Sun, 19 Jul 2026 07:10:00 +0700

Đối tượng: Backend Engineer chưa từng làm Blockchain. Mục tiêu: Hiểu Blockchain là gì từ góc nhìn Distributed Systems, không phải từ góc nhìn Crypto.

1. Problem Statement: Bắt đầu từ bài toán nghiệp vụ

Hãy quên Blockchain đi. Bắt đầu từ một bài toán Backend quen thuộc.

Bạn xây dựng hệ thống chuyển tiền giữa hai ngân hàng A và B. Mỗi ngân hàng có database riêng (PostgreSQL chẳng hạn). Khi khách hàng của A chuyển 100$ cho khách hàng của B, cả hai database phải đồng thời:

Blockchain cho Backend Engineer

Sun, 19 Jul 2026 07:00:00 +0700

Bộ tài liệu chuyên sâu về Blockchain dưới góc nhìn Distributed Systems và Backend Architecture — dành cho Backend/Senior Backend Engineer, Blockchain Backend Developer và Software/Solution Architect.

Không phải tài liệu đầu tư crypto, không phải khóa học Solidity. Mục tiêu: hiểu blockchain là một hệ phân tán chuyên biệt — nơi cryptography, networking, consensus, economics và backend engineering kết hợp để quản lý state trong môi trường trustless — và xây dựng, vận hành được các hệ thống tích hợp blockchain trong production.

Web3 on Thanh HV's Blog

12 – So sánh tổng hợp

1. Bitcoin vs Ethereum vs Solana

2. Account Model vs UTXO

11 – Blockchain System Design

SD-1. Crypto Payment Gateway (nhận thanh toán crypto cho merchant)

10 – Production Failure Cases

FC-01. Chain Reorganization sâu

09 – Security cho Blockchain Backend

1. Threat model — nghĩ như kẻ tấn công

Level 8 – Production Operations

1. Node Deployment

1.1. Yêu cầu phần cứng (Ethereum mainnet, 2025-2026)

Level 7 – Backend Integration Patterns

1. Wallet Authentication (Sign-In with Ethereum)

Problem statement

Level 6 – Scaling: Layer 2, Rollup, Sharding

1. Problem Statement

Level 5 – Blockchain Infrastructure

1. Problem Statement

Level 4 – Virtual Machine & Smart Contract

1. Problem Statement

Level 3 – Blockchain Runtime: Transaction Lifecycle

1. Problem Statement

Level 2 – Distributed Systems & Consensus

1. Problem Statement

Level 1 – Blockchain Fundamentals

1. Problem Statement: Bắt đầu từ bài toán nghiệp vụ

Blockchain cho Backend Engineer