Case study: mô hình hợp đồng thông minh giải ngân theo điều kiện giả lập

Các khái niệm hợp đồng thông minh, oracle, điều kiện và trạng thái chỉ trở nên rõ khi đặt vào một quy trình cụ thể. Một mô hình giải ngân theo tiến độ là tình huống phù hợp để thấy công nghệ có thể tự động hóa được gì và điểm nào vẫn cần kiểm soát nghiệp vụ.

Trong case study này, không giả định blockchain thay ngân hàng, thay hồ sơ pháp lý hay thay người nghiệm thu. Mục tiêu là thiết kế một lớp điều phối và lưu dấu: tiền chỉ được phép đi tiếp khi tập hợp điều kiện đã được xác minh theo quy tắc.

Tình huống được xây dựng cho mục đích học tập. Người học phải liên tục hỏi: dữ liệu đến từ đâu, ai có quyền xác nhận, điều kiện nào có thể đảo ngược và điều gì xảy ra nếu các bên không đồng ý.

Chuyên đề: Blockchain và tài sản số trong BĐS · Bài 24 · Phần 3: Hợp đồng thông minh và Oracle

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. Từ “giải ngân tự động” đến một mô hình trạng thái có kiểm soát

Một khoản giải ngân không nên được mô hình hóa bằng duy nhất câu lệnh “nếu đủ điều kiện thì chuyển tiền”. Hệ thống cần biết khoản tiền đang ở trạng thái nào, dữ liệu nào đã nhận, điều kiện nào thiếu, ai đang có quyền can thiệp, thời gian chờ bao lâu và khi nào chuyển sang tranh chấp hoặc hoàn trả.

Điểm quan trọng là không đánh đồng bản ghi kỹ thuật với quyền pháp lý. Blockchain có thể giúp nhiều bên cùng kiểm chứng một trạng thái hoặc tự động thực hiện một số bước đã được mã hóa, nhưng nó không tự xác nhận sự thật ngoài đời, không tự tạo quyền sử dụng đất, quyền sở hữu công trình, quyền đối với phần vốn hoặc quyền nhận dòng tiền. Mọi thiết kế phải nêu rõ tài sản cơ sở là gì, token hoặc trạng thái trên chuỗi đại diện cho điều gì và chứng cứ pháp lý nằm ở đâu.

2. Mục tiêu học tập

Xây được máy trạng thái cho giải ngân theo mốc.
Xác định dữ liệu/oracle và quyền xác nhận cho từng điều kiện.
Thiết kế tách nhiệm vụ giữa bên đề nghị, bên xác minh, bên phê duyệt và bên nhận tiền.
Mô phỏng tranh chấp, dữ liệu đến muộn và nguồn dữ liệu bị lỗi.
Đánh giá khi nào mô hình lai phù hợp hơn tự động hóa hoàn toàn.

3. Tình huống BĐS mở bài

Giả định một dự án có ba đợt giải ngân cho nhà thầu. Mỗi đợt cần đủ: hồ sơ yêu cầu thanh toán, xác nhận khối lượng, xác nhận không có cờ tranh chấp và phê duyệt của chủ thể có thẩm quyền. Nhóm muốn dùng hợp đồng thông minh để giữ trạng thái và chỉ phát lệnh giải ngân khi đủ điều kiện. Ngày thứ 10, xác nhận khối lượng đến trước hồ sơ thanh toán; ngày thứ 11 có cờ tranh chấp rồi được gỡ; ngày thứ 12 oracle gửi lại thông điệp cũ. Thiết kế phải xử lý được toàn bộ chuỗi này.

Khi phân tích, nhóm học viên phải tách bốn cột: 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. Nếu chưa xác định được một cột, không được lấy sự “tự động” của hệ thống làm bằng chứng thay thế. Cách làm này giúp tránh lỗi phổ biến: mã chạy đúng nhưng nghiệp vụ sai, dữ liệu đúng định dạng nhưng sai thực tế, hoặc token chuyển thành công nhưng quyền ngoài đời chưa hề chuyển.

4. Khung phân tích dùng xuyên suốt bài

