Tương lai của Ethereum Rollup thực sự là sự kết hợp của hai cách tiếp cận chính (ZK và Lạc quan).

Tiêu đề gốc: " ZK lai / Rollup lạc quan của tương lai "

Được viết bởi: kelvinfichter

Biên dịch: MK

Gần đây tôi đã bị thuyết phục rằng tương lai của Ethereum Rollups thực sự là sự kết hợp của hai cách tiếp cận chính (ZK và Lạc quan). Trong bài đăng này, tôi sẽ cố gắng giải thích kiến ​​trúc cơ bản của những gì tôi hình dung và giải thích lý do tại sao tôi nghĩ đây là con đường tốt nhất phía trước.

Tôi sẽ không dành quá nhiều thời gian để thảo luận về bản chất của ZK hoặc Bản tổng hợp lạc quan. Bài đăng này giả định rằng bạn đã hiểu rõ về cách thức hoạt động của những thứ này. Bạn không cần phải là một chuyên gia, nhưng ít nhất bạn nên biết chúng là gì và chúng hoạt động ở cấp độ cao như thế nào. Nếu tôi cố gắng giải thích Rollup cho bạn, thì bài đăng này sẽ rất, rất dài. Tất cả trong tất cả, thưởng thức đọc!

Bắt đầu với Rollup lạc quan

Hybrid ZK/Optimistic Rollup bắt đầu với tên Optimistic Rollup, rất giống với kiến ​​trúc Bedrock của Optimism. Bedrock nhằm mục đích tương thích tối đa với Ethereum ("tương đương EVM") và đạt được điều này bằng cách chạy một ứng dụng khách thực thi gần giống với ứng dụng khách Ethereum thông thường. Bedrock sử dụng mô hình phân tách ứng dụng khách thực thi/đồng thuận sắp tới của Ethereum, giảm đáng kể phương sai đối với EVM (một số thay đổi sẽ luôn được yêu cầu, nhưng chúng tôi có thể quản lý điều này). Khi tôi viết bài này, khác biệt Bedrock Geth là một cam kết +388 -30.

Giống như bất kỳ Rollup tốt nào, Optimism lấy dữ liệu khối/giao dịch từ Ethereum, sắp xếp dữ liệu này theo một số cách xác định trong ứng dụng khách đồng thuận, sau đó cung cấp dữ liệu này vào ứng dụng khách thực thi L2 để thực thi. Kiến trúc này giải quyết nửa đầu của câu đố "Bản tổng hợp lý tưởng", cung cấp cho chúng tôi L2 tương đương EVM.

Tất nhiên, bây giờ chúng ta cũng cần giải quyết vấn đề làm thế nào để nói một cách có thể chứng minh được những gì đang diễn ra bên trong Ethereum Optimism. Không có tính năng này, các hợp đồng không thể đưa ra quyết định dựa trên trạng thái Lạc quan. Điều này có nghĩa là người dùng có thể gửi tiền vào Optimism nhưng không bao giờ có thể rút tài sản của họ. Mặc dù trong một số trường hợp, tổng số một chiều có thể thực sự hữu ích, nhưng nói chung, tổng số hai chiều sẽ hữu ích hơn.

Chúng tôi có thể cho Ethereum biết trạng thái của bất kỳ Rollup nào bằng cách đưa ra cam kết về trạng thái đó và bằng chứng rằng cam kết đã được tạo chính xác. Một cách khác để nói điều này là chúng tôi đang chứng minh rằng "chương trình Rollup" đã được thực thi chính xác. Sự khác biệt thực sự duy nhất giữa ZK và Bản tổng hợp lạc quan là hình thức của bằng chứng này. Trong ZK Rollup, bạn cần đưa ra bằng chứng ZK rõ ràng rằng chương trình được thực thi chính xác. Trong Tổng hợp lạc quan, bạn đưa ra tuyên bố về những lời hứa nhưng không có bằng chứng rõ ràng. Những người dùng khác có thể thách thức các tuyên bố của bạn và buộc bạn phải chơi một trò chơi lặp đi lặp lại để cuối cùng bạn tìm ra ai đúng.

