Nâng cấp Fusaka dự kiến sẽ được triển khai trên Ethereum mainnet vào ngày 03/12 nhằm mở rộng khả năng xử lý của mạng lưới, duy trì tính phi tập trung và bảo mật.
Ethereum ấn định thời điểm hardfork Fusaka, chuẩn bị cho nâng cấp lớn nhất năm 2025
Các nhà phát triển Ethereum đang gấp rút bước vào giai đoạn chuẩn bị cho nâng cấp quan trọng tiếp theo mang tên Fusaka, dự kiến triển khai trên mainnet ngày 03/12/2025.
Đây sẽ là bản cập nhật trọng yếu tiếp theo cho Ethereum – kể từ sau The Merge, Dencun và gần nhất là Pectra – tập trung vào mở rộng khả năng xử lý dữ liệu, giảm chi phí, và cải thiện trải nghiệm người dùng, đồng thời đặt nền móng cho lộ trình Danksharding trong tương lai.
– Bản nâng cấp Fusaka của Ethereum không chỉ đơn giản là một đợt hard fork lớn, mà còn được thiết kế với một lộ trình nhiều giai đoạn để đảm bảo tính an toàn, khả năng tương thích và sự chuẩn bị tốt nhất cho toàn bộ hệ sinh thái.
– Theo thông tin từ nhà nghiên cứu Christine D. Kim, lịch trình nâng cấp Fusaka được triển khai cụ thể như sau:
Bản nâng cấp Fusaka được đánh giá là một trong những cột mốc quan trọng nhất của Ethereum kể từ sau Dencun và Pectra. Tại thời điểm viết bài, đã có tới 12 EIP đã được chốt để triển khai, tập trung vào ba trụ cột chính: mở rộng quy mô mạng lưới, tối ưu chi phí và nâng cao trải nghiệm người dùng.
EIP-7594 – Peer Data Availability Sampling (PeerDAS)
– PeerDAS (Peer Data Availability Sampling) là được coi cải tiến cốt lõi trong nâng cấp Fusaka. Cơ chế này thay đổi cách các node xử lý dữ liệu, nếu trước đây mỗi node Ethereum phải tải và lưu trữ toàn bộ dữ liệu blob, thì nay PeerDAS cho phép các node chỉ cần lưu một phần nhỏ data và phối hợp với các node khác để kiểm chứng tính xác thực.
– Ví dụ, khi một node cần chắc chắn rằng toàn bộ blob tồn tại, node này có thể yêu cầu ngẫu nhiên nhiều node khác cung cấp mẫu dữ liệu. Nếu các mẫu đều khớp, có thể chắc chắn rằng blob đầy đủ và không bị giả mạo.
– Nhờ vậy, hệ thống vẫn đảm bảo tính toàn vẹn và khả dụng của toàn bộ dữ liệu mà không làm tăng gánh nặng tài nguyên, từ đó giảm mạnh chi phí giao dịch trên layer-2 như Arbitrum, Optimism hay zkSync, vốn phụ thuộc vào blob để lưu trữ dữ liệu off-chain.
– PeerDAS còn mở đường cho Ethereum có thể xử lý tới 128 blob/block trong tương lai, nâng thông lượng lên mức cạnh tranh với những blockchain khác mà vẫn giữ vững tính phi tập trung.
EIP-7825 – Transaction Gas Limit Cap
– Trong bản nâng cấp Fusaka, EIP-7825 quyết định đặt mức trần gas cho mỗi giao dịch ở 16,777,216 gas (2^24). Mục tiêu là tránh tình trạng một giao dịch quá “nặng” chiếm gần hết dung lượng của cả block, từ đó đảm bảo sự công bằng trong việc sử dụng blockspace và giữ cho mạng lưới vận hành ổn định hơn.
– Đối với người dùng phổ thông, hầu như sẽ không cảm nhận được sự thay đổi, bởi phần lớn giao dịch hiện tại đều tiêu tốn lượng gas thấp hơn rất nhiều so với ngưỡng 16,8M. Tuy nhiên, với những nhà phát triển ứng dụng triển khai hợp đồng thông minh phức tạp, có khả năng họ sẽ cần phải chia nhỏ các thao tác thành nhiều giao dịch để phù hợp với giới hạn mới.
– Về phía Layer 2, EIP-7825 có thể tác động đến cơ chế gộp giao dịch (batching) nhưng đổi lại, nó mang đến sự ổn định và bền vững hơn cho toàn bộ hệ thống.
– Còn với validator và node operator, bản nâng cấp này đem lại lợi thế rõ rệt, các block sẽ trở nên dễ xử lý hơn, giảm nguy cơ tắc nghẽn cục bộ khi gặp phải những giao dịch có dung lượng quá lớn.
EIP-7918 – Blob base fee bounded by execution cost
– Một trong những vấn đề của Ethereum sau nâng cấp Dencun là thị trường phí blob đôi khi hoạt động không hiệu quả. Cụ thể, khi chi phí thực thi trên layer-2 cao hơn nhiều so với chi phí blob, mức phí blob có thể tụt xuống mức tối thiểu chỉ 1 wei. Điều này khiến giá phí blob không còn phản ánh đúng giá trị thật của tài nguyên mạng lưới.
– Để giải quyết, EIP-7918 đưa ra cơ chế giá sàn (reserve price) cho blob, gắn trực tiếp với chi phí thực thi. Nhờ đó, phí blob luôn duy trì ở mức hợp lý, dù thị trường có biến động thế nào, phí blob cũng không thể tụt xuống mức quá thấp, phản ánh đúng cung – cầu thực tế.
– EIP-7918 không chỉ giải quyết vấn đề ngắn hạn mà còn đặt nền móng cho sự phát triển của các hệ sinh thái layer-2 trên Ethereum. Khi nhu cầu sử dụng blob tăng mạnh, cơ chế giá sàn này sẽ giúp thị trường duy trì khám phá giá (price discovery) một cách hiệu quả, đảm bảo rằng Ethereum có thể mở rộng mà không gặp rủi ro trong cơ chế phí.
EIP-7935 – Set default gas limit to XX0M
– EIP-7935 đề xuất nâng giới hạn gas (gas limit) mặc định của Ethereum từ 36 triệu lên một mức cao hơn (hiện vẫn đang được thảo luận). Về nguyên tắc, thay đổi này không cần hard fork vì gas limit vốn do validator quyết định. Tuy nhiên, để đảm bảo tính ổn định của mạng lưới trước khối lượng tính toán lớn hơn, EIP được đưa vào nâng cấp Fusaka nhằm ưu tiên thử nghiệm và triển khai.
– Việc nâng giới hạn gas sẽ giúp tăng trực tiếp thông lượng của Ethereum, cho phép xử lý nhiều giao dịch hơn trong mỗi block. Ngoài ra, gas limit cao hơn còn mở đường cho những hợp đồng thông minh phức tạp hơn, phục vụ các ứng dụng DeFi, AI và những mô hình dApp yêu cầu nhiều tài nguyên tính toán.
– Nhờ việc nâng gas limit, người dùng sẽ được hưởng lợi rõ rệt với tốc độ giao dịch nhanh hơn và chi phí ổn định hơn. Nhà phát triển ứng dụng có thêm không gian để triển khai những hợp đồng thông minh phức tạp mà không lo chạm trần gas limit.
– Đặc biệt, Layer 2 sẽ có thêm blockspace để xử lý dữ liệu. Tuy nhiên, điều này cần phối hợp chặt chẽ với EIP-7825 (giới hạn gas cho từng giao dịch) để tránh rủi ro xung đột.
– Dù mang lại nhiều lợi ích, EIP-7935 cũng đi kèm thách thức kỹ thuật. Ở cấp độ client, cả consensus layer và execution layer sẽ phải thử nghiệm, tinh chỉnh liên tục để bảo đảm các block lớn có thể truyền tải nhanh qua mạng lưới gossip mà không gây chậm trễ hay fork tạm thời.
– Bên cạnh đó, validator và node operator sẽ chịu áp lực lớn hơn vì block nặng hơn đồng nghĩa với việc cần phần cứng mạnh mẽ hơn và khả năng xử lý cao hơn.
– Sau khi triển khai thành công và hoạt động ổn định trên mainnet, nâng cấp Fukasa sẽ bước sang giai đoạn tiếp theo với những bản hard fork nhỏ được gọi là BPO fork, tập trung điều chỉnh dung lượng blob .
– Theo lộ trình dài hạn, sẽ có tổng cộng 5 đợt BPO fork để tăng dung lượng blob. Mục tiêu là đáp ứng nhu cầu ngày càng tăng của các layer-2 mà vẫn duy trì sự ổn định mạng lưới.
– Điểm đáng chú ý là các đợt BPO (Blob Parameter Only) chỉ thay đổi tham số blob target và blob limit, hoàn toàn không yêu cầu cập nhật client.
– Trong giai đoạn đầu, Fusaka sẽ chưa tác động đến dung lượng blob. Tuy nhiên, khi các đợt BPO fork lần lượt được triển khai, dung lượng blob sẽ được điều chỉnh tăng dần theo từng giai đoạn, thay vì thay đổi đột ngột.
– Nhà nghiên cứu Ethereum Christine D. Kim cho biết: Theo một số phân tích sơ bộ trên Fusaka Devnet-5, dung lượng blob dự kiến sẽ tăng hơn gấp đôi chỉ trong vòng hai tuần sau khi bản nâng cấp Fusaka được triển khai.”
– Cộng đồng phát triển ethPandaOps cho biết: “Kết luận ban đầu là chúng ta có thể nâng số blob tối đa lên 15 ở BPO1 và 21 ở BPO2. Tổng cộng sẽ có 5 đợt BPO Fork trong Fusaka, nhờ đó mainnet có thể mở rộng quy mô một cách an toàn.”
– Blob đóng vai trò quan trọng trong việc lưu trữ dữ liệu lớn ngoài chuỗi (off-chain), giúp các mạng layer-2 hoạt động hiệu quả hơn và giảm chi phí giao dịch. Kể từ khi bản nâng cấp Dencun được triển khai, mức sử dụng blob đã tăng đều đặn: trung bình hiện nay đạt 5,1 blob mỗi block, cao hơn rất nhiều so với chỉ 0,9 blob mỗi block vào tháng 3/2023, theo dữ liệu từ Dune.
Trung bình số blob sử dụng mỗi block kể từ Dencun. Nguồn: Dune – @hildobby (Ngày 19/09/2025)
– Chính vì thế, các BPO fork được triển khai ngay sau Fusaka vừa để đáp ứng nhu cầu mở rộng từ các layer-2 trong tương lai, vừa đảm bảo tính ổn định cho toàn bộ mạng lưới Ethereum.
– Sau khi hoàn tất nâng cấp Fusaka, Ethereum sẽ hướng tới bản nâng cấp Glamsterdam vào năm 2026. Điểm nhấn quan trọng nhất là EOF (EVM Object Format), cải tiến lớn cho Máy ảo Ethereum (EVM).
– EOF mang đến định dạng bytecode mới, rõ ràng và có cấu trúc hơn. Thay vì kiểu bytecode cũ vốn lộn xộn và khó kiểm soát, EOF tách biệt code và data. Nhờ đó, smart contract có thể được kiểm tra tính hợp lệ ngay khi triển khai hợp đồng, thay vì phải kiểm tra lặp đi lặp lại trong quá trình chạy.
– Cơ chế này giúp tiết kiệm gas, tăng tính bảo mật, đồng thời hỗ trợ tốt hơn cho các công nghệ tiên tiến như zero-knowledge proofs.
Coin68 tổng hợp