StarkNet Roundup #36

Weekly summary of all things StarkNet

Oct 10, 2022

This newsletter is made possible thanks to Braavos Wallet! Braavos is a StarkNet wallet made for an intuitive and safe start in crypto available on Android, iOS, Chrome and Firefox.

Check out Braavos Wallet now

Braavos is hiring!

If you are a strong developer with a keen interest in making crypto accessible to everyday users apply now via: jobs@braavos.app

Welcome to the 36th edition of my weekly comprehensive StarkNet summary. The previous update can be found here. 👇🏻

Swagtimus.eth🦇🔊L2'22’s Newsletter

StarkNet Roundup #35

This newsletter is made possible thanks to Empiric! Empiric is the first live oracle on StarkNet, and the leading provider of robust data feeds to the ecosystem today. The network is powered by data partners that include Alameda Research, Jane Street, Gemini, and CMT, is offering VRF and will be offering new data verticals soon. By leveraging StarkNet‘s…

2 years ago · @Testnet_Digger

Would you like to sponsor this newsletter? Reach out to me.

If you enjoy this newsletter, don’t forget to subscribe. It’s free!

Let’s get into this week’s news! 💪

StarkNet Community & Shamans Highlights

StarkNet Community Call #24 | Presentation by Cartridge

Regenesis state migration - Current suggestion

In this post, we want to share our current thinking on how the actual migration would look like during StarkNet’s regenesis. Our goal is to create transparency and use your feedback to improve the mechanism and reach a solution that will be the least disruptive and allow applications to launch on StarkNet Alpha before the regenesis.
We highly recommend you read the Regenesis Update 11 to undersrand the scope, timeline, and code migration before deep diving into this post around the state migration.
Wen Regenesis? The overall timeline
End of 2022 - introducing Cairo 1.0 language
Beginning of Q1 2023 - StarkNet would support the deployment and execution of Cairo 1.0 contracts.
A few months after that - blocking Cairo v0 deployment and interactions
We intend to have a fully alive and functional system in which contracts are gradually and seamlessly updated to Cairo 1.0 without breaking anything. At the end of this period, transactions attempting to call Cairo v0 code would fail.
We next detail the mechanisms that would allow us to achieve that - and what you, as the dapps developers, would need to do.
Moving forward with a backward compatible state
The fundamental feature allowing us to replace the contracts without breaking anything is preserving all contracts’ addresses. For example, imagine that your account contract owns three types of ERC-20 tokens and that you upgrade the account to Cairo 1.0. If you keep the same address, this change is transparent to the ERC-20 contracts. But if your address changes, the state of these contracts also needs to change.
The second thing we will apply to make this possible is backward compatibility of the storage layout. This means that the place in the state in which StarkNet stores variables won’t change between the Cairo v0 and the Cairo 1.0 versions of the contract (assuming the variable name and type is the same). Thus, developers can upgrade their contracts’ code, and things will continue to work without changing the contract’s state. To leverage on this invariant and guarantee a smooth transition, the dapps developers will need to verify that variable names in the new implementation match the names in the current one.