ข้ามไปยังเนื้อหา
Financial Context Wiki

โหนดแบบเต็ม

คู่มือที่เน้นการตรวจสอบสำหรับโหนดแบบเต็ม execution client และ consensus client ของ Ethereum, sync checkpoint, state ปัจจุบันและย้อนหลัง, pruning, ความเป็นส่วนตัวของ RPC, finality และการวางแผนทรัพยากรปฏิบัติการ

อัปเดต

จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

คำตอบโดยตรง

โหนดแบบเต็มดาวน์โหลดข้อมูลที่โปรโตคอลต้องใช้ ตรวจสอบบล็อกและ state transition ตามกฎ consensus และ execution ในเครื่อง ติดตาม chain ที่กฎเหล่านั้นเลือก และปฏิเสธข้อมูล peer ที่ไม่ถูกต้องได้โดยไม่ส่งต่อการตัดสินใจนั้นให้ผู้ให้บริการ RPC คำว่า “แบบเต็ม” หมายถึงความรับผิดชอบในการตรวจสอบ ไม่ใช่การเก็บ state ย้อนหลังทุกช่วงไว้อย่างถาวร การผลิตบล็อก การ staking การให้บริการ API สาธารณะ หรือการปลอดจากข้อผิดพลาดของซอฟต์แวร์และการกำหนดค่า

บน Ethereum แบบ proof-of-stake โหนดแบบเต็มที่ใช้งานได้ต้องจับคู่ execution client กับ consensus client โดย execution client ตรวจสอบธุรกรรมและ execution payload, รักษา state การดำเนินการปัจจุบัน และให้บริการ JSON-RPC ส่วน consensus client ตรวจสอบวัตถุ consensus, ใช้กฎ fork choice และติดตาม justification กับ finalization สำหรับ validator client เป็นส่วนเสริมที่ไม่จำเป็น เว้นแต่ต้องเสนอและ attest บล็อกด้วย validator ที่ stake อยู่

กลไกการทำงาน

  1. กำหนดเป้าหมายการตรวจสอบและ snapshot ของเครือข่าย ได้แก่ โปรโตคอล อัตลักษณ์ของ chain และ genesis, กำหนดการ fork, chainId ที่คาดไว้, hash ของบล็อกปัจจุบันและ finalized, เวอร์ชัน client, โหมด sync, แหล่ง checkpoint, โหมด pruning, วิธี RPC, ขอบเขต state ย้อนหลัง และ uptime ที่ต้องการ คำว่าโหนดแบบเต็มมีข้อกำหนดเฉพาะแต่ละ chain
  2. ติดตั้ง client release ที่ได้มาและตรวจสอบอย่างเป็นอิสระ แล้วจับคู่ส่วนประกอบที่จำเป็น บน Ethereum ปัจจุบัน ให้เชื่อม execution client หนึ่งตัวกับ consensus client หนึ่งตัวผ่าน Engine API ในเครื่องที่มีการยืนยันตัวตน และเพิ่ม validator เฉพาะเมื่อต้อง staking แยก data directory, พอร์ต P2P, การเปิด RPC และกุญแจ signer หรือ validator ออกจากกัน
  3. เริ่ม bootstrap จาก trust anchor ที่ตั้งใจใช้ full sync จาก genesis จะตรวจสอบไปข้างหน้าตั้งแต่ genesis ส่วนกลยุทธ์ snap หรือ checkpoint เริ่มจาก state ที่ใหม่กว่าและยืนยันแล้ว หรือ weak-subjectivity checkpoint จากนั้นจึงตรวจสอบบล็อกถัดไป ตรวจเทียบ genesis, checkpoint root, chain ID, fork digest และ finalized head ผ่านช่องทางอิสระก่อนเชื่อถือฐานข้อมูล
  4. เฝ้าติดตามทั้งสอง pipeline ยืนยัน peer ฝั่ง execution และ consensus, ระยะล้าของ head และ finalized block, สถานะ Engine API, ความตรงกันของ state root, การซิงก์ clock, การเติบโตของ disk, input/output, memory, CPU, ข้อผิดพลาดฐานข้อมูล และความพร้อมสำหรับ fork คำว่า “ซิงก์แล้ว” ต้องหมายถึง client ที่จำเป็นเห็นตรงกันใน chain เป้าหมายและยังคงนำเข้าข้อมูลที่ถูกต้อง
  5. จับคู่การเก็บข้อมูลกับ query โหนดแบบเต็มที่ prune แล้วจะเก็บ state ปัจจุบันและข้อมูลบล็อก receipt และ snapshot เพียงพอสำหรับการตรวจสอบ แต่อาจต้องสร้าง state เก่าขึ้นใหม่หรือปฏิเสธ query นั้น การกำหนดค่า archive จะ materialize state ย้อนหลังเพื่อ query ตามช่วงเวลาได้รวดเร็ว ส่วน light client ตรวจสอบเส้นทาง commitment ที่แคบกว่าและขอข้อมูลเพิ่มเติม จึงไม่ใช่เพียงโหนดแบบเต็มขนาดเล็ก
  6. เปิดพื้นผิว RPC เท่าที่จำเป็น ผูก administrative API และ Engine API ไว้ในเครื่อง ยืนยันตัวตน client ใช้ firewall กับโฮสต์ จำกัดอัตรา RPC ของแอป และอย่าเผยแพร่วิธี debug, trace, account หรือ transaction pool โดยไม่มีการควบคุม ทดสอบ tag latest, safe และ finalized, historical call, log และการส่งธุรกรรมกับโหนดเป้าหมาย และ failover ไปยัง endpoint ที่ตรวจสอบแยกต่างหากแล้วเท่านั้น
  7. กระทบยอดและกู้คืน เปรียบเทียบ block hash, state root และ finalized checkpoint กับ client ที่สองหรือโหนดอิสระ ซ้อม clean shutdown, snapshot และ restore, การสร้างฐานข้อมูลใหม่, การ upgrade client, การเปิดใช้ fork, การเปลี่ยน disk, การสูญเสีย peer และ RPC failover เก็บ log และการกำหนดค่า พร้อมแยกผลลัพธ์ที่โหนดตรวจสอบแล้วออกจาก claim ของ frontend, oracle, bridge และแอป

