Sự kết hợp giữa ZK và OP có phải là tương lai của Ethereum Rollup không?

Tiêu đề gốc: "OP+ZK, Hybrid Rollup có trở thành tương lai cuối cùng của việc mở rộng Ethereum không?" "

Bài gốc của @kelvinfichter

Biên soạn gốc: Jaleel, BlockBeats

Gần đây tôi đã khá tin rằng 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. Trong bài đăng này, tôi sẽ cố gắng trình bày những điều cơ bản về những gì tôi tưởng tượng về kiến trúc này và lý do tại sao tôi tin rằng đây là hướng chúng ta nên hướng tới. Lưu ý rằng tôi dành phần lớn thời gian của mình để làm việc về Chủ nghĩa lạc quan, hay còn gọi là Bản tổng hợp lạc quan, nhưng tôi không phải là chuyên gia về ZK. Nếu tôi có bất kỳ sai lầm nào khi nói về ZK, vui lòng liên hệ với tôi và tôi sẽ sửa.

Tôi không có ý định mô tả chi tiết nguyên lý hoạt động của ZK và Rollup lạc quan trong bài viết này, nếu dành thời gian để giải thích bản chất của Rollup thì bài viết này sẽ quá dài. Vì vậy bài viết này dựa trên cơ sở bạn đã có hiểu biết nhất định về các công nghệ này, tất nhiên không cần phải là chuyên gia nhưng ít nhất bạn cũng nên biết ZK và Optimistic Rollup là gì cũng như cơ chế hoạt động chung của chúng. Dù sao, xin vui lòng đọc bài viết này.

Hãy bắt đầu với Tổng hợp lạc quan

Hệ thống kết hợp ZK và Optimistic Rollup ban đầu dựa trên Optimistic Rollup dựa trên kiến trúc Bedrock của Optimism. Bedrock được thiết kế để tương thích tối đa ("tương đương với EVM") với Ethereum bằng cách chạy ứng dụng khách thực thi gần như giống hệt với ứng dụng khách Ethereum. Bedrock tận dụng mô hình phân tách ứng dụng khách đồng thuận/thực thi sắp tới của Ethereum, giảm đáng kể sự khác biệt so với EVM (tất nhiên sẽ luôn có một số thay đổi trong quá trình thực hiện, nhưng chúng tôi có thể xử lý được).

Liệu sự kết hợp giữa ZK và OP có phải là tương lai của Ethereum Rollup không?

Giống như tất cả các Rollup tốt, Optimism trích xuất dữ liệu khối/giao dịch từ Ethereum, sau đó 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 và cung cấp dữ liệu này cho ứng dụng khách thực thi L2 để thực thi. Kiến trúc này giải được nửa đầu của câu đố "Bản tổng hợp lý tưởng" và mang lại cho chúng tôi L2 tương đương với EVM.

Tất nhiên, vấn đề chúng ta vẫn cần giải quyết bây giờ là nói cho Ethereum biết điều gì đã xảy ra bên trong Chủ nghĩa lạc quan theo một cách có thể kiểm chứng được. Nếu vấn đề này không được giải quyết, hợp đồng thông minh 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 thể rút tài sản của họ. Mặc dù có thể thực hiện tổng số một chiều trong một số trường hợp nhưng trong hầu hết các trường hợp, tổng số hai chiều sẽ hiệu quả hơn.

Bằng cách cung cấp một số loại cam kết đối với trạng thái này và bằng chứng rằng cam kết này là chính xác, chúng tôi có thể truyền đạt trạng thái của tất cả các Bản tổng hợp tới Ethereum. Nói cách khác, chúng tôi đang chứng minh rằng "Chương trình tổng số" đã được thực thi chính xác. Sự khác biệt đáng kể 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 cung cấp bằng chứng rõ ràng không có kiến thức để chứng minh việc thực thi chính xác chương trình. Trong Tổng hợp lạc quan, bạn có thể đưa ra tuyên bố về lời hứa mà không cần cung cấp bằng chứng rõ ràng. Bằng cách thách thức và đặt câu hỏi về tuyên bố của bạn, những người dùng khác có thể buộc bạn tham gia vào một "trò chơi" cân nhắc và thách thức qua lại để xác định ai cuối cùng là Có.

Tôi sẽ không đi vào chi tiết về những thách thức của Tổng hợp lạc quan. Điều đáng chú ý là trạng thái nghệ thuật ở giai đoạn này đang biên dịch chương trình của bạn (Geth EVM + một số bit bên lề trong trường hợp Lạc quan) 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 chương trì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 bao gồm đầy đủ 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 tuyến, bạn sẽ có Bản tổng hợp lạc quan đầy đủ chức năng.

Chuyển sang ZK Rollup

Nhìn chung, tôi tin chắc rằng Bản tổng hợp lạc quan sẽ thống trị trong 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 không đồng ý với quan điểm này. Tôi cảm thấy rằng tính đơn giản và tính linh hoạt tương đối hiện tại của Bản tổng hợp lạc quan có nghĩa là chúng có thể dần dần được chuyển đổi thành Bản tổng hợp ZK. Nếu chúng ta có thể tìm thấy một mô hình để thực hiện quá trình chuyển đổi này, thì thay vì cố gắng xây dựng một hệ sinh thái ZK kém linh hoạt và mong manh hơn, chúng ta có thể chỉ cần triển khai vào một hệ sinh thái Tổng hợp Lạc quan đã có sẵ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 hệ sinh thái OP hiện đại hiện có (như Bedrock) chuyển đổi liền mạch sang hệ sinh thái ZK. Tôi tin rằng điều này không chỉ khả thi mà còn là một cách vượt xa cách tiếp cận zkEVM hiện tại.

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

Tuy nhiên, L2 của chúng tôi không gì khác hơn là một chương trình chạy trên một máy đơn giản như MIPS. Chúng tôi hoàn toàn có thể xây dựng một mạch ZK cho một cơ chế đơ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 xuất bản bằng chứng hợp lệ cho Chủ nghĩa lạc quan. Đó là đơn giản trong thực tế.

Tại sao phương pháp này đáng tin cậy?

Chỉ cần làm rõ nhanh: Mặc dù trong phần này, tôi đề cập đến "zkMIPS", ý tôi thực sự là nó như một thuật ngữ cho tất cả các máy ảo bằng chứng không kiến thức chung và đơn giản hóa (zkVM).

zkMIPS dễ hơn zkEVM

Xây dựng zkMIPS (hoặc bất kỳ loại máy ảo zk nào khác) có một lợi thế lớn so với zkEVM: 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 điều chỉnh, opcode thay đổi và các yếu tố được thêm hoặc xóa. Và MIPS-V đã không thay đổi kể từ năm 1996. Tập trung vào zkMIPS và bạn đang xử lý một không gian có vấn đề cố định. Bạn không cần thay đổi hoặc thậm chí 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 thông tin quan trọng khác là zkMIPS linh hoạt hơn zkEVM. Với zkMIPS, bạn có thể thay đổi mã máy khách theo ý muốn, thực hiện nhiều tối ưu hóa khác nhau hoặc cải thiện trải nghiệm người dùng mà không cần cập nhật mạch tương ứng. Bạn thậm chí có thể tạo một thành phần cốt lõi biến bất kỳ chuỗi khối nào thành ZK Rollup, không chỉ Ethereum.

Nhiệm vụ của bạn biến thành thời gian chứng minh

Thời gian của việc chứng minh tri thức bằng không tỷ lệ theo hai trục: số lượng ràng buộc và kích thước của 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 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ể và thời gian chứng minh tổng thể của bạn cũng vậy.

Tuy nhiên, giảm thời gian kiểm chứng cũng là một vấn đề bắt nguồn sâu xa trong miền Web2. Cho rằng kiến trúc máy MIPS khó có thể thay đổi sớm, chúng tôi có thể tối ưu hóa mạch và hiệu chuẩn cao bất kể những thay đổi trong tương lai đối với EVM. Tôi cảm thấy khá tự tin khi thuê một kỹ sư phần cứng cao cấp để tối ưu hóa một vấn đề đã được xác định rõ ràng, có thể gấp mười hoặc thậm chí gấp trăm lần số lượng kỹ sư xây dựng và xem xét một mục tiêu zkEVM đang di chuyển. Một công ty như Netflix có thể có một số lượng lớn kỹ sư phần cứng tối ưu hóa chip chuyển mã và họ có khả năng sẵn sàng chi nhiều quỹ đầu tư mạo hiểm để thực hiện thử thách ZK thú vị này.

Thời gian chứng minh ban đầu cho một mạch như thế nà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 7 ngày rút khỏi Chủ nghĩa lạc quan hiện tại và chúng tôi có thể bắt đầu quá trình thử thách để xem xét loại bỏ Chủ nghĩa lạc quan. Chạy một châm ngôn trong 7 ngày có lẽ vẫn còn quá đắt, vì vậy chúng tôi có thể đợi lâu hơn một chút, nhưng vấn đề là có thể chấp nhận được. Bạn thậm chí có thể chạy cả hai hệ thống bằng chứng cùng một lúc, vì vậy chúng tôi có thể bắt đầu sử dụng bằng chứng ZK nhanh nhất có thể và quay lại bằng chứng Lạc quan nếu phương pháp chứng minh không thành công vì bất kỳ lý do gì. Khi sẵn sàng, bằng chứng Lạc quan có thể được xóa theo cách hoàn toàn trong suốt đối với ứng dụng, do đó, Bản tổng hợp lạc quan của bạn trở thành Bản tổng hợp ZK.

Bạn có thể đi và quan tâm đến các vấn đề quan trọng khác

Chạy một chuỗi khối là một vấn đề phức tạp liên quan đến nhiều thứ hơn là chỉ viết nhiều mã phụ trợ. Tại Optimism, phần lớn công việc của chúng tôi 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 bằng cách cung cấp 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 cho các vấn đề "nhẹ nhàng": trò chuyện với các dự án, hiểu điểm yếu của họ 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, bạn càng có ít thời gian hơn để giải quyết những việc khác này. Mặc dù 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 chi phí liên lạc nội bộ.

Vì công việc của mạch không kiến thức có thể được áp dụng trực tiếp cho chuỗi đang chạy, nên bạn có thể xây dựng nền tảng cốt lõi và phát triển phần mềm kiểm chứng cùng một lúc. 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 riêng ứng dụng khách và nhóm chứng minh của mình. Một bản tổng hợp lạc quan theo cách này có thể đi trước nhiều năm so với các đối thủ cạnh tranh không có kiến thức về hoạt động thực tế trên chuỗi.

Tóm lại là

Thẳng thắn mà nói, tôi không thấy bất kỳ nhược điểm đáng kể nào đối với chứng minh zkMIPS, trừ khi nó không 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 của các opcode khác nhau có thể cần được điều chỉnh để phản ánh thời gian kiểm chứng tăng lên cho các opcode này. Nếu thực sự không thể tối ưu hóa câu tục ngữ này ở mức hợp lý, thì tôi thừa nhận mình đã thất bại. Nhưng nếu có thể tối ưu hóa câu tục ngữ này, thì cách tiếp cận zkMIPS/zkVM có thể thay thế hoàn toàn cách tiếp cận zkEVM hiện tại. Điều đó nghe 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.

liên kết gốc

Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • Bình luận
  • Chia sẻ
Bình luận
0/400
Không có bình luận
  • Ghim
Giao dịch tiền điện tử mọi lúc mọi nơi
qrCode
Quét để tải xuống ứng dụng Gate
Cộng đồng
Tiếng Việt
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)