Эфириума

Ethereum пашырае стандарты для аўдыту бяспекі смарт-кантрактаў

08/22/2022
Навіны Bitcoin Ethereum

Экасістэма Ethereum працягвае развівацца сведка шквал актыўнасці, у выніку якой прыватныя асобы і арганізацыі разгортваюць кантракты на токены, дадаюць ліквіднасць пулам і разгортваюць смарт-кантракты для падтрымкі шырокага спектру бізнес-мадэляў. Нягледзячы на ​​​​тое, што характэрна, гэты рост таксама быў прасякнуты эксплойтамі бяспекі, якія сыходзяць дэцэнтралізаваныя фінансы (DeFi) пратаколы, уразлівыя для ўзломаў і махлярства. 

Напрыклад, нядаўнія высновы кампаніі Chainalysis, якая займаецца крыптааналізам Паказваць што хакі, звязаныя з крыпта выраслі на 58.3% з пачатку года па ліпень 2022 г. Далей у справаздачы адзначаецца, што 1.9 мільярда долараў было страчана з-за ўзломаў за гэты перыяд часу — лічба, якая не ўключае Хак Nomad bridge коштам 190 мільёнаў долараў што адбылося 1 жніўня 2022 г.

Хоць адкрыты зыходны код можа быць выгадна для блокчейн-індустрыі, на жаль, яго могуць лёгка вывучыць кіберзлачынцы, якія шукаюць эксплойты. Аўдыты бяспекі для смарт-кантрактаў накіраваны на вырашэнне гэтых праблем, аднак у гэтай працэдуры адсутнічаюць галіновыя стандарты, што стварае складанасці.

Прамысловы стандарт для забеспячэння бяспекі смарт-кантрактаў 

Крыс Кордзі, старшыня рабочай групы па ўзроўнях бяспекі EthTrust tEnterprise Ethereum Alliance (EEA), сказаў Cointelegraph, што па меры росту блокчейн-індустрыі Ethereum расце і патрэба ў спелай структуры для ацэнкі бяспекі смарт-кантрактаў. 

Каб вырашыць гэтую праблему, Cordi разам з некалькімі прадстаўнікамі-членамі EEA, якія маюць вопыт аўдыту і бяспекі, дапамаглі стварыць рабочую групу па ўзроўнях бяспекі EthTrust у лістападзе 2020 г. З таго часу арганізацыя працуе над праектам дакумента спецыфікацыі смарт-кантракту або галіны стандарт, накіраваны на павышэнне бяспекі смарт-кантактаў.

Зусім нядаўна рабочая група абвясціла аб публікацыі спецыфікацыі EthTrust Security Levels Specification v1. Чалс Нэвіл, дырэктар тэхнічнай праграмы EEA, сказаў Cointelegraph, што гэтая спецыфікацыя апісвае ўразлівасці смарт-кантрактаў, якія належны аўдыт бяспекі патрабуе ў якасці мінімальнай меры якасці:

«Гэта актуальна для ўсіх платформаў смарт-кантрактаў на аснове EVM, дзе распрацоўшчыкі выкарыстоўваюць Solidity у якасці мовы кадавання. У нядаўнім аналізе Splunk гэта значна больш за 3/4 кантрактаў асноўнай сеткі. Але ёсць таксама прыватныя сеткі і праекты, якія заснаваныя на тэхналагічным стэку Ethereum, але працуюць у сваёй уласнай ланцужку. Гэтая спецыфікацыя такая ж карысная для іх, як і для карыстальнікаў асноўнай сеткі, каб дапамагчы забяспечыць іх працу».

З тэхнічнага пункту гледжання Нэвіл растлумачыў, што новая спецыфікацыя акрэслівае тры ўзроўні тэстаў, якія арганізацыі павінны ўлічваць пры правядзенні аўдыту бяспекі смарт-кантрактаў.

«Узровень [S] распрацаваны такім чынам, што ў большасці выпадкаў, калі агульныя функцыі Solidity выкарыстоўваюцца ў адпаведнасці з добра вядомымі шаблонамі, пратэставаны код можа быць сертыфікаваны аўтаматызаваным інструментам «статычнага аналізу», - сказаў ён.

