4 APIs de Ativos Digitais

O Oracle Blockchain Platform Enterprise Edition para Besu fornece APIs de ativos digitais que você pode usar para trabalhar com contratos inteligentes.

As APIs de ativos digitais são componentes reutilizáveis baseados em Solidity para desenvolver, testar e implementar contratos inteligentes de ativos digitais na Besu. Você pode usar as APIs para implementar aplicativos de token específicos do domínio, mantendo abordagens consistentes para configuração de token, controles de identidade e acesso, capacidade de upgrade e governança.

O núcleo de qualquer aplicativo Oracle Blockchain Platform Besu é um ou mais contratos inteligentes que definem os estados de um ativo digital e as regras de negócios que regem como ele é criado, transferido, mantido, resgatado e gerenciado. Como essas regras afetam diretamente o ciclo de vida do ativo, os contratos devem ser projetados, revisados e testados antes da implantação. Cada uma das duas APIs suporta um padrão de token diferente.

Padrão de token	Uso principal	Exemplo de Casos de Uso
ERC-20	Ativos fungíveis em que cada token é intercambiável com todos os outros tokens.	Pagamentos, stablecoins, tokens de depósito, tokens de liquidação e ativos CBDC por atacado.
ERC-1155	Ativos fungíveis e ativos não fungíveis (NFT). Vários tipos de token são suportados no mesmo contrato inteligente. Tokens fracionários (compartilhamentos) são suportados.	Ativos, coleções e ativos digitais exclusivos com token.

As APIs fornecem contratos base configuráveis e bibliotecas de suporte que você pode herdar ou compor em seus próprios contratos do Solidity. Dependendo do modelo de token selecionado, os aplicativos podem incorporar recursos como cunhagem e gravação, transferências controladas, retenções, aprovações, permissões com reconhecimento de identidade e aplicação de políticas. As APIs também suportam padrões de contrato atualizáveis e operações de ciclo de vida controladas pela governança, se forem exigidas por um aplicativo.

O diagrama a seguir ilustra os recursos das implementações padrão de token ERC-20 estendidas.

O diagrama a seguir ilustra os recursos das implementações padrão estendidas do ERC-1155token.

Módulos Plugáveis de Controle de Acesso

Você pode selecionar módulos de conta e política para alinhar as operações de token ao modelo de controle de acesso de um aplicativo. Especificamente, a API inclui versões de contrato e conta para os modelos de permissão ERC-5982 e EIP-6617. Esses módulos conectam contratos de token a gateways de identidade e política, permitindo que os aplicativos apliquem autorização com reconhecimento de função e com reconhecimento de organização sem incorporar uma única implementação de controle de acesso em cada contrato de token.

Você pode escolher a variante de conta e os recursos de política adequados ao seu aplicativo e, em seguida, usar as interfaces de conta comuns dos contratos de token. Essa separação mantém a lógica de negócios de token focada no ciclo de vida do ativo, permitindo que as políticas de acesso sejam configuradas, estendidas ou trocadas à medida que os requisitos do aplicativo evoluem.

Modelo de Composição do Contrato

A camada de tokenização Solidity usa um modelo de composição de contrato. Você seleciona uma base de token atualizável, adiciona os módulos de comportamento exigidos pelo ciclo de vida do ativo e, em seguida, emparelha o token com uma conta apropriada e um módulo de controle de acesso. Esse modelo suporta recursos como cunhagem, gravação, retenção e aprovações sem exigir que cada token exponha cada operação. Você pode usar composição restrita ou composição de mistura/compatibilidade.

A composição rigorosa é apropriada quando as operações de token suportadas são conhecidas no design time. Os desenvolvedores herdam de um contrato base restrito que suporta apenas recursos específicos. Apenas as operações selecionadas são incluídas no ABI do contrato. Durante a inicialização, a configuração do token é validada em relação ao perfil de capacidade selecionado, para que comportamentos incompatíveis ou modos de cunhagem e gravação sejam rejeitados.

Mixin / composição de compatibilidade é apropriado quando a flexibilidade de tempo de execução e um conjunto mais amplo e reutilizável de operações de token são mais importantes. Os desenvolvedores herdam de um contrato base mais completo, com sinalizadores de comportamento de runtime que determinam quais políticas opcionais estão ativas. O ABI completo permanece disponível, enquanto as operações específicas de comportamento impõem a configuração ativada quando elas são chamadas.

Escolha a composição mais restrita que atenda aos requisitos do produto e, em seguida, combine-a com o módulo de conta de controle de acesso necessário e a lógica de negócios específica do produto. Composição estrita produz um ABI menor, mais intencional e impede que operações não suportadas sejam expostas. Mixin / composição de compatibilidade fornece uma base mais ampla para aplicativos cujo comportamento deve ser configurado no tempo de execução.

Use as APIs como pontos de partida e não como aplicativos fixos. Normalmente, uma equipe seleciona a base ERC-20 ou ERC-1155 que corresponde ao modelo de ativo necessário, configura os controles de comportamento e acesso e, em seguida, implementa uma lógica de negócios específica para dar suporte ao ciclo de vida do ativo. Isso permite uma base de contrato comum, permitindo que cada aplicativo reflita seus próprios participantes, regras de autorização e processos operacionais.

As APIs são para desenvolvedores Solidity que trabalham diretamente com as fontes de contrato ERC-20 e ERC-1155. Você pode desenvolver e testar aplicativos usando o Hardhat e, em seguida, implantar em um ambiente do Oracle Blockchain Platform usando a abordagem de implantação apropriada para o aplicativo.

Fluxo de Governança para Implantação e Atualização de Contratos

A governança controla quando um contrato implantado se torna utilizável e quais atualizações de implementação de UUPS são autorizadas. Projetos compostos implantam e conectam os proxies de conta e token e, em seguida, anexam um contrato de governança e um UUID de governança. Os proxies ficam deliberadamente inativos até que o fluxo de governança configurado os ative, conforme mostrado no seguinte ciclo de vida:

1. Implante proxies UUPS de conta e token.
2. Defina o contexto da conta/token e o contexto de governança. Os representantes permanecem inativos.
3. Envie a intenção de implantação com componentes de proxy, implementação e code-hash.
4. • No-Op: Aceito imediatamente, componentes ativados.
   • Controlado: Colete aprovações de política e, em seguida, os componentes são ativados após a aprovação.

Modelos de Governança

Os dois modelos de governança suportados são No-Op e Governed.

O No-Op não remove o ciclo de vida de governança do aplicativo. Ele implementa a mesma interface de governança, registra a intenção e aprova verificações de implantação e upgrade automaticamente. Não use o modelo No-Op como um mecanismo de aprovação de produção.

O modelo Governado não permite que o implantador, o Blockchain App Builder ou um script CLI ignorem os aprovadores. Os aprovadores necessários, o limite, o prazo e o processo de aprovação são definidos pela governança implantada e pela configuração da política.

A tabela a seguir resume o comportamento dos dois modelos de governança.

Modelo de Governança	Objetivo	Comportamento da Implantação	Comportamento da atualização
Sem op	Desenvolvimento local, demonstrações e outras situações em que a aprovação da governança é intencionalmente ignorada.	A função proposeDeployIntent aceita a intenção e ativa seus componentes imediatamente.	A intenção de upgrade é aceita sem aprovação de política; o operador ainda executa a etapa de execução upgradeToAndCall preparada.
Controlado	Ambientes que necessitam de revisão e aprovação baseadas em políticas.	A intenção permanece pendente até que a política configurada receba as aprovações necessárias antes de seu prazo; somente então os componentes são ativados.	A implementação proposta e seu hash de código devem receber a autorização necessária para que a etapa de execução possa consumir a implementação e atualizar o proxy.

Quando você cria um projeto com o Blockchain App Builder, os seguintes blocos de construção de governança já são fornecidos:

• A interface IDAContractGovernance e as implementações NoOpGovernance e GovernedGovernance.
• Contexto de governança e suporte de ativação em bases de contrato de conta e token gerados, incluindo os métodos setGovernanceContext, getGovernanceContext e activateFromGovernance.
• A autorização de upgrade do UUPS por meio do método UpgradeAuthorizationLib da API, que chama o contrato de governança configurado durante o processo _authorizeUpgrade.
• Scripts de implantação e upgrade gerados que definem o contexto de governança, preparam dados de intenção, registram manifestos e enviam solicitações de intenção.

Como esses blocos de construção já são fornecidos, um projeto composto padrão não exige que você escreva ganchos extras de governança do Solidity para seus contratos de token e conta gerados. Você ainda deve escolher e implantar ou obter o contrato de governança apropriado, configurar o UUID e a política, fornecer seus endereços para o workflow de implantação/upgrade e passar pelo processo de aprovação para ambientes Governados. Para uma rede do Oracle Blockchain Platform Besu, um contrato de governança é implantado como parte do provisionamento da instância.