O introducere în Scriptul Bitcoin

Introducere

Bitcoin este uneori denumit bani programabili. Datorită naturii sale digitale, oferă utilizatorilor un grad mare de flexibilitate atunci când vine vorba de stabilirea condițiilor pentru modul în care fondurile pot fi cheltuite.

Vorbim de portofele și monede atunci când discutăm despre Bitcoin. Dar ne-am putea gândi și la portofele ca la chei, la monede ca la cecuri și la blockchain ca rând după rând de seifuri încuiate. Fiecare seif are un slot subțire în el, astfel încât oricine poate depune cecuri sau să se uite pentru a vedea cât de multă valoare deține seiful. Cu toate acestea, doar deținătorul cheii va putea accesa interiorul.

Când un deținător de cheie vrea să dea bani altcuiva, își deblochează cutia. Ei fac un nou cec care face referire la cel mai vechi (care este apoi distrus) și îl blochează într-o cutie pe care destinatarul o poate deschide. Pentru a cheltui asta, noul destinatar repetă procesul.

În acest articol, vom arunca o privire mai atentă la Script, limbajul de programare interpretat de nodurile din rețeaua Bitcoin. Scriptul este cel care guvernează mecanismul de blocare/deblocare menționat pentru seifuri.

Cum funcționează Bitcoin?

Urmând analogia noastră de sus, ați putea spune că fiecare tranzacție are două părți – o cheie (pentru a vă debloca cutia) și un lacăt. Folosiți cheia pentru a deschide caseta care conține cecul pe care doriți să-l trimiteți, apoi adăugați unul nou într-o casetă nouă cu un lacăt diferit. Pentru a cheltui din noua cutie, ai nevoie de o altă cheie.

Destul de simplu. De asemenea, puteți obține o mică variație cu privire la tipurile de încuietori din sistem. Poate că unele seifuri necesită să furnizați mai multe chei și poate că altele au nevoie să dovediți că cunoașteți un secret. Există o mulțime de condiții pe care oamenii le pot pune.

Cheia noastră este ceea ce numim un scriptSig. Lacătul este scriptPubKey. Dacă ne uităm la aceste componente mai detaliat, vom descoperi că sunt de fapt alcătuite din biți de date și blocuri de cod. Când sunt combinate, ele creează un program mic.

Când efectuați o tranzacție, transmiteți acea combinație în rețea. Fiecare nod care îl primește va verifica programul, care îi spune dacă tranzacția este validă. Dacă nu, va fi doar aruncat și nu veți putea cheltui fondurile blocate.

Cecurile (monedele) pe care le dețineți se numesc rezultate de tranzacție necheltuite (UTXO). Fondurile pot fi folosite de oricine poate furniza cheia care se potrivește încuietorului. Mai exact, cheia este scriptSig, iar lacătul este scriptPubKey.

Dacă UTXO-urile sunt în portofel, probabil că vor avea o condiție care spune că numai persoana care poate dovedi deținerea acestei chei publice poate debloca aceste fonduri. Pentru a-l debloca, furnizați un scriptSig care include o semnătură digitală, folosind cheia privată care se mapează la cheia publică specificată în scriptPubKey. Toate acestea vor deveni mai clare în curând.

Înțelegerea stivei Bitcoin

Scriptul este ceea ce este cunoscut ca un limbaj bazat pe stivă. Toate acestea înseamnă că, atunci când citim un set de instrucțiuni, le plasăm în ceea ce poate fi considerat o coloană verticală. Lista A, B, C, de exemplu, ar avea ca rezultat o stivă cu A în partea de jos și C în partea de sus. Când instrucțiunile ne spun să facem ceva, operăm pe unul sau mai multe elemente începând din partea de sus a stivei.

Elementele A, B și C sunt adăugate și „ieșite” din stivă.

Putem distinge între date (lucruri precum semnături, hashuri și chei publice) și instrucțiuni (sau opcodes). Instrucțiunile elimină datele și fac ceva cu ele. Iată un exemplu foarte simplu despre cum ar putea arăta un script:

<xyz> <md5 hasher> <d16fb36f0911f878998c136191af705e> <verifica dacă este egal>

În roșu, avem date, iar în albastru, avem codurile operaționale. Citim de la stânga la dreapta, așa că mai întâi punem șirul <xyz> pe stivă. Următorul este codul operațional <md5 hasher>. Acesta nu există în Bitcoin, dar să presupunem că îndepărtează elementul superior al stivei (<xyz>) și îl hash folosind algoritmul MD5. Apoi, rezultatul este adăugat înapoi în stivă. Ieșirea de aici se întâmplă să fie d16fb36f0911f878998c136191af705e.

