Descripción general de los desafíos de seguridad

Una característica definitoria de las cadenas de bloques es la naturaleza atómica de las transacciones: una vez que se registra una actualización en la cadena de bloques, no hay oportunidad de intervención o reversión. Esto proporciona fuertes garantías de consistencia y seguridad a nivel de protocolo, pero expone a los usuarios a un mayor riesgo operativo: un solo error, una clave comprometida o una aprobación apresurada pueden provocar una pérdida irreversible.

Como resultado, una carga significativa de seguridad recae sobre el usuario. Para usar Ethereum de manera segura, las personas y las organizaciones deben guardar y administrar claves de forma segura, interactuar con aplicaciones en cadena y usar sus claves para firmar transacciones para transferir activos o actualizar el estado de Ethereum de otra manera.

Cada uno de estos requisitos introduce riesgos como el compromiso o la pérdida de claves, aprobaciones apresuradas o desinformadas, o el compromiso del software de la billetera en el que confían los usuarios para informarse y guiarse a través de la interacción con Ethereum.

1.1 Gestión de claves

Muchos usuarios no están equipados para administrar claves criptográficas de forma segura.

La mayoría de las billeteras de software ampliamente utilizadas dependen de que los usuarios almacenen de forma segura frases semilla que representan su clave privada criptográfica subyacente, lo que a menudo los lleva a usar soluciones alternativas inseguras como almacenar frases semilla en texto sin formato, en servicios en la nube o escribirlas en papel.

Las billeteras de hardware son una alternativa que permite a los usuarios administrar una clave criptográfica almacenada dentro de un dispositivo físico de propósito especial. Sin embargo, las billeteras de hardware tienen sus propios defectos y superficie de ataque. Las billeteras de hardware pueden perderse, dañarse o ser robadas. Muchas billeteras de hardware no son de código abierto y pueden tener cadenas de suministro opacas, lo que aumenta el riesgo de un ataque a la cadena de suministro donde se venden dispositivos comprometidos en el mercado.

Ya sea que las claves se administren en una billetera de software o de hardware, muchos usuarios están comprensiblemente nerviosos por la autocustodia cuando puede verse comprometida por robo físico o asalto.

Los usuarios empresariales e institucionales enfrentan desafíos adicionales en la gestión de claves. Si los empleados individuales tienen claves (por ejemplo, como parte de una billetera multifirma), la organización debe poder reemplazarlas y crear otras nuevas debido a los cambios de personal a lo largo del tiempo. Los requisitos de cumplimiento en diferentes industrias y jurisdicciones pueden requerir flujos de trabajo personalizados o pistas de auditoría no compatibles con el software de billetera existente. En algunos casos, los usuarios empresariales recurren a custodios externos para los activos digitales, lo que puede introducir otra capa de riesgos de seguridad a considerar.

1.2 Firma a ciegas e incertidumbre de las transacciones

Los usuarios aprueban transacciones de forma rutinaria "a ciegas" sin entender lo que están haciendo. Las billeteras a menudo presentan datos hexadecimales sin procesar, una dirección de contrato truncada u otra información que no es suficiente para que el usuario comprenda las consecuencias de una transacción determinada. Esto deja a los usuarios de todo tipo vulnerables a contratos inteligentes maliciosos, phishing, estafas, interfaces falsificadas, compromisos de front-end y errores básicos del usuario.

1.3 Gestión de aprobaciones y permisos

En muchas aplicaciones de Ethereum, es común que los usuarios otorguen ciertos permisos a la aplicación subyacente como parte del uso normal. Por ejemplo, un usuario podría otorgar a un intercambio descentralizado como Uniswap permiso para mover sus tokens con el fin de intercambiarlos por ETH.

Estas aprobaciones pueden tener límites en la cantidad, pero muchas billeteras otorgan por defecto aprobaciones ilimitadas sin fecha de vencimiento. No hay forma de que los usuarios administren o revisen sus aprobaciones pendientes desde la mayoría de las billeteras.

