Правовое регулирование блокчейна

Блокчейн и технологии распределенных реестров

За последние пять лет блокчейн успел пережить и сверх ажиотаж, спровоцированный 20-кратным ростом курса Биткойна, и побыть неотъемлемым признаком инновационности, ему даже пророчили будущее мировой финансово-кредитной системы.

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

Хайп благополучно прошел.

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

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

Правительства всего мира в связи с этим вынуждены были как никогда серьезно отнестись к криптовалютам и ICO, способных составить конкуренцию своим легальным аналогами в реальном секторе. Власти Венесуэллы даже сделали релиз своей криптовалюты PETRO и порой кажется, что целесообразность этого решения они и сами не вполне тогда понимали. Неизвестно, понимает ли Китай. Но остальные правительства, слегка подумав, открыто и решительно заявили, что неприемлют появление новых денег, кроме тех, которые контролируют сами, и было сказано решительное «НЕТ» криптовалютам как валютам и любым токенам как эквивалентам стоимости. Будьте любезны относиться к криптовалютам и токенам как к товарам, как к документам, но не как к деньгам!

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

Итак, блокчейн – это связанный список структурированных однородных блоков информации. Каждый новый блок в этом списке криптографически связан с предыдущим, в связи с чем всю последовательность называют «цепочкой» (chain, blockchain) и в структуру этой цепочки невозможно встроить фиктивный блок. Более того, каждый блок записывается в цепочку навсегда.

Как правило, копии цепочек дублируются на множестве разных узлов сети, в связи с чем цепочку (ее оригинальное состояние) практически невозможно уничтожить как невозможно уничтожить Гидру, у которой каждый раз вырастают новые головы. Актуальное состояние цепочки так и называют – реестром («ledger») или «журнал», который доступен для чтения для любого узла сети.

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

  • перманентность (историческая неизменяемость) данных;

  • транспарентность (каждый блок в реестре доступен для чтения и анализа);
  • устойчивость (неудаляемость) данных;
  • строгая очередность транзакций.

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

В экспертной среде не принято безусловно отождествлять термины «блокчейн» («BC», Blockchain) и «технологии распределенных реестров» («DLT», Distributed Ledger Technologies), в связи с тем, что блокчейн – это лишь частный случай реализации DLT. В действительности, технологий, обеспечивающих схожие качества, может быть намного больше (хотя бы в теории), поэтому для терминологической чистоты мы будем исходить из того, что блокчейн – это частный вид технологии распределенного реестра и в обстоятельствах когда речь пойдет о классе таких технологий в целом, мы будем использовать термин BC/DLT – то есть блокчейн или иная технология распределенных реестров.

Итак, благодаря популярности Bitcoin и сотен других криптовалютных проектов, BC/DLT доказала всему мировому сообществу свою надежность и стабильность как технология массового использования. Без такой популярности, пожалуй, до сих пор существовали бы сомнения в надежности основных упомянутых свойств BC/DLT (неизменяемости, транспарентности, устойчивости и строгой очередности), но современные блокчейны сейчас – это доказавшие свою надежность системы.

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

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

  • реестры прав и других правоустанавливающих записей (ЕГРП, ЕГРН и др.);
  • любые системы, требующие соблюдение очередности (например, очереди в детские сады и школы, очереди заявок в патентный орган, очереди заявок в процессе торгов в государственных закупках и др.);
  • любые системы, в которых необходимо синхронизировать две взаимозависимые необратимые операции с разной продолжительностью (например, любая купля-продажа с регистрацией прав).

Неизменяемость, транспарентность, устойчивость и очередность делают BC/DLT идеальной технологией для создания подобного класса систем, требующих гарантированной «чистоплотности» в обращении с данными и исключающих какие-либо злоупотребления с данными или противоправные действия.

Смарт-контракты

Настало время дать ясное представление о смарт-контрактах и особенно о том, что к традиционным контрактам (договорам) они не имеют никакого отношения.

Смарт-контракт стал результатом очень важного шага в эволюции BC/DLT и представляет собой компьютерную программу, работающую в среде исполнения BC/DLT. Характер исполнения такой программы прозрачен (код доступен для чтения) и предсказуем (поскольку исполнение осуществляется в изолированной среде BC/DLT).

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

