Su dApp es vulnerable: esto es lo que lo está provocando

Los nodos RPC (Remote Procedure Call) son componentes fundamentales de la infraestructura de la cadena de bloques. Se encargan de la comunicación entre el libro de contabilidad inmutable descentralizado y las aplicaciones front-end. Estas infraestructuras intermediarias actúan como mensajeros que facilitan las solicitudes y respuestas entre los nodos y los servicios creados en una cadena de bloques.

Los nodos RPC son como el Servicio Postal de los Estados Unidos (USPS), que facilita el movimiento de información desde la aplicación descentralizada a la cadena de bloques y viceversa. Así como usted depende del servicio postal para que su correo llegue de un punto a otro, las aplicaciones descentralizadas dependen de los nodos RPC para acceder a la cadena de bloques. Y sin estos nodos, las aplicaciones descentralizadas tendrán dificultades para funcionar.

Los nodos RPC han evolucionado significativamente en los últimos 10 años, pero la centralización de la infraestructura ha introducido una vulnerabilidad oculta. Este artículo tiene como objetivo explorar el papel de los nodos RPC, el peligro de la centralización y las alternativas que pueden proteger sus aplicaciones descentralizadas de las vulnerabilidades.

Evolución de la infraestructura RPC

La idea de las llamadas a procedimientos remotos se remonta a la década de 1970, cuando los científicos informáticos buscaron formas de comunicarse entre diferentes máquinas para hacer que las computadoras distribuidas fueran transparentes para los desarrolladores.

En la década de 1980, Sun Microsystem desarrolló el primer RPC, denominado Network File System. Sun Microsystem desarrolló el protocolo Open Network Computing RPC, que se ha convertido en un estándar para la comunicación entre diferentes programas en una red.

Sin embargo, a principios de los años 90, Microsoft desarrolló e implementó su versión de RPC para permitir la comunicación entre procesos en sistemas basados en Windows. A principios de los años 2000, se introdujo JSON RPC, que utiliza JSON para la codificación de datos. Se hizo famoso entre los desarrolladores y programadores debido a la facilidad para transferir datos estandarizados.

Durante la última década, las dApps se han convertido en una parte importante de la industria blockchain y RPC ha sido una infraestructura perfecta necesaria para completar el laberinto.

¿Por qué?

1. Su capacidad de realizar una llamada de función remota en otra computadora como una llamada de función local es perfecta para la arquitectura blockchain.
2. Su falta de estado y su peso ligero potencian la cadena de bloques y son útiles en situaciones de restricciones de ancho de banda y de cómputo.

Debido a sus ventajas, el protocolo RPC se volvió rápidamente muy utilizado. Se propuso para permitir que las aplicaciones escritas en diferentes lenguajes se conectaran y se comunicaran. La idea básica detrás de RPC es realizar una llamada a una función remota en otra computadora o servidor como si fuera una llamada a una función local.

A lo largo de los años, ha habido tres tipos principales de RPC (centralizado, descentralizado y autoalojado) y cada uno es único a su manera.

El peligro de los nodos RPC centralizados

Los nodos RPC centralizados son nodos administrados y controlados por una única entidad. Estos nodos centralizados tienen modelos que se asemejan a los servicios de alojamiento en la nube web2, como AWS (Amazon Web Services), Microsoft Azure y Google Cloud Protocol (GCP).

Aunque estos proveedores centralizados de RPC web3 mantienen una infraestructura de nodos para aplicaciones descentralizadas, un análisis profundo del sistema reveló lo centralizados que están. Irónicamente, estos proveedores de infraestructura web3 también dependen de la infraestructura del servidor de alojamiento en la nube web2 para mantener sus servicios.

Por lo tanto, cuando estos proveedores de servicios en la nube sufren interrupciones, los servicios web3, que están pensados para ser descentralizados, también sufren interrupciones. A continuación, se muestran ejemplos de nodos RPC centralizados: Alchemy, Infura, Quicknode, etc.

Veamos los peligros que plantean los nodos RPC centralizados para la infraestructura web3.

1. Punto único de falla: tener un único punto de falla siempre afecta la confiabilidad del sistema. Un único servidor o una red de servidores controlados por una única entidad introducirá un punto crítico que podría provocar la falla de su dApp.

   
   

   

   
   

   Si el servidor a través del cual se envían los datos falla, el vínculo entre la cadena de bloques y la aplicación descentralizada se rompe y el sistema falla. Un único punto de falla afectará la confiabilidad del sistema, especialmente en aplicaciones relacionadas con las finanzas, como las plataformas DeFi.

