zkTLS so với oracle truyền thống: Dữ liệu web nào phù hợp hơn để đưa lên chuỗi?

So sánh này dành cho độc giả quan tâm đến sản phẩm và rủi ro, đang lựa chọn giữa các trường dữ liệu trên trang riêng tư và các nguồn cấp dữ liệu công khai. Cơ chế này được giải thích trong zkTLS; thuật ngữ bao quát cho các cầu nối dữ liệu ngoài chuỗi là oracle blockchain. Các phần dưới đây đối chiếu nguồn dữ liệu, quyền riêng tư, độ tin cậy và độ trễ, đồng thời làm rõ ranh giới giữa ảnh chụp màn hình/PDF và nguồn gốc mật mã.

Tiếp theo là các khía cạnh so sánh và danh sách "Chọn nếu", bao gồm điểm mà ảnh chụp màn hình hoặc PDF không còn đủ và nguồn gốc mật mã bắt đầu cần thiết. Các lớp đóng gói theo giao thức gồm oracle zkTLS zkPass; các mô hình nguồn cấp dữ liệu zero-knowledge được trình bày cùng zkOracle và zkCoprocessor.

Những điểm chính

• zkTLS tối ưu hóa việc chứng minh một trường trong phiên HTTPS đến từ máy chủ nào được liên kết với miền; các oracle truyền thống tối ưu hóa việc liên tục ghi các thông tin công khai lên chuỗi với khả năng chống thao túng.
• Các trang riêng tư sau khi đăng nhập không có API công khai được ký phù hợp với zkTLS; giá thị trường liên tục và việc tổng hợp từ nhiều nguồn phù hợp với các mạng oracle trưởng thành.
• Công bố có chọn lọc là một ưu điểm phổ biến của zkTLS; các nguồn cấp dữ liệu truyền thống thường công bố các giá trị đã tổng hợp cho mọi người quan sát trên chuỗi.
• Ảnh chụp màn hình và tệp PDF tải lên có thể hỗ trợ vận hành, nhưng không có nguồn gốc phiên có thể kiểm tra; các tuyên bố mật mã chứng minh nguồn gốc và tính toàn vẹn, không chứng minh tính trung thực của nội dung gốc.
• Hãy lựa chọn dựa trên danh sách "Chọn nếu" và đưa rủi ro liên quan đến công chứng viên/tập hợp nút cùng các lỗi từ nguồn gốc vào mô hình mối đe dọa.

Bảng này rút gọn lựa chọn thành các khía cạnh dễ quét: nguồn và đường truy cập quyết định ai có thể xem dữ liệu; quyền riêng tư và gốc tin cậy quyết định chi phí của việc chấp nhận sai; độ trễ và loại dữ liệu quyết định phương án nào ít tốn công triển khai hơn. Ảnh chụp màn hình có một hàng riêng vì hoạt động vận hành thường coi hình ảnh là "bằng chứng", nhưng đây không phải cùng một loại bằng chứng với nguồn gốc mật mã.

Hình 1. Góc nhìn song song về zkTLS và oracle truyền thống theo quyền truy cập nguồn, quyền riêng tư, các giả định về độ tin cậy và độ trễ.

zkTLS là gì?

zkTLS, với tư cách là một nhóm kỹ thuật, biến các trường bên trong một phiên TLS/HTTPS thành các tuyên bố mà bên thứ ba có thể kiểm tra: liên kết miền và chứng chỉ, đồng thời tùy chọn chỉ công bố kết quả của một vị từ, chẳng hạn số dư vượt quá ngưỡng, mà không cần cung cấp toàn bộ văn bản thuần.

zkTLS không thay thế HTTPS và cũng không tự động quyết định liệu các thông tin nghiệp vụ của nguồn gốc có chính xác hay không; nó cung cấp bằng chứng về nguồn gốc và tính toàn vẹn, trong đó bảo mật tầng truyền tải là giao thức HTTPS cho phép trao đổi dữ liệu an toàn giữa máy khách và máy chủ. Các nhóm thường sử dụng MPC, đường dẫn Proxy hoặc TEE làm các đường dẫn đảm bảo tính toàn vẹn; "zk" thường là một nhãn bao quát và quá trình bắt tay TLS có thể không bao giờ chạy một mạch zero-knowledge, ngay cả khi bằng chứng zero-knowledge là một lớp tùy chọn trong nhóm giao thức rộng hơn.

