Grunnleggende om Web3- og DApp-utvikling · leksjon

Teknikker for gassoptimalisering

Lær strategier for å skrive gaseffektiv Solidity-kode, redusere transaksjonskostnader og forbedre DApp-ytelsen på blokkjeden.

Leksjon 3 av 311 trinn

Teknikker for gassoptimalisering er en gratis leksjon i Grunnleggende om Web3- og DApp-utvikling på CoddyKit. Dette er leksjon 3 av 3. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Grunnleggende om Web3- og DApp-utvikling, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Grunnleggende om Web3- og DApp-utvikling inneholder totalt 3 leksjoner.

Hvorfor gassoptimalisering er viktig

Velkommen til den siste leksjonen i DApp-sikkerhet og revisjon! I dag skal vi mestre teknikker for gassoptimalisering.

Gass er avgiften som betales for å utføre transaksjoner på Ethereum-nettverket. Det fungerer omtrent som drivstoffet i en bil.

Kostnadsreduksjon: Lavere gassavgifter betyr billigere transaksjoner for brukerne.
Ytelse: Optimaliserte kontrakter kjører raskere.
Brukeropplevelse: Bedre ytelse gir mer fornøyde brukere og mer problemfrie DApp-er.

Forstå gasskostnader

Hver operasjon Ethereum Virtual Machine (EVM) utfører, koster en viss mengde gass. Komplekse operasjoner koster mer.

Når en smartkontrakt distribueres eller brukes, betales det gass for:

Lagring av data på blokkjeden (dyrest).
Utføring av beregninger.
Sending av Ether.

Målet er å skrive kode som bruker færre av disse kostbare operasjonene.

Storage, memory og calldata

Det er avgjørende å forstå hvor dataene dine befinner seg, slik at du kan spare gass. Hver plassering har ulike kostnader:

Storage: Permanent lagring på kjeden. Dyrest å lese fra og skrive til (SSTORE/SLOAD).
Memory: Midlertidig lagring som bare finnes mens en funksjon kjøres. Billigere enn storage.
Calldata: Uforanderlig, skrivebeskyttet og midlertidig. Brukes for argumenter til eksterne funksjoner. Billigst for eksterne inndata.

Prioriter calldata eller memory for variabler som ikke trenger å lagres permanent på kjeden.

Minimer lagringsskrivinger (SSTORE)

Å skrive til storage (SSTORE) er den klart dyreste operasjonen i Solidity. Spør alltid: Må denne variabelen virkelig lagres på kjeden?

I stedet for å oppdatere en teller i storage for hver iterasjon kan telleren beregnes én gang på slutten, eller endringer kan logges ved hjelp av hendelser.

Se på dette enkle eksempelet:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract StorageCostExample {
    uint256 public counter;

    // High gas cost: writes to storage every call
    function incrementBad() public {
        counter++;
    }

    // Lower gas cost: only reads state
    function getCounter() public view returns (uint256) {
        return counter;
    }
}

Pakking av lagringsvariabler

Solidity lagrer variabler i 256-bits (32-byte) «slots». Hvis flere variabler får plass i én slot, kan de «pakkes» sammen, slik at det spares gass.

For eksempel bruker tre uint8-variabler mindre lagringsplass enn tre uint256-variabler når de deklareres etter hverandre. Dette sparer SSTORE-operasjoner.

Deklarer mindre datatyper (for eksempel uint8 og bool) når det er mulig.
Grupper variabler med tilsvarende størrelse.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract StoragePacking {
    // These will likely pack into one slot
    uint8 public value1;
    bool public isActive;
    uint8 public value2;

    // This will take a separate slot
    address public owner;

    function setValues(uint8 _v1, bool _active, uint8 _v2) public {
        value1 = _v1;
        isActive = _active;
        value2 = _v2;
    }
}

Kortslutning av betingelser

Når logiske operatorer som && (AND) eller || (OR) brukes, benytter Solidity «kortslutning». Det betyr at evalueringen av betingelsene stopper så snart resultatet er kjent.

Gass kan spares ved å plassere den billigste betingelsen først, eller den som mest sannsynlig vil mislykkes eller bli sann.

For && plasseres betingelsen som mest sannsynlig er false, først.
For || plasseres betingelsen som mest sannsynlig er true, først.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract ShortCircuitExample {
    uint256 public data = 100;

    function checkCondition(uint256 _input) public view returns (bool) {
        // Cheaper check (input) before more expensive check (storage read)
        return (_input > 0 && data > 50); 
    }
}

Effektive løkker og iterasjoner

