M11-L04 · Web3 System Design

Unknown payment outcomes

M11-L04: Unknown payment outcomes — Bài học chuyên sâu

1. Bài toán

Broadcast/receipt timeouts do not imply failure; reconciliation queries chain state. Hãy tưởng tượng một dịch vụ có hai client đồng thời và một lỗi mạng đúng lúc ghi nhận kết quả. Ai là nguồn sự thật, trạng thái nào có thể xác minh và phần nào vẫn phải tin tưởng?

2. Vấn đề và phản ví dụ

Retrying payment as a new tx may double-send. Để tái hiện, xây một trường hợp bình thường và một trường hợp cố tình vi phạm giả định. Không coi một HTTP response thành công là bằng chứng blockchain đã final.

3. Giải pháp và trade-off

Broadcast/receipt timeouts do not imply failure; reconciliation queries chain state. Thiết kế phải phân biệt dữ liệu on-chain và off-chain, transaction đã ký và transaction đã được thực thi, dữ liệu provisional và finalized. Trade-off cần đánh giá: phí gas, độ trễ, quyền admin, khả năng nâng cấp, tính khả dụng của RPC, và recovery sau crash.

4. Lý thuyết cốt lõi

5. Lab — triển khai từng bước

Mục tiêu: Model CREATED,SIGNED,BROADCAST,UNKNOWN,CONFIRMED,FAILED.

  1. Đọc PREREQUISITES.md, chọn môi trường offline/local trước; không dùng tiền thật.
  2. Tạo một case happy-path có input cố định và lưu kết quả vào results/normal.txt.
  3. Triển khai logic theo yêu cầu: Model CREATED,SIGNED,BROADCAST,UNKNOWN,CONFIRMED,FAILED.
  4. Viết ít nhất 3 assertions: kết quả chuẩn, input sai, và lặp lại cùng request/event.
  5. Tạo một case lỗi: Retrying payment as a new tx may double-send. Chụp state trước/sau và giải thích tại sao phải reject hoặc rollback.
  6. Nếu có blockchain node, dùng Anvil; nếu là thuật toán, dùng Java/JUnit; nếu là contract, dùng Forge.
  7. Ghi lại command, stdout, transaction hash (nếu có), block number, gas used và cách xác minh.
  8. Chạy lại từ trạng thái sạch để bảo đảm reproducible.

6. Expected output / Acceptance criteria

7. Exercises

  1. Basic: Tự cài đặt happy path mà không xem solution/; đối chiếu với expected output.
  2. Intermediate: Thêm hai actor hoặc hai transaction cạnh tranh; kiểm tra invariant trước và sau.
  3. Advanced: Inject một failure (timeout, duplicate, wrong chain, revert, hoặc reorg tùy bài); viết regression test chứng minh đã xử lý.
  4. Review: Giải thích điều gì sẽ thay đổi nếu triển khai trên BSC Testnet thay vì Anvil.

8. Interview

Q1. When is FAILED actually safe to assign?

Gợi ý: bắt đầu từ cơ chế, chỉ ra giả định, đưa phản ví dụ, nêu cách test và trade-off.

Q2. Khi nào không nên dùng blockchain cho bài toán này?

Trả lời theo tiêu chí: các bên có cần xác minh độc lập không, ai được sửa dữ liệu, chi phí vận hành, tính riêng tư và latency.

Q3. Nếu RPC timeout hoặc process crash, kết quả nào còn đáng tin?

Phân biệt local request status, tx hash, receipt, canonical block, và trạng thái đã đạt finality theo chính sách.

9. Checklist hoàn thành