Hva er Tendermint Core? Den mest omfattende guiden noensinne

Hva er Tendermint Core? …

Lesetid: 17 minutter

Cosmos er et av de mest lovende prosjektene der ute. Med folk som Jae Kwon og Ethan Buchman i laget deres, har det mye potensiale. I hjertet og sjelen ligger Tendermint Core.

Ultimate Guide to Tendermint

Tendermint Core kombinerer Tendermint konsensusalgoritmen sammen med en p2p sladderprotokoll. Så når du legger alt sammen i programvarestakken, får du Tendermint Core sammen med Cosmos-SDK-applikasjonslaget.

Uansett, så før vi går videre, la oss se på hvorfor Tendermint er en slik nødvendighet.

Bitcoin og Blockchain

Da Satoshi Nakamoto opprettet Bitcoin, laget han det aller første desentraliserte kryptografiske systemet. Den virkelig bemerkelsesverdige delen av denne oppdagelsen var at han var i stand til å løse den bysantinske generalens problem som hjalp et WAN-nettverk (WAN) til å komme til enighet i et tillitsfullt miljø. Bitcoin brukte bevis på arbeidsalgoritme for å ivareta konsensus.

Når det er sagt, kan Bitcoins viktigste bidrag veldig godt være det faktum at det introduserte hele verden for blockchain-teknologien.

En blockchain er, i de enkleste ordene, en tidsstemplet serie med uforanderlig registrering av data som administreres av en klynge datamaskiner som ikke eies av en enkelt enhet. Hver av disse datablokkene (dvs. blokken) er sikret og bundet til hverandre ved hjelp av kryptografiske prinsipper (dvs. kjede).

Med andre ord er en blockchain en deterministisk tilstand maskin replikert på noder som ikke nødvendigvis stoler på hverandre.

Med deterministisk mener vi at hvis de samme spesifikke trinnene blir tatt, vil det alltid føre til det samme resultatet.

F.eks. 1 + 2 vil alltid være 3.

Så, hva betyr staten? La oss se på det med Bitcoin og Ethereum.

I Bitcoin er staten en liste over saldoer for hver konto, som er en liste over Unspent Transaction Output (UTXO). Denne tilstanden blir modifisert via transaksjoner som endrer balansen.

På den annen side, i Ethereum, er applikasjonen en virtuell maskin som kjører smarte kontrakter. Hver transaksjon går gjennom Ethereum Virtual Machine og endrer tilstanden i henhold til den spesifikke smarte kontrakten som kalles i den.

Hvis du ser på arkitekturen til blockchain-teknologien, vil du ha tre spesifikke lag:

  • Nettverk: Formering av transaksjonen / informasjonen gjennom nodene
  • Konsensus: Tillater nodene å komme til en beslutning som er gitt >2/3 av nodene er ikke skadelige
  • Applikasjon: Ansvarlig for oppdatering av staten gitt et sett med transaksjoner, dvs. behandling av transaksjoner. Gitt en transaksjon og en stat, vil søknaden returnere en ny stat.

For visuelle signaler:

Ultimate Guide to Tendermint

Problemer med den nåværende Blockchain-arkitekturen

Det viser seg at det er veldig hardt å bygge en blockchain fra grunnen av med alle disse 3 lagene. Så mange prosjekter foretrakk å bygge videre ved å forkaste Bitcoin-kodebasen. Nå, mens dette sparer mye tid, er faktum at de fortsatt er håndjern av begrensningene i Bitcoin-protokollen. Åpenbart kan du ikke utføre komplekse prosjekter når du bruker en protokoll som er kjent for sine gjennomstrømningsproblemer.

Ting ble mye bedre da Ethereum kom til spill. Ethereum ga faktisk utviklere en plattform som de kunne bruke til å lage sin egen tilpassede kode aka smarte kontrakter og prosjekter. Imidlertid, som med Bitcoin, lider også Ethereum av det samme problemet. De har begge monolitisk arkitektur i motsetning til modulær.

Monolitisk arkitektur vs modulær arkitektur

Monolitisk arkitektur betyr at alt er sammensatt i ett stykke. Når programvare betraktes som “monolitisk”, er komponentene koblet sammen og avhengige av hverandre, og designet er mer selvstendig. I dette tilfellet er arkitekturen tettere koblet, og de tilknyttede komponentene må være tilstede for at koden skal kunne kjøres eller kompileres.

