I den här artikeln kommer jag att berätta om DAG (Directed Acyclic Graph) och dess tillämpning i distribuerade ledgers, och vi kommer att jämföra det med blockchain.
DAG är inget nytt i kryptovalutornas värld. Du kanske har hört talas om det som en lösning på problem med skalbarhet av blockkedjor. Men idag ska vi inte prata om skalbarhet, utan om vad som skiljer kryptovalutor från allt annat: decentralisering, brist på mellanhänder och censurmotstånd.
Jag kommer också att visa dig att DAG faktiskt är mer censurbeständig och att det inte finns några mellanhänder för att komma åt reskontran.
I de blockkedjor vi är bekanta med har användare inte direkt tillgång till själva reskontran. När du vill lägga till en transaktion i reskontran måste du "be" blockproducenten (a.k.a. "gruvarbetare") att göra det. Det är gruvarbetarna som bestämmer vilken transaktion som ska läggas till i nästa block och vilken inte. Det är gruvarbetarna som har exklusiv tillgång till block och rätten att bestämma vems transaktion som ska accepteras för inkludering i reskontran.
Gruvarbetare är mellanhänder som står mellan dig och den distribuerade huvudboken.
I praktiken kontrollerar vanligtvis ett litet antal gruvarbetare tillsammans mer än hälften av nätverkets datorkraft. För Bitcoin är det fyra pooler, för Ethereum - två. Om de samarbetar kan de blockera alla transaktioner de vill.
Under de senaste åren har många varianter av blockkedjor föreslagits, som skiljer sig åt i principerna för att välja blockproducenter. Men blockproducenterna själva går ingenstans, de "står fortfarande vid barriären": varje transaktion måste gå via blockproducenten, och om han inte accepterar det, så existerar faktiskt inte transaktionen.
Detta är ett oundvikligt problem med blockchain. Och om vi vill lösa det måste vi radikalt ändra designen och helt göra oss av med block och blockproducenter. Och istället för att bygga en kedja av block kommer vi att koppla samman transaktionerna själva, inklusive hasharna från flera tidigare i varje transaktion. Som ett resultat får vi en struktur känd inom matematiken som en riktad acyklisk graf - DAG.
Nu har alla direkt tillgång till registret, utan mellanhänder. När du vill lägga till en transaktion i reskontran lägger du helt enkelt till den. Du väljer flera överordnade transaktioner, lägger till dina data, signerar och skickar din transaktion till peers på nätverket. Redo. Det finns ingen som hindrar dig från att göra detta, så din transaktion finns redan i huvudboken.
Detta är det mest decentraliserade, mest censursäkra sättet att lägga till transaktioner i redovisningen utan mellanhänder. Eftersom alla helt enkelt lägger till sina transaktioner i registret utan att fråga om tillstånd från någon.
DAG kan betraktas som det tredje steget i utvecklingen av register. Först fanns det centraliserade register, där en part kontrollerade tillgången till dem. Sedan kom blockkedjor, som redan hade flera controllers som registrerade transaktioner i reskontran. Och slutligen, det finns inga kontrollanter alls i DAG, användare lägger till sina transaktioner direkt.
Nu när vi har den här friheten borde det inte leda till kaos. Vi måste ha enighet om registrets tillstånd. Och denna överenskommelse, eller konsensus, betyder vanligtvis enighet om två saker:
- Vad hände?
- I vilken ordning hände detta?
Vi kan enkelt svara på den första frågan: när en korrekt skapad transaktion har lagts till i reskontran har den inträffat. Och punkt. Information om detta kan nå alla deltagare vid olika tidpunkter, men så småningom kommer alla noder att ta emot denna transaktion och veta att det hände.
Om det var en blockchain skulle gruvarbetare bestämma vad som händer. Vad gruvarbetaren än bestämmer sig för att inkludera i ett block är vad som händer. Allt som han inte tar med i blocket händer inte.
I blockkedjor löser gruvarbetare också ett andra problem med konsensus: ordning. De får beställa transaktionerna inom blocket som de vill.
Hur bestämmer man ordningen för transaktioner i en DAG?
Bara för att vår graf är riktad har vi redan en viss ordning. Varje transaktion hänvisar till en eller flera tidigare överordnade. Föräldrar hänvisar i sin tur till sina föräldrar och så vidare. Föräldrar dyker uppenbarligen före barntransaktioner. Om någon av transaktionerna kan nås genom övergångar mellan förälder-underlänkar, vet vi exakt ordningen mellan transaktionerna i den transaktionskedjan.
Men ordningen mellan transaktionerna kan inte alltid bestämmas utifrån grafens form enbart. Till exempel när två transaktioner ligger på parallella grenar av grafen.
För att lösa oklarheter i sådana fall förlitar vi oss på så kallade orderleverantörer. Vi kallar dem också "vittnen". Det är vanliga användare vars uppgift är att hela tiden skicka transaktioner till nätet på ett ordnat sätt, d.v.s. så att var och en av deras tidigare transaktioner kan nås genom övergångar längs föräldra-barn-länkarna. Orderleverantörer är betrodda användare, och hela nätverket förlitar sig på att de inte bryter mot denna regel. För att rationellt lita på dem kräver vi att varje orderleverantör är en känd (icke-anonym) person eller organisation och har något att förlora om den bryter mot reglerna, såsom rykte eller affärer baserade på förtroende.
Orderleverantörer väljs av användare och varje användare inkluderar en lista över sina betrodda leverantörer i varje transaktion som den skickar till nätverket. Denna lista består av 12 leverantörer. Detta är ett tillräckligt litet antal för att en person ska kunna verifiera identiteten och ryktet för var och en av dem, och tillräckligt för att säkerställa att nätverket fortsätter att fungera i händelse av oundvikliga problem med en minoritet av orderleverantörer.
Denna lista över leverantörer varierar från användare till användare, men listorna över närliggande transaktioner kan skilja sig åt med upp till en leverantör.
Nu när vi har orderleverantörer kan vi isolera deras transaktioner till en DAG och beställa alla andra transaktioner runt ordern som skapats av dem. Det är möjligt att skapa en sådan algoritm (se. för tekniska detaljer).
Men ordningen för hela nätverket kan inte bestämmas direkt, vi behöver tid för orderleverantörerna att skicka ett tillräckligt antal av sina transaktioner för att verifiera den slutliga ordningen på tidigare transaktioner.
Och eftersom ordningen endast bestäms av positionerna för leverantörernas transaktioner i DAG, kommer alla noder på nätverket förr eller senare att ta emot alla transaktioner och komma till samma slutsats angående ordningen för transaktionerna.
Så vi har enighet om vad vi anser ha hänt: alla transaktioner som hamnar i DAG hände. Vi har också enighet om händelseordningen: detta framgår antingen av relationerna mellan transaktioner eller härleds från ordningen på transaktioner som skickas av orderleverantörer. Så vi har en konsensus.
Vi har den här versionen av konsensus i Obyte. Även om åtkomsten till Obyte-reskontran är helt decentraliserad, är konsensusen om transaktionsordningen fortfarande centraliserad eftersom 10 av 12 leverantörer kontrolleras av skaparen (Anton Churyumov), och endast två av dem är oberoende. Vi letar efter kandidater som är villiga att bli en av de oberoende orderleverantörerna för att hjälpa oss att decentralisera beställningen av reskontran.
Nyligen har en tredje oberoende kandidat dykt upp villig att installera och underhålla en orderleverantörsnod - University of Nicosia.
Hur kontrollerar vi dubbla utgifter?
Enligt reglerna, om två transaktioner upptäcks som spenderar samma mynt, vinner den transaktion som kommer först i den slutliga ordningen av alla transaktioner. Den andra ogiltigförklaras av konsensusalgoritmen.
Om det är möjligt att upprätta ordning mellan två transaktioner som spenderar samma mynt (genom förälder-barn-förbindelser), så avvisar alla noder omedelbart ett sådant försök att dubbla utgifterna.
Om ordern inte är synlig från de överordnade relationerna mellan två sådana transaktioner, accepteras de båda i reskontran, och vi kommer att behöva vänta på konsensus och upprättande av ordern mellan dem med hjälp av orderleverantörerna. Då vinner den tidigare transaktionen och den andra blir ogiltig.
Även om den andra transaktionen blir ogiltig, finns den fortfarande kvar i registret eftersom den redan har efterföljande transaktioner som refererar till den, som inte har brutit mot någonting och inte visste att denna transaktion skulle bli ogiltig i framtiden. Annars skulle vi behöva ta bort föräldern till goda efterföljande transaktioner, vilket skulle bryta mot huvudprincipen för nätverket - alla korrekta transaktioner accepteras i reskontran.
Detta är en mycket viktig regel som gör att hela systemet är motståndskraftigt mot censurförsök.
Låt oss föreställa oss att alla orderleverantörer samarbetar i ett försök att "censurera" en specifik transaktion. De kan ignorera det och aldrig välja det som "förälder" för sina transaktioner, men det räcker inte, transaktionen kan fortfarande inkluderas indirekt som förälder till någon annan transaktion utfärdad av vilken användare som helst i nätverket som inte samarbetar. Med tiden kommer en sådan transaktion att ta emot fler och fler barn, barnbarn och barnbarnsbarn från vanliga användare, som växer som en snöboll, och alla överenskomna orderleverantörer måste också ignorera dessa transaktioner. Så småningom kommer de att behöva censurera hela nätverket, vilket är liktydigt med sabotage.
På så sätt förblir DAG censurresistent även om det råder samverkan mellan orderleverantörerna, och överträffar därmed den censurresistenta blockkedjan där vi inte kan göra någonting om gruvarbetarna beslutar sig för att inte inkludera någon av transaktionerna. Och detta följer av DAGs huvudegenskap: deltagande i registret är helt oberoende och utan mellanhänder, och transaktioner är oåterkalleliga.
Källa: will.com