Jag vet jag vet. Det finns många kryptoprojekt, det finns många konsensus: baserat på arbete och ägande, guld, olja, bakade pajer (det finns en, ja, ja). Vad mer behöver vi av en? Detta är vad jag föreslår att diskutera efter att ha läst översättningen av den "lätta" tekniska dokumentationen för *Constellation-projektet (). Naturligtvis är detta inte en fullständig beskrivning av algoritmen, men jag är intresserad av Habr-gemenskapens åsikt, finns det en plats för en sådan konsensus att "vara" eller är det onödigt?
Det finns inte många fler bokstäver, så om du bara vill skriva "wow, så mycket du kan om krypto", vänligen avstå. Om du är intresserad av nya utvecklingar inom området distribuerade system och har något att dela med dig av i kommentarerna, vänligen hänvisa till kat.
PS Jag är inte författaren till tekniken, jag kan inte garantera den fullständiga överföringen av essensen, så jag tar gärna emot kommentarer med ändringar, om det finns några.
Utveckling från synkron till asynkron konsensus
Noder väljs med hjälp av en deterministisk process (samma som används i DHT som bittorrent) som dynamiskt justerar nodernas ansvar för att "underlätta" validering eller, mer förståeligt, för att uppnå konsensus. Vi väljer grupper om 3 noder och kör konsensusrundor parallellt så att en nod kan vara en facilitator i flera block. Detta tillåter oss att behandla transaktioner asynkront, vilket i huvudsak betyder att vi har flera blockkedjor som bildas samtidigt. Processen är som ett spindelnät, bildad av många trådar, till skillnad från noder som bildar en enda kedja över tiden. Asynkron eller parallell bearbetning är grunden för skalbar programmering eftersom den tillåter användningen av alla datorresurser, vilket påskyndar den totala beräkningen. Detta nätverk kallas en riktad acyklisk graf eller DAG inom datavetenskap.
Kanalbredd för en linjär blockkedja kontra multiplikationseffekten av en DAG där vi har flera parallella blockkedjor.
Geometrisk implementering av linjär blockchain mot DAG. Svarta prickar är block, vita prickar är noder
Vi använder 3 noder i varje konsensusrunda eftersom det ger oss några intressanta matematiska processer för att resonera om tillståndet, som bildar ett "ytplan" över datan i form av sammankopplade trianglar. Protokollet använder sedan trianglarna för att sy ihop en optimal yta som inte innehåller några redundanta eller inkonsekventa data och som har minsta möjliga trianglar. Algoritmiskt är detta analogt med ett "minimisnitt" av en graf, och matematiskt är det analogt med en derivata eller optimeringsfunktion (från vilken funktionen hittar den kortaste vägen den kan korsa längs ytan). Denna kortaste väg motsvarar optimal lagring av data (transaktioner) i en DAG. Motstridiga triangulära ”plattor” så att evenemangets yta blir slät och fri från konflikter.
Geometrisk implementering av konfliktdetektering/hantering. Ett motstridigt block skapar ytterligare en yta. Vi tar bort ytterligare ytplattor för att bibehålla en plan (= konfliktfri) evenemangsyta.
Konsensus baserad på rykte
I ett optimalt decentraliserat p2p-ryktesystem bör varje nod självständigt kunna bestämma sitt förtroende för andra noder. Vårt system använder en speciell modell som inkluderar transitiva relationer, eller relationer som en nod har med andra noder, när man tilldelar en global poäng. "Du är bara så bra som ditt företag." Slutresultatet är en "skev" eller gradient baserat på transitivt förtroende eller rykte över alla noder i $DAG eller vanliga kanalen. Detta kan ses som en borste eller ostriv som raderar över ett "ytplan" och väljer vilka "triangulära plattor" som ska raderas och vilka som ska lämnas. Det är så konfliktlogik faktiskt tar bort "triangulära brickor".
En DAG med en motstridig platta som går genom ett "böjt" utrymme som är en gradient, som liknar ett rivjärn, och kommer att ta bort eller "radera" den motstridiga brickan.
Partiell/full nodskalning
I nätverksteorin är den optimala allokeringen vanligtvis känd som "skalfri", vilket kan beskrivas som ett hierarkiskt arrangemang med stora centrala noder som hanterar många mindre perifera noder. Denna distribution är synlig i naturen och framför allt på Internet. Constellation använder den här arkitekturen för att "skala ut" eller öka genomströmningen eller bredden på vår graf.
Effekten av hierarkisk uppdelning. Vi kan lägga till fler noder genom att öka bandbredden
Hylochain - Kanalbaserat applikationsstöd
Vår strategi för applikationsstöd kan ses som en "decentraliserad smart kontraktsplattform." Istället för ett centralt nätverk som kör all logik och bearbetar all data från applikationen, koordinerar Constellation applikationsdata med "huskanaler", vilket kan ses som en tv-station som sänder all data från hussystemet. Varje personalkanal kan implementera sin egen verifieringslogik för att lösa orakelproblemet genom end-to-end-autentisering av dataproducenter och transitiv verifiering av sammansatta personalsystem. Statliga kanalnätverk ger parallellt stöd för applikationer, vilket påskyndar adoptionstider som begränsas av traditionell synkron konsensus i ett smart kontraktsnätverk.
Två standardkanaler som är "kompatibla" via $DAG-nätverket. De kan interagera eller tolkas eftersom de båda är "integrerade" med $DAG genom att distribuera hybrid $DAG + Channel-noder.
Anledningen till att den heter Hylochain är för att vår strategi för applikationsstöd använde den funktionella programmeringsmodellen Recursion Schemes för att skapa MapReduce-gränssnittet. I synnerhet kan hylomorphism och metamorphism rekursionsscheman integreras för att skapa verifierbara frågor och strömanslutningar över inhemska kanaler genom att validera algebraiska datatyper på samma sätt som op-koder för smarta kontrakt verifieras. Slutresultatet är ett funktionellt MapReduce-gränssnitt som är bekant för dataingenjörer och kompatibelt med befintlig big data-teknik.
Hylomorphic och Metamorphic är standardkanaler för kontrast. I det metamorfa tillståndet skickas data från två vanliga kanaler till ett block i metakanalen. I Gilo tar vi det tidigare tillståndet för en kanal och använder det för att fråga (ställa en specifik fråga) två andra kanaler och lagrar sedan frågeresultatet i ett block.
Tokenomics och dess koppling till Hylochain
När en inbyggd kanal väl har skapats kan den integreras i $DAG-kanalen, men med hjälp av ACI eller Application Chain Interface. Detta gränssnitt är helt enkelt ett JSON-objekt med konfigurationsinformation och en publik nyckel som är associerad med själva kanalen. Anledningen till att vi associerar en publik nyckel med en vanlig kanal är att skapa en mäklarmekanism för den vanliga kanaldata. När den vanliga kanalen är utplacerad konfigurerar utvecklarna själva hur betalningar från $DAG-nätverket fördelas mellan noder och operatörer.
Flöde för att köpa tillgång till information eller ändring av information. Begäran skickas till $DAG, medel skickas till kanalkontot, resultatet skickas till köparen och transaktionskontrollsumman skickas till $DAG-nätverket, som sedan frigör pengar till den vanliga kanalen.
Källa: will.com