Introdução

E se perdesse a memória de hora em hora? E precisa de pedir constantemente a alguém para lhe dizer o que fez? Esse é o estado atual dos contratos inteligentes. Em blockchains como o Ethereum, os contratos inteligentes não podem aceder diretamente a estados para além dos 256 blocos. Este problema é ainda mais agravado no ecossistema multi-cadeias, onde a recuperação e verificação de dados em diferentes camadas de execução é ainda mais difícil.

Em 2020, Vitalik Buterin e Tomasz Stanczak propuseram uma forma de aceder aos dados ao longo do tempo. Enquanto o EIP ficou estagnado, a sua necessidade ressurgiu no mundo multi-cadeias centrado no roll-up. Hoje, as provas de armazenamento emergiram como uma fronteira, para dar consciência e memória aos contratos inteligentes.

Aceder a dados na cadeia

Existem várias maneiras pelas quais os dapps podem aceder aos dados e ao estado. Todas as abordagens exigem que a aplicação confie em humanos/entidades ou segurança ou código económico criptográfico e tenha algumas compensações:

Confiança em humanos/entidades:

• Nódulos de arquivo: Os operadores podem executar eles próprios um nó de arquivo ou contar com provedores de serviços de nó de arquivo como Alchemy ou Infura para aceder a todos os dados desde o bloco Genesis. Fornecem todos os mesmos dados que um Full Node mas também todos os dados históricos do estado de toda a cadeia de blocos. Os serviços fora da cadeia, como o Etherscan e o Dune Analytics, utilizam nós de arquivo para aceder a dados na cadeia. Os intervenientes fora da cadeia podem atestar a validade destes dados, e os contratos inteligentes na cadeia podem verificar se os dados foram assinados por um ator/comité de confiança. A integridade dos dados subjacentes não é verificada. Esta abordagem exige que o dapp confie que o fornecedor de serviços de nó de arquivo está a executar a infraestrutura corretamente e sem qualquer intenção maliciosa.

Confie na segurança económica Crypto:

• Indexadores: O protocolo de indexação organiza todos os dados no Blockchain, permitindo aos programadores construir e publicar APIs abertas que as aplicações podem consultar. Os indexadores individuais são operadores de nós que aposta tokens para fornecer serviços de indexação e processamento de consultas. No entanto, podem ocorrer disputas quando os dados fornecidos estão incorretos e o processo de arbitragem pode levar tempo. Além disso, os dados de indexadores como o The Graph não podem ser utilizados diretamente pela lógica empresarial dos contratos inteligentes e são utilizados no contexto analítico de dados baseado na web2.
• Oráculos: Os prestadores de serviços Oracle utilizam os dados agregados de muitos operadores de nós independentes. O desafio aqui é que os dados disponíveis no Oracles podem não ser atualizados com frequência e têm um escopo limitado. Oráculos como o Chainlink normalmente mantêm apenas estados específicos, como feeds de preços e para estados e histórico específicos da aplicação não são viáveis. Além disso, esta abordagem também introduz um certo nível de desvio nos dados e requer confiança nos operadores de nós.

Código de Confiança:

• Variável e Funções Especiais: Blockchains como o Ethereum têm variáveis e funções especiais que são usadas principalmente para fornecer informações sobre a cadeia de blocos ou são funções utilitárias de uso geral. Só é possível para um contrato inteligente aceder ao hash de bloco dos 256 blocos mais recentes. Os hashes de bloco não estão disponíveis para todos os blocos por razões de escalabilidade. Ter acesso a hashes de bloco histórico seria útil, pois poderia permitir a verificação de provas contra eles. Não existe nenhum opcode na execução do EVM que permita o acesso a conteúdos de blocos antigos ou conteúdos de transações anteriores ou saídas de recebimento, para que um nó possa esquecer essas coisas com segurança e ainda ser capaz de processar novos blocos. Este método também está limitado a uma única cadeia de blocos.

Dados os desafios e limitações destas soluções, há uma necessidade clara de armazenar e fornecer hashes de bloco na cadeia. É aqui que entram as provas de armazenamento. Para entender melhor as provas de armazenamento, vamos dar uma olhada rápida no armazenamento de dados em blockchains.

Armazenamento de dados numa cadeia de blocos

Uma blockchain é uma base de dados pública que é atualizada e partilhada entre muitos computadores numa rede. Os dados e o estado são armazenados em grupos consecutivos chamados blocos e cada bloco faz referência criptograficamente ao seu pai, armazenando o hash do cabeçalho do bloco anterior.

Vamos tomar o bloco Ethereum como exemplo. O Ethereum aproveita um tipo específico de árvore Merkle conhecida como a “árvore Merkle Patricia” (MPT). Os cabeçalhos de bloco Ethereum contêm raízes de quatro tentativas diferentes da Merkle-Patricia, i.e. Tribo estadual, Tribo de armazenamento, Tribo de recibos e Triagem de transação. Estas 4 tentativas codificam mapeamentos que compreendem todos os dados do Ethereum. As árvores Merkle são utilizadas devido à sua eficiência no armazenamento de dados. Usando hashes recursivos, apenas o hash raiz eventualmente precisa ser armazenado, economizando muito espaço. Permitem que qualquer pessoa prove a existência de um elemento na árvore provando que o hash recursivo dos nós leva ao mesmo hash raiz. As provas da Merkle permitem que clientes ligeiros no Ethereum obtêm respostas a perguntas como:

• Esta transação existe num determinado bloco?
• Qual é o saldo atual da minha conta?
• Esta conta existe?

Em vez de descarregar todas as transações e cada bloco, um “cliente leve” só pode descarregar a cadeia de cabeçalhos de bloco e verificar as informações usando Merkle Proofs. Isto torna o processo global altamente eficiente. Consulte este blog da Vitalik e do artigo de pesquisa Maven11 para entender melhor a implementação, vantagens e desafios associados às Merkle Trees.

Provas de armazenamento

As provas de armazenamento permitem-nos provar que algo está comprometido na base de dados e é válido também usando compromissos criptográficos. Se pudermos fornecer essa prova, é uma alegação verificável de que algo aconteceu na cadeia de blocos.

O que podem permitir as provas de armazenamento?

As provas de armazenamento permitem duas funcionalidades principais:

1. Aceda a dados históricos na cadeia para além dos últimos 256 blocos, desde o bloco de génese
2. Aceda a dados em cadeia (históricos e atuais) de um blockchain em outro blockchain com a ajuda de verificação de consenso ou ponte L1-L2 no caso de L2s

Como funcionam as provas de armazenamento?

Provas de armazenamento a um nível muito alto verificam se o bloco específico faz parte do histórico canónico da cadeia de blocos e, em seguida, verifique se os dados específicos solicitados fazem parte do bloco. Isto poderia ser conseguido através de:

• Processamento em cadeia: os dapps podem pegar o bloco confiável inicial, passar o bloco como calldata para acessar o bloco anterior e atravessar todo o caminho de volta ao bloco de génese. Isto requer muita computação em cadeia e uma enorme quantidade de dados de chamadas. Esta abordagem não é de todo praticamente viável devido à enorme quantidade de computação necessária na cadeia. Aragão tentou usar a abordagem on-chain em 2018, mas não foi viável devido ao alto custo da cadeia.
• Usando provas ZK: A abordagem é semelhante ao processamento em cadeia, excepto pelo facto de o ZK prover ser utilizado para mover a computação complexa fora da cadeia.

1. Aceder a dados na mesma cadeia: A prova ZK pode ser usada para afirmar que um cabeçalho de bloco histórico arbitrário é um ancestral de um dos 256 cabeçalhos de bloco mais recentes que estão acessíveis no ambiente de execução. A outra abordagem é indexar todo o histórico da cadeia de origem e gerar uma prova ZK do mesmo para provar que a indexação aconteceu corretamente. Esta prova é atualizada regularmente à medida que novos blocos são adicionados à cadeia de origem. Aceder a dados entre cadeias: O fornecedor recolhe os cabeçalhos de bloco da cadeia de origem na cadeia de destino e atesta a validade desses cabeçalhos de bloco usando a prova de consenso ZK. Também é possível usar uma solução AMP existente como Axelar, Celer ou LayerZero para consultar os cabeçalhos dos blocos.
2. Um cache de hashes de cabeçalhos de bloco da cadeia de origem, ou o hash raiz de um acumulador de hash de bloco fora da cadeia, é mantido na cadeia de destino. Este cache é atualizado regularmente e é utilizado para provar eficientemente na cadeia que existe um determinado bloco e tem ligação criptográfica a um hash de bloco recente acessível a partir do estado. Este processo é conhecido como provar a continuidade da cadeia. Também é possível usar uma blockchain dedicada para armazenar os cabeçalhos de bloco de todas as cadeias de origem.
3. Os dados/bloco históricos são acedidos a partir de dados indexados fora da cadeia ou cache na cadeia (dependendo da complexidade do pedido) conforme solicitado pelo dapp na cadeia de destino. Enquanto o cache de um hash de cabeçalhos de bloco é mantido na cadeia, os dados reais podem ser armazenados fora da cadeia.
4. A existência de dados no bloco especificado é verificada através de provas de inclusão merkle e é gerada uma prova zk para o mesmo. Esta prova é combinada com a prova zk de indexação correta ou prova de consenso ZK e a prova é disponibilizada na cadeia para verificação sem confiança.
5. Os dapps podem então verificar esta prova na cadeia e usar os dados para executar a ação desejada. Juntamente com a verificação da prova ZK, parâmetros públicos como o número do bloco e o hash do bloco são verificados em relação ao cache de cabeçalhos de bloco mantidos na cadeia.

