Вашата dApp е ранлива - Еве што ја предизвикува

RPC (Remote Procedure Call) Јазлите се критични компоненти на блокчејн инфраструктурата. Тие се справуваат со комуникацијата помеѓу децентрализираната непроменлива книга и апликациите од предниот дел. Овие посреднички инфраструктури делуваат како гласник кој ги олеснува барањата и одговорите помеѓу јазлите и услугите изградени на блокчејн.

RPC јазлите се исто како Поштенската служба на Соединетите Американски Држави (USPS), која го олеснува движењето на информациите од dApp до блокчејнот и назад. Исто како што се потпирате на поштенската услуга за да ја добиете вашата пошта од една до друга точка, така и dApps зависат од RPC јазлите за пристап до блокчејнот. И без овие јазли, децентрализираните апликации ќе се борат да функционираат.

RPC јазлите значително еволуираа во последните 10 години, но централизацијата на инфраструктурата воведе скриена ранливост. Оваа статија има за цел да ја истражи улогата на RPC јазлите, опасноста од централизација и алтернативите што можат да ги заштитат вашите dApps од пропусти.

Еволуција на RPC инфраструктура

Идејата за повици за далечинска процедура датира од 1970-тите кога компјутерските научници бараа начини да комуницираат помеѓу различни машини за да ги направат дистрибуираните компјутери транспарентни за програмерите.

Во 1980-тите, првиот RPC беше развиен од Sun Microsystem наречен Network File System. Sun Microsystem го разви протоколот Open Network Computing RPC и ова стана стандард за комуникација помеѓу различни програми на мрежата.

Сепак, во раните 1990-ти, Мајкрософт ја разви и имплементира својата верзија на RPC за да овозможи комуникација помеѓу процесите на системи базирани на Windows. Во раните 2000-ти, беше претставен JSON RPC, кој користи JSON за кодирање на податоци. Стана озлогласен меѓу програмерите и програмерите поради леснотијата за пренос на стандардизирани податоци.

Во текот на изминатата деценија, dApps станаа важен дел од блокчејн индустријата и RPC беше совршена инфраструктура потребна за комплетирање на лавиринтот.

Зошто?

1. Неговата способност да прави далечински повик на функција на друг компјутер како локален функциски повик е совршена за архитектурата на блокчејн.
2. Нејзината бездржавност и лесна тежина го зајакнуваат блокчејнот и се корисни во ситуации со пропусниот опсег и пресметување на ограничувања.

Поради придобивките, RPC брзо стана широко користен. RPC беше предложен да им овозможи на апликациите напишани на различни јазици да се поврзуваат и да комуницираат. Основната идеја зад RPC е да се направи далечински функциски повик на друг компјутер или сервер како да е локален функциски повик.

Со текот на годините, постоеја три главни типа на RPC (централизирани, децентрализирани и самодомаќини) и секој е единствен на свој начин.

Опасноста од централизирани RPC јазли

Централизираните RPC јазли се јазли управувани и контролирани од еден ентитет. Овие централизирани јазли имаат модели кои личат на веб2 облак хостинг услуги како AWS (Amazon Web Services), Microsoft Azure и Google Cloud Protocol (GCP).

Иако овие централизирани веб3 RPC провајдери одржуваат јазли инфраструктура за децентрализирани апликации, длабокиот поглед во системот откри колку се централизирани. Овие даватели на веб3 инфраструктура иронично, исто така, зависат од инфраструктурата на серверот за хостирање на облак web2 за одржување на нивните услуги.

Значи, кога овие даватели на облак ќе доживеат прекини, веб3 услугите, кои треба да бидат децентрализирани, исто така доживуваат прекини. Еве примери на централизирани RPC јазли: Alchemy, Infura, Quicknode итн.

Ајде да ги провериме опасностите што ги претставуваат централизираните RPC јазли за веб3 инфраструктурата.

1. Единечна точка на дефект: Имањето единствена точка на дефект секогаш влијае на доверливоста на системот. Еден сервер или мрежа на сервери контролирани од еден ентитет ќе воведат критична точка што може да доведе до неуспех на вашата dApp.

   
   

   

   
   

   Ако серверот низ кој се насочуваат податоците не успее, врската помеѓу блокчејнот и dApp станува скршена и системот откажува. Една точка на неуспех ќе влијае на веродостојноста на системот, особено во апликациите поврзани со финансии, како што се DeFi платформите.

