Audit mã nguồn và kiểm thử nghiệp vụ cần phối hợp thế nào?

Một hợp đồng thông minh có thể không có lỗ hổng lập trình nghiêm trọng nhưng vẫn thực hiện sai nghiệp vụ. Ngược lại, quy trình nghiệp vụ được mô tả rất đúng nhưng mã triển khai có thể chứa lỗi quyền truy cập, tính toán hoặc xử lý trạng thái.

Vì vậy, “đã audit” không nên được hiểu là một con dấu bảo đảm. Audit (rà soát/kiểm toán) mã nguồn trả lời một nhóm câu hỏi về cách mã được viết và các rủi ro kỹ thuật; kiểm thử nghiệp vụ trả lời nhóm câu hỏi khác về việc hệ thống có thực hiện đúng quy tắc kinh doanh, dữ liệu và ngoại lệ hay không.

Với BĐS, hai nhóm phải nối với nhau vì một lỗi nhỏ ở mã có thể làm sai dòng tiền, còn một giả định nghiệp vụ sai có thể được mã hóa hoàn hảo và tự động nhân rộng.

Chuyên đề: Blockchain và tài sản số trong BĐS · Bài 23 · 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. Audit mã và kiểm thử nghiệp vụ là hai lớp bằng chứng khác nhau

Kiểm toán/rà soát mã nguồn tập trung vào logic, quyền truy cập, lỗ hổng, tương tác và các mẫu lỗi kỹ thuật. Kiểm thử nghiệp vụ phải kiểm tra yêu cầu thực tế: ai được làm gì, dữ liệu nào hợp lệ, điều kiện nào được coi là hoàn tất, số tiền tính ra có đúng và tranh chấp xử lý ra sao. Chỉ khi hai lớp dùng chung một bộ yêu cầu và bất biến thì kết quả mới có ý nghĩa.

Đ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

Phân biệt phạm vi audit mã nguồn, kiểm thử chức năng, kiểm thử tích hợp và nghiệm thu nghiệp vụ.
Chuyển yêu cầu BĐS thành bất biến có thể kiểm tra được.
Thiết kế dữ liệu kiểm thử cho oracle, quyền truy cập, trạng thái và tính toán tiền.
Hiểu giới hạn của audit và trách nhiệm xử lý các phát hiện còn tồn tại.
Xây quy trình bằng chứng từ yêu cầu đến mã, kiểm thử, triển khai và giám sát.

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

Một hợp đồng phân phối dòng tiền vượt qua rà soát kỹ thuật vì không phát hiện lỗ hổng nghiêm trọng. Sau khi chạy thật, hệ thống phân phối tiền cho người đã bán token trước ngày chốt quyền do nhóm nghiệp vụ chưa mô tả rõ “ngày ghi nhận danh sách”. Đây không phải lỗi bảo mật điển hình; mã đã thực hiện đúng một yêu cầu chưa đầ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 23: Làm thế nào biến yêu cầu BĐS thành các bất biến và ca kiểm thử mà cả nhóm nghiệp vụ lẫn nhóm kỹ thuật đều có thể xác nhận? 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. Bắt đầu từ yêu cầu và bất biến, không bắt đầu từ danh sách lỗ hổng

Bất biến là điều phải luôn đúng, ví dụ tổng tiền phân phối không vượt số tiền đã nhận hợp lệ hoặc người không có quyền không thể thay oracle. Nó nối nghiệp vụ với kiểm thử kỹ thuật.

Ví dụ BĐS: Tổng phân phối cho nhà đầu tư phải bằng khoản được phép phân phối sau phí theo quy tắc đã phê duyệt.

Điểm kiểm soát: Lập danh mục bất biến có chủ sở hữu nghiệp vụ và ánh xạ từng bất biến sang ca kiểm thử.

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. Rà soát mã không thay nghiệm thu nghiệp vụ

Chuyên gia rà soát có thể đọc mã rất sâu nhưng không tự biết quy tắc BĐS nội bộ nếu yêu cầu không được cung cấp. Nghiệp vụ phải xác nhận kết quả mong đợi.

