Waarom progressieve decentralisatie de beste hoop van blockchain is

Immutability is de grootste kracht en grootste barrière van blockchain. Progressieve decentralisatie zou het antwoord kunnen zijn.

Toen we een jaar geleden CryptoKitties uitbrachten, hebben we ervoor gekozen om het niet vooraf te financieren met een ICO, maar in plaats daarvan te bouwen op een duurzaam verdienmodel. Dat model is dit: we ontvangen een vergoeding van 3,75% voor elke transactie in de game. Gezien het feit dat we na de lancering de kosten niet kunnen wijzigen - CryptoKitties is gebouwd op de blockchain van Ethereum - vragen mensen vaak hoe we aan dat aantal zijn gekomen.

Het klinkt als een slimme, goed beredeneerde keuze. Ik zou een boeiend verhaal kunnen vertellen over hoe we simulaties met geavanceerde voorspellingsmodellen hebben uitgevoerd om de vergoeding te vinden die een optimaal rendement zou opleveren.

Maar dat is niet waar.

De waarheid is dat we een weloverwogen gok hebben gedaan. We hebben een nummer gekozen dat eerlijk aanvoelde en hebben ons eraan gecommitteerd.

Onveranderlijkheid is geweldig en eng

We hadden gemakkelijk verkeerd kunnen kiezen, en omdat je iets niet kunt veranderen als je het eenmaal aan de blockchain toevoegt, zou dat cat-astrofisch zijn geweest. Gelukkig voor CryptoKitties is onze community zo gepassioneerd en de Kitties zijn zo schattig dat 3,75% prima werkte.

Immutability, het onvermogen om te worden bewerkt, is meteen de grootste kracht van de blockchain en de grootste barrière voor betekenisvolle acceptatie. De druk van onsterfelijke code verlamt ontwikkelaars: je kunt voor altijd sleutelen in een testomgeving, maar er zullen altijd real-world variabelen zijn waarop je niet kunt anticiperen. Je ogen bedekken en lanceren raken is geen manier om doorbraken te maken. De kans op storingen is groter.

Onze vergoeding was slechts een van de vele beslissingen: hoe lang moet het fokken van een Kitty duren? In welk tempo moeten hun fokafkoeling vertragen? Hoeveel moet een Gen 0-kat kosten? Op blockchain kan zelfs een ogenschijnlijk kleine keuze ernstige, zelfs kritische, gevolgen hebben.

Decentralisatie biedt gewone mensen enorme voordelen: de eerlijkheid van permanente en universele regels en de transparantie van code en gedrag die, gecombineerd, veiligheid creëren. Omdat het echter vaak wordt geïmplementeerd met alles-of-niets onveranderlijkheid, maakt blockchain agile ontwikkeling onmogelijk en vertraagt ​​teams tot een crawl.

Behendigheid vereist iteratie. Snel itereren is de sleutel tot het bouwen van de beste producten en de beste producten leiden tot massale acceptatie.

Voer progressieve decentralisatie in

We zijn deze barrières zelf tegengekomen bij het bouwen van CryptoKitties, waardoor we moesten onderhandelen, inclusief gedecentraliseerde functies, terwijl we iets bouwden dat, weet je, werkt. Sindsdien zijn we begonnen met het verkennen van progressieve decentralisatie in ontwikkeling, een idee dat we kort geleden hebben geïntroduceerd.

Laten we nu dieper duiken.

Simpel gezegd, progressieve decentralisatie pleit voor een versoepeling van de decentralisatie in fasen in plaats van in eerste instantie te duiken. Hoe dat eruit ziet is het inbouwen van mechanismen in slimme contracten die speciale krachten aan de makers vooraf verlenen, en vervolgens die krachten geleidelijk op een transparante en systematische manier opsluiten.

De kritieke voorwaarde is dat de vergrendelingsmechanismen vanaf het begin openbaar en onveranderlijk moeten zijn. De maker kan niet beslissen om de voorwaarden later aan te passen en hun macht onbeperkt uit te breiden. Dat evenwicht is van vitaal belang: correct gedaan, biedt progressieve decentralisatie makers de flexibiliteit om hun code te repareren zonder afbreuk te doen aan de gedecentraliseerde kenmerken van het contract.

Progressieve decentralisatie kan vele vormen aannemen

Er is geen goede manier om progressieve decentralisatie te implementeren. Er zijn tientallen variabelen om te overwegen en de beste aanpak zal van project tot project variëren.

Hier zijn een paar manieren waarop ontwikkelaars progressieve decentralisatie kunnen benaderen:

  1. Stel meerdere contracten op met de juiste scheiding van punten van zorg en de mogelijkheid om sommige van die contracten te vervangen. Sommige gedecentraliseerde apps ("dapps") zoals Decentraland, met upgradable contracten, maken hier al gebruik van.
  2. Configureerbare variabelen en machtigingen om die waarden onafhankelijk te wijzigen. Etheremon verleent bijvoorbeeld speciale machtigingen aan groepen gebruikers die moderator worden.
  3. Neem een ​​vooraf gedefinieerde set van oplopende niveaus op in het contract, die elk de makers bepaalde mogelijkheden bieden. De niveaus kunnen alleen worden verhoogd, nooit verlaagd, dus backtracking is geen optie. Op niveau 1 kunnen de contracteigenaren bijvoorbeeld spelen met alle gameplay-variabelen. Op niveau 2 eindigt hun vermogen om kernvariabelen te wijzigen. Op het laatste niveau trekt het contract al hun speciale privileges in.

