STEEM на русском на steeme.ru
Горячее
Лучшее
Новое
 
STEEME.RU :: Записи с тэгом "smartcontract"
$0.899

После публикации поста о Смарт-контрактах несколько человек оставили комментарии по поводу моего выбора языка программирования. Wren – это малоизвестный невероятно незрелый, игрушечный, практически не проверенный на практике язык программирования. Буквально на этой неделе я был вынужден отправить запрос на внесение изменений в программный код (pull request), чтобы исправить критическую ошибку, не позволяющую его использовать.

Теоретически, благодаря новаторскому развитию исключения необходимости детерминированного вычисления “газа” (прим. газ – единица измерения в Ethereum, которая позволяет понять, какой объем работы необходимо выполнить для определенных операций и устанавливает диапазон комиссионных сборов за проведение транзакций), может использоваться любой язык программирования. Существуют интерпретаторы JavaScript, функциональные возможности языков Lua и Python.

Песочница (Sandboxing) – это сложно

Первоочередным фактором при выборе языка программирования является удобство песочницы. Другими словами того, что скомпилированный код может храниться в контролируемом наборе ресурсов процессора и памяти. Следующим требованием является простота обеспечения взаимодействия с программным кодом C++ /ChainBase.

До выбора Wren был рассмотрен Duktape – быстрый встроенный движок JavaScript, который, как я думал, был весьма многообещающим. Я потратил немало времени, пытаясь реализовать полноценную песочницу в Duktape, но без особого успеха.

JavaScript – прекрасный язык программирования, но он не предназначен для быстродействия, хотя современные движки JavaScript удивительно хороши! Но чтобы получить такую скорость от JavaScript, требуется невероятно сложная Just-In-Time компиляция.

Дело в том, что большинство языков программирования недостаточно хорошо поддерживают песочницы. Их внедрение является слишком сложным и требует приложения гораздо больших усилий, чем необходимо. В течение многих лет я искал хороший способ реализации песочницы для JavaScript. Но традиционные подходы к реализации надежных решений песочницы предполагают, как минимум, родительские потоки и подчиненные процессы. Такие песочницы требуют больших затрат на установку и свертывание и делают взаимодействие с блокчейном более дорогостоящим.

Взаимодействие с блокчейном представляет сложность, поскольку объем кода, выполняемого в песочнице, чрезвычайно мал! Типовой контракт будет выполняться за миллисекунды, но большинство традиционных подходов к реализации песочницы с существующими библиотеками требуют значительных расходов на установку и свертывание.

Wren же, даже в его текущем незрелом состоянии, оказался невероятно быстрым и эффективным, при этом без необходимости использования Just-In-Time компиляции. Я уверен, что Wren с родным компилятором мог бы стать на порядок быстрее. Быстрее, чем Lua или JavaScript JIT благодаря самой структуре этого языка программирования.

Язык программирования, который я могу настроить

Wren не является конечным языком программирования, это всего лишь отправная точка. Это небольшая, хорошо организованная база исходного кода, которая может быть легко адаптирована для удовлетворения потребностей блокчейна. На самом деле, я, возможно, вырезал бы многие функциональные возможности Wren (например, Fibers), чтобы сделать его еще проще.

Попытка модификации высокопроизводительных библиотек Lua, JavaScript и Python была бы намного сложнее и более подвержена ошибкам.

C++ -подобный язык программирования

Я бы даже сказал, что конечный язык программирования будет простой подсистемой C/C++. Скриптовый язык программирования C/C++ может быть легко преобразован в машинный код, при этом обладая преимуществами запросто помещенного в “песочницу” интерпретатора. Ненадежные скрипты будут запущены интерпретатором, а разработчики смогут легко преобразовать любой широко используемый скрипт с надежным альтернативным машинным кодом.

Снятие возражений @anonymint

Когда на Steem была совершена DOS атака, хакер транслировал столько транзакций, сколько мог. Все они были признаны действительными и включены в блокчейн. Отказ в обслуживании (DOS) был поддержан протоколом блокчейн, а не сетевым протоколом.

@anonymint, похоже, считает, что я не до конца разобрался, как работает ГАЗ в Ethereum. Вот то, что я "знаю" с точки зрения основных принципов. Если пользователи платят только за то, что они используют и возвращают то, что не используют, то всем нодам необходимо согласовать возврат.

Если автор транзакции указал “точное” количество требуемого ГАЗа, то механизм проверки допустимости может просто использовать это число, но нам известно, что создатель транзакции не может знать заранее, сколько именно ГАЗа потребуется для проведения сделки. (Другие пользователи могут изменить состояние в период между подписанием сделки и выполнением транзакции в блоке).

Что касается Доказательства выполнения работы (The Proof of Work) для транзакций

Я бы рассчитывал временную сложность, требуемую для того, чтобы отправитель потратил 10X процессорного времени для выполнения POW также, как для механизма проверки допустимости, выполняющего сценарий на таком же оборудовании. Запуск типового сценария должен занимать не более 1 мс, так что типовой POW должен занимать не более 10 мс на обычном персональном компьютере, и с течением времени это не должно привести к увеличению временной сложности.

До тех пор, пока ASIC или GPU позволяют злоумышленнику произвести большее количество транзакций, это было бы бессмысленно. Цель POW – заставить злоумышленника потратить больше времени и средств, чем сервер. ASIC или GPU в состоянии произвести эти вычисления быстрее, чем сервер сможет выполнить сценарий, но даже при этом злоумышленник будет вынужден использовать значительно большее количество ресурсов для такой же атаки.

Можно возразить, что POW для транзакций вообще не является целесообразным, потому что протокол уже оценил предельные значения процессорного времени, пропускной способности и памяти взломщиков. Целью доказательства выполнения работы является защита отдельной ноды от вредоносного пира. Каждая нода может легко идентифицировать подключения (и блокчейн аккаунты), которые выполняют больше транзакций, чем может быть обеспечено.

