Ethereum
Un contrato que sigue ejecutándose tras una llamada fallida no tiene hoy una forma confiable de determinar si el llamado se revirtió intencionadamente o simplemente se quedó sin gas, según lo eligió el remitente. Esta brecha es la raíz del griefing por gas insuficiente, y una nueva propuesta en borrador intenta cerrarla a nivel EVM. EIP-8456, abierta a discusión en Ethereum Magicians el lunes, añade una instrucción llamada CALLSTATUS, provisionalmente en el opcode 0xA5 con un costo de 2 gas. Esta instrucción empuja el estado de finalización de la llamada o creación más reciente en el marco actual como tres bits. El bit 0 indica una reversión, el bit 1 indica una parada excepcional, como falta de gas, y el bit 2 indica que algo en un marco inferior se detuvo. El autor señala que la única evidencia disponible hoy es el cálculo de gasleft() tras la llamada, y que cada bifurcación de repricing ha roto esos umbrales. El propuesto gas bidimensional de EIP-8037 haría aún más débil ese cálculo, ya que su reservorio no es visible a través del opcode GAS. Entonces, ¿por qué el tercer bit? La mayoría de las llamadas reales pasan por intermediarios como proxies, el wrapper functionCall de OpenZeppelin, Multicall3 o verificadores de firma ERC-1271. Si solo se informara el estado final del llamado directo, un wrapper que capture una parada por falta de gas y revierta con un motivo parecería una reversión intencionada. El borrador mantiene una bandera persistente que viaja hacia arriba en cada marco, por lo que un remitente que solo controle el gas nunca podrá hacer que un llamador lea una reversión simple. Se informan resultados en lugar de causas, y un llamado aún puede producir una parada intencionada con INVALID. Solo protege código escrito después de su implementación, ya que los contratos desplegados no lo leerán. Aún no hay revisiones externas, el número del opcode sigue abierto, y un prototipo junto con pruebas para los 58 casos listados aún está pendiente. Enlace - https://t.co/KnByUBgWrY
La mayoría de los monederos de ethereum aún muestran todo tu historial financiero a cualquiera que tenga tu dirección, y la Fundación ethereum ahora lo considera un agujero de seguridad, no solo una característica de privacidad deseable. El lunes, la Fundación publicó que los ataques y explotaciones de la semana pasada les hicieron entender con mayor claridad que la privacidad y la seguridad no pueden tratarse como objetivos separados. Su planteamiento es que puedes preocuparte menos si un atacante usa tu historial onchain en tu contra cuando la privacidad es el valor predeterminado. La publicación citó una actualización sobre Kohaku, el proyecto de herramientas de privacidad de la Fundación. El repositorio de JavaScript lo divide en paquetes que un equipo de monedero puede adoptar uno por uno. Hay bibliotecas para Privacy Pools y Tornado Cash, además de una biblioteca Railgun que el README actualmente marca como en mantenimiento. Un paquete de plugins define una interfaz estándar para protocolos de pools blindados, para que un monedero pueda comunicarse con todos ellos de la misma manera. Un paquete provider abstracta sobre ethers, viem, Helios y Colibri. El repositorio también incluye una cuenta ERC-4337 post-cuántica. Los crates de Rust se encuentran en un repositorio hermano separado. Me gusta que esto se presente como un SDK en lugar de otro monedero de privacidad que pide a los usuarios que transfieran fondos. La idea es que los monederos existentes agreguen flujos blindados sin que cada equipo tenga que reimplementar tres protocolos. El README es directo sobre el estado actual de las cosas. Algunas partes están marcadas como no listas para producción, y los paquetes contienen código no auditado. Jordan Enev de Ambire dijo el viernes pasado que el equipo ha pasado meses probando las integraciones, y aún no se ha dado ninguna fecha de lanzamiento pública. Vitalik y Nicolas Consigny tienen programado demostrar Kohaku con Ambire en el mainnet de ethereum el próximo martes en @EFDevcon, según la lista de sesiones. Aquí está el repositorio - https://t.co/egNbLgAo0J
Tu terminal ahora puede responder-te, y lo curioso es que lo hace sin llamar a ninguna API en la nube. El sábado, Ollama lanzó la versión 0.40.11 con síntesis de voz en macOS. El primer modelo de voz es Phonon, una familia de modelos pequeños de TTS de Gradium. Lo descargas con ollama pull phonon y lo ejecutas como cualquier otro modelo. Lo que realmente interesa a los desarrolladores es la API. Phonon funciona con el endpoint /v1/audio/speech compatible con OpenAI en localhost. Si tu código ya usa el SDK de OpenAI para voz, la documentación dice que solo necesitas una nueva URL base. La respuesta se transmite mientras se genera el audio, por lo que la reproducción puede comenzar antes de que se termine todo el texto. Incluso puedes redirigir la respuesta de un modelo de chat directamente a Phonon, y comenzará a hablar tras la primera oración. La salida es mono de 24 kHz, por defecto en formato WAV o PCM crudo de 16 bits si lo solicitas. La documentación enumera algunos límites que son fáciles de superar. Cada solicitud admite hasta 4.096 caracteres, aunque ollama run divide automáticamente el texto más largo. Los precios, símbolos, correos electrónicos y URLs se pronuncian letra por letra, mientras que las fechas numéricas se leen tal como están escritas; por ello, la documentación sugiere escribir las fechas en palabras. Las opciones no compatibles, como la velocidad o instrucciones, devuelven un error 400 en lugar de ignorarse silenciosamente. La licencia merece una lectura cuidadosa antes de lanzar cualquier cosa. El modelo predeterminado en inglés de Phonon es Apache 2.0. Las variantes en francés, alemán, español, portugués y multilingüe de 40M están bajo CC BY-NC 4.0, lo que excluye su uso comercial. Ollama también indica que en un MacBook Pro con M5 Max funcionó un 35 % más rápido que el entorno de ejecución propio de Gradium, aunque esto es su propio benchmark y no uno independiente. La síntesis de voz es solo para Apple Silicon por ahora, con soporte para Windows y Linux listado como próximo.
Un L2 de Ethereum que acepta firmas cero suena como un error de seguridad, pero BB84 lo hace intencionalmente para evitar ataques cuánticos. El fin de semana pasado, su fundador, que publica como Hadamard, publicó el diseño en Ethereum Research y pidió comentarios críticos. BB84 es un rollup de OP Stack en mainnet, activo desde el 30 de septiembre, donde las transacciones L2 no llevan ningún ECDSA en absoluto. Cada cuenta es el extremo de una cadena de hashes keccak-256 construida a partir de un secreto, con 1.000 pasos por defecto. Para gastar, tu monedero revela el valor anterior en la cadena, que cualquiera puede verificar con un solo hash. Dentro del L2, la única suposición restante es la resistencia a la preimagen de keccak-256, que el algoritmo de Grover reduce a aproximadamente 2^128 de trabajo. Revelar un secreto lo vuelve público, por lo que el protocolo añade un paso de commit y revelación para vincular cada preimagen a una sola transacción primero. Dos nuevos tipos de transacción en op-geth manejan esto, y la verificación del remitente reemplaza a ecrecover. La autorización se consume incluso cuando la llamada se revierte, y si una billetera omite el paso de renovación en el último eslabón, esa dirección queda muerta. El post incluye una falla de front-running que el equipo encontró mientras lo escribía. Los commits no llevan firma, por lo que un nuevo commit solía reemplazar uno pendiente, y un atacante podría volver a vincular un secreto revelado a su propio pago. Una regla que entró en vigor el 21 de octubre hace que el primer commit gane. Los límites se explican claramente. Los depósitos y retiros L1 aún usan ECDSA. Aún no hay pruebas de fallas, y según el propio post, la cadena ni siquiera alcanzaría el Estadio 0 de L2BEAT. El secuenciador es operado por el equipo, y las direcciones de 160 bits dejan aproximadamente 2^80 de resistencia cuántica a preimágenes secundarias. El post también pregunta si las cuentas en cadena de hashes podrían convertirse en un EIP-7702 o un modo nativo de validación de abstracción de cuenta en L2 generales.
OpenZeppelin hizo de Chainlink el estándar para cross-chain y cumplimiento en sus herramientas de tokens, y si marcas la casilla de cumplimiento, la licencia de tu token cambia. Hace una semana, OpenZeppelin anunció una asociación estratégica con Chainlink. CCIP y ACE, el protocolo cross-chain de Chainlink y su Motor de Cumplimiento Automatizado, ahora están integrados en el Contracts Wizard, la herramienta de IA de OpenZeppelin y su documentación. Los generadores de ERC20, Stablecoin y RWA ofrecen ambas opciones. Seleccionar la opción CCIP expone las llamadas de mint y burn que necesita la piscina de burn-and-mint de Chainlink, detrás de los permisos propios del token. También nombra un administrador para el registro de CCIP. Esta parte mantiene la licencia que elegiste, ya que ningún código de Chainlink se incluye. La opción ACE es diferente. Redirige transferencias, mints y burns a un Policy Engine que tú despliegas y configuras. La propia documentación de OpenZeppelin indica que los tokens que usan ACE caen bajo BUSL-1.1, y su uso en producción debe satisfacer la licencia ACE y sus permisos de uso adicionales. Durante años, un token generado por OpenZeppelin llevaba la licencia que elegiste, generalmente MIT. Ahora, una sola casilla de verificación cambia eso, y un desarrollador junior con prisa podría no darse cuenta. El generador no registra tu piscina, no configura permisos ni escribe tus políticas. Conectar un Policy Engine no configura ninguna política, y tú sigues siendo responsable de cumplir con las reglas que te apliquen. El anuncio también menciona una ruta de migración desde OpenZeppelin Defender hacia el Runtime Environment de Chainlink. Nada de esto está oculto, y para un equipo RWA que ya desea Chainlink, esto ahorra trabajo real de integración. Solo quiero que los desarrolladores lo elijan con propósito, no porque el asistente lo colocó allí.
Smart contract maxis, Su compilador de Solidity podría haber eliminado silenciosamente un almacenamiento que necesitaba, y nunca lo habría visto en su código fuente. Solidity 0.8.38 se lanzó el jueves pasado. Corrige un error en el optimizador Yul que estuvo presente en todas las versiones desde la 0.8.19 hasta la 0.8.37. El optimizador lleva un registro de lo que hay en memoria y en almacenamiento. Utiliza esos registros para reemplazar una carga con un valor que ya conoce, y para omitir un almacenamiento que escribe lo que ya está allí. Para determinar si dos direcciones pueden superponerse, describe cada una como una variable base más un desplazamiento. Misma base, desplazamiento diferente, por lo tanto deben ser diferentes ranuras. Esas descripciones se almacenaban en caché. Luego, alguien vuelve a asignar la variable base. El optimizador no siempre lo nota. Ahora compara una dirección construida con el valor antiguo con otra construida con el valor nuevo, como si compartieran la misma base. Decide que son diferentes, pero en tiempo de ejecución apuntan al mismo lugar. El resultado es un registro obsoleto. Una carga posterior puede devolver un valor antiguo. Un almacenamiento que necesitaba puede eliminarse. Un keccak256 sobre esa ubicación puede hashear datos desactualizados. Solo el código compilado con el optimizador activado está expuesto. Con via-IR, cualquier código puede afectarlo, incluso sin ensamblaje en línea. Con la canalización heredada predeterminada, solo algunos ensamblajes en línea y funciones auxiliares generadas por el compilador. Las compilaciones sin optimizar son seguras. El equipo lo clasifica como baja gravedad, y hicieron algo que desearía que todos los equipos de compiladores hicieran: Volvieron a compilar todos los contratos verificados en la base de datos de Sourcify con y sin la corrección, y el bytecode fue idéntico en todos ellos. Por lo tanto, es raro. Raro no es lo mismo que nunca, especialmente si su código es reciente y aún no se ha desplegado. El error se descubrió a través del programa de recompensas por errores de la Ethereum Foundation, y un segundo informe mostró que Solidity simple sin ensamblaje también puede activarlo.
El impulso masculino de ser máximista de ETH. 🥳
Ethereum es Ethereum y siempre lo será. En la próxima bifurcación, la comunidad de Ethereum verá la verdadera magia del protocolo.