ธุรกรรมคริปโตได้รับการยืนยันอย่างไร: จากการกดส่งจนถึงสถานะสุดท้าย

คำว่า "ได้รับการยืนยัน" หมายความว่าอย่างไรกันแน่?

คำตอบสั้น ๆ: ได้รับการยืนยันหมายความว่ามีบล็อกที่ถูกต้องซึ่งปัจจุบันถือเป็นส่วนหนึ่งของเชนที่ได้รับการยอมรับบรรจุธุรกรรมนั้นไว้ บน Bitcoin บล็อกที่บรรจุธุรกรรมนับเป็นการยืนยันครั้งที่หนึ่ง บล็อกถัดมาแต่ละบล็อกเพิ่มการยืนยันอีกหนึ่งครั้ง ส่วนบน Ethereum การถูกบรรจุลงบล็อกยังพัฒนาต่อไปได้ผ่านสถานะ Latest, Safe และ Finalised

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

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

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

ก่อนธุรกรรมจะไปถึง Mempool มีอะไรเกิดขึ้นบ้าง?

คำตอบสั้น ๆ: กระเป๋าเงินประกอบและเซ็นข้อความตามรูปแบบเฉพาะของเชนนั้น แล้วส่งไปยังโหนดหรือบริการส่วนตัว ผู้รับปลายทางจะตรวจความถูกต้องตามกฎ Consensus และนโยบายในเครื่องก่อนจะเก็บหรือส่งต่อ การเซ็นไม่ได้รับประกันว่าธุรกรรมจะถูกยอมรับ แพร่กระจาย หรือถูกบรรจุลงบล็อก

การประกอบธุรกรรมและการเซ็น

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

การส่งธุรกรรมไม่เท่ากับการกระจายไปทั่วทั้งเครือข่าย

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

กฎความถูกต้องกับนโยบายการส่งต่อ

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

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

Mempool คืออะไร และทำไมจึงไม่มีเพียงหนึ่งเดียว?

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

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

Mempool ของ Bitcoin

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

พูลธุรกรรมของ Ethereum

ไคลเอนต์ชั้น Execution ของ Ethereum มักแยกธุรกรรมที่พร้อมทำงาน (executable หรือ pending) ออกจากธุรกรรมที่เข้าคิวรอหรือมีช่องว่างของลำดับ (queued หรือ gapped) ธุรกรรมที่ใช้ Nonce ลำดับถัดไปที่ใช้ได้จะพร้อมทำงาน ส่วนธุรกรรมที่ใช้ Nonce ถัดไปไกลกว่านั้นอาจต้องรอ เพราะยังขาด Nonce ก่อนหน้าอยู่หนึ่งค่าหรือมากกว่า เอกสารของ Geth อธิบายพูล pending และ queued แยกกัน รวมถึงการแทนที่ธุรกรรมที่มีผู้ส่งเดียวกันและ Nonce เดียวกันด้วยเวอร์ชันที่จ่ายแพงกว่าอย่างเพียงพอ

Mempool สาธารณะกับคำสั่งธุรกรรมแบบส่วนตัว

ผู้ส่งสามารถส่งธุรกรรมตรงไปยังผู้สร้างบล็อกหรือบริการเฉพาะทาง แทนการกระจายไปทั่วเครือข่ายสาธารณะ วิธีนี้อาจลดการเปิดเผยต่อสาธารณะซึ่งนำไปสู่การตัดหน้าคำสั่ง (front-running) หรือช่วยให้จัดการชุดธุรกรรมได้ดีขึ้น แต่ก็เพิ่มข้อสมมติเรื่องความพร้อมใช้งานของปลายทาง การเซ็นเซอร์ และความไว้วางใจ เอกสารของ Ethereum เองระบุชัดว่าผู้ใช้ระดับสูงอาจส่งธุรกรรมไปยังผู้สร้างบล็อกเฉพาะทางแทนการส่งเข้า Mempool สาธารณะ

ประเด็นสำคัญ: ให้พูดว่า "Mempool ของโหนดหนึ่ง" หรือ "การกระจายธุรกรรมสาธารณะ" แทนการพูดว่า "Mempool" ราวกับว่ามันเป็นฐานข้อมูลเดียวที่สอดคล้องกันทั้งโลก

ค่าธรรมเนียมและการคัดเลือกธุรกรรมของ Bitcoin ทำงานอย่างไร?

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

