Waarom private blockchains niet enthousiast zouden moeten zijn om code uit te voeren

Ik ben geen fan van de term 'slimme contracten'. Om te beginnen is het door zoveel mensen gebruikt voor zoveel verschillende dingen, dat we het waarschijnlijk gewoon helemaal moeten verbieden. Zo is de eerste bekende referentie uit 1997, toen Nick Szabo het gebruikte om fysieke objecten te beschrijven die hun gedrag veranderen gebaseerd op enkele gegevens. Meer recentelijk is de term gebruikt voor precies het tegenovergestelde: om berekening op een blockchain te beschrijven die wordt beïnvloed door externe gebeurtenissen zoals het weer. Laten we voorlopig beide betekenissen opzij zetten.

Ik wil me hier concentreren op 'slimme contracten' in de zin van berekening voor algemene doeleinden die plaatsvindt op een blockchain. Deze betekenis werd gepopulariseerd door Ethereum, wiens wit papier heeft als ondertitel "Een slim contract van de volgende generatie en een gedecentraliseerd applicatieplatform". Als gevolg van de aandacht die Ethereum heeft gekregen, is deze betekenis de dominante geworden, waarbij banken (en anderen) werken aan slimme contract-proofs-of-concept. Aangezien we het over gereguleerde financiële instellingen hebben, is dit natuurlijk meestal in de context van particuliere of geautoriseerde blockchains, die een beperkt aantal geïdentificeerde deelnemers hebben. Om redenen die nu zijn goed begrepen, openbare blockchains, voor al hun genialiteit, zijn nog niet geschikt voor zakelijke doeleinden.

Dus is de toekomst rooskleurig voor slimme contracten in private blockchains? Nou ja, maar niet echt. Zie je, het probleem is:

In private blockchains combineren slimme contracten vier goede ideeën met één slechte.

Dus wat zijn de goede ideeën? (a) bedrijfslogica uitdrukken als een computerprogramma, (b) de gebeurtenissen die die logica activeren als berichten naar het programma weergeven, (c) digitale handtekeningen gebruiken om te bewijzen wie de berichten heeft verzonden, en (d) al het bovenstaande op te zetten een blockchain.

En de slechte? Elk programma voor elk bericht op elk blockchain-knooppunt uitvoeren. Met andere woorden, het maken van de uitvoering van alle programma's de taak van de blockchain, in plaats van het alleen te gebruiken als mediaopslag voor de programma's en berichten. En toch is deze wereldwijde uitvoering de volledige reden waarom Ethereum is ontwikkeld.

Als je je bewust bent van de deterministische aard van berekening, weet over de stopprobleem, en begrijp hoe gegevensafhankelijkheden gelijktijdigheid voorkomen dan ben je misschien al overtuigd. Maar zo niet, maak dan een kop koffie, haal diep adem en volg me door het konijnenhol ...

Ethereum begrijpen

Om slimme contracten in Ethereum-stijl te begrijpen, moeten we beginnen met bitcoin, de eerste (en nog steeds meest populaire) openbare blockchain. De bitcoin-blockchain is oorspronkelijk maar voor één ding ontworpen: de bitcoin-valuta van de ene eigenaar naar de andere verplaatsen. Maar toen het eenmaal operationeel was, begonnen mensen ‘metadata’ in transacties in te bedden voor andere doeleinden, zoals digitale activa en documentnotarisatie. Terwijl sommige bitcoiners vochten deze toepassingen, een officieel mechanisme voor metadata werd in maart 2014 geïntroduceerd, met gebruik exponentieel groeit sindsdien.

Naast projecten die zijn gebouwd op de bitcoin-blockchain, zijn er veel openbare blockchains van de volgende generatie ontwikkeld en gelanceerd, zoals Nxt, Bitshares, Ripple en Stellar. Deze zijn vanaf de basis ontworpen om een ​​breder scala aan activiteiten te ondersteunen, zoals door de gebruiker gecreëerde activa, gedecentraliseerde uitwisseling en door zekerheden gedekte leningen. Elk van deze blockchains heeft een andere set functies, zoals besloten door de ontwikkelaars, en elk moet worden geüpgraded door al zijn gebruikers wanneer een nieuwe functie wordt toegevoegd. Het begon nogal rommelig te worden.

Na betrokken te zijn geweest bij sommige van deze projecten, Vitalik Buterin stelde een simpele maar briljante vraag: in plaats van veel applicatiespecifieke blockchains, waarom niet één openbare blockchain hebben die kan worden geprogrammeerd wat we maar willen? Deze über-blockchain zou oneindig uitbreidbaar zijn, alleen beperkt door de verbeeldingskracht van degenen die hem gebruiken. De wereld van crypto-enthousiasten was bijna unaniem overtuigd door dit krachtige idee. En dus met $ 18 miljoen aan crowdfunding en tot grote opwinding werd Ethereum geboren.

