Chuyển tiêu đề ban đầu ‘Làm thế nào chúng ta có thể làm cho việc sử dụng dữ liệu web2 trong web3 thực sự riêng tư và có thể xác minh?’

Nhiều người tuyên bố rằng web3 là internet mới định nghĩa nó với cụm từ “đọc, viết, sở hữu.” Phần “đọc” và “viết” rõ ràng, nhưng khi nói đến “sở hữu” trong thuật ngữ dữ liệu, chúng ta hiếm khi sở hữu bất cứ điều gì ngày nay.

Dữ liệu người dùng thường bị các tập đoàn đánh cắp và sử dụng một cách có lợi cho họ; chúng ta không thực sự sở hữu bất cứ điều gì trên internet.

Tuy nhiên, chúng ta không thể chỉ chuyển sang một thế giới chỉ tồn tại web3 mà không chia sẻ gì cả. Không, chúng ta vẫn cần phải chia sẻ, nhưng chỉ là những gì cần thiết.

Như một người có hộ chiếu yếu, tôi bị kẹt khi phải nộp đơn xin thị thực điện tử và gửi đi vô số chi tiết về bản thân để chứng minh rằng tôi đủ điều kiện để xin visa cụ thể. Và tôi luôn tự hỏi mình:

• Tại sao tôi phải chia sẻ toàn bộ sao kê ngân hàng khi họ chỉ cần xác nhận một mức thu nhập cụ thể?

• Tại sao tôi nên cung cấp đặt phòng khách sạn cụ thể thay vì chỉ chứng minh rằng tôi đã đặt phòng khách sạn ở đất nước này?

• Tại sao tôi phải nộp đầy đủ chi tiết hộ chiếu khi họ chỉ cần xác minh nơi cư trú cố định của tôi tại quốc gia hiện tại?

Có hai vấn đề chính ở đây: dịch vụ biết nhiều hơn họ cần, và dữ liệu bạn cung cấp không riêng tư. Nhưng điều này liên quan đến bảo mật và riêng tư trong tiền điện tử như thế nào?

1. Web3 không thể tồn tại mà không có dữ liệu web2.

Như hầu hết mọi người đã biết, hợp đồng thông minh về cơ bản không biết giá của BTC, ETH, SOL, hoặc bất kỳ tài sản nào khác. Nhiệm vụ này được giao cho các nguồn thông tin, luôn đăng dữ liệu công khai từ thế giới bên ngoài vào hợp đồng thông minh.

Trong thế giới Ethereum, vai trò này gần như bị độc quyền bởi @chainlinkvới mạng lưới oracles của họ để đảm bảo chúng ta không phụ thuộc vào một nút duy nhất. Vì vậy, chúng ta thực sự cần dữ liệu web2 cho nhiều trường hợp sử dụng hơn chỉ là biết giá của một số tài sản cụ thể.

Tuy nhiên, điều này chỉ áp dụng cho dữ liệu công khai. Điều gì sẽ xảy ra nếu tôi muốn kết nối an toàn tài khoản ngân hàng hoặc tài khoản Telegram của mình và chia sẻ thông tin nhạy cảm không có sẵn công khai nhưng riêng tư đối với tôi?

Suy nghĩ đầu tiên là: làm thế nào chúng ta có thể đưa dữ liệu này lên một chuỗi khối với chứng minh rằng dữ liệu riêng tư được bảo mật?

Rất tiếc, nó không hoạt động theo cách đó vì máy chủ không ký các phản hồi mà họ gửi, vì vậy bạn không thể xác minh một cách đáng tin cậy điều gì đó như vậy trong hợp đồng thông minh.

Giao thức bảo mật giao tiếp trên mạng máy tính được gọi là TLS: Bảo mật Tầng Vận chuyển. Ngay cả khi bạn chưa từng nghe về nó, bạn vẫn sử dụng nó hàng ngày. Ví dụ, khi bạn đọc bài viết này, bạn sẽ thấy “https://“ trong thanh địa chỉ trình duyệt của bạn.

Nếu bạn cố truy cập trang web với kết nối “http://” (không có “s”), trình duyệt sẽ cảnh báo rằng kết nối không an toàn. Chữ “s” trong liên kết đó tượng trưng cho TLS, giúp bảo vệ kết nối của bạn, đảm bảo quyền riêng tư và ngăn chặn bất kỳ ai đánh cắp dữ liệu bạn đang truyền.

