No soy Alicia, pero hace algunos meses me caí en un rabbit hole. Empecé haciendo un par de preguntas sobre nodos en Ethereum y terminé corriendo mi propio nodo. En el camino escribí varios artículos, entre ellos sobre capas, nodos, clientes y consenso. Cuanto más aprendía, más cuenta me daba de lo que no sabía. Y cuanto más aprendía de lo que no sabía, el ciclo se volvía a repetir.
Ahora considero que sé muchísimo más que hace uno o dos años sobre qué es Ethereum y cómo funciona. Pero eso no me sacó del loop. Al contrario: me dejó en ese umbral móvil de "todavía no sé lo que no sé".
Antes de seguir yéndonos por las ramas, vamos a la historia que nos convoca hoy: cómo monté mi propio nodo de Ethereum con conocimientos previos bastante limitados, equipamiento muy sencillo, presupuesto cero, y cómo Google Cloud me bajó el proyecto a mitad de camino por estar trabajando con blockchain.
Claro que nada de esto hubiera sido posible sin a little help from my friends. Mención especial a Enti de Lido, Chuy García de DappNode, Lorenzo Hardoy y la comunidad de Club de Nodos en general. No hubiera hecho absolutamente nada sin su ayuda.
El episodio cobra particular sentido en estos días, en los que Google Cloud le suspendió temporalmente la cuenta a Railway y después se la devolvió. Railway no es una empresa cripto, sino una plataforma cloud para desplegar aplicaciones, servicios y backends. Pero parte del ecosistema Web3 también la usa para bots, indexers, autenticación con wallets y otras piezas de infraestructura. Entonces la pregunta vuelve a aparecer: ¿hasta dónde puede crecer Ethereum corriendo sobre infraestructura centralizada de grandes corporaciones de internet? Mi historia es una versión chica de esa pregunta. Pero la pregunta es la misma.
El problema
Si estamos en Ethereum, salvo que seamos parte de la runfla de extractivistas que todos conocemos, es porque en algún punto estamos enamorados de la libertad y de todo lo que creemos que las tecnologías descentralizadas, o descentralizadoras, pueden aportarle a ese hermoso ideal.
Por eso me parece bastante natural que, tarde o temprano, a cualquier usuario que permanece el tiempo suficiente en Ethereum, se haya convertido en builder o no, se le cruce por la cabeza la idea de montar su propio nodo. Cuando empezamos a entender cómo funciona la cosa, y vemos que en nuestro uso diario del protocolo todavía lidiamos con varias instancias que se alejan del ideal descentralizado, es normal que un día nos paremos y digamos: "pará, ¿por qué no tengo mi propio nodo? O todavía mejor: ¿por qué no tengo un nodo validador?".
Después viene la primera respuesta lógica: porque no tenés 32 ETH, ni una máquina con el disco y la RAM suficientes, y probablemente también te esté costando pagar la boleta de la electricidad.
Pero esperen: hay vida después de esa trompada. No es el paraíso, pero quedan signos vitales.
El workshop
Hace aproximadamente un año me anoté en un workshop que dio Enti, de Lido Finance, para montar un nodo, según decía la propuesta, de una manera fácil y sin necesidad de grandes recursos. El problema de la falta de hardware se resolvía usando una virtual machine en Google Cloud. Eso mismo resolvía, al menos por un rato, el problema de la factura de la luz. El problema de los 32 ETH se resolvía deployando en testnet.
Para muchos puede ser una obviedad, pero para mí no lo era. Sé bien que muchísimos nodos y validadores de Ethereum corren en infraestructura cloud, con AWS como caso arquetípico. Pero la verdad es que lo veía como algo ajeno. No pensaba que se pudiera configurar de manera relativamente sencilla y que, encima, hubiera opciones gratis para pasar del estudio a la acción y vivenciar en primera persona cómo late el corazón de Ethereum entre esa diástole y sístole perfectamente coordinadas de ejecución y consenso.
La solución estaba ahí nomás: un nodo en testnet usando los créditos gratuitos de Google Cloud. La propuesta era atractiva. No hacía falta hardware propio. No hacía falta una conexión estable de casa. Solo una máquina virtual gratuita en la nube, una guía bien hecha y unas horas para seguirla con atención. Al final del proceso, si todo salía bien, uno terminaba siendo operador de un nodo validador en testnet.
El stack
Lo que armamos en el workshop era esto. Una máquina virtual en Google Cloud con Debian 12, 16 GB de RAM y 300 GB de disco. Encima, DappNode, una distribución que orquesta clientes de Ethereum y otros servicios on-chain con una interfaz visual amigable. Como cliente de ejecución, Reth, escrito en Rust y relativamente joven dentro del menú de clientes disponibles. Como cliente de consenso, Lighthouse. Como signer, Web3Signer. Y como capa final, MEV-Boost conectado a relays validados por Lido.
Para conectarse a la interfaz de DappNode, una VPN con WireGuard. Aunque suene raro, era mi primera vez con una VPN. No era el corazón del workshop, pero sí una pieza que tuve que entender mientras avanzaba.
La testnet elegida fue Hoodi. Para generar las keys del validador se usa una herramienta llamada Wagyu, que arma el keystore y los datos del depósito apuntando a la bóveda de retiros de Lido en Hoodi.
Google Cloud me bajó el proyecto
El nodo levantó. Empezó a sincronizar. Los bloques empezaron a llegar y los logs de Reth eran un río continuo de hashes y números de bloque. Ver en mi pantalla los bloques de Ethereum llegando a mi propia copia del estado de la red, verificados por mi propia máquina, no lo voy a negar, fue bastante emocionante.
Era, por fin, pasar del artículo a la experiencia. De leer sobre clientes, consenso y nodos a ver cómo esa maquinaria empezaba a moverse en una VM que yo había levantado siguiendo una guía, preguntando, equivocándome y volviendo a probar.
Hasta que un día llegó un e-mail de Google Cloud informándome que mi proyecto había sido suspendido. Motivo: "minar criptomonedas".
Apelé. Mandé una nota explicando que se trataba de un proyecto educativo en testnet, que el nodo no estaba validando ni recibiendo recompensas, y que no había actividad económica de ningún tipo.
Menos de una semana después, llegó la confirmación de reactivación.
La historia terminó bien, pero la pregunta que dejó quedó dando vueltas. Si una alerta automática puede bajarte el proyecto sin previo aviso acusándote de minar criptomonedas, ¿qué garantías tiene cualquiera de los miles de nodos y validadores de Ethereum que hoy corren sobre Google Cloud, AWS o Azure? Lo de Railway unos meses después fue una versión más grave, pero el mecanismo es exactamente el mismo.
El bug del Web3Signer
El nodo seguía sincronizado, los clientes en verde, los peers a 100. Lo único que faltaba era el paso final: importar las keys del validador al Web3Signer para empezar a validar en la testnet.
Ahí me trabé. Cada vez que intentaba importar el keystore, la interfaz me devolvía un error genérico que decía literalmente "Error: [object Object]". Un mensaje que aparentemente significa que algo en el código serializó un objeto donde tendría que haber serializado un texto, y el resultado es que no sabés qué pasó. No puedo dar fe de esto, pues vibecoder y etc.
El problema con el Web3Signer nunca se terminó de resolver en esa instancia. No por falta de ayuda de los mentores, que tuvieron paciencia infinita y respondieron cada vez que escribí, sino porque la combinación específica de mi setup tenía algún detalle que se nos escapaba.
Terminé sin haber validado. El nodo corrió, sincronizó, los clientes funcionaron. Pero la última milla, la de efectivamente firmar bloques en la testnet como validador, no la crucé.
Un par de meses después tuve que apagar la máquina virtual y, en consecuencia, el nodo. No lo indiqué antes, pero la prueba gratuita de Google Cloud, como toda prueba gratuita, en algún momento llega a su fin. En ese momento, no había presupuesto para seguir sosteniéndolo.
Lo que aprendí igual
Aunque no haya validado, el ejercicio sirvió para entender un montón de cosas que antes solo conocía en abstracto. Cómo se levanta una VM. Qué es, para qué sirve y cómo se usa una VPN. Cómo conviven los clientes de ejecución y consenso en una misma máquina. Qué tipo de hardware requiere un nodo. Cuánto disco consume. Cuántos peers se conectan. Qué pinta tiene un log de un cliente real cuando está procesando bloques.
También entendí algo más político: que correr un nodo, incluso en testnet, sigue teniendo fricciones inesperadas. Y que el debate sobre cuánto de Ethereum vive realmente sobre infraestructura centralizada no es nuevo, pero cada tanto se prende fuego de nuevo. Hace poco le pasó a Railway, que se quedó sin sus VMs en Google Cloud de un día para el otro, aunque después se las devolvieron. Y aunque AWS es el caso arquetípico de cloud para nodos y validadores en Ethereum, también se cae cada tanto, y cuando se cae no es chiste: arrastra a una parte importante de la red detrás suyo. Lo mío fue una versión menor de la misma película. Lo de Railway, una versión más fea. La de AWS, una versión a escala industrial. La pregunta sigue ahí, abierta.
Por último, la paradoja o contradicción: las herramientas de cloud pueden democratizar el acceso a los nodos para gente de a pie como uno, pero por otro lado, como quedó demostrado en tan corto experimento, no ser dueño de los equipos tiene un precio, que no es monetario: la última palabra sigue quedando en la boca del que tiene en la mano la palanca de apagado. Por eso dije al principio, no vengo a predicarles el paraíso ni la panacea en este artículo, pero sí a contarles de una herramienta que bien entendida y en determinadas circunstancias puede aportar, con sus limitaciones, a la descentralización de Ethereum. Y específicamente, en casos como el mío, puede aportar aún mucho más a la formación y capacitación del ethernauta empedernido.
La espina en el ojo
Este año lo voy a retomar. Por dos razones. Una: nadie le va a decir a un argentino que una prueba gratuita se terminó. Buscaremos la forma de gozar de otra... y otra... y otra... Bromas aparte, hoy sostener una VM para un proyecto como este no sería para nada caro, en un mundo en el que ya nos acostumbramos a pagar distintos servicios en internet: suscripciones a apps, plataformas de streaming, plataformas de IA y un largo etcétera.
Ahora quiero llegar a la etapa de validación, y como soñar no cuesta nada, por qué no, el día de mañana pasar a mainnet.
Hoy sé bastante más que cuando arranqué, pero también sé bastante más de lo que no sé. Vendrá Web3Signer, vendrá staking, vendrá MEV, vendrá correr algo fuera de la nube, vendrán cosas que ni siquiera todavía aparecen en mi radar.
Y vendrá, también, lo que el caso Railway deja como tarea para todo el ecosistema: pensar seriamente cómo se sigue construyendo Ethereum cuando una parte importante de su infraestructura sigue corriendo sobre la nube de unos pocos. No es una pregunta que yo solo vaya a responder, ni mucho menos. Pero ahora la entiendo distinto.
Está bien que sea así. Es lo que tiene caerse en un rabbit hole: que el fondo siempre está más abajo. Pero cada tanto, mientras uno cae, puede agarrarse de una rama, mirar alrededor y decir: pucha, qué lindo es enterarme de que existe todo esto de lo que hasta recién ni sabía que no sabía.