Giới thiệu về zk-SNARKs

blog 1Tin tứcDevelopersEnterpriseBlockchain ExplainedEvents and ConferencePressBản tin

Theo dõi bản tin của chúng tôi.

Địa chỉ email

Chúng tôi tôn trọng quyền riêng tư của bạn

Trang chủBlogBlockchain phát triển

Giới thiệu về zk-SNARKs

Tổng quan về các bằng chứng không có kiến ​​thức và cách tích hợp zk-SNARK vào Ethereum. bởi ConsenSysMarch 27, 2017Đăng vào ngày 27 tháng 3 năm 2017

anh hùng quê hương

Trong bài đăng này, chúng tôi nhằm mục đích cung cấp một cái nhìn tổng quan về zk-SNARK từ một quan điểm thực tế. Chúng tôi sẽ coi toán học thực tế như một hộp đen và cố gắng phát triển một số trực giác về cách chúng tôi có thể sử dụng chúng. Chúng tôi cũng sẽ cung cấp một ứng dụng đơn giản của công việc gần đây trên tích hợp zk-SNARK trong Ethereum.

Bằng chứng Zero-Knowledge

Mục tiêu của chứng minh không có kiến ​​thức là để người xác minh có thể thuyết phục mình rằng một câu châm ngôn sở hữu kiến ​​thức về một tham số bí mật, được gọi là nhân chứng, đáp ứng một số mối quan hệ, mà không tiết lộ nhân chứng cho người xác minh hoặc bất kỳ ai khác..

Chúng ta có thể nghĩ về điều này một cách cụ thể hơn là có một chương trình, ký hiệu là C, lấy hai đầu vào: C (x, w). Đầu vào x là đầu vào công khai và w là đầu vào của nhân chứng bí mật. Đầu ra của chương trình là boolean, tức là true hoặc false. Mục tiêu sau đó được đưa ra một đầu vào công khai cụ thể x, chứng minh rằng câu tục ngữ biết một đầu vào bí mật w sao cho C (x, w) == true.

Chúng tôi đặc biệt sẽ thảo luận về các bằng chứng kiến ​​thức không tương tác. Điều này có nghĩa là bản thân bằng chứng là một khối dữ liệu có thể được xác minh mà không cần bất kỳ sự tương tác nào từ câu tục ngữ..

Chương trình mẫu

Giả sử Bob được cấp một hàm băm H có giá trị nào đó và anh ta muốn có bằng chứng rằng Alice biết giá trị s mà hàm băm thành H. Thông thường Alice sẽ chứng minh điều này bằng cách đưa s cho Bob, sau đó Bob sẽ tính toán hàm băm và kiểm tra xem nó bằng H.

Tuy nhiên, giả sử Alice không muốn tiết lộ giá trị s cho Bob mà thay vào đó cô ấy chỉ muốn chứng minh rằng cô ấy biết giá trị đó. Cô ấy có thể sử dụng zk-SNARK cho việc này.

Chúng ta có thể mô tả kịch bản của Alice bằng cách sử dụng chương trình sau, ở đây được viết dưới dạng một hàm Javascript:

function C (x, w) {return (sha256 (w) == x);} Ngôn ngữ mã: JavaScript (javascript)

Nói cách khác: chương trình nhận vào một hàm băm công khai x và một giá trị bí mật w và trả về true nếu hàm băm SHA – 256 của w bằng x.

Dịch bài toán của Alice bằng cách sử dụng hàm C (x, w), chúng ta thấy rằng Alice cần tạo ra một bằng chứng rằng cô ấy sở hữu s sao cho C (H, s) == true, mà không cần phải tiết lộ s. Đây là vấn đề chung mà zk-SNARK giải quyết.

Định nghĩa của zk-SNARK

Một zk-SNARK bao gồm ba thuật toán G, P, V được định nghĩa như sau:

Trình tạo khóa G nhận tham số bí mật lambda và một chương trình C, đồng thời tạo ra hai khóa công khai, một khóa chứng minh pk và một khóa xác minh vk. Các khóa này là các tham số công khai chỉ cần được tạo một lần cho một chương trình C nhất định.

