Từ Glamsterdam đến Hegotá: Sau khi mở rộng quy mô, giai đoạn tiếp theo của Ethereum sẽ giải quyết vấn đề gì?

Từ việc Dencun giới thiệu Blob để giảm thuế đáng kể cho Rollup, đến Pectra điều chỉnh hiệu quả validator và cơ chế staking, rồi Fusaka triển khai PeerDAS để giảm gánh nặng phân phối dữ liệu, tầng giao thức gần như đã dồn toàn bộ tâm sức vào một việc: giúp Ethereum nuốt trọn nhiều dữ liệu hơn, đồng thời không nâng ngưỡng vận hành node lên quá cao.

Bộ combo này quả thực hiệu quả. Chi phí dữ liệu của Rollup đã giảm xuống, Gas Limit trên mainnet cũng đang tăng đều đặn. Ethereum không còn khiến người ta e ngại với mức phí hàng chục đô la mỗi giao dịch như chu kỳ tăng giá trước.

Nhưng con đường đã được mở rộng, việc lái xe vẫn còn nhiều bất tiện:

• Chúng ta vẫn phải di chuyển tài sản giữa ba hoặc bốn L2, lơ đãng một chút là gửi nhầm chain;
• Một giao dịch chuyển tiền rõ ràng đã được đóng gói trong vài giây, nhưng cầu nối và sàn giao dịch lại bắt bạn chờ đợi mười mấy phút mới dám xác nhận;
• Các Builder chuyên nghiệp gần như độc quyền việc đóng gói block, bạn muốn gửi một giao dịch nhạy cảm, bất cứ lúc nào cũng có thể bị từ chối bởi những quy tắc ngầm ngoài giao thức;
• Chưa kể đến tận hôm nay, một người dùng mới bước chân vào ngành nếu chỉ muốn chuyển vài trăm USDC, vẫn phải đi tìm hiểu tại sao ví phải có ETH, Nonce là gì, Gas là gì;

Bề ngoài, những vấn đề này đều thể hiện là sự ma sát trong trải nghiệm người dùng, nhưng đằng sau chúng lại liên quan đến các cơ chế giao thức nền tảng hơn như quy tắc xác nhận, xây dựng block, khả năng chống kiểm duyệt và mô hình tài khoản.

Và đây cũng chính là những vấn đề mới mà Ethereum bắt đầu tập trung xử lý, từ Glamsterdam đến Hegotá, từ Q4 2026 đến 2027.

1. Tiếp tục mở rộng quy mô, nhưng bắt đầu "khâu nối" L1 và L2

Tất nhiên, việc mở rộng quy mô sẽ không dừng lại.

Glamsterdam vẫn mang nặng định hướng hiệu năng. Trong đó, hai hạng mục đáng chú ý nhất là ePBS (EIP-7732) và BAL (Block-level Access Lists, EIP-7928). Hiểu một cách đơn giản:

• ePBS chính là việc đưa sự phân công Proposer và Builder vốn đã tồn tại rất nhiều bên ngoài giao thức vào giao thức một cách chính thức hơn, đồng thời phân chia khoảng thời gian sản xuất block và xác nhận một cách khoa học hơn, để dành đủ bộ đệm cho các block lớn hơn trong tương lai;
• BAL giống như việc để block liệt kê một "danh sách truy cập" ngay từ đầu, node chỉ cần liếc qua là có thể tìm nạp trước dữ liệu hoặc thậm chí xử lý song song, chuyên trị điểm nghẽn I/O lưu trữ;

Chỉ là, ngoài việc mở rộng quy mô, nỗi đau thực sự của hầu hết mọi người ngày hôm nay không phải là TPS của Ethereum có đủ cao hay không, mà là "có quá nhiều chain".

Ví dụ, ETH nằm trên mainnet, meme để chơi thì ở trên Robinhood Chain, USDC dùng để thanh toán có thể lại ở trên Arbitrum, còn USDC muốn bắt đáy thì ở trên Base...

Đối với Ethereum Foundation, các Rollup đều là một phần trong bản đồ của Ethereum, nhưng đối với người dùng, điều này chẳng khác gì chuyển đổi ngoại tệ qua biên giới hay xin visa.

