Evolution af Kadena, den første Real Private Blockchain | DK.democraziakmzero.org

Evolution af Kadena, den første Real Private Blockchain

Evolution af Kadena, den første Real Private Blockchain

George Samman er en blockchain og cryptocurrency konsulent og rådgiver, der for nylig medforfatter en skelsættende rapport om blockchain arkitektur med KPMG.

Her forklarer Samman hvordan konsensus algoritme opnås ved Raft blev endeligt fastsat af dens fjerne slægtning, Kadena. 

Denne artikel dækker Kadena s blockchain. Det bruger ScalableBFT at tilbyde højtydende (8.000-12.000 transaktioner per sekund) med fuld replikering og distribution på tidligere umulige skalaer (kapacitet til mere end 500 deltagende noder).

Dette, sammen med den flerlagede sikkerhedsmodel og trinvis hashing give mulighed for en virkelig robust blockchain. Baseret på Raft og Juno, Kadena integrerer en fuld smarte kontrakt sprog (pagten) i sin blockchain der kan køres som enten offentlig (almindelig tekst) eller private (dobbelt-skralde krypterede) transaktioner.

Det er et stort skridt fremad i blockchain rum, muligvis repræsenterer en ny generation af blockchain teknologi helt ved introduktionen af ​​ideen om "pervasive determinisme".

Svarende til Bitcoin, er Kadena s blockchain tæt integreret, og forstå, hvad det er i stand til, og hvad disse funktioner indebærer, kræver dækker en betydelig mængde jord. Som sådan har jeg brudt artiklen i tre dele: 1) Introduktion & Raft, 2) Kadena forgængere - Tangaroa & Juno, og 3) Kadena s Blockchain - ScalableBFT, pagten og Pervasive Determinisme.

Del 1: Introduktion og Raft Consensus algoritme

Historien bag Kadena er et interessant studie i det nye område blockchain konsensus algoritmer og distribueret databehandling.

Kadena er en 'fjern slægtning' af Raft konsensus algoritme. The Raft konsensus mekanisme blev efterfulgt af Tangaroa (en byzantinsk Fault Tolerant (BFT) Raft) og JP Morgan projektet Juno (en gaffel af Tangaroa), hvoraf ingen er længere under aktiv udvikling.

JP Morgans nye blockchain Quorumis meget forskellig fra Juno og bruger en fusion af ideer fra sidekæder og ethereum - offentlige smarte kontrakter er tilladt på blockchain foruden private kontrakter, der er repræsenteret som krypterede hashes og replikerede via side-kanaler.

Kadena er den "næste generation Juno". Det bruger en ny, men relateret, protokol kaldet ScalableBFT der blev udklækkede fra open source-kode i Juno-projektet og blev bygget af de to centrale udviklere, der byggede Juno. Før dykning dybt ind Kadena, en kort historie og beskrivelse af Raft og forgængere til Kadena skal diskuteres.

Raft konsensus

Den Raft konsensus algoritme er en enkelt leder-baseret system til styring af et replikeret log. Det bruger en replikeret tilstand maskine arkitektur og giver et resultat svarende til Paxos, men er strukturelt forskellig.

At holde replikeres log konsekvent er en opgave for den konsensus algoritme. I denne model, lederen gør det meste af arbejdet, fordi det udsender alle log opdateringer, validering transaktioner, og generelt styre klyngen. Raft konsensus garanterer en streng bestilling og replikering af meddelelser. Det er ligeglad, hvad meddelelserne indeholder.

En ny leder vælges ved hjælp af randomiserede timeouts, som er udløst, hvis en medløber ikke får meddelelse fra lederen før timeout brande. Disse kaldes "hjerteslag".

Hvis tilhænger modtager ingen kommunikation over denne periode, bliver det en kandidat, og indleder et valg. En kandidat, der modtager stemmer fra et flertal af den fulde klynge (noder i netværket) bliver den nye leder. Ledere typisk opererer indtil de ikke. De hjerteslag bliver sendt ud for at sikre lederen er der stadig; hvis der ikke er modtaget et nyt valg finder sted.

