Tendex en activos digitales: infraestructura de trading, creación de mercado y fiabilidad de RPC

Alcance: a qué Tendex se refiere este artículo

El término tendex aparece en varios contextos no relacionados: un concepto de visualización de agujeros negros en astrofísica, una fórmula de eficiencia en baloncesto, una plataforma de ventas B2B, una marca de exoesqueletos portátiles y una firma suiza de trading de activos digitales. Este artículo cubre únicamente el contexto de trading de activos digitales, donde tendex se refiere a un gestor de activos y creador de mercado con sede en Suiza que construye sistemas propietarios de gestión de órdenes y ejecución para los mercados de criptomonedas.

El material público de esa firma describe tres áreas de producto: creación de mercado y provisión de liquidez para socios seleccionados, un fondo cuantitativo de mercado neutral y la implementación de estrategias personalizadas. También describe sistemas de gestión de órdenes y ejecución diseñados para completar operaciones a los mejores precios disponibles en múltiples venues y tipos de producto. Esas son afirmaciones documentadas sobre el stack de la propia firma, no benchmarks que usted pueda verificar desde fuera.

Este artículo no reproduce cifras de rendimiento propietarias, rendimientos de fondos ni listas de venues. En su lugar, explica los patrones de infraestructura que implica un stack de este tipo y le proporciona un método reproducible para medir las partes que usted puede controlar, especialmente la fiabilidad de RPC.

• Cubierto: tendex como operación de trading y creación de mercado de activos digitales.
• No cubierto: la línea de tendex en astrofísica, la estadística Tendex en baloncesto, la plataforma de ventas B2B o la marca de exoesqueletos.
• El comportamiento documentado se separa de las recomendaciones y de las mediciones que usted debe ejecutar por su cuenta.

Requisitos previos y supuestos

Los procedimientos a continuación asumen que tiene conocimientos prácticos de API HTTP, un shell con curl y Node.js o Python para los scripts más largos. Necesita al menos un endpoint RPC que esté autorizado a consultar, representado aquí como RPC_URL. Si está evaluando proveedores en lugar de un único endpoint, recopile varias URL candidatas y ejecute el mismo procedimiento contra cada una.

También debe saber de qué cadena y de qué métodos depende realmente su estrategia. Un sistema de creación de mercado que solo lee precios de venues centralizados tiene requisitos de RPC muy diferentes a los de uno que liquida en cadena, monitorea mempools o envía transacciones. Anote los métodos que llama y el presupuesto de latencia de cada uno antes de medir nada.

Por último, asuma que cualquier endpoint individual puede fallar. El procedimiento de medición está diseñado para exponer modos de fallo, no para demostrar que un endpoint es perfecto.

Modelo mental: dónde se sitúa RPC en un stack de trading

Un stack de trading de activos digitales suele tener cuatro capas: ingesta de datos de mercado, estrategia y riesgo, gestión de órdenes y ejecución, y liquidación o custodia. Los nodos RPC se sitúan en el límite entre la capa de estrategia y la cadena. Sirven lecturas como saldos, nonces y estado de contratos, y retransmiten escrituras como transacciones firmadas.

Para un creador de mercado, la ruta crítica suele ser lecturas sensibles a la latencia y escrituras fiables. Una lectura de saldo obsoleta puede hacer que se rechace una orden; una difusión de transacción retrasada puede provocar una ejecución a un precio no deseado; un desajuste de nonce puede paralizar toda una cuenta. Para un fondo de mercado neutral, la ruta crítica suele ser la consistencia entre venues e instrumentos, por lo que la capacidad de conciliar el estado en cadena con las posiciones fuera de cadena importa más que el rendimiento bruto.

La implicación práctica es que la fiabilidad de RPC no es un único número. Es un perfil de latencia, tasa de error, consistencia y comportamiento de recuperación bajo la combinación específica de métodos que utiliza su estrategia.

• Las estrategias con muchas lecturas se preocupan por los percentiles de latencia y la frescura de la caché.
• Las estrategias con muchas escrituras se preocupan por el éxito de la difusión, el manejo de nonces y el comportamiento de reemplazo.
• Las estrategias entre múltiples venues se preocupan por la consistencia entre el estado en cadena y el estado del venue.

Capacidades documentadas de Tendex frente a sus propias mediciones

