Key Takeaways

1. Solana izmanto vienādranga tenku protokolu, kura pamatā ir Plumtree algoritms, ļaujot decentralizētai saziņai starp mezgliem efektīvi izplatīt stāvokļa izmaiņas visā tīklā, nepaļaujoties uz centrālo avotu.
2. Ik pēc 0,1 sekundes Solana mezgli apmainās ar "push" un "pull" ziņojumiem, nodrošinot nepārtrauktu un atjauninātu informācijas koplietošanu, lai nodrošinātu ātru datu izplatīšanu un sinhronizāciju visā tīklā.
3. Tenku protokols sastāv no četriem galvenajiem ziņojumu veidiem — Push, Pull, Prune un Ping/Pong —, kas palīdz izplatīt datus, pieprasīt trūkstošo informāciju, pārvaldīt mezglu savienojumus un pārbaudīt mezgla vitalitāti.
4. Tenku dati tiek glabāti klastera replicēto datu krātuvē (CrdsTable), kas tiek nepārtraukti atjaunināts ar pakāpeniskiem tīkla stāvokļa atjauninājumiem, nodrošinot datu pieejamību un sinhronizāciju starp mezgliem.
5. Solana arhīvu sistēma izmanto "noliktavas mezglus", lai saglabātu darījumu vēsturi, jaunākos datus (1–2 laikus) saglabājot pārbaudītājiem, savukārt pilna darījumu vēsture tiek glabāta Ledger Archives vai Google Bigtable instancēs, lai RPC un citi dalībnieki varētu viegli piekļūt.

Tenkas

Tenku protokols ir vienādranga komunikācijas metode sadalītās sistēmās, kur tīkla mezgli periodiski apmainās ar informāciju par sevi un citiem mezgliem, ar kuriem katrs mezgls ir savienots decentralizēti. Tas ir līdzīgi tam, kā baumas izplatās sociālajos medijos. Tas nozīmē, ka visas nelielas stāvokļa izmaiņas galu galā tiks izplatītas tīklā, un visiem mezgliem būs pilnīga informācija par šo stāvokļa maiņu.

Vietnē Solana tās tenku protokola ieviešanā tiek izmantota neformāla saziņas metode ar koka apraides pieeju, kas ir ļoti modelēta saskaņā ar Plumtree algoritmu. Tas padara stāvokļa izmaiņu izplatību, nepaļaujoties uz centrālo galvas avotu. Tas darbojas kā Solana vadības panelis, jo tas palīdz pārbaudītājiem un RPC mezgliem uzzināt, kuras adreses un porti ir atvērti saziņai. Solana Gossip darbojas ar citiem galvenajiem komponentiem, piemēram, pārbaudītājiem, turbīnas protokolu, arhīva mezgliem, vēstures pierādījumiem utt. Validatori un RPC apmainās ar parakstītiem datu objektiem ik pēc 0,1 sekundes, izmantojot UDP, izmantojot tenkas, garantējot informācijas pieejamību visā tīklā. Katram tenku ziņojumam ir jābūt vienādam ar maksimālo pārraides vienību (MTU) 1280 baitu vai mazāku, ko kodu bāzē sauc par "pakešu struktūru".

Tenku protokols kalpo kā centrālais mehānisms mezgliem, lai efektīvi pārvaldītu klasteru komunikāciju, nepārtraukti koplietojot parakstītos datu objektus, piemēram, kontaktinformāciju, virsgrāmatas augstumu un balsis. Ik pēc 0,1 sekundes mezgli apmainās ar "push" un "pull" ziņojumiem, kur push ziņojumus var pārsūtīt un abi veidi var izraisīt atbildes, veicinot ātru datu izplatīšanu visā tīklā. Darbojoties labi zināmā UDP/IP portā vai portu diapazonā, tenku protokols ļauj mezgliem reklamēt savus tenku galapunktus (ligzdas adreses) viens otram pēc klastera sāknēšanas. Šis decentralizētais augstfrekvences komunikācijas grafiks nodrošina, ka Solana mezgli paliek sinhronizēti un elastīgi, atbalstot blokķēdes mērogojamību un veiktspēju.

Solanas tenku protokolā četri ziņojumu veidi atvieglo klasteru saziņu: Push ziņojumi, kas ir visizplatītākie, izplata datus atlasītai "push vienaudžu" grupai. Izvilkšanas ziņojumi kopā ar to izvilkšanas atbildēm tiek periodiski nosūtīti, lai izgūtu trūkstošo informāciju, pieprasot un piegādājot nekopīgotus datus. Apgriešanas ziņojumi ļauj mezgliem pēc vajadzības samazināt savus aktīvos savienojumus. Visbeidzot, Ping un Pong ziņojumi kalpo kā vitalitātes pārbaudes, kur ping prasa tenisa atbildi, lai apstiprinātu vienādranga mezgla darbības statusu.

Tenku dati tiek glabāti klastera replicēto datu krātuvē (CrdsTable). Šī datu struktūra tiek pastāvīgi atjaunināta ar tenku protokola ziņojumiem. Šajos ziņojumos ir ietverti tenku ieraksti, kas būtībā ir CrdsTable pakāpeniski atjauninājumi.

Arhīvs

Solana atšķir sevi no citām blokķēdēm, neprasot pilnu darījumu vēsturi, lai noteiktu konta pašreizējo stāvokli. Tā konta modelis nodrošina, ka ir zināms stāvoklis jebkurā konkrētajā slotā, ļaujot pārbaudītājiem saglabāt pašreizējo stāvokli, neapstrādājot visus vēsturiskos blokus. RPC un validatori parasti nesaglabā visu virsgrāmatas vēsturi; tā vietā tie saglabā tikai 1 vai 2 epochas (2–4 dienas) darījumu datus, kas ir pietiekami, lai apstiprinātu jaunāko bloku.

Arhīvu datus pārvalda "noliktavas mezgli", kurus vada profesionāli RPC pakalpojumu sniedzēji, Solana Foundation un citi ekosistēmas dalībnieki, lai nodrošinātu darījumu vēstures pieejamību. Šie noliktavas mezgli bieži uztur vai nu Virsgrāmatas arhīvu, kurā tiek glabāti neapstrādāti virsgrāmatas un AccountsDB momentuzņēmumi, lai tos varētu atkārtoti atskaņot no nulles, vai Google Bigtable instanci, kas glabā bloku datus no ģenēzes bloka tālāk RPC pieprasījumiem piemērotā formātā.

Secinājums

Visbeidzot, Solana tenku protokols un arhīvu sistēma nodrošina efektīvu saziņu un datu sinhronizāciju visā tīklā. Tenku protokols nodrošina ātru stāvokļa izplatīšanu, savukārt arhīvu sistēma saglabā darījumu vēsturi, lai pārbaudītāji un RPC varētu tai viegli piekļūt. Kopā šie līdzekļi atbalsta Solana mērogojamību, veiktspēju un decentralizāciju.