Trạng thái hết hạn: Trong giao thức so với Ngoài giao thức

Tăng trưởng trạng thái vẫn là nút thắt chính về hiệu suất và phân quyền. Nó làm tăng thời gian đồng bộ hóa node, làm giảm hiệu suất thực thi Block và tăng yêu cầu lưu trữ. Điều này khác với tăng trưởng lịch sử (khối/biên lai cũ), mà Đề xuất cải tiến Ethereum (EIP)-4444 cho phép máy khách cắt bớt. Phân tích thực nghiệm gần đây về các mô hình truy cập trạng thái cho thấy việc sử dụng trạng thái bị lệch rất nhiều—hầu hết các giao dịch đều gặp phải một tập hợp nhỏ trạng thái nóng, vì vậy việc loại bỏ trạng thái lạnh có thể giúp giảm đáng kể gánh nặng cho node.

Việc hết hạn trạng thái chủ yếu nhằm mục đích làm chậm tốc độ tăng trưởng của trạng thái (hoặc thậm chí giữ nó ở mức không đổi). Nó đề xuất loại bỏ trạng thái lạnh khỏi tập hợp đang hoạt động và yêu cầu bằng chứng phục hồi khi nó được truy cập lại. Cho đến nay, có hai yếu tố cản trở việc đưa trạng thái hết hạn vào hoạt động:

1. Trải nghiệm người dùng: cách người dùng lấy bằng chứng để phục hồi.
2. Dán nhãn rẻ và chắc chắn cho các đối tượng đã hết hạn.

Khi chúng ta hướng tới việc chứng minh theo thời gian thực và một thế giới không trạng thái, việc hết hạn trạng thái sẽ diễn ra như thế nào vẫn chưa rõ ràng. Do đó, bài viết này sẽ thực hiện hai việc:

• Bản đồ cho biết ai thực sự cần trạng thái và việc hết hạn trạng thái giúp ích như thế nào trên lộ trình hiện tại và tương lai.
• So sánh trạng thái hết hạn trong giao thức với trạng thái hết hạn ngoài giao thức cùng với những đánh đổi cụ thể.

Ai nắm giữ nhà nước?

Hôm nay (2025)

Tóm lại: Hầu hết các nút phải giữ trạng thái.

1. Trình xác thực : Xây dựng, thực thi và xác thực các khối dựa trên trạng thái đang hoạt động. Hoạt động thực tế vẫn giả định trạng thái đầy đủ.
2. Người xây dựng: Ngoài giao thức. Một số thực thể xây dựng phần lớn các khối (xem phần tập trung trong Ai thắng đấu giá xây dựng Block ? ). Chúng duy trì trạng thái để mô phỏng và xây dựng các khối.
3. Các nút RPC : Thường chạy các nút đầy đủ. Một số có thể sử dụng các mẫu theo dõi (ví dụ: chế độ hạm đội của Besu ) trong đó các nút nhẹ hơn lấy delta trạng thái từ một nút đầy đủ đáng tin cậy.

Nếu chúng ta triển khai trạng thái hết hạn trong giao thức ngay bây giờ: mọi người đều được hưởng lợi từ nó—trạng thái hoạt động nhỏ hơn để thực thi, đồng bộ hóa nhanh hơn, độ trễ đọc/ghi trạng thái thấp hơn và ít rủi ro hơn khi tăng giới hạn gas .

Dài hạn (ePBS + không quốc tịch)

Tóm lại: Chỉ có người xây dựng mới phải giữ trạng thái trong khi những người khác có thể không có trạng thái.

Giả sử PBS được bảo vệ ( Đề xuất cải tiến Ethereum (EIP)-7732 ) và các cơ chế chống kiểm duyệt (ví dụ: FOCIL ), cộng với tình trạng không có trạng thái với (a) các nhân chứng trie Verkle/Binary trong các khối hoặc (b) các bằng chứng ZK thực thi Block :