Впервые концепция смарт-контракта была сформулирована в начале 1990-х, еще до появления BC/DLT, и имела правовой смысл: смарт-контракт предлагался как новая форма договора о гарантированных транзакциях, или договора с отложенным исполнением транзакций, которое запрограммировано в среде неподконтрольной никому из субъектов отношений.

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

Мы, также будем рассматривать смарт-контракт исключительно в связи с BC/DLT, где смарт-контракт – это всего лишь компьютерная программа, записанная в распределенный реестр и которая по известному алгоритму осуществляет одну или несколько транзакций в реестре (может при этом принимать исходные данные от пользователя), а значит эта программа:

  • подчиняется всем основным законам обработки транзакционных данных в среде BC/DLT (неизменяемость, транспарентность, устойчивость и очередность);
  • исполняемый код программы подчиняется этим же законам, поэтому код программы нельзя подменить или удалить, а стало быть, смысл и характер исполнения также нельзя подменить или отменить незадекларированным образом (общая неотменяемость*);

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

  • каждый запуск программы и параметры запуска фиксируется в реестре.

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

Для демонстрации этой возможности приведем абстрактный пример со сделкой купли-продажи недвижимости как если бы она заключалась и исполнялась с использованием смарт-контракта.

Если представить, что сделки с недвижимостью регистрируются в блокчейне и оплачиваются криптовалютой этой же сети, тогда можно написать смарт-контракт купли-продажи недвижимости, в рамках которого осуществляется:

  • блокировка определенной суммы на счете покупателя и ожидание факта государственной регистрации (итога правовой экспертизы);
  • в случае положительного результата государственной регистрации – перечисление суммы со счет покупателя на счет продавца, что в свою очередь автоматически влечет встречное перемещение записи права от продавца к покупателю.

Таким образом, имея уверенность, что транзакция будет исполнена описанным образом и никто не может вмешаться в ход ее исполнения, мы устраняем недоверие между покупателем и продавцом, связанное с тем, что либо регистрация может пройти, а деньги не будут уплачены или наоборот – регистрация не пройдет, а деньги не будут возвращены. Сегодня мы снижаем эти риски с помощью банковских ячеек и аккредитивов, то есть привлекаем третье лицо. В случае с BC/DLT, «третьим лицом» является сам смарт-контракт, его бездушный механизм реализации.

Собственно, это все, что необходимо знать о существе смарт-контракта с точки зрения перспективы правового регулирования. Объективное исполнение транзакции – основная функция смарт-контракта и его основная практическая ценность.

Правовое регулирование

Рассмотрев существо технологии BC/DLT, мы видим, что она интересна не только в связи с криптовалютами. Технология намного более интересна в связи с ее уникальными функциональными свойствами, с которыми мы познакомились.

Более того, прямо сейчас признаюсь в том, что я вообще не намерен рассматривать регулирование криптовалют и токенов. Существо этих предметов относится к категории цифровых финансовых активов и ценных бумаг. Вопросы о допуске или правовой квалификации криптовалют в качестве собственно цифровых валют или финансовых активов, а также токенов в качестве цифровых ценных бумаг – это вопросы исключительно финансово-экономической политики государства. Криптовалюты и токены – это всего лишь частный случай применения BC/DLT. Более того, известно, что законопроект о цифровых финансовых активах уже существует и находится в рамках законодательного процесса.

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

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

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

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

Чтобы продемонстрировать необходимость такого улучшения приведем очень условную регуляторную модель.

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

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

Мы предлагаем в данном случае считать истиной те показания очереди, которые были зафиксированы в блокчейн-системе, поскольку в силу технологических особенностей у нас есть основания доверять этим данным. Мы точно знаем, что зафиксированные в блокчейн-системе сведения о времени поступления заявок объективны и не могли быть умышленно изменены, поэтому придадим мета-данным системы статус истины ex lege (лат. «из закона»), то есть установим презумпцию достоверности сведений об очередности, времени и иных технических сведений. Научив систему фиксировать время подачи заявок с максимально возможной для ЭВМ точностью (до наносекунды), мы получим самый объективный результат о первенстве в этом споре.

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

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

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

