Комментарии 11
Думаю из -99.7% проекты уже не выбираются
Это не тот RChain. У нас нет токенов.
У меня такой вопрос: почему для Quorum был выбран Raft, а не другой консенсус — IBFT, который также есть в Quorum.
Поясню свой вопрос, Raft в «классическом» изложении защищает только от падения узла, который формирует «блоки», если такой узел падает, то роль передаётся другому. При этом по составу блока отдельного раунда голосования не проводится, поэтому «лидер» потенциально может рассылать некорректную информацию разным узлам. И в рафте отдельные участники консенсуса могут саботировать работу сети через механизм назначения нового лидера. Как планируется решать эти 2 проблемы?
Я уверен, что Raft работает быстрее, из-за отсутствия дополнительных раундов голосования. На сколько порядков производительнее чем PoA, PoW?
Спасибо за интересный вопрос.
- Raft обеспечивает отсутствие точки отказа в сети (что для корп-сети является одним из важднейших преимуществ децентрализации) при максимальной простоте и, следовательно, надежности механизма консенсуса.
- Так как подделать подпись транзакции лидер не может, а ролевая авторизация на смартах связана с аккаунтом отправителя, то максимально, что он может — не рассылать какую-то информацию. Так как все "макрооперации" на "зеркале" обязательно содержат верификацию результата исполнения после отправки транзакции, а блоки имеют сквозную связь, то с выборочной рассылкой незаметно не получится.
- По той же причине — верификации плюс наличия централизованного "зондирующего" мониторинга факт нарушения работы сети из-за саботажа будет быстро выявлен, а виновный — наказан (т.к. это всё-таки корп-сеть)
- Безусловно, даже располагая только возможностью временно саботировать работу сети, возможно проведение результативных атак для определенных видов сделок (например, для сделок, чувствительных ко времени). Поэтому при выборе используемого в сети механизма консенсуса необходимо учитывать подобные риски — то, что для платежного сервиса не играет существенного значения (как в нашем конкретном случае), для брокерского может оказаться весьма критическим.
К сожалению, конкретную причину, по которой нами для Асконы был выбран именно Raft, а не IBFT, я, честно говоря, уже точно не помню, но мне кажется, что основой для него послужила беседа с одним из блокчейн-экспертов на тему мега-форков, в которой он упомянул, что была информация о возможности схожих с Clique проблемах в реализованной на тот момент в Quorum версии IBFT. Учитывая ситуацию, мы просто решили не рисковать.
Собственно, каких-либо объективных причин совсем отказываться от IBFT я не вижу — надо просто его как следует погонять в реальной инфраструктуре, что мы вполне можем провести в рамках Ассоциации Финтех :-)
Относительно быстродействия Raft- и IBFT-сетей каких-либо специальных исследований мы не проводили, так как ни разу не упирались в техническую производительность собственно Quorum и объективной надобности в этом не было.
Давно читаю о решениях Райффайзенбанка. Сэкономили массу времени, благодарю.
Решил задать вопрос здесь, т.к. ответ может быть полезен др. читателям:
— что посоветуете в начале проектирования Blockchain решения, чтоб с одной стороны прототип не оброс на взлете лишним балластом, затрудняющим маневры, а с другой — не упустить важные детали, без которых возможно придется пересматривать решение?
Краткий контекст:
Команда MISMO (банковские стандарты США).
Разрабатываем прототип Blockchain для банковского кредитования США.
Задача — протестировать полезность, определить проблемы, привлечь пилотов, совместно сформировать рекомендации и стандарты.
На первых порах отказались от технических деталей, типа выбора Blockchain платформы, consensus algorithm, а сконцентрировались на прикладном функционале:
— выявление банковских процессов, которые выигрывают от imutable ledger of mortgage transactions.
— выявление функционала, который открывает доп. возможности. Типа smart contracts для запуска regulatory compliance проверок, или запуск обязательных процессов в рамках BPMN индустрии.
— симуляция управления хостами (регистрация, симуляция отказов), симуляция транзакций и т.п. рабочие процессы в рамках прикладной задачи.
Буду благодарен за любые советы «что делать и не делать» при создании и тестировании прототипа Blockchain решения.
Надеюсь, похожие задачи встречаются не только у меня и ответы будут полезны многим.
У вас очень интересный случай, быстро и коротко ответить на него проблематично, но если брать общую канву, то я бы рекомендовал следующее.
Первый вопрос который надо решить в таких проектах — кто будет владельцем узлов и почему они захотят ими быть. Именно про него многие забывают, а потом не могут ответить на вопрос — а зачем оно всё вообще?
Второе — это безусловно выделение бизнес-процессов и выявление "точек конкуренции" — мест связанных с гонкой приоритетов, чувствительных к времени и так далее. Эти точки затем должны особенно внимательно анализироваться на предмет безопасной и надежной реализации в смарт-контрактах.
Третье — выделение абстрактных объектов/процессов для максимальной унификации работы с ними. Скажем, кроме нашего Процесса могут потребоваться другие абстракции, например для построения сложных связей и так далее.
Четвертое — выявление специальных общих сервисов, которые могут быть полезны всем участникам — они могут быть оформлены в виде оракулов и, кстати, могут представлять одну из "плюшек" для участников.
Пятое — максимально быстро выйти на реальную инфраструктуру и хотя бы простейший, но реальный процесс. Как показывает опыт, картинка мира в голове разработчика и в реальности всегда расходятся и необходимо максимально быстро привести "голову" к реальности. Иначе многие сложные построения окажутся бесполезны из-за ошибки в базисе, иногда просто "технической".
Я попрошу поделится своим мнением Марину gelbplaneten, с которой мы вместе поднимали блокчейн в Райфе и которая сейчас активно участвует в крупнейшем российском межкорпоративном блокчейн-проекте Факторин, и, насколько мне известо, в организации международного проекта по "демократизации" блокчейн-решений. Многие эти вопросы она проходила на практике и весьма успешно.
P.S. И я был бы не против получать новости с вашего проекта :-)
По рекомендациям:
1. Мы определились (MBA — Mortgage Bankers Association, если интересно)
2.а. «выделение бизнес-процессов» — работаем.
За основу взят «Processes of Loan Lifecycle» (продукт другой группы MISMO, порядка 300 этапов) и анализ каждого процесса жизненного цикла кредита на получение преимуществ от blockchain.
2.б. выявление «точек конкуренции» — слабое понимание, боюсь мы протабанили.
Уточните пож., если не сложно, что означает этот термин. Гугл особо не помог.
3. над абстрактными объектами/процессами еще не работали и не размышляли.
Можно ли предположить что объекты/процессы проявятся в процессе прототипирования?
4. есть ли связь «специальных общих сервисов» с №№ 2.а и 3, или это что-то иное?
5. огромное спасибо, ваш совет коррелирует с нашим опытом — создание прототипа.
После 2х лет теоретических изысканий мы утонули в теориях, отказались от этого подхода и начали заново черезе создание прототипа. По ходу работы ожидаем обрастание деталями.
Еще раз благодарю за советы.
P.S. И я был бы не против получать новости с вашего проекта :-)Прототип в открытом доступе, но процессы у нас движутся крайне медленно. :)
Страничка с прототипом и обвязкой в этой секции меню:
Одна из главных ошибок стартапов — потратить время на освоение нескольких блокчейнов и выбор лучшего. Мой совет: если нужен POC и понятен кейс для тестирования, лучше сделать MVP в «песочнице» с готовой блокчейн-инфраструктурой.
— За относительно небольшие деньги: QuickNode , Settlemint
— Бесплатно, с поддержкой Ethereum, Quorum и Hyperledger Fabric: Kekker.
Любой блокчейн будет иметь порог вхождения, а его преодоление отнимет время от разработки бизнес-приложения.
Самые распространенные проблемы:
— На первых этапах — не так просто развернуть сеть даже из трех узлов и поддерживать ее живой дольше одного рабочего дня. Нужен мониторинг, как правильно писал Павел. А потом — разбор проблемы.
— Кратное усложнение обновлений: количество установок примерно равно числу узлов в сети.
— Даже у зрелых технологий (Ethereum, Quorum, Hyperledger Fabric и пр.) встречаются ошибки, полезной информации по решению которых нет. Сейчас стало чуть легче, официальная документация заметно пополнилась. Но иногда единственным решением остается пересоздание узла.
По опыту — 20% времени POC займет бизнес-логика и 80% — написание своего мониторинга, логики отработки ошибок и пр.
Желаю вам удачи, держите в курсе!
В данном случае это не имеет значения, так как по сути IPFS используется не как децентрализованное ХРАНИЛИЩЕ ФАЙЛОВ, а как средство децентрализованного ОБМЕНА ШИФРО-КОНТЕЙНЕРАМИ. То есть:
- В самом IPFS файлы присутствуют только в зашифрованном виде.
- Механизм "зеркал" работает таким образом, что как только на одном из узлов к сделке прикрепили файл (который выкладывается в IPFS в виде шифро-контейнера), узлы других участников сделки узнают об этом, выкачивают шифро-контейнер из IPFS, расшифровывают его и сохраняют на своем локале в защищенной зоне. Таким образом, когда бизнес-приложение захочет обратится к файлу — он уже находится в локальном доступе.
- Так как шифро-контейнеры создаются на сертификаты участников сделки, то другие участники сети даже получив их из IPFS не смогут их расшифровать
- Так как процесс "раздачи" файлов достаточно кратковременный — даже для больших файлов он не превышает десятков минут от момента формирования шифро-контейнера на узле-источнике до его расшифровывания на узлах-приемниках, то отсутствует проблема с истечением срока действия сертификатов, используемых для формирования шифро-контейнера.
Блокчейн-платформа R-chain: общая архитектура и эволюция