https://www.naszakasa.org.pl/kwestie-techniczne-i-kopanie-kryptowalut/czym-rozni-sie-maszyna-wirtualna-ethereum-evm-od-innych/ pl-PL Sat, 18 Apr 2026 11:10:01 +0000 wpForo 60 https://www.naszakasa.org.pl/kwestie-techniczne-i-kopanie-kryptowalut/czym-rozni-sie-maszyna-wirtualna-ethereum-evm-od-innych/#post-185 Mon, 30 Mar 2026 23:51:42 +0000 synchroniczną kompozycyjność. Kojarzysz termin "money legos"? W architekturze EVM możesz w ramach jednej, absolutnie atomowej transakcji wziąć wielomilionową pożyczkę flash loan, zrobić arbitraż przeskakując przez trzy różne deksy, zapłacić prowizję i oddać kapitał. Wszystko w jednym ułamku sekundy, w tym samym bloku. Albo to wszystko przechodzi w całości, albo wirtualny silnik robi twardy revert i udajemy że nic się nie stało. W wirtualnych maszynach krypto stawiających na zrównoleglenie, zbudowanie tak skomplikowanej logiki łączącej mnóstwo niezależnych puli bywa sporo trudniejsze i potrafi generować dziwne asynchroniczne problemy. Czasem ten powolny, sztywny determinizm to po prostu mniejsze ryzyko, że jakaś noga skomplikowanego tradu się wywali. Druga sprawa, o której mało kto gada, to fakt że oryginalna maszyna wirtualna sieci Ethereum to jest dosłownie poligon, na którym wybuchło już chyba wszystko, co miało wybuchnąć. Miliony zrabowanych dolarów sprawiły, że wokół EVM wytworzył się twardy pancerz ze standardów. Kiedy odpalasz nowiutki silnik oparty np. na Move czy Rust, to siłą rzeczy przecierasz szlaki. Wiele wektorów ataków wychodzi dopiero w praniu na produkcji. W EVM takie klasyki jak reentrancy attack czy front-running mamy już przemielone na wylot. To nie działa tak, że Ethereum Virtual Machine samo z siebie chroni przed błędami - oj nie, kod chętnie pozwala na strzelenie sobie w kolano. Ale to dojrzałe środowisko deweloperskie ma potężne narzędzia do analizy statycznej kodu, co daje devom chociaż trochę lepszy sen. No i jest jeszcze jedna kwestia, o której wogóle musimy wspomnieć przy temacie alternatyw. Branża krypto wcale nie chce porzucać EVM, ona chce je zmutować. Słyszałeś o zkEVM? To jest ten mityczny graal, nad którym teraz wszyscy siedzą. Chodzi o to, żeby zachować pełną kompatybilność z maszyną EVM (żeby dev mógł wziąć gotowy kod w Solidity bez poprawek), ale żeby same ciężkie obliczenia działy się off-chain. Potem używamy zaawansowanej kryptografii (zero-knowledge proofs), żeby tylko udowodnić głównej sieci, że wykonaliśmy to poprawnie. Omijasz problem drogiego gazu zatykającego mainnet, a dalej korzystasz z tego samego, sprawdzonego wirtualnego silnika. Żadna inna nowa architektura Web3 nie ma narazie tak kosmicznie rozwiniętego ekosystemu warstwy drugiej (L2). Więc jak tak sobie siedzisz i próbujesz to rozkminić, to potraktuj środowisko EVM jak starego, topornego Windowsa w świecie IT. Każdy na niego narzeka, każdy widzi jego limity z zarządzaniem pamięcią, ale prawda jest taka, że to na nim odpala się większość realnego biznesu. Twórcy nowych sieci chętnie plują na ten standard marketingowo, ale finalnie i tak odpalają u siebie środowiska kompatybilne z Ethereum, bo bez tego pies z kulawą nogą nie przeniósłby tam swojego kapitału. Moja rada? Przestań traktować EVM tylko jako parser kodu do odpalania apek. Zrozum jak działa gas, ogarnij dlaczego modyfikowanie storage'u jest takie zabójczo drogie, a dopiero potem zacznij testować inne, egzotyczne wirtualne środowiska na blockchainie. Dużo łatwiej ci będzie docenić wydajność nowości, jak najpierw solidnie ubrudzisz ręce w starym smarze. Trzymaj się tam w tej króliczej norze!]]> Kwestie techniczne i kopanie kryptowalut chleb2574slodki https://www.naszakasa.org.pl/kwestie-techniczne-i-kopanie-kryptowalut/czym-rozni-sie-maszyna-wirtualna-ethereum-evm-od-innych/#post-185 https://www.naszakasa.org.pl/kwestie-techniczne-i-kopanie-kryptowalut/czym-rozni-sie-maszyna-wirtualna-ethereum-evm-od-innych/#post-184 Mon, 30 Mar 2026 23:51:06 +0000 czym różni się maszyna wirtualna Ethereum (EVM) od innych środowisk tego typu i dlaczego ten flagowy wirtualny silnik budzi w branży aż tyle kontrowersji. Zacznijmy od totalnych podstaw. Klasyczne wirtualne maszyny z tradycyjnego IT, tak jak wspomniałeś w swoim poście JVM dla Javy czy V8 do Node.js, mają jeden główny cel: odpalić kod aplikacji szybko i sprawnie na jednym konkretnym serwerze lub kompie, wyciskając z procka i RAMu ile fabryka dała. Z kolei środowisko uruchomieniowe smart kontraktów w zdecentralizowanym blockchainie ma zupełnie inny priorytet. Tutaj świętym Graalem dla twórców jest absolutny determinizm. Co to znaczy w praktyce? Jeśli zapuścisz ten sam skrypt z tymi samymi danymi wejściowymi na potężnym klastrze w AWS, na starym lapku u kogoś w piwnicy i na małym Raspberry Pi, wszędzie na świecie musisz dostać dokładnie co do bitu identyczny wynik i identyczną zmianę globalnego stanu sieci. W klasycznym programowaniu możesz na przykład wywołać losowość z zegara systemowego albo odpytać zewnętrzne API o kurs dolara. W środowisku EVM takie akcje to zbrodnia. Gdyby węzły w sieci dostały minimalnie różne wyniki działania funkcji, konsensus by się totalnie wysypał i blockchain by od razu sforkował. Dlatego cała wewnętrzna architektura Ethereum Virtual Machine jest odcięta od świata zewnętrznego jak w sterylnej izolatce (brak standardowego I/O, brak randomizacji, polegamy tylko i wyłącznie na zewnętrznych oracle'ach typu Chainlink). To od razu pokazuje gigantyczne różnice między EVM a JVM. Druga potężna kwestia: model pamięci i słowa danych. Tradycyjne środowiska uruchomieniowe i procesory śmigają optymalnie na 32 albo 64 bitach. A wiesz jak to wymyślili magicy w fundacji Ethereum? Architektura EVM opiera się na słowach 256-bitowych. Brzmi to kosmicznie, ale ma swoje głębokie techniczne uzasadnienie. Wlasnie prawie wszystko w świecie krypto kręci się wokół ciężkiej kryptografii na krzywych eliptycznych, podpisów cyfrowych i hashowania (na czele z algorytmem Keccak256). Skoro natywne hashe mają 256 bitów, to programiści uznali, że najbardziej optymalne logicznie będzie oparcie o to całej maszyny stosowej. Problem w tym, że klasyczny hardware x86 na którym stoją nody strasznie się przy tym dusi, bo musi te ogromne 256 bitów sztucznie ciąć na mniejsze kawałki żeby to w ogóle procesor mógł przetworzyć. Przez to oryginalna maszyna wirtualna sieci Ethereum jest z definicji strasznie mało zoptymalizowana pod współczesne fizyczne procesory i działa po prostu topornie. Teraz przejdźmy do tego, co zauważyłeś o gazie i kosztach wykonania kodu. Dobrze kminisz! Mechanizm opłat za gaz to nie jest tylko złośliwy sposób na dojenie userów z kasy dla górników. W architekturze komputerowej istnieje coś takiego jak Problem Stopu (Halting Problem). W mega dużym skrócie: nie da się z góry, matematycznie udowodnić, czy dany program kiedykolwiek sam się zakończy, dopóki fizycznie go nie uruchomisz. Jak w zwykłym środowisku IT ktoś wypuści na serwer nieskończoną pętlę w kodzie, to maszyna łapie zadyszkę, system sypie alertem, admin ręcznie ubija zacięty proces, pije kawkę i wszystko wraca do życia. W zdecentralizowanym, rozproszonym systemie Web3 taka pętla `while(true)` powiesiłaby kompletnie całą globalną sieć. Każda maszyna wirtualna krypto musi się przed tym wektorem ataku skutecznie bronić. W EVM każdy pojedynczy opcode (czyli najmniejsza instrukcja dla wirtualnego procesora, np. dodawanie, mnożenie zmiennych, zapis do pamięci flash) ma przypisaną z góry sztywną cenę w gazie. Zwykła matematyka jest tania, odczyt ze storage'u drogi, a zapis do permanentnego storage'u ekstremalnie kosztowny. Ustalasz limit gazu na transakcję i wirtualny silnik jedzie instrukcja po instrukcji. Skończy się waha w baku? Maszyna wypluwa "Out of Gas!", robi twardy revert i cofa wszelkie zmiany w globalnym stanie kont żeby zachować spójność. Ale co najlepsze... hajs za już zużytą energię obliczeniową przepada i trafia do walidatorów. Blockchain funkcjonuje niewzruszony dalej, a nieogarnięty atakujący bankrutuje. Ten bezwzględny, wpisany w protokół rygor ekonomiczny to mechanika, czym tak naprawde różni się maszyna wirtualna Ethereum (EVM) od innych silników obliczeniowych, które nie mają żadnego pojęcia o wartości pieniądza. Zjechałeś też temat skalowalności na przykładzie Solany, co idealnie trafia w punkt. Dlaczego ludzie z branży Web3 tak często cisną po EVM, nazywając go antykiem? Chodzi o sekwencyjne przetwarzanie transakcji. Wyobraź sobie globalny stan sieci jako jedną wielką bazę danych, a architekturę środowiska EVM jako starszą kasjerkę w markecie. Nieważne czy przyszło nagle 100 osób z jednym batonikiem, czy jedna osoba z dwoma pełnymi wózkami gruzu, wszyscy grzecznie stoją w jednym, wąskim sznureczku i obsługiwani są absolutnie jeden po drugim. Single-threaded na pełnej kurwie. Nie da się przetworzyć dwóch oddzielnych transferów w tym samym ułamku sekundy na głównym łańcuchu. I tutaj z buta wjeżdża konkurencja z nowej fali Web3. Nowsze wirtualne maszyny blockchain, takie jak MoveVM w sieciach Sui i Aptos, czy wirtualne środowisko Sealevel w Solanie, obsługują paralelizację (przetwarzanie równoległe). Jak to działa na czysty chłopski rozum? Jeżeli ja wysyłam USDC do kumpla "A", a ty w tym samym czasie robisz trade na zupełnie innym deksie i wchodzisz w interakcję z pulą płynności "B", to nasze wywołania kontraktów fizycznie w ogóle się nie krzyżują, bo nie dotykają tych samych komórek pamięci. Zamiast pakować nasze requesty w jedną wspólną kolejkę, taka Solana odpala wiele wirtualnych kas fiskalnych naraz i mieli transakcje równolegle wykorzystując wiele rdzeni procesora węzła. To jest totalna przepaść wydajnościowa i główny powód, dlaczego potrafią oni kręcić po kilkadziesiąt tysięcy TPS (transakcji na sekundę), podczas gdy sieć Ethereum ze swoim przestarzałym wirtualnym środowiskiem dławi się przy marnej kilkunastu. Poruszyłeś też bolesny problem storage'u. Maszyna Ethereum trzyma wszystkie globalne dane w ogromnej, skomplikowanej strukturze zwanej Merkle Patricia Trie. Pod kątem weryfikacji kryptograficznej i bezpieczeństwa to jest absolutny sztos. Łatwo udowodnić, że konkretny adres ma konkretne saldo. Niestety, aktualizowanie tego potwora i grzebanie w jego gałęziach po każdej zmianie stanu to istny koszmar dla operacji odczytu i zapisu (I/O) na dyskach węzłów. Stan sieci nieustannie i nieodwracalnie puchnie, co w krypto nazywamy "state bloat". Odczyt danych (komenda SLOAD) i nadpisanie ich (SSTORE) na poziomie języka Solidity to absolutnie najwięksi pożeracze gazu. Konkurencyjne rozwiązania i środowiska uruchomieniowe smart kontraktów próbują od początku projektować to inaczej, mapując pamięć w sposób mniej obciążający hardware węzłów. I to nas prowadzi do najważniejszego paradoksu w twoim wpisie: skoro EVM posiada tyle absurdalnych wad technicznych, tworzy potężne wąskie gardła i działa jak stary czołg, to dlaczego tyle nowych projektów (warstw L1 i L2) robi wszystko, żeby ich sieci były w pełni EVM-compatible? Dlaczego po prostu nie napiszą sobie silnika od nowa? Odpowiedź sprowadza się do efektu sieciowego (network effects) i zjawiska Lindy. Pomyśl przez chwilę... co z tego, że odpalisz sobie ultra-wydajne, autorskie, rozproszone środowisko wykonawcze napisane w Rust, jeśli nikt na świecie nie umie w nim postawić kodu? Wokół architektury Ethereum Virtual Machine wyrosła przez lata kolosalna, niezatapialna infrastruktura programistyczna. Mamy Hardhat, Truffle, Foundry, sprawdzone biblioteki ethers.js. Mamy tony perfekcyjnie przetestowanych standardów bezpieczeństwa od OpenZeppelin. Audytorzy smart kontraktów znają na wylot każdy możliwy błąd i wektor ataku w Solidity. Gdy tworzysz od zera nową sieć Rollup i odpalasz u siebie kompatybilność z maszyną EVM, pozwalasz devom z największych protokołów typu Uniswap, Aave czy Curve wziąć ich sprawdzony kod bajtowy, kliknąć "deploy" i przerzucić aplikację na twój chain w kilka godzin. Bez kosztownego przepisywania logiki, bez wydawania setek tysięcy na nowe audyty, bez zmuszania teamów do nauki obcego języka o którym nic nie wiedzą. To jest poprostu czysty biznes – bycie EVM-compatible daje ci instant dostęp do największej na rynku płynności (TVL) i rzeszy użytkowników. Pytałeś też o projekty z WebAssembly (eWASM). WASM ma taką potężną zaletę, że to ogólnoświatowy standard, a nie hermetyczny wymysł krypto-nerdów. Daje deweloperom luksus pisania skryptów w znanych językach jak C++, Go czy Rust, które potem kompilator mieli na niezwykle lekki, super zoptymalizowany pod sprzęt format binarny, a nie ociężały bytecode EVM. Ekosystemy zbudowane na Cosmos SDK czy cały Polkadot bardzo agresywnie w to weszły. W samej fundacji Ethereum też przez lata trwała gruba dyskusja o całkowitym wywaleniu EVM i przejściu na eWASM (często trąbiono o tym przy okazji roadmapy na ETH 2.0). Koniec końców fundacja uznała, że operacja na otwartym sercu u pacjenta, który obraca setkami miliardów dolarów na żywo, niesie zbyt ekstremalne ryzyko. Poszli w bezpieczniejsze skalowanie przez sieci L2, zachowując starą, poczciwą, ale zbadaną pod każdym mikroskopem wirtualną maszynę krypto na warstwie bazowej. Reasumując to przydługie wypracowanie: czemu w ogóle nowi twórcy sieci podejmują morderczą walkę próbując robić alternatywy od zera? Bo wiedzą, że ograniczenia EVM są na dłuższą metę nie do przeskoczenia pod kątem globalnej masowej adopcji. Architekturę EVM można przyrównać do ogromnego, starego silnika V8 z amerykańskiego muscle cara. Jest cholernie nieefektywny i pożera zasoby, ale z drugiej strony każdy mechanik w mieście potrafi go naprawić, ma pełno części zamiennych, a rynek kocha jego brzmienie. Nowoczesne maszyny wirtualne na blockchainie (te implementujące MoveVM czy środowiska na WASM) są próbą zbudowania od postaw sterylnego, bezpiecznego reaktora nuklearnego. Są szybkie, bezpieczniejsze w obsłudze na poziomie kompilatora i zjadają sekwencyjne EVM na śniadanie. Problem jest taki, że zbudowanie do nich całej otoczki dev-toolsów, adopcji i zaufania wymaga czasu i wyrzeczeń. Napewno ta technologiczna wojna będzie w krypto trwać jeszcze wiele lat, ale moim zdaniem dominacja środowisk kompatybilnych z Ethereum szybko się nie skończy, bo czysta moc obliczeniowa przeważnie przegrywa z siecią kontaktów, miliardami w DeFi i zwykłym brakiem czasu deweloperów. Mam cichą nadzieję, że chociaż trochę ci to łopatologicznie ułożyło klocki w głowie. Jeśli masz ochotę kopać w tym głębiej, mega polecam rzucić okiem na artykuły o "EVM Opcodes" i przestudiować, jak fizycznie na bitach funkcjonuje pamięć w tym silniku. To bardzo drastycznie uświadamia, dlaczego pewne optymalizacje w kodzie blockchainowym kosztują fortune, a inne grosze. Pozdro i powodzenia w dalszej rozkminie Web3!]]> Kwestie techniczne i kopanie kryptowalut GrubyLaptop https://www.naszakasa.org.pl/kwestie-techniczne-i-kopanie-kryptowalut/czym-rozni-sie-maszyna-wirtualna-ethereum-evm-od-innych/#post-184 https://www.naszakasa.org.pl/kwestie-techniczne-i-kopanie-kryptowalut/czym-rozni-sie-maszyna-wirtualna-ethereum-evm-od-innych/#post-183 Mon, 30 Mar 2026 23:49:38 +0000 architektura EVM wydaje się działać na zupełnie innych zasadach. Przecież to potężne, rozproszone środowisko wykonawcze musi ogarniać tysiące węzłów na całym świecie, aktualizować wspólny stan sieci i jeszcze pilnować, żeby nikt nie zhakował systemu. Zastanawiam się, co sprawia, że Ethereum Virtual Machine jest tak bardzo specyficzna na tle klasycznego IT, ale też na tle nowszej konkurencji z branży Web3. Zauważyłem, że sporo projektów chwali się tym, że są w pełni EVM-compatible (kompatybilne z maszyną Ethereum), co mega ułatwia devom przerzucanie dAppsów napisanych pierwotnie w Solidity bez przepisywania całego kodu. Ale z drugiej strony mamy np. Solanę, która forsuje swoje własne, podobno dużo szybsze środowisko, albo projekty stawiające na eWASM (WebAssembly) w blockchainie. Co takiego unikalnego ma w sobie ta oryginalna maszyna wirtualna sieci Ethereum, że z jednej strony wszyscy chcą być z nią zgodni i zrzynać standardy, a z drugiej – non stop próbują ją zaorać wytykając jej archaiczność i powolność? Dużo czytałem o tym, jak działa mechanizm opłat za gaz (gas fees). Z tego co łapię, to chyba główna różnica w stosunku do normalnych VM, bo na zwykłym serwerze nie płacisz za każdą pojedynczą operację obliczeniową czy zapis do pamięci. Tutaj kod to dosłownie hajs. Jak zrobisz nieskończoną pętlę albo źle zoptymalizujesz skrypt, to ci poprostu wyzeruje portfel i elo, transakcja odrzucona. Czy ten rygorystyczny determinizm i koszty to jest ta główna rzecz wyróżniająca evm? A może chodzi bardziej o to, jak maszyna ethereum zarządza stanem kont i storage'em? Bo z tego co kminię, to ten wbudowany globalny stan blockchaina to jest jakiś koszmar pod kątem skalowalności. Gdzieś mi mignęło, że EVM przetwarza transakcje sekwencyjnie, jedną po drugiej, podczas gdy inne, nowsze wirtualne maszyny krypto potrafią robić to równolegle. Chcę to zrozumieć tak na czysto chłopski rozum. Dlaczego twórcy nowych łańcuchów (np. warstw L1 i L2) czasem decydują się na pisanie od zera własnych środowisk do smart kontraktów, zamiast po prostu kopiować gotowy, przetestowany silnik od fundacji Ethereum? Jakie są te absolutnie fundamentalne różnice w budowie i działaniu? Będę wdzięczny za jakieś łopatologiczne wyjaśnienia albo sprawdzone linki do mądrych artykułów, bo utknąłem na tym temacie i za nic nie mogę tego wziąść na logikę. Z góry wielkie dzięki za pomoc!]]> Kwestie techniczne i kopanie kryptowalut KoderMaster https://www.naszakasa.org.pl/kwestie-techniczne-i-kopanie-kryptowalut/czym-rozni-sie-maszyna-wirtualna-ethereum-evm-od-innych/#post-183