ค่าธรรมเนียมรวมกับอัตราค่าธรรมเนียม

ค่าธรรมเนียมรวมคือผลต่างระหว่างมูลค่ารวมของอินพุตที่ถูกใช้จ่ายกับมูลค่ารวมของเอาต์พุตใหม่ ส่วนอัตราค่าธรรมเนียม (Feerate) คือค่าธรรมเนียมนั้นหารด้วยขนาดเสมือน และมักแสดงเป็น sat/vB ค่าธรรมเนียม 1,000 ซาโตชิอาจแข่งขันได้ในธุรกรรมขนาดเล็ก แต่ไม่พอสำหรับธุรกรรมที่ใหญ่กว่ามาก ไบต์เสมือนรวมส่วนลดน้ำหนักของ SegWit เอาไว้ด้วย จึงไม่ใช่ขนาดไฟล์ดิบ ๆ

ทำไมความสัมพันธ์ระหว่างธุรกรรมจึงเปลี่ยนการประมูล

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

สิ่งที่นักขุดและพูลขุดพยายามทำให้ดีที่สุด

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

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

ประเด็นสำคัญ: Bitcoin คือการประมูลแย่งน้ำหนักบล็อก แต่หน่วยทางเศรษฐศาสตร์อาจเป็นกลุ่มธุรกรรมที่เชื่อมโยงกัน ไม่ใช่ธุรกรรมเดี่ยวรายการเดียว

ค่าธรรมเนียม Gas และลำดับ Nonce ของ Ethereum ทำงานอย่างไร?

คำตอบสั้น ๆ: Ethereum คิดค่าประมวลผลเป็น Gas ธุรกรรมกำหนด Gas Limit ค่าธรรมเนียมสูงสุดต่อหนึ่งหน่วย Gas และ Priority Fee สูงสุด โดย Base Fee ระดับโปรโตคอลจะถูกเผาทิ้ง ส่วน Priority Fee ที่มีผลจริงเป็นรางวัลของผู้เสนอบล็อกหรือผู้รับค่าธรรมเนียมที่ตั้งค่าไว้ ธุรกรรมจากบัญชีเดียวกันจะทำงานเรียงตามลำดับ Nonce

Gas ที่ใช้จริงกับ Gas Limit

Gas ใช้วัดทรัพยากรการประมวลผลที่ธุรกรรม Ethereum ต้องใช้ ส่วน Gas Limit คือปริมาณ Gas สูงสุดที่ผู้ส่งอนุมัติให้ธุรกรรมนั้นใช้ได้ ผู้ส่งจ่ายเฉพาะ Gas ที่ถูกใช้จริงเท่านั้น โดยไม่เกินเพดานที่ตั้งไว้ การโอน ETH ธรรมดามีต้นทุนพื้นฐานที่คาดเดาได้ ส่วนการโต้ตอบกับสัญญาอาจใช้มากกว่านั้นมาก และแปรผันตามสถานะได้

Base Fee, Priority Fee และค่าธรรมเนียมสูงสุด

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

ลำดับ Nonce

ค่า Nonce ของบัญชีที่ควบคุมด้วยคีย์ภายนอกจะเพิ่มขึ้นทุกครั้งที่มีธุรกรรมทำงาน ธุรกรรมที่ใช้ Nonce ลำดับหลังจะทำงานก่อนไม่ได้ จนกว่าทุก Nonce ก่อนหน้าจะถูกใช้ไปแล้ว นี่คือเหตุผลที่ธุรกรรมเดียวซึ่งจ่ายต่ำเกินไปหรือหายไป สามารถขวางคิวธุรกรรมลำดับหลังที่จ่ายแพงกว่าจากบัญชีเดียวกันได้ ไคลเอนต์และบริการกระเป๋าเงินแต่ละรายอาจเรียกสถานะเหล่านี้ว่า pending, queued หรือ gapped

การทำงานที่เกิด revert ก็ยังเสีย Gas

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

ค่าธรรมเนียม Blob แยกต่างหาก

ธุรกรรมที่พก Blob ตาม EIP-4844 ซึ่งใช้กันมากในฝั่ง Rollup จะเข้าร่วมตลาดค่าธรรมเนียม Blob แยกต่างหาก เพิ่มเติมจาก Gas ของการประมวลผลตามปกติ การโอน ETH ธรรมดาไม่ต้องจ่ายค่าธรรมเนียม Blob ความต่างนี้สำคัญเวลาวินิจฉัยต้นทุนของ Rollup แต่ไม่ใช่ส่วนหนึ่งของการคำนวณการโอนจากกระเป๋าเงินตามปกติ