2. Kết nối đã an toàn, chúng ta có thể vận chuyển và sử dụng nó trong web3 không?

Như tôi đã đề cập trước đó, chúng ta đối mặt với một vấn đề xác minh: các máy chủ không ký các phản hồi mà họ gửi đi, vì vậy chúng ta không thể thực sự xác minh dữ liệu.

Ngay cả khi một nguồn dữ liệu đồng ý chia sẻ dữ liệu của nó, giao thức TLS tiêu chuẩn không thể chứng minh tính xác thực của nó cho người khác. Chỉ đơn giản là chuyển phản hồi là không đủ: khách hàng có thể dễ dàng thay đổi dữ liệu cục bộ, chia sẻ những phản hồi đó phơi bày đầy đủ chúng, gây rủi ro cho quyền riêng tư của người dùng.

Một cách tiếp cận vấn đề xác minh là phiên bản cải tiến của TLS được gọi là zkTLS.

Cơ chế hoạt động của zkTLS tương tự như TLS nhưng có chút khác biệt, đây là cách hoạt động của nó:

• Bạn truy cập một trang web thông qua kết nối TLS an toàn và gửi yêu cầu cần thiết.

• zkTLS tạo ra một chứng minh zk xác minh dữ liệu trong khi chỉ tiết lộ những chi tiết cụ thể mà người dùng muốn chứng minh, giữ cho mọi thứ khác riêng tư.

• Bằng chứng zk được tạo sau đó được các ứng dụng khác sử dụng để xác nhận và xác minh rằng thông tin được cung cấp là chính xác.

Khi tôi nói về zkTLS, tôi đang đề cập đến các dự án sử dụng zkTLS, nhưng có các cách tiếp cận khác nhau để xác minh dữ liệu bằng cách sử dụng các giải pháp khác nhau:

1. TEE (Môi trường Thực thi Đáng tin cậy)
2. MPC (Multi-Party Computation)
3. Proxy

Thú vị thay, mỗi phương pháp đều giới thiệu bộ sưu tập các trường hợp sử dụng độc đáo của riêng nó. Vậy, chúng khác nhau như thế nào?

3. Tại sao không có một tiêu chuẩn duy nhất cho zkTLS? Chúng khác nhau như thế nào?

zkTLS không phải là một công nghệ duy nhất vì việc xác minh dữ liệu web riêng tư mà không để lộ nó có thể được tiếp cận từ nhiều góc độ, mỗi góc độ có sự đánh đổi riêng. Ý tưởng cốt lõi là mở rộng TLS bằng các bằng chứng, nhưng cách bạn tạo và xác thực các bằng chứng đó phụ thuộc vào cơ chế cơ bản.

Như tôi đã đề cập trước đây, ba cách tiếp cận chính là sử dụng TEE-TLS, MPC-TLS hoặc Proxy-TLS.

TEE dựa vào phần cứng chuyên dụng, như Intel SGX hoặc AWS Nitro Enclaves, để tạo ra một “hộp đen” an toàn, nơi dữ liệu có thể được xử lý và tạo bằng chứng. Phần cứng đảm bảo dữ liệu ở chế độ riêng tư và các tính toán chống giả mạo.

Trong thiết lập TEE-based zkTLS, TEE chạy giao thức, chứng minh việc thực thi và nội dung của phiên TLS. Người xác minh là chính TEE, vì vậy sự tin cậy phụ thuộc vào nhà sản xuất TEE và khả năng chống lại các cuộc tấn công. Phương pháp này hiệu quả với chi phí tính toán và mạng thấp.

Tuy nhiên, nó có một lỗ lỗi lỗn: bạn phải tin tượng nhà sản xuất phần cống, và các lỗ hội trong TEEs (như các cuộn tưởng kéo theo) có thể phá về toàn bộ hệ thống.

Proxy-TLS và MPC-TLS là những phương pháp được áp dụng rộng rãi nhất do phạm vi sử dụng rộng lớn của chúng. Các dự án như @OpacityNetworkvà @reclaimprotocol, được xây dựng trên@eigenlayer, tận dụng các mô hình này để đảm bảo bảo mật dữ liệu và quyền riêng tư cùng với một lớp bảo mật kinh tế bổ sung.

Hãy xem xét xem các giải pháp này có bảo mật như thế nào, các trường hợp sử dụng giao thức zkTLS cho phép, và những điều đã hoạt động ngày hôm nay.

4. Có gì đặc biệt về MPC-TLS và Mạng Opacity?

Trong quá trình Bắt tay TLS (nơi mà một máy khách và một máy chủ đồng ý cách thức để giao tiếp một cách an toàn bằng cách chia sẻ các khóa mã hóa), vai trò của trang web vẫn không thay đổi, nhưng quá trình của trình duyệt lại có một số điều khác biệt.

Thay vì tạo khóa bí mật của riêng mình, nó sử dụng một mạng lưới các nút để tạo khóa bí mật đa bên thông qua MPC. Khóa này thực hiện bắt tay cho trình duyệt, đảm bảo rằng không có thực thể nào biết khóa được chia sẻ.

Mã hóa và giải mã đòi hỏi sự hợp tác giữa tất cả các nút và trình duyệt, mỗi nút thêm hoặc loại bỏ phần mã hóa của mình theo thứ tự trước khi dữ liệu đến hoặc rời khỏi trang web. MPC-TLS cung cấp bảo mật mạnh mẽ và có thể được phân phối để không có nhóm nào có toàn quyền.

Opacity Network tăng cường sự cổ điển @tlsnotarykhung cơ bản bằng cách thêm các biện pháp bảo vệ để giảm thiểu các vấn đề về sự tin tưởng. Nó sử dụng nhiều biện pháp an ninh như:

1. Xác minh trên chuỗi của các ID tài khoản web2
2. Giao diện commit
3. Tiết lộ kế hoạch
4. Mẫu mẫu lấy mẫu mạng MPC ngẫu nhiên
5. Nhật ký nỗ lực có thể xác minh

Các ID tài khoản, tĩnh trong các hệ thống web2, cho phép chứng minh bởi ủy ban nơi mà mười nút khác nhau phải xác nhận sở hữu. Điều này liên kết tài khoản với một ví tiền điện tử duy nhất, ngăn chặn việc thử lại với các ví khác để tìm nút đồng âm mưu.

Bạn có thể xem cách Opacity hoạt động chi tiết bên dưới:

Các nút Opacity hoạt động trong một TEE, làm cho việc kết đồng hầu như không thể nếu TEE là an toàn. Vượt qua TEEs, Opacity cũng sử dụng Eigenlayer để tận dụng một AVS, yêu cầu các nút phải restake 32 stETH, với việc cắt giảm ngay lập tức cho hành vi không đúng, tránh các trì hoãn liên quan đến thời gian chờ cooldowns.

Bạn có thể thấy rằng Opacity sử dụng cả MPC và TEE, nhưng vì MPC được sử dụng cho zkTLS trong khi TEE được sử dụng cơ bản để bảo mật nút, nó vẫn được gọi là MPC-TLS.

Tuy nhiên, nếu các TEEs gặp sự cố, điều đó có thể cho phép một nút tham gia vào sự đồng lòng trong MPC. Đó là một trong những lý do tại sao một lớp bảo mật kinh tế bổ sung cần được áp dụng để ngăn chặn hành vi này.

Đó cũng là lý do tại sao Opacity đang phát triển một cơ chế tiết lộ thông tin nơi người dùng có thể chứng minh rằng một công chứng viên đã hành động không đúng cách sẽ được thưởng bằng một phần của tiền phạt được áp dụng vào cổ phần của công chứng viên đó.

Do vì sự đơn giản trong tích hợp, bảo mật và sự riêng tư mà nó cung cấp, Opacity đã thu hút các giao thức khác nhau để tích hợp nó vào sản phẩm của họ trên các lĩnh vực tiêu dùng, DeFi và AI agent.

Nhóm từ @earnos_io đang phát triển một nền tảng nơi các thương hiệu có thể thưởng cho người dùng khi tham gia hoặc hoàn thành nhiệm vụ. EarnOS sử dụng công nghệ của Opacity để chứng minh các đặc điểm thông qua các ứng dụng phổ biến mà không tiết lộ thông tin cá nhân, cho phép các thương hiệu nhắm mục tiêu đến đối tượng trong khi người dùng giữ quyền riêng tư và kiếm phần thưởng.

Opacity cũng được tích hợp vào @daylightenergy_giao thức, phát triển một mạng lưới tiện ích điện phân cấp nơi người dùng có thể kiếm phần thưởng khi đóng góp vào các giải pháp năng lượng sạch. Nhờ vào Opacity, người dùng có thể chứng minh sở hữu thiết bị năng lượng trên chuỗi mà không cần phần cứng chuyên dụng.

Độ mờ thậm chí có thể được tích hợp với các đại lý trí tuệ nhân tạo, mang lại sự xác minh và tính minh bạch hơn cho một lĩnh vực đang đối mặt với những thách thức đáng kể hiện nay. zkTLS đã được tích hợp vào @elizaOS, cho phép tương tác trí tuệ nhân tạo có thể xác minh mà không mất quyền riêng tư.

Tuy nhiên, TEE-TLS và MPC-TLS chỉ là hai biến thể của zkTLS, còn có một biến thể thứ ba được gọi là Proxy-TLS, với Mạng Reclaim được coi là biểu hiện nổi tiếng nhất của mô hình này. Vậy, nó khác biệt như thế nào về công nghệ so với hai biến thể khác, và các trường hợp sử dụng nào có thể được kích hoạt bởi Proxy-TLS?

5. Có điều gì đặc biệt về Proxy-TLS và Reclaim Protocol không?

Các proxy HTTPS, phổ biến trên internet, chuyển tiếp lưu lượng được mã hóa mà không truy cập vào nội dung của nó. Trong mô hình proxy zkTLS, nó hoạt động gần như giống với một số sự bổ sung nhỏ:

• Trình duyệt gửi yêu cầu đến trang web thông qua một proxy, cũng xử lý các phản hồi của trang web.

• Proxy thấy tất cả các trao đổi được mã hóa và chứng thực tính xác thực của chúng, ghi chú xem mỗi trao đổi là yêu cầu hay phản hồi.

• Trình duyệt sau đó tạo ra một chứng minh zk cho biết nó có thể mã hóa dữ liệu này bằng một khóa chia sẻ mà không tiết lộ khóa và hiển thị kết quả.

• Điều này hoạt động vì gần như không thể tạo ra một khóa giả biến dữ liệu thành bất cứ thứ gì hợp lý, vì vậy chỉ cần hiển thị bạn có thể giải mã nó là đủ.

Việc tiết lộ khóa sẽ đe dọa tất cả các tin nhắn trước đó, bao gồm dữ liệu nhạy cảm như tên người dùng và mật khẩu. Proxy-TLS khá nhanh, giá cả phải chăng, và xử lý khối lượng dữ liệu lớn tốt, làm cho nó lý tưởng cho cài đặt truyền thông cao.

Đa số các máy chủ không hạn chế truy cập dựa trên địa chỉ IP khác nhau, làm cho phương pháp này khá phổ biến.

Reclaim Protocol sử dụng Proxy-TLS để xác minh dữ liệu hiệu quả và sử dụng proxy để tránh tường lửa Web2 ngăn chặn việc chặn proxy quy mô lớn.

Đây là cách nó hoạt động:

Vấn đề chính ở đây là sự kết hợp: nếu người dùng và người chứng thực kết hợp, họ có thể ký bất cứ điều gì và hành động một cách độc ác. Để giảm thiểu điều này, Reclaim tích hợp một tập hợp con của các bộ xác minh được chọn để giới thiệu sự ngẫu nhiên và chặn các hành vi lạm dụng như vậy.

Reclaim sử dụng AVS của Eigen để phi tập trung hóa việc xác thực dữ liệu. Các nhà điều hành EigenLayer có thể hoạt động như những người chứng thực, nhưng họ sẽ cần triển khai AVS riêng của mình để chỉ định logic chứng thực cho dịch vụ của họ.

Reclaim là một nền tảng cho phép các trường hợp sử dụng độc đáo như nhập dữ liệu chia sẻ chuyến đi cho ứng dụng vận tải, kết nối dữ liệu ngoài chuỗi cho kinh tế blockchain, xác minh danh tính bằng dữ liệu thẻ căn cước quốc gia, tạo ra các giải pháp dữ liệu tùy chỉnh thông qua các công cụ phát triển, và nhiều hơn nữa.

