BNB Chain divide o poder dos ativos em 4 funções enquanto administradores mantêm a chave

O lançamento da testnet Jenner da BNB Chain avança um design de ativo nativo que daria a um administrador nomeado pela governança controle sobre quando novas stablecoins e ativos tokenizados podem ser criados.

Os emissores poderiam ter o código disponível na rede e ainda precisariam de uma função separada ativada antes de lançar um token CAS20.

O lançamento da versão 1.8.1 em 16 de outubro agenda Jenner para a testnet Chapel da BNB Smart Chain em 29 de outubro às 02:30 UTC. Um anúncio anterior fornece orientações para o mainnet no final de novembro, com o horário exato ainda não anunciado.

O padrão BEP-702 proposto permanece rotulado como Rascunho e abrange a nova família de tokens CAS20, enquanto os tokens BEP-20 existentes permaneceriam inalterados. Sua arquitetura separa três questões: se a rede admite uma função, quem pode exercer os poderes de um token e quais detentores esses poderes podem afetar.

O CAS20 colocaria o comportamento comum dos tokens na lógica da cadeia nativa, implementado como pré-compilados com estado. O mesmo design dá à governança da rede um papel na disponibilização da infraestrutura, ao lado do controle do emissor sobre o ativo em si.

A governança controlaria a ativação

Sob o BEP-702, a governança da cadeia nomeia o administrador de ativação através do GovHub, o contrato de encaminhamento de governança da BSC. O administrador então faz chamadas separadas para ativar ou desativar funções.

A implementação de ativação do lançamento reforça essa divisão. Apenas o GovHub pode mudar o administrador, e apenas o administrador armazenado e não zero pode operar os interruptores.

O design fornece interruptores separados para criar tokens variantes de Ativo, criar tokens variantes de Stablecoin e escrever no registro de políticas compartilhadas.

Uma vez que uma variante é habilitada, o caminho de criação da fábrica não contém uma lista de aprovação de emissor individual. O criador fornece o administrador inicial do token e instruções de inicialização. A lista de acesso antecipado voltada para emissores da BNB Chain não deve ser lida como prova de que este código licencia cada emissor separadamente.

Fechar uma função de criação de token impediria que novos tokens CAS20 dessa variante fossem criados. Não impediria um token existente de cunhar unidades adicionais sob suas próprias permissões, transferir saldos ou administrar suas funções.

Para um emissor planejando um lançamento, a dependência é concreta: instalar o suporte ao Jenner e ativar a criação para a variante de token nativo escolhida são marcos diferentes. Para um detentor existente, o mesmo interruptor não é um mecanismo direto para mover ou congelar um saldo. Os controles CAS20 propostos da BNB Chain dividem a autoridade em quatro funções, com apreensões desativadas por padrão.

O registro de políticas compartilhadas cria uma segunda dependência após um token existir. Um administrador de token seleciona políticas para operações específicas, e cada política tem seu próprio administrador responsável pela adesão.

A implementação da política marcada bloqueia gravações no registro atrás da ativação da função, incluindo mudanças de adesão à lista e transferências de administrador. Um token pode continuar consultando uma lista existente mesmo quando essa lista não pode ser atualizada.

Considere uma conta já bloqueada por uma política usada para transferências. Se a função do registro de políticas estiver desativada, o administrador da lista não pode remover a conta enquanto esse bloqueio estiver fechado. O detentor poderia permanecer restrito sob a regra existente, mesmo que a ação em nível de rede não tenha congelado o token ou alterado seus saldos.

O administrador padrão do token ainda pode vincular outra política existente, porque a vinculação de política em nível de token está fora do interruptor de gravação do registro. Isso é diferente de editar a lista compartilhada congelada e depende das permissões administrativas restantes do token.

Reutilizar uma lista pode simplificar operações em vários ativos, mas concentra o efeito de uma decisão de adesão. Uma alteração em uma política compartilhada pode alterar a elegibilidade da mesma conta em cada token e operação que a referencia.