Câu tục ngữ P nhận đầu vào là khóa chứng minh pk, đầu vào công khai x và nhân chứng riêng w. Thuật toán tạo ra một bằng chứng prf = P (pk, x, w) rằng câu tục ngữ biết một nhân chứng w và nhân chứng đó thỏa mãn chương trình.

Trình xác minh V tính toán V (vk, x, prf) trả về true nếu bằng chứng là đúng và sai nếu ngược lại. Do đó, hàm này trả về true nếu câu tục ngữ biết một nhân chứng w thỏa mãn C (x, w) == true.

Lưu ý ở đây tham số bí mật lambda được sử dụng trong trình tạo. Thông số này đôi khi khiến việc sử dụng zk-SNARK trong các ứng dụng thực tế trở nên khó khăn. Lý do cho điều này là bất kỳ ai biết thông số này đều có thể tạo ra các bằng chứng giả. Cụ thể, với bất kỳ chương trình C nào và đầu vào công khai x, một người biết lambda có thể tạo ra một bằng chứng fake_prf sao cho V (vk, x, fake_prf) đánh giá là true mà không cần biết về bí mật w.

Do đó, việc chạy máy phát điện trên thực tế đòi hỏi một quy trình rất an toàn để đảm bảo không ai tìm hiểu và lưu tham số ở bất kỳ đâu. Đây là lý do cho nghi lễ cực kỳ công phu nhóm Zcash đã tiến hành để tạo khóa chứng minh và khóa xác minh, đồng thời đảm bảo thông số lambda “thải độc” đã bị phá hủy trong quá trình này.

A zk-SNARK cho chương trình ví dụ của chúng tôi

Alice và Bob sẽ sử dụng zk-SNARK trong thực tế như thế nào để Alice chứng minh rằng cô ấy biết giá trị bí mật trong ví dụ trên?

Trước hết, như đã thảo luận ở trên, chúng ta sẽ sử dụng một chương trình được định nghĩa bởi hàm sau:

hàm C (x, w) {return (sha256 (w) == x); } Ngôn ngữ mã: JavaScript (javascript)

Bước đầu tiên là Bob chạy trình tạo G để tạo khóa chứng minh pk và khóa xác minh vk. Đầu tiên, tạo ngẫu nhiên lambda và sử dụng nó làm đầu vào:

(pk, vk) = G (C, lambda)

Xử lý tham số lambda một cách cẩn thận, vì nếu Alice biết được giá trị của lambda, cô ấy sẽ có thể tạo ra các bằng chứng giả. Bob sẽ chia sẻ pk và vk với Alice.

Alice bây giờ sẽ đóng vai trò của câu châm ngôn. Cô ấy cần chứng minh rằng cô ấy biết giá trị s có giá trị băm cho hàm băm đã biết H. Cô ấy chạy thuật toán chứng minh P bằng cách sử dụng các đầu vào pk, H và s để tạo ra bằng chứng prf:

prf = P (pk, H, s)

Tiếp theo Alice trình bày prf bằng chứng cho Bob, người chạy hàm xác minh V (vk, H, prf) sẽ trả về true trong trường hợp này vì Alice đã biết đúng bí mật s. Bob có thể tự tin rằng Alice đã biết bí mật, nhưng Alice không cần tiết lộ bí mật cho Bob.

Chìa khóa xác minh và chứng minh có thể tái sử dụng

Trong ví dụ của chúng tôi ở trên, không thể sử dụng zk-SNARK nếu Bob muốn chứng minh với Alice rằng anh ấy biết một bí mật, vì Alice không thể biết rằng Bob không lưu tham số lambda. Bob hợp lý có thể giả mạo bằng chứng.

Nếu một chương trình hữu ích với nhiều người (như ví dụ về Zcash), một nhóm độc lập đáng tin cậy tách biệt với Alice và Bob có thể chạy trình tạo và tạo khóa chứng minh pk và khóa xác minh vk theo cách mà không ai biết về lambda.

Bất kỳ ai tin tưởng rằng nhóm không gian lận sau đó có thể sử dụng các khóa này cho các tương tác trong tương lai.

zk-SNARKs trong Ethereum

Các nhà phát triển đã bắt đầu tích hợp zk-SNARK vào Ethereum. điều này như thế nào? Cụ thể, bạn có thể thêm các khối xây dựng của thuật toán xác minh vào Ethereum dưới dạng hợp đồng được biên dịch trước. Dưới đây là cách thực hiện: chạy trình tạo ngoài chuỗi để tạo ra khóa chứng minh và khóa xác minh. Sau đó, bất kỳ câu tục ngữ nào cũng có thể sử dụng chìa khóa chứng minh để tạo ra một bằng chứng, cũng có thể không theo chuỗi. Sau đó, bạn có thể chạy thuật toán xác minh chung bên trong hợp đồng thông minh, sử dụng bằng chứng, khóa xác minh và đầu vào công khai làm tham số đầu vào. Sau đó, bạn có thể sử dụng kết quả của thuật toán xác minh để kích hoạt hoạt động trên chuỗi khác.

Ví dụ: Giao dịch bí mật

Dưới đây là một ví dụ đơn giản về cách zk-SNARK có thể giúp bảo mật trên Ethereum. Giả sử chúng ta có một hợp đồng mã thông báo đơn giản. Thông thường, một hợp đồng mã thông báo sẽ có cốt lõi của nó là ánh xạ từ địa chỉ đến số dư:

ánh xạ (địa chỉ => uint256) số dư; Ngôn ngữ mã: JavaScript (javascript)

Chúng tôi sẽ giữ lại cùng một lõi cơ bản, ngoại trừ thay thế một số dư bằng băm của một số dư:

ánh xạ (địa chỉ => bytes32) balanceHashing; Ngôn ngữ mã: JavaScript (javascript)

Chúng tôi sẽ không che giấu người gửi hoặc người nhận giao dịch. Nhưng chúng tôi sẽ ẩn số dư và số tiền đã gửi. Thuộc tính này đôi khi được gọi là giao dịch bí mật.

Chúng tôi sẽ sử dụng hai zk-SNARK để gửi mã thông báo từ tài khoản này sang tài khoản khác. Một bằng chứng được tạo bởi người gửi và một bằng chứng do người nhận.

Thông thường trong hợp đồng mã thông báo để giao dịch có giá trị quy mô hợp lệ, chúng tôi cần xác minh những điều sau:

số dư [fromAddress] >= giá trị

Các zk-SNARK của chúng tôi cần chứng minh rằng điều này được giữ nguyên, cũng như các băm được cập nhật khớp với số dư được cập nhật.

Ý tưởng chính là người gửi sẽ sử dụng số dư ban đầu của họ và giá trị giao dịch làm đầu vào riêng. Là đầu vào công khai, chúng sử dụng các hàm băm của số dư đầu kỳ, số dư cuối kỳ và giá trị. Tương tự, người nhận sẽ sử dụng số dư ban đầu và giá trị làm đầu vào bí mật. Là đầu vào công khai, chúng sử dụng các hàm băm của số dư đầu kỳ, số dư cuối kỳ và giá trị.

Dưới đây là chương trình chúng tôi sẽ sử dụng cho người gửi zk-SNARK, trong đó x đại diện cho đầu vào công khai và w đại diện cho đầu vào riêng tư.

