ERPC เปิดตัว Solana Stream SDK v4.0.0 เพิ่มความเร็วในการประมวลผล UDP Shreds และการกู้คืนการเชื่อมต่อ gRPC

ELSOUL LABO B.V. และ Validators DAO เปิดตัว Solana Stream SDK v4.0.0 อย่างเป็นทางการเมื่อวันที่ 6 พฤศจิกายน 2026 โดยเป็น SDK แบบโอเพนซอร์สสำหรับจัดการข้อมูลสตรีมมิงของ Solana ผลทดสอบประสิทธิภาพภายในเครื่องวัดได้ว่าความเร็วในการประมวลผลภายในของ Rust UDP Shreds อยู่ที่ประมาณ 108 เท่าของเดิม และอัตราประมวลผลคิวอีเวนต์ TypeScript อยู่ที่ประมาณ 4 เท่าของเดิม นอกจากนี้ Geyser gRPC ยังกลับมารับข้อมูลอัปเดตได้เร็วขึ้นหลังการเชื่อมต่อขาด SDK ใช้งานได้ฟรี พร้อมโค้ดตัวอย่าง Rust และ TypeScript เพื่อช่วยให้นักพัฒนาเริ่มต้นได้
การใช้ประโยชน์จากการส่งข้อมูลที่มีความหน่วงต่ำในแอปพลิเคชันยังขึ้นอยู่กับความเร็วในการประมวลผลข้อมูลที่เข้ามาด้วย เวอร์ชัน 4.0.0 เพิ่มประสิทธิภาพการประมวลผลภายในหลังข้อมูลมาถึง และปรับปรุงการกู้คืนเมื่อการเชื่อมต่อขาด การใช้งานร่วมกับ ERPC Shreds UDP Forwarding Premium ช่วยให้นักพัฒนาปรับปรุงได้ทั้งเส้นทางส่งข้อมูลและส่วนรับข้อมูลของแอปพลิเคชัน Solana
วัดผลการปรับปรุงการประมวลผลและการกู้คืนด้วยการทดสอบสามรายการ

ในเส้นทางรับข้อมูล UDP ของ Rust เวอร์ชัน 4 เพิ่มความเร็วในการดีโค้ดดาตาแกรม การแทรกข้อมูลลงในบัฟเฟอร์ภายใน และการทำ deshred ซึ่งประกอบข้อมูลขึ้นใหม่จาก Shreds การปรับขั้นตอนล้างสถานะภายในและอ่านนาฬิกาที่เดิมทำซ้ำสำหรับทุกแพ็กเก็ตช่วยลดภาระการประมวลผล โดยยังคงระยะเวลาเก็บรักษาข้อมูลไว้ตามเดิม ในการทดสอบเปรียบเทียบ เวลาประมวลผลภายในต่อดาตาแกรมลดลงจาก 94,236 ns เหลือ 855–881 ns คิดเป็นความเร็วประมาณ 108 เท่าของเดิม
การทดสอบประสิทธิภาพนี้ทำบน Mac ที่ใช้ชิป Apple M-series โดยแต่ละรอบประมวลผล 403,200 ดาตาแกรม ครอบคลุม 300 สล็อต และเปรียบเทียบผลด้วยค่ามัธยฐานจากการทดสอบห้ารอบ ขอบเขตการวัดคือเส้นทางประมวลผลภายใน decode→insert→deshred ไม่รวมเวลาส่งข้อมูลผ่านเครือข่ายหรือการประมวลผลขั้นถัดไปในแอปพลิเคชันของผู้ใช้ การลดงานที่จำเป็นสำหรับประกอบข้อมูลขึ้นใหม่จาก Shreds ที่ได้รับช่วยให้นักพัฒนาจัดสรรทรัพยากรคำนวณให้กับตรรกะของแอปพลิเคชันได้มากขึ้น
โค้ดตัวอย่างและโปรเจกต์เริ่มต้น Geyser gRPC ใน TypeScript ลดการรอขณะที่ยังมีอีเวนต์อยู่ในคิว ทำให้ดึงข้อมูลที่ได้รับออกมาได้อย่างมีประสิทธิภาพมากขึ้น ในการทดสอบเฉพาะคิวที่ประมวลผลสองล้านอีเวนต์บน Node.js 24 อัตราประมวลผลเพิ่มจาก 5.7–7.4 ล้านอีเวนต์ต่อวินาที เป็น 24.8–29.4 ล้านอีเวนต์ต่อวินาที หรือประมาณ 4 เท่าของเดิม
สำหรับ Geyser gRPC มีการอัปเดตไคลเอนต์ที่จัดการการเชื่อมต่อใหม่และช่วงเวลารอก่อนลองเชื่อมต่อซ้ำครั้งแรก ในการทดสอบที่ทำให้การเชื่อมต่อขาด 20 ครั้งบนเซิร์ฟเวอร์ tonic ภายในเครื่อง ค่ามัธยฐานของช่วงเวลาระหว่างข้อมูลอัปเดตที่รับก่อนและหลังการเชื่อมต่อขาดแต่ละครั้งลดจาก 552 ms เมื่อใช้ 3.0 runner เหลือ 103 ms เมื่อใช้ 4.0 runner ค่านี้เป็นการวัดช่วงเวลาจนกลับมารับข้อมูลอัปเดตได้ในสภาพแวดล้อมทดสอบภายในเครื่อง
ผลลัพธ์ทั้งสามมาจากการทดสอบที่มีขอบเขตและเงื่อนไขแตกต่างกัน โดยแสดงการปรับปรุงการประมวลผลภายในของ Rust คิวอีเวนต์ TypeScript และการเชื่อมต่อ gRPC ใหม่ตามลำดับ รายละเอียดการพัฒนาและเงื่อนไขการทดสอบเผยแพร่ไว้ใน PR #129 ที่ระบุในส่วนลิงก์ที่เกี่ยวข้อง
คงการรองรับ Alpenglow และอัปเดตไคลเอนต์
การรองรับ Alpenglow เริ่มตั้งแต่ v3.0.0 เวอร์ชัน 4.0.0 ยังคงแยกเครื่องหมายบล็อก ซึ่งแสดงการอัปเดตส่วนหัว ส่วนท้าย และบล็อกแม่ ออกจากรายการ entries ที่มีธุรกรรมอยู่ภายใน แอปพลิเคชันจึงสามารถจัดการข้อมูลโครงสร้างบล็อกแยกจาก entries ที่ต้องประมวลผลได้
เวอร์ชัน 4.0.0 อัปเดตไคลเอนต์เป็น Agave 4.4.1 และ Yellowstone gRPC 17.x ระหว่างการเชื่อมต่อใหม่ อีเวนต์
Disconnected สามารถรายงานข้อมูลที่ใช้ระบุชุดข้อมูลที่ยังรับมาไม่ครบ พร้อมตำแหน่งที่จะรับต่อได้ ข้อมูลนี้ช่วยให้แอปพลิเคชันนำไปพัฒนาวิธีจัดการข้อมูลที่ถูกส่งซ้ำและเกิดรายการซ้ำ รวมถึงข้อมูลที่รับมาเพียงบางส่วนได้เองการย้ายจาก v3 ไป v4 ยังคงนิยาม protobuf ของ Geyser ไว้ ขณะที่อัปเดตอีเวนต์เกี่ยวกับการเชื่อมต่อใหม่และชนิดข้อมูล Solana message กับ transaction ที่ใช้ใน Rust คู่มือการย้ายเวอร์ชันที่เผยแพร่แล้วอธิบายการเปลี่ยนแปลงของตัวจัดการอีเวนต์และเวอร์ชันของไลบรารีที่โปรเจกต์พึ่งพา
ใช้ Rust สำหรับ UDP หรือ Rust และ TypeScript สำหรับ gRPC
แพ็กเกจ Rust solana-stream-sdk และแพ็กเกจ TypeScript @validators-dao/solana-stream-sdk ที่เผยแพร่แล้วมีเวอร์ชัน v4.0.0 ให้ใช้ทั้งคู่ ภาษาที่รองรับสำหรับการเชื่อมต่อแต่ละรูปแบบมีดังนี้
| รูปแบบการเชื่อมต่อ | ภาษาที่รองรับ |
|---|---|
| Shreds UDP | Rust |
| Geyser gRPC | Rust และ TypeScript |
| Shreds gRPC | Rust และ TypeScript |
หากต้องการรับ Shreds ผ่าน UDP ให้ใช้ไคลเอนต์ Rust โค้ดตัวอย่างและโปรเจกต์เริ่มต้น Rust UDP ใช้ SDK v4.0.0 ที่เผยแพร่แล้ว และช่วยให้ทดลองรับข้อมูล ประกอบข้อมูลขึ้นใหม่จาก Shreds และตรวจจับคำสั่งของโปรแกรมที่ต้องการติดตามได้ คุณสามารถเปลี่ยนโปรแกรมที่ติดตามและขั้นตอนประมวลผลหลังตรวจจับ เพื่อใช้เป็นจุดเริ่มต้นของแอปพลิเคชันของคุณเอง
สำหรับการพัฒนาด้วย TypeScript สามารถใช้ Geyser gRPC หรือ Shreds gRPC ได้ การปรับปรุงคิวอีเวนต์ในรุ่นนี้รวมอยู่ในโค้ดตัวอย่างและโปรเจกต์เริ่มต้น Geyser gRPC แล้ว เลือกใช้โค้ดที่เผยแพร่ให้ตรงกับภาษาและวิธีส่งข้อมูลที่คุณใช้งาน
ใช้ประโยชน์จาก Shreds UDP Forwarding Premium
ERPC Shreds UDP Forwarding Premium เชื่อมหลายโหนดภายในแต่ละภูมิภาคเป็นเครือข่ายแบบเมช และส่งต่อสำเนาของแต่ละ Shred ที่เครือข่ายนี้ได้รับเป็นลำดับแรก ทั้งเวลาที่ข้อมูลมาถึงผ่านเส้นทางส่งข้อมูลและเวลาประกอบข้อมูลขึ้นใหม่ภายใน SDK หลังจากนั้น ล้วนส่งผลต่อเวลาที่ข้อมูลที่ได้รับจะพร้อมใช้งาน การปรับปรุงการรับ UDP ใน Rust สามารถนำมาใช้ฝั่งรับเพื่อประมวลผลข้อมูลที่ส่งมาจาก Premium ได้
ในการเปรียบเทียบที่แฟรงก์เฟิร์ตเมื่อวันที่ 30 ตุลาคม 2026 มีการจับข้อมูลจาก Standard และ Premium พร้อมกันเป็นเวลา 120 วินาทีบนเครื่องเดียวกันและใช้แหล่งนาฬิกาเดียวกัน จากนั้นนำเพย์โหลด UDP ที่มีเนื้อหาตรงกันใน pcap มาจับคู่ ในชุดข้อมูลที่จับคู่นี้ Premium มาถึงก่อนใน 98% ของกรณี และค่ามัธยฐานของผลต่างเวลาที่มาถึงอยู่ที่ 1.78 ms ส่วนเพย์โหลดที่ตรวจพบใน Standard มี 93.9% ที่ตรวจพบใน Premium ด้วยเช่นกัน

ภาพของ Premium แสดงผลต่างเวลาที่ข้อมูลมาถึงระหว่างเส้นทางส่งข้อมูล ส่วนภาพของ SDK แสดงการประมวลผลภายในฝั่งรับและการกู้คืนการเชื่อมต่อ ในแอปพลิเคชันจริง การบันทึกทั้งเวลาที่แพ็กเก็ตมาถึงและเวลาที่ตรวจพบคำสั่งที่เกี่ยวข้องช่วยให้ตรวจสอบได้ว่า ข้อได้เปรียบด้านเวลาส่งข้อมูลส่งต่อไปถึงผลการประมวลผลมากเพียงใด
เปรียบเทียบในสภาพแวดล้อมของคุณด้วยการคิดค่าบริการรายชั่วโมงและโค้ดตัวอย่าง
Shreds UDP Forwarding Premium มีบริการแบบคิดค่าบริการรายชั่วโมงในราคา €1.39 ต่อชั่วโมง เริ่มใช้งานได้จากแดชบอร์ด และตรวจสอบการรับข้อมูลด้วยโปรเจกต์เริ่มต้น Rust UDP การใช้ภูมิภาค เซิร์ฟเวอร์รับข้อมูล และภาระงานของแอปพลิเคชันเดียวกันช่วยให้ประเมินผลต่างเวลาที่ข้อมูลมาถึงแยกจากเวลาประมวลผลหลังรับข้อมูลได้
ขั้นแรก ลงทะเบียนที่อยู่ IPv4 สาธารณะและพอร์ต UDP ในแดชบอร์ด แล้วอนุญาตทราฟฟิกขาเข้าจากต้นทางที่แสดงไว้ เมื่อใช้โปรเจกต์เริ่มต้น Rust UDP ตรวจสอบการรับแพ็กเก็ตและการประกอบข้อมูลขึ้นใหม่แล้ว ให้เพิ่มโปรแกรมที่ต้องการติดตามและขั้นตอนประมวลผลจริงของแอปพลิเคชันเข้าไปในการประเมิน ใช้โค้ดตัวอย่างร่วมกับบริการส่งข้อมูลเพื่อวัดเวลาตั้งแต่รับข้อมูลจนถึงการตรวจจับในสภาพแวดล้อมของคุณเอง
ลิงก์ที่เกี่ยวข้อง
- โค้ดตัวอย่างและโปรเจกต์เริ่มต้น Rust UDP: https://github.com/ValidatorsDAO/solana-stream/tree/main/temp-release/shreds-udp-rs
- คู่มือการย้ายไปใช้ Solana Stream SDK v4: https://github.com/ValidatorsDAO/solana-stream/blob/main/docs/migration-v4.md
- การปรับปรุงประสิทธิภาพ SDK และบันทึกการทดสอบ: https://github.com/ValidatorsDAO/solana-stream/pull/129
- เอกสาร Shreds UDP Forwarding: https://erpc.global/th/doc/shredstream/udp-forwarding/
- ใช้งาน Shreds UDP Forwarding Premium: https://dashboard.erpc.global/th/user/shreds?plan=udp
- ราคา ERPC: https://erpc.global/th/price/