Что же касается смарт-контрактов, то законодательство регулирует их правовой режим как обычных программ для ЭВМ, что не позволяет создавать более совершенные механизмы исполнения обязательств и более продвинутые цифровые платформы. Поэтому при оценке возможностей регулирования смарт-контрактов, речь также должна идти о придании свойствам смарт-контракта правовой оценки ex lege, аналогично тому как потребительские свойства BC/DLT получают правовое значение в виде презумпций достоверности и аутентичности.

В сфере смарт-контрактов с помощью законодательства имеет смысл урегулировать одну довольно простую систему правил:

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

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

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

Таким образом, смарт-контракт целесообразно рассматривать как механизм исполнения обязательств и необходимо установить правила обращения с таким механизмом – правовой режим исполнения обязательств с применением смарт-контракта.

Существует, вместе с тем, и договорная концепция смарт-контракта. В сентябре 2019 Межународной организацией по стандартизации (ISO) был принят стандарт ISO-TR 23455-2019 «Блокчейн и технологии распределенных реестров – Обзор и взаимодействие между смарт-контрактами в системах блокчейн и распределенных реестров». Стандарт, в частности, утверждает, что смарт-контракт непосредственно следует рассматривать как договор в электронном виде (в письменной форме), поскольку, например, в структуре транзакции на приобретение токена ERC-721 в блокчейне Ethereum наблюдаются все необходимые основания заключения сделки, включая оферту, выражение воли, акцепт и осознаваемый интерес (consideration).

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

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

Исходя из вышеизложенного, целесообразно рассматривать в качестве цели регулирования BC/DLT:

  1. Презумпцию достоверности мета-данных распределенных реестров.
  2. Презумпцию аутентичности блока данных распределенных реестров.
  3. Право сторон в юридических отношениях использовать смарт-контракт в качестве механизма исполнения обязательств.
  4. Право сторон в юридических отношениях на качество исполнения смарт-контракта: неизменяемость, транспарентность, устойчивость, общая неотменяемость.

Архитектура правовых институтов

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

В связи с этим архитектура правовых институтов должна строиться путем декомпозиции правовых условий.

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

Архитектура правовых институтов законодательства о распределенных реестрах​
Архитектура правовых институтов законодательства о распределенных реестрах​

1. Правовой режим данных из распределенных реестров.

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

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

Приведем пример очень показательного проекта с участием банка «А» и авиакомпании «Б» по продаже агентами авиакомпании авиабилетов через блокчейн-платформу.

Этот проект обеспечивает существенное сокращение транзакционных издержек в администрировании процесса дистрибуции авиабилетов. Авиакомпания хочет быть уверена в том, что получит оплату своих билетов с агента, расчеты с которым производятся один раз в отчетный период, а билеты продаются им ежесекундно. Раньше для этого использовались классические инструменты гарантий и депозитов и это требовало ресурсов. Но теперь участникам за счет свойств технологии удалось выстроить доверительную среду, при которой система сама проверяет наличие денег у агента и переводит их на счет авиакомпании в реальном времени. Банк «А» может себе позволить осуществлять такие платежи только будучи абсолютно уверенным в действительности целевой транзакции агента с авиакомпанией – он видит их в блокчейне и верит в их достоверность и аутентичность.

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

2. Права и обязанности в связи с применением смарт-контрактов.

Это второй целевой институт правового регулирования распределенных реестров, а точнее говоря – смарт-контрактов как дочерней технологии BC/DLT.

В рассмотренном проекте с участием банка «А» и авиакомпании «Б» каждый акт функционирования блокчейн-системы – это результат выполнения смарт-контракта, то есть компьютерной программы, работающей по согласованному участниками алгоритму в среде исполнения BC/DLT, и самостоятельно выполняющей предусмотренные транзакции.

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

Стороны сами несут ответственность за существо смарт-контракта. Такая норма, с одной стороны, не ограничивает стороны в применении смарт-контрактов, а с другой стороны – избавляет арбитражи всех уровней от необходимости разбираться в существе смарт-контрактов (для этого понадобилась бы специальная экспертиза). Доказательство правовой позиции сторон в смарт-контрактах необходимо переложить на сами стороны.