Las descripciones públicas de tendex enfatizan sistemas propietarios de gestión de órdenes y ejecución, integraciones que permiten cotizar en múltiples tipos de instrumentos y herramientas utilizadas dentro de sus productos de inversión. Estas son afirmaciones sobre el stack interno de la firma. No le dicen qué latencia verá, qué tasa de error es aceptable ni qué proveedor de RPC servirá a su estrategia.

Trate las capacidades documentadas como contexto para la arquitectura que podría construir, no como evidencia sobre su propio entorno. Las mediciones que importan son las que usted ejecuta contra sus endpoints con su combinación de métodos y su perfil de tráfico.

La siguiente tabla es una plantilla. Rellénela con valores de sus propias ejecuciones; no copie números de ningún artículo, incluido este.

• Documentado: OEMS propietario, cotización en múltiples venues, fondo de mercado neutral, estrategias personalizadas.
• Recomendado: medir percentiles de latencia, tasa de error y consistencia por método.
• Medido por usted: todos los valores numéricos de su tabla de resultados.

Plantilla de tabla de resultados para la evaluación de RPC

Utilice una tabla Markdown como la siguiente para registrar los resultados. Ejecute cada método al menos unos cientos de veces en diferentes momentos del día y registre la latencia p50, p95 y p99, la tasa de error y cualquier fallo de consistencia. Deje las celdas en blanco hasta que tenga datos reales.

| Endpoint | Método | Muestras | p50 (ms) | p95 (ms) | p99 (ms) | Tasa de error | Fallos de consistencia |

| --- | --- | --- | --- | --- | --- | --- | --- |

| RPC_URL_A | eth_getBalance | | | | | | |

| RPC_URL_A | eth_sendRawTransaction | | | | | | |

| RPC_URL_B | eth_getBalance | | | | | | |

| RPC_URL_B | eth_sendRawTransaction | | | | | | |

La columna de consistencia es donde registra los casos en que dos lecturas del mismo estado devolvieron resultados diferentes en una ventana corta, o en que una transacción fue aceptada pero no visible después de un retraso razonable. Esos fallos importan más que la latencia promedio para los sistemas de ejecución.

Diagnóstico ejecutable: latencia y tasa de error con curl

Comience con un bucle simple que mida el tiempo de ida y vuelta y el estado HTTP para un método de lectura. Esto le da una visión de primer orden de la latencia y la tasa de error sin dependencias.

Ejecútelo contra cada endpoint candidato y guarde la salida. El siguiente script utiliza un RPC_URL de marcador de posición y una carga útil JSON-RPC para eth_blockNumber, que es económico y ampliamente soportado.