function senderFunction (x, w) {return (w.senderBalanceBefore > w.value && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} Ngôn ngữ mã: JavaScript (javascript)

Chương trình được sử dụng bởi người nhận như sau:

function receiverFunction (x, w) {return (sha256 (w.value) == x.hashValue && sha256 (w.receiverBalanceBefore) == x.hashReceiverBalanceBefore && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} Ngôn ngữ mã: JavaScript (javascript)

Các chương trình kiểm tra xem số dư đang gửi có lớn hơn giá trị đang được gửi hay không, cũng như kiểm tra xem tất cả các hàm băm có khớp nhau hay không. Một nhóm người đáng tin cậy sẽ tạo ra các khóa chứng minh và xác minh cho zk-SNARK của chúng tôi. Hãy gọi chúng là confTxSenderPk, confTxSenderVk, confTxReceiverPk và confTxReceiverVk.

Sử dụng zk-SNARK trong hợp đồng mã thông báo sẽ trông giống như sau:

chuyển hàm (address _to, bytes32 hashValue, bytes32 hashSenderBalanceAfter, bytes32 hashReceiverBalanceAfter, byte zkProofSender, byte zkProofReceiver) {bytes32 hashSenderBalanceBefore = balanceHashing [msg.sender]; bytes32 hashReceiverBalanceBefore = balanceHashing [_to]; bool senderProofIsCorrect = zksnarkverify (confTxSenderVk, [hashSenderBalanceBefore, hashSenderBalanceAfter, hashValue], zkProofSender); bool receiverProofIsCorrect = zksnarkverify (confTxReceiverVk, [hashReceiverBalanceBefore, hashReceiverBalanceAfter, hashValue], zkProofReceiver); if (senderProofIsCorrect && receiverProofIsCorrect) {balanceHashing [msg.sender] = hashSenderBalanceAfter; balanceHashing [_to] = hashReceiverBalanceAfter; }} Ngôn ngữ mã: JavaScript (javascript)

Do đó, các cập nhật duy nhất trên blockchain là các băm của số dư chứ không phải bản thân số dư. Tuy nhiên, chúng tôi có thể biết rằng tất cả số dư đều được cập nhật chính xác vì chúng tôi có thể tự kiểm tra xem bằng chứng đã được xác minh chưa.

Chi tiết

Sơ đồ giao dịch bí mật ở trên chủ yếu là để đưa ra một ví dụ thực tế về cách người ta có thể sử dụng zk-SNARK trên Ethereum. Để tạo một kế hoạch giao dịch bí mật mạnh mẽ, chúng tôi cần giải quyết một số vấn đề:

  • Người dùng sẽ cần theo dõi số dư của họ ở phía khách hàng và nếu bạn mất số dư thì những mã thông báo đó sẽ không thể khôi phục được. Số dư có lẽ có thể được lưu trữ mã hóa trên chuỗi bằng một khóa bắt nguồn từ khóa ký.
  • Số dư cần sử dụng 32 byte dữ liệu và mã hóa entropy để ngăn khả năng đảo ngược hàm băm để tìm ra số dư.
  • Cần phải đối phó với trường hợp cạnh gửi đến một địa chỉ không sử dụng.
  • Người gửi cần phải tương tác với người nhận để gửi. Người ta có thể có một hệ thống trong đó người gửi sử dụng bằng chứng của họ để bắt đầu giao dịch. Sau đó, người nhận có thể thấy trên blockchain rằng họ có “giao dịch đến đang chờ xử lý” và có thể hoàn thành nó.

Bản tin Đăng ký nhận bản tin của chúng tôi để biết tin tức mới nhất về Ethereum, các giải pháp doanh nghiệp, tài nguyên dành cho nhà phát triển và hơn thế nữa.Làm thế nào để xây dựng một sản phẩm chuỗi khối thành côngHội thảo trên web

Làm thế nào để xây dựng một sản phẩm chuỗi khối thành công

Cách thiết lập và chạy Ethereum NodeHội thảo trên web

Cách thiết lập và chạy Ethereum Node

Cách xây dựng API Ethereum của riêng bạnHội thảo trên web

Cách xây dựng API Ethereum của riêng bạn

Cách tạo mã thông báo xã hộiHội thảo trên web

Cách tạo mã thông báo xã hội

Sử dụng các công cụ bảo mật trong phát triển hợp đồng thông minhHội thảo trên web

Sử dụng các công cụ bảo mật trong phát triển hợp đồng thông minh

Tương lai của tài sản kỹ thuật số tài chính và DeFiHội thảo trên web

Tương lai của tài chính: Tài sản kỹ thuật số và DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
map