Jūsu dApp ir neaizsargāta — lūk, kas to izraisa

RPC (Remote Procedure Call) mezgli ir kritiski blokķēdes infrastruktūras komponenti. Tie apstrādā saziņu starp decentralizēto nemainīgo virsgrāmatu un priekšgala lietojumprogrammām. Šīs starpniekinfrastruktūras darbojas kā kurjers, kas atvieglo pieprasījumus un atbildes starp mezgliem un pakalpojumiem, kas veidoti uz blokķēdes.

RPC mezgli ir gluži kā Amerikas Savienoto Valstu pasta dienests (USPS), kas atvieglo informācijas kustību no dApp uz blokķēdi un atpakaļ. Tāpat kā jūs paļaujaties uz pasta pakalpojumu, lai nosūtītu pastu no viena punkta uz citu, dApps ir atkarīgs no RPC mezgliem, lai piekļūtu blokķēdei. Un bez šiem mezgliem decentralizētajām lietojumprogrammām būs grūti darboties.

RPC mezgli pēdējo 10 gadu laikā ir ievērojami attīstījušies, taču infrastruktūras centralizācija ir ieviesusi slēptu ievainojamību. Šī raksta mērķis ir izpētīt RPC mezglu lomu, centralizācijas draudus un alternatīvas, kas var aizsargāt jūsu dApps no ievainojamībām.

RPC infrastruktūras attīstība

Ideja par attālo procedūru izsaukumiem aizsākās 1970. gados, kad datorzinātnieki meklēja veidus, kā sazināties starp dažādām iekārtām, lai padarītu izplatītos datorus pārredzamus izstrādātājiem.

Astoņdesmitajos gados pirmo RPC izstrādāja Sun Microsystem ar nosaukumu Network File System. Sun Microsystem izstrādāja Open Network Computing RPC protokolu, un tas ir kļuvis par standartu saziņai starp dažādām programmām tīklā.

Tomēr 90. gadu sākumā Microsoft izstrādāja un ieviesa savu RPC versiju, lai nodrošinātu saziņu starp procesiem Windows sistēmās. 2000. gadu sākumā tika ieviests JSON RPC, kas datu kodēšanai izmanto JSON. Tas kļuva bēdīgi slavens izstrādātāju un programmētāju vidū, jo tika viegli pārsūtīt standartizētus datus.

Pēdējo desmit gadu laikā dApps ir kļuvuši par svarīgu blokķēdes nozares sastāvdaļu, un RPC ir bijusi ideāla infrastruktūra, kas nepieciešama, lai pabeigtu labirintu.

Kāpēc?

1. Tā spēja veikt attālo funkciju zvanu citā datorā, piemēram, vietējās funkcijas zvanu, ir lieliski piemērota blokķēdes arhitektūrai.
2. Tā bezvalstniecība un vieglais svars nodrošina blokķēdes spēku un palīdz joslas platuma un skaitļošanas ierobežojumu situācijās.

Priekšrocību dēļ RPC ātri kļuva plaši izmantots. RPC tika ierosināts, lai ļautu dažādās valodās rakstītām lietojumprogrammām izveidot savienojumu un sazināties. RPC pamatideja ir veikt attālo funkciju zvanu citā datorā vai serverī tā, it kā tas būtu lokāls funkcijas izsaukums.

Gadu gaitā ir bijuši trīs galvenie RPC veidi (centralizētie, decentralizētie un pašmitinātie), un katrs ir unikāls savā veidā.

Centralizēto RPC mezglu briesmas

Centralizētie RPC mezgli ir mezgli, kurus pārvalda un kontrolē viena entītija. Šiem centralizētajiem mezgliem ir modeļi, kas līdzinās web2 mākoņa mitināšanas pakalpojumiem, piemēram, AWS (Amazon Web Services), Microsoft Azure un Google Cloud Protocol (GCP).

Lai gan šie centralizētie tīmekļa 3 RPC nodrošinātāji uztur mezglu infrastruktūru decentralizētām lietojumprogrammām, dziļa sistēmas izpēte atklāja, cik centralizēti tie ir. Šie web3 infrastruktūras nodrošinātāji ironiskā kārtā ir atkarīgi arī no web2 mākoņa mitināšanas servera infrastruktūras, lai uzturētu savus pakalpojumus.