1. Người đề xuất/Người chứng thực — Xác minh thông qua nhân chứng hoặc bằng chứng. Không cần trạng thái toàn cục. Lý tưởng nhất là trạng thái không trạng thái một phần chỉ có giá trị pháp lý (VOPS) để giữ cho bộ nhớ công khai hoạt động tốt.
2. Người xây dựng : Cần có trạng thái để xây dựng các khối. Với FOCIL (không có giao dịch mang chứng cứ), người xây dựng được kỳ vọng có quyền truy cập vào toàn bộ trạng thái.
3. Người chứng minh : Cần có quyền truy cập trạng thái để lấy lại chứng cứ được sử dụng trong quá trình tạo bằng chứng.
4. Các nút RPC : Xu hướng hướng tới trạng thái không trạng thái một phần ( ưu tiên nút cục bộ ) trong đó mỗi nút chỉ lưu trữ trạng thái mà nó quan tâm, nhưng lý tưởng nhất vẫn là VOPS.

Trong thế giới này, việc hết hạn trạng thái chủ yếu mang lại lợi ích cho các nhà xây dựng, những người gánh chịu phần lớn chi phí phát triển trạng thái. Nếu không hết hạn, các nhà xây dựng phải trang bị phần cứng ngày càng nặng, làm gia tăng sự tập trung của các nhà xây dựng.

Nếu trình chứng minh khác với trình xây dựng, thì chúng có thể không có trạng thái. Tuy nhiên, trình chứng minh không có trạng thái vẫn cần phải lấy chứng cứ trạng thái từ các nút chứa trạng thái đầy đủ, do đó việc hết hạn trạng thái cũng cải thiện chi phí và hiệu quả trong thế giới chứng minh thời gian thực.

Vào hay ra?

Trạng thái hết hạn trong giao thức

“Trong giao thức” nghĩa là các quy tắc hết hạn được áp dụng theo Consensus . Các đối tượng trạng thái mang siêu dữ liệu tối thiểu được cập nhật khi truy cập trạng thái (đọc, ghi hoặc cả hai). Nếu một đối tượng hết hạn tại thời điểm truy cập, nó phải được phục hồi (thường thông qua giao dịch) với các chứng thực được đính kèm. Một ví dụ là Đề xuất cải tiến Ethereum (EIP)-7736 (hết hạn cấp lá trên Verkle/Binary trie).

Tại sao nó tốt

1. Ranh giới trách nhiệm rõ ràng
Nếu trạng thái của bạn đã hết hạn, bạn có trách nhiệm tìm và cung cấp bằng chứng. Không còn vấn đề mơ hồ "ai lưu trữ trạng thái cũ của tôi?" nữa.

2. Duy trì khả năng xây dựng tại địa phương
Trong một thế giới không có quốc tịch, một quốc gia hoạt động nhỏ hơn sẽ giúp các nhà xây dựng địa phương duy trì hoạt động và hạn chế sự tập trung của các nhà xây dựng. Tuy nhiên, không thể phủ nhận rằng trong tình hình hiện tại, một số ít nhà xây dựng đang tạo ra hầu hết các khối Ethereum.

3. Lợi ích của các nút trạng thái còn lại
Trong một thế giới với các trình chứng thực không trạng thái, việc đồng bộ hóa toàn bộ trạng thái sẽ rất khó khăn, nếu không muốn nói là bất khả thi, nếu hầu hết người tham gia đều không có trạng thái. Do đó, chúng ta vẫn nên kỳ vọng một số nút sẽ vẫn giữ toàn bộ trạng thái và phục vụ nó một cách vị tha (tức là đồng bộ nhanh). Một quy tắc hết hạn trong giao thức sẽ giảm bớt gánh nặng cho chúng. Tuy nhiên, sự phụ thuộc vào tính vị tha này có thể được giảm thiểu bằng một mạng trạng thái phi tập trung như Mạng Cổng thông tin , mạng này bảo toàn và có thể phục vụ trạng thái mà không phụ thuộc vào các nút có trạng thái vị tha. Mặc dù bản thân Cổng thông tin là một hệ thống vị tha.

4. Giao diện UX có thể dự đoán được
Ví có thể hướng tới một quy tắc hết hạn duy nhất , chứ không phải một loạt các chính sách của nhà phát triển.

Tại sao nó khó

1. Trải nghiệm người dùng phục sinh
Ví cần luồng dữ liệu mạnh mẽ để phục hồi nhiều đối tượng (ví dụ: chứng minh hàng loạt) nhằm tránh việc phải thực hiện nhiều bước nhảy để phục hồi trạng thái. Sơ đồ càng chi tiết (cấp khe cắm so với cấp tài khoản), trải nghiệm người dùng (UX) càng khó khăn.

