TL;DR

• StarkWare is developing a new blazing-fast prover: Stwo.
• Stwo will implement the groundbreaking Circle STARK, which will unlock the efficient prime field M31.
• Stwo will be open-sourced from day one under Apache 2.0.
• In time, systems benefitting from Stone prover, including public Starknet and Starknet appchains, will benefit from Stwo.

Unlocking the next phase of STARKs

The next generation of STARK proofs is here! To avoid a barrage of unsolicited information, we’ll go for an overview with some fancy words peppered throughout. We invite you to go link-hopping and window-shopping!

High level for non-math folks

The future of STARK-scaling is coming. On the theoretical front, joint research with the Polygon Labs team culminated in a groundbreaking mathematical innovation: the Circle STARK protocol. On the applied front, StarkWare is developing a new blazing-fast open-source prover: Stwo. Stwo will implement the new Circle STARK protocol alongside various other optimizations. It will unlock the full potential of the extremely efficient prime field M31 for the benefit of everyone in the zk-proof and blockchain spaces.

Deep dive for math folks

The classical STARK protocol requires an algebraic structure for its constituent steps. Chiefly, it requires a prime field of size p so that p-1 is divisible by a large power of two. Why? To facilitate two core parts of the STARK protocol: FFT and FRI. This is all nice and good, but such a constraint rules out many fields of smaller size that are otherwise very well-suited to efficient computation. Specifically, it rules out the very efficient Mersenne prime field M31 (with p=231–1) because p-1=2(230–1) is not even divisible by 4. Thus we are at an impasse: the classical STARK protocol does not mix with M31.

Before we proceed, a quick digression. A few years ago, we stumbled upon a similar problem, albeit with a different motivation. We wanted to adapt the STARK protocol for two cryptographic mainstream curves: secp256k1 and secp256r1. Each of these uses a different prime, neither of which satisfies the constraint of the above paragraph. To circumvent this problem, we came up with the ECFFT paper that uses elliptic curves to provide an alternative source of structure for FFT and FRI. This research detailed machinery for adapting STARKs to pretty much any field you can think of.

Back to our story. The desire to adapt the classical STARK protocol for M31 led to a fertile collaboration with the Polygon Labs team, culminating in Circle STARK: a compact, elegant protocol that avoids the heavy machinery of ECFFT paper. In a nutshell: when p+1 is divisible by a large power of two, as is the case with M31, the circle curve over the prime field furnishes the structure necessary to adapt both FFT and FRI. The remaining details — of which there are plenty — are lucidly worked out in the paper.

Next-gen open-source prover: Stwo

The shiny new math isn’t just for show though. It comes with a blazing-fast open-source prover that will leverage Circle STARKs, and various other optimizations, to bring unprecedented proving performance.

What is the name of this mythical creature, you ask? The first generation is Stone, so the second generation can only be Stwo! (pronounced “Stoo”). Now, what do you get out of it?

That depends on who you are.

Users and builders will benefit from next-level scaling. The zk-proof and blockchain spaces will benefit from having an open-source implementation of the most advanced STARK technology! Since the first implementation of STARK-based scaling technology (launched in June 2020 with StarkEx), many protocols have moved to develop STARK-based scaling solutions. Anyone interested in diving into these fascinating fields (pun intended) — whether to learn about or to use STARKs for whatever purpose — will have the best tool at their disposal.

What about systems that are or will be based on Stone, namely Starknet and appchains that may launch around it? Not a problem. Developers will not be impacted at all because high-level Cairo will be completely compatible with Stwo. When the time comes, and Stwo is ready to be rolled out, the Starknet ecosystem — namely users and developers — will benefit from Stwo’s next level of scaling without having to do anything at all! Stwo will be compatible with high level Cairo code in which contracts are written, and also with Sierra. The Starknet prover(s), currently based on Stone, will employ it. Users/builders/dapps will reap its benefits both in terms of latency and fees.

Summary

Stwo is the future of scaling! It will leverage the mathematical leap that blew the minds of math lovers — Circle STARKs — to the benefit of the Starknet ecosystem.

The blazing-fast, open-source Stwo prover will empower Starknet developers with an optimized proving experience on all fronts. And, yes, that will translate into faster and cheaper transactions for users.

Builders, don’t wait — start building on Starknet today so you can benefit from the supercharged scalability Stwo will offer once it is available.

Stwo will be open-sourced from day one under Apache 2.0. Be sure to follow its development here.

Stwo Prover: the next-gen of STARK scaling is here was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

STARK-tech as the secret sauce that helps dApps scale and thrive on Ethereum — today and tomorrow.

TL;DR

• Starknet set the foundations to be the home for complex, computational-hungry, and innovative DeFi platforms, onchain games, dynamic NFTs, and more.
• Starknet continues to have the fastest-growing dev ecosystem among all L2s (and a few L1s).
• StarkWare open-sourced key elements such as Stone Prover, Starknet sequencer, and Papyrus full node in 2023.

Read on to learn about our highlights and the overall progress of the Starknet ecosystem in 2023.

Decentralization & Community Expansion

• Gaming Boom on Starknet

L1 limitation of scale, UX, and high costs have made creating successful onchain games nearly impossible. But with the maturity of Validity Rollup technology, the promise of onchain games is finally being delivered.

As a result, the number of projects building fully onchain games on Starknet boomed over the past year. Some examples include Influence, a grand-strategy MMO set in a distant asteroid belt with a player-owned open economy, Shoshin, a user-programmable fighting game, Realms, a fantasy-strategy game, and Loot Survivor, a survival-strategy game.

This year, we also saw the launch of Dojo, a decentralized gaming engine built by the Starknet community, which simplifies key elements required for game building. Other components like ECS, Sozu, Torii, and Katana aid game development and deployment.

• The Starknet Decentralization Roadmap

The Starknet ecosystem took several strides in 2023 toward fulfilling the Starknet decentralization roadmap. Published in October 2023, this canonical paper outlines the values on which the ecosystem was created, how the transition process to a decentralized Starknet will look like, the decentralized network architecture, and the plan towards a fully open-sourced software stack.

• The Devonomics Pilot Program

Starknet’s founding vision recognized that developers are central to the network’s
mission of scaling Ethereum while retaining Ethereum’s core principles of decentralization, transparency, inclusivity, and security.

That’s why, in December 2023, and in accordance with this vision of decentralized governance, the Starknet Foundation, in collaboration with StarkWare, launched the Devonomics Pilot Program. A first-of-its-kind program among L2s, Devonomics distributes over 1,600 ETH to Starknet dApp and Core Developers who have contributed to Starknet’s expansion and adoption. The distribution is done via a novel mechanism that aims for fairness, inclusivity, and transparency.

The end goal of Devonomics is to bolster developer participation in decision-making and the future operation of Starknet.

STARK-Tech: Reaching New Heights

• Leading the Pack

STARK-Tech continues to scale Ethereum and provide apps with the ability to grow their audience and activity at low costs. StarkEx passed $1 trillion (yes, you read that right) in cumulative trading, and Starknet, during several weeks in 2023, scaled more activity on Ethereum than all the other L2s combined.

Moreover, in 2023, Starknet’s developer ecosystem grew by 14% to become the 8th largest crypto developer community, the largest developer ecosystem among all L2s.

• Quantum Leap

The release of Starknet Alpha v0.12.0 marked the beginning of a quantum leap forward in providing enhanced performance and scalability, featuring a 10x increase in throughput. Three key ingredients contributed to this improvement: Cairo VM in Rust (part of a year-long collaboration between LambdaClass and StarkWare), Blockifier, and Papyrus, all benefiting from the power of Rust.

Innovating on Ethereum

• Herodotus Proves Ethereum

In ground-breaking research that used cryptographic proofs and block hashes, Herodotus collaborated with StarkWare to prove Ethereum blocks all the way back to the Genesis block. Until this point, the only records developers could access in a trustless manner was the history of the past hour. However, by leveraging Herodotus’s storage proofs solution and StarkWare’s powerful SHARP (SHARed Prover) system, developers can now retrieve — in a chain-native and provable way — all Ethereum block hashes back to the Genesis block.

By doing so, this accomplishment achieves the goals of EIP-2935 — a way to access historical block hashes older than 256 blocks in a chain-native way, and unlocks new use cases for Defi and more.

Open-Sourcing Time — Setting New Bars for Protocols

In keeping with its vision to facilitate decentralization on Starknet, StarkWare open-sourced various key components of its tech stack to empower developers. Here are some of the key elements that were open-sourced:

• Cairo

The upgrade from Cairo Zero to (the new) Cairo in January brought 2023 in with a bang. A major milestone in the evolution of Cairo, the Turing-complete programming language for efficiently writing provable programs, this new release made Cairo dev-friendly, allowing for writing safer code while also being more expressive.