Tātad, kad šiem mākoņa pakalpojumu sniedzējiem rodas pārtraukumi, dīkstāve tiek piedzīvota arī decentralizētajiem tīmekļa 3 pakalpojumiem. Šeit ir centralizēto RPC mezglu piemēri: Alchemy, Infura, Quicknode utt.

Apskatīsim apdraudējumus, ko web3 infrastruktūrai rada centralizētie RPC mezgli.

1. Viens atteices punkts: viens kļūmes punkts vienmēr ietekmē sistēmas uzticamību. Viens serveris vai serveru tīkls, ko kontrolē viena vienība, radīs kritisku punktu, kas var izraisīt jūsu dApp kļūmi.

   
   

   

   
   

   Ja serveris, caur kuru dati tiek maršrutēti, neizdodas, saikne starp blokķēdi un dApp tiek pārtraukta un sistēma neizdodas. Viens kļūmes punkts ietekmēs sistēmas uzticamību, īpaši ar finansēm saistītās lietotnēs, piemēram, DeFi platformās.

2. Mērogojamības problēma : centralizēti RPC mezgli var kļūt par sastrēgumiem lielas satiksmes laikā, un tas ierobežo dApp mērogojamību. Ja tīkls ir pārslogots, jo paļaujas uz vienu mezglu, tas ietekmē dApps efektivitāti un palielina latentumu, kas ietekmē lietotājus.

   
   

   Tā kā tā ir centralizēta sistēma, nav iespējams palielināt dApp mērogojamību.

3. Drošības risks un ievainojamība: centralizēts vai speciāls mezgls ir atvērts ievainojamībai un var būt viegls mērķis negodīgām personām. Datus var atklāt un manipulēt, un galu galā tie var ietekmēt lēmumu pieņemšanu dApps.

   
   

   Turklāt koordinētu uzbrukumu pakalpojumu sniedzējam var arī viegli īstenot, galu galā atklājot Dapp lietotājus. Valsts aģentūras var piespiest vienu vienību slēgt lietojumprogrammu.

   
   

   Šeit ir piemērs:

   
   

   2022. gadā MetaMask, iespējams, bloķēja lietotājus ar Venecuēlas un Irānas IP adresēm, lai tie nevarētu veikt darījumus blokķēdē.

   
   

   Tas bija iespējams, pateicoties centralizētajam RPC (Infura), ko izmantoja web3 seifs.

Centralizēto RPC mezglu kļūmju un ievainojamību gadījumu izpēte

Centralizētie RPC var izskatīties kā droši, taču tā nav. Tomēr, šauboties par to, apskatīsim dažus gadījumu izpēti par centralizēto RPC pagātnes kļūmēm.

Infuras lieta

Infura ir viens no pirmajiem blokķēdes aizmugures infrastruktūras kā pakalpojuma (IaaS) nodrošinātājiem tīmeklī 3, kas jums tika piedāvāts pēc vienprātības. Tiek apgalvots, ka infrastruktūra ir pieejama 99,9% darbības laikam un pieejama 16 blokķēdes EVM.

Līdz 2020. gadam Infura tika uzskatīta par varoni, jo tā ir viena no dApp izstrādes robežām un vadošā kriptovalūtu/blokķēdes masveida ieviešana.

2020. gada 11. novembrī Infura piedzīvoja pakalpojuma pārtraukumu kļūdas dēļ, kas ietekmēja Infura pārvaldīto GEth versiju.

Galvenā problēma šeit ir tāda, ka Infura sistēma nedarbojās un visi Infura infrastruktūras lietotāji nevarēja izveidot savienojumu ar blokķēdi. Serveru darbība tika traucēta kļūdas dēļ, un tika atklāts centralizācijas risks aiz decentralizēta tīkla.

Metamask, lielākais patērētājiem paredzētais Ethereum maks ar miljoniem aktīvo lietotāju, tika traucēts. Viss tāpēc, ka viņi paļaujas uz Infura, centralizētu RPC nodrošinātāju.

Centralizācijas problēmas tīkla jaunināšanas laikā