2. Ai là người lưu trữ trạng thái hết hạn?
Việc trạng thái hết hạn không làm cho các đối tượng trạng thái biến mất vĩnh viễn. Chúng ta vẫn cần cơ sở hạ tầng phục vụ trạng thái — lý tưởng nhất là phi tập trung. Việc dựa vào các nhà cung cấp bằng chứng đáng tin cậy có thể chấp nhận được trong Short hạn chỉ khi chương trình thực sự loại bỏ các trạng thái vô dụng đối với ~99,99% người dùng. Tuy nhiên, đánh đổi là trạng thái ít lạnh hơn có xu hướng bị loại bỏ.

3. Độ phức tạp và bề mặt DoS
Siêu dữ liệu hết hạn phải được lưu trữ, điều này làm tăng thêm chi phí lưu trữ. Sơ đồ hết hạn càng chi tiết thì chi phí này càng cao. Độ phức tạp của việc phục hồi cũng phụ thuộc vào sơ đồ: ví dụ, việc phục hồi trong phương pháp hết hạn đa cây phức tạp hơn so với thiết kế cấp lá như Đề xuất cải tiến Ethereum (EIP)-7736 . Người dùng cũng phải chịu thêm chi phí để phục hồi trạng thái đã hết hạn.

Trạng thái ngoài giao thức Hết hạn

Ngoài giao thức đồng nghĩa với việc không có thay đổi Consensus . Các nút có thể áp dụng các chính sách hết hạn được phối hợp xã hội (ví dụ: sổ đăng ký trên chuỗi hoặc ngoài chuỗi). Các nút có thể hủy trạng thái và yêu cầu người dùng mang theo bằng chứng của riêng họ —nhưng chuỗi không bắt buộc điều đó.

Tại sao nó tốt

1. Giảm độ phức tạp của giao thức Ethereum
Người xây dựng có thể linh hoạt xác định các quy tắc hết hạn và lặp lại nhanh chóng. Các chính sách có thể được điều phối thông qua mạng xã hội hoặc thông qua cấu hình trên chuỗi. Điều này có thể dễ dàng hơn so với việc Fork.

2. Lặp lại nhanh hơn và khả năng đảo ngược
Các nhà xây dựng có thể thử nghiệm với các phương án cắt tỉa khác nhau một cách sáng tạo hơn. Nếu một chính sách phản tác dụng, việc khôi phục sẽ được thực hiện ngay lập tức và cục bộ. Cài đặt hết hạn không tốt sẽ làm giảm chất lượng dịch vụ của nhà xây dựng (ví dụ: bỏ lỡ MEV, độ trễ cao hơn) thay vì tạo ra rủi ro Consensus toàn cầu hoặc bề mặt DoS trên toàn chuỗi.

3. Khả năng phân hủy của hệ sinh thái
Tạo ra nhu cầu rõ ràng cho các mạng lưới nhà nước phi tập trung và các dịch vụ chứng kiến ​​thương mại. Cả hai đều có thể cạnh tranh về độ trễ, phạm vi phủ sóng và giá cả mà không cần kết nối giao thức. Phí ngoài giao thức để cung cấp chứng kiến ​​hợp lệ có thể được thử nghiệm như một thị trường phụ trợ.

4. Chuyển đổi sang giao thức trong
Việc sử dụng thực tế có thể quyết định thời điểm hết hạn trong giao thức (nếu cần). Cách này cũng dễ hơn so với việc thực hiện trong giao thức ngay từ ngày đầu.

5. Lớp truy cập thống nhất (khi DA mạnh)
Nếu tồn tại một mạng trạng thái nhanh, Không cần cho phép , thì việc sử dụng giao thức ngoài là bắt buộc. Bất kỳ nút không trạng thái hoặc không trạng thái một phần nào cũng có thể lấy chứng cứ theo yêu cầu. Các nút nhận được hầu hết lợi ích hết hạn mà không cần Fork, và ví sử dụng một đường dẫn truy cập đơn giản, tập trung vào bằng chứng.

Tại sao nó khó

