El XRP Ledger finalmente implementó 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 sucedía incluso si el usuario tenía suficiente XRP para pagarlos.
Ahora, ese límite arbitrario desapareció y la red depende de las Reservas (el XRP que bloqueás para crear un objeto) para prevenir el spam en su lugar.
Por qué esto es importante
Pensá 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 fijo 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 podí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 "Owner Reserves". Tenés que bloquear XRP para crear una oferta u objeto. Ese costo económico es suficiente para evitar que la gente haga spam con objetos infinitos.
Los validadores ya no tienen que desperdiciar recursos verificando 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 mucho tráfico.
Un año movido
Este ha sido un año movido para XRPL. Esta fue la primera gran enmienda del año. Se agregó 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.
