The inadvertant Ethereum hard fork took a lot of people by surprise — here, we break down how Ethereum can be both decentralized with points of centralization at the same time.
[wps_section size=”full-boxed” height=”auto” background_color=”#1e73be” background_size=”cover” background_repeat=”no-repeat” background_mode=”fixed” align_content_vertical=”center” align=”left” content_width=”100%” content_color=”#fff” padding=”12″ margin=”15″] [wps_lists icon=”arrow-right” icon_color=”#fff”]- Centralizar una red descentralizada
- Fallo de sincronización
- Por qué confiamos en Infura
- Superar la centralización
Es imposible confiar en las aplicaciones que usamos todos los días sin confiar en las instituciones subyacentes que garantizan que se respeten todos los acuerdos implícitos y explícitos.
Esta confianza centraliza el poder alrededor de esas instituciones y deja al individuo impotente. Las cadenas de bloques como Ethereum descentralizan el poder en un conjunto bien definido de reglas que son ejecutadas por una red de computadoras de una manera abierta y justa para todos.
La descentralización es la clave para transferir el poder de las instituciones a los individuos. Por eso es tan importante. Una cadena de bloques que se ejecuta solo en un servidor central no es mejor que el status quo.
Centralizar una red descentralizada
Para el ojo inexperto, las aplicaciones de Ethereum a menudo parecen descentralizadas. Los contratos inteligentes se manifiestan como interfaces basadas en web que muestran datos obtenidos de la actividad en cadena. Los fondos de los usuarios están custodiados por claves privadas almacenadas en carteras locales. Las transacciones se propagan rápidamente a los mineros y se incluyen en bloques. Sin embargo, aunque la red Ethereum en sí está lo suficientemente descentralizada, hay muchos puntos centrales donde la falla puede comprometer a los usuarios.
Por ejemplo, si el servidor de una DApp está infiltrado, es posible que se complete la interfaz web con información falsa. Esto podría hacer que los usuarios tomen decisiones que de otro modo no tomarían. O tal vez se supere el proveedor de billetera de un usuario. Sería posible desconectar al proveedor de billetera de la red y no propagar las transacciones de los usuarios a los mineros, censurando así su capacidad para realizar transacciones con la cadena.
Estos son exactamente los escenarios para los que se creó Ethereum, y el 11 de noviembre, la incapacidad del ecosistema para evitar esos escenarios se hizo evidente.
Fallo de sincronización
A las 7:08 UTC del 11 de noviembre, se extrajo el bloque 11234873 que contenía una transacción que algunas versiones antiguas de go-ethereum (Geth) rechazaron como inválida. Aunque el número de clientes en la red que ejecutan esta versión desactualizada fue significativamente superado en número por los clientes actualizados, uno de los operadores que ejecuta la versión desactualizada fue el popular proveedor de infraestructura, Infura.
A las 7:13 UTC, el sistema de monitoreo de Infura alertó al equipo de que se estaba quedando atrás de la punta de la cadena. Durante las siguientes cinco horas, trabajaron en el problema e implementaron una solución urgente para reanudar el servicio. Según todos los informes, manejaron la situación bien y con prisa. Desafortunadamente, la realidad es que durante aproximadamente cinco horas, muchas aplicaciones de Ethereum estuvieron rastreando una cadena no válida y la mayoría de los usuarios no pudieron enviar transacciones.
Aunque una división de la cadena es el peor error en el que puede incurrir una cadena de bloques, es inevitable si los operadores no se mantienen actualizados. Antes de este evento, generalmente se entendía que para mantenerse sincronizados, solo se requerían para los operadores las actualizaciones que coincidían con las bifurcaciones programadas. Por esta razón, Infura asumió que cualquier otra actualización crítica de consenso sería anunciada de manera más liberal por el equipo de go-ethereum.
Debido a que operan versiones personalizadas de go-ethereum que se ajustan específicamente para satisfacer las demandas de su infraestructura de alto rendimiento y miles de millones de solicitudes por día, es difícil para ellos actualizar sus nodos cada dos semanas para mantenerse sincronizados con el repositorio upstream. Es por eso que todavía estaban ejecutando sus versiones personalizadas de go-ethereum v1.9.9 y v1.9.13, a pesar de que la última versión era la v1.9.23.
Por qué confiamos en Infura
Está claro que si las DApps simplemente no dependieran de Infura, el impacto de la división de la cadena se habría reducido drásticamente. Entonces, ¿por qué la mayoría de las interfaces de DApp no obtienen sus datos directamente de los nodos de Ethereum?
En primer lugar, la mayoría de los usuarios no ejecutan sus propios nodos. Ejecutar un nodo es costoso y requiere experiencia para configurarlo correctamente, especialmente en un entorno de producción. Por lo tanto, la carga la asumen las DApps.
Infura ha envuelto la funcionalidad de los clientes de Ethereum y ha creado una API sencilla que permite a cualquier desarrollador escribir software que interactúe con la red Ethereum. El producto que han creado es excelente y, a menudo, más económico que ser autosuficiente. Esto hace que las DApps usen Infura de forma rutinaria como su única fuente de verdad.
En segundo lugar, los clientes de Ethereum solo son buenos para responder consultas simples como “¿Cuál es el saldo de Alice?”. Las consultas más complicadas son prohibitivamente caras de responder utilizando solo un cliente Ethereum. Incluso si los usuarios tuvieran su propio nodo local, no podrían obtener respuestas a consultas como “¿Cuánto gastó Alice entre marzo y abril?”.
El quid es que las DApps a menudo dependen de estas consultas enriquecidas y, por lo tanto, están relegadas a mantener sus propias bases de datos fuera de la cadena para respaldar su aplicación. Por lo general, estas bases de datos se crean escuchando la cadena en su propio servidor, registrando los eventos a medida que ingresan y luego organizando y agregando los eventos en una forma que se adapte a las consultas deseadas. Exigir que todos los usuarios hagan esto crearía mucha fricción en términos de adquirir nuevos usuarios, por lo que se proporciona al mundo con regularidad a través de una API central.
Incluso si una DApp es proactiva y ejecuta su propio nodo para poblar su base de datos, evitando Infura por completo, sus usuarios se conectan a Infura de forma predeterminada a través de la billetera MetaMask. Si bien es posible conectarse a un nodo Ethereum personal a través de MetaMask, la mayoría de los usuarios ni siquiera comprenden el problema de conectarse a una única fuente y, en consecuencia, no pueden ajustar su comportamiento.
Aunque Infura es un ejemplo destacado de centralización en el ecosistema Ethereum, está lejos de ser el único. Etherscan, oráculos, API de DApp, incluso una conexión singular a Internet, son susceptibles de coerción. Depender de cualquiera de estos servicios para obtener información resultaría en confiar completamente en ese operador.
Es sorprendentemente difícil ser auto-soberano utilizando una tecnología cuyo objetivo principal es la auto-soberanía. Así que no confíes, verifica.
Superar la centralización
Las cadenas de bloques son una primitiva de descentralización. Mantener esta propiedad para todos los usuarios es un problema de herramientas. Cualquiera con conocimientos suficientes ya puede ejecutar su propio nodo completo e interactuar directamente con la red hoy. Pero este no es el objetivo. El objetivo es permitir que todos interactúen con las aplicaciones, sin necesidad de confiar en ninguna institución; para ello, las herramientas deben mejorar.
El statu quo es utilizar una única fuente de verdad al interactuar con la cadena. Esto centraliza inherentemente el flujo de información y requiere confianza en esa fuente. También contrasta mucho con los nodos completos, que se conectan con 25-50 pares únicos. Los nodos completos pueden mantener una vista precisa de la red incluso si solo uno de sus pares es honesto.
Es fundamental que continuemos desarrollando herramientas que permitan a los usuarios mantener su propia visión de la red, basándose en muchas fuentes diferentes. Hay muchas técnicas que lo facilitarán, incluidos clientes ligeros, testigos de bloque, pruebas estatales, redes de recuperación de datos y pruebas de conocimiento cero.
Cada técnica tiene diferentes supuestos de configuración y umbrales de seguridad. En última instancia, una combinación de ellos se integrará en un software que los usuarios finales utilizan todos los días. “Simplemente funcionarán” de la misma manera que Internet “simplemente funciona”, lo que nos permitirá lograr nuestro objetivo de aplicaciones descentralizadas para todos.
Mientras tanto, es importante estar consciente de los puntos de falla que existen hoy.