1. UX và tính khả dụng của dữ liệu không nhất quán
Các trình xây dựng không có trạng thái cụ thể yêu cầu người dùng cung cấp bằng chứng. Điều này tương tự như gánh nặng UX trong giao thức nhưng không đảm bảo rằng bất kỳ trình xây dựng nào vẫn nắm giữ trạng thái của bạn. Nếu các chính sách được Consensus xã hội, công cụ ứng dụng phải theo dõi nhiều quy tắc, điều này càng làm phức tạp UX.

2. Ai là người lưu trữ trạng thái hết hạn?
Vấn đề tương tự như hết hạn trạng thái trong giao thức. Tuy nhiên, trong trường hợp trong giao thức, quyền sở hữu được xác định rõ ràng (tức là trạng thái của bạn thuộc về bạn). Đối với trường hợp ngoài giao thức, quyền sở hữu không rõ ràng như vậy nên khả năng dữ liệu bị mất vĩnh viễn sẽ cao hơn.

3. Vectơ kiểm duyệt
Nếu chính sách “chúng tôi không giữ nhà nước của bạn” là một chính sách có thể chấp nhận được, áp lực bên ngoài có thể biến nó thành vũ khí để loại trừ các hợp đồng cụ thể, trên thực tế biến nó thành một cuộc tấn công kiểm duyệt.

4. Người xây dựng + sắc thái FOCIL
Nếu các giao dịch trong danh sách bao gồm không có nhân chứng, các nhà xây dựng thực sự cần quyền truy cập vào toàn bộ trạng thái, do đó, động lực cho việc hết hạn ngoài giao thức sẽ giảm. Các nhà xây dựng có thể áp dụng phân tách trạng thái nóng-lạnh nếu hiệu suất được chứng minh là tốt hơn.

Nếu các giao dịch trong danh sách bao gồm có mang theo chứng thực, trình xây dựng có thể không có trạng thái một phần, nhưng điều này trở thành một quy tắc trong giao thức khác làm giảm trải nghiệm của người dùng vì bây giờ tất cả các giao dịch đều phải mang theo chứng thực (hay còn gọi là không có trạng thái mạnh).

5. Đồng bộ hóa trạng thái
Khi người vận hành cắt bỏ trạng thái ngoài giao thức, tính khả dụng của trạng thái sẽ không đồng đều giữa các đối tác. Việc đồng bộ hóa toàn bộ trạng thái có thể khó khăn hơn hoặc thậm chí là bất khả thi.

Những thách thức với sự phục hồi của Nhà nước

Nhìn chung, bất kỳ hình thức hết hạn trạng thái nào (có hoặc không) đều phải đối mặt với việc phục hồi. Dưới đây là một số thách thức:

Nhảy Phục Sinh

Hãy tưởng tượng bạn muốn gửi 1 ETH và một ít Dai đến một tài khoản đã ngừng hoạt động từ lâu. Đầu tiên, việc tra cứu tài khoản cho thấy tài khoản đã hết hạn, nên giao dịch không thành công. Bạn lấy bằng chứng và khôi phục tài khoản. Tiếp theo, giao dịch Dai sẽ chạm vào bộ nhớ của token, vốn cũng đã hết hạn. Bạn phải lấy thêm bằng chứng và khôi phục các khe đó. Tương tác qua lại này chính là vấn đề "hồi sinh nhảy cóc" .

Điều này còn tệ hơn với việc hết hạn trong giao thức vì mỗi lần phục hồi thường yêu cầu gửi một giao dịch. Giao dịch càng chạm đến nhiều đối tượng hết hạn thì càng nhiều bước nhảy và phí. Giao dịch ngoài giao thức cũng gặp phải vòng lặp khám phá/lấy dữ liệu, nhưng các bước nhảy này nằm Ngoài chuỗi (không có giao dịch bổ sung), nhưng vẫn tăng thêm độ trễ.

Các biện pháp giảm thiểu có thể

