Chạy một nút Geth: Go-Ethereum trên mạng Ethereum

Bạn quyết định ngừng tin tưởng vào điểm cuối Infura để xử lý lưu lượng truy cập ví của mình. Có thể một người bạn đã đề nghị hướng dẫn bạn cách đặt cọc 32 ETH. Có thể dApp của bạn chỉ còn một bước nữa là bị lỗi do vượt quá giới hạn tốc độ truy cập vào ngày ra mắt. Dù lý do là gì, câu tiếp theo luôn giống nhau: bạn cần chạy một node Geth.

Câu đó nghe có vẻ nặng nề hơn thực tế. Geth, viết tắt của go-ethereum, là máy khách thực thi Ethereum đầu tiên, được viết bằng ngôn ngữ lập trình Go bởi Jeffrey Wilcke và một nhóm mã nguồn mở toàn cầu vào năm 2014. Một máy tính xách tay hiện đại với ổ SSD dung lượng lớn có thể chạy được nó. Một thiết bị Hetzner giá 30 đô la một tháng cũng vậy. Những thứ khiến mọi người bối rối không phải là các lệnh cài đặt. Mà là các lựa chọn xung quanh chúng: chọn chế độ đồng bộ nào, ghép Geth với máy khách đồng thuận nào, điều gì xảy ra sau khi Hợp nhất, làm thế nào để giữ cho nút hoạt động khi ổ đĩa đầy lúc 2 giờ sáng.

Hướng dẫn này sẽ trình bày toàn bộ quy trình. Từ việc mua phần cứng, cài đặt, đồng bộ hóa Snap, ghép nối sau khi hợp nhất với máy khách đồng thuận, bảng điều khiển JavaScript, tài khoản và Clef, thiết lập trình xác thực, đến các lỗi thường gặp. Sau khi hoàn thành, bạn sẽ biết chính xác máy của mình đang làm gì khi các nhật ký màu trắng xuất hiện và phải làm gì khi chúng dừng lại.

Nút Geth là gì và tại sao nó lại quan trọng ngày nay

Một nút Geth là một máy tính chạy ứng dụng khách go-ethereum và được kết nối với mạng ngang hàng của Ethereum. Máy này tải xuống các khối. Nó xác minh mọi giao dịch. Nó chạy các hợp đồng thông minh trên Máy ảo Ethereum. Nó giữ một bản sao được đồng bộ hóa của trạng thái thế giới. Từ bên ngoài, nó trông giống như một tiến trình hoạt động âm thầm lắng nghe trên một vài cổng. Bên trong, nó là một người ghi sổ cứng đầu từ chối chấp nhận lời nói của bất kỳ ai khác về sổ cái. Nó giữ bản sao riêng của dữ liệu chuỗi khối, cho phép ví của bạn kiểm tra số dư tài khoản hoặc gửi giao dịch lên chuỗi và cho phép ứng dụng phi tập trung (dApp) của bạn tương tác trực tiếp với chuỗi khối thay vì thông qua API của bên thứ ba.

Tại sao tất cả những điều này lại quan trọng vào năm 2026? Đó là do sự tập trung. Hầu hết lưu lượng truy cập dApp công khai trên Ethereum đều đi qua một số ít nhà cung cấp RPC được lưu trữ – Infura, Alchemy, QuickNode và một vài công ty nhỏ hơn. Chỉ riêng Infura đã xử lý hơn 600 tỷ yêu cầu blockchain vào năm ngoái. Chúng đáng tin cậy, nhưng phần lớn là vậy. Chúng cũng là điểm yếu duy nhất: khi một nhà cung cấp gặp sự cố ở một khu vực, một nửa số ví trỏ đến điểm cuối đó sẽ hiển thị số dư lỗi thời và các giao dịch bị kẹt cho đến khi ai đó khắc phục sự cố. Hãy tự vận hành node Geth của riêng bạn và toàn bộ loại lỗi đó sẽ không còn là vấn đề của bạn nữa.

Đây cũng là một cuộc chơi về số lượng. Công cụ theo dõi node của Etherscan thống kê được khoảng 13.678 node Ethereum đang hoạt động trên toàn thế giới tính đến tháng 4 năm 2026. Hoa Kỳ nắm giữ 37,55% trong số đó — khoảng 5.171 node. Đức có 16,05%. Trung Quốc, 12,06%. Việc tạo thêm một node không phải là điều phi thường. Nó chỉ đơn giản là hữu ích, và mạng lưới vẫn âm thầm trông chờ vào việc mọi người làm điều đó.

Còn một lý do sâu xa hơn nữa. Ethereum vẫn là Ethereum bởi vì bất kỳ ai cũng có thể xác minh nó mà không cần xin phép. Geth là ứng dụng khách phổ biến nhất thực hiện việc xác minh đó. Mỗi khi một nhà điều hành độc lập khác đưa một nút Geth mới trực tuyến, việc chiếm đoạt chuỗi khối lại trở nên khó khăn hơn một bậc. Logic này đã có từ trước khi sáp nhập và vẫn không hề suy yếu kể từ đó.

Geth, Go Ethereum và Giao thức Ethereum

Ba cái tên, một dự án. Mọi người thường ghép chúng lại với nhau trong cuộc trò chuyện mà không có vấn đề gì, nhưng đây là sự phân tách thực tế.

