Tác giả: Justin Drake, nhà nghiên cứu Ethereum, ethresearch; Biên dịch: Tao Zhu, Jinse Finance
Công lao của bài viết này phải được ghi nhận cho cộng đồng nghiên cứu và phát triển Ethereum rộng lớn hơn. Các đóng góp then chốt đến từ năm 2017, với những bước tiến lớn trong thiết kế qua nhiều năm. Những đột phá gần đây trong kỹ thuật zkVM đã kích hoạt một không gian thiết kế mới đầy hứa hẹn. Bài viết này chỉ là một nỗ lực để tạo ra một thiết kế liền mạch cho một ý tưởng lớn có thể cuối cùng đã đến.
Tóm tắt
Chúng tôi đề xuất một EXECUTE tiền xử lý thanh lịch và mạnh mẽ, để phơi bày động cơ thực thi EVM bản địa L1 cho tầng ứng dụng. Tổng hợp thực thi bản địa (gọi tắt là "tổng hợp bản địa") là một cách sử dụng EXECUTE để xác minh các giao dịch của người dùng theo lô thông qua các chuyển đổi trạng thái EVM. Có thể xem tổng hợp bản địa như là "phân mảnh thực thi có thể lập trình", đóng gói các tiền xử lý trong các hàm phái sinh để xử lý logic hệ thống ngoài EVM, chẳng hạn như sắp xếp, cầu nối, bắt buộc bao gồm, quản trị.
Do EXECUTE tiền xử lý được thực thi trực tiếp bởi người xác minh, nên nó hưởng lợi từ sự đa dạng của (zk)EL máy trạm và cung cấp tương đương EVM, tương đương này không có lỗi trong cấu trúc và tương thích về phía trước với các nâng cấp EVM thông qua hard fork L1. Đối với các tổng hợp tương đương EVM muốn hoàn toàn kế thừa bảo mật của Ethereum, các hình thức tự phản ánh EVM như EXECUTE là cần thiết. Chúng tôi sẽ gọi các tổng hợp hoàn toàn kế thừa bảo mật của Ethereum là "tổng hợp không cần tin tưởng".
EXECUTE tiền xử lý đơn giản hóa đáng kể việc phát triển các tổng hợp tương đương EVM, vì không cần cơ sở hạ tầng phức tạp (như trò chơi chống gian lận, mạch SNARK, ủy ban an toàn) để mô phỏng và duy trì EVM. Chỉ với vài dòng mã Solidity, sử dụng các hàm phái sinh đơn giản, có thể triển khai tổng hợp bản địa tối thiểu và dựa trên tổng hợp, mà không cần xử lý đặc biệt cho sắp xếp, bắt buộc bao gồm hoặc quản trị.
Quan trọng nhất, tổng hợp bản địa có thể hưởng lợi từ thanh toán thời gian thực, mà không cần lo lắng về chứng minh thời gian thực, do đó đơn giản hóa đáng kể khả năng tổng hợp có thể tổ hợp.
Bài viết này chia thành hai phần, đầu tiên giới thiệu về tiền xử lý được đề xuất, sau đó thảo luận về tổng hợp bản địa.
Phần 1 - Tiền xử lý EXECUTE
Cấu trúc
Tiền xử lý EXECUTE nhận đầu vào pre_state_root, post_state_root, trace và gas_used. Nó chỉ trả về true khi:
trace là một dấu vết thực thi hợp lệ (ví dụ: danh sách giao dịch L2 và các bằng chứng truy cập trạng thái tương ứng)
thực thi không trạng thái của trace bắt đầu từ pre_state_root và kết thúc ở post_state_root
thực thi không trạng thái của trace chính xác tiêu thụ gas_used gas
Có một cơ chế giống EIP-1559 để đo lường và định giá tổng gas tiêu thụ bởi tất cả các lệnh EXECUTE trong một khối L1. Cụ thể, có một giới hạn gas tích lũy EXECUTE_CUMULATIVE_GAS_LIMIT và một mục tiêu gas tích lũy EXECUTE_CUMULATIVE_GAS_TARGET. (Khi L1 EVM có thể được thực thi không trạng thái bởi người xác minh, giới hạn và mục tiêu tích lũy có thể được hợp nhất với cơ chế EIP-1559 của L1.)
Gọi tiền xử lý yêu cầu tiêu tốn một số lượng cố định L1 gas, EXECUTE_GAS_COST, cộng với gas_used * gas_price, trong đó gas_price (tính bằng ETH/gas) được thiết lập bởi cơ chế giống EIP-1559. Ngay cả khi tiền xử lý trả về false, khoản thanh toán trước đó vẫn được thu đầy đủ.
Dấu vết phải trỏ đến dữ liệu Ethereum có sẵn từ dữ liệu gọi, blob, trạng thái hoặc bộ nhớ.
Tái thực thi
Nếu EXECUTE_CUMULATIVE_GAS_LIMIT đủ nhỏ, người xác minh có thể đơn giản tái thực thi dấu vết để thực thi tính chính xác của lệnh EXECUTE. Triển khai ban đầu của tiền xử lý dựa trên tái thực thi có thể được sử dụng như một bước đệm, tương tự như tải lại đơn giản blob trong danksharding ban đầu. Lưu ý rằng, tái thực thi đơn giản sẽ không gây ra sự gia tăng trạng thái hoặc chi phí băng thông cho người xác minh, và bất kỳ chi phí thực thi nào cũng có thể được song song hóa trên các lõi CPU.
Người xác minh phải giữ một bản sao rõ ràng của dấu vết để tái thực thi, ngăn chặn việc sử dụng con trỏ đến dữ liệu blob được lấy mẫu thông qua DAS thay vì tải xuống. Lưu ý rằng, các tổng hợp bản địa lạc quan vẫn có thể công bố dữ liệu tổng hợp dưới dạng blob, chỉ rút lui sang dữ liệu gọi trong trò chơi chứng minh gian lận. Cũng lưu ý rằng, các tổng hợp bản địa lạc quan có thể có giới hạn gas vượt xa EXECUTE_CUMULATIVE_GAS_LIMIT, vì EXECUTE tiền xử lý chỉ cần được gọi một lần trên một đoạn EVM nhỏ để giải quyết thách thức chứng minh gian lận.
Như một ghi chép lịch sử, vào năm 2017, Vitalik đã đề xuất một tiền xử lý tương tự "EVM bên trong EVM" 16, được gọi là EXECTX.
Thực thi thông qua SNARK
Để mở khóa EXECUTE_CUMULATIVE_GAS_LIMIT lớn hơn, tự nhiên sẽ khiến người xác minh chọn lọc xác minh các bằng chứng SNARK. Từ đây, chúng tôi giả định một độ trễ thực thi theo thời gian, trong đó các khối (hoặc giao dịch) không hợp lệ được coi là không hoạt động. (Để biết thêm thông tin về thực thi trì hoãn, vui lòng xem bài đăng ethresearch 15, EIP 18 này và thiết kế của Francesco 19.) Thực thi trì hoãn theo thời gian sẽ tạo ra vài giây (toàn bộ khoảng thời gian) để chứng minh. Chúng cũng tránh được cuộc cạnh tranh chứng minh được thúc đẩy bởi MEV, điều này sẽ dẫn đến xu hướng tập trung hóa.
Lưu ý rằng, ngay cả khi EXECUTE được thực thi bằng SNARK, không có hệ thống chứng minh hoặc mạch cụ thể được đưa vào đồng thuận. (Lưu ý rằng, tiền xử lý EXECUTE không nhận 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 stake có thể tự do chọn bộ khách hàng (zk)EL xác minh mà họ tin tưởng nhất, tương tự như cách họ chọn khách hàng EL chủ quan ngày nay. Phần "Chứng minh ngoài chuỗi" tiếp theo sẽ giải thích lợi ích của quyết định thiết kế này.
Từ đây, chúng tôi giả định rằng các nhà đề xuất thực thi đã trưởng thành trong bối cảnh tách biệt người đề xuất-người xác minh (APS) với các khoảng thời gian thay phiên thực thi và đồng thuận. Để khuyến khích các nhà đề xuất thực thi hợp lý tạo bằng chứng kịp thời (trong 1 khoảng thời gian), chúng tôi yêu cầu người xác minh chỉ xác minh thực thi khối n+1 khi bằng chứng thực thi khối n có sẵn. (Chúng tôi khuyến nghị nên đóng gói khối n+1 với bằng chứng EXECUTE của khối n trên lớp p2p.) Các nhà đề xuất thực thi bỏ qua việc tạo bằng chứng có thể bỏ lỡ khoảng thời gian của họ, dẫn đến mất phí và MEV. Chúng tôi tiếp tục áp đặt một hình phạt cố định cho các khoảng thời gian thực thi bị bỏ lỡ, đủ cao (ví dụ: 1 ETH) để luôn vượt quá chi phí chứng minh.
Lưu ý rằng, trong bối cảnh APS, việc tạo ra các khối đồng thuận sẽ không bị cản trở bởi các khoảng thời gian thực thi bị bỏ lỡ. Tuy nhiên, việc tạo bằng chứng kịp thời rất quan trọng đối với các máy trạm nhẹ, để họ có thể dễ dàng đọc trạng thái trên chuỗi mà không cần thực thi lại không trạng thái. Để đảm bảo việc tạo bằng chứng kịp thời cho các máy trạm nhẹ, ngay cả trong trường hợp đặc biệt khi nhà đề xuất tiếp theo bỏ lỡ khoảng thời gian của họ, chúng tôi dựa vào giả định về sự vị tha của thiểu số. Một người chứng minh vị tha duy nhất đủ để tạo bằng chứng trong 1 khoảng thời gian. Để tránh các bằng chứng d冗thừa, đa số người chứng minh vị tha có thể chờ đợi và chỉ khởi động khi không có bằng chứng đến trong 1 khoảng thời gian, đóng vai trò là biện pháp an toàn tối đa 2 khoảng thời gian.
Lưu ý rằng, EXECUTE_CUMULATIVE_GAS_LIMIT cần được đặt đủ thấp để giả định về sự vị tha của thiểu số trở nên đáng tin cậy (cũng như để các đề xuất thực thi không trở nên quá phức tạp không thực tế). Một chiến lược bảo thủ có thể là đặt EXECUTE_CUMULATIVE_GAS_LIMIT để một chiếc laptop (ví
Dưới đây là bản dịch tiếng Việt của nội dung trên:Tải chứng minh và phân mảnh p2p: Do không có một tiêu chuẩn chứng minh duy nhất, nên cần phải tạo ra nhiều chứng minh (ít nhất một cho mỗi máy trạm zkEL). Mỗi phiên bản zkEL được tùy chỉnh (ví dụ: thay đổi một RISC-V zkVM bằng một cái khác) đều yêu cầu chứng minh khác nhau. Tương tự, mỗi bản nâng cấp zkEL cũng yêu cầu chứng minh khác nhau. Điều này sẽ dẫn đến tăng tải chứng minh. Nếu mỗi loại chứng minh đều có kênh thông tin riêng, nó sẽ tiếp tục phân mảnh mạng p2p.
Ít zkEL: Rất khó để khuyến khích các zkEL ít tạo ra chứng minh. Các nhà đề xuất hợp lý có thể chỉ tạo đủ chứng minh để đạt được đa số chứng minh, mà không bỏ lỡ khoảng thời gian của họ. Để giải quyết vấn đề này, có thể khuyến khích các nhà điều hành stake chạy nhiều máy trạm zkEL song song, tương tự như các nhà điều hành Vouch 4 ngày nay. Chạy cài đặt k-of-n cũng có lợi ích bổ sung về tăng cường bảo mật, đặc biệt là có thể ngăn chặn các lỗ hổng tính toán, cho phép kẻ tấn công tạo chứng minh cho bất kỳ lệnh EXECUTE nào (điều này không phổ biến đối với các máy trạm EL truyền thống).
Chứng minh ngoài chuỗi cũng sẽ làm giảm hiệu quả thanh toán thời gian thực của L2:
Không có DA thay thế: Do việc theo dõi đầu vào EXECUTE cần được cung cấp cho người xác minh L1, nên L2 thanh toán thời gian thực (tức là cập nhật ngay lập tức rễ trạng thái chuẩn của L2) phải tiêu thụ DA L1, tức là tổng hợp. Lưu ý rằng các L2 lạc quan, nơi thanh toán bị trì hoãn thông qua trò chơi chứng minh gian lận, không có hạn chế này và có thể là giá trị hợp lệ.
Chi phí truy cập trạng thái: Do việc theo dõi phải là không trạng thái có thể thực thi, nên nó phải bao gồm các lá trie trạng thái được đọc hoặc ghi, điều này đưa vào một lượng nhỏ chi phí DA so với các khối L2 điển hình. Lưu ý rằng các L2 lạc quan không có hạn chế này, vì chỉ cần các lá trie trạng thái trong thách thức chứng minh gian lận, người thách thức có thể tái tính toán các lá trie.
Không có sự khác biệt về trạng thái: Do có một dấu vết nhất định, chứng minh phải là không cần phép, do đó không thể tổng hợp các khác biệt về trạng thái. Tuy nhiên, nếu các chứng minh chuyên dụng tương ứng được đưa vào đồng thuận, thì có thể nén các chứng minh truy cập không trạng thái hoặc chữ ký giao dịch EVM.
Thực thi gốc RISC-V
Với sự hội tụ sự thật về RISC-V zkVM 31 ngày nay, có thể có cơ hội để phơi bày trạng thái chuyển đổi RISC-V nội bộ cho EVM (tương tự như môi trường Arbitrum Stylus 5) và vẫn duy trì tính thân thiện với SNARK.
Phần 2 - Rollup gốc
Đặt tên
Trước tiên, chúng tôi sẽ thảo luận về việc đặt tên Rollup gốc để giải quyết một số vấn đề dễ gây nhầm lẫn:
Tên thay thế: Rollup gốc trước đây được gọi là Rollup được ghi nhận, ví dụ: xem tài liệu 13 và tài liệu 7. (Thuật ngữ "Rollup chuẩn" cũng được sử dụng ngắn hạn trong Polynya 12.) Sau đó, thuật ngữ "được ghi nhận" đã bị bỏ và thay thế bằng "gốc" để chỉ ra rằng các Rollup tương đương EVM hiện có có thể chọn nâng cấp thành gốc. Cái tên "gốc" được Dan Robinson và một người đóng góp ẩn danh của Lido đề xuất độc lập vào tháng 11 năm 2022.
Dựa trên Rollup: Rollup dựa trên và Rollup gốc là các khái niệm vuông góc: "Dựa trên" liên quan đến sắp xếp L1, trong khi "gốc" liên quan đến thực thi L1. Cả Rollup dựa trên và gốc đều được gọi một cách lạc quan là "Rollup siêu âm".
Phân mảnh thực thi: Phân mảnh thực thi (tức là bản sao được ghi nhận của chuỗi EVM L1) là một khái niệm khác nhưng liên quan đến Rollup gốc, xuất hiện vài năm trước Rollup gốc. (Phân mảnh thực thi trước đây là "Giai đoạn 2" trong lộ trình Ethereum 2.0.) Khác với Rollup gốc, phân mảnh thực thi không có khả năng lập trình, nghĩa là không có tùy chỉnh quản trị, sắp xếp tùy chỉnh, token gas tùy chỉnh, v.v. Phân mảnh thực thi cũng thường được cụ thể hóa bằng số lượng cố định các phân mảnh (ví dụ: 64 hoặc 1.024). Không may, Martin Köppelmann đã sử dụng thuật ngữ "L2 gốc" trong bài thuyết trình về phân mảnh thực thi tại Devcon 2024 7.
Lợi ích
Rollup gốc có một số lợi ích, chúng tôi sẽ thảo luận chi tiết dưới đây:
Tính đơn giản: Phần lớn độ phức tạp của máy ảo Rollup gốc có thể được đóng gói bằng cách sử dụng các tiền xử lý. Hiện nay, optimism và zk-rollup tương đương với EVM có hàng nghìn dòng mã cho trò chơi chứng minh gian lận hoặc bộ xác minh SNARK của họ, những thứ này có thể được nén thành một dòng mã. Rollup gốc cũng không cần cơ sở hạ tầng phụ trợ như mạng chứng minh, đài quan sát và ủy ban an toàn.
Bảo mật: Xây dựng một trò chơi chứng minh gian lận EVM hoặc bộ xác minh SNARK không có lỗi là một nhiệm vụ kỹ thuật rất khó khăn, có thể yêu cầu xác minh hình thức sâu. Hiện nay, mỗi optimism và zk EVM rollup có rất nhiều lỗ hổng nghiêm trọng trong hàm chuyển đổi trạng thái EVM của họ. Để ngăn chặn các lỗ hổng, thường được sử dụng sắp xếp tập trung như một cây gậy để kiểm soát sản xuất khối đối kháng. Các tiền xử lý thực thi gốc cho phép triển khai an toàn không cần phép của sắp xếp. Các rollup không cần tin tưởng hoàn toàn kế thừa bảo mật L1 và tính tương hỗ tài sản.
Tương đương EVM: Hiện nay, cách duy nhất để giữ cho rollup đồng bộ với các quy tắc EVM L1 là để cho quản trị (thường là ủy ban an toàn và/hoặc token quản trị) phản ánh các nâng cấp EVM L1. (Các bản cập nhật EVM vẫn được thực hiện định kỳ thông qua các hard fork khoảng một lần mỗi năm.) Quản trị không chỉ là một phương tiện tấn công, mà về mặt nghiêm ngặt, nó cũng đi ngược lại EVM L1 và ngăn cản bất kỳ rollup nào đạt được tương đương EVM thực sự lâu dài. Mặt khác, Rollup gốc có thể đồng bộ hóa với L1 mà không cần quản trị.
Chi phí gas SNARK: Chi phí xác minh SNARK trên chuỗi rất cao. Do đó, nhiều zk-rollup hiếm khi kết toán để giảm chi phí. Vì SNARK không được xác minh trên chuỗi, nên có thể sử dụng tiền xử lý EXECUTE để giảm chi phí xác minh. Nếu sử dụng đệ quy SNARK để batch xử lý chứng minh EXECUTE của nhiều lệnh trong một khối, EXECUTE_GAS_COST có thể được đặt tương đối thấp.
Tính có thể thành phần đồng bộ: Hiện nay, tính có thể thành phần đồng bộ với L1 yêu cầu chứng minh thời gian thực cùng khe. Đối với zk rollups, việc thực hiện chứng minh độ trễ siêu thấp (ví dụ: khoảng 100 mili giây) là một nhiệm vụ kỹ thuật đặc biệt thách thức. Bằng cách sử dụng độ trễ trạng thái rễ khe đầy đủ, có thể nới lỏng độ trễ chứng minh của tiền xử lý thực thi gốc lên một khe đầy đủ.