Vì vậy, để khâu những mảnh ghép rời rạc lại thành một tấm lưới, ngoài việc các giao thức cầu nối cross-chain tự thể hiện, một cơ chế nền tảng mà tầng giao thức đang thúc đẩy gần đây rất đáng chú ý — FCR (Fast Confirmation Rule, Quy tắc xác nhận nhanh).

Nhiều người nghĩ rằng giao dịch được đóng gói vào block là đã thành công. Nhưng ở cấp độ mật mã học và đồng thuận, một block vừa mới được tạo ra hoàn toàn có thể gặp phải sự tổ chức lại nhỏ. Để đạt được "Finality" (tính cuối cùng) thực sự không thể đảo ngược, Ethereum cần phải hoàn thành hai Epoch, mất khoảng 13 phút.

Điều này bình thường không ảnh hưởng gì đến việc chuyển tiền, nhưng đối với cầu nối cross-chain, thanh toán quy mô lớn và các sàn giao dịch tập trung thì quả là cực hình. Để không phải chịu rủi ro tổ chức lại, chúng chỉ có thể bắt bạn chờ đợi.

Điểm khéo léo của FCR nằm ở chỗ, không cần phải ngây ngốc chờ đợi Finality hoàn chỉnh trong mười mấy phút, mà tận dụng Attestation vốn được tạo ra liên tục bởi các validator, dựa trên trọng số bỏ phiếu đã tích lũy để phán đoán sớm hơn liệu một block nào đó đã nhận được sự ủng hộ đồng thuận đủ mạnh hay chưa.

Theo mục tiêu Ethereum Foundation đưa ra, trong điều kiện mạng đồng bộ bình thường, FCR có khả năng rút ngắn "xác nhận mạnh" này xuống còn khoảng 15 đến 30 giây. Mặc dù không tương đương với Finality hoàn chỉnh, nhưng đối với nhiều cầu nối, giao tiếp cross-chain và hạ tầng hiện đang phải chờ đợi finality, điều này đã đủ để cung cấp một tín hiệu xác nhận sớm hơn và có mô hình bảo mật rõ ràng.

Đặc biệt hơn, FCR không cần phải chờ một lần hard fork nào đó mới có thể kích hoạt. Nó gần giống với một bộ quy tắc xác nhận có thể được các consensus client và hạ tầng áp dụng dần dần.

Một khi các loại L2, cầu nối cross-chain và ví bắt đầu sử dụng tín hiệu này, rất nhiều độ trễ cross-layer phát sinh do "chờ đợi L1 Finality" ngày hôm nay sẽ có cơ hội được nén từ mười mấy phút xuống còn vài chục giây.

Điều này cũng có nghĩa là, trong tương lai khi bạn điều động một tài sản, hệ thống hậu trường có thể âm thầm vượt qua hai hoặc nhiều chain, nhưng ở giao diện người dùng, chỉ cần nhấp một lần xác nhận, sau đó tiền sẽ đến rất nhanh.

2. Một bài toán cấp thấp hơn: Ai có quyền quyết định giao dịch có thể lên chuỗi hay không?

Tuy nhiên, khi block ngày càng lớn và Builder ngày càng chuyên nghiệp, Ethereum lại phải đối mặt với một tình thế lưỡng nan rất điển hình khác.

Vì các Builder chuyên nghiệp nhờ vào sức mạnh tính toán hàng đầu và dòng lệnh đã đưa hiệu quả xây dựng block lên đến cực hạn, thì quyền sinh sát của đại đa số các block tự nhiên cũng rơi vào tay một số ít các tổ chức lớn.

Điều này dẫn đến một mối nguy hiểm cực kỳ nghiêm trọng: Kiểm duyệt.

Nếu một số Builder vì áp lực tuân thủ, cạnh tranh thương mại, hoặc đơn giản chỉ vì không ưa một số giao thức bảo mật nào đó, cố tình giả điếc làm ngơ trong mempool, từ chối đóng gói giao dịch hợp pháp của bạn, thì dù bạn nắm chìa khóa riêng tư trong tay, Gas trả đủ, giao dịch của bạn vẫn có thể bị kẹt cứng bên ngoài chuỗi (đọc thêm bài viết "Đưa khả năng chống kiểm duyệt vào giao thức: Ai quyết định một giao dịch Ethereum có thể lên chuỗi?").

