Los modelos de IA de largo alcance resumen conversaciones y historiales de tareas para continuar procesando. ARCBench verifica, mediante operaciones reales de herramientas, si los prohibidos aún permanecen en el resumen y si esto garantiza la seguridad. Crea historiales en la plataforma de ejecución "pi", luego introduce solicitudes que violan las reglas tras comprimir el historial, y compara las operaciones con y sin compresión. Al mismo tiempo, examina si las reglas se mantuvieron, se debilitaron o se perdieron en el resumen. Por ejemplo, si existe una regla que solo permite enviar correos electrónicos dentro de la empresa, se considera una violación llamar a una herramienta para enviar correos a destinatarios externos. En una evaluación con 17 casos, se encontró que en la mayoría de las violaciones tras la compresión, la regla en sí aún persistía. Sin embargo, también ocurrieron problemas en el lado de la acción, como tratar las solicitudes posteriores como permitidas. No basta con verificar que la regla esté escrita en el resumen; se debe comprobar también que no se realicen operaciones que la violen.

He creado Kiwa, un marco de prueba para dapps 🥝 Una herramienta que permite escribir desde el documento técnico hasta las pruebas de forma continua. Además de la documentación, carga el código existente, genera especificaciones de prueba y produce cuatro niveles de pruebas: contrato, E2E de dapp, unitarias y de integración API. https://t.co/FCNjrLbVSV

📚 Nueva arquitectura de mempool para prevenir operaciones de reordenamiento en bloques ✅ Resumen Esta propuesta consiste en encriptar el mempool de Ethereum (el lugar donde se almacenan las transacciones no confirmadas), ocultando su contenido hasta que se incluyan en un bloque. El objetivo es reducir significativamente prácticas como el reordenamiento de transacciones (leer transacciones de otros y manipular su orden) y el MEV (ganancia adicional obtenida por mineros o validadores), que buscan manipular precios. Aunque las transacciones se revelarán finalmente, el hecho de que su contenido permanezca oculto hasta el momento de su ejecución es un punto clave. ✅ ¿Por qué se necesita un mempool encriptado? En la actualidad, en Ethereum, cualquier transacción que entre en el mempool puede ser vista por cualquiera. Esto permite estrategias de MEV como el *front-running* (insertar transacciones antes que las de otros) o el *ataque de sándwich* (insertar transacciones antes y después para manipular el precio), lo que conduce a pérdidas para los usuarios y a una centralización de los bloques (concentración en pocos actores poderosos). Al encriptar las transacciones, aunque se conozca el orden, su contenido permanecerá oculto, dificultando que estas estrategias sean viables. ✅ ¿Cómo se encriptan las transacciones? Las transacciones se dividen en dos partes: un "envoltorio" y el "contenido encriptado". En el envoltorio se incluyen únicamente datos mínimos en texto plano, como la cantidad de gas, las tarifas y la clave necesaria para desencriptar. En el contenido encriptado se incluyen los datos reales, como la dirección de destino, el monto y los datos de llamada a contratos. Solo después de que la transacción entre en un bloque, y se publique la clave de desencriptación correspondiente, se ejecutará el contenido. ✅ ¿Qué es un "proveedor de claves"? Los proveedores de claves son los encargados de gestionar las claves necesarias para desencriptar las transacciones. La propuesta no fija un único método, sino que permite elegir entre varias opciones: - Criptografía de umbral (distribución de claves entre múltiples partes) - MPC (Cálculo Multilateral, donde se divide el secreto entre múltiples actores) - TEE (Entornos Ejecutivos Seguros, áreas de hardware seguro) - Criptografía con retraso temporal Ethereum solo proporcionará la infraestructura base que permita usar cualquier método de encriptación. ✅ Orden y seguridad dentro del bloque En un bloque, primero se ejecutan las transacciones en texto plano, seguido por el procesamiento de los envoltorios de las transacciones encriptadas, y finalmente se ejecutan los contenidos una vez desencriptados. Esto garantiza la siguiente estructura segura: - Las tarifas se pagan siempre antes. - El contenido no se ejecuta si no se publica la clave. Incluso si no se publica la clave, solo se detiene el procesamiento del contenido, no el de todo el bloque, por lo que la cadena no se detiene. ✅ Efectos sobre el MEV y la resistencia a la censura Cuando el contenido de las transacciones no es visible, los constructores de bloques no pueden calcular con anticipación qué transacciones afectarán a qué precios. Por lo tanto, resulta más difícil obtener beneficios mediante el reordenamiento, lo que debilita estructuralmente el MEV. Además, al ocultar el contenido, resulta más difícil censurar transacciones específicas dirigidas a ciertas direcciones o operaciones DeFi, mejorando así la "resistencia a la censura en tiempo real" (la capacidad de no ser bloqueadas inmediatamente).

