Thêm quyền riêng tư vào hợp đồng thông minh không đơn giản

Tiêu đề gốc: "Mẹo nhanh | Không dễ để thêm quyền riêng tư vào hợp đồng thông minh"

Nguồn gốc: Những người đam mê Ethereum

Đối với người dùng, việc bảo vệ quyền riêng tư của các giao dịch thông thường (Lưu ý của người dịch: Đôi khi được gọi là giao dịch riêng tư trong bài viết) về cơ bản là một vấn đề đã được giải quyết (mặc dù nghiên cứu vẫn còn một số thách thức). Nếu chúng tôi muốn chuyển tiền điện tử mà không tiết lộ số dư tài khoản hoặc số tiền chuyển, chúng tôi có các tùy chọn có thể chấp nhận được như Zcash hoặc Monero. Tuy nhiên, bảo vệ quyền riêng tư vẫn là một vấn đề chưa được giải quyết đối với các ứng dụng phi tập trung hoặc hợp đồng thông minh.

Điều gì khiến hợp đồng thông minh khác với các giao dịch thông thường về khả năng bảo vệ quyền riêng tư đầu vào/đầu ra (I/O)? Sự khác biệt?

Trong bài viết này, chúng tôi giải thích những thách thức mà chúng tôi sẽ gặp phải khi mở rộng khả năng bảo vệ quyền riêng tư khi giải mã từ các giao dịch thông thường sang hợp đồng thông minh. Để làm điều này, chúng tôi sẽ kiểm tra các công cụ mã hóa phổ biến được áp dụng cho đồng tiền riêng tư và khám phá lý do tại sao những công cụ này ít phù hợp hơn với các ứng dụng bảo mật phức tạp hơn. Cuối cùng, chúng tôi sẽ giới thiệu ngắn gọn một số chương trình bảo vệ quyền riêng tư của hợp đồng thông minh được đề xuất gần đây.

Định nghĩa về bảo vệ quyền riêng tư

Chính xác thì "bảo vệ quyền riêng tư" nghĩa là gì?

Chúng tôi sẽ xác định biện pháp bảo vệ quyền riêng tư từ góc độ chức năng. Ví dụ: chúng ta có thể coi các giao dịch là các hàm lấy đầu vào là số dư tài khoản và số tiền chuyển khoản. Sau đó nó xuất ra số dư đã cập nhật.

- Hình 1: Các hàm được sử dụng để thể hiện quá trình giao dịch. -

(Để đạt được sự bảo vệ quyền riêng tư), chúng ta có thể xem xét việc ẩn đầu vào và đầu ra của hàm. Về mặt giao dịch, điều này cho phép chúng tôi ẩn số dư tài khoản và số tiền chuyển. Bạn có sẵn sàng tiết lộ số dư tài khoản và lịch sử chuyển khoản của mình không? Chắc là không. Do đó, ít nhất chúng ta cần hỗ trợ bảo vệ quyền riêng tư I/O cho các chức năng (và sau đó là hợp đồng thông minh).

- Hình 2: I/O của các hàm ẩn. -

Chúng ta cũng có thể xem xét việc ẩn thông tin người gọi của hàm. Đôi khi đầu vào hàm để lại manh mối về danh tính của người gọi hàm. Trong thực tế, việc ẩn đầu vào và đầu ra của hàm thường được kết hợp với việc ẩn danh tính của người gọi hàm.

- Hình 3: Ẩn người gọi hàm. -

Cuối cùng, chúng ta có thể xem xét việc ẩn chính hàm đó. Điều này ít phổ biến hơn trong thế giới tiền điện tử, thường được kết hợp với đầu vào/đầu ra của các hàm ẩn.

- Hình 4: Ẩn chính hàm đó. -

Khi bạn nhìn thấy từ "bảo vệ quyền riêng tư" trong bài viết này, vui lòng coi nó như một thuật ngữ chung, ít nhất là đề cập đến  thứ gì đó hỗ trợ bảo vệ quyền riêng tư I/O.

