Чому багато випадків використання смарт-контрактів просто неможливі

Доктор Гідеон Грінспен є засновником і генеральним директором Coin Sciences, компанії, що стоїть за платформою MultiChain для приватних блокчейнів.

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

Мене, як розробника популярної блокчейн-платформи, інколи запитують, чи є смарт-контракти, подібні до Ethereum, у дорожній карті MultiChain. Я завжди даю відповідь: «Ні, або принаймні поки що».

Але в сповненому галасу світі блокчейнів, розумні контракти у моді, то чому б і ні? Що ж, проблема полягає в тому, що зараз ми знаємо три сильні варіанти використання дозволених блокчейнів у стилі біткойн (походження, ведення документації компанії та легкі Фінанси), але нам ще належить знайти еквівалент для Ethereum розумні контракти.

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

Смарт-контракт — це фрагмент коду, який зберігається в блокчейні, ініціюється транзакціями блокчейну та який зчитує та записує дані в базу даних цього блокчейну. Ось і все. Дійсно.

Смарт-контракт — це просто химерна назва для коду, який працює в блокчейні та взаємодіє зі станом цього блокчейну. А що таке код? Це Pascal, це Python, це PHP. Це Java, це Fortran, це C++. Якщо ми говоримо про бази даних, то це збережені процедури, написані в розширенні SQL.

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

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

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

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

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

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

1. Звернення до зовнішніх служб

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

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

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

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

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

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

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

Іншими словами, оракул передає дані в блокчейн, а не смарт-контракт.

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

Якщо відповідь — лише ONE вузол, що станеться, якщо цей конкретний вузол виходить з ладу, навмисно чи ні? І якщо відповідь — кожен вузол, чи можемо ми довіряти кожному вузлу пароль цього API? І чи дійсно ми хочемо, щоб API викликався сотні разів? Що ще гірше, якщо смарт-контракту потрібно знати, чи виклик API був успішним, ми повертаємося до проблеми залежності від зовнішніх даних.

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

Розглядаючи ці два обхідні шляхи, ми можемо зробити деякі зауваження.

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

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

Детальніше про цей факт ми поговоримо пізніше.

2. Примусове здійснення платежів у мережі

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

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

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

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

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

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

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

3. Приховування конфіденційних даних

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

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

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

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

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

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

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

Напівпристойний програміст міг би зробити це приблизно за годину.

Для чого потрібні розумні контракти

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

Блокчейни дозволяють дезінтемедіювати дані, і це може призвести до значної економії складності та вартості.

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

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

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

ONE уявити різні способи вираження цих правил, але наразі існують дві домінуючі парадигми, натхненні Bitcoin та Ethereum відповідно. Метод Bitcoin , який ми можемо назвати «обмеженнями транзакцій», оцінює кожну транзакцію з точки зору: (а) записів бази даних, видалених цією транзакцією, і (б) створених записів.

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

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

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

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

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

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

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

Якою б не була відповідь, головне пам’ятати, що смарт-контракти — це лише ONE із методів обмеження транзакцій, які виконуються в базі даних.

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

Олівець і ластик зображення через Shutterstock