Selv om dette gjør systemet det ble opprettet for mer robust, kan du ikke virkelig komme fra det og opprette egendefinerte koder. Det er ikke det mest fleksible systemet. I tillegg er det et annet problem med dette systemet. Hvis noen av komponentene i programmet må oppdateres, må hele søknaden omarbeides. Dette er vel ikke den mest ideelle situasjonen nå?

På den annen side har vi modulær arkitektur. I motsetning til monolitisk er lagene ikke det som er knyttet til hverandre. Så selv om det kanskje ikke er like robust, er det ganske enkelt å oppdatere hele applikasjonen ved å jobbe med de forskjellige separate modulene.

Siden modulene er så uavhengige, lar modulær arkitektur deg faktisk oppdatere en bestemt del uten å forårsake uforutsette endringer i resten av systemet. Iterative prosesser er også mye enklere i modulære programmer, i motsetning til monolitiske.

Tendermint’s Architecture and Goals

Tendermint bruker den modulære arkitekturen. Målene deres er som følger:

  • Gi nettverks- og konsensuslagene til en blockchain som en plattform der forskjellige desentraliserte applikasjoner kan bygges
  • Utviklere trenger bare å bekymre seg for applikasjonslaget til blockchain, og sparer alle timene de ville ha kastet bort på å jobbe med konsensus og nettverkslaget også..
  • Tendermint inkluderer også Tendermint consensus protocol som er den bysantinske feiltolerante konsensusalgoritmen som brukes i Tendermint Core-motoren

La oss se på hvordan Tendermints arkitektur vil se ut:

Ultimate Guide to Tendermint

Som du kan se, er applikasjonen koblet til Tendermint Core via en sokkelprotokoll kalt APCI eller Application Blockchain Interface. Siden Tendermint Core og applikasjonen som kjører på den kjører i separate UNIX-prosesser, må de ha en metode for å snakke med hverandre. ABCI hjelper disse to i sin kommunikasjon.

Så hvordan ser ABCIs design ut? ABCI vil ha noen distinkte designkomponenter:

# 1 Meldingsprotokoll

  • Par forespørsel og svarmeldinger
  • Forespørsler kommer med konsensus mens søknaden tar seg av svaret
  • Den defineres ved hjelp av protobuf

# 2 Server / klient

  • Konsensusmotoren kjører klienten
  • Programmet kjører serveren
  • Det er to riktige implementeringer: asynkroniser råbyte og grpc

# 3 Blockchain Protocol

ABCI er veldig tilkoblingsorientert. De tre tilkoblingene for Tendermint Core er som følger:

  • Mempool-tilkobling: Dette sjekker om transaksjonene skal videreformidles før de blir forpliktet. Den kan bare bruke CheckTx
  • Konsensusforbindelse: Denne forbindelsen hjelper til å utføre transaksjoner som er begått. Meldingssekvensen er for hver blokk BeginBlock, [DeliverTx,…], EndBlock, Commit
  • Spørringstilkobling: Hjelper med å spørre om applikasjonstilstanden. Denne delen bruker bare spørring og info

Alt i alt er hovedmålet med Tendermint å gi utviklere et verktøy som ikke bare er praktisk, men som også har høy gjennomstrømning. Her er egenskapene til Tendermint som gjør den så forlokkende:

# 1 Offentlig eller privat Blockchain-kompatibel

Ulike prosjekter har forskjellige behov. Noen prosjekter må ha et åpent system der alle kan delta og bidra, som Ethereum. På den annen side har vi organisasjoner som medisinsk industri, som ikke kan eksponere dataene sine for omtrent alle. For dem krever de noe som den tillatte blockchain.

Ok, så hvordan kan Tendermint hjelpe til med å tilfredsstille begge disse behovene? Husk at Tendermint bare håndterer nettverk og konsensus for blockchain. Så det hjelper i:

  • Formering av transaksjonen mellom nodene via sladderprotokollen
  • Hjelper validatorene å bli enige om settet med transaksjoner som blir lagt til blockchain.

