Solana, der blev grundlagt i slutningen af ​​2017 af tidligere Qualcomm, Intel og Dropbox-ingeniører, er en enkeltkædet delegeret proof-of-stake-protokol, der fokuserer på at give skalerbarhed uden at gå på kompromis med decentralisering eller sikkerhed. I hjertet af Solanas skaleringsløsning er et decentralt ur kaldet Proof of History (PoH), designet til at løse problemet med tid i et distribueret netværk uden en eneste pålidelig tidskilde. Ved at bruge en verificerbar forsinkelsesfunktion tillader PoH hver node at generere tidsstempler lokalt ved hjælp af SHA256-beregninger. Dette eliminerer behovet for at udsende tidsstempler på tværs af netværket, hvilket øger den samlede netværkseffektivitet.
SOL er det native token af ​​Solana blockchain. Solana bruger en Delegeret Proof-of-Stake-konsensusalgoritme til at tilskynde token-indehavere til at validere transaktioner. Som en del af Solanas sikre design vil alle gebyrer blive betalt i SOL og brændt, hvilket reducerer det samlede udbud. Denne deflationære SOL-mekanisme tilskynder flere token-indehavere til at deltage og øger derved netværkssikkerheden.

Projektfunktioner

For at skabe en distribueret hovedbog med kodet, tillidsfri tid, designede SOLANA Proof of History, som er et bevis på tiden mellem verifikationsordrer og specifikke begivenheder.
Proof of History vil fungere med Proof of Work (konsensusalgoritmen brugt af Bitcoin osv.) eller Proof of Stake (konsensusalgoritmen brugt af Ethereums Casper). Dette reducerer meddelelsesomkostningerne, der fører til opsigelsestider på under sekunder.
Ud over det arbejder Solana på at generere op til 710K transaktioner i sekundet på en 1 GB netværksbasis uden datapartitionering. Vil du vide, hvordan de planlægger at opnå denne store sejr?
I kapløbet om at udvikle high-throughput (Tps) og meget sikre blockchains, udtænker teams nye måder at skabe meget skalerbare løsninger, der tillader Conduct høje transaktionsvolumener.
"Et spørgsmål om tid?". I computer- og informationstiden er der et grundlæggende behov, der venter på at blive løst. Fair koordinering mellem arrangementer. Det betyder: for eksempel, når en computer sender en besked til en anden computer, skal de synkronisere tiden mellem transaktioner. Så det betyder, at hvis de hver især har deres eget interne ur, kan de eller måske ikke være i stand til at koordinere korrekt.
Koordinering af begivenheder med tidsstempler er ikke kun et systemkrav, men også en stor omkostning i penge, mennesker og indsats.
Udviklere er begyndt at bruge en teknik til at øge den samlede gennemstrømning af kæden. Sharding er en teknik, der bruges til at forbedre TPS (system throughput) i den overordnede kæde og har vist sig at være vellykket, men det er ikke en komplet løsning i sig selv, da dette kan introducere sårbarheder.
Den største sårbarhed er fragmentering af transaktioner, som, hvis de ikke håndteres korrekt, kan åbne kæden for svigagtige transaktioner, dobbeltudgifter eller fragmenter af den samme transaktion, der mangler delt viden.
For at give et generelt perspektiv bruger Google Spanner (Googles skalerbare, multi-versionerede, globalt distribuerede og synkront replikerede database, der understøtter læse-skrive-transaktioner, skrivebeskyttede transaktioner og snapshot-læsninger) mange ressourcer på at synkronisere sine data Atom-ure mellem datacentre.
De skal vedligeholdes præcist, og der er tonsvis af ingeniører, der arbejder på det. Det kan virke som om at koordinere tid er en nem opgave, men det er den ikke, og dette er Proof-of-History-løsningen foreslået af Solana.
Ved at muliggøre pålidelig tidskoordinering øger Solana ikke kun blockchain-gennemstrømningen med hensyn til hastighed og pålidelighed, men reducerer også de gennemsnitlige omkostninger.
Et team, der med succes løser dette problem, vil sandsynligvis have en stærkt vedtaget blockchain.

Teknisk oversigt

