A brief intro to Starknet’s Lineup for a Championship Win in Rollups

Starknet is undeniably the only future for on-chain gaming.

So let’s be clear. STARKs are superior.

There comes a point in any game developer's life when you want a better machine. More powerful, stronger, faster, and more reliable. Thankfully for us, Starknet provides these features in comparison to EVM at large.

The workarounds I’ve seen in the EVM community to avoid the contract size limit are laughable. We even went so far as making the diamond pattern the absolute must for games, because god forbid a contract went over the ~26KiB limit.

This is not how we’re supposed to build the future right? No. Strap in.

So, why STARKs and not SNARKs?

There are a few basic reasons. You’ll hear them often:

Quantum Resistance — Starknet uses hash functions instead of elliptic curves.

No trusted setup (Transparency) — even though some SNARKs allow for open ceremonies where randomness is drawn from the crowd, it does come with its own efficiency drawbacks. STARKs don’t. They have a reference string that’s public and that’s that.

Scalability — This is our personal favorite; STARKs have a logarithmic verifier and prover. Yes, you heard that right. Read on.

What does this logarithmic complexity prover & verifier mean?

Well, large circuits in the past using ZK-SNARKs would generate proofs linearly. Meaning that at some point they would get so incredibly heavy and slow to generate that they simply just would not be able to provide serious computational power for large-scale programs. Given that PC games are at large to blame for the arms race of computer processing. Yes, we’re going to need it.

The proof is in the pudding.

With SNARKs, users have not been able to create the absolute behemoths that are being created with Cairo on Starknet. Entire game physics engines, EVM interpreters, and more are currently being worked on.

Yes, the significance is that severe.

When dealing with O(N) proof generation complexity in SNARKs vs O(log N) in STARKs, there is a clear winner for creating large-scale distributed applications, which is exactly what we like to do.

Now you might be thinking; “Sir, there has to be a tradeoff, but polygon zk-EVM?? zk-Sync!”

Yes, the verification time for STARKs is larger and more computationally expensive.

Does this matter?

Not really.

Many transactions can be batched into one proof before being verified on L1. Proofs can also be recursively proved into each other, creating one single proof out of many.

In terms of proof generation…

STARKs are generally heavier to generate than SNARKs. This is partially due to many of the processes involved in STARK generation relying often on heavier arithmetic operations such as FFTs. It really doesn't matter very quickly. STARKs outpace SNARKs like Canada against the Jamaican bobsled team with a 20 second head start.

This is where happiness and rainbows come in.

It turns out FFTs are used pretty much everywhere, from music creation software to biological research. They are actually one of the most optimized functions on the planet.

Not only are they greatly optimized in both software and hardware, but they are also extremely parallelizable.

FFTs have a computational complexity of O(N log N), but given an amount of cores P. The right setting. Without taking into account load balancing and other higher-level operations, you can reduce the complexity to O(N log N / P). Wow! This is a significant amount.

Many of these techniques are not in the field yet, but they soon will be. Hardware acceleration alongside FFT parallelization, will be the rocket attached to Moorse’s law that makes Starknet future-proof.

In conclusion, yes Starknet absolutely rules. If the EVM interpreter is

@KakarotZkEvm, and the blazing fast sequencer is @MadaraStarknet, then @Starknet is One Punch Man. Just wait till you see what happens when these three badmons team up.