;

Opside ZK-PoW V2.0: Prover Network Phi tập Trung Multi-chain và Multi-Rollup

Kiến Thức

Posted by Huynh Duc - 04/08/2023

CryptoViet Info

    MỤC LỤC

Giới thiệu

Opside là một nền tảng phi tập trung ZK-RaaS (ZK-Rollup as a Service) và mạng lưới hàng đầu cho việc mining ZKP (Zero-Knowledge Proof). ZK-RaaS cung cấp dịch vụ one-click service để tạo ra ZK-Rollups cho bất kỳ ai. Opside cung cấp một nền tảng ZK-Rollup phổ quát, cho phép 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.

  • Base chains (Các chuỗi cơ sở): Ethereum/Opside chain/BNB chain/Polygon PoS và các public chain khác. 
  • Các loại ZK-Rollup: zkSync, Polygon zkEVM, Scroll, StarkNet và các biến thể khác của ZK-Rollups.
Opside Chain
Opside Chain

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

Khối 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:

  • ZK-PoW Cloud: Đây là cơ sở hạ tầng đám mây được 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. ZK-PoW Cloud chịu trách nhiệm điều phối và quản lý các nhiệm vụ tính toán ZKP.
  • Miner Nodes: Đây là các nút do các thợ đào vận hành, đóng góp sức mạnh tính toán của họ để thực hiện các tính toán ZKP. Các thợ đào 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 mining của họ.
  • ZKP Task Distribution: ZK-PoW Cloud phân phối các nhiệm vụ tính toán ZKP cho các thợ đào node. Việc phân phối được thực hiện theo cách phi tập trung để đảm bảo sự công bằng và hiệu quả. Các nhiệm vụ ZKP bao gồm việc tạo ra và xác minh zero-knowledge proofs cho các ZK-Rollup khác nhau.
  • ZKP Computation: Các miner nodes nhận các nhiệm 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 yêu cầu. Điều này bao gồm thực thi các thuật toán mật mã và thực hiện các phép tính phức tạp.
  • Proof Submission and Verification: Sau khi việc tính toán ZKP hoàn thành, các miner node gửi các bằng chứng đã tạo ra đến ZK-PoW Cloud cho việc 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.
  • Incentive Mechanism (Cơ chế Khuyến khích): Các thợ đào được khuyến khích tham gia vào mạng ZK-PoW bằng cách nhận phần thưởng cho đóng góp tính toán của họ. Hệ thống phần thưởng được thiết kế để thúc đẩy các thợ đào 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 các thợ đào với cơ sở hạ tầng đám mây để cung cấp tính toán ZKP hiệu quả và có khả năng mở rộng cho nhiều loại ZK-Rollups khác nhau.

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ụ (ZKP Proofs), quản lý các bằng chứng và gửi chúng lên Base Chain (Chuỗi Cơ Sở) để nhận phần thưởng. Dựa trên chức năng của mình, phiên bản mới của Aggregator được chia thành ba phân mô-đun con: Proof Generator, Proof Manager và Proof Sender.

Aggregator của Opside Chain
Aggregator của Opside Chain
  • Mô-đun Proof Generator có trách nhiệm giao nhiệm vụ chứng minh cho Prover (thợ mỏ PoW), nhận kết quả nhiệm vụ ( ZKP Proofs) và lưu trữ các bằng chứng ZKP trong DB database.
  • Proof Manager đảm nhiệm quản lý các ZKP proofs đã hoàn thành và đóng gói các bằng chứng đã sẵn sàng để nộp lên chuỗi dưới dạng nhiệm vụ cho mô-đun Proof Sender.
  • Mô-đun Proof Sender xử lý việc nộp các bằng chứng ZKP lên chuỗi bằng cách gửi chúng vào hợp đồng zkEVM được triển khai trên Base Chain (Chuỗi Cơ sở).

Dưới đây là mô tả về ba mô-đun:

Proof Generator

