ERPC รองรับ HTTPS สำหรับ endpoint Solana Shreds และ Geyser gRPC แบบแชร์ — เลือก HTTPS หรือ HTTP ตาม use case

ERPC รองรับ HTTPS สำหรับ endpoint Solana Shreds และ Geyser gRPC แบบแชร์ — เลือก HTTPS หรือ HTTP ตาม use case

ERPC รองรับ HTTPS สำหรับ endpoint Solana Shreds และ Geyser gRPC แบบแชร์ — เลือก HTTPS หรือ HTTP ตาม use case
ELSOUL LABO B.V. (สำนักงานใหญ่: Amsterdam, Netherlands; CEO: Fumitake Kawasaki) และ Validators DAO ผู้ให้บริการ ERPC ได้เพิ่มการรองรับ HTTPS ให้กับ endpoint แบบแชร์ทั้ง Shreds gRPC และ Geyser gRPC ควบคู่กับ HTTP ที่เราให้บริการมาโดยตลอด ตอนนี้คุณจึงเลือกได้ระหว่าง HTTPS และ HTTP
การเปลี่ยนแปลงนี้ครอบคลุม Direct Shreds Connect และ Direct Shreds Turbo ในฝั่ง Shreds gRPC รวมถึงแพ็กเกจมาตรฐาน พรีเมียม และ Burst ของ Shared Geyser gRPC Stream
คุณสามารถเลือก endpoint HTTPS ที่เข้ารหัสและปลอดภัย หรือ endpoint HTTP ที่ไม่มีการประมวลผล TLS เลย ในทางศัพท์ของ gRPC แบบแรกคือ gRPC over TLS ส่วนแบบหลังคือ plaintext HTTP/2 ที่ไม่ใช้ TLS ทำให้รองรับ use case ได้กว้างขึ้นมาก ตั้งแต่งานที่ latency คือสิ่งเดียวที่สำคัญ ไปจนถึงงานที่ความลับของสิ่งที่คุณ subscribe สำคัญที่สุด
hostname ของ endpoint ไม่เปลี่ยนแปลง สิ่งที่ต่างกันมีเพียง scheme และ port เท่านั้น โดย HTTPS ใช้ port 443 ส่วน HTTP ใช้ port 80 คุณสลับระหว่างทั้งสองแบบได้ใน ERPC Web Dashboard

HTTPS คือสิ่งที่เพิ่มเข้ามา ส่วน HTTP เดิมยังให้บริการต่อไปเหมือนเดิม

endpoint stream แบบแชร์ของ ERPC ให้บริการผ่าน HTTP มาโดยตลอดจนถึงตอนนี้
สิ่งที่เพิ่มเข้ามาคือฝั่ง HTTPS การเชื่อมต่อ HTTP เดิมไม่มีการเปลี่ยนแปลงทั้งข้อกำหนดทางเทคนิคและพฤติกรรม และคุณใช้งานต่อได้เหมือนเดิมทุกประการ ลูกค้าที่เชื่อมต่อผ่าน HTTP อยู่แล้วไม่จำเป็นต้องดำเนินการใด ๆ
เราไม่มีแผนจะยกเลิก HTTP โดยยังคงให้บริการต่อไปในฐานะตัวเลือกสำหรับงานที่ให้ความสำคัญกับ latency เป็นอันดับแรก

HTTPS — การเชื่อมต่อที่เข้ารหัสและปลอดภัย

บน endpoint HTTPS การรับส่งข้อมูลทั้งหมดระหว่าง client ของคุณกับ ERPC จะถูกเข้ารหัสด้วย TLS
ทั้งเนื้อหาของ subscription request และข้อมูล stream ที่ส่งกลับมาหาคุณจะถูกเข้ารหัสด้วย TLS ดังนั้นโดยทั่วไปจึงไม่สามารถอ่านเนื้อหาของ payload บนเส้นทางได้ ใน ERPC Web Dashboard นั้น HTTPS เป็นวิธีการเชื่อมต่อที่ถูกเลือกไว้เป็นค่าเริ่มต้น
TLS handshake เกิดขึ้นเป็นหลักตอนสร้างการเชื่อมต่อ หลังจากนั้นการเข้ารหัสและถอดรหัสข้อมูล stream ยังคงดำเนินต่อไป แต่สำหรับ gRPC stream ที่เปิดค้างไว้เป็นเวลานาน จะไม่ต้องเสียต้นทุน handshake ซ้ำแล้วซ้ำอีก

HTTP — ตัวเลือก latency ต่ำที่ไม่มีการประมวลผล TLS