De følgende trin er, hvordan Raft kommer til konsensus:

  1. En klynge af Raft node servere startes med hver node lancering som en "follower". Til sidst vil en knude timeout, bliver en kandidat, vinde et flertal af stemmerne og blive leder.
  2. Hver knude gemmer en log, der indeholder kommandoer. Det er lederens opgave at acceptere nye kommandoer, strengt bestille kommandoerne i sin log, kopiere sin log til sine tilhængere, og til sidst informere tilhængere når at begå logfiler, som de har replikeret. Konsensus algoritme sikrer således, at hver serverens logfiler er den samme rækkefølge.
  3. Logs "forpligtet", når de er blevet kopieret til et flertal af noder. Lederen samler replikation tæller, og efter et flertal at blive set, forpligter sine egne nye logposter og informerer sine tilhængere til at gøre det samme.
  4. Ved "forpligte" kommandoen i hvert loggen evalueres af en stat maskiner. Fordi Raft er ligegyldig til kroppen af ​​kommandoen, kan enhver tilstandsmaskinen behandle engagerede firmaer. Desuden konsensus sikrer, at kommandoeksekveringen altid sker i samme rækkefølge som de kommandoer kommer fra Log der er strengt bestilt.
  5. Statslige maskiner vil være konsekvent, så længe kommando henrettelser er deterministisk.
  6. Når en klient sender en kommando til en af ​​serverne, vil den pågældende server enten sende kommandoen til lederen eller er leder. Lederen indsamler den nye kommando, tildeler det et Log Index, indkapsler det i loggen, og tilføjer kommandoen til det uudnyttede del af sin log.
  7. Når lederen har uudnyttede poster, den gentager denne del af logbogen til sine tilhængere. Når leder informeres om vellykket replikation af et flertal af klyngen, det forpligter de nye poster og beordrer sine tilhængere til at gøre det samme.
  8. Hver gang en ny logregistrering er er nået engageret konsensus om denne post. Det er derefter vurderes af staten maskine på hver server.
  9. Fra dette punkt, Raft er færdigt og udførende kan beslutte, hvordan man håndterer reaktioner; besvarelse til kunden eller venter for kunden at forespørge for resultatet.

Svar til klienten er generelt asynkron.

Den Raft konsensus-protokollen er netop det - en konsensus-algoritme. Det har ikke en forestilling om og er, som standard, helt åben for enhver klient udstede kommandoer. Det eneste deltagelse restriktion det gør er, hvad noder findes på et givet tidspunkt.

Desuden leder har absolut myndighed over klynge og beordrer tilhængere til at replikere og begå. Det betyder ikke antage byzantinske angreb, er det nødvendigt at kun håndtere nedbrud fejl, fordi knuderne antages altruistisk.

Del 2: Kadena forgængere - Tangaroa og Juno

Tangaroa: Det første skridt i retning af en BFT Raft

Tangaroa er byzantinske Fault Tolerant (BFT) variant af Raft konsensus algoritme inspireret af den oprindelige Raft algoritme og den praktiske byzantinske fejltolerance (PBFT) algoritme.

Byzantinske fejltolerance refererer til en klasse forårsaget af ondsindede knuder angriber netværket. Hvis nogle af de knuder gå ned er det bydende nødvendigt for netværket at fortsætte med at køre uden at stoppe.

I standard Raft, du har brug for at kopiere en log indgang til et flertal af knuder i klyngen før begå det. For BFT konsensus algoritmer, herunder Tangaroa, den krævede klyngestørrelse er mindst 2f + 1, hvor f er antallet af fejl, du vil tolerere (herunder både nedstyrtede knudepunkter og kompromitterede noder). Konsensus opnås ved en flertalsafgørelse af klyngen; hvis f <= 3 og derefter klyngestørrelse = 7 og ikke-byzantinske knudepunkter = 4. Nogle BFT protokoller kan endda kræve 3f + 1.

En byzantinsk Leader kan beslutte at vilkårligt øge begå indekset for andre knuder før logposter er blevet tilstrækkeligt gentaget, hvilket førte til sikkerhed krænkelser, når noder mislykkes senere. Tangaroa forskyder begå ansvaret væk fra lederen, og hver node kan kontrollere sig selv, at en log post er blevet sikkert replikeret til en beslutningsdygtig knudepunkter, og at denne er beslutningsdygtig enig om en bestilling.

Tangaroa tillader klienter, der afbryder den nuværende ledelse, hvis det ikke lykkes at gøre fremskridt, på samme måde som andre BFT Consensus algoritmer gør det muligt at klienten til at opføre sig som en betroet orakel at afsætte visse noder. Dette gør det muligt for Tangaroa at forhindre byzantinske ledere fra sultende systemet, men er meget tillidsfuld af klienten.

