Як насправді працює протокол Біткойн

(Чудове пояснення принципів роботи мережі Bitcoin авторства Michael Nielsen. Багато тексту, трохи картинок. Про всі кострубата переведення - в личку, буду виправляти в міру виявлення)

Багато тисяч статей було написано для того, щоб пояснити Біткоін - онлайн, однорангову (p2p) валюту. Більшість з цих статей поверхнево розповідають суть криптографічного протоколу, опускаючи багато деталей. Навіть ті статті, які «копають» глибше, часто замовчують важливі моменти. Моя мета в цій публікації - пояснити основні ідеї, що лежать в протоколі Біткоін в ясній, легкодоступній формі. Ми почнемо з простих принципів, далі підемо до широкого теоретичного розуміння, як працює протокол, а потім копнемо глибше, розглядаючи сирі (raw) дані в транзакції Біткойн.

Досить складно зрозуміти роботу протоколу в деталях. Набагато простіше замість цього прийняти Біткойн як даність і брати участь у спекуляціях про те, як розбагатіти за допомогою Біткойн, чи є Біткоїн бульбашкою, чи може Біткоїн в один прекрасний день знищити обов'язкове оподаткування, і так далі. Це все весело, але суттєво обмежує ваше розуміння. Розуміння деталей протоколу Біткойн відкриває недоступні перспективи. Зокрема, це основа для розуміння вбудованого мови сценаріїв (скриптова мова програмування) Біткойн, який робить можливим використання Біткойн для створення нових видів фінансових інструментів, таких як розумні контракти (1 2). Нові фінансові інструменти можуть, у свою чергу, бути використані для створення нових ринків і отримання нових форм колективної поведінки людини.

Я опишу такі концепції, як контракти, в наступних публікаціях. Ця публікація концентрується на поясненні внутрішності протоколу Біткойн. Щоб зрозуміти мене, ви повинні бути знайомі з ідеєю публічного криптоключа, і з тісно пов'язаної ідей про цифровий підпис. Я також припускаю, що ви знайомі з криптографічною хеш-функцією (зміна ввідних даних всього на один біт кардинально змінює хеш-суму, прим. пер.). Ніщо з цього не становить великої складності. Основні ідеї можна отримати з програм першого курсу з математики в університеті або класів з комп'ютерної інформатики. Ідеї красиві, так що якщо ви не знайомі з ними, я рекомендую витратити кілька годин, щоб ознайомитися.

Це може здатися дивним, що основою Біткойн є криптографія. Хіба Біткойн не валюта, не спосіб відправки секретних повідомлень? Насправді, проблеми, які повинен вирішувати Біткойн, стосуються в основному забезпечення безпеки угод - бути впевненим, що люди не можуть красти один у одного, або видавати себе за один одного, і так далі. У світі атомів ми досягаємо такої безпеки за допомогою таких пристроїв, як замки, сейфи, підписи та банківські сховища. У світі битів ми досягаємо такого роду безпеки за допомогою криптографії. І ось чому Біткоїн в душі - криптографічний протокол.

Стратегія, яку я буду використовувати в моїй публікації, передбачає створення Біткойн поетапно. Я почну з пояснення дуже простої цифрової валюти, заснованої на ідеях, які практично очевидні. Ми назвемо цю валюту Інфокоїн, щоб відрізнити її від Біткойн. Звичайно, наша перша версія Інфокоїн буде мати багато недоліків, і тому ми будемо проходити через кілька ітерацій Інфокоїн, з кожною новою ітерацією будемо вводити тільки одну або дві прості нові ідеї. Після декількох таких ітерацій ми прийдемо до повного протоколу Біткойн. Ми знову відкриємо Біткойн!

Ця стратегія працює повільніше, ніж якби я пояснив роботу всього протоколу Біткойн залпом. Навіть якщо ви можете зрозуміти механіку Біткойн через таке залпове пояснення, буде важко зрозуміти, чому Біткойн спроектований таким ось чином. Перевага повільного, ітераційного пояснення в тому, що це дає нам набагато більш чітке розуміння кожного елемента Біткойн.

Нарешті, я повинен згадати, що я новачок в Біткоїн. Я спостерігаю за ним з 2011 року (і за криптовалютами з кінця 1990-х років), але серйозно вник у деталі протоколу Біткойн тільки на початку цього року. Так що буду вдячний за виправлення будь-яких помилок з мого боку. Крім того, я в своєму матеріалі включив ряд «проблем для автора», - замітки для себе про питання, які виникли у мене під час написання. Ви можете знайти їх цікавими, але ви також можете пропустити їх повністю, не втрачаючи основного тексту.

Перші кроки: підписано протокол про наміри

Так як ми можемо спроектувати цифрову валюту?

На перший погляд, цифрова валюта здається чимось неможливим. Уявімо собі людину - назвемо її Аліса - вона має деякі цифрові гроші, які вона хоче витратити. Якщо Аліса може використовувати рядок битів як гроші, як ми можемо перешкодити їй використовувати один і той же рядок битів знову і знову, таким чином, створивши необмежену кількість грошей? Або, якщо ми можемо якось вирішити цю проблему, як ми можемо запобігти підробки такого рядка битів і використання її для крадіжки у Аліси?

Це лише дві з багатьох проблем, які повинні бути подолані, щоб використовувати інформацію як гроші.

У першій версії Інфокоїн давайте знайдемо спосіб, щоб Аліса могла використовувати рядок битів в (дуже примітивній і неповній) формі грошей, але таким чином, щоб у неї був хоч якийсь захист від підробки. Припустимо, Аліса хоче дати іншій людині, назвемо її Боб, один інфокоїн. Щоб зробити це, Аліса записує повідомлення «Я, Аліса, даю Бобу один інфокоїн». Потім вона підписує в цифровому форматі повідомлення з використанням закритого ключа шифрування (криптоключ), і заявляє про підписаний рядок битів всьому світу.

(До речі, я використовую «Інфокоїн» з великої літери для позначення протоколу і загальної концепції, і «інфокоїн» з маленької літери для позначення конкретного грошового знака. Подібна практика є звичайним явищем, хоча і не загальною, у світі Біткойн.)

Такий прототип цифрової валюти вас не дуже вразить! Але у нього є деякі переваги. Будь-яка людина в світі (в тому числі і Боб) може використовувати відкритий ключ Аліси для перевірки, що Аліса насправді була людиною, яка підписала повідомлення «Я, Аліса, даю Бобу один інфокоїн». Ніхто інший не зміг би створити цей рядок битів, а значить Аліса не може повернутися і сказати: «Ні, я зовсім не мала на увазі, що хочу віддати Бобу один інфокоїн». Таким чином, протокол встановлює, що Аліса дійсно має намір дати Бобу один інфокоїн. Такий же факт - ніхто не зміг би скласти таке підписане повідомлення - дає Алісі деякий обмежений захист від підробки. Звичайно, після того, як Аліса опублікувала своє повідомлення, існує можливість дублювати її повідомлення іншими людьми, так що в деякому сенсі підробка можлива. Але це не можливо з нуля. Ці дві властивості - встановлення наміру з боку Аліси і обмежений захист від підробки - дійсно примітні особливості цього протоколу.

Я (зовсім) не сказав про те, що, власне, є цифрові гроші. Пояснюю: це просто саме повідомлення, тобто послідовність бітів, а точніше, підписане цифровим підписом повідомлення: «Я, Аліса, даю Бобу один інфокоїн». У майбутньому протоколи будуть схожі в тому, що всі наші форми цифрових грошей будуть просто більш змістовними повідомленнями.

Використання серійних номерів з метою позначити монети

Проблема з першою версією Інфокоїн в тому, що Аліса може продовжувати посилати Бобу те ж підписане повідомлення знову і знову. Припустимо, Боб отримує десять копій підписаного повідомлення «Я, Аліса, даю Бобу один інфокоїн». Чи це означає, що Аліса послала Бобу десять різних інфокоїнів? Чи було її послання випадково дубльованим? Можливо, вона намагалася обдурити Боба, прикидаючись, що вона дала йому десять різних іфнокоїнів, в той час як повідомлення лише доводить всьому світу, що вона має намір передати один інфокоїн.

Чого б нам хотілося, так це знайти спосіб зробити інфокоїни унікальними. Вони потребують лейблу або серійного номера. Аліса підпише повідомлення «Я, Аліса, даю Бобу один інфокоїн, з серійним номером 8740348». Потім, пізніше, Аліса може підписати повідомлення «Я, Аліса, даю Бобу один інфокоїн, з серійним номером 8770431», і Боб (і всі інші) буде знати, що інший інфокоін був переданий.

Щоб ця схема працювала, нам потрібне надійне джерело серійних номерів для інфокоїнів. Одним із способів створення такого джерела є відкриття банку. Цей банк буде надавати серійні номери для інфокоїнів, відстежувати, хто має які інфокоїни, і перевіряти, що угоди дійсно є легітимними.

Більш конкретно, давайте припустимо, що Аліса приходить в банк і каже: «Я хочу зняти (withdraw) один інфокоїн з мого рахунку». Банк зменшує її баланс рахунку на один інфокоїн, і привласнює йому новий, ніколи раніше не використовуваний серійний номер, скажімо 1234567. Потім, коли Аліса хоче передати її інфокоїн Бобу, вона підписує повідомлення «Я, Аліса, даю Бобу один інфокоїн з порядковим номером 1234567». Але Боб не просто приймає інфокоїн. Замість цього, він вступає в контакт з банком, і перевіряє, що: (а) інфокоїн з цим серійним номером належить Алісі; і (б) Аліса ще не витратила цей інфокоїн. Якщо умови правильні, то Боб інформує банк про те, що він хоче прийняти цей інфокоїн, і банк оновлює свої записи, щоб відображати, що інфокоїн з цим серійним номером в даний час в розпорядженні Боба і більше не належить Алісі.

Створювати банк спільними зусиллями

Це останнє рішення виглядає досить перспективним. Тим не менш, виявляється, що ми можемо зробити щось набагато більш амбітне. Ми можемо повністю виключити банк з протоколу. Це значно змінює характер валюти. Це означає, що більше немає єдиної організації, що відповідає за валюту. І якщо ви уявите про величезну владу в руках центрального банку - контроль над грошовою масою - це досить серйозна зміна.

Ідея полягає в тому, щоб кожен (у сукупності) був банком. Зокрема, ми допустимо, що всі користувачі Інфокоїн зберігають повний запис про те, кому інфокоїни належать. Ви можете уявити це як відкриту загальну книгу обліку із зазначенням всіх операцій Інфокоїн. Ми назвемо цю книгу «ланцюжок блоків» (blockchain), саме так у Біткойн і називається публічний запис усіх транзакцій.

Тепер припустимо, що Аліса хоче передати інфокоїн Бобу. Вона підписує повідомлення «Я, Аліса, даю Бобу один інфокоїн з порядковим номером 1234567», і відправляє підписане повідомлення Бобу. Боб може використовувати свою копію ланцюжка блоків, щоб перевірити, чи дійсно інфокоїн належить Алісі. Якщо це перевіряється, то потім він надсилає одночасно повідомлення Аліси і свок повідомлення про прийняття угоди по всій мережі і всі оновлюють свої копії ланцюжка блоків.

У нас ще є проблема «звідки береться серійний номер», але це, виявляється, досить легко вирішити, і тому я відкладу її на потім, коли будемо обговорювати Біткойн. Більш складною проблемою є те, що цей протокол дозволяє Алісі обманювати через повторне витрачання (double spending) її інфокоїнів. Вона відправляє підписане повідомлення «Я, Аліса, даю Бобу один інфокоїн з порядковим номером 1234567» Бобу, і повідомлення «Я, Аліса, даю Чарлі один інфокоїн, з [тим же] серійний номером 1234567» Чарлі. Обидва, Боб і Чарлі, використовують свою копію ланцюжка блоків для перевірки того, що інфокоїн належить Алісі. За умови, що вони роблять цю перевірку в той же самий час (до того, як вони мали можливість почути один від одного), обидва побачать, що так, ланцюжок блоків показує приналежність монети Алісі. Отже, вони обидва приймають переклад і також разом транслюють інформацію про прийняття угоди. Ось тепер ми маємо проблему. Як інші люди повинні оновлювати свої ланцюжки блоків? Може бути не так вже просто знайти спосіб отримання погоджуючої загальної книги транзакцій. І навіть якщо всі можуть погодитися на постійній основі оновлювати свої ланцюжки блоків, є ще одна проблема, що Боб або Чарлі можуть бути обдуреними.

На перший погляд повторне витрачання виглядає важким для Аліси в реалізації. Зрештою, якщо Аліса надсилає повідомлення спочатку Бобу, то Боб може перевірити повідомлення, і розповісти всім інші в мережі (в тому числі Чарлі), щоб вони оновили свої ланцюжки блоків. Як тільки це сталося, Чарлі вже не зможе бути одураженим Алісою. Так що, швидше за все, тільки в короткому проміжку часу Аліса може робити повторні витрачання. Проте, очевидно, будь-який такий проміжок часу небажаний. Гірше того, існують методи, завдяки яким Аліса може зробити цей період довше. Вона може, наприклад, використовувати аналіз мережевого трафіку, щоб знайти час, коли Боб і Чарлі мають багато затримок у зв'язку. Або, можливо, вона може щось зробити, щоб свідомо зірвати їх зв'язок. Якщо вона може уповільнити зв'язок навіть на малість, то це дозволить спростити їй завдання з повторним витрачанням.

Як ми можемо вирішити проблему подвійних витрат? Очевидним рішенням буде, що, коли Аліса посилає Бобу один інфокоїн, Боб не повинен намагатися перевірити угоду поодинці. Швидше за все, він повинен транслювати про можливу угоду всім користувачам мережі Інфокоїн, і попросити їх допомогти йому визначити, чи є угода легітимною. Якщо вони всі разом вирішать, що угода в порядку, то Боб може прийняти цей інфокоїн, і всі оновлять свої ланцюжки блоків. Цей тип протоколу може допомогти запобігти проблемі подвійних витрат, так як, якщо Аліса спробує витратити її інфокоїн разом з Бобом і Чарлі, інші люди в мережі помітять, і користувачі мережі скажуть Боб і Чарлі, що є проблема з транзакцією, і угода не повинна бути здійснена.

Більш детально, давайте припустимо, що Аліса хоче дати Бобу один інфокоїн. Як і раніше, вона підписує повідомлення «Я, Аліса, даю Бобу один інфокоїн з порядковим номером 1234567», і дає підписане повідомлення Бобу. Так само, як і раніше, Боб робить перевірку працездатності, використовуючи його копію ланцюжка блоків, щоб перевірити чи дійсно монета в даний час належить Алісі. Але в цей момент протокол змінено. Боб не просто йде вперед і приймає угоду. Замість цього, він передає повідомлення Аліси всієї мережі. Інші члени мережі перевіряють, чи має Аліса цей інфокоїн. Якщо це так, вони передають повідомлення «Так, Аліса володіє інфокоїном 1234567, тепер він може бути переданий Бобу». Як тільки достатня кількість людей поширять цей послання в мережі, всі оновлять свої ланцюжки блоків, які будуть показувати, що інфокоїн 1234567 тепер належить Бобу, і угода завершена.

