Building on StarkNet: A Primer for New Developers Migrating from Ethereum

Understanding sequencers and provers, account abstraction, memory management, and the current state of StarkNet developer tooling.

Key takeaways

• StarkNet is the second ZK rollup solution in development by StarkWare and adds support for general purpose smart contracts and composable ecosystem applications.
• There are a number of important differences between StarkNet and Ethereum that new and aspiring developers should be aware of.
• First, StarkNet is a ZK rollup, meaning it bundles together hundreds, even thousands, of transactions into a single, succinct proof. Sending a transaction or deploying a contract to StarkNet therefore works differently than it does on Ethereum. There is a sequence of operations involving sequencers, provers and verifiers, and transactions must be approved both on Layer 2 (StarkNet) and Layer 1 (Ethereum).
• Second, whereas Ethereum runs on an account-based transaction model, in StarkNet the concept of an ‘account’ is not defined out of the box. This feature, called account abstraction, makes accounts on StarkNet much more customisable, but also harder to grasp and interact with.
• Third, smart contracts on StarkNet are written in Cairo, a low level, assembly-like programming language optimised for use with validity proofs. It has a number of quirks and syntactic features that give it a steeper learning curve than Solidity. These include, for instance, its non-deterministic, read-only memory model, use of recursive functions, implicit arguments, and more.
• Four, because StarkNet is so much newer than Ethereum, it has far less available developer tooling. That said, there is certainly enough to get started, and may even become dangerous with.
• It’s really exciting to see the vibrant and growing community of developers building on StarkNet. If you are a current or aspiring Cairo developer and would like to work together on any problems, please feel free to reach out.

In an earlier article, I wrote about Layer 2 scaling solutions as a way to offload traffic from Ethereum mainnet and increase the scalability of the network.

With more smart contract developers migrating to StarkNet (the current leading general purpose ZK rollup), I thought it would be useful to highlight some of the core differences between StarkNet and Ethereum.

StarkNet recap

StarkNet is the second ZK rollup solution in development by StarkWare, a deeply technical Israeli team comprising some of the most experienced individuals in blockchain scaling.

An improvement upon StarkEx (its predecessor), StarkNet adds support for general purpose smart contracts and the composability of ecosystem applications. Smart contracts on StarkNet are written in a proprietary language called Cairo, meaning they are not natively compatible with Ethereum. However, developers can use a transpiler known as Warp to syndicate EVM compatibility.

StarkNet is currently live on mainnet in alpha and looking to scale up its throughput rapidly. A growing ecosystem of applications is already building on StarkNet, including Immutable, Sorare, dYdX and others.

Let’s break down some of the key differences between StarkNet and Ethereum.

Difference 1: Contract deployment

StarkNet is a ZK rollup, meaning it bundles together hundreds, even thousands of transactions into a single, succinct proof for publishing to the Layer 1 network. Because of this proving mechanism, deploying contracts and submitting transactions works differently on StarkNet than it does on Ethereum.

In Ethereum, the process is relatively simple: users submit transactions to validators, who process those and mine them as blocks on the blockchain. In StarkNet, the process is more complex (as shown below).

The sequence of actions (and actors) is as follows:

1. A user submits a transaction to send ETH, or to call a smart contract function.
2. The transaction is received by sequencers, who decide on the sequence of transactions for inclusion in the next block.
3. Provers generate a STARK proof of the computational integrity of the block, which encapsulates complete information about the bundle of transactions to be included in it. Note that sequencing and proving are currently centralised and performed by StarkNet only, but there is a roadmap to decentralise these toward community ownership.
4. Verifiers validate the computational integrity of transactions, but more importantly registers them back onto the Layer 1 blockchain (Ethereum). This is done to leverage the consensus mechanism of Ethereum and ensure state transitions are correctly registered on both chains.
5. Once verified, the transaction is mined as a block on the Layer 2 blockchain (StarkNet) and is considered accepted on Layer 2. However, it needs to go through one more step before it is deemed final and immutable.
6. Lastly, the transaction, or more accurately the proof of its validity, is mined on Layer 1 (Ethereum). Once complete, the transaction is considered final on both Layer 1 and Layer 2.

Difference 2: Account abstraction

Ethereum runs on an account-based transaction model, meaning it represents assets as balances within user-owned accounts. In StarkNet, the concept of an ‘account’ is not really defined out of the box.

This has two interrelated implications:

1. In StarkNet, accounts must first be defined before they can be used. In fact, when setting up a new wallet for the first time, users must first deploy their address to the network using an ‘account’ smart contract, so that it can start sending and receiving funds.
2. The abstraction of accounts means that there is much greater flexibility over the way in which transactions are signed and executed. For example, accounts can be upgraded over time to use a different signature validation scheme (rather than being tied to KECCAK-256 as with Ethereum). Accounts can also be customised to allow payments to be made from external wallets / contracts.

Account abstraction can be hard to wrap one’s head around. A useful analogy is to think about it in the same way as data types in the context of high level and low level programming languages.

With a high level programming language like JavaScript, data types such as strings are pre-defined and useable out of the box, whereas with a low level programming language like C, strings are simply one-dimensional arrays of characters and must be manipulated manually using bitwise operations. Conceptually, accounts in StarkNet are analogous to strings in C — they need to first be defined in order to be used. In practice, this makes accounts both harder to interact with for developers, but also substantially more customisable. Indeed, companies like Argent are now making use of account abstraction to build social recovery and other UX features directly into StarkNet wallets in a way they could not with Ethereum.

Difference 3: Cairo

Smart contracts on StarkNet are written in Cairo, a low level, assembly-like programming language optimised for use with validity proofs. Cairo is very efficient and well-optimised for the Cairo VM, but its downside is that it has various quirks and syntactic features that give it a (somewhat) steep learning curve. Here are some of the main ones to be aware of.

a) Memory management model

Like some other functional programming languages, memory in Cairo is read-only. This means that once you have written a value to memory, it can no longer be changed.

To syndicate read-write memory, Cairo uses dictionaries or maps to track the value of variables and record subsequent updates to their value. This works like a set of accounting entries (or indeed Bitcoin’s UTXO model) — the dictionary records a series of credit and debit operations that, when tallied up, derives the current values of the variables.

b) Recursion

Another consequence of Cairo’s memory system is that it does not allow for the use of loops. Developers normally use loops extensively in their applications, but in Cairo, loops aren’t allowed because memory is immutable (meaning the iterable cannot be properly updated to reflect changes in state).

To circumvent this, loops are replaced with recursive functions. Unfortunately, recursive functions are less efficient than loops, and can also make basic operations more complicated to perform.

c) Non-determinism

Another feature of Cairo’s memory system is its non-determinism. Cairo is primarily used for generating proofs — and these can be verified in one of two ways: either by starting with the program output and work backwards to arrive at a valid input, or by starting with an input and showing that it correctly derives the asserted output (a property known as non-determinism).

Nondeterministic pseudocode, known as hints, are instructions to tell the prover to use a certain input when computing a proof. This is a quirk of Cairo that helps to optimise the proving process.

d) Implicit arguments

Certain low-level operations are too expensive to perform in Cairo and must be outsourced to the Cairo CPU. This is done by importing builtin modules as implicit arguments, to introduce support for low-level operations like reading and writing. For the end developer, it can mean that the list of arguments imported to a function doesn’t always match with what is actually used in the body of the function (which can be confusing for new developers).

—

Cairo is still a relatively new language, and there are ongoing initiatives to abstract away low-level features and improve its friendliness for developers. Until then, the documentation page is a good resource for understanding all of Cairo’s quirks.

Difference 4: Developer tooling

Ethereum has been around for several years now, and there is an ever-growing set of libraries, frameworks and other tools to help make life easier for devs. StarkNet is still relatively new and there are far fewer tools available. However, there is definitely enough to get started, and maybe even become dangerous with. Below is a non-exhaustive list of essential tools for new builders in this space:

• Voyager: a block explorer for StarkNet, similar to Etherscan for Ethereum.
• Nile: a command line framework for bootstrapping and developing StarkNet projects. Nile is to StarkNet what Hardhat is to Ethereum, and will often be the starting point for new builders.
• Starknet Devnet: Starknet Devnet is like Ganache but for StarkNet. It allows users to setup a local instance of the StarkNet blockchain for use in smart contract development and testing.
• starknet.js: the official JavaScript library for interacting with StarkNet, similar to ethers.js for Ethereum. There is also starknet.py for Python, and Caigo for Golang.
• OpenZeppelin’s Standard Cairo Contracts: a helpful library of audited, reusable Cairo contracts written by OpenZeppelin.

… and more available here: https://starknet.io/building-on-starknet/developer-tools/

Let’s connect

It’s really exciting to see the vibrant and growing community of developers building on StarkNet. If you are a current or aspiring Cairo developer and would like to work together on any problems, please feel free to reach out!

This article was originally published on Open Source Finance.