Được rồi, nhưng chúng ta sử dụng tính năng bảo vệ quyền riêng tư ở đâu?

Chúng tôi có thể nghĩ rằng việc bảo vệ quyền riêng tư của các giao dịch thông thường đã được giải quyết (ít nhất là về tính khả thi và khả năng mở rộng là một câu chuyện khác), vì vậy hãy chuyển thẳng sang vấn đề bảo vệ quyền riêng tư trong hợp đồng thông minh.

Tuy nhiên, trước tiên hãy đi đường vòng và xem xét Ethereum...

Ethereum hỗ trợ các hợp đồng do người dùng xác định, được thực thi dưới dạng mã (còn được gọi là "hợp đồng thông minh"). Các hợp đồng này được viết bằng ngôn ngữ Turing-complete của Ethereum và trả một số phí (đặt trước) cho mỗi hoạt động được thực hiện. Do đó, phí giao dịch được đính kèm với mỗi giao dịch để khuyến khích người khai thác đóng gói giao dịch.

Bảo vệ quyền riêng tư cho các ứng dụng

Hợp đồng thông minh cho phép Chúng tôi có thể xây dựng nhiều ứng dụng khác nhau trên blockchain - từ các sàn giao dịch phi tập trung (DEX) nơi người dùng có thể giao dịch nhiều loại tiền điện tử và công cụ phái sinh của chúng, đến các ứng dụng phi tập trung cho phép người nắm giữ cổ phần bỏ phiếu cho các đề xuất của Tổ chức tự trị (DAO).

Tôi không nghĩ cần phải giải thích chi tiết tại sao DAO cần bảo vệ quyền riêng tư; trong cuộc sống thực, việc bỏ phiếu thường được thực hiện riêng tư, vì vậy việc ẩn phiếu bầu ảo của chúng tôi là điều hoàn toàn hợp lý.

Mặt khác, việc bảo vệ quyền riêng tư của các sàn giao dịch phi tập trung cần phải được giải thích. Chạy trước là một vấn đề đối với cả sàn giao dịch tập trung và phi tập trung. Trong thế giới blockchain, các nhà giao dịch tiền tuyến giám sát chặt chẽ các đơn đặt hàng đã gửi và nhảy vào hàng đợi bằng cách trả phí giao dịch cao hơn (hối lộ cho người khai thác). Điều này cho phép Eve, nhà giao dịch tiên phong, mua chứng khoán mà Bob muốn mua trước Bob, sau đó bán nó cho Bob với giá cao hơn. Đấu giá kín là một giải pháp khả thi cho vấn đề này. Đối với những độc giả quan tâm, bạn có thể tìm thêm thông tin về việc chạy trước trên các sàn giao dịch phi tập trung tại đây.

Tuy nhiên, hợp đồng thông minh của Ethereum không cung cấp bất kỳ hình thức bảo vệ quyền riêng tư nào ngay từ đầu. Tất cả thông tin đều có thể xem được một cách công khai—đầu vào/đầu ra của hợp đồng, chức năng của hợp đồng, người dùng tham gia, v.v. Việc thêm tính năng bảo vệ quyền riêng tư vào hợp đồng thông minh của Ethereum không phải là một nhiệm vụ dễ dàng, vì Ethereum ngay từ đầu đã không được thiết kế để hỗ trợ bảo vệ quyền riêng tư. Mặc dù các giao dịch riêng tư có thể được thực hiện trên Ethereum (thông qua 1, 2), nhưng các hoạt động bảo vệ quyền riêng tư phức tạp hơn thường quá tốn kém, thậm chí vượt quá giới hạn phí của một khối Ethereum duy nhất (tức là giới hạn gas) để thực hiện.