2. Проблем со приспособливост : Централизираните RPC јазли можат да станат тесни грла во време на голем сообраќај и тоа ја ограничува приспособливоста на dApp. Кога мрежата е пренатрупана поради потпирање на еден јазол, тоа влијае на ефикасноста на dApps и ја зголемува латентноста, што влијае на корисниците.

   
   

   Бидејќи тоа е централизиран систем, зголемувањето на приспособливоста на dApp е невозможно.

3. Безбедносен ризик и ранливост: централизиран или посветен јазол е отворен за ранливост и може да биде лесна цел за бескрупулозните поединци. Податоците може да бидат изложени и манипулирани и на крајот да влијаат на донесувањето одлуки во dApps.

   
   

   Згора на тоа, координираниот напад врз давателот може лесно да се имплементира, што на крајот ќе ги открие корисниците на Dapp. Еден ентитет може да биде принуден од владините агенции да затвори апликација.

   
   

   Еве еден пример:

   
   

   Во 2022 година, MetaMask наводно блокирал корисници со венецуелска и иранска IP адреси да вршат трансакции на блокчејнот.

   
   

   Ова беше можно поради централизираниот RPC (Infura) што го користи веб3 паричникот.

Студии на случај на централизирани RPC јазли неуспеси и ранливости

Централизираниот RPC може да изгледа како да е безбеден, но не е. Сепак, во сомнеж за ова, ајде да провериме некои студии на случај за минати неуспеси на централизирани RPC.

Случајот Инфура

Infura е еден од првите даватели на блокчејн Backend Infrastructure as a Service (IaaS) во web3, донесен до вас со консензус. Се тврди дека инфраструктурата е достапна за 99,9% време на работа и достапна за 16 блокчејн EVM.

До 2020 година, Infura се сметаше за херој, како еден од границите за развојот на dApp и предводник на масовното усвојување на крипто/блокчејн.

На 11 ноември 2020 година, Infura доживеа прекин на услугата поради грешка што влијаеше на верзијата на GEth управувана од Infura.

Главното прашање овде е што системот Infura беше во прекин и сите корисници на инфраструктурата на Infura не можеа да се поврзат со блокчејнот. Серверите беа прекинати поради грешка и беше откриен ризикот од централизација зад децентрализирана мрежа.

Metamask, најголемиот паричник Ethereum со кои се соочува потрошувачот со милиони активни корисници, беше нарушен. Сите затоа што се потпираат на Infura, централизиран RPC провајдер.

Загриженост за централизација при надградба на мрежата

За време на мрежните надградби/хардфорки, обично постои загриженост за неуспеси на услугите, особено во врска со dAapps кои се потпираат на централизирани даватели на инфраструктура. Овие грижи вклучуваат:

Единствена точка на неуспех, што може да ги наруши активностите и да доведе до прекини.

Еве неколку примери од минатото:

• За време нахардфорк Ethereum Istanbul во 2019 година , многу централизирани провајдери на RPC доживеаја прекини. Некои од овие прекини се резултат на тоа што мрежата поминува низ надградби. Дефи апликациите не можат да обработуваат трансакции, оставајќи ги корисниците во неизвесност.

  
  

• За време на надградбата на Polygon Heimdall , давателите на услуги на RPC се соочија со проблеми со поврзувањето и не беа синхронизирани со блокчејн мрежата. Корисниците не можеа да пристапат до DeFi dApps неколку часа, па трансакциите беа одложени или неуспешни.

Солана RPC Преоптоварување во 2021 година

Солана доживеа многу прекини во 2021 година. Еден од неславните прекини е предизвикан од преоптоварувањето на централизираните RPC услуги за време на шпицовите периоди. Бидејќи јавните јазли станаа преоптоварени, корисниците не можеа да комуницираат со Solana Blockchain неколку часа и мрежата се соочи со целосно прекинување на услугата многу часови.

Овие случаи на дланки за лице и безброј други ја откриваат важноста на давателите на RPC за блокчејн алатката. Додека централизираните провајдери сè уште се користат од многу dApps (можеби од незнаење или непромисленост), со текот на годините имаше алтернативи.

Во следните делови, ќе ве водиме низ другите алтернативи и како тие биле одлична опција за развој на блокчејн.

