Timechain, або Blockchain Bitcoin, — це з’єднаний ланцюг дійсних блоків від Genesis Block до поточної вершини мережі. Кожен наступний блок посилається на хеш попередника, його цифровий відбиток, і додає власний Proof of Work — доказ обчислювальної роботи, потрібної для створення блоку. Завдяки цьому вузли можуть незалежно перевіряти, яка історія відповідає правилам і має найбільшу накопичену роботу. «Час» тут не означає точний годинник для кожної транзакції; передусім це порядок подій, який можна довести.
Уявіть публічну облікову історію, де тисячі комп’ютерів можуть незалежно перевірити кожну нову сторінку. Одна сторінка — це блок. Він містить набір транзакцій і посилання на попередній блок, тому сторінки мають визначений порядок і їх не можна довільно переставити. Timechain — це вся така з’єднана послідовність від першого блоку до сьогоднішньої вершини. Вона не повідомляє, скільки bitcoin належить кожній названій людині; вона зберігає історію транзакцій, з якої вузли визначають невитрачені виходи транзакцій. Це також не сервер однієї компанії. Будь-який Full Node (вузол, який сам перевіряє транзакції та правила мережі) може завантажити копію та перевірити її. [1] [3]
У контексті Bitcoin обидві назви означають ту саму історію блоків. У збереженому коді до запуску від листопада 2008 року слово timechain вживалося у коментарях і назвах змінних або функцій. Whitepaper натомість говорить про позначення часу, ланцюг блоків і ланцюг Proof of Work; точного слова timechain у ньому немає. Згодом Blockchain став загальновживаним терміном у світі. Нині це також широке позначення інших мереж і баз даних, тоді як Bitcoin Timechain є конкретним ланцюгом Bitcoin. Отже, два слова в заголовку не означають два протоколи. Вони зберігають історичну назву поруч із сучасним поширеним терміном. [2] [1] [8]
Цифровий підпис може довести, що транзакцію дозволив власник потрібного ключа. Сам по собі він не заважає підписати дві суперечливі транзакції, які намагаються витратити той самий невитрачений вихід попередньої транзакції, що називається UTXO. Один вузол може спочатку отримати платіж продавцеві, а інший — повернення тієї самої суми відправникові. Тому мережі потрібна спільна історія, яка визначає, яку витрату підтверджено, а яка вже не може бути дійсною. Блоки надають транзакціям місце в цьому порядку, яке можна перевірити. Вони не доводять, яке повідомлення було створене першим за людським або мережевим часом: вузли могли бачити непідтверджені транзакції в різному порядку. [1]
Block Header — заголовок з основними даними блоку. Він містить, зокрема, хеш попереднього заголовка та Merkle Root, який об’єднує ідентифікатори транзакцій блоку в один хеш. Hash схожий на цифровий відбиток: навіть невелика зміна вхідних даних дає інший результат. Зміна старої транзакції змінила б Merkle Root, hash блоку та посилання, записане в наступному блоці. Редагування не залишилося б одним зміненим рядком історії — воно зламало б усю наступну послідовність. Сам хеш не доводить, що транзакції відповідають правилам. Вузли також повинні перевірити транзакції, а кожен блок має виконати потрібний Proof of Work. [3] [1]
Вузол не приймає гілку лише тому, що вона довша або її просуває великий майнер. Спершу він перевіряє правила: Proof of Work, зв’язки з попередніми блоками, дозволену винагороду, транзакції, умови витрачання й те, чи не були вже витрачені кошти, на які посилаються входи. Недійсна гілка залишається недійсною незалежно від обчислювальної потужності автора. Лише серед дійсних кандидатів вузол вибирає ланцюг із найбільшою накопиченою роботою. Тому точніше говорити про дійсну гілку з найбільшою роботою, а не просто про «найдовший ланцюг». Поле chainwork оцінює очікувану кількість обчислень хешу, потрібних для створення ланцюга за складності кожного блоку; це не лічильник спроб, які майнери фактично виконали. [4] [5] [6]
Proof of Work потребує часу, електроенергії та обчислювальної потужності, але його результат швидко перевіряється. Той, хто змінює старий блок, мусить створити для нього новий дійсний Proof of Work, заново з’єднати всі наступні блоки й надалі наздоганяти роботу, яку чесна гілка продовжує додавати. Що глибше блок міститься під вершиною, то більшу перевагу має звичайна історія. Це не математична обіцянка, що минуле ніколи не зміниться. Це економічний та ймовірнісний захист: додаткові блоки зазвичай швидко підвищують вартість успішного переписування. Зловмисник також не може вставити в замінну гілку довільний недійсний платіж чи біткоїни понад дозволений ліміт, бо інші вузли відхилять блок. [1] [4]
Майнер записує часову мітку у Block Header. Правила консенсусу допускають певний діапазон, тому значення time не є точним доказом моменту створення блоку або конкретної транзакції. Часова мітка блоку не обов’язково має бути більшою за мітку його безпосереднього попередника. Для деяких правил Bitcoin тому використовує Median Time Past — медіану часових міток попередніх 11 блоків. Медіану отримують, упорядкувавши ці часові мітки й обравши значення посередині отриманого ряду. Вона рухається рівномірніше за окремі позначки. Середній десятихвилинний інтервал між блоками теж не є розкладом. Два блоки можуть з’явитися майже разом, а наступної появи іноді доводиться чекати значно довше. Висота блоку дає точне місце в ланцюгу, а не точний час у календарі. [4] [7]
Два майнери можуть майже одночасно знайти різні дійсні блоки на однаковій висоті. Частина вузлів спочатку побачить одну гілку, частина — іншу. Коли подальший Proof of Work створює різницю між дійсними гілками, вузли переходять на ту, що має більше накопиченої роботи. Такий перехід називають Reorg. Транзакції з від’єднаного блоку можуть підтвердитися в новій гілці, повернутися до Mempool або стати недійсними, якщо нова історія підтвердить суперечливу витрату. Включення до блоку є першим підтвердженням; кожен наступний блок над ним додає ще одне. Єдиного магічного числа для всіх платежів не існує. Потрібний рівень упевненості залежить від суми, ризику та можливості чекати. [1] [3]
Bitcoin дає змогу створити транзакцію, яку можна підтвердити лише від певної висоти блоку або після визначеного часу. Timelock не наказує автоматично виконати транзакцію саме тієї хвилини. Він лише встановлює найранішу точку, від якої дійсний блок може її включити. Для nLockTime, заснованого на часі, BIP 113 використовує Median Time Past попереднього блоку замість часової мітки створюваного блоку, який легше зсунути. Отже, умова спирається на історію кількох блоків. Навіть після її виконання транзакцію треба поширити, вузли мають її прийняти, а майнер — обрати; включення до конкретного блоку не гарантоване. [7] [4]
RPC — інтерфейс, через який можна давати вузлу команди й читати його відповіді. Full Node не мусить довіряти твердженню публічного оглядача блоків, що блок або транзакція належить поточній історії. Для конкретного хешу виклик RPC getblock може показати height, кількість підтверджень, Merkle Root, time, mediantime, попередній hash, складність і chainwork. Кожне поле відповідає на інше питання: height дає позицію; previousblockhash показує походження; confirmations — глибину під поточною вершиною; time є значенням заголовка; mediantime є медіаною; chainwork представляє накопичену очікувану роботу. Жодного числа окремо недостатньо. Сенс Timechain у тому, що вузол перевіряє їхній взаємозв’язок і всі правила консенсусу як одне ціле. [6] [4]
Для повної картини прочитайте також Genesis Block, Proof of Work, Транзакція, Full Node, Difficulty Adjustment. На цю статтю також посилаються Bitcoin Whitepaper, Genesis Block, Proof of Work, Full Node.