L'XRP Ledger (XRPL) si avvicina all'attivazione di un upgrade che consentirebbe alle organizzazioni di dividere il controllo di un singolo account tra più account delegati, limitando il potere di ogni singola chiave operativa.

PermissionDelegationV1_1 è progettato per le organizzazioni che elaborano transazioni frequentemente ma non vogliono chiavi in grado di controllare un intero account all'interno dei sistemi operativi quotidiani. Un emittente di stablecoin, ad esempio, potrebbe avere bisogno di un sistema per approvare le trust line dei clienti (il meccanismo del ledger per detenere asset emessi), un altro per elaborare i pagamenti e una configurazione più protetta per gestire la sicurezza dell'account. L'emendamento consentirebbe di dividere tali compiti tra account XRPL separati.

Il suo elemento in stile "bancario" è la separazione delle responsabilità. Non indica un'approvazione normativa né un'adozione confermata da parte di una banca. Un delegato compromesso potrebbe comunque essere abusato nell'ambito del proprio ruolo, ma l'attaccante non riceverebbe automaticamente tutti i poteri detenuti dall'account principale, riducendo il potenziale danno di una singola chiave operativa esposta.

XRPL applicherebbe ogni permesso onchain

Secondo la specifica XLS-75, l'account che assegna l'autorità è il delegante. Invia una transazione DelegateSet indicando un secondo account e le azioni che tale account può eseguire. La relazione è memorizzata in una voce Delegate del ledger.

Il delegato firma con le proprie chiavi, identifica l'account per cui agisce e paga la fee di transazione. XRPL respinge le richieste al di fuori dell'autorità registrata, e il delegante può in seguito aggiornare o revocare tale autorità.

La documentazione ufficiale elenca permessi per tipo di transazione e permessi granular più restrittivi, e ciascun delegato può riceverne al massimo dieci. I controlli granulari disponibili sono predefiniti, quindi le organizzazioni non possono creare qualsiasi restrizione desiderino. I delegati devono inoltre mantenere account con fondi, mentre ogni delega crea un oggetto onchain che aumenta il requisito di owner reserve del delegante, ovvero la quantità minima di XRP che un account deve detenere per ogni oggetto del ledger che possiede.

I poteri sensibili, tra cui la modifica delle chiavi di firma o la nomina di nuovi delegati, non possono essere delegati. Le transazioni che non possono entrare immediatamente nel ledger aperto falliscono invece di entrare nella coda.

Ventinovoti hanno avviato un conto alla rovescia condizionato

PermissionDelegationV1_1 è entrato nel suo periodo di attivazione di 14 giorni il 21 settembre con il sostegno di 29 dei 35 validatori trusted dell'XRP Ledger, secondo il tracker degli emendamenti in tempo reale. Gli emendamenti sono il meccanismo integrato del ledger per modificarne le regole, e un sostegno prolungato dei validatori è ciò che porta il nuovo codice di protocollo sulla mainnet. Almeno 28 validatori devono continuare a sostenerlo, e scendere al di sotto di tale livello azzererebbe il conto alla rovescia. CoinDesk ha riportato un'attivazione prevista per il 5 ottobre alle 11:18 UTC, a condizione che il sostegno resti ininterrotto.

Il codice esiste già nel software server di XRPL, ma non può essere utilizzato sulla mainnet prima dell'attivazione. Il separato emendamento Batch V1.1 segue lo stesso processo di due settimane, sebbene riguardi transazioni collegate piuttosto che l'autorità sugli account.

La delega non sostituisce la multisignature

La multisignature determina quante parti approvate debbano autorizzare un'azione, mentre la delega di permessi limita quali azioni un account operativo può richiedere. Un'organizzazione potrebbe combinarle limitando un delegato ai pagamenti mentre richiede a più persone di approvare ciascun pagamento.

Dopo un compromissione di chiave, la multisignature può impedire a un firmatario rubato di raggiungere la soglia di approvazione, mentre la delega può limitare i tipi di transazione disponibili per l'attaccante anche dopo che l'account delegato è stato compromesso. Nessuno dei due controlli verifica che l'istruzione aziendale sia legittima.

La versione originale fallì prima di raggiungere la mainnet

Un tester della community ha scoperto che la prima implementazione di PermissionDelegation poteva, in determinate condizioni, addebitare una fee di transazione a un altro account anche quando la transazione delegata non era firmata correttamente. Invii ripetuti con fee elevate avrebbero potuto ridurre il saldo XRP della vittima senza rivelarne la chiave privata.

Il difetto fu scoperto durante i test, e l'emendamento non si attivò mai sulla mainnet. La divulgazione ufficiale della vulnerabilità ha riportato nessuna perdita di fondi di utenti reali.

Coindoo aveva precedentemente esaminato perché Permission Delegation è tornato in forma rivista con gli emendamenti di xrpld 3.3.0. Il nuovo voto mostra che i validatori sono ora disposti a prendere in considerazione l'attivazione della versione sostitutiva.

L'attivazione non stabilirà l'adozione istituzionale

Wallet e fornitori di custodia dovranno comunque creare interfacce per la creazione, la revisione e la revoca dell'autorità delegata. Nessun deployment bancario identificato è stato annunciato, e le istituzioni restano responsabili della decisione su quali account ricevano ciascun permesso.

Le decisioni di compliance resterebbero inoltre al di fuori del ledger. Un'azienda continuerebbe a eseguire verifiche dell'identità, screening delle sanzioni e valutazioni del rischio attraverso i propri sistemi. XRPL applicherebbe quale delegato possa inviare l'autorizzazione risultante; non determinerebbe se il cliente dovesse essere approvato.

L'uso della funzionalità sarebbe visibile tramite le voci Delegate pubbliche, sebbene collegare un indirizzo a un'azienda possa richiedere una divulgazione volontaria. Gli account delegati necessitano inoltre di XRP per riserve e fee, ma l'attivazione non stabilisce alcun volume di utilizzo né una domanda automatica per il token.

L'uso in produzione diventa la prossima prova

Se il sostegno dei validatori regge, le evidenze arriveranno dalle integrazioni dei wallet, dalle nuove voci Delegate e dai deployment identificati. Questi segnali mostreranno se le organizzazioni necessitano di una separazione a livello di protocollo tra proprietà dell'account e operazioni quotidiane.

Il voto rende possibile l'accesso limitato agli account. Il suo valore dipenderà da quanto strettamente le organizzazioni configureranno tali permessi e se utilizzeranno la funzionalità al di fuori delle dimostrazioni.

Questo articolo è fornito solo a scopo informativo e non costituisce consulenza finanziaria, legale o di sicurezza. Il sostegno dei validatori e i tempi di attivazione possono cambiare.