Hệ sinh thái Reclaim là nơi đặt chân của hơn 20 dự án, nhưng tôi muốn nhấn mạnh về 4 dự án trong lĩnh vực thị trường tiền tệ, danh tính số, người tiêu dùng và tuyển dụng.

@3janexyzlà thị trường tiền tệ dựa trên tín dụng đầu tiên trên Base, cung cấp các dòng tín dụng đảm bảo cho người dùng tiền mã hóa bằng cách đánh giá khả năng tín dụng và lưu lượng tiền mặt tương lai của họ, sử dụng cả dữ liệu tài chính on-chain và off-chain.

3Jane sử dụng mô hình ủy quyền của Reclaim để xác minh dữ liệu tín dụng từ VantageScore, Cred, Coinbase và Plaid, đảm bảo sự riêng tư của dữ liệu này.

Một ứng dụng khác của điểm tín dụng với zkTLS là thông qua @zkme_‘s tính năng, zkCreditScore. Nó sử dụng Giao thức Reclaim để lấy điểm tín dụng của bạn tại Mỹ một cách an toàn với zkTLS. Điều này cho phép zkMe kiểm tra điểm tín dụng của người dùng và tạo ra các mã thông báo soulbound duy nhất (SBTs) để lưu trữ dữ liệu này.

Có thể có bất kỳ trường hợp sử dụng nào khác ngoài điểm tín dụng không? Tất nhiên, có.

Chúng ta có thể đến @zkp2pnhư một ví dụ, đó là một thị trường hàng tiêu dùng sử dụng Reclaim để xác minh dữ liệu người dùng của Ticketmaster cũng như xác minh thanh toán người dùng.

Đồng thời, @bondexapp, một trong những bảng công việc phổ biến nhất trong tiền điện tử, sử dụng Reclaim để lấy bằng chứng về công việc của hồ sơ, xác minh rằng dữ liệu là thật, riêng tư và có thể xác minh được.

Nhìn vào các trường hợp sử dụng có thể thực hiện thông qua zkTLS, khả năng xác minh bản ghi TLS trên chuỗi đã mở khóa nhiều chức năng mới, cho phép người dùng kiểm soát dữ liệu của mình mà không cần sự cho phép từ các tập đoàn lớn.

Quan trọng hơn, zkTLS được tạo ra để đảm bảo rằng dữ liệu cá nhân của bạn không bị sử dụng chống lại bạn. Vậy, điều này đang dẫn đến đâu?

6. Có phải zkTLS ở đây để ở lại không?

Vẫn còn công việc phải làm, nhưng các giao thức zkTLS khác nhau đã giới thiệu các trường hợp sử dụng mới đang phân phối lại quyền lực trở lại cho người dùng.

@Tim_RoughgardenTrong podcast crypto của a16z nhấn mạnh rằng các chứng minh zk, được đề xuất vào năm 1985, chỉ trở nên phổ biến với các ứng dụng blockchain, nhờ hàng trăm nhà phát triển làm việc để giảm kích thước và chi phí chứng minh.

Và bây giờ, các đóng góp từ ngành công nghiệp blockchain đang được sử dụng trong các lĩnh vực khác ngoài việc chỉ là tiền điện tử.

Tôi mong đợi một câu chuyện tương tự sẽ diễn ra với zkTLS, bắt đầu bằng việc triển khai trong Web3 và sau đó mở rộng ra ngoài, bởi vì, như tôi đã nói trước đó, hiện tại, chúng ta “đọc” và “viết,” nhưng chúng ta gần như không được bảo vệ và gần như không “sở hữu” thậm chí cả dữ liệu của chính chúng ta.

Disclaimer:

1. Bài viết này được sao chép từ [gatePavel Paramonov]. Tất cả bản quyền thuộc về tác giả gốc [Pavel Paramonov]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Gate Learnnhóm, và họ sẽ xử lý nhanh chóng.
2. Miễn Trừ Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Nhóm Gate Learn thực hiện dịch các bài viết sang các ngôn ngữ khác. Việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép trừ khi có được đề cập.