Esto puede exponer a los usuarios a aplicaciones maliciosas o frontends comprometidos, porque el patrón predeterminado para muchos usuarios es otorgar aprobaciones ilimitadas que pueden usarse para vaciar sus fondos. Incluso si un usuario otorga una aprobación a un contrato inteligente legítimo, si ese contrato se viera comprometido más tarde mientras la aprobación sigue vigente, entonces el contrato comprometido podría vaciar los fondos del usuario.

Esto es igualmente un riesgo para los usuarios organizacionales. Por ejemplo, una organización podría optar por otorgar a un enrutador DEX una asignación ilimitada de USDC por conveniencia operativa, lo que luego los expone a riesgos si se actualiza el contrato del enrutador.

1.4 Interfaces web comprometidas

La mayoría de los usuarios no interactúan directamente con un contrato inteligente, sino a través de una interfaz web mediante su dispositivo móvil o navegador web.

Estos frontends pueden ser vulnerables a ataques a través de medios familiares como el secuestro de DNS, la inyección maliciosa de JavaScript, el alojamiento inseguro o varias dependencias de terceros. Una UX de aplicación comprometida puede redirigir a usuarios de todo tipo a contratos inteligentes maliciosos o llevarlos a firmar transacciones engañosas.

1.5 Privacidad

La privacidad puede mitigar o magnificar los riesgos de seguridad para usuarios de todo tipo.

Las protecciones de privacidad más débiles exponen a los usuarios individuales a una variedad de amenazas dirigidas como phishing, explotación, estafas o ataques físicos. Muchos patrones comunes de UX exponen a los usuarios, por ejemplo, la reutilización de direcciones, los datos KYC y otras filtraciones de metadatos.

Para las instituciones y empresas, la privacidad suele ser un requisito comercial fundamental por razones de cumplimiento o ciertos casos de uso. Además de esos problemas, puede crear exposición a riesgos de seguridad específicos. Por ejemplo, un usuario de un sistema de cadena de suministro construido en Ethereum puede requerir fuertes garantías de privacidad para proteger los activos de propiedad intelectual que podrían verse comprometidos si el sistema fuera transparente.

1.6 Fragmentación

Hay una falta de consistencia en cómo las diferentes billeteras manejan comportamientos centrales como mostrar transacciones, manejar aprobaciones o etiquetar contratos. Esta fragmentación de la experiencia del usuario agrega fricción a la capacidad del usuario para aprender a usar las billeteras de manera segura y aumenta los riesgos.

Por ejemplo, los usuarios no pueden confiar en señales de UX consistentes para protegerse del phishing y la suplantación de identidad, ya que difieren entre las billeteras. Los usuarios no pueden formarse expectativas confiables sobre cómo funciona Ethereum si cada herramienta funciona de manera diferente.

La seguridad de los contratos inteligentes ha mejorado radicalmente a lo largo de la historia de Ethereum. Los primeros incidentes de seguridad como el hackeo de The DAO motivaron al ecosistema a profesionalizarse y mejorar las salvaguardas en todo el ciclo de vida del software que conduce a que el código se despliegue en cadena. Los avances clave incluyen:

• La auditoría de seguridad se convirtió en una práctica estándar, con varias firmas de seguridad ingresando al ecosistema y desarrollando experiencia.
• Las herramientas, las pruebas y los sistemas de análisis estático maduraron y se convirtieron en una práctica estándar.
• Las bibliotecas de componentes comunes preauditados brindaron a los desarrolladores bloques de construcción seguros por defecto.
• Se adoptaron técnicas de verificación formal, especialmente para puentes, sistemas de staking y contratos de alto valor.
• La cultura de seguridad y las mejores prácticas del ecosistema mejoraron.
• La creación de importantes programas de recompensas que fortalecieron la capa de aplicaciones.

