﻿---
title: "เครือข่ายเพียร์ทูเพียร์"
description: "เครือข่ายเพียร์ทูเพียร์ทำให้แต่ละโหนดมีชุดเพียร์โดยตรงที่จำกัดและเปลี่ยนแปลงได้สำหรับการค้นหา การเผยแพร่แบบกอสซิป และการแลกเปลี่ยนคำขอและคำตอบ แต่ไม่ได้สร้างมุมมองส่วนกลางเพียงหนึ่งเดียวหรือเปลี่ยนการยอมรับข้อความให้เป็นฉันทามติ"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# เครือข่ายเพียร์ทูเพียร์

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

<a id="answer"></a>

## คำตอบโดยตรง

เครือข่ายเพียร์ทูเพียร์ช่วยให้แต่ละโหนดค้นหาและรักษาชุดเพียร์โดยตรงที่จำกัด แลกเปลี่ยนข้อความโปรโตคอลที่ยืนยันตัวตน และสร้างมุมมองเฉพาะของตนได้โดยไม่ต้องส่งทุกอย่างผ่านเซิร์ฟเวอร์กลางเพียงเครื่องเดียว เครือข่ายนี้ไม่ใช่กราฟที่ทุกโหนดเชื่อมถึงกัน ไม่ใช่เมมพูลส่วนกลาง และไม่ใช่แหล่งความจริงด้วยตัวเอง การที่เพียร์รับ ตรวจสอบ หรือส่งต่อวัตถุไม่ได้พิสูจน์ว่าทุกโหนดเห็นวัตถุนั้น มีบล็อกรวมวัตถุนั้น หรือฉันทามติให้สถานะสิ้นสุดแล้ว

Ethereum หลังการผสานใช้เครือข่ายเพียร์ทูเพียร์ 2 ชุดแยกกัน ไคลเอนต์ชั้นการประมวลผลใช้การค้นหา RLPx และความสามารถ `eth` ที่มีรุ่นกำกับเพื่อซิงก์และแลกเปลี่ยนธุรกรรม ไคลเอนต์ชั้นฉันทามติใช้ discv5 เพื่อค้นหาเพียร์ และใช้กอสซิป libp2p กับโปรโตคอลคำขอและคำตอบสำหรับบล็อกบีคอน การรับรอง และวัตถุฉันทามติอื่น ไคลเอนต์ทั้งสองประสานงานกันภายในเครื่องผ่าน Engine API ที่ยืนยันตัวตน ส่วนกระเป๋ามักส่งธุรกรรมผ่าน JSON-RPC และไม่ได้กลายเป็นโหนดกอสซิปเพราะเหตุนี้

<a id="mechanism"></a>

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

1. ระบุเชน เครือข่าย เจเนซิส การกำหนดค่าฟอร์ก รุ่นไคลเอนต์ชั้นการประมวลผลและชั้นฉันทามติ ตัวตนโหนด และเวลาสังเกต วาดไคลเอนต์ชั้นการประมวลผล ไคลเอนต์ชั้นฉันทามติ ตัวตรวจสอบความถูกต้องที่อาจมี Engine API ภายในเครื่อง และ RPC สำหรับผู้ใช้เป็นคนละองค์ประกอบ
2. ตรวจทุกเส้นทางค้นหา ได้แก่ บูตโหนดที่ติดมากับโปรแกรม รายการ DNS เพียร์คงที่หรือที่เชื่อถือ ตัวตน ENR หรือ enode จุดเชื่อมต่อและลำดับที่ประกาศ ความเข้ากันได้ของเครือข่าย NAT และการเข้าถึงจากภายนอก ENR ที่ลงนามผูกระเบียนกับกุญแจ แต่ไม่ได้พิสูจน์ความซื่อสัตย์ การซิงก์ หรือการเข้าถึงได้ในปัจจุบัน
3. บันทึกการเชื่อมต่อกับการเจรจาโปรโตคอลแยกกัน เพียร์ชั้นการประมวลผลสร้างเซสชัน RLPx และเจรจาความสามารถ เช่น `eth` ส่วนเพียร์ชั้นฉันทามติเจรจาการขนส่ง libp2p ความปลอดภัย และรหัสโปรโตคอลหลังค้นพบด้วย discv5 การพบจุดเชื่อมต่อไม่ได้หมายถึงความเข้ากันได้ระดับแอปพลิเคชัน
4. ติดตามวัตถุแต่ละชนิดตามเส้นทางจริง ธุรกรรมอาจเริ่มจากการส่งผ่าน RPC ไปสู่การตรวจสอบภายในเครื่องและเมมพูลชั้นการประมวลผล แล้วผ่านการประกาศและคำขอ `eth` วัตถุฉันทามติใช้การตรวจสอบกอสซิปเฉพาะหัวข้อ ส่วนบล็อกที่ขาดสามารถดึงผ่านคำขอและคำตอบ
5. ใช้การถอดรหัสแบบมีขอบเขต การกำจัดข้อมูลซ้ำ การจำกัดอัตรา และการตรวจลายเซ็น ไวยากรณ์ และสถานะ ก่อนรับหรือส่งต่อภายในเครื่อง บันทึกผลที่ไม่ถูกต้อง ถูกละเว้น ไม่พร้อมใช้ และติดข้อจำกัดทรัพยากร คะแนนเพียร์และนโยบายตัดการเชื่อมต่อเป็นการตัดสินใจของโปรแกรมเฉพาะเครื่อง ไม่ใช่ชื่อเสียงในฉันทามติ
6. แยกการได้รับ การตรวจสอบ การส่งต่อ การรวมธุรกรรม ผลการประมวลผล การเลือกฟอร์ก การให้เหตุผลรองรับ และภาวะสิ้นสุดเป็นคนละสถานะและคนละเวลา เปรียบเทียบหลายเพียร์หรือหลายโหนดเมื่อคำตอบจากพูล หัวเชน หรือประวัติภายในเครื่องไม่ครบ ขัดแย้ง หรือล้าสมัย
7. เฝ้าติดตามความหลากหลายของเพียร์ขาเข้าและขาออก ผู้ดำเนินการ คำนำหน้า IP การกระจุกตัวของ ASN การเปลี่ยนเพียร์ เวลาแฝง การสูญหายของแพ็กเก็ต แบนด์วิดท์ คิว การรับส่งข้อมูลไม่ถูกต้อง ความถูกต้องของนาฬิกา และการพึ่งพา RPC ทดสอบการสูญเสียบูตโหนด ความล้มเหลวของ NAT การแบ่งเครือข่าย การโจมตีแบบครอบงำเพียร์ ภาระเกิน และการฟื้นตัวโดยไม่กล่าวอ้างว่าป้องกันได้สมบูรณ์

การค้นหาเพียร์ ความปลอดภัยของการขนส่ง และความถูกต้องระดับแอปพลิเคชันแก้ปัญหาต่างกัน บูตโหนดแนะนำเพียร์ที่เป็นไปได้ แต่ไม่ส่งต่อการรับส่งข้อมูลทั่วไปหรือเลือกเชนมาตรฐาน การเข้ารหัสปกป้องเนื้อหาเซสชันและการยืนยันตัวตน แต่เพียร์ยังทราบจุดเชื่อมต่อและเวลา ผู้ให้บริการ RPC ระยะไกลยังอาจเห็นคำค้น ที่อยู่ และธุรกรรมที่ส่ง

การเผยแพร่เกิดพร้อมกันและขึ้นกับโทโพโลยี การกระจายต่อ เส้นทางซ้ำ การส่งเรียงตามแบนด์วิดท์ CPU สำหรับตรวจสอบ คิว การสูญหายของแพ็กเก็ต การส่งซ้ำ คะแนนเพียร์ และกฎเฉพาะวัตถุ เป็นตัวกำหนดการกระจายและช่วงปลายของเวลาที่มาถึง สูตรอย่าง `delay = hops * perHopTime` เป็นเพียงแบบจำลองการสอนแบบเรียงลำดับที่ระบุสมมติฐาน ไม่ใช่การรับประกันของเครือข่าย

<a id="example"></a>

## ตัวอย่าง

- **เส้นทางเรียงลำดับเทียบกับไปป์ไลน์** บนเส้นทางสาธิต `4 hops` แต่ละฮอปใช้เวลาเครือข่าย `80 ms` และเวลาตรวจสอบ `20 ms` การทำงานแบบเรียงลำดับทั้งหมดให้ `4 * (80 + 20) = 400 ms` หากการตรวจสอบซ้อนกับการส่งครั้งถัดไป ขอบล่างอย่างง่ายคือ `4 * 80 + 20 = 340 ms` ทั้งสองค่าไม่ใช่เวลาเผยแพร่ทั่วทั้งเครือข่าย
- **การประกาศและดึงธุรกรรม** โหนดได้รับแฮชธุรกรรม `20` รายการและมีอยู่แล้ว `6` รายการ จึงขาดตัวธุรกรรม `20 - 6 = 14` รายการ หากคำขอสาธิตบรรจุได้ไม่เกิน `8` รายการ จะต้องใช้ `ceil(14 / 8) = 2 batches` เมื่อเวลาไปกลับเท่ากับ `120 ms` และตรวจสอบชุดละ `30 ms` การทำงานแบบเรียงลำดับใช้ `2 * (120 + 30) = 300 ms` ส่วนแบบขนานในอุดมคติใช้ `150 ms` ขีดจำกัดจริงขึ้นกับรุ่น `eth` ที่เจรจาและไคลเอนต์
- **ความน่าจะเป็นแบบง่ายของการโจมตีครอบงำเพียร์** หากเพียร์ขาออกแต่ละรายจาก `8` รายถูกสุ่มอย่างอิสระ และผู้สมัครที่เป็นอันตรายมี `25%` ความน่าจะเป็นที่ทั้งหมดเป็นอันตรายคือ `0.25^8 = 0.0000152587890625 = 0.00152587890625%` อคติของการค้นหา ตัวตน Sybil สหสัมพันธ์ของ IP และ ASN และการรักษาเพียร์ไว้ละเมิดสมมติฐานความเป็นอิสระ ตัวเลขนี้จึงไม่ใช่การรับประกันความปลอดภัย
- **ภาระตรวจสอบเกิน** กอสซิปขาเข้าเท่ากับ `900 messages/s` ผู้ทำงาน `4` ชุดตรวจได้ชุดละ `250 messages/s` ทำให้มีกำลัง `1,000 messages/s` กำลังสำรอง `100 messages/s` และใช้งาน `90%` การโจมตีที่ `1,400 messages/s` สร้างงานค้าง `400 messages/s` และ `6,000 messages` ใน `15 seconds` คิวขนาด `5,000-message` เต็มใน `5,000 / 400 = 12.5 seconds` ก่อนทิ้งข้อความหรือจำกัดอัตรา โดยไม่รวมความแปรปรวนของเวลาบริการ

<a id="risks"></a>

## ความเสี่ยง

- กำหนดค่าเชน เจเนซิส หรือฟอร์กผิด
- ไคลเอนต์ชั้นการประมวลผล ไคลเอนต์ชั้นฉันทามติ หรือ Engine API ไม่เข้ากัน
- การค้นหาผ่านบูตโหนดและ DNS กระจุกตัวหรือถูกยึด
- ข้อมูลจุดเชื่อมต่อล้าสมัย ปลอม หรือเข้าถึงไม่ได้
- NAT ไฟร์วอลล์ หรือการกำหนดค่าพอร์ตขวางการเข้าถึงที่คาดหมาย
- การโจมตีแบบครอบงำเพียร์กรองมุมมองภายในเครื่องของโหนด
- ตัวตน Sybil และการกระจุกตัวของ IP, ASN, ผู้ดำเนินการ หรือคลาวด์
- พึ่งพาเพียร์คงที่หรือที่เชื่อถือมากเกินไป
- การเซ็นเซอร์ธุรกรรมหรือการส่งต่อแบบเลือก
- กระแสคำสั่งสาธารณะกับส่วนตัวต่างกัน
- กฎรับ แทนที่ และขับออกจากเมมพูลภายในเครื่องต่างกัน
- กอสซิปไม่ถูกต้องใช้ CPU ตรวจสอบจนหมด
- คำขอขนาดใหญ่ การคลายการบีบอัด แบนด์วิดท์ หน่วยความจำ หรือดิสก์ใช้ทรัพยากรจนหมด
- การบิดเบือนคะแนนเพียร์หรือการลงโทษผิด
- แรงดันย้อนกลับของคิวทิ้งข้อความที่ไวต่อเวลา
- เวลาแฝง การสูญหาย หรือความคลาดเคลื่อนของนาฬิกาทำให้หัวเชนต่างกันชั่วคราว
- รุ่นโปรโตคอลหรือไดเจสต์ฟอร์กไม่เข้ากัน
- ตีความประวัติที่ตัดทอนหรือคำตอบว่าทรัพยากรไม่พร้อมใช้เป็นการไม่มีข้อมูล
- รั่วไหลความเป็นส่วนตัวของ IP เวลา คำค้น และต้นทางธุรกรรม
- RPC แบบรวมศูนย์หรือเปิดเผยทำให้ถูกติดตาม ได้มุมมองล้าสมัย ถูกเซ็นเซอร์ หรือถูกยึด