บน endpoint HTTP ไม่มี TLS handshake และไม่มีการประมวลผลเข้ารหัสหรือถอดรหัสใด ๆ เลย
ในการประมวลผลแบบ real-time ของ Solana ทุกการประมวลผลบนเส้นทางตั้งแต่จุดที่ข้อมูลถูกสร้างขึ้นไปจนถึงจุดที่แอปพลิเคชันของคุณได้รับ ล้วนส่งผลต่อ latency เนื่องจากไม่ต้องใช้การเข้ารหัสและถอดรหัส TLS การเชื่อมต่อแบบ HTTP จึงเหมาะกับงาน latency ต่ำที่ต้องการลดการประมวลผลบนเส้นทางให้มากที่สุด
HTTP ได้เปรียบในการตั้งค่าที่ต้องสร้างการเชื่อมต่อใหม่บ่อยครั้ง หรือการตั้งค่าที่ไม่สามารถยอมรับ overhead ใด ๆ บนเส้นทางได้เลย

เมื่อรูปแบบการรวมกลุ่มของ subscription filter มีความหมายในตัวเอง

HTTP เป็นตัวเลือกที่ latency ต่ำกว่า แต่ขึ้นอยู่กับวิธีที่แต่ละโปรเจกต์ใช้งาน กลุ่มของ address ที่ร้องขอจะถูกเปิดเผยบนเส้นทาง และสำหรับบางโปรเจกต์นั่นคือปัญหา
ข้อมูลบน blockchain นั้นเป็นข้อมูลสาธารณะอยู่แล้วในตัวมันเอง แต่เมื่อการรวมกลุ่มถูกเปิดเผย มันอาจมีความหมายที่ข้อมูลแต่ละรายการเพียงลำพังไม่เคยมี
สมมติว่าโปรเจกต์หนึ่งต้องการ filter และติดตาม wallet ของลูกค้าทุกรายของตน รายการ address ในคำขอ subscription นั้นเองก็อาจเป็นข้อมูลที่ละเอียดอ่อนสำหรับโปรเจกต์นั้น แม้ว่าแต่ละ address จะเป็นข้อมูลสาธารณะ แต่การรู้ว่ากลุ่ม address ใดถูกติดตามรวมกันเป็นชุดเดียว ก็อาจเป็นเบาะแสให้คาดเดาฐานลูกค้าของโปรเจกต์ สิ่งที่โปรเจกต์เฝ้าติดตาม และขอบเขตความสนใจทางธุรกิจได้
นี่คือจุดที่ endpoint HTTPS มีประโยชน์ โดยแลกกับการประมวลผลเข้ารหัสและถอดรหัสที่ TLS ต้องใช้ payload ของทั้งคำขอ subscription และข้อมูล stream จะถูกเข้ารหัส
latency มาก่อน หรือความลับของ subscription มาก่อน การตัดสินใจนี้แตกต่างกันไปในแต่ละโปรเจกต์ ตอนนี้ ERPC เปิดให้คุณเป็นผู้เลือกเองตาม use case ของคุณ

ขอบเขตคือ endpoint แบบแชร์

การรองรับ HTTPS ครั้งนี้ครอบคลุม endpoint แบบแชร์ต่อไปนี้
  • Direct Shreds Connect
  • Direct Shreds Turbo
  • Shared Geyser gRPC Stream — มาตรฐาน
  • Shared Geyser gRPC Stream — พรีเมียม
  • Shared Geyser gRPC Stream — Burst
เราเปิดใช้งาน HTTPS บน endpoint stream แบบแชร์ในทุก region แล้ว และยังคง endpoint HTTP เดิมไว้เหมือนเดิมทุกประการ endpoint แบบแชร์ที่รวมอยู่ใน Shreds Bundle และ ERPC Bundle ก็ใช้ HTTPS ได้เช่นกัน
endpoint เฉพาะ (Dedicated) ไม่ได้อยู่ในขอบเขตของการเปลี่ยนแปลงครั้งนี้ Dedicated Geyser gRPC และผลิตภัณฑ์ Shreds เฉพาะยังคงใช้วิธีการเชื่อมต่อเดิมโดยไม่มีการเปลี่ยนแปลง

สลับได้ใน Dashboard และใช้ IP allowlist ร่วมกัน

คุณสลับวิธีการเชื่อมต่อได้จากส่วนแสดง endpoint ใน ERPC Web Dashboard
สลับระหว่าง HTTPS กับ HTTP แล้วระบบจะแสดง URL ของ endpoint สำหรับวิธีการที่เลือก ให้ตั้งค่า client ของคุณด้วย URL ตามที่แสดงทุกประการ
ทั้งสองวิธีใช้ IP allowlist ที่ลงทะเบียนไว้ชุดเดียวกัน การยืนยันตัวตนยังคงอิงจาก IP address ที่ลงทะเบียนไว้เหมือนเดิม จึงไม่จำเป็นต้องลงทะเบียน IP ใหม่เพื่อย้ายไปใช้ HTTPS และไม่ต้องเพิ่ม token หรือ Authorization header ใด ๆ

