ZK-SNARKs: thiết lập có thể cập nhật trên blockchain

Ngày 07 tháng 09 năm 2022

Zk-SNARKs đã được chứng minh là 'con dao đa năng' cho chuỗi khối và sổ cái phân tán, với các ứng dụng về quyền riêng tư, khả năng tương tác và khả năng mở rộng

Kể từ khi được giới thiệu, Bằng chứng không tri thức (Zero-Knowledge Proofs - ZKP) đã được sử dụng để hỗ trợ các ứng dụng tiềm năng, từ tính toán bên ngoài có thể xác minh đến thông tin xác thực ẩn danh, cùng vô số các thiết lập yêu cầu cân bằng giữa Quyền riêng tư và Tính toàn vẹn. 

Hiểu ngắn gọn

Zero-Knowledge Proofs là một công nghệ cho phép một cá nhân chứng minh cho đối tượng khác rằng một tuyên bố nào đó là đúng, mà không phải tiết lộ bất kỳ thông tin nào ngoài tính hợp lệ của tuyên bố đó. Các bên liên quan thường được gọi là bên chứng minh và bên xác minh, và tuyên bố họ giữ bí mật với nhau được gọi là bằng chứng. Mục tiêu chính của các bằng chứng này là tiết lộ càng ít dữ liệu càng tốt giữa hai bên, nhưng vẫn đảm bảo tính trung thực. Nói cách khác, người ta có thể sử dụng bằng chứng Zero-Knowledge để chứng minh rằng họ có hiểu biết nhất định mà không tiết lộ bất kỳ thông tin nào về hiểu biết đó.

ZKP được ứng dụng trong nhiều trường hợp sử dụng trên chuỗi góp phần giải quyết các vấn đề về quyền riêng tư, khả năng tương tác và khả năng mở rộng.

Trong bài đăng này, chúng ta sẽ xem xét các loại ZKP khác nhau và những trường hợp cụ thể sẽ sử dụng chúng. Chúng ta cũng thảo luận về zk-SNARK, một số vấn đề đã biết về tính ứng dụng của nó và đề xuất một cơ chế blockchain với các đặc điểm an toàn trong các điều kiện tương đương với giao thức blockchain. 

Bài viết dựa trên tài liệu nghiên cứu ' Khai thác để bảo mật: Cách khởi động chuỗi khối Snarky ' được viết bởi Thomas Kerber, Aggelos Kiayias và Markulf Kohlweiss.

Các loại ZKP khác nhau

Trong cài đặt blockchain, máy trạm được thiết lập tải xuống và xác minh mọi giao dịch được xuất bản lên mạng lưới. Điều này có nghĩa là kích thước bằng chứng nhỏ và thời gian xác minh nhanh là rất quan trọng đối với việc triển khai thực tế các giao thức zero-knowledge. Có một số cơ chế thực thi để bạn lựa chọn, với một khoảng không gian rộng lớn của sự đánh đổi trong hiệu suất và các giả định về mật mã:

• Non-interactive zero-knowledge arguments (NIZKs): đây là khái niệm chung nhất. NIZK có thể không ngắn gọn, nhưng đây cũng là điểm có lợi, bởi có thể dựa trên các giả định mật mã tiêu chuẩn và thường sẽ đáp ứng các đảm bảo an ninh mạnh mẽ.
• Succinct non-interactive zero-knowledge arguments (SNARGs): đạt được sự ngắn gọn cần thiết bằng cách đánh đổi các giả định mật mã mạnh hơn dẫn đến các đảm bảo bảo mật thường yếu hơn.
• Succinct non-interactive zero-knowledge arguments of knowledge (SNARKs hoặc viết tắt là zk-SNARKs): đây là các SNARG cũng là proofs of knowledge và zero-knowledge. Cái tên này cũng được yêu thích vì bài thơ The Hunting of the Snark của Lewis Carrol.
• Succinct transparent arguments of knowledge (STARKs): tính Minh bạch ở đây đề cập đến việc thiết lập chỉ yêu cầu một hàm băm đáng tin cậy. Điều này có lợi nhưng có thể đi kèm với chi phí cao về hiệu suất.

Giải thích các từ chuyên nghành

