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

Цифровая подпись – централизованная vs децентрализованная

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

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

Если совсем упрощать, в этом случае Алиса и Боб могут воспользоваться каким-то публичным централизованным сервисом, куда внести свои персональные данные и после этого такая электронная подпись начинает иметь юридическую значимость.

Но, есть ряд сложностей:

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

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

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


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

Как Алиса и Боб могут подписать тот же самый документ, используя нашу инфраструктуру.

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

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

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

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

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

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


Почему для это инфраструктуры нужен Side-chain

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

  • Мы решили не использовать любой из публичных блокчейн платформ, чтобы не быть сделать наиболее удобную и специализированную структуру хранения данных. С другой стороны, чтобы в этом блокчейн не было других «мусорных» данных.

  • Delegated Proof-of-Stake – сразу три проблемы решаются этим типом консенсуса: энергоэффективность, скорость валидации новых блоков, возможность внедрения изменений в продуктовой сети.

  • Протокол, который работает уже не первый год

И вот что у нас получилось пока мы разрабатывали наш MVP:

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

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

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

  4. Возможность внедрить собственную off-chain логику с помощью plugins - например, нам надо было внедрить свое собственное хранилище для транзакций(из коробки нельзя найти все транзакции, которые были сделаны одним пользователем) – имплементация такого модуля у нас заняла всего одну неделю. И при этом, для тех участников сети, которые не хотят давать такое API – такой plugin ставить не обязательно.

  5. On-chain логика в виде транзакций - это вообще самая главная фишка на наш взгляд(собственно из-за этого мы и выбрали именно Lisk SDK). В случае если у нас поменяется логика смарт-контрактов(но не изменится структура данных) – нам достаточно имплементировать новую логику на уровне транзакций и она сразу же применится ко всему sdide-chain в целом. Если бы мы делали тоже самое, например на Ethereum, нам бы пришлось для каждого аккаунта внедрять логику этих смарт-контрактов и контролировать версионность и целостность. 

В ближайшее время мы запустим наш test-net, чтобы показать что у нас получилось, так что подписывайтесь и следите за обновлениями.

