zkTLS là gì: Giải thích dành cho người mới bắt đầu

zkTLS dành cho những người cần đưa các giá trị từ trang web hoặc API đã xác thực vào hợp đồng hay cho một đối tác, chứ không phải một phương thức truyền tải mới thay thế HTTPS. So với ảnh chụp màn hình hoặc tự khai báo, zkTLS biến việc “phiên đã truy cập trang web mục tiêu” và “trường dữ liệu đáp ứng một điều kiện” thành bằng chứng có thể kiểm tra. Các luồng dữ liệu thị trường công khai liên tục thường dựa vào oracle blockchain; phần so sánh theo mô hình luồng dữ liệu nằm bên dưới.

Các phần bên dưới trình bày về định nghĩa, các bước từ phiên đến bằng chứng, sự khác biệt giữa MPC/Proxy/TEE, các trường hợp sử dụng, đối chiếu với oracle và rủi ro, cùng với các bài viết công khai về cơ chế như bài giải thích zkTLS của Oasis và trang mô hình zk-TLS của EthSystems.

Những điểm chính

• zkTLS biến một phiên HTTPS thành một tuyên bố có thể kiểm tra: liên kết tên miền/chứng chỉ và có thể chỉ công bố kết quả của một điều kiện.
• Tên gọi này thường gây hiểu nhầm: không phải mọi thiết kế đều sử dụng bằng chứng không tiết lộ tại thời điểm bắt tay; MPC, Proxy và TEE là ba hướng phổ biến.
• Vì TLS kết thúc bằng một khóa phiên đối xứng dùng chung, riêng máy khách có thể giả mạo một bản ghi phiên để trình bày, do đó cần có công chứng viên, proxy hoặc TEE.
• Nguồn gốc không đồng nghĩa với tính xác thực: nếu nguồn trả về một trường dữ liệu sai, bằng chứng vẫn có thể hợp lệ về mặt hình thức.
• Bên xác minh cần kiểm tra liên kết tên miền/chứng chỉ, điều kiện, chữ ký chứng thực hoặc gốc tin cậy trên đường dẫn bằng chứng.

zkTLS là gì và giải quyết vấn đề nào?

zkTLS giải quyết một khoảng trống của TLS thông thường: Transport Layer Security là nền tảng cho các kết nối HTTPS của trình duyệt, mã hóa và xác thực kênh giữa máy khách với máy chủ, nhưng sau khi phiên kết thúc, rất khó thuyết phục bên thứ ba rằng máy chủ thực sự đã trả về nội dung đó mà không phải cung cấp tài liệu giải mã có thể bị lạm dụng hoặc dựa vào ảnh chụp màn hình. Vì vậy, các hợp đồng gặp khó khăn khi cần sử dụng những trường dữ liệu sau khi đăng nhập.

Một quá trình bắt tay TLS tiêu chuẩn tạo ra một khóa phiên đối xứng: cả trình duyệt và máy chủ đều có thể mã hóa và giải mã. Nếu người dùng tự mình xuất trình bản mã cùng khóa đó, các bên khác không thể loại trừ khả năng người dùng đã mã hóa văn bản gốc giả rồi giải mã theo yêu cầu, do đó một máy khách đơn lẻ không thể là nhân chứng đáng tin cậy. Giới hạn này tạo ra nhu cầu về công chứng viên, proxy hoặc TEE.

zkTLS cung cấp bằng chứng về nguồn gốc và tính toàn vẹn, chứ không đưa ra phán quyết cuối cùng về tính đúng đắn trong nghiệp vụ. Việc chứng minh một trường số dư đến từ phiên TLS của một trang web không bác bỏ khả năng nhập dữ liệu sai hoặc trang bị can thiệp, điều này gần với các mô hình luồng dữ liệu không tiết lộ trong zkOracle và zkCoprocessor, nhưng thuộc một miền vấn đề khác.

zkTLS hoạt động như thế nào? Từ phiên HTTPS đến tuyên bố có thể xác minh

Ở cấp độ khái quát, zkTLS chuyển từ một phiên HTTPS thông thường sang bằng chứng có thể kiểm tra: người dùng mở một phiên với nguồn; đường dẫn MPC công chứng viên, Proxy hoặc TEE để lại bằng chứng có thể kiểm tra; sau đó một bằng chứng tiết lộ có chọn lọc được tạo ra và xác minh.

