Khi hệ thống Ethereum ngày càng khó sử dụng, Buterin có giải pháp gì?
Tiêu đề gốc: "Ý kiến| Đề xuất quản lý quy mô trạng thái Ethereum"
Tác giả gốc: Vitalik Buterin
Bản dịch gốc: Một người đam mê Ethereum, Jian
Một trong những thách thức dai dẳng và chưa được giải quyết nhất mà giao thức Ethereum phải đối mặt là vấn đề do kích thước dữ liệu trạng thái ngày càng tăng. Nhiều hoạt động trên chuỗi khối Ethereum (tạo tài khoản, ghi vào khe lưu trữ hợp đồng, gửi ETH đến tài khoản mới...) sẽ thêm nội dung trạng thái vào Ethereum (nghĩa là thêm đối tượng dữ liệu vào dữ liệu trạng thái) và Tất cả đều đầy đủ các nút phải lưu trữ toàn bộ lượng dữ liệu trạng thái để chúng có thể xác minh các khối mới và tạo các khối mới. Các hoạt động này chỉ yêu cầu người gửi giao dịch phải trả phí xử lý một lần được tính bằng mức sử dụng Gas, nhưng sẽ gây ra chi phí liên tục vĩnh viễn cho toàn bộ mạng vì các nút cần lưu trữ những dữ liệu mới này (và các nút tham gia trong tương lai cũng vậy). cần đồng bộ hóa quá trình để tải xuống dữ liệu này).
Đây là sự mất cân bằng đáng kể trong thiết kế hệ thống và có thể khiến hệ thống Ethereum ngày càng khó sử dụng vì trạng thái chứa đầy thông tin không còn tồn tại. "Dữ liệu rác" hữu ích. Mục đích của bài viết này là giải thích chi tiết nguồn gốc của vấn đề cũng như một số cách giải quyết. Nếu chúng ta có thể thực hiện một giải pháp, điều này sẽ mở đường cho việc tăng giới hạn gas khối một cách an toàn và đáng kể.
Lĩnh vực nghiên cứu được thảo luận trong bài viết này vẫn đang được tiến hành và những ý tưởng mới hơn, tốt hơn cũng như những sự đánh đổi hợp lý hơn có thể xuất hiện bất cứ lúc nào.
Giới thiệu: Vấn đề là gì?
"Trạng thái" đề cập đến thông tin mà các nút phải lưu trữ nếu chúng muốn xử lý các khối và giao dịch mới được tạo. Trạng thái hoàn toàn khác với "lịch sử", là thông tin về quá khứ mà các nút có thể lưu để phát lại hoặc lưu trữ sau này, nhưng không bắt buộc phải xử lý chuỗi khối.
Trong giao thức Ethereum, thông tin trạng thái bao gồm:
· Số dư ETH của tài khoản ;và nonce (số sê-ri)
·Mã hợp đồng thông minh
·Các mục lưu trữ hợp đồng thông minh (bộ nhớ)
·Liên quan đến cơ chế đồng thuận Dữ liệu (băm khối gần đây, khối chú; dữ liệu đồng thuận cho bằng chứng cổ phần cũng bao gồm khóa công khai của người xác nhận và các hoạt động của nó được ghi lại trên chuỗi beacon, v.v.)
Thông tin lịch sử bao gồm các khối cũ và biên lai. Không có opcode nào trong EVM cho phép bạn truy cập các khối cũ, giao dịch cũ, nội dung và đầu ra biên nhận, vì vậy các nút có thể loại bỏ dữ liệu này và vẫn xác minh các khối mới, vì vậy đây là thông tin lịch sử.
Mục cuối cùng trong danh sách thông tin trạng thái trên - dữ liệu liên quan đến cơ chế đồng thuận - đã được thiết kế giới hạn kích thước một cách cẩn thận nên chúng ta không cần phải lo lắng về nó . Nhưng ba mục đầu tiên khiến bạn đau đầu. Quy mô của ba loại thông tin trạng thái này sẽ tiếp tục tăng theo thời gian, bởi vì người dùng mới sẽ tiếp tục tham gia mạng. Họ sẽ tạo tài khoản mới, hợp đồng mới, tham gia hợp đồng, nhận mã thông báo, v.v.
Điều khó khăn là nhiều trạng thái sẽ nằm yên ở đó sau khi được sử dụng (sẽ không được chạm vào nữa); một khi người dùng tắt một trạng thái nhất định, Sau một ứng dụng; , một số "trạng thái rác" sẽ được tạo ra - nó sẽ không được sử dụng nữa nhưng sẽ ở đó mãi mãi.
Về mặt lý thuyết, người dùng có thể giữ rác không rơi xuống đất. Người dùng chỉ có thể xuất bản hợp đồng với các điều kiện SELFDESTRUCT và khi họ không cần hợp đồng nữa, hãy gọi mã hoạt động này để xóa hợp đồng và xóa số dư mã thông báo của nó; họ cũng có thể sử dụng ví hợp đồng thông minh để sử dụng tài khoản nắm giữ bên ngoài hiện có (EOA) để gửi giao dịch mà không tạo EOA mới (không thể xóa trạng thái EOA).
Nhưng trên thực tế, có rất ít động cơ khuyến khích như vậy và độ phức tạp về mặt kỹ thuật của việc dọn dẹp trạng thái phù hợp là quá lớn. Trong nhiều hợp đồng, việc cấp cho bất kỳ ai quyền gọi SELFDESTRUCT theo cách này là không phù hợp (điều mọi người muốn là một ứng dụng "không thể thành công"!), và nó cũng sẽ làm tăng trải nghiệm người dùng và mã rất phức tạp. Trên thực tế, vì SELFDESTRUCT có mức độ hữu ích cực kỳ hạn chế và tác dụng phụ nghiêm trọng, tôi muốn loại bỏ opcode này mãi mãi. Nếu chúng ta thực sự muốn kiểm soát kích thước của dữ liệu trạng thái, điều chúng ta cần là một cách để các nút trong mạng loại bỏ "trạng thái rác" theo mặc định không còn được sử dụng.
Khách hàng không quốc tịch
Một loại giải pháp cho vấn đề này là dựa trên "Khách hàng không quốc tịch " End" (bài viết này là nguồn gốc của khái niệm này, đây là video bài phát biểu). Nguyên tắc cơ bản là làm cho việc xác minh khối không còn là tiền đề để giữ trạng thái toàn cầu. Thay vào đó, các khối đi kèm với bằng chứng (hoặc “nhân chứng”) của riêng họ để chứng minh giá trị của trạng thái mà họ truy cập. Giống như thiết kế hiện tại, khối sẽ chứa một "gốc trạng thái" và giá trị truy cập có thể được chứng minh tương ứng với gốc trạng thái (Lưu ý của người dịch: Bằng chứng Merkel là một công nghệ chứng minh phổ biến). Sơ đồ cây trạng thái hiện tại của Ethereum (cây Merkle Patricia) hỗ trợ công nghệ chứng minh như vậy và các sơ đồ hiệu quả hơn như cây nhị phân hoặc Verkle Tries cũng có thể được sử dụng. Dữ liệu nhân chứng cũng chứng minh tính đúng đắn của trạng thái gốc mới sau khi xử lý khối.
Tình trạng không quốc tịch có hai dạng:
· Tình trạng không quốc tịch yếu: nhà sản xuất khối vẫn cần phải ở trạng thái hoàn chỉnh để tạo dữ liệu chứng kiến cho khối (do chính bạn thực hiện); nhưng giai đoạn xác minh khối có thể không có trạng thái;
· Không có trạng thái mạnh mẽ: Không có nút nào yêu cầu bàn xoay hoàn chỉnh . Đổi lại, người gửi giao dịch cần cung cấp dữ liệu nhân chứng và nhà sản xuất khối có thể tổng hợp dữ liệu này. Người gửi giao dịch chịu trách nhiệm lưu trữ phần cây trạng thái cần thiết để tạo dữ liệu chứng thực cho tài khoản được đề cập.
Không trạng thái mạnh mẽ là một giải pháp rất "tinh tế" vì nó chuyển giao hoàn toàn trách nhiệm cho người dùng, mặc dù để đảm bảo trải nghiệm người dùng tốt trong thực tế, chúng ta cần phải tạo một số loại giao thức để giúp người dùng không chạy các nút cá nhân duy trì trạng thái và xử lý các tình huống mà người dùng cần tương tác với các tài khoản không mong muốn. Việc tạo ra một thỏa thuận như vậy là rất khó khăn.
Ngoài ra, tất cả các loại trạng thái không quốc tịch đều làm tăng băng thông dữ liệu mà mạng yêu cầu; tình trạng không quốc tịch mạnh cũng yêu cầu các giao dịch phải khai báo các tài khoản mà họ tương tác và chìa khóa để lưu trữ. mục đó (về mặt khái niệm, đây được gọi là "danh sách truy cập").
Một giải pháp nhẹ nhàng hơn: trạng thái hết hạn
Một giải pháp nhẹ nhàng hơn là Có nhiều hình thức khác nhau các giải pháp "hết hạn trạng thái". Trạng thái phải truy cập liên tục có thể duy trì "trạng thái kích hoạt"; trạng thái không được giám sát trong một thời gian dài sẽ trở thành "không hoạt động" (hoặc "hết hạn"). Có nhiều tùy chọn về việc sử dụng chính xác cơ chế nào để cập nhật trạng thái (chẳng hạn như trả trước "tiền thuê" hoặc đơn giản là truy cập trạng thái đó), nhưng quy tắc chung là trừ khi một đối tượng trạng thái được cập nhật rõ ràng, nếu không nó sẽ ở một dạng thất bại nào đó. trạng thái sống. Do đó, bất kỳ hoạt động nào tạo ra các đối tượng trạng thái mới (và cập nhật các đối tượng trạng thái hiện có) sẽ chỉ là gánh nặng cho nút trong một khoảng thời gian chứ không trở thành gánh nặng vĩnh viễn như hiện tại.
Trạng thái không hoạt động, như tên cho thấy, không phải là một phần của các nút "trạng thái"; các nút muốn xử lý khối hoặc tạo khối không cần lưu trữ trạng thái không hoạt động. Tuy nhiên, trạng thái ngừng hoạt động không bị xóa hoàn toàn! Trong tất cả các loại đề xuất hết hạn trạng thái, một số phương pháp được đặt trước để "phục hồi" trạng thái đã ngừng hoạt động.
Nguyên tắc chung là trạng thái hoạt động được sử dụng giống như trạng thái hiện tại, còn trạng thái không hoạt động cần được sử dụng thông qua trạng thái không trạng thái nêu trên cơ chế khách hàng Một giao dịch phục hồi một đối tượng ở trạng thái hết hạn cần cung cấp bằng chứng (dữ liệu chứng kiến) rằng đối tượng đó là một phần của trạng thái ngừng hoạt động. Để có thể tạo ra bằng chứng như vậy, bản thân người dùng cần lưu trữ và duy trì ít nhất một phần trạng thái bị vô hiệu hóa (phần tương ứng với đối tượng trạng thái bị vô hiệu hóa mà anh ta quan tâm).
Khi nào hết hạn
Có nhiều thiết kế để xác định điều kiện hết hạn. Những cái phổ biến nhất là:
· Tiền thuê trực tiếp: "Tiền thuê" được thu theo từng khối và thanh toán trực tiếp bằng số dư của từng tài khoản (hoặc đối tượng nhà nước khác); 0, Tài khoản đã hết hạn.
· Giá trị thời gian tồn tại còn lại: Mỗi đối tượng trạng thái lưu trữ một giá trị "thời gian tồn tại còn lại", giá trị này có thể tăng lên bằng cách trả phí.
· Làm mới khi chạm: Mỗi đối tượng trạng thái lưu trữ một giá trị "thời gian tồn tại còn lại" và giá trị này sẽ tăng lên mỗi khi tài khoản được đọc hoặc ghi.
· Tất cả các đối tượng trạng thái đều hết hạn theo định kỳ (ví dụ: 6 tháng một lần): hay còn gọi là đề xuất ReGenesis.
Bản thân tôi ngày càng thích giải pháp "chạm và làm mới" hơn, vì (1) nó tránh được việc các ứng dụng phải tạo ra các mô hình kinh tế phức tạp để cho phép người dùng giả sử trạng thái Rent; và (2) nó đảm bảo rằng kích thước của trạng thái kích hoạt có giới hạn trên rõ ràng (giới hạn trên của khối Gas / Mức tiêu thụ gas của đối tượng trạng thái chạm vào × khoảng thời gian trạng thái tồn tại). Sơ đồ hết hạn một số lượng lớn trạng thái theo các khoảng thời gian đều đặn (tức là ReGenesis) có cùng lợi ích, nhưng cũng có một số đánh đổi thú vị: lợi ích chính là sơ đồ hết hạn đơn giản hơn (không cần duyệt toàn bộ cây trạng thái và hủy kích hoạt từng trạng thái) đối tượng), nhưng thiếu sót chính là sau khi vượt qua điểm hết hạn, khi bạn kích hoạt đối tượng trạng thái của mình, lượng dữ liệu nhân chứng cần thiết sẽ liên quan đến thời điểm bạn chạm vào đối tượng trạng thái.
Hết hạn ở cấp tài khoản so với hết hạn ở cấp khe lưu trữ
Logic của trạng thái hết hạn là cả hai. Nó có thể được vận hành ở cấp tài khoản hoặc ở cấp khe lưu trữ riêng lẻ. Hiện tại, tôi thực sự thích triển khai hết hạn trạng thái ở cấp độ vị trí. Vì số lượng chỗ lưu trữ trong nhiều tài khoản hợp đồng là không giới hạn nên bất kỳ người dùng nào cũng có thể tham gia hợp đồng và tăng số lượng chỗ lưu trữ theo hợp đồng (ví dụ: airdrop là trường hợp đã xảy ra). Bất kể sơ đồ hết hạn của lớp tài khoản được sử dụng là gì, để hạn chế kích thước trạng thái một cách hiệu quả, số tiền thuê phải tỷ lệ thuận với số lượng vị trí lưu trữ trong hợp đồng (hoặc thời gian tồn tại tỷ lệ nghịch với nó). Do đó, người dùng vẫn chỉ có thể trả khoản phí một lần và áp dụng các chi phí liên tục vĩnh viễn đối với hợp đồng và người dùng hợp đồng.
Để giải quyết vấn đề này, hợp đồng phải thêm logic phức tạp bên trong để "chuyển" tiền thuê hoạt động lưu trữ cho người dùng hoặc thiết kế lại mô hình hợp đồng của chính mình và chuyển sang sử dụng opcode CREATE2 để tạo một hợp đồng mới và cách sử dụng. Các hợp đồng này đóng vai trò là nơi lưu trữ. Bất kể phương pháp nào được sử dụng, cuối cùng nó sẽ trở nên tương đương với gói hết hạn ở cấp độ khe lưu trữ. Vì vậy, cá nhân tôi tin rằng chúng ta chỉ nên triển khai kế hoạch hết hạn trạng thái ở cấp độ khe lưu trữ hợp đồng.
Tuy nhiên, sơ đồ hết hạn ở cấp độ khe lưu trữ cũng có những thiếu sót riêng: mỗi khe lưu trữ cần thêm siêu dữ liệu cho biết khi nào nó hết hạn (hoặc đã hết hạn hay chưa). bị vô hiệu hóa), điều này cũng có nghĩa là "vấn đề xung đột hồi sinh" (xem bên dưới) sẽ không chỉ ảnh hưởng đến tài khoản mà còn cả khe lưu trữ.
Xóa khỏi cây trạng thái so với sắp xếp một phần "nghỉ hưu" của cây trạng thái
Một điểm khác biệt nữa khía cạnh kỹ thuật của các đề xuất hết hạn trạng thái khác nhau là "luồng một cây" và "luồng hai cây". Nói cách khác, chúng ta chỉ có một cây trạng thái như hiện tại mà chỉ đánh dấu một số trạng thái nhất định là đã hết hạn hay chúng ta trực tiếp loại bỏ trạng thái không hoạt động khỏi cây trạng thái chính và chuyển nó sang một cây chuyên dụng khác ( trên một cây khác; data) chỉ chứa trạng thái đã hết hạn?
一树流
Các nút đang hoạt động được đánh dấu bằng màu trắng và các nút không hoạt động được đánh dấu bằng màu xám
Lưu ý rằng ngay cả các nút trung gian trong cây cũng sẽ được đánh dấu là đang hoạt động hoặc bị kích hoạt sai (hoặc thực tế hơn là mỗi nút sẽ được đánh dấu bằng ngày ngừng hoạt động , do đó có thể dễ dàng kiểm tra độ sống của nó); việc đánh dấu có thể được thực hiện tại mỗi nút (nút lá và nút trung gian) trong cây trạng thái.
Hai luồng cây
Cây màu trắng chứa trạng thái kích hoạt; cây màu xám lưu trữ trạng thái không hoạt động
Một Ưu điểm của luồng cây là ít nhất, phương thức làm việc của nó sẽ trông giống với cây trạng thái hiện tại, đồng thời quá trình hủy kích hoạt và phục hồi cũng tương đối đơn giản: quá trình phục hồi chỉ cần làm mới tham số "ngày hết hạn" của các nút có liên quan trong cây và mất đi. Công việc được tự động hóa. Nhưng nhược điểm của nó là nó yêu cầu cấu trúc cây có thể lưu trữ thông tin trung gian trong các nút theo cách này và không mở rộng tốt sang cây Verkle. Ngoài ra, nó còn yêu cầu thêm yếu tố Merkle proof, không chỉ có khả năng chìm xuống các nút lá mà còn có thể dừng ở các nút trung gian (khi cần chứng minh một phần nào đó của trạng thái đã hết hạn).
Ưu điểm của luồng nhị phân là các bộ tích lũy trạng thái thuần túy hiện tại có thể hỗ trợ loại lược đồ này mà không cần thêm siêu dữ liệu cho mỗi nút. Nhược điểm là nó yêu cầu một số thay đổi sâu hơn đối với toàn bộ giao thức và yêu cầu một quy trình rõ ràng để hủy kích hoạt trạng thái (vì vậy việc hết hạn không còn tự động nữa). Ngoài ra, nó không cung cấp giải pháp tích hợp cho tình huống khó xử xung đột hồi sinh (xem phần tiếp theo), vì vậy bạn cần phải lựa chọn giữa hai cách tiếp cận.
Lưu ý rằng trong luồng nhị phân, cấu trúc dữ liệu lưu trữ trạng thái không hoạt động không nhất thiết phải là một cây. Trên thực tế, hoàn toàn có thể có thiết kế như vậy: khi cần phục hồi một đối tượng trạng thái, bạn chỉ cần cung cấp cây Merkle trỏ đến biên nhận khi đối tượng bị vô hiệu hóa, sau đó đính kèm một số bằng chứng mật mã để chứng minh rằng đối tượng chưa có trước đây Nó đã được phục hồi (hoặc gần đây đã hết hạn).
Xung đột Phục sinh
Sau đó, chúng ta đi đến một vấn đề chính của kế hoạch hết hạn nhà nước: " Xung đột phục sinh". Khái niệm về xung đột hồi sinh như sau. Giả sử một tài khoản được tạo bởi địa chỉ A; tài khoản này hết hạn, sau đó, địa chỉ A sẽ tạo một tài khoản mới (ví dụ: sử dụng mã thao tác CREATE2 để đảm bảo rằng địa chỉ của các tài khoản được tạo hai lần cuối cùng giống nhau); Cố gắng khôi phục lại tài khoản ban đầu. Điều gì sẽ xảy ra vào lúc này?
Dưới đây là một số giải pháp khả thi:
1. Quy trình "Hợp nhất" tài khoản rõ ràng. : tương tự như quy định "ngoại trừ việc tích lũy số dư ETH của hai tài khoản, trạng thái của tài khoản cũ sẽ được ưu tiên" hoặc "ngoại trừ việc tích lũy số dư ETH, thậm chí trạng thái của tài khoản mới sẽ được ưu tiên"; có thể được thực hiện bằng tài khoản cũ. Mã hợp đồng của tài khoản để chỉ định quy trình hợp nhất đặc biệt
2. Đảm bảo rằng xung đột phục sinh sẽ không xảy ra bằng cách loại bỏ chức năng. triển khai lặp đi lặp lại cùng một địa chỉ: nghĩa là điều chỉnh các Hàm CREATE2, chẳng hạn như bao gồm thời gian hiện tại trong tiền ảnh dữ liệu cuối cùng được băm thành một địa chỉ, do đó, ngay cả khi cùng một dữ liệu được sử dụng để tạo ra nó trong tương lai, thì không thể lấy được cùng một địa chỉ
3. Thêm "sơ khai" vào đối tượng trạng thái để ngăn các tài khoản mới được tạo tại cùng một vị trí (một cây ở trên) flow phương thức này tự động thực hiện chức năng này)
4. Khi tạo một tài khoản mới, phải kèm theo bằng chứng cho thấy tài khoản chưa hết hạn trước đó: Theo một nghĩa nào đó, nó tương đương với giải pháp sơ khai, ngoại trừ phương pháp này đặt sơ khai ở một phần riêng biệt của trạng thái, vì vậy bất kỳ ai muốn tạo Người dùng tài khoản hợp đồng đều phải theo dõi phần trạng thái này
(Lưu ý rằng nếu chúng tôi sử dụng cơ chế hết hạn khe lưu trữ thì mọi giải pháp trên đều phải được mở rộng thành một cấp khe lưu trữ duy nhất chứ không chỉ ở cấp tài khoản)
Mối quan tâm chính là: (1) Nó sẽ tăng thêm độ phức tạp cho ứng dụng và họ cần thêm logic hợp nhất; (2) Sau khi thực hiện việc này, trừ khi một địa chỉ được "đăng ký" trên đó; chuỗi, người dùng sẽ không còn có thể dễ dàng lấy được địa chỉ mà họ có thể tương tác và tích lũy tài sản (chẳng hạn như mã thông báo ERC20). Địa chỉ chưa đăng ký rất quan trọng: bất kỳ người dùng nào nhận ETH lần đầu tiên đều sử dụng địa chỉ chưa được đăng ký. Nguồn đáng lo ngại (2) là các địa chỉ chưa đăng ký thực sự có giới hạn thời gian. Nếu người dùng tạo địa chỉ, nhận tiền nhưng quên gửi giao dịch trong năm tới (nghĩa là quên " Đăng ký"), thì người đó sẽ quên gửi giao dịch. tiền sẽ bị khóa.
Lưu ý rằng EOA không miễn dịch. Mặc dù có vẻ như có thể, vì quá trình hợp nhất EOA tương đối đơn giản (chỉ cần thêm số dư ETH cũ vào số mới và có EIP 169 cho nonce). Tuy nhiên, có hai vấn đề ở đây. Trước hết, mục tiêu của việc trừu tượng hóa tài khoản là thay thế EOA bằng các hợp đồng và quá trình hợp nhất các hợp đồng trừu tượng hóa tài khoản có thể không đơn giản. Thứ hai, không chỉ bản thân EOA sẽ bị ảnh hưởng bởi các sự kiện hết hạn và phục hồi mà còn cả các khóa lưu trữ liên quan (chẳng hạn như số dư mã thông báo ERC20) trong các ứng dụng mà EOA tham gia, do đó vẫn cần có logic hợp nhất phức tạp.
Vì vậy, theo quan điểm của tôi, cách ít gây rối nhất là một số dạng giải pháp sơ khai. Tuy nhiên, có một vấn đề về lý thuyết thông tin trong sơ đồ sơ khai có thể dẫn đến một số kết quả lạ. Để ngăn không cho các đối tượng trạng thái mới được tạo tại vị trí của N đối tượng trạng thái đã hết hạn, một tập hợp bao gồm N địa chỉ này (và/hoặc khóa lưu trữ) phải là một phần của trạng thái. Nếu tập hợp này được giảm thiểu thông tin (tức là chỉ chứa những địa chỉ này), thì kích thước của tập hợp này sẽ là O(N), và do đó kích thước trạng thái của nó cũng sẽ là O(N); sẽ giống như trạng thái bị mất tỷ lệ thuận với kích thước của trạng thái trực tiếp, vì vậy chúng tôi không thực sự giải quyết được vấn đề này.
Thối cây
Cách duy nhất để giải quyết vấn đề này là che phủ nhiều hơn N thông tin tài khoản; trên thực tế, chúng ta sẽ phải làm cho toàn bộ cây không thể truy cập được (một lần nữa, đây là bản chất của giải pháp luồng một cây: nếu hai tài khoản hết hạn, tất cả khoảng trống giữa chúng sẽ hoàn toàn hết hạn (nếu hai tài khoản hết hạn, tất cả khoảng trống ở giữa chúng cũng ngầm hết hạn)).
Và đây là một vấn đề khác: điều này tạo ra một dạng "thối cây" mà theo thời gian khiến các tài khoản mới được tạo ra. Tất cả các phần của cây trạng thái đều không thể truy cập được, tại ít nhất là đối với những người dùng không theo dõi trạng thái hết hạn của khu vực đó.
Những vấn đề thứ yếu do nấm mốc gây ra cũng phải được giải quyết. Ví dụ: nếu một hợp đồng tạo hợp đồng phụ, nó phải có khả năng tạo hợp đồng ở khu vực trạng thái không bị hỏng hoặc người dùng có dữ liệu nhân chứng (có thể có "lời nhắc" do người dùng cung cấp). Một giải pháp cho vấn đề nấm mốc ở đây là: liên tục mở các khu vực mới của bang để tạo tài khoản. Một cách suy nghĩ khác là mỗi người dùng chọn một số khu vực của tiểu bang (ví dụ: 1/256 của tiểu bang), theo dõi các thay đổi trong khu vực đó (bao gồm cả các trạng thái đã hết hạn) để có thể tạo thông báo nhân chứng và chỉ tạo tài khoản trong đó khu vực.
Một vấn đề khác đối với tình trạng cây bị mốc là nó đòi hỏi một cấu trúc dữ liệu rõ ràng để lưu trữ và kiểm tra phạm vi. Tốt nhất là cây có dữ liệu có thể được đặt trong một nút cho biết phần nào bên dưới nút đó đã hết hạn (như cách sử dụng giải pháp phát trực tuyến một cây), nhưng việc lưu trữ khóa-giá trị thì điều này vẫn khá khó khăn.
Nhìn lại tình trạng không trạng thái mạnh mẽ
Những lý do nên sử dụng cấu trúc cây khi hết hạn trạng thái sơ đồ Nhiều vấn đề nảy sinh có thể bắt nguồn từ thực tế là chúng ta cần đạt được sự đồng thuận về trạng thái nào đang hoạt động và trạng thái nào không hoạt động. Trong chế độ luồng hai cây, điều này rõ ràng hơn; nhưng ngay cả trong chế độ luồng một cây, cần phải có một dấu rõ ràng trên cây trạng thái để các nút Ethereum gần đây đã tải xuống trạng thái bằng cách sử dụng đồng bộ hóa nhanh có thể xác định một nỗ lực. Một giao dịch truy cập vào tài khoản nhưng không cung cấp thông báo làm chứng sẽ thành công hoặc thất bại. Vì vậy, chúng ta có thể làm điều đó mà không cần làm rõ sự khác biệt này?
Nếu chúng tôi đạt được trạng thái không trạng thái hoàn toàn thì chúng tôi có thể giúp người gửi giao dịch và nhà sản xuất khối có được trạng thái cần thiết để tạo thông báo nhân chứng một cách đáng tin cậy. Vậy phương pháp nào có thể giúp người gửi giao dịch và nhà sản xuất khối thực hiện được điều này?
Một cách tiếp cận tự nhiên là mỗi nút trong mạng chỉ lưu một phần của cây trạng thái, chẳng hạn như phần đã truy cập trong năm qua. Chỉ cần thêm cài đặt tự nguyện trong cài đặt máy khách. Nếu chúng tôi muốn đáng tin cậy hơn, chúng tôi có thể buộc ít nhất những người khai thác (và sau này là người xác thực PoS) lưu trữ một số dữ liệu bằng cách đưa ra sơ đồ bằng chứng về quyền giám hộ.
Một điều cần lưu ý: Nếu lớp đồng thuận không thể biết trạng thái nào đang hoạt động và trạng thái nào không hoạt động, thì việc truy cập Gas của trạng thái gần đây và trạng thái cũ. là giống nhau. Điều này sẽ dẫn đến hai kết quả:
1. Chi phí Gas để truy cập trạng thái gần đây cũng cần phải tăng thêm
2. Giới hạn trên của kích thước khối chứa thông báo nhân chứng có thể rất lớn nếu một khối chứa đầy các giao dịch truy cập trạng thái cũ (khoảng 800 byte * 12,5 m gas / 2400 gas mỗi lần truy cập ~ = 4,1 MB, giả sử triển khai EIP-2929, được chuyển đổi thành cây nhị phân)
Chúng ta cần theo dõi điều gì trong sự đồng thuận nếu muốn tránh những bất lợi này? Các đối tượng trạng thái (bao gồm các vùng không gian địa chỉ chưa được lấp đầy) đang hoạt động, điều này một lần nữa đưa chúng ta trở lại các thuộc tính gần với kịch bản hết hạn trạng thái. Điều này một lần nữa minh họa rằng "không quốc tịch và hết hạn trạng thái (tiền thuê nhà nước)" là một phạm vi, một không gian đánh đổi phức tạp, không phải là một trong hai/hoặc một lựa chọn.
Rollup cũng cần và có thể sử dụng giải pháp tương tự
Một giai đoạn trung hạn quan trọng đối với Ethereum Khả năng mở rộng giải pháp là cuộn lại. Tuy nhiên, bản thân việc tổng hợp không còn cần phải lo lắng về vấn đề quy mô dữ liệu trạng thái; trên thực tế, vấn đề quy mô trạng thái của hệ thống tổng hợp hoàn toàn giống với vấn đề của chính chuỗi Ethereum.
May mắn thay, nếu chúng tôi có thể giới thiệu một giải pháp, thì ít nhất bản tổng hợp EVM (giải pháp tổng hợp cố gắng tái tạo môi trường thời gian chạy Ethereum nhiều nhất có thể) có thể sử dụng cùng một giải pháp cho vấn đề mở rộng quy mô trạng thái bên trong của nó. Do đó, quản lý quy mô trạng thái bổ sung cho các chiến lược tổng hợp, phân chia và các chiến lược mở rộng quy mô khác.
(Ghi chú của người dịch: Cá nhân tôi nghĩ từ “bổ sung” ở đây gây hiểu lầm nghiêm trọng.)
Kết luận
Quy mô cấp bang là một vấn đề ngày càng nghiêm trọng và các giải pháp ở quy mô cấp bang cũng có thể mở đường cho việc tăng đáng kể giới hạn gas khối. Chúng ta nên đồng ý về một số hình thức kế hoạch hết hạn của tiểu bang và thực hiện nó. Tuy nhiên, có sự đánh đổi đáng kể về mặt kỹ thuật giữa các giải pháp khác nhau, đặc biệt nếu chúng ta cũng muốn duy trì một số đặc tính quan trọng của thiết kế hiện tại.
Một số thuộc tính mà chúng tôi có thể cần phải hy sinh bao gồm:
· Người dùng có thể tạo tài khoản ngoại tuyến và Thuộc tính nhận tiền tại địa chỉ này và giữ im lặng trong một khoảng thời gian trước khi hiển thị địa chỉ trên chuỗi
· Địa chỉ vẫn dài 20 byte (sơ đồ mở rộng trạng thái luân phiên yêu cầu không gian địa chỉ lớn hơn, mặc dù Độ dài của địa chỉ vốn có thể cần thay đổi nhanh chóng để chống va chạm)
· Trạng thái có thể được coi là thuộc tính được lưu trữ khóa-giá trị "thuần túy" và không cần lưu trữ nó trong mỗi thuộc tính nút trong cây trạng thái. Các thuộc tính để lưu trữ siêu dữ liệu
· Các ứng dụng hiện có yêu cầu viết lại ở nhiều mức độ khác nhau để đảm bảo rằng người dùng có thể tạo dữ liệu chứng kiến mà không cần lưu trữ tất cả các trạng thái không hoạt động
· Tiêu thụ gas; khó khăn trong việc tạo hợp đồng mới và viết các khe lưu trữ mới
Nếu chúng ta sẵn sàng hy sinh thì có một số giải pháp có thể được thực hiện nhanh chóng. Mặt khác, có lẽ theo thời gian, chúng tôi có thể khắc phục hoặc tổng hợp tốt hơn các khái niệm này, giảm thiểu các vấn đề và đặc biệt là làm cho chúng dễ triển khai hơn về mặt kỹ thuật (ví dụ: cho phép sử dụng kho lưu trữ khóa-giá trị "thuần túy"). Chúng ta nên phát triển sự hiểu biết sâu sắc hơn về lĩnh vực mà chúng ta ít nhiều sẵn sàng chấp nhận hy sinh và tiếp tục tích cực thực hiện các đề xuất cải tiến.
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia
Bài viết liên quan
