Kompletność Turinga to cecha systemu obliczeniowego, który potrafi wykonać dowolny algorytm, jaki da się w ogóle zapisać, pod warunkiem że ma wystarczająco dużo czasu i pamięci. Nazwa pochodzi od Alana Turinga, brytyjskiego matematyka, który w 1936 roku opisał abstrakcyjną „maszynę Turinga”, czyli teoretyczny model każdego komputera.
W praktyce system jest kompletny w sensie Turinga, jeśli ma dwie rzeczy: instrukcje warunkowe („jeśli X, zrób Y”) i możliwość powtarzania (pętle albo rekurencję) przy nieograniczonej pamięci.
W kryptowalutach to pojęcie wraca w jednym sporze: Ethereum jest kompletne w sensie Turinga, a Bitcoin celowo nie. To nie przypadek i nie zaniedbanie. To dwie różne filozofie bezpieczeństwa.
Kompletność Turinga jest łatwiejsza, niż myślisz
Kompletność Turinga brzmi jak cecha zaawansowanych systemów, ale to raczej niski próg. Da się ją osiągnąć w miejscach, o które nikt by nie podejrzewał:
- w arkuszu Excel, od kiedy dodano funkcję LAMBDA,
- w animacjach PowerPointa, co ktoś zademonstrował dla żartu,
- w karcianej grze Magic: The Gathering, co opisano w pracy naukowej,
- w obwodach z czerwonego kamienia w grze Minecraft.
Wniosek jest ważny dla inwestora: kompletność Turinga nie jest ani rzadka, ani szczególnie cenna. To cecha, którą bardzo łatwo mieć. Pytanie brzmi, czy się jej chce.
Problem stopu
W tym samym 1936 roku Turing udowodnił coś, co ma bezpośrednie konsekwencje dla blockchainów. Nie istnieje ogólny sposób, żeby dla dowolnego programu z góry stwierdzić, czy kiedykolwiek się zatrzyma. To tak zwany problem stopu.
Teraz wyobraź sobie sieć, w której tysiące węzłów wykonują ten sam kod. Jeśli ktoś wyśle program z nieskończoną pętlą, a węzły nie mogą tego z góry wykryć, to wszystkie utkną. Jedna transakcja zatrzymuje cały blockchain.
Bitcoin i Ethereum rozwiązały ten problem na dwa zupełnie różne sposoby.
Bitcoin: brak pętli z założenia
Bitcoin Script to prosty język stosowy bez pętli. Każdy skrypt wykonuje się raz, od początku do końca, a koszt jego sprawdzenia da się łatwo przewidzieć z góry. Problem stopu po prostu nie występuje.
W 2010 roku Satoshi Nakamoto poszedł jeszcze dalej i wyłączył kilka instrukcji, w tym OP_CAT i operacje mnożenia, po znalezieniu błędów, które mogły posłużyć do ataku na węzły. Filozofia jest jasna: im mniej potrafi język, tym mniej rzeczy może w nim pójść źle.
Mimo to Bitcoin ma smart kontrakty, tylko proste: multisig, blokady czasowe, zabezpieczenia hashem. Na nich zbudowano między innymi Lightning Network. W 2023 roku pojawił się też BitVM, który pozwala weryfikować dowolne obliczenia wykonywane poza łańcuchem, bez dodawania do Bitcoina kompletności Turinga. W społeczności wciąż trwa dyskusja, czy przywrócić OP_CAT albo dodać inne rozszerzenia, ale każda zmiana idzie tu bardzo powoli.
Ethereum: kompletność z limitem gas
Ethereum wybrało drugą drogę. Maszyna wirtualna EVM obsługuje pętle, rekurencję i dowolne obliczenia. Problem stopu rozwiązano ekonomicznie: każda instrukcja kosztuje gas, a każda transakcja ma limit gas.
Program z nieskończoną pętlą nie zatrzyma sieci. Zatrzyma się sam, gdy skończy się opłacony gas. Transakcja zostanie wtedy cofnięta, ale opłata przepada, bo węzły wykonały pracę.
Policzmy: wysyłasz transakcję z błędem powodującym nieskończoną pętlę i ustawiasz limit na 100 000 gas.
- przy cenie 2 gwei płacisz 100 000 × 2 gwei = 0,0002 ETH,
- przy ETH po około 2700 dolarów to około 55 centów,
- sieć nic nie odczuła, a Ty zapłaciłeś za swój błąd.
Dlatego o Ethereum mówi się czasem „prawie kompletne w sensie Turinga”. Teoretycznie potrafi wszystko, ale każde obliczenie jest ograniczone budżetem, a cały blok limitem 60 mln gas.
Bitcoin Script a EVM
| Bitcoin Script | EVM (Ethereum) | |
|---|---|---|
| Kompletność Turinga | nie | tak, w granicach limitu gas |
| Pętle | brak | są |
| Jak rozwiązano problem stopu | brak pętli | opłata za każdy krok i limit gas |
| Przewidywalność kosztu | bardzo wysoka | trzeba szacować przed wysłaniem |
| Typowe zastosowania | płatności, multisig, blokady czasowe, Lightning | DeFi, tokeny, NFT, DAO |
| Powierzchnia ataku | mała | duża |
Cena elastyczności
Kompletność Turinga daje ogromne możliwości. Na niej wyrosło całe DeFi. Ale każda dodatkowa możliwość to dodatkowe miejsce na błąd.
The DAO (2016). Fundusz inwestycyjny zbudowany jako smart kontrakt zebrał ogromną część wszystkich ETH w obiegu. Błąd typu reentrancy pozwolił atakującemu wyprowadzić około 3,6 mln ETH. Społeczność zdecydowała się na hard fork, który cofnął skutki ataku. Część osób się nie zgodziła i została przy starym łańcuchu. Tak powstało Ethereum Classic.
Parity (2017). Użytkownik, prawdopodobnie przez przypadek, wywołał funkcję, która zniszczyła bibliotekę używaną przez wiele portfeli multisig. Około 513 tys. ETH zostało zamrożonych na zawsze. Nikt tego nie ukradł. Po prostu nikt już nie może tych środków ruszyć.
Od tego czasu każdego roku z protokołów DeFi i mostów wyciekają setki milionów, a bywa, że miliardy dolarów. W Bitcoinie podobne kategorie błędów praktycznie nie występują, bo język nie pozwala napisać tak złożonego kodu.
Trzecia droga: ograniczenia w języku i modelu danych
Między „bez pętli” Bitcoina a „wszystko wolno, byle za gas” Ethereum są też inne podejścia. Nie odbierają kompletności Turinga, ale utrudniają popełnianie najgroźniejszych błędów.
Cardano (model eUTXO). Cardano rozszerzyło bitcoinowy model niewydanych wyjść o możliwość dołączania do nich logiki kontraktów. Transakcja z góry deklaruje, jakie wyjścia wydaje, więc jej wynik i opłatę można sprawdzić przed wysłaniem. Nie ma sytuacji, w której transakcja nie przejdzie, a opłata i tak przepadnie z powodu zmiany stanu sieci w międzyczasie. Ceną jest trudniejsze programowanie aplikacji, w których wiele osób jednocześnie korzysta z tego samego kontraktu.
Sui i Aptos (język Move). Move traktuje aktywa jak zasoby, których nie da się skopiować ani przypadkowo zniszczyć. Kompilator pilnuje, żeby tokena nie dało się skopiować ani przez nieuwagę zgubić. Cała klasa błędów, które w Solidity trzeba wyłapywać ręcznie, jest tu blokowana na poziomie języka. To nie znaczy, że kontrakty w Move są bezbłędne, bo błędy logiczne dalej się zdarzają, ale część pułapek po prostu nie istnieje.
Wniosek dla Ciebie: kompletność Turinga to nie jest przełącznik „tak albo nie”. Ważne jest też, ile język pozwala zepsuć przez nieuwagę.
Co to oznacza w praktyce, gdy korzystasz z DeFi
Kilka rzeczy, które wynikają bezpośrednio z kompletności Turinga i które widzisz w portfelu:
- Szacowanie gas może się nie udać. Portfel próbuje przewidzieć, ile kosztuje transakcja, symulując ją na obecnym stanie sieci. Jeśli stan zmieni się, zanim transakcja trafi do bloku, może zużyć więcej, skończyć się błędem „out of gas” i kosztować Cię opłatę bez żadnego efektu.
- Nieudana transakcja też kosztuje. Węzły wykonały pracę, więc opłata przepada, nawet jeśli nic się nie stało.
- Kontrakt, z którym dziś rozmawiasz, jutro może działać inaczej. Wiele protokołów używa kontraktów aktualizowalnych, w których logikę można podmienić. Kompletność Turinga oznacza, że nowy kod może zrobić dosłownie wszystko, na co mu pozwolisz swoimi zgodami.
Najczęstsze nieporozumienia
„Kompletność Turinga czyni blockchain lepszym.” Czyni go bardziej elastycznym. Czy lepszym, zależy od tego, do czego go używasz. Do przechowywania wartości prostota jest zaletą.
„Bitcoin nie ma smart kontraktów.” Ma, tylko proste. Multisig i blokada czasowa to smart kontrakty.
„Gas to tylko opłata dla walidatorów.” Gas to przede wszystkim mechanizm ochrony sieci. Bez niego kompletność Turinga oznaczałaby, że jedna transakcja może zatrzymać wszystko.
Co ja o tym myślę
Spór o kompletność Turinga jest dla mnie w gruncie rzeczy sporem o to, gdzie ma leżeć ryzyko. Bitcoin mówi: mało potrafię, ale to, co potrafię, jest przewidywalne i trudne do zepsucia. Ethereum mówi: potrafię wszystko, a ryzyko przenoszę na autorów kontraktów i użytkowników.
Oba podejścia są uczciwe, tylko służą czemu innemu. Z tego wynika praktyczna zasada, niezależnie od sieci. Pieniądze, które mają leżeć latami, powinny leżeć tam, gdzie jest najmniej ruchomych części. Pieniądze do eksperymentów mogą trafić tam, gdzie możliwości są większe, ale wtedy zakładaj, że każdy kontrakt może mieć błąd, którego jeszcze nikt nie znalazł.
Kompletność Turinga to nie jest funkcja, za którą płacisz premię. To jest ryzyko, które przejmujesz razem z możliwościami.
