Tác giả: Wei Han Ng, Carlos Pérez, Đội ngũ nghiên cứu về sự đồng thuận phi quốc gia; Người dịch: Jinse Finance
Ethereum đã phát triển từ một mạng lưới nhỏ, mang tính thử nghiệm thành một thành phần quan trọng của cơ sở hạ tầng toàn cầu. Nó quyết toán 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óm lại, tất cả điều này đều phụ thuộc vào một thành phần cốt lõi: trạng thái .
1. " Nhà nước " là gì và tầm quan trọng của nó ra sao?
Số dư của người dùng không được lưu trữ trong ví của họ, mà được lưu trữ trong trạng thái Ethereum. Trạng thái này có thể được hiểu một cách khái quát 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 của hầu hết mọi chức năng:
Ví điện tử dựa vào đó để 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 về vị thế giữ hiện có, các lệnh hoặc tin nhắn của chúng;
Cơ sở hạ tầng (Block Explorer, cầu nối xuyên chuỗi, 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 nhà nước trở nên quá lớn, quá tập trung quyền lực, hoặc không thể cung cấp các dịch vụ cần thiết, tất cả các tầng lớp nêu trên sẽ trở nên dễ tổn thương hơn, tốn kém hơn và khó phi tập trung hơn.
2. Mở rộngL1 sẽ dẫn đến những hệ quả tương ứng.
Ethereum đã nỗ lực mở rộng mạng lưới trong nhiều năm: thông qua các mạng Layer 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 và người xây dựng được 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 đến những thách thức mới.
Thử thách 1: Liên tục mở rộng đà phát triển
Kích thước trạng thái của Ethereum chỉ tăng lên, không bao giờ giảm xuống. Mỗi tài khoản mới, thao tác lưu trữ và ghi mã bytecode đều vĩnh viễn bổ sung thêm dữ liệu mà mạng lưới phải lưu giữ.
Điều này phát sinh những chi phí cụ thể:
Các trình xác thực và 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 phải xử lý khối lượng công việc bổ sung, và hiệu suất của nó sẽ giảm theo.
Các nhà cung cấp dịch vụ RPC phải duy trì khả năng truy cập đầy đủ, đả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.
Tăng trưởng của các bang hội dẫn đến tốc độ đồng bộ hóa nút chậm hơn và độ ổn định giảm.
Việc 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. Chuỗi công khai khác đã gặp phải vấn đề này. Khi kích thước trạng thái tăng lên, người dùng thông thường khó có thể vận hành 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 những người xây dựng chuyên nghiệp. Mối quan ngại cốt lõi là có bao nhiêu thực thể độc lập vẫn có thể hoàn thành quá trình 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 trạng thái hoàn chỉnh, 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 — bở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 yếu tố tích cực là các cơ chế như FOCIL và VOPS nhằm đảm bảo khả năng chống kiểm duyệt trong hệ sinh thái của các nhà phát triển chuyên nghiệp. Tuy nhiên, hiệu quả của chúng vẫn phụ thuộc vào một hệ sinh thái nút lành mạnh, nơi 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 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 mấu chốt của vấn đề, chúng tôi đang tích cực tiến hành các bài kiểm tra khả năng chịu tải:
Khi nào thì tăng trưởng của một tiểu bang trở thành nút thắt cổ chai mở rộng?
Khi nào kích thước trạng thái khiến nút khó theo kịp nút đầu Chuỗi?
Việc triển khai máy trạm sẽ thất bại khi nào trong điều kiện quy mô trạng thái cực lớn?
Thử thách 2: Trong một 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ì mức phí gas hiện tại, chúng ta cuối cùng cũng sẽ gặp phải vấn đề phình to trạng thái. Trong khi đó, cộng đồng rõ ràng kỳ vọng thông lượng cao hơn.
Phương pháp không lưu trữ trạng thái loại bỏ một hạn chế lớn: các trình 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, mà chỉ cần bằng chứng. Đây là một bước đột phá đáng kể 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 khẳng định – 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 thông tin về trạng thái có thể chỉ được lưu trữ bởi các thực thể sau:
Công cụ xây dựng khối;
Nhà cung cấp dịch vụ RPC;
Các nhà khai thác chuyên biệt khác (chẳng hạn như các nhà tìm kiếm MEV và Block Explorer).
Nói cách khác, nhà nước sẽ trở nên tập trung hơn.
Điều này sẽ dẫn đến nhiều hậu quả:
Việc đồng bộ hóa trở nên khó khăn hơn: 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 hệ thống, khiến cho các nhà cung cấp dịch vụ mới khó có thể bắt đầu hoạt động;
Khả năng chống lại kiểm duyệt giảm: Nếu không thể thu thập được dữ liệu về tình trạng cần kiểm duyệt, các cơ chế chống kiểm duyệt như FOCIL có thể trở nên không hiệu quả.
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 đủ, sự gián đoạn dịch vụ hoặc tác động từ bên ngoài sẽ nhanh chóng làm gián đoạn quyền truy cập vào hầu hết các thành phần của hệ sinh thái.
Mặc dù nhiều thực thể lưu trữ trạng thái, nhưng vẫn thiếu các phương pháp hiệu quả để xác minh rằng chúng thực sự đang cung cấp dịch vụ, và khích lệ 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. Trừ khi chi phí của các dịch vụ trạng thái được giảm xuống và sức hấp dẫn chung của chúng được tăng lên, khả năng truy cập trạng thái của chính các mạng sẽ bị hạn chế chỉ ở một vài nhà cung cấp dịch vụ.
Vấn đề này cũng ảnh hưởng đến các mạng Lớp 2. Khả năng buộc đóng gói giao dịch của người dùng 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 Lớp 1. Nếu việc truy cập trạng thái L1 trở nên dễ bị lỗi hoặc tập trung hóa cao độ, các cơ chế van an toàn này sẽ khó vận hành trong thực tế.
3. Ba hướng chính mà chúng ta 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 quan trọng như nhau trong thời gian vô hạn. 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, nút vẫn phải chịu chi phí lưu trữ trạng thái này vĩnh viễn.
Ý tưởng cốt lõi của các cơ chế hết hạn 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 trạng thái 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. Nhìn chung, chúng có thể được chia thành hai loại chính:
Thể loại 1: Đánh dấu, Hết hạn, Phục sinh
Giao thức này không còn coi tất cả các trạng thái là hoạt động vĩnh viễn nữa. Thay vào đó, đá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 trạng thái hoạt động được duy trì bởi mỗi nút, đồng thời cho phép chúng được khôi phục trong tương lai thông qua bằng chứng lịch sử về sự tồn tại. 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 duy trì liên tục bởi mỗi nút và vẫn có thể được khôi phục khi cần thiết.
Loại 2: Cơ chế hỏng hóc đa chu kỳ
Trong thiết kế đa chu kỳ, thay vì vô hiệu hóa từng mục riêng lẻ, chúng ta định kỳ chia trạng thái thành các chu kỳ (ví dụ: một chu kỳ = một năm). Chu kỳ hiện tại nhỏ và hoạt động hoàn toàn, trong khi các chu kỳ 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 chu kỳ 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 chu kỳ trước đó.
Cơ chế đánh dấu- vô hiệu hóa - khôi phục nhìn chung phức tạp 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ữ thêm dữ liệu. Vô hiệu hóa nhiều chu kỳ đơn giản hơn về mặt khái niệm và 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 hơn và có kích thước lớn hơn.
Tóm lại, cả hai phương pháp đều có chung mục tiêu là duy trì sự tinh gọn của các thành phần hoạt động bằng cách tạm thời loại bỏ các phần không hoạt động trong khi vẫn cung cấp cách để khôi phục chúng – nhưng chúng lại có những sự đánh đổi khác nhau về độ phức tạp, trải nghiệm người dùng và việc phân bổ khối lượng công việc cho máy trạm và cơ sở hạ tầng.
(2) Lưu trữ trạng thái
Hệ thống lưu trữ của tiểu bang phân loại các tiểu bang thành các tiểu bang "lạnh" và "nóng".
Trạng thái "nóng" là phần của mạng cần được truy cập thường xuyên;
Trạng thái lạnh đề cập đến phần lịch sử sơ và khả năng kiểm chứng vẫn còn quan trọng nhưng hiếm khi được sử dụng.
Trong thiết kế lưu trữ trạng thái, nút lưu trữ riêng biệt các trạng thái thường xuyên sử dụng ( dữ liệu "nóng") khỏi dữ liệu lịch sử . Ngay cả khi trạng thái tổng thể tiếp tục tăng trưởng , các phần yêu cầu truy cập nhanh (tập dữ liệu "nóng") vẫn có kích thước hữu hạn. Trên thực tế, điều này có nghĩa là hiệu suất thực thi của nút —đặc biệt là chi phí I/O khi truy cập trạng thái—vẫn tương đối ổn định theo thời gian và không tăng trưởng theo giảm Chuỗi .
(3) Hạ thấp rào cản gia nhập đối với kho lưu trữ và dịch vụ của nhà nước
Một câu hỏi hiển nhiên là: Liệu chúng ta có thể đạt được mục tiêu trong khi lưu trữ ít dữ liệu hơn không? Nói cách khác, liệu chúng ta có thể thiết kế nút và ví điện tử vẫn hoạt động hiệu quả mà không cần lưu trữ vĩnh viễn toàn bộ trạng thái?
Một hướng đi đầy triển vọng là các giải pháp bán phi trạng thái:
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 một người dùng hoặc ứng dụng cụ thể).
Ví điện tử và máy trạm đơn giản đóng nhân vật chủ động hơn trong việc lưu trữ và 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. Bằng cách phân phối lưu trữ an toàn trên các ví điện tử và nút chuyên biệt, gánh nặng cho từng nhà điều hành sẽ được giảm bớt, và cộng đồng người nắm giữ trạng thái sẽ trở nên đa dạng hơn.
Một cách tiếp cận khác là giảm bớt rào cản gia nhập thị trường để vận hành cơ sở hạ tầng hữu ích:
Đơn giản hóa quy trình triển khai nút RPC chỉ phục vụ một phần trạng thái;
Thiết kế các giao thức và công cụ để cho phép ví điện tử và ứng dụng khám phá và tích hợp nhiều nguồn dữ liệu cục bộ, thay vì chỉ dựa vào một điểm cuối RPC hoàn chỉnh duy nhất.
4. Định hướng tương lai
Tình trạng hiện tại của Ethereum đang âm thầm trở thành yếu tố then chốt đối với một số vấn đề cốt lõi ảnh hưởng đến tương lai của giao thức này:
Đến mức nào thì tăng trưởng mô của một quốc gia trở thành rào cản đối với sự tham gia?
Khi trình xác thực có thể xác minh một khối một cách an toàn mà không cần trạng thái, thì ai sẽ lưu trữ trạng thái đó?
Ai sẽ cung cấp dịch vụ cập nhật trạng thái cho người dùng? Sẽ có khích lệ gì?
Một số vấn đề vẫn chưa được giải quyết, nhưng hướng đi đã rõ ràng: giảm thiểu ảnh hưởng của trạng thái hệ thống đến hiệu năng, 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:
Kế hoạch lưu trữ
Chúng tôi đang nghiên cứu một 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 một lược đồ lưu trữ để lưu giữ 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 đưa vào như một nâng cấp trong giao thức nếu cần thiết.
Một số nút không 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 nút, ngay cả khi nút không lưu trữ tất cả trạng thái;
Cho phép nhiều nút cộng tác để cung cấp các dịch vụ trạng thái hoàn chỉnh;
Tăng cường sự đa dạng của các nhà cung cấp dịch vụ RPC để tránh tình trạng tắc nghẽn tại một điểm duy nhất.
Các dự án này được lựa chọn cẩn thận vì chúng kết hợp tính khả thi tức thời với 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 nâng cấp giao thức sâu rộng hơn trong tương lai.