Giao thức Ethereum không phải là mã nguồn. Nó là một bản đặc tả, được viết trên tờ giấy vàng và một loạt các EIP (Emotional Improvement Property), và bất kỳ ai cũng có thể viết một chương trình client cho nó. Go Ethereum, đôi khi được viết là go-ethereum, là bản triển khai giao thức Ethereum bằng ngôn ngữ Go. Geth là chương trình dòng lệnh bên trong Go Ethereum mà bạn chạy trên dòng lệnh, cấu hình bằng các cờ (flags), và sử dụng để tương tác với mạng Ethereum. Mọi thứ khác trong kho lưu trữ đều là các thư viện và công cụ hỗ trợ được bao bọc xung quanh nó. Một "nút Geth" chỉ đơn giản là một máy mà bạn đã khởi động Geth, trỏ nó đến thư mục `chaindata`, và cho phép nó giao tiếp với mạng chính Ethereum.

Có nhiều thư viện client khác nhau cho cùng một giao thức. Nethermind, viết bằng C#. Besu, viết bằng Java. Erigon và Reth, cả hai đều viết bằng Rust. Cùng một định dạng truyền tải dữ liệu. Nhưng mã nguồn khác nhau, hiệu năng khác nhau, lịch sử hoạt động khác nhau.

Geth là dự án lâu đời nhất trong số đó. Hơn 400 người đã đóng góp; Péter Szilágyi đã điều hành dự án này trong nhiều năm. Dự án thuộc về Ethereum Foundation; mã nguồn nằm tại ethereum/go-ethereum trên GitHub; giấy phép là GNU General Public License, GPL-3.0 cho các tệp nhị phân và LGPL-3.0 cho mã thư viện. Phiên bản ổn định hiện tại, khi tôi viết bài này, là v1.17.2 — tên mã "EMF Suppressor" — ra mắt ngày 30 tháng 3 năm 2026. Nó đã vá ba lỗ hổng CVE (CVE-2026-26313, -26314, -26315) và hướng dẫn máy khách cách đồng bộ hóa với các chuỗi có lịch sử trước sự kiện Prague đã được cắt tỉa.

Một vài công cụ liên quan khác được tích hợp cùng Geth. Clef là một công cụ ký riêng biệt giúp giữ khóa riêng tư của bạn tách biệt khỏi chính node. Abigen chuyển đổi ABI của Solidity thành các liên kết Go mà bạn có thể sử dụng. Công cụ `evm` cho phép bạn chạy mã bytecode một cách độc lập khi cần gỡ lỗi một vấn đề cụ thể. Không công cụ nào là bắt buộc. Bạn sẽ cần đến ít nhất một trong số chúng trong vòng một tuần.

Tại sao cần vận hành một Node: Bảo mật, Tốc độ, Chủ quyền

Hầu hết những người tự vận hành node Geth của riêng mình đều chọn một trong ba lý do sau. Thứ nhất là quyền riêng tư. Khi ví điện tử giao tiếp với máy chủ RPC, nhà cung cấp dịch vụ sẽ thấy mọi địa chỉ, mọi lệnh gọi hợp đồng và mọi yêu cầu báo giá. Một node tự lưu trữ sẽ phá vỡ liên kết đó. Nhà cung cấp dịch vụ không tồn tại. Ví của bạn hỏi máy tính của bạn, máy tính của bạn hỏi mạng và chỉ máy tính của bạn mới thấy được mô hình đó.

Lý do thứ hai là hiệu năng. Các RPC được lưu trữ sẽ bị giới hạn tốc độ. Gói miễn phí của Infura giới hạn ở 100.000 yêu cầu mỗi ngày; gói Team có giá 225 đô la mỗi tháng cho 75 triệu yêu cầu mỗi ngày. Một node cục bộ phục vụ lưu lượng truy cập của bạn với tốc độ bộ nhớ và không mất phí cho mỗi lần gọi. Đối với một dApp tải trạng thái trên mỗi lần tải trang, sự khác biệt về độ trễ là đáng chú ý. Đối với một bot giao dịch chênh lệch giá quét mempool, đó là sự khác biệt giữa việc thực hiện giao dịch và việc chỉ nhìn thấy nó trôi qua. Bản thân Mainnet đã xử lý khoảng 200,4 triệu giao dịch trong quý 1 năm 2026, đạt đỉnh điểm 2,88 triệu giao dịch vào ngày 16 tháng 1, vì vậy một node có thể theo kịp mạng lưới đang thực sự làm việc hiệu quả.

Quyền tự chủ là yếu tố thứ ba. Nếu bạn đặt cược trên Ethereum, mạng lưới sẽ mong đợi trình xác thực của bạn xuất bản một khối khi đến lượt của nó. Việc ủy thác việc xuất bản đó cho một RPC dùng chung về mặt kỹ thuật là được phép nhưng lại dễ gặp rủi ro về mặt vận hành. Hãy tự vận hành máy khách lớp thực thi của riêng bạn và bạn sẽ kiểm soát được vị trí của mình. Điều tương tự cũng áp dụng cho những người xây dựng dApp chuyên nghiệp, các nhà phân tích on-chain, những người tìm kiếm MEV và bất kỳ ai mà công việc kinh doanh của họ phụ thuộc vào việc Ethereum phải có sẵn cho riêng họ.

Sau khi hợp nhất: Geth và ứng dụng khách đồng thuận của bạn

