Cairo 简介
标榜为图灵完备的零知识证明系统语言，Cairo 对原本熟悉 Solidity 的开发者来说还是会感到比较难上手和陌生的。再加上套件库还不够充足，目前支援的杂凑函式是 Pedersen，数位签章演算法是 ECDSA（相对于 SNARK，EdDSA 的效能反而比较差所以没有支援）。
但 Cairo 还在早期开发的阶段，相信开发体验会越来越好的。
另外需要注意的是作为一个证明系统，会有 Prover 和 Verifier 的角色。而 STARK 的 Verifier 是开源的，但 Prover 软体预计会有 License 保护。 Prover 一般情况下不得用于商业用途，除非将 proof 上传至官方的 Verifier。
CAIRO 字母分别代表的意思是
C: CPU
AIR: Algebra Intermediate Representation
O: One AIR(verifier smart contract) to rule them all
Cairo 是一种为 StarkNet 开发的专门编程语言，它被设计用于编写可在 StarkNet 平台上运行的智能合约。Cairo 语言的设计理念、特点、应用场景、与其他区块链编程语言的比较以及其在区块链领域的未来发展，都是理解其重要性和影响的关键。
随着区块链技术的发展，特别是以太坊智能合约的普及，对于更高效、更安全的区块链编程语言的需求日益增长。Cairo（可计算任意输入输出）语言是作为解决这一需求而诞生的，特别是为了与 StarkNet 的 STARK 证明技术相结合，提供更高效和安全的智能合约编程方式。
Cairo 的设计理念
安全性：Cairo 旨在提高智能合约的安全性。它的设计减少了编程错误的可能性，并支持创建复杂且安全的合约。
效率：Cairo 专为 STARK 证明优化，能够有效地支持大量计算，同时保持合约的高效执行。
灵活性：它支持多种编程范式，包括面向对象和函数式编程，为开发者提供了广泛的灵活性。
Cairo 语言的特点
与 STARK 证明的紧密结合：Cairo 与 STARK 证明技术紧密结合，能够生成和验证零知识证明，这对于确保智能合约的安全和私密性至关重要。
可扩展性：它支持创建高度可扩展的智能合约，适应各种复杂应用的需求。
独特的编程结构：Cairo 引入了独特的控制流和数据结构，与传统的编程语言有所不同。
内存模型：Cairo 采用了一种独特的内存模型，使得合约的状态可以在执行过程中高效地被修改和访问。
与其他区块链编程语言的比较
Cairo 与其他区块链编程语言（如 Solidity 和 Vyper）相比，有其独特的优势和特点。相比于 Solidity，Cairo 在安全性和效率方面有明显的提升，尤其是在处理复杂逻辑和大规模数据时。不过，由于 Cairo 的新颖性，它的学习曲线可能比较陡峭，尤其是对于那些习惯于传统编程语言的开发者。
应用场景
Cairo 的应用场景广泛，尤其适合于那些需要高度安全性和效率的应用，如去中心化金融（DeFi）、游戏、供应链管理等。由于其与 STARK 证明技术的结合，它特别适用于那些需要保护用户隐私的应用。
开发环境
Cairo 有提供像是 Remix 的浏览器 IDE：playground。里面提供各种范例练习和挑战，除了可以编译，还可以直接生成并上传 proof。
注：但有些功能还是没办法在 playground 里使用，例如要给你的程式 custom input 时。这时候只能在本地端开发才能使用这个功能。
开发 Cairo 要先安装 python，我将开发者文件整理出来的资料统整在这个 hackmd 文档里：https://hackmd.io/w690dpAQTsKeKZv3oikzTQ
里面包含简介、设置本地开发环境以及 Cairo 基础（因为篇幅原因，所以不将内容复制到这里）
StarkNet Cairo
第二版的 Cairo 其实功能和第一版的 Cairo 是差不多的，所以不必担心在开发者文件里学到的 Cairo 在 StarkNet 版本会不能用或差很多。在读完 Hello Cairo/How Cairo works 后，就可以接着看 Hello StarkNet。会很顺利的切换到 StarkNet 版本的 Cairo。
注 1：我整理的文档里是按照第一版 Cairo 所写的
注 2：如果你从开发者文件一路看下来，体验过非 StarkNet 版的 Cairo，那你在体验 StarkNet 版的 Cairo 时一定会发现这更像一般智能合约的使用方式 — 你可以用 view 函式查询 storage 变数，可以用 external 函式去执行合约（非 StarkNet 版本不是这样操作 DApp 的，这边因为篇幅原因没有详细介绍）。
非常建议尝试两种版本的 Cairo，你会知道 1. 操作一个单独在 L2 的 DApp 和 2. 操作与其他 DApp 共存在 Rollup 上的 DApp 的不同。这对了解 L2 怎么运行、需要哪些资料、为什么需要这些资料非常有帮助。
0.0.2 版的 StarkNet Cairo 目前还缺少一些功能：
函式还没办法宣告阵列或 struct 型态的参数
合约和合约之间还没办法互动
L1 没有办法读取到 L2 的资料，L2 也没办法读取到 L1 的资料。如果要建立跨 L2 Bridge，这个功能非常重要。
补充及个人心得
STARK 的 proof size 相比于 SNARK 系列的 proof size 大很多，又其证明所包含的交易数量对 proof size 和验证时间的影响不大，所以把很多笔交易一并做一个 proof 会是对 STARK 非常有利、节省成本的方式（SNARK、STARK 比较表）。但这同时也是一个缺点，如果你的 DApp 或 Rollup 的 TPS 不高，那就只能等更久时间搜集多一点的交易，要不然就只能提高成本来维持验证 proof 的频率。
StarkWare 和 zkSync 一样都有 Rollup 宇宙的概念（ Rollup 宇宙的用词并不精确，因为在他们的宇宙中不会所有子链都是 Rollup，而是会有依照 Data Availability 程度不同所区分的子链，像是 Validium、zk Porter 的设计），个人觉得能够有（针对 Data Availability 程度的）选择是会比只有一个选择（完全 Data Available） 还好的方式，但实际上的可行性就要等其团队释出更多的资讯。
在 Rollup 越趋成熟的情况下，能够提供快速跨 Rollup 服务的流动性提供者的角色会越来越重要。 zk Rollup（StarkNet、zkSync、etc…）比 Optimistic Rollup （Optimism、Arbitrum、etc…）有着短上许多的 finalize 时间，这对降低流动性提供者的风险有很大的帮助，但目前 zk Rollup 支援合约功能甚至 L1 <-> L2 互动的完成度都比 Optimistic Rollup 还低上许多。短期内快速跨 Rollup 的服务应该还是局限在 Optimitic Rollup 之间。