Quỹ Ethereum: Lộ trình phát triển trạng thái của Ethereum và những thách thức trong tương lai

Tác giả: Wei Han Ng, Carlos Pérez, Nhóm Nghiên cứu Đồng thuận Không trạng thái; Dịch thuật: @jinsecaijingxiaozou

Ethereum đã phát triển từ một mạng lưới thử nghiệm nhỏ thành một thành phần quan trọng của cơ sở hạ tầng toàn cầu. Nó xử lý các giao dịch trị giá hàng tỷ đô la mỗi ngày, điều phối hàng ngàn ứng dụng và là nền tảng của toàn bộ hệ sinh thái mạng Lớp 2 (L2).

Tất cả những điều này cuối cùng đều dựa trên một thành phần cốt lõi: trạng thái.

1, "Trạng thái" là gì và tầm quan trọng của nó

Số dư của người dùng không được lưu trữ trong ví của họ, mà nằm trong trạng thái của Ethereum. Trạng thái có thể được hiểu một cách đại khái là "mọi thứ mà Ethereum hiện đang biết": tài khoản, bộ nhớ hợp đồng (tất cả dữ liệu được ghi vào hợp đồng) và mã bytecode (logic chạy khi sử dụng hợp đồng thông minh).

Trạng thái là nền tảng cho hầu hết mọi chức năng: Ví dựa vào nó để hiển thị số dư và lịch sử giao dịch trước đó; các ứng dụng phi tập trung (DApps) truy vấn nó để hiểu số dư hiện tại, lệnh hoặc tin nhắn của chúng; và cơ sở hạ tầng (trình khám phá khối, cầu nối chuỗi chéo, trình lập chỉ mục, v.v.) liên tục đọc trạng thái để cung cấp các dịch vụ trên đó. Nếu trạng thái trở nên quá lớn, quá tập trung hoặc không thể cung cấp dịch vụ, tất cả các lớp trên sẽ trở nên dễ bị tổn thương hơn, tốn kém hơn và khó phân quyền hơn.

2、L1Mở rộng mang lại những hậu quả tương ứng

Ethereum đã liên tục nỗ lực mở rộng mạng lưới trong nhiều năm: thông qua mạng lưới Lớp 2, EIP-4844, tăng giới hạn gas, định giá lại phí gas và cơ chế tách biệt người đề xuất-người xây dựng tích hợp sẵn. Mỗi bước đều cải thiện khả năng xử lý của mạng lưới, nhưng cũng mang lại những thách thức mới.

Thách thức 1: Trạng thái liên tục mở rộng

Kích thước trạng thái của Ethereum chỉ tăng lên. Mỗi tài khoản mới, thao tác lưu trữ và ghi mã bytecode đều làm tăng vĩnh viễn lượng dữ liệu mà mạng phải lưu trữ.

Điều này gây ra những chi phí cụ thể:

Các trình xác thực và các nút đầy đủ phải lưu trữ nhiều dữ liệu hơn. Khi kích thước trạng thái tăng lên, cơ sở dữ liệu cần xử lý thêm khối lượng công việc và hiệu suất giảm tương ứng.

