Asegura tus nodos: migrando de Parity a Geth
Autor: Kunal Roy

El ecosistema de Ethereum depende principalmente de dos proveedores para la unidad fundamental de infraestructura: los nodos. Una de estas organizaciones, Parity Technologies, anunció que se enfocará en otras iniciativas y descontinuará el desarrollo de su software de nodo para Ethereum. En Alchemy decidimos recientemente cambiar de Parity a la otra opción principal, Geth, y te sugerimos hacer lo mismo, ya que está siendo desarrollado activamente por un equipo dedicado. Migrar infraestructura central es una tarea crítica y con muchos matices. A partir de nuestros años de experiencia en infraestructura dando soporte a las principales empresas del mundo en Alchemy, creamos esta guía de migración de Parity a Geth para compartir mejores prácticas y ayudarte a tener una transición exitosa. Compartir esta guía con tu equipo de ingeniería puede ayudarlos a entender las particularidades de los nodos de blockchain y asegurar que tu infraestructura central funcione correctamente.
Contexto
Un breve resumen de lo básico. Las aplicaciones de blockchain requieren ejecutar servidores llamados "nodos" que permiten leer y escribir en la blockchain. Puedes pensar en ellos como una base de datos que almacena la blockchain.
Actualmente existen dos opciones principales de software de nodo: Parity y Geth. Ambos equipos que construyen y mantienen este software de cliente de nodo open source han prestado un servicio enorme a todo el ecosistema de blockchain, y Ethereum no existiría sin ellos. Ambos cuentan con el profundo agradecimiento del equipo de Alchemy.
Recientemente, el equipo de Parity, que contribuyó enormemente a impulsar el crecimiento del desarrollo de blockchain en Ethereum desde el principio, ahora se está enfocando en su propia chain.
Peter y todo el equipo de Geth han hecho un trabajo increíble construyendo un cliente de Ethereum excelente y continúan activamente su desarrollo.

Distribución de clientes de nodo Eth (ethernodes.org/)
¿Por qué deberías migrar?
Los nodos son la infraestructura central de toda empresa de blockchain. Cada vez que tu sistema necesita leer o escribir información en la blockchain, usa tu nodo.
Comparados con la infraestructura web tradicional, los nodos de blockchain son considerablemente más complejos y demandan más tiempo de gestión. Además, configurar un nodo nuevo puede tomar días o semanas debido al tiempo de sincronización. Esto significa que tener problemas con tu infraestructura de nodos puede dejar tu producto no funcional durante semanas.
Para asegurar que tengas una infraestructura estable, robusta y escalable, es esencial ejecutar un cliente de nodo mantenido activamente.
Parity Technologies ha entregado generosamente el código base de Parity Ethereum a su recién creada OpenEthereum DAO, y nos entusiasma ver los avances que se logren en este software de nodo en este medio verdaderamente descentralizado. En contraste, la Ethereum Foundation tiene un equipo de tiempo completo dedicado a construir y mejorar continuamente el software en el futuro previsible.
Usar un proyecto desarrollado activamente significa que los bugs, problemas de estabilidad, forks y otros desafíos desconocidos se resolverán con prontitud y el software mejorará continuamente. Nuestra recomendación es considerar seriamente cambiar tu infraestructura de nodos a Geth.
Este es un proceso bastante complejo, así que considera presupuestar de 2 a 4 semanas de tiempo de ingeniería para completar la transición.
Finalmente, si prefieres enfocarte solo en construir tu producto central sin lidiar con la infraestructura de nodos de bajo nivel, contáctanos. La Alchemy Blockchain Developer Platform fue diseñada desde cero para que sea extremadamente fácil para cualquiera construir grandes productos de blockchain.
Bien, ahora que estás al tanto, ¡empecemos a migrar!
Cómo migrar de Parity a Geth
Los 8 pasos
- Eliminar la dependencia de métodos de namespace específicos de Parity
- Eliminar la dependencia de campos de respuesta específicos de Parity
- Eliminar la dependencia de respuestas específicas de la API para solicitudes incorrectas
- Eliminar la dependencia de códigos de error específicos de Parity
- Configurar el hardware de Geth
- Configurar el software de Geth
- Ejecutar simulaciones de tráfico específicas de la aplicación en los nodos
- Cambiar el tráfico y monitorear el servicio
1. Eliminar la dependencia de métodos de namespace específicos de Parity
Parity y Geth implementan ambos el conjunto genérico del protocolo JSON-RPC de Ethereum establecido por la Ethereum Foundation, y luego sus propios métodos de API suplementarios. Existen algunos métodos de namespace de Parity como parity_allTransactions, que devuelve todas las transacciones pendientes desde la perspectiva de un nodo Parity. En cuanto a funcionalidad, debería haber paralelos en Geth a través de distintos paquetes. En términos de tráfico hacia Alchemy, la omisión más importante en Geth es el módulo trace, cuyos métodos se trasladaron al paquete debug, donde puedes replicar métodos populares de trace como trace_replayTransaction con el análogo debug_traceTransaction.
2. Eliminar la dependencia de campos de respuesta específicos de Parity
A pesar de sus mejores esfuerzos por mantener una implementación consistente, hay algunas diferencias menores. Verifica que no dependas de un campo que se omite en las respuestas de Geth. Hemos visto casos reales en los que la gente dependía de ciertos campos, como el campo transactionLogIndex presente en los objetos logs de eth_getLogs.
En general hemos observado que Geth tiende a cortar y fallar en llamadas de mayor duración para preservar la salud de sus nodos.
3. Diferencias en las respuestas para solicitudes incorrectas
Solicitudes correctamente formateadas que podrían fallar en el EVM (Ethereum Virtual Machine) por cualquier motivo podrían comportarse de manera distinta. Verifica que no dependas de errores de ejecución de la VM en Parity para solicitudes incorrectas, ya que en Geth generalmente devolverán un resultado de 0x. Algunos ejemplos de solicitudes incorrectas a continuación:
- El parámetro de número de bloque proporcionado en eth_call está pendiente.
- Un rango de bloques de eth_getLogs no se puede encontrar en el nodo
- Una eth_call que se ejecuta por más de 5 segundos será cortada automáticamente por el EVM.
4. Códigos de error específicos de Parity
Algunos mecanismos de reintento de clientes dependen de códigos de error específicos de Parity para informarles sobre cierta lógica. Verifica que no dependas de códigos de error que puedan cambiar en Geth. Puedes encontrar una lista más completa de códigos de error JSON-RPC de Parity aquí. En general, hay una pérdida de especificidad en algunos de estos errores, por lo que necesitarás cierta lógica del lado del cliente para manejar estos casos.
5. Configurar el hardware de Geth
Los nodos de Geth deberían poder ejecutarse en el mismo hardware que has estado usando para Parity. Hay algunos atributos clave que hemos notado y discutido con el equipo de Geth que ayudarán a mantener el rendimiento de tu flamante nodo Geth. Hay dos métricas del sistema que vale la pena monitorear de cerca: porcentaje de CPU e iowaits, la tasa a la que el sistema escribe en disco. Hemos visto fuertes correlaciones entre estas métricas para nodos en la práctica cuando empiezan a fallar en llamadas, se vuelven no responsivos o en general entran en un estado degradado. El porcentaje de CPU y el uso de iowait dependen del hardware que estés usando. Para una instancia EC2 m5.2x large, normalmente vemos rendimiento degradado alrededor del 65% de uso de CPU y 1 iowait/segundo para nodos archive.