Trên thực tế, máy khách mở một phiên TLS đến máy chủ nguồn gốc. Do khóa phiên được chia sẻ giữa máy khách và máy chủ, một máy khách đơn lẻ có thể mã hóa các byte tùy ý rồi sau đó "giải mã" chúng, vì vậy các bên khác không thể coi một bản chép lại thô là đầu ra trung thực của máy chủ. Đó là lý do các thiết kế zkTLS bổ sung một bên làm chứng: công chứng viên MPC cùng chạy giao thức với máy khách, Proxy chứng thực hướng của bản mã hoặc TEE giữ khóa trong môi trường tính toán được niêm phong. Bằng chứng tạo ra cho phép bên xác minh sử dụng tuyên bố mà không biết toàn bộ trang hoặc khóa phiên.

Oracle truyền thống là gì?

Oracle truyền thống ghi các thông tin ngoài chuỗi vào trạng thái trên chuỗi để hợp đồng thông minh có thể truy cập dữ liệu bên ngoài từ các nguồn dữ liệu ngoài chuỗi hoặc thế giới thực. Các đầu ra điển hình gồm nguồn cấp giá, lãi suất, kết quả thể thao hoặc kết quả sự kiện công khai, và các mạng này mạnh nhất với dữ liệu công khai hoặc dữ liệu có sẵn công khai, thay vì hồ sơ người dùng riêng tư. Trọng tâm thiết kế thường là tổng hợp đa nguồn, khả năng hoạt động của nút và khả năng chống thao túng, không phải chứng minh trường HTML nào xuất hiện trong phiên đã đăng nhập của người dùng.

Hợp đồng đọc các cập nhật từ nguồn cấp dữ liệu, không đọc bản chép lại từ trình duyệt. Dữ liệu thị trường công khai liên tục phù hợp tự nhiên với hướng này; các trường trên trang đăng nhập riêng tư thường không có API công khai được ký, và theo mặc định các mạng nguồn cấp dữ liệu không phát lại phiên HTTPS của từng người dùng. Đây là lý do các ứng dụng phi tập trung thường sử dụng oracle cho dữ liệu bên ngoài được chia sẻ, không phải bằng chứng phiên cá nhân. Các bên oracle thường vận hành máy chủ truy xuất điểm cuối công khai; họ không nằm trong kênh TLS của máy khách người dùng, do đó không thể tùy tiện sử dụng trang ngân hàng riêng tư theo cách giao thức zkTLS gồm máy khách và bên làm chứng có thể thực hiện.

Nguồn dữ liệu và đường truy cập khác nhau như thế nào?

Điểm tách biệt cốt lõi là: zkTLS theo dõi các phiên mà người dùng đã có thể mở đến một nguồn gốc; oracle truyền thống theo dõi các nguồn công khai mà các nút vận hành có thể truy xuất.