2. Problema de escalabilidad : los nodos RPC centralizados pueden convertirse en cuellos de botella en momentos de mucho tráfico y esto limita la escalabilidad de la dApp. Cuando una red está congestionada debido a la dependencia de un solo nodo, afecta la eficiencia de las dApps y aumenta la latencia, lo que afecta a los usuarios.

   
   

   Debido a que es un sistema centralizado, aumentar la escalabilidad de la dApp es imposible.

3. Riesgo de seguridad y vulnerabilidad: un nodo centralizado o dedicado está expuesto a vulnerabilidades y puede ser un blanco fácil para personas sin escrúpulos. Los datos pueden quedar expuestos y manipulados, lo que en última instancia afecta la toma de decisiones en las aplicaciones descentralizadas.

   
   

   Además, también es fácil llevar a cabo un ataque coordinado contra el proveedor, que en última instancia exponga a los usuarios de la aplicación descentralizada. Las agencias gubernamentales pueden obligar a una sola entidad a cerrar una aplicación.

   
   

   He aquí un ejemplo:

   
   

   En 2022, MetaMask supuestamente bloqueó a los usuarios con direcciones IP venezolanas e iraníes para que no pudieran realizar transacciones en la cadena de bloques.

   
   

   Esto fue posible gracias al RPC centralizado (Infura) utilizado por la billetera web3.

Casos prácticos de fallas y vulnerabilidades de nodos RPC centralizados

Puede parecer que las RPC centralizadas son seguras, pero no lo son. Aun así, si tenemos dudas al respecto, veamos algunos estudios de casos sobre fallas pasadas de las RPC centralizadas.

El caso de Infura

Infura es uno de los primeros proveedores de infraestructura como servicio (IaaS) de backend de blockchain en la Web3, ofrecido por consenso. Se afirma que la infraestructura está disponible para un tiempo de actividad del 99,9 % y para 16 EVM de blockchain.

Hasta 2020, Infura ha sido considerado un héroe, como una de las fronteras para el desarrollo de dApp y liderando la adopción masiva de criptomonedas/blockchain.

El 11 de noviembre de 2020, Infura experimentó una interrupción del servicio debido a un error que afectó a la versión de GEth ejecutada por Infura.

El problema principal es que el sistema Infura no funcionaba y todos los usuarios de la infraestructura de Infura no podían conectarse a la cadena de bloques. Los servidores dejaron de funcionar debido a un error y se reveló el riesgo de centralización detrás de una red descentralizada.

Metamask, la billetera Ethereum más grande orientada al consumidor con millones de usuarios activos, sufrió interrupciones. Todo porque dependen de Infura, un proveedor de RPC centralizado.

Preocupaciones sobre la centralización durante las actualizaciones de red

Durante las actualizaciones de red o las bifurcaciones duras, suelen surgir preocupaciones sobre fallas en el servicio, especialmente en lo que respecta a las aplicaciones descentralizadas que dependen de proveedores de infraestructura centralizados. Estas preocupaciones incluyen:

Punto único de falla, que puede interrumpir actividades y generar tiempo de inactividad.

A continuación se muestran algunos ejemplos pasados:

• Durante labifurcación dura de Ethereum Istanbul en 2019 , muchos proveedores de RPC centralizados experimentaron tiempos de inactividad. Algunos de estos tiempos de inactividad se deben a que la red está pasando por actualizaciones. Las aplicaciones DeFi no pueden procesar transacciones, lo que deja a los usuarios en el limbo.

  
  

• Durante la actualización de Polygon Heimdall , los proveedores de servicios de RPC enfrentaron problemas de conectividad y no estaban sincronizados con la red blockchain. Los usuarios no pudieron acceder a las aplicaciones descentralizadas DeFi durante varias horas, por lo que las transacciones se retrasaron o fallaron.

Sobrecarga de RPC de Solana en 2021

Solana experimentó muchas interrupciones en 2021. Una de las interrupciones más famosas se debe a la sobrecarga de los servicios RPC centralizados durante los períodos pico. Como los nodos públicos se vieron abrumados, los usuarios no pudieron interactuar con Solana Blockchain durante varias horas y la red sufrió una interrupción total del servicio durante muchas horas.