Leader valg og stadier

Tangaroa bruger Raft som grundlag for konsensus; derfor er der en enkelt leder. I Tangaroa, som i Raft, hver node er i en af ​​de tre stater: leder, tilhænger, eller kandidat.

Svarende til Raft, hver node starter som en tilhænger, hvoraf den ene i sidste ende vil timeout og udskrive valg. Vinderen af ​​valget tjener som leder for resten af ​​perioden; vilkår slutter, når en ny leder vælges. Nogle gange vil et valg resultere i en delt afstemning, og udtrykket vil ende med ingen leder. I dette tilfælde vil en medløber igen timeout (timeout nulstilles, når en afstemning er støbt eller et valg kaldes det) og starte afstemningen processen igen.

Til at begynde et valg, en medløber intervaller sin nuværende valgperiode og sender RequestVote (RV) Remote Procedure Call (RPC'er) parallelt til hver af de andre knuder i klyngen beder om deres stemme. RPCS Tangaroa anvendelser ligner Raft s RPC'er med den undtagelse, at hver RPC er underskrevet og valideret via PPK signaturer.

RPCer mulighed for en udveksling af data mellem forskellige computere bopæl på et netværk og underskrifterne tillader modtagelse af knudepunkter for at kontrollere, hvilke node sendt RPC ud over at lade enhver node at sende enhver anden knude s RPC til enhver tid.

Når en Tangaroa knude modtager en RV RPC med en gyldig signatur, det giver en stemme straks, hvis det ikke i øjeblikket har en leder (kun optræder ved start). Ellers begynder den proces, som Tangaroa kalder en "LazyVote."

Formålet med en LazyVote er at beskytte ikke-byzantinske Abonnenter fra valg af en ny leder, når lederen er ikke defekt; uden dovne stemme kunne en byzantinske knudepunkt udløse gentagne valg til enhver tid og sulte systemet. Når en ny RV modtages af en tilhænger, det sparer RV og venter på alle følgende betingelser være opfyldt:

A) follower valget timeout udløser brande, før det håndterer et hjerteslag fra dets nuværende leder. Hvis et hjerteslag modtages, bliver LazyVote ryddet.

B) RV nye udtryk er større end den nuværende valgperiode.

C) Anmodningen afsenderen er en støtteberettiget kandidat (gyldigt PPK signatur og kunden har ikke forbudt noden).

D) knude modtager RV har ikke stemt for en anden leder for den foreslåede sigt.

E) Kandidaten deler en log præfiks med den knude, der indeholder alle engagerede poster. En knude altid afviser anmodningen, hvis den stadig modtager hjerteslag beskeder fra den nuværende leder, og det ignorerer RequestVote RPC, hvis den foreslåede gyldighedsperiode allerede er begyndt.

Hvis en RequestVote er gyldig, og for en ny periode, og kandidaten har en tilstrækkelig up-to-date loggen, men modtageren er stadig modtager hjerteslag fra den nuværende leder, vil det optage sin stemme lokalt, og derefter sende en stemme respons, hvis noden selv gennemgår et valg timeout eller hører fra en klient, at den nuværende leder er afvisende.

Under doven stemme, er en knude ikke give en stemme til en kandidat, medmindre den mener den nuværende leder er defekt. Dette forhindrer knuder, der starter unødvendige valg i at få de nødvendige stemmer til at blive leder og sulte systemet.

Nodes vente, indtil de tror et valg skal finde sted før nogensinde kaster en afstemning. Når en afstemning er sendt, vil knuden opdatere sin sigt nummer. Det behøver ikke antage, at den knude det stemte for vandt valget dog, og det vil stadig afvise AppendEntries (AE) RPC'er fra kandidaten, hvis ingen af ​​dem indeholder et sæt af stemmer, der beviser, kandidat vandt valget. AE s tjener det dobbelte formål at hjerteslag og bærere af nye logposter der har brug for replikation. Kandidaten fortsætter i kandidatland, indtil en af ​​de tre ting sker:

A) Det vinder valget ved udlevering af en flertalsafgørelse fra klyngen. En kandidat skal redde disse stemmer - RequestVoteResponse (RVR) RPCer - til fremtidig fordeling.

B) En anden knude etablerer sig som en leder

C) En periode med tiden går uden vinder (ie: det oplever en anden valg timeout)