Sin embargo, persisten debilidades y áreas de mejora en este dominio.

2.1 Vulnerabilidades de los contratos

A pesar de los avances en la seguridad de los contratos inteligentes, todavía existen vulnerabilidades que pueden provocar problemas de seguridad importantes, que incluyen:

• Riesgo de actualización de contratos. Algunos contratos están diseñados para ser modificables después del despliegue, para permitir que un equipo de desarrollo continúe actualizando y mejorando una aplicación. Sin embargo, esto introduce riesgos. Las actualizaciones podrían resultar en nuevas vulnerabilidades o en la pérdida total de los fondos de los usuarios en el caso de una actualización maliciosa.
• Reentrada, donde el contrato A llama a un contrato externo B antes de actualizar su propio estado interno, y el contrato B vuelve a llamar al contrato original A antes de que finalice la primera llamada.
• Uso inseguro de bibliotecas externas, donde un contrato llama a una biblioteca externa que puede no estar auditada, ser maliciosa o actualizable.
• Componentes no auditados. Si bien la auditoría y el uso de bibliotecas estándar han mejorado, los desarrolladores a veces confían en componentes no auditados en sus aplicaciones.
• Fallas de control de acceso, donde los permisos están mal configurados o definidos de manera demasiado amplia, lo que permite a los atacantes realizar acciones maliciosas.
• Acceso no autorizado, donde un actor malicioso obtiene una clave privada que es capaz de controlar el contrato.
• Puentes e interacciones entre cadenas. Los puentes y los protocolos entre cadenas introducen una complejidad adicional, y los atacantes pueden explotar las debilidades en cómo se transmiten o validan los mensajes entre cadenas.
• Uso indebido de firmas o delegación de cuentas de propiedad externa (EOA). Las aplicaciones maliciosas pueden engañar a los usuarios para que firmen la delegación completa de su cuenta a un tercero, lo que permite el robo. Las aplicaciones maliciosas también pueden usar mensajes firmados por el usuario de formas inesperadas, por ejemplo, en un ataque de repetición.
• Riesgo emergente de errores introducidos por la generación de código de IA o herramientas de refactorización automatizadas.

2.2 Experiencia del desarrollador, herramientas y lenguajes de programación

Las vulnerabilidades terminan en el código desplegado como resultado de un error del desarrollador. Las herramientas mejoradas para desarrolladores han hecho que sea significativamente más fácil desplegar contratos inteligentes seguros. Sin embargo, los problemas persisten.

• Falta de valores predeterminados seguros en marcos populares. Algunas herramientas priorizan la flexibilidad o la velocidad sobre la seguridad, estableciendo valores predeterminados inseguros como aprobaciones de tokens ilimitadas en la función approve(), o no incluyendo patrones de control de acceso por defecto.
• Código personalizado para controles operativos avanzados. Los usuarios institucionales con requisitos operativos complejos a menudo deben crear las funciones requeridas desde cero, lo que aumenta el riesgo de vulnerabilidades. Hay una falta de componentes o marcos seguros estandarizados para flujos de trabajo de seguridad avanzados.
• Cobertura de pruebas inconsistente en todas las pilas de herramientas, así como una falta de normas en torno al uso de técnicas probadas como el fuzzing o la verificación de invariantes.
• Baja adopción de métodos de verificación formal. Las técnicas de verificación formal son poderosas, pero son complejas, costosas, requieren experiencia especializada en el dominio y no están bien integradas en los flujos de trabajo estándar de los desarrolladores, donde podrían usarse mucho antes en la producción de software para verificar la seguridad en la etapa de especificación.
• Problemas relacionados con la verificación de contratos. Los usuarios y desarrolladores no pueden evaluar fácilmente la confiabilidad de los contratos desplegados, el alcance de su validación de seguridad (por ejemplo, auditorías de código) o la presencia de riesgos latentes. Si bien existen soluciones para este propósito, persisten muchos problemas. Las herramientas que abordan estos problemas no se adoptan ampliamente, los estándares que unificarían los enfoques siguen fragmentados y algunos de los servicios existentes son en sí mismos dependencias centralizadas.
• Riesgos del compilador. Los compiladores (el software que convierte el código legible por humanos como Solidity en el código de bytes utilizado por la propia EVM) pueden tener fallas que introducen errores en los contratos inteligentes antes de ser desplegados. El ecosistema de Ethereum hoy en día depende principalmente del compilador solc, lo que significa que un error podría tener efectos generalizados.
• Diversidad y profundidad de los lenguajes de programación. Aunque Solidity tiene un ecosistema de herramientas profundo construido sobre él, algunos desarrolladores desean características de seguridad más modernas que se encuentran en otros lenguajes de programación, como la seguridad de la memoria.