Substituir o administrador de ativação da rede restauraria o controle do interruptor, mas não corrigiria por si só uma entrada na lista. Reabrir as políticas de escrita e atualizar a adesão permitida são ações separadas.

Permissões do emissor governam transferências e apreensões

Dentro de um token, a administração de funções e a seleção de políticas concedem poderes diferentes. A criação, autoqueima, apreensão, pausa e retoma utilizam funções separadas.

Você pode atribuir os poderes a endereços diferentes ou concentrá-los no mesmo. A autoridade de ativação da rede, a adesão a funções de token e a administração da lista de políticas permanecem permissões distintas, mesmo que uma organização possua várias delas.

A implementação de transferência ordinária verifica o remetente e o destinatário em relação às suas respectivas políticas e verifica um executor delegado quando move os fundos de outra conta.

A criação tem uma política de destinatário separada, portanto, a permissão para receber unidades recém-criadas não responde automaticamente se uma conta pode enviar tokens ou agir em nome de outro titular.

A apreensão permitiria que um operador autorizado reatribua saldos elegíveis sem a permissão do titular. Mas sua configuração padrão protege cada titular: conceder apenas um papel de apreensão não torna os saldos elegíveis.

O código administrativo v1.8.1 chama a regra do titular de SEIZE_EXEMPT_POLICY. A autorização sob ela protege a conta de apreensão. Em chamadas ordinárias após a criação, a reatribuição requer que o titular falhe na verificação de isenção, além do papel de apreensão do token, uma função de apreensão não pausada, saldo suficiente e um destino válido permitido pela política do receptor de apreensão.

Quando essas proteções são superadas, seizeWithMemo ignora as verificações de política de transferência ordinária e deixa o suprimento total inalterado. A queima, em vez disso, destrói o suprimento e, para chamadas CAS20 ordinárias, leva apenas os próprios tokens do chamador sob um papel separado.

Consequentemente, as restrições de transferência e a elegibilidade para apreensão não podem ser tratadas como intercambiáveis. A capacidade de uma conta de fazer uma transferência ordinária não determina se ela poderia estar sujeita a reatribuição administrativa.

Pausar transferências também não pausa a apreensão, que tem sua própria configuração de pausa e ainda requer suas outras salvaguardas.

Os controles de Cobalt da Base utilizam uma separação semelhante de funções e elegibilidade em seu padrão B20. A questão adicional relevante do CAS20 aqui é como a própria admissão de recursos em nível de rede da BNB Chain interagiria com esses controles em nível de token.

Os próximos marcos da BNB Chain são operacionais

A página CAS20 da BNB Chain está buscando emissores de acesso antecipado e descreve variantes de Stablecoin e Ativos.

O arranjo de governança também deixa um compromisso para emissores que adotam lógica nativa. O código comum reduz a necessidade de implementar o mesmo comportamento de token separadamente, enquanto a proposta alerta que um defeito no cliente nativo poderia afetar vários tokens CAS20 e exigir outro hard fork para corrigir.

O fork da testnet de 29 de outubro é o próximo passo agendado no lançamento. Uma data de lançamento da mainnet sozinha ainda deixaria questões separadas sobre qual endereço detém o papel de ativação, como ele assina alterações e quais recursos foram abertos.

Os lançamentos de novos tokens dependeriam da admissão de recursos, a manutenção contínua da lista compartilhada dependeria da disponibilidade do registro, e a exposição à transferência ou apreensão dos titulares dependeria das permissões e políticas que seu emissor realmente configura.

Este conteúdo é disponibilizado apenas para fins informativos gerais e não constitui aconselhamento financeiro, de investimento, jurídico ou fiscal. Quaisquer eventos, recompensas, promoções online ou informações relacionadas aqui mencionados não devem ser interpretados como uma recomendação, solicitação ou convite para comprar, vender, negociar ou realizar quaisquer outras operações com criptoativos. Os criptoativos são altamente voláteis e podem resultar em perdas. A disponibilidade dos serviços, produtos e eventos relacionados da WEEX pode variar consoante a região. O utilizador é responsável por garantir que a sua participação está em conformidade com a legislação e os regulamentos locais aplicáveis.