Hình ảnh ChatGPT 22 tháng 4 năm 2025, 11_26_48 AM 1024×1536 148 KB

Giới thiệu

Ethereum từ lâu đã theo đuổi mục tiêu xác thực không trạng thái : cho phép người tham gia xác minh các khối mà không cần lưu trữ toàn bộ trạng thái của chuỗi. Không trạng thái nhằm mục đích giảm yêu cầu về phần cứng, thúc đẩy sự phân cấp lớn hơn giữa các nút xác minh và mở khóa khả năng mở rộng bằng cách cho phép xây dựng và xác thực các khối lớn hơn mà không yêu cầu tất cả các nút sao chép toàn bộ trạng thái.

Một đề xuất hàng đầu hướng tới tầm nhìn này là trạng thái yếu , trong đó chỉ có nhà sản xuất khối giữ nguyên trạng thái đầy đủ và các nút khác xác thực khối bằng cách sử dụng bằng chứng trạng thái nhỏ. Mặc dù hấp dẫn vì tính đơn giản và hiệu quả, trạng thái yếu đặt ra một thách thức quan trọng: Làm thế nào Ethereum có thể duy trì các thuộc tính chống kiểm duyệt (CR) của mình trong một thế giới mà hầu hết các nút không thể xác thực giao dịch một cách độc lập?

Trong bài đăng này, chúng tôi sẽ khám phá lý do tại sao trạng thái không trạng thái yếu, tự nó, làm suy yếu khả năng đảm bảo chống kiểm duyệt của Ethereum và đề xuất một giải pháp thực tế: Trạng thái không trạng thái một phần chỉ có giá trị (VOPS) . Bằng cách yêu cầu các nút lưu trữ vừa đủ dữ liệu tài khoản để xác thực các giao dịch đang chờ xử lý, VOPS cung cấp khả năng giảm lưu trữ 25 lần trong khi vẫn duy trì khả năng chống kiểm duyệt của Ethereum.

Chúng tôi lập luận rằng:

• Chỉ riêng tình trạng vô quốc tịch yếu không thể đảm bảo khả năng chống kiểm duyệt mạnh mẽ.
• Các thiết kế trong tương lai phải xem xét lại tình trạng không trạng thái mạnh và giải quyết các câu hỏi thực tế, chẳng hạn như ai tạo ra các bằng chứng này , loại bằng chứng nào hiệu quả nhất và băng thông và chi phí chứng minh tác động đến yêu cầu của nút như thế nào.
• Trong khi đó, Tính năng Không trạng thái một phần chỉ có giá trị (VOPS) cung cấp một giải pháp đơn giản và hiệu quả: giảm dung lượng lưu trữ cục bộ xuống 25 lần trong khi vẫn duy trì được bộ nhớ công khai có chức năng và chống kiểm duyệt.
  AA-VOPS mở rộng VOPS để hỗ trợ tính năng trừu tượng hóa tài khoản gốc hoàn toàn, cung cấp con đường hướng tới trạng thái không trạng thái mạnh mẽ bằng cách giảm thiểu chi phí chứng kiến thông qua bộ nhớ đệm cục bộ và cập nhật gia tăng.

Tại sao

Chúng tôi sẽ bắt đầu bằng cách giải thích lý do tại sao trạng thái không trạng thái yếu (tức là chỉ dựa vào các nhà sản xuất khối để giữ trạng thái) không hiệu quả nếu chúng ta muốn cung cấp bảo đảm chống kiểm duyệt mạnh cho tất cả các giao dịch thông qua các cơ chế như FOCIL . Trước khi đi sâu hơn, đây là bản tóm tắt nhanh về các thành phần chính cần thiết để FOCIL hoạt động trong thế giới có trạng thái. Chúng tôi sẽ chỉ ra cách thiết kế hiện tại của FOCIL dựa trên giả định rằng mempool có thể giữ lại các giao dịch hợp lệ trong khi cắt bỏ các giao dịch không hợp lệ:

• Người dùng gửi các giao dịch, nếu hợp lệ (tức là vượt qua kiểm tra nonce và số dư), sẽ được phát qua các nút và vẫn đang chờ xử lý trong mempool công khai.
  Lưu ý: Trong bài đăng này, chúng tôi sử dụng thuật ngữ “node” để chỉ những người duy trì mempool thông qua máy khách lớp thực thi của họ.
• Bộ bao gồm : Mỗi khe, 16 bộ bao gồm sẽ theo dõi các giao dịch mempool đang chờ xử lý, thêm chúng vào danh sách bao gồm (IL) và phát các IL này trên toàn mạng CL P2P.
• Người tạo khối phải bao gồm hợp nhất các giao dịch hợp lệ từ tất cả các IL trong khối của họ. Giao dịch IL chỉ có thể bị loại khỏi khối nếu nó không hợp lệ hoặc nếu khối đã đầy (tức là thuộc tính có điều kiện).
• Người chứng thực xác minh xem tất cả các giao dịch IL có được bao gồm trong khối hay không. Nếu có, người chứng thực sẽ bỏ phiếu cho khối. Nếu không, họ sẽ đánh giá xem khối đã đầy hay các giao dịch bị thiếu có hợp lệ hay không, để xác định xem các loại trừ có hợp lý hay khối đang kiểm duyệt hay không.

Bây giờ, hãy tưởng tượng giao thức chỉ mong đợi các nhà sản xuất khối giữ trạng thái. Điều này có nghĩa là người dùng , các nút duy trì mempool, includer và attesters không thể tự mình xác định xem các giao dịch có hợp lệ với preStateRoot hay không. Thật vậy, họ sẽ không có quyền truy cập vào thông tin trạng thái đầy đủ, cập nhật cần thiết cho các lần kiểm tra xác thực quan trọng, bao gồm xác nhận rằng người gửi có đủ balance và nonce của giao dịch là chính xác. Lưu ý rằng bất kỳ điều kiện hợp đồng thông minh hoặc logic phụ thuộc vào trạng thái nào (ví dụ: trạng thái hiện tại của nhóm Uniswap) đều đã được các dApp cung cấp ngay hôm nay để giúp người dùng tránh việc hoàn nguyên.

Vì vậy, trong một thế giới vô quốc tịch yếu:

• Mọi thứ thực sự diễn ra suôn sẻ với người chứng thực: họ không cần phải lưu trữ bất cứ thứ gì vì nhà sản xuất khối tạo ra các chứng thực cấp khối . Các chứng thực này có thể ở dạng các bằng chứng Merkle/Verkle tổng hợp (ví dụ: nhiều bằng chứng IPA ) hoặc thậm chí là SNARK (sẽ nói thêm về điều này trong phần sau), cho thấy rằng tất cả các quyền truy cập trạng thái được thực hiện bởi các giao dịch có trong khối đều hợp lệ đối với preStateRoot . Nói cách khác, chúng chứng minh rằng dữ liệu được cung cấp để thực hiện khối tồn tại trong gốc trạng thái khối trước đó. Điều quan trọng là, nhà sản xuất khối cũng phải đính kèm các chứng thực cho bất kỳ giao dịch IL nào mà họ loại trừ (bằng cách sử dụng các chứng thực được gửi cùng với các IL hoặc bằng cách tái tạo chúng), để người chứng thực có thể thực hiện lại khối và xác minh xem mỗi lần bỏ sót có hợp lý không.
• Đối với các nút duy trì mempool và includer , có một vấn đề cơ bản nếu chúng ta muốn chúng không có trạng thái. Khi các giao dịch được người dùng gửi đến mempool công khai, các nút không có cách nào biết được liệu các giao dịch này có hợp lệ với preStateRoot hay không vì chúng không thể thực hiện các kiểm tra nonce và balance thông thường để xác định xem chúng có nên phát lại các giao dịch hay cắt bớt chúng khỏi mempool cục bộ của chúng hay không:
  • Điều này có thể bị lợi dụng để làm tràn ngập mempool và IL bằng các giao dịch không hợp lệ, về cơ bản phủ nhận các lợi ích của FOCIL và cho phép kiểm duyệt các giao dịch vốn sẽ được hưởng lợi nếu được đưa vào IL.
  • Việc không có kiểm tra nonce và balance như một tuyến phòng thủ đầu tiên tạo ra một vectơ DoS mới: nó cho phép bất kỳ ai gửi các giao dịch không hợp lệ đến mempool hoặc IL, làm giảm chất lượng của mempool và khiến các giao dịch hợp lệ khó xuất hiện hơn. Điều này tạo ra cùng một loại gián đoạn sẽ xảy ra nếu các includeer là đối kháng và lấp đầy IL bằng rác. Sự khác biệt chính là ngày nay, chỉ có các trình xác thực (với 32 ETH) mới có thể là includeer , trong khi nếu không có bộ lọc cơ bản, bất kỳ người tham gia nào cũng có thể làm giảm chất lượng mempool và can thiệp vào hiệu quả của danh sách include—làm giảm rào cản tấn công và làm suy yếu khả năng chống kiểm duyệt trong thực tế.

Làm gì thế?

Trong phần sau, chúng tôi sẽ khám phá các lựa chọn tiềm năng để khắc phục những thách thức do cách tiếp cận vô quốc tịch yếu gây ra.

Lựa chọn 1: Vô quốc tịch mạnh

Một cách tiếp cận có vẻ đơn giản là yêu cầu các giao dịch của người dùng được đóng gói với các quyền truy cập trạng thái hoàn chỉnh so với preStateRoot (ví dụ: bằng chứng Merkle hoặc Verkle), thường được gọi là trạng thái không trạng thái mạnh. Chúng ta thậm chí có thể nới lỏng định nghĩa nghiêm ngặt về trạng thái không trạng thái mạnh bằng cách yêu cầu mỗi nhà sản xuất khối trước đó đính kèm các chứng nhân trạng thái vào mọi giao dịch, để các nút có thể truy xuất chúng theo yêu cầu. Về mặt lý thuyết, điều này sẽ cho phép bất kỳ nút nào, bao gồm cả trình bao gồm và trình xác thực , xác minh độc lập rằng các quyền truy cập trạng thái của giao dịch là nhất quán với preStateRoot mà không cần truy cập vào trạng thái hiện tại đầy đủ. Một cơ chế như vậy rất hữu ích để quản lý mempool hiệu quả: thay vì loại trừ và bao gồm các giao dịch ở mọi khe, các nút có thể giữ lại các giao dịch không bị ảnh hưởng bởi các khối tiếp theo và cắt tỉa các giao dịch có nonce hoặc số dư đã thay đổi.

Nhưng trên thực tế, nó sẽ yêu cầu một kênh phân phối thời gian thực giữa các nút và nhà sản xuất khối hiện tại, đưa ra các giả định tin cậy mạnh mẽ và một vectơ kiểm duyệt mới: nhà sản xuất khối có thể trì hoãn hoặc giữ lại có chọn lọc các bằng chứng cấp giao dịch để giữ các giao dịch mục tiêu ra khỏi mọi mempool và danh sách bao gồm, âm thầm loại trừ chúng trong khi vẫn tạo ra một khối hợp lệ rõ ràng. Hơn nữa, đối với các giao dịch mới, chỉ dựa vào trạng thái của khối trước đó là không đủ. Người dùng cần truy cập vào các bằng chứng trạng thái được cập nhật, thời gian thực bao gồm cả tài khoản và khe lưu trữ thực sự được giao dịch chạm tới, cũng như bất kỳ phần bổ sung nào của trie trạng thái cần thiết để tái tạo đường dẫn đến các mục nhập đó—do cách cấu trúc trie liên kết trạng thái. Việc liên tục tìm nạp các bằng chứng này không chỉ làm tăng mức sử dụng băng thông và độ trễ—làm giảm UX—mà còn đặt ra một câu hỏi quan trọng: ai nên đóng vai trò là các nút phục vụ bằng chứng ? Ví? dApp? Mạng lưới Portal? Siêu nút (tức là, trình xác thực đặt cược 2048 ETH )? Tất cả các mục trên?

Mặc dù trạng thái không trạng thái mạnh có thể là mục tiêu cuối cùng nếu chúng ta muốn các nút xác thực và nút bao gồm hoàn toàn không trạng thái và chạy trên đồng hồ thông minh, nhưng cần phải nghiên cứu thêm để trả lời câu hỏi này và xác định tác nhân nào phù hợp nhất để thực hiện nhiệm vụ này bằng cách đánh giá chi phí và yêu cầu phần cứng cần thiết để (1) lưu trữ trạng thái đầy đủ và (2) tạo và phát các nhân chứng và bằng chứng liên quan đến giao dịch của người dùng. Lưu ý rằng cách tiếp cận này chỉ yêu cầu giả định trung thực một trong N - về mặt lý thuyết, một tác nhân trung thực duy nhất có khả năng tạo ra các bằng chứng hợp lệ là đủ. Tuy nhiên, trên thực tế, việc chỉ dựa vào một hoặc rất ít tác nhân có thể dẫn đến các vấn đề như trích xuất tiền thuê (ví dụ: tấn công cam kết, kiểm duyệt và định giá độc quyền).

Tùy chọn 2: Chỉ có tính hợp lệ một phần không có trạng thái

Một cách tiếp cận thực dụng, ngắn hạn là dựa vào trạng thái không trạng thái một phần và chỉ lưu trữ dữ liệu tối thiểu cần thiết để xác minh tính hợp lệ của giao dịch. Theo VOPS, mỗi nút chỉ duy trì bốn trường cho mỗi EOA— address (20 B), nonce (8 B), balance (12 B) và codeFlag một bit —thay vì trạng thái đầy đủ.

Khi một giao dịch đến, nút sẽ kiểm tra codeFlag :

• codeFlag = 0 (EOA thuần túy, không có chỉ định ủy quyền — nghĩa là tài khoản không thể ủy quyền thực thi cho mã tùy chỉnh):
  • Xác minh chữ ký, nonce, số dư so với phí và giới hạn gas.
  • Cho phép nhiều giao dịch đang diễn ra trên mỗi địa chỉ.
• codeFlag = 1 (bất kỳ địa chỉ nào có khả năng chạy mã bằng cách sử dụng ký hiệu ủy quyền EIP‑7702 23 byte):
  • Thực hiện tối đa một giao dịch đang chờ xử lý cho mỗi địa chỉ.
  • Ngăn ngừa xung đột nonce/balance vì mã được ủy quyền có thể thay đổi trạng thái một cách khó lường.

Trên mỗi khối mới, nút sẽ cập nhật bảng của mình với tất cả các bộ tứ đã sửa đổi, cắt bớt bất kỳ giao dịch nào bị coi là không hợp lệ do các nonce cũ hoặc số dư không đủ, loại bỏ tất cả ngoại trừ giao dịch đang chờ có mức ưu tiên cao nhất bất cứ khi nào codeFlag của tài khoản đảo từ 0 sang 1 và thúc đẩy bất kỳ giao dịch EOA nào trong hàng đợi có nonce khớp với nhau khi cờ đảo từ 1 sang 0 .

Vì mỗi mục nhập tài khoản chỉ có 20 + 8 + 12 + 0.125 ≈ 40.125 bytes nên việc duy trì ~241 triệu tài khoản yêu cầu:

Con số này giảm hơn 25 lần so với kích thước trạng thái đầy đủ ~233 GiB hiện nay (h/t Guillaume), nhưng vẫn cho phép các nút VOPS duy trì mempool hiệu quả. Lưu ý rằng con số 8.4 GiB không được nén, do đó, đây là ước tính bi quan về khả năng tiết kiệm lưu trữ mà VOPS có thể mang lại.

VOPS cho Verkle

Để cụ thể hóa ý tưởng VOPS, chúng ta sẽ bắt đầu bằng cách neo đề xuất vào bối cảnh Verkle .

Các trường tiêu đề khối

Chúng ta hãy cùng tóm tắt lại ai làm gì trong tình huống đó:

• Người dùng phát các giao dịch đến mempool công khai. Theo VOPS, các nút không trạng thái một phần chỉ giữ bốn trường cho mỗi tài khoản— address , nonce , balance và codeFlag —chỉ đủ để quyết định xem mỗi giao dịch đang chờ xử lý có nên ở lại hay bị cắt bớt.

• Includer : Mỗi khe, 16 includer sẽ quan sát các giao dịch mempool đang chờ xử lý, thêm chúng vào danh sách include (IL) và phát các IL này qua mạng CL P2P. Nếu includer cũng duy trì một mempool—như trường hợp hiện nay—không cần kiểm tra thêm trước khi bao gồm các giao dịch trong IL, vì các kiểm tra tính hợp lệ đối với preStateRoot (ví dụ: nonce , balance và codeFlag ) được thực hiện như một phần của việc bảo trì mempool. Tuy nhiên, nếu trong tương lai, các includer được tách thành một vai trò độc lập (ví dụ: các includer “smart-watch” nhẹ ), chúng sẽ cần thực hiện kiểm tra tính hợp lệ của giao dịch một cách độc lập trước khi bao gồm các giao dịch trong IL.

• Nhà sản xuất khối nắm giữ toàn bộ trạng thái Ethereum. Họ phải bao gồm sự hợp nhất của tất cả các giao dịch hợp lệ từ tất cả các IL trong các khối được đề xuất của họ. Giao dịch IL chỉ có thể bị loại trừ nếu nó không hợp lệ hoặc nếu khối đã đầy (tức là, thuộc tính có điều kiện được thỏa mãn).

  Trong thế giới VOPS dành cho Verkle, nhà sản xuất khối có trách nhiệm tạo và cam kết những điều sau:

  • Một nhân chứng cấp khối (ví dụ: chứng minh đa IPA trên cây Verkle): Điều này chứng minh rằng dữ liệu được cung cấp để thực thi khối tồn tại trong gốc trạng thái khối trước đó.
  • Post-state root : Sau khi thực hiện tất cả các giao dịch, block producer sẽ tính toán và cam kết postStateRoot kết quả trong tiêu đề khối. Đây đóng vai trò là đầu ra của quá trình thực hiện và phải được xác minh bởi người chứng thực. Đây là những gì block producer thực hiện ngày nay và sẽ không phải là yêu cầu mới trong thế giới VOPS.

• Người chứng thực xác minh khối bằng cách thực hiện các bước sau:

  1. Xác minh chứng cứ cấp khối : Xác nhận rằng tất cả trạng thái được cung cấp (được chứng minh thông qua IPA multiproof) đều hợp lệ đối với preStateRoot .

  2. Thực hiện lại khối cục bộ: Sử dụng các giao dịch được cung cấp, người chứng thực thực hiện lại khối một cách độc lập bắt đầu từ trạng thái trước (được xây dựng lại từ nhân chứng) để tính toán lại postStateRoot .

  3. Kiểm tra postStateRoot : Đảm bảo rằng postStateRoot được tính toán lại cục bộ khớp với postStateRoot đã cam kết trong khối.

  4. Xác thực điều kiện IL

  • Bao gồm các giao dịch IL
    • Trong quá trình thực hiện lại cục bộ từ trạng thái trước được tái tạo, tất cả các thay đổi trạng thái tương ứng với các giao dịch IL có trong khối đều có thể được quan sát.
  • Giao dịch IL bị loại trừ
    • Sau khi thực hiện tất cả các giao dịch được bao gồm trong khối, hãy thử thực hiện từng giao dịch IL bị loại trừ:
      • Nếu giao dịch không vượt qua được kiểm tra nonce hoặc số dư, hoặc nếu khối đã đầy, thì việc loại trừ là hợp lý.
      • Nếu không, nhà sản xuất khối sẽ kiểm duyệt và khối đó sẽ không được bỏ phiếu.

  Nếu tất cả các kiểm tra đều vượt qua—tính hợp lệ của quyền truy cập trạng thái, tính chính xác của việc thực hiện và sự thỏa mãn các điều kiện IL —người chứng thực sẽ bỏ phiếu cho khối . Bằng cách thực hiện lại các khối ở bước 2 và đồng thời cập nhật các bảng quadruplet cục bộ của chúng ở bước 3 , các nút VOPS giữ trạng thái một phần của chúng đồng bộ hoàn hảo mà không bao giờ lưu trữ toàn bộ cây Verkle.

VOPS cho zkVM

Dựa trên hương vị Verkle của VOPS, chúng ta có thể thay thế các bằng chứng trạng thái cấp khối và thực thi lại cục bộ bằng Máy ảo không kiến thức ( zkVM) . Mỗi khối sẽ đi kèm với một SNARK cho phép mọi trình xác minh kiểm tra toàn bộ quá trình chuyển đổi—và tất cả các điều kiện IL—bằng cách chạy một xác minh duy nhất, quy mô mili giây.

• Nhà sản xuất khối phải chứng minh những gì:
  • Tính hợp lệ của trạng thái: Mọi khóa/giá trị được giao dịch đọc đều được chứng minh dựa trên preStateRoot .
  • Tính chính xác của quá trình thực hiện: Thực hiện các giao dịch đã sắp xếp trên trạng thái trước được tái tạo đó sẽ tạo ra postStateRoot đã cam kết.
  • Độ chính xác của diff: Áp dụng diff trạng thái đầy đủ chính xác cho preStateRoot sẽ tạo ra postStateRoot và diff này khớp với diff được nhúng trong tiêu đề.

Các trường tiêu đề khối

Hai lưu ý:

• Theo VOPS và AA‑VOPS, các nút dựa vào việc nhận toàn bộ stateDiff cho mỗi khối để vá trạng thái cục bộ của chúng. EIP-7928 Block-Level Access Lists (BAL) sẽ cung cấp chính xác điều này: một ấn phẩm có thể xác minh và bắt buộc của tất cả các tài khoản đã sửa đổi, khóa lưu trữ, số dư và nonce.
• Sự tuân thủ IL được kiểm tra cục bộ bởi các nút VOPS bằng cách sử dụng các bảng tứ phân tử được cập nhật của chúng và stateDiff đã nhận —không có nghĩa vụ chứng minh bổ sung nào ở đây (xem AA-VOPS để biết bằng chứng theo từng tài khoản có liên quan đến các quy tắc danh sách bao gồm hay không).

Quy trình từng khối cho các nút VOPS

1. Xác minh execProof . Xác nhận trạng thái hiệu lực, tính chính xác của việc thực hiện và sự khác biệt về tính chính xác.
2. Trích xuất tứ phân. Từ stateDiff đầy đủ đã xác minh, hãy lấy ra từng tài khoản đã sửa đổi (address, nonce, balance, codeFlag) và cập nhật bảng cục bộ.
3. Thực thi các quy tắc IL. Sử dụng bảng quadruplet đã làm mới, kiểm tra lại các điều kiện của danh sách bao gồm cục bộ. Thực thi IL có thể được thực hiện ngoài phạm vi bằng cách sử dụng các kiểm tra cục bộ với các trường VOPS-quadruplet đã lưu trữ.
4. Cắt bớt mempool. Hủy bỏ bất kỳ giao dịch đang chờ xử lý nào bị vô hiệu hóa bởi các giá trị quadruplet mới.

Hồ sơ tài nguyên

Tóm lại.

Với khoảng 8,4 GiB trạng thái cục bộ, các quy tắc mempool không thay đổi và một bằng chứng ngắn gọn duy nhất cho mỗi khối, zkVM VOPS duy trì khả năng chống kiểm duyệt của Ethereum trong khi vẫn giữ các yêu cầu về phần cứng xác minh trong giới hạn cấp độ người tiêu dùng.

Đồng bộ VOPS

Hãy bắt đầu với một lưu ý quan trọng. Trong các đề xuất Verkle và Binary tree ngày nay, các tài khoản và khe lưu trữ được xen kẽ mà không có sự tách biệt rõ ràng. Không giống như Merkle Patricia Tree hiện tại, nơi các tài khoản tạo thành một subtrie riêng biệt, điều này có nghĩa là một nút VOPS không thể chỉ cần tải xuống một ảnh chụp nhanh để xây dựng lại bảng tài khoản cục bộ của nó. Thay vào đó, nó phải thực hiện lại tất cả các khối từ genesis. Các thiết kế cây hợp nhất trong tương lai có thể thêm ngữ nghĩa tối thiểu (ví dụ: một bitfield) để phân biệt các tài khoản với bộ lưu trữ, cho phép đồng bộ hóa snap hiệu quả.

Ngày nay, tài khoản trie chiếm khoảng 1/6 tổng kích thước trạng thái. Giả sử phương pháp đồng bộ hóa nhanh, chỉ cần tải xuống tài khoản trie sẽ giúp đồng bộ hóa nhanh hơn khoảng năm đến sáu lần so với việc tải xuống toàn bộ trạng thái, tính đến giai đoạn chữa lành. Giai đoạn chữa lành vẫn sẽ mất cùng thời gian như ngày nay và phần lớn dữ liệu đã tải xuống cuối cùng sẽ bị loại bỏ, nhưng việc đồng bộ hóa có thể diễn ra từ bất kỳ nút đầy đủ nào, giống như ngày nay.

Việc khởi động một nút VOPS chỉ yêu cầu trạng thái tài khoản (không cần thử lưu trữ hoặc mã blob) cùng với các tiêu đề khối thông thường:

1. Tải xuống và xác minh tiêu đề

   • Lấy và xác minh tiêu đề khối từ genesis (hoặc điểm kiểm tra đáng tin cậy) đến tiêu đề mới nhất.

2. Cập nhật từng khối

   Đối với mỗi khối mới:

   • Lấy lại:
     • Verkle-tree: tiêu đề + IPA multiproof + danh sách giao dịch đầy đủ
     • zkVM: tiêu đề + SNARK execProof + sidecar stateDiff nhỏ gọn
   • Xác minh & Trích xuất:
     • Verkle-tree: kiểm tra multiproof, trích xuất tất cả các mục tài khoản đã chạm vào, sau đó thực hiện lại mọi giao dịch theo thứ tự so với trạng thái trước đó được tái tạo. Ghi lại từng thay đổi (address, nonce, balance, codeFlag) .
     • zkVM: xác minh SNARK (quy tắc đọc trạng thái, thực thi và IL) và phân tích danh sách sidecar stateDiff của các bộ tứ được cập nhật.
   • Áp dụng: cập nhật bảng cục bộ với mỗi mục nhập tài khoản đã sửa đổi.

3. Cắt tỉa Mempool

   • Sau mỗi lần cập nhật bảng, hãy loại bỏ mọi giao dịch đang chờ xử lý mà người gửi hiện có nonce cũ, số dư không đủ hoặc codeFlag đảo ngược từ 0→1 (chỉ giữ lại giao dịch đang chờ có mức ưu tiên cao nhất cho địa chỉ đó).
   • Sau khi xử lý tất cả các khối đến đầu, bảng sẽ được cập nhật đầy đủ và mempool thực thi việc chấp nhận/cắt bỏ chỉ những khối hợp lệ chính xác như trong hoạt động trực tiếp.

VOPS và Trừu tượng hóa tài khoản gốc (AA‑VOPS)

Native Account Abstraction (AA, xem EIP-7701 ) giới thiệu một sự thay đổi lớn về mô hình: tài khoản không còn là các đối tượng đơn giản với các quy tắc xác thực cố định nữa mà là các thực thể có thể lập trình được có thể chạy mã tùy ý. Tính linh hoạt này phá vỡ giả định rằng chỉ cần kiểm tra nonce , balance và codeFlag là đủ để xác thực giao dịch. Do đó, VOPS cần nâng cấp: AA-VOPS .

AA-VOPS mở rộng VOPS để hỗ trợ AA gốc trong khi vẫn giữ cho các nút nhẹ, bằng cách tránh sao chép toàn bộ trạng thái toàn cầu. Thay vì yêu cầu mọi nút theo dõi mọi tài khoản, mỗi nút chỉ theo dõi các tài khoản mà nó chủ động quan tâm (đối với EOA của riêng nó hoặc những tài khoản mà nó tương tác), duy trì một bộ nhớ đệm cục bộ nhỏ được cập nhật gia tăng theo thời gian.

Trong khi AA gốc mở khóa các khả năng mới mạnh mẽ, nó cũng buộc hệ sinh thái gần hơn với các thiết kế không trạng thái mạnh mẽ, trong đó các giao dịch phải có nhân chứng rõ ràng. Khi chúng ta mở rộng VOPS để hỗ trợ AA-VOPS, chúng ta nên cân nhắc cẩn thận xem liệu các lợi ích của AA gốc đầy đủ có biện minh cho sự phức tạp bổ sung này hay không, hoặc nếu tuân theo mô hình VOPS đơn giản hơn thì có bảo tồn tốt hơn tính phi tập trung và hiệu quả hay không.

AA-VOPS so với Vô quốc tịch mạnh

Tính năng không quốc tịch mạnh yêu cầu người dùng phải đính kèm chứng nhận quốc tịch đầy đủ vào mọi giao dịch, bao gồm tất cả các tài khoản và khe lưu trữ được chạm vào.

Ngược lại, AA-VOPS cho phép các nút duy trì các bằng chứng cập nhật chỉ cho các tài khoản cụ thể được liên kết với EOA của riêng chúng. Các bằng chứng này vẫn có hiệu lực trên nhiều khối trừ khi tài khoản thay đổi và được làm mới bằng stateDiffs nhẹ có trong mỗi khối.

Điều này tránh được tình trạng quá nhiều nhân chứng trong mỗi giao dịch, giữ cho yêu cầu về băng thông và lưu trữ ở mức tối thiểu trong khi vẫn đảm bảo khả năng chống kiểm duyệt và tính hợp lệ của giao dịch.

AA-VOPS hoạt động như thế nào

Bảo trì bộ nhớ đệm cục bộ và nhân chứng

Một nút (hoặc ví hoặc ứng dụng phi tập trung hoạt động thay mặt cho nút) sẽ lưu giữ:

• Tài khoản riêng của nó: nonce , balance , storageRoot và codeHash .
• Bất kỳ khe lưu trữ bổ sung nào được yêu cầu bởi logic AA của tài khoản.
• Một chứng thực đường dẫn Merkle hoặc Verkle xác thực các trường này với stateRoot gần đây.

Bằng chứng vẫn có hiệu lực cho đến khi một khối sau đó sửa đổi bất kỳ trường nào được bao phủ.

Tự lực chứng kiến:

• Nút này sẽ lấy được lá và đường dẫn ban đầu một lần, bằng cách sử dụng eth_getProof từ bất kỳ nút đầy đủ hoặc nhà cung cấp RPC nào (trong Reth, giờ đây bạn có thể lấy được tất cả các nhân chứng chỉ bằng một lệnh gọi RPC ).

Cập nhật gia tăng:

Mỗi khối cung cấp

1. Một stateDiff đầy đủ, nhỏ gọn (như trong VOPS-with-zkVM).
2. Cam kết IL (ví dụ: tổng hợp 16 chữ ký IL). Cam kết này cho phép người chứng thực xác minh rằng nhà sản xuất khối đã cam kết với tất cả các IL mà họ quan sát tại địa phương.
3. Bằng chứng cấp khối (ví dụ: SNARK) liên kết transactions , stateDiff và các quy tắc tuân thủ IL với nhau.

Khi một khối đến, nút:

1. Xác minh bằng chứng cấp khối , đảm bảo:

   • stateDiff mã hóa chính xác quá trình chuyển đổi từ preStateRoot sang postStateRoot .
   • Tất cả các giao dịch được bao gồm đều được thực hiện chính xác.
   • Mỗi giao dịch trong tập IL đều được bao gồm hoặc bị loại trừ một cách hợp lệ (vì khối đã đầy hoặc giao dịch trở nên không hợp lệ sau khi thực hiện trước đó).

   (Tối ưu hóa tùy chọn: Nhà sản xuất khối có thể đính kèm “gợi ý lỗi” cho mỗi giao dịch IL bị loại trừ, chỉ ra chỉ mục đang thực hiện khi giao dịch không thành công, giúp giảm khối lượng công việc của người chứng thực.)

2. Vá lỗi chứng kiến của mình nếu cần:

   Nút VOPS (hoặc ví/dapp theo dõi EOA của chính nó) sẽ kiểm tra xem bất kỳ tài khoản nào của nó có xuất hiện trong stateDiff hay không.

   • Nếu có , nó sẽ cập nhật lá được lưu trong bộ nhớ đệm và tính toán lại các đường dẫn Merkle/Verkle bị ảnh hưởng.
   • Nếu không có , chứng cứ được lưu trong bộ nhớ đệm vẫn có giá trị đối với stateRoot mới.

Nếu một nút vẫn trực tuyến và xử lý mọi khối, nó không bao giờ cần truy vấn lưu trữ khác sau khi khởi động. Nếu nó tụt hậu, nó có thể phát lại các diff bị thiếu hoặc gieo lại nhân chứng của nó thông qua eth_getProof .

Gói giao dịch

Khi gửi giao dịch:

• Đối với tài khoản EOA và EIP-7702 , không cần thêm nhân chứng. Các trường tài khoản tối thiểu có sẵn tại địa phương.
• Đối với tài khoản thông minh EIP-7701 , bằng chứng xác thực tài khoản đơn ngắn gọn (ví dụ: SNARK) được đính kèm, cho thấy cả việc bao gồm phần tài khoản và thực hiện logic VALIDATE chính xác.

Khả năng tương thích AA trong tương lai

Nếu các tiêu chuẩn AA trong tương lai cho phép VALIDATE đọc bên ngoài tài khoản, người gửi có thể mở rộng chứng thực đính kèm để bao phủ các khe lưu trữ bổ sung đó. Mô hình mở rộng một cách tự nhiên.

Nhập học Mempool

Một nút nhận sẽ xác minh nhân chứng hoặc bằng chứng so với stateRoot được tham chiếu, sử dụng stateDiffs được lưu trong bộ nhớ đệm để kiểm tra các bản cập nhật:

• Nếu sự khác biệt cho thấy tài khoản không thay đổi thì giao dịch được chấp nhận.
• Nếu sự khác biệt cho thấy tài khoản đã thay đổi, chứng cứ sẽ cũ và nút sẽ yêu cầu bằng chứng cập nhật.

Trên thực tế, các nút cũng có thể duy trì một cửa sổ trượt của các stateDiff gần đây—ví dụ: ~N khối cuối cùng—để cho phép xác thực giao dịch mà không cần truy vấn lại.

Tại sao AA-VOPS lại hấp dẫn

• Không có sự sao chép toàn cầu:

  Mỗi nút chỉ lưu trữ một vài kilobyte, không phải 8 GiB (VOPS) hoặc ~233 GiB (trạng thái đầy đủ). Các nhà sản xuất khối và nhà cung cấp RPC vẫn cần trạng thái đầy đủ.

• Khả năng tương thích của AA:

  Hoạt động với EIP-7701 hiện nay và có thể thích ứng nếu logic xác thực sau này đọc bộ nhớ ngoài.

• Khởi nghiệp theo yêu cầu:

  Để theo dõi một EOA mới, một nút sẽ lấy một eth_getProof duy nhất một lần và giữ nó mới bằng cách so sánh.

Sự đánh đổi

1. Băng thông P2P cao hơn:

   Mỗi giao dịch đều có bằng chứng hoặc bằng chứng ngắn gọn riêng, kích thước giao dịch trung bình ngày càng tăng (~736 byte đối với Verkle, ~1024 byte đối với cây nhị phân).

2. Kiểm tra hoặc tìm kiếm phía người dùng:

   Các nút phải cập nhật bằng cách theo dõi sự khác biệt hoặc truy vấn một nút đầy đủ, điều này dễ dẫn đến các vectơ tập trung.

3. Sự phụ thuộc vào các nút đầy đủ để khởi động:

   Không giống như VOPS, AA-VOPS phụ thuộc vào các nút đầy đủ hoặc nhà cung cấp RPC để ban đầu lấy bằng chứng tài khoản. Nếu thiếu diff, các nút phải gieo lại thông qua eth_getProof , có khả năng gây ra rủi ro tập trung nếu ít nhà cung cấp chiếm ưu thế.

Kết luận và bài học rút ra

Tính hợp lệ-Chỉ có trạng thái một phần ( VOPS ) giảm yêu cầu lưu trữ cục bộ cho các nút xuống còn khoảng 8,4 GiB không nén—chỉ là các bộ tứ (address, nonce, balance, codeFlag) —trong khi vẫn giữ nguyên các thuộc tính chống kiểm duyệt của Ethereum. Cách tiếp cận này tận dụng sự bất đối xứng giữa sự tăng trưởng của tài khoản và khe lưu trữ: miễn là lưu trữ tiếp tục thống trị các mục nhập trạng thái mới, thì khoản tiết kiệm vẫn đáng kể; nếu việc tạo tài khoản vượt quá tốc độ tăng trưởng của lưu trữ, thì lợi thế tương đối sẽ giảm dần theo đó.

Có hai lợi thế chính đối với VOPS trong phiên bản gốc của nó: Đầu tiên là mempool không có chứng cứ: vì mọi nút đều lưu trữ từng EOA (address, nonce, balance, codeFlag) quadruplet, mempool không bao giờ cần bằng chứng Merkle hoặc Verkle cho mỗi giao dịch. Bằng chứng cấp khối (ví dụ: SNARK trong zkEVM) vẫn đảm bảo tính chính xác hoàn toàn trong khi chỉ thêm vài trăm byte vào quá trình truyền của mỗi khối. Thứ hai là đồng bộ hóa ngang hàng thực sự: vì mọi nút đều duy trì trạng thái tối thiểu đó cho tất cả EOA, bạn có thể khởi động hoặc khôi phục từ bất kỳ ngang hàng nào mà không cần bằng chứng bổ sung hoặc dữ liệu tài khoản riêng lẻ, loại bỏ sự phụ thuộc vào các nút lưu trữ hoặc nút đầy đủ.

Nhưng việc hỗ trợ AA gốc đẩy chúng ta đến một tập hợp các đánh đổi khác. AA-VOPS cắt giảm dung lượng lưu trữ cục bộ xuống chỉ còn vài kilobyte bằng cách đính kèm một bằng chứng nhỏ, cập nhật vào mỗi giao dịch, nhưng nhược điểm là tải trọng P2P cao hơn và thỉnh thoảng gọi đến một nút đầy đủ hoặc dịch vụ chuyên dụng bất cứ khi nào bạn bắt đầu theo dõi một tài khoản mới, khởi động một nút hoặc quay lại trực tuyến sau khi ngoại tuyến. Khi công nghệ chứng minh và SNARK tiếp tục được cải thiện, AA-VOPS có thể trở thành con đường dài hạn, có khả năng chống lại tương lai để đạt được trạng thái không trạng thái hoàn toàn. Ngược lại, VOPS ban đầu nổi bật như một giải pháp thực dụng trong ngắn hạn, bảo toàn UX liền mạch bằng cách tránh các nhân chứng cấp giao dịch.