En kandidat, der vinder valget så fremmer sig selv til lederen tilstand og sender en AE hjerteslag meddelelser, der indeholder de stemmer, der valgte den, og den opdaterede sigt for at etablere sin autoritet og forhindre nye valg. De underskrevne stemmer effektivt forhindrer en byzantinsk node fra vilkårligt fremme sig selv som leder af en højere sigt. Desuden hver tilhænger udfører en optælling på den førnævnte flertal, validering og tælle hver stemme den nye leder transmitteret til selvstændigt verificere gyldigheden af ​​valget.

Governance

Ligesom Raft, Tangaroa bruger randomiserede timeouts til at udløse valg leder. Lederen af ​​hver valgperiode sender periodisk hjerteslag beskeder (tom AE RPC'er) at bevare sin autoritet. Hvis en tilhænger modtager nogen meddelelse fra en leder i en tilfældigt valgt tidsperiode, valget timeout, så bliver det en kandidat og indleder et nyt valg.

Ud over de spontane follower-udløst valg, Tangaroa giver også klient indgreb: når en klient bemærker ingen fremskridt med en leder for en periode kaldes fremskridt timeout, udsender UpdateLeader RPCs til alle knuder, som fortæller dem at ignorere fremtidige hjerteslag fra hvad kunden mener at være den nuværende leder i den nuværende valgperiode. Disse tilhængere vil ignorere hjerteslag meddelelser i den nuværende periode og tid ud som om den nuværende leder havde undladt startede en ny valg.

Data modtaget

Dataene (nye kommandoer) kommer fra kunder i Raft klynge, der sender anmodninger til lederen. Lederen kopierer disse anmodninger til klyngen, og reagerer på klienten, når beslutningsdygtig nås i klyngen på denne anmodning.

Hvad der udgør en "anmodning" er systemet afhængig. Hvordan data er gemt er system-afhængigt. Det er vigtigt for staten til at vare ved til disk, så knuder kan komme sig og huske oplysninger, som de har forpligtet sig til (som noder de stemte for, hvad log poster de har begået, osv). Uden dette, vil protokollen ikke.

Tangaroa tilføjer BFT at Raft evolution

Juno

JP Morgan-projektet Juno er gaffel af Tangoroa og var en proof of concept, der var i stand til at skalere Tangaroa at omfatte op til 50 noder og hæve transaktion hastighed op til 5.000 transaktioner i sekundet.

Den JPM Holdet bag Juno så potentialet, at en Tangaroa-lignende tilgang repræsenteret - en højtydende privat blockchain. De gentog på ideen i et år og åben fremskaffede projektet i februar 2016. De tilføjede en smart kontrakt sprog, fast nogle design fejl, og det lykkedes at opnå en 10x højere ydeevne, som gav mulighed for at antallet af knuder til at stemme for at skifte, mens systemet kørte. Juno tilladt for at tilføje og fjerne knudepunkter, og var en permissioned distribueret system, hvor alle knudepunkterne i netværket var kendt.

Etaperne i mekanismen og lederen valgprocessen er de samme som Tangaroa (se ovenfor). Tilsvarende er en transaktion anses for levende, når det er fuldt kopieret og engageret i loggen.

Lederen afgør rækkefølgen af ​​kommandoer og hver node validerer. Hvert knudepunkt uafhængigt beslutter, hvornår at begå loggen baseret på dokumentation, den modtager fra andre knudepunkter. Hver post i logfilen er individuelt engageret og trinvist hashet mod tidligere post. Det tager ca. 5 ms for en enkelt logregistrering at gå fra leder modtager posten til fuld enighed er nået og netværk latenstid.

Del 3: Kadena s Blockchain - ScalableBFT, pagten, og Pervasive Determinisme

Kryptografi

Forskellige til Raft, hver replika i et BFT Raft-system (en familie af algoritmer, der omfatter Tangaroa, Juno, og Kadean s ScalableBFT) beregner en kryptografisk hash hver gang det vedhæfter en ny post til sin log. Hash er beregnet over den tidligere hash og den nyligt tilføjet loggen.

En knude kan tilmelde sin sidste hash til at bevise, at det har gentaget helhed af en log, og andre servere kan bekræfte dette hurtigt ved hjælp af signaturen og hash. BFT Raft noder og kunder altid underskrive, før du sender beskeder og afvise beskeder, der ikke indeholder en gyldig signatur.

BFT Rafts bruger Incremental Hashing gør knuder at være sikker på, at både selve indholdet og bestilling af andre node logfiler matche deres egen. Ved hjælp af denne viden, kan knuder uafhængigt begå logposter sikkert fordi både selve indholdet og bestilling af andre node logfiler attesteret via matchende trinvise hashes.

BFT Rafts bruger digitale signaturer i udstrakt grad at autentificere meddelelser og verificere deres integritet. Dette forhindrer en byzantinsk leder i at ændre meddelelsens indhold eller smedning meddelelser og beskytter klyngen generelt fra et stort antal byzantinske angreb.

Konsensus

I Raft, er en leder valgt via randomiserede timeouts, der udløser en follower at foreslå sig selv som kandidat og anmode stemmer. ScalableBFT også gør dette, men i en kryptografisk sikret måde. For eksempel, hvis en leder bliver uopnåelig, ville en timeout udløse nyvalg men valgprocessen er robust over for byzantinske noder erklære valget. ScalableBFT løser de problemer, Juno og Tangaroa stødt hensyn doven stemme.

Lederens eneste unikke egenskaber er: 1) bestilling af nye transaktioner forud for replikation og 2) replikerer nye transaktioner til Follower noder. Fra det tidspunkt, alle knuder uafhængigt bevise både konsensus gyldighed og individuel transaktion integritet.

