[Proposal] Starknet Alpha v0.12.0

Hey every one !

Here are the key elements guiding my vote : a pragmatic choice but some highlights

  1. Dapp Deployment: The v0.12.0 update is particularly stable on the dapp side, displaying no significant bugs since its deployment, (we faced some ux issues because of the speed and the delay of the indexer)
  2. RPC and UX: Although the RPC is not delivering as expected due to the delta with Gateway, I perceive it as a non-critical issue rather than a blocker. lets move forward and fixe on the way
  3. Vote Timing: The voting timeline does feel rushed, which leads me to stress the importance of thoroughly discussing and understanding potential watchouts like the RPC issue before casting our votes.

In future votes, I recommend presenting potential risks and mitigation strategies beforehand to facilitate informed decisions, for me roadmap and technical desc is not sufficient we should have an operational approach here imo.

I am available to support in developing this structured approach to voting.

LFG daddy !

Dear Starknet Governance Committee and fellow DAO Members,

I appreciate the dedication and continuous effort to improve and upgrade our Starknet protocol. However, I would like to express my concerns regarding the absence of adequate documentation for breaking changes to the RPC API. These concerns have led me to cast a ‘AGAINST’ vote for this upgrade and I’d like to explain why.

I see there is a lot of non technical people here so let me explain,

In the world of software development, documentation is not just an optional extra but a critical component that ensures reliability and usability of the system for its users. When API changes occur, especially those that are breaking in nature, they need to be properly documented to ensure developers are able to adjust their software accordingly. Without such documentation, systems may break and services can be disrupted, leading to user dissatisfaction and potential loss of reputation.

This happened to our team, for example getSimulateTransaction changed it’s input data. Before it was only a transaction, now it is a array of transaction with a new type field inside the transaction. The data returned also changed, which had me update all my tests and mock data all within a week before update is applied to mainnet.

Unfortunately, the provided documentation and blog posts related to the Starknet Alpha v0.12.0 upgrade do not seem to address these breaking changes.

This is not the first time we have faced this issue. It is crucial that we as a DAO address these issues proactively to prevent recurring lapses. We should insist on complete and thorough documentation for all upgrades, including details about API changes, to ensure all teams can continue building on Starknet without unforeseen disruptions.

It is my hope that we will use this opportunity to improve our process and insist on better API documentation moving forward. If these concerns are addressed in a satisfactory manner, I am more than willing to reconsider my stance and support this upgrade. But for now, for the reasons stated above, I cannot vote in favor of Starknet Alpha v0.12.0.

Thank you for considering my viewpoint. I look forward to our continued collaboration as we strive to make Starknet the best it can be.

I am not the most technical person, so I am keen to hear from devs and builders on what they think of the upgrade. From a user point of view, this is a no-brainer, but I do not fully understand the security or decentralization implications of the upgrade.

Having used the testnet I am pleased with the upgrade and would vote ‘yes’.

So voting a YES. I think need more convenient setting of fees and transaction speed on network starknet

I stand by the proposal and I hope it helps to resolve current issues to increase adoption of Starknet network, because it isn’t very user-friendly right now

I tend to agree with Clément.

The performance improvements are impressive, and both StarkWare and Lambda Class have done a tremendous amount of work. Congratulations to them!

However, I have concerns about the reliability of the RPC. If there are any problems on the day of the eagerly awaited update release of our ecosystem, Starknet’s reputation will suffer. In my opinion, there is no need to rush.

I abstain on this vote. I will vote yes once the RPC issue is resolved.

I’m not a technical person but the improvement made to the testnet is really impressive and if everything goes well mainnet needs to be upgraded as well. Currently, transactions are taking more then 30-40 minutes to complete! Of course, blockchain will still need improvements but this is already a major improvement and it shall come to mainnet.

I’m afraid we will have a wave of deception if the RPC is still not reliable.
We need more public RPC, and ability to change it easily in the two major wallets on Starknet.

If user can’t send tx because of the RPC, then more TPS will not help.

I don’t have any token so i can’t vote, so i’m just posting my 2 cents here.

Thank you for raising this point Clement - you make a fair point.

I raised this issue with the Starrkware team directly to get a feel for their thinking on the matter. I am not technical so my understanding is limited, but from what I can gather -

  1. Starkware are taking this issue very seriously.
  2. The issue doesn’t put the network at risk.
  3. Apps that didn’t use “pending” before won’t break. Instead, they will experience the same delay as before.

Therefore unless any new information comes to light, I don’t think this is a showstopper, and therefore I am voting YES

You also make a fair point!

When I voted NO, I guess that there was 100% YES and more that 100M STRK staked, so my NO was more to raise a flag than to actually try to stop this update, which I indeed think needs to be done! (maybe I should have ABSTAIN instead).

The simple message is: as a builder who migrated to full RPC already, without any change in your codebase, you (and your users), don’t benefit from the upgrade. This is a bit shocking regarding the fact that the RPC is the recommended way to go and that the Gateway is deprecated.

As a delegate of the builders, I feel that I did my duty reading some responses that show a similar concern wrt the RPC.

I believe the message got through; and now, :point_right::point_left:, wen 0.12.1 :rocket:

I completely agree with you - it is great to surface these things and I hope you continue to do so in the future. Are you already speaking to the StarkNet Builder’s Council about the RPC concern and next steps?

hey starknet fam,

I voted ‘FOR’ the proposal, I understand the concerns from other delegates about the RPC’s and removal of the pending status, but in my opinion, I don’t think these concerns should be a show stopper for v0.12.0. Gateway won’t be deprecated before these RPC issues have been resolved.

The syscall function is very awesome as it will make for easy look ups of transactions in their respective block hash to 10 previous blocks. Someone can throw more light on this firvne right?

I dont have any voting power but I support the deployment on mainnet too. The syscall function for getting the block hash is very superb. Can’t wait to see it.

My vote would be yes, if I could vote. Goerli is perfect for testing. Once it’s ready go ahead and deploy the real thing. You guys are going in the right direction.

Recently there has been a growing call in the community to improve performance. Due to the growth of the user base, the number of transactions processed by Starknet per day is also increasing, and to accommodate more users, it’s time to improve its TPS

I couldn’t wait to use it after upgrading to V0.12.0 on the testnet. Its TPS has improved dramatically compared to the previous version, thus boosting my confidence in this upgrade,I hope it will be deployed on the mainnet soon. Anyway, this is a step we have to take. I believe further improvements to Starknet from Giga Brains will provide a better experience for us.

more TPS daddy​:point_right::point_left:

I vote for

Support network upgrade is sure, the current experience is too poor to attract more users, I hope that after the upgrade can solve the current high gas fees and frequent failures of the pain points, I hope starknet is getting better and better

I vote “Yes” for the proposal. Changes of the 0.12 update are improving user experience because of the increasing speed of txns.

Would love to vote “yes” since 0.12 update seems to be improving the chain in regards to speed, but right now I don’t have any voting power…

I support the Mainet upgrade. The congestion has been a pain for normal users and as soon as we can upgrade (with proper testing prior of course). The better the experience will be & it will be easier to attract future users.