Oracle Risk: dữ liệu đầu vào sai có thể làm hợp đồng đúng mã nhưng sai nghiệp vụ thế nào?

Một hợp đồng thông minh có thể hoàn toàn không có lỗi mã nhưng vẫn gây tổn thất nếu dữ liệu đầu vào sai. Đây là điểm đặc biệt nguy hiểm của tự động hóa: hệ thống thực thi nhanh và nhất quán dựa trên một giả định sai. Khi dữ liệu đó quyết định thanh toán, giải ngân hoặc định giá tài sản, sai sót có thể lan trực tiếp sang dòng tiền.

OWASP Smart Contract Top 10 năm 2025 xếp thao túng oracle giá trong nhóm rủi ro trọng yếu. Trong BĐS, rủi ro oracle không chỉ là giá token; nó còn là NAV, trạng thái thanh toán, kết quả kiểm định, tỷ lệ lấp đầy, chỉ số năng lượng hay một xác nhận đã hoàn tất điều kiện giải ngân.

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. “Đúng mã nhưng sai nghiệp vụ” là thất bại của cả chuỗi kiểm soát dữ liệu

Nếu hợp đồng quy định “khi oracle báo TRUE thì giải ngân” và oracle báo TRUE sai, hợp đồng thực hiện hoàn hảo nhưng kết quả nghiệp vụ vẫn sai. Phân tích rủi ro phải đi ngược từ quyết định tài chính đến dữ liệu, nguồn, phương pháp, người có quyền sửa, đường truyền và cơ chế phát hiện bất thường.

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

Phân loại rủi ro oracle theo nguồn, tính toàn vẹn, thời gian, tổng hợp và khả dụng.
Thiết kế ngưỡng, kiểm tra chéo và cơ chế ngắt an toàn cho dữ liệu quan trọng.
Phân biệt lỗi dữ liệu vô ý với thao túng có chủ đích.
Xây quy trình xử lý khi oracle sai sau khi hợp đồng thông minh đã hành động.
Áp dụng khung rủi ro vào NAV, giải ngân và vận hành BĐS.

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

Một hợp đồng thông minh giải ngân 20 tỷ đồng tương đương khi hệ thống quản lý dự án báo “hoàn thành 80%”. Dữ liệu tiến độ do nhà thầu tự cập nhật; API bị cấu hình sai và trả 80 thay vì 0,80, nhưng lớp chuyển đổi coi đây là 80%. Hợp đồng thấy điều kiện đạt và giải ngân. Mã không có lỗi. Vấn đề nằm ở đơn vị, nguồn xác nhận, kiểm tra biên và việc một nguồn duy nhất vừa tạo dữ liệu vừa hưởng lợi từ kết quả.

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. Sai nguồn là rủi ro nền tảng

Nếu chọn nguồn không có thẩm quyền hoặc có xung đột lợi ích, dữ liệu chính xác về mặt kỹ thuật vẫn không phù hợp.

Ví dụ BĐS: nhà thầu tự báo tiến độ để kích hoạt thanh toán.

Điểm kiểm soát: xác định nguồn có thẩm quyền và cơ chế xác nhận độc lập.

5.2. Thao túng dữ liệu có thể xảy ra trước khi dữ liệu vào blockchain

Kẻ tấn công không cần phá blockchain; họ có thể tác động API, tài khoản nguồn, cơ sở dữ liệu hoặc quy trình phê duyệt.

Ví dụ BĐS: chiếm tài khoản người nhập NAV.

Điểm kiểm soát: bảo vệ nguồn, ký dữ liệu và tách quyền.

5.3. Dữ liệu cũ có thể nguy hiểm như dữ liệu sai

Nếu nguồn cấp dừng cập nhật nhưng hợp đồng tiếp tục dùng giá trị cuối, quyết định có thể không phản ánh thực tế.

Ví dụ BĐS: tỷ giá hoặc lãi suất cũ làm sai khoản thanh toán.

Điểm kiểm soát: dấu thời gian, nhịp cập nhật và tuổi dữ liệu tối đa.

5.4. Đơn vị và chuẩn hóa dữ liệu là nguồn lỗi lớn

Phần trăm, tỷ lệ, tiền tệ, số thập phân và múi giờ có thể bị hiểu khác nhau.

Ví dụ BĐS: 7,5% được truyền là 7.5 thay vì 0.075.

Điểm kiểm soát: cấu trúc dữ liệu ghi rõ đơn vị và có kiểm thử biên.

5.5. Tổng hợp nhiều nguồn cũng có thể bị thao túng

Nếu số nguồn ít hoặc trọng số sai, một nguồn có thể kéo kết quả; nếu nhiều nguồn sao chép lẫn nhau, trung vị tạo cảm giác an toàn giả.

Ví dụ BĐS: ba cổng giá thuê dùng cùng dữ liệu môi giới gốc.

Điểm kiểm soát: đánh giá độc lập nguồn và ngoại lệ.

5.6. Cơ chế ngắt an toàn giới hạn tốc độ lan truyền sai

