Il post XRPL corregge una falla critica pre-mainnet, ma le app client restano a rischio è apparso su BitcoinEthereumNews.com.
I validatori di XRP Ledger (XRPL) hanno posto BatchV1_1 su un percorso condizionale per l'attivazione alle 14:06:41 UTC del 29 settembre, trasformando un quasi-incidente di sicurezza in un test dal vivo del processo di emendamento della rete e del suo software circostante. Il 22 settembre, xrpldashboard ha mostrato 30 dei 35 validatori fidati a supporto dell'emendamento, al di sopra della soglia visualizzata di 28 voti. La maggioranza è apparsa per la prima volta on-ledger il 15 settembre. Secondo le regole di emendamento di XRPL, il supporto deve rimanere sopra l'80% per due settimane. Una caduta all'80% o meno termina il periodo di maggioranza, quindi la data di attivazione rimane condizionale. Il 29 settembre è il primo test in produzione per verificare se il processo dei validatori di XRPL, l'implementazione di riferimento e l'ecosistema client hanno convertito una pericolosa falla pre-mainnet in un'infrastruttura utilizzabile per transazioni atomiche. Il firewall dei validatori ha funzionato prima della mainnet L'emendamento Batch originale non è mai stato attivato sulla mainnet di XRP Ledger. A febbraio, i ricercatori hanno scoperto una falla critica di autorizzazione mentre l'emendamento era ancora nella sua fase di voto, e ai validatori è stato consigliato di votarlo contro. La divulgazione ufficiale della vulnerabilità di XRPL Labs afferma che nessun fondo era a rischio. La falla risiedeva nel ciclo che verificava i conti che autorizzavano un batch. Se il codice incontrava un firmatario per un conto appena creato la cui chiave corrispondeva a quel conto, restituiva immediatamente successo invece di continuare attraverso i firmatari rimanenti. Un attaccante poteva collocare quel firmatario valido per primo, poi aggiungere una voce falsificata che pretendeva di autorizzare un conto vittima. Se l'emendamento fosse andato live, la transazione della vittima non verificata avrebbe potuto essere eseguita senza le chiavi della vittima. La risposta di XRPL è arrivata in due fasi. La versione 3.1.1 ha contrassegnato gli emendamenti originali Batch e fixBatchInnerSigs come non supportati, bloccandone l'attivazione. BatchV1_1 li ha poi sostituiti con un percorso di autorizzazione riscritto e difese aggiuntive. L'episodio è stato un fallimento colto al confine tra rilascio del software e attivazione del protocollo. La specifica finale XLS-56 della XRPL Foundation ora…