BNB Chain distribuisce il potere degli asset in 4 ruoli mentre gli amministratori detengono la chiave

Il rilascio della testnet Jenner di BNB Chain avanza un design di asset nativi che darebbe a un amministratore nominato dalla governance il controllo su quando possono essere creati nuovi stablecoin e asset tokenizzati.

Gli emittenti potrebbero avere il codice disponibile sulla rete e necessitare comunque di un'interruttore di funzionalità separato aperto prima di lanciare un token CAS20.

Il rilascio 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 fornisce indicazioni sulla mainnet per la fine di novembre, con l'orario esatto ancora non annunciato.

Lo standard BEP-702 proposto rimane etichettato come Bozza e copre la nuova famiglia di token CAS20, mentre i token BEP-20 esistenti rimarrebbero inalterati. La sua architettura separa tre questioni: se la rete ammette una funzionalità, chi può esercitare i poteri di un token e quali detentori possono essere influenzati da tali poteri.

CAS20 metterebbe il comportamento comune dei token nella logica della catena nativa, implementato come precompilati con stato. Lo stesso design conferisce alla governance della rete un ruolo nel rendere disponibile l'infrastruttura, insieme al controllo dell'emittente sull'asset stesso.

La governance controllerebbe l'apertura

Sotto il BEP-702, la governance della catena nomina l'amministratore di attivazione tramite GovHub, il contratto di inoltro della governance di BSC. L'amministratore quindi effettua chiamate separate per attivare o disattivare le funzionalità.

L'implementazione dell'attivazione del rilascio applica quella divisione. Solo GovHub può cambiare l'amministratore e solo l'amministratore memorizzato e non nullo può operare gli interruttori.

Il design fornisce interruttori separati per la creazione di token di variante Asset, la creazione di token di variante Stablecoin e la scrittura nel registro delle politiche condivise.

Una volta che una variante è abilitata, il percorso di creazione della fabbrica non contiene un elenco di approvazione dell'emittente individuale. Il creatore fornisce l'amministratore iniziale del token e le istruzioni di inizializzazione. La whitelist di accesso anticipato per gli emittenti di BNB Chain non dovrebbe essere letta come prova che questo codice autorizza ciascun emittente separatamente.

Chiudere una funzionalità di creazione di token fermerebbe la creazione di nuovi token CAS20 di quella variante. Non fermerebbe un token esistente dal coniare ulteriori unità sotto i propri permessi, trasferire saldi o amministrare i propri ruoli.

Per un emittente che pianifica un lancio, la dipendenza è concreta: installare il supporto Jenner e attivare la creazione per la variante di token nativo scelta sono traguardi diversi. Per un detentore esistente, lo stesso interruttore non è un meccanismo diretto per spostare o congelare un saldo. I controlli CAS20 proposti di BNB Chain dividono l'autorità in quattro ruoli, con le seizure disabilitate per impostazione predefinita.

Il registro delle politiche condivise crea una seconda dipendenza dopo che un token esiste. Un amministratore di token seleziona politiche per operazioni specifiche e ogni politica ha il proprio amministratore responsabile dell'appartenenza.

L'implementazione della politica etichettata blocca le scritture del registro dietro l'attivazione della funzionalità, comprese le modifiche all'appartenenza all'elenco e i passaggi di amministratore. Un token può continuare a consultare un elenco esistente anche quando quell'elenco non può essere aggiornato.

Considera un account già bloccato da una politica utilizzata per i trasferimenti. Se la funzionalità del registro delle politiche è disabilitata, l'amministratore dell'elenco non può rimuovere l'account mentre quel gate è chiuso. Il detentore potrebbe rimanere ristretto sotto la regola esistente anche se l'azione a livello di rete non ha bloccato il token o alterato i suoi saldi.

L'amministratore predefinito del token può comunque legare un'altra politica esistente, perché il binding della politica a livello di token è al di fuori dell'interruttore di scrittura del registro. Questo è diverso dall'editing dell'elenco condiviso bloccato e dipende dai permessi amministrativi rimanenti del token.

Riutilizzare un elenco può semplificare le operazioni su più asset, ma concentra l'effetto di una decisione di appartenenza. Una modifica a una politica condivisa può alterare l'idoneità dello stesso account su ogni token e operazione che lo fa riferimento.

Sostituire l'amministratore di attivazione della rete ripristinerebbe il controllo dell'interruttore, ma non correggerebbe di per sé un'entrata nell'elenco. Riaprire le scritture politiche e aggiornare i membri autorizzati sono azioni separate.

