Onlangs was er een kleine ruzie tussen de Core- en Unlimited-facties van de Bitcoin-gemeenschap, een ruzie die misschien de vijftigste keer vertegenwoordigt dat hetzelfde thema werd besproken, maar die niettemin interessant is vanwege de manier waarop het een heel subtiel filosofisch punt benadrukt over hoe blockchains werk.
ViaBTC, een mijnbouwpool die de voorkeur geeft aan Unlimited, tweeted “hashpower is law”, een gebruikelijk gespreksonderwerp voor de Unlimited-kant, die gelooft dat mijnwerkers een zeer grote rol spelen en zouden moeten hebben in het bestuur van Bitcoin. Het gebruikelijke argument hiervoor is dat mijnwerkers de enige categorie gebruikers zijn die heeft een grote en illiquide financiële prikkel in het succes van Bitcoin. Greg Maxwell (van de Core-kant) antwoordde dat “de beveiliging van Bitcoin juist werkt omdat hash-macht GEEN wet is”.
Het kernargument is dat miners slechts een beperkte rol spelen in het Bitcoin-systeem, om de volgorde van transacties veilig te stellen, en dat ze NIET de macht zouden moeten hebben om iets anders te bepalen, inclusief blokgroottelimieten en andere blokgeldigheidsregels. Deze beperkingen worden afgedwongen door volledige knooppunten die door gebruikers worden beheerd. Als miners blokken gaan produceren volgens een reeks regels die anders zijn dan de regels die de knooppunten van gebruikers afdwingen, zullen de knooppunten van de gebruikers de blokken eenvoudigweg afwijzen, ongeacht of ze 10% of 60% zijn. % of 99% van de hashpower ligt achter hen. Hierop antwoordt Unlimited vaak met iets als: “Als 90% van de hashpower achter een nieuwe keten zit die de bloklimiet verhoogt, en de oude keten met 10% hashpower nu tien keer langzamer is gedurende vijf maanden totdat de moeilijkheidsgraad zich weer aanpast, zou je dan werkelijk uw klant niet updaten om de nieuwe keten te accepteren?
Veel mensen vaak argumenteren tegen het gebruik van openbare blockchains voor toepassingen waarbij echte activa betrokken zijn of iets met tegenpartijrisico. De kritiek is ofwel totaal, waarbij wordt gezegd dat het geen zin heeft om dergelijke gebruiksscenario’s op openbare blockchains te implementeren, ofwel gedeeltelijk, waarbij wordt gezegd dat er weliswaar voordelen kunnen zijn aan het opslaan van de gegevens op een publieke keten, de bedrijfslogica buiten de keten moeten worden uitgevoerd.
Het argument dat gewoonlijk wordt gebruikt, is dat er bij dergelijke toepassingen al vertrouwenspunten bestaan: er is iemand die eigenaar is van de fysieke activa die de toegestane activa in de keten ondersteunen, en dat iemand er altijd voor kan kiezen om met de activa weg te lopen of gedwongen te worden om te bevriezen. ze door een overheid of bank worden beheerd, en dus is het beheren van de digitale representaties van deze activa op een blockchain hetzelfde als betalen voor een versterkte stalen deur voor je huis als het raam open staat. In plaats daarvan zouden dergelijke systemen gebruik moeten maken van private ketens, of zelfs van traditionele servergebaseerde oplossingen, waarbij misschien stukjes en beetjes cryptografie moeten worden toegevoegd om de controleerbaarheid te verbeteren, en daardoor te besparen op de inefficiëntie en kosten die gepaard gaan met het plaatsen van alles op een blockchain.
De bovenstaande argumenten zijn allebei gebrekkig in hun pure vorm, maar ook op soortgelijke wijze. Terwijl het zo is theoretisch mogelijk voor mijnwerkers om 99% van hun hashpower over te zetten naar een keten met nieuwe regels (om een voorbeeld te geven waar dit onomstreden slecht is: stel dat ze de blokbeloning verhogen), en zelfs spawn-kamp de oude keten om het permanent onbruikbaar te maken, en het is theoretisch ook mogelijk dat een gecentraliseerde beheerder van een door activa gedekte valuta stopt met het respecteren van één digitaal token, en een nieuw digitaal token maakt met hetzelfde saldo als het oude token, behalve met de rekeningen van één bepaalde rekening. het saldo teruggebracht tot nul, en begin in de praktijk het nieuwe token te eren die dingen zijn allebei behoorlijk moeilijk om te doen.
In het eerste geval zullen gebruikers zich moeten realiseren dat er iets mis is met de bestaande keten, het erover eens moeten zijn dat ze naar de nieuwe keten moeten gaan waar de miners nu op minen, en de software moeten downloaden die de nieuwe regels accepteert. In het tweede geval zullen alle clients en applicaties die afhankelijk zijn van het originele digitale token kapot gaan, zullen gebruikers hun clients moeten updaten om over te stappen naar het nieuwe digitale token, en zullen slimme contracten zonder capaciteit om naar de buitenwereld te kijken en te zien dat zij moet worden bijgewerkt, zal volledig kapot gaan. Te midden van dit alles kunnen tegenstanders van de overstap een angst-onzekerheid-en-twijfel-campagne opzetten om mensen ervan te overtuigen dat ze hun klanten misschien toch niet moeten updaten, of hun klanten moeten updaten naar een aantal derde reeks regels (bijvoorbeeld het wijzigen van het bewijs van werk), en dit maakt het implementeren van de overstap nog moeilijker.
Daarom kunnen we zeggen dat in beide gevallen, ook al zijn er theoretisch gecentraliseerde of quasi-gecentraliseerde partijen die een overgang van staat A naar staat B zouden kunnen afdwingen, waarbij staat B onaangenaam is voor de gebruikers maar te verkiezen is boven de gecentraliseerde partijen, dit vereist dat er het doorbreken van een moeilijk coördinatieprobleem. Coördinatieproblemen komen overal in de samenleving voor en zijn vaak een slechte zaak – terwijl het voor de meeste mensen beter zou zijn als de Engelse taal zijn zeer complexe en onregelmatige spellingssysteem zou afschaffen en een fonetisch systeem zou maken, of als de Verenigde Staten zouden overstappen op metrisch, of als we dat onmiddellijk konden doen alle prijzen en lonen met tien procent verlagen in geval van een recessieIn de praktijk betekent dit dat iedereen het tegelijkertijd eens moet zijn over de overstap, en dat is vaak heel erg moeilijk.
Met blockchain-toepassingen doen we echter iets anders: we gebruiken coördinatieproblemen in ons voordeel, waarbij de wrijving die coördinatieproblemen veroorzaken, wordt gebruikt als bolwerk tegen misdaden door gecentraliseerde actoren. We kunnen systemen bouwen die eigenschap X hebben, en we kunnen garanderen dat ze eigenschap X in hoge mate zullen behouden, omdat het veranderen van de regels van X naar niet-X zou vereisen dat een hele groep mensen ermee instemt om tegelijkertijd hun software bij te werken. . Zelfs als er een actor is die de verandering zou kunnen forceren, zou dat moeilijk zijn. Dit is het soort beveiliging dat u krijgt door validatie aan de clientzijde van blockchain-consensusregels.
Houd er rekening mee dat dit soort beveiliging specifiek afhankelijk is van de decentralisatie van gebruikers. Zelfs als er maar één mijnwerker in de wereld is, is er nog steeds een verschil tussen een cryptocurrency die door die mijnwerker wordt gedolven en een PayPal-achtig gecentraliseerd systeem. In het laatste geval kan de exploitant ervoor kiezen om willekeurig de regels te veranderen, het geld van mensen te bevriezen, slechte service te bieden, hun vergoedingen op te krikken of een hele reeks andere dingen te doen, en de coördinatieproblemen zijn in het voordeel van de exploitant, aangezien dergelijke systemen aanzienlijke netwerkeffecten en dus zouden heel veel gebruikers tegelijkertijd moeten instemmen met de overstap naar een beter systeem. In het eerste geval betekent validatie aan de clientzijde dat veel pogingen tot kattenkwaad waar de mijnwerker zich mee zou willen bezighouden standaard worden afgewezen, en het coördinatieprobleem werkt nu in het voordeel van de gebruikers.
Merk op dat de bovenstaande argumenten NIET zelfimpliceren dat het een slecht idee is dat mijnwerkers de belangrijkste actoren zijn die de blokgrootte (of in het geval van Ethereum, de gaslimiet) coördineren en beslissen. Het kan heel goed zo zijn dat, in het specifieke geval van de blokgrootte/gaslimietis “een regering door gecoördineerde mijnwerkers met op elkaar afgestemde prikkels” de optimale benadering om deze ene specifieke beleidsparameter te bepalen, misschien omdat het risico dat mijnwerkers hun macht misbruiken kleiner is dan het risico dat een specifiek gekozen harde limiet enorm ongepast zal blijken te zijn voor de marktomstandigheden. tien jaar nadat de limiet is vastgesteld. Er is echter niets onredelijks om te zeggen dat de regering door mijnwerkers de beste manier is om over één beleidsparameter te beslissen, en tegelijkertijd te zeggen dat voor andere parameters (bijv. blokbeloning) willen we vertrouwen op validatie aan de clientzijde om ervoor te zorgen dat mijnwerkers beperkt zijn. Dit is de essentie van het ontwerpen van gedecentraliseerde instituties: het gaat over het strategisch benutten van coördinatieproblemen om ervoor te zorgen dat systemen aan bepaalde gewenste eigenschappen blijven voldoen.
De bovenstaande argumenten impliceren ook niet dat het altijd optimaal is om te proberen alles op een blockchain te zetten, zelfs voor diensten die vertrouwen vereisen. Over het algemeen valt er op zijn minst enige winst te behalen door meer bedrijfslogica op een blockchain te laten draaien, maar deze zijn vaak veel kleiner dan de verliezen op het gebied van efficiëntie of privacy. En dit is oké; de blockchain is niet het beste hulpmiddel voor elke taak. Wat bovenstaande argumenten do Wat echter impliceert is dat als je een op blockchain gebaseerde applicatie bouwt die uit noodzaak veel gecentraliseerde componenten bevat, je substantiële verdere winst kunt boeken op het gebied van vertrouwensminimalisatie door gebruikers een manier te geven om toegang te krijgen tot je applicatie via een reguliere blockchain-client ( in het geval van Ethereum kan dit bijvoorbeeld Mist, Parity, Metamask of Status zijn), in plaats van ze een webinterface te laten gebruiken die u persoonlijk beheert.
Theoretisch worden de voordelen van validatie aan de gebruikerszijde geoptimaliseerd als letterlijk elke gebruiker een onafhankelijk ‘ideaal volledig knooppunt’ heeft – een knooppunt dat alle blokken accepteert die de protocolregels volgen waarmee iedereen heeft ingestemd bij het maken van het systeem, en alle blokken afwijst die dat wel doen. niet. In de praktijk betekent dit echter dat elke gebruiker wordt gevraagd elke transactie van iedereen in het netwerk te verwerken, wat duidelijk onhoudbaar is, vooral als je de snelle groei van het aantal smartphonegebruikers in de ontwikkelingslanden in gedachten houdt.
Er zijn hier twee uitwegen. De eerste is dat we ons dat kunnen realiseren zolang het zo is optimale vanuit het oogpunt van bovenstaande argumenten dat iedereen een full node draait, is dat zeker niet het geval nodig. Het is waarschijnlijk dat elke grote blockchain die op volle capaciteit draait al het punt heeft bereikt waarop het voor “het gewone volk” geen zin meer heeft om een vijfde van hun harde schijfruimte te besteden aan het draaien van een volledig knooppunt, en dus zijn de overgebleven gebruikers hobbyisten en ondernemingen. Zolang er een vrij groot aantal van hen is en ze verschillende achtergronden hebben, zal het coördinatieprobleem om deze gebruikers te laten samenwerken nog steeds erg moeilijk zijn.
Ten tweede kunnen we erop vertrouwen sterke light client-technologie.
Er zijn twee niveaus van ‘light clients’ die over het algemeen mogelijk zijn in blockchain-systemen. De eerste, zwakkere, lichte client overtuigt de gebruiker eenvoudigweg, met enige mate van economische zekerheid, dat hij of zij deel uitmaakt van de keten die wordt ondersteund door de meerderheid van het netwerk. Dit kan veel goedkoper worden gedaan dan het verifiëren van de hele keten, omdat het enige wat klanten hoeven te doen is in proof-of-work-schema's nonces verifiëren of in proof-stake-schema's ondertekende certificaten verifiëren die vermelden: 'ofwel de root-hash van de staat is wat ik zeg. is, of u kunt dit certificaat in de hoofdketen publiceren om een groot deel van mijn geld te verwijderen”. Zodra de light-client een root-hash heeft geverifieerd, kunnen ze Merkle-bomen gebruiken om elk specifiek stukje gegevens te verifiëren dat ze mogelijk willen verifiëren.
Kijk, het is een Merkle-boom!
Het tweede niveau is een ‘bijna volledig verifiërende’ light-client. Dit soort klanten probeert niet alleen de keten te volgen die de meerderheid volgt; in plaats daarvan probeert het ook alleen ketens te volgen die alle regels volgen. Dit wordt gedaan door een combinatie van strategieën; het eenvoudigst uit te leggen is dat een lichte klant kan samenwerken met gespecialiseerde knooppunten (met dank aan Gavin Wood voor het bedenken van de naam ‘vissers’), wiens doel het is om te zoeken naar blokken die ongeldig zijn en ‘fraudebewijzen’ te genereren, korte berichten die zeg in wezen: “Kijk! Dit blok heeft hier een fout!”. Light clients kunnen vervolgens dat specifieke deel van een blok verifiëren en controleren of het daadwerkelijk ongeldig is.
Als een blok ongeldig blijkt te zijn, wordt het weggegooid; als een light client gedurende een paar minuten geen fraudebewijzen voor een bepaald blok hoort, gaat hij ervan uit dat de blokkering waarschijnlijk legitiem is. Er is een beetje meer complexiteit betrokken bij de behandeling van de zaak waarbij het probleem niet de gegevens zijn slecht, maar eerder gegevens vermist, maar over het algemeen is het mogelijk om vrij dicht bij alle mogelijke manieren te komen waarop miners of validators de regels van het protocol kunnen schenden.
Merk op dat als een light client een set applicatieregels efficiënt kan valideren, deze regels binnen consensus moeten worden uitgevoerd - dat wil zeggen dat ze deel moeten uitmaken van het protocol of deel moeten uitmaken van een mechanisme dat binnen het protocol wordt uitgevoerd ( zoals een slim contract). Dit is een belangrijk argument vóór het gebruik van de blockchain voor zowel gegevensopslag als uitvoering van bedrijfslogica, in tegenstelling tot alleen gegevensopslag.
Deze light client-technieken zijn onvolmaakt, in die zin dat ze gebaseerd zijn op aannames over netwerkconnectiviteit en het aantal andere light clients en vissers dat zich in het netwerk bevindt. Maar het is eigenlijk niet cruciaal dat ze 100% van de tijd voor 100% van de validators werken. Het enige dat we willen is het creëren van een situatie waarin elke poging van een vijandig kartel van mijnwerkers/validators om ongeldige blokken te pushen zonder toestemming van de gebruiker, voor veel mensen veel kopzorgen zal veroorzaken en uiteindelijk van iedereen zal vereisen dat ze hun software updaten als ze dat willen. wilt doorgaan met synchroniseren met de ongeldige keten. Zolang hieraan wordt voldaan, hebben we het doel van veiligheid bereikt door middel van coördinatiefricties.
Bron: https://vitalik.eth.limo/general/2017/05/08/coordination_problems.html
- Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
- PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
- PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
- PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
- Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
- BlockOffsets. Eigendom voor milieucompensatie moderniseren. Toegang hier.
- Bron: Plato data-intelligentie.