Ce coincidenta! Următorul nostru element de adăugat este <d16fb36f0911f878998c136191af705e>, așa că acum stiva noastră are două elemente identice. În cele din urmă, <check if equal> scoate două elemente de sus și verifică dacă sunt egale. Dacă sunt, se adaugă <1> la stivă. Dacă nu, se adaugă <0>.

Am ajuns la sfârșitul listei noastre de instrucțiuni. Scriptul nostru ar fi putut eșua în două moduri – dacă elementul rămas era zero sau dacă unul dintre operatori l-a determinat să eșueze atunci când unele condiții nu au fost îndeplinite. Nu am avut astfel de operatori în acest exemplu și ajungem cu un element diferit de zero (<1>), așa că scriptul nostru era valid. Aceste reguli sunt valabile și pentru tranzacțiile reale cu Bitcoin.

Acesta a fost doar un program inventat. Să ne uităm acum la unele reale.

Pay-to-Pubkey (P2PK)

Pay-to-Pubkey (P2PK) este incredibil de simplu. Implica blocarea fondurilor pentru o anumită cheie publică. Dacă doriți să primiți fonduri în acest mod, ați furniza expeditorului cheia dvs. publică, spre deosebire de o adresă Bitcoin.

Prima tranzacție între Satoshi Nakamoto și Hal Finney în 2009 a fost una P2PK. Structura a fost foarte folosită în primele zile ale Bitcoin, dar în prezent, Pay-to-Pubkey-Hash (P2PKH) a înlocuit-o în mare măsură.

Scriptul de blocare pentru o tranzacție P2PK urmează formatul <cheie publică> OP_CHECKSIG. Destul de simplu. S-ar putea să fi ghicit că OP_CHECKSIG verifică o semnătură în raport cu cheia publică furnizată. Ca atare, scriptSig-ul nostru va fi o simplă <semnătură>. Amintiți-vă, scriptSig este cheia lacătului.

Nu devine mult mai simplu decât asta. O semnătură este adăugată la stivă, urmată de o cheie publică. OP_CHECKSIG le afișează pe ambele și verifică semnătura față de cheia publică. Dacă se potrivesc, se adaugă un <1> la stivă. În caz contrar, adaugă un <0>.

Din motive pe care le vom detalia în secțiunea următoare, P2PK nu mai este folosit cu adevărat.

Pay-to-Pubkey-Hash (P2PKH)

Pay-to-Pubkey-Hash (P2PKH) este acum cel mai comun tip de tranzacție. Cu excepția cazului în care faceți tot posibilul să descărcați software arhaic, portofelul dvs. le face probabil în mod implicit.

scriptPubKey din P2PKH este următorul:

OP_DUP OP_HASH160 <cheie publică hash> OP_EQUALVERIFY OP_CHECKSIG

Înainte de a introduce scriptSig, să detaliem ce vor face noile opcodes:

OP_DUP

OP_DUP afișează primul element și îl dublează. Apoi, le adaugă pe ambele înapoi la stivă. De obicei, acest lucru se face astfel încât să putem face o operație pe duplicat fără a afecta originalul.

OP_HASH160

Acest lucru afișează primul element și îl hash de două ori. Prima rundă va fi hash cu algoritmul SHA-256. Ieșirea SHA-256 este apoi hashing cu algoritmul RIPEMD-160. Ieșirea rezultată este adăugată înapoi în stivă.

OP_EQUALVERIFY

OP_EQUALVERIFY combină alți doi operatori – OP_EQUAL și OP_VERIFY. OP_EQUAL afișează două elemente și verifică dacă sunt identice. Dacă sunt, se adaugă un 1 la stivă. Dacă nu, adaugă un 0. OP_VERIFY afișează elementul de sus și verifică dacă este adevărat (adică, diferit de zero). Dacă nu este, tranzacția eșuează. Combinat, OP_EQUALVERIFY face ca tranzacția să eșueze dacă primele două elemente nu se potrivesc.

De data aceasta, scriptSig arată astfel:

<semnătură> <cheie publică>

Trebuie să furnizați o semnătură și cheia publică corespunzătoare pentru a debloca ieșirile P2PKH.

Puteți vedea ce se întâmplă în GIF-ul de mai sus. Nu este prea diferit de un script P2PK. Adăugăm doar un pas suplimentar pentru a verifica dacă cheia publică se potrivește cu hash-ul din script.