ตัวอย่างคำนวณ

  • แบบจำลอง bandwidth สมมติว่า chain สร้างหนึ่งบล็อกทุก 12 seconds และ block body ที่ดาวน์โหลดพร้อม side data ที่ต้องใช้มีค่าเฉลี่ย 150 kB โหนดประมวลผล 86,400 / 12 = 7,200 blocks/day และดาวน์โหลด 7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day ในหน่วยฐานสิบ ก่อนนับ overhead ของ P2P, การลองใหม่, traffic ของ consensus, snapshot หรือ upload ตัวเลขเหล่านี้เป็นสมมติฐานเพื่อวางแผน ไม่ใช่ค่าคงที่จริงของ Ethereum
  • พื้นที่สำรองบน disk โหนดที่ prune แล้วเริ่มต้นที่ 1.20 TB และฐานข้อมูลที่วัดได้เติบโต 18 GB/month ตลอด 30 months การใช้งานตามแบบจำลองคือ 1,200 + 18 * 30 = 1,740 GB การสำรอง 25% เหนือประมาณการต้องใช้ 1,740 * 1.25 = 2,175 GB หรือ 2.175 TB ในหน่วยฐานสิบ การเปลี่ยน client, pruning และ fork อาจทำให้แบบจำลองเชิงเส้นนี้ใช้ไม่ได้
  • ความพร้อมใช้งานเชิงปฏิบัติการ ตลอด 30 days = 720 hours การบำรุงรักษา execution client ใช้ 2 hours ความล้มเหลวของ consensus client ใช้ 3 hours และไฟดับร่วมกันใช้ 1 hour โดยไม่ทับซ้อนกัน downtime เท่ากับ 6 hours ความพร้อมใช้งานที่สังเกตได้คือ (720 - 6) / 720 = 99.1666666667% โหนดอาจมีกระบวนการทำงานอยู่แต่ล้าหลัง ถูกแบ่งเครือข่าย หรืออยู่บน chain ผิด ดังนั้น uptime ของกระบวนการเพียงอย่างเดียวไม่พอ
  • การสร้าง state ย้อนหลังใหม่ client ที่ prune แล้วมี snapshot ที่ใช้ได้ ณ บล็อก 18,000,000 และต้องการ state ณ บล็อก 18,250,000 จึงต้อง replay 250,000 blocks ที่อัตราวัดได้ 500 blocks/second เวลาคำนวณในอุดมคติคือ 250,000 / 500 = 500 seconds = 8.3333333333 minutes โดยยังไม่รวมการอ่าน state, receipt, การจัดการ reorg และ cache miss ส่วน archive node แลกพื้นที่เก็บเพิ่มกับการเข้าถึง state ย้อนหลังโดยตรงที่เร็วกว่า

