ERPC ขยาย Solana Leader Slot API ด้วยการวัด Ping จาก 7 Region ทั่วโลก พร้อมเปิดตัว Validators Information API
ERPC ขยาย Solana Leader Slot API ด้วยการวัด Ping จาก 7 Region ทั่วโลก พร้อมเปิดตัว Validators Information API
ELSOUL LABO B.V. (สำนักงานใหญ่: Amsterdam, Netherlands; CEO: Fumitake Kawasaki) และ Validators DAO ผู้ให้บริการ ERPC ได้ปรับปรุง APIs สำหรับทำความเข้าใจข้อมูล leader ตำแหน่งโดยประมาณ และ latency ของ Solana โดยเพิ่มการรองรับ RTT อ้างอิง (การวัด ping) จาก 7 region ทั่วโลกให้แก่ Leader Slot API และเปิดตัว Validators Information API ใหม่
ประการแรก เราได้ขยาย Leader Slot API (
getLeaderSlots) ให้สามารถรับค่า RTT อ้างอิงจาก 7 region เฝ้าสังเกตของ ERPC ทั่วโลก (Frankfurt, Amsterdam, New York, London, Tokyo, Singapore และ Sydney) ก่อนหน้านี้การวัดทำจาก Frankfurt เพียงจุดเดียวพร้อมกันนี้ เราได้เปิดตัว Validators Information API (
getValidatorsInformation) ใหม่ API นี้แสดงรายการ validator ทุกตัวที่ถือ leader slot อย่างน้อยหนึ่ง slot ใน epoch ปัจจุบันด้วย call เดียว นอกเหนือจากจำนวน slot และ active stake แล้ว ยังคืนตำแหน่งโดยประมาณ, network endpoint, client version และ RTT อ้างอิงจาก 7 region ในกรณีที่มีข้อมูลทั้งสอง API พร้อมใช้งานสำหรับผู้ใช้ ERPC ทุกคนผ่าน standard JSON-RPC interface
- เอกสาร Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- เอกสาร Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
ความแตกต่างจาก Infrastructure การเทรดแบบดั้งเดิม: ใน Solana ปลายทางการสื่อสารเปลี่ยนแปลงแบบ Dynamic
ใน exchange และระบบการเงินแบบดั้งเดิม ปลายทางที่ส่งคำสั่งไป เช่น exchange, gateway, matching engine มักถูกกำหนดตายตัวอยู่กับ data center หรือ network เฉพาะ
ดังนั้นเมื่อผู้ใช้ทราบปลายทางการเชื่อมต่อแล้ว ก็สามารถ optimize เส้นทาง network ไปยังปลายทางนั้นได้อย่างต่อเนื่อง เนื่องจากตำแหน่งของ server เป้าหมายไม่เปลี่ยนบ่อย การวาง infrastructure และเส้นทางการสื่อสารจึงออกแบบแบบค่อนข้างคงที่ได้
ในทางกลับกัน ใน Solana, leader ซึ่งเป็น validator ที่รับผิดชอบการผลิต block จะสลับเปลี่ยนทุก ๆ ไม่กี่ slot ตาม leader schedule เนื่องจาก validator ที่ทำหน้าที่ leader กระจายอยู่ทั่วโลก ทั้งปลายทางที่ transaction ของคุณต้องไปถึงและเส้นทาง network ที่ใกล้ปลายทางนั้นที่สุดจึงเปลี่ยนแปลงอยู่ตลอดเวลา
กล่าวอีกนัยหนึ่ง ใน Solana ปลายทางการสื่อสารที่ต้อง optimize ไม่สามารถถือเป็นจุดเชื่อมต่อเดียวที่ตายตัวได้
คุณต้องระบุจาก leader schedule ก่อนว่า leader ปัจจุบันและอนาคตคือใคร จากนั้นจึงตรวจสอบว่า validator แต่ละตัวน่าจะอยู่ใน region หรือ network ใด และมี latency จากจุดส่งแต่ละจุดเท่าใด ก่อนตัดสินใจเลือกเส้นทางส่ง
การเข้าใจโครงสร้างนี้อย่างถูกต้องคือจุดเริ่มต้นของการส่ง transaction แบบ latency ต่ำและการออกแบบ infrastructure ระดับ global บน Solana
ใช้ Leader Schedule และตำแหน่ง Network เป็นข้อมูล
ในสภาพแวดล้อมที่ปลายทางเปลี่ยนแปลงแบบ dynamic การให้คนคอยตรวจสอบ leader และจุดส่งทุกครั้งแล้วสลับเส้นทางด้วยตนเองนั้นไม่ใช่เรื่องที่ทำได้จริง
สิ่งที่จำเป็นคือการรับข้อมูลต่อไปนี้อย่างต่อเนื่อง และนำไปฝังไว้ในตรรกะการตัดสินใจของ application และ infrastructure ของคุณ
- leader ที่รับผิดชอบ slot ปัจจุบันและที่กำลังจะมาถึง
- จำนวน slot ที่ validator แต่ละตัวรับผิดชอบ
- ประเทศ เมือง และ region โดยประมาณของ validator แต่ละตัว
- network endpoint เช่น TPU และ QUIC
- RTT อ้างอิงที่เก็บจาก region เฝ้าสังเกตแต่ละแห่ง
- เวลาที่ได้รับค่าการวัดแต่ละครั้งและสถานะการตอบกลับ
ตำแหน่งโดยประมาณและ latency ที่วัดได้มีบทบาทต่างกัน
ข้อมูลตำแหน่งใช้สำหรับการตัดสินใจระยะกลางถึงระยะยาวว่าควรวาง infrastructure และ capacity ไว้ที่ใด ส่วน RTT อ้างอิงจากแต่ละ region เป็น input สำหรับตัดสินใจว่าตอนนี้จากจุดใดมีแนวโน้มไปถึงได้ด้วยเส้นทางที่สั้น
ตำแหน่งที่ใกล้กันทางกายภาพหรือภูมิศาสตร์ไม่ได้เป็นเส้นทางที่สั้นที่สุดบน network เสมอไป ด้วยเหตุนี้ จึงสำคัญที่จะตัดสินใจโดยผสมผสานตำแหน่งโดยประมาณกับค่าที่สังเกตได้จริง
Leader Slot API และ Validators Information API ของ ERPC คือ APIs ที่ออกแบบมาให้คุณตั้งโปรแกรมการตัดสินใจเหล่านี้บนพื้นฐานของข้อมูลได้
Leader Slot API: วัด RTT อ้างอิงจาก 7 Region ทั่วโลก
Leader Slot API คืนข้อมูล leader slot ที่กำลังจะมาถึง พร้อมตัวตนของ validator, active stake, network endpoint, ตำแหน่งโดยประมาณ, RTT อ้างอิง และอื่น ๆ
จนถึงตอนนี้ การวัด
pingToLeaders ถูกเก็บจาก origin ที่ Frankfurt เพียงจุดเดียว ซึ่งเป็นจุดสังเกตเดียวบน network ของ Solana ที่กระจายทั่วโลกด้วยอัปเดตนี้ ตอนนี้คุณสามารถรับ RTT อ้างอิงที่วัดจาก 7 region ต่อไปนี้ได้
frankfurtamsterdamnylondontokyosingaporesydney
โดยการเปรียบเทียบ RTT อ้างอิงจาก 7 region เฝ้าสังเกตสำหรับ leader แต่ละตัว คุณสามารถตัดสินได้ว่าจากจุดส่งใดมีแนวโน้มไปถึงได้ด้วยเส้นทาง network ที่สั้น
สิ่งนี้เป็น input สำหรับการตัดสินใจไม่เพียงแต่การ route transaction เท่านั้น แต่ยังรวมถึงการตัดสินใจว่าจะวาง capacity ของ RPC, gRPC, Direct Shreds, transaction sending server และอื่น ๆ ไว้ที่ region ใด
ผลการวัดประกอบด้วย
icmpReplied ซึ่งบ่งชี้ว่า validator ตอบกลับ ICMP หรือไม่ และ measuredAt ซึ่งบ่งชี้เวลาที่ได้รับค่าการวัดที่สำเร็จครั้งล่าสุดvalidator ที่ไม่ตอบกลับ ICMP อาจยังให้บริการเช่น TPU และ QUIC ตามปกติ ด้วยเหตุนี้ เมื่อ
icmpReplied เป็น false ควรถือว่าไม่ใช่ “อยู่ไกล” แต่เป็น “วัดผ่าน ICMP ไม่ได้”นอกจากนี้ เมื่อไม่สามารถรับค่าการวัดที่สำเร็จได้ในขณะ refresh entry นั้นจะไม่ถูกเขียนทับด้วยค่าที่ไม่ได้วัด โดยจะเก็บค่าที่วัดสำเร็จครั้งล่าสุดพร้อมเวลาที่วัดไว้
Validators Information API: แสดงข้อมูล Leader ทั้ง Epoch ในรายการเดียว
Leader Slot API เหมาะกับการตัดสินใจระดับ slot — “ใครคือ leader ที่รับผิดชอบ slot ถัดไป?”
ในทางกลับกัน การวาง infrastructure และการวางแผน capacity ต้องการมุมมองที่กว้างกว่า
- validator ตัวใดเป็น leader ใน epoch ปัจจุบัน
- แต่ละตัวรับผิดชอบกี่ slot
- กระจายอยู่ในประเทศและ region ใดบ้าง
- ควรวาง infrastructure ไว้ที่ใดจึงจะเข้าใกล้ leader ได้มากขึ้น
Validators Information API (
getValidatorsInformation) ใหม่คือ API ที่สร้างขึ้นเพื่อตอบคำถามเหล่านี้เมื่อเรียกโดยไม่ระบุ parameter จะคืนข้อมูล validator ทุกตัวที่ทำหน้าที่ leader อย่างน้อยหนึ่ง slot ใน epoch ปัจจุบัน หนึ่งแถวต่อหนึ่ง validator โดยค่าเริ่มต้นผลลัพธ์จะเรียงจากจำนวน leader slot ที่ถือมากไปน้อย
แต่ละแถวมีข้อมูลดังต่อไปนี้
slotCountstakeWeight(จำนวน active stake ในหน่วย SOL)- ตัวตนของ validator
ในกรณีที่มีข้อมูล จะคืนข้อมูลเพิ่มเติมดังต่อไปนี้ด้วย
- region, เมือง และประเทศโดยประมาณ
- network endpoint
- client version
- RTT อ้างอิงจาก 7 region
เนื่องจากข้อมูลถูก refresh อย่างสม่ำเสมอ การเรียก API เป็นประจำจะช่วยให้ dataset สำหรับการวางแผนของคุณทันสมัยอยู่เสมอ
คุณยังสามารถจำกัดผลลัพธ์ให้แคบลงได้ด้วย optional parameter
limit (1–2000), country และ regionการคิดค่าบริการขึ้นอยู่กับจำนวน validator ที่คืนมา จำนวน leader validator จะแตกต่างกันไปในแต่ละ epoch ในตัวอย่าง ณ เวลาที่เขียนบทความนี้ การดึง validator ทั้ง 673 ตัวใช้ 6,800 API tokens (เครดิตการใช้งาน API ของ ERPC) และการดึงสูงสุด 10 validator ใช้ 100 API tokens
สู่ Routing แบบ Programmable ที่ขับเคลื่อนด้วยข้อมูล
APIs เหล่านี้ไม่ได้มีไว้เพียงเพื่อแสดงรายการ validator หรือ RTT อ้างอิง
เป้าหมายสุดท้ายคือการทำให้คุณสามารถฝัง leader schedule ตำแหน่งโดยประมาณของ validator และ RTT อ้างอิงจาก region เฝ้าสังเกตแต่ละแห่งไว้ในตรรกะการตัดสินใจของ application ของคุณ
ตัวอย่างเช่น application สามารถดึง leader schedule ที่กำลังจะมาถึง เปรียบเทียบ RTT อ้างอิงจาก 7 region เฝ้าสังเกตสำหรับ leader แต่ละตัว จากนั้นเลือก RPC หรือเส้นทางส่ง transaction ที่จะใช้
คุณยังสามารถวิเคราะห์การกระจายตัวของ leader ทั้ง epoch และวาง infrastructure ล่วงหน้าใน region ที่ใกล้กับ validator ที่มีจำนวน slot สูงได้
Use case หลักมีดังต่อไปนี้
- การเลือกเส้นทางส่งในระดับ slot
- การวางแผน capacity ในระดับ epoch
- การวิเคราะห์ leader validator ตาม region
- การจัดลำดับความสำคัญโดยพิจารณา active stake และจำนวน slot
- การเฝ้าสังเกตการเปลี่ยนแปลงของการกระจายตัวทางภูมิศาสตร์และ network ในแต่ละ epoch
- การเลือกอัตโนมัติระหว่าง RPC และ sending server ที่ deploy ไว้หลาย region
ใน Solana ที่ปลายทางเปลี่ยนแปลงแบบ dynamic การ optimize network แบบ static เพียงอย่างเดียวไม่เพียงพอ
สิ่งที่สำคัญคือการติดตาม leader ที่เปลี่ยนแปลงอย่างต่อเนื่อง และเลือกเส้นทางส่งและ infrastructure แบบ dynamic ตามตำแหน่งและสภาพ network ของ leader
สู่ Solana Infrastructure ที่ออกแบบมาเพื่อการดำเนินงานระดับ Global
ERPC คือ high-performance infrastructure สำหรับ Solana ออกแบบมาตั้งแต่วันแรกโดยคำนึงถึงการดำเนินงานระดับ global
edge network, บริการ bare metal และ VPS, Direct Shreds, Geyser gRPC, SWQoS endpoint และ operational intelligence APIs เหล่านี้ ล้วนให้บริการภายใต้เป้าหมายร่วมกัน
เป้าหมายนั้นคือการมอบทั้งข้อมูลและ infrastructure ให้แก่ builders ที่ต้องการ execution ที่ latency ต่ำและมีประสิทธิภาพ ในสภาพแวดล้อมที่ผู้ใช้และ leader กระจายอยู่ทั่วโลก
RTT อ้างอิงจาก 7 region ทั่วโลกและข้อมูล validator ทั้ง epoch สามารถรับได้ผ่าน RPC call ธรรมดาแล้ว ตอนนี้ Solana application สามารถเลือกจุดส่งและเส้นทาง network บนพื้นฐานของข้อมูล เพื่อตอบสนองต่อ leader ที่เปลี่ยนแปลงอยู่ตลอดเวลา
สำหรับ builders ที่ต้องการการส่งแบบ latency ต่ำ การวาง infrastructure ระดับ global และการ optimize routing แบบ dynamic บน Solana นี่คือข้อมูลประกอบการตัดสินใจที่เชื่อมโยงโดยตรงกับการปฏิบัติงานจริง
เราหวังว่าสิ่งนี้จะช่วยในการเลือกเส้นทางส่งแบบ latency ต่ำ การออกแบบ infrastructure ที่ลดการ transfer ระยะไกลที่ไม่จำเป็น และการวางแผน capacity ระดับ global
ดูรายละเอียดได้ในเอกสาร
- Leader Slot API: https://erpc.global/en/doc/rpc/leader-slot-api/
- Validators Information API: https://erpc.global/en/doc/rpc/validators-information-api/
- ERPC Web Dashboard: https://dashboard.erpc.global/en
ข่าว
