Tương lai có thể của Ethereum: The Purge

Kể từ ngày 14 tháng 10, người sáng lập Ethereum Vitalik Buterin đã lần lượt phát hành một loạt bài thảo luận về sự phát triển tương lai của Ethereum, từ "The Merge" đến "The Purge" mới nhất, thể hiện tầm nhìn của ông về sự phát triển tương lai của mạng chính Ethereum và các giải pháp cho các vấn đề hiện tại.

Bài viết "The Purge" khám phá cách mà Ethereum có thể giảm thiểu độ 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à tính phi tập trung của chuỗi. Các biện pháp chính bao gồm giảm gánh nặng lưu trữ của khách hàng thông qua "hết hạn lịch sử" và "hết hạn trạng thái", và đơn giản hóa giao thức thông qua "dọn dẹp đặc điểm" để đảm bảo tính bền vững và khả năng mở rộng của mạng.

History expiry Lịch sử ghi lại hết hạn

Giải quyết vấn đề gì?

Hiện tại, một nút Ethereum đồng bộ hoàn chỉnh cần khoảng 1.1TB dung lượng đĩa để thực thi khách hàng, ngoài ra còn cần vài trăm GB cho khách hàng đồng thuận. Phần lớn là dữ liệu lịch sử, ngay cả khi giới hạn Gas không thay đổi, kích thước nút cũng sẽ tăng thêm vài trăm GB mỗi năm.

Nó là gì, nó hoạt động như thế nào?

Một đặc điểm quan trọng của lưu trữ lịch sử là sự đồng thuận hiện tại đủ để đạt được sự đồng thuận về lịch sử. Điều này cung cấp nhiều lựa chọn cho việc lưu trữ hồ sơ lịch sử, chẳng hạn như mạng mà mỗi nút chỉ lưu trữ một phần dữ liệu.

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 nhận. Mục tiêu dài hạn là thiết lập thời gian lưu trữ thống nhất khoảng 18 ngày, sau đó thiết lập một mạng P2P gồm các nút Ethereum để lưu trữ dữ liệu cũ theo cách phân tán.

Mã xóa có thể được sử dụng để nâng cao tính chống chịu, đồng thời duy trì cùng một yếu tố sao chép. Giải pháp đơn giản nhất có thể là tái sử dụng mã xóa hiện có của Blob và cũng đưa dữ liệu khối thực thi và đồng thuận vào blob.

còn cần làm gì, cần cân nhắc điều gì?

Công việc chính 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à đưa vào 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.

Các cân nhắc chính liên quan đến cách nỗ lực cung cấp dữ liệu lịch sử "cổ đại". Giải pháp đơn giản nhất là ngay lập tức ngừng lưu trữ dữ liệu lịch sử cổ đại, dựa vào các nút lưu trữ hiện có. Giải pháp an toàn hơn nhưng khó khăn hơn là trước tiên xây dựng và tích hợp mạng torrent.

và sự tương tác với các phần khác của lộ trình

Giảm nhu cầu lưu trữ lịch sử là rất quan trọng để làm cho việc vận hành các nút trở nên cực kỳ dễ dàng. Chỉ khi đạt được trạng thái không lưu và EIP-4444, mới có thể thực hiện được tầm nhìn chạy nút Ethereum trên đồng hồ thông minh.

Việc hạn chế lưu trữ lịch sử cũng làm cho các nút Ethereum mới chỉ hỗ trợ phiên bản giao thức mới nhất trở nên khả thi hơn, từ đó đơn giản hóa khách hàng.

Hết hạn trạng thái

Giải quyết vấn đề gì?

Ngay cả khi nhu cầu lưu trữ lịch sử được loại bỏ, nhu cầu lưu trữ của khách hàng vẫn sẽ tăng khoảng 50GB mỗi năm, vì số dư tài khoản trạng thái (, mã hợp đồng, v.v. ) sẽ tiếp tục gia tăng. Người dùng có thể thanh toán một lần, gây ra gánh nặng vĩnh viễn cho khách hàng hiện tại và tương lai.

Nó là gì, cách hoạt động ra sao?