ประเด็นสำคัญ: บน Ethereum ให้แยกการที่ธุรกรรมถูกบรรจุลงบล็อกออกจากความสำเร็จของการทำงาน และแยกเพดาน Gas ออกจากจำนวนที่ถูกเรียกเก็บจริง

ใครเป็นผู้ประกอบและเสนอบล็อกกันแน่?

คำตอบสั้น ๆ: พูลขุด Bitcoin มักเป็นผู้ประกอบเทมเพลตบล็อกที่จะใช้ แล้วนักขุดทำ Proof of Work บนเทมเพลตนั้น ส่วน Ethereum กำหนด Validator หนึ่งรายเป็นผู้เสนอบล็อกในแต่ละสล็อต แต่ผู้เสนอจำนวนมากยกงานประกอบเพย์โหลดชั้น Execution ให้ผู้สร้างบล็อกเฉพาะทางผ่านระบบแยกบทบาทผู้เสนอกับผู้สร้างที่อยู่นอกโปรโตคอล ทั้งนี้โหนดเต็มรูปแบบทุกตัวยังตรวจสอบความถูกต้องด้วยตัวเองอยู่ดี

Bitcoin: พูลขุด การประกอบเทมเพลต และ Proof of Work

พูลขุดประสานกำลังขุดจากนักขุดที่เข้าร่วม และมักจ่ายงานให้ตามเทมเพลตบล็อกของตัวเอง พูลหรือระบบของพูลเป็นผู้เลือกธุรกรรมและประกอบธุรกรรม Coinbase ส่วนนักขุดค้นหาเฮดเดอร์ที่ผ่าน Proof of Work นักขุดหรือพูลที่หาบล็อกที่ถูกต้องได้จะกระจายบล็อกนั้นออกไป โหนด Bitcoin อิสระจะตรวจทั้งบล็อกและปฏิเสธมันหากมีกฎ Consensus ข้อใดถูกละเมิด

Ethereum: ผู้เสนอบล็อกกับผู้สร้างบล็อกอาจเป็นคนละราย

ทุกสล็อตความยาว 12 วินาทีจะมี Validator หนึ่งรายถูกเลือกเป็นผู้เสนอบล็อก ผู้เสนอสามารถประกอบเพย์โหลดชั้น Execution เองจากธุรกรรมที่ตัวเองรู้ หรือใช้ตลาดผู้สร้างบล็อกก็ได้ การแยกบทบาทผู้เสนอกับผู้สร้างนอกโปรโตคอล ซึ่งมักทำผ่าน Builder API และระบบนิเวศ MEV-Boost เปิดให้ผู้สร้างบล็อกเฉพาะทางประมูลสิทธิ์ในการจัดหาเพย์โหลดชั้น Execution ผู้เสนอเซ็นบล็อกที่เลือกไว้ แล้วโหนดอื่นรันซ้ำและตรวจสอบมัน แผนพัฒนาของ Ethereum พูดถึงการนำการแยกบทบาทนี้เข้าไปอยู่ในโปรโตคอลโดยตรง แต่ข้อเสนอในแผนพัฒนาไม่ควรถูกอธิบายว่าใช้งานอยู่แล้ว จนกว่าจะถูกนำไปใช้จริง

ทำไม MEV จึงส่งผลต่อการจัดลำดับ

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

ข้อแลกเปลี่ยนของคำสั่งธุรกรรมแบบส่วนตัว

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

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

ทำไมธุรกรรมจึงค้าง หายไป หรือแสดงสถานะขัดกัน?

คำตอบสั้น ๆ: สาเหตุที่พบบ่อยคือความสำคัญเชิงเศรษฐศาสตร์ต่ำ ช่องว่างของ Nonce หรือของธุรกรรมที่เกี่ยวเนื่องกัน ความต่างของนโยบายในเครื่อง เงินไม่พอ ธุรกรรมแทนที่ที่ขัดแย้งกัน ปลายทางล่ม การถูกคัดออกจาก Mempool หรือการจัดเรียงเชนใหม่ ให้วินิจฉัยสถานะก่อนลงมือแก้

ถูกทิ้งไม่ได้แปลว่าทุกที่ลืมมันไปแล้ว

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

ค่าธรรมเนียมต่ำไม่ใช่สาเหตุเดียว

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

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

จะเร่งหรือแทนที่ธุรกรรม Bitcoin ที่รอดำเนินการได้อย่างไร?

คำตอบสั้น ๆ: เครื่องมือมาตรฐานมีสองอย่าง คือ Replace-by-Fee ซึ่งใช้ธุรกรรมที่ขัดแย้งกันแต่จ่ายมากกว่า และ Child-Pays-For-Parent ซึ่งใช้การใช้จ่ายเอาต์พุตที่ยังไม่ได้รับการยืนยันเพื่อเพิ่มมูลค่าเชิงเศรษฐศาสตร์ของการขุดแพ็กเกจที่เชื่อมโยงกันนั้น ความเป็นไปได้ขึ้นกับการรองรับของกระเป๋าเงิน โครงสร้างธุรกรรม และนโยบายของโหนดในขณะนั้น

Replace-by-Fee (RBF)

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

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

Child-Pays-For-Parent (CPFP)

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

บริการเร่งธุรกรรมจากภายนอก

บริการขุดบางรายเสนอบริการเร่งธุรกรรม บางครั้งฟรีและบางครั้งเสียเงิน บริการเหล่านี้ไม่ใช่ฟีเจอร์ของโปรโตคอล และรับประกันการบรรจุธุรกรรมโดยนักขุดที่ตัวเองไม่ได้ควบคุมไม่ได้ อย่าให้ Seed Phrase หรือ Private Key เด็ดขาด และให้ถือว่า "ทีมสนับสนุนบริการเร่งธุรกรรม" ที่ติดต่อมาเองเป็นกลโกง บริการที่ถูกต้องต้องการอย่างมากก็แค่ข้อมูลธุรกรรมสาธารณะ และถ้าเป็นบริการเสียเงินก็ใช้การชำระเงินตามปกติ

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

จะเร่งหรือยกเลิกธุรกรรม Ethereum ที่รอดำเนินการได้อย่างไร?

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

การแทนที่เพื่อเร่งธุรกรรม

การเร่งธุรกรรมยังคงการกระทำเดิมไว้ แต่เพิ่มค่า maxFeePerGas และเพิ่ม maxPriorityFeePerGas ในกรณีที่เหมาะสม ธุรกรรมที่มาแทนต้องผ่านกฎการขึ้นราคาของกระเป๋าเงิน ไคลเอนต์ชั้น Execution หรือผู้ให้บริการ และเพราะ Base Fee ขยับได้ระหว่างที่ธุรกรรมยังรออยู่ การเพิ่มแค่ทิปอาจไม่ช่วย หากค่าธรรมเนียมสูงสุดไม่ครอบคลุม Base Fee บวกทิปที่มีผลจริงอีกต่อไป

การพยายามยกเลิก

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

อย่าข้าม Nonce ที่ติดอยู่

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

ข้อควรระวังเรื่องสัญญาและการอนุมัติ

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

ประเด็นสำคัญ: คำว่า "ยกเลิก" บน Ethereum หมายถึง "ชนะการแข่งขันด้วย Nonce เดียวกันโดยใช้ธุรกรรมที่ไม่ก่อผลอะไร" มันไม่ใช่ข้อความสั่งยกเลิกที่ส่งไปถึง Validator

ธุรกรรมที่ได้รับการยืนยันแล้วย้อนกลับได้หรือไม่?

คำตอบสั้น ๆ: ธุรกรรมที่เพิ่งถูกบรรจุลงบล็อกอาจหลุดออกจากเชนที่ได้รับการยอมรับได้ระหว่างการจัดเรียงเชนใหม่ บน Bitcoin โอกาสย้อนกลับโดยทั่วไปลดลงเมื่อมี Proof of Work สะสมมากขึ้น ส่วนบน Ethereum ไคลเอนต์แสดงมุมมอง Latest, Safe และ Finalised โดยการย้อนสิ่งที่ Finalised แล้วต้องอาศัยความล้มเหลวของ Consensus อย่างรุนแรง ซึ่ง ETH ที่สเตกไว้ทั้งหมดอย่างน้อยหนึ่งในสามจะถูกพิสูจน์ได้ว่าเข้าข่าย Slashing และถูกเผาไปจาก Validator ที่ต้องรับผิดชอบ

การจัดเรียงเชนใหม่คืออะไร

โหนดอาจได้รับบล็อกที่ถูกต้องซึ่งแข่งกันเองใกล้ปลายเชนในช่วงสั้น ๆ กฎ Fork Choice เป็นตัวกำหนดว่ากิ่งไหนจะกลายเป็นเชนที่ได้รับการยอมรับ เมื่อบล็อกที่เคยถูกยอมรับแพ้ มันจะถูกตัดออกและกิ่งที่ชนะจะเข้ามาแทน ธุรกรรมจากบล็อกที่ถูกตัดออกจะถูกพิจารณาใหม่ บางรายการกลับเข้า Mempool บางรายการได้รับการยืนยันในกิ่งใหม่ และบางรายการใช้ไม่ได้อีกเพราะการใช้จ่ายที่ขัดแย้งกันหรือค่า Nonce ของบัญชีชนะไปก่อนแล้ว

Bitcoin: Finality เชิงความน่าจะเป็น

โหนด Bitcoin เลือกเชนที่ถูกต้องซึ่งมี Proof of Work สะสมมากที่สุด ความมั่นใจในธุรกรรมเพิ่มขึ้นเมื่อมีบล็อกที่ถูกต้องมาเพิ่มงานสะสมไว้เหนือมัน แต่โปรโตคอลไม่ได้กำหนดว่าความลึกระดับใดคือจุดสิ้นสุดในเชิงคณิตศาสตร์ การยืนยัน 6 ครั้งเป็นธรรมเนียมสำหรับรายการมูลค่าสูงที่ใช้กันมายาวนาน มันไม่ใช่สิ่งจำเป็นสำหรับทุกธุรกรรม และไม่ใช่การรับประกันเด็ดขาดต่อผู้โจมตีที่มีกำลังขุดมากพอและต่อเนื่อง

Ethereum: Latest, Safe และ Finalised

Execution API ของ Ethereum แยกสถานะล่าสุดออกจากกัน "Latest" คือปลายเชนที่ไคลเอนต์ยอมรับอยู่ในขณะนั้น และเกิดการจัดเรียงเชนใหม่ได้แม้ระบบทำงานปกติดี "Safe" คือสถานะที่คาดว่าจะไม่ถูกจัดเรียงใหม่ ภายใต้ข้อสมมติว่าเสียงข้างมากซื่อสัตย์และเครือข่ายทำงานประสานกันตามเวลา ส่วน "Finalized" คือจุดตรวจล่าสุดที่ปลอดภัยเชิงเศรษฐศาสตร์การเข้ารหัส การย้อนกลับมันต้องอาศัยการเข้าแทรกแซงด้วยมือของชุมชนหลังเกิดความล้มเหลวของ Consensus และทำให้ ETH ที่สเตกไว้ทั้งหมดอย่างน้อยหนึ่งในสามถูกพิสูจน์ได้ว่าเข้าข่าย Slashing ดังนั้น Validator ที่ต้องรับผิดชอบจะสูญเสียและถูกเผาเงินสเตกไปแล้วอย่างน้อยตามสัดส่วนนั้น โดยบทลงโทษที่แน่นอนจะเพิ่มขึ้นตามจำนวน Validator ที่ถูก Slashing พร้อมกัน

ภาพที่ 3 Bitcoin ให้ความมั่นใจเชิงความน่าจะเป็นที่เพิ่มขึ้นเรื่อย ๆ ส่วน Ethereum ยังแสดงมุมมอง Consensus แบบ Safe และ Finalised อย่างชัดเจนด้วย

Finality ไม่ใช่ความเป็นไปไม่ได้เชิงอภิปรัชญา

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

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

การยืนยันและ Finality ใช้เวลานานแค่ไหน?

คำตอบสั้น ๆ: Bitcoin ตั้งเป้าให้บล็อกห่างกันโดยเฉลี่ยสิบนาที แต่บล็อกจริงมาแบบสุ่ม อาจห่างกันไม่กี่วินาทีหรือนานกว่านั้นมาก ส่วน Ethereum กำหนดตารางเป็นสล็อตละ 12 วินาที แม้บางสล็อตจะพลาดไปได้ ภายใต้การเข้าร่วมตามปกติ Finality ของ Ethereum มักมาถึงหลังผ่านไปราวสองอีพ็อก อีพ็อกละ 32 สล็อต หรือประมาณ 13 นาที

เวลาของ Bitcoin เป็นเชิงความน่าจะเป็น

Bitcoin ปรับความยากในการขุดเพื่อให้บล็อกห่างกันเฉลี่ยราวสิบนาทีในระยะยาว นั่นไม่ใช่ตารางเวลาของบล็อกถัดไป การค้นหา Proof of Work เป็นเรื่องสุ่ม บล็อกที่ถูกต้องถัดไปอาจโผล่มาทันทีหรือมาหลังจากเว้นช่วงยาว การประมาณค่าธรรมเนียมตั้งเป้าที่ความน่าจะเป็นของการได้รับการยืนยันภายในจำนวนบล็อกหนึ่ง โดยอิงจาก Mempool และการขุดที่สังเกตได้ในอดีต มันสัญญาเวลาตามนาฬิกาจริงไม่ได้

เวลาของ Ethereum แบ่งเป็นสล็อต

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

Finality หยุดชะงักได้

ในภาวะปกติ การโหวตจุดตรวจจะทำให้ประวัติถึงสถานะ Finalised หลังผ่านไปราวสองอีพ็อก ถ้าการเข้าร่วมลดลงต่ำกว่าเกณฑ์สองในสามที่กำหนดไว้ เชนจะยังผลิตบล็อกต่อไปได้โดยไม่ถึง Finality กลไก Inactivity Leak ของ Ethereum จะค่อย ๆ ลดน้ำหนักของ Validator ที่ไม่พร้อมใช้งาน เพื่อให้กลุ่มที่ออนไลน์อยู่กลับมาทำให้เชนถึง Finality ได้ในที่สุด แต่ระยะเวลาที่ใช้ไม่ตายตัว

Layer 2 เพิ่มนาฬิกาอีกหลายเรือน

บน Rollup ของ Ethereum ผู้ใช้อาจเห็นการตอบรับทันทีจาก Sequencer การถูกบรรจุลงบล็อกของ L2 การเผยแพร่ข้อมูลไปยัง Ethereum การพิสูจน์หรือช่วงยื่นคัดค้านที่เสร็จสิ้น และการที่เงินถอนได้ เป็นขั้นตอนแยกจากกัน มาตรฐานการชำระเสร็จสิ้นที่ถูกต้องขึ้นกับ Rollup และแอปพลิเคชันนั้น อย่านำตัวเลข Finality ราว 13 นาทีของ Ethereum mainnet ไปใช้กับประสบการณ์ผู้ใช้บน L2 ทุกแห่ง

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

ผู้รับควรรอการยืนยันกี่ครั้ง?

คำตอบสั้น ๆ: ไม่มีตัวเลขสากล ผู้รับควรเลือกเกณฑ์จากมูลค่าธุรกรรม ความย้อนกลับได้ของสิ่งที่ส่งมอบ ความเสี่ยงของคู่สัญญา ความมั่นคงของเชน สภาพเครือข่ายในขณะนั้น และความสามารถของตัวเองในการเฝ้าดูการจัดเรียงเชนใหม่หรือการใช้จ่ายที่ขัดแย้งกัน

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

ทำไมการยืนยัน 6 ครั้งบน Bitcoin จึงกลายเป็นธรรมเนียม

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

ทำไมบริการบน Ethereum จึงเครดิตยอดก่อนถึง Finality

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

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

จะตรวจสอบธุรกรรมอย่างถูกต้องได้อย่างไร?

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

สำหรับ Bitcoin

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

สำหรับ Ethereum

• ยืนยันแฮชธุรกรรม Chain ID และเครือข่ายให้ถูกต้อง
• ตรวจ from, to, value, ข้อมูล input และอีเวนต์การโอนโทเค็น เพราะการโอนโทเค็นอาจไม่ปรากฏในค่า value ของ ETH ที่ระดับบนสุด
• ตรวจสถานะในใบเสร็จธุรกรรม สถานะ 1 ตามปกติหมายถึงการทำงานสำเร็จ ส่วนสถานะ 0 หมายถึงการเรียกที่ถูกบรรจุลงบล็อกเกิด revert
• ตรวจ Gas ที่ใช้จริงและราคา Gas ที่มีผลจริง แทนการเหมาว่าค่าธรรมเนียมสูงสุดที่เซ็นไว้ถูกเรียกเก็บทั้งหมด
• บันทึกแฮชบล็อกไว้ และดูว่าผู้ให้บริการของคุณรายงานสถานะ Latest, Safe หรือ Finalised
• สำหรับการโต้ตอบกับสัญญา ให้ตรวจฟังก์ชันที่ตั้งใจเรียก บันทึกอีเวนต์ และสถานะผลลัพธ์ ไม่ใช่ดูแค่คำว่า "ได้รับการยืนยัน"

ความเป็นส่วนตัวและความเสี่ยงจาก Block Explorer

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

ประเด็นสำคัญ: การตรวจสอบหมายถึงการตรวจวัตถุบนเชนที่เจาะจงและสถานะของมันบนเชนที่ได้รับการยอมรับ ไม่ใช่การเชื่อการแจ้งเตือนของกระเป๋าเงิน ภาพหน้าจอ หรือป้ายกำกับที่คัดลอกมาจาก Block Explorer

เช็กลิสต์การแก้ปัญหา

คำตอบสั้น ๆ: ระบุธุรกรรม เครือข่าย ลำดับธุรกรรมของผู้ส่ง และสถานะปัจจุบันบนเชนที่ได้รับการยอมรับ ก่อนจะลงมือทำอะไร แล้วจึงเลือกวิธีแก้เฉพาะของเชนนั้นที่กระเป๋าเงินรองรับ

• คัดลอกแฮชธุรกรรมจากกระเป๋าเงิน แล้วยืนยันเครือข่ายและ Chain ID
• ตรวจว่าโหนดหรือ Block Explorer ที่เชื่อถือได้มองเห็นธุรกรรมหรือไม่ สำหรับมูลค่าสูงให้ใช้แหล่งข้อมูลอิสระแหล่งที่สองด้วย
• ถ้ายังไม่ได้รับการยืนยัน ให้ตรวจค่าพารามิเตอร์ของค่าธรรมเนียม ธุรกรรมที่เกี่ยวเนื่องกัน และดูว่าธุรกรรมถูกกระจายแบบสาธารณะหรือส่งผ่านเส้นทางส่วนตัว
• บน Bitcoin ให้ตรวจธุรกรรมแม่ที่ยังไม่ได้รับการยืนยัน สภาพ sat/vB ในขณะนั้น และดูว่ากระเป๋าเงินรองรับ RBF หรือ CPFP หรือไม่
• บน Ethereum ให้ระบุค่า Nonce ของบัญชี Nonce ที่รอดำเนินการลำดับแรกสุด ค่าธรรมเนียมสูงสุด Priority Fee และ Base Fee ปัจจุบัน
• มองหาธุรกรรมแทนที่ที่ขัดแย้งกัน คืออินพุตชุดเดียวกันบน Bitcoin หรือผู้ส่งและ Nonce เดียวกันบน Ethereum
• ถ้าธุรกรรมได้รับการยืนยันแล้วหายไป ให้เทียบแฮชบล็อกเดิมของมันกับเชนที่ได้รับการยอมรับ เพื่อดูว่ามีการจัดเรียงเชนใหม่หรือไม่
• ถ้าธุรกรรม Ethereum ได้รับการยืนยันแต่การกระทำล้มเหลว ให้ตรวจสถานะในใบเสร็จธุรกรรม บันทึกอีเวนต์ และข้อมูลของ revert
• ใช้ฟีเจอร์เร่งหรือยกเลิกที่มีอยู่ในกระเป๋าเงิน แทนการเซ็นคำสั่งอะไรก็ตามที่มาจากข้อความของฝ่ายสนับสนุน
• อย่าเปิดเผย Private Key หรือ Recovery Phrase เด็ดขาด การวินิจฉัยธุรกรรมต้องใช้แฮชสาธารณะและข้อมูลในกระเป๋าเงินของคุณ ไม่ใช่ข้อมูลคีย์

ประเด็นสำคัญ: การตรวจสถานะอย่างเป็นระบบเร็วกว่าและปลอดภัยกว่าการส่งธุรกรรมซ้ำไปเรื่อย ๆ การสลับเครือข่าย หรือการทำตามคำแนะนำ "กู้คืนเงิน" ที่ส่งมาหาคุณเอง

คำถามที่พบบ่อย

การยืนยันหนึ่งครั้งในโลกคริปโตคืออะไร?

การยืนยันหนึ่งครั้งตามปกติหมายความว่าธุรกรรมถูกบรรจุอยู่ในบล็อกบนเชนที่ได้รับการยอมรับ บน Bitcoin บล็อกที่บรรจุธุรกรรมคือการยืนยันครั้งที่หนึ่ง ส่วนบน Ethereum การถูกบรรจุลงบล็อกคือสถานะ Latest และแอปพลิเคชันอาจรอสถานะ Safe หรือ Finalised เพิ่มด้วย

