Tiêu đề gốc: "So sánh các zkEVM"

Tác giả: Daniel Lubarov

Biên soạn: Kxp, BlockBeats

Khi "cuộc chiến zkEVM" nóng lên, đã có rất nhiều cuộc thảo luận công khai về giá trị của các zkEVM khác nhau. Nhưng cũng có một số thông tin sai lệch, vì vậy chúng tôi muốn làm rõ một số sự thật về Polygon zkEVM và cách nó so sánh với các dự án khác.

Là một nhân viên của Polygon, tôi có thành kiến, nhưng tôi sẽ cố gắng tương đối không thiên vị. Tôi chủ yếu tập trung vào Kỷ nguyên zkEVM và zkSync của Polygon, vì chúng đã được đưa vào sử dụng sản xuất và tôi không biết nhiều về các dự án zkEVM khác.

zkEVM và prover của zkSync bao gồm hơn 100 nghìn dòng mã. Tôi đã cố gắng hết sức để cung cấp một bản tóm tắt chính xác, nếu có bất kỳ điểm nào không chính xác, vui lòng cho tôi biết và tôi sẽ sửa chúng.

Khả năng tương thích EVM

Đa giác zkEVM thực thi trực tiếp mã byte EVM. Theo phân loại của Vitalik, nó là zkEVM loại 3. Chẳng bao lâu nữa nó sẽ là loại 2; hiện tại chúng tôi đang thiếu bốn bản tiền biên dịch. Scroll cũng đang hoạt động đối với zkEVM Loại 2.

Ngược lại, zkSync Era sử dụng định dạng mã byte khác bằng cách cung cấp trình biên dịch để hỗ trợ Solidity. Điều này làm cho nó trở thành zkEVM loại 4: nó hỗ trợ Solidity, nhưng không hỗ trợ mã byte EVM. Không thể sử dụng trực tiếp các công cụ như Hardhat, mặc dù có sẵn plugin cho zkSync.

zkSync tin rằng zkVM của họ phù hợp với tương lai hơn, tức là nó hoạt động tốt hơn với các ngôn ngữ khác ngoài Solidity. Tuy nhiên, máy ảo của họ dường như kế thừa nhiều đặc điểm hiệu suất của EVM, chẳng hạn như kích thước từ 256 bit của nó. Một zkVM như Miden có thể mang tính tương lai hơn vì nó được thiết kế cho mục đích điện toán đa năng thay vì tập trung vào Solidity.

Hiệu suất

Hiệu suất luôn là trọng tâm của Polygon và zkEVM của chúng tôi rất hiệu quả. Chạy chứng minh của chúng tôi trên CPU tốn khoảng 0,000084 đô la cho mỗi giao dịch.

Mặc dù chúng tôi không tìm thấy bất kỳ điểm chuẩn hoạt động nào cho zkEVM với zkSync, nhưng chúng tôi nghi ngờ rằng có một khoảng cách lớn về hiệu suất do các lựa chọn công nghệ ZK rất khác nhau của chúng tôi.

Lựa chọn  miền

Sau khi nghiên cứu một số phương án, chúng tôi quyết định chọn trường Goldilocks, trường gồm các số nguyên tố khổng lồ bậc hai 2^64 - 2^32 + 1. Kích thước nhỏ và cấu trúc nhị phân đẹp mắt của nó dẫn đến các hoạt động tại hiện trường cực kỳ nhanh, với phép nhân chỉ mất chưa đến hai chu kỳ trên một CPU hiện đại.

zkSync có cách tiếp cận truyền thống hơn, sử dụng SNARK dựa trên đường cong alt-bn128. Kích thước của trường cơ bản là khoảng 254 bit và phép nhân trường mất khoảng 80 chu kỳ trên CPU.

Để cảm nhận được tác động của sự khác biệt lớn này, chúng ta có thể xem điểm chuẩn SHA2 của Celer. Ở đó, bộ chuẩn STARK của chúng tôi nhanh hơn 5-50 lần so với bộ chuẩn dựa trên đường cong elip.

Cái hay của alt-bn128 là EVM hỗ trợ nó nguyên bản, vì vậy việc gửi bằng chứng tới Ethereum sẽ đơn giản hơn. Tại Polygon, chúng tôi "bọc" bằng chứng tổng hợp cuối cùng bằng bằng chứng flonk của alt-bn128. Mặc dù phương pháp của chúng tôi đòi hỏi nhiều công việc hơn, nhưng chúng tôi tin rằng nó đáng để đạt được hiệu suất đáng kinh ngạc.

Số học hóa

Sự khác biệt không dừng lại ở đó. zkEVM của chúng tôi được xây dựng trên STARK, nhưng với những thay đổi hiện đại. Chúng tôi có một STARK chính cho CPU (một hàng trên mỗi chu kỳ) và các STARK khác cho số học, băm, v.v. Các bảng này có thể được nối như chúng tôi mô tả trong RapidUp. Điều này tương tự với CPU vật lý, thường có bộ đồng xử lý để tăng tốc các hoạt động chuyên sâu như kết xuất, suy luận Crypto hoặc ML.

Lấy Keccak làm ví dụ. Vì nó được sử dụng rộng rãi trong các ứng dụng EVM nên chúng tôi đã thiết kế một STARK dành riêng cho nó, sử dụng một số thủ thuật mới mà chúng tôi ghi lại ở đây. Việc thiết kế một phép tính số học tùy chỉnh như vậy đòi hỏi rất nhiều công sức, nhưng nó đã được đền đáp, cho phép chúng tôi chứng minh hàng trăm hoán vị Keccak mỗi giây.

zkSync sử dụng cái mà tôi gọi là cách tiếp cận truyền thống hơn. Họ sử dụng một bộ kiểm chứng dựa trên PLONK và mặc dù nó hỗ trợ các cổng tùy chỉnh, nhưng zkEVM của họ không được sử dụng nhiều; hầu hết các phép tính được thực hiện bằng một cổng chung có tên là SelectorOptimizedWidth4MainGateWithDNext. Nó dường như mạnh hơn một chút so với cổng PLONK thông thường, nhưng vẫn bị giới hạn ở các hoạt động đơn giản như thêm nhiều lần.

Đối với tín dụng của zkSync, nó sử dụng các tham số tra cứu (như của chúng tôi), một kỹ thuật hiện đại hơn có thể giúp làm cho những thứ như Keccak hiệu quả hơn. Tuy nhiên, nếu không có số học tùy chỉnh, toán học 256-bit, Keccak, v.v. sẽ kém hiệu quả hơn nhiều.

Tính an toàn

Polygon rất coi trọng vấn đề bảo mật và zkEVM của chúng tôi đã trải qua hai cuộc kiểm toán độc lập: một bởi Spearbit và một bởi Hexens. Cả hai báo cáo đều có thể xem công khai tại đây. Chúng tôi cũng xuất bản các hướng dẫn để xác minh việc triển khai.

Chúng tôi không biết liệu zkEVM của zkSync đã trải qua bất kỳ cuộc kiểm toán công khai nào chưa. Trang web của zkSync liệt kê các cuộc kiểm toán cho các hợp đồng bắc cầu, nhưng không liệt kê bản thân zkEVM.

Ngoài việc kiểm tra, cả hai dự án đều có nhiều "bản sao lưu an toàn" khác nhau để cung cấp một lớp bảo mật thay thế, nhưng đây là một chủ đề sâu mà tôi sẽ không đi vào chi tiết ở đây.

Số liệu L1

Polygon zkEVM xuất bản tất cả dữ liệu giao dịch lên L1. Đã có một số nhầm lẫn về điều này trên Twitter, hãy xem bài viết của Edu về phí xăng để biết điều này. Hiện tại, kích thước giao dịch trung bình là khoảng 120 byte, vì vậy phí gas cho mỗi giao dịch là khoảng 120*16=1920Gas.

zkSync công bố sự khác biệt về trạng thái. Các bộ nối tiếp độc hại có thể che giấu dữ liệu giao dịch, nhưng zkSync tin rằng việc có trạng thái hiện tại của bộ ba là đủ để bảo mật. Điều này có vẻ gây tranh cãi vì dữ liệu giao dịch thường được dự kiến ​​sẽ có sẵn và một số ứng dụng phụ thuộc vào dữ liệu đó.

Sau khi xem xét dữ liệu đã sửa, chúng tôi có thể thấy rằng zkEVM và zkSync của chúng tôi có phí gas gần như giống nhau cho mỗi giao dịch. Những con số này có thể thay đổi theo thời gian với sự kết hợp của các loại giao dịch xảy ra trên mỗi chuỗi, nhưng cho đến ngày nay, sự khác biệt về trạng thái không tiết kiệm được bất kỳ khí nào; cả hai hệ thống đều gửi khoảng 120 byte cho mỗi giao dịch tới L1 .

Chúng tôi dự định thực hiện một số tối ưu hóa ở đây, nhưng không sử dụng các khác biệt về trạng thái. Bản thân các giao dịch có thể được nén để giảm chi phí gas trong khi vẫn duy trì tính sẵn có của dữ liệu giao dịch. Giữ nguyên!