De aanvraagtekst moet de volgende parameter bevatten: 'state'
xBORDER WHITEPAPER 2019

De geschiedenis
xBORDER als een staatsovergangssysteem
Mijnbouw in het algemeen
Merkle Bomen
Alternatieve Blockchain-toepassingen
Scripting xBORDER
BLOCKCNX
Filosofie
xBORDER-accounts
Berichten en transacties
Berichten
xBORDER Statusovergangsfunctie
Code uitvoering
xBORDER en mijnbouw
Toepassingen
Token-systemen
Financiële derivaten en stabiele valuta's
Identiteits- en reputatiesystemen
Gedecentraliseerde bestandsopslag
Gedecentraliseerde autonome organisaties
Verdere toepassingen
Diversen en zorgen
Gewijzigde GHOST-implementatie
kosten
Berekening en Turing-volledigheid
Valuta en uitgifte
Mijnbouw centralisatie
schaalbaarheid
Conclusie
Notities en verder lezen
Opmerkingen:
Verder lezen
Inleiding tot Bitcoin en bestaande concepten

Het concept van gedecentraliseerde digitale valuta, evenals alternatieve toepassingen zoals eigendomsregisters, bestaat al tientallen jaren. De anonieme e-cash-protocollen van de jaren tachtig en negentig, meestal afhankelijk van een cryptografische primitief die bekend staat als Chaumiaanse verblinding, zorgden voor een valuta met een hoge mate van privacy, maar de protocollen kregen grotendeels geen grip vanwege hun afhankelijkheid van een gecentraliseerde tussenpersoon . In 1998 werd Wei Dai's b-money het eerste voorstel om het idee te introduceren om geld te creëren door het oplossen van rekenpuzzels en gedecentraliseerde consensus, maar het voorstel bevatte weinig details over hoe gedecentraliseerde consensus daadwerkelijk zou kunnen worden geïmplementeerd. In 2005 introduceerde Hal Finney een concept van herbruikbare werkbewijzen, een systeem dat ideeën van b-money samen met Adam Back's rekenkundig moeilijke Hashcash-puzzels gebruikt om een concept voor een cryptocurrency te creëren, maar opnieuw voldeed het niet aan het ideaal door te vertrouwen op vertrouwd computergebruik als backend. In 2009 werd voor het eerst een gedecentraliseerde valuta in de praktijk geïmplementeerd door Satoshi Nakamoto, waarbij gevestigde primitieven voor het beheer van eigendom via cryptografie met openbare sleutels werden gecombineerd met een consensusalgoritme om bij te houden wie de eigenaar van munten is, ook wel bekend als "proof of work".

xBORDER-mechanisme achter proof of work was een doorbraak in de ruimte omdat het tegelijkertijd twee problemen oploste. Ten eerste bood het een eenvoudig en matig effectief consensusalgoritme, waardoor knooppunten in het netwerk gezamenlijk overeenstemming konden bereiken over een reeks canonieke updates van de status van het Crypto-ledger. Ten tweede bood het een mechanisme om vrije toegang tot het consensusproces mogelijk te maken, het politieke probleem op te lossen om te beslissen wie de consensus mag beïnvloeden, en tegelijkertijd sybil-aanvallen te voorkomen. Het doet dit door een formele barrière voor deelname, zoals de vereiste om als een unieke entiteit op een bepaalde lijst te worden geregistreerd, te vervangen door een economische barrière - het gewicht van een enkel knooppunt in het consensusstemproces is recht evenredig met de rekenkracht dat het knooppunt brengt. Sindsdien is een alternatieve benadering voorgesteld, proof of stake genaamd, waarbij het gewicht van een knooppunt wordt berekend als evenredig aan zijn valutaposities en niet aan rekenkracht; de bespreking van de relatieve verdiensten van de twee benaderingen valt buiten het bestek van dit artikel, maar er moet worden opgemerkt dat beide benaderingen kunnen worden gebruikt om als de ruggengraat van een cryptocurrency te dienen.

