El XRP Ledger finalmente ha implementado la enmienda fixDirectoryLimit, eliminando un "límite máximo" obsoleto sobre cuántos elementos pueden almacenarse en una lista específica en el ledger.
Hasta hoy, si una sola lista se hacía demasiado larga, la red bloqueaba la adición de nuevos elementos. Esto ocurría incluso si el usuario tenía suficiente XRP para pagarlos.
Ahora, ese límite arbitrario ha desaparecido y la red depende de las Reservas (el XRP que bloqueas para crear un objeto) para prevenir el spam en su lugar.
Por qué esto es importante
Piense en un directorio como una carpeta específica en un archivador. XRPL utiliza directorios para agrupar cosas similares. El ejemplo más común es el libro de órdenes.
Si 500 personas quieren comprar XRP exactamente a $2.50, el ledger agrupa esas 500 ofertas en un solo "directorio" para ese precio.
Anteriormente, el código tenía un límite estricto sobre cuántas "páginas" podía tener esta carpeta.
Si un precio específico ($2.50) se volvía increíblemente popular y miles de ofertas llegaban, el directorio podría "llenarse" esencialmente.
Los usuarios recibían un código de error como tecDIR_FULL. Esto significaba que transacciones válidas fallaban simplemente porque esa "carpeta" específica estaba técnicamente llena.
La enmienda elimina este límite. La red no necesita un límite codificado para detener el spam porque ya existen las "Reservas de Propietario". Debes bloquear XRP para crear una oferta u objeto. Ese coste económico es suficiente para evitar que la gente envíe objetos infinitos como spam.
Los validadores ya no tienen que desperdiciar recursos comprobando si una página de directorio está "llena".
Mientras tanto, los traders y las aplicaciones no se encontrarán con errores inesperados tecDIR_FULL durante momentos de alto tráfico.
Un año ocupado
Este ha sido un año ocupado para XRPL. Esta fue la primera enmienda importante del año. Añadió una función de "clawback" específicamente para los pools de Automated Market Maker (AMM). La red introdujo capacidades de DynamicNFT, permitiendo que los tokens no fungibles actualicen sus metadatos con el tiempo sin necesidad de ser destruidos y reemitidos.
