paint-brush
Opside ZK-PoW V2.0: Mạng chứng minh phi tập trung đa chuỗi và nhiều cuộnby@opside
6,412
6,412

Opside ZK-PoW V2.0: Mạng chứng minh phi tập trung đa chuỗi và nhiều cuộn

Opside7m2023/07/06
Read on Terminal Reader

Opside là một nền tảng ZK-RaaS (ZK-Rollup as a Service) phi tập trung và là mạng hàng đầu để khai thác ZKP (Bằng chứng không kiến thức). Nó cung cấp dịch vụ một cú nhấp chuột để tạo Zk-Rollups cho bất kỳ ai. Opside cung cấp một cơ sở khởi chạy ZK.Rollup phổ quát, cho phép các nhà phát triển dễ dàng triển khai các loại ZK.-Rollup khác nhau trên các chuỗi cơ sở khác nhau.
featured image - Opside ZK-PoW V2.0: Mạng chứng minh phi tập trung đa chuỗi và nhiều cuộn
Opside HackerNoon profile picture
0-item


Giới thiệu ZK-PoW đối lập

Opside là một nền tảng ZK-RaaS (ZK-Rollup as a Service) phi tập trung và là mạng hàng đầu để khai thác ZKP (Bằng chứng không kiến thức). ZK-RaaS cung cấp dịch vụ một cú nhấp chuột để tạo ZK-Rollups cho bất kỳ ai. Opside cung cấp một cơ sở khởi chạy ZK-Rollup phổ quát, cho phép các nhà phát triển dễ dàng triển khai các loại ZK-Rollup khác nhau trên các chuỗi cơ sở khác nhau.


  • Chuỗi cơ sở: Chuỗi Ethereum/ Chuỗi Opside/ Chuỗi BNB/ Polygon PoS và các chuỗi công khai khác.
  • Các loại ZK-Rollup: zkSync, Polygon zkEVM, Scroll, StarkNet và các biến thể khác của ZK-Rollup.




Trong thiết kế của Opside, các nhà phát triển có thể triển khai ZK-Rollups trên các chuỗi cơ sở khác nhau này. Khi công nghệ ZK-Rollup hoàn thiện, có thể có hàng trăm hoặc thậm chí hàng nghìn ZK-Rollup trong tương lai, điều này sẽ tạo ra nhu cầu đáng kể về sức mạnh tính toán của ZKP. Opside sử dụng cơ chế ZK-PoW để khuyến khích các công cụ khai thác cung cấp sức mạnh tính toán ZKP, do đó cung cấp cơ sở hạ tầng phần cứng hoàn chỉnh cho ZK-Rollups.

Kiến trúc ZK-PoW V2.0

Kiến trúc tổng thể của ZK-PoW V2.0 bao gồm một số thành phần chính:


  1. Đám mây ZK-PoW: Đây là cơ sở hạ tầng đám mây do Opside cung cấp để tính toán ZKP. Nó được triển khai trên nhiều chuỗi, bao gồm Ethereum, BNB Chain, Polygon PoS và Opside Chain. Đám mây ZK-PoW chịu trách nhiệm điều phối và quản lý các tác vụ tính toán ZKP.


  2. Nút khai thác: Đây là các nút được vận hành bởi những người khai thác đóng góp sức mạnh tính toán của họ để thực hiện tính toán ZKP. Người khai thác có thể tham gia vào mạng ZK-PoW bằng cách chạy phần mềm chuyên dụng trên phần cứng khai thác của họ.


  3. Phân phối nhiệm vụ ZKP: Đám mây ZK-PoW phân phối các nhiệm vụ tính toán ZKP cho các nút khai thác. Việc phân phối được thực hiện theo phương thức phân quyền đảm bảo công bằng và hiệu quả. Các tác vụ ZKP bao gồm tạo và xác minh bằng chứng không có kiến thức cho các ZK-Rollup khác nhau.


  4. Tính toán ZKP: Các nút khai thác nhận các tác vụ tính toán ZKP và thực hiện các tính toán cần thiết để tạo ra các bằng chứng cần thiết. Điều này liên quan đến việc thực hiện các thuật toán mật mã và thực hiện các phép tính phức tạp.


  5. Gửi và xác minh bằng chứng: Sau khi hoàn thành tính toán ZKP, các nút khai thác sẽ gửi bằng chứng đã tạo tới Đám mây ZK-PoW để xác minh. Cơ sở hạ tầng đám mây xác minh tính chính xác của các bằng chứng để đảm bảo tính hợp lệ và tính toàn vẹn của chúng.


  6. Cơ chế khuyến khích: Những người khai thác được khuyến khích tham gia vào mạng ZK-PoW bằng cách kiếm phần thưởng cho những đóng góp tính toán của họ. Hệ thống phần thưởng được thiết kế để thúc đẩy những người khai thác và duy trì tính bảo mật và ổn định của mạng.


