Mapping, structs and ledger accounting

01 — Bài toán

Thiết kế một Smart Contract có thể được nhiều địa chỉ gọi mà không cần tin cậy một backend quản lý state.

02 — Vấn đề

Code chạy trong EVM, mỗi state write tiêu tốn gas và giao dịch có thể bị gọi từ bất kỳ địa chỉ nào. Java private không tương đương với bí mật on-chain.

03 — Giải pháp

Áp dụng các primitive Solidity đúng ngữ cảnh, xác minh preconditions, cập nhật state nhất quán và kiểm thử trường hợp thất bại.

04 — Lý thuyết

Mappings default to zero values and are not enumerable; struct groups account fields. A Solidity mapping is unlike an iterable Java Map.

So sánh Java: contract giống một stateful service được nhân bản theo đồng thuận; msg.sender tương tự authenticated caller nhưng không tự đảm bảo user identity; storage tồn tại trên chain, không giống Java heap.

Dependency: M04 EVM; M05 bài trước nếu có.

05 — Hands-on lab: Mapping, structs and ledger accounting

Chuẩn bị

• Foundry (forge, cast, anvil); Solidity 0.8.24
• Chạy hoàn toàn local, không dùng mainnet funds

Thực hiện

1. Đọc theory.md và solution/src/Lab.sol, xác định state, invariants và external calls.
2. Tự triển khai starter/src/Lab.sol trước khi xem solution.
3. Viết các test trong starter/test/Lab.t.sol.
4. cd solution && forge build && forge test -vvv
5. forge test --gas-report để quan sát chi phí.
6. forge test -vvvv nếu test fail, đọc call trace và revert reason.

Các test trong reference

• testCredit
• testIsolation
• testZeroReverts

Expected output

forge build thành công, tất cả các test trên PASS. Đây là kết quả dự kiến, chưa được xác minh trong môi trường đóng gói vì không có forge/solc.

Troubleshooting

• forge: command not found: cài Foundry chính thức.
• Compiler download error: kiểm tra network và solc_version.
• Assertion failure: chạy forge test -vvvv để xem trace.

07 — Exercises

1. Implement contract và test từ đầu trong starter/, không copy solution.
2. Implement debit and enforce totalCredit equals the sum of known accounts in tests.
3. Bổ sung ít nhất một negative test (revert) và một edge case.
4. Viết giải thích vì sao state thay đổi hoặc revert; so sánh với Java service.

Acceptance criteria: forge build pass; toàn bộ test pass; không sử dụng tài sản mainnet; README ghi các invariants và assumptions.

08 — Interview

Q1: Vì sao contract cần kiểm tra msg.sender? Bởi mọi địa chỉ đều có thể gửi transaction; quyền phải được enforce on-chain, không thể chỉ dựa vào API gateway.

Q2: view và pure khác nhau thế nào? view có thể đọc state nhưng không sửa state; pure không đọc hoặc sửa state contract.

Q3: Revert ảnh hưởng gì? State updates trong phạm vi bị revert được rollback, nhưng gas đã tiêu thụ không được hoàn lại hoàn toàn.

Q4: Mapping, structs and ledger accounting có rủi ro gì? Kiểm tra access control, arithmetic bounds, external calls, assumptions về người gọi và accounting invariants.