Ví dụ BĐS: Mã tính đúng công thức được giao nhưng công thức không tính khoản dự phòng bảo trì đã được phê duyệt.

Điểm kiểm soát: Yêu cầu người nghiệp vụ ký xác nhận đặc tả và tập dữ liệu nghiệm thu.

5.3. Kiểm thử phải bao gồm dữ liệu sai và đường lỗi

Chạy vài ví dụ đúng không đủ. Hợp đồng cần được thử với giá trị biên, dữ liệu cũ, thiếu, trùng, đảo thứ tự và dữ liệu đến từ nguồn không hợp lệ.

Ví dụ BĐS: Oracle gửi cùng một mốc nghiệm thu hai lần hoặc gửi mốc số 3 trước mốc số 2.

Điểm kiểm soát: Xây ma trận dữ liệu hợp lệ/không hợp lệ và kết quả mong đợi cho từng trạng thái.

5.4. Quyền truy cập là một phần của nghiệp vụ

Một hàm kỹ thuật có thể an toàn về mã nhưng vai trò được cấp sai vẫn tạo rủi ro. Ai được pause, đổi oracle, nâng cấp, phát hành hoặc chuyển tiền phải xuất phát từ mô hình trách nhiệm.

Ví dụ BĐS: Tài khoản vận hành được quyền thay địa chỉ nhận phí dù quy định nội bộ chỉ cho phép quản trị quỹ.

Điểm kiểm soát: So khớp vai trò trên hợp đồng với ma trận phân quyền được phê duyệt và thử mọi hành vi vượt quyền.

5.5. Kiểm thử tích hợp mới thấy lỗi giữa chuỗi và hệ thống ngoài chuỗi

Nhiều lỗi nằm ở API, hàng đợi, đơn vị đo, múi giờ hoặc mapping dữ liệu chứ không nằm trong hợp đồng.

Ví dụ BĐS: Hệ thống kế toán gửi đơn vị đồng trong khi hợp đồng hiểu đơn vị nhỏ hơn, làm sai số tiền.

Điểm kiểm soát: Kiểm thử đầu-cuối từ dữ liệu nguồn đến giao dịch, sổ sách và màn hình người dùng.

5.6. Kết quả rà soát phải gắn phiên bản cụ thể

Kết luận rà soát chỉ có nghĩa với mã, cấu hình và phụ thuộc đã được xem. Sau khi đổi mã hoặc tham số trọng yếu, không thể mặc nhiên dùng lại kết luận cũ.

Ví dụ BĐS: Bản đã rà soát dùng oracle A, nhưng trước triển khai đổi sang oracle B mà không rà lại.

Điểm kiểm soát: Gắn mã băm/mã phiên bản, danh mục phụ thuộc, cấu hình và địa chỉ triển khai với báo cáo rà soát.

5.7. Phát hiện phải được quản trị đến khi đóng

Một báo cáo liệt kê lỗi nhưng không có người xử lý, mức ưu tiên, quyết định chấp nhận rủi ro và bằng chứng sửa thì chưa tạo kiểm soát.

Ví dụ BĐS: Lỗi mức trung bình về quyền pause bị hoãn nhiều lần rồi quên trước ngày ra mắt.

Điểm kiểm soát: Theo dõi phát hiện, chủ sở hữu, hạn xử lý, tái kiểm tra và phê duyệt rủi ro còn lại.

5.8. Giám sát sau triển khai là phần tiếp theo của kiểm thử

Không thể mô phỏng mọi điều kiện thực tế. Sau triển khai cần theo dõi sự kiện, sai lệch và hành vi bất thường để phát hiện giả định sai.

Ví dụ BĐS: Tần suất gọi một hàm tăng đột biến hoặc dữ liệu oracle lệch so với nguồn đối chiếu.

