การตรวจจับธุรกรรม การยืนยันบนเชน การเชื่อมโยงคำสั่งซื้อ และการให้บริการเป็นขั้นตอนที่แยกจากกัน ตรวจสอบเชน สินทรัพย์ ผู้รับ และจำนวนเงินให้ถูกต้อง ใช้นโยบายการยอมรับที่เป็นเอกสาร และทำให้การกระทบยอดเป็นแบบ idempotent การอ้างอิงธุรกรรม ภาพหน้าจอ หรือปุ่มบนเบราว์เซอร์เพียงอย่างเดียวไม่สามารถยืนยันได้ว่าคำสั่งซื้อเฉพาะรายการได้รับการชำระเงินแล้ว
แยกเหตุการณ์บนเชนออกจากเหตุการณ์คำสั่งซื้อ
กระเป๋าเงินที่รายงานว่าส่งโอนแล้วเป็นหลักฐานเกี่ยวกับการกระทำของตัวมันเอง ไม่ใช่การตัดสินใจชำระเงินที่สมบูรณ์ แบ็กเอนด์ฝ่ายรับต้องสังเกตเครือข่ายที่ตั้งใจไว้ ตรวจสอบการโอนจริง และเชื่อมโยงกับคำสั่งซื้อ จากนั้นคำสั่งซื้อจึงจะสามารถใช้นโยบายการยอมรับได้ การส่งมอบโครงสร้างพื้นฐานเป็นอีกขั้นตอนการดำเนินงานหลังจากการยอมรับการชำระเงิน
ทำให้การเปลี่ยนสถานะเหล่านี้ชัดเจนทั้งในโค้ดและในภาษาที่สื่อสารกับลูกค้า หน้าจอสามารถแสดงสถานะรอ ตรวจพบ หรือกำลังยืนยัน โดยไม่เรียกว่าคำสั่งซื้อชำระแล้ว อย่าให้เบราว์เซอร์เป็นผู้กำหนดจำนวนเงินที่ยอมรับหรือเขียนทับสถานะที่เป็นทางการ จัดเก็บใบเสนอราคาที่สร้างโดยเซิร์ฟเวอร์และคำแนะนำของใบเสนอราคานั้น เพื่อให้การกระทบยอดในภายหลังประเมินเทียบกับคำสั่งซื้อเดิมได้ ไม่ใช่เทียบกับตะกร้าที่เปลี่ยนแปลงได้
ใช้กฎความเชื่อมั่นเฉพาะเชน
เครือข่ายต่างๆ อธิบายความเชื่อมั่นของธุรกรรมแตกต่างกัน คู่มือสำหรับนักพัฒนาของ Bitcoin อธิบายว่าโหนดเลือกเชนที่มีหลักฐาน proof of work สะสมมากที่สุดอย่างไร และบล็อกที่แข่งขันกันเกิดขึ้นได้อย่างไร ดังนั้นธุรกรรมที่เพิ่งพบเห็นจึงต้องมีนโยบายเรื่องความลึกของการยืนยันและความเป็นไปได้ที่เชนจะเปลี่ยนแปลง ไม่มีจำนวนการยืนยันเพียงค่าเดียวที่เหมาะสมกับทุกสินทรัพย์และความเสี่ยงทางการค้า
เอกสาร proof-of-stake ของ Ethereum อธิบายความสมบูรณ์ขั้นสุดท้ายของ checkpoint ขณะที่ Solana เอกสารสถานะ commitment แบบ processed, confirmed และ finalized อย่าแปลคำเหล่านี้อย่างมักง่ายเป็นจำนวนบล็อกสากลค่าเดียว บันทึกกฎเฉพาะเครือข่าย แหล่งข้อมูล และพฤติกรรมในช่วงที่ยังไม่แน่นอน ผู้ดำเนินการควรกำหนดเกณฑ์การยอมรับตามความเสี่ยงของการชำระเงินและการส่งมอบ ไม่ใช่คัดลอกตัวเลขจากหน้าชำระเงินที่ไม่เกี่ยวข้อง
ตรวจสอบเพย์โหลดการโอนจริง
ระบุผู้รับ สินทรัพย์ และจำนวนเงินบนเชนที่ถูกต้อง การชำระด้วยโทเคนต้องระบุตัวตนของโทเคนที่ตั้งใจไว้ ไม่ใช่เพียงธุรกรรมที่สำเร็จไปยังที่อยู่หนึ่ง ตรวจสอบความสำเร็จของการดำเนินการและหลักฐานการโอนที่เกี่ยวข้องตามโมเดลของเชนนั้น แยกวิเคราะห์จำนวนเต็มตามความแม่นยำที่เหมาะสมของสินทรัพย์ แทนที่จะเชื่อถือทศนิยมที่จัดรูปแบบแล้วซึ่งเบราว์เซอร์ส่งมา
คำแนะนำการชำระเงินต้องผูกอยู่กับเส้นทางเดิมเสมอ การโอนบนเครือข่ายอื่น โทเคนอื่นที่มีสัญลักษณ์เดียวกัน หรือการอ้างอิงธุรกรรมที่ไม่เกี่ยวข้อง ไม่ควรถือว่าเป็นการชำระตามคำแนะนำนั้น บันทึกการตรวจสอบควรอธิบายว่าตรวจสอบอะไรไปบ้างและเก็บหลักฐานที่จำเป็นสำหรับทบทวนการตัดสินใจ คู่มือนี้กล่าวถึงหลักการทั่วไปของการกระทบยอดการชำระเงิน ไม่ใช่การใช้งานบริการใดบริการหนึ่งโดยเฉพาะ
ทำให้การเชื่อมโยงคำสั่งซื้อไม่กำกวม
ที่อยู่รับแบบคงที่สามารถรับคำสั่งซื้อหลายรายการที่มีจำนวนใกล้เคียงกันได้ การมีอยู่ของการโอนที่ตรงกันไม่ได้พิสูจน์ว่าลูกค้าหรือคำสั่งซื้อรายใดควรได้รับเครดิต กำหนดวิธีการเชื่อมโยงก่อนรับชำระเงินจริง และรวมการจัดการกรณีชนกันไว้ด้วย การอ้างอิงธุรกรรมที่ผู้ใช้ให้มายังต้องมีการตรวจสอบว่าการโอนเดียวกันนั้นไม่เคยถูกกำหนดให้ที่อื่นมาก่อน
ลองจินตนาการว่ามีใบแจ้งหนี้สองใบสำหรับจำนวนเงินเดียวกันบนเส้นทางเดียวกันในช่วงเวลาที่ทับซ้อนกัน ตัวเฝ้าดูเห็นการโอนหนึ่งรายการ การทำเครื่องหมายว่าทั้งสองใบชำระแล้วโดยอัตโนมัติเป็นสิ่งที่ผิด การเลือกใบใดใบหนึ่งโดยไม่มีหลักฐานเพียงพอก็ไม่ปลอดภัยเช่นกัน ปล่อยให้การโอนนั้นไม่ถูกจัดสรรหรืออยู่ในสถานะรอตรวจสอบ จนกว่านโยบายของผู้ดำเนินการจะสร้างความเชื่อมโยงที่ถูกต้องได้ การจับคู่ที่คลุมเครือเป็นสถานะที่ต้องจัดการ ไม่ใช่เหตุผลให้สร้างความแน่นอนขึ้นมาเอง
กำหนดสถานะที่ทนต่อหลักฐานที่มาสายและเปลี่ยนแปลง
กระบวนการชำระเงินได้ประโยชน์จากชุดสถานะที่ชัดเจนจำนวนไม่มาก โดยแยกหลักฐานบนเชนออกจากการตัดสินใจยอมรับคำสั่งซื้อ ตารางตัวอย่างนี้ใช้อธิบายขั้นตอนที่เป็นไปได้ ไม่ได้อธิบายชื่อสถานะของบริการใดบริการหนึ่งโดยเฉพาะ การเปลี่ยนสถานะแต่ละครั้งควรมีเหตุผลที่ตรวจสอบได้ และการยอมรับการชำระเงินควรแยกจาการส่งมอบโครงสร้างพื้นฐาน
รวมกรณีการโอนล่าช้า การโอนบางส่วน การโอนเกินจำนวน การหมดอายุของใบเสนอราคา และข้อมูลเชนที่ใช้ชั่วคราวไม่ได้ การหมดอายุไม่ได้ทำให้การโอนจริงหายไป การชำระล่าช้าอาจต้องทบทวนแทนการยอมรับหรือปฏิเสธโดยอัตโนมัติ หากเหตุการณ์บนเชนที่เคยสังเกตไว้เปลี่ยนแปลง ให้ประเมินสถานะใหม่ตามนโยบายที่เป็นเอกสาร แทนที่จะถือว่าการแจ้งเตือนทุกครั้งจากตัวเฝ้าดูเป็นความจริงที่ย้อนกลับไม่ได้
| สถานะตัวอย่าง | ความหมาย | การตัดสินใจถัดไป |
|---|---|---|
| รอดำเนินการ | ยังไม่มีการโอนที่ผ่านการตรวจสอบและเข้าเกณฑ์ | สังเกตใบแจ้งหนี้ที่ยังใช้ได้ต่อไป |
| ตรวจพบ | พบการโอนที่เกี่ยวข้อง | ตรวจสอบความเชื่อมั่นของเชนและการเชื่อมโยง |
| กำลังยืนยัน | ยังไม่เป็นไปตามกฎการยอมรับ | สังเกตต่อไปจนกว่านโยบายจะอนุญาตให้ตัดสินใจ |
| ทบทวน | หลักฐานล่าช้า บางส่วน หรือคลุมเครือ | แก้ไขตามนโยบายของผู้ดำเนินการ |
| ยอมรับแล้ว | การชำระเงินที่ตรวจสอบและกระทบยอดแล้ว | ดำเนินการต่อยังขั้นตอนการส่งมอบที่แยกจากกัน |
ทำให้การลองใหม่ปลอดภัยและสังเกตได้
ตัวเฝ้าดูและงานกระทบยอดจะลองใหม่หลังการเชื่อมต่อถูกขัดจังหวะหรือกระบวนการรีสตาร์ท ใช้ตัวระบุการโอนที่มั่นคง เช่น เชนและตัวระบุธุรกรรมหรือการโอนที่เหมาะสม เพื่อป้องกันการให้เครดิตซ้ำ จัดเก็บความคืบหน้าและการตัดสินใจไว้อย่างถาวร เพื่อให้เหตุการณ์เดียวกันประมวลผลซ้ำได้โดยไม่ต้องจัดเตรียมบริการที่สองหรือเปลี่ยนใบเสนอราคาที่ได้รับการยอมรับแล้ว
แยกแยะผลลัพธ์ที่ไม่ทราบออกจากการดำเนินการที่ล้มเหลว หากคำขอปลายทางหมดเวลา ให้ตรวจสอบผลลัพธ์ที่เป็นทางการก่อนส่งซ้ำ เก็บบันทึกที่คงทนของการกระทำที่ยอมรับแล้วและที่ยังไม่แน่นอน จำกัดการเข้าถึงโทเคนคำสั่งซื้อและหลักฐานภายใน ขณะเดียวกันก็เก็บข้อมูลให้เพียงพอต่อการสอบสวนการชำระเงินที่มีข้อโต้แย้ง ความน่าเชื่อถือในที่นี้คือการตัดสินใจที่ทำซ้ำได้ ไม่ใช่แอนิเมชันที่ลื่นไหลในหน้าชำระเงิน
รู้ว่าคำสั่งซื้อที่รอดำเนินการยังต้องการอะไร
คำสั่งซื้ออาจยังคงรอดำเนินการเพราะยังไม่พบการโอน ยังไม่ถึงระดับความเชื่อมั่นของเชนที่กำหนด หรือการเชื่อมโยงกับใบแจ้งหนี้ต้องทบทวน เก็บใบแจ้งหนี้และการอ้างอิงธุรกรรมสาธารณะไว้ ตรวจสอบกฎการยอมรับที่ระบุไว้ และใช้กระบวนการช่วยเหลือที่กำหนดไว้สำหรับคำสั่งซื้อนั้น การอัปเดตสถานะที่ล่าช้าไม่ใช่เหตุผลในตัวเองที่จะส่งการชำระเงินอีกครั้ง
ปฏิบัติตามคำแนะนำและสถานะที่ตรวจสอบแล้วสำหรับคำสั่งซื้อจริง การยืนยันการชำระเงินควรระบุการยอมรับการโอนที่กระทบยอดแล้ว ขณะที่การส่งมอบบริการมีสถานะแยกต่างหาก อย่าใส่โทเคนการเข้าถึงส่วนตัวและความลับของกระเป๋าเงินในคำขอความช่วยเหลือ
รายการตรวจสอบปฏิบัติของคุณ
- จัดเก็บใบเสนอราคาที่สร้างโดยเซิร์ฟเวอร์แบบแก้ไขไม่ได้
- ตรวจสอบเชน ผู้รับ สินทรัพย์ และจำนวนเต็ม
- จัดทำเอกสารกฎการยอมรับเฉพาะเชน
- จัดการกรณีที่อยู่คงที่ชนกันโดยไม่เดา
- ป้องกันการให้เครดิตซ้ำและการส่งคำขอซ้ำที่ไม่ปลอดภัย
- ทดสอบกรณีล่าช้า บางส่วน ผิดเส้นทาง และหลักฐานเปลี่ยนแปลง
รายละเอียดที่สำคัญ
แฮชธุรกรรมเพียงพอที่จะยืนยันการชำระเงินหรือไม่+
ไม่เพียงพอ ตรวจสอบการโอนบนเชนที่ตั้งใจไว้ เพย์โหลดและความเชื่อมั่นของมัน จากนั้นยืนยันว่าการโอนนั้นเป็นของคำสั่งซื้อและยังไม่เคยถูกให้เครดิต
ทุกเครือข่ายใช้เกณฑ์การยืนยันเดียวกันได้หรือไม่+
ไม่ได้ เครือข่ายต่างๆ มีโมเดลความเชื่อมั่นและความสมบูรณ์ขั้นสุดท้ายที่แตกต่างกัน ผู้ดำเนินการต้องกำหนดและทดสอบนโยบายการยอมรับที่เหมาะสมกับแต่ละเส้นทาง
การชำระเงินที่ยืนยันแล้วหมายความว่าเซิร์ฟเวอร์ถูกจัดเตรียมแล้วหรือไม่+
ไม่ใช่ การยอมรับการชำระเงินและการส่งมอบเป็นเหตุการณ์ในเวิร์กโฟลว์ที่แยกจากกัน สื่อสารสถานะการจัดเตรียมจากกระบวนการที่เป็นทางการของมันเอง
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- คู่มือสำหรับนักพัฒนาของ Bitcoin: พฤติกรรมของบล็อกเชน developer.bitcoin.org
- Ethereum: Proof of stake และความสมบูรณ์ขั้นสุดท้าย ethereum.org
- Solana: สถานะ commitment ผ่าน RPC solana.com
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก