Xin cảm ơn Péter Garamvölgyi , Thomas Thiery , Francesco Risitano và Jihoon Song vì những phản hồi và nhận xét.
Bài viết sau đây dựa trên hoặc liên quan đến các EIP ở các giai đoạn tích hợp rất khác nhau, cụ thể là: FOCIL (SFI), Bằng chứng thực thi tùy chọn (PFI), Danh sách truy cập cấp khối (SFI), Trạng thái không xác thực một phần chỉ dựa trên tính hợp lệ (không có Đề xuất cải tiến Ethereum (EIP)), Tổng hợp gốc (chưa được đề xuất). Do đó, các chi tiết dự kiến sẽ thay đổi theo thời gian. Mặc dù nghiên cứu này chủ yếu được thúc đẩy bởi nhu cầu tìm kiếm một cơ chế giao dịch bắt buộc đơn giản cho tổng hợp gốc, nhưng các phát hiện có thể được áp dụng chung cho tất cả Máy ảo Ethereum (EVM) L2, bao gồm cả những EVM hiện có.
Tóm tắt
Chúng tôi trình bày một phương thức triển khai cơ chế giao dịch bắt buộc thông qua FOCIL có thể được sử dụng để bỏ qua các bộ điều khiển trình tự tập trung của Máy ảo Ethereum (EVM) L2 mà không cần sửa đổi hàm chuyển trạng thái hoặc các loại giao dịch mới, khác với các giải pháp hiện có.
Lý lịch
FOCIL cập nhật STF của Ethereum bằng cách thêm một danh sách giao dịch mới (danh sách bao gồm) mà Block phải đáp ứng để được chứng thực. Các giao dịch này được lựa chọn bởi một "ủy ban IL" ở phía CL, bao gồm 16 trình xác thực và được chuyển đến EL thông qua API Engine được cập nhật.
def state_transition ( chain: BlockChain, block: Block, inclusion_list_transactions: Tuple [LegacyTransaction | Bytes, ...] ) -> None :Các giao dịch trong IL vẫn có thể được loại trừ khỏi Block một cách hợp lệ vì ba lý do sau:
Các kiểm tra nội tại thất bại: giao dịch không đúng định dạng, ID chuỗi sai, thiếu gas, chữ ký không hợp lệ, tham số nằm ngoài giới hạn;
Kiểm tra trạng thái thất bại: Nonce không khớp, số dư không đủ;
Các bước kiểm tra liên quan đến Block bị lỗi: không đủ gas (so với phí cơ bản), không đủ dung lượng trong Block.
Mặc dù người xây dựng có thể cố ý loại trừ một giao dịch thông qua "nhồi nhét Block ", giao thức vẫn cung cấp khả năng chống kiểm duyệt bằng cách gây ra chi phí theo cấp số nhân cho kẻ tấn công bằng cách tăng phí cơ bản Đề xuất cải tiến Ethereum (EIP)-1559 và giữ giao dịch trong mempool, giao dịch này sẽ được chèn vào IL tiếp theo.
Tất cả Máy ảo Ethereum (EVM) L2 hiện có đều thực hiện các giao dịch bắt buộc bằng cách giới thiệu các loại giao dịch mới và sửa đổi hàm chuyển đổi trạng thái. Ngăn xếp OP giới thiệu loại “giao dịch đã gửi”, được tạo ra từ sự kiện L1, tự động được chèn vào đầu Block L2 tương ứng, không có chữ ký trên L2, trả phí gas trên L1 và không tiêu tốn gas trên L2. Tất cả các thay đổi của op-geth trên geth có thể được tìm thấy ở đây . Ngăn xếp Arbitrum cũng giới thiệu một loại giao dịch mới (thực ra là nhiều loại) không có chữ ký, việc đưa vào được thực thi bởi một hàng đợi giao dịch bắt buộc trên chuỗi, nhưng phải trả phí gas trên L2. Tất cả các thay đổi trên geth có thể được tìm thấy ở đây . Quan trọng nhất, trong cả hai trường hợp, một giao dịch hợp lệ được đưa vào danh sách các giao dịch bị bắt buộc đưa vào sẽ không bao giờ bị loại trừ một cách hợp lệ do Block đầy hoặc phí cơ bản: không gian dành cho chúng luôn được dành riêng và hoặc phí cơ bản không được tính hoặc một cơ chế thử lại được thực hiện.
Cơ chế
Ý tưởng cốt lõi là logic CL và mempool của FOCIL có thể được thay thế và sao chép hoàn toàn bằng một hợp đồng thông minh trên L1: người dùng gửi các giao dịch bắt buộc đến một hợp đồng thông minh L1 thay vì một mempool L2 truyền thống (có thể thông qua FOCIL L1!), hợp đồng này sẽ xây dựng danh sách bao gồm và chuyển nó làm đầu vào cho trình xác minh STF L2, theo cách tương tự như API Engine chuyển nó cho EL. STF L2 được giả định là hoàn toàn giống với chức năng STF không trạng thái được giới thiệu bởi Đề xuất cải tiến Ethereum (EIP)-8025 . Vì 8025 chưa được xây dựng trên nền tảng Hegotá và do đó không tính đến FOCIL, chúng ta có thể tự do hình dung giao diện IL không trạng thái.
Hình minh họa cách “L2 FOCIL” thay thế các thành phần CL và EL liên quan đến việc kiểm tra FOCIL cho L1.
Để mô phỏng hành vi của mempool và đảm bảo khả năng chống kiểm duyệt, chúng ta cần đảm bảo rằng các giao dịch kết thúc trong L2 IL không bị tự động loại bỏ, vì không giống như các cơ chế giao dịch bắt buộc hiện có, FOCIL thực sự không đảm bảo việc đưa vào một Block cụ thể. Hơn nữa, tất cả các giao dịch không hợp lệ không nên làm ô nhiễm IL càng nhiều càng tốt, để ngăn chặn việc lãng phí tính toán ở phía người chứng minh và các cuộc tấn công DoS vào các giao dịch hợp lệ.
Chúng tôi giả định rằng mỗi lô L2 do nhà điều hành đăng tải tương ứng với một Block L2, nếu không nhà điều hành luôn có thể tạo ra các khối trống để giảm phí cơ bản và thực hiện các cuộc tấn công nhồi Block một cách rẻ tiền. Điều này hiện không đúng với hầu hết các rollup, nhưng các khối nhanh hơn có thể được mô phỏng bằng các kỹ thuật như flashblocks .
Do đó, chúng tôi thiết kế một hợp đồng giao dịch bắt buộc như sau: người dùng gửi các giao dịch đã ký vào một danh sách trên chuỗi được sắp xếp theo `maxFeePerGas`, giảm dần. Khi gửi, tất cả các kiểm tra nội tại (tức là không trạng thái) sẽ được thực hiện. Như đã giải thích trong bài đăng nghiên cứu về Trạng thái một phần chỉ dựa trên tính hợp lệ (VOPS) và tại đây , việc thực hiện các kiểm tra có trạng thái là điều cơ bản để duy trì một mempool lành mạnh: mặc dù trong L2 FOCIL, một giao dịch được gửi sẽ trả phí gas trên L1, nhưng việc đưa các giao dịch có `maxFeePerGas` rất cao nhưng có Nonce không hợp lệ hoặc số dư không đủ vào đầu danh sách là rất dễ dàng, khiến IL chỉ chứa các giao dịch không hợp lệ. Do đó, VOPS đề xuất rằng các nút không trạng thái vẫn nên duy trì số dư và Nonce của mỗi tài khoản thông qua BAL . Mặc dù Máy ảo Ethereum (EVM) L2 cũng có thể tạo và công bố BAL, nhưng việc duy trì số dư và nonce trong hợp đồng thông minh là không khả thi: đối với L1, dung lượng lưu trữ ước tính đã lên tới ~8,4GB, và đối với L2, con số này có thể cao hơn đáng kể. Do đó, chúng tôi yêu cầu người dùng gửi bằng chứng tài khoản, được lấy thông qua eth_getProof so với trạng thái L2 gần đây để được chấp nhận vào danh sách. Vì FOCIL không cho chúng ta biết liệu một giao dịch trong danh sách bao gồm đã được đưa vào hay chưa và lý do tại sao, nên các giao dịch kết thúc trong danh sách bao gồm, ngay cả sau các kiểm tra này, không thể tự động bị loại bỏ. Có thể sử dụng hai cơ chế:
Một chức năng "cắt tỉa" Không cần cho phép được thêm vào, khi có bằng chứng tài khoản so sánh với một Block mới hơn, sẽ chứng minh rằng Nonce đã thay đổi hoặc số dư đã trở nên không đủ. Điều quan trọng cần nhớ là chỉ kiểm tra Nonce thôi là chưa đủ vì Đề xuất cải tiến Ethereum (EIP)-7702 đã phá vỡ quy tắc bất biến rằng số dư tài khoản chỉ có thể giảm nếu Nonce tăng. Để đạt được tính tương thích về khuyến khích, những người gửi giao dịch bắt buộc có thể được yêu cầu gửi một khoản tiền bảo đảm nhỏ để hoàn trả cho người cắt tỉa khi giao dịch bị vô hiệu hóa.
Nhà điều hành cung cấp bằng chứng Merkle chống lại gốc giao dịch trong quá trình thanh toán. Vì IL được STF xác thực (ví dụ: thông qua bằng chứng ZK), chúng ta có thể kiểm tra xem nếu một giao dịch chưa được đưa vào và vẫn còn chỗ trống trong Block, thì giao dịch đó phải không hợp lệ và có thể bị loại bỏ. Chi phí ước tính: ~275k gas mỗi giao dịch trong IL, 32 giao dịch nằm trong phạm vi 10 triệu gas, có thể thấp hơn với nhiều bằng chứng. Nếu một giao dịch trong IL không hợp lệ nhưng không còn chỗ trống trong Block, giao dịch đó sẽ không bị loại bỏ vì chúng ta không thể phân biệt trường hợp toàn bộ Block với trường hợp không hợp lệ. Cơ chế phí cơ bản 1559 đảm bảo rằng một Block với đủ chỗ trống cuối cùng sẽ được tạo ra, giả sử có đủ độ đàn hồi.
Khi gọi hàm thanh toán với một Block L2, toán tử L2 sẽ lấy IL hiện tại từ các giao dịch ở đầu danh sách cho đến khi đạt đến ngân sách gas được xác định trước hoặc cho đến khi các giao dịch không trả đủ phí cho phí cơ bản hiện tại. IL này được sử dụng làm đầu vào cho trình xác minh trên chuỗi, và việc đáp ứng nó được coi là một quy tắc hợp lệ. Để ngăn chặn các điều kiện tranh chấp và các cuộc tấn công phá hoại, IL có thể được xây dựng chỉ với các giao dịch ít nhất cũ hơn một Threshold, để người chứng minh có thể biết trước chính xác các giao dịch mà họ sẽ bị buộc phải đưa vào. Nếu bộ tạo chuỗi tập trung L2 từ chối tạo ra các khối hoàn toàn, một thời gian chờ có thể được kích hoạt trên chuỗi để xóa Danh sách trắng và khôi phục khả năng chống kiểm duyệt.
Bạn có thể tìm thấy cách triển khai cụ thể tại đây . Ước tính việc gửi yêu cầu tốn khoảng 1,3 triệu gas, trong khi việc loại bỏ yêu cầu tốn khoảng 1,1 triệu gas, cả hai đều tương ứng với khoảng 0,001 ETH với giá 1 gwei mỗi gas.
Mặc dù nằm ngoài phạm vi bài nghiên cứu này, hợp đồng giao dịch bắt buộc có thể được tùy chỉnh để thực hiện các bước kiểm tra bổ sung trước khi được chấp nhận dựa trên các nhu cầu cụ thể của L2.
Các nút chỉ dành cho tài khoản
Hiện nay, việc lấy bằng chứng tài khoản yêu cầu kết nối với một node đầy đủ, điều này là quá khó khăn đối với hầu hết người dùng, đặc biệt là người dùng L2. Đề xuất VOPS , khi kết hợp với zkEVM, nhằm mục đích giảm tải lưu trữ trên các trình xác thực và trình bao gồm từ ~233GiB xuống ~8,4 GiB bằng cách chỉ xác thực trạng thái bằng bằng chứng và duy trì một mempool lành mạnh bằng cách chỉ lưu trữ số dư và nonce thu được thông qua BAL . Vì người dùng L2 cũng đăng bằng chứng và sẽ có thể đăng BAL, nên có thể hình dung một loại node tương tự dành cho người dùng L2 để cho phép họ dễ dàng hơn trong việc gửi các giao dịch bắt buộc trong trường hợp kiểm duyệt mà không cần phải duy trì trạng thái đầy đủ. Thật không may, vì BAL chỉ đăng các khác biệt về lưu trữ, nên cần phải theo dõi trạng thái đầy đủ để có thể tái tạo lại gốc lưu trữ cần thiết để cung cấp bằng chứng tài khoản. Để tham khảo nhanh, BAL được định nghĩa như sau:
BlockAccessList = List [AccountChanges]AccountChanges = [Address, # address List [SlotChanges], # storage_changes (slot -> [block_access_index -> new_value]) List [StorageKey], # storage_reads (read-only storage keys) List [BalanceChange], # balance_changes ([block_access_index -> post_balance]) List [NonceChange], # nonce_changes ([block_access_index -> new_nonce]) List [CodeChange] # code_changes ([block_access_index -> new_code]) ]trong khi một Account được tuần tự hóa trong cấu trúc dữ liệu trie như sau:
def encode_account ( raw_account_data: Account, storage_root: Bytes ) -> Bytes: """Encode `Account` dataclass.Storage is not stored in the `Account` dataclass, so `Accounts` cannot beencoded without providing a storage root.""" return rlp.encode((raw_account_data.nonce,raw_account_data.balance,storage_root,raw_account_data.code_hash,))Nếu BAL được sửa đổi để cung cấp cả các thay đổi gốc lưu trữ, trong đó chỉ cần thay đổi cuối cùng ở cuối Block , thì các nút sẽ có thể xây dựng bằng chứng tài khoản mà không cần phải duy trì toàn bộ trạng thái. Đề xuất cải tiến Ethereum (EIP)-8268 (cảm ơn Toni vì đã dẫn nguồn!) đề xuất chính xác sự thay đổi này.