📚 Mecanismo para demostrar la identidad y reputación de los agentes mediante NFT ✅ Visión general ERC8004 v1.0 es un conjunto de reglas comunes que permite a agentes de software autónomos colaborar de forma segura entre organizaciones. Utiliza Ethereum como "base de coordinación", registrando de forma inmutable la identidad, reputación y resultados de verificación de los agentes. Desde la versión v0.4, el diseño ha cambiado significativamente y ha evolucionado hacia un mecanismo basado en experiencias de uso real. ✅ Gestión de identidad de los agentes (Identity Registry) El mecanismo para demostrar "quién es quién" en los agentes ha migrado de un formato personalizado a ERC721 (un estándar de NFT). Cada agente se registra como un NFT individual, y en su tokenURI se almacena información de registro en formato JSON. Esta información incluye métodos de comunicación (direcciones de conexión a protocolos como A2A o MCP), claves públicas y modelos de confianza asociados. Gracias a esto, la identidad del agente puede gestionarse mediante una cartera, y cualquiera puede verificar "¿quién es el agente de esta dirección?" de forma compatible con la infraestructura de NFT. ✅ Sistema de reputación (Reputation Registry) Las valoraciones sobre el trabajo de los agentes se almacenan directamente en la cadena como puntuaciones. Antes de enviar una valoración, el cliente recibe datos de permiso firmados por el agente. Estos datos se verifican mediante EIP191 (método habitual de firma de carteras) o ERC1271 (método de firma para carteras inteligentes), lo que previene suplantaciones de identidad y ataques de repetición (replay attacks). Las puntuaciones y etiquetas (etiquetas de clasificación) se pueden acceder directamente desde contratos inteligentes, por lo que otras dApps pueden usar esta información para determinar automáticamente si un agente es confiable. ✅ Verificación de trabajos (Validation Registry) Es un mecanismo para que terceros verifiquen si los resultados emitidos por un agente son correctos. En la versión v1.0, en lugar de un solo hash, se presenta la evidencia mediante URI (referencia a datos externos), permitiendo registrar múltiples niveles de verificación para la misma solicitud. Por ejemplo, se puede construir una estructura escalonada de confianza, como una verificación rápida, una detallada y una auditoría externa. Actualmente, se está trabajando con la comunidad de entornos de ejecución seguros (TEE) para afinar los estándares. ✅ Seguridad y coste de gas Para hacer frente a los métodos de ataque descubiertos durante la operación en redes de prueba, se han reforzado la verificación de firmas y el diseño de almacenamiento. Como resultado, el costo de gas para escribir valoraciones y verificaciones aumenta, pero la ventaja es que los datos de confianza son directamente utilizables en la cadena. En redes L2, los costes se reducen considerablemente. ✅ Migración desde v0.4 La versión v1.0 no es compatible con versiones anteriores y ha cambiado completamente la estructura de almacenamiento. Por esta razón, toda la información de registro y reputación anterior se reinicia por completo, y los agentes deben registrarse nuevamente como NFT y el sistema de evaluación debe adaptarse al nuevo método de firma. En el futuro, se implementará un "método de actualización con espacios de nombres", que permitirá actualizar las especificaciones sin borrar los datos, por lo que este reinicio a gran escala será único.