Ethereum is een nieuwe openbare blockchain met een bijbehorende cryptocurrency genaamd "ether", zoals honderden die ervoor kwam. Maar in tegenstelling tot andere blockchains, stelt Ethereum iedereen in staat om een ​​"contract" binnen de blockchain te creëren. Een contract is een computerprogramma met een bijbehorende miniatuurdatabase, die kan alleen worden gewijzigd door het programma dat er eigenaar van is. Als een blockchain-gebruiker een database wil wijzigen, moet hij een digitaal ondertekend bericht naar zijn contract sturen. De code in het contract onderzoekt dit bericht om te beslissen of en hoe te reageren. (Deze "inkapseling”Van code en data is ook een basis van Objectgeoriënteerde programmeren.)

Ethereum-contracten kunnen worden geschreven in een van de vele nieuwe programmeertalen, zoals Stevigheid en Slang. Zoals de meeste programmeertalen zijn dit Turing compleet, wat betekent dat ze elke berekening voor algemene doeleinden kunnen uitdrukken. Een belangrijk kenmerk van Turing complete talen is de lus structuur, die een bewerking herhaaldelijk uitvoert totdat aan een bepaalde voorwaarde is voldaan. Een lus kan bijvoorbeeld worden gebruikt om de cijfers van één tot een miljoen af ​​te drukken, zonder dat er een miljoen regels code nodig is. Omwille van de efficiëntie zijn programma's die voor Ethereum zijn geschreven gecompileerd (dwz omgezet) in compacter bytecode voordat ze op de ketting worden opgeslagen. Ethereum-knooppunten voeren deze bytecode vervolgens uit binnen een virtuele machine, wat in wezen een gesimuleerde computer is die in een echte computer draait.

Wanneer een Ethereum-contract wordt gemaakt op de blockchain, stelt het de begintoestand van zijn database in. Dan stopt het, beleefd wachten tot er een beroep op wordt gedaan. Wanneer een gebruiker van de blockchain (of een ander contract) hem een ​​bericht stuurt in een transactie, komt het contract in actie. Afhankelijk van de code erin, kan het de bron van het bericht identificeren, andere contracten activeren, de database wijzigen en / of een antwoord terugsturen naar de beller. Al deze stappen worden onafhankelijk uitgevoerd op elk knooppunt in het netwerk, met identieke resultaten.

Om een ​​voorbeeld te geven, een eenvoudig Ethereum subvalutacontract onderhoudt een database met gebruikerssaldi voor een bepaald activum. Als het een bericht ontvangt om geld over te maken van Alice naar Bob, zal het (a) controleren of het bericht is ondertekend door Alice, (b) controleren of Alice voldoende geld heeft, (c) geld overmaken van Alice naar het account van Bob in de database en d) antwoorden dat de operatie is geslaagd. Daar hebben we natuurlijk geen Ethereum voor nodig, want een simpele bitcoin-achtige blockchain mee native asset-ondersteuning kan hetzelfde doen. Ethereum komt echt tot zijn recht voor complexe bedrijfslogica in meerdere fasen, zoals crowdfunding, gedecentraliseerde uitwisselingen en hiërarchische bestuursstructuren. Of zo, tenminste, de belofte gaat.

Het af te breken

Nu we weten hoe slimme contracten van Ethereum werken, kunnen we ze onderverdelen in vijf onderdelen:

1. Bedrijfslogica uitdrukken als computerprogramma's.
2. Vertegenwoordigt de gebeurtenissen die die logica activeren als berichten naar de programma's.
3. Gebruik digitale handtekeningen om te bewijzen wie de berichten heeft verzonden.
4. De programma's, berichten en handtekeningen op een blockchain zetten.
5. Elk programma voor elk bericht op elk knooppunt uitvoeren.

Om te herhalen wat ik in het begin zei, denk ik dat delen 1 tot en met 4 zeer goede ideeën zijn. Laten we beginnen met de eerste twee (die trouwens zijn niet nieuw). In tegenstelling tot juridische contracten die kunnen hebben verschillen in interpretatie, computerprogramma's zijn ondubbelzinnig. Voor een bepaald programma in een goed gedefinieerde programmeertaal leidt dezelfde invoer altijd tot dezelfde uitvoer. Dus als bepaalde bedrijfslogica wordt uitgedrukt als een computerprogramma, en gebeurtenissen worden weergegeven als berichten aan dat programma, dan is het bedrijfsresultaat in steen gebeiteld. In feite maakt deze deterministische eigenschap van berekening willekeurigheid een kleverig probleem in de informatica, en zelfs de geeks bij Google kunnen dat het fout hebben.

Hoe zit het met digitale handtekeningen en blockchains? Deze vermijden de noodzaak van een centrale autoriteit om te bepalen welke berichten zijn verzonden, in welke volgorde en door wie. In plaats daarvan maakt elke deelnemer een paar privé- en openbare sleutelsen distribueert de openbare sleutel eens aan de andere deelnemers. Daarna volgden ze teken elk bericht met hun privésleutel voordat dat bericht over het netwerk wordt verspreid. De andere deelnemers kunnen vervolgens de bron van het bericht verifiëren met alleen de openbare sleutel van de afzender. Het zijn slimme cryptografische dingen. Door het programma en de ondertekende berichten tenslotte op een blockchain te plaatsen, kunnen we ervoor zorgen dat elke deelnemer een identiek beeld heeft van wie wat en wanneer deed. Gecombineerd met deterministische berekening betekent dit deelnemers kunnen het niet oneens zijn over het uiteindelijke zakelijke resultaat.

Maar hoe zit het met het laatste idee, van elk knooppunt dat elk programma voor elk bericht uitvoert? Hier komen we bij het omstreden deel. Want hoewel deze globale uitvoering misschien leuk is om te hebben, is het ook niet nodig. Omdat berekeningen deterministisch zijn, maakt het niet uit of een programma wordt uitgevoerd door één knooppunt, elk knooppunt of een extern proces. Het maakt ook niet uit of dit in realtime, op aanvraag of 10 jaar later gebeurt. Het resultaat van de berekening zal altijd hetzelfde zijn. En als dit om een ​​of andere reden niet het geval is, kan dit alleen te wijten zijn aan een probleem in de blockchain-software of het netwerk.

Het probleem met berekening

Als het niet uitmaakt waar een berekening plaatsvindt, waarom niet doe het overal? Nou, dat blijkt computerprogramma's zijn onvoorspelbaar. Hoe onschuldig ze er ook uitzien, het kan lang duren voordat ze wegrennen. En soms blijven ze voor altijd rennen. Beschouw het volgende klassieke voorbeeld (bekend als een LCG):

1. Zet de x naar een enkelcijferig nummer naar keuze
2. Zet de y naar 123 * x + 567
3. Zet de x tot de laatste twee cijfers van y, Dwz en modulo 100
4. If x is meer dan 2 ga dan terug naar stap 2
5. Stop anders en voer de waarde van uit x

Simpel genoeg toch? Dus hier is een vraag voor u: zal dit programma ooit eindigen? Of komt het vast te zitten in een oneindige lus? Niet zo zeker? Laat me je uit je lijden verlossen: Het hangt af van de beginwaarde van x.

If x is 0, 1, 2, 5, 6, 7 or 8stopt het programma redelijk snel. Maar als x is 3, 4 or 9, het gaat voor onbepaalde tijd door. Geloof me niet? Open Excel en probeer het zelf (je hebt de "MOD" -functie nodig).

Als je dat niet kon voorspellen door alleen naar de code te kijken, voel je dan niet al te slecht. Omdat dit niet alleen moeilijk is voor mensen, het is onmogelijk voor computers. Het probleem om te bepalen of een bepaald programma zal worden uitgevoerd, wordt de genoemd stopprobleem. In 1936 Alan Turing, van "Turing compleet" en De Imitatie Game roem, bewees dat het niet kan worden opgelost voor de algemene zaak. Afgezien van triviale uitzonderingen, is dit de enige manier om erachter te komen of een programma stopt met draaien is om het te laten draaien zolang het duurt, en dat kan voor altijd zijn.

Voor degenen onder ons die liever zonder leven blauwe schermen van de dood en draaiende strandballen, het is allemaal nogal lastig. Maar we leven ermee en, opmerkelijk genoeg, de meeste software werkt meestal probleemloos. En zo niet, dan beschermen moderne besturingssystemen zoals Windows ons tegen op hol geslagen code door ons programma's handmatig te laten beëindigen. Hetzelfde kan echter niet worden gedaan op een blockchain zoals Ethereum. Als we individuele knooppunten zouden toestaan ​​om berekeningen naar believen te beëindigen, zouden verschillende knooppunten verschillende meningen hebben over de uitkomst van die berekeningen. Met andere woorden, de netwerkconsensus zou afbreken. Dus wat moet een blockchain doen?

