A fejlesztő jelentős kockázatokra figyelmeztet a javasolt Bitcoin csökkentett adat soft fork kapcsán

A tranzakciós adatok áttekintése megmutatja, hogy az RDTS blokkolhatja a kulcsfontosságú Bitcoin felhasználási eseteket

Egy új soft fork javaslat, amely a Bitcoin blokkláncon tárolt túlzott adattárolás megfékezését célozza, éles kritikát váltott ki a közelmúltban. Szerdán a független elemző és mempool.space fejlesztő, Mononaut közzétett egy értékelést, amely felvázolja a szabályrendszer által okozott potenciális járulékos veszteségeket.

A javaslat, amely Csökkentett Adatok Ideiglenes Softfork (RDTS) néven ismert, egy sor konszenzus szintű korlátozást vezet be, amelyek célja az adattartamú tranzakciók csökkentése—a fejlesztők szerint ez szükséges a Bitcoin Core v30 frissítése után, amely eltávolította az OP_RETURN adatok korlátait.

Az RDTS körülbelül egy évig lenne érvényben, ha aktiválásra kerül, korlátozva a scriptPubKeys-t 34 byte-ra, az OP_RETURN kimeneteket 83 byte-ban, a Taproot vezérlő blokkokat, tiltva a meghatározatlan tanúverziókat, és letiltva a Tapscript logikájának egész kategóriáit. A BIP támogatói azt állítják, hogy ezek az intézkedések adattartamú feltöltések sürgősségi fékeként szolgálnak, amelyek potenciálisan jogi felelősséget jelenthetnek a node üzemeltetők számára, ha illegális anyagokat ágyaznának be a láncba.

Mononaut értékelése azonban számszerűsíti ezeknek a korlátozásoknak a gyakorlati következményeit, korábbi blokklánc tevékenységek áttekintésével, hogy megvizsgálják, mely valós tranzakciók szegnék meg a javasolt szabályokat. Megállapításai jelentős zavart sugallnak. A scriptPubKey méretkorlát alapján önmagában minden pay-to-public-key (P2PK) és multisig (P2MS) kimenet érvénytelen lenne. Ez a korlátozás érinti a múltbeli tranzakciók nem szabványos kimeneteinek kis részét is.

Az egyik legátfogóbb szabály—az OP_PUSHDATA műveletek 256 byte feletti hasznos terhekkel történő érvénytelenítése—nem érinti az inskripciós borítékokat, feltéve, ha csak a végrehajtott push-okra vonatkozik. De Mononaut hangsúlyozta, hogy a meghatározatlan tanúverziók több mint 54,000 történelmi tranzakciót érintenének, amelyek közül sok az OP_RETURN adatokra vonatkozó korlátok megkerülésére használt nem szokványos kimeneteket alkalmazott. Mivel a tanúverziók hosszúsága szigorúan definiált a BIP 141 és 341 szerint, a javaslat, ahogy íródott, még néhány érvényes modern formátumot is blokkolna, mint például a P2A horgonyokat.

További olvasnivaló: A Bitcoin Core fejlesztők egyesítik a vitatott politikai változásokat: Szétválás következhet?

Mononaut részletezte, hogy az RDTS érvényteleníti az olyan tanúhalmokat is, amelyek Taproot mellékletet tartalmaznak. Bár ritka, a mempool.space fejlesztő megjegyzi, hogy legalább 11 tranzakció használta az adatintenzív célú mellékletet. Egy jelentősebb kategória, ahogy Mononaut hangsúlyozta, a nagy Taproot vezérlőblokkok: körülbelül 32,000 korábbi költés tartalmaz 100-nál nagyobb mélységű vezérlőblokkokat, amelyeket gyakran használnak adatbeágyazásra, de még néhány nem-adat kísérlet is támaszkodik kisebb, legitim konfigurációkra, amelyeket letiltanának. Egy aktív cím következetesen költ vezérlőblokk mélység 11-nél, amelyet az RDTS elutasítana.

A javaslat legszigorúbb tételei—az OP_SUCCESS* és bármely Tapscript OP_IF vagy OP_NOTIF végrehajtásának tiltása—messze túlmutatnak az inskripciós borítékokon. Mononaut kiemel két történelmi OP_SUCCESS tranzakciót, beleértve Burak villám-romboló tranzakcióját, és körülbelül 70 nem-enscription OP_IF-alapú Taproot költést. Több ezek közül pénzügyi primitív, beleértve a lejáró multisig sablonokat és a hash-time-locked contract (HTLC) tervezéseket. Néhány ezek közül szándékosan letiltotta a kulcse utat, így az skript-útvonal költések maradtak az egyetlen lehetőségként a pénzek mozgatására.

Az RDTS támogatói állították, hogy az érintett skriptek felhasználói visszatérhetnek a kulcsúú vágáshoz. Mégis, Mononaut adatai közvetlenül kihívják ezt a feltételezést: körülbelül 560,000 történelmi Taproot költés származik olyan kimenetekből, ahol a kulcsút bizonyíthatóan le volt tiltva, így az OP_IF és hasonló funkciók inkább lényegesek, mintsem opcionálisak.

A javasolt ideiglenes soft fork támogatói fenntartják, hogy az RDTS egy rövid távú védelmi intézkedés, amely a Bitcoin monetáris hasznosságának megőrzésére, jogi kockázatok elkerülésére, és a node terhekként jelentkező adattárolás csökkentésére szolgál. A kritikusok azzal érvelnek, hogy a Tapscript viselkedésének széles korlátozása kockázatot jelent a de facto cenzúra bevezetésére, érvényes tranzakció típusok letiltására, és a meglévő alkalmazások megszakítására.

A vita tükrözi a korábbi vitákat az inskripció-vezérelt adatok növekedése kapcsán, ami mélyebb nézeteltéréseket tükröz arról, hogy a Bitcoin maradjon szigorúan monetáris, vagy továbbra is kísérleti felhasználásokat fogadjon el. A javaslat tervezet formájában marad, és a fejlesztők, kutatók és az ökoszisztéma résztvevői között folyik a vita.

GYIK ❓

• Mi az RDTS?
  Egy ideiglenes soft fork javaslat, amely számos Bitcoin szkript és adat funkciót korlátoz.
• Miért vitatják az RDTS-t?
  A támogatók szeretnék megfékezni az adatvisszaélést, míg a kritikusok azt mondják, hogy letiltja az érvényes tranzakciókat.
• Mit talált Mononaut?
  Elemzése szerint sok történelmi tranzakció nem felelne meg az RDTS szabályainak.
• Meddig tartana az RDTS?
  A javaslat egy éves aktiválási ablakot vázol fel, ha elfogadják.