La testnet de Aptos ha procesado más de 10.000 millones de transacciones, un hito que pone de relieve el rápido crecimiento de la actividad en la infraestructura de pruebas de la blockchain, al tiempo que plantea interrogantes sobre los requisitos de almacenamiento a largo plazo que implica mantener un historial de transacciones cada vez más grande. Aptos es en sí misma una blockchain de capa 1 con prueba de participación desarrollada por Aptos Labs —un equipo fundado por exingenieros de Meta que habían trabajado en el proyecto blockchain Diem de la compañía— y ejecuta contratos inteligentes escritos en el lenguaje de programación Move.

El cofundador de Aptos, Avery Ching, llamó la atención sobre la cifra al hablar del crecimiento del almacenamiento de la testnet y de una propuesta en fase de borrador conocida como AIP-147, una de las Aptos Improvement Proposals (AIP) mediante las cuales se sugieren y revisan formalmente los cambios en el ecosistema. La propuesta está diseñada para crear un proceso más predecible de gestión de la creciente huella de datos de la testnet sin realizar ningún cambio en la mainnet de Aptos.

Según AIP-147, la testnet de Aptos se reiniciaría como máximo una vez cada seis meses, y los usuarios y desarrolladores recibirían un mes de aviso previo antes de que se produzca un reinicio.

El enfoque propuesto se dirige específicamente al entorno de pruebas, donde la actividad transaccional puede acumularse rápidamente a medida que los desarrolladores prueban aplicaciones, contratos inteligentes y funcionalidades de la red. A diferencia de la mainnet, la testnet está destinada principalmente al desarrollo y la experimentación, lo que convierte los reinicios periódicos en una posible forma de controlar las demandas de almacenamiento sin dejar de preservar un entorno eficaz para las pruebas. Estos reinicios no son exclusivos de Aptos; otros grandes ecosistemas han retirado o reemplazado periódicamente redes de prueba, como hizo Ethereum al descontinuar la testnet Goerli, de larga trayectoria, e introducir Holesky como sucesora.

El crecimiento del almacenamiento se convierte en un desafío clave para la testnet

El hito de los 10.000 millones de transacciones subraya la escala que ha alcanzado la actividad en la testnet de Aptos. A medida que los registros de transacciones siguen acumulándose, la cantidad de almacenamiento necesaria para mantener la testnet puede aumentar considerablemente, lo que genera desafíos operativos y de infraestructura para los participantes que operan nodos y otros componentes de la red de pruebas.

AIP-147 tiene como objetivo abordar este problema mediante la introducción de un calendario de reinicios definido, en lugar de permitir que los datos de la testnet crezcan indefinidamente. Un reinicio se produciría con una frecuencia no mayor a una vez cada seis meses. El intervalo mínimo de seis meses está pensado para ofrecer a los desarrolladores un período de pruebas suficientemente estable y proporcionar a los operadores de la red un mecanismo para gestionar el crecimiento del almacenamiento.

La propuesta también incluye un período de aviso de un mes. Un aviso previo de este tipo podría permitir que los desarrolladores y los proveedores de infraestructura se preparen para la eliminación de los datos históricos de la testnet y ajusten sus procesos de pruebas en consecuencia.

La mainnet permanece sin cambios

Un aspecto clave de esta novedad es que el mecanismo de reinicio propuesto no se aplicaría a la mainnet de Aptos. La distinción es importante porque las transacciones de la mainnet representan actividad real de la red y tienen requisitos sustancialmente diferentes en materia de retención de datos, fiabilidad y continuidad.

Full AIP introduced by @AptosLabs' @sherryxiao:

— Aptos (@Aptos) August 22, 2026

La propuesta deja intacta la mainnet de Aptos: los reinicios sugeridos se limitan a la testnet y tienen como objetivo gestionar la infraestructura de desarrollo en lugar de alterar la blockchain en producción.

Para los desarrolladores, un calendario de reinicios predecible podría facilitar la planificación en la testnet. Los equipos tendrían expectativas más claras sobre cuánto tiempo pueden permanecer disponibles los datos de prueba y cuándo podrían necesitar recrear sus entornos de pruebas. El período de aviso también podría reducir las interrupciones al dar a los proyectos tiempo para respaldar la información relevante o ajustar sus flujos de trabajo de desarrollo.

La política propuesta también podría beneficiar a los operadores de nodos al imponer un límite recurrente a la acumulación de datos de la testnet. Unos requisitos de datos más reducidos podrían facilitar el mantenimiento de la infraestructura de pruebas, aunque el impacto operativo preciso dependería de cómo se implemente la propuesta.

La propuesta refleja el creciente nivel de actividad en la red

El hito también ilustra el nivel de actividad generado en la infraestructura de pruebas de Aptos. Procesar más de 10.000 millones de transacciones indica un uso sustancial del entorno con fines de prueba y desarrollo, al tiempo que pone de manifiesto los costos de infraestructura asociados al mantenimiento de un registro histórico en constante crecimiento.

Si se aprueba, AIP-147 establecería un mecanismo estructurado para depurar periódicamente los datos de la testnet, manteniendo al mismo tiempo una comunicación anticipada con los desarrolladores y los proveedores de infraestructura.

Dado que AIP-147 aún es un borrador, los acontecimientos inmediatos a seguir son su avance en el proceso de revisión de Aptos y, en caso de que se apruebe, la forma en que se comunique a los usuarios, desarrolladores y operadores de nodos la primera ventana de reinicio y el aviso previo de un mes que la acompañaría.

La propuesta sigue centrada en las operaciones de la testnet, y su importancia se relaciona principalmente con la escalabilidad y la gestión de recursos, más que con cambios en la red en producción de Aptos. A medida que la testnet continúe respaldando la actividad de desarrollo, una política de reinicios definida podría ofrecer un equilibrio entre mantener un entorno de pruebas útil y controlar la carga de infraestructura creada por los datos de transacciones acumulados.