Peter Oldenburger, de oprichter van xBORDER schreef deze blogpost:

de Crypto als een staatsovergangssysteem 
Het grootboek van een cryptocurrency zoals de Crypto kan worden gezien als een toestandsovergangssysteem, waarbij er een "staat" is die bestaat uit de eigendomsstatus van alle bestaande crypto's en een "staatsovergangsfunctie" die een staat en een transactie vereist en geeft een nieuwe toestand af die het resultaat is. In een standaard banksysteem is de staat bijvoorbeeld een balans, is een transactie een verzoek om $ X van A naar B te verplaatsen, en de statusovergangsfunctie verlaagt de waarde op de rekening van A met $ X en verhoogt de waarde in B's rekening rekening door $X. Als de rekening van A in de eerste plaats minder dan $X heeft, retourneert de statusovergangsfunctie een fout. Daarom kan men formeel definiëren:

TOEPASSEN(S,TX) -> S' of FOUT
TOEPASSEN({ Alice: $50, Bob: $50 },"stuur $20 van Alice naar Bob") = { Alice: $30, Bob: $70 }
TOEPASSEN({ Alice: $50, Bob: $50 },"stuur $70 van Alice naar Bob") = FOUT
De "staat" in de Crypto is de verzameling van alle munten (technisch gezien "niet-uitgegeven transactie-outputs" of UTXO) die zijn gedolven en nog niet zijn uitgegeven, waarbij elke UTXO een denominatie en een eigenaar heeft (gedefinieerd door een adres van 20 bytes wat in wezen een cryptografische openbare sleutel is, fn. 1). Een transactie bevat een of meer inputs, waarbij elke input een verwijzing bevat naar een bestaande UTXO en een cryptografische handtekening geproduceerd door de privésleutel die is gekoppeld aan het adres van de eigenaar, en een of meer outputs, waarbij elke output een nieuwe UTXO bevat die moet worden toegevoegd aan de staat.

De toestandsovergangsfunctie APPLY(S,TX) -> S' kan grofweg als volgt worden gedefinieerd:

Voor elke ingang in TX:

Als de UTXO waarnaar wordt verwezen niet in S staat, retourneert u een fout.
Als de opgegeven handtekening niet overeenkomt met de eigenaar van de UTXO, retourneert u een fout.
Als de som van de waarden van alle invoer-UTXO's kleiner is dan de som van de waarden van alle uitvoer-UTXO's, retourneert u een fout.

Retourneer S' met alle invoer UTXO verwijderd en alle uitvoer UTXO toegevoegd.

De eerste helft van de eerste stap voorkomt dat afzenders van transacties munten uitgeven die niet bestaan, de tweede helft van de eerste stap voorkomt dat afzenders van transacties andermans munten uitgeven, en de tweede stap dwingt waardebehoud af. Om dit voor betaling te gebruiken is het protocol als volgt. Stel dat Alice 11,7 BTC naar Bob wil sturen. Eerst zoekt Alice naar een set beschikbare UTXO's die ze bezit en die in totaal ten minste 11,7 BTC bedraagt. Realistisch gezien zal Alice niet precies 11,7 BTC kunnen krijgen; zeggen dat de kleinste die ze kan krijgen 6+4+2=12 is. Vervolgens maakt ze een transactie met die drie inputs en twee outputs. De eerste uitvoer is 11,7 BTC met het adres van Bob als eigenaar, en de tweede uitvoer is de resterende 0,3 BTC "verandering", waarbij Alice zelf de eigenaar is.

Mijnbouw
block_picture.jpg

