[Wątek] Ignorowana prawda: prawdziwy powód otwarcia OP_RETURN w Bitcoin Core v30

Chainfeeds Wprowadzenie:

Zmiana polityki OP_RETURN w Bitcoin Core v30: to nie jest kapitulacja wobec Ordinals, lecz proaktywne ukierunkowanie ekosystemu BitVM. To nie jest bierna reakcja na spekulacje, ale wcześniejsze przygotowanie gruntu pod innowacje technologiczne. To dalekowzroczne myślenie deweloperów Core.

Źródło artykułu:

Autor artykułu:

Aaron Zhang

Poglądy:

Aaron Zhang: W kwietniu 2024 roku Citrea wypuściła pierwszy kompletny BitVM bridge — Clementine. To pierwszy zkRollup na Bitcoin, wykorzystujący BitVM do weryfikacji na L1. Następnie napotkali problem techniczny: musieli opublikować na łańcuchu 144 bajty danych kotwiczących. Te 144 bajty obejmują 128 bajtów: Groth16 zero-knowledge proof oraz 16 bajtów: total accumulated work (całkowity dowód pracy). Dane te są wykorzystywane, gdy Watchtower kwestionuje Operatora, aby udowodnić, że posiadają poprawny łańcuch Bitcoin. Pojawia się problem: OP_RETURN pozwala tylko na 83 bajty. To za mało. Ktoś mógłby zapytać, dlaczego nie umieścić tego w witness? Tak jak robią to Ordinals? Kluczowa różnica polega na tym, że kolejne transakcje weryfikacyjne Citrea muszą odczytać te dane. Jednak Bitcoin Script nie może odwoływać się do danych witness z poprzedniej transakcji. Dlatego dane muszą być w scriptPubKey, to nie jest opcjonalne. Mówiąc prościej: dane witness mogą jedynie potwierdzić ważność bieżącej transakcji, ale nie mogą być odczytane przez kolejne transakcje. Dane scriptPubKey mogą być odczytywane przez skrypty kolejnych transakcji. Logika weryfikacyjna BitVM wymaga łańcuchowego odwoływania się, więc musi korzystać ze scriptPubKey. 83 bajty to za mało, więc Citrea była zmuszona użyć bardzo złego rozwiązania: tworzenie „nie do wydania” Taproot outputs, maskując dane jako klucz publiczny. Problem tego rozwiązania polega na trwałym powiększaniu zbioru UTXO. Każda transakcja WatchtowerChallenge tworzy dwa UTXO, których nigdy nie da się oczyścić. Wszystkie pełne węzły muszą na zawsze przechowywać te fałszywe klucze publiczne. To właśnie najgorszy scenariusz, którego deweloperzy Core zawsze chcieli uniknąć. Łańcuch rozumowania deweloperów Core: obecnie Citrea używa fałszywych UTXO (złe rozwiązanie), w przyszłości więcej projektów BitVM może to naśladować lub używać gołych multisig (jak protokół Stamp). Wniosek: lepiej poluzować OP_RETURN, oferując „mniej szkodliwą” ścieżkę. To strategia harm reduction (redukcji szkód). Dlaczego Core chce utorować drogę BitVM? Ponieważ BitVM to ważny kierunek innowacji na Bitcoin L1. CEO Blockstream Adam Back powiedział: „Mechanizm anchor BitVM to ważny kierunek dla L1”. Jeśli ekosystem BitVM się rozwinie: różne zkRollups, cross-chain bridges i złożone weryfikacje on-chain będą miały podobne potrzeby kotwiczące.