Løkker kan være kostbare når det gjelder gass, særlig hvis de går gjennom store arrayer som er lagret i storage. Unngå ubundne løkker eller løkker over dynamiske arrayer i storage når det er mulig.

Behandle data utenfor kjeden hvis det er mulig.
Bruk arrayer med fast størrelse i stedet for dynamiske arrayer når størrelsen er kjent.
Refaktorer logikken for å unngå løkker eller redusere antallet iterasjoner.
Vurder et uttaksbasert system for utbetalinger i stedet for å sende til mange mottakere i én transaksjon.

Bruke `view`- og `pure`-funksjoner

Funksjoner som er merket med view eller pure, endrer ikke blokkjede-tilstanden. Når de kalles eksternt, koster de ingen gass!

view: Leser tilstandsvariabler, men endrer dem ikke.
pure: Verken leser eller endrer tilstandsvariabler.

Interne kall til view-/pure-funksjoner bruker fortsatt gass som en del av den større transaksjonen, men korrekt bruk av dem for eksterne forespørsler kan spare brukerne for mye gass.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract ViewPureExample {
    uint256 public myNumber = 42;

    // Costs no gas for external calls
    function getNumber() public view returns (uint256) {
        return myNumber;
    }

    // Costs no gas for external calls
    function add(uint256 a, uint256 b) public pure returns (uint256) {
        return a + b;
    }
}

Gasskostnader ved feilhåndtering

Solidity tilbyr flere måter å håndtere feil på: require(), revert() og assert().

require(): Brukes til å validere inndata og betingelser. Refunderer ubrukt gass når den mislykkes. (Anbefales for de fleste kontroller.)
revert(): Ligner på require og refunderer også ubrukt gass.
assert(): Brukes for interne invariansbetingelser og skal *aldri* mislykkes. Bruker ALL gjenværende gass når den mislykkes. (Brukes sparsomt for kritiske interne kontroller.)

Det er mye dyrere å få en assert til å mislykkes enn en require, så velg feilhåndtering med omhu.

Spørsmål: Gassoptimalisering

Se på følgende Solidity-kode. Hvilken endring vil sannsynligvis gi de MEST betydelige gassbesparelsene for en bruker som kaller updateStatus?

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract GasPuzzle {
    uint256 public statusId;
    string public statusName;
    address public owner;

    constructor() {
        owner = msg.sender;
        statusId = 1;
        statusName = "Initial";
    }

    function updateStatus(uint256 _newId, string memory _newName) public {
        require(msg.sender == owner, "Not owner");
        statusId = _newId;
        statusName = _newName;
    }
}

Besvar den i den interaktive leksjonen

Oppsummering: Mestre gassoptimalisering

Du har lært viktige strategier for å skrive gasseffektiv Solidity-kode!

Husk disse prinsippene:

Minimer lagringsskrivinger: Den viktigste regelen.
Pak variabler: Grupper mindre variabler slik at de får plass i slots.
Bruk effektive dataplaceringer: Foretrekk calldata/memory fremfor storage.
Optimaliser løkker: Unngå ubundne eller omfattende iterasjoner.
Utnytt view/pure: For eksterne lesinger uten gasskostnad.
Smart feilhåndtering: Bruk require/revert, ikke assert, for brukerinput.

Ved å bruke disse teknikkene blir DApp-ene rimeligere, raskere og mer brukervennlige. Fortsett å øve!

Gratis å komme i gang

Lær deg Grunnleggende om Web3- og DApp-utvikling med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 29
Leksjoner: 105

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Teknikker for gassoptimalisering» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Grunnleggende om Web3- og DApp-utvikling, inkludert «Teknikker for gassoptimalisering», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Grunnleggende om Web3- og DApp-utvikling inneholder totalt 3 leksjoner.

Hva lærer jeg i «Teknikker for gassoptimalisering»?

Lær strategier for å skrive gaseffektiv Solidity-kode, redusere transaksjonskostnader og forbedre DApp-ytelsen på blokkjeden. Du øver på Grunnleggende om Web3- og DApp-utvikling med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Grunnleggende om Web3- og DApp-utvikling?

Ingen tidligere erfaring er nødvendig. Grunnleggende om Web3- og DApp-utvikling på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 3.

Hvor lang tid tar leksjonen «Teknikker for gassoptimalisering»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Grunnleggende om Web3- og DApp-utvikling-leksjonen?

Ja. Alle Grunnleggende om Web3- og DApp-utvikling-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

← Tilbake til Grunnleggende om Web3- og DApp-utvikling