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 เริ่มต้นในโลกการเงิน การให้คำปรึกษาแบบดั้งเดิม และกระโดดเข้าสู่โลกแห่งสกุลเงินดิจิทัลและบล็อกเชน

อัปเดตล่าสุดไปยังแหล่งเก็บข้อมูลที่สำคัญ

อัปเดตล่าสุดเกี่ยวกับการเปลี่ยนแปลงที่สำคัญในโปรโตคอล

การสนทนาในวันนี้เป็นการถามตอบเกี่ยวกับการโยกย้าย TAP กับ Ana จาก GraphOps และ Gustavo จาก Semiotic Labs TAP เป็นระบบไมโครเพย์เมนต์ใหม่สำหรับการสืบค้นกราฟ

🚨 ตัวสร้างดัชนีจะต้องย้ายไปยัง TAP ก่อนวันที่ 3 ธันวาคม 2024

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

Ana |GraphOps: มาเริ่มกันที่ TAP คืออะไร

ภาพรวม TAP (Timeline Aggregation Protocol):

ตัวสร้างดัชนีต้องทำอะไร?

Mickey |The Graph |E&N: จะเกิดอะไรขึ้นถ้าตัวจัดทำดัชนีพลาดกำหนดเวลา? เกตเวย์จะไม่กำหนดเส้นทางการสืบค้นใหม่ไปยังพวกเขาจนกว่าจะอัปเกรดหรือ...

Mickey |The Graph |E&N: มีวิธีใดบ้างที่จะบอกได้ว่าตัวสร้างดัชนีถูกย้ายไปยังตัวสร้างดัชนีกี่เปอร์เซ็นต์?

Mickey |กราฟ |E&N: ความประทับใจของฉันคือผู้ทำดัชนีจำนวนมากกำลังมีปัญหาในการอัปเกรด - การแสดงผลนั้นถูกต้องหรือไม่ และหากเป็นเช่นนั้น เส้นตายวันที่ 3 ธันวาคมจะสมจริงหรือไม่ที่จะให้ทุกคนที่นั่นอัปเกรดก่อนหน้านี้ (ไม่มีการแรเงา แค่อยากรู้ว่ามันเสถียรเพียงพอหรือไม่)

มิกกี้ |กราฟ |E&N: ทำไมต้อง 88 [ดัชนีชี้วัด]? สิ่งเหล่านี้เป็นเพียงสิ่งเดียวที่ให้บริการการสืบค้นจริงหรือไม่

paka |E&N: ฉันมั่นใจด้วยว่าปริมาณการค้นหาส่วนใหญ่จะถูกนำมาที่ TAP

มิกกี้ |เดอะกราฟ |E&N: เข้าใจแล้ว! กลยุทธ์ที่ดี

Mickey |The Graph |E&N: คุณจะติดต่อกับบริษัทที่ยังไม่ปรับตัวที่สอบถามข้อมูลแต่ยังไม่ได้อัปเกรดเป็นรายบุคคลหรือไม่?

Ana: เรายินดีให้ผู้ทำดัชนีติดธงทำเครื่องหมายตัวทำดัชนีที่ถูกย้ายเพื่อขอความช่วยเหลือ หากคุณมีคำถามใด ๆ โปรดติดต่อเรา

Gustavo |. Semiotic Labs: หากใครมีคำถามใดๆ ฉันจะตอบคำถามเหล่านั้นใน 📁︱indexers และ 📁︱indexers -softwarechannels ใน The Graph Discord

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

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

หากเราดูการกำหนดค่าคร่าวๆ มีบางสิ่งที่สำคัญที่นี่:

ทั้งสองนี้กำหนดค่าทริกเกอร์

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

การกำหนดค่า: สูงสุด-config-example-toml

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

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

ตัวสร้างดัชนี 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

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

{"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 คุณสามารถดูได้ว่าผู้ส่งถูกบล็อกหรือไม่

Pierre |. Chain-Insights.io: จนถึงวันที่ 3 ธันวาคม มีผู้ส่งเพียงคนเดียวเท่านั้นที่ยังใช้งานอยู่?

# collect-receipts-endpoint: " " DEPRECATED # collect-receipts-endpoint: " " DEPRECATED gateway-endpoint: " " gateway-endpoint: " "

ปิแอร์: สิ่งนี้ดีหรือฉันควรเปลี่ยนกลับเพื่อเปิดใช้งานจุดรับ-ส่งปลายทาง

ปิแอร์: สิ่งนี้ดีหรือฉันควรเปลี่ยนกลับเพื่อเปิดใช้งานจุดรับ-ส่งปลายทาง

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

Gustavo: หากคุณมีคำขอคุณลักษณะหรือแนวคิดเกี่ยวกับวิธีกำหนดค่าให้ดีขึ้น โปรดแจ้งปัญหาใน repo ของ Indexer-rs ได้เลย

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

#blockchaindataindex#web3dataanalytics#TheGraph