Cairo also introduced Sierra, a new intermediate representation that ensures every program that Cairo runs can be proven. This makes Cairo particularly well-suited for use in a permissionless network like Starknet, where it can provide robust DoS protection and censorship resistance. To learn more about Cairo, read here.

• Papyrus Full Node

A Rust implementation of a Starknet full node, Papyrus was launched to provide the foundations for the new Starknet Sequencer, which dramatically enhances Starknet’s throughput. In line with StarkWare’s ongoing move to open-source the Starknet stack, Papyrus was provided open source under the Apache 2.0 license and joined other Starknet full nodes — Pathfinder, Juno, and Deoxys — which were built by external teams in the ecosystem.

• Starknet’s Sequencer

Built on the foundations of Papyrus, the new open-sourced Starknet sequencer became available under the Apache 2.0 license and was designed and developed to boost throughput and level up Starknet’s performance. The vital first stop in a user transaction’s journey to STARK scaling, sequencers order the transaction and produce blocks to be converted into a proof for Ethereum.

• Stone Prover

StarkWare open-sourced its battle-tested and powerful Stone (STARK one) Prover under the Apache 2.0 license. In doing so, StarkWare allows builders to use this robust battle-tested prover and build their proving systems around it for whatever cause they choose. It also allows more eyes to review the code and offer optimizations, improve its quality, help detect bugs, and provide transparency.

Appchains on Starknet: The Home of Innovative dApps

Public networks offer composability and ecosystem benefits, but for some apps, a dedicated scaling solution can offer specific benefits that cannot be implemented on the public network. Starknet appchains are making notable strides forward, with the first Starknet appchain already in production. Here are a few milestones we saw in 2023:

• The Launch of Starknet’s First Appchain

In July 2023, Paradigm, the largest institutional liquidity network in crypto, launched Paradex, a crypto-derivatives exchange and the first appchain on Starknet. The launch demonstrated Starknet’s ability to cater to the needs of apps that require heavy computation, low costs, and custom specs, all while retaining self-custody.

The smart contract behind this new, beta-stage perpetual trading platform was written in Cairo by the Paradex team within only six months.

• Madara: An Exploration Team Project

The launch of Madara, a sequencer built by Starknet’s exploration team and community members, was a game-changer for projects and developers interested in creating customizable and efficient appchains.

By using the Substrate framework, Madara amplifies the capabilities of the Cairo VM, leading to provable, secure, and flexible programs. Madara offers developers special features, including support for potential onchain privacy, streamlined interoperability across various chains, and robust execution.

Madara is paving the way in dApp development by delivering cost-effective, scalable, and customizable solutions in the blockchain domain and already has many projects using it to enhance their apps with scalable infrastructure, high throughput, and unprecedented control.

• Starknet’s Tech Stack

One of the Starknet ecosystem’s main goals is to provide developers with decentralized, open-sourced tools that empower them to create scalable and secure projects. Starknet has the most decentralized rollup stack, including lots of key infrastructure built by multiple independent teams.

Community Engagement & Events

While creating programs to benefit our existing community members, StarkWare continued expanding the Starknet community by holding countless meetups, workshops, hacker houses, and events. Two of the events that stand out most are StarkWare Sessions and StarkWare Summit.

• StarkWare Sessions — Over the course of two days, StarkWare hosted more than 1,000 attendees from all over the world, crypto ecosystem, and walks of life. Designed to bring the ever-expanding StarkWare community together to meet, collaborate, and learn, the event exceeded our wildest expectations and served as a promising beacon for the future of the Ethereum and Starknet developer community. Relive the magic of all the discussions and workshops on our YouTube channel.
• Starknet Summit — In August, hundreds of participants flew into San Francisco to meet the faces behind the Twitter handles and Discord IDs of the vast STARK ecosystem.

Vision for the Future

StarkWare aims to lead the way in developing the most innovative solutions for scaling Ethereum.

STARK-tech has proved itself to be the secret sauce that allows amazing use cases to scale and thrive and turning Starknet into a hub of creative apps with complex logic such as fully onchain gaming, perpetuals, dynamic NFTs, and more.

Throughout 2023, StarkWare supported the Starknet ecosystem with tools for building blockchain applications by providing unlimited scaling needs at low costs. In parallel to those accomplishments, StarkWare made significant strides toward supporting developers and other members of the ecosystem, under its goal of expanding decentralization on Starknet.

By introducing innovative technology and processes, and open-sourcing key elements of its tech stack, Starknet became the fastest-growing L2 (by number of devs) in the industry and continues to expand. Going into 2024, expect StarkWare to build on these amazing achievements and bring more ideas to Starknet’s thriving ecosystem.

Make sure to join the discussion on Discord and follow StarkWare and Starknet on X.

From Milestones to Masterstrokes: StarkWare’s Year in Review was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Moving towards decentralization by supporting and empowering Starknet developers

TL;DR

• The Starknet Foundation, in collaboration with StarkWare, is launching Devonomics, an experimental pilot program that puts Starknet developers first by rewarding and empowering them.
• Devonomics is initially allocating over 1600 ETH ($3.5M+ at time of publication), constituting 10% of all transaction fees accumulated until November 30, 2023.
• The program runs through a transparent and inclusive distribution process, unique to Ethereum’s L2 landscape.
• The end goal of Devonomics is to bolster developer participation in decision-making and the future operation of Starknet.

Overview

In accordance with its vision of decentralized governance, the Starknet Foundation, in collaboration with StarkWare, is launching the Devonomics Pilot Program which will distribute over 1,600 ETH (over $3,500,000 at current prices) to Starknet developers. This constitutes approximately 10% of all Starknet fees accrued from November 2021 until November 30, 2023. The distribution will be done via a novel mechanism, unique to the Ethereum L2 landscape, that aims for fairness, inclusivity, and transparency.

This post provides background on Starknet, describes the details of Devonomics, and explains how it relates to Starknet’s decentralization vision. Finally, it discusses Devonomics in the broader context of other initiatives for Starknet users and developers.

Background on Starknet

Since Nov ’21, developers worldwide have worked around the clock to build and develop Starknet’s Mainnet, the first Turing-complete Validity Rollup on Ethereum. As a result, Starknet is now the largest developer ecosystem among all L2s, having grown 14% over the past year to become the 8th largest blockchain developer community, and the leader in the L2 landscape.

This growth is partially explained by the mature technology stack Starknet offers. This stack is built on STARKs — the safest and most scalable proof system; Cairo — an ergonomic and dev-friendly smart contract language; and includes novel blockchain features like native account abstraction.

Another explanation for the rapid growth of Starknet’s developer ecosystem is its vision, in which Devonomics plays a key role.

Starknet’s Vision Reflected in Devonomics

Starknet’s founding vision recognized that developers are central to the network’s mission of scaling Ethereum, while retaining Ethereum’s core principles of decentralization, transparency, inclusivity, and security.

By distributing fees via the Devonomics Program, Starknet is progressing according to this vision in the following ways:

1. Rewarding developers for operating and developing the network

Devonomics will give devs additional rewards for operating core network infrastructure or building new dApps and incentivize them to continue doing so in the future. In this sense, the program is a realization of the network’s governance vision. “A fair, open, and censorship-resistant service is only possible if several parties show up to compete to perform work that powers the decentralized service, and that can only be guaranteed if those workers are compensated for their role as operators of the network.” (A Decentralization and Governance Proposal for Starknet)

2. Empowering developers to govern the network in a decentralized manner

Devonomics helps those who build the network and its dApps play a prominent role in governing the network. It ensures that no single centralized entity holds sway over Starknet. It uses a reliable method for judging the level of contribution of dApps to the ecosystem, assessed by fees generated, and likewise will use reliable methods to judge the contribution of core developers. These judgments are then reflected in the strength each developer has in the governance of the ecosystem.

3. Maintaining and securing the network by staking

In the future, all fees on Starknet will be denominated in STRK and the operation of the network will be decentralized via a Proof-of-Stake based protocol. At that time, Devonomics will enable devs to stake their STRK to participate in ensuring the liveness and security of the network, via sequencing, STARK-proving services and data availability provisioning, to name a few examples.

Overview of the Devonomics Pilot Program

As mentioned above, Devonomics will initially allocate 10% of Starknet transaction fees accrued from the launch of Mainnet in November 2021 until the end of November 2023. This is over 1,600 ETH (over $3,500,000 at the time of writing).

This sum will be distributed by the Starknet Foundation to two cohorts of developers, (a) dApp Developers and (b) Core Developers, as follows:

Fee allocation for dApp Developers

The program will distribute 8% of collected fees (over 1,200 ETH) to dApp Developers.

