Web3

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). ...

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. ...

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. ...

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. ...

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. ...

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. 1. Wallet Authentication (Sign-In with Ethereum) 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). ...

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. ...

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. ...

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. ...

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). ...

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 đổ. ...

Đố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: ...

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. ...