Tác giả: @Web3Mario
Mở đầu: Vào ngày 13 tháng 5 năm 2024, Vitalik đã công bố đề xuất EIP-7706, đưa ra một phương án bổ sung cho mô hình Gas hiện tại bằng cách tách riêng cơ chế tính phí gas dành cho calldata và thiết lập cơ chế định giá base fee tương tự như Blob gas, nhằm giảm thêm chi phí vận hành cho L2. Đề xuất liên quan này cần được truy ngược về EIP-4844 được đưa ra vào tháng 2 năm 2022, do khoảng thời gian khá dài giữa hai sự kiện nên việc tổng hợp lại các tài liệu liên quan sẽ giúp người đọc nhanh chóng nắm bắt được bức tranh tổng thể mới nhất về cơ chế Gas của Ethereum.
Các mô hình Gas hiện đã được hỗ trợ —— EIP-1559 và EIP-4844
Trong thiết kế ban đầu, Ethereum sử dụng cơ chế đấu giá đơn giản để định giá phí giao dịch, theo đó người dùng phải chủ động đặt giá cho giao dịch của mình, tức là thiết lập gas price. Thông thường, vì phí giao dịch người dùng trả sẽ thuộc về thợ đào, nên thợ đào sẽ quyết định thứ tự đóng gói giao dịch dựa trên nguyên tắc tối ưu kinh tế – ai trả cao hơn thì được xử lý trước (bỏ qua MEV). Tuy nhiên, theo quan điểm của các nhà phát triển cốt lõi lúc bấy giờ, cơ chế này gặp phải bốn vấn đề chính sau:
l Sự không phù hợp giữa mức độ biến động phí giao dịch và chi phí đồng thuận thực tế: Với các blockchain đang hoạt động mạnh mẽ, nhu cầu đóng gói giao dịch luôn dồi dào, điều này khiến khối dễ dàng bị lấp đầy, nhưng cũng dẫn đến biến động phí rất lớn. Ví dụ, khi mức Gas Price trung bình là 10 Gwei, chi phí biên mà mạng phải chịu khi chấp nhận thêm một giao dịch trong khối sẽ gấp 10 lần so với khi mức trung bình chỉ là 1 Gwei – điều này là không thể chấp nhận được.
l Gây trì hoãn không cần thiết cho người dùng: Do mỗi khối đều có giới hạn cứng về gaslimit, cộng với sự dao động tự nhiên của lượng giao dịch trong quá khứ, nhiều giao dịch thường phải chờ vài khối mới được xử lý, gây kém hiệu quả cho toàn bộ mạng lưới; tức là không tồn tại cơ chế “đàn hồi” nào cho phép một khối mở rộng hơn và khối tiếp theo nhỏ lại để đáp ứng sự chênh lệch nhu cầu từng khối.
l Hiệu quả định giá thấp: Việc áp dụng cơ chế đấu giá đơn giản dẫn đến khả năng phát hiện giá công bằng kém, khiến người dùng khó xác định mức giá hợp lý, dẫn đến tình trạng rất thường xuyên phải trả phí cao hơn mức cần thiết.
l Blockchain không có phần thưởng khối sẽ bất ổn: Khi loại bỏ phần thưởng khối từ khai thác và chuyển sang mô hình chỉ dựa vào phí giao dịch, có thể dẫn đến nhiều bất ổn, ví dụ như khuyến khích khai thác các "khối chị em" nhằm chiếm đoạt phí giao dịch, hoặc làm gia tăng nguy cơ tấn công khai thác ích kỷ.
Cho đến khi EIP-1559 được đề xuất và triển khai, mô hình Gas mới có bước cải tiến đầu tiên. EIP-1559 do Vitalik và các nhà phát triển cốt lõi khác đề xuất vào ngày 13 tháng 4 năm 2019 và được áp dụng trong đợt nâng cấp London vào ngày 5 tháng 8 năm 2021. Cơ chế này loại bỏ hoàn toàn mô hình đấu giá, thay vào đó sử dụng mô hình định giá kép gồm Base fee và Priority fee. Trong đó, Base fee được tính toán định lượng theo một mô hình toán học cố định, dựa trên mối quan hệ giữa lượng gas đã tiêu thụ trong khối cha và một mục tiêu gas linh hoạt, có thể điều chỉnh đệ quy. Hiệu ứng trực quan là nếu lượng gas sử dụng trong khối trước vượt quá mục tiêu gas đã định, thì base fee sẽ tăng; nếu chưa đạt mục tiêu thì base fee sẽ giảm. Cách làm này vừa phản ánh tốt hơn mối quan hệ cung - cầu, vừa giúp dự đoán mức gas hợp lý trở nên chính xác hơn, tránh tình trạng người dùng do thao tác sai mà phải trả phí Gas Price "trên trời". Bởi vì base fee được hệ thống quyết định hoàn toàn chứ không do người dùng tự đặt. Mã cụ thể như sau:
Có thể thấy rằng khi parent_gas_used lớn hơn parent_gas_target, base fee của khối hiện tại sẽ tăng thêm một giá trị lệch so với base fee của khối trước, giá trị lệch này bằng parent_base_fee nhân với tỷ lệ chênh lệch giữa tổng lượng gas sử dụng và mục tiêu gas, lấy modulo với thương số giữa gas target và một hằng số, rồi lấy max so với 1. Trường hợp ngược lại logic tương tự.
Ngoài ra, Base fee không còn được phân phối cho thợ đào mà bị đốt cháy hoàn toàn, giúp mô hình kinh tế của ETH hướng tới trạng thái lạm phát âm, góp phần ổn định giá trị. Trong khi đó, Priority fee giống như khoản tiền boa của người dùng cho thợ đào, có thể định giá tự do, điều này giúp tái sử dụng một phần thuật toán sắp xếp của thợ đào.
Khi thời gian trôi đến năm 2021, Rollup bắt đầu phát triển mạnh mẽ. Chúng ta biết rằng dù là OP Rollup hay ZK Rollup, đều yêu cầu nén dữ liệu L2 và gửi lên chuỗi dưới dạng dữ liệu chứng minh thông qua calldata để đảm bảo tính sẵn sàng dữ liệu (Data Availability) hoặc kiểm chứng trực tiếp trên chuỗi. Điều này khiến các giải pháp Rollup phải chịu chi phí Gas lớn khi duy trì tính cuối cùng (finality) cho L2, và chi phí này cuối cùng sẽ được chuyển sang người dùng. Vì vậy, chi phí sử dụng của hầu hết các giao thức L2 lúc bấy giờ không hề thấp như kỳ vọng.
Đồng thời, Ethereum cũng đối mặt với tình trạng cạnh tranh không gian khối. Mỗi khối có giới hạn Gas nhất định, nghĩa là tổng lượng gas tiêu thụ của tất cả giao dịch trong khối không được vượt quá giới hạn này. Với mức Gas Limit hiện tại là 30.000.000, về lý thuyết sẽ có giới hạn 30.000.000 / 16 = 1.875.000 byte, trong đó con số 16 biểu thị lượng gas tiêu thụ bởi EVM cho mỗi byte calldata. Như vậy, kích thước dữ liệu tối đa một khối có thể chứa khoảng 1,79 MB. Dữ liệu Rollup do trình sắp xếp (sequencer) L2 tạo ra thường có dung lượng lớn, dẫn đến cạnh tranh với các giao dịch của người dùng trên chuỗi chính, làm giảm số lượng giao dịch có thể đóng gói trong một khối, ảnh hưởng đến TPS của chuỗi chính.
Để giải quyết vấn đề này, các nhà phát triển cốt lõi đã đề xuất EIP-4844 vào ngày 5 tháng 2 năm 2022, và được triển khai sau nâng cấp Dencun vào quý II năm 2024. Đề xuất này giới thiệu một loại giao dịch mới, gọi là Blob Transaction. Khác với giao dịch truyền thống, Blob Transaction bổ sung một kiểu dữ liệu mới: Blob data. Không giống calldata, blob data không thể được EVM truy cập trực tiếp, mà chỉ có thể truy cập hash của nó, còn gọi là VersionedHash. Ngoài ra còn có hai thiết kế đi kèm: thứ nhất, chu kỳ GC (garbage collection) của blob transaction ngắn hơn so với giao dịch thông thường, nhằm đảm bảo dữ liệu khối không phình to quá mức; thứ hai, blob data có cơ chế Gas riêng biệt, về tổng thể hiệu ứng tương tự EIP-1559, nhưng trong mô hình toán học sử dụng hàm mũ tự nhiên, giúp ổn định hơn khi đối phó với biến động quy mô giao dịch. Bởi vì đạo hàm của hàm mũ tự nhiên cũng là chính nó, nghĩa là dù mạng đang ở trạng thái nào, khi quy mô giao dịch tăng vọt, base fee của blob gas sẽ phản ứng mạnh mẽ hơn, từ đó kiềm chế hiệu quả mức độ hoạt động. Một đặc tính quan trọng khác là khi hoành độ bằng 0, giá trị hàm bằng 1.
base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)
Trong đó MIN_BASE_FEE_PER_BLOB_GAS và BLOB_BASE_FEE_UPDATE_FRACTION là hai hằng số, excess_blob_gas được xác định bởi chênh lệch giữa tổng lượng blob gas tiêu thụ trong khối cha và hằng số TARGET_BLOB_GAS_PER_BLOCK. Khi tổng blob gas vượt mục tiêu (chênh lệch dương), e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) > 1, dẫn đến base_fee_per_blob_gas tăng; ngược lại thì giảm.
Như vậy, các trường hợp chỉ cần tận dụng khả năng đồng thuận của Ethereum để lưu trữ chứng cứ cho dữ liệu lớn nhằm đảm bảo tính sẵn sàng có thể thực hiện với chi phí thấp, đồng thời không chiếm dụng năng lực đóng gói giao dịch của khối. Ví dụ với sequencer của Rollup, có thể dùng blob transaction để đóng gói thông tin quan trọng của L2 vào blob data, rồi thông qua thiết kế tinh vi trong EVM, sử dụng versionedHash để thực hiện logic kiểm chứng trên chuỗi.
Cần补充 rằng hiện tại việc thiết lập TARGET_BLOB_GAS_PER_BLOCK và MAX_BLOB_GAS_PER_BLOCK tạo ra một giới hạn cho mainnet, tức là trung bình mỗi khối xử lý mục tiêu 3 blob (0,375 MB) và tối đa 6 blob (0,75 MB). Những giới hạn ban đầu này nhằm giảm thiểu áp lực mà EIP này gây ra cho mạng lưới, và dự kiến sẽ được tăng lên trong các bản nâng cấp tương lai khi mạng lưới chứng minh được độ tin cậy dưới khối lớn hơn.
Tinh chỉnh sâu hơn mô hình tiêu thụ Gas cho môi trường thực thi —— EIP-7706
Sau khi làm rõ mô hình Gas hiện tại của Ethereum, chúng ta hãy xem mục tiêu và chi tiết triển khai của đề xuất EIP-7706. Đề xuất này do Vitalik đưa ra vào ngày 13 tháng 5 năm 2024. Tương tự như Blob data, đề xuất này tách riêng mô hình Gas cho một trường dữ liệu đặc biệt khác – đó là calldata – đồng thời tối ưu hóa logic mã thực hiện tương ứng.
Về nguyên lý, logic tính toán base fee của calldata giống với base fee for blob data trong EIP-4844, đều sử dụng hàm mũ và tính toán hệ số co giãn base fee hiện tại dựa trên độ lệch giữa lượng gas tiêu thụ thực tế và mục tiêu trong khối cha.
Lưu ý rằng có một tham số mới được thiết kế: LIMIT_TARGET_RATIOS=[2,2,4], trong đó LIMIT_TARGET_RATIOS[0] biểu thị tỷ lệ mục tiêu cho loại Gas thao tác thực thi, LIMIT_TARGET_RATIOS[1] biểu thị tỷ lệ mục tiêu cho loại Gas blob data, LIMIT_TARGET_RATIOS[2] biểu thị tỷ lệ mục tiêu cho loại Gas calldata. Vector này dùng để tính toán giá trị gas target tương ứng cho ba loại gas trong khối cha, theo công thức sau: lần lượt chia gas limit cho các phần tử trong LIMIT_TARGET_RATIOS:
Logic thiết lập gas_limits như sau:
gas_limits[0] phải tuân theo công thức điều chỉnh hiện tại
gas_limits[1] phải bằng MAX_BLOB_GAS_PER_BLOCK
gas_limits[2] phải bằng gas_limits[0] // CALLDATA_GAS_LIMIT_RATIO
Biết rằng hiện tại gas_limits[0] là 30.000.000, CALLDATA_GAS_LIMIT_RATIO được đặt trước là 4, điều này có nghĩa là calldata gas target hiện tại khoảng 30.000.000 // 4 // 4 = 1.875.000. Vì theo logic tính toán gas calldata hiện tại, mỗi byte không bằng không tiêu thụ 16 Gas, mỗi byte bằng không tiêu thụ 4 Gas, giả sử trong một đoạn calldata có 50% byte không bằng không và 50% byte bằng không, thì trung bình xử lý 1 byte calldata cần 10 Gas. Do đó, calldata gas target hiện tại tương ứng với khoảng 187.500 byte dữ liệu calldata, tương đương khoảng 2 lần mức sử dụng trung bình hiện tại.
Lợi ích của cách làm này là giảm đáng kể xác suất xảy ra tình trạng calldata chạm giới hạn gas, thông qua mô hình kinh tế giữ mức sử dụng calldata ở trạng thái ổn định, đồng thời ngăn chặn việc lạm dụng calldata. Mục đích thiết kế này vẫn là để dọn đường cho sự phát triển của L2, kết hợp với blob data để tiếp tục giảm chi phí cho sequencer.
@web3_mario
