Solidity õpetus gaasi efektiivsuse kohta: 12 nõuannet, kuidas toime tulla tõusvate tasudega baas- ja muudes L2 ahelates

Nende piirangute ületamiseks on välja töötatud mitu 2. kihi lahendust, nagu Base, mida kontrollitakse skaleeritavuse ja vähenenud gaasikulude abil. Kuigi L2-lahendused pakuvad Ethereumi põhivõrgu suhtes märkimisväärset tasude alandamist, ei saa nutikate lepingute arendajad oma arendustöös gaasi optimeerimist ignoreerida.

Käesolev juhend püüab konsolideerida kasutajakogemust ja luua konkurentsivõimelisemaid, detsentraliseeritud rakendusi, kasutades selleks täiustatud strateegiaid, mis vähendavad testitavate nutilepingute gaasikulusid. Esitatud näited on simuleeritud lihtsate lepingutega ja võtavad peamiselt arvesse jooksva gaasi hindu, kuna rakendamise kulud erinevad oluliselt sõltuvalt lepingu suurusest.

Gaasi optimeerimine on oluline arendajatele, kasutajatele ja projekti pikaajalisele edule. Nutikate lepingute gaasi majanduslik kasutamine tagab, et protokollid on kulutõhusamad ja skaleeritavamad ning vähem altis turvaohtudele, nagu teenuse keelamise rünnakud.

Gaasi optimeerimine võimaldab nutikatele lepingutele, protokollidele ja projektidele töötada ülekoormatud võrkudes ning muudab need odavaks ja tõhusaks. Lepingu koodi täiustamisega on võimalik avastada võimalikke nõrkusi ja protokolle ning kasutajad saavad suurema kindluse.

Gaasi optimeerimine on samuti arenduse oluline fookus. See ei ole pelgalt meeldiv omadus, vaid nutika lepingu pikaajalise edu ja turvalisuse võti. Asjaolu, et L2-l on võimalik ehitada võrreldavalt madalate tasudega, ei tähenda, et gaasitasud ei oleks konkurentidest oluliselt kõrgemad.

Kõik testid kasutavad Foundry ja Solidity versiooni 0.8.13, kohalikku plokiahela sõlme Anvil, forge testikäske ja 100 optimeerimiskäsku.

Asendamatud tokenid said populaarseks 2021. aastal ja äratasid huvi täielikult ketis olevate NFT-de vastu. Ketis olevad NFT-d, võrreldes traditsiooniliste NFT-dega, mis kasutavad ketiväliseid andmeid, sealhulgas metaandmeid ja pildiviiteid, paigutavad kogu teabe otse plokiahelasse.

Nende tokenitega suhtlemine on kurikuulsalt kulukas ja kui kasutajad kannatavad tasude all, on hübriidlahendused vaikimisi valikuks. Sõltumata sellest, kas loote NFT-sid, mänge või DeFi protokolle, peaksite alati mõtlema, millised andmed on tegelikult vaja blockchainis salvestada ja millised on mõlema alternatiivi kompromissid.

Vähendage oluliselt gaasi kasutamist, salvestades teavet väljaspool ahelat, mis nõuab vähem muutujate salvestamist. Üks konkreetne meetod on kasutada sündmusi andmete salvestamiseks väljaspool ahelat, mitte tegelikult ahelas.

Tehingu gaasikulusid suurendavad sündmustega kaasnevad täiendavad emit-funktsioonid, kuid kuna teave ei ole ahelas salvestatud, ületavad säästud tavaliselt kulud.

Võtame näiteks nutika lepingu, mis võimaldab kasutajatel hääletada „jah” või „ei”. Esimesel juhul salvestatakse kasutajate hääled ahelasiseses struktuuris. Foundryga läbi viidud hääletusfunktsiooni test, mis sisaldas üle 100 iteratsiooni, näitab teatud gaasikulusid.

Võrdle seda nutika lepinguga, mis ei salvestaks teavet ahelas, vaid tekitaks sündmuse, kui hääletusfunktsioon käivitatakse. Uue hääletusfunktsiooni test, mis hõlmab Foundryt rohkem kui 100 korda, annab tulemusi.