Trước tháng 9 năm 2022, một tiến trình Geth duy nhất thực hiện mọi thứ. Nó kết nối với mạng lưới. Nó vận hành EVM. Nó chọn ra khối thắng cuộc trong số các khối cạnh tranh thông qua khai thác bằng chứng công việc. Sự kiện Merge đã chia công việc đó làm đôi. Geth vẫn vận hành EVM và duy trì trạng thái. Một chương trình thứ hai — máy khách đồng thuận — hiện xử lý bằng chứng cổ phần: truyền tải thông tin về các khối giữa các trình xác thực, bỏ phiếu về khối nào được tính và cho Geth biết nhánh nào là chính tắc.

Vì vậy, mọi thiết lập Geth hiện đại đều là một cặp, chứ không phải một tiến trình đơn lẻ. Hãy chọn một máy khách đồng thuận để chạy song song với nó. Các lựa chọn bao gồm Lighthouse (Rust), Prysm (Go), Teku (Java), Nimbus (Nim) và Lodestar (TypeScript). Hai tiến trình giao tiếp với nhau qua một kênh riêng tư được gọi là API Engine, được bảo vệ bởi một mã bí mật JWT mà bạn tạo một lần và chuyển cho cả hai phía bằng lệnh `--authrpc.jwtsecret`.

Khởi động Geth một mình, không có máy khách đồng thuận, và nhật ký sẽ hiển thị thông báo kiểu như "Mạng sau khi hợp nhất, nhưng không thấy máy khách beacon. Vui lòng khởi chạy một máy khách để theo dõi chuỗi!" Nút sẽ nằm đó, lịch sự nhưng vô dụng. Bản thân Geth không còn là một nút Ethereum hoàn chỉnh nữa. Cặp đôi này mới là đơn vị hoàn chỉnh.

Sự đa dạng của các client rất quan trọng ở đây. Cộng đồng Ethereum yêu cầu các nhà điều hành phân bổ đều các triển khai trên cả hai phía của sự phân tách, bởi vì nếu hơn hai phần ba số người xác thực sử dụng cùng một client bị lỗi, những người xác thực đó sẽ phải chịu hình phạt cắt giảm 32 ETH khi có sự cố xảy ra. Số liệu mới nhất từ clientdiversity.org cho thấy Geth chiếm khoảng 41% số client được sử dụng vào năm 2026; báo cáo năm 2026 của Stake.fish cho biết con số này gần 50%. Dù sao đi nữa, con số này đã giảm so với hơn 86% vào năm 2023, nhưng vẫn cao hơn ngưỡng an toàn 33% mà cộng đồng coi là lý tưởng. Đó là lý do tại sao một số nhà điều hành mới cố tình chọn Nethermind, Besu hoặc Reth — mặc dù Geth là bước đi đầu tiên dễ dàng hơn.

Pectra, bản nâng cấp Prague + Electra được kích hoạt vào ngày 7 tháng 5 năm 2025, cũng đã định hình lại công việc hàng ngày của người vận hành. EIP-7251 đã nâng số dư hiệu dụng tối đa cho mỗi trình xác thực từ 32 ETH lên 2.048 ETH. Người vận hành staking trước đây phải quản lý 1.000 trình xác thực riêng lẻ giờ đây có thể hợp nhất chúng thành 16 trình xác thực lớn. EIP-6110 đã rút ngắn thời gian chờ giữa lúc gửi tiền và lúc hoạt động từ khoảng 12 giờ xuống còn khoảng 13 phút. EIP-7002 cho phép các trình xác thực tự kích hoạt việc rút tiền của mình, thay vì phải nhờ người ký gửi tiền ban đầu thực hiện. Việc vận hành một hệ thống trình xác thực ghép nối Geth vào năm 2026 đơn giản hơn đáng kể so với năm 2024.

Phần cứng: CPU, RAM và SSD cho các nút Geth

Tiêu chuẩn phần cứng thực tế vào năm 2026 cao hơn so với những gì tài liệu chính thức thừa nhận. Hãy lên kế hoạch cho ba năm tới, chứ không phải ba năm cuối cùng.

Dung lượng lưu trữ là điều khiến các nhà khai thác mới ngạc nhiên. Một node Geth đầy đủ, được đồng bộ hóa nhanh chóng và cắt tỉa, hiện có dung lượng khoảng 650 GB. Tài liệu của Geth cho biết nó tăng thêm khoảng 14 GB mỗi tuần. Thêm một máy khách đồng thuận. Thêm vài tháng dự phòng tăng trưởng. Thêm bất kỳ lưu lượng RPC L2 nào bạn dự định phục vụ. Bạn sẽ nhanh chóng cần từ 4 đến 8 TB NVMe.

Vài lời về loại ổ đĩa. Về mặt kỹ thuật, SSD SATA vẫn hoạt động. Tuy nhiên, chúng cũng làm gián đoạn quá trình đồng bộ hóa và bỏ sót các chứng thực khi chịu tải. NVMe không còn là lựa chọn khả thi vào năm 2026. Ổ đĩa cơ học đã không còn phù hợp từ nhiều năm nay. Nếu nhà cung cấp của bạn chỉ cung cấp SATA ở gói giá rẻ, hãy nâng cấp lên gói cao hơn. Phép tính rất khắc nghiệt: một ổ đĩa SATA bị kẹt sẽ khiến bạn mất đi phần thưởng xác thực mỗi chu kỳ.