Nhìn chung, ZK-PoW V2.0 kết hợp sức mạnh của tài nguyên tính toán của thợ đào với cơ sở hạ tầng đám mây để cung cấp khả năng tính toán ZKP hiệu quả và có thể mở rộng cho nhiều loại ZK-Rollup.


Aggregator là một thành phần quan trọng của Prover trong hệ thống ZK-PoW V2.0. Nó chịu trách nhiệm phân phối các nhiệm vụ chứng minh ZKP, nhận kết quả nhiệm vụ (bằng chứng ZKP), quản lý các bằng chứng và gửi chúng đến Chuỗi cơ sở để kiếm phần thưởng. Dựa trên các chức năng của chúng, phiên bản mới của Trình tổng hợp được chia thành ba mô-đun phụ: Trình tạo bằng chứng, Trình quản lý bằng chứng và Người gửi bằng chứng.




  • Mô-đun Trình tạo bằng chứng chịu trách nhiệm gán các nhiệm vụ bằng chứng cho Prover (công cụ khai thác PoW), nhận kết quả nhiệm vụ (bằng chứng ZKP) và lưu trữ bằng chứng ZKP trong cơ sở dữ liệu DB.

  • Trình quản lý bằng chứng chịu trách nhiệm quản lý các bằng chứng ZKP đã hoàn thành và đóng gói các bằng chứng sẵn sàng để gửi trên chuỗi dưới dạng nhiệm vụ cho mô-đun Người gửi bằng chứng.

  • Mô-đun Người gửi Bằng chứng xử lý việc gửi bằng chứng ZKP trên chuỗi bằng cách gửi chúng đến hợp đồng zkEVM được triển khai trên Chuỗi cơ sở.


Dưới đây là phần giới thiệu của ba mô-đun này:

trình tạo bằng chứng

Chuỗi cuộn tổng hợp một số lượng giao dịch nhất định thành một đợt, sau đó nhiều đợt (dựa trên các yếu tố như tần suất giao dịch) được kết hợp thành một chuỗi. Trình tự sau đó được gửi đến Chuỗi cơ sở, làm cho nó trở thành đơn vị gửi dữ liệu cho mỗi hoạt động trên chuỗi. Mỗi chuỗi bao gồm một hoặc nhiều lô và bằng chứng ZKP xác minh tính hợp lệ của chuỗi đã gửi. Do đó, lô là đơn vị nhỏ nhất của nhiệm vụ chứng minh. Tùy thuộc vào số lô có trong một trình tự, các nhiệm vụ chứng minh được yêu cầu sẽ khác nhau như sau:


  • Nếu số lô là 1, quy trình kiểm chứng bao gồm BatchProofTask, sau đó là FinalProofTask và các tác vụ được hoàn thành tuần tự.

  • Nếu trình tự chứa nhiều hơn 1 đợt, quy trình kiểm chứng bao gồm nhiều BatchProofTask, AggregatorProofTask và FinalProofTask, đồng thời các tác vụ được hoàn thành tuần tự.


Để tối đa hóa hiệu quả của việc tạo bằng chứng và tăng phần thưởng khai thác cho những người khai thác PoW, chúng tôi đặt mục tiêu tạo ra các bằng chứng đồng thời. Điều này đạt được ở hai khía cạnh:


  • Việc tạo bằng chứng cho các trình tự khác nhau có thể được thực hiện đồng thời vì không có sự phụ thuộc vào ngữ cảnh hoặc trạng thái.

  • Trong cùng một trình tự, nhiều BatchProofTask có thể được thực thi đồng thời.