The value offered to users by a smart contract is reflected in the amount of fees collected by that smart contract. By allocating a fixed portion of fees to each smart contract, Starknet rewards dApp Developers objectively, transparently and fairly, in correlation with the value they offer to Starknet users. In other words, smart contracts that contribute to users’ engagement with Starknet will receive more funds.

The computation of the exact allocation to each dApp is done by measuring the L1 and L2 fees paid by users of these contracts (the fee estimation algorithm has been built to ensure the inclusion of a variety of dApps and will likely be modified over time). In the future, the allocation of fees and ongoing newly minted Stark Tokens to dApp Developers will be automatically done by the Starknet protocol itself in a manner that is fair, transparent and objective.

A description of the fee allocation algorithm and the list of recipient Starknet accounts can be found here.

Fee allocation for Core Developers

The program will distribute 2% of collected fees (over 300 ETH) to Core Developers.

While the relative value offered by dApp Developers can be assessed by the fees users pay, there is no known objective metric to compare the contribution of Core Developers, such as those who write code for provers, sequencers, full nodes, long-term storage providers, etc. Therefore some human discretion is needed. However, having a single central entity assigning a fixed portion of fees to Core Developers would be arbitrary and open to favoritism. With this in mind, we are conducting research on the best practices to evaluate contributions in a fair, transparent, and efficient manner, and we are learning from existing mechanisms in the blockchain space.

For the current Pilot Program, we decided to put the responsibility for recommending the assignment of funds to Core Developers in the hands of the very dApp Developers who receive fees from the program. We made this decision in order to have a simple yet reliable mechanism for the Pilot Program, as dApp Developers are familiar with core projects and their contribution to Starknet.

In other words, during the Pilot Program, each dApp Developer will be asked to recommend how to allocate an additional 25% of fee revenue on top of what they have received. Thereby, an additional 2% of fees collected by Starknet (over 300 ETH) will be apportioned by dApp Developers to Core Developers whose work they value.

Example: Suppose Alice, a dApp Developer, is set to receive 8 ETH. As part of the claiming process, Alice will be asked to recommend how to allocate a separate amount of 2 ETH (i.e., 25% of her allocated amount), to Core Developers, at arm’s length. To clarify, this amount of 2 ETH is separate from, and additional to, the 8 ETH that Alice receives as a dApp Developer, and is paid directly from the Starknet Foundation to the Core Developers.

Further restrictions appear in the “Fine Print” section below.

Other Starknet Initiatives for Users and Developers

Devonomics is one of several complementary initiatives that reflect Starknet’s commitment to decentralization. These initiatives seek to empower important network stakeholders who have contributed in the past to Starknet’s success, and ensure that present and future stakeholders continue to maintain Starknet as a public good. Previous Starknet Foundation initiatives include:

• The Early Adopter Grant (EAG) Program
• The Early Community Member Program (ECMP)
• Developer Partnerships (DPs)
• Grants to Individual Contributors

Regarding user-facing initiatives, the upcoming first round of Provisions, the first of several rounds, will initiate Starknet’s user-focused decentralization efforts. Future user-oriented initiatives include rebates denominated in STRK on transactions performed, and other mechanisms that recognize and reward the contribution of users to the network.

Finally, in the near future there is expected to be a significant reduction in fees, a benefit to all ecosystem users.

Summary

The Devonomics Pilot Program is an important step in Starknet’s progress towards a fully decentralized ecosystem in both its tech stack and the processes that govern it. Put simply, it is a bold experiment in building and sustaining a decentralized community.

By allocating 10% of transaction fees to developers, the program seeks to encourage the growth of the Starknet community and bolster the role developers play in the network’s decision making processes. As the program is expected to change over time, developers are encouraged to actively participate and explore this exciting space together by providing feedback to shape the pilot program’s evolution into something more robust and permanent.

Want to join the discussion about the Devonomics Pilot? Join our community forum and follow Starknet on X.

To become a member of Starknet’s community, get started with the Starknet Book and Cairo Book.

— — — — — —

Fine Print

• At the moment, there is no need to reach out to the Starknet Foundation or any other party in the Starknet ecosystem regarding participation in the program. The Starknet Foundation will initially reach out to projects directly and later on share details on how to receive fee allocations through the program.
• Fees in the first phase of the program will be paid in ETH, and, when relevant after the launch of Starknet v0.13.0, in both ETH and STRK. Generally speaking, Devonomics will be denominated in the token(s) used to pay transaction fees on Starknet.
• It should be noted that the Devonomics mechanism is not supposed to replace sustainable business models for projects. In particular, it may be modified over time and may be terminated at any point in time based on an evaluation of its benefit to the Starknet ecosystem.
• The mechanisms for allocating fees to both dApp and Core Developers will be modified over time, to improve transparency, fairness and efficiency.
• The fraction distributed is very likely to change over time, e.g., following events such as future fee reductions on Starknet due to greater efficiency and scale, the introduction of EIP-4844, introduction of a fee market to Starknet and modification of the Starknet gas computation model. The percentage may also evolve based on community feedback and other factors.
• The Starknet Foundation will strive to allocate fees in accordance with the outlined pilot program. However, final discretion on all payments will be left to the Starknet Foundation, to accommodate regulatory and financial obligations.
• The Devonomics Pilot Program has a total budget of 8% for dApps and 2% for Core Developers, but this does not create a current or future commitment, legal or otherwise, to allocate to any dApp 8% of the fees collected through such dApp. The exact computation method for the Pilot Program is merely an attempt to approximate a fair allocation.
• The claiming threshold for receiving fees in this round is set at 0.1ETH. In case this threshold is not reached, fees will accumulate and roll over to the next distribution date until the threshold is met.

FAQs:

What do I need to do to receive Devnomics?

Nothing, at the moment. The Starknet Foundation will release further details at a later point in time and will contact the relevant projects.

Starknet Launches the ‘Devonomics’ Pilot Program was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Towards a Smoother Blockchain User Experience

Ethereum has revolutionized the world of decentralized applications (dApps), offering a secure and transparent way to interact online. However, early blockchain networks like Ethereum, provide a basic account model which is unintuitive for most users, called Externally Owned Accounts (EOAs).

In a recent blog post about native account abstraction, we dived into the key challenges posed by EOAs:

• A subpar blockchain user experience.
• Security risks associated with complete control by the private key holder.
• The lack of flexibility due to EOA’s rigid ties with the Ethereum protocol.

To deal with these problems, account abstraction was introduced. Account abstraction redefines how accounts function, offering developers flexibility through customizable “account contracts.” These contracts, acting as smart contracts, employ the three pillars of account abstraction: signature abstraction for custom permissions, fee abstraction for versatile payments, and nonce abstraction for enhanced convenience.

For a deeper understanding of the challenges associated with EOAs and how Starknet overcomes them, visit Native Account Abstraction: Opening Blockchain to New Possibilities.

Session Keys

A particularly promising application of account abstraction lies in the concept of “session keys.” Traditionally, decentralized applications (dApps) require users to individually sign each transaction through their wallet, introducing friction, especially during multiple transactions in a session. Account abstraction introduces the innovation of generating “session keys,” enabling a dApp to autonomously sign transactions on behalf of the user for a specified period and transaction parameters, such as limits on duration and value.

The implementation of session keys presents a significant opportunity for dApps to streamline user interactions. Users can tailor session keys to their specific needs, whether they engage in frequent trading or occasional purchases. This adaptability fosters a more inclusive user base for blockchain technology and markedly enhances user experience in two pivotal areas: decentralized finance (DeFi) and onchain gaming.

DeFi

In the DeFi realm, the current inconvenience of decentralized exchanges (DEXs) lies in the necessity to approve each transaction individually at various stages. However, with session keys, we can replicate the seamless experience of centralized exchanges (CEXs) without succumbing to their drawbacks. For instance, a user could create a session key valid for an hour, allowing trades of up to $7000 on a decentralized exchange without the need for individual confirmation of each transaction through their wallet. This not only simplifies the process but also contributes to a more user-friendly and efficient DeFi ecosystem.

Gaming

The current state of onchain gaming can be described as clunky at best. Rather than imposing the intricacies of managing gas fees or signing multiple transactions on users, session keys facilitate seamless UX, resembling the smooth experience of traditional games. This shift results in a more user-friendly onchain gaming environment, liberating gamers from the hassle of configurations and errors. Gamers can focus on gaming, instead of having to focus more on the blockchain itself.

Conclusion

Ethereum has transformed decentralized applications (dApps) but faces challenges with rigid account structures like Externally Owned Accounts (EOAs). The introduction of account abstraction addresses these issues, offering developers flexibility and enhancing user experience through customizable “account contracts.”

Perhaps one of the most important applications of account abstraction is “session keys,” which streamlines user interactions in DeFi and onchain gaming. In DeFi, session keys eliminate the need for individual transaction approvals on decentralized exchanges (DEXs), providing a user-friendly experience similar to centralized exchanges (CEXs). In onchain gaming, session keys simplify the user experience, freeing gamers from the complexities of gas fees and transaction signatures. Explore more special features enabled by using Starknet’s Native Account Abstraction, and learn Cairo to try it out yourself.