2.3 Evaluación de riesgos del código en cadena

Las instituciones y empresas tienen procesos, estándares y requisitos existentes para evaluar la seguridad de la tecnología y los sistemas de los que dependen. Sin embargo, los marcos existentes a menudo no se adaptan claramente a los contratos inteligentes, ya que generalmente asumen código mutable, control de cambios centralizado y líneas claras de responsabilidad o responsabilidad legal. Los sistemas construidos sobre contratos inteligentes a veces pueden romper esas suposiciones, lo que dificulta que las organizaciones adopten Ethereum y gestionen el riesgo de manera adecuada.

Estos sistemas son una superficie de ataque tanto para la capa de la billetera y la aplicación (por ejemplo, puntos de conexión RPC para billeteras) como para el propio protocolo de Ethereum (por ejemplo, muchos validadores están alojados en infraestructura en la nube). El compromiso de la clave privada, el phishing y la falta de controles de acceso granulares pueden provocar interrupciones a gran escala, robos o cambios no autorizados, incluso si el protocolo de la cadena de bloques subyacente sigue siendo seguro.

3.1 Cadenas de capa 2 (l2)

Las cadenas de capa 2 (l2) sirven como extensiones para Ethereum, permitiendo entornos más rápidos y con tarifas más bajas mientras conservan algunas de las garantías de seguridad características de la red principal de Ethereum (dependiendo de su diseño específico). Sin embargo, también tienen sus propias superficies de ataque distintas, que incluyen:

• Complejidad de los activos puenteados de múltiples saltos. Cuando los activos viajan entre la capa 1 (l1) y múltiples l2, están expuestos a múltiples conjuntos de contratos, todos los cuales deben ser seguros. La contabilidad no coincidente o las interrupciones en las cadenas de l2 pueden introducir vulnerabilidades que pueden ser explotadas por los atacantes.
• Las l2 de rollup dependen de sistemas de prueba para hacer cumplir la exactitud de las actualizaciones de estado. Los errores o configuraciones incorrectas en estos sistemas pueden detener o evitar la finalización, o permitir la finalización de actualizaciones de estado falsas que conducen a la pérdida de fondos de los usuarios.
• Los consejos de seguridad son grupos de poseedores de claves que sirven como un mecanismo de "respaldo" para actualizar el software de l2 o responder a ciertas emergencias. Los propios consejos de seguridad plantean riesgos, ya que el compromiso o la colusión entre los miembros podría poner en riesgo los fondos de los usuarios o congelar los activos.

Consulte L2BEAT (opens in a new tab) para obtener un marco detallado y un panel de monitoreo que evalúa y compara el rendimiento y la seguridad de las l2.

3.2 Infraestructura de RPC y nodos

Las aplicaciones de Ethereum dependen de un pequeño número de proveedores de infraestructura para el acceso a RPC, API y servicios de nodos. Esto incluye proveedores de infraestructura específicos de cripto, así como servicios tradicionales en la nube que se utilizan comúnmente para alojar nodos (por ejemplo, AWS, Cloudflare, Hetzner).