Цей протокол має багато неточних елементів в даний час. Наприклад, що означає сказати «достатня кількість людей повинні транслювати це повідомлення»? Що означає «достатньо»? Це не може означати всіх в мережі, оскільки ми апріорі не знаємо, хто знаходиться в мережі Інфокоїн. З тієї ж причини, це не може означати деяку фіксовану частку користувачів в мережі. Ми не будемо намагатися розібратися в цьому прямо зараз. Замість цього, в наступному розділі я буду вказувати серйозні проблеми в підході, який ми описали. Звертаючи увагу на цю проблему, ми будемо мати приємний побічний ефект від створення ідей вище більш зрозумілими.

Доказ роботи

Припустимо, Аліса хоче повторно витратити в протоколі, який я тільки що описав. Вона може зробити це, взявши на себе контроль мережі Інфокоїн. Давайте припустимо, що вона використовує автоматизовану систему для налаштування великої кількості окремих ідентичностей (користувачів), скажімо, мільярд, в мережі Інфокоїн. Як і раніше, вона намагається двічі оплатити той же самим інфокоїн Бобу і Чарлі. Але коли Боб і Чарлі попросять мережу перевірити угоди, додаткові користувачі Аліси завалять мережу, оголосивши Бобу, що вони підтвердили його угоду, і Чарлі, що вони підтвердили його угоду, обдуривши одного або обох одночасно, приймаючи таку транзакцію.

Існує спосіб уникнути цієї проблеми, використовуючи ідею, відому як доказ правильності роботи (proof-of-work). Ідея парадоксальна і включає в себе поєднання двох інших ідей: (1) (штучно) зробити підтвердження транзакцій витратними для користувачів мережі у вигляді комп'ютерних обчислень; і (2), винагородити їх за допомогу перевірки транзакцій. Нагорода використовується для того, щоб люди в мережі пробували допомогти перевірити угоди, незважаючи на необхідність витрачати обчислювальну потужність на цей процес. Користь від того, що перевірка транзакцій вимагає витрат, допомагає уникнути залежності від кількості ідентичностей (користувачів мережі), підконтрольних кому-небудь. Таким чином, тільки загальна обчислювальна потужність може чинити тиск на перевірку. Як ми побачимо, використовуючи певний розумний дизайн, ми можемо зробити так, щоб шахраєві знадобилися величезні обчислювальні ресурси для обману, що робить це практично недоцільним.

Ось суть доказу правильності роботи. Але щоб по-справжньому зрозуміти, ми повинні придивитися до деталей.

Припустимо, Аліса транслює в мережу новину «Я, Аліса, даю Бобу один інфокоїн з порядковим номером 1234567».

Почувши це повідомлення, кожен додає його в чергу очікуючих підтвердження (pending) угод: почуті, але ще не були затверджені мережею. Наприклад, інший користувач мережі на ім'я Девід може мати наступну чергу незавершених угод:

Я, Том, даю Сью один інфокоїн, з серійним номером 1201174.

Я, Сідней, даю Синтії один інфокоїн, з серійним номером 1295618.

Я, Аліса, даю Бобу один інфокоїн з порядковим номером 1234567.

Девід перевіряє свою копію ланцюжка блоків, і бачить, що кожна угода придатна. Він хотів би допомогти, відправивши новину про придатність угод для всієї мережі.

Тим не менш, перш ніж зробити це, як частина протоколу перевірки, Девіду потрібно вирішити непросте обчислювальне завдання - доказ правильності роботи. Без вирішення цього завдання, інша частина мережі не буде приймати його перевірку угод.

Що за завдання Давиду потрібно вирішити? Щоб пояснити це, давайте h буде фіксованою хеш-функцією відомою всім в мережі - вона вбудована в протокол. Біткойн використовує відому хеш-функцію SHA-256, але будь-яка криптографічно безпечна хеш-функція підійде. Давайте дамо черзі незавершених угод Девіда Лейбл L, щоб нам зручніше було посилатися. Припустимо, Девід додає число х (так званий одноразовий номер) і обчислює хеш-суму з комбінації. Наприклад, якщо ми використовуємо L = «Hello, world!» (Очевидно, що це не список операцій, просто рядок використовується для ілюстрації) і одноразовий х = 0, то (вихід отримуємо в шістнадцятковому форматі)

