Первое и обязательное условие, чтобы новая нода начала работать в системе, необходимо при первом ее запуске указать адрес ноды администратора (помните, у нас PoA), после чего на ноде администратора дать права подключаемой ноде. А дальше каждая нода «знает» об остальных нодах системы и вход вступает p2p.
Нет, не совсем так. Multichain и CryptoPro мы между собой не дружили. Multichain вообще про CryptoPro ничего не знает. На уровне транзакций он (Multichain) как работал со своей криптографией, так и работает (secp256k1). Мы же на уровни бизнес логике перед записью в Multichain данные зашифровываем, а после чтения из него — расшифровываем.
Изначально мы думали над тем, чтоб реализовать поддержку crypto.pro на уровне ядра в Multichain, но тут дрогнула рука у нас.
Однозначно быстрее, ведь мы храним информацию о бизнес объектах, а их размер зависит только от требований к структуре данных.А делать только одно — добавлять диски :) Мы же понимаем с вами, что это решение enterprise уровня.
Вот это как раз один из моментов, почему нам пришлось реализовывать «тяжелые» api. Вся работа с шифрованием данных происходит в бизнеслогике по ГОСТ с использованием CryptoPro.
На данный момент не так много порядка нескольких ГБ (в тестах было до 500ГБ). Блокчейн сторится в файловой системе в виде файлов. Поэтому и масштабируеться как файловый datastore.
Спасибо за Ваш вопрос.
Для нас решение этих задач является приоритетным. В настоящее время реализовано через проверку подключения ноды к системе. Если подключения нет — запись не возможна.
С другой стороны, специфика хранения данных (в Multichain это потоки) при восстановлении подключения позволяет смержить данные. А в виду того, что это не платежные транзакции, то угрозы двойного расхода нет. К тому же все тот же поток позволяет хранить историю изменений по уникальному ключу документа.
Что касается минимального количество нод для «кворума», то этот параметр настраивается при создании блокчейна в зависимости от требований.
Для подобных случаев разработан механизм версионности. Т.е. если нам надо у участника забрать права доступа, то владелец коллекции выпускает новый ключ шифрования и раздает его тем участникам, у которых доступ остался. Т.о. все записи, которые были сделаны ранее, участнику, лишенного прав, будут доступны как и ранее, а новые уже нет.
Изначально мы думали над тем, чтоб реализовать поддержку crypto.pro на уровне ядра в Multichain, но тут дрогнула рука у нас.
Для нас решение этих задач является приоритетным. В настоящее время реализовано через проверку подключения ноды к системе. Если подключения нет — запись не возможна.
С другой стороны, специфика хранения данных (в Multichain это потоки) при восстановлении подключения позволяет смержить данные. А в виду того, что это не платежные транзакции, то угрозы двойного расхода нет. К тому же все тот же поток позволяет хранить историю изменений по уникальному ключу документа.
Что касается минимального количество нод для «кворума», то этот параметр настраивается при создании блокчейна в зависимости от требований.