Trong đường dẫn zkTLS, máy khách hoàn tất HTTPS đến máy chủ miền mục tiêu và bằng chứng có thể được tạo từ bất kỳ trang web HTTPS nào mà không cần quyền truy cập API từ trước. Một số thiết kế sử dụng mô hình Proxy, trong đó một bên trung gian làm chứng hoặc chuyển tiếp trao đổi giữa máy khách và máy chủ thay vì sử dụng xử lý phiên theo kiểu MPC. Các phương pháp dựa trên MPC khác thực thi chung quá trình bắt tay TLS, tức bước giao thức thiết lập khóa phiên an toàn, để không bên nào có thể tự giả mạo bản mã của máy chủ. Công chứng viên, Proxy hoặc TEE để lại bằng chứng có thể kiểm tra; sau đó bằng chứng cho tuyên bố được xây dựng. Trong đường dẫn oracle truyền thống, các nút truy xuất địa điểm giao dịch, chỉ số hoặc API công khai, tổng hợp thành nguồn cấp dữ liệu và hợp đồng đọc nguồn cấp đó. Điều này khiến zkTLS hữu ích để xác minh dữ liệu Web2 từ các hệ thống hiện có khi không có nguồn cấp dữ liệu công khai dễ sử dụng. Nếu không, việc xác thực dữ liệu truyền thống hoặc một quy trình xác nhận khác sẽ yêu cầu một bên riêng biệt truy xuất trực tiếp cùng nguồn đó. Không có phiên người dùng, zkTLS không thể thay thế nguồn cấp công khai; không có nguồn công khai có thể truy xuất, các nút không thể sử dụng an toàn các trường riêng tư sau đăng nhập. Các phương pháp được máy chủ hỗ trợ cũng phụ thuộc vào việc máy chủ nguồn gốc có cho phép xuất dữ liệu hay không, vì vậy bên vận hành có thể giới hạn những gì được chia sẻ. Do đó, các sản phẩm sử dụng Web Proofs coi máy khách, máy chủ và các bên làm chứng là một đường dẫn giao thức. Các tài liệu mô tả cơ chế công khai như phần giải thích zkTLS của Oasis và trang mô hình zk-TLS của EthSystems đều thể hiện cùng đường dẫn từ phiên đến bằng chứng.

Quyền riêng tư, dữ liệu riêng tư và công bố có chọn lọc khác nhau như thế nào?

Một khả năng phổ biến của zkTLS là công bố có chọn lọc: chứng minh một ngưỡng được đáp ứng mà không công bố số tiền chính xác, hoặc trích xuất một trường trong khi che giấu phần còn lại. zkTLS cũng có thể chứng minh các tuyên bố về dữ liệu đó mà không tiết lộ toàn bộ nội dung. Điều này khiến zkTLS hữu ích khi cần chứng minh dữ liệu riêng tư hoặc nhạy cảm mà không làm lộ toàn bộ hồ sơ. Khi nguồn cấp oracle truyền thống đã ở trên chuỗi, giá trị tổng hợp thường hiển thị cho mọi người quan sát, nên mục tiêu về quyền riêng tư thường xung đột với một nguồn cấp có thể đọc hoàn toàn.

Nếu một sản phẩm cần các điều kiện đủ tư cách mà không cần toàn bộ sao kê, zkTLS phù hợp với mục đích này. Điều đó đặc biệt liên quan khi cần chứng minh dữ liệu cá nhân hoặc nhạy cảm như danh tính pháp lý hay hồ sơ tài chính bằng công bố có chọn lọc. Nếu một sản phẩm cần mọi người cùng xác nhận một mức giá công khai, các nguồn cấp truyền thống phù hợp hơn. Hai phương án cũng có thể kết hợp: giá công khai thông qua oracle, thuộc tính người dùng riêng tư thông qua tuyên bố zkTLS. Điều này hỗ trợ đưa dữ liệu internet riêng tư lên chuỗi mà không công bố rộng rãi; một số hệ thống mô tả đây là mô hình cho phép xác minh dữ liệu internet riêng tư trên chuỗi từ các trang web HTTPS mà không làm lộ toàn bộ hồ sơ.

Công bố có chọn lọc thường nằm trên lớp bằng chứng bản chép lại TLS. Máy khách vẫn giao tiếp với máy chủ nguồn gốc; các bên làm chứng hỗ trợ liên kết phản hồi; sau đó một mạch hoặc giao thức che giấu tạo ra bằng chứng nhỏ hơn để các bên khác sử dụng. Trong thiết kế MPC, khóa phiên có thể được chia tách để không bên đơn lẻ nào có thể lạm dụng khóa. Trong thiết kế Proxy, Proxy chứng thực bản mã trong khi máy khách giữ khóa giải mã và chứng minh rằng họ biết văn bản thuần bên trong một phép tính. Dù theo cách nào, mục tiêu là sử dụng các trường riêng tư mà không phải gửi chúng đến mọi máy chủ xác minh.

