Understanding Solana Data Streams and Protocols (Shreds, gRPC, WS, UDP)
Understanding Solana Data Streams and Protocols (Shreds, gRPC, WS, UDP)
Cuando usted piensa en hacer su aplicación Solana o estrategia de trading más rápido, las primeras cosas a aclarar no son el código o las especificaciones del servidor.
El punto de partida es dos preguntas fundamentales.
El punto de partida es dos preguntas fundamentales.
Primero, ¿qué tan lejos estás de los validadores de Solana que te importan?
¿En qué región vive tu aplicación, y cuántos milisegundos se necesita para llegar a un validador desde allí? Esta distancia es la base de todo. Si la distancia es incorrecta, ninguna cantidad de software o optimización de hardware desbloqueará el rendimiento que debe ser posible.
¿En qué región vive tu aplicación, y cuántos milisegundos se necesita para llegar a un validador desde allí? Esta distancia es la base de todo. Si la distancia es incorrecta, ninguna cantidad de software o optimización de hardware desbloqueará el rendimiento que debe ser posible.
Segundo, ¿dónde está el validador líder en un momento dado?
Cuando Frankfurt es el líder, los nodos cerca de Frankfurt están estructuralmente favorecidos. Cuando Tokio es el líder, los nodos cerca de Tokio son favorecidos. Los líderes de Solana giran alrededor del globo slot por slot. Mientras exista esta propiedad, una configuración de una sola región siempre tendrá ventanas de tiempo donde está físicamente desfavorecida.
Cuando Frankfurt es el líder, los nodos cerca de Frankfurt están estructuralmente favorecidos. Cuando Tokio es el líder, los nodos cerca de Tokio son favorecidos. Los líderes de Solana giran alrededor del globo slot por slot. Mientras exista esta propiedad, una configuración de una sola región siempre tendrá ventanas de tiempo donde está físicamente desfavorecida.
En la práctica, esto significa que una estrategia realista debe ser multiregión.
Al colocar la infraestructura en múltiples lugares como Frankfurt, Amsterdam, Nueva York, Chicago, Tokio y Singapur, se puede observar la cadena desde una región cercana al líder actual o próximo en cada banda de tiempo.
Al colocar la infraestructura en múltiples lugares como Frankfurt, Amsterdam, Nueva York, Chicago, Tokio y Singapur, se puede observar la cadena desde una región cercana al líder actual o próximo en cada banda de tiempo.
Con ese contexto físico y de programación establecido, podemos hablar de las secuencias de datos de Solana. En este artículo nos centramos en tres que los desarrolladores a menudo encuentran:
- WebSocket (WS)
- Geyser gRPC
- Shredstream (Rip Shreds)
Vamos a ver qué momento de los datos cada uno ve, qué características de transporte tienen, y qué son realmente buenos para.
El objetivo no es escoger algo porque “el nombre suena rápido”, sino entender cómo funciona Solana y cómo se comportan los protocolos subyacentes, luego conectarlo a la actuación de la aplicación y UX de una manera concreta.
El objetivo no es escoger algo porque “el nombre suena rápido”, sino entender cómo funciona Solana y cómo se comportan los protocolos subyacentes, luego conectarlo a la actuación de la aplicación y UX de una manera concreta.
Tener diferencias en cómo fluyen los datos de Solana
El primer paso es entender cuando, en el pipeline interno de Solana, aparecen diferentes tipos de datos.
En términos generales, hay tres etapas útiles para razonar sobre el rendimiento.
En términos generales, hay tres etapas útiles para razonar sobre el rendimiento.
La primera etapa es Shreds.
Los validadores intercambian Shreds sobre UDP para construir bloques. Durante este intercambio, lo que fluye sobre la red es datos que aún no se han montado completamente en un bloque. Si puede pulsar en esta etapa, puede ver cambios en la cadena lo antes posible. El tradeoff es que, porque esto es UDP, usted debe asumir la pérdida de paquetes y salidas fuera de orden y diseñar su sistema en consecuencia.
Los validadores intercambian Shreds sobre UDP para construir bloques. Durante este intercambio, lo que fluye sobre la red es datos que aún no se han montado completamente en un bloque. Si puede pulsar en esta etapa, puede ver cambios en la cadena lo antes posible. El tradeoff es que, porque esto es UDP, usted debe asumir la pérdida de paquetes y salidas fuera de orden y diseñar su sistema en consecuencia.
La segunda etapa es Geyser gRPC.
Después de que un validador haya recibido Shreds y formado y confirmado un bloque, puede exponer los resultados en una forma estructurada a través de plugins Geyser. Aquí es donde Geyser gRPC Los flujos provienen de: emiten eventos como bloques, registros y actualizaciones de cuentas. El tiempo es un paso más tarde que Shreds, pero los datos ya están organizados, lo que hace que sea mucho más fácil para las aplicaciones consumir.
Después de que un validador haya recibido Shreds y formado y confirmado un bloque, puede exponer los resultados en una forma estructurada a través de plugins Geyser. Aquí es donde Geyser gRPC Los flujos provienen de: emiten eventos como bloques, registros y actualizaciones de cuentas. El tiempo es un paso más tarde que Shreds, pero los datos ya están organizados, lo que hace que sea mucho más fácil para las aplicaciones consumir.
La tercera etapa es HTTP RPC y WebSocket.
Una vez que los datos han pasado por Geyser y otro tratamiento interno y se ha escrito a las tiendas internas del nodo, se pone a disposición a través de JSON-RPC y WebSocket notificaciones. Métodos como getBalance, getProgramAccounts, y las suscripciones de registro están leyendo desde este estado almacenado. En términos de tiempo, esto se encuentra detrás de las notificaciones de Geyser y es el más alto “público API capa” que la mayoría de las aplicaciones ven primero.
Una vez que los datos han pasado por Geyser y otro tratamiento interno y se ha escrito a las tiendas internas del nodo, se pone a disposición a través de JSON-RPC y WebSocket notificaciones. Métodos como getBalance, getProgramAccounts, y las suscripciones de registro están leyendo desde este estado almacenado. En términos de tiempo, esto se encuentra detrás de las notificaciones de Geyser y es el más alto “público API capa” que la mayoría de las aplicaciones ven primero.
Resumiendo estas tres etapas:
- Los fragmentos son datos brutos muy cercanos al momento de la propagación.
- Geyser gRPC proporciona datos estructurados en el punto donde se confirman los bloques.
- RPC / WebSocket exponer los datos almacenados APIsi te preguntas después del hecho.
La etapa que observas determina lo temprano que puedes detectar cambios en la cadena. Esa diferencia de tiempo por sí sola ya crea una brecha de rendimiento significativa.
Características del transporte: UDP, gRPC, WebSocket, y TLS
El tiempo es un eje. El segundo eje es cómo los datos son realmente transportados.
Los arbustos usan UDP.
UDP tiene pequeños encabezados y no requiere configuración de conexión. No proporciona garantías de retransmisión o ordenación, pero a cambio minimiza la latencia. Para algo como Shreds, donde los datos se propagan redundantemente entre muchos validadores, esta sencillez y velocidad es exactamente lo que desea.
UDP tiene pequeños encabezados y no requiere configuración de conexión. No proporciona garantías de retransmisión o ordenación, pero a cambio minimiza la latencia. Para algo como Shreds, donde los datos se propagan redundantemente entre muchos validadores, esta sencillez y velocidad es exactamente lo que desea.
Geyser gRPC se ejecuta sobre TCP usando un protocolo binario.
Streaming RPC, compresión de cabecera y codificación binaria le permiten mover datos más eficientemente que HTTP+JSON típico. Es muy adecuado para el consumo continuo de eventos estructurados en backends, sistemas de monitoreo y tuberías de análisis.
Streaming RPC, compresión de cabecera y codificación binaria le permiten mover datos más eficientemente que HTTP+JSON típico. Es muy adecuado para el consumo continuo de eventos estructurados en backends, sistemas de monitoreo y tuberías de análisis.
WebSocket típicamente se sienta encima de TCP más TLS, con cargas de pago JSON.
La ventaja clave es que los navegadores y las pilas web estándar pueden utilizarlo directamente, por lo que está en todas partes en dApps y bots ligeros. La desventaja es que el texto JSON debe ser analizado, y los encabezados más cifrado añadir sobrecabeza. Entre los tres, éste tiende a ser el patrón más pesado.
La ventaja clave es que los navegadores y las pilas web estándar pueden utilizarlo directamente, por lo que está en todas partes en dApps y bots ligeros. La desventaja es que el texto JSON debe ser analizado, y los encabezados más cifrado añadir sobrecabeza. Entre los tres, éste tiende a ser el patrón más pesado.
Además, TLS añade otra capa de costo.
Cuando utiliza https, wss o gRPC-TLS, cada conexión debe realizar un apretón de manos y encriptar y descifrar cargas de pago. Para las aplicaciones web generales esto es generalmente aceptable y ni siquiera notado. Para estrategias donde decenas de milisegundos importan para UX o PnL, la cabeza es notable.
Cuando utiliza https, wss o gRPC-TLS, cada conexión debe realizar un apretón de manos y encriptar y descifrar cargas de pago. Para las aplicaciones web generales esto es generalmente aceptable y ni siquiera notado. Para estrategias donde decenas de milisegundos importan para UX o PnL, la cabeza es notable.
El punto importante es que:
- El momento de ver los datos (Shreds / Geyser / RPC)
- La forma en que lo transportas (UDP / gRPC / WebSocket / TLS)
son preocupaciones separadas, pero ambos tienen una fuerte influencia en su latencia final y UX.
Poner velocidad en contexto: tiempo y transporte
Con esas piezas en su lugar, puede razonar sobre la velocidad más concretamente.
Desde el punto de vista del tiempo:
- Los arbustos ven la primera etapa.
- Geyser gRPC viene después.
- RPC / WebSocket Ven el último.
Desde el punto de vista del transporte:
- UDP es el más ligero y más rápido.
- gRPC sobre TCP es el siguiente, con un flujo binario eficiente.
- WebSocket con JSON y TLS es generalmente el más pesado.
Si usted normaliza para “la misma región, el mismo hardware, el mismo camino de red”, el orden de velocidad técnica es:
- UDP (Shreds)
- gRPC (Geyser)
- WebSocket (JSON)RPC notificaciones)
Por supuesto, esta es la velocidad en aislamiento. En sistemas reales no puedes mirar sólo la latencia. También tiene que considerar la fiabilidad, los requisitos de corrección, el costo del desarrollo y la complejidad que su equipo puede absorber.
Costo de fiabilidad y desarrollo: por qué WS gRPC " UDP in practice
En muchos proyectos reales, el orden en que se adoptan las secuencias de datos es casi la inversa del ranking de velocidad técnica:
- Primera WebSocket
- Entonces... Geyser gRPC
- Finalmente Shreds / UDP
Esto no es un accidente.
Los fragmentos (UDP) son los más rápidos pero requieren que usted diseña para datos perdidos y fuera de orden desde el principio.
Usted no puede asumir que cada paquete llega y que todos los datos están perfectamente alineados. Su lógica debe manejar las brechas, reconciliarse con otras corrientes si es necesario, y tolerar el ruido. El pago es latencia mínima, pero la ejecución y las operaciones se vuelven significativamente más difíciles.
Usted no puede asumir que cada paquete llega y que todos los datos están perfectamente alineados. Su lógica debe manejar las brechas, reconciliarse con otras corrientes si es necesario, y tolerar el ruido. El pago es latencia mínima, pero la ejecución y las operaciones se vuelven significativamente más difíciles.
Geyser gRPC le da datos que ya han sido confirmados y estructurados dentro del nodo.
Eso hace mucho más fácil consumir. Los backends impulsados por eventos, sistemas de alerta, análisis en cadena y indexadores pueden construir en Geyser con un buen equilibrio de velocidad, fiabilidad y esfuerzo de implementación. Para muchos equipos, este es el segundo paso natural una vez WebSocket- Sólo las configuraciones alcanzan sus límites.
Eso hace mucho más fácil consumir. Los backends impulsados por eventos, sistemas de alerta, análisis en cadena y indexadores pueden construir en Geyser con un buen equilibrio de velocidad, fiabilidad y esfuerzo de implementación. Para muchos equipos, este es el segundo paso natural una vez WebSocket- Sólo las configuraciones alcanzan sus límites.
WebSocket’s principal ventaja es que se conecta directamente a los navegadores y la infraestructura web normal.
dApp frontends y servicios ligeros pueden utilizarlo con herramientas y bibliotecas existentes, y las muestras de código están ampliamente disponibles. Para enviar una primera versión de su producto, WebSocket es a menudo el punto de partida más práctico, especialmente si ya ha resuelto el problema de la “distancia a los validadores”.
dApp frontends y servicios ligeros pueden utilizarlo con herramientas y bibliotecas existentes, y las muestras de código están ampliamente disponibles. Para enviar una primera versión de su producto, WebSocket es a menudo el punto de partida más práctico, especialmente si ya ha resuelto el problema de la “distancia a los validadores”.
Así que en teoría, la orden de velocidad es UDP √ gRPC - ¿Qué?
En la práctica, el pedido de adopción es por lo general WS gRPC UDP.
Usted necesita tener ambos ejes en mente y elegir basado en su fase actual y metas en lugar de perseguir una etiqueta abstracta "rápida".
En la práctica, el pedido de adopción es por lo general WS gRPC UDP.
Usted necesita tener ambos ejes en mente y elegir basado en su fase actual y metas en lugar de perseguir una etiqueta abstracta "rápida".
¿Cómo escorias y Geyser gRPC trabajar juntos
Una vez que va más allá de la afinación básica de la velocidad y empieza a preocuparse por cada decenas de milisegundos, la pregunta clave se convierte en cómo combinar los fragmentos y Geyser gRPC.
Los arbustos son por ser el primero en darse cuenta.
Si puedes recibir a Shreds cerca del líder actual, puedes detectar cambios en la cadena de decenas a cientos de milisegundos antes que alguien viendo sólo a Geyser o RPCPara las estrategias donde esa brecha se traduce directamente en PnL, esto importa mucho. El cambio es que aceptas ruido y diseño para ello.
Si puedes recibir a Shreds cerca del líder actual, puedes detectar cambios en la cadena de decenas a cientos de milisegundos antes que alguien viendo sólo a Geyser o RPCPara las estrategias donde esa brecha se traduce directamente en PnL, esto importa mucho. El cambio es que aceptas ruido y diseño para ello.
Geyser gRPC es para confirmar y razonar correctamente.
En el tiempo de confirmación de bloqueo, Geyser emite registros, cambios de cuenta y otros eventos estructurados. Usted puede conectar estos en su lógica de estrategia, controles de riesgo, indexadores y sistemas de monitoreo. Es más lento que Shreds, pero los datos son consistentes y mucho más fáciles de razonar.
En el tiempo de confirmación de bloqueo, Geyser emite registros, cambios de cuenta y otros eventos estructurados. Usted puede conectar estos en su lógica de estrategia, controles de riesgo, indexadores y sistemas de monitoreo. Es más lento que Shreds, pero los datos son consistentes y mucho más fáciles de razonar.
Un patrón común en el campo es:
- Use Shreds para detectar oportunidades y reunir transacciones de candidatos lo antes posible.
- Uso Geyser gRPC simultáneamente para verificar bloques y registros y para conducir su lógica principal y monitoreo.
Esta separación le permite empujar latencia mientras mantiene su decisión basada en datos estables y verificables.
TLS, endpoints compartidos y nodos dedicados
Hasta ahora hemos asumido el nodo y la red subyacentes son los mismos. En realidad, hay otra diferencia estructural masiva: si usted está usando un endpoint compartido o un nodo dedicado.
Un endpoint compartido es utilizado por muchos inquilinos a la vez.
Está expuesta sobre el Internet público, y el tráfico pasa por un perímetro de seguridad. El cifrado es obligatorio; simplemente no puede apagar TLS. El costo de encriptación, descifrado y apretones de manos es perfectamente aceptable para el uso normal de dApp, pero aparece si usted está tratando de afeitar cada posible milisegundos en un contexto de estilo HFT.
Está expuesta sobre el Internet público, y el tráfico pasa por un perímetro de seguridad. El cifrado es obligatorio; simplemente no puede apagar TLS. El costo de encriptación, descifrado y apretones de manos es perfectamente aceptable para el uso normal de dApp, pero aparece si usted está tratando de afeitar cada posible milisegundos en un contexto de estilo HFT.
Un nodo dedicado está reservado para un solo inquilino.
Debido a que puede restringir el acceso por dirección IP y aislar el medio ambiente, usted gana la opción deshabilitar TLS y utilizar HTTP o texto sin formato gRPC. Tampoco comparte CPU, memoria, Discord I/O, o ancho de banda de red con otros clientes, por lo que su latencia no salta porque alguien más está ejecutando una pesada carga de trabajo en la misma máquina.
Debido a que puede restringir el acceso por dirección IP y aislar el medio ambiente, usted gana la opción deshabilitar TLS y utilizar HTTP o texto sin formato gRPC. Tampoco comparte CPU, memoria, Discord I/O, o ancho de banda de red con otros clientes, por lo que su latencia no salta porque alguien más está ejecutando una pesada carga de trabajo en la misma máquina.
Si manejas tus Shreds, Geyser gRPC, y RPC todo en los nodos dedicados, todas estas corrientes operan en un ambiente aislado de otros inquilinos y de la sobrecarga TLS.
Esta combinación es lo que hace que las configuraciones dedicadas alcancen rangos de latencia que los endpoints compartidos, por diseño, no pueden alcanzar incluso con el mismo hardware.
Esta combinación es lo que hace que las configuraciones dedicadas alcancen rangos de latencia que los endpoints compartidos, por diseño, no pueden alcanzar incluso con el mismo hardware.
Existen nodos compartidos para ofrecer un rendimiento sólido para muchos usuarios.
Los nodos dedicados existen para empujar los límites cuando realmente necesita el camino más rápido posible.
Los nodos dedicados existen para empujar los límites cuando realmente necesita el camino más rápido posible.
Multi-región y dedicadas Shreds (UDP forwarding)
Volviendo a la distancia y a la posición de líder, mientras los líderes de Solana giran alrededor del mundo, una configuración de una sola lista nunca puede ser la más rápida en todas partes, todo el tiempo.
Aquí es donde entran las configuraciones de triregión.
Se combinan las trituraciones dedicadas (primas de premio, trituraciones estándar, trituraciones de metal, ediciones limitadas y líneas similares):
- UDP delivery of Shreds as rapid as possible
- Servidores dedicados con mínimo jitter
Mediante el despliegue de Shreds dedicados en múltiples regiones como Frankfurt, Amsterdam, Nueva York, Chicago, Tokio y Singapur, puede recibir Shreds cerca del líder, independientemente de cuál región está actualmente favorecida.
Un patrón común es suscribirse a múltiples alimentaciones de Shreds de diferentes regiones al mismo tiempo y sólo actuar en el que llega primero.
Esto reduce el impacto de la latencia larga y la congestión regional y le permite aproximarse “siempre cerca del líder” de una manera práctica.
Esto reduce el impacto de la latencia larga y la congestión regional y le permite aproximarse “siempre cerca del líder” de una manera práctica.
Para hacer más accesibles los fragmentos dedicados multiregión, ERPC proporciona cupones de descuento para uso multiregión:
- 2 regiones: 5% de descuento
- 3 regiones: 8% de descuento
- 5 regiones: 10% de descuento
- Todas las regiones: 15% de descuento
Esto hace que sea más fácil diseñar configuraciones en las que pongas los más altos niveles de Shreds (por ejemplo, Premium o Metal) en las regiones más competitivas, y utilice opciones más rentables en las regiones de soporte, al tiempo que logra una amplia cobertura.
Compartida Shredstream Bundles: una on-ramp más amplia en Shreds
Antes de comprometerse con Shreds completamente dedicados en todas partes, una multi-región Compartida Shredstream La configuración puede ser un paso intermedio muy práctico.
Compartida Shredstream Los envases te permiten consumir fragmentos compartidos de varias regiones bajo un solo plan.
Internamente, Compartida Shredstream toma datos de la capa Shreds (UDP) y se lo entrega a través de gRPC. La fuente es todavía Criados, por lo que usted ve la información un paso antes que Geyser gRPC, mientras se beneficia de la conveniencia gRPC streaming.
Internamente, Compartida Shredstream toma datos de la capa Shreds (UDP) y se lo entrega a través de gRPC. La fuente es todavía Criados, por lo que usted ve la información un paso antes que Geyser gRPC, mientras se beneficia de la conveniencia gRPC streaming.
En términos de cómo las capas se alinean:
- Shreds dedicados a través del reenvío UDP son los más rápidos, más cercanos a la propagación.
- Compartida Shredstream es un gRPC flujo derivado de Shreds, sentado justo encima de eso.
- Geyser gRPC viene después de eso, en el momento de confirmación de bloque.
Compartida Shredstream Los envases incluyen la lista blanca IP, 10 conexiones y el enrutamiento automático al borde más cercano. Esto mantiene costos razonables al tiempo que le permite utilizar datos obtenidos por Shreds simultáneamente en regiones como Asia, América del Norte y Europa.
En lugar de saltar directamente a los fragmentos dedicados en cada región, usted puede:
- Comience con un Shared Shredstream Agrupar para obtener experiencia práctica con datos basados en Shreds.
- Utilice los registros y los datos de rendimiento para entender dónde marca la mayor diferencia.
- Migrar regiones de alto impacto a Shreds dedicados una vez que tenga evidencia y un caso de negocio claro.
Medidas prácticas por fase de desarrollo
Poniendo todo esto juntos, es más fácil pensar en términos de fases.
En la fase 1, elegir la región correcta y la distancia, luego construir su dApp o bot utilizando RPC y WebSocket.
Obtener la región y la ubicación de la red derecha a menudo produce grandes mejoras UX incluso antes de tocar Shreds o gRPC. Para lanzar un producto, WebSocket es una elección muy racional, especialmente desde el frontend.
Obtener la región y la ubicación de la red derecha a menudo produce grandes mejoras UX incluso antes de tocar Shreds o gRPC. Para lanzar un producto, WebSocket es una elección muy racional, especialmente desde el frontend.
En la fase 2, añadir Geyser gRPC para fortalecer backends, monitoreo y análisis.
Geyser gRPC le permite consumir bloques, registros y eventos de cuenta eficientemente y construir indexadores robustos, sistemas de alerta y externos APIarriba de ellos. Huelga un buen equilibrio entre la velocidad, la fiabilidad y el costo del desarrollo y es un “segundo paso” natural para muchos equipos.
Geyser gRPC le permite consumir bloques, registros y eventos de cuenta eficientemente y construir indexadores robustos, sistemas de alerta y externos APIarriba de ellos. Huelga un buen equilibrio entre la velocidad, la fiabilidad y el costo del desarrollo y es un “segundo paso” natural para muchos equipos.
En la fase 3, ingrese Shreds y UDP, donde las diferencias de latencia afectan directamente a PnL o UX.
Mediante el despliegue de Shreds dedicados en múltiples regiones y el uso de descuentos multiregión, puede entrar en la banda de latencia requerida para HFT, MEV, y estrategias de 0 slot sin diseñar todo desde cero en una sola toma.
Mediante el despliegue de Shreds dedicados en múltiples regiones y el uso de descuentos multiregión, puede entrar en la banda de latencia requerida para HFT, MEV, y estrategias de 0 slot sin diseñar todo desde cero en una sola toma.
El punto clave no es “UDP es teóricamente más rápido, así que utiliza sólo UDP en todas partes”.
La clave es mirar tu fase y tu economía, luego decidir dónde y cuándo invertir en Shreds e infraestructura dedicada realmente mueve la aguja.
La clave es mirar tu fase y tu economía, luego decidir dónde y cuándo invertir en Shreds e infraestructura dedicada realmente mueve la aguja.
Uso ERPC Bundles y VPS como fundamento
El ERPC Los planes de los grupos están diseñados para darle una base completa:
- RPC (HTTP / WebSocket)
- Geyser gRPC
- Compartida Shredstream gRPC
todo bajo una sola estructura.
Usted puede seguir utilizando RPC y WebSocket como su interfaz de producción principal, mientras experimenta con Geyser gRPC y Shredstream en la misma red.
Debido a que todo funciona en una infraestructura unificada, puede comparar el comportamiento y el rendimiento directamente y tomar decisiones basadas en mediciones reales en lugar de hipótesis.
Debido a que todo funciona en una infraestructura unificada, puede comparar el comportamiento y el rendimiento directamente y tomar decisiones basadas en mediciones reales en lugar de hipótesis.
Además de eso, puedes combinar esto con VPS líneas que viven dentro de la misma ERPC red, como EPYC VPS y Premium Ryzen VPS.
Esto te permite sintonizar, en un lugar:
- Distancia a los validadores Solana
- Elección de flujos de datos (WS, gRPC, Shreds)
- Rendimiento de hardware
Un enfoque práctico es asegurar primero las regiones y ERPC Bundle + VPS cimiento, luego enciende capas más rápidas (Geyser, Criados Compartidos, Criados dedicados) a medida que sus necesidades y economía evolucionan.
Conclusión: diseño del rendimiento de Solana desde el momento, el transporte y la distancia
El rendimiento y el UX de una aplicación Solana provienen de una combinación de factores:
- Donde se encuentran sus servidores
- Qué cerca estás del líder en cada banda de tiempo
- En qué momento recibes datos en cadena
- Que transporte y protocolo utiliza
- Cómo tu lógica de aplicación reacciona encima de eso
Distancia y posición de líder forman la base. Por encima de eso tienes:
- Criaturas para la primera etapa
- Geyser gRPC para datos confirmados y estructurados
- RPC / WebSocket para acceder al estado almacenado APIs
Y en el lado del transporte tienes:
- UDP
- gRPC TCP
- WebSocket sobre TCP con JSON y TLS
Elegir un flujo o protocolo por nombre o marketing solo no es suficiente.
El punto es seleccionar una estructura que coincida con su caso de uso a lo largo de estos tres ejes: tiempo, características de transporte y distancia a los validadores pertinentes.
El punto es seleccionar una estructura que coincida con su caso de uso a lo largo de estos tres ejes: tiempo, características de transporte y distancia a los validadores pertinentes.
ERPC y Validators DAO proporcionar una red centrada en Solana, RPC / gRPC / Shredstream servicios, VPS líneas, y descuentos multi-región para Shreds dedicados, para que pueda construir estas estructuras a un costo realista y evolucionar a medida que sus necesidades crecen.
Si desea discutir el diseño de flujo de datos, optimización de distancia de red, o combinaciones de fragmentos dedicados, Compartido Shredstream Bundles, Bundles, y VPS, no dude en llegar a través de Validators DAO Discord.
- ERPC: https://erpc.global/en
- SLV: https://slv.dev/en
- elSOL: https://elsol.app/en
- Epics DAO: https://epics.dev/en
- Validators DAO Discord: https://discord.gg/C7ZQSrCkYR
Noticias
