Descripción general de los desafíos de seguridad

Una característica determinante 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 posibilidad de intervención ni reversión. Esto proporciona garantías sólidas 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 precipitada pueden provocar pérdidas irreversibles.

Como resultado, el usuario debe asumir una responsabilidad considerable en cuanto a la seguridad. Para utilizar Ethereum de forma segura, los particulares y las organizaciones deben conservar y gestionar las claves de forma segura, interactuar con aplicaciones en cadena y utilizar sus claves para firmar transacciones con el fin de transferir activos o actualizar el estado de Ethereum.

Cada uno de estos requisitos conlleva riesgos como el comprometimiento o la pérdida de claves, aprobaciones precipitadas o desinformadas, o el compromiso del software de la cartera en el que los usuarios se basan para informarse y guiarse en su interacción con Ethereum.

1.1. Gestión de claves

Muchos usarios no estan equipados para gestionar de manera segura las claves criptográficas.

Las carteras de software más utilizadas dependen de que los usuarios almacenen de forma segura las frases semilla (de recuperación) que constituyen su clave privada criptográfica subyacente; lo que a menudo les lleva a utilizar soluciones poco seguras, como almacenar las frases semilla en texto no cifrado, en servicios en la nube o anotarlas en papel.

Las carteras de hardware son una alternativa que permite a los usuarios gestionar una clave criptográfica almacenada en un dispositivo físico de uso específico. Sin embargo, las carteras de hardware tienen sus propios defectos y superficie de ataque. Las carteras de hardware pueden extraviarse, dañarse o robarse. Muchas carteras de hardware no son de código abierto ni pueden tener cadenas de suministro opacas, aumentando el riesgo de un ataque a la cadena de suministro en la que se comercializan dispositivos comprometidos en el mercado.

Ya se administren las claves en una cartera de software o de hardware, muchos usuarios están razonablemente nerviosos acerca de la autocustodia, cuando puede comprometerse a través del robo físico o el asalto.

Los usuarios empresariales e institucionales se enfrentan a desafíos adicionales en la gestión de claves. Si los colaboradores disponen de claves (por ejemplo, como parte de una cartera multisig), la organización debe ser capaz de reemplazarlas y crear nuevas claves, debido a los cambios de personal a lo largo del tiempo. Los requisitos de cumplimiento normativo en diferentes sectores y jurisdicciones pueden exigir flujos de trabajo personalizados o registros de auditoría que no son compatibles con el software de cartera existente. En algunos casos, los usuarios empresariales recurren a terceros para la custodia de activos digitales, lo que puede introducir otra capa de riesgos de seguridad a tener en cuenta.

1.2 Firma a ciegas e incertidunmbre en las transacciones

Los usuarios suelen aprobar transacciones «a ciegas», sin comprender lo que están haciendo. Las careteras a menudo muestran datos hexadecimales brutos, direcciones de contrato truncadas u otra información que no es suficiente para que el usuario comprenda las consecuencias de una transacción en particular. Esto expone a todo tipo de usuarios a contratos inteligentes maliciosos, phishing, estafas, interfaces falsas, vulnerabilidades en la interfaz de usuario y errores de usuario básicos.

1.3 Administración de aprobaciones y permisos

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

Estas aprobaciones pueden tener límites en cuanto a la cantidad, pero muchas carteras conceden por defecto aprobaciones ilimitadas sin fecha de caducidad. Los usuarios no tienen forma de gestionar o revisar sus aprobaciones pendientes en la mayoría de las carteras.

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 drenar sus fondos. Incluso si un usuario otorga una aprobación a un contrato inteligente legítimo, si ese contrato se comprometió más tarde mientras la aprobación permanece en su lugar, el contrato comprometido podría agotar los fondos del usuario.

Esto también supone un riesgo para los usuarios de la empresa. Por ejemplo, una empresa podría optar por otorgar una asignación de USDC ilimitada de router DEX para conveniencia operativa, 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 a través de su dispositivo móvil o navegador web.

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

1.5 Privacidad

La privicidad puede mitigar a magnificar los riesgos de seguridad para usarios de todo tipo.

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

Para las instituciones y empresas, la privacidad es a menudo 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 carteras 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 carteras de forma segura y aumenta los riesgos.

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

La seguridad del contrato inteligente ha mejorado radicalmente sobre la historia de Ethereum. Los primeros incidentes de seguridad como el DAO Hack motivaron el ecosistema para profesionalizar y mejorar las salvaguardas en todo el ciclo de vida del software que lleva al código que se implementa en la cadena. Los avances clave incluyen:

