Syllabus học Blockchain & Fintech

UpdatedJuly 11, 2026

•172 min read•View as Markdown

Hải Yến Trịnh

Part of seriesKnowledge

PHẦN 0 - MÔI TRƯỜNG & NỀN TẢNG KỸ THUẬT (Ngày 1–15)

Tuần 1 (Ngày 1–5): Môi trường làm việc & hệ điều hành

Ngày 1: Cài đặt môi trường ảo hóa

Khái niệm
- Type-1 vs Type-2 hypervisor - vì sao KVM (Type-1, tích hợp kernel) nhanh hơn VirtualBox (Type-2) trên Linux host.
- Virtualization extension: Intel VT-x/AMD-V - kiểm tra egrep -c '(vmx|svm)' /proc/cpuinfo.
Thực hành và quan sát
- Cài libvirt + qemu-kvm (Linux host) hoặc VirtualBox (macOS/Windows).
- Tải ISO Ubuntu Server hoặc Rocky Linux minimal, cài thủ công - partition bằng tay (không auto-partition) để hiểu layout /, /boot, swap.
Advanced concepts
- Nested virtualization: bật kvm_intel nested=1 nếu lab trong VM của công ty.

Ngày 2: Linux fundamentals cho node operator

Khái niệm
- Process, file descriptor, systemd unit - vì sao blockchain client chạy như systemd service trong production.
- Filesystem: ext4 vs XFS - I/O pattern nào phù hợp với write-heavy workload (LSM-tree DB của node).
Thực hành và quan sát
- Viết 1 systemd unit file cho 1 process giả lập, cấu hình restart policy, resource limit (MemoryMax, CPUQuota).
- Dùng strace, lsof quan sát 1 process đang mở file/socket.
Advanced concepts
- cgroups v2 - cách Kubernetes/systemd dùng để giới hạn tài nguyên node.

Ngày 3: Networking cơ bản cho P2P systems

Khái niệm
- TCP handshake, TLS handshake, UDP - tại sao QUIC (dùng trong libp2p mới) kết hợp cả hai ưu điểm.
- NAT, port forwarding - vì sao node ở sau NAT khó nhận inbound connection.
Thực hành và quan sát
- Dùng tcpdump/Wireshark bắt gói tin của 1 kết nối TCP thật, quan sát 3-way handshake.
- Setup port forwarding trên router/VM để mở 1 cổng TCP ra ngoài, test bằng nc.
Advanced concepts
- STUN/TURN - kỹ thuật NAT traversal dùng trong nhiều P2P client.

Ngày 4: Git, containerization, và reproducible environment

Khái niệm
- Git internals sơ lược: object model (blob/tree/commit) - tại sao Git là 1 dạng content-addressed store (liên hệ trực tiếp tới Merkle DAG của blockchain).
- Docker: layer, union filesystem, image vs container.
Thực hành và quan sát
- Viết Dockerfile multi-stage build cho 1 ứng dụng Go/Rust đơn giản.
- Dùng git cat-file -p để xem raw object của 1 commit - so sánh cấu trúc với block header sẽ học sau.
Advanced concepts
- Content-addressable storage là mẫu số chung của Git, IPFS, và blockchain state - ghi chú lại để liên hệ xuyên suốt khóa học.

Ngày 5: Ôn tập tuần 1 + setup toolchain ngôn ngữ

Khái niệm
- So sánh Rust vs Go cho hệ thống blockchain: ownership model (Rust, không GC) vs garbage collector (Go) - ảnh hưởng tới độ trễ (latency) trong validator node.
Thực hành và quan sát
- Cài Rust (rustup) + Go, viết "hello world" cho cả hai, build binary, đo thời gian compile và kích thước binary.
Advanced concepts
- Đọc lý do Solana chọn Rust, Cosmos SDK chọn Go - trade-off thực tế của các dự án lớn.

Tuần 2 (Ngày 6–10): Cấu trúc dữ liệu nền tảng

Ngày 6: Hash function nhập môn & Merkle Tree (lý thuyết)

Khái niệm
- Thuộc tính hash: preimage resistance, second-preimage resistance, collision resistance.
- Merkle Tree: cách build từ leaf lên root, tại sao root thay đổi khi 1 leaf thay đổi (avalanche qua cấu trúc cây).
Thực hành và quan sát
- Vẽ tay 1 Merkle Tree 8 leaf, tính root bằng SHA-256 qua script Python.
Advanced concepts
- Merkle proof (inclusion proof) - kích thước proof là O(log n), tại sao điều này quan trọng cho light client.

Ngày 7: Implement Merkle Tree từ đầu

Khái niệm
- Padding khi số leaf lẻ, thứ tự nối hash trái/phải (ảnh hưởng tới second-preimage attack nếu làm sai - CVE thực tế của nhiều dự án).
Thực hành và quan sát
- Code Merkle Tree bằng Rust/Python: build tree, generate proof, verify proof. Viết unit test cho trường hợp leaf bị sửa.
Advanced concepts
- Sparse Merkle Tree - dùng khi cần chứng minh "key không tồn tại" (non-membership proof), nền tảng của nhiều light client hiện đại.

Ngày 8: Merkle Patricia Trie (MPT) - bước đệm cho Ethereum

Khái niệm
- Trie thường vs Patricia Trie (path compression) vs Merkle Patricia Trie (kết hợp hash).
- 3 loại node trong MPT của Ethereum: leaf, extension, branch.
Thực hành và quan sát
- Vẽ tay MPT cho 3 key/value đơn giản, xác định loại node ở mỗi bước.
Advanced concepts
- Verkle Tree - thay thế MPT trong tương lai Ethereum, dùng vector commitment thay vì hash thường (ghi chú, học sâu ở Phần Advanced Crypto).

Ngày 9: Bloom Filter & xác suất trong cấu trúc dữ liệu blockchain

Khái niệm
- Bloom filter: false positive rate, số hash function tối ưu - dùng trong Ethereum log filter (eth_getLogs).
Thực hành và quan sát
- Implement Bloom filter từ đầu, đo false positive rate thực tế với các kích thước bitset khác nhau.
Advanced concepts
- Golomb-coded set - Bitcoin dùng cho BIP-158 (compact block filter), hiệu quả hơn Bloom filter về kích thước.

Ngày 10: Big number arithmetic & modular math

Khái niệm
- Modular exponentiation, extended Euclidean algorithm (tìm nghịch đảo modular) - nền tảng trực tiếp cho ECDSA tuần sau.
Thực hành và quan sát
- Implement modular exponentiation bằng square-and-multiply (không dùng thư viện bignum có sẵn phần lõi), so sánh tốc độ với thư viện chuẩn.
Advanced concepts
- Montgomery multiplication - kỹ thuật tối ưu modular arithmetic dùng trong hầu hết thư viện crypto production.

Tuần 3 (Ngày 11–15): Tư duy hệ thống & độ phức tạp

Ngày 11: Độ phức tạp thuật toán & gas cost

Khái niệm
- Big-O cho các thao tác cơ bản: array access O(1), tìm kiếm trong trie O(log n) - liên hệ trực tiếp tới bảng gas cost EVM sẽ học.
Thực hành và quan sát
- Viết benchmark so sánh O(n) vs O(log n) vs O(n²) trên tập dữ liệu lớn dần, vẽ biểu đồ thời gian thực tế.
Advanced concepts
- Amortized complexity - vì sao dynamic array (Vec trong Rust) có amortized O(1) append.

Ngày 12: State machine & event sourcing (nhập môn)

Khái niệm
- Định nghĩa formal: State × Event → State' - đây chính là mô hình mọi blockchain đều tuân theo.
Thực hành và quan sát
- Implement 1 state machine đơn giản (VD: máy bán hàng tự động) bằng pattern match trong Rust/Go, log lại toàn bộ event.
Advanced concepts
- Event sourcing vs CRUD truyền thống - tại sao ledger tài chính (và blockchain) luôn dùng append-only log thay vì update-in-place.

Ngày 13: Serialization formats

Khái niệm
- JSON vs Protobuf vs RLP (Recursive Length Prefix - dùng trong Ethereum) - trade-off kích thước, tốc độ, khả năng xác định (determinism).
Thực hành và quan sát
- Implement RLP encode/decode từ đầu cho vài kiểu dữ liệu (string, list lồng nhau), so sánh output với thư viện chuẩn.
Advanced concepts
- Vì sao RLP phải deterministic tuyệt đối (không như JSON có thể sắp xếp key khác nhau) - ảnh hưởng tới việc hash dữ liệu để đưa vào block.

Ngày 14: Đọc code người khác - kỹ năng bắt buộc

Khái niệm
- Kỹ thuật đọc codebase lớn: đọc từ entry point (main.rs/main.go), dùng grep/ripgrep tìm định nghĩa struct/interface trước khi đọc logic.
Thực hành và quan sát
- Clone 1 repo nhỏ (VD: 1 CLI tool Rust ~2000 dòng), vẽ sơ đồ module dependency bằng tay trong 1 giờ.
Advanced concepts
- Dùng cargo doc/godoc sinh tài liệu tự động để định hướng đọc nhanh hơn.

Ngày 15: Ôn tập Phần 0 + Bài test tổng hợp

Khái niệm
- Ôn lại: Merkle Tree, MPT, Bloom filter, RLP, modular math.
Thực hành và quan sát
- Bài test tự làm: cho 1 tập dữ liệu, build Merkle root, tạo và verify 1 proof, encode bằng RLP - tất cả trong 1 chương trình, không dùng thư viện ngoài cho phần crypto.
Advanced concepts
- Review lại toàn bộ code đã viết tuần 1-3, refactor cho sạch - chuẩn bị tâm thế "code sẽ được đọc lại nhiều lần" giống production thật.

PHẦN 1 - DISTRIBUTED SYSTEMS FOUNDATION (Ngày 16–35)

Tuần 4 (Ngày 16–20): Mô hình hệ thống phân tán

Ngày 16: Mô hình lỗi & giả định hệ thống

Khái niệm
- Failure model: crash-stop, crash-recovery, Byzantine (arbitrary) - tại sao blockchain phải giả định Byzantine trong khi Paxos/Raft chỉ giả định crash-stop.
- Synchronous vs asynchronous vs partially synchronous network model.
Thực hành và quan sát
- Vẽ bảng so sánh 3 mô hình lỗi với ví dụ thực tế (node bị crash vs node bị hack gửi dữ liệu sai).
Advanced concepts
- Đọc paper gốc Lamport "Time, Clocks, and the Ordering of Events in a Distributed System" (1978) - nền tảng của logical clock.

Ngày 17: FLP Impossibility

Khái niệm
- Định lý FLP: không thể có thuật toán consensus deterministic đảm bảo cả safety và liveness trong mô hình async với dù chỉ 1 node lỗi.
- Vì sao đây là lý do mọi hệ thống thực tế (kể cả blockchain) phải "lách" bằng cách hy sinh 1 phần (dùng timeout, randomness, hoặc partial synchrony).
Thực hành và quan sát
- Đọc paper gốc FLP (1985), tóm tắt lại chứng minh bằng ngôn ngữ của riêng bạn (không chép lại) trong 1 trang.
Advanced concepts
- So sánh cách Bitcoin "lách" FLP (dùng PoW + xác suất, không cần finality tuyệt đối) vs cách Tendermint "lách" (dùng partial synchrony + 2/3 voting).

Ngày 18: CAP Theorem - hiểu đúng, không hiểu sai

Khái niệm
- CAP: Consistency, Availability, Partition tolerance - vì sao P không phải "lựa chọn" (mạng luôn có thể partition) mà là hy sinh giữa C và A khi có partition.
- Sai lầm phổ biến: "CAP nói bạn chỉ chọn được 2/3" - thực ra chỉ có ý nghĩa khi network bị partition.
Thực hành và quan sát
- Phân loại 5 hệ thống bạn biết (PostgreSQL single-node, Cassandra, Ethereum, Tendermint chain, DynamoDB) theo CP hay AP.
Advanced concepts
- PACELC theorem - mở rộng CAP, thêm trade-off Latency vs Consistency ngay cả khi không có partition.

Ngày 19: Consistency models

Khái niệm
- Linearizability, sequential consistency, causal consistency, eventual consistency - thứ tự mạnh yếu dần.
- Liên hệ: blockchain với finality tuyệt đối (Tendermint) ≈ linearizable; blockchain PoW trước finality ≈ eventual consistency.
Thực hành và quan sát
- Viết 3 kịch bản cụ thể (VD: 2 client đọc/ghi cùng lúc) minh họa sự khác biệt giữa linearizable và eventually consistent.
Advanced concepts
- Snapshot isolation, serializability trong database - liên hệ tới MEV (2 giao dịch cùng đọc 1 state, ai xử lý trước quyết định kết quả).

Ngày 20: Logical clocks & Vector clocks

Khái niệm
- Lamport timestamp: cách gán thứ tự "happens-before" mà không cần đồng bộ đồng hồ vật lý.
- Vector clock: phát hiện concurrent events mà Lamport timestamp không làm được.
Thực hành và quan sát
- Implement Lamport clock cho 3 process giả lập gửi message qua nhau, in ra thứ tự sự kiện.
Advanced concepts
- So sánh với block timestamp trong blockchain - tại sao block timestamp KHÔNG phải logical clock mà chỉ là gợi ý (miner/validator có thể gian lận trong biên độ cho phép).

Tuần 5 (Ngày 21–25): Consensus cổ điển (crash fault tolerant)

Ngày 21: Quorum systems

Khái niệm
- Quorum: tại sao majority quorum (>n/2) đảm bảo 2 quorum bất kỳ luôn giao nhau - nền tảng toán học của mọi consensus.
Thực hành và quan sát
- Chứng minh bằng tay: với n=5, quorum ≥3 luôn giao nhau ít nhất 1 node; thử với quorum=2 để thấy tại sao sai.
Advanced concepts
- Weighted quorum - dùng trong PoS khi voting power khác nhau theo stake, không phải theo số node.

Ngày 22: Paxos - lý thuyết

Khái niệm
- Basic Paxos: 2 phase (Prepare/Promise, Accept/Accepted), vai trò Proposer/Acceptor/Learner.
- Vì sao Paxos đúng (an toàn) nhưng khó hiểu và khó implement đúng trong thực tế.
Thực hành và quan sát
- Trace tay 1 kịch bản Paxos với 5 acceptor, 2 proposer cạnh tranh, ghi lại từng bước message.
Advanced concepts
- Multi-Paxos - tối ưu Basic Paxos cho chuỗi quyết định liên tiếp (giống blockchain cần quyết định liên tiếp từng block).

Ngày 23: Raft - Paxos dễ hiểu hơn

Khái niệm
- Raft: leader election, log replication, safety - thiết kế để dễ hiểu/implement hơn Paxos nhưng tương đương về mặt lý thuyết.
Thực hành và quan sát
- Dùng raftscope (công cụ visualize Raft trực tuyến) hoặc tự code leader election đơn giản với 5 node giả lập (dùng goroutine/thread), gây crash 1 node và quan sát re-election.
Advanced concepts
- So sánh Raft leader election với Tendermint round-robin proposer - Tendermint không cần "election" vì proposer được xác định trước theo thuật toán xoay vòng có trọng số.

Ngày 24: Viewstamped Replication & so sánh 3 giao thức

Khái niệm
- VR: giao thức cùng thời với Paxos, ít được biết tới hơn nhưng ảnh hưởng thiết kế "view change" mà nhiều BFT protocol sau này kế thừa (kể cả PBFT).
Thực hành và quan sát
- Lập bảng so sánh Paxos/Raft/VR: cơ chế leader, cách xử lý network partition, độ phức tạp message.
Advanced concepts
- "View change" trong VR chính là tiền thân khái niệm "round/view" trong Tendermint và HotStuff.

Ngày 25: Ôn tập consensus CFT + Bài test

Khái niệm
- Tổng hợp: quorum, Paxos, Raft, VR - tất cả đều giả định crash fault, KHÔNG chống được node ác ý gửi dữ liệu sai (Byzantine).
Thực hành và quan sát
- Bài test: cho 1 kịch bản có node Byzantine (gửi 2 giá trị khác nhau cho 2 node khác), chứng minh Raft/Paxos sẽ bị phá vỡ.
Advanced concepts
- Đây chính là lý do cần chuyển sang phần tiếp theo: Byzantine Fault Tolerance.

Tuần 6 (Ngày 26–30): Byzantine Fault Tolerance

Ngày 26: Byzantine Generals Problem

Khái niệm
- Bài toán gốc của Lamport/Shostak/Pease (1982): n=3f+1 là ngưỡng tối thiểu để chịu được f node Byzantine trong mô hình đồng bộ.
Thực hành và quan sát
- Chứng minh tay tại sao n=3f không đủ (dựng phản ví dụ với f=1, n=3).
Advanced concepts
- Ngưỡng khác nhau tùy mô hình mạng: đồng bộ cần n≥3f+1, bất đồng bộ (theo FLP) không thể đạt cả safety+liveness deterministic.

Ngày 27: PBFT (Practical Byzantine Fault Tolerance)

Khái niệm
- 3 phase: Pre-prepare, Prepare, Commit - vì sao cần 2 vòng bỏ phiếu (không phải 1) để đảm bảo an toàn khi có Byzantine node.
- Độ phức tạp message: O(n²) - lý do PBFT gốc không scale tốt với nhiều validator.
Thực hành và quan sát
- Implement giản lược PBFT 3-phase trên 4 node giả lập cục bộ (dùng thread/goroutine + channel), có 1 node cố tình gửi message sai để test.
Advanced concepts
- HotStuff - cải tiến PBFT xuống O(n) message bằng cách dùng threshold signature và pipeline hóa các phase (nền tảng của LibraBFT/DiemBFT, và ảnh hưởng tới nhiều BFT chain hiện đại).

Ngày 28: Tendermint BFT chi tiết

Khái niệm
- Kiến trúc: Propose → Prevote → Precommit, round-robin proposer có trọng số theo stake, lock mechanism chống double-vote.
- Instant finality: khác biệt so với PoW (finality xác suất).
Thực hành và quan sát
- Hoàn thiện bài "implement Tendermint-style BFT trên 4 node" (đã bắt đầu ở tuần trước nếu theo bản cũ) - thêm đầy đủ round, lock, timeout.
Advanced concepts
- Đọc paper gốc "The latest gossip on BFT consensus" (Buchman, Kwon, Milosevic) - so sánh với bản implement của bạn, tìm chỗ thiếu.

Ngày 29: Gasper (Ethereum consensus) chi tiết

Khái niệm
- Casper FFG (finality gadget) + LMD-GHOST (fork choice) kết hợp thành Gasper.
- Epoch, slot, attestation, checkpoint - vì sao finality mất 2 epoch (~12-15 phút), không tức thì như Tendermint.
Thực hành và quan sát
- Vẽ sơ đồ timeline 1 epoch Ethereum (32 slot), đánh dấu khi nào attestation được gửi, khi nào checkpoint finalize.
Advanced concepts
- Slashing conditions cụ thể: surround vote, double vote - viết pseudocode kiểm tra 2 điều kiện này.

Ngày 30: Nakamoto Consensus (PoW) dưới góc nhìn lý thuyết

