Вступ до блокчейну

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

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

Почнімо з розуміння того, чому створення розподілених систем є однією з найскладніших проблем у комп'ютерних науках.

Розподілені системи

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

Коли ви пишете код на одному комп'ютері, ви живете в передбачуваному світі:

• Операції або відразу успішні, або відразу невдалі
• Дані не змінюються таємничим чином між зчитуваннями
• Час рухається вперед послідовно
• Коли ви щось зберігаєте, воно дійсно зберігається

Візьмімо просту банківську систему. Переказ 100 доларів від Аліси до Боба в такому випадку надзвичайно простий:

def transfer(from_account, to_account, amount):
    if from_account.balance >= amount:
        from_account.balance -= amount
        to_account.balance += amount
        return "Transfer successful"
    return "Insufficient funds"

Це працює ідеально... доки вам не потрібно масштабуватися.

Ваш банк росте за межі того, що може обробити один комп'ютер, тому тепер ви розподіляєте рахунки рівномірно між різними базами даних:

• Сервер A: Рахунки від 1 до 1 000 000
• Сервер B: Рахунки від 1 000 001 до 2 000 000
• Сервер C: Рахунки від 2 000 001 до 3 000 000

Тепер Аліса (на Сервері A) хоче надіслати 100 доларів Бобу (на Сервері B). Цей простий переказ стає:

def distributed_transfer(alice_server, bob_server, amount):
    # Check Alice's balance on Server A
    if alice_server.get_balance("alice") >= amount:
        alice_server.deduct("alice", amount)    # Step 1
        bob_server.add("bob", amount)           # Step 2
        return "Transfer successful"
    return "Insufficient funds"

Все ще здається простим? Ось що може піти не так:

• Розділення мережі: З'єднання між серверами обривається одразу після Кроку 1, але до Кроку 2. $100 Аліси зникають у цифровій порожнечі.
• Збій сервера: Сервер B виходить з ладу після отримання команди "додати гроші", але до підтвердження її обробки. Чи отримав Боб гроші? Ніхто не знає.
• Умови гонки: Два перекази від Аліси відбуваються одночасно. Обидва перевіряють її баланс у $100, бачать, що в неї достатньо коштів, і обидва продовжують. Аліса тепер витратила $100, яких у неї не було.

Теорема CAP

У 1999 році вчений-комп'ютерник Ерік Брюер сформулював теорему CAP, яка стверджує, що будь-яка розподілена система може гарантувати щонайбільше дві з цих трьох властивостей:

• Узгодженість (Consistency, C): Усі сервери завжди показують однакові дані. Коли баланс Аліси змінюється на Сервері A, кожен інший сервер негайно відображає це.
• Доступність (Availability, A): Система продовжує працювати, навіть коли сервери виходять з ладу. Якщо Сервер A вимикається, користувачі все ще можуть отримати доступ до облікових записів через Сервери B і C.
• Стійкість до розділення (Partition Tolerance, P): Система витримує збої мережі, які розділяють сервери на ізольовані групи.

Ми повинні гарантувати стійкість до розділення, оскільки розділення мережі неминучі: кабелі перерізаються, маршрутизатори виходять з ладу, центри обробки даних втрачають живлення. Це залишає нам вибір між Узгодженістю АБО Доступністю.

Традиційні банківські системи зазвичай обирають Узгодженість + Стійкість до розділення (CP-системи). Вони радше вимкнуться, ніж показуватимуть неправильні баланси рахунків.

Платформи соціальних мереж часто обирають Доступність + Стійкість до розділення (AP-системи). Вони радше дозволять вам публікувати (навіть якщо друзі не зможуть це одразу побачити), ніж взагалі заборонять вам публікувати.

Проблема візантійських генералів

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

Проблема візантійських генералів, сформульована вченими-комп'ютерниками у 1982 році, ілюструє цей виклик:

Ви — візантійський генерал, який планує атакувати укріплене місто. У вас є кілька союзних генералів, розташованих навколо міста, кожен з яких командує власною армією. Щоб досягти успіху, ви повинні координувати одночасну атаку. Якщо одні атакують, а інші відступають, атакуючі сили будуть знищені.

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

• Надсилати повідомлення "атакувати" одним генералам і "відступати" іншим
• Змінювати повідомлення від лояльних генералів під час їх передачі
• Координуватися з іншими зрадниками для максимального створення плутанини

Як досягти консенсусу щодо "атаки" чи "відступу", коли ви не можете відрізнити лояльних генералів від зрадників, і не можете довіряти каналам зв'язку?

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

• Стійкою до візантійських відмов (працює, незважаючи на зловмисних учасників)
• Безперешкодною (будь-хто може приєднатися без схвалення)
• Децентралізованою (без центрального органу влади)

Потім у 2008 році хтось, хто називав себе Сатоші Накамото, довів, що вони помилялися.

Bitcoin: перший блокчейн

Bitcoin був першою практичною реалізацією технології блокчейн. Хоча окремі компоненти існували й раніше (криптографічне хешування, цифрові підписи, однорангові мережі), Сатоші першим об'єднав їх для вирішення проблеми подвійних витрат для цифрової валюти.

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

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