• Succinct (cô đọng), có nghĩa là những bằng chứng này có kích thước nhỏ và có thể được xác minh nhanh chóng.
• Non-interactive (không tương tác), có nghĩa là có ít hoặc không có tương tác giữa bên chứng minh và bên xác minh. Các phiên bản cũ hơn của giao thức không kiến thức thường yêu cầu bên chứng minh và bên xác minh giao tiếp qua lại, do đó, được coi là bằng chứng zk “Interactive”(Tương tác). Nhưng với cách xây dựng “non-interactive” (không tương tác), bên chứng minh và bên xác minh chỉ phải trao đổi một bằng chứng.
• Argument (đối số). zk-SNARKs được coi là có tính đúng đắn dựa trên sức mạnh điện toán, có nghĩa là khả năng bên chứng minh đánh lừa hệ thống thành công là rất thấp. Đặc điểm này được gọi là tính đúng đắn với giả định rằng bên chứng minh có sức mạnh tính toán hạn chế. Về mặt lý thuyết, bên chứng minh khi có đủ sức mạnh tính toán có thể tạo ra bằng chứng giả. Và đây là một trong những lý do máy tính lượng tử được nhiều người coi là mối đe dọa đối với zk-SNARK và các hệ thống blockchain.
• Knowledge (Tri thức), nghĩa là bên chứng minh không thể xây dựng một bằng chứng mà không thực sự có tri thức (hoặc nhân chứng) để hỗ trợ cho tuyên bố của mình.
• Zero-knowledge proof (bằng chứng không tri thức) có thể được kiểm chứng nhanh chóng và thường chiếm ít dữ liệu hơn nhiều so với tiêu chuẩn áp dụng cho giao dịch Bitcoin. Điều này giúp mở ra một cơ hội cho công nghệ zk-SNARK được sử dụng như một giải pháp bảo mật và mở rộng.

Hiện tại, hệ thống bằng chứng đáng chú ý nhất, dưới góc độ của người xác minh là Succinct non-interactive argument of knowledge, hay gọi tắt là zk-SNARK. zk-SNARK có kích thước bằng chứng không đổi nhỏ và chi phí xác minh theo thời gian không đổi ngay cả với các liên kết lớn tùy ý. Zk-SNARKs đã được chứng minh là "Swiss army knife" (con dao đa năng của quân đội Thụy Sĩ) cho chuỗi khối và sổ cái phân tán, với các ứng dụng về quyền riêng tư, khả năng tương tác và khả năng mở rộng.

Tiêu điểm

• Zero-knowledge Succinct non-interactive argument of knowledge (zk-SNARK): Đối số tri thức không tương tác cô đọng
• Zero-knowledge Succinct transparent argument of knowledge (zk-STARK): Đối số tri thức không minh bạch cô đọng.

Bằng chứng Zk-SNARK đã được sử dụng trên Zcash, trên hệ thống thanh toán dựa trên blockchain của JPMorgan Chase, và đóng vai trò như một phương thức để xác thực kết nối an toàn từ máy khách tới máy chủ. Trong khi zk-SNARK đã có những bước tiến đáng kể để được thiết lập và chấp nhận, zk-STARK hiện đang được quảng cáo là phiên bản giao thức mới và cải tiến, giúp giải quyết nhiều nhược điểm trước đây của zk-SNARK.

Các trường hợp sử dụng

Các trường hợp sử dụng của zk-SNARK rất đa dạng. Đôi khi SNARK được sử dụng để cải thiện hiệu suất và các thuộc tính ngắn gọn của hệ thống. Các trường hợp sử dụng khác sử dụng zk-SNARK để cải thiện quyền riêng tư. Một số trường hợp là hỗn hợp, trong đó cả hai khía cạnh đều đóng một vai trò.

Trong cài đặt blockchain, có tính đến hiệu suất và tính ngắn gọn, zk-SNARKS có thể đóng góp rất nhiều vào các trường hợp sử dụng như:

• Máy khách nhẹ: để nâng cao hiệu quả của các thông số và cấu trúc tổng thể của các ứng dụng. Hệ thống bằng chứng hiệu quả (không yêu cầu zero-knowledge) đóng một vai trò quan trọng trong việc khởi động các ứng dụng khách nhẹ. Hệ thống chứng minh đệ quy cũng hoạt động như một kết hợp tốt cho trường hợp sử dụng này để đảm bảo an toàn cho đệ quy không bị ràng buộc cũng như việc sử dụng các hàm bên ngoài (ví dụ, hàm băm) trong các chứng minh đệ quy.
• Hợp đồng thông minh: để giảm tắc nghẽn sổ cái có thể xảy ra do thực thi hợp đồng thông minh công khai. Việc biên dịch mã trên chuỗi thành SNARK, với thời gian xác minh không đổi hoặc theo lôgarit, có thể cho phép các trình xác thực phức tạp hơn.
• Bằng chứng về công việc hữu ích (PoUW): SNARK có thể là chìa khóa để xác minh 'các tính toán hữu ích' được thực hiện bởi các thợ đào, nếu không thì sẽ rất tốn kém để xác thực trên chuỗi.

Từ góc độ quyền riêng tư, nhiều ứng dụng sử dụng bằng chứng zero-knowledge để triển khai các giải pháp thanh toán an toàn, trao đổi tùy chọn, quản lý danh tính, bỏ phiếu, đấu giá, thống kê có thể xác minh (một dạng tiên tri của blockchain) hoặc giao tiếp ẩn danh được khuyến khích. Các trường hợp sử dụng có thể bao gồm:

• Hợp đồng thông minh riêng: SNARK là không thể thiếu trong thiết kế hợp đồng thông minh riêng hiện nay. Hai điều tối quan trọng: tính phổ biến, để hỗ trợ các hợp đồng thông minh do người dùng triển khai và dễ biên dịch. Ví dụ, tính biểu đạt của hợp đồng thông minh có thể được loại bỏ để giảm bớt phạm vi vấn đề, bằng cách không cho phép các vòng lặp và đệ quy không bị ràng buộc. Do đó, không cần thành phần SNARK đệ quy. Về cơ bản, một số tập hợp con của ngôn ngữ hợp đồng cấp cao có thể được biên dịch thành SNARK.
• Thanh toán cá nhân: tài sản có thể được coi là một hình thức xác nhận danh tính cụ thể bao gồm mô hình hóa sự khan hiếm. Một đề xuất cho các khoản thanh toán cá nhân cũng có thể hỗ trợ nhiều tài sản và token không thể thay thế (NFT), đồng thời kết nối các token này với các hợp đồng thông minh.
• Quản lý danh tính: Trong bối cảnh thông tin xác thực có thể xác minh, tổ chức phát hành có thể xác nhận các yêu cầu về chủ thể bằng cách tạo các đối tượng mật mã (thông tin xác thực). Các đối tượng sau đó xuất trình thông tin đăng nhập của họ cho những người dùng khác đang đóng vai trò là người xác minh. Sau đó, người xác minh có thể xác thực rằng một tổ chức phát hành đã xác nhận các tuyên bố về chủ thể xuất trình thông tin xác thực.
• Bỏ phiếu và kho bạc: Bằng chứng ZK có thể được sử dụng trong bỏ phiếu kho bạc. Ví dụ, một hệ thống ngân khố cho giao thức tiền điện tử cung cấp một kế hoạch bỏ phiếu bảo vệ quyền riêng tư, trong đó các lá phiếu của cử tri được mã hóa và sau đó được đối chiếu bằng cách sử dụng tính toán đồng hình (homomorphic computations). Bằng chứng ZK trong kho bạc là các giao thức Sigma không tương tác dựa trên DLP được sử dụng để chứng minh tính đúng đắn của các thông điệp được mã hóa ở các giai đoạn khác nhau của giao thức (ví dụ: lá phiếu của cử tri được mã hóa chứa một lá phiếu được soạn chính xác).

Các trường hợp sử dụng hỗn hợp bao gồm:

• Mục tiêu của chuỗi khối: SNARK có thể giảm chi phí xác minh khi tổng hợp dữ liệu từ nhiều nguồn và chúng có thể giảm kích thước của dữ liệu trên chuỗi được đăng bằng cách chỉ bao gồm giá trị tổng hợp và bằng chứng, thay vì tất cả các điểm dữ liệu. Để đạt được hai đặc tính này, các bên phải có khả năng chứng minh một cách ngắn gọn kiến ​​thức về chữ ký trên một số điểm dữ liệu cũng như giá trị trung bình / trung vị / phương sai tương ứng.
• Sidechains: một chuỗi trong cấu hình chuỗi neo vào có thể hoạt động như một ứng dụng khách nhẹ đối với chuỗi kia, xác minh các giao dịch xuyên chuỗi trên chuỗi khác mà không cần phải xác minh toàn bộ chuỗi đó. Sự khác biệt là việc neo này thường được duy trì lâu dài, và do đó, các bằng chứng có thể được cung cấp thường xuyên và theo kiểu 'có thể cập nhật được'. Xem Bằng chứng cổ phần Sidechains để biết thêm thông tin.