Tīkla jaunināšanas/hardforks laikā parasti rodas bažas par pakalpojuma kļūmēm, īpaši attiecībā uz dAapps, kas paļaujas uz centralizētiem infrastruktūras nodrošinātājiem. Šīs bažas ietver:

Viens kļūmes punkts, kas var traucēt darbības un izraisīt dīkstāvi.

Šeit ir daži pagātnes piemēri:

• Ethereum Istanbul hardfork laikā 2019. gadā daudzi centralizētie RPC nodrošinātāji piedzīvoja dīkstāves. Dažas no šīm dīkstāvēm ir saistītas ar tīkla jaunināšanu. DeFi Apps nevar apstrādāt darījumus, atstājot lietotājus neskaidrībā.

  
  

• Polygon Heimdall jaunināšanas laikā RPC pakalpojumu sniedzēji saskārās ar savienojamības problēmām un netika sinhronizēti ar blokķēdes tīklu. Lietotāji nevarēja piekļūt DeFi dApps vairākas stundas, tāpēc darījumi tika aizkavēti vai neizdevās.

Solana RPC pārslodze 2021. gadā

Solana 2021. gadā piedzīvoja daudz atslēgumu. Viens no bēdīgi slavenajiem atslēgumiem ir saistīts ar centralizēto RPC pakalpojumu pārslodzi pīķa periodos. Tā kā publiskie mezgli kļuva pārslogoti, lietotāji vairākas stundas nevarēja mijiedarboties ar Solana Blockchain, un tīkls saskārās ar pilna servisa apturēšanu uz daudzām stundām.

Šie facepalm gadījumi un neskaitāmi citi atklāj RPC nodrošinātāju nozīmi blokķēdes utilītprogrammā. Lai gan centralizētos pakalpojumu sniedzējus joprojām izmanto daudzas dApps (varbūt nezināšanas vai neapdomības dēļ), gadu gaitā ir bijušas alternatīvas.

Nākamajās sadaļās mēs iepazīstināsim jūs ar citām alternatīvām un to, kā tās ir bijušas lieliskas blokķēdes izstrādes iespējas.

DApp decentralizācija: labākās alternatīvas centralizētajiem RPC mezgliem

Pašmitinātie RPC mezgli

Kā norāda nosaukums, pašmitinātie RPC mezgli ir mezgli, kurus mitināt vai pārvaldīt savā aparatūrā vai mākoņa infrastruktūrā. Tā vietā, lai paļautos uz trešo pušu RPC nodrošinātājiem, varat mitināt savus RPC mezglus. Jūs iegūstat tiešu piekļuvi blokķēdes tīklam, apstipriniet darījumus, tieši pieprasāt blokķēdes datus un mijiedarbojaties ar dApps.

Pašmitināto RPC mezglu priekšrocības ietver:

1. Autonomija/vadība : mezglu palaišana nozīmē, ka jums ir pilnīga kontrole pār mezglu konfigurācijām. Varat pielāgot programmatūru atbilstoši savām vajadzībām, lietot atjauninājumus pēc saviem ieskatiem un pārvaldīt drošību.

2. Uzticamība : jums nav jāmeklē pakalpojumu pārtraukumi vai kļūmes pakalpojumu sniedzēja problēmu dēļ, kas ir izplatīti trešo pušu centralizētajos mezglos.

3. Tiešā piekļuve tīklam : mezglu darbība jūsu infrastruktūrā nozīmē, ka esat atbildīgs par viņu pakalpojumiem, jums ir zema latentuma piekļuve blokķēdes tīklam.

Lai gan pašizmitinātie mezgli izskatās uzticamāki nekā to centralizētās alternatīvas, tiem ir savi trūkumi. Un šeit viņi ir:

1. Augstas resursu prasības . RPC mezgla mitināšanai ir nepieciešama ievērojama vieta diskā, lai saglabātu blokķēdes vēsturi. Uzglabāšana, joslas platums un apstrādes jauda, kas nepieciešama RPC mezglu darbināšanai, var būt milzīga.

   
   

   Turklāt jums ir nepieciešama pastāvīga sinhronizācija ar blokķēdi, un tas var patērēt lielu joslas platumu, kas var būt milzīgs. Nepieciešamā apstrādes jauda var būt arī milzīga, īpaši, apstrādājot informāciju intensīvas satiksmes situācijās.

   
   

