Vitalik Buterin cho biết The Purge có thể giúp giảm độ phức tạp của Ethereum và yêu cầu lưu trữ

27/10/2024 05:06 5

Một trong những vấn đề của Ethereum, hoặc bất kỳ blockchain nào, là nó tăng kích thước theo thời gian. Điều này có nghĩa là sự gia tăng về độ phức tạp của mã và yêu cầu lưu trữ của nó.

Một blockchain phải lưu giữ tất cả dữ liệu trong suốt lịch sử của nó, dữ liệu này cần được lưu trữ bởi tất cả các máy khách và được tải xuống bởi các máy khách mới. Điều này dẫn đến việc tăng liên tục tải máy khách và thời gian đồng bộ hóa.

Hơn nữa, độ phức tạp của mã tăng theo thời gian vì "thêm một tính năng mới dễ hơn là xóa một tính năng cũ", Vitalik Buterin đã viết trên blog của mình.

Do đó, Buterin tin rằng các nhà phát triển phải tích cực hành động để ngăn chặn các xu hướng tăng trưởng này trong khi vẫn duy trì tính lâu dài của Ethereum. Do đó, Buterin đã trình bày The Purge—một kế hoạch gồm ba phần nhằm mục đích đơn giản hóa blockchain và giảm tải dữ liệu của nó.

Phần 1: Lịch sử hết hạn

Một Node Ethereum được đồng bộ hóa hoàn toàn hiện yêu cầu khoảng 1,1 TB dung lượng lưu trữ cho máy khách thực thi. Nó yêu cầu thêm vài trăm gigabyte cho máy khách đồng thuận. Theo Buterin, hầu hết dữ liệu này là lịch sử, chẳng hạn như dữ liệu về các khối, giao dịch và biên lai lịch sử, nhiều trong số đó đã có từ nhiều năm trước. Để lưu trữ tất cả lịch sử này, dung lượng đĩa cần thiết tiếp tục tăng lên hàng trăm gigabyte mỗi năm.

Buterin tin rằng vấn đề này có thể được giải quyết bằng thứ gọi là Lịch sử hết hạn.

Mỗi khối trên blockchain trỏ đến khối trước đó thông qua liên kết băm. Điều này có nghĩa là sự đồng thuận trên khối hiện tại biểu thị sự đồng thuận về lịch sử.

Theo Buterin, miễn là mạng lưới có sự đồng thuận về khối hiện tại, bất kỳ dữ liệu lịch sử liên quan nào cũng có thể được cung cấp bởi một tác nhân duy nhất thông qua bằng chứng Merkle, cho phép bất kỳ ai xác minh tính toàn vẹn của nó. Điều này có nghĩa là thay vì để mọi Node lưu trữ tất cả dữ liệu, mỗi Node có thể lưu trữ một phần trăm nhỏ dữ liệu, giảm yêu cầu lưu trữ.

Buterin về cơ bản đề xuất áp dụng mô hình hoạt động của mạng torrent, trong đó mỗi người tham gia chỉ lưu trữ và phân phối một phần nhỏ dữ liệu được mạng lưu trữ và phân phối.

Ethereum đã thực hiện các bước để giảm yêu cầu lưu trữ—một số thông tin hiện có ngày hết hạn. Ví dụ, các khối đồng thuận được lưu trữ trong sáu tháng và các blob được lưu trữ trong 18 ngày.

EIP-4444 là một bước tiến khác theo hướng đó—nó nhằm mục đích giới hạn thời gian lưu trữ cho các khối và biên lai lịch sử ở mức một năm. Tuy nhiên, mục tiêu dài hạn là có một khoảng thời gian cố định, như 18 ngày, trong đó mọi Node phải lưu trữ mọi thứ và sau đó dữ liệu cũ hơn được lưu trữ theo cách phân tán trên mạng ngang hàng.

Phần 2: Hết hạn trạng thái