Vähendatud ketis olevad andmed vähendasid keskmist gaasi 90,34% võrra.

Soliditys on kaks peamist andmestruktuuri: massiivid ja kaardistused.

• •Massiivid kasutatakse teatud indeksitega seotud elementide kogumite salvestamiseks
• •Võtme-väärtuse kaardistused on andmestruktuurid, mis toetavad otsest juurdepääsu andmetele unikaalsete võtmete abil

Kuigi massiivid võivad olla kasulikud vektorite ja muude sarnaste andmete salvestamisel, eelistatakse tavaliselt kaardistusi nende gaasitõhususe tõttu. Need on eriti optimaalselt kohandatud olukordadele, kus on vaja andmeid nõudmise korral, nt nime, rahakoti aadressi või kontoseisu järgi.

Massiivide või kaardistuste kasutamisel gaasi tarbimise mõistmiseks võib olla vaja tutvuda seotud EVM-opkoodide poolt kasutatava gaasiga. Opkoodid on madala taseme juhised, mida Ethereumi virtuaalmasin täidab nutikate lepingute täitmisel, kusjuures igal opkoodil on gaasi maksumus.

Juurdepääsuks massiivi väärtustele tuleb maksta EVM-i opkoodide kasutatud gaasiühiku eest. Kasutaja aadresside ja vastavate saldode salvestamine massiivi vormis eeldab kõigi massiivi elementide läbivaatamist, kontrollides, kas userAddress ja antud argument ühtivad, ning vastavuse korral saldokonto tagastamist.

Otse kasutaja konkreetsele saldole liikudes ei oleks vaja läbi vaadata kõiki massiivi elemente. Kui massiivid asendati kaardistustega, vähenes andmetele juurdepääsuks kasutatud gaasi kogus 89 protsenti.

Teine optimeerimisnõuanne oleks kasutada konstandeid ja muutumatuid muutujaid. Muutuvaid või konstante muutujaid määratledes antakse nende väärtused ainult lepingu loomise ajal ja mitte hiljem.

Need ei võta EVM-is võrreldes teiste muutujatega salvestusruumi. Väärtusi on võimalik kodeerida otse nutikas lepingus baitkoodis, mis tähendab, et andmete salvestamise kulud vähenevad, kuna muutujatel nagu maxSupply ja owner puuduvad konstantsed või muutumatud märksõnad.

Kui teste on tehtud 100 korda, on keskmine gaasi maksumus 112 222 ühikut. Kuna maxSupply ja owner on teadaolevad väärtused, mida ei ole kavas muuta, on parim valik deklareerida maksimaalne varu ja omanik, mis ei kasuta salvestusruumi.

**Konstantse või muutumatu muutuja testide tulemuseks on keskmiselt 35,89% sääst (112 222-st 71 940-ni gaasiühikut).

See on ilmselge gaasi optimeerimise nõuanne, et optimeerida muutujaid nutikates lepingutes. Mittekasulikud muutujad säilitatakse aga enamasti lepingu täitmisel, mis viib gaasi tarbetu kasutamiseni.

Üksikute kasutamata muutujate eemaldamine võib aidata säästa gaasikulusid keskmiselt 18%, kui võtta arvesse lepinguid, milles on määratletud ja manipuleeritud kasutamata muutujad, mida mujal kunagi ei kasutata.

Kasutamata muutujate eemaldamine on katse määrata muutujatele vaikimisi väärtused pärast nende täielikku arvutamist, ilma et andmeid mällu salvestataks. Näiteks on uint-tüüpi muutujate vaikimisi väärtus 0.

Kui funktsioonide lõppemisel funktsioonide muutujaid ei hävitata, on keskmised gaasikulud 100 300 ühikut, et määrata muutujad andmetele. Keskmiselt 19% gaasi kokkuhoid, kasutades kustutusklahvi andmete muutujate eemaldamiseks (muutujate seadmiseks väärtusele 0).