ค่าธรรมเนียมที่สูงกว่ารับประกันว่าจะเข้าบล็อกถัดไปหรือไม่?

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

ธุรกรรมเดียวกันสองเวอร์ชันได้รับการยืนยันพร้อมกันได้หรือไม่?

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

ธุรกรรม Bitcoin ที่ได้รับการยืนยันแล้วยกเลิกได้หรือไม่?

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

ธุรกรรม Ethereum ยกเลิกได้หรือไม่?

ทำได้เฉพาะตอนที่มันยังรอดำเนินการ โดยพยายามแทนที่ด้วยธุรกรรมที่ใช้ Nonce เดียวกันและจ่ายมากพอจะชนะการแข่งขัน ถ้าธุรกรรมเดิมได้รับการยืนยันก่อน การยกเลิกก็ล้มเหลว ธุรกรรมที่ได้รับการยืนยันแล้วเรียกคืนด้วยการแทนที่ Nonce ไม่ได้

ทำไมธุรกรรม Ethereum ของฉันยังรอดำเนินการทั้งที่จ่ายทิปสูง?

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

เกิดอะไรขึ้นเมื่อธุรกรรม Bitcoin ถูกทิ้งออกจาก Mempool?

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

ทำไมธุรกรรมที่ได้รับการยืนยันแล้วจึงกลับมารอดำเนินการอีก?

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

การยืนยัน 6 ครั้งเพียงพอเสมอหรือไม่?

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

Finality ของ Ethereum ใช้เวลานานแค่ไหน?

ภายใต้การเข้าร่วมตามปกติคือราวสองอีพ็อก อีพ็อกละ 32 สล็อต หรือประมาณ 13 นาที มันอาจนานกว่านั้นถ้าการเข้าร่วมลดต่ำกว่าเกณฑ์ที่กำหนด การถูกบรรจุลงบล็อกตามปกติเกิดขึ้นก่อนหน้านั้น และไม่ใช่สิ่งเดียวกับ Finality

การยืนยันที่เพิ่มขึ้นต้องจ่ายเพิ่มหรือไม่?

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

สถานะสำเร็จบน Block Explorer พิสูจน์ได้หรือไม่ว่าผู้รับได้โทเค็นที่ตั้งใจส่ง?

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

แหล่งข้อมูลและการอ่านเพิ่มเติม

แหล่งอ้างอิงหลักของบทความนี้ เป็นข้อมูลล่าสุด ณ เดือนกรกฎาคม 2026

• Bitcoin Developer Guide หัวข้อ Transactions https://developer.bitcoin.org/devguide/transactions.html
• Bitcoin Developer Guide หัวข้อ Block Chain https://developer.bitcoin.org/devguide/block_chain.html
• บันทึกการเปลี่ยนแปลงของ Bitcoin Core 31.0 https://bitcoincore.org/en/releases/31.0/
• Bitcoin Core 31.0 คำสั่ง RPC bumpfee https://bitcoincore.org/en/doc/31.0.0/rpc/wallet/bumpfee/
• นโยบายการแทนที่ธุรกรรมใน Mempool ของ Bitcoin Core https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
• Ethereum.org หัวข้อ Transactions https://ethereum.org/developers/docs/transactions/
• Ethereum.org หัวข้อ Gas and fees https://ethereum.org/developers/docs/gas/
• Ethereum.org หัวข้อ Proof of stake https://ethereum.org/developers/docs/consensus-mechanisms/pos/
• Ethereum Execution APIs หัวข้อ block tags https://ethereum.github.io/execution-apis/
• Ethereum.org หัวข้อ Maximal extractable value https://ethereum.org/developers/docs/mev/
• EIP-1559 https://eips.ethereum.org/EIPS/eip-1559
• เอกสารของ Geth หัวข้อ command-line options https://geth.ethereum.org/docs/fundamentals/command-line-options
• Ethereum.org หัวข้อ Proof-of-stake attack and defence https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/
• Google Search Central หัวข้อ Creating helpful, reliable, people-first content https://developers.google.com/search/docs/fundamentals/creating-helpful-content

หมายเหตุฝ่ายผลิต: แผนผังลิงก์ภายใน

ลบส่วนนี้ออกก่อนเผยแพร่