Nutikate lepingute uuendamine proksi-mustrite abil: põhjalik juhend

Arukad lepingud on programmeeritud nii, et need on pärast blockchain-võrgustikku paigaldamist püsivad ja muutumatud. See muutumatus on turvalisuse ja usalduse allikas, kuid see tekitab ka probleeme, kui arendajad peavad parandama vigu või lisama uusi funktsioone.

Kui muudatused on vajalikud, peavad arendajad välja andma täiesti uue lepingu, millel on teine aadress. Kuigi selline püsivus on suurepärane turvalisuse seisukohast, võib see olla piirav olukordades, kus midagi läheb valesti või vajab parandamist.

Ajalugu on näidanud, et nutikate lepingute nõrkused võivad põhjustada katastroofilisi rahalisi kaotusi. Üks konkreetne näide on suur intsident, mille käigus kaotati miljonid dollarid ärakasutatava vea tõttu.

Need juhtumid rõhutavad, kui oluline on suuta lahendada turvaprobleeme ja vigu pärast rakendamist. Lepingute uuendatavaks muutmine võimaldab probleeme parandada ilma olemasolevat seisundit ja kasutajakogemust kaotamata, mis on nutikate lepingute uuendatavuse oluline aspekt.

See võime võib olla oluline, et vältida märkimisväärseid kahjusid ja säilitada süsteemi terviklikkus.

Proxy-mudel on struktuuriline disainimudel, kus üks leping rakendab teise lepingu liidest. Sellel arhitektuuril on kaks peamist osa: proxy-leping ja rakendusleping.

Selle asemel, et kasutaja suhtleks otse rakenduslepinguga, suhtleb ta proxy-lepinguga, mis edastab taotlused vastavalt.

Selles seadistuses ei muudeta pärast kasutuselevõttu nii proksilepingut kui ka rakenduslepingut. Uuendatavus saavutatakse aga sellega, et proksil on võimalik aja jooksul viidata erinevatele rakenduslepingutele.

See tähendab, et kasutajad saavad jätkata sama aadressi ja liidese kasutamist, samal ajal kui aluseks oleva funktsionaalsuse uuendatakse. Kasutaja seisukohast jätkab rakendus täiuslikult töötamist, kuigi tagapõhja loogika muutub.

Proxy-leping vastutab kasutajate suhtluse ja kõigi andmete salvestamise eest. See säilitab rakenduslepingu aadressi spetsiaalses salvestuspaigas.

Kui kasutajad kutsuvad proksilepingu funktsioone, kutsutakse varufunktsioon. Järgmine funktsioon kasutab delegatecall ethereum-mehhanismi, et kutsuda koodi rakenduslepingust, kuid kõik seisundi muutused salvestatakse proksilepingu salvestusse.

Läbipaistev proksi mudel

Läbipaistev proksi mudel paigutab uuendamise funktsionaalsuse proksi lepingusse. Proksil on meetod upgradeTo, mida kasutatakse rakenduslepingule viitava aadressi uuendamiseks.

See tekitab potentsiaalse probleemi: kui nii proxy- kui ka rakendamislepingud sisaldavad meetodit upgradeTo, ei ole selge, kumba neist tuleks kasutada, kui kasutaja käivitab selle funktsiooni.

Selle ebaselguse lahendamiseks on välja töötatud lahendus, mille puhul otsus selle kohta, kellele delegeerida, põhineb sellel, kes lepingut sõlmib.

Kui helistaja on volituse haldaja, käsitletakse kõnesid volituse lepingu enda poolt. Muul juhul delegeeritakse kõned rakenduslepingule. Selline lähenemine tagab, et funktsioonid täidetakse selgelt ja et haldus- ja tavakasutaja toimingud ei segune omavahel.

Universaalne uuendatav proksi standard

Universal Upgradeable Proxy Standard kasutab teistsugust lähenemisviisi, paigutades uuendamise funktsionaalsuse rakendamislepingusse, mitte proksisse. Proksi delegeerib kõik kutsed rakendamislepingule, millel on meetod upgradeTo, mis viitab uuematele versioonidele.

See mudel annab arendajatele suurema kontrolli uuendamise üle. Kui arendaja otsustab tulevastes versioonides meetodit upgradeTo enam mitte kasutada, on leping nüüd püsivalt muutumatu ja seda ei saa enam uuendada.

See võib olla abiks, kui leping on hästi testitud ja arendusmeeskond soovib selle lõplikus vormis külmutada.

Kuna uuendamise loogika on rakendamislepingus, ei ole vaja, et proksi varufunktsioon kontrolliks enne kõnede delegeerimist, kas helistaja on administraator.

See muudab mustri gaasitõhusamaks kui läbipaistev proksi muster. Potentsiaalne nimede konflikt on samuti kõrvaldatud, kuna meetod upgradeTo eksisteerib ainult rakendamislepingus.