Het antwoord van Ethereum is gebaseerd op transactiekosten, ook wel bekend als gas. De afzender van elke transactie pays voor de berekeningen die het activeert, en deze betaling wordt verzameld door de mijnwerker die het in een blok bevestigt. Om preciezer te zijn, elke Ethereum-transactie geeft vooraf aan hoeveel van de "ether" van de afzender kan worden besteed aan de verwerking ervan. De vergoeding wordt geleidelijk besteed terwijl het contract stapsgewijs wordt uitgevoerd binnen de Ethereum Virtual Machine. Als een transactie geen kosten meer heeft voordat de uitvoering is voltooid, worden eventuele wijzigingen in de database ongedaan gemaakt en wordt de vergoeding niet geretourneerd. Als een transactie met succes wordt voltooid, wordt het resterende bedrag teruggestort naar de afzender. Op deze manier kunnen transacties het netwerk alleen belasten voor zover ze bereid zijn ervoor te betalen. Het is ongetwijfeld een nette economische oplossing, maar het vereist een native blockchain-valuta om te kunnen werken.

Slimme contracten versus gelijktijdigheid

Als gas op hol geslagen berekeningen kan voorkomen, krijgen slimme contracten dan groen licht? Nou, niet zo snel, want er is nog een probleem met slimme contracten waar we het over moeten hebben:

Slimme contracten werken slecht voor een hoge transactiedoorvoer.

samenloop is een van de meest fundamentele problemen in computerarchitectuur. Een systeem heeft een goede gelijktijdigheid als het meerdere processen tegelijkertijd en in willekeurige volgorde mogelijk maakt. Gelijktijdige systemen verminderen vertragingen en maken over het algemeen een veel hogere doorvoer mogelijk door optimaal gebruik te maken van technologieën zoals procesplanning, parallelle verwerking en gegevensverdeling. Dat is hoe Google zoekt 30 biljoen webpagina's bijna 100,000 keer per seconde.

In elk computersysteem kan een reeks transacties alleen tegelijkertijd worden verwerkt als ze niet afhankelijk zijn van elkaar of elkaar storen. Anders kunnen verschillende verwerkingsopdrachten tot totaal verschillende uitkomsten leiden. Bedenk nu dat een slim contract een bijbehorende database heeft en dat het algemene berekeningen uitvoert, inclusief lussen. Dit betekent dat een smart contract in reactie op een bepaald bericht elk stukje informatie in zijn database kan lezen of schrijven. Als het bijvoorbeeld een subvaluta beheert, kan het besluiten om wat rente te betalen aan elke houder van die valuta. Dit zal natuurlijk niet altijd het geval zijn. Maar het probleem is: voordat het contractprogramma voor een bepaald bericht wordt uitgevoerd, een blockchain-knooppunt kan niet voorspellen welke subset van de contractdatabase het gaat gebruiken. Evenmin kan het zeggen of deze subset onder verschillende omstandigheden anders zou zijn geweest. En als het ene contract een ander contract kan activeren, strekt dit probleem zich uit tot het volledige inhoud van elke database van elk contract. Elke transactie moet dus worden behandeld alsof ze elkaar zou kunnen verstoren. In databasetermen vereist elke transactie een globale vergrendeling.

Denk nu eens aan de wereld waarin een blockchain-knooppunt leeft. Transacties komen binnen van verschillende peers, in willekeurige volgorde, aangezien er geen centraal beheerde wachtrij is. Bovendien komt er met gemiddelde intervallen tussen 12 seconden (Ethereum) en 10 minuten (bitcoin) een nieuw blok binnen, dat een reeks transacties in een specifieke volgorde bevestigt. Een node heeft waarschijnlijk de meeste transacties van een blok al gezien, maar sommige zijn mogelijk nieuw. Hoe dan ook, het is onwaarschijnlijk dat de volgorde van de transacties in het blok de volgorde weerspiegelt waarin ze afzonderlijk zijn aangekomen. En aangezien de volgorde van transacties de uitkomst kan beïnvloeden, betekent dit transacties kunnen pas worden verwerkt nadat hun bestelling in de blockchain is bevestigd.