1. Mô phỏng trước giao dịch so với một oracle trạng thái đầy đủ để liệt kê tất cả các tài khoản và khe lưu trữ phải được khôi phục trước khi gửi giao dịch của người dùng.
2. Giảm mức độ chi tiết của ngày hết hạn (ví dụ: cấp tài khoản hoặc hợp đồng so với cấp khe) để loại bỏ số lượng đối tượng riêng biệt cần phục hồi.
3. Phục hồi hàng loạt : hỗ trợ một bằng chứng được đóng gói duy nhất, phục hồi nhiều tài khoản/khe dữ liệu một cách nguyên tử, với giới hạn byte rõ ràng để kiểm soát rủi ro DoS. Blobs có thể giúp giảm chi phí giao dịch, nhưng vì chúng là tạm thời, nên dữ liệu phục hồi phải được lưu trữ vĩnh viễn ở nơi khác và cung cấp cho mọi người.

Lấy thông tin về trạng thái ở đâu?

1. Nhà cung cấp RPC
   Cơ sở hạ tầng của bên thứ ba (thương mại hoặc công cộng) cung cấp bằng chứng cho nhà nước.

   • Ưu điểm
     • Có sẵn rộng rãi ngày nay
     • Có thể cung cấp các thỏa thuận cấp độ dịch vụ (SLA) đảm bảo tính khả dụng của dữ liệu
     • Tự nhiên được khuyến khích giữ lại trạng thái đầy đủ để "bán" quyền truy cập vào trạng thái đã hết hạn
   • Nhược điểm
     • Rủi ro về lòng tin và kiểm duyệt: Các nhà cung cấp RPC có thể lựa chọn hoặc bị buộc phải kiểm duyệt một số trạng thái nhất định, từ chối khôi phục trạng thái
     • Người dùng trả tiền để lấy lại trạng thái (ngoài các giao dịch phục hồi để trạng thái trong giao thức hết hạn)

2. Nhà cung cấp do khách hàng lưu trữ
   Các nhóm máy khách EL có thể lưu trữ các tệp/ảnh chụp nhanh tĩnh cho trạng thái đã hết hạn trong một khoảng thời gian hết hạn xác định—tương tự như các tệp thời đại cho dữ liệu Block . Các tệp này được làm mới khi chuỗi chính thức bước vào một khoảng thời gian hết hạn mới. Erigon và Reth sử dụng các cơ chế Snapshot tương tự trong kiến ​​trúc đồng bộ trạng thái của họ.

   • Ưu điểm
     • Cộng đồng tin tưởng và minh bạch hơn
     • Các tệp trạng thái và định dạng phản hồi có thể được phối hợp để giảm thiểu độ trễ phục hồi
   • Nhược điểm
     • Gánh nặng về cơ sở hạ tầng và bảo trì bổ sung cho nhóm khách hàng EL
     • Vấn đề vẫn là tin tưởng rằng các nhóm sẽ nắm giữ toàn bộ trạng thái đã hết hạn. Nếu trạng thái không khả dụng, người dùng phải quay lại với các nhà cung cấp RPC hoặc tìm kiếm ở nơi khác.

3. Đồng nghiệp đồng bộ hóa nhanh vị tha
   Dựa vào các peer phục vụ các khối trạng thái (đồng bộ hóa snap) để tập hợp các tài khoản/khe cần thiết cho bằng chứng. Điều này dựa trên giả định rằng vẫn còn các node có trạng thái đầy đủ sẽ phục vụ các yêu cầu snap một cách vị tha ngay cả khi trạng thái hết hạn.

   • Ưu điểm
     • Đã hoạt động ngày hôm nay
     • Tránh phụ thuộc vào một nhà cung cấp đáng tin cậy cụ thể
   • Nhược điểm
     • Giả định này có thể không thành công khi nhiều nút loại bỏ trạng thái hết hạn. Nghĩa là, các nút mới tạo không còn có thể thực hiện đồng bộ hóa nhanh.
     • Trải nghiệm người dùng (UX) của Resurrection bị suy giảm khi số lượng các đối tác trạng thái đầy đủ giảm. Trong trường hợp xấu nhất, người dùng phải quay lại với các nhà cung cấp đáng tin cậy.

4. Mạng lưới nhà nước phi tập trung
   Mạng Không cần cho phép lưu trữ toàn bộ trạng thái và có thể phục vụ trạng thái kèm theo bằng chứng. Một ví dụ như vậy là mạng trạng thái từ mạng Portal.

   • Ưu điểm
     • Chống kiểm duyệt
     • Sao chép tích hợp làm giảm nguy cơ mất trạng thái
   • Nhược điểm
     • Không có triển khai cấp sản xuất nào vào thời điểm hiện tại
     • Sự tham gia phần lớn là vị tha mà không có động cơ khuyến khích, điều này có thể hạn chế độ tin cậy khi chịu tải