Kasutage võimaluse korral kaardistusi, et vähendada nutikate lepingute gaasikulusid. Siiski, kui on vaja massiive, on fikseeritud suurusega massiivid gaasi seisukohast ökonoomsemad kui dünaamilise suurusega massiivid, kuna dünaamilise suurusega massiive saab lõpmatult laiendada, mis toob kaasa suuremad gaasikulud.

Dünaamilisi massiive saab laiendada, mistõttu EVM peab jälgima pikkusi ja neid uuendama, kui lisatakse uusi elemente.

Võtke arvesse koodi, mis määratleb dünaamiliselt suurusega massiivid ja uuendab neid updateArray funktsioonidega. Require avaldused tagavad, et antud indeksid jäävad kindla suurusega massiivi vahemikku. Kui testitakse 100 korda, on keskmine kasutatud gaasi kogus 12 541.

Muutes massiivid fikseeritud suuruseks 5, luuakse fikseeritud suurusega massiivid pikkusega 5, tüüp uint256. EVM teab, et fikseeritud massiivil, mille muutuja suurus on 5, on 5 pesa ja pikkus ei ole salvestatud. Dünaamiliste massiivide asendamine fikseeritud massiividega säästab 17,99% gaasi.

See on vähem tõhus ja võib olla kallim kui uint256, kuna EVM töötab 256-bitiste sõnade suurusega. Operatsioonid 256-bitiste täisarvudega (uint256) on tavaliselt kõige efektiivsemad, kuna need sobivad EVM-i sõna suurusega, samas kui väiksemad tüübid (nagu uint8) nõuavad Solidity kompilaatorilt täiendavate operatsioonide loomist, et mahutada väiksemad tüübid ühte 256-bitisesse salvestusruumi.

Üldiselt võib väikeste tüüpide, nagu uint8, kasutamine olla kasulik salvestamise seisukohast (mitmed väikesed tüübid saab pakkida ühte operatsiooni 256-bitise salvestusruumiga), kuid on näha, et väiksemad tüübid aitavad ainult salvestamisel. Salvestusruumi kokkuhoid võib muutuda tühiseks, kui arvutuste tegemiseks tuleb teha teisendusi uint256-st ja uint256-sse.

Alla 256-bitise suurusega muutujate ühendamine ei ole tavaliselt nii tõhus kui 256-bitiste muutujate ühendamine. Koostalitlusvõimetud olukorrad sunnivad aga kasutama vähem võimsaid tüüpe väiksemates suurustes, nt boole'i muutujad, mille salvestamiseks kulub 1 bait või 8 bitti.

Vähem võimsate tüüpide kasutamisel on võimalik deklareerida seisundimuutujad, pidades silmas salvestusruumi, ning Solidity saab need kokku pakkida ja salvestada, kasutades sama salvestusruumi. Muutuja pakkimise eelist arvestatakse tavaliselt salvestusoperatsioonides, mitte mäluoperatsioonides või pinuoperatsioonides.

Kuna kahepoolsed kombinatsioonisuurused on 16 bitti ehk 240 bitti väiksemad kui ühe salvestuspesa mahutavus, saab Solidity abil pakkida muutujad samasse pesasse, et minimeerida kasutuselevõtu gaasi kasutamist, kuna seisundimuutujate salvestamiseks ei ole vaja palju pesasid.

Muutujate deklaratsioonide ümberkorraldamine võimaldab optimeerida keskmiselt 13% gaasi.

Selleks, et maksimeerida nutika lepingu gaasi, on mõistlik valida funktsioonide õige nähtavus. Välised nähtavuse modifikaatorid võivad olla gaasi kasutamisel efektiivsemad kui avalikud, kuna avalik funktsioon haldab oma argumente ja andmeid edastatakse funktsioonidele teatud viisil.

Välised funktsioonid saavad juurdepääsu calldata-le, mis on EVM-is ainult lugemiseks mõeldud ajutine ruum, mis sisaldab funktsioonikõne parameetreid. Avalikke funktsioone võib kutsuda:

• •Väliselt (kui neid kutsutakse väliselt tehinguga, mis kasutab calldata)
• •Sisemiselt (kui neid kutsutakse lepingus calldata abil)