1. Mở phiên — Bắt đầu TLS với tên miền mục tiêu; liên kết chứng chỉ và tên miền trở thành một phần của tuyên bố sau đó.
2. Cùng làm chứng hoặc ủy quyền — Một công chứng viên tham gia vào quá trình bắt tay/giải mã hóa (MPC), một proxy chứng thực hướng của bản mã (Proxy), hoặc TEE thực hiện yêu cầu, nhờ đó một máy khách đơn lẻ không thể dễ dàng giả mạo bản mã do máy chủ gửi; một số thiết kế coi đây là giao thức đa bên thay vì quy trình chỉ có một máy khách.
3. Truy xuất trường dữ liệu mục tiêu — Trong phiên, yêu cầu trang tài khoản hoặc API và nhận phản hồi được mã hóa.
4. Tạo tuyên bố — Tạo một bằng chứng, hoặc chữ ký đường dẫn, dựa trên các cam kết bản ghi phiên, danh tính máy chủ và một điều kiện như số dư > ngưỡng; các đường dẫn dựa trên mạch biến các ràng buộc của bản ghi phiên thành đầu ra bằng chứng.
5. Gửi để xác minh — Một hợp đồng hoặc đối tác kiểm tra bằng chứng và các gốc tin cậy, sau đó chấp nhận hoặc từ chối.

Tiết lộ có chọn lọc là một lớp thứ hai phổ biến: chứng minh số dư vượt ngưỡng mà không tiết lộ số tiền chính xác, hoặc trích xuất một trường trong khi ẩn phần còn lại. Theo ghi chú của Reclaim về “zk” trong zkTLS, ZK để bảo vệ quyền riêng tư thường là một cải tiến; yêu cầu cơ bản hơn là thuyết phục bên thứ ba rằng phản hồi thực sự đến từ nguồn.

Hình 1. zkTLS chuyển từ một phiên HTTPS của máy khách, qua đường dẫn chứng thực MPC/Proxy/TEE, đến bằng chứng tiết lộ có chọn lọc do bên xác minh hoặc hợp đồng thông minh kiểm tra.

Danh sách kiểm tra của bên xác minh cần bao gồm ít nhất bốn mục: liên kết tên miền và chứng chỉ với nguồn được tuyên bố; một điều kiện phù hợp với quy tắc nghiệp vụ; chữ ký đường dẫn bằng chứng hoặc gốc tin cậy trong danh sách cho phép; và việc thay đổi cấu trúc của nguồn có làm hỏng bộ phân tích hay không. Bỏ qua bất kỳ mục nào sẽ biến “có thể xác minh” thành “trông giống bằng chứng”, trong khi mục tiêu là tạo dữ liệu có thể xác minh cho hợp đồng thông minh hoặc đối tác.

Vì sao được gọi là zkTLS? MPC, Proxy và TEE khác nhau như thế nào?

“zkTLS” là một thuật ngữ bao quát phổ biến, gợi ý rằng bằng chứng không tiết lộ phải được chạy vào thời điểm bắt tay, nhưng điều đó không phải lúc nào cũng đúng. Nhãn này thường được dùng rộng rãi cho một giao thức lai, dù không phải mọi cách triển khai thực sự phù hợp với mô tả đó. Nhiều thiết kế gần với Web Proofs hoặc chứng thực TLS hơn: trọng tâm là khả năng xác minh, không phải bắt buộc có ZK trong quá trình bắt tay.

Cả ba phương thức đều trả lời cùng một câu hỏi: làm thế nào để thuyết phục bên thứ ba rằng bản mã đến từ máy chủ mà không giao khóa đối xứng để bị lạm dụng. Proxy có thể quan sát hướng truyền dữ liệu mà không thấy văn bản gốc. Các thiết kế MPC/2PC theo kiểu TLSNotary sử dụng khóa chung để ngăn chặn việc giả mạo đơn phương; các thiết kế Proxy kết hợp chứng thực hướng với bằng chứng giải mã phía người dùng; các thiết kế TEE lưu trữ phiên trong vùng cách ly phần cứng. ZK để bảo vệ quyền riêng tư có thể được bổ sung ở lớp trên nhằm che giấu trường dữ liệu, nhưng TEE và phần lớn quá trình bắt tay MPC không phải là ZK ở lớp bắt tay.

Việc chọn phương thức là quyết định dựa trên mô hình rủi ro và chi phí: liệu một công chứng viên, proxy hoặc TEE duy nhất có thể chấp nhận được hay không; liệu các phiên có phải duy trì độ trễ thấp hay không; liệu nguồn chỉ hỗ trợ một số phiên bản TLS nhất định hay không. Các đường dẫn MPC cũng bảo đảm rằng không một nút đơn lẻ nào từng nắm toàn bộ khóa. Hãy hiểu “zk” là nhãn dành cho dữ liệu web có thể xác minh, không phải một phân loại mật mã nghiêm ngặt.

zkTLS có thể được sử dụng cho những việc gì?

Một trường hợp sử dụng điển hình là chứng minh một tài khoản ngoài chuỗi đáp ứng một ngưỡng mà không công bố toàn bộ sao kê: ngưỡng số dư để đủ điều kiện tín dụng, kiểm tra số dư ngân hàng trong quy trình tài chính mà không tiết lộ số tiền chính xác, các trường về việc làm hoặc uy tín từ cổng thông tin đã đăng nhập, và xác nhận hoạt động ngoài chuỗi phục vụ quy tắc nhiệm vụ. Mô hình chung là dữ liệu nằm sau HTTPS nhưng không có API công khai đã được ký sẵn.

Các trường hợp sử dụng về danh tính và thuộc tính gồm xác minh danh tính và thông tin xác thực đã được xác minh, cùng với nhóm tuổi, cấp độ thành viên hoặc điểm đánh giá tổng hợp: bên xác minh chỉ thấy kết quả điều kiện, thay vì toàn bộ trang dữ liệu riêng tư. Các sản phẩm theo mô hình giao thức như oracle zkTLS của zkPass định vị dữ liệu riêng tư có thể xác minh trên chuỗi; cần phân biệt cách một giao thức đóng gói bằng chứng với điều mà mô hình zkTLS thực sự bảo đảm.

Một nhóm khác là các luồng dữ liệu bảo vệ quyền riêng tư: ứng dụng cần sử dụng các trường dữ liệu từ trang web trong ứng dụng trên chuỗi mà không để lộ toàn bộ văn bản gốc đã thu thập cho mọi người quan sát. Trong trường hợp này, zkTLS cung cấp bằng chứng về một trường dữ liệu có nguồn gốc; vẫn cần phân biệt với các luồng giá liên tục và tổng hợp từ nhiều nguồn được sử dụng trong tài chính phi tập trung cũng như các quy trình web-to-chain rộng hơn.

zkTLS khác với oracle truyền thống như thế nào?

Oracle truyền thống tập trung vào việc ghi các dữ kiện ngoài chuỗi, chẳng hạn giá và kết quả sự kiện, lên blockchain, thường thông qua tập hợp nút hoặc luồng dữ liệu từ nhiều nguồn. Sự khác biệt này là một phần của vấn đề oracle: đưa dữ liệu ngoài chuỗi hoặc dữ liệu web đáng tin cậy vào hợp đồng. zkTLS tập trung vào việc chứng minh các trường dữ liệu của phiên HTTPS đến từ một nguồn cụ thể, có thể kèm tiết lộ có chọn lọc. Luồng dữ liệu tối ưu hóa khả năng sẵn sàng và khả năng chống thao túng; zkTLS tối ưu hóa việc chuyển một phiên web thành tuyên bố có thể kiểm tra.

Khi so sánh kiến trúc luồng dữ liệu, giả định về độ tin cậy và các chế độ lỗi, hãy sử dụng zkTLS so với oracle truyền thống. Quy tắc ngắn gọn: các luồng dữ liệu thị trường công khai liên tục vẫn phù hợp với các mạng oracle đã hoàn thiện; các trường dữ liệu riêng tư sau khi đăng nhập cần công bố tối thiểu phù hợp với zkTLS hơn, trong khi một số hệ thống cũng coi khả năng chuyển dữ liệu là một mục tiêu thiết kế riêng, hai phương thức có thể kết hợp nhưng không phương thức nào thay thế phương thức kia.

Ưu điểm và rủi ro khi sử dụng hoặc phụ thuộc vào zkTLS cho dữ liệu nhạy cảm là gì?

Các ưu điểm gồm xuất các trường có thể kiểm tra bất cứ khi nào người dùng vẫn có thể hoàn tất HTTPS với nguồn mà không cần chờ API luồng dữ liệu chuyên dụng; tiết lộ có chọn lọc cho phép hợp đồng xác minh một dữ kiện mà không để lộ toàn bộ hồ sơ riêng tư; và các tuyên bố có thể được hợp đồng kiểm tra theo chương trình.

Các rủi ro cũng rất cụ thể. Tính trung thực và khả năng hoạt động của công chứng viên, proxy hoặc TEE tạo thành các gốc tin cậy: thông đồng, từ chối hoặc ngừng hoạt động có thể dẫn đến chấp nhận sai hoặc lỗi. Các thiết kế dựa trên TEE cũng mang rủi ro bảo mật liên quan đến nhà sản xuất phần cứng hoặc gốc chứng thực. Tính trung thực của nguồn nằm ngoài phạm vi giao thức: các trang sai vẫn có thể tạo ra bằng chứng hợp lệ về mặt hình thức. Thay đổi đường dẫn trường dữ liệu có thể làm hỏng điều kiện; một số hệ thống công chứng chỉ hỗ trợ một số phiên bản TLS nhất định.