Các giả định về độ tin cậy, tính toàn vẹn dữ liệu và chế độ lỗi khác nhau như thế nào?

Độ tin cậy của zkTLS dựa trên liên kết miền/chứng chỉ và việc đường dẫn công chứng viên, Proxy hoặc TEE có trung thực và hoạt động hay không. Nếu máy chủ nguồn gốc trả về một trường sai, bằng chứng hợp lệ về mặt hình thức vẫn có thể được chấp nhận, vì nguồn gốc không đồng nghĩa với tính trung thực của nội dung. Khi công bố zero-knowledge được triển khai đúng, bên xác minh vẫn không biết thông tin cá nhân của bên chứng minh. Tuy nhiên, người đánh giá vẫn nên hỏi bên nào nắm giữ vật liệu khóa, bên nào chạy giao thức MPC hoặc Proxy, và chứng chỉ máy chủ nào ghim điểm cuối TLS.

Độ tin cậy của oracle truyền thống dựa trên cấu trúc tập hợp nút, quy tắc đa nguồn và các động lực kinh tế. Các lỗi thường biểu hiện dưới dạng thao túng nguồn, thông đồng giữa các nút hoặc nguồn cấp lỗi thời/thiên lệch. Hồ sơ riêng tư cũng tạo thêm rủi ro bảo mật và nguy cơ rò rỉ dữ liệu nếu bên xác minh hoặc bên vận hành phải kiểm tra trực tiếp. Các danh sách kiểm tra khác nhau: zkTLS nhấn mạnh các kiểm tra về liên kết, vị từ, tính xác thực dữ liệu, tính toàn vẹn dữ liệu và gốc tin cậy; oracle nhấn mạnh tính mới, ngưỡng sai lệch và nguồn tổng hợp. Bỏ qua việc kiểm tra ở bất kỳ bên nào đều biến trạng thái "có vẻ dùng được" thành cảm giác xác minh sai lệch. Giả mạo từ phía máy khách vẫn là một chế độ lỗi chính nếu không có bên làm chứng; bên làm chứng bị xâm phạm là chế độ lỗi chính nếu các bên trong giao thức thông đồng.

Nên đánh đổi giữa độ trễ, chi phí và loại dữ liệu như thế nào?

Ba quy tắc thực tế: dữ liệu thị trường công khai liên tục phù hợp với oracle truyền thống; bằng chứng một lần hoặc tần suất thấp đối với dữ liệu theo từng người dùng hoặc dữ liệu tài chính phù hợp với zkTLS; ảnh chụp màn hình và PDF phù hợp cho hồ sơ vận hành, không phù hợp cho nguồn gốc mật mã.

zkTLS phát sinh chi phí theo từng phiên và chi phí chứng minh, thường có độ trễ cao hơn đường dẫn nguồn cấp đang hoạt động, đồng thời phù hợp với ngưỡng số dư, cấp thành viên và trường dữ liệu việc làm hoặc danh tiếng. Điều này bao gồm chứng minh tài khoản ngân hàng hoặc số dư tài khoản ngân hàng vượt qua ngưỡng yêu cầu mà không tiết lộ thông tin xác thực nền tảng hoặc toàn bộ sao kê. Đường dẫn MPC TLS có thể cần trao đổi dữ liệu nhiều; đường dẫn Proxy có thể sử dụng tính toán tương tác ít hơn nhưng vẫn cần máy chủ làm chứng hoạt động; các đường dẫn TEE chuyển việc xử lý khóa vào phần cứng được niêm phong. Oracle truyền thống duy trì cập nhật liên tục và phù hợp với giá, lãi suất cùng sự kiện công khai, được thiết kế cho dữ liệu thị trường có độ trễ thấp mà nhiều ứng dụng máy khách sử dụng ở mỗi khối.