• La auditoría de seguridad se convirtió en una práctica estándar, con varias firmas de seguridad introducidas en el ecosistema y desarrollando experiencias.
• Las herramientas, pruebas y sistemas de análisis estáticos maduraron y se convirtieron en práctica estándar.
• Las bibliotecas de componentes comunes preauditados proporcionaron a los desarrolladores bloques de construcción predeterminados seguros.
• Se adoptaron técnicas de verificación formales, especialmente para puentes, sistemas de participación y contratos de alto valor.
• La cultura de seguridad y las prácticas aconsejadas del ecosistema mejoraron.
• La creación de programas de recompensas significativos que endurecieron la capa de la aplicación.

Sin embargo, sigue habiendo debilidades y áreas de mejora en este campo.

2.1 Vulnerabilidades de contratos

A pesar de los avances en la seguridad de los contratos inteligentes, todavía hay vulnerabilidades que pueden conducir a importantes problemas de seguridad, incluyendo:

• El riesgo de mejora del contrato. Algunos contratos están diseñados para poder modificarse después de la implementación y así permitir que un equipo de desarrollo continúe actualizando y mejorando la aplicación. Sin embargo, esto no está exento de riesgos: las actualizaciones podrían producir nuevas vulnerabilidades o la pérdida total de fondos del usuario en el caso de una actualización maliciosa.
• Reingreso, cuando el contrato A invoca a un contrato externo B antes de actualizar su propio estado interno, y el contrato B vuelve al contrato original A antes de que finalice la primera invocación.
• Uso inseguro de bibliotecas externas, donde un contrato invoca a una biblioteca externa que puede ser no auditada, maliciosa o actualizable.
• Componentes no auditados. Mientras que la auditoría y el uso de bibliotecas estándar han mejorado, los desarrolladores a veces dependen de componentes no auditados en sus aplicaciones.
• Fallos en el control de accesos, donde los permisos se configuran incorrectamente o se definen de manera demasiado amplia, lo que permite a los atacantes realizar acciones maliciosas.
• Acceso no autorizado, cuando un actor malicioso obtiene una clave privada que puede controlar el contrato.
• Puentes e interacciones entre cadenas. Los puentes y los protocolos de cadenas cruzadas introducen una complejidad adicional, y los atacantes pueden explotar las debilidades en la forma en que se pasan o validan los mensajes de cadena cruzada.
• Delegación de cuenta de propiedad externa (EOA) o uso indebido de la firma. Las aplicaciones maliciosas pueden engañar a los usuarios para que inicien sesión en la delegación completa de su cuenta a otra parte, lo que permite el robo. Las aplicaciones maliciosas también pueden usar mensajes firmados del usuario de maneras 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 automatizadas de refactorización.

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

Las vulnerabilidades terminan en el código implementado como resultado de un error del desarrollador. La mejora de las herramientas para desarrolladores ha facilitado significativamente la implementación de contratos inteligentes seguros. Sin embargo, los problemas persisten.

• Falta de valores predeterminados seguros en los marcos populares. Algunas herramientas priorizan la flexibilidad o la velocidad sobre la seguridad, estableciendo valores predeterminados inseguros como aprobaciones de tókenes ilimitadas en la función approve(), o el no incluir 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 características 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 inconsistentes a través de las pilas de herramientas, así como la falta de normas en torno al uso de técnicas probadas como la técnica del «fuzzing» o el control de invariante.
• Baja adopción de métodos de verificación formal. Las técnicas de verificación formal son potentes, a la par que complejas, costosas, requieren experiencia especializada en el dominio y no están bien integradas en los flujos de trabajo estándar del desarrollador, 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 del contrato. Los usuarios y desarrolladores no pueden evaluar fácilmente la fiabilidad de los contratos implementados, 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, quedan muchos problemas. Las herramientas que abordan estos problemas no se adoptan ampliamente, los estándares que unificarían los enfoques siguen siendo 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 defectos que introducen errores en los contratos inteligentes antes de que se implementen. El ecosistema Ethereum hoy en día depende principalmente del compilador solc, lo que significa que un error podría tener efectos generalizados.
• Diversidad y profundidad del lenguaje de programación. Si bien Solidity tiene un profundo ecosistema de herramientas construido sobre él, algunos desarrolladores quieren 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 asignan de forma limpia a los contratos inteligentes, generalmente asumiendo un código mutable, un control de cambio centralizado y líneas claras de asunción 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 cartera como para la capa de aplicación (por ejemplo, puntos finales RPC para carteras) como para el propio protocolo 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 cadena de bloques subyacente sigue siendo seguro.