Chúng ta không thể thiết kế một loại tiền điện tử mới hỗ trợ bảo vệ quyền riêng tư cho bất kỳ chức năng nào ngay từ đầu sao? ? Suy cho cùng thì đó là những gì Zcoin và Monero làm.

Hiện tại, chúng tôi không biết cách hỗ trợ các chức năng tùy ý trong tiền điện tử (chẳng hạn như các chức năng cần thiết để bỏ phiếu và trao đổi) chức năng) Bảo vệ quyền riêng tư I/O. Để hiểu những thách thức này, chúng ta cần kiểm tra cách tiền điện tử hỗ trợ các giao dịch riêng tư.

Con đường bảo vệ quyền riêng tư

Chúng ta hãy cùng nhau trước tiên hãy kiểm tra các công cụ mật mã được sử dụng để bảo vệ quyền riêng tư  I/O trong giao dịch thông thường. Chúng tôi sẽ tập trung vào mô hình tài khoản thay vì mô hình UTXO của tiền điện tử. Mô hình tài khoản đặc biệt hữu ích trong các tình huống hỗ trợ hợp đồng thông minh, nhưng không cần thiết cho việc tính toán quyền riêng tư (như chúng ta sẽ thấy sau).

Công cụ 1: Phép cộng đồng cấu

Lớn nhất các kế hoạch bảo vệ quyền riêng tư của tiền điện tử dựa trên các kế hoạch mã hóa hoặc cam kết có tính đồng hình bổ sung. Để đơn giản, chúng ta sẽ tập trung vào các sơ đồ mã hóa, nhưng các nguyên tắc tương tự cũng áp dụng cho các sơ đồ cam kết.

Theo sơ đồ mã hóa đồng cấu phụ gia, chúng ta có phương trình sau: Enc(a) + Enc(b) = Enc(a + b).

Do đó, sơ đồ mã hóa đồng cấu phụ gia cho phép bất cứ ai xác minh tính hợp lệ của một giao dịch như thế này: Enc(balance ) + Enc(số tiền chuyển) = Enc(số dư + số tiền chuyển) (Tổng giá trị mã hóa của số dư và giá trị mã hóa của số tiền chuyển hoàn toàn bằng giá trị mã hóa của tổng của cả hai).

- Hình 5: Alice chuyển tiền mà không tiết lộ số dư tài khoản hay số tiền chuyển. -

Alice có khóa công khai của riêng mình - pk_a. Cô ấy mã hóa số dư tài khoản bal_a bằng khóa chung của mình (vì vậy chỉ cô ấy mới biết số dư tài khoản). Chúng tôi sử dụng β_a để thể hiện số dư được mã hóa của cô ấy, β_a = Enc(pk_a, bal_a). Khóa công khai pk_a và số dư được mã hóa β_a của Alice đều công khai trên Internet và bất kỳ ai cũng có thể xem được.

Điều tương tự cũng đúng với Bob, anh ấy cũng có khóa công khai pk_b của riêng mình, số dư tài khoản bal_b mà chỉ anh ấy mới có biết, và tên người dùng Số dư β_b sau khi mã hóa khóa công khai của mình, β_b = Enc(pk_b, bal_b).

Nếu Alice muốn chuyển tiền cho Bob mà không tiết lộ số tiền chuyển (amnt) hoặc số dư tài khoản của chính mình, cô ấy chỉ cần Xuất bản số tiền chuyển được mã hóa bằng khóa chung của chính cô ấy và số tiền chuyển được mã hóa bằng khóa chung của Bob. Chúng tôi biểu thị các giá trị này lần lượt bằng c_a = Enc(pk_a, amnt) và c_b = Enc(pk_b, amnt).

Giờ đây, bất kỳ ai cũng có thể tính toán số dư cập nhật. Số dư tài khoản cập nhật của Alice là β_a - c_a và số dư tài khoản cập nhật của Bob là β_b + c_b.

Đợi một chút! Nếu tất cả các giá trị này được mã hóa, làm sao chúng tôi biết liệu Alice có đủ tiền trong tài khoản của mình để chi trả cho số tiền chuyển khoản hay không? Làm thế nào để chúng tôi biết liệu số lượng c_a và c_b được mã hóa có giống nhau hay không?

Đây là lúc chúng ta cần sử dụng công cụ tiếp theo - bằng chứng không có kiến thức.

Công cụ 2: Bằng chứng không có kiến thức (ZKP)

Để đảm bảo rằng Alice không gian lận trong giao dịch trên, cô ấy cần đưa ra bằng chứng kèm theo giao dịch. Bằng chứng này cần chứng minh rằng cô ấy có đủ tiền trong tài khoản để hoàn tất giao dịch, rằng cô ấy không chuyển số tiền âm cho Bob (vô tình hay cố ý) và rằng c_a và c_b đã mã hóa số tiền giống nhau.

Tất nhiên, Alice không muốn tiết lộ số dư tài khoản thực và số tiền chuyển khoản của mình nên cô ấy đính kèm số 0 -know Chứng minh π thuyết phục tất cả người dùng khác rằng các điều kiện cần thiết đã được đáp ứng mà không tiết lộ bất kỳ thông tin bổ sung nào (chẳng hạn như số dư tài khoản hoặc số tiền chuyển khoản của cô ấy).

Bây giờ hãy đặt tất cả các công cụ lại với nhau...

- Hình 6: Bây giờ đính kèm ZKP cần thiết cho giao dịch riêng tư -

Alice sử dụng khóa chung của cô ấy và Bob để mã hóa số tiền chuyển tương ứng và lấy được c_a và c_b. Cô ấy cung cấp ZKP, π, chứng minh rằng cô ấy không gian lận trong giao dịch. Người khai thác sẽ xác minh rằng tất cả các điều kiện cần thiết đều được đáp ứng và ZKP hợp lệ. Sau đó, họ cập nhật số dư mật mã của Alice và Bob tương ứng bằng cách sử dụng phép cộng đồng hình: β_a = β_a - c_a, β_b = β_b + c_b. Lưu ý rằng mặc dù người dùng cung cấp đầu vào được mã hóa và ZKP, người khai thác vẫn chịu trách nhiệm thực hiện tính toán và cập nhật số dư được mã hóa. Trong một blockchain, chúng tôi giả định rằng phần lớn những người khai thác đều trung thực, vì vậy chúng tôi biết rằng họ sẽ cập nhật số dư của Alice và Bob một cách chính xác.

Lưu ý: Đây là cách giải thích được đơn giản hóa rất nhiều (ví dụ: bỏ qua tính ngẫu nhiên cần thiết để đảm bảo bảo mật mật mã)

Thách thức trong việc mở rộng công nghệ bảo vệ quyền riêng tư của các giao dịch thông thường sang hợp đồng thông minh

Như vậy chúng ta vừa thấy rằng chúng ta có thể thực hiện các giao dịch với đầu vào và đầu ra ẩn. Vậy chúng ta có thể sử dụng công nghệ được sử dụng trong các giao dịch quyền riêng tư để hỗ trợ bảo vệ quyền riêng tư I/O cho các ứng dụng không? Nói cách khác:

Tính toán riêng tư và giao dịch riêng tư có khác nhau không? Nếu đúng thì tại sao?

Câu hỏi 1

Cần lưu ý rằng các giao dịch riêng tư cần phải đáp ứng các điều kiện đã đặt ra để chính xác (tức là người gửi phải có đủ tiền, số tiền chuyển phải là số dương, v.v.). Làm thế nào chúng ta có thể tìm ra những điều kiện mà một hợp đồng tùy ý cần phải đáp ứng? Những điều kiện này rõ ràng sẽ bị ảnh hưởng bởi ứng dụng cụ thể. Trong một cuộc thăm dò, chúng tôi có thể muốn chứng minh rằng số phiếu ẩn của chúng tôi đã được bỏ trong phạm vi chính xác, trong khi trong một cuộc đấu giá, chúng tôi có thể muốn chứng minh rằng chúng tôi có đủ tiền trên sổ sách cho một giá thầu đã đóng.

