Cómo la capa edge potencia un RPC más rápido en Alchemy
Autor: Uttam Singh
Alchemy opera su propia capa edge sobre bare metal en lugar de poner un CDN de terceros delante del tráfico RPC. El DNS basado en geoproximidad resuelve cada solicitud hacia la región de Alchemy más cercana (US East, US West, EU Central y Sudeste Asiático), y los health checks regionales hacen failover del tráfico automáticamente a la región más cercana siguiente, sin que tengas que hacer nada. Tras el despliegue de octubre de 2025, la latencia P99 en APAC bajó de 150 ms a 20 ms.
Billones de dólares en valor se mueven a través de la infraestructura blockchain cada año. Un swap de DeFi en Solana, una transferencia de stablecoin en Ethereum, la liquidación de un mercado de predicción en Polygon: cada una de estas transacciones depende de llamadas RPC que atraviesan capas de red antes de llegar a un nodo. Cuando la actividad financiera se ejecuta onchain, cada milisegundo en ese trayecto es dinero en riesgo.
Para un proveedor de infraestructura que atiende billones de solicitudes en más de 100 redes blockchain, la capa entre el usuario y el centro de datos es donde se gana o se pierde el rendimiento. Esa capa es el edge. Y a fines de 2025, Alchemy la reconstruyó desde cero.
¿Por qué importa la latencia de RPC en las finanzas onchain?
Los usuarios y las aplicaciones de blockchain están distribuidos globalmente. Un bot de trading en Singapur, una aplicación de wallet en Frankfurt, el backend de un protocolo de DeFi en Virginia: todos hacen llamadas RPC para leer el estado de la blockchain y enviar transacciones. Cuanto más rápido se resuelven esas llamadas, mejor es la experiencia.
En DeFi, la latencia se traduce directamente en calidad de ejecución. Un eth_call más lento significa datos de precio desactualizados. Un envío de transacción retrasado significa peores ejecuciones o transacciones fallidas. Para las aplicaciones de wallet, cada 100ms adicionales de tiempo de carga degrada la experiencia de usuario que mantiene a la gente onchain.
Pero la latencia es solo la mitad de la ecuación. La confiabilidad importa igual. Si tu proveedor de RPC enruta todo el tráfico a través de un único CDN de terceros, ese CDN se convierte en un punto único de falla. Cuando cae, cada red, cada cliente y cada solicitud caen con él.
¿Qué es el Alchemy Edge Proxy?
Piensa en el Edge Proxy como la puerta de entrada a la infraestructura de RPC de Alchemy. Cada solicitud de API, ya sea que esté leyendo el estado de Ethereum, consultando cuentas de Solana, o enviando una transacción en Base, pasa por esta capa de ingreso antes de llegar a la infraestructura de servicio que está detrás.
Durante años, en Alchemy usamos un CDN importante como esa puerta de entrada. Los CDN son una opción popular en la industria por buenas razones: vienen listos con protección contra DDoS, enrutamiento geográfico, reglas de WAF y terminación SSL. Para la mayoría de las aplicaciones web, ese conjunto es suficiente. Los CDN llevan dos décadas siendo la capa de ingreso predeterminada para todo, desde e-commerce hasta streaming, y se ganan esa posición.
Las finanzas onchain tienen demandas distintas. El tráfico de RPC es intermitente, sensible a la latencia, globalmente distribuido y crítico en términos de seguridad de maneras que el tráfico web común no lo es. A un bot de trading que lee el estado de tres chains en paralelo no le importa que un CDN pueda cachear una página de marketing en 50 ciudades. Le importa el tiempo entre emitir eth_call y recibir una respuesta. Una wallet que sincroniza saldos no necesita una regla de WAF contra inyección SQL. Necesita el nodo de edge más cercano posible y un handshake TLS que se complete en milisegundos de un solo dígito. Un protocolo que liquida posiciones en un exchange de derivados no puede tolerar que el cronograma de incidentes de un CDN de terceros sea un techo para su propio uptime.
Para satisfacer esas demandas, construimos un edge proxy personalizado sobre bare metal: una capa de ingreso diseñada desde cero para tráfico RPC de blockchain de alto rendimiento y baja latencia. Se ejecuta en infraestructura controlada por Alchemy en múltiples regiones globales, reemplaza cada protección de la capa de CDN con una capa equivalente o más fuerte que podemos ajustar por red, y elimina por completo una dependencia de terceros de la ruta de servicio crítica.
En el despliegue de octubre de 2025, la latencia P99 en APAC bajó de 150 ms a 20 ms y la latencia mediana de unos 35 ms a unos 5 ms, medidas en más de 100 redes.
¿Cómo funciona el Alchemy Edge Proxy?
La arquitectura del Edge Proxy consiste en dos componentes principales que se ejecutan en servidores bare-metal dedicados en múltiples regiones globales (US East, US West, EU Central, Sudeste Asiático, entre otras).
Istio Ingress Gateway
El primer componente es un Istio Ingress Gateway que ejecuta Envoy como plano de datos. Esto maneja la terminación TLS, la gestión de conexiones y el proxying de solicitudes. Envoy es el mismo proxy que impulsa a Lyft, Google Cloud y AWS App Mesh bajo carga. Su núcleo async no bloqueante en C++, la multiplexación HTTP/2 y los pools de conexiones upstream precalentados lo hacen adecuado para un ingreso de alto rendimiento y baja latencia.
Edge Proxy Control Plane (EPCP)
El segundo componente es un plano de control personalizado que se ejecuta junto a Envoy como un filtro ext_authz. Para cada solicitud entrante, el EPCP evalúa:
- Hacia dónde enrutar la solicitud según la URL, los headers y la red blockchain de destino
- Qué clusters de backend están disponibles para esa solicitud (por ejemplo, clusters de archive nodes, servicios alojados en AWS, endpoints específicos de región)
- Si la solicitud debe bloquearse por razones de seguridad o cumplimiento
- Qué redes están sanas en la región local (mediante health checks)
El EPCP luego inyecta headers de enrutamiento que le indican a Envoy hacia dónde reenviar la solicitud. Este diseño mantiene rápida la ruta crítica (Envoy maneja el proxying) mientras conserva la lógica de enrutamiento flexible y configurable dinámicamente.
Ciclo de vida de una solicitud
Así es como fluye por el sistema una solicitud exitosa típica:
- El cliente envía una solicitud RPC a
*.g.alchemy.com. - El DNS basado en geolocalización resuelve la solicitud hacia la región de Edge Proxy más cercana.
- El Istio Ingress Gateway recibe la solicitud y la pasa al EPCP vía ext_authz.
- El EPCP valida la solicitud (verificaciones OFAC, reglas de seguridad), determina el cluster de destino y devuelve los headers de enrutamiento.
- Istio reenvía la solicitud al backend correspondiente.
- La respuesta regresa directamente al cliente.
Enrutamiento DNS basado en geolocalización
El Edge Proxy usa resolución DNS basada en geoproximidad. Esto significa que la capa de DNS es agnóstica a la chain y a la red: una solicitud para Ethereum mainnet y una solicitud para Solana mainnet resuelven a la misma región de Edge Proxy. El propio Edge Proxy maneja internamente el enrutamiento consciente de la red.
Este diseño tiene varias ventajas:
- La resolución DNS y los handshakes TLS ocurren en la ubicación de edge más cercana, sin importar qué red blockchain se necesite finalmente.
- Agregar nuevas redes blockchain no requiere cambios de DNS.
- Los health checks regionales se ejecutan a nivel del Edge Proxy. Si una región de Edge Proxy deja de estar sana, el DNS hace failover automáticamente a la región más cercana siguiente.
Configuración dinámica
El Edge Proxy obtiene su configuración de enrutamiento de nuestra plataforma de configuración interna. Esto permite cambios en tiempo de ejecución sin redeployments:
regions:
us-east:
enabled: true
routes:
"/v2":
verbs: ["POST"]
destination: archive-cluster
fallbackRegions:
- us-west
- eu-central
- apac-southeast
security:
ipsBanned: ["..."]
pathsBanned: ["..."]Si una región necesita drenarse, una red necesita re-enrutamiento, o una nueva regla de seguridad necesita aplicarse, las actualizaciones de configuración se propagan sin tocar el proxy en ejecución.
¿Cómo funciona el modelo de seguridad sin un CDN?
Eliminar la dependencia del CDN significó reconstruir cada protección de seguridad desde cero. El Edge Proxy reemplaza las protecciones del CDN con un enfoque por capas:
La idea clave: estas protecciones no son más débiles que las del CDN. Son más específicas. Alchemy controla cada capa, puede ajustar umbrales por red y no depende del cronograma de respuesta a incidentes de un tercero cuando algo falla.
¿Qué resultados ha entregado el Alchemy Edge Proxy?
El Edge Proxy se desplegó en más de 100 redes blockchain a lo largo de tres semanas en octubre de 2025, sin requerir migración alguna de clientes. Los resultados fueron inmediatos.
Latencia
La telemetría del lado del cliente mostró mejoras de magnitud similar en cargas de trabajo diversas, con las más sensibles a la latencia obteniendo las mayores ganancias.
Para datos públicos actuales de proveedores, compara los benchmarks de latencia de RPC entre chains, regiones y métodos comunes.
Confiabilidad
Durante la misma ventana de tiempo en la que la configuración anterior con CDN al frente habría estado expuesta a incidentes upstream, la infraestructura de Alchemy funcionó sin verse afectada.
¿Cómo se compara esto con otros enfoques de infraestructura?
Hay tres enfoques comunes para manejar el ingreso de infraestructura de API de blockchain:
El edge proxy personalizado combina las ventajas de latencia de una conexión directa con la protección y flexibilidad de tráfico de un CDN, sin la dependencia de proveedor ni el escalamiento de costos de ninguno de los dos.
Algunos proveedores de RPC han lanzado soluciones de edge sin CDN, pero esos despliegues típicamente han requerido que los clientes migren a nuevos endpoints antes de plazos de descontinuación. El Alchemy Edge Proxy entregó ganancias de rendimiento equivalentes o mayores sin requerir ninguna acción por parte de los clientes.
Preguntas frecuentes
¿Qué proveedor de RPC tiene la mejor red edge global?
Depende de dónde se origina tu tráfico, así que la comparación útil es técnica y no un ranking. Hay cuatro cosas que revisar en cualquier proveedor: si la capa de ingreso es infraestructura propia del proveedor o un CDN de terceros alquilado, cuántas regiones opera y dónde, si el failover entre regiones es automático o algo que tú configuras, y cuál es la latencia medida desde tu región y no a nivel global.
Alchemy opera un edge proxy personalizado en servidores bare-metal dedicados en US East, US West, EU Central y Sudeste Asiático, que reemplaza a un CDN de terceros que antes estaba en la ruta de servicio. Eliminar esa dependencia significa que el cronograma de incidentes de ningún proveedor externo pone un techo al uptime de Alchemy. Para ver las cifras medidas actuales por región, consulta los benchmarks de latencia de RPC en vivo.
¿Qué proveedores ofrecen failover de RPC multi-región listo para usar?
"Listo para usar" es lo que vale la pena verificar: muchos proveedores soportan failover si lo configuras, lo cual es un producto distinto a un failover que ya funciona.
En Alchemy, el failover es automático y no requiere configuración: los health checks regionales se ejecutan a nivel del Edge Proxy, y cuando una región deja de estar sana, el DNS hace failover del tráfico a la región más cercana siguiente. Cada región tiene una lista explícita y ordenada de regiones de respaldo, así que el tráfico sigue una ruta definida en lugar de resolverse de forma arbitraria. Como esto ocurre en la capa de DNS y de ingreso, no hay nada que configurar en tu aplicación, y no se requirió ninguna migración cuando la capa se desplegó en más de 100 redes en octubre de 2025.
¿Cómo funciona el enrutamiento DNS basado en geolocalización para RPC?
Alchemy usa resolución DNS basada en geoproximidad. Una solicitud a *.g.alchemy.com se resuelve hacia la región edge más cercana, y la capa de DNS es agnóstica a la chain de forma deliberada: una solicitud para Ethereum mainnet y una solicitud para Solana mainnet resuelven al mismo edge proxy regional, que luego maneja internamente el enrutamiento consciente de la red.
De esto se derivan dos consecuencias. La resolución DNS y el handshake TLS ocurren en la ubicación de edge más cercana sin importar qué chain necesite finalmente la solicitud, y de ahí proviene la mayor parte del ahorro en el tiempo de ida y vuelta. Además, agregar una nueva red blockchain no requiere ningún cambio de DNS, así que la cobertura de redes y el enrutamiento escalan de forma independiente entre sí.
¿Qué pasa con mi tráfico cuando falla una región?
Los health checks regionales se ejecutan de forma continua a nivel del Edge Proxy. Cuando una región se marca como no sana, el DNS deja de resolver hacia ella y envía el tráfico a la región más cercana siguiente, según una lista ordenada de regiones de respaldo configurada por región en lugar de elegir de forma arbitraria.
La configuración de enrutamiento se obtiene en tiempo de ejecución de una plataforma de configuración interna, así que se puede drenar una región, re-enrutar una red o aplicar una regla de seguridad sin redeployments ni reinicios del proxy. Desde el lado de tu aplicación no cambia nada: el mismo endpoint sigue funcionando, servido desde otra región.
Construye sobre la infraestructura blockchain más rápida
El Edge Proxy de Alchemy es una pieza de una plataforma construida para las demandas de la actividad financiera global. Hasta 7.5 veces más rápido en RPC en la cola de latencia, más de 100 redes soportadas, presencia multi-región en varios continentes y mejoras de rendimiento sin ninguna acción requerida: todo viene incluido de fábrica con los endpoints de RPC de Alchemy.
Ya sea que estés construyendo un protocolo de DeFi, una wallet, una aplicación de pagos, o infraestructura onchain para instituciones financieras, el rendimiento y la confiabilidad son requisitos indispensables. Explora la lista completa de chains soportadas, revisa la documentación para desarrolladores de Alchemy, o crea una cuenta gratuita para empezar a construir.
Boletín de Alchemy
Entérate primero de los lanzamientos
Suscríbete a nuestro boletín
Recibe las últimas actualizaciones de productos y recursos de Alchemy
Al ingresar tu correo electrónico, aceptas recibir nuestras comunicaciones de marketing y actualizaciones de productos. Reconoces que Alchemy procesa la información que recibimos de acuerdo con nuestro Aviso de Privacidad. Puedes cancelar tu suscripción en cualquier momento.
Artículos relacionados
Cómo Alchemy impulsa los pagos con stablecoins
Un pago llega o no llega. Así es como Cash App, Slash, AllScale, Pana y Usual operan la mitad onchain de los pagos con stablecoins sobre Alchemy.
Le dimos a cada blockchain su propio agente de guardia
Cómo Alchemy usa más de 230 agentes, uno por cada red blockchain, para hacer triage y corregir alertas en nuestra flota de nodos. La mediana del tiempo de resolución bajó de 30 minutos a 8.
Glamsterdam: la guía completa para desarrolladores de Ethereum
Glamsterdam ya está en Sepolia. La guía completa sobre lo que significa para los desarrolladores y cómo Alchemy se preparó para la actualización de la red.