h(«Hello, world!0») = 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64

Завдання, яке Девід повинен вирішити - доказ правильності роботи - це знайти просте число х так, що коли ми додаємо х до L і результат хешування комбінації починається з ряду нулів. Завдання можна зробити більш-менш важким, змінюючи число нулів, необхідних для вирішення цього завдання. Щодо простим доказом правильності роботи завдання може вимагати тільки три або чотири нуля на початку хешу, в той час як більш важким доказом правильності роботи завдання може вимагати набагато більшу кількість нулів, скажімо 15 послідовних нулів. У будь-якому випадку, вище спроба знайти відповідний одноразовий номер з х = 0 не вдалася, так як результат не починається з нуля. Спробуємо х = 1,. Теж не спрацює:

h(«Hello, world!1») = e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8

Ми можемо продовжувати шукати різні значення для х = 2,3,4.... нарешті, при значенні x = 4250 ми отримуємо:

h(«Hello, world!4250») = 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9

Це число дає нам рядок з чотирьох нулів на початку виходу хеш. Цього буде достатньо, щоб вирішити просте завдання «доказ роботи», але не достатньо, щоб вирішити більш важке завдання «доказ роботи».

Є річ, яка робить це завдання складним для вирішення. Результат криптографічної хеш-функції веде себе як випадкові числа: поміняй хоч один біт у вихідних даних і результат буде кардинально відрізнятися настільки, що його неможливо передбачити. Так що, якщо ми хочемо мати значення хеш суми з 10 нулями спочатку, то Девіду буде потрібно, в середньому, перебрати різних значень х, перш ніж він знайде відповідний простий номер. Це досить складне завдання, що вимагає великої обчислювальної потужності.

Існує можливість зробити це завдання більш-менш важко вирішуваним через більшу або меншу кількість нулів на виході з хеш-функції. Насправді, протокол Біткойн отримує досить хороший рівень контролю над трудністю завдання, використовуючи незначну варіацію головоломки на доказ правильності роботи (proof-of-work), описаної вище. Замість того, щоб вимагати нулі, Біткойн як доказ правильності роботи вимагає, щоб хеш заголовка блоку транзакцій бути меншим або рівним числу, відомому як мета. Ця мета автоматично регулюється для того, щоб блок Біткойн займав, в середньому, близько десяти хвилин для авторизації.

(На практиці є значна випадковість у тому, як багато часу буде потрібно для затвердження блоку - іноді новий блок затверджений всього за хвилину або дві, а в інших випадках це може зайняти 20 хвилин або навіть більше. Це безпосередньо змінюється в протоколі Біткойн, так що час для перевірки зазвичай досягає максимум близько десяти хвилин. Замість того, щоб вирішувати одну задачу, ми можемо вимагати вирішення декількох завдань; використовуючи ретельно розроблений програмний дизайн, можна значно зменшити дисперсію в часі для перевірки блоку угод.)

Добре, давайте припустимо, що Девіду пощастило і він знайшов відповідне число х. Ура! (Він отримає винагороду за знаходження числа, як буде описано нижче). Він транслює блок операцій, який він стверджує, в мережу разом зі значенням х. Інші учасники мережі Інфокоїн можуть перевірити, що х є рішенням доказу правильності роботи завдання. І вони потім повинні оновити свої ланцюжки блоку, щоб включити новий блок операцій в ланцюжок.

Щоб ідея доказу правильності роботи мала шанси на успіх, користувачам мережі потрібен стимул, щоб вони допомагали перевіряти транзакцій. Без такого стимулу, вони не мають жодних підстав витрачати цінну обчислювальну потужність просто так, щоб допомогти перевірити операції інших людей. І якщо користувачі мережі не готові витрачати цю потужність, то вся система не буде працювати. Вирішенням цієї проблеми є винагорода людям, які допомагають перевіряти угоди. Зокрема, припустимо, ми нагороджуємо тих, хто успішно перевірив блок угод, шляхом зарахування їм деякої кількості інфокоїнів. Нагорода в інфокоїн настільки велика, що дасть їм стимул брати участь у перевірці.

