Encaminhar o Título Original: 解读Starknet智能合约模型与原生AA: 特立独行的技术巨匠

Autores originais: Shew & Faust, Consultores Web3: CryptoNerdCn, Desenvolvedor Core do Starknet, Fundador da Plataforma de Desenvolvimento Cairo WASM do lado do navegador

Resumo:

As principais características tecnológicas do Starknet incluem a linguagem Cairo, que é propícia para a geração de 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 aplicativos 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 Contract. 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 a 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 locação de armazenamento e paralelização de transações. Embora os dois últimos ainda não tenham sido implementados, a estrutura dos contratos inteligentes do Cairo criou 'condições necessárias' para eles. · Há apenas contas de contrato inteligente na cadeia Starknet e não há contas EOA. Ele suporta a abstração de conta AA em nível nativo desde o início. Seu plano AA incorpora as ideias do ERC-4337 até certo ponto, permitindo aos usuários escolher soluções de processamento de transações altamente personalizadas. Para evitar possíveis cenários de ataque, o Starknet adotou muitas contramedidas e fez importantes explorações no ecossistema AA.

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 Ethereum Layer 2, conhecida por sua atitude "independente" e "desconsiderando a experiência do usuário", silenciosamente esculpiu seu próprio território no florescente ecossistema de Camada 2 compatível com EVM. Devido à sua excessiva negligência com os usuários, e até mesmo a criação aberta de um canal de "mendigo eletrônico" no Discord, Starknet já foi criticado pela comunidade. Em meio a acusações de ser "desumano", sua profunda competência técnica parecia instantaneamente desvalorizada, como se apenas UX e criação de riqueza fossem tudo. O verso de "O Templo do Pavilhão Dourado" - "o fato de não ser compreendido pelos outros tinha sido 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 e AA nativo da Starknet 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 "guarda solitário incompreendido". Após uma breve introdução ao idioma 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 o 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 no 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 à de Rust e é na verdade uma linguagem ZK versátil. Além de ser usado para escrever contratos inteligentes no Starknet, ele também pode ser usado para o desenvolvimento de aplicativos 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 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, Cairo utiliza um método de compilação baseado em linguagem intermediária, como mostrado na figura abaixo. Sierra na imagem é uma representação intermediária (IR) no processo de compilação da linguagem Cairo, e Sierra será compilada em uma representação de código binário de nível inferior, chamada CASM, que roda 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 novos recursos. Em muitos casos, é apenas necessário manipular a linguagem intermediária Sierra sem alterar diretamente o código CASM subjacente. Isso economiza muitos problemas, e o cliente de nó do Starknet não precisa ser atualizado com frequência. Dessa forma, iterações frequentes da linguagem Cairo podem ser alcançadas 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 planeja compilar o Cairo em código de máquina de baixo nível que pode se adaptar a diferentes dispositivos de hardware. Os nós do Starknet não precisarão mais depender da máquina virtual CairoVM ao executar contratos inteligentes. Isso 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 do código e armazenamento de estado

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

1. Os desenvolvedores escrevem o código do contrato inteligente localmente e compilam o programa Solidity em bytecode EVM usando um editor. Esse 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 de contratos inteligentes. Exatamente, o contrato inteligente Ethereum = lógica de negócios + informações de status. Por exemplo, o contrato USDT não apenas implementa funções comuns como Transferência e Aprovação, mas também armazena o status do ativo 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 de contratos DAPP e migração de estado, nem é propício para o processamento paralelo de transações. É uma carga técnica pesada.

Em resposta a isso, o Starknet melhorou a forma como o estado é armazenado. Na sua solução de implementação de contrato inteligente, a lógica de negócios dos DApps está completamente desacoplada dos estados de ativos e armazenada separadamente. Os benefícios dessa abordagem são evidentes: em primeiro lugar, permite ao sistema distinguir rapidamente se existem implantações de código duplicadas ou redundantes. Aqui está como funciona: no Ethereum, um contrato inteligente compreende tanto a lógica de negócios quanto os dados de estado. Se vários contratos têm a mesma lógica de negócios, mas dados de estado diferentes, seus hashes também serão diferentes, tornando difícil para o sistema determinar se existem “contratos de lixo”. No entanto, na solução do Starknet, o código e os dados de estado são separados, tornando mais fácil para o sistema detectar 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 do Starknet.

