Thực hiện trì hoãn và DA miễn phí

bởi Toni và Francesco

Cảm ơn Łukasz , Ansgar , Dankrad và Terence đã phản hồi!

Ngày nay, DA (Data Availability) miễn phí không còn là vấn đề nữa. Mỗi người gửi giao dịch phải trả tiền cho tất cả các tài nguyên được sử dụng trong quá trình thực hiện giao dịch. Dữ liệu được đưa vào chuỗi, bao gồm dữ liệu trong calldata hoặc các mục được liệt kê trong danh sách truy cập EIP-2930 , phải chịu chi phí gas, khiến việc công bố dữ liệu mà không phải trả phí là không thể.

Ethereum hiện đảm bảo tính hợp lệ của mỗi khối bằng cách yêu cầu các trình xác thực thực hiện và xác thực đầy đủ mọi giao dịch trong một khối trước khi xác nhận khối đó. Nếu một giao dịch không có đủ số dư để thanh toán cho gas cần thiết tại thời điểm thực hiện, toàn bộ khối chứa giao dịch đó sẽ trở nên không hợp lệ.

Tuy nhiên, việc giới thiệu Delayed Execution (EIP-7886) sẽ sửa đổi quy trình này. Trong chế độ thực hiện bị trì hoãn:

• Trình xác thực xác nhận tính hợp lệ của khối trước khi giao dịch hoàn tất, thay vào đó dựa vào các kiểm tra trước.
• Do đó, các khối phải có khả năng duy trì hiệu lực ngay cả khi các giao dịch ban đầu có vẻ đủ khả năng trang trải chi phí nhưng lại không đủ tiền tại thời điểm thực hiện.

Ví dụ, hãy tưởng tượng hai tài khoản, A A và B B , mỗi tài khoản gửi giao dịch (tương ứng là a a và b b ). Giao dịch ' a a ' được sắp xếp trước ' b b ' trong một khối. Nếu giao dịch ' a a ' làm cạn kiệt số dư của tài khoản B B , thì giao dịch ' b b ', mặc dù ban đầu có vẻ như đã được cấp vốn, nhưng lại không thể thanh toán tại thời điểm thực hiện, khiến khối không còn hiệu lực.

Xem bài đăng có thiết kế ban đầu tại đây .

Không gian thiết kế thực hiện chậm trễ

Việc áp dụng phương pháp thực hiện chậm mở ra nhiều khả năng thiết kế.
Mỗi biến thể đều có ưu và nhược điểm riêng và sau đây, chúng tôi chủ yếu tập trung vào các danh mục sau:

• UX của người gửi
• Độ phức tạp của người xây dựng
• Độ phức tạp của Fork-Choice
• Xác thực tĩnh
• Khả năng tương thích FOCIL
• Hiệu quả đóng gói khối kém

1. Chứng thực lạc quan

Xác thực lạc quan là hoạt động của những người xác thực bỏ phiếu cho một khối mà không chắc chắn hoàn toàn về tính hợp lệ của nó. Sau khi kiểm tra tối thiểu, những người xác thực tại khe N N bỏ phiếu cho khối đầu được đề xuất trong cùng khe đó. Nếu sau đó khối này hóa ra không hợp lệ khi thực hiện, thì người đề xuất tiếp theo tại khe N{+}1 N + 1 sẽ sắp xếp lại khối đó ra khỏi chuỗi.

Cách tiếp cận này giải quyết vấn đề DA miễn phí trong quá trình thực hiện bị trì hoãn vì nó đảm bảo rằng các giao dịch không trả tiền cho dữ liệu mà chúng ghi sẽ không được đưa vào chuỗi.

Phần khó khăn nằm ở quy tắc fork-choice: những người chứng thực tại slot N N hợp pháp bỏ phiếu, và những chứng thực đó đại diện cho sự hỗ trợ không chỉ cho chính khối đó, mà còn cho toàn bộ chuỗi tổ tiên của nó. Do đó, chúng ta có thể cần phải giữ lại các chứng thực cho các khối có đầu không hợp lệ và cho phép một số hiện vật nhất định từ các khối này tồn tại trong Store .

Ưu điểm

• Trải nghiệm người dùng của người gửi vẫn giữ nguyên như hiện nay.
• Độ phức tạp của Builder vẫn giữ nguyên.
• Đóng gói theo khối vẫn giữ nguyên như ngày nay.