Các bên phụ thuộc vào hệ thống cũng cần cân nhắc chi phí tạo bằng chứng, độ trễ phiên và rủi ro lưu giữ bản ghi phiên. zkTLS cải thiện khả năng kiểm tra nguồn gốc; nó không biến các trang web tùy ý thành nguồn sự thật chưa được kiểm toán.

Tóm tắt

zkTLS nâng cấp các phiên HTTPS thông thường thành các tuyên bố có thể kiểm tra và tiết lộ ở mức tối thiểu, để hợp đồng có thể xác minh trường dữ liệu đến từ máy chủ nào được liên kết với tên miền, thay vì tin vào ảnh chụp màn hình. “zk” không bảo đảm có bằng chứng không tiết lộ tại thời điểm bắt tay; MPC, Proxy và TEE đạt được tính toàn vẹn theo các giả định tin cậy khác nhau.

Trước khi triển khai, cần chấp nhận rằng một máy khách đơn lẻ nắm khóa đối xứng có thể dựng một phiên giả để trình bày; danh sách kiểm tra của bên xác minh phải bao gồm tên miền/chứng chỉ, điều kiện và các gốc tin cậy; nguồn gốc không phải là tính xác thực của nội dung; và oracle truyền thống so với zkTLS phân tách các luồng liên tục với bằng chứng trường dữ liệu từ trang riêng tư. Hãy chọn phương thức phù hợp với mô hình rủi ro, đồng thời đưa rủi ro từ nguồn và chứng thực vào mô hình đó.

Câu hỏi thường gặp

zkTLS là gì?

zkTLS là một nhóm thiết kế được xây dựng trên TLS/HTTPS tiêu chuẩn, tạo ra các tuyên bố mà bên thứ ba có thể kiểm tra: dữ liệu cụ thể đến từ một máy chủ được liên kết với tên miền và chứng chỉ, đồng thời có thể chỉ tiết lộ kết quả của một điều kiện. zkTLS kết nối các trường dữ liệu Web2 riêng tư với việc xác minh của hợp đồng mà không thay thế HTTPS.

zkTLS biến một phiên HTTPS thành tuyên bố có thể xác minh như thế nào?

Máy khách và nguồn mở một phiên; một công chứng viên MPC, Proxy hoặc TEE cùng làm chứng hoặc được ủy quyền để máy khách đơn lẻ không thể giả mạo bản mã của máy chủ; một bằng chứng tiết lộ có chọn lọc được tạo ra; bên xác minh kiểm tra liên kết tên miền, điều kiện và các gốc tin cậy trước khi chấp nhận hoặc từ chối.

zkTLS có bắt buộc sử dụng bằng chứng không tiết lộ trong quá trình bắt tay TLS không?

Không. Nhiều hệ thống được gắn nhãn zkTLS sử dụng MPC, Proxy hoặc TEE để bảo đảm tính toàn vẹn; bằng chứng không tiết lộ thường xuất hiện sau đó để phục vụ tiết lộ có chọn lọc hoặc chứng minh giải mã theo kiểu Proxy. Quá trình bắt tay có thể không bao giờ chạy mạch ZK, “zk” chỉ là một nhãn phổ biến.

zkTLS khác với oracle truyền thống như thế nào?

Oracle truyền thống liên tục đưa các dữ kiện ngoài chuỗi vào hợp đồng với mục tiêu đa nguồn và khả năng sẵn sàng; zkTLS chứng minh nguồn gốc, cùng các điều kiện tùy chọn, cho các trường HTTPS ở cấp phiên. Luồng dữ liệu công khai và trường dữ liệu từ trang đăng nhập riêng tư là các vấn đề khác nhau; xem chủ đề so sánh, hai phương thức có thể kết hợp.

Những rủi ro chính khi phụ thuộc vào zkTLS là gì?

Các rủi ro chính gồm công chứng viên, proxy hoặc TEE bị xâm phạm hoặc không khả dụng; nguồn phục vụ dữ liệu sai trong khi bằng chứng vẫn hợp lệ về mặt hình thức; thay đổi cấu trúc trang làm hỏng bộ phân tích; và giới hạn về phiên bản TLS. Bỏ qua việc kiểm tra liên kết tên miền và gốc tin cậy làm tăng rủi ro chấp nhận sai.