Samouczek Solidity dotyczący efektywności zużycia gazu: 12 wskazówek, jak radzić sobie z rosnącymi opłatami w łańcuchach bazowych i innych łańcuchach L2

Aby pokonać te ograniczenia, opracowano kilka rozwiązań warstwy 2, takich jak Base, które są kontrolowane przez skalowalność i zmniejszone koszty gazu. Chociaż L2 oferują znaczne obniżki opłat w porównaniu z siecią główną Ethereum, twórcy inteligentnych kontraktów nie mogą ignorować optymalizacji gazu podczas ich opracowywania.

Ten samouczek ma na celu konsolidację doświadczeń użytkowników i tworzenie bardziej konkurencyjnych, zdecentralizowanych aplikacji poprzez zaawansowane strategie obniżające koszt gazu w testowanych inteligentnych kontraktach. Podane przykłady są symulowane przy użyciu prostych kontraktów i uwzględniają głównie ceny gazu w czasie wykonywania, ponieważ koszty wdrożenia różnią się znacznie w zależności od wielkości kontraktu.

Optymalizacja zużycia gazu ma duże znaczenie dla programistów, użytkowników i długoterminowego sukcesu projektu. Ekonomiczne wykorzystanie gazu w inteligentnych kontraktach może zapewnić większą opłacalność i skalowalność protokołów oraz zmniejszyć podatność na zagrożenia bezpieczeństwa, takie jak ataki typu denial of service.

Optymalizacja gazu pozwala inteligentnym kontraktom, protokołom i projektom działać w warunkach przeciążonych sieci i sprawia, że są one zarówno tanie, jak i wydajne. Dzięki ulepszeniu kodu kontraktu istnieje możliwość ujawnienia potencjalnych luk w zabezpieczeniach, a protokoły i użytkownicy zyskują większą pewność.

Optymalizacja zużycia gazu jest również ważnym elementem rozwoju. Nie jest to jedynie miły dodatek, ale klucz do długoterminowego sukcesu i bezpieczeństwa inteligentnych kontraktów. Fakt, że możliwe jest tworzenie na L2 przy stosunkowo niskich opłatach, nie oznacza, że opłaty za gaz nie będą znacznie wyższe niż u konkurencji.

Wszystkie testy wykorzystują Foundry i Solidity w wersji 0.8.13, lokalny węzeł blockchain Anvil, polecenia testowe forge oraz 100 przebiegów optymalizacyjnych.

Tokeny niewymienne (Non-Fungible Tokens) stały się popularne w 2021 roku i wzbudziły zainteresowanie w pełni łańcuchowymi NFT. Łańcuchowe NFT, w porównaniu z tradycyjnymi NFT, które wykorzystują dane poza łańcuchem, w tym metadane i odniesienia do obrazów, umieszczają wszystkie informacje bezpośrednio w łańcuchu bloków.

Komunikacja za pomocą tych tokenów jest niezwykle kosztowna, dlatego też rozwiązania hybrydowe są domyślnym wyborem w przypadku użytkowników obciążonych opłatami. Niezależnie od tego, czy tworzycie NFT, gry czy protokoły DeFi, zawsze powinniście zastanowić się, jakie dane faktycznie muszą być przechowywane w łańcuchu bloków, oraz rozważyć kompromisy związane z obiema alternatywami.

Znacznie zmniejsz zużycie gazu poprzez przechowywanie informacji poza łańcuchem, co wymaga mniejszego zapotrzebowania na pamięć zmiennych. Jedną z konkretnych metod jest wykorzystanie zdarzeń do przechowywania danych poza łańcuchem, a nie w rzeczywistej pamięci łańcucha.

Koszty transakcji gazowych są podwyższane przez dodatkowe funkcje emitowane przez zdarzenia; jednak informacje nie są przechowywane w łańcuchu bloków, więc oszczędności zazwyczaj przewyższają koszty.

Rozważmy inteligentną umowę, która pozwala użytkownikom głosować na „tak” lub „nie”. Pierwsza z nich przechowuje głosy użytkowników w strukturach łańcucha bloków. Demonstracja testu funkcji głosowania za pomocą Foundry z ponad 100 iteracjami pokazuje określone koszty gazu.