Trạng thái khó "hết hạn" hơn lịch sử, vì EVM giả định rằng các đối tượng trạng thái một khi được tạo ra sẽ tồn tại mãi mãi. Mục tiêu là làm cho các đối tượng tự động hết hạn theo thời gian, trong khi vẫn duy trì hiệu suất, thân thiện với người dùng và thân thiện với nhà phát triển.

Chủ yếu có hai loại kế hoạch:

1. Một số trạng thái hết hạn: Chia nhỏ trạng thái, chỉ lưu trữ dữ liệu được truy cập gần đây. EIP-7736 đề xuất giải pháp dựa trên cây Verkle, dữ liệu không được truy cập trong 6 tháng chỉ lưu 32 byte gốc.

2. Thời hạn trạng thái dựa trên chu kỳ địa chỉ: Sử dụng danh sách cây trạng thái ngày càng tăng, thêm cây trống mới mỗi năm. Node đầy đủ chỉ lưu giữ hai cây gần nhất. Dữ liệu hết hạn cần phải cung cấp chứng minh để đọc và ghi.

còn cần làm gì, cần cân nhắc điều gì?

Các con đường có thể trong tương lai bao gồm:

1. Thực hiện không trạng thái, không đưa vào trạng thái hết hạn. Trạng thái tiếp tục tăng nhưng chỉ cần lưu trữ của người dùng đặc biệt.

2. Thực hiện một phần trạng thái đến hạn, chấp nhận tỷ lệ tăng trạng thái vĩnh viễn thấp nhưng không bằng không.

3. Thực hiện trạng thái hết hạn thông qua việc mở rộng không gian địa chỉ. Cần một quá trình nhiều năm để đảm bảo việc chuyển đổi định dạng địa chỉ an toàn và hiệu quả.

4. Thực hiện hết hạn trạng thái thông qua việc thu hẹp không gian địa chỉ. Cần nhiều năm quy trình để đảm bảo giải quyết tất cả các rủi ro an ninh.

Bất kể giải pháp nào được áp dụng, đều cần giải quyết vấn đề mở rộng và thu hẹp không gian địa chỉ, vì các cuộc tấn công xung đột địa chỉ trong tương lai sẽ trở nên dễ dàng hơn.

Dọn dẹp tính năng 特征清理

giải quyết vấn đề gì?

Sự đơn giản của giao thức là chìa khóa cho tính bảo mật, khả năng tiếp cận và tính trung lập đáng tin cậy. Nhưng giao thức theo mặc định sẽ trở nên phức tạp hơn theo thời gian. Chúng ta cần có khả năng loại bỏ các chức năng và giảm độ phức tạp.

Nó là gì, hoạt động như thế nào?

Không có một sửa chữa lớn nào có thể giảm bớt độ phức tạp của giao thức, mà cần nhiều giải pháp nhỏ. Một số ví dụ quan trọng bao gồm:

• Chuyển đổi RLP → SSZ: Thay thế mã hóa RLP bằng SSZ tốt hơn
• Xóa loại giao dịch cũ
• Cải cách LOG: Xóa các chức năng như bộ lọc Bloom không sử dụ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ỏ byte thứ hỗn hợp

Một số ví dụ trong EVM:

• Cơ chế Gas được đơn giản hóa
• Xóa biên dịch trước
• Loại bỏ khả năng quan sát gas
• Cải tiến phân tích tĩnh: Xóa bỏ nhảy động

còn cần làm gì, cần cân nhắc điều gì?

Cân nhắc chính là mức độ đơn giản hóa và tốc độ với khả năng tương thích ngược. Cần tạo ra một quy trình 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, bao gồm phân tích tác động, loại bỏ EIP chính thức, xóa bỏ cuối cùng và các bước khác.

Định dạng đối tượng EVM(EOF) đã đề xuất một loạt các thay đổi EVM, nhằm cho phép nhiều nâng cấp hơn. Cần cân nhắc giữa độ phức tạp tăng thêm và mục tiêu đơn giản hóa toàn bộ EVM.

Phương pháp quyết liệt hơn là chuyển 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 bảng tổng hợp 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, nhưng cần phải cân nhắc về tính tương thích.