Why Cairo may replace Solidity

In this post, I will argue that Cairo can influence the coming wave of provable computing in the same way that Solidity supports composable computing. Cairo is the native programming language for StarkNet, an L2 network for scaling Ethereum.

It is unfortunate when we think of smart contracts as merely an extension of finance (DeFi) or a generalization of the web (web3). Smart contract networks are actually platforms for composable computing.

Ethereum embeds some standards that allow its computer programs to interoperate:

  • Transparent bytecode (no hidden web API)
  • Standardized API structure (called ABI)
  • Guaranteed uptime (every app is hosted on multiple machines, denial of service per app is not economical)
  • Built-in payment infrastructure (no dependencies on third parties like Stripe)
  • Complete Deployment and Transaction Lineage
  • Frictionless contracts between different application layers (governance, ownership, etc.)

These limitations can reduce developer productivity, but also incentivize composition and reuse of stateful applications at an unprecedented scale.

Solidity was the first mainstream language for composable computing

Solidity was created as a simple language compatible with the above standards. It provides:

  • Basic state machine functions (state, access, update, etc.)
  • No access to non-composable primitives (e.g. external data feeds)
  • The interface of contract-to-contract interaction (combination method)
  • Built-in gas metering for transaction fees
  • High-performance access to the underlying virtual machine (assembly)

While existing programming languages ​​can accommodate composable computation, they require a combination of extensions (adding interfaces for composition) and restrictions (eliminating all forms of nondeterminism and external access), which are difficult to incorporate. Furthermore, optimization is a completely different performance metric (execution footprint) than optimizing Solidity code (gas cost), which is how compilers for these languages ​​are defined.

Introduce provable computation

StarkNet’s scalability tool, ZK-Rollups, enables a new paradigm known as provable computing. In this paradigm, we retain all the advantages of composable computations, but also allow programs to prove that they have been executed without re-running.

This simple idea allows us to move from a network that requires re-running transactions (Ethereum) to a better network (StarkNet) where transactions are verified by proof that they have been executed with a specific outcome, which is a more economical operation.

Because this paradigm is so different, it also requires a different computational model that effectively translates programs into numerical theoretical equations rather than executing them on a machine.

What programming language can we use to achieve this?

Solidity vs. Cairo

It’s only natural to think about Solidity. First, it already supports composition (calling other smart contracts) and is widely adopted. Second, a range of applications are deployed on Solidity that can be easily migrated to other Layer 2 solutions (including zkSync, which supports provable computation). Third, Solidity has a well-maintained multi-layered compiler that can be adapted to different use cases.

But Solidity is not inherent to provable computation. Any compiler that takes idiomatic Solidity code and turns it into a proof suffers from the following problems:

  • Relying on inefficient data structures like `uint256
  • Variability at the language level
  • Lack of efficient built-in plugins
  • no underlying access

Technical details : In practice, there are two different techniques for proving generic procedures (SNARK and STARK). The instruction set favored by SNARK is more suitable as a compilation target for languages ​​such as Solidity. STARKs offer more scalability while having a less natural instruction set. When we say “Solidity is not an efficient language for provable computation, we really mean two things: 1) Solidity can be efficiently encoded as SNARKs, but they are not as extensible as STARKs 2) Solidity is not the most efficient way to compile to STARKs A preferred language because the common constructs in Solidity are “expensive” for STARKs.

Cairo has all the above solutions:

  • An underlying field integer data type called felt is available (along with the uint256 type)
  • Cairo language is traditionally written once (similar to functional programming languages)
  • More and more built-in non-deterministic hints are being developed for common computations
  • Cairo provides full low-level access to low-level primitives

Cairo programming is more challenging and the ecosystem tools are still maturing. But the whole point of scaling Ethereum is to go beyond existing limitations and build better composable applications. If so, why stop at Solidity?

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/why-cairo-may-replace-solidity/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-01-28 08:36
Next 2022-01-28 08:39

Related articles