Hva dette betyr er at applikasjonslaget kan defineres fritt slik som utviklerne vil at det skal defineres. Det er opp til utviklerne å definere hvordan validatorsettet defineres i økosystemet.

  • Utviklerne kan enten la applikasjonen ha et valgsystem som velger validatorer basert på hvor mange innfødte tokens disse validatorene har satt inn i økosystemet..aka bevis på innsats og opprettet en offentlig blockchain
  • I tillegg kan utviklerne også lage et program som definerer et begrenset sett med forhåndsgodkjente validatorer som tar seg av konsensus og de nye nodene som kommer inn i økosystemet. Dette kalles autorisasjonsbevis og er kjennetegnet på en tillatt eller privat blockchain.

# 2 Høy ytelse

Søknader gjort via Tendermint Core kan forvente eksepsjonell ytelse. Tendermint Core har en blokkeringstid på bare 1 sekund. Den kan også håndtere et transaksjonsvolum på 10.000 transaksjoner per sekund for 250byte-transaksjoner, så lenge applikasjonen tillater det.

# 3 Finalitet

Hva er finalitet?

Enkelt sagt betyr det at når en bestemt handling er utført, kan den ikke tas tilbake. La oss ta eksemplet med en enkel økonomisk transaksjon. Anta at du kjøper noen aksjer i et selskap, bare fordi det er en feil i systemet deres, bør du ikke miste eierforholdet til aksjene dine. Som du kan forestille deg, er finalitet superkritisk for et finanssystem. Tenk deg å gjøre en million dollar-transaksjon, og neste dag er den transaksjonen ikke lenger gyldig på grunn av en feil.

Som vi har nevnt før, har ikke Bitcoin og Ethereum (inntil full implementering av Casper FFG) egentlig ikke oppgjørsfinalitet. I anledning hardfork eller 51% angrep, har transaksjoner en sjanse til å bli tilbakeført.

Tendermint, derimot, gir øyeblikkelig finalitet innen 1 sekund etter at transaksjonen er fullført. Det opprettes aldri gafler i systemet, så lenge mindre enn 2/3 av validatorene er ondsinnede. Så snart en blokk er opprettet (som er i løpet av et sekund), kan brukerne være trygg på at transaksjonen deres er fullført.

# 4 Sikkerhet

Tendermint er sikker og tvinger deltakerne til å være ansvarlige for sine handlinger også. Som vi har sagt før, kan tendermint aldri gaffles så lenge mindre enn 2/3 av validatorene er ondsinnede. Hvis blockchain i noen tilfeller gaffel, er det en måte å bestemme ansvar. I tillegg er Tendermint-konsensus ikke bare feiltolerant, den er også bysantinsk feiltolerant

# 5 Enkel å bruke

En annen flott ting med Tendermint er brukervennligheten. Som vi har nevnt før, har de en modulær arkitektur der applikasjonslaget kan tilpasses på passende måte. Dette gjør det mulig for eksisterende blockchain-kodebaser enkelt å bli koblet til Tendermint via ABCI. Det perfekte eksemplet på dette er Etheremint, som i utgangspunktet er Ethereum-kodebase-pluggen på virtuell maskin på toppen av Tendermint.

Ethermint fungerer akkurat som Ethereum, men har også fordeler av alle de positive funksjonene vi har nevnt ovenfor. Alle Ethereum-verktøy som Metamask og Truffle er kompatible med Ethermint.

# 6 Skalerbarhet

Tendermint’s proof-of-stake implementering er mye mer skalerbar enn en tradisjonell proof-of-work konsensusalgoritme. Hovedårsaken er at POW-baserte systemer ikke kan sharding.

Sharding i utgangspunktet horisontalt partisjonerer en database og oppretter mindre databaser eller shards som deretter utføres parallelt av nodene. Årsaken er at et sterkt gruvebasseng lett kan ta over et skjær.

Tendermint vil tillate implementering av sharding som vil øke skalerbarheten sterkt.

Tendermint Consensus Protocol

Ok, så la oss se på hvordan Tendermint-konsensusprotokollen fungerer. Hva er egentlig en konsensusprotokoll?

Slik definerer Wikipedia konsensusbeslutninger:

Konsensusbeslutning er en beslutningsprosess der gruppemedlemmene utvikler seg, og er enige om å støtte en beslutning i helhetens beste. Konsensus kan defineres profesjonelt som en akseptabel oppløsning, en som kan støttes, selv om det ikke er “favoritten” til hver enkelt. “Konsensus” er definert av Merriam-Webster som, for det første, generell enighet, og for det andre, gruppesolidaritet av tro eller følelse. “