Một ứng dụng blockchain trong BĐS chỉ có ý nghĩa khi đồng thời đọc được sáu lớp sau. Sáu lớp này phải nối được với nhau bằng bằng chứ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 phân tích	Câu hỏi bắt buộc	Bằng chứng nên có
Tài sản/quy trình	Đang xử lý tài sản, quyền lợi hay dòng tiền nào?	Hồ sơ tài sản cơ sở, hợp đồng, quy trình nghiệp vụ.
Chủ thể/quyền	Ai có quyền quyết định và quyền đó đến từ đâu?	Điều lệ, ủy quyền, hợp đồng, hồ sơ pháp lý.
Dữ liệu	Dữ liệu nào kích hoạt quyết định và ai chịu trách nhiệm?	Nguồn dữ liệu, thời điểm, phiên bản, dấu kiểm chứng.
Kỹ thuật	Mã thực thi điều gì và điều gì nằm ngoài mã?	Mã nguồn, cấu hình, kiểm thử, nhật ký và kết quả đối soát.
Quản trị	Ai được thay đổi, tạm dừng, xử lý ngoại lệ?	Ma trận quyền, ngưỡng phê duyệt, nhật ký thay đổi.
Pháp lý	Quyền, nghĩa vụ và hiệu lực giao dịch dựa trên căn cứ nào?	Văn bản pháp luật, hợp đồng, hồ sơ đăng ký và ý kiến chuyên môn khi cần.

Câu hỏi trung tâm của Bài 24: Có thể thiết kế một luồng giải ngân theo điều kiện sao cho tự động phần rõ ràng nhưng vẫn bảo toàn quyền dừng, kiểm tra và giải quyết ngoại lệ? Khi trả lời, không chỉ hỏi “công nghệ có làm được không”, mà phải hỏi thêm “ai chịu trách nhiệm, quyền nào phát sinh, dữ liệu nào được tin, ngoại lệ xử lý ra sao và pháp luật nào chi phối”.

5. Các nguyên lý cốt lõi

5.1. Máy trạng thái giúp ngăn bỏ qua bước

Mỗi khoản giải ngân nên đi qua các trạng thái được định nghĩa, ví dụ khởi tạo, chờ hồ sơ, chờ xác nhận, đủ điều kiện, tạm dừng, đã giải ngân hoặc hủy. Chuyển trạng thái chỉ xảy ra theo quy tắc.

Ví dụ BĐS: Đợt 2 không thể sang “đủ điều kiện” nếu đợt 1 chưa đóng hoặc hồ sơ bắt buộc chưa có.

Điểm kiểm soát: Lập sơ đồ trạng thái và cấm mọi chuyển trạng thái không được định nghĩa.

Câu hỏi phản biện: Nếu dữ liệu đầu vào bị sai, người có thẩm quyền thay đổi hoặc hệ thống ngoài chuỗi ngừng hoạt động, nguyên lý này còn đứng vững không? Hãy chỉ ra bằng chứng cần kiểm tra trước khi cho phép hệ thống tiếp tục thực thi. Đây là bước bắt buộc để phân biệt một mô hình có thể trình diễn với một mô hình đủ khả năng vận hành trong môi trường BĐS thật.

5.2. Mỗi điều kiện cần một nguồn và một chủ thể chịu trách nhiệm

Tên điều kiện không đủ; phải biết ai cung cấp dữ liệu, quyền của họ và bằng chứng gốc.

Ví dụ BĐS: “Đã nghiệm thu” phải gắn với đơn vị/người có thẩm quyền và mã biên bản cụ thể.

Điểm kiểm soát: Tạo registry nguồn được phép, khóa quyền thay nguồn và lưu dấu phiên bản.

5.3. Thông điệp phải chống gửi trùng và đảo thứ tự

Hệ thống ngoài chuỗi có thể gửi lại dữ liệu do retry hoặc đến không theo thứ tự. Nếu không có idempotency và sequence, một sự kiện cũ có thể kích hoạt lại logic.

