Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
A Cadeia BNB divide o poder dos ativos em 4 funções enquanto os administradores detêm a chave
O lançamento da rede de teste Jenner da BNB Chain avança um design de ativos nativos que daria a um administrador nomeado pela governança controle sobre quando novas stablecoins e ativos tokenizados podem ser criados.
Os emissores podem ter o código disponível na rede e ainda precisar de um switch de recurso separado aberto antes de lançar um token CAS20.
O Lançamento v1.8.1 de 16 de outubro agenda Jenner para o testnet da BNB Smart Chain’s Chapel em 29 de outubro às 02:30 UTC. Um anúncio anterior fornece orientação para a rede principal no final de novembro, com a hora exata ainda sem aviso prévio.
A proposta BEP-702 o padrão permanece rotulado como Draft e cobre 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 um recurso, quem pode exercer os poderes de um token e quais detentores esses poderes podem afetar.
O CAS20 colocaria o comportamento comum do token na lógica da cadeia nativa, implementada como pré-compilações com estado. O mesmo desenho confere à governação da rede um papel na disponibilização da infra-estrutura, juntamente com o controlo do emitente sobre o próprio activo.
A governança controlaria a abertura
De acordo com o BEP-702, a governança da cadeia nomeia o administrador de ativação por meio do GovHub, o contrato de encaminhamento de governança do BSC. O administrador então faz chamadas separadas para ativar ou desativar recursos.
O implementação de ativação do lançamento reforça essa divisão. Somente o GovHub pode alterar o administrador, e somente o administrador armazenado e diferente de zero pode operar os switches.
O design fornece opções separadas para criar tokens variantes de ativos, criar tokens variantes de Stablecoin e gravar no registro de política compartilhada.
Depois que uma variante é ativada, o caminho de criação da fábrica não contém uma lista de aprovação de emissores individuais. O criador fornece o administrador do token inicial e as instruções de inicialização. BNB A lista branca de acesso antecipado voltada para emissores da Chain não deve ser interpretada como prova de que este código licencia cada emissor separadamente.
Fechar um recurso de criação de token impediria a criação de novos tokens CAS20 dessa variante. Isso 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 que planeja um lançamento, a dependência é concreta: instalar o suporte Jenner e ativar a criação para a variante de token nativo escolhida são marcos diferentes. Para um suporte existente, a mesma chave não é um mecanismo direto para mover ou congelar uma balança.
O registro de política compartilhada cria uma segunda dependência após a existência de um token. Um administrador de token seleciona políticas para operações específicas e cada política tem seu próprio administrador responsável pela associação.
O implementação de política marcada O registro do Gates grava por trás da ativação de recursos, incluindo alterações de associação à lista e transferências de administradores. 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 o recurso de registro de políticas estiver desativado, o administrador da lista não poderá remover a conta enquanto o portão estiver fechado. O detentor poderia permanecer restrito sob a regra existente, mesmo que a ação no nível da rede não congelasse o token ou alterasse 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 da opção de gravação do registro. Isso é diferente de editar a lista compartilhada congelada e depende das permissões administrativas restantes do token.
A reutilização de uma lista pode simplificar as operações em vários ativos, mas concentra o efeito de uma decisão de adesão. Uma alteração a uma política partilhada pode alterar a elegibilidade da mesma conta em todos os tokens e operações que a referenciam.
A substituição do administrador de ativação da rede restauraria o controle do switch, mas por si só não corrigiria uma entrada da lista. A reabertura de gravações de políticas e a atualização da associação permitida são ações separadas.
As permissões do emissor regem 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. Cunhagem, auto-queima, apreensão, pausa e retomada usam funções separadas.
Você pode atribuir os poderes a endereços diferentes ou concentrá-los em um mesmo. A autoridade de ativação de rede, a associação à função de token e a administração da lista de políticas permanecem permissões distintas, mesmo que uma organização possua várias delas.
O 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 movimenta os fundos de outra conta.
A cunhagem tem uma política de destinatário separada, portanto, a permissão para receber unidades recém-cunhadas 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 reatribuísse saldos elegíveis sem a permissão do titular. Mas sua configuração padrão protege todos os titulares: a concessão de uma função de apreensão por si só não torna os saldos elegíveis.
O Código administrativo v1.8.1 chama a regra do titular SEIZE_EXEMPT_POLICY. A autorização sob ela protege a conta contra apreensão. Em chamadas normais após a criação, a reatribuição exige que o titular seja reprovado na verificação de isenção, além da função 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 esses guardas passarem, seizeWithMemo ignora as verificações normais da política de transferência e deixa a oferta total inalterada. Em vez disso, a queima destrói o fornecimento e, para chamadas CAS20 comuns, utiliza apenas os tokens do próprio chamador em uma função separada.
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 fazer uma transferência normal não determina se ela poderá 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 outras salvaguardas.
Controles Cobalt da Base usa uma separação semelhante de funções e elegibilidade em seu padrão B20. A questão adicional relevante do CAS20 aqui é como a admissão de recursos em nível de rede da própria cadeia BNB interagiria com esses controles em nível de token.
Os próximos marcos da Rede BNB estão operacionais
Cadeia BNB Página CAS20 está buscando emissores de acesso antecipado e descreve variantes de Stablecoin e Asset.
O acordo de governação também deixa uma compensação para os emitentes que adoptam a 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 do cliente nativo pode afetar vários tokens CAS20 e exigir outro hard fork para correção.
A bifurcação testnet de 29 de outubro é a próxima etapa programada do lançamento. A data de lançamento da mainnet por si só ainda deixaria questões separadas sobre qual endereço detém a função de ativação, como ele assina as alterações e quais recursos foram abertos.
O lançamento de novos tokens dependeria da admissão de recursos, a manutenção contínua da lista compartilhada dependeria da disponibilidade do registro e a transferência ou exposição dos detentores à apreensão dependeria das permissões e políticas que seu emissor realmente configura.