Ảnh chụp màn hình, PDF hoặc bản tải lên thủ công có thể cho thấy "một thứ trông giống một trang", nhưng bên thứ ba không thể xác minh bằng mật mã rằng một phiên TLS đã truy cập máy chủ miền mục tiêu hoặc các trường không bị máy khách chỉnh sửa. Các tuyên bố theo kiểu zkTLS có thể đảm bảo tính xác thực dữ liệu và duy trì nguồn gốc dữ liệu cho loại dữ liệu đầu vào riêng tư này, nhưng chúng vẫn không chứng minh các thông tin nghiệp vụ từ nguồn gốc là đúng. Ngay cả khi đó, các trang nguồn gốc sai, lỗi DOM và công chứng viên ngừng hoạt động vẫn làm gián đoạn tính chính xác hoặc khả dụng. Coi ảnh chụp màn hình là cổng duy nhất nghĩa là tin tưởng người tải lên và người đánh giá; coi bằng chứng là "sự thật" nghĩa là bỏ qua khả năng các lỗi tại nguồn gốc vẫn có thể hợp lệ về mặt hình thức. Các nhóm sử dụng cả ảnh chụp màn hình và bằng chứng mật mã nên ghi rõ mỗi cổng chấp nhận loại bằng chứng nào.

Bạn nên chọn zkTLS hay oracle truyền thống?

Ưu tiên zkTLS nếu: dữ liệu nằm sau một trang HTTPS đăng nhập hoặc API riêng tư mà máy khách có thể mở đến máy chủ nguồn gốc; cần công bố tối thiểu ở cấp vị từ; không có sẵn nguồn cấp công khai đa nguồn; chấp nhận được độ trễ chứng minh theo từng yêu cầu và gốc tin cậy là công chứng viên, Proxy hoặc TEE. Đây thường là hướng tốt hơn để xác minh danh tính hoặc các bằng chứng khác về hồ sơ người dùng riêng tư khi không thể chấp nhận công bố toàn bộ. Chọn MPC khi tính toán chung giữa các bên quan trọng hơn sự thuận tiện trên trình duyệt; chọn Proxy khi muốn sử dụng các tính năng Proxy hiện có của máy khách; chọn TEE khi việc lưu giữ khóa trong môi trường niêm phong là biện pháp kiểm soát chính.

Ưu tiên oracle truyền thống nếu: cần giá thị trường công khai hoặc kết quả sự kiện liên tục; hợp đồng phải thanh toán dựa trên nguồn cấp dữ liệu mà mạng có thể đọc; đã có sẵn cơ chế tổng hợp đa nguồn và giám sát sai lệch trưởng thành; quyền riêng tư không phải hạn chế chính của trường dữ liệu. Các nguồn cấp này thường thúc đẩy quyết định của hợp đồng thông minh từ các hệ thống bên ngoài được chia sẻ thay vì hồ sơ cá nhân. Mạng oracle được xây dựng để nhiều hợp đồng máy khách có thể sử dụng cùng một nguồn cấp công khai mà không yêu cầu mỗi người dùng phải mở một phiên TLS riêng tư.

Kết hợp cả hai nếu: giá công khai đi qua oracle và thuộc tính người dùng riêng tư đi qua zkTLS. Sự kết hợp này phổ biến khi ứng dụng cần nguồn cấp công khai cùng các tuyên bố riêng tư cho quy trình tài sản trong thế giới thực hoặc logic nghiệp vụ nhạy cảm. Dù theo cách nào, hãy ghi "nguồn gốc ≠ sự thật" vào các quy tắc: lỗi máy chủ nguồn gốc, thông đồng nút, công chứng viên bị xâm phạm, quản lý khóa yếu và thiết kế lại trang đều là các rủi ro cốt lõi, không phải chú thích phụ. Lựa chọn giao thức cần nêu rõ các bên nào phải duy trì sự trung thực để bằng chứng vẫn có ý nghĩa.

Tóm tắt