Enklere er konsensus en dynamisk måte å oppnå enighet i en gruppe på. Mens det bare stemmer for en flertallsregel uten å tenke på minoritetens følelser og velvære, sørger en enighet derimot for at det oppnås en avtale som kan være til fordel for hele gruppen som helhet.

Fra et mer idealistisk synspunkt kan konsensus brukes av en gruppe mennesker spredt over hele verden for å skape et mer likeverdig og rettferdig samfunn.

En metode hvor konsensusbeslutning oppnås, kalles “konsensusmekanisme”.

Så nå hva vi har definert hva konsensus er, la oss se på hva som er målene for en konsensusmekanisme (data hentet fra Wikipedia).

  • Avtale søker: En konsensusmekanisme bør gi så mye enighet fra gruppen som mulig.
  • Samarbeidende: Alle deltakerne bør sikte på å samarbeide for å oppnå et resultat som setter gruppens beste først.
  • Kooperativ: Alle deltakerne bør ikke sette sine egne interesser først og jobbe som et team mer enn enkeltpersoner.
  • Deltakende: Konsensusmekanismen skal være slik at alle skal delta aktivt i den samlede prosessen.
  • Inklusive: Så mange mennesker som mulig bør være involvert i konsensusprosessen. Det burde ikke være som vanlig stemmegivning der folk ikke har lyst til å stemme fordi de tror at deres stemme ikke vil ha noen vekt i det lange løp.
  • Likestilt: En gruppe som prøver å oppnå konsensus, bør være så egalitær som mulig. Hva dette i utgangspunktet betyr at hver stemme har like vekt. En persons stemme kan ikke være viktigere enn andres stemmer.

Nå som vi har definert hva konsensusmekanismer er og hva de skal sikte mot, må vi tenke på den andre elefanten i rommet.

Hvilke konsensusmekanismer som skal brukes for en enhet som blockchain.

Før Bitcoin var det mange iterasjoner av peer-to-peer desentraliserte valutasystemer som mislyktes fordi de ikke kunne svare på det største problemet når det gjaldt å oppnå enighet. Dette problemet kalles “Byzantine Generals Problem”.

Bysantinsk generals problem

For å få gjort noe i et peer-to-peer-nettverk, bør alle nodene kunne komme til enighet. Saken er imidlertid at for at dette systemet skal fungere, legger det mye vekt på at folk skal opptre i beste interesse for det samlede nettverket. Men som vi allerede vet, er folk ikke veldig pålitelige når det gjelder å handle på etisk vis. Det er her den bysantinske generalens problem kommer inn.

Ultimate Guide to Tendermint

Se for deg denne situasjonen.

Det er en hær som omgir et godt befestet slott. Den eneste måten de kan vinne er hvis de angriper slottet sammen som en enhet. Imidlertid står de overfor et stort problem. Hæren er langt fra hverandre, og generalene kan ikke kommunisere og koordinere angrepet direkte, og noen av generalene er korrupte.

Det eneste de kan gjøre er å sende et bud fra generelt til generelt. Imidlertid kan mange ting skje med budbringeren. De korrupte generalene kan fange opp budbringeren og endre meldingen. Så, hva kan generalene gjøre for å sikre at de starter et koordinert angrep uten å stole på etikken til hver enkelt general? Hvordan kan de på en tillitsfull måte komme til enighet om å gjøre det som må gjøres?

Det er den bysantinske generals problem, og Satoshi Nakamoto løste dette problemet ved å bruke konsensusmekanismen Proof-of-Work (POW).

Hva er bevis på arbeid?

La oss sjekke hvordan POW fungerer i sammenheng med eksemplet vårt ovenfor. Anta at en general ønsker å kommunisere med en annen general. Hvordan tror du det vil gå ned?

  • Et “nonce” legges til den opprinnelige meldingen. Nonce er en tilfeldig heksadesimal verdi.
  • Denne nye meldingen blir deretter hash. Anta at generalene på forhånd er enige om at de bare vil sende meldinger, som når de blir haset begynner med 4 “0”.

    Hvis hashen ikke gir ønsket antall 0s, endres nonce og meldingen hashes igjen. Denne prosessen gjentas til ønsket hash er mottatt.

  • Hele prosessen er ekstremt tidkrevende og tar opp mye beregningskraft.
  • Nå når de endelig får den hashverdien, får budbringeren den originale meldingen og nonce og blir fortalt å kommunisere med de andre generalene. Så hva skjer hvis noen prøver å fange opp meldingen? Vel, husk skredeffekten av hashfunksjonene? Meldingen vil endres drastisk, og siden den ikke begynner med det nødvendige antallet “0” lenger, vil folk innse at meldingen har blitt tuklet med.