Комментарии (32)


  1. Revertis
    11.02.2022 16:55
    +3

    демократезировать

    От слова демократЕя? Или кратер?

    (обычно в личку пишу, но тут не удержался, простите)

    Edit:

    подписать его электронной подписью с каждой стороны

    Вы бы хоть попробовали прочитать этот бред, а?


    1. theioberry Автор
      11.02.2022 17:47

      Спасибо, поправил


  1. amarao
    11.02.2022 17:56

    Выглядит как попытка изобрести кейсервер. https://keyserver.pgp.com/vkd/GetWelcomeScreen.event видели?


    1. theioberry Автор
      11.02.2022 17:59

      Все же идея у ребят несколько шире, на сколько я понял из оригинальной статьи. Не только хранилище ключенй, но и публичная идентификация их не только по e-mail.


      1. amarao
        11.02.2022 18:32

        Web of trust куда тоньшее, включая непубличное доверие.


      1. count_enable
        11.02.2022 18:40
        +2

        Не понял чем шире.

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

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

        Насчёт анонимности и публичной идентификации тоже не понял. Например Пупкин Василий зарегистрировался как КриптоКотик99 с хэшем 0xDEADBEEF в вашей системе. Я прошу Василия подписать договор аренды, и вижу что какой-то КриптоКотик99 подписался под этим. Если я могу проверить что это Василий, требуя его личные данные и вычисляя хэш, я могу легко сбрутить хэши интересующих меня людей. Если я не могу этого однозначно проверить (хэш посолили), Василий разгромит мне хату и потом скажет что никакого договора он не подписывал.

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


        1. theioberry Автор
          11.02.2022 19:36

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


          1. SadOcean
            11.02.2022 20:07
            +1

            А теперь представьте, что КриптоКотик99 взял данные Василия Пушкина и зарегистрировал без его ведома хеш

            После разгромленной квартиры вы приходите к Василию, а он ни сном ни духом

            И опять все упирается в ответственность третьего лица и доверие к нему


            1. unsignedchar
              11.02.2022 20:57
              +1

              В случае с государством ответственность декларируется законодательством. А в случае анонимуса из интернетов по имени Галя - её ответственность базируется на чём?


              1. SadOcean
                14.02.2022 00:59

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

                Но в остальном все верно - доверие к ответственности Гали - это просто доверие к человеку.
                Доверие же к "государству" - это доверие к большим сообществам, которые проактивно обеспечивают ту самую ответственность и обратную связь - через институты полиции, судов, общественное порицание, репутацию и т.д.


  1. apapacy
    11.02.2022 18:09

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


    1. theioberry Автор
      11.02.2022 18:17

      берутся приватные данные от контрагента, хэшируются и сравниваются с "публичным хэшем" для этого адреса – если хэши равны, то приватные данные соответвуют этому аккаунту(пубичному ключу), разве нет?


      1. NTDLL
        11.02.2022 18:39

        Прикол в том, что необходимость подписи сертификатов в УЦ отпадает. Для нужд TLS/SSL тоже нужно подтверждать сертификат сайта, но УЦ для этого необязателен. И вот для таких случаев создана описанная в статье технология.


  1. BugM
    11.02.2022 18:30

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

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


    1. amarao
      11.02.2022 18:33

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


      1. BugM
        11.02.2022 18:46
        +2

        Вы поверите этой подписи на документе о продаже вам дома?

        Отраслевые подписи это очень узкий кейс. Там хватает самых простых решений.


        1. amarao
          12.02.2022 13:13
          +1

          Вы задали потрясающе правильный вопрос. Поверю ли я цифровой подписи о продаже дома?

          Нет. Вне зависимости от того, чьё правительство эту подпись выпустит. При покупке квартиры я видел как организовано хранение документов в land registry. Толстые чёрные папки с готичным шрифтом на котором написано 1968 и т.д. И это вселило в меня уверенность.

          А вот если бы это был цифровой сертификат, подписанный 512-битной RSA (вполне была "устойчивой" в 1993), то... спасибо, не надо.

          Я планирую владеть домом (с учётом наследников) не менее 100 лет. Какой, говорите, шифроалгоритм, обещает устойчивость против новых атак на 100 лет?

          Или, сформулируем задачу иначе: какой шифроалгоритм из 1980 с длинами ключей тех лет, всё ещё не взломан?

          Так что ответ, НЕЕЕТ. Никаких цифровых подписей. Гербовая бумага, печати, готичный шрифт на папочках и т.д.


          1. unsignedchar
            12.02.2022 14:26
            +1

            Какой, говорите, шифроалгоритм, обещает устойчивость против новых атак на 100 лет?

            Какой бумажный документ совсем невозможно подделать? ;)

            Решение стойкости шифров чисто административное - регулярный перевыпуск сертификатов, например. С бумагой то же самое - архивы, бланки строгой отчётности, хитрая полиграфия.. С бумажными документами решения уже выработаны, с электронными - в процессе.


          1. Ukaru
            14.02.2022 03:28

            Вот такие гербовые бумаги и толстые папочки, заведенные в 196.. году иногда пропадали и сотни и тысячи граждан, "собственность" которых так была подтверждена остались ни с чем.


            1. amarao
              14.02.2022 15:01

              На руках остаются документы, договора.

              Я повторю, аутентичность бумаги 1980 года с лёгкостью можно проверить. Чем проверить подпись 1980 года? сравнить md5?


              1. theioberry Автор
                14.02.2022 15:14

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

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


    1. theioberry Автор
      11.02.2022 18:39

      а чем ЭЦП от гос. органов технически отличается от любой другой ЭЦП? Только тем, что перед выдачей некий орган проверил кому выдается эта подпись. Т.е. фактически ставит в соответствие конкретную подпись с конкретным человеком (или юр. лицом). 

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


      1. BugM
        11.02.2022 18:49
        +1

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

        Неа. Вас любой суд завернет с таким.


        1. theioberry Автор
          11.02.2022 19:04

          Почему? Если это договорённости между двумя контрагентами?


          1. BugM
            11.02.2022 19:14

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

            http://pravo.gov.ru/proxy/ips/?docbody=&nd=102146610

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


            1. theioberry Автор
              11.02.2022 19:33

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


              1. BugM
                11.02.2022 19:41
                +2

                Смею предположить, что авторы оригинальной статьи не вдавались в детали именно Российского законодательства - это с одной стороны.

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

                Признание любых ЭЦП дает слишком большой простор мошенникам и при этом не дает никаких плюсов обычным людям и организациям. И зачем?

                А с другой стороны – есть такое понятие как оферта, и если одна из сторон принимает оферту другой, то дальше их взаимоотношения регулируется офертой.

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

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


                1. theioberry Автор
                  11.02.2022 19:56

                  Осталось только показать такую оферту клиенту и как-то получить подтверждение, что он с ней согласен, чтобы потом предъявлять претензии по ней :)


                  1. BugM
                    11.02.2022 19:59
                    +1

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

                    И она конечно же не дает возможности нарушать законы.


  1. kawena54
    11.02.2022 18:57

    не понял а как это сейчас работает?

    тоесть получается когда ты подключаешься метамаском и посылаешь запрос на сервер , можно "через дебагер" изменить адрес кошелька ? И то что ты залогинился в метамаске с правильным паролем\сидфразов ничего не дает?


  1. mbamber
    13.02.2022 21:03

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


  1. ggo
    14.02.2022 11:29

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


    Ничего не понятно.

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

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