Ví dụ BĐS: Oracle gửi lại xác nhận mốc 1 sau khi hệ thống đã chuyển sang mốc 2.

Điểm kiểm soát: Dùng mã sự kiện duy nhất, số thứ tự, dấu thời gian và quy tắc từ chối bản tin cũ/trùng.

5.4. Tranh chấp phải chặn đường tự động

Một cờ tranh chấp hợp lệ phải đưa khoản giải ngân sang trạng thái tạm dừng cho đến khi có quyết định xử lý; không để luồng tự động bỏ qua vì các điều kiện khác đã đủ.

Ví dụ BĐS: Nhà đầu tư/chủ đầu tư có khiếu nại về khối lượng trước giờ giải ngân.

Điểm kiểm soát: Định nghĩa ai được đặt/gỡ cờ, bằng chứng nào cần, và gỡ cờ không tự động đồng nghĩa giải ngân ngay.

5.5. Số tiền và hạn mức phải kiểm tra độc lập

Đủ điều kiện nghiệp vụ không có nghĩa số tiền đề nghị luôn đúng. Hợp đồng cần so với hạn mức, giá trị còn lại và tổng đã giải ngân.

Ví dụ BĐS: Yêu cầu thanh toán nhập thừa một chữ số nhưng các cờ nghiệm thu đều hợp lệ.

Điểm kiểm soát: Đặt trần theo đợt, trần tích lũy, kiểm tra tổng và bước phê duyệt tăng cường khi vượt ngưỡng.

5.6. Khóa và quyền ký phải khớp ma trận trách nhiệm

Nếu một người có thể vừa cập nhật oracle vừa phê duyệt giải ngân thì tách nhiệm vụ chỉ tồn tại trên giấy.

Ví dụ BĐS: Tài khoản quản trị kỹ thuật đồng thời có quyền gỡ tranh chấp và phát lệnh.

Điểm kiểm soát: Tách khóa, vai trò, đơn vị và nhật ký; thử thực tế các hành vi vượt quyền.

5.7. Đối soát sau giải ngân là bắt buộc

Giao dịch thành công trên chuỗi chưa chứng minh sổ sách, ngân hàng và hợp đồng đều ghi nhận đúng.

Ví dụ BĐS: Hợp đồng phát lệnh đúng nhưng hệ thống kế toán ghi sai mã đợt thanh toán.

Điểm kiểm soát: Đối chiếu giao dịch, số tiền, người nhận, chứng từ và trạng thái nghiệp vụ sau mỗi đợt.

5.8. Thiết kế phải có chế độ suy giảm an toàn

Khi oracle hoặc hệ thống ngoài chuỗi không khả dụng, lựa chọn an toàn thường là chờ hoặc chuyển sang xử lý thủ công có kiểm soát, không tự suy đoán.

Ví dụ BĐS: API nghiệm thu ngừng 6 giờ đúng ngày thanh toán.

Điểm kiểm soát: Đặt timeout, cảnh báo, tuyến thủ công có phê duyệt và cấm mặc định “coi như đạt”.

6. Bảng so sánh để ra quyết định

Phương án/tình huống	Lợi ích có thể đạt	Rủi ro hoặc giới hạn	Câu hỏi trước khi chọn
Một cờ đủ/không đủ	Dễ hiểu	Che mất tiến trình và nguyên nhân	Có cần biết điều kiện nào chưa đạt?
Máy nhiều trạng thái	Truy vết tốt, chặn sai bước	Thiết kế phức tạp hơn	Mọi chuyển trạng thái đã được kiểm thử chưa?
Oracle đơn	Nhanh	Phụ thuộc một nguồn	Nguồn có thể bị lỗi/thiên lệch không?
Đa xác nhận	Giảm rủi ro nguồn đơn	Chậm và tốn phối hợp	Điều kiện nào đáng dùng ngưỡng cao?
Fallback thủ công	Giữ vận hành khi hệ thống lỗi	Có thể thành cửa hậu	Ai phê duyệt và bằng chứng nào bắt buộc?

