727 FinanceUn incidente no solo se lleva los activos, sino también la confianza. Las criptomonedas no pueden seguir así; debemos salvarnos a nosotros mismos.
Autor: Robert Mao, Fundador y CEO de ArcBlock
Este artículo está autorizado para que cualquiera pueda reproducirlo y reenviarlo libremente, con la esperanza de que más personas vean este llamado para que la industria se salve a sí misma.
Crypto no puede seguir así. Una y otra vez, robos masivos se llevan no solo activos, sino también la confianza de los participantes en toda la industria. Debemos salvarnos a nosotros mismos.
El 29 de octubre de 2026, ocurrió un importante incidente de seguridad en Binance. Su anuncio preliminar estimó que aproximadamente $6.3 mil millones en activos se vieron afectados, y aproximadamente $3 mil millones de los activos afectados habían sido congelados; la investigación apuntó inicialmente a la laptop de un ingeniero de DevOps, y posteriormente también se descubrieron otros posibles puntos de intrusión. Binance también declaró que no se había encontrado evidencia de filtración de claves privadas de billeteras. El monto afectado no es la pérdida neta final, y la cadena de ataque completa sigue bajo investigación. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
Esta iniciativa está dirigida a los constructores de proyectos blockchain como Ethereum y Solana, y también a Binance, Coinbase, Kraken y todos los exchanges, billeteras, protocolos y constructores de seguridad dispuestos a participar: reconstruyamos juntos la base para proteger los activos. Estoy dispuesto a participar, y espero que más personas actúen en conjunto.
Esto ya es suficientemente grave. Pero lo que más me preocupa es cuánta confianza en Crypto destruirá este incidente, y a cuántos atacantes llevará a ver esta industria como un objetivo que aún vale la pena seguir atacando. Incluso si alguien finalmente asume las pérdidas, la compensación no puede reparar automáticamente la confianza de los usuarios, ni puede impedir que el mismo tipo de destrucción vuelva a ocurrir.
Binance es solo el punto de entrada que nos obliga a enfrentar el problema hoy. Mirando hacia otro lado, los exchanges, los puentes, los protocolos on-chain y las billeteras han dejado desde hace mucho tiempo un largo rastro de heridas. Nuevas redes y productos no dejan de aparecer, pero los viejos modos de falla se repiten una y otra vez. No podemos emitir un anuncio, esperar un tiempo y luego tratar el siguiente incidente como rutina.
También debemos reconocer que las estafas y la práctica de limitarse a crear conceptos sin asumir la responsabilidad de construir han dañado esta industria durante demasiado tiempo. Los equipos que construyen seriamente tecnología e infraestructura también deben cargar juntos con las consecuencias de la pérdida de confianza. Para cuando las personas vean todo Crypto como una estafa, la tecnología y la exploración que realmente vale la pena preservar también podrían ser abandonadas junto con ello.
Como fundador de ArcBlock y practicante en Crypto y Blockchain, no estoy dispuesto a aceptar tal resultado. Creo que esta industria tiene un valor que vale la pena proteger, y también creo que debemos asumir la responsabilidad de nuestra propia base de seguridad. Si seguimos esperando pasivamente el próximo incidente, el sangrado repetido podría terminar destruyendo todo lo que hemos construido juntos.Por lo tanto, quiero lanzar esta iniciativa: los constructores de exchanges, wallets y blockchains deberían reconstruir conjuntamente la base del control de activos y la verificación de seguridad, de modo que el alcance del daño de una sola intrusión quede acotado. La línea de tiempo a continuación explica por qué el cambio es necesario; la propuesta técnica que sigue es el trabajo que creo que podemos comenzar a hacer.
En 2008, Satoshi Nakamoto propuso un sistema de efectivo electrónico entre pares, intentando hacer que los pagos dependieran menos de intermediarios de confianza. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) Sin embargo, los incidentes importantes desde entonces han expuesto repetidamente el problema de que los fondos, la autorización y las dependencias de software vuelven a concentrarse.
A continuación se presenta una lista cronológica de incidentes representativos en áreas como exchanges centralizados (CEX), exchanges descentralizados (DEX), puentes y wallets. No es una base de datos completa de incidentes, ni una estadística de pérdidas año por año. Cuando se indican montos, se refieren al impacto bruto aproximado en el momento del incidente; el robo, la congelación y la recuperación posterior se describen por separado y no pueden sumarse como pérdidas permanentes.
2008 · Whitepaper de Bitcoin
Punto de partida
El whitepaper de Bitcoin propuso pagos entre pares sin instituciones financieras como intermediarias.
Fuente
2011–2014 · Robo prolongado de Mt. Gox
CEX
Mt. Gox sufrió robos prolongados y finalmente cesó operaciones. Una acusación posterior del Departamento de Justicia de EE. UU. alegó que aproximadamente 647.000 BTC fueron robados entre 2011 y 2014. No fue un ataque de un solo día en 2014.
Fuente
2012 · Bitcoinica y Bitfloor
CEX / infraestructura de custodia
El entorno de alojamiento Linode de Bitcoinica fue comprometido; en el mismo año, la copia de seguridad no cifrada de la wallet de Bitfloor se convirtió en un punto de entrada del ataque. Los servidores y las copias de seguridad detrás de la plataforma también forman parte del perímetro de seguridad de los activos.
Fuente
2015 · Hot wallet de Bitstamp
CEX
La hot wallet de Bitstamp fue comprometida y el entorno operativo se reconstruyó posteriormente. La distinción oficial entre el alcance del incidente y las reservas offline mostró que el aislamiento puede limitar el alcance de la exposición.
Fuente
2016 · Bitfinex
CEX
Aproximadamente 120.000 BTC fueron robados de Bitfinex. Los esquemas de multifirma siguen requiriendo autorización y verificación independientes de extremo a extremo.
Fuente 1 · Fuente 2
2016 · The DAO
Protocolo on-chain
El contrato de The DAO sufrió un ataque de reentrada y aproximadamente 3,6 millones de ETH fueron transferidos a una sub-DAO, lo que posteriormente desencadenó un fork de Ethereum. Una ruta de ejecución legítima puede producir resultados empresariales catastróficos.
Fuente 1 · Fuente 2
2017 · Biblioteca de wallet compartida de Parity
Wallet de contrato
La biblioteca de wallet compartida de Parity fue destruida y aproximadamente 513.000 ETH quedaron congelados. Incluso si no se transfieren, los fondos pueden volverse inutilizables debido a dependencias de código compartido.
Fuente
2018 · Coincheck
CEXLa hot wallet NEM de Coincheck fue robada. La frontera entre las reservas offline, los permisos de la hot wallet y las necesidades del negocio volvió a ser un problema.
Fuente
2019 · Binance
CEX
Binance anunció que se retiraron 7.000 BTC en una sola transacción. Las salidas de activos a gran escala deben restringirse antes de firmar.
Fuente
2020 · KuCoin
CEX
Incidente de la hot wallet de KuCoin, con una gran cantidad de activos posteriormente recuperados mediante colaboración multipartita. El monto bruto robado 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 fuera de Poly Network y posteriormente devueltos por etapas. La autorización cross-chain y el control de activos no pueden sostenerse solo mediante las rutas normales del negocio.
Fuente
2022 · Puente Ronin
Puente
Los permisos de los validadores de Ronin fueron comprometidos y se transfirieron 173.600 ETH y 25,5 millones de USDC. Las claves de múltiples validadores también pueden caer en la misma cadena de ataque.
Fuente
2022 · Monedero Slope
Monedero
Incidente del monedero Slope en el ecosistema Solana. Solana declaró oficialmente que la información de la clave privada se transmitió accidentalmente a un servicio de monitoreo de aplicaciones; no fue un compromiso del consenso de Solana.
Fuente
2023 · Euler
Protocolo de lending
Aproximadamente 197 millones de dólares en activos fueron transferidos fuera de Euler debido a una vulnerabilidad del protocolo y posteriormente recuperados. Las combinaciones complejas en una sola transacción pueden amplificar los fallos de la lógica de negocio.
Fuente
2023 · Ledger Connect Kit
Herramienta de conexión de monederos
Ledger Connect Kit sufrió un ataque de supply chain y código malicioso entró en el frontend de la aplicación. La seguridad del dispositivo hardware no puede sustituir 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 posteriormente revelaron ataques de ingeniería social dirigidos al personal relevante y a la cadena de firma.
Fuente
2024 · Radiant Capital
Protocolo de lending / firma
Aproximadamente 50 millones de dólares fueron robados de Radiant Capital y múltiples dispositivos de desarrolladores fueron comprometidos. La firma multipartita aún puede depender colectivamente de información de transacción contaminada.
Fuente
2025 · Bybit / Safe
CEX / frontend de monedero
El incidente de Bybit de aproximadamente 1.500 millones de dólares involucró el entorno de desarrollo y el frontend de Safe, y los firmantes aprobaron una transacción que cambió la lógica de control del monedero.
Fuente 1 · Fuente 2
2025 · Cetus DEX
DEXEl incidente de aproximadamente 223 millones de dólares en Cetus en Sui, con investigadores señalando un fallo en una biblioteca matemática. Los entornos non-EVM deben examinar igualmente su código y el alcance de la exposición de activos.
Fuente
2026-07 · Fallo del generador de números aleatorios de COLDCARD
Monedero hardware / generación de seedUn fallo de firmware debilitó la generación de semillas, permitiendo a los atacantes reconstruir las claves privadas relevantes mientras el dispositivo estaba fuera de línea. Actualizar no puede corregir semillas débiles que ya han sido generadas; la migración según el aviso sigue siendo necesaria.
Fuente
2026-10 · Implante de hardware Ledger
Ataque de billetera hardware / distribución
Ledger confirmó que dispositivos genuinos fueron modificados y circulados a través de canales de distribución en el sudeste asiático, con componentes implantados que robaban frases de recuperación durante la inicialización. El proveedor afirma que sus chips, sistema operativo y servidores no fueron comprometidos.
Fuente
2026 · Incidente multicadena de Binance
CEX / multicadena
Binance estimó inicialmente que aproximadamente $6.3 mil millones en activos se vieron afectados, y las investigaciones sobre otros posibles puntos de intrusión siguen en curso. Un único sistema operativo puede exponer activos en múltiples redes simultáneamente.
Fuente 1 · Fuente 2 · Fuente 3
Aquí hay CEX, pero también exchanges descentralizados, protocolos de préstamo y puentes; hay activos robados y activos congelados. Los ataques ocurren en diferentes capas, y los métodos de remediación difieren. Me opongo a reducir todo esto a la única frase "los usuarios no supieron salvaguardar sus claves privadas". ¿Cómo pueden los usuarios saber que el entorno de desarrollo de cierta herramienta, cierta biblioteca compartida o una autorización incomprensible se convertirá en el punto de entrada a todos sus activos?
Las redes distribuidas ya han hecho mucho, sin embargo, el aislamiento de fallos para el control de activos está lejos de ser suficiente. La ejecución en cadena completa fielmente una transacción, pero no puede responder por nosotros por qué esa transacción tiene derecho a mover tanto.
La contribución de Ethereum es significativa. Permitió que más personas escribieran aplicaciones en cadena y fomentó un rico conjunto de herramientas y experiencia de desarrollo. Pero hoy, muchas nuevas cadenas y L2 (redes de escalado de capa 2) tratan la compatibilidad con EVM como su objetivo principal. La EVM, la máquina virtual que ejecuta los contratos inteligentes de Ethereum, se está convirtiendo en una premisa técnica ampliamente replicada. La compatibilidad sí facilita la migración de aplicaciones; la documentación de proyectos como Unichain cita explícitamente la reutilización de las herramientas de Ethereum como el valor de un entorno de ejecución equivalente. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
Creo que tratar la compatibilidad con EVM como la respuesta predeterminada de la industria está creando una concentración estructural de riesgo. Puede haber muchos nombres de red, y los validadores pueden diferir, 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 dependencias compartidas no desaparecen solo porque el despliegue ocurra en otra cadena. Este es un juicio sobre la ruta técnica, no una afirmación de que toda implementación de EVM tenga necesariamente la misma vulnerabilidad.Aquí es también donde reside mi crítica a Ethereum. La capacidad de ejecución de contratos de propósito general se conecta directamente con activos transferibles, lo que impone una enorme responsabilidad al código de las aplicaciones y a las interacciones con las billeteras. Los contratos pueden llamar a contratos, las autorizaciones pueden persistir durante mucho tiempo, y una confirmación aparentemente ordinaria puede cambiar el modo de control posterior de una cuenta. La seguridad depende cada vez más de que cada equipo de desarrollo comprenda correctamente estas combinaciones, y de que cada usuario comprenda correctamente lo que ha firmado.
EIP-7702 deja este problema muy claro. Una transferencia ordinaria es "cuánto a quién esta vez"; una autorización de delegación puede ser "a partir de ahora, deja que este fragmento de código ejecute operaciones en nombre de mi cuenta". Tiene los objetivos de mejorar la experiencia del usuario y refinar los permisos, pero configurar una delegación en sí mismo otorga una amplia capacidad de ejecución, y los permisos granulares todavía tienen que ser implementados correctamente por el código delegado. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) El preprint "EIP-7702 Phishing Attack" de Minfeng Qi et al. estudia la vía de controlar persistentemente una cuenta tras inducir la firma de tales autorizaciones. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) A medida que aumenta la conveniencia, también aumenta la responsabilidad de seguridad; esta última no puede simplemente delegarse a los usuarios.
Este incidente de Binance abarca múltiples cadenas, y la investigación aún no ha concluido, por lo que el impacto total no puede atribuirse directamente a EIP-7702 o a la EVM. La reentrada, el compromiso de los servicios de firma y la manipulación del front-end tampoco son la misma vulnerabilidad. Pero tales distinciones no deberían convertirse en una excusa para dejar de cuestionar la arquitectura: ¿por qué la capa inferior no conserva más restricciones que no puedan eludirse fácilmente, en representación de los errores de las capas superiores?
MEV tampoco me satisface. Se refiere al espacio en el que los participantes obtienen valor extra mediante la inclusión, exclusión y ordenación de transacciones. Para mí, utilizar el poder de ordenación para interponer transacciones de usuarios y empeorar sus resultados de ejecución debería tratarse como un error que necesita corrección, no empaquetarse como una característica que vale la pena preservar solo porque alguien puede beneficiarse de ello. La documentación propia de Ethereum también reconoce explícitamente el daño del interponer transacciones a los usuarios y el riesgo de MEV para la estabilidad de la red. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV no es exclusivo de Ethereum e incluye también diferentes actividades como el arbitraje y la liquidación; la industria ya cuenta con investigación sobre mitigación. Mi crítica es que el incentivo para mantener la red no puede convertirse en una razón para sacrificar las condiciones de transacción de los usuarios. Un mejor sistema de transacciones debería escribir el resultado mínimo de entrega y las tarifas permitidas en la autorización, y limitar el espacio para que los ordenadores utilicen información no completada para perjudicar a los usuarios.Siempre he sentido que el impacto de Ethereum en el Crypto es algo parecido al impacto de PHP en Internet: permitió que muchas personas construyeran cosas y también dejó deuda de ingeniería que tardará mucho en pagarse. PHP todavía necesitaba corregir en octubre de 2026 una grave vulnerabilidad de ejecución remota de código. La madurez y la popularidad no pueden sustituir el endurecimiento continuo. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) Lo valioso de Internet es que los lenguajes, los frameworks y los servicios en la nube pueden evolucionar por separado. También deberíamos permitir que distintos modelos de activos y métodos de ejecución sigan desarrollándose, en lugar de tratar la "compatibilidad con la misma máquina virtual" como el boleto de entrada para participar en el ecosistema.
Por lo tanto, hago un llamado a los ecosistemas de Bitcoin, Solana y Ripple/XRP Ledger, así como a constructores incluido ArcBlock, a participar seriamente en la construcción de una base de seguridad común. Participar en estándares e interoperabilidad no requiere primero convertirse en Ethereum. La diversidad debe implementarse en los métodos de control y verificación de activos y estar abierta al escrutinio público. Los incidentes de Slope y Cetus ya nos han recordado que lo no-EVM tampoco tiene una exención de seguridad.
Lo que espero ver tomar forma es una especificación de seguridad que los distintos entornos de ejecución puedan adoptar: los mismos límites de activos y requisitos de verificación pueden ser implementados por separado por la EVM y otras vías, y luego las garantías y los costos de cada una pueden examinarse públicamente.
1. Que los controles de riesgo subyacentes limiten el poder de disposición sobre los activos
Las carteras grandes deberían poder establecer listas blancas de destinatarios, límites acumulados de gasto y períodos de espera para nuevos destinatarios. La clave es que estas reglas no puedan ser canceladas de inmediato por la misma clave de transacción cotidiana. Modificar las reglas requiere una autorización independiente y debe dejar tiempo para la monitorización y la revocación.Las cuentas inteligentes existentes ya cuentan con una base de implementación; por ejemplo, Safe Guards puede añadir restricciones de transacción más allá del multifirma. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) Necesitamos convertir esto en una capacidad fundacional más fácil de adoptar que cubra todas las vías de control de activos. Si solo se restringen las transferencias directas mientras se permiten evasiones mediante aprobaciones ilimitadas, módulos o actualizaciones, la protección fallará. También deben entrar en el ámbito de verificación si el contrato de lista blanca puede actualizarse y si los permisos del receptor han cambiado.El Bloqueo de Activación de Apple ofrece una inspiración para la vida cotidiana: restringe la reactivación de dispositivos robados y limita la calibración de ciertas piezas robadas, con el objetivo de reducir el valor que puede explotarse tras el robo. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) Las billeteras también merecen diseñarse en esta dirección. Si un atacante obtiene una clave, el rango de activos que puede convertir en efectivo sigue siendo limitado, y el retorno esperado de un ataque puede disminuir; riesgos como la interrupción de servicios aún deben gestionarse por separado.
Esto es lo que llamo la "constitución" de la seguridad de los activos: la autoridad operativa puede verse comprometida, pero la autoridad para modificar los límites debe permanecer independiente. Los procesos de recuperación también deben estar restringidos, para evitar que una única configuración errónea bloquee permanentemente los activos.
II. Hacer que las billeteras asuman la responsabilidad de la seguridad, en lugar de limitarse a entregar las palabras mnemónicas
Tengo una fuerte insatisfacción con los sistemas de billeteras actuales: si un producto pide a una persona común que copie un conjunto de palabras, exige que nunca las filtre, pierda ni sea engañada para revelarlas, y luego atribuye todos los fallos posteriores a la responsabilidad del usuario, considero que esto es un diseño irresponsable. La autocustodia debe dar a las personas control, y también debe darles capacidades de protección y 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 llegar a más usuarios comunes.Los incidentes recientes han puesto este problema directamente sobre la mesa. En octubre de 2026, Ledger confirmó que los atacantes modificaron dispositivos genuinos y luego los enviaron de vuelta al mercado a través de canales de distribución en el sudeste asiático, con componentes implantados que robaban las palabras de recuperación durante la inicialización. Ledger definió esto como un ataque de distribución localizado después de que el dispositivo saliera de la fábrica, en lugar de un compromiso de su chip, sistema operativo o servidores. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) El incidente de COLDCARD en julio involucró un debilitamiento del firmware en la generación de la semilla: el dispositivo no necesitaba ser controlado remotamente para que un atacante reconstruyera las claves privadas relevantes. Actualizar el firmware corrige el proceso de generación en adelante, pero las semillas débiles que ya han sido generadas todavía necesitan ser migradas. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
Estos dos incidentes no son el mismo tipo de vulnerabilidad, pero juntos demuestran: incluso si los usuarios copian cuidadosamente las palabras y mantienen el dispositivo fuera de línea, no pueden verificar la aleatoriedad y la integridad de la cadena de suministro en nombre del fabricante. Que el dispositivo muestre las palabras de respaldo tiene el propósito de recuperación fuera de línea, pero también provoca que el secreto de recuperación completo pase por una pantalla y una ruta de respaldo que necesitan protección. La seguridad del chip no puede reemplazar la verificación del dispositivo completo y del proceso de entrega.
El objetivo de la mejora debería ser el ciclo de vida completo de la billetera: cómo se generan las claves, cómo se explican las transacciones, cómo se separan los permisos y cómo funciona la recuperación después de que se pierde un dispositivo. La abstracción de cuentas, es decir, permitir que las cuentas verifiquen la autorización mediante reglas programables, y los respaldos de umbral como SLIP-39, ya cuentan con estándares y bases de implementación, por lo que no se puede decir que nadie en la industria esté trabajando en ellos. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) Pero necesitamos convertir estas capacidades en protecciones probadas y fáciles de usar, en lugar de que los usuarios ensamblen esquemas complejos por su cuenta.
La simple ofuscación de las palabras mnemónicas no es suficiente. Las direcciones más confiables incluyen respaldos cifrados auditados, recuperación de umbral y autorización de dispositivos independientes, y que los usuarios completen simulacros de recuperación antes de depositar grandes cantidades de activos. Los fragmentos de respaldo y la multifirma son capas diferentes: los primeros pueden recombinarse en el mismo secreto durante la recuperación, mientras que la segunda requiere que múltiples firmantes independientes aprueben una transacción. Los servicios de recuperación no deben convertirse silenciosamente en una nueva clave maestra, ni una contraseña adicional debe convertirse en otra trampa donde perderla signifique una pérdida irrecuperable.Las carteras personales y los sistemas de carteras de exchanges pueden compartir especificaciones de seguridad para descripciones de transacciones, solicitudes de firma, restricciones de activos y procesos de recuperación, mientras adoptan diferentes límites y políticas de aprobación. El PSBT de Bitcoin ya proporciona un formato para pasar transacciones no firmadas entre herramientas, y esta interfaz común merece seguir desarrollándose. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) Lo que es común son los requisitos de seguridad verificables; cada cadena todavía necesita aclarar sus propias reglas de adaptación. Las carteras deben presentar claramente qué transferirá esta firma y cuánta autoridad posterior otorga a quién, y las políticas independientes deben rechazar operaciones fuera de límites; una página de confirmación más bonita no es suficiente.
III. Lograr verificabilidad con la divulgación mínima necesaria
Demostrar que una condición se cumple no debería requerir siempre que los usuarios divulguen todos los datos subyacentes. La divulgación selectiva, las pruebas de conocimiento cero y el acceso de auditoría otorgado bajo demanda deberían convertirse en opciones normales en la infraestructura. Esto también está relacionado con la seguridad de los activos: la identidad pública y las relaciones entre activos pueden proporcionar pistas para un engaño dirigido; los datos que el negocio no necesita deberían exponerse lo menos posible.
El sistema de credenciales verificables del W3C ya cuenta con una vía técnica para la divulgación selectiva; sin embargo, aún debe aclararse cómo probar que las entradas son auténticas, que las credenciales siguen siendo válidas y cómo se revoca el estado. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) Adoptar pruebas de conocimiento cero (ZK) no oculta automáticamente los montos y las relaciones de las transacciones; las pruebas de escalabilidad y la protección de la privacidad son objetivos diferentes.
Por ejemplo, cuando un negocio solo necesita verificar la elegibilidad para participar, un usuario puede presentar una conclusión de elegibilidad válida emitida por una institución de confianza sin divulgar materiales financieros completos. Cuando sea necesario demostrar que un valor oculto satisface una condición, se puede utilizar entonces un mecanismo de prueba adecuado. La fuente de confianza de la credencial y su estado de revocación todavía necesitan ser verificados.
Mi iniciativa es primero aclarar "quién necesita verificar qué" y luego diseñar los datos que deben hacerse públicos. Quienes verifican la elegibilidad pueden necesitar solo la conclusión de elegibilidad; quienes asumen responsabilidades de auditoría específicas pueden obtener evidencia restringida. Las restricciones verificables públicamente deberían minimizar la información personal expuesta permanentemente a todos.
IV. Hacer que los servicios de transacción estén lo más libres posible de custodia centralizadaLa coincidencia de operaciones, la búsqueda de rutas y la liquidación de activos deben diseñarse por separado. Un servicio que proporciona un punto de entrada de negociación solo debe obtener los permisos necesarios para completar la liquidación actual en la medida de lo posible, de modo que los activos del usuario permanezcan bajo su respectivo control el resto del tiempo. Los protocolos de transacción basados en intenciones existentes ya han explorado parte del camino, y la industria puede seguir completándolo. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
Lo que los usuarios aceptan deben ser condiciones de liquidación claras, incluido qué se paga, qué se recibe como mínimo, cuándo expira y las comisiones permitidas. Después de que un servicio de negociación sea comprometido, el atacante puede denegar el servicio, pero no puede cambiar arbitrariamente estas condiciones. Las empresas que aún requieren custodia centralizada también deben separar los permisos de reserva y operativos, y limitar la exposición de la cartera caliente y los límites de reposición automática.
IBIT es el producto cotizado de bitcoin de iShares, y lo que se negocia en el mercado son sus acciones. Su estructura proporciona un ejemplo de aislamiento parcial: las acciones y el Bitcoin subyacente se registran por separado, y las claves privadas relevantes para el Vault Balance (saldo en custodia) se colocan en almacenamiento en frío. Los cambios en el registro de negociación de acciones no requieren que el Bitcoin subyacente se mueva con cada transacción. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) Lo que se puede aprender de esto es la separación de los derechos de negociación y los derechos de disposición de reservas. Su Trading Balance (saldo del servicio de negociación) tiene una disposición diferente, y la custodia en sí misma también conlleva riesgos; el almacenamiento en frío debe combinarse con instrucciones independientes y verificación de firmas.
Comparo el punto de entrada de negociación con un router con la esperanza de que pueda reemplazarse sin llevar un interruptor maestro sobre todos los activos de los usuarios. La liquidación es más compleja que el reenvío de paquetes, y la entrega de activos y la autorización aún deben verificarse de forma independiente. Hacer que un servicio no sea custodial y luego otorgarle derechos de retiro ilimitados solo traerá de vuelta el riesgo centralizado.
V. Utilizar una arquitectura por capas para aislar fallos y preservar la reemplazabilidadNecesitamos interfaces de identidad y autorización, políticas de activos y métodos de verificación de liquidación que puedan evolucionar de forma independiente. Las distintas cadenas pueden conservar sus propios modelos de ejecución y conectarse mediante interfaces claras. Las interfaces deben indicar las garantías de seguridad y sus condiciones, no limitarse a decir "la llamada se realizó correctamente".La experiencia de Internet respalda este enfoque. En la RFC 9518, "Centralization, Decentralization, and Internet Standards", Mark Nottingham analiza específicamente situaciones en las que la centralización puede ser útil y también analiza el poder y los riesgos que conlleva. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) Esta es precisamente la actitud que vale la pena aprender: dejar que la arquitectura responda qué responsabilidades pueden centralizarse, en qué grado y cómo evitar que ese poder se expanda. Se puede permitir que un servicio identifique anomalías de forma centralizada mientras su permiso para tocar activos está limitado; los usuarios deben poder cambiar de servicio sin perder sus propias políticas de activos y registros de verificación.
La pregunta de aceptación más importante es: después de que un servicio empresarial sea comprometido, ¿qué capa independiente todavía puede rechazarlo? Si todas las capas comparten una única clave administrativa, la llamada estratificación solo es estratificación en un diagrama de despliegue.
Este objetivo puede verse como cinco capas de responsabilidad: el servicio de transacciones envía solicitudes, la billetera expresa la intención del usuario, una política independiente limita la autoridad sobre la disposición de activos, el componente de verificación comprueba operaciones y evidencia, y la capa de liquidación impone restricciones y proporciona registros verificables. Pueden ser implementadas por equipos diferentes, y sus dependencias y condiciones de fallo también deben describirse por separado.
La arquitectura objetivo defendida en este artículo. La capa de liquidación debe imponer la política de activos; las indicaciones en la billetera no pueden sustituir esta restricción. La firma diaria, los cambios de reglas y la autoridad de recuperación deben aislarse y someterse a pruebas de elusión.
6. Permitir que los usuarios verifiquen ligeramente sus propios activos
Las personas comunes no deberían tener que almacenar y ejecutar todo el historial de toda la cadena para verificar sus propios saldos y recibos; tampoco deberían tener que confiar únicamente en un solo servidor detrás de la billetera. Satoshi Nakamoto ya propuso SPV, verificación de pago simplificada, en la Sección 8 del whitepaper. La BIP-157 de Bitcoin sigue explorando permitir que los clientes descarguen filtros y encuentren bloques relacionados consigo mismos; Ethereum también tiene diseños de cliente ligero. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) Así que el problema no es que nadie lo haya pensado alguna vez, sino que todavía necesitamos incorporar capacidad de verificación con condiciones de seguridad claras en las billeteras que los usuarios usan a diario.Tomemos como ejemplo una cadena que admite pruebas de estado de cuenta: al consultar un saldo, el servidor debe devolver tanto el saldo como una prueba. La billetera primero verifica un resumen corto del bloque, es decir, el encabezado del bloque, según las reglas de esa cadena, y luego comprueba si este saldo es consistente con los datos comprometidos por el resumen. El servidor proporciona la respuesta y la billetera puede verificarla. El SPV de Bitcoin verifica la evidencia de que las transacciones relevantes fueron incluidas; no puede copiarse directamente como prueba de saldo. La billetera también debe mostrar claramente hasta dónde se ha sincronizado y qué información ha sido verificada; cuando faltan pruebas, los datos están desactualizados o las fuentes entran en conflicto, debe advertir o detener las operaciones de alto riesgo que dependen de esta información, y no debe recurrir silenciosamente a la confianza ciega.
La verificación ligera todavía tiene condiciones. Probar que una transacción fue incluida en un bloque no es lo mismo que comprobar por uno mismo que todas las transacciones del bloque son válidas. Diferentes esquemas pueden depender de que una mayoría del poder de hash sea honesta, o de un registro inicial confiable, es decir, un checkpoint; también deben protegerse contra servidores que ocultan datos o aíslan a los usuarios en un registro de cadena desactualizado. También debe abordarse si la consulta en sí expone las direcciones que le importan al usuario. Los nodos completos y los productores de bloques no son el mismo rol; Ethereum hoy utiliza validadores en lugar de mineros para la producción de bloques.
Más importante aún, probar que "esta transferencia realmente ocurrió en la cadena" no puede probar que "esta es exactamente la transferencia que el usuario quería". Los clientes ligeros no pueden reemplazar los límites de activos y las comprobaciones de firma anteriores. Permiten a los usuarios depender menos de una respuesta no verificable, mientras que la política de activos garantiza que incluso una firma válida no pueda disponer de activos sin límite. Solo construyendo ambas capas juntas se puede distribuir la capacidad de verificación entre los participantes.
7. Construir la identificación de anomalías y la verificación de seguridad como infraestructura pública
Antes de una transacción, alguien debería comprobar si la operación cumple con la política de activos y si cambia repentinamente el comportamiento histórico. Las anomalías evidentes pueden desencadenar una pausa o una revisión escalada; ampliar permisos requiere otra vía independiente. La IA puede participar en el juicio, pero no debe recibir un pase que anule las reglas estrictas.
Al mismo tiempo, necesitamos mantener conjuntamente casos de ataque, pruebas de permisos y herramientas de verificación que puedan ejecutarse repetidamente. Solo compartiendo especificaciones y preservando implementaciones independientes y verificación independiente se pueden reducir las fallas de modo común. Las fundaciones y los exchanges ya tienen inversiones en seguridad, como la Iniciativa de Seguridad del Billón de Dólares de la Fundación Ethereum. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) La siguiente pregunta que hay que plantear es si la inversión puede transformarse en infraestructura pública que otros equipos también puedan adoptar e inspeccionar.Ninguno de estos siete elementos de trabajo puede garantizar una seguridad absoluta. Lo que deben entregar son límites inspeccionables: bajo qué condiciones de compromiso de permisos, cuántos activos quedan expuestos como máximo, con qué rapidez se pueden descubrir las anomalías y de quién depende aún la recuperación.
Llegados a este punto, algunos dirán: la dirección suena bien, pero el sector lleva ya muchos años; ¿cuántas personas y cuánto tiempo requeriría una reconstrucción? ¿No sigue siendo esto idealismo?
Si se estima según el modo pasado de producción de software, esta duda es muy realista. Pero para 2026, creo que los agentes de programación y la ingeniería de software habilitada por IA ya han cambiado la capacidad de construcción que podemos movilizar. Los agentes de programación mencionados aquí son asistentes de programación con IA que pueden leer y escribir código, invocar herramientas, ejecutar pruebas y continuar trabajando en función de la retroalimentación en un entorno de desarrollo. Los constructores fijan objetivos, definen límites de seguridad, usan estas herramientas para implementar y verificar sistemas, y asumen la responsabilidad de los resultados.
El trabajo que antes requería grandes equipos para implementar, adaptar y mantener repetidamente ahora puede ser intentado por equipos pequeños con este nuevo enfoque de ingeniería. Un equipo se encarga de una capa, entrega componentes en torno a interfaces claras, y luego otros equipos los inspeccionan y combinan. Organizar el juicio arquitectónico humano, la capacidad de implementación de los agentes de programación y la verificación de seguridad independiente es, en mi opinión, la ruta de construcción que vale la pena reevaluar seriamente.
La investigación de Anthropic y PNNL ofrece un ejemplo concreto: en un entorno de simulación limitado de infraestructura crítica, los investigadores informaron que la reconstrucción del ataque se redujo de posiblemente varias semanas a unas tres horas. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) No puede probar que un equipo pequeño ya pueda reescribir de forma segura todo el sector, pero muestra que el trabajo de verificación y de ataque-defensa, antes costoso, puede tener nuevas condiciones de costo.
Un enfoque organizativo que puede iniciarse ahora es construir conjuntamente una Build in Public AI Factory. Expertos del sector, académicos y profesionales escriben abiertamente requisitos y especificaciones de aceptación (spec), explicando qué se debe proteger, qué operaciones están permitidas y qué límites deben mantenerse aún tras el compromiso de qué permisos, y luego convierten estos requisitos en pruebas de aceptación. Grupos de agentes de programación asumen el trabajo principal de codificación, prueba y depuración; diferentes equipos inspeccionan diseños y resultados, y los humanos asumen la responsabilidad del juicio y la aceptación.Los participantes pueden aportar ideas, máquinas, potencia de cómputo y cuotas de invocación de 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 mediante cuotas de modelos, recursos de cómputo y herramientas. Las especificaciones, el código prototipo, los flujos de trabajo de agentes, los entornos de prueba y los resultados de verificación pueden convertirse en infraestructura mantenida en común, permitiendo que el siguiente equipo continúe directamente desde ahí. El objetivo es convertir la capacidad de desarrollo en instalaciones públicas reutilizables y reducir la dependencia del tiempo de cualquier persona o de cualquier equipo.
Los atacantes también están usando IA, y ya no tenemos razón para dejar la defensa en los métodos de producción del pasado. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) Pero que la generación de código sea rápida es solo el punto de partida. Solo escribiendo las restricciones con claridad, haciendo que las pruebas se puedan ejecutar repetidamente y logrando que un componente sea inspeccionable y reemplazable, la capacidad de la IA puede transformarse en una mejora de la infraestructura.
Los constructores independientes trabajan juntos con la ayuda de agentes de programación y herramientas de IA. El taller espacial es una metáfora de la construcción pública. Quiero dirigirme especialmente a quienes todavía aman construir. El "hacker" aquí se refiere a alguien dispuesto a averiguar cómo funciona un sistema, dispuesto a compartir lo que encuentra y dispuesto a dejar que otros prueben su trabajo. Ese espíritu alguna vez impulsó el avance de Internet, y hoy también puede impulsar el avance de Crypto.
No creo que a esta industria le falten personas inteligentes, y no creo que las industrias de Crypto e IA no puedan encontrar los recursos para apoyar este trabajo. Lo más difícil es organizar juntos el talento, el financiamiento y la responsabilidad sostenida. Las fundaciones y las empresas capaces deberían estar dispuestas a asumir el costo a largo plazo del trabajo fundacional que no genera ingresos directamente pero beneficia a todos.
Espero que todos puedan trabajar juntos para construir una infraestructura criptográfica compartida globalmente. Diferentes redes y equipos pueden colaborar bajo restricciones de seguridad compartidas, cada uno implementando sus propias soluciones y probando las de los demás, y los usuarios pueden elegir y migrar. Puede comenzar con un solo componente, pero la dirección debe ser lo suficientemente grande como para acoger a toda la industria construyendo en conjunto. Todos los participantes, incluido ArcBlock, deberían aportar trabajo verificable.
Deberíamos construir conjuntamente un tipo de infraestructura en la que, incluso si alguna parte ha sido comprometida, los activos sigan teniendo límites, otros sistemas aún puedan rechazar errores y los usuarios aún tengan caminos de recuperación y salida. Tomando el nombre de Star Wars, esta es nuestra A New Hope. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) La esperanza proviene de constructores ordinarios dispuestos a actuar, y también de este momento en que los agentes de programación y los nuevos métodos de ingeniería les permiten asumir más trabajo de construcción.Quiero extender una invitación a los constructores de proyectos como Ethereum, Solana, Bitcoin y XRP Ledger, a exchanges como Binance, Coinbase y Kraken, y también a equipos de wallets, protocolos, investigación de seguridad, IA y computación en la nube: comiencen con un piloto de alcance claramente definido y produzcan conjuntamente mejoras que otros equipos puedan adoptar y probar.
Los nombres enumerados son solo ejemplos, en ningún orden particular. Independientemente de su tamaño o de la ruta técnica que tomen, son bienvenidos a participar. Esta invitación también incluye a los constructores de las rutas técnicas criticadas en este artículo; mejorar conjuntamente la seguridad de los activos vale la pena cruzar las fronteras de nuestros respectivos ecosistemas.
Yo mismo estoy dispuesto a participar y aportar nuestra infraestructura existente, ingeniería de software y prácticas de colaboración con IA. Somos solo un equipo pequeño en la industria, y lo que podemos hacer es limitado. Espero comenzar con un prototipo y un conjunto de pruebas repetibles.
Las personas con experiencia operativa práctica pueden aportar escenarios de ataque desensibilizados, los equipos de wallets y protocolos pueden implementar protecciones, y los investigadores independientes pueden intentar evadirlas. Cada equipo asume la parte que puede manejar, prueba conjuntamente la solución y decide el siguiente paso.
Estoy dispuesto a participar en organizar los requisitos de limitación y recuperación de activos de este artículo en la primera especificación pública, y también estoy dispuesto a aportar las prácticas técnicas y de ingeniería relevantes para construir, junto con otros participantes, una AI Factory pública para este piloto. Primero elegir un problema muy concreto: una vez que la clave de transacción cotidiana ha sido comprometida, ¿cómo se puede evitar que el atacante vacíe la wallet de una sola vez? Escribir el rango de pérdida permitido, la autoridad para modificar reglas y las condiciones de recuperación en pruebas de aceptación, luego hacer que agentes de desarrollo implementen un prototipo, y que otro grupo de agentes e investigadores independientes busquen rutas de evasión. Los servidores de datos que devuelven saldos incorrectos, y la recuperación tras la pérdida del dispositivo, también pueden añadirse gradualmente a las pruebas. Lo que el prototipo logra, dónde falla y qué dependencias quedan deben explicarse públicamente, y el siguiente paso debe decidirse con base en la evidencia.
Quienes estén dispuestos a participar son bienvenidos a repostear o citar públicamente esta iniciativa en X y @mave99a, y hablar sobre el problema que quieren resolver, casos de ataque desensibilizados o los recursos que pueden aportar. Espero que la discusión transcurra públicamente, para que más constructores puedan verla y sumarse.
Crypto no puede seguir así. Quienes estén dispuestos a trabajar juntos, actuemos ahora, comenzando con una mejora que se pueda construir y que resista las pruebas.Binance, publicación oficial del anuncio inicial y actualización oficial de la investigación de seguimiento, 2026-10-30; análisis multicadena de TRM. Este borrador fue verificado a fecha de 2026-10-30; el estado de la investigación y recuperación puede cambiar. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Equivalence. La concentración de riesgo de dependencias compartidas es un juicio del autor en este artículo, no una conclusión de dicho documento. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, creado 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, preprint arXiv v1; no constituye una identificación de este incidente de Binance. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), mecanismos de ordenación, diferentes tipos y efectos negativos; "debería corregirse como un bug" es la postura de ingeniería del autor sobre comportamientos que perjudican a los usuarios. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
Archivo de noticias oficiales de PHP 2026; actualización del catálogo de vulnerabilidades explotadas conocidas de CISA del 2026-10-26, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards and Modules, descripción de funcionalidad y riesgos de permisos. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; descripción actual del soporte de emparejamiento de piezas. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, declaración del proveedor sobre un ataque en la cadena de distribución; Joe Grand, investigación de ingeniería inversa sobre implantes de hardware. No presentar estimaciones no verificadas de pérdidas en la red como conclusiones definitivas. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, consultado 2026-10-30, registro actualizado continuamente del incidente de julio de 2026 y su remediación; la actualización y la migración de la semilla son dos operaciones distintas. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, recuperación por umbral, compatibilidad y riesgos adicionales de la frase de contraseña. Los mecanismos existentes son una base para construir, y no significan que cada implementación sea fiable. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: Formato de Transacción Bitcoin Parcialmente Firmada, un formato de intercambio para transacciones no firmadas, no una especificación de estrategia general de activos entre cadenas. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Verifiable Credentials Overview v1.0, 2026-07-30 Group Note; notas de privacidad de Ethereum. El estado normativo de las tecnologías descritas en la visión general es independiente en cada caso. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
Documentación de CoW Protocol, intenciones de transacción y mecanismos de solver; este artículo no proporciona un respaldo de seguridad integral para ningún despliegue específico. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, IBIT 2025 Annual Report, páginas 8–10 del PDF sobre acuerdos de custodia y página 45 sobre divulgación de riesgos. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Centralization, Decentralization, and Internet Standards, 2023-12, presentado de forma independiente, RFC informativo, no una especificación de la vía normativa. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Bitcoin whitepaper Sección 8 Simplified Payment Verification; BIP-157: Client Side Block Filtering; Ethereum, Light clients. Los diferentes clientes ligeros tienen distintos alcances de verificación y condiciones de confianza. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Announcing the Trillion Dollar Security Initiative, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, AI to defend critical infrastructure, 2026-01-08, investigación en entorno limitado en colaboración con PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Mapping AI-enabled cyber threats, investigación sobre muestras reales de abuso. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; este artículo toma prestados el título y la imaginería del auto-rescate conjunto. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)