У протоколі Біткойн, цей процес підтвердження називається майнінг (mining). За кожен перевірений блок угод, успішний майнер отримує винагороду в біткойнах. Спочатку ця нагорода була встановлена на рівні 50 біткойнів. Але на кожні 210 тисяч перевірених блоків (приблизно, раз на чотири роки) нагорода зменшується вдвічі. Це сталося тільки один раз. На сьогодні винагорода за видобуток блоку становить 25 біткойнів. Це зниження ставки вдвічі триватиме кожні чотири роки до року 2140. У той момент, нагорода за майнінг впаде нижче 10-8 біткойнів за блок.10-8 біткойнів, насправді, мінімальна одиниця Біткойн, і відома як Сатоші. Таким чином, у 2140 році загальна пропозиція біткойнів перестане збільшуватися. Однак це не усуне стимул, щоб продовжувати перевірки транзакцій. Біткоїн також дає можливість виділити деяку суму в угоді як плату за транзакцію, що потрапить до майнера, який допомагає акцептувати угоди. У перші дні Біткойн плата за транзакцію становила нуль, але зі зростанням популярності Біткойн плати за транзакцію поступово зросли, і в даний час є додатковою надбавкою до нагороди в 25 біткойнів за майнінг блоку.

Ви можете думати про доказ правильності роботи (proof-of-work) як про змагання хто швидше акцептує угоди. Кожен вхід у змагання коштує трохи обчислювальної потужності. Шанс перемоги майнера в змаганні є (грубо кажучи, і з деякими застереженнями) рівним ставленню до загальної обчислювальної потужності, що вони контролюють. Так, наприклад, якщо майнер контролює один відсоток всієї обчислювальної потужності використовуваного для перевірки транзакцій в Біткоін, то він має приблизно один відсоток шансів на перемогу. Тобто за умови, що в змаганні задіяно багато обчислювальної потужності, нечесний майнер швидше за все буде мати відносно невеликий шанс спотворити процес перевірки, якщо тільки він не витратить величезну кількість обчислювальних ресурсів.

Звичайно, в той час як це викликає наснагу, що нечесна сторона має лише відносно невеликий шанс зіпсувати ланцюжок блоку, але цього не достатньо, щоб викликати довіру до валюти. Зокрема, ми ще не остаточно вирішили питання про повторні витрати.

Я проаналізую подвійні витрати вже скоро. Перш ніж зробити це, я хочу заповнити важливу деталь в описі Інфокоїн. Ідеально було б узгодити порядок в мережі Інфокоїн, в якому мали місце транзакції. Якщо у нас немає такого порядку, то в будь-який момент може стати незрозуміло, хто володіє якими інфокоїнами. Щоб вирішити це, ми вимагатиме, щоб нові блоки завжди включали покажчик на попередній блок, затверджений у ланцюжку, на додаток до списку транзакцій у блоці. (Індекс насправді просто хеш попереднього блоку). Отже, у нас є ланцюжок блоків (block chain) - це просто прямий ланцюжок блоків транзакцій, один за одним, де кожен блок містить покажчик на безпосередньо попередній блок:

Іноді, з'являється виделка в ланцюжку блоків. Це може статися, наприклад, якщо випадково два майнера здійснили перевірку блоку операцій одночасно - і обидва транслюють свій нещодавно затверджений блок в мережу, і деякі люди оновлять свій ланцюжок блоків в одну сторону, а інші оновлять в іншу сторону:

Здавалося б, це викликає проблему, яку ми намагаємося уникнути - вже не ясно, в якому порядку відбулися угоди, і це не прояснює, хто володіє якими інфокоїнами. На щастя, є проста ідея, яка може бути використана для видалення будь-якої вилки. Правило таке: якщо раптом трапляється вилка, люди в мережі відстежують обидва розгалуження. Але в будь-який момент часу, майнери працюють тільки над продовженням того розгалуження, в якому довша копія ланцюжка блоків.

Припустимо ми маємо вилку, в якій деякі майнери отримують спочатку блок А і деякі майнери отримують блок В. Ті майнери, які отримують блок А спочатку, будуть продовжувати працювати вздовж цього розгалуження, в той час як інші майнери будуть йти разом з розгалуженням B. Припустимо, що майнери, що працюють на розгалуженні B успішно добули блок:

Після того, як всі отримують звістку, що це сталося, майнери, що працюють на розгалуженні А помітять, що розгалуження B тепер вже довше і переключаться на роботу з цього розгалуження. Ось і все! Негайно ж робота на розгалуженні А перестане, і всі будуть працювати на тому ж лінійному ланцюжку, і блок А можна проігнорувати. Звичайно, будь-які непідтверджені транзакції, включені в блок А, ще будуть очікувати рішення в чергах майнерів, що працюють на розгалуженні B, і надалі всі угоди будуть підтверджені. Крім того, може виявитися, що майнери, які працюють на розгалуженні А, раніше її розширять. У цьому випадку робота на розгалуженні B швидко припинитися, і знову у нас є один лінійний ланцюжок.

Незалежно від результату, цей процес гарантує, що ланцюжок блоків має узгоджене в часі впорядкування блоків транзакцій. У Біткойн прийнято, що угода не вважається підтвердженою до того як: (1) вона є частиною блоку в довгому розгалуженні, і (2), щонайменше, 5 блоків послідували за ним в найдовшому розгалуженні. У цьому випадку ми говоримо, що угода має «6 підтверджень». Це дає час мережі прийти до узгодженої впорядкованості блоків. Ми будемо також використовувати цю стратегію для Інфокоїн.

З упорядкуванням ми розібралися, давайте повернемося до роздумів про те, що відбувається, якщо нечесний користувач намагається двічі витратити. Припустимо, Аліса намагається двічі витратити інфокійний з Бобом і Чарлі. Один з можливих підходів для неї, спробувати самостійно перевірити блок, який включає в себе обидві транзакції. Припускаючи, що у неї є один відсоток загальної обчислювальної потужності, їй може пощастити, і вона підтверджує блок, вирішуючи математичну задачу правильності роботи (proof-of-work). На жаль, для Аліси, повторний платіж буде відразу помічений іншими людьми в мережі Іфнокоїн і відхилений, незважаючи на вирішення завдання з доказом правильності роботи. Так що нам не потрібно турбуватися.

Більш серйозна проблема виникає, якщо вона транслює окремо дві угоди, в яких вона проводить той же інфокоїн з Бобом і Чарлі, відповідно. Вона може, наприклад, транслювати одну транзакцію одній групі майнерів, а іншу транзакцію - іншій, сподіваючись отримати схвалення угод таким чином. На щастя, в цьому випадку, як ми бачили, мережа буде остаточно підтверджувати тільки одну з цих угод, але не обидві. Так, наприклад, угода Боба в кінцевому рахунку може бути підтверджена, і в цьому випадку Боб може бути спокійний. Між тим, Чарлі побачить, що його угода не була підтверджена, і він відмовиться від пропозиції Аліси. Так що в цьому немає проблеми. Насправді, знаючи, що це буде відбуватися, немає особливих причин для Аліси пробувати це.

Існує інший важливий варіант подвійних витрат, якщо Аліса = Боб, тобто Аліса намагається оплатити монету Чарлі, яку вона також «витрачає» сама собі (тобто, віддаючи собі). Виглядає це так, що легко помітити і впоратися з цим, але в той же час, звичайно, легко в мережі налаштувати кілька користувачів, пов'язаних з тією ж особою або організацією, так що таку можливість необхідно враховувати. В такому випадку, стратегія Аліси чекати, поки Чарлі не при