Nu is het waar dat een niet-bevestigde bitcoin-transactie mogelijk moet worden teruggedraaid vanwege een dubbele uitgave. Maar een onbevestigde Ethereum-transactie heeft helemaal geen voorspelbare uitkomst. Inderdaad, huidige implementaties van Ethereum verwerken zelfs niet-geconfirmeerde transacties. Maar als een Ethereum-knooppunt was om transacties onmiddellijk te verwerken, moet het nog steeds terugspoelen en ze in de juiste volgorde afspelen wanneer een blok binnenkomt. Deze herverwerking is een enorme verspilling van moeite en voorkomt dat externe processen gelijktijdig de Ethereum-database lezen terwijl deze doorgaat. (Om eerlijk te zijn moet worden opgemerkt dat bitcoin's referentie-implementatie spoelt ook transacties terug en speelt ze opnieuw af wanneer er een blok binnenkomt, maar dit komt alleen door een gebrek aan optimalisatie.)

Dus wat is het met het transactiemodel van bitcoin dat uitvoering buiten de bestelling mogelijk maakt? In bitcoin, elke transactie verklaart expliciet de relatie met andere transacties. Het heeft een reeks inputs en outputs, waarbij elke input is verbonden met de output van een eerdere transactie die hij “uitgeeft”. Er zijn geen andere afhankelijkheden om u zorgen over te maken. Zolang (a) twee bitcoin-transacties niet proberen dezelfde output te besteden, en (b) de output van de ene niet naar de input van een andere leidt, kan een bitcoin-node er zeker van zijn dat de transacties onafhankelijk zijn, en het kan ze in willekeurige volgorde verwerken. Hun definitieve posities in de blockchain doen er helemaal niet toe.

Om formele informatica-terminologie te gebruiken, moeten Ethereum-transacties zijn strikt totaal besteld, wat betekent dat de relatieve volgorde tussen elk paar transacties moet worden gedefinieerd. Daarentegen vormen bitcoin-transacties een Gerichte acyclische grafiek dat is alleen gedeeltelijk besteld, wat betekent dat enige dubbelzinnigheid bij het bestellen van transacties is toegestaan. Als het om gelijktijdigheid gaat, maakt dit het verschil in de wereld.

Om het in de praktijk te bekijken, wordt er in de onderneming veel gepraat over private blockchains. Maar een private blockchain is slechts een gedistribueerde database met enkele extra functies. En als u vandaag heeft geprobeerd een database van ondernemingsklasse te verkopen die geen gelijktijdigheid ondersteunt, je zou de kamer uit gelachen worden. Even belachelijk zou de suggestie zijn dat een individueel knooppunt 12 seconden moet wachten voordat hij het resultaat van zijn eigen transacties kan zien. Zoals Vitalik zelf onlangs getweet:

Belangrijkste punt over dapp dev dat ik ondergewaardeerd heb: belangrijkste probleem is niet tx kosten; ppl kan $ 0.001 aan. Waarschijnlijk is latentie; ppl wil 500ms, geen 17s.

- Vitalik Buterin (@VitalikButerin) 27 september 2015

Voor ons bij Coin Sciences is dit niet alleen een academische kwestie, want we moeten beslissen of en hoe we slimme contracten opnemen MultiChain. Vreemd genoeg, ondanks de honderden functieverzoeken en vragen die we tot nu toe hebben ontvangen, zijn er slechts twee gerelateerd aan slimme contracten, en zelfs dan in een zwakkere vorm dan Ethereum biedt. Dus hoewel we een open geest hebben, kan het blijken dat slimme contracten geen echte problemen voor onze gebruikers oplossen.

In het voordeel van Ethereum

Als u slechts in één kant van het argument geïnteresseerd bent, kunt u hier stoppen met lezen. Maar je vraagt ​​je misschien af: zijn de makers van Ethereum stom? Waarom zouden ze in vredesnaam wereldwijde uitvoering in een openbare gedistribueerde database nodig hebben, als elk knooppunt eenvoudig zou kunnen kiezen welke programma's het belangrijk vindt om te draaien? Zijn er goede redenen voor de Ethereum-manier?

Als we het eigenlijk over openbare blockchains hebben, denk ik dat die er zijn. Maar om deze redenen te begrijpen, moeten we nadenken over de dynamiek van het Ethereum-netwerk zelf.

Transactiespam voorkomen

Een blockchain wordt onderhouden door een peer-to-peer-netwerk, waarin elk knooppunt is verbonden met een willekeurige subset van de andere knooppunten. Wanneer een nieuwe transactie op één knooppunt wordt aangemaakt, verspreidt deze zich snel en lukraak naar de andere via een proces dat "relaying" wordt genoemd. In een open openbaar netwerk kan iedereen transacties maken, dus we hebben een manier nodig om ons daartegen te beschermen transactiespam die het systeem zou kunnen overweldigen. Omdat het netwerk gedecentraliseerd is, kan dit alleen worden bereikt door individuele knooppunten die nieuwe transacties beoordelen zodra ze binnenkomen en beslissen of ze deze al dan niet doorgeven. Hoewel dit mechanisme niet kan voorkomen dat een spammer overweldigend een individueel knooppunt, het beschermt het netwerk als geheel.

Wanneer een knooppunt in een openbaar netwerk beslist of een nieuwe transactie moet worden doorgestuurd, is een belangrijk criterium de verhouding tussen de vergoeding en de kosten voor het netwerk. In het geval van bitcoin zijn deze kosten voornamelijk gebaseerd op de onbewerkte grootte van de transactie in bytes. In Ethereum is een complexere formule wordt gebruikt, gebaseerd op de rekeninspanning die de transactie zal verbruiken. Hoe dan ook, vergoedingen fungeren als een marktgebaseerd mechanisme om transactiespam te voorkomen.

Maar hoe weet een knooppunt of de afzender voldoende geld heeft om de vergoeding te betalen die ze aanbieden? In het geval van Ethereum wordt het saldo van "ether" van elke gebruiker sindsdien beïnvloed door de uitkomst van eerdere transacties contracten kunnen ether zowel uitgeven als uitbetalen. Dus zonder alle programma's voor alle eerdere berichten daadwerkelijk uit te voeren, kan een Ethereum-knooppunt niet op de hoogte zijn van het actuele saldo van een gebruiker. Daarom kan het niet beoordelen of een transactie naar andere knooppunten moet worden doorgestuurd. En zonder dat zou een open netwerk triviaal kunnen worden vernietigd.

Compacte gegevensproeven

In een blockchain worden blokken meestal gevuld door de transacties die ze bevestigen. Elk blok heeft echter ook een compacte 'header', die belangrijke informatie bevat zoals een tijdstempel en een link naar het vorige blok. Voor openbare blockchains gebaseerd op bewijs van werk-hashing, is de invoer voor het hash-algoritme alleen deze blokheader. Dit betekent dat de autoriteit van een keten kan worden beoordeeld door een "lichtgewicht client" zonder de meeste inhoud te downloaden. Vanaf november 2015 is de volledige set bitcoin-headers bijvoorbeeld 30 MB groot, vergeleken met 45 GB voor de volledige keten. Dat is een verhouding van 1500: 1, wat een cruciaal verschil maakt voor mobiele apparaten met beperkte bandbreedte en opslag.

De header van elk Ethereum-blok bevat een "state root", die de staat van de keten met vingerafdrukken afdrukt na het verwerken van de transacties in dat blok. Deze status omvat onder meer de inhoud van de database van elk contract, waarbij de vingerafdruk efficiënt wordt berekend met behulp van een boom van eenrichtingshashfuncties. De minste wijziging in de database van een contract zou leiden tot een compleet andere root van de staat, dus de root "sluit" de inhoud van de database aan. (Een gelijkwaardige notie van "UTXO-verplichtingen" voor bitcoin is besproken maar nog niet geïmplementeerd.)

De boomachtige methode om staatswortels te berekenen heeft een belangrijke eigenschap: Gegeven een bekende status root, kan de waarde van een bepaald item in een contractdatabase efficiënt worden bewezen. De grootte van dit bewijs is evenredig met de diepte van een binaire boom waarvan de bladeren de individuele database-items zijn, dwz log₂ de totale databasegrootte. Dat betekent dat, voor een individuele inzending, alleen het bewijs dubbelspel in lengte wanneer de databasegrootte is kwadraat - het soort schaalbaarheid waar computerwetenschappers voor doodgaan. Bedenk nu dat de statusroot van elk blok in de header staat, wat een lichtgewicht client kan verifiëren. Als resultaat kunnen lichtgewicht clients veilig en efficiënt elk volledig knooppunt in het netwerk bevragen voor individuele database-items, en volledige knooppunten kunnen niet liegen.

Maar als onze blockchain-headers een state root bevatten, en de state root hangt af van de inhoud van de database, dan elk knooppunt moet de database van de blockchain up-to-date houden. Dit betekent op zijn beurt dat elk contract wordt uitgevoerd voor elk bericht dat het tot nu toe heeft ontvangen. Zonder dit zou een mining-node niet weten welke state-root in een block-header moet worden geplaatst, noch zouden andere nodes de blokken die ze ontvangen kunnen verifiëren. Het komt erop neer: als we willen dat lichtgewicht clients veilig compacte gegevensbewijzen uit het netwerk halen, moeten volledige knooppunten alle berekeningen uitvoeren die worden beschreven door de gegevens in de keten.

Het oordeel voor particuliere blockchains

Laten we deze twee argumenten opnieuw bekijken in de context van private blockchains. Het eerste dat u moet opmerken over privéketens is dat ze meestal geen native token of cryptocurrency hebben. Dit heeft verschillende redenen:

• Het soort entiteiten dat geïnteresseerd is in privéketens, wil niet omgaan met een nieuwe activaklasse.
• Het consensusmodel voor particuliere ketens is meer gebaseerd op overeenstemming tussen een set gesloten mijnwerkers dan op bewijs van werk. De kosten van mijnbouw zijn dus minimaal en mijnwerkers hebben niet veel beloning nodig.
• Omdat alle deelnemers aan een privéketen worden doorgelicht, is er minder bezorgdheid over spam en misbruik.

Bedenk dat het eerste argument voor wereldwijde uitvoering was om elk Ethereum-knooppunt in staat te stellen te beslissen of een inkomende transactie moet worden doorgestuurd, op basis van de vergoeding die het biedt. Welnu, het ontbreken van een native token maakt deze reden niet relevant, want als een blockchain geen native token heeft, transacties kunnen geen vergoedingen betalen. Als spam om de een of andere reden een probleem blijft, moet het op een andere manier worden gecontroleerd, bijvoorbeeld door de machtigingen van de afzender in te trekken.

Laten we nu eens kijken naar het tweede argument, om compacte gegevensbewijzen mogelijk te maken. Een openbare blockchain heeft waarschijnlijk eindgebruikers op mobiele of andere lichtgewicht portefeuilles. Maar dit is minder waarschijnlijk bij particuliere ketens, waarvan de primaire functie is het delen van een database tussen grotere bedrijven. En als de blockchain is toegankelijk vanaf een mobiel apparaat, is de mobiele gebruiker waarschijnlijk een klant van een van deze bedrijven en kan hij vertrouwen op wat dat bedrijf hen vertelt.

In plaats daarvan, in private blockchains, de problemen van wereldwijde executie zijn bijzonder acuut. Als een private blockchain geen native token heeft, hebben we geen gasachtig marktmechanisme om op hol geslagen code te voorkomen. In plaats daarvan zouden we een soort vaste limiet moeten invoeren in termen van rekenstappen per transactie. Maar om transacties opzettelijk veel verwerkingen te laten uitvoeren, zou deze limiet hoog moeten zijn. Als gevolg hiervan kan het netwerk nog steeds veel energie verspillen aan onbedoelde lussen voordat ze uiteindelijk worden afgesloten.

Wat concurrency betreft, zullen private blockchains veel waarschijnlijker het soort transactievolumes zien dat concurrency essentieel maakt. De capaciteit van openbare blockchains wordt beperkt door het feit dat ze, om zinvol gedecentraliseerd te kunnen worden, duizenden knooppunten nodig hebben die worden beheerd door enthousiastelingen met beperkte budgetten. Daarentegen zullen particuliere ketens veel eerder slechts enkele tientallen ondernemingen met elkaar verbinden, in welk geval capaciteit en snelheid essentieel zijn.

Dubbeldekker blockchains

Dus als alles over slimme contracten zinvol is in privéketens, afgezien van wereldwijde uitvoering, waar blijven we dan? Welk type blockchain geeft ons de prestaties en flexibiliteit die we nodig hebben? Om eerlijk te zijn denk ik er nog steeds over na. Maar een antwoord zou kunnen zijn: een blockchain met twee niveaus.

Het lagere niveau zou worden gebouwd op transacties in bitcoin-stijl die onmiddellijk en gelijktijdig worden verwerkt en niet hoeven te wachten op blokbevestigingen. Deze transacties kunnen eenvoudige bewegingen van activa uitvoeren, waaronder veilige transacties atomaire uitwisselingen, zonder toevlucht te nemen tot slimme contracten. Maar deze lagere laag zou ook worden gebruikt als een blinde opslaglaag voor de programma's en berichten die complexere bedrijfsprocessen vertegenwoordigen, ingebed als transactiemetagegevens.

Wat betreft het hogere niveau, zou elke netwerkdeelnemer kiezen welke programma's ze willen uitvoeren. Sommigen kiezen er misschien voor om er helemaal geen uit te voeren, omdat ze alleen geïnteresseerd zijn in eenvoudige activabewegingen. Anderen kunnen een kleine groep programma's uitvoeren die relevant zijn voor hun interne processen (met de wetenschap dat deze groep geen berichten uitwisselt met programma's van buitenaf). Sommigen kiezen misschien zelfs voor wereldwijde uitvoering, waarbij ze elk bericht voor elk programma verwerken, net als Ethereum. Maar het belangrijkste zou dat zijn elk knooppunt voert alleen de code uit die nodig is. In de informatica wordt deze techniek genoemd luie evaluatie, omdat het inhoudt dat er zo min mogelijk werk wordt verricht, zonder iets cruciaal te vergeten. Met luie evaluatie, als een blockchain-berekening misgaat, zullen alleen die knooppunten die dat programma daadwerkelijk uitvoeren, het opmerken. Het netwerk zelf voelt niets.

Wat MultiChain betreft, als we uiteindelijk de volledige berekening van Turing gaan ondersteunen, betwijfel ik of we een wereldwijde uitvoering zullen implementeren. Misschien gaan we voor dit soort luie tweeledige aanpak, of misschien bedenken we iets beters.

Slimme contracten in openbare blockchains

Zoals ik eerder betoogde, in publiek Turing complete blockchains zoals Ethereum, daar zijn goede redenen voor wereldwijde uitvoering. Maar hier is nog een vraag: wat is het onderneming use case voor deze kettingen? Laten we ons een toekomstige tijd voorstellen waarin ondernemingen voldoende vertrouwen hebben in openbare blockchains om ze te gebruiken voor echte bedrijfsprocessen. Als een groep bedrijven wat computationele logica wil inbedden in een openbare blockchain, hebben ze twee keuzes: (1) een blockchain in Ethereum-stijl gebruiken met wereldwijde uitvoering, of (2) elke blockchain als een eenvoudige opslaglaag en het zelf uitvoeren van de code. En gezien deze opties, waarom zouden ze kiezen (1)?

De rationele keuze zou de openbare blockchain zijn met (a) de goedkoopste prijs per opslagbyte en / of (b) het hoogste beveiligingsniveau op basis van het totale mijnvermogen. Omdat de berekening deterministisch is, hoeven de bedrijven alleen het netwerk te betalen shop hun contract en berichten, niet echt hen. Door een blockchain alleen voor opslag te gebruiken, kunnen ze bovendien elke gewenste programmeertaal. Dit kan de bytecode van Ethereum zijn, JavaScript / ECMAScript voor leesbaarheid of zelfs machine code voor hoge prestaties. Ethereum-contracten zelfs kan al worden opgeslagen metadata gebruiken op de bitcoin blockchain. Dit is precies de tweeledige aanpak die ik heb voorgesteld.

Deze discussie houdt verband met het idee van abstractielagen, beroemd gemaakt door de OSI-netwerkmodel. Voor optimale betrouwbaarheid en flexibiliteit moet elke laag van een systeem zo veel mogelijk worden geabstraheerd (dwz onafhankelijk) van de andere lagen. We zouden bijvoorbeeld niet willen dat onze harddiskcontrollers code bevatten voor het weergeven van JPEG-afbeeldingen. Dus waarom zouden we een blockchain willen om de programma's uit te voeren die het opslaat? Voor de meeste use-cases halen we hier geen voordeel uit, en het brengt aanzienlijke kosten met zich mee.

Epiloog

Als wereldwijde executie geen zin heeft in privé-blockchains, waarom werkt iedereen dan aan dit spul? Ik denk dat dit, althans gedeeltelijk, kan worden verklaard door een misverstand over wat blockchains kunnen doen in de echte wereld. Zie je, openbare blockchains zoals bitcoin kunnen dat direct een echte asset verplaatsen (namelijk hun eigen valuta), omdat de blockchain definieert het eigendom van die valuta. Dit brengt twee aspecten van activa samen die doorgaans verschillend zijn: (a) een grootboek waarin wordt vastgelegd wie de eigenaar is van de activa, en (b) de feitelijke fysieke locatie. Dit maakt cryptocurrencies het ultieme instrument aan toonder, het creëren van een dappere nieuwe wereld of een paradijs voor witwassers, afhankelijk van wie je het vraagt.

Maar voor andere activa die onafhankelijk van een blockchain bestaan, is het enige dat een ketting kan doen, een record van wie ze moet behoren tot. Dit blijft zo totdat we de primaire uitgifte van activa op een blockchain, waarbij het juridische eigendom van dat activum wordt gedefinieerd in termen van de database van de keten. Voor de institutionele financiële sector denk ik dat deze dag nog ver weg is, niet in de laatste plaats vanwege de vereiste wijzigingen in de regelgeving. Tot dan, er zal altijd een extra stap zijn, contractueel en procedureel, tussen wat de blockchain zegt en wat er in de echte wereld gebeurt. Deze stap kan net zo goed een Turing complete code bevatten, lui uitgevoerd op het laatst mogelijke moment.

Dit probleem wordt benadrukt door het geval van "slimme obligaties" waar we zo veel over hebben gehoord. Een slimme obligatie wordt rechtstreeks op een blockchain uitgegeven, waarbij de blockchain ervoor zorgt dat couponbetalingen op de juiste momenten aan de obligatiehouders worden gedaan. Allemaal goed en wel. Maar wat gebeurt er als de uitgever van de obligatie onvoldoende geld op zijn blockchain-account heeft staan ​​om een ​​verschuldigde betaling te dekken? De blockchain kan zeker een vlag zetten om te zeggen dat er iets mis is, maar het kan niets anders doen. We hebben nog steeds een leger van advocaten en accountants nodig om de hele puinhoop op te lossen, of het nu gaat om een ​​haircut, schuldherstructurering, verbeurdverklaring of een regelrecht faillissement. In het kort:

Als slimme contracten hun belofte niet kunnen waarmaken, waarom betalen we dan hun prijs?

Bedankt voor het lezen.

Bron: https://www.multichain.com/blog/2015/11/smart-contracts-good-bad-lazy/