Bảng này là công cụ học tập và thiết kế, không phải kết luận pháp lý hay khuyến nghị đầu tư. Với dự án thật, phải cập nhật theo cấu trúc pháp nhân, hợp đồng, loại tài sản cơ sở, quy định chuyên ngành, đối tượng nhà đầu tư, nhà cung cấp công nghệ và thời điểm triển khai.

7. Quy trình thực hành đề xuất

Bước 1. Vẽ quy trình giải ngân hiện tại và các bên tham gia. Đầu ra của bước này phải là tài liệu, cấu hình, phép thử, biên bản hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng. Nếu có giả định, phải ghi rõ giả định và điều kiện làm giả định đó mất hiệu lực.
Bước 2. Thiết kế máy trạng thái và danh sách chuyển trạng thái hợp lệ. Đầu ra của bước này phải là tài liệu, cấu hình, phép thử, biên bản hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng. Nếu có giả định, phải ghi rõ giả định và điều kiện làm giả định đó mất hiệu lực.
Bước 3. Ánh xạ từng điều kiện sang nguồn dữ liệu, người chịu trách nhiệm và thời hạn hiệu lực. Đầu ra của bước này phải là tài liệu, cấu hình, phép thử, biên bản hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng. Nếu có giả định, phải ghi rõ giả định và điều kiện làm giả định đó mất hiệu lực.
Bước 4. Thiết kế vai trò, khóa, ngưỡng phê duyệt và hạn mức tiền. Đầu ra của bước này phải là tài liệu, cấu hình, phép thử, biên bản hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng. Nếu có giả định, phải ghi rõ giả định và điều kiện làm giả định đó mất hiệu lực.
Bước 5. Xây ca kiểm thử cho gửi trùng, đảo thứ tự, dữ liệu cũ, tranh chấp và vượt hạn mức. Đầu ra của bước này phải là tài liệu, cấu hình, phép thử, biên bản hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng. Nếu có giả định, phải ghi rõ giả định và điều kiện làm giả định đó mất hiệu lực.
Bước 6. Mô phỏng mất oracle và kích hoạt tuyến phương án dự phòng có kiểm soát. Đầu ra của bước này phải là tài liệu, cấu hình, phép thử, biên bản hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng. Nếu có giả định, phải ghi rõ giả định và điều kiện làm giả định đó mất hiệu lực.
Bước 7. Đối soát toàn bộ một chu kỳ từ yêu cầu thanh toán đến sổ sách sau giải ngân. Đầu ra của bước này phải là tài liệu, cấu hình, phép thử, biên bản hoặc quyết định có thể kiểm tra lại; không dừng ở trao đổi miệng. Nếu có giả định, phải ghi rõ giả định và điều kiện làm giả định đó mất hiệu lực.

Sau khi hoàn tất quy trình, nhóm phải thực hiện một vòng “đảo chiều”: giả sử kết quả cuối cùng sai hoặc có tranh chấp, lần ngược lại từng bước để xác định nơi có thể phát sinh lỗi, ai có quyền can thiệp và bằng chứng nào còn đủ để tái dựng sự kiện.

8. Ma trận kiểm soát tối thiểu

Nhóm kiểm soát	Câu hỏi	Bằng chứng tối thiểu	Người nên độc lập kiểm tra
Quyền và thẩm quyền	Ai được khởi tạo, phê duyệt, ký, thay đổi hoặc dừng?	Ma trận quyền; quyết định ủy quyền; nhật ký phê duyệt.	Kiểm soát nội bộ/pháp chế
Dữ liệu	Dữ liệu nào quyết định kết quả và nguồn nào được chấp nhận?	Danh mục nguồn; quy tắc kiểm tra; thời điểm cập nhật.	Bộ phận nghiệp vụ/dữ liệu
Mã và cấu hình	Phiên bản nào đang chạy và ai được thay đổi?	Mã đã kiểm thử; băm phiên bản; nhật ký triển khai.	Nhóm kỹ thuật độc lập
Tài sản/dòng tiền	Trạng thái trên chuỗi có khớp tài sản, hợp đồng và sổ sách?	Đối soát; hồ sơ tài sản; chứng từ thanh toán.	Kế toán/kiểm toán
Ngoại lệ	Khi dữ liệu hoặc hệ thống sai thì ai có quyền tạm dừng?	Kịch bản sự cố; ngưỡng kích hoạt; nhật ký xử lý.	Quản trị rủi ro
Pháp lý	Token/giao dịch đang đại diện quyền gì?	Căn cứ pháp luật; hợp đồng; hồ sơ đăng ký nếu có.	Pháp chế/chuyên gia phù hợp