Kuna funktsioonid on avalikud, peavad nad vastu võtma mällu massiive, mis võivad olla kulukad gaasikulu poolest, kui need on suured. Funktsioonide välisele lülitamine võimaldab massiivide vastuvõtmist calldata-s, mis on suuremate massiivide puhul kulutõhusam, säästes keskmiselt 0,3 protsenti gaasiühikutest ühe kõne kohta.

Hea viis gaasi säästmiseks on mitte lugeda sama väärtust salvestusruumis mitu korda. Salvestusruumist lugemine on kulukam kui mälust lugemine. Sama muutuja mitu korda salvestusruumist uuesti lugemine ja salvestusruumi kirjutamine, kui see pole vajalik, võib nutikates lepingutes gaasi raiskamiseks osutuda.

Seda saab vältida, määratledes muutujad, mis on mälus funktsioonide alguses, ja andes neile numbriliste muutujate väärtused.

See säästab 17% sumNumbers-funktsioonide poolt tarbitavast gaasist, kuid mida suurem on massiiv, seda suuremad on iteratsioonide arv ja kasutatav gaas.

Kui deklareerite muutujaid ilma neid algväärtustamiseta (st neile algväärtust määramata), algväärtustatakse need muutujad automaatselt vaikimisi väärtustega:

• •uint: 0
• •bool: false
• •aadress: aadress(0)

Viimane on odavam kui väärtuste deklareerimine vaikimisi ja nende lihtne uuendamine, kui kasutaja süsteemiga suhtleb, mis ei ole gaasitõhus. Ilma muutujate initsialiseerimiseta näitab optimeerimine 4% keskmist gaasi kokkuhoidu.

Solidity sisaldab kompilaatoreid, mille seadeid on lihtne muuta, et optimeerida kompileeritud koodi. Optimeeritud versioon töötab mitusada korda, optimeerides koodi ja teisendades selle odavamaks vormiks, mille käivitamiseks on vaja vähem gaasi.

Kompilaatoreid saab kohandada, et saavutada sobiv kompromiss rakendamise ja käitamise kulude vahel. Hinnangulise lepingute arvu määratlemine käivitamiskäskude abil:

• •Kõrgemad tasemed on optimaalsed madalate gaasihindade seisukohast lepingu täitmisel
• •Vähem numbreid on optimaalne gaasikulude vähendamise seisukohast lepingu rakendamisel

Optimeeri lipud ja väärtus run=200 ütlevad kompilaatoritele, et nad optimeeriksid koodi, et säästa gaasi, kui incrementCount funktsioone käivitatakse 200 korda. Liigita sellised seaded vastavalt rakenduse unikaalsetele nõuetele.

Kui kirjutate nutikaid lepinguid Solidity keeles, kompileeritakse need baitkoodideks, mis on EVM opkoodide jada. Assambleri abil saate lihtsalt kirjutada koodi, mis töötab opkoodidega paremini ühilduval tasemel, ja mõnel juhul annab opkoodide käsitsi optimeerimise võimalus eelise Solidity baitkoodi ees.

Kuigi nii madalal tasemel koodi kirjutamine ei ole kõige lihtsam ülesanne, on selle eeliseks võimalus optimeerida opkoode käsitsi, mistõttu on see üldiselt parem võrreldes Solidity baitkoodiga. Selline optimeerimise tase muudab lepingu täitmise tõhusamaks ja efektiivsemaks.

Isegi lihtsates juhtudel, kus kaks funktsiooni peaksid liitma kahte numbrit, on tavalised solidity ja assembly versioonid mõnevõrra erinevad, kuid assembly versioonid on odavamad.

Projektide rakendamine L2-süsteemides nagu Base tähendab, et kasutajatel on protokollide kasutamine odavam, kuid arendajate ülesanne on tagada gaasi optimeerimise tehnoloogiate rakendamine. Need näpunäited võivad oluliselt vähendada tehingukulutusi, suurendada skaleeritavust ja parandada lepingu üldist tõhusust.