Session Keys: Unlocking Better UX was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR:

• StarkWare and Herodotus have created a way to prove Ethereum blocks all the way back to genesis
• This is accomplished using the power of cryptographic proofs and block hashes
• It achieves the goals of EIP-2935 — a way to access historical block hashes older than 256 blocks in a chain-native way, and unlocks new use cases for Defi and more
• This technology is being brought to Ethereum as a public good by Herodotus and StarkWare

Introduction

Being able to access historical state on Ethereum in a provable way is important — but until now all you could access in a trustless manner was the history of the past hour.

But Starknet is a vibrant, innovative ecosystem that pushes the edge of what’s possible. And now, thanks to Herodotus and StarkWare, you can retrieve — in a chain-native and provable way — all Ethereum block hashes all the way back to the genesis block.

Let’s look in detail at how Herodotus and StarkWare achieved this and what it all means. We’ll start with a background on storage proofs.

What are Storage Proofs?

Storage proofs allow us to prove that a certain state existed at some point in the past, and without having to trust any third party. With storage proofs, trust is built into the mathematics. Storage proofs can also be used to access this state across different chains.

In a recent article on storage proofs, we introduced Herodotus, the team leading the research and innovation of storage proofs. The Herodotus team has now created a way to make storage proofs even better by providing trustless proving of Ethereum all the way back to the genesis block.

Let’s look at how Herodotus achieved this and why it’s important.

Proving Ethereum’s Genesis Block On-Chain

First, we need to understand how Ethereum block headers and block hashes work.

So, What is a Block Header and a Block Hash?

A block header is the section of a block that summarizes all the information kept in that block. It includes the hash of the parent block, the block timestamp, the state root, and more.

Ethereum block header and state merkle tree (source)

There is a lot of information kept inside the block header. For this article, we’re particularly interested in the state root. Let’s look at why.

In the diagram above you can see, just below the block header, the Ethereum Account State. Every Ethereum account has an associated storage space where that account’s variables are stored (essentially, the smart contract’s state). A cryptographic commitment of the account’s storage is hashed and stored as a storage root along with the account balance, nonce, and code hash. Together, this all acts as a basic summary of this account’s state.

A Merkle Patricia Trie of all the Ethereum account states is constructed, and its hash is stored in the block header as the state root (labeled stateRoot in the diagram above). This state root contains all the information you need to prove the state of the entire Ethereum network at any particular point in time.

Finally, since every block on Ethereum (and EVM chains) contains this state root, and since every block also has an associated string called the block hash (which is the result of hashing everything inside the block header including the state root), the block hash acts as a cryptographic commitment of the entire Ethereum state at a particular time.

Historical Block Hashes on EVM

Since so much key information is kept in the block hashes, we often need to access them historically.

In Solidity, if we want to retrieve the block hash of the block that was mined two blocks ago (the backward count starts from the block in which a transaction is included), we use the following syntax:

bytes32 lastBlockHash = blockhash(block.number - 2);

Pretty simple. But there’s a catch — this block-hash method can only retrieve the block hash for the last 256 blocks. With an average of 12-second blocks on Ethereum, that’s 51.2 minutes of history on-chain.

For someone who wishes to use historical block hashes as a source of entropy (randomness), the 256 limit is generally good enough. However, if you want to use block hashes for fetching the historical state of the chain at a specific block, a 51-minute history is not nearly enough (compared to an eight-year history of the Ethereum blockchain).

This 256 limit of on-chain block hash retrieval was primarily a design choice made for state storage efficiency and to mitigate potential state growth problems.

Herodotus Gives Access to the Complete History of Block Hashes

So, how does Herodotus solve this limitation and allow us to:

• access the complete history of block hashes on Ethereum
• prove Ethereum’s state all the way back to the genesis block
• and all in a trustless manner?

The key is the power of cryptographic proofs.

Let’s delve deeper by dividing the Herodotus Historical Block Hash Accumulator procedure into steps:

Step 1. Registering a recent block hash

On the Ethereum mainnet, a recent block hash is registered in a smart contract named the SharpFactsAggregator smart contract. The block hash can be retrieved using the block hash opcode (opcode value 0x40) and saved in the aforementioned smart contract as a simple string variable. The corresponding block number can also be registered for access later on.

Let’s assume that the registered block number is block 18,000,000. From Etherscan, we can see that the block hash of this block is 0x95b1…4baf3.

Step 2. Proving the block hash of the latest block

The next step is to retrieve the block header (from an archival node) for block 18,000,000, compute its block hash in an off-chain computation, and compare it to the registered block hash 0x95b1…4baf3. This calculation is also run through a prover to create a proof of this computation.

The block hash for this block is added to a Merkle Mountain Range (MMR). This is a variation of a Merkle tree such that appending new elements to the tree does not require significant computation.

Step 3. Proving the block hash of block X-1

Once we have proven that the block header retrieved from the archival node is valid, we retrieve the block header for block X-1, compute its block hash, and compare it with the parentHash value for block X. (It is available in the X’s block header that we retrieved earlier).

If the hashes match, we know that the block header for X-1 is also valid. Since this whole computation can be modeled as a function, a STARK proof of this computation can be created simultaneously. Hence, a proof of validity for the block header of block X-1 is created (see diagram below).

Step 4. Recursively proving the block hashes for previous blocks

The block hashes are computed similarly for all the previous blocks until we reach all the way back to the Genesis block — the first block on the Ethereum mainnet. These are all appended to the MMR tree, thus creating a final MMR root.

It should be noted that all of these computations are done off-chain with a simultaneous generation of proof of computation by Herodotus.

Step 5. Publishing of proof on-chain and subsequent use

Once the final MMR root is generated, this root can be published on-chain (on a Proofs Aggregation smart contract) along with the proof of computation for the millions of blocks. Since the generated STARK proofs are exponentially cheaper to verify, the cost of verifying these proofs on-chain is reasonable.

And there we have it! We’ve created a way to access Ethereum’s state all the way back to the genesis block.

These MMRs (called “historical block hash accumulators” by the Herodotus team) achieve the goals of EIP-2935 proposed by Vitalik Buterin and Tomasz Stanczak in 2020 — a way to access historical block hashes older than 256 blocks. This was a problem that had remained unsolved for over three years! And yet, Herodotus and Starknet achieved it without having to make any protocol-level changes.

Some key points to note on the process above:

• Herodotus processes the blocks in batches of ~1350 blocks, and the proof is published on-chain for every single batch. Once the whole process is completed for the first 18,000,000 blocks on Ethereum, the MMR root for the history of the block can be updated periodically as new blocks are added to the chain’s history.

• Once the MMR root is available on-chain, it becomes possible to prove the inclusion of every single block hash in the MMR (that’s a basic property of Merkle trees).
• Before sending the proof onto the Ethereum mainnet, the Herodotus team’s prover uses SHARP, created by the StarkWare team. The primary benefit of the SHARP system is its ability to decrease costs and enhance the efficiency of the generated proofs.
• The workflow described above is being duplicated for two independent MMRs — one that uses the Keccak256 hashing function and one that uses the Poseidon. On Ethereum, the Keccak256 variant will be used, while Starknet will use the Poseidon variant.
• The MMR root for the Ethereum mainnet is also sent to Starknet using the native Starknet L1-to-L2 messaging protocol for use on Starknet. The Herodotus Block Hash Accumulator also enables Ethereum historical data access on Starknet. The Starknet L1-to-L2 messaging system can be used to relay an L1 block hash and the verified MMR root to Starknet in a secure manner. Once on Starknet, storage proofs of historical Ethereum data can be verified against these commitments.

New Opportunities with the Herodotus Block Hash Accumulators

These block hash accumulators are being brought to Ethereum by Herodotus and StarkWare as a public good. Once the final MMR roots are published on Ethereum mainnet, along with proofs of computation, any developer can utilize them for accessing a provable state of the chain for any time since inception.

Since the MMR roots for Ethereum are also going to be sent to Starknet via the native messaging protocol cross-chain, cross-chain state information can be accessed in a simple yet trustless manner. DeFi protocols could benefit from historical state proofs by utilizing the information about a specific account balance or leveraged positions of an account at any point in time. More robust random number generation using a larger history of block hashes becomes possible. Cross-chain voting becomes simplified without users having to bridge assets before they cast their votes on an L2. And much more.

Conclusion

In the evolving world of blockchain scalability, decentralization, and verifiability, teams on Starknet are emerging as beacons of innovation. Projects created in Starknet are becoming key elements in scaling Ethereum. As we delve into this new future, familiarizing yourself with the ecosystem will position you for what lies ahead.

