Crypto no puede seguir así: una carta de autoconservación de un profesional de blockchain

Autor: Robert Mao, fundador y CEO de ArcBlock

Este artículo está autorizado para ser reproducido y redistribuido libremente por cualquier persona, con la esperanza de que más personas vean este llamado a la autoconservación de la industria.

Crypto no puede seguir así. Los robos masivos han llevado no solo a la pérdida de activos, sino también a la desconfianza de los participantes en toda la industria. Debemos autoconservarnos.

El 29 de octubre de 2026, Binance sufrió un grave incidente de seguridad. Su anuncio preliminar estima que aproximadamente 6.3 mil millones de dólares en activos se vieron afectados, y alrededor de 3 mil millones de dólares en activos han sido congelados; la investigación inicialmente apuntó a la computadora portátil de un ingeniero de DevOps, y luego se descubrieron otros posibles puntos de entrada. Binance también declaró que no se han encontrado pruebas de filtración de claves privadas de billetera. La cantidad afectada no es la pérdida neta final, ya que la cadena completa de ataques aún está bajo investigación.[[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/ " \l "fn-binance)

Esta carta está dirigida a los constructores de proyectos de blockchain como Ethereum y Solana, así como a Binance, Coinbase, Kraken y todos los intercambios, billeteras, protocolos y constructores de seguridad que deseen participar: reconstruyamos juntos la base para proteger los activos. Estoy dispuesto a participar y espero que más personas actúen.

Esto ya es lo suficientemente pesado. Pero me preocupa aún más cuánta confianza en Crypto se verá afectada por este incidente y cuántos atacantes verán a esta industria como un objetivo digno de continuar atacando. Incluso si al final alguien asume las pérdidas, las compensaciones no pueden restaurar automáticamente la confianza de los usuarios, ni pueden detener la misma destrucción de volver a ocurrir.

Binance es solo la entrada que hoy nos obliga a enfrentar el problema. Al desviar la mirada, los intercambios, puentes, protocolos en cadena y billeteras ya han dejado una larga lista de heridas. Nuevas redes y productos siguen apareciendo, pero los viejos patrones de fallos se repiten una y otra vez. No podemos emitir un anuncio, esperar un tiempo y luego tratar el próximo incidente como algo cotidiano.

También debemos reconocer que las estafas y las prácticas que solo crean conceptos sin asumir responsabilidades de construcción han dañado esta industria durante demasiado tiempo. Los equipos que se dedican seriamente a la tecnología y la infraestructura también deben soportar las consecuencias de la pérdida de confianza. Cuando la gente vea todo Crypto como una estafa, la tecnología y la exploración realmente valiosas también podrían ser abandonadas.

Como fundador de ArcBlock y profesional de Crypto y Blockchain, no estoy dispuesto a aceptar tal desenlace. Creo que esta industria tiene un valor que vale la pena proteger y también creo que debemos asumir la responsabilidad de nuestra base de seguridad. Si seguimos esperando pasivamente el próximo incidente, la pérdida continua podría destruir todo lo que hemos construido juntos.

Por lo tanto, quiero emitir esta carta: los constructores de intercambios, billeteras y blockchain deben reconstruir juntos la base del control de activos y la verificación de seguridad, para que el alcance de la destrucción de una intrusión esté limitado. La siguiente línea de tiempo explica por qué es necesario cambiar; las soluciones técnicas posteriores son lo que creo que se puede comenzar a hacer.

Esta línea de tiempo de incidentes ya es demasiado larga

En 2008, Satoshi Nakamoto propuso un sistema de efectivo electrónico peer-to-peer, intentando reducir la dependencia de intermediarios de confianza.[[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/ " \l "fn-bitcoin) Sin embargo, los incidentes importantes posteriores han expuesto continuamente el problema de la re-centralización de fondos, autorizaciones y dependencias de software.

A continuación, se enumeran cronológicamente eventos representativos en el ámbito de intercambios centralizados (CEX), intercambios descentralizados (DEX), puentes y billeteras. No es un repositorio completo de incidentes ni una estadística de pérdidas por año. Las cantidades, si se mencionan, indican el impacto bruto aproximado en el momento del incidente; los robos, congelaciones y recuperaciones posteriores se explican por separado y no pueden sumarse como pérdidas permanentes.

2008 · Libro Blanco de Bitcoin

• Punto de partida
• El libro blanco de Bitcoin propone pagos peer-to-peer sin la necesidad de intermediarios financieros.
• Fuente

2011--2014 · Robo prolongado de Mt. Gox

• CEX
• Mt. Gox sufrió un robo prolongado y finalmente dejó de operar. La posterior acusación del Departamento de Justicia de EE. UU. alegó que aproximadamente 647,000 BTC fueron robados entre 2011 y 2014. Este no fue un ataque que ocurrió en un solo día en 2014.
• Fuente

2012 · Bitcoinica y Bitfloor

• CEX / Infraestructura de custodia
• El entorno de alojamiento de Linode de Bitcoinica fue comprometido; ese mismo año, la copia de seguridad de la billetera no cifrada de Bitfloor se convirtió en un punto de entrada para el ataque. Los servidores y copias de seguridad detrás de la plataforma también son límites de seguridad de activos.
• Fuente

2015 · Billetera caliente de Bitstamp

• CEX
• La billetera caliente de Bitstamp fue infiltrada, y luego se reconstruyó el entorno de operación. La oficial separó el alcance del incidente de las reservas fuera de línea, indicando que el aislamiento puede limitar el alcance de la exposición.
• Fuente

2016 · Bitfinex

• CEX
• Aproximadamente 120,000 BTC fueron robados de Bitfinex. Los arreglos de múltiples firmas aún requieren autorización y verificación independientes de extremo a extremo.
• Fuente 1 · Fuente 2

2016 · The DAO

• Protocolo en cadena
• El contrato de The DAO fue objeto de un ataque de reentrada, y aproximadamente 3.6 millones de ETH fueron transferidos a un sub DAO, lo que posteriormente provocó un fork de Ethereum. Las rutas de ejecución legal pueden tener resultados comerciales catastróficos.
• Fuente 1 · Fuente 2

2017 · Biblioteca de billeteras compartidas de Parity

• Billetera de contrato
• La biblioteca de billeteras compartidas de Parity fue destruida, congelando aproximadamente 513,000 ETH. No se transfirieron, pero podrían haber perdido la capacidad de uso debido a la dependencia de código compartido.
• Fuente

2018 · Coincheck

• CEX
• La billetera caliente de NEM de Coincheck fue robada. La frontera entre las reservas fuera de línea, los permisos de billetera caliente y las necesidades comerciales se convirtió nuevamente en un problema.
• Fuente

2019 · Binance

• CEX
• Binance anunció que 7,000 BTC fueron retirados en una sola transacción. La salida masiva de activos necesita estar restringida antes de la firma.
• Fuente

2020 · KuCoin

• CEX
• Incidente de billetera caliente de KuCoin, que posteriormente recuperó una gran cantidad de activos a través de la colaboración de múltiples partes. La cantidad robada bruta y la pérdida final no son la misma cifra.
• Fuente

2021 · Poly Network

• Protocolo cross-chain
• Aproximadamente 612 millones de dólares en activos fueron transferidos de Poly Network, que luego fueron devueltos gradualmente. La autorización cross-chain y el control de activos no pueden depender únicamente de las rutas comerciales normales.
• Fuente

2022 · Puente Ronin

• Puente
• Los permisos de los validadores de Ronin fueron comprometidos, y 173,600 ETH y 25.5 millones de USDC fueron transferidos. Las claves de múltiples validadores también podrían haber caído en la misma cadena de ataque.
• Fuente

2022 · Billetera Slope

• Billetera
• Evento de la billetera Slope en el ecosistema de Solana. Solana señaló que la información de la clave privada fue accidentalmente enviada a un servicio de monitoreo de aplicaciones; no fue un hackeo del consenso de Solana.
• Fuente

2023 · Euler

• Protocolo de préstamos
• Aproximadamente 197 millones de dólares en activos de Euler fueron transferidos debido a una vulnerabilidad del protocolo, que luego fueron recuperados. La combinación compleja de una sola transacción puede amplificar los defectos de la lógica comercial.
• Fuente

2023 · Kit de Conexión Ledger

• Herramienta de conexión de billetera
• El Kit de Conexión Ledger fue atacado en la cadena de suministro, con código malicioso ingresando a la interfaz de la aplicación. La seguridad del dispositivo de hardware no puede reemplazar la verificación del contenido de la transacción.
• Fuente

2024 · DMM Bitcoin

• CEX
• Aproximadamente 308 millones de dólares fueron robados de DMM Bitcoin. El FBI y otras agencias revelaron posteriormente ataques de ingeniería social dirigidos a personas relacionadas y enlaces de firma.
• Fuente

2024 · Radiant Capital

• Protocolo de préstamos / firma
• Aproximadamente 50 millones de dólares fueron robados de Radiant Capital, con múltiples dispositivos de desarrolladores comprometidos. Las firmas múltiples aún pueden depender conjuntamente de información de transacción contaminada.
• Fuente

2025 · Bybit / Safe

• CEX / interfaz de billetera
• Aproximadamente 1.5 mil millones de dólares en incidentes de Bybit, el ataque involucró el entorno de desarrollo de Safe y la interfaz frontal, donde los firmantes aprobaron transacciones que cambiaron la lógica de control de la billetera.
• Fuente 1 · Fuente 2

2025 · Cetus DEX

• DEX
• Aproximadamente 223 millones de dólares en incidentes de Cetus en Sui, donde los investigadores señalaron defectos en la biblioteca matemática. El entorno no EVM también debe verificar el código y el rango de exposición de los activos.
• Fuente

2026-07 · Defecto de número aleatorio de COLDCARD

• Billetera de hardware / generación de semillas
• Un defecto en el firmware debilitó la generación de semillas, permitiendo a los atacantes reconstruir las claves privadas relacionadas mientras el dispositivo estaba fuera de línea. Las actualizaciones no pueden reparar semillas débiles ya generadas, y aún deben migrarse según el anuncio.
• Fuente

2026-10 · Infiltración de hardware de Ledger

• Billetera de hardware / ataque de distribución
• Ledger confirmó que los dispositivos reales fueron modificados y circulados a través de canales de distribución en el sudeste asiático, con componentes implantados que roban frases de recuperación durante la inicialización. El fabricante afirmó que su chip, sistema operativo y servidores no fueron comprometidos.
• Fuente

2026 · Incidente multichain de Binance

• CEX / multichain
• Binance estimó inicialmente que aproximadamente 6.3 mil millones de dólares en activos se vieron afectados, y la investigación sobre otros posibles puntos de entrada aún está en curso. Un único sistema operativo puede exponer simultáneamente activos en múltiples redes.
• Fuente 1 · Fuente 2 · Fuente 3

Aquí hay CEX, así como intercambios descentralizados, protocolos de préstamos y puentes; hay activos robados y activos congelados. Los ataques ocurren en diferentes capas, y los métodos de reparación también son diferentes. Me opongo a resumir todo esto en la frase "los usuarios no cuidaron bien sus claves privadas". ¿Cómo pueden los usuarios saber que el entorno de desarrollo de una herramienta, una biblioteca compartida o una autorización que no entienden se convertirán en la entrada a todos sus activos?

Las redes distribuidas han hecho mucho, pero el aislamiento de fallos en el control de activos es aún muy insuficiente. La ejecución en cadena completó fielmente una transacción, pero no puede responder por qué esa transacción tiene el derecho de mover tantos activos.

Construyendo una base de seguridad conjunta con diferentes rutas tecnológicas

La contribución de Ethereum ha sido significativa. Ha permitido que más personas puedan desarrollar aplicaciones en la cadena, creando una rica variedad de herramientas y experiencias de desarrollo. Sin embargo, hoy en día, muchas nuevas cadenas y L2 (redes de escalado de segunda capa) han adoptado la compatibilidad con EVM como su principal objetivo. EVM, que es la máquina virtual que ejecuta contratos inteligentes de Ethereum, se está convirtiendo en un requisito técnico ampliamente replicado. La compatibilidad facilita la migración de aplicaciones; la documentación de proyectos como Unichain deja claro que reutilizar herramientas de Ethereum es un valor equivalente a un entorno de ejecución.

Creo que adoptar la compatibilidad con EVM como la respuesta predeterminada de la industria está creando una concentración de riesgos estructurales. Puede haber muchos nombres de red y diferentes validadores, pero los desarrolladores pueden desplegar repetidamente los mismos contratos, usar los mismos hábitos de autorización y depender de las mismas bibliotecas de software. Los errores en esta dependencia común no desaparecerán simplemente porque se desplieguen en otra cadena. Esto es un juicio sobre la ruta técnica, no significa que cada implementación de EVM tenga necesariamente la misma vulnerabilidad.

Mis críticas a Ethereum también surgen aquí. La capacidad de ejecución de contratos genéricos se conecta directamente a activos transferibles, delegando una gran responsabilidad al código de la aplicación y a la interacción con las billeteras. Los contratos pueden invocar otros contratos, las autorizaciones pueden existir a largo plazo, y una confirmación que parece ordinaria puede cambiar la forma en que se controla la cuenta en el futuro. La seguridad depende cada vez más de que cada equipo de desarrollo comprenda correctamente estas combinaciones, así como de que cada usuario entienda correctamente lo que ha firmado.

El EIP-7702 ilustra este problema de manera clara. Una transferencia normal es "cuánto se transfiere a quién"; la autorización delegada puede ser "de ahora en adelante, permite que este código ejecute operaciones en mi cuenta". Tiene como objetivo mejorar la experiencia del usuario y segmentar permisos, pero establecer una delegación otorga en sí misma una amplia capacidad de ejecución, y los permisos finos deben ser implementados correctamente por el código delegado. El preprint de Minfeng Qi y otros, titulado "EIP-7702 Phishing Attack", estudia las vías para mantener el control de la cuenta después de inducir la firma de tales autorizaciones. A medida que la conveniencia aumenta, también lo hace la responsabilidad de seguridad, y no se puede dejar todo esto a los usuarios.

El reciente incidente de Binance abarca múltiples cadenas, y la investigación aún no ha concluido, por lo que no se puede atribuir todo el impacto directamente al EIP-7702 o al EVM. La reentrada, la caída de servicios de firma y la manipulación del frontend no son la misma vulnerabilidad. Pero esta distinción no debería ser una excusa para dejar de cuestionar la arquitectura: ¿por qué la capa inferior no retiene más restricciones que no se pueden eludir fácilmente para proteger los errores de la capa superior?

MEV también me desagrada. Se refiere al espacio que los participantes utilizan para obtener valor adicional mediante la inclusión, exclusión y ordenación de transacciones. Para mí, utilizar el poder de ordenación para atacar las transacciones de los usuarios y empeorar sus resultados de ejecución debería considerarse un bug que necesita ser corregido; no se puede empaquetar como una característica valiosa solo porque alguien pueda ganar dinero con ello. La propia documentación de Ethereum también reconoce claramente el daño que causan las transacciones de ataque a los usuarios, así como el riesgo que MEV representa para la estabilidad de la red. MEV no es exclusivo de Ethereum, también incluye actividades como arbitraje y liquidación; ya hay investigaciones en la industria para mitigar esto. Mi crítica es que los incentivos para mantener la red no pueden ser una razón para sacrificar las condiciones de transacción de los usuarios. Un mejor sistema de transacciones debería incluir los resultados mínimos de entrega y las tarifas permitidas en las autorizaciones, y limitar el espacio para que los ordenadores utilicen información no ejecutada para perjudicar a los usuarios.

Siempre he sentido que la influencia de Ethereum en Crypto es algo parecido a la de PHP en Internet: ha permitido que muchas personas creen cosas, pero también ha dejado una deuda técnica que debe ser saldada a largo plazo. PHP aún necesita reparar graves vulnerabilidades de ejecución remota de código en octubre de 2026. La madurez y la popularidad no pueden reemplazar el fortalecimiento continuo. Lo valioso de Internet es que los lenguajes, marcos y servicios en la nube pueden evolucionar por separado. También debemos permitir que diferentes modelos de activos y métodos de ejecución continúen desarrollándose, en lugar de considerar "la compatibilidad con una única máquina virtual" como un boleto de entrada al ecosistema.

Por lo tanto, hago un llamado a los ecosistemas de Bitcoin, Solana, Ripple/XRP Ledger, y a los constructores como ArcBlock, para que participen seriamente en la construcción de una base de seguridad común. Participar en estándares e interoperabilidad no requiere que primero se conviertan en Ethereum. La diversidad debe implementarse en el control de activos y en los métodos de verificación, aceptando la revisión pública. Los incidentes de Slope y Cetus ya nos han recordado que el no EVM tampoco tiene exenciones de seguridad.

Lo que espero formar es un estándar de seguridad que pueda ser adoptado por diferentes entornos de ejecución: las mismas restricciones de activos y requisitos de verificación pueden ser implementados por EVM y otras rutas, y luego se pueden verificar públicamente sus garantías y costos.

Siete medidas de fortalecimiento que se pueden comenzar a implementar

1. Permitir que las restricciones de control de riesgos en la capa inferior regulen el derecho a disponer de activos

Las billeteras de gran tamaño deberían poder establecer listas blancas de destinatarios, límites de gasto acumulativo y períodos de espera para nuevos destinatarios. Lo clave es que estas reglas no pueden ser canceladas de inmediato por la misma clave de transacción diaria. Cambiar las reglas requiere una autorización independiente, y también debe dejar tiempo para la supervisión y la revocación.

Las cuentas inteligentes existentes ya tienen una base de implementación, por ejemplo, Safe Guards puede agregar restricciones de transacción además de la firma múltiple. Necesitamos hacerlo más fácil de adoptar y capaz de cubrir todos los caminos de control de activos. Solo limitar las transferencias directas, pero permitir eludir a través de autorizaciones ilimitadas, módulos o actualizaciones, hará que la protección sea ineficaz. También debe entrar en el ámbito de verificación si el contrato de lista blanca puede ser actualizado y si ha habido cambios en los permisos del destinatario.

El Activation Lock de Apple proporciona una inspiración en la vida cotidiana: limita la reactivación de dispositivos robados y restringe la calibración de ciertas piezas robadas, con el objetivo de reducir el valor que se puede aprovechar después de ser robado. Las billeteras también deberían ser diseñadas en esta dirección. Si un atacante obtiene una clave, el rango de activos que puede monetizar sigue siendo limitado, lo que podría reducir la expectativa de ganancias del ataque; los riesgos de interrupción del servicio aún deben ser tratados por separado.

Esto es lo que llamo la "constitución" de la seguridad de los activos: los permisos de operación pueden ser comprometidos, pero los permisos para modificar los límites deben permanecer independientes. El proceso de recuperación también debe estar sujeto a restricciones, para evitar que una configuración errónea bloquee permanentemente los activos.

2. Hacer que las billeteras asuman la responsabilidad de seguridad, y no solo entregar las frases de recuperación

Tengo una gran insatisfacción con el sistema de billeteras actual: si un producto hace que una persona común copie un conjunto de palabras, exigiendo que nunca las revele, no las pierda y no sea engañada, y luego atribuye todos los fracasos posteriores a la responsabilidad del usuario, creo que es un diseño irresponsable. La autogestión debería otorgar control, pero también debería proporcionar protección y capacidad de recuperación utilizables. No debería exigir que cada usuario se convierta primero en un experto en seguridad. Este es también un umbral que Crypto debe cruzar para atraer a más usuarios comunes.

Los recientes incidentes han planteado este problema de manera directa. Ledger confirmó en octubre de 2026 que los atacantes modificaron dispositivos reales y los enviaron de vuelta al mercado a través de canales de distribución en el sudeste asiático, implantando componentes que robaban las frases de recuperación durante la inicialización. Ledger lo definió como un ataque de distribución local posterior a la fabricación del dispositivo, y no como un ataque a su chip, sistema operativo o servidores. El incidente de COLDCARD en julio involucró la debilitación del firmware en la generación de semillas: el dispositivo no necesita ser controlado de forma remota, el atacante también puede reconstruir las claves privadas relacionadas. Actualizar el firmware repara el proceso de generación futuro, pero las semillas débiles ya generadas aún necesitan ser migradas.

Estos dos incidentes no son la misma vulnerabilidad, pero ambos indican que incluso si los usuarios copian cuidadosamente las palabras y mantienen el dispositivo en modo offline, no pueden validar la aleatoriedad y la cadena de suministro completa del fabricante. Hacer que el dispositivo muestre las palabras de respaldo tiene un propósito de recuperación offline, pero también puede permitir que el secreto de recuperación completo pase por un camino que necesita ser protegido para su visualización y respaldo. La seguridad del chip no puede reemplazar la validación de todo el dispositivo y el proceso de entrega.

El objetivo de la mejora debe ser el ciclo de vida completo de la billetera: cómo se generan las claves, cómo se interpretan las transacciones, cómo se separan los permisos y cómo se recupera después de la pérdida del dispositivo. La abstracción de cuentas, que permite que las cuentas verifiquen autorizaciones a través de reglas programables, así como el SLIP-39 y otros métodos de respaldo umbral, ya tienen estándares y bases de implementación; no se puede decir que la industria no está haciendo nada. Pero necesitamos que estas capacidades se conviertan en protecciones verificadas y fáciles de usar, en lugar de dejar que los usuarios ensamblen soluciones complejas por sí mismos.

La simple confusión de las frases de recuperación no es suficiente. Direcciones más confiables incluyen respaldos encriptados revisados, recuperación umbral y autorizaciones de dispositivos independientes, y permitir que los usuarios completen ensayos de recuperación antes de depositar activos de gran valor. La fragmentación de respaldos y la firma múltiple son diferentes capas: la primera puede recombinar el mismo secreto durante la recuperación, mientras que la segunda requiere que varios firmantes independientes aprueben la transacción. Los servicios de recuperación no pueden convertirse silenciosamente en una nueva clave maestra, ni permitir que contraseñas adicionales se conviertan en otra trampa de la que no se puede recuperar si se pierde.

Los sistemas de billeteras personales y de intercambio pueden compartir descripciones de transacciones, solicitudes de firma, restricciones de activos y normas de seguridad para procesos de recuperación, adoptando diferentes límites y estrategias de aprobación. El PSBT de Bitcoin ya ha proporcionado un formato para la transmisión de transacciones pendientes de firma entre herramientas, y esta interfaz común merece seguir construyéndose. Lo común son los requisitos de seguridad verificables, y cada cadena aún necesita aclarar sus propias reglas de adaptación. Las billeteras deben presentar claramente qué se transferirá en esta firma, cuántos permisos posteriores se otorgarán a quién, y ser rechazadas por estrategias independientes en caso de operaciones fuera de los límites; una página de confirmación más atractiva no es suficiente.

3. Implementar divulgaciones mínimas necesarias para lograr verificabilidad

Probar que una condición se cumple no debería requerir siempre que los usuarios revelen todos los datos subyacentes. La divulgación selectiva, las pruebas de conocimiento cero y el acceso a auditorías otorgadas según sea necesario deberían ser opciones normales en la infraestructura. Esto también está relacionado con la seguridad de los activos: la relación pública entre identidad y activos puede proporcionar pistas para engaños dirigidos; los datos que no son necesarios para el negocio deberían ser expuestos lo menos posible.

El sistema de credenciales verificables del W3C ya tiene un camino técnico para la divulgación selectiva; sin embargo, aún se necesita claridad sobre cómo probar la veracidad de la entrada, la validez de la credencial y cómo revocar el estado. La adopción de pruebas de conocimiento cero (ZK) no oculta automáticamente los montos y relaciones de las transacciones; la escalabilidad de las pruebas y la protección de la privacidad son objetivos diferentes.

Por ejemplo, cuando un negocio solo necesita verificar la elegibilidad de participación, el usuario puede presentar una conclusión de elegibilidad válida emitida por una entidad de confianza, sin revelar materiales financieros completos. Cuando se necesita probar que un valor oculto cumple con ciertas condiciones, se debe utilizar un mecanismo de prueba adecuado. La fuente confiable de la credencial y el estado de revocación aún deben ser verificados.

Mi propuesta es aclarar "quién necesita verificar qué" antes de diseñar los datos que deben ser públicos. Quien verifica la elegibilidad puede necesitar solo la conclusión de elegibilidad; quienes asumen responsabilidades de auditoría específicas pueden obtener evidencia restringida. Las restricciones verificables públicas deben minimizar la exposición permanente de información personal a todos.

IV. Descentralizar los servicios de transacción tanto como sea posible

La coincidencia de transacciones, la búsqueda de rutas y la finalización de la entrega de activos deben ser diseñadas por separado. Un servicio que proporciona un punto de entrada para transacciones debería obtener solo los permisos necesarios para completar la entrega actual, permitiendo que los activos de los usuarios permanezcan bajo su control el resto del tiempo. Los protocolos existentes basados en la intención de transacción ya han explorado parte de este camino, y la industria puede continuar completándolo.

Los términos de entrega a los que el usuario consiente deben ser claros, incluyendo qué se entrega, qué se recibe al menos, cuándo caduca y qué costos son permitidos. Si el servicio de transacción es comprometido, el atacante puede rechazar el servicio, pero no puede cambiar arbitrariamente estos términos. Los negocios que aún requieren custodia centralizada también deben separar las reservas de los permisos operativos, limitando la exposición de las billeteras calientes y la recarga automática de límites.

IBIT es un producto cotizado en bolsa de Bitcoin de iShares, y lo que se negocia en el mercado son sus acciones. Su disposición proporciona un ejemplo de aislamiento parcial: las acciones y el Bitcoin subyacente se registran por separado, y las claves privadas relacionadas con el Vault Balance (saldo de custodia) se mantienen en almacenamiento en frío. Los registros de transacciones de acciones cambian sin requerir que el Bitcoin subyacente se mueva con cada transacción. Lo que se puede aprender es la separación de los derechos de transacción y los derechos de disposición de reservas. Su Trading Balance (saldo del servicio de transacción) tiene disposiciones diferentes, y la custodia en sí misma conlleva riesgos; el almacenamiento en frío debe ir acompañado de instrucciones y verificaciones de firma independientes.

Comparo el punto de entrada de transacciones con un enrutador, esperando que pueda ser reemplazado sin ser un interruptor total que contenga todos los activos de los usuarios. La liquidación es más compleja que el reenvío de paquetes de datos; la entrega de activos y la autorización aún deben ser verificadas de forma independiente. Una vez que el servicio se convierte en no custodial, otorgarle derechos de retiro ilimitados solo volverá a introducir riesgos centralizados.

V. Aislar fallos mediante una arquitectura en capas y mantener la capacidad de reemplazo

Necesitamos interfaces de identidad y autorización, políticas de activos y métodos de verificación de liquidación que puedan evolucionar de manera independiente. Diferentes cadenas pueden mantener sus propios modelos de ejecución, conectándose a través de interfaces claras. Las interfaces deben especificar las garantías de seguridad y sus condiciones, no solo decir "llamada exitosa".

La experiencia de Internet respalda este enfoque. Mark Nottingham discute en el RFC 9518 "Centralización, Descentralización y Estándares de Internet" las situaciones en las que la centralización puede ser útil, y también analiza el poder y los riesgos que conlleva. Esta es una actitud que vale la pena emular: permitir que la arquitectura responda qué responsabilidades pueden ser centralizadas, hasta qué punto y cómo prevenir la expansión de ese poder. Se puede permitir que un servicio identifique anomalías de manera centralizada, mientras se limita su acceso a los activos; los usuarios deberían poder cambiar de servicio sin perder sus políticas de activos y registros de verificación.

La pregunta más importante de aceptación es: después de que un servicio de negocio sea comprometido, ¿qué capa independiente aún puede rechazarlo? Si todas las capas comparten una sola llave de gestión, la llamada separación en capas es solo una separación en el diagrama de implementación.

Se puede ver este objetivo como cinco responsabilidades: el servicio de transacción envía la solicitud, la billetera expresa la intención del usuario, la política independiente limita los derechos de disposición de activos, el componente de verificación revisa las operaciones y la evidencia, y la capa de liquidación ejecuta las restricciones y proporciona registros verificables. Pueden ser implementados por diferentes equipos, y también deben especificar las dependencias y las condiciones de fallo.

La arquitectura objetivo propuesta en este artículo. La capa de liquidación debe hacer cumplir las políticas de activos; las indicaciones en la billetera no pueden reemplazar esta restricción. Las firmas diarias, los cambios de reglas y la recuperación de permisos necesitan ser aislados y aceptar pruebas de elusión.

VI. Permitir que los usuarios verifiquen sus activos de manera ligera

Las personas comunes no deberían tener que guardar y ejecutar toda la historia de la cadena para verificar su saldo y recibir pagos; tampoco deberían tener que confiar únicamente en un servidor detrás de la billetera. Satoshi ya propuso en la sección ocho del libro blanco el SPV, o verificación de pagos simplificada. El BIP-157 de Bitcoin continúa explorando cómo permitir que los clientes descarguen filtros y busquen bloques relacionados con ellos; Ethereum también tiene diseños de clientes ligeros. Por lo tanto, el problema no es que nunca se haya pensado en ello, sino que aún necesitamos incorporar la capacidad de verificación con condiciones de seguridad claras en las billeteras que los usuarios utilizan diariamente.

Tomando como ejemplo una cadena que soporta la prueba del estado de la cuenta, al consultar el saldo, el servidor debería devolver simultáneamente el saldo y la prueba. La billetera primero verifica un resumen breve del bloque según las reglas de esta cadena, es decir, el encabezado del bloque, y luego verifica si este saldo coincide con los datos prometidos por el resumen. El servidor proporciona la respuesta, y la billetera puede verificar la respuesta. La verificación SPV de Bitcoin es evidencia de que las transacciones relacionadas han sido incluidas, y no se puede copiar directamente este tipo de prueba de saldo. La billetera también debe mostrar claramente hasta dónde se ha sincronizado y qué información ha sido verificada; en caso de falta de prueba, datos caducados o fuentes contradictorias, debe advertir o detener operaciones de alto riesgo que dependan de esta información, y no volver a una confianza ciega sin previo aviso.

La verificación ligera aún tiene condiciones. Probar que una transacción ha sido incluida en un bloque no significa que se haya verificado que todas las transacciones dentro del bloque sean legales. Diferentes soluciones pueden depender de la honestidad de la mayoría del poder de cómputo, o de un registro inicial confiable, es decir, un punto de control; también se debe prevenir que el servidor oculte datos o aísle al usuario en un registro de cadena obsoleto. La consulta en sí misma no debería exponer la dirección de interés del usuario. Los nodos completos y los creadores de bloques no son el mismo rol; hoy en día, los creadores de bloques de Ethereum utilizan validadores, no mineros.

Más importante aún, probar que "realmente ocurrió esta transferencia en la cadena" no prueba que "esta es exactamente la transferencia que el usuario quería". Los clientes ligeros no pueden reemplazar las restricciones de activos y las verificaciones de firma anteriores. Permiten que los usuarios dependan menos de una respuesta no verificable, mientras que la política de activos asegura que incluso una firma válida no puede disponer de los activos de forma ilimitada. Construir ambas capas juntas es lo que realmente distribuye la capacidad de verificación entre los participantes.

VII. Construir una base pública para la identificación de anomalías y la verificación de seguridad

Antes de una transacción, alguien debería verificar si esta operación cumple con la política de activos y si ha cambiado repentinamente el comportamiento histórico. Anomalías evidentes pueden activar pausas o auditorías mejoradas; ampliar permisos requiere otro camino independiente. La IA puede participar en el juicio, pero no debería obtener un pase para eludir reglas estrictas.

Al mismo tiempo, necesitamos mantener conjuntamente casos de ataque, pruebas de permisos y herramientas de verificación que se puedan ejecutar repetidamente. Compartir normas, manteniendo implementaciones independientes y verificaciones independientes, es la única forma de reducir fallos comunes. Las fundaciones y los intercambios ya han realizado inversiones en seguridad, como la Iniciativa de Seguridad de Trillion Dollar de la Fundación Ethereum. El siguiente paso es preguntar si estas inversiones pueden convertirse en una base pública que otros equipos también puedan adoptar y verificar.

Estas siete tareas no pueden garantizar una seguridad absoluta. Lo que deben entregar son límites verificables: bajo qué condiciones se comprometen los permisos, cuánto se exponen los activos como máximo, cuánto tiempo se pueden detectar anomalías y de quién depende la recuperación.

Ingeniería de software potenciada por IA: nuestra nueva esperanza

Al llegar a este punto, puede que algunos digan: la dirección suena correcta, pero la industria ha estado avanzando durante tantos años, ¿cuántas personas y cuánto tiempo se necesitará para la reconstrucción? ¿No es esto idealismo?

Si seguimos estimando según los métodos de producción de software del pasado, esta pregunta es muy realista. Pero para 2026, creo que los agentes de codificación y la ingeniería de software potenciada por IA habrán cambiado nuestra capacidad de construcción. Lo que se entiende por agentes de codificación son asistentes de programación de IA que pueden leer y escribir código, invocar herramientas, ejecutar pruebas y continuar trabajando según la retroalimentación en un entorno de desarrollo. Los constructores establecen objetivos, delimitan fronteras de seguridad y utilizan estas herramientas para implementar y verificar sistemas, asumiendo la responsabilidad de los resultados.

El trabajo que antes requería grandes equipos para implementar, adaptar y mantener repetidamente, ahora puede ser intentado por pequeños equipos utilizando este nuevo enfoque de ingeniería. Un equipo mantiene una capa, entrega componentes alrededor de interfaces claras, y otros equipos revisan y combinan. Organizar el juicio arquitectónico humano, la capacidad de implementación de los agentes de codificación y la verificación de seguridad independiente es el camino de construcción que creo que merece una reevaluación seria.

La investigación de Anthropic y PNNL proporciona un ejemplo concreto: en un entorno simulado de infraestructura crítica limitado, los investigadores informaron que la reconstrucción de ataques se redujo de semanas a aproximadamente tres horas. No puede probar que un pequeño equipo ya puede reescribir de manera segura toda la industria, pero indica que el costoso trabajo de verificación y defensa puede surgir bajo nuevas condiciones de costo.

Una forma de organización que se puede iniciar ahora es construir conjuntamente una Fábrica de IA en Público. Expertos de la industria, académicos y profesionales escriben públicamente los requisitos y especificaciones de aceptación, indicando qué se debe proteger, qué operaciones están permitidas, qué permisos deben mantenerse incluso si se pierden, y luego se redactan pruebas de aceptación basadas en estos requisitos. Grupos de agentes de codificación asumen el trabajo principal de codificación, pruebas y depuración; diferentes equipos verifican el diseño y los resultados, y las personas asumen la responsabilidad de juicio y aceptación.

Los participantes pueden contribuir con ideas, máquinas, potencia de cálculo y cuotas de llamadas a modelos, es decir, tokens de IA. Las empresas de IA y computación en la nube también pueden apoyar esta construcción pública a través de cuotas de modelos, recursos de cálculo y herramientas. Las especificaciones, el código prototipo, los flujos de trabajo de los agentes, los entornos de prueba y los resultados de validación pueden convertirse en una base mantenida en común, permitiendo que el siguiente equipo continúe directamente. El objetivo es construir la capacidad de desarrollo como una infraestructura pública reutilizable, reduciendo la dependencia del tiempo de una sola persona o de un solo equipo.

Los atacantes también están utilizando IA, y ya no tenemos razón para dejar la defensa en los métodos de producción del pasado. Sin embargo, la generación de código es rápida, solo es el punto de partida. Escribir claramente las restricciones, permitir que las pruebas se ejecuten repetidamente y permitir que un componente sea inspeccionado y reemplazado es lo que convertirá la capacidad de IA en una mejora de infraestructura.

Los constructores independientes trabajan junto con agentes de codificación y herramientas de IA. El taller espacial es una metáfora de la construcción pública.

Quiero especialmente enviar este llamado a aquellos que aún aman construir. Aquí, el hacker es alguien que está dispuesto a entender cómo funciona el sistema, dispuesto a compartir descubrimientos y también dispuesto a permitir que otros verifiquen su trabajo. Este espíritu ha impulsado Internet y hoy puede impulsar Crypto.

No creo que esta industria carezca de personas inteligentes, ni creo que la industria de Crypto y AI no pueda encontrar los recursos para apoyar este trabajo. Lo más difícil es organizar talento, fondos y responsabilidad continua. Las fundaciones y las empresas capaces deberían estar dispuestas a asumir los costos a largo plazo de trabajos fundamentales que no generan ingresos directos, pero benefician a todos.

Espero que todos podamos crear una infraestructura de criptografía compartida globalmente. Diferentes redes y equipos pueden colaborar bajo restricciones de seguridad comunes, implementando y verificando mutuamente, permitiendo a los usuarios elegir y migrar. Puede comenzar con un componente, pero la dirección debe ser lo suficientemente amplia como para albergar la construcción conjunta de toda la industria. Todos los participantes, incluido ArcBlock, deben presentar contribuciones verificables.

Debemos construir juntos una infraestructura: incluso si un área ya ha sido comprometida, los activos aún tienen límites, otros sistemas aún pueden rechazar errores, y los usuarios aún tienen caminos para recuperar y salir. Usando el nombre de "Star Wars", esta es nuestra Nueva Esperanza. La esperanza proviene de los constructores comunes dispuestos a actuar, así como de los agentes de codificación y nuevas formas de ingeniería que les permiten asumir más trabajo de construcción en este momento.

Actuemos Ahora

Quiero invitar a los constructores de proyectos como Ethereum, Solana, Bitcoin, XRP Ledger, así como a intercambios como Binance, Coinbase, Kraken, y también a equipos de billeteras, protocolos, investigación de seguridad, IA y computación en la nube: comencemos con un piloto de alcance definido y hagamos mejoras que otros equipos también puedan adoptar y verificar.

Los nombres mencionados son solo ejemplos, sin ningún orden en particular. No importa el tamaño o la tecnología utilizada, todos son bienvenidos a participar. Esta invitación también incluye a los constructores de las rutas tecnológicas criticadas en este artículo; mejorar la seguridad de los activos vale la pena cruzar las fronteras de nuestros propios ecosistemas.

Estoy dispuesto a participar, contribuyendo con nuestra infraestructura existente, ingeniería de software y prácticas de colaboración de IA. Somos solo un pequeño equipo en la industria, y lo que podemos hacer es limitado, pero esperamos comenzar con un prototipo y un conjunto de pruebas que se puedan ejecutar repetidamente.

Las personas con experiencia operativa real pueden proporcionar escenarios de ataque desensibilizados, los equipos de billeteras y protocolos implementan protecciones, y los investigadores independientes intentan eludirlas. Cada equipo asume la parte que puede, verificando conjuntamente las soluciones y decidiendo los próximos pasos.

Estoy dispuesto a participar en la organización de las restricciones de activos y los requisitos de recuperación de este artículo en la primera especificación pública, y también dispuesto a contribuir con prácticas técnicas y de ingeniería relacionadas, junto con otros participantes para construir esta Fábrica de IA pública orientada a este piloto. Primero, elijamos un problema muy específico: las claves de transacción diarias ya han sido comprometidas, ¿cómo podemos asegurarnos de que los atacantes aún no puedan vaciar la billetera de una sola vez? Escribamos las pruebas de aceptación que definan el rango de pérdidas permitidas, los permisos para modificar las reglas y las condiciones de recuperación, y luego los agentes de desarrollo implementan el prototipo, permitiendo que otro grupo de agentes y investigadores independientes busquen caminos de elusión. Los servidores de datos pueden devolver saldos incorrectos y la recuperación después de la pérdida de dispositivos también puede incorporarse gradualmente a las pruebas. Lo que logró el prototipo, dónde falló y qué dependencias existen se explican públicamente, y luego se decide el siguiente paso basado en la evidencia.

Las personas dispuestas a participar son bienvenidas a compartir públicamente esta iniciativa en X o citarla, y @mave99a, para hablar sobre los problemas que desean resolver, casos de ataque desensibilizados o recursos que pueden contribuir. Espero que la discusión se realice públicamente, para que más constructores la vean y participen.

Crypto no puede seguir así. Aquellos dispuestos a hacerlo juntos, actuemos ahora, comenzando con una mejora que se pueda realizar y verificar.

1. Binance, anuncio preliminar de la publicación oficial y actualización de la investigación, 2026-10-30; análisis multichain de TRM. Este documento se verifica hasta el 2026-10-30; el estado de la investigación y recuperación puede cambiar. \↩\
2. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. \↩\
3. Uniswap, Equivalencia EVM de Unichain. La concentración de riesgos compartidos es un juicio del autor de este artículo, no es la conclusión de este documento. \↩\
4. Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, creado el 2024-05-07. \↩\
5. Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, arXiv v1 preprint; no es una evaluación del incidente de Binance. \↩\
6. Ethereum, valor máximo extraíble (MEV), mecanismos de ordenación, diferentes tipos e impactos negativos; "debería considerarse como una corrección de errores" es la afirmación del autor sobre el comportamiento dañino hacia los usuarios. \↩\
7. Archivo de noticias de PHP oficial 2026; actualización de vulnerabilidades conocidas aprovechadas por CISA 2026-10-26, CVE-2026-109618, CVE-2026-109619. \↩\
8. Safe, Guards y Modules, descripción de riesgos de funciones y permisos. \↩\
9. Apple, Apple ampliará las opciones de reparación con soporte para piezas genuinas usadas, 2024-04-11; descripción del soporte de bloqueo de piezas actuales. \↩\
10. Ledger, Respuesta de Ledger al ataque de implante de hardware, 2026-10, explicación del fabricante sobre el ataque en la cadena de distribución; Joe Grand, investigación inversa de implantes de hardware. No se debe escribir una estimación de pérdidas en línea que no haya sido verificada por el fabricante como conclusión. \↩\
11. Coinkite, Estado de seguridad actual de COLDCARD, consulta del 2026-10-30, registros de incidentes y reparaciones de julio de 2026 en actualización continua; la actualización y la migración de semillas son dos operaciones diferentes. \↩\
12. ERC-4337: Abstracción de cuentas utilizando Alt Mempool; Trezor, Preguntas frecuentes sobre SLIP39, recuperación umbral, compatibilidad y riesgos de contraseñas adicionales. Los mecanismos existentes son la base de la construcción, no representan que cada implementación sea confiable. \↩\
13. BIP-174: Formato de transacción de Bitcoin parcialmente firmada, formato de intercambio de transacciones pendientes, no es una norma de estrategia de activos interoperables. \↩\
14. W3C, Visión general de credenciales verificables v1.0, Nota del grupo del 2026-07-30; descripción de la privacidad de Ethereum. El estado estándar de la tecnología descrita en la visión general es independiente. \↩\
15. Documentación del Protocolo CoW, intención de transacción y mecanismo de solucionador; este artículo no proporciona un respaldo de seguridad integral para implementaciones específicas. \↩\
16. iShares, Informe anual de IBIT 2025, páginas 8-10 del PDF sobre arreglos de custodia y descripción de riesgos en la página 45. \↩\
17. Mark Nottingham, RFC 9518: Centralización, descentralización y estándares de Internet, 2023-12, presentación independiente, RFC explicativo, no es una norma de trayectoria. \↩\
18. Sección 8 del libro blanco de Bitcoin Verificación de pago simplificada; BIP-157: Filtrado de bloques del lado del cliente; Ethereum, clientes ligeros. El alcance de validación y las condiciones de confianza de diferentes clientes ligeros son diferentes. \↩\
19. Fundación Ethereum, Anunciando la Iniciativa de Seguridad de un Trillion de Dólares, 2025-05-14. \↩\
20. Anthropic, IA para defender infraestructura crítica, 2026-01-08, investigación en un entorno controlado en colaboración con PNNL. \↩\
21. Anthropic, Mapeo de amenazas cibernéticas habilitadas por IA, investigación de muestras de abuso real. \↩\
22. Lucasfilm, Star Wars: A New Hope (Episodio IV), 1977; este artículo toma prestado el nombre de la obra y la imagen de autoayuda conjunta. \↩\