Så for å sette POW i sammenheng med kryptodrift:

  • Gruverne prøver å løse kryptografiske gåter for å legge til en blokk i blockchain.
  • Prosessen krever mye innsats og beregningskraft.
  • Gruvearbeiderne presenterer deretter blokken sin for bitcoin-nettverket.
  • Nettverket sjekker deretter ektheten til blokken ved å bare sjekke hasjen, hvis den er riktig, blir den lagt til blockchain.

Så å oppdage den nødvendige nonce og hash bør være vanskelig, men å sjekke om det er gyldig eller ikke, bør være enkelt. Det er essensen av bevis på arbeid.

Nå lurer du sannsynligvis på hvorfor skulle gruvearbeiderne ofre sin tid og ressurser for å bryte bitcoins? Vel, viser seg at de har et ganske sunt økonomisk insentiv:

Når du oppdager en blokk, mottar du en blokkbelønning på 12,5 bitcoins. Belønningen halveres hver 210.000 blokker.

Når du har utvunnet en blokk, blir du den midlertidige diktatoren for blokken. Du er den som er ansvarlig for å plassere transaksjoner i blokken, og har dermed rett til transaksjonsgebyrer.

Det er bare et begrenset antall bitcoins der ute, 21 millioner for å være nøyaktig. Så hva hindrer disse gruvearbeiderne i å utvinne alle bitcoins på en gang?

Vises at bitcoin-gruvedrift blir gradvis vanskeligere over tid. Denne funksjonen kalles “vanskeligheter”, og vanskeligheten med gruvedrift fortsetter å øke etter hvert som du fortsetter å bryte.

Dette er grunnen til at det i dag er umulig for solo gruvearbeidere å gruve Bitcoins bare ved hjelp av datamaskiner. Gruvearbeidere har nå gått sammen og opprettet “gruvebassenger” for å samle beregningskraften sammen og gruve som en gruppe. Disse bassengene bruker ASIC (Application-Specific Integrated Circuits) spesielt laget for gruvedrift for å utvinne bitcoins.

Problemer med POW

Det er tre hovedproblemer med Proof-of-Work-algoritmene. Vi har snakket om dette i detalj før, så vi skal bare gjøre en generell oversikt.

  • Energisvinn: Bitcoin spiser opp mer kraft enn Irland og Slovakia. Dette enorme sløsingen med energi er et av prinsippene i Bitcoin. Det er svinn for svinnets skyld.
  • Sentralisering: Som vi allerede har fortalt deg, bruker Bitcoin ASIC for gruvedrift. Problemet med det er at ASIC er dyre, og bassenger med mer penger har en tendens til å ha flere ASIC og følgelig mer gruvedrift. Som sådan er Bitcoin ikke så desentralisert som den vil være.
  • Skalerbarhet: Selve arkitekturen til POW forhindrer skalerbarhet. Bitcoin administrerer bare 7 transaksjoner per sekund. For et moderne finanssystem er det rett og slett ikke tilstrekkelig nok.

Gå inn i Tendermint

Så, for å motvirke de mange problemene med Proof-of-Work konsensus-systemet, opprettet Jae Kwon, en datalogi og systemtekniker, Tendermint. Tendermint er en ren BFT-basert protokoll, bygget i en tillatelsesfri setting med Proof-of-Stake (PoS) som den underliggende sikkerhetsmekanismen.

På grunn av kompleksiteten har Tendermint tatt nesten 4 år å fullføre.

Jae Kwon og Tendermint CTO Ethan Buchman ble inspirert av Raft og PBFT til å lage et konsensussystem som tilfredsstilte den bysantinske generals problem. Det er

“Modellert som en deterministisk protokoll, lever under delvis synkronisering, som oppnår gjennomstrømning innenfor grensene for latenstiden til nettverket og individuelle prosesser i seg selv.”

Greit, vi vet at det er mange kompliserte ord å kaste etter hverandre, men for å forstå hva Tendermint-konsensus er og hvorfor den ble designet slik den ble designet, må du forstå hva noen av disse kompliserte begrepene betyr. Du vil se hvordan alle sammen knytter seg til hverandre som et intrikat puslespill.