Rollup Chain tổng hợp một số giao dịch cụ thể thành một batch, sau đó nhiều batch (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 sequence. Sequence sau đó được gửi lên Base Chain, làm cho nó trở thành đơn vị nộp dữ liệu cho mỗi hoạt động on-chain. 

Mỗi sequence bao gồm một hoặc nhiều batch, và ZKP proof xác minh tính hợp lệ của sequence đã được nộp. Do đó, batch là đơn vị nhỏ nhất của nhiệm vụ chứng minh (proof task). Tùy thuộc vào số lượng batch bao gồm trong một sequence, nhiệm vụ chứng minh sẽ thay đổi như sau:

  • Nếu số lượng batch là 1, quá trình chứng minh bao gồm BatchProofTask theo sau là FinalProofTask, và các nhiệm vụ được hoàn thành theo thứ tự.
  • Nếu sequence chứa nhiều hơn 1 batch, quá trình chứng minh bao gồm nhiều BatchProofTasks, AggregatorProofTask và FinalProofTask, và các nhiệm vụ được hoàn thành theo thứ tự.

Nhằm tối đa hóa hiệu suất của việc tạo bằng chứng và tăng cường phần thưởng đào cho các thợ đào PoW, các bằng chứng đồng thời sẽ được thực hiện trong hai khía cạnh:

  • Tạo bằng chứng cho các sequence khác nhau có thể được thực hiện đồng thời vì không có sự phụ thuộc ngữ cảnh hoặc trạng thái.
  • Trong cùng một sequence, nhiều BatchProofTasks có thể được thực thi đồng thời.

Phương pháp này tận dụng tài nguyên tính toán của Provers một cách hiệu quả hơn, từ đó đạt được hiệu quả cao hơn trong việc tạo bằng chứng.

Proof Manager

Module này chịu trách nhiệm chủ yếu về việc quản lý các ZKP proof và kiểm soát việc xác minh on-chain của chúng. Bao gồm ba mô-đun chính:

  • submitPendingProof: Mô-đun này chỉ được thực thi một lần khi Aggregator bắt đầu. Mục đích của nó là hoàn thành việc nộp các bằng chứng ZKP chưa hoàn thành từ Aggregator service trước đó. Điều này xử lý tình huống proofHash được nộp nhưng các thợ đào khác đã nộp bằng chứng của họ trước đó.
  • tryFetchProofToSend: Mô-đun này chạy như một luồng coroutine và thêm ZKP proof mới nhất, cùng với sequence tương ứng chưa được xác minh vào bộ nhớ cache của Proof Sender đang chờ on-chain submission.
  • processResend: Mô-đun này chạy như một luồng coroutine và nhằm mục đích gửi lại các sequence 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 sequence vượt quá thời gian xác minh sẽ được gửi lại để xử lý on-chain.

Proof Sender

Opside đã đề xuất một thuật toán Two-step ZKP Submission nhằm đạt được sự phi tập trung của Prover. Thuật toán này ngăn chặn các cuộc tấn công front-running ZKP và cho phép nhiều thợ đào hơn nhận được phần thưởng, từ đó khuyến khích nhiều thợ đào tham gia 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 một bằng chứng PoW cho một sequence cụ thể (hay còn gọi là proof), Prover trước tiên tính toán hash của "proof/address" và gửi nó đến hợp đồng. Nếu chưa có proofHash nào được nộp cho chuỗi đó trước đó, T1 - một cửa sổ proofHash submission time được mở. Thợ đào có đủ điều kiện để nộp sequence trong T1 Blocks và chỉ có thể nộp bằng chứng sau T1 Blocks.
  • Bước 2: Sau T1 Blocks, proof submission window được mở trong T2 Blocks. Nếu không có bằng chứng nào được submit vượt qua sự xác minh trong T2 Blocks, tất cả các thợ đào đã từng nộp proofHash sẽ bị phạt. Nếu proofHash được nộp thành công trong T1 Time Window nhưng không thể nộp bằng chứng thành công trong T2 Time Window, và các thợ đào khác nộp thành công bằng chứng của họ trong T2 Time Window, Prover vẫn có thể tiếp tục nộp bằng chứng đó. Trong các tình huống khác, quá trình Two-step Submission này sẽ được khởi đầu lại.

Sơ đồ dưới đây mô tả cách Proof Sender thực hiện Two-step Submission bằng cách sử dụng ba bộ nhớ cache có độ ưu tiên (priority-sorted) và bảo mật luồng (thread-safe). Các cache này được sắp xếp theo độ cao bắt đầu của các sequence, đảm bảo rằng mỗi khi một phần tử được truy xuất từ các cache này, nó tương ứng với sequence với độ cao thấp nhất. Ngoài ra, các phần tử trong các cache này được loại bỏ trùng lặp. Độ cao của sequence tương ứng càng thấp, độ ưu tiên cho việc xử lý càng cao.

  • finalProofMsgCache: Lưu trữ các finalProof message được gửi bởi Proof Manager, chỉ ra việc hoàn thành các ZKP proof.
  • monitPHTxCache: Lưu trữ các giao dịch proofHash để được giám sát.
  • ProofHashCache: Lưu trữ các proof message cho on-chain submission.
FinalProofMsg từ Manage Proof
FinalProofMsg từ Manage Proof

Sau khi mô-đun Proof Sender được khởi chạy, ba luồng coroutine được bắt đầu để tiêu thụ dữ liệu từ ba bộ nhớ cache. Quá trình đơn giản được mô tả như sau:

  • Luồng coroutine 1 tiêu thụ các tin nhắn finalProof từ finalProofMsgCache, tính toán proofHash và nếu nó đáp ứng điều kiện cho on-chain submission (bên trong T1 Window), nó gửi proofHash lên chain và thêm giao dịch proofHash vào monitPHTxCache.
  • Luồng coroutine 2 tiêu thụ các tin nhắn giao dịch proofHash từ monitPHTxCache. Nếu proofHash đáp ứng điều kiện cho on-chain submission trong T2 Window, nó xây dựng nên proof message và lưu trữ nó trong ProofHashCache.
  • Luồng coroutine 3 tiêu thụ các tin nhắn proof từ ProofHashCache và nộp các bằng chứng đó lên chain.

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.

Tóm tắt sơ bộ

So với Phiên bản 1.0:

  • Phiên bản 2.0 chia dịch vụ ban đầu thành ba phân mô-đun con, mỗi phân mô-đun chịu trách nhiệm về việc tạo proof, quản lý proof và submit proof, từ đó dẫn đến cấu trúc rõ ràng hơn, mức độ kết nối thấp hơn và tính chắc chắn mạnh hơn.
  • Mô-đun tạo proof - Proof Generator đã thêm tham số startBatch so với phiên bản cũ, giúp cho các thợ đào mới dễ dàng bắt kịp tiến độ đào.
  • Mô-đun quản lý proof - Proof Manager đã được cải tiến so với phiên bản cũ. Nó gửi lại các proof nhanh chóng trong trường hợp dịch vụ của thợ đào khởi động lại hoặc do các nguyên nhân khác gây ra sự cố khi submit proof, đảm bảo lợi ích cho các thợ đào. Cơ chế Resend không chỉ giải quyết các trường hợp fail khi nộp proof mà còn xử lý tất cả các trường hợp fail hoặc không submit proof, đảm bảo tính bảo mật của Rollup Chain.
  • Mô-đun submit proof - Proof Sender thực hiện quá trình Two-step transaction Submission bằng cách sử dụng ba bộ nhớ cache thread-safe priority. So với các phiên bản trước đây, nó giảm sự sử dụng Global Locks, đảm bảo rằng các proof có độ cao thấp được nộp kịp thời và bảo vệ lợi ích của các thợ đào. Ngoài ra, luồng dịch vụ tổng thể rõ ràng hơn, với số luồng giảm và lượng tài nguyên tiêu thụ giảm trong quá trình thực thi chương trình.

Kết quả thử nghiệm:

  • Trong Phiên bản 2.0, việc sử dụng 10 máy với mỗi máy có 64 core đã hoàn thành 566 batch proof 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 proof. Trong kịch bản có nhiều thợ đào, so với Phiên bản 1.0, hiệu suất tạo ZK proof trong Phiên bản 2.0 đã tăng 50% so với tổng thể tổng thể.

Lời kết

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

Vậy là bạn đã tìm hiểu xong bài viết Opside ZK-PoW V2.0: Prover Network Phi tập Trung Multi-chain và Multi-Rollup. CryptoViet Info hy vọng bài viết sẽ cung cấp cho bạn những thông tin hữu ích nhất.

DISCLAIMER: Thông tin trên trang web này chỉ được cung cấp cho mục đích thông tin và không đại diện cho lời khuyên đầu tư. Để đưa ra quyết định đầu tư, chúng tôi khuyên bạn nên tự nghiên cứu.

Có thể bạn sẽ quan tâm

Recent PostPopular Post
Categories
Follow Us
CryptoViet Info
CryptoViet Info
CryptoViet Info
CryptoViet Info
CryptoViet Info
CryptoViet Info
CryptoViet Info
CryptoViet Info
CryptoViet Info
©2017 CryptoViet Info. All Rights ReservedMedia Kit