ความเสี่ยง

  • เชื่อมต่อ chain, genesis, กำหนดการ fork หรือ chainId ผิดรายการ
  • เชื่อถือ sync checkpoint ที่เป็นอันตราย ล้าสมัย หรือตรวจเทียบไม่เพียงพอ
  • ใช้ client ล้าสมัยขณะมีการ upgrade เครือข่าย
  • Consensus client และ execution client ไม่เห็นตรงกันหรือขาดการเชื่อมต่อ Engine API
  • ข้อบกพร่องของ client implementation ทำให้ยอมรับ ปฏิเสธ หรือให้บริการข้อมูลผิด
  • การใช้ client แบบกระจุกตัวทำให้โหนดและเครือข่ายเสี่ยงต่อความล้มเหลวที่สัมพันธ์กัน
  • มี peer น้อยเกินไป ถูก eclipse เป็นอันตราย หรือขาดความหลากหลาย
  • Clock drift ทำให้หน้าที่ consensus, timestamp หรือพฤติกรรม peer ผิดพลาด
  • Disk เต็ม storage ช้า filesystem ล้มเหลว หรือฐานข้อมูลเสียหาย
  • เข้าใจผิดว่า uptime ของกระบวนการคือการทำงานที่ซิงก์ เป็น canonical และ finalized
  • สับสนระหว่าง state แบบ head, safe และ finalized ระหว่าง reorganization
  • สมมติว่าโหนดแบบเต็มที่ prune แล้วตอบทุก query ของ state ย้อนหลังได้ทันที
  • สมมติว่า archive node เก็บดัชนี off-chain, trace หรือป้ายกำกับแอปทุกชนิด
  • เปิด API ของ Engine, admin, debug, trace หรือ transaction pool โดยไม่ยืนยันตัวตน
  • ทำที่อยู่ wallet, query, metadata หรือเจตนาส่งธุรกรรมรั่วผ่าน RPC log
  • RPC overload, query ที่ไม่จำกัด หรือ denial of service แย่งทรัพยากรจากการตรวจสอบบล็อก
  • การ restore backup หรือ snapshot ทำให้ได้ข้อมูลล้าสมัยหรือไม่สอดคล้องภายใน
  • ทำกุญแจ validator หรือ signer สูญหายเพราะวางร่วมกับบริการโหนดอย่างไม่รอบคอบ
  • ถือว่าข้อมูล chain ที่ตรวจสอบในเครื่องพิสูจน์ว่า frontend, oracle หรือ bridge ซื่อสัตย์
  • นำแบบจำลองสอง client, pruning หรือ weak subjectivity ของ Ethereum ไปใช้กับ chain อื่น

ความเข้าใจผิดที่พบบ่อย

  • โหนดแบบเต็มทุกโหนดเป็น archive node ที่เก็บ state ย้อนหลังทุกช่วงตลอดไป
  • การรันโหนดแบบเต็มทำให้ผู้ดำเนินการเป็น validator หรือผู้ผลิตบล็อกโดยอัตโนมัติ
  • โหนดที่รายงานว่า “ซิงก์แล้ว” ต้องอยู่บน chain เป้าหมายที่เป็น canonical และ finalized
  • การโฮสต์ RPC เองขจัดความเสี่ยงด้าน trust, privacy, software และ operation ทั้งหมด
  • Disk, peer หรือ uptime ที่มากขึ้นเพียงอย่างเดียวพิสูจน์ความถูกต้องของการตรวจสอบและความปลอดภัยของเครือข่าย

หัวข้อที่เกี่ยวข้อง

แหล่งข้อมูล

การนำทาง

ค้นหาในวิกิ...