Mặt khác ZK-PoW V2.0: Hỗ trợ khai thác ZKP đa chuỗi và đa cuộn

1.Giới thiệu về Opside ZK-PoW

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

Chuỗi cơ sở, bao gồm 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, bao gồm zkSync, Polygon zkEVM, Scroll, StarkNet và các loại zkEVM khác, cũng như các loại ZK-Rollups khác.

Opside ZK-PoW Cloud sẽ được triển khai trên nhiều chuỗi, bao gồm nhưng không giới hạn ở Ethereum, Chuỗi BNB, Polygon PoS và chính Opside Chain. 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 được đề cập ở trên. Khi công nghệ ZK-Rollup dần trưởng thành, hàng trăm hoặc hàng nghìn ZK-Rollup có thể ra đời trong tương lai, điều này sẽ mang đến nhu cầu lớn về sức mạnh tính toán ZKP. Opside sử dụng cơ chế ZK-PoW để khuyến khích Thợ mỏ cung cấp sức mạnh tính toán ZKP, từ đó cung cấp cơ sở phần cứng hoàn chỉnh cho ZK-Rollup.

2. Kiến trúc tổng thể của ZK-PoW V2.0

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

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

Các nút khai thác: Đây là các nút được vận hành bởi các thợ mỏ đóng góp sức mạnh tính toán của họ để thực hiện các phép tính 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ọ.

Phân phối nhiệm vụ ZKP: ZK-PoW Cloud phân phối các nhiệm vụ điện toán ZKP cho các nút khai thác. Việc phân phối được thực hiện theo cách phi tập trung để đảm bảo tính công bằng và hiệu quả. Nhiệm 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.

Tính toán ZKP: Các nút khai thác nhận nhiệm vụ tính toán ZKP và thực hiện các phép tính cần thiết để tạo ra 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ã hóa và thực hiện các phép tính phức tạp.

Gửi bằng chứng và xác minh: Sau khi quá trình tính toán ZKP hoàn tất, nút khai thác sẽ gửi bằng chứng được 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 chứng thực để đảm bảo tính hợp lệ và đầy đủ của nó.

Cơ chế khuyến khích: Người khai thác được khuyến khích tham gia vào mạng ZK-PoW bằng cách nhận 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ế để khuyến khích người khai thác và duy trì tính bảo mật và ổn định của mạng.

Nói chung, ZK-PoW V2.0 kết hợp tài nguyên điện toán của thợ mỏ với cơ sở hạ tầng đám mây để cung cấp các giải pháp hiệu quả và đáng tin cậy cho nhiều ZK-Rollup khác nhau. .

Aggregator là một mô-đun thành phần quan trọng của Prover, chịu trách nhiệm phân phối các nhiệm vụ chứng minh ZKP và nhận kết quả nhiệm vụ, cụ thể là chứng minh ZKP, quản lý chứng minh ZKP và gửi chứng minh ZKP vào Chuỗi cơ sở. Nhận phần thưởng cho việc này. Do đó, phiên bản mới của Bộ tổng hợp được chia thành ba mô-đun phụ dựa trên các chức năng: 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.

Như thể hiện trong hộp chấm ở hình trên, mô-đun Proof Generator sẽ chịu trách nhiệm đưa ra các nhiệm vụ bằng chứng cho người khai thác (máy khai thác PoW) và chấp nhận kết quả của nhiệm vụ: bằng chứng ZKP, sau đó lưu bằng chứng ZKP vào cơ sở dữ liệu DB. Người quản lý bằng chứng chịu trách nhiệm quản lý bằng chứng ZKP đã hoàn thành và đóng gói bằng chứng ZKP để tải lên tác vụ gửi và chuyển nó đến Người gửi bằng chứng mô-đun. Người gửi bằng chứng mô-đun hoàn thành bằng chứng ZKP trên chuỗi, nghĩa là gửi bằng chứng cho hợp đồng zkevm được triển khai trên Chuỗi cơ sở.

Ba mô-đun được giới thiệu dưới đây:

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

Chuỗi cuộn lên đóng gói một số lượng giao dịch nhất định thành một lô, sau đó đóng gói nhiều lô (dựa trên nhiều yếu tố như tần suất giao dịch) thành một chuỗi và sau đó gửi nó đến Chuỗi cơ sở, vì vậy chúng tôi có thể nói đơn vị dữ liệu được tải lên mỗi lần là tuần tự. Mỗi chuỗi bao gồm nhiều hơn 1 lô và bằng chứng ZKP là để chứng minh tính hợp pháp của chuỗi được gửi, vì vậy lô là đơn vị nhỏ nhất của nhiệm vụ chứng minh.