Điểm kiểm soát: Thiết lập chỉ báo, ngưỡng cảnh báo và quy trình dừng/điều tra trước khi chạy thậ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
kiểm thử đơn vị	Nhanh, kiểm hàm riêng	Không thấy toàn bộ chuỗi nghiệp vụ	Bất biến nào được bao phủ?
kiểm thử theo thuộc tính/dữ liệu ngẫu nhiên	Tìm trường hợp biên tốt	Cần mô tả thuộc tính đúng	Thuộc tính có phản ánh nghiệp vụ không?
Rà soát mã thủ công	Phát hiện mẫu lỗi và logic phức tạp	Không thể đảm bảo không còn lỗi	Phạm vi/phiên bản nào đã audit?
nghiệm thu người dùng/nghiệp vụ	Xác nhận quy trình thực tế	Có thể bỏ sót lỗi kỹ thuật	Dữ liệu nghiệm thu có đủ tình huống xấu?
Kiểm thử tích hợp	Thấy lỗi giữa nhiều hệ thống	Tốn công dựng môi trường	Có mô phỏng oracle/API/thanh toán thật không?

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. Chốt yêu cầu nghiệp vụ, từ điển dữ liệu và ma trận quyề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 2. Chuyển yêu cầu thành bất biến và tiêu chí chấp nhậ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 3. Xây kiểm thử đơn vị, kiểm thử theo thuộc tính/kiểm thử dữ liệu ngẫu nhiên và tình huống quyền truy cập. Đầ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. Kiểm thử tích hợp với oracle, API, sổ sách và giao diện liên quan. Đầ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. Thực hiện rà soát trên phiên bản mã/cấu hình đã đóng băng. Đầ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. Sửa phát hiện, tái kiểm tra và lập danh sách rủi ro còn lại. Đầ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. Triển khai có kiểm soát và giám sát chỉ báo sau triển khai. Đầ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

Một báo cáo rà soát chỉ là một đầu vào. Bằng chứng mạnh hơn là chuỗi truy vết: yêu cầu → bất biến → mã → ca kiểm thử → phiên bản đã rà soát → bản triển khai → nhật ký giám sát.

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

Nội dung rà soát kỹ thuật không tự xác nhận tính hợp pháp của mô hình kinh doanh hoặc quyền mà token đại diện. Với ứng dụng tài sản số BĐS, pháp chế và nghiệp vụ phải xác định cấu trúc quyền, hợp đồng, đối tượng tham gia và giới hạn pháp luật trước khi xem một kết quả kiểm thử kỹ thuật là đủ để triển khai.

NIST SSDF nhấn mạnh thực hành phát triển phần mềm an toàn xuyên suốt vòng đời; với hợp đồng thông minh, cách tiếp cận này phù hợp hơn việc coi rà soát cuối kỳ là bước bảo mật duy nhất. Các nguồn Ethereum cũng nhấn mạnh cần kết hợp nhiều phương pháp kiểm thử vì một loại test riêng lẻ không bao phủ mọi rủi ro.

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: “Báo cáo rà soát không phát hiện lỗi trọng yếu nghĩa là hợp đồng an toàn.”

Cần hiểu đúng: Rà soát giảm rủi ro trong phạm vi đã xem, không bảo đảm không còn lỗi hay lỗi nghiệp vụ.

Hiểu sai: “Nghiệp vụ chỉ cần test giao diện.”

Cần hiểu đúng: Nghiệp vụ phải xác nhận trạng thái, số tiền, quyền và ngoại lệ từ đầu đến cuối.

Hiểu sai: “Mức bao phủ mã cao là đủ.”

Cần hiểu đúng: Bao phủ dòng mã không chứng minh các giả định và bất biến kinh doanh đã đúng.

Hiểu sai: “Phát hiện thấp có thể bỏ qua.”

Cần hiểu đúng: Mức kỹ thuật phải đặt trong giá trị tài sản, khả năng kết hợp và tác động nghiệp vụ.

Hiểu sai: “Rà soát một lần dùng mãi.”

Cần hiểu đúng: Mọi thay đổi mã, cấu hình, oracle hoặc quyền có thể làm kết luận cũ mất hiệu lực.

