ฉันรัน Bitcoin node บน VPS เล็กได้ไหม?

ได้ — แบบ pruned มันตรวจสอบทั้งเชนระหว่างการซิงก์ จากนั้นเก็บเฉพาะบล็อกล่าสุด (~10–15 GB) ซึ่งพอดีเครื่องเล็ก full archival node ต้องการ 600 GB+ และโตต่อไป

ทำไมฉันต้องการ dedicated IP สำหรับ node?

เพื่อรับการเชื่อมต่อ peer ขาเข้าบนพอร์ต 8333 และมีส่วนร่วมกับเครือข่ายจริง บนแพ็กเกจ NAT คุณได้พอร์ต SSH ที่ forward หนึ่งตัวและเปิด 8333 ไม่ได้ dedicated IP ทำให้ node ของคุณเข้าถึงได้

การซิงก์ครั้งแรกใช้เวลานานแค่ไหน?

หลายชั่วโมงถึงหนึ่งถึงสองวัน node ของคุณดาวน์โหลดและตรวจสอบทั้งเชนหนึ่งครั้ง (~600 GB ของแบนด์วิดท์) แม้ pruned node จะไม่เก็บทั้งหมด รอบแรกนั้นเป็นธรรมชาติ — คุณข้ามไม่ได้

pruned node ทำอะไรไม่ได้?

ให้บริการบล็อกประวัติศาสตร์แก่ peer อื่น หรือ rescan ประวัติกระเป๋าเก่าตามใจ หากคุณวางแผน import กระเป๋าที่มีธุรกรรมยุคแรก ใช้ full node ที่มีประวัติเต็มแทน

รัน Bitcoin node ของคุณเองบน VPS

การรัน node ของคุณเองคือเส้นระหว่างการรับคำของใครเรื่องเชนกับการตรวจสอบมันเอง node ของคุณบังคับใช้ทุกกฎ consensus อย่างอิสระ และกระเป๋าของคุณ query node ของคุณ แทนเซิร์ฟเวอร์สาธารณะที่ log ที่อยู่ทั้งหมดของคุณเงียบ ๆ กำแพงที่คนชน: full archival node ต้องการดิสก์ 600 GB+ และโตต่อไป pruned node เดินอ้อมนั่น — มันยังตรวจสอบทั้งเชน จากนั้นทิ้งบล็อกเก่าที่ไม่ต้องการอีก ลงที่ราว 10–15 GB นั่นพอดี VPS เล็ก นี่คือวิธีที่ตรงไปตรงมา และการ prune คุณอะไร

node ให้อะไรกับคุณจริง ๆ

การตรวจสอบอิสระ คุณบังคับใช้กฎเอง ไม่มีอะไรไม่ถูกต้องผ่าน node ของคุณเพราะมันเชื่อคนแปลกหน้า
ความเป็นส่วนตัวสำหรับ query ของคุณเอง กระเป๋าของคุณถาม node ของคุณ ไม่ใช่ explorer สาธารณะที่เห็นทุกที่อยู่ที่คุณดู
ฐานสำหรับส่วนที่เหลือ node คือรากฐานที่สิ่งอื่นนั่งอยู่ภายหลัง — Lightning, explorer, แอปของคุณเอง

pruned กับ full — แก่นที่ตรงไปตรงมา

ระหว่างการซิงก์เริ่มต้น node ของคุณดาวน์โหลดและตรวจสอบทั้งเชน นั่นคือราว 600 GB ของแบนด์วิดท์ หนึ่งครั้ง การ prune เปลี่ยนเฉพาะสิ่งที่เกิดหลัง: มันเก็บบล็อกล่าสุดและทิ้งบล็อกเก่า ดังนั้นดิสก์สุดท้ายยังเล็ก