Read more about projects in the Starknet ecosystem here.

Herodotus: Proving Ethereum’s State Using Storage Proofs on Starknet was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

The building blocks for Starknet developers

While Starknet is a Layer 2 network built over Ethereum, it is different from other Layer 2s built on the model of the Ethereum virtual machine (EVM), and so it has many of its own developer tools to support the community of developers that are building on Starknet.

While originally the stack of Starknet development tools was based mostly on Python, there is an overall trend to move from tools built on Python to tools built in Rust.

Here are 7 Dev Tools for Starknet devs:

1. Starkli
2. Starknet-devnet
3. Katana
4. Scarb
5. Starknet Foundry
6. Hardhat
7. Starknet Remix Plugin

Workflow

This diagram illustrates the development process, with the tools that are useful for each stage of development.

Starkli

What is it?

Starkli, pronounced Stark-lie, is a fast command-line interface that replaces the legacy starknet-CLI. Starkli is a standalone interface, that is, you can use it on its own, rather than as a component of another tool. If you’re not actually developing on Starknet and just want to interact, such as by sending transactions, then a standalone CLI might be more appropriate than an interface such as Cast, which is an integrated component of the Foundry development environment.

Who maintains it?

Starknet community contributor Jonathan Lei, the co-founder and CTO of zkLend.

Why should you care?

Starkli is a Starknet CLI similar to cairo-lang but written in Rust. It’s easier to install and to navigate, and has no dependencies. The tool supports Braavos and Argent X smart wallets, and has embedded support for RPC endpoints.

Starkli includes standard CLI functionality, such as the following:

• deploying accounts
• interacting with contracts
• getting Starknet data, such as information about blocks, transactions and more

Starkli also includes the following features:

• compute class hashes from the Cairo file that defines the class
• compute a function’s selector
• encode messages
• auto-completion
• useful help commands
• the ability to make multi-calls

Where do you get it?

For information on getting started, including installation instructions, see Starkli: The New Starknet CLI.

See also:

• The Starkli Github repository
• the Starkli book

SDKs: A window into Starknet

A Software Development Kit (SDK) is a library that abstracts the complexities of Starknet when building transactions and interacting with the blockchain, including the following:

• read and write API calls, using both the JSON-RPC and the Feeder gateway API
• account creation
• cryptography: Signature verification and signing, computing hashes used by Starknet
• contract interactions: ABI import, constructing transactions

There are several SDKs for various languages, so you can choose the SDK according to your preferred language.

LanguageUsed byWho maintains it?Where do you get it?Starknet.jsJavaScript/

TypeScript

Dapps/WalletsShardlabsThe starknet.js Github repositoryStarknet.pyPythonUseful scriptsSoftware Mansion (SWM)The starknet.py Github repositoryStarknet-rsRustStarkli, FoundryJonathan LeiThe starknet-rs Github repositoryStarknet-goGoChainlinkNethermindThe starknet-go Github repository

starknet-devnet, starknet-devnet-rs

What is it?

A devnet is a Starknet instance that you run as a local node, which enables much quicker development than is possible using testnet, as well as providing privacy prior to launching on testnet.

Shardlabs, originally wrote starknet-devnet in Python, but they are now actively developing a version in Rust, starknet-devnet-rs. For now, the Python-based version is more feature-rich, with the most notable feature being the ability to fork the network at a given block, so if that’s important to you, then you need to use the Python-based version. However, starknet-devnet-rs runs more quickly, and the developers are working to bring it to feature parity with the Python-based starknet-devnet.

starknet-devnet-rs is the only version that is receiving new features.

Who maintains it?

Shardlabs

Why should you care?

starknet-devnet and starknet-devnet-rs include some accounts that are already funded with an ERC-20 token that can be used to pay fees. The ERC-20 contract that defines this token is also included.

With starknet-devnet and starknet-devnet-rs You can do the following:

• Create mock accounts.
• Send transactions using pre-deployed, pre-funded accounts, which are included.
• Test tools.
• Test RPC requests.
• Deploy new contracts using an included Universal Deployer Contract (UDC).

What’s next?

starknet-devnet-rs is the devnet to pay attention to, as it is developed in cooperation with StarkWare, and it is the version that is being actively developed.

Where do you get it?

• The starknet-devnet Gitbhub repository
• The starknet-devnet-rs Github repository

Katana

What is it?

Katana, developed by the Dojo team, is an extremely fast devnet designed to support local development with Dojo, which is a gaming engine for Starknet. You can use Katana as a general purpose devnet as well. Katana lets developers test applications locally using the Katana network to test the transactions being sent during the game.

• Katana provides convenient RPC methods that you can use to change the network’s configuration as needed. For example, you can change the block time or allow zero-fee transactions.
• Katana supports version v0.3.0 of the Starknet JSON-RPC specifications, the latest version as of June 2023. Katana lets you use native Starknet JSON calls, such as starknet_getTransactionReceipt, starknet_getStorageAt

Where do you get it?

For information on installing and using Katana, see Katana in the Dojo documentation.

Scarb: The Cairo package manager

What is it?

The official package manager for Starknet.

Who maintains it?

Software Mansion

Why should you care?

It makes life easier in the following ways:

• When installing Cairo packages, it handles adding, updating, and removing dependencies.
• You can use it to compile smart contracts.
• When creating your own Cairo package, it takes care of patching any libraries you need from Github, and lets you know if there’s a version mismatch. You can then use it to build and test your project, using the Cairo test runner. Building is quite fast.
• It includes the Cairo compiler, built-in, so unless you’re actually a compiler developer, you don’t need to set up any extra tooling.
• It includes a bundled binary of the Cairo language server, which you can use
• It works well with other tools in the Cairo ecosystem, such as Foundry and Dojo.

What’s next?

Developers are currently working on improving the way Scarb handles the management of versions, projects, and workspaces.

Where do you get it?

The Scarb site

Starknet Foundry

What is it?

Starknet Foundry is a toolchain for developing Starknet smart contracts. It helps with writing, deploying, and testing your smart contracts.

Who maintains it?

Software Mansion

Why should you care?

Starknet Foundry includes the following features:

• Forge, a fast testing framework. Forge achieves performance comparable to the Cairo Test Runner with a better user experience. You can test standalone functions in your smart contracts and embed complex deployment flows.
• Support for prints in contracts. According to the documentation, the debugging features will follow the addition of support in the Starknet compiler.
• The online Foundry Book, with lots of helpful information and guidance in writing and running tests and interacting with Starknet.
• Integrated compiling and dependency management, using Scarb.
• Cast, which the documentation refers to by its command name, `sncast`. Cast is an integrated CLI specifically designed for performing Starknet RPC calls, sending transactions and getting Starknet chain data. You can use Cast to declare, deploy, and interact with contracts using the Starknet JSON-RPC.

What’s next?

Many new features are coming soon, including fuzz testing, L1<>L2 messaging, and code coverage.

The Starknet Foundry Github repo has a roadmap showing new and in-development features, although it’s not clear if the checkmarks indicate features that are already implemented, or in active development.

Where do you get it?

The Starknet Foundry Github repo

Hardhat (with a plugin)

What is it?

A tool primarily for testing Cairo code. You can also deploy contracts using scripts in JavaScript.

Who maintains it?

Shardlabs

Why should you care?

Hardhat is a popular JavaScript development environment for Ethereum, and if you are already familiar with it and want to use it on Starknet, then this plugin can come in handy. You can run Starknet commands as tasks in Hardhat, such as compiling a Cairo contract.

Hardhat is integrated with a local devnet, so you only need to worry about writing your tests, in JavaScript, of course.

What’s next?

Upcoming features include:

• improved integration with Starknet.js, for a better developer experience
• improved support for the latest Cairo features

Where do you get it?

Get Hardhat at the Hardhat site.

Get the Starknet plugin at the Starknet Hardhat plugin Github repo.

See examples of how to use the plugin at the Starknet Hardhat example scripts Github repo.

The Starknet Remix plugin

What is it?

Remix is a browser-based integrated development environment (IDE) for Ethereum that you can use for learning, experimenting and finding vulnerabilities in smart contracts, without installing anything. The Starknet Remix plugin lets you use Remix for testing Starknet smart contracts, so you can focus on learning Cairo and Starknet without the distraction of setting up a toolchain.

Who maintains it?

Nethermind

Why should you care?

Remix and the Starknet Remix plugin include the following features:

• Integrated compiling.
• You can deploy contracts on any devnet, including the plugin’s own integrated devnet.
• You can also deploy on testnet or Mainnet.
• You can call functions of contracts that you have already deployed, to facilitate testing and interaction.
• Seamless integration with Scarb.
• Integration with block explorers such as Voyager, so you can easily check the execution of your transactions, in real time.
• The Starknet Remix Plugin is integrated with Starknet By Example, a rich repository of practical learning content.