Các nhà cung cấp dịch vụ RPC cần duy trì khả năng truy cập trạng thái hoàn chỉnh, đảm bảo rằng bất kỳ tài khoản hoặc dữ liệu được lưu trữ nào cũng có thể được truy vấn bất cứ lúc nào. Sự tăng trưởng trạng thái dẫn đến đồng bộ hóa nút chậm hơn và giảm tính ổn định. Tăng giới hạn gas làm trầm trọng thêm tình trạng phình to trạng thái vì mỗi khối có thể chứa nhiều thao tác ghi hơn. Vấn đề này đã xảy ra trên các chuỗi công khai khác. Khi kích thước trạng thái tăng lên, người dùng thông thường khó có thể chạy các nút đầy đủ, dẫn đến dữ liệu trạng thái tập trung vào tay một vài nhà cung cấp dịch vụ lớn. Trong Ethereum, hầu hết các khối đã được tạo ra bởi các nhà xây dựng chuyên nghiệp. Mối quan tâm cốt lõi là có bao nhiêu thực thể độc lập vẫn có thể hoàn thành việc xây dựng khối từ đầu đến cuối vào những thời điểm quan trọng. Nếu chỉ một số lượng rất nhỏ người tham gia có thể lưu trữ và cung cấp toàn bộ trạng thái, khả năng chống kiểm duyệt và tính trung lập về độ tin cậy sẽ bị tổn hại—vì sẽ có ít thực thể hơn có thể xây dựng các khối chứa các giao dịch bị kiểm duyệt. Một phần tích cực là các cơ chế như FOCIL và VOPS được thiết kế để đảm bảo khả năng chống kiểm duyệt trong một hệ sinh thái xây dựng chuyên nghiệp. Tuy nhiên, hiệu quả của nó vẫn phụ thuộc vào một hệ sinh thái nút lành mạnh, nơi các nút có thể truy cập, lưu trữ và cung cấp dữ liệu trạng thái với chi phí hợp lý. Do đó, kiểm soát sự tăng trưởng trạng thái là một điều kiện tiên quyết cần thiết, chứ không phải là một tối ưu hóa tùy chọn. Để xác định điểm bùng phát, chúng tôi đang tích cực tiến hành các bài kiểm tra căng thẳng: Khi nào sự tăng trưởng trạng thái trở thành nút thắt cổ chai về khả năng mở rộng? Khi nào kích thước trạng thái khiến các nút khó theo kịp đầu chuỗi? Khi nào việc triển khai máy khách thất bại dưới kích thước trạng thái cực lớn? Thử thách thứ hai: Trong kiến ​​trúc không trạng thái, ai chịu trách nhiệm lưu trữ và cung cấp trạng thái? Ngay cả khi Ethereum duy trì vĩnh viễn giới hạn gas hiện tại, cuối cùng chúng ta cũng sẽ gặp phải vấn đề phình to trạng thái. Trong khi đó, cộng đồng rõ ràng mong đợi thông lượng cao hơn. Các giải pháp không trạng thái loại bỏ một hạn chế lớn: người xác thực không cần phải giữ toàn bộ trạng thái để xác minh các khối, chỉ cần bằng chứng. Đây là một bước đột phá đáng kể về khả năng mở rộng, đáp ứng nhu cầu của cộng đồng về thông lượng cao hơn và tiết lộ một thực tế trước đây chưa được biết đến – việc lưu trữ trạng thái có thể phát triển thành một chức năng độc lập và chuyên biệt hơn, thay vì bị ràng buộc với từng trình xác thực. Vào thời điểm đó, hầu hết trạng thái có thể chỉ được lưu trữ bởi: các nhà xây dựng khối; các nhà cung cấp dịch vụ RPC; và các nhà điều hành chuyên biệt khác (chẳng hạn như các công cụ tìm kiếm MEV và các công cụ khám phá khối). Nói cách khác, trạng thái sẽ trở nên tập trung hơn. Điều này sẽ dẫn đến nhiều hậu quả: Khó khăn hơn trong việc đồng bộ hóa: Các nhà cung cấp dịch vụ tập trung có thể bắt đầu hạn chế quyền truy cập vào trạng thái, gây khó khăn cho các nhà cung cấp dịch vụ mới; Khả năng chống kiểm duyệt suy yếu: Nếu không thể lấy được dữ liệu trạng thái bị kiểm duyệt, các cơ chế chống kiểm duyệt như FOCIL có thể thất bại; Rủi ro về khả năng phục hồi hệ thống: Nếu chỉ một vài thực thể lưu trữ và cung cấp trạng thái đầy đủ, việc gián đoạn dịch vụ hoặc áp lực bên ngoài sẽ nhanh chóng cắt đứt quyền truy cập vào hầu hết các thành phần của hệ sinh thái. Ngay cả khi nhiều thực thể lưu trữ trạng thái, vẫn thiếu các cách hiệu quả để xác minh rằng chúng thực sự đang cung cấp dịch vụ, và các động lực hiện có là không đủ. Đồng bộ hóa ảnh chụp nhanh được hỗ trợ rộng rãi theo mặc định, nhưng điều này không đúng với các dịch vụ RPC. Nếu chi phí dịch vụ nhà nước không được giảm và sức hấp dẫn chung của chúng không được tăng lên, khả năng truy cập vào trạng thái của chính mạng lưới sẽ bị hạn chế đối với một vài nhà cung cấp dịch vụ. Vấn đề này cũng ảnh hưởng đến mạng lưới Lớp 2. Khả năng người dùng buộc đóng gói giao dịch phụ thuộc vào việc truy cập đáng tin cậy vào trạng thái của hợp đồng Rollup trên L1. Nếu việc truy cập trạng thái L1 trở nên dễ bị tổn thương hoặc tập trung cao độ, các cơ chế van an toàn này sẽ khó hoạt động trong thực tế.

3、Ba hướng chính mà chúng tôi nhận thấy

(1) Thời hạn hiệu lực của trạng thái

Không phải tất cả dữ liệu trạng thái đều có tầm quan trọng lâu dài như nhau. Phân tích gần đây của chúng tôi cho thấy khoảng 80% dữ liệu trạng thái đã không được truy cập trong hơn một năm. Tuy nhiên, các nút vẫn phải chịu chi phí lưu trữ các trạng thái này vĩnh viễn.

Ý tưởng cốt lõi của cơ chế thời hạn hiệu lực trạng thái là tạm thời loại bỏ các trạng thái không hoạt động khỏi "tập hợp hoạt động" và khôi phục chúng thông qua một số hình thức chứng minh khi cần thiết.

Tóm lại, chúng có thể được chia thành hai loại chính: Loại thứ nhất: Đánh dấu, Vô hiệu hóa và Khôi phục. Thay vì coi tất cả các trạng thái là hoạt động vĩnh viễn, giao thức đánh dấu các trạng thái ít được sử dụng là không hoạt động, loại bỏ chúng khỏi tập hợp hoạt động do mỗi nút duy trì, đồng thời cho phép chúng được khôi phục trong tương lai thông qua bằng chứng về sự tồn tại trong quá khứ của chúng. Hiệu quả thực tế là các hợp đồng và số dư được sử dụng thường xuyên vẫn hoạt động với chi phí truy cập thấp, trong khi các trạng thái bị lãng quên từ lâu không cần phải được mỗi nút duy trì liên tục và vẫn có thể được gọi lại khi cần thiết. Loại thứ hai: Cơ chế vô hiệu hóa đa kỳ. Trong thiết kế đa kỳ, chúng ta không đặt vô hiệu hóa cho từng mục riêng lẻ, mà chia trạng thái định kỳ thành các kỳ (ví dụ: một kỳ = một năm). Khoảng thời gian hiện tại ngắn hơn và hoàn toàn hoạt động, trong khi các khoảng thời gian cũ hơn bị đóng băng từ góc độ thực thi thời gian thực, và các trạng thái mới được ghi vào khoảng thời gian hiện tại. Các trạng thái cũ chỉ có thể được khôi phục bằng cách chứng minh sự tồn tại của chúng trong các khoảng thời gian trước đó. Cơ chế đánh dấu-vô hiệu hóa-khôi phục thường được tinh chỉnh hơn và quá trình khôi phục trực tiếp hơn, nhưng quá trình đánh dấu yêu cầu lưu trữ siêu dữ liệu bổ sung. Vô hiệu hóa nhiều chu kỳ đơn giản hơn về mặt khái niệm và được tích hợp tự nhiên hơn với các cơ chế lưu trữ, nhưng bằng chứng khôi phục thường phức tạp và đồ sộ hơn. Cuối cùng, cả hai loại giải pháp đều có cùng mục tiêu—giữ cho trạng thái hoạt động được sắp xếp hợp lý bằng cách tạm thời loại bỏ các phần không hoạt động trong khi cung cấp đường dẫn khôi phục—nhưng chúng thực hiện các sự đánh đổi khác nhau về độ phức tạp, trải nghiệm người dùng và phân bổ khối lượng công việc cho máy khách và cơ sở hạ tầng. (2) Lưu trữ trạng thái Lưu trữ trạng thái phân biệt các trạng thái thành trạng thái lạnh và trạng thái nóng. Trạng thái nóng là các phần của mạng cần được truy cập thường xuyên; trạng thái lạnh là các phần vẫn quan trọng đối với hồ sơ lịch sử và khả năng xác minh nhưng hiếm khi được sử dụng. Trong thiết kế lưu trữ trạng thái, các nút lưu trữ rõ ràng các trạng thái nóng được sử dụng thường xuyên và dữ liệu lịch sử một cách riêng biệt. Ngay cả khi trạng thái tổng thể tiếp tục phát triển, phần cần được truy cập nhanh chóng (các tập dữ liệu nóng) vẫn có thể duy trì ở kích thước hạn chế. Trên thực tế, điều này có nghĩa là hiệu suất của nút—đặc biệt là chi phí I/O để truy cập trạng thái—về cơ bản có thể ổn định theo thời gian, mà không bị suy giảm theo tuổi của chuỗi. (3) Giảm rào cản gia nhập đối với lưu trữ và dịch vụ trạng thái. Một câu hỏi hiển nhiên là: Chúng ta có thể đạt được mục tiêu của mình trong khi nắm giữ ít dữ liệu hơn không? Nói cách khác, chúng ta có thể thiết kế các nút và ví không cần lưu trữ vĩnh viễn toàn bộ trạng thái và vẫn có thể là những người tham gia hiệu quả không? Một hướng đi đầy hứa hẹn là các giải pháp bán trạng thái: Các nút chỉ lưu trữ và cung cấp trạng thái một phần (chẳng hạn như dữ liệu liên quan đến người dùng hoặc ứng dụng cụ thể); Ví và các máy khách nhẹ đóng vai trò chủ động hơn trong việc lưu trữ và lưu vào bộ nhớ đệm các mảnh trạng thái cần thiết, thay vì hoàn toàn dựa vào một vài nhà cung cấp dịch vụ RPC lớn. Nếu việc lưu trữ có thể được phân phối an toàn trên các ví và các nút chuyên biệt, gánh nặng cho các nhà điều hành riêng lẻ sẽ giảm đi và cộng đồng người nắm giữ trạng thái sẽ trở nên đa dạng hơn. Một hướng đi khác là giảm rào cản gia nhập để vận hành cơ sở hạ tầng hữu ích: Đơn giản hóa quy trình triển khai các nút RPC chỉ phục vụ trạng thái một phần; Thiết kế các giao thức và công cụ cho phép ví và ứng dụng khám phá và tích hợp nhiều nguồn dữ liệu một phần, thay vì chỉ dựa vào một điểm cuối RPC hoàn chỉnh duy nhất.