Trong case study giải ngân, điểm phải kiểm chứng không chỉ là “mã có chạy đúng”. Cần chứng minh mỗi trạng thái trên chuỗi có thể nối tới hồ sơ, nguồn dữ liệu và chủ thể chịu trách nhiệm ngoài đời.

9. Bối cảnh pháp lý và quản trị cần lưu ý

Case study không giả định rằng hợp đồng thông minh tự tạo hiệu lực cho việc giải ngân hoặc thay các điều kiện theo hợp đồng, pháp luật xây dựng, tín dụng, BĐS hay quy định nội bộ. Hệ thống kỹ thuật chỉ nên phản ánh những điều kiện đã được xác định bởi cấu trúc pháp lý/nghiệp vụ phù hợp.

Nếu dòng tiền sử dụng tài sản mã hóa hoặc liên quan dịch vụ tài sản mã hóa, phải tiếp tục đối chiếu phạm vi thí điểm theo Nghị quyết 05/2025/NQ-CP. Không được lấy một mô hình giả lập trong giáo trình làm kết luận rằng cấu trúc phát hành/thanh toán cụ thể được phép triển khai thương mại tại Việt Nam.

Tại Việt Nam, Luật Công nghiệp công nghệ số số 71/2025/QH15 có hiệu lực từ ngày 01/01/2026 tạo khung khái niệm và quản lý đối với tài sản số, trong đó có tài sản mã hóa. Nghị quyết 05/2025/NQ-CP đang triển khai thí điểm thị trường tài sản mã hóa với phạm vi, đối tượng và điều kiện riêng. Vì vậy, không được suy diễn rằng mọi mô hình token hóa BĐS, phát hành token, giao dịch thứ cấp hoặc cơ chế thanh toán đều đương nhiên được phép chỉ vì kỹ thuật có thể triển khai.

Trong BĐS, quyền sử dụng đất, quyền sở hữu tài sản gắn liền với đất, phần vốn trong pháp nhân, quyền theo hợp đồng và quyền nhận dòng tiền là các lớp khác nhau. Một token có thể được thiết kế để ghi nhận hoặc đại diện một lợi ích nhất định, nhưng bản thân token không tự thay thế thủ tục đăng ký, điều kiện giao dịch, hồ sơ pháp lý hoặc cơ chế xác lập quyền theo pháp luật chuyên ngành. Khi mô hình còn đang thí điểm hoặc chưa có hướng dẫn đủ chi tiết, bài học đúng là nhận diện giới hạn và câu hỏi cần xác minh, không phải tự điền phần còn thiếu bằng suy đoán.

10. Những cách hiểu sai thường gặp

Hiểu sai: “Đủ 3 cờ true là đủ để giải ngân.”

Cần hiểu đúng: Phải biết nguồn, độ mới, thứ tự, quyền và trạng thái tranh chấp của từng cờ.

Hiểu sai: “Oracle gửi lại dữ liệu thì hệ thống tự hiểu là trùng.”

Cần hiểu đúng: Chỉ đúng nếu đã thiết kế mã sự kiện/idempotency.

Hiểu sai: “Có blockchain thì không cần đối soát.”

Cần hiểu đúng: Đối soát ngoài chuỗi vẫn cần để khớp sổ sách, chứng từ và tài sản thực.

Hiểu sai: “Fallback thủ công luôn an toàn.”

Cần hiểu đúng: Fallback không kiểm soát có thể trở thành cửa hậu vượt mọi quy tắc.

Hiểu sai: “Giải ngân đúng mã là giải ngân đúng hợp đồng.”