Fjernelsen af ​​anonym deltagelse er et design krav til private blockchains, og dette gav mulighed for en højtydende BFT konsensus mekanisme til at erstatte minedrift. ScalableBFT primære tilføjelse til familien af ​​BFT Rafts er evnen til at skalere ind i 1000-vis af knuder uden at reducere systemets gennemløb.

Hver transaktion replikeres til hver node. Når et flertal af knudepunkter har kopieret transaktionen, er transaktionen begået. Nodes indsamle og distribueret information (inkremental hash) om, hvad de har kopieret og bruge disse oplysninger til selvstændigt beslutte, hvornår de skal begå (> 50% af andre knuder sende dem trinvise hashes for uforpligtede transaktioner, som de er enige med).

Det virker dybest set ved at gøre en flertalsafgørelse på hvad at begå. At begå en transaktion betyder ikke, det vil blive henrettet, blot at det er blevet permanent kopieret af et flertal af klyngen. Dårlige transaktioner, dem, der fejl eller har dårlige signaturer, replikeres samt konsensus opgave er at give perfekt bestilt replikation.

Begå en transaktion tillader hvert knudepunkt for derefter selv bedømme (parse / dekryptere / validere krypto / udføre / etc.) Hver transaktion på en identisk måde. Hver transaktion bliver parret med en udgang, kan dette variere fra "dårlige krypto" til udgangen af ​​smart kontrakt lag (som også kan være en fejl).

Endelig, foruden lederen replikere nye transaktioner til hver node knuderne er mere eller mindre uafhængig. I stedet for "synkronisering" de sender "Jeg har gentaget op til at logge indeks N og det har en trinvis hash af H" til klyngen og indsamle disse oplysninger fra andre knuder - baseret på resultaterne fra andre noder hver node kan selvstændigt besluttet, hvis klynge har gentaget forbi baren er nødvendig for at begå (et flertal replikering for nogle som i endnu uudnyttede log indeks N).

Her er den subtile del: den trinvise hash indebærer replikation af alt, hvad der kom før det. Hvis lederen replikater 8.000 nye transaktioner (hvilket er, hvad det gør i dag), behøver hver node kun distribuere og indsamle beviser for den sidste transaktion af dette parti, da det indebærer en korrekt replikation af dem, der kom før det. I stedet for at sende 8.000 beskeder (en for hver transaktion), der vidner om ordentlige replikering knuder kun diskutere den seneste transaktion.

Dette er grunden til Kadena behov så meget pipelining, fordi holdet regnet ud, hvordan at begå 8.000 transaktioner med samme hastighed som at begå en enkelt transaktion.

ScalableBFT repræsenterer et gennembrud i området BFT konsensus da det er den første og eneste deterministisk BFT konsensus mekanisme, der kan skalere sidste hundrede knudepunkter med fuld replikation og kryptering. ScalableBFT giver også en unik sikkerhedsmodel kendt som pervasive determinisme, der giver sikkerhed ikke bare på transaktionen niveau, men på den konsensus niveau samt mens kryptere hver eneste transaktion ved hjælp af Noise-protokollen (se nedenfor).

