Po pierwsze, istnieje wiele powodów, dla których ktoś chciałby przechowywać wszystkie bloki, a nie tylko uruchamiać przycięty węzeł - zobacz post @FractalEncrypt na ten temat.
Po drugie, plebs nie jest normą. Może nie są twórcami protokołów, ale wiedzą, jak działają węzły. To trochę obraźliwe zakładać, że plebs nie zna problemu z balonowaniem zestawu UTXO.
Moduły uruchamiające węzły nie chcą śmieci w zestawie UTXO OR w OP_RETURN. Gdyby zwolennicy zniesienia limitu poświęcili choćby 1 minutę na wysłuchanie użytkowników, zrozumieliby to. Zamiast tego są to tyrady typu "my wiemy lepiej" i "ty nie rozumiesz".
W najlepszym razie usunięcie limitu OP_RETURN w żaden sposób nie naprawia sytuacji. Całe uzasadnienie Core Dev za usunięciem limitu jest pełne słów takich jak "może" i "może" rozwiązać problem.
W najgorszym przypadku wprowadziliśmy nowy wektor ataku, aby wyprzeć transakcje finansowe, zidentyfikowane przez @LaurentMT.
"Zestaw UTXO miał kiedyś około 4 GB. Ze względu na inskrypcje i BRC-20 urósł do około 12 GB."
Plebs jest w pełni świadomy.
Pytanie tylko, co z tym zrobić.
Myślę, że dużym rozdźwiękiem jest to, że większość normies nie wie, jaki jest rozmiar zestawu UTXO, rozumieją tylko "rozmiar bloku".
Mówiąc prościej, rozmiar łańcucha bloków (tj. całkowity rozmiar wszystkich bloków) wpływa tylko na początkowy czas synchronizacji podczas konfigurowania węzła od zera. Może to wzrosnąć maksymalnie o 4 MB na blok (realistycznie około 2 MB).
Teoretycznie musisz zsynchronizować węzeł od zera tylko raz w życiu... w przypadku nowych węzłów możesz pominąć synchronizację, pobierając zestaw UTXO, a następnie sprawdzając, czy nowy węzeł ma ten sam skrót zestawu UTXO, co jeden ze starszych węzłów.
NIE MUSISZ przechowywać wszystkich bloków, ani nie powinieneś, chyba że masz całkiem dobry powód.
Tak więc optymalizacja rozmiaru łańcucha bloków nie zmniejsza znacząco minimalnych zasobów wymaganych do uruchomienia węzła. W najlepszym przypadku nieznacznie zmniejsza zużycie przepustowości. Jeśli przechowujesz wszystkie bloki, ze względu na obecną regułę konsensusu, powinieneś i tak zaplanować zwiększenie o 2 MB na bloki w celu zaplanowania aktualizacji sprzętu.
Ważniejsze niż rozmiar blockchaina, jest to, co każdy MUSI przechowywać: rozmiar zestawu UTXO.
Programiści znacznie bardziej dbają o rozmiar zestawu UTXO, ponieważ określa on minimalną pamięć masową wymaganą do uruchomienia pełnego węzła. ("Pełny węzeł" oznacza, że weryfikujesz wszystkie bloki, niekoniecznie przechowujesz je wszystkie).
Zestaw UTXO miał kiedyś około 4 GB. Ze względu na inskrypcje i BRC-20 urósł do około 12 GB.
Zestaw UTXO nie przechowuje OP_RETURN danych ani podpisów.
Jeśli chcesz, aby Twój węzeł działał płynnie na małych urządzeniach, skup się na zminimalizowaniu rozmiaru zestawu UTXO, a nie rozmiaru łańcucha bloków. I właśnie dlatego wielu deweloperów tak naprawdę nie przejmuje się ograniczeniami OP_RETURN.
558
60,87 tys.
Treści na tej stronie są dostarczane przez strony trzecie. O ile nie zaznaczono inaczej, OKX nie jest autorem cytowanych artykułów i nie rości sobie żadnych praw autorskich do tych materiałów. Treść jest dostarczana wyłącznie w celach informacyjnych i nie reprezentuje poglądów OKX. Nie mają one na celu jakiejkolwiek rekomendacji i nie powinny być traktowane jako porada inwestycyjna lub zachęta do zakupu lub sprzedaży aktywów cyfrowych. Treści, w zakresie w jakim jest wykorzystywana generatywna sztuczna inteligencja do dostarczania podsumowań lub innych informacji, mogą być niedokładne lub niespójne. Przeczytaj podlinkowany artykuł, aby uzyskać więcej szczegółów i informacji. OKX nie ponosi odpowiedzialności za treści hostowane na stronach osób trzecich. Posiadanie aktywów cyfrowych, w tym stablecoinów i NFT, wiąże się z wysokim stopniem ryzyka i może podlegać znacznym wahaniom. Musisz dokładnie rozważyć, czy handel lub posiadanie aktywów cyfrowych jest dla Ciebie odpowiednie w świetle Twojej sytuacji finansowej.