Các giải pháp tiềm năng cho vấn đề 1

Vấn đề này không nghiêm trọng lắm; nó chỉ đòi hỏi người dùng phải làm việc nhiều hơn. Các nhà phát triển ứng dụng phi tập trung phải làm rõ những điều kiện mà ứng dụng cụ thể của họ cần để đáp ứng và truyền đạt những điều kiện này tới người dùng. Để có thể chứng minh các điều kiện khác nhau, chúng tôi có thể muốn hỗ trợ một số ZKP chung trong sơ đồ. Cái gọi là  ZKP phổ quát ZKP là những thứ có thể chứng minh bất kỳ tuyên bố nào (không giống như những ZKP hiện đang được sử dụng trong Zcash, vốn không phổ biến).

Câu hỏi 2

Trong các giao dịch thông thường, chúng tôi chỉ hoạt động trên các giá trị thuộc về cùng một người dùng (tức là được mã hóa bằng cùng một khóa). Ví dụ: trong Hình 6, người khai thác thêm số dư được mã hóa bằng khóa chung của Alice và số tiền chuyển được mã hóa bằng khóa chung của Alice. Điều gì sẽ xảy ra nếu chúng ta muốn thực hiện tính toán quyền riêng tư trên các giá trị đầu vào thuộc về những người dùng khác nhau? Đây không phải là một yêu cầu xa vời, chẳng hạn như nó sẽ được đưa vào khi chúng tôi xem xét việc bảo vệ quyền riêng tư cho việc bỏ phiếu.

Các giải pháp tiềm năng cho vấn đề 2

Không rõ cách hỗ trợ tính toán đầu vào từ những người dùng khác nhau mà không tiết lộ văn bản rõ ràng của đầu vào cho nhau. Có các thành phần mật mã tiên tiến (chẳng hạn như tính toán an toàn nhiều bên và mã hóa đồng cấu hoàn toàn dựa trên nhiều khóa FHE) cho phép người dùng thực hiện tính toán trên các đầu vào được mã hóa bằng các khóa khác nhau. Tuy nhiên, những lựa chọn này rất tốn kém và có nhiều nhược điểm. Trong bối cảnh tiền điện tử, hiện tại dường như không ai có giải pháp tốt cho vấn đề này (ngoài việc chia sẻ bản rõ với những người dùng khác tham gia tính toán và sau đó mã hóa nó bằng cùng một khóa).

Câu hỏi 3

Các giao dịch thông thường chỉ yêu cầu Bổ sung trạng thái tương tự, vì chúng tôi chỉ cần thêm số tiền chuyển được mã hóa vào số dư được mã hóa. Điều gì sẽ xảy ra nếu chúng ta muốn thực hiện một phép tính phức tạp hơn, có thể liên quan đến phép nhân?

Các giải pháp tiềm năng cho vấn đề 3

Phép nhân đồng hình cho phép chúng ta nhân các đầu vào được mã hóa sao cho Enc(a) * Enc(b) = Enc(a * b) . Thông qua phép cộng đồng cấu và phép nhân đồng cấu, chúng ta có thể biểu diễn bất kỳ hàm đa thức nào. Vì vậy, chúng ta tự nhiên nghĩ ra câu hỏi này:

Chúng ta có thể hỗ trợ phép nhân đồng cấu không?

Một sơ đồ mã hóa hỗ trợ cả phép cộng đồng cấu và phép nhân đồng cấu là mã hóa đồng cấu hoàn toàn ( FHE). Sử dụng FHE, chúng ta vẫn có thể làm theo mô hình được mô tả trong Hình 6. Nghĩa là, người dùng chỉ định đầu vào được mã hóa, chức năng sẽ chạy và ZKP chứng minh đầu vào được mã hóa đáp ứng các điều kiện cần thiết. Thợ mỏ có thể xác minh ZKP. Họ sử dụng phép cộng và phép nhân đồng cấu để thao tác trực tiếp trên bản mã do người dùng cung cấp.

