Encaminhar o Título Original: Decifrando o modelo de contrato inteligente Starknet e o AA nativo: o gênio técnico solitário

Autores Originais: Shew & Faust, Consultores Web3: CryptoNerdCn, Desenvolvedor Principal do Starknet, Plataforma de Desenvolvimento Cairo no Navegador Fundador do WASM Cairo

Resumo:

As principais características tecnológicas do Starknet incluem a linguagem Cairo, que é propícia para gerar provas ZK, AA em nível nativo e um modelo de contrato inteligente onde a lógica de negócios é independente do armazenamento de estado. Cairo é uma linguagem ZK versátil que pode ser usada para implementar contratos inteligentes no Starknet, bem como desenvolver aplicações com inclinações tradicionais. Seu processo de compilação introduz Sierra como uma linguagem intermediária, permitindo iterações frequentes do Cairo sem alterar diretamente o bytecode subjacente. Além disso, a biblioteca padrão do Cairo inclui muitas estruturas de dados básicas necessárias para a abstração de contas. Os contratos inteligentes do Starknet separam a lógica de negócios do armazenamento de dados de estado, ao contrário das cadeias EVM. A implantação de contratos Cairo envolve três etapas: compilação, declaração e implantação, onde a lógica de negócios é declarada em uma classe de Contrato. As instâncias de contratos contendo dados de estado podem ser associadas à classe e chamar o código que ele contém.

O modelo de contrato inteligente acima mencionado do Starknet é propício para reutilização de código, reutilização de estado de contrato, camadas de armazenamento e detecção de contratos inúteis. Também é propício para a realização de arrendamento de armazenamento e paralelização de transações. Embora os dois últimos ainda não tenham sido implementados, a estrutura dos contratos inteligentes de Cairo criou condições necessárias para eles. ·Existem apenas contas de contrato inteligente na cadeia Starknet e nenhuma conta EOA. Ele suporta a abstração de conta AA de nível nativo desde o início. Seu plano AA incorpora as ideias do ERC-4337 em certa medida, permitindo aos usuários escolher soluções de processamento de transações altamente personalizadas. Para prevenir cenários de ataque potenciais, o Starknet tomou muitas contramedidas e fez importantes explorações no ecossistema AA.

texto: Após a emissão de tokens na Starknet, o STRK gradualmente se tornou um elemento indispensável aos olhos dos observadores do Ethereum. Esta estrela da Camada 2 do Ethereum, conhecida por sua atitude "independente" e "desconsiderando a experiência do usuário", silenciosamente esculpiu seu próprio território no florescente ecossistema da Camada 2 compatível com EVM. Devido à sua negligência excessiva com os usuários, e até mesmo criando abertamente um canal de "mendigo eletrônico" no Discord, Starknet já foi criticado pela comunidade. Em meio a acusações de ser "desumano", sua profunda experiência técnica pareceu instantaneamente desvalorizada, como se apenas UX e criação de riqueza fossem tudo. A frase de "O Templo do Pavilhão Dourado" - "o facto de não ser compreendido pelos outros tinha sido a minha única fonte de orgulho" - é quase um autorretrato de Starknet. No entanto, deixando de lado essas questões triviais do mundo, puramente baseadas no gosto técnico dos geeks de código, Starknet e StarkEx, como pioneiros do ZK Rollup, são quase tesouros aos olhos dos entusiastas do Cairo. Na mente de alguns desenvolvedores de jogos blockchain, Starknet e Cairo são simplesmente tudo na Web3, superando Solidity e Move. A maior lacuna entre "geeks técnicos" e "usuários" hoje é, na verdade, em grande parte atribuída à falta de compreensão das pessoas sobre a Starknet. Impulsionado por um interesse na tecnologia blockchain e na exploração do valor da Starknet, o autor deste artigo parte do modelo de contrato inteligente da Starknet e AA nativo para descrever brevemente suas soluções técnicas e projetos de mecanismos, com o objetivo de mostrar as características técnicas da Starknet para mais pessoas, enquanto também espera ajudar as pessoas a entender esse "ranger solitário incompreendido". Após uma breve introdução à linguagem do Cairo na seção subsequente, nos concentraremos em discutir o modelo de contrato inteligente da Starknet e a abstração de conta nativa, explicando como a Starknet alcança AA nativo. Depois de ler este artigo, os leitores também entenderão por que frases mnemônicas de diferentes carteiras não podem ser misturadas na Starknet. Mas antes de introduzir a abstração de conta nativa, vamos primeiro entender a inovadora linguagem do Cairo criada pela Starknet. No processo de desenvolvimento do Cairo, houve versões iniciais chamadas Cairo0, seguidas pela versão moderna. A sintaxe geral da versão moderna do Cairo é semelhante a Rust e é na verdade uma linguagem ZK versátil. Além de ser usado para escrever contratos inteligentes na Starknet, também pode ser usado para o desenvolvimento de aplicações gerais. Por exemplo, podemos desenvolver um sistema de verificação de identidade ZK usando a linguagem Cairo, e este programa pode ser executado em nosso próprio servidor sem depender da rede StarkNet. Pode-se dizer que qualquer programa que exija propriedades computacionais verificáveis pode ser implementado usando a linguagem Cairo. E o Cairo pode ser atualmente a linguagem de programação mais propícia para gerar provas ZK.

