Các nhà nghiên cứu của Ethereum Foundation cảnh báo về gánh nặng lưu trữ do 'state bloat', đề xuất các giải pháp giảm tắc nghẽn node

Nhóm Stateless Consensus của Ethereum Foundation đã trình bày một loạt ý tưởng nhằm hạn chế “state bloat”, cảnh báo rằng việc lưu trữ ngày càng mở rộng các tài khoản, lưu trữ hợp đồng và bytecode của mạng lưới đang trở nên ngày càng khó khăn cho các nhà vận hành node trong việc lưu trữ, phục vụ và đồng bộ hóa.

“State” của Ethereum bao gồm tất cả những gì mạng lưới hiện biết, bao gồm số dư tài khoản, lưu trữ hợp đồng và mã nguồn vận hành các ứng dụng. Foundation cho biết hệ thống này đã trở thành một phần hạ tầng toàn cầu quan trọng “giải quyết hàng billions đô la giá trị” và điều phối hàng nghìn ứng dụng.

Tuy nhiên, các nhà nghiên cứu của EF cho biết tầm quan trọng này hiện đã tạo ra một vấn đề nghiêm trọng: state chỉ tăng lên; nó không bao giờ giảm xuống.

Khi dữ liệu tích lũy nhiều hơn, việc vận hành một node đầy đủ trở nên đắt đỏ và dễ bị tổn thương hơn. Một bài đăng trên blog của EF lưu ý rằng “nếu state trở nên quá lớn, quá tập trung hoặc quá khó để phục vụ, tất cả các lớp này sẽ trở nên mong manh hơn, đắt đỏ hơn và khó phi tập trung hóa hơn.”

Các cải tiến về mở rộng như Layer 2, EIP-4844 (proto-danksharding) và tăng giới hạn gas đã cho phép nhiều hoạt động hơn, nhưng chúng cũng thúc đẩy sự tăng trưởng của state.

Các nhà nghiên cứu cảnh báo rằng nếu chỉ một nhóm nhỏ các nhà vận hành tinh vi có thể đủ khả năng lưu trữ và phục vụ toàn bộ state, khả năng chống kiểm duyệt, tính trung lập và khả năng phục hồi của Ethereum có thể bị suy yếu. Nhóm cho biết họ đang tích cực kiểm tra áp lực để xác định khi nào “sự tăng trưởng của state trở thành nút thắt mở rộng”, khi nào “kích thước state khiến các node khó theo dõi đầu chuỗi”, và khi nào “các triển khai client bắt đầu thất bại dưới kích thước state cực lớn.”

Xác thực không trạng thái đặt ra câu hỏi mới: ai sẽ lưu trữ dữ liệu?

Lộ trình dài hạn của Ethereum bao gồm statelessness, tập trung vào việc cho phép các validator xác minh block mà không cần giữ toàn bộ state.

Mặc dù điều này giảm gánh nặng cho validator và mở khóa thông lượng cao hơn, nó cũng chuyển trách nhiệm lưu trữ state lịch sử cho một nhóm nhỏ, chuyên biệt hơn. Các nhà nghiên cứu viết rằng trong thiết kế stateless, “phần lớn state có khả năng chỉ được lưu trữ bởi: block builder, RPC provider [và] các nhà vận hành chuyên biệt khác như MEV searcher và block explorer.”

Nhóm cho biết sự tập trung hóa đó tạo ra các thách thức về đồng bộ hóa, khả năng chống kiểm duyệt và khả năng phục hồi trước sự cố hoặc áp lực bên ngoài.

Ba hướng đề xuất

Nhóm Stateless Consensus đã đề xuất ba cách tiếp cận tiềm năng để việc lưu trữ và phục vụ state trở nên dễ quản lý hơn.

Đầu tiên, State Expiry, loại bỏ dữ liệu không hoạt động khỏi tập hợp hoạt động trong khi vẫn cho phép người dùng khôi phục lại bằng các bằng chứng. Nhóm cho biết khoảng “80% state chưa được chạm tới trong hơn 1 năm”, nhưng tất cả các node vẫn phải lưu trữ nó ngày nay. Hai biến thể đang được xem xét: “đánh dấu, hết hạn, khôi phục”, đánh dấu và loại bỏ các mục ít được sử dụng, và “multi-era expiry”, cuộn dữ liệu thành các thời kỳ và đóng băng các thời kỳ cũ hơn.

Hướng thứ hai, State Archive, tách state nóng khỏi state lạnh. Dữ liệu nóng vẫn được giới hạn và truy cập nhanh, trong khi dữ liệu lạnh được bảo tồn cho mục đích lịch sử và xác minh. Điều này sẽ cho phép hiệu suất node “giữ ổn định theo thời gian, thay vì suy giảm khi chuỗi già đi”, ngay cả khi tổng state tăng lên.

Lựa chọn cuối cùng, Partial Statelessness, cho phép các node chỉ lưu trữ một phần của state, trong khi ví và light client lưu vào bộ nhớ cache dữ liệu mà chúng dựa vào. Điều này có thể mở rộng sự tham gia bằng cách giảm chi phí lưu trữ và giảm sự phụ thuộc vào các RPC provider lớn.

Ở cả ba cách tiếp cận, mục tiêu là “giảm state như một nút thắt hiệu suất, giảm chi phí lưu trữ và làm cho việc phục vụ trở nên dễ dàng hơn.”

Bước tiếp theo là gì?

EF cho biết họ đang ưu tiên các nỗ lực thực tiễn có thể mang lại lợi ích ngay hôm nay đồng thời chuẩn bị cho những thay đổi giao thức tham vọng hơn trong tương lai.

Theo bài đăng, những điều này bao gồm phát triển archive, cải tiến hạ tầng RPC và làm cho việc vận hành các node partial stateless trở nên dễ dàng hơn. Nhóm cũng nhấn mạnh rằng các sáng kiến này được chọn vì “chúng hữu ích ngay lập tức và tương thích với tương lai.”

Trong thời gian tới, foundation đã mời các nhà phát triển, nhà vận hành node và các nhóm hạ tầng tham gia.

“Khi chúng tôi lặp lại, chúng tôi sẽ tiếp tục chia sẻ tiến trình và các câu hỏi mở của mình. Nhưng chúng tôi không thể giải quyết điều này một mình,” các nhà nghiên cứu viết. “Nếu bạn là nhà phát triển client, vận hành node, vận hành hạ tầng, xây dựng trên Layer 2 hoặc đơn giản là quan tâm đến sức khỏe lâu dài của Ethereum, chúng tôi mời bạn tham gia: chia sẻ phản hồi về các đề xuất của chúng tôi, tham gia thảo luận trên diễn đàn và cuộc gọi, và giúp thử nghiệm các cách tiếp cận mới trong thực tế.”

Bản cập nhật này được đưa ra khi Ethereum Foundation đã tăng cường truyền thông về phát triển giao thức dài hạn.