Types, visibility and safe arithmetic

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

State types (uint256, address), visibility (public, external), pure versus state-changing calls and Solidity 0.8 checked arithmetic.

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: Types, visibility and safe arithmetic

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

• testInitialState
• testIncrement
• testPure
• testZeroReverts
• testReset

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. Add decrement with underflow protection and a revert test.
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: Types, visibility and safe arithmetic có rủi ro gì? Kiểm tra access control, arithmetic bounds, external calls, assumptions về người gọi và accounting invariants.