Haven’t vote power at least there I will say, that I’m supporting update, had many experience with slow transactions and even waiting for transaction to come through.
Onchain confirmations time has been a pain. I think this proposal should pass to speed up confirmations. Sadly I have no voting power to help push it.
I vote for the great upgrade though I donot have vote power. It’s a milestone for starknet
I am excited to use StarkNet after the upgrade as it will attract more users. It’s time to bid farewell to Stucknet.
More TPS daddy 
Hello everyone,
First of all let me express my gratitude and respect for the starkware and the Lamda team, for their great effort to push starknet once again a big step forward.
I will here justify my ABSTAIN vote:
- It results from “mixed” feelings i have of this update:
The increase in throughput is more than impressive and NEEDED having in mind starknet s increased use over time. - However the release feels independent from the rest of the network’s components. My major concern is with the persistent lack of good and organized documentation. Which is amplified with the recent frequent releases of updates. For instance i had a hard time explaining a team member (who is an experienced blockchain developer) working on the app side how to install cairo, and more importantly which version to use for what and which not as the lib functions aren’t available, or version 2 of the compiler wasn’t deployable, where to search for information as there are a lot of different resources… It was a mess, which should not be if our goal is to attract more people to the community.
As the RPC issue is not critical, and the increase in TPS is very needed, i believe we should upgrade mainnet to 0.12 but the trend of unorganized and missing documentation should be fixed.
This is great feedback. Have you raised your documentation concerns with the StarkWare team directly yet?
Voted in favor.
welcome the changes such as Parallelization and No More Pending Transactions but we need to focus more on documentations, as others have mentioned above.
Would also suggest for longer voting period, 5 day feels rushed even for non-prod changes.
This deployment is a YES for me as most people use goerli which makes is easily accesible to wide range of users. Also to testing for performance and scalability to ensure top efficiency is never a bad idea. again it is a YES for me
Not yet, i had a discussion with someone from the builder’s council tho, but i would be more than happy to share my thoughts concerning the documentation with starkware.
Another issue that i would like to raise is that 5 days is not enough to test out such an upgrade in my opinion as its a pretty busy period for devs. Personally i only tested out the increase in throughput by executing a few tx’s on a few occurrences. Which i wouldn’t estimate enough to confirm the improvement with confidence.
Hi folks! The Builder’s Council has met and decided to vote FOR on the Mainnet upgrade to alpha v 0.12.0, with some remarks to improve the process and level of confidence in future release. We’re excited about the increase in TPS!
Context
- The Builders’ Council is an assembly of 17 builders selected by the Starknet foundation for their contribution to the Starknet ecosystem (Builders Council post).
- The Builders’ Council holds 1.2Bn worth of voting power, representing 23% of the voting of the 1st phase of Starknet governance (First Phase of Governance post), delegated to this address: builderscouncil.starknet.eth.
- Voting happens with a single majority vote among the 17 voters, according to the criteria below.
Voting method
- Each member of the builder votes FOR/AGAINST/ABSTAIN on the following criteria, then gives a final vote (FOR/AGAINST/ABSTAIN)
- Stability: is the upgrade usable and stable enough in terms of usage, documentation and tooling?
- Features: does this upgrade introduce interesting features that would enable new capabilities on Starknet? Are they sufficiently tested?
- Security: Does this upgrade provide the sufficient level of reassurance that it will not introduce security risks to the Starknet network?
Voting results
- Stability:
- FOR: 15
- ABSTAIN: 2
- AGAINST: 0
- Features:
- FOR: 17
- ABSTAIN: 0
- AGAINST: 0
- Security:
- FOR: 11
- ABSTAIN: 6
- AGAINST: 0
- Final vote:
- FOR: 16
- ABSTAIN: 1
- AGAINST: 0
Comments
The Builder’s Council is excited about the new features and performance improvements introduced by alpha v 0.12.0. Council members have been able to attest that Starknet’s testnet is indeed significantly faster with this upgrade and are excited to see these improvements carry over to mainnet. The Rust rewrite of key components does not only improve the current performance but will help reap incremental improvements in the future. This is why the Council has unanimously voted FOR this upgrade and would like to thank the StarkWare and LambdaClass teams for their work which will bring Starknet to new heights.The Council also notes improvements in the communication of the release and the scheduling of the vote on this second community-enabled upgrade. The Council would like to point out that an issue with the RPC was identified during the launch to testnet and, in our mind, should have been avoided with better testing and communication. Part of the release notes are still lacking in documentation and reflect poorly on an otherwise anticipated release. Finally, the Council would like to stress that, although benchmarks have been shared by the StarkWare team, the lack of testing on real use cases using mainnet data reduces the actual improvements that will be reaped with production apps on mainnet. As far as the Council knows performance tests were performed using ERC20 transaction tests, but Starknet, thanks to account abstraction and high computation capacity, needs to ensure that complex transactions and multicalls can improve as well. The Council will expect a clear set of benchmarks to be used every upgrade to better track speed improvements and increase confidence in its votes. Please find below the action points a list of benchmarks the Council would recommend for future upgrades.
Action points
| Issue | Proposed remediation |
|---|---|
| RPC specifications not up to date | Crema, Clément, rmzls, coburn, petarcalic99 and lyskey have expressed concerns regarding the breaking changes of the RPC spec brought about by v0.12 and the Builders’ Council agrees that, although these are not critical changes, they decrease the stability of the release. In the future the Council would prefer these changes are communicated, documented and agreed upon by the community. The Council is happy to help with a smoother process on the next upgrade. The council notes that this should not be considered a blocker for the release. |
| Performance improvement benchmarks are not using real production data | The benchmark shared for v0.12 mention ERC20 tests show a clear improvement in TPS numbers, which prove the upgrade brings about performance improvements. The Builders’ Council had expressed with StarkWare the desire for benchmarks from version to version using production data coming from real network usage and DApps running in production to be able to assess the release and vote with a high degree of confidence on the actual improvement v0.12 will bring about on mainnet. |
| Changes and release should be better documented | For example the release details of the latest version of the Cairo Compiler only mentions “Cairo Compiler” but doesn’t detail the changes brought about by this update. The Council has already mentioned the RPC changes and also notes that changes to the ABI were brought forward but not properly documented. We very much agree with petarcalic99 that “As the RPC issue is not critical, and the increase in TPS is very needed, I believe we should upgrade mainnet to 0.12 but the trend of unorganized and missing documentation should be fixed […] if our goal is to attract more people to the community.” |
Performance benchmarks & tests
- Measure average, median for:
- Blocktime
- Cairo Steps per Second (CSPS)
- Transactions per second
- Using consistent data replayed from Mainnet activity, taking inspiration from LambdaClass’ speed benchmarks for the Cairo VM, Starknet in Rust and Prover.
Thank you very much for your time, and let’s get more TPS
Staknet’s Builder’s Council
I have been trying to join the discussion but foe some reasons i cannot. First of all the sycall function is the most intriguing for me. I have tried to use it on testnet but i still cannot use it. I will vote yes for this proposal. Deployment on mainnet is a win for all starknet community. I still vote yes