Phần 1 của loạt bài về riêng tư của chúng tôi Bao gồm những gì "quyền riêng tư" đòi hỏi, quyền riêng tư trong các mạng blockchain khác với quyền riêng tư của Web2 như thế nào và tại sao nó khó đạt được trong blockchain.

Điểm chính của bài viết này là nếu trạng thái cuối cùng mong muốn là có cơ sở hạ tầng riêng tư có thể lập trình được có thể xử lý trạng thái riêng tư chia sẻ mà không có bất kỳ điểm thất bại đơn nào, thì tất cả các con đường đều dẫn đến MPC. Chúng tôi cũng khám phá tính chín muồi của MPC và giả định tin cậy của nó, nhấn mạnh các phương pháp thay thế, so sánh các sự đánh đổi và cung cấp một cái nhìn tổng quan về ngành công nghiệp.

Chúng ta có đang xây dựng cùng một thứ không? Tiếp tục đọc để tìm hiểu.

Cảm ơn vì Avishay (SodaLabs), Lukas (Taceo), Michael (Cân bằng) và Nico ( Arcium) cho những cuộc thảo luận đã giúp định hình bài đăng này.

Gì có thể, không gánh bởi những gì đã qua

Cơ sở hạ tầng bảo mật hiện tại trong các chuỗi khối đượ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. Điều này là quan điểm khá hẹp và chủ yếu phản ánh những gì mà các chuỗi khối hiện đang được sử dụng (giao dịch, chuyển khoản và đầu cơ). Tom Walpo đã nói - Crypto gặp phải nghịch lý Fermi:

Ngoài việc tăng cường tự do cá nhân, chúng tôi tin rằng quyền riêng tư là một tiền đề để mở rộng không gian thiết kế của các chuỗi khối vượt ra khỏi quảng cáo hiện tại. Nhiều ứng dụng đòi hỏi một số trạng thái riêng tư và/hoặc logic ẩn để hoạt động đúng cách:

• Trạng thái ẩn: Hầu hết các trường hợp sử dụng tài chính yêu cầu (ít nhất) quyền riêng tư khỏi người dùng khác và nhiều trò chơi nhiều người chơi trở nên ít thú vị hơn khi không có một số trạng thái ẩn (ví dụ: nếu mọi người tại bàn poker đều nhìn thấy nhau bài của nhau).
• Logic ẩn: Một số trường hợp sử dụng yêu cầu ẩn đi một số logic trong khi vẫn cho phép những người khác sử dụng ứng dụng, chẳng hạn như một bộ khớp lệnh, chiến lược giao dịch trên chuỗi, vv.

Phân tích kinh nghiệm (từ cả web2 và web3) cho thấy hầu hết người dùng không sẵn lòng trả thêm hoặc vượt qua các rắc rối bổ sung để có thêm tính riêng tư, và chúng tôi đồng ý rằng tính riêng tư không phải là điểm bán hàng mạnh mẽ. Tuy nhiên, nó cho phép các trường hợp sử dụng mới và (hy vọng) ý nghĩa hơn tồn tại trên các nền tảng blockchain - cho phép chúng ta thoát khỏi Nghịch lý Fermi.

Công nghệ tăng cường quyền riêng tư (PETs) và các giải pháp mật mã hiện đại (“mã hóa có thể lập trình“) là những khối xây dựng cơ bản để thực hiện tầm nhìn này (xem phụ lụcđể biết thêm thông tin về các giải pháp khác nhau có sẵn và các sự đánh đổi của chúng).

Ba Giả Thuyết Hình Thành Quan Điểm Của Chúng Ta

Ba giả thuyết chính hình thành quan điểm của chúng tôi về cách chúng tôi tin rằng cơ sở hạ tầng bảo mật riêng tư trên blockchain có thể phát triển:

1. Mật mã sẽ được trừu tượng hóa khỏi các nhà phát triển ứng dụng: Hầu hết các nhà phát triển ứng dụng không muốn (hoặc biết cách) xử lý mật mã cần thiết cho quyền riêng tư. Thật vô lý khi mong đợi họ triển khai mật mã của riêng họ và xây dựng các chuỗi ứng dụng riêng tư (ví dụ: ZcashhoặcNamada) hoặc các ứng dụng riêng tư trên đầu chuỗi công khai (ví dụ: Tornado Cash). Điều này chỉ đơn giản là quá phức tạp và chi phí, hiện đang hạn chế không gian thiết kế cho hầu hết các nhà phát triển (không thể xây dựng các ứng dụng yêu cầu một số đảm bảo 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ật mã phải được trừu tượng hóa khỏi 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 được chia sẻ) hoặc "bảo mật như một dịch vụ" cho phép thuê ngoài tính toán bí mật.
2. Nhiều trường hợp sử dụng (có thể nhiều hơn chúng ta 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 để hoạt động đúng. Nhà nước riêng được chia sẻ là một tập hợp con của điều này, trong đó nhiều bên tính toán trên cùng một phần của nhà nước tư nhân. Mặc dù chúng ta có thể tin tưởng một đảng tập trung làm điều đó cho chúng ta và gọi đó là một ngày, nhưng lý tưởng nhất là chúng ta muốn làm điều đó theo cách giảm thiểu sự tin tưởng để tránh những điểm thất bại đơn lẻ. Không có bằng chứng kiến thức (ZKP) một mình không thể đạt được điều này - chúng ta cần tận dụng các công cụ bổ sung như môi trường thực thi đáng tin cậy (TEE), mã hóa đồng cấu hoàn toàn (FHE) và / hoặc tính toán đa bên (MPC).
3. Các bộ lớn được che đậy tối đa hóa quyền riêng tư: Hầu hết thông tin được tiết lộ khi đang nhập hoặc thoát Bộ được che chắn, vì vậy chúng ta nên cố gắng giảm thiểu điều đó. Có nhiều ứng dụng riêng tư được xây dựng 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 tập hợp được bảo vệ.

Cuộc chơi cuối cùng của Cơ sở hạ tầng Quyền riêng tư

Với các giả thuyết trên, mục tiêu cuối cùng cho cơ sở hạ tầng bảo mật trong các chuỗi khối là gì? Có một phương pháp nào phù hợp cho mọi ứng dụng không? Một công nghệ nâng cao quyền riêng tư để chi phối tất cả?

Không hoàn toàn đúng. Tất cả những phương pháp này đều có những ưu điểm và nhược điểm khác nhau và chúng ta đã thấy chúng được kết hợp với nhau theo nhiều cách khác nhau. Tổng cộng, chúng tôi đã xác định được 11 phương pháp khác nhau (xem phụ lục.

Hiện nay, hai phương pháp phổ biến nhất để xây dựng cơ sở hạ tầng bảo mật trong các chuỗi khối là sử dụng ZKPs hoặc FHE. Tuy nhiên, cả hai đều có nhược điểm cơ bản:

• Các giao thức bảo mật dựa trên ZK với chứng minh phía máy khách có thể cung cấp các cam kết bảo mật mạnh mẽ nhưng không cho phép nhiều bên tính toán trên cùng trạng thái riêng tư. Điều này hạn chế tính biểu đạt, tức là loại ứng dụng mà nhà phát triển có thể xây dựng.
• FHE cho phép 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 về người sở hữu trạng thái đó, tức là ai giữ khóa giải mã. Điều này giới hạn sức mạnh của các cam kết bảo mật và mức độ chúng ta có thể tin tưởng rằng những điều riêng tư hôm nay vẫn thế ngày mai.

Nếu trạng thái kết thúc mong muốn là có cơ sở hạ tầng riêng tư có thể lập trình được có thể xử lý trạng thái riêng tư chia sẻ mà không có bất kỳ điểm hỏng lòi nào, thì cả hai con đường đều dẫn đến MPC:

Lưu ý rằng dù hai phương pháp này cuối cùng đều hội tụ, MPC được sử dụng cho các mục đích khác nhau:

• Mạng lưới ZKP: MPC được sử dụng để thêm tính biểu đạt bằng cách cho phép tính toán trên trạng thái riêng được chia sẻ.
• Mạng FHE: MPC được sử dụng để tăng cường bảo mật và đảm bảo quyền riêng tư bằng cách phân phối khóa giải mã cho một ủy ban MPC (thay vì một bên thứ ba đơn lẻ).

Trong khi cuộc thảo luận đang bắt đầu chuyển sang một quan điểm nhiều sắc thái hơn, 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á. Cho rằng các giả định tin tưởng của chúng tôi sôi sục với các giả định của MPC, ba câu hỏi chính cần đặt ra là:

1. MPC là gì?
2. Công nghệ đã đủ chín chắn chưa? Nếu chưa, những rào cản là gì?
3. Với sức mạnh của các cam kết và sự lạc hậu mà nó mang lại, liệu nó có ý nghĩa so với các phương pháp thay thế không?

Hãy giải quyết những câu hỏi này một cách chi tiết hơn.

Phân tích Rủi ro và Điểm yếu với MPC

Khi một giải pháp sử dụng FHE, luôn cần hỏi: “Ai giữ chìa khóa giải mã?”. Nếu câu trả lời là “mạng”, câu hỏi tiếp theo là: “Các thực thể thực tế nào tạo thành mạng này?”. Câu hỏi sau liên quan đến tất cả các trường hợp sử dụng MPC theo một hình thức nào đó.

Nguồn:Bài phát biểu của Zama tại ETH CC

Rủi ro chính với MPC là thông đồng, tức là đủ các bên hành động độc hại và thông đồng để giải mã dữ liệu hoặc tính toán sai. Thông đồng có thể được thỏa thuận ngoài chuỗi và chỉ được tiết lộ nếu các bên độc hại làm điều gì đó rõ ràng (tống tiền, đúc mã thông báo từ không khí, v.v.). Không cần phải nói, điều này có ý nghĩa quan trọng đối với các đảm bảo quyền riêng tư mà hệ thống có thể cung cấp. Rủi ro thông đồng phụ thuộc vào:

• Ngưỡng nguy hiểm của bên ác ý mà giao thức có thể chịu được là bao nhiêu?
• Các bên nào cấu thành mạng lưới và mức độ đáng tin cậy của họ như thế nào?
• Số lượng các bên khác nhau tham gia vào mạng và phân phối của chúng - Có bất kỳ vector tấn công chung nào không?
• Mạng có phải là mạng không cần sự cho phép hay cần sự cho phép (có căn cứ kinh tế hoặc uy tín/pháp lý)?
• Hình phạt cho hành vi độc hại là gì? Liên kết trò chơi có phải là kết quả tối ưu lý thuyết không?

1. Mức độ bảo mật mạnh mẽ mà các giao thức MPC có thể cung cấp trong các blockchain là bao nhiêu?

Tóm lại: Không mạnh như chúng tôi muốn, nhưng mạnh hơn việc chỉ tin cậy vào một bên thứ ba trung gian tập trung duy nhất.

Ngưỡng yêu cầu để giải mã phụ thuộc vào lựa chọn MPC - chủ yếu là sự cân đối giữa tính sống còn ("đảm bảo việc giao hàng đầu ra") và tính bảo mật. Bạn có thể có một chương trình N/N rất an toàn nhưng sẽ phá vỡ nếu chỉ có một nút bị ngắt kết nối. Trên một phía khác, các chương trình N/2 hoặc N/3 có tính ổn định cao hơn nhưng có nguy cơ va chạm cao hơn.

Hai điều kiện cần cân nhắc là:

1. Thông tin bí mật không bao giờ bị rò rỉ (ví dụ: khóa giải mã)
2. Thông tin bí mật không bao giờ biến mất (ngay cả khi 1/3 các bên đột ngột rời đi).

Lược đồ được chọn thay đổi tùy thuộc vào cài đặt. Ví dụ, Zama đang nhắm tới N/3, trong khi Arcium hiện đang triển khai một Chương trình N/Nnhưng sau này cũng nhằm mục tiêu hỗ trợ các giải pháp có độ tin cậy cao hơn (và giả định tin tưởng lớn hơn).

Một sự thoả hiệp dọc theo biên giới trao đổi này có thể là một giải pháp kết hợp:

• Ủy ban tin cậy cao, xử lý các khóa với ngưỡng N/3 ví dụ như.
• Các ủy ban tính toán có tính xoay vòng và có ngưỡng N-1 (hoặc nhiều ủy ban tính toán khác nhau với các đặc tính khác nhau để người dùng lựa chọn).

Mặc dù điều này hấp dẫn trong lý thuyết, nhưng nó cũng đưa vào thêm sự phức tạp bổ sung như làm thế nào ban chấp hành tính toán sẽ tương tác với ban cao cấp.

Một cách khác để tăng cường đảm bảo an ninh là chạy MPC trong phần cứng đáng tin cậy để các cổ phiếu chính được giữ bên trong một vùng an toàn. Điều này làm cho việc trích xuất hoặc sử dụng các chia sẻ khóa cho bất kỳ thứ gì khác ngoài những gì được xác định bởi giao thức trở nên khó khăn hơn. Chí ít Zama và Arciumđang khám phá góc nhìn TEE.

Những rủi ro tinh vi hơn bao gồm các trường hợp biên về như kỹ thuật xã hội, ví dụ như một kỹ sư cấp cao được thuê bởi tất cả các công ty trong cụm MPC trong hơn 10-15 năm.

2. Công nghệ đã đủ chín chắn chưa? Nếu chưa, những vấn đề gì đang gây trở ngại?

Từ một khía cạnh hiệu suất, thách thức chính với MPC là chi phí giao tiếp. Nó tăng lên theo độ phức tạp của tính toán và số lượng nút tham gia mạng (yêu cầu thêm giao tiếp qua lại). Đối với các trường hợp sử dụng blockchain, điều này dẫn đến hai tác động thực tế:

1. Bộ toán tử nhỏ: Để giữ cho chi phí liên lạc có thể quản lý được, 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). Dựa trên các điểm chuẩn ban đầu được Zama công bố cho mạng giải mã của họ (TKMS), phải mất 0,5-1 giây để giải mã ngay cả khi chỉ với một cụm 4 nút (luồng e2e đầy đủ mất nhiều thời gian hơn). Một ví dụ khác là Taceo Thực hiện MPC cho cơ sở dữ liệu iris của Worldcoin, có 3 bên (với giả định bên thứ ba trung thực 2/3).

1. Nguồn: Bài nói chuyện của Zama tại ETH CC
2. Nhóm toán tử được phép: Trong hầu hết các trường hợp, nhóm toán tử được 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 một bộ toán tử không được phép là không có cách nào để biết liệu mọi người có thông đồng ngoài chuỗi hay không. Ngoài ra, nó sẽ yêu cầu khởi động thường xuyên hoặc phân phối lại chia sẻ khóa cho các nút để có thể tự động vào / thoát mạng. Mặc dù các bộ toán tử không cần cấp phép là mục tiêu cuối cùng và đang có nghiên cứu về cách mở rộng cơ chế PoS cho MPC ngưỡng (ví dụ bởi Zama), tuyến đường được phép có vẻ là cách tốt nhất hiện tại.

Phương pháp thay thế

Hỗn hợp bảo mật toàn diện bao gồm:

• FHE cho tính toán riêng tư được ủy quyền
• ZKP để xác minh rằng tính toán FHE đã được thực hiện chính xác
• MPC cho giải mã ngưỡng
• Mỗi nút MPC chạy trong một TEE để tăng cường bảo mật

Điều này phức tạp, giới thiệu rất nhiều trường hợp cạnh không được khám phá, có overhead cao, và có thể không thực tế trong nhiều năm tới. Một rủi ro khác là cảm giác an toàn giả mạo mà người ta có thể nhận được từ việc thêm nhiều khái niệm phức tạp lên trên nhau. Càng phức tạp và giả định về sự tin cậy mà chúng ta thêm vào, việc đánh giá về tính an toàn của giải pháp tổng thể càng trở nên khó khăn.

Có đáng không? Có thể, nhưng cũng đáng khám phá các phương pháp thay thế khác có thể mang lại hiệu suất tính toán tốt hơn đáng kể với chi phí chỉ là đảm bảo quyền riêng tư yếu hơn một chút.Lyron từ SeismicChú ý - chúng ta nên tập trung vào giải pháp đơn giản nhất để đáp ứng tiêu chuẩn về mức độ bảo mật cần thiết và các sự đánh đổi chấp nhận được, thay vì thiết kế quá phức tạp chỉ vì sự hứng thú về công nghệ.

1. Sử dụng MPC trực tiếp cho tính toán chung

Nếu cả ZK và FHE cuối cùng đều dựa trên giả thiết tin cậy của MPC, tại sao không sử dụng MPC trực tiếp cho tính toán? Đây là một câu hỏi hợp lệ và điều mà các nhóm như Gate, Arcium, SodaLabs (sử dụng bởi Coti v2), Taceo, vàNillionđang cố gắng thực hiện. Lưu ý rằng MPC có nhiều hình thức, nhưng trong ba phương pháp chính, chúng tôi đang ám chỉ đến các giao thức dựa trên chia sẻ bí mật và mạch rối (GC), không phải các giao thức dựa trên FHE sử dụng MPC cho việc giải mã.

Trong khi MPC đã được sử dụng cho các tính toán đơn giản như chữ ký phân tán và ví tiền an toàn hơn, thì thách thức chính khi sử dụng MPC cho tính toán tổng quát hơn là chi phí giao tiếp (tăng lên cùng với độ phức tạp của tính toán và số lượng nút tham gia).

Có một số cách để giảm phí quản lý, chẳng hạn như bằng cách thực hiện xử lý trước (tức là các phần đắt đỏ nhất của giao thức) trước và ngoại tuyến - điều gì cả hai ArciumvàSodaLabs đang khám phá. Việc tính toán sau đó được thực hiện trong giai đoạn trực tuyến, tiêu thụ 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í truyền thông tổng thể.

Bảng dưới đây của SodaLabs cho thấy các chỉ số ban đầu về thời gian thực thi các opcode khác nhau 1.000 lần trong gcEVM của họ (được ghi chú bằng micro giây). Mặc dù đây là một bước tiến trong đúng hướng, nhưng còn rất nhiều công việc phải làm để cải thiện hiệu suất và mở rộng bộ toán tử vượt ra ngoài một vài nút.

Nguồn: SodaLabs

Lợi ích của phương pháp 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ên trạng thái riêng chia sẻ. FHE cạnh tranh trực tiếp hơn với MPC và phụ thuộc mạnh vào việc tăng tốc phần cứng.

2. Môi trường thực thi đáng tin cậy

Gần đây đã có một sự quan tâm tái sinh đối với TEEs, có thể được tận dụng hoặc độc lập (blockchain tư nhân dựa trên TEE hoặc bộ vi xử lý cộng tác) hoặc kết hợp với các PEM khác như các giải pháp dựa trên ZK (chỉ sử dụng TEE để tính toán trên trạng thái tư nhân chia sẻ).

Mặc dù TEEs ở một số cách có sự chín chắn hơn và giới thiệu ít chi phí hiệu suất hơn, nhưng chúng không thiếu nhược điểm. Đầu tiên, TEEs có các giả định tin cậy khác nhau (1/N) và cung cấp một giải pháp dựa trên phần cứng thay vì phần mềm. Một lời chỉ trích thường nghe là về quá khứ lỗ hổng của SGX, nhưng điều đáng chú ý là TEE ≠ Intel SGX. TEE cũng yêu cầu tin tưởng nhà cung cấp phần cứng và phần cứng đắt tiền (hầu hết không thể truy cập được). Một giải pháp cho nguy cơ bị tấn công vật lý có thể là: chạy TEE trong không giancho những việc quan trọng đến nhiệm vụ.

Nhìn chung, TEE có vẻ phù hợp hơn cho các trường hợp chứng thực hoặc sử dụng chỉ cần quyền riêng tư ngắn hạn (giải mã ngưỡng, sổ lệnh tối, v.v.). Đối với quyền riêng tư vĩnh viễn hoặc lâu dài, các đảm bảo bảo mật 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 cho quyền riêng tư

Quyền riêng tư trung gian có thể cung cấp quyền riêng tư khỏi người dùng khác nhưng cam kết quyền riêng tư chỉ đến từ việc tin tưởng một bên thứ ba (điểm thất bại duy nhất). Mặc dù nó giống với "quyền riêng tư web2" (quyền riêng tư khỏi người dùng khác), nhưng nó có thể được củng cố với các cam kết bổ sung (mật mã hoặc kinh tế) và cho phép xác minh thực thi chính xác.

Ủy ban khả dụng dữ liệu riêng tư (DAC) là một ví dụ về điều này; 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 đúng cách và thực hiện cập nhật chuyển trạng thái. Một phong cách khác của điều này là Máy phân tích chuỗi được nhượng quyềnđược đề xuất bởi Tom Walpo.

Mặc dù phương pháp này có sự đánh đổi lớn trong việc đảm bảo sự riêng tư, nó có thể là lựa chọn duy nhất khả thi cho các ứng dụng hiệu suất cao, nhỏ giá trị về mặt chi phí và hiệu suất (ít nhất là hiện tại). Một ví dụ là Giao thức ống kính, có kế hoạch sử dụng DAC riêng để đạt được nguồn cấp dữ liệu riêng tư. Đối với các trường hợp sử dụng như xã hội trên chuỗi, sự cân bằng giữa quyền riêng tư và chi phí / hiệu suất có lẽ là hợp lý cho đến bây giờ (với chi phí và chi phí thay thế).

4. Địa chỉ ẩn

Địa chỉ ẩn danh có thể cung cấp các cam kết về quyền riêng tư tương tự như việc tạo một địa chỉ mới cho mỗi giao dịch, nhưng quá trình này được tự động hóa ở phía sau và trừu tượng hoá khỏi người dùng. Để biết thêm thông tin, xem tổng quan bởi Vitalikhoặc điều nàysự nghiên cứu sâu vào các phương pháp khác nhau. Những người chơi chính trong lĩnh vực này bao gồm: Umbra và Phím lỏng.

Mặc dù địa chỉ ẩn danh cung cấp một giải pháp tương đối đơn giản, nhược điểm chính là chúng chỉ có thể thêm các cam kết về quyền riêng tư cho các giao dịch (thanh toán và chuyển khoản), không phải tính toán đa dụng. Điều này làm cho chúng khác biệt so với ba giải pháp khác đã được đề cập ở trên.

Ngoài ra, các cam kết vị bảo mật quá trình để đãn Stealth cung cấp không mạnh mành như các phương án khác. Sự ẩn danh có thể bị phá vềi Phân tích phân cụm đơn giản, đặc biệt là nếu các giao dịch đến và đi không nằm trong một khoảng tương tự (ví dụ: nhận $10.000 nhưng chi trung bình từ $10-100 cho các giao dịch hàng ngày). Một thách thức khác của địa chỉ ẩn danh là nâng cấp khóa, hiện nay cần phải thực hiện cho từng ví một cách riêng biệt (các gói lưu trữ khóa có thể giúp giải quyết vấn đề này). Từ phía giao diện người dùng, các giao thức địa chỉ ẩn danh cũng yêu cầu trừu tượng hóa tài khoản hoặc một người thanh toán để chi trả phí nếu tài khoản không có token phí (ví dụ: ETH).

Rủi ro đối với luận điểm của chúng tôi

Với tốc độ phát triển nhanh chóng và sự không chắc chắn chung quanh các giải pháp kỹ thuật khác nhau, có một số rủi ro đối với luận điểm của chúng tôi về việc MPC là cuộc chơi cuối cùng. Những lý do chính tại sao chúng ta có thể không cần thiết MPC trong một dạng hoặc một hình thức bao gồm:

1. Trạng thái riêng tư được chia sẻ không quan trọng như chúng ta tưởng tượng: Trong trường hợp đó, cơ sở hạ tầng dựa trên ZK được đặt ở vị trí tốt hơn để chiến thắng vì nó có các cam kết về quyền riêng tư mạnh mẽ hơn và chi phí thấp hơn so với FHE. Đã có các trường hợp sử dụng nơi hệ thống dựa trên ZK hoạt động tốt cho các trường hợp sử dụng cô lập, chẳng hạn như giao thức thanh toán riêng tư Payy.
2. Sự đánh đổi về hiệu suất không đáng giá lợi ích về đảm bảo quyền riêng tư: Có thể lập luận rằng sự giả định về niềm tin của một mạng lưới MPC với 2-3 bên được cấp quyền không khác biệt đáng kể so với một người chơi tập trung đơn lẻ và tăng đáng kể về chi phí / overhead không đáng giá. Điều này có thể đúng đối với nhiều ứng dụng, đặc biệt là những ứng dụng có giá trị thấp và nhạy cảm về chi phí (ví dụ: 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 khác nơi sự hợp tác hiện tại rất đắt đỏ (hoặc không thể thực hiện) do các vấn đề pháp lý hoặc sự ma sát lớn trong việc phối hợp. Đây là lúc mà MPC và các giải pháp dựa trên FHE có thể tỏa sáng.
3. Đặc hóa giành chiến thắng hơn thiết kế đa năng: Xây dựng một chuỗi mới và khởi động cộng đồng người dùng và nhà phát triển là rất khó khăn. Do đó, cơ sở hạ tầng riêng tư đa năng (L1/L2s) có thể gặp khó khăn trong việc thu hút sự quan tâm. Một câu hỏi khác liên quan đến đặc hóa; rất khó khăn để một thiết kế giao thức duy nhất bao phủ toàn bộ không gian cân đối. Trong thế giới này, các giải pháp cung cấp sự riêng tư cho các hệ sinh thái hiện có (bảo mật như một dịch vụ) hoặc các trường hợp sử dụng chuyên biệt (ví dụ như cho thanh toán) sẽ chiếm ưu thế. Tuy nhiên, chúng tôi đang hoài nghi về việc áp dụng sau do độ phức tạp mà nó đem lại cho các nhà phát triển ứng dụng mà sẽ phải tự thực hiện một số mật mã (thay vì trừu tượng hóa).
4. Quy định tiếp tục cản trở thử nghiệm xung quanh các giải pháp bảo mật: Đây là rủi ro cho bất kỳ ai xây dựng cả cơ sở hạ tầng quyền riêng tư và ứng dụng với một số đảm bảo quyền riêng tư. Các trường hợp sử dụng phi tài chính phải đối mặt với ít rủi ro pháp lý hơn, nhưng thậ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. Chúng tôi cũng có thể giải quyết các vấn đề kỹ thuật trước các vấn đề quy định.
5. Chi phí của các chương trình 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: Trong khi MPC chủ yếu bị chi phí giao tiếp, các nhóm FHE phụ thuộc rất nhiều vào khả năng tăng tốc phần cứng để cải thiện hiệu suất của họ. Tuy nhiên, nếu chúng ta có thể ngoại suy sự phát triển của phần cứng chuyên dụng ở phía ZK, sẽ mất nhiều thời gian hơn hầu hết mọi người muốn trước khi chúng ta có được phần cứng FHE sẵn sàng sản xuất. Ví dụ về các nhóm làm việc về tăng tốc phần cứng FHE bao gồm Optalysys, Fhela, và Niobi.

Tóm tắt

Cuối cùng, một chuỗi chỉ mạnh như điểm yếu nhất của nó. Trong trường hợp cơ sở hạ tầng quyền riêng tư có thể lập trình, các cam kết đáng tin cậy đều dựa trên MPC nếu chúng ta muốn nó có thể xử lý trạng thái riêng tư được chia sẻ mà không có điểm thất bại duy nhất.

Mặc dù đoạn này có vẻ chỉ trích MPC, nhưng thực tế không phải vậy. MPC mang lại sự cải tiến lớn cho tình trạng hiện tại phụ thuộc vào bên thứ ba tập trung. Vấn đề chính, theo quan điểm của chúng tôi, là sự tự tin sai lầm trong ngành và những vấn đề bị che mờ đi. Thay vì vậy, chúng ta nên đối mặt trực tiếp với vấn đề và tập trung vào đánh giá các rủi ro tiềm năng.

Tuy nhiên, không phải tất cả các vấn đề đều cần được giải quyết bằng cùng một công cụ. Dù chúng tôi tin rằng MPC là giải pháp cuối cùng, nhưng các phương pháp thay thế cũng là những lựa chọn khả thi miễn là chi phí cho các giải pháp được cung cấp bởi MPC vẫn cao. Luôn đáng xem xét phương pháp nào phù hợp nhất với các nhu cầu/đặc điểm cụ thể của các vấn đề chúng ta đang cố gắng giải quyết và những điều đánh đổi chúng ta sẵn lòng thực hiện.

Dù bạn có cái búa tốt nhất trên thế giới, không phải mọi thứ đều là đinh.

Phụ lục 1: Các phương pháp khác nhau để Bảo mật trong Blockchain

Công nghệ tăng cường quyền riêng tưhoặc PET, nhằm mục tiêu cải thiện một hoặc nhiều khía cạnh của những điều trên. Cụ thể hơn, chúng là các giải pháp kỹ thuật để bảo vệ dữ liệu trong quá trình lưu trữ, tính toán và truyền thông.

Có rất nhiều loại PET khác nhau để lựa chọn, nhưng những loại quan trọng nhất đối với ngành công nghiệp blockchain bao gồm bốn phương pháp viết tắt gồm ba chữ cái - ZKP, MPC, FHE và TEE - cùng với các phương pháp bổ sung như địa chỉ ẩn danh:

Các PET này có thể được kết hợp theo nhiều cách khác nhau để đạt được sự đánh đổi và giả định tin cậy khác nhau. Chúng tôi cũng có các giải pháp dựa vào bên thứ ba đáng tin cậy (quyền riêng tư qua trung gian), chẳng hạn như ủy ban sẵn có dữ liệu riêng tư (DAC). Những điều này có thể cho phép quyền riêng tư từ những người dùng khác, nhưng đảm bảo quyền riêng tư chỉ đến từ việc tin tưởng vào bên thứ ba. Theo nghĩa này, nó giống như "quyền riêng tư của web2" (quyền riêng tư từ những người dùng khác), nhưng nó có thể được củng cố với các đảm bảo bổ sung (mật mã hoặc kinh tế).

Tổng cộng, chúng tôi đã xác định 11 phương pháp khác nhau để đạt được một số đảm bảo về quyền riêng tư trong mạng lưới blockchain. Một số sự đánh đổi quan sát bao gồm:

• Quyền riêng tư đáng tin cậy so với quyền riêng tư được giảm thiểu sự tin cậy (Có một điểm thất bại duy nhất không?)
• Phương pháp tiếp cận phần cứng và phần mềm
• Phiên bản riêng biệt so với sự kết hợp của nhiều PET
• L1 vs L2
• New chain vs Add-on privacy to existing chains (“confidentiality as a service”)
• Kích thước của tập hợp bảo vệ (Đa chuỗi > Đơn chuỗi > Ứng dụng > Tài sản đơn)

Phụ lục 2: Tổng quan ngành

Trong 11 danh mục này, nhiều công ty khác nhau đang làm việc trên một hoặc nhiều giải pháp. Dưới đây là một cái nhìn tổng quan (không đầy đủ) về tình hình hiện tại của ngành công nghiệp:

Thông báo:

1. Bài viết này được in lại từ [cân bằng], Tất cả bản quyền thuộc về tác giả gốc [Hannes Huitula] Nếu có ý kiến ​​phản đối về việc tái bản này, vui lòng liên hệ Học cổngđội ngũ và họ sẽ xử lý nhanh chóng.
2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết ra các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi có đề cập, 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.