Sobre a atualização padrão do token Flow FT && NFT

December 25, 2022

Faz 11 meses desde que o último padrão NFT MetadataView foi lançado. Tokens fungíveis da flow inerentes ao Padrão MetadataView, embora ainda esteja em fase de teste, podemos esperar a adoção formal do padrão. Esta atualização não apenas nos traz a MetadataView contrato padrão de tokens fungíveis. O FungibleTokenSwitchboard pode implementar uma coleção geral de recursos do Receiver para resolver o NFTMetadataView anterior Realeza problema de configuração.

Essa atualização também é realizada de maneira baixa, com modificações no contrato padrão, e a ideia geral de design é a mesma que a do NFTMetadataViews. Para mais detalhes sobre o NFTMetadataViews, você pode ir aqui leia o artigo de introdução que escrevi anteriormente e este é sobre a prática de design e explicação da Flow NFT e FT. Este artigo será apresentado e explicado de acordo com duas grandes atualizações do contrato padrão do Financial Times.

Pontos principais:

Essas atualizações são implantadas apenas na rede de teste e os novos recursos precisam ser suportados por um novo spork.
O contrato FT existente não força as atualizações, você pode optar por não atualizar, o que não afetará o uso normal.
Os recursos do Vault que foram inicializados pelo usuário não precisam ser reinicializados. Se a implementação do contrato atualizar a função, os recursos que foram inicializados pelo usuário serão herdados automaticamente.
Além das informações básicas do Financial Times, também serão incluídas informações sobre recursos e tipos de informações. ( Acho que está em preparação para a exibição de agregação de informações na cadeia )
Semelhante ao NFTMetadataView, o FTMetadataView também tem a capacidade de exibir type
extensões para suportar mais tipos de metadados no futuro.
O FungibleTokenSwitchboard, como um recurso de roteamento adicional, preserva os recursos do FT Receiver na conta do usuário e pode receber vários tipos de token FT através de um recurso como roteador.

Views de dados do fungibleTokenMetadata

FungibleTokenMetadataViews.cdc depende FungibleToken e MetadataViews

O FTView estrutura é definida, incluindo FTDisplay e FTVaultData

FTDisplay
contém as informações, como nomes, símbolos, descrições, links externos, links de logotipo e alguns links de contas sociais necessários para a exibição do FT, que podem ser entendidos como as informações básicas do Token.
FTVaultData função createEmptyVault
isso contém as informações de recursos do FTVault e algumas informações de tipo da interface, além de uma inicialização
para criar Vault.

Do ponto de vista da implementação, FTDisplay foi projetado para enriquecer as informações básicas na cadeia do FungibleToken, enquanto FTVaultData foi projetado para facilitar a integração de terceiros para integrar o Token on-chain. Vários tipos de FungibleToken pode ser compatível com o padrão MetadataViews interface.

Obviamente, a premissa dessa suposição é que FungibleToken implementou as interfaces necessárias de MetadataViews. Vamos ver o que mudanças e atualizações foram feitos para FungibleToken

pub fun getViews(): [Type] {
     return []
   }
pub fun resolveView(_ view: Type): AnyStruct? {
    return nil
  }

De fato, FungibleToken apenas adiciona getViews e resolveView funções para o existente Balance interface e retorna o tipo de opcional. A dependência do contrato recém-adicionada não é introduzida aqui, mas é introduzida em ExampleToken do exemplo:

Nota: as alterações do FungibleToken são ligeiramente diferentes aqui. Devido à adição da função de implementação no tipo de interface Balance, ela causará problemas com os recursos existentes que herdam o FungibleToken. Saldo na rede. ( normalmente falando, um contrato que herda o FungibleToken.Balance, mas não implementa getViews e o resolveView, não pode ser implantado corretamente. ) Durante uma discussão com o B.T. Wood, ele me disse uma atualização recente do Cadence, se você herdar os recursos da interface, mesmo que não implemente os métodos definidos pela interface. O Cadence usará o método padrão da própria interface, para que os problemas acima não ocorram. Esse recurso será atualizado no futuro spork.

Essas duas novas interfaces são implementadas em Vault recurso:

 pub fun getViews(): [Type]{
     return [Type<FungibleTokenMetadataViews.FTView>(),
        Type<FungibleTokenMetadataViews.FTDisplay>(),
        Type<FungibleTokenMetadataViews.FTVaultData>()]
        }

Três tipos de estruturas, FTView, incluir FTDisplay e FTVaultData, são definidos. Após a atualização, podemos chamar diretamente getViews na interface Balance existente do FungibleToken para obter os tipos atuais de MetadataView suportados pelo Token e obter informações específicas sobre Metadados por meio de resolveView.

Essa estrutura de código não apenas atinge o efeito de compatibilidade com versões anteriores, mas também atende ao requisito de adicionar dinamicamente tipos de metadados de acordo com as necessidades no futuro. Podemos enriquecer os metadados da cadeia do FT estendendo os tipos suportados pelo FungibleTokenMetadataViews.

Painel fungível

Podemos pensar em FungibleTokenSwitchboard como um recurso de roteamento agregado em uma conta. Implementa a interface de FungibleToken.Receiver e atua como uma coleção universal no padrão. Através do receiverCapabilities nos recursos, o Receiver de Vault na conta do usuário pode ser salvo e encaminhado para o correspondente Receiver com apenas um caminho. receiverCapabilities é definido no Switchboard recurso para agregar os recursos de coleta de FungibleToken:

 pub resource Switchboard: FungibleToken.Receiver, SwitchboardPublic {
        access(contract) var receiverCapabilities: {Type: Capability<&{FungibleToken.Receiver}>}
        //....
}

receiverCapabilities leva Type como a chave e o recibo Capability de Vault como valor, esse é o núcleo da coleta de roteamento

Ao mesmo tempo, fornece uma maneira de gerenciar rotas:

addNewVaultVaultSwitchboardCapability
Adicione um novo
rota para
via
addNewVaultsByPathSwitchboard
Adicionar lote a
através da matriz de caminhos de recursos
removeVault
remover

Porque Switchboard herda FungibleToken.Receiver, o deposit a função precisa ser implementada.

  pub fun deposit(from: @FungibleToken.Vault) {
            // Get the capability from the ones stored at the switchboard
            let depositedVaultCapability = self
                .receiverCapabilities[from.getType()]
                ?? panic ("The deposited vault is not available on this switchboard")
            // Borrow the reference to the desired vault
            let vaultRef = depositedVaultCapability.borrow()
                ?? panic ("Can not borrow a reference to the the vault")
            vaultRef.deposit(from: <-from)
        }

Essa função de depósito implementa uma função de encaminhar depósitos e direciona a coleta para os recursos específicos na configuração. Também podemos ver que se o valor correspondente de receiverCapabilities não é encontrado aqui, o programa Panic fará com que a transação do depósito falhe. Para conveniência de terceiros, o tipo de interface de SwitchboardPublic é definido e três funções são definidas:

getVaultTypesVault
pegue o
tipos que suportam recepção
depósito como menção berfore
a função de depósito seguro safeDeposit@FungibleToken.Vault
não causa pânico, mesmo que falhe, mas retorna o
recurso
igual a Deposit@FungibleToken.Vault
, recebendo
recurso
primeiro determinará se receiverCapabilities
possui um recurso de recebimento configurado para o recurso correspondente.
se não for encontrado e o valor do depósito for maior que zero, o evento de falha do depósito será acionado e a entrada @ FungibleToken.Vault
recurso será retornado.
caso contrário, destrua os recursos de recarga diretamente e retorne nil

 pub fun safeDeposit(from: @FungibleToken.Vault): @FungibleToken.Vault? {
            // Try to get the proper vault capability from the switchboard
            // If the desired vault is present on the switchboard...
            if let depositedVaultCapability = self
                                        .receiverCapabilities[from.getType()] {
                // We try to borrow a reference to the vault from the capability
                // If we can borrow a reference to the vault...
                if let vaultRef =  depositedVaultCapability.borrow() {
                    // We deposit the funds on said vault
                    vaultRef.deposit(from: <-from.withdraw(amount: from.balance))
                }
            }
            // if deposit failed for some reason
            if from.balance > 0.0 {
                emit NotCompletedDeposit(type: from.getType(),
                                        amount: from.balance,
                                        switchboardOwner: self.owner?.address)
                return <-from
            }
            destroy from
            return nil
        }

Em suma, o Switchboard O recurso, como recurso de roteamento de terceiros, fornece um método geral de coleta para os usuários, para que a configuração de royalties de Realeza no anterior NFTMetadataViews pode receber uma variedade de ativos de FT. Do ponto de vista do aplicativo, desenvolvedores ou portais de carteira de terceiros ainda precisam integrar e introduzir novos contratos, o que facilita a configuração e o gerenciamento manual dos recursos Switchboard.

NFT tomnFTSAfe

Aliás, o contrato padrão da NFT também foi lançado atualização, adicionou uma função emprestNFTSafe à interface de recursos da NFT CollectionPublic para evitar erros na execução do script devido à falha em encontrar a NFT do ID específico na conta durante a execução do script de consulta. Melhore a experiência de consulta e desenvolvimento dos desenvolvedores.

Resumo

Esta atualização ainda está no estágio de Implantação de rede de teste, onde os desenvolvedores podem experimentar os recursos de novos padrões e novos contratos. Após o futuro spork da rede principal, esses novos códigos serão implantados. Em seguida, o FT poderá consultar o Metadata on-chain, e os editores originais do FT poderão implementar novas funções e atualizar seus contratos de acordo com o exemplo do projeto do FT.

Dessa forma, os produtos de catálogo que suportam o FT não devem estar longe.