2. Pārvaldīšana ir dārga : šķiet, ka labāks risinājums ir iestatīt pašmitinātu mezglu, taču tā nav. Aparatūras izmaksas, darbības izmaksas un alternatīvās izmaksas var būt milzīgas.

   
   

   Darbības izmaksas, piemēram, elektrība, interneta joslas platums un mākoņpakalpojumu maksas (ja izmantojat mākoņa infrastruktūru), var būt milzīgas. Lai mezgls darbotos veiksmīgi, jums ir nepieciešama īpaša ekspertu komanda, kas ir gaidīšanas režīmā, lai novērstu jebkuru problēmu, pretējā gadījumā jūs riskējat ar pārtraukumiem vairākas stundas.

3. Sarežģīta iestatīšana un uzturēšana : jums ir nepieciešama laba izpratne par blokķēdes tehnoloģiju, servera pārvaldību un drošības paraugpraksi. Regulāra apkope, lai izvairītos no pārtraukumiem, piemēram, programmatūras atjauninājumiem, drošības ielāpiem un aparatūras jauninājumiem, lai mezgli darbotos pareizi.

4. Ierobežota mērogojamība un bez atbalsta daudzķēdei : atšķirībā no trešo pušu pakalpojumu sniedzējiem, kuriem ir modeļi šīs problēmas risināšanai, lai mijiedarbotos ar vairākām blokķēdēm, katrai blokķēdei ir jāmitina mezgli, kas var būt resursietilpīgi un neilgtspējīgi.

   
   

   Pašmitinātie mezgli nodrošina neatkarību, lielisku blokķēdes mijiedarbības kontroli un privātumu. Tie prasa ievērojamus resursus, zināšanas par tehnoloģijām un apkopi, kas var būt neiespējama pat spēcīgākajai blokķēdes izstrādes komandai.

Decentralizēti RPC mezgli

Decentralizētie RPC ir blokķēdes serveri, kas ļauj dApps decentralizēti sazināties ar blokķēdi. Decentralizētie RPC nodrošinātāji izplata savu infrastruktūru vairākos mezglos. Tas samazina vienu atteices punktu, uzlabo tīkla stabilitāti un mērogojamību, kā arī samazina latentumu.

Decentralizēto RPC mezglu priekšrocības salīdzinājumā ar citiem ietver

1. Izkliedētais tīkls : mezglu nodrošinātāju sadalītais tīkls strādā, lai apstrādātu pieprasījumus, atbildētu uz vaicājumiem un mijiedarbotos ar blokķēdi.

2. Darbības ir neuzticīgas : neuzticas vienam pakalpojumu sniedzējam. Pieprasījumi tiek izplatīti starp vairākiem pakalpojumu sniedzējiem, nodrošinot, ka nevienai pusei nav pilnīgas kontroles pār datiem vai veiktajiem pieprasījumiem.

3. Izturība pret cenzūru : tā kā RPC mezgli neatrodas tajā pašā jurisdikcijā, entītija/iestāde nevar viegli cenzēt, bloķēt vai ierobežot piekļuvi blokķēdei. Ja RPC infrastruktūra tiek izslēgta jurisdikcijas politiku dēļ, dApp pieprasījumus var novirzīt uz citiem RPC mezgliem no citas jurisdikcijas.

4. Kļūdu tolerance : RPC pakalpojumu decentralizētais modelis padara tos izturīgus pret pārtraukumiem. Ja mezgls tiek pazemināts, pakalpojumu aizstās cits. Tas samazina dīkstāves laiku un nodrošina pastāvīgu pieejamību.

Izaicinājumi ietver:

1. Latentums : ja tie nav pareizi iestatīti, decentralizētie RPC pakalpojumi var ieviest latentumu, jo tos var novirzīt caur vairākiem mezgliem. RPC mezglu decentralizācija var viegli kļūt lieka, un tā rezultātā datus var maršrutēt caur vairākiem serveriem, palielinot latentumu.

