Nhiều lỗi hợp đồng thông minh bắt đầu trước khi lập trình: yêu cầu nghiệp vụ không rõ trạng thái, sự kiện hoặc điều kiện chuyển bước. Khi đó lập trình viên buộc phải tự suy diễn, và mã có thể chạy đúng theo suy diễn nhưng khác ý định của bộ phận BĐS.
Mô hình hóa tốt giúp cả luật sư, chuyên viên nghiệp vụ và kỹ sư nhìn cùng một quy trình. Thay vì nói “khi đủ điều kiện thì trả tiền”, cần chỉ rõ trạng thái hiện tại, điều kiện nào được kiểm tra, dữ liệu đến từ đâu, sự kiện nào kích hoạt, ai có quyền và trạng thái mới là gì.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
1. Một quy trình BĐS nên được biến thành máy trạng thái trước khi biến thành mã
State machine (máy trạng thái) là cách biểu diễn hệ thống bằng các trạng thái hữu hạn và quy tắc chuyển từ trạng thái này sang trạng thái khác. Với hợp đồng thông minh, cách tiếp cận này làm rõ điều gì được phép ở mỗi thời điểm và giúp phát hiện chuyển trạng thái thiếu kiểm soát, gọi lặp hoặc bỏ qua bước bắt buộc.
2. Mục tiêu học tập
- Xác định trạng thái và chuyển trạng thái của một quy trình BĐS.
- Phân biệt điều kiện, sự kiện kích hoạt, dữ liệu và hành động.
- Thiết kế quyền gọi hàm theo vai trò.
- Nhận diện lỗi thứ tự, gọi lặp, trạng thái treo và ngoại lệ.
- Chuyển mô hình nghiệp vụ thành đặc tả có thể kiểm thử.
3. Tình huống BĐS mở bài
Một SPV có quy trình gọi vốn: DRAFT → OPEN → FUNDED → INVESTED → DISTRIBUTING → CLOSED. Nhóm phát triển bỏ qua trạng thái FUNDED và cho phép đầu tư ngay khi có bất kỳ khoản tiền nào. Kết quả: một phần vốn được sử dụng trước khi đạt ngưỡng tối thiểu theo tài liệu chào bán. Lỗi không nằm ở cú pháp mã; lỗi nằm ở mô hình trạng thái thiếu điều kiện nghiệp vụ.
Khi phân tích tình huống, hãy tách thành bốn lớp: dữ kiện đã biết – giả định đang dùng – dữ liệu cần xác minh – người có thẩm quyền quyết định. Cách tách này đặc biệt quan trọng với blockchain vì một chữ ký kỹ thuật hoặc bản ghi trên chuỗi có thể hoàn toàn hợp lệ về mặt máy tính nhưng vẫn không phản ánh đúng quyền, nghĩa vụ hoặc trạng thái thực tế ngoài đời.
4. Khung phân tích dùng xuyên suốt bài
Một giải pháp tài sản số BĐS không nên được xem chỉ như phần mềm. Ít nhất phải đọc đồng thời sáu lớp: tài sản hoặc dòng tiền cơ sở; chủ thể và quyền pháp lý; dữ liệu; cơ chế ký hoặc thực thi; quản trị và kiểm soát; pháp luật áp dụng. Nếu một lớp bị bỏ trống, tự động hóa ở lớp còn lại có thể làm sai sót lan nhanh hơn.
| Lớp | Câu hỏi trọng tâm | Bằng chứng cần có |
|---|---|---|
| Tài sản/quy trình | Đang kiểm soát cái gì và vì sao? | Quy trình, hợp đồng, tài sản cơ sở, dòng tiền. |
| Chủ thể/quyền | Ai có quyền ra quyết định? | Điều lệ, ủy quyền, hồ sơ định danh, hạn mức. |
| Dữ liệu | Dữ liệu đến từ đâu và ai chịu trách nhiệm? | Nguồn, thời điểm, phiên bản, chữ ký hoặc dấu kiểm chứng. |
| Kỹ thuật | Hệ thống ký/thực thi điều gì? | Mã, khóa, cấu hình, nhật ký, kết quả kiểm thử. |
| Quản trị | Ai giám sát, ai xử lý ngoại lệ? | Ma trận quyền, cảnh báo, quy trình sự cố. |
| Pháp lý | Quyền và nghĩa vụ được công nhận theo căn cứ nào? | Văn bản pháp luật, hợp đồng, hồ sơ pháp lý. |
5. Các nguyên lý cốt lõi
5.1. Trạng thái phải phản ánh mốc nghiệp vụ có ý nghĩa
Không nên tạo trạng thái chỉ vì tiện lập trình. Mỗi trạng thái cần gắn với quyền, dữ liệu hoặc hành động khác nhau.
Ví dụ BĐS: hợp đồng thuê có thể là DRAFT, ACTIVE, SUSPENDED, TERMINATED, EXPIRED.
Điểm kiểm soát: mô tả ý nghĩa và tiêu chí vào/ra của từng trạng thái.
5.2. Điều kiện là biểu thức phải kiểm tra trước khi chuyển trạng thái
Điều kiện có thể là số tiền, thời gian, quyền, trạng thái trước đó hoặc kết quả oracle. Điều kiện phải đo được và có nguồn dữ liệu.
Ví dụ BĐS: chỉ chuyển FUNDED khi tổng vốn hợp lệ đạt ngưỡng và kỳ gọi vốn chưa hết.
Điểm kiểm soát: mỗi điều kiện phải có ca kiểm thử đúng, sai và biên.
5.3. Sự kiện kích hoạt khác với điều kiện
Sự kiện là điều xảy ra khiến hệ thống xem xét chuyển trạng thái; điều kiện quyết định có được chuyển hay không.
Ví dụ BĐS: hết ngày gọi vốn là sự kiện; đạt tối thiểu 80% vốn là điều kiện để chuyển sang FUNDED.
Điểm kiểm soát: không nhầm đồng hồ thời gian với bằng chứng nghiệp vụ.
5.4. Hành động phải nguyên tử hoặc có cơ chế bù trừ
Nếu một bước thay trạng thái, chuyển token và ghi sự kiện, cần xem điều gì xảy ra nếu một phần thất bại. Blockchain thường xử lý giao dịch nguyên tử trong một giao dịch, nhưng tích hợp ngoài chuỗi không nhất thiết.
Ví dụ BĐS: hợp đồng thông minh chuyển token thành công nhưng hệ thống kế toán chưa cập nhật.
Điểm kiểm soát: thiết kế idempotency, thử lại và đối soát.
5.5. Quyền gọi hàm là một phần của trạng thái
Một hàm hợp lệ về logic nhưng được người không đúng vai trò gọi vẫn là lỗ hổng. Cần mô hình vai trò song song với trạng thái.
Ví dụ BĐS: chỉ quản lý quỹ được mở kỳ phân phối; nhà đầu tư chỉ được nhận phần của mình.
Điểm kiểm soát: bảng quyền vai trò–hàm–trạng thái.
5.6. Sự kiện blockchain là bằng chứng kỹ thuật, không phải chứng cứ đầy đủ
Nhật ký sự kiện hữu ích cho tích hợp và kiểm toán nhưng có ý nghĩa trong ngữ cảnh hợp đồng, chuỗi và dữ liệu đầu vào. Nó không tự chứng minh sự kiện ngoài đời đã xảy ra đúng.
Ví dụ BĐS: sự kiện `PropertyInspected` chỉ chứng minh mã ghi sự kiện, không tự chứng minh kỹ sư đã kiểm tra hiện trường.
Điểm kiểm soát: chỉ rõ nguồn xác nhận và tài liệu ngoài chuỗi.
5.7. Phải chống gọi lặp và chuyển trạng thái hai lần
Hàm phân phối hoặc hoàn tiền thường có rủi ro bị gọi lặp nếu không đánh dấu trạng thái đúng hoặc logic có lỗi.
Ví dụ BĐS: nhà đầu tư nhận lợi nhuận hai lần.
Điểm kiểm soát: cập nhật trạng thái trước hoặc đồng thời với chuyển giá trị và kiểm thử gọi lặp.
5.8. Trạng thái treo cần đường thoát
Quy trình có thể dừng vì oracle không cập nhật, một bên không ký hoặc hết thời hạn. Nếu không có timeout và cơ chế giải quyết, tài sản có thể bị khóa.
Ví dụ BĐS: escrow chờ xác nhận bàn giao nhưng đơn vị kiểm định giải thể.
Điểm kiểm soát: timeout, vai trò trọng tài hoặc cơ chế hoàn tiền có điều kiện.
6. Bảng so sánh để ra quyết định
| Thành phần | Câu hỏi | Ví dụ | Lỗi thường gặp |
|---|---|---|---|
| Trạng thái | Hệ thống đang ở đâu? | OPEN | Tên trạng thái không gắn nghĩa nghiệp vụ |
| Sự kiện | Điều gì vừa xảy ra? | Hết hạn gọi vốn | Nhầm sự kiện với điều kiện |
| Điều kiện | Có được chuyển không? | Đủ vốn tối thiểu | Nguồn dữ liệu không rõ |
| Hành động | Hệ thống làm gì? | Chuyển token/ghi sổ | Một phần ngoài chuỗi thất bại |
| Vai trò | Ai được gọi? | Quản lý quỹ | Quyền quá rộng |
Bảng trên là công cụ phân tích chứ không phải công thức pháp lý. Khi áp dụng vào dự án thật phải cập nhật theo giá trị giao dịch, cấu trúc pháp nhân, quy định nội bộ, loại BĐS, hệ thống công nghệ và thời điểm triển khai.
7. Quy trình thực hành đề xuất
- Bước 1. Liệt kê toàn bộ mốc nghiệp vụ trên giấy trước khi viết mã. Đầu ra của bước này phải là tài liệu, cấu hình, bằng chứng hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng.
- Bước 2. Định nghĩa trạng thái và ý nghĩa của từng trạng thái. Đầu ra của bước này phải là tài liệu, cấu hình, bằng chứng hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng.
- Bước 3. Vẽ mọi chuyển trạng thái và sự kiện kích hoạt. Đầu ra của bước này phải là tài liệu, cấu hình, bằng chứng hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng.
- Bước 4. Gắn điều kiện và nguồn dữ liệu cho từng chuyển. Đầu ra của bước này phải là tài liệu, cấu hình, bằng chứng hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng.
- Bước 5. Gắn vai trò được phép và hạn mức. Đầu ra của bước này phải là tài liệu, cấu hình, bằng chứng hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng.
- Bước 6. Xác định timeout, hủy, hoàn tiền và đường xử lý ngoại lệ. Đầu ra của bước này phải là tài liệu, cấu hình, bằng chứng hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng.
- Bước 7. Chuyển sơ đồ thành bảng ca kiểm thử. Đầu ra của bước này phải là tài liệu, cấu hình, bằng chứng hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng.
- Bước 8. Đối chiếu sơ đồ với mã sau mỗi thay đổi. Đầu ra của bước này phải là tài liệu, cấu hình, bằng chứng hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng.
Điểm quan trọng là mỗi bước phải chỉ rõ người chịu trách nhiệm – dữ liệu đầu vào – tiêu chí đạt – bằng chứng đầu ra – cách xử lý nếu không đạt. Đây là cách biến một ý tưởng công nghệ thành quy trình có thể quản trị và kiểm toán.
8. Ma trận kiểm soát tối thiểu
| Nhóm kiểm soát | Mục tiêu | Bằng chứng nên lưu | Câu hỏi kiểm toán |
|---|---|---|---|
| Phân quyền | Không để một người tự hoàn tất giao dịch quan trọng | Ma trận quyền, danh sách vai trò, lịch sử thay đổi | Có ai vừa tạo, vừa duyệt, vừa ký và vừa đối soát không? |
| Dữ liệu | Đầu vào đúng nguồn, đúng phiên bản và còn hiệu lực | Nguồn, dấu thời gian, phiên bản, mã băm/chữ ký | Có thể truy ngược dữ liệu đến nguồn gốc không? |
| Giao dịch | Nội dung ký khớp quyết định nghiệp vụ | Phiếu lệnh, payload, địa chỉ, số lượng, mã giao dịch | Người ký có nhìn thấy đúng dữ liệu đã được duyệt? |
| Giám sát | Phát hiện bất thường đủ sớm | Cảnh báo, nhật ký, vụ việc và kết quả xử lý | Cảnh báo có người độc lập xử lý và đóng vụ việc? |
| Phục hồi | Hệ thống vẫn hoạt động khi mất người/thiết bị/nguồn | Biên bản diễn tập, RTO/RPO hoặc mục tiêu tương đương | Lần gần nhất tổ chức kiểm thử thực tế là khi nào? |
| Pháp lý | Bản ghi kỹ thuật nối đúng quyền/nghĩa vụ | Hợp đồng, ủy quyền, hồ sơ pháp lý, ý kiến tuân thủ | Điều gì xảy ra nếu code và văn bản không giống nhau? |
9. Bối cảnh pháp lý và quản trị cần lưu ý
Mô hình trạng thái là công cụ kỹ thuật; trạng thái `OWNED` hoặc `TRANSFERRED` trong hợp đồng không tự có nghĩa pháp lý tương đương quyền sở hữu/chuyển quyền BĐS.
Các mốc pháp lý như ký hợp đồng, công chứng, đăng ký hoặc hoàn tất nghĩa vụ cần được mô hình hóa dựa trên pháp luật thực tế và nguồn xác nhận có thẩm quyền.
Trong thiết kế dữ liệu cá nhân và nhật ký, vẫn phải áp dụng quy định bảo vệ dữ liệu hiện hành thay vì mặc định mọi trạng thái nên công khai trên chuỗi.
Các nội dung pháp lý trong bài nhằm giúp sinh viên nhận diện lớp vấn đề cần kiểm tra. Khi triển khai dự án thật, tổ chức phải đối chiếu văn bản đang có hiệu lực, phạm vi giấy phép, loại sản phẩm, tư cách nhà đầu tư và cấu trúc quyền đối với tài sản cơ sở; không được suy từ một nguyên tắc kỹ thuật thành kết luận pháp lý.
10. Những cách hiểu sai thường gặp
10.1. “Chỉ cần viết if/else là đủ”
Quy trình nhiều bước cần mô hình trạng thái và quyền.
10.2. “Nhật ký sự kiện chứng minh sự kiện thật”
Nhật ký chỉ chứng minh hợp đồng phát sự kiện theo dữ liệu đã nhận.
10.3. “Mọi lỗi có thể sửa bằng nâng cấp”
Nâng cấp có rủi ro quản trị và không sửa được hậu quả giao dịch đã hoàn tất.
10.4. “Trạng thái càng nhiều càng chính xác”
Quá nhiều trạng thái làm hệ thống phức tạp nếu không có ý nghĩa nghiệp vụ.
11. Case study tổng hợp
Mô hình hóa quy trình escrow cho tiền đặt cọc thuê văn phòng: tạo khoản đặt cọc, nhận tiền, chờ bàn giao, xác nhận đủ điều kiện, giải phóng tiền hoặc hoàn trả. Xác định trạng thái, timeout, người xác nhận và trường hợp tranh chấp.
Nhóm học viên không nên trả lời bằng một danh sách công nghệ. Hãy lập bảng gồm: chủ thể – quyền – dữ liệu – sự kiện – kiểm soát – ngoại lệ – bằng chứng. Với mỗi quyết định, giải thích vì sao chọn mức kiểm soát đó và điều gì sẽ xảy ra nếu một lớp bị lỗi.
| Hạng mục | Câu hỏi phải trả lời | Đầu ra |
|---|---|---|
| Phạm vi | Giao dịch/tài sản nào nằm trong bài toán? | Sơ đồ phạm vi và tài sản. |
| Chủ thể | Ai tham gia và ai có thẩm quyền? | Ma trận vai trò/quyền. |
| Dữ liệu | Thông tin nào quyết định hành động? | Danh mục dữ liệu và nguồn. |
| Kiểm soát | Điểm nào cần hai người hoặc cơ chế độc lập? | Luồng phê duyệt. |
| Ngoại lệ | Nếu dữ liệu sai, mất khóa hoặc hệ thống dừng? | Kịch bản xử lý. |
| Kiểm toán | Làm sao chứng minh giao dịch được xử lý đúng? | Bộ bằng chứng cuối. |
12. Phòng thực hành phân tích sâu
Tình huống 1: Trạng thái phải phản ánh mốc nghiệp vụ có ý nghĩa
Giả sử hệ thống đã vận hành sáu tháng và xuất hiện một sự cố liên quan trực tiếp nguyên lý này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu/đầu vào – lỗi quyền hoặc quy trình – lỗi kỹ thuật. Không được kết luận trước khi có bằng chứng.
Dữ kiện nền: Không nên tạo trạng thái chỉ vì tiện lập trình. Mỗi trạng thái cần gắn với quyền, dữ liệu hoặc hành động khác nhau.
Bối cảnh BĐS để phân tích: hợp đồng thuê có thể là DRAFT, ACTIVE, SUSPENDED, TERMINATED, EXPIRED.
Yêu cầu xử lý: mô tả ý nghĩa và tiêu chí vào/ra của từng trạng thái. Sau đó xác định người có quyền ra quyết định, thời hạn phản ứng, dữ liệu cần khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.
Câu hỏi phản biện: Nếu bỏ blockchain và dùng cơ sở dữ liệu truyền thống thì kiểm soát này còn cần không? Nếu câu trả lời là có, hãy chỉ ra phần nào là kiểm soát quản trị chung và phần nào đặc thù của tài sản số.
Tình huống 2: Điều kiện là biểu thức phải kiểm tra trước khi chuyển trạng thái
Giả sử hệ thống đã vận hành sáu tháng và xuất hiện một sự cố liên quan trực tiếp nguyên lý này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu/đầu vào – lỗi quyền hoặc quy trình – lỗi kỹ thuật. Không được kết luận trước khi có bằng chứng.
Dữ kiện nền: Điều kiện có thể là số tiền, thời gian, quyền, trạng thái trước đó hoặc kết quả oracle. Điều kiện phải đo được và có nguồn dữ liệu.
Bối cảnh BĐS để phân tích: chỉ chuyển FUNDED khi tổng vốn hợp lệ đạt ngưỡng và kỳ gọi vốn chưa hết.
Yêu cầu xử lý: mỗi điều kiện phải có ca kiểm thử đúng, sai và biên. Sau đó xác định người có quyền ra quyết định, thời hạn phản ứng, dữ liệu cần khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.
Câu hỏi phản biện: Nếu bỏ blockchain và dùng cơ sở dữ liệu truyền thống thì kiểm soát này còn cần không? Nếu câu trả lời là có, hãy chỉ ra phần nào là kiểm soát quản trị chung và phần nào đặc thù của tài sản số.
Tình huống 3: Sự kiện kích hoạt khác với điều kiện
Giả sử hệ thống đã vận hành sáu tháng và xuất hiện một sự cố liên quan trực tiếp nguyên lý này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu/đầu vào – lỗi quyền hoặc quy trình – lỗi kỹ thuật. Không được kết luận trước khi có bằng chứng.
Dữ kiện nền: Sự kiện là điều xảy ra khiến hệ thống xem xét chuyển trạng thái; điều kiện quyết định có được chuyển hay không.
Bối cảnh BĐS để phân tích: hết ngày gọi vốn là sự kiện; đạt tối thiểu 80% vốn là điều kiện để chuyển sang FUNDED.
Yêu cầu xử lý: không nhầm đồng hồ thời gian với bằng chứng nghiệp vụ. Sau đó xác định người có quyền ra quyết định, thời hạn phản ứng, dữ liệu cần khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.
Câu hỏi phản biện: Nếu bỏ blockchain và dùng cơ sở dữ liệu truyền thống thì kiểm soát này còn cần không? Nếu câu trả lời là có, hãy chỉ ra phần nào là kiểm soát quản trị chung và phần nào đặc thù của tài sản số.
Tình huống 4: Hành động phải nguyên tử hoặc có cơ chế bù trừ
Giả sử hệ thống đã vận hành sáu tháng và xuất hiện một sự cố liên quan trực tiếp nguyên lý này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu/đầu vào – lỗi quyền hoặc quy trình – lỗi kỹ thuật. Không được kết luận trước khi có bằng chứng.
Dữ kiện nền: Nếu một bước thay trạng thái, chuyển token và ghi sự kiện, cần xem điều gì xảy ra nếu một phần thất bại. Blockchain thường xử lý giao dịch nguyên tử trong một giao dịch, nhưng tích hợp ngoài chuỗi không nhất thiết.
Bối cảnh BĐS để phân tích: hợp đồng thông minh chuyển token thành công nhưng hệ thống kế toán chưa cập nhật.
Yêu cầu xử lý: thiết kế idempotency, thử lại và đối soát. Sau đó xác định người có quyền ra quyết định, thời hạn phản ứng, dữ liệu cần khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.
Câu hỏi phản biện: Nếu bỏ blockchain và dùng cơ sở dữ liệu truyền thống thì kiểm soát này còn cần không? Nếu câu trả lời là có, hãy chỉ ra phần nào là kiểm soát quản trị chung và phần nào đặc thù của tài sản số.
Tình huống 5: Quyền gọi hàm là một phần của trạng thái
Giả sử hệ thống đã vận hành sáu tháng và xuất hiện một sự cố liên quan trực tiếp nguyên lý này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu/đầu vào – lỗi quyền hoặc quy trình – lỗi kỹ thuật. Không được kết luận trước khi có bằng chứng.
Dữ kiện nền: Một hàm hợp lệ về logic nhưng được người không đúng vai trò gọi vẫn là lỗ hổng. Cần mô hình vai trò song song với trạng thái.
Bối cảnh BĐS để phân tích: chỉ quản lý quỹ được mở kỳ phân phối; nhà đầu tư chỉ được nhận phần của mình.
Yêu cầu xử lý: bảng quyền vai trò–hàm–trạng thái. Sau đó xác định người có quyền ra quyết định, thời hạn phản ứng, dữ liệu cần khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.
Câu hỏi phản biện: Nếu bỏ blockchain và dùng cơ sở dữ liệu truyền thống thì kiểm soát này còn cần không? Nếu câu trả lời là có, hãy chỉ ra phần nào là kiểm soát quản trị chung và phần nào đặc thù của tài sản số.
Tình huống 6: Sự kiện blockchain là bằng chứng kỹ thuật, không phải chứng cứ đầy đủ
Giả sử hệ thống đã vận hành sáu tháng và xuất hiện một sự cố liên quan trực tiếp nguyên lý này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu/đầu vào – lỗi quyền hoặc quy trình – lỗi kỹ thuật. Không được kết luận trước khi có bằng chứng.
Dữ kiện nền: Nhật ký sự kiện hữu ích cho tích hợp và kiểm toán nhưng có ý nghĩa trong ngữ cảnh hợp đồng, chuỗi và dữ liệu đầu vào. Nó không tự chứng minh sự kiện ngoài đời đã xảy ra đúng.
Bối cảnh BĐS để phân tích: sự kiện `PropertyInspected` chỉ chứng minh mã ghi sự kiện, không tự chứng minh kỹ sư đã kiểm tra hiện trường.
Yêu cầu xử lý: chỉ rõ nguồn xác nhận và tài liệu ngoài chuỗi. Sau đó xác định người có quyền ra quyết định, thời hạn phản ứng, dữ liệu cần khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.
Câu hỏi phản biện: Nếu bỏ blockchain và dùng cơ sở dữ liệu truyền thống thì kiểm soát này còn cần không? Nếu câu trả lời là có, hãy chỉ ra phần nào là kiểm soát quản trị chung và phần nào đặc thù của tài sản số.
Tình huống 7: Phải chống gọi lặp và chuyển trạng thái hai lần
Giả sử hệ thống đã vận hành sáu tháng và xuất hiện một sự cố liên quan trực tiếp nguyên lý này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu/đầu vào – lỗi quyền hoặc quy trình – lỗi kỹ thuật. Không được kết luận trước khi có bằng chứng.
Dữ kiện nền: Hàm phân phối hoặc hoàn tiền thường có rủi ro bị gọi lặp nếu không đánh dấu trạng thái đúng hoặc logic có lỗi.
Bối cảnh BĐS để phân tích: nhà đầu tư nhận lợi nhuận hai lần.
Yêu cầu xử lý: cập nhật trạng thái trước hoặc đồng thời với chuyển giá trị và kiểm thử gọi lặp. Sau đó xác định người có quyền ra quyết định, thời hạn phản ứng, dữ liệu cần khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.
Câu hỏi phản biện: Nếu bỏ blockchain và dùng cơ sở dữ liệu truyền thống thì kiểm soát này còn cần không? Nếu câu trả lời là có, hãy chỉ ra phần nào là kiểm soát quản trị chung và phần nào đặc thù của tài sản số.
Tình huống 8: Trạng thái treo cần đường thoát
Giả sử hệ thống đã vận hành sáu tháng và xuất hiện một sự cố liên quan trực tiếp nguyên lý này. Nhóm học viên phải lập ba giả thuyết: lỗi dữ liệu/đầu vào – lỗi quyền hoặc quy trình – lỗi kỹ thuật. Không được kết luận trước khi có bằng chứng.
Dữ kiện nền: Quy trình có thể dừng vì oracle không cập nhật, một bên không ký hoặc hết thời hạn. Nếu không có timeout và cơ chế giải quyết, tài sản có thể bị khóa.
Bối cảnh BĐS để phân tích: escrow chờ xác nhận bàn giao nhưng đơn vị kiểm định giải thể.
Yêu cầu xử lý: timeout, vai trò trọng tài hoặc cơ chế hoàn tiền có điều kiện. Sau đó xác định người có quyền ra quyết định, thời hạn phản ứng, dữ liệu cần khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.
Câu hỏi phản biện: Nếu bỏ blockchain và dùng cơ sở dữ liệu truyền thống thì kiểm soát này còn cần không? Nếu câu trả lời là có, hãy chỉ ra phần nào là kiểm soát quản trị chung và phần nào đặc thù của tài sản số.
13. Bài tập thực hành
- Vẽ sơ đồ trạng thái cho case escrow bằng ít nhất 6 trạng thái. Bài làm phải nêu giả định, dữ liệu cần thu thập, phương án lựa chọn và lý do loại bỏ ít nhất một phương án khác.
- Viết bảng chuyển trạng thái gồm trạng thái hiện tại, kích hoạt, điều kiện, người thực hiện, hành động, trạng thái mới. Bài làm phải nêu giả định, dữ liệu cần thu thập, phương án lựa chọn và lý do loại bỏ ít nhất một phương án khác.
- Thiết kế 12 ca kiểm thử cho thứ tự sai, gọi lặp và timeout. Bài làm phải nêu giả định, dữ liệu cần thu thập, phương án lựa chọn và lý do loại bỏ ít nhất một phương án khác.
- Chỉ ra những sự kiện ngoài đời nào cần oracle hoặc xác nhận con người. Bài làm phải nêu giả định, dữ liệu cần thu thập, phương án lựa chọn và lý do loại bỏ ít nhất một phương án khác.
14. Bộ câu hỏi tự kiểm tra trước khi triển khai
- Tài sản hoặc dòng tiền cơ sở đã được mô tả rõ chưa?
- Quyền pháp lý và quyền kỹ thuật đã được tách riêng chưa?
- Có điểm nào một cá nhân có thể tự hoàn tất giao dịch quan trọng không?
- Dữ liệu quyết định giao dịch có nguồn, thời điểm và người chịu trách nhiệm không?
- Hệ thống có cơ chế phát hiện dữ liệu quá cũ, sai đơn vị hoặc sai phiên bản không?
- Quy trình thay đổi khóa, vai trò hoặc cấu hình có phê duyệt tăng cường không?
- Có kế hoạch khi một người, thiết bị, nhà cung cấp hoặc oracle không khả dụng không?
- Nhật ký kỹ thuật có nối được với hồ sơ quyết định nghiệp vụ không?
- Dữ liệu cá nhân/bí mật kinh doanh đã được tối thiểu hóa trên chuỗi chưa?
- Đã kiểm thử tình huống xấu và ngoại lệ, không chỉ đường đi bình thường chưa?
- Có người độc lập đối soát sau giao dịch không?
- Có tiêu chí dừng dự án nếu blockchain không tạo giá trị hơn phương án đơn giản hơn không?
15. Nguồn tham khảo chính
- Ethereum.org – Anatomy of smart contracts.
- Ethereum.org – Introduction to smart contracts.
- OWASP Smart Contract Top 10: 2025.
- NIST IR 8202 – Blockchain Technology Overview.
Nguồn được dùng để kiểm định khái niệm, nguyên tắc kiểm soát và bối cảnh pháp lý/kỹ thuật. Các tình huống BĐS trong bài là tình huống học tập do tác giả xây dựng; không phải tư vấn pháp lý, đầu tư hoặc khuyến nghị phát hành/giao dịch tài sản mã hóa.
Ghi nhớ trong 30 giây
- Trạng thái, sự kiện, điều kiện và hành động là bốn khái niệm khác nhau.
- Máy trạng thái giúp nghiệp vụ và kỹ thuật nói cùng một ngôn ngữ.
- Quyền gọi hàm phải được mô hình cùng trạng thái.
- Timeout và đường thoát là bắt buộc cho quy trình có phụ thuộc bên ngoài.
- Sự kiện trên chuỗi không tự chứng minh sự kiện ngoài đời.
Bài tiếp theo: Oracle là gì và vì sao blockchain không tự biết giá BĐS, lãi suất hay trạng thái thanh toán?