อ่าน 8 สถานะที่ธุรกรรม Ethereum อาจพบได้ในบทความเดียว
หมายเหตุบรรณาธิการ: บทความนี้มาจากค่ายบล็อคเชน (ID: blockchain_camp)หมายเหตุบรรณาธิการ: บทความนี้มาจาก
ค่ายบล็อคเชน (ID: blockchain_camp)
ค่ายบล็อคเชน (ID: blockchain_camp)
, ผู้แต่ง: dfuse, ทำซ้ำโดย Odaily โดยได้รับอนุญาต
เมื่อใดก็ตามที่ธุรกรรมถูกส่งไปยังเครือข่าย Ethereum ธุรกรรมนั้นจะต้องผ่านสถานะที่ค่อนข้างซับซ้อน และไม่ใช่ทุกสถานะที่ส่งต่อไปข้างหน้า - ธุรกรรมอาจถูกย้อนกลับไปสู่สถานะก่อนหน้า ธุรกรรมนั้นอาจถูกแทนที่ด้วยธุรกรรมอื่นแทน และเป็นไปได้ ส้อมที่สมบูรณ์ (วงจรชีวิตของธุรกรรมมีรายละเอียดอธิบายไว้ด้านล่าง)
การติดตามความคืบหน้าของการทำธุรกรรมใน dapp และการมอบประสบการณ์ที่ดีให้กับผู้ใช้เป็นสิ่งที่ท้าทาย วันนี้ dapps ที่ใช้ Ethereum จำนวนมากสามารถให้ประสบการณ์ผู้ใช้ที่น่าดึงดูดแต่ยังคงค่อนข้างคงที่: แอปพลิเคชันสามารถแสดงสถานะการทำธุรกรรม ณ เวลาใดเวลาหนึ่ง แต่ต้องรีเฟรช (คลิกเพื่อรีเฟรชหรือ UI ของ dapp จะรีเฟรชหน้าเป็นระยะ) เพื่อ รับการปรับปรุงข้อมูล มีอินเทอร์เฟซแบบไดนามิกที่ค่อนข้างมากกว่าในตลาด แต่ความละเอียดของข้อมูลที่มีให้นั้นยังไม่ดีพอ หรือ/ในขณะที่ทราฟฟิกเครือข่ายมีค่าใช้จ่ายในการโหลดที่สูง โหนดบล็อกเชนที่อยู่ภายใต้นั้นมีภาระงานสูง
ต่อไปเราจะพูดถึงสาเหตุที่เป็นกรณีนี้ และการอัพเดทสถานะธุรกรรมแบบละเอียดในลักษณะเครือข่ายและเซิร์ฟเวอร์อย่างมีประสิทธิภาพสามารถมอบประสบการณ์ผู้ใช้ที่ราบรื่นใน dapps ที่ตรงตามมาตรฐานสมัยใหม่ได้อย่างไร
ชื่อเรื่องรอง
อินเทอร์เฟซ Dapp วันนี้
ผู้ใช้มักต้องอัปเดตข้อมูลระหว่างการทำธุรกรรม (เช่น ทราบเมื่อการถ่ายโอนเสร็จสิ้น) ดังนั้น dapp จะวางปุ่ม "รีเฟรช" บนอินเทอร์เฟซ (หรือรีเฟรชหน้าโดยอัตโนมัติสำหรับผู้ใช้เป็นระยะๆ) หรือผู้ใช้ ต้องคลิกที่ปุ่มรีเฟรชของเบราว์เซอร์โดยตรงเพื่อรับการอัปเดต
แอพบางตัวที่มีประสบการณ์ผู้ใช้ที่เป็นผู้ใหญ่มากขึ้นจะแสดงการอัปเดตธุรกรรมแบบไดนามิกแก่ผู้ใช้ พวกเขาสำรวจคำขอ AJAX ในพื้นหลัง ตรวจสอบโหนด Ethereum อีกครั้งเพื่อรับการอัปเดต และโพสต์การอัปเดตไปยังส่วนหน้า การทำเช่นนี้มีความซับซ้อนเนื่องจาก dapp ต้องทำการเรียก API จำนวนมากเพื่อสืบค้นแหล่งข้อมูลต่างๆ จำนวนมาก (รวมถึงบล็อก เมมพูล และเงื่อนไขของเครือข่าย) เพื่อติดตามวงจรชีวิตของธุรกรรมตั้งแต่ต้นจนจบ
วิธีนี้มีข้อเสีย: ธุรกรรมได้รับการอัปเดตไม่บ่อยนักและความละเอียดของข้อมูลมีมาก ทำให้ผู้ใช้ต้องการคลิก "รีเฟรช" ซ้ำๆ เพื่อรับการอัปเดตเร็วขึ้น หรือ dapp ต้องสำรวจบล็อกเชนบ่อยครั้ง ส่งผลให้เกิดทราฟฟิกเครือข่ายจำนวนมาก ซึ่งทำให้โหลดสูงบนโหนดบล็อกเชนพื้นฐาน
ชื่อเรื่องรอง
เหตุใดจึงไม่ใช้อินเทอร์เฟซตามเหตุการณ์บนเครือข่าย
สำหรับนักพัฒนา dapp การทำ Static Page หรือ Poll เป็นเพียงสองตัวเลือกที่มีอยู่ ซึ่งสะท้อนถึงธรรมชาติของ API ที่โหนด Ethereum ให้มา หากมีอินเทอร์เฟซตามเหตุการณ์บนเครือข่าย ซึ่งสามารถรับการอัปเดตสถานะธุรกรรมที่ส่งไปยังเชนและให้ข้อเสนอแนะตามเวลาจริงแก่ผู้ใช้ dapps สามารถมอบประสบการณ์ผู้ใช้ที่ดีกว่า ในขณะที่โหนด Ethereum มาตรฐานไม่ได้ให้ข้อมูลแบบเรียลไทม์ที่สมบูรณ์ ข้อมูลการทำธุรกรรม
โหนด Ethereum ให้การอ่านสตรีมของกิจกรรมบนเครือข่าย แต่ฟังก์ชันการทำงานมีจำกัดและใช้ได้เฉพาะผ่านฟังก์ชัน PUB/SUB โดยใช้อินเทอร์เฟซ JSON-RPC ของ Ethereum (ไม่สามารถใช้งานได้เมื่อใช้ GraphQL) อินเทอร์เฟซ PUB/SUB ช่วยให้ dapps ได้รับการแจ้งเตือนสำหรับเหตุการณ์บางประเภท:
newHeads - ทุกครั้งที่เพิ่มส่วนหัวของบล็อกใหม่เข้ากับเชน
newPendingTransactions - แฮชของธุรกรรมทั้งหมดที่เข้าสู่สถานะรอดำเนินการและลงนามโดยคีย์ที่มีอยู่ในโหนด (และสิ่งนี้เกิดขึ้นได้ยากในโหนดสาธารณะ)
การซิงค์ - ระบุเมื่อโหนดเริ่มหรือหยุดการซิงค์
ชื่อเรื่องรอง
วงจรการทำธุรกรรม Ethereum
ธุรกรรม Ethereum มีวงจรชีวิตที่ซับซ้อน ธุรกรรมแต่ละรายการจะผ่านหลายสถานะ (สถานะ) ผ่านการเปลี่ยนแปลงสถานะต่างๆ ตลอดกระบวนการ และอาจเดินหน้าหรือย้อนกลับ
ชื่อเรื่องรอง
สถานะการซื้อขาย
ตั้งแต่การส่งธุรกรรม Ethereum ไปจนถึงการเข้าสู่บล็อก (ด้วยความน่าจะเป็นที่จะสำเร็จ) จะต้องผ่านสถานะต่างๆ ดังต่อไปนี้:
UNKNOWN (ไม่รู้จัก): ธุรกรรมที่ไม่ได้ตรวจพบหรือประมวลผลโดยเครือข่ายถูกกำหนดให้อยู่ในสถานะ UNKOWN
รอดำเนินการ: การทำธุรกรรมกำลังรอการหยิบและดำเนินการโดยนักขุดในสิ่งที่เราเรียกว่า mempool นักขุดมักจะเลือกธุรกรรมที่ราคาน้ำมันสูงขึ้นก่อน ดังนั้นธุรกรรมที่ราคาน้ำมันต่ำกว่าอาจอยู่ในสถานะรอดำเนินการเป็นเวลานาน ธุรกรรมที่มีราคาน้ำมันต่ำสุดอาจไม่สามารถเลือกได้ ซึ่งจะปล่อยให้อยู่ในสถานะรอดำเนินการอย่างไม่มีกำหนด
IN_BLOCK: เมื่อนักขุดเลือกธุรกรรมสำเร็จและประมวลผลเป็นบล็อก ธุรกรรมจะเข้าสู่สถานะ IN_BLOCK หากธุรกรรมเข้าสู่สถานะ IN_BLOCK แต่การบล็อกนั้นอยู่ในสถานะ Forks ธุรกรรมอาจกลับสู่สถานะรอดำเนินการ
ธุรกรรมอื่นจากผู้ส่งเดียวกันกับ nonce เดียวกันเข้าสู่สถานะ IN_BLOCK หรือ
ธุรกรรมอื่นจากผู้ส่งรายเดียวกันที่มี nonce เดียวกัน แต่ราคาก๊าซสูงขึ้น 12% เข้าสู่สถานะรอดำเนินการ
แผนภาพด้านล่างแสดงสถานะเหล่านี้และการเปลี่ยนระหว่างสถานะเหล่านี้
ชื่อเรื่องรอง
การเปลี่ยนสถานะ
ดังที่แสดงในรูปด้านบน การเปลี่ยนระหว่างสถานะจะถูกกำหนดโดยชื่อ
POOLED (ลงในกลุ่ม): ธุรกรรมในสถานะ UNKOWN (ไม่ทราบ) เข้าสู่กลุ่มธุรกรรมที่รอให้นักขุดเลือก เรียกว่า POOLED และเข้าสู่สถานะ PENDING (รอดำเนินการ) ธุรกรรมในสถานะ REPLACED หากเงื่อนไขการเปลี่ยนไม่เป็นจริงอีกต่อไป (ตัวอย่าง: ในบางกรณี ธุรกรรมที่มีราคาก๊าซต่ำใน IN_BLOCK จะถูก fork และแทนที่ด้วย nonce เดียวกัน และส่ง หากธุรกรรมของอดีตคือ ยังคงลอยอยู่บนเครือข่าย) นอกจากนี้ยังสามารถเปลี่ยนเป็นสถานะ POOLED ได้อีก
MINED (ขุด): ธุรกรรมที่ขุดได้คือธุรกรรมที่ดำเนินการโดยนักขุดซึ่งสร้างบล็อก เมื่อขุดได้ ธุรกรรมจะถือว่าอยู่ในสถานะ IN_BLOCK เนื่องจากลักษณะเครือข่าย Ethereum แบบเพียร์ทูเพียร์ จากมุมมองของโหนดที่กำหนด ธุรกรรมสามารถเข้าสู่สถานะ IN_BLOCK ได้โดยตรงจากสถานะ UNKNOWN (ไม่รู้จัก) โดยไม่ต้องผ่านสถานะ PENDING (รอดำเนินการ) อย่างชัดเจน ด้วยเหตุผลเดียวกัน ธุรกรรมยังสามารถเปลี่ยนโดยตรงจากสถานะ REPLACED เป็นสถานะ IN_BLOCK โดยไม่ผ่านสถานะ PENDING ซึ่งได้รับการตรวจสอบจากมุมมองของโหนดที่กำหนด
FORKED (forked): เมื่อธุรกรรมที่ขุดได้อยู่ในบล็อกที่ถูกเพิกถอนโดยเครือข่าย ธุรกรรมนั้นจะถูก forked ธุรกรรมทั้งหมดในบล็อกนั้นจะถูกแยกจากกัน จากสถานะ IN_BLOCK (บล็อกขาเข้า) กลับสู่สถานะ PENDING (รอดำเนินการ)
ยืนยัน: การทำธุรกรรมในสถานะ IN_BLOCK จะได้รับการยืนยันทุกครั้งที่มีการขุดบล็อกย่อยที่ตามมา
ดังที่ได้กล่าวไว้ข้างต้น วงจรชีวิตของการทำธุรกรรมบน Ethereum นั้นซับซ้อนมาก ซึ่งทำให้ยากสำหรับ dapps ในการติดตามอย่างแม่นยำและให้การอัปเดตที่ราบรื่นและราบรื่นแก่ผู้ใช้
ชื่อเรื่องรอง
ติดตามสถานะการทำธุรกรรมได้อย่างง่ายดาย
แพลตฟอร์ม dfuse มอบอินเทอร์เฟซที่หลากหลายซึ่งสามารถตรวจสอบการสตรีมได้ ซึ่งสนับสนุนการติดตามโดยละเอียดแบบเรียลไทม์ของวงจรชีวิตของธุรกรรม Ethereum API ตัวติดตามสถานะการทำธุรกรรมของ dfuse Ethereum ช่วยให้นักพัฒนาสามารถส่งธุรกรรม Ethereum และรับการอัปเดตสถานะแบบละเอียดทันทีในช่องข้อมูลเดียวกัน ติดตามความคืบหน้าของธุรกรรมตลอดวงจรชีวิต
เมื่อใช้ GraphQL คุณสามารถตรวจสอบการเปลี่ยนแปลงในประเภทธุรกรรมที่ระบุได้แบบเรียลไทม์ และในขณะเดียวกันก็ระบุข้อมูลที่คุณต้องการรับในแต่ละครั้งที่มีการเปลี่ยนแปลงธุรกรรมได้อย่างแม่นยำ แพลตฟอร์ม dfuse จัดการความซับซ้อนของการติดตามธุรกรรมและสตรีมไปยัง dapps แบบเรียลไทม์เมื่อมีเหตุการณ์เกิดขึ้น
ภาพเคลื่อนไหวด้านล่างแสดงธุรกรรมที่ต้องผ่านวงจรชีวิตที่ซับซ้อนนี้ — ธุรกรรมต้องผ่านการเปลี่ยนสถานะแปดครั้งก่อนที่จะรวมอยู่ในบล็อกและได้รับการยืนยัน
หากไม่ได้ใช้ dfuse dapp จะต้องเข้าถึง blockchain ครั้งแล้วครั้งเล่าเพื่อบันทึกการเปลี่ยนแปลงทั้งหมดที่ได้รับจากการทำธุรกรรมและอัปเดตให้กับผู้ใช้ และรหัสส่วนหลังจำเป็นต้องเตรียมเพื่อจัดการกับการเปลี่ยนผ่านแต่ละสถานะ
ด้วย dfuse dapps จำเป็นต้องได้รับการอัปเดตการสตรีมผ่านการเชื่อมต่อเพียงครั้งเดียวเท่านั้น และ dfuse จะติดตามธุรกรรมให้คุณผ่านจุดพลิกผันต่างๆ จนกว่าชะตากรรมจะสิ้นสุด
ชื่อเรื่องรอง
แพลตฟอร์มที่ทันสมัยสำหรับ Dapps ขั้นสูง
Lifecycle API เป็นเพียงส่วนเล็กๆ และสำคัญของแพลตฟอร์ม dfuse dfuse ให้ชั้นโครงสร้างพื้นฐานที่ทันสมัยสมบูรณ์แบบสำหรับ dapps กล่าวคือ:
เร็ว,
ปรับขนาดได้