<a id="misconceptions"></a>

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

- **ทุกโหนดเชื่อมต่อโดยตรงกับทุกโหนดอื่น** แต่ละโหนดมีชุดเพียร์ภายในเครื่องที่จำกัดและเปลี่ยนแปลงได้ โหนดต่างกันจึงอาจเห็นข้อความและหัวเชนต่างกันชั่วคราว
- **บูตโหนดเป็นแหล่งบล็อกที่เชื่อถือหรือเป็นผู้ร่วมฉันทามติ** บทบาทปกติคือแนะนำเพียร์ในช่วงเริ่มต้น ส่วนความถูกต้องของเชนและการเลือกฟอร์กตรวจสอบที่อื่น
- **ธุรกรรมที่เพียร์หนึ่งยอมรับจะเผยแพร่ทั่วโลกและรับประกันว่าถูกรวม** การรับและส่งต่อเป็นเรื่องเฉพาะเครื่อง และผู้สร้างหรือผู้เสนอบล็อกอาจไม่นำธุรกรรมนั้นไปรวม
- **การตรวจสอบกอสซิปหมายถึงฉันทามติและภาวะสิ้นสุด** นี่เป็นด่านเครือข่ายภายในเครื่องขั้นต้น การเลือกฟอร์ก การให้เหตุผลรองรับ และภาวะสิ้นสุดเป็นเครื่องสถานะแยกกัน
- **เพียร์มากขึ้นหรือการขนส่งแบบเข้ารหัสให้ความนิรนามและต้านการครอบงำเพียร์โดยอัตโนมัติ** ความหลากหลายและการเลือกยังสำคัญ และเพียร์กับผู้ให้บริการ RPC ยังเชื่อมโยงจุดเชื่อมต่อ เวลา และกิจกรรมได้

<a id="related"></a>

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

- [โหนดเต็มรูปแบบ](/th/crypto/full-node/)
- [เมมพูล](/th/crypto/mempool/)
- [การต้านการเซ็นเซอร์](/th/crypto/censorship-resistance/)

<a id="sources"></a>

## แหล่งข้อมูล

- [Networking layer](https://ethereum.org/developers/docs/networking-layer) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [Ethereum Wire Protocol (ETH)](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) - Ethereum devp2p (เข้าถึงเมื่อ: 2026-08-13)
- [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md) - Ethereum devp2p (เข้าถึงเมื่อ: 2026-08-13)
- [Node Discovery Protocol v5 - Wire Protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) - Ethereum devp2p (เข้าถึงเมื่อ: 2026-08-13)
- [Phase 0 -- Networking](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Consensus Specs (เข้าถึงเมื่อ: 2026-08-13)
- [gossipsub v1.1: Security extensions to improve on attack resilience and bootstrapping](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) - libp2p (เข้าถึงเมื่อ: 2026-08-13)
- [Connecting To The Network](https://geth.ethereum.org/docs/fundamentals/peer-to-peer) - go-ethereum (เข้าถึงเมื่อ: 2026-08-13)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)

Source: https://wiki.fcontext.com/th/crypto/peer-to-peer-network/index.mdx