สิ่งที่คุณสละเป็นเรื่องจริง: pruned node ให้บริการบล็อกประวัติศาสตร์ไม่ได้แก่ peer อื่น และrescan ประวัติกระเป๋าเก่าตามใจไม่ได้ ดังนั้นหากคุณจะ import กระเป๋าเก่าที่มีธุรกรรมยุคแรก คุณต้องการประวัติเต็ม — full node บนดิสก์ใหญ่ ไม่ใช่ pruned สำหรับการตรวจสอบและรันกระเป๋าปัจจุบันง่าย ๆ pruned ถูกต้องพอดี

สิ่งที่คุณต้องการ

ดิสก์: ~15–20 GB สำหรับ pruned node — เครื่องเล็กโอเค
RAM: 2–4 GB dbcache มากขึ้นเร่งการซิงก์เริ่มต้น คุณลดมันภายหลังได้
แบนด์วิดท์: throughput จริงสำหรับการดาวน์โหลดเต็มครั้งเดียว
IP ที่เข้าถึงได้: เพื่อรับ peer ขาเข้าบนพอร์ต 8333 และช่วยเครือข่ายจริง คุณต้องการ IP สาธารณะที่เปิด 8333 — แพ็กเกจ dedicated-IP บน NAT คุณได้พอร์ต SSH หนึ่งตัวและเปิด 8333 ไม่ได้

การตั้งค่า

ติดตั้ง bitcoind จากนั้น bitcoin.conf ขั้นต่ำ:

prune=10000        # เก็บบล็อกล่าสุด ~10 GB
dbcache=2048       # การซิงก์เริ่มต้นเร็วขึ้น ลดมันภายหลัง
listen=1           # รับ peer ขาเข้า

รันมันใต้ systemd เพื่อให้รีสตาร์ทเมื่อแครชและกลับมาหลังรีบูต และเปิดพอร์ต 8333 เพื่อให้ peer เข้าถึงคุณ จากนั้นให้มันซิงก์ — นี่คือส่วนยาว หลายชั่วโมงถึงหนึ่งถึงสองวัน เพราะมันตรวจสอบทั้งเชนจาก genesis

ล็อกมัน

SSH คีย์เท่านั้น firewall ถึง 8333 และพอร์ต SSH ของคุณ (เช็กลิสต์สิบนาที)
อย่าเปิดพอร์ต RPC ต่ออินเทอร์เน็ต ผูกมันกับ localhost และเข้าถึงผ่าน SSH tunnel หรือเฉพาะจากแอปบนเครื่องเดียวกัน RPC ที่เปิดคือประตูเปิด

ขีดจำกัดที่ตรงไปตรงมา

การซิงก์ครั้งแรกยาวและใช้แบนด์วิดท์หนัก นั่นเป็นธรรมชาติ — การตรวจสอบเชนจากศูนย์ไม่ใช่ขั้นที่คุณกำหนดค่าให้หายไป
pruned node ให้บริการบล็อกเก่าหรือ rescan ประวัติเก่าไม่ได้ ต้องการเหล่านั้น? นั่นคือ full node และดิสก์ใหญ่
Monero เป็นคำถามที่ยุติธรรม และคำตอบตรงไปตรงมาคือขอบเขต เชนของมันใหญ่กว่า — สองสามร้อย GB และแม้ pruned ราว 90 GB — ดังนั้นมันต้องการดิสก์ใหญ่กว่าที่แพ็กเกจเล็กของเราแบก นั่นคือเรื่อง full-node สำหรับเครื่องชนิดต่าง และเราขอบอกอย่างนั้นดีกว่าแสร้งว่ามันพอดี
คุณดูแลมัน: อัปเดต ดิสก์ ปัญหา peer เป็นครั้งคราว node คือความมุ่งมั่นเล็ก ไม่ใช่ fire-and-forget

จ่ายค่ามัน

สมัครด้วยอีเมลและจ่ายด้วย USDC หรือ USDT — ไม่มีบัตร ไม่มี ID วิธีที่เหมาะสมในการจ่ายค่าการรันมุมของ Bitcoin ของคุณเอง