在这篇文章中，我将论证Cairo可以影响即将到来的可证明计算的浪潮，就像Solidity支持可组合计算一样。Cairo是StarkNet的原生编程语言，StarkNet是一种用于扩展以太坊的L2网络。
当我们把智能合约仅仅看作是金融的延伸(DeFi)或网络的泛化(web3)时，这是令人遗憾的。智能合约网络实际上是可组合计算的平台。
以太坊嵌入了一些允许其计算机程序互操作的标准：
透明字节码
标准化API结构
保证正常运行时间
内置支付基础设施
以太坊核心开发人员：自2020年以来只有0.04%的以太坊验证者被移除:金色财经报道，以太坊核心开发人员Superphiz表示，自2020年12月1日启动信标链以来，以太坊生态系统只削减了226个验证者，仅占524,060个验证者的0.04%。最大的削减事件之一发生在2021年2月4日，当时质押基础设施提供商Staked的75个验证器因生产竞争区块而被削减。Staked说，违反认证是由于“技术问题”造成的。
削减是一个验证者违反权益证明共识规则的过程，这通常会导致该验证者从网络中移除并削减一部分质押的以太坊。Superphiz表示，这种被大幅削减的可能性很小，这表明人们不应该因为这个特定原因而担心抵押ETH。Superphiz指出许多移除是由于“系统迁移失败”造成的。[2023/2/23 12:24:35]
完整的部署和交易沿袭
报告：自2017年以来，比特币开发人员增长了70％:12月12日消息，加密研究公司Electric Capital于12月10日发布了有关发展趋势的报告。该报告提供了有关加密技术的新趋势。数据显示比特币，以太坊和DeFi是最活跃的细分市场，在过去三年中，比特币生态系统收到了超过70％的新开发人员。在2020年第三季度至第四季度之间，Polkadot的开发人员数量增加了一倍，而Filecoin的数量增加了三倍。（Beincrypto）[2020/12/12 15:00:08]
不同应用程序层之间无摩擦的合约
这些限制可能会降低开发人员的生产力，但也会以前所未有的规模激励有状态应用程序的组合和重用。
Prysmatic Labs开发人员：以太坊2.0测试网Zinken表现完美:10月12日，以太坊2.0测试网Zinken已确定启动。Prysmatic Labs的开发人员Terence?Tsao发推称， “在社区运行的激励测试网络上，Zinken有几乎完美的性能。”据beaconcha.in数据，目前有超过136,000个模拟ETH或G?ETH投放在测试网上，有效验证器数量达到4269个。[2020/10/13]
Solidity是可组合计算的第一个主流语言
Solidity被创建为一种与上述标准兼容的简单语言。它提供了:
Nethermind Warp将演示把Uniswap V3转换到Cairo并将其部署在StarkNet上:9月22日消息，以太坊客户端Nethermind表示，其Warp团队关于在StarkNet上支持任意Solidity合约的研究取得了重大进步，很快就可以将任意Solidity合约转换到Cairo并将它们部署到StarkNet上，下一步将演示将UniswapV3转换到Cairo并将其部署在StarkNet上。[2021/9/22 16:57:39]
基本状态机功能(状态、访问、更新等)
无法访问不可组合的原语(例如，外部数据馈送)
合约对合约交互的接口
用于交易费用的内置gas计量
对底层虚拟机的高性能访问
虽然现有的编程语言可以适应可组合计算，但它们需要扩展和限制的组合，这很难合并。此外，在优化上其是与优化Solidity代码完全不同的性能指标，这些语言的编译器就是这么被定义的。
引入可证明的计算
StarkNet的可扩展性工具ZK-Rollups启用了一种被称为可证明计算的新范式。在这个范例中，我们保留了可组合计算的所有优点，但也允许程序证明它们已被执行，而无需重新运行。
这个简单想法允许我们从一个需要重新运行交易的网络(以太坊)转移到一个更好的网络(StarkNet)，在这个网络中，通过验证交易已以特定结果执行的证明来验证交易，这是一个更经济的操作。
因为这个范式是如此不同，它也需要一个不同的计算模型，有效地将程序转换成数值理论方程，而不是在机器上执行它们。
我们可以用什么编程语言来实现呢?
Solidityvs.Cairo
考虑Solidity是很自然的。首先，它已经支持组合(调用其他智能合约)，并被广泛采用。第二，在Solidity上部署了一系列应用程序，可以很容易地迁移到其他Layer2解决方案(包括支持可证明计算的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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。