5. Khuyến khích các nút giữ tập hợp con trạng thái thông qua Staking cầu vồng
   Xử lý trạng thái phục vụ như một dịch vụ nhẹ trong "vai trò không được đóng gói" của rainbow staking (nặng so với nhẹ). Các nhà điều hành cam kết lưu trữ các tập hợp con của trạng thái và cung cấp các chứng cứ có thể xác minh, trong khi người ủy quyền phân bổ trọng số cho các nhà điều hành này.

   • Ưu điểm
     • phi tập trung
     • Điều chỉnh các động cơ: phần thưởng cố định, dựa trên giao thức để duy trì trạng thái khả dụng, giảm sự phụ thuộc vào lòng vị tha
   • Nhược điểm
     • Hiện tại vẫn đang trong giai đoạn nghiên cứu và cần thiết kế cụ thể để lựa chọn nhà điều hành và tính toán phần thưởng

Phương án 5 là phương án tốt nhất về lâu dài, nhưng sẽ mất thời gian để triển khai. Phương án 2 khả thi hơn trong ngắn hạn.

Tiếp theo là gì?

Nếu chúng ta coi trọng các nhà phát triển độc lập và trải nghiệm người dùng (UX) có thể dự đoán được, thì việc hết hạn trạng thái trong giao thức vẫn là giải pháp an toàn hơn về lâu dài. Trong thế giới ngày nay, việc hết hạn trạng thái rõ ràng có ích. Tuy nhiên, gánh nặng về UX và rủi ro dữ liệu không thể khôi phục khiến việc lưu trữ ngay lập tức trở nên khó xảy ra.

Trong tương lai gần, chúng ta nên thử nghiệm out-of-protocol . Hãy coi out-of-protocol như những nguyên mẫu để giải quyết cùng một vấn đề mà không gặp rủi ro Consensus , đồng thời nêu bật các vấn đề thực tế (ví dụ: trạng thái khả dụng) và lặp lại các giải pháp. Nếu việc hết hạn out-of-protocol tỏ ra đáng tin cậy và thân thiện với người dùng, chúng ta có thể cân nhắc việc áp dụng nó sau này - chỉ khi thực sự cần thiết.

Đóng cửa

Việc hết hạn trạng thái vận chuyển sớm hơn mang lại lợi ích tức thời—trạng thái hoạt động nhỏ hơn, đồng bộ hóa nhanh hơn, dung lượng gas an toàn hơn. Trong tương lai không trạng thái, phần lớn lợi ích đó thuộc về các nhà xây dựng, người chứng minh và một vài nhà cung cấp có trạng thái—chính là những nơi áp lực tập trung tập trung. Bắt đầu với việc hết hạn ngoài giao thức sẽ nhanh chóng nắm bắt được lợi ích, đồng thời phơi bày các rủi ro (tính khả dụng của bằng chứng, DoS, UX) và cho phép chúng ta lặp lại mà không gặp rủi ro Consensus .

Trên hết, cơ sở hạ tầng phục vụ nhà nước là thiết yếu. Khi chúng ta tiến tới trạng thái vô tư và trạng thái hết hạn, mạng lưới cần những phương thức công khai, đáng tin cậy, Không cần cho phép để truy xuất trạng thái và chứng cứ một cách nhất quán.

Tóm lại : mạng không được phép mất trạng thái vĩnh viễn.

Đọc thêm

• Tương lai có thể có của giao thức Ethereum, phần 5: Cuộc thanh trừng
• Cách tăng Gas Limit, Phần 1: Tăng trưởng của tiểu bang
• Đề xuất cải tiến Ethereum (EIP)-7732: Sự tách biệt giữa người đề xuất và người xây dựng được ghi nhận
• Không phải mọi quốc gia đều bình đẳng
• Quan điểm thiết kế giao thức về tình trạng vô quốc tịch
• Một delta ưu tiên nút cục bộ cho lộ trình mở rộng

Lời cảm ơn

Xin chân thành cảm ơn Guillaume, Carlos và Ignacio đã đánh giá bài viết này.