# 1 FLP Umulighet

FLP (Fischer Lynch Paterson) Umulighet sier at en konsensusalgoritme bare kan ha 2 av følgende 3 egenskaper:

  • Sikkerhet
  • Garantert avslutning eller levetid
  • Feiltoleranse

Ultimate Guide to Tendermint

Bildekreditt: Medium

Med andre ord, FLP umulighet fastslår at

“Både avslutning og avtale (levetid og sikkerhet) kan ikke oppfylles på en tidbundet måte i et asynkront distribuert system, hvis det skal være motstandsdyktig mot minst en feil (de viser resultatet for generell feiltoleranse, som er svakere enn bysantinsk feil toleranse, siden det bare krever en fail-stop node – så BFT er inkludert i FLP umulighetskrav). “

Så i utgangspunktet er det ganske umulig for et asynkront WAN å komme til enighet, ettersom det ikke er noen spesifikk tid som nodene vil ta å motta, behandle og svare på meldinger. Dette er åpenbart et stort problem fordi det er ekstremt upraktisk for et stort nettverk av noder som Bitcoin å anta at de skal synkronisere..

Ok, så synkronicitet skulle være et problem. Forskerne Dwork, Lynch og Stockmeyers kastet imidlertid en livline her med papiret sitt kalt “Konsensus i tilstedeværelsen av delvis synkronisering.”Dette ble kalt DLS-konsensus.

# 2 DLS-konsensus og delvis synkronitet

DLS-papiret sier at mellom et synkront system og et asynkront system eksisterer det et spesielt system som er “delvis synkron”. Siden dette delvis synkrone systemet kan ha en øvre grense gitt tid, vil det være i stand til å utforme en gjennomførbar BFT-protokoll.

Ifølge DLS er den virkelige utfordringen med å designe protokoller å ha en som fungerer riktig i et delvis synkron system.

Så la oss se hvordan populære desentraliserte protokoller som Bitcoin og Ethereum fungerer i den forbindelse.

Bitcoin har en kjent øvre grense som er rundt 10 minutter. Så, det produseres en blokk med transaksjoner hvert 10. minutt. Denne tidsforutsetningen pålegges nettverket slik at nodene får 10 hele minutter for å samle informasjonen og overføre den via sladder..

Hva er statsmaskinen?

På den annen side har vi Ethereum som gjør synkroniserende antakelser for deres blokker og nettverk ved å holde en øvre blokkeringstid på 15 sekunder. Med så lav blokkeringstid er de mer skalerbare enn Bitcoin, men de er egentlig ikke så effektive. Ethereum gruvearbeidere produserer mange foreldreløse blokker.

# 3 Liv og avslutning

Oppsigelse er en eiendom som sier at hver korrekt prosessor til slutt skal ta en beslutning. De fleste konsensusalgoritmer som vi har akkurat nå, er avhengige av synkrone modeller for deres sikkerhet og avslutning. De har faste grenser og regler som er kjent, i tilfelle de ikke holder seg, kjedet kjedet i flere protokoller

Klart det er konsensusprotokoller som fungerer i asynkrone nettverk, men de kan ikke være deterministiske etter FLP-umulighetsteoremet. Som bringer oss til ….

# 4 Deterministiske kontra ikke-deterministiske protokoller

Vanligvis er rent asynkrone konsensusprotokoller avhengige av ikke-bestemte medlemmer som Oracles, som innebærer en høy grad av usikkerhet og kompleksitet..

Så hvordan håndterer tendermint alle disse faktorene?

Tendermint er en stort sett asynkron, deterministisk, BFT-konsensus der validatorer har en eierandel som angir deres stemmerett. I FLP-umulighetstrekanten foretrekker den Feiltoleranse og sikkerhet (konsistens) fremfor livlighet.

Tendermint svinger konstant mellom perioder med synkronisering og asynkroni. Dette betyr at selv om det er avhengig av tidsforutsetninger for å gjøre fremgang, avhenger ikke hastigheten til nevnte fremdrift av systemparametere, men avhenger av reell nettverkshastighet.