zkTLS và oracle truyền thống trả lời các câu hỏi trên chuỗi khác nhau: oracle truyền thống chủ yếu phục vụ dữ liệu bên ngoài được chia sẻ, trong khi zkTLS giúp các hồ sơ web riêng tư có thể kiểm tra được mà vẫn bảo toàn quyền riêng tư. Khoảng cách này trong lịch sử khiến các nguồn cấp công khai dễ sử dụng hơn, trong khi dữ liệu riêng tư ít được khai thác hơn. Sau khi đối chiếu quyền truy cập nguồn, quyền riêng tư, gốc tin cậy và độ trễ, các trường trên trang riêng tư sau đăng nhập và nguồn cấp công khai hiếm khi có thể thay thế lẫn nhau.

Tóm lại: sử dụng oracle truyền thống khi nhiều hợp đồng cần cùng một nguồn cấp công khai; sử dụng zkTLS khi máy khách phải chứng minh phản hồi TLS riêng tư từ máy chủ nguồn gốc bằng bằng chứng công bố có chọn lọc. MPC, Proxy và TEE vẫn là các kiểu bên làm chứng chính cho đường dẫn giao thức đó, và mỗi kiểu thay đổi bên nào nắm giữ vật liệu khóa cũng như lượng tính toán tương tác mà máy khách phải thực hiện. Ảnh chụp màn hình và PDF không thể bù đắp khoảng trống về nguồn gốc mật mã; bằng chứng TLS không thể tự động đảm bảo nội dung từ nguồn gốc là chính xác. Lựa chọn bằng danh sách "Chọn nếu", đồng thời ghi các chế độ lỗi của công chứng viên/nút và nguồn gốc vào mô hình mối đe dọa, hiệu quả hơn việc tranh luận về nhãn gọi.

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

Sự khác biệt giữa zkTLS và oracle truyền thống là gì?

Oracle truyền thống chủ yếu cung cấp dữ liệu công khai cho hợp đồng thông minh, trong khi các sản phẩm sử dụng zkTLS khi cần chứng minh tính xác thực của dữ liệu trong một phiên HTTPS do người dùng nắm giữ; điều này cũng ảnh hưởng đến việc bên xác minh có thấy hồ sơ nền tảng hay chỉ thấy bằng chứng về hồ sơ đó. zkTLS chứng minh rằng các trường trong phiên TLS đến từ máy chủ được liên kết với miền và chứng chỉ. Một số thiết kế sử dụng MPC, tức tính toán đa bên an toàn, trong quá trình bắt tay TLS giữa máy khách và các bên công chứng viên; các thiết kế khác dựa vào Proxy hoặc bên làm chứng dựa trên TEE. Oracle truyền thống liên tục ghi các thông tin công khai ngoài chuỗi, chẳng hạn giá, vào hợp đồng thông qua tập hợp nút và tổng hợp đa nguồn. Một phương án tối ưu nguồn gốc phiên; phương án kia tối ưu khả năng sẵn sàng của nguồn cấp và khả năng chống thao túng. Trong các thiết kế dựa trên Proxy hoặc bên làm chứng, bản thân máy chủ nguồn gốc thường không cần thay đổi và máy khách vẫn nắm giữ hoặc chia sẻ khóa phiên theo quy tắc giao thức.

Khi nào nên sử dụng zkTLS thay vì oracle truyền thống?

Sử dụng zkTLS cho các trường riêng tư sau đăng nhập cần công bố tối thiểu và không có API công khai được ký, đặc biệt khi sản phẩm cần chia sẻ dữ liệu có thể xác minh từ một nguồn riêng tư bằng cách sử dụng mã thông báo truy cập hoặc thông tin xác thực phiên để máy khách có thể xác thực trực tiếp với máy chủ nguồn gốc thay vì giao hồ sơ thô cho bên trung gian. Một số triển khai chạy tính toán bằng chứng zero-knowledge cục bộ để các thuộc tính được chọn có thể được chứng minh mà không tải lên toàn bộ hồ sơ. Sử dụng oracle truyền thống cho giá thị trường công khai hoặc kết quả sự kiện liên tục cần thanh toán mà mạng có thể đọc; điều đó có thể giữ hồ sơ riêng tư ngoài nguồn cấp oracle công khai trong khi vẫn cho phép hợp đồng sử dụng giá dùng chung. Các nguồn cấp công khai và thuộc tính riêng tư có thể kết hợp trong một sản phẩm khi các bên khác nhau cần những loại bằng chứng khác nhau.