For more information on the Starknet Remix plugin, see Unlocking Onboarding to Starknet: An Overview of the Starknet Remix Plugin.

What’s next?

• Support for testing Starknet contracts directly within the browser.
• An integrated code editor is planned for a future release.

Where do you get it?

To get started with Remix, see the Remix Project site.

To get started with the Starknet Remix plugin, see the Starknet Remix plugin’s Github repo.

Looking for more dev tools, libraries and tutorials? Go to Starknet’s Developers Hub

7 Super Cool Dev Tools for Starknet Devs was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• StarkWare is progressing towards decentralization in two threads: planning and implementation.
• A clear roadmap lies ahead for the steps required to ensure the transition of the Starknet protocol to a decentralized proof-of-stake protocol.

Intro

Starknet enjoys the security and decentralization provided by Ethereum by sending STARK proofs of its state transitions for verification on the Ethereum blockchain. This flow places substantial limits on the power of otherwise centralized entities building and maintaining Starknet, such as StarkWare and the Starknet Foundation: no centralized entity on the network can forge transaction messages that would misstate or otherwise fraudulently manipulate user data or assets.

This is the first and most critical step in ensuring that Starknet is trust-minimized, and that users of Starknet are not reliant on the honesty of any centralized party when they use the network. However, more must be done to ensure full trust-minimization and decentralization, so that even if entities like the Foundation or StarkWare were to disappear, the network would continue to function as designed and without interruption. This post outlines a tentative roadmap for those next steps.

How We Got Here

Just under a year ago, we began documenting our decentralization research process in a long series of blog posts which culminated in a simple concrete proposal.

In short, our goal is to transition operation of the Sequencer+Prover to a decentralized proof-of-stake protocol, whereby anyone can participate in sequencing and such that no party is essential to the continued liveliness of the network. To this end, two necessary threads open:

1. Implementation of the various components required to run the decentralized protocol,
2. A transitional process to gradually decentralize operations to Starknet stakers.

In this post we will focus on the latter.

The Transition Process

In a nutshell, the transition process itself has four main threads:

1. Transitioning to a decentralized network architecture while Sequencer operation remains under centralized operation
2. Ensuring the availability of a fully open-sourced software stack
3. Developing increasingly broad testing and integration networks
4. Fostering Staker onboarding in advance of the final transition of Sequencer operation to proof-of-stake participants.

The numbering represents some obvious sequential dependencies, but a lot of concurrent work is possible. Below we slightly expand with a paragraph for each thread.

Decentralized Network Architecture

The Starknet network will move to a more decentralized model:

• At present, full nodes do not communicate with each other, instead each node relies on periodic queries to the Sequencer through a centralized feeder gateway.
• In a less centralized model, full nodes will be part of a peer-to-peer network that does not require a connection between each of them and the Sequencer.

This change goes beyond the connectivity of the network. Let us illustrate this with two examples.

First, the Sequencer will sign its blocks to alleviate some trust assumptions and prepare for a vote-based BFT protocol with many voters. Second, data propagation will take on a more distributed flavor, with nodes helping each other to sync on the state and complete their local view.

Working towards a Fully Open-Sourced Software Stack

Open-Source Software Stack: Ensuring availability of an open-source software stack is critical to enable everyone to participate in the various aspects of the protocol and the network. As more components are implemented, both by StarkWare and by other contributors, they will be released for everyone to test, criticize, and get comfortable with. Some notable examples (of already open sourced parts of the stack) are full nodes (Pathfinder, Juno, Deoxys), Provers (Stone, Sandstorm), Sequencers (Blockifier, Madara), and Block Explorers (Starkscan, Voyager, ViewBlock, Stark Compass)

Testing & Integration Networks: Increasingly broad testing and integration networks are necessary for a maximally smooth transition process. For each new component there will likely be a progression from an internal testnet, to a slightly broader permissioned testnet with external participants, and eventually to a public testnet, integration, and mainnet. There are some choices to be made later, e.g between sequential and concurrent approaches for introducing testing new components, but that’s for another day.

Staker onboarding: We must give time for the L1 staking contract to accumulate sufficient staked tokens to secure the decentralized protocol with real economic weight. This is to avoid a scenario where a small number of participants with little actual skin in the game maliciously attempt to take control of Starknet.

Conclusion

In summary, we have given here a rough overview of the tentative roadmap to decentralizing Starknet. As with any engineering plan, certainly one of this complexity, it is likely to evolve and change over time as our community of contributing builders develops better insights and understanding.

As always, feedback, suggestions, and criticism are welcome. Feel free to reach out on the Starknet community forum!

Starknet Decentralization: A Roadmap in Broad Strokes was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Starknet is taking the emerging Autonomous Worlds space by storm

TL;DR

• Starknet is a frontier in the evolving space of onchain gaming and autonomous worlds, channeling the power of Dojo engine and Madara to enable onchain gaming.
• Using Starknet’s high throughput and Cairo, a world of possibilities is emerging for devs and users who want to utilize asset ownership and limitless interoperability.
• Multiple teams are utilizing Starknet’s capabilities to bypass EVM limitations and explore new horizons in gaming.

Intro

Autonomous worlds are the convergence of tech, gaming, decentralization, creativity, and innovation. These worlds operate independently and without a central authority, which allows users to engage and explore, create content, and interact, all without permission from anyone and without any concern of censorship.

Starknet has positioned itself as the natural choice for those who spearhead the creation of these worlds. Worlds that need an L1 to ensure they can exist forever, but they also need a robust L2 to cater for their complexity. The combination of Ethereum, as the basis layer, and Starknet, as the scaling and creativity enabling layer, allows these worlds to emerge.

Let’s look at this new frontier of autonomous worlds and onchain gaming and the features that Starknet offers, which makes it so suited for this vision.

What Exactly are Autonomous Worlds?

As mentioned above, autonomous worlds are worlds that operate independently and without a central authority. Some of the key features of an autonomous world include:

• Constant Accessibility: They are always available.
• Multiplayer Interactivity: Allowing multiple players to concurrently explore and have interactive experiences.
• Immunity to Shutdown: Autonomous worlds are censorship-proof, which means there is no central authority that can be told to shut the game down.
• Unrestricted User Engagement: They allow users to independently explore, create, and interact (independently, or as a group) with no central authority.

Players, individually and as a whole, create, control, and play in this world, all on their own. It’s a new frontier in gaming with untapped capabilities and new use cases. It challenges the current conventions in gaming and redefines what is possible. The potential is huge.

But to exist, autonomous worlds must be onchain, on a network that can handle the requirements outlined above. At the same time, they must be highly performant and highly cost-efficient. That’s where Starknet comes in.

The Origins of Onchain Gaming on Starknet

In November 2021, StarkWare released Starknet Alpha, and prior to that, Cairo. The combination of a Validity Rollup that provides Ethereum-grade security, and a new non-EVM compatible language, was a challenge and a puzzle that opened a new world of opportunities. The earliest adopters of Cairo (developers like Perama and Guiltygyoza) started delving deeper into the language, creating guides and experimenting with physics and neural networks. This level of innovation in the Ethereum ecosystem was impressive.

Eventually, the first game on Starknet emerged: a proposal to recreate the classic game “Drug Wars” was submitted, a grant was given, and a fully onchain game engine began to take shape.

Teams such as Realms, Influence, and Briq were among the earliest projects to build on Starknet. They came from the Solidity world, where complex games were nearly impossible to build. Others, such as Topology, came directly as they had heard of the limitations of Solidity. For all of them, though, their visions were finally possible with Starknet. Cairo, as a general computation programming language, lifted barriers that were created by the EVM. Teams got a taste of the flexibility it offered builders.

Escaping the EVM Limit: Online and Autonomous Games on Starknet

Currently, after years of research and iteration, Starknet is one of the first L2s that can sustainably host onchain, high-TPS games. It is the platform where game developers can finally build their complex visions of worlds that operate on a permissionless basis and in a decentralized manner. Among active L2s, Starknet has attracted the largest number of game developers and teams.

Let’s look at two key technologies that make Starknet the premier platform for building and playing onchain games and autonomous worlds — Dojo gaming engine and the Madara sequencer.

Dojo Gaming Engine

In a recent article, we covered in detail the Dojo Gaming Engine — the world’s first provable onchain game engine. Dojo enables Starknet’s gaming builders to provide transparency, provability, and scalability for their games.

The Dojo gaming engine is a software framework for Starknet game developers that helps them create fast, provable games onchain. It provides developers with everything they need to get started creating games and autonomous worlds (such as physics, graphics, and game mechanics).