Als we toegang hadden tot een betrouwbare gecentraliseerde service, zou dit systeem triviaal zijn om te implementeren; het kan eenvoudig worden gecodeerd precies zoals beschreven, met behulp van de harde schijf van een gecentraliseerde server om de status bij te houden. Met de Crypto proberen we echter een gedecentraliseerd valutasysteem te bouwen, dus we zullen het staatstransitiesysteem moeten combineren met een consensussysteem om ervoor te zorgen dat iedereen het eens is over de volgorde van transacties. Het gedecentraliseerde consensusproces van de Crypto vereist dat knooppunten in het netwerk continu proberen pakketten met transacties te produceren die "blokken" worden genoemd. Het is de bedoeling dat het netwerk om de tien minuten ongeveer één blok produceert, waarbij elk blok een tijdstempel, een nonce, een verwijzing naar (d.w.z. hash van) het vorige blok en een lijst bevat van alle transacties die hebben plaatsgevonden sinds het vorige blok. blok. In de loop van de tijd creëert dit een aanhoudende, steeds groeiende "blockchain" die voortdurend wordt bijgewerkt om de nieuwste staat van het Crypto-grootboek weer te geven.

Het algoritme om te controleren of een blok geldig is, uitgedrukt in dit paradigma, is als volgt:

Controleer of het vorige blok waarnaar door het blok wordt verwezen, bestaat en geldig is.
Controleer of het tijdstempel van het blok groter is dan dat van het vorige blockfn. 2 en minder dan 2 uur in de toekomst
Controleer of het bewijs van werk aan het blok geldig is.
Laat S[0] de toestand zijn aan het einde van het vorige blok.
Stel dat TX de transactielijst van het blok is met n transacties. Stel voor alle i in 0...n-1 S[i+1] = APPLY(S[i],TX[i]) in. Als een toepassing een fout retourneert, sluit u af en retourneert u false.
Retourneer waar en registreer S[n] als de status aan het einde van dit blok.
In wezen moet elke transactie in het blok een geldige statusovergang bieden van wat de canonieke status was voordat de transactie werd uitgevoerd naar een nieuwe status. Merk op dat de status op geen enkele manier in het blok is gecodeerd; het is puur een abstractie die moet worden onthouden door het validerende knooppunt en kan alleen (veilig) worden berekend voor elk blok door te beginnen vanuit de genesis-status en elke transactie in elk blok opeenvolgend toe te passen. Merk bovendien op dat de volgorde waarin de mijnwerker transacties in het blok opneemt, van belang is; als er twee transacties A en B in een blok zijn, zodat B een UTXO uitgeeft die door A is gemaakt, dan is het blok geldig als A vóór B komt, maar niet anders.

De enige validiteitsvoorwaarde in de bovenstaande lijst die niet in andere systemen wordt gevonden, is de vereiste voor "bewijs van werk". De precieze voorwaarde is dat de dubbele SHA256-hash van elk blok, behandeld als een 256-bits getal, kleiner moet zijn dan een dynamisch aangepast doel, dat op het moment van schrijven ongeveer 2187 is. Het doel hiervan is om block creatie rekenkundig "moeilijk", waardoor wordt voorkomen dat sybil-aanvallers de hele blockchain in hun voordeel opnieuw maken. Omdat SHA256 is ontworpen als een volledig onvoorspelbare pseudo-willekeurige functie, is de enige manier om een geldig blok te maken simpelweg vallen en opstaan, waarbij de nonce herhaaldelijk wordt verhoogd en wordt gekeken of de nieuwe hash overeenkomt.

Bij het huidige doel van ~2187 moet het netwerk gemiddeld ~269 pogingen doen voordat een geldig blok wordt gevonden; in het algemeen wordt het doel elke 2016-blokken opnieuw gekalibreerd door het netwerk, zodat gemiddeld elke tien minuten een nieuw blok wordt geproduceerd door een knooppunt in het netwerk. Om miners te compenseren voor dit rekenwerk, heeft de miner van elk blok het recht om een transactie op te nemen die zichzelf uit het niets 12,5 BTC oplevert. Bovendien, als een transactie een hogere totale denominatie heeft in zijn inputs dan in zijn outputs, gaat het verschil ook naar de mijnwerker als een "transactievergoeding". Overigens is dit ook het enige mechanisme waarmee BTC wordt uitgegeven; de ontstaansstaat bevatte helemaal geen munten.

