Сегодня только ленивый не запускает очередной бесполезный проект на блокчейне, в этом уроке я расскажу как сделать что-то имеющее практическое применение. В качестве примера возьмем реестр пакетов наподобие npm только использующий цифровую подпись, децентрализованное хранилище Swarm и смарт-контракты на основе Ethereum.  Реестр кода на блокчейне имеет ряд приемуществ перед обычным, это: Рассмотрим каждый из пунктов по отдельности: Это важный момент в построении доверенной среды. Код должен быть подписан разработчиком, которому вы доверяете. В случае с блокчейном это происходит автоматически. Сегодня при желании любой крупный репозиторий может быть атакован, а код в нем подменен, узнать об этом вы вряд ли сможете. Блокчейн репозиторий защищает нас от подмены путем хранения подтвержденной хэш-суммы. Думаю, тут все понятно распределенное хранилище дает возможность глобального нецензурируемого доступа к данным. Управлять и владеть пакетом может один или несколько участников или даже организация. Сегодня все учетные записи и данные в большинстве случаев регистрируются на сотрудников, как следствие при увольнении передача прав на такие ресурсы может стать проблемой. Токенизация позволяет компании владеющей пакетом поставить его на баланс, занести в нематериальные активы, продать и так жалее. Так же при продаже самой компании токенизированные активы будет легко учесть и включить в стоимость. Для внедрения такого решения будем использовать смарт-контракт на блокчейне Ethereum и распределенную файловую систему Swarm. Для тех кто не знает Swarm – это децентрализованное файловое хранилище наподобие ipfs, только от разработчиков Ethereum. Сразу замечу, что запуск Swarm запланирован на 4 квартал этого года и код может немного измениться, но общая концепция останется прежней. Файлы в swarm хранятся в виде директорий. Каждая директория содержит манифест – список всех файлов в директории. Манифест это по сути JSON с массивом путей к файлам и их хешами. Каждой директории присваивается bzz-адрес, который является вершиной дерева Меркеля для файлов перечисленных в манифесте. Для идентификации файлов используется хеш-сумма защищенная от атаки удинением сообщения, для этого перед взятием хэш-суммы в начало данных добавляется значение длинны в виде 64-битного числа с порядком байт от младшего к старшему.  Хранение версии ведется по принципам semver без именованных веток (alpha, rc0 и т.п. не поддерживаются). Все пакеты хранятся в списке, где ключ — имя пакета, а значение – дерево версий. Выглядит это так: Для работы контракта используются три списка: Регистрация пакета нужна для того, чтобы связать название пакета и владельца, а так же конвертировать имя в хеш. Хеширование имени нужно для того, чтобы работа с пакетом, имеющим название любой длинны всегда занимала одинаковое время/потребляла одинаковое количество газа: Вызов из JS: Данные в Sqarm загружаются по протоколу HTTP, при этом для загрузки директории можно поместить файлы в tar-архив: В результате получим 32-битную вершину дерева Меркеля (bzz-адрес), например: Для получения файлов из swarm необходимо получить список файлов: Для регистрации новой версии достаточно вызвать метод register с указанием хеша имени, номеров версии (мажорный, минорный, билд) и bzz-адреса. Как уже говорилось выше право владения пакетом можно передавать, методы реализующие этот функционал: transfer и receive. Метод transfer назначает нового владельца, после чего новый владелец может получить пакет вызвав метод receive. Данная схема исключает возможность отзыва мажорных или минорных версии. Отозвать возможно только определенный билд. Так же нельзя отзывать последний билд минорной версии. Для этого предварительно необходимо опубликовать новый, а затем отозвать предыдущий билд. Это исключает необходимость перебирать дерево версий для переназначения новой latest версии и таким образом сокращает количество потребляемого газа. В таком виде все версии пакетов становятся глобально идентифицируемы по хешу, что позволяет, для примера, привязывать номера CVE к определенным версиям кода. А за счет применения блокчейна и распределенной структуры, изменения в вашем коде гарантированно достигнут пользователей. Если есть идеи, как улучшить данный код, оставляйте issues или PR, следите за изменениями, ну и ставьте звезды, буду признателен. Ответы на вопросы в комментарии пользователя StanislavL: Некоторые версии пакетов имеют LTS поддержку, поэтому ситуация когда в релиз попадают старшая и младшая версия вполне вероятен.  Этот функционал может сильно отличаться для каждой группы разработчиков, поэтому должен быть реализован в стороннем контракте, который и будет являться владельцем. Это упрощает код рееста и исключает привязку к единственной реализации. Semver предполагает, что сам код пакета версионируется билдами, мажорные и минорные ветки указывают на интерфейс. Другими словами, код контракта между соседними билдами может быть переписан на 100%, но при этом интерфейс останется прежним. Событие Transfered и есть OwnershipChanged: он вызывается когда получающая сторона вызвала receive и владелец сменился. Адрес кандидата не попадает в лог, чтобы не тратить дополнительный газ, так как эти данные могут быть получены из транзакции. Developer and tech writer