Dojo is the brainchild of two early innovators in Starknet-based game development — the Cartridge and the Realms teams. Their collaboration was inspired by the insights they gained over a one-year journey starting in early 2021, during which they explored the most efficient ways to build games on Starknet.

Dojo consists of the Entity Component System (ECS) framework, which is a system for blockchain-based game development that promotes modularity, efficiency, and flexibility, and three additional useful tools for game developers: Sozo, Torii, and Katana.

Sozo — Sozo is a migration planner that handles the complex task of deploying autonomous worlds onchain. With a simple `sozo migrate` command, deploying an instance of the game world onchain is possible.

Sozo also has the ability for any participant in the ecosystem to propose new components to the onchain gaming universe by using the simple CLI tool. This is a key philosophy of autonomous games: worlds can outlive the game’s creators, and additional contributors can extend the ecosystem with their own assets, levels, characters, and more.

Katana — Katana is a sequencer built for local game development. Running this sequencer on Starknet enables immense jumps in productivity. Katana enables RPC methods offered by Starknet on mainnet and allows the developer to test with various parameters such as the block time, base fee per transaction, etc.

Torii — Torii is an indexing layer built on top of the Dojo engine that connects the onchain infrastructure with game development clients such as Unity or Unreal Engine. Based on the developed game’s source, Torii can be used to easily start indexing game-specific events and expose a GraphQL API for queries. Simply running `torii` creates a GraphQL API running on http://localhost:8080, ready to be queried.

Madara Sequencer

The Madara sequencer is a high-performance Starknet sequencer that can create highly customizable and efficient appchains, especially suited for gaming. Madara is built using the proven Substrate framework used by the Polkadot ecosystem.

Appchains are a private instance of Starknet that allows developers to control virtually all parameters configured in a network: sequencing, data availability, settlement layer, governance, and more.

Why is this useful? For example, if a game wants to prioritize the speed of player transactions, they could choose to implement a form of First-Come-First-Served sequencing. But if instead, they want to incentivize users to bid higher for quicker block inclusion, Priority Gas Auction (PGA) sequencing could be implemented with a more profit-driven perspective.

With many other possible parameters (such as block times, frequency of settlement on L2, or utilization of non-native data availability solutions), the possibility to launch their games on a Starknet appchain provides devs with choices and power.

Future Features: Offchain Provable Games

Not every action that the player takes must be onchain. For some games, where the user’s actions should not be public before the state of the game changes, an offchain proof of the user’s action could be generated on the client, with only the proof stating the action took place being submitted onchain. Beyond multiplayer games, this infrastructure holds promise for auctions and voting-system applications where you might want to obscure the user’s input data.

Client-side proving also unlocks the possibility for models where gamers try out a hybrid approach: proofs are published, but only whenever something significant happens in-game (e.g., a level is passed or the character finds a rare asset).

Autonomous Worlds in Action — Shoshin

In a previous article, we looked at some of the largest gaming projects built on Starknet — from space colonization strategy games to ‘immutable arcade machines’ enabled by ZK circuits. We reviewed games that can be shaped and continue to evolve with the guidance of their player, even if their creators will not operate them.

One additional example is Shoshin — which has implemented a novel way of onchain gaming where the user programs their character and the actions they take. Once this programmed logic is in place, players can battle with other players’ characters.

All in-game mechanics are executed within the Cairo virtual machine. Shoshin even had a recent in-person tournament in Palo Alto for pioneer gamers. To try out the game, log in to shoshin.gg, and show off your fighting skills by programming a character no one can beat!

Conclusion

With onchain gaming and autonomous worlds, Starknet is not just refining the present state of gaming; It is shaping the future of how games are played, assets are owned, and communities are built.

The likes of eth_worm, Guiltygyoza, and others, are trailblazing the field of onchain gaming and technical innovation. Teams such as Realms, Topology, Influence, Briq, Cartridge, and Madara are building on Starknet, escaping EVM limits.

With these collaborators and many others pushing boundaries, Starknet is poised to lead the way into this new landscape of autonomous worlds.

Want to play a Starknet-based onchain game? Check out Shoshin, an asynchronous 2-dimensional fighting game from Topology.

Trailblazing the Way to Building New Worlds was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Safe and Sound — A Deep Dive into STARK Security

Explore the Full Security Analysis of STARKs

TL;DR

• Non-interactive STARKs start as Interactive Oracle Proofs (IOPs) which are compiled to non-interactive ones in the random oracle model.
• This post explains the recent update to the ethSTARK documentation, which gives a full and concrete analysis of the security of the ethSTARK protocol in the random oracle model.

STARK Security Explained

A STARK proof system (Scalable Transparent Argument of Knowledge) is a powerful tool for computational integrity: it allows verifying the correctness of computations performed on public data in a trustless manner. In this blog post, we delve into the security that is provided by STARK proofs, defining it and exploring techniques to prove scheme security.

(Read Section 6 in the ethSTARK documentation (version 1.2) for full details, and the important and comprehensive independent work of Block et al. on the topic.)

What are we trying to achieve with our security analysis? We would like to prevent a “successful attack” on the STARK system, which is given by a false statement and a STARK proof accepted by the STARK verifier for this (false) statement. Since false statements are dangerous and they can come in all sizes and shapes, we want to be secure against all false statements. Any false statement, even as trivial as 1+1=3, combined with a STARK proof accepted by a STARK verifier for this statement, is considered a successful attack on the system. (Those with a cryptographic background may be interested to know that STARKs also satisfy stronger security notions such as knowledge soundness but for simplicity this post focuses on the simpler case of soundness.)

How do we formally define the security of a STARK system? We do so by analyzing the “soundness error” which roughly measures the expected “cost” that an attacker would need to spend in order to construct a successful attack (i.e., find a STARK proof for a false statement that nevertheless is accepted by the STARK verifier). Mathematically speaking, the soundness error is a function e(t) that gets as input a time parameter “t”, representing the amount of computation time an attacker is willing to spend to mount the attack, and outputs the success probability of the attacker in succeeding with the attack (finding a convincing proof of a false statement). As the “cost” t that the attacker is willing to spend grows larger, his success probability increases.

Thus far we have defined the security of STARKs as a function e(t) which is not the way you naturally discuss security, say, on crypto Twitter. There, you probably heard statements of the form “The scheme has 96 bits of security”. How does such a statement translate to our security definition? There is no one answer to this, as people have slightly different interpretations of “x bits of security”:

• A very strict translation would mean that for any t between 1 and 2⁹⁶, the soundness error is e(t) ≤ 1/2⁹⁶ . This means that any attacker running time at most 2⁹⁶ has a tiny probability of success, smaller than 1/2⁹⁶, which is smaller than one in a billion times a billion times a billion.
• A more relaxed, and perhaps more common, translation is that 96 bits of security means that for any t, it holds that t/e(t) ≥ 2⁹⁶. This means that the success probability is (inverse) linear to the running time. For example, if an attacker has running time 2⁸⁶, its success probability is at most 1/2¹⁰.

In this blog post we will relate to the second option.

From IOPs to STARKs with 96-Bit Security

So how do we prove that a scheme has 96 bits of security? To answer that, we need to understand the high-level structure of how STARKs are constructed. A STARK consists of three main ingredients: an IOP (interactive oracle proof), a Merkle tree, and a Fiat-Shamir hash; the main component we will focus on is the IOP. Once these components are specified, one can compile them to yield a STARK. We will elaborate on these, what they are, and how to assemble them together.

The first component we’ll review is the IOP: An IOP is similar to a standard interactive proof, where a prover and verifier interact for multiple rounds (we limit ourselves to public-coin protocols, where the verifier only sends random challenges to the prover). In an IOP, the verifier does not read the prover messages entirely but instead samples a small number of bits from each prover message. This is what allows the succinctness of the later compiled STARK.

So we have an IOP, how do you build a STARK from it? The prover messages might be long (actually, they are longer than the computation itself). To compress the messages, we use Merkle trees. A Merkle tree is a binary hash tree where each leaf node represents a query or an answer in the IOP. The root of the tree is a commitment to the entire message. When the verifier wants to read a specific location in a message, the prover provides the value at the location and an authentication path. The verifier can then use the path to verify that the value is correct. The IOP verifier reads only a small number of locations from the prover messages. Thus, the use of a Merkle tree results in a succinct protocol (one with small communication).

Compressing Rounds

One may opt for interactive STARKs, meaning but often it is convenient to make them non-interactive to simplify the process of generating them, so that the prover need not wait for external messages when constructing one. Indeed, this is the way currently all STARK systems are deployed, and this is the way the ethSTARK protocol is constructed. Non-interactive STARKs are also a special case of transparent SNARKs (transparency means that no trusted setup is needed to instantiate them; this is also known as an “Arthur Merlin protocol” or a “public coin IOP”). To this end, a final step is to apply Fiat-Shamir to compress the rounds to a single message, which we’ll call the STARK Proof. The Fiat-Shamir transformation converts an interactive protocol into a non-interactive one. The prover simulates the interactive protocol while “talking to a hash function”. To derive the random challenge for round i, the prover hashes the partial transcript up to round i, and interprets the output as the next challenge.

