461 GiB: Node Ethereum đồng bộ trong nửa ngày với cấu hình Geth

Dung lượng thư mục dữ liệu của một node Ethereum (ETH) có thể giảm xuống 461 GiB trong một cấu hình nhất định, đồng thời thời gian đồng bộ nhanh nhất được ghi nhận là khoảng nửa ngày. Tuy nhiên, đây là con số thuộc một cấu hình Geth cụ thể, không có nghĩa dung lượng lưu trữ cần thiết cho mọi node đều giảm tương ứng.

Vitalik Buterin (Vitalik Buterin), đồng sáng lập Ethereum, ngày 26 cho biết trên X: “Trong trường hợp nhanh nhất hiện nay, chỉ cần nửa ngày để đồng bộ một node Ethereum”. Ông nói thêm rằng việc áp dụng các thiết lập tích cực có thể đưa mức sử dụng đĩa xuống dưới 0,5 TB.

EtherWorld đăng lại phát biểu của Buterin và cho biết thư mục dữ liệu của node Geth được ông nêu có dung lượng 461 GiB. Đây là con số theo trường hợp cụ thể, có thể thay đổi tùy loại node, cấu hình client và phương thức đồng bộ.

Tài liệu chính thức của Ethereum cho biết snap sync trên Geth có thể cần hơn 500 GB. Thiết bị lưu trữ tối thiểu thường được khuyến nghị cho một full node là SSD NVMe 2 TB, trong khi cấu hình đề xuất là SSD NVMe 4 TB.

Node là máy tính tải xuống và xác minh dữ liệu blockchain. Node Ethereum phải vận hành đồng thời execution client và consensus client, trong khi gánh nặng vận hành thực tế phụ thuộc đáng kể vào dung lượng lưu trữ, tốc độ đọc ghi đĩa và môi trường mạng.

Snap sync rút ngắn thời gian đồng bộ bằng cách lấy dữ liệu trạng thái tại một thời điểm nhất định, thay vì tính toán lại toàn bộ dữ liệu lịch sử blockchain từ đầu. Thời gian đồng bộ và dung lượng lưu trữ thực tế có thể khác nhau tùy client, phần cứng, tốc độ mạng và thiết lập.

EIP-4444 là đề xuất nhằm giảm gánh nặng lưu trữ dữ liệu lịch sử đối với execution client. Chưa có bằng chứng xác nhận mối quan hệ nhân quả trực tiếp giữa EIP-4444 và trường hợp 461 GiB.

Node xác minh trạng thái mới nhất có thể xóa bớt dữ liệu cũ, trong khi archive node phải lưu trữ toàn bộ dữ liệu lịch sử. Vì vậy, yêu cầu dung lượng lưu trữ của archive node lớn hơn nhiều so với node thông thường.

Nếu gánh nặng lưu trữ dữ liệu lịch sử giảm, việc vận hành node riêng trên phần cứng gia đình có thể trở nên dễ dàng hơn. Node riêng được xem là phương án giảm phụ thuộc vào nhà cung cấp RPC bên thứ ba, đồng thời hỗ trợ bảo vệ quyền riêng tư và khả năng chống kiểm duyệt. Dù vậy, người vận hành vẫn phải tự bảo đảm thiết bị lưu trữ, quản lý mạng và bảo trì client.

Ngược lại, các ứng dụng cần dữ liệu cũ có thể phụ thuộc nhiều hơn vào nhà cung cấp dữ liệu riêng hoặc mạng lưới lưu trữ. Tài liệu EIP-4444 cũng giải thích rằng mức độ phụ thuộc vào các dịch vụ dữ liệu tập trung có thể tăng trong quá trình khả năng tiếp cận dữ liệu suy giảm.

U.Today phân tích rằng sự phổ biến của PC hiệu năng cao dành cho AI có thể làm giảm gánh nặng tương đối khi vận hành thêm node trên cùng thiết bị, nếu số người dùng sở hữu SSD dung lượng lớn và bộ nhớ cao để chạy mô hình AI cục bộ tăng lên. Đây là cách diễn giải về khả năng kỹ thuật.

Tuy nhiên, chưa có số liệu thực nghiệm cho thấy việc phổ biến phần cứng AI đã trực tiếp dẫn đến số lượng node Ethereum tăng. Tài liệu chính thức của Ethereum cũng chưa xác lập mối quan hệ nhân quả giữa sự mở rộng của AI và số người vận hành node.

Bản nâng cấp Glamsterdam tiếp theo cũng hướng đến việc cải thiện đồng bộ node và xử lý block song song. Lộ trình chính thức của Ethereum cho biết Glamsterdam đang được thử nghiệm trên mạng lưới dành cho nhà phát triển và dự kiến triển khai mainnet trong quý IV năm 2026, nhưng chưa ấn định ngày cụ thể.

Block-Level Access Lists (BAL), dự kiến được đưa vào Glamsterdam, là chức năng sắp xếp trước dữ liệu mà block sẽ truy cập và trạng thái cuối cùng. BAL được thiết kế để node cập nhật trạng thái bằng kết quả cuối cùng thay vì thực thi lại tuần tự mọi giao dịch, với mục tiêu hỗ trợ thực thi song song và đọc đĩa song song.

Con số 461 GiB lần này là trường hợp của một cấu hình Geth cụ thể gắn với phát biểu của Buterin, không thay thế cho thông số khuyến nghị đối với node thông thường.

Nhìn chung, trường hợp 461 GiB cho thấy gánh nặng vận hành node Ethereum có thể giảm trong một số môi trường nhất định. Sau quá trình kiểm chứng trên mạng lưới dành cho nhà phát triển và testnet, việc triển khai Glamsterdam trên mainnet cùng lịch trình cụ thể sẽ được quyết định.