ผลิตภัณฑ์ Shreds แบบแชร์ของ ERPC ยังให้บริการต่อไปหลัง Jito ShredStream สิ้นสุด

Jito ShredStream สิ้นสุดการให้บริการในวันที่ 5 กันยายน 2026 ในขณะที่ผลิตภัณฑ์ Shreds แบบแชร์ของ ERPC จะยังคงให้บริการต่อไปหลังจากวันดังกล่าว
ทั้ง Direct Shreds Connect และ Direct Shreds Turbo ที่ได้รับการรองรับ HTTPS ในครั้งนี้ รวมถึง แพ็กเกจหลาย IP ของ Shreds Bundle และ Direct Shreds Connect ที่รวมอยู่ในแพ็กเกจ ERPC Bundle ทั้งหมดยังคงใช้งานได้ต่อไปหลังวันที่ 5 กันยายน
เพื่อความชัดเจน การสิ้นสุดบริการวันที่ 5 กันยายนที่ประกาศไว้เมื่อวันที่ 21 สิงหาคม 2026 นั้นมีผลกับ ผลิตภัณฑ์ Shredstream เฉพาะและ Stream Bundle ผลิตภัณฑ์ Shreds แบบแชร์ไม่รวมอยู่ในการสิ้นสุดบริการดังกล่าว ส่วนคำแนะนำการย้ายสำหรับลูกค้าที่ใช้แพ็กเกจเฉพาะ เรายังคงดำเนินการเป็นรายกรณีเหมือนเดิม
หากคุณกำลังทบทวนว่าโปรเจกต์ของคุณรับ Shreds ด้วยวิธีใด นี่คือจังหวะที่เหมาะจะพิจารณาตัวเลือกต่าง ๆ เรายินดีอย่างยิ่งหากคุณจะได้ลองใช้งาน

ทดสอบด้วยค่าบริการรายชั่วโมง เริ่มต้นจาก 1 ชั่วโมง

endpoint แบบแชร์ของ ERPC เริ่มใช้งานได้ตั้งแต่ 1 ชั่วโมง โดยคิดค่าบริการเป็นรายชั่วโมง
โดยไม่ต้องผูกมัดกับแผนรายเดือน คุณสามารถทดลองทั้ง HTTPS และ HTTP กับ workload จริงของคุณ และตรวจสอบด้วยตัวเองว่า latency กับความลับของข้อมูลสมดุลกันอย่างไรในสภาพแวดล้อมของคุณเอง
เริ่มจากการทดสอบสั้น ๆ ก่อน แล้วจึงเลือกแผนจากผลที่คุณวัดได้

ผลิตภัณฑ์ UDP Forwarding โฉมใหม่จะเปิดตัวเร็ว ๆ นี้

สำหรับ UDP Forwarding ซึ่งทำให้เส้นทางการส่ง Shreds เองเรียบง่ายขึ้น ผลิตภัณฑ์โฉมใหม่จะเปิดตัวเร็ว ๆ นี้
เป้าหมายคือไลน์อัปที่คุณเลือกวิธีการส่งให้เหมาะกับงานได้ ได้แก่ UDP สำหรับงานที่ให้ความสำคัญกับ latency ต่ำเหนือสิ่งอื่นใด และ Shreds gRPC สำหรับ stream subscription ผ่าน gRPC interface ที่มีอยู่เดิม
region ที่รองรับ ราคา ข้อมูลจำเพาะโดยละเอียด และวันเปิดตัวอย่างเป็นทางการจะประกาศให้ทราบเมื่อพร้อม

สู่ infrastructure ที่เลือกได้ตามการใช้งาน

ERPC ไม่ได้ประเมินประสิทธิภาพของ infrastructure ของ Solana จาก spec ของ server เพียงอย่างเดียว ความใกล้ชิดกับแหล่งข้อมูล เส้นทาง network ฮาร์ดแวร์ OS และ kernel รวมถึงวิธีการส่งข้อมูลขั้นสุดท้ายไปยังผู้ใช้ ล้วนถูกออกแบบร่วมกันเป็นระบบ low-latency เดียว
การรองรับ HTTPS ครั้งนี้เป็นการขยายตัวเลือกในวิธีการส่งขั้นสุดท้ายนั้น ไม่มีตัวเลือกที่เร็วที่สุดเพียงหนึ่งเดียวที่เหมาะกับทุกโปรเจกต์ และการให้น้ำหนักระหว่าง latency กับความลับของข้อมูลมากน้อยเพียงใด ขึ้นอยู่กับลักษณะของผลิตภัณฑ์
หากมีข้อสงสัย โปรดติดต่อเราผ่าน support chat ใน ERPC Web Dashboard