Beacon Proxy Pattern

Beacon Proxy Pattern tutvustab kolme komponendiga arhitektuuri: proxy leping, beacon leping ja rakendusleping. Rakenduse aadressi salvestamise asemel salvestab proxy beacon lepingu aadressi.

Beacon-leping omakorda sisaldab rakenduslepingu aadressi.

Kui kasutaja kutsub proksi, saab see esmalt beacon-lepingu aadressi ja seejärel kutsub beaconi, et saada rakenduslepingu aadress. Lõpuks jätab ta rakenduslepingu kutsumise.

See lisanduv kaudne kiht on mõeldud väga spetsiifiliseks otstarbeks.

Diamond Proxy Pattern

Diamond Proxy Pattern lahendab nutikate lepingute suuruspiirangu probleemi, mis on tavaliselt piiratud umbes 24 kilobaidiga. See muster jagab funktsionaalsuse mitmeks väiksemaks lepinguks, mida nimetatakse facetideks.

Proksileping säilitab seose funktsioonivalijate ja nende funktsioone sisaldavate aspektide aadresside vahel.

Kui proksil kutsutakse funktsiooni, kasutab see funktsioonivalijat, et otsida funktsiooni sisaldav facet ja delegeerida funktsioonikõne sobivale facetile.

Uuendused tehakse proxy facettide aadresside muutmisega. See mudel võimaldab palju suuremat funktsionaalsust, jagades funktsionaalsuse mitme lepingu vahel, kusjuures iga facett jääb suuruspiirangu alla.

Igal proksimudelil on erinevad omadused, mis muudavad selle sobivaks erinevate kasutusjuhtude jaoks. Kõik neli mudelit vajavad proksilepingut ja kasutavad delegeerimist, et edastada kõned rakenduslepingutele.

Läbipaistev proksi mudel paigutab uuendamise funktsioonid proksi lepingusse ja UUPS paigutab uuendamise funktsioonid rakenduslepingusse. Beacon mudel paigutab uuendamise funktsiooni oma beacon lepingusse ja Diamond mudel paigutab uuendamise funktsiooni tavaliselt rakenduslepingusse, kuid see ei ole rangelt määratletud.

Muutumatuse osas võivad UUPS- ja Diamond-mustrid muuta lepingud püsivalt muutumatuks, eemaldades tulevastest versioonidest uuendamise funktsiooni. Transparent- ja Beacon-mustrid ei paku sellist paindlikkust.

Mitme proksi puhul on Beacon-mudelil selge eelis. Transparent-, UUPS- ja Diamond-mudelite puhul tuleb iga proksi uue rakenduse juurutamisel eraldi muuta.

Beacon-mustri puhul tuleb uuendada ainult beacon-leping ja kõik proksid hakkavad automaatselt kasutama uut rakendust.

Kütusesäästlikkus on iga mustri puhul erinev. Läbipaistev muster nõuab, et enne iga delegeerimist kontrollitaks, kas helistaja on administraator, mistõttu on see kulukam.

UUPS on tõhusam, kuna ei vaja seda kontrolli. Kõikidel mustritel, välja arvatud Diamond, on lisakulud täiendavate otsingute eest.

Kõik mustrid, välja arvatud Diamond, on piiratud 24 kilobaidiga lepingut kohta. Diamond-mustri puhul võib iga tahk olla kuni 24 kilobaidi suurune, mis võimaldab mitme tahu puhul saavutada palju suurema kogufunktsionaalsuse.

Salvestusruumi kokkupõrke probleemid

Proxy-mustrite rakendamisel on tõsine oht, et tekivad salvestuskonfliktid. Lepingumuutujad salvestatakse kindlatesse salvestuskohtadesse ja kui proxy-lepingu muutujad ja rakenduslepingu muutujad salvestatakse samadesse salvestuskohtadesse, hakkavad need üksteist segama.

Lisaks, kui rakenduslepingu muutujate järjekord muutub ühest versioonist teise, võivad salvestuskohtade määramised muutuda, põhjustades andmete rikkumist.

Initsialiseerimata rakendamislepingud

Rakendamislepingud tuleb algatada täpselt üks kord algatamisfunktsiooni abil, mis on sarnane traditsiooniliste lepingute konstruktoriga.

Arendajad unustavad ka rakenduse algseadistamise või ei lisa kaitset, mis takistaks algseadistamise funktsiooni mitmekordset käivitamist.

Sellisel juhul võivad ründajad ise käivitada algseadistamise funktsiooni ja potentsiaalselt võtta kontrolli lepingu üle või manipuleerida selle seisundit.

Reaalsed turvalisusjuhtumid

Andmete eraldamise muster

Proxy-mustrite alternatiiviks on andmete eraldamise lähenemisviis. See lähenemisviis põhineb eraldi lepingute kasutamisel salvestamise ja loogika jaoks. Loogikaleping suhtleb salvestuslepinguga, et lugeda või uuendada andmeid.