No sistema de contrato inteligente da Starknet, a implantação e uso de contratos são divididos em três estágios: “compilar, declarar e implantar”. Se um emissor de ativos deseja implantar um contrato Cairo, ele primeiro compila o código Cairo escrito nas formas Sierra e bytecode de nível inferior CASM em seu dispositivo local. Em seguida, o implantador do contrato publica uma transação de “declarar”, implantando o bytecode CASM do contrato e o código intermediário Sierra na cadeia, denominado como a Classe de Contrato.

(Fonte: site oficial da Starknet)

Mais tarde, se você quiser utilizar as capacidades de função definidas no contrato de ativos, pode iniciar uma transação de 'implantação' por meio do frontend do DApp para implantar uma instância de Contrato associada à Classe de Contrato. Essa instância manterá o estado do ativo. Posteriormente, os usuários podem chamar as funções dentro da Classe de Contrato para modificar o estado da instância do Contrato. Na verdade, qualquer pessoa familiarizada com programação orientada a objetos deve entender facilmente o que Classe e Instância representam no Starknet. A Classe de Contrato declarada pelos desenvolvedores contém apenas a lógica de negócios do contrato inteligente, compreendendo funções que qualquer pessoa pode chamar, mas não possui estado real do ativo, assim não implementando diretamente 'entidades de ativos', tendo apenas a 'alma' sem o 'corpo'. No entanto, quando os usuários implantam instâncias específicas de Contrato, os ativos são 'materializados'. Se você precisar modificar o estado da 'entidade' de ativo, como transferir seus tokens para outra pessoa, pode chamar diretamente as funções escritas na Classe de Contrato. O processo acima é algo semelhante à 'instantiação' em linguagens de programação orientada 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 o Starknet:

1. Propício para a realização da hierarquização de armazenamento e do sistema de “locação 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. O StarkNet está pronto para ser compatível com camadas DA, como Celestia, e os desenvolvedores DAPP podem armazenar dados nessas camadas DA de terceiros. Por exemplo, um jogo pode armazenar seus dados de ativos mais importantes na rede principal Starknet e armazenar outros dados em camadas DA off-chain, como Celestia.Esta solução de personalização da camada DA de acordo com os requisitos de segurança foi chamada de "Volition" pela Starknet.

O chamado sistema de aluguel de armazenamento significa que todos devem continuar a pagar pelo espaço de armazenamento que ocupam. Tanto espaço na cadeia quanto ocupar, teoricamente, você deve continuar a pagar o aluguel.

