เรียกใช้งานโหนด Geth: Go-Ethereum บนเครือข่าย Ethereum
คุณตัดสินใจที่จะไม่ไว้วางใจ Infura endpoint สำหรับการรับส่งข้อมูลกระเป๋าเงินของคุณอีกต่อไป อาจเป็นเพราะเพื่อนเสนอที่จะช่วยคุณวางเดิมพัน 32 ETH หรืออาจเป็นเพราะ dApp ของคุณใกล้จะล่มในวันเปิดตัวเนื่องจากเกินขีดจำกัดอัตราการใช้งาน ไม่ว่าด้วยเหตุผลใดก็ตาม ประโยคถัดไปจะเหมือนกันเสมอ: คุณจำเป็นต้องใช้งานโหนด Geth
ประโยคนั้นฟังดูซับซ้อนกว่าที่เป็นจริง Geth ซึ่งย่อมาจาก go-ethereum คือโปรแกรมไคลเอ็นต์สำหรับการประมวลผลข้อมูลบน Ethereum รุ่นแรก เขียนด้วยภาษา Go โดย Jeffrey Wilcke และทีมโอเพนซอร์สทั่วโลกในปี 2014 แล็ปท็อปสมัยใหม่ที่มี SSD ขนาดใหญ่สามารถใช้งานได้ หรือแม้แต่เซิร์ฟเวอร์ Hetzner ราคา 30 ดอลลาร์ต่อเดือนก็เช่นกัน ส่วนที่ทำให้คนสับสนไม่ใช่คำสั่งติดตั้ง แต่เป็นตัวเลือกต่างๆ ที่เกี่ยวข้อง เช่น โหมดการซิงค์ที่จะเลือก ไคลเอ็นต์ฉันทามติที่จะใช้ร่วมกับ Geth จะเกิดอะไรขึ้นหลังจาก Merge และวิธีการรักษาโหนดให้ทำงานต่อไปเมื่อดิสก์เต็มในเวลาตี 2
คู่มือนี้จะพาคุณไปทุกขั้นตอน ตั้งแต่การเลือกซื้อฮาร์ดแวร์ การติดตั้ง การซิงค์ Snap การจับคู่หลังการรวมข้อมูลกับไคลเอ็นต์ Consensus คอนโซล JavaScript บัญชีและ Clef การตั้งค่าตัวตรวจสอบความถูกต้อง และปัญหาที่พบบ่อย เมื่ออ่านจบแล้ว คุณจะเข้าใจอย่างถ่องแท้ว่าเครื่องของคุณกำลังทำอะไรอยู่เมื่อมีข้อความสีขาวปรากฏขึ้น และควรทำอย่างไรเมื่อข้อความเหล่านั้นหยุดปรากฏ
โหนดเกธคืออะไร และทำไมจึงมีความสำคัญในปัจจุบัน
โหนด Geth คือคอมพิวเตอร์ที่ใช้งานไคลเอ็นต์ go-ethereum และเชื่อมต่อเข้ากับเครือข่ายแบบ peer-to-peer ของ Ethereum เครื่องนี้จะดาวน์โหลดบล็อก ตรวจสอบทุกธุรกรรม รันสัญญาอัจฉริยะบนเครื่องเสมือน Ethereum และเก็บสำเนาสถานะของโลกที่ซิงโครไนซ์ไว้ จากภายนอก มันดูเหมือนกระบวนการเงียบๆ ที่คอยฟังอยู่บนพอร์ตไม่กี่พอร์ต แต่ภายในแล้ว มันคือผู้ดูแลบัญชีที่ดื้อรั้นซึ่งปฏิเสธที่จะเชื่อคำพูดของคนอื่นเกี่ยวกับบัญชีแยกประเภท มันเก็บสำเนาข้อมูลบล็อกเชนของตัวเอง อนุญาตให้กระเป๋าเงินของคุณตรวจสอบยอดคงเหลือในบัญชีหรือส่งธุรกรรมไปยังบล็อกเชน และอนุญาตให้ dApp ของคุณโต้ตอบกับบล็อกเชนโดยตรงแทนที่จะผ่าน API ของคนอื่น
ทำไมเรื่องทั้งหมดนี้ถึงสำคัญในปี 2026? เพราะความเข้มข้นของการให้บริการ ปริมาณการใช้งาน dApp สาธารณะส่วนใหญ่บน Ethereum ไหลผ่านผู้ให้บริการ RPC เพียงไม่กี่ราย ได้แก่ Infura, Alchemy, QuickNode และผู้ให้บริการรายเล็กๆ อีกไม่กี่ราย เฉพาะ Infura เพียงรายเดียวก็ให้บริการคำขอบล็อกเชนมากกว่า 600 พันล้านรายการเมื่อปีที่แล้ว พวกเขามีความน่าเชื่อถือในระดับหนึ่ง แต่พวกเขาก็เป็นจุดอ่อนสำคัญเช่นกัน: เมื่อผู้ให้บริการรายใดรายหนึ่งล่มในภูมิภาคใดภูมิภาคหนึ่ง กระเป๋าเงินครึ่งหนึ่งที่เชื่อมต่อกับปลายทางนั้นจะแสดงยอดคงเหลือที่ล้าสมัยและธุรกรรมที่ค้างอยู่จนกว่าจะมีคนมาแก้ไข หากคุณใช้งานโหนด Geth ของคุณเอง ปัญหาความล้มเหลวประเภทนี้ก็จะหมดไป
นี่เป็นเรื่องของตัวเลขเช่นกัน ตัวติดตามโหนดของ Etherscan นับจำนวนโหนด Ethereum ที่ใช้งานอยู่ทั่วโลกได้ประมาณ 13,678 โหนด ณ เดือนเมษายน 2026 สหรัฐอเมริกาครองส่วนแบ่ง 37.55% หรือประมาณ 5,171 โหนด เยอรมนีมี 16.05% และจีนมี 12.06% การสร้างโหนดเพิ่มอีกหนึ่งโหนดไม่ใช่เรื่องที่ยิ่งใหญ่ มันเป็นเพียงสิ่งที่มีประโยชน์ และเครือข่ายก็ยังคงคาดหวังว่าจะมีคนทำเช่นนั้นต่อไปอย่างเงียบๆ
นอกจากนั้นยังมีเหตุผลที่ลึกซึ้งกว่านั้นอีกด้วย Ethereum ยังคงเป็น Ethereum เพราะทุกคนสามารถตรวจสอบความถูกต้องได้โดยไม่ต้องขออนุญาต Geth เป็นไคลเอนต์ที่ได้รับความนิยมมากที่สุดสำหรับการตรวจสอบความถูกต้องนั้น ทุกครั้งที่ผู้ดำเนินการอิสระรายอื่นนำโหนด Geth ใหม่เข้ามาใช้งาน การควบคุมเครือข่ายก็จะยากขึ้นอีกระดับ ตรรกะนี้มีมาก่อนการรวมเครือข่ายและยังคงไม่เปลี่ยนแปลงนับตั้งแต่นั้นมา
Geth, Go Ethereum และ Ethereum Protocol
สามชื่อ หนึ่งโปรเจกต์ คนส่วนใหญ่มักนำมาผสมกันในบทสนทนาแล้วก็ไม่มีอะไรผิดพลาด แต่ต่อไปนี้คือรายละเอียดที่แท้จริง
โปรโตคอล Ethereum ไม่ใช่โค้ด มันเป็นข้อกำหนดที่เขียนไว้บนกระดาษสีเหลืองและกองเอกสาร EIP จำนวนมาก และใครๆ ก็สามารถเขียนไคลเอ็นต์สำหรับมันได้ Go Ethereum บางครั้งเขียนว่า go-ethereum คือการใช้งานโปรโตคอล Ethereum ด้วยภาษา Go Geth คือโปรแกรมบรรทัดคำสั่งภายใน Go Ethereum ที่คุณเรียกใช้บนบรรทัดคำสั่ง กำหนดค่าด้วยแฟล็ก และใช้เพื่อโต้ตอบกับเครือข่าย Ethereum ทุกอย่างอื่นในที่เก็บข้อมูลคือไลบรารีและตัวช่วยที่ห่อหุ้มอยู่รอบๆ Geth "โหนด Geth" เป็นเพียงเครื่องที่คุณได้เริ่มต้น Geth ชี้ไปยังไดเร็กทอรี `chaindata` และปล่อยให้มันสื่อสารกับเมนเน็ตของ Ethereum
มีไคลเอ็นต์หลายตัวสำหรับโปรโตคอลเดียวกัน เช่น Nethermind ที่เขียนด้วย C#, Besu ที่เขียนด้วย Java, Erigon และ Reth ที่เขียนด้วย Rust รูปแบบการส่งข้อมูลเหมือนกัน แต่โค้ดต่างกัน ประสิทธิภาพต่างกัน และประวัติความเป็นมาก็ต่างกันด้วย
Geth เป็นโปรโตคอลที่เก่าแก่ที่สุด มีผู้ร่วมพัฒนามากกว่า 400 คน และ Péter Szilágyi เป็นหัวหน้าโครงการมานานหลายปี โครงการนี้อยู่ภายใต้การดูแลของ Ethereum Foundation ซอร์สโค้ดอยู่ที่ ethereum/go-ethereum บน GitHub และได้รับใบอนุญาต GNU General Public License, GPL-3.0 สำหรับไบนารี และ LGPL-3.0 สำหรับโค้ดไลบรารี เวอร์ชันเสถียรปัจจุบัน ณ เวลาที่ฉันเขียนบทความนี้คือ v1.17.2 — ชื่อรหัส "EMF Suppressor" — เปิดตัวเมื่อวันที่ 30 มีนาคม 2026 เวอร์ชันนี้แก้ไขช่องโหว่ CVE สามรายการ (CVE-2026-26313, -26314, -26315) และสอนให้ไคลเอนต์ซิงค์กับเชนที่มีประวัติก่อนการประชุม Prague ถูกลบออกไปแล้ว
นอกจาก Geth แล้ว ยังมีเครื่องมืออื่นๆ อีกหลายตัวที่มาพร้อมกัน Clef เป็นเครื่องมือลงนามแยกต่างหากที่ช่วยเก็บคีย์ส่วนตัวของคุณให้ห่างจากโหนด Abigen แปลง Solidity ABI ให้เป็น Go bindings ที่คุณสามารถใช้งานได้จริง และเครื่องมือ `evm` ที่ช่วยให้คุณรัน bytecode ในสภาพแวดล้อมที่แยกต่างหากเมื่อคุณต้องการดีบักบางอย่างโดยเฉพาะ ไม่มีเครื่องมือใดที่จำเป็นต้องใช้ แต่คุณจะต้องใช้อย่างน้อยหนึ่งอย่างภายในหนึ่งสัปดาห์
เหตุผลที่ควรใช้งาน Node: ความเป็นส่วนตัว ความเร็ว และอำนาจอธิปไตย
คนส่วนใหญ่ที่ใช้งานโหนด Geth ด้วยตนเองมักเลือกใช้วิธีใดวิธีหนึ่งในสามเหตุผลนี้ ประการแรกคือเรื่องความเป็นส่วนตัว เมื่อกระเป๋าเงินดิจิทัลสื่อสารกับ RPC ที่ให้บริการโดยผู้ให้บริการนั้น ผู้ให้บริการจะเห็นทุกที่อยู่ ทุกการเรียกใช้สัญญา และทุกคำขอใบเสนอราคา แต่โหนดที่โฮสต์เองจะตัดการเชื่อมต่อดังกล่าว ผู้ให้บริการนั้นไม่มีอยู่จริง กระเป๋าเงินของคุณจะสอบถามเครื่องของคุณ เครื่องของคุณจะสอบถามเครือข่าย และมีเพียงเครื่องของคุณเท่านั้นที่เห็นรูปแบบนั้น
ประสิทธิภาพคือเหตุผลข้อที่สอง RPC ที่โฮสต์อยู่จะถูกจำกัด แพ็กเกจฟรีของ Infura จำกัดไว้ที่ 100,000 คำขอต่อวัน ส่วนแพ็กเกจ Team มีค่าใช้จ่าย 225 ดอลลาร์ต่อเดือน สำหรับ 75 ล้านคำขอต่อวัน โหนดภายในเครื่องจะให้บริการทราฟฟิกของคุณด้วยความเร็วระดับหน่วยความจำโดยไม่มีค่าใช้จ่ายต่อการเรียกใช้ สำหรับ dApp ที่ดึงสถานะทุกครั้งที่โหลดหน้าเว็บ ความแตกต่างของความหน่วงนั้นเห็นได้ชัด สำหรับบอทเก็งกำไรที่สแกน mempool มันคือความแตกต่างระหว่างการทำธุรกรรมสำเร็จกับการปล่อยให้มันผ่านไป เครือข่ายหลักเองประมวลผลธุรกรรมประมาณ 200.4 ล้านรายการในไตรมาสที่ 1 ปี 2026 โดยสูงสุดที่ 2.88 ล้านรายการในวันที่ 16 มกราคม ดังนั้นโหนดที่สามารถรองรับเครือข่ายได้จึงทำงานได้อย่างมีประสิทธิภาพจริง ๆ
อธิปไตยเป็นประการที่สาม หากคุณทำการ Stake บน Ethereum เครือข่ายจะคาดหวังว่า Validator ของคุณจะเผยแพร่บล็อกเมื่อถึงคิวของตน การมอบหมายการเผยแพร่ให้กับ RPC ที่ใช้ร่วมกันนั้น ในทางเทคนิคแล้วอนุญาต แต่ในทางปฏิบัติแล้วมีความเปราะบาง การใช้งาน Client ใน Execution Layer ของคุณเองจะทำให้คุณควบคุม Slot ของคุณได้ เช่นเดียวกับผู้สร้าง dApp ที่จริงจัง นักวิเคราะห์บนบล็อกเชน ผู้ค้นหา MEV และทุกคนที่ธุรกิจขึ้นอยู่กับการใช้งาน Ethereum โดยเฉพาะ
หลังจากการรวมระบบ: Geth และไคลเอ็นต์ Consensus ของคุณ
ก่อนเดือนกันยายน 2022 กระบวนการ Geth เพียงกระบวนการเดียวทำทุกอย่าง มันเชื่อมต่อกับเครือข่าย มันรัน EVM และเลือกผู้ชนะจากบล็อกที่แข่งขันกันผ่านการขุดแบบพิสูจน์การทำงาน (proof-of-work) การรวมเครือข่าย (Merge) แบ่งงานนั้นออกเป็นครึ่ง Geth ยังคงรัน EVM และเก็บสถานะอยู่ โปรแกรมที่สอง — ไคลเอนต์ฉันทามติ — ตอนนี้จัดการการพิสูจน์การถือครอง (proof-of-stake) เช่น การส่งข้อมูลบล็อกระหว่างผู้ตรวจสอบความถูกต้อง การลงคะแนนว่าอะไรนับได้ และบอก Geth ว่าฟอร์กใดเป็นมาตรฐาน
ดังนั้น การตั้งค่า Geth สมัยใหม่ทุกระบบจึงเป็นแบบคู่ ไม่ใช่กระบวนการเดียว เลือกไคลเอ็นต์ฉันทามติที่จะทำงานควบคู่กันไป ตัวเลือกได้แก่ Lighthouse (Rust), Prysm (Go), Teku (Java), Nimbus (Nim) และ Lodestar (TypeScript) กระบวนการทั้งสองจะสื่อสารกันผ่านช่องทางส่วนตัวที่เรียกว่า Engine API ซึ่งถูกควบคุมโดยรหัสลับ JWT ที่คุณสร้างขึ้นเพียงครั้งเดียวและส่งให้ทั้งสองฝ่ายด้วย `--authrpc.jwtsecret`
หากเริ่มต้น Geth เพียงลำพัง โดยไม่มีไคลเอ็นต์สำหรับติดตามฉันทามติ บันทึกจะแสดงข้อความประมาณว่า "เครือข่ายหลังการรวม แต่ไม่พบไคลเอ็นต์บีคอน โปรดเปิดใช้งานไคลเอ็นต์เพื่อติดตามเชน!" โหนดจะอยู่นิ่งๆ อย่างสุภาพแต่ไร้ประโยชน์ Geth เพียงลำพังไม่ใช่โหนด Ethereum ที่สมบูรณ์อีกต่อไปแล้ว การทำงานเป็นคู่จึงเป็นหน่วยที่สมบูรณ์
ความหลากหลายของไคลเอ็นต์มีความสำคัญในที่นี้ ชุมชน Ethereum ขอให้ผู้ดำเนินการกระจายการใช้งานไปยังไคลเอ็นต์ทั้งสองฝั่งของการแบ่งแยก เพราะหากผู้ตรวจสอบความถูกต้องมากกว่าสองในสามใช้ไคลเอ็นต์ที่มีข้อบกพร่องเดียวกัน ผู้ตรวจสอบความถูกต้องเหล่านั้นจะต้องเผชิญกับบทลงโทษการหัก ETH จำนวน 32 ETH เต็มจำนวนเมื่อเกิดปัญหาขึ้น ตัวเลขล่าสุดจาก clientdiversity.org ระบุว่า Geth จะอยู่ที่ประมาณ 41% ของไคลเอ็นต์ที่ใช้ในการประมวลผลในปี 2026 รายงานปี 2026 ของ Stake.fish ระบุว่าใกล้เคียงกับ 50% ไม่ว่าจะอย่างไรก็ตาม ตัวเลขนี้ลดลงจากกว่า 86% ในปี 2023 แต่ยังคงสูงกว่าเกณฑ์ความปลอดภัย 33% ที่ชุมชนพิจารณาว่าเหมาะสม ซึ่งเป็นเหตุผลว่าทำไมผู้ดำเนินการรายใหม่บางรายจึงเลือก Nethermind, Besu หรือ Reth โดยเจตนา แม้ว่า Geth จะเป็นขั้นตอนแรกที่ง่ายกว่าก็ตาม
Pectra ซึ่งเป็นการอัปเกรด Prague + Electra ที่เปิดใช้งานเมื่อวันที่ 7 พฤษภาคม 2025 ได้เปลี่ยนแปลงวิธีการทำงานของผู้ดำเนินการในแต่ละวันไปอย่างสิ้นเชิง EIP-7251 เพิ่มยอดคงเหลือสูงสุดต่อผู้ตรวจสอบความถูกต้องจาก 32 ETH เป็น 2,048 ETH ผู้ดำเนินการ Staking ที่เคยดูแลผู้ตรวจสอบความถูกต้องรายย่อย 1,000 ราย สามารถรวมเข้าเป็นกลุ่มใหญ่ 16 กลุ่มได้แล้ว EIP-6110 ลดระยะเวลารอระหว่างการฝากและการเปิดใช้งานจากประมาณ 12 ชั่วโมงเหลือประมาณ 13 นาที EIP-7002 ทำให้ผู้ตรวจสอบความถูกต้องสามารถถอนเงินได้ด้วยตนเอง แทนที่จะต้องขอให้ผู้ลงนามฝากเงินเดิมดำเนินการให้ การใช้งานระบบตรวจสอบความถูกต้องที่จับคู่ Geth ในปี 2026 นั้นง่ายกว่าในปี 2024 อย่างมาก
ฮาร์ดแวร์: CPU, RAM และ SSD สำหรับ Geth Nodes
มาตรฐานฮาร์ดแวร์ที่แท้จริงในปี 2026 นั้นสูงกว่าที่เอกสารทางการระบุไว้ วางแผนสำหรับสามปีข้างหน้า ไม่ใช่สามปีที่ผ่านมา
| ส่วนประกอบ | เอกสารทางการของ Geth (ปี 2023 ยังคงใช้ได้อยู่) | ความเป็นจริงระดับผู้ปฏิบัติงาน (Cherry Servers, Chainstack, 2026) | โหนดเก็บถาวร (ตามเส้นทาง, เวอร์ชัน 1.16 ขึ้นไป) |
|---|---|---|---|
| ซีพียู | ควอดคอร์ | โปรเซสเซอร์ AMD หรือ Intel รุ่นใหม่ 8 คอร์ / 16 เธรด | ซีพียู 8 คอร์ขึ้นไป ประสิทธิภาพการทำงานแบบ Single-thread สูง |
| แรม | 16 GB | ขั้นต่ำ 32 GB, 64 GB จะใช้งานได้ราบรื่นกว่า | 64 GB ขึ้นไป |
| พื้นที่จัดเก็บ | SSD ขนาด 2 เทราไบต์ | SSD NVMe ขนาด 4 ถึง 8 TB | NVMe ขนาด 4 TB (จัดเก็บตามเส้นทาง ใช้ไปประมาณ 2 TB) |
| เครือข่าย | 25 เมกะบิตต่อวินาที | ความเร็ว 300 ถึง 500 Mbps สำหรับ RPC เต็มรูปแบบ | ความเร็วมากกว่า 300 เมกะบิตต่อวินาที |
| พลัง | UPS แนะนำ | UPS แนะนำเป็นอย่างยิ่ง | UPS ต้องการ |
พื้นที่จัดเก็บข้อมูลเป็นสิ่งที่ทำให้ผู้ใช้งานใหม่ประหลาดใจ โหนดเต็มรูปแบบของ Geth ที่ซิงค์ข้อมูลด้วย Snap และตัดแต่งแล้ว จะมีพื้นที่ประมาณ 650 GB ในปัจจุบัน เอกสารของ Geth เองระบุว่ามันเพิ่มขึ้นประมาณ 14 GB ต่อสัปดาห์ เพิ่มไคลเอนต์ฉันทามติ เพิ่มพื้นที่เผื่อการเติบโตอีกสองสามเดือน เพิ่มปริมาณการรับส่งข้อมูล L2 RPC ที่คุณวางแผนจะให้บริการ คุณจะพบพื้นที่ NVMe ระหว่าง 4 ถึง 8 TB อย่างรวดเร็ว
ขอพูดถึงประเภทของดิสก์สักเล็กน้อย SSD แบบ SATA นั้นใช้งานได้จริง แต่ก็มีปัญหาเรื่องการซิงค์ข้อมูลและการตรวจสอบความถูกต้องที่ผิดพลาดเมื่อมีการใช้งานหนัก NVMe นั้นไม่ใช่ทางเลือกในปี 2026 ดิสก์แบบจานหมุนนั้นไม่สามารถใช้งานได้อย่างมีประสิทธิภาพมาหลายปีแล้ว หากผู้ให้บริการของคุณเสนอเฉพาะ SATA ในแพ็กเกจราคาประหยัด คุณควรจ่ายเงินเพิ่ม เพราะการคำนวณนั้นโหดร้ายมาก: ดิสก์ SATA ที่ค้างจะทำให้คุณพลาดรางวัลจากผู้ตรวจสอบความถูกต้องในแต่ละรอบ
RAM คือกับดักข้อที่สอง หน้าเว็บฮาร์ดแวร์อย่างเป็นทางการของ Geth ซึ่งอัปเดตครั้งล่าสุดในปี 2023 ยังคงระบุว่า 16 GB แต่ในปี 2026 เซิร์ฟเวอร์ Cherry, Chainstack และ bacloud ต่างก็ใช้ RAM 32 GB เป็นขั้นต่ำ และ 64 GB เป็นขนาดที่เหมาะสมที่สุด Geth เก็บข้อมูลสถานะส่วนใหญ่ไว้ในหน่วยความจำ ไคลเอนต์ที่ใช้ในการสร้างฉันทามติก็ต้องการส่วนแบ่งเช่นกัน หากเพิ่ม Prometheus, Grafana และโปรแกรมอื่นๆ ที่คุณใช้งานจริงเข้าไปด้วย 16 GB ก็จะหมดเร็วมาก
CPU เป็นส่วนที่ง่ายที่สุดในสามส่วนนี้ ชิปเดสก์ท็อปสมัยใหม่มีประสิทธิภาพเหลือเฟือมากกว่าที่ Geth จะรับมือได้ ความเร็วสัญญาณนาฬิกาแทบไม่มีความสำคัญ จำนวนคอร์และคำสั่งสมัยใหม่มีความสำคัญมากกว่า AVX2 ช่วยให้การตรวจสอบลายเซ็นรวดเร็ว คอร์แปดตัวช่วยป้องกันไม่ให้กระแสไฟกระชากทำให้เครื่องของคุณค้าง มองไปข้างหน้า ขีดจำกัดก๊าซบล็อกเพิ่มขึ้นจาก 30 ล้านเป็น 45 ล้านเป็น 60 ล้านระหว่างกลางปี 2024 ถึงเดือนพฤศจิกายน 2025 มูลนิธิ Ethereum ได้ส่งสัญญาณว่าจะเพิ่มขึ้นเป็น 100 ล้านขึ้นไปภายในปี 2026 นั่นคือเส้นโค้งที่คุณต้องพิจารณา ไม่ใช่ภาระงานของปีที่แล้ว
โหมดการซิงค์ Geth สำหรับบล็อกเชน Ethereum
โหมดการซิงค์เป็นตัวแปรสำคัญที่สุดที่ผู้เล่นใหม่ในเกม Geth ต้องปรับแต่ง หากเลือกผิด คุณอาจเสียเวลาไปหนึ่งสัปดาห์กับการดาวน์โหลดข้อมูลที่ไม่จำเป็น
| โหมด | สิ่งที่มันจัดเก็บ | ดิสก์ในปี 2026 | เวลาซิงค์ | กรณีศึกษา |
|---|---|---|---|---|
| สแนป (ค่าเริ่มต้น) | สถานะปัจจุบัน + ใบเสร็จรับเงินล่าสุด | ประมาณ 650 GB, เพิ่มขึ้น 14 GB ต่อสัปดาห์ | 1 ถึง 3 วัน (เร็วกว่าบน NVMe) | dApps, กระเป๋าเงินดิจิทัล, ตัวตรวจสอบความถูกต้อง |
| เต็ม | สถานะล่าสุด + ส่วนหัวทั้งหมดตั้งแต่เริ่มต้น | ~1 เทราไบต์ | 3 ถึง 5 วัน | ตรวจสอบทุกบล็อกตั้งแต่เริ่มต้น |
| ไฟล์เก็บถาวร (ตามเส้นทาง, เวอร์ชัน 1.16 ขึ้นไป) | สถานะทางประวัติศาสตร์ผ่านความแตกต่างแบบย้อนกลับ | 1.9 ถึง 2.0 เทราไบต์ | 1 ถึง 2 สัปดาห์ | กรณีการใช้งานคลังข้อมูลส่วนใหญ่ |
| คลังข้อมูล (แบบเดิมใช้แฮช) | ทุกรัฐทางประวัติศาสตร์ ทุกใบเสร็จ ทุกความพยายาม | 12 ถึง 20 TB | 4 ถึง 8 สัปดาห์ | ดัชนี DeFi ที่ต้องการ eth_getProof |
Snap เป็นค่าเริ่มต้น และโดยส่วนใหญ่แล้วก็เป็นตัวเลือกที่ถูกต้อง มันจะดึงภาพรวมสถานะล่าสุดจากโหนดต่างๆ แล้วเติมส่วนหัวและใบเสร็จรับเงินลงไปอย่างเงียบๆ คุณจะได้โหนด Geth ที่ใช้งานได้ภายในสองสามวันบนฮาร์ดแวร์ที่ดี มันให้บริการกระเป๋าเงินดิจิทัล แอปพลิเคชันแบบกระจายศูนย์ และผู้ตรวจสอบความถูกต้องได้เป็นอย่างดี สิ่งเดียวที่มันทำไม่ได้คือการตอบคำถามเกี่ยวกับประวัติ เช่น "ยอดเงินคงเหลือของ Vitalik ในวันที่ 7 ตุลาคม 2017 คือเท่าไหร่?" หากคุณไม่สนใจเรื่องนั้น คุณก็ไม่จำเป็นต้องคิดถึงโหมดการซิงค์อีกต่อไป
การซิงค์แบบเต็มรูปแบบยังคงมีให้ใช้งาน คนส่วนใหญ่ไม่จำเป็นต้องใช้ โหมดเต็มรูปแบบจะตรวจสอบทุกบล็อกย้อนกลับไปยังบล็อกเริ่มต้นและเรียกใช้ธุรกรรมทุกรายการอีกครั้ง ทำให้ไคลเอนต์สามารถตรวจสอบบล็อกเชนแบบครบวงจรได้ แทนที่จะเชื่อถือสแนปช็อตของ Snap มีประโยชน์หากคุณกังวลเกี่ยวกับ Snap หรือหากคุณกำลังสร้างคลังเก็บข้อมูลที่มีประวัติที่ถูกตัดแต่ง ไม่จำเป็นสำหรับการใช้งานทั่วไป
การจัดเก็บข้อมูลเป็นส่วนที่ใช้ทรัพยากรมาก และปี 2025 เป็นปีที่โหนดจัดเก็บข้อมูลมีการเปลี่ยนแปลง ก่อนการเปิดตัวเวอร์ชัน 1.16 โหนดจัดเก็บข้อมูลหมายถึง SSD ความเร็วสูงขนาด 12 ถึง 20 TB ซึ่งโดยพื้นฐานแล้วก็คือเซิร์ฟเวอร์ขนาดเล็ก เวอร์ชัน 1.16 มาพร้อมกับโหมดจัดเก็บข้อมูลแบบอิงตามเส้นทาง ซึ่งจัดเก็บสถานะในอดีตเป็นความแตกต่างแบบย้อนกลับ และลดความต้องการพื้นที่ดิสก์ลงเหลือประมาณ 1.9 ถึง 2.0 TB บนเมนเน็ต ทำให้ขนาดของ Geth ลดลงใกล้เคียงกับ Erigon (~1.77 TB) ข้อเสียในตอนแรกคือ การจัดเก็บข้อมูลแบบอิงตามเส้นทางไม่รองรับ Merkle proof ในอดีต (`eth_getProof` บนบล็อกเก่า) ตัวจัดทำดัชนี DeFi และเวิร์กโหลดที่ต้องการ proof จำนวนมากยังคงต้องการการจัดเก็บข้อมูลแบบอิงตามแฮชแบบเดิม เวอร์ชัน 1.17.0 ในเดือนกุมภาพันธ์ 2026 ได้เพิ่มการรองรับ proof ในโหมดอิงตามเส้นทางในบางการกำหนดค่า — ตรวจสอบบันทึกการเผยแพร่สำหรับเวอร์ชันที่แน่นอนของคุณ ผู้ใช้งานการจัดเก็บข้อมูลโดยทั่วไปคือ ผู้สำรวจบล็อก ทีมพิสูจน์หลักฐาน และบริษัทวิเคราะห์ข้อมูลที่จริงจัง คนส่วนใหญ่ที่อ่านคู่มือนี้คงไม่จำเป็นต้องใช้มัน
หมายเหตุเพิ่มเติม โหมดไคลเอ็นต์แบบเบา (Light-client mode) ซึ่งเป็นแฟล็กเก่า `--syncmode "light"` นั้นถูกยกเลิกแล้วและไม่มีการดูแลรักษาบนเมนเน็ตอีกต่อไป หากบทช่วยสอนปี 2026 บอกให้คุณเริ่ม Geth ในโหมดเบา แสดงว่าบทช่วยสอนนั้นล้าสมัยแล้ว
ติดตั้ง Geth บน Ubuntu, macOS และ Windows
ขั้นตอนการติดตั้งนั้นสั้นมาก เพียงเลือกแพลตฟอร์มที่คุณตั้งใจจะใช้งานจริง ไม่ใช่แพลตฟอร์มบนแล็ปท็อปของคุณ
ลินุกซ์ / อูบุนตู (ระบบปฏิบัติการหลัก)
โหนด Geth ที่ใช้งานจริงส่วนใหญ่ทำงานบน Ubuntu ทีม Ethereum ดูแล PPA และการใช้คำสั่งสามคำสั่งผ่านตัวจัดการแพ็กเกจของ Ubuntu จะทำให้คุณได้ไบนารีที่ใช้งานได้มา:
```
sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install ethereum
```
ใช้คำสั่ง `geth version` เพื่อยืนยัน PPA จะติดตามเวอร์ชันเสถียรล่าสุด ในการใช้งานจริง คุณมักจะกำหนดเวอร์ชันที่ใช้งานได้ดีด้วยคำสั่งเช่น `apt-get install ethereum=1.17.2-...` และอัปเกรดตามกำหนดเวลาที่เหมาะสมกว่า "เมื่อใดก็ตามที่ apt อยากจะอัปเดต"
macOS (เป็นมิตรกับนักพัฒนา)
บน macOS นั้น Homebrew จะจัดการให้ เพียงแค่สองบรรทัด:
```
brew tap ethereum/ethereum
brew install ethereum
```
Mac เหมาะอย่างยิ่งสำหรับการทดลองบนเครือข่ายทดสอบและการพัฒนา dApp แต่แทบไม่มีใครใช้ Mac เป็นตัวตรวจสอบความถูกต้องบนเครือข่ายหลักเลย เพราะการจัดการพลังงานนั้นเข้มข้นเกินไป และ macOS จะทำให้โหนดบีคอนของคุณเข้าสู่โหมดพักเครื่องในเวลาที่ไม่เหมาะสมเสมอ
วินโดวส์
มีไฟล์ติดตั้ง `.exe` และไฟล์เก็บถาวร `.zip` อยู่ที่ geth.ethereum.org และในหน้า GitHub releases ของโครงการ คลิกเพื่อดาวน์โหลดตัวติดตั้ง อนุญาตให้มันแก้ไข PATH ของคุณ จากนั้นเปิด Command Prompt หรือ PowerShell แล้วรันคำสั่ง `geth version` มันควรจะแสดงผลลัพธ์ออกมา
Windows Server สามารถรองรับโหนด Geth แบบสแตนด์อโลนได้อย่างสมบูรณ์แบบ โดยทั่วไปแล้วระบบตรวจสอบความถูกต้องมักจะใช้ Linux เนื่องจากไคลเอ็นต์สำหรับการสร้างฉันทามติส่วนใหญ่เริ่มต้นจาก Linux แต่คุณสามารถผสมผสานระบบอื่นๆ ได้ตามต้องการ ส่วนที่เหลือของคู่มือนี้จะเขียนคำสั่งในรูปแบบของเชลล์ Linux การแปลงเป็น PowerShell นั้นส่วนใหญ่เป็นเรื่องของตัวคั่นเส้นทางและวิธีการต่อบรรทัดที่แตกต่างกัน
ด็อกเกอร์
`docker pull ethereum/client-go:stable` จะสร้างคอนเทนเนอร์ที่สะอาดหมดจด Docker เป็นวิธีที่ง่ายที่สุดในการทดสอบ Geth เวอร์ชันใหม่โดยไม่ทำให้ระบบโฮสต์ของคุณเสียหาย นอกจากนี้ยังเป็นวิธีการใช้งานจริงที่น่าเชื่อถือหากทีมของคุณคุ้นเคยกับการใช้คอนเทนเนอร์อยู่แล้ว ข้อควรระวังอย่างหนึ่งคือ วอลุ่ม Docker ที่เก็บข้อมูล `chaindata` ต้องอยู่บน NVMe การวางไว้บนวอลุ่ม EBS ทั่วไป, ฮาร์ดดิสก์ หรือวอลุ่ม Docker Desktop บน Mac จะทำให้เกิดปัญหา "การซิงค์ค้าง" เหมือนในกระทู้ Reddit ทั่วไป
การสร้างจากแหล่งที่มา
การสร้างจากซอร์สโค้ดต้องการ Go เวอร์ชัน 1.23 หรือใหม่กว่า รวมถึงคอมไพเลอร์ C ด้วย คำสั่ง `make geth` จะสร้างเฉพาะ Node.js เท่านั้น ส่วนคำสั่ง `make all` จะสร้างชุดเครื่องมือแบบเต็มรูปแบบ ได้แก่ geth, clef, abigen, evm, devp2p และ rlpdump ควรใช้การสร้างจากซอร์สโค้ดเมื่อคุณต้องการเวอร์ชันที่ยังไม่ได้บรรจุเป็นแพ็กเกจ หรือเมื่อคุณมีแพตช์ส่วนตัวที่คุณไม่ต้องการดูแลรักษาในรูปแบบของ fork
เรียกใช้ Geth: ซิงค์ข้อมูลก่อน แล้วใช้คอนโซล JSON-RPC
ติดตั้งไบนารี่เรียบร้อยแล้ว สร้างรหัสลับ JWT แล้ว ไคลเอนต์ฉันทามติพร้อมใช้งานแล้ว คำสั่งแรกบนเครื่องเมนเน็ตจะมีลักษณะคร่าวๆ ดังนี้:
```
เกธ \
--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
```
พอร์ตหลักสามพอร์ตทำหน้าที่ในระบบนี้ พอร์ต 30303 ผ่าน TCP และ UDP ซึ่งเป็นช่องทางการสื่อสารแบบ peer-to-peer กับส่วนที่เหลือของ Ethereum พอร์ต 8545 เป็นช่องทาง HTTP-RPC ที่กระเป๋าเงินและสคริปต์ของคุณใช้เชื่อมต่อ และพอร์ต 8551 เป็น API ของ Engine ซึ่งเข้าถึงได้เฉพาะไคลเอ็นต์ฉันทามติของคุณและถูกควบคุมด้วยรหัสลับ JWT
หากต้องการตรวจสอบการทำงานของโหนด ให้เชื่อมต่อคอนโซล Geth (ซึ่งเป็นคอนโซล JavaScript ที่เชื่อมต่อกับ API ของโหนด) เปิดเชลล์ที่สอง:
```
geth attach http://127.0.0.1:8545
```
ตอนนี้เมธอด JSON-RPC ทุกตัวเป็นการเรียกใช้ JavaScript แล้ว เช่น `eth.blockNumber`, `net.peerCount` (ประมาณสามสิบถือว่าปกติบน mainnet) `eth.syncing` จะคืนค่า `false` เมื่อโหนดซิงค์ข้อมูลเสร็จแล้ว ต้องการตรวจสอบยอดคงเหลือไหม? ใช้ `web3.fromWei(eth.getBalance('0x...'), 'ether')` นี่คือส่วนติดต่อผู้ใช้ทั้งหมด
จากนั้นก็มีไฟล์บันทึก (log file) ให้ดู บรรทัดที่คุณต้องการดูคือ `Imported new chain segment` นั่นหมายความว่า Geth ได้ตามทันแล้วและกำลังประมวลผลธุรกรรมใหม่ๆ จากเครือข่ายบล็อกเชน Ethereum อย่างต่อเนื่อง หากไฟล์บันทึกของคุณแสดงแค่ `Looking for peers` และไม่มีอะไรเพิ่มเติม แสดงว่าไฟร์วอลล์กำลังบล็อกการเชื่อมต่อ P2P ขาเข้า เปิดพอร์ต 30303 บน TCP และ UDP รีสตาร์ท Geth แล้วลองใหม่อีกครั้ง วิธีนี้ได้ผลเก้าในสิบครั้ง
สำหรับการทำงานแบบอัตโนมัติ ไลบรารี Ethereum ทุกตัวที่คุ้มค่าแก่การใช้งานจะใช้ JSON-RPC ผ่าน HTTP หรือผ่าน WebSocket หากคุณส่งพารามิเตอร์ `--ws` เพิ่มเติม เช่น ethers.js, web3.js, viem, ไคลเอ็นต์ Go และไคลเอ็นต์ Python พวกมันจะทำงานกับโหนด Geth ในเครื่องของคุณเหมือนกับ Infura ทุกประการ เพียงแค่ชี้ไปที่ `http://127.0.0.1:8545` แล้วก็หยุด โค้ดจะยังคงเหมือนเดิม สิ่งเดียวที่เปลี่ยนไปคือใครเป็นผู้รับสาย
ใช้ Geth: บัญชี, Clef และธุรกรรม
Geth ยังคงมีตัวจัดการบัญชีให้ใช้งาน แต่คำแนะนำในปัจจุบันคือการแยกการลงนามออกจากโหนดโดยใช้ Clef Clef เป็นโปรแกรมขนาดเล็กที่แยกต่างหากซึ่งเก็บคีย์ของคุณและขอการยืนยันอย่างชัดเจนทุกครั้งที่มีสิ่งใดพยายามใช้คีย์เหล่านั้น
การสร้างบัญชีผ่าน Clef มีขั้นตอนดังนี้:
```
clef newaccount --keystore /var/lib/geth/keystore
```
Clef ต้องการรหัสผ่านที่มีความยาวอย่างน้อยสิบตัวอักษร มันจะสร้างไฟล์คีย์สโตร์ที่เข้ารหัสและส่งที่อยู่กลับมาให้คุณ ที่อยู่นั้นคือบัญชีที่ควบคุมโดยภายนอก (EOA) ซึ่งเป็นประเภทเดียวกับที่กระเป๋าเงินฮาร์ดแวร์หรือ MetaMask สร้างขึ้น ไม่มีอะไรแปลกใหม่
เพื่อให้ Geth ใช้ Clef ให้ชี้โหนดไปยังซ็อกเก็ต IPC ของ Clef โดยใช้คำสั่ง `--signer=/path/to/clef.ipc` หลังจากนั้น คำขอธุรกรรมทุกรายการ ไม่ว่าจะมาจากคอนโซล Geth หรือจาก dApp ที่ใช้ JSON-RPC API จะต้องได้รับการอนุมัติที่เทอร์มินัลของ Clef นี่คือโมเดลที่ทีม Geth แนะนำในปี 2026 คีย์จะอยู่ภายนอกโหนด โหนดเองไม่สามารถใช้ wei แม้แต่หน่วยเดียวได้
การถ่ายโอนข้อมูลจากเครื่องเล่นเกมคอนโซลจะมีลักษณะดังนี้:
```
eth.sendTransaction({
from: '0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec',
to: '0xce8dba5e4157c2b284d8853afeeea259344c1653',
value: web3.toWei(0.1, 'ether')
});
```
Clef ปรากฏขึ้น คุณยืนยัน การทำธุรกรรมเข้าสู่ mempool และไม่กี่วินาทีต่อมาก็อยู่ในบล็อก เบื้องหลังบรรทัดเดียวนี้ Geth ได้ทำการค้นหา nonce ประเมินค่าธรรมเนียม ส่งต่อลายเซ็นไปยัง Clef กระจายสัญญาณ และตรวจสอบการรวมเข้าไว้ด้วยกัน วงจรเดียวกันนี้ทำงานอยู่เบื้องหลัง dApp ทุกตัว
สำหรับงานที่ซับซ้อนยิ่งขึ้น จุดเชื่อมต่อ JSON-RPC เดียวกันนี้รองรับการส่งธุรกรรม การสมัครรับเหตุการณ์ การเรียกใช้ฟังก์ชันมุมมอง และการติดตาม จากมุมมองของไลบรารี อินสแตนซ์ Geth ในเครื่องของคุณนั้นไม่แตกต่างจากโหนดที่โฮสต์ไว้ ยกเว้นแต่ว่ามันเร็วกว่า ฟรีต่อการเรียกใช้ และเป็นของคุณเอง
การตั้งค่า Validator: วางเดิมพัน Ether และรับรางวัล
เมื่อโหนด Geth ของคุณซิงค์และจับคู่กับไคลเอ็นต์ฉันทามติแล้ว การเพิ่มตัวตรวจสอบความถูกต้องส่วนใหญ่เป็นเพียงการตั้งค่า คุณไม่จำเป็นต้องติดตั้งโหนดใหม่ เลเยอร์การดำเนินการ (Geth) ยังคงทำงานต่อไป ไคลเอ็นต์ฉันทามติจะรับบทบาทเป็นตัวตรวจสอบความถูกต้องเพิ่มเติม โดยจะลงนามรับรองในแต่ละยุค และเมื่อโปรโตคอลเลือกตัวตรวจสอบความถูกต้องของคุณแล้ว จะขอให้ Geth รวบรวมเนื้อหาของบล็อก
การเปิดใช้งานระบบนั้นมีส่วนประกอบหลักสามส่วน ส่วนแรกคือการฝากอีเธอร์ 32 เหรียญ คุณจะต้องสร้างคีย์ตรวจสอบความถูกต้องโดยใช้ CLI สำหรับการฝากอย่างเป็นทางการ ส่งธุรกรรมการฝากไปยังสัญญาบนเมนเน็ต และรอการเปิดใช้งาน ส่วนที่สองคือกระบวนการไคลเอ็นต์ตรวจสอบความถูกต้อง ซึ่งทำงานควบคู่ไปกับโหนดบีคอน เก็บคีย์ลงนามของคุณ และลงนามรับรองตามกำหนดเวลา ส่วนที่สามคือ MEV-Boost หรือการตั้งค่ารีเลย์ หากคุณต้องการรางวัลสำหรับการจัดลำดับธุรกรรมเพิ่มเติมจากรางวัลพื้นฐาน Geth เองไม่ได้ทำงานในส่วนของตัวตรวจสอบความถูกต้อง แต่เป็นไคลเอ็นต์ฉันทามติที่ทำงานนั้น Geth เป็นจุดสิ้นสุดการดำเนินการที่สร้างเพย์โหลดบล็อกจริงเมื่อถึงคิวของสล็อตตัวตรวจสอบความถูกต้องของคุณ
ในแต่ละวัน ผู้ตรวจสอบความถูกต้องจะสนใจตัวเลขสามอย่าง ได้แก่ การตรวจสอบความถูกต้องที่พลาดไป เวลาการซิงค์ข้อมูล และพื้นที่ดิสก์ที่ใช้งาน การตรวจสอบความถูกต้องที่พลาดไปเกือบทั้งหมดมักเกิดจากโหนดที่ล้าหลัง ซึ่งในทางกลับกันก็มักเกิดจากปัญหาการอ่านเขียนข้อมูลบนดิสก์หรือการสูญเสียการเชื่อมต่อกับโหนดอื่น พื้นที่ดิสก์ที่ใช้งานบน Geth คือสาเหตุหลัก หากต่ำกว่าข้อกำหนด NVMe ที่แนะนำ ประสิทธิภาพการตรวจสอบความถูกต้องก็จะลดลง และรางวัลก็จะลดลงตามไปด้วย
ผู้ที่ทำการ Staking ที่บ้านส่วนใหญ่ใช้มินิพีซีเฉพาะทาง เช่น Intel NUC, Beelink หรือเครื่องประกอบเองที่ใช้ Ryzen ค่าใช้จ่ายด้านฮาร์ดแวร์อยู่ที่ประมาณ 800 ถึง 2,000 ดอลลาร์สหรัฐฯ ค่าไฟและอินเทอร์เน็ตเพิ่มอีกประมาณ 10 ถึง 20 ดอลลาร์สหรัฐฯ ต่อเดือน การวิเคราะห์ของ Coin Bureau ในปี 2026 ระบุว่า ค่าใช้จ่ายสำหรับผู้ตรวจสอบความถูกต้อง (validator) ระดับมืออาชีพของ Hetzner อยู่ที่ 30 ถึง 40 ดอลลาร์สหรัฐฯ ต่อเดือน โหนดเต็มรูปแบบพื้นฐานของ AWS ต่ำกว่า 100 ดอลลาร์สหรัฐฯ และโหนดเก็บข้อมูลของ AWS ประมาณ 1,500 ดอลลาร์สหรัฐฯ การ Staking แบบเดี่ยวให้ผลตอบแทนประมาณ 4% ต่อปี (APY) จากรางวัลพื้นฐาน และเพิ่มขึ้นเป็น 5-6% เมื่อใช้ MEV-Boost บนฮาร์ดแวร์ที่บ้าน จะคุ้มทุนในเวลาประมาณ 4 ถึง 6 เดือน ในราคา Ether ในปัจจุบัน ณ ปลายปี 2025 เครือข่ายมีผู้ตรวจสอบความถูกต้องที่ใช้งานอยู่ประมาณ 1.06 ล้านราย ถือครอง ETH ประมาณ 35 ถึง 37 ล้านเหรียญ (29 ถึง 31% ของอุปทาน) Lido เพียงรายเดียวควบคุม 27.7% ของ ETH ที่ถูก Staking ทั้งหมด Coinbase ควบคุม 8.4% ผู้ตรวจสอบความถูกต้องอิสระแต่ละรายที่เพิ่มเข้ามาจะค่อยๆ เบี่ยงเบนความเข้มข้นไปในทิศทางตรงกันข้าม ซึ่งเป็นเหตุผลสำคัญที่ทำให้การวางเดิมพันแบบเดี่ยวๆ ยังคงเป็นสิ่งที่ผู้คนทำกันอยู่
Testnet กับ Mainnet: ควรติดตั้ง Ethereum Node ที่ไหนดี
อย่าเริ่มต้นบน mainnet ความผิดพลาดบน testnet นั้นเกิดขึ้นได้ง่ายและมีค่าใช้จ่ายสูง และไม่มีอะไรถูกกว่านี้อีกแล้ว Geth จัดการเครือข่ายที่รองรับทั้งหมดได้ด้วยแฟล็กเดียว
เครือข่ายทดสอบ Ethereum สองเครือข่ายที่คุณควรสนใจในปี 2026 คือ Holesky ซึ่งเป็นเครือข่ายทดสอบระยะยาวที่เน้นผู้ตรวจสอบความถูกต้อง และ Sepolia ซึ่งเป็นเครือข่ายที่เบากว่าและเน้นแอปพลิเคชัน หากต้องการโหนด Geth บน Sepolia ให้เปลี่ยน `--mainnet` เป็น `--sepolia` หากต้องการใช้งาน Holesky ให้เปลี่ยน `--holesky` เป็น `--holesky` โฟลเดอร์ข้อมูลของคุณควรอยู่ในเส้นทางที่แยกต่างหากจาก `chaindata` บนเครือข่ายหลัก หากคุณใช้โฟลเดอร์เดียวกัน Geth จะไม่สามารถเริ่มต้นได้เนื่องจากรหัสเชนไม่ตรงกัน ซึ่งเป็นข้อความแสดงข้อผิดพลาดที่ใช้เวลาแก้ไขเพียงสามสิบวินาที แต่ใช้เวลาค้นหาเป็นชั่วโมง
อีเธอร์ใน Testnet นั้นฟรี เว็บไซต์แจกอีเธอร์อย่าง Paradigm Multifaucet และ Sepolia faucet ที่ faucet.sepolia.dev จะแจก Sepolia ETH ในปริมาณที่เพียงพอสำหรับการใช้งานสัญญา ทดสอบการทำงานร่วมกัน และส่งธุรกรรมหลายพันรายการ "อีเธอร์" นั้นเป็นของปลอม ส่วนอย่างอื่นเป็นของจริงทั้งหมด: EVM ทำงานเหมือนเดิม API JSON-RPC ก็เหมือนเดิม การเชื่อมต่อกับไคลเอ็นต์ฉันทามติของคุณก็เหมือนเดิม และความยุ่งยากในการใช้งานก็เหมือนเดิม ลองใช้งานระบบของคุณบน Sepolia สักหนึ่งสัปดาห์ก่อนที่จะเชื่อมต่อกับ mainnet
เครือข่ายทดสอบเก่าๆ ถูกปิดไปแล้ว Ropsten, Rinkeby, Kovan, Goerli — ทั้งหมดถูกปลดระวางแล้ว หากบทช่วยสอนใดยังบอกให้คุณเริ่ม Geth ด้วย `--ropsten` แสดงว่ามันเป็นเวอร์ชันก่อนการรวม (pre-Merge) และคุณควรปิดแท็บนั้นไป
เพื่อให้ได้สภาพแวดล้อมที่เป็นส่วนตัวอย่างแท้จริง ให้สร้างเครือข่ายของคุณเอง โหมด `--dev` ของ Geth จะบูตเชนแบบโหนดเดียวในไม่กี่วินาที ซึ่งเหมาะสำหรับการทดสอบหน่วย สำหรับเครือข่ายส่วนตัวแบบหลายเครื่อง ให้เขียนไฟล์ `genesis.json` แบบกำหนดเอง แชร์ไฟล์นั้นให้กับเครื่องต่างๆ และเริ่มต้นกระบวนการ Geth แต่ละตัวด้วย `--datadir` ที่ชี้ไปยังโฟลเดอร์ chaindata ใหม่ เฟรมเวิร์ก Kurtosis จะรวมทุกอย่างนี้ไว้ในคำสั่งเดียว หากคุณไม่ต้องการเชื่อมต่อด้วยตนเอง
ปัญหาและวิธีแก้ไขปัญหาที่พบบ่อยใน Geth Node
เหตุการณ์ที่เกี่ยวข้องกับเกธส่วนใหญ่มักมีรูปแบบคล้ายคลึงกัน การแก้ไขมักทำได้อย่างรวดเร็วเมื่อคุณเข้าใจรูปแบบนั้นแล้ว
การซิงค์หยุดชะงักที่ไม่กี่เปอร์เซ็นต์ โหนด Geth ของคุณออนไลน์อยู่ แต่ซิงค์ไม่ทัน: จำนวน Peer ต่ำเกินไป แบนด์วิดท์เต็ม หรือดิสก์ทำงานไม่ทัน ตรวจสอบ `net.peerCount` ในคอนโซล หากต่ำกว่าสิบห้า แสดงว่าพอร์ต P2P ขาเข้าของคุณถูกปิดกั้นด้วยไฟร์วอลล์ เปิดพอร์ต 30303 TCP และ UDP หากปกติ ให้รัน `iostat -xm 5` บน Linux ระหว่างการซิงค์ หาก SSD ทำงานเต็ม 100% แสดงว่าคุณมีข้อจำกัดด้าน I/O และต้องการพื้นที่จัดเก็บข้อมูลที่เร็วกว่า หมายเหตุเฉพาะเวอร์ชัน: Geth v1.17.1 (3 มีนาคม 2026) เปิดตัวเพื่อแก้ไขข้อผิดพลาดในการซิงค์แบบ snap ใน v1.17.0 โดยเฉพาะ หากคุณยังคงใช้เวอร์ชันนั้น การอัปเกรดคือวิธีแก้ไข
"เครือข่ายหลังการรวม แต่ไม่พบไคลเอ็นต์บีคอน" ไคลเอ็นต์ฉันทามติไม่ทำงาน รหัสลับ JWT ไม่ตรงกัน หรือไคลเอ็นต์ฉันทามติชี้ไปยังพอร์ต AuthRPC ที่ไม่ถูกต้อง ตรวจสอบเส้นทาง JWT พอร์ต 8551 และตรวจสอบให้แน่ใจว่าทั้งสองกระบวนการเริ่มต้นด้วยไฟล์รหัสลับเดียวกัน
พื้นที่ดิสก์เต็มในชั่วข้ามคืน การซิงค์ Snap อาจทำให้การใช้งานดิสก์พุ่งสูงขึ้นในช่วงเริ่มต้นของการกู้คืนสถานะ การตัดแต่งจะทำงานโดยอัตโนมัติหลังจากนั้น หากคุณเริ่มต้นด้วย SSD ขนาด 1 TB หัวอ่านจะตามทันในที่สุด วิธีแก้ไขคือการเพิ่มพื้นที่ ไม่ใช่การตัดแต่งที่รุนแรงขึ้น เพราะการตัดแต่งของ Geth ได้รับการปรับแต่งมาแล้ว ย้าย chaindata ไปยัง NVMe ที่มีขนาดใหญ่กว่า แล้วใช้ rsync ถ่ายโอนข้อมูล
Geth ไม่สามารถเริ่มต้นได้: "ไม่พบฐานข้อมูลที่เข้ากันได้กับ Geth เวอร์ชันนี้" การทำงานครั้งก่อนใช้รหัสเชนที่แตกต่างกัน เวอร์ชัน Geth เก่ากว่า หรือสถานะเสียหาย โฟลเดอร์ `chaindata` ไม่ตรงกัน โปรดซิงค์ข้อมูลไปยังไดเร็กทอรีข้อมูลใหม่ หรือย้อนกลับไปยัง Geth เวอร์ชันก่อนหน้า
ตัวตรวจสอบความถูกต้องขาดการยืนยัน หากโหนด Geth ของคุณอ่านบล็อกใหม่ทุกบล็อกได้อย่างถูกต้อง แต่ตัวตรวจสอบความถูกต้องยังคงขาดการยืนยัน ให้ตรวจสอบแรงดันดิสก์ก่อน ตามด้วยเครือข่าย และสุดท้ายคือ CPU รูปแบบในเครื่องมือตรวจสอบเช่น Netdata นั้นชัดเจนมาก: PSI (Pressure Stall Information) สำหรับดิสก์จะสูงถึง 30% หรือมากกว่าในช่วงเวลาการยืนยัน
การร้องขอ RPC ช้า ลง ไคลเอนต์ dApp ขนาดใหญ่ที่เรียกใช้ `eth_getLogs` หรือ `debug_traceTransaction` อย่างต่อเนื่องอาจทำให้ CPU ของ Geth เต็มได้ ควรย้ายการรับส่งข้อมูลเหล่านั้นไปยังโหนดอื่น หรือใช้ `--rpc.gascap` และ `--rpc.txfeecap` เพื่อจำกัดการเรียกใช้ที่ใช้ทรัพยากรมาก
นิสัยสุดท้ายคือ ตรวจสอบบันทึกการทำงานอย่างต่อเนื่องในช่วงสัปดาห์แรก เพื่อให้ Geth ทำงานได้อย่างราบรื่นภายใต้ภาระงานจริง เครื่องมือต่างๆ เช่น Netdata, Prometheus + Grafana หรือเพียงแค่คำสั่ง `journalctl -fu geth` จะช่วยให้เห็นโหมดความล้มเหลวในช่วงแรกได้ชัดเจน เมื่อถึงสัปดาห์ที่สอง การแจ้งเตือนเกี่ยวกับการรับรองความถูกต้องที่ขาดหายไปและอัตราการเต็มของดิสก์ก็เพียงพอแล้ว
Geth เทียบกับไคลเอ็นต์ Ethereum อื่นๆ: ข้อดีข้อเสีย
Geth เป็นตัวเลือกแรกโดยค่าเริ่มต้น แต่ไม่ใช่ตัวเลือกเดียว และคำตอบของคำถาม "ฉันควรเปลี่ยนไปใช้ตัวเลือกอื่นหรือไม่" ขึ้นอยู่กับความต้องการของคุณ
| ลูกค้า | ภาษา | ส่วนแบ่งปี 2026 (clientdiversity.org / ช่วง Stake.fish) | จุดแข็ง | ใช้ในกรณีที่... |
|---|---|---|---|---|
| เกธ | ไป | 41 ถึง 50% | ความเสถียร ชุมชนขนาดใหญ่ ค่าเริ่มต้นอย่างเป็นทางการ | คุณต้องการโหนดแรกที่ปลอดภัยที่สุด |
| เนเธอร์มายด์ | ซี# | 25 ถึง 38% | การซิงค์ข้อมูลแบบรวดเร็ว รองรับปลั๊กอิน และ Hyperledger | คุณต้องการไคลเอนต์การประมวลผลที่ไม่ใช่ภาษา Go |
| เบสุ | ชวา | 10 ถึง 16% | คุณสมบัติระดับองค์กร, เชนที่มีสิทธิ์อนุญาต, ไฮเปอร์เลดเจอร์ | คุณใช้งานบล็อกเชนแบบมีสิทธิ์อนุญาต |
| เรธ | สนิม | 2 ถึง 8% | โค้ดเบสแบบโมดูลาร์ที่ทันสมัย ซิงค์ข้อมูลได้อย่างรวดเร็ว | คุณต้องการไคลเอ็นต์ Rust ชั้นนำ |
| เอริกอน | สนิม/โก | 3 ถึง 7% | ไฟล์เก็บข้อมูลขนาดกะทัดรัด (~1.77 TB) ค้นหาข้อมูลในอดีตได้อย่างรวดเร็ว | คุณต้องการโหนดเก็บข้อมูลขนาดเล็ก |
เหตุผลหลักที่ชุมชนเลือกใช้ระบบอื่นที่ไม่ใช่ Geth คือความหลากหลายของไคลเอ็นต์ หากไคลเอ็นต์ตัวใดตัวหนึ่งได้รับเสียงส่วนใหญ่เกินสองในสามบนเมนเน็ตและปล่อยการอัปเกรดที่มีข้อบกพร่อง ผู้ตรวจสอบความถูกต้องบนไคลเอ็นต์นั้นอาจเสี่ยงต่อการถูกลงโทษ การแบ่งกลุ่มผู้ตรวจสอบความถูกต้องของคุณไปยังไคลเอ็นต์สองตัวจะช่วยลดความเสี่ยงนั้นลงครึ่งหนึ่ง สำหรับผู้ที่ทำการสเตคเกอร์ที่บ้านเพียงคนเดียว การคำนวณนั้นง่ายกว่ามาก: เลือกไคลเอ็นต์ที่คุณสามารถดูแลรักษาให้ใช้งานได้ดี และเปลี่ยนไปใช้ไคลเอ็นต์อื่นก็ต่อเมื่อมีเหตุผลเฉพาะเท่านั้น สถาปัตยกรรมของโหนดนั้นคล้ายคลึงกันในทุกไคลเอ็นต์ ดังนั้นการเปลี่ยนในภายหลังจึงง่ายกว่าที่คิด Erigon และ Reth โดยเฉพาะอย่างยิ่ง ตอนนี้มีความเสถียรมากพอที่จะเป็นไคลเอ็นต์หลัก ไม่ใช่แค่สิ่งแปลกใหม่เท่านั้น