Децентрализација на вашата DApp: Топ алтернативи за централизирани RPC јазли

Само-домаќини RPC јазли

Како што имплицира неговото име, само-домаќините RPC јазли се јазли што ги хостирате или управувате на вашиот сопствен хардвер или облак инфраструктура. Наместо да се потпирате на трети лица RPC провајдери, можете да ги хостирате вашите сопствени RPC јазли. Добивате директен пристап до блокчејн мрежата, ги потврдувате трансакциите, директно барате податоци за блокчејн и комуницирате со dApps.

Придобивките од самодомаќините RPC јазли вклучуваат:

1. Автономија/Контрола : извршувањето на вашите јазли значи дека имате целосна контрола врз конфигурациите на јазлите. Можете да го приспособите софтверот за да одговара на вашите потреби, да применувате ажурирања по ваша дискреција и да управувате со безбедноста.

2. Доверливост : не мора да барате прекини на услугата или неуспех поради проблеми со давателот, вообичаени за централизираните јазли од трета страна.

3. Директен пристап до мрежата : пуштањето јазли на вашата инфраструктура значи дека сте одговорни за нивните услуги, имате ниска латентност на пристап до блокчејн мрежата.

Додека јазлите кои сами се вдомуваат изгледаат посигурни од нивните централизирани алтернативи, тие имаат свои недостатоци. И еве ги:

1. Високи барања за ресурси . Хостирањето на јазол RPC бара значителен простор на дискот за складирање на историјата на блокчејн. Складирањето, пропусниот опсег и моќта за процесирање потребни за извршување на RPC јазлите може да бидат огромни.

   
   

   Покрај тоа, потребна ви е постојана синхронизација со блокчејнот, а тоа може да потроши голема количина на пропусен опсег што може да биде огромно. Потребната процесорска моќ, исто така, може да биде огромна, особено кога се обработуваат информации за време на ситуации со голем сообраќај.

   
   

2. Скапо е да се управува : поставувањето на јазли кои сами се одржуваат се чини дека е подобра опција, но не е. Хардверските трошоци, оперативните трошоци и опортунитетните трошоци можат да бидат огромни.

   
   

   Оперативните трошоци како што се струјата, интернет пропусниот опсег и надоместоците за облак услуги (ако користите облак инфраструктура) може да бидат огромни. За да извршите успешен јазол, потребен ви е посветен тим од експерти кои ќе бидат во состојба на подготвеност за да го решат секој проблем или ризикувате прекини на неколку часа.

3. Комплексно поставување и одржување : Потребно ви е солидно разбирање на технологијата на блокчејн, управувањето со серверот и најдобрите безбедносни практики. Редовно одржување за да се избегнат прекини како што се ажурирања на софтверот, безбедносни закрпи и надградби на хардверот за да се одржуваат јазлите да работат правилно.

4. Ограничена приспособливост и без поддршка за повеќе синџири : за разлика од трети лица провајдери со модели за справување со овој проблем, за да комуницирате со повеќе блокчејн, треба да ги хостирате јазлите за секој блокчејн што може да биде интензивно за ресурси и неодржливо.

   
   

   Јазлите што се одржуваат сами обезбедуваат независност, одлична контрола на интеракцијата на блокчејн и приватност. Тие бараат значителни ресурси, технолошка експертиза и одржување, што може да биде невозможно дури и за најсилниот тим за развој на блокчејн на располагање.

Децентрализирани RPC јазли

Децентрализираните RPC се блокчејн сервери кои им овозможуваат на dApps да комуницираат со блокчејнот на децентрализиран начин. Децентрализираните провајдери на RPC ја дистрибуираат својата инфраструктура низ повеќе јазли. Ова ја намалува една точка на неуспех, ја подобрува стабилноста и приспособливоста на мрежата и ја намалува латентноста.

Придобивките од децентрализираните RPC јазли во однос на другите вклучуваат

1. Дистрибуирана мрежа : дистрибуираната мрежа на даватели на јазли работи на обработка на барања, одговарање на прашања и интеракција со блокчејнот.

2. Операциите се неверодостојни : Нема доверба во ниту еден провајдер. Барањата се дистрибуираат низ повеќе провајдери со што се обезбедува дека ниту една страна нема целосна контрола врз податоците или поднесените барања.