Thật không may, sơ đồ FHE sử dụng mã hóa dựa trên mạng, phương pháp này (hiện tại) không giống với phương thức được sử dụng trong tiền điện tử. -ZKP hiệu quả không tương thích. Chúng tôi đã viết về FHE và các vấn đề của nó trước đây. Hiện tại chưa có ai đề xuất giải pháp dựa trên FHE do FHE còn một số hạn chế.

Theo cách này, hiện tại chúng ta chỉ còn lại hai cách để giải bài toán 3.

Hãy chấp nhận hiện trạng là chúng tôi chỉ có thể hỗ trợ phép cộng đồng hình và tuân theo mô hình giao dịch riêng tư.

- Hình 7: Theo mô hình giao dịch quyền riêng tư-

Tại đây, người dùng cung cấp đầu vào được mã hóa và ZKP, Prove rằng đầu vào của chúng thỏa mãn một số điều kiện quy định cho một ứng dụng cụ thể. Người khai thác xác minh bằng chứng, sử dụng phép cộng đồng hình để vận hành trên đầu vào. Lưu ý rằng các hàm áp dụng cho đầu vào chỉ có thể được biểu diễn bằng phép cộng. Do đó, miễn là hàm chỉ yêu cầu phép cộng đồng hình, chúng ta có thể yêu cầu người khai thác thực thi bất kỳ hàm nào thỏa mãn điều kiện này trên đầu vào được mã hóa của chúng ta. Đây là cách tiếp cận được thực hiện bởi Zether 

Yêu cầu người dùng tính toán ngoại tuyến. Bằng cách này, chúng tôi không cần hỗ trợ phép nhân đồng cấu cho mã hóa/cam kết.

- Hình 8: Gia công công việc cho người dùng-

Ở đây, chúng tôi yêu cầu người dùng Alice thực hiện Hầu như tất cả các tính toán được thực hiện ngoại tuyến. Cô xuất bản các đầu vào được mã hóa và đầu ra được mã hóa của các phép tính. Vì việc tính toán được thực hiện ngoại tuyến (nên chúng tôi không biết Alice có trung thực hay không) nên cô ấy cũng cần cung cấp ZKP để chứng minh rằng quá trình tính toán là chính xác. Lưu ý rằng bước này không cần thiết đối với các giao dịch riêng tư vì thợ mỏ thực hiện các phép tính và chúng tôi cho rằng phần lớn thợ mỏ đều trung thực. Về phía đơn đăng ký, cô ấy cũng có thể cần một ZKP khác để chứng minh rằng các điều kiện mà đơn đăng ký chỉ định đã được đáp ứng. Tất cả những gì thợ mỏ cần làm là xác minh rằng ZKP hợp lệ và sau đó đồng ý với thay đổi trạng thái được đề xuất của Alice. Đây là cách tiếp cận được thực hiện bởi Zexe và Zkay.

Ở đây tôi sẽ không tranh luận xem cách tiếp cận nào (Hình 7 so với Hình 8) tốt hơn; chỉ là chúng khác nhau .

Bảo vệ quyền riêng tư của hợp đồng thông minh

Chúng ta đã nói về một số vấn đề gặp phải khi hỗ trợ bảo vệ quyền riêng tư cho các chức năng tùy ý trong chuỗi khối. Bây giờ chúng ta hãy xem cấu trúc của một số giải pháp hiện có.

Nếu những gì tôi nói trước đây chưa đủ rõ ràng, hãy để tôi nhắc lại rằng lĩnh vực này vẫn còn lâu mới giải quyết được vấn đề. Con đường để đi. Các bài báo thiết kế các công trình này (tức là Zether, Zkay, Zexe) đều được xuất bản trong hai năm qua.