RAM là cạm bẫy thứ hai. Trang thông tin phần cứng chính thức của Geth, được cập nhật lần cuối vào năm 2023, vẫn ghi là 16 GB. Đến năm 2026, Cherry Servers, Chainstack và bacloud đều thống nhất mức tối thiểu là 32 GB, và 64 GB là mức lý tưởng. Geth lưu trữ một lượng lớn trạng thái trong bộ nhớ cache. Máy khách đồng thuận cũng muốn có phần của mình. Thêm Prometheus, Grafana, và bất kỳ phần mềm nào khác bạn thực sự sử dụng, thì 16 GB sẽ nhanh chóng hết.

CPU là yếu tố dễ đánh giá nhất trong ba yếu tố. Các chip máy tính để bàn hiện đại có nhiều khả năng xử lý hơn mức cần thiết. Tốc độ xung nhịp hầu như không phải là vấn đề. Số lượng lõi và các tập lệnh hiện đại mới là yếu tố quan trọng hơn. AVX2 giúp xác thực chữ ký nhanh chóng. Tám lõi giúp ngăn chặn tình trạng quá tải đồng bộ làm treo máy. Nhìn về phía trước, giới hạn gas khối đã tăng từ 30 triệu lên 45 triệu rồi lên 60 triệu từ giữa năm 2024 đến tháng 11 năm 2025. Quỹ Ethereum đã báo hiệu mức hơn 100 triệu gas cho đến năm 2026. Đó là đường cong mà bạn đang dựa vào để đánh giá, chứ không phải tải của năm ngoái.

Các chế độ đồng bộ Geth cho chuỗi khối Ethereum

Chế độ đồng bộ là nút điều chỉnh quan trọng nhất mà người vận hành Geth mới cần xoay. Chọn sai và bạn sẽ lãng phí cả tuần để tải xuống dữ liệu mà bạn thực sự không cần.

Chế độ Snap là chế độ mặc định và hầu như luôn là lựa chọn đúng đắn. Nó lấy ảnh chụp trạng thái gần nhất từ các máy chủ ngang hàng, sau đó âm thầm điền các tiêu đề và biên lai phía sau. Bạn sẽ có một node Geth hoạt động trong vài ngày trên phần cứng tốt. Nó phục vụ ví, dApp và trình xác thực rất tốt. Điều duy nhất nó không thể làm là trả lời các câu hỏi lịch sử như "số dư của Vitalik vào ngày 7 tháng 10 năm 2017 là bao nhiêu?". Nếu bạn không quan tâm đến điều đó, bạn không cần phải nghĩ đến chế độ đồng bộ nữa.

Chế độ đồng bộ đầy đủ vẫn được cung cấp. Hầu hết mọi người không cần đến nó. Chế độ đầy đủ sẽ truy ngược từng khối về khối gốc và chạy lại mọi giao dịch, do đó máy khách có thể xác minh chuỗi khối từ đầu đến cuối thay vì chỉ tin tưởng vào ảnh chụp nhanh. Hữu ích nếu bạn lo ngại về ảnh chụp nhanh, hoặc nếu bạn đang tạo một kho lưu trữ lịch sử đã được cắt tỉa. Không hữu ích cho các hoạt động thông thường.

Kho lưu trữ là phần nặng nề nhất, và năm 2025 là thời điểm các node lưu trữ thay đổi. Cho đến khi phát hành phiên bản 1.16, một node lưu trữ có nghĩa là 12 đến 20 TB SSD tốc độ cao — về cơ bản là một máy chủ nhỏ. Phiên bản 1.16 đã phát hành chế độ lưu trữ dựa trên đường dẫn, lưu trữ trạng thái lịch sử dưới dạng khác biệt ngược và giảm yêu cầu về dung lượng đĩa xuống còn khoảng 1,9 đến 2,0 TB trên mạng chính. Điều đó giúp giảm dung lượng của Geth xuống gần bằng Erigon (~1,77 TB). Ban đầu, nhược điểm là chế độ lưu trữ dựa trên đường dẫn không hỗ trợ bằng chứng Merkle lịch sử (`eth_getProof` trên các khối cũ). Các trình lập chỉ mục DeFi và các khối lượng công việc nặng về bằng chứng khác vẫn cần chế độ lưu trữ dựa trên hàm băm cũ. Phiên bản 1.17.0, vào tháng 2 năm 2026, đã thêm hỗ trợ bằng chứng vào chế độ dựa trên đường dẫn trong một số cấu hình — hãy kiểm tra ghi chú phát hành để biết phiên bản chính xác của bạn. Các nhà điều hành kho lưu trữ điển hình là các trình khám phá khối, các nhóm pháp y và các công ty phân tích nghiêm túc. Hầu hết những người đọc hướng dẫn này sẽ không bao giờ cần đến chúng.

Một lưu ý nhỏ. Chế độ máy khách nhẹ, cờ cũ `--syncmode "light"`, đã bị loại bỏ và không còn được duy trì trên mạng chính. Nếu một hướng dẫn năm 2026 yêu cầu bạn khởi động Geth ở chế độ nhẹ, thì hướng dẫn đó đã lỗi thời.

Cài đặt Geth trên Ubuntu, macOS và Windows

Bước cài đặt rất ngắn gọn. Hãy chọn nền tảng mà bạn thực sự định sử dụng, chứ không phải nền tảng trên máy tính xách tay của bạn.

Linux / Ubuntu (hệ điều hành chủ lực)

Hầu hết các node Geth đang hoạt động trên hệ điều hành Ubuntu. Nhóm Ethereum duy trì một PPA (Product Property Package), và chỉ cần ba lệnh thông qua trình quản lý gói của Ubuntu là bạn có thể cài đặt được file nhị phân hoạt động:

```

sudo add-apt-repository -y ppa:ethereum/ethereum

sudo apt-get update

sudo apt-get install ethereum

```

Chạy lệnh `geth version` để xác nhận. PPA theo dõi phiên bản ổn định mới nhất. Trong môi trường sản xuất, bạn thường cố định một bản dựng đã được kiểm chứng bằng lệnh như `apt-get install ethereum=1.17.2-...` và nâng cấp theo lịch trình đều đặn hơn là "bất cứ khi nào apt muốn".

macOS (thân thiện với nhà phát triển)

Trên macOS, Homebrew sẽ thực hiện việc đó. Chỉ cần hai dòng lệnh:

```

brew tap ethereum/ethereum

brew install ethereum

```

Máy Mac rất tuyệt vời cho các thử nghiệm trên mạng thử nghiệm và phát triển dApp. Tuy nhiên, hầu như không ai chạy trình xác thực mạng chính trên máy Mac. Quản lý năng lượng quá mạnh tay, và macOS sẽ dễ dàng đưa nút beacon của bạn vào chế độ ngủ vào những thời điểm không thích hợp.

Windows

Có các trình cài đặt `.exe` và các tệp lưu trữ `.zip` trên geth.ethereum.org và trên trang phát hành GitHub của dự án. Nhấp vào trình cài đặt, cho phép nó chỉnh sửa PATH của bạn, sau đó mở Command Prompt hoặc PowerShell và chạy lệnh `geth version`. Nó sẽ trả lời.

Windows Server hoàn toàn có thể chạy một node Geth độc lập. Các stack xác thực thường ưu tiên Linux vì các client đồng thuận được phát triển cho Linux trước tiên, nhưng bạn có thể kết hợp cả hai nếu muốn. Phần còn lại của hướng dẫn này viết các lệnh theo kiểu shell Linux. Việc chuyển đổi sang PowerShell chủ yếu liên quan đến dấu phân cách đường dẫn và cách xuống dòng khác nhau.

Docker

Lệnh `docker pull ethereum/client-go:stable` sẽ tạo ra một container sạch. Docker là cách dễ nhất để kiểm tra bản phát hành Geth mới mà không làm ảnh hưởng đến máy chủ của bạn. Nó cũng là một giải pháp triển khai sản phẩm đáng tin cậy nếu nhóm của bạn đã quen thuộc với container. Một lưu ý: ổ đĩa Docker chứa `chaindata` phải nằm trên NVMe. Việc đặt nó trên ổ đĩa EBS thông thường, kho lưu trữ HDD hoặc ổ đĩa Docker Desktop trên máy Mac sẽ gây ra hiện tượng "kẹt đồng bộ" như mọi vấn đề được thảo luận trên Reddit.

Xây dựng từ mã nguồn

Để biên dịch từ mã nguồn, bạn cần Go 1.23 trở lên và trình biên dịch C. Lệnh `make geth` chỉ biên dịch node. Lệnh `make all` sẽ biên dịch toàn bộ bộ tiện ích: geth, clef, abigen, evm, devp2p, rlpdump. Hãy sử dụng biên dịch từ mã nguồn khi bạn muốn phát hành một phiên bản chưa được đóng gói hoặc khi bạn có một bản vá riêng tư mà bạn không muốn duy trì dưới dạng một nhánh riêng.

Chạy Geth: Đồng bộ hóa lần đầu và Bảng điều khiển JSON-RPC

Tệp nhị phân đã được cài đặt, mã bí mật JWT đã được tạo, máy khách đồng thuận đã sẵn sàng. Lệnh đầu tiên trên máy chủ mạng chính trông đại khái như thế này:

```

geth \

--mainnet \

--datadir /var/lib/geth \

--syncmode snap \

--http \

--http.addr 127.0.0.1 \

--http.port 8545 \

--http.api eth,net,web3 \

--authrpc.addr 127.0.0.1 \

--authrpc.port 8551 \

--authrpc.jwtsecret /etc/geth/jwt.hex \

--authrpc.vhosts localhost

```

Ba cổng thực hiện chức năng ở đây. Cổng 30303 qua TCP và UDP — đó là đường truyền ngang hàng của bạn với phần còn lại của Ethereum. Cổng 8545, cổng HTTP-RPC mà ví và các tập lệnh của bạn đi qua. Cổng 8551, API của Engine, chỉ có thể truy cập được bởi máy khách đồng thuận của bạn và được bảo vệ bởi khóa bí mật JWT.

Để can thiệp vào tiến trình đang chạy của node, hãy gắn console Geth. (Đây là một console JavaScript được tích hợp với API của node.) Mở một shell thứ hai:

```

geth attach http://127.0.0.1:8545

```

Giờ đây, mọi phương thức JSON-RPC đều là một lệnh gọi JavaScript. `eth.blockNumber`. `net.peerCount` (khoảng ba mươi là mức bình thường trên mạng chính). `eth.syncing` trả về `false` khi nút đã bắt kịp. Muốn kiểm tra số dư? `web3.fromWei(eth.getBalance('0x...'), 'ether')`. Đó là toàn bộ giao diện tương tác.