Alguns dos projetos que adotam esta abordagem são Heródoto, Lagrange, Axiom, Hyper Oracle, Brevis Network e nil foundation. Enquanto um esforço significativo está a ser feito para tornar as aplicações sensíveis ao estado em vários blockchains, o IBC (Inter Blockchain Communication) destaca-se como um padrão de interoperabilidade que permite aplicações como ICQ (interchain queries) e ICA (Interchain accounts). O ICQ permite que as aplicações na Cadeia A consultem o estado da cadeia B incluindo a consulta num pacote IBC simples e o ICA permite que uma cadeia de blocos controle com segurança uma conta noutra cadeia de blocos. Combiná-los pode permitir casos de uso interessantes entre cadeias. Os fornecedores de RaaS como a Saga oferecem estas funcionalidades a todas as suas cadeias de aplicações por predefinição, utilizando o IBC.

Existem muitas maneiras pelas quais as provas de armazenamento podem ser otimizadas para encontrar o equilíbrio certo entre o consumo de memória, o tempo de prova, o tempo de verificação, a eficiência computacional e a experiência do programador. O processo global pode ser amplamente dividido em 3 subprocessos principais.

• Acesso a dados
• Processamento de dados
• Geração ZK Proof para acesso e processamento de dados

Acesso aos dados: Neste subprocesso, o fornecedor de serviços acessa os cabeçalhos de bloco da cadeia de origem nativamente na camada de execução ou através da manutenção de uma cache na cadeia. Para acesso a dados entre cadeias, é necessária a verificação do consenso da cadeia de origem na cadeia de destino. Algumas das abordagens e otimizações que estão a ser adotadas incluem:

• O Blockchain Ethereum Existente: A estrutura existente da blockchain Ethereum pode ser usada para provar o valor de qualquer slot de armazenamento histórico em relação ao blockheader atual usando ZKP. Isto pode ser pensado como uma grande prova de inclusão. É a prova de que, dado um cabeçalho de bloco recente X na altura b, existe o blockheader Y que é um ancestral de X na altura b-k. Baseia-se na segurança do consenso do Ethereum e requer um sistema de prova rápida para a eficiência. Esta é a abordagem utilizada por Lagrange.
• Cache em cadeia de Merkle Mountain Ranges (MMR): Uma Cordilheira Merkle pode ser vista como uma lista de árvores Merkle onde as árvores Merkle individuais são combinadas quando duas árvores atingem o mesmo tamanho. As árvores Merkle individuais no MMR são combinadas adicionando nós pais às raízes anteriores das árvores. MMR é uma estrutura de dados semelhante às árvores Merkle com alguns benefícios adicionais, como anexação eficiente de elementos e consultas de dados eficientes, particularmente ao ler dados sequenciais de grandes conjuntos de dados. Anexar novos cabeçalhos através da árvore Merkle exigiria a passagem de todos os nós irmãos em cada nível. Para anular dados de forma eficiente, a Axiom usa MMR para manter uma cache do hash dos cabeçalhos de bloco na cadeia. O Heródoto armazena o hash raiz do acumulador de hash do bloco MMR na cadeia. Isto permite-lhes verificar os dados obtidos com estes hashes de cabeçalho de bloco através de provas de inclusão. Esta abordagem requer que a cache seja atualizada regularmente e traz preocupações animadas se não descentralizadas.
• Heródoto mantém dois MMR diferentes. Dependendo do blockchain ou camada específica, os acumuladores podem ser adaptados para utilizar diferentes funções de hash, otimizando a eficiência e os custos computacionais. Para provar na Starknet, o hash poseidon pode ser usado mas o hash Keccack pode ser usado para cadeias EVM.
• Cache MMR fora da cadeia: O Herodotus mantém um cache fora da cadeia de consultas e resultados obtidos anteriormente para permitir uma busca mais rápida caso os dados sejam solicitados novamente. Isto requer uma infra-estrutura adicional do que simplesmente executar um nó de arquivo. As otimizações feitas em infraestruturas fora da cadeia podem potencialmente diminuir os custos para o utilizador final.
• Blockchain dedicado para armazenamento: Brevis conta com um conjunto ZK dedicado (camada de agregação) para armazenar todos os cabeçalhos de bloco de todas as cadeias que atestam. Sem esta camada de agregação, cada cadeia teria de armazenar os cabeçalhos de bloco para todas as outras cadeias, resultando em “ligações” O (N2) para N blockchains. Ao introduzir uma camada de agregação, cada blockchain só precisa de armazenar a raiz do estado para o rollup, reduzindo as ligações gerais com O (N). Esta camada também é usada para agregar várias provas para cabeçalhos de bloco/resultados de consulta e uma única prova de verificação em cada blockchain conectada pode ser enviada.
• Passagem de mensagem L1-L2: A verificação do consenso da cadeia de origem pode ser evitada no caso de L2s porque os L2s suportam mensagens nativas para atualizar contratos L2 em L1. O cache pode ser atualizado no Ethereum e a passagem de mensagens L1-L2 pode ser usada para enviar o hash do bloco ou a raiz da árvore compilada fora da cadeia para outros L2s. Heródoto está a adotar esta abordagem mas isso não é viável para Alt L1s.

Processamento de dados:

Juntamente com o acesso aos dados, os contratos inteligentes também devem poder fazer cálculos arbitrários sobre os dados. Embora alguns casos de uso possam não exigir computação, é um serviço importante de valor acrescentado para muitos outros casos de uso. Muitos dos prestadores de serviços permitem cálculos nos dados, uma vez que uma prova zk do cálculo pode ser gerada e fornecida na cadeia para validade. Como as soluções AMP existentes como Axelar, LayerZero, Polyhedra Network poderiam potencialmente ser usadas para acesso a dados, o processamento de dados pode tornar-se um diferencial para os prestadores de serviços à prova de armazenamento.

O Hyper Oracle, por exemplo, permite aos programadores definir cálculos personalizados fora da cadeia com JavaScript. A Brevis projetou um mercado aberto de ZK Query Enginees que aceita consultas de dados de DApps e processa-as usando os cabeçalhos de bloco atestados. O contrato inteligente envia uma consulta de dados, que é recolhida por um provador do mercado. O Prover gera uma prova com base na entrada da consulta, cabeçalhos de bloco relevantes (da camada de agregação Brevis) e resultados. Lagrange introduziu o ZK Big Data Stack para provar modelos de programação distribuída como SQL, MapReduce e Spark/RDD. As provas são modulares e podem ser geradas a partir de qualquer cabeçalho de bloco originado de pontes de cadeia cruzada existentes e protocolos AMP. O ZK MapReduce, o primeiro produto da pilha Lagrange ZK BigData, é um motor de computação distribuído (baseado no conhecido modelo de programação MapReduce) para provar resultados de computação envolvendo conjuntos consideráveis de dados multi-cadeia. Por exemplo, uma única prova ZKMR pode ser usada para provar alterações na liquidez de um DEX implantado em 4—5 cadeias ao longo de uma janela de tempo especificada. Para consultas relativamente simples, o cálculo também pode ser feito diretamente na cadeia, como está sendo feito por Heródoto no momento.

Geração de provas:

• Provas atualizáveis: As provas atualizáveis podem ser usadas quando uma prova precisa ser calculada e mantida de forma eficiente em um fluxo móvel de blocos. Quando um dapp deseja manter uma prova de uma média móvel para uma variável de contrato (como o preço do token), à medida que novos blocos estão a ser criados, sem recalcular a nova prova a partir do zero, as provas existentes podem ser atualizadas de forma eficiente. Para provar a computação dinâmica paralela de dados num estado em cadeia, o Lagrange constrói um compromisso de vetor em lote, chamado Recproof, em cima de uma parte do MPT, atualiza-o em tempo real e calcula dinamicamente sobre ele. Ao criar recursivamente uma árvore Verkle no topo do MPT, o Lagrange é capaz de calcular grandes quantidades de dados dinâmicos de estado na cadeia de forma eficiente.
• Árvores Verkle: Ao contrário das árvores Merkle, onde precisamos fornecer todos os nós que compartilham um dos pais, as Árvores Verkle requerem apenas o caminho para a raiz. Este caminho é muito menor em comparação com todos os nós irmãos no caso da árvore Merkle. O Ethereum também está a explorar o uso de árvores Verkle em lançamentos futuros para minimizar a quantidade de estado que os nós completos do Ethereum são obrigados a manter. Brevis aproveita o Verkle Tree para armazenar cabeçalhos de bloco atestados e resultados de consulta na camada de agregação. Reduz significativamente o tamanho da prova de inclusão de dados, especialmente quando a árvore contém um grande número de elementos, e também suporta prova de inclusão eficiente para um lote de dados.
• Monitorização de Mempool para geração de provas mais rápida: Heródoto anunciou recentemente o turbo, que permite aos programadores adicionar algumas linhas de código ao seu código de contrato inteligente para especificar a consulta de dados. O Heródoto monitoriza o mempool para transações de contratos inteligentes que interagem com o contrato turbo. O processo de geração de provas começa quando a transação está no próprio mempool. Uma vez que a prova é gerada e verificada na cadeia, os resultados são inscritos no contrato de troca turbo na cadeia. Os resultados só podem ser gravados no contrato de troca turbo depois de autenticados por provas de armazenamento. Quando isto acontecer, uma parte das taxas de transação é partilhada com o sequenciador ou construtor de blocos, incentivando-os a esperar um pouco mais para cobrar as taxas. Para consultas de dados simples, é possível que os dados solicitados sejam disponibilizados na cadeia antes que a transação do utilizador seja incluída no bloco.

Aplicação de provas de estado/armazenamento

As provas de estado e armazenamento podem desbloquear muitos novos casos de utilização para contratos inteligentes na camada de aplicação, middleware e infra-estrutura. Alguns destes são:

Camada de aplicação:

Governança:

• Votação entre cadeias: Um protocolo de votação em cadeia pode permitir que os utilizadores da Cadeia B provem a propriedade dos ativos na Cadeia A. Os utilizadores não terão de ligar os seus ativos para ganhar poder de voto numa nova cadeia. Exemplo: SnapshotX em Heródoto
• Distribuição de tokens de governança: As aplicações podem distribuir mais tokens de governança a utilizadores ativos ou a adoptadores iniciais. Exemplo: RetroPGFem Lagrange

Identidade e Reputação:

• Prova de propriedade: Um utilizador pode fornecer prova de propriedade de um determinado NFT, SBT ou ativos na cadeia A, permitindo-lhes realizar determinadas ações na Cadeia B. Por exemplo, uma cadeia de aplicação de jogos pode decidir lançar a sua coleção NFT noutra cadeia com liquidez existente como Ethereum ou qualquer L2. Isto permitirá ao jogo explorar a liquidez que existe noutro lugar e ligar o utilitário NFT sem realmente exigir que os NFTs sejam interligados.
• Prova de utilização: Os utilizadores podem receber descontos ou funcionalidades premium com base na sua utilização histórica da plataforma (provar que o volume X negociado pelo utilizador no Uniswap)
• Prova de OG: Um utilizador pode provar que possui uma conta ativa com mais de X dias
• Pontuação de crédito em cadeia: Uma plataforma de pontuação de crédito multicadeias pode agregar dados de várias contas de um único utilizador para gerar uma pontuação de crédito

Todas as provas acima podem ser utilizadas para fornecer uma experiência personalizada aos utilizadores. Os Dapps podem oferecer descontos ou privilégios para reter comerciantes ou utilizadores experientes e oferecer uma experiência de utilizador simplificada para utilizadores novatos.

Defina:

• Empréstimos entre cadeias: Os utilizadores podem bloquear ativos na Cadeia A e contrair um empréstimo na Cadeia B em vez de fazer a ponte entre os tokens
• Seguro em cadeia: As falhas podem ser determinadas acessando dados históricos na cadeia e o seguro pode ser liquidado totalmente na cadeia.
• TWAP do preço do activo num pool: Uma aplicação poderia calcular e buscar o preço médio de um activo num pool AMM durante um período de tempo especificado. Exemplo: Uniswap TWAP Oraclecom Axiom
• Preços de opções: um protocolo de opções em cadeia pode precificar uma opção usando a volatilidade de um ativo nos últimos n blocos numa bolsa descentralizada.

Os dois últimos casos de uso exigirão que a prova seja atualizada sempre que um novo bloco for adicionado à cadeia de origem.

Middleware:

• Intenções: As provas de armazenamento permitirão que os utilizadores sejam mais articulados e claros com as suas intenções. Embora seja o trabalho dos solucionadores executar as etapas necessárias para cumprir a intenção do utilizador, um utilizador pode especificar mais claramente as condições com base nos dados e parâmetros na cadeia. Os solucionadores também podem provar a validade dos dados em cadeia aproveitados para encontrar a solução ideal.
• Abstração da conta: Os utilizadores podem confiar em dados provenientes de outras cadeias usando provas de armazenamento para definir regras através da Abstração da Conta. Exemplo: Cada carteira tem um nonce. Podemos provar que há um ano, o nonce era um número específico, e atualmente o nonce é o mesmo. Isso pode ser usado para provar que esta carteira não foi usada de todo e o acesso à carteira pode então ser delegado a outra carteira.
• Automação em cadeia: Os contratos inteligentes podem automatizar certas ações com base em condições predefinidas que dependem dos dados na cadeia. Os programas automatizados são obrigados a chamar contratos inteligentes em determinados intervalos para manter o fluxo de preços ideal do AMM ou para manter os protocolos de empréstimo saudáveis, evitando o crédito incobrável. O Hyper Oracle permite a automação juntamente com o acesso a dados em cadeia.

Infraestrutura

• Oracle em cadeia sem confiança: Redes oracle descentralizadas agregam respostas de vários nós oracle individuais dentro de uma rede oracle. A Oracle Networks pode eliminar esta redundância e alavancar a segurança criptográfica para dados em cadeia. A rede Oracle poderia ingerir dados de várias cadeias (L1s, L2s e Alt L1s) numa única cadeia e simplesmente provar a existência usando provas de armazenamento noutro lugar. As soluções DeFii com tração significativa também podem funcionar numa solução personalizada. Por exemplo, a Lido Finance, o maior fornecedor de liquidez staking, juntou-se à Nil Foundation, para financiar o desenvolvimento do ZKoracle. As soluções permitirão o acesso a dados fidedignos a dados históricos in-EVM e garantirão $15 mil milhões em liquidez Ethereum apostada no Lido Finance.
• Protocolos AMP: As soluções AMP existentes podem aumentar a expressividade das suas mensagens através da parceria com prestadores de serviços à prova de armazenamento. Esta é uma abordagem sugerida por Lagrange no seu artigo Modular Thesis.

Conclusão

A sensibilização capacita as empresas de tecnologia a servirem melhor os seus clientes. Da identidade do utilizador ao comportamento de compra aos gráficos sociais, as empresas de tecnologia aproveitam a consciência para desbloquear capacidades como segmentação de precisão, segmentação de clientes e marketing viral. As empresas de tecnologia tradicionais precisam de permissão explícita dos seus utilizadores e têm de ter cuidado ao gerir os dados do utilizador. No entanto, todos os dados do utilizador em blockchains sem permissão estão disponíveis publicamente sem revelar necessariamente a identidade do utilizador. Os contratos inteligentes devem poder alavancar os dados publicamente disponíveis para melhor servir os utilizadores. O desenvolvimento e a adoção de ecossistemas mais especializados farão da sensibilização do estado ao longo do tempo e das blockchains um problema cada vez mais importante a ser resolvido. As provas de armazenamento podem permitir que o Ethereum surja como uma camada de identidade e propriedade de ativos, além de ser uma camada de liquidação. Os utilizadores podem manter a sua identidade e activos chave no Ethereum que poderiam ser usados em várias cadeias de blocos sem fazer a ponte entre ativos o tempo todo. Continuamos entusiasmados com as novas possibilidades e casos de utilização que serão desbloqueados no futuro.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [medium]. Todos os direitos de autor pertencem ao autor original [LongHash Ventures]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.