Tendermint gafler aldri i nærvær av asynkroni hvis mindre enn 1/3 av validatorene er korrupte / uforsiktige. Dette er selve grunnen til at Tendermint er bysantinsk feiltolerant. Som vi har sagt før, fokuserer Tendermint på sikkerhet over livlighet. Så hvis mer enn en tredjedel av validatorene er ondsinnede, vil Tendermint blockchain ganske enkelt stoppe midlertidig til flere 2/3 validatorer kommer til enighet i stedet for nettverksgaffelen..

Tendermint er også helt deterministisk, og det er ingen tilfeldighet i protokollen. Lederne i systemet velges alle i en deterministisk versjon, via en definert matematisk funksjon. Så vi kan faktisk matematisk bevise at systemet oppfører seg slik det skal oppføre seg.

Tendermint – The Proof of Stake System

I et bevis på innsats (POS) -system har vi visse personer som kalles “validatorer”. Disse validatorene låser en innsats inne i systemet. Etter det har de ansvaret for å satse på blokken som de føler kommer til å bli lagt til ved siden av blockchain. Når blokken blir lagt til, får de en belønning proporsjonalt med innsatsen.

OK, så det er slik en generisk POS fungerer. La oss nå se på hvordan tendermint fungerer.

La oss først gjøre oss kjent med noen av begrepene vi skal bruke:

  • Et nettverk består av mange noder. Noder som er koblet til en bestemt node kalles dens jevnaldrende.
  • Konsensusprosessen foregår i en bestemt blokkhøyde H. Prosessen for å bestemme neste blokk består av flere runder.
  • Runden består av mange stater som er: NewHeight, Propose, Prevote, Precommit og Commit. Hver stat kalles et Roundstep eller bare “trinn”.
  • En node sies å være i en gitt høyde, rundt og trinn, eller ved (H, R, S), eller i kort (H, R) for å utelate trinnet.
  • Å forutsette eller forplikte noe betyr å kringkaste en forhåndsstemme eller forutsette avstemning for noe.
  • Når en blokk blir >2/3 av prevotene ved (H, R) så kalles det proof-of-lock-change eller PoLC.

Hva er statsmaskinen??

Statsmaskinen er motoren til Tendermint-protokollen så å si. Følgende diagram gir deg en god ide om hvordan det vil se ut:

Hva er statsmaskinen?

Ok, så hva skjer her?

Husker du tilstandene som hver runde går gjennom? NewHeight, Propose, Prevote, Precommit og Commit.

Av disse består “Propose, Prevote, Precommit” av en runde mens de to andre er spesielle runder. I et ideelt scenario vil statsovergangen fungere slik:

NewHeight -> (Foreslå -> Forhindre -> Forpliktelse)+ -> Begå -> NewHeight ->…

Det er imidlertid ikke slik det alltid kan fungere. Flere runder kan være nødvendig før blokken er begått. Følgende er årsakene til at det kan være behov for flere runder:

  • Den angitte forslagsstiller kan være fraværende.
  • Foreslått blokkering kan være ugyldig.
  • Blokken forplantet seg ikke i tide.
  • >2/3 av prevotene ble ikke mottatt i tide av valideringsnodene.
  • Selv om +2/3 av prevotes er nødvendig for å komme videre til neste trinn, kan minst en validator ha stemt eller skadelig stemt på noe annet.
  • >2/3 av forpliktelsene for blokkeringen ble ikke mottatt, selv om forhåndsbevis kan ha blitt mottatt.

Hva skjer under hver stat?

Greit … så la oss se nærmere på hver eneste stat og se hvordan det hele kommer sammen.

Foreslå

I dette trinnet foreslår den angitte forslagsstilleren, dvs. den valgte noden, en blokk som skal legges til ved (H, R). Denne fasen ender på en av to måter:

Blokken blir foreslått, og det går inn i forrige fase.

Forslagsstillerens tid til å velge blokken utløper hvor den uansett går inn i den forrige scenen.

Forhindre

Nå kommer vi til den forrige fasen. I dette stadiet må hver validator ta en beslutning.

  • Hvis validatoren på en eller annen måte er låst på en foreslått blokk fra en forrige runde, signerer de automatisk og sender den blokken.
  • Hvis validatoren hadde mottatt et akseptabelt forslag for den aktuelle runden, signerer og sender de en forhåndsmelding for den foreslåtte blokken.
  • Imidlertid, hvis de finner noe fishy med forslaget eller ikke har mottatt noe forslag i det hele tatt (f.eks. Hvis forslagsstillerens tid går ut), så signerer de med en “null” prevote.
  • Ingen blokkering skjer i løpet av dette stadiet.
  • I løpet av denne perioden forplanter alle noder forekomsten i hele systemet via sladderprotokollen.

