Tóm Tắt

Thực thi Stateless: Các validator không lưu trữ toàn bộ trạng thái mà chỉ xác minh các chuyển tiếp thông qua bằng chứng mật mã.

Thực thi Stateful: Mỗi validator lưu trữ và cập nhật toàn bộ trạng thái hệ thống (mô hình truyền thống của Ethereum mainnet).

Stateless dựa vào bằng chứng nhỏ gọn (Verkle trees, STARKs) và lớp dữ liệu khả dụng (DA) mạnh mẽ.

Ưu điểm chính: Chi phí phần cứng thấp hơn nhiều + Tăng tính phi tập trung so với Kích thước bằng chứng và băng thông cao hơn.

Hiện thực 2025: Mô hình Stateless thuần túy vẫn còn hiếm; hầu hết kiến trúc module sử dụng thực thi Stateless kết hợp với DA/trạng thái (mô hình hỗn hợp).

Ví dụ tiêu biểu: Ethereum Verge (Verkle), Polygon AggLayer, rollups trên Celestia, và các cầu nối lười (lazy bridging)

Tại sao mô hình thực thi lại quan trọng?

Cách các nút blockchain truy cập và cập nhật trạng thái không còn là chi tiết triển khai đơn thuần; nó trở thành một trong những công cụ chính để mở rộng quy mô và đạt được chủ quyền trong thiết kế module. Khi các rollups, appchains, và L2 chủ quyền phát triển, các nhà kiến trúc phải quyết định liệu các validator có cần mang theo terabytes dữ liệu lịch sử hay có thể xác minh chuyển tiếp trạng thái mà không cần lưu trữ trạng thái.

Lựa chọn giữa Stateless và Stateful trực tiếp ảnh hưởng đến tính phi tập trung, rào cản phần cứng, chi phí khả dụng dữ liệu, và khả năng kết hợp liên chuỗi.

Định nghĩa 2 Mô Hình

Thực thi Stateful – Mô Hình Truyền Thống

Trong mô hình Stateful, mỗi nút đầy đủ duy trì một bản sao cập nhật hoàn chỉnh của toàn bộ trạng thái hệ thống (số dư tài khoản, lưu trữ hợp đồng thông minh, mã băm, v.v.). Khi một khối được đề xuất:

Nhà sản xuất khối bao gồm giao dịch và root trạng thái mới.

Mỗi validator thực thi lại từng giao dịch trên bản sao trạng thái cục bộ.

Nếu root trạng thái kết quả khớp với root trong khối, khối được chấp nhận.

Ethereum, Solana, BNB Chain, và hầu hết các L1 monolithic hoạt động theo cách này. Ưu điểm là tính đơn giản và xác nhận trạng thái tức thì: bất kỳ nút nào cũng có thể trả lời "số dư địa chỉ X là bao nhiêu?" mà không cần trao đổi với bên nào khác.

Nhược điểm rõ ràng vào năm 2025: Nút lưu trữ đầy đủ Ethereum hiện vượt quá 14 TB và đang tiếp tục tăng. Ngay cả các nút đã được cắt xén cũng cần SSD ~1 TB và RAM 32+ GB, loại bỏ khả năng vận hành của hầu hết người dùng cá nhân.

Thực thi Stateless

Trong mô hình Stateless, các validator không lưu trữ trạng thái hệ thống cục bộ. Thay vào đó, mỗi giao dịch (hoặc lô) đi kèm với bằng chứng mật mã xác nhận rằng giao dịch có quyền truy cập vào các phần trạng thái cần thiết (ví dụ: nhánh Merkle trong cây Patricia hoặc bằng chứng Verkle).

Quy trình xác minh trở thành:

Nhà sản xuất khối đính kèm bằng chứng + giao dịch + root trạng thái mới.

Các validator kiểm tra tính hợp lệ của bằng chứng so với root trạng thái đã chấp nhận gần nhất.

Các validator thực thi lại giao dịch chỉ với dữ liệu bằng chứng được cung cấp.

Nếu root trạng thái tính toán khớp với tuyên bố trong khối, chấp nhận.

Không nút nào lưu trữ nhiều hơn vài khối trạng thái gần đây. Gánh nặng chuyển từ lưu trữ sang băng thông và xác minh mật mã.

Cân nhắc Kỹ thuật Khi Mở rộng Quy mô

Yêu cầu Phần cứng và Tính Phi tập trung

Stateless chiếm ưu thế rõ ràng ở khía cạnh này. Một client Ethereum Stateless đang được thử nghiệm trên mạng testnet Verge có thể chạy mượt mà trên mini-PC 300 USD hoặc thậm chí cụm Raspberry Pi 5 cao cấp. Trong khi đó, chạy nút thực thi Stateful trên hầu hết L1/L2 yêu cầu phần cứng doanh nghiệp.

Bằng chứng thực tế: Các nút DA nhẹ của Celestia đã hoạt động Stateless với <8 GB RAM, trong khi các nút thực thi Ethereum vật lộn với vấn đề trạng thái phình to.

Băng thông và Kích thước

Nhược điểm chính của thực thi Stateless thuần túy luôn là vấn đề bằng chứng phình to. Với cây Merkle-Patricia cổ điển của Ethereum, một giao dịch ERC-20 đơn lẻ thường yêu cầu ~1–3 KB dữ liệu bằng chứng. Ngay cả với 1.000 giao dịch/giây, điều này chuyển thành hàng chục megabit/giây chỉ cho bằng chứng, vượt ngưỡng thực tế cho client Stateless.

