Nhà nghiên cứu Ethereum: Bản tổng hợp gốc—siêu năng lực từ việc thực thi L1

Tác giả: Nhà nghiên cứu Ethereum Justin Drake, nhà nghiên cứu đạo đức; Người biên dịch: Tao Zhu, Golden Finance

Tác giả của bài viết này được gửi đến cộng đồng R&D Ethereum rộng lớn hơn. Những đóng góp quan trọng bắt đầu từ năm 2017, với việc mở khóa thiết kế tăng dần đáng kể qua nhiều năm. Những đột phá kỹ thuật zkVM gần đây đã dẫn đến việc khám phá không gian có thiết kế triệt để. Bài viết này chỉ là nỗ lực tốt nhất của tôi trong việc tạo ra một thiết kế mạch lạc cho một ý tưởng lớn cuối cùng có thể xuất hiện ở đây.

Tóm tắt

Chúng tôi đề xuất một trình biên dịch trước EXECUTE tinh tế và mạnh mẽ giúp hiển thị công cụ thực thi L1 EVM gốc cho lớp ứng dụng. Bản tổng hợp thực thi gốc ("gọi tắt là bản tổng hợp gốc") là một bản tổng hợp sử dụng EXECUTE để xác thực các chuyển đổi trạng thái EVM cho các lô giao dịch của người dùng. Bản tổng hợp gốc có thể được coi là "phân đoạn thực thi có thể lập trình", gói phần biên dịch trước trong các hàm dẫn xuất để xử lý logic hệ thống bên ngoài EVM, chẳng hạn như sắp xếp, bắc cầu, đưa vào bắt buộc, quản trị.

Vì quá trình biên dịch trước EXECUTE được trình xác minh thực hiện trực tiếp nên nó có tính đa dạng của máy khách (zk)EL và cung cấp tính tương đương EVM không có lỗi trong quá trình xây dựng và phù hợp với các bản nâng cấp Forked EVM tương thích về phía trước. Đối với các bản tổng hợp tương đương EVM muốn kế thừa hoàn toàn tính bảo mật của Ethereum, cần phải có một hình thức xem xét nội tâm EVM như biên dịch trước EXECUTE. Chúng tôi gọi các bản tổng hợp kế thừa hoàn toàn tính bảo mật của Ethereum là "các bản tổng hợp không cần tin cậy".

Việc biên dịch trước EXECUTE giúp đơn giản hóa đáng kể việc phát triển các bản tóm tắt tương đương EVM vì không cần cơ sở hạ tầng phức tạp (ví dụ: trò chơi phòng chống gian lận, mạch SNARK, ủy ban an toàn) để mô phỏng và bảo trì EVM. Với EXECUTE, tính năng tổng hợp gốc tối thiểu và tóm tắt dựa trên tổng hợp có thể được triển khai chỉ bằng một vài dòng mã Solidity bằng cách sử dụng các hàm dẫn xuất đơn giản, loại bỏ nhu cầu xử lý đặc biệt về sắp xếp, đưa vào bắt buộc hoặc quản trị.

Quan trọng nhất là Tính tổng hợp gốc có thể tận hưởng khả năng xử lý theo thời gian thực mà không cần lo lắng về bằng chứng thời gian thực, do đó đơn giản hóa đáng kể Khả năng kết hợp đồng bộ.

Bài viết này được chia thành hai phần, phần đầu tiên giới thiệu về quá trình biên dịch trước được đề xuất và cuối cùng là thảo luận về tập hợp gốc.

Phần 1 - THỰC HIỆN Biên dịch trước

Cấu trúc

THỰC HÀNH Biên dịch trước chấp nhận đầu vào pre_state_root, post_state_root, trace và gas_used. Nó trả về true khi và chỉ khi các điều kiện sau được đáp ứng:

• trace is Well -dấu vết thực thi được định dạng (chẳng hạn như danh sách giao dịch L2 và bằng chứng truy cập trạng thái tương ứng)

• Việc thực thi dấu vết không trạng thái bắt đầu tại pre_state_root và kết thúc tại post_state_root Kết thúc

• Việc thực hiện dấu vết không trạng thái sẽ tiêu tốn chính xác lượng khí gas đã sử dụng

Có cơ chế đo lường kiểu EIP-1559 và định giá lượng gas tích lũy được tiêu thụ bởi tất cả các cuộc gọi EXECUTE trong khối L1. Cụ thể, có giới hạn khí tích lũy EXECUTE_CUMULATIVE_GAS_LIMIT và mục tiêu khí tích lũy EXECUTE_CUMULATIVE_GAS_TARGET. (Khi L1 EVM có thể được trình xác thực thực thi ở trạng thái không trạng thái, thì giới hạn tích lũy và mục tiêu có thể được hợp nhất với cơ chế L1 EIP-1559.)

Việc gọi quá trình biên dịch trước sẽ tiêu tốn một lượng khí L1 cố định, EXECUTE_GAS_COST, cộng thêm gas_used * gas_price, trong đó gas_price (giá bằng ETH/gas) được đặt theo cơ chế kiểu EIP-1559. Ngay cả khi biên dịch trước trả về sai, toàn bộ số tiền tạm ứng sẽ được lấy.

Dấu vết phải trỏ đến dữ liệu Ethereum có sẵn từ dữ liệu cuộc gọi, đốm màu, trạng thái hoặc bộ nhớ.

Thực hiện lại

Nếu EXECUTE_CUMULATIVE_GAS_LIMIT đủ nhỏ, trình xác thực có thể chỉ cần thực hiện lại dấu vết để buộc THỰC HIỆN Tính đúng đắn của cuộc gọi. Việc triển khai ban đầu dựa trên việc thực hiện lại quá trình biên dịch trước có thể được sử dụng làm bước đệm, tương tự như việc tải xuống lại blob đơn giản của danksharding ban đầu cho đến danksharding đầy đủ. Lưu ý rằng việc thực thi lại đơn giản không yêu cầu tăng trưởng trạng thái hoặc tiêu tốn băng thông trên trình xác nhận và mọi chi phí thực thi đều có thể được song song trên các lõi CPU.

Người xác thực phải giữ một bản sao rõ ràng của dấu vết để thực thi lại, do đó ngăn chặn việc sử dụng con trỏ tới dữ liệu blob được lấy mẫu qua DAS (thay vì tải xuống). Lưu ý rằng tính năng tổng hợp gốc lạc quan vẫn có thể xuất bản dữ liệu tóm tắt dưới dạng các đốm màu, chỉ quay lại dữ liệu cuộc gọi trong các trò chơi có bằng chứng gian lận. Ngoài ra, hãy lưu ý rằng tập hợp gốc lạc quan có thể có giới hạn gas vượt xa EXECUTE_CUMULATIVE_GAS_LIMIT, vì quá trình biên dịch trước EXECUTE chỉ cần được gọi một lần trên phân đoạn EVM nhỏ để giải quyết thách thức chống gian lận.

Để ghi lại lịch sử, vào năm 2017 Vitalik đã đề xuất một bản biên dịch trước "EVM bên trong EVM" tương tự có tên là EXECTX.

Thực thi thông qua SNARK

Để mở khóa EXECUTE_CUMULATIVE_GAS_LIMIT lớn hơn, điều này đương nhiên sẽ cho phép người xác minh xác minh có chọn lọc SNARK bằng chứng. Từ giờ trở đi, chúng tôi giả sử việc thực thi bị trì hoãn theo vị trí trong đó các khối (hoặc giao dịch không hợp lệ) không hợp lệ được coi là không hoạt động. (Để biết thêm thông tin về việc thực thi bị trì hoãn, hãy xem bài đăng nghiên cứu đạo đức này, EIP này và thiết kế này của Francesco.) Việc thực thi bị trì hoãn theo vị trí sẽ mất vài giây (toàn bộ vị trí) để chứng minh. Họ cũng tránh khuyến khích các cuộc thi bằng chứng do MEV điều khiển, điều này sẽ tạo ra các vectơ tập trung.

Lưu ý rằng ngay cả khi EXECUTE được thực thi bởi SNARK thì không có hệ thống hoặc mạch bằng chứng rõ ràng nào được đưa vào sự đồng thuận. (Lưu ý rằng quá trình biên dịch trước EXECUTE không lấy bất kỳ bằng chứng rõ ràng nào làm đầu vào.) Thay vào đó, mỗi nhà điều hành đặt cược có thể tự do chọn ứng dụng khách xác thực zkEL yêu thích của họ, tương tự như cách các ứng dụng khách EL được chọn một cách chủ quan ngày nay. Phần tiếp theo, “Bằng chứng ngoài chuỗi”, giải thích lợi ích của quyết định thiết kế này.

Từ giờ trở đi, chúng tôi giả định rằng những người đề xuất thực thi đã trưởng thành trong bối cảnh phân tách người chứng minh-người đề xuất (APS) với các vị trí thực thi và đồng thuận xen kẽ. Để khuyến khích những người đề xuất thực thi hợp lý tạo bằng chứng kịp thời (trong vòng 1 vị trí), chúng tôi yêu cầu người chứng minh chỉ chứng nhận khối thực thi n+1 nếu có sẵn bằng chứng cho khối thực thi n. (Chúng tôi khuyên bạn nên đóng gói khối n+1 với bằng chứng THỰC HIỆN của khối n ở lớp p2p.) Những người đề xuất thực thi bỏ qua bằng chứng có thể bỏ lỡ vị trí của họ, dẫn đến bỏ lỡ phí và MEV. Chúng tôi tiếp tục áp dụng hình phạt cố định đối với các vị trí thực thi bị bỏ lỡ, đặt mức phạt đủ cao (ví dụ: 1 ETH) để luôn vượt quá chi phí của bằng chứng.

Lưu ý rằng trong bối cảnh APS, việc tạo khối đồng thuận không bị chặn bởi các khe thực thi bị bỏ lỡ. Tuy nhiên, điều quan trọng đối với các client đơn giản là tạo ra bằng chứng kịp thời để họ có thể dễ dàng đọc trạng thái ở phía chuỗi mà không cần phải thực thi lại trạng thái không trạng thái. Để đảm bảo tạo ra bằng chứng kịp thời cho các client hạng nhẹ, ngay cả trong trường hợp đặc biệt khi người đề xuất thực thi tiếp theo bỏ lỡ vị trí của mình, chúng tôi dựa vào giả định của người chứng minh thiểu số vị tha. Một câu tục ngữ vị tha duy nhất là đủ để tạo ra bằng chứng trong 1 ô. Để tránh những bằng chứng dư thừa không cần thiết, hầu hết những người chứng minh vị tha có thể đợi ở chế độ chờ và chỉ bắt đầu khi không có bằng chứng nào đến trong 1 khe, do đó hoạt động như một biện pháp dự phòng đối với độ trễ lên đến 2 khe.

Lưu ý rằng EXECUTE_CUMULATIVE_GAS_LIMIT cần được đặt đủ thấp để giả định về người chứng minh thiểu số vị tha là đáng tin cậy (và để việc thực hiện đề xuất không phức tạp về mặt phi thực tế). Một chiến lược thận trọng có thể là đặt EXECUTE_CUMULATIVE_GAS_LIMIT để máy tính xách tay (chẳng hạn như MacBook Pro cao cấp) có thể truy cập bằng chứng một khe cắm. Một chính sách thực dụng và tích cực hơn có thể là nhắm mục tiêu vào một tập hợp con GPU nhỏ và cuối cùng có thể là những người chứng minh SNARK ASIC sau khi chúng đủ phổ biến.

Bằng chứng ngoài chuỗi

Để nhắc lại, chúng tôi khuyên bạn không nên đưa bằng chứng zkEL EXECUTE lên chuỗi , nhưng nó được chia sẻ ngoài chuỗi. Không lưu bản chứng minh là một ý tưởng hay, được Vitalik đề xuất lần đầu tiên và có một số ưu điểm:

• < p>Tính đa dạng: Người xác thực có thể tự do lựa chọn người xác thực chứng thực (bao gồm hệ thống và mạch chứng thực) từ các nhóm phát triển mà họ tin tưởng, tương tự như cách người xác thực chọn khách hàng EL mà họ tin tưởng. Điều này mang lại sự mạnh mẽ thông qua sự đa dạng. Máy khách xác thực zkEL (và zkVM cơ bản cho một số máy khách) là phần mềm mã hóa phức tạp. Một lỗi trong bất kỳ ứng dụng khách nào sẽ không khiến Ethereum gặp sự cố.

• Tính trung lập: Việc có thị trường khách hàng xác thực zkEL cho phép lớp đồng thuận không chọn người chiến thắng về công nghệ. Ví dụ: thị trường zkVM có tính cạnh tranh cao và việc chọn một nhà cung cấp chiến thắng (chẳng hạn như Risc0, Succinct hoặc nhiều nhà cung cấp khác) có thể không được coi là trung lập.

• Đơn giản: Lớp đồng thuận không cần chứa trình xác nhận SNARK cụ thể, do đó đơn giản hóa đáng kể đặc điểm kỹ thuật của lớp đồng thuận. Chỉ cần đưa định dạng của bằng chứng truy cập trạng thái chứ không cần đưa vào chi tiết triển khai trình xác thực bằng chứng cụ thể.

• Tính linh hoạt: Nếu phát hiện ra lỗi hoặc tối ưu hóa, người xác thực bị ảnh hưởng có thể cập nhật ứng dụng khách của họ mà không cần hard fork.

Việc có bằng chứng ngoài chuỗi sẽ gây ra một số vấn đề phức tạp có thể quản lý được:

• Tải bằng chứng và phân mảnh p2p: Vì không có bằng chứng chính tắc duy nhất nên cần phải tạo nhiều bằng chứng (ít nhất một bằng chứng cho mỗi khách hàng zkEL). Mỗi tùy chỉnh ứng dụng khách zkEL (chẳng hạn như trao đổi một zkVM RISC-V lấy một zkVM khác) yêu cầu một chứng nhận khác. Tương tự, mỗi lần nâng cấp phiên bản zkEL đều yêu cầu chứng nhận khác nhau. Điều này sẽ dẫn đến tải bằng chứng tăng lên. Nó cũng sẽ phân mảnh mạng p2p hơn nữa nếu có các kênh tin đồn riêng biệt cho từng loại bằng chứng.

• Ít zkEL: Rất khó để khuyến khích một số lượng nhỏ zkEL tạo ra bằng chứng. Những người đề xuất thực hiện một cách hợp lý chỉ có thể tạo ra đủ bằng chứng để tiếp cận được đại đa số những người chứng minh mà không bỏ sót vị trí của họ. Để giải quyết vấn đề này, các nhà khai thác đặt cược có thể được khuyến khích chạy song song nhiều máy khách zkEL, tương tự như các nhà khai thác Vouch ngày nay. Việc chạy thiết lập k-of-n còn có thêm lợi ích là cải thiện tính bảo mật, đặc biệt là ngăn chặn các lỗ hổng bảo mật có thể cho phép kẻ tấn công tạo ra bằng chứng cho các lệnh gọi EXECUTE tùy ý (một tình huống không thể xảy ra với các máy khách EL truyền thống).

Bằng chứng ngoài chuỗi cũng sẽ làm giảm hiệu quả xử lý L2 theo thời gian thực:

• Không có DA thay thế: Vì đầu vào theo dõi của EXECUTE cần được cung cấp cho trình xác thực L1 nên L2 của quá trình xử lý theo thời gian thực (tức là L2 của gốc trạng thái chính tắc cập nhật ngay lập tức) L1 DA phải được sử dụng, nghĩa là tổng hợp. Lưu ý rằng L2 lạc quan với việc giải quyết trò chơi chống gian lận bị trì hoãn không có hạn chế này và có thể là một giá trị hợp lệ.

• Chi phí truy cập trạng thái: Vì dấu vết phải có khả năng thực thi không trạng thái nên nó phải bao gồm trạng thái được đọc hoặc viết, điều này giới thiệu một lượng nhỏ DA trên cao hơn so với khối L2 thông thường. Lưu ý rằng L2 lạc quan không có hạn chế này, vì trạng thái lá trie chỉ được yêu cầu trong các thử thách chống gian lận và người thách thức có thể tính toán lại lá trie.

• Sự khác biệt không có trạng thái: Vì việc chứng thực phải được cấp phép dựa trên dấu vết nên không thể tổng hợp các khác biệt về trạng thái. Tuy nhiên, bằng chứng truy cập không trạng thái hoặc chữ ký giao dịch EVM có thể được nén nếu bằng chứng chuyên biệt tương ứng được đưa vào sự đồng thuận.

Thực thi gốc RISC-V

Với sự hội tụ trên thực tế ngày nay với RISC-V zkVM, có thể có cơ hội để lộ các chuyển đổi trạng thái RISC-V ban đầu Cung cấp EVM (tương tự WASM trong môi trường Arbitrum Stylus) và giữ cho nó thân thiện với SNARK.

Phần 2 - Bản gốc cuộn

Đặt tên

Đầu tiên chúng ta thảo luận về cách đặt tên bản gốc để giải quyết một số vấn đề khó hiểu:

• Tên thay thế: Bản tổng hợp gốc trước đây được gọi là bản tóm tắt được lưu giữ. (Thuật ngữ "bản tổng hợp chuẩn" cũng được sử dụng ngắn gọn trong Polynya 12.) Thuật ngữ "được lưu giữ" sau đó đã bị loại bỏ để chuyển sang "gốc" để chỉ ra rằng các bản tổng hợp tương đương EVM hiện có có thể được nâng cấp tùy ý lên bản gốc. Cái tên "Native" được đề xuất độc lập vào tháng 11 năm 2022 bởi Dan Robinson và một cộng tác viên Lido muốn giấu tên.

• Dựa trên tổng hợp: Dựa trên tổng hợp và tổng hợp gốc là các khái niệm trực giao: "dựa trên" liên quan đến thứ tự L1, trong khi "gốc" có liên quan để thực hiện L1. Cả bản cuộn dựa trên và bản gốc đều được gọi một cách kỳ lạ là "bản cuộn siêu âm".

• Phân mảnh thực thi: Phân mảnh thực thi (tức là các bản sao được lưu giữ của chuỗi L1 EVM) là một khái niệm khác nhưng có liên quan đến tổng hợp gốc, Tập hợp gốc được định trước bởi vài năm. (Phân đoạn thực thi trước đây là “Giai đoạn 2” của lộ trình Ethereum 2.0.) Không giống như các bản tổng hợp gốc, phân đoạn thực thi không thể lập trình được, tức là không có tùy chọn nào cho quản trị tùy chỉnh, đặt hàng tùy chỉnh, mã thông báo gas tùy chỉnh, v.v. Các phân đoạn thực thi cũng thường được khởi tạo theo một số cố định (chẳng hạn như 64 hoặc 1.024 phân đoạn). Thật không may, Martin Köppelmann đã sử dụng thuật ngữ "bản địa L2" trong bài nói chuyện của mình về việc triển khai sharding tại Devcon 2024 7.

Lợi ích

Bản tổng hợp gốc có một số lợi ích mà chúng tôi sẽ trình bày chi tiết bên dưới:

• Đơn giản: Hầu hết sự phức tạp của VM tổng hợp gốc có thể được gói gọn thông qua quá trình biên dịch trước. Các loại tương đương EVM ngày nay, lạc quan và zk-rollup, có hàng nghìn dòng mã cho các trò chơi chống gian lận hoặc trình xác minh SNARK có thể được nén thành một dòng mã duy nhất. Bản tổng hợp gốc cũng không yêu cầu cơ sở hạ tầng hỗ trợ như mạng bằng chứng, tháp canh và ủy ban bảo mật.

• Bảo mật: Xây dựng trò chơi chống gian lận EVM hoặc trình xác minh SNARK không có lỗi là một nhiệm vụ kỹ thuật rất khó khăn và có thể yêu cầu xác minh chính thức sâu sắc. Ngày nay, mọi sự lạc quan và tổng hợp zk EVM đều có thể có một lỗ hổng nghiêm trọng trong chức năng chuyển đổi trạng thái EVM của nó. Để đề phòng các lỗ hổng, việc đặt hàng tập trung thường được sử dụng như một chiếc nạng để kiểm soát việc sản xuất khối đối nghịch. Việc thực thi quá trình biên dịch trước tự nhiên cho phép triển khai an toàn tính năng sắp xếp không được phép. Các bản tổng hợp không tin cậy kế thừa đầy đủ tính bảo mật L1 cũng kế thừa đầy đủ khả năng thay thế của nội dung L1.

• Tính tương đương của EVM: Ngày nay, cách duy nhất để giữ cho quá trình tổng hợp được đồng bộ hóa với các quy tắc EVM L1 là có quyền quản trị (thường là ủy ban bảo mật và/hoặc mã thông báo quản trị) phản ánh nâng cấp L1 EVM. (Các bản cập nhật EVM vẫn diễn ra thường xuyên thông qua các đợt hard fork khoảng một năm một lần.) Quản trị không chỉ là một vectơ tấn công, mà nói đúng ra, nó khác với L1 EVM và ngăn cản bất kỳ đợt tổng hợp nào đạt được sự tương đương EVM dài hạn thực sự. Mặt khác, bản tổng hợp gốc có thể được nâng cấp đồng thời với L1 mà không cần quản trị.

• Chi phí gas SNARK: Việc xác minh SNARK trên chuỗi rất tốn kém. Do đó, nhiều zk-rollup hiếm khi được giải quyết để giảm thiểu chi phí. Vì SNARK không được xác minh trên chuỗi nên quá trình biên dịch trước EXECUTE có thể được sử dụng để giảm chi phí xác minh. Nếu bạn đang sử dụng đệ quy SNARK để thực hiện hàng loạt bằng chứng EXECUTE cho nhiều cuộc gọi trong một khối, EXECUTE_GAS_COST có thể được đặt ở mức tương đối thấp.

• Khả năng kết hợp đồng bộ: Ngày nay, khả năng kết hợp đồng bộ với L1 yêu cầu bằng chứng thời gian thực đồng thời. Đạt được bằng chứng về độ trễ cực thấp (ví dụ: khoảng 100 mili giây) là một nhiệm vụ kỹ thuật đặc biệt khó khăn đối với các bản tổng hợp zk. Bằng cách sử dụng gốc trạng thái bị trì hoãn một khe, độ trễ bằng chứng của quá trình biên dịch trước thực thi gốc có thể được giảm xuống thành một khe đầy đủ.