Este ceva de remarcat, totuși. Într-un script de blocare P2PKH, cheia publică nu este vizibilă - îi putem vedea doar hash-ul. Dacă mergem la un explorator blockchain și ne uităm la o ieșire P2PKH care nu a fost cheltuită, nu putem determina cheia publică. Este dezvăluit doar atunci când destinatarul decide să transfere fondurile.

Acest lucru are câteva beneficii. Primul este că hash-ul cheii publice este pur și simplu mai ușor de transmis decât o cheie publică completă. Satoshi l-a lansat în 2009 tocmai din acest motiv. Hash-ul cheii publice este ceea ce știm ca adresă Bitcoin astăzi.

Al doilea beneficiu este că hashurile cheii publice ar putea oferi un nivel suplimentar de securitate împotriva calculului cuantic. Deoarece cheia noastră publică nu este cunoscută până când nu cheltuim fondurile, este și mai dificil pentru alții să calculeze cheia privată. Ar trebui să inverseze cele două runde de hashing (RIPEMD-160 și SHA-256) pentru a-l obține.

➠ Vrei să începi cu criptomoneda? Cumpărați Bitcoin pe Binance!

Pay-to-Script-Hash (P2SH)

Pay-to-Script-Hash (P2SH) a fost o dezvoltare foarte interesantă pentru Bitcoin. Acesta permite expeditorului să blocheze fonduri în hash-ul unui script - nu trebuie să știe ce face de fapt scriptul. Luați următorul hash SHA-256:

e145fe9ed5c23aa71fdb443de00c7d9b4a69f8a27a2e4fbb1fe1d0dbfb6583f1

Nu trebuie să cunoașteți intrarea hash-ului pentru a bloca fonduri pentru acesta. Cel care cheltuiește, totuși, trebuie să furnizeze scriptul care a fost folosit pentru a-l hash și trebuie să îndeplinească condițiile acelui script.

Hash-ul de mai sus a fost creat din următorul script:

<înmulțire cu 2> <4> <verifica dacă este egal>

Dacă doriți să cheltuiți monedele legate de acel scriptPubKey, nu oferiți doar acele comenzi. De asemenea, aveți nevoie de un scriptSig care face ca scriptul finalizat să fie evaluat la True. În acest exemplu, acesta este un element pe care <înmulțiți cu 2> pentru a da un rezultat de <4>. Desigur, asta înseamnă că scriptSig-ul nostru este doar <2>.

În viața reală, scriptPubKey pentru o ieșire P2SH este:

OP_HASH160 <redeemScript hash> OP_EQUAL

Nu există operatori noi aici. Dar, avem <redeemScript hash> ca element nou. După cum sugerează și numele, este un hash al scriptului pe care trebuie să-l furnizăm pentru a răscumpăra fondurile (numit redeemScript). ScriptSig se va schimba în funcție de ceea ce este în redemScript. În general, totuși, veți descoperi că este o combinație de semnături și cheile publice atașate, urmate de Scriptul de răscumpărare (obligatoriu):

<semnătură> <cheie publică> <redeemScript>

Evaluarea noastră diferă puțin de execuția stivei pe care am văzut-o până acum. Se întâmplă în două părți. Primul pur și simplu verifică dacă ați furnizat hash-ul corect.

Veți observa că nu facem nimic cu elementele care preced Scriptul de răscumpărare. Ele nu sunt folosite în acest moment. Am ajuns la sfârșitul acestui mini-program, iar elementul de sus este diferit de zero. Asta înseamnă că este valabil.

Încă nu am terminat, totuși. Nodurile de rețea recunosc această structură ca P2SH, așa că de fapt au elementele scriptSig care așteaptă într-o altă stivă. Acolo vor fi folosite semnătura și cheia publică.

Până acum, am tratat redeemScript ca pe un element. Dar acum, va fi interpretat ca instrucțiuni, care ar putea fi orice. Să luăm exemplul unui script de blocare P2PKH, căruia trebuie să îi furnizăm <semnătura> și <cheia publică> care se potrivește cu un hash <cheie publică> în cadrul <redeemScript>.

Odată ce reemScript a fost extins, puteți vedea că avem o situație care arată exact ca o tranzacție obișnuită P2PKH. De acolo, pur și simplu îl rulați ca pe unul normal.

Am demonstrat aici ceea ce se numește un script P2SH(P2PKH), dar este puțin probabil să găsiți unul dintre acestea în sălbăticie. Nimic nu vă împiedică să faceți unul, dar nu vă oferă beneficii suplimentare și ajunge să ocupe mai mult spațiu într-un bloc (și, prin urmare, costă mai mult).

