Chạy full node Bitcoin trên VPS

Ba điều, và chỉ hai trong số đó liên quan đến quyền riêng tư.

• Xác minh. Node của bạn tự thực thi đồng thuận — mọi chữ ký, script, khoản thưởng khối (subsidy) và điều chỉnh độ khó, đều được kiểm tra dựa trên bản sao chuỗi của chính nó. Không ai có thể khiến nó tin rằng một đồng coin tồn tại trong khi thực tế không phải vậy. Đây là phần không thể giao phó cho ai khác: một ví light (light wallet) buộc phải tin vào câu trả lời của một máy chủ.
• Quyền riêng tư ở lớp mạng. Một ví light phải nói cho ai đó biết nó quan tâm đến những địa chỉ nào. Ngay cả các giao thức lịch sự nhất cũng trao đủ thông tin để một máy chủ gom các địa chỉ của bạn vào một ví và gắn nó với một IP. Node của riêng bạn tự trả lời các truy vấn đó cục bộ.

Điều mà một node không mang lại là tính ẩn danh on-chain. Sổ cái vẫn công khai và vĩnh viễn; một node chỉ khắc phục lớp mạng mà thôi. Nếu yêu cầu của bạn là tính không thể liên kết ngay trên chuỗi, đó lại là chuyện của một chuỗi khác — hãy chạy node Monero thay vào đó — và bài VPS trả bằng crypto có thực sự ẩn danh? trình bày phần còn lại của bài toán này.

Cả hai kiểu node đều xác thực giống hệt nhau. Một node pruned tải về mọi block, kiểm tra mọi quy tắc và xây dựng cùng một tập UTXO, sau đó xóa các tệp block cũ không còn cần đến. Cái nó đánh đổi là khả năng phục vụ lịch sử: nó không thể gửi các block cũ cho một peer đang đồng bộ, không thể rescan một ví có coin từ trước mốc prune, và không thể làm nền cho một chỉ mục đọc các giao dịch lịch sử tùy ý.

Khoảng cách về dung lượng không hề nhỏ. Vào năm 2026, chuỗi unpruned đã vượt xa 700 GB và vẫn tăng thêm hàng chục GB mỗi năm — hãy kiểm tra con số hiện tại trước khi quyết định dung lượng ổ đĩa, vì nó chỉ có tăng chứ không giảm. Một node pruned với prune=5000 giữ lại khoảng 5 GB tệp block cộng với tập UTXO và các cơ sở dữ liệu riêng của Core: coi như datadir tốn 20 GB.

Vì vậy, hãy dùng pruned trừ khi bạn có lý do cụ thể để không làm vậy. Các lý do đó khá hẹp: phục vụ lại các block lịch sử cho mạng lưới, dùng txindex cho một block explorer, hoặc tự chạy một Electrum server.

• CPU. Một nhân là đủ để bắt kịp tip của chuỗi vô thời hạn. IBD là lúc các nhân CPU phát huy tác dụng, vì việc xác minh chữ ký chạy song song được — 2 đến 4 vCPU rút ngắn lần đồng bộ đầu tiên rồi sau đó trở về trạng thái nhàn rỗi. Ảo hóa KVM đầy đủ quan trọng hơn số lượng nhân: đó là sự cách ly phần cứng thật sự và kernel riêng của bạn, không phải một container dùng chung với người khác.
• RAM. 2 GB là mức sàn để một node pruned hoạt động được. dbcache mới là thông số đáng quan tâm — một hoặc hai GB bộ nhớ đệm UTXO trong lúc IBD giúp loại bỏ hàng giờ đọc ngẫu nhiên, và bạn có thể hạ nó xuống lại sau đó.
• Ổ đĩa. Kích thước như đã nêu ở trên, và nên là NVMe chứ không phải loại nào khác. IBD bị chi phối bởi việc truy cập ngẫu nhiên vào chainstate, chứ không phải bởi việc tải xuống.
• Băng thông. IBD tải toàn bộ chuỗi bất kể có pruning hay không: vài trăm GB, một lần duy nhất. Sau đó, một node đang lắng nghe (listening) sẽ tải lên đều đặn cho các peer, có thể giới hạn bằng maxuploadtarget. Mọi gói ở đây đều chạy cổng 1 Gbps với lưu lượng không giới hạn và không có hóa đơn phụ trội.

Số liệu cụ thể từ bảng giá của chúng tôi, vì “còn tùy” không phải là một câu trả lời:

• Pruned, dùng cá nhân — Cub, 1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo. Một datadir 20 GB có dư chỗ, và là khuyến nghị trung thực nhất cho phần lớn độc giả.
• Pruned, thoải mái — Scout, 2 vCPU / 4 GB / 70 GB, $9.00/mo. Giảm gần một nửa thời gian chờ đồng bộ. Nếu máy này sẽ đảm nhiệm nhiều việc hơn một, hãy bắt đầu từ đây.
• Node cộng Lightning cộng giám sát — Runner, 3 vCPU / 6 GB / 100 GB, $14.00/mo.
• Full archive — nơi sự trung thực thắng việc chèo kéo bán hàng. Garmr (500 GB, $69.00/mo) không còn đủ chỗ cho một chuỗi unpruned năm 2026, nên đừng mua nó cho việc này. Fenrir (16 vCPU / 64 GB / 800 GB NVMe, $99.00/mo) thì đủ, với dư địa tính bằng vài năm chứ không phải mãi mãi.

Vị trí đặt máy chủ không quan trọng với một node, vốn không có yêu cầu về độ trễ, nên hãy chọn theo giá hoặc theo pháp lý: Amsterdam, Paris, Bucharest và Sofia có giá cơ bản, trong khi Stockholm, Kuala Lumpur, Reykjavik và Zurich có hệ số nhân thêm. Thanh toán theo năm chỉ tính mười tháng thay vì mười hai.

IBD không phải là vấn đề tải xuống. Vài trăm GB đến qua cổng 1 Gbps chỉ trong vài giờ; những ngày dài đến từ những gì diễn ra sau đó — xác minh mọi chữ ký kể từ năm 2009 và duy trì một tập UTXO liên tục bị đọc lại một cách ngẫu nhiên. Khối lượng công việc đó bị giới hạn trước tiên bởi độ trễ lưu trữ, rồi mới đến CPU.

Tác động thực tế chênh nhau cả một bậc độ lớn. Trên NVMe RAID10 với vài GB dbcache, một IBD pruned thường hoàn tất trong khoảng một ngày. Cùng công việc đó trên ổ SATA SSD dùng chung của một host giá rẻ thường xuyên mất cả tuần và đôi khi không bao giờ xong, vì người vận hành bỏ cuộc trước. Đây chính là lúc NVMe so với SSD không còn chỉ là một dòng trên bảng thông số kỹ thuật nữa. Mọi gói ở đây đều toàn NVMe, đó là lý do vì sao gói rẻ nhất vẫn là nơi thực tế để chạy một node, chứ không chỉ là lý thuyết.

Một mẹo nếu bạn nóng lòng: tăng dbcache lên cao nhất mức RAM cho phép trong suốt thời gian đồng bộ, rồi hạ nó xuống lại sau đó.

Core hỗ trợ Tor ở mức hạng nhất, và với một node cá nhân, chế độ chỉ dùng Tor là lựa chọn mặc định đáng cân nhắc. Nó che giấu node nào là nguồn gốc của một giao dịch, giữ địa chỉ VPS của bạn không xuất hiện trong danh sách peer được gossip vĩnh viễn của Bitcoin, và cho phép các ví của bạn tiếp cận node từ bất cứ đâu mà không cần mở cổng inbound.

Cài đặt tor, thêm user của daemon vào nhóm debian-tor để Core có thể truy cập cổng điều khiển (control port), và thêm vào bitcoin.conf:

proxy=127.0.0.1:9050
onlynet=onion
listenonion=1
discover=0
dnsseed=0

Core tự động tạo và quảng bá dịch vụ onion v3 của riêng nó; hãy xác nhận bằng bitcoin-cli getnetworkinfo rằng địa chỉ onion đã được liệt kê và mạng onion hiển thị là có thể truy cập được.

Sự đánh đổi trung thực ở đây: các peer qua onion ít hơn và chậm hơn, nên việc đồng bộ qua Tor sẽ mất nhiều thời gian hơn rõ rệt. Nếu Tor đã chạy sẵn trên máy chủ này rồi, hướng dẫn Tor relay của chúng tôi và ghi chú về VPS thân thiện với Tor sẽ nói rõ khía cạnh chính sách — relay và dịch vụ onion được chào đón ở đây, không chỉ đơn thuần là được dung thứ.

Một Electrum server nằm giữa node của bạn và các ví theo giao thức Electrum, duy trì một khung nhìn chuỗi được lập chỉ mục theo địa chỉ để một ví có thể hỏi “scripthash này có gì?” và nhận được câu trả lời tức thì. Tự chạy server của riêng bạn nghĩa là Electrum, Sparrow và BlueWallet sẽ kết nối tới bạn thay vì tới một máy chủ công khai vốn nhìn thấy mọi địa chỉ bạn sở hữu.

Cái bẫy mà các hướng dẫn ngắn gọn hay bỏ qua: cả electrs lẫn Fulcrum đều yêu cầu một node unpruned. Chúng xây dựng chỉ mục bằng cách đọc trực tiếp các tệp block, nên lịch sử vẫn phải nằm trên đĩa. Vì vậy, thêm một Electrum server sẽ kéo bạn từ một máy $5 chạy pruned lên thành một node archive đầy đủ cộng thêm 50–100 GB nữa cho chỉ mục — đó là địa hạt của Fenrir, không phải Cub.

Giữa hai lựa chọn, electrs nhẹ hơn về bộ nhớ nhưng xây chỉ mục chậm hơn; Fulcrum lập chỉ mục và trả lời nhanh hơn nhưng cần nhiều RAM hơn. Cả hai đều lắng nghe ở cổng 50001 (plaintext) và 50002 (TLS). Hãy giữ chúng chỉ bind vào localhost và truy cập qua một đường hầm WireGuard hoặc một dịch vụ onion, thay vì phơi bày chúng ra ngoài.

Một node Lightning cần một backend Bitcoin đáng tin cậy, và node của bạn chính là ứng viên hiển nhiên. Cả hai triển khai lớn đều chạy song song với Core trên cùng một VPS:

• LND nói chuyện với bitcoind qua RPC và ZMQ. Hãy thêm các endpoint zmqpubrawblock và zmqpubrawtx vào bitcoin.conf, chỉ bind vào localhost.
• Core Lightning mặc định gọi ra bitcoin-cli, dễ hình dung hơn và không mở thêm cổng nào.

Pruning cũng làm phức tạp thêm chuyện này. LND có thể hoạt động với một bitcoind pruned nhưng phải lấy các block lịch sử còn thiếu từ các peer, chậm hơn và đôi khi kém ổn định; Core Lightning thoải mái hơn khi lịch sử vẫn còn đó. Nếu Lightning là mục tiêu ngay từ đầu, hoặc chấp nhận chạy một node unpruned, hoặc chủ động chấp nhận sự bất tiện đó.

Bản thân Lightning khá nhẹ — cơ sở dữ liệu kênh (channel) chỉ vài trăm MB — nhưng nó phải luôn trực tuyến để theo dõi các vi phạm kênh (channel breach), đó là lý do nên dùng VPS thay vì một laptop hay ngủ. Cổng 9735 là cổng P2P của Lightning, và một node Lightning chỉ chạy qua Tor là hoàn toàn bình thường.

Một node không phải là bí mật, nhưng nó là một cỗ máy chạy liên tục, quảng bá một địa chỉ ra mạng lưới gossip toàn cầu, và — nếu bạn bất cẩn — được thuê dưới tên bạn bằng thẻ mang tên bạn.

• Đăng ký mà không cần danh tính. Ở đây vốn được thiết kế không cần KYC: không cần giấy tờ tùy thân, không tải lên tài liệu, không có bước xác minh nào để có thể trượt.
• Thanh toán on-chain. Nạp tiền bằng BTC rồi triển khai từ số dư đó, hoặc bằng Monero nếu bạn muốn khoản thanh toán không trở thành một bản ghi công khai vĩnh viễn — điều đáng suy ngẫm khi thứ bạn đang tài trợ chính là một node Bitcoin. Dù chọn cách nào cũng không có thẻ và không có bên xử lý thanh toán thứ ba nào; cơ chế cụ thể nằm trong bài mua VPS không cần thẻ tín dụng.
• Không đặt bất kỳ danh tính nào lên máy chủ. Đừng đặt tên hostname theo tên bạn, đừng dùng lại một SSH key từng xuất hiện trên một hồ sơ lưu trữ mã nguồn công khai, và nhớ rằng địa chỉ của một node đang lắng nghe vốn được công bố theo thiết kế — đây chính là lý lẽ thực tế mạnh nhất cho chế độ chỉ dùng Tor ở trên.

Điều mà nhà cung cấp máy chủ có thể thấy chỉ là một cỗ máy di chuyển lưu lượng peer-to-peer đều đặn trên một cổng đã biết rõ. Không có gì về ví, địa chỉ hay số dư của bạn cả — những thứ đó không bao giờ rời khỏi máy chủ, và đó chính là toàn bộ ý nghĩa của việc này. Một node xác thực là hạ tầng bình thường và hoàn toàn được chào đón; điều khoản liền kề duy nhất trong chính sách sử dụng chấp nhận được là việc đào tiền mã hóa không được phép trên các gói dùng chung, vì nó chiếm dụng độc quyền các nhân CPU dùng chung. Một node không phải máy đào: sau IBD nó gần như ở trạng thái nhàn rỗi.

Giai đoạn vận hành sau đó không có gì kịch tính. Core phát hành một bản lớn khoảng sáu tháng một lần, và nâng cấp chỉ đơn giản là dừng dịch vụ, thay thế các file binary, khởi động lại — datadir tương thích ngược nên không cần đồng bộ lại. Hãy sao lưu descriptor của bạn nếu node có giữ một ví; ngoài ra không gì khác quan trọng, vì bản thân chuỗi sẽ tự tải lại theo định nghĩa. Nếu bạn dùng hết ổ đĩa — và một node archive chắc chắn sẽ — việc nâng cấp lên gói cao hơn sẽ mở rộng ổ đĩa ngay khi đang chạy, không cần cài lại, tính phí theo tỷ lệ thời gian từ số dư của bạn.