Hiểu sai: “Lỗi oracle không thuộc hợp đồng thông minh.”

Cần hiểu đúng: Nếu hợp đồng dựa vào oracle, rủi ro tích hợp là một phần của hệ thống cần kiểm thử.

11. Case study tổng hợp

Mã đúng nhưng ngày chốt quyền sai

Một hợp đồng giả lập phân phối tiền thuê theo số dư token ở “ngày chốt”. Chuyên gia rà soát kiểm mã và không thấy khả năng rút tiền trái phép. Nhưng tài liệu nghiệp vụ dùng ngày địa phương còn mã dùng thời gian UTC; giao dịch gần nửa đêm bị xếp sang ngày khác và một số người nhận sai quyền lợi.

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

Kỹ thuật và nghiệp vụ phải cùng định nghĩa dữ liệu, thời gian, bất biến và kết quả mong đợi. Rà soát tốt không cứu được đặc tả sai; nghiệp vụ đúng cũng không cứu được mã có lỗ hổng. Hai lớp phải gặp nhau ở bằng chứng kiểm thử có thể lặp lại.

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

Tình huống 1: Bắt đầu từ yêu cầu và bất biến, không bắt đầu từ danh sách lỗ hổng

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: Bất biến là điều phải luôn đúng, ví dụ tổng tiền phân phối không vượt số tiền đã nhận hợp lệ hoặc người không có quyền không thể thay oracle. Nó nối nghiệp vụ với kiểm thử kỹ thuật.

Bối cảnh BĐS để phân tích: Tổng phân phối cho nhà đầu tư phải bằng khoản được phép phân phối sau phí theo quy tắc đã phê duyệt.

Yêu cầu kiểm soát: Lập danh mục bất biến có chủ sở hữu nghiệp vụ và ánh xạ từng bất biến sang ca kiểm thử. 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: Rà soát mã không thay nghiệm thu nghiệp vụ

Dữ kiện nền: Chuyên gia rà soát có thể đọc mã rất sâu nhưng không tự biết quy tắc BĐS nội bộ nếu yêu cầu không được cung cấp. Nghiệp vụ phải xác nhận kết quả mong đợi.

Bối cảnh BĐS để phân tích: Mã tính đúng công thức được giao nhưng công thức không tính khoản dự phòng bảo trì đã được phê duyệt.

Yêu cầu kiểm soát: Yêu cầu người nghiệp vụ ký xác nhận đặc tả và tập dữ liệu nghiệm thu. 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: Kiểm thử phải bao gồm dữ liệu sai và đường lỗi

Dữ kiện nền: Chạy vài ví dụ đúng không đủ. Hợp đồng cần được thử với giá trị biên, dữ liệu cũ, thiếu, trùng, đảo thứ tự và dữ liệu đến từ nguồn không hợp lệ.

Bối cảnh BĐS để phân tích: Oracle gửi cùng một mốc nghiệm thu hai lần hoặc gửi mốc số 3 trước mốc số 2.

Yêu cầu kiểm soát: Xây ma trận dữ liệu hợp lệ/không hợp lệ và kết quả mong đợi cho 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 bảo toàn và tiêu chí đóng vụ việc.

Tình huống 4: Quyền truy cập là một phần của nghiệp vụ

Dữ kiện nền: Một hàm kỹ thuật có thể an toàn về mã nhưng vai trò được cấp sai vẫn tạo rủi ro. Ai được pause, đổi oracle, nâng cấp, phát hành hoặc chuyển tiền phải xuất phát từ mô hình trách nhiệm.

Bối cảnh BĐS để phân tích: Tài khoản vận hành được quyền thay địa chỉ nhận phí dù quy định nội bộ chỉ cho phép quản trị quỹ.

Yêu cầu kiểm soát: So khớp vai trò trên hợp đồng với ma trận phân quyền được phê duyệt và thử mọi 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 5: Kiểm thử tích hợp mới thấy lỗi giữa chuỗi và hệ thống ngoài chuỗi

