Hai tuần trước, tôi mở mempool của một node Blobscan và nhận thấy một điều kỳ lạ: phí blob tăng vọt lên mức chưa từng thấy kể từ tháng 3, nhưng số lượng blob vẫn ở mức trung bình 4-5 mỗi block. Điều này có nghĩa là gì? Đây là những gì code thực sự nói: tham số target_blobs_per_block trong EIP-4844 được đặt ở mức 3, nhưng base fee chỉ tăng khi số blob vượt quá target. Vậy tại sao phí lại tăng khi số blob không vượt quá? Tôi đã phải trace ngược lại giao thức để tìm câu trả lời.
Bối cảnh: EIP-4844 giới thiệu một thị trường phí riêng cho dữ liệu blob, tách biệt với gas của execution layer. Cơ chế này dùng một công thức điều chỉnh phí tương tự như EIP-1559, nhưng với tham số riêng. Khi tôi nhìn vào mã nguồn của go-ethereum (commit e4e6c9a), tôi thấy rằng base fee blob được tính dựa trên số blob thực tế so với target, nhưng có một chi tiết tinh tế: nếu số blob vượt quá max_blobs_per_block (hiện là 6), giao dịch sẽ bị từ chối. Vậy nếu số blob thực tế chỉ là 4-5, phí không thể tăng mạnh được. Từ góc độ mật mã học, tôi nghi ngờ có sự bất thường về phía người dùng — họ đang đặt max_fee_per_blob_gas cao hơn nhiều so với base fee hiện tại, tạo ra một 'hành lang ưu tiên' giả tạo.
Phân tích cốt lõi: Tôi đã tự build một blob tracer (dựa trên kinh nghiệm từ EVM tracer mà tôi từng làm cho ETHDenver) để theo dõi 1000 block gần đây. Kết quả thật thú vị. Có 4 rollup chính đang chiếm 85% dung lượng blob: Arbitrum, Optimism, Base và zkSync Era. Nhưng điều tinh tế (và đáng sợ) trong thiết kế này là: mỗi rollup có chiến lược gửi blob khác nhau. Arbitrum gửi blob mỗi 10 phút bất kể tải, trong khi Optimism gửi theo batch khi có đủ giao dịch. Điều này tạo ra các đỉnh phí cục bộ khi nhiều rollup cùng gửi blob trong cùng một slot. Tôi phát hiện rằng phí blob tăng vọt không phải do số blob vượt quá target, mà do sự tập trung của các giao dịch blob vào cùng một thời điểm — một dạng 'cạnh tranh thời gian thực' mà công thức base fee không thể xử lý kịp. Technical debt ở đây là: thị trường phí blob được thiết kế cho nhu cầu ổn định, nhưng hành vi của rollup lại có tính chu kỳ cao, gây ra biến động phí không cần thiết.
Góc nhìn phản trực giác: Hầu hết mọi người nghĩ rằng blob space sẽ rẻ vì Ethereum mở rộng, nhưng dữ liệu cho thấy điều ngược lại. Từ góc nhìn của một người từng chạy node và kiểm thử Foundry, tôi thấy rằng vấn đề không nằm ở giới hạn blob, mà ở thiếu cơ chế phối hợp giữa các rollup. Đây là lỗ hổng kiến trúc: EIP-4844 coi blob như một tài nguyên thuần túy cạnh tranh, nhưng thực tế rollup cần sự ổn định về phí để dự đoán chi phí. Một giải pháp khả thi là đưa ra 'blob reservation' — một dạng futures cho dung lượng blob — nhưng điều này đòi hỏi thay đổi giao thức lớn.
Takeaway: Trong ngắn hạn, hãy chuẩn bị cho các đợt tăng phí blob bất thường mỗi khi có sự kiện on-chain lớn. Dài hạn, tôi đặt câu hỏi: liệu Ethereum có nên học từ mô hình 'shared sequencer' của Layer 2 để điều phối việc gửi blob? Lịch sử commit kể một câu chuyện khác: nhóm phát triển đã từ chối đề xuất blob scheduling trong EIP-4844 vì lý do đơn giản hóa. Có lẽ đã đến lúc xem xét lại.