Logo
Share this article

Чому розумні контракти потребуватимуть «розумних таблиць термінів», щоб відповідати

Юристи стверджують, що в еру розумних контрактів у юристів ще буде багато роботи, щоб гарантувати, що розробники отримають правильний код.

Тед Млинар та Айра Шефер є партнерами практики інтелектуальної власності Hogan Lovells у Нью-Йорку. Вони консультують з питань патентів та інших питань інтелектуальної власності, пов’язаних із технологіями блокчейн і Криптовалюта .

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

STORY CONTINUES BELOW
Don't miss another story.Subscribe to the Crypto Daybook Americas Newsletter today. See all newsletters

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

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

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

Щоб подолати інформаційний розрив між узгодженими бізнес-умовами та процесом кодування смарт-контракту, необхідна «розумна таблиця умов». Він може: вказати практичні деталі, необхідні для впровадження узгоджених умов, визначити та розглянути умови, які не можна реалізувати в смарт-контракті, а також додати «шаблонні» юридичні умови.

Коротше кажучи, можна подолати практичні та юридичні перешкоди на шляху впровадження аркуша умов.

Не надто гіпотетичний приклад

Як приклад корисності розумної таблиці термінів розглянемо гіпотетичний Політика страхування від землетрусу для Нью-Йорка (NYC).

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

Комп’ютерні вузли мережі блокчейн виконуватимуть комп’ютерний код смарт-контракту на основі повідомлень, отриманих на адресу блокчейну смарт-контракту.

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

Традиційний спрощений список умов страхування від землетрусу в Нью-Йорку може виглядати так:

  • Сторони: Earthquake Insurance Co («Страховик») і Unshakable Corp («Страхувальник»)
  • Зона покриття: Нью-Йорк
  • Покриття: Страхувальник отримує 50 мільйонів доларів, якщо землетрус стався в зоні покриття.
  • Преміум: $500 тис. за 12 місяців страхування
  • Варіант поновлення: Політика можна поновити на 12 місяців після оплати премії протягом трьох днів після закінчення терміну дії
  • Мінімальна платоспроможність: Страховик підтримуватиме ліквідні активи, що дорівнюють щонайменше 30% від зони покриття Страховика
  • Додатково: Звичайні умови

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

На жаль, розробник програмного забезпечення не може знати, що робити, якщо таблиця термінів також T є «розумною».

Трансляція концепцій у код

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

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

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

За допомогою необхідних ресурсів зразок умов страхування від землетрусів можна легко перетворити на «розумну таблицю умов», готову для кодування:

1. Сторони: Earthquake Insurance Co. («Страховик») і Unshakable Corp. («Страхувальник»)

2. Зона покриття: П'ять районів Нью-Йорка (Оракул 1)

3. Покриття: Страхувальник отримує 5 мільйонів доларів США в Bitcoin (BTC), якщо Геологічна служба Сполучених Штатів оприлюднить публічне оголошення про те, що епіцентр землетрусу виявлено в зоні покриття.

3.1 Запуск під час землетрусу магнітудою 5,0 або більше відповідно до служби сповіщень про землетруси USGS (або даних ATOM Syndication) (Oracle 2)

3.2 Курс обміну валют, визначений CoinDesk Індекс цін на Bitcoin на час Плата Преміум (Oracle 3)

3.3 Визначення розташування епіцентру землетрусу відносно зони покриття за допомогою API геокодування Карт Google (Oracle 4)

3.4 Виплата на гаманець Страхувальника о [адреса гаманця]

4. Преміум: 50 тисяч доларів США в Bitcoin (BTC) на 12 місяців покриття

4.1. Курс обміну валют, визначений поточним індексом цін на Bitcoin CoinDesk на момент сплати премії (Oracle 3)

4.2. Оплата на гаманець Страховика в [адреса гаманця]

5. Варіант поновлення: Страхувальник може продовжити Політика на другий 12-місячний період після сплати другої премії не пізніше ніж через 72 години після закінчення першого 12-місячного періоду

6. Мінімальна платоспроможність: Страховик підтримуватиме ліквідні активи, що дорівнюють щонайменше 30% від максимального ризику Страховика в Зоні покриття протягом попереднього 30-денного періоду.

6.1. Баланс ліквідних активів Страховика доступний за адресою [адреса гаманця]

6.2. Щоденний ризик Страховика в Зоні покриття доступний за адресою [адреса гаманця]

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

7. Додатково: Звичайні умови

7.1. 168-годинна подія: землетруси та поштовхи, що відбуваються протягом будь-якого 168-годинного (1 тижня) періоду, вважаються одним землетрусом

7.2. Обмеження виплат: максимум дві (2) виплати будуть здійснені за Політика

7.3. Переуступка: Страховик не може переуступити цей договір, Страхувальник може

7.4. Вибір права: застосовується законодавство Нью-Йорка

7.5. Арбітраж: усі суперечки, пов’язані з предметом контракту, будуть передані на обов’язковий арбітраж у Нью-Йорку

Будьте розумними, будьте готові

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

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

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

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

Контрольний список

зображення через Shutterstock

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

Note: The views expressed in this column are those of the author and do not necessarily reflect those of CoinDesk, Inc. or its owners and affiliates.

Picture of CoinDesk author Ted Mlynar and Ira Schaefer