Nếu phi tập trung hóa mà ngay cả "quyền truy cập giao dịch chống kiểm duyệt" cơ bản nhất cũng không giữ được, thì throughput dù có cao đến đâu cũng chỉ là tòa lâu đài trên không.

Đây cũng là lý do tại sao trong kế hoạch Hegotá, FOCIL (Fork-choice Enforced Inclusion Lists, EIP-7805) lại được đặt ở vị trí quan trọng đến vậy.

Logic của nó cực kỳ đơn giản và trực tiếp, chính là đeo vòng kim cô lên đầu Builder.

Mỗi Slot, giao thức sẽ ngẫu nhiên chọn ra một nhóm các validator độc lập bình thường, bảo họ nhét tất cả các giao dịch hợp pháp đang chờ xử lý mà họ nhìn thấy trong mempool vào một "Danh sách bao gồm (Inclusion List)", Builder vẫn có thể tự do sắp xếp thứ tự giao dịch để kiếm MEV của mình, nhưng block bạn nộp ra phải ngoan ngoãn mang theo các giao dịch trong danh sách.

Nếu Builder dám cố tình phớt lờ danh sách này, các validator trên toàn mạng sẽ trực tiếp loại block đó ra khỏi quy tắc lựa chọn fork. Nói cách khác, bạn có thể kiếm tiền bằng tài năng của mình, nhưng bạn không thể thay mặt toàn mạng quyết định ai có tư cách sử dụng Ethereum.

Khi cơ chế này được thiết lập, nó kéo theo một mảnh ghép yếu khác của Ethereum mà người ta đã kêu gọi rất lâu nhưng vẫn không thể thúc đẩy, đó là quyền riêng tư mà mọi người đang mong đợi, cuối cùng cũng đã tìm được điểm hạ cánh.

Như chúng ta đã biết, trước đây khi nhắc đến quyền riêng tư, ai cũng nói về bằng chứng không tiết lộ (zero-knowledge proof), địa chỉ ẩn (stealth address), bể trộn coin (mixer), nhưng chỉ cần Builder nhận ra "đây là một lời gọi gửi đến hợp đồng riêng tư", rồi từ chối bạn, thì phép màu toán học của bạn lập tức tê liệt.

Còn hiện tại, trong lộ trình quyền riêng tư của Ethereum, thứ mà FOCIL bịt lại, chính xác là nơi dễ bị bóp nghẹt nhất. Dù sao đi nữa, chỉ cần tầng giao thức có thể bảo vệ đến cùng quyền truy cập của mọi giao dịch hợp pháp, thì việc khám phá quyền riêng tư ở tầng trên mới có đường sống.

Hiện tại, các đề xuất quyền riêng tư táo bạo hơn như EIP-8182 (cố gắng giới thiệu Shielded Pool nguyên bản ở cấp giao thức) vẫn đang trong giai đoạn thảo luận ứng cử viên (Proposed), nhưng xu hướng đã rất rõ ràng, đó là quyền riêng tư không thể tiếp tục bị coi là một tính năng ngoại vi của một DApp bên thứ ba nào đó, nó cần dần trở thành một tiện ích cơ bản như điện, nước ở tầng nền tảng của Ethereum.

3. Bước cuối cùng, AA nguyên bản và chiếc ví không còn phản nhân tính

Những điều chỉnh kiến trúc được nhắc đến ở trên diễn ra nhiều hơn dưới mặt nước, còn việc thứ ba sẽ liên quan mật thiết đến trải nghiệm sử dụng thực tế của người dùng thông thường.

Đó là việc Ethereum cuối cùng đã hạ quyết tâm phẫu thuật lớn cho mô hình tài khoản EOA đã tồn tại hơn mười năm.

Thành thật mà nói, mô hình ký bằng khóa riêng tư mà Ethereum vẫn sử dụng cho đến ngày nay, đối với một người dùng internet hơi bình thường một chút thì quả thực phản nhân tính đến cùng cực:

Mất khóa riêng tư là vạn kiếp bất phục; trong ví rõ ràng có hàng ngàn, hàng vạn stablecoin, nhưng chỉ vì thiếu 0.001 ETH để trả phí