Do ponto de vista do processo de compilação, o Cairo utiliza um método de compilação baseado em linguagem intermédia, como mostrado na figura abaixo. Sierra na imagem é uma representação intermédia (RI) no processo de compilação da linguagem Cairo, e Sierra será compilado numa representação de código binário de nível inferior, chamado CASM, que é executado diretamente no dispositivo de nó Starknet.

A introdução da Sierra como uma representação intermediária torna mais fácil para a linguagem Cairo adicionar novas funcionalidades. Em muitos casos, apenas é necessário manipular a linguagem intermediária Sierra sem alterar diretamente o código CASM subjacente. Isto poupa muito trabalho, e o cliente de nó do Starknet não precisa de ser atualizado com frequência. Desta forma, é possível alcançar iterações frequentes da linguagem Cairo sem alterar a lógica subjacente do StarkNet. A biblioteca padrão do Cairo também inclui muitas estruturas de dados básicas necessárias para a abstração de contas. Outras inovações do Cairo incluem uma solução teórica chamada Cairo Native, que planeia compilar o Cairo em código de máquina de baixo nível que pode adaptar-se a diferentes dispositivos de hardware. Os nós do Starknet não terão de depender da máquina virtual CairoVM ao executar contratos inteligentes. Isto pode melhorar significativamente a velocidade de execução do código [ainda está na fase teórica e ainda não foi implementado].

Modelo de contrato inteligente Starknet: removendo lógica de código e armazenamento de estado

Ao contrário das cadeias compatíveis com Ethereum, Starknet fez inovações revolucionárias no design do seu sistema de contrato inteligente, em grande parte em preparação para AA nativas e funcionalidades futuras como processamento de transações paralelas. Aqui, é importante entender que, ao contrário das cadeias públicas tradicionais como Ethereum, a implementação de contratos inteligentes em Starknet segue um processo diferente. Vamos pegar o exemplo da implementação de um contrato inteligente Ethereum:

1. Os desenvolvedores escrevem o código do contrato inteligente localmente e compilam o programa Solidity em bytecode EVM usando um editor. Este bytecode pode então ser compreendido e processado diretamente pelo EVM.

1. O desenvolvedor inicia uma transação para implantar o contrato inteligente, implantando o bytecode EVM compilado na cadeia Ethereum.

Fonte: not-satoshi.com

