Opcode

Анна хоче заплатити Петру. Гаманець готує транзакцію та потрібні підписи, а вузли перевіряють, чи могла вона витратити вибрані монети. Гаманець — це застосунок або пристрій для отримання й надсилання біткоїнів. Вузол — програма, що перевіряє транзакції та блоки й обмінюється даними з іншими учасниками мережі. Bitcoin Script описує частину цих перевірок. Opcode — одна з інструкцій, наприклад перевірка підпису. Для звичайної оплати Анна не пише їх вручну. Але вузол не може повірити імені власника чи позначці «підписано»: він має перевірити умови. Коректний скрипт — лише частина перевірки всієї транзакції. [1] [4]

У зрозумілому людині записі можна побачити OP_DUP або OP_CHECKSIG. Це назви інструкцій; у скрипті їм відповідають однобайтові коди. Байт — звичайна одиниця обсягу даних. Інші частини містять дані, наприклад публічний ключ. Відкритий ключ використовують для перевірки підписів; його не потрібно тримати в таємниці. Інструкції сімейства OP_PUSHDATA задають, скільки наступних байтів додати як дані. Байти всередині таких даних не виконуються повторно як інструкції. Це як різниця між словами «додайте сіль» у рецепті та інгредієнтом, який кладуть у миску. [1] [2]

Уявіть стос записок, з якого беруть верхню. Так працює основний стек скрипту. OP_DUP копіює верхній елемент, OP_DROP видаляє його. Якщо виконати OP_DUP, а потім OP_DROP на непорожньому стеку, його вміст стане початковим. Ви не подвоїли монети, лише робочі дані. Відсутність потрібного елемента може спричинити помилку. Порядок і точне кодування також мають значення. [1]

OP_EQUAL бере два верхні елементи, порівнює їхні байти й замінює результатом порівняння. OP_EQUALVERIFY негайно завершується помилкою за невідповідності; якщо дані однакові, продовжує без цього результату в стеку. Жодна з цих двох операцій сама не перевіряє підпис. Дві однакові копії публічного ключа може надати будь-хто. Потрібна відповідна перевірка підпису, щоб установити, що хтось міг підписати необхідне повідомлення. [1] [4]

OP_CHECKSIG перевіряє підпис за публічним ключем і повідомленням, складеним із транзакції. Приватний ключ — секретне числове значення, за допомогою якого створюють такий підпис. Приватний ключ не розкривається. Параметр sighash визначає, які частини охоплює підпис; не кожен режим підписує все. Старі скрипти та SegWit версії 0 використовують алгоритм підпису ECDSA. Tapscript, скриптові правила Taproot, для звичайних ключів довжиною 32 байти використовує інший алгоритм — Schnorr. Самої назви інструкції без цього контексту недостатньо. [1] [3]

Умова може дозволяти звичайне витрачання або альтернативний шлях відновлення. OP_IF та OP_ELSE вибирають гілку за значенням зі стеку, а OP_ENDIF закриває умовну частину. Bitcoin Script не має загальних програмних циклів із довільним повторенням. Проте це не дозволяє ігнорувати все в невиконаній гілці. Деякі інструкції перевіряються вже під час читання скрипту; важливі їхній тип і версія правил. [1] [3]

CLTV, інструкція OP_CHECKLOCKTIMEVERIFY, може встановити абсолютну межу, наприклад певну висоту блоку, тобто його позицію в ланцюзі. CSV, OP_CHECKSEQUENCEVERIFY, разом із правилами віку транзакції задає відносну затримку від підтвердження виходу, що витрачається. Вихід — раніше отримана сума з умовами витрачання. Інструкції перевіряють поля транзакції: не запускають таймер, не надсилають гроші й не замінюють підпис. Для конкретного застосування потрібне правильне поєднання часового блокування з іншими умовами. [7] [8] [9]

Перш ніж читати технічний приклад, з’ясуйте, чи йдеться про старі скрипти, SegWit або Tapscript. Tapscript додає OP_CHECKSIGADD для поєднання перевірок підписів. Натомість OP_CHECKMULTISIG завершується помилкою при виконанні; у невиконаній гілці ці правила його ігнорують. Назви не суперечать одна одній: різняться середовища перевірки. Перелік opcodes — не універсальний конструктор, деталі якого можна бездумно переносити між форматами. [1] [3] [6]

BIP 342 резервує сімейство OP_SUCCESSx для майбутніх розширень Tapscript. Після проходження попередніх перевірок достатньо зустріти таку інструкцію під час декодування, щоб пропустити наступні скриптові перевірки з успіхом, навіть у невиконаній гілці. Випадково такий самий байт усередині доданих даних не рахується. Це можливість змінити правила, а не вже активований захист. Умова, що покладається на ще не визначене майбутнє значення, може не захистити кошти так, як очікує автор. [1] [3]

Full Node самостійно перевіряє правила дійсності, але може суворіше ставитися до приймання та поширення непідтверджених транзакцій. Наприклад, Bitcoin Core v29.0 за замовчуванням відмовляється поширювати транзакції, що використовують інструкцію OP_SUCCESSx у Tapscript, хоча консенсус може допускати їх у блоці. Читаючи приклад, визначайте версію, початкові дані, охоплення підпису та причини відмови. Зрозумілий синтаксис не доводить безпеку гаманця; у звичайному користуванні цю роботу виконує перевірене програмне забезпечення. [1] [5]