В данном случае это не имеет значения, так как по сути IPFS используется не как децентрализованное ХРАНИЛИЩЕ ФАЙЛОВ, а как средство децентрализованного ОБМЕНА ШИФРО-КОНТЕЙНЕРАМИ. То есть:
В самом IPFS файлы присутствуют только в зашифрованном виде.
Механизм "зеркал" работает таким образом, что как только на одном из узлов к сделке прикрепили файл (который выкладывается в IPFS в виде шифро-контейнера), узлы других участников сделки узнают об этом, выкачивают шифро-контейнер из IPFS, расшифровывают его и сохраняют на своем локале в защищенной зоне. Таким образом, когда бизнес-приложение захочет обратится к файлу — он уже находится в локальном доступе.
Так как шифро-контейнеры создаются на сертификаты участников сделки, то другие участники сети даже получив их из IPFS не смогут их расшифровать
Так как процесс "раздачи" файлов достаточно кратковременный — даже для больших файлов он не превышает десятков минут от момента формирования шифро-контейнера на узле-источнике до его расшифровывания на узлах-приемниках, то отсутствует проблема с истечением срока действия сертификатов, используемых для формирования шифро-контейнера.
У вас очень интересный случай, быстро и коротко ответить на него проблематично, но если брать общую канву, то я бы рекомендовал следующее.
Первый вопрос который надо решить в таких проектах — кто будет владельцем узлов и почему они захотят ими быть. Именно про него многие забывают, а потом не могут ответить на вопрос — а зачем оно всё вообще?
Второе — это безусловно выделение бизнес-процессов и выявление "точек конкуренции" — мест связанных с гонкой приоритетов, чувствительных к времени и так далее. Эти точки затем должны особенно внимательно анализироваться на предмет безопасной и надежной реализации в смарт-контрактах.
Третье — выделение абстрактных объектов/процессов для максимальной унификации работы с ними. Скажем, кроме нашего Процесса могут потребоваться другие абстракции, например для построения сложных связей и так далее.
Четвертое — выявление специальных общих сервисов, которые могут быть полезны всем участникам — они могут быть оформлены в виде оракулов и, кстати, могут представлять одну из "плюшек" для участников.
Пятое — максимально быстро выйти на реальную инфраструктуру и хотя бы простейший, но реальный процесс. Как показывает опыт, картинка мира в голове разработчика и в реальности всегда расходятся и необходимо максимально быстро привести "голову" к реальности. Иначе многие сложные построения окажутся бесполезны из-за ошибки в базисе, иногда просто "технической".
Я попрошу поделится своим мнением Марину gelbplaneten, с которой мы вместе поднимали блокчейн в Райфе и которая сейчас активно участвует в крупнейшем российском межкорпоративном блокчейн-проекте Факторин, и, насколько мне известо, в организации международного проекта по "демократизации" блокчейн-решений. Многие эти вопросы она проходила на практике и весьма успешно.
P.S. И я был бы не против получать новости с вашего проекта :-)
Raft обеспечивает отсутствие точки отказа в сети (что для корп-сети является одним из важднейших преимуществ децентрализации) при максимальной простоте и, следовательно, надежности механизма консенсуса.
Так как подделать подпись транзакции лидер не может, а ролевая авторизация на смартах связана с аккаунтом отправителя, то максимально, что он может — не рассылать какую-то информацию. Так как все "макрооперации" на "зеркале" обязательно содержат верификацию результата исполнения после отправки транзакции, а блоки имеют сквозную связь, то с выборочной рассылкой незаметно не получится.
По той же причине — верификации плюс наличия централизованного "зондирующего" мониторинга факт нарушения работы сети из-за саботажа будет быстро выявлен, а виновный — наказан (т.к. это всё-таки корп-сеть)
Безусловно, даже располагая только возможностью временно саботировать работу сети, возможно проведение результативных атак для определенных видов сделок (например, для сделок, чувствительных ко времени). Поэтому при выборе используемого в сети механизма консенсуса необходимо учитывать подобные риски — то, что для платежного сервиса не играет существенного значения (как в нашем конкретном случае), для брокерского может оказаться весьма критическим.
К сожалению, конкретную причину, по которой нами для Асконы был выбран именно Raft, а не IBFT, я, честно говоря, уже точно не помню, но мне кажется, что основой для него послужила беседа с одним из блокчейн-экспертов на тему мега-форков, в которой он упомянул, что была информация о возможности схожих с Clique проблемах в реализованной на тот момент в Quorum версии IBFT. Учитывая ситуацию, мы просто решили не рисковать.
Собственно, каких-либо объективных причин совсем отказываться от IBFT я не вижу — надо просто его как следует погонять в реальной инфраструктуре, что мы вполне можем провести в рамках Ассоциации Финтех :-)
Относительно быстродействия Raft- и IBFT-сетей каких-либо специальных исследований мы не проводили, так как ни разу не упирались в техническую производительность собственно Quorum и объективной надобности в этом не было.
Ну, собственно тесты и предназначены для того, чтобы проверить соответствие того, что написано в доке тому, что получилось в жизни. Ведь оно не всегда совпадает...
Строго говоря, криптография по ГОСТ требуется только для работы с госучреждениями. Те компоненты, которые требовали ГОСТ и лицензии были вынесены за пределы собственно блокчейн-платформы.
Встроенную крипту по ГОСТ и какие надо лицензии будет иметь Мастерчейн.
НРД — это не цензор, а валидатор и оркестратор. Блокчейн — это, строго говоря, схема хранения данных, обеспечивающая их историческую неизменность. Он может быть и централизованным, и распределённым. Вопросы того, что принимать в блокчейн, а что нет, решаются механизмом консенсуса.
СКЗИ — это средства криптозащиты информации, то есть хэш и цифровые подписи. Без них блокчейн пока построить не удалось. В данном случае выделены именно сертифицированные СКЗИ, обеспечивающие легетимность сделки по Российскому законодательству — они были за пределами блокчейн-платформы.
Если прочитать отчет Японской фондовой биржи, ссылка на который приведена в статье, то обнаружится, что немалая его часть посвящена роли "доверенных третьих сторон". На текущий момент построение КОРПОРАТИВНЫХ блокчейн-платформ без "доверенных третьих сторон" видится крайне затруднительным. Здесь следует учитывать различие в условиях применения публичных и приватных децентрализованных реестров.
Если фул-стек девелопер + опыт мобильных приложений + опыт докера — закидывай резюме на R&D девелопер. А если ещё и Бауманка… :-)
Правда, учти, что широкая свобода предполагает не менее широкую ответственность и отсутствие лености ума.
Ну, во-вторых, мултисигн Вам в помощь.
А, во-первых, наличие реестра недвижимости не предполагает его тождественности с торговой платформой.
И таки да, пихают, куда не поподя… Но это всё-таки другой вопрос.
Вопросы криптографии — это тоже всё-таки тоже отдельный вопрос, люди же пользуются интернет-банкингом, хотя там не всегда и RSA есть. Есть отдельная концепция вынесенных аппаратных шифро-модулей из которых ключи никогда не выходят — как на смарт-картах.
Вот меня всегда интересовал вопрос — если парное программирование эффективнее одиночного, то, по-идее, программирование в тройках должно быть еще более эффективным?
Никто не пробовал?
Как говорили в моё время — каждый уважающий себя программист пишет свою библиотеку графики и свою сетевую библиотеку. Безусловно, для практического применения изложенные элементарные действия каждый программист "обернёт" по своему вкусу и потребностям — главное иметь возможность пройти этап "инициации", который часто связан с определенными трудностями из-за недостатка информации и эталонных примеров.
Нода у нас изолирована от сети на вход и изменен порт RPC по-умолчанию. Ибо сначала мы поленились и огребли :-)
Счета разблокируются на короткое время перед проведением каждой транзакции, благо имеется сказочный API-метод personal_unlockAccount.
Безусловно, при работе в боевой сети можно и нужно применять и более сложные решения защиты, но у нас потребности в них просто не было.
В данном случае это не имеет значения, так как по сути IPFS используется не как децентрализованное ХРАНИЛИЩЕ ФАЙЛОВ, а как средство децентрализованного ОБМЕНА ШИФРО-КОНТЕЙНЕРАМИ. То есть:
У вас очень интересный случай, быстро и коротко ответить на него проблематично, но если брать общую канву, то я бы рекомендовал следующее.
Первый вопрос который надо решить в таких проектах — кто будет владельцем узлов и почему они захотят ими быть. Именно про него многие забывают, а потом не могут ответить на вопрос — а зачем оно всё вообще?
Второе — это безусловно выделение бизнес-процессов и выявление "точек конкуренции" — мест связанных с гонкой приоритетов, чувствительных к времени и так далее. Эти точки затем должны особенно внимательно анализироваться на предмет безопасной и надежной реализации в смарт-контрактах.
Третье — выделение абстрактных объектов/процессов для максимальной унификации работы с ними. Скажем, кроме нашего Процесса могут потребоваться другие абстракции, например для построения сложных связей и так далее.
Четвертое — выявление специальных общих сервисов, которые могут быть полезны всем участникам — они могут быть оформлены в виде оракулов и, кстати, могут представлять одну из "плюшек" для участников.
Пятое — максимально быстро выйти на реальную инфраструктуру и хотя бы простейший, но реальный процесс. Как показывает опыт, картинка мира в голове разработчика и в реальности всегда расходятся и необходимо максимально быстро привести "голову" к реальности. Иначе многие сложные построения окажутся бесполезны из-за ошибки в базисе, иногда просто "технической".
Я попрошу поделится своим мнением Марину gelbplaneten, с которой мы вместе поднимали блокчейн в Райфе и которая сейчас активно участвует в крупнейшем российском межкорпоративном блокчейн-проекте Факторин, и, насколько мне известо, в организации международного проекта по "демократизации" блокчейн-решений. Многие эти вопросы она проходила на практике и весьма успешно.
P.S. И я был бы не против получать новости с вашего проекта :-)
Спасибо за интересный вопрос.
К сожалению, конкретную причину, по которой нами для Асконы был выбран именно Raft, а не IBFT, я, честно говоря, уже точно не помню, но мне кажется, что основой для него послужила беседа с одним из блокчейн-экспертов на тему мега-форков, в которой он упомянул, что была информация о возможности схожих с Clique проблемах в реализованной на тот момент в Quorum версии IBFT. Учитывая ситуацию, мы просто решили не рисковать.
Собственно, каких-либо объективных причин совсем отказываться от IBFT я не вижу — надо просто его как следует погонять в реальной инфраструктуре, что мы вполне можем провести в рамках Ассоциации Финтех :-)
Относительно быстродействия Raft- и IBFT-сетей каких-либо специальных исследований мы не проводили, так как ни разу не упирались в техническую производительность собственно Quorum и объективной надобности в этом не было.
Это не тот RChain. У нас нет токенов.
Ну, собственно тесты и предназначены для того, чтобы проверить соответствие того, что написано в доке тому, что получилось в жизни. Ведь оно не всегда совпадает...
Удачной охоты!
Удачной охоты!
Запрашиваем подтверждение транзакции
События контрактов (те которые event) мы пока никак не обрабатываем. Приложение написано на C++ под Windows.
.
Строго говоря, криптография по ГОСТ требуется только для работы с госучреждениями. Те компоненты, которые требовали ГОСТ и лицензии были вынесены за пределы собственно блокчейн-платформы.
Встроенную крипту по ГОСТ и какие надо лицензии будет иметь Мастерчейн.
--
НРД — это не цензор, а валидатор и оркестратор. Блокчейн — это, строго говоря, схема хранения данных, обеспечивающая их историческую неизменность. Он может быть и централизованным, и распределённым. Вопросы того, что принимать в блокчейн, а что нет, решаются механизмом консенсуса.
Нет.
Если фул-стек девелопер + опыт мобильных приложений + опыт докера — закидывай резюме на R&D девелопер. А если ещё и Бауманка… :-)
Правда, учти, что широкая свобода предполагает не менее широкую ответственность и отсутствие лености ума.
Блокчейн с отсечкой "хвоста". Точнее, "головы".
Ну, во-вторых, мултисигн Вам в помощь.
А, во-первых, наличие реестра недвижимости не предполагает его тождественности с торговой платформой.
И таки да, пихают, куда не поподя… Но это всё-таки другой вопрос.
Вопросы криптографии — это тоже всё-таки тоже отдельный вопрос, люди же пользуются интернет-банкингом, хотя там не всегда и RSA есть. Есть отдельная концепция вынесенных аппаратных шифро-модулей из которых ключи никогда не выходят — как на смарт-картах.
Вот меня всегда интересовал вопрос — если парное программирование эффективнее одиночного, то, по-идее, программирование в тройках должно быть еще более эффективным?
Никто не пробовал?
Счета разблокируются на короткое время перед проведением каждой транзакции, благо имеется сказочный API-метод personal_unlockAccount.
Безусловно, при работе в боевой сети можно и нужно применять и более сложные решения защиты, но у нас потребности в них просто не было.