Към съдържанието
ДаретеEN

Скриптовият език

P2TR

P2TR биткойн заключва изход към един 32-байтов tweaked key, харчен по пътя на ключа или по пътя на скрипта. Вижте адреса bc1p и формата на witness.

От Dimitar Zurnov · Обновено на 4 ноември 2026
Адаптирано от Learn Me a Bitcoin на Greg Walker.

P2TR (pay to Taproot) заключва изход към един 32-байтов публичен ключ, наречен tweaked key (променен ключ). Този ключ се обвързва с набор от незадължителни собствени скриптове, но във веригата изглежда като всеки друг ключ.

За да харчите, или подписвате с tweaked key, което е пътят на ключа (key path), или разкривате един от скриптовете и изпълнявате условията му, което е пътят на скрипта (script path). P2TR е въведен с ъпгрейда Taproot, което е било активирано на блок 709,632 през ноември 2021 г.

P2TR съчетава неща, които по-старите заключвания са правили поотделно. P2WPKH заключва един ключ, а P2WSH заключва един скрипт. P2TR заключване може да покрива ключ и много скриптове, а харченето показва само частта, която се използва.

Как изглежда P2TR заключването?

P2TR заключващият скрипт (scriptPubKey) е OP_1, последван от push на 32 байта. Push-ът е самият tweaked key, а не негов хеш:

OP_1
OP_PUSHBYTES_32
0f0c8db753acbd17343a39c2f3f4e35e4be6da749f9e35137ab220e7b238a667

Като hex заключването е 34 байта:

51200f0c8db753acbd17343a39c2f3f4e35e4be6da749f9e35137ab220e7b238a667

Изход 0 на трансакция a7115c7267dbb4aab62b37818d431b784fe731f4d2f9fa0939a9980d581690ec носи това заключване. Трансакцията е била потвърдена в блок 861,957. Адресът му е bc1ppuxgmd6n4j73wdp688p08a8rte97dkn5n70r2ym6kgsw0v3c5ensrytduf.

P2TR заключването съдържа tweaked key, който е вътрешният ключ плюс промяна (tweak), изградена от дървото на скриптовете. Вътрешен ключ, 32 байта x-only публичният ключ на собственика Корен на скриптовете, 32 байта хеш над всеки скрипт, ако има такива хеш от ключа и корена Промяна t (tweak) tagged hash, 32 байта добави t по G Tweaked key Q, 32 байта единственият ключ, записан в заключването OP_1 и Q, общо 34 байта
Заключването пази само tweaked key. Вътрешният ключ и скриптовете остават скрити, докато харченето не ги разкрие.

OP_1 е версия на witness 1. P2WPKH заключването започва с OP_0, и P2WSH заключването също започва с OP_0, но P2TR е следващата версия. Push-ът от 32 байта е самият ключ, а не хеш, така че P2TR заключването не съдържа хеш, който да се търси.

Какво е tweaked key?

Tweaked key-ът се строи от две части:

  • Вътрешният ключ, 32-байтов публичен ключ, обикновено на собственика. Той е x-only ключ, което значи, че се пази само x координатата. Y координатата се приема за четна, както дефинира BIP 340.
  • Коренът на дървото от скриптове, хеш, който се обвързва с всеки скрипт в дървото. Ако няма скриптове, няма и корен.

Промяната (tweak) е хеш от вътрешния ключ и корена, както дефинира BIP 341. Tweaked key-ът е вътрешният ключ, преместен по кривата с тази промяна. Всеки може да го изчисли от частите. Заключването пази само резултата.

Тази конструкция скрива скриптовете. Ако изходът се похарчи по пътя на ключа, никой не научава, че съществуват скриптове. Ако се похарчи по пътя на скрипта, другите скриптове остават скрити. Разкрива се само използваният скрипт и неговият клон от дървото.

Как се харчи P2TR изход?