3. Отпорност на цензура : Бидејќи јазлите на RPC не се наоѓаат во истата јурисдикција, ентитетот/органитетот не може лесно да го цензурира, блокира или ограничи пристапот до блокчејнот. Ако RPC инфраструктура се исклучи поради политики од јурисдикција, барањата на dApp може да се пренасочат до други RPC јазли од друга јурисдикција.

4. Толеранција на грешки : Децентрализираниот модел на RPC услуги ги прави отпорни на прекини. Ако некој јазол е срушен, друг ќе ја замени услугата. Ова го намалува времето на застој и обезбедува постојана достапност.

Предизвиците вклучуваат:

1. Латентност : Ако не се правилно поставени, децентрализираните RPC услуги може да воведат латентност бидејќи може да се пренасочат низ неколку јазли. Децентрализацијата на јазлите RPC лесно може да стане непотребна, и како резултат на тоа, податоците може да се пренасочат низ повеќе сервери, зголемувајќи ја латентноста.

2. Безбедност : бидејќи јазлите се управувани од различни ентитети, јазлите може да не се подеднакво обезбедени.

3. Консензус меѓу јазлите : обезбедувањето конзистентни и сигурни податоци може да биде предизвик. Треба да постојат механизми за откривање и ублажување на малициозни/неисправни јазли.

Примери на децентрализирани RPC јазли вклучуваат:

dRPC, Pocket мрежа и Ankr

Најдобри практики за да се избегне ризикот од централизација во развојот на dApp

1. Диверзификација на даватели на јазли

Со изборот на децентрализирани даватели на јазли RPC како dRPC, можете да избегнете ризици од централизација. Децентрализираните провајдери на RPC имаат системи за да обезбедат јазлите да работат како што се потребни карактеристики како што се балансирачи на оптоварување, следење на давателот на јазли и стимулации за добри актери.

На пример, dRPC ви обезбедува пристап до контролната табла за следење на диверзификацијата на вашата јазолна инфраструктура. Иако немате директна контрола врз тоа кои јазли ги користите и колку е децентрализирано, контролната табла ви овозможува да видите колку се децентрализирани јазлите.

Погледот на горната слика покажа дека врската е децентрализирана помеѓу четири различни даватели на јазли RPC ( Besked, drpc-free, drpc-public-multiregion, p2p-validator-optimism-free ). Индексот на децентрализација од 0,563 покажа кумулативен број на нивото на децентрализација при што „еден“ е најдецентрализиран и „нула“ најцентрализиран.

2. Следење и управување со здравјето на јазлите

Програмерите треба да бидат способни да ги следат RPC јазлите што ги користи нивната dApp. Ова ја осигурува веродостојноста на dApp. Иако можеби нема да можете да контролирате како провајдерите на RPC управуваат со нивните системи, децентрализираните провајдери на RPC како dRPC имаат системи за следење на давателите на јазли RPC.

Контролната табла SaaS на dRPC ви дава пристап до сеопфатна аналитика за да следите како вашата dApp комуницира со инфраструктурата. Во контролната табла dRPC, на пример, можете да го следите вкупниот број на барања направени од вашиот dApp во одредени денови, да ја следите децентрализацијата на јазолот RPC и да барате дистрибуција врз основа на клучот API. Имате пристап дури и до евиденција на грешки од контролната табла.

Освен контролната табла за аналитика на dRPC, dRPC има механизам за заднина за следење на давателите на јазли и спречување на нив да одат непријателски. Прочитајте повеќе за овие задни механизми овде.

Заклучок

RPC јазлите играат значајна улога во олеснувањето на комуникацијата помеѓу децентрализираната апликација и блокчејнот. Сепак, централизацијата на RPC претставува значителен ризик за вашиот dApp и блокчејн мрежата воопшто. Како што се гледа во претходните неуспеси од студиите на случај дискутирани погоре, потпирањето на централизирани провајдери на RPC претставува ризик од една точка на неуспех и може да доведе до критично нарушување на услугата на веб3 услугите.

Програмерите не се без алтернативи. Самодомаќините и децентрализираните RPC нудат сигурни решенија кои можат да помогнат во изградбата на еластични апликации. Со прифаќање на децентрализирани RPC како dRPC , програмерите можат да го намалат ризикот од централизација и да изградат моќни, еластични, отпорни на цензура и обезбедени апликации.