Завершення дебатів про біткойн проти блокчейну

Чи є якась цінність у блокчейні без криптовалюти?

Дебати точаться деякий час, але останній місяць став серйозним підйомом. Поставлене запитання:

Чи є якась цінність у блокчейні без криптовалюти? І чи можна ці «спільні книги без токенів» взагалі назвати блокчейнами?

Так я прочитав Стаття Бейлі, дивився Відео Тіма, читайте ця публікація Nasdaq, слідував за Річардом кожен слово, і навіть мав власний весела дискусія (див. коментарі) з Крісом ДеРозом із фонду Counterparty. Так багато гарячого повітря.

Одне, що Кріс добре вміє, це звести його до питання: чи є блокчейн інновацією в економіці чи комп’ютерній науці? Мається на увазі, що якщо блокчейни є суто економічною інновацією, блокчейни не мають сенсу без криптовалют. Отже, дозвольте мені висловити свою позицію на початку:

Блокчейн біткойнів був і економічною та інновація в інформатиці.

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

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

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

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

Транзакційна модель біткойна

Транзакційна модель біткойнів проста, але потужна. Кожна біткойн-транзакція має набір входів і набір виходів. Кожен вхід «витрачає» один вихід попередньої транзакції. Усі біткойни у ​​вхідних даних транзакції надходять у цю транзакцію та розподіляються між її виходами відповідно до зазначених у ньому кількостей. Таким чином, транзакції утворюють багатосторонній зв’язаний ланцюжок, який завершується транзакціями «coinbase», у яких створюються нові біткойни.

Біткойн має купу додаткових правил, які виконуються кожним вузлом у мережі:

• Кожен вхід в транзакцію повинен підтвердити, що він має право витрачати попередній вихід, з яким він пов’язаний. Це право обмежене умовами, закодованими в попередньому виведенні.
• Транзакція повинна мати достатню загальну суму біткойнів на своїх входах, щоб покрити загальну суму, записану на її виходах. Єдиним винятком є ​​транзакції coinbase, які створюють нові одиниці валюти.
• Кожен вихід може бути використаний лише один раз, іншими словами, він може бути підключений лише до одного входу в одній наступній транзакції.

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

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

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

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

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

Щоб вирішити цю проблему, біткойн навмисно ускладнює додавання блоку в ланцюжок за допомогою процесу, який називається «майнінг». Щоб створити блок, ви повинні вирішити складну, але безглузду математичну задачу, яка вимагає багато обчислень (і, отже, електроенергії та грошей). Вам також потрібна удача, оскільки ви конкуруєте з багатьма іншими майнерами блоків у всьому світі. Ви не можете просунутися надовго, купивши більш потужний комп’ютер для майнінгу, тому що мережа регулярно регулює складність проблеми, щоб підтримувати стабільну глобальну швидкість в один блок за 10 хвилин.

Якщо це так важко і дорого створити блок, навіщо комусь турбуватися? Відповідь у винагороді за блок. Успішний майнер блоку контролює транзакцію coinbase, яка присуджує йому 25 біткойнів (ця сума зменшується вдвічі кожні чотири роки). Вони можуть продати ці біткойни на відкритому ринку за 7,000 доларів США (за сьогоднішнім курсом), погасити рахунки за електроенергію та, сподіваюся, отримати прибуток. Майнери також отримують трохи додатково від комісій, які додаються до транзакцій, хоча наразі ці комісії відіграють незначну роль.

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

Мультиверсійний контроль паралельності

Тим часом я хочу поговорити про те, що може здатися абсолютно не пов’язаним.

База даних — це сховище структурованої інформації, згрупованої в сутності, подібні до електронних таблиць, які називаються таблицями. Простим прикладом такої таблиці є список банківських рахунків, у якому кожен рядок містить номер рахунку разом із сальдо цього рахунку. Припустімо, ваш обліковий запис починає день із балансом 900 доларів США. Сьогодні заплановано автоматичну виплату іпотеки в розмірі 750 доларів США, а також потрібно зняти 400 доларів США в банкоматі. На жаль, у вас немає можливості овердрафту, тому одна з цих операцій налаштована на збій.

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

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

Але що станеться, якщо обидва процеси розпочнуться одночасно? У цьому випадку кожен з них прочитає баланс вашого рахунку та вважатиме його достатнім для продовження. Після завершення виплати іпотечного кредиту ваш новий баланс буде розраховано як 150 доларів США та записано в базу даних. Після завершення зняття в банкоматі ваш новий баланс у розмірі 500 доларів США буде таким же чином записаний. Одна з цих операцій запису замінить іншу, і, залежно від вашої удачі, ви отримаєте бонус у розмірі 750 або 400 доларів США від свого банку. Безсумнівно, ви незабаром навчитеся розраховувати відвідування банкомату на день іпотеки.

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

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

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

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

Для наших цілей дуже важливо, що MVCC запобігає конфліктам між операціями запису. зокрема:

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

Дзвонити в дзвіночки? Є ще одна передісторія, яку ми повинні обговорити.

Реплікація бази даних із кількома головними

Тепер поговоримо про реплікацію бази даних, у якій база даних існує в кількох копіях. Існує кілька вагомих причин для реплікації бази даних, наприклад:

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

Коли справа доходить до читання даних із баз даних, реплікація є ідеальною технікою, оскільки всі репліки містять однакову інформацію. Однак ситуація стає складнішою, коли справа доходить до операцій запису, тому що нам потрібно вирішити, де ці операції виконуються та як вони переносяться в інші копії бази даних.

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

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

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

Теоретично це звучить просто, але реплікація з декількома головними створює нову проблему, оскільки можуть виникати конфлікти. Що, якщо дві копії бази даних оновлять один і той самий рядок одночасно, а потім спробують обмінятися цими оновленнями одна з одною? Обидві бази даних помітять, що відбулося конфліктне оновлення, і повинні застосувати певну узгоджену стратегію для вирішення цих конфліктів. І тут справи йдуть досить складний – перегляньте документи MySQL, SQL Server or оракул для деяких прикладів стратегій вирішення конфліктів. (Я ігнорую синхронну або так звану реплікацію з декількома головними реплікаціями, у якій усі репліки повинні виконати операцію запису, перш ніж вона може відбутися, оскільки це перетворює кожен копія бази даних у вузьке місце.)

Отже, ось до чого веде весь цей фон:

Хіба не було б чудово, якби ми могли мати розподілене багатоверсійне керування паралелізмом, щоб запобігти виникненню конфліктів у реплікації з кількома головними?

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

Блокчейни як розподілений MVCC

Давайте скопіюємо кілька речень, які я написав жирним шрифтом вище:

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

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

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

Блокчейн забезпечує розподілений MVCC (з кількома додатковими наворотами).

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

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

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

• Ми можемо прийняти невелику затримку між моментом, коли транзакція ймовірно буде прийнята, і моментом, коли вона буде остаточно прийнята. (Ця затримка може становити кілька секунд, а не 10 хвилин, як у біткойнах.)
• Конфліктні транзакції ніколи не повинні відбуватися, якщо всі чесні та їхні системи функціонують належним чином.
• Кожна транзакція змінює лише кілька рядків одночасно (інакше наші транзакції блокчейну матимуть громіздку кількість вхідних даних).
• Розмір кожного рядка бази даних досить малий (знову ж таки, щоб запобігти збільшенню розміру транзакцій блокчейну).

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

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

Блокчейни за межами MVCC

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

По-перше, правила щодо дійсних транзакцій містять частину логіки програми для нашої бази даних облікових записів. Пам’ятайте, що загальна кількість біткойнів на вході транзакції має покривати загальну кількість на виході. У перекладі на логіку додатків бази даних це правило стверджує, що транзакції бази даних (за винятком баз монет) не можуть збільшувати загальну кількість біткойнів у базі даних. Цей тип обмежень виходить за рамки звичайної бази даних збережені процедури тому що його не можна обійти ні за яких обставин.

По-друге, пам’ятайте, що кожна транзакція біткойнів кодує умови, за яких їх можна витратити. Для звичайних виходів біткойнів ця умова базується на криптографії з відкритим ключем. Загальнодоступна адреса вбудована в вихідний «сценарій», тому її можна використовувати лише за допомогою закритого ключа, що відповідає цій публічній адресі. Якщо ми розглядаємо цей вихід як рядок бази даних, ми маємо базу даних із дозволами для кожного рядка, які базуються на криптографії з відкритим ключем. Крім того, кожна транзакція представляє публічно перевірений доказ того, що її творці мали право видаляти/змінювати її попередні рядки. Це (на мою думку) справжня новинка в технології баз даних.

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

Так де жетон?

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

Але лише одне маленьке питання: Хто займається майнінгом для досягнення такого консенсусу? У біткойнах анонімні майнери повинні виконувати дорогі безкорисні обчислення, і їх до цього стимулюють винагороди за блок (і комісії за транзакції), деноміновані в рідній валюті або токені блокчейну. Чи є у нас інші варіанти?

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

Епілог

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

Чи справді ці дозволені системи загального реєстру без токенів гідні назви «блокчейн»?

Коротка відповідь: кого це хвилює? Рідко варто сперечатися про значення слів, тому що воно є немає правильної відповіді.

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

Чи достатньо ці спільні книги схожі на біткойн, щоб заслужити назву «блокчейн»?

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

Спасибі за читання.

Ти можеш слідкуйте за мною у Twitter тут. Дивись також: Доставка проти оплати на блокчейні.

Ось кілька інших матеріалів, які варто прочитати на цю тему Пьотр Пясецький та Даг Кемпбелл.