Khái niệm
- PoW không phải BFT cổ điển - nó là "longest chain rule" dựa trên xác suất và chi phí kinh tế, chấp nhận fork tạm thời.
- Chứng minh trực giác: xác suất attacker vượt qua honest chain giảm theo hàm mũ theo số block confirmation (bài toán Gambler's Ruin).
Thực hành và quan sát
- Mô phỏng Monte Carlo: viết script tính xác suất 1 attacker có 30% hashpower thành công đảo ngược giao dịch sau k block confirmation, vẽ biểu đồ theo k.
Advanced concepts
- So sánh formal: PoW an toàn dưới giả định honest majority hashpower (>50%), Tendermint an toàn dưới giả định >2/3 voting power trung thực - khác nhau về ngưỡng và về loại "an toàn" (probabilistic vs absolute).

Tuần 7 (Ngày 31–35): Distributed storage & database internals

Ngày 31: LSM-Tree - nền tảng storage engine của mọi blockchain client

Khái niệm
- Log-Structured Merge Tree: memtable, SSTable, compaction - vì sao write-heavy workload (blockchain state) hợp với LSM hơn B-Tree.
Thực hành và quan sát
- Cài LevelDB hoặc RocksDB, viết script insert 1 triệu key/value, quan sát file SSTable sinh ra trên disk qua ls -la.
Advanced concepts
- Write amplification, read amplification, space amplification - 3 trade-off chính khi tune compaction strategy (leveled vs tiered).

Ngày 32: Write-Ahead Log & durability

Khái niệm
- WAL: đảm bảo durability trước khi ghi vào memtable - vì sao node có thể recover đúng trạng thái sau khi crash giữa chừng.
Thực hành và quan sát
- Test thực tế: insert dữ liệu vào RocksDB, kill process (kill -9) giữa chừng, khởi động lại và kiểm tra dữ liệu có được recover đúng không.
Advanced concepts
- fsync và group commit - trade-off giữa durability tuyệt đối và throughput ghi.

Ngày 33: Quorum-based replication & consistent hashing

Khái niệm
- Consistent hashing: cách phân phối dữ liệu qua nhiều node mà không cần rebalance toàn bộ khi thêm/bớt node.
Thực hành và quan sát
- Implement consistent hashing ring từ đầu, thêm/bớt node và đo % dữ liệu cần di chuyển.
Advanced concepts
- Virtual nodes - kỹ thuật giảm hotspot trong consistent hashing, dùng trong Cassandra/DynamoDB.

Ngày 34: State sync & snapshot

Khái niệm
- Full sync vs fast sync vs snap sync (Ethereum) - cách node mới đồng bộ mà không cần replay toàn bộ lịch sử từ genesis.
Thực hành và quan sát
- Đọc doc snap sync của Geth, vẽ sơ đồ luồng dữ liệu: state trie download → healing phase.
Advanced concepts
- Trade-off bảo mật: fast sync tin tưởng vào checkpoint thay vì verify toàn bộ lịch sử - mô hình "weak subjectivity" trong PoS.

Ngày 35: Ôn tập Phần 1 + Bài test tổng hợp Distributed Systems

Khái niệm
- Tổng hợp toàn bộ: FLP, CAP, Paxos/Raft, PBFT/Tendermint, Gasper, Nakamoto, LSM-tree.
Thực hành và quan sát
- Bài test viết luận ngắn (2-3 trang): "So sánh 4 cơ chế consensus đã học theo 4 tiêu chí: finality, throughput, ngưỡng chịu lỗi, mô hình mạng giả định" - không tra cứu, dùng kiến thức đã học.
Advanced concepts
- Chuẩn bị tinh thần: từ Phần 2 trở đi, mọi khái niệm consensus/crypto sẽ được liên hệ ngược lại phần Distributed Systems này liên tục.

PHẦN 2 - CRYPTOGRAPHY ỨNG DỤNG (Ngày 36–60)

Tuần 8 (Ngày 36–40): Hash function

Ngày 36: SHA-256 internals

Khái niệm
- Cấu trúc Merkle-Damgård, compression function, message schedule - cách SHA-256 xử lý block 512-bit.
Thực hành và quan sát
- Implement SHA-256 từ đầu (không dùng thư viện) bằng Rust/Python theo đúng spec FIPS 180-4, test với test vector chuẩn NIST.
Advanced concepts
- Length-extension attack - vì sao Merkle-Damgård dễ bị tấn công này và tại sao HMAC (không phải hash trần) được dùng để ký message.

Ngày 37: Keccak-256 & sự khác biệt với SHA-3 chuẩn

Khái niệm
- Sponge construction (khác Merkle-Damgård) - absorb/squeeze phase.
- Lưu ý quan trọng: Ethereum dùng Keccak-256 gốc (trước khi NIST chuẩn hóa SHA-3 với padding khác) - 2 hàm cho kết quả khác nhau dù cùng tên gọi phổ biến.
Thực hành và quan sát
- Tính hash "hello" bằng cả Keccak-256 và SHA3-256 chuẩn, so sánh kết quả khác nhau, giải thích tại sao (padding byte 0x01 vs 0x06).
Advanced concepts
- Sponge construction chống length-extension attack tự nhiên - không cần HMAC như SHA-256.

Ngày 38: Key Derivation Functions

Khái niệm
- PBKDF2, scrypt, Argon2 - vì sao cần "làm chậm cố ý" (memory-hard, iteration count) để chống brute-force offline.
Thực hành và quan sát
- Đo thời gian derive key bằng PBKDF2 với 1,000 vs 100,000 vs 600,000 iteration, quan sát trade-off UX vs bảo mật.
Advanced concepts
- Memory-hardness của scrypt/Argon2 chống lại ASIC/GPU cracking tốt hơn PBKDF2 (chỉ CPU-bound).

Ngày 39: HMAC & message authentication

Khái niệm
- HMAC construction: H(key ⊕ opad || H(key ⊕ ipad || message)) - vì sao cấu trúc này an toàn hơn H(key || message) đơn giản.
Thực hành và quan sát`
- Implement HMAC-SHA256 từ đầu, verify với test vector RFC 2104.
Advanced concepts
- HMAC dùng trong BIP-32 (HD wallet derivation) - chuẩn bị nền cho phần ví tuần sau.

Ngày 40: Merkle proof nâng cao & accumulator

Khái niệm
- Cryptographic accumulator - cấu trúc cho phép chứng minh membership mà không cần lưu toàn bộ set (RSA accumulator, Merkle accumulator).
Thực hành và quan sát
- So sánh kích thước proof giữa Merkle proof thường và 1 ví dụ RSA accumulator (đọc + tóm tắt, không cần implement đầy đủ RSA accumulator ở bước này).
Advanced concepts
- Utreexo - ứng dụng accumulator để giảm kích thước UTXO set cần lưu trữ trong Bitcoin full node (sẽ gặp lại ở Phần Bitcoin Internals).

Tuần 9 (Ngày 41–45): Elliptic Curve Cryptography

Ngày 41: Toán học đường cong elliptic

Khái niệm
- Phương trình Weierstrass y² = x³ + ax + b mod p, phép cộng điểm hình học, point at infinity.
Thực hành và quan sát
- Vẽ tay phép cộng 2 điểm trên 1 đường cong nhỏ (mod p với p nhỏ, VD p=17) để hiểu trực quan trước khi làm với secp256k1 thật.
Advanced concepts
- Đường cong Weierstrass vs Montgomery (Curve25519) vs Edwards (Ed25519) - lý do các dự án khác nhau chọn dạng đường cong khác nhau (tốc độ, chống side-channel).

Ngày 42: secp256k1 - đường cong của Bitcoin/Ethereum

Khái niệm
- Tham số cụ thể của secp256k1: prime p, generator point G, order n.
- Scalar multiplication: double-and-add algorithm.
Thực hành và quan sát
- Implement scalar multiplication (double-and-add) từ đầu trên secp256k1 dùng thư viện bignum (không dùng hàm EC có sẵn), tính public key từ 1 private key mẫu, so khớp với kết quả thư viện chuẩn.
Advanced concepts
- Timing attack lên scalar multiplication ngây thơ - vì sao production code cần constant-time implementation.

Ngày 43: ECDSA - ký và verify

Khái niệm
- Thuật toán ký: chọn nonce k, tính r, s; thuật toán verify dùng public key.
Thực hành và quan sát
- Implement ECDSA sign/verify từ đầu (dùng phép EC đã viết ngày 42), test round-trip sign→verify.
Advanced concepts
- Malleable signature: (r, s) và (r, -s mod n) đều valid - lý do Ethereum/Bitcoin phải chuẩn hóa "low-s" để chống transaction malleability.

Ngày 44: Tấn công nonce reuse - thực hành tấn công thật

Khái niệm
- Công thức khôi phục private key khi 2 chữ ký dùng chung nonce k: k = (h1-h2)/(s1-s2), sau đó suy ra private key.
Thực hành và quan sát
- Tự tạo 2 chữ ký cố ý dùng chung nonce, sau đó viết script khôi phục lại private key từ 2 chữ ký đó - tái hiện lỗi thực tế đã từng xảy ra (Sony PS3, một số ví Bitcoin/Android bug 2013).
Advanced concepts
- RFC 6979: deterministic nonce generation (derive k từ private key + message thay vì random) - cách phòng chống triệt để lỗi này.

Ngày 45: Schnorr signatures

Khái niệm
- Cấu trúc Schnorr đơn giản hơn ECDSA, và quan trọng nhất: linear - cho phép cộng dồn chữ ký (signature aggregation).
Thực hành và quan sát
- Implement Schnorr sign/verify từ đầu, so sánh độ phức tạp code với ECDSA đã viết.
Advanced concepts
- MuSig/MuSig2 - giao thức multisig dùng Schnorr aggregation, nền tảng của Bitcoin Taproot (sẽ học chi tiết ở Phần Bitcoin Internals).

Tuần 10 (Ngày 46–50): Ví, key management, và HD wallet

Ngày 46: Từ public key tới address

Khái niệm
- Ethereum: address = last 20 bytes of Keccak256(pubkey). Bitcoin: hash160 = RIPEMD160(SHA256(pubkey)) + Base58Check encoding.
Thực hành và quan sát
- Implement cả 2 cách derive address từ đầu, verify với address thật đã biết (từ 1 private key test cố định, KHÔNG dùng ví có tiền thật).
Advanced concepts
- Checksum trong Base58Check (4 byte đầu của double-SHA256) - vì sao giúp phát hiện lỗi gõ nhầm địa chỉ.

Ngày 47: BIP-39 - mnemonic seed phrase

Khái niệm
- Entropy → wordlist mapping → checksum - cách 12/24 từ mã hóa lại entropy gốc.
Thực hành và quan sát
- Implement BIP-39 từ đầu: sinh entropy ngẫu nhiên, tính checksum, map sang wordlist chuẩn, verify với test vector chính thức.
Advanced concepts
- Passphrase (từ thứ 25, "25th word") - tạo ra "hidden wallet", vì sao đây vừa là tính năng bảo mật vừa là rủi ro (mất passphrase = mất ví vĩnh viễn).

Ngày 48: BIP-32 - Hierarchical Deterministic wallet

Khái niệm
- Master key derivation từ seed (dùng HMAC-SHA512), child key derivation (hardened vs non-hardened).
- Lỗ hổng: non-hardened derivation - nếu lộ 1 child private key + parent public key có thể suy ngược ra parent private key.
Thực hành và quan sát
- Implement BIP-32 derivation từ đầu (dùng HMAC đã viết ngày 39), derive vài child key từ 1 master seed, so khớp kết quả với thư viện chuẩn.
Advanced concepts
- BIP-44 derivation path chuẩn (m/44'/60'/0'/0/0 cho Ethereum) - ý nghĩa từng cấp (purpose/coin_type/account/change/index).

Ngày 49: Multisig & Threshold Signature Schemes (TSS)

Khái niệm
- On-chain multisig (script/contract yêu cầu m-of-n chữ ký) vs off-chain TSS (dùng MPC để tạo 1 chữ ký duy nhất từ nhiều bên, không lộ bất kỳ share private key nào lên chain).
Thực hành và quan sát
- Đọc kiến trúc Gnosis Safe (on-chain multisig phổ biến nhất Ethereum) - vẽ sơ đồ luồng: propose → collect signature → execute.
Advanced concepts
- So sánh chi phí gas: on-chain multisig tốn gas cho mọi lần verify m chữ ký, TSS chỉ tốn gas như 1 chữ ký thường (vì đã gộp off-chain) - lý do các custodian lớn (Fireblocks) chọn MPC/TSS.

Ngày 50: Ôn tập Phần Cryptography ứng dụng + Bài test

Khái niệm
- Tổng hợp: hash, HMAC, EC, ECDSA/Schnorr, BIP-32/39/44, multisig/TSS.
Thực hành và quan sát
- Bài test tổng hợp: từ 1 mnemonic tự sinh → derive master key → derive 5 địa chỉ Ethereum → ký 1 message giả lập bằng private key đầu tiên → verify chữ ký - toàn bộ pipeline tự viết, không dùng thư viện wallet có sẵn.
Advanced concepts
- Review code, tìm chỗ không constant-time (dễ lộ qua timing attack) - ghi chú lại dù chưa cần fix ngay ở giai đoạn học.

Tuần 11 (Ngày 51–55): Symmetric crypto & bảo mật ứng dụng

Ngày 51: AES & symmetric encryption

Khái niệm
- AES block cipher, mode of operation: ECB (không an toàn - vì sao), CBC, CTR, GCM (authenticated encryption).
Thực hành và quan sát
- Mã hóa cùng 1 ảnh bitmap đơn giản bằng AES-ECB, quan sát pattern vẫn lộ ra trong ảnh mã hóa (minh chứng kinh điển ECB không an toàn) - dùng thư viện AES có sẵn, chỉ tự chọn mode.
Advanced concepts
- AES-GCM - vì sao được ưu tiên trong production (vừa mã hóa vừa xác thực, chống tamper).

Ngày 52: Keystore file & mã hóa private key khi lưu trữ

Khái niệm
- Cấu trúc file keystore chuẩn Ethereum (UTC--...json): KDF params + cipher params + MAC - cách bảo vệ private key bằng password.
Thực hành và quan sát
- Implement encrypt/decrypt keystore file từ đầu theo đúng chuẩn Ethereum keystore, verify có thể mở lại bằng geth thật.
Advanced concepts
- Vì sao dùng scrypt (không phải PBKDF2 thường) làm KDF mặc định trong Ethereum keystore - memory-hardness chống GPU cracking.

Ngày 53: TLS/Noise Protocol cho giao tiếp P2P

Khái niệm
- TLS handshake tóm tắt, và Noise Protocol Framework (dùng trong libp2p) - lightweight hơn TLS cho P2P.
Thực hành và quan sát
- Setup 1 kết nối TLS đơn giản giữa 2 process (dùng thư viện chuẩn), quan sát certificate exchange qua Wireshark.
Advanced concepts
- Noise_XX pattern - mutual authentication không cần PKI/CA (phù hợp mạng P2P phi tập trung, không có "authority" trung tâm cấp chứng chỉ).

Ngày 54: Secure random number generation

Khái niệm
- CSPRNG (Cryptographically Secure PRNG) vs PRNG thường - tại sao Math.random() KHÔNG BAO GIỜ được dùng để sinh private key.
Thực hành và quan sát
- So sánh output của PRNG thường vs CSPRNG (crypto.randomBytes trong Node, OsRng trong Rust) qua test thống kê đơn giản (không cần NIST full suite, chỉ cần hiểu khái niệm).
Advanced concepts
- Case study thực tế: lỗ hổng Android SecureRandom 2013 khiến nhiều ví Bitcoin bị mất tiền do entropy yếu - liên hệ ngược lại bài nonce reuse ngày 44.

Ngày 55: Ôn tập + bài test bảo mật ứng dụng

Khái niệm
- Tổng hợp AES, keystore, TLS/Noise, CSPRNG.
Thực hành và quan sát
- Bài test: thiết kế (viết pseudocode + giải thích, không cần code đầy đủ) 1 hệ thống lưu trữ private key cho ứng dụng ví mobile, liệt kê rõ: KDF nào, cipher mode nào, nguồn entropy nào, và lý do chọn.
Advanced concepts
- So sánh thiết kế của bạn với secure enclave (iOS Keychain/Android Keystore hardware-backed) - sẽ học sâu hơn ở Phần Production Security.

Tuần 12 (Ngày 56–60): Nhập môn Zero-Knowledge (phần cơ bản; phần nâng cao ở Phần 5)

Ngày 56: Trực giác Zero-Knowledge Proof

Khái niệm
- 3 thuộc tính: completeness, soundness, zero-knowledge. Ví dụ kinh điển "hang động Ali Baba" để hiểu trực giác trước khi vào toán.
Thực hành và quan sát
- Viết lại ví dụ hang động bằng ngôn ngữ của riêng bạn, chỉ rõ đâu là completeness, đâu là soundness, đâu là zero-knowledge trong ví dụ đó.
Advanced concepts
- Interactive vs non-interactive proof - vì sao blockchain cần non-interactive (verifier không thể "chat qua lại" với prover on-chain).

Ngày 57: Sigma protocol & Fiat-Shamir transform

Khái niệm
- Sigma protocol: commit → challenge → response (3 bước). Fiat-Shamir: thay challenge ngẫu nhiên của verifier bằng hash (biến interactive thành non-interactive).
Thực hành và quan sát
- Implement 1 sigma protocol đơn giản nhất: chứng minh biết discrete log (Schnorr identification protocol) - chính là "nửa non-signing" của Schnorr signature đã học ngày 45.
Advanced concepts
- Random Oracle Model - giả định lý thuyết cần thiết để Fiat-Shamir an toàn (hash function coi như hộp đen ngẫu nhiên hoàn hảo).

Ngày 58: Giới thiệu SNARK/STARK ở mức khái niệm

Khái niệm
- Arithmetic circuit - cách biểu diễn 1 bài toán tính toán thành các ràng buộc đại số (constraint system).
- Trade-off SNARK (proof nhỏ, cần trusted setup) vs STARK (proof lớn hơn, không cần trusted setup, chống lượng tử tốt hơn).
Thực hành và quan sát
- Biểu diễn tay bài toán "x² = 9" thành 1 constraint đơn giản (R1CS dạng cơ bản: a*b=c).
Advanced concepts
- Trusted setup ceremony (Powers of Tau) - tại sao cần multi-party computation để không ai biết "toxic waste" (tham số bí mật có thể dùng để giả mạo proof).

Ngày 59: Circom & viết circuit đầu tiên

Khái niệm
- Circom DSL: signal, constraint, template - cách viết circuit khai báo thay vì lập trình mệnh lệnh thông thường.
Thực hành và quan sát
- Cài Circom + snarkjs, viết circuit chứng minh biết x sao cho x*x == y (không tiết lộ x), generate proof, verify off-chain.
Advanced concepts
- Witness generation - bước tính toán trung gian trước khi tạo proof thật, thường là bottleneck hiệu năng lớn nhất trong ứng dụng ZK thực tế.

Ngày 60: Verify proof on-chain + Ôn tập Phần 2

Khái niệm
- Verifier contract sinh tự động bởi snarkjs - cấu trúc cơ bản của 1 Solidity verifier cho Groth16.
Thực hành và quan sát
- Deploy verifier contract sinh từ circuit ngày 59 lên testnet, gọi verify proof on-chain, đo gas cost thực tế.
Advanced concepts
- Ghi chú chuyển tiếp: phần ZK nâng cao (PLONK, KZG commitment, Verkle Tree, BLS aggregation dùng trong Ethereum consensus) sẽ học sâu ở Phần 5, sau khi đã hiểu Bitcoin/Ethereum internals cụ thể.

PHẦN 3 - BITCOIN INTERNALS (Ngày 61–80)

Tuần 13 (Ngày 61–65): UTXO model & transaction

Ngày 61: UTXO model vs Account model

Khái niệm
- UTXO (Unspent Transaction Output): mỗi giao dịch tiêu thụ UTXO cũ, tạo UTXO mới - không có khái niệm "balance" lưu trữ trực tiếp, balance là tổng UTXO chưa tiêu.
- So sánh song song với Account model (Ethereum) đã biết sơ bộ: ưu điểm UTXO (privacy tốt hơn, parallelizable, không cần nonce) vs nhược điểm (khó xử lý state phức tạp, smart contract giới hạn).
Thực hành và quan sát
- Vẽ tay 3 giao dịch liên tiếp minh họa UTXO được tạo/tiêu như thế nào, tính balance cuối cùng bằng cách cộng UTXO chưa tiêu.
Advanced concepts
- Coin selection algorithm - cách ví Bitcoin chọn UTXO nào để chi tiêu khi có nhiều UTXO nhỏ lẻ (ảnh hưởng phí giao dịch và privacy).

Ngày 62: Cấu trúc transaction Bitcoin

Khái niệm
- Transaction fields: version, input (txid + vout + scriptSig), output (value + scriptPubKey), locktime.
Thực hành và quan sát
- Dùng bitcoin-cli (regtest mode, không cần mainnet) hoặc thư viện Python (python-bitcoinlib) decode 1 raw transaction thật, xác định từng field.
Advanced concepts
- RBF (Replace-By-Fee) và locktime - cơ chế cho phép thay thế giao dịch chưa confirm bằng phí cao hơn.

Ngày 63: Bitcoin Script - VM không Turing-complete

Khái niệm
- Stack-based scripting language, cố ý KHÔNG Turing-complete (không có loop) - lý do thiết kế: tránh halting problem, dễ phân tích an toàn.
- Opcode phổ biến: OP_DUP, OP_HASH160, OP_EQUALVERIFY, OP_CHECKSIG.
Thực hành và quan sát
- Trace tay P2PKH script (Pay-to-Public-Key-Hash) execution từng bước trên stack, từ scriptSig + scriptPubKey tới kết quả TRUE/FALSE.
Advanced concepts
- OP_RETURN - cách ghi dữ liệu tùy ý (limited) lên Bitcoin blockchain, nền tảng ban đầu của các giao thức layer trên như Omni/Counterparty.

Ngày 64: Implement mini Script interpreter

Khái niệm
- Cấu trúc interpreter: đọc script byte-by-byte, push/pop stack theo từng opcode.
Thực hành và quan sát
- Implement từ đầu 1 interpreter hỗ trợ ~10 opcode cơ bản (OP_DUP, OP_HASH160, OP_EQUAL, OP_EQUALVERIFY, OP_CHECKSIG giả lập, OP_ADD...), test với P2PKH script thật.
Advanced concepts
- Sự khác biệt giữa Bitcoin Script (không loop, giới hạn cứng) và EVM (Turing-complete, giới hạn bằng gas) - sẽ học kỹ ở Phần 4, ghi chú lại so sánh ngay từ bây giờ.

Ngày 65: Multisig script & P2SH

Khái niệm
- OP_CHECKMULTISIG, Pay-to-Script-Hash (P2SH) - cách "giấu" script phức tạp sau 1 hash để giảm dữ liệu on-chain cho tới khi spend.
Thực hành và quan sát
- Tạo 1 địa chỉ 2-of-3 multisig bằng bitcoin-cli trên regtest, thực hiện giao dịch chi tiêu cần 2 chữ ký.
Advanced concepts
- P2WSH (SegWit version của P2SH) - sự khác biệt về cách witness data được tách khỏi transaction chính.

Tuần 14 (Ngày 66–70): SegWit, Taproot, Schnorr trong Bitcoin

Ngày 66: Transaction malleability & động lực cho SegWit

Khái niệm
- Vấn đề malleability: txid có thể bị thay đổi mà không làm invalid transaction (do ECDSA signature malleability đã học ngày 43) - gây rắc rối cho các giao thức layer 2 dựa vào txid (như Lightning Network).
Thực hành và quan sát
- Minh họa lại bằng tay: từ 1 chữ ký (r,s) hợp lệ, tạo chữ ký (r, n-s) cũng hợp lệ, dẫn tới txid khác nhưng transaction vẫn valid.
Advanced concepts
- Đây chính là lý do BIP-62/BIP-66 rồi cuối cùng SegWit (BIP-141) ra đời để giải quyết tận gốc.

Ngày 67: SegWit chi tiết

Khái niệm
- Tách witness data (chữ ký) ra khỏi phần tính txid - witness discount (giảm "trọng số" tính phí cho phần witness) để khuyến khích áp dụng.
- Block weight vs block size: weight = base_size*3 + total_size.
Thực hành và quan sát
- Decode 1 SegWit transaction thật, xác định rõ phần nào thuộc "base" và phần nào thuộc "witness".
Advanced concepts
- Soft fork vs hard fork - vì sao SegWit implement được như soft fork (backward compatible) nhờ dùng "anyone-can-spend" output pattern khéo léo.

Ngày 68: Taproot & Schnorr trong Bitcoin (BIP-340/341/342)

Khái niệm
- Chuyển từ ECDSA sang Schnorr (đã học nền tảng ngày 45) - cho phép signature aggregation, giúp multisig trông giống single-sig on-chain (tăng privacy).
- MAST (Merkelized Alternative Script Trees) - chỉ tiết lộ nhánh script được thực thi, giấu các nhánh khác.
Thực hành và quan sát
- Tạo 1 địa chỉ Taproot bằng bitcoin-cli trên regtest (hoặc testnet), so sánh cấu trúc với địa chỉ SegWit thường.
Advanced concepts
- Key-path spend vs script-path spend trong Taproot - cách thiết kế để trường hợp phổ biến nhất (single-sig hoặc multisig hợp tác) trông giống hệt nhau on-chain, tăng privacy toàn mạng.

Ngày 69: Mempool policy & fee market Bitcoin

Khái niệm
- Fee rate (sat/vByte), mempool ordering theo fee, CPFP (Child Pays For Parent) - chiến lược đẩy nhanh giao dịch bị kẹt.
Thực hành và quan sát
- Setup regtest với nhiều transaction fee khác nhau, quan sát thứ tự chọn vào block khi mine.
Advanced concepts
- Package relay (cải tiến gần đây của Bitcoin Core) - cho phép mempool đánh giá theo "gói" giao dịch liên quan thay vì từng cái riêng lẻ.

Ngày 70: Ôn tập tuần 13-14 + Bài test

Khái niệm
- Tổng hợp: UTXO, Script, SegWit, Taproot.
Thực hành và quan sát
- Bài test: trên regtest, thực hiện toàn bộ luồng - tạo ví, tạo địa chỉ P2WPKH và Taproot, gửi giao dịch giữa 2 loại địa chỉ, giải thích sự khác biệt cấu trúc.
Advanced concepts
- Ghi chú so sánh: Taproot + Schnorr aggregation là bước đệm tư duy cho BLS aggregation trong Ethereum consensus (Phần 5).

Tuần 15 (Ngày 71–75): Bitcoin Core source code reading

Ngày 71: Setup môi trường đọc Bitcoin Core

Khái niệm
- Kiến trúc tổng quan repo bitcoin/bitcoin: thư mục src/ chính - validation.cpp, script/, net.cpp, txmempool.cpp.
Thực hành và quan sát
- Clone repo, build từ source (hoặc dùng docker build có sẵn), chạy bitcoind -regtest, kết nối bằng bitcoin-cli.
Advanced concepts
- Đọc CONTRIBUTING.md và coding style guide - hiểu convention trước khi đọc sâu code.

Ngày 72: Trace transaction validation

Khái niệm
- Luồng: AcceptToMemoryPool → script verification → UTXO set check.
Thực hành và quan sát
- Đọc validation.cpp, hàm CheckTransaction và AcceptToMemoryPool, đánh dấu từng bước validate (kích thước, double-spend, script).
Advanced concepts
- libconsensus - phần code được tách riêng để đảm bảo mọi implementation (kể cả bên thứ 3) validate giống hệt Bitcoin Core, tránh consensus fork ngoài ý muốn.

Ngày 73: Trace block validation & UTXO set update

Khái niệm
- ConnectBlock - cách 1 block mới được áp dụng vào UTXO set (chain state).
Thực hành và quan sát
- Đọc code ConnectBlock trong validation.cpp, vẽ sơ đồ các bước kiểm tra (PoW, timestamp, coinbase maturity, script...).
Advanced concepts
- chainstate database (dùng LevelDB, liên hệ ngược Phần 1 ngày 31) - cách UTXO set được lưu và cache trong memory (CCoinsViewCache).

Ngày 74: Mempool internals

Khái niệm
- txmempool.cpp: cấu trúc dữ liệu mempool, ancestor/descendant tracking, eviction policy khi mempool đầy.
Thực hành và quan sát
- Đọc CTxMemPool class, xác định cách tính "mempool ancestor fee" dùng để sắp xếp thứ tự ưu tiên.
Advanced concepts
- RBF implementation cụ thể trong code - so với lý thuyết đã học ngày 62.

Ngày 75: P2P networking trong Bitcoin Core

Khái niệm
- net.cpp, net_processing.cpp - message type (inv, getdata, tx, block), peer management.
Thực hành và quan sát
- Chạy 2 node bitcoind regtest kết nối với nhau, dùng -debug=net xem log message trao đổi thực tế.
Advanced concepts
- Eclipse attack - cách attacker cô lập 1 node bằng cách chiếm toàn bộ outbound connection của nó, và các biện pháp phòng chống đã implement trong Bitcoin Core (outbound connection diversity).

Tuần 16 (Ngày 76–80): Lightning Network & tổng kết Bitcoin

Ngày 76: Payment channel - nguyên lý cơ bản

Khái niệm
- 2-of-2 multisig funding transaction, commitment transaction, cách cập nhật balance off-chain mà không cần broadcast mỗi lần.
Thực hành và quan sát
- Vẽ tay luồng: mở channel → 3 lần cập nhật balance off-chain → đóng channel - chỉ 2 giao dịch on-chain (open + close) cho toàn bộ quá trình.
Advanced concepts
- Revocation key - cơ chế phạt nếu 1 bên cố tình broadcast commitment transaction cũ (đã bị revoke) để gian lận.

Ngày 77: HTLC & routing đa chặng

Khái niệm
- Hashed Timelock Contract (HTLC) - cho phép định tuyến thanh toán qua nhiều channel trung gian mà không cần tin tưởng node trung gian.
Thực hành và quan sát
- Vẽ sơ đồ 1 thanh toán qua 3 node trung gian, minh họa cách HTLC đảm bảo atomic (hoặc tất cả đều nhận tiền, hoặc không ai nhận).
Advanced concepts
- Onion routing trong Lightning (tương tự Tor) - cách mỗi node trung gian chỉ biết node liền kề, không biết toàn bộ route.

Ngày 78: Thực hành Lightning Network trên regtest/testnet

Khái niệm
- lnd hoặc core-lightning - cách setup node Lightning kết nối với bitcoind regtest.
Thực hành và quan sát
- Cài lnd, mở 1 channel trên regtest giữa 2 node Lightning tự chạy, thực hiện 1 thanh toán off-chain, đóng channel.
Advanced concepts
- Watchtower - dịch vụ giám sát hộ để phát hiện đối tác gian lận (broadcast commitment cũ) khi bạn offline.

Ngày 79: So sánh Bitcoin vs Ethereum - tổng kết có căn cứ

Khái niệm
- Tổng hợp lại toàn bộ Phần 3 để so sánh CÓ CĂN CỨ (không chỉ liệt kê bề mặt): UTXO vs Account, Script vs EVM, PoW thuần vs PoS, fee market, layer 2 approach (Lightning channel-based vs Rollup execution-based).
Thực hành và quan sát
- Viết bảng so sánh chi tiết 8-10 tiêu chí, mỗi tiêu chí có ví dụ code/lệnh cụ thể đã thực hành trong 3 tuần qua làm minh chứng.
Advanced concepts
- Utreexo (nhắc lại từ ngày 40) - hướng nghiên cứu giảm kích thước UTXO set Bitcoin cần lưu bằng accumulator, đọc BIP liên quan.

Ngày 80: Bài test tổng hợp Phần 3

Khái niệm
- Ôn tập toàn diện Bitcoin Internals.
Thực hành và quan sát
- Bài test thực hành: trên regtest, tạo toàn bộ luồng end-to-end - ví HD (dùng code đã viết ở Phần 2) → tạo địa chỉ Taproot → nhận UTXO → tạo giao dịch multisig chi tiêu → mở 1 Lightning channel - ghép nối tất cả kiến thức đã học thành 1 pipeline hoàn chỉnh.
Advanced concepts
- Chuẩn bị chuyển sang Phần 4 (Ethereum & EVM) với tư duy so sánh liên tục thay vì học độc lập.

PHẦN 4 - ETHEREUM & EVM INTERNALS (Ngày 81–115)

Tuần 17 (Ngày 81–85): Account model & transaction lifecycle

Ngày 81: Account model chi tiết

Khái niệm
- 2 loại account: EOA (Externally Owned Account) và Contract Account - cấu trúc mỗi account: nonce, balance, storageRoot, codeHash.
Thực hành và quan sát
- Dùng eth_getTransactionCount và eth_getBalance qua JSON-RPC (kết nối node testnet công khai hoặc node tự chạy) lấy thông tin 1 địa chỉ thật, đối chiếu với cấu trúc lý thuyết.
Advanced concepts
- Nonce - vì sao bắt buộc tuần tự (chống replay + double-spend trong account model, khác cơ chế UTXO của Bitcoin).

Ngày 82: Cấu trúc transaction Ethereum & transaction types

Khái niệm
- Legacy transaction vs EIP-1559 transaction (type 2: baseFee + priorityFee) vs EIP-2930 (access list) vs EIP-4844 (blob transaction).
Thực hành và quan sát
- Decode 1 transaction EIP-1559 thật (qua eth_getTransactionByHash), xác định từng field, tính actual gas price trả (baseFee + min(maxPriorityFee, maxFee-baseFee)).
Advanced concepts
- Cơ chế điều chỉnh baseFee tự động theo độ đầy block (EIP-1559) - công thức tăng/giảm tối đa 12.5%/block.

Ngày 83: Block structure Ethereum

Khái niệm
- Block header fields: parentHash, stateRoot, transactionsRoot, receiptsRoot, gasUsed, gasLimit, baseFeePerGas...
Thực hành và quan sát
- Lấy 1 block header thật qua RPC, xác định từng field, verify transactionsRoot bằng cách tự build Merkle Patricia Trie từ danh sách transaction (dùng code MPT đã hiểu ở Phần 0, thực hành implement đầy đủ ở đây).
Advanced concepts
- 3 trie riêng biệt trong mỗi block: state trie, transaction trie, receipt trie - vì sao tách riêng thay vì gộp chung 1 trie.

Ngày 84: Gas mechanism sâu

Khái niệm
- Gas cost table chi tiết: tại sao SSTORE (thay đổi storage) đắt hơn nhiều so với ADD; khái niệm gas refund (SSTORE về 0), EIP-2929 (cold/warm access).
Thực hành và quan sát
- Viết 1 contract test đơn giản với vài opcode khác nhau, dùng eth_estimateGas đo gas thực tế, đối chiếu với bảng gas cost chính thức.
Advanced concepts
- EIP-1559 base fee bị "đốt" (burn) - tác động kinh tế lên tổng cung ETH, liên hệ tới phần Tokenomics sẽ học ở Phần 7.

Ngày 85: Receipt & event log

Khái niệm
- Transaction receipt: status, gasUsed, logs, logsBloom - cách event được emit và index qua topic.
Thực hành và quan sát
- Lấy receipt thật qua eth_getTransactionReceipt, decode log bằng ABI, kiểm tra logsBloom bằng thuật toán Bloom filter đã tự implement ở Phần 0 ngày 9.
Advanced concepts
- eth_getLogs performance - vì sao filter theo block range rộng có thể rất chậm nếu node không có index tốt (liên hệ trực tiếp tới nhu cầu dùng indexer riêng, sẽ học ở Phần 11).

Tuần 18 (Ngày 86–90): EVM Bytecode & interpreter

Ngày 86: EVM là gì - stack machine

Khái niệm
- Stack-based VM (khác register-based như x86): 1024 slot stack, mỗi slot 256-bit - tại sao chọn 256-bit (khớp kích thước hash Keccak/số nguyên lớn cho crypto).
Thực hành và quan sát
- Disassemble bytecode của 1 contract đơn giản (dùng evm disasm từ go-ethereum hoặc công cụ tương đương) thành danh sách opcode, đọc thủ công từng dòng.
Advanced concepts
- 3 vùng bộ nhớ của EVM: stack (tạm, 1024 slot), memory (tạm, byte-addressable, mở rộng tuyến tính theo gas), storage (bền vững, key-value 256-bit, cực đắt).

Ngày 87: Implement mini EVM interpreter - phần 1 (arithmetic + stack)

Khái niệm
- Cấu trúc interpreter: fetch-decode-execute loop, program counter (PC), xử lý PUSH/POP/DUP/SWAP.
Thực hành và quan sát
- Bắt đầu implement EVM interpreter từ đầu (Rust/Go): hỗ trợ PUSH1-PUSH32, POP, ADD, SUB, MUL, DIV, stack overflow/underflow check.
Advanced concepts
- Xử lý overflow của số 256-bit - vì sao cần thư viện U256 riêng (không dùng số nguyên native của ngôn ngữ).

Ngày 88: Implement mini EVM - phần 2 (control flow + memory)

Khái niệm
- JUMP/JUMPI/JUMPDEST - cách EVM đảm bảo chỉ nhảy tới vị trí hợp lệ (chống nhảy vào giữa 1 lệnh PUSH multi-byte).
- MLOAD/MSTORE - cách memory mở rộng động và tính gas cho việc mở rộng.
Thực hành và quan sát
- Mở rộng interpreter: thêm JUMP, JUMPI, JUMPDEST, MLOAD, MSTORE, gas metering cho memory expansion (công thức memory_cost = 3*words + words²/512).
Advanced concepts
- Vì sao chi phí memory tăng theo bậc 2 (quadratic) - cơ chế chống tấn công DoS bằng cách cấp phát memory khổng lồ.

Ngày 89: Implement mini EVM - phần 3 (storage + call)

Khái niệm
- SLOAD/SSTORE với gas cost động (cold/warm, EIP-2929), CALL/DELEGATECALL/STATICCALL semantics khác nhau (context, msg.sender, storage nào được dùng).
Thực hành và quan sát
- Hoàn thiện interpreter: thêm SLOAD, SSTORE (dùng HashMap giả lập storage), CALL cơ bản giữa 2 "contract" giả lập trong cùng chương trình test.
Advanced concepts
- DELEGATECALL - cơ chế chính xác (giữ nguyên msg.sender, msg.value, và storage context của caller) - nền tảng bắt buộc phải hiểu trước khi học proxy pattern ở Phần 6.

Ngày 90: Test EVM interpreter với bytecode thật + Ôn tập

Khái niệm
- So sánh output interpreter tự viết với kết quả thực thi thật trên EVM chuẩn (dùng evm run từ go-ethereum làm oracle để so sánh).
Thực hành và quan sát
- Test interpreter tự viết với 3-5 bytecode contract đơn giản thật (compile từ Solidity ra bytecode), so sánh kết quả execution và gas used với evm run.
Advanced concepts
- Ghi nhận các opcode chưa implement (danh sách ~140 opcode chuẩn), lên kế hoạch mở rộng dần trong các phần sau nếu muốn (không bắt buộc phải implement đủ 100%, mục tiêu là hiểu cơ chế).

Tuần 19 (Ngày 91–95): Consensus layer Ethereum

Ngày 91: The Merge - kiến trúc 2 client

Khái niệm
- Execution client (xử lý transaction, EVM, state) vs Consensus client (chạy Gasper, xử lý attestation) - Engine API kết nối 2 bên.
Thực hành và quan sát
- Vẽ sơ đồ kiến trúc 2-client, đánh dấu luồng dữ liệu qua Engine API (engine_newPayloadV3, engine_forkchoiceUpdatedV3).
Advanced concepts
- Tại sao tách 2 client là quyết định kiến trúc quan trọng (client diversity - giảm rủi ro nếu 1 client có bug nghiêm trọng).

Ngày 92: Validator lifecycle

Khái niệm
- Deposit 32 ETH → activation queue → active → (voluntary exit hoặc slashing) → withdrawal.
Thực hành và quan sát
- Đọc deposit contract (DepositContract.sol - contract thật, đơn giản, đáng đọc kỹ toàn bộ) trên Etherscan, xác định logic verify deposit data.
Advanced concepts
- Activation/exit queue rate limit - cơ chế chống 1 lượng lớn validator join/leave đột ngột gây bất ổn mạng.

Ngày 93: Attestation & committee

Khái niệm
- Mỗi epoch (32 slot) validator được chia vào committee, mỗi slot có 1 proposer + nhiều attester bỏ phiếu cho block head và checkpoint.
Thực hành và quan sát
- Dùng beacon chain API công khai (/eth/v1/beacon/...) lấy dữ liệu attestation thật của 1 epoch, đếm số validator tham gia.
Advanced concepts
- RANDAO - cơ chế sinh randomness on-chain để chọn proposer/committee, và "RANDAO biasability" (validator cuối cùng reveal có thể thao túng nhẹ, giới hạn bởi thiết kế).

Ngày 94: Slashing conditions chi tiết

Khái niệm
- Double vote (2 attestation khác nhau cùng target epoch) và surround vote (1 attestation "bao trùm" attestation khác) - cả 2 đều vi phạm an toàn Casper FFG.
Thực hành và quan sát
- Viết pseudocode kiểm tra 2 điều kiện slashing từ 2 attestation giả lập cho trước, xác định có vi phạm hay không.
Advanced concepts
- Slashing protection database - vì sao validator client bắt buộc lưu lịch sử attestation đã ký (kể cả sau khi restart) để tự bảo vệ khỏi vô tình double-sign.

Ngày 95: Fork choice rule (LMD-GHOST) + Ôn tập

Khái niệm
- LMD-GHOST: chọn nhánh có "latest message driven, greatest weight" - cách kết hợp với Casper FFG để tạo thành Gasper hoàn chỉnh.
Thực hành và quan sát
- Mô phỏng tay 1 kịch bản fork nhỏ (3 nhánh) với voting weight khác nhau, áp dụng LMD-GHOST xác định nhánh nào được chọn.
Advanced concepts
- Reorg trong PoS Ethereum - hiếm nhưng vẫn có thể xảy ra (proposer boost mechanism được thêm vào để giảm thiểu).

Tuần 20 (Ngày 96–100): MEV, mempool, và PBS

Ngày 96: Mempool Ethereum & transaction propagation

Khái niệm
- Gossip transaction qua devp2p, private mempool (Flashbots Protect) vs public mempool.
Thực hành và quan sát
- Kết nối tới 1 node qua WebSocket, subscribe pendingTransactions, log lại vài giao dịch pending thực tế, quan sát gas price distribution.
Advanced concepts
- "Dark forest" - thuật ngữ mô tả mempool công khai như môi trường đầy bot săn MEV, lý do nhiều giao dịch nhạy cảm chuyển sang private mempool.

Ngày 97: MEV - phân loại cụ thể

Khái niệm
- Front-running, back-running, sandwich attack, liquidation MEV, arbitrage MEV - cơ chế từng loại.
Thực hành và quan sát
- Phân tích 1 giao dịch sandwich attack thật (tìm qua block explorer/MEV explorer như EigenPhi hoặc Etherscan), xác định 3 giao dịch trong sandwich (front-tx, victim-tx, back-tx) và lợi nhuận attacker.
Advanced concepts
- JIT (Just-In-Time) liquidity - dạng MEV nâng cao trong AMM concentrated liquidity (sẽ hiểu rõ hơn sau khi học Uniswap V3 ở Phần 7).

Ngày 98: PBS - Proposer-Builder Separation

Khái niệm
- Tách vai trò builder (đóng gói block tối ưu MEV) khỏi proposer (validator chỉ chọn block trả phí cao nhất) - giảm quyền lực tập trung vào validator.
Thực hành và quan sát
- Đọc kiến trúc MEV-Boost (middleware phổ biến nhất implement PBS), vẽ sơ đồ luồng: builder → relay → proposer.
Advanced concepts
- Relay là điểm tin cậy trung gian hiện tại - vấn đề centralization risk, và hướng đi ePBS (enshrined PBS) đưa cơ chế này vào protocol layer thay vì middleware.

Ngày 99: Flashbots & bundle

Khái niệm
- Bundle: nhóm giao dịch được gửi atomic (tất cả thành công hoặc không giao dịch nào được đưa vào) tới builder, tránh lộ ra public mempool.
Thực hành và quan sát
- Đọc docs Flashbots, viết pseudocode 1 bundle đơn giản gồm 2 giao dịch (VD: approve + swap) gộp atomic.
Advanced concepts
- MEV-Share - cơ chế chia sẻ lại 1 phần MEV cho user gốc thay vì để toàn bộ rơi vào tay searcher/builder.

Ngày 100: Ôn tập Tuần 19-20 + Bài test

Khái niệm
- Tổng hợp: consensus layer, validator lifecycle, MEV, PBS.
Thực hành và quan sát
- Bài test: viết luận ngắn giải thích toàn bộ luồng 1 block Ethereum PoS từ lúc transaction được gửi tới lúc finalize - bao gồm cả builder/relay/proposer nếu áp dụng MEV-Boost.
Advanced concepts
- Chuẩn bị chuyển sang Layer 2 - vì sao các vấn đề MEV/gas cost đã học là động lực chính thúc đẩy scaling.

Tuần 21 (Ngày 101–105): Layer 2 - Rollups

Ngày 101: Rollup - nguyên lý chung

Khái niệm
- Execute off-chain, post data + proof (hoặc chỉ data) on-chain - data availability là yếu tố quyết định bảo mật của rollup.
Thực hành và quan sát
- Vẽ sơ đồ luồng chung: user tx → sequencer → batch → post to L1 → (optional) proof verify.
Advanced concepts
- "Rollup" chỉ thực sự an toàn nếu data được post đầy đủ lên L1 (hoặc DA layer đáng tin) - phân biệt rollup thật với "validium" (off-chain data, đánh đổi bảo mật lấy chi phí thấp).

Ngày 102: Optimistic Rollup chi tiết

Khái niệm
- Fraud proof, challenge period (thường 7 ngày), assumption "honest minority" (chỉ cần 1 người trung thực theo dõi và challenge).
Thực hành và quan sát
- Đọc tài liệu kiến trúc Optimism/Arbitrum, vẽ sơ đồ luồng withdraw từ L2 về L1 và giải thích vì sao mất 7 ngày.
Advanced concepts
- Fast withdrawal bridge (bên thứ 3 ứng trước thanh khoản) - cách UX thực tế "lách" challenge period mà không ảnh hưởng bảo mật gốc.

Ngày 103: ZK Rollup chi tiết

Khái niệm
- Validity proof - verify on-chain ngay lập tức (không cần challenge period), nhưng chi phí tạo proof (proving cost) cao hơn.
Thực hành và quan sát
- So sánh cụ thể zkSync/Starknet/Polygon zkEVM: loại proof dùng (SNARK/STARK), có phải "full EVM equivalent" hay không.
Advanced concepts
- zkEVM types (Vitalik phân loại Type 1-4) - trade-off giữa tương thích EVM hoàn toàn (Type 1, chậm hơn) và tối ưu riêng cho ZK (Type 4, nhanh hơn nhưng không tương thích bytecode EVM gốc).

Ngày 104: Data Availability

Khái niệm
- EIP-4844 (proto-danksharding): blob transaction - dữ liệu tạm thời (không lưu vĩnh viễn trong state) giúp giảm phí rollup đáng kể.
- DA sampling - cách light node verify data available mà không cần tải toàn bộ (dùng erasure coding).
Thực hành và quan sát
- Tìm 1 blob transaction thật trên block explorer hỗ trợ EIP-4844, so sánh phí với calldata truyền thống trước đó.
Advanced concepts
- Celestia - modular DA layer chuyên biệt, khác với monolithic chain (Ethereum) tích hợp cả execution + DA + consensus.

Ngày 105: Thực hành deploy lên L2 + Ôn tập

Khái niệm
- Sequencer centralization hiện tại - hầu hết rollup vẫn có 1 sequencer tập trung (roadmap decentralize dần).
Thực hành và quan sát
- Deploy 1 smart contract đơn giản (đã có sẵn từ trước hoặc viết mới) lên cả L1 testnet và 1 L2 testnet, so sánh thực tế: gas cost, tốc độ confirm, finality thời gian thật.
Advanced concepts
- Shared sequencer (Espresso, Astria) - hướng giải quyết centralization + cross-rollup composability.

Tuần 22 (Ngày 106–110): Statelessness, Verkle Tree, và tương lai Ethereum

Ngày 106: Vấn đề state growth

Khái niệm
- State bloat - vì sao state trie ngày càng lớn là vấn đề dài hạn cho node operator (storage, sync time).
Thực hành và quan sát
- Tra cứu số liệu thực tế kích thước state Ethereum hiện tại (qua dashboard công khai), so với vài năm trước.
Advanced concepts
- State expiry proposal - hướng nghiên cứu "hết hạn" state cũ không dùng tới, cần cơ chế "revival" nếu cần dùng lại.

Ngày 107: Verkle Tree - thay thế MPT

Khái niệm
- Vector commitment thay vì hash thường - proof kích thước nhỏ hơn nhiều so với Merkle proof cho cùng độ sâu cây (log giảm đáng kể).
Thực hành và quan sát
- Đọc tài liệu kỹ thuật Verkle Tree của Ethereum Foundation, vẽ so sánh kích thước proof MPT (32 byte/node × depth) vs Verkle (constant-ish theo Pedersen/KZG commitment).
Advanced concepts
- Cần KZG polynomial commitment (sẽ học chi tiết ở Phần 5) - Verkle Tree phụ thuộc trực tiếp vào phần Advanced Cryptography.

Ngày 108: Statelessness & witness

Khái niệm
- Stateless client - validator không cần lưu toàn bộ state, chỉ cần "witness" (proof) đi kèm mỗi block để verify.
Thực hành và quan sát
- Vẽ sơ đồ so sánh: full node hiện tại (lưu toàn bộ state) vs stateless validator tương lai (chỉ cần witness theo từng block).
Advanced concepts
- Trade-off: giảm gánh nặng storage cho validator nhưng tăng kích thước mỗi block (phải kèm witness).

Ngày 109: Danksharding roadmap

Khái niệm
- Full Danksharding - mở rộng từ proto-danksharding (đã học ngày 104), mục tiêu tăng số blob/block đáng kể, dùng DAS (Data Availability Sampling) toàn diện.
Thực hành và quan sát
- Đọc roadmap chính thức Ethereum Foundation, tóm tắt các giai đoạn (The Surge) theo mốc thời gian dự kiến - lưu ý: đây là lĩnh vực thay đổi nhanh, cần tra cứu nguồn cập nhật khi học tới đây.
Advanced concepts
- 2D KZG scheme cho DAS - cách encode dữ liệu theo cả hàng và cột để sampling hiệu quả hơn.

Ngày 110: Ôn tập Tuần 21-22 + Bài test

Khái niệm
- Tổng hợp: Rollup, DA, statelessness, Verkle Tree, Danksharding.
Thực hành và quan sát
- Bài test: vẽ sơ đồ toàn bộ "The Surge" roadmap kèm giải thích từng thành phần bằng ngôn ngữ riêng.
Advanced concepts
- Ghi chú: những nội dung Phần này (đặc biệt roadmap) cần đối chiếu tài liệu chính thức tại thời điểm học vì tiến độ triển khai thực tế có thể khác dự kiến ban đầu.

Tuần 23 (Ngày 111–115): Đọc source code go-ethereum (nhập môn - sâu hơn ở Phần 8)

Ngày 111: Kiến trúc tổng thể go-ethereum

Khái niệm
- Cấu trúc thư mục chính: core/ (blockchain, state), eth/ (protocol), p2p/ (networking), consensus/, trie/.
Thực hành và quan sát
- Clone go-ethereum, build từ source, chạy geth ở chế độ dev (--dev), gửi 1 transaction test qua console tích hợp.
Advanced concepts
- Đọc go-ethereum/AGENTS.md hoặc tài liệu contributor guide (nếu có) để hiểu convention trước khi đọc sâu.

Ngày 112: Trace transaction qua core/state_processor.go

Khái niệm
- ApplyTransaction - hàm trung tâm áp dụng 1 transaction vào state, gọi vào EVM interpreter thật.
Thực hành và quan sát
- Đọc core/state_processor.go, đánh dấu từng bước: intrinsic gas check → EVM call → refund → receipt.
Advanced concepts
- So sánh với mini EVM interpreter tự viết ở tuần 18 - tìm những chỗ implementation thật xử lý edge case mà bản tự viết bỏ sót.

Ngày 113: core/vm - EVM implementation thật

Khái niệm
- core/vm/instructions.go, core/vm/interpreter.go - cách production code tổ chức opcode dispatch (thường dùng jump table thay vì switch-case đơn giản để tối ưu tốc độ).
Thực hành và quan sát
- Đọc jump table trong core/vm/jump_table.go, xác định cấu trúc mỗi opcode (execute function, gas function, minStack/maxStack).
Advanced concepts
- Precompiled contracts (core/vm/contracts.go) - các phép toán đặc biệt (modexp, EC operations, BLS) được "hardcode" native thay vì chạy qua bytecode thường vì lý do hiệu năng.

Ngày 114: trie/ package - MPT implementation thật

Khái niệm
- So sánh implementation MPT thật trong trie/ với bản tự vẽ tay/implement ở Phần 0.
Thực hành và quan sát
- Đọc trie/trie.go, xác định cách node được cache và commit xuống database (liên hệ LSM-tree đã học Phần 1).
Advanced concepts
- Trie pruning - cách geth dọn dẹp state cũ không cần thiết để giảm dung lượng disk.

Ngày 115: Ôn tập toàn bộ Phần 4 + Bài test lớn

Khái niệm
- Tổng hợp toàn bộ Ethereum & EVM Internals: account model, EVM, consensus layer, MEV/PBS, Layer 2, tương lai roadmap, source code thật.
Thực hành và quan sát
- Bài test lớn: chọn 1 transaction thật trên mainnet/testnet, trace toàn bộ vòng đời của nó - từ lúc ký, gửi vào mempool, được builder đóng gói (nếu qua MEV-Boost), tới lúc block chứa nó được finalize - viết báo cáo 2-3 trang kèm bằng chứng (link Etherscan, RPC call output).
Advanced concepts
- Đây là bài test tổng hợp quan trọng nhất tính tới thời điểm này trong khóa học - nếu làm được trọn vẹn, bạn đã vượt qua phần khó nhất của "Blockchain Engineer" theo đánh giá ban đầu.

PHẦN 5 - ADVANCED CRYPTOGRAPHY & ZERO-KNOWLEDGE (Ngày 116–135)

Tuần 24 (Ngày 116–120): Pairing-based cryptography

Ngày 116: Bilinear pairing - trực giác

Khái niệm
- Bilinear map e: G1 × G2 → GT với thuộc tính e(aP, bQ) = e(P,Q)^(ab) - "phép nhân ẩn trong số mũ", nền tảng cho hầu hết SNARK hiện đại và BLS signature.
Thực hành và quan sát
- Đọc và tóm tắt (không cần chứng minh toán học đầy đủ) ví dụ minh họa tại sao pairing cho phép verify 1 phương trình bậc 2 (multiplication) chỉ bằng phép cộng điểm - điều ECDSA thường không làm được.
Advanced concepts
- Đường cong BLS12-381 - vì sao được chọn cho Ethereum consensus layer (độ an toàn ~128-bit, hiệu năng pairing tốt).

Ngày 117: BLS Signature

Khái niệm
- Sign: σ = H(m)^sk. Verify: e(σ, G) = e(H(m), pk) - cách pairing cho phép verify mà không cần biết secret key.
Thực hành và quan sát
- Dùng thư viện BLS có sẵn (VD blst hoặc binding Python), sign 1 message, verify, và quan trọng nhất: aggregate nhiều chữ ký thành 1 chữ ký duy nhất, verify chữ ký gộp.
Advanced concepts
- Rogue key attack lên BLS aggregation - vì sao cần Proof of Possession (PoP) khi đăng ký public key (Ethereum validator bắt buộc điều này khi deposit).

Ngày 118: BLS aggregation trong Ethereum consensus thực tế

Khái niệm
- Ethereum dùng BLS aggregate signature để gộp attestation của hàng ngàn validator trong 1 committee thành 1 chữ ký duy nhất trên chain - lý do khả thi throughput hiện tại.
Thực hành và quan sát
- Tính toán ước lượng: nếu không dùng aggregation, kích thước block cần lưu bao nhiêu chữ ký riêng lẻ mỗi epoch (~hàng trăm ngàn validator) - so với thực tế dùng aggregate.
Advanced concepts
- Liên hệ ngược lại Phần 4 ngày 91-95 (Gasper) - giờ đã hiểu tại sao attestation có thể xử lý ở quy mô lớn.

Ngày 119: KZG Polynomial Commitment

Khái niệm
- Commit vào 1 đa thức bằng 1 điểm elliptic curve duy nhất (constant size, không phụ thuộc bậc đa thức) - dùng trusted setup (Powers of Tau, đã nhắc ở Phần 2 ngày 58).
- Opening proof: chứng minh p(z) = y mà không tiết lộ toàn bộ đa thức.
Thực hành và quan sát
- Dùng thư viện KZG có sẵn (hoặc code mẫu tham khảo), commit vào 1 đa thức bậc thấp, tạo và verify 1 opening proof.
Advanced concepts
- KZG là nền tảng trực tiếp của EIP-4844 (blob commitment) và Verkle Tree đã học ở Phần 4 - giờ quay lại hiểu chi tiết cơ chế toán học đằng sau.

Ngày 120: Ôn tập pairing-based crypto

Khái niệm
- Tổng hợp: bilinear pairing, BLS, KZG.
Thực hành và quan sát
- Bài test: giải thích bằng ngôn ngữ riêng tại sao KZG proof có kích thước O(1) trong khi Merkle proof là O(log n) - và trade-off (KZG cần trusted setup + phép toán pairing nặng hơn).
Advanced concepts
- Chuẩn bị cho phần PLONK/STARK - cả hai đều dùng polynomial commitment (KZG hoặc FRI) làm building block.

Tuần 25 (Ngày 121–125): SNARK (Groth16 → PLONK)

Ngày 121: R1CS & QAP

Khái niệm
- Rank-1 Constraint System: mỗi ràng buộc dạng (a·s)*(b·s) = (c·s) - cách bài toán tính toán bất kỳ được "biên dịch" thành R1CS.
- Quadratic Arithmetic Program (QAP): chuyển R1CS thành đa thức để dùng polynomial commitment.
Thực hành và quan sát
- Chuyển tay 1 bài toán đơn giản (x³ + x + 5 = y) thành R1CS, xác định các ma trận A, B, C.
Advanced concepts
- Đây chính là bước "biên dịch" mà Circom (đã dùng ở Phần 2) làm tự động phía sau - giờ hiểu rõ nó làm gì.

Ngày 122: Groth16 chi tiết

Khái niệm
- Cấu trúc proof 3 điểm elliptic curve (A, B, C) - cực nhỏ và verify cực nhanh, nhưng cần trusted setup RIÊNG cho mỗi circuit (circuit-specific).
Thực hành và quan sát
- Quay lại circuit Circom đã viết ở Phần 2 ngày 59, đọc kỹ output verification_key.json, xác định ứng với thành phần nào trong công thức Groth16.
Advanced concepts
- Vì sao trusted setup circuit-specific là nhược điểm lớn của Groth16 (mỗi lần đổi circuit phải làm lại ceremony) - động lực cho PLONK.

Ngày 123: PLONK - universal setup

Khái niệm
- Universal & updatable trusted setup - 1 lần setup dùng được cho MỌI circuit (tới 1 kích thước giới hạn), khác biệt lớn so với Groth16.
- Permutation argument - cách PLONK kiểm tra tính nhất quán giữa các wire mà không cần custom circuit riêng.
Thực hành và quan sát
- Đọc tài liệu kỹ thuật PLONK (bài viết gốc hoặc tài liệu tóm tắt uy tín), vẽ sơ đồ so sánh luồng setup Groth16 (per-circuit) vs PLONK (universal).
Advanced concepts
- PlonKup/custom gates - mở rộng PLONK cho phép ràng buộc tùy biến hiệu quả hơn (dùng trong nhiều zkEVM hiện đại như zkSync, Scroll).

Ngày 124: STARK - không cần trusted setup

Khái niệm
- FRI (Fast Reed-Solomon Interactive Oracle Proof) thay cho polynomial commitment dạng KZG - chỉ cần hash function (collision-resistant), không cần pairing hay trusted setup.
Thực hành và quan sát
- So sánh bảng: Groth16 vs PLONK vs STARK theo 5 tiêu chí (kích thước proof, tốc độ verify, tốc độ prove, cần trusted setup?, chống lượng tử?).
Advanced concepts
- Kích thước proof STARK lớn hơn SNARK đáng kể (dùng nhiều Merkle proof qua FRI) - trade-off rõ ràng giữa "trustless setup" và "proof size".

Ngày 125: Ôn tập SNARK/STARK + Bài test

Khái niệm
- Tổng hợp R1CS/QAP, Groth16, PLONK, STARK.
Thực hành và quan sát
- Bài test: cho 1 use-case cụ thể (VD: zkRollup cho payment đơn giản), đề xuất và giải thích lý do chọn hệ proof nào (Groth16/PLONK/STARK) dựa trên trade-off đã học.
Advanced concepts
- Recursive proof - 1 proof verify 1 proof khác (dùng để nén nhiều block thành 1 proof duy nhất) - kỹ thuật nâng cao dùng trong nhiều zkEVM production.

Tuần 26 (Ngày 126–130): MPC & Threshold Cryptography

Ngày 126: Secret Sharing

Khái niệm
- Shamir's Secret Sharing: chia 1 secret thành n phần, chỉ cần t phần để khôi phục (dùng nội suy đa thức Lagrange).
Thực hành và quan sát
- Implement Shamir's Secret Sharing từ đầu: chia 1 số bí mật thành 5 phần (t=3), khôi phục lại từ 3 phần bất kỳ, verify khôi phục sai nếu thiếu phần.
Advanced concepts
- Verifiable Secret Sharing (VSS) - cho phép mỗi bên verify phần của mình đúng mà không cần tin tưởng người chia.

Ngày 127: MPC nguyên lý cơ bản

Khái niệm
- Secure Multi-Party Computation: nhiều bên tính chung 1 hàm mà không ai tiết lộ input riêng của mình cho bên khác.
Thực hành và quan sát
- Đọc ví dụ kinh điển "Millionaire's Problem" (Yao) - 2 triệu phú so sánh ai giàu hơn mà không tiết lộ số tiền cụ thể, tóm tắt ý tưởng garbled circuit ở mức khái niệm.
Advanced concepts
- MPC dùng trong custody hiện đại (Fireblocks, Web3Auth) - không có bên nào (kể cả provider) từng nắm giữ toàn bộ private key tại bất kỳ thời điểm nào.

Ngày 128: Threshold ECDSA/EdDSA

Khái niệm
- Khác biệt với Shamir đơn giản: ECDSA/EdDSA không tuyến tính hoàn toàn, cần giao thức MPC phức tạp hơn (GG18/GG20 cho ECDSA) để threshold-sign mà không bao giờ tái tạo lại private key đầy đủ ở 1 nơi.
Thực hành và quan sát
- Đọc kiến trúc tổng quan giao thức GG18 (không cần implement đầy đủ - độ phức tạp cao), vẽ sơ đồ các round giao tiếp giữa các party.
Advanced concepts
- So sánh threshold Schnorr (đơn giản hơn nhiều nhờ tính linear, dùng MuSig2 đã nhắc ở Phần 2) với threshold ECDSA - lý do nhiều hệ thống mới chuyển sang Schnorr khi có thể.

Ngày 129: EigenLayer & Restaking (ứng dụng thực tế của threshold crypto)

Khái niệm
- Restaking: dùng lại ETH đã stake để bảo mật thêm các dịch vụ khác (AVS - Actively Validated Services) - cần cơ chế slashing đa tầng.
Thực hành và quan sát
- Đọc whitepaper/docs EigenLayer, vẽ sơ đồ luồng: staker → EigenLayer → AVS, xác định rủi ro chính (slashing chồng chéo, correlated risk).
Advanced concepts
- Nhiều AVS dùng BLS aggregation (đã học ngày 117-118) cho operator set riêng - liên hệ trực tiếp kiến thức pairing-based crypto vào use-case thực tế mới.

Ngày 130: Ôn tập Tuần 26 + Bài test

Khái niệm
- Tổng hợp Secret Sharing, MPC, Threshold signature, ứng dụng thực tế (custody, restaking).
Thực hành và quan sát
- Bài test: thiết kế (viết pseudocode/sơ đồ) 1 hệ thống custody cho sàn giao dịch dùng threshold signature 3-of-5, giải thích luồng ký giao dịch rút tiền.
Advanced concepts
- So sánh thiết kế của bạn với on-chain multisig (Gnosis Safe, đã học Phần 2) - khi nào nên chọn TSS off-chain, khi nào nên chọn multisig on-chain.

Tuần 27 (Ngày 131–135): Verkle Tree thực hành & tổng kết ZK

Ngày 131: Pedersen Commitment

Khái niệm
- Commit(m, r) = mG + rH - commitment scheme homomorphic đơn giản, hiding và binding dưới giả định discrete log khó.
Thực hành và quan sát
- Implement Pedersen commitment từ đầu, verify tính chất homomorphic: Commit(a) + Commit(b) = Commit(a+b).
Advanced concepts
- Pedersen commitment là building block của Verkle Tree (dùng vector commitment mở rộng từ ý tưởng này) và của Confidential Transactions (che giấu số lượng giao dịch, dùng trong Monero/Mimblewimble).

Ngày 132: Verkle Tree - thực hành

Khái niệm
- Quay lại Phần 4 ngày 107, giờ đủ nền tảng (KZG/Pedersen) để hiểu chi tiết: mỗi node dùng vector commitment thay vì hash, cho phép proof kích thước nhỏ dù cây có branching factor cao (256-way thay vì 16-way như MPT).
Thực hành và quan sát
- Đọc implementation reference Verkle Tree (Go hoặc Rust, có trên GitHub Ethereum Foundation), trace 1 lần insert + generate proof.
Advanced concepts
- Vì sao branching factor cao hơn (256 thay vì 16) giúp giảm độ sâu cây → giảm kích thước proof tổng thể dù mỗi commitment "nặng" hơn hash thường.

Ngày 133: Confidential transaction & Pedersen trong thực tế

Khái niệm
- Range proof (Bulletproofs) - chứng minh 1 giá trị nằm trong khoảng hợp lệ (VD: không âm) mà không tiết lộ giá trị, cần thiết để confidential transaction không bị lợi dụng tạo tiền từ hư không.
Thực hành và quan sát
- Đọc ý tưởng Bulletproofs (không cần implement đầy đủ), tóm tắt vì sao kích thước proof chỉ logarit theo số bit của giá trị (thay vì tuyến tính).
Advanced concepts
- Mimblewimble (Grin/Beam) - thiết kế blockchain dựa hoàn toàn trên Pedersen commitment + CoinJoin tự nhiên, loại bỏ khái niệm address truyền thống.

Ngày 134: So sánh toàn cảnh các công nghệ ZK đã học

Khái niệm
- Tổng hợp toàn bộ Phần 5: bilinear pairing, BLS, KZG, R1CS/QAP, Groth16/PLONK/STARK, Secret Sharing/MPC/TSS, Pedersen/Verkle/Bulletproofs.
Thực hành và quan sát
- Vẽ 1 sơ đồ tổng thể (mindmap) liên kết toàn bộ các khái niệm này với những nơi chúng được ứng dụng thực tế đã học (Ethereum consensus, EIP-4844, Verkle Tree, zkRollup, custody, restaking).
Advanced concepts
- Đây là bản đồ kiến thức quan trọng nhất của toàn khóa học về mặt lý thuyết - nên in ra/lưu lại để tham chiếu xuyên suốt các phần sau.

Ngày 135: Bài test tổng hợp Phần 5

Khái niệm
- Kiểm tra toàn diện Advanced Cryptography & ZK.
Thực hành và quan sát
- Bài test: chọn 1 trong các chủ đề đã học (KZG, PLONK, Threshold ECDSA, Verkle Tree...) viết 1 bài giải thích kỹ thuật dài 2-3 trang như thể giải thích cho 1 kỹ sư backend chưa biết gì về crypto - đây là cách tốt nhất để tự kiểm tra mức độ hiểu thật sự (Feynman technique).
Advanced concepts
- Chuẩn bị chuyển sang Phần 6 (Smart Contract Development) - giờ đã có đủ nền tảng để hiểu vì sao nhiều pattern security trong Solidity liên quan trực tiếp tới các khái niệm crypto vừa học.

PHẦN 6 - SMART CONTRACT DEVELOPMENT & SECURITY (Ngày 136–170)

Tuần 28 (Ngày 136–140): Solidity nền tảng

Ngày 136: Storage layout & slot packing

Khái niệm
- Mỗi storage slot 32 byte, cách compiler tự động "đóng gói" nhiều biến nhỏ vào cùng 1 slot - thứ tự khai báo biến ảnh hưởng trực tiếp gas cost.
Thực hành và quan sát
- Viết 2 contract giống hệt nhau về logic nhưng thứ tự khai báo biến khác nhau, dùng forge inspect <Contract> storage-layout so sánh số slot dùng.
Advanced concepts
- Storage collision trong proxy pattern - vì sao thứ tự biến giữa proxy và implementation phải khớp tuyệt đối (liên hệ ngày 89 - DELEGATECALL dùng storage của caller).

Ngày 137: Memory, calldata, và ABI encoding

Khái niệm
- Khi nào dùng memory vs calldata (calldata rẻ hơn cho external function không cần sửa dữ liệu) - ABI encoding: cách function selector (4 byte đầu Keccak256 của signature) và argument được encode.
Thực hành và quan sát
- Dùng cast calldata (Foundry) encode 1 lời gọi hàm thủ công, decode lại bằng tay theo spec ABI, so khớp với cast decode-calldata.
Advanced concepts
- Dynamic type encoding (array, string) - offset-based encoding phức tạp hơn static type, dễ gây lỗi khi viết low-level call thủ công.

Ngày 138: Inheritance, interface, và library

Khái niệm
- Linearization (C3 linearization) khi kế thừa đa cấp - thứ tự gọi constructor và override function.
- library với using...for - cách tránh trùng lặp code mà không tốn thêm storage.
Thực hành và quan sát
- Viết 1 hệ thống contract có kế thừa đa cấp (3 tầng), cố tình tạo diamond inheritance để quan sát cách Solidity xử lý linearization.
Advanced concepts
- virtual/override keyword và function selector clash - khi 2 interface có cùng selector nhưng khác signature ý nghĩa (hiếm nhưng là vector tấn công tiềm ẩn).

Ngày 139: Error handling & custom errors

Khái niệm
- require/revert/assert khác biệt về gas refund và use-case; custom error (từ Solidity 0.8.4) tiết kiệm gas hơn string message.
Thực hành và quan sát
- Viết lại 1 contract dùng require với string message, đo gas, sau đó chuyển sang custom error, đo lại và so sánh.
Advanced concepts
- Try/catch cho external call - cách bắt lỗi khi gọi contract khác, và giới hạn (không bắt được lỗi out-of-gas trong 1 số trường hợp).

Ngày 140: Events, indexed parameters, và off-chain indexing

Khái niệm
- indexed parameter → đưa vào topic (tối đa 3 topic + 1 event signature), ảnh hưởng khả năng filter qua eth_getLogs.
Thực hành và quan sát
- Thiết kế event cho 1 contract ERC-20 tự viết, chọn field nào nên indexed, viết script off-chain filter theo địa chỉ cụ thể qua eth_getLogs.
Advanced concepts
- Anonymous event (tiết kiệm gas, mất khả năng filter theo signature) - trade-off hiếm dùng nhưng cần biết tồn tại.

Tuần 29 (Ngày 141–145): Token standards

Ngày 141: ERC-20

Khái niệm
- Interface chuẩn: transfer, approve, transferFrom, allowance - vấn đề race condition kinh điển của approve (front-running approve amount).
Thực hành và quan sát
- Viết ERC-20 hoàn chỉnh từ đầu KHÔNG dùng OpenZeppelin, đầy đủ event, kiểm tra edge case (transfer 0, transfer tới chính mình, approve race condition minh họa bằng test).
Advanced concepts
- increaseAllowance/decreaseAllowance pattern (đã bị deprecate trong OZ mới nhưng vẫn cần hiểu lý do lịch sử) vs Permit (EIP-2612 - approve bằng chữ ký off-chain, không cần transaction riêng).

Ngày 142: ERC-721 (NFT)

Khái niệm
- Ownership mapping, safeTransferFrom và onERC721Received callback - lý do cần callback (tránh NFT bị "mắc kẹt" vĩnh viễn trong contract không hỗ trợ nhận NFT).
Thực hành và quan sát
- Viết ERC-721 từ đầu, test kỹ callback: gửi NFT tới 1 contract không implement onERC721Received và quan sát transaction bị revert.
Advanced concepts
- ERC-721A - pattern tối ưu gas cho batch mint (giảm số lần SSTORE bằng cách suy luận ownership từ khoảng ID thay vì lưu từng token).

Ngày 143: ERC-1155 (multi-token)

Khái niệm
- 1 contract quản lý nhiều loại token (fungible + non-fungible) - batch operation giảm đáng kể gas so với gọi lặp lại ERC-20/721.
Thực hành và quan sát
- Viết ERC-1155 tối giản, test balanceOfBatch và safeBatchTransferFrom, đo gas so với thực hiện tương đương bằng nhiều lệnh ERC-20 riêng lẻ.
Advanced concepts
- Use-case thực tế: game item, semi-fungible token (vé sự kiện - fungible trước khi dùng, non-fungible sau khi check-in).

Ngày 144: Permit & meta-transaction (gasless UX)

Khái niệm
- EIP-2612 Permit: approve bằng chữ ký off-chain (ECDSA đã học sâu ở Phần 2), người khác trả gas để submit.
- EIP-2771 meta-transaction: forwarder contract xác thực chữ ký, relayer trả gas thay user.
Thực hành và quan sát
- Implement Permit cho ERC-20 đã viết ngày 141, viết script off-chain ký permit message và submit bằng 1 account khác (mô phỏng relayer).
Advanced concepts
- Account Abstraction (ERC-4337) - hướng đi rộng hơn cho phép logic xác thực tùy biến hoàn toàn (sẽ học sâu ở tuần sau).

Ngày 145: Ôn tập token standards + Bài test

Khái niệm
- Tổng hợp ERC-20/721/1155/Permit.
Thực hành và quan sát
- Bài test: thiết kế 1 hệ thống có cả fungible reward token (ERC-20) và collectible NFT (ERC-721), cho phép stake NFT để nhận token - viết đầy đủ 2 contract tương tác với nhau, test integration.
Advanced concepts
- Review lại toàn bộ code, đối chiếu với OpenZeppelin thật để tìm những edge case mình đã bỏ sót.

Tuần 30 (Ngày 146–150): Security vulnerabilities

Ngày 146: Reentrancy - mổ xẻ The DAO hack

Khái niệm
- Cơ chế: external call trước khi cập nhật state (call.value gửi ETH trước, trừ balance sau) - attacker gọi lại (reenter) hàm withdraw trong callback trước khi balance được cập nhật.
Thực hành và quan sát
- Tái hiện lại 1 phiên bản đơn giản hóa của lỗ hổng The DAO trên testnet cá nhân: viết contract vulnerable + contract attacker, chạy exploit thành công, sau đó fix bằng Checks-Effects-Interactions pattern và verify exploit không còn hoạt động.
Advanced concepts
- Cross-function reentrancy (khó phát hiện hơn - 2 hàm khác nhau chia sẻ state bị khai thác qua reentrancy) và read-only reentrancy (view function trả giá trị sai trong lúc đang bị reenter, ảnh hưởng contract khác đọc giá trị đó).

Ngày 147: Integer overflow/underflow & access control

Khái niệm
- Trước Solidity 0.8: overflow im lặng (cần SafeMath); từ 0.8: revert tự động - nhưng unchecked{} block vẫn có thể tái tạo lỗi cũ nếu dùng sai.
- Access control lỗi: quên modifier onlyOwner, hoặc dùng tx.origin thay vì msg.sender (dễ bị phishing qua contract trung gian).
Thực hành và quan sát
- Viết 1 contract dùng tx.origin để check quyền, viết contract attacker lừa victim gọi qua trung gian, chứng minh bypass thành công; sau đó fix bằng msg.sender.
Advanced concepts
- unchecked block dùng đúng chỗ (VD: loop counter chắc chắn không overflow) để tối ưu gas mà vẫn an toàn - ranh giới giữa tối ưu và rủi ro.

Ngày 148: Oracle manipulation & flash loan attack

Khái niệm
- Dùng giá spot từ 1 AMM pool làm oracle trực tiếp - attacker dùng flash loan thao túng giá trong 1 transaction duy nhất rồi khai thác.
Thực hành và quan sát
- Đọc phân tích kỹ thuật chi tiết 1 vụ hack thật dùng flash loan + oracle manipulation (VD: Harvest Finance hoặc bZx - tra cứu report kỹ thuật cụ thể), vẽ lại sơ đồ luồng tấn công từng bước.
Advanced concepts
- TWAP (Time-Weighted Average Price) oracle - cách giảm thiểu (không loại bỏ hoàn toàn) rủi ro thao túng giá trong 1 block/vài block.

Ngày 149: Delegatecall injection & proxy vulnerability

Khái niệm
- Rủi ro khi delegatecall tới địa chỉ do user kiểm soát, hoặc storage layout giữa proxy/implementation không khớp - attacker có thể ghi đè biến quan trọng (VD: owner).
Thực hành và quan sát
- Tái hiện 1 lỗ hổng storage collision đơn giản: proxy có biến owner ở slot 0, implementation cố tình có biến khác ở slot 0, chứng minh attacker chiếm quyền owner qua contract implementation.
Advanced concepts
- EIP-1967 storage slot pattern - dùng slot được tính theo hash đặc biệt (keccak256("eip1967...") - 1) để tránh collision với storage của implementation.

Ngày 150: Ôn tập vulnerability kinh điển + Ethernaut

Khái niệm
- Tổng hợp reentrancy, overflow/access control, oracle manipulation, delegatecall injection.
Thực hành và quan sát
- Giải 10 level đầu tiên của Ethernaut (OpenZeppelin) - bắt buộc, mỗi level viết lại báo cáo ngắn: lỗ hổng gì, cách khai thác, cách fix.
Advanced concepts
- So sánh cách bạn giải với writeup chính thức (chỉ đọc SAU khi tự giải xong) - tìm cách tiếp cận khác mà bạn chưa nghĩ tới.

Tuần 31 (Ngày 151–155): Testing với Foundry

Ngày 151: Foundry setup & unit test cơ bản

Khái niệm
- Cấu trúc dự án Foundry: forge test, cheatcodes (vm.prank, vm.deal, vm.expectRevert).
Thực hành và quan sát
- Setup project Foundry mới, viết unit test đầy đủ cho contract ERC-20 đã viết ngày 141, dùng vm.prank giả lập nhiều account khác nhau.
Advanced concepts
- vm.warp/vm.roll - giả lập thời gian/block number để test logic phụ thuộc timestamp (VD: vesting contract).

Ngày 152: Fuzz testing

Khái niệm
- Property-based testing: thay vì test 1 input cụ thể, khai báo property phải đúng với MỌI input, Foundry tự sinh hàng ngàn input ngẫu nhiên để tìm phản ví dụ.
Thực hành và quan sát
- Viết fuzz test cho contract AMM đơn giản (nếu chưa có, viết 1 AMM tối giản): property "tổng giá trị pool sau swap phải ≥ trước swap trừ phí" - chạy forge test --fuzz-runs 10000.
Advanced concepts
- Bounding input (vm.assume, hoặc custom bound function) - tránh fuzz test lãng phí thời gian vào input vô nghĩa (VD: amount = 0).

Ngày 153: Invariant testing

Khái niệm
- Khác fuzz test (test 1 hàm với nhiều input), invariant test gọi NGẪU NHIÊN nhiều hàm liên tiếp (stateful) rồi kiểm tra invariant vẫn đúng sau chuỗi hành động bất kỳ.
Thực hành và quan sát
- Viết invariant test cho hệ thống lending đơn giản (nếu chưa có, viết 1 lending contract tối giản): invariant "tổng collateral luôn ≥ tổng debt theo tỷ lệ an toàn" sau chuỗi random deposit/borrow/withdraw.
Advanced concepts
- Handler pattern - giới hạn không gian hành động ngẫu nhiên để invariant test hiệu quả hơn (tránh phần lớn run bị revert vô nghĩa).

Ngày 154: Static analysis với Slither

Khái niệm
- Slither: phân tích tĩnh dựa trên SlithIR (intermediate representation), phát hiện pattern nguy hiểm tự động (reentrancy, uninitialized storage, shadowing...).
Thực hành và quan sát
- Chạy Slither trên toàn bộ contract đã viết từ đầu khóa học, fix mọi warning mức High/Medium, ghi chú lại false positive (nếu có) và giải thích tại sao là false positive.
Advanced concepts
- Viết 1 custom Slither detector đơn giản (nếu có thời gian) - hiểu cách công cụ phân tích tĩnh hoạt động từ bên trong, không chỉ dùng như hộp đen.

Ngày 155: Symbolic execution & formal verification (nhập môn)

Khái niệm
- Symbolic execution (Mythril) - thử tất cả nhánh thực thi có thể bằng biến symbolic thay vì giá trị cụ thể; formal verification (Certora) - chứng minh toán học property luôn đúng.
Thực hành và quan sát
- Chạy Mythril trên 1 contract, so sánh kết quả phát hiện với Slither đã chạy hôm trước.
Advanced concepts
- Certora Prover - viết 1 spec đơn giản (CVL - Certora Verification Language) cho 1 property cơ bản (VD: tổng supply không đổi qua transfer) nếu có quyền truy cập bản dùng thử.

Tuần 32 (Ngày 156–160): Gas optimization & assembly

Ngày 156: Gas optimization patterns cơ bản

Khái niệm
- Cache storage vào memory trong loop, dùng immutable/constant cho giá trị không đổi, short-circuit trong điều kiện logic.
Thực hành và quan sát
- Optimize 1 contract có loop đọc storage lặp lại, đo gas trước/sau bằng forge snapshot --diff.
Advanced concepts
- Packed struct trong array - tiết kiệm đáng kể khi lặp qua mảng lớn struct, đánh đổi với độ phức tạp đọc/ghi.

Ngày 157: Custom errors, unchecked math, và calldata optimization

Khái niệm
- Đã học custom error ngày 139, giờ áp dụng có hệ thống; unchecked cho loop counter; dùng calldata thay memory cho array tham số external function.
Thực hành và quan sát
- Refactor 1 contract phức tạp hơn (VD: contract lending đã viết), áp dụng toàn bộ pattern trên, đo tổng gas tiết kiệm được qua benchmark trước/sau.
Advanced concepts
- Function selector ordering - Solidity dispatch theo binary search trên selector đã sort; đặt hàm được gọi nhiều nhất với selector "may mắn" có thể tiết kiệm vài gas (tối ưu vi mô, chỉ đáng làm ở contract cực kỳ high-frequency).

Ngày 158: Giới thiệu Yul/Assembly

Khái niệm
- Yul - ngôn ngữ trung gian gần assembly nhưng vẫn đọc được, dùng trong assembly{} block khi cần kiểm soát tuyệt đối.
Thực hành và quan sát
- Viết lại 1 hàm đơn giản (VD: kiểm tra địa chỉ có phải contract không, dùng extcodesize) bằng Yul thay vì Solidity thường, so sánh gas.
Advanced concepts
- Rủi ro dùng assembly: bypass hoàn toàn type-safety và các check tự động của Solidity - chỉ nên dùng khi thực sự cần và đã test kỹ.

Ngày 159: Huff language (tối ưu cực hạn)

Khái niệm
- Huff - viết trực tiếp bằng opcode EVM, dùng cho các contract cực kỳ nhạy cảm về gas (VD: một số MEV bot, router tối ưu).
Thực hành và quan sát
- Viết 1 contract cực đơn giản (VD: cộng 2 số, trả kết quả) hoàn toàn bằng Huff, so sánh bytecode size và gas với bản Solidity tương đương.
Advanced concepts
- Đây là kỹ năng chuyên biệt (niche) - không cần thành thạo, chỉ cần hiểu khi nào ngành công nghiệp dùng tới mức độ tối ưu này và tại sao.

Ngày 160: Ôn tập gas optimization + Bài test

Khái niệm
- Tổng hợp toàn bộ kỹ thuật tối ưu gas đã học.
Thực hành và quan sát
- Bài test: lấy 1 contract đã viết đầu khóa học (VD: ERC-20 hoặc AMM), optimize toàn diện, mục tiêu giảm ≥25% gas so với bản gốc, viết báo cáo liệt kê từng thay đổi và gas tiết kiệm tương ứng.
Advanced concepts
- Cân nhắc trade-off readability vs gas - không phải lúc nào tối ưu tối đa cũng đáng, đặc biệt với contract ít được gọi.

Tuần 33 (Ngày 161–165): Upgrade pattern, Account Abstraction, và kiến trúc nâng cao

Ngày 161: Proxy pattern - Transparent Proxy

Khái niệm
- Vấn đề "function selector clash" giữa proxy admin function và implementation function - Transparent Proxy giải quyết bằng cách phân biệt caller là admin hay user thường.
Thực hành và quan sát
- Deploy 1 hệ thống Transparent Proxy (dùng OpenZeppelin Upgrades) cho contract ERC-20 đã viết, thực hiện upgrade thêm 1 hàm mới, verify state cũ vẫn giữ nguyên sau upgrade.
Advanced concepts
- Overhead gas của Transparent Proxy (mỗi call đều phải check admin) - động lực cho UUPS.

Ngày 162: UUPS Proxy

Khái niệm
- Universal Upgradeable Proxy Standard - logic upgrade nằm trong implementation (không phải proxy), giảm gas overhead, nhưng rủi ro nếu implementation quên hàm upgrade (không thể upgrade được nữa).
Thực hành và quan sát
- Chuyển đổi hệ thống ngày 161 sang UUPS, so sánh gas cost mỗi lần gọi hàm thường giữa 2 pattern.
Advanced concepts
- Lỗ hổng thực tế: quên initializer modifier hoặc quên gọi _disableInitializers() trong constructor implementation - dẫn tới ai đó có thể "chiếm" implementation contract trực tiếp (dù không ảnh hưởng proxy, vẫn là rủi ro).

Ngày 163: Diamond Pattern (EIP-2535)

Khái niệm
- 1 proxy có thể route tới NHIỀU implementation contract (facet) khác nhau theo function selector - giải quyết giới hạn kích thước contract (24KB) và cho phép upgrade từng phần nhỏ.
Thực hành và quan sát
- Đọc reference implementation Diamond Pattern, vẽ sơ đồ luồng: fallback function → lookup facet theo selector → delegatecall.
Advanced concepts
- Độ phức tạp vận hành cao hơn đáng kể (nhiều facet, dễ storage collision nếu không quản lý cẩn thận qua Diamond Storage pattern) - chỉ dùng khi thực sự cần, đa số dự án UUPS là đủ.

Ngày 164: Account Abstraction - ERC-4337

Khái niệm
- UserOperation, EntryPoint, Bundler, Paymaster - kiến trúc cho phép logic xác thực tùy biến hoàn toàn (social recovery, session key, sponsor gas) mà không cần thay đổi protocol layer Ethereum.
Thực hành và quan sát
- Đọc kiến trúc ERC-4337 chi tiết, vẽ sơ đồ luồng đầy đủ: user ký UserOperation → gửi tới bundler → bundler gộp nhiều UserOp → gọi EntryPoint → EntryPoint gọi tới smart account.
Advanced concepts
- Paymaster - cho phép bên thứ 3 trả gas thay user (hoặc trả bằng token khác ETH) - mở khóa nhiều UX mới cho fintech/Web3 (user không cần giữ ETH để trả gas).

Ngày 165: Thực hành Smart Account với ERC-4337

Khái niệm
- Triển khai 1 smart account tối giản tuân theo ERC-4337 (validate signature tùy biến).
Thực hành và quan sát
- Deploy 1 smart account đơn giản lên testnet có hỗ trợ ERC-4337 (dùng bundler công khai của testnet), gửi 1 UserOperation thành công qua smart account đó thay vì EOA thường.
Advanced concepts
- Session key pattern - cấp quyền giới hạn (thời gian, số lượng giao dịch, contract được phép gọi) cho 1 key phụ mà không cần lộ key chính, ứng dụng thực tế cho game/dapp cần UX mượt.

Tuần 34 (Ngày 166–170): Audit process

Ngày 166: Quy trình audit thực tế

Khái niệm
- Scoping (xác định phạm vi, commit hash cụ thể) → manual review → automated tools → report draft → remediation review → final report.
Thực hành và quan sát
- Đọc 2-3 audit report thật (Trail of Bits, OpenZeppelin, Consensys Diligence) trên các dự án lớn công khai, ghi chú cấu trúc report chuẩn (severity classification: Critical/High/Medium/Low/Informational).
Advanced concepts
- Vì sao "audit" không phải "bảo chứng an toàn tuyệt đối" - nhiều dự án đã audit vẫn bị hack (do phạm vi audit giới hạn, thay đổi code sau audit, hoặc lỗ hổng mới không nằm trong pattern đã biết).

Ngày 167: Checklist audit có hệ thống

Khái niệm
- Tổng hợp checklist: access control, arithmetic, external calls, oracle dependency, upgrade safety, gas griefing, front-running, centralization risk.
Thực hành và quan sát
- Chọn 1 contract open-source thật trên GitHub (dự án nhỏ/vừa, chưa có audit công khai), tự chạy qua toàn bộ checklist, đánh dấu mục nào pass/fail/cần xem thêm.
Advanced concepts
- SWC Registry (Smart Contract Weakness Classification) - dùng như tài liệu tham chiếu chuẩn hóa khi phân loại lỗ hổng tìm được.

Ngày 168: Viết audit report

Khái niệm
- Cấu trúc report chuẩn: Executive Summary → Scope → Findings (mỗi finding có severity, description, impact, recommendation, PoC) → Appendix.
Thực hành và quan sát
- Viết audit report đầy đủ cho contract đã review ngày 167, tối thiểu 3-5 finding thật (kể cả finding mức Informational/Low nếu không tìm được lỗi nghiêm trọng), có PoC code cho ít nhất 1 finding.
Advanced concepts
- Cách viết recommendation "actionable" - không chỉ nói "có lỗ hổng X" mà đề xuất cụ thể code sửa như thế nào.

Ngày 169: Damn Vulnerable DeFi - thử thách nâng cao

Khái niệm
- Bộ challenge mô phỏng các vụ hack DeFi thật, độ khó cao hơn Ethernaut, đòi hỏi hiểu sâu tương tác đa contract.
Thực hành và quan sát
- Giải tối thiểu 8-10 challenge của Damn Vulnerable DeFi, viết writeup kỹ thuật cho mỗi challenge (không chỉ code exploit mà giải thích root cause).
Advanced concepts
- So sánh mỗi challenge với vụ hack thật ngoài đời mà nó lấy cảm hứng (đa số challenge đều dựa trên incident có thật) - tìm hiểu vụ thật để đối chiếu.

Ngày 170: Bài test tổng hợp Phần 6

Khái niệm
- Tổng hợp toàn bộ Smart Contract Development & Security.
Thực hành và quan sát
- Bài test lớn: xây dựng 1 hệ thống DeFi hoàn chỉnh từ đầu (VD: lending protocol tối giản với oracle + liquidation), bao gồm - full test suite (unit + fuzz + invariant), chạy Slither sạch warning nghiêm trọng, self-audit report đầy đủ, upgrade pattern (UUPS), gas-optimized, deploy lên testnet có verify.
Advanced concepts
- Đây chính là 1 phiên bản rút gọn của Capstone project - nên giữ lại code này, có thể mở rộng thành Capstone thật ở cuối khóa học.

PHẦN 7 - DEFI, TOKEN ECONOMICS & MARKET STRUCTURE (Ngày 171–195)

Tuần 35 (Ngày 171–175): Game theory & mechanism design

Ngày 171: Nash Equilibrium & game theory cơ bản

Khái niệm
- Nash Equilibrium: trạng thái không ai có động lực đơn phương đổi chiến lược - áp dụng vào việc miner/validator chọn hành vi trung thực hay không.
Thực hành và quan sát
- Giải tay ma trận payoff của "Prisoner's Dilemma" và 1 ví dụ đơn giản về 2 miner quyết định có mine trên fork hay không, tìm Nash Equilibrium.
Advanced concepts
- Schelling point - điểm hội tụ tự nhiên khi các bên không thể giao tiếp trực tiếp (liên hệ tới honest majority assumption trong PoW/PoS).

Ngày 172: Incentive compatibility & mechanism design

Khái niệm
- Mechanism design: thiết kế luật chơi (protocol) sao cho hành vi tối ưu cá nhân (rational) trùng với hành vi mong muốn của hệ thống (incentive-compatible).
Thực hành và quan sát
- Phân tích lại cơ chế slashing (đã học Phần 4) dưới góc nhìn mechanism design: tại sao mức phạt phải đủ lớn hơn lợi ích tiềm năng từ hành vi gian lận.
Advanced concepts
- VCG mechanism (Vickrey-Clarke-Groves) - nền tảng lý thuyết của nhiều cơ chế đấu giá on-chain (liên hệ tới EIP-1559 - dạng gần giống second-price auction cho block space).

Ngày 173: Byzantine rationality

Khái niệm
- Khác biệt giữa "Byzantine" thuần túy (hành vi bất kỳ, kể cả phi lý) và "rational adversary" (luôn hành động tối ưu lợi ích riêng) - hầu hết thiết kế kinh tế blockchain giả định rational, không phải Byzantine tuyệt đối.
Thực hành và quan sát
- Phân tích lại 51% attack dưới góc nhìn rational: khi nào tấn công có lợi về mặt kinh tế (chi phí hashpower/stake vs lợi nhuận double-spend) - tính thử với số liệu thực tế của 1 chain nhỏ.
Advanced concepts
- "Nothing-at-stake" problem trong PoS thuần túy (không slashing) - vì sao rational validator có động lực vote trên MỌI fork nếu không bị phạt.

Ngày 174: Security budget & validator economics

Khái niệm
- Security budget = tổng giá trị kinh tế cần bỏ ra để tấn công thành công mạng - với PoW là chi phí hashpower, với PoS là chi phí mua/thuê đủ stake để kiểm soát 1/3 hoặc 2/3.
Thực hành và quan sát
- Tính toán ước lượng security budget hiện tại của Ethereum (tổng ETH staked × giá thị trường × % cần kiểm soát) - tra cứu số liệu thực tế qua dashboard công khai.
Advanced concepts
- "Long-range attack" trong PoS - khác biệt với PoW (không có "chi phí chìm" vật lý như phần cứng mining), cần weak subjectivity checkpoint để phòng chống.

Ngày 175: Inflation modeling & tokenomics nâng cao

Khái niệm
- Issuance curve (tỷ lệ phát hành mới theo thời gian/số lượng stake), burn mechanism (EIP-1559) - cân bằng giữa đủ incentive cho validator và không pha loãng quá mức giá trị token.
Thực hành và quan sát
- Vẽ đồ thị mô phỏng: net issuance ETH theo số lượng validator active và mức độ đốt phí (baseFee) khác nhau - dùng công thức issuance thực tế của Ethereum.
Advanced concepts
- "Ultra sound money" narrative - phân tích có căn cứ (không thiên vị) về điều kiện để ETH trở thành deflationary, và giới hạn của lập luận này.

Tuần 36 (Ngày 176–180): CeFi market structure (nền tảng cần biết trước DeFi)

Ngày 176: Order book & matching engine

Khái niệm
- Limit order vs market order, price-time priority matching algorithm - cách order book khớp lệnh.
Thực hành và quan sát
- Implement 1 matching engine tối giản từ đầu (in-memory, không cần persistence): nhận limit order, khớp theo price-time priority, trả lại trade log.
Advanced concepts
- Pro-rata matching (khác price-time) - dùng trong 1 số thị trường derivative, phân bổ theo tỷ lệ thay vì ai đến trước.

Ngày 177: Market making cơ bản

Khái niệm
- Bid-ask spread, inventory risk - market maker kiếm lời từ spread nhưng chịu rủi ro nếu giá di chuyển mạnh 1 chiều (adverse selection).
Thực hành và quan sát
- Mô phỏng đơn giản: viết bot market making tối giản chạy trên matching engine tự viết ngày 176, quan sát P&L khi giá thị trường giả lập biến động ngẫu nhiên vs có xu hướng.
Advanced concepts
- Avellaneda-Stoikov model - mô hình toán học nổi tiếng cho optimal market making quote (không cần implement đầy đủ, chỉ cần hiểu ý tưởng: quote lệch theo inventory hiện tại).

Ngày 178: CEX architecture tổng quan

Khái niệm
- Kiến trúc hệ thống sàn giao dịch tập trung: matching engine (thường in-memory, cực nhanh) → risk engine → wallet/custody layer → ledger.
Thực hành và quan sát
- Vẽ sơ đồ kiến trúc CEX hoàn chỉnh, đánh dấu rõ ranh giới hot wallet/cold wallet, và luồng dữ liệu từ lúc đặt lệnh tới lúc balance cập nhật.
Advanced concepts
- Vì sao matching engine thường KHÔNG dùng database truyền thống (dùng in-memory order book + WAL riêng) để đạt độ trễ micro-giây.

Ngày 179: Perpetual futures & funding rate

Khái niệm
- Funding rate mechanism: cơ chế giữ giá perpetual bám sát giá spot mà không cần ngày đáo hạn (khác futures truyền thống).
Thực hành và quan sát
- Tính tay funding payment giữa long/short dựa trên công thức funding rate đơn giản, mô phỏng vài chu kỳ funding với giá perpetual lệch khỏi spot.
Advanced concepts
- Liquidation engine - cơ chế đóng vị thế tự động khi margin không đủ, và "insurance fund" xử lý trường hợp thanh lý không kịp (giá gap mạnh).

Ngày 180: Ôn tập CeFi market structure + Bài test

Khái niệm
- Tổng hợp order book, market making, CEX architecture, perpetual/funding.
Thực hành và quan sát
- Bài test: mở rộng matching engine ngày 176 thêm cơ chế margin đơn giản và liquidation, test kịch bản 1 vị thế bị liquidate khi giá di chuyển đủ mạnh.
Advanced concepts
- Chuẩn bị so sánh với AMM (DeFi) ở tuần sau - order book cần matching engine tích cực, AMM không cần "người khớp lệnh" mà dùng công thức toán học.

Tuần 37 (Ngày 181–185): AMM & DeFi primitives

Ngày 181: Constant Product AMM - toán học đầy đủ

Khái niệm
- x*y=k, chứng minh giá tức thời = đạo hàm của đường cong tại điểm hiện tại, slippage tăng phi tuyến theo kích thước lệnh.
Thực hành và quan sát
- Implement AMM constant-product từ đầu (smart contract), viết script Python tính slippage cho các kích thước swap khác nhau trên cùng 1 pool, vẽ đồ thị.
Advanced concepts
- Constant sum, constant mean (Balancer - trọng số khác nhau cho từng token) - các biến thể AMM khác ngoài constant product.

Ngày 182: Impermanent Loss - chứng minh toán học đầy đủ

Khái niệm
- Công thức IL theo tỷ lệ thay đổi giá IL = 2√(price_ratio)/(1+price_ratio) - 1 - chứng minh từ đầu bằng đại số, không chỉ nhớ công thức.
Thực hành và quan sát
- Tự suy ra công thức IL từ định nghĩa constant product (không tra công thức có sẵn trước), sau đó verify lại bằng script tính số cụ thể với vài kịch bản giá thay đổi.
Advanced concepts
- IL vs phí giao dịch nhận được - khi nào LP thực sự có lời ròng (cần fee thu được > IL), phân tích với dữ liệu pool thật.

Ngày 183: Concentrated Liquidity (Uniswap V3)

Khái niệm
- Thanh khoản tập trung trong 1 khoảng giá (tick range) thay vì trải đều 0→∞ - tăng vốn hiệu quả (capital efficiency) đáng kể nhưng đòi hỏi LP quản lý active hơn.
Thực hành và quan sát
- Đọc whitepaper Uniswap V3 (phần toán học tick/liquidity), vẽ tay sơ đồ 1 pool có nhiều LP position ở các range khác nhau, tính thanh khoản hiệu dụng tại 1 mức giá cụ thể.
Advanced concepts
- JIT liquidity (nhắc lại từ Phần 4 ngày 97) - giờ hiểu rõ cơ chế: LP thêm thanh khoản ngay trước 1 swap lớn, rút ngay sau đó để hưởng phí mà gần như không chịu rủi ro IL dài hạn.

Ngày 184: Lending protocol - interest rate model

Khái niệm
- Utilization-based interest rate model (Aave/Compound): lãi suất tăng phi tuyến khi utilization gần 100% để khuyến khích trả nợ/thêm thanh khoản.
Thực hành và quan sát
- Implement interest rate model từ đầu (kink model - 2 đoạn tuyến tính khác slope), viết script mô phỏng lãi suất theo utilization từ 0-100%.
Advanced concepts
- Liquidation mechanism DeFi: health factor, liquidation bonus, và rủi ro "bad debt" nếu giá giảm quá nhanh không kịp thanh lý (liên hệ oracle manipulation đã học Phần 6).

Ngày 185: Stablecoin mechanism

Khái niệm
- 3 loại: fiat-backed (USDC - cần trust vào reserve/attestation), crypto-collateralized (DAI - overcollateralized, cần liquidation engine), algorithmic (rủi ro cao nhất - cần cơ chế arbitrage giữ peg).
Thực hành và quan sát
- Đọc phân tích kỹ thuật chi tiết vụ sụp đổ UST/Terra (tra cứu report kỹ thuật uy tín), vẽ lại "death spiral" - vòng xoáy giảm giá tự củng cố giữa UST và LUNA.
Advanced concepts
- DAI's Peg Stability Module (PSM) - cơ chế hybrid cho phép swap trực tiếp DAI ↔ USDC tỷ lệ cố định để giữ peg cứng hơn, đánh đổi lấy sự phụ thuộc vào stablecoin tập trung.

Tuần 38 (Ngày 186–190): Oracle, cross-chain, và MEV trong DeFi

Ngày 186: Chainlink architecture chi tiết

Khái niệm
- Decentralized Oracle Network: nhiều node độc lập báo giá, aggregate (thường lấy median) trước khi ghi on-chain, cơ chế deviation threshold + heartbeat để quyết định khi nào update.
Thực hành và quan sát
- Tích hợp Chainlink price feed thật (testnet) vào 1 contract lending đơn giản, viết logic check "staleness" (giá cập nhật quá lâu thì không tin tưởng).
Advanced concepts
- Chainlink CCIP - mở rộng từ price feed sang cross-chain messaging tổng quát, cạnh tranh trực tiếp với các bridge chuyên biệt.

Ngày 187: Cross-chain bridge - mô hình kỹ thuật

Khái niệm
- Lock-mint (khóa token gốc chain A, mint token đại diện chain B) vs burn-mint vs liquidity network (2 pool thanh khoản riêng biệt, không cần mint token mới) - trade-off về trust assumption.
Thực hành và quan sát
- Vẽ sơ đồ chi tiết luồng lock-mint bridge, đánh dấu rõ điểm tin cậy (ai xác nhận sự kiện lock trên chain A để mint trên chain B - multisig, light client, hay oracle).
Advanced concepts
- Light client bridge (dùng ZK proof hoặc BFT signature verify trực tiếp on-chain) - mô hình trustless nhất nhưng chi phí gas cao và phức tạp implement.

Ngày 188: Phân tích vụ hack bridge thật

Khái niệm
- Case study kỹ thuật cụ thể (VD: Ronin Bridge - 5/9 validator signature bị xâm phạm; Wormhole - lỗi xác thực signature trong contract Solana).
Thực hành và quan sát
- Đọc post-mortem kỹ thuật chi tiết của 1 vụ hack bridge, vẽ lại chính xác bước attacker khai thác (không chỉ tóm tắt hời hợt "bridge bị hack").
Advanced concepts
- So sánh rủi ro tập trung hóa: bridge dùng multisig nhỏ (n≤10) có "điểm chết người" (single point of failure) rõ ràng hơn nhiều so với việc tấn công trực tiếp 1 blockchain lớn.

Ngày 189: MEV trong DeFi - arbitrage & liquidation bot

Khái niệm
- Cross-DEX arbitrage (chênh lệch giá giữa 2 pool), liquidation bot (chạy đua thanh lý vị thế dưới ngưỡng an toàn để nhận thưởng).
Thực hành và quan sát
- Viết 1 bot giả lập (chạy trên fork local của mainnet dùng Foundry anvil --fork-url) tự động phát hiện và thực hiện arbitrage giữa 2 pool có giá lệch nhau đã tự tạo.
Advanced concepts
- "MEV supply chain" tổng thể: searcher (tìm cơ hội) → builder (đóng block) → relay → proposer - liên hệ lại toàn bộ kiến thức PBS đã học ở Phần 4.

Ngày 190: Ôn tập Tuần 37-38 + Bài test

Khái niệm
- Tổng hợp AMM, lending, stablecoin, oracle, bridge, MEV trong DeFi.
Thực hành và quan sát
- Bài test: viết báo cáo phân tích rủi ro (risk assessment) cho 1 protocol DeFi thật đang hoạt động (chọn 1 protocol cụ thể, đọc docs + contract on-chain), liệt kê rõ: oracle dependency, bridge dependency (nếu có), centralization point, lịch sử audit.
Advanced concepts
- Đây là kỹ năng trực tiếp áp dụng được cho vai trò "DeFi risk analyst" hoặc để tự đánh giá trước khi gửi vốn vào bất kỳ protocol nào.

Tuần 39 (Ngày 191–195): Governance & DAO

Ngày 191: On-chain governance mechanism

Khái niệm
- Token-weighted voting, quorum requirement, timelock (delay giữa lúc proposal pass và lúc thực thi - cho phép cộng đồng phản ứng nếu proposal độc hại).
Thực hành và quan sát
- Deploy OpenZeppelin Governor contract, tạo 1 proposal test, vote, và execute qua timelock trên testnet.
Advanced concepts
- Quadratic voting - giảm quyền lực của "cá voi" (large holder) bằng cách chi phí vote tăng theo bậc 2 số phiếu, nhưng dễ bị Sybil attack (chia nhỏ token qua nhiều địa chỉ) nếu không có identity layer.

Ngày 192: Governance attack vectors

Khái niệm
- Flash loan governance attack (vay token biểu quyết tạm thời trong 1 block, pass proposal độc hại, trả lại ngay) - và cách phòng chống (snapshot voting power tại block trước khi proposal, không dùng balance real-time).
Thực hành và quan sát
- Đọc phân tích kỹ thuật 1 vụ flash loan governance attack thật (VD: Beanstalk), vẽ lại luồng tấn công.
Advanced concepts
- Vote delegation - cho phép holder ủy quyền vote cho người khác mà không cần chuyển token, tăng tỷ lệ tham gia thực chất.

Ngày 193: Off-chain governance & Snapshot

Khái niệm
- Gasless voting (ký message off-chain, không cần transaction) - dùng cho giai đoạn "temperature check" trước khi đưa proposal quan trọng lên on-chain thật.
Thực hành và quan sát
- Tạo 1 proposal thử trên Snapshot (testnet/sandbox nếu có, hoặc mô phỏng cấu trúc), phân tích cách signature off-chain được lưu trữ và xác minh (thường qua IPFS).
Advanced concepts
- Vì sao off-chain governance không có tính "chấp hành tự động" - cần 1 multisig hoặc cơ chế riêng để thực thi kết quả vote off-chain lên on-chain.

Ngày 194: Thiết kế tokenomics cho dự án giả định

Khái niệm
- Tổng hợp toàn bộ Phần 7: distribution model, vesting schedule, governance rights, utility (fee sharing, staking reward).
Thực hành và quan sát
- Thiết kế đầy đủ tokenomics cho 1 dự án DeFi giả định: bảng phân bổ (team/investor/community/treasury), vesting cliff + linear release, cơ chế governance, viết rationale cho từng quyết định.
Advanced concepts
- Phân tích rủi ro "governance capture" - khi 1 nhóm nhỏ (VC, team) nắm đủ token để chi phối mọi quyết định dù danh nghĩa là "phi tập trung".

Ngày 195: Bài test tổng hợp Phần 7

Khái niệm
- Tổng hợp toàn bộ DeFi, Token Economics, Market Structure.
Thực hành và quan sát
- Bài test lớn: xây dựng 1 mini "DeFi suite" tích hợp - AMM + lending sử dụng LP token làm collateral + governance contract điều chỉnh tham số (fee, interest rate model) - toàn bộ liên kết với nhau, có test đầy đủ.
Advanced concepts
- Chuẩn bị chuyển sang Phần 8 - giờ đã hiểu DeFi ở tầng ứng dụng, tiếp theo sẽ đọc source code thật của các protocol lớn (Uniswap, Aave) để đối chiếu với hiểu biết lý thuyết.

PHẦN 8 - PROTOCOL ENGINEERING: ĐỌC SOURCE CODE CLIENT (Ngày 196–215)

Tuần 40 (Ngày 196–200): Cosmos SDK & ABCI

Ngày 196: Kiến trúc ABCI (Application BlockChain Interface)

Khái niệm
- ABCI tách biệt consensus engine (Tendermint/CometBFT) khỏi application logic - bất kỳ ứng dụng nào implement đúng interface ABCI đều có thể chạy trên Tendermint.
Thực hành và quan sát
- Đọc interface ABCI (CheckTx, DeliverTx/FinalizeBlock, Commit), vẽ sơ đồ luồng 1 transaction đi qua consensus engine rồi tới application.
Advanced concepts
- So sánh kiến trúc "tách rời consensus/execution" này với The Merge của Ethereum (Phần 4 ngày 91) - cùng triết lý modular nhưng cách tiếp cận khác.

Ngày 197: BaseApp - trái tim của Cosmos SDK

Khái niệm
- BaseApp implement ABCI, route transaction tới đúng module qua Msg type, middleware pattern (AnteHandler xử lý fee/signature trước khi vào module logic).
Thực hành và quan sát
- Clone cosmos-sdk, đọc baseapp/baseapp.go, trace luồng 1 transaction từ CheckTx tới DeliverTx.
Advanced concepts
- AnteHandler chain - cách các middleware (check signature, deduct fee, check sequence number) được xâu chuỗi lại, tương tự middleware pattern trong web framework.

Ngày 198: Module & Keeper pattern

Khái niệm
- Mỗi module (bank, staking, gov...) có Keeper riêng quản lý state của module đó - Keeper của module khác chỉ được truy cập qua interface giới hạn (permission control giữa các module).
Thực hành và quan sát
- Đọc module bank (đơn giản nhất, dễ hiểu nhất) trong x/bank/keeper/, trace hàm SendCoins từ đầu tới cuối.
Advanced concepts
- Vì sao thiết kế Keeper giới hạn quyền truy cập chéo module - giảm thiểu rủi ro 1 module lỗi ảnh hưởng module khác (tư duy "least privilege" áp dụng vào kiến trúc blockchain).

Ngày 199: IAVL Tree

Khái niệm
- IAVL (Immutable AVL Tree) - cấu trúc dữ liệu state của Cosmos SDK, khác Merkle Patricia Trie của Ethereum, hỗ trợ versioning (truy vấn state tại block cũ) tự nhiên hơn.
Thực hành và quan sát
- Đọc iavl repo, so sánh cấu trúc node (AVL balancing) với MPT đã học ở Phần 0/4, xác định điểm khác biệt chính (self-balancing binary tree vs radix trie).
Advanced concepts
- Pruning strategy trong IAVL - cách quản lý version cũ để tránh phình to vô hạn (tương tự vấn đề state growth đã học Phần 4).

Ngày 200: Viết 1 module Cosmos SDK tối giản

Khái niệm
- Scaffold 1 module mới: định nghĩa Msg, Keeper, Handler, Genesis cho 1 logic đơn giản (VD: counter tăng dần lưu on-chain).
Thực hành và quan sát
- Dùng ignite scaffold (hoặc viết tay theo cấu trúc chuẩn) tạo 1 module tối giản, chạy chain local, gửi transaction tăng counter qua CLI, verify state cập nhật.
Advanced concepts
- So sánh trải nghiệm viết "module" Cosmos SDK (thay đổi ở tầng protocol/chain) với viết "smart contract" Solidity (chạy trong VM của 1 chain có sẵn) - khác biệt triết lý ứng dụng.

Tuần 41 (Ngày 201–205): IBC & interoperability

Ngày 201: IBC (Inter-Blockchain Communication) nguyên lý

Khái niệm
- Light client verification: chain A xác minh trạng thái chain B bằng cách chạy light client của B ngay trên A (và ngược lại) - không cần bên trung gian tin cậy như bridge truyền thống.
Thực hành và quan sát
- Vẽ sơ đồ luồng IBC packet: gửi từ chain A → light client B verify → relayer chuyển tiếp → chain B nhận và xử lý → gửi acknowledgement ngược lại.
Advanced concepts
- So sánh trust model IBC (trustless, dựa trên light client + validator set) với lock-mint bridge đã học Phần 7 ngày 187 - vì sao IBC được coi là an toàn hơn về mặt lý thuyết nhưng chỉ khả thi giữa các chain có fast finality (Tendermint-based).

Ngày 202: Relayer - vai trò và cơ chế

Khái niệm
- Relayer không cần được tin tưởng (chỉ chuyển tiếp dữ liệu, light client tự verify) nhưng cần được incentivize để đảm bảo liveness (packet không bị "kẹt" mãi mãi).
Thực hành và quan sát
- Đọc kiến trúc hermes (relayer phổ biến), chạy thử kết nối 2 chain local (VD: 2 instance chain scaffold từ ngày 200) qua IBC, gửi 1 token transfer qua kênh IBC.
Advanced concepts
- ICS-20 (Fungible Token Transfer) standard - cách token "đi qua" nhiều chain vẫn giữ được nguồn gốc (denom trace) để tránh double-spend qua nhiều hop.

Ngày 203: Interchain Security & Shared Security

Khái niệm
- Consumer chain "mượn" validator set của Provider chain (Cosmos Hub) thay vì tự xây validator set riêng - giảm rào cản bảo mật cho chain mới.
Thực hành và quan sát
- Đọc tài liệu Interchain Security, vẽ sơ đồ so sánh với mô hình "mỗi chain tự có validator riêng" (sovereign chain).
Advanced concepts
- So sánh với EigenLayer restaking (đã học Phần 5 ngày 129) - cả hai đều là dạng "chia sẻ bảo mật" nhưng cơ chế kỹ thuật khác nhau hoàn toàn (restaking dựa trên Ethereum + AVS, Interchain Security dựa trên Cosmos validator set trực tiếp).

Ngày 204: Solana - kiến trúc tổng quan

Khái niệm
- Sealevel (parallel execution engine), Proof of History (PoH - đồng hồ mật mã học liên tục hash để chứng minh thời gian trôi qua, KHÔNG phải cơ chế đồng thuận độc lập mà bổ trợ cho PoS).
Thực hành và quan sát
- Cài Solana CLI, chạy local validator (solana-test-validator), gửi 1 transaction transfer đơn giản, quan sát tốc độ confirm.
Advanced concepts
- Vì sao Solana đánh đổi decentralization (yêu cầu phần cứng validator cao) lấy throughput - phân tích khách quan trade-off này, không thiên vị theo hướng nào.

Ngày 205: AccountsDB & BankingStage

Khái niệm
- Solana Account model (khác Ethereum: mọi state đều là "account", kể cả program code) - AccountsDB lưu trữ, BankingStage xử lý transaction song song dựa trên account nào transaction đó đọc/ghi (không xung đột → chạy song song).
Thực hành và quan sát
- Đọc source code solana-labs/solana phần banking_stage, xác định cách hệ thống phát hiện 2 transaction có conflict account hay không trước khi quyết định chạy song song hay tuần tự.
Advanced concepts
- PoH Recorder - cách mỗi transaction được "đóng dấu thời gian" liên tục qua chuỗi hash, cho phép validator khác verify thứ tự mà không cần đồng bộ đồng hồ vật lý (liên hệ Logical Clock đã học Phần 1 ngày 20).

Tuần 42 (Ngày 206–210): Substrate & Move VM

Ngày 206: Substrate framework - kiến trúc pallet

Khái niệm
- Substrate (Polkadot's framework): FRAME - hệ thống pallet (module) tương tự Cosmos SDK nhưng dùng Rust + Wasm runtime, cho phép upgrade runtime bằng on-chain governance mà không cần hard fork.
Thực hành và quan sát
- Đọc cấu trúc 1 pallet mẫu (VD: pallet-balances) trong Substrate, so sánh triết lý với module Cosmos SDK đã học tuần trước.
Advanced concepts
- Runtime upgrade "forkless" - cách Substrate cho phép thay đổi logic chain hoàn toàn qua governance vote mà node không cần restart với binary mới (Wasm runtime được lưu on-chain).

Ngày 207: Shared security trong Polkadot - Parachain

Khái niệm
- Relay chain cung cấp bảo mật chung cho các parachain (khác Cosmos - mỗi zone tự bảo mật riêng trừ khi dùng Interchain Security).
Thực hành và quan sát
- Vẽ sơ đồ so sánh 3 mô hình interoperability đã học: Cosmos IBC (sovereign + light client), Polkadot (shared security qua relay chain), Ethereum L2 (rollup, kế thừa bảo mật L1 trực tiếp).
Advanced concepts
- XCM (Cross-Consensus Messaging) - giao thức nhắn tin giữa parachain, khác biệt kỹ thuật so với IBC packet.

Ngày 208: Move VM - tư duy resource-oriented

Khái niệm
- Move (Aptos/Sui): tài sản là "resource" - kiểu dữ liệu đặc biệt không thể copy, không thể bị bỏ quên (compiler ép buộc phải "di chuyển" hoặc "hủy" tường minh) - chống lỗi kinh điển như double-spend do lập trình sai ở tầng ngôn ngữ.
Thực hành và quan sát
- Cài Move CLI (Aptos hoặc Sui), viết 1 module Move đơn giản định nghĩa 1 resource (VD: Coin tối giản), thử cố tình "copy" resource và quan sát compiler báo lỗi.
Advanced concepts
- So sánh triết lý an toàn: Solidity dựa vào lập trình viên cẩn thận + tool kiểm tra bên ngoài (Slither...), Move dựa vào type system ép buộc an toàn ngay từ ngôn ngữ - trade-off linh hoạt vs an toàn mặc định.

Ngày 209: Sui object model & parallel execution

Khái niệm
- Sui: object-centric model (khác account-centric) - mỗi object có owner rõ ràng, giao dịch chỉ động tới object độc lập được xử lý song song mà không cần consensus toàn cục (fast-path).
Thực hành và quan sát
- Đọc tài liệu kiến trúc Sui, vẽ sơ đồ so sánh với Sealevel của Solana (Sui: song song ở tầng object ownership; Solana: song song ở tầng account access pattern).
Advanced concepts
- Causal order vs total order - Sui chỉ cần causal order cho giao dịch object độc lập (không cần biết thứ tự tuyệt đối toàn hệ thống), giảm gánh nặng consensus đáng kể cho use-case đơn giản.

Ngày 210: Ôn tập Tuần 40-42 + Bài test

Khái niệm
- Tổng hợp: ABCI/Cosmos SDK, IBC, Solana Sealevel/PoH, Substrate/Polkadot, Move VM/Sui.
Thực hành và quan sát
- Bài test: viết bảng so sánh toàn diện 6 kiến trúc đã học (Ethereum, Bitcoin, Cosmos, Solana, Polkadot, Move-based) theo 6 tiêu chí (execution model, state model, consensus, interoperability approach, ngôn ngữ smart contract, trade-off chính) - dựa hoàn toàn trên những gì đã tự đọc code, không chép lại từ tài liệu marketing.
Advanced concepts
- Đây là bảng kiến thức cực kỳ giá trị cho vai trò "Protocol Engineer" hoặc "Blockchain Architect" - nên giữ lại và cập nhật liên tục khi có kiến trúc mới xuất hiện.

Tuần 43 (Ngày 211–215): Kỹ năng đọc code & đóng góp thực tế

Ngày 211: Kỹ thuật debug distributed system

Khái niệm
- Distributed tracing, structured logging - khó khăn đặc thù khi debug hệ thống nhiều node (không thể "step through" như debug 1 process đơn).
Thực hành và quan sát
- Setup logging có cấu trúc (JSON log) cho 1 trong các node/chain local đã chạy trước đó (Cosmos scaffold hoặc Solana test validator), dùng log để trace 1 vấn đề giả lập (VD: cố tình gây lỗi rồi tìm nguyên nhân qua log).
Advanced concepts
- Chaos engineering cơ bản - cố tình gây fault (kill node, delay network bằng tc command trên Linux) để quan sát hệ thống phản ứng ra sao, đối chiếu với lý thuyết consensus đã học.

Ngày 212: Đọc và hiểu 1 CVE/security advisory thật

Khái niệm
- Cấu trúc security advisory: mô tả lỗ hổng, phiên bản ảnh hưởng, patch - cách đọc changelog để hiểu bản chất kỹ thuật lỗi đã fix.
Thực hành và quan sát
- Chọn 1 security advisory thật của go-ethereum, Cosmos SDK, hoặc Solana (tra cứu GitHub Security Advisories), đọc commit fix, giải thích lỗi gốc là gì và patch giải quyết như thế nào.
Advanced concepts
- Nhiều lỗ hổng nghiêm trọng nhất trong lịch sử blockchain không nằm ở smart contract mà ở tầng client/protocol (VD: lỗi trong chính go-ethereum hay Bitcoin Core) - mở rộng tư duy audit ra ngoài phạm vi smart contract.

Ngày 213: Đóng góp mã nguồn mở - bước đầu

Khái niệm
- Quy trình contribute: tìm "good first issue", đọc CONTRIBUTING.md, viết PR nhỏ, quy trình review.
Thực hành và quan sát
- Tìm 1 issue nhỏ (docs fix, test coverage, hoặc bug nhỏ) trong 1 repo blockchain client đã học (go-ethereum, cosmos-sdk, hoặc 1 dự án vệ tinh nhỏ hơn dễ tiếp cận hơn), gửi PR thật.
Advanced concepts
- Đóng góp mã nguồn mở thành công là 1 trong những minh chứng năng lực mạnh nhất khi ứng tuyển vị trí Protocol Engineer - nên duy trì thói quen này xuyên suốt phần còn lại của khóa học.

Ngày 214: Benchmark & profiling hiệu năng

Khái niệm
- CPU profiling (pprof cho Go, perf/flamegraph cho Rust) - tìm bottleneck thực sự thay vì đoán mò khi tối ưu hiệu năng client.
Thực hành và quan sát
- Chạy profiler trên 1 trong các chương trình tự viết trước đó (VD: mini EVM interpreter Phần 4, hoặc matching engine Phần 7), tìm hàm tốn CPU nhiều nhất, thử tối ưu và đo lại.
Advanced concepts
- So sánh với benchmark công khai của các client thật (VD: so sánh throughput reth vs geth) - hiểu tại sao 1 số client mới viết lại bằng Rust đạt hiệu năng cao hơn đáng kể.

Ngày 215: Bài test tổng hợp Phần 8

Khái niệm
- Tổng hợp toàn bộ Protocol Engineering.
Thực hành và quan sát
- Bài test: viết 1 bài "deep dive" kỹ thuật (3-5 trang) về 1 phần cụ thể của 1 client thật mà bạn đã đọc trong suốt Phần 3-4-8 (VD: "Cách go-ethereum xử lý reorg trong fork choice" hoặc "Cách Solana BankingStage xử lý transaction song song") - bao gồm trích dẫn cụ thể tên hàm/file, không viết chung chung.
Advanced concepts
- Đây là kỹ năng viết đúng chất "Protocol Engineer" - công khai bài viết này (blog cá nhân, Mirror, hoặc forum kỹ thuật) là bước xây dựng portfolio rất giá trị.

PHẦN 9 - LAYER-1 DEVELOPMENT: TỰ XÂY BLOCKCHAIN (Ngày 216–240)

Tuần 44 (Ngày 216–220): Xây blockchain từ đầu bằng Rust (không dùng framework)

Ngày 216: Thiết kế kiến trúc tổng thể

Khái niệm
- Trước khi code, thiết kế trên giấy: block structure, transaction format, state model (chọn account-based cho đơn giản), consensus (chọn PoA - Proof of Authority đơn giản làm điểm khởi đầu, không phải PoW/PoS phức tạp).
Thực hành và quan sát
- Viết document thiết kế (1-2 trang) cho blockchain riêng của bạn: đặt tên, định nghĩa rõ block header fields, transaction fields, state model.
Advanced concepts
- Quyết định trade-off ngay từ đầu: ưu tiên đơn giản/dễ hiểu (giai đoạn học) hay ưu tiên hiệu năng - chọn đơn giản, có thể tối ưu sau.

Ngày 217: Implement block & transaction structure

Khái niệm
- Áp dụng lại toàn bộ kiến thức Phần 0 (Merkle Tree, RLP-like serialization) vào thiết kế thật.
Thực hành và quan sát
- Code struct Block, Transaction, BlockHeader bằng Rust, implement serialize/deserialize, tính block hash.
Advanced concepts
- Versioning ngay từ đầu (field version trong header) - thói quen tốt để sau này có thể hard fork/soft fork mà không phá vỡ block cũ.

Ngày 218: State management với account model

Khái niệm
- Implement state store dùng HashMap trong bước đầu (chưa cần trie thật), áp dụng kiến thức nonce/balance từ Phần 4.
Thực hành và quan sát
- Code State struct quản lý account (balance, nonce), viết hàm apply_transaction(state, tx) -> Result<State> với đầy đủ validate (nonce đúng, đủ balance).
Advanced concepts
- Chuẩn bị sẵn interface để sau này thay HashMap bằng MPT thật (đã implement ở Phần 0) mà không cần sửa logic transaction xử lý.

Ngày 219: Mempool & transaction pool

Khái niệm
- Implement mempool cơ bản: nhận transaction, validate sơ bộ (signature, nonce hợp lý), sắp xếp theo fee (áp dụng lại lý thuyết Phần 4 ngày 96).
Thực hành và quan sát
- Code Mempool struct, hàm add_transaction, get_pending_transactions_sorted_by_fee.
Advanced concepts
- Giới hạn kích thước mempool và eviction policy khi đầy (loại bỏ transaction fee thấp nhất trước).

Ngày 220: Block production (PoA đơn giản)

Khái niệm
- Proof of Authority: 1 tập hợp cố định "authority" node được phép tạo block theo round-robin, đơn giản nhất để bắt đầu (không cần mining/staking phức tạp).
Thực hành và quan sát
- Implement block producer: lấy transaction từ mempool, apply vào state, tạo block mới, ký bằng private key của authority (dùng ECDSA đã implement Phần 2).
Advanced concepts
- Ghi chú rõ: PoA hy sinh hoàn toàn decentralization - chỉ dùng cho mục đích học, không phải thiết kế production thật.

Tuần 45 (Ngày 221–225): Networking & P2P thật

Ngày 221: Thiết kế giao thức P2P riêng

Khái niệm
- Message type cần có: NewBlock, NewTransaction, GetBlocks, Blocks - thiết kế đơn giản dựa trên TCP.
Thực hành và quan sát
- Viết document đặc tả giao thức P2P của bạn (message format, cách handshake giữa 2 node).
Advanced concepts
- So sánh thiết kế của bạn với devp2p (Ethereum) đã đọc ở Phần 4 - bạn thiếu gì so với thiết kế thật (VD: không có peer discovery, không có version negotiation).

Ngày 222: Implement TCP networking layer

Khái niệm
- Async networking bằng Tokio (Rust) - xử lý nhiều kết nối đồng thời không chặn (non-blocking I/O).
Thực hành và quan sát
- Code TCP server/client bằng Tokio, implement message framing (length-prefixed) để gửi/nhận message có cấu trúc qua TCP stream.
Advanced concepts
- Backpressure handling - điều gì xảy ra nếu 1 peer gửi dữ liệu nhanh hơn khả năng xử lý của node bạn, làm sao tránh memory blow-up.

Ngày 223: Gossip protocol cho block/transaction propagation

Khái niệm
- Flood gossip đơn giản: nhận message mới → broadcast cho tất cả peer khác (trừ peer gửi tới) - áp dụng kiến thức Phần 2 (Phần 1 cũ) về gossip.
Thực hành và quan sát
- Implement gossip cho NewTransaction và NewBlock, test với 4-5 node local, gửi 1 transaction từ 1 node, verify tất cả node khác nhận được.
Advanced concepts
- Duplicate message suppression (dùng bloom filter hoặc set các message ID đã thấy) - tránh gossip storm vô hạn.

Ngày 224: Chain synchronization

Khái niệm
- Node mới join mạng cần đồng bộ toàn bộ lịch sử block - implement GetBlocks/Blocks request-response.
Thực hành và quan sát
- Implement sync protocol: node mới kết nối, request block từ genesis tới hiện tại từ peer, verify từng block trước khi apply.
Advanced concepts
- Xử lý trường hợp 2 node có nhánh khác nhau (fork) khi sync - áp dụng fork choice rule đơn giản (longest chain, vì PoA nên không cần LMD-GHOST phức tạp).

Ngày 225: Ôn tập Tuần 44-45 + Test toàn hệ thống

Khái niệm
- Tổng hợp: block/state/mempool, networking, gossip, sync.
Thực hành và quan sát
- Bài test: chạy 5 node blockchain tự viết trên máy local (hoặc 5 Docker container riêng biệt), gửi transaction từ 1 node, verify toàn bộ mạng đồng bộ đúng trạng thái sau vài block.
Advanced concepts
- Đo thời gian propagation trung bình 1 block/transaction lan tới toàn mạng - bắt đầu có tư duy đo đạc hiệu năng thực tế thay vì chỉ "chạy được là xong".

Tuần 46 (Ngày 226–230): Thêm smart contract layer & consensus

Ngày 226: Thiết kế VM tối giản cho blockchain riêng

Khái niệm
- Tái sử dụng mini EVM interpreter đã viết ở Phần 4, tích hợp vào blockchain riêng làm execution layer cho "smart contract".
Thực hành và quan sát
- Tích hợp interpreter (đã viết Phần 4 tuần 18) vào state transition function của blockchain riêng - transaction giờ có thể là "deploy contract" hoặc "call contract".
Advanced concepts
- Gas metering thật cho blockchain riêng - quyết định gas limit per block, gas price tối thiểu.

Ngày 227: Nâng cấp consensus - từ PoA sang PoS đơn giản

Khái niệm
- Thêm khái niệm "stake" - validator phải khóa 1 lượng token native để được quyền tạo block, chọn proposer theo trọng số stake (áp dụng lý thuyết Phần 4 ngày 92).
Thực hành và quan sát
- Thêm transaction type Stake/Unstake, cập nhật logic chọn block producer dựa trên stake weight thay vì round-robin cố định.
Advanced concepts
- Implement slashing đơn giản: nếu 1 validator ký 2 block khác nhau cùng height (double-sign, áp dụng kiến thức Phần 4 ngày 94), trừ 1 phần stake của họ.

Ngày 228: Finality gadget đơn giản

Khái niệm
- Thêm cơ chế voting sau khi block được đề xuất (áp dụng lại Tendermint 3-phase đã implement ở Phần 1 ngày 28) - block chỉ "final" khi ≥2/3 validator vote.
Thực hành và quan sát
- Tích hợp lại code Tendermint-style BFT đã viết ở Phần 1 vào blockchain riêng, thay thế fork choice rule đơn giản bằng finality thật.
Advanced concepts
- Đo thời gian tới finality với số lượng validator khác nhau (4, 10, 20 node) - quan sát overhead tăng theo O(n²) message của BFT classic.

Ngày 229: Light client cho blockchain riêng

Khái niệm
- Thiết kế light client: chỉ cần lưu block header + validator set, verify finality bằng cách check đủ 2/3 chữ ký thay vì tải toàn bộ block.
Thực hành và quan sát
- Implement 1 light client tối giản: kết nối tới full node, nhận block header + tập chữ ký, tự verify đủ điều kiện 2/3 mà không cần tin tưởng full node hoàn toàn.
Advanced concepts
- So sánh với weak subjectivity (Phần 4 ngày 34) - light client mới join cần 1 checkpoint đáng tin cậy ban đầu (không thể tự verify từ genesis chỉ bằng header).

Ngày 230: Ôn tập Tuần 46 + Bài test

Khái niệm
- Tổng hợp: VM tích hợp, PoS, finality gadget, light client.
Thực hành và quan sát
- Bài test: chạy mạng 7 validator, deploy 1 "smart contract" đơn giản (VD: token transfer) qua VM tích hợp, thực hiện double-sign cố ý từ 1 validator, verify slashing hoạt động đúng.
Advanced concepts
- Viết báo cáo so sánh blockchain tự xây với 1 chain thật tương tự nhất (VD: Tendermint-based chain đơn giản) - liệt kê rõ những gì đã thiếu so với production thật.

Tuần 47 (Ngày 231–235): SDK approach - Cosmos SDK & Substrate

Ngày 231: Xây appchain bằng Cosmos SDK - thiết kế

Khái niệm
- So với tự viết từ đầu (tuần 44-46), Cosmos SDK cho tốc độ phát triển nhanh hơn nhiều nhờ có sẵn module chuẩn (bank, staking, gov, IBC).
Thực hành và quan sát
- Thiết kế 1 appchain use-case cụ thể (VD: chain quản lý carbon credit, hoặc chain settlement cho 1 mạng lưới thanh toán giả định) - chọn module cần dùng, thiết kế module custom cần viết thêm.
Advanced concepts
- Quyết định "xây appchain riêng" vs "deploy smart contract trên chain có sẵn" - trade-off thực tế (toàn quyền kiểm soát + tối ưu riêng vs chi phí vận hành + bootstrap validator set).

Ngày 232: Implement module custom trên Cosmos SDK

Khái niệm
- Áp dụng kiến thức Keeper/Msg/Handler đã học Phần 8, viết module thật cho use-case đã thiết kế.
Thực hành và quan sát
- Code module custom hoàn chỉnh (Msg type, Keeper logic, Genesis state), tích hợp với module bank có sẵn (VD: logic mint token thưởng khi 1 hành động xảy ra).
Advanced concepts
- Viết CLI command và gRPC query cho module - trải nghiệm đầy đủ như 1 chain thật (không chỉ logic on-chain mà cả tooling truy vấn).

Ngày 233: Testnet & validator onboarding

Khái niệm
- Genesis file, validator set khởi tạo, cách mời thêm validator tham gia qua transaction MsgCreateValidator.
Thực hành và quan sát
- Khởi tạo testnet 4 node cho appchain tự viết, thêm 1 validator mới vào mạng đang chạy (không phải từ genesis), verify hoạt động bình thường.
Advanced concepts
- Chain upgrade - thực hiện 1 lần "software upgrade" có coordinate (halt height, tất cả validator cùng nâng cấp binary tại 1 block cụ thể) - mô phỏng quy trình hard fork có kế hoạch.

Ngày 234: Substrate - xây parachain tối giản (nếu chọn hướng Polkadot)

Khái niệm
- So với Cosmos SDK (Go), Substrate dùng Rust + Wasm, phù hợp nếu định hướng ecosystem Polkadot.
Thực hành và quan sát
- Scaffold 1 Substrate node tối giản (dùng template có sẵn), thêm 1 pallet custom đơn giản, chạy local network.
Advanced concepts
- So sánh trải nghiệm dev thực tế giữa Cosmos SDK module và Substrate pallet - cả 2 đều là dạng "app-specific blockchain SDK" nhưng ngôn ngữ và triết lý runtime khác nhau.

Ngày 235: Ôn tập Tuần 47 + Bài test

Khái niệm
- Tổng hợp trải nghiệm xây appchain bằng SDK (Cosmos) so với tự viết từ đầu (tuần 44-46).
Thực hành và quan sát
- Bài test: viết báo cáo so sánh 2 cách tiếp cận (tự viết vs dùng SDK) theo các tiêu chí: tốc độ phát triển, mức độ kiểm soát, độ trưởng thành tooling, rủi ro bảo mật (SDK đã được audit rộng rãi vs code tự viết chưa qua kiểm định).
Advanced concepts
- Đưa ra khuyến nghị (dựa trên trải nghiệm thật của chính bạn) cho 1 team startup thật sự cần build appchain - khi nào nên tự viết, khi nào nên dùng SDK có sẵn.

Tuần 48 (Ngày 236–240): Hoàn thiện & benchmark blockchain tự xây

Ngày 236: Load testing

Khái niệm
- Throughput (TPS), latency (thời gian từ submit tới finalize) - cách đo đạc có phương pháp thay vì cảm tính.
Thực hành và quan sát
- Viết script gửi hàng loạt transaction đồng thời tới blockchain tự xây (tuần 44-46) và appchain SDK (tuần 47), đo TPS thực tế và latency trung bình/p99.
Advanced concepts
- Xác định bottleneck: là network (gossip), là execution (VM), hay là consensus (BFT voting round) - dùng profiling đã học Phần 8 ngày 214.

Ngày 237: Security review cho blockchain tự xây

Khái niệm
- Áp dụng checklist audit (Phần 6 ngày 167) nhưng ở tầng protocol thay vì smart contract: DoS vector, resource exhaustion, consensus edge case.
Thực hành và quan sát
- Tự review toàn bộ code blockchain đã viết, liệt kê ít nhất 5 rủi ro bảo mật thực tế (VD: mempool không giới hạn kích thước dẫn tới OOM, thiếu rate-limit kết nối P2P dẫn tới Sybil dễ dàng).
Advanced concepts
- So sánh với các CVE thật đã đọc ở Phần 8 ngày 212 - tìm điểm tương đồng giữa lỗi bạn tự tìm ra và lỗi thật đã xảy ra trong lịch sử.

Ngày 238: Documentation & runbook

Khái niệm
- Viết tài liệu vận hành cho blockchain tự xây: cách chạy node, cách join validator set, cách xử lý sự cố cơ bản (node bị fork khỏi mạng).
Thực hành và quan sát
- Viết README + runbook đầy đủ, đủ chi tiết để 1 người khác (không phải bạn) có thể tự chạy được node từ đầu chỉ dựa vào tài liệu.
Advanced concepts
- Đây là kỹ năng bị đánh giá thấp nhưng cực kỳ quan trọng trong công việc thật - nhiều dự án blockchain thất bại một phần vì thiếu tài liệu vận hành tốt cho node operator/validator bên ngoài.

Ngày 239: Retrospective toàn diện

Khái niệm
- Nhìn lại toàn bộ hành trình Phần 9: từ thiết kế giấy → tự viết từ đầu → dùng SDK → benchmark → security review.
Thực hành và quan sát
- Viết retrospective (1-2 trang): quyết định thiết kế nào đúng, quyết định nào sai/cần sửa nếu làm lại, bài học lớn nhất.
Advanced concepts
- So sánh source code cuối cùng của bạn với 1 L1 thật đơn giản, mã nguồn mở, dễ đọc (VD: 1 chain nhỏ dựa Tendermint) - đọc và ghi chú điểm khác biệt lớn nhất.

Ngày 240: Bài test tổng hợp Phần 9

Khái niệm
- Tổng hợp toàn bộ Layer-1 Development.
Thực hành và quan sát
- Bài test lớn cuối phần: hoàn thiện blockchain tự xây (hoặc appchain SDK) thành trạng thái "demo-able" - có thể chạy live demo 5 phút: khởi động mạng, gửi giao dịch, deploy 1 contract đơn giản, thực hiện 1 kịch bản slashing, dừng và khởi động lại node (verify recovery đúng).
Advanced concepts
- Đây là dự án có thể đưa thẳng vào portfolio/CV cho vị trí Blockchain Protocol Engineer - nên push code lên GitHub công khai kèm README chất lượng đã viết ngày 238.

PHẦN 10 - FINTECH SYSTEMS CHUYÊN SÂU (Ngày 241–275)

Tuần 49 (Ngày 241–245): Ledger Engineering

Ngày 241: Double-entry bookkeeping - nền tảng toán học

Khái niệm
- Mỗi giao dịch ghi ít nhất 2 bút toán (debit/credit), tổng debit luôn bằng tổng credit - bất biến (invariant) này là nền tảng phát hiện sai sót/gian lận.
Thực hành và quan sát
- Thiết kế schema database cho ledger double-entry: bảng accounts, journal_entries, journal_lines (mỗi dòng có account_id, debit/credit amount) - viết constraint đảm bảo tổng debit = tổng credit trong 1 journal entry.
Advanced concepts
- Chart of Accounts - cách phân loại account chuẩn (Asset/Liability/Equity/Revenue/Expense) và quy tắc debit/credit tăng/giảm khác nhau theo từng loại.

Ngày 242: Atomicity & consistency trong ledger transaction

Khái niệm
- Áp dụng ACID (đặc biệt Atomicity) - 1 transfer giữa 2 account phải là 1 database transaction duy nhất, không được phép chỉ trừ mà không cộng (hoặc ngược lại).
Thực hành và quan sát
- Implement hàm transfer(from, to, amount) dùng database transaction thật (PostgreSQL), test bằng cách cố tình gây lỗi giữa chừng (throw exception sau khi debit nhưng trước khi credit), verify rollback đúng.
Advanced concepts
- Isolation level (Read Committed vs Serializable) - rủi ro race condition khi 2 transfer đồng thời cùng đọc balance 1 account (lost update problem).

Ngày 243: Idempotency trong hệ thống thanh toán

Khái niệm
- Idempotency key: đảm bảo 1 request gửi lặp lại (do network timeout, client retry) không tạo ra 2 giao dịch trùng lặp.
Thực hành và quan sát
- Implement idempotent payment API: dùng bảng riêng lưu idempotency_key + unique constraint database, nếu key đã tồn tại thì trả lại kết quả cũ thay vì xử lý lại.
Advanced concepts
- Trường hợp race condition: 2 request cùng idempotency key gửi đồng thời (trước khi request đầu hoàn tất) - cần cơ chế lock hoặc "processing" state để xử lý đúng.

Ngày 244: Event Sourcing cho ledger

Khái niệm
- Thay vì chỉ lưu balance hiện tại, lưu toàn bộ chuỗi event (mỗi giao dịch là 1 event bất biến) - balance là kết quả tính toán (replay) từ toàn bộ event, cho phép audit trail hoàn chỉnh và debug lịch sử.
Thực hành và quan sát
- Refactor ledger ngày 241-242 sang event sourcing: bảng events append-only, viết hàm "replay" tính lại balance từ đầu, verify khớp với balance đang lưu cache.
Advanced concepts
- CQRS (Command Query Responsibility Segregation) - tách write model (event store) khỏi read model (balance view được tối ưu cho truy vấn nhanh), đồng bộ qua projection.

Ngày 245: Reconciliation engine

Khái niệm
- Đối soát (reconciliation): so khớp dữ liệu giữa 2 hệ thống độc lập (VD: ledger nội bộ vs sao kê ngân hàng đối tác) để phát hiện sai lệch.
Thực hành và quan sát
- Viết 1 reconciliation script: cho 2 tập dữ liệu giao dịch giả lập (có cố ý tạo vài sai lệch), viết logic match theo reference ID + amount, output báo cáo các giao dịch không khớp.
Advanced concepts
- Reconciliation ở quy mô lớn (triệu giao dịch/ngày) cần thuật toán matching hiệu quả (không phải O(n²) so khớp từng cặp) - dùng hash/index theo reference ID.

Tuần 50 (Ngày 246–250): Payment Rails chuẩn công nghiệp

Ngày 246: ISO 8583 - chuẩn giao dịch thẻ

Khái niệm
- Message format dạng bitmap (xác định field nào có mặt) + field value - chuẩn dùng trong giao dịch thẻ (ATM, POS) từ thập niên 1980s tới nay vẫn phổ biến.
Thực hành và quan sát
- Đọc cấu trúc 1 message ISO 8583 mẫu (MTI - Message Type Indicator, bitmap, data element), thử decode tay 1 ví dụ authorization request đơn giản.
Advanced concepts
- MTI phân loại: 0100 (authorization request), 0110 (response), 0200 (financial request)... - hiểu ý nghĩa từng nhóm số.

Ngày 247: Card authorization flow - acquirer/issuer/network

Khái niệm
- Luồng đầy đủ: merchant → acquirer → card network (Visa/Mastercard) → issuer bank → phản hồi ngược lại - mỗi bên có vai trò rõ ràng.
Thực hành và quan sát
- Vẽ sơ đồ chi tiết luồng 1 giao dịch thẻ từ lúc quẹt thẻ tại POS tới lúc merchant nhận approval, đánh dấu rõ ISO 8583 message trao đổi ở mỗi bước.
Advanced concepts
- Interchange fee - cơ chế phân chia phí giữa acquirer/issuer/network, và vì sao đây là nguồn thu chính của mô hình 4-party card network.

Ngày 248: EMV chip & tokenization

Khái niệm
- EMV (Europay-Mastercard-Visa) chip: mỗi giao dịch sinh cryptogram động (khác dữ liệu tĩnh trên dải từ) - chống sao chép thẻ (cloning).
- Tokenization: thay số thẻ thật bằng token (dùng trong Apple Pay/Google Pay) - số thẻ thật không bao giờ rời khỏi hệ thống phát hành/network.
Thực hành và quan sát
- Đọc tài liệu kỹ thuật EMV tổng quan, vẽ sơ đồ so sánh giao dịch dải từ (static data, dễ giả mạo) vs chip (dynamic cryptogram) vs tokenized mobile payment.
Advanced concepts
- PCI-DSS - chuẩn bảo mật bắt buộc khi xử lý dữ liệu thẻ, tại sao tokenization giúp giảm đáng kể phạm vi hệ thống phải tuân thủ PCI-DSS đầy đủ (giảm "scope").

Ngày 249: ISO 20022 - chuẩn thế hệ mới

Khái niệm
- XML/JSON-based, structured data richer hơn ISO 8583 nhiều - đang dần thay thế SWIFT MT message truyền thống cho thanh toán quốc tế.
Thực hành và quan sát
- So sánh 1 message SWIFT MT103 (chuyển tiền quốc tế, format cũ) với message ISO 20022 tương đương (pacs.008) - chỉ ra điểm khác biệt về structured data.
Advanced concepts
- Vì sao migration sang ISO 20022 là 1 sự kiện lớn của ngành ngân hàng toàn cầu (deadline migration của SWIFT) - dữ liệu structured hơn giúp AML/compliance tốt hơn đáng kể.

Ngày 250: Real-time payment systems

Khái niệm
- ACH (batch, chậm, rẻ) vs Wire/Fedwire (real-time, đắt hơn) vs FedNow/RTP (real-time, chi phí thấp, ra đời để cạnh tranh) vs SEPA Instant (châu Âu).
Thực hành và quan sát
- Lập bảng so sánh 5 hệ thống thanh toán trên theo: tốc độ settlement, chi phí, giới hạn giá trị giao dịch, khả năng đảo ngược (reversibility).
Advanced concepts
- So sánh trực tiếp với blockchain settlement (Ethereum/stablecoin) theo cùng các tiêu chí - đây chính là nơi "giá trị thực" của blockchain trong fintech được thể hiện rõ nhất (hoặc bị thổi phồng, cần đánh giá khách quan).

Tuần 51 (Ngày 251–255): Core Banking & Open Banking

Ngày 251: Core banking system architecture

Khái niệm
- Kiến trúc hệ thống ngân hàng lõi: account management, transaction processing engine, interest accrual engine - thường vẫn chạy trên mainframe/hệ thống cũ (legacy) ở nhiều ngân hàng lớn.
Thực hành và quan sát
- Vẽ sơ đồ kiến trúc core banking hiện đại (dùng ledger event sourcing đã học tuần 49) cho 1 sản phẩm ngân hàng số giả định.
Advanced concepts
- Vì sao migration core banking cũ (COBOL trên mainframe) sang hệ thống mới cực kỳ rủi ro và tốn kém - nhiều ngân hàng chọn "wrap" API hiện đại quanh core cũ thay vì thay thế hoàn toàn.

Ngày 252: Interest calculation engine

Khái niệm
- Simple interest vs compound interest, day-count convention (Actual/365, 30/360...) - sự khác biệt nhỏ trong quy ước tính ngày có thể tạo chênh lệch đáng kể ở quy mô lớn.
Thực hành và quan sát
- Implement hàm tính lãi tiết kiệm theo 2 day-count convention khác nhau cho cùng 1 khoản tiền/kỳ hạn, so sánh kết quả.
Advanced concepts
- Accrual accounting cho lãi - lãi được "dồn tích" (accrue) hàng ngày trong ledger dù chưa thực sự trả cho khách hàng, ảnh hưởng tới báo cáo tài chính.

Ngày 253: KYC/AML - quy trình thực tế

Khái niệm
- KYC (Know Your Customer): xác minh danh tính khi onboarding; AML (Anti-Money Laundering): giám sát giao dịch liên tục để phát hiện rửa tiền.
Thực hành và quan sát
- Thiết kế luồng KYC cho 1 sản phẩm fintech giả định: document upload → identity verification → risk scoring → approve/reject/manual review.
Advanced concepts
- Risk-based approach (RBA) - mức độ KYC (simplified/standard/enhanced due diligence) tùy theo mức rủi ro của khách hàng, không áp dụng 1 quy trình cứng cho mọi trường hợp.

Ngày 254: Sanction screening & transaction monitoring

Khái niệm
- Sanction list screening (OFAC, UN, EU list) - check tên/entity với danh sách trừng phạt; transaction monitoring - rule-based hoặc ML-based phát hiện pattern đáng ngờ (structuring, rapid movement...).
Thực hành và quan sát
- Implement 1 fuzzy-matching đơn giản (Levenshtein distance) để screen tên khách hàng với 1 danh sách tên mẫu, xử lý trường hợp tên gần giống (không chỉ exact match).
Advanced concepts
- False positive rate cao là vấn đề thực tế lớn nhất của sanction screening - cân bằng giữa bỏ sót (rủi ro pháp lý) và quá nhiều false positive (chặn nhầm khách hàng hợp lệ, tốn nhân lực review).

Ngày 255: Open Banking & PSD2

Khái niệm
- PSD2 (EU): bắt buộc ngân hàng mở API cho bên thứ 3 (với sự đồng ý khách hàng) - AISP (Account Information Service Provider) và PISP (Payment Initiation Service Provider).
Thực hành và quan sát
- Đọc tài liệu kỹ thuật Open Banking API chuẩn (UK Open Banking hoặc Berlin Group NextGenPSD2), thiết kế luồng OAuth-based consent flow cho 1 ứng dụng bên thứ 3 truy cập dữ liệu tài khoản.
Advanced concepts
- SCA (Strong Customer Authentication) - yêu cầu 2-factor bắt buộc theo PSD2, và exemption trong 1 số trường hợp (giao dịch giá trị nhỏ, recurring payment đã whitelist).

Tuần 52 (Ngày 256–260): Risk Systems & Fraud Detection

Ngày 256: Fraud detection - rule-based approach

Khái niệm
- Rule engine: velocity check (quá nhiều giao dịch trong thời gian ngắn), geolocation mismatch, device fingerprint bất thường.
Thực hành và quan sát
- Implement 1 rule engine đơn giản: cho 1 chuỗi giao dịch giả lập, viết 3-5 rule phát hiện fraud cơ bản (VD: >5 giao dịch/phút, giao dịch từ 2 quốc gia cách xa nhau trong thời gian ngắn), output alert.
Advanced concepts
- Rule-based dễ giải thích (explainable) nhưng dễ bị "học" và lách luật bởi kẻ gian tinh vi - động lực chuyển sang ML-based detection.

Ngày 257: Fraud detection - ML approach (khái niệm, không cần chuyên sâu ML)

Khái niệm
- Feature engineering cho fraud (transaction amount, time-of-day, merchant category, historical behavior), imbalanced dataset problem (fraud cực hiếm so với giao dịch hợp lệ).
Thực hành và quan sát
- Dùng 1 dataset fraud detection công khai (VD: dataset Kaggle credit card fraud), train 1 model đơn giản (logistic regression hoặc random forest) bằng thư viện có sẵn, đánh giá bằng precision/recall (không dùng accuracy vì dataset mất cân bằng nặng).
Advanced concepts
- Trade-off precision/recall trong fraud: recall cao (bắt được nhiều fraud) thường đi kèm false positive cao (chặn nhầm khách hàng thật) - quyết định ngưỡng phụ thuộc chi phí kinh doanh cụ thể.

Ngày 258: Credit risk & scoring

Khái niệm
- Credit scoring model cơ bản: các yếu tố đầu vào phổ biến (lịch sử thanh toán, tỷ lệ nợ/thu nhập, thời gian tín dụng) - quy định fairness/không phân biệt đối xử trong scoring.
Thực hành và quan sát
- Thiết kế 1 scorecard đơn giản (weighted sum các yếu tố) cho use-case cho vay tiêu dùng giả định, giải thích rationale từng trọng số.
Advanced concepts
- Model explainability trong credit scoring - nhiều thị trường yêu cầu pháp lý phải giải thích được lý do từ chối cho vay (không thể dùng "black box" model hoàn toàn mà không có cách giải thích).

Ngày 259: Real-time risk decisioning architecture

Khái niệm
- Kiến trúc hệ thống quyết định real-time (latency thấp, thường <100ms) cho fraud/risk check trước khi approve giao dịch - cần cân bằng độ chính xác và tốc độ.
Thực hành và quan sát
- Vẽ sơ đồ kiến trúc: transaction request → feature lookup (cache, không query DB chậm real-time) → rule engine + ML model → decision → log để retrain sau.
Advanced concepts
- Feature store - hệ thống lưu trữ feature đã tính sẵn (pre-computed) để tra cứu real-time cực nhanh, tránh tính toán phức tạp trong luồng quyết định chính.

Ngày 260: Ôn tập Tuần 52 + Bài test

Khái niệm
- Tổng hợp fraud detection, credit risk, real-time decisioning.
Thực hành và quan sát
- Bài test: thiết kế toàn diện hệ thống risk cho 1 sản phẩm fintech giả định (VD: BNPL - Buy Now Pay Later), bao gồm cả credit decisioning lúc đăng ký và fraud monitoring liên tục sau đó.
Advanced concepts
- Phân tích trade-off business: risk system quá chặt → mất khách hàng tốt; quá lỏng → tổn thất do fraud/nợ xấu - đây luôn là bài toán cân bằng, không có đáp án "đúng tuyệt đối".

Tuần 53 (Ngày 261–265): Treasury & liquidity management

Ngày 261: Treasury management cơ bản

Khái niệm
- Cash management, liquidity forecasting - đảm bảo đủ tiền mặt/thanh khoản để đáp ứng nghĩa vụ thanh toán mà không giữ quá nhiều vốn nhàn rỗi (opportunity cost).
Thực hành và quan sát
- Xây dựng 1 mô hình cash flow forecast đơn giản (dùng spreadsheet hoặc script) dựa trên lịch sử giao dịch giả định, dự báo nhu cầu thanh khoản 7 ngày tới.
Advanced concepts
- Liquidity buffer requirement theo quy định (VD: LCR - Liquidity Coverage Ratio trong Basel III cho ngân hàng) - khái niệm tổng quan, không cần tính toán chi tiết.

Ngày 262: Settlement netting

Khái niệm
- Bilateral/multilateral netting - thay vì settle từng giao dịch riêng lẻ, gộp lại tính net amount cuối kỳ để giảm số lượng giao dịch thực tế cần chuyển tiền (giảm chi phí, giảm rủi ro đối tác).
Thực hành và quan sát
- Viết script tính netting cho 1 tập giao dịch giả định giữa nhiều bên (A nợ B, B nợ C, C nợ A...), tính net position cuối cùng mỗi bên.
Advanced concepts
- CCP (Central Counterparty) - cách sàn giao dịch/clearing house đứng giữa để giảm rủi ro đối tác (mỗi bên chỉ có rủi ro với CCP, không phải với từng đối tác riêng lẻ).

Ngày 263: FX & cross-currency settlement

Khái niệm
- Correspondent banking (nostro/vostro account) - cách ngân hàng giữ tài khoản lẫn nhau ở nước ngoài để thực hiện thanh toán xuyên biên giới.
Thực hành và quan sát
- Vẽ sơ đồ luồng 1 giao dịch chuyển tiền quốc tế qua correspondent banking (2-3 ngân hàng trung gian), đánh dấu rõ phí và độ trễ phát sinh ở mỗi bước.
Advanced concepts
- So sánh với stablecoin cross-border settlement (loại bỏ correspondent banking, settlement gần tức thì) - đánh giá khách quan lợi ích thực tế và rủi ro (thanh khoản on/off-ramp, quy định pháp lý).

Ngày 264: Stablecoin reserve management thực tế

Khái niệm
- Cấu trúc reserve của stablecoin lớn (thường: cash + short-term treasury bills), attestation report định kỳ (khác audit đầy đủ - attestation chỉ xác nhận số dư tại 1 thời điểm, không đảm bảo toàn bộ hoạt động).
Thực hành và quan sát
- Đọc 1 attestation report thật của stablecoin lớn (công khai trên website), phân tích cấu trúc tài sản đảm bảo, so sánh với yêu cầu 1:1 backing.
Advanced concepts
- Rủi ro "run" trên stablecoin (giống bank run truyền thống) khi redemption đồng loạt vượt quá khả năng thanh khoản tức thời của reserve (kể cả khi reserve đủ về mặt tổng giá trị nhưng không đủ thanh khoản tức thời).

Ngày 265: Ôn tập Tuần 53 + Bài test

Khái niệm
- Tổng hợp treasury, netting, FX settlement, stablecoin reserve.
Thực hành và quan sát
- Bài test: thiết kế hệ thống treasury cho 1 fintech xử lý thanh toán xuyên biên giới bằng stablecoin, bao gồm cả on/off-ramp liquidity management và quy trình đối soát với đối tác ngân hàng truyền thống.
Advanced concepts
- Đây là use-case điển hình nơi kiến thức Blockchain (Phần 1-9) và Fintech truyền thống (Phần 10) phải kết hợp chặt chẽ với nhau.

Tuần 54 (Ngày 266–270): CBDC & quy định pháp lý

Ngày 266: CBDC - kiến trúc kỹ thuật

Khái niệm
- Wholesale CBDC (chỉ dùng giữa ngân hàng/tổ chức tài chính) vs Retail CBDC (dùng trực tiếp bởi người dân) - kiến trúc 2-tier phổ biến (ngân hàng trung ương → ngân hàng thương mại → người dùng cuối, tránh disintermediation hoàn toàn hệ thống ngân hàng).
Thực hành và quan sát
- Đọc 1 báo cáo kỹ thuật CBDC thật (BIS hoặc ngân hàng trung ương cụ thể), tóm tắt kiến trúc 2-tier và lý do thiết kế.
Advanced concepts
- Offline capability - 1 số thiết kế CBDC (retail) hỗ trợ giao dịch offline hạn chế (dùng secure element trên thiết bị) - đánh đổi giữa tiện lợi và kiểm soát/an ninh.

Ngày 267: Privacy vs traceability trong CBDC

Khái niệm
- Spectrum từ hoàn toàn ẩn danh (như tiền mặt) tới hoàn toàn traceable - hầu hết thiết kế CBDC thực tế nằm ở giữa (tiered privacy: giao dịch nhỏ có privacy cao hơn, giao dịch lớn bị giám sát chặt hơn).
Thực hành và quan sát
- Đọc và tóm tắt 1 phần cụ thể của báo cáo kỹ thuật e-CNY hoặc digital Euro concept liên quan tới thiết kế privacy - tra cứu nguồn hiện tại vì đây là lĩnh vực thay đổi nhanh.
Advanced concepts
- So sánh privacy model CBDC với privacy trong blockchain công khai (Ethereum - pseudonymous nhưng traceable hoàn toàn) và ZK-based private payment (đã học Phần 5) - CBDC thường KHÔNG áp dụng ZK đầy đủ vì mục tiêu ngược lại (kiểm soát, không phải ẩn danh tuyệt đối).

Ngày 268: Khung pháp lý MiCA & VASP

Khái niệm
- MiCA (Markets in Crypto-Assets - EU): khung pháp lý toàn diện đầu tiên cho crypto-asset ở quy mô khu vực lớn; VASP (Virtual Asset Service Provider) - định nghĩa và nghĩa vụ tuân thủ theo khuyến nghị FATF.
Thực hành và quan sát
- Đọc tóm tắt chính thức về phạm vi MiCA (loại tài sản nào thuộc phạm vi điều chỉnh, loại nào ngoại lệ), lập bảng phân loại 5 loại crypto-asset phổ biến (stablecoin, utility token, security token, NFT, native coin) theo MiCA.
Advanced concepts
- Travel Rule (FATF Recommendation 16) - yêu cầu VASP chia sẻ thông tin originator/beneficiary cho giao dịch vượt ngưỡng nhất định, tương tự quy định wire transfer truyền thống - thách thức kỹ thuật khi áp dụng cho giao dịch on-chain (giao thức chuẩn hóa như TRP - Travel Rule Protocol).

Ngày 269: Tình hình quy định crypto tại Việt Nam (cần tra cứu cập nhật)

Khái niệm
- Khung pháp lý crypto tại Việt Nam đang trong quá trình hoàn thiện và thay đổi - CẦN tra cứu nguồn chính thức tại thời điểm học (Ngân hàng Nhà nước, Bộ Tài chính, các văn bản pháp luật mới nhất) thay vì dựa vào thông tin cũ.
Thực hành và quan sát
- Tra cứu các văn bản/thông báo chính thức gần nhất liên quan tới crypto-asset tại Việt Nam, tóm tắt hiện trạng (được phép/cấm/đang thí điểm) - ghi rõ ngày tra cứu vì thông tin có thể thay đổi nhanh.
Advanced concepts
- So sánh cách tiếp cận của Việt Nam với các nước trong khu vực (Singapore - cấp phép MAS, Thái Lan - khung pháp lý riêng) để có góc nhìn tương đối.

Ngày 270: Ôn tập Tuần 54 + Bài test

Khái niệm
- Tổng hợp CBDC, MiCA/VASP, Travel Rule, quy định khu vực.
Thực hành và quan sát
- Bài test: viết compliance checklist đầy đủ cho 1 sản phẩm ví crypto có tính năng on/off-ramp (chuyển đổi fiat ↔ crypto), bao gồm: KYC tier, AML monitoring, Travel Rule implementation, và các nghĩa vụ báo cáo theo khung pháp lý đã học.
Advanced concepts
- Nhấn mạnh: checklist này chỉ mang tính học thuật/tham khảo - triển khai thực tế cần tư vấn pháp lý chuyên môn tại từng thị trường cụ thể, quy định thay đổi liên tục.

Tuần 55 (Ngày 271–275): Payment gateway & tích hợp hệ thống thực tế

Ngày 271: Kiến trúc payment gateway hiện đại

Khái niệm
- Kiến trúc tổng thể (lấy cảm hứng từ Stripe - case study kỹ thuật xuất sắc và được viết công khai rất chi tiết): API layer → payment processing → ledger → webhook notification.
Thực hành và quan sát
- Đọc 1-2 bài blog kỹ thuật của Stripe Engineering về kiến trúc hệ thống của họ, vẽ lại sơ đồ kiến trúc theo hiểu biết của bạn.
Advanced concepts
- API versioning strategy - cách payment gateway lớn quản lý thay đổi API mà không phá vỡ tích hợp của hàng nghìn merchant đang dùng phiên bản cũ.

Ngày 272: Webhook design & reliability

Khái niệm
- At-least-once delivery (không phải exactly-once) - webhook có thể gửi trùng lặp, receiver PHẢI tự xử lý idempotency (liên hệ ngày 243).
Thực hành và quan sát
- Implement webhook sender với retry logic (exponential backoff) và webhook receiver xử lý idempotent đúng cách (dùng idempotency key từ event ID).
Advanced concepts
- Webhook signature verification (HMAC - liên hệ Phần 2 ngày 39) - cách đảm bảo webhook thật sự đến từ payment gateway, không phải request giả mạo.

Ngày 273: Chargeback & dispute handling

Khái niệm
- Chargeback flow: khách hàng khiếu nại qua ngân hàng phát hành → merchant có cơ hội phản hồi bằng chứng → quyết định cuối cùng - chi phí và rủi ro cho merchant.
Thực hành và quan sát
- Vẽ sơ đồ luồng chargeback đầy đủ (từ dispute tới representment tới final decision), thiết kế schema database lưu trạng thái dispute qua từng giai đoạn.
Advanced concepts
- Chargeback ratio monitoring - merchant có tỷ lệ chargeback quá cao có thể bị card network đưa vào chương trình giám sát đặc biệt hoặc bị chấm dứt hợp đồng.

Ngày 274: Tích hợp on-chain settlement vào payment gateway truyền thống

Khái niệm
- Kết hợp toàn bộ kiến thức khóa học: payment gateway nhận fiat, settlement cuối cùng qua stablecoin on-chain cho merchant ở nước khác - cần xử lý số block confirmation, khả năng reorg (liên hệ Phần 6/Production).
Thực hành và quan sát
- Thiết kế (sơ đồ + pseudocode) luồng đầy đủ: merchant nhận thanh toán thẻ → payment gateway xử lý → convert sang stablecoin → gửi on-chain tới ví merchant ở quốc gia khác → merchant off-ramp về fiat địa phương.
Advanced concepts
- Xử lý rủi ro tỷ giá (FX risk) trong khoảng thời gian giữa lúc nhận fiat và lúc hoàn tất on-chain settlement - cần cơ chế hedge hoặc chấp nhận rủi ro trong khung thời gian ngắn.

Ngày 275: Bài test tổng hợp Phần 10

Khái niệm
- Tổng hợp toàn bộ Fintech Systems: ledger, payment rails, core banking, risk/fraud, treasury, CBDC/quy định, payment gateway.
Thực hành và quan sát
- Bài test lớn: thiết kế toàn diện (document kiến trúc 4-6 trang) cho 1 sản phẩm "neobank" xử lý cả fiat truyền thống và stablecoin, bao gồm: ledger engine, KYC/AML flow, risk decisioning, treasury/liquidity management, và compliance checklist theo khung pháp lý đã học.
Advanced concepts
- Đây là bản thiết kế có thể dùng làm nền tảng trực tiếp cho Capstone project cuối khóa (Phần Capstone, hướng 1 hoặc 3).

PHẦN 11 - PRODUCTION, DEVOPS & BẢO MẬT VẬN HÀNH (Ngày 276–310)

Tuần 56 (Ngày 276–280): Vận hành node production

Ngày 276: Chạy full node Ethereum production-grade

Khái niệm
- Execution client + consensus client (Geth + Lighthouse hoặc Nethermind + Prysm...) - client diversity (đã học Phần 4 ngày 91), tại sao KHÔNG nên chỉ dùng 1 loại client cho toàn mạng.
Thực hành và quan sát
- Cài đặt đầy đủ 1 cặp execution+consensus client trên VPS/server thật (không phải local dev nữa), đồng bộ testnet, đo thời gian sync và dung lượng disk sử dụng.
Advanced concepts
- JWT secret giữa execution và consensus client (Engine API authentication) - vì sao 2 client cần xác thực lẫn nhau dù chạy trên cùng máy.

Ngày 277: Archive node vs full node vs light client - chọn đúng loại

Khái niệm
- Trade-off storage/tốc độ/khả năng truy vấn lịch sử - archive node cần hàng chục TB, full node chỉ cần lưu state gần đây.
Thực hành và quan sát
- So sánh cấu hình pruning khác nhau trên node đã cài ngày 276, quan sát dung lượng disk thay đổi theo config.
Advanced concepts
- Use-case cụ thể cần archive node (VD: block explorer cần query balance tại block cũ bất kỳ) vs không cần (VD: validator chỉ cần state hiện tại).

Ngày 278: Validator operations

Khái niệm
- Deposit process, validator key (signing key) vs withdrawal key - tách biệt 2 loại key theo mức độ nhạy cảm khác nhau.
Thực hành và quan sát
- Setup validator trên testnet đầy đủ: generate key bằng deposit CLI chính thức, submit deposit transaction, chạy validator client kết nối với consensus client.
Advanced concepts
- Slashing protection database (đã nhắc Phần 4 ngày 94) - thực hành: cố tình chạy 2 instance validator client cùng key trên 2 máy khác nhau (KHÔNG làm trên mainnet thật) để quan sát nguy cơ double-sign nếu không có cơ chế bảo vệ.

Ngày 279: RPC infrastructure - load balancing & failover

Khái niệm
- Chạy nhiều node đằng sau load balancer, health check để tự động loại node bị lag/lỗi ra khỏi pool.
Thực hành và quan sát
- Setup 2-3 node RPC, dùng Nginx/HAProxy làm load balancer, viết health check script kiểm tra eth_blockNumber để phát hiện node bị lag.
Advanced concepts
- Rate limiting theo API key - cách provider RPC lớn (Infura, Alchemy) quản lý fair-use giữa nhiều khách hàng.

Ngày 280: Ôn tập Tuần 56 + Bài test

Khái niệm
- Tổng hợp vận hành node, validator, RPC infrastructure.
Thực hành và quan sát
- Bài test: viết runbook đầy đủ "vận hành validator production" - bao gồm checklist trước khi deploy, monitoring cần thiết, quy trình xử lý khi node bị down.
Advanced concepts
- So sánh runbook của bạn với best practice công khai từ Ethereum Foundation hoặc các staking service lớn - tìm điểm còn thiếu.

Tuần 57 (Ngày 281–285): Monitoring & Indexing

Ngày 281: Prometheus & Grafana cho node metrics

Khái niệm
- Metrics dạng time-series, pull-based scraping (Prometheus) - dashboard visualize (Grafana).
Thực hành và quan sát
- Setup Prometheus scrape metrics từ node đã cài (Geth/Lighthouse expose metrics endpoint sẵn), tạo Grafana dashboard hiển thị: peer count, sync status, CPU/memory.
Advanced concepts
- PromQL - viết query phức tạp hơn (VD: rate of block processing, alert khi peer count giảm dưới ngưỡng).

Ngày 282: Alerting

Khái niệm
- Alertmanager - routing alert theo severity, tránh alert fatigue (quá nhiều alert vô nghĩa khiến người vận hành bỏ qua alert quan trọng).
Thực hành và quan sát
- Cấu hình alert rule: node bị lag quá X block, disk usage vượt ngưỡng, validator missed attestation - gửi thông báo qua kênh thật (Slack/Telegram webhook).
Advanced concepts
- Alert deduplication & silencing - cách tránh spam alert khi 1 sự cố gây ra hàng loạt alert liên quan cùng lúc.

Ngày 283: Custom indexer - thiết kế

Khái niệm
- Vì sao cần indexer riêng thay vì query trực tiếp node cho ứng dụng production (hiệu năng eth_getLogs giới hạn ở quy mô lớn, đã nhắc Phần 4 ngày 85).
Thực hành và quan sát
- Thiết kế schema PostgreSQL cho indexer lưu event log của 1 contract cụ thể (transfer event của token), lên kế hoạch cách xử lý reorg (sẽ implement chi tiết ngày sau).
Advanced concepts
- So sánh build indexer riêng vs dùng The Graph (subgraph) - trade-off giữa kiểm soát toàn diện và tốc độ phát triển.

Ngày 284: Implement custom indexer

Khái niệm
- Poll block mới, extract log qua ABI decode, lưu vào database, checkpoint (block đã xử lý) để resume nếu indexer restart.
Thực hành và quan sát
- Code indexer hoàn chỉnh: lắng nghe event từ contract test (deploy sẵn trên testnet), lưu vào PostgreSQL, expose qua REST API đơn giản để truy vấn lịch sử transfer.
Advanced concepts
- Batch processing - xử lý nhiều block cùng lúc khi indexer bị "đuổi theo" (catch up) sau downtime, cân bằng giữa tốc độ catch-up và tải lên node RPC.

Ngày 285: Xử lý reorg trong indexer

Khái niệm
- Chain reorganization - block đã index có thể bị "đảo ngược" nếu chưa đủ finality, indexer PHẢI có cơ chế phát hiện và rollback dữ liệu tương ứng.
Thực hành và quan sát
- Thêm logic vào indexer ngày 284: lưu block hash đã index, mỗi block mới kiểm tra parentHash có khớp với block hash đã lưu trước đó không - nếu không khớp, rollback dữ liệu về điểm chung gần nhất.
Advanced concepts
- Số block confirmation cần chờ tùy theo mức độ tin cậy cần thiết (VD: giao dịch giá trị lớn chờ nhiều confirmation hơn giao dịch nhỏ) - trade-off tốc độ UX vs rủi ro reorg.

Tuần 58 (Ngày 286–290): Key Management production-grade

Ngày 286: HSM (Hardware Security Module)

Khái niệm
- Thiết bị phần cứng chuyên dụng lưu trữ và thực hiện phép toán với private key mà KHÔNG BAO GIỜ để key rời khỏi thiết bị (kể cả admin cũng không đọc được key trực tiếp).
Thực hành và quan sát
- Đọc tài liệu kỹ thuật 1 HSM cloud-based (VD: AWS CloudHSM hoặc tương đương), vẽ sơ đồ luồng: application gửi yêu cầu ký → HSM thực hiện ký nội bộ → trả kết quả, key không bao giờ xuất ra ngoài.
Advanced concepts
- FIPS 140-2/3 certification level - chuẩn đánh giá độ an toàn phần cứng HSM, các cấp độ khác nhau (Level 1-4) tương ứng mức độ chống can thiệp vật lý.

Ngày 287: KMS (Key Management Service) & Vault

Khái niệm
- KMS (cloud-managed, VD AWS KMS/GCP KMS) vs self-hosted (HashiCorp Vault) - trade-off giữa tiện lợi (managed) và kiểm soát toàn diện (self-hosted).
Thực hành và quan sát
- Cài HashiCorp Vault local, cấu hình secret engine lưu 1 private key test, thực hành encrypt/decrypt qua Vault API thay vì lưu key trực tiếp trong code/config file.
Advanced concepts
- Dynamic secrets & secret rotation - Vault có thể tự động sinh credential tạm thời (VD: database password) có thời hạn ngắn, giảm rủi ro nếu secret bị lộ.

Ngày 288: Secure Enclave - Intel SGX

Khái niệm
- Trusted Execution Environment (TEE): vùng bộ nhớ được mã hóa và cô lập ở tầng phần cứng CPU, ngay cả hệ điều hành/hypervisor cũng không đọc được nội dung bên trong khi đang thực thi.
Thực hành và quan sát
- Đọc kiến trúc SGX tổng quan (enclave, attestation), vẽ sơ đồ so sánh với mô hình bảo mật thông thường (OS-level isolation) - chỉ ra điểm khác biệt cốt lõi (threat model bao gồm cả OS/hypervisor bị compromise).
Advanced concepts
- Remote attestation - cách 1 bên ngoài có thể verify từ xa rằng code đang chạy đúng trong 1 enclave hợp lệ (không bị giả mạo) trước khi gửi dữ liệu nhạy cảm vào.

Ngày 289: AWS Nitro Enclaves - ứng dụng thực tế

Khái niệm
- TEE dạng cloud-native, dùng phổ biến trong ngành custody crypto hiện đại (Fireblocks và nhiều custodian lớn dùng kiến trúc tương tự) - cô lập hoàn toàn khỏi instance cha, không có network, không có persistent storage, không SSH access.
Thực hành và quan sát
- Đọc tài liệu kiến trúc Nitro Enclaves, vẽ sơ đồ luồng ký giao dịch: request từ parent instance → gửi vào enclave qua vsock (không qua network thường) → enclave ký bằng key chỉ tồn tại trong bộ nhớ enclave → trả kết quả ra ngoài.
Advanced concepts
- So sánh threat model: Nitro Enclaves bảo vệ khỏi cả trường hợp AWS admin hoặc kẻ tấn công chiếm được quyền root trên parent instance - vẫn không đọc được nội dung trong enclave.

Ngày 290: Ôn tập Tuần 58 + Bài test

Khái niệm
- Tổng hợp HSM, KMS/Vault, SGX, Nitro Enclaves.
Thực hành và quan sát
- Bài test: thiết kế kiến trúc key management đầy đủ cho 1 sàn giao dịch giả định - phân loại rõ: hot wallet key (dùng enclave/HSM, ký tự động với giới hạn), warm/cold wallet key (multisig + TSS + offline signing).
Advanced concepts
- So sánh chi phí vận hành (HSM vật lý đắt, KMS cloud rẻ hơn nhưng phải tin tưởng cloud provider, TEE là điểm cân bằng phổ biến hiện nay) - không có giải pháp "đúng tuyệt đối" cho mọi quy mô công ty.

Tuần 59 (Ngày 291–295): Incident Response & Circuit Breaker

Ngày 291: Threat modeling cho hệ thống Web3/fintech

Khái niệm
- STRIDE framework (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) - cách hệ thống hóa việc tìm ra rủi ro thay vì brainstorm ngẫu nhiên.
Thực hành và quan sát
- Áp dụng STRIDE cho hệ thống custody đã thiết kế ngày 290, liệt kê ít nhất 1 rủi ro cụ thể cho mỗi hạng mục trong STRIDE.
Advanced concepts
- Attack tree - biểu diễn trực quan các con đường tấn công khác nhau dẫn tới cùng 1 mục tiêu (VD: "đánh cắp private key") để ưu tiên phòng thủ đúng chỗ.

Ngày 292: Circuit breaker pattern cho smart contract

Khái niệm
- Pausable pattern - cho phép admin (hoặc multisig/DAO) tạm dừng contract khi phát hiện exploit đang diễn ra, giới hạn thiệt hại.
Thực hành và quan sát
- Thêm cơ chế Pausable (dùng OpenZeppelin hoặc tự viết) vào 1 contract DeFi đã viết trước đó (Phần 6/7), test kịch bản: phát hiện giao dịch bất thường → gọi pause → verify mọi hàm nhạy cảm bị chặn ngay lập tức.
Advanced concepts
- Trade-off decentralization: có circuit breaker nghĩa là có 1 điểm tập trung quyền lực (ai giữ quyền pause) - cần cân bằng giữa an toàn khẩn cấp và tính phi tập trung của giao thức.

Ngày 293: Incident response playbook

Khái niệm
- Cấu trúc playbook chuẩn: Detect → Contain → Eradicate → Recover → Post-mortem - áp dụng framework an ninh mạng truyền thống vào bối cảnh Web3.
Thực hành và quan sát
- Viết 1 playbook cụ thể cho kịch bản "phát hiện giao dịch khai thác đang diễn ra trên contract production": ai được thông báo đầu tiên, quy trình quyết định pause, cách giao tiếp với cộng đồng/người dùng.
Advanced concepts
- White-hat rescue - trường hợp đặc biệt trong Web3: 1 số vụ hack được "cứu" bởi bên thứ 3 tự khai thác lỗ hổng tương tự để rút tài sản về nơi an toàn trước kẻ xấu (vùng xám về đạo đức/pháp lý, cần hiểu nhưng không khuyến khích tự thực hiện).

Ngày 294: Bug bounty program

Khái niệm
- Immunefi model - cấu trúc thưởng theo mức độ nghiêm trọng (thường tính theo % giá trị tài sản gặp rủi ro, có thể lên tới hàng triệu đô cho lỗ hổng Critical).
Thực hành và quan sát
- Đọc 2-3 chương trình bug bounty thật trên Immunefi, phân tích scope (contract nào trong phạm vi, loại lỗ hổng nào được tính thưởng) và mức thưởng theo severity.
Advanced concepts
- Vì sao bug bounty với mức thưởng đủ lớn là chiến lược kinh tế hợp lý (rational) - trả cho white-hat report còn rẻ hơn rất nhiều so với bị exploit thật (liên hệ lại mechanism design đã học Phần 7).

Ngày 295: Ôn tập Tuần 59 + Bài test

Khái niệm
- Tổng hợp threat modeling, circuit breaker, incident response, bug bounty.
Thực hành và quan sát
- Bài test: viết incident response playbook đầy đủ cho hệ thống DeFi capstone (Phần 6 ngày 170), diễn tập giả lập 1 kịch bản exploit (tự viết 1 lỗ hổng cố ý vào 1 bản copy contract, "phát hiện" và thực hiện đúng playbook đã viết).
Advanced concepts
- Đo thời gian phản ứng thực tế (từ lúc "phát hiện" tới lúc pause thành công) trong bài diễn tập - đây là con số rất thực tế các công ty Web3 nghiêm túc phải đo đạc và cải thiện liên tục.

Tuần 60 (Ngày 296–300): CI/CD & Deployment

Ngày 296: CI pipeline cho smart contract

Khái niệm
- Pipeline chuẩn: lint → compile → test (unit+fuzz+invariant) → static analysis (Slither) → coverage report - chạy tự động mỗi PR.
Thực hành và quan sát
- Setup GitHub Actions workflow đầy đủ cho 1 dự án Foundry: chạy forge test, forge coverage, slither ., fail pipeline nếu coverage dưới ngưỡng hoặc Slither phát hiện High severity.
Advanced concepts
- Caching dependency (Foundry libs, Slither install) để giảm thời gian CI chạy - tối ưu developer experience cho team lớn.

Ngày 297: Multi-network deployment script

Khái niệm
- Deploy script phải tham số hóa theo network (testnet/mainnet khác RPC, khác private key, khác cấu hình gas) - tránh hardcode gây lỗi khi deploy nhầm network.
Thực hành và quan sát
- Viết Foundry deploy script (Solidity script, không phải bash) hỗ trợ deploy cùng 1 hệ thống contract lên nhiều network khác nhau chỉ bằng đổi tham số --rpc-url.
Advanced concepts
- CREATE2 deterministic deployment - deploy contract có cùng địa chỉ trên nhiều chain khác nhau (hữu ích cho hệ thống multi-chain cần địa chỉ nhất quán).

Ngày 298: Contract verification & CI gated deployment

Khái niệm
- Verify source code trên block explorer ngay sau deploy (tự động qua CI, không làm thủ công) - tăng minh bạch và tin cậy cho người dùng.
Thực hành và quan sát
- Thêm bước auto-verify vào deploy script (Foundry hỗ trợ --verify trực tiếp), thiết lập CI pipeline: chỉ cho phép deploy lên mainnet khi merge vào branch main VÀ đã qua review (gated deployment, cần approval thủ công).
Advanced concepts
- Deployment artifact tracking - lưu lại địa chỉ contract đã deploy + commit hash tương ứng vào file JSON, giúp truy vết chính xác version code nào đang chạy ở địa chỉ nào.

Ngày 299: Blue-green deployment cho backend fintech

Khái niệm
- Áp dụng pattern DevOps truyền thống cho backend service (không phải smart contract) - deploy version mới song song, chuyển traffic dần, rollback tức thì nếu phát hiện lỗi.
Thực hành và quan sát
- Setup 1 kịch bản blue-green deployment đơn giản cho backend indexer/API đã viết trước đó (dùng Docker + reverse proxy chuyển traffic giữa 2 phiên bản).
Advanced concepts
- Canary deployment - biến thể chuyển traffic dần dần (5% → 25% → 100%) thay vì chuyển toàn bộ ngay lập tức, giảm thiểu blast radius nếu có lỗi.

Ngày 300: Ôn tập Tuần 60 + Bài test

Khái niệm
- Tổng hợp CI/CD cho smart contract và backend.
Thực hành và quan sát
- Bài test: hoàn thiện toàn bộ pipeline CI/CD cho hệ thống DeFi capstone - từ commit code tới deploy verified lên testnet hoàn toàn tự động, có gate kiểm tra chất lượng (test/coverage/static analysis) trước khi cho phép merge.
Advanced concepts
- Viết tài liệu "Deployment Runbook" mô tả toàn bộ quy trình cho người mới trong team.

Tuần 61 (Ngày 301–305): Scalability & reliability cho backend fintech

Ngày 301: Exactly-once processing trong distributed system

Khái niệm
- Thực tế không có "exactly-once" tuyệt đối trong network không tin cậy - kỹ thuật thực tế: "at-least-once delivery + idempotent processing" = hiệu ứng tương đương exactly-once.
Thực hành và quan sát
- Áp dụng lại idempotency key (Phần 10 ngày 243) vào 1 message queue thật (RabbitMQ/Kafka), test gửi trùng lặp message và verify hệ thống xử lý đúng chỉ 1 lần dù nhận nhiều lần.
Advanced concepts
- Outbox pattern - kỹ thuật đảm bảo consistency giữa database write và message publish (tránh trường hợp ghi DB thành công nhưng publish message thất bại, hoặc ngược lại).

Ngày 302: Message queue cho hệ thống fintech

Khái niệm
- Kafka (log-based, có thể replay) vs RabbitMQ (traditional queue) - trade-off use-case: Kafka phù hợp event sourcing/audit trail dài hạn, RabbitMQ phù hợp task queue đơn giản.
Thực hành và quan sát
- Setup Kafka local, publish event ledger (từ Phần 10) vào Kafka topic, viết consumer xử lý và cập nhật read-model (áp dụng CQRS đã học ngày 244).
Advanced concepts
- Partition strategy trong Kafka - cách chọn partition key (VD: theo account_id) để đảm bảo thứ tự xử lý đúng cho cùng 1 account mà vẫn parallelize được giữa các account khác nhau.

Ngày 303: Database scaling cho hệ thống ledger lớn

Khái niệm
- Read replica cho query nặng (báo cáo, dashboard) tách khỏi write path chính; sharding theo account_id khi 1 database instance không đủ tải.
Thực hành và quan sát
- Setup PostgreSQL với 1 read replica, viết logic application route query đọc (SELECT) sang replica, query ghi (INSERT/UPDATE) vẫn qua primary.
Advanced concepts
- Replication lag - rủi ro đọc dữ liệu cũ từ replica ngay sau khi ghi vào primary (read-your-writes consistency problem), và cách giải quyết (route đọc gần đó về primary nếu cần consistency cao).

Ngày 304: Circuit breaker & retry pattern cho backend (khác circuit breaker smart contract)

Khái niệm
- Circuit breaker pattern trong microservice: tự động ngắt gọi tới service đang lỗi liên tục (thay vì tiếp tục gọi và làm chậm toàn hệ thống), retry với exponential backoff + jitter.
Thực hành và quan sát
- Implement circuit breaker đơn giản cho 1 service gọi RPC blockchain node: nếu 5 request liên tiếp fail, tạm ngắt gọi trong X giây trước khi thử lại (half-open state).
Advanced concepts
- Bulkhead pattern - cô lập tài nguyên (connection pool riêng) cho từng dependency, tránh 1 dependency chậm làm cạn kiệt tài nguyên toàn hệ thống.

Ngày 305: Ôn tập Tuần 61 + Bài test

Khái niệm
- Tổng hợp exactly-once processing, message queue, database scaling, circuit breaker backend.
Thực hành và quan sát
- Bài test: thiết kế kiến trúc backend hoàn chỉnh cho hệ thống nhận deposit on-chain quy mô lớn (hàng chục ngàn giao dịch/ngày) - bao gồm message queue, database read replica, circuit breaker cho RPC calls, và idempotent processing toàn diện.
Advanced concepts
- Vẽ sơ đồ capacity planning đơn giản: ước lượng tải hệ thống cần chịu (TPS), từ đó suy ra số lượng replica/partition cần thiết.

Tuần 62 (Ngày 306–310): Tổng hợp - end-to-end system

Ngày 306: Disaster recovery planning

Khái niệm
- RTO (Recovery Time Objective) và RPO (Recovery Point Objective) - 2 chỉ số quyết định chiến lược backup/failover phù hợp.
Thực hành và quan sát
- Viết disaster recovery plan cho hệ thống capstone: xác định RTO/RPO mục tiêu, thiết kế backup strategy (database snapshot, key backup an toàn) đáp ứng mục tiêu đó.
Advanced concepts
- Chaos engineering nâng cao - lên lịch "game day" định kỳ giả lập sự cố lớn (mất toàn bộ 1 region cloud) để test disaster recovery plan có thực sự hoạt động, không chỉ nằm trên giấy.

Ngày 307: Cost optimization cho infrastructure Web3/fintech

Khái niệm
- RPC call cost (nhiều provider tính phí theo request), node vận hành cost (server + storage), trade-off giữa self-host node vs dùng provider managed.
Thực hành và quan sát
- Tính toán ước lượng chi phí vận hành hàng tháng cho hệ thống capstone ở quy mô production giả định (VD: 100,000 user active) - server, RPC, database, monitoring.
Advanced concepts
- Caching strategy để giảm RPC call - cache aggressive cho dữ liệu ít thay đổi (VD: token metadata) vs không cache cho dữ liệu real-time (VD: balance).

Ngày 308: Compliance & audit trail cho toàn hệ thống

Khái niệm
- Tổng hợp lại yêu cầu Phần 10 (KYC/AML, reconciliation) vào góc nhìn vận hành: log immutable, access control theo role, audit log cho MỌI thao tác nhạy cảm (không chỉ giao dịch tiền mà cả thao tác admin).
Thực hành và quan sát
- Implement audit log middleware cho hệ thống capstone: mọi API call nhạy cảm (thay đổi quyền, thao tác admin, giao dịch giá trị lớn) được ghi log immutable (append-only, có thể dùng chính kỹ thuật event sourcing đã học).
Advanced concepts
- Log retention policy theo yêu cầu pháp lý (thường 5-7 năm cho dữ liệu tài chính tùy khu vực) - cân nhắc chi phí lưu trữ dài hạn.

Ngày 309: Security review toàn diện hệ thống end-to-end

Khái niệm
- Review lại TOÀN BỘ hệ thống capstone qua lăng kính đã học suốt khóa: smart contract security (Phần 6), key management (Phần 11), infrastructure security (Phần 11), compliance (Phần 10).
Thực hành và quan sát
- Thực hiện self-audit toàn diện, viết báo cáo tổng hợp theo đúng format audit report đã học (Phần 6 ngày 168) nhưng áp dụng cho TOÀN BỘ hệ thống (không chỉ smart contract).
Advanced concepts
- Threat modeling lại lần cuối (STRIDE, ngày 291) cho toàn hệ thống end-to-end, đảm bảo không bỏ sót góc nhìn nào.

Ngày 310: Bài test tổng hợp Phần 11 - sẵn sàng cho Capstone

Khái niệm
- Tổng hợp toàn bộ Production, DevOps & Bảo mật vận hành.
Thực hành và quan sát
- Bài test lớn cuối cùng trước Capstone: đảm bảo hệ thống capstone đang xây (dù đã bắt đầu từ Phần 6 hoặc đang phát triển song song) có đầy đủ - CI/CD hoàn chỉnh, monitoring/alerting, key management production-grade, incident response playbook, disaster recovery plan.
Advanced concepts
- Đây là checklist "go-live readiness" - checklist mà bất kỳ hệ thống fintech/Web3 thật nào cũng cần hoàn thành trước khi ra mắt production với tiền thật của người dùng thật.

CAPSTONE PROJECT (Ngày 311–330)

Tích hợp toàn bộ 11 Phần đã học thành 1 hệ thống hoàn chỉnh, production-ready. Chọn 1 trong 2 hướng bên dưới tùy định hướng nghề nghiệp.

Hướng A - Protocol/Infrastructure track: Hoàn thiện blockchain tự xây (Phần 9) thành 1 testnet công khai nhỏ với đầy đủ tooling (explorer đơn giản, faucet, docs), có ít nhất 3 người ngoài chạy thử validator.

Hướng B - Fintech/Application track: Hoàn thiện hệ thống "neobank + stablecoin settlement" (thiết kế từ Phần 10 ngày 275) thành sản phẩm chạy được end-to-end trên testnet, đầy đủ ledger, KYC flow giả lập, risk system, và production infrastructure.

Tuần 63 (Ngày 311–315): Thiết kế & kiến trúc chi tiết

Ngày 311: Chốt phạm vi & viết Technical Design Document

Khái niệm
- TDD (Technical Design Document) chuẩn công nghiệp: Problem statement → Goals/Non-goals → Architecture → Trade-offs → Rollout plan.
Thực hành và quan sát
- Viết TDD đầy đủ (4-8 trang) cho hướng đã chọn, liệt kê rõ mọi component sẽ dùng lại từ các Phần trước (VD: "Ledger engine dùng lại thiết kế Phần 10 ngày 241-244", "Consensus dùng lại BFT implement Phần 1 ngày 28").
Advanced concepts
- Risk register - liệt kê rủi ro kỹ thuật lớn nhất của dự án và kế hoạch giảm thiểu cho từng rủi ro.

Ngày 312: Kiến trúc hệ thống chi tiết

Khái niệm
- Vẽ đầy đủ system architecture diagram: mọi service, database, message queue, external dependency (blockchain node, oracle...).
Thực hành và quan sát
- Hoàn thiện diagram kiến trúc (dùng công cụ vẽ sơ đồ bất kỳ), review lại với checklist đã học ở Phần 11 (single point of failure, scaling bottleneck).
Advanced concepts
- API contract design-first - viết OpenAPI spec (hoặc Protobuf nếu dùng gRPC) TRƯỚC khi code, đảm bảo interface rõ ràng giữa các service.

Ngày 313: Setup infrastructure nền tảng

Khái niệm
- Provisioning: server/VPS, database, message queue, monitoring stack - chuẩn bị hạ tầng trước khi viết logic nghiệp vụ.
Thực hành và quan sát
- Setup toàn bộ infrastructure cơ bản (dùng Docker Compose cho môi trường dev, hoặc Terraform nếu muốn thực hành Infrastructure-as-Code) theo kiến trúc đã thiết kế ngày 312.
Advanced concepts
- Infrastructure-as-Code - viết Terraform/Pulumi cho hạ tầng, đảm bảo có thể tái tạo môi trường từ đầu chỉ bằng script (không phụ thuộc thao tác thủ công).

Ngày 314: Setup CI/CD skeleton

Khái niệm
- Thiết lập pipeline CI/CD ngay từ đầu dự án (không để tới cuối mới thêm) - best practice thực tế.
Thực hành và quan sát
- Setup GitHub Actions (hoặc CI tool khác) cho repo capstone, áp dụng lại toàn bộ pattern đã học Phần 11 tuần 60.
Advanced concepts
- Branch protection rule - yêu cầu CI pass + review trước khi merge vào main, mô phỏng quy trình team thật.

Ngày 315: Ôn tập tuần thiết kế + Review kiến trúc với "peer review" tự thực hiện

Khái niệm
- Architecture review - tự đóng vai "reviewer khó tính" review lại chính thiết kế của mình sau 1 ngày nghỉ (khoảng cách thời gian giúp nhìn khách quan hơn).
Thực hành và quan sát
- Đọc lại toàn bộ TDD + diagram đã viết, tìm ít nhất 3 điểm yếu/thiếu sót, cập nhật thiết kế trước khi bắt đầu code chính.
Advanced concepts
- Nếu có thể, nhờ 1 người khác (bạn học, đồng nghiệp) thật sự review - feedback từ người ngoài luôn giá trị hơn tự review.

Tuần 64 (Ngày 316–320): Core development

Ngày 316-317: Xây dựng core logic

Khái niệm
- Tập trung vào phần logic nghiệp vụ quan trọng nhất trước (Hướng A: consensus + execution; Hướng B: ledger engine + core banking logic).
Thực hành và quan sát
- Code core logic với test coverage đầy đủ ngay từ đầu (TDD - Test-Driven Development nếu quen), không để "viết xong rồi mới test".
Advanced concepts
- Domain-Driven Design nhẹ - tách rõ domain logic (business rule) khỏi infrastructure code (database, network) để dễ test và maintain.

Ngày 318: Tích hợp blockchain layer

Khái niệm
- Kết nối phần core logic với blockchain thật (testnet) - Hướng A: network layer cho blockchain tự xây; Hướng B: smart contract settlement + indexer.
Thực hành và quan sát
- Deploy/kết nối và test tích hợp end-to-end lần đầu tiên giữa core logic và blockchain layer.
Advanced concepts
- Xử lý edge case tích hợp: timeout, retry, và (với Hướng B) reorg handling đã học Phần 11 ngày 285.

Ngày 319: Xây dựng API layer & authentication

Khái niệm
- REST/GraphQL API cho hệ thống, authentication/authorization (JWT hoặc session-based tùy thiết kế).
Thực hành và quan sát
- Implement API layer đầy đủ theo OpenAPI spec đã viết ngày 312, thêm authentication middleware.
Advanced concepts
- Rate limiting per-user/per-API-key - bảo vệ hệ thống khỏi abuse ngay từ giai đoạn phát triển, không để "làm sau".

Ngày 320: Ôn tập tuần core development + Integration test

Khái niệm
- Integration test - test toàn bộ luồng end-to-end thay vì chỉ unit test từng phần riêng lẻ.
Thực hành và quan sát
- Viết bộ integration test cho luồng chính của hệ thống (Hướng A: gửi transaction → propagate → finalize; Hướng B: user đăng ký → KYC → deposit → transfer → settlement), chạy tự động trong CI.
Advanced concepts
- Test environment giống production nhất có thể (dùng testnet thật, không mock hoàn toàn) để phát hiện vấn đề tích hợp sớm.

Tuần 65 (Ngày 321–325): Security, monitoring, và hoàn thiện

Ngày 321: Security hardening

Khái niệm
- Áp dụng lại toàn bộ checklist Phần 6 (nếu có smart contract) và Phần 11 (key management, infrastructure security).
Thực hành và quan sát
- Chạy Slither (nếu có smart contract), review key management implementation, đảm bảo không có secret hardcode trong code (dùng Vault/env variable).
Advanced concepts
- Dependency scanning - quét lỗ hổng trong thư viện bên thứ 3 đang dùng (npm audit, cargo audit, hoặc tool tương đương).

Ngày 322: Monitoring & observability

Khái niệm
- Setup đầy đủ Prometheus/Grafana + structured logging cho toàn hệ thống capstone (áp dụng Phần 11 tuần 57).
Thực hành và quan sát
- Dashboard hiển thị metrics quan trọng nhất của hệ thống (Hướng A: peer count, block time, finality time; Hướng B: transaction volume, ledger balance consistency, API latency).
Advanced concepts
- SLI/SLO (Service Level Indicator/Objective) - định nghĩa rõ chỉ số nào là quan trọng nhất và mục tiêu cụ thể (VD: "99% API request dưới 200ms").

Ngày 323: Load testing & performance tuning

Khái niệm
- Áp dụng lại Phần 9 ngày 236 (nếu Hướng A) hoặc thiết kế load test riêng cho API (Hướng B, dùng k6/Locust).
Thực hành và quan sát
- Chạy load test với tải giả lập tăng dần, xác định điểm hệ thống bắt đầu suy giảm hiệu năng (bottleneck), thực hiện ít nhất 1 vòng tối ưu dựa trên kết quả đo được.
Advanced concepts
- So sánh kết quả trước/sau tối ưu bằng số liệu cụ thể (không chỉ cảm tính "nhanh hơn") - viết báo cáo benchmark có bảng số liệu.

Ngày 324: Documentation toàn diện

Khái niệm
- README, API docs, architecture docs, runbook vận hành - tài liệu đủ để người khác tự chạy được dự án từ đầu.
Thực hành và quan sát
- Hoàn thiện toàn bộ tài liệu, nhờ 1 người chưa biết gì về dự án thử làm theo README để verify tính đầy đủ (nếu có thể).
Advanced concepts
- Architecture Decision Records (ADR) - ghi lại các quyết định thiết kế quan trọng kèm lý do, giúp người sau (hoặc chính bạn 6 tháng sau) hiểu tại sao hệ thống được thiết kế như vậy.

Ngày 325: Bug fixing & polish

Khái niệm
- Giai đoạn dọn dẹp cuối cùng - không thêm tính năng mới, chỉ fix bug và cải thiện chất lượng code hiện có.
Thực hành và quan sát
- Review lại toàn bộ codebase, fix mọi warning từ linter/static analysis, đảm bảo test suite pass 100% và ổn định (không flaky test).
Advanced concepts
- Code review checklist cuối cùng - tự đánh giá code theo tiêu chuẩn "sẵn sàng để người khác đọc và maintain", không chỉ "chạy được".

Tuần 66 (Ngày 326–330): Trình bày, và tổng kết

Ngày 326: Deploy lên testnet công khai (hoặc môi trường staging)

Khái niệm
- Go-live checklist đã xây dựng ở Phần 11 ngày 310 - áp dụng thực tế lần này cho chính dự án capstone.
Thực hành và quan sát
- Thực hiện deploy chính thức, verify toàn bộ hệ thống hoạt động đúng trong môi trường gần production nhất có thể.
Advanced concepts
- Rollback plan sẵn sàng - nếu deploy có vấn đề, có kế hoạch quay lại trạng thái ổn định trước đó ngay lập tức.

Ngày 327: Self-audit report cuối cùng

Khái niệm
- Áp dụng lại toàn bộ format audit report (Phần 6 ngày 168) cho TOÀN BỘ hệ thống capstone, không chỉ smart contract.
Thực hành và quan sát
- Viết audit report hoàn chỉnh: Executive Summary, Scope, Findings (kể cả finding về chính hệ thống của mình - trung thực, không giấu điểm yếu), Recommendations.
Advanced concepts
- Đây là tài liệu cực kỳ giá trị cho portfolio - thể hiện khả năng tự đánh giá khách quan, kỹ năng được đánh giá cao trong ngành.

Ngày 328: Chuẩn bị bài trình bày kỹ thuật

Khái niệm
- Technical presentation - cách trình bày 1 hệ thống phức tạp cho nhiều đối tượng khác nhau (kỹ sư khác vs người không chuyên).
Thực hành và quan sát
- Chuẩn bị slide/demo script (15-20 phút): vấn đề giải quyết → kiến trúc → điểm kỹ thuật khó nhất đã vượt qua → demo live → bài học rút ra.
Advanced concepts
- Chuẩn bị trả lời câu hỏi khó (anticipate hard questions) - tự đặt ra 5 câu hỏi "khó nhất" người khác có thể hỏi về thiết kế của bạn và chuẩn bị câu trả lời.

Ngày 329: Trình bày & thu thập feedback

Khái niệm
- Trình bày thật (trước bạn học, đồng nghiệp, cộng đồng online, hoặc ít nhất tự quay video) - feedback từ người khác luôn giá trị hơn tự đánh giá.
Thực hành và quan sát
- Thực hiện trình bày, ghi chú lại mọi câu hỏi/feedback nhận được, đặc biệt các câu hỏi bạn không trả lời được tốt.
Advanced concepts
- Public writeup - viết lại toàn bộ hành trình xây dựng thành 1 bài blog kỹ thuật công khai (Mirror, dev.to, hoặc blog cá nhân) kèm link GitHub - đây là tài sản portfolio quan trọng nhất của toàn khóa học.

Ngày 330: Tổng kết toàn khóa học & lên kế hoạch tiếp theo

Khái niệm
- Retrospective toàn diện 330 ngày: nhìn lại từ Ngày 1 (cài hypervisor) tới hôm nay - con đường đã đi qua 11 Phần lớn.
Thực hành và quan sát
- Viết bài retrospective cá nhân: phần nào khó nhất, phần nào thú vị nhất, kỹ năng nào cần tiếp tục mài giũa; cập nhật CV/portfolio với toàn bộ dự án đã làm (mini EVM, blockchain tự xây, DeFi capstone, neobank capstone...).
Advanced concepts
- Lên kế hoạch học tập liên tục (continuous learning): theo dõi research mới (Ethereum roadmap, ZK proving system mới, quy định pháp lý cập nhật), tham gia cộng đồng (contribute mã nguồn mở tiếp tục, tham gia audit contest như Code4rena/Sherlock để rèn kỹ năng security với tiền thưởng thật).

Command Palette