Kadena bruger deterministisk konsensus

Konsensus mekanisme er deterministisk hvis konsensusprocessen er fuldt specificeret i protokollen, og denne proces anvender ikke tilfældighed. Som anført ovenfor, Raft, for eksempel, bruger randomiserede timeouts til at udløse valg, når en leder går ned (da lederen ikke kan kommunikere "Jeg er ved at gå ned", er der en timeout, der ture til at bede en node at kontrollere, om lederen er nede), men valget er ikke en del af konsensus på transaktionen niveau, er det i stedet et middel til at finde en node at orkestrere konsensus.

ScalableBFT er deterministisk og forhærdet sådan, at:

  1. Knudepunkter vil forpligte kun, når et flertal af klyngen er enig med dem
  2. Beviserne aftale skal være fuldt kontrollerbar til enhver tid
  3. Når der mangler beviser for aftale, ikke gøre noget.

Kadena er specielt designet til permissioned netværk, og som sådan det forudsætter, at visse angreb (ligesom en DoS) er usandsynlig og er ude af deres kontrol. Hvis man skulle ske, ville systemet enten lås (alle knuder timeout til sidst med, men et valg ville aldrig lykkes) eller sidde inaktiv.

Når en sådan begivenhed slutter, vil de knuder komme tilbage i konsensus og tingene vil vende tilbage til normal. Men i en permissioned netværk, ville administratorer har fuld kontrol og dræbe forbindelsen årsag til problemet.

Leader Valg

Leader valget er meget lig Raft i, at enhver knude kan blive valgt leder, hver node får en stemme pr sigt, og valg kaldes, når det randomiserede timeout en af ​​de knuder brande (timeren nulstilles, hver gang en knude hører fra lederen ).

Den største forskel er, at en knude, der får nok stemmer i Raft antager ledelse, hvorimod en knude, der får et flertal af stemmerne i ScalableBFT distribuerer disse stemmer til hver anden node for at demonstrere (i en BFT måde), at det er blevet valgt som leder af klyngen.

ScalableBFT mekanisme løser problemer set i Juno og Tangaroa, som en "løbsk kandidat", hvor en ikke-byzantinsk knude er udløbet på grund af et netværk partition, men, fordi dens udtryk er blevet forøget, kan det ikke komme tilbage ind i konsensus og i stedet fortsætter timeout intervaller derefter sin sigt ( "Runaway".)

Raft konsensus garanterer en streng bestilling og replikation af meddelelser; det er ligegyldigt, hvad der er i hver meddelelse og kan variere fra tilfældige tal til kodeteksten til almindelig tekst smarte kontrakter. Kadena udnytter loggen lag som en beskedtjeneste, når du kører i en krypteret sammenhæng; meget gerne Signal kan køre Støj protokol kryptering løbet SMS. ScalableBFT kører Støj over en blockchain.

ScalableBFT tilføjer konsensus robusthed, hvor laget, der beskæftiger sig med tolkning meddelelserne antager som en garanti, men også trinvise hashes der sikrer perfekt replikation af meddelelser. Støj slots mellem konsensus og smart udførelse kontrakt, kryptering / dekryptering af meddelelser efter behov protokol; fordi beskederne er kodeteksten kun nogle af de normale tricks til at undgå Kartesianer blowup af levende tests er nødvendige for at køre pr besked uden at lække oplysninger.

Sikkerhed model / pervasive determinisme

Kadena anvender begrebet "pervasive determinisme" til at beskrive "ideen om en blockchain der bruger PPK-Sig baseret kryptografi for forfatterskab garantier (ligesom bitcoin) og består af et fuldt deterministisk konsensus lag foruden en Turing-ufuldstændige, single-opgave Smart kontrakt lag.

Konsekvenserne af en 'gennemgribende deterministisk' blockchain er temmelig dyb, da det giver mulighed for en bitcoin-hovedbog klasse af revisionsmulighed udvides dybt ind i konsensus lag ved kædning sammen flere lag af kryptografisk tillid.