Voor die-hard decentralisten klinkt dit waarschijnlijk te gecentraliseerd. Maar dit is slechts het beginpunt. Er zijn verdere maatregelen om decentralisatie in evenwicht te brengen met iteratie. De oplossing combineert transparantie van het doel en de voorwaarden en beperkingen in de contracten. Deze beperkingen kunnen zijn:

  1. Selectie: niet alles kan worden gewijzigd, alleen de specifieke items die we moeten herhalen.
  2. Bereik: voor veel van de vragen rond game-economieën hebben we misschien een algemeen idee, maar weten we niet het precieze antwoord. Het beperken van de configuratie tot een bepaald bereik garandeert gebruikers dat de iteratie binnen een redelijk bereik zal landen.
  3. Richting: Vergelijkbaar met het bovenstaande “niveaus” -concept, laat bepaalde variabelen slechts in één richting bewegen, afnemend of groter maar nooit teruglopend.

Makers verantwoordelijk houden

Dit klinkt allemaal geweldig in theorie. Maar hoe zorgen we ervoor dat makers trouw blijven aan hun stappenplan en de volledig gedecentraliseerde versie van hun contracten bereiken? Hoe kunnen gebruikers zich vroeg aanmelden met de garantie dat het systeem een ​​toepassing van progressieve decentralisatie is? Hoe kunnen we weten dat we niet zullen eindigen met weer een gebrekkig, gecentraliseerd systeem?

Progressieve decentralisatie omvat principes om makers verantwoordelijk te houden:

Op tijd of op blokken gebaseerde looptijd

Vergrendel bepaalde configuratiewaarden, trek de mogelijkheden van de eigenaar in of ga naar een volgend volwassenheidsniveau voorbij een bepaald tijdstip of bloknummer. Zodra dat punt is bereikt, verandert het contract automatisch.

Stel je bijvoorbeeld voor dat CryptoKitties vanaf het moment dat het werd gelanceerd een startbaan van 360.000 blokken had (ongeveer 60 dagen) om de fokafkoelingsvariabelen van de Kitties aan te passen. We kunnen de cooldownmechanismen tot dat moment aanpassen, waardoor we de ademruimte krijgen om de balans te perfectioneren, terwijl we spelers toch garanderen dat we die kracht niet voor onbepaalde tijd zouden hebben.

Op gebruik gebaseerde looptijd

Vergrendel deze mogelijkheden zodra een bepaald aantal gebruikers of transacties is voltooid. Deze optie moet zorgvuldig worden doordacht om exploits te voorkomen, maar we zouden bijvoorbeeld configureerbare vergoedingen in CryptoKitties kunnen hebben ingebouwd die na 10.000 transacties zouden vastlopen.

Economische stimulans

Breng de prikkels van de maker in lijn met verhoogde decentralisatie. In dit scenario profiteren de makers meer als het contract meer gedecentraliseerd wordt. Misschien stijgt de vergoeding met elk niveau dat de ontwikkelaar stijgt, en vergrendelt hij zich op de maximale vergoeding wanneer hij volledige decentralisatie bereikt. Of misschien verdienen ze helemaal geen geld totdat volledige decentralisatie is doorgevoerd. Deze financiële beloning motiveert de ontwikkelaar om in een redelijk tempo te decentraliseren.

Er is geen beste aanpak om op de blockchain voort te bouwen

"Progressieve decentralisatie" is echt een paraplu die vele strategieën, mechanismen en hulpmiddelen omvat om het bouwen op de blockchain levensvatbaarder te maken. De beste manier om progressieve decentralisatie toe te passen, hangt altijd af van het project en gebruikt een combinatie van de hierboven geschetste concepten.

Progressieve decentralisatie is niet perfect. Het ideale slimme contract is eenvoudig en duidelijk, en deze maatregelen voegen complexiteit toe. Hoe en hoeveel het moet opnemen, is een afweging die per geval moet worden geëvalueerd.

Hoewel het hardline-decentralisten boos kan maken, geloven we dat progressieve decentralisatie op de lange termijn veel beter is voor gebruikers: door ontwikkelaars de flexibiliteit te geven zich aan te passen, krijgt de consument een nuttiger product. Dat betekent dat ze het daadwerkelijk zullen gebruiken, en als het eenmaal waarde aan hun leven toevoegt, zullen ze zijn lof zingen voor de mensen om hen heen. Dat is hoe massa-acceptatie begint.

Auteurs: Arthur Camara, Dieter Shirley en Grady Mitchell