Ён дадаў, што тэст узроўню [M] патрабуе больш строгага статычнага аналізу, адзначыўшы, што гэта ўключае ў сябе патрабаванні, у якіх чакаецца, што аўдытар-чалавек вызначыць, ці з'яўляецца выкарыстанне функцыі неабходным, і ці апраўдана сцвярджэнне аб уласцівасцях бяспекі кода.

Далей Нэвіл растлумачыў, што тэст на ўзровень [Q] забяспечвае аналіз бізнес-логікі, якую рэалізуе тэсціраваны код. «Гэта робіцца для таго, каб пераканацца, што код не дэманструе вядомых уразлівасцяў бяспекі, а таксама пераканацца, што ён правільна рэалізуе тое, што ў ім сцвярджаецца», — сказаў ён. Існуе таксама дадатковы тэст «рэкамендаваных добрых практык», які можа дапамагчы павысіць бяспеку смарт-кантрактаў. Нэвіл сказаў:

«Выкарыстанне найноўшага кампілятара з'яўляецца адным з «рэкамендаваных добрых практык». У большасці выпадкаў гэта даволі проста, але ёсць шмат прычын, па якіх кантракт мог не быць разгорнуты з апошняй версіяй. Іншыя добрыя практыкі ўключаюць паведамленне аб новых уразлівасцях, каб іх можна было ліквідаваць у абнаўленні спецыфікацыі, і напісанне чыстага, лёгкачытэльнага кода».

Увогуле, ва ўсёй спецыфікацыі ёсць 107 патрабаванняў. Па словах Нэвіла, каля 50 з іх з'яўляюцца патрабаваннямі ўзроўню [S], якія ўзнікаюць з-за памылак у sкампілятары olidity. 

Ці дапаможа галіновы стандарт арганізацыям і распрацоўшчыкам? 

Нэвіл адзначыў, што спецыфікацыя ўзроўняў бяспекі EthTrust у канчатковым рахунку накіравана на тое, каб дапамагчы аўдытарам прадэманстраваць кліентам, што яны працуюць на ўзроўні, адпаведным галіны. "Аўдытары могуць паказаць на гэты галіновы стандарт, каб усталяваць асноўны давер", - сказаў ён. 

Апошнія: Гульні Web3 утрымліваюць функцыі для стымулявання ўдзелу жанчын

Праліваючы святло на гэта, Жунхуэй Гу, генеральны дырэктар і сузаснавальнік фірмы па бяспецы блокчейнов CertiK, сказаў Cointelegraph, што такія стандарты дапамагаюць гарантаваць чаканыя працэсы і рэкамендацыі. Аднак ён адзначыў, што такія стандарты ні ў якім разе не з'яўляюцца «гумовым штампам», які паказвае, што разумны кантракт цалкам бяспечны:

«Важна разумець, што не ўсе аўдытары смарт-кантрактаў роўныя. Аўдыт смарт-кантракту пачынаецца з разумення і вопыту канкрэтнай экасістэмы, для якой правяраецца смарт-кантракт, а таксама выкарыстоўванага стэка тэхналогій і мовы кода. Не ўсе коды або ланцужкі аднолькавыя. Тут важны досвед для асвятлення і высноваў».

Улічваючы гэта, Гу лічыць, што кампаніі, якія жадаюць мець свае разумныя кантракты аўдытар павінен глядзець не толькі на сертыфікацыю, якую аўдытар сцвярджае, і прымаць пад увагу якасць, маштаб і рэпутацыю аўдытара. Паколькі гэтыя стандарты з'яўляюцца рэкамендацыямі, Гу адзначыў, што лічыць гэтую спецыфікацыю добрай адпраўной кропкай. 

З пункту гледжання распрацоўшчыка, гэтыя характарыстыкі могуць апынуцца надзвычай карыснымі. Марк Бейлін, сузаснавальнік Myco — новай сацыяльнай сеткі, заснаванай на блокчейне, — сказаў Cointelegraph, што гэтыя стандарты будуць неверагодна каштоўнымі, каб дапамагчы распрацоўшчыкам смарт-кантрактаў лепш зразумець, чаго чакаць ад аўдыту бяспекі. Ён сказау:

«У цяперашні час існуе мноства разрозненых рэсурсаў для бяспекі смарт-кантрактаў, але няма канкрэтнага зводу правілаў, якім аўдытары будуць прытрымлівацца пры ацэнцы бяспекі праекта. Выкарыстоўваючы гэтую спецыфікацыю, і аўдытары бяспекі, і іх кліенты могуць быць на той жа старонцы, якія патрабаванні бяспекі будуць правярацца».

Майкл Левэлен, распрацоўшчык і ўкладчык у спецыфікацыі, далей сказаў Cointelegraph, што гэтыя спецыфікацыі дапамагаюць, даючы кантрольны спіс вядомых праблем бяспекі, на якія трэба праверыць. «Многія распрацоўшчыкі Solidity не атрымалі нядаўняй фармальнай адукацыі або навучання па аспектах бяспекі распрацоўкі Solidity, але бяспека ўсё яшчэ чакаецца. Маючы такія спецыфікацыі, лягчэй зразумець, як пісаць код больш бяспечна», — сказаў ён.

Апошнія: Ethereum Merge прапануе майнерам і пулам майнинга зрабіць выбар

Левэлен таксама адзначыў, што большасць патрабаванняў да спецыфікацый напісаны ў простай форме, што робіць іх лёгкімі для разумення распрацоўшчыкам. Аднак ён пракаментаваў, што не заўсёды зразумела, чаму ўключана патрабаванне. «У некаторых ёсць спасылкі на знешнюю дакументацыю аб уразлівасці, а ў некаторых няма. Распрацоўшчыкам было б лягчэй зразумець, калі б яны мелі больш выразныя прыклады таго, як можа выглядаць сумяшчальны і несумяшчальны код».

Эвалюцыя стандартаў бяспекі смарт-кантрактаў 

Улічваючы ўсё, спецыфікацыя ўзроўню бяспекі дапамагае развіваць экасістэму Ethereum, усталёўваючы рэкамендацыі для аўдыту смарт-кантрактаў. Тым не менш, Нэвіл адзначыў, што найбольш складаным аспектам у далейшым з'яўляецца прадбачанне таго, як можа адбыцца эксплойт. Ён сказау: 

«Гэтая спецыфікацыя не вырашае гэтыя праблемы цалкам. Аднак спецыфікацыя вызначае пэўныя этапы, такія як дакументаванне архітэктуры і бізнес-логікі кантрактаў, якія важныя для правядзення дбайнага аўдыту бяспекі».

Гу таксама лічыць, што розныя сеткі пачнуць распрацоўваць падобныя стандарты па меры прасоўвання Web3. Напрыклад, некаторыя распрацоўшчыкі ў індустрыі Ethereum прыдумляюць уласныя патрабаванні да смарт-кантрактаў, каб дапамагчы іншым. Напрыклад, Сэмюэль Кардзіла, дырэктар па тэхналогіях RTFKT, нядаўна напісаў у твітэры, што ён стварыў сістэму для распрацоўшчыкаў, каб публічна ацэньваць разумныя кантракты на аснове добрых і дрэнных элементаў з пункту гледжання распрацоўкі: 

Нягледзячы на ​​тое, што ўсё гэта крок у правільным кірунку, Гу адзначыў, што для шырокага прыняцця стандартаў патрабуецца час. Больш за тое, Нэвіл растлумачыў, што бяспека ніколі не бывае статычнай. Пры гэтым ён растлумачыў, што прыватныя асобы могуць накіраваць пытанні рабочай групе, якая пісала спецыфікацыю. «Мы прымем да ўвагі гэтыя водгукі, а таксама паглядзім, якія дыскусіі ідуць у шырокай грамадскай прасторы, таму што мы чакаем абнаўлення спецыфікацыі», — сказаў Нэвіл. Ён дадаў, што новая версія спецыфікацыі будзе падрыхтавана на працягу шасці-васемнаццаці месяцаў.