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 đề "Hyper-scaling state by creating new forms of state".
Trong bài viết này, Vitalik Buterin tiếp tục làm rõ con đường mở rộng của Ethereum. Bài viết không chỉ thảo luận về việc mở rộng Ethereum từ góc độ kỹ thuật, mà còn cung cấp một giải pháp mở rộng theo từng giai đoạn từ góc độ kiến trúc tổng thể, nhằm tạo nền tảng cho việc mở rộng dung lượng mạng Ethereum trong những năm tới.
Đồng thời, anh ấy cũng đã đăng một bài tweet trên X để giải thích thêm về bài viết này. Chúng ta hãy cùng tìm hiểu một cách dễ hiểu: Giải pháp mở rộng mới mà Vitalik đề xuất lần này là gì, và tại sao anh ấy lại làm như vậy?
Short-term and long-term expansion of computational and data resources
Vitalik chỉ ra ở phần mở đầu của bài viết dài rằng: “Để mở rộng Ethereum trong năm năm tới, cần mở rộng ba tài nguyên”:
- Tài nguyên thực thi: Tính toán EVM, xác minh chữ ký, v.v.
- Tài nguyên dữ liệu: Người gửi, người nhận, chữ ký của giao dịch, v.v.
- Tài nguyên trạng thái: Số dư tài khoản, mã, lưu trữ
Hai cái trước có cá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, trong ngắn hạn sẽ đạt tăng trưởng khoảng 10-30 lần thông qua danh sách truy cập khối (BAL), ePBS và định giá lại phí gas; trong dài hạn sẽ đạt tăng trưởng khoảng 1000 lần thông qua ZK-EVM, và đối với một số loại tính toán cụ thể (chữ ký, SNARK/STARK), việc tổng hợp ngoài chuỗi có thể tăng hiệu năng lên khoảng 10.000 lần.
Đối với tài nguyên dữ liệu, trong ngắn hạn sẽ đạt mức tăng trưởng khoảng 10-20 lần thông qua cải tiến P2P và Gas đa chiều, trong dài hạn sẽ đạt mức tăng trưởng khoảng 500 lần thông qua Blobs + PeerDAS.
Việc mở rộng ngắn hạn tập trung vào việc giúp Ethereum chạy nhanh hơn. Hiện tại, Ethereum chạy chậm vì cách xác minh hiện tại là tuần tự—xác minh giao dịch từng cái 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ệ.
Vì vậy, trong đợt nâng cấp Glamsterdam năm nay, chúng tôi sẽ triển khai Danh sách truy cập khối (BAL) và ePBS.
Danh sách truy cập khối cho phép người đóng khối thông báo trước cho người 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, người xác thực có thể chuẩn bị sẵn bằng cách tải các dữ liệu này từ ổ cứng vào bộ nhớ. Sau đó, người xác thực có thể kiểm tra đồng thời nhiều giao dịch thay vì kiểm tra từng giao dịch một. Giống như dây chuyền sản xuất trong nhà máy: trước đây một công nhân phụ trách toàn bộ sản phẩm, bây giờ nhiều công nhân cùng xử lý các phần khác nhau.
ePBS tách riêng quá 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 minh chịu trách nhiệm xác minh khối. Mỗi vai trò đều làm tốt phần việc của mình, nhờ đó người xây dựng khối có thể đóng gói nhiều giao dịch hơn một cách chủ động, vì người đề xuất và người xác minh sẽ giúp kiểm tra, không cần lo lắng về vấn đề bảo mật.
Việc định giá lại phí gas + phí gas đa chiều có thể được xem là “kỹ năng cốt lõi”. Hiện tại, tất cả các thao tác trên Ethereum đều sử dụng cùng một loại phí gas. Nhưng ý tưởng của Vitalik là các thao tác khác nhau nên có mức giá khác nhau.
Đặc biệt, việc tạo trạng thái mới (ví dụ: tạo tài khoản mới, triển khai hợp đồng mới) nên có một khoản phí tạo trạng thái đặc biệt. Vì tạo trạng thái mới là thao tác tốn chi phí nhất. Nó không chỉ tiêu tốn tài nguyên tính toán mà còn tiêu tốn 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, trạng thái này sẽ tồn tại mãi mãi.
Vì vậy, ý tưởng của Vitalik là làm cho việc tạo trạng thái mới trở nên đắt hơn, nhưng làm cho các giao dịch thông thường trở nên rẻ hơn.
Phương pháp thực hiện là "cơ chế hồ chứa". Hãy tưởng tượng có hai thùng, một thùng chứa "phí tạo trạng thái" và một thùng khác chứa "phí Gas thông thường". Khi các hợp đồng gọi lẫn nhau, Gas sẽ tự động vay từ cả hai thùng này, đảm bảo không xảy ra tình trạng lộn xộn.
Giao dịch của người dùng thông thường sẽ trở nên rẻ hơn vì những giao dịch này không phải trả phí tạo trạng thái. Trong khi đó, 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. Nhờ đó, dung lượng tổng thể của mạng tăng mạnh, nhưng sự gia tăng trạng thái được kiểm soát, tránh khiến ổ cứng của các nút đầy đủ bị quá tải.
Việc mở rộng dài hạn là giúp chính mạng chính trở nên mạnh mẽ hơn, giảm sự phụ thuộc vào Layer 2. Điều này bao gồm việc triển khai từng giai đoạn Blobs + PeerDAS và ZK-EVM.
Blobs, một kho lưu trữ tệp lớn tạm thời, hiện chủ yếu được sử dụng cho Layer 2. Trong tương lai, chính mạng chính của Ethereum cũng sẽ sử dụng Blobs để lưu trữ dữ liệu. Nhưng vấn đề cũng phát sinh—nếu mỗi nút đều phải tải xuống tất cả các Blobs, mạng lưới sẽ bị quá tải.
Lúc này, PeerDAS sẽ phát huy tác dụng—bạn không cần tải xuống toàn bộ dữ liệu, mà chỉ cần tải xuống một phần nhỏ. Giống như khảo sát mẫu, bạn không cần hỏi tất cả mọi người, mà chỉ cần hỏi một nhóm nhỏ để suy ra tình hình của toàn bộ tập thể. Kết hợp với chứng minh ZK, ngay cả khi bạn chỉ tải xuống 1/16 tổng dữ liệu, bạn vẫn có thể xác minh tính toàn vẹn của dữ liệu.
Tiếp theo là việc triển khai từng giai đoạn ZK-EVM, giúp việc xác minh một khối không còn cần phải thực thi lại tất cả các giao dịch trong khối, mà các nút chỉ cần tin tưởng vào bằng chứng ZK, từ đó 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 một bằng chứng ZK”.
Kế hoạch của Vitalik là vào năm 2026, một số nút sẽ thử nghiệm xác minh ZK. Đến năm 2027, sẽ khuyến khích nhiều nút hơn sử dụng. Cuối cùng, để một khối hợp lệ, nó phải chứa 3 trong số 5 loại chứng minh từ các hệ thống chứng minh khác nhau. Ông dự kiến, tất cả các nút (trừ các nút chỉ mục) cuối cùng sẽ phụ thuộc vào chứng minh ZK-EVM.
Không có trạng thái mở rộng như “thần dược”
Bây giờ hãy cùng xem xét “tài nguyên trạng thái” mà chưa được đề cập đến trong mở rộng ngắn hạn và dài hạn. Mặc dù trong ngắn hạn, vẫn có thể cải thiện khoảng 5-30 lần thông qua các cách như đồng bộ hóa danh sách truy cập khối, cải tiến p2p và tối ưu hóa cơ sở dữ liệu, thì trong 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? 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 thông minh và dữ liệu tại tất cả các vị trí lưu trữ.
Hiện tại cơ sở dữ liệu này chưa lớn, chỉ khoảng 100 GB, nhưng nếu mở rộng trạng thái lên 20 lần, sẽ thành 2 TB. Vậy nếu lâu hơn nữa 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ơ 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 (ví dụ: cây Merkle) để tổ chức dữ liệu. Khi ghi một dữ liệu mới, toàn bộ cây cần được cập nhật. Điều này có nghĩa là, nếu bạn thực hiện X lần cập nhật, thì ở cấp độ cơ sở dữ liệu cũng sẽ có X lần thao tác, chứ không phải chỉ một lần cập nhật là xong một thao tác cơ sở dữ liệu. Càng cập nhật nhiều, càng nhiều thao tác, việc ghi dữ liệu sẽ chậm lại đáng kể.
Khó đồng bộ: Một nút mới gia nhập mạng Ethereum cần tải toàn bộ trạng thái để xác minh các khối mới. Nếu kích thước dữ liệu lên tới 8 TB, tốc độ mạng hiện tại của hầu hết mọi người sẽ phải tải trong thời gian rất dài.
Có giải pháp, nhưng Vitalik cho rằng tất cả đều có vấn đề:
- “Strong statelessness”: Các nút không cần lưu trữ trạng thái đầy đủ, chỉ cần người dùng cung cấp bằng chứng Merkle. Vitalik cho rằng giải pháp này gặp vấn đề về tập trung hóa lưu trữ trạng thái, lỗi giao dịch do truy cập trạng thái động và chi phí băng thông.
- "Trạng thái hết hạn": Các trạng thái không được truy cập thường xuyên 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 mới nhất được truy cập, giúp giảm đáng kể không gian lưu trữ. Vitalik cho rằng tồn tại một "vấn đề cốt lõi" cơ bản: khi tạo một trạng thái mới, làm thế nào để chứng minh rằng trạng thái đó "chưa từng tồn tại". Giả sử tạo một tài khoản mới, cần chứng minh rằng địa chỉ tài khoản mới chưa từng được tạo ra trên Ethereum. Điều này có nghĩa là việc tạo mỗi tài khoản mới đều cần 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 giải pháp này, đề xuất một số dạng trạng thái mới, đây là sự thay đổi toàn diện đối với kiến trúc tài nguyên trạng thái của Ethereum:
- Lưu trữ tạm thời: Một loại lưu trữ tự động hết hạn. Ví dụ: có thể tạo một cây mới, tự động xóa sạch mỗi tháng. Loại lưu trữ này có thể dùng cho dữ liệu tạm thời như danh sách đặt hàng, hồ sơ thanh khoản, bộ đếm tạm thời—những dữ liệu thường không cần lưu trữ vĩnh viễn; sau một tháng, các lệnh cũ sẽ hết hạn và hồ sơ thanh khoản mới được tạo ra.
- Lưu trữ định kỳ: Tương tự như lưu trữ tạm thời, nhưng với chu kỳ dài hơn, ví dụ 1 năm.
- Bộ nhớ bị hạn chế: Một số bộ nhớ chỉ có thể được truy cập theo cách cụ thể. Ví dụ: bộ nhớ lưu số dư của một token ERC20 có thể chỉ có thể 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 bộ nhớ này.
Đồng thời, giữ nguyên trạng thái hiện tại. Như vậy, việc thực thi có thể rẻ hơn 1000 lần (qua ZK-EVM), nhưng việc tạo trạng thái mới có thể chỉ rẻ hơn 20 lần.
Vitalik cho rằng, với hình thức trạng thái mới, các nhà phát triển có sự lựa chọn: tiếp tục sử dụng hình thức trạng thái hiện tại nhưng trả phí cao hơn, hoặc thiết kế lại ứng dụng để sử dụng hình thức trạng thái mới, từ đó giảm chi phí. Đối với các trường hợp sử dụng phổ biến (như số dư ERC20, NFT), sẽ có các quy trình chuẩn hóa, trong khi đối với các trường hợp phức tạp hơn (như DeFi), các nhà phát triển cần tự tìm cách tối ưu.
Chiến lược này khá thú vị, mang chút hương vị của các nhà phát triển vận dụng trí óc để giảm chi phí, giúp người dùng Ethereum rộng rãi được hưởng lợi.