Chi tiết: Kiến thức học thuật chuyên sâu

Các vấn đề đã biết

Non-interactive zero-knowledge yêu cầu một số ngẫu nhiên được chia sẻ hoặc một dãy tham chiếu (reference string) chung. Đối với nhiều hệ thống ngắn gọn, một thuộc tính mạnh hơn là cần thiết:

Không chỉ cần một giá trị ngẫu nhiên được chia sẻ mà còn phải tuân theo một cấu trúc cụ thể. Một dãy tham chiếu có cấu trúc (SRS) thường bao gồm các phần tử nhóm có liên quan, nghĩa là: g(^x)ⁱ với mọi i∈𝕫_n.

Cách rõ ràng để lấy mẫu một dãy tham chiếu như vậy từ ngẫu nhiên công khai tiết lộ số mũ được sử dụng - và kiến ​​thức về những giá trị này phá vỡ tính hợp lý của chính hệ thống chứng minh. Để làm cho vấn đề trở nên tồi tệ hơn, tính bảo mật của các hệ thống này thường dựa (trong số những thứ khác) vào kiến ​​thức về các giả định lũy thừa, trong đó nêu rõ rằng để tạo các phần tử nhóm có liên quan theo cách như vậy đòi hỏi phải biết các số mũ cơ bản và do đó bất kỳ trình lấy mẫu SRS nào sẽ phải 'biết' các số mũ được sử dụng và đáng tin cậy để xóa chúng, trên thực tế, trở thành một điểm thất bại duy nhất cho hệ thống cơ bản.

Tính toán đa bên an toàn (Secure multi-party computation - MPC) có thể đã và đang được sử dụng để làm giảm sự tin cậy được đặt vào một quy trình thiết lập như vậy. Tuy nhiên, việc lựa chọn những người tham gia để tính toán an toàn và xác minh việc tạo SRS bằng giao thức MPC giữ lại một yếu tố tập trung. Sử dụng MPC vẫn là một yếu tố gây tranh cãi trong việc thiết lập một hệ thống phi tập trung yêu cầu SNARK.

Giải quyết các vấn đề về quyền riêng tư với tạo SRS an toàn

Dãy tham chiếu có cấu trúc có thể cập nhật (updatable structured reference string - uSRS) có thể được khởi tạo an toàn bằng cách sử dụng sổ cái phân tán bằng cách yêu cầu người tạo khối thực hiện cập nhật trên uSRS đang phát triển trong thời gian thiết lập ban đầu. Sau khi chờ thống nhất về uSRS cuối cùng, nó có thể được sử dụng một cách an toàn.

Bằng chứng về điều này dựa trên phương tiện hoạt động cơ bản của sổ cái kiểu Nakamoto: những người dùng khác nhau có thể mở rộng chuỗi khối nếu họ có thể đáp ứng một số điều kiện, với điều kiện này được liên kết với một loại độ cứng đảm bảo những kẻ tấn công bị hạn chế về số lượng phần mở rộng mà họ có thể thực hiện. Với cấu trúc như vậy, chúng tôi liên kết bản cập nhật uSRS với mỗi khối trước thời điểm 𝛿 1 . Thời gian này được chọn sao cho các thuộc tính bảo mật của sổ cái đảm bảo rằng ít nhất một trong các khối là trung thực trong mỗi chuỗi cạnh tranh tại thời điểm này.

Điều này có thể được xây dựng từ chức năng sổ cái với trạng thái lãnh đạo bổ sung, được lấy từ thông tin mà các thợ đào nhúng vào các khối của họ để mã hóa các bản cập nhật uSRS. Điều này là đủ chung để cho phép các mục đích sử dụng khác. Ý tưởng cơ bản là chỉ ra rằng sổ cái thực hiện cập nhật uSRS ở trạng thái lãnh đạo của nó tương đương với sổ cái không thực hiện, nhưng đi kèm với một uSRS an toàn. Sau thời gian 𝛿₁ , người dùng đợi thêm một khoảng thời gian 𝛿₂ cho đến khi tiền tố chung đảm bảo rằng tất cả các bên đồng ý về dãy tham chiếu.

