Trong Ethereum, tài nguyên cho đến gần đây vẫn bị giới hạn và định giá bằng cách sử dụng một loại tài nguyên duy nhất gọi là “gas”. Gas là một đơn vị đo lường lượng “nỗ lực tính toán” cần thiết để xử lý một giao dịch hoặc khối cụ thể. Gas kết hợp cùng nhau nhiều loại “nỗ lực”, đáng chú ý nhất là:
- Tính toán thô (ví dụ: CỘNG, NHÂN)- Đọc và ghi vào bộ nhớ lưu trữ Ethereum (ví dụ: SSTORE, SLOAD, chuyển ETH)- Băng thông dữ liệu- Chi phí tạo ra một Chứng minh ZK-SNARKcủa khốiVí dụ, giao dịch nàyTôi đã gửi đã tốn tổng cộng 47,085 gas. Điều này được chia thành (i) một “chi phí cơ sở” của 21000 gas, (ii) 1556 gas cho byte trong calldata được bao gồm là một phần của giao dịch (iii) 16500 gas cho việc đọc và ghi vào bộ nhớ, (iv) gas 2149 để thực hiện một nhật ký, và phần còn lại để thực thi EVM. Phí giao dịch mà người dùng phải trả tỷ lệ thuận với lượng gas mà giao dịch tiêu thụ. Một khối có thể chứa tối đa 30 triệu gas, và giá gas được điều chỉnh liên tục qua @vbuterin/eip-1559-faq">EIP-1559 cơ chế nhắm mục tiêu, đảm bảo rằng trung bình, các khối chứa 15 triệu khí.
Cách tiếp cận này có một hiệu suất chính lớn: vì mọi thứ được hợp nhất thành một tài nguyên ảo duy nhất, nó dẫn đến một thiết kế thị trường rất đơn giản. Tối ưu hóa giao dịch để giảm thiểu chi phí là dễ dàng, tối ưu hóa một khối để thu thập phí cao nhất có thể là tương đối dễ dàng (không bao gồm MEV) và không có cơ hội kỳ lạ nào khuyến khích một số giao dịch gói chung với các giao dịch khác để tiết kiệm phí.
Nhưng phương pháp này cũng có một hiệu suất chính không tốt: nó xem xét các nguồn lực khác nhau như là có thể chuyển đổi lẫn nhau, khi sự giới hạn cơ bản thực sự về những gì mạng có thể xử lý không phải như vậy. Một cách để hiểu vấn đề này là nhìn vào sơ đồ này:
Giới hạn gas áp đặt một ràng buộc của
𝑥1∗𝑑𝑎𝑡𝑎+𝑥2∗𝑐𝑜𝑚𝑝𝑢𝑡𝑎𝑡𝑖𝑜𝑛- Các giao dịch mà tốn nhiều tài nguyên vẫn bị tính một lượng lớn một cách không cần thiết, ngay cả khi tất cả các giao dịch khác trong khối sử dụng ít tài nguyên đó.- Nó tạo động lực cho các giao dịch nặng về dữ liệu và tính toán hợp nhất lại với nhau thành một gói để tiết kiệm chi phí.Tôi sẽ cho rằng một quy tắc kiểu EIP-7623, cả về dữ liệu giao dịch và về các nguồn lực khác, có thể mang lại các lợi ích đủ lớn để đáng giá ngay cả khi có những hạn chế này. Tuy nhiên, nếu và khi chúng ta sẵn lòng đầu tư vào nỗ lực phát triển (đáng kể cao hơn), có một cách tiếp cận lý tưởng hơn.
Đa chiều EIP-1559: chiến lược khó nhưng lý tưởngHãy đầu tiên tổng kết cách hoạt động của EIP-1559 “thường”. Chúng tôi sẽ tập trung vào phiên bản được giới thiệu trong EIP-4844 cho các đoạn văn, vì nó toán học tinh tế hơn.
Chúng tôi theo dõi một tham số, excess_blobs. Trong mỗi khối, chúng tôi thiết lập:
excess_blobs EIP-1559 trở lại vào năm 2020. Với EIP-4844, chúng ta hiện có hai mức giá riêng biệt cho gas và cho blobs.
Phí cơ sở gas trong vòng một giờ vào ngày 08-05-2024, tính bằng gwei. Nguồn: ultrasound.money.
Về nguyên tắc, chúng tôi có thể thêm nhiều khoản phí riêng lẻ cho việc đọc lưu trữ và các loại hoạt động khác, tuy nhiên với một điều cần lưu ý mà tôi sẽ mở rộng trong phần tiếp theo.
Đối với người dùng, trải nghiệm rất giống với hiện tại: thay vì thanh toán một khoản phí cơ sở, bạn sẽ thanh toán hai khoản phí cơ sở, nhưng ví của bạn có thể trừ trừ điều đó và chỉ hiển thị cho bạn khoản phí dự kiến và khoản phí tối đa mà bạn có thể mong đợi phải thanh toán.
Đối với những người xây dựng khối, hầu hết thời gian chiến lược tối ưu là giống như ngày hôm nay: bao gồm bất cứ điều gì hợp lệ. Hầu hết các khối không đầy - không phảitrong khínortrong các đám. Trường hợp thách thức duy nhất là khi có đủ khí hoặc đủ blobs để vượt quá giới hạn khối, và người xây dựng cần có thể giải quyết một Vấn đề ba lô đa chiềuđể tối đa hóa lợi nhuận của nó. Tuy nhiên, ngay cả khi có các thuật toán xấp xỉ khá tốt, và lợi ích từ việc tạo ra các thuật toán độc quyền để tối ưu hóa lợi nhuận trong trường hợp này cũng nhỏ hơn nhiều so với lợi ích từ việc làm điều tương tự với MEV.
Đố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 các tính năng của EVM và hệ thống xung quanh của nó, được thiết kế xung quanh một giá và một giới hạn ngày nay thành một thiết kế có thể chứa nhiều giá và nhiều giới hạn. Một vấn đề đối với các nhà phát triển ứng dụng là tối ưu hóa trở nên khó khăn hơn: trong một số trường hợp, bạn không còn thể nói rõ ràng rằng A hiệu quả hơn B, vì nếu A sử dụng nhiều calldata hơn nhưng B sử dụng nhiều thực thi hơn, thì 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ả tương đối tốt bằng cách tối ưu hóa dựa trên giá trị trung bình lịch sử dài hạn.
Giá đa chiều, EVM và cuộc gọi phụCó một vấn đề mà không xuất hiện với blobs, và cũng sẽ không xuất hiện với EIP-7623 hoặc thậm chí một bản triển khai giá đa chiều 'đầy đủ' cho calldata, nhưng sẽ xuất hiện nếu chúng ta cố gắng định giá truy cập trạng thái một cách riêng lẻ, hoặc bất kỳ tài nguyên nào khác: 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, giới hạn tổng lượng gas có thể 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 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 rằng họ sẽ còn gas để thực hiện các phép tính khác sau cuộc gọi đó.
Một dấu vết của một giao dịch trừu tượng tài khoản, nơi một tài khoản gọi một tài khoản khác, và chỉ cung cấp cho người được gọi một lượng gas hạn chế, để đảm bảo rằng cuộc gọi bên ngoài vẫn có thể tiếp tục chạy ngay cả khi người được gọi tiêu thụ toàn bộ gas được gán cho nó.
Thách thức là: làm cho khí đa chiều giữa các loại thực thi khác nhau dường như sẽ đòi hỏi các cuộc gọi con để cung cấp nhiều giới hạn cho mỗi loại khí, điều này sẽ đòi hỏi một sự thay đổi sâu rộng đối với EVM và sẽ không tương thích với các ứng dụng hiện có.
Điều này là một lý do tại sao các đề xuất khí đa chiều thường dừng lại ở hai chiều: dữ liệu và thực hiện. Dữ liệu (dù là calldata giao dịch hoặc blobs) chỉ được gán bên ngoài EVM, vì vậy không cần thay đổi bất cứ điều gì bên trong EVM để làm cho calldata hoặc blobs có giá riêng biệt.
Chúng ta có thể nghĩ ra một "giải pháp kiểu EIP-7623" cho vấn đề này. Đây là một cách triển khai đơn giản: trong quá trình thực hiện, tính phí gấp 4 lần cho các hoạt động lưu trữ; Để đơn giản hóa việc phân tích, giả sử 10000 khí cho mỗi hoạt động lưu trữ. Khi kết thúc giao dịch, hoàn lại tiền tối thiểu (7500 * storage_operations, execution_gas). Kết quả sẽ là, sau khi trừ đi khoản tiền hoàn lại, người dùng sẽ bị tính phí:
execution_gas + 10000storage_operations - min(7500lưu trữ thao tác, thực hiện gas)
Tương đương:
tối đa (execution_gas + 2500 hoạt động lưu trữ, 10000storage_operations)
Điều này phản ánh cấu trúc của EIP-7623. Một cách khác để thực hiện nó là theo dõi storage_operations và execution_gas trong thời gian thực, và thu phí là 2500 hoặc 10000 tùy thuộc vào việc max(execution_gas + 2500thao_tác_lưu_trữ, 10000Khi lệnh được gọi, lượng gas được sử dụng trong storage_operations) tăng lên. Điều này giúp tránh việc giao dịch phải cấp phát quá nhiều gas mà họ sẽ nhận lại chủ yếu thông qua hoàn trả.
Chúng tôi không nhận được quyền kiểm soát tinh xảo cho các cuộc gọi phụ: một cuộc gọi phụ có thể tiêu tốn toàn bộ "phần cấp 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 vẫn có điều gì đó đủ tốt, nơi mà một hợp đồng thực hiện cuộc gọi phụ có thể đặt một giới hạn và đảm bảo rằng sau khi cuộc gọi phụ kết thúc thực thi, cuộc gọi chính vẫn có đủ gas để thực hiện bất kỳ xử lý sau cần thiết nào.
Giải pháp giá cả đa chiều đầy đủ dễ nhất mà tôi nghĩ đến là: chúng ta xem xét giới hạn gas của cuộc gọi con là tỷ lệ thuận. Đó là, giả sử rằng có
𝑘
các loại thực thi khác nhau, và mỗi giao dịch đặt một giới hạn đa chiều
𝐿1…𝐿𝑘
. Giả sử rằng, tại điểm hiện tại trong quá trình thực hiện, khí gas còn lại là
𝑔1…𝑔𝑘
. Giả sử một mã lệnh GỌI được gọi, với giới hạn gas gọi con
𝑆
. Let
𝑠1=𝑆
và sau đó
𝑠2=𝑠1𝑔1∗gas2
,
s3=s1g1∗g3
, và cetera.
Nghĩa là, chúng tôi xem xử lý gas loại đầu tiên (hiện thực hóa VM) là một loại “đơn vị tính toán” đặc quyền nào đó, sau đó gán các loại gas khác sao cho cuộc gọi con nhận cùng phần trăm gas khả dụng trên mỗi loại. Điều này hơi xấu, nhưng nó tối đa hóa tính tương thích ngược. Nếu chúng ta muốn làm cho cơ chế trở nên “trung lập” hơn giữa các loại gas khác nhau, với chi phí hy sinh tính tương thích ngược, chúng ta có thể đơn giản làm cho tham số giới hạn gas cuộc gọi con đại diện cho một phần (ví dụ [1…63] / 64) của gas còn lại trong ngữ cảnh hiện tại).
Trong cả hai trường hợp, tuy nhiên, đáng lưu ý rằng khi bạn bắt đầu giới thiệu gas thực thi đa chiều, mức độ xấu xa cố hữu tăng lên và điều này dường như khó tránh khỏi. Do đó, nhiệm vụ của chúng tôi là thực hiện một sự cân nhắc phức tạp: liệu chúng ta có chấp nhận một chút xấu xí hơn ở mức EVM, để an toàn mở khóa những lợi ích đáng kể về khả năng mở rộng L1, và nếu có, đề xuất cụ thể nào hoạt động tốt nhất cho kinh tế giao thức và các nhà phát triển ứng dụng? Khá có khả năng, chúng không phải là những gì tôi đề cập ở trên, và vẫn còn chỗ để đưa ra một cái gì đó tinh tế và tốt hơn.
Disclaimer：- Bài viết này được sao chép từ [[Vitalik Buterin]], Tất cả bản quyền thuộc về tác giả gốc [Vitalik Buterin]. Nếu có ý kiến phản đối về việc tái in này, vui lòng liên hệ [Cổng Học](https://www.Gate.com/questionnaire/3967đội của họ và họ sẽ xử lý nhanh chóng.- Tất cả các quan điểm và ý kiến được thể hiện trong bài viết này đều là quan điểm cá nhân của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.- Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.
