“Zróbmy to na smartkontrakcie!” – od ponad roku jest to jedno z częściej wypowiadanych zdań w wielu firmach i startupach. Jednak w wielu (większości?) przypadkach jest to działanie pochopne lub skazane na porażkę.

Dlaczego?

Smartkontrakty, jako że są programami komputerowymi, mają możliwości ograniczone tylko wyobraźnią twórców i możliwościami języka w jakim są napisane.

Polecamy także: Przewodnik po smartkontraktach: Czym jest smart contract?

Istnieją jednak znaczne ograniczenia w działaniu smartkontraktów, o których nie wszyscy pamiętają lub (co gorsza) nie wiedzą.

Ograniczenia smartkontraktów

Największym ograniczeniem jest brak możliwości bezpośredniego dostępu smartkontraktu do “świata zewnętrznego” poza blockchainem na którym działa kontrakt. Nie ma więc możliwości, aby kontrakt “sprawdził kurs” czy “sprawdził wynik meczu”. Aby taka operacja była możliwa, należy użyć innych kontraktów, które “karmione są” informacjami. Kontrakty takie nazywane są “wyroczniami” (oracle). Oczywiście, musimy zaufać w sposób podawania informacji do wyroczni…

Drugim dużym ograniczeniem jest brak “autostartu” kontraktów. Każde działanie kontraktu musi być poprzedzone jego wywołaniem za pomocą transakcji skierowanej na kontrakt. Odpadają więc wszelkie pomysły “kontrakt uruchomi się raz dziennie/co godzinę i zrobi ….”. Takie działanie musimy wywołać sami, stąd pojawia się pojęcie “dAPP” – połączenie systemu poza blockchainem który używa do swojego działania smartkontraktu.

Trzecim, i największym, niebezpieczeństwem jest “nieobliczalność” kosztów używania kontraktu na blockchainie publicznym. Np. w przypadku ETH musimy brać pod uwagę nie tylko cenę samej waluty Ethereum, ale również koszt jednostki “gas” zużywanej przez kontrakt. O ile ilość “gas” możemy policzyć i/lub sprawdzić doświadczalnie w testnecie czy lokalnym blockchainie, o tyle nie jesteśmy w stanie zgadnąć ile ETH będzie kosztować gas w przyszłości. Cena gas zależy bowiem od chwilowego obciążenia sieci, które zależy od ilości transakcji (która zależy od użytkowników sieci) oraz od limitu gas w bloku (który zależy od węzłów kopalni). Przed wahaniem ceny ETH możemy ustrzec się kupując odpowiedni zapas, jednak w przypadku wzrostu ceny gas nasze obliczenia (a tym samym zapasy) mogą szybko stać się nieadekwatne.

Jeżeli pomimo wszystko chcemy rozpocząć naszą przygodę ze smartkontraktami, od czego zacząć?

Solidity

Solidity jest językiem programowania w którym składnia podobna jest do JavaScript. Oczywiście, ma funkcje i komendy charakterystyczne dla smartkontraktów, które w JavaScript nie występują. Mając podstawy programowania w innym niż JavaScript języku i tak dość szybko powinniśmy się odnaleźć.

Najnowsza wersja dokumentacji języka znajduje się pod adresem https://solidity.readthedocs.io/, odsyła ona nas automatycznie do najnowszej wersji produkcyjnej, obecnie 0.5, która całkiem niedawno przestała być wersją deweloperską.

Przygodę z pisaniem własnych kontraktów warto zacząć od istniejących i sprawdzonych projektów, których spory wybór znajdziemy np w projekcie OpenZeppelin na GitHubie https://github.com/OpenZeppelin

W repozytorium “openzeppelin-solidity” w katalogu “contracts” znajdziemy wzorcowe implementacje tokenów w standardzie ERC20, kontraktów crowdfundingu, bibliotek matematycznych z kontrolą przepełnień i wiele innych.

Mając kod kontraktu napisanego/opublikowanego nawet kilka miesięcy temu, może się okazać że po zmianie wersji używanego kompilatora na aktualną, kompilator zacznie zwracać ostrzeżenia i błędy. Jest to dobry sposób aby nauczyć się modyfikować i aktualizować kontrakty. W jakiej wersji jest napisany dany kontrakt możemy zauważyć w pierwszej linii kodu kontraktu. Jako że wersja 0.5 dopiero co przeszła na wersję produkcyjną, bardzo duża ilość kontraktów wersjach 0.4.x będzie wymagała mniejszych lub większych poprawek.

Najprostszym sposobem, nie wymagającym instalacji żadnego oprogramowania, do rozpoczęcia programowania w Solidity jest użycie przeglądarkowej wersji kompilatora i łańcucha bloków – Remix: https://remix.ethereum.org

Remix pozwala nam na pisanie praktycznie dowolnych kontraktów i testowanie ich, jednocześnie dbając o składnię i wyłapując oczywiste literówki czy braki przecinków. Jego wadą jest szybkość działania. O ile proste kontrakty (np. tokeny) działają bez opóźnień, o tyle wykonanie bardziej skomplikowanych kontraktów (np. kilku odwołujących się do siebie czy zapisujących kilkaset wpisów do pamięci kontraktu) może być męczące, nawet na szybkich komputerach. Wynika to z prostego faktu – sam Remix jest po prostu programem w JavaScript uruchomionym w naszej przeglądarce, i to ogranicza jego szybkość.

Kolejnym krokiem jest użycie frameworku Truffle https://truffleframework.com/. Może on używać silnika Ganache do uruchomienia testowego blockchaina, dając możliwość użycia pełnej mocy CPU jaki oferuje komputer na którym go uruchamiamy. Sam Truffle daje nam dostęp do konsoli web3, pozwalając “na żywo” wywoływać wszelkie komendy i uruchamiać skrypty.

Możemy też zrobić kombinację: użyć Remix do pisania ale podłączyć go do Ganache aby kontrakty szybciej się wykonywały. Nie jest to strasznie skomplikowane, w Remix w zakładce “run” wystarczy wybrać “Web3 provider” i wpisać ip/port pod jakim zgłasza się Ganache.

Miłej zabawy!