Trước khi nâng cấp Fusaka, hầu hết các tham số cốt lõi của lớp giao thức Ethereum(như phần thưởng khối và thuật toán điều chỉnh độ khó) đều được "mã hóa cứng" vào phần mềm máy trạm.
Tác giả: Zhixiong Pan, ChainFeeds Research
Bối cảnh : Nâng cấp Gas Limit không yêu cầu hard fork.
Trước khi nâng cấp Fusaka, hầu hết các tham số cốt lõi của lớp giao thức Ethereum(như phần thưởng khối và thuật toán điều chỉnh độ khó) đều được "mã hóa cứng" trong phần mềm máy trạm. Điều này có nghĩa là ngay cả khi bạn chỉ muốn sửa đổi một giá trị duy nhất, bạn cũng phải trải qua một Đề án EIP kéo dài, các cuộc diễn tập mạng thử nghiệm và phối hợp một hard fork quy mô lớn trên toàn nút , thường mất sáu tháng hoặc thậm chí lâu hơn.
Trước đây, ngoại lệ duy nhất trong giao thức Ethereum là giới hạn Gas khối. Giới hạn Gas không được xác định bởi hard fork , mà cho phép các trình xác thực thực hiện các điều chỉnh nhỏ bằng thuật toán khi đóng gói khối (ví dụ : tăng từ 30 triệu lên 60 triệu trong năm nay). Cơ chế này mang lại cho mạng lưới một mức độ linh hoạt nhất định.
EIP-7892, hay Blob Parameter Only, được phát triển để mở rộng tính linh hoạt này cho miền dữ liệu. Nó làm cho các tham số chính của blob được cấu hình theo cách thông qua một hard fork của Blobs cho phép thay đổi tham số mà không cần sửa đổi mã. Từ góc độ phát triển máy trạm, nó gần giống như thực hiện cập nhật tham số nóng.
Điều này đã giải phóng Ethereum khỏi vòng luẩn quẩn "phải chờ đợi đợt hard fork lớn tiếp lần muốn điều chỉnh số lượng Blob" về vấn đề mở rộng quy mô, cho phép điều chỉnh tham số thường xuyên hơn thông qua fork nhỏ hơn.
Tại sao số lượng các đốm lại quan trọng?
Mục tiêu chính của sự điều chỉnh lần là Blob. Kể từ nâng cấp Cancun, hầu hết các Rollup không còn ghi phần lớn dữ liệu giao dịch của chúng vào calldata tốn kém nữa, mà thay vào đó chuyển sang Blob, một "điểm gắn kết dữ liệu tạm thời" chuyên dụng.
Nguyên lý kinh tế của blob rất đơn giản: blob là một nguồn tài nguyên khan hiếm, và số lượng blob có thể gắn vào mỗi khối là có hạn. Giá của nó được xác định bởi cung và cầu; khi nhu cầu về Layer 2 vượt quá nguồn cung, giá đơn vị của một blob sẽ tăng lên, dẫn đến phí giao dịch L2 cao hơn.
Do đó, trên cơ sở đảm bảo an ninh, việc tăng giới hạn trên của số lượng blob lên mức tối đa là cách trực tiếp nhất để giảm chi phí cho người dùng L2.
Các thông số cốt lõi: Cơ chế của Target và Max
Trong kế hoạch điều chỉnh BPO, có thể quan sát thấy hai cặp số (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:
Mục tiêu (hoặc giá trị mục tiêu): "Yếu tố điều chỉnh" chi phí.
Đây là hệ số tải lý tưởng do Ethereum thiết lập. Hệ thống tự động điều chỉnh phí cơ bản của Blob dựa trên giá trị này. Nếu mức sử dụng thực tế > Mục tiêu, phí tăng để hạn chế nhu cầu; nếu mức sử dụng thực tế < Mục tiêu, phí giảm.
Nó xác định thông lượng và tốc độ chuẩn của mạng trong điều kiện bình thường.
Max (giá trị tối đa): Một "cầu chì" an toàn.
Đây là giới hạn vật lý cứng được thiết lập để ngăn chặn tình trạng tê liệt mạng. Bất kể nhu cầu cao đến mức nào, giao thức quy định rằng số lượng blob chứa trong một khối duy nhất không được vượt quá giá trị này để ngăn nút bị sập hoặc ngoại tuyến do xử lý quá nhiều dữ liệu.
Nó thể hiện giới hạn tối đa về khả năng tải của mạng lưới.
Ngoài ra, kể từ Pectra, các tham số blob của mainnet về cơ bản tuân theo mô hình "Max = 1.5 × Target": 6/9, 10/15, 14/21, tất cả đều theo tỷ lệ này.
Lộ trình nâng cấp: Tại sao Fusaka lại chọn cách tiếp cận "từng bước"?
Việc mở rộng lần này không được hoàn thành cùng một lúc vào ngày 3 tháng 12, mà được thực hiện theo chiến lược ba giai đoạn nghiêm ngặt: "triển khai công nghệ trước, sau đó mới giải phóng năng lực":
Giai đoạn 1: Nâng cấp Fusaka hoàn tất (ngày 3 tháng 12)
Trạng thái tham số: Mục tiêu: 6 / Tối đa: 9 (tương tự như các phiên bản Pectra trước đó, không có thay đổi).
Bản nâng cấp Fusaka đã kích hoạt PeerDAS (Dữ liệu Availability Sampling), một công nghệ cốt lõi. Mặc dù về mặt kỹ thuật có khả năng xử lý nhiều dữ liệu hơn, nhưng vì lý do bảo mật, các nhà phát triển đã chọn không tăng tải mạng trong ngày đầu tiên nâng cấp. Đây là "giai đoạn quan sát an ninh" để xác minh tính ổn định của cơ chế PeerDAS trong điều kiện lưu lượng hiện tại.
Giai đoạn Hai: BPO 1 (Dự kiến ngày 9 tháng 12)
Điều chỉnh thông số: Mục tiêu: 10 / Tối đa: 15
Sau khi PeerDAS hoạt động ổn định được khoảng một tuần, bản cập nhật nóng đầu tiên đã được thực hiện thông qua cơ chế BPO. Giá trị mục tiêu đã được tăng từ 6 lên 10. Đây là lần mở rộng đáng kể lần trong chu kỳ Fusaka.
Giai đoạn 3: BPO 2 (dự kiến ngày 7 tháng 1 năm 2026)
Điều chỉnh thông số: Mục tiêu: 14 / Tối đa: 21
Sau một tháng thử nghiệm khả năng chịu tải kỹ lưỡng, bản cập nhật nóng lần đã được thực hiện. So với thời điểm Fusaka ra mắt, dung lượng đã tăng gấp 2,3 lần (6 → 14). Điều này đánh dấu việc hoàn thành toàn bộ kế hoạch mở rộng lần.
Tóm tắt
Việc giới thiệu BPO là một cột mốc quan trọng. Nó đã phá vỡ mô hình cũ "lần một Blob được mở rộng, đều cần một hard fork quy mô lớn", và chia nhỏ quá trình mở rộng thành sê-ri hard fork nhỏ chỉ thay đổi các tham số.
Điều này có nghĩa là trong tương lai, Ethereum sẽ giống như một hộp số biến đổi liên tục (CVT). Việc mở rộng Blob sẽ không còn bị ràng buộc chặt chẽ với các phiên bản chính nữa. Thay vào đó, nó có thể lên kế hoạch cho BPO3 và BPO4 định kỳ dựa trên nhu cầu L2 và hiệu suất máy trạm, sử dụng hard fork nhỏ thường xuyên hơn để tối ưu hóa thông lượng, thay vì chỉ thay đổi nó vài năm một lần.
Tuyên bố miễn trừ trách nhiệm: Là blockchain, các bài viết được đăng tải trên trang web này chỉ thể hiện quan điểm cá nhân của tác giả và khách mời và không phản ánh lập trường của Web3Caff. Thông tin trong các bài viết chỉ mang tham khảo và không cấu thành bất kỳ lời khuyên hoặc đề nghị đầu tư nào. Vui lòng tuân thủ các luật và quy định hiện hành của quốc gia hoặc khu vực của bạn.
Chào mừng bạn đến với cộng đồng chính thức của Web3Caff : Tài khoản Twitter | Tài khoản Twitter nghiên cứu của Web3Caff | Nhóm độc giả WeChat | Tài khoản chính thức WeChat