Dữ kiện nền: Nhiều lỗi nằm ở API, hàng đợi, đơn vị đo, múi giờ hoặc mapping dữ liệu chứ không nằm trong hợp đồng.

Bối cảnh BĐS để phân tích: Hệ thống kế toán gửi đơn vị đồng trong khi hợp đồng hiểu đơn vị nhỏ hơn, làm sai số tiền.

Yêu cầu kiểm soát: Kiểm thử đầu-cuối từ dữ liệu nguồn đến giao dịch, sổ sách và màn hình người dù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: Kết quả rà soát phải gắn phiên bản cụ thể

Dữ kiện nền: Kết luận rà soát chỉ có nghĩa với mã, cấu hình và phụ thuộc đã được xem. Sau khi đổi mã hoặc tham số trọng yếu, không thể mặc nhiên dùng lại kết luận cũ.

Bối cảnh BĐS để phân tích: Bản đã rà soát dùng oracle A, nhưng trước triển khai đổi sang oracle B mà không rà lại.

Yêu cầu kiểm soát: Gắn mã băm/mã phiên bản, danh mục phụ thuộc, cấu hình và địa chỉ triển khai với báo cáo rà 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 bảo toàn và tiêu chí đóng vụ việc.

Tình huống 7: Phát hiện phải được quản trị đến khi đóng

Dữ kiện nền: Một báo cáo liệt kê lỗi nhưng không có người xử lý, mức ưu tiên, quyết định chấp nhận rủi ro và bằng chứng sửa thì chưa tạo kiểm soát.

Bối cảnh BĐS để phân tích: Lỗi mức trung bình về quyền pause bị hoãn nhiều lần rồi quên trước ngày ra mắt.

Yêu cầu kiểm soát: Theo dõi phát hiện, chủ sở hữu, hạn xử lý, tái kiểm tra và phê duyệt rủi ro còn lạ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 bảo toàn và tiêu chí đóng vụ việc.

Tình huống 8: Giám sát sau triển khai là phần tiếp theo của kiểm thử

Dữ kiện nền: Không thể mô phỏng mọi điều kiện thực tế. Sau triển khai cần theo dõi sự kiện, sai lệch và hành vi bất thường để phát hiện giả định sai.

Bối cảnh BĐS để phân tích: Tần suất gọi một hàm tăng đột biến hoặc dữ liệu oracle lệch so với nguồn đối chiếu.

Yêu cầu kiểm soát: Thiết lập chỉ báo, ngưỡng cảnh báo và quy trình dừng/điều tra trước khi chạy thậ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

Viết 10 bất biến cho hợp đồng phân phối dòng tiền BĐS và ánh xạ mỗi bất biến sang ít nhất hai ca kiểm thử. 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 ma trận kiểm thử cho oracle gồm: đúng, cũ, thiếu, trùng, sai đơn vị, sai nguồn và đến muộ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, người chịu trách nhiệm và lý do loại bỏ ít nhất một phương án khác.
Đọc một báo cáo rà soát giả lập và thiết kế bảng theo dõi phát hiện đến khi đó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.
Thiết kế quy trình đảm bảo mã đã rà soát chính là mã được triển khai. 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

Audit mã nguồn và kiểm thử nghiệp vụ trả lời hai nhóm câu hỏi khác nhau.
Bất biến là cầu nối quan trọng giữa yêu cầu BĐS và kiểm thử kỹ thuật.
Phải thử đường lỗi, dữ liệu xấu, quyền sai và tích hợp ngoài chuỗi.
Kết luận rà soát chỉ gắn với phiên bản, cấu hình và phạm vi đã được xem.
Mọi phát hiện cần chủ sở hữu, thời hạn, tái kiểm tra và quyết định rủi ro còn lại.
Giám sát sau triển khai nối tiếp kiểm thử vì môi trường thật luôn có tình huống chưa mô phỏng.

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: Case study: mô hình hợp đồng thông minh giải ngân theo điều kiện giả lập