Tùy thuộc vào các lô có trong trình tự, các nhiệm vụ chứng minh cần hoàn thành cũng khác nhau, như sau:

Số lượng lô bằng 1 và quy trình chứng minh BatchProofTask ----> FinalProofTask cần được hoàn thành theo trình tự các tác vụ chứng minh BatchProofTask, FinalProofTask.

Chuỗi chứa số lô lớn hơn 1, chứng tỏ rằng quy trình có nhiều BatchProofTask ---->AggregatorproofTask ---> FinalProofTask và nhiều Nhiệm vụ BatchProofTask cần phải được hoàn thành theo trình tự. Nhiệm vụ chứng minh AggregatorproofTask, FinalProofTask.

Để tăng hiệu quả tạo bằng chứng càng nhiều càng tốt và tăng thu nhập của những người khai thác PoW, chúng tôi tạo ra bằng chứng song song nhiều nhất có thể. Điều này được phản ánh cụ thể ở hai khía cạnh sau:

Mỗi trình tự chứng minh rằng việc tạo không có sự phụ thuộc vào bối cảnh hoặc trạng thái và có thể được thực hiện đồng thời.

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

Bằng cách này, nguồn sức mạnh tính toán của người chứng minh có thể được sử dụng tốt hơn, do đó có thể tạo ra bằng chứng hiệu quả hơn.

Trình 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ý các chứng chỉ ZKP và kiểm soát hoạt động trên xác minh chuỗi chứng chỉ ZKP. . Chủ yếu được chia thành ba mô-đun

submitPendingProof: Mô-đun này chỉ được thực thi một lần mỗi khi Aggregator khởi động, mục đích là hoàn thành ZKP chưa được hoàn thành trước lần cuối cùng dịch vụ Tổng hợp đã bị ngừng. Chứng minh việc gửi đã hoàn tất. Điều này dành cho trường hợp proofHash được gửi và những người khai thác khác gửi bằng chứng. Để biết phần giới thiệu về proofHash và bằng chứng, vui lòng tham khảo Người gửi bằng chứng.

tryFetchProofToSend: Khi coroutine được thực thi, hãy thêm bằng chứng ZKP được tạo mới nhất và trình tự tương ứng với bằng chứng chưa được xác minh vào bộ đệm của Người gửi bằng chứng và đợi nó thực hiện được tải lên chuỗi.

processResend: được thực thi trong coroutine, mục đích là gửi lại trình tự chưa được xác minh thành công sau khoảng thời gian và được tải lên chuỗi.

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

Opside đã đề xuất thuật toán gửi hai bước ZKP để triển khai bằng chứng về phân cấp . Thuật toán này không chỉ có thể ngăn chặn các cuộc tấn công chạy trước ZKP mà còn 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 hơn trực tuyến và cung cấp sức mạnh tính toán ZKP ổn định và liên tục.

Bước 1: Đối với một trình tự nhất định, tạo bằng chứng PoW và ghi lại làm bằng chứng. Đầu tiên hãy tính Hash (bằng chứng/địa chỉ), ghi lại dưới dạng proofHash, và gửi nó vào hợp đồng. Nếu trình tự chưa gửi proofHash trước đó, thì cửa sổ thời gian gửi proofHash T1 sẽ mở. Người khai thác sẽ đủ đ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 khối T1.

Bước 2: Gửi bằng chứng. Sau khối T1, việc gửi bằng chứng được kích hoạt và việc gửi bị giới hạn ở các khối T2. Nếu sau khối T2, tất cả các thợ mỏ gửi bằng chứng nhưng không vượt qua được xác minh, thì tất cả những người khai thác đã gửi proofHash trước đó sẽ bị trừng phạt. Nếu proofHash có thể đượ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 bằng chứng thành công trong cửa sổ T2, bạn vẫn có thể tiếp tục gửi bằng chứng. Ngoài các tình huống trên, hãy thực hiện lại quy trình gửi hai bước.

Như được hiển thị bên dưới, Người gửi bằng chứng thực hiện gửi hai bước dựa trên ba bộ đệm được sắp xếp theo mức độ ưu tiên và an toàn theo luồng. Ba 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 chiều cao chuỗi tương ứng với các phần tử thu được từ ba bộ đệm này luôn ở mức thấp nhất và các phần tử trong ba bộ đệm này sẽ được loại bỏ trùng lặp. Chiều cao của chuỗi tương ứng càng thấp thì càng cần xử lý mức độ ưu tiên.

finalProofMsgCahce: lưu trữ thông báo Bằng chứng cuối cùng được gửi bởi Người quản lý Bằng chứng, thông báo này hoàn thành bằng chứng ZKP.

monitPHTxCache: Bộ lưu trữ để giám sát các giao dịch proofHash.

ProofHashCache: lưu trữ các thông báo bằng chứng cho bằng chứng trên chuỗi.

Như được hiển thị bên dưới:

Sau khi mô-đun Proof Sender được khởi động, nó sẽ khởi động ba coroutine để sử dụng ba dữ liệu được lưu trong bộ nhớ đệm này tương ứng .

Quy trình đơn giản là:

1. Coroutine 1 chịu trách nhiệm xử lý thông báo Proof cuối cùng trong FinalProofMsgCahce , tính proofHash và nếu nó đáp ứng các điều kiện trên chuỗi (trong điều kiện T1), sau đó tải proofHash lên chuỗi và đặt giao dịch proofHash vào monitPHTxCache.

2. Coroutine 2 sử dụng thông báo giao dịch proofHash của monitPHTxCache. Nếu điều kiện bằng chứng trên chuỗi được đáp ứng trong khung thời gian T2, thông báo bằng chứng sẽ được xây dựng và được lưu trữ trong ProofHashCache. .

3. Coroutine 3 sử dụng thông báo bằng chứng và bằng chứng được tải lên chuỗi.

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

3. Tóm tắt

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

V2.0 chia dịch vụ ban đầu thành ba mô-đun phụ. Ba mô-đun này lần lượt chịu trách nhiệm tạo bằng chứng, quản lý bằng chứng và bằng chứng trên chuỗi. rõ ràng hơn.Mỗi mô-đun có khả năng ghép thấp và độ bền cao.

So với phiên bản cũ, mô-đun tạo bằng chứng Proof Generator bổ sung tham số startBatch để tạo điều kiện cho những người khai thác mới theo kịp tiến độ khai thác nhanh hơn.

Mô-đun quản lý bằng chứng Proof Manager tốt hơn và cải tiến hơn phiên bản cũ: nếu bằng chứng không được gửi hoặc không gửi được do người khai thác khởi động lại dịch vụ hoặc vì lý do khác, bằng chứng sẽ được phát hành lại trong thời gian sớm nhất. Đảm bảo lợi ích của người khai thác, đồng thời, cơ chế gửi lại không chỉ nhắm mục tiêu đến việc gửi bằng chứng không thành công mà còn nhắm mục tiêu khoảng thời gian khởi động lại cho tất cả các lần gửi bằng chứng không thành công hoặc không gửi được để đảm bảo tính bảo mật của Chuỗi Rollup.

Mô-đun gửi bằng chứng Proof Sender thực hiện gửi giao dịch hai bước dựa trên ba bộ đệm ưu tiên an toàn theo luồng. So với phiên bản trước, nó giảm việc sử dụng khóa toàn cầu và đảm bảo rằng bằng chứng chiều cao thấp có thể được gửi ngay lập tức để đảm bảo lợi ích của người khai thác. Đồng thời, toàn bộ quy trình dịch vụ rõ ràng hơn, giảm số lượng luồng và giảm mức tiêu thụ tài nguyên trong quá trình thực thi chương trình.

Kết quả stress test:

Phiên bản 2.0 sử dụng 10 máy 64 lõi để hoàn thành đợt Có 566 bản chứng minh và phải mất 7 giờ, 38 phút và 40 giây để hoàn thành một bản chứng minh, trung bình là 48,62 giây. Trong kịch bản nhiều công cụ khai thác, so với V1.0, hiệu suất tạo bằng chứng zk của V2.0 đã được 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 để nhiều thợ mỏ tham gia tính toán ZKP, cải thiện việc sử dụng phần cứng, cải thiện tính khả dụng của dịch vụ và thân thiện hơn với các thợ mỏ. Quan trọng hơn, trong kịch bản nhiều thợ mỏ, việc tính toán ZKP được rút ngắn 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ủa ZK-Rollup.

Bài viết này là từ một bài gửi và không thể hiện quan điểm của BlockBeats

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