Theo Buterin, việc loại bỏ nhu cầu lưu trữ toàn bộ lịch sử của khách hàng không giải quyết hoàn toàn vấn đề về yêu cầu lưu trữ phình to. Điều này là do khách hàng phải tăng dung lượng lưu trữ của mình khoảng 50GB mỗi năm do "sự tăng trưởng liên tục của trạng thái: số dư tài khoản và nonce, mã hợp đồng và lưu trữ hợp đồng".

Một đối tượng trạng thái mới có thể được tạo theo ba cách—bằng cách tạo một tài khoản mới, bằng cách gửi ETH đến một tài khoản mới và bằng cách thiết lập một khe lưu trữ trước đó không hoạt động. Khi một đối tượng trạng thái được tạo, nó sẽ ở trong trạng thái đó mãi mãi.

Buterin tin rằng giải pháp để tự động hết hạn các đối tượng trạng thái theo thời gian cần phải 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. Điều này có nghĩa là giải pháp không yêu cầu khối lượng tính toán lớn, người dùng không nên mất quyền truy cập vào Token của họ nếu họ thoát khỏi chúng mà không bị động đến trong nhiều năm và các nhà phát triển không gặp nhiều bất tiện trong quá trình này.

Buterin gợi ý hai loại "giải pháp ít tệ nhất được biết đến":

Giải pháp hết hạn trạng thái một phần Đề xuất hết hạn trạng thái theo chu kỳ địa chỉ.

Hết hạn trạng thái một phần

Đề xuất hết hạn trạng thái một phần hoạt động dựa trên nguyên tắc chia trạng thái thành "khối". Điều này sẽ yêu cầu mọi người lưu trữ "bản đồ cấp cao nhất" về khối nào rỗng hoặc không rỗng mãi mãi. Dữ liệu trong khối chỉ được lưu trữ nếu chúng đã được truy cập gần đây. Cơ chế "hồi sinh" cho phép bất kỳ ai khôi phục dữ liệu trong khối nếu nó không được lưu trữ bằng cách cung cấp bằng chứng về dữ liệu đó là gì.

Hết hạn trạng thái theo chu kỳ địa chỉ

Hết hạn trạng thái theo chu kỳ địa chỉ đề xuất có danh sách tăng trưởng của các cây trạng thái thay vì chỉ một cây lưu trữ toàn bộ trạng thái. Bất kỳ trạng thái nào được đọc hoặc ghi đều được cập nhật vào cây trạng thái gần đây nhất. Một cây trạng thái trống mới được thêm một lần cho mỗi chu kỳ, có thể là một năm.

Trong kịch bản này, các cây trạng thái cũ hơn bị đóng băng và các Node đầy đủ chỉ cần lưu trữ hai cây mới nhất. Nếu một đối tượng trạng thái trở thành một phần của cây đã hết hạn, nó có thể được đọc hoặc ghi, nhưng giao dịch sẽ yêu cầu bằng chứng Merkle cho nó. Sau giao dịch, nó sẽ được thêm lại vào cây mới nhất.

Dọn dẹp tính năng

Theo thời gian, mọi giao thức đều trở nên phức tạp, bất kể ban đầu chúng có đơn giản đến đâu.

Buterin đã viết:

"Nếu chúng ta không muốn Ethereum rơi vào hố đen ngày càng phức tạp, chúng ta cần thực hiện một trong hai điều sau: (i) ngừng thực hiện các thay đổi và làm cứng giao thức, (ii) có thể thực sự loại bỏ
các tính năng và giảm
độ phức tạp."

Theo Buterin, việc dọn dẹp sự phức tạp của Ethereum đòi hỏi một số bản sửa lỗi nhỏ, như xóa opcode SELFDESTRUCT, xóa các loại giao dịch cũ và các ủy ban chuỗi beacon, cải tổ LOG, v.v. Buterin cũng đề xuất đơn giản hóa cơ chế gas, xóa khả năng quan sát gas và cải thiện phân tích tĩnh.

Chia sẻ bài viết này với bạn bè qua Facebook / Zalo / Telegram:

Chia sẻ

Chủ đề về Nổi bật