Analisi: proposta BNB Chain divide i poteri sugli asset tra quattro ruoli

Il progetto CAS20 proposto da BNB Chain divide i poteri sugli asset tra quattro ruoli, affidando però a un amministratore nominato tramite governance il controllo su quando possano essere creati nuovi stablecoin e asset tokenizzati. La release v1.8.1 del 16 ottobre programma Jenner per la testnet Chapel di BNB Smart Chain il 29 ottobre alle 02:30 UTC. Un annuncio precedente indica come periodo per il lancio sulla rete principale la fine di novembre, senza che l'orario esatto sia ancora stato annunciato. Lo standard BEP-702 proposto è ancora contrassegnato come «Draft» e riguarda i token CAS20, mentre i token BEP-20 esistenti non sarebbero interessati. CAS20 implementerebbe il comportamento comune dei token nella logica nativa della blockchain tramite precompile con stato.

In base alla BEP-702, la governance della blockchain nomina l'amministratore dell'attivazione tramite GovHub, il contratto di inoltro della governance di BSC. L'implementazione dell'attivazione consente solo a GovHub di cambiare l'amministratore e solo all'amministratore non nullo memorizzato di attivare o disattivare le funzionalità. Interruttori separati regolano la creazione di token della variante Asset, la creazione di token della variante Stablecoin e le modifiche al registro delle policy condivise. Una volta attivata una variante, il processo di creazione della factory non prevede un elenco di approvazione per i singoli emittenti. Il creatore fornisce l'amministratore iniziale del token e le istruzioni di inizializzazione. La lista di accesso anticipato di BNB Chain rivolta agli emittenti non dimostra che il codice conceda licenze separatamente a ciascun emittente.

Disattivare una funzionalità di creazione dei token impedirebbe la creazione di nuovi token CAS20 di quella variante. I token esistenti potrebbero comunque coniare unità aggiuntive secondo i permessi già previsti, trasferire saldi e amministrare ruoli. L'installazione del supporto per Jenner e l'attivazione della creazione per la variante scelta sono due tappe distinte del lancio. L'interruttore di creazione non è un meccanismo diretto per spostare o congelare il saldo di un detentore esistente.

L'amministratore di un token seleziona le policy per operazioni specifiche e ciascuna policy ha un amministratore distinto, responsabile della gestione dei membri. L'implementazione contrassegnata richiede l'attivazione della funzionalità per le modifiche al registro, comprese quelle relative ai membri e i passaggi di consegne dell'amministratore. Un token può continuare a consultare un elenco esistente anche quando le modifiche al registro sono disattivate. Un account già bloccato da una policy sui trasferimenti potrebbe rimanere soggetto alla restrizione perché l'amministratore dell'elenco non può rimuoverlo mentre le modifiche al registro sono disattivate. Tuttavia, l'amministratore predefinito del token può associare un'altra policy esistente al di fuori dell'interruttore che regola le modifiche al registro, nel rispetto degli altri permessi amministrativi del token. Una modifica ai membri di una policy condivisa può cambiare l'idoneità di un account per ogni token e operazione che fa riferimento a quella policy. Sostituire l'amministratore dell'attivazione ripristina il controllo dell'interruttore, ma non corregge una voce dell'elenco: riattivare le modifiche e aggiornare i membri autorizzati restano operazioni distinte.

Conio, autodistruzione dei token, sequestro, sospensione e riattivazione utilizzano ruoli distinti, assegnabili a indirizzi diversi oppure concentrabili in un unico indirizzo. L'autorità di attivazione a livello di rete, l'appartenenza ai ruoli del token e l'amministrazione degli elenchi di policy restano permessi distinti anche quando una stessa organizzazione ne detiene diversi. I trasferimenti ordinari verificano il mittente e il destinatario rispetto alle rispettive policy; i trasferimenti delegati verificano anche l'esecutore. Il conio applica una policy distinta al destinatario, quindi il permesso di ricevere unità appena coniate non conferisce automaticamente il permesso di inviare token o di agire per conto di un altro detentore.

Il sequestro consentirebbe a un operatore autorizzato di riassegnare saldi idonei senza l'autorizzazione del detentore. Tuttavia, la configurazione predefinita protegge tutti i detentori, quindi il solo conferimento del ruolo di sequestro non rende i saldi idonei. Il codice v1.8.1 chiama la regola relativa ai detentori SEIZE_EXEMPT_POLICY e l'autorizzazione prevista da tale regola protegge l'account dal sequestro. Una riassegnazione ordinaria successiva alla creazione richiede che il controllo di esenzione abbia esito negativo, che sia assegnato il ruolo di sequestro, che la funzione di sequestro non sia sospesa, che il saldo sia sufficiente e che la destinazione sia valida e consentita dalla policy sui destinatari del sequestro. Se queste protezioni sono rispettate, seizeWithMemo non applica i controlli delle policy sui trasferimenti ordinari e lascia invariata l'offerta totale. La distruzione dei token riduce l'offerta e, nelle normali chiamate CAS20, riguarda solo i token del chiamante, secondo un ruolo distinto. L'idoneità ai trasferimenti ordinari non determina quella al sequestro. Sospendere i trasferimenti non sospende il sequestro, che ha un'impostazione di sospensione separata e mantiene le altre protezioni.

Anche i controlli Cobalt di Base separano ruoli e idoneità secondo lo standard B20. CAS20 aggiunge la questione di come l'ammissione delle funzionalità a livello di rete di BNB Chain interagirebbe con i controlli a livello di token. La pagina CAS20 di BNB Chain cerca emittenti per l'accesso anticipato e descrive le varianti Stablecoin e Asset. Il codice nativo condiviso riduce la necessità di implementare separatamente lo stesso comportamento dei token. Tuttavia, la proposta avverte che un difetto nel client nativo potrebbe interessare più token CAS20 e richiedere un altro hard fork per essere corretto. La sola data di rilascio sulla rete principale non chiarirebbe quale indirizzo detiene l'autorità di attivazione, come quell'indirizzo autorizza le modifiche o quali funzionalità siano state attivate.