2022 ngày 29 tháng 8
Xem tất cả bài viết
Đặc biệt cảm ơn các nhóm PSE, Polygon Hermez, Zksync, Scroll, Matter Labs và Starkware đã tham gia thảo luận và hỗ trợ hiệu đính
Gần đây, nhiều ZK-EVM khác nhau đã lần lượt xuất hiện. ZK-EVM của Polygon được phát hành dưới dạng mã nguồn mở, ZKSync đã công bố kế hoạch cho ZKSync 2.0 và Scroll, được đưa vào thị trường tương đối muộn, cũng đã tung ra ZK-EVM của họ. ZK-EVM đang được phát triển, cũng như PSE, Nicholas Liochon và những người khác, và trình biên dịch alpha (có thể biên dịch EVM thành Cairo do Starkware phát triển) đang được phát triển bởi Starkware.
Các dự án trên có một mục tiêu chung: sử dụng ZK-SNARK để chứng minh mật mã và xác minh việc thực hiện các giao dịch giống như Ethereum. Điều này sẽ xác minh tốt hơn các giao dịch và trạng thái trên chuỗi Ethereum L1, đồng thời thiết lập các ZK-rollup tương đương (gần) với Ethereum và có khả năng mở rộng tốt hơn. Nhưng sự khác biệt nhỏ giữa các dự án này phản ánh sự đánh đổi giữa tính thực tế và tốc độ. Bài báo này cố gắng đề xuất một cách để phân loại các EVM khác nhau, đồng thời minh họa những sự đánh đổi và đánh đổi.
Túi lười (được trình bày dưới dạng sơ đồ)
Loại 1: ZK-EVM hoàn toàn tương đương với Ethereum
Loại ZK-EVM đầu tiên nhằm mục đích đạt được giá trị tương đương với Ethereum một cách hoàn toàn và không thỏa hiệp. Nó không thay đổi thiết kế của bất kỳ phần nào của hệ sinh thái Ethereum để làm cho bằng chứng dễ dàng hơn, cũng như không thay thế hàm băm, cây trạng thái, cây giao dịch và tiền biên dịch. thay thế.
Ưu điểm: tương thích hoàn hảo
Mục đích của mọi thứ là sử dụng chuỗi Ethereum hiện tại—ít nhất là để xác minh lớp thực thi (và do đó không bao gồm logic đồng thuận của Chuỗi Beacon (Beacon Chain), nhưng tất cả các khái niệm thực thi giao dịch, hợp đồng thông minh và tài khoản đều được đề cập).
ZK-EVM của loại 1 là giải pháp cuối cùng có thể mở rộng hơn của Ethereum L1. Về lâu dài, các bản sửa lỗi đối với Ethereum có thể được đưa vào Ethereum thông thường sau các thử nghiệm Loại 2 hoặc Loại 3. Sau đó, để quy hoạch lại kiến trúc, sẽ có những phức tạp.
ZK-EVM loại 1 cũng lý tưởng cho các bản tổng hợp, vì các bản tổng hợp có thể tái sử dụng nhiều cơ sở hạ tầng. Ví dụ: phía thực thi của Ethereum có thể được sử dụng để tạo và xử lý các khối tổng số (để lùi lại một bước, chức năng này có thể được sử dụng lại trong khoản tiền ký quỹ Ethereum của đợt tổng số sau khi giải phóng khoản tiền ký quỹ có hiệu lực), ví dụ: các Công cụ chuỗi khối như trình duyệt và sản xuất khối rất dễ sử dụng lại.
Bất lợi: Prover thời gian
Ethereum vốn không sử dụng kiến thức không để chứng minh cơ sở hạ tầng của nó, vì vậy cónhiềuCác thành phần vốn có của Ethereum cần tiêu tốn một lượng lớn thời gian tính toán để xác minh kiến thức bằng không. Loại ZK-EVM đầu tiên tìm cách sao chép hoàn toàn hoạt động của Ethereum, do đó, nó không tránh khỏi quy trình chứng minh không hiệu quả. Ở giai đoạn này, phải mất vài giờ để tạo bằng chứng không có kiến thức từ các khối hiện có trong Ethereum. Tuy nhiên, trở ngại này có thể được giảm bớt nhờ thiết kế kỹ thuật khéo léo, cải thiện đáng kể khả năng của trình xác minh để song song hóa đầu ra của bằng chứng không có kiến thức hoặc xây dựng ASIC ZK-SNARK.
thí dụ
ZK-EVM mà PSE đang bao gồm là loại 1.
Loại 2: ZK-EVM tương đương với máy ảo Ethereum (hoàn toàn tương đương với EVM)
Loại ZK-EVM thứ hai được cố gắng tương đương với EVM, nhưng không hoàn toàn tương đương với Ethereum. Nói cách khác, chúng có “bên trong” giống Ethereum nhưng nhìn bên ngoài thì khác, đặc biệt là cấu trúc khối, cây trạng thái và các cấu trúc dữ liệu khác.
Mục đích của mọi thứ là hoàn toàn tương thích với phần mềm ứng dụng hiện có, nhưng hãy tinh chỉnh Ethereum để giúp việc phát triển dễ dàng hơn và tạo ra bằng chứng nhanh hơn.
Ưu điểm: tương đương máy ảo
Loại 2 ZK-EVM sửa đổi cấu trúc dữ liệu lưu trữ dữ liệu, chẳng hạn như trạng thái Ethereum. May mắn thay, đây là cấu trúc mà bản thân EVM không thể truy cập trực tiếp, vì vậy hầu hết tất cả các ứng dụng chạy trên Ethereum đều có thể được sử dụng trên bản tổng hợp ZK-EVM Loại 2. Bạn không thể sử dụng trực tiếp phía thực thi ethereum, nhưng với một số tinh chỉnh, các công cụ sửa lỗi của EVM và hầu hết các phương tiện phát triển cũng có thể được sử dụng như bình thường.
Ngoài ra còn có một vài trường hợp ngoại lệ. Đối với bằng chứng Merkle sử dụng các khối Ethereum lịch sử để xác minh giao dịch lịch sử, chi tiết giao dịch hoặc trạng thái (tuyên bố về giao dịch lịch sử, biên lai hoặc trạng thái) (ví dụ: cầu nối chuỗi đôi khi sẽ làm như vậy) sẽ có sự không tương thích. Nếu có một ZK-EVM thay thế Keccak bằng các hàm băm khác, các bằng chứng này sẽ trở nên không hợp lệ. Tuy nhiên, tôi không khuyên bạn nên thiết kế ứng dụng theo cách này ngay từ đầu, vì những thay đổi trong tương lai mà Ethereum sẽ giới thiệu (chẳng hạn như cây Verkle) sẽ khiến những ứng dụng này không sử dụng được ngay cả trên Ethereum. Một giải pháp thay thế tốt hơn là bản thân Ethereum nên thêm các bản biên dịch trước truy cập lịch sử bằng chứng trong tương lai mà công nghệ tương lai không dễ dàng loại bỏ.
Nhược điểm: Thời gian hoạt động của thiết bị chứng minh đã được cải thiện đôi chút nhưng vẫn còn chậm
Tốc độ tính toán của chứng minh loại ZK-EVM thứ hai nhanh hơn loại thứ nhất.Lý do chính là do một số mật mã Ethereum không thân thiện với công nghệ không kiến thức đã không còn được sử dụng nữa. Cụ thể, họ có thể thay đổi cây Merkle Patricia dựa trên Keccak và RLP của Ethereum, và có thể là cấu trúc của các khối và chi tiết giao dịch. ZK-EVM Loại 2 có thể sử dụng hàm băm khác, chẳng hạn như Poseidon.Một thay đổi cũng xảy ra một cách tự nhiên là sửa đổi cây trạng thái để lưu trữ mã hợp đồng băm và keccak, miễn trừEXTCODEHASHvàEXTCODECOPYYêu cầu xác minh hàm băm.
Những thay đổi này cải thiện đáng kể thời gian tính toán chứng minh, nhưng không giải quyết triệt để mọi vấn đề. Điều đó chứng tỏ rằng hiệu quả chậm của EVM hiện tại, cũng như sự kém hiệu quả khác bắt nguồn từ EVM và sự không thân thiện với zk vẫn còn đó. Lấy một ví dụ đơn giản: bộ nhớ.bởi vì mộtMLOADChỉ có thể đọc 32 byte tại một thời điểm, bao gồm cả byte “không được phân bổ” (cả bắt đầu và kết thúc không phải là bội số của 32), MLOAD không thể được đọc trực tiếp dưới dạng một đoạn, có thể cần đọc nhiều hơn hai mâm cặp liên tiếp và Do một số tính toán và kết hợp các kết quả.
thí dụ
Scroll’s ZK-EVM và Polygon Hermez đều thuộc loại thứ hai. Tuy nhiên, cả hai dự án vẫn còn lâu mới được thực hiện. Đặc biệt là vì phần biên dịch trước phức tạp hơn chưa được thêm vào, nên hiện tại, cả hai dự án nên được xếp vào loại thứ ba.
Loại 2.5: Cấu trúc tương tự như máy ảo Ethereum, nhưng ngoại lệ về giá gas
Cách để giảm đáng kể thời gian kiểm chứng trong trường hợp xấu nhất là tăng đáng kể giá gas cần thiết cho các hoạt động chứng minh không có kiến thức khó khăn trong EVM. Điều này liên quan đến việc biên dịch trước, mã KECCAK và có lẽ là các mẫu gọi hợp đồng cụ thể, truy cập bộ nhớ, lưu trữ hoặc hoàn nguyên.
Cải thiện giá gas có thể làm giảm khả năng tương thích của công cụ dành cho nhà phát triển và làm hỏng một số ứng dụng, nhưng nó ít rủi ro hơn so với các thay đổi EVM “sâu” hơn. Các nhà phát triển nên cẩn thận để không tiêu nhiều gas hơn mức mà một khối có thể đáp ứng trong một giao dịch và không bao giờ mã hóa cứng gas cần thiết để gọi hợp đồng (đây là lời khuyên tiêu chuẩn dành cho các nhà phát triển).
Một cách khác để giải quyết vấn đề giới hạn tài nguyên là trực tiếp áp đặt một giới hạn cứng đối với số lần mỗi hoạt động có thể được gọi. Điều này dễ thực hiện hơn trên mạch, nhưng các giả định về an toàn trên EVM ít phù hợp hơn. Tôi nghĩ rằng thực hành này rơi vào loại 3 hơn là loại 2.5.
Loại 3: Gần như tương đương với EVM
ZK-EVM loại 3 làgần EVM tương đương, chỉ với sự thỏa hiệp để cải thiện thời gian tính toán chứng minh và giúp phát triển dễ dàng hơn.
Ưu điểm: Dễ thực hiện hơn, thời gian tính toán của người chứng minh được rút ngắn
Loại 3 ZK-EVM có thể loại bỏ một số tính năng đặc biệt khó thay đổi thành ZK-EVM. Điều có khả năng bị loại bỏ nhất là tiền biên dịch. Ngoài ra, các ZK-EVM Loại 3 khác nhau cũng có những khác biệt nhỏ trong việc xử lý mã hợp đồng, bộ nhớ hoặc ngăn xếp.
Nhược điểm: Không tương thích
Loại 3 ZK-EVM nhằm mục đích làm theophần lớnTương thích với các ứng dụng khác và chỉ cần viết lại một vài phần. Mặc dù vậy, vẫn có một số ứng dụng cần được viết lại, bởi vì chúng sử dụng chức năng biên dịch trước bị loại bỏ bởi loại ZK-EVM thứ ba, hoặc trong các trường hợp đặc biệt (trường hợp cạnh), một số máy ảo xử lý các phụ thuộc phương pháp khác nhau.
thí dụ
Cuộn và Đa giác, mặc dù chúng được kỳ vọng sẽ cải thiện khả năng tương thích trong tương lai, nhưng hiện tại là lớp 3. Polygon có một thiết kế đặc biệt để xác minh ngôn ngữ riêng của nó, zkASM, và họ sử dụng zkASM để biên dịch các chương trình ZK-EVM. Mặc dù vậy, tôi coi đây là ZK-EVM Loại 3. Nó vẫn có thể xác minh mã EVM, nhưng logic bên trong đã thay đổi.
Hiện tại, không có nhóm ZK-EVM nàomuốn trở thànhLớp 3 ZK-EVM. Category 3 chỉ là giai đoạn chuyển tiếp, chờ tính năng precompilation hoàn thiện rồi mới chuyển sang category 2.5. Nhưng trong tương lai, loại 1 hoặc loại 2 có thể thêm tính năng tiền biên dịch thân thiện với ZK-SNARK và tự động trở thành loại 3, giảm thời gian tính toán và khí của trình chứng minh.
Lớp 4 (tương đương ngôn ngữ cấp cao)
Loại 4 đặt (ví dụ: Solidity, Vyper hoặc một số ngôn ngữ trung gian khác mà cả hai ngôn ngữ biên dịch thành) và đặtngôn ngữ cấp caoBiên dịch sang các ngôn ngữ khác được thiết kế đặc biệt để thân thiện với ZK-SNARK.
Ưu điểm: Trình tự yêu cầu thời gian tính toán rất ngắn
Miễn là bằng chứng không kiến thức được sử dụng từ ngôn ngữ cấp cao, thay vì đợi các bước khác nhau trong giai đoạn thực thi để bắt đầu sử dụng nó trên EVM, nó có thể tiết kiệmrất nhiềurắc rối.
Mặc dù tôi chỉ dùng một câu để mô tả ưu điểm này (nhưng có rất nhiều nhược điểm về khả năng tương thích được liệt kê bên dưới), tôi không có ý nói rằng loại 4 không có ưu điểm. Đây là một lợi thế rất lớn! Biên dịch trực tiếp từ một ngôn ngữ cấp cao thực sự có thể giảm đáng kể chi phí và vì ngưỡng tham gia bằng chứng trở nên thấp hơn nên nó được phân cấp nhiều hơn.
Nhược điểm: khả năng tương thích thấp
Thông thường, một ứng dụng “bình thường” được viết bằng Vyper hoặc Solidity có thể được biên dịch và sau đó được sử dụng, nhưng có nhiều ứng dụng không thể “bình thường” như vậy và lý do rất quan trọng:
- Vì địa chỉ hợp đồng trong CREATE2 phụ thuộc vào quyết định mã byte, nên “Địa chỉ hợp đồng trong hệ thống Loại 4” không nhất thiết giống như “Địa chỉ hợp đồng trong EVM”. Điều này sẽ khiến nhiều ứng dụng không sử dụng được, chẳng hạn như các hệ thống dựa trên “hợp đồng phản thực tế” chưa được triển khai, ví ERC-4337, đĩa đơn EIP-2470, v.v.
- Mã byte EVM được chạm khắc thủ công khó bị khai thác hơn. Một số phần của nhiều chương trình sử dụng mã byte EVM được chạm khắc thủ công để nâng cao hiệu quả. Hệ thống loại 4 không được hỗ trợ. Mặc dù có nhiều cách để triển khai hỗ trợ mã byte EVM hạn chế để đáp ứng các trường hợp này, nhưng không nhất thiết phải chuyển thẳng sang ZK-EVM Loại 3.
- Phần lớn cơ sở hạ tầng gỡ lỗi không thể được khai thác trực tiếp, bởi vì các cơ sở hạ tầng này chỉ có thể chạy trên mã byte EVM. Phải nói rằng, có nhiều công cụ sửa lỗi từ các ngôn ngữ cấp cao hoặc cấp trung truyền thống (chẳng hạn như LLVM) có thể được sử dụng để khắc phục nhược điểm này.
Đây đều là những vấn đề mà các kỹ sư cần lưu ý.
thí dụ
ZKSync là một hệ thống loại 4, mặc dù chúng có thể cải thiện khả năng tương thích với mã byte EVM theo thời gian. Dự án Warp của Nethermind đang xây dựng một trình biên dịch có thể biên dịch Solidity sang ngôn ngữ Cairo của Starkware, do đó sẽ biến StarkNet thành một hệ thống Lớp 4 trên thực tế.
Triển vọng tương lai cho các loại ZK-EVM
Không có “tốt hơn” hay “xấu” giữa các loại khác nhau ở trên, nhưng có sự khác biệt về sự đánh đổi: càng gần với loại đầu tiên, càng tương thích với cơ sở hạ tầng hiện có, nhưng chậm hơn. Các loại gần lớp 4 ít tương thích hơn, nhưng nhanh hơn. Nói chung, nó tốt hơn cho toàn bộ hệ sinh thái, tức là từng loại khác nhau đã được nghiên cứu.
Loại ZK-EVM gần với loại thứ tư cũng có thể dần được thay đổi thành loại gần với loại đầu tiên theo thời gian. ngược lại. Ví dụ: – ZK-EVM có thể bỏ qua các chức năng khó chứng minh bằng không kiến thức, chỉ là loại thứ ba. Sau đó, thêm các chức năng từ từ và dần dần chuyển sang danh mục thứ hai. – ZK-EVM cũng có thể là lớp 2 trước tiên, sau đó cung cấp một môi trường hoàn toàn tương đương trong Ethereum hoặc cây trạng thái được sửa đổi để chứng minh nhanh hơn và trở thành hỗn hợp của lớp 2 và lớp 1. Scroll đang xem xét chiến lược phát triển này. – Ban đầu là một hệ thống Type 4, khả năng xử lý các opcode EVM cũng có thể được bổ sung từ từ (mặc dù các nhà phát triển vẫn được khuyến khích biên dịch trực tiếp từ các ngôn ngữ cấp cao để tiết kiệm phí và cải thiện thời gian cần thiết cho việc tính toán chứng minh). – Giả sử rằng bản thân Ethereum trở nên thân thiện với kiến thức bằng không hơn, ZK-EVM ban đầu bắt đầu là Loại 2 hoặc Loại 3 sẽ trở thành Loại 1. – Nếu các bản tiền biên dịch thuộc ZK-EVM loại 1 hoặc loại 2, thì nó sẽ trở thành ZK-EVM loại 3. Các thành phần được biên dịch trước này có hiệu quả cao để xác minh và được viết bằng ngôn ngữ thân thiện với ZK-SNARK. Điều này cho phép các nhà phát triển lựa chọn giữa khả năng tương thích và tốc độ của Ethereum. ZK-EVM này thuộc loại 3 vì nó hy sinh tính tương đương Ethereum hoàn hảo, nhưng nó có nhiều lợi ích hơn loại 1 hoặc 2 từ quan điểm thực tế. Thiếu chính là một số công cụ dành cho nhà phát triển không hỗ trợ biên dịch trước tùy chỉnh ZK-EVM, tuy nhiên, điều này có thể được cải thiện: bằng cách chỉ định thủ công tệp cấu hình bởi nhà phát triển, công cụ dành cho nhà phát triển có thể hỗ trợ chuyển đổi các thành phần được biên dịch trước trở lại mã EVM có chức năng tương đương , để nó có thể được sử dụng trong mọi môi trường.
Hy vọng cá nhân của tôi là cùng với thời gian, công nghệ ZK-EVM phát triển và bản thân Ethereum thân thiện hơn với thiết kế ZK-SNARK, tất cả ZK-EVM có thể dần dần phát triển thành loại đầu tiên. Trong tương lai như vậy, chúng tôi sẽ có một số ZK-EVM có thể đồng thời đóng vai trò là ZK-rollup và xác minh chính chuỗi Ethereum. Về lý thuyết, không cần phải chuẩn hóa Ethereum thành L1 chỉ có thể được sử dụng bởi một ZK-EVM. Chúng tôi chỉ có thể gặt hái những lợi ích của dự phòng mã nếu các máy khách khác nhau sử dụng các phương pháp chứng thực khác nhau.
Tuy nhiên, sẽ mất một thời gian để đi đến một tương lai như vậy. Trên con đường này, chúng ta sẽ thấy rất nhiều thay đổi nhanh chóng trong công nghệ mở rộng Ethereum và Ethereum ZK-rollups.
