TL; DR: กำหนดเวลาการย้าย TAP ของกราฟคือวันที่ 3 ธันวาคม 2024 และตัวสร้างดัชนีประมาณ 34% ได้รับการอัปเกรด ซึ่งคิดเป็น 81.6% ของปริมาณการสืบค้น การสนทนาถามตอบมุ่งเน้นไปที่การตั้งค่าการกำหนดค่าของ TAP โดยเฉพาะเกี่ยวกับคำขอ RAV (ใบสำคัญรวมใบเสร็จรับเงิน) และการจัดการค่าใช้จ่ายที่ไม่ได้รวมไว้ พร้อมคำแนะนำให้เริ่มต้นด้วยค่าเริ่มต้นและปรับตามปริมาณการสืบค้น
สวัสดีทุกคน ยินดีต้อนรับสู่รายงานการประชุม Indexer Office Hours เซสชัน 184!
ลิงค์วิดีโอ: https://youtu.be/w0LZkVJemPY
ดูพอดแคสต์ GRTiQ กับ Jeroen Develter, COO ของ Persistence Labs การเดินทางผ่าน web3 ของ Jeroen เริ่มต้นในโลกการเงิน การให้คำปรึกษาแบบดั้งเดิม และกระโดดเข้าสู่โลกแห่งสกุลเงินดิจิทัลและบล็อกเชน
อัปเดตล่าสุดไปยังแหล่งเก็บข้อมูลที่สำคัญ
- Geth เวอร์ชันใหม่ v1.4.12:
- วันที่: 19-11-2024 13:53:28 UTC
- รีลีสนี้จะลบเนมสเปซ RPC ส่วนบุคคลและคำสั่ง –unlock ที่เลิกใช้แล้ว ซึ่งบ่งชี้ถึงการเปลี่ยนแปลงที่สำคัญในการจัดการคีย์ นอกจากนี้ยังรวมถึงการเพิ่มประสิทธิภาพ การปรับปรุงฐานข้อมูล และการแก้ไขข้อบกพร่องต่างๆ รวมถึงการเปลี่ยนแปลงการกำหนดค่าตัวติดตามที่สำคัญ
- สัญญาณฉุกเฉิน: สีเหลือง
- เหตุผลเร่งด่วน: การเปลี่ยนแปลงการจัดการคีย์จำเป็นต้องมีการปรับเปลี่ยนโดยผู้ใช้
- Reth เวอร์ชันใหม่ v1.1.2
- วันที่: 19-11-2024 16:27:10 UTC
- เวอร์ชันนี้ประกอบด้วยการปรับปรุงประสิทธิภาพ การแก้ไขข้อบกพร่อง และการเตรียมการที่สำคัญสำหรับฮาร์ดฟอร์กใหม่ การเปลี่ยนแปลงเหล่านี้เพิ่มประสิทธิภาพการรับงานเพย์โหลดโดยเฉพาะและที่อยู่การเรียงลำดับธุรกรรมที่รอดำเนินการ ทำให้ผู้ใช้ OP-reth ต้องอัปเดตอยู่เสมอ
- สัญญาณฉุกเฉิน: สีแดง
- เหตุผลด่วน: การเตรียม Hard Fork สำหรับผู้ใช้ OP-reth
- sfeth/fireeth: เวอร์ชันใหม่ v2.8.0:
- วันที่: 14-11-2024 14:55:01 UTC
- CombinedFilter ผสานรวมการตรวจสอบความปลอดภัยแบบไม่มีข้อมูลเพื่อเพิ่มเสถียรภาพในระหว่างการประมวลผลธุรกรรม นอกจากนี้ การอัปเดตสตรีมย่อยและการวัดขนาดยังรวมถึงการปรับปรุงฟังก์ชันการวัดด้วย
- สัญญาณฉุกเฉิน: สีเหลือง
- เหตุผลด่วน: ปรับปรุงความเสถียร ไม่ใช่ภัยคุกคามทันที
- หิมะถล่ม: เวอร์ชันใหม่ v1.11.13:
- วันที่: 18-11-2024 22:24:03 UTC
- รุ่นนี้จะแนะนำ API ใหม่ให้กับแพลตฟอร์ม เช่นเดียวกับการแก้ไขการเริ่มต้นตัววัด RPCChainVM และการปรับปรุงความเข้ากันได้ ขอแนะนำให้ผู้ดำเนินการอัปเดตเป็นเวอร์ชันปลั๊กอินล่าสุดเพื่อปรับปรุงความเข้ากันได้และความเสถียร
- สัญญาณฉุกเฉิน: สีเหลือง
- เหตุผลเร่งด่วน: การแก้ไขที่สำคัญและฟีเจอร์ใหม่จำเป็นต้องได้รับการดูแลโดยทันที
- บริการและตัวแทนดัชนี (TS): เวอร์ชันใหม่ v0.21.8:
- วันที่: 18-11-2024 19:23:13 UTC
- รุ่นนี้มีการอัปเดตเล็กๆ น้อยๆ ปรับปรุงส่วนติดต่อผู้ใช้โดยแสดงข้อความข้อขัดแย้งความสูงของกราฟย่อย และแก้ไขพารามิเตอร์ช่วงเวลาการโพลในตัวแทนดัชนี ไม่พบการเปลี่ยนแปลงที่สำคัญที่ส่งผลต่อประสิทธิภาพหรือความปลอดภัยของระบบ
- สัญญาณฉุกเฉิน: สีเขียว
- เหตุผลเร่งด่วน: การเปลี่ยนแปลงที่มีผลกระทบน้อย ไม่มีปัญหาร้ายแรง
- Indexer Service และ Click Agent (RS): เวอร์ชันใหม่ indexer-tap-agent-v1.7.3:
- วันที่: 13-11-2024 19:04:13 UTC
- เวอร์ชัน 1.7.3 แก้ไขจุดบกพร่องโดยการลบการตรวจสอบอะแดปเตอร์ที่ได้รับการจัดการ ซึ่งอาจส่งผลกระทบต่อการประมวลผลธุรกรรม ผู้ปฏิบัติงานทั้งหมดควรตรวจสอบการเปลี่ยนแปลงนี้เพื่อให้แน่ใจว่ามีฟังก์ชันการทำงานที่ราบรื่น
- สัญญาณฉุกเฉิน: สีเหลือง
- เหตุผลเร่งด่วน: การแก้ไขที่สำคัญ ไม่สำคัญ แต่แนะนำให้อัปเดตโดยเร็วที่สุด
อัปเดตล่าสุดเกี่ยวกับการเปลี่ยนแปลงที่สำคัญในโปรโตคอล
- การปรับปรุงอนุญาโตตุลาการในกราฟ: การเปิดตัวคณะทำงาน การขยายคณะกรรมการอนุญาโตตุลาการ และการอัปเดตกระบวนการ
- คณะทำงานอนุญาโตตุลาการชุดใหม่จะเข้ารับหน้าที่นักวิเคราะห์อนุญาโตตุลาการชั่วคราว จนกว่าจะมีการนำนักวิเคราะห์คนใหม่เข้ามาร่วมงาน
- การขยายคณะอนุญาโตตุลาการเป็นการตอกย้ำความมุ่งมั่นของ The Graph ในการรักษามาตรฐานระดับสูงในการอนุญาโตตุลาการ
- กระบวนการอนุญาโตตุลาการอยู่ระหว่างการตรวจสอบเพื่อระบุประเด็นที่ต้องปรับปรุง
- ดูโพสต์ในฟอรัมสำหรับคำถามที่พบบ่อยและเอกสารอ้างอิง
- ขอข้อมูลเกี่ยวกับข้อพิพาท #GDR-19
- ข้อพิพาทนี้เกี่ยวข้องกับ GDR-18 เนื่องจากตัวสร้างดัชนีคนเดียวกันได้ทำซ้ำพฤติกรรมที่ส่งผลให้เกิดการเฉือนก่อนหน้านี้
- ทั่วไป: ใช้บัญชี hardhat-secure สำหรับเครือข่ายที่ไม่ใช่ภายในเครื่อง #1070 (เปิด)
- ทั่วไป: Bump Ignition เวอร์ชันเป็น 0.15.7 #1069 (เปิด)
- แก้ไข: เพิ่มพารามิเตอร์ที่ขาดหายไปให้กับสคริปต์การปรับใช้และลดจำนวนการเรียกใช้ SubgraphService เป็น 50 เท่า #1062 (เปิด)
การสนทนาในวันนี้เป็นการถามตอบเกี่ยวกับการโยกย้าย TAP กับ Ana จาก GraphOps และ Gustavo จาก Semiotic Labs TAP เป็นระบบไมโครเพย์เมนต์ใหม่สำหรับการสืบค้นกราฟ
🚨 ตัวสร้างดัชนีจะต้องย้ายไปยัง TAP ก่อนวันที่ 3 ธันวาคม 2024
เซสชั่นนี้ได้รับคำแนะนำจากบันทึกถามตอบเกี่ยวกับการโยกย้าย IOH TAP ของ Ana ซึ่งได้รับการคัดลอกไว้ในส่วนนี้พร้อมกับข้อมูลพื้นฐานบางส่วนจากการสนทนา ความคิดเห็นได้รับการแก้ไขเล็กน้อย
Ana |GraphOps: มาเริ่มกันที่ TAP คืออะไร
ภาพรวม TAP (Timeline Aggregation Protocol):
- แทนที่ระบบการชำระเงินแบบสเกลาร์แบบเก่า
- โดยมีคุณสมบัติที่สำคัญ เช่น การชำระเงินแบบไมโครเพย์เมนต์ที่มีประสิทธิภาพ ธุรกรรมออนไลน์ที่ลดลง และการควบคุมตัวจัดทำดัชนีเกี่ยวกับใบเสร็จรับเงิน
- เปิดใช้งานเกตเวย์แบบกระจายอำนาจโดยอนุญาตให้ตัวสร้างดัชนียอมรับการสืบค้นจากหลายเกตเวย์
ตัวสร้างดัชนีต้องทำอะไร?
- อัปเดตสแต็กตัวทำดัชนีเพื่อรัน indexer-agent (เวอร์ชัน 0.21.4 หรือใหม่กว่า) แทนที่ indexer-service เพื่อรันเวอร์ชัน Rust และเพิ่มส่วนประกอบใหม่ indexer-tap-agent
- Indexer repo (ตัวแทนดัชนี)
- ฐานรหัส Indexer-rs (บริการดัชนีและตัวทำดัชนี-tap-agent)
- ทรัพยากร:
- หากใช้ Kubernetes ให้ใช้ launchpad-charts/graph-network-indexer
- หากใช้ Docker Compose ให้ใช้สแต็ก StakeSquid
- คู่มือการโยกย้าย TAP
Mickey |The Graph |E&N: จะเกิดอะไรขึ้นถ้าตัวจัดทำดัชนีพลาดกำหนดเวลา? เกตเวย์จะไม่กำหนดเส้นทางการสืบค้นใหม่ไปยังพวกเขาจนกว่าจะอัปเกรดหรือ...
- Gustavo |Semiotic Labs: ขณะนี้เกตเวย์ให้ใบเสร็จรับเงินสำหรับ Scalar และ TAP เมื่อเราถึงกำหนดเวลา เกตเวย์จะรองรับเฉพาะใบเสร็จรับเงิน TAP เท่านั้น หากเวอร์ชันของคุณต่ำกว่า 1.0 คุณจะไม่ได้รับการสอบถามอีกต่อไป
- อานา: ขอบใจนะ นั่นก็สมเหตุสมผลดี ดังนั้นหากคุณต้องการรับข้อความค้นหาต่อไป คุณจะต้องย้ายข้อมูล
Mickey |The Graph |E&N: มีวิธีใดบ้างที่จะบอกได้ว่าตัวสร้างดัชนีถูกย้ายไปยังตัวสร้างดัชนีกี่เปอร์เซ็นต์?
- Ana: วิธีหนึ่งที่จะบอกได้ว่าตัวสร้างดัชนีถูกย้ายไปยัง TAP หรือไม่ก็คือ พวกเขามีป้ายชื่อ TAP READY ในไฟล์การกำหนดค่าตัวสร้างดัชนีใน GraphSeer หรือไม่
- Gustavo: ที่ Semiotic เรากำลังติดตามตัวเลขนี้อย่างใกล้ชิด โดยตรวจสอบว่าตัวสร้างดัชนีกำลังใช้งานเวอร์ชันที่สูงกว่า 1.0 หรือไม่ จากตัวสร้างดัชนี 88 ตัวที่เราติดตาม มี 30 ตัวที่กำลังใช้งานตัวสร้างดัชนีเวอร์ชัน 1.0 หรือสูงกว่า คิดเป็นประมาณ 34% ของผู้ทำดัชนี
- นอกจากนี้ เรายังติดตามจำนวนคำค้นหาที่ให้บริการในช่วงเดือนที่ผ่านมาสำหรับแต่ละคำค้นหา ดังนั้นเราจึงมีคำค้นหา 81.6% ที่ทำงานผ่าน TAP
- อานา: ฉันคิดว่าสิ่งที่คุณกำลังพูดก็คือตัวทำดัชนีที่มีปริมาณการสืบค้นสูงสุดได้รับการอัปเกรดแล้ว
- กุสตาโว: ใช่. จากตัวทำดัชนี 10 อันดับแรก มี 9 ตัวที่ได้รับการอัปเกรดแล้ว อันที่จริงแล้ว จากตัวทำดัชนี 14 ตัวแรก มี 13 ตัวที่ได้รับการอัปเกรดแล้ว
Mickey |กราฟ |E&N: ความประทับใจของฉันคือผู้ทำดัชนีจำนวนมากกำลังมีปัญหาในการอัปเกรด - การแสดงผลนั้นถูกต้องหรือไม่ และหากเป็นเช่นนั้น เส้นตายวันที่ 3 ธันวาคมจะสมจริงหรือไม่ที่จะให้ทุกคนที่นั่นอัปเกรดก่อนหน้านี้ (ไม่มีการแรเงา แค่อยากรู้ว่ามันเสถียรเพียงพอหรือไม่)
- Gustavo: ฉันคิดว่าเรากำลังมาถูกทางในการ [โยกย้าย] ข้อความค้นหาส่วนใหญ่ การย้ายตัวจัดทำดัชนี 100% ก่อนกำหนดเวลาวันที่ 3 ธันวาคมนั้นค่อนข้างยาก แต่ฉันคิดว่าเราสามารถไปถึง 95% ได้อย่างง่ายดาย เราอยู่ที่นี่เพื่อสนับสนุนคุณเพื่อให้เราสามารถพยายามเข้าถึงได้ 100%
มิกกี้ |กราฟ |E&N: ทำไมต้อง 88 [ดัชนีชี้วัด]? สิ่งเหล่านี้เป็นเพียงสิ่งเดียวที่ให้บริการการสืบค้นจริงหรือไม่
- Gustavo: เราใช้กราฟย่อย Quality of Service (QoS) เพื่อตรวจสอบตัวสร้างดัชนีที่ใช้งานอยู่ทั้งหมด ดังนั้นโดยพื้นฐานแล้ว หากพวกเขาให้บริการแบบสอบถามในเดือนที่ผ่านมา ก็จะปรากฏในรายการ 88 เราให้ความสำคัญกับการสืบค้นเป็นหลัก และเราพอใจหากตัวสร้างดัชนีที่ให้บริการการสืบค้นใช้เวอร์ชันล่าสุด
paka |E&N: ฉันมั่นใจด้วยว่าปริมาณการค้นหาส่วนใหญ่จะถูกนำมาที่ TAP
มิกกี้ |เดอะกราฟ |E&N: เข้าใจแล้ว! กลยุทธ์ที่ดี
Mickey |The Graph |E&N: คุณจะติดต่อกับบริษัทที่ยังไม่ปรับตัวที่สอบถามข้อมูลแต่ยังไม่ได้อัปเกรดเป็นรายบุคคลหรือไม่?
- Gustavo: เราอยู่ระหว่างการติดต่อผู้จัดทำดัชนีที่เราติดต่อ เรามีรายชื่อและเรากำลังติดต่อกับแต่ละคน โดยเริ่มจากรายการที่ใหญ่ที่สุด ปัจจุบัน สองสิ่งที่ใหญ่ที่สุดที่ยังไม่ได้อัปเกรดคือ Upgrade Indexer [Edge & Node] และ Pinax เรากำลังทำงานอย่างใกล้ชิดกับ Edge และ Node เพื่อให้สามารถรองรับการอัปเกรดเป็นเวอร์ชันที่เกิน 1.0 ได้ ตราบใดที่เราเชื่อมต่อกับตัวสร้างดัชนีนั้น เราจะทำงานทีละรายการจากการสืบค้นที่มีปริมาณสูงสุดไปจนถึงการสืบค้นที่มีปริมาณน้อยที่สุด
Ana: เรายินดีให้ผู้ทำดัชนีติดธงทำเครื่องหมายตัวทำดัชนีที่ถูกย้ายเพื่อขอความช่วยเหลือ หากคุณมีคำถามใด ๆ โปรดติดต่อเรา
Gustavo |. Semiotic Labs: หากใครมีคำถามใดๆ ฉันจะตอบคำถามเหล่านั้นใน 📁︱indexers และ 📁︱indexers -softwarechannels ใน The Graph Discord
- ค่าใช้จ่ายแบบรวมและคำขอ RAV:
- ปัญหา: ผู้จัดทำดัชนีอาจเห็นว่าค่าใช้จ่ายแบบรวมของตนอยู่ในระดับสูง โดยเฉพาะอย่างยิ่งหากตั้งค่า rav_request_trigger_value ต่ำเกินไป
- คำอธิบาย: rav_request_trigger_value กำหนดว่าเมื่อใดที่ตัวจัดทำดัชนีขอ Receipt Aggregation Voucher (RAV) จากผู้ส่ง (คุณอาจคิดว่าผู้ส่งเป็นเกตเวย์) หากค่านี้ต่ำเกินไป ทริกเกอร์อาจไม่ตอบสนองบ่อยเพียงพอ ส่งผลให้ค่าใช้จ่ายสะสมโดยไม่ถูกทบ
- วิธีแก้ไข: อัปเดต rav_request_trigger_value ของคุณ ซึ่งคำนวณเป็น max_amount_willing_to_lose_grt / trigger_value_divisor
Ana: มีแดชบอร์ด ฉันวางไว้ที่นี่ ในแผงแบบไม่รวม คุณจะเห็นค่าทริกเกอร์ ในกรณีของฉันค่าทริกเกอร์ RAV คือ 3 วิธีการทำงานคือเมื่อได้รับใบเสร็จรับเงินใหม่ มูลค่าจะถูกเพิ่มไปยังค่าใช้จ่ายแบบรวม และระบบจะตรวจสอบอย่างต่อเนื่องว่าค่าใช้จ่ายรวมรวมเกินมูลค่าทริกเกอร์หรือไม่
เมื่อตรงตามเงื่อนไขทริกเกอร์ คำขอ RAV จะถูกสร้างขึ้นโดยการตรวจสอบบัฟเฟอร์การประทับเวลาเพื่อกำหนดระยะเวลาย้อนหลังที่การรับจะถือเป็นการรับ และจะจำกัดจำนวนการรับตามขีดจำกัดการรับคำขอ RAV
หากเราดูการกำหนดค่าคร่าวๆ มีบางสิ่งที่สำคัญที่นี่:
- max_amount_willing_to_lose_GRT
- trigger_value_divisor
ทั้งสองนี้กำหนดค่าทริกเกอร์
- timestamp_buffer_secs เช่น เวลาที่พิจารณาใบเสร็จรับเงิน
- max_receipts_per_request ดังนั้น RAV จึงสามารถบรรจุใบเสร็จรับเงินได้สูงสุด 10,000 ใบ
หากใบเสร็จรับเงินใดๆ ไม่ถูกต้อง ใบเสร็จรับเงินเหล่านั้นจะถูกจัดเก็บแยกต่างหากในตารางใบเสร็จรับเงิน Scaler TAP ที่ไม่ถูกต้องในฐานข้อมูลเมตาดาต้าของตัวจัดทำดัชนี เมื่อ max_receipt_value_GRT สูงกว่าค่านี้ แสดงว่าใบเสร็จรับเงินไม่ถูกต้อง
การกำหนดค่า: สูงสุด-config-example-toml
Gustavo: ฉันแค่อยากจะพูดถึงสิ่งที่เกิดขึ้นที่นี่ และทำไมเราถึงมีการกำหนดค่ามากมาย สำหรับตัวสร้างดัชนีส่วนใหญ่ การกำหนดค่าเหล่านี้จะไม่เป็นปัญหาเนื่องจากไม่มีปริมาณการสืบค้นขนาดใหญ่
หากคุณมีการจัดสรรต่อวินาทีมากเกินไปหรือมีการสืบค้นมากเกินไป อาจเป็นเรื่องยากเล็กน้อย ซึ่งเป็นเหตุผลว่าทำไมคุณต้องอัปเดตและกำหนดค่าสิ่งเหล่านี้ โดยทั่วไปฉันขอแนะนำให้คุณลองใช้ค่าเริ่มต้นก่อนแล้วจึงดู ค่าเริ่มต้นปัจจุบันคือ:
- max_amount_willing_to_lose_GRT = 20
- trigger_value_divisor = 10
- ซึ่งหมายความว่าทุกครั้งที่ยอดรวมของใบเสร็จรับเงินแบบไม่สรุปของคุณ (หรือที่เรียกว่าค่าใช้จ่ายที่ไม่ได้สรุป) มีจำนวนถึง 2 GRT เราจะพยายามทบยอด อย่างไรก็ตาม หากค่ามากกว่า 2 เสมอ คุณจะต้องเปลี่ยนค่าเหล่านี้
- พยายามรักษา max_amount_willing_to_lose_GRT ให้ต่ำที่สุดเท่าที่จะเป็นไปได้ อย่างไรก็ตาม หากคำขอ RAV ล้มเหลวและคุณได้รับใบเสร็จรับเงินจำนวนมากในขณะนั้นเนื่องจากคุณเป็นผู้ทำดัชนีรายใหญ่ คุณจะบล็อกผู้ส่งอย่างรวดเร็ว
- การประทับเวลา_buffer_secs = 60
- request_timeout_secs = 5
- max_receipts_per_request = 10,000
ตัวสร้างดัชนี 15-20 ตัวแรกจำเป็นต้องอัปเดตค่าเหล่านี้
Pierre |. Chain-Insights.io: ค่านิยมในอุดมคติของฉันคืออะไร ค่าเริ่มต้นยังดีสำหรับฉันใช่ไหม ดูเหมือนว่าฉันจะไม่ได้รับคำขอ RAV
ตัวสร้างดัชนี 15-20 ตัวแรกจำเป็นต้องอัปเดตค่าเหล่านี้
Pierre |. Chain-Insights.io: ค่านิยมในอุดมคติของฉันคืออะไร ค่าเริ่มต้นยังดีสำหรับฉันใช่ไหม ดูเหมือนว่าฉันจะไม่ได้รับคำขอ RAV
Gustavo: ขอฉันตรวจสอบหน่อย... มูลค่าทริกเกอร์ ต้นทุนรวมที่ไม่ได้รวม ดังนั้นก่อนอื่นให้อัปเดตเล็กน้อย คุณใช้เวอร์ชันใดอยู่?
ปิแอร์: เวอร์ชันล่าสุด
Gustavo: โดยปกติแล้วเมื่อคุณเข้าถึงทริกเกอร์ RAV ก็ควรพยายามสร้างคำขอ RAV หากไม่เกิดขึ้น เราจำเป็นต้องสอบสวน
ปิแอร์ |. Chain-Insights.io: ไม่ใช่สำหรับฉัน:
tap: max_amount_willing_to_lose_grt: 20 tap.rav_request: trigger_value_divisor: 2 timestamp_buffer_secs: 60 request_timeout_secs: 5 max_receipts_per_request: 10000
Gustavo: ค่าทริกเกอร์ของคุณคือประมาณ 10 ใช่ไหม?
ปิแอร์โพสต์: ใช่ 20 / 2
Gustavo: ดังนั้น คุณจะทริกเกอร์คำขอ RAV เมื่อคุณมียอดถึง 10 GRT หรือใบเสร็จรับเงิน 10,000 ใบสำหรับการจัดสรรที่กำหนดเท่านั้น เนื่องจากปริมาณการค้นหาของคุณ ฉันจึงแนะนำประมาณ 0.1 หรือ:
max_amount_willing_to_lose_grt: 1 trigger_value_divisor: 10 max_receipts_per_request: 1000
ปิแอร์โพสต์: โอเค ขอบคุณ
Gustavo: หากคุณไม่มีการสืบค้นต่อวินาทีมากนัก คุณจะต้องมีคำขอ RAV เพิ่มขึ้นหรือมีค่าทริกเกอร์ที่มากขึ้น
ทุกอย่างขึ้นอยู่กับจำนวนการจัดสรรที่คุณเปิดไว้ และจำนวนการสืบค้นต่อวินาทีที่คุณได้รับ และจำนวนการสืบค้นต่อวินาทีต่อการจัดสรร และการระเบิดใดๆ ที่คุณมี
ใน TAP หลังจากการรวม ณ เวลาใดเวลาหนึ่ง ใบเสร็จรับเงินที่มีการประทับเวลาก่อนเวลาดังกล่าวจะไม่ทำงาน ถือว่าไม่ถูกต้อง ดังนั้นเราจึงมีบัฟเฟอร์นี้ เรารับเฉพาะใบเสร็จหลังจาก 60 วินาทีเท่านั้น นี่เป็นเพราะว่าการซิงโครไนซ์นาฬิการะหว่างคอมพิวเตอร์เครื่องอื่นเป็นเรื่องยาก เกตเวย์จะส่งใบเสร็จรับเงินให้คุณและกำหนดเวลาประทับซึ่งอาจเป็น 5 วินาทีก่อนหรือหลังนาฬิกาของคุณ
เราตั้งค่าเริ่มต้นให้อยู่ระหว่างนั้น โดยมีการสืบค้น 1-2 ครั้งต่อวินาที และคำขอ RAV 1 ครั้งทุกๆ 15 นาที อย่างไรก็ตาม หากคุณมีหน่วยความจำน้อยกว่าจำนวนนี้ คุณอาจต้องอัปเดตเป็น max_amount_willing_to_lose_grt ที่ต่ำกว่า หากเกินจำนวนนี้ คุณอาจต้องอัปเดตเพิ่มเติม
Gemma |. LunaNova: ค่าเหล่านี้ต่อการจัดสรรหรือในการจัดสรรทั้งหมด?
calinah |. GraphOps: ต่อการมอบหมาย
Pierre |. Chain-Insights.io: หลังจากอัปเดตเป็นเวอร์ชันต่อไปนี้:
Gemma|LunaNova: ค่าเหล่านี้ต่อการจัดสรรหรือในการจัดสรรทั้งหมดหรือไม่
calinah |. GraphOps: ต่อการมอบหมาย
Pierre |. Chain-Insights.io: หลังจากอัปเดตเป็นเวอร์ชันต่อไปนี้:
calinah |GraphOps: เยี่ยมเลย อัตราการยอมรับของคุณดีขึ้นแล้ว
กุสตาโว: ใช่ ดีเลย ดังนั้นสิ่งที่คุณต้องการทำสำหรับแดชบอร์ดก็คือ ค่าใช้จ่ายแบบรวมควรอยู่ที่ 0.1 เสมอ ดังนั้นทุกครั้งที่คุณมีคำขอ RAV ค่าใช้จ่ายจะลดลงเล็กน้อย และหลังจากนั้น 15 นาที คุณก็จะมีใบเสร็จรับเงินเพียงพอที่จะทริกเกอร์คำขอ RAV อื่น
Josh Kauffman |StreamingFast.io: ใครสามารถแบ่งปันสิ่งที่พวกเขาตั้งไว้สำหรับค่าเหล่านี้ได้หรือไม่
Marc-André |Ellipfra: เพื่อการอ้างอิง ฉันใช้ค่าเหล่านี้กับแคมเปญของฉัน ฉันไม่แนะนำเป็นพิเศษเนื่องจากมีการตั้งค่าแบบสุ่มไม่มากก็น้อย max_willing_to_lose สูงมากเพื่อหลีกเลี่ยงการปฏิเสธเกตเวย์บ่อยเกินไป ฉันวางแผนที่จะลดมันลงในจุดใดจุดหนึ่ง:
max_amount_willing_to_lose_grt = "1000.0" [tap.rav_request] timestamp_buffer_secs = 30 trigger_value_divisor = 50 request_timeout_secs = 20 max_receipts_per_request = 2000
- ปัญหาการปฏิเสธผู้ส่ง:
- ผู้ส่งไม่อยู่ในรายการ tap.sender_aggregator_endpoints
- ยอดคงเหลือเอสโครว์ของผู้ส่งไม่เพียงพอที่จะครอบคลุมค่าบริการคงค้าง
- ค่าธรรมเนียมรวมเกินขีดจำกัด max_fee_per_sender
- ปัญหา: ตัวสร้างดัชนีอาจพบการปฏิเสธผู้ส่ง ส่งผลให้การประมวลผลและรายได้หยุดชะงัก
- เหตุผลในการปฏิเสธ: มีสาเหตุหลักสามประการที่ทำให้ผู้ส่งถูกปฏิเสธ:
- วิธีแก้ไข: วิธีแก้ไขเฉพาะสำหรับเหตุผลในการปฏิเสธแต่ละข้อ:
- ตรวจสอบว่าผู้ส่งได้รับการกำหนดค่าอย่างถูกต้องในส่วน tap.sender_aggregator_endpoints
- ตรวจสอบปัญหาที่อาจเกิดขึ้นกับกองทุนเอสโครว์และรับรองยอดคงเหลือที่เพียงพอ
- หากการเรียกเก็บเงินแบบรวมมักถึงขีดจำกัด ให้ตรวจสอบและอาจปรับการตั้งค่า max_amount_willing_to_lose_grt
- หมายเหตุ: ตัวแทน TAP ของตัวทำดัชนีจะเริ่มต้นด้วยชื่อต่อไปนี้เสมอ:
2024-11-13T08:41:31.200776Z ERROR indexer_tap_agent::agent::sender_accounts_manager: There was an error while starting the sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490, denying it. Error: No sender_aggregator_endpoints found for sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490 at tap-agent/src/agent/sender_accounts_manager.rs:311 in ractor::actor::Actor with id: "0.0"
สำหรับ INDEXER_TAP__SENDER_AGGREGATOR_ENDPOINTS__ ไม่ได้อยู่ใน tap.sender_aggregator_endpoints หรือผ่าน env vars
- ข้อผิดพลาดการรวบรวมใบเสร็จรับเงินบนตัวสร้างดัชนี:
- indexer-agent 上的 collect-receipt-endpoint 错误：
{"level":40,"time":1731239677641,"pid":1,"hostname":"graph-network-indexer-agent-0","name":"IndexerAgent","msg":"The option '--collect-receipts-endpoint' is deprecated. Please use the option '--gateway-endpoint' to inform the Gateway base URL."}
Gustavo: เหตุผลที่คุณต้องการปฏิเสธผู้ส่งก็คือผู้ส่งไม่ได้จ่ายเงินให้คุณ ดังนั้นพวกเขาจึงไม่มีเอสโครว์เพียงพอ หรือพวกเขาขอจำนวนเงินที่คุณยินดีจะเสีย อีกสิ่งหนึ่งที่สามารถเกิดขึ้นได้คือเราใช้ใบเสร็จที่ไม่ถูกต้องสำหรับสิ่งนี้ ดังนั้นหากจำนวนใบเสร็จที่ไม่ถูกต้องที่คุณมีคือจำนวนสูงสุดที่คุณยินดีจะสูญเสีย คุณจะบล็อกผู้ส่งสำหรับสิ่งนั้น
การอัปเดตด่วนบน max_receipt_value_grt คือสิ่งนี้ใช้ได้กับบริการนั้นเท่านั้น เพื่อให้ TAP เชื่อถือได้น้อยที่สุด สิ่งเหล่านี้จะต้องเป็นการชำระเงินแบบไมโคร ดังนั้นเมื่อเกตเวย์ส่งใบเสร็จให้คุณ นี่คือมูลค่าใบเสร็จสูงสุดที่พวกเขาจะยอมรับโดยไม่ถือว่าเป็นใบเสร็จที่ไม่ถูกต้อง
ใบเสร็จรับเงินที่ไม่ถูกต้องคือใบเสร็จที่คุณได้รับ สอบถามรายละเอียดเพิ่มเติม และพบว่าใบเสร็จนั้นไม่ถูกต้อง
Ana: สำหรับใบเสร็จรับเงินที่ไม่ถูกต้อง จะมีผลหรือไม่หากเงื่อนไขใดๆ เปลี่ยนแปลง หรือจะไม่มีการลองอีกครั้งเมื่อใบเสร็จถูกทำเครื่องหมายว่าไม่ถูกต้อง
กุสตาโว: ไม่ต้องลองอีกครั้ง ตารางนี้ใช้สำหรับการบันทึกเท่านั้น เพื่อให้คุณสามารถเข้าถึงฐานข้อมูลและดูว่าเกิดอะไรขึ้นและเหตุใดการรับจึงล้มเหลว
อานา: นั่นก็สมเหตุสมผลดี นอกจากนี้ บนแผงควบคุม TAP คุณสามารถดูได้ว่าผู้ส่งถูกบล็อกหรือไม่
- ข้อผิดพลาดคำขอ RAV:
- ปัญหา: ข้อผิดพลาดระหว่างคำขอ RAV อาจขัดจังหวะกระบวนการรวม
- ตัวอย่างข้อผิดพลาด: ดูเหมือนว่าคำขอ RAV ไม่มีใบเสร็จรับเงินที่ถูกต้อง... คุณสามารถแก้ไขได้โดยเพิ่ม rav_request_trigger_value
- คำอธิบาย: ข้อผิดพลาดนี้บ่งชี้ว่า rav_request_trigger_value ไม่เพียงพอ ป้องกันไม่ให้รวมการรับไว้ในคำขอ RAV
- วิธีแก้ไข: วิธีแก้ไขมีอยู่ในข้อความแสดงข้อผิดพลาด - เพิ่ม rav_request_trigger_value
- เวอร์ชันซอฟต์แวร์: ใช้เวอร์ชันซอฟต์แวร์ที่จำเป็นสำหรับ Indexer-agent, Indexer-service และ tap-agent
- บทสรุปไฟล์การกำหนดค่า:
- การกำหนดค่าที่ใช้ร่วมกัน: บริการทำดัชนีและ tap-agent แชร์ไฟล์การกำหนดค่า TOML ทั่วไป
- ที่อยู่ Blockchain และจุดสิ้นสุด:
- สิ่งสำคัญ: ใช้ที่อยู่สัญญา จุดสิ้นสุดเกตเวย์ และรหัสลูกโซ่ที่ถูกต้อง
- การกำหนดค่าระดับบันทึก: หากต้องการตั้งค่าตัวแปรสภาพแวดล้อม RUST_LOG สำหรับการบันทึกที่เหมาะสม ให้ใช้ RUST_LOG=indexer_tap_agent=debug,info
- แดชบอร์ดตัวชี้วัดและ Grafana:
- จุดสิ้นสุดการวัด: ส่วนประกอบทั้งหมดเปิดเผยการวัดบนพอร์ต 7300 ของ Prometheus
- แดชบอร์ด Grafana: indexer-rs/docs/dashboard.json
Pierre |. Chain-Insights.io: จนถึงวันที่ 3 ธันวาคม มีผู้ส่งเพียงคนเดียวเท่านั้นที่ยังใช้งานอยู่?
# collect-receipts-endpoint: " " DEPRECATED # collect-receipts-endpoint: " " DEPRECATED gateway-endpoint: " " gateway-endpoint: " "
- อานา: เท่าที่ฉันรู้ สิ่งนี้ถูกต้อง ดังนั้นมีเพียงผู้ส่ง Edge และโหนดเท่านั้นที่ทุกคนใช้งานและใช้งาน GraphOps หวังว่าจะเพิ่มตัวสร้างดัชนีบางส่วนในเกตเวย์ของเราภายในสิ้นเดือนธันวาคมถึงต้นเดือนมกราคม
ปิแอร์: สิ่งนี้ดีหรือฉันควรเปลี่ยนกลับเพื่อเปิดใช้งานจุดรับ-ส่งปลายทาง
ปิแอร์: สิ่งนี้ดีหรือฉันควรเปลี่ยนกลับเพื่อเปิดใช้งานจุดรับ-ส่งปลายทาง
- อนา: การใช้เกตเวย์-ปลายทางนั้นดีมาก โดยพื้นฐานแล้ว สิ่งเดียวที่คุณต้องรู้ก็คือคุณสามารถเลือกได้ว่าจะใช้แฟล็ก CLI ใด แต่คุณจะเห็นข้อผิดพลาดเดียวกันนี้ ซึ่งทำให้เกิดความสับสน ดังนั้นคุณจึงไม่ต้องทำอะไรที่นี่
Ana: ผู้จัดทำดัชนีบางคนที่ย้ายถิ่นฐานมีความคิดเห็นเกี่ยวกับสิ่งที่พวกเขาพบว่าต้องการแบ่งปันหรือไม่
- Marc-André |Ellipfra: การตั้งค่าและการตรวจสอบแดชบอร์ดถือเป็นสิ่งสำคัญ แต่ละรุ่นจะมีความเสถียรมากขึ้น แต่คุณไม่มีทางรู้ได้เลย
Gustavo: หากคุณมีคำขอคุณลักษณะหรือแนวคิดเกี่ยวกับวิธีกำหนดค่าให้ดีขึ้น โปรดแจ้งปัญหาใน repo ของ Indexer-rs ได้เลย
เรายินดีที่จะตรวจสอบทุกปัญหาและคำขอคุณสมบัติเพื่อให้เราสามารถทำให้ระบบดีขึ้น เทคโนโลยีมีเสถียรภาพมากขึ้น และหวังว่าจะไปถึงระดับที่ดีขึ้น ขอขอบคุณที่สละเวลาเพื่อหารือเกี่ยวกับ TAP โดยละเอียด
#blockchaindataindex#web3dataanalytics#TheGraph
ความคิดเห็นทั้งหมด