Фактически, 99% времени ограничение предоставляемой пропускной способности будет вызывать сбои транзакций еще до того, как будет вызван сценарий с интенсивной вычислительной нагрузкой на центральный процессор. Таким образом, Proof-of-work является объективным средством "запроса" фактического времени Вашего сценария и определения итогового вознаграждения производителя блока, включающего Ваш скрипт.

Заключение

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

Я твердо убежден, что разработчики могут легко адаптироваться к любому C/ C++ подобному языку программирования, и что смарт-контракты должны представлять собой относительно простые фрагменты кода, не использующие повторно крупные библиотеки существующего кода, даже если такие библиотеки уже есть. Если вы не используете существующие библиотеки кода, то выбор языка программирования не имеет особого значения, до тех пор, пока он в достаточной степени подобен другим используемым языкам.

Оригинальный пост и его обсуждение ЗДЕСЬ

Данный пост опубликован в рамках бета тестирования проекта RuSteemitBlog

Перевод осуществлен: @uuuhha, все SBD, собранные данным постом, будут использованы для Power Up переводчика в рамках инициативы #spreadthepower

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

[![30 second exposure](http://i.imgur.com/wOxrdeJ.png)](https://steemit.com/@rusteemitblog)
$0.225

Ethereum является действующим стандартом для смарт-контрактов общего назначения, но любой, кто занимался разработкой для Ethereum знает, что существуют серьезные проблемы, связанные с его программной архитектурой. На этой неделе я провел некоторое время, работая над подтверждением концепции новой системы тьюринг-полных смарт-контрактов, и в процессе установил некоторые существенные различия в философских подходах.

Технические проблемы Ethereum

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

1. Производительность

Анализ производительности в феврале 2016 года показал, что клиенту Ethereum Parity требуется более часа, чтобы обработать транзакции за 6 месяцев (1 миллион блоков). Все эти блоки были произведены до недавней компьютерной атаки на сеть Ethereum.

Для сравнения, обработка 6 миллионов блоков Steem со средней скоростью транзакций, значительно превышающей скорость транзакций Ethereum, может занять всего несколько минут. Скорость обработки данных Steem выше более чем в 20 раз.

Скорость, с которой один процессорный поток может обрабатывать виртуальную машину напрямую влияет на пропускную способность сети. Текущая сеть Ethereum поддерживает чуть больше 20 транзакций в секунду. Steem, в отличии от него, может поддерживать 1000 транзакций в секунду.

Недавняя атака на Ethereum смогла полностью перенасытить сеть и привела к отказу в обслуживании пользователей. Steem же с легкость пережил направленный на него флуд атаки без перерывов в обслуживании пользователей, и это без каких-либо комиссий за транзакцию!

Есть несколько причин почему ВМЭ — Виртуальная Машина Эфира (EVM - Ethereum Virtual Machine) медленная.

  1. Доступ к хранению основан на Level DB и 32 битных парах ключ/значение
  2. 256 битные операции очень медленны для обычных вычислений
  3. Подсчет потребления ГАЗа является частью консенсуса
  4. Планировка Внутренней Памяти Скрипта также является частью консенсуса (см. 1.)
  5. Мало возможностей по оптимизации скриптов EVM
Об утверждениях о Безграничной Масштабируемости

Виталик Бутерин заявляет, что Ethereum предложит “безграничную” масштабируемость в течение двух лет. Это заявление основано на идее, что не всем узлам сети (node) нужно обрабатывать все транзакции. Это смелое заявление, как я думаю, не удастся осуществить на практике по причинам, которые я опишу ниже.

Их подход — “фрагментировать” (shard) блокчейн, что можно рассматривать как способ сделать блокчейн “многопоточным”. Каждый узел сети будет обрабатывать “один поток” и каждый “поток” сможет обработать 20 транзакций в секунду. В теории они смогут добавить неограниченное количество узлов в сеть и объем транзакций сможет масштабироваться неограниченно. Давайте предположим, что существует два полностью независимых смарт контракта. Эти два контракта могут работать на собственном ”фрагменте” со скоростью в 20 транзакций в секунду. Но что произойдет, если этим контрактам потребуется обмениваться информацией друг с другом? Решение будет в передаче сообщений от контракта к другому контракту. Любой, кто создавал мультипоточные программы с передачей сообщений знает, что это не стоит усилий, если затраты на обработку передачи сообщений достаточно низки.

Затраты на передачу сообщений между узлами через интернет очень высоки. “Цена” “прочтения” единичного значения из другого фрагмента будет значительной.

Наконец, разработчики многопоточных программ знакомы с идеей, что каждый поток “владеет” данными, которые он обрабатывает. Все, что хочет дотянуться до этих данных, должно пройти через их владельца. Что произойдет, когда один фрагмент владеет данными, к которым обращаются чаще 20 раз в секунду? В какой-то момент единичный поток создаст затор.

Если реализовать фрагментирование в Steem, это создаст заторы на уровне “глобального состояния”, на которое влияет каждый голос. То же самое произойдет с любой биржей, обрабатывающей лимитированные ордеры. Фрагментирование просто не масштабируется линейно, и уж точно не безгранично.

2. Ценообразование

Для того, чтобы исполнять программы на Ethereum, контракты должны платить ГАЗом. ВМЭ считает все исполненные инструкции, смотрит, сколько газа стоит эта инструкция, и списывает за нее средства. Если у контракта заканчивается ГАЗ, то все изменения, сделанные контрактом, откатываются, но производитель блока все равно оставляет оплату за ГАЗ.

Попытка реализации чего-то подобного Steem на Ethereum’е сталкивается с тем, что пользователям придется платить $0.01 за каждый голос и даже больше за пост, что является большой проблемой. С ростом числа пользователей сеть переполнится и цена ГАЗа возрастёт.

Теперь давайте представим, что Steem не единственное приложение на Ethereum’е, представим, что Голос и Augur тоже стали популярны, с миллионом пользователей каждый. Цена ГАЗа будет расти до тех пор, пока не остановит развитие всех трех приложений.

Единственный способ снизить цены — увеличить пропускную способность транзакций, повысив эффективность.

Улучшение эффективности - неравномерный процесс. Установка дисков с более высокой скоростью не увеличит эффективность вычислений. Увеличение скорости вычислений не поможет со скоростью обращения к диску. Все попытки увеличения эффективности обязательно повлияют на относительную цену каждой операции в ГАЗе.

Недавно Ethereum был вынужден провести хардфорк для изменения расходования газа. В прошлый раз, когда у Ethereum был хардфорк, это привело к появлению Ethereum Classic!

Можно с уверенностью говорить, что все попытки оптимизации ВМЭ будут изменять относительную стоимость операций. Цена ГАЗа может быть снижена на пропорциональную инструкции величину, которая будет наименее оптимизирована.

И хотя оптимизация некоторых инструкций может увеличить размер прибыли валидаторов блоков, разработчикам Смарт Контрактов все равно придется платить завышенные цены.

Поскольку ГАЗ - это часть консенсуса, всем узлам нужно продолжать обрабатывать старые блоки, используя старые подсчеты ГАЗа до тех пор, пока не произойдет хардфорк. Это означает, что будущие оптимизации сдерживаются необходимостью поддерживать оригинальный метод учета.

3. Оптимизация кода

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

У компиляторов есть возможность оптимизировать, потому что у них есть доступ к информации о задумке программиста. Как только код конвертируется в машинный язык, теряется множество возможностей по оптимизации.

Представьте, что кто-то решил оптимизировать целый контракт, предоставив нативную имплементацию. Нативная имплементация будет давать одинаковые результаты на выходе при одинаковых данных на входе, но она не будет знать как считать цены на ГАЗ, потому что она работала не на ВМЭ.

4. Задумка программиста

Смарт контракты Ethereum публикуются в виде скомпилированного байт-кода, который обрабатывается интерпретатором. Для того, чтобы люди могли понять смарт контракт, им нужно читать код, но блокчейн хранит не исходный код, а ассемблерный. Людям приходится проверять, выдаёт ли “скомпилированный код” те данные, которые ожидаются от исходного кода.

У такого подхода есть несколько проблем. Он требует, чтобы все разработчики компиляторов генерировали одинаковый код и использовали одинаковые оптимизации, или чтобы все контракты проверялись через выбранный компилятор.

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

Другой подход

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

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

Представьте себе платформу для смарт контрактов, где разработчики публикуют код, который они хотят запустить, а консенсус блокчейна обязан правильно интерпретировать код, но не имеет обязательств в том как выполнять этот код.

В этом примере можно заменить скрипт на предварительно скомпилированный бинарный код, используя другой алгоритм, и все будет окей до тех пор, пока вводимые и исходящие из черного ящика данные остаются теми же самыми. С Etheruem это невозможно, потому что чёрному ящику требуется считать сколько всего истрачено ГАЗа.

Лучшее решение проблемы ГАЗа

ГАЗ - это грубый подход к подсчету детерминистического времени исполнения программ. В идеальном мире мы бы просто использовали бы настенные часы, но компьютеры с разными характеристиками и нагрузками получат разные результаты. Хотя и невозможно прийти к детерминистическому консенсусу о том, сколько времени что-то занимает, вполне возможно достигнуть консенсуса о том, включать ли трансляцию [в блок - прим. пер.] или нет. Представьте, как несколько людей в комнате пытаются решить - включать ли какую-то транзакцию или нет. Каждый из них измеряет время, необходимое для обработки транзакции, по настенным часам, и используют вытесняющее планирование для остановки исполнения, если оно происходит слишком долго.

После измерений они все голосуют, и если большинство говорит, что все было “ок”, тогда все включают эту транзакцию. Сеть не знает “сколько это заняло времени”, она только знает, что транзакция выполнена за одобренное время. И отдельные компьютеры будут выполнять транзакции вне зависимости от того, сколько это займет, как только они будут знать, что консенсус достигнут.

С точки зрения консенсуса это означает, что все скрипты платят одинаковую цену вне зависимости от проведенных вычислений. Скрипты платят за “промежутки времени фиксированной длины”, вместо того, чтобы платить за “вычисления”. В терминах, понятных разработчикам операционных систем — скрипты должны выполняться в выделенный им на это квант времени, или их вытеснят и работа будет потеряна. Вышеописанный подход очень абстрактен и не будет практичным в реализации с прямым голосованием, но есть способ реализовать его, который масштабируется без больших накладных расходов, чем уже существуют в Steem. Для начала, все производители блоков должны произвести свой блок в сжатые сроки. Если они не успевают в отведенное время, то это делает следующий делегат. Это означает, что производители блоков должны добавить свой блок и распространить его в сети, достигнув большинства узлов (включая следующего делегата), до времени следующего блока.

Это означает, что просто присутствие транзакции в блоке — знак, что сеть смогла обработать блок и все присутствующие в нем транзакции вовремя. Каждый узел сети может “голосовать” о том, как долго обрабатывался блок и его транзакции. Таким образом, узлу не нужно пересылать блок, если ему кажется, что транзакции превышают выделенное им время.

При этом узел, который против передачи блока из-за большого времени на исполнение, все равно будет принимать новые блоки, следующие за этим “плохим” блоком. В какой-то момент узел встретит ответвление цепочки большей длины и переключится на нее, или “плохой” блок получит достаточно подтверждений (голосов) и станет необратимым. Как только это произойдет, узел начнет передавать его и все, что за ним следует.

Производитель блоков, который хочет получать оплату, будет пытаться сделать так, чтобы его блоки распространялись и поэтому будет “консервативен” в предположениях о замерах с настенных часов, которые производят другие узлы. Сети нужно будет изменять награды за блоки в пропорции к количеству включенных транзакций.

Из-за естественного “ограничения скорости”, связанного с пропускной способностью / квантом на каждую вложенную долю (vesting stake), потребуется серьезное вложение, чтобы какой-либо один майнер смог бы наполнить свой блок, просто чтобы получить бонус.

Предотвращение ДоС атак (Предотвращение Отказов в Обслуживании)

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

Чтобы справиться с такого рода злоупотреблениями, проверяющие могут выбрать один из двух путей:

  1. Создать локальные черные и белые списки скриптов, учетных записей и пиров (peer)
  2. Требовать доказательства выполнения работы (proof-of-work) от каждого скрипта

Использование доказательства выполнения работы позволяет проверяющему узнать, что создатель скрипта затратил минимальные усилия. Чем больше выполнено работы, тем больше времени по “настенным часам” проверяющий выделит на выполнение скрипта до какого-то максимального предела.

Тому, кто желает распространить транзакцию, которая вычислительно затратна, придется создать более сложное доказательство выполнения работы, чем тому, кто создает менее дорогую транзакцию.

Это доказательство выполнения работы совмещенное с ТрДоД (TaPoS Transactions as Proof of Stake) Транзакции как Доказательство Доли означает, что мы теперь имеем Транзакции как Доказательство Выполнения Работы, которые коллективно обеспечивают безопасность сети.

У этого подхода есть побочный эффект в том, что он не дает делегатам “набить собственный блок” чтобы получить вознаграждение, потому что каждая созданная ими транзакция потребует доказательства выполненной работы. Таким образом, блокчейн будет вознаграждать делегатов за транзакции на основании сложности доказательства выполненной работы, как объективного мерила сложности выполнения скрипта.

Подтверждение работоспособной концепции

Недавно я написал немного кода на скриптовом языке Wren со встроенными в него экспериментальными блокчейн операциями. Вот как выполнить простую “крипто валюту” в один смарт контракт:

test_script = R"(
    class SimpleCoin {
        static transfer( from, to, amount ) {
          var from_balance = 0
          var to_balance = 0

          if( from != Db.current_account_authority().toString ) 
              Fiber.abort( "invalid authority" )

          var a = Num.fromString( amount )
          if( a < 0  ) Fiber.abort( "cannot transfer negative balance" )

          if( Db.has( from ) ) 
               from_balance = Num.fromString(Db.fetch( from ))
          if( Db.has( to ) )   
               to_balance   = Num.fromString(Db.fetch( to ))
            
          if( from_balance <= 0 && Db.script_account().toString != from) 
               Fiber.abort( "insufficient balance" )

          from_balance = from_balance - a
          to_balance   = to_balance + a

          Db.store( from, from_balance.toString )
          Db.store( to, to_balance.toString )
        }
    }
)";

 trx.operations.emplace_back( set_script{ 0, test_script } );
 trx.operations.emplace_back( 
     call_script{ 
             account_authority_level{1,1}, 0, 
             "SimpleCoin", 
              "transfer(_,_,_)", {"1","0","33"}
      }
 );

Я ввёл две операции на уровне блокчейна: set_script, и call_script. Первая операция назначает скрипт учетной записи (учетная запись 0), а вторая операция вызывает метод, определенный в скрипте.

Скриптовая среда имеет доступ к состоянию блокчейна при помощи Db API базы данных. Из этого API он может загружать и хранить данные, характерные для этого скрипта, а также запрашивать информацию о текущем уровне авторизации операции. Операция call_script объявляет, что “учетная запись 1” с уровнем авторизации “1”, т.н. активная авторизация, подтвердила вызов. И тогда она запустит скрипт на “учетной записи 0” и вызовет SimpleCoin.transfer( “1”, “0”, “33” ).

Метод передачи может подтвердить, что current_account_authority совпадает с полем from вызова передачи.

Тестирование работоспособной концепции

Я запустил симуляцию, обрабатывающую тысячи транзакций, каждая из которых содержит один вызов функции ‘SimpleCoin.transfer’ и замерил время, потребовашееся на выполнение. В общем мой компьютер смог произвести более 1100 транзакций в секунду через интерпретатор. Это уровень производительности до каких-либо оптимизаций и/или кэширования скрипта. Другими словами, измеренные 1100 транзакций в секунду включают в себя компилирование скрипта 1100 раз. Более разумная имплементация кешировала бы скомпилированный код для существенных улучшений в скорости.

Для сравнения, если мы предположим, что “Безграничный” Ethereum идеально масштабировался, потребовалось бы 55 узлов для обработки этих же транзакций, которые только что обработал мой единственный узел. К тому моменту, когда Wren будет оптимизирован с нормальным кешированием, а Ethereum сделает скидку на необходимые дополнительные издержки, платформа для смарт контрактов на базе технологий Steem и Wren сможет быть в сотни раз более эффективной, чем Ethereum.

Зачем тьюринг-полные смарт-контракты?

Децентрализованное управление отчасти зависит от децентрализованного исполнения контрактов. Блокчейн не может наперёд знать, что каждый контракт будет полезен, и политически централизующая необходимость хардфорков для поддержания новых смарт контрактов ограничивает возможность органично прийти к пониманию, что же работает.

С подходящим движком для смарт контрактов разработчики смогут экспериментировать с “низкопроизводительными скриптами” и потом заменять свои “медленные скрипты” более высокопроизводительными версиями, которые соответствуют тому же интерфейсу черного ящика. Это позволит избавиться от необходимости детерминистически подсчитывать ГАЗ и распределение памяти, что является абсолютно критичным для воплощения желаемых улучшений производительности.

Вывод

Технология, лежащая в основе Steem, в сочетании с описанной реализацией смарт-контрактов будет в сотни раз более масштабируемой, чем технология Ethereum, полностью исключая операционные сборы за выполнение смарт-контрактов. Это может открыть двери тысячам новых приложений, которые не являлись бы экономически целесообразными на Ethereum.

$0

Правовые аспекты технологии смарт-контракта в Республике Беларусь

В начале ноября 2016 года ведущие мировые СМИ опубликовали новость, которая вызвала серьезный интерес в мире торговли, права и финансовых технологий. Договор поставки 88 тюков хлопка, заключенный между Brighann Cotton US и Brighann Cotton Australia, при поддержке банков Wells Fargo и Commonwealth Bank of Australia, был исполнен посредством новой информационной технологии – смарт-контракта. Смарт-контракт – это цифровой протокол, который способствует проверке и исполнению договор между сторонами. Смарт-контракты являются продуктом технологии блокчейн, на которой также базируются криптовалюты. Впервые данный термин был предложен в 1994 году Ником Шабо. Им был сформулирован концепт смарт-контракта, который был реализован спустя 20 лет. Шабо дает следующее определение: «Смарт-контракт – это набор обещаний, предусмотренных в цифровой форме, включающий в себя протоколы, в рамках которых стороны исполняют иные обещания». Для совершения сделки, описанной ранее, смарт-контракт, запускающий банковскую операцию по выплате аккредитива, был помещен на частную блокчейн платформу. Одним из условий смарт-контракта являлось осуществление платежа по прибытии товара в заданный пункт назначения. Далее, на контейнер, в котором находился товар, был установлен GPS-датчик, позволяющий зафиксировать местонахождение объекта. Данные о прибытии в точку назначения, передаваемые датчиком в смарт-контракт, автоматически запустили процедуру платежа. Таким образом, товар был оплачен покупателем без каких-либо платежных инструкций и предоставления большого количества документов. В будущем банки намерены устанавливать датчики контроля температуры, влажности и вибрации, которые будут передавать данные о предполагаемом качестве товара. В случае нарушения заданных нормативов, смарт-контракт может отменить трансфер денежных сумм, предназначенных для оплаты товара. Очевидно, что международную торговлю и сопутствующие ей банковские операции ждут серьезные изменения, поскольку смарт-контракты решают одну из главных проблем современного общества – проблему доверия. Дорогостоящие системы обеспечения исполнения обязательств, многочисленные верификации и посредники являются причинами значительной неэффективности. Набирающая обороты компьютеризация общества привела к созданию эффективных медиумов в виде смарт-контрактов, способных объективно и быстро решать задачи, требующие участия человека. Возникает закономерный вопрос: почему же данный концепт не был реализован в середине 90-ых годов? Разрыв, существовавший между миром Интернета и миром вещей, оставлял технологию смарт-контрактов на обочине прогресса. Однако сегодня большинство современных гигантов индустрии ведут разработки систем «Интернета вещей». Холодильник, самостоятельно приобретающий в онлайн-магазине продукты, автомобиль, позволяющий включить двигатель исключительно на период, указанный в договоре аренды, дверной замок, открывающийся на срок договора найма жилого помещения. Все эти технологии станут частью жизни простых потребителей уже в ближайшем будущем. Юридическому сообществу предстоит оценить возможные перспективы взаимодействия смарт-контрактов и правовых норм, регулирующих сделки. Смарт-контракты могут рассматриваться в качестве инструмента реализации классической гражданско-правовой сделки. В вышеупомянутом договоре поставки хлопка, смарт-контракт выполняет вспомогательную роль и не порождает прав и обязанностей у сторон договора. Однако у сделок, заключенных в форме смарт-контракта много общего со стандартными сделками, заключенными в простой письменной форме. Как и любой протокол, написанный на определенном языке программного кода, смарт-контракт содержит простые логические конструкции, которые влекут наступление или отсутствие определенного результата в зависимости от имеющихся данных: «Если штрих-код на товаре был просканирован лицом Y, то сумма Х должна быть перечислена со счета А на счет В». Юридические условия сделок, в основной своей массе, состоят из подобных логических конструкций. При этом далеко не все сделки могут быть осуществлены посредством смарт-контракта, поскольку содержат оценочные конструкции, которые алгоритмы, предусмотренные смарт-контрактом, оценить не могут. Рост объема Интернета вещей, а также совершенствование технологии смарт-контракта позволят ликвидировать существующие разрывы между интернетом и реальностью. Одной из ветвей эволюции смарт-контракта является внедрение оракулов. Оракул — это смарт-контракт, содержащий в себе информацию о состоянии внешней реальности или о событиях вне блокчейна. При этом информация, которая поступает в контракт, может заполняться как самими участниками сделки, так и третьими независимыми лицами, обладающими доступом к смарт-контракту. В качестве третьих независимых лиц потенциально могут выступать как частные лица, назначенные сторонами, так и государственные органы, имеющие универсальный доступ к смарт-контрактам в соответствии с действующими нормами законодательства. Таким образом, сделки, совершенные с использованием смарт-контракта, могут быть оценены как правоохранительными органами, так и частными институтами (арбитраж, страховые компании). Неизбежное совершенствование технологии ставит перед правотворческими органами две теоретические задачи:

  1. Является ли договор, заключенный посредством смарт-контракта, договором, заключенным в простой письменной форме?
  2. Возможно ли заключение полноценных гражданско-правовых договоров в форме смарт-контракта?

П. 2 статьи 404 Гражданского кодекса Республики Беларусь (далее – ГК РБ) устанавливает, что договор в письменной форме может быть заключен путем составления одного документа, подписанного сторонами, а также путем обмена документами посредством почтовой, телеграфной, телетайпной, электронной или иной связи, позволяющей достоверно установить, что документ исходит от стороны по договору. Буквальное толкование данной нормы позволяет сделать вывод, что форма договора в виде смарт-контракта может рассматриваться в качестве письменной формы договора. Широкие определения электронного документа и электронной цифровой подписи, установленные Законом Республики Беларусь от 28.12.2009 г. № 113-З «Об электронном документе и электронной цифровой подписи», позволяют квалифицировать смарт-контракт в качестве «одного документа, подписанного сторонами». Определение электронного документа, предусмотренное законодательством, не содержит требования хранения информации на носителе владельца документа. Также, определение электронной цифровой подписи вполне соответствует средствам криптографической защиты, используемой при заключении смарт-контракта. Таким образом, форма договора, выраженная в смарт-контракте, может рассматриваться в качество простой письменной формы договора. Смарт-контракт, размещенный в рамках блокчейн-платформы, позволит заключать договоры, которые, по требованию законодательства, должны быть выражены в нотариальной письменной форме. Блокчейн-платформа, государственная или частная, может выступать в качестве нотариуса, удостоверяя сделку и принимая на хранение электронный договор. Тем не менее, выполняя функцию хранения, смарт-контракт не может выполнить другую функцию нотариата: проверку доказательств и правосубъектности лиц. Учитывая тот факт, что договор в форме смарт-контракта заключается, как правило, на расстоянии, приравнивание формы смарт-контрактов к нотариальной письменной форме представляется несостоятельным. Пункт 1 статьи 390 ГК РБ устанавливает, что договором признается соглашение двух или нескольких лиц об установлении, изменении или прекращении гражданских прав и обязанностей. Договор в форме смарт-контракта невозможен без соглашения лиц, поскольку предусматривает размещение смарт-контракта на определенной платформе, к примеру, банка или криптовалютного трансмиттера с использованием уникальных криптографических ключей. Смарт-контракт может содержать определенный набор прав и обязанностей субъектов, которые должны иметь связь между реальностью и Интернетом. В странах романо-германской правовой семьи соглашение, необходимое для заключения договора, требует наличия оферты и акцепта. П. 1 статьи 405 ГК РБ устанавливает, что офертой признается адресованное одному или нескольким конкретным лицам предложение, которое достаточно определенно и выражает намерение лица, сделавшего предложение, считать себя заключившим договор с адресатом, которым будет принято предложение. Также, оферта должна содержать существенные условия договора. Офертой может являться размещение на блокчейн-платформе одной из сторон проекта будущего договора в форме смарт-контракта. Поскольку существенными условиями договора могут быть объекты или явления материального мира, которые не имеют связи с миром Интернета, включение юридических конструкций в протокол является необходимостью. Технические особенности большинства языков программирования позволяют добавлять в протокол комментарии, которые не влияют на выполнение функций программы. Следовательно, договор в форме смарт-контракта может представлять собой совокупность юридических и программных конструкций, которые будут устанавливать права и обязанности сторон. Представляется, что условия договора в форме смарт-контракта, которые запускают его в действие, могут быть продублированы обычными юридическими конструкциями. При этом, в случае конфликта текста и программного кода, приоритет необходимо отдавать программному коду, что позволит упредить потенциальное недобросовестное поведение контрагентов и будет способствовать тщательному исследованию технических условий договора. Практически любая сфера человеческой деятельности имеет определенное юридическое значение. Отсутствие правовых норм, предписывающих ежедневное поведение членов семьи, не означает отсутствия охвата данных отношений правом вообще. В последующем, то или иное поведение может стать основанием для установления, изменения или прекращения прав и обязанностей. На сегодняшний день смарт-контракт не является самостоятельной формой или видом договора с точки зрения законодательства Республики Беларусь, что не отменяет его юридического значения в вопросе установления прав и обязанностей. Представляется, что потенциальное использование смарт-контрактов гражданами и субъектами предпринимательской деятельности не должно быть ограничено со ссылкой на несоответствие правовым конструкциям. Очевидно, что смарт-контракты не настолько «умны» и не могут отразить то разнообразие формулировок, которое закладывается в большинство комплексных юридических документов. Положения законодательства, применяемые к договорам по умолчанию, также не будут учтены смарт-контрактом. Тем не менее, абсолютное большинство договоров, как в потребительской, так и в производственной сфере заключаются по стандартным условиям. Именно эта ниша может быть занята смарт-контрактами, которые обеспечат эффективное исполнение, низкие издержки, уменьшение бухгалтерских расходов путем автоматической выплаты налогов. Юридическая наука должна следовать прогрессу, а не препятствовать его развитию. Нормотворческим органам, при изучении перспектив правового регулирования, необходимо исходить не из удобства и стройности теоретических конструкций, а из практической пользы новой технологии. Значимость смарт-контрактов в будущем может сравниться со значимостью Интернета, поскольку данная технология несет в себе не только технический, но и социально-экономический посыл. Только плодотворная совместная работа специалистов социальных и технических наук позволит изменить повседневную жизнь человека к лучшему.

 

RU тэги:

ru (2853)
money (579)
steemit (573)
life (546)
sport (405)
sportus (375)
sportusbet (370)
bitcoin (342)
steem (321)
news (320)
blockchain (277)
photography (275)
art (202)
travel (177)
ru-steemit (167)
story (137)
russia (134)
writing (123)
introduceyourself (118)
food (117)
ru-steem (112)
funny (98)
rusteemitblog (94)
ru-news (93)
ru-bitcoin (92)
ru-health (86)
sports (82)
ru-longtech (82)
humor (82)
russian (81)
investments (79)
new (77)
blog (75)
recipes (75)
spreadthepower (74)
ethereum (72)
photo (72)
cryptocurrency (71)
poetry (57)
video (56)
ru-life (56)
psychology (55)
crypto (54)
ru-immortality (54)
hyip (51)
philosophy (51)
rus (50)
nature (50)
anarchism (50)
crypto-news (48)
millionaire (47)
business (47)
stemmit (46)
mining (46)
steemwatch (46)
mountshow (44)
handmade (41)
health (41)
longtech (41)
ru-cryptocurrency (40)
ru-help (40)
golos (36)
history (35)
ru-longevity (35)
hot (34)
usa (30)
top (30)
technology (30)
steemmag (29)
spam (28)
immortality (28)
ukraine (26)
longetech (26)
ru-ethereum (25)
music (25)
help (25)
beauty (25)
kitchen (25)
ua (23)
ru-writing (23)
dream (23)
post (22)
investment (22)
cyberfund (22)
love (22)
game (22)
pictures (21)
people (21)
steemkino (21)
science (21)
ru-money (20)
ru-blockchain (20)
ru-mining (19)
security (19)
ru-science (19)
eth (18)
steemsquad (18)
fun (18)
pokemon (18)
dao (18)
btc (18)
steem-help (18)
minnowsunite (17)
experiment (17)
ru-reading (17)
trading (17)
fish (17)
steemit-ru (17)
ico (17)
games (16)
football (16)
poem (16)
ru-invest (16)
motivation (16)
see (15)
politics (15)
internet (15)
world (15)
steemit-news (15)
foto (15)
wings (15)
live (14)
children (14)
lifehack (13)
lisk (13)
facebook (13)
work (13)
secret-writer (13)
coin (13)
ru-travel (13)
animals (12)
investing (12)
religion (12)
illustration (12)
painting (12)
wisdom (12)
ru-business (12)
social (12)
ru-community (12)
kibo (12)
ru-funny (11)
ru-medicine (11)
ru-introduceyourself (11)
space (11)
wolf (11)
interesting (11)
trade (11)
bussinesman (11)
news-ru (11)
youtube (11)
putin (11)
country (10)
turkey (10)
creative (10)
ru-crypto (10)
motivational (10)
education (10)
night (10)
book (10)
war (10)
economics (10)
future (10)
vote (10)
pokemongo (10)
movie (10)
ussr (10)
active (10)
skyway (10)
ru-philosophy (9)
basicincome (9)
recipe (9)
lake (9)
mushrooms (9)
hello (9)
ru-quotes (9)
en (9)
verse (9)
law (9)
bitshares (9)
gold (9)
meditation (9)
fiction (9)
photos (9)
pamplona (9)
qwe (8)
literature (8)
cat (8)
etc (8)
apple (8)
poloniex (8)
pritchi (8)
finance (8)
poems (8)
steemit-help (8)
zarubezhom (8)
ru-story (8)
ru-btc (8)
telegram (8)
christianprogress (8)
marijuana (8)
auto (8)
kz (8)
economy (8)
freedom (8)
cartoon (7)
tech (7)
trends (7)
design (7)
baikal (7)
books (7)
sevenskills (7)
family (7)
creation (7)
tourism (7)
media (7)
ru-psychology (7)
popular (7)
sailing (7)
mind (7)
censorship (7)
gardening (7)
toys (7)
bot (7)
bookmakerhell (7)
bitfinex (7)
steemitphotochallenge (7)
test (7)
cats (7)
flowers (7)
taunigma (7)
yetaras (7)
ru-future (7)
self-development (7)
iconomi (7)
postcoin (7)
productivity (7)
scam (7)
indulgence (7)
craftbeer (7)
comedy (7)
inspiration (6)
car (6)
innovation (6)
girls (6)
the (6)
mlm (6)
faucet (6)
china (6)
invest (6)
upvote (6)
steemit-faq (6)
gif (6)
newlife (6)
steemart (6)
sci-fi (6)
death (6)
autumn (6)
gaming (6)
lisk-russia (6)
bulgaria (6)
picture (6)
universe (6)
language (6)
invention (6)
army (6)
ru-trading (6)
bitcoin-ru (6)
ru-humor (6)
litecoin (6)
tisenkovv (6)
reputation (6)
anarchy (6)
craigrant (6)
ru-faq (5)
ru-video (5)
community (5)
of (5)
garden (5)
politic (5)
cinema (5)
ponzi (5)
ether (5)
wallet (5)
hobby (5)
bitcoinsider (5)
ice (5)
howto (5)
mystic (5)
ru-post (5)
ru-russia (5)
cn (5)
ru--sismgkzki (5)
corruption (5)
baking (5)
from-lj (5)
ru-food (5)
sea (5)
belarus (5)
copywriting (5)
in (5)
ru-thinking (5)
steempower (5)
sonyankastyle (5)
tips (5)
akchmen (5)
by (5)
thoughts (5)
success (5)
salad (5)
moscow (5)
ru-cancer (5)
help-ru (5)
exchange (5)
steeme (5)
miner (5)
soccer (5)
inout (5)
analytics (5)
introduce (5)
journey (5)
time (5)
microsoft (5)
brain (5)
good (5)
overview (4)
mistermax (4)
nootrobox (4)
fintech (4)
woodcarving (4)
startup (4)
suka (4)
bread (4)
misskaty (4)
ru-kino (4)
sun (4)
library (4)
cosmos (4)
ru-wisdom (4)
ru-blokcheyna (4)
english (4)
tutorials (4)
android (4)
release (4)
maltsev (4)
introducing (4)
ruonly (4)
present (4)
ru-fasting (4)
classic (4)
survival (4)
human (4)
medicine (4)
lottery (4)
cars (4)
trading-analysis (4)
profit (4)
translate (4)
positive (4)
meme (4)
you (4)
power (4)
gambling (4)
steem-fun (4)
newcryptocurrency (4)
newcoin (4)
bank (4)
fairytale (4)
memory (4)
school (4)
culture (4)
astro (4)
idea (4)
fulfillment (4)
wish (4)
bigotry (4)
app (4)
ru-steeme (4)
http (4)
justice (4)
waves (4)
steemhelp (4)
cloudmining (4)
etherium (4)
windows (4)
languages (4)
cancer (4)
text (4)
film (4)
introducemyself (4)
drugs (4)
ru-macrophilosophy (4)
networking (4)
tutorial (4)
free (4)
energy (4)
zamok (4)
ru-longetech (4)
fairy-tale (3)
faq (3)
socialnetwork (3)
recreation (3)
smile (3)
flower (3)
sex (3)
raw (3)
melnikov (3)
weapon (3)
montenegro (3)
ru-blog (3)
relax (3)
account (3)
dveri (3)
lifestyle (3)
witness (3)
spain (3)
cryptonews (3)
biography (3)
smartcontract (3)
pie (3)
translation (3)
stereotypes (3)
man (3)
pushkin (3)
google (3)
dance (3)
forest (3)
coinfox (3)
hacker (3)
ru-fishing (3)
eeoneguy (3)
earning (3)
syria (3)
governance (3)
ru-poetry (3)
cash (3)
decentralization (3)
what (3)
reading (3)
me (3)
rippel (3)
personaldevelopment (3)
absurd (3)
ufo (3)
dicov (3)
from (3)
newbee (3)
buy (3)
meat (3)
nvidia (3)
stickers (3)
state (3)
ru-politics (3)
mirra (3)
kiev (3)
greece (3)
macroquiz (3)
nasa (3)
cooking (3)
sleep (3)
poker (3)
government (3)
job (3)
fashion (3)
donate (3)
thinking (3)
guitarist (3)
mine (3)
blondgirl-way (3)
article (3)
ru--titmgkzki (3)
ru-motivation (3)
mathematics (3)
dating (3)
ned (3)
question (3)
memes (3)
stats (3)
node (3)
blogging (3)
buisness (3)
ru--potryasayusche (3)
shopping (3)
leisure (3)
china-philosophy (3)
house (3)
yoga (3)
collection (3)
vopros (3)
longevity (3)
shop (3)
steem-tutorials (3)
soup (3)
liver (3)
ru-auto (3)
obama (3)
best (3)
steemfest (3)
not (3)
bounty (3)
word (3)
travels (3)
hardwork (3)
dog (3)
ru-people (3)
peace (3)
globalengineeringbaltia (3)
dogecoin (3)
prohodim (3)
biology (3)
tv (3)
cryptovalute (3)
drawing (3)
hentai (3)
x11 (2)
tesla (2)
italy (2)
coinbase (2)
trump (2)
color (2)
links (2)
meetup (2)
makerdao (2)
cheese (2)
hashflare (2)
motocross (2)
melania (2)
twitter (2)
safe (2)
true (2)
ukr (2)
steemtools (2)
israel (2)
mist (2)
transfer (2)
pytin (2)
spacex (2)
filmmaking (2)
blocktrades (2)
peru (2)
steem-bet (2)
comments (2)
mapala (2)
thailand (2)
ru-ethereumclassic (2)
ru-criptocurrency (2)
passwords (2)
steemitchat (2)
bali (2)
beyondbitcoin (2)
dash (2)
ru-chat (2)
password (2)
asic (2)
ecology (2)
ru-steam (2)
deposit (2)
bitcoinexchange (2)
silkroad (2)
traveling (2)
kids (2)
lg (2)
politica (2)
women (2)
flash (2)
rrr (2)
ru-new (2)
steem-fr (2)
identity (2)
fraud (2)
iron (2)
ru-eth (2)
rock (2)
sony (2)
lisk-ru (2)
updates (2)
steemdollar (2)
steemdollars (2)
medvedev (2)
lgbt (2)
ilcoin (2)
sky (2)
aboutme (2)
russiansteemit (2)
cybernomics (2)
ru-financial (2)
criptodengi (2)
ecommerce (2)
shoping (2)
guide (2)
usesteem (2)
payitforward (2)
wedding (2)
testing (2)
artist (2)
ya (2)
mother (2)
vegetables (2)
writen (2)
curation (2)
it-steemit (2)
cyrillic (2)
nintendo (2)
criptocurrency (2)
ru--vau (2)
esenin (2)
indoortv (2)
mastercard (2)
ural (2)
steemit-guide (2)
smoothies (2)
one (2)
vmf (2)
fencing (2)
swisscoin (2)
regulation (2)
ru-interesting (2)
ru--titjki (2)
ru--piswki (2)
it (2)
advertising (2)
theory (2)
alcohol (2)
home (2)
duedill (2)
inchain (2)
locoso (2)
amd (2)
blockpay (2)
cosmetic (2)
sdc (2)
mobile (2)
shadowcash (2)
hi (2)
flag (2)
incent (2)
city (2)
fork (2)
cryptomania (2)
mass (2)
ios (2)
posts (2)
ru-art (2)
ru-library (2)
earnings (2)
japan (2)
price (2)
ru-book (2)
decor (2)
skoda (2)
senenskills (2)
craftbeerart (2)
blokcheyna (2)
hustlersmanual (2)
easy (2)
esoteric (2)
start (2)
steemit-ideas (2)
diet (2)
astronomy (2)
dpos (2)
trojan (2)
my (2)
internetecommerce (2)
research (2)
matrix (2)
style (2)
tour (2)
bees (2)
manual (2)
gadget (2)
visa (2)
dessert (2)
do (2)
avto (2)
rap (2)
ru-football (2)
ru-ru (2)
horror (2)
ru-poem (2)
card (2)
newcomers (2)
ru-tor (2)
lecture (2)
sciens (2)
museum (2)
bittrex (2)
forever (2)
support (2)
techreview (2)
pokemon-go (2)
psychedelic (2)
london (2)
summer (2)
fly (2)
iphone (2)
ru-stih (2)
computers (2)
riches (2)
taxes (2)
marketing (2)
p2p (2)
mobileapp (2)
cryptovallute (2)
daxi (2)
ship (2)
humour (2)
programming (2)
archive (2)
personal (2)
barbecue (2)
steemrussia (2)
want (2)
tattoo (2)
api (2)
joke (2)
review (2)
monero (2)
lotto (2)
doping (2)
legal (2)
com (2)
films (2)
feminism (2)
thevenusproject (2)
rusio (2)
fishing (2)
reviews (2)
to (2)
cityfrog (2)
liqui (2)
fsb (2)
steem-power (2)
soul (2)
transport (2)
gardering (2)
diary (2)
consciousness (2)
ukrainian (2)
sreemit-ru (2)
ru-traveling (2)
cia (2)
us (2)
view (2)
Bitcoin (2)
elections (2)
islam (2)
first (2)
quail (2)
altcoins (2)
dice (2)
roadmap (2)
bots (2)
robot (2)
writer (2)
extremism (2)
thw (2)
global (2)
crpcenter (2)
movies (2)
winter (2)
circus (2)
sheldrake (2)
tormozi (2)
optimism (2)
ocean (2)
no (2)
currency (2)
body (2)
hidden-gems (2)
trend (2)
go (2)
pay (2)
fitness (2)
wikipedia (2)
election (2)
product (2)
cyberpunk (2)
introduceyourself-ru (2)
nakladnoi (2)
gyroscooter (2)
friends (2)
steemithelp (2)
egaas (2)
bitkoin (2)
logo (2)
rome-antique (2)
roman-portrait (2)
potatoes (2)
cryptography (2)
zashita (2)
stuffed (2)
dolevik (2)
steemlotto (2)
vdice (2)
maining (2)
crimea (2)
crowdsale (2)
stomach (2)
kodovyi (2)
aliexpress (2)
liberland (2)
prof1983 (2)
steeme-ru (2)
fake (2)
pelevin (2)
system (2)
steemit-howto (2)
relationship (2)
service (2)
site (2)
create (2)
pc (2)
RuEenglish (2)
magic (2)
steemstats (2)
geforce (2)