Forpliktelse

Nå går vi inn i det siste trinnet i “runden” kalt “precommit.” Når de kommer inn på dette stadiet, forplikter validatorene seg til sin avgjørelse ved å kringkaste sine prevoter. Ett av følgende tre scenarier kan skje:

  • Hvis validatoren mottar >2/3 av forutsetningene for en bestemt akseptabel blokkering, deretter signerer validatoren og sender sin forpliktelse til blokken. De blir også låst på den blokken. En validator kan bare låses på en blokk om gangen.
  • Imidlertid, hvis validatoren mottar mer enn 2/3 av NUL, så låser de opp og forplikter seg til “NIL”.
  • Til slutt, hvis de ikke har mottatt et superflertall på 2/3 i det hele tatt, logger de ikke av eller låser på noe.

Gjennom hele dette stadiet fortsetter nodene å sladre om forpliktelsene i hele nettverket.

Til slutt, hvis den foreslåtte blokken får mer enn 2/3 forpliktelser, beveger vi oss mot “Commit” -trinnet. Men hvis de ikke når den fasen, går de inn i “Propose” -fasen i neste runde.

Begå

Commit-staten er ikke en del av “runden”. Sammen med NewHeight er det en av de to spesielle rundene. Under forpliktelsesstaten kontrolleres to parallelle vilkår for å se om de blir oppfylt eller ikke.

  • For det første må validatorene motta blokken som er forhåndsengasjert av nettverket. Når det er gjort, logger de av og sender sitt engasjement.
  • For det andre må de vente til de har fått minst 2/3 forpliktelser for blokken.

    Når dette er gjort, blir blokken forpliktet til nettverket.

NewHeight

Øk bare blokkhøyde med 1 for å vise at blokken er lagt til.

Velge validatorene

Som du kanskje har forstått nå, er det viktig å velge det første settet med validatorer for at Cosmos skal fungere. Så, hvordan akkurat de skal velges?

I motsetning til Bitcoin hvor hvem som helst kan bli gruvearbeider når som helst, er det bare så mange validatorer som Tendermint-systemet kan ta inn. Siden validatorer hver for seg vil trenge å gjøre mange funksjoner, vil økning i antall validatorer bare føre til forsinkelse.

Dette er grunnen til at Cosmos bestemte seg for å velge 100 validatorer i løpet av Genesis-dagen (dvs. dagen for innsamlingen.) Antallet validatorer vil øke med 13% hvert år til 10 år når det vil avgjøre 300.

Ultimate Guide to Tendermint

Så hva med resultatene?

Som kosmotabellen sier:

Tendermint gir eksepsjonell ytelse. I standardverdier for 64 noder fordelt på 7 datasentre på 5 kontinenter, på råvareskyforekomster, kan Tendermint-konsensus behandle tusenvis av transaksjoner per sekund, med forsinkelsesforsinkelser i størrelsesorden ett til to sekunder. Spesielt opprettholdes utførelsen av godt over tusen transaksjoner per sekund selv under tøffe motstandsforhold, med validatorer som krasjer eller kringkaster ondsinnede stemmer. “

Grafen nedenfor støtter kravet ovenfor:

Casper vs Tendermint

Sammen med Tendermint er Casper en annen populær implementering av POS-protokoll.

Mens Tendermint fokuserer på sikkerhet, er Caspers fokus i livskraft, med FLP umulighet. Så, hva skjer i Casper under en gaffel?

Casper FFG vil tillate at en blockchain fortsetter å bygges, samtidig som den har egenskapen til at alle noder vil være klar over at denne kjeden ikke er ferdig. Så blockchain kan forbli tilgjengelig uten noen finalitet. Validatorene kjeden har valget om å flytte til gaffelkjeden. Hvis mer enn 2/3 av validatorene stemmer, bytter de kjetting.

I tillegg har Casper en berømt kuttmekanisme. Ethvert slags ondsinnet angrep vil føre til at validatorer får sin innsats umiddelbart kuttet.

Tendermint Konklusjon

Så der har du det. Vi håper at vi ga deg så mye verdifull informasjon som mulig. Hva synes du om Tendermint og dens potensiale? Hør av på kommentarseksjonen nedenfor!

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me