从编译流程来看，Cairo使用了基于中间语言的编译方法，如下图所示。图中的Sierra是Cairo语言编译过程中的一道中间形态(IR)，而Sierra会再被编译为更底层的二进制代码形式，名为CASM，在Starknet节点设备上直接运行。
引入Sierra作为中间形态，便于Cairo语言增加新特性，许多时候只要在Sierra这道中间语言上做手脚，不必直接变更底层的CASM代码，这就省去了很多麻烦事，Starknet的节点客户端就不必频繁更新。这样就可以在不变更StarkNet底层逻辑的情况下，实现Cairo语言的频繁迭代。而在Cairo的标准库内，还纳入了账户抽象所需要的许多基本数据结构。
Cairo的其他创新，包括一种被称为Cairo Native的理论方案，该方案计划把Cairo编译为能适配不同硬件设备的底层机器代码，Starknet节点在运行智能合约时，将不必依赖于CairoVM虚拟机，这样可以大幅度提升代码执行速度【目前还处于理论阶段，未落地】。
Starknet智能合约模型：代码逻辑与状态存储的剥离
与EVM兼容链不同，Starknet在智能合约系统的设计上，有着突破性的创新，这些创新很大程度是为原生AA以及未来上线的并行交易功能准备的。在这里，我们要知道，以太坊等传统公链上，智能合约的部署往往遵循“编译后部署”的方式，以ETH智能合约举例:
1.开发者在本地编写好智能合约后，通过编辑器将Solidity程序编译为EVM的字节码，这样就可以被EVM直接理解并处理；
2.开发者发起一笔部署智能合约的交易请求，把编译好的EVM字节码部署到以太坊链上。
（图片来源：not-satoshi.com）
Starknet的智能合约虽然也遵循“先编译后部署”的思路，智能合约以CairoVM支持的CASM字节码形式部署在链上，但在智能合约的调用方式与状态存储模式上，Starknet与EVM兼容链有着巨大差异。
准确的说，以太坊智能合约=业务逻辑+状态信息，比如USDT的合约中不光实现了Transfer、Approval等常用的函数功能，还存放着所有USDT持有者的资产状态，代码和状态被耦合在了一起，这带来了诸多麻烦，首先不利于DAPP合约升级与状态迁移，也不利于交易的并行处理，是一种沉重的技术包袱。
对此，Starknet对状态的存储方式进行了改良，在其智能合约实现方案中，DAPP的业务逻辑与资产状态完全解耦，分别存放在不同地方，这样做的好处很明显，首先可以让系统更快速的分辨出，是否存在重复或多余的代码部署。这里的原理是这样：以太坊的智能合约=业务逻辑+状态数据，假如有几个合约的业务逻辑部分完全一致，但状态数据不同，则这几个合约的hash也不同，此时系统不太好分辨是否有“垃圾合约”存在。
而在Starknet的方案中，代码部分和状态数据直接分开，系统根据代码部分的hash，更容易分辨出是否有相同的代码被多次部署，因为他们的hash是相同的。这样便于制止重复的代码部署行为，节约Starknet节点的存储空间。
在Starknet的智能合约系统中，合约的部署与使用，分为“编译、声明、部署”三个阶段。资产发行者如果要部署Cairo合约，第一步要在自己的设备本地，把写好的Cairo代码，编译为 Sierra 以及底层字节码CASM形式。
然后，合约部署者要发布声明“declare”交易，把合约的 CASM 字节码和 Sierra 中间代码部署到链上，名为Contract Class。
（图片来源：Starknet官网）
之后，如果你要要采用该资产合约里定义的函数功能，可以通过DAPP前端发起“deploy"交易，部署一个和Contract Class相关联的Contract实例，这个实例里面会存放资产状态。之后，用户可以调用Contract Class里的函数功能，变更Contract实例的状态。
其实，但凡了解面向对象编程的人，都应该能很容易的理解Starknet这里的Class和Instance各自代表啥。开发者声明的Contract Class，只包含智能合约的业务逻辑，是一段谁都可以调用的函数功能，但没有实际的资产状态，也就没有直接实现“资产实体”，只有“灵魂”没有“肉体”。
而当用户部署具体的Contract实例后，资产就完成了“实体化”。如果你要对资产“实体”的状态进行变更，比如把自己的token转移给别人，可以直接调用Contract Class里写好的函数功能。上述过程就和传统面向对象编程语言里的“实例化”有些类似（但不完全一致）。
智能合约被分离为Class和实例后，业务逻辑与状态数据解耦合，为Starknet带来了以下特性：
1.利于存储分层和“存储租赁制”的实现
所谓的存储分层，就是开发者可以按照自己的需求，将数据放在自定义的位置，比如Starknet链下。StarkNet准备兼容Celestia等DA层，DAPP开发者可以将数据存放在这些第三方DA层里。比如一个游戏可以将最重要的资产数据存放在Starknet主网上，而将其他数据存储在Celestia等链下DA层。这种按照安全需求定制化选择DA层的方案，被Starknet命名为"Volition"。
而所谓的存储租赁制，是指每个人应当持续的为自己占用的存储空间付费。你占用的链上空间有多少，理论上就该持续的支付租金。
在以太坊智能合约模型中，合约的所有权不明确，难以分辨出一个ERC-20合约应该由部署者还是资产持有者支付“租金”，迟迟没有上线存储租赁功能，只在合约部署时向部署者收取一笔费用，这种存储费用模型并不合理。
而在Starknet和Sui以及CKB、Solana的智能合约模型下，智能合约的所有权划分更明确，便于收取存储资金【目前Starknet没有直接上线存储租赁制，但未来会实现】
2.实现真正的代码复用，减少垃圾合约的部署
我们可以声明一个通用的代币合约作为class存储到链上，然后所有人都可以调用这个class里的函数，来部署属于自己的代币实例。而且合约也可以直接调用class内的代码，这就实现了类似于Solidity中的Library函数库的效果。同时，Starknet的这种智能合约模型，有助于分辨“垃圾合约”。前面对此有所解释。在支持代码复用与垃圾合约检测后，Starknet可以大幅度减少上链的数据量，尽可能减轻节点的存储压力。
3.真正的合约“状态”复用
区块链上的合约升级主要涉及到业务逻辑的变更，在Starknet的场景下，智能合约的业务逻辑与资产状态天生就是分离的，合约实例变更了关联的合约类型class，就可以完成业务逻辑升级，不需要把资产状态迁移到新去处，这种合约升级形式比以太坊的更彻底、更原生。
而以太坊合约要变更业务逻辑，往往就要把业务逻辑“外包”给代理合约，通过变更依赖的代理合约，来实现主合约业务逻辑的变更，但这种方式不够简洁，也“不原生”。
（图片来源：wtf Academy）
在某些场景下，如果旧的以太坊合约被整个弃用，里面的资产状态就无法直接迁移到新去处，非常麻烦；而Cairo合约就不需要把状态迁移走，可以直接“复用”旧的状态。4.利于交易并行化处理要尽可能提升不同交易指令的可并行度，必要一环是把不同人的资产状态分散开存储，这在比特币、CKB和Sui身上可见一斑。而上述目标的先决条件，就是把智能合约的业务逻辑和资产状态数据剥离开。虽然Starknet还没有针对交易并行进行深度的技术实现，但未来将把并行交易作为一个重要目标。
Starknet的原生AA与账户合约部署
其实，所谓的账户抽象与AA，是以太坊社区发明出来的独特概念，在许多新公链中，并没有EOA账户和智能合约账户的分野，从一开始就避开了以太坊式账户体系的坑。比如在以太坊的设定下，EOA账户控制者必须在链上有ETH才可以发起交易，没有办法直接选用多样性的身份验证方式，要添加一些定制化的支付逻辑也极为麻烦。甚至有人认为，以太坊的这种账户设计简直就是反人类的。
如果我们去观察Starknet或zkSyncEra等主打“原生AA”的链，可以观察到明显的不同：首先，Starknet和zkSyncEra统一了账户类型，链上只有智能合约账户，从一开始就没有EOA账户这种东西（zkSync Era会在用户新创建的账户上，默认部署一套合约代码，模拟出以太坊EOA账户的特征，这样就便于兼容Metamask）。
而Starknet没有考虑直接兼容Metamask等以太坊周边设施，用户在初次使用Starknet钱包时，会自动部署专用的合约账户，说白了就是部署前面提到的合约实例，这个合约实例会和钱包项目方事先部署的合约class相关联，可以直接调用class里面写好的一些功能。
下面我们将谈及一个有意思的话题：在领取STRK空投时，很多人发现Argent与Braavos钱包彼此不能兼容，将Argent的助记词导入Braavos后，无法导出对应的账户，这其实是因为Argent和Braavos采用了不同的账户生成计算方式，导致相同助记词生成的账户地址不同。
具体而言，在Starknet中，新部署的合约地址可以通过确定性的算法得出，具体使用以下公式:
上述公式中的pedersen()，是一种易于在ZK系统中使用的哈希算法，生成账户的过程，其实就是给pedersen函数输入几个特殊参数，产生相应的hash，这个hash就是生成的账户地址。
上面的图片中显示了Starknet生成“新的合约地址”时用到的几个参数，deployer_address代表“合约部署者”的地址，这个参数可以为空，即便你事先没有Starknet合约账户，也可以部署新的合约。
salt为计算合约地址的盐值，简单来说，就是一个随机数，该变量实际上是为了避免合约地址重复引入的。class_hash就是前面介绍过的，合约实例对应的class的哈希值。而constructor_calldata_hash，代表合约初始化参数的哈希。
基于上述公式，用户可以在合约部署至链上之前，就预先算出生成的合约地址。Starknet允许用户在事先没有Starknet账户的情况下，直接部署合约，流程如下:
1. 用户先确定自己要部署的合约实例，要关联哪个合约class，把该class的hash作为初始化参数之一，并算出salt，得知自己生成的合约地址；
2. 用户知道自己将会把合约部署在哪后，先向该地址转入一定量的ETH，作为合约部署费用。一般来说，这部分ETH要通过跨链桥从L1跨到Starknet网络；
3. 用户发起合约部署的交易请求。
其实，所有的Starknet账户都是通过上述流程部署的，但大部分钱包屏蔽了这里面的细节，用户根本感知不到里面的过程，就好像自己转入ETH后合约账户就部署完了。
上述方案带来了一些兼容性问题，因为不同的钱包在生成账户地址时，生成的结果并不一致，只有满足以下条件的钱包才可以混用:
- 钱包使用的私钥派生公钥与签名算法相同；
- 钱包的salt计算流程相同；
- 钱包的智能合约class在实现细节上没有根本性不同；
（Starknet架构师指明的原生AA方案示意图，交易验证和gas费资格验证都被转移到链上合约去处理，链的底层虚拟机可以调用用户自定义或指定的这些函数）
按照zkSyncEra和Starknet官方人员的说法，这套账户功能模块化的思路，借鉴了EIP-4337。但不同的是，zkSync和Starknet从一开始就把账户类型合并了，统一了交易类型，并且用统一入口接收处理所有交易，而以太坊因为存在历史包袱，且基金会希望尽可能避免硬分叉等粗暴的迭代方案，所以支持了EIP-4337这种“曲线救国”的方案，但这样的效果是，EOA账户和4337方案各自采用独立的交易处理流程，显得别扭而且臃肿，不像原生AA那么灵便。
（图片来源：ArgentWallet）但目前Starknet的原生账户抽象还没有达到完全的成熟，从实践进度来看，Starknet的AA账户实现了签名验证算法的自定义，但对于手续费支付的自定义，目前Starknet实际上仅支持ETH和STRK缴纳gas费，并且还没有支持第三方代缴gas。所以Starknet在原生AA上的进度，可以说是“理论方案基本成熟，实践方案还在推进”。由于Starknet内只有智能合约账户，所以其交易的全流程都考虑了账户智能合约的影响。首先，一笔交易被Starknet节点的内存池(Mempool)接收后，要进行校验，验证步骤包括：
- 交易的数字签名是否正确，此时会调用交易发起者账户中，自定义的验签函数；
- 交易发起人的账户余额能否支付得起gas费；
- 单一用户在单位时间内，可发起的交易笔数有上限；
- Starknet账户合约中自定义的签名验证函数，存在复杂度上的限制，过于复杂的验签函数不会被执行。Starknet限制了验签函数的gas消耗上限，如果验签函数消耗的gas量过高，则直接拒绝此交易。同时，也不允许账户合约内的验签函数调用其他合约。
值得注意的是，为了进一步加速交易校验流程，Starknet节点客户端中直接实现了Braavos和Argent钱包的签名验证算法，节点发现交易生成自这两大主流Starknet钱包时，会调用客户端里自带的Braavos/Argent签名算法，通过这种类似于缓存的思想，Starknet可以缩短交易验证时间。
交易数据再通过排序器的验证后（排序器的验证步骤比内存池验证会深入很多），排序器会将来自内存池的交易打包处理，并递交给ZK证明生成者。进入此环节的交易即使失败，也会被收取gas。但如果读者了解Starknet的历史，会发现早期的Starknet对执行失败的交易不收取手续费，最常见的交易失败情况是，用户仅有1ETH 的资金，但是对外转出10ETH，这种交易显然有逻辑错误，最终必然失败，但在具体执行前谁也不知道结果是啥。但StarkNet在过去不会对这种失败交易收取手续费。这种无成本的错误交易会浪费Starknet节点的计算资源，会衍生出ddos攻击场景。表面上看，对错误交易收取手续费似乎很好实现，实际上却相当复杂。Starknet推出新版的Cairo1语言，很大程度就是为了解决失败交易的gas收取问题。
我们都知道，ZK Proof是一种有效性证明，而执行失败的交易，其结果是无效的，无法在链上留下输出结果。尝试用有效性证明，来证明某笔指令执行无效，不能产生输出结果，听起来就相当奇怪，实际上也不可行。所以过去的Starknet在生成证明时，直接把不能产生输出结果的失败交易都刨除了出去。Starknet团队后来采用了更聪明的解决方案，构建了一门新的合约语言Cairo1，使得“所有交易指令都能产生输出结果并onchain”。乍一看，所有交易都能产生输出，就意味着从不出现逻辑错误，而大多数时候交易失败，是因为遇到一些bug，导致指令执行中断了。让交易永不中断并成功产生输出，很难实现，但实际上有一种很简单的替代方案，就是在交易遇到逻辑错误导致中断时，也让他产生输出结果，只不过这时候会返回一个False值，使大家知道这笔交易的执行不顺利。但要注意，返回False值，也就返回了输出结果，也就是说，Cairo1里面，不管指令有没有遇到逻辑错误，有没有临时中断，都能够产生输出结果并onchain。这个输出结果可以是正确的，也可以是False报错信息。For Example，假如存在以下代码段
此处的 _balances::read(from) - amount可能因为向下溢出而报错，这个时候就会导致相应的交易指令中断并停止执行，不会在链上留下交易结果；而如果将其改写为以下形式，在交易失败时仍然返回一个输出结果，留存在链上，单纯从观感上来看，这就好像所有的交易都能顺利的在链上留下交易输出，统一收取手续费就显得特别合理。
StarknetAA合约概述
考虑到本文有部分读者可能存在编程背景，所以此处简单展示了一下Starknet中的账户抽象合约的接口:
上述接口中的__validate_declare__，用于用户发起的declare交易的验证，而__validate__则用于一般交易的验证，主要验证用户的签名是否正确，而__execute__则用于交易的执行。我们可以看到Starknet合约账户默认支持multicall即多重调用。多重调用可以实现一些很有趣的功能，比如在进行某些DeFi交互时打包以下三笔交易:
- 第一笔交易将代币授权给DeFi合约
- 第二笔交易触发DeFi合约逻辑
- 第三笔交易清空对DeFi合约的授权