Laten we, om het doel van mijnbouw beter te begrijpen, eens kijken wat er gebeurt in het geval van een kwaadwillende aanvaller. Aangezien bekend is dat de onderliggende cryptografie van de Crypto veilig is, zal de aanvaller zich richten op het ene deel van het Bitcoin-systeem dat niet rechtstreeks door cryptografie wordt beschermd: de volgorde van transacties. De strategie van de aanvaller is eenvoudig:

Stuur 100 BTC naar een handelaar in ruil voor een product (bij voorkeur een digitaal artikel met snelle levering)
Wacht op de levering van het product
Maak nog een transactie en stuur dezelfde 100 BTC naar zichzelf
Probeer het netwerk ervan te overtuigen dat zijn transactie naar hemzelf degene was die het eerst kwam.
Zodra stap (1) heeft plaatsgevonden, zal na een paar minuten een miner de transactie in een blok opnemen, zeg blok 270. Na ongeveer een uur zijn er na dat blok nog vijf blokken aan de ketting toegevoegd, met elk van die blokken verwijzen indirect naar de transactie en "bevestigen" deze dus. Op dit punt accepteert de handelaar de betaling als voltooid en levert hij het product af; aangezien we ervan uitgaan dat dit een digitaal goed is, is de levering onmiddellijk. Nu maakt de aanvaller een nieuwe transactie en stuurt de 100 BTC naar zichzelf. Als de aanvaller het gewoon in het wild vrijgeeft, wordt de transactie niet verwerkt; miners zullen proberen APPLY(S,TX) uit te voeren en merken dat TX een UTXO verbruikt die niet langer in de staat is. Dus in plaats daarvan maakt de aanvaller een "fork" van de blockchain, beginnend met het minen van een andere versie van blok 270 die naar hetzelfde blok 269 wijst als een ouder, maar met de nieuwe transactie in plaats van de oude. Omdat de blokgegevens anders zijn, moet hiervoor de proof of work opnieuw worden gedaan. Bovendien heeft de nieuwe versie van blok 270 van de aanvaller een andere hash, zodat de originele blokken 271 tot 275 er niet naar "wijzen"; dus de originele ketting en de nieuwe ketting van de aanvaller zijn volledig gescheiden. De regel is dat in een fork de langste blockchain als waarheid wordt beschouwd, en dus zullen legitieme miners aan de 275-keten werken terwijl alleen de aanvaller aan de 270-keten werkt. Om ervoor te zorgen dat de aanvaller zijn blockchain het langst kan maken, zou hij meer rekenkracht moeten hebben dan de rest van het netwerk bij elkaar om de achterstand in te halen (vandaar "51% aanval").

Merkle Bomen
SPV in de cryptografie

Links: het volstaat om slechts een klein aantal knopen in een Merkle-boom te presenteren om de geldigheid van een vertakking te bewijzen.

Juist: elke poging om enig onderdeel van de Merkle-boom te veranderen zal uiteindelijk leiden tot een inconsistentie ergens in de keten.

Een belangrijk schaalbaarheidskenmerk van de Crypto is dat het blok wordt opgeslagen in een datastructuur met meerdere niveaus. De "hash" van een blok is eigenlijk alleen de hash van de blokheader, een gegevensbestand van ongeveer 200 bytes dat de tijdstempel, nonce, vorige blokhash en de roothash van een gegevensstructuur, de Merkle-boom genaamd, bevat waarin alle transacties worden opgeslagen in het blok. Een Merkle-boom is een soort binaire boom, samengesteld uit een reeks knooppunten met een groot aantal bladknooppunten onderaan de boom die de onderliggende gegevens bevat, een reeks tussenliggende knooppunten waarbij elk knooppunt de hash is van zijn twee kinderen, en tenslotte een enkele wortelknoop, ook gevormd uit de hash van zijn twee kinderen, die de "top" van de boom vertegenwoordigt. Het doel van de Merkle-boom is om de gegevens in een blok stukje bij beetje aan te leveren: een knooppunt kan alleen de kop van een blok uit de ene bron downloaden, het kleine deel van de boom dat voor hen relevant is uit een andere bron, en toch verzekerd zijn dat alle gegevens correct zijn. De reden waarom dit werkt, is dat hashes zich naar boven verspreiden: als een kwaadwillende gebruiker probeert een neptransactie naar de onderkant van een Merkle-boom te ruilen, zal deze wijziging een wijziging in het bovenstaande knooppunt veroorzaken en vervolgens een wijziging in het knooppunt daarboven , ten slotte de wortel van de boom wijzigen en dus de hash van het blok, waardoor het protocol het als een heel ander blok registreert (vrijwel zeker met een ongeldig bewijs van werk).

