Dlaczego łańcuchy nie-EVM są często reprezentowane przez główne protokoły DeFi, które są narażone na ataki? Mam obawy związane z inwestowaniem w DeFi na łańcuchach nie-EVM. W rzeczywistości, na łańcuchach takich jak Sui, Aptos, Stacks i innych, które nie są oparte na EVM, często dochodzi do ataków na główne protokoły DeFi. Dlatego, mimo że wiem, że zyski z depozytów @MMTFinance mogą być atrakcyjne, nie mogę wysłać dużej ilości aktywów. Dlaczego zatem łańcuchy nie-EVM są tak często narażone na ataki? Hacking blockchainów jest bardzo trudny. (Prawie niemożliwy, ale poprawiam się.) Jednak programowanie dla DeFi (smart kontrakty) jest zadaniem ludzkim, a ludzie zawsze popełniają błędy. Dlatego DeFi zawsze musi ponosić ryzyko ataków na protokoły. Łańcuchy EVM również doświadczyły ogromnych incydentów związanych z hackowaniem DeFi w historii. W miarę jak toczyła się ta historia, ekosystem Ethereum i EVM korzystał z niezliczonych otwartych źródeł, takich jak OpenZeppelin, Uniswap, Curve, które były wielokrotnie wykorzystywane, atakowane i weryfikowane. Oznacza to, że teraz istnieje wiele bezpiecznych otwartych źródeł, które można po prostu wykorzystać. Doświadczenie firm audytorskich w zakresie kodu smart kontraktów EVM jest zdecydowanie większe. Wręcz przeciwnie, Move używane w Sui czy Aptos jest, moim zdaniem, bardziej zaawansowanym językiem i VM dla blockchainów w wielu aspektach niż EVM/Solidity. Jednak kody łańcuchów nie-EVM nie zostały jeszcze wystarczająco zaatakowane i zweryfikowane. Ich historia jest krótka, a otwartych kodów jest niewiele, dlatego nawet firmy audytorskie mają ograniczone doświadczenie. Protokóły DeFi boją się ataków i nie mogą nawet otworzyć swojego kodu. To jak obawa przed robakami, które uniemożliwiają zrobienie przetworów.. Uważam, że to jest bardzo ważne zadanie, które łańcuchy nie-EVM muszą rozwiązać. Kluczowy protokół DeFi w ekosystemie, Alex, został dwukrotnie zaatakowany na Stacks i nie ma już możliwości odbudowy. Jeśli historia i doświadczenie nie mogą być rozwiązane przez społeczność i czas, fundacja musi prowadzić standaryzację kodu i jego dostarczanie. Dodatkowo, należy opracować środki, które zachęcą protokoły do otwierania swojego kodu oraz fundacja powinna aktywnie wspierać audyty.

W rzeczywistości 80% występujących włamań to działania wewnętrzne, ale naprawdę przypadków, w których "kod został źle napisany" i przez to doszło do włamania, w EVM czy Solanie już nie ma. A w przypadku działań wewnętrznych... Uważam, że lepiej jest pisać kontrakty w sposób, który uniemożliwia ich aktualizację, zamiast kierować się zasadą "Don't be evil", lepiej "Can't be evil".