Tag som eksempel en transaktion, der indlæser et nyt smart-kontrakt modul kaldet "lån". Sig "lån" import andet modul kaldet "betalinger", der allerede er til stede i kæden. Den vellykkede import af "betalinger" indebærer alene følgende (med hver er fuldt kontrollerbar ved kryptografiske midler):

  • Hvem underskrev den transaktion, der er lagt "betalinger"
  • Hvad konsensus knuder var i klyngen på tidspunktet for lastning
  • Hvad konsensus noder enige om, at transaktionen var gyldig
  • Hvad knuder stemte for den nuværende leder på tidspunktet for lastning
  • Hvem leder var
  • Hvem den tidligere leder var
  • Etc.

En gennemgribende deterministisk system gør det muligt nye transaktioner til at udnytte ikke blot den kryptografiske tillid, som naturligt forekommer som transaktioner er lænket sammen i en blockchain, men også tillid hvordan disse transaktioner, afsats i første omgang. Dermed kan du skabe et system mere sikkert end Bitcoin fordi konsensus proces bliver så kryptografisk tillid, kontrollerbar, og viklet ind så godt, med transaktionen niveau henrettelser indebærer, at specifikke konsensus niveau begivenheder fandt sted, og med hver underforstået at være kryptografisk kontrollerbare.

Dette giver BFT ikke kun for konsensus lag, men for transaktionen lag (Bitcoin allerede gør dette) samt. Dette adskiller sig fra, siger, PBFT som forudsætter, at transaktioner, der sendes fra kundens server er gyldige som efterlader dem med en evne til at være kompromitteret. Desuden ikke-Raft BFTs generelt overlade klienten med evnen til at afsætte / ban knudepunkter. Pervasive Determinisme tager et alternativt synspunkt: trust ingenting, revision alting.

At tillade ScalableBFT at indarbejde omsiggribende determinisme skaber et helt paranoid system, som er robust ved hver eneste lag via permanent sikkerhed (dvs. Når en form for kryptografiske sikkerhed, der kan gemmes til disk). Det har Bitcoin sikkerhedsmodel til transaktioner, udvider denne model til den konsensus niveau, og tilføjer smarte kontrakter uden behov for minedrift eller de afvejninger, som de fleste i branchen har vænnet sig til. Det er en rigtig blockchain der er hurtigt og skalerbar.

Jeg spurgte Will Martino (medstifter af Kadena) for detaljerne i, hvordan dette arbejdede for hvert lag:

Hvad er dit konsensus-niveau sikkerhed model?

Til replikation, Kadena anvender en trinvis hashed log over transaktioner, der er identisk replikeres ved hvert knudepunkt. Disse er enige om indholdet af loggen via de distribuerede signerede meddelelser, der indeholder den trinvise hash af en given log indeks, som derefter indsamlet af andre knuder og bruges til individuelt ræsonnere over, når en begå er berettiget. Ingen dubletter er tilladt i loggen og replikation meddelelser fra lederen, der indeholder dubletter straks afvist.

Vi bruger blake2 hashes og Term nummer for at definere entydighed, så kunderne i systemet ikke bekymre dig om at sende kopier ved et uheld eller om en ondsindet knude / man-in-the-middle (MITM) fremlægger på ny kommandoer. Vi ansætter permanent sikkerhed, en PPK-SIG tilgang til forfatterskab verifikation (eller en hvilken som helst form for tilgang, der kan gemmes til disk), der er meget lig hvordan Bitcoin kontrollerer transaktioner, men på den konsensus-niveau (i tillæg til den transaktion niveau).

Dette står i modsætning til flygtig sikkerhed som bruger sikrede kanaler (TLS) til forfatterskab validering - en langt ringere tilgang, hvor spørgsmålet "der har sendt transaktionen X?" besvares ikke via PPK kryptografi men via en konsensus-niveau forespørgsel fordi enhver individuel knudepunkt er i stand til at tilvejebringe en BFT svar.

Hvad er din transaktion-niveau sikkerhed model?

De ideer flygtig og permanent sikkerhed spændvidde både konsensus og transaktionen niveau, da det er enighed om, at hænder smart kontrakt udførelse lag enkelte transaktioner. På den smarte kontrakt / transaktion niveau, vi bruger også permanent sikkerhed samt, støtte rækken niveau offentlige nøgle tilladelse indbygget i pagten.

Dette er vigtigt, fordi flygtig indebærer, at en angriber er én server væk fra udgive en enhed; sikrede kanaler arbejde ved punkt til punkt distribution af nye transaktioner af kunden / indsenderen til klyngenoder over TLS og konsensus sikrer, at en given transaktion skal være engageret og replikeres. Men hvis en hacker fine kombination da klienten serveren holder den anden ende af TLS-forbindelse, kan de handle, som om de var kunden uden klyngen bliver klogere.