I permessi dell'emittente governano trasferimenti e sequestro

All'interno di un token, l'amministrazione dei ruoli e la selezione delle politiche conferiscono poteri diversi. La creazione, l'auto-bruciatura, il sequestro, la pausa e la ripresa utilizzano ruoli separati.

Puoi assegnare i poteri a indirizzi diversi o concentrarli nello stesso. L'autorità di attivazione della rete, l'appartenenza ai ruoli del token e l'amministrazione dell'elenco delle politiche rimangono permessi distinti anche se un'organizzazione ne detiene diversi.

L'implementazione ordinaria del trasferimento controlla il mittente e il destinatario rispetto alle rispettive politiche e controlla un esecutore delegato quando sposta i fondi di un altro account.

La creazione ha una politica di destinatario separata, quindi il permesso di ricevere unità appena coniate non risponde automaticamente alla domanda se un account possa inviare token o agire per un altro titolare.

Il sequestro consentirebbe a un operatore autorizzato di riassegnare saldi idonei senza il permesso del titolare. Ma la sua configurazione predefinita protegge ogni titolare: concedere un ruolo di sequestro da solo non rende i saldi idonei.

Il codice amministrativo v1.8.1 chiama la regola del titolare SEIZE_EXEMPT_POLICY. L'autorizzazione sotto di essa protegge l'account dal sequestro. Nelle chiamate ordinarie dopo la creazione, la riassegnazione richiede che il titolare fallisca quel controllo di esenzione, più il ruolo di sequestro del token, una funzione di sequestro non in pausa, un saldo sufficiente e una destinazione valida consentita dalla politica del destinatario del sequestro.

Quando queste protezioni vengono superate, seizeWithMemo bypassa i controlli ordinari della politica di trasferimento e lascia invariato l'offerta totale. Bruciare invece distrugge l'offerta e, per le chiamate CAS20 ordinarie, prende solo i token del chiamante sotto un ruolo separato.

Le restrizioni sui trasferimenti e l'idoneità al sequestro, di conseguenza, non possono essere trattate come intercambiabili. La capacità di un account di effettuare un trasferimento ordinario non stabilisce se potrebbe essere soggetto a riassegnazione amministrativa.

Mettere in pausa i trasferimenti non mette in pausa il sequestro, che ha la propria impostazione di pausa e richiede comunque le sue altre protezioni.

I controlli Cobalt di Base utilizzano una separazione simile di ruoli e idoneità sul suo standard B20. La domanda aggiuntiva rilevante di CAS20 qui è come l'ammissione delle funzionalità a livello di rete di BNB Chain interagirebbe con quei controlli a livello di token.

I prossimi traguardi di BNB Chain sono operativi

La pagina CAS20 di BNB Chain sta cercando emittenti per accesso anticipato e descrive varianti di Stablecoin e Asset.

L'accordo di governance lascia anche un compromesso per gli emittenti che adottano logiche native. Un codice comune riduce la necessità di implementare il comportamento dello stesso token separatamente, mentre la proposta avverte che un difetto del client nativo potrebbe influenzare più token CAS20 e richiedere un altro hard fork per essere corretto.

Il fork della testnet del 29 ottobre è il prossimo passo programmato nel rilascio. Una data di rilascio della mainnet da sola lascerebbe comunque domande separate su quale indirizzo detiene il ruolo di attivazione, come firma le modifiche e quali funzionalità sono state aperte.

I lanci di nuovi token dipenderebbero dall'ammissione delle funzionalità, il mantenimento continuo dell'elenco condiviso dipenderebbe dalla disponibilità del registro e l'esposizione al trasferimento o al sequestro dei titolari dipenderebbe dai permessi e dalle politiche che il loro emittente configura effettivamente.

Questo contenuto è fornito a solo scopo informativo generale e non costituisce consulenza finanziaria, di investimento, legale o fiscale. Qualsiasi evento, ricompensa, promozione online o informazione correlata menzionata nel presente documento non deve essere considerata una raccomandazione, una sollecitazione o un invito ad acquistare, vendere, fare trading o altrimenti negoziare criptovalute. Le criptovalute sono altamente volatili e possono comportare perdite. La disponibilità dei servizi, dei prodotti e degli eventi correlati di WEEX può variare a seconda della regione. È tua responsabilità assicurarti che la tua partecipazione sia conforme alle leggi e ai regolamenti locali applicabili.