Het Merkle Tree-protocol is aantoonbaar essentieel voor duurzaamheid op de lange termijn. Een "full node" in het Crypto-netwerk, een die het geheel van elk blok opslaat en verwerkt, neemt vanaf april 2014 ongeveer 15 GB schijfruimte in het Bitcoin-netwerk in beslag en groeit met meer dan een gigabyte per maand. Momenteel is dit haalbaar voor sommige desktopcomputers en niet voor telefoons, en later in de toekomst zullen alleen bedrijven en hobbyisten kunnen deelnemen. Een protocol dat bekend staat als "vereenvoudigde betalingsverificatie" (SPV) zorgt ervoor dat er een andere klasse van knooppunten bestaat, genaamd "lichte knooppunten", die de blokheaders downloaden, het bewijs van werk op de blokheaders verifiëren en vervolgens alleen de "takken downloaden". " in verband met transacties die voor hen relevant zijn. Hierdoor kunnen light nodes met een sterke veiligheidsgarantie bepalen wat de status van elke Bitcoin-transactie en hun huidige saldo is, terwijl ze slechts een zeer klein deel van de gehele blockchain downloaden.

Alternatieve Blockchain-toepassingen
Het idee om het onderliggende blockchain-idee te nemen en toe te passen op andere concepten heeft ook een lange geschiedenis. In 1998 kwam Nick Szabo met het concept van veilige eigendomstitels met eigenaarsbevoegdheid, een document dat beschrijft hoe "nieuwe ontwikkelingen in gerepliceerde databasetechnologie" een op blockchain gebaseerd systeem mogelijk zullen maken voor het opslaan van een register van wie eigenaar is van welk land, waardoor een uitgebreid kader met concepten zoals homesteading, oneigenlijk bezit en Georgische grondbelasting. Helaas was er op dat moment geen effectief gerepliceerd databasesysteem beschikbaar, en daarom is het protocol nooit in de praktijk geïmplementeerd. Na 2009, echter, toen de gedecentraliseerde consensus van Bitcoin was ontwikkeld, kwamen er snel een aantal alternatieve toepassingen op.