for i in $(seq 1 50); do
  start=$(date +%s%3N)
  status=$(curl -s -o /tmp/rpc_out.json -w "%{http_code}" \
    -X POST "$RPC_URL" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')
  end=$(date +%s%3N)
  echo "$i $status $((end-start))"
done

Diagnóstico ejecutable: percentiles y consistencia en Python

El bucle de curl le proporciona muestras brutas. Un breve script de Python las convierte en percentiles y verifica la consistencia comparando lecturas repetidas del mismo bloque. Este es el procedimiento que debe adaptar a su propia combinación de métodos.

El siguiente script utiliza solo la biblioteca estándar más requests. Reemplace RPC_URL y ajuste la lista de métodos para que coincida con su estrategia. Registre la salida en la tabla de resultados anterior.

import time, statistics, requests

RPC_URL = "RPC_URL"
METHODS = ["eth_blockNumber", "eth_getBalance"]
SAMPLES = 200

def call(method, params):
    payload = {"jsonrpc":"2.0","id":1,"method":method,"params":params}
    start = time.perf_counter()
    r = requests.post(RPC_URL, json=payload, timeout=5)
    elapsed = (time.perf_counter() - start) * 1000
    return r.status_code, elapsed, r.json()

for method in METHODS:
    params = [] if method == "eth_blockNumber" else ["0x0000000000000000000000000000000000000000", "latest"]
    latencies, errors = [], 0
    for _ in range(SAMPLES):
        try:
            status, ms, body = call(method, params)
            latencies.append(ms)
            if status != 200 or "error" in body:
                errors += 1
        except Exception:
            errors += 1
    latencies.sort()
    p50 = statistics.median(latencies)
    p95 = latencies[int(len(latencies) * 0.95) - 1]
    p99 = latencies[int(len(latencies) * 0.99) - 1]
    print(method, "p50", round(p50,1), "p95", round(p95,1), "p99", round(p99,1), "errors", errors)

Resultado esperado de la verificación

Un endpoint saludable debería devolver HTTP 200 con un resultado JSON-RPC válido para cada muestra, y los percentiles de latencia deberían ser estables entre ejecuciones. Si observa una latencia p99 muy superior a la p50, o errores intermitentes, el endpoint no es adecuado para rutas críticas de ejecución sin un respaldo.

Para la consistencia, las lecturas repetidas de la misma altura de bloque deberían devolver resultados idénticos. Si no lo hacen, registre la discrepancia e investigue si el endpoint está balanceado entre nodos con estados diferentes.

No considere una única ejecución exitosa como prueba. Repita el procedimiento en diferentes momentos del día y bajo una carga que se parezca a su tráfico de producción.

Solución de problemas: modos de fallo comunes

Los modos de fallo más comunes en el uso de RPC para trading son desajustes de nonce, lecturas obsoletas, limitación de tasa y conmutación por error silenciosa a un nodo retrasado. Cada uno tiene una firma diferente en sus mediciones.

Los desajustes de nonce suelen aparecer como transacciones rechazadas con un error de nonce. Las lecturas obsoletas aparecen como saldos o números de bloque que van por detrás de otros endpoints. La limitación de tasa aparece como respuestas HTTP 429 agrupadas bajo carga. La conmutación por error silenciosa aparece como fallos de consistencia en los que la misma consulta devuelve resultados diferentes en una ventana corta.

Para cada modo de fallo, decida si su estrategia puede tolerarlo. Un creador de mercado puede aceptar lecturas obsoletas ocasionales si tiene un bucle de conciliación, pero no puede tolerar desajustes de nonce que paralicen una cuenta.

• Errores de nonce: verifique el manejo de transacciones pendientes y la lógica de reemplazo.
• Lecturas obsoletas: compare la altura de bloque entre endpoints antes de confiar en un saldo.
• Limitación de tasa: mida la tasa de error bajo concurrencia realista, no con solicitudes individuales.
• Fallos de consistencia: registre la altura de bloque y el resultado de cada lectura.

Limitaciones y compensaciones

Ningún endpoint RPC es perfecto. Una mayor fiabilidad suele costar más, y la infraestructura dedicada cambia flexibilidad por control. Un único endpoint es más simple de operar pero no tiene redundancia; un grupo de endpoints añade complejidad y requiere verificaciones de consistencia.

El procedimiento de medición de este artículo es un punto de partida, no una evaluación completa. No cubre el monitoreo de mempool, el reemplazo de transacciones ni el comportamiento entre cadenas. Si su estrategia depende de eso, amplíe la combinación de métodos y vuelva a ejecutar el procedimiento.

Por último, las descripciones públicas del stack de cualquier firma de trading, incluida tendex, no sustituyen su propia revisión de arquitectura. Úselas como contexto y luego mida su propio entorno.

Próximos pasos: de la medición a la elección de infraestructura

Una vez que tenga una tabla de resultados, el siguiente paso es decidir si necesita endpoints compartidos, nodos dedicados o una combinación. Los endpoints compartidos son apropiados para cargas de trabajo con muchas lecturas y tolerantes a la latencia. Los nodos dedicados son apropiados cuando necesita un rendimiento predecible y control sobre el software del nodo.

Para recomendaciones concretas de endpoints y proveedores, utilice el RPC Assistant en lugar de este artículo. Para obtener información sobre el alojamiento de nodos y el diseño de endpoints, consulte las guías de Learn sobre alojamiento de nodos blockchain y endpoints RPC multicadena.

Si está evaluando OnFinality específicamente, revise las páginas de servicio API, precios de RPC, redes compatibles y nodo dedicado, y luego ejecute el procedimiento de medición contra los endpoints que esté considerando.

• Comience con el RPC Assistant para elegir endpoints y proveedores.
• Utilice las guías de Learn para obtener contexto sobre arquitectura y medición.
• Vuelva a ejecutar el procedimiento después de cualquier cambio en la infraestructura.