Tóm tắt sổ cái được đề xuất

Việc xây dựng chức năng dãy tham chiếu có cấu trúc có thể cập nhật của chúng tôi dựa trên các thuộc tính của tiền tố chung , chất lượng chuỗi và tăng trưởng chuỗi được xác định trong phân tích xương sống Bitcoin của Garay và cộng sự, cho các thuật toán đồng thuận kiểu Nakamoto:

• Tiền tố chung . Cho chuỗi hiện tại 𝛱₁ và 𝛱₂ của hai bên và loại bỏ k khối khỏi chuỗi thứ nhất, nó là tiền tố của chuỗi thứ hai: 𝛱₁^⌊k ≺𝛱₂.
• Chất lượng chuỗi tồn tại . Đối với chuỗi hiện tại của bất kỳ bên nào 𝛱, bất kỳ khối l liên tiếp nào trong chuỗi này sẽ bao gồm ít nhất một khối được tạo bởi một bên trung thực.
• Tăng trưởng theo chuỗi . Nếu chuỗi của một bên có độ dài c , thì s khe thời gian sau đó, nó sẽ có độ dài ít nhất là c + 𝛾 .

Xây dựng uSRS phi tập trung

Việc xây dựng được đề xuất của chúng tôi, được trình bày chi tiết trong bài báo về Khai thác quyền riêng tư, rất đơn giản: mỗi chuỗi được liên kết với một uSRS cụ thể và khi người khai thác mở rộng một chuỗi, họ cũng thực hiện cập nhật uSRS. Tại nguồn gốc của chuỗi, có thể sử dụng tính ngẫu nhiên đã biết (hoặc thậm chí không có ngẫu nhiên). Nguyên tắc đằng sau thiết kế này rất đơn giản: khả năng cập nhật của uSRS đảm bảo rằng nếu một cập nhật duy nhất được thực hiện trung thực (cả sử dụng ngẫu nhiên thực sự và xóa ngẫu nhiên này sau khi cập nhật được thực hiện), uSRS kết quả có thể được sử dụng một cách an toàn. Chúng tôi dựa vào thuộc tính chất lượng chuỗi tồn tại để đảm bảo điều này - khi l khối đã được tạo, ít nhất một trong số này phải được tạo bởi một người khai thác trung thực và do đó sau khi, uSRS của một chuỗi được bảo mật.

Tuy nhiên, vẫn chưa đủ để biết rằng dãy tham chiếu của một chuỗi cụ thể là an toàn - đối với hầu hết các ứng dụng thực tế, chúng tôi muốn tất cả người dùng đồng ý về dãy tham chiếu. Điều này được cung cấp bởi thuộc tính tiền tố chung , đảm bảo rằng đối với bất kỳ chuỗi nào dài l + k khối, tất cả người dùng khác sẽ có cùng một dãy tham chiếu như chuỗi được tạo bởi chuỗi này - miễn là người dùng ngừng cập nhật sau l khối!

Cuối cùng, tăng trưởng chuỗi đảm bảo rằng sự kiện mà chúng tôi quan tâm - khi mọi người đồng ý về dãy tham chiếu - cuối cùng sẽ xảy ra. Nó đảm bảo rằng người dùng cuối cùng sẽ có một chuỗi chiều dài l+k . Cụ thể, cứ mỗi s đơn vị thời gian, các khối được tạo ra, thì sự kiện sẽ xảy ra chậm nhất tại thời điểm ⌈(l+k)/s⌉.

Tất cả điều này là tốt trong phần tóm tắt, nhưng để lại các câu hỏi về tính thực tiễn: các phân tích trừu tượng như vậy giả định rằng các bản cập nhật có thể được tạo ra với chi phí ít hoặc không tốn kém và chúng không ảnh hưởng đến quy trình khai thác tiêu chuẩn. Tuy nhiên, điều này không hoàn toàn đúng với khai thác bằng chứng công việc:

1. Việc cập nhật tương đối tốn kém, mất 5-10 phút để tính toán, tùy thuộc vào kích thước của uSRS được nhắm mục tiêu.
2. Có thể gian lận trong các bản cập nhật, thực hiện chúng nhanh hơn nhưng không thêm tính bảo mật của dãy tham chiếu.

Kết hợp lại, các yếu tố này đặt ra một thách thức, đặc biệt là trong cài đặt bằng chứng công việc, nơi cần thực hiện cập nhật trước khi người khai thác có thể bắt đầu khai thác một khối. Điều này làm trì hoãn các thợ đào không gian lận, trong khi các đối tác gian lận của họ đã khai thác! Do đó, độ khó khai thác (tương ứng với thời gian dự định giữa các khối) không được quá thấp, vì càng thấp, người khai thác gian lận càng được lợi. Mặt khác, độ khó cao đương nhiên dẫn đến thời gian đạt được sự đồng thuận lâu hơn. Sự cân bằng này được biểu đồ trong Hình 1.

Với điều kiện độ khó được hiệu chỉnh một cách thích hợp, một phân tích mô phỏng cho thấy rằng hiệu ứng này không làm hỏng an ninh tổng thể. Tùy thuộc vào xác suất thất bại (є) mà chúng tôi sẵn sàng chấp nhận và phần sức mạnh khai thác của kẻ tấn công (а) mà chúng tôi muốn bảo vệ chống lại, uSRS có thể được tạo an toàn bằng quy trình trong vòng vài giờ hoặc trong vài giờ trong một kịch bản bi quan hơn, như thể hiện trong Hình 1.

Hình 1. Thời gian cần thiết cho đến khi đảm bảo có ít nhất một bản cập nhật trung thực, như một hàm của thời gian khối đích

Nguồn: ' Khai thác vì quyền riêng tư: Cách khởi động một bài báo nghiên cứu về chuỗi khối Snarky '

Một vấn đề tương tự xảy ra khi xem xét hành vi hợp lý - những người khai thác chỉ tìm kiếm lợi nhuận cũng sẽ cố gắng gian lận trong các bản cập nhật của họ, không phải vì ác ý, mà đơn giản là vì họ có thể tạo ra các khối nhanh hơn nếu họ làm vậy. Điều này có thể được tránh bằng cách bổ sung thưởng cho hành vi tốt - sau khi thực tế có thể yêu cầu lấy mẫu các thợ đào để cung cấp tính ngẫu nhiên cho các bản cập nhật của họ và chứng minh rằng nó đã được lấy mẫu theo cách thích hợp (ví dụ: sử dụng hàm băm). Nếu họ có thể làm như vậy, họ có thể nhận được một phần thưởng bổ sung, bù đắp bất kỳ tổn thất nào mà họ có thể có do không gian lận.

Tóm lại

Khả năng ứng dụng của zk-SNARK mang lại rất nhiều lợi ích cho các trường hợp sử dụng trên chuỗi khác nhau giải quyết các vấn đề về quyền riêng tư, khả năng tương tác và khả năng mở rộng.

Mặc dù thiết lập đáng tin cậy, được yêu cầu đối với nhiều zk-SNARK, dường như trái ngược với bản chất phi tập trung của sổ cái phân tán, nó có thể được thực hiện theo cách phân cấp hoàn toàn cho SNARK với các dãy tham chiếu có thể cập nhật. Mặc dù về nguyên tắc, người ta cũng có thể sử dụng SNARK minh bạch như Halo , các kỹ thuật được mô tả ở trên cho phép SNARK như Plonk (có thể hiệu quả hơn tùy thuộc vào hoàn cảnh), dựa trên các dãy tham chiếu có thể cập nhật, cũng được sử dụng một cách an toàn cho- ứng dụng chuỗi - không còn là trường hợp các thiết lập SNARK quá mờ để tin tưởng, nếu chúng đã từng.

Nguồn bài viết tại đây

Mặc dù đã cố gắng, nhưng người dịch bài không thể chuyển tải hết các nội dung kỹ thuật để có thể dễ hiểu hơn. Tất cả nội dung bài viết này có thể cô đọng ở phần TIP tóm tắt ý. 😄

---

---

Đọc thêm các bài viết liên quan tại thẻ Tags bên dưới