Hợp đồng mã hóa cần quy tắc về chứng cứ và công bố

Bài viết kỹ thuật của Fhenix ngày 20/10/2026 bàn về bảo mật khi hợp đồng tính toán với các giá trị mã hóa. Điểm đáng chú ý là cách bài viết đưa thiết kế ứng dụng trở lại một cuộc thảo luận thường bị chi phối bởi mật mã học. Bài viết kỹ thuật của Fhenix

Với doanh nghiệp đang cân nhắc ứng dụng bảo mật trên chuỗi, quyết định đầu tiên là thông tin nào những người tham gia khác không được biết. Quyết định tiếp theo là điều gì họ vẫn phải kiểm chứng được. Hai yêu cầu này có thể căng kéo nhau. Một quy trình mua sắm cần giấu giá dự thầu nhưng đồng thời chứng minh đã tuân thủ quy tắc lựa chọn công bố trước. Giấu báo giá chưa trả lời được ai viết quy tắc, ai được sửa và ai có thể xem kết quả khi xảy ra tranh chấp.

Bài này đưa ra một khung phân tích, không đánh giá an ninh của một triển khai cụ thể. Tài liệu kiến trúc trình bày một thiết kế, không chứng minh phần triển khai không có lỗi. Nghiên cứu về một nhóm hệ thống cũng không tự động chứng minh một sản phẩm cụ thể có lỗ hổng.

Giá dự thầu kín vẫn cần quy tắc rõ ràng

Hãy xét một tình huống giả định: bên mua tổ chức đấu thầu bằng tính toán mã hóa. Nhà cung cấp gửi mức giá đối thủ không đọc được; bên mua muốn chọn giá thấp nhất đáp ứng yêu cầu giao hàng và chất lượng. Lý do thương mại cho tính bảo mật rất rõ: nhà cung cấp không nên phải tiết lộ toàn bộ chiến lược giá chỉ để cạnh tranh một đơn hàng.

Tuy nhiên, con số thấp nhất chưa chắc là kết quả đúng về nghiệp vụ. Nhà cung cấp có thể dùng sai loại tiền, chưa tính phí vận chuyển hoặc hứa ngày giao hàng không phù hợp. Ngay cả phép toán mã hóa hoàn toàn chính xác cũng có thể so sánh những đầu vào vốn không nên được so sánh với nhau. Ứng dụng vì thế cần xác định báo giá hợp lệ trước khi bắt đầu tính toán. Mã hóa không thể quyết định lời hứa giao hàng có đáng tin hay bản yêu cầu có phản ánh đúng nhu cầu mua sắm hay không.

Đầu ra cũng đòi hỏi lựa chọn. Bên mua có thể chỉ cần tên nhà cung cấp trúng thầu và số tiền phải trả. Công khai toàn bộ thứ hạng cho mọi bên có thể tiết lộ nhiều thông tin thương mại hơn mức cần thiết. Ngược lại, tiết lộ quá ít có thể khiến bên thua không thể phản đối một quyết định thiếu nhất quán. Chính sách công bố thích hợp phải xuất phát từ mục đích giao dịch và cơ chế giải quyết tranh chấp, không phải do một công cụ mật mã tự quyết định.

Tính toán hợp lệ và quyết định hợp lý cần chứng cứ khác nhau

Nghiên cứu Verifiable Fully Homomorphic Encryption, nộp ngày 17/1/2023, xem tính toàn vẹn của tính toán là vấn đề riêng và nghiên cứu biện pháp chống thực thi độc hại. Đây là nghiên cứu kỹ thuật trước đây, không phải kết luận về triển khai CoFHE hiện nay. Bài nghiên cứu

Trong ví dụ đấu thầu giả định, cần phân biệt hai loại bảo đảm. Kiểm chứng kỹ thuật hỏi liệu thao tác được quy định có thực sự chạy trên đúng tập đầu vào hay không. Rà soát nghiệp vụ hỏi liệu các đầu vào và thao tác đó có thể hiện quy tắc mua sắm đã thống nhất hay không. Bằng chứng cho điều thứ nhất không được âm thầm thay thế điều thứ hai. Phép so sánh mã hóa thực hiện chính xác một điều kiện tham gia đã lỗi thời vẫn có thể chọn ra nhà cung cấp không thể chấp nhận về mặt thương mại.

Sự phân biệt này còn thay đổi cách tổ chức chứng cứ. Hồ sơ rà soát hữu ích nên nối phiên bản quy tắc, tập đầu vào được chấp nhận, phép tính được kiểm chứng và kết quả cuối cùng được công bố. Một phép kiểm tra mật mã tách khỏi bối cảnh có thể đúng về toán học nhưng chưa đủ giải thích quyết định mua hàng. Đây là suy luận biên tập về thiết kế chứng cứ, không phải khẳng định một giao thức tự động cung cấp toàn bộ hồ sơ đó.

Nhóm mua sắm cũng cần thống nhất người giải thích hồ sơ trước khi vận hành. Nhân sự kỹ thuật có thể xác định chương trình đã làm gì nhưng không có quyền diễn giải ngoại lệ thương mại. Người quản lý nghiệp vụ có thể giải thích mục tiêu mua hàng nhưng không biết chứng minh bao phủ những điều kiện nào. Gộp hai trách nhiệm vào nhãn chung “hệ thống đã xác minh” sẽ làm tranh chấp sau này khó giải quyết hơn.

