Vào ngày 27 tháng 2 năm 2026, Vitalik Buterin đã đăng một bài viết dài trên Ethereum Research với tiêu đề "Siêu mở rộng rộng trạng thái bằng cách tạo ra các dạng trạng thái mới".
Trong bài viết này, Vitalik Buterin tiếp tục phác thảo lộ trình mở rộng của Ethereum . Bài viết này không chỉ đơn thuần là thảo luận kỹ thuật về mở rộng Ethereum ; nó cung cấp một giải pháp mở rộng mô theo từng giai đoạn từ góc độ kiến trúc tổng thể, nhằm đặt nền tảng cho việc tiếp tục mở rộng dung lượng mạng lưới Ethereum trong những năm tới.
Anh ấy cũng đăng một tweet trên X, giải thích thêm về bài báo. Chúng ta sẽ cố gắng hiểu một cách đơn giản giải pháp mở rộng lần mà Vitalik đề xuất là gì và tại sao anh ấy lại làm theo cách này.
Mở rộng ngắn hạn và dài hạn các nguồn lực thực thi và nguồn lực dữ liệu.
Ngay từ đầu bài đăng dài của mình, Vitalik đã chỉ ra rằng "để mở rộng Ethereum trong năm năm tới, cần phải mở rộng quy mô ba nguồn lực":
- Tài nguyên thực thi: Tính toán EVM, xác minh chữ ký, v.v.
- Nguồn dữ liệu: Người gửi giao dịch, người nhận, chữ ký, v.v.
- Tài nguyên của tiểu bang: số dư tài khoản, mã, dung lượng lưu trữ
Hai công ty đầu tiên có kế hoạch mở rộng ngắn hạn và dài hạn.
Đối với tài nguyên thực thi, tăng trưởng ngắn hạn khoảng 10-30 lần có thể đạt được thông qua Danh sách truy cập khối (BAL), ePBS và định giá lại phí Gas , trong khi tăng trưởng dài hạn khoảng 1000 lần có thể đạt được thông qua ZK-EVM. Hơn nữa, đối với một số loại tính toán nhất định (chữ ký, SNARK/STARK), việc tổng hợp Chuỗi chuỗi có thể cải thiện hiệu suất lên khoảng 10.000 lần.
Đối với tài nguyên dữ liệu , trong ngắn hạn, chúng ta có thể đạt được tăng trưởng khoảng 10-20 lần thông qua cải tiến p2p và gas đa chiều, và trong dài hạn, chúng ta có thể đạt được tăng trưởng khoảng 500 lần thông qua Blobs + PeerDAS.
Mục tiêu mở rộng ngắn hạn là tập trung vào việc làm cho Ethereum hoạt động nhanh hơn. Hiện tại, Ethereum hoạt động chậm vì phương pháp xác minh của nó là tuần tự—kiểm tra từng giao dịch một. Nếu một giao dịch bị kẹt, toàn bộ quá trình xác minh sẽ bị đình trệ.
Do đó, nâng cấp Glamsterdam sắp tới trong năm nay sẽ giới thiệu Danh sách truy cập theo khối (BAL) và ePBS.
Danh sách truy cập khối cho phép người đóng gói khối thông báo trước cho các trình xác thực: "Các giao dịch trong khối này sẽ truy cập vào các tài khoản và vị trí lưu trữ này." Với thông tin này, các trình xác thực có thể chuẩn bị trước bằng cách tải dữ liệu từ ổ cứng vào bộ nhớ. Sau đó, các trình xác thực có thể kiểm tra nhiều giao dịch song song, thay vì từng giao dịch một. Nó giống như một dây chuyền lắp ráp trong nhà máy: trước đây một công nhân chịu trách nhiệm cho toàn bộ sản phẩm, giờ đây nhiều công nhân xử lý các bộ phận khác nhau cùng một lúc.
ePBS tách biệt quy trình đóng gói và xác minh khối — người xây dựng khối chịu trách nhiệm đóng gói giao dịch, người đề xuất chịu trách nhiệm đề xuất khối, và người xác thực chịu trách nhiệm xác minh khối. Mỗi nhân vật thực hiện tốt nhiệm vụ cụ thể của mình, cho phép người xây dựng khối đóng gói nhiều giao dịch hơn một cách hiệu quả hơn, vì người đề xuất và người xác thực sẽ kiểm tra chúng, loại bỏ những lo ngại về bảo mật.
Việc điều chỉnh lại phí gas , kết hợp với định giá gas đa chiều, có thể được coi là "chiến lược cốt lõi". Hiện tại, tất cả các hoạt động Ethereum đều sử dụng cùng một mức phí gas . Tuy nhiên, ý tưởng của Vitalik là các hoạt động khác nhau nên có mức giá khác nhau.
Cụ thể, việc tạo ra các trạng thái mới (chẳng hạn như tạo tài khoản mới hoặc triển khai hợp đồng mới) cần phải chịu một khoản phí "tạo trạng thái" đặc biệt. Điều này là do việc tạo ra một trạng thái mới là thao tác tốn kém nhất. Nó không chỉ tiêu tốn tài nguyên tính toán mà còn cả tài nguyên lưu trữ. Hơn nữa, chi phí này là vĩnh viễn—một khi đã được tạo ra, trạng thái đó sẽ tồn tại mãi mãi.
Do đó, ý tưởng của Vitalik là làm cho việc tạo ra các quốc gia mới trở nên tốn kém hơn, nhưng lại làm cho các giao dịch thông thường trở nên rẻ hơn.
Phương pháp được sử dụng để đạt được điều này là "cơ chế dự trữ". Hãy tưởng tượng hai thùng, một thùng chứa "phí tạo trạng thái" và thùng kia chứa "phí gas thông thường". Khi các hợp đồng gọi nhau, gas sẽ tự động được mượn từ cả hai thùng, đảm bảo không xảy ra tình trạng hỗn loạn.
Giao dịch dành cho người dùng thông thường sẽ trở nên rẻ hơn vì họ sẽ không phải chịu "phí tạo trạng thái". Các nhà phát triển muốn tạo trạng thái mới sẽ phải trả phí cao hơn. Điều này dẫn đến sự gia tăng dung lượng mạng tổng thể, nhưng tăng trưởng trạng thái vẫn được kiểm soát, ngăn chặn tình trạng quá tải ổ cứng của nút đầy.
Mục tiêu mở rộng dài hạn là củng cố mainnet chính (mainnet) và giảm sự phụ thuộc vào Layer 2. Điều này bao gồm triển khai theo từng giai đoạn bằng cách sử dụng Blobs + PeerDAS và ZK-EVM.
Blobs, một phương pháp lưu trữ tạm thời cho các tệp lớn, hiện chủ yếu được sử dụng bởi Layer 2. Trong tương lai, mạng chủ Ethereum cũng sẽ sử dụng Blobs để lưu trữ dữ liệu. Tuy nhiên, điều này đặt ra một vấn đề—nếu mỗi nút phải tải xuống tất cả các Blobs, mạng sẽ bị quá tải.
Đây là lúc PeerDAS phát huy tác dụng — nó không yêu cầu tải xuống toàn bộ dữ liệu, mà chỉ cần một phần nhỏ. Giống như một cuộc khảo sát lấy mẫu, bạn không cần hỏi tất cả mọi người; bạn chỉ cần hỏi một nhóm nhỏ để suy đoán tình hình của toàn bộ dân số. Kết hợp với bằng chứng ZK, ngay cả khi bạn chỉ tải xuống 1/16 tổng số dữ liệu, bạn vẫn có thể xác nhận tính toàn vẹn dữ liệu.
Tiếp theo là quá trình triển khai theo từng giai đoạn của ZK-EVM, giúp việc xác minh một khối không còn yêu cầu thực thi lại tất cả các giao dịch trong khối đó nữa. Nút chỉ cần tin tưởng vào bằng chứng ZK, giảm chi phí xác minh từ "thực thi tất cả các giao dịch" xuống còn "xác minh bằng chứng ZK".
Kế hoạch của Vitalik là một số nút sẽ thử nghiệm xác minh ZK vào năm 2026. Đến năm 2027, nhiều nút hơn sẽ được khuyến khích sử dụng nó. Cuối cùng, để một khối hợp lệ, nó phải chứa ba trong năm loại bằng chứng từ các hệ thống bằng chứng khác nhau. Ông dự đoán rằng tất cả nút(ngoại trừ nút chỉ mục) cuối cùng sẽ dựa vào bằng chứng ZK-EVM.
Mở rộng phạm vi hoạt động của nhà nước mà không cần "phương thuốc thần kỳ"
Giờ chúng ta hãy xem xét "tài nguyên trạng thái", vốn chưa được thảo luận trong các phần về mở rộng quy mô ngắn hạn và dài hạn. Trong ngắn hạn, mặc dù vẫn có thể đạt được sự cải thiện khoảng 5-30 lần thông qua việc đồng bộ hóa với danh sách truy cập khối, cải tiến P2P và tối ưu hóa cơ sở dữ liệu, nhưng còn về dài hạn thì sao?
Câu trả lời của Vitalik là không.
Tại sao tài nguyên trạng thái lại khó mở rộng vậy? Trạng thái của Ethereum giống như một cơ sở dữ liệu khổng lồ. Cơ sở dữ liệu này lưu trữ số dư của tất cả các tài khoản, mã của tất cả các hợp đồng và dữ liệu từ tất cả các vị trí lưu trữ.
Hiện tại, cơ sở dữ liệu còn nhỏ, chỉ khoảng 100 GB, nhưng nếu mở rộng 20 lần, nó sẽ lên tới 2 TB. Còn trong thời gian dài hơn thì sao? 8 TB?
Vấn đề không phải là ổ cứng không đủ dung lượng, mà là:
- Hiệu suất của cơ sở dữ liệu bị ảnh hưởng: Các cơ sở dữ liệu hiện đại sử dụng cấu trúc cây (như cây Merkle) để tổ chức dữ liệu. Khi dữ liệu mới được ghi vào, toàn bộ cây cần được cập nhật. Điều này có nghĩa là nếu bạn cần thực hiện X lần, sẽ có LẦN thao tác ở cấp độ cơ sở dữ liệu, thay vì chỉ một bản cập nhật và một thao tác cơ sở dữ liệu. Càng nhiều bản cập nhật, càng nhiều thao tác, và tốc độ ghi sẽ trở nên cực kỳ chậm.
- Khó khăn trong việc đồng bộ hóa: Một nút mới tham gia mạng Ethereum cần tải xuống toàn bộ trạng thái trước khi có thể xác minh một khối mới. Nếu dung lượng dữ liệu đạt đến 8 TB, hầu hết mọi người sẽ mất rất nhiều thời gian để tải xuống với tốc độ mạng hiện tại của họ.
Có những giải pháp, nhưng Vitalik cho rằng tất cả chúng đều có vấn đề:
- "Tính không trạng thái mạnh": Nút không cần lưu trữ toàn bộ trạng thái; chúng chỉ cần người dùng cung cấp bằng chứng Merkle. Vitalik cho rằng rằng phương án này gặp phải các vấn đề như lưu trữ trạng thái tập trung, lỗi giao dịch do truy cập lưu trữ động và chi phí băng thông.
- "Hết hạn trạng thái": Các trạng thái ít được truy cập sẽ tự động bị xóa khỏi danh sách trạng thái hoạt động. Nút chỉ cần lưu trữ các trạng thái được truy cập gần đây, giúp giảm đáng kể không gian lưu trữ. Vitalik cho rằng có một "vấn đề tồn tại" cơ bản: làm thế nào để chứng minh rằng một trạng thái "chưa từng tồn tại" khi tạo một trạng thái mới. Ví dụ, việc tạo một tài khoản mới yêu cầu chứng minh rằng địa chỉ tài khoản mới chưa từng được tạo trên Ethereum . Điều này có nghĩa là việc tạo mỗi tài khoản mới sẽ yêu cầu kiểm tra dữ liệu lịch sử trong 10 năm, khiến việc tạo tài khoản trở nên phức tạp và tốn kém.
Phương pháp cuối cùng của Vitalik là kết hợp hai cách tiếp cận này và đề xuất một số hình thức trạng thái mới, đại diện cho một sự thay đổi hoàn toàn đối với kiến trúc tài nguyên trạng thái Ethereum:
- Lưu trữ tạm thời: Một loại lưu trữ tự động hết hạn. Ví dụ, một cây mới có thể được tạo và tự động đặt lại về 0 mỗi tháng. Loại lưu trữ này có thể được sử dụng cho dữ liệu tạm thời, chẳng hạn như sổ lệnh, nhóm thanh khoản và bộ đếm tạm thời. Dữ liệu này thường không cần được lưu trữ vĩnh viễn. Sau một tháng, các lệnh cũ hết hạn và một nhóm thanh khoản mới được tạo.
- Lưu trữ định kỳ: Tương tự như lưu trữ tạm thời, nhưng với thời gian dài hơn, chẳng hạn như 1 năm.
- Lưu trữ hạn chế: Một số loại lưu trữ chỉ có thể được truy cập theo cách cụ thể. Ví dụ, số dư lưu trữ của token ERC20 chỉ có thể được truy cập thông qua một giao diện cụ thể. Điều này cho phép hệ thống tối ưu hóa loại lưu trữ đó.
Đồng thời, dạng trạng thái hiện tại được bảo toàn. Bằng cách này, việc thực thi có thể tiết kiệm hơn 1000 lần (thông qua ZK-EVM), nhưng việc tạo ra trạng thái mới có thể chỉ tiết kiệm hơn 20 lần.
Vitalik cho rằng rằng với các định dạng trạng thái mới, các nhà phát triển có nhiều lựa chọn. Họ có thể tiếp tục sử dụng định dạng trạng thái hiện có nhưng phải trả phí cao hơn, hoặc thiết kế lại ứng dụng của mình để sử dụng định dạng trạng thái mới và nhận được phí thấp hơn. Đối với các trường hợp sử dụng phổ biến (như số dư ERC20 và NFT), sẽ có các quy trình làm việc được tiêu chuẩn hóa, trong khi đối với các trường hợp sử dụng phức tạp hơn (như DeFi), các nhà phát triển cần tìm ra cách riêng để tối ưu hóa.
Chiến lược này khá thú vị, và dường như nó cho thấy các nhà phát triển có thể sử dụng sự khéo léo của mình để giảm chi phí, trong khi người dùng Ethereum được hưởng lợi từ điều đó.