This ensures that the prover cannot change their responses after the challenge has been generated. However, the cheating prover has some new strategy avenues that it did not have with the interactive IOP. The prover can regenerate the verifier challenge by modifying the last prover message, which would give a new transcript, and thus a new challenge as well. As it turns out, the standard soundness notion of IOPs does not suffice to prove the security of the Fiat-Shamir transformation.

For example, consider an IOP with 96 rounds with the following “hack” to the verifier: if the first bit of the randomness of the verifier is 0 in each of the 96 rounds then the verifier accepts (without looking at the proof whatsoever). One can see that adding this hack to the verifier only adds a term of 1/2⁹⁶ to the soundness error of the IOP. However, after the Fiat-Shamir transformation, an attacker can easily modify the prover messages to ensure that each hash begins with a zero, essentially breaking the system within a very short time. Rest assured, this scary scenario is merely a theoretical example, not one that applies to deployed STARKs. So, let’s see why our STARKs are secure after all? In a nutshell, we’ll show that an attacker running at most t steps will succeed in attacking with probability at most e(t) ≤ t / 2⁹⁶. Details follow.

IOPs and Round-by-Round Soundness

A STARK can only be as secure as its underlying IOP. But what does it mean for an IOP to have 96-bits of security? The standard definition would say that the IOP has soundness error 1/2⁹⁶: meaning that the probability of any attacker (regardless of running time) fooling the verifier is at most 1/2⁹⁶. However, as we discussed, IOP soundness is only one component out of three, and this does not suffice to get 96 bits of security for the STARK compiled from all three steps. Instead, security of the compiled STARK is proven assuming the STARK has 96 bits of round-by-round soundness error (sometimes a similar definition called state-restoration soundness is used).

Intuitively, the round-by-round soundness says that every round has 96-bits of security and not just the overall protocol. In more detail, round-by-round says that there exists a predicate that gets a partial transcript of the protocol and tells us if this transcript is “fooling”: The empty transcript is not “fooling”, a full transcript is “fooling” if and only if the verifier accepts it. Finally, for any partial transcript that is not one that “fools” the verifier, the probability that in the next round the transcript will become “fooling” is at most 1/2⁹⁶. If such a predicate exists with these properties, we say that the protocol has 96 bits of round-by-round soundness (the predicate is not required to be efficiently computable).

In many cases, only the soundness of an IOP is analyzed and not its round-by-round soundness. Admittedly, it is hard to think of examples where an IOP has standard soundness but not round-by-round soundness (except for contrived examples). However, the differences between the two might come up when deriving concrete security bounds where each bit matters. Thus, to derive tight and concrete bounds, one must give a tight analysis of the round-by-round soundness of the IOP. This is precisely what we do to the FRI protocol and then ethSTARK IOP that underlies the IOP of our STARKs. The analysis itself is far from trivial and beyond the scope of this post. Using the new analysis, we can set precise parameters for our proofs.

The round-by-round soundness does give us the desired guarantee. The prover can regenerate the challenge many times, but we know that for any round, the probability of generating a “fooling” transcript is 1/2⁹⁶. Thus, if the prover has time t, which is measured as the number of hash invocations, then it can try at most t times to get a fooling transcript, which limits its success probability to e(t) ≤ min{t /2⁹⁶,1}.

Adding All the Error Terms

Finally, for all of this to hold, we need to ensure that the prover cannot tamper with the Merkle tree. One can show that as long as the prover finds no collision in the hash function, it cannot cheat in the Merkle tree. The probability of an attacker finding a collision using t invocations (to a random hash function) is at most min{t²/ 2ˢ,1}, where s is the output length of the hash function (this is due to the “birthday paradox”). This is why we set the hash function to have a length that is double the desired security. Thus, if we have a hash function with output length 192 bits and an IOP with round-by-round soundness of 96 bits, we get a compiled STARK with soundness error e(t) = t /2⁹⁶ + min{t² / 2¹⁹²,1}. In particular, such a scheme has 95 bits of security since the function we use to define security, namely t/e(t), satisfies the inequality t/e(t) ≥ t/(t /2⁹⁶ + min{t² / 2¹⁹²,1}), and the right hand side of this inequality achieves its minimal value at t=2⁹⁶, and for this value of t we have t/e(t) ≥ 2⁹⁵.

Summary

In conclusion, STARKs provide a powerful method for verifying the correctness of computations performed on public data in a trustless manner. The security of STARKs is typically measured in terms of the “soundness error”, which represents the probability of an attacker successfully providing a false statement and convincing the verifier with a proof. To achieve a desired level of security, such as 96 bits, the underlying IOP must satisfy round-by-round soundness, ensuring that every round maintains a high level of security. We analyzed the round-by-round soundness of the IOP underlying our SATRKs which allowed us to derive concrete security bounds.

Safe and Sound — A Deep Dive into STARK Security was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.

Deciphering Cairo VM, CASM, Cairo Zero, Cairo, and Sierra.

Intro

In order to unlock secure and decentralized scaling for Ethereum, Validity Rollups make the verification of batches of transactions vastly more efficient than their naive re-execution. Specialized nodes (called Sequencers) on Layer 2 (L2) bundle transactions into new L2 blocks, while Ethereum mainnet nodes confirm these transactions with minimal effort.

Starknet is a Validity Rollup that leverages the Cairo VM, purposefully designed to optimize the efficiency of Validity proofs. Starknet utilizes STARKs (Scalable, Transparent ARgument of Knowledge) as its proof system, enabling the generation of succinct proofs for complex computations, thus greatly reducing the complexity of on-chain verification processes.

In this blog post, we’ll dive into the different components that make Starknet the most performant L2 by TPS — Cairo VM, CASM, Cairo Zero, Cairo, and Sierra.

Cairo VM

Creating Validity Proofs for general computational programs requires a deep grasp of the complex mathematical principles that underlie STARKs. For every computation, it’s crucial to construct an Algebraic Intermediate Representation (AIR), which comprises a set of polynomial constraints that accurately represent the given computation. Initially coined as “CPU AIR,” Cairo is a virtual CPU and a singular AIR, capable of describing any computation with the same “generic” AIR. The Cairo VM is intentionally tailored for Validity Proof systems and is not constrained by the limitations imposed by the EVM (Ethereum virtual machine).

CASM

CASM (Cairo Assembly) is the machine code that the Cairo VM runs. CASM is translated to polynomial constraints that enforce the correct execution of a program. CASM is a key component in the ecosystem because regardless of what the user sends to the Starknet sequencer, what’s proven is the correct CASM execution.

Cairo Zero, A Breakthrough

Cairo Zero, released in 2020, introduced the world’s first Turing-complete language for creating STARK-provable programs, revolutionizing verifiable computation. Cairo Zero programs were compiled locally into CASM and then sent to the Starknet sequencer. Although groundbreaking, Cairo Zero had a steep learning curve owing to its low-level nature and did not entirely abstract away the underlying cryptographic primitives required to prove the program execution.

Cairo: Cairo Zero, but Better

Cairo (now v2.1.1) overcomes the limitations of Cairo Zero, promising safer, more efficient contract writing. Cairo greatly improves the developer experience with a Rust-like syntax and by abstracting away the limitations that were present in Cairo Zero (e.g. write once memory).
Cairo brings modern programming concepts from the rust world, such as trait/impls, generics, enum matching, without compromising the efficiency of proof generation that is brought about by the underlying CairoVM.

Sierra

With Cairo, came Sierra. Sierra serves as an intermediate representation between Cairo and CASM. This additional layer ensures that user code remains provable in all cases. Sierra compiles down to “safe CASM,” a subset of CASM that is guaranteed to be provable for all inputs. This intermediate layer between user code and proven code is crucial in protecting the Starknet sequencer from DOS in the form of unprovable transactions.

A perhaps surprising benefit of Sierra is, that thanks to this simple intermediate representation, Starknet sequencers may eventually run on native hardware directly instead of going through the CairoVM. To illustrate the power of sequencers executing Sierra, consider the following example: one can use type information from Sierra to work with native types (e.g. u32) instead of working in the prime field of the CairoVM.

Conclusion

Cairo builds upon the foundation laid by CairoVM to revolutionize verifiable computation. With a Rust-like syntax and modern programming languages features, Cairo greatly enhances the developer experience, simplifying contract writing and reducing the chance for bugs. Cairo emerges as a powerful tool driving decentralized innovation.

​​The What’s What of the Cairo World was originally published in StarkWare on Medium, where people are continuing the conversation by highlighting and responding to this story.