Tôi sẽ không đi vào chi tiết quá nhiều về trò chơi thử thách Optimistic Rollup. Điều đáng chú ý là trình độ nghệ thuật trong trò chơi này đang biên dịch chương trình của bạn (Geth EVM + một số phần bên lề trong trường hợp của Optimism) thành một số kiến ​​trúc máy đơn giản như MIPS. Chúng tôi làm điều này vì chúng tôi cần xây dựng trình thông dịch cho chương trình của mình trên chuỗi và việc xây dựng trình thông dịch MIPS dễ dàng hơn nhiều so với trình thông dịch EVM. EVM cũng là một mục tiêu di động (chúng tôi có các nhánh nâng cấp thường xuyên) và không hoàn toàn bao gồm các chương trình mà chúng tôi muốn chứng minh (cũng có một số nội dung không phải EVM trong đó).

Khi bạn đã xây dựng trình thông dịch trên chuỗi cho kiến ​​trúc máy đơn giản của mình và tạo một số công cụ ngoài chuỗi, bạn sẽ có Bản tổng hợp lạc quan đầy đủ chức năng.

Chuyển đổi sang ZK Rollup

Nhìn chung, tôi nghĩ rằng Bản tổng hợp lạc quan sẽ chiếm ưu thế trong ít nhất vài năm tới. Một số người nghĩ rằng Bản tổng hợp ZK cuối cùng sẽ vượt qua Bản tổng hợp lạc quan, nhưng tôi nghĩ điều này có thể sai. Tôi nghĩ tính đơn giản và tính linh hoạt tương đối của các Bản tổng hợp lạc quan ngày nay có nghĩa là chúng có thể được chuyển đổi thành Bản tổng hợp ZK theo thời gian. Nếu chúng ta có thể tìm ra một mô hình có thể biến nó thành hiện thực, thì thực sự không có động cơ mạnh mẽ nào để triển khai một mô hình kém linh hoạt hơn, dễ gãy hơn khi bạn có thể chỉ cần triển khai một hệ thống Lạc quan hiện có và gọi đó là hệ thống ZK hoạt động trong ngày.

Do đó, mục tiêu của tôi là tạo ra một kiến ​​trúc và lộ trình di chuyển để các hệ thống Lạc quan hiện đại hiện có (chẳng hạn như Bedrock) có thể được chuyển đổi liền mạch thành các hệ thống ZK. Đây là cách tôi nghĩ rằng điều này không chỉ có thể thực hiện được mà còn theo một cách vượt xa cách tiếp cận zkEVM hiện tại.