Tiếp theo là tập tin nhật ký. Hãy theo dõi nó. Dòng bạn cần thấy là `Imported new chain segment`. Điều đó có nghĩa là Geth đã bắt kịp và đang theo kịp tốc độ, xử lý từng danh sách giao dịch mới từ mạng blockchain Ethereum khi mạng lưới chuyển chúng đi. Nếu nhật ký của bạn chỉ ghi `Looking for peers` và không có gì khác, tường lửa đang chặn các kết nối P2P đến. Hãy mở cổng 30303 trên TCP và UDP, khởi động lại Geth, và thử lại. Đó là cách khắc phục trong chín trường hợp trên mười.

Để tự động hóa, mọi thư viện Ethereum đáng dùng đều sử dụng JSON-RPC qua HTTP, hoặc qua WebSocket nếu bạn cũng truyền tham số `--ws`. ethers.js. web3.js. viem. Client Go. Client Python. Tất cả đều xử lý node Geth cục bộ của bạn giống hệt như Infura — chỉ cần trỏ chúng đến `http://127.0.0.1:8545` và dừng lại. Mã vẫn giữ nguyên. Điều duy nhất thay đổi là ai trả lời cuộc gọi.

Sử dụng Geth: Kế toán, Sổ cái và Giao dịch

Geth vẫn cung cấp trình quản lý tài khoản, nhưng khuyến nghị hiện đại là tách biệt việc ký kết khỏi node bằng cách chạy Clef. Clef là một chương trình nhỏ riêng biệt lưu trữ các khóa của bạn và yêu cầu xác nhận rõ ràng mỗi khi có thứ gì đó cố gắng sử dụng chúng.

Việc tạo tài khoản thông qua Clef diễn ra như sau:

```

clef newaccount --keystore /var/lib/geth/keystore

```

Clef yêu cầu mật khẩu có ít nhất mười ký tự. Nó ghi một tệp kho khóa được mã hóa và trả lại cho bạn một địa chỉ. Địa chỉ đó là một tài khoản thuộc sở hữu bên ngoài (EOA) — cùng loại với ví phần cứng hoặc MetaMask. Không có gì đặc biệt cả.

Để Geth sử dụng Clef, hãy trỏ node đến socket IPC của Clef: `--signer=/path/to/clef.ipc`. Từ thời điểm đó trở đi, mọi yêu cầu giao dịch, dù đến từ bảng điều khiển Geth hay từ một dApp sử dụng API JSON-RPC, đều phải được phê duyệt tại thiết bị đầu cuối Clef. Đó là mô hình mà nhóm Geth khuyến nghị vào năm 2026. Khóa nằm ngoài node. Bản thân node không thể tự mình chi tiêu bất kỳ wei nào.

Quá trình chuyển dữ liệu từ máy chơi game diễn ra như sau:

```

eth.sendTransaction({

from: '0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec',

to: '0xce8dba5e4157c2b284d8853afeeea259344c1653',

value: web3.toWei(0.1, 'ether')

});

```

Clef hiện lên. Bạn xác nhận. Giao dịch được đưa vào mempool, và vài giây sau nó nằm trong một block. Đằng sau dòng lệnh duy nhất đó, Geth đã thực hiện việc tra cứu nonce, ước tính phí, chuyển giao chữ ký cho Clef, phát sóng và kiểm tra tính hợp lệ. Vòng lặp tương tự chạy trong mọi dApp.

Đối với các tác vụ phức tạp hơn, cùng một điểm cuối JSON-RPC chấp nhận việc gửi giao dịch, đăng ký sự kiện, gọi hàm xem và theo dõi. Từ góc độ thư viện, phiên bản Geth cục bộ của bạn không thể phân biệt được với một node được lưu trữ — ngoại trừ việc nó nhanh hơn, miễn phí mỗi lần gọi và thuộc sở hữu của bạn.

Thiết lập Trình xác thực: Đặt cọc Ether và nhận phần thưởng

Sau khi nút Geth của bạn được đồng bộ hóa và ghép nối với máy khách đồng thuận, việc thêm trình xác thực chủ yếu là cấu hình. Bạn không cần cài đặt nút mới. Lớp thực thi (Geth) tiếp tục hoạt động. Máy khách đồng thuận sẽ đảm nhận vai trò trình xác thực: nó ký các chứng thực mỗi kỷ nguyên, và khi giao thức chọn trình xác thực của bạn, nó sẽ yêu cầu Geth tập hợp nội dung khối.

Có ba bước cần thực hiện để đưa hệ thống trực tuyến. Đầu tiên là khoản tiền gửi 32 ether. Bạn tạo khóa xác thực bằng CLI gửi tiền chính thức, gửi giao dịch gửi tiền đến hợp đồng trên mạng chính và chờ kích hoạt. Thứ hai là quy trình máy khách xác thực. Nó chạy song song với nút beacon, giữ khóa ký của bạn và ký các chứng thực theo lịch trình. Thứ ba là MEV-Boost hoặc thiết lập relay, nếu bạn muốn nhận phần thưởng theo thứ tự giao dịch ngoài phần thưởng cơ bản. Bản thân Geth không chạy trình xác thực. Máy khách đồng thuận mới là thứ chạy. Geth là điểm cuối thực thi xây dựng tải trọng khối thực tế khi vị trí của trình xác thực của bạn được kích hoạt.