3.1 Cadenas de capa 2

Las cadenas de capa 2 (L2) sirven como extensiones para Ethereum, lo que permite entornos de tarifas más rápidos y de menor frecuencia, al tiempo que 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, incluyendo:

• Complejidad de activos puenteados de múltiples saltos. Cuando los activos viajan entre L1 y múltiples L2, están expuestos a múltiples conjuntos de contratos, que deben ser seguros todos ellos. La contabilidad que no cuadra o las interrupciones en las cadenas L2 pueden introducir vulnerabilidades a merced de los atacantes.
• Los rollup L2 dependen de sistemas de prueba para asegurar la exactitud de las actualizaciones de estado. Los errores o configuraciones erróneas en estos sistemas pueden detener o impedir la finalización, o permitir la finalización de actualizaciones de estado falsas que conducen a la pérdida de fondos de usuario.
• Los consejos de seguridad son grupos de titulares de claves que sirven como un mecanismo de «respaldo» para actualizar el software 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ían poner en riesgo los fondos de los usuarios o congelar los activos.

Consulte L2Beatopens in a new tab para obtener un marco detallado y un panel de control que evalúa y compara el rendimiento y la seguridad de L2.

3.2 RPC e infraestructura de 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 criptomonedas, así como servicios en la nube tradicionales que se utilizan comúnmente para alojar nodos (por ejemplo, AWS, Cloudflare, Hetzner).

Si estos proveedores de infraestructura se desconectaran o intentaran censurar o acelerar el acceso, a muchos usuarios se les podría impedir acceder a Ethereum a través de su cartera 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 una cadena de bloques, lo que cuestiona su fiabilidad a largo plazo para aplicaciones descentralizadas.

3.3 Vulnerabilidades dentro de DNS

El Sistema de nombres de dominio (DNS, en inglés) 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 de:

• Secuestro de DNS donde un atacante inserta una interfaz falsa maliciosa.
• Apoderación de dominios, donde un gobierno o registrador puede incautar dominios.
• Phishing a través de dominios similares, donde los atacantes se registran cerca de nombres idénticos para confundir a los usuarios.

3.4 Cadena de suministro de software y bibliotecas

Los desarrolladores de Ethereum confían en 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 para ataques como:

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

3.5 Servicios de entrega de frontend y riesgos relacionados

Muchas aplicaciones 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 para ataques como la inyección de JavaScript maliciosa, donde los atacantes sirven una interfaz alterada a los usuarios.

3.6 Censura dentro de los proveedores de servicios de internet

Los proveedores de servicios de Nternet (ISP) o los Estados nacionales pueden controlar la infraestructura de internet subyacente para censurar el acceso a Ethereum. Por ejemplo, estos ataques podrían incluir:

• Bloqueo o tráfico de embotellamiento a los puertos de Ethereum comunes
• Filtrando las solicitudes de DNS que resuelven a los servicios relacionados con Ethereum
• Prohibiciones de geofencing (o acotamiento virtual) o IP contra nodos Ethereum conocidos
• 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 las están utilizando gobiernos autoritarios de todo el mundo para suprimir el acceso a la información, las herramientas de protesta o las criptomonedas hoy en día.

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

4.1 Consenso de fragilidad y riesgos de recuperación

La elección de bifurcación de Ethereum y las normas de finalidad son resilientes, pero no vulnerables. En determinados casos extremos (como un desacuerdo prolongado con el validador, errores del cliente o particiones de la red) el consenso podría estancarse y divergir. En condiciones extremas, esto podría conllevar la difusión de penalizaciones de validador a través de fugas de inactividad o recortes, que por su parte pueden mermar la huida del capital de los validadores.

4.2. Diversidad de clientes

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

4.3 Centralization de las participaciones y dominio de las reservas

Se concentra una cantidad significativa de peso de validador en protocolos de participaciones líquidas, servicios de custodia y grandes operadores de nodos. Esta concentración puede conducir a riesgos como:

• Captura o influencia de gobernanza. Si las entidades que controlan grandes cantidades de participación (o entidades con poder legal para influir en esas entidades) se coordinan juntas, podrían haber superado la influencia sobre la cual los bloques se proponen y atestiguan, censurando potencialmente a los usuarios o influyendo en las actualizaciones del protocolo.
• La homogeneidad en la elección del cliente y la configuración de la infraestructura, que puede aumentar los riesgos de fallo correlacionado.

4.4 Recortes sociales indefinidos y brechas de coordinación

En algunos casos de fallo extremo, Ethereum recurriría al «slashing» o recorte social para penalizar a los validadores que actuaran maliciosamente para atacar la red (véase la sección 6.1). Sin embargo, la infraestructura, las normas y los procesos previstos para este tipo de slashing están poco desarrollados. No existe un mecanismo establecido que la comunidad pueda utilizar para participar en este proceso.

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

Muchos vectores potenciales de ataque económico siguen siendo poco estudiados, incluyendo:

• Ataques de griefing (o sabotaje) o recorte por sabotaje. Los validadores pueden incurrir en costes o reducir las sanciones no debido a sus propios fallos, sino a un comportamiento no deseado, destinado únicamente a dañar a otros a un coste neto para el atacante.
• Salidas estratégicas o inactividad programada . Los validadores podrían desconectarse intencionadamente o salir en momentos críticos para maximizar las ganancias o interrumpir el consenso con sanciones mínimas.
• Confabulación entre validadores o relés. El comportamiento coordinado entre los validadores o entre relés y validadores podría reducir la descentralización o extraer MEV.
• Explotación de incentivos de casos de borde en MEV, separación proponedor-constructor o diseño de participación líquida. Los actores pueden manipular condiciones de protocolo raras para obtener recompensas desproporcionadas.

4.6 Riesgo cuántico

La criptografía principal de Ethereum (por ejemplo, firmas de curvas elípticas como secp256k1) podrían algún día romperla los ordenadores cuánticos. Si bien esto no es un riesgo inminente, una amenaza creíble podría hacer que las carteras, los contratos y las claves de participación existentes sean vulnerables al instante. Este desafío futuro debilita las garantías a largo plazo de Ethereum para los usuarios.

Las rutas de migración a la criptografía resistente a la 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 Ethereum, incluida Ethereum Foundation, están explorando activamente estas opciones y monitoreando los riesgos.

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

• Llegar al equipo afectado. Puede ser difícil ponerse en contacto con el equipo cuya aplicación se ha visto comprometida. Esto puede llevar a horas de retrasos, limitando la capacidad de los socorristas para recuperar fondos.
• Problemas de escalada en organizaciones relacionadas. Cuando el problema involucra una plataforma (como una red social o un intercambio centralizado), puede ser difícil que los participantes escalen el problema si no tienen un contacto preexistente.
• Coordinación de 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 puede haber sido más efectivo.
• Falta de capacidades de control. Puede ser difícil monitorear los problemas en la cadena y fuera de la cadena, lo que proporcionaría una alerta temprana y garantizaría una respuesta rápida a las amenazas.
• Acceso al seguro. El seguro es una herramienta esencial para mitigar las pérdidas en la mayoría de los sistemas tradicionales que se ocupan del dinero, los sistemas financieros, la identidad y otra información valiosa. Sin embargo, hoy en día hay pocas opciones de seguro disponibles de los servicios financieros tradicionales para el ecosistema criptográfico.

Estos riesgos tienden a estar más orientados a largo plazo y conciernen a Ethereum en su conjunto más que a la seguridad de 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 conspirar.
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 participación, podrían:

• Coordinar o resistir las bifuraciones.
• Censurar ciertas transacciones o contratos.
• Socorrar el consenso de la comunidad amenazando con la salida u oposición.

Si se diera este caso extremo, la comunidad de Ethereum ha sugerido que el recorte social podría ser la respuesta. Recorte social es el uso del consenso social fuera de la cadena para decidir recortar a los validadores que se comportan mal, como una comprobación de su poder. Pero no existen normas, procedimientos o herramientas claras para promulgar tales medidas (véase la sección 4.4).

6.2 Centralización de activos fuera de la cadena

Ethereum alberga cantidades significativas de activos del mundo real, 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 tókenes que representan una reclamación sobre los activos fuera de la cadena. Por ejemplo, muchas monedas estables grandes funcionan de esta manera.

Las instituciones que tienen los depósitos fuera de la cadena pueden tener influencia sobre el ecosistema 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 acepta ampliamente al elegir solo reconocer los tokens 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 que censuren o interfieran de otra manera con el protocolo Ethereum. Los usuarios institucionales de Ethereum también podrían verse afectados por estas presiones, lo que tendría consecuencias adicionales para sus usuarios (por ejemplo, un banco que ya no puede ofrecer ciertos productos criptográficos debido a las prohibiciones reglamentarias).

6.4 Captura organizativa 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, la infraestructura y las herramientas principales del cliente.

Varias formas de influencia (adquisiciones corporativas, dependencias de financiación, empleo de contribuyentes clave, conflictos de intereses dentro de las empresas 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, debilitando potencialmente la neutralidad y la resistencia de Ethereum con el tiempo.