Introduction to Cairo
Cairo is touted as a Turing-complete zero-knowledge proof system language. For developers familiar with Solidity, Cairo may be difficult to learn and unfamiliar. In addition, the library support is not sufficient yet, and the supported hash function is Pedersen, and the digital signature algorithm is ECDSA (compared to SNARK, EdDSA is less efficient, so it is not supported).
However, Cairo is still in the early stages of development, and it is believed that the development experience will improve over time.
It is important to note that as a proof system, there are roles for Provers and Verifiers. The Verifier for STARK is open source, but the Prover software is expected to be protected by a license. In general, Provers cannot be used for commercial purposes unless the proof is uploaded to the official Verifier.
The letters in CAIRO represent the following meanings:
C: CPU
AIR: Algebra Intermediate Representation
O: One AIR (verifier smart contract) to rule them all
Cairo is a specialized programming language developed for StarkNet. It is designed to write smart contracts that can run on the StarkNet platform. Understanding the design principles, features, applications, and comparison with other blockchain programming languages, as well as its future development in the blockchain field, is crucial to understanding its importance and impact.
With the development of blockchain technology, especially the popularity of Ethereum smart contracts, there is an increasing demand for more efficient and secure blockchain programming languages. Cairo (Computable Arbitrary Input Output) language was born to address this need, especially in combination with StarkNet's STARK proof technology, to provide a more efficient and secure way of programming smart contracts.
Design principles of Cairo:
Security: Cairo aims to improve the security of smart contracts. Its design reduces the possibility of programming errors and supports the creation of complex and secure contracts.
Efficiency: Cairo is optimized for STARK proofs and can effectively support a large number of computations while maintaining efficient contract execution.
Flexibility: It supports multiple programming paradigms, including object-oriented and functional programming, providing developers with a wide range of flexibility.
Features of Cairo language:
Tightly integrated with STARK proofs: Cairo is closely integrated with STARK proof technology and can generate and verify zero-knowledge proofs, which is crucial for ensuring the security and privacy of smart contracts.
Scalability: It supports the creation of highly scalable smart contracts to meet the needs of various complex applications.
Unique programming structure: Cairo introduces unique control flow and data structures that differ from traditional programming languages.
Memory model: Cairo adopts a unique memory model that allows efficient modification and access to the contract's state during execution.
Comparison with other blockchain programming languages:
Cairo has its unique advantages and characteristics compared to other blockchain programming languages such as Solidity and Vyper. Compared to Solidity, Cairo has significant improvements in security and efficiency, especially in handling complex logic and large-scale data. However, due to the novelty of Cairo, the learning curve may be steep, especially for developers accustomed to traditional programming languages.
Applications:
Cairo has a wide range of applications, especially suitable for applications that require high security and efficiency, such as decentralized finance (DeFi), gaming, supply chain management, etc. Due to its integration with STARK proof technology, it is particularly suitable for applications that require protecting user privacy.
Development environment:
Cairo provides a browser IDE called "playground" similar to Remix. It provides various example exercises and challenges, and in addition to compiling, it can also directly generate and upload proofs.
Note: However, some features cannot be used in the playground, such as providing custom input to your program. In this case, you can only use this feature for local development.
To develop Cairo, you need to install Python first. I have compiled the information from the developer's files in this HackMD document: [link to the document].
It includes an introduction, setting up the local development environment, and Cairo basics (due to space constraints, the content is not copied here).
StarkNet Cairo:
The functionality of the second version of Cairo is similar to the first version, so there is no need to worry that what you learned from the developer's files about Cairo will not be usable or significantly different in the StarkNet version. After reading Hello Cairo/How Cairo works, you can continue to read Hello StarkNet. It will be smooth to switch to the StarkNet version of Cairo.
Note 1: The documents I compiled are based on the first version of Cairo.
Note 2: If you have followed the developer's files all the way and experienced the non-StarkNet version of Cairo, you will find that using the StarkNet version is more like the usual way of using smart contracts. You can use view functions to query storage variables and use external functions to execute contracts (the non-StarkNet version does not operate DApps in this way, and it is not detailed here due to space constraints).
It is highly recommended to try both versions of Cairo. You will understand the differences between operating a DApp solely on L2 and operating a DApp shared with other DApps on Rollup. This is very helpful in understanding how L2 works, what data is needed, and why this data is needed.
The current version (0.0.2) of StarkNet Cairo still lacks some features:
Functions cannot declare array or struct-type parameters.
Contracts cannot interact with each other.
L1 cannot read data from L2, and L2 cannot read data from L1. This feature is crucial for establishing cross-L2 bridges.
Supplement and personal experience:
The proof size of STARK is much larger than that of the SNARK series, and the number of transactions included in the proof has little impact on the proof size and verification time. Therefore, combining multiple transactions into one proof is a cost-effective way for STARK (SNARK vs. STARK comparison). However, this is also a disadvantage. If your DApp or Rollup has a low TPS, you can only wait longer to collect more transactions, or increase the cost to maintain the frequency of proof verification.
Like zkSync, StarkWare also has the concept of a Rollup universe (the term "Rollup universe" is not accurate because not all subchains in their universe are Rollups, but are distinguished based on different levels of Data Availability, such as Validium and zk Porter's design). Personally, I think having the option (based on Data Availability) is better than having only one choice (fully Data Available). However, the feasibility of this option will depend on the team releasing more information.
As Rollup becomes more mature, the role of liquidity providers who can provide fast cross-Rollup services will become increasingly important. zk Rollup (StarkNet, zkSync, etc.) has a much shorter finalize time compared to Optimistic Rollup (Optimism, Arbitrum, etc.), which greatly helps reduce the risk for liquidity providers. However, currently, zk Rollup has lower support for contract functionality and L1 <-> L2 interaction compared to Optimistic Rollup. In the short term, fast cross-Rollup services should still be limited to Optimistic Rollup.