aelf

Cuando el plan de aelf se presentó a inversores el 10 de diciembre de 2017, la salida propuesta a la congestión compartida era estructural. La red de pruebas pública llegó en 2018 y MainChain en 2020. Las aplicaciones podían funcionar en cadenas propias y enviar información de bloques para su indexación, de modo que un producto concurrido no ocupara la misma cola de ejecución que todos los demás.

ELF asumió dos funciones conectadas. Pagaba transacciones ordinarias e indexación de cadenas de aplicaciones y servía para elegir productores y nodos candidatos. Los tenedores elegían a los operadores, pero el procedimiento parlamentario documentado daba a esos operadores la vía de propuesta: los productores presentaban iniciativas y productores y candidatos las votaban.

La primera reducción programada llegó el 12 de diciembre de 2024 y bajó la recompensa de MainChain de 0,125 a 0,0625 ELF por bloque. Cambió la nueva emisión dentro del máximo publicado de mil millones de ELF.

La gran cifra del mes siguiente contaba otra historia. El 18 de enero de 2025, aelf informó de la quema de 295.519.800 ELF ERC-20 depositados durante el canje a Mainnet. Esos tokens de Ethereum representaban activos que ya habían avanzado hacia la red nativa: la quema limpió una representación antigua, no eliminó 295.519.800 ELF nativos de usuarios.

El 18 de agosto de 2026, la vigilancia interna detectó un contrato anómalo no autorizado que parecía intentar desbordamiento y elevación de privilegios. aelf indicó a todos los productores que detuvieran la red, comenzó una corrección e incorporó una auditoría externa. La parada cubrió AELF MainChain y la cadena de aplicación tDVV, convirtiendo la elección de productores en una respuesta operativa de emergencia.

El primer aviso no zanjó la causa. El informe del 26 de agosto describió una ruta más concreta: parámetros de transacciones podían introducir ensamblados .NET codificados e instrucciones en la ruta de ejecución de contratos del nodo. Asoció 155 transacciones a la actividad —127 en AELF y 28 en tDVV— y redujo el conjunto a cinco cargas únicas.

Las cinco cargas podían ejecutar órdenes en el sistema anfitrión, recoger resultados, intentar comunicaciones salientes, acceder a claves y configuraciones relacionadas con nodos y reconocer infraestructura. aelf no afirmó que todas se ejecutaran en cada nodo, que se obtuvieran todas las credenciales objetivo ni que salieran datos sensibles. Esas preguntas siguieron abiertas en los análisis del sistema, la nube, la identidad y la red.

En la actividad en cadena y las pruebas sobre claves revisadas al 26 de agosto, aelf no encontró evidencia de transferencias no autorizadas ni exposición de claves de usuarios comunes. Al mismo tiempo, trató las claves de firma de nodos y las credenciales de infraestructura como potencialmente expuestas y continuó rotándolas o revocándolas. El resultado limitado sobre usuarios no puede ampliarse a una afirmación de que todo activo o credencial estuvo a salvo.

Los puntos públicos de consulta podían responder aunque la producción siguiera cerrada. El informe mantenía desactivado el envío público de transacciones y enumeraba pasos pendientes: reconstrucción limpia de nodos, rotación de claves, repetición determinista, aislamiento permanente del entorno de ejecución y revisión independiente. El índice oficial examinado hasta el 5 de septiembre no mostraba un cierre posterior. La consecuencia fue concreta: las cargas de las aplicaciones estaban separadas, pero el límite de software y la respuesta de los operadores que debían restaurarlas seguían siendo comunes.