บอต Stream API ของ OpenSea: เปลี่ยนเหตุการณ์เป็นสถานะ

บอต Stream API ของ OpenSea ได้รับข้อมูลอะไร

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

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

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

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

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

แยกตัวตนของเหตุการณ์ออกจากตัวตนของสินทรัพย์

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

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

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

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

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

การจัดลำดับเหตุการณ์ของบอต Stream API ของ OpenSea ต้องมีบริบท

พิจารณาชิ้นงานสมมติที่มีรายการขาย A ในราคา 0.40 ETH ภาพสถานะภายในระบบยังมีรายการขาย B ที่ราคา 0.43 สำหรับอีกชิ้น และรายการขาย C ที่ราคา 0.45 สำหรับชิ้นที่สาม ณ จุดเริ่มต้นนั้น ราคาต่ำสุดที่มองเห็นคือ 0.40

ที่เวลา 12:00:02 รายการขาย A ถูกยกเลิก ที่เวลา 12:00:03 ชิ้นงานเดิมได้รับรายการขายใหม่ A2 ในราคา 0.41 สมมติว่าบอตได้รับเหตุการณ์สร้าง A2 ก่อน แล้วจึงได้รับเหตุการณ์ยกเลิก A ที่เก่ากว่าในภายหลัง นี่เป็นลำดับเหตุการณ์ที่ตั้งใจสร้างขึ้นให้มาถึงผิดลำดับ

หากโปรแกรมใช้เพียงตัวตนโทเคนเป็นกุญแจอ้างอิงสถานะรายการขาย การยกเลิกที่มาช้าอาจลบ A2 โดยผิดพลาด โปรแกรมจะรายงานราคาต่ำสุดเป็น 0.43 แต่หากเก็บตัวตนคำสั่งไว้ โปรแกรมสามารถยกเลิก A โดยยังรักษา A2 ไว้ ทำให้ราคาต่ำสุดที่ถูกต้องในตัวอย่างยังเป็น 0.41

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

ส่วนประมวลผลที่เปลี่ยนสถานะอย่างรัดกุมจะตรวจว่าเหตุการณ์เปลี่ยนวัตถุใด และการเปลี่ยนแปลงนั้นสอดคล้องกับหลักฐานปัจจุบันหรือไม่ การเรียงทุกข้อความตามเวลาที่ได้รับ หรือเก็บเพียงข้อความล่าสุดของแต่ละโทเคนยังไม่เพียงพอ

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

ตัดผลที่ซ้ำกันโดยไม่ทิ้งกิจกรรมที่เกิดขึ้นจริง

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

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

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

ข้อมูลนำเข้าจากสตรีมจะมีการขายที่ไม่ซ้ำกัน 18 ครั้งกับข้อมูลซ้ำอีกห้ารายการ รวมเป็น 23 ข้อความที่แสดงเหตุการณ์ขาย หากรวมทุกข้อความจะได้ปริมาณ 4.60 ETH เมื่อตัดเหตุการณ์ที่ส่งมาซ้ำกันออกจะได้ 3.60 ETH ส่วนชุดข้อมูลที่ทราบว่าครบมีปริมาณ 4.00 ETH

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

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

การเชื่อมต่อกลับมาไม่ใช่การกู้คืนประวัติ

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

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

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

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

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

รวมภาพสถานะกับเหตุการณ์โดยไม่สมมติว่ามีนาฬิการ่วมทั่วระบบ

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

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

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

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

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

แยกกิจกรรมในอดีตออกจากความมีผลในปัจจุบัน

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

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

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

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

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

ข้อมูลตลาดสาธารณะไม่สามารถแทนหลักฐานของบัญชี

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

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

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

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

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

จัดการคิวค้างในฐานะหลักฐานที่ล้าสมัย

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

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

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

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

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

เลือกการสมัครรับข้อมูลให้ตรงกับคำถามวิจัย

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

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

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

สำหรับบอต NFT บน Solana ความครอบคลุมของการสมัครรับข้อมูลไม่ได้ยืนยันว่ามาตรฐานหรือเส้นทางรายการขายทุกรายการที่สังเกตสามารถซื้อขายได้ แบบจำลองสินทรัพย์และการรองรับการดำเนินการยังต้องได้รับการตรวจสอบอย่างอิสระหลังจากได้รับเหตุการณ์

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

แยกเวลาสำหรับรายงานออกจากเวลาที่ใช้ตัดสินใจ

เหตุการณ์ที่มาช้าอาจจัดอยู่ในช่วงประวัติที่เก่ากว่า แต่เพิ่งพร้อมให้ใช้ตัดสินใจในตอนนี้ ลองนึกถึงการขายที่เอกสารระบุเวลาเหตุการณ์เป็น 09:59:59 แต่ข้อความมาถึงบอตที่ 10:00:04 ประวัติที่จัดกลุ่มตามเวลาเหตุการณ์อาจจัดการขายนั้นไว้ในนาทีที่สิ้นสุดที่ 10:00 แต่การตัดสินใจสดที่เกิดขึ้นเวลา 10:00:01 ไม่สามารถใช้ข้อความนั้นได้

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

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

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

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

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

ทดสอบเครื่องสถานะด้วยผลสุดท้ายที่ทราบล่วงหน้า

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

ตัวอย่าง A และ A2 ก่อนหน้าควรลงท้ายด้วย A ถูกยกเลิก และ A2 ยังทำงานที่ราคา 0.41 ร่วมกับ B และ C การสลับลำดับส่งข้อมูลไม่ควรลบคำสั่งผิดรายการ ตัวอย่างการขาย 20 ครั้งควรลงท้ายด้วยชุดข้อมูลที่ทราบว่าครบหลังการกระทบยอด ไม่ใช่เพียงยอดรวมที่ดูน่าเชื่อถือ

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

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

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