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 之間。