Остерігайтеся неможливого смарт-контракту

Три найпоширеніші помилки щодо смарт-контрактів

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

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

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

На жаль, реальність розумних контрактів набагато більш приземлена, ніж усе це:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Будь ласка, залишайте будь-які коментарі у LinkedIn.