Cách tiếp cận này sử dụng tài nguyên tính toán của Provers hiệu quả hơn, dẫn đến việc tạo bằng chứng hiệu quả hơn.

quản lý bằng chứng

Mô-đun này chịu trách nhiệm chính trong việc quản lý bằng chứng ZKP và kiểm soát xác minh trên chuỗi của chúng. Nó bao gồm ba mô-đun chính:


  • submitPendingProof : Mô-đun này chỉ được thực thi một lần khi Trình tổng hợp khởi động. Mục đích của nó là để hoàn thành việc gửi bằng chứng ZKP chưa hoàn thành từ dịch vụ Tổng hợp trước đó. Điều này xử lý tình huống trong đó proofHash đã được gửi nhưng những người khai thác khác đã gửi bằng chứng của họ. Để biết thêm thông tin về proofHash, vui lòng tham khảo mô-đun Người gửi Bằng chứng.
  • tryFetchProofToSend : Mô-đun này chạy dưới dạng coroutine và thêm bằng chứng ZKP được tạo mới nhất, cùng với trình tự chưa được xác minh tương ứng của nó, vào bộ đệm của Người gửi bằng chứng, chờ gửi trên chuỗi.
  • processResend : Mô-đun này chạy như một quy trình đăng ký và nhằm mục đích gửi lại các chuỗi chưa được xác minh thành công trong một khoảng thời gian nhất định. Mục đích của nó là để đảm bảo rằng các chuỗi vượt quá thời gian xác minh sẽ được gửi lại để xử lý trên chuỗi.

người gửi bằng chứng

Opside đã đề xuất thuật toán gửi ZKP hai bước để đạt được sự phân cấp của người chứng thực. Thuật toán này ngăn chặn các cuộc tấn công chạy trước của ZKP và cho phép nhiều người khai thác hơn nhận được phần thưởng, từ đó khuyến khích nhiều người khai thác tham gia hơn và cung cấp sức mạnh tính toán ZKP ổn định và liên tục.


  • Bước 1 : Khi tạo bằng chứng PoW cho một chuỗi cụ thể (được gọi là bằng chứng), trước tiên người chứng minh sẽ tính toán hàm băm của "bằng chứng / địa chỉ" và gửi nó cho hợp đồng. Nếu không có proofHash nào được gửi cho trình tự đó trước đó, cửa sổ thời gian gửi proofHash, T1, sẽ được mở. Những người khai thác đủ điều kiện để gửi trình tự trong các khối T1 và bằng chứng chỉ có thể được gửi sau các khối T1.


  • Bước 2 : Sau các khối T1, cửa sổ gửi bằng chứng được mở cho các khối T2. Nếu không có bằng chứng nào được gửi vượt qua xác minh trong các khối T2, thì tất cả những người khai thác đã gửi bằng chứng trước đó sẽ bị phạt. Nếu proofHash được gửi thành công trong cửa sổ thời gian T1 nhưng bằng chứng không thể được gửi thành công trong cửa sổ thời gian T2 và những người khai thác khác đã gửi thành công bằng chứng của họ trong cửa sổ T2, thì người chứng minh vẫn có thể tiếp tục gửi bằng chứng đó. Trong các trường hợp khác, quy trình gửi hai bước được khởi động lại.


Sơ đồ sau đây minh họa cách Người gửi Bằng chứng thực hiện quy trình gửi hai bước bằng cách sử dụng ba bộ nhớ đệm được sắp xếp theo mức độ ưu tiên và an toàn cho luồng. Các bộ đệm này được sắp xếp dựa trên chiều cao bắt đầu của chuỗi, đảm bảo rằng mỗi khi một phần tử được truy xuất từ các bộ đệm này, nó sẽ tương ứng với chiều cao chuỗi thấp nhất. Ngoài ra, các phần tử trong các bộ nhớ cache này được loại bỏ trùng lặp. Chiều cao của chuỗi tương ứng càng thấp thì ưu tiên xử lý càng cao.


  • finalProofMsgCache: Lưu trữ các tin nhắn finalProof do Trình quản lý Bằng chứng gửi, cho biết việc hoàn thành các bằng chứng ZKP.
  • monitPHTxCache: Lưu trữ các giao dịch proofHash sẽ được theo dõi.
  • ProofHashCache: Lưu trữ các thông báo bằng chứng để gửi trên chuỗi.



