Dezvoltatorul Semnalează Riscuri Majore în Propunerea de Soft Fork pentru Reducerea Datelor Bitcoinului

Revizuirea Datelor Tranzacțiilor Arată Că RDTS Ar Putea Bloca Cazuri Cheie de Utilizare Bitcoin

O nouă propunere de soft fork concepută pentru a reduce excesul de stocare de date pe blockchain-ul Bitcoin atrage critici ascuțite în ultimele vremuri. Miercuri, analistul independent și dezvoltatorul mempool.space, Mononaut, a publicat o evaluare care detaliază daunele colaterale potențiale pe care regulile ar putea să le cauzeze.

Propunerea, cunoscută sub numele de Softfork Temporar de Date Reducate (RDTS), introduce un set de restricții la nivel de consens menite să reducă tranzacțiile grele în date—un efort pe care dezvoltatorii îl consideră necesar, în urma actualizării Bitcoin Core v30 care a eliminat limitele asupra datelor OP_RETURN.

RDTS ar fi aplicabil pentru aproximativ un an dacă este activat, limitând scriptPubKeys la 34 de octeți, plafonând ieșirile OP_RETURN la 83 de octeți, restricționând blocurile de control Taproot, interzicând versiunile de martori nedefinite și dezactivând categorii întregi de logică Tapscript. Susținătorii BIP susțin că măsurile acționează ca o frână de urgență împotriva încărcărilor de date arbitrare care ar putea expune operatorii de noduri la responsabilitate legală dacă materialul ilegal ar fi încorporat în lanț.

Evaluarea lui Mononaut, însă, cuantifică impactul practic al acestor restricții prin revizuirea activității istorice a blockchain-ului pentru a vedea care tranzacții reale ar fi violat regulile propuse. Constatările sale sugerează o întrerupere semnificativă. Sub limita de dimensiune a scriptPubKey, toate ieșirile pay-to-public-key (P2PK) și multisig (P2MS) ar fi invalide. Această restricție afectează, de asemenea, un număr mic de ieșiri non-standard din tranzacțiile trecute.

Una dintre regulile mai ample—invalidarea operațiunilor OP_PUSHDATA cu încărcături mai mari de 256 de octeți—nu ar afecta plicurile de inscripție, presupunând că numai operațiunile efectuate califică. Dar Mononaut a subliniat că versiunile de martori nedefinite ar afecta mai mult de 54.000 de tranzacții istorice, multe dintre ele utilizând ieșiri neconvenționale pentru a ocoli limitele de date OP_RETURN. Deoarece lungimile versiunilor de martori sunt definite strict în BIP-uri 141 și 341, propunerea așa cum este scrisă ar bloca chiar și unele formate moderne valide precum ancorele P2A.

Citește și: Dezvoltatorii Bitcoin Core Integrează Modificări de Politică Controversate: Urmează un Fork?

Mononaut a detaliat că RDTS invalidează, de asemenea, stivele de martori care conțin un anex Taproot. Deși rare, dezvoltatorul mempool.space observă că cel puțin 11 tranzacții au folosit un anex pentru scopuri grele în date. O categorie mai semnificativă, Mononaut a subliniat, o reprezintă blocurile de control Taproot mari: aproximativ 32.000 de cheltuieli anterioare includ blocuri de control de adâncime 100+ utilizate adesea pentru încorporarea de date, dar chiar și unele experimente non-date se bazează pe configurații mai mici și legitime care ar fi dezactivate. O adresă activă cheltuie constant la o adâncime de bloc de control 11, care ar fi respinsă sub RDTS.

Cele mai stricte elemente din propunere—interzicerea OP_SUCCESS* și a oricărui Tapscript care execută OP_IF sau OP_NOTIF—depășesc cu mult plicurile de inscripție. Mononaut subliniază două tranzacții istorice OP_SUCCESS, incluzând tranzacția de rupere a fulgerului lui Burak, și aproximativ 70 de cheltuieli Taproot bazate pe OP_IF non-inscripționale. Câteva dintre acestea sunt primitive financiare, incluzând șabloane multisig perisabile și designuri contractuale hash-time-locked (HTLC). Unele provin din portofele care au dezactivat în mod intenționat calea lor de cheie, lăsând cheltuirea pe calea scriptului ca singura modalitate de a muta fonduri.

Susținătorii RDTS au susținut că utilizatorii cu scripturi afectate ar putea să se bazeze pe cheltuirea pe calea cheii. Totuși, datele lui Mononaut contestă direct acea presupunere: aproximativ 560.000 de cheltuieli Taproot istorice provin din ieșiri a căror cale de cheie a fost demonstrabil dezactivată, făcând OP_IF și funcții similare esențiale, mai degrabă decât opționale.

Susținătorii soft fork-ului temporar mențin că RDTS este o măsură de protecție pe termen scurt concepută pentru a păstra utilitatea monetară a Bitcoin, preveni riscurile legale și reduce încărcările pe noduri prin limitarea stocării de date. Criticii contraargumentează că restricțiile ample asupra comportamentului Tapscript riscă să introducă un de facto cenzură, dezactivând tipuri valide de tranzacții și străpungând aplicațiile existente.

Dezbaterea reflectă dispute mai vechi asupra creșterii datelor conduse de inscripții, reflectând dezacorduri mai profunde privind dacă Bitcoin ar trebui să rămână strict monetar sau să continue să acomodeze utilizările experimentale. Pe măsură ce propunerea rămâne în formă de draft, discuția este în desfășurare între dezvoltatori, cercetători și participanți la ecosistem.

FAQ ❓

• Ce este RDTS?
  O propunere temporară de soft fork care restricționează mai multe caracteristici de script și date Bitcoin.
• De ce se dezbate RDTS?
  Susținătorii doresc să reducă abuzul de date, în timp ce criticii spun că dezactivează tranzacții valide.
• Ce a descoperit Mononaut?
  Analiza sa arată că multe tranzacții istorice ar eșua în conformitate cu regulile RDTS.
• Cât timp ar dura RDTS?
  Propunerea prevede o fereastră de activare de un an, dacă este adoptată.