Porównaj z inteligentną umową, która nie przechowuje informacji w łańcuchu bloków, ale generuje zdarzenie po wywołaniu funkcji głosowania. Test obejmujący ponad 100 użyć Foundry w nowej funkcji głosowania dostarcza wyników.

Zmniejszona ilość danych w łańcuchu bloków spowodowała spadek średniego zużycia gazu o 90,34%.

W Solidity istnieją dwie główne struktury danych: tablice i mapowania.

• Tablice służą do przechowywania zestawów elementów przypisanych do określonych indeksów
• Mapowania klucz-wartość to struktury danych, które umożliwiają bezpośredni dostęp do danych za pomocą unikalnych kluczy

Chociaż tablice mogą być przydatne do przechowywania wektorów i innych podobnych danych, zazwyczaj preferowane są mapowania ze względu na ich wydajność gazową. Są one szczególnie optymalnie dostosowane do sytuacji, w których potrzebne są dane na żądanie, np. według nazwy, adresu portfela lub salda konta.

Aby zrozumieć zużycie gazu podczas korzystania z tablic lub mapowań, może być konieczne sprawdzenie zużycia gazu przez powiązane kody operacyjne EVM. Kody operacyjne to niskopoziomowe instrukcje wykonywane przez maszynę wirtualną Ethereum podczas realizacji inteligentnych kontraktów, przy czym każdy kod operacyjny ma określony koszt gazu.

Aby uzyskać dostęp do wartości tablicy, należy uiścić opłatę za jednostkę gazu zużytą przez kody operacyjne EVM. Przechowywanie adresów użytkowników i odpowiadających im sald w formie tablicy wymaga przechodzenia przez wszystkie elementy tablicy, sprawdzania, czy adres użytkownika i podany argument są zgodne, oraz zwracania salda w przypadku zgodności.

Przejście bezpośrednio do konkretnego salda użytkownika pozwoliłoby uniknąć konieczności przeglądania wszystkich elementów tablicy. Po zastąpieniu tablic mapowaniami zużycie gazu potrzebnego do uzyskania dostępu do danych zmniejszyło się o 89 procent.

Kolejną wskazówką dotyczącą optymalizacji jest używanie stałych i niezmiennych zmiennych. Określając zmienne jako niezmienne lub stałe, ich wartości są podawane tylko w momencie tworzenia umowy i nie są już aktualizowane.

W przeciwieństwie do innych zmiennych nie zajmują one miejsca w pamięci EVM. Możliwe jest bezpośrednie kodowanie wartości w kodzie bajtowym smart contract, co oznacza, że koszt przechowywania danych jest zmniejszony dzięki temu, że zmienne takie jak maxSupply i owner nie mają słów kluczowych constant lub immutable.

Po 100-krotnym przeprowadzeniu testów średni koszt gazu wynosi 112 222 jednostek. Ponieważ maxSupply i owner są znanymi wartościami, które nie mają ulec zmianie, najlepszym wyborem jest zadeklarowanie maksymalnej podaży i właściciela, które nie zajmują miejsca w pamięci.

Testy stałych lub niezmiennych zmiennych dają średnią oszczędność na poziomie 35,89% (z 112 222 do 71 940 jednostek gazu).

Oczywistą wskazówką dotyczącą optymalizacji zużycia gazu jest optymalizacja zmiennych w inteligentnych kontraktach. Jednak w większości przypadków niepotrzebne zmienne są zachowywane podczas wykonywania kontraktu, co prowadzi do niepotrzebnego zużycia gazu.

Usunięcie pojedynczych nieużywanych zmiennych może pomóc w obniżeniu kosztów gazu, średnio o 18%, biorąc pod uwagę kontrakty z nieużywanymi zmiennymi zdefiniowanymi i modyfikowanymi w funkcjach, ale nigdy nie wywoływanymi w innych miejscach.

Eliminacja nieużywanych zmiennych jest próbą przypisania wartości domyślnych do zmiennych po ich pełnym obliczeniu bez przechowywania danych w pamięci. Przykładowo, wartością domyślną zmiennych typu uint jest 0.

Nie niszcząc zmiennych funkcji po zakończeniu działania funkcji, średnie koszty gazu wynoszą 100 300 jednostek, aby przypisać zmienne do danych. Średnio 19% oszczędności gazu przy użyciu klawisza delete do usunięcia zmiennych danych (aby ustawić zmienne na 0).