Sau khi mô-đun Người gửi Bằng chứng được khởi chạy, ba coroutine sẽ bắt đầu sử dụng dữ liệu từ ba bộ đệm. Quá trình đơn giản hóa như sau:


  1. Coroutine 1 sử dụng các thông báo finalProof từ finalProofMsgCache, tính toán bằng chứng và nếu nó đáp ứng các điều kiện để gửi trên chuỗi (trong cửa sổ T1), nó sẽ gửi bằng chứng đến chuỗi và thêm giao dịch bằng chứng vào monitPHTxCache.

  2. Coroutine 2 sử dụng các thông báo giao dịch proofHash từ monitPHTxCache. Nếu proofHash đáp ứng các điều kiện để gửi trên chuỗi trong cửa sổ T2, nó sẽ tạo thông báo bằng chứng và lưu trữ nó trong ProofHashCache.

  3. Coroutine 3 sử dụng các thông báo bằng chứng từ ProofHashCache và gửi bằng chứng đến chuỗi.


So với mô-đun trước, cấu trúc này rõ ràng hơn và tiết kiệm chi phí tài nguyên.

Bản tóm tắt

So sánh với Phiên bản 1.0


  • Phiên bản 2.0 chia dịch vụ ban đầu thành ba mô-đun phụ, mỗi mô-đun chịu trách nhiệm tạo bằng chứng, quản lý bằng chứng và gửi bằng chứng, dẫn đến cấu trúc rõ ràng hơn, khớp nối thấp hơn và độ bền cao hơn.
  • Mô-đun tạo bằng chứng, Proof Generator, đã thêm tham số startBatch so với phiên bản cũ, giúp những người khai thác mới dễ dàng bắt kịp tiến độ khai thác hơn.
  • Mô-đun quản lý bằng chứng Proof Manager được cải tiến so với phiên bản cũ. Nó nhanh chóng gửi lại bằng chứng trong trường hợp khởi động lại dịch vụ khai thác hoặc các lý do khác khiến việc gửi bằng chứng không thành công, đảm bảo quyền lợi của người khai thác. Cơ chế gửi lại không chỉ giải quyết các trường hợp gửi bằng chứng không thành công mà còn xử lý tất cả các trường hợp gửi bằng chứng không thành công hoặc không gửi, đảm bảo tính bảo mật của Chuỗi tổng số.
  • Mô-đun gửi bằng chứng, Người gửi Bằng chứng, thực hiện gửi giao dịch hai bước bằng cách sử dụng ba bộ đệm ưu tiên an toàn cho luồng. Nó giảm việc sử dụng khóa toàn cầu so với các phiên bản trước, đảm bảo rằng các bằng chứng có độ cao thấp hơn được gửi kịp thời và bảo vệ lợi ích của người khai thác. Ngoài ra, luồng dịch vụ tổng thể rõ ràng hơn, với số lượng luồng giảm và mức tiêu thụ tài nguyên giảm trong quá trình thực thi chương trình.


Kết quả kiểm tra căng thẳng:


  • Trong Phiên bản 2.0, sử dụng 10 máy với 64 lõi mỗi máy, 566 bản in thử hàng loạt đã được hoàn thành trong 7 giờ, 38 phút và 40 giây, với thời gian trung bình là 48,62 giây cho mỗi bản in thử. Trong kịch bản nhiều người khai thác, so với Phiên bản 1.0, hiệu quả của việc tạo bằng chứng zk trong Phiên bản 2.0 đã cải thiện tổng thể 50%.


Tóm lại, Opside ZK-PoW V2.0 đã tối ưu hóa quy trình có nhiều thợ đào tham gia tính toán ZKP, cải thiện việc sử dụng phần cứng, nâng cao tính khả dụng của dịch vụ và thân thiện với thợ đào hơn. Điều quan trọng là trong kịch bản nhiều người khai thác, thời gian tính toán cho ZKP đã giảm xuống còn chưa đầy một phút, giúp tăng tốc đáng kể thời gian xác nhận các giao dịch ZK-Rollup.