P2SH este, în general, util pentru lucruri precum tranzacții cu semnături multiple sau compatibile cu SegWit. Tranzacțiile multisig pot fi de dimensiuni foarte mari, deoarece ar putea necesita mai multe chei. Înainte de implementarea Pay-to-Script-Hash, un expeditor ar trebui să listeze toate cheile publice posibile în scriptul de blocare.

Dar cu P2SH, nu contează cât de complexe sunt condițiile de cheltuieli. Hash-ul lui redeemScript are întotdeauna o dimensiune fixă. Prin urmare, costurile sunt transferate utilizatorilor care doresc să deblocheze scriptul de blocare.

Compatibilitatea SegWit este un alt caz în care P2SH este util (vom intra în detalii despre cum diferă structura tranzacției în secțiunea următoare). SegWit a fost un soft furk care a dus la o schimbare a formatelor bloc/tranzacție. Deoarece este o actualizare opt-in, nu toate programele de portofel recunosc modificările. Nu contează dacă clienții împachetează hash-ul scriptului SegWit în P2SH. Ca și în cazul tuturor tranzacțiilor de acest tip, ei nu trebuie să știe care va fi Scriptul de deblocare.

Tranzacții SegWit (P2WPKH și P2WSH)

Pentru o introducere mai cuprinzătoare în SegWit, consultați Ghidul pentru începători pentru Martorul Segregat.

Pentru a înțelege formatul tranzacției în SegWit, trebuie doar să știți că nu mai avem doar un scriptSig și un scriptPubKey. Acum, avem și un câmp nou numit martor. Datele pe care le păstrăm în scriptSig sunt mutate la martor, astfel încât scriptSig este gol.

Dacă ați întâlnit adrese care încep cu „bc1”, acestea sunt ceea ce numim SegWit-native (spre deosebire de compatibile cu SegWit, care încep cu „3”, deoarece sunt adrese P2SH).

Pay-to-Witness-Pubkey-Hash (P2WPKH)

Pay-to-Witness-Pubkey-Hash (P2WPKH) este versiunea SegWit a P2PKH. Martorul nostru arată astfel:

<semnătură> <cheie publică>

Veți observa că acesta este același cu scriptSig de la P2PKH. Aici, scriptSig este gol. Între timp, scriptPubKey seamănă cu următorul:

<OP_0> <public key hash>

Pare puțin ciudat, nu-i așa? Unde sunt codurile operaționale pentru a ne permite să comparăm semnătura, cheia publică și hash-ul acesteia?

Nu arătăm operatori suplimentari aici, deoarece nodurile care primesc tranzacția știu ce să facă cu aceasta în funcție de lungimea <public key hash>. Vor calcula lungimea și vor înțelege că trebuie să fie rulată în același stil ca o tranzacție P2PKH de modă veche.

Nodurile neactualizate nu știu cum să interpreteze tranzacția în acest fel, dar nu contează. Conform vechilor reguli, nu există nici un martor, așa că au citit un scriptSig gol și câteva date. Ei evaluează acest lucru și îl marchează ca valid - în ceea ce îi privește, oricine ar putea cheltui rezultatul. Acesta este motivul pentru care SegWit este considerat o furcă moale compatibilă cu înapoi.

Pay-to-Witness-Script-Hash (P2WSH)

Pay-to-Witness-Script Hash (P2WSH) este noul P2SH. Dacă ați ajuns până aici, probabil vă puteți da seama cum va arăta, dar oricum o vom analiza. Martorul nostru este ceea ce am pune în mod normal în scriptSig. Într-un P2WSH care include o tranzacție P2PKH, de exemplu, ar putea arăta cam așa:

<semnătura 1> <cheie publică>

Iată scriptPubKey:

<OP_0> <script hash>

Sunt valabile aceleași reguli. Nodurile SegWit citesc lungimea hash-ului scriptului și determină că este o ieșire P2WSH, care este evaluată în mod similar cu P2SH. Între timp, nodurile vechi îl văd doar ca pe o ieșire pe care oricine poate cheltui.

Gânduri de închidere

În acest articol, am învățat puțin despre elementele de bază ale Bitcoin. Să le rezumam rapid:

Odată ce săpați mai adânc în Bitcoin, începeți să înțelegeți de ce are atât de mult potențial. Tranzacțiile pot fi formate din mai multe componente diferite. Prin manipularea acestor blocuri, utilizatorii au o mare flexibilitate atunci când vine vorba de stabilirea condițiilor cu privire la modul și când pot fi cheltuite fondurile.

➠ Întrebări despre Script? Mergeți la Ask Academy!