At grave i de løsninger, der er foreslået af Solana, rejser spørgsmål såsom, hvordan man implementerer proof of history på blockchain, og hvordan fungerer Solana præcist, og hvilke værktøjer bruger de?
Først skal vi forstå, hvordan nettet er designet, og hvad det består af.
Historiebevis er en højfrekvent verificerbar forsinkelsesfunktion. Det betyder, at det vil kræve et fastlagt antal relevante trin at blive vurderet. Men på den anden side ender disse trin med at producere et unikt output, som er nemt at verificere.
I løsningsafsnittet diskuterede vi, hvordan Solana kan øge antallet af TXN/s og reducere de nødvendige ressourcer til at køre dem. Fortolkningen af ​​denne mulighed er i overensstemmelse med fortolkningen af ​​hashfunktioner.
Hash fungerer som en måde at komprimere data på, så større mængder data kan ende med at blive komprimeret til et lille antal bits, hvilket tilskynder til reducerede TX-vægte, hvilket resulterer i øget effektivitet og hurtigere sekvenser.
Som nævnt ovenfor er proof-of-history-sekvenser designet til at fungere med kryptografiske hash-funktioner.
Af særlig relevans for kryptografiske hash-funktioner er brugen af ​​rå input til at forudsige det endelige resultat (output) uden at udføre hele funktionen fra bunden. Så hvis du har et input og forsøger at forudsige outputtet er umuligt, bliver du nødt til at køre funktionen for at få resultatet.
Med dette i tankerne, antag, at denne hash-funktion køres fra et tilfældigt startpunkt (indledende input), og når processen er færdig, opnås det første output (hash). Her er det, hvor det bliver interessant, ved at føre input til input til den næste hash sammen med det output, du får fra at køre funktionen.
Hvis vi vil gentage denne proces, så sig 300 gange. Du kan begynde at se, at vi har oprettet en enkelt-trådsproces, hvor det endelige output (hash 300) er fuldstændigt utænkeligt, undtagen af ​​den, der udfører hele tråden.
Denne sløjfe, der giver output til den næste funktions input og genererede data, er repræsenteret som tidens gang og skabelsen af ​​historie, i Solana-sprog, som flueben. Hvert output bærer detaljeret information, som ikke kan forudsiges uden at køre funktionen. Ligesom Marvel-filmene i ovenstående eksempel repræsenterer hvert værk en tidsperiode, der tilfældigvis er dets plads i tråden af ​​kontinuerlig tid.
Derfor anbefaler Solana ikke at bruge upålidelige tider, men at bruge disse sekventielt ordnede og uforudsigelige output til at bestemme et specifikt moment, det vil sige et specifikt øjeblik i trådprocessen. Vi kan kalde det historie.

Bevis for projektets egenkapital

Solana bruger Proof-of-Stake (POS) til konsensus, og det deler mange af de samme karakteristika som andre POS-baserede tokens. Som en genopfriskning er her nogle nøglefunktioner ved POS-tokens:
Bevis for POS-tokens brug af validatorer
POS kan verificeres
1. Lås tokens i tegnebogen
2. Put-tokens er låst på masternode, som bidrager til kædens stabilitet
Betalingsrækkefølgen bestemmes af "alderen" på POS-tokenet eller masternode-belønningsprogrammet.
Hvert POS-pung eller masternode-belønningsprogram modtager prægede eller nyligt forfalskede tokens.
Tegnebøger eller masternode-belønningsprogrammer, der har været offline for længe, ​​"betaler" ikke længere og kan blive fjernet fra netværket.
POS's rolle er at forhindre dårlige aktører i at indføre ugyldige transaktioner ved at underminere netværkets sikkerhed.
Straffen for "dårlige skuespillere" kan være tab af POS-tokens og belønninger.
Tillid er garanteret, så længe belønningen ved at bevise fordele opvejer chancen for at opnå gevinster gennem svindel.
Solana har en meget lignende struktur, men de implementerede deres POS på en lidt anden måde.
Solana vælger en validator (dvs. sætter et token) blandt de noder, der er forbundet.
Validator-afstemning og -valg vil derefter blive bestemt af den node, der har været den længste eller mest bundne node.
Solana er afhængig af hurtig bekræftelse; hvis en node ikke svarer inden for en specificeret tid, markeres den som død og fjernes fra afstemning, og hvis noden var en validator på det tidspunkt, afholdes et nyt valg for at vælge en ny valideringsenhed.
Hvis en super-majority node (to tredjedele af noder) stemmer inden for denne timeout, anses forken for gyldig.
Klipning er handlingen med at ugyldiggøre indsats, som forhindrer validatorer i at begå svindel eller forsøge at validere flere noder, da bundne tokens vil gå tabt.
En væsentlig forskel er konceptet med sekundære valgknudepunkter. Når den er valgt, kan en sekundær node overtage den primære rolle i tilfælde af netværkssvigt eller anden fejl.

Relaterede links:
https://www.qukuaiwang.com.cn/news/9130.html