En de mogelijke effecten van K=1000
Vandaag wil ik u iets laten zien waar ik aan heb gewerkt met betrekking tot de K- en minPoolCost-enquête
Als business (data)analist geloof ik in meetbare argumenten. Vooral als het gaat om zaken als het wijzigen van de beloningsformule. Je zou kunnen stellen dat het veranderen van iets dat een groot wiskundig aspect heeft, op zijn minst ondersteund moet worden door ENKELE gegevens. Anders zouden we deze zeer belangrijke formule puur op onderbuikgevoelens of aannames uit het verleden kunnen veranderen, terwijl we de beschikbare informatie negeren.
Terwijl ik probeerde te beslissen op welke optie ik zou stemmen, begon ik 3 gegevensbronnen te verzamelen en ze te combineren op een manier die me zou kunnen helpen beslissen wat volgens mij het beste is voor het protocol.
Deze gegevensbronnen waren:
Mijn doel was om te proberen een idee te krijgen van wat er met de verschillende pools zou gebeuren als K zou worden verhoogd. Hoeveel enkele pools zouden verzadigen en hoeveel inzet zou dat zijn. Idem voor de Multipool groepen.
Ik heb deze gegevensbronnen gecombineerd en 5 interactieve Google Looker Studio-dashboards gebouwd.
Hier is de link voor iedereen te gebruiken:
Dit eerste ruwe rapport hielp me een stemkeuze te maken waar ik me prettig bij voelde. En die ik mijn afgevaardigden kon uitleggen.
Na het uitbrengen van mijn stem en het delen van mijn argumenten op Discord, Twitter en tijdens een Twitter Spaces dacht ik dat dit dashboard van algemene hulp zou kunnen zijn voor de bredere gemeenschap.
Ik ben hier om dit dashboard en de onderliggende gegevens met u te delen.
Het eerste dashboard toont een Algemeen overzicht van het zwembadlandschap met enkele filters die vooraf zijn geconfigureerd en sommige die u zelf kunt wijzigen. Merk op dat u het dashboard ook kunt filteren door op een pool of poolgroep te klikken:
Het tweede dashboard zoomt in op de multi-poolgroepen en toont alleen die MPO's die niet worden beïnvloed wanneer K naar 1000 gaat. De grondgedachte hier is dat zelfs als sommige pools van een groep verzadigd raken, de groep als geheel alleen wordt "getroffen" als die verzadigde inzet niet kan worden verplaatst naar een van hun andere pools.
De andere 3 dashboards tonen bijgevolg de Niet-beïnvloede Single pools, Betrokken MPO's en Betrokken Single Pools
Ik heb de gegevens gebruikt om mijn eigen mening te vormen. Ik heb mijn eigen argumenten waarom ik denk dat het verhogen van K misschien niet de beste manier is om vooruit te komen, maar dat is niet de reden waarom ik deze rapporten publiceer. Ik hoop dat anderen het nuttig vinden en de informatie gebruiken om zich te houden aan de Cardano-manier, wat imho is:
“Twee keer meten, één keer knippen”
Het belangrijke woord voor mij hier is "Meten" en ik hoop dat ik een beetje heb bijgedragen aan dit ethos.
Basisdisclaimers
Hoewel deze dashboards gegevens tonen, heb ik mijn eigen filters en aannames daarin.
Er staan waarschijnlijk fouten in deze rapporten. Het is niet bedoeld als een kunstwerk, maar begon als een snelle manier om mijn eigen stemkeuze te helpen. Laat het me weten en ik zal kijken of ik ze kan verbeteren
De gegevens zijn niet dynamisch. Ik moet ze handmatig bijwerken.
Ik heb 2 filters gebruikt om pools uit te sluiten waarvan ik denk dat ze moeten worden uitgesloten in deze analyse. Het kan zijn dat u het hier niet mee eens bent. Een van de filters is het filter “Normaal zwembad”. Het sluit pools uit met een gemiddelde inzet van meer dan 100.000 per delegeerder. Het andere filter is het "marge"-filter, waarbij ik alle pools met een marge van meer dan 20% uitsluit.
De rapporten zijn gebaseerd op deze gegevensbron in Google Spreadsheets:Cardano Pools-statistieken en K=1000 - Google Spreadsheets
Als je meer vragen hebt over Cardano of Staking Cardano, word lid van onze Discord-server en vraag me alles!
Laat hieronder uw opmerkingen achter en laat me weten welke andere onderwerpen u wilt dat ik behandel zonder jargon en binnen 199 woorden.