Estos casos de “facepalms” y otros tantos revelan la importancia de los proveedores de RPC para la utilidad de la cadena de bloques. Si bien muchas aplicaciones descentralizadas aún utilizan proveedores centralizados (quizás por ignorancia o irreflexión), a lo largo de los años han surgido alternativas.

En las siguientes secciones, le mostraremos las otras alternativas y cómo han sido una excelente opción para los desarrollos de blockchain.

Descentralización de su DApp: Principales alternativas a los nodos RPC centralizados

Nodos RPC autoalojados

Como su nombre lo indica, los nodos RPC autoalojados son nodos que usted aloja o administra en su propio hardware o infraestructura en la nube. En lugar de depender de proveedores de RPC externos, puede alojar sus propios nodos RPC. Obtiene acceso directo a la red de blockchain, valida transacciones, consulta datos de blockchain directamente e interactúa con las dApps.

Los beneficios de los nodos RPC autohospedados incluyen:

1. Autonomía/Control : al ejecutar sus nodos, usted tiene control total sobre las configuraciones de los mismos. Puede personalizar el software para adaptarlo a sus necesidades, aplicar actualizaciones a su discreción y administrar la seguridad.

2. Confiabilidad : no tiene que buscar interrupciones del servicio ni fallas debido a problemas del proveedor, comunes en los nodos centralizados de terceros.

3. Acceso directo a la red : ejecutar nodos en su infraestructura significa que usted es responsable de sus servicios y tiene acceso de baja latencia a la red blockchain.

Si bien los nodos alojados en servidores propios parecen ser más confiables que sus alternativas centralizadas, tienen sus desventajas. Estas son:

1. Altos requisitos de recursos . El alojamiento de un nodo RPC requiere un espacio de disco significativo para almacenar el historial de la cadena de bloques. El almacenamiento, el ancho de banda y la potencia de procesamiento necesarios para ejecutar nodos RPC pueden ser abrumadores.

   
   

   Además, es necesaria una sincronización constante con la cadena de bloques, lo que puede consumir una gran cantidad de ancho de banda, lo que puede resultar abrumador. La potencia de procesamiento necesaria también puede ser abrumadora, especialmente cuando se procesa información en situaciones de mucho tráfico.

   
   

2. Costoso de gestionar : configurar nodos alojados en el servidor parece ser una mejor opción, pero no lo es. El coste del hardware, el coste operativo y el coste de oportunidad pueden ser abrumadores.

   
   

   Los costos operativos, como la electricidad, el ancho de banda de Internet y las tarifas de servicios en la nube (si utiliza una infraestructura en la nube), pueden ser abrumadores. Para que un nodo funcione correctamente, necesita un equipo de expertos dedicado que esté disponible para solucionar cualquier problema o corre el riesgo de sufrir cortes de suministro durante varias horas.

3. Configuración y mantenimiento complejos : necesita un conocimiento sólido de la tecnología blockchain, la administración de servidores y las mejores prácticas de seguridad. Mantenimiento regular para evitar interrupciones, como actualizaciones de software, parches de seguridad y actualizaciones de hardware para mantener los nodos funcionando correctamente.

4. Escalabilidad limitada y sin soporte para múltiples cadenas : a diferencia de los proveedores externos con modelos para manejar este problema, para interactuar con múltiples cadenas de bloques, es necesario alojar nodos para cada cadena de bloques, lo que puede consumir muchos recursos y ser insostenible.

   
   

   Los nodos alojados en servidores propios brindan independencia, un gran control de la interacción en la cadena de bloques y privacidad. Requieren recursos significativos, experiencia tecnológica y mantenimiento, lo que puede resultar imposible incluso para el equipo de desarrollo de cadenas de bloques más sólido disponible.

Nodos RPC descentralizados

Los RPC descentralizados son los servidores de blockchain que permiten que las aplicaciones descentralizadas se comuniquen con la blockchain de manera descentralizada. Los proveedores de RPC descentralizados distribuyen su infraestructura entre múltiples nodos. Esto reduce los puntos únicos de falla, mejora la estabilidad y la escalabilidad de la red y reduce la latencia.

Los beneficios de los nodos RPC descentralizados sobre otros incluyen:

1. Red distribuida : la red distribuida de proveedores de nodos trabaja para procesar solicitudes, responder consultas e interactuar con la cadena de bloques.

2. Las operaciones no requieren confianza : no se confía en un único proveedor. Las solicitudes se distribuyen entre varios proveedores, lo que garantiza que ninguna de las partes tenga control total sobre los datos o las solicitudes realizadas.

