Starknet’s second vote is coming - Starknet Alpha v0.12.0

🏛 Governance
1

Starknet Alpha v0.12.0 timeline

We are excited to share that the next vote on Starknet protocol upgrade is just around the corner. Starknet Alpha v0.12.0 is planned to be deployed on integration in mid-June, which will lead us to Goerli deployment and voting in the second half of June!

Starknet Alpha v0.12.0 details

Starknet Alpha v0.12.0 brings a range of exciting enhancements focused on performance and user experience. Among the notable improvements is the introduction of a new Rust implementation for the sequencer. This version is expected to have a significant impact on the network - increased throughput and lower transaction latency.

In addition, this version will include the removal of the PENDING transaction status, which means that the transaction status will progress directly from RECEIVED to ACCEPTED_ON_L2, and the addition of a block hash syscall.

You can find more information here. Expect an additional post diving into all the proposed changes as we approach the integration period.

Starknet Alpha v0.11.0 Reflection

Starknet Alpha v0.11.0 was the first version that was voted on by the community. We learned alot from it and from the community feedback posted in the v0.11.0 proposal forum thread. Read the conclusions and lessons from this vote posted here.

Proposed time frames for Starknet Alpha v0.12.0 vote

Among the lessons learned from the previous vote is that when proposing a new version, certain parameters should be taken into account with regards to its characteristics (i.e. the level of complexity, changes required among various tools, etc.)

  1. Integration period - The amount of time for a stable version on integration
  2. Testnet period - The amount of time for a stable version on a public testnet, before the vote start
  3. Voting period - The vote duration
  4. Freezing period - the amount of time between the vote conclusion and applying the decision on Mainnet
    Screenshot 2023-06-03 at 1.38.28 PM
    Screenshot 2023-06-03 at 1.38.28 PM1430×360 83.9 KB

Note that the time durations are relatively short since the current version of v0.12.0 is significantly more simple than Starknet Alpha v0.11.0 in terms of tools adaption, testing needed, etc.

We appreciate feedback on the suggested upgrade period timeframes for v0.12.0.

New delegation agreement (Optional)

In order to promote delegate neutrality and enable informed decision-making by Starknet token holders, we have created a customized template delegation agreement which delegates are free to adopt. It’s important to note that this recommendation is optional. Delegation remains a completely permissionless process with no requirement to adopt any legal agreements. This is simply a tool for both delegates and token holders to define their relationship in permissionless delegation.

To adopt the template delegation agreement, visit your profile by clicking ‘Delegate Login’ on delegate.starknet.io and edit the ‘Delegation Agreement’ section to include your name in the template. Do not make any additional changes if you choose to adopt the recommended agreement posted.

If delegates choose not to adopt the specific terms proposed, we encourage them to clearly define their own terms and decision-making processes they adhere to both in their delegate profile and delegate agreement. While our template agreement serves as a helpful starting point, delegates should explore a variety of approaches and are free to express their own terms.

The delegation agreement TL;DR

  • The agreement is unilateral and if a token holder or a delegate choose to adopt it, both parties will be bound by the terms of the delegation agreement by executing a delegation.
  • Token holders will not exercise influence or control over the delegated tokens, allowing the delegate to exercise independent judgment in voting.
  • Delegates agree to:
    • Participate in governance in the best interest of the Starknet protocol.
    • Conduct due diligence, monitor community discussions, and review proposed changes to the protocol.
    • Not accept any payment or value that could influence their voting.

The ability to adopt a delegate agreement allows each delegate to define their relationship with those who chose to delegate to them. It also gives token holders clarity on the relationship between themselves and a selected delegate. Again, this is an additional tool available to delegates and is not a requirement for being a delegate for Starknet governance.

Call to action

  • We would be happy to hear feedback in the discussion following this thread.
  • If you are interested in becoming a delegate, now is a great time to step forward!
  • Stay tuned for further updates, including the specific timeline and details regarding the vote on Starknet Alpha v0.12.0.
  • Join the Starknet Snapshot space and turn on notificiations to stay up to date with future votes on network upgrades