W miarę możliwości używaj mapowań, aby zmniejszyć koszty gazu związane z inteligentnymi kontraktami. Niemniej jednak, gdy wymagane są tablice, tablice o stałym rozmiarze są bardziej ekonomiczne pod względem zużycia gazu niż tablice o rozmiarze dynamicznym, ponieważ tablice o rozmiarze dynamicznym mogą być rozszerzane w nieskończoność, co prowadzi do wyższych kosztów gazu.

Tablice dynamiczne mogą być rozszerzane, dlatego EVM musi monitorować długości i odświeżać je po dodaniu nowych elementów.

Rozważ kod, który definiuje tablice o dynamicznej wielkości i aktualizuje je za pomocą funkcji updateArray. Instrukcje require zapewnią, że podane indeksy mieszczą się w zakresie tablicy o stałej wielkości. Po 100 powtórzeniach testu średnia ilość zużytego gazu wynosi 12 541.

Zmiana tablic na stały rozmiar 5 tworzy tablice o stałym rozmiarze długości 5, typu uint256. EVM wie, że fixedArray ze zmienną stanową rozmiaru 5 ma 5 slotów, a długość nie jest przechowywana w pamięci. Zastąpienie tablic dynamicznych tablicami stałymi pozwala zaoszczędzić 17,99% gazu.

Jest to mniej wydajne i może być droższe w użyciu niż uint256 ze względu na działanie EVM. EVM ma 256-bitowe rozmiary słów. Operacje z liczbami całkowitymi 256-bitowymi (uint256) są zazwyczaj najbardziej wydajne, ponieważ pasują do rozmiaru słowa EVM, podczas gdy mniejsze typy (takie jak uint8) wymagają od kompilatora Solidity tworzenia dodatkowych operacji, aby dopasować mniejsze typy do pojedynczego 256-bitowego slotu pamięci.

Ogólnie rzecz biorąc, chociaż małe typy, takie jak uint8, mogą być korzystne, jeśli chodzi o przechowywanie (wiele małych typów można zapakować do jednej operacji z 256-bitowym slotem pamięci), zaobserwowano, że mniejsze typy pomagają tylko w przechowywaniu. Oszczędności w zakresie przechowywania mogą zostać zniwelowane przez konwersję do i z uint256 w celu wykonania obliczeń.

Łączenie zmiennych o rozmiarze mniejszym niż 256 bitów zazwyczaj nie jest tak wydajne jak w przypadku zmiennych 256-bitowych. Jednak sytuacje, w których nie ma możliwości współdziałania, wymuszają stosowanie mniej wydajnych typów w mniejszych rozmiarach, np. zmiennych logicznych, które zajmują 1 bajt lub 8 bitów do przechowywania.

W przypadku korzystania z mniej wydajnych typów możliwe jest deklarowanie zmiennych stanu z uwzględnieniem przestrzeni pamięci, a Solidity może je spakować i przechowywać w tym samym slocie pamięci. Zalety pakowania zmiennych są zazwyczaj brane pod uwagę w operacjach pamięciowych, a nie w operacjach pamięciowych lub operacjach stosu.

Ponieważ rozmiary kombinacji dwukierunkowych wynoszą 16 bitów, czyli są o 240 bitów mniejsze niż pojemność pojedynczego slotu pamięci, Solidity może być używany do pakowania zmiennych do tego samego slotu, aby zminimalizować zużycie gazu podczas wdrażania, ponieważ nie wymaga wielu slotów do przechowywania zmiennych stanu.

Zmiana kolejności deklaracji zmiennych pozwala na optymalizację średnio o 13% gazu.

Aby zmaksymalizować zużycie gazu przez inteligentny kontrakt, rozsądne jest wybranie odpowiedniej widoczności funkcji. Zewnętrzne modyfikatory widoczności mogą być bardziej wydajne pod względem zużycia gazu niż publiczne ze względu na sposób, w jaki funkcja publiczna zarządza swoimi argumentami, oraz sposób, w jaki dane są przekazywane do funkcji.

Funkcje zewnętrzne mogą uzyskać dostęp do calldata, czyli tymczasowej przestrzeni tylko do odczytu w EVM, która zawiera parametry wywołania funkcji. Możesz wywoływać funkcje publiczne:

• Zewnętrznie (gdy są wywoływane zewnętrznie przez transakcję przy użyciu calldata)
• Wewnętrznie (gdy są wywoływane w umowie przy użyciu calldata)

Ponieważ funkcje są publiczne, muszą one odbierać tablice w pamięci, co może być kosztowne pod względem zużycia gazu, jeśli są one duże. Przełączenie funkcji na zewnętrzne umożliwia odbiór tablic w calldata, co jest bardziej opłacalne w sytuacjach związanych z dużymi tablicami, oszczędzając średnio 0,3% jednostek gazu na każde wywołanie.

Dobrą techniką oszczędzania gazu jest unikanie wielokrotnego odczytywania tej samej wartości z pamięci. Odczytywanie z pamięci jest droższe niż odczytywanie z pamięci operacyjnej. Wielokrotne odczytywanie tych samych zmiennych z pamięci i zapisywanie w pamięci, gdy nie jest to konieczne, może być marnowaniem gazu w inteligentnych kontraktach.

Można temu zapobiec, definiując zmienne, które znajdują się w pamięci na początku funkcji, i nadając im wartości zmiennych liczbowych.

Pozwala to zaoszczędzić 17% gazu zużywanego przez funkcje sumNumbers, ale im większa tablica, tym większa będzie liczba iteracji i zużycie gazu.

W przypadku deklarowania zmiennych stanu bez ich inicjalizacji (tj. bez przypisywania im wartości początkowej) zmienne te są automatycznie inicjalizowane do wartości domyślnych:

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

To drugie rozwiązanie jest tańsze niż deklarowanie wartości domyślnych i ich aktualizowanie w momencie interakcji użytkownika z systemem, co nie jest efektywne pod względem zużycia gazu. Bez inicjalizacji zmiennych optymalizacja wskazuje na średnią oszczędność gazu na poziomie 4%.

Solidity zawiera kompilatory z ustawieniami, które można łatwo zmienić w celu optymalizacji skompilowanego kodu. Optymalizacja kompilacji przebiega kilkaset razy, optymalizując kod i konwertując go do tańszych form, które wymagają mniej gazu do działania.

Kompilatory można dostosować, aby osiągnąć odpowiedni kompromis między kosztami wdrożenia a kosztami czasu wykonywania. Określanie szacowanej liczby kontraktów do wykonania za pomocą poleceń run:

• Wyższe poziomy są optymalne pod względem niskich cen gazu przy egzekwowaniu umowy
• Mniejsza liczba cyfr jest optymalna pod względem zmniejszenia kosztów gazu w ramach wdrażania umowy

Optymalizuj flagi oraz wartość run=200, aby kompilatory optymalizowały kod w celu oszczędzania gazu podczas 200-krotnego uruchamiania funkcji incrementCount. Sklasyfikuj takie ustawienia zgodnie z unikalnymi wymaganiami aplikacji.

Podczas pisania inteligentnych kontraktów w Solidity są one kompilowane do kodów bajtowych, czyli sekwencji kodów operacyjnych EVM. Dzięki asemblerowi możesz po prostu pisać kod działający na poziomach bardziej kompatybilnych z kodami operacyjnymi, a w niektórych przypadkach możliwość ręcznej optymalizacji kodów operacyjnych daje mu przewagę nad kodem bajtowym Solidity.

Chociaż pisanie kodu na tak niskim poziomie nie jest najłatwiejszym zadaniem, ma ono tę zaletę, że umożliwia ręczną optymalizację kodów operacyjnych, dzięki czemu jest ogólnie lepsze w porównaniu z kodem bajtowym Solidity. Taki poziom optymalizacji zapewnia większą wydajność i skuteczność w wykonywaniu umowy.

Nawet w prostych przypadkach, gdy dwie funkcje mają za zadanie dodać dwie liczby, wersje w języku Solidity i asemblerze będą się nieco różnić, ale wersje asemblerowe są tańsze.

Wdrożenie projektów na L2, takich jak Base, oznacza, że użytkownicy poniosą mniejsze koszty korzystania z protokołów, ale obowiązkiem programistów jest zapewnienie wdrożenia technik optymalizacji zużycia gazu. Te wskazówki mogą znacznie obniżyć koszty transakcji, zwiększyć skalowalność i ogólnie poprawić wydajność kontraktu.