Permanent sikkerhed, på den anden side, har mange nøgler til de enkelte roller i en given enhed således kræver en hacker at få adgang til de enkelte taster; yderligere, med permanent sikkerhed for CEO transaktioner er signeret med en anden nøgle end den Mail Clerk transaktioner vs flygtig hvor "som sender denne transaktion" er bestemt af en "fra: X" feltet.

Hvis der anvendes samme TLS-forbindelse til at indsende både administrerende direktører og Clerk transaktioner, så forfatterskab og godkendelse logik er en "fordi jeg siger det / tro mig" model vs en PPK-SIG tilgang, hvor du verificere mod den relevante tast før udførelse. Kadena s blockchain er designet til at have tillid til så lidt som muligt; hvis vi vidste af en mere paranoid eller finkornet tilgang end række-niveau PPK signaturer vi ville bruge det i stedet.

Hvad er dine fortrolige model transaktion?

Vi bruger dobbelt-Ratchet-protokollen (hvad Signal, WhatsApp, etc. Bruger til krypteret kommunikation) indlejret i de blockchain (krypterede transaktionsomkostninger organer) til multi-party privatliv bevare use cases. Vi arbejder med begrebet adskilte databaser via den 'pagt' primitiv i pagt - de beskriver en multifase begå arbejdsgang i disjunkte databaser via krypterede meddelelser.

Smart kontrakter

Pagten er en fuld smart kontrakt sprog, tolken som er bygget i Haskell. I Kadena, hver transaktion er en smart kontrakt og pagten smarte kontrakt sprog er åbent købes. Pagten er database-fokuserede, forretningsmæssig, Turing-ufuldstændige, single-opgave (variabler kan ikke ændres i deres levetid), og dermed særdeles modtagelig for statisk verifikation.

Pagten er også tolkes - den kode, du skriver er, hvad der udfører on-kæde - hvorimod Soliditet er kompileret, hvilket gør det vanskeligt at verificere koden, og også umuligt at rette op på sikkerhedsproblemer i gamle sprogversioner, når kompileret. Pagten skibe med sin egen tolk, men kan køre i nogen deterministisk-input blockchain, og kan understøtte forskellige backends, herunder kommerciel RDBMS. I ScalableBFT blockchain, det kører med en hurtig SQLite oplagringslag.

Karakteristik af Kadena Blockchain

Den Kadena blockchain indeholder alle disse funktioner:

Afslutningsvis har Kadena udviklet en fuldt replikerende, skalerbar og deterministisk konsensus algoritme for private blockchains med høj ydeevne. Denne blockchain løsning kan være et kæmpe spring fremad for finansielle virksomheder, der ønsker at ansætte en reel privat løsning, der forbliver tro mod mange af nøglen Bitcoin blockchain funktioner uden minedrift (bevis for arbejde), anonymitet og censur modstand mens catering til de vigtigste designelementer at finansielle tjenesteydelser hungrer især skalerbarhed og fortrolighed.

Denne artikel er tidligere offentliggjort på Sammantics blogand er blevet gengivet her med tilladelse. Nogle redigeringer er blevet gjort for stil og kortfattethed.

Privat BlockchainsKadena

Relaterade nyheter


Post Blockchain

New Chicago Blockchain Center lancerer med statsstøtte

Post Blockchain

Libertarian Party of Texas til at gemme valgresultater på tre blokker

Post Blockchain

Hvad Blockchain betyder for økonomisk velstand

Post Blockchain

En Pitch Perfekt Illustration af Blockchain Hype

Post Blockchain

Blockchain i 2017: Ved vi hvad vi ikke ved?

Post Blockchain

Blockai lancerer Netscape til Bitcoin med Blockchain Browser

Post Blockchain

MultiChain 1.0: Bitcoin-kompatibel Privat Blockchain åbner for Enterprise

Post Blockchain

Deloitte: Nye Blockchain applikationer vil accelerere vedtagelsen

Post Blockchain

Blockchain.info: Verdens mest populære Bitcoin hjemmeside og tegnebog

Post Blockchain

Blockstream: $ 21 millioner finansiering vil drive Bitcoin Development

Post Blockchain

27 Finansielle Virksomheder Form Korean Blockchain Consortium

Post Blockchain

Bitcoin går ind i alderen af praksis