Khi dữ liệu thay đổi vượt ngưỡng, hệ thống có thể tạm dừng và yêu cầu xác nhận thay vì tự động thực thi.

Ví dụ BĐS: NAV thay đổi hơn 15% trong một ngày không tự phân phối.

Điểm kiểm soát: ngưỡng dựa trên nghiệp vụ, không chỉ kỹ thuật.

5.7. Phải có cơ chế sửa sai sau giao dịch

Blockchain khó đảo ngược; thiết kế cần quy trình bù trừ, khiếu nại, bảo hiểm hoặc quỹ dự phòng cho trường hợp dữ liệu sai đã kích hoạt giao dịch.

Ví dụ BĐS: phân phối thừa cần cơ chế thu hồi theo thỏa thuận hoặc bù vào kỳ sau nếu pháp lý cho phép.

Điểm kiểm soát: xác định trước quyền và nghĩa vụ khi oracle sai.

5.8. Giám sát oracle phải độc lập với oracle

Nếu cùng hệ thống tạo và giám sát dữ liệu, lỗi chung có thể không bị phát hiện. Cần nguồn đối chứng hoặc kiểm tra thống kê độc lập.

Ví dụ BĐS: so NAV trên chuỗi với báo cáo kế toán đã ký.

Điểm kiểm soát: cảnh báo chênh lệch và người xử lý độc lập.

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

Rủi ro	Ví dụ BĐS	Phát hiện	Giảm thiểu
Nguồn sai	Nhà thầu tự xác nhận tiến độ	Rà nguồn/quyền	Xác nhận độc lập
Dữ liệu cũ	Lãi suất không cập nhật	Dấu thời gian/nhịp cập nhật	Từ chối dữ liệu quá hạn
Sai đơn vị	80 so với 0,80	Kiểm tra hợp lệ	Cấu trúc dữ liệu + kiểm thử biên
Thao túng	API bị chiếm quyền	Kiểm tra chéo/nhật ký	Chữ ký, đa nguồn, phân quyền
Mất khả dụng	Oracle ngoại tuyến	Kiểm tra tình trạng	Dự phòng/tạm dừng
Ngoại lệ	Giá tăng bất thường	Ngưỡng chênh lệch	Cơ chế ngắt an toàn

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ê mọi dữ liệu ngoài chuỗi có thể kích hoạt dòng tiền hoặc thay 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 2. Xếp hạng tác động nếu từng dữ liệu sai. Đầ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. Xác định nguồn, người quản trị và xung đột lợi ích. Đầ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. Đặt kiểm tra về kiểu, đơn vị, khoảng hợp lý và thời hạ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. Thiết kế đa nguồn hoặc nguồn đối chứng cho dữ liệu trọng yếu. Đầ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. Đặt cơ chế ngắt an toàn và quyền tạm dừng. Đầ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. Giám sát chênh lệch và khả dụng liên tụ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 8. Diễn tập dữ liệu sai, trễ, mất nguồn và thao túng. Đầ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 9. Xây phương án bù trừ sau khi giao dịch đã thực hiệ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.

Đ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 ý

Oracle không chuyển trách nhiệm pháp lý từ tổ chức sang “công nghệ”. Nếu doanh nghiệp sử dụng dữ liệu để tự động giải ngân hoặc thanh toán, trách nhiệm lựa chọn nguồn và kiểm soát vẫn phải được quy định trong hợp đồng và quy trình.

Trong BĐS, một số sự kiện cần xác nhận từ chủ thể có thẩm quyền; việc dùng API từ bên thứ ba không tự thay thẩm quyền đó.

Với dữ liệu cá nhân hoặc dữ liệu giao dịch nhạy cảm, thiết kế oracle cần tuân thủ Luật Bảo vệ dữ liệu cá nhân và nguyên tắc tối thiểu hóa dữ liệu.

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. “Blockchain bất biến nên oracle cũng đáng tin”

Bất biến chỉ bảo vệ dữ liệu sau khi đã ghi.

10.2. “Nhiều oracle thì không thể bị thao túng”

Nếu nguồn phụ thuộc chung hoặc quản trị yếu, vẫn có rủi ro.

10.3. “Sai oracle là lỗi của nhà cung cấp dữ liệu”

Tổ chức tích hợp vẫn phải quản trị lựa chọn, ngưỡng và phương án dự phòng.

10.4. “Cơ chế ngắt an toàn làm mất tính tự động”

Đó là thiết kế an toàn cho tình huống ngoài dự kiến.

11. Case study tổng hợp

Một quỹ tự động tính tỷ lệ phân phối dựa trên NAV và tỷ lệ lấp đầy. NAV cập nhật hàng quý; tỷ lệ lấp đầy cập nhật hằng ngày từ hệ thống quản lý tòa nhà. Hãy thiết kế kiểm tra hợp lệ, tuổi dữ liệu tối đa, nguồn đối chứng, ngưỡng dừng và quy trình nếu dữ liệu sai đã gây phân phối.

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: Sai nguồn là rủi ro nền tảng

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 chọn nguồn không có thẩm quyền hoặc có xung đột lợi ích, dữ liệu chính xác về mặt kỹ thuật vẫn không phù hợp.