Во-вторых, очевидно не имело бы смысла использовать смарт-контракт в качестве инструмента исполнения обязательств, если бы не сохранение гарантии того, что обязательства будут исполнены так, как предусмотрено смарт-контрактом. И здесь надо исходить из того, что неизменяемость, транспарентность, устойчивость, общая неотменяемость – это те качества технологии, именно ради которых стороны договорились использовать смарт-контракт в качестве инструмента исполнения обязательств.

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

В упомянутом проекте банка «А» и авиакомпании «Б» существует несколько смарт-контрактов, один из которых – это транзакция сделки по покупке билета и встречное списание денежных средств в пользу авиакомпании. Это, скорее всего, одномоментная операция и трудно себе представить, что, например, банк сохраняет за собой право признать платежи недействительными и отменить их, хотя, опять же, чисто объективно банк все еще сохраняет такое право. По нашей концепции такого права быть не должно, поскольку у иных сторон договора должны быть правовые гарантии невозможности такого отзыва, иначе их участие в таком взаимодействии содержит в себе избыточные правовые риски, которых не должно быть.

3. Квалификация смарт-контракта.

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

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

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

  • среда размещения («on-chain» – публичные, или «off-chain» – приватные блокчейны);
  • спецификация программного кода;
  • способ верификации.

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

  • идентификационные атрибуты (адрес контракта и др.);
  • владелец (учетная запись, кошелек и др.);
  • программный код контракта.

4. Паспортизация и регистрация системы.

Здесь речь идет непосредственно об информационной системе BC/DLT. Если нам важны базовые свойства BC/DLT и дочерней технологии смарт-контракта, то должна существовать экспертиза по проверке этих свойств, по результатам которой блокчейн-система получает регистрационный статус и обобщенное формализованное свидетельство (паспорт). Этот процесс называется квалификацией, то есть присвоение информационной системе правового режима информационной системы BC/DLT.

Для того, чтобы не прибегать к необходимости постоянного мониторинга сохранения в информационной системе свойств BC/DLT, необходимо предусмотреть такой порядок паспортизации, который обеспечивает аутентичность кодовой базы программного обеспечения и баз данных реестра (например, с использованием хэш-сумм).

5. Подтверждение соответствия.

Регистрация системы должна быть основана на результатах экспертизы по проверке наличия свойств BC/DLT. Необходим отдельный регламент проведения экспертизы, то есть процедурный нормативный акт, который должен быть основан на материальном нормативном акте как источнике самих критериев и нормативов – Технических требованиях BC/DLT.

Можно использовать два режима подтверждения соответствия:

  1. Аккредитация – подтверждение (по результатам экспертизы) соответствия индивидуального решения, как правило, частной, уникальной реализации BC/DLT, осуществляется только в случае, если применяется несертифицированное средство.
  2. Сертификация – подтверждение (по результатам экспертизы) соответствия серийного продукта (программного обеспечения) какого-либо производителя или сообщества разработчиков.

6. Технические требования.

Собственно, Технические требования – нормативный акт или группа связанных актов, содержащая критерии технический оценки, наличие которых в реальной информационной системе обеспечивает существенные функциональные свойства BC/DLT, а также отдельных видов.

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

7. Статус оператора

Отдельный правовой статус оператора чрезвычайно важен.

Прежде всего, необходимо разобраться с тем, что в децентрализованных системах и BC/DLT в частности отсутствуют владельцы и какие-либо операторы (в противном случае это противоречило бы природе BC/DLT). Но и признать, что система развивается сама по себе – тоже чрезвычайно легкомысленно. Важно знать, что в BC/DLT отсутствует единый центр, все технологии реализованы на узлах сети – компьютерах участников этой сети, дублирующих и разделяющих функционал друг друга.

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

И у этих ресурсов есть мейнтейнер, хозяин или координатор, к деятельности которого также придется предъявить законные требования, но это заслуживает отдельного анализа.

Начать дискуссию