Witness казва на биткойн кой път да следва. Първо се премахва незадължителният анекс (annex). Той е последният елемент и се появява само когато witness има два или повече елемента, а този елемент започва с 50. Анексите са запазени за бъдеща употреба, така че портфейлите не трябва да добавят такъв. После броят на елементите решава:

  • Един елемент. Това е харчене по пътя на ключа. Елементът е Schnorr подпис, направен с частния tweaked key.
  • Два или повече елемента. Това е харчене по пътя на скрипта. Последният елемент е control block, елементът преди него е leaf script (скриптът в едно листо на дървото), а елементите преди тях са входовете за скрипта.
Witness с един елемент е харчене по пътя на ключа. С два или повече последният елемент е control block, а предишният е скриптът. Witness без анекса 1 елемент: път по ключа един Schnorr подпис, направен с tweaked key 2 или повече: път по скрипта последният: control block преди него: leaf script преди тях: входовете за скрипта
Пътят на ключа е по подразбиране и най-евтин. Пътят на скрипта е за харчения, които изискват условие.

Как изглежда харченето по пътя на ключа?

Witness при харчене по пътя на ключа има един елемент, 65-байтов подпис. Подписът е 64 байта плюс sighash байт. Примерът е вход 0 на трансакция 091d2aaadc409298fd8353a4cd94c319481a0b4623fb00872fe240448e93fcbe, потвърдена в блок 861,970. Witness е:

0141b693a0797b24bae12ed0516a2f5ba765618dca89b75e498ba5b745b71644362298a45ca39230d10a02ee6290a91cebf9839600f7e35158a447ea182ea0e022ae01

Първият байт, 01, е броят на елементите. После 41 дава 65-байтовия елемент. Последният му байт, 01, е типът sighash, SIGHASH_ALL. Taproot подпис без sighash байт е 64 байта и означава SIGHASH_DEFAULT.

Подписът е Schnorr, а не ECDSA. Schnorr подписите имат фиксиран 64-байтов вид, без DER обвивка, затова са по-къси. Освен това позволяват на няколко подписващи да комбинират ключовете си в един общ ключ чрез MuSig2, така че мултисиг може да се похарчи като единичен ключ. Страницата за Schnorr обяснява самия подпис.

Как изглежда харченето по пътя на скрипта?

Witness при харчене по пътя на скрипта има поне два елемента. Примерът по-долу има три. Той е вход 0 на трансакция 797505b104b5fb840931c115ea35d445eb1f64c9279bf23aa5bb4c3d779da0c2, потвърдена в блок 863,508:

Елемент Размер Съдържание Роля
0 65 байта (41) Schnorr подпис с sighash байт Вход за скрипта
1 34 байта (22) 20, 32-байтов ключ, после ac Leaf script
2 33 байта (21) c0, после 32-байтов вътрешен ключ Control block

Скриптът в листото казва: ключът трябва да подпише. 20 е push на 32 байта, самият ключ, а ac е OP_CHECKSIG. Като hex целият witness е:

034101769105cbcbdcaaee5e58cd201ba3152477fda31410df8b91b4aee2c4864c7700615efb425e002f146a39ca0a4f2924566762d9213bd33f825fad83977fba7f0122206d4ddc0e47d2e8f82cbe2fc2d0d749e7bd3338112cecdc76d8f831ae6620dbe0ac21c0924c163b385af7093440184af6fd6244936d1288cbb41cc3812286d3f83a3329

Control block-ът няма Меркъл път, защото дървото има само един скрипт. Control block е 33 байта плюс 32 байта за всяка стъпка от пътя, както дефинира BIP 341. Най-дългият път, 128 стъпки, прави control block с 4,129 байта.

Как control block-ът доказва скрипта?

Control block-ът позволява на биткойн да провери, че скриптът в листото е бил обвързан със заключването. Това става на пет стъпки:

Пет стъпки проверяват харченето по пътя на скрипта: leaf hash, Меркъл корен, промяна, tweaked key и съвпадение със заключването. 1. Leaf hash хеш на версия, дължина и скрипт 2. Меркъл корен хешът на листото с пътя в дървото 3. Промяна (tweak) хеш на вътрешния ключ и корена 4. Tweaked key Q вътрешният ключ плюс tweak по G 5. Съвпадение, после изпълнение x и паритетът трябва да съвпадат
Стъпките съвпадат само ако скриптът в листото е бил в дървото, когато заключването е било направено.
  1. Leaf hash (хеш на листото). Tagged hash (хеш с етикет) на версията на листото, дължината на скрипта и самия скрипт. Версията е първият байт на control block-а, след като се изчисти битът за четност. c0 означава версия 0xc0, което е tapscript.
  2. Меркъл корен. Хешът на листото се комбинира с всеки хеш от пътя, докато се стигне до корена: хешът, който обобщава цялото дърво. При един лист коренът е самият хеш на листото.
  3. Промяна (tweak). Tagged hash на вътрешния ключ и корена.
  4. Tweaked key. Вътрешният ключ плюс промяната, умножена по точката G. Това е същата точка, която заключването пази.
  5. Съвпадение. Резултатът трябва да съвпада с ключа в заключването, а битът за четност в control block-а трябва да отговаря на Y координатата. Ако и двете съвпаднат, биткойн изпълнява скрипта в листото с входовете за скрипта.

Какво е tapscript?

Скриптовете в листата на P2TR ползват tapscript, дефиниран в BIP 342. Tapscript е близък до обикновения скрипт, с три основни промени:

  • Подписите в OP_CHECKSIG са 64-байтови Schnorr подписи.
  • Tapscript няма OP_CHECKMULTISIG. Мултисиг се записва с OP_CHECKSIGADD, който брои валидните подписи един по един.
  • Някои неизползвани опкодове минават успешно нарочно, за да може по-късно ъпгрейд да им даде смисъл, без да счупи по-старите нодове.

Страницата за мултисиг обяснява по-стария вид, който tapscript замени.

Защо P2TR?

P2TR има три основни предимства:

  • Гъвкавост. Едно заключване може да съдържа няколко условия за харчене, а собственикът избира кое да използва.
  • Поверителност. Харчене по пътя на ключа изглежда като всяко харчене с един ключ. Неизползваните скриптове никога не се появяват във веригата.
  • Ефективност. Заключването е един 32-байтов ключ, независимо от броя на скриптовете. Мултисиг може да се похарчи като един подпис, ако подписващите ползват MuSig2.

Ако ви трябва само един ключ, P2WPKH е по-прост. Ако ви трябва само един скрипт, P2WSH е по-прост. P2TR си струва допълнителната сложност, когато ви трябват няколко условия или харчене по пътя на ключа, което изглежда обикновено.

Как се прави P2TR адрес?

Адресът е witness програмата, кодирана с bech32m, дефиниран в BIP 350. Bech32m се различава от bech32 с една константа в контролната сума и тази разлика маркира версия на witness 1 и по-нови. Адресът започва с bc1p и е винаги с 62 знака, защото ключът в него е 32 байта.

Каква е историята на P2TR?

P2TR е въведен с ъпгрейда Taproot, което съчетава две по-ранни предложения: Меркъл дървета от скриптове, описани в BIP 114 (MAST) и Schnorr подписите. Taproot е един soft fork, така че един ъпгрейд покри и двете. Той е бил активиран на блок 709,632 през ноември 2021 г. Страницата за ъпгрейда Taproot го описва, а думата Taproot дава кратко определение.

Как изглеждат истинските P2TR трансакции?

Сравнете харченията по пътя на ключа и по пътя на скрипта. И двете плащат към един и същи вид заключване, а веригата показва само това, което харчещият е решил да разкрие.

В този раздел: Скриптовият език

Целият курс „Биткойн от нулата“

Нещо не изглежда наред? Кажете ни