Starknet smart contract model and native AA: Maverick technical master

Author: shew & amp; faust, geee web3

summary

• The most important technical characteristics of StarkNet, including the CAIRO language that is conducive to ZK proof,Native level AA, Smart contract model of business logic and status storage.

• CAIRO is a common ZK language that can implement smart contracts on Starknet, or it can be used to develop traditional applications.The introduction of Sierra as an intermediate language in its compilation process allows cairo to iterate frequently, but there is no need to change the bottom layer of bytecode.In the standard library of Cairo, many basic data structures needed for account abstractionEssence

• Starknet smart contracts separate business logic and status data. Unlike the EVM chain, the CAIRO contract deployment contains“Compilation, declaration, deployment”In the third stage, business logic is declared in the contract class. The Contract instance containing status data can be established with Class and calls the code contained in the latter;

• StarkNet’s above -mentioned intelligent contract model is conducive to code reuse, contract status reuse, storage layers, and detection of garbage contracts.It is also conducive to the realization of the storage lease system and transaction parallelization.Although the latter two have not yet landed, the architecture of the CAIRO smart contract has created “necessary conditions” for it.

• There is only a smart contract account on the Starknet chain, and there is no EOA account.From the beginning, it supports native AA account abstraction.Its AA solution absorbs the idea of ​​ERC-4337 to a certain extent, allowing users to choose a highly customized transaction processing scheme.In order to prevent potential attack scenes, Starknet has made many countermeasures and made important explorations for the AA ecosystem.

Following Starknet’s issuing tokens, Strk has gradually become one of the indispensable elements in the eyes of Ethereum observers.The Ethereum Layer2 star known for “uniqueness” and “not pay attention to user experience” is like a hermit with the world.Essence

Because it was too ignored by users, and even publicly opened the “Electronic Beggar” channel on Discord, StarkNet was once attacked by the Mao Party. While being sprayed “not nearly human”, the deep technical accomplishment became “worthless in an article.”It seems that only UX and wealth -making effects are everything.The phrase “not understood as my only pride” in “Golden Pavilion Temple” is simply a self -portrait of StarkNet.

But aside from these trivial matters, it is simply starting from the “technical taste” of the code geeks. As one of the StarkNet and Starkex of the pioneers of the ZK Rollup, it is almost the treasure in the eyes of Cairo enthusiasts. In the minds of some all -chain game developers,StarkNet and Cairo are everything in Web3, neither Solidity nor MOVE is comparable.Nowadays, the largest generation gap between “technical geeks” and “user” is actually more due to people’s lack of cognition of StarkNet.

With the interest and exploration of blockchain technology, and the value of the value of StarkNet,The author starts from StarkNet’s smart contract model and native AA to simply sort out its technical solution and mechanism design for everyone.While showing the technical characteristics of the StarkNet to more people, I also hope to let people understand this “not understandable lone man”.

Cairro language minimalist science

In the following, we will focus on discussing Starknet’s smart contract model and abstraction of native accounts, explaining how StarkNet achieves native AA.After reading this article, everyone can also understand why the aid of different wallets in Starknet cannot be mixed.

But before introducing native account abstraction,Let’s first understand the original cairo language of Starknet.During the development of Cairo, an early version named Cairo0 appeared, as well as the later modern version.The overall grammar of the modern version of cairo is similar to Rust, which is actually a common ZK language.In addition to writing smart contracts on Starknet, it can also be used for the development of general applications.

For example, we can develop the ZK identity verification system in Cairo language. This program can run on the server we set up and does not need to rely on the StarkNet network.It can be said that any program that needs to be verified can be implemented in the cairo language.andCairo is probably the programming language that is most conducive to generating ZK.

Judging from the compilation process, CAIRO uses the compilation method based on intermediate language, as shown in the figure below.The Sierra in the figure is a intermediate form (IR) in the CAIRO language compilation process, and Sierra will be compiled into a more underlying binary code form, named CASM, which is directly operated on the StarkNet node equipment.

Introduce Sierra as the intermediate form, which is convenient for the cairo language to increase the new features. Many times as long as the Sierra intermediate language does not need to change the bottom CASM code directly.This saves a lot of trouble, and Starknet’s node client does not have to be updated frequently.In this way, it can achieve frequent iterations of the cairo language without changing the underlying logic of the Starknet.andIn the CAIRO standard library, many basic data structures needed for account abstraction.

Other CAIRO’s innovation, including a theoretical solution called Cairo Native. This plan plans to compile cairo as a underlying machine code that can adapt to different hardware devices. StarkNet nodes do not need to rely on the Cairovm virtual machine when running smart contracts.This can greatly improve the code execution speed [It is still in the theoretical stage and has not been landed].

Starknet smart contract model: code logic and state storage stripping

Unlike the EVM and capable chain, Starknet has breakthrough innovation in the design of smart contract systems. These innovations are largely prepared for parallel trading functions for native AA and future online.Here, we need to know that on the traditional public chain such as Ethereum,The deployment of smart contracts often follows the “post -compilation deployment” method, and uses ETH smart contracts for example:

1. After the developer wrote the smart contract locally, the developer compiles the solidity program into the byte code of EVM through the editor, so that the EVM can be directly understood and processed;

2. Developers initiate a transaction request to deploy smart contracts to deploy compiled EVM bytecode on Ethereum chain.

(Picture source: not-satoshi.com)

Although the smart contract of Starknet also follows the idea of ​​”compile and then deployment”,Intelligent contracts are deployed on the chain in the form of CASM bytecode supported by Cairovm.However, in terms of calling and status storage mode of smart contracts, StarkNet and EVM compatible chains are huge.

To be precise,Ethereum smart contract = business logic+status information,For example, the USDT contract not only implements commonly used function functions such as Transfer, APPROVAL, etc., but also stores the asset status of all USDT holders.Code and status are coupled together, which brings a lot of trouble. First of all, it is not conducive to the upgrade and state migration of the DAPP contract, and it is not conducive to the parallel processing of transactions. It is a heavy technical burden.

In this regard, StarkNet has improved the storage method of the state.In its smart contract implementation plan, the business logic and asset status of DAPP are completely decoupled, and they are stored in different places.The benefits of doing so are obvious. First of all, the system can be more distinguished by the system that has a duplicate or extra code deployment.The principle here is:

Ethereum’s smart contract = business logic+status data,If the business logic of several contracts is completely consistent, but the status data is different, the Hash of these contracts is also different. At this time, it is difficult for the system to distinguish whether these contracts are redundant and whether there are “junk contracts”.

andIn StarkNet’s scheme, the code part and status data are directly separated. According to the hash part of the code part, it is easier to distinguish whether the same code has been deployed multiple times.Because their hash is the same.This is convenient for stopping duplicate code deployment and saving the storage space of the StarkNet nodes.

In the smart contract system of Starknet, the deployment and use of the contract are divided into“Compilation, declaration, deployment”Three stages.If the asset issuer wants to deploy the CAIRO contract, the first step is to compile the written Cairo code to Sierra and the underlying bytecode CASM form.

Then, contract deployee will issue a statement of “DeCLARE” transaction, deploy the contract’s Casm bytecode and Sierra intermediate code to the chain, namedContract classEssence

(Picture source: Starknet’s official website)

After that, if you want to use the function function defined in the asset contract, you can initiate a “deploy” transaction through the front end of the DAPP and deploy aContract instanceThis instance will store asset status.After that, the user can call the function function in the Contract class to change the state of the Contract instance.

In fact, anyone who understands object -oriented programming should easily understand what the class and Instance of StarkNet represent.The Contract class declared by the developer only contains the business logic of smart contracts. It is a function function that anyone can call, but there is no actual asset state, and there is no “asset entity” directly.Essence

ShouldAfter the user deploys a specific Contract instance, the assets complete the “physicalization”.If you want to change the status of the asset “entity”, such as transferring your token to others, you can directly call the function function written in the Contract class.The above process is somewhat similar (but not completely consistent) in the traditional programming language.

After the intelligent contract is separated as Class and instances, the business logic and status data decouples brings the following features:

1. Failure to store layers and the realization of the “storage lease system”

The so -called storage stratification means that developers can place data in a customized position according to their own needs, such as under the StarkNet chain.Starknet is compatible with the DA layer such as Celestia, and DAPP developers can store data in these third -party DA layers.For example, a game can store the most important asset data on the main network of Starknet and store other data on the DA layer under the link of Celestia.This solution to the DA layer according to the customization of security needs is named “Volition” by Starknet.

The so -called storage lease system means that everyone should continue to pay for the storage space they occupy.How much space do you take for you, theoretically, you should continue to pay the rent.

In the Ethereum smart contract model, the ownership of the contract is not clear, and it is difficult to distinguish the ERC-20 contract should be paid by the deployee or the asset holder to pay “rent”.It has not been launching the storage lease function, and only charges a fee to the deployee during the contract deployment. This storage cost model is unreasonable.

Under the smart contract models of StarkNet and SUI and CKB and Solana, the ownership of the smart contract is more clear, which is convenient for the collection of storage funds [Starknet currently does not directly online storage lease system, but it will be realized in the future]

2. Realize the real code reuse and reduce the deployment of garbage contracts

We can declare a universal token contract as Class stored on the chain, and then everyone can call the function in this class to deploy its own token instance.And the contract can also directly call the code in the class, which achieves the effect of Library function library similar to the library function library in Solidity.

At the same time, this smart contract model of StarkNet,Helps distinguish the “garbage contract”.Earlier explained this.After supporting code reuse and garbage contract detection, StarkNet can greatly reduce the amount of data on the chain and minimize the storage pressure of nodes as much as possible.

3. Real “status” of the real contract

The contract upgrade on the blockchain mainly involves changes in business logic. In the scenario of Starknet, the business logic of smart contracts is inherently separated from asset status. The contract instance changes the related contract type Class, which can complete the business logic upgrade of the business logic upgradeThere is no need to migrate the asset status to a new place. This contract upgrade is more thorough and native than Ethereum.

To change the business logic of the Ethereum contract, it is often necessary to “outsourcing” the business logic to the agency contract. By changing the dependent agency contract, the business logic of the main contract business is changed.Essence

(Picture source: WTF Academy)

In some scenarios, if the old Ethereum contract is abandoned throughout, the asset status inside cannot be directly migrated to a new place, which is very troublesome; the CAIRO contract does not need to move the status away, and it can be directly “reused” the old old.State.

4. Failure to transaction parallelization

To increase the parallel degree of different transaction instructions as much as possible, the need to disperse and store the asset status of different people, which can be seen on Bitcoin, CKB and SUI.The prerequisite for the above goals is to peel off the business logic and asset status data of smart contracts.Although StarkNet has not yet carried out in -depth technological implementation of parallel transactions, it will take parallel transactions as an important goal in the future.

Starknet’s native AA and account contract deployment

In fact, the so -called account abstraction and AA are the unique concepts invented by the Ethereum community. Among the many new public chains, there is no division of the EOA account and smart contract account. From the beginning, the Ethereum account system was avoided from the beginning.pit.For example, under the setting of Ethereum, the EOA account controller must have ETH on the chain to initiate transactions. There is no way to directly choose a diverse identity verification method. It is also very troublesome to add some customized payment logic.Some people even think that the design of this account in Ethereum is simply anti -human.

If we go to observe StarkNet or ZKSYNCERA, etc.“Native AA”The chain can observe the obvious difference: first,Starknet and ZKSYNCERA unify the account type. There are only smart contract accounts on the chain. From the beginning, there is no such thing as an EOA account.(ZKSYNC Era will deploy a set of contract code by default on the newly created account of the user to simulate the characteristics of the Ethereum EOA account, which is convenient for compatibility with Metamask).

Starknet does not consider directly compatible with Metamask and other facilities around Ethereum.When users use the StarkNet wallet for the first time, they will automatically deploy a dedicated contract account.This contract instance will be associated with the contract CLASS deployed by the wallet project party in advance, which can directly call some of the functions written in Class.

Below we will talk about an interesting topic:When receiving the Strk airdrop, many people find that Argent and the Braavos wallet are incompatible with each other.After importing Argent’s notes into Braavos, the corresponding account cannot be exported.This is actually because Argent and Bravos use different account generation calculation methods.The account address generated by the same aids is different.

Specifically, in Starknet, the newly deployed contract address can be obtained through a certainty algorithm. The following formulas are used:

Pedersen () in the above formula is a process that is easy to use in the ZK system to generate an account. In fact, entering several special parameters to the PEDERSEN function to generate corresponding hash. This hash is the account address generated by the generated account addressEssence

The above picture shows a few parameters used when Starknet generates “new contract address”. Deployer_address represents the address of the “contract deployer”. This parameter can be empty.Contracts.

SALT is the salt value of the contract address. In simple terms, it is a random number.This variable is actually to avoid repeatedly introduced the contract address.Class_hash is introduced earlier, and the class hash values ​​corresponding to the contract instance.Constructor_callData_hash represents the hash on behalf of the contract for initialization of the contract.

Based on the above formulas, users can pre -calculate the generated contract address in advance before the contract deployment to the chain.Starknet allows users to directly deploy contracts without the Starknet account in advance. The process is as follows: the process is as follows:

1. The user first determines the contract instance that he wants to deploy, which contract Class should be associated, and use the class HASH as one of the initialization parameters, and calculate the SALT to learn about the contract address of the contract;

2. After the user knows where he will deploy the contract, first transfer to the address into a certain amount of ETH as a contract deployment fee.Generally speaking, this part of ETH across the chain bridge from L1 to the Starknet network;

3. The user initiates a transaction request for contract deployment.

actually,All StarkNet accounts are deployed through the above process, but most of the wallets shield the details inside. The user can not perceive the process inside.It is as if the contract account is deployed after transferring to ETH.

The above solution brings some compatibility problems, because when different wallets generate account addresses, the resulting results are not consistent.Only wallets that meet the following conditions can be mixed:

1. The private key derived public key used by wallets is the same as the signature algorithm;

2. The SALT calculation process of the wallet is the same;

3. The wallet’s smart contract Class is not fundamentally different in the implementation details;

In the previous cases, Argent and Braavos both use the ECDSA signature algorithm, but the SALT calculation method of both sides is different. The same assists will be inconsistent with the account address generated in the two wallets.

We return to the topic of account abstraction.StarkNet and ZKSYNC Era make a series of processes involved in the transaction processing process, such as authentication (verification digital signature), and GAS fee payment, all of which are moved outside the “bottom of the chain”.Users can customize the details of the above logic in their account.

For example, you can deploy a dedicated digital signature verification function in your Starknet smart contract account,When the StarkNet node receives the transaction you initiated, you will call a series of transaction processing logic you customized on the account on the chain.This is obviously more flexible.

In the design of Ethereum, logic such as authentication (digital signature) is written in the node client code, and it cannot natively support the customization of account functions.



(The original AA schematic diagram stated by the StarkNet architect, the transaction verification and the GAS Featured verification have been transferred to the contract to handle it. The underlying virtual machine of the chain can call the user’s custom or specified function)

According to the official personnel of ZKSYNCERA and Starknet, this set of account function has been modularized, and the EIP-4337 is learned.But the difference is that ZKSYNC and Starknet merged the account type from the beginning, unified the trading type, and received all transactions with a unified entrance.Because Ethereum has historical burdens and the foundation hopes to avoid rough iterative schemes such as hard forks as much as possible, it supports the “curve to save the country” scheme EIP-4337.But this effect is that the EOA account and the 4337 solution each adopt an independent transaction processing process, which looks awkward and bloated, unlike the native AA spirit.



(Image source: ARGENTWALLET)

But the abstraction of StarkNet’s native account has not yet reached a complete maturity.From the perspective of practical progress, Starknet’s AA account has realized the customization of signature verification algorithms, but for the customization of handling fees, StarkNet actually only supports ETH and STRK payment GAS fees, and has not supported third -party payment GAS.EssenceSo the progress of StarkNet on native AA can be said to be“The theoretical solution is basically mature, and the practical solution is still advancing.”

Because there is only a smart contract account in Starknet, the entire process of its transactions considers the influence of account smart contracts.First of all, a transaction is accepted by the memory pool of the Starknet node (MEMPOOL), and the verification steps include:

1. Whether the digital signature of the transaction is correct. At this time, the custom signing function will be called in the trading initiator account;

2. Can the balance of the transaction initiator be paid?

It should be noted here that using the customized signature verification function in the intelligent contract of the account means that there is an attack scenario.Because the memory pool does not charge the GAS fee when signing the new transaction verification(If you charge the GAS fee directly, it will bring more serious attack scenarios).Malicious users can customize super -complicated signing functions in their account contract, and then initiate a large number of transactions, so that when these transactions are verified, they will call the custom complex signature function.Computing resources.

In order to avoid this situation, StarkNet has the following limits on transactions:

1. During the unit time, the number of transaction pens can be initiated in the unit time is limited;

2. The customized signature verification function in the StarkNet account contract has limits in complexity, and an over -complicated signing function will not be executed.Starknet limits the upper limit of the GAS consumption of the signing function. If the amount of GAS consumed by the signing function is too high, it will directly reject this transaction.At the same time, other contracts in the account contract are not allowed to call other contracts in the account contract.

The flow chart of the Starknet transaction is as follows:



It is worth noting,In order to further accelerate the transaction verification process, the STARKNET node client directly implements the signature verification algorithm of Bravos and Argent wallets.When the node finds that the transaction generates the two mainstream StarkNet wallets, it will call the Bravos/Argent signature algorithm that comes with the client. Through this cache thought, Starknet can shorten the transaction verification time.

After the transaction data is verified by the sorter (the verification steps of the sorter will be much deeper than the memory pool verification), the sorter will pack the transaction from the memory pool and submit it to the ZK to prove the generator.The transaction that enters this link will be charged GAS even if it fails.

But if the reader understands the history of Starknet,You will find that the early Starknet does not charge a handling fee for the transaction that fails to execute,The most common transaction failure is that users have only 1 ETH funds, but 10 ETH is transferred out of the outside. This transaction obviously has logical errors and eventually fails, but no one knows what the result is before the specific execution.

But StarkNet will not charge fees for such failure transactions in the past.This costless trading will waste the computing resources of the StarkNet node, which will derive the DDOS attack scene.On the surface, it seems that the handling fee for wrong transactions seems to be very easy to achieve, but it is actually quite complicated.Starknet launched the new version of the Cairo1 language, which is largely to solve the problem of collecting the GAS of failure transactions.

We all know that ZK Proof is an effective proof, and the result that fails to execute is invalid and cannot leave output results on the chain.Try to prove it with effectiveness to prove that the execution of a certain instruction is invalid, and the output result cannot be generated. It sounds strange and it is actually not feasible.Therefore, in the past, when the StarkNet was generated, the failure transactions that could not produce the output results were directly planned.

The Starknet team later adopted a smarter solution,A new contract language cairo1 is constructed, so that “all transaction instructions can generate output results and onchain.”At first glance, all transactions can produce output, which means that there is no logical error, and most of the time the transaction fails because encountering some bugs, which causes the instruction execution to be interrupted.

It is difficult to achieve the never -interruption and successful output of the transaction, but in fact, there is a very simple alternative that when the transaction encounters logical errors, it also allows him to produce the output result. However, at this time, a return will return one to a return one.False value makes everyone know that the execution of this transaction is not smooth.

But pay attention, return the FALSE value, and return the output result, that is,In Cairo1, no matter whether the instruction has encountered logical errors or whether there is a temporary interrupt, the output result can be produced and onChain.This output result can be correct or False error information.

For exmple, if there is the following code segment:



The _balances :: read (from) -Amount may report an error because of the overflow. At this time, the corresponding transaction instructions will be interrupted and the execution will be stopped, which will not leave the transaction results on the chain; if it rewrites itFor the following form, a output result is still returned when the transaction fails, leaving the chain,From the perspective of the perception, this is as if all transactions can smoothly leave trading output on the chain, and it seems reasonable to collect the handling fees.



Overview of Starknetaa Contract

Considering that some readers may have a programming background in this article, there is a brief display of the interface of the account abstraction contract in StarkNet:



The __validate_declare__ in the above interface is used to verify the DECLARE transaction initiated by the user, while __validate__ is used for verification of general transactions. It mainly verifies whether the user’s signature is correct, and __execute__ is used for transaction execution.We can see that the StarkNet contract account supports Multical, which is multiple calls by default.Multi -calling can achieve some very interesting features, such as packing the following three transactions when performing some DEFI interaction:

1. The first transaction authorizes the token to the DEFI contract

2. The second transaction triggers DEFI contract logic

3. The third transaction is authorized to authorize the DEFI contract

Of course, because multiple calls are atomic, there are some more complicated usage, such as performing certain arbitrage transactions.

Summarize

• The most important technical characteristics of StarkNet, including the CAIRO language, AA, and business logic and state storage independent smart contract models that are conducive to ZK.

• CAIRO is a common ZK language that can not only implement smart contracts on StarkNet, or to develop traditional applications. It introduces Sierra as an intermediate language in its compilation process, so that CAIRO can iterate frequently, but there is no need to change the bottom layerThe bytecode needs to be transmitted to the middle language; in the standard library of Cairo, many basic data structures needed for account abstraction.

• Starknet smart contracts separate business logic and status data. Unlike the EVM chain, the CAIRO contract deployment includes three stages of “compilation, statement, deployment”.Establish associations and call the latter’s code;

• Starknet’s above -mentioned intelligent contract model is conducive to code reuse, contract status reuse, storage storage, detection of garbage contracts, and also conducive to the realization of the parallelization of leasing and transaction.Although the latter two have not yet landed, the architecture of the CAIRO smart contract has created “necessary conditions” for it.

• There is only a smart contract account on the StarkNet chain and no EOA account. From the beginning, it supports the abstract AA account of the native level.Its AA solution absorbs the idea of ​​ERC-4337 to a certain extent, allowing users to choose a highly customized transaction processing scheme.In order to prevent potential attack scenes, Starknet has made many countermeasures and made important explorations for the AA ecosystem.