Начинаю разработку блокчейна для промышленных решений

Привет, друзья! Сегодня я уже могу рассказать детали реализации своего нового протокола, который будет использоваться в промышленных решениях. В частности в распределенных системах по управлению жизненным циклом изделий. Связей поставщиков и заказчиков. И все это с применением технологии блокчейна. Особенно это важно поскольку сейчас выходят в свет новые протоколы Биткоина Startum 2 и Ethereum 2 (Раньше он работал на Casper). И, конечно, многие ждут TON от создателе ВКонтакте и Telegram. Что касается моей разработки, детально все описание и инструкции появятся на github.com и в документации на сайте проекта в течении месяца.

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

Протоколы блокчейна работают по следующему принципу:

• Установка соединения с "соседними" узлами;
• Обмен инвентарем (здесь он сообщает подключившимся узлам версию ПО, поддерживаемые типы и структуры данных, "высоту своего блокчейна", список хранимых адресов других узлов на своей стороне и пр.);

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

Все известные мне протоколы для такой синхронизации имеют фиксированный максимальный размер блока (например 1Мб или 10). Поэтому среди разработчиков постоянно идут споры, - какой размер наиболее оптимальный. В нашей реализации протокола блоки будут "гибкие" то есть размер может быть любым в рамках установленных ограничений в настройках ноды: от MIN_BUFFERLENGTH до MAX_BUFFERLENGTH. Программное обеспечение должно будет само посчитать размер данных, которые собирается передать другому узлу и отправить заголовок "data:bufferlength/Nbyte если другой узел готов это получить, то он отправляет в ответ inv:getdata и начинается процесс синхронизации. Можно за один раз передавать несколько блоков даже в вперемешку - они будут валидироваться получателем и в итоге встанут каждый на свое место в блокчейне.

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

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

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

В скором времени нужно будет придумать для протокола и название, ну например: altnet, jetstat, scanfly.