Nhược điểm

• Fork-choice phải xử lý các khối không hợp lệ và xác nhận chúng.
• Về mặt xác thực tĩnh , chúng ta sẽ không thực sự nhận được bất cứ điều gì. Giao dịch vẫn có thể bị vô hiệu hóa trong quá trình thực hiện.
• Tương tác với FOCIL không tối ưu vì FOCIL dựa vào các kiểm tra sau khi thực thi để đảm bảo khối tuân thủ IL.

Xem bài đăng này của Francesco để biết thêm chi tiết về chứng thực lạc quan.

2. Xác thực trước và tính phí trước

Với xác thực giao dịch trước , chúng tôi giới thiệu một bước mới giữa xác thực tĩnh và thực thi.

Sau khi xác thực tĩnh khối và các giao dịch của nó, chúng tôi thực hiện các kiểm tra trạng thái sau đây trên tất cả các giao dịch và tính phí trực tiếp cho người gửi :

• Xác minh nonce khớp với nonce của tài khoản hiện tại của người gửi và khi có nhiều giao dịch từ cùng một người gửi, hãy đảm bảo các nonce là tuần tự.
• Đảm bảo số dư tài khoản đủ, được kiểm tra đối với người gửi mỗi giao dịch tại chỉ mục tương ứng trong khối.
• Tính toàn bộ số tiền gas trước (ví dụ: tx.gas * gas_price )
  • Điều này bao gồm gas cho blob và giá trị giao dịch bằng ETH
• Áp dụng lệnh chặn block_gas_limit > block_gas_used .
  Với block_gas_used = sum(tx.gas for tx in block.transactions) .
• Bắt đầu thực hiện giao dịch đầu tiên sau khi tất cả người gửi giao dịch đã được tính phí trước

Các mô hình liên quan đến việc cấp vốn cho một tài khoản và giao dịch ngay lập tức từ tài khoản đó trong cùng một khối có thể trở nên bất khả thi do xác thực thanh toán trước nghiêm ngặt. Điều này có thể được khắc phục bằng cách giới thiệu việc tài trợ phí cơ sở do coinbase của khối đó tài trợ.

Điều này có nghĩa là các giao dịch không chỉ được xác thực tĩnh mà còn được kiểm tra theo trạng thái hiện tại—đảm bảo rằng nonce khớp và có đủ tiền. Phí được giữ lại ngay lập tức.

Các giao dịch không còn có thể can thiệp lẫn nhau trong quá trình thực hiện, không giống như ngày nay. Kết quả là:

• Tài khoản không thể được cấp vốn và sau đó thực hiện giao dịch trong cùng một khối
• Giao dịch không thể làm cạn kiệt số dư của tài khoản khác và do đó làm mất hiệu lực các giao dịch tiếp theo

Cách tiếp cận này giúp giảm thiểu các vấn đề về DA miễn phí , vì các khối có thể bị từ chối sớm hơn— trước khi bắt đầu thực hiện. Khi xác thực trước hoàn tất và phí được giữ lại, người xác thực có thể tự tin xác nhận khối, biết rằng các giao dịch của nó sẽ thực hiện thành công theo thứ tự.

Thiết kế này đi kèm với sự đánh đổi về khả năng tương thích với FOCIL .

FOCIL yêu cầu thực hiện đầy đủ để xác minh sự tuân thủ IL. Chỉ có quyền truy cập vào khối và các giao dịch của nó là không đủ—bạn không thể xác định liệu IL có được tôn trọng chỉ từ thông tin đó. Thay vào đó, FOCIL yêu cầu kiểm tra xem bất kỳ giao dịch nào không được bao gồm trong khối nhưng nằm trong IL có thể được bao gồm hay không, với trạng thái sau khi thực hiện cuối cùng.

Một điểm quan trọng khi đưa FOCIL vào phương trình với các kiểm tra trước khi thực hiện là “làm thế nào để xử lý việc hoàn tiền gas_left ?”:

2.1 Với gas_left Hoàn tiền

Việc cho phép người gửi lấy lại gas_left của họ không thay đổi bất cứ điều gì so với hiện tại—tổng chi phí giao dịch vẫn như nhau.

Vấn đề thực sự nảy sinh với FOCIL. Một giao dịch có thể xuất hiện để tiêu thụ toàn bộ giới hạn gas khối nhưng thực tế không phải vậy. Ví dụ, một giao dịch ETH 21.000 gas đơn giản có thể được gửi với giới hạn gas bằng với giới hạn khối đầy đủ (ví dụ: 36 triệu gas). Theo FOCIL, một trình xây dựng khối có thể bao gồm giao dịch "có vẻ lớn" này và bỏ qua các IL.

Vấn đề là người chứng thực—trước khi thực hiện khối—không thể biết khối thực sự đầy hay không. FOCIL cho phép bỏ qua các giao dịch trên IL nếu khối được coi là đầy. Nhưng vì chúng ta không biết lượng gas mà các giao dịch được bao gồm thực sự sử dụng cho đến sau khi thực hiện, nên chúng ta không thể xác định liệu một giao dịch IL bị loại trừ có thể vừa với khối hay không.

Có hai giải pháp tiềm năng cho vấn đề này. Giải pháp đầu tiên là loại bỏ hoàn tiền gas. Giải pháp thứ hai là biến FOCIL thành vô điều kiện —tức là thực thi danh sách bao gồm bất kể khối có đầy hay không. Điều này loại bỏ hoàn toàn sự mơ hồ xung quanh việc sử dụng gas, đảm bảo rằng các mục nhập danh sách bao gồm không thể bị bỏ qua với lý do không đủ không gian khối.

2.2. Với capped gas_left Hoàn tiền

Thay vì cách tiếp cận trong 2.1, trong đó toàn bộ gas_left được hoàn lại cho người gửi, chúng ta có thể chỉ cần giới hạn mức hoàn lại. Ví dụ, việc giới hạn mức hoàn lại gas_left ở mức 50% lượng gas thực sự được giao dịch sử dụng sẽ khiến các cuộc tấn công kiểm duyệt (khi giới hạn gas cao được chỉ định nhưng chỉ một lượng nhỏ được tiêu thụ) trở nên không khả thi về mặt kinh tế. Ở khối gas 36 triệu, một nhà xây dựng kiểm duyệt chọn bỏ qua IL sẽ cần một giao dịch sử dụng ít nhất 24 triệu gas để nhận được mức hoàn lại tối đa là 50%, tức là 12 triệu gas.

Nhược điểm của cách tiếp cận này là nó làm cho việc đóng gói khối kém hiệu quả hơn. So với mô hình hiện tại, nơi mà lượng khí tích lũy được sử dụng được theo dõi, chúng ta có thể rơi vào tình huống mà mỗi giao dịch bao gồm một bộ đệm lớn hơn, hạn chế hiệu quả thông lượng. Để giảm thiểu điều này, có thể sử dụng mức trần thấp hơn - ví dụ, giới hạn hoàn tiền ở mức 10% gas_used , điều này sẽ làm giảm đáng kể chi phí đệm.

2.3 Không có gas_left Hoàn tiền

Việc loại bỏ hoàn tiền gas_left sẽ khiến việc giả mạo mức sử dụng gas lớn trở nên không khả thi về mặt kinh tế , vì người dùng sẽ phải trả toàn bộ số tiền cho hạn mức gas đã khai báo, bất kể mức tiêu thụ thực tế là bao nhiêu.

Điều này giải quyết cuộc tấn công vào FOCIL, nơi một nhà xây dựng bao gồm các giao dịch có vẻ lớn—tuyên bố giới hạn gas cao—cuối cùng lại rất rẻ để thực hiện, trên thực tế là làm giả một khối đầy đủ để bỏ qua danh sách bao gồm.

Rõ ràng, tùy chọn này là một thay đổi UX khá triệt để.

2.4 Với gas_left Hoàn tiền và Optimistic gas_used

Một cách khác để giải quyết sự không tương thích của FOCIL là kết hợp xác thực trước với xác thực lạc quan . Trong cách tiếp cận này, chúng tôi giới thiệu một trường tiêu đề mới, block_gas_used , mà trình xây dựng phải thiết lập. Sau khi thực thi, chúng tôi xác minh rằng block_gas_used khớp với khí thực tế được sử dụng. Nếu không, khối được coi là không hợp lệ và phải được sắp xếp lại.

Điều này sẽ có lợi cho FOCIL vì trình xác thực có thể kiểm tra đáng tin cậy xem giao dịch từ IL có thể được thêm vào khối hay không, dựa trên mức sử dụng gas đã khai báo.

Tuy nhiên, sự phức tạp của lựa chọn fork liên quan đến xác nhận lạc quan vẫn áp dụng. Một khối có block_gas_used không chính xác sẽ không trở thành chuẩn, nhưng chúng ta vẫn có thể muốn cho phép xác nhận các khối như vậy tác động đến lựa chọn fork.

3. Sạc trước <thực thể>

Tính phí trước cho một thực thể trước khi thực hiện và hoàn tiền sau đó là một cách hiệu quả để giải quyết DA miễn phí . Bất cứ khi nào dữ liệu được ghi trên chuỗi mà không có ai trả tiền, giao thức có thể chỉ cần giữ lại khoản hoàn tiền từ bên bị tính phí trước. Điều này đảm bảo rằng giao thức luôn được đền bù, ngay cả trong trường hợp không có ai trả tiền rõ ràng cho dữ liệu.

3.1 Chi phí bao gồm mặt tiền Coinbase

Phiên bản ban đầu của việc thực hiện chậm trễ đã tính phí trước cho tài khoản COINBASE với chi phí bao gồm của tất cả các giao dịch. Chi phí bao gồm bao gồm gas cho calldata, blob và danh sách truy cập EIP-2930. Coinbase trả trước chi phí và các giao dịch trở nên không hợp lệ trong quá trình thực hiện sẽ bị bỏ qua, với dấu chân dữ liệu của chúng đã được thanh toán.

Ưu điểm

• Không có gì thay đổi đối với người dùng, điều này thật tuyệt.
• Không có thay đổi lựa chọn phân nhánh nào xung quanh các khối không hợp lệ vẫn có giá trị.
• Không có sự thiếu hiệu quả khi đóng gói khối khi sử dụng tx.gas . Thay vào đó, chúng ta có thể sử dụng khí thực tế được sử dụng.

Nhược điểm

• Xây dựng khối trở nên phức tạp hơn vì chúng tôi yêu cầu tài khoản Coinbase phải duy trì số dư ETH đủ để chi trả chi phí bao gồm trước. Khách hàng thực hiện sẽ chỉ xây dựng các khối hợp lệ dựa trên số dư Coinbase—các khối trống trong trường hợp xấu nhất.
• Sự không tương thích của FOCIL
• Quản lý khóa coinbase trở thành một vấn đề—đặc biệt nếu trình xác thực cần khóa riêng để ký khối và rút phần thưởng. Hợp đồng ERC-1271 có thể là cần thiết, gây ra sự phức tạp, đặc biệt là khi cần xây dựng cục bộ như một giải pháp dự phòng.

Sự không tương thích với FOCIL bắt nguồn từ việc không thể thực thi IL trước khi thực thi. Ngay cả khi một khối được xác thực tĩnh, coinbase được tính phí trước cho chi phí bao gồm và cho phép bỏ qua các giao dịch, một khối vẫn có thể trở nên không hợp lệ theo FOCIL nếu nó không bao gồm một giao dịch nằm trong IL, mặc dù có không gian trong khối.

3.2 Xác thực trước với Hoàn tiền + Coinbase fronts gas_claimed

Để giải quyết vấn đề không tương thích FOCIL, một giải pháp tiềm năng là chuyển sang xác thực giao dịch trước, với coinbase sẽ trả trước toàn bộ gas_used * base_fee cho tất cả các giao dịch trong khối. Một trường tiêu đề mới, gas_claimed , sẽ cho phép trình xây dựng khối khai báo lượng gas mà khối tiêu thụ. Điều này cho phép kiểm tra xác thực để xác định xem giao dịch từ IL có phù hợp với khối hay không.

Theo mô hình này, người xây dựng trả trước phí cơ bản cho tất cả khí gas đã yêu cầu. Trong quá trình thực hiện, toàn bộ phí giao dịch—bao gồm phí ưu tiên—cho các giao dịch đã thực hiện sẽ được hoàn lại cho người xây dựng. Nếu giá trị gas_claimed phản ánh chính xác mức sử dụng khí gas thực tế, người xây dựng chỉ cần được hoàn lại tiền, cộng với họ nhận được phí ưu tiên. Tuy nhiên, nếu lượng khí gas đã yêu cầu vượt quá lượng khí gas thực tế đã sử dụng—ví dụ, để tránh bao gồm các giao dịch IL—thì người xây dựng sẽ phải trả tiền cho lượng khí gas đó.

3.3 Hình phạt của người đề xuất

Tương tự như các yêu cầu mục đích chung trên EL, chúng ta có thể giới thiệu một trường mới trong tải trọng thực thi được gọi là proposer_penalty , biểu diễn tổng phí gas từ tất cả các giao dịch bị bỏ qua. Khi xử lý tải trọng trên CL, proposer_penalty này sẽ được khấu trừ khỏi proposal. Yêu cầu cần được hoãn lại trong một khối để chúng ta xử lý hình phạt từ khe n n trong khe n{+}1 n + 1 .

Ưu điểm của cách tiếp cận này là nó loại bỏ nhu cầu về một tài khoản được cấp vốn trên EL. Thay vào đó, nó tận dụng cổ phần hiện có trên CL.

Tuy nhiên, nhược điểm là nó làm tăng rủi ro tài chính cho người đề xuất. Trong trường hợp xấu nhất, họ không chỉ mất phần thưởng mà còn có thể mất tiền. Đối với người dùng MEV-Boost, điều này có nghĩa là ký vào một khối có thể khiến họ mất tiền, dựa vào rơle để thực hiện xác thực phù hợp trước thời hạn.

Ưu điểm

• Không yêu cầu số dư EL. Người đề xuất đã đặt cược ETH và duy trì đủ số dư để quản lý các khoản phạt này.

Nhược điểm

• Giới thiệu một mô hình mới: Người xác thực hiện bị phạt ở lớp đồng thuận vì xây dựng các khối “xấu”.
• Đối với người dùng MEV-Boost, hành vi chuyển tiếp sai sẽ làm tăng rủi ro tài chính. Trước đây, các chuyển tiếp độc hại chỉ có thể khiến người đề xuất bỏ lỡ các vị trí; giờ đây, người đề xuất có thể phải chịu tổn thất tài chính trực tiếp.

Chi phí bao gồm thường rất thấp (~0,55 ETH giả sử mức phí cơ sở rất cao là 100 gwei). Do đó, mức phạt cũng phải thấp ở mức trung bình. Trường hợp xấu nhất chỉ đơn giản là gas_limit * base_fee .

Việc người đề xuất trả bằng cổ phần cũng có thể được sử dụng như một phương án dự phòng cho việc Coinbase chi trả chi phí trước.

4. Tải trọng Không hoạt động

Một ý tưởng liên quan đến việc chứng thực lạc quan hoạt động như sau:

1. Chỉ thực hiện xác thực tĩnh cho khối.
2. Đảm bảo không có giao dịch nào bị bỏ qua.
3. Nếu bất kỳ giao dịch nào được phát hiện là không hợp lệ trong quá trình thực hiện, hãy coi toàn bộ payload EL là no-op . Điều này có nghĩa là khôi phục trạng thái về trạng thái trước đó và tiếp tục từ đó. Khách hàng vẫn cần giữ lại payload để xác minh tính chính xác của việc khôi phục trong quá trình đồng bộ hóa.

Lợi ích chính của cách tiếp cận này là người chứng thực vẫn có thể chứng thực khối sớm. Tuy nhiên, không giống như chứng thực lạc quan, khối sẽ vẫn là chuẩn ngay cả khi tải trọng của nó không hợp lệ. Điều này tránh được sự phức tạp khi xử lý các chứng thực trung thực đối với một khối sau đó được tổ chức lại. Thay vào đó, người chứng thực sẽ chứng thực khối mà tải trọng thực thi của nó chỉ trở thành no-op.
Theo quan điểm của người đề xuất, để khai thác cơ chế này cho DA miễn phí, bạn sẽ muốn ít nhất những gì bạn nhận được dưới dạng thanh toán MEV-Boost hoặc, đối với các nhà xây dựng địa phương, phí ưu tiên của khối, để bù đắp. Vì vậy, không có lợi nhuận bền vững nào được tạo ra từ việc khai thác cơ chế cho "DA miễn phí" - mà KHÔNG hề miễn phí. Hoàn nguyên trạng thái có nghĩa là hoàn nguyên tất cả các giao dịch và phí ưu tiên của chúng. Nó cũng có nghĩa là hoàn nguyên khoản thanh toán của nhà xây dựng cho người đề xuất, do đó, rất khó có khả năng người đề xuất sẽ tham gia vào các chiến lược như vậy.

Ưu điểm

• Fork-choice không cần quan tâm đến các khối không hợp lệ vì BeaconBlock vẫn “hợp lệ” như trước.

Nhược điểm

• Không thực sự giải quyết được DA miễn phí. Các giao dịch cần được lưu giữ để xác thực rằng tải trọng thực sự là không hoạt động và để đồng bộ hóa.
• Chúng tôi chỉ có thể biến payload thành no-op trong/sau khi thực hiện. Do đó, các giao dịch blob vẫn có thể được coi là "có sẵn".

4.1 Bộ cảm biến tính phí trước và Tải trọng Không hoạt động cho gas_used

Trong thiết kế này, người gửi vẫn trả trước cho giới hạn gas của giao dịch trước khi thực hiện và nhận lại gas_left sau khi thực hiện. Để thực thi giới hạn gas, người xây dựng phải ghi lượng gas mà khối sử dụng vào tiêu đề. Tải trọng EL chuyển thành no-op nếu gas_used khác với gas_used được chỉ định trong khối. Chuyển thành no-op có nghĩa là quay lại trạng thái trước khối.

Kiểm tra cách triển khai của Francesco bằng cách sử dụng thông số kỹ thuật thực thi Ethereum.

Ưu điểm

• không có thay đổi lựa chọn ngã ba phức tạp, người chứng thực có thể chứng thực cho một BeaconBlock có tải trọng chuyển thành không hoạt động,
• gas_left hoàn tiền có thể giữ nguyên, do đó UX vẫn không thay đổi,
• thân thiện với người xây dựng và IL,
• “ DA tự do ” thực sự chưa được giải quyết, nhưng trên thực tế, việc thực hiện các chiến lược khai thác nó là không bền vững.

Nhược điểm

• việc cấp vốn cho một tài khoản và giao dịch từ tài khoản đó trong một khối trở nên bất khả thi, trừ khi phí cơ sở do COINBASE tài trợ được đưa vào thêm.

Tổng quan về các tùy chọn

1. Sự xác nhận lạc quan
2. Người gửi tính phí trước cho toàn bộ tx.gas
3. Coinbase tính phí trước
4. EL Payload không hoạt động

^ theo dõi chứng thực cho một khối không hợp lệ
^^ xác thực tĩnh yêu cầu included_gas <= claims_gas_used, do đó chi phí bao gồm được chi trả trước và chúng ta có thể bỏ qua các giao dịch vượt quá giới hạn gas

Tiếp cận	UX của người gửi	Độ phức tạp của người xây dựng	Độ phức tạp của lựa chọn ngã ba	Xác thực tĩnh	Khả năng tương thích FOCIL	Yêu cầu sum(tx.gas) < block_gas_limit
(1)	Như nhau	Như nhau	Cao hơn^	KHÔNG	Thấp (thực thi hai pha)	KHÔNG
(2) không có gas_left được hoàn lại	Luôn trả tiền xăng đầy đủ	Như nhau	Không có	Đúng	Đúng	Đúng
(2) với gas_left được hoàn lại	Như nhau	Như nhau	Không có	Đúng	Thấp (thực thi hai pha)	Đúng
(2) với gas_left được hoàn lại + (1) (lạc quan gas_used)	Như nhau	Như nhau	Cao hơn^	KHÔNG	Đúng	KHÔNG
(2) với gas_left được hoàn lại + (3) cho gas_used đã yêu cầu	Như nhau	Coinbase được tài trợ	Không có	Có^^	Đúng	KHÔNG
(3) cho chi phí bao gồm	Như nhau	Coinbase được tài trợ	Không có	Đúng	Thấp (thực thi hai pha)	KHÔNG
(4)	Như nhau	Như nhau	Không có	Đúng	Thấp (thực thi hai pha)	KHÔNG
(2) với gas_left được hoàn lại + (4) cho gas_used	Như nhau	Như nhau	Không có	Đúng	Đúng	KHÔNG

hình ảnh 1024×1024 34 KB