2. Drošība : tā kā mezglus pārvalda dažādas entītijas, mezgli var nebūt vienlīdz aizsargāti.

3. Vienprātība starp mezgliem : konsekventu un uzticamu datu nodrošināšana var būt sarežģīta. Ir jābūt ieviestiem mehānismiem, lai atklātu un mazinātu ļaunprātīgus/bojātus mezglus.

Decentralizēto RPC mezglu piemēri:

dRPC, kabatas tīkls un Ankr

Paraugprakse, lai izvairītos no centralizācijas riska dApp izstrādē

1. Mezglu nodrošinātāju dažādošana

Izvēloties decentralizētu RPC mezglu nodrošinātājus, piemēram, dRPC, varat izvairīties no centralizācijas riskiem. Decentralizētiem RPC nodrošinātājiem ir sistēmas, kas nodrošina mezglu darbību atbilstoši nepieciešamajām funkcijām, piemēram, slodzes balansētājiem, mezglu nodrošinātāju uzraudzībai un labu dalībnieku stimuliem.

Piemēram, dRPC nodrošina piekļuvi informācijas panelim, lai uzraudzītu jūsu mezgla infrastruktūras dažādošanu. Pat ja jums nav tiešas kontroles pār to, kādus mezglus izmantojat un cik tie ir decentralizēti, informācijas panelis ļauj redzēt, cik mezgli ir decentralizēti.

Iepriekšējā attēla apskate parādīja, ka savienojums ir decentralizēts starp četriem dažādiem RPC mezglu nodrošinātājiem ( Besked, bez drpc, drpc-public-multiregion, p2p-validator-free-optimism-free ). Decentralizācijas indekss 0,563 uzrādīja kumulatīvu decentralizācijas līmeņa skaitli, kur “viens” ir visvairāk decentralizēts un “nulle” ir visvairāk centralizētais.

2. Mezglu veselības uzraudzība un pārvaldība

Izstrādātājiem jāspēj pārraudzīt RPC mezglus, ko izmanto viņu dApp. Tas nodrošina dApp uzticamību. Lai gan jūs, iespējams, nevarat kontrolēt, kā RPC nodrošinātāji pārvalda savas sistēmas, decentralizētiem RPC nodrošinātājiem, piemēram, dRPC, ir sistēmas RPC mezglu nodrošinātāju uzraudzībai.

dRPC SaaS informācijas panelis sniedz piekļuvi visaptverošai analīzei, lai pārraudzītu, kā jūsu dApp mijiedarbojas ar infrastruktūru. Piemēram, dRPC informācijas panelī varat pārraudzīt kopējo dApp pieprasījumu skaitu atlasītajās dienās, pārraudzīt RPC mezglu decentralizāciju un pieprasījumu izplatīšanu, pamatojoties uz API atslēgu. Jums pat ir piekļuve kļūdu žurnālu pārraudzībai no informācijas paneļa.

Papildus dRPC analītikas informācijas panelim dRPC ir aizmugursistēmas mehānisms, lai uzraudzītu mezglu nodrošinātājus un novērstu to negodīgu darbību. Lasiet vairāk par šiem aizmugursistēmas mehānismiem šeit.

Secinājums

RPC mezgliem ir nozīmīga loma saziņas veicināšanā starp decentralizētu lietojumprogrammu un blokķēdi. Tomēr RPC centralizācija rada ievērojamu risku jūsu dApp un blokķēdes tīklam kopumā. Kā redzams iepriekšējās kļūmēs no iepriekš apspriestajiem gadījumu izpētēm, paļaušanās uz centralizētiem RPC nodrošinātājiem rada vienas kļūmes risku un var izraisīt kritisku tīmekļa 3 pakalpojumu pakalpojumu pārtraukšanu.

Izstrādātāji nav bez alternatīvām. Pašmitinātie un decentralizētie RPC piedāvā uzticamus risinājumus, kas var palīdzēt izveidot elastīgas lietojumprogrammas. Ietverot decentralizētus RPC, piemēram, dRPC , izstrādātāji var mazināt centralizācijas risku un izveidot jaudīgas, elastīgas, cenzūrai izturīgas un aizsargātas lietojumprogrammas.