Cairo 或將取代 Solidity 的原因
在這篇文章中,我將論證Cairo可以影響即將到來的可證明計算的浪潮,就像Solidity支持可組合計算一樣。Cairo是StarkNet的原生編程語言,StarkNet是一種用於擴展以太坊的L2網絡。
當我們把智能合約僅僅看作是金融的延伸(DeFi)或網絡的泛化(web3)時,這是令人遺憾的。智能合約網絡實際上是可組合計算的平臺。
以太坊嵌入了一些允許其計算機程序互操作的標准:
透明字節碼(沒有隱藏的Web API)
標准化API結構(稱為ABI)
保證正常運行時間(每個應用都托管在多臺機器上,每個應用程序拒絕服務是不經濟的)
內置支付基礎設施(不依賴於Stripe等第三方)
完整的部署和交易沿襲
不同應用程序層(治理、所有權等)之間無摩擦的合約
這些限制可能會降低开發人員的生產力,但也會以前所未有的規模激勵有狀態應用程序的組合和重用。
Solidity 是可組合計算的第一個主流語言
Solidity被創建為一種與上述標准兼容的簡單語言。它提供了:
基本狀態機功能(狀態、訪問、更新等)
無法訪問不可組合的原語(例如,外部數據饋送)
合約對合約交互的接口(組合方式)
用於交易費用的內置gas計量
對底層虛擬機(程序集)的高性能訪問
雖然現有的編程語言可以適應可組合計算,但它們需要擴展(為組合添加接口)和限制(消除所有形式的非確定性和外部訪問)的組合,這很難合並。此外,在優化上其是與優化 Solidity 代碼(gas 成本)完全不同的性能指標(執行足跡),這些語言的編譯器就是這么被定義的。
引入可證明的計算
StarkNet的可擴展性工具ZK-Rollups啓用了一種被稱為可證明計算的新範式。在這個範例中,我們保留了可組合計算的所有優點,但也允許程序證明它們已被執行,而無需重新運行。
這個簡單想法允許我們從一個需要重新運行交易的網絡(以太坊)轉移到一個更好的網絡(StarkNet),在這個網絡中,通過驗證交易已以特定結果執行的證明來驗證交易,這是一個更經濟的操作。
因為這個範式是如此不同,它也需要一個不同的計算模型,有效地將程序轉換成數值理論方程,而不是在機器上執行它們。
我們可以用什么編程語言來實現呢?
Solidity vs. Cairo
考慮Solidity是很自然的。首先,它已經支持組合(調用其他智能合約),並被廣泛採用。第二,在Solidity上部署了一系列應用程序,可以很容易地遷移到其他Layer 2解決方案(包括支持可證明計算的zkSync)。第三,Solidity有一個維護良好的多層編譯器,可以適應不同的用例。
但是Solidity並不是可證明計算的固有特性。任何接受慣用的Solidity代碼並將其轉換為證明的編譯器都會遇到以下問題:
依賴於低效的數據結構,如`uint256
語言層面的可變性
缺乏高效的內置插件
沒有底層訪問
技術細節:在實踐中,有兩種不同的技術來證明通用程序(SNARK和STARK)。SNARK青睞的指令集更適合作為Solidity等語言的編譯目標。STARK提供了更多的可伸展性,同時具有不太自然的指令集。當我們說“Solidity 不是可證明計算的有效語言時,我們實際上是指兩件事:1) Solidity 可以有效地編碼為 SNARK,但它們不像 STARK 那樣可擴展 2)Solidity不是編譯到STARK的最佳語言,因為在 Solidity 中常見的構造對於 STARK 來說是“昂貴的”。
Cairo有上述所有解決方案:
一個稱為felt的底層字段整數數據類型是可用的(與uint256類型一起)
Cairo語言習慣上只編寫一次(類似於函數式編程語言)
正在為常見計算开發越來越多的內置非確定性提示
Cairo提供了對底層原語的完全底層訪問
Cairo編程更具挑战性,生態系統工具仍在不斷成熟。但擴展以太坊的全部意義在於超越現有的限制,構建更好的可組合應用。如果是這樣,為什么止步於Solidity?
Source:https://medium.com/yagi-fi/provable-vs-composable-computation-or-why-cairo-will-supersede-solidity-6b00e69bfc9e
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。
24H熱門幣種與要聞 | Michael Saylor發布數字資產框架提案;Azuki疑似即將發幣(12.23)
24 H 熱門幣種 1、CEX 熱門幣種 CEX 成交額 Top 10 及 24 小時漲跌幅: B...