3. Resistencia a la censura : dado que los nodos RPC no se encuentran en la misma jurisdicción, la entidad o autoridad no puede censurar, bloquear o restringir fácilmente el acceso a la cadena de bloques. Si una infraestructura RPC deja de funcionar debido a las políticas de una jurisdicción, las solicitudes de la aplicación descentralizada se pueden enrutar a otros nodos RPC de una jurisdicción diferente.

4. Tolerancia a fallos : el modelo descentralizado de los servicios RPC los hace resistentes a las interrupciones. Si un nodo deja de funcionar, otro reemplazará el servicio. Esto reduce el tiempo de inactividad y garantiza una disponibilidad constante.

Los desafíos incluyen:

1. Latencia : si no se configuran correctamente, los servicios RPC descentralizados pueden generar latencia, ya que podrían enrutarse a través de varios nodos. La descentralización de los nodos RPC puede volverse fácilmente redundante y, como resultado de esto, los datos pueden enrutarse a través de múltiples servidores, lo que aumenta la latencia.

2. Seguridad : dado que los nodos son administrados por entidades diferentes, es posible que no estén igualmente seguros.

3. Consenso entre nodos : garantizar la coherencia y fiabilidad de los datos puede ser un desafío. Es necesario implementar mecanismos para detectar y mitigar los nodos maliciosos o defectuosos.

Algunos ejemplos de nodos RPC descentralizados incluyen:

dRPC, red Pocket y Ankr

Mejores prácticas para evitar el riesgo de centralización en el desarrollo de aplicaciones descentralizadas

1. Diversificación de proveedores de nodos

Con la selección de proveedores de nodos RPC descentralizados como dRPC, puede evitar los riesgos de centralización. Los proveedores de RPC descentralizados tienen sistemas implementados para garantizar que los nodos funcionen según las características requeridas, como balanceadores de carga, monitoreo de proveedores de nodos e incentivos para buenos actores.

Por ejemplo, dRPC te brinda acceso a un panel para monitorear la diversificación de tu infraestructura de nodos. Aunque no tienes control directo sobre qué nodos usas y cuán descentralizados están, el panel te permite ver cuán descentralizados están los nodos.

Una mirada a la imagen anterior mostró que la conexión está descentralizada entre cuatro proveedores de nodos RPC diferentes ( Besked, drpc-free, drpc-public-multiregion, p2p-validator-optimism-free ). Un índice de descentralización de 0,563 mostró un número acumulativo del nivel de descentralización, donde “uno” es el más descentralizado y “cero” el más centralizado.

2. Monitoreo y gestión de la salud de los nodos

Los desarrolladores deberían poder monitorear los nodos RPC utilizados por su dApp. Esto garantiza la confiabilidad de la dApp. Si bien es posible que no pueda controlar cómo los proveedores de RPC administran sus sistemas, los proveedores de RPC descentralizados como dRPC tienen sistemas implementados para monitorear a los proveedores de nodos RPC.

El panel de control SaaS de dRPC le brinda acceso a análisis integrales para monitorear cómo su dApp interactúa con la infraestructura. En el panel de control de dRPC, por ejemplo, puede monitorear la cantidad total de solicitudes realizadas por su dApp durante los días seleccionados, monitorear la descentralización del nodo RPC y la distribución de solicitudes según la clave API. Incluso tiene acceso para monitorear los registros de errores desde el panel de control.

Además del panel de análisis de dRPC, dRPC tiene un mecanismo de backend para monitorear a los proveedores de nodos y evitar que cometan errores. Lea más sobre estos mecanismos de backend aquí.

Conclusión

Los nodos RPC desempeñan un papel importante a la hora de facilitar la comunicación entre una aplicación descentralizada y la cadena de bloques. Sin embargo, la centralización de los RPC plantea un riesgo importante para su aplicación descentralizada y la red de la cadena de bloques en general. Como se ha visto en los fallos anteriores de los estudios de caso analizados anteriormente, depender de proveedores de RPC centralizados plantea el riesgo de un único punto de fallo y puede provocar una interrupción crítica del servicio de los servicios web3.

Los desarrolladores no carecen de alternativas. Las RPC autoalojadas y descentralizadas ofrecen soluciones confiables que pueden ayudar a crear aplicaciones resistentes. Al adoptar RPC descentralizadas como dRPC , los desarrolladores pueden mitigar el riesgo de centralización y crear aplicaciones potentes, resistentes, seguras y resistentes a la censura.