No modelo de contrato inteligente Ethereum, a propriedade do contrato é incerta e é difícil distinguir se o implantador 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 implantador só é cobrado uma taxa quando o contrato é implantado. 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 a coleta de fundos de armazenamento [Atualmente, a Starknet não lança diretamente um sistema de locação 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 "contratos inúteis". Isso foi explicado anteriormente. Após o suporte à reutilização de código e detecção de contratos inúteis, a Starknet pode reduzir significativamente a quantidade de dados carregados para a cadeia e reduzir a pressão de armazenamento nos nós o máximo possível.

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

As atualizações de contratos na blockchain envolvem principalmente mudanças na lógica de negócios. No cenário da Starknet, a lógica de negócios dos contratos inteligentes é inherentemente separada 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 há necessidade de migrar o status do ativo para um novo local. Esse tipo 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 “terceirizar” 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, esse método não é conciso o suficiente e não é “nativo”.

Fonte: 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 diretamente "reutilizar" o status antigo.

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

Para maximizar o paralelismo de diferentes instruções de negociação, um passo necessário é armazenar o status do ativo de pessoas diferentes 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, ele considerará as transações paralelas como um objetivo importante no futuro.

Implantação de contrato nativo AA e de conta 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 contrato inteligente, evitando as armadilhas do sistema de contas 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á como 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 cadeia zkSyncEra "Native AA", obviamente diferenças podem ser observadas: em primeiro lugar, Starknet e zkSyncEra têm tipos de conta unificados. Existem apenas contas de contrato inteligente na cadeia. Não existe tal coisa como uma conta EOA desde o início. (O zkSync Era irá implantar um conjunto de códigos de contrato por padrão na conta recém-criada do usuário para simular as características da conta EOA do Ethereum, de modo que seja compatível com o Metamask).

No entanto, o Starknet não considera diretamente a compatibilidade com periféricos do Ethereum, como o Metamask. Quando os usuários utilizam a carteira Starknet pela primeira vez, uma conta de contrato dedicada é automaticamente implantada. Em outras palavras, a instância de contrato mencionada anteriormente é implantada, e esta instância está associada à classe de contrato implantada antecipadamente pelo projeto da carteira. Os usuários podem chamar diretamente algumas das funcionalidades escritas na classe. Agora, vamos nos aprofundar em um tópico interessante: ao reivindicar os airdrops STRK, muitas pessoas descobriram que as carteiras Argent e Braavos não eram compatíveis uma com a outra. Importar a mnemônica do Argent para o Braavos não permitiu exportar a conta correspondente, principalmente devido aos diferentes algoritmos de geração de conta usados pelo Argent e pelo Braavos, resultando em diferentes endereços de conta gerados a partir da mesma mnemônica. Especificamente, no Starknet, o endereço do contrato recém-implantado pode ser derivado por meio 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 fornecimento de vários parâmetros especiais para a 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 de contrato'. O 'deployer_address' representa o endereço do 'implantador de contrato'. Este parâmetro pode estar vazio, o que significa que mesmo que você não tenha uma conta de contrato Starknet antecipadamente, ainda é possível implantar um novo contrato. O 'salt' é o valor de sal usado 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. O Starknet permite que os usuários implantem contratos diretamente sem ter uma conta Starknet antecipadamente, da seguinte forma:

1. Os usuários primeiro determinam a instância do contrato que desejam implantar e com qual classe de contrato associá-la, usando 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 saber onde vão implantar o contrato, os usuários transferem primeiro uma certa quantidade de ETH para esse endereço como taxa de implantação do contrato. Geralmente, este ETH precisa ser transferido da L1 para a rede Starknet via uma ponte de criptomoedas.
3. Os usuários iniciam a solicitação de transação para implantação de contrato.

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

A solução acima trouxe alguns problemas de compatibilidade, pois 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 misturadas:

1. A chave privada derivada da chave pública 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 de contrato inteligente da carteira não são fundamentalmente diferentes nos detalhes de implementação; \

No caso mencionado anteriormente, tanto Argent quanto 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 de abstração de conta. 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 taxa de gás, para fora da “camada da 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ções personalizada por você na cadeia.

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

Diagrama esquemático da solução AA nativa especificada pelo arquiteto da 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.

De acordo com os funcionários do zkSyncEra e do Starknet, essa abordagem modular para a funcionalidade da conta é inspirada pelo EIP-4337. No entanto, o que os diferencia é que o zkSync e o Starknet mesclaram 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 peso histórico e ao desejo da fundação de evitar estratégias de iteração agressivas, como hard forks, tanto quanto possível, apoiou o EIP-4337, usando uma maneira diferente de resolver o problema. No entanto, o resultado é que as contas EOA e as soluções EIP-4337 têm fluxos de processamento de transações independentes, que parecem desajeitados e pesados, ao contrário da agilidade dos AA nativos.

Fonte: 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 personalizados de verificação de assinaturas, atualmente elas só 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 AAs nativas pode ser descrito como "o arcabouço teórico está em sua maioria maduro, enquanto a implementação prática ainda está em andamento". Como o Starknet só possui contas de contratos inteligentes internamente, todo o processo de suas transações leva em consideração a influência dos contratos inteligentes de conta. Primeiramente, após uma transação ser recebida pela mempool (pool de memória) do nó do 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. Verificando se o saldo da conta do iniciador pode cobrir a taxa de gás. \

Deve-se notar aqui que usar a função de verificação de assinatura personalizada no contrato inteligente da conta significa que existe um cenário de ataque. Isso ocorre porque a mempool não cobra taxas de gás ao verificar a assinatura de novas transações. (Se as taxas de gás fossem cobradas diretamente, cenários de ataque mais sérios ocorreriam). Usuários mal-intencionados 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 exaurir diretamente os recursos de computação do nó. Para evitar essa situação, o StarkNet impõe as seguintes restrições às transações:

1. Existe um limite superior para o número de transações que um único usuário pode iniciar dentro de um período de tempo unitário;
2. A função de verificação de assinatura personalizada no contrato da conta Starknet tem limitações de complexidade, e funções de verificação de assinatura excessivamente complexas não serão executadas. 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, a função de verificação de assinatura no contrato da conta não pode chamar outros contratos.

O gráfico de fluxo das transações do Starknet é o seguinte:

Vale 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ó detecta transações geradas a partir dessas duas principais carteiras Starknet, ele chamará os algoritmos de assinatura Braavos/Argent integrados no cliente. Por meio dessa abordagem semelhante ao cache, a Starknet pode reduzir o tempo de verificação da transação. Depois que os dados da transação forem 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. As 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 fracassadas. 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 fracassadas. Essas transações errôneas sem custo desperdiçam recursos computacionais do nó Starknet e podem levar a cenários de ataque DDoS. Na superfície, cobrar taxas por transações errôneas 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 das instruções. Garantir que as transações nunca sejam interrompidas 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 retornando um valor Falso indicando que a execução da transação não foi suave. É importante observar 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 ser on-chain. Esse resultado de saída pode ser 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 underflow, resultando na instrução de transação correspondente sendo interrompida e interrompida sem deixar um resultado de transação na cadeia. No entanto, se for reescrito na seguinte forma, ainda retorna um resultado de saída quando a transação falha, deixando-o na cadeia. Puramente do ponto de vista estético, parece que todas as transações podem deixar suavemente resultados de transação na cadeia, tornando a coleta de taxas uniforme particularmente razoável.

Visão geral do contrato StarknetAA

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

A validar_declarara interface mencionada acima é usada para validar transações declaradas iniciadas pelos usuários, enquanto validaré usado para validação geral da transação, verificando principalmente a correção da assinatura do usuário. Por outro lado, execute é usado para execução da transação. É importante destacar que as contas de contrato Starknet suportam inerentemente multicall, permitindo a realização de várias chamadas. A funcionalidade de multicall pode facilitar várias funcionalidades interessantes, como agrupar as seguintes três transações ao interagir com determinados 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. Revogando 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 geração de prova ZK, abstração de contas em 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 o desenvolvimento de aplicações mais tradicionais. Seu processo de compilação introduz a Sierra como uma linguagem intermediária, permitindo que o Cairo itere com frequência sem alterar o bytecode subjacente, propagando apenas as alterações para a linguagem intermediária. 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 do 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 ele 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 inúteis. Também facilita a implementação de locação de armazenamento e paralelização de transações, embora esses recursos ainda não tenham sido totalmente implementados. A arquitetura de contratos inteligentes do Cairo cria condições necessárias para esses recursos.

Starknet possui apenas contas de contrato inteligente, sem contas EOA, e suporta a abstração de conta AA em nível nativo desde o início. Sua solução AA absorve parcialmente as ideias do ERC-4337, permitindo que os usuários escolham soluções altamente personalizadas de processamento de transações. Para prevenir cenários de ataque potenciais, Starknet implementou várias contramedidas, realizando importantes explorações para o ecossistema AA.

Aviso Legal：

1. Este artigo é reproduzido a partir de [Web3 Geek]. *Encaminhe o Título Original ‘解读Starknet智能合约模型与原生AA：特立独行的技术巨匠’. Todos os direitos autorais pertencem ao autor original [Shew & Faust]. Se houver objeções a esta reprodução, entre em contato com oGate Learnequipe, e eles vão lidar com isso prontamente.
2. Responsabilidade Legal: 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 outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.