Đó là lý do tại sao toàn bộ hệ sinh thái đang đua nhau hướng tới Verkle trees và STARK recursion: cả hai giảm kích thước bằng chứng 20–30× và biến client Stateless thành khả thi ở quy mô thực tế.

Đảm bảo Khả dụng Dữ liệu

Client Stateless chỉ an toàn bằng lớp khả dụng dữ liệu nền tảng. Nếu nhà sản xuất khối ẩn một phần bằng chứng hoặc delta trạng thái, validator Stateless không thể phát hiện gian lận mà không có toàn bộ dữ liệu.

Đây là lý do thực thi Stateless hầu như luôn kết hợp với lớp DA chuyên dụng (Celestia, Ethereum DAS sau Prague, Avail). Lớp DA vẫn Stateful, nghĩa là phải lưu trữ và phục vụ dữ liệu, nhưng các validator thực thi giữ nguyên nhẹ và Stateless.

Tính Khả hợp Đồng bộ & Không đồng bộ

Rollups Stateful (ví dụ: Arbitrum One trước Atlas, chuỗi OP Stack) cung cấp khả hợp đồng bộ: một token trên rollup này có thể được sử dụng trong rollup khác cùng khối nếu chia sẻ lớp thanh toán chung.

Thiết kế Stateless có xu hướng hướng tới khả hợp không đồng bộ vì bằng chứng trạng thái mất thời gian để tạo và lan truyền. Các dự án như Polygon AggLayer và cầu SP1 của Succinct đang giải quyết điều này bằng cơ chế xác nhận trước và cầu Stateless chung.

Triển khai Thực tế

Ethereum – Verkle Trees

Cập nhật "Verge" sắp tới của Ethereum thay thế cây Patricia Merkle bằng Verkle trees, giảm kích thước bằng chứng từ kilobytes xuống ~30–50 bytes mỗi ô lưu trữ. EIP-6800 và EIP-7691 đặt nền móng cho client Stateless hoàn toàn vào 2026–2027. Khi triển khai, bất kỳ ai cũng có thể chạy nút xác minh đầy đủ trên laptop trong khi vẫn xác minh toàn bộ chuỗi.

Celestia + Rollups – DA Stateless, Thực thi Hỗn hợp

Celestia hoàn toàn Stateless cho việc lấy mẫu khả dụng dữ liệu. Các rollups đăng ký lên Celestia (ví dụ: Doma, Movement) hiện chạy nút thực thi Stateful, nhưng các dự án như Eclipse và Citrus (rollup SVM trên Celestia) đang chuyển hướng client SVM Stateless bằng bằng chứng STARK và DA Celestia.

Polygon AggLayer – Cầu Stateless Đa năng

AggLayer triển khai bộ tổng hợp bằng chứng Stateless chung. Các chuỗi riêng biệt có thể giữ trạng thái nội bộ, nhưng tin nhắn liên chuỗi được chứng minh qua ZK Stateless dựa trên root trạng thái chung. Điều này mang lại an ninh của lớp thanh toán chung mà không bắt buộc mỗi validator lưu trữ trạng thái của mọi chuỗi.

Các Phương pháp Hỗn hợp – Giải pháp Thực tế

Thực thi thuần túy Stateless vẫn hiếm trong sản xuất. Hầu hết các nhóm áp dụng một trong ba mô hình hỗn hợp:

Thực thi Stateful + xác minh Stateless (ví dụ: bộ prover boojum của zkSync Era tạo ra bằng chứng mà bất kỳ nút Stateless nào cũng có thể xác minh)

Client Stateless + DA/trạng thái cơ bản (mô hình Ethereum + Celestia)

Lớp cầu Stateless trên chuỗi Stateful (AggLayer, chữ ký chuỗi của Near)

Các mô hình hỗn hợp này nắm bắt được hầu hết lợi ích phi tập trung trong khi kiểm soát chi phí bằng chứng.

Triển khai Trong Tương lai

Đến 2027, giả định mặc định trong kiến trúc module có thể là "thực thi Stateless, khả dụng dữ liệu và thanh toán tối thiểu Stateful". Tiến bộ trong Verkle trees, STARK recursion, và phân phối bằng chứng phân tán (ví dụ: Mạng Portal, client nhẹ Helios) đang loại bỏ những trở ngại lớn cuối cùng.

Đối với các nhà xây dựng chọn mô hình thực thi ngày nay:

Nếu ưu tiên tối đa tính phi tập trung và chủ quyền dài hạn → chọn Stateless từ đầu (kết hợp với Celestia/Avail/Ethereum DAS)

Nếu cần khả hợp đồng bộ và chấp nhận phần cứng cao hơn → thực thi Stateful với cắt xén dữ liệu mạnh mẽ và lộ trình chuyển đổi sang Stateless

Mô hình Stateless không phải là giải pháp vạn năng, nhưng nó đang trở thành điều kiện tiên quyết cho bất kỳ chuỗi nào muốn duy trì tính trung lập và khả năng tiếp cận toàn cầu khi trạng thái tăng vô hạn.

Tương lai của blockchain mở rộng và chủ quyền là nơi không thực thể nào, dù được tài trợ mạnh mẽ, phải lưu trữ toàn bộ lịch sử chuỗi để tham gia đồng thuận. Tương lai đó đang được xây dựng.