Hàng ngày, các trình xác thực quan tâm đến ba con số: số lần xác thực bị bỏ sót, thời gian đồng bộ hóa và áp lực ổ đĩa. Số lần xác thực bị bỏ sót hầu như luôn bắt nguồn từ một nút bị tụt lại phía sau, và điều này hầu như luôn dẫn đến I/O ổ đĩa hoặc mất kết nối với máy chủ ngang hàng. Áp lực ổ đĩa trên Geth là nguyên nhân điển hình. Nếu hiệu suất giảm xuống dưới thông số kỹ thuật NVMe được khuyến nghị, hiệu quả xác thực của bạn sẽ giảm. Phần thưởng cũng giảm theo.

Hầu hết những người tham gia staking tại nhà đều sử dụng một máy tính mini chuyên dụng: Intel NUC, Beelink, hoặc một máy tính tự lắp ráp với bộ xử lý Ryzen. Chi phí phần cứng ban đầu dao động từ 800 đến 2.000 đô la. Điện và internet cộng thêm từ 10 đến 20 đô la mỗi tháng. Theo phân tích của Coin Bureau năm 2026, một trình xác thực Hetzner chuyên nghiệp có giá từ 30 đến 40 đô la mỗi tháng, một node đầy đủ cơ bản của AWS dưới 100 đô la, và một node lưu trữ của AWS khoảng 1.500 đô la. Staking cá nhân mang lại lợi nhuận khoảng 4% APY trên phần thưởng cơ bản và tăng lên 5-6% với MEV-Boost; trên phần cứng tại nhà, việc này sẽ hòa vốn trong khoảng 4 đến 6 tháng với giá Ether hiện tại. Tính đến cuối năm 2025, mạng lưới có khoảng 1,06 triệu trình xác thực hoạt động, nắm giữ từ 35 đến 37 triệu ETH (29 đến 31% tổng nguồn cung). Riêng Lido kiểm soát 27,7% tổng số ETH được stake. Coinbase nắm giữ 8,4%. Mỗi trình xác thực độc lập bổ sung đều âm thầm làm lệch trọng tâm theo hướng ngược lại, đó là lý do tại sao việc đặt cược riêng lẻ vẫn còn được nhiều người thực hiện.

Mạng thử nghiệm so với mạng chính: Nên đặt node Ethereum ở đâu?

Đừng bắt đầu trên mạng chính (mainnet). Sai lầm trên mạng thử nghiệm (testnet) thì không tốn kém gì, và chúng cũng không hề rẻ hơn bất kỳ khoản phí nào. Geth xử lý mọi mạng được hỗ trợ chỉ với một cờ duy nhất.

Hai mạng thử nghiệm Ethereum mà bạn nên quan tâm trong năm 2026 là Holesky, mạng thử nghiệm lâu đời tập trung vào trình xác thực, và Sepolia, mạng nhẹ hơn, tập trung vào ứng dụng. Muốn tạo node Geth trên Sepolia? Hãy đổi `--mainnet` thành `--sepolia`. Còn Holesky? `--holesky`. Thư mục dữ liệu của bạn nên là một đường dẫn riêng biệt với thư mục `chaindata` trên mạng chính. Nếu bạn sử dụng lại cùng một thư mục, Geth sẽ từ chối khởi động vì ID chuỗi không khớp — đây là loại thông báo lỗi chỉ mất ba mươi giây để khắc phục nhưng lại mất cả giờ để tìm ra.

Ether trên testnet là miễn phí. Các trang web phát Ether miễn phí như Paradigm Multifaucet và Sepolia faucet tại faucet.sepolia.dev sẽ cung cấp đủ Sepolia ETH để triển khai hợp đồng, chạy thử nghiệm tích hợp và thực hiện vài nghìn giao dịch. "Ether" ở đây là ảo. Mọi thứ khác đều là thật: EVM hoạt động giống nhau, API JSON-RPC giống nhau, sự kết nối với máy khách đồng thuận của bạn giống nhau, và những khó khăn khi vận hành cũng giống nhau. Hãy chạy hệ thống của bạn trên Sepolia trong một tuần trước khi chuyển bất kỳ thứ gì lên mainnet.

Các mạng thử nghiệm cũ đã biến mất. Ropsten, Rinkeby, Kovan, Goerli — tất cả đều đã ngừng hoạt động. Nếu hướng dẫn vẫn yêu cầu bạn khởi động Geth với `--ropsten`, thì đó là phiên bản trước khi hợp nhất và bạn nên đóng tab đó lại.

Để có một môi trường riêng tư thực sự, hãy tự vận hành mạng lưới của riêng bạn. Chế độ `--dev` của Geth khởi động một chuỗi đơn nút chỉ trong vài giây, rất tuyệt vời cho việc kiểm thử đơn vị. Đối với mạng riêng tư nhiều máy, hãy viết một tệp `genesis.json` tùy chỉnh, chia sẻ nó giữa các máy và khởi động mỗi tiến trình Geth với `--datadir` trỏ đến thư mục chaindata mới. Khung Kurtosis đóng gói tất cả những điều này đằng sau một lệnh duy nhất nếu bạn không muốn tự mình thiết lập kết nối.

Các sự cố thường gặp và cách khắc phục sự cố trên Geth Node.

Hầu hết các sự cố liên quan đến Geth đều tuân theo một số khuôn mẫu nhất định. Việc khắc phục thường nhanh chóng một khi bạn nhận ra được hình dạng của vấn đề.

