Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
Участник №1 создаёт новую коллекцию и определяет, с кем из участников системы он хотел бы поделиться её содержимым (Участник №2 и №3), затем добавляет в эту коллекцию документ.
Что делать с участниками, которые появятся после создания коллекции? Нет ничего похожего на группы, теги, или более комфортные аналоги в рамках такой задачи, если такие существуют?
Простите, не туда ответил
При добавлении нового пользователя доступ к коллекции ему предоставляет её владелец. По сути он свои приватным ключом расшифровывает симметричный ключ и шифрует его публичным ключом нового пользователям, которому предоставляет доступ. Тот уже своим приватным ключом расшифровывает симметричный ключ и получает доступ к содержимому коллекции.
На уровне ядра системы мы не оперируем такими понятиями как «Группа», возможно это будет добавлено в будущем
На уровне ядра системы мы не оперируем такими понятиями как «Группа», возможно это будет добавлено в будущем
У меня нескромный вопрос. В рамках блокчейна все транзакции, по идее, должны быть видны всем участникам (пусть и зашифрованные). То есть каждый, вступивший в систему, получит в своё хранилище не только «свои» транзакции, а вообще все.
Или у Вас как-то не так?
Или у Вас как-то не так?
Естественно, все транзакции видны, но данные в них — зашифрованы, таким образом получить доступ к ним не получится, пока Вам не выдадут ключ для дешифровки данных.
Т.е. фактически не решен вопрос прозрачности гос. закупок? Ведь мы можем всё равно скрыть данные о том, кто что выполнил, и насколько качественно, если эти данные видны лишь им двоим. А захочет третий заказчик иметь дело с ними, но их история им недоступна. Тут должно быть как раз таки всё прозрачно, видеть кто, когда и что именно выполнил, в каких масштабах. Разве нет?
Решение задачи прозрачности госзакупок — вне скоупа данной системы, более того — эта задача уже давно решена на гос. уровне — существует ЕИС (http://zakupki.gov.ru/epz/main/public/home.html) где публикуются все данные о госзакупках. Данная система была разработана для решения задачи KYC (Know Your Customer) между различными, в том числе — конкурирующими друг с другом — площадками. Т.е. речь идет не о хранении данных о закупках, а об обмене данными о клиентах площадок между этими площадками.
Все зависит от железа. На стенде (Core i5, 8Gb, SSD) если «напрямую» с блокчейном через RPC-call то получается порядка 250 записей в секунду на чтение и 160 записей в секунду на запись. Если через API с применением шифрования на той же конфигурации, получаем цифры 32 и 12 записи в секунду соответственно. Да, это немного, есть над чем поработать, главным образом — над оптимизацией работы с json объектами.
Планируем делать похожий проект, но для производства, собираем команду. Какой набор скилов нужен, какие роли, какими силами вы проект запустили, без коммерческой информации, в-общем если можно?
Мы эту Платформу реализовали довольно небольшой командой — архитектор и 2 разработчика — примерно за полгода. Скиллы — зависит от того, какую блокчейн-платформу и целевую платформу Вашего решения Вы выберете, но в целом — кроме общих скиллов разработчиков необходимо хорошо понимать детали работы выбранной блокчейн-платформы и иметь опыт работы с криптосредствами.
Прочитал и подумал, а причем тут блокчейн? Ну вот реально, вы по-моему просто используете этот хайповый термин. Судя по описанию обычное серверное приложение со своими рюшечками.
Какие мы молодцы! Даешь блокчейн в массы!:)
Подскажите, если не секрет, на каком технологическом стеке вы реализовали блокчейн?
Вы указали, что система продолжает работать при обрывах связи, разъясните, а что будет при сплите сети?
Как я понял платформ-узлов в сети не так много. Представьте ситуацию, что одна платформа засинкалась, потом ее узел перестал общаться с внешним миром, но не утерял возможности работать с клиентами. Тогда после некоторой небольшой работы с данной платформой, пользователь уверен, что все данные сохраняются. Однако блочейн же выберет самую длинную цепь подтвержденную большинством без всяких мержей, соответственно, все что было сделано на этом отдленном узле будет потеряно. Как с этим боретесь?
Аналогично как решаются следующие вопросы в случае, когда нода ушла в отрыв:
— предоставления актуальной информации
— считает ли нода себя потерянной и всячески сигналит, не давая менять данные, что она отвалилась, или просто продолжает работать
— есть ли минимальнео количество нод для «кворума»
Как я понял платформ-узлов в сети не так много. Представьте ситуацию, что одна платформа засинкалась, потом ее узел перестал общаться с внешним миром, но не утерял возможности работать с клиентами. Тогда после некоторой небольшой работы с данной платформой, пользователь уверен, что все данные сохраняются. Однако блочейн же выберет самую длинную цепь подтвержденную большинством без всяких мержей, соответственно, все что было сделано на этом отдленном узле будет потеряно. Как с этим боретесь?
Аналогично как решаются следующие вопросы в случае, когда нода ушла в отрыв:
— предоставления актуальной информации
— считает ли нода себя потерянной и всячески сигналит, не давая менять данные, что она отвалилась, или просто продолжает работать
— есть ли минимальнео количество нод для «кворума»
Спасибо за Ваш вопрос.
Для нас решение этих задач является приоритетным. В настоящее время реализовано через проверку подключения ноды к системе. Если подключения нет — запись не возможна.
С другой стороны, специфика хранения данных (в Multichain это потоки) при восстановлении подключения позволяет смержить данные. А в виду того, что это не платежные транзакции, то угрозы двойного расхода нет. К тому же все тот же поток позволяет хранить историю изменений по уникальному ключу документа.
Что касается минимального количество нод для «кворума», то этот параметр настраивается при создании блокчейна в зависимости от требований.
Для нас решение этих задач является приоритетным. В настоящее время реализовано через проверку подключения ноды к системе. Если подключения нет — запись не возможна.
С другой стороны, специфика хранения данных (в Multichain это потоки) при восстановлении подключения позволяет смержить данные. А в виду того, что это не платежные транзакции, то угрозы двойного расхода нет. К тому же все тот же поток позволяет хранить историю изменений по уникальному ключу документа.
Что касается минимального количество нод для «кворума», то этот параметр настраивается при создании блокчейна в зависимости от требований.
Как обрабатывается ситуация с компрометацией приватного ключа агента (участника)?
Для подобных случаев разработан механизм версионности. Т.е. если нам надо у участника забрать права доступа, то владелец коллекции выпускает новый ключ шифрования и раздает его тем участникам, у которых доступ остался. Т.о. все записи, которые были сделаны ранее, участнику, лишенного прав, будут доступны как и ранее, а новые уже нет.
Какие объемы в вашем блокчейне и что планируете делать когда он(блокчейн) разрастется?
Ответ на Ваш вопрос
На данный момент не так много порядка нескольких ГБ (в тестах было до 500ГБ). Блокчейн сторится в файловой системе в виде файлов. Поэтому и масштабируеться как файловый datastore.
И в перспективе сколько? 500 гигов на каждую машину это уж слишком перебор. По сути своей это и плюс и минус блокчейна.
Вопрос как раз в том, когда он разрастется до 500Гб, а произойдет это, как мне кажется гораздо быстрее чем у простой криптовалюты. И что делать когда он на столько сильно разрастется? Не бомба ли это замедленного действия?
Однозначно быстрее, ведь мы храним информацию о бизнес объектах, а их размер зависит только от требований к структуре данных.А делать только одно — добавлять диски :) Мы же понимаем с вами, что это решение enterprise уровня.
А причем здесь диски то? У вас разве нет копии на каждой локальной машине? Это же суть блокчейна, независимость от единого источника.
На каждой машине, где развернута нода блокчейна добавляем диски по мере того, как заканчивается свободное место. Относитесь к этому как к datastorage
Ничего что эта копия должна быть на каждом клиенте так то, в этом суть.
А если этого нет, если у вас все ноды контролируются вами, то у вас просто зеркалирование базы данных, это не блокчейн т.к. вы нарушаете ее основной принцип.
В общем вернувшись к моему первому комментарию — у вас обычное распределенное приложение, блокчейн здесь просто красивое модное слово.
Рекомендую перечитать, если не читали
habrahabr.ru/company/kaspersky/blog/336036
А если этого нет, если у вас все ноды контролируются вами, то у вас просто зеркалирование базы данных, это не блокчейн т.к. вы нарушаете ее основной принцип.
В общем вернувшись к моему первому комментарию — у вас обычное распределенное приложение, блокчейн здесь просто красивое модное слово.
Рекомендую перечитать, если не читали
habrahabr.ru/company/kaspersky/blog/336036
Давайте еще раз поясню, если это необходимо.
Данные хранятся именно в блокчейне, реализованном на базе Multichain, детали его реализации — не вижу смысла повторять, они описаны на www.multichain.com, в общем, классический блокчейн, за базе того же биткойновского ядра. Но работать с голым блокчейном для хранения данных не слишком удобно, поэтому поверх блокчейна нами реализован слой доступа к данным, который дает:
1) удобный интерфейс доступа к данным, а-ля документ-ориентированная БД
2) шифрование/дешифрование информации православными ГОСТовыми алгоритмами (это было важно для нашего клиента)
3) механизм подписки на обновления данных.
Именно это расширение и есть наша разработка, сам Мультичейн — открыто распространяемая опенсорсная блокчейн-платформа, мы к его созданию отношения не имеем, мы его используем. По этому странно видеть Ваше негодование, что это не блокчейн — ну ОК, исходные коды этого «неблокчейна» открыты, приведите, что именно в них заставляет Вас так думать?
По поводу контроля за нодами — наша система представляет собой не открытый блокчейн, а консорциум, что и оговорено в статье. Соответственно, контроль за узлами — в руках администраторов этих узлов, в нашем случае — ряда организаций. Но круг этих организаций — ограничен, и каждый новый узел должен получить разрешение других узлов, либо одного уполномоченного узла(в зависимости от настроек чейна), на подключение к системе. Опять же, если интересны детали — могу посоветовать обратиться к документации Мультичейна, там все подробно изложено.
Данные хранятся именно в блокчейне, реализованном на базе Multichain, детали его реализации — не вижу смысла повторять, они описаны на www.multichain.com, в общем, классический блокчейн, за базе того же биткойновского ядра. Но работать с голым блокчейном для хранения данных не слишком удобно, поэтому поверх блокчейна нами реализован слой доступа к данным, который дает:
1) удобный интерфейс доступа к данным, а-ля документ-ориентированная БД
2) шифрование/дешифрование информации православными ГОСТовыми алгоритмами (это было важно для нашего клиента)
3) механизм подписки на обновления данных.
Именно это расширение и есть наша разработка, сам Мультичейн — открыто распространяемая опенсорсная блокчейн-платформа, мы к его созданию отношения не имеем, мы его используем. По этому странно видеть Ваше негодование, что это не блокчейн — ну ОК, исходные коды этого «неблокчейна» открыты, приведите, что именно в них заставляет Вас так думать?
По поводу контроля за нодами — наша система представляет собой не открытый блокчейн, а консорциум, что и оговорено в статье. Соответственно, контроль за узлами — в руках администраторов этих узлов, в нашем случае — ряда организаций. Но круг этих организаций — ограничен, и каждый новый узел должен получить разрешение других узлов, либо одного уполномоченного узла(в зависимости от настроек чейна), на подключение к системе. Опять же, если интересны детали — могу посоветовать обратиться к документации Мультичейна, там все подробно изложено.
Если в названии продукта который вы используете есть частичка chain и они себя чем-то называют это не делает их тем чем они являются.
У вас модифицированное что-то там как-то там и пусть называется chain, но оно не соответствует критериям блокчейна, в статье которую я привел все предельно понятно изложено.
Основная претензия в том что вы пишите «Практическое применение блокчейна как распределенного хранилища данных», но это лукавство и игра слов на тренде. Распределенная система — Да, но не классический блокчейн.
У вас модифицированное что-то там как-то там и пусть называется chain, но оно не соответствует критериям блокчейна, в статье которую я привел все предельно понятно изложено.
Основная претензия в том что вы пишите «Практическое применение блокчейна как распределенного хранилища данных», но это лукавство и игра слов на тренде. Распределенная система — Да, но не классический блокчейн.
Простите, мне сложно с Вами дискутировать не понимая вашего профессионального бэкграунда. Если вы разработчик — то вот вам исходные коды системы — github.com/MultiChain/multichain — скажите, что именно в них наводит вас на мысль, что это НЕ блокчейн?
Если Вы не разработчик — «то начнем издалека» (с). Что, по-вашему, блокчейн?
Если Вы не разработчик — «то начнем издалека» (с). Что, по-вашему, блокчейн?
Подскажите, а что с лицензированием/сертификацией криптографии, Multichain вряд ли имеет лицензии/сертификацию от ФСБ/ФСТЭК?
Вот это как раз один из моментов, почему нам пришлось реализовывать «тяжелые» api. Вся работа с шифрованием данных происходит в бизнеслогике по ГОСТ с использованием CryptoPro.
а может тогда опишите чуть подробнее как удалось подружить Multichain и CryptoPro? с какими проблемами столкнулись, и как разрешили?
Нет, не совсем так. Multichain и CryptoPro мы между собой не дружили. Multichain вообще про CryptoPro ничего не знает. На уровне транзакций он (Multichain) как работал со своей криптографией, так и работает (secp256k1). Мы же на уровни бизнес логике перед записью в Multichain данные зашифровываем, а после чтения из него — расшифровываем.
Изначально мы думали над тем, чтоб реализовать поддержку crypto.pro на уровне ядра в Multichain, но тут дрогнула рука у нас.
Изначально мы думали над тем, чтоб реализовать поддержку crypto.pro на уровне ядра в Multichain, но тут дрогнула рука у нас.
Получается у вас используется двойное шифрование? сначала по ГОСТу, а потом сверху secp256k1? Юридически такой вариант прорабатывали?
P.S. Понимаю вопросы не очень технические и не очень приятные, но они по сути без их решения в бизнес задачах вряд ли как то будут решаться…
P.S. Понимаю вопросы не очень технические и не очень приятные, но они по сути без их решения в бизнес задачах вряд ли как то будут решаться…
Да, именно так. Если мы хотим получить блокчейн с гостовой криптографией — у нас есть 3 пути:
1) запилить все с нуля — очевидно, это долго, дорого и не очень надежно, т.к. вряд ли получится быстро набрать такую пользовательскую базу (читай, халявных тестировщиков), как популярные открытые проекты. Поэтому примеров таких решения я даже и не вспомню сейчас.
2) попробовать адаптировать готовую популярную платформу под православную криптографию — этим путем пошел Центробанк в своем проекте Мастерчейн (http://fintechru.org/Masterchain_whitepaper_11_08.pdf)
3) Перейти на уровень выше и рассматривать блокчейн просто как специфичный слой хранения данных, со всеми его преимуществами и недостатками, с которым обмениваться уже шифрованными/подписанными данными.
Мы в решили попробовать третий подход.
1) запилить все с нуля — очевидно, это долго, дорого и не очень надежно, т.к. вряд ли получится быстро набрать такую пользовательскую базу (читай, халявных тестировщиков), как популярные открытые проекты. Поэтому примеров таких решения я даже и не вспомню сейчас.
2) попробовать адаптировать готовую популярную платформу под православную криптографию — этим путем пошел Центробанк в своем проекте Мастерчейн (http://fintechru.org/Masterchain_whitepaper_11_08.pdf)
3) Перейти на уровень выше и рассматривать блокчейн просто как специфичный слой хранения данных, со всеми его преимуществами и недостатками, с которым обмениваться уже шифрованными/подписанными данными.
Мы в решили попробовать третий подход.
дрогнула рука
Коллеги, если Вам интересна наша система или есть вопросы которые Вы хотели бы обсудить тет-а-тет — у меня в профиле указаны контакты — пишите, будем рады сотрудничеству.
Если все полностью децентрализовано, то как участник блокчейн находит остальные сервера, чтобы распространить им информацию о записи в блокчейн?
хотелось бы подробнее узнать алгоритм поиска соседних нод.
хотелось бы подробнее узнать алгоритм поиска соседних нод.
Вот ответ на Ваш вопрос
Первое и обязательное условие, чтобы новая нода начала работать в системе, необходимо при первом ее запуске указать адрес ноды администратора (помните, у нас PoA), после чего на ноде администратора дать права подключаемой ноде. А дальше каждая нода «знает» об остальных нодах системы и вход вступает p2p.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практическое применение блокчейна как распределенного хранилища данных