Ảnh chụp màn hình hoặc tệp PDF tải lên có thể thay thế bằng chứng zkTLS không?

Không một cách đáng tin cậy. Ảnh chụp màn hình và PDF từ một trang web có thể trông thuyết phục trong vận hành, nhưng chúng không có nguồn gốc phiên TLS có thể kiểm tra và không mang bằng chứng mật mã về nguồn gốc hoặc tính toàn vẹn của phiên. Vì vậy, bên thứ ba không thể dễ dàng loại trừ ảnh đã chỉnh sửa hoặc trang không đúng. Ngược lại, bên làm chứng HTTP Proxy có thể quan sát hoặc định tuyến trao đổi để duy trì nguồn gốc có thể kiểm tra theo cách mà ảnh chụp màn hình hoặc PDF không thể làm được. Các tuyên bố theo kiểu zkTLS cung cấp liên kết miền và các đường kiểm tra tính toàn vẹn, nhưng nếu nguồn gốc trả về dữ liệu không tốt, bằng chứng vẫn có thể hợp lệ về mặt hình thức.

Việc xác minh zkTLS thành công có nghĩa dữ liệu nguồn gốc là đúng không?

Không. Kết quả đạt thường có nghĩa là tuyên bố đáp ứng yêu cầu về nguồn gốc và tính toàn vẹn theo các giả định tin cậy đã nêu, đồng thời bằng chứng có thể bao gồm các kiểm tra tính toàn vẹn như mã xác thực thông điệp trên dữ liệu phản hồi. Bằng chứng có thể thể hiện nguồn gốc và tính toàn vẹn, trong khi thông tin nhạy cảm nền tảng vẫn có thể phản ánh một trường sai hoặc dữ liệu nhập từ phía nguồn gốc không chính xác; lỗi nhập dữ liệu tại nguồn gốc, trang bị can thiệp hoặc trường API không đúng vẫn có thể tạo ra bằng chứng hợp lệ về mặt hình thức. Một số thiết kế cũng dẫn xuất khóa mã hóa trong phiên để người dùng có thể giải mã phản hồi trong khi bên xác minh vẫn không thể thấy hồ sơ nền tảng. Nguồn gốc có thể kiểm tra và tính trung thực của nội dung là các lớp riêng biệt.

Oracle truyền thống có thể trực tiếp sử dụng các trường trên trang web sau đăng nhập của người dùng không?

Thông thường không thể sử dụng chúng như một phiên HTTPS cá nhân. Các nút truyền thống thường truy xuất nguồn công khai từ API hoặc các điểm cuối công khai khác, không phải bản chép lại phiên riêng tư sau đăng nhập hoặc Web Proofs của người dùng. Một số thiết kế oracle riêng tư-đến-riêng tư mới hơn thay vào đó gửi dữ liệu TLS đã xác thực vào các máy chủ tính toán mù thay vì công bố dữ liệu như một nguồn cấp tiêu chuẩn. Mô hình này tập trung vào việc cung cấp nguồn gốc dữ liệu cho dữ liệu đầu vào riêng tư, có thể giữ dữ liệu được mã hóa ở trạng thái riêng tư để tuân thủ quy định, đồng thời có thể kết hợp dữ liệu từ nhiều máy khách cho các phép tính chung. Các nền tảng như Private-to-Private Oracles của Nillion sử dụng tính toán mù để bảo vệ quyền riêng tư, trong khi Reclaim Protocol là một ví dụ theo kiểu Proxy, khác với phương pháp đó. Điều này cũng có thể nâng cao bảo mật bằng cách chuyển dữ liệu phiên nhạy cảm vào tính toán riêng tư thay vì để lộ nội dung trang thô; khi các trang riêng tư sau đăng nhập không có API mở được ký, Web Proofs theo kiểu zkTLS hoặc các quan hệ đối tác dữ liệu chuyên dụng phù hợp hơn một tác vụ nguồn cấp mặc định.