Quá trình đồng bộ bị kẹt ở vài phần trăm. Nút Geth của bạn đang trực tuyến nhưng không bắt kịp: số lượng peer quá thấp, băng thông của bạn bị bão hòa hoặc ổ đĩa không thể theo kịp. Kiểm tra `net.peerCount` trong bảng điều khiển. Nếu nó dưới mười lăm, cổng P2P đến của bạn bị tường lửa chặn. Mở cổng 30303 TCP và UDP. Nếu hoạt động bình thường, hãy chạy `iostat -xm 5` trên Linux trong quá trình đồng bộ; nếu SSD đạt mức sử dụng 100%, bạn đang bị giới hạn bởi I/O và cần bộ nhớ nhanh hơn. Lưu ý cụ thể về phiên bản: Geth v1.17.1 (ngày 3 tháng 3 năm 2026) được phát hành để khắc phục lỗi hồi quy đồng bộ nhanh trong v1.17.0; nếu bạn đang sử dụng phiên bản đó, nâng cấp sẽ khắc phục được sự cố.

"Mạng sau khi hợp nhất, nhưng không thấy máy khách beacon." Máy khách đồng thuận không chạy, khóa bí mật JWT không khớp hoặc máy khách đồng thuận đang trỏ đến cổng AuthRPC sai. Kiểm tra đường dẫn JWT, cổng 8551 và đảm bảo cả hai tiến trình đều được khởi chạy với cùng một tệp bí mật.

Ổ cứng sẽ đầy qua đêm. Đồng bộ nhanh (Snap sync) có thể làm tăng đột biến mức sử dụng ổ cứng trong giai đoạn khôi phục trạng thái ban đầu. Quá trình cắt tỉa (pruning) sẽ chạy tự động sau đó. Nếu bạn bắt đầu với ổ SSD 1 TB, đầu đọc cuối cùng cũng sẽ đạt đến giới hạn. Giải pháp luôn là tăng dung lượng, chứ không phải cắt tỉa mạnh hơn, vì quá trình cắt tỉa của Geth đã được tinh chỉnh. Hãy chuyển dữ liệu chuỗi (chaindata) sang ổ NVMe lớn hơn và sử dụng rsync để chuyển.

Geth không khởi động được: "Không tìm thấy cơ sở dữ liệu tương thích với phiên bản geth này." Lần chạy trước đó được thực hiện trên một ID chuỗi khác, một phiên bản Geth cũ hơn hoặc trạng thái bị lỗi. Thư mục `chaindata` không khớp. Hãy đồng bộ lại vào một thư mục dữ liệu mới hoặc quay lại phiên bản Geth trước đó.

Trình xác thực bỏ sót các chứng thực. Nếu nút Geth của bạn đọc đúng mọi khối mới nhưng trình xác thực vẫn bỏ sót các chứng thực, hãy kiểm tra áp lực ổ đĩa trước, sau đó là mạng, và cuối cùng là CPU. Mẫu trong các công cụ giám sát như Netdata rất rõ ràng: PSI (Thông tin tắc nghẽn áp lực) của ổ đĩa đạt 30% trở lên trong các cửa sổ chứng thực.

Các yêu cầu RPC chậm. Một ứng dụng khách dApp nặng liên tục gọi `eth_getLogs` hoặc `debug_traceTransaction` có thể làm quá tải CPU của Geth. Hãy chuyển lưu lượng truy cập đó sang một node riêng biệt, hoặc sử dụng `--rpc.gascap` và `--rpc.txfeecap` để giới hạn các lệnh gọi tốn kém.

Một thói quen cuối cùng. Theo dõi nhật ký liên tục trong tuần đầu tiên để đảm bảo Geth hoạt động trơn tru dưới tải thực tế. Các công cụ như Netdata, Prometheus + Grafana, hoặc đơn giản là `journalctl -fu geth` sẽ giúp phát hiện các lỗi sớm. Đến tuần thứ hai, việc cảnh báo về các chứng thực bị bỏ sót và tốc độ đầy ổ đĩa là đủ.

Geth so với các thư viện client Ethereum khác: Những ưu và nhược điểm

Geth là bước đầu tiên mặc định. Tuy nhiên, nó không phải là lựa chọn duy nhất, và câu trả lời cho câu hỏi "Tôi có nên chuyển sang Geth không?" phụ thuộc vào nhu cầu của bạn.

Lý lẽ mà cộng đồng đưa ra để chọn một client khác ngoài Geth là sự đa dạng. Nếu một client thực thi duy nhất vượt qua được đa số tuyệt đối hai phần ba trên mainnet và phát hành bản nâng cấp lỗi, các validator trên client đó có nguy cơ bị cắt giảm. Việc chia nhỏ đội ngũ validator của bạn trên hai client sẽ giảm một nửa rủi ro đó. Đối với một người chơi cá nhân, phép toán đơn giản hơn: hãy chọn client mà bạn có thể duy trì hoạt động, vận hành nó tốt và chỉ chuyển đổi nếu bạn có lý do cụ thể. Kiến trúc node tương tự nhau trên tất cả các client, vì vậy việc chuyển đổi sau này dễ hơn bạn nghĩ. Đặc biệt, Erigon và Reth hiện đã đủ trưởng thành để trở thành các client chính, chứ không phải là những thứ chỉ để xem thử.

Marco Lucchetti

Marco Lucchetti is a senior content strategist and blockchain analyst at Plisio. With over 7 years of experience in cryptocurrency research, DeFi protocols, and payment technologies, Marco specializes in creating clear, data-driven content for a global crypto audience. His work focuses on transaction tracing, crypto compliance, and the future of blockchain infrastructure.