Zether là giải pháp giao dịch riêng tư được xây dựng trên Ethereum. Nó có thể được mở rộng để hỗ trợ bảo vệ quyền riêng tư I/O cho các hợp đồng thông minh có giới hạn—tức là những hợp đồng có thể được biểu diễn bằng phép cộng đồng hình. Điều này cho phép chúng tôi thực hiện các cuộc đấu giá kín đơn giản (giả sử người đặt giá thầu sẽ mua tất cả các căn hộ cùng một lúc) và bỏ phiếu kín (giả sử tùy chọn bỏ phiếu là 0 hoặc 1). Thật không may, do hạn chế về gas, hiện tại chỉ có thể ẩn số dư của người dùng và số tiền chuyển trong các giao dịch trên Ethereum. Không giống như hai cấu trúc tiếp theo, Zether sử dụng ZKP "minh bạch" (tức là ZKP không yêu cầu thiết lập khởi động đáng tin cậy).

Zkay cũng mở rộng thiết kế của Ethereum để hỗ trợ bảo vệ quyền riêng tư của các hợp đồng thông minh. Họ dựa vào ZKP để đảm bảo tính chính xác của các phép tính riêng tư, do đó hầu hết công việc có thể được giao cho người dùng hoàn thành ngoại tuyến. Do đó, lựa chọn thiết kế này cho phép chúng hỗ trợ nhiều chức năng hơn Zether.

Zexe cố gắng mở rộng thiết kế của Zcash để hỗ trợ các tập lệnh tùy ý. Không giống như hai phần đầu tiên, Zexe cũng có thể hỗ trợ bảo vệ quyền riêng tư cho chính chức năng này.

* Zkay và Zexe (như đã đề cập trước đó) sử dụng sơ đồ ZKP với cài đặt đáng tin cậy. Tuy nhiên, các sơ đồ ZKP này chắc chắn có thể được thay thế bằng các sơ đồ không yêu cầu thiết lập đáng tin cậy.

** Trong kịch bản blockchain, bảo vệ quyền riêng tư I/O dường như có ý nghĩa hơn bảo vệ quyền riêng tư theo chức năng, bởi vì người dùng có thể muốn kiểm tra hợp đồng trước khi quyết định có tham gia hợp đồng hay không.

Xin lưu ý rằng có các cấu trúc khác để bảo vệ quyền riêng tư của hợp đồng thông minh (ví dụ: Ekiden, Hawk, Arbitrum), nhưng tất cả các giải pháp này đều yêu cầu một số loại trình quản lý bán tin cậy hoặc phần cứng đáng tin cậy.

Hầu hết các chương trình bảo vệ quyền riêng tư của hợp đồng thông minh đều yêu cầu các giả định bảo mật bổ sung - cho dù đó là thiết lập đáng tin cậy, người quản lý gần như đáng tin cậy hay bất kỳ phần cứng nào đáng tin cậy. Tuy nhiên, ZKP là một lĩnh vực đang phát triển nhanh chóng và các cấu trúc minh bạch và hiệu quả hơn có thể sẽ được tạo ra.

Kỳ vọng

Việc khám phá tính năng bảo vệ quyền riêng tư trong hợp đồng thông minh đặt ra rất nhiều lý thuyết thú vị khi nói đến tính biểu cảm, sự tin cậy và hiệu quả. và những thách thức thực tế. Bây giờ, thật khó để nói phương pháp nào trong số các phương pháp được trình bày trong Hình 7 hoặc Hình 8 có khả năng giành chiến thắng trong các tính toán về quyền riêng tư cho chuỗi khối. Ngoài ra, sẽ rất thú vị để xem liệu những tiến bộ trong tương lai về mã hóa đồng cấu hoàn toàn có thể được chuyển sang blockchain để giải quyết vấn đề 3 hay không.

Nguồn gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia