Vitalik's Bài Viết Nhanh Mới: Định Giá Gas Đa Chiều

Do đó, việc thêm một chiều Gas riêng cho các hoạt động tăng kích thước trạng thái (ví dụ, từ không đến không-zero SSTORE, tạo hợp đồng) có thể có giá trị, nhưng với một mục tiêu khác: chúng ta có thể đặt một giá động nhắm mục tiêu vào một lượng sử dụng trung bình cụ thể nhưng không đặt một giới hạn cho mỗi khối.

Điều này thể hiện một thuộc tính mạnh mẽ của Gas đa chiều: nó cho phép chúng ta tách biệt hỏi cho mỗi tài nguyên (i) sử dụng trung bình lý tưởng là bao nhiêu? (ii) sử dụng tối đa an toàn mỗi khối là bao nhiêu? Bằng cách đặt giá Gas dựa trên giá trị tối đa mỗi khối và cho phép sử dụng trung bình thay đổi, chúng ta có 2n độ tự do để đặt 2n tham số, điều chỉnh mỗi tham số dựa trên các yếu tố an ninh mạng.

Trong các tình huống phức tạp hơn, chẳng hạn như khi các yếu tố an ninh cho hai tài nguyên trùng lắp một phần, việc xử lý điều này có thể được thực hiện bằng cách có một opcode hoặc tài nguyên tiêu thụ nhiều loại Gas trong một số lượng nhất định (ví dụ, một zero-to-non-zero SSTORE có thể tiêu thụ 5000 Gas chứng minh khách hàng không có trạng thái và 20000 Gas mở rộng lưu trữ).

Tối đa mỗi giao dịch (chọn cái có chi phí dữ liệu hoặc tính toán cao hơn)

Hãy để 𝑥1 là chi phí Gas cho dữ liệu, 𝑥2 là chi phí Gas cho tính toán, vì vậy trong một hệ thống Gas một chiều, chúng ta có thể viết chi phí Gas của một giao dịch như sau:

Trong kế hoạch này, chúng ta xác định chi phí Gas của một giao dịch như sau:

Nghĩa là, các giao dịch được tính phí dựa trên việc họ tiêu thụ nhiều tài nguyên nào hơn, thay vì tổng của dữ liệu và tính toán. Điều này dễ dàng mở rộng để bao gồm nhiều chiều hơn (ví dụ, 𝑚𝑎𝑥(...,𝑥3∗𝑠𝑡𝑜𝑟𝑎𝑔𝑒_𝑎𝑐𝑐𝑒𝑠𝑠)).

Có thể thấy cách này làm tăng hiệu suất trong khi đảm bảo an ninh. Lý thuyết, khối lượng dữ liệu tối đa trong một khối vẫn là Gas LIMIT /𝑥1, giống như trong một hệ thống Gas một chiều. Tương tự, tối đa tính toán lý thuyết là Gas LIMIT /𝑥2, cũng giống như trong một hệ thống Gas một chiều. Tuy nhiên, chi phí Gas cho bất kỳ giao dịch nào tiêu thụ dữ liệu và tính toán sẽ giảm.

Điều này có thể là phương pháp được áp dụng trong EIP-7623 đề xuất để giảm kích thước khối tối đa trong khi tiếp tục tăng số lượng blob. Cơ chế chính xác trong EIP-7623 phức tạp hơn một chút: nó giữ giá calldata hiện tại ở 16 Gas mỗi byte nhưng giới thiệu một giá tối thiểu là 48 Gas mỗi byte; các giao dịch trả phí cao hơn giữa (16 * byte + execution _ Gas) và (48 * byte). Do đó, EIP-7623 giảm giá trị tối đa lý thuyết của dữ liệu gọi giao dịch trong một khối từ khoảng 1,9 MB xuống khoảng 0,6 MB trong khi giữ nguyên chi phí cho hầu hết các ứng dụng. Lợi ích của phương pháp này là nó thay đổi rất ít so với hệ thống Gas một chiều hiện tại, làm cho việc triển khai rất dễ dàng.

Tuy nhiên, phương pháp này có hai điểm nhược:

1. Ngay cả khi tất cả các giao dịch khác trong một khối sử dụng rất ít tài nguyên đó, các giao dịch tiêu thụ mạnh một tài nguyên vẫn sẽ bị tính phí lớn một cách không cần thiết;

2. Nó khuyến khích việc gom giao dịch tiêu thụ dữ liệu nặng và tính toán nặng cùng nhau để tiết kiệm chi phí.

Tôi tin rằng các quy tắc như trong EIP-7623, cho dữ liệu gọi giao dịch hoặc các tài nguyên khác, có thể mang lại lợi ích đáng kể, ngay cả với những điểm nhược này.

Tuy nhiên, nếu chúng ta sẵn lòng đầu tư (rất nhiều) nỗ lực phát triển, một phương pháp lý tưởng hơn sẽ xuất hiện.

EIP-1559 Đa chiều: Một Chiến lược Khó Khăn nhưng Lý tưởng Hơn

Hãy xem xét cách EIP-1559 tiêu chuẩn hoạt động trước tiên. Chúng ta sẽ tập trung vào phiên bản được giới thiệu cho các blob trong EIP-4844, vì nó có vẻ toán học hơn.

Chúng ta theo dõi một tham số excess _ blobs. Trong mỗi khoảng thời gian khối, chúng ta đặt:

excess _ blobs <-- max (excess _ blobs + len(block.blobs) - TARGET, 0)

nơi TARGET = 3. Điều này có nghĩa là nếuMột khối có nhiều hạt hơn mục tiêu, số hạt thừa tăng lên, và nếu một khối có ít hạt hơn mục tiêu, số hạt thừa giảm đi. Sau đó, chúng ta đặt blob _ basefee = exp(số hạt thừa / 25.47), trong đó exp là hàm mũ 𝑒𝑥𝑝(𝑥)=2.71828^𝑥's xấp xỉ.

Điều này có nghĩa là mỗi khi số hạt thừa tăng khoảng 25, phí cơ sở cho hạt tăng khoảng 2.7 lần. Nếu hạt trở nên quá đắt đỏ, việc sử dụng trung bình giảm, và số hạt thừa bắt đầu giảm, tự động giảm giá lại. Giá của hạt được điều chỉnh liên tục để đảm bảo rằng trên trung bình, các khối chỉ đầy khoảng một nửa, có nghĩa là mỗi khối chứa trung bình 3 hạt.

Nếu có một đỉnh tạm thời trong việc sử dụng, có một giới hạn: mỗi khối chỉ có thể chứa tối đa 6 hạt, trong trường hợp đó, các giao dịch có thể cạnh tranh bằng cách tăng phí ưu tiên. Tuy nhiên, trong các hoàn cảnh bình thường, mỗi hạt chỉ cần trả phí cơ sở cho hạt cộng thêm một khoản phí ưu tiên nhỏ để được bao gồm như một động lực.

Loại hình định giá Gas này đã tồn tại trong Ethereum từ nhiều năm: ngay từ năm 2020, EIP-1559 đã giới thiệu một cơ chế rất tương tự. Thông qua EIP-4844, chúng ta đặt hai mức giá độc lập cho Gas và Hạt.

Lưu ý: Phí cơ sở Gas trong gwei cho một giờ vào ngày 8 tháng 5 năm 2024. Nguồn: ultrasound.money

Về nguyên tắc, chúng ta có thể thêm nhiều phí độc lập cho việc đọc lưu trữ và các loại hoạt động khác, nhưng tôi sẽ trình bày một vấn đề cần chú ý trong phần tiếp theo.

Đối với người dùng, trải nghiệm này rất giống với hiện tại: bạn không còn trả phí cơ sở (basefee) nữa, mà là hai phí cơ sở, mà ví của bạn có thể trừ trực tiếp từ bạn, chỉ hiển thị phí dự kiến và phí tối đa bạn có thể mong đợi trả.

Đối với người xây dựng khối, chiến lược tối ưu hóa đa phần giống như hiện tại: bao gồm bất kỳ nội dung hợp lệ nào. Hầu hết các khối không đầy—dù là về Gas hay Hạt. Một tình huống khó khăn nảy sinh khi có đủ Gas hoặc đủ Hạt để vượt quá giới hạn khối, đòi hỏi người xây dựng có thể giải quyết một vấn đề ba chiều để tối đa hóa lợi nhuận của họ. Tuy nhiên, ngay cả với các thuật toán xấp xỉ khá tốt, lợi ích từ việc tối ưu hóa lợi nhuận thông qua các thuật toán độc quyền trong tình huống này nhỏ hơn nhiều so với việc sử dụng MEV cho các hoạt động tương tự.

Đối với các nhà phát triển, thách thức chính là cần phải thiết kế lại chức năng của EVM và cơ sở hạ tầng liên quan của nó, hiện đang được thiết kế dựa trên một giá và giới hạn duy nhất và bây giờ cần phải được tái cấu trúc để chứa nhiều giá và giới hạn.

Một vấn đề mà các nhà phát triển ứng dụng phải đối mặt là việc tối ưu hóa trở nên phức tạp hơn một chút: trong một số trường hợp, bạn không còn có thể nói rõ ràng A hiệu quả hơn B vì nếu A sử dụng nhiều calldata và B sử dụng nhiều thực thi, A có thể rẻ hơn khi calldata rẻ và đắt hơn khi calldata đắt.

Tuy nhiên, các nhà phát triển vẫn có thể đạt được kết quả khá tốt bằng cách tối ưu hóa dựa trên giá trung bình lịch sử dài hạn.

Định giá Đa chiều, EVM, và Các cuộc gọi con

Một vấn đề không nảy sinh trong hạt, và cũng không nảy sinh trong EIP-7623 hoặc thậm chí trong một triển khai định giá đa chiều hoàn chỉnh cho calldata, nhưng sẽ nảy sinh nếu chúng ta cố gắng định giá từng cá nhân truy cập trạng thái hoặc bất kỳ tài nguyên nào khác, đó là giới hạn Gas trong các cuộc gọi con.

Giới hạn Gas trong EVM tồn tại ở hai nơi. Đầu tiên, mỗi giao dịch đặt một giới hạn Gas, hạn chế tổng lượng Gas có thể được sử dụng trong giao dịch đó. Thứ hai, khi một hợp đồng gọi một hợp đồng khác, cuộc gọi đó có thể đặt giới hạn Gas riêng của mình. Điều này cho phép các hợp đồng gọi các hợp đồng khác mà họ không tin tưởng và vẫn đảm bảo họ có một giới hạn sau khi cuộc gọi được thực hiện.

Còn Gas còn lại để thực thi các phép tính khác.

<img src="https://img.bitgetimg.com/multiLang/image/ec5474dbb2a7f1806abef925ed20134b171525709<p>Chú ý: Dấu vết của các giao dịch trừu tượng liên quan đến một tài khoản gọi một tài khoản khác và cung cấp một lượng Gas hạn chế cho người được gọi để đảm bảo rằng ngay cả khi người được gọi tiêu hết toàn bộ Gas được phân bổ cho nó, cuộc gọi bên ngoài vẫn có thể tiếp tục chạy.</p> <p>Thách thức đặt ra ở việc đạt được Gas đa chiều giữa các loại thực thi khác nhau, điều này dường như đòi hỏi nhiều hạn chế cho mỗi loại Gas cho các cuộc gọi con, đòi hỏi những thay đổi rất sâu trong EVM và không tương thích với các ứng dụng hiện có.</p> <p>Đây là một trong những lý do tại sao các đề xuất Gas đa chiều thường giữ lại ở hai chiều: dữ liệu và thực thi. Dữ liệu (dù là calldata giao dịch hoặc blob) được phân bổ bên ngoài cho EVM, vì vậy không cần thay đổi nội bộ của EVM để định giá calldata hoặc blob một cách riêng biệt.</p> <p>Chúng ta có thể đưa ra một " giải pháp theo kiểu EIP-7623" để quyết vấn đề này. Dưới đây là một cách triển khai đơn giản: tính 4 lần phí cho các hoạt động lưu trữ trong quá trình thực thi; giản hóa việc phân tích, giả sử mỗi tốn 10000 gas. Cuối giao dịch, hoàn lại min(7500 * động_lưu_trữ, Gas_thực_thi). Kết quả, sau khi trừ lại, người dùng cần trả khoản sau:< p>

Gas_thực_thi + 10000 * hoạt_động_lưu_trữ - min(7500 * hoạt_động_lưu_trữ, Gas_thực_thi)

Điều này bằng:

max(Gas_thực_thi + 2500 * hoạt_động_lưu_trữ, 10000 * hoạt_động_lưu_trữ)

Điều này phản ánh cấu trúc của EIP-7623. Một cách tiếp cận khác là theo dõi hoạt_động_lưu_trữ và Gas_thực_thi theo thời gian thực và tính phí 2500 hoặc 10000 dựa trên việc tăng max(Gas_thực_thi + 2500 * hoạt_động_lưu_trữ, 10000 * hoạt_động_lưu_trữ) đã tăng lên bao nhiêu khi mã opcode được gọi. Điều này tránh cần phải giao Gas quá mức, chủ yếu được hoàn lại thông qua việc hoàn trả.

Chúng tôi không nhận được sự cho phép tinh mịch cho các cuộc gọi con: các cuộc gọi con có thể tiêu hết toàn bộ phần phép của một giao dịch cho các hoạt động lưu trữ rẻ tiền.

Nhưng chúng tôi đã có được một điều khá tốt, đó là, hợp đồng thực hiện cuộc gọi con có thể đặt một giới hạn và đảm bảo rằng sau khi cuộc gọi con hoàn tất, cuộc gọi chính vẫn còn đủ Gas cho việc xử lý sau cần thiết.

Giải pháp "hoàn chỉnh về giá đa chiều" đơn giản nhất mà tôi có thể nghĩ đến là: chúng ta coi xét giới hạn Gas cho các cuộc gọi con là tỷ lệ. Nghĩa là, giả sử có 𝑘 loại thực thi khác nhau, và mỗi giao dịch đặt giới hạn đa chiều 𝐿1...𝐿𝑘. Giả sử tại điểm thực thi hiện tại, Gas còn lại là 𝑔1...𝑔𝑘. Giả sử một mã CALL được gọi, sử dụng giới hạn Gas cho cuộc gọi con 𝑆. Đặt 𝑠1=𝑆, sau đó 𝑠2=𝑠1/𝑔1*𝑔2, 𝑠3=𝑠1/𝑔1*𝑔3, và cứ tiếp tục như vậy.

Nói cách khác, chúng ta xem xét Gas cho loại đầu tiên (thực sự là thực thi VM) như một "đơn vị tài khoản" đặc biệt, sau đó phân bổ Gas cho các loại khác sao cho cuộc gọi con nhận cùng một phần trăm Gas khả dụng trong mỗi loại. Cách tiếp cận này có thể trông hơi xấu xí, nhưng nó tối đa hóa tính tương thích ngược với phiên bản trước.

Nếu chúng ta muốn làm cho giải pháp này trở nên "trung lập" hơn giữa các loại Gas khác nhau mà không hy sinh tính tương thích ngược, chúng ta có thể đơn giản biểu diễn tham số giới hạn Gas cho cuộc gọi con như một phần của Gas còn lại trong ngữ cảnh hiện tại (ví dụ, [1...63]/64).

Tuy nhiên, bất kể trường hợp nào, đáng lưu ý rằng một khi chúng ta bắt đầu giới thiệu Gas thực thi đa chiều, sự phức tạp bẩm sinh sẽ tăng lên, điều này dường như khó tránh khỏi.

Do đó, nhiệm vụ của chúng ta là thực hiện một sự cân nhắc phức tạp: chúng ta có chấp nhận một mức độ tăng phức tạp (xấu xí) tại cấp độ EVM để mở khóa những lợi ích quan trọng về khả năng mở rộng L1, và nếu có, đề xuất cụ thể nào là hiệu quả nhất đối với kinh tế giao thức và các nhà phát triển ứng dụng? Rất có khả năng rằng không phải cả hai giải pháp mà tôi đề cập ở trên là tốt nhất, nhưng vẫn còn không gian để đề xuất những giải pháp tinh tế và tốt hơn.

Cảm ơn đặc biệt Ansgar Dietrichs, Barnabe Monnot, và Davide Crapis vì phản hồi và xem xét của họ.