Cover Image

XRP Ledger (XRPL) è pronto a ricevere un aggiornamento mirato a risolvere un problema di rete. Il problema principale che ha richiesto questo aggiornamento ha riguardato i nodi full history (FH) che fallivano a causa di una restrizione di SQLite nel dimensionamento della pagina.

Vet, un validatore dUNL XRP, ha condiviso questo sviluppo in un post X. Secondo Vet, la correzione per il problema dei server XRP Ledger Full History è stata unita in una versione ufficiale rippled del repository XRPLF, rippled 2.2.3, che è ora disponibile per l'installazione.

La correzione per i server#XRPLedger Full History è stata unita in una versione ufficiale rippled del repository XRPLF - rippled 2.2.3 e disponibile per l'installazione. pic.twitter.com/Owpd6xPEHx

— Veterinario 🏴‍☠️ (@Vet_X0) 15 settembre 2024

Secondo uno screenshot condiviso da Vet, la versione 2.2.3 di Rippled (XRP ledger server) è fortemente consigliata per i server di cronologia completa che utilizzano una dimensione di pagina di 4096. Poiché i validatori non sono interessati da questo problema, possono scegliere di eseguire 2.2.2 o aggiornare a 2.2.3. Questo perché la versione 2.2.3 non introduce nuove modifiche alla versione 2.2.2.

Quello che è successo?

Nel fine settimana, la comunità XRP ha attirato l'attenzione su un problema sul server rippled che causava il malfunzionamento dei nodi Full History (FH).

In circostanze normali, i server full history registrano e servono felicemente la cronologia completa delle transazioni. Tuttavia, i nodi FH hanno fallito a causa di una restrizione di SQLite nel dimensionamento delle pagine.

Questo problema, secondo alcuni validatori dUNL dell'XRPL, era stato evidenziato settimane fa, ma non era stato immediatamente preso in considerazione.

Il fondatore di XRP Cafe, xrpl Adam, ha chiarito in un post su X che, contrariamente a quanto si crede, questo problema non ha alcun impatto sul consenso o sulla salute della rete.

carta

Inoltre, grazie alla ridondanza di clio, la maggior parte degli endpoint XRPL pubblici non necessita di un server FH effettivo per restituire i risultati storici delle transazioni.

Secondo Xrpl Adam, il problema non era nuovo su XRP Ledger, essendo stato documentato anni fa. Fu notato allora che alcuni server rippled con cronologia completa del ledger potrebbero avere un problema con la dimensione della pagina del database SQLite, impedendo al server di funzionare correttamente.

Tuttavia, il fondatore di XRP Cafe ritiene che l'urgenza della correzione avrebbe dovuto essere promossa prima per evitare il crollo dei nodi FH, come accaduto nel fine settimana.