Iowaits de nodo Geth interno de Alchemy
6. Configurar el software de Geth
Aunque es poco frecuente, hemos visto casos en los que los nodos de Geth se quedan atascados sincronizando en intervalos aleatorios (número de bloque desconocido). En estos casos, la paciencia es la virtud clave y el nodo eventualmente comenzará a sincronizar en cuestión de horas.
Iniciar el proceso de Geth tiene algunas particularidades que discutiremos a continuación. Geth especifica muchas opciones de flags. El flag --pprof tiene muchas métricas útiles que brindan visibilidad sobre la salud del nodo, como su peer count, el tx_pool, y mucha otra información útil expuesta por defecto en el puerto 9090. Otro punto importante a señalar es especificar la señal de terminación como KillSignal=SIGINT. Encontramos que Geth tenía problemas al reiniciar, donde retrocedía hasta el último bloque, ya que no estaba volcando correctamente los bloques o el estado en memoria a disco persistente al momento del apagado.
7. Ejecutar simulaciones de tráfico específicas de la aplicación en los nodos
Hemos visto algunos métodos en Geth que tienen los mismos formatos de solicitud/respuesta pero se comportan ligeramente distinto que la versión de Parity. Un caso real que hemos visto es el siguiente: eth_gasPrice y otros métodos que dependen de estimaciones de gasPrice como eth_estimateGas en Geth utilizan un modelo de estimación que tiende a resultar en predicciones de gasPrice más bajas que en Parity. Esto genera fallos de transacción inesperados como: Transaction gas price supplied is too low. There is another transaction with the same nonce in the queue. Try increasing the gas price or incrementing the nonce. Puedes mitigar esto aumentando el gas price, o usando otras fuentes de terceros, como Eth Gas Station para obtener tus estimaciones de precio.
8. Cambiar el tráfico y monitorear el servicio
¡Finalmente llegó el momento de hacer el cambio! Mueve tu tráfico a Geth y monitoréalo cuidadosamente durante unos días. Si te encuentras con algún otro problema inesperado, no dudes en contactar al equipo de Geth o hablar con nosotros.
¿Buscas una forma más fácil de migrar?
¡Esperamos que esta guía haya sido útil para ayudarte a navegar el proceso de migración de Parity a Geth! Si tienes alguna pregunta o dificultad, no dudes en contactarnos, estamos aquí para ayudar.
Además, si quieres potenciar tu desarrollo con una plataforma que hace significativamente más fácil construir y lanzar aplicaciones de blockchain sin tener que lidiar con tareas de bajo nivel como la gestión de nodos, ¡habla con nosotros!
En Alchemy, creamos la Blockchain Development Platform desde cero para facilitar la vida de los desarrolladores. Ahora, a través de un potente conjunto de herramientas de desarrollo, soporte 24/7 y una novedosa plataforma de infraestructura de blockchain escalable globalmente, puedes ahorrar miles de horas de desarrollo, hacer que tu aplicación sea 107 veces más confiable y crear productos mucho mejores para tus usuarios. ¡No dudes en contactarnos para saber más!
Buena suerte con tu migración a Geth.
Es 2020. Cuídate y mantén tus nodos saludables también.
Regístrate para obtener una cuenta gratuita de Alchemy aquí.
Acerca de Alchemy
Alchemy ofrece la Blockchain Development Platform líder, que da soporte a productos usados por millones de usuarios en 197 países. El motor de infraestructura novedoso de la Alchemy Platform y su conjunto de herramientas de desarrollo sin comparación permiten a los creadores construir fácilmente grandes productos basados en blockchain en una fracción del tiempo. Respaldado por Stanford University, Coinbase, el Chairman de Google, Charles Schwab y destacados ejecutivos de tecnología y finanzas, el equipo aporta un profundo conocimiento en desarrollo de blockchain e infraestructura masivamente escalable, construido a lo largo de décadas de experiencia en gigantes tecnológicos como Google, Microsoft y Facebook.
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

¿Con qué proveedor de RPC deberías construir en Tokio?
Comparamos cinco de los proveedores de RPC que sirven Tokio en cinco cadenas. Así se comparan, y dónde importan las diferencias para los equipos sensibles a la latencia.

Diseño de lecturas RPC de Solana para velocidad y confiabilidad líderes en la industria
Alchemy tiene la latencia de lectura de Solana más baja: 9.21 ms, cerca de 26% más rápido que el siguiente proveedor.

El costo de la latencia en el trading onchain
Los costos de latencia se manifiestan como la brecha entre el estado observado y la ejecución. Aquí se explica dónde aparece el retraso, por qué importa el p95 y cómo evaluar tu ruta RPC.