4, Hướng đi Tương lai

Trạng thái của Ethereum đang âm thầm trở thành chìa khóa cho một số vấn đề cốt lõi đối với tương lai của giao thức:

Kích thước của trạng thái sẽ trở thành rào cản tham gia đến mức nào?

Khi các trình xác thực có thể xác minh các khối một cách an toàn mà không cần trạng thái, ai sẽ lưu trữ trạng thái?

Ai sẽ cung cấp dịch vụ trạng thái cho người dùng? Động lực thúc đẩy sẽ là gì?

Một số câu hỏi vẫn chưa được giải quyết, nhưng hướng đi đã rõ ràng: giảm bớt các ràng buộc của trạng thái đối với hiệu suất, giảm chi phí lưu trữ và cải thiện khả năng truy cập dịch vụ.

Trọng tâm hiện tại của chúng tôi là thúc đẩy các sáng kiến ​​rủi ro thấp, lợi nhuận cao: **Các lược đồ lưu trữ** Chúng tôi đang khám phá các giải pháp ngoài giao thức để kiểm soát quy mô trạng thái hoạt động trong khi dựa vào các lược đồ lưu trữ để lưu trữ dữ liệu lịch sử. Điều này sẽ cung cấp dữ liệu thực tế về hiệu suất, trải nghiệm người dùng và độ phức tạp vận hành. Nếu được chứng minh là hiệu quả, nó có thể được thúc đẩy như một bản nâng cấp trong giao thức nếu cần thiết. **Các nút bán trạng thái và cải tiến RPC** Hầu hết người dùng và ứng dụng tương tác với Ethereum thông qua các nhà cung cấp dịch vụ RPC tập trung. Chúng tôi đang nỗ lực thực hiện các cải tiến sau: **Giảm độ khó và chi phí vận hành các node, ngay cả khi các node không lưu trữ toàn bộ trạng thái;** **Cho phép nhiều node cùng nhau cung cấp dịch vụ trạng thái hoàn chỉnh;** **Tăng tính đa dạng của các nhà cung cấp dịch vụ RPC để tránh các điểm lỗi đơn lẻ.** Các dự án này được lựa chọn cẩn thận dựa trên sự kết hợp giữa tính khả thi tức thời và khả năng tương thích trong tương lai: chúng có thể vừa cải thiện tình trạng hiện tại của Ethereum vừa đặt nền tảng cho các nâng cấp giao thức sâu rộng hơn trong tương lai.