Bối cảnh BĐS để phân tích: nhà thầu tự báo tiến độ để kích hoạt thanh toán.

Yêu cầu xử lý: xác định nguồn có thẩm quyền và cơ chế xác nhận độc 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 2: Thao túng dữ liệu có thể xảy ra trước khi dữ liệu vào blockchain

Dữ kiện nền: Kẻ tấn công không cần phá blockchain; họ có thể tác động API, tài khoản nguồn, cơ sở dữ liệu hoặc quy trình phê duyệt.

Bối cảnh BĐS để phân tích: chiếm tài khoản người nhập NAV.

Yêu cầu xử lý: bảo vệ nguồn, ký dữ liệu và tách 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 khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.

Tình huống 3: Dữ liệu cũ có thể nguy hiểm như dữ liệu sai

Dữ kiện nền: Nếu nguồn cấp dừng cập nhật nhưng hợp đồng tiếp tục dùng giá trị cuối, quyết định có thể không phản ánh thực tế.

Bối cảnh BĐS để phân tích: tỷ giá hoặc lãi suất cũ làm sai khoản thanh toán.

Yêu cầu xử lý: dấu thời gian, nhịp cập nhật và tuổi dữ liệu tối đ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 khóa để bảo toàn bằng chứng và tiêu chí đóng vụ việc.

Tình huống 4: Đơn vị và chuẩn hóa dữ liệu là nguồn lỗi lớn

Dữ kiện nền: Phần trăm, tỷ lệ, tiền tệ, số thập phân và múi giờ có thể bị hiểu khác nhau.

Bối cảnh BĐS để phân tích: 7,5% được truyền là 7.5 thay vì 0.075.

Yêu cầu xử lý: cấu trúc dữ liệu ghi rõ đơn vị và có kiểm thử 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.

Tình huống 5: Tổng hợp nhiều nguồn cũng có thể bị thao túng

Dữ kiện nền: Nếu số nguồn ít hoặc trọng số sai, một nguồn có thể kéo kết quả; nếu nhiều nguồn sao chép lẫn nhau, trung vị tạo cảm giác an toàn giả.

Bối cảnh BĐS để phân tích: ba cổng giá thuê dùng cùng dữ liệu môi giới gốc.

Yêu cầu xử lý: đánh giá độc lập nguồn và ngoại lệ. 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.

Tình huống 6: Cơ chế ngắt an toàn giới hạn tốc độ lan truyền sai

Dữ kiện nền: Khi dữ liệu thay đổi vượt ngưỡng, hệ thống có thể tạm dừng và yêu cầu xác nhận thay vì tự động thực thi.

Bối cảnh BĐS để phân tích: NAV thay đổi hơn 15% trong một ngày không tự phân phối.

Yêu cầu xử lý: ngưỡng dựa trên nghiệp vụ, không chỉ kỹ thuậ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.

Tình huống 7: Phải có cơ chế sửa sai sau giao dịch

Dữ kiện nền: Blockchain khó đảo ngược; thiết kế cần quy trình bù trừ, khiếu nại, bảo hiểm hoặc quỹ dự phòng cho trường hợp dữ liệu sai đã kích hoạt giao dịch.

Bối cảnh BĐS để phân tích: phân phối thừa cần cơ chế thu hồi theo thỏa thuận hoặc bù vào kỳ sau nếu pháp lý cho phép.

Yêu cầu xử lý: xác định trước quyền và nghĩa vụ khi oracle sai. 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.

Tình huống 8: Giám sát oracle phải độc lập với oracle

Dữ kiện nền: Nếu cùng hệ thống tạo và giám sát dữ liệu, lỗi chung có thể không bị phát hiện. Cần nguồn đối chứng hoặc kiểm tra thống kê độc lập.

Bối cảnh BĐS để phân tích: so NAV trên chuỗi với báo cáo kế toán đã ký.

Yêu cầu xử lý: cảnh báo chênh lệch và người xử lý độc 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.

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

Lập FMEA hoặc bảng rủi ro cho 10 lỗi oracle có thể xảy ra. 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ế bảng theo dõi độ mới, chênh lệch và tình trạng nguồn. 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.
Đề xuất cơ chế ngắt an toàn cho NAV, giá, lãi suất và trạng thái thanh toán. 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.
Phân tích trách nhiệm giữa nhà cung cấp dữ liệu, nhà phát triển và đơn vị vận hành khi oracle sai. 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

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

Hợp đồng thông minh có thể đúng mã nhưng sai nghiệp vụ nếu oracle sai.
Nguồn, đơn vị, thời gian và xung đột lợi ích đều là rủi ro oracle.
Dữ liệu quá hạn phải được coi là trạng thái cần kiểm soát.
Cơ chế ngắt an toàn giúp giới hạn hậu quả tự động hóa sai.
Thiết kế phải có phương án xử lý sau khi giao dịch sai đã xảy ra.

Bài tiếp theo: Escrow bằng hợp đồng thông minh có thể tự động hóa khâu nào?