Есть такая цитата достаточно известная цитата «Хочешь что-то спрятать – положи на самое видное место» – примерно такой же подход мы используем для хранения приватных данных в публичной инфраструктуре на базе технологии блокчейн. Нам хотелось бы объяснить почему, а главное зачем мы хотим хранить данные именно таким образом.
Цифровая подпись – централизованная vs децентрализованная
Для того, чтобы упростить жизнь большому количеству людей и бизнесу давно придумали такую замечательную штуку как электронная цифровая подпись. Фактически этот инструмент позволяет подписывать документы, которые имеют такую же юридическую силу, как если бы вы встретились лично и подписали их. Но на практике возникает масса вопросов.
Допустим у нас есть Алиса и Боб, которые хотят просто подписать какой-то документ, который накладывает какие-то обязательства на каждую из сторон, но физически они встретиться не могут. И на помощь как раз приходит электронная подпись. В этом случае каждая сторона всего лишь может взять документ, подписать его электронной подписью с каждой стороны и прислать друг другу публичный ключ и цифровую подпись. При этом подписать электронной подписью документ можно практически на любом компьютере, это вообще бесплатно. Но вот как доказать, что эта эл. подпись соответствует именно этому пользователю – вообще никак невозможно, фактически такая подпись не легитимна.
Если совсем упрощать, в этом случае Алиса и Боб могут воспользоваться каким-то публичным централизованным сервисом, куда внести свои персональные данные и после этого такая электронная подпись начинает иметь юридическую значимость.
Но, есть ряд сложностей:
Такой сервис требует предъявить публичные данные и сохранить их на централизованном сервере. Я не буду приводить список утечек приватных данных через различные публичные сервисы, которых с каждым годом становиться все больше, но потенциально это может стать проблемой.
Если Алиса или Боб регулярно подписывают электронной подписью различные документы с различными людьми, как правило они должны зарегистрироваться в нескольких сервисах (и везде идентифицировать себя с помощью приватных данных) и заплатить каждому сервису. Проблема еще в том, что чаще всего у меня есть обязательный платеж, за который я должен платить ежемесячно или ежегодно. Т.е. Если мне надо с помощью сервиса подписать два документ год с периодичностью в полгода, я фактически должен заплатить за весь год.
Другими словами, я должен быть зарегистрирован в куче сервисов – платить за них и везде предоставлять свои приватные данные.
Решить эту проблему в децентрализованной инфраструктуре достаточно просто. Для этого мы демократизируем цифровую электронную подпись и делаем ее публичной, так чтобы все участники могли однозначно идентифицировать контрактантов, с которыми они ведут какие-то дела.
Как Алиса и Боб могут подписать тот же самый документ, используя нашу инфраструктуру.
Завести вебе электронную подпись, так же как и в любом аналогичном централизованном сервисе. С одним лишь отличием – приватный ключ храниться только у пользователя. Даже если что-то случится с инфраструктурой – никто не будет знать приватный ключ пользователя.
Идентифицировать себя публично. И вот тут главное отличие - пользователь сохраняет публично не свои персональные данные в открытом или даже зашифрованном виде. Он сохраняет хэш этих данных. Таким образом знать, что за данных хранятся публично можно только в том случае, если я знаю что это за данные.
В этом случае, если Боб или Алиса точно хотят убедиться, что данная электронная подпись действительно принадлежат контрактанту - ему достаточно валидировать приватные данные друг друга в децентрализованном хранилище и дальше спокойно вести дела друг с другом. Никакие централизованные органы для этого не нужны. И подписывать этой подписью можно что угодно, когда угодно, сколько угодно раз.
В децентрализованной системе можно такой третей стороной фактически может выступать вообще кто угодно. Например, если Чарли лично знакома с Алисой, она легко может подтвердить валидность приватных данных, и при этом достаточно авторитетна для Боба. То она может выступить таким валидатором. В более широком смысле, конечно, таким валидатором может выступить фактически любой KYC провайдер или крупная и уважаемая организация.
Есть еще одно принципиальное отличие при использование децентрализованной публичной инфраструктуры для цифровой подписи - это уровень доверия. Чем больше я использую одну и ту же цифровую подпись, с чем большим количеством людей я работаю, чем больше органов валидировали мои данные – тем больше доверия к моему аккаунту.
Таким образом, я не меняю и не заказываю каждый раз новую электронную подпись каждый раз, когда я пытаюсь работать с новыми контрагентами, я лишь каждый раз получаю все больше и больше доверия от новых контрактантов, с которыми я работаю. Т.е. проблема доверия решается сама собой, но я не трачу на это кучу времени и денег.
Почему для это инфраструктуры нужен Side-chain
В принципе, не так важно какой публичный блокчейн взять для реализации этой модели хранения данных. Как мы уже писали – всю публичную инфраструктуру мы делаем с помощью Lisk SDK и тут хотелось бы немного заглянуть под капот архитектуры решения и структуры хранения данных.
Мы решили не использовать любой из публичных блокчейн платформ, чтобы не быть сделать наиболее удобную и специализированную структуру хранения данных. С другой стороны, чтобы в этом блокчейн не было других «мусорных» данных.
Delegated Proof-of-Stake – сразу три проблемы решаются этим типом консенсуса: энергоэффективность, скорость валидации новых блоков, возможность внедрения изменений в продуктовой сети.
Протокол, который работает уже не первый год
И вот что у нас получилось пока мы разрабатывали наш MVP:
Выделение модулей – очень круто, что при разработке блокчейн приложения всю функциональность можно разбить на различные модули. Это удобно как с точки зрения внедрения функциональности, так и с точки зрения обеспечения доступа к данным. Фактически - каждый модуль имеет доступ только к определенному разделу и на другие повлиять не может если модуль не дает такой функциональности. Такой подход дает возможность как безопасно управлять моделью данных, так и внедрять новую функциональность в новых модулях.
Код модулей и транзакций приложения блокчейн можно писать на JS или TS – это важно с той точки зрения, что любой разработчик может фактически проверить логику работы всего приложения и удостовериться в работе всей инфраструктуре. Не нужно привлекать дополнительных узкоспециализированных специалистов, которые бы удостоверились в том, что логика работает именно так как заявлено, что очень важно в работе публичных децентрализованных решениях.
Отличная документация и SDK, которая дает возможность не только использовать базовые принципы блокчейн, но предоставляет набор дополнительных библиотек – начиная от криптографии, заканчивая готовым клиентом для построения фронтона.
Возможность внедрить собственную off-chain логику с помощью plugins - например, нам надо было внедрить свое собственное хранилище для транзакций(из коробки нельзя найти все транзакции, которые были сделаны одним пользователем) – имплементация такого модуля у нас заняла всего одну неделю. И при этом, для тех участников сети, которые не хотят давать такое API – такой plugin ставить не обязательно.
On-chain логика в виде транзакций - это вообще самая главная фишка на наш взгляд(собственно из-за этого мы и выбрали именно Lisk SDK). В случае если у нас поменяется логика смарт-контрактов(но не изменится структура данных) – нам достаточно имплементировать новую логику на уровне транзакций и она сразу же применится ко всему sdide-chain в целом. Если бы мы делали тоже самое, например на Ethereum, нам бы пришлось для каждого аккаунта внедрять логику этих смарт-контрактов и контролировать версионность и целостность.
В ближайшее время мы запустим наш test-net, чтобы показать что у нас получилось, так что подписывайтесь и следите за обновлениями.