---
title: "Front-running บนเชน"
description: "Front-running บนเชนคือการใช้ข้อมูลของธุรกรรมที่รอดำเนินการเพื่อให้ธุรกรรมอีกชุดได้รับการประมวลผลก่อนและทำกำไร บทความนี้อธิบายผลของพูลธุรกรรมสาธารณะ การจัดลำดับ MEV slippage และการส่งแบบส่วนตัว"
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.

# Front-running บนเชน

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

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

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

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

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

สำหรับผู้ใช้ ประเด็นสำคัญคือธุรกรรมเปิดเผยเจตนาที่มีมูลค่าก่อนดำเนินการหรือไม่ ข้อจำกัดของธุรกรรมเปิดช่องให้ดึงมูลค่าหรือไม่ และใครมีอิทธิพลต่อลำดับได้บ้าง Swap บน DEX ที่ตั้ง slippage กว้าง การรับสิทธิ์แบบสาธารณะที่ใช้ความลับซ้ำได้ การชำระบัญชี การประมูล และการ mint แบบจำกัดจำนวน ล้วนดึงดูดการแข่งขันได้

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

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

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

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

ฟิลด์ค่าธรรมเนียมของ Ethereum เช่น `maxPriorityFeePerGas` และ `maxFeePerGas` มีผลต่อจำนวนที่ผู้ส่งยอมจ่าย แต่ไม่ได้ทำให้เนื้อหาธุรกรรมเป็นส่วนตัว และ Builder อาจประเมินบันเดิลแทนการเรียงทุกธุรกรรมด้วยฟิลด์ค่าธรรมเนียมเดียว ดังนั้น Front-running จึงเป็นปัญหาเรื่องข้อมูลและการจัดลำดับ ไม่ใช่แค่การแข่งขันราคา Gas

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

## ตัวอย่าง

สมมติว่าพูล AMM มี 100 ETH และ 200,000 USDC ผู้ใช้ส่งธุรกรรมสาธารณะเพื่อซื้อ ETH ด้วย 10,000 USDC โดยตั้งค่าความคลาดเคลื่อน 5% ธุรกรรมที่รออยู่เปิดเผยทิศทาง ขนาด และผลลัพธ์ขั้นต่ำที่ยอมรับได้

Searcher จำลอง Swap แล้วส่งคำสั่งซื้อให้ดำเนินการก่อน ตามด้วยคำสั่งขายให้ดำเนินการหลัง หากทั้งสองรายการถูกจัดไว้รอบธุรกรรมของผู้ใช้ ผู้ใช้จะได้รับ ETH น้อยกว่ากรณีไม่มี sandwich แต่ยังอยู่ในขอบเขต 5% ส่วน Searcher เก็บส่วนต่างหลังหักค่าธรรมเนียม

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

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

## ความเสี่ยงและการลดความเสี่ยง

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

- กำหนดผลลัพธ์ขั้นต่ำหรือขีดจำกัดราคาที่สมเหตุสมผลตามความลึกของพูลและสภาวะปัจจุบัน อย่าขยาย slippage เพียงเพื่อบังคับให้ธุรกรรมสำเร็จ
- ตรวจสอบผลกระทบต่อราคา สภาพคล่อง กฎการโอนโทเคน และเส้นทางก่อนลงนาม โดยเฉพาะธุรกรรมขนาดใหญ่ในพูลที่ตื้น
- ใช้บริการส่งแบบส่วนตัวหรือป้องกัน MEV ที่น่าเชื่อถือเมื่อเหมาะสม พร้อมตรวจสอบการครอบคลุม Builder พฤติกรรมเมื่อเกิดข้อผิดพลาด นโยบายความเป็นส่วนตัว และสมมติฐานด้านความไว้วางใจ
- ในการออกแบบโปรโตคอล อย่าใส่ความลับที่ให้สิทธิ์แก่ผู้มาก่อนไว้ในข้อมูลธุรกรรม ควรใช้การผูกกับผู้รับ commit-reveal การประมูลแบบเป็นชุด หรือกลไกที่เหมาะกับงาน

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

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

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

### ความเชื่อผิด 1: จ่าย Gas มากขึ้นแล้วจะป้องกัน Front-running ได้

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

### ความเชื่อผิด 2: การดำเนินการที่เสียเปรียบทุกครั้งคือการโจมตีแบบ sandwich

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

### ความเชื่อผิด 3: Slippage เป็นศูนย์ปลอดภัยที่สุดเสมอ

ขีดจำกัดที่แคบเกินไปอาจปฏิเสธการเคลื่อนไหวของราคาตามปกติ และยังเสีย Gas เมื่อธุรกรรมสาธารณะย้อนกลับ ขีดจำกัดที่เหมาะสมขึ้นอยู่กับสภาพคล่อง ขนาดธุรกรรม ความเร่งด่วน และการขาดทุนสูงสุดที่ผู้ใช้ยอมรับได้

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

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

- [DEX](/th/crypto/dex/)
- [ค่าธรรมเนียม Gas](/th/crypto/gas-fee/)
- [MEV](/th/crypto/mev/)
- [การโจมตี Sybil](/th/crypto/sybil-attack/)
- [Yield farming](/th/crypto/yield-farming/)

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

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

- [Transactions](https://ethereum.org/developers/docs/transactions/) - ethereum.org (เข้าถึงเมื่อ: 2026-08-20)
- [Maximal extractable value (MEV)](https://ethereum.org/developers/docs/mev/) - ethereum.org (เข้าถึงเมื่อ: 2026-08-20)
- [Flashbots Protect Quick Start](https://docs.flashbots.net/flashbots-protect/quick-start) - Flashbots (เข้าถึงเมื่อ: 2026-08-20)

Source: https://wiki.fcontext.com/th/crypto/front-running/index.mdx