Resumen
Los nodos Sui gRPC dedicados brindan a tu equipo un entorno de nodo completo aislado para el acceso a datos de Sui de alto rendimiento. En lugar de compartir endpoints públicos o multiinquilino con límites de tasa, operas un nodo dimensionado para tus indexadores, servicios de backend y consumidores de suscripciones. La API gRPC utiliza Protocol Buffers sobre HTTP/2, lo que hace que los flujos de checkpoints, transacciones y eventos sean más eficientes que el sondeo JSON-RPC. La capacidad dedicada ayuda cuando necesitas un rendimiento estable para backfills, múltiples consumidores de flujo concurrentes o envío y simulación de transacciones sin vecinos ruidosos. Aún eres dueño de la superficie operativa: retraso de sincronización, crecimiento del disco, actualizaciones y monitoreo. La superficie gRPC de Sui incluye LedgerService, StateService, TransactionExecutionService y SubscriptionService. Los flujos de trabajo de streaming como SubscribeCheckpoints, SubscribeTransactions y SubscribeEvents son centrales para la indexación de baja latencia; ExecuteTransaction y SimulateTransaction admiten rutas de escritura y simulación. Un nodo dedicado no es una caja mágica administrada. Planifica el crecimiento del estado, la recuperación de snapshots, TLS, pruebas de carga y conmutación por error antes de producción. Esta guía cubre planificación de capacidad, aislamiento, reproducción, monitoreo y decisiones del ciclo de vida del nodo completo sin rankings de proveedores ni afirmaciones de rendimiento inventadas.
Puntos clave
- La capacidad dedicada de gRPC se adapta a backends que necesitan un rendimiento constante en el streaming de checkpoints, transacciones y eventos.
- Los consumidores de streaming deben manejar reconexiones, contrapresión y reproducción de checkpoints; las suscripciones no son de tipo 'dispara y olvida'.
- Tú eres responsable del ciclo de vida del nodo: almacenamiento, actualizaciones, poda, monitoreo y conmutación por error.
- Evalúa el aislamiento, la retención, TLS/autenticación y las herramientas operativas antes de elegir un plan dedicado de gRPC de Sui.
Para qué sirven los nodos Sui gRPC dedicados
Los nodos Sui gRPC dedicados son nodos completos de Sui de un solo inquilino que exponen la API gRPC de Sui en lugar de, o junto con, la superficie JSON-RPC legacy. Están diseñados para servicios de backend que necesitan capacidad predecible para la ingesta de checkpoints, streaming de transacciones, procesamiento de eventos y cargas de ejecución de transacciones.
Un nodo dedicado te da una sincronización de estado y una huella de almacenamiento aisladas, de modo que tu indexador o aplicación no compite con otros inquilinos por CPU, memoria, E/S de disco o ancho de banda de red. Esto es más importante para consumidores de alta frecuencia, backfills paralelos y equipos que necesitan latencia estable sin tiempos de espera de endpoints públicos.
- Indexadores de alto rendimiento que ingieren cada checkpoint y transacción
- Pipelines de eventos que se suscriben a eventos de Sui y los distribuyen a sistemas downstream
- Bots de trading, wallets y backends que simulan y ejecutan muchas transacciones
- Servicios de analítica y datos que necesitan consultas de estado completo y streaming en un solo lugar
Superficie de servicios gRPC de Sui y primitivas de streaming
Los nodos completos de Sui exponen servicios gRPC que se corresponden con las funciones centrales del nodo. Los nombres exactos de los paquetes y las formas de los mensajes dependen de la versión de proto de Sui contra la que generes, pero los roles de los servicios son lo suficientemente estables como para planificar en torno a ellos.
Los clientes generados pueden envolver estos métodos con nombres específicos del lenguaje o constructores de suscripción de nivel superior. Verifica el flujo de trabajo contra los archivos proto proporcionados por tu operador de nodo. No asumas las firmas de los métodos a partir de ejemplos de REST o WebSocket JSON-RPC.
- LedgerService: lee checkpoints, transacciones y datos de objetos para backfills y verificación
- StateService: consulta el estado de los objetos y los saldos para búsquedas de cuentas/estado
- TransactionExecutionService: usa ExecuteTransaction para el envío y SimulateTransaction para validación en seco antes de la difusión
- SubscriptionService: usa SubscribeCheckpoints, SubscribeTransactions y SubscribeEvents para consumidores de streaming de servidor en tiempo real
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Ingesta de checkpoints finalizados | SubscriptionService con SubscribeCheckpoints | Streaming de servidor; persiste la secuencia de checkpoints y reanuda desde el último procesado. |
| Monitorear confirmaciones de transacciones | SubscribeTransactions | El volumen puede ser alto; planifica el filtrado del lado del cliente si el filtrado del lado del servidor no es compatible. |
| Rastrear registros de eventos | SubscribeEvents | Usa filtros con cuidado; se requieren contrapresión y sumideros idempotentes. |
| Enviar o simular ejecución | TransactionExecutionService.ExecuteTransaction o SimulateTransaction | Simula primero para detectar errores; envía con control explícito de gas y nonce. |
Planificación de capacidad y aislamiento
La capacidad dedicada no es un número único. Modélala a partir de tu carga de trabajo real: número de flujos concurrentes, tamaño promedio y máximo de checkpoint, transacciones por segundo por consumidor y concurrencia de backfill. Un nodo que está bien para un backend de sondeo puede verse abrumado por cinco flujos de checkpoints paralelos.
- Mide el rendimiento sostenido del flujo durante horas, no solo un pico corto
- Planifica para el volumen máximo de checkpoints y eventos, no el promedio
- Ten en cuenta la amplificación de escritura en disco y las operaciones de snapshot/compactación
- Separa la analítica con muchas lecturas de la ejecución con muchas escrituras si es posible
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Concurrencia de suscripciones | Máximo de consumidores simultáneos de SubscribeCheckpoints/Transactions/Events | Cada flujo mantiene búferes y estado de conexión; demasiados pueden degradar la sincronización o aumentar la latencia. |
| Tasa de backfill | Qué tan rápido puedes reproducir checkpoints históricos | Los backfills compiten con los flujos en vivo por E/S y CPU. |
| Ejecución de transacciones | Llamadas concurrentes a SimulateTransaction y ExecuteTransaction | La ejecución y simulación aumentan el uso de CPU y memoria; los vecinos ruidosos pueden causar tiempos de espera. |
| Crecimiento del almacenamiento | Crecimiento de la base de datos de checkpoints y objetos más los intervalos de poda | El disco lleno es una causa común de interrupciones; la retención y la poda son decisiones operativas. |
Consumidores de streaming: contrapresión, reproducción y recuperación
Los métodos de streaming de servidor gRPC como SubscribeCheckpoints, SubscribeTransactions y SubscribeEvents entregan una secuencia de respuestas a través de un flujo lógico. El cliente debe aplicar contrapresión, o acumulará una cola sin límites y detendrá el procesamiento.
Las consideraciones de reproducción difieren del streaming en vivo. Un nodo dedicado puede permitir backfills más rápidos, pero aún así debes limitar la tasa de los trabajos de reproducción para que no priven de recursos a los consumidores en vivo. Programa backfills grandes durante ventanas de bajo tráfico y monitorea el retraso de sincronización durante la reproducción.
- Impón una profundidad máxima de cola en el cliente; bloquea o descarta carga cuando el sumidero downstream se quede atrás
- Persiste un cursor duradero para cada flujo, como el último número de secuencia de checkpoint o ID de evento, y reanuda desde ese cursor después de la reconexión
- Trata la entrega como al menos una vez; haz que las escrituras sean idempotentes y desduplica con una clave estable
- En caso de desconexión, reconecta con retroceso y reanuda desde el cursor persistido, nunca desde el extremo actual de la cadena
- Usa un hilo o tarea asíncrona separada para las lecturas del flujo y las escrituras downstream para evitar bloqueos mutuos
Ciclo de vida del nodo completo y responsabilidad operativa
Un nodo gRPC dedicado de Sui sigue siendo un nodo completo de Sui. Ya sea que lo autogestiones o compres un plan administrado, alguien debe encargarse de la sincronización de estado, actualizaciones, almacenamiento, poda y recuperación. Aclara quién es responsable de cada tarea antes de depender del endpoint para producción.
- Sigue las notas de versión del nodo Sui; las actualizaciones pueden incluir cambios en fullnode.yaml, pasos de migración o cambios en la API gRPC
- Planifica el crecimiento del estado y configura la poda si no puedes retener el historial completo de checkpoints indefinidamente
- Usa la restauración de snapshots para acelerar la puesta al día después de un inicio nuevo o un fallback importante
- Bloquea el puerto de métricas y la interfaz de administración; expón gRPC a través de terminación TLS y autenticación por token
- Mantén separadas las configuraciones de mainnet y testnet; el faucet de testnet es https://faucet.sui.io, pero verifica la política y los límites actuales
- Consulta la página de red de Sui en /networks/sui y la guía de testnet en /rpc-assistant/sui-testnet-rpc para detalles de la red de OnFinality
Autenticación, TLS y pruebas de conexión
Los endpoints gRPC de producción deben requerir TLS y un token bearer o credencial equivalente. Nunca expongas gRPC sin autenticación en una interfaz pública. Usa grpcurl contra tu endpoint dedicado para inspeccionar los servicios disponibles antes de escribir código.
Usa grpcurl list y describe para inspeccionar los servicios disponibles, incluidos LedgerService, StateService, TransactionExecutionService y SubscriptionService. El nombre completo del servicio gRPC puede incluir un prefijo de paquete; usa la ruta de tu cliente generado.
Monitoreo y conmutación por error
No puedes operar un nodo gRPC dedicado sin observabilidad. Como mínimo, monitorea el retraso de sincronización de checkpoints, el uso de disco, la presión de memoria, la rotación de conexiones de flujo y las tasas de error de gRPC. Configura alertas que despierten a un humano antes de que los consumidores agoten el tiempo de espera.
- Exporta métricas de Prometheus desde el nodo Sui y recójalas con tu stack de monitoreo
- Alerta sobre estancamiento de sincronización, disco por encima del umbral, alta rotación de conexiones o errores repetidos UNAVAILABLE / DEADLINE_EXCEEDED
- Diseña la conmutación por error configurando un endpoint o región secundaria; mantén los cursores de flujo en almacenamiento externo para que la conmutación sea sin interrupciones
- Prueba la conmutación por error fuera de producción; no codifiques de forma rígida un solo endpoint en las configuraciones del cliente
- Si usas gRPC administrado por OnFinality, confirma las opciones de monitoreo, conmutación por error y notificaciones; consulta /rpc-assistant/sui-rpc-providers y /networks/sui
Marco de decisión para nodos Sui gRPC dedicados
Utiliza las comprobaciones a continuación para evaluar un nodo dedicado sin depender de rankings de proveedores o afirmaciones de rendimiento no verificadas. La elección correcta depende del perfil de streaming de tu carga de trabajo, la madurez operativa y las necesidades de retención de datos.
No aceptes afirmaciones de latencia, tiempo de actividad o RPS sin probarlas contra tu propia carga de trabajo. Aprovisiona un flujo de prueba o canario, mide el rendimiento sostenido, simula una partición de red y valida la conmutación por error antes de comprometerte.
Próximos pasos: Guía de gRPC de Sui.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Aislamiento de capacidad | ¿El plan proporciona CPU, memoria, disco y red de un solo inquilino para tu carga de suscripciones? | Los endpoints compartidos pueden limitar flujos de larga duración o backfills con ráfagas. |
| Superficie de streaming | ¿Están disponibles SubscribeCheckpoints, SubscribeTransactions y SubscribeEvents? ¿Hay límites por flujo? | Tu indexador en tiempo real depende de flujos continuos y reanudables. |
| Acceso operativo | ¿Puedes ver registros, métricas, snapshots y calendarios de actualización? | Sin acceso no puedes diagnosticar estancamientos de sincronización ni planificar el mantenimiento. |
| Retención de datos | ¿Cuánto tiempo se retienen el historial de checkpoints y el estado? ¿Es configurable la poda? | Los requisitos de reproducción y auditoría difieren de las necesidades de streaming en vivo. |
| Seguridad | Requisito de TLS, rotación de tokens, listas blancas de IP y registros de auditoría | Un nodo dedicado con autenticación débil se convierte en una superficie de ataque pública. |
| Paridad con testnet | Endpoint de testnet separado con configuración de streaming realista | La testnet debe reflejar el comportamiento de producción, no un endpoint compartido reducido. |
| Ruta de migración | ¿Puedes comenzar con JSON-RPC y migrar a gRPC sin retrabajo? | gRPC debería ser la superficie principal; JSON-RPC legacy puede ser limitado. |
| Recuperación | Restauración de snapshots, velocidad de backfill y semántica de reanudación de flujo | Una recuperación rápida reduce el tiempo de inactividad después de actualizaciones o conmutación por error. |
Preguntas frecuentes
¿Qué hace que un nodo Sui gRPC dedicado sea diferente de un Sui RPC público o compartido?
Un nodo dedicado proporciona recursos aislados y capacidad de streaming estable para tu backend; los endpoints públicos/compartidos están limitados por tasa y pueden imponer tiempos de espera de suscripción. Aún debes gestionar el ciclo de vida del nodo a menos que esté totalmente administrado.
¿Qué servicios gRPC debo esperar en un nodo Sui dedicado?
LedgerService, StateService, TransactionExecutionService y SubscriptionService. Confirma los stubs de cliente generados y los tipos de solicitud/respuesta a partir de los archivos proto del proveedor.
¿Cómo manejo las reconexiones y la reproducción para SubscribeCheckpoints?
Persiste el último número de secuencia de checkpoint o cursor procesado, reanuda desde ese punto al reconectar, haz que las escrituras downstream sean idempotentes y aplica contrapresión del lado del cliente.
¿Puedo usar un nodo Sui gRPC dedicado para desarrollo en testnet?
Sí, pero mantén la testnet separada de mainnet. Usa el faucet oficial en https://faucet.sui.io y verifica la política/límites actuales. Los datos de testnet pueden restablecerse; no los trates como producción.
¿Todavía necesito operar un nodo completo de Sui si compro un plan gRPC dedicado?
Un nodo dedicado administrado todavía tiene un nodo completo subyacente; puede que seas o no responsable de las actualizaciones, snapshots y monitoreo según el plan. Aclara la responsabilidad operativa y el acceso.
¿Qué métricas debo monitorear para un nodo gRPC dedicado?
Retraso de sincronización de checkpoints, uso de disco, CPU/memoria, rotación de conexiones de flujo, tasas de error y rendimiento de backfill. Alerta sobre estancamientos y umbrales de capacidad.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