Si estos proveedores de infraestructura se desconectaran o intentaran censurar o limitar el acceso, a muchos usuarios se les podría impedir acceder a Ethereum a través de su billetera o aplicación, hasta que pudieran migrar a un nuevo RPC u otro proveedor de infraestructura. Algunos de estos proveedores han suspendido o cerrado previamente cuentas asociadas con la actividad de la cadena de bloques, lo que genera preocupaciones sobre su confiabilidad a largo plazo para las aplicaciones descentralizadas.

3.3 Vulnerabilidades a nivel de DNS

El Sistema de Nombres de Dominio (DNS) es una capa fundamental de internet, pero también está centralizado y puede verse comprometido. Muchos usuarios acceden a las aplicaciones a través de dominios web, que son susceptibles a:

• Secuestro de DNS, donde un atacante inserta un frontend falso y malicioso.
• Incautación de dominios, donde un gobierno o registrador puede incautar dominios.
• Phishing a través de dominios similares, donde los atacantes registran nombres casi idénticos para confundir a los usuarios.

3.4 Cadena de suministro de software y bibliotecas

Los desarrolladores de Ethereum dependen de bibliotecas de código abierto, a menudo extraídas directamente de servicios como npm, crates.io o GitHub. Si estas bibliotecas se ven comprometidas, pueden ser un vector de ataques como:

• Inyección de paquetes maliciosos, donde los atacantes comprometen un paquete ampliamente utilizado o publican uno con un nombre similar
• Dependencias secuestradas, donde los mantenedores pierden el control de un proyecto y un actor malicioso introduce código dañino
• Compromiso del desarrollador, donde los paquetes instalados contienen código que le da al atacante el control sobre la computadora del desarrollador.

3.5 Servicios de entrega de frontend y riesgos relacionados

Muchas aplicaciones de Ethereum sirven sus frontends a través de una Red de Entrega de Contenido (CDN) o una plataforma de alojamiento basada en la nube (por ejemplo, Vercel, Netlify, Cloudflare). Si estos servicios se ven comprometidos, pueden ser un vector de ataques como la inyección maliciosa de JavaScript, donde los atacantes sirven un frontend alterado a los usuarios.

3.6 Censura a nivel de Proveedor de Servicios de Internet

Los Proveedores de Servicios de Internet (ISP) o los estados nacionales pueden usar el control de la infraestructura de internet subyacente para censurar el acceso a Ethereum. Por ejemplo, estos ataques podrían incluir:

• Bloquear o limitar el tráfico a los puertos comunes de Ethereum
• Filtrar solicitudes de DNS que se resuelven en servicios relacionados con Ethereum
• Geocercas o prohibiciones de IP contra nodos conocidos de Ethereum
• Inspección profunda de paquetes para identificar y censurar el tráfico relacionado con el protocolo de Ethereum

Muchas de estas técnicas básicas ya son utilizadas por gobiernos autoritarios de todo el mundo para suprimir el acceso a la información, herramientas de protesta o criptomonedas en la actualidad.

El protocolo de consenso de Ethereum ha demostrado ser robusto en la práctica, con cero tiempo de inactividad desde su primer lanzamiento en 2015 y a través de varias actualizaciones. Sin embargo, siguen existiendo áreas de mejora a largo plazo para hacer que el sistema sea más resistente y seguro.

4.1 Fragilidad del consenso y riesgos de recuperación

Las reglas de elección de bifurcación y finalidad de Ethereum son resistentes, pero no son invulnerables. Durante ciertas condiciones de casos extremos (como un desacuerdo prolongado de los validadores, errores del cliente o particiones de la red), el consenso podría detenerse o divergir temporalmente. En condiciones extremas, esto podría conducir a penalizaciones en cascada para los validadores a través de fugas por inactividad o recortes, lo que podría provocar aún más la fuga de capitales de los validadores.