Cần hiểu đúng: Mã có thể đang phản ánh đặc tả sai hoặc thiếu.

Hiểu sai: “Tạm dừng là lỗi thiết kế.”

Cần hiểu đúng: Trong nghiệp vụ có tranh chấp, khả năng dừng an toàn thường là một yêu cầu kiểm soát.

11. Case study tổng hợp

Ba đợt giải ngân và một sự kiện gửi trùng

Nhóm học viên nhận bảng sự kiện giả lập trong 15 ngày: hồ sơ, nghiệm thu, tranh chấp, phê duyệt và yêu cầu thanh toán đến không theo thứ tự. Nhiệm vụ là xác định trạng thái hệ thống sau từng sự kiện, chỉ ra sự kiện nào phải bị từ chối và thời điểm nào hệ thống được phép phát lệnh giải ngân.

11.1. Việc đầu tiên: xác định thứ đang được tự động hóa

Nhóm không được bắt đầu bằng việc chọn blockchain hay chọn nền tảng. Trước hết phải vẽ quy trình nghiệp vụ hiện tại, xác định tài sản hoặc dòng tiền đi qua từng bước, hồ sơ nào tạo quyền, dữ liệu nào chỉ để tham khảo và dữ liệu nào có thể làm thay đổi kết quả. Nếu không làm rõ bước này, hợp đồng thông minh rất dễ mã hóa một quy trình vốn đã sai hoặc quá mơ hồ.

11.2. Việc thứ hai: tách điều kiện kỹ thuật khỏi điều kiện pháp lý

Một điều kiện có thể kiểm tra bằng máy không có nghĩa nó đủ để tạo hiệu lực pháp lý. Ví dụ “đã nhận tín hiệu thanh toán” có thể là điều kiện kỹ thuật; còn việc quyền đối với BĐS đã chuyển hay chưa còn phụ thuộc hồ sơ, điều kiện giao dịch và thủ tục theo pháp luật áp dụng. Thiết kế phải ghi rõ cái gì được tự động, cái gì cần quyết định của con người và cái gì phải dựa trên hệ thống đăng ký hoặc chứng từ bên ngoài.

11.3. Việc thứ ba: kiểm thử đường lỗi, không chỉ đường đúng

Nhóm phải tạo dữ liệu sai, dữ liệu quá cũ, dữ liệu đến trễ, xung đột giữa hai nguồn, người phê duyệt vắng mặt, khóa bị thu hồi và hệ thống ngoài chuỗi mất kết nối. Với mỗi lỗi, cần xác định hệ thống dừng ở đâu, có hoàn tác được không, ai nhận cảnh báo và hồ sơ nào được lưu để giải quyết tranh chấp.

11.4. Kết luận của tình huống

Một mô hình tốt biến quy trình mơ hồ thành trạng thái, quyền, dữ liệu và bằng chứng có thể kiểm tra; đồng thời không giả vờ rằng mọi quyết định ngoài đời đều có thể giảm xuống một cờ nhị phân. Mục tiêu của tự động hóa là giảm sai sót ở phần có quy tắc rõ, không phải xóa quyền xử lý ngoại lệ có trách nhiệm.

12. Phòng thực hành phân tích sâu

Tình huống 1: Máy trạng thái giúp ngăn bỏ qua bước

Giả sử hệ thống đã vận hành sáu tháng và xuất hiện một tranh chấp liên quan trực tiếp nội dung này. Nhóm học viên phải lập ít nhất 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ỗi khoản giải ngân nên đi qua các trạng thái được định nghĩa, ví dụ khởi tạo, chờ hồ sơ, chờ xác nhận, đủ điều kiện, tạm dừng, đã giải ngân hoặc hủy. Chuyển trạng thái chỉ xảy ra theo quy tắc.

Bối cảnh BĐS để phân tích: Đợt 2 không thể sang “đủ điều kiện” nếu đợt 1 chưa đóng hoặc hồ sơ bắt buộc chưa có.

Yêu cầu kiểm soát: Lập sơ đồ trạng thái và cấm mọi chuyển trạng thái không được định nghĩa. 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 bảo toàn và tiêu chí đóng vụ việc.