Cheers,
Deven Matthews
Starknet Governance Committee

3

Finally, 0.12 is coming!

4

I coundn`t agree more. this form becomes more transparent, and everyone can see the levels of difficulty of implementing an update of this magnitude

5

Reminder that the purpose of this post is to collect feedback on the recommended upgrade phases. If there is are not significant, reputable concerns raised, this upgrade framework will be adopted for the upcoming v 0.12.0 vote.

6

Hopefully the transparency can be more pronounced.

7

Adopted the agreement,

Just curious whether a 9 day observation window on Goerli is sufficient : )

8

I appreciate transparency in the deployment process.
But should delegates expect any critical info about testnet deployment right before voting begins? Then there should be a delay between the 2nd and the 3rd phase. It’s more about the future, not the current deployment.

Also, to increase voting activity (in some way to make the protocol more decentralized), it makes sense to increase voting time to 7 days.

Creating a separate topic for the new delegation agreement would be clear as the title and subject are slightly different.

9

0.12 is a special one, can’t wait to surf in starknet via 0.12

10

The hope is there is no new critical information that should arise between test net deployment and voting period. If there are bugs that are discovered, or it is found tooling is not up to date, the defined periods should be re-assessed, potentially postponing the vote.

The outlined processes are meant to act as a minimum requirement best case scenario. New information discovered during test net period would definitely require a reassessment before moving to vote.

As for the delegate agreement, at this time it isn’t mission critical, but will definitely boost it as a stand alone topic in the future as we expand on delegate tooling.

11

[UPDATE] Starknet v0.12.0 Upgrade Schedule

As mentioned in the post, the above was a suggested timeline for the v0.12.0 upgrade. As we enter integration period, a 16-day upgrade cycle would likely have a major upgrade falling during ETHCC and StarknetCC. This affects the developer communities ability to have ‘all hands on deck’ during a major Starknet mainnet upgrade.

To avoid this, the following revisions to the Starknet v0.12.0 upgrade periods were recommended by the StarkWare team and accepted by the Builder’s Council and Starknet Foundation. We are now bringing it to the community.

  • Frozen Integration - 6 days (and not 7)
  • Goerli - 7 Days total (and not 9)
  • After testnet deployment, before opening the vote - 1 Day (and not 3)
  • Vote period - 5 Days (same)
  • Freeze after vote, before deploying mainnet- 1 Day (Same)

Totaling to 13 days instead of 16 days total on Goerli + integration.
and 7 days instead of 9 days on Goerli before a mainnet deployment.

I’ve included an updated graphic to reflect the new schedule.

image
image1988×516 105 KB

Keep in mind the testnet deployment remains live and testable during the vote period. Delegates + token holders are able to change their cast votes until the end of the 5 day voting period.

The community is working to ensure all relevant tooling is updated to support testing of the Starknet v0.12.0 upgrade. Would recommend reading the Starknet v0.12.1 spec posted in the community forum by @EvyatarO and watching the v0.12.0 community call as we approach Starknet’s Quantum Leap.

:point_right: :point_left:,
DevenMat

12

Test vote is now open on Snapshot.

Note that we expect a much wider set of participants in the upcoming v0.12 vote. This is because more teams building on Starknet have gotten access to STRK voting power through channels like EAG, and more token holders have chosen to delegate their voting power (including expanding SNF delegation).

As we anticipate more voting addresses participating, it’s important that all those who plan to vote ensure they are able to do so smoothly in a test environment. Please help us test the governance infrastructure prior to the 0.12 vote.

The timeline is as follows

  • July 4th → deploy v0.12.0 to Goerli + open test vote (done)

  • July 5th → start v0.12.0 vote

  • July 10th → end v0.12.0 vote

  • July 11th → freeze period

  • July 12th → deploy v0.12.0 to mainnet according to vote results