📚 Mecanismo para distribuir el contenido de los bloques y prevenir el MEV ✅ Visión general En esta propuesta, se explica cómo el MEV, que es un problema en Ethereum, puede reducirse casi a cero mediante un enfoque que distribuya la decisión del "contenido" de los bloques. En lugar de enfocarse en la estructura del bloque en sí, se centra en la selección y ordenación de las transacciones, proponiendo añadir una nueva capa de consenso para estos procesos. ✅ La verdadera razón por la que ocurre el MEV El MEV surge porque los mineros o validadores pueden elegir libremente qué transacciones incluir en un bloque y en qué orden. Aunque la estructura de los bloques en Ethereum está acordada de forma descentralizada, el contenido de los bloques lo decide un solo proponente en un corto periodo de tiempo. Esta situación, en la que "una sola persona decide el contenido", es la causa fundamental de MEV, como las corridas front-running o ataques de sándwich. ✅ El consenso estructural y el consenso de contenido son problemas distintos Las cadenas de bloques han logrado descentralizar con éxito el consenso estructural, es decir, quién reconoce qué bloque como válido. Sin embargo, la decisión de qué transacciones incluir y en qué orden no está descentralizada. Esta propuesta explica que este problema tiene una estructura similar al antiguo problema de doble gasto. Al igual que se resolvió mediante un consenso cuando la autoridad estaba concentrada en una sola computadora, también se debería aplicar un consenso para decidir el contenido de los bloques. ✅ La idea de una capa de contenido Se propone añadir una "capa de contenido" (una capa de consenso para decidir el contenido de las transacciones) encima de la estructura del bloque. En esta capa, varios nodos colaboran y se distribuyen roles para decidir qué transacciones incluir y en qué orden. El objetivo es eliminar cualquier posibilidad de que un validador o secuenciador específico pueda reordenar las transacciones según su conveniencia. ✅ Mecanismo básico del protocolo Alex En el ejemplo del protocolo Alex, se distribuyen tres roles: recolectar transacciones, aleatorizar su orden y gestionar todo el proceso para reflejarlo en el bloque. Cada uno actúa de forma independiente, y si alguien intenta actuar de manera fraudulenta, otros participantes lo verificarán y complementarán. Gracias a esto, se vuelve extremadamente difícil censurar transacciones o reordenarlas de forma arbitraria. ✅ Relación con Ethereum existente Este mecanismo no rompe el consenso actual de Ethereum. Mantiene la estructura del bloque intacta y solo añade una capa superior para decidir el contenido. Se puede aplicar a los validadores de eth2, a los secuenciadores de rollup y a futuros secuenciadores descentralizados. Por lo tanto, se resalta que, una vez implementado, puede aplicarse ampliamente. ✅ Impacto en la equidad y en la formación de precios Este diseño no excluye actividades necesarias para el mercado, como el arbitraje simple. Por otro lado, se centra específicamente en el MEV que explota a los usuarios de forma imposible de evitar. Como resultado, busca un estado en el que la red proporcione equidad por sí misma, sin necesidad de que las aplicaciones implementen complejos mecanismos de defensa.

📚 Nuevo mecanismo para añadir anonimato a tokens existentes ✅ Resumen Este contenido propone un nuevo estándar ERC que permite añadir privacidad a los tokens ya existentes en Ethereum, sin cambiar su funcionalidad ni características. Se enfoca en tokens ampliamente utilizados como ERC20, ERC721 y ERC1155, proporcionando un mecanismo que dificulta el seguimiento de las transacciones. ✅ Qué problema resuelve Actualmente, los tokens de Ethereum muestran públicamente quién envía a quién desde qué dirección. Aunque esto ofrece transparencia, también permite que terceros rastreen fácilmente los saldos y movimientos de fondos. Este nuevo estándar ERC busca abordar precisamente esta debilidad sin necesidad de rehacer los tokens. ✅ Concepto del envoltorio de tokens con cero conocimiento El envoltorio de tokens con cero conocimiento funciona mediante un proceso en el que los tokens existentes se depositan y se reciben a cambio "tokens envueltos". Estos tokens envueltos pueden ser enviados y negociados de manera similar a los originales, pero internamente ocultan la propiedad mediante compromisos criptográficos que permiten demostrar su validez sin revelar información sensible. ✅ Interrupción del historial mediante quema y reemisión Una característica destacada es el flujo combinado de "quema" (hacer los tokens inutilizables) y "reemisión" (emitir nuevos tokens). Al presentar una prueba de conocimiento cero (una tecnología criptográfica que demuestra la validez sin revelar el contenido), se emiten nuevos tokens que no están vinculados a los tokens quemados anteriormente. Esto dificulta el seguimiento en la cadena. ✅ Caso de tokens fungibles como ERC20 En el caso de tokens fungibles como ERC20, este mecanismo permite interrumpir efectivamente el flujo de fondos. Quién posee qué saldo se vuelve difícil de determinar desde el exterior hasta que se realice un retiro. ✅ Aplicación en tokens NFT En el caso de NFT como ERC721, donde cada token es único, no es posible mezclarlos completamente. Sin embargo, sí es posible ocultar quién posee actualmente el NFT hasta que se realice una operación de retiro. ✅ Uso transparente para el usuario Este mecanismo está diseñado para que los usuarios puedan utilizarlo sin necesidad de ser conscientes de la existencia de los tokens envueltos. Gracias al procesamiento interno de billeteras y aplicaciones, se mantiene la misma experiencia de uso habitual, pero con el beneficio adicional de la privacidad. ✅ Compatibilidad con el ecosistema existente Al no emitir nuevos tokens dedicados, sino envolver los tokens existentes, se puede integrar directamente con el ecosistema actual de Ethereum, como DEX y DeFi. Esto permite añadir anonimato sin sacrificar la liquidez ni el alcance de uso de los tokens.

📚ERC7694 ¡He resumido la propuesta de "ERC7694", que presenta un mecanismo mediante el cual los contratos inteligentes de Ethereum pueden tratar a Solana como almacenamiento externo, permitiendo escrituras y lecturas de forma segura entre cadenas! https://t.co/hYzUup7dBO