Một thách thức quan trọng mà Ethereum phải đối mặt là làm thế nào để giảm độ phức tạp và nhu cầu lưu trữ trong dài hạn, đồng thời duy trì tính bền vững và phi tập trung của chuỗi. Để Ethereum có thể tồn tại lâu dài, chúng ta cần áp dụng áp lực mạnh mẽ để chống lại độ phức tạp và sự phình to, giảm độ phức tạp và sự phình to theo thời gian. Nhưng cùng lúc đó, chúng ta cần giữ lại thuộc tính bền vững của blockchain này.
Mục tiêu chính của việc tinh lọc bao gồm:
Giảm yêu cầu lưu trữ của khách hàng bằng cách giảm bớt hoặc loại bỏ nhu cầu lưu trữ vĩnh viễn tất cả các lịch sử hoặc thậm chí trạng thái cuối cùng của mỗi nút.
Giảm độ phức tạp của giao thức bằng cách loại bỏ các chức năng không cần thiết.
Hồ sơ lịch sử hết hạn
Giải quyết vấn đề gì?
Tính đến thời điểm hiện tại, một nút Ethereum hoàn toàn đồng bộ cần khoảng 1.1 TB dung lượng đĩa để thực thi khách hàng, bên cạnh đó còn cần hàng trăm GB cho khách hàng đồng thuận. Phần lớn trong số đó là dữ liệu lịch sử, ngay cả khi kích thước khối không thay đổi, kích thước nút cũng sẽ tiếp tục tăng hàng trăm GB mỗi năm.
Nó là gì, làm thế nào để hoạt động?
Một đặc điểm chính đơn giản hóa của vấn đề lưu trữ lịch sử là, vì mỗi khối được liên kết với khối trước đó thông qua hàm băm, nên việc đạt được sự đồng thuận hiện tại là đủ để đạt được sự đồng thuận lịch sử. Điều này cung cấp cho chúng ta nhiều lựa chọn về cách lưu trữ hồ sơ lịch sử. Một lựa chọn tự nhiên là mạng mà mỗi nút chỉ lưu trữ một phần nhỏ dữ liệu.
Hiện nay, Ethereum đã bắt đầu thoát khỏi mô hình lưu trữ vĩnh viễn tất cả lịch sử của tất cả các nút. Các khối đồng thuận chỉ lưu trữ khoảng 6 tháng. Blob chỉ lưu trữ khoảng 18 ngày. EIP-4444 nhằm mục đích giới thiệu thời gian lưu trữ một năm cho các khối lịch sử và biên lai. Mục tiêu dài hạn là thiết lập một thời kỳ thống nhất ( có thể khoảng 18 ngày ), trong đó mỗi nút chịu trách nhiệm lưu trữ tất cả nội dung, sau đó thiết lập một mạng ngang hàng gồm các nút Ethereum, lưu trữ dữ liệu cũ theo cách phân tán.
còn cần làm gì, cần cân nhắc điều gì?
Công việc chính còn lại bao gồm xây dựng và tích hợp một giải pháp phân tán cụ thể để lưu trữ lịch sử. Giải pháp đơn giản nhất là giới thiệu thư viện torrent hiện có hoặc giải pháp gốc của Ethereum được gọi là mạng Portal. Sự đánh đổi chính liên quan đến cách chúng ta nỗ lực cung cấp dữ liệu lịch sử "cổ xưa". Giải pháp đơn giản nhất là ngừng lưu trữ lịch sử cổ xưa vào ngày mai và dựa vào các nút lưu trữ hiện có và các nhà cung cấp tập trung khác nhau để sao chép. Cách tiếp cận khó khăn hơn nhưng an toàn hơn là trước tiên xây dựng và tích hợp mạng torrent để lưu trữ lịch sử một cách phân tán.
tương tác với các phần khác của lộ trình như thế nào?
Nếu chúng ta muốn việc chạy hoặc khởi động nút trở nên cực kỳ dễ dàng, thì việc giảm nhu cầu lưu trữ lịch sử có thể được coi là quan trọng hơn tính không trạng thái. Chỉ khi đạt được tính không trạng thái và EIP-4444, chúng ta mới có thể thực hiện được tầm nhìn về việc chạy nút Ethereum trên đồng hồ thông minh và chỉ cần vài phút để thiết lập.
Trạng thái hết hạn
Giải quyết vấn đề gì?
Ngay cả khi chúng tôi loại bỏ nhu cầu lưu trữ lịch sử trên máy khách, nhu cầu lưu trữ của máy khách vẫn sẽ tiếp tục tăng, khoảng 50 GB mỗi năm, vì trạng thái tiếp tục tăng. Người dùng có thể trả một khoản phí một lần, từ đó vĩnh viễn mang lại gánh nặng cho các khách hàng Ethereum hiện tại và tương lai.
Nó là gì, làm thế nào để hoạt động?
Hôm nay, khi tạo một đối tượng trạng thái mới, đối tượng trạng thái đó luôn ở trạng thái đó. Ngược lại, điều chúng tôi muốn là đối tượng tự động hết hạn theo thời gian. Thách thức chính là làm điều này theo cách đạt được ba mục tiêu: hiệu quả, thân thiện với người dùng và thân thiện với nhà phát triển.
Hiện tại có hai loại "giải pháp không tồi tệ nhất đã biết":
Giải pháp hết hạn một phần trạng thái
Đề xuất hết hạn trạng thái dựa trên chu kỳ địa chỉ
Một số đề xuất hết hạn trạng thái sẽ chia trạng thái thành các khối. Mọi người sẽ lưu trữ "bản đồ hàng đầu" vĩnh viễn, trong đó các khối có thể trống hoặc không trống. Dữ liệu trong mỗi khối chỉ được lưu trữ khi dữ liệu đó đã được truy cập gần đây. Có một cơ chế "tái sinh" nếu không còn dữ liệu nào được lưu trữ.
Thiết kế dựa trên chu kỳ địa chỉ sử dụng một danh sách cây trạng thái đang không ngừng phát triển, và bất kỳ trạng thái nào được đọc hoặc ghi đều sẽ được lưu trong cây trạng thái mới nhất. Mỗi thời kỳ ( ví dụ: 1 năm ) thêm một cây trạng thái rỗng mới. Cây cũ đều bị đóng băng. Các nút đầy đủ chỉ lưu trữ hai cây gần đây nhất.
còn cần làm gì, cần cân nhắc điều gì?
Tôi nghĩ rằng trong tương lai có bốn con đường khả thi:
Chúng tôi thực hiện không trạng thái và không bao giờ đưa vào tình trạng hết hạn.
Chúng tôi tiến hành một phần trạng thái hết hạn và chấp nhận một tỷ lệ tăng kích thước trạng thái vĩnh viễn thấp hơn nhiều nhưng vẫn khác không.
Chúng tôi thực hiện hết hạn trạng thái thông qua mở rộng không gian địa chỉ.
Chúng tôi thực hiện trạng thái hết hạn thông qua việc thu hẹp không gian địa chỉ.
Điều quan trọng là, bất kể việc có thực hiện kế hoạch hết hạn dựa trên thay đổi định dạng địa chỉ hay không, cuối cùng vẫn phải giải quyết vấn đề liên quan đến việc mở rộng và thu hẹp không gian địa chỉ.
Dọn dẹp chức năng
Giải quyết vấn đề gì?
Một trong những điều kiện tiên quyết chính cho tính bảo mật, khả năng tiếp cận và tính trung lập đáng tin cậy là sự đơn giản. Nếu giao thức đẹp và đơn giản, thì khả năng xảy ra lỗi sẽ giảm. Nó làm tăng cơ hội cho các nhà phát triển mới có thể tham gia vào bất kỳ phần nào của nó. Nó có khả năng công bằng hơn và cũng dễ dàng hơn để kháng cự lại các lợi ích đặc biệt. Thật không may, giao thức giống như bất kỳ hệ thống xã hội nào, theo mặc định sẽ trở nên phức tạp hơn theo thời gian.
Nó là gì, nó hoạt động như thế nào?
Không có bất kỳ sửa chữa lớn nào có thể giảm bớt sự phức tạp của giao thức; bản chất của vấn đề là có nhiều giải pháp nhỏ. Một số ví dụ chính bao gồm:
Chuyển đổi RLP → SSZ
Xóa loại giao dịch cũ
LOG cải cách
Cuối cùng xóa cơ chế Ủy ban đồng bộ chuỗi tín hiệu
Định dạng dữ liệu thống nhất
Xóa ủy ban chuỗi tín hiệu
Loại bỏ thứ tự byte hỗn hợp
Đơn giản hóa cơ chế Gas
Xóa tiền tố đã biên soạn sẵn
Loại bỏ khả năng quan sát gas
Cải tiến phân tích tĩnh
còn cần làm gì, cần cân nhắc điều gì?
Sự cân nhắc chính khi thực hiện sự đơn giản hóa chức năng này là mức độ và tốc độ mà chúng tôi đơn giản hóa so với khả năng tương thích ngược. Vấn đề xã hội rộng lớn hơn là tạo ra một quy trình tiêu chuẩn hóa để thực hiện các thay đổi phá vỡ khả năng tương thích ngược không khẩn cấp.
Định dạng đối tượng EVM ( EOF ) là một nhóm thay đổi chính được đề xuất cho EVM. Ưu điểm của nó là tạo ra một con đường tự nhiên để thêm các tính năng EVM mới và khuyến khích việc chuyển đổi sang EVM nghiêm ngặt hơn với đảm bảo mạnh mẽ hơn. Nhược điểm của nó là làm tăng đáng kể độ phức tạp của giao thức, trừ khi chúng ta có thể tìm ra cách để cuối cùng loại bỏ và xóa EVM cũ.
Một chiến lược đơn giản hóa Ethereum cực đoan hơn là giữ nguyên giao thức, nhưng chuyển hầu hết các chức năng từ giao thức sang mã hợp đồng. Phiên bản cực đoan nhất là khiến Ethereum L1 "về mặt kỹ thuật" chỉ là chuỗi tín hiệu, và đưa vào một máy ảo tối thiểu, cho phép người khác tạo ra các tổng hợp của riêng họ. Sau đó, EVM sẽ trở thành cái đầu tiên trong số các tổng hợp này.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Con đường thanh lọc Ethereum: Thả độ phức tạp và nhu cầu lưu trữ là thách thức lâu dài
Tương lai có thể của Ethereum: Làm sạch
Một thách thức quan trọng mà Ethereum phải đối mặt là làm thế nào để giảm độ phức tạp và nhu cầu lưu trữ trong dài hạn, đồng thời duy trì tính bền vững và phi tập trung của chuỗi. Để Ethereum có thể tồn tại lâu dài, chúng ta cần áp dụng áp lực mạnh mẽ để chống lại độ phức tạp và sự phình to, giảm độ phức tạp và sự phình to theo thời gian. Nhưng cùng lúc đó, chúng ta cần giữ lại thuộc tính bền vững của blockchain này.
Mục tiêu chính của việc tinh lọc bao gồm:
Giảm yêu cầu lưu trữ của khách hàng bằng cách giảm bớt hoặc loại bỏ nhu cầu lưu trữ vĩnh viễn tất cả các lịch sử hoặc thậm chí trạng thái cuối cùng của mỗi nút.
Giảm độ phức tạp của giao thức bằng cách loại bỏ các chức năng không cần thiết.
Hồ sơ lịch sử hết hạn
Giải quyết vấn đề gì?
Tính đến thời điểm hiện tại, một nút Ethereum hoàn toàn đồng bộ cần khoảng 1.1 TB dung lượng đĩa để thực thi khách hàng, bên cạnh đó còn cần hàng trăm GB cho khách hàng đồng thuận. Phần lớn trong số đó là dữ liệu lịch sử, ngay cả khi kích thước khối không thay đổi, kích thước nút cũng sẽ tiếp tục tăng hàng trăm GB mỗi năm.
Nó là gì, làm thế nào để hoạt động?
Một đặc điểm chính đơn giản hóa của vấn đề lưu trữ lịch sử là, vì mỗi khối được liên kết với khối trước đó thông qua hàm băm, nên việc đạt được sự đồng thuận hiện tại là đủ để đạt được sự đồng thuận lịch sử. Điều này cung cấp cho chúng ta nhiều lựa chọn về cách lưu trữ hồ sơ lịch sử. Một lựa chọn tự nhiên là mạng mà mỗi nút chỉ lưu trữ một phần nhỏ dữ liệu.
Hiện nay, Ethereum đã bắt đầu thoát khỏi mô hình lưu trữ vĩnh viễn tất cả lịch sử của tất cả các nút. Các khối đồng thuận chỉ lưu trữ khoảng 6 tháng. Blob chỉ lưu trữ khoảng 18 ngày. EIP-4444 nhằm mục đích giới thiệu thời gian lưu trữ một năm cho các khối lịch sử và biên lai. Mục tiêu dài hạn là thiết lập một thời kỳ thống nhất ( có thể khoảng 18 ngày ), trong đó mỗi nút chịu trách nhiệm lưu trữ tất cả nội dung, sau đó thiết lập một mạng ngang hàng gồm các nút Ethereum, lưu trữ dữ liệu cũ theo cách phân tán.
còn cần làm gì, cần cân nhắc điều gì?
Công việc chính còn lại bao gồm xây dựng và tích hợp một giải pháp phân tán cụ thể để lưu trữ lịch sử. Giải pháp đơn giản nhất là giới thiệu thư viện torrent hiện có hoặc giải pháp gốc của Ethereum được gọi là mạng Portal. Sự đánh đổi chính liên quan đến cách chúng ta nỗ lực cung cấp dữ liệu lịch sử "cổ xưa". Giải pháp đơn giản nhất là ngừng lưu trữ lịch sử cổ xưa vào ngày mai và dựa vào các nút lưu trữ hiện có và các nhà cung cấp tập trung khác nhau để sao chép. Cách tiếp cận khó khăn hơn nhưng an toàn hơn là trước tiên xây dựng và tích hợp mạng torrent để lưu trữ lịch sử một cách phân tán.
tương tác với các phần khác của lộ trình như thế nào?
Nếu chúng ta muốn việc chạy hoặc khởi động nút trở nên cực kỳ dễ dàng, thì việc giảm nhu cầu lưu trữ lịch sử có thể được coi là quan trọng hơn tính không trạng thái. Chỉ khi đạt được tính không trạng thái và EIP-4444, chúng ta mới có thể thực hiện được tầm nhìn về việc chạy nút Ethereum trên đồng hồ thông minh và chỉ cần vài phút để thiết lập.
Trạng thái hết hạn
Giải quyết vấn đề gì?
Ngay cả khi chúng tôi loại bỏ nhu cầu lưu trữ lịch sử trên máy khách, nhu cầu lưu trữ của máy khách vẫn sẽ tiếp tục tăng, khoảng 50 GB mỗi năm, vì trạng thái tiếp tục tăng. Người dùng có thể trả một khoản phí một lần, từ đó vĩnh viễn mang lại gánh nặng cho các khách hàng Ethereum hiện tại và tương lai.
Nó là gì, làm thế nào để hoạt động?
Hôm nay, khi tạo một đối tượng trạng thái mới, đối tượng trạng thái đó luôn ở trạng thái đó. Ngược lại, điều chúng tôi muốn là đối tượng tự động hết hạn theo thời gian. Thách thức chính là làm điều này theo cách đạt được ba mục tiêu: hiệu quả, thân thiện với người dùng và thân thiện với nhà phát triển.
Hiện tại có hai loại "giải pháp không tồi tệ nhất đã biết":
Một số đề xuất hết hạn trạng thái sẽ chia trạng thái thành các khối. Mọi người sẽ lưu trữ "bản đồ hàng đầu" vĩnh viễn, trong đó các khối có thể trống hoặc không trống. Dữ liệu trong mỗi khối chỉ được lưu trữ khi dữ liệu đó đã được truy cập gần đây. Có một cơ chế "tái sinh" nếu không còn dữ liệu nào được lưu trữ.
Thiết kế dựa trên chu kỳ địa chỉ sử dụng một danh sách cây trạng thái đang không ngừng phát triển, và bất kỳ trạng thái nào được đọc hoặc ghi đều sẽ được lưu trong cây trạng thái mới nhất. Mỗi thời kỳ ( ví dụ: 1 năm ) thêm một cây trạng thái rỗng mới. Cây cũ đều bị đóng băng. Các nút đầy đủ chỉ lưu trữ hai cây gần đây nhất.
còn cần làm gì, cần cân nhắc điều gì?
Tôi nghĩ rằng trong tương lai có bốn con đường khả thi:
Điều quan trọng là, bất kể việc có thực hiện kế hoạch hết hạn dựa trên thay đổi định dạng địa chỉ hay không, cuối cùng vẫn phải giải quyết vấn đề liên quan đến việc mở rộng và thu hẹp không gian địa chỉ.
Dọn dẹp chức năng
Giải quyết vấn đề gì?
Một trong những điều kiện tiên quyết chính cho tính bảo mật, khả năng tiếp cận và tính trung lập đáng tin cậy là sự đơn giản. Nếu giao thức đẹp và đơn giản, thì khả năng xảy ra lỗi sẽ giảm. Nó làm tăng cơ hội cho các nhà phát triển mới có thể tham gia vào bất kỳ phần nào của nó. Nó có khả năng công bằng hơn và cũng dễ dàng hơn để kháng cự lại các lợi ích đặc biệt. Thật không may, giao thức giống như bất kỳ hệ thống xã hội nào, theo mặc định sẽ trở nên phức tạp hơn theo thời gian.
Nó là gì, nó hoạt động như thế nào?
Không có bất kỳ sửa chữa lớn nào có thể giảm bớt sự phức tạp của giao thức; bản chất của vấn đề là có nhiều giải pháp nhỏ. Một số ví dụ chính bao gồm:
còn cần làm gì, cần cân nhắc điều gì?
Sự cân nhắc chính khi thực hiện sự đơn giản hóa chức năng này là mức độ và tốc độ mà chúng tôi đơn giản hóa so với khả năng tương thích ngược. Vấn đề xã hội rộng lớn hơn là tạo ra một quy trình tiêu chuẩn hóa để thực hiện các thay đổi phá vỡ khả năng tương thích ngược không khẩn cấp.
Định dạng đối tượng EVM ( EOF ) là một nhóm thay đổi chính được đề xuất cho EVM. Ưu điểm của nó là tạo ra một con đường tự nhiên để thêm các tính năng EVM mới và khuyến khích việc chuyển đổi sang EVM nghiêm ngặt hơn với đảm bảo mạnh mẽ hơn. Nhược điểm của nó là làm tăng đáng kể độ phức tạp của giao thức, trừ khi chúng ta có thể tìm ra cách để cuối cùng loại bỏ và xóa EVM cũ.
Một chiến lược đơn giản hóa Ethereum cực đoan hơn là giữ nguyên giao thức, nhưng chuyển hầu hết các chức năng từ giao thức sang mã hợp đồng. Phiên bản cực đoan nhất là khiến Ethereum L1 "về mặt kỹ thuật" chỉ là chuỗi tín hiệu, và đưa vào một máy ảo tối thiểu, cho phép người khác tạo ra các tổng hợp của riêng họ. Sau đó, EVM sẽ trở thành cái đầu tiên trong số các tổng hợp này.