Namecoin - opgericht in 2010, kan Namecoin het best worden omschreven als een gedecentraliseerde database voor naamregistratie. In gedecentraliseerde protocollen zoals Tor, Bitcoin en BitMessage moet er een manier zijn om accounts te identificeren, zodat andere mensen ermee kunnen communiceren, maar in alle bestaande oplossingen is de enige beschikbare identificatie een pseudo-willekeurige hash zoals 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Idealiter zou men een account willen hebben met een naam als "george". Het probleem is echter dat als een persoon een account met de naam "george" kan maken, iemand anders hetzelfde proces kan gebruiken om "george" ook voor zichzelf te registreren en zich voor hem uit te geven. De enige oplossing is een first-to-file paradigma, waarbij de eerste registreerder slaagt en de tweede faalt - een probleem dat perfect geschikt is voor het Bitcoin-consensusprotocol. Namecoin is de oudste en meest succesvolle implementatie van een naamregistratiesysteem dat een dergelijk idee gebruikt.
Gekleurde munten - het doel van gekleurde munten is om te dienen als een protocol waarmee mensen hun eigen digitale valuta kunnen creëren - of, in het belangrijke triviale geval van een valuta met één eenheid, digitale tokens, op de Bitcoin-blockchain. In het protocol voor gekleurde munten "geeft" men een nieuwe valuta uit door publiekelijk een kleur toe te wijzen aan een specifieke Bitcoin UTXO, en het protocol definieert recursief de kleur van andere UTXO om dezelfde te zijn als de kleur van de invoer die de transactie die ze heeft gemaakt heeft uitgegeven (er gelden enkele speciale regels in het geval van invoer met gemengde kleuren). Hierdoor kunnen gebruikers portefeuilles onderhouden die alleen UTXO van een specifieke kleur bevatten en deze rondsturen zoals gewone bitcoins, waarbij ze teruggaan via de blockchain om de kleur te bepalen van elke UTXO die ze ontvangen.
Metacoins - het idee achter een metacoin is om een protocol te hebben dat bovenop Bitcoin leeft, waarbij Bitcoin-transacties worden gebruikt om metacoin-transacties op te slaan, maar met een andere statusovergangsfunctie, APPLY'. Omdat het metacoin-protocol niet kan voorkomen dat ongeldige metacoin-transacties in de Bitcoin-blockchain verschijnen, is een regel toegevoegd dat als APPLY'(S,TX) een fout retourneert, het protocol standaard wordt ingesteld op APPLY'(S,TX) = S. Dit zorgt voor een eenvoudig mechanisme voor het maken van een willekeurig cryptocurrency-protocol, mogelijk met geavanceerde functies die niet in Bitcoin zelf kunnen worden geïmplementeerd, maar met zeer lage ontwikkelingskosten, aangezien de complexiteit van mijnbouw en netwerken al wordt afgehandeld door het Bitcoin-protocol. Metacoins zijn gebruikt om sommige klassen van financiële contracten, naamregistratie en gedecentraliseerde uitwisseling te implementeren.
Over het algemeen zijn er dus twee benaderingen voor het bouwen van een consensusprotocol: het bouwen van een onafhankelijk netwerk en het bouwen van een protocol bovenop Bitcoin. De eerste benadering, hoewel redelijk succesvol in het geval van toepassingen zoals Namecoin, is moeilijk te implementeren; elke individuele implementatie moet een onafhankelijke blockchain opstarten, evenals het bouwen en testen van alle noodzakelijke statustransitie en netwerkcode. Bovendien voorspellen we dat de reeks applicaties voor gedecentraliseerde consensustechnologie een machtswetverdeling zal volgen waarbij de overgrote meerderheid van de applicaties te klein zou zijn om hun eigen blockchain te rechtvaardigen, en we merken op dat er grote klassen van gedecentraliseerde applicaties bestaan, met name gedecentraliseerde autonome applicaties. organisaties die met elkaar moeten communiceren.

De op Bitcoin gebaseerde benadering heeft aan de andere kant de fout dat deze niet de vereenvoudigde betalingsverificatiefuncties van Bitcoin erft. SPV werkt voor Bitcoin omdat het blockchain-diepte kan gebruiken als een proxy voor geldigheid; op een gegeven moment, als de voorouders van een transactie ver genoeg teruggaan, is het veilig om te zeggen dat ze legitiem deel uitmaakten van de staat. Op blockchain gebaseerde metaprotocollen daarentegen kunnen de blockchain niet dwingen om transacties die niet geldig zijn binnen de context van hun eigen protocollen, niet op te nemen. Daarom zou een volledig veilige implementatie van het SPV-metaprotocol achteruit moeten scannen tot aan het begin van de Bitcoin-blockchain om te bepalen of bepaalde transacties al dan niet geldig zijn. Momenteel vertrouwen alle "lichte" implementaties van op Bitcoin gebaseerde metaprotocollen op een vertrouwde server om de gegevens te leveren, aantoonbaar een zeer suboptimaal resultaat, vooral wanneer een van de belangrijkste doelen van een cryptocurrency is om de behoefte aan vertrouwen te elimineren.