Kuigi loogilist lepingut on võimalik asendada uute versioonidega, on salvestusleping fikseeritud ja muutumatu. See pakub teistsugust uuendatavuse mudelit, mis võib mõnel juhul olla sobiv.

Verifitseerimise kihid

Ükski tavaliselt kasutatavatest proxy-mustritest ei sisalda mehhanisme, mis võimaldaksid enne uuenduse tegemist kontrollida uue rakendamislepingu kehtivust.

Uued versioonid peavad sisaldama kogu vajalikku äriloogikat, varufunktsioone ja muid olulisi komponente.

Seda on võimalik saavutada, lisades kontrollikihti, mis asub proksikihti, äriloogika kihti ja salvestuskihti kõrval. See lisakiht tagab, et uuendused vastavad teatud kriteeriumidele enne, kui neid lubatakse teostada.

Arendajad, kes kujundavad uuendatavaid lepinguid, peaksid järgima mõningaid olulisi suuniseid, et tagada turvalisus ja usaldusväärsus:

• •Selle asemel tugine hästi testitud rakendustele hästi testitud raamatukogudest, mis on põhjalikult läbi vaadatud ja auditeeritud
• •Veenduge alati, et rakendamislepingud on korrektselt initsialiseeritud ja et initsialiseerimisfunktsioone saab kutsuda ainult üks kord.
• •Ära kunagi initsialiseeri seisundimuutujaid nende deklaratsioonis või konstruktoris, kasuta initsialiseerimisfunktsiooni kõigi seisundite seadistamiseks
• •Ära muuda riiklike muutujate järjekorda ega tüüpe, kui lood uusi versioone rakenduslepingutest.
• •Kui on vaja uusi muutujaid, siis tuleks need lisada pärast kõiki olemasolevaid muutujaid
• •Diamond-mustri rakenduste puhul kasutage selle mustri jaoks optimeeritud spetsiaalseid salvestusmeetodeid
• •UUPS-meetod on võimaluse korral eelistatavam kui läbipaistev proksi-mudel, kuna see nõuab rutiinsete toimingute jaoks vähem gaasi
• •Veenduge, et proxy administraatori konto on väga turvaline, kuna see konto kontrollib uuendamisprotsessi ja on kriitiline turvapunkt.
• •Lõpuks laske kõik lepingud enne kasutuselevõttu professionaalselt üle vaadata kogenud nutikate lepingute turvalisuse spetsialistidel.

Proxy-mustrid pakuvad võimsa mehhanismi nutikate lepingute uuendamiseks, säilitades samal ajal sama aadressi ja seisundi. Proxy-leping kasutab delegateCall-i, et edastada täitmine rakenduslepingutele, nii et alusloogikat saab muuta ilma kasutajaliidest muutmata.

Kui aga uuendatavad lepingud ei ole nõuetekohaselt rakendatud, võivad need tekitada tõsiseid turvaauke.

Arendajad peavad hoolikalt kaaluma erinevate proksimustrite vahelisi kompromisse, järgima kehtivaid parimaid tavasid ja tagama, et läbi viiakse nõuetekohased turvaauditid, et luua usaldusväärsed ja turvalised uuendatavad nutikad lepingud.

Proxy-mustrite võrdlemisel tuleb arvesse võtta mitmeid tegureid:

Musterite valiku peamised kaalutlused:

• •Kõik mustrid vajavad proksilepingut ja kasutavad delegeerimist kõnede edastamiseks
• •Läbipaistva proksi mudelit kasutatakse uuendamise funktsioonide salvestamiseks proksi lepingus endas
• •UUPS lisab uuendamise funktsioonid rakendamislepingusse
• •Beacon-mudel kasutab uuenduste jaoks eraldi beacon-lepingut
• •Diamond-mudelis paigutatakse uuendamise funktsioonid tavaliselt rakenduslepingutesse, kuid spetsifikatsioon ei nõua seda.
• •Ainult UUPS- ja Diamond-mustritel on võimalus muuta lepingud püsivalt muutumatuks, jättes tulevastest versioonidest välja uuendamise funktsiooni
• •Beacon-mudel on ideaalne, kui teil on mitu proksit, mida tuleb samaaegselt uuendada, kuna uuendada tuleb ainult beacon, mitte iga proksi eraldi.
• •Transparent-, UUPS- ja Beacon-mustrite maksimaalne lepingumahutavus on 24 kilobaiti
• •Diamond-mustri puhul toetab iga tahk kuni 24 kilobaidi suurust, mistõttu on võimalik toetada palju suuremat funktsionaalsust
• •Kõik mustrid on keskmise rakendamise keerukusega ja Transparent-, UUPS- ja Beacon-mustrite jaoks on olemas hästi väljakujunenud raamatukogud