Embora os contratos inteligentes da Starknet também sigam a ideia de "compilar primeiro e depois implantar", os contratos inteligentes são implantados na cadeia na forma de bytecode CASM suportado pelo CairoVM. No entanto, existem enormes diferenças entre a Starknet e as cadeias compatíveis com EVM no método de chamada e modo de armazenamento de estado dos contratos inteligentes. Exatamente, contrato inteligente do Ethereum = lógica de negócios + informações de estado. Por exemplo, o contrato USDT não apenas implementa funções comuns como Transfer e Approval, mas também armazena o status de ativos de todos os detentores de USDT. Código e estado estão acoplados, o que traz muitos problemas. Em primeiro lugar, não é propício para a atualização do contrato DAPP e migração de estado, nem propício para o processamento paralelo de transações. É um grande fardo técnico.

Em resposta a isso, a Starknet melhorou a forma como o estado é armazenado. Em sua solução de implementação de contrato inteligente, a lógica de negócios do DApps é completamente dissociada dos estados dos ativos e armazenada separadamente. Os benefícios dessa abordagem são evidentes: em primeiro lugar, ela permite que o sistema distinga rapidamente se há implantações de código duplicadas ou redundantes. Veja como funciona: no Ethereum, um contrato inteligente compreende a lógica de negócios e os dados de estado. Se vários contratos tiverem lógica de negócios idêntica, mas dados de estado diferentes, seus hashes também serão diferentes, tornando difícil para o sistema determinar se "contratos de lixo" existem. No entanto, na solução da Starknet, os dados de código e estado são separados, tornando mais fácil para o sistema detetar se o mesmo código foi implantado várias vezes com base no hash da parte do código. Isso ajuda a evitar a implantação de código duplicado e economiza espaço de armazenamento nos nós Starknet.

No sistema de contratos inteligentes da Starknet, a implantação e o uso de contratos são divididos em três etapas: "compilar, declarar e implantar". Se um emissor de ativos quiser implantar um contrato do Cairo, ele primeiro compilará o código escrito do Cairo no Sierra e formulários CASM de bytecode de nível inferior em seu dispositivo local. Em seguida, o implantador de contrato publica uma transação de "declaração", implantando o código de bytes CASM do contrato e o código intermediário Sierra na cadeia, chamada de Classe de Contrato.

(Fonte: site oficial da Starknet)

Mais tarde, se desejar utilizar as capacidades de função definidas no contrato de ativos, pode iniciar uma transação de “implementação” através do front-end da DApp para implementar uma instância de Contrato associada à Classe de Contrato. Essa instância irá manter o estado do ativo. Posteriormente, os utilizadores podem chamar as funções dentro da Classe de Contrato para modificar o estado da instância de Contrato. Na verdade, qualquer pessoa familiarizada com programação orientada a objetos deve compreender facilmente o que Classe e Instância representam no Starknet. A Classe de Contrato declarada pelos programadores contém apenas a lógica de negócio do contrato inteligente, compreendendo funções que qualquer pessoa pode chamar, mas não tem estado de ativo real, não implementando diretamente “entidades de ativo,” tendo apenas a “alma” sem o “corpo.” No entanto, quando os utilizadores implementam instâncias específicas de Contrato, os ativos são “materializados.” Se precisar de modificar o estado da “entidade” de ativo, como transferir os seus tokens para outra pessoa, pode chamar diretamente as funções escritas na Classe de Contrato. O processo acima é algo semelhante à “instanciação” em linguagens de programação orientadas a objetos tradicionais (embora não seja totalmente idêntico).

Após os contratos inteligentes serem separados em classes e instâncias, a lógica de negócios e os dados de status são desacoplados, trazendo as seguintes características para a Starknet:

1. Propício para a realização da segmentação de armazenamento e do sistema de 'leasing' de armazenamento

A chamada camada de armazenamento significa que os desenvolvedores podem colocar dados em locais personalizados de acordo com suas próprias necessidades, como sob a cadeia Starknet. A StarkNet está pronta para ser compatível com camadas DA como Celestia, e os desenvolvedores de DAPP podem armazenar dados nessas camadas DA de terceiros. Por exemplo, um jogo pode armazenar seus dados de ativos mais importantes na mainnet Starknet e armazenar outros dados em camadas DA off-chain como Celestia. Essa solução de personalização da camada DA de acordo com os requisitos de segurança foi denominada 'Volition' pela Starknet.

O chamado sistema de aluguer de armazenamento significa que todos devem continuar a pagar pelo espaço de armazenamento que ocupam. Por muito espaço na cadeia que ocupem, teoricamente devem continuar a pagar renda.

No modelo de contrato inteligente Ethereum, a propriedade do contrato não é clara e é difícil distinguir se o implementador ou o detentor do ativo deve pagar 'aluguel' por um contrato ERC-20. A função de locação de armazenamento não foi lançada por muito tempo e o implementador só é cobrado uma taxa quando o contrato é implementado. Esse modelo de taxa de armazenamento é irracional.

Nos modelos de contratos inteligentes da Starknet, Sui, CKB e Solana, a propriedade dos contratos inteligentes é mais claramente dividida, tornando mais fácil coletar fundos de armazenamento [Atualmente, a Starknet não lança diretamente um sistema de aluguel de armazenamento, mas será implementado no futuro]

1. Alcance a verdadeira reutilização de código e reduza a implantação de contratos inúteis

Podemos declarar um contrato de token geral para ser armazenado na cadeia como uma classe e, em seguida, todos podem chamar as funções nesta classe para implantar suas instâncias de token. Além disso, o contrato também pode chamar diretamente o código na classe, o que alcança um efeito semelhante à função de biblioteca na Solidity. Ao mesmo tempo, o modelo de contrato inteligente da Starknet ajuda a identificar os "contratos lixo". Isso foi explicado anteriormente. Após o suporte à reutilização de código e à detecção de contratos lixo, a Starknet pode reduzir significativamente a quantidade de dados enviados para a cadeia e reduzir a pressão de armazenamento nos nós o máximo possível.

1. Reutilização do verdadeiro estado do "contrato"

As atualizações de contrato na blockchain envolvem principalmente alterações na lógica de negócios. No cenário Starknet, a lógica de negócios dos contratos inteligentes está separada intrinsecamente do status do ativo. Se a instância do contrato alterar a classe do tipo de contrato associado, a atualização da lógica de negócios pode ser concluída. Não é necessário migrar o status do ativo para um novo local. Esta forma de atualização de contrato é mais completa e nativa do que a do Ethereum.

Para alterar a lógica de negócios de um contrato Ethereum, muitas vezes é necessário "externalizar" a lógica de negócios para um contrato de agência e alterar a lógica de negócios do contrato principal alterando o contrato de agência dependente. No entanto, este método não é suficientemente conciso e não é "nativo".

Origem: Academia wtf

Em alguns cenários, se o antigo contrato Ethereum for completamente abandonado, o status do ativo dentro não pode ser migrado diretamente para o novo lugar, o que é muito problemático; o contrato do Cairo não precisa migrar o status e pode "reutilizar" diretamente o status antigo.

1. Propício ao processamento paralelo de transações

Para maximizar o paralelismo de diferentes instruções comerciais, um passo necessário é armazenar o status do ativo de diferentes pessoas em locais separados, como pode ser visto no Bitcoin, CKB e Sui. O pré- -requisito para o objetivo acima é separar a lógica de negócios dos contratos inteligentes dos dados de status do ativo. Embora o Starknet ainda não tenha realizado uma implementação técnica aprofundada de transações paralelas, considerará as transações paralelas como um objetivo importante no futuro.

Implementação de contrato nativo AA e de conta do Starknet

Na verdade, o conceito de abstração de conta (AA) e EOA (contas de propriedade externa) foi inventado pela comunidade Ethereum como um conceito único. Em muitas novas cadeias públicas, não há distinção entre contas EOA e contas de contratos inteligentes, evitando as armadilhas do sistema de contas do estilo Ethereum desde o início. Por exemplo, sob a configuração do Ethereum, o controlador da conta EOA deve ter ETH na cadeia antes de poder iniciar uma transação. Não há maneira de escolher diretamente uma variedade de métodos de autenticação, e é extremamente problemático adicionar alguma lógica de pagamento personalizada. Algumas pessoas até pensam que o design de conta do Ethereum é simplesmente anti-humano.

