Một trong những thách thức mà Ethereum phải đối mặt là, theo mặc định, sự phình to và độ phức tạp của bất kỳ giao thức blockchain nào sẽ tăng lên theo thời gian. Điều này xảy ra ở hai khía cạnh: sự tích lũy dữ liệu lịch sử và sự gia tăng chức năng của giao thức. Để Ethereum có thể duy trì lâu dài, chúng ta cần áp dụng áp lực ngược mạnh mẽ lên cả hai xu hướng này, giảm độ phức tạp và sự phình to theo thời gian. Đồng thời, chúng ta cần giữ lại tính bền vững của blockchain, thuộc tính quan trọng này.
Mục tiêu chính của The Purge là:
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 mỗi nút lưu trữ vĩnh viễn tất cả lịch sử hoặc thậm chí trạng thái cuối cùng.
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.
History expiry Lịch sử ghi lại hết hạn
Lịch sử ghi lại thời gian hết hạn nhằm giải quyết vấn đề nhu cầu lưu trữ của các nút ngày càng tăng. Hiện tại, một nút Ethereum hoàn toàn đồng bộ cần khoảng 1,1 TB không gian đĩa và vẫn tiếp tục tăng hàng trăm GB mỗi năm.
Ý tưởng cơ bản về việc hết hạn lịch sử là: mỗi nút chỉ lưu trữ dữ liệu lịch sử hoàn chỉnh gần đây trong một khoảng thời gian ( như 18 ngày ), dữ liệu cũ hơn sẽ được các nút trong mạng lưu trữ theo cách phân tán. Điều này có thể được thực hiện theo cách tương tự như mạng hạt giống, mỗi nút chỉ lưu trữ một phần nhỏ dữ liệu cũ.
Hiện tại đã bắt đầu thực hiện ý tưởng này, như khối đồng thuận chỉ lưu trữ khoảng 6 tháng, blob chỉ lưu trữ khoảng 18 ngày. Đề xuất EIP-4444 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 nhận. Mục tiêu dài hạn là thiết lập một thời gian lưu trữ thống nhất ( có thể khoảng 18 ngày ), sau đó dữ liệu cũ sẽ được lưu trữ phân tán bởi mạng P2P được tạo thành từ các nút Ethereum.
Việc thực hiện lịch sử ghi nhận hết hạn cần thêm công việc, chẳng hạn như xây dựng và tích hợp các giải pháp lưu trữ phân tán cụ thể, xử lý sao chép dữ liệu lịch sử cổ xưa, v.v. Sự đánh đổi chính là cách chúng ta nỗ lực đảm bảo rằng tập hợp các nút lớn nhất thực sự lưu trữ tất cả dữ liệu, cũng như độ sâu mà chúng ta tích hợp bộ lưu trữ lịch sử vào giao thức.
State expiry trạng thái hết hạn
Trạng thái hết hạn nhằm giải quyết vấn đề tăng trưởng liên tục của trạng thái Ethereum. Ngay cả khi loại bỏ nhu cầu lưu trữ lịch sử, nhu cầu lưu trữ trạng thái của các khách hàng vẫn sẽ tăng khoảng 50GB mỗi năm.
Thách thức chính của việc trạng thái hết hạn là làm thế nào để thực hiện việc hết hạn tự động của các đối tượng trạng thái trong khi vẫn giữ được tính tương thích với EVM. Hiện tại có hai loại giải pháp chính:
Một số trạng thái hết hạn: Chia trạng thái thành các khối, chỉ những khối đã được truy cập gần đây mới được lưu trữ. Một đề xuất cụ thể là EIP-7736, nó dựa trên thiết kế "nhánh lá" của Verkle tree, lưu trữ dữ liệu liền kề dưới cùng một "thân chính", nếu không được truy cập trong 6 tháng thì chỉ lưu trữ cam kết 32 byte.
Trạng thái hết hạn dựa trên chu kỳ địa chỉ: Sử dụng một danh sách cây trạng thái đang ngày càng tăng, mỗi kỳ ( như 1 năm ) thêm một cây trống mới. Các nút hoàn chỉnh chỉ lưu trữ hai cây gần đây nhất. Các đối tượng trạng thái đã hết hạn có thể được phục hồi bằng cách cung cấp chứng cứ.
Cả hai phương án này đều đối mặt với một số thách thức, chẳng hạn như thiết kế động lực, thay đổi định dạng địa chỉ, v.v. Các con đường có thể trong tương lai bao gồm: chỉ thực hiện vô trạng không thực hiện trạng thái hết hạn, thực hiện một phần trạng thái hết hạn, thông qua mở rộng hoặc thu hẹp không gian địa chỉ để thực hiện trạng thái hết hạn. Cần phải cân nhắc giữa việc đơn giản hóa giao thức và tính tương thích ngược.
Dọn dẹp tính năng
Dọn dẹp đặc điểm nhằm giảm bớt sự 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. Một số cơ hội dọn dẹp chính bao gồm:
Chuyển đổi mã hóa RLP sang SSZ
Xóa loại giao dịch cũ
Cải cách cơ chế LOG
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 Beacon
Loại bỏ byte thứ hỗn hợp
Đơn giản hóa cơ chế gas
Xóa các biên dịch trước ít được sử dụng
Làm cho gas không thể quan sát được
Cải tiến phân tích tĩnh
Việc thực hiện các công việc dọn dẹp này cần phải cân nhắc giữa mức độ đơn giản hóa và khả năng tương thích ngược. Cần thiết lập một quy trình chuẩn hóa để thực hiện các thay đổi không tương thích ngược không khẩn cấp. Định dạng đối tượng EVM (EOF) đề xuất đã đưa ra một loạt các thay đổi, nhưng cũng làm tăng độ phức tạp và cần phải cân nhắc.
Một chiến lược đơn giản hóa quyết liệt hơn là chuyển đổi hầu hết nội dung của giao thức thành mã hợp đồng, chẳng hạn như biến EVM thành một tóm tắt, hoặc thay thế EVM bằng VM mới. Điều này có thể đơn giản hóa đáng kể giao thức cốt lõi, nhưng việc thực hiện sẽ khó khăn hơn.
Tổng thể, The Purge nhằm giảm bớt sự phức tạp và nhu cầu lưu trữ của Ethereum thông qua việc hết hạn hồ sơ lịch sử, hết hạn trạng thái và dọn dẹp đặc điểm, nhằm đảm bảo tính bền vững lâu dài của nó. Điều này đòi hỏi phải cân nhắc giữa việc đơn giản hóa và khả năng tương thích, đồng thời thiết lập một quy trình lâu dài và có trật tự để thực hiện những thay đổi 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.
10 thích
Phần thưởng
10
7
Chia sẻ
Bình luận
0/400
RooftopReserver
· 07-25 09:20
Ôi V神 cuối cùng cũng chịu dọn rác rồi
Xem bản gốcTrả lời0
DaoResearcher
· 07-25 03:50
Cơ sở dữ liệu tham khảo cho thấy con đường này có nguy cơ phân nhánh đa dạng.
Xem bản gốcTrả lời0
ContractTester
· 07-22 13:46
Dọn dẹp lịch sử - Thú vị không bằng dọn dẹp gas phí
Xem bản gốcTrả lời0
RegenRestorer
· 07-22 13:45
Sắp xếp thì sắp xếp đi, đừng ảnh hưởng đến lượng giao dịch.
Ethereum The Purge kế hoạch: Thả độ phức tạp Đảm bảo tính bền vững lâu dài
Tương lai có thể của Ethereum: The Purge
Một trong những thách thức mà Ethereum phải đối mặt là, theo mặc định, sự phình to và độ phức tạp của bất kỳ giao thức blockchain nào sẽ tăng lên theo thời gian. Điều này xảy ra ở hai khía cạnh: sự tích lũy dữ liệu lịch sử và sự gia tăng chức năng của giao thức. Để Ethereum có thể duy trì lâu dài, chúng ta cần áp dụng áp lực ngược mạnh mẽ lên cả hai xu hướng này, giảm độ phức tạp và sự phình to theo thời gian. Đồng thời, chúng ta cần giữ lại tính bền vững của blockchain, thuộc tính quan trọng này.
Mục tiêu chính của The Purge là:
History expiry Lịch sử ghi lại hết hạn
Lịch sử ghi lại thời gian hết hạn nhằm giải quyết vấn đề nhu cầu lưu trữ của các nút ngày càng tăng. Hiện tại, một nút Ethereum hoàn toàn đồng bộ cần khoảng 1,1 TB không gian đĩa và vẫn tiếp tục tăng hàng trăm GB mỗi năm.
Ý tưởng cơ bản về việc hết hạn lịch sử là: mỗi nút chỉ lưu trữ dữ liệu lịch sử hoàn chỉnh gần đây trong một khoảng thời gian ( như 18 ngày ), dữ liệu cũ hơn sẽ được các nút trong mạng lưu trữ theo cách phân tán. Điều này có thể được thực hiện theo cách tương tự như mạng hạt giống, mỗi nút chỉ lưu trữ một phần nhỏ dữ liệu cũ.
Hiện tại đã bắt đầu thực hiện ý tưởng này, như khối đồng thuận chỉ lưu trữ khoảng 6 tháng, blob chỉ lưu trữ khoảng 18 ngày. Đề xuất EIP-4444 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 nhận. Mục tiêu dài hạn là thiết lập một thời gian lưu trữ thống nhất ( có thể khoảng 18 ngày ), sau đó dữ liệu cũ sẽ được lưu trữ phân tán bởi mạng P2P được tạo thành từ các nút Ethereum.
Việc thực hiện lịch sử ghi nhận hết hạn cần thêm công việc, chẳng hạn như xây dựng và tích hợp các giải pháp lưu trữ phân tán cụ thể, xử lý sao chép dữ liệu lịch sử cổ xưa, v.v. Sự đánh đổi chính là cách chúng ta nỗ lực đảm bảo rằng tập hợp các nút lớn nhất thực sự lưu trữ tất cả dữ liệu, cũng như độ sâu mà chúng ta tích hợp bộ lưu trữ lịch sử vào giao thức.
State expiry trạng thái hết hạn
Trạng thái hết hạn nhằm giải quyết vấn đề tăng trưởng liên tục của trạng thái Ethereum. Ngay cả khi loại bỏ nhu cầu lưu trữ lịch sử, nhu cầu lưu trữ trạng thái của các khách hàng vẫn sẽ tăng khoảng 50GB mỗi năm.
Thách thức chính của việc trạng thái hết hạn là làm thế nào để thực hiện việc hết hạn tự động của các đối tượng trạng thái trong khi vẫn giữ được tính tương thích với EVM. Hiện tại có hai loại giải pháp chính:
Một số trạng thái hết hạn: Chia trạng thái thành các khối, chỉ những khối đã được truy cập gần đây mới được lưu trữ. Một đề xuất cụ thể là EIP-7736, nó dựa trên thiết kế "nhánh lá" của Verkle tree, lưu trữ dữ liệu liền kề dưới cùng một "thân chính", nếu không được truy cập trong 6 tháng thì chỉ lưu trữ cam kết 32 byte.
Trạng thái hết hạn dựa trên chu kỳ địa chỉ: Sử dụng một danh sách cây trạng thái đang ngày càng tăng, mỗi kỳ ( như 1 năm ) thêm một cây trống mới. Các nút hoàn chỉnh chỉ lưu trữ hai cây gần đây nhất. Các đối tượng trạng thái đã hết hạn có thể được phục hồi bằng cách cung cấp chứng cứ.
Cả hai phương án này đều đối mặt với một số thách thức, chẳng hạn như thiết kế động lực, thay đổi định dạng địa chỉ, v.v. Các con đường có thể trong tương lai bao gồm: chỉ thực hiện vô trạng không thực hiện trạng thái hết hạn, thực hiện một phần trạng thái hết hạn, thông qua mở rộng hoặc thu hẹp không gian địa chỉ để thực hiện trạng thái hết hạn. Cần phải cân nhắc giữa việc đơn giản hóa giao thức và tính tương thích ngược.
Dọn dẹp tính năng
Dọn dẹp đặc điểm nhằm giảm bớt sự 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. Một số cơ hội dọn dẹp chính bao gồm:
Việc thực hiện các công việc dọn dẹp này cần phải cân nhắc giữa mức độ đơn giản hóa và khả năng tương thích ngược. Cần thiết lập một quy trình chuẩn hóa để thực hiện các thay đổi không tương thích ngược không khẩn cấp. Định dạng đối tượng EVM (EOF) đề xuất đã đưa ra một loạt các thay đổi, nhưng cũng làm tăng độ phức tạp và cần phải cân nhắc.
Một chiến lược đơn giản hóa quyết liệt hơn là chuyển đổi hầu hết nội dung của giao thức thành mã hợp đồng, chẳng hạn như biến EVM thành một tóm tắt, hoặc thay thế EVM bằng VM mới. Điều này có thể đơn giản hóa đáng kể giao thức cốt lõi, nhưng việc thực hiện sẽ khó khăn hơn.
Tổng thể, The Purge nhằm giảm bớt sự phức tạp và nhu cầu lưu trữ của Ethereum thông qua việc hết hạn hồ sơ lịch sử, hết hạn trạng thái và dọn dẹp đặc điểm, nhằm đảm bảo tính bền vững lâu dài của nó. Điều này đòi hỏi phải cân nhắc giữa việc đơn giản hóa và khả năng tương thích, đồng thời thiết lập một quy trình lâu dài và có trật tự để thực hiện những thay đổi này.