Блокът кандидат

Блокът кандидат (candidate block) е блокът, който майнърът се опитва да добави следващ към блокчейна. Той съдържа трансакциите, които майнърът е избрал, coinbase трансакция и заглавие, което още не е валидно. Блокът става част от веригата едва когато хешът на заглавието падне под целта. Всеки майнър строи собствения си блок кандидат, така че няма общ блок кандидат, който всички да ползват.

Как се строи блок кандидат?

Строенето става на три стъпки, а редът им е умишлен.

1. Избор на трансакциите

Майнърът взима трансакции от своя мемпул и ги слага в блока. Обикновено избира онези, които плащат най-висока такса, защото таксите се прибавят към наградата му. Всяка избрана трансакция трябва да е валидна.

2. Построяване на coinbase трансакцията

Coinbase трансакцията е първата в блока и взима наградата. Строи се след като трансакциите са избрани, защото блокът със SegWit трансакции трябва да се обвърже с техните witness данни. Обвързването е хеш, построен от witness данните на всяка трансакция, затова те трябва да са известни, преди да се запише.

3. Построяване на заглавието

Заглавието на блока е кратко обобщение на целия блок и то е частта, която майнърът хешира. Съдържа шест полета: версия, хеш на предишния блок, Меркъл корен, време, bits и nonce. Двете най-важни тук са следните.

• Хеш на предишния блок. Той посочва блока, върху който строи този. Майнърът винаги строи върху върха на веригата, защото блокът печели наградата си само ако попадне в най-дългата верига.
• Меркъл корен. Той е отпечатък на всяка трансакция в блока. Промяна на една трансакция променя корена, а с това и заглавието. Затова заглавието се строи последно, след като трансакциите са фиксирани.

Какви правила трябва да спазва блокът кандидат?

Блокът кандидат има стойност само ако е валиден. Всеки нод го проверява, а блок, който нарушава правило, се отхвърля и цялата работа, вложена в него, отива на вятъра. Основните правила са тези.

1. Coinbase трансакцията е първа

Първата трансакция трябва да е coinbase. Така всеки блок има поне една трансакция, дори празен.

2. Всяка трансакция трябва да е валидна

Всяка трансакция може да харчи само монети, които вече съществуват и не са похарчени в друго място в блока. Една лоша трансакция прави целия блок невалиден.

3. Родителите идват преди децата

Ако една трансакция харчи изход на друга трансакция в същия блок, родителят трябва да е по-горе. Нодовете проверяват блока отгоре надолу, така че дете над родителя би изглеждало като харчене на изходи, които още не съществуват.

4. Блокът има лимит за размер

Блок може да тежи най-много 4,000,000 weight units. Тежестта е начинът, по който SegWit мери размера: witness данните се броят една четвърт толкова, колкото останалата част от трансакцията. Заглавието и броят на трансакциите също влизат в лимита. Стойността е зададена в консенсусния код.

5. Блокът има лимит за проверки на подпис

Блок може да съдържа най-много 80,000 проверки на подпис. Това са опкодове, които проверяват подпис, като OP_CHECKSIG и OP_CHECKMULTISIG. Лимитът съществува, защото проверката на подпис отнема време, а блок, пълен с тях, би бавил всеки нод при валидиране. По правилата на SegWit проверка на подпис в legacy scriptSig се брои четири пъти към лимита, а в SegWit witness се брои веднъж.

Как майнърите избират трансакциите?

Майнърът може да сложи в блока всякакви валидни трансакции, но иска най-много такси. Когато мемпулът има повече трансакции, отколкото се побират, майнърът взима първо най-скъпите. За такса на байт той сравнява таксата с виртуалния размер.

Предшествениците усложняват това. Трансакцията може да влезе в блок само след като непотвърдените ѝ родители влязат. Затова майнърът не съди трансакцията само по собствената ѝ такса. Гледа ancestor feerate, тоест средната такса на трансакцията и на всичко, от което тя зависи. Скъпо дете може да вдигне евтин родител в блока. Така работи child pays for parent.

Намирането на най-добрата комбинация от трансакции би означавало да се провери всяка възможна група, а това е твърде бавно. Затова повечето майнъри правят добър опит, а не перфектен, и държат времето за него кратко.

Защо някои блокове излизат празни?

Избирането на трансакции отнема време. Някои майнъри започват да хешират веднага, върху блок кандидат, който съдържа само coinbase трансакцията, и го допълват по пътя. Ако такъв блок бъде намерен първи, той излиза празен. Случва се рядко, но обяснява защо понякога във веригата се появява празен блок.

Блок 828,012 е един пример. Той съдържа само своята coinbase трансакция, докато блоковете от двете му страни съдържат 4,385 и 5,639 трансакции. Майнърът, който е намерил празния блок, пак получава субсидията. Губи само таксите.

Как се вижда блок кандидат?

Bitcoin Core строи такъв за вас с RPC командата getblocktemplate. Тя приема шаблонна заявка, а трябва да поискате правилото segwit, според BIP 22:

bitcoin-cli getblocktemplate '{"rules": ["segwit"]}'

Резултатът съдържа трансакциите, избрани от мемпула на вашия нод, хеша на предишния блок, bits, времето и целта. Не съдържа готов блок. Вие още трябва да построите coinbase трансакцията, да намерите Меркъл корена и сами да хеширате. Шаблонът върши тежката работа по избора на трансакции вместо вас.

Ще бъде ли трансакцията от блока кандидат включена сигурно?

Не съвсем. Всеки майнър избира от собствения си мемпул, а никои два мемпула не са еднакви. Повечето блокове кандидати се припокриват много, така че трансакция, която е в единия, вероятно ще влезе в следващия блок. Това не е гарантирано.

Ако трансакцията има ниска такса, тя може да отпадне от блока кандидат, когато пристигне трансакция с по-висока такса. За това какво става, когато трансакция чака твърде дълго, вижте страницата за мемпула. За да я ускорите, вижте replace-by-fee.