M10-L03: Signing and nonce manager — Bài học chuyên sâu

1. Bài toán

Signing is separate from broadcast; keys require isolation and explicit chain ID. 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ụ

Concurrent requests may reuse nonce or leak keys. Để 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

Signing is separate from broadcast; keys require isolation and explicit chain ID. 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

Cơ chế: Signing is separate from broadcast; keys require isolation and explicit chain ID.
Bất biến: Dữ liệu hoặc quyền sở hữu không được tự phát sinh ngoài quy tắc đã định; cùng một sự kiện hợp lệ không được tạo hai business effects.
Ranh giới tin cậy: Khóa riêng, RPC provider, contract address, chain ID, validator/network, và DB indexer không có cùng mức độ tin cậy.
Đối chiếu Java backend: @Transactional chỉ bảo vệ database cục bộ; nó không rollback một giao dịch blockchain đã được ghi nhận. Với bài thuần cryptography, hãy phân biệt kiểm tra chữ ký với authorization nghiệp vụ.
Phân tích lỗi: Concurrent requests may reuse nonce or leak keys.

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

Mục tiêu: Use local test signer and serialized nonce allocator.

Đọc PREREQUISITES.md, chọn môi trường offline/local trước; không dùng tiền thật.
Tạo một case happy-path có input cố định và lưu kết quả vào results/normal.txt.
Triển khai logic theo yêu cầu: Use local test signer and serialized nonce allocator.
Viết ít nhất 3 assertions: kết quả chuẩn, input sai, và lặp lại cùng request/event.
Tạo một case lỗi: Concurrent requests may reuse nonce or leak keys. Chụp state trước/sau và giải thích tại sao phải reject hoặc rollback.
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.
Ghi lại command, stdout, transaction hash (nếu có), block number, gas used và cách xác minh.
Chạy lại từ trạng thái sạch để bảo đảm reproducible.

6. Expected output / Acceptance criteria

Concurrent sends receive distinct nonces; keys absent from logs.
Case bất hợp lệ phải trả lỗi rõ ràng hoặc assertion fail có chủ đích, không âm thầm tạo state mới.
Lặp lại test từ trạng thái sạch cho cùng kết quả về tính đúng đắn (hash/nonce có thể thay đổi khi input khác).
Có file results/README.md mô tả input, output và cách kiểm tra.

7. Exercises

Basic: Tự cài đặt happy path mà không xem solution/; đối chiếu với expected output.
Intermediate: Thêm hai actor hoặc hai transaction cạnh tranh; kiểm tra invariant trước và sau.
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ý.
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. What is replacement transaction handling?

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

[ ] Hiểu được cơ chế và tự giải thích bằng lời
[ ] Có happy-path và negative-path test
[ ] Có expected output đã kiểm chứng
[ ] Không dùng mainnet/private key thật
[ ] Ghi lại hạn chế của demo so với production