Back to top
  • 공유 Chia sẻ
  • 인쇄 In
  • 글자크기 Cỡ chữ
URL đã được sao chép

Vitalik Buterin đề xuất đại tu Ethereum(ETH): EIP-7864, cây trạng thái mới và lộ trình VM RISC-V tối ưu cho ZK

Vitalik Buterin đề xuất đại tu Ethereum(ETH): EIP-7864, cây trạng thái mới và lộ trình VM RISC-V tối ưu cho ZK / Tokenpost

Theo CoinDesk đưa tin ngày 2 (giờ địa phương), nhà đồng sáng lập Ethereum(Ethereum(ETH)) *Vitalik Buterin* đã đề xuất một lộ trình thay đổi sâu cấu trúc *từ* lớp thực thi (execution layer) *từ* của Ethereum(ETH). Trọng tâm là thiết kế lại cây trạng thái (State Tree) và máy ảo (VM), nhằm gỡ bỏ các điểm nghẽn lớn nhất trong môi trường *từ* chứng minh không kiến thức (zero-knowledge, ZK) mở rộng *từ* và mô hình chứng minh phía khách hàng (client-side proving).

Theo bài viết dài mà Buterin đăng trên X ngày 1 (giờ địa phương), trạng thái cây (state tree) và máy ảo EVM hiện tại đang chiếm “hơn 80%” giới hạn về hiệu suất chứng minh toàn hệ thống. Ông xem đây là những “mục tiêu buộc phải động tới” nếu Ethereum(ETH) muốn đồng thời đạt được *từ* khả năng mở rộng *từ* và quyền riêng tư trên lớp thực thi, thay vì chỉ tối ưu từng phần nhỏ.

Theo CoinDesk đưa tin, Buterin cho rằng những thay đổi này cần được nhìn nhận như một cuộc đại tu kiến trúc lõi, chứ không chỉ là các bản vá cục bộ.

MỘT CÂY TRẠNG THÁI MỚI: EIP-7864 VÀ MỤC TIÊU GIẢM 3–4 LẦN CHI PHÍ CHỨNG MINH

Cơ sở kỹ thuật chính mà Buterin viện dẫn là đề xuất EIP-7864 do nhà phát triển *Guillaume Ballet* và cộng sự soạn thảo. Hiện tại, Ethereum(ETH) sử dụng cấu trúc cây *Merkle Patricia Tree* (MPT) dạng thập lục phân (hexary, 16 nhánh) với hàm băm Keccak. EIP-7864 đề xuất thay thế bằng một cây nhị phân (binary tree) dùng hàm băm hiệu quả hơn.

Theo phân tích của Buterin, nếu chuyển sang cây nhị phân, độ dài “nhánh Merkle” (Merkle branch – đường dẫn xác minh) có thể rút ngắn khoảng 4 lần. Nhánh ngắn hơn đồng nghĩa:

- Dữ liệu chứng minh cần truyền trên mạng ít hơn, giảm áp lực băng thông.

- Chi phí tính toán để client xác minh nhánh chứng minh cũng giảm mạnh.

Buterin ước tính riêng thay đổi này có thể cải thiện hiệu suất chứng minh tổng thể khoảng 3–4 lần trong các kịch bản *từ* ZK proof *từ* và client-side proof.

Bình luận: Với các rollup ZK, dữ liệu nhánh Merkle là một trong những thành phần nặng nhất trong bằng chứng. Việc rút gọn độ sâu cây là một trong những cách trực diện nhất để “ép mỏng” chi phí chứng minh mà không phải thay đổi mô hình bảo mật.

TỐI ƯU HÀM BĂM: TỪ KECCAK SANG BLAKE3, POSEIDON

Lợi ích trở nên lớn hơn nếu Ethereum(ETH) mạnh dạn thay đổi cả hàm băm nền tảng.

Buterin lấy BLAKE3 làm ví dụ, cho rằng hàm băm này trong nhiều bối cảnh có thể hiệu quả gấp khoảng 3 lần so với Keccak – vốn là chuẩn de facto trong Ethereum(ETH) từ trước đến nay. Việc sử dụng BLAKE3 hoặc các hàm băm hiện đại khác có thể giảm thêm thời gian và chi phí cho việc tạo cũng như xác minh bằng chứng, nhất là trên các phần cứng tối ưu hóa song song.

Ông cũng nhắc tới họ hàm băm *Poseidon*, vốn được thiết kế rất thân thiện với mạch ZK, với tiềm năng cải thiện tới hàng chục, thậm chí đến “xấp xỉ 100 lần” trong một số khía cạnh liên quan đến chứng minh. Tuy vậy, Buterin lưu ý rằng việc dùng các biến thể Poseidon trong lớp giao thức nền sẽ đòi hỏi thêm thời gian đánh giá và kiểm chứng bảo mật, bởi đây là bước rủi ro hơn so với việc dùng các hàm băm đã được triển khai rộng rãi.

