Solan grundades i slutet av 2017 av före detta ingenjörer från Qualcomm, Intel och Dropbox och är ett enkedjedelegerat proof-of-stake-protokoll fokuserat på att tillhandahålla skalbarhet utan att kompromissa med decentralisering eller säkerhet. Kärnan i Solanas skalningslösning är en decentraliserad klocka som kallas Proof of History (PoH), designad för att lösa problemet med tid i ett distribuerat nätverk utan en enda pålitlig tidskälla. Genom att använda en verifierbar fördröjningsfunktion tillåter PoH varje nod att generera tidsstämplar lokalt med hjälp av SHA256-beräkningar. Detta eliminerar behovet av att sända tidsstämplar över nätverket, vilket ökar den totala nätverkseffektiviteten.
SOL är den ursprungliga symbolen för Solana-blockkedjan. Solana använder en Delegerad Proof-of-Stake-konsensusalgoritm för att uppmuntra tokeninnehavare att validera transaktioner. Som en del av Solanas säkra design kommer alla avgifter att betalas i SOL och brännas, vilket minskar det totala utbudet. Denna deflationära SOL-mekanism uppmuntrar fler tokeninnehavare att delta, vilket ökar nätverkssäkerheten.

Projektfunktioner

För att skapa en distribuerad reskontra med kodad, tillförlitlig tid, designade SOLANA Proof of History, som är ett bevis på tiden mellan verifieringsorder och specifika händelser.
Proof of History kommer att fungera med Proof of Work (konsensusalgoritmen som används av Bitcoin etc.) eller Proof of Stake (konsensusalgoritmen som används av Ethereums Casper). Detta minskar meddelandekostnaderna som leder till uppsägningstider under en sekund.
Utöver det arbetar Solana med att generera upp till 710K transaktioner per sekund på en 1 GB nätverksbasis utan datapartitionering. Vill du veta hur de planerar att uppnå denna stora seger?
I kapplöpningen om att utveckla high-throughput (Tps) och mycket säkra blockkedjor, utarbetar teamen nya sätt att skapa mycket skalbara lösningar som tillåter Conduct höga transaktionsvolymer.
"En tidsfråga?". I data- och informationsåldern finns ett grundläggande behov som väntar på att bli löst. Rättvis koordinering mellan evenemang. Det betyder: när en dator till exempel skickar ett meddelande till en annan dator måste de synkronisera tiden mellan transaktionerna. Så detta betyder att om de var och en har sin egen interna klocka, kanske de kan eller kanske inte kan koordinera korrekt.
Att koordinera evenemang med tidsstämplar är inte bara ett systemkrav, utan också en enorm kostnad i pengar, människor och ansträngning.
Utvecklare har börjat använda en teknik för att öka den totala genomströmningen av kedjan. Sharding är en teknik som används för att förbättra TPS (systemgenomströmning) för den övergripande kedjan och har visat sig vara framgångsrik, men det är inte en komplett lösning i sig, eftersom detta kan introducera sårbarheter.
Den största sårbarheten är fragmentering av transaktioner som, om de inte hanteras på rätt sätt, kan öppna kedjan för bedrägliga transaktioner, dubbla utgifter eller fragment av samma transaktion som saknar delad kunskap.
För att ge ett allmänt perspektiv, spenderar Google Spanner (Googles skalbara, flerversionsbaserade, globalt distribuerade och synkront replikerade databas som stöder läs- och skrivtransaktioner, skrivskyddade transaktioner och ögonblicksbildläsningar) mycket resurser på att synkronisera sina data Atomklockor mellan datacenter.
De måste underhållas exakt och det finns massor av ingenjörer som arbetar med det. Det kan tyckas som att koordinera tid är en lätt uppgift, men det är det inte, och det här är Proof-of-History-lösningen som Solana föreslår.
Genom att möjliggöra pålitlig tidskoordinering ökar Solana inte bara blockchain-genomströmningen när det gäller hastighet och tillförlitlighet, utan minskar också den genomsnittliga kostnaden.
Ett team som framgångsrikt löser detta problem kommer sannolikt att ha en starkt antagen blockkedja.

Teknisk översikt

Att gräva i de lösningar som Solana föreslår väcker frågor som hur man implementerar proof of history på blockkedjan och hur exakt fungerar Solana och vilka verktyg använder de?
Först måste vi förstå hur webben är designad och vad den består av.
Bevis på historik är en högfrekvent verifierbar fördröjningsfunktion. Detta innebär att det kommer att krävas ett bestämt antal relevanta steg för att bedömas. Men å andra sidan ger dessa steg en unik utdata, som är lätt att verifiera.
I lösningsavsnittet diskuterade vi hur Solana kan öka antalet TXN/s och minska de resurser som krävs för att köra dem. Tolkningen av denna möjlighet överensstämmer med tolkningen av hashfunktioner.
Hash fungerar som ett sätt att komprimera data så att större mängder data kan sluta komprimeras till ett litet antal bitar uppmuntrar minskade tx-vikter, vilket resulterar i ökad effektivitet och snabbare sekvenser.
Som nämnts ovan är proof-of-history-sekvenser designade för att fungera med kryptografiska hashfunktioner.
Av särskild relevans för kryptografiska hashfunktioner är användningen av rådata för att förutsäga det slutliga resultatet (output) utan att köra hela funktionen från början. Så om du har en ingång och försöker förutsäga resultatet är omöjligt, måste du köra funktionen för att få resultatet.
Med detta i åtanke, anta att denna hash-funktion körs från någon slumpmässig startpunkt (initial input), och när processen är klar, erhålls den första outputen (hash). Det är här det blir intressant, att mata in input till nästa hash tillsammans med output du får från att köra funktionen.
Om vi ​​vill upprepa den här processen, säg 300 gånger. Du kan börja se att vi har skapat en entrådad process där den slutliga utdata (hash 300) är helt omöjlig att gissa utom av den som kör hela tråden.
Denna cykel av att tillhandahålla utdata till nästa funktions indata och genererade data representeras som tidens gång och skapandet av historia, på Solana-språk, som tick. Varje utdata innehåller detaljerad information som inte kan förutsägas utan att köra funktionen. Liksom Marvel-filmerna i exemplet ovan representerar varje verk en tidsperiod som råkar vara dess plats i tråden av kontinuerlig tid.
Därför rekommenderar Solana att inte använda opålitliga tider, utan att använda dessa sekventiellt ordnade och oförutsägbara utdata för att bestämma ett specifikt moment, det vill säga ett specifikt ögonblick i trådprocessen. Vi kan kalla det historia.

Bevis på projektets eget kapital

Solana använder Proof-of-Stake (POS) för konsensus, och det delar många av samma egenskaper som andra POS-baserade tokens. Som en uppfräschning är här några viktiga funktioner hos POS-tokens:
Bevis på POS-tokens använder validatorer
POS kan verifieras
1. Lås tokens i plånboken
2. Put Tokens är låsta på masternode, som bidrar till kedjans stabilitet
Betalningsordningen bestäms av "åldern" för POS-token eller masternode-belöningsprogrammet.
Varje POS-plånbok eller masternode-belöningsprogram får präglade eller nyförfalskade tokens.
Plånböcker eller masternode-belöningsprogram som har varit offline för länge "betalar" inte längre och kan tas bort från nätverket.
POS roll är att förhindra dåliga aktörer från att införa ogiltiga transaktioner genom att undergräva nätverkets säkerhet.
Straffet för "dåliga skådespelare" kan vara förlust av POS-tokens och belöningar.
Förtroende är garanterat så länge som belöningen för att bevisa fördelar överväger chansen att vinna vinster genom bedrägerier.
Solana har en mycket liknande struktur, men de implementerade sin POS på ett lite annorlunda sätt.
Solana väljer en validator (dvs. sätter in en token) bland de noder som är anslutna.
Validatorns röstning och val kommer sedan att bestämmas av den nod som har varit den längsta eller mest bundna noden.
Solana förlitar sig på snabb bekräftelse; om en nod inte svarar inom en angiven tid markeras den som död och tas bort från omröstningen, och om noden var en validator vid den tidpunkten hålls ett nytt val för att välja en ny valideringsenhet.
Om en nod med supermajoritet (två tredjedelar av noderna) röstar inom denna timeout, anses gaffeln vara giltig.
Clipping är handlingen att ogiltigförklara insatser, vilket förhindrar validerare från att begå bedrägerier eller försöka validera flera noder, eftersom bundna tokens kommer att gå förlorade.
En stor skillnad är konceptet med sekundära valnoder. När den väl är vald kan en sekundär nod ta över den primära rollen i händelse av ett nätverksavbrott eller annat fel.

Relaterade länkar:
https://www.qukuaiwang.com.cn/news/9130.html