Quyền truy cập là một phần của sản phẩm

Tài liệu ACL hiện tại của Zama phân biệt quyền đối với bản mã có hiệu lực lâu dài và quyền chỉ tồn tại trong giao dịch hiện tại. Tài liệu cũng mô tả riêng quyền cho phép giải mã công khai một giá trị. Đây là những lựa chọn ứng dụng khác nhau. Tài liệu ACL của Zama

Nhóm mua sắm có thể dùng sự phân biệt này để diễn đạt yêu cầu mà không giả định mọi nền tảng có cùng cơ chế. Dịch vụ tính toán có thể chỉ cần quyền tạm thời cho một công việc. Kiểm toán viên có thể cần xem thông tin trong phạm vi một hợp đồng cụ thể. Nhân viên hỗ trợ có thể chỉ cần dữ liệu đủ để xử lý một yêu cầu riêng lẻ. Cấp quyền rộng như nhau cho cả ba vai trò có thể đơn giản hóa quản trị nhưng làm suy yếu lý do ban đầu để giữ ứng dụng bí mật.

Phạm vi quyền cũng cần chịu được thay đổi tổ chức thông thường: nhà cung cấp đổi tài khoản, hợp đồng kiểm toán kết thúc hoặc bên mua thay đơn vị vận hành thuê ngoài. Câu hỏi không chỉ là có cấp được quyền hay không. Nhóm vận hành phải xác định dữ liệu bị ảnh hưởng và hiểu thay đổi quyền có tác dụng gì, không có tác dụng gì. Chặn truy cập trong tương lai không làm người nhận quên bản rõ họ đã có. Vì thế, báo cáo xuất ra và ảnh chụp màn hình vẫn thuộc phạm vi quản lý riêng tư, dù tính toán nền tảng tiếp tục được mã hóa.

Rà soát quyền không thể dừng ở lần tích hợp đầu tiên. Một dịch vụ ban đầu chỉ hiển thị kết quả có thể bổ sung phân tích hoặc xuất dữ liệu. Thay đổi đó không nhất thiết là lỗi kỹ thuật, nhưng có thể thay đổi những người và hệ thống tiếp xúc với dữ liệu. Doanh nghiệp cần nhận ra phạm vi nghiệp vụ đã đổi trước khi quyết định điều chỉnh quyền, thay vì dựa mãi vào lần duyệt cũ.

Đánh giá hệ thống đang tồn tại

Tài liệu Teecryptor hiện tại của CoFHE mô tả giải mã trong môi trường thực thi tin cậy có chứng thực. Giải mã ngưỡng đa bên được trình bày là phương án thay thế dự kiến. Không nên nhập nhằng thiết kế hiện tại với lộ trình tương lai. Tài liệu Teecryptor của CoFHE

Điều kiện này không phải lập luận chống triển khai có giả định về phần cứng. Doanh nghiệp thường chấp nhận phụ thuộc kỹ thuật khi lợi ích xứng đáng. Điều cần làm là so sánh các phụ thuộc thực tế thay vì nhãn tiếp thị. Bên mua nên hiểu thành phần nào phải hoạt động, chứng cứ nào hỗ trợ hoạt động đó và điều gì xảy ra khi dịch vụ cần thiết không thể trả kết quả.

Trong đấu thầu, kết quả không sẵn có có thể làm chậm trao hợp đồng ngay cả khi không lộ giá và không sai phép toán. Quy trình hoãn hoặc hủy đã định trước có thể hữu ích hơn việc ứng biến bằng cách công bố thêm dữ liệu. Quy trình đó cũng có chi phí: nhà cung cấp có thể phải giữ năng lực sản xuất lâu hơn. Tính bảo mật, tính sẵn sàng và thời hạn hợp đồng vì vậy phải được cân nhắc cùng nhau, thay vì giao cho các nhóm đánh giá riêng rồi không đối chiếu giả định.

Lập luận thuyết phục nhất cho tính toán mã hóa là giúp các bên hợp tác mà không phải phân phối toàn bộ dữ liệu nền. Đây là lợi ích cụ thể khi việc tiết lộ tự nó gây tổn thất cạnh tranh. Giá trị đó dễ đánh giá hơn nếu ứng dụng nêu rõ sự kiện nào được giấu, kết luận nào được kiểm chứng và ai vẫn có quyền quyết định thay đổi hoặc ngoại lệ.

Do đó, triển khai ban đầu nên được đánh giá bằng một giao dịch hoàn chỉnh và tranh chấp thực tế, không chỉ bằng màn trình diễn tính toán mã hóa. Nếu bên mua giải thích được kết quả bị phản đối mà không lộ các báo giá không liên quan, đồng thời xử lý được quy trình đình trệ mà vẫn giữ giới hạn công bố ban đầu, công nghệ đang đáp ứng nhu cầu nghiệp vụ rõ ràng. Một triển khai cụ thể có đạt được điều đó hay không vẫn cần chứng cứ và thử nghiệm, không thể suy ra từ nhãn FHE.