4.2 Diversidad de clientes

La diversidad de clientes líder en la industria de Ethereum protege la red de errores en cualquier cliente individual. Sin embargo, la diversidad de clientes aún podría mejorarse con una mayor adopción de clientes minoritarios para reducir estos riesgos aún más.

4.3 Centralización del staking y dominio de los pools

Una cantidad significativa del peso de los validadores se concentra en protocolos de staking líquido, servicios de custodia y grandes operadores de nodos. Esta concentración puede generar riesgos como:

• Captura o influencia de la gobernanza. Si las entidades que controlan grandes cantidades de participación (o entidades con poder legal para influir en esas entidades) se coordinaran juntas, podrían tener una influencia desmesurada sobre qué bloques se proponen y atestiguan, censurando potencialmente a los usuarios o influyendo en las actualizaciones del protocolo.
• Homogeneidad en la elección del cliente y la configuración de la infraestructura, lo que puede aumentar los riesgos de fallas correlacionadas.

4.4 Penalización social indefinida y brechas de coordinación

En algunos modos de falla extremos, Ethereum dependería de la "penalización social" para castigar a los validadores que actuaron maliciosamente para atacar la red (consulte la sección 6.1). Sin embargo, la infraestructura, las normas y los procesos esperados para este tipo de penalización están subdesarrollados. No existe un mecanismo establecido que la comunidad usaría para participar en este proceso.

4.5 Vectores de ataque económicos y de teoría de juegos

Muchos vectores de ataque económicos potenciales siguen estando poco estudiados, incluyendo:

• Ataques de molestia (griefing) o griefing de recorte. Los validadores pueden incurrir en costos o penalizaciones de recorte no por sus propias fallas, sino debido a un comportamiento adversario destinado únicamente a dañar a otros a un costo neto para el atacante.
• Salidas estratégicas o inactividad programada. Los validadores podrían desconectarse intencionalmente o salir en momentos críticos para maximizar las ganancias o interrumpir el consenso con penalizaciones mínimas.
• Colusión entre validadores o retransmisores (relays). El comportamiento coordinado entre validadores o entre retransmisores y validadores podría reducir la descentralización o extraer MEV.
• Explotación de incentivos de casos extremos en MEV, la separación proponente-constructor (PBS) o el diseño del staking líquido. Los actores pueden manipular condiciones raras del protocolo para obtener recompensas desmesuradas.

4.6 Riesgo cuántico

La criptografía central de Ethereum (por ejemplo, las firmas de curva elíptica como secp256k1) podría algún día ser descifrada por computadoras cuánticas. Si bien este no es un riesgo inminente, una amenaza creíble podría hacer que las billeteras, los contratos y las claves de staking existentes se vuelvan vulnerables al instante. Este desafío futuro debilita las garantías a largo plazo de Ethereum para los usuarios.

Las rutas de migración hacia una criptografía resistente a la computación cuántica (por ejemplo, a través de esquemas de firma poscuántica) deben diseñarse, probarse y posiblemente integrarse en el protocolo años antes de que sean necesarias. Las organizaciones de todo el ecosistema de Ethereum, incluida la Fundación Ethereum, están explorando activamente estas opciones y monitoreando los riesgos.

Incluso un ecosistema de cadena de bloques idealizado tendrá riesgos, ataques y vulnerabilidades. Cuando las cosas salen mal, debe haber sistemas efectivos para mitigar, detectar y responder. Los desafíos aquí incluyen:

• Contactar al equipo afectado. Puede ser difícil ponerse en contacto con el equipo cuya aplicación se ha visto comprometida. Esto puede provocar horas de retraso, lo que limita la capacidad de los equipos de respuesta para recuperar los fondos.
• Escalar problemas en organizaciones relacionadas. Cuando el problema involucra a una plataforma (como una red social o un intercambio centralizado), puede ser un desafío para los equipos de respuesta escalar el problema si no tienen un contacto preexistente.
• Coordinación de la respuesta. A menudo no está claro cuántos equipos de respuesta a incidentes están ayudando a la aplicación afectada, lo que lleva a una falta de comunicación o a un esfuerzo desperdiciado cuando un esfuerzo grupal podría haber sido más efectivo.
• Falta de capacidades de monitoreo. Puede ser difícil monitorear los problemas en cadena y fuera de la cadena, lo que proporcionaría una alerta temprana y garantizaría una respuesta rápida a las amenazas.
• Acceso a seguros. El seguro es una herramienta esencial para mitigar las pérdidas en la mayoría de los sistemas tradicionales que manejan dinero, sistemas financieros, identidad y otra información valiosa. Sin embargo, hoy en día hay pocas opciones de seguros disponibles de los servicios financieros tradicionales para el ecosistema cripto.

Estos riesgos tienden a estar más orientados a largo plazo y conciernen a Ethereum en su conjunto en lugar de a la seguridad de los usuarios o aplicaciones individuales.

6.1 Centralización de la participación

La centralización de grandes cantidades de participación puede plantear riesgos para Ethereum en su conjunto si las entidades que controlan esa participación deciden coludir.
Esta centralización económica crea el potencial para la captura de la gobernanza social. Si un pequeño grupo de validadores controla una supermayoría de la participación, podrían:

• Coordinar o resistir bifurcaciones.
• Censurar ciertas transacciones o contratos.
• Socavar el consenso de la comunidad amenazando con la salida o la oposición.

Si este escenario extremo ocurriera, la comunidad de Ethereum ha sugerido que la "penalización social" podría ser la respuesta. La penalización social es el uso del consenso social fuera de la cadena para decidir penalizar a los validadores que se comportan mal, como un control sobre su poder. Pero no existen normas, procedimientos o herramientas claras para promulgar tales medidas (consulte la sección 4.4).

6.2 Centralización de activos fuera de la cadena

Ethereum aloja cantidades significativas de activos del mundo real (RWA), donde los activos se mantienen fuera de la cadena en cuentas bancarias u otros depósitos, que luego se negocian en cadena a través de tokens que representan un reclamo sobre los activos fuera de la cadena. Por ejemplo, muchas monedas estables grandes funcionan de esta manera.

Las instituciones que mantienen los depósitos fuera de la cadena pueden tener influencia sobre el ecosistema de Ethereum. Por ejemplo, durante un escenario extremo en el que hay una bifurcación polémica o una actualización de la red, los grandes depositantes pueden influir en qué cadena se vuelve ampliamente aceptada al elegir reconocer tokens solo en una cadena u otra.

6.3 Ataque o presión regulatoria

Los gobiernos y los reguladores podrían presionar a varias entidades que controlan componentes importantes de la pila de Ethereum para censurar o interferir de otra manera con el protocolo de Ethereum. Los usuarios institucionales de Ethereum también podrían verse afectados por estas presiones, lo que tendría más consecuencias para sus usuarios (por ejemplo, un banco que ya no puede ofrecer ciertos productos cripto debido a prohibiciones regulatorias).

6.4 Captura organizacional de la gobernanza

Los procesos de gobernanza y desarrollo de código abierto de Ethereum están impulsados por un conjunto diverso y global de equipos y empresas que mantienen el software del cliente principal, la infraestructura y las herramientas.

Varias formas de influencia (adquisiciones corporativas, dependencias de financiamiento, empleo de contribuyentes clave, conflictos de intereses dentro de las organizaciones existentes) podrían cambiar gradualmente la cultura y las prioridades de la gobernanza de Ethereum. Esto puede conducir a una alineación con intereses comerciales o externos específicos que divergen del espíritu impulsado por la comunidad y la hoja de ruta establecida, lo que podría debilitar la neutralidad y la resiliencia de Ethereum con el tiempo.