Se olharmos para produtos principais como Starknet ou a cadeia “Native AA” do zkSyncEra, obviamente podem ser observadas diferenças: em primeiro lugar, o Starknet e o zkSyncEra têm tipos de conta unificados. Existem apenas contas de contratos inteligentes na cadeia. Não existe tal coisa como uma conta EOA desde o início. (A Era zkSync irá implementar um conjunto de códigos de contrato por defeito na conta recém-criada do utilizador para simular as características da conta EOA do Ethereum, de forma a ser compatível com o Metamask).

No entanto, o Starknet não considera diretamente a compatibilidade com periféricos Ethereum como o Metamask. Quando os utilizadores utilizam a carteira Starknet pela primeira vez, é automaticamente implementada uma conta de contrato dedicada. Em outras palavras, a instância de contrato previamente mencionada é implementada, e esta instância está associada à classe de contrato implementada antecipadamente pelo projeto da carteira. Os utilizadores podem chamar diretamente algumas das funcionalidades escritas na classe. Agora, vamos aprofundar um tópico interessante: ao reivindicar airdrops STRK, muitas pessoas descobriram que as carteiras Argent e Braavos não eram compatíveis entre si. Importar o mnemônico do Argent para o Braavos não permitiu exportar a conta correspondente, principalmente devido aos diferentes algoritmos de geração de contas utilizados pelo Argent e Braavos, resultando em diferentes endereços de conta gerados a partir do mesmo mnemônico. Especificamente, no Starknet, o endereço do contrato recém-implementado pode ser derivado através de um algoritmo determinístico, conforme segue:

A função 'pedersen()' mencionada acima é um algoritmo de hash que é fácil de usar em sistemas ZK. O processo de geração da conta envolve a introdução de vários parâmetros especiais na função pedersen para gerar o hash correspondente, que é o endereço da conta gerada. A imagem acima mostra os parâmetros usados pelo Starknet para gerar o 'novo endereço do contrato'. O 'deployer_address' representa o endereço do 'implementador do contrato'. Este parâmetro pode estar vazio, o que significa que mesmo que não tenha uma conta de contrato Starknet antecipadamente, ainda pode implementar um novo contrato. O 'salt' é o valor de salt utilizado para calcular o endereço do contrato, que é essencialmente um número aleatório introduzido para evitar endereços de contrato duplicados. O 'class_hash' corresponde ao valor de hash da classe mencionada anteriormente, com a qual a instância do contrato está associada. O 'constructor_calldata_hash' representa o hash dos parâmetros de inicialização do contrato.

Com base na fórmula acima, os usuários podem calcular o endereço do contrato gerado antes de implantar o contrato na cadeia. Starknet permite que os usuários implantem contratos diretamente sem ter uma conta Starknet antecipadamente, conforme a seguir:

1. Os utilizadores determinam primeiro a instância do contrato que pretendem implementar e qual a classe de contrato a associar a ela, utilizando o hash da classe como um dos parâmetros de inicialização, e calculam o salt para determinar o endereço do contrato gerado.
2. Depois de saberem onde vão implementar o contrato, os utilizadores transferem primeiro uma certa quantidade de ETH para esse endereço como taxa de implementação do contrato. Geralmente, este ETH precisa de ser transferido de L1 para a rede Starknet através de uma ponte intercadeias.
3. Os utilizadores iniciam o pedido de transação para implementação de contrato.

Na verdade, todas as contas Starknet são implementadas através do processo acima, mas a maioria das carteiras protege os detalhes, e os usuários não percebem o processo como a implementação da sua conta de contrato assim que transferem ETH.

A solução acima trouxe alguns problemas de compatibilidade, porque quando diferentes carteiras geram endereços de conta, os resultados gerados são inconsistentes. Apenas as carteiras que atendem às seguintes condições podem ser combinadas:

1. A chave pública derivada da chave privada usada pela carteira é a mesma que o algoritmo de assinatura;
2. O processo de cálculo do sal da carteira é o mesmo;
3. As classes dos contratos inteligentes da carteira não são fundamentalmente diferentes nos detalhes de implementação; \

No caso mencionado anteriormente, tanto Argent como Braavos usaram o algoritmo de assinatura ECDSA, mas os métodos de cálculo para o salt eram diferentes entre os dois, resultando em endereços de conta inconsistentes gerados a partir do mesmo mnemônico.

Agora, vamos revisitar o tópico da abstração de contas. Starknet e zkSync Era moveram uma série de processos envolvidos no processamento de transações, como verificação de identidade (verificação de assinaturas digitais) e pagamento de taxas de gás, para fora da “camada de cadeia.” Os usuários podem personalizar os detalhes de implementação da lógica acima em suas próprias contas. Por exemplo, você pode implantar uma função dedicada de verificação de assinatura digital em sua conta de contrato inteligente Starknet. Quando um nó Starknet recebe uma transação iniciada por você, ele chamará uma série de lógica de processamento de transação personalizada por você na cadeia.

Esta abordagem claramente oferece mais flexibilidade. No design do Ethereum, no entanto, a lógica como a verificação de identidade (assinaturas digitais) está codificada no código do cliente do nó e não pode suportar nativamente funcionalidades de conta personalizáveis.

Diagrama esquemático da solução nativa AA especificada pelo arquiteto Starknet. A verificação da transação e a verificação da qualificação da taxa de gás são transferidas para o contrato on-chain para processamento. A máquina virtual subjacente da cadeia pode chamar essas funções personalizadas ou especificadas pelo usuário.

Segundo os funcionários da zkSyncEra e da Starknet, este enfoque modular para a funcionalidade da conta é inspirado no EIP-4337. No entanto, o que os distingue é que a zkSync e a Starknet fundiram tipos de conta desde o início, unificaram tipos de transação e utilizaram um único ponto de entrada para receber e processar todas as transações. Em contraste, o Ethereum, devido ao seu peso histórico e ao desejo da fundação de evitar estratégias de iteração agressivas, como hard forks, tanto quanto possível, suportou o EIP-4337, utilizando uma abordagem diferente para resolver o problema. No entanto, o resultado é que as contas EOA e as soluções do EIP-4337 têm fluxos de processamento de transações independentes, o que parece desajeitado e complicado, ao contrário da agilidade das AAs nativas.

Origem: ArgentWallet

No entanto, a abstração de conta nativa no Starknet ainda não atingiu plena maturidade. Do ponto de vista prático, embora as contas AA do Starknet tenham implementado algoritmos de verificação de assinatura personalizados, atualmente apenas suportam o pagamento de taxas de gás em ETH e STRK e ainda não suportam o pagamento de gás por terceiros. Portanto, o progresso do Starknet em AA nativas pode ser descrito como 'a estrutura teórica está em grande parte madura, enquanto a implementação prática ainda está em andamento'. Como o Starknet só possui contas de contrato inteligente internamente, todo o processo de suas transações leva em consideração a influência dos contratos inteligentes de conta. Primeiro, após uma transação ser recebida pela mempool (Mempool) do nó Starknet, ela passa por verificação, que inclui:

1. Verificando se a assinatura digital da transação está correta, momento em que a função de verificação personalizada da conta do signatário é chamada;
2. Verificar se o saldo da conta do iniciador pode cobrir a taxa de gás. \

Deve ser notado aqui que o uso da função de verificação de assinatura personalizada no contrato inteligente da conta significa que há um cenário de ataque. Porque a memória não cobra taxas de gás ao verificar a assinatura de novas transações. (Se as taxas de gás forem cobradas diretamente, ocorrerão cenários de ataque mais sérios). Usuários maliciosos podem primeiro personalizar uma função de verificação de assinatura super complexa em seu contrato de conta e, em seguida, iniciar um grande número de transações. Quando essas transações são verificadas, elas chamarão a função de verificação de assinatura complexa personalizada, o que pode esgotar diretamente os recursos de computação do nó. Para evitar essa situação, a StarkNet impõe as seguintes restrições às transações:

1. Existe um limite superior no número de transações que um único utilizador pode iniciar dentro de um período de tempo unitário;
2. A função de verificação de assinatura personalizada no contrato de conta da Starknet tem limitações de complexidade, e funções de verificação de assinatura excessivamente complexas não serão executadas. A Starknet limita o limite de consumo de gás da função de verificação de assinatura. Se a quantidade de gás consumida pela função de verificação de assinatura for muito alta, a transação será diretamente rejeitada. Ao mesmo tempo, não é permitido que a função de verificação de assinatura no contrato de conta chame outros contratos.

O fluxograma das transações do Starknet é o seguinte:

Vale a pena notar que, para agilizar ainda mais o processo de verificação de transações, o cliente do nó Starknet implementou diretamente os algoritmos de verificação de assinatura das carteiras Braavos e Argent. Quando um nó deteta transações geradas a partir dessas duas principais carteiras Starknet convencionais, ele chamará os algoritmos de assinatura Braavos/Argent integrados no cliente. Através dessa abordagem semelhante ao cache, a Starknet pode reduzir o tempo de verificação da transação. Depois que os dados da transação são validados pelo sequenciador (as etapas de verificação do sequenciador são muito mais completas do que as do pool de memória), o sequenciador empacotará e enviará as transações do pool de memória para o gerador de prova ZK. Nas transações que entrarem nesta fase serão cobradas taxas de gás, mesmo que falhem. No entanto, se os leitores estiverem familiarizados com a história da Starknet, notarão que as versões anteriores da Starknet não cobravam taxas por transações falhadas. O cenário mais comum para falha de transação é quando um usuário tem apenas 1 ETH, mas tenta transferir 10 ETH externamente, o que indica claramente um erro de lógica e inevitavelmente falhará, mas ninguém sabe o resultado antes da execução. No entanto, no passado, a StarkNet não cobrava taxas por essas transações falhadas. Essas transações errôneas e sem custos desperdiçam recursos computacionais do nó Starknet e podem levar a cenários de ataque DDoS. À primeira vista, cobrar taxas por transações erradas parece simples, mas, na realidade, é bastante complexo. A Starknet introduziu uma nova versão da língua Cairo1 em grande parte para abordar a questão das taxas de gás para transações fracassadas. Como todos sabemos, uma prova ZK é uma prova de validade, e o resultado de uma transação com falha é inválido e não pode deixar um resultado de saída na cadeia. Tentar usar uma prova de validade para provar que uma determinada execução de instrução é inválida e não pode produzir resultados de saída soa estranho e é realmente inviável. Portanto, no passado, a Starknet excluía transações com falha que não podiam produzir resultados de saída ao gerar provas. Mais tarde, a equipe da Starknet adotou uma solução mais inteligente e construiu uma nova linguagem de contrato, Cairo1, que garante que "todas as instruções de transação possam produzir resultados de saída e estar on-chain". À primeira vista, o fato de que todas as transações podem produzir resultados de saída significa que erros lógicos nunca ocorrem. No entanto, na maioria das vezes, as transações falham porque encontram bugs que interrompem a execução da instrução. Garantir que as transações nunca interrompam e produzam resultados de saída com sucesso é difícil de alcançar, mas na verdade existe uma solução alternativa simples, que é permitir que as transações produzam resultados de saída ao encontrar erros de lógica que levam a interrupções, embora retorne um valor Falso indicando que a execução da transação não foi suave. É importante notar que retornar um valor False também retorna um resultado de saída, o que significa que no Cairo1, independentemente de uma instrução encontrar um erro de lógica ou ser temporariamente interrompida, ela pode produzir resultados de saída e estar on-chain. Esse resultado de saída pode estar correto ou uma mensagem de erro False. Por exemplo, considere o seguinte trecho de código:

Neste ponto, _balances::read(from) - amount pode causar um erro de subfluxo, resultando na instrução de transação correspondente sendo interrompida e parada sem deixar um resultado de transação na cadeia. No entanto, se for reescrito na forma seguinte, ainda retorna um resultado de saída quando a transação falha, deixando-a na cadeia. Puramente de um ponto de vista estético, parece que todas as transações podem deixar suavemente resultados de transação na cadeia, tornando a coleta uniforme de taxas particularmente razoável.

Visão geral do contrato StarknetAA

Tendo em consideração que alguns leitores deste artigo possam ter formação em programação, aqui está uma breve demonstração da interface do contrato abstrato da conta em Starknet:

O validar_declarara interface mencionada acima é usada para validar transações de declaração iniciadas pelos utilizadores, enquanto validaré usado para validação geral da transação, verificando principalmente a correção da assinatura do usuário. Por outro lado, executar é usado para execução da transação. Notavelmente, as contas de contrato do Starknet suportam intrinsecamente multicall, permitindo a realização de várias chamadas. A funcionalidade de multicall pode facilitar várias funcionalidades interessantes, como agrupar as três transações a seguir ao interagir com certos protocolos DeFi:

1. Autorizando tokens para o contrato DeFi na primeira transação.
2. Desencadeando a lógica do contrato DeFi na segunda transação.
3. Revogar a autorização para o contrato DeFi na terceira transação.

Claro, devido à atomicidade do multicall, existem casos de uso mais complexos, como a execução de negociações de arbitragem.

Resumo

As principais características tecnológicas do Starknet incluem a linguagem Cairo otimizada para a geração de provas ZK, a abstração de contas a nível nativo e o modelo de contrato inteligente que separa a lógica de negócios do armazenamento de estado.

Cairo é uma linguagem ZK versátil que pode ser usada para contratos inteligentes na Starknet, bem como para desenvolver aplicações mais tradicionais. O seu processo de compilação introduz a Sierra como uma linguagem intermédia, permitindo que o Cairo itere frequentemente sem alterar o bytecode subjacente, apenas propagando alterações para a linguagem intermédia. A biblioteca padrão do Cairo também inclui muitas estruturas de dados básicas necessárias para abstração de contas.

Os contratos inteligentes da Starknet separam a lógica de negócios do armazenamento de dados de estado, ao contrário das cadeias EVM. A implantação do contrato no Cairo envolve três etapas: compilação, declaração e implantação. A lógica de negócios é declarada em classes de contrato, e instâncias de contrato contendo dados de estado podem ser associadas a uma classe e chamar o código que ela contém.

O modelo de contrato inteligente da Starknet facilita a reutilização de código, a reutilização de estado de contrato, a camada de armazenamento e a detecção de contratos de lixo. Também facilita a implementação de arrendamento de armazenamento e paralelização de transações, embora esses recursos ainda não tenham sido totalmente implementados. A arquitetura de contratos inteligentes de Cairo cria condições necessárias para esses recursos.

Starknet possui apenas contas de contrato inteligente, sem contas EOA, e suporta abstração de contas AA ao nível nativo desde o início. A sua solução AA absorve parcialmente as ideias do ERC-4337, permitindo aos utilizadores escolher soluções de processamento de transações altamente personalizadas. Para prevenir cenários de ataque potenciais, o Starknet implementou várias contramedidas, fazendo explorações importantes para o ecossistema AA.

Aviso Legal：

1. Este artigo é reimpresso de [极客 Web3]. *Encaminhe o Título Original '解读Starknet智能合约模型与原生AA：特立独行的技术巨匠'. Todos os direitos autorais pertencem ao autor original [Shew & Faust]. Se houver objeções a esta reimpressão, por favor entre em contato com oGate Learnequipa, e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.