Bình luận: Nếu Ethereum(ETH) thực sự chuyển sang các hàm băm tối ưu cho ZK ngay từ lớp trạng thái, toàn bộ hệ sinh thái rollup và ứng dụng ZK phía trên sẽ được “thừa hưởng” trực tiếp, thay vì mỗi dự án phải tự thiết kế cây trạng thái riêng, gây phân mảnh và trùng lặp nỗ lực.

TIẾT KIỆM GAS VÀ GHÉP NỐI ZK APP: “ĐỪNG TẠO TRẠNG THÁI RIÊNG, HÃY DÙNG CHUNG VỚI ETHEREUM”

Theo mô tả của Buterin, thiết kế cây nhị phân mới không chỉ giảm chi phí chứng minh mà còn có thể *từ* tiết kiệm gas *từ* đáng kể cho các ứng dụng.

Trong đề xuất EIP-7864, không gian lưu trữ (storage) được chia thành các “trang” (page) gồm khoảng 64–256 slot liên tiếp. Việc nhóm các slot liền kề lại với nhau cho phép máy ảo tải và cập nhật dữ liệu cục bộ hiệu quả hơn, tận dụng tốt cache và giảm số lần truy xuất cây trạng thái.

Buterin cho biết các ứng dụng thường xuyên thao tác với các slot lưu trữ ban đầu (initial storage slots) – ví dụ các hợp đồng DeFi có nhiều biến trạng thái truy cập lặp lại – có thể giảm được “hơn 10.000 gas mỗi giao dịch” nhờ cấu trúc mới.

Bên cạnh đó, việc chuẩn hóa một cây trạng thái “thân thiện với prover” ngay trên Ethereum(ETH) sẽ giúp các *từ* ứng dụng ZK *từ* dễ dàng đọc – ghi trực tiếp vào trạng thái L1, thay vì phải:

- Dựng một cây trạng thái riêng phục vụ chứng minh;

- Duy trì hai hệ thống trạng thái song song (một cho Ethereum, một cho hệ ZK), vừa phức tạp vừa tốn tài nguyên.

Nếu tận dụng được cùng một cây trạng thái nền, nhà phát triển ZK có thể giảm đáng kể chi phí vận hành, đồng thời đơn giản hóa logic đồng bộ hoá dữ liệu on-chain – off-chain.

Buterin cũng cho rằng thiết kế mới, do đơn giản và mô-đun hơn, sẽ tạo khoảng trống để Ethereum(ETH) cài đặt thêm *từ* cơ chế hết hạn trạng thái (state expiry) *từ* trong tương lai. Khi đó, các phần dữ liệu cũ, ít được truy cập có thể dần được loại bỏ hoặc đưa vào lớp lưu trữ rẻ hơn, giúp giới hạn kích thước trạng thái toàn mạng về dài hạn.

Bình luận: State expiry từng được thảo luận nhiều năm nhưng luôn vướng ở bài toán phức tạp của MPT hiện tại. Một cây trạng thái gọn và thiết kế “từ đầu cho ZK” có thể mở lại cánh cửa cho các cơ chế thu gọn trạng thái, giảm gánh nặng cho full node.

TỪ EVM SANG RISC-V: MỘT LỘ TRÌNH DÀI HƠI CHO MÁY ẢO ETHEREUM

Song song câu chuyện cây trạng thái, Buterin còn đề xuất một ý tưởng dài hạn hơn: thay thế hoàn toàn *Ethereum Virtual Machine (EVM)* hiện tại bằng một máy ảo dựa trên kiến trúc *RISC-V*.

Buterin nhấn mạnh đây là ý tưởng “dài hạn và không thuộc lớp đồng thuận” – nghĩa là không phải thay đổi tức thời trên consensus. Tuy nhiên ông bày tỏ niềm tin rằng sau khi hoàn tất các nâng cấp lớn liên quan tới trạng thái, việc chuyển sang RISC-V gần như sẽ là “sự lựa chọn hiển nhiên”.

Lý do được ông đưa ra gồm ba điểm:

- RISC-V có hiệu suất thực thi tốt hơn cho kiểu tính toán phổ biến trong hợp đồng thông minh.

- RISC-V thân thiện với *từ chứng minh ZK *từ hơn, vì đã có nhiều prover và công cụ ZK tối ưu cho kiến trúc lệnh đơn giản này.

- Cấu trúc lệnh RISC-V gọn, dễ kiểm chứng và dễ hiện thực hóa bằng các trình thông dịch (interpreter) ngắn gọn – theo Buterin, một interpreter RISC-V có thể được viết chỉ trong vài trăm dòng mã.

Phương án chuyển đổi, theo Buterin, sẽ diễn ra theo lộ trình từng bước:

1. Ban đầu, máy ảo RISC-V mới được đưa vào dưới dạng các “precompile” – các hàm hệ thống được gọi từ EVM.

2. Tiếp theo, các nhà phát triển có thể triển khai hợp đồng trực tiếp trên VM mới, song song với EVM.

3. Cuối cùng, EVM sẽ được “hạ cấp” thành một lớp tương thích (compatibility layer), bản thân EVM chạy như một smart contract trên hệ thống VM mới.

Trong giai đoạn cuối, chi phí gas cho các hoạt động EVM có thể thay đổi, do phải đi qua lớp tương thích. Tuy nhiên Buterin dự đoán trong vài năm tới, những cải tiến về mở rộng quy mô (scaling) – cả từ lớp trạng thái, ZK lẫn VM – sẽ đủ lớn để bù đắp, thậm chí vượt xa bất kỳ sự gia tăng chi phí nào ở tầng tương thích.

Bình luận: Nếu kịch bản này thành hiện thực, “EVM” sẽ dần trở thành một lớp tương thích lịch sử, còn nền tảng thực thi thật sự của Ethereum(ETH) là một VM tổng quát dựa trên RISC-V, tối ưu cho ZK. Điều này tương tự cách nhiều hệ thống giữ “EVM compatibility” như một lớp, nhưng bên dưới chạy kiến trúc hoàn toàn khác.

LIÊN KẾT VỚI LỘ TRÌNH CHỐNG MÁY TÍNH LƯỢNG TỬ CỦA ETHEREUM

Đề xuất mới của Buterin xuất hiện ngay sau khi ông công bố *từ lộ trình chống lượng tử (quantum-resistance roadmap) *từ cho Ethereum(ETH). Trong lộ trình đó, Buterin đề cập khả năng thay thế chữ ký BLS đang dùng ở lớp đồng thuận (consensus layer) bằng các sơ đồ chữ ký dựa trên hàm băm, chẳng hạn biến thể Winternitz, để giảm rủi ro trước các cuộc tấn công từ máy tính lượng tử trong tương lai.

Sự liên tiếp của hai đề xuất cho thấy Buterin đang muốn Ethereum(ETH) dịch chuyển dần sang một kiến trúc “chuẩn hóa” hơn cho kỷ nguyên hậu ZK và hậu lượng tử:

- Ở lớp trạng thái và máy ảo: dùng cây, hàm băm, VM đều hướng tới *từ thân thiện ZK *từ.

- Ở lớp đồng thuận: chuẩn bị sẵn đường lui sang các sơ đồ chữ ký và hàm băm có khả năng chống lượng tử mạnh hơn.

Bình luận: Đối với nhà đầu tư và nhà phát triển, chuỗi đề xuất này ngầm nói rằng Ethereum(ETH) sẵn sàng đánh đổi sự ổn định ngắn hạn của kiến trúc hiện tại để tạo nền tảng bền vững hơn cho chu kỳ tiếp theo của *từ mở rộng quy mô *từ và bảo mật. Dù chưa có mốc thời gian cụ thể, hướng đi này có thể ảnh hưởng đến chiến lược của các dự án ZK rollup, middleware và hạ tầng node trong vài năm tới.

KẾT LUẬN

Những chia sẻ mới của *Vitalik Buterin* cho thấy Ethereum(ETH) đang đứng trước một giai đoạn điều chỉnh sâu về kiến trúc: từ *từ cây trạng thái *từ đến *từ máy ảo *từ và thậm chí cả mô hình chữ ký ở lớp đồng thuận.

Nếu đề xuất *từ EIP-7864 *từ và các tối ưu hàm băm được chấp nhận, chi phí và độ trễ cho *từ ZK proof *từ cùng môi trường chứng minh phía khách hàng có thể giảm 3–4 lần, đồng thời mở đường cho các cơ chế như *từ state expiry *từ và hạ tầng ZK native ngay trên L1. Về dài hạn, một lộ trình chuyển EVM sang VM dựa trên RISC-V có thể biến Ethereum(ETH) thành nền tảng thực thi vừa thân thiện ZK, vừa sẵn sàng hơn trước các rủi ro công nghệ mới như máy tính lượng tử.

Theo dõi cách cộng đồng và các nhà phát triển cốt lõi phản hồi những đề xuất này sẽ là chìa khóa để đánh giá triển vọng *từ khả năng mở rộng *từ và *từ bảo mật *từ của Ethereum(ETH) trong chu kỳ tiếp theo.

<Bản quyền ⓒ TokenPost, nghiêm cấm sao chép và phân phối trái phép>

Phổ biến nhất

Các bài viết liên quan khác

Bình luận 0

Mẹo bình luận

Bài viết tuyệt vời. Mong có bài tiếp theo. Phân tích xuất sắc.

0/1000

Mẹo bình luận

Bài viết tuyệt vời. Mong có bài tiếp theo. Phân tích xuất sắc.
1