“Vô cấp biến tốc” trong nâng cấp Fusaka của Ethereum: Xây dựng cơ chế phản ứng nhanh cho mở rộng L2

Ethereum trong tương lai sẽ giống như được trang bị một "hộp số vô cấp", việc mở rộng Blob sau này không cần phải gắn liền với các bản nâng cấp lớn nữa.

Tác giả: Zhixiong Pan

Bối cảnh: Nâng cấp Gas Limit không cần Hard Fork

Trước khi nâng cấp Fusaka, hầu hết các tham số cốt lõi của tầng giao thức Ethereum (như phần thưởng khối, thuật toán điều chỉnh độ khó, v.v.) đều được "mã hóa cứng" trong phần mềm client. Điều này có nghĩa là, ngay cả khi chỉ muốn sửa đổi một giá trị, cũng phải trải qua quá trình đề xuất EIP kéo dài, thử nghiệm trên testnet, và phối hợp toàn bộ các node trên mạng để thực hiện một đợt hard fork quy mô lớn, thường mất nửa năm hoặc lâu hơn.

Trước đó, ngoại lệ duy nhất trong giao thức Ethereum là Block Gas Limit (giới hạn Gas của khối). Gas Limit không được quyết định bởi hard fork, mà cho phép các validator điều chỉnh nhẹ thông qua thuật toán khi đóng gói khối (ví dụ năm nay tăng từ 30M lên 60M). Cơ chế này mang lại cho mạng lưới một mức độ linh hoạt nhất định.

Sự xuất hiện của EIP-7892, BPO (Blob Parameter Only), chính là để mở rộng sự linh hoạt này sang lĩnh vực dữ liệu. Nó biến các tham số quan trọng của Blob thành cấu hình động, và thông qua BPO - một dạng hard fork nhẹ "chỉ đổi tham số, không đổi mã nguồn" để có hiệu lực. Từ góc độ phát triển client, gần như giống như thực hiện một lần cập nhật nóng tham số.

Điều này giúp Ethereum trong vấn đề mở rộng, thoát khỏi nhịp điệu "mỗi lần muốn điều chỉnh số lượng Blob đều phải đợi đợt hard fork lớn tiếp theo", mà có thể điều chỉnh tham số thường xuyên hơn thông qua các đợt fork nhỏ BPO.

Tại sao số lượng Blob lại quan trọng?

Đối tượng điều chỉnh cốt lõi lần này là Blob. Kể từ sau nâng cấp Cancun (Dencun), phần lớn các Rollup không còn ghi phần lớn dữ liệu giao dịch vào calldata đắt đỏ nữa, mà chuyển sang Blob - một "khu vực gắn dữ liệu tạm thời" chuyên biệt.

Logic kinh tế của Blob rất đơn giản: Blob là tài nguyên khan hiếm, số lượng Blob có thể gắn vào mỗi khối là hữu hạn. Giá của nó phụ thuộc vào cung cầu, khi nhu cầu của Layer 2 vượt quá nguồn cung, giá đơn vị Blob sẽ tăng, dẫn đến phí giao dịch L2 tăng cao.

Vì vậy, trong điều kiện đảm bảo an toàn, tăng tối đa giới hạn số lượng Blob là cách trực tiếp nhất để giảm chi phí cho người dùng L2.

Tham số cốt lõi: Cơ chế Target và Max

Trong kế hoạch điều chỉnh BPO, có thể thấy hai con số xuất hiện theo cặp (ví dụ 10/15). Đây là hai ngưỡng quan trọng được thiết lập dựa trên cơ chế EIP-4844:

Target (Giá trị mục tiêu): "Bộ điều chỉnh" phí

Đây là mức tải lý tưởng do Ethereum đặt ra. Hệ thống sẽ điều chỉnh động phí cơ bản (Base Fee) của Blob dựa trên giá trị này. Nếu lượng sử dụng thực tế > Target, phí tăng để kiềm chế nhu cầu; nếu lượng sử dụng thực tế < Target, phí giảm.

Nó quyết định khả năng thông lượng và mức phí chuẩn của mạng trong trạng thái bình thường.

Max (Giá trị tối đa): "Cầu chì" an toàn

Đây là giới hạn cứng vật lý được đặt ra để ngăn mạng lưới bị tê liệt. Dù nhu cầu cao đến đâu, giao thức bắt buộc số lượng Blob trong mỗi khối không được vượt quá giá trị này, nhằm tránh các node bị quá tải dữ liệu dẫn đến sập hoặc mất kết nối.

Nó là trần giới hạn khả năng chịu tải của mạng.

Thêm vào đó, kể từ sau Pectra, các tham số blob trên mainnet cơ bản tuân theo mô hình "Max = 1.5 × Target": 6/9, 10/15, 14/21 đều theo tỷ lệ này.

Lộ trình nâng cấp: Tại sao Fusaka chọn "đi từng bước"?

Lần mở rộng này không thực hiện ngay vào ngày 3 tháng 12 (UTC+8), mà áp dụng chiến lược ba giai đoạn nghiêm ngặt "triển khai kỹ thuật trước, giải phóng dung lượng sau":

Giai đoạn 1: Kích hoạt nâng cấp Fusaka (3 tháng 12 (UTC+8))

Trạng thái tham số: Target: 6 / Max: 9 (giữ nguyên như phiên bản Pectra trước đó, không thay đổi).

Nâng cấp Fusaka kích hoạt công nghệ cốt lõi PeerDAS (lấy mẫu khả dụng dữ liệu). Dù về mặt kỹ thuật đã có thể xử lý nhiều dữ liệu hơn, nhưng để đảm bảo an toàn, các nhà phát triển chọn không tăng tải mạng trong ngày đầu nâng cấp. Đây là "giai đoạn quan sát an toàn", dùng để kiểm chứng sự ổn định của cơ chế PeerDAS dưới lưu lượng hiện tại.

Giai đoạn 2: BPO 1 (dự kiến 9 tháng 12 (UTC+8))

Điều chỉnh tham số: Target: 10 / Max: 15

Sau khoảng một tuần PeerDAS vận hành ổn định, sẽ tiến hành cập nhật nóng lần đầu thông qua cơ chế BPO. Giá trị mục tiêu tăng từ 6 lên 10. Đây là lần mở rộng thực chất đầu tiên trong chu kỳ Fusaka.

Giai đoạn 3: BPO 2 (dự kiến 7 tháng 1 năm 2026 (UTC+8))

Điều chỉnh tham số: Target: 14 / Max: 21

Sau một tháng kiểm tra áp lực đầy đủ, sẽ tiến hành cập nhật nóng lần thứ hai. So với thời điểm Fusaka ra mắt, dung lượng đã tăng 2.3 lần (6 → 14). Điều này đánh dấu việc hoàn thành kế hoạch mở rộng lần này.

Tổng kết

Việc đưa vào BPO là một cột mốc quan trọng. Nó phá vỡ mô hình cũ "mỗi lần mở rộng Blob đều phải đợi một đợt hard fork lớn", biến việc mở rộng thành một chuỗi các hard fork mini chỉ thay đổi tham số.

Điều này có nghĩa là, Ethereum trong tương lai sẽ giống như được trang bị một "hộp số vô cấp", việc mở rộng Blob sau này không cần phải gắn liền với các bản nâng cấp lớn nữa, mà có thể lên kế hoạch cho BPO3, BPO4 theo nhu cầu của L2 và hiệu năng client, điều chỉnh thông lượng bằng các hard fork nhỏ, dày đặc hơn, thay vì phải chờ nhiều năm mới thay đổi một lần.