Tác giả: EQ Labs Nguồn: cân bằng Bản dịch: Shan Oppa, Golden Finance
Phần số của loạt bài về quyền riêng tư của chúng tôi Hình 1 giải thích "quyền riêng tư" nghĩa là gì, quyền riêng tư trong mạng chuỗi khối khác với quyền riêng tư trên web2 như thế nào và tại sao khó đạt được quyền riêng tư trong chuỗi khối.
Điểm chính của bài viết này là nếu trạng thái cuối lý tưởng là có cơ sở hạ tầng bảo mật có thể lập trình có thể xử lý trạng thái riêng tư được chia sẻ mà không có bất kỳ điểm lỗi nào, Rồi mọi con đường đều dẫn tới MPC. Chúng tôi cũng sẽ khám phá sự trưởng thành của MPC và các giả định về độ tin cậy của nó, nêu bật các phương pháp tiếp cận thay thế, so sánh sự đánh đổi và cung cấp cái nhìn tổng quan về ngành.
Gạt bỏ quá khứ và đón nhận tương lai
Nền tảng bảo mật hiện có trong blockchain Cơ sở vật chất được thiết kế để xử lý các trường hợp sử dụng rất cụ thể, chẳng hạn như thanh toán riêng tư hoặc bỏ phiếu. Đây là một quan điểm khá hẹp, chủ yếu phản ánh việc sử dụng blockchain hiện tại (giao dịch, chuyển nhượng và đầu cơ). Như Tom Walpo đã nói - Tiền điện tử gặp phải Nghịch lý Fermi:
Trong Ngoài việc tăng cường quyền tự do cá nhân, chúng tôi tin rằng quyền riêng tư là điều kiện tiên quyết để mở rộng không gian thiết kế blockchain ngoài siêu dữ liệu đầu cơ hiện tại. Nhiều ứng dụng yêu cầu một số trạng thái riêng tư và/hoặc logic ẩn để hoạt động bình thường:
< mạnh>Trạng thái ẩn: Phần lớn các trường hợp sử dụng tài chính yêu cầu bảo mật từ (ít nhất) những người dùng khác và nhiều trò chơi nhiều người chơi sẽ kém thú vị hơn đáng kể nếu không có trạng thái ẩn nào đó (ví dụ: nếu Mọi người đều có thể nhìn thấy thẻ của nhau ).
Ẩn logic: Một số trường hợp sử dụng yêu cầu ẩn một số logic trong khi vẫn cho phép người khác sử dụng nó Các ứng dụng, chẳng hạn như công cụ khớp lệnh, chiến lược giao dịch trên chuỗi, v.v.
Phân tích thực nghiệm (từ web2 và web3) cho thấy hầu hết người dùng không sẵn lòng trả thêm tiền hoặc bỏ qua để tăng cường quyền riêng tư Như một phần thưởng , chúng tôi cũng đồng ý rằng bản thân quyền riêng tư không phải là điểm bán hàng. Tuy nhiên, nó cho phép tồn tại các trường hợp sử dụng mới và (hy vọng) có ý nghĩa hơn trên blockchain – giúp chúng ta thoát khỏi Nghịch lý Fermi.
Công nghệ nâng cao quyền riêng tư (PET) và các giải pháp mật khẩu hiện đại("Mật khẩu có thể lập trình ” )là những nền tảng cơ bản để đạt được tầm nhìn này(Để biết thêm thông tin về các giải pháp khác nhau hiện có và sự cân bằng giữa chúng, hãy xemPhụ lục < /em>).
Ba giả định ảnh hưởng đến quan điểm của chúng tôi
Ba giả định chính xác định quan điểm của chúng tôi về khu vực A hãy xem cơ sở hạ tầng bảo mật blockchain sẽ phát triển như thế nào:
Tiền điện tử sẽ chuyển từ nhà phát triển ứng dụng sang Trừu tượng trong tay: Hầu hết các nhà phát triển ứng dụng không muốn (hoặc không biết cách xử lý) mã hóa cần thiết để xử lý quyền riêng tư. Yêu cầu họ triển khai mật mã của riêng mình và xây dựng các chuỗi dành riêng cho ứng dụng riêng tư (ví dụ: Zcash hoặc Namada) Hoặc các ứng dụng riêng tư trên chuỗi công khai(ví dụ: Tornado Cash) là không hợp lý. Điều này đơn giản là quá phức tạp và tốn kém và hiện đang giới hạn không gian thiết kế của hầu hết các nhà phát triển (không có khả năng xây dựng các ứng dụng yêu cầu một số đảm bảo về quyền riêng tư). Do đó, chúng tôi tin rằng sự phức tạp của việc quản lý phần mã hóa phải được loại bỏ khỏi tầm tay của các nhà phát triển ứng dụng. Hai cách tiếp cận ở đây là cơ sở hạ tầng bảo mật có thể lập trình (L1/L2 riêng tư được chia sẻ) hoặc Bí mật dưới dạng dịch vụ, cho phép thuê ngoài các tính toán bí mật.
Nhiều trường hợp sử dụng (có thể nhiều hơn chúng tôi nghĩ) yêu cầu trạng thái riêng tư được chia sẻ: Như đã đề cập trước đó, nhiều ứng dụng yêu cầu một số trạng thái Ẩn và /hoặc logic là cần thiết để hoạt động đúng. Trạng thái riêng tư được chia sẻ là tập hợp con trong đó nhiều bên thực hiện tính toán trên cùng một trạng thái riêng tư. Mặc dù chúng tôi có thể tin tưởng một bên tập trung sẽ làm việc đó cho chúng tôi và để nó ở đó, nhưng lý tưởng nhất là chúng tôi muốn thực hiện việc đó theo cách giảm thiểu sự tin cậy để tránh một điểm thất bại duy nhất. Chỉ riêng bằng chứng không kiến thức (ZKP) không thể đạt được điều này - chúng ta cần tận dụng các công cụ khác như Môi trường thực thi đáng tin cậy (TEE), Mã hóa hoàn toàn đồng hình (FHE) và/hoặc Tính toán nhiều bên (MPC).
Bộ mặt nạ lớn hơn sẽ tối đa hóa quyền riêng tư: hầu hết thông tin sẽ bị chặn khi vào hoặc ra khỏi bộ mặt nạ, vì vậy chúng ta nên thử để giảm thiểu điều này. Xây dựng nhiều ứng dụng riêng tư trên cùng một blockchain có thể giúp tăng cường đảm bảo quyền riêng tư bằng cách tăng số lượng người dùng và giao dịch trong cùng một nhóm được bảo vệ.
Sự kết thúc của cơ sở hạ tầng quyền riêng tư
Xem xét những điều trên Theo giả thuyết, mục tiêu cuối cùng của cơ sở hạ tầng quyền riêng tư blockchain là gì? Có cách tiếp cận nào phù hợp cho tất cả không? Có công nghệ nâng cao quyền riêng tư nào sẽ thống trị tất cả các ứng dụng không?
Không chính xác. Tất cả những thứ này đều có sự đánh đổi khác nhau và chúng tôi đã thấy chúng được kết hợp theo nhiều cách khác nhau. Nhìn chung, chúng tôi đã xác định được 11 cách tiếp cận khác nhau.
Hiện tại, hai phương pháp phổ biến nhất để xây dựng cơ sở hạ tầng quyền riêng tư trong chuỗi khối là tận dụng ZKP hoặc FHE. Tuy nhiên, cả hai đều có những sai sót cơ bản:
Dựa trên ZK với quyền riêng tư được chứng thực phía khách hàng Giao thức có thể cung cấp sự đảm bảo mạnh mẽ về quyền riêng tư nhưng không cho phép nhiều bên tính toán cùng một trạng thái riêng tư. Điều này hạn chế khả năng diễn đạt, tức là những loại ứng dụng mà nhà phát triển có thể xây dựng.
FHE hỗ trợ tính toán trên dữ liệu được mã hóa và trạng thái riêng tư được chia sẻ, nhưng đặt ra câu hỏi ai sở hữu Câu hỏi của trạng thái này là ai có khóa giải mã. Điều này hạn chế sức mạnh của việc đảm bảo quyền riêng tư và mức độ mà chúng ta có thể tin tưởng rằng quyền riêng tư hôm nay sẽ vẫn như vậy vào ngày mai.
Nếu trạng thái cuối lý tưởng là có cơ sở hạ tầng bảo mật có thể lập trình có thể xử lý trạng thái riêng tư được chia sẻmà không cần Nếu có bất kỳ điểm lỗi nào thì hai đường dẫn có thể dẫn đến MPC:
p>
Lưu ý rằng mặc dù hai cách tiếp cận cuối cùng sẽ hội tụ nhưng MPC phục vụ một mục đích khác:
-
Mạng ZKP: MPC tăng khả năng biểu đạt bằng cách triển khai tính toán các trạng thái riêng tư được chia sẻ.
Mạng FHE: MPC cải thiện tính bảo mật bằng cách phân phối khóa giải mã cho ủy ban MPC thay vì một bên thứ ba
Mặc dù cuộc thảo luận đang bắt đầu chuyển sang một quan điểm đa sắc thái hơn nhưng những đảm bảo đằng sau những cách tiếp cận khác nhau này vẫn chưa được khám phá. Vì các giả định về độ tin cậy của chúng tôi giống với MPC, nên có ba câu hỏi chính cần đặt ra là:
Sự đảm bảo quyền riêng tư mà giao thức MPC có thể cung cấp trong blockchain mạnh đến mức nào?
Công nghệ đã đủ trưởng thành chưa? Nếu không thì nút cổ chai là gì?
Với sức mạnh của sự đảm bảo và chi phí mà nó đưa ra, liệu nó có hợp lý so với các phương pháp khác không?
Hãy trả lời những câu hỏi này một cách chi tiết hơn.
Sử dụng MPC để phân tích rủi ro và điểm yếu
Bất cứ khi nào giải pháp sử dụng FHE, mọi người luôn Một cần hỏi: "Ai có chìa khóa giải mã?". Nếu câu trả lời là "mạng", thì câu hỏi tiếp theo là: "Những thực thể thực sự nào tạo nên mạng này?". Vấn đề thứ hai liên quan đến tất cả các trường hợp sử dụng dựa vào MPC dưới một số hình thức.
Nguồn: Zama tại Speech tại ETH CC
Rủi ro chính của MPC là thông đồng, tức là có đủ các bên thông đồng ác ý để giải mã dữ liệu hoặc đánh cắp các phép tính. Sự thông đồng có thể được thỏa thuận ngoài chuỗi và chỉ bị tiết lộ khi một bên độc hại thực hiện một số hành động rõ ràng (tống tiền, đúc mã thông báo ngoài luồng, v.v.). Không cần phải nói, điều này có ý nghĩa quan trọng đối với sự đảm bảo quyền riêng tư mà hệ thống có thể cung cấp. Nguy cơ thông đồng phụ thuộc vào:
Giao thức có thể chịu được bao nhiêu bên độc hại?
Mạng bao gồm những bên nào? Họ đáng tin đến mức nào?
Số lượng các bên khác nhau tham gia vào mạng và sự phân bổ của họ - có các vectơ tấn công phổ biến không?
Mạng có được phép hay không được phép (lợi ích kinh tế và danh tiếng/cơ sở pháp lý)?
Các hình phạt dành cho hành vi nguy hiểm là gì? Trò chơi thông đồng có phải là kết quả tối ưu về mặt lý thuyết không?
1. Sự đảm bảo quyền riêng tư mà giao thức MPC có thể cung cấp trong blockchain mạnh đến mức nào?
TLDR: Không mạnh như chúng tôi mong muốn, nhưng mạnh hơn việc dựa vào bên thứ ba tập trung.
Ngưỡng cần thiết để giải mã phụ thuộc vào sơ đồ MPC đã chọn - phần lớn là độ sống động("phân phối đầu ra được đảm bảo")< sự cân bằng giữa /em > và an ninh. Bạn có thể có sơ đồ N/N rất an toàn, nhưng nó sẽ bị lỗi ngay khi một nút ngoại tuyến. Mặt khác, sơ đồ N/2 hoặc N/3 mạnh mẽ hơn nhưng có nguy cơ thông đồng cao hơn.
Hai điều kiện cần cân bằng là:
Thông tin bí mật không bao giờ được tiết lộ (chẳng hạn như khóa giải mã)
Thông tin bí mật không bao giờ được tiết lộ tiết lộ Biến mất (ngay cả khi 1/3 số người tham gia đột ngột rời đi).
Các tùy chọn được chọn sẽ khác nhau tùy theo cách triển khai. Ví dụ: Zama nhắm mục tiêu N/3, trong khi Arcium hiện đang triển khai sơ đồ N/N, nhưng sau này sẽ hỗ trợ các sơ đồ có đảm bảo về độ sống cao hơn (và các giả định về độ tin cậy cao hơn).
Tại ranh giới đánh đổi này, một sự thỏa hiệp là áp dụng một giải pháp kết hợp:
Ủy ban có độ tin cậy cao thực hiện xử lý khóa với ngưỡng N/3 chẳng hạn.
Ban tính toán đang luân phiên, ví dụ có ngưỡng N-1 (hoặc bội số với đặc điểm khác nhau của các ủy ban tính toán khác nhau để người dùng lựa chọn).
Mặc dù điều này hấp dẫn về mặt lý thuyết nhưng nó cũng gây ra những phức tạp bổ sung như ủy ban tính toán Cách tương tác với độ tin cậy cao các ủy ban.
Một cách khác để tăng cường bảo mật là chạy MPC trong phần cứng đáng tin cậy để việc chia sẻ khóa được lưu giữ trong một vùng an toàn. Điều này khiến việc trích xuất hoặc sử dụng tính năng chia sẻ khóa cho bất kỳ mục đích nào khác ngoài những gì giao thức xác định trở nên khó khăn hơn. Ít nhất Zama và Arcium đang khám phá góc độ TEE.
Rủi ro tinh vi hơn bao gồm các trường hợp khó khăn như kỹ thuật xã hội, ví dụ: tất cả các công ty trong cụm MPC đều tuyển dụng một kỹ sư cấp cao từ 10 đến 15 tuổi.
2. Công nghệ có đủ trưởng thành không? Nếu chưa đủ trưởng thành thì nút thắt là gì?
Từ góc độ hiệu suất, thách thức chính đối với MPC là chi phí liên lạc. Nó phát triển theo độ phức tạp của tính toán và số lượng nút trong mạng (đòi hỏi nhiều giao tiếp qua lại hơn). Đối với các trường hợp sử dụng blockchain, điều này có hai ý nghĩa thực tế:
Bộ toán tử nhỏ: Để duy trì liên lạc có thể kiểm soát được chi phí, hầu hết các giao thức hiện có hiện bị giới hạn ở các bộ toán tử nhỏ. Ví dụ: mạng giải mã của Zama hiện cho phép tối đa 4 nút (mặc dù họ có kế hoạch mở rộng lên 16 nút). Theo điểm chuẩn ban đầu do Zama công bố cho mạng giải mã (TKMS) của mình, ngay cả với cụm chỉ có 4 nút, quá trình giải mã cũng mất 0,5-1 giây (quá trình e2e đầy đủ mất nhiều thời gian hơn). Một ví dụ khác là việc Taceo triển khai MPC cho cơ sở dữ liệu mống mắt của Worldcoin, có 3 bên (giả sử 2/3 bên trung thực).
Nguồn: Zama trên các bài giảng ETH trên CC
Bộ toán tử được phép: Trong hầu hết các trường hợp, bộ toán tử được cho phép. Điều này có nghĩa là chúng tôi dựa vào danh tiếng và hợp đồng pháp lý hơn là bảo mật kinh tế hoặc mật mã. Thách thức chính với các bộ toán tử không được phép là không thể biết liệu mọi người có thông đồng ngoài chuỗi hay không. Ngoài ra, nó yêu cầu khởi động định kỳ hoặc phân phối lại các chia sẻ chính để các nút có thể tự động vào/ra mạng. Mặc dù bộ toán tử không được phép là mục tiêu cuối cùng và nghiên cứu đang được tiến hành về cách mở rộng cơ chế PoS để đạt được ngưỡng MPC (ví dụ: Zama), nhưng lộ trình được phép dường như là cách tốt nhất hiện nay.
Các lựa chọn thay thế
Danh mục quyền riêng tư toàn diện bao gồm: < /p>
FHE được sử dụng để ủy quyền tính toán quyền riêng tư
- < p style="text-align: left;">ZKP được sử dụng để xác minh xem phép tính FHE có được thực hiện chính xác hay không
Được sử dụng cho MPC giải mã ngưỡng
Mỗi nút MPC chạy trong TEE để tăng cường bảo mật
< p style="text-align:center">
Điều này phức tạp, giới thiệu nhiều trường hợp góc chưa được khám phá, đắt tiền và Điều này có thể không thực tế trong nhiều năm tới. Một rủi ro khác là mọi người có thể bị ru ngủ vào cảm giác an toàn sai lầm bằng cách xếp chồng nhiều khái niệm phức tạp lên nhau. Chúng ta càng thêm các giả định phức tạp và tin cậy thì việc suy ra tính bảo mật của giải pháp tổng thể càng trở nên khó khăn hơn.
Có đáng không? Nó có thể đáng giá, nhưng cũng đáng khám phá những cách tiếp cận khác có thể mang lại hiệu quả tính toán tốt hơn đáng kể nhưng chỉ đảm bảo quyền riêng tư yếu hơn một chút. Như Lyron của Seismic đã chỉ ra - chúng ta nên tập trung vào các giải pháp đơn giản nhất đáp ứng các tiêu chuẩn của chúng ta về mức độ riêng tư mong muốn và những đánh đổi có thể chấp nhận được, thay vì kỹ thuật quá mức chỉ vì lợi ích của nó.
1. Sử dụng trực tiếp MPC để tính toán chung
Nếu cuối cùng ZK và FHE trở về MPC giả định về độ tin cậy, tại sao không sử dụng MPC để tính toán? Đó là một câu hỏi chính đáng và đó là điều mà các nhóm như Arcium, SodaLabs (được sử dụng trong Coti v2), Taceo và Nillion đang cố gắng thực hiện. Lưu ý rằng MPC có nhiều dạng, nhưng trong ba cách tiếp cận chính, ở đây chúng tôi đề cập đến các giao thức dựa trên Chia sẻ bí mật và Mạch bị cắt xén (GC) thay vì giao thức dựa trên FHE sử dụng MPC để giải mã.
Mặc dù MPC đã được sử dụng cho các tính toán đơn giản như chữ ký phân tán và ví an toàn hơn, thách thức chính của việc sử dụng MPC cho các tính toán tổng quát hơn là chi phí liên lạc (tăng theo độ phức tạp của phép tính và số lượng nút liên quan).
Có nhiều cách để giảm chi phí, chẳng hạn như tiền xử lý (tức là phần đắt nhất của giao thức) ngoại tuyến trước - cả Arcium và SodaLabs đều đang khám phá điều này một chút . Sau đó, quá trình tính toán được thực hiện trong giai đoạn trực tuyến, tiêu tốn một số dữ liệu được tạo ra trong giai đoạn ngoại tuyến. Điều này làm giảm đáng kể chi phí liên lạc tổng thể.
Bảng bên dưới của SodaLabs hiển thị điểm chuẩn ban đầu(tính bằng micro giây) về thời gian cần thiết để thực thi các opcode khác nhau 1.000 lần trong gcEVM của chúng. Mặc dù đây là một bước đi đúng hướng nhưng vẫn còn rất nhiều việc phải làm để nâng cao hiệu quả và mở rộng bộ toán tử ra ngoài một vài nút.
Nguồn: SodaLabs
< p style="text-align: left;">Lợi ích của cách tiếp cận dựa trên ZK là bạn chỉ sử dụng MPC cho các trường hợp sử dụng yêu cầu tính toán ở trạng thái riêng tư được chia sẻ. FHE cạnh tranh trực tiếp hơn với MPC và phụ thuộc nhiều vào khả năng tăng tốc phần cứng.
2. Môi trường thực thi đáng tin cậy
Gần đây, mối quan tâm của mọi người đối với TEE đã được hồi sinh. bật lên, nó có thể được sử dụng một mình (blockchain riêng tư hoặc bộ đồng xử lý dựa trên TEE) hoặc kết hợp với các PET khác (chẳng hạn như các giải pháp dựa trên ZK) (chỉ sử dụng TEE để tính toán trạng thái riêng tư được chia sẻ).
Mặc dù TEE đã trưởng thành hơn ở một số khía cạnh và có ít chi phí hoạt động hơn nhưng chúng không phải là không có nhược điểm. Đầu tiên, TEE có các giả định tin cậy khác nhau (1/N) và cung cấp các giải pháp dựa trên phần cứng thay vì dựa trên phần mềm. Người ta thường nghe thấy những lời chỉ trích xung quanh các lỗ hổng trong quá khứ của SGX, nhưng điều đáng chú ý là TEE ≠ Intel SGX. TEE cũng yêu cầu sự tin tưởng vào nhà cung cấp phần cứng, điều này rất tốn kém (và nằm ngoài tầm với của hầu hết mọi người). Một giải pháp để giải quyết nguy cơ bị tấn công vật lý có thể là vận hành TEE trong không gian để xử lý các nhiệm vụ quan trọng.
Nhìn chung, TEE có vẻ phù hợp hơn với các bằng chứng hoặc trường hợp sử dụng chỉ yêu cầu quyền riêng tư ngắn hạn (giải mã ngưỡng, sổ cái đĩa đen, v.v.). Đối với quyền riêng tư lâu dài hoặc lâu dài, các đảm bảo về an ninh có vẻ kém hấp dẫn hơn.
3. DAC riêng tư và các phương pháp khác dựa vào bên thứ ba đáng tin cậy để bảo vệ quyền riêng tư
Quyền riêng tư của Người trung gian có thể cung cấp quyền riêng tư để người dùng khác không thể truy cập, nhưng việc đảm bảo quyền riêng tư hoàn toàn xuất phát từ sự tin tưởng vào bên thứ ba (điểm lỗi duy nhất). Mặc dù nó tương tự như "quyền riêng tư của web2" (ngăn chặn quyền riêng tư của người dùng khác), nhưng nó có thể được tăng cường bằng các đảm bảo bổ sung (mật mã hoặc kinh tế) và cho phép thực hiện xác minh một cách chính xác.
Ủy ban sẵn có dữ liệu riêng tư (DAC) là một ví dụ; các thành viên của DAC lưu trữ dữ liệu ngoài chuỗi và người dùng tin tưởng họ lưu trữ dữ liệu một cách chính xác và thực hiện trạng thái cập nhật chuyển tiếp. Một dạng khác là trình sắp xếp trình tự được cấp phép do Tom Walpo đề xuất.
Mặc dù phương pháp này tạo ra sự đánh đổi đáng kể về mặt đảm bảo quyền riêng tư, nhưng về mặt chi phí và hiệu suất, nó có thể là lựa chọn tối ưu cho giá trị thấp, hiệu suất cao Giải pháp thay thế khả thi duy nhất (ít nhất là ở thời điểm hiện tại) là các ứng dụng. Ví dụ: Lens Protocol có kế hoạch sử dụng các DAC riêng tư để kích hoạt luồng thông tin riêng tư. Đối với các trường hợp sử dụng như mạng xã hội trên chuỗi, sự đánh đổi giữa quyền riêng tư và chi phí/hiệu suất hiện có thể hợp lý (với chi phí và chi phí chung của các lựa chọn thay thế).
4. Địa chỉ ẩn
Địa chỉ ẩn có thể cung cấp và tạo địa chỉ mới cho mỗi giao dịch Đảm bảo quyền riêng tư tương tự, nhưng quy trình này được tự động hóa ở phần phụ trợ và ẩn khỏi người dùng. Để biết thêm thông tin, hãy xem phần tổng quan này từ Vitalik hoặc bài viết này đi sâu vào các phương pháp tiếp cận khác nhau. Những người chơi chính trong không gian này bao gồm Umbra và Fluidkey.
Mặc dù các địa chỉ ẩn cung cấp một giải pháp tương đối đơn giản nhưng nhược điểm chính là chúng chỉ có thể thêm đảm bảo quyền riêng tư cho các giao dịch (thanh toán và chuyển khoản) chứ không thể thêm đảm bảo quyền riêng tư cho tính toán mục đích chung. Điều này làm cho chúng khác biệt với ba giải pháp còn lại được đề cập ở trên.
Ngoài ra, các đảm bảo về quyền riêng tư do địa chỉ ẩn cung cấp không mạnh bằng các lựa chọn thay thế khác. Tính ẩn danh có thể bị phá vỡ thông qua phân tích cụm đơn giản, đặc biệt khi các giao dịch chuyển tiền đến và đi không nằm trong phạm vi giống nhau (ví dụ: nhận được 10.000 USD nhưng giao dịch hàng ngày có chi phí trung bình là 10-100 USD). Một thách thức khác với địa chỉ ẩn là nâng cấp khóa, ngày nay cần phải nâng cấp riêng cho từng ví (việc tổng hợp lưu trữ khóa có thể giúp giải quyết vấn đề này). Từ góc độ trải nghiệm người dùng, nếu tài khoản không có mã thông báo phí (chẳng hạn như ETH), giao thức địa chỉ ẩn cũng yêu cầu trừu tượng hóa tài khoản hoặc người trả phí để trả phí.
Rủi ro đối với lập luận của chúng tôi
Với tốc độ phát triển nhanh chóng và các giải pháp công nghệ khác nhau Trong bối cảnh không chắc chắn chung, có một số rủi ro đối với lập luận của chúng tôi rằng MPC sẽ là giải pháp cuối cùng. Cuối cùng, chúng tôi có thể không cần một số dạng MPC vì những lý do chính sau:
Được chia sẻ riêng tư state Không quan trọng như chúng tôi nghĩ: Cơ sở hạ tầng dựa trên ZK có nhiều khả năng thắng hơn trong trường hợp này vì nó có những đảm bảo về quyền riêng tư mạnh mẽ hơn và chi phí thấp hơn FHE. Đã có một số trường hợp sử dụng trong đó các hệ thống dựa trên ZK hoạt động tốt trong các trường hợp sử dụng riêng biệt, chẳng hạn như giao thức thanh toán riêng Payy.
Sự đánh đổi hiệu suất không xứng đáng với lợi ích về quyền riêng tư: người ta có thể nói rằng một mạng MPC có 2-3 người được cấp phép Sự tin tưởng các giả định không khác nhiều so với một tác nhân tập trung duy nhất và sự gia tăng đáng kể về chi phí/chi phí chung là không đáng có. Điều này có thể đúng với nhiều ứng dụng, đặc biệt là các ứng dụng có giá trị thấp, nhạy cảm với chi phí như mạng xã hội hoặc trò chơi. Tuy nhiên, cũng có nhiều trường hợp sử dụng có giá trị cao mà việc cộng tác hiện cực kỳ tốn kém (hoặc không thể thực hiện được) do các vấn đề pháp lý hoặc xung đột phối hợp cao. Sau này là nơi các giải pháp dựa trên MPC và FHE có thể tỏa sáng.
Chuyên môn hóa lấn át thiết kế phổ quát: Xây dựng chuỗi mới và khởi động cộng đồng người dùng và nhà phát triển là điều khó khăn. Do đó, cơ sở hạ tầng bảo mật chung (L1/L2) có thể gặp khó khăn trong việc thu hút sự chú ý. Một vấn đề khác liên quan đến sự chuyên môn hóa; rất khó để một thiết kế giao thức duy nhất có thể bao quát toàn bộ không gian cân bằng. Trong thế giới này, các giải pháp cung cấp quyền riêng tư cho các hệ sinh thái hiện có (bảo mật dưới dạng dịch vụ) hoặc các trường hợp sử dụng chuyên biệt (chẳng hạn như thanh toán) sẽ chiếm ưu thế. Tuy nhiên, chúng tôi nghi ngờ về điều thứ hai, vì nó gây ra sự phức tạp cho các nhà phát triển ứng dụng, những người cần tự mình triển khai một số mật mã (thay vì trừu tượng hóa nó).
Quy định tiếp tục cản trở việc thử nghiệm các giải pháp bảo mật: đối với bất kỳ ai xây dựng cơ sở hạ tầng và ứng dụng bảo mật với một số đảm bảo về quyền riêng tư. Đối với tôi, đây là một rủi ro. Các trường hợp sử dụng phi tài chính gặp ít rủi ro pháp lý hơn nhưng rất khó (không thể) kiểm soát những gì được xây dựng trên cơ sở hạ tầng bảo mật không được phép. Rất có thể chúng tôi sẽ giải quyết các vấn đề kỹ thuật trước khi giải quyết các vấn đề pháp lý.
Chi phí hoạt động của các giải pháp dựa trên MPC và FHE vẫn còn quá cao đối với hầu hết các trường hợp sử dụng: mặc dù MPC chủ yếu bị hạn chế bởi giao tiếp tác động từ phía trên, nhưng nhóm FHE chủ yếu dựa vào khả năng tăng tốc phần cứng để cải thiện hiệu suất. Nhưng nếu chúng tôi có thể ngoại suy quá trình phát triển phần cứng chuyên dụng về phía ZK, thì sẽ mất nhiều thời gian hơn hầu hết mọi người nghĩ trước khi chúng tôi có được phần cứng FHE sẵn sàng sản xuất. Các nhóm nghiên cứu khả năng tăng tốc phần cứng của FHE bao gồm Optalysys, fhela và Niobium.
Tóm tắt
Trong phân tích cuối cùng , chuỗi Nó chỉ mạnh bằng mắt xích yếu nhất của nó. Trong trường hợp cơ sở hạ tầng bảo mật có thể lập trình, nếuchúng tôi muốn nó có thể xử lý trạng thái riêng tư được chia sẻ mà không có một điểm lỗi nào thì sự đảm bảo tin cậy sẽ tập trung vào sự đảm bảo của MPC.
Mặc dù bài viết này nghe có vẻ chỉ trích MPC nhưng thực tế không phải vậy. MPC cải thiện đáng kể tình trạng phụ thuộc vào bên thứ ba tập trung hiện nay. Chúng tôi tin rằng vấn đề chính là sự tin tưởng sai lầm trong toàn ngành và vấn đề đang được che đậy. Thay vào đó, chúng ta nên đối mặt trực tiếp với vấn đề và tập trung đánh giá những rủi ro tiềm ẩn.
Tuy nhiên, không phải mọi vấn đề đều yêu cầu những công cụ giống nhau để giải quyết. Mặc dù chúng tôi coi MPC là mục tiêu cuối cùng, nhưng các phương pháp tiếp cận khác vẫn là những lựa chọn khả thi miễn là chi phí chung của các giải pháp do MPC điều khiển vẫn ở mức cao. Luôn luôn đáng để xem xét cách tiếp cận nào phù hợp nhất với nhu cầu/đặc điểm cụ thể của vấn đề mà chúng ta đang cố gắng giải quyết và những đánh đổi mà chúng ta sẵn sàng thực hiện.
Ngay cả khi bạn có chiếc búa tốt nhất thế giới thì không phải mọi thứ đều là đinh.