Vitalik plantea transacciones simuladas para repensar la seguridad en las criptomonedas
Vitalik Buterin dice que las simulaciones de transacciones podrían cerrar la brecha entre la intención del usuario y los resultados en la cadena, transformando la seguridad en criptomonedas desde sus cimientos.
El cofundador de Ethereum, Vitalik Buterin, ha propuesto una forma innovadora de pensar sobre la seguridad en criptomonedas. No comienza con el código. Comienza con la intención.
En una publicación en X, Vitalik Buterin argumentó que la seguridad y la experiencia del usuario no son campos separados en absoluto. Ambos, escribió, se tratan de reducir la brecha entre lo que un usuario realmente desea y lo que un sistema realmente hace. La diferencia es que la seguridad trata con la versión peor de esa brecha, donde el comportamiento adversarial hace que el costo de la divergencia sea muy alto.
El argumento va directo a algo que la mayoría de los desarrolladores de criptomonedas dan por sentado.
Por qué la “Seguridad Perfecta” Nunca Fue Real
Buterin dijo en X que la seguridad perfecta es imposible. No porque fallen las máquinas. No porque los ingenieros cometan errores. Sino porque la intención humana es demasiado compleja para ser codificada completamente.
Usó un ejemplo sencillo. Que un usuario quiera enviar 1 ETH a Bob suena claro. Pero “Bob” no puede definirse matemáticamente. La clave pública podría estar equivocada. La cadena podría bifurcarse. La palabra “ETH” se vuelve subjetiva. Esa brecha entre la imagen del mundo real del usuario y la representación matemática del sistema es donde reside el riesgo.
Se vuelve más complicado con los objetivos de privacidad. Encriptar mensajes parece suficiente. Pero los metadatos, patrones de temporización y gráficos de comunicación pueden filtrar una gran cantidad de información. ¿Qué se considera exposición trivial versus exposición catastrófica? Ninguna fórmula responde a eso de manera clara.
El Principio de Redundancia que Buterin Promueve
La solución que Buterin señala no es un solo cerrojo más fuerte. Son especificaciones superpuestas. El sistema solo actúa cuando varias descripciones de la intención coinciden entre sí.
Ya listó varios ejemplos de este patrón funcionando en la práctica. Los sistemas de tipos en programación hacen que los desarrolladores escriban tanto lo que hace el código como la forma que tiene cada estructura de datos. Si esas dos versiones del programa no coinciden, no compila. La verificación formal hace algo similar a las pruebas matemáticas. Las carteras multisig requieren que varias claves estén de acuerdo antes de mover fondos. Las advertencias de límite de gasto se activan cuando algo parece fuera de lo normal.
Las simulaciones de transacciones encajan en la misma lógica. Según Vitalik Buterin en X, el usuario primero especifica una acción, luego ve una vista previa simulada de lo que realmente sucede en la cadena. El clic que confirma o cancela esa simulación se convierte en una segunda especificación. Ambas deben apuntar en la misma dirección.
Las afirmaciones posteriores en las transacciones llevan esto más allá. La propia transacción codifica tanto la acción como sus efectos esperados. Si no coinciden en la ejecución, la transacción falla.
También te puede interesar: npm Worm roba claves criptográficas, apunta a 19 paquetes
Dónde entran los LLM en la imagen
Peroerin no se detuvo en las herramientas tradicionales. Dibujó una línea directa desde este marco hasta cómo los modelos de lenguaje de IA deben y no deben usarse en la seguridad en criptomonedas.
Un LLM de propósito general, dijo en su publicación en X, actúa como una sombra del sentido común humano. Un modelo ajustado a un comportamiento específico de un usuario aproxima ese sentido de lo que es normal versus inusual. Eso lo convierte en un ángulo más desde el cual se puede aproximar la intención. Un ángulo verdaderamente diferente del código formal o las firmas criptográficas, que es el objetivo principal. La redundancia funciona mejor cuando las especificaciones provienen de direcciones completamente distintas.
Sin embargo, fue claro sobre el límite. Un LLM nunca debe ser la única cosa que decida si una transacción refleja la intención del usuario. Eso colapsaría la redundancia en la que toda la estrategia se basa.
Vale la pena leer: El plan de capa cypherpunk de Vitalik podría cambiar para siempre Ethereum
La seguridad no es más clics
Un punto que Buterin destacó merece atención por sí solo. Una buena seguridad no significa hacer que los usuarios confirmen todo con más frecuencia. Eso intercambia un problema por otro.
El objetivo real, como dijo en X, es facilitar o automatizar acciones de bajo riesgo, mientras que las acciones verdaderamente peligrosas sean difíciles. Ese equilibrio es el verdadero desafío de diseño. La fricción en los lugares equivocados no protege a los usuarios. Los entrena a hacer clic en advertencias sin leer.
Esa observación tiene implicaciones directas en cómo se construyen las carteras de Ethereum. También afecta a cada capa de la pila, desde los sistemas operativos hasta la verificación de contratos inteligentes y el hardware. El mismo principio se aplica en todos ellos.
También leer: Los ETFs de Bitcoin atraen 88 millones de dólares mientras los flujos de Ethereum se estancan cerca de cero
El marco de Buterin no promete un problema resuelto. Propone una mejor forma de pensar sobre uno que no tiene solución. Ninguna especificación única de la intención del usuario será alguna vez completa. La pregunta es cuántos ángulos diferentes puedes revisar antes de que el sistema actúe.