Yêu cầu phản biện: Đề xuất một phương án dùng cơ sở dữ liệu tập trung hoặc kiến trúc lai. So sánh với blockchain về tin cậy giữa các bên, quyền sửa dữ liệu, chi phí vận hành, khả năng kiểm toán và trách nhiệm khi có sai sót. Nếu phương án đơn giản hơn đáp ứng tốt, phải nói rõ vì sao không nên dùng blockchain.

Tình huống 2: Mỗi điều kiện cần một nguồn và một chủ thể chịu trách nhiệm

Dữ kiện nền: Tên điều kiện không đủ; phải biết ai cung cấp dữ liệu, quyền của họ và bằng chứng gốc.

Bối cảnh BĐS để phân tích: “Đã nghiệm thu” phải gắn với đơn vị/người có thẩm quyền và mã biên bản cụ thể.

Yêu cầu kiểm soát: Tạo registry nguồn được phép, khóa quyền thay nguồn và lưu dấu phiên bả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 bảo toàn và tiêu chí đóng vụ việc.

Tình huống 3: Thông điệp phải chống gửi trùng và đảo thứ tự

Dữ kiện nền: Hệ thống ngoài chuỗi có thể gửi lại dữ liệu do retry hoặc đến không theo thứ tự. Nếu không có idempotency và sequence, một sự kiện cũ có thể kích hoạt lại logic.

Bối cảnh BĐS để phân tích: Oracle gửi lại xác nhận mốc 1 sau khi hệ thống đã chuyển sang mốc 2.

Yêu cầu kiểm soát: Dùng mã sự kiện duy nhất, số thứ tự, dấu thời gian và quy tắc từ chối bản tin cũ/trùng. 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 bảo toàn và tiêu chí đóng vụ việc.

Tình huống 4: Tranh chấp phải chặn đường tự động

Dữ kiện nền: Một cờ tranh chấp hợp lệ phải đưa khoản giải ngân sang trạng thái tạm dừng cho đến khi có quyết định xử lý; không để luồng tự động bỏ qua vì các điều kiện khác đã đủ.

Bối cảnh BĐS để phân tích: Nhà đầu tư/chủ đầu tư có khiếu nại về khối lượng trước giờ giải ngân.

Yêu cầu kiểm soát: Định nghĩa ai được đặt/gỡ cờ, bằng chứng nào cần, và gỡ cờ không tự động đồng nghĩa giải ngân ngay. 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 bảo toàn và tiêu chí đóng vụ việc.

Tình huống 5: Số tiền và hạn mức phải kiểm tra độc lập

Dữ kiện nền: Đủ điều kiện nghiệp vụ không có nghĩa số tiền đề nghị luôn đúng. Hợp đồng cần so với hạn mức, giá trị còn lại và tổng đã giải ngân.

Bối cảnh BĐS để phân tích: Yêu cầu thanh toán nhập thừa một chữ số nhưng các cờ nghiệm thu đều hợp lệ.

Yêu cầu kiểm soát: Đặt trần theo đợt, trần tích lũy, kiểm tra tổng và bước phê duyệt tăng cường khi vượt ngưỡng. 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 bảo toàn và tiêu chí đóng vụ việc.

Tình huống 6: Khóa và quyền ký phải khớp ma trận trách nhiệm

Dữ kiện nền: Nếu một người có thể vừa cập nhật oracle vừa phê duyệt giải ngân thì tách nhiệm vụ chỉ tồn tại trên giấy.

Bối cảnh BĐS để phân tích: Tài khoản quản trị kỹ thuật đồng thời có quyền gỡ tranh chấp và phát lệnh.

Yêu cầu kiểm soát: Tách khóa, vai trò, đơn vị và nhật ký; thử thực tế các hành vi vượt quyề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 bảo toàn và tiêu chí đóng vụ việc.

Tình huống 7: Đối soát sau giải ngân là bắt buộc

Dữ kiện nền: Giao dịch thành công trên chuỗi chưa chứng minh sổ sách, ngân hàng và hợp đồng đều ghi nhận đúng.

Bối cảnh BĐS để phân tích: Hợp đồng phát lệnh đúng nhưng hệ thống kế toán ghi sai mã đợt thanh toán.

Yêu cầu kiểm soát: Đối chiếu giao dịch, số tiền, người nhận, chứng từ và trạng thái nghiệp vụ sau mỗi đợ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 bảo toàn và tiêu chí đóng vụ việc.

Tình huống 8: Thiết kế phải có chế độ suy giảm an toàn

Dữ kiện nền: Khi oracle hoặc hệ thống ngoài chuỗi không khả dụng, lựa chọn an toàn thường là chờ hoặc chuyển sang xử lý thủ công có kiểm soát, không tự suy đoán.

Bối cảnh BĐS để phân tích: API nghiệm thu ngừng 6 giờ đúng ngày thanh toán.

Yêu cầu kiểm soát: Đặt timeout, cảnh báo, tuyến thủ công có phê duyệt và cấm mặc định “coi như đạ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 bảo toàn và tiêu chí đóng vụ việc.

13. Bài tập thực hành

Vẽ máy trạng thái hoàn chỉnh cho case study và liệt kê mọi chuyển trạng thái bị cấm. 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, người chịu trách nhiệm và lý do loại bỏ ít nhất một phương án khác.
Tạo bảng sự kiện 20 dòng có dữ liệu đến muộn, gửi trùng và xung đột, sau đó xác định kết quả mong đợ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, người chịu trách nhiệm và lý do loại bỏ ít nhất một phương án khác.
Thiết kế ma trận vai trò cho chủ đầu tư, tư vấn giám sát, ngân hàng, quản trị hệ thống và kiểm soát nội bộ. 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, người chịu trách nhiệm và lý do loại bỏ ít nhất một phương án khác.
Đề xuất 8 chỉ số giám sát sau triển khai để phát hiện giải ngân bất thường. 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, người chịu trách nhiệm 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ả chính xác chưa?
Quyền pháp lý và quyền kỹ thuật đã được tách riêng chưa?
Dữ liệu đầu vào có nguồn, thời điểm và người chịu trách nhiệm không?
Có điểm nào một cá nhân hoặc một khóa có thể tự hoàn tất giao dịch quan trọng không?
Đã kiểm thử dữ liệu sai, dữ liệu cũ, thiếu dữ liệu và xung đột dữ liệu chưa?
Quy trình thay đổi mã, tham số, vai trò hoặc địa chỉ có phê duyệt và lưu vết không?
Có phương án khi oracle, nhà cung cấp, nút mạng hoặc hệ thống ngoài chuỗi không khả dụng không?
Nhật ký kỹ thuật có nối được với quyết định nghiệp vụ và hồ sơ pháp lý không?
Dữ liệu cá nhân và bí mật kinh doanh đã được tối thiểu hóa trên chuỗi chưa?
Đã mô phỏng tình huống tranh chấp và cách tạm dừng/xử lý ngoại lệ chưa?
Có người độc lập đối soát sau giao dịch hoặc sau thay đổi cấu hình không?
Nếu bỏ blockchain và dùng cơ sở dữ liệu truyền thống, lợi ích nào thực sự mất đi?

Ghi nhớ trong 30 giây

Giải ngân tự động cần máy trạng thái, không chỉ một điều kiện if/else.
Mỗi điều kiện phải có nguồn, độ mới, quyền xác nhận và bằng chứng.
Hệ thống phải chống thông điệp trùng, cũ và đảo thứ tự.
Tranh chấp phải có khả năng chặn luồng tự động.
Số tiền, hạn mức và quyền ký cần được kiểm tra độc lập.
Fallback thủ công phải có kiểm soát; đối soát sau giải ngân vẫn bắt buộc.

Nguồn tham khảo

Nguồn được dùng để kiểm định khái niệm, giới hạn kỹ thuật và bối cảnh pháp lý. 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.

Bài tiếp theo: Token hóa BĐS là gì và token đại diện cho tài sản, quyền hay dòng tiền nào?