Chúng tôi bắt đầu với kiến ​​trúc theo phong cách Bedrock mà tôi đã mô tả ở trên. Lưu ý rằng tôi (ngắn gọn) đã giải thích cách Bedrock có một trò chơi thử thách xác nhận các chương trình L2 (chạy EVM + một số nội dung bổ sung để biến nó thành ZK Rollup

Nhìn chung, tôi nghĩ rằng các bản tổng hợp lạc quan sẽ thống trị trong vài năm tới. Có ý kiến ​​cho rằng ZK Rollup cuối cùng sẽ vượt qua Optimistic Rollup, nhưng tôi nghĩ điều này có thể sai. Tôi nghĩ tính đơn giản và tính linh hoạt tương đối của Bản tổng hợp lạc quan có nghĩa là chúng có thể được chuyển đổi thành Bản tổng hợp ZK theo thời gian. Nếu chúng ta có thể tìm ra một mô hình để quá trình chuyển đổi này xảy ra, thì thực sự không có động cơ mạnh mẽ nào để triển khai sang các hệ thống ZK kém linh hoạt hơn và dễ gặp sự cố hơn.

Do đó, mục tiêu của tôi là tạo ra một kiến ​​trúc và lộ trình di chuyển cho phép các hệ thống Lạc quan hiện đại hiện có (chẳng hạn như Bedrock) được chuyển đổi liền mạch thành các hệ thống ZK. Tôi tin rằng đây là một cách để không chỉ thực hiện quá trình chuyển đổi này mà còn thực hiện theo cách vượt xa cách tiếp cận zkEVM ngày nay.

Chúng tôi bắt đầu với kiến ​​trúc theo phong cách Bedrock mà tôi đã mô tả trước đó. Lưu ý rằng tôi (ngắn gọn) đã giải thích cách Bedrock có một trò chơi thử thách có thể khẳng định tính hợp lệ của việc thực thi chương trình L2 (chương trình MIPS chạy EVM + một số tính năng bổ sung). Một trong những nhược điểm chính của phương pháp này là chúng tôi cần cho phép một khoảng thời gian để người dùng phát hiện và thách thức thành công đề xuất kết quả chương trình sai. Điều này làm tăng thêm một lượng thời gian đáng kể cho quá trình rút tài sản (hiện tại là 7 ngày trên mạng chính của Optimism).

Tuy nhiên, L2 của chúng tôi chỉ là một chương trình chạy trên một máy đơn giản (MIPS). Hoàn toàn có thể xây dựng mạch ZK cho một máy đơn giản như vậy. Sau đó, chúng ta có thể sử dụng mạch này để chứng minh rõ ràng việc thực hiện đúng chương trình L2. Không thực hiện bất kỳ thay đổi nào đối với cơ sở mã Bedrock hiện tại, bạn có thể bắt đầu đưa ra bằng chứng hợp lệ cho Chủ nghĩa lạc quan. Nó thật sự đơn giản.

tại sao phương pháp này rất tốt

Lưu ý nhanh: Trong phần này, tôi đề cập đến "zkMIPS", nhưng thực sự tôi đang sử dụng nó để chỉ bất kỳ zkVM "đơn giản" chung nào.

tại sao phương pháp này rất tốt

Lưu ý nhanh: Trong phần này, tôi đề cập đến "zkMIPS", nhưng thực sự tôi đang sử dụng nó để chỉ bất kỳ zkVM "đơn giản" chung nào.

zkMIPS đơn giản hơn zkEVM

Lợi ích to lớn của việc xây dựng zkMIPS (hoặc zk[chèn tên máy khác]) thay vì zkEVM là kiến ​​trúc của máy mục tiêu đơn giản và tĩnh. EVM thay đổi thường xuyên. Giá xăng sẽ thay đổi, opcode sẽ được điều chỉnh và mọi thứ sẽ được thêm hoặc bớt. Và MIPS-V đã không thay đổi kể từ năm 1996. Bằng cách nhắm mục tiêu zkMIPS, bạn làm việc trên một không gian có vấn đề cố định. Bạn không cần thay đổi và có thể kiểm tra lại mạch của mình mỗi khi EVM được cập nhật.

zkMIPS linh hoạt hơn zkEVM

Một điểm gây tranh cãi quan trọng khác là zkMIPS linh hoạt hơn zkEVM. Với zkMIPS, bạn có thể linh hoạt hơn trong việc sửa đổi mã máy khách theo ý muốn để đạt được nhiều sự tối ưu hóa hoặc cải thiện trải nghiệm người dùng. Bản cập nhật máy khách không còn cần phải đi kèm với bản cập nhật mạch. Bạn cũng có thể tạo một thành phần cốt lõi có thể được sử dụng để biến bất kỳ chuỗi khối nào thành ZK Rollup, không chỉ Ethereum.

Câu hỏi của bạn biến thành thời gian chứng minh

Thời gian chứng minh ZK chia tỷ lệ dọc theo hai trục: số lượng ràng buộc và kích thước mạch. Bằng cách tập trung vào mạch của một máy đơn giản như MIPS (chứ không phải là một máy phức tạp hơn như EVM), chúng tôi có thể giảm đáng kể kích thước và độ phức tạp của mạch. Tuy nhiên, số lượng ràng buộc phụ thuộc vào số lượng lệnh máy được thực thi. Mỗi opcode EVM được chia nhỏ thành nhiều opcode MIPS, điều đó có nghĩa là số lượng ràng buộc tăng lên đáng kể, cũng như thời gian kiểm chứng tổng thể.

Nhưng giảm thời gian kiểm chứng là một vấn đề bắt nguồn từ không gian Web2. Cho rằng kiến ​​trúc máy MIPS sẽ không thay đổi trong tương lai gần, chúng tôi có thể tối ưu hóa cao các mạch và chương trình kiểm chứng của mình mà không phải lo lắng về các thay đổi của EVM ở giai đoạn sau. Tôi khá chắc chắn rằng nhóm tuyển dụng các kỹ sư phần cứng có thể tối ưu hóa một chương trình được xác định rõ ràng lớn hơn ít nhất 10 lần (nếu không muốn nói là 100 lần) so với nhóm tuyển dụng để xây dựng và kiểm tra mục tiêu zkEVM luôn thay đổi. Một công ty như Netflix có thể có rất nhiều kỹ sư phần cứng đang làm việc để tối ưu hóa các chip chuyển mã và họ sẵn sàng chấp nhận một khoản tiền đầu tư mạo hiểm để giải quyết một thử thách ZK thú vị.

Thời gian chứng minh ban đầu cho một mạch như vậy có thể vượt quá khoảng thời gian rút tiền 7 ngày của Optimistic Rollup. Thời gian chứng minh này sẽ chỉ giảm theo thời gian. Bằng cách giới thiệu ASIC và FPGA, chúng tôi có thể tăng tốc đáng kể thời gian kiểm chứng. Với một mục tiêu tĩnh, chúng ta có thể xây dựng các bộ chứng minh tối ưu hơn.

Cuối cùng, thời gian chứng minh cho mạch này sẽ thấp hơn khoảng thời gian rút tiền của Tổng số lạc quan 7 ngày hiện tại và chúng tôi có thể bắt đầu quá trình thử thách để xem xét việc hủy bỏ Lạc quan. Chạy bằng chứng trong 7 ngày có thể vẫn còn quá đắt, vì vậy chúng tôi có thể muốn đợi lâu hơn một chút, nhưng quan điểm vẫn giữ nguyên. Bạn thậm chí có thể chạy cả hai hệ thống bằng chứng cùng một lúc để chúng tôi có thể bắt đầu sử dụng bằng chứng ZK ngay lập tức và nếu vì lý do nào đó mà chương trình bằng chứng không thành công, chúng tôi có thể quay lại bằng chứng Lạc quan. Khi đã sẵn sàng, thật dễ dàng chuyển sang bằng chứng ZK theo cách hoàn toàn minh bạch đối với ứng dụng. Không có hệ thống nào khác cung cấp con đường di chuyển linh hoạt và suôn sẻ này.

Bạn có thể tập trung vào các vấn đề quan trọng khác

Chạy một chuỗi khối là một nhiệm vụ khó khăn và nó không chỉ liên quan đến việc viết nhiều mã phụ trợ. Phần lớn những gì chúng tôi làm tại Optimism tập trung vào việc cải thiện trải nghiệm của người dùng và nhà phát triển thông qua các công cụ hữu ích phía máy khách. Chúng tôi cũng đã dành nhiều thời gian và năng lượng để giải quyết các khía cạnh "mềm": nói chuyện với các dự án, tìm hiểu các điểm yếu và thiết kế các biện pháp khuyến khích. Bạn càng dành nhiều thời gian cho phần mềm chuỗi khối, bạn càng dành ít thời gian hơn để suy nghĩ về những thứ khác. Bạn luôn có thể cố gắng thuê thêm người, nhưng các tổ chức không mở rộng quy mô một cách tuyến tính và mỗi lần tuyển dụng mới sẽ làm tăng thêm gánh nặng liên lạc nội bộ.

Vì công việc mạch ZK có thể được thêm vào chuỗi đang chạy hiện có, nên bạn có thể xây dựng nền tảng lõi và phần mềm kiểm chứng song song. Ngoài ra, vì có thể sửa đổi ứng dụng khách mà không thay đổi mạch, nên bạn có thể tách biệt nhóm ứng dụng khách và chứng thực của mình. Một Bản tổng hợp lạc quan áp dụng cách tiếp cận này có thể đi trước các đối thủ ZK nhiều năm về hoạt động thực tế trên chuỗi.

một số kết luận

một số kết luận

Thành thật mà nói, tôi không thể thấy bất kỳ nhược điểm đáng kể nào đối với phương pháp này với giả định rằng chứng minh zkMIPS có thể được tối ưu hóa đáng kể theo thời gian. Tác động thực sự duy nhất mà tôi thấy đối với ứng dụng là chi phí gas cho các opcode khác nhau có thể cần được điều chỉnh để phản ánh thời gian thử nghiệm được thêm vào bởi các opcode đó. Nếu thực sự không thể tối ưu hóa câu tục ngữ này đến mức hợp lý, thì tôi nhận thất bại. Nếu thực sự có thể tối ưu hóa câu tục ngữ này, thì cách tiếp cận zkMIPS/zkVM dường như tốt hơn rất nhiều so với cách tiếp cận zkEVM hiện tại đến nỗi nó có thể khiến cách tiếp cận sau hoàn toàn lỗi thời. Điều này có vẻ giống như một tuyên bố cấp tiến, nhưng cách đây không lâu, các bằng chứng thất bại lạc quan một bước đã được thay thế hoàn toàn bằng các bằng chứng nhiều bước.

Nếu bạn nghĩ rằng tôi hoàn toàn sai về cách tiếp cận này, vui lòng liên hệ với tôi và cho tôi biết lý do.