Referendum #456

Showcasing Polkadot’s Capabilities: The Spammening Test Run

Medium Spender
3mos ago
15 Comments
Executed
Content
AI Summary
Reply
Up
Share
Request
2,860KSM
Status
Decision14d
Confirmation1d
Attempts
1
Tally
75.2%Aye
51.6%Threshold
24.8%Nay
Aye
522.92KKSM
Nay
172.7KKSM
  • 0.0%
  • 0.0%
  • 0.0%

Threshold

Support(1.23%)
187.77KKSM
Issuance
15.24MKSM
Votes
Nested
Flattened
Calls
Call
Metadata
Timeline6
Votes Bubble
Statistics
Comments

This test can be done here, on Kusama , Polkadot after Kusama

Edited

Reply
Up

I'm all for it, this is an easy way to show that Kusama is able to handle high TPS before we actually test it on Polkadot. The team is known, capable, and from my information already did all the needed previous work.

Reply
Up

Hey Luke, idk why you're trying to change my vote or question my voting power. Also I don't have nearly as much time to invest in writing nor reading walls of text. My way of voting and promoting open gov proposals is mostly based on:

  • my values
  • my experience
  • my network

I know the ppl behind this proposal, I trust them, I want this to happen both on Kusama and Polkadot, bc I think it makes sense. That's it, no 4d chess needed.

Reply
Up

Whatever happened to Kusama's vision for embracing chaos and risks? The requested KSM is going back to the treasury and whatever is left will also be returned to the treasury. This proposal should pass. Our TPS metrics shared on crypto Twitter are a joke. Let's show our prowess through this proposal.

The largest ever recorded TPS on Polkadot is 112 TPS. This proposal aims to improve this number by 6-8 X. Think and vote. https://chainspect.app/dashboard

image.png

Reply
Up 2

AYE.
We need a real benchmark, i mean a real one on prod infra.

Other chains are dealing with theoretical numbers, the tps narrative is all based on "i was told this chain makes 1000 tps, 10 000 tps", but no one ever saw these numbers.

Show me the code, show me the proof.

It's our time to show what we can do and end this endless debate.
Other chains will have to do the same or they are just talking cheap.

Edited

Reply
Up

I really think we should make this happen for the marketing purposes. We can also re-use these numbers later to compare to JAM. Not doing this compared to other spending seems absolutely crazy. I will address some of the questions because it seems like a problem here.

@ltfschoen
14. UIs should allow to specify tip for the transaction if the chain is congested it would be nice to see how we can handle this in general i.e. polkadot.js apps does allow this. I believe that this will be widely marketed on twitter and in the discord accounts to prevent confusion. As stated before, there will be no tips on the spammening transactions, so that anybody can include their transactions with minimal tip.
15. Transaction fee ramp up function is slow and it's not gonna affect the price that much. https://research.web3.foundation/Polkadot/overview/token-economics#2-slow-adjusting-mechanism if I count correctly it's gonna change maximum 75% per day as per these settings https://github.com/paritytech/polkadot-sdk/blob/df12fd34e36848a535892b1e88281faa59bf34b6/polkadot/runtime/common/src/lib.rs#L96
16+. (Conflict of interest) I would expect the script to have pre-defined start and end block set publicly before the script is started to prevent confusion and enable other agents to conduct their own tests. Also, the notion of selecting time for specified validators to pick up extra fees is trivial to solve and is also very unlikely to ever be a problem as it would require crazy amount of work for gaining small amount of funds and destroying reputation which doesn't make any sense. The block production lottery is selected in the epoch before and thus is unpredictable if the blocks are selected upfront.

All in all @Amforc is publicly facing respected member of the community, running multiple services, attending conferences and promoting the ecosystem as a whole. I trust that he is doing this for the good of the community in his spare time and for free because he cares. It would be ridiculous for him to destroy his reputation for this.

Side note: Proposals like these failing sends a bad signal to people wanting to do something cool, as the grift passes relatively unhindered and this has to go through 3d chess politics and scrutiny to pass. It is really demotivating. We should find a way forward from this situation otherwise the cool things won't get even started or fail on governance.

Reply
Up 2

@ltfschoen I think that 17. is a no concern if the block is chosen upfront enough (at least one day) I would not try to randomize it as that brings more problems and questions than it helps. Also Kusama has 1000 validators. There will be 300 blocks built in the period of 30 minutes. That corresponds to (2860/300)*0.2 = ~1.9KSM per block for validator... I think even if in the scenario they land couple of these blocks, this is absolutely non issue and I would consider it as thank you for making this work. I think we wasted more money in time by even talking about this.
27. The chance of Kusama network stalling is slim to none. There were multiple occasions where there were multiple full blocks including the famous Remark spam back in the day, and if this would happen, it would mean all of the testing and protection measures failed which is very bad for the developers which I'm sure will be watching this also so they will be up to fix it. In any way, parity runs multiple testnets to try to simulate these scenarios with replicated states and I am sure putting transactions to the chain is zero concern. Kusama at the moment has very low traction and doing this is something that can get it on the map.

Edited

Reply
Up

I got this tattoo the last year in honor of this damn referendum, before I even knew about it 💦.
Expect Chaos on Kusama please. Be kind, make decisions and act, do not argue about unnecessary things, no one has to prove how intelligent and blameless they are, move. Thanks.
IMG_5195 (1).jpg

Reply
Up