Хочу проект по EXONUM

Проекты
1

Всем привет. Недавно в телеге я “исполнил” что-то такое, что может со стороны выглядеть сомнительно в плане корректности. Если именно так, то скажите мне :slight_smile:

О чем речь: Я в группе EXONUM стал задавать вопросы по фунционалу, который хотел бы в нем видеть, получил ответ - что такого нет. Спросил, если найдутся программисты которые захотят реализовать, можно ли будет рассчитывать на помощь Bitfury? Ответили - пишите письма на два адреса - обсуждаемо. Было бы вообще здорово, если бы я был таким программистом или у меня были бы хорошие знакомые программисты на Rust кому было бы интересно разобраться и освоить (и сделать лучше) EXONUM.
Но увы, пока ни того ни другого нет.
И я предварительно спросив в чате раста разрешение задать вопрос по EXONUM - просто закопипастил туда переписку. Достаточно быстро порешали, что все таки это оффтоп. Я согласен. Но нужный функционал мне по прежнему интересен и я думаю что у него есть коммерческий потенциал и просто интересно реализовать.

Поэтому я здесь также закопипащу переписку из чата. Вдруг здесь найду тех, кому будет интересно:

Игорь, [23.02.19 10:07]
Вопрос есть. На одной ноде можно запустить 100 валидаторов для 100 разных чейнов и под одной осью без деления на виртуалки?

Игорь, [23.02.19 10:08]
Чейны EXONUM конечно

Игорь, [23.02.19 10:08]
Или это плохая идея с точки зрения надежности ?

Игорь, [23.02.19 10:16]
Поясню для примера. Есть много много разных чейнов с редкими транзакциями. До 5 или до 100 в день. Задача максимально эффективно это упаковать в железо например для предоставления сервиса валидации

Игорь, [23.02.19 10:16]
Большому числу таких клиентов

Ilya Bogdanov, [23.02.19 10:54]
[In reply to Игорь]
можно, если позволит производительность хоста

Ilya Bogdanov, [23.02.19 10:54]
[In reply to Игорь]
100 сервисов на одной ноде не подходят?

Игорь, [23.02.19 11:00]
[In reply to Ilya Bogdanov]
Извините не понял вопроса. Сервисы же - это ещё и термин из самого фреймворка (аналог смартконтрактов)

Игорь, [23.02.19 11:01]
что такое 100 сервисов на одной ноде в Вашем вопросе?

Игорь, [23.02.19 11:04]
Ещё проще. Есть допустим на аутсорсе пусть те же 100 клиентов из малого бизнеса, и у них бардак с документооборотом, например с актированием. Бухши у них постоянно говорят, что вот такой то менеджер мне акт не отдавал, а манагер говорит - отдавал :). Внедряем таким наш БЧ на Эксонуме, один два валидатора у них в офисе, один у них в облаке, один у нас - у Аутсорсера - фиксируем прием-передачу документов подписями сотрудников и бухши

Ilya Bogdanov, [23.02.19 11:04]
в одной ноде (бинарном приложении) может работать несколько сервисов. В официальных примерах используется максимум по три, но технически их может быть и сотня. Это не отдельные чейны правда будут.

Игорь, [23.02.19 11:04]
И вот таких клиентов у нас допустим 100 или 200 или 1000

Игорь, [23.02.19 11:04]
и это отдельные чейны

Игорь, [23.02.19 11:04]
И вот интересует максимально эффективная упаковка

Игорь, [23.02.19 11:05]
все таки для каждого чейна надо будет свою виртуалку поднимать ?

Ilya Bogdanov, [23.02.19 11:05]
а, ну окей

Ilya Bogdanov, [23.02.19 11:06]
ну ничего не мешает запускать по несколько на одном хосте. Но виртуалки не просто так придумали, они помогают менеджить ресурсы.

Игорь, [23.02.19 11:08]
… если однотипные ресурсы-сервисы - и уже где то зарезервированы и так на стороне - да ещё и с анкорингом :slight_smile: то для уменбшения накладных расходов хотелось бы иметь возможность одним ядром разные чейны обслуживать… может бредово конечно

Игорь, [23.02.19 11:51]
и смежный этому вопрос-хотелка. Кластера динамические. То есть возможность легкого масштабирования просто добавлением нод (нод кластера а не ноды валидации какого то одного блокчейна)

Игорь, [23.02.19 11:52]
Может это уже реализовано в EXONUM - а я просто не знаю ?

Ilya Bogdanov, [23.02.19 22:23]
[In reply to Игорь]
Это совершенно ортогональная возможностям Exonum хотелка, поэтому ответ - нет.

Игорь, [24.02.19 17:06]
А если найдутся люди программисты, которые будут дорабатывать фреймворк в эту сторону, на какую то помощь со стороны Bitfury можно будет рассчитывать? Или там настолько ортогонально, что будет иметь смысл все с нуля делать, а значит в качестве основы брать то, что сейчас есть в EXONUM - не будет иметь смысла ?

Ilya Bogdanov, [24.02.19 17:12]
[In reply to Игорь]
Это нужно обсуждать, напишите на exonum@bitfury.com, можно копию мне (ilya.bogdanov@bitfury.com)

1 лайк
2

Хмм, а что конкретно нуждается в доработке?
В чём проблема запустить на одном хосте 100 процессов?
Если не хватает возможности что-то сконфигурировать - это легко подровнять напильником.
Лишь бы, как сказали в переписке, ресурсов системы хватало, что уже зависит от загрузки соответствующих блокчейнов.

1 лайк
3

Для начала хотелось бы упростить “терминологию”, чтобы не запутываться. Я укажу как я знаю, но не претендую на точность последней истанции, потому что БЧ от БЧ все-таки отличаются.

Во множестве БЧ проектов, есть ОДИН тип ноды - “просто нода”, которая делает все и вся, выполняет/содержит в себе ВЕСЬ необходимый функционал, хранит весь БЧ и т.д., т.е. одновременно выполняет множество процессов/задач внутри одной программы/JVM/ит.д. Она может стоять “отдельно на серваках” (в облаке, виртуалке и т.д, не суть важно). Она также может стоять у конечных пользователей. В каких то БЧ часть функционала “выносят” на “спец.ноды”, но пока мне кажется лучше исключить этот случай для простоты.

В сети ноды “обычно” объединяются через общие :

  • список начальных пиров (IP адреса, откуда начинать опрос)
  • общие сетевые параметы типа порты веб-сокета(ов) и/или rest-api порты, которые типа одинаковые у всех нод в одной сети (если порты в разных сетях гарантировано отличаются, то данные “не из той” сети гарантировано не попадут в неправильную ноду). Т.е. делается некоторая изоляций по физическим портам.

След.уровнень абстракции - chainId, как некоторый “внутренний признак” внутри передаваемых данныхмежду нодами (в учетом разделения сетей через порты/сокеты), который позволяет сделать как-бы “логические подсети внутри сети физических нод”.

Не знаю как у других (exonum), должны быть проекты, где chainId подразумевает использование полность отдельной, изолированной БАЗЫ/СХЕМЫ для хранения полностью отдельного блокчейна, каждый со своим уникальным набором блоков и данных. Это типа некоторое деление на tenat-ы - польностью логически отделенные чейны. Тут важна “надежность кода”, чтобы данные относящиеся к разным организациям никогда не попадали и не могли ни при каких ошибках/атаках попасть в “чужой chainId”, что потенциально возможно.

Если код ноды написан так, что она работает одновременно со множеством баз/схем(т.е. чейнов = chainId) в рамках одной физ-й сети (которые разделенны между собой конфигами портов), то вопрос “а сколько туда фирмочек/контор можно запихнуть каждая под своим уникальным chainId” - не имеет точного ответа, т.к. зависит от кода, железа и нагрузки на чейн (с учетом не равномерной нагрузки от разных компаний).
Разрабы тоже далеко не всегда могут (без реальных тестов на вполне конкретно указанном железе) ответить на такой вопрос.

1 лайк
4

Как я понял из ответа в чате EXONUM, что сейчас как раз написано так, что нельзя одной нодой (не физической, в которой нарезаны виртуалки или контейнеры, а скажем так, нодой-программой) разные чейны обслуживать. … И примерно понятна причина, хоть и приватного БЧ фреймворк - но позиционируется для высоконагруженного БЧ, заявлена большая скорость обработки транзакций. Но я вполне вижу “кейсы”, когда приватный БЧ используется в системах-задачах с небольшим числом транзакций в единицу времени. Но таких заказчиков может быть много и “борьба” за таких многочисленных, но не очень богатых заказчиков ведется в том числе и в направлении уменьшения накладных расходов по оборудованию, обслуживанию. И вот было бы интересно - можно ли потенциальную мощь EXONUMA “вывернуть наизнанку” :slight_smile: Не много транзакций в единицу времени для одного чейна, а много чейнов с небольшим кол-вом транзакций, без лишенго оверхеда.

5

Да, именно это я интуитивно понял, но решил уточнить.

Собственно ответ прост, т.к. он актуален для большинства БЧ кода…
Скорее всего нельзя, потому что за chainId стоит “отдельная БД, отдельный каталог, настройки и т.д.”. “Ядро” одной программы-ноды обслуживает и работает на одну БД. Т.е. можно ноду стопнуть, переконфигурить на “другой chainId” и запустить в другом БЧ.

Переделка кода так, чтобы он одновременно работал с несколькими отдельными ядрами, которые смотрять в отдельные БД (по chainId) скорее всего будет НЕ тривиальной задачей, это фактически тотальная переделка архитектуры ноды. Это со всеми вытекающими последствиями, в том числе и обратной совместимости с легаси данными, если это будет актуально где-то (зависит от принятия архитектурных решений).

Изначально бОльшая часть БЧ проектов, под такой “режим работы” НЕ проектировалось, знаю по своему проекту и коду. Только сейчас такие вещи появляются, как “было бы не плохо, но нет жесткой необходимости, т.к. влечет МАССУ работы с сомнительным бенефитом”.

Если хотите выступить некоторым “SAAS провайдером” в сфере БЧ, то скорее всего придется разворачивать массу сеток под массу заказчиков. Я точно не могу сказать, есть ли хотя бы один проект БЧ, который работает так, как вам хотелось бы, т.е. одновременнно с разными БД, при этом эти “ядра” должны быть достаточно секьюрно изолированы друг от друга и обслуживать разные chainID логические сети в один момент времени.

1 лайк
6

Вот по этому “должны” тоже есть повод обсудить. Какие то проблемы самим же БЧ и решаются, ошибка (инфобезопаспроблема) на одной ноде не даст по чейну распространиться из за наличия других нод. Другой вопрос - могут ли это быть ошибки - атаки, которые пройдут одновременно “через все ноды” именно по причине только минимальной логической изолированности (а не максимально физической)

7

Всё так - один инстанс Экзонума обслуживает один блокчейн.

Однако ничто не мешает конфигурировать работу ноды на конкретных портах. Это не делает ноду “невидимой для других нод”. Просто Экзонум - это приватный блокчейн, все его ноды находятся под управлением конкретной организации (которая может быть совместным проектом нескольких компаний).

То есть на одном хосте можно обслуживать сотню блокчейнов - если они не высоконагруженные, хост справится. Поэтому “персональный блокчейн для бедных” - не является проблемой.

С другой стороны - в рамках блокчейна может быть множество сервисов, что в общем похоже на множество “субчейнов”, с той лишь разницей, что нет никакого сокрытия их друг от друга.

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

Подобным образом, например, работает Transparency International, которая держит у себя аудиторы государственных проектов на Экзонуме. При этом проекты независимы друг от друга, как и государства :slight_smile:

1 лайк
8

Если как вы хотите - обслуживать множество БЧ проектов на “одном наборе портов и БД”, то это скорее всего серьезные переделки архитектуры, т.е. фактически всего кода, снизу от доступа к БД (веб-сокет транспорта) до остальных верхних подсистем (рест-апи, может UI). А бенефиты - сомнительные, того же можно добиться запуском нескольких “нод-программ” на разных портах в одном физическом-виртуальном железе.

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

1 лайк
9

Какие то проблемы самим же БЧ и решаются, ошибка (инфобезопаспроблема) на одной ноде не даст по чейну распространиться из за наличия других нод. Другой вопрос - могут ли это быть ошибки - атаки, которые пройдут одновременно “через все ноды” именно по причине только минимальной логической изолированности (а не максимально физической)

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

Другая проблема - какая-то нода (или их группа) может себя вести некорректно. Это может быть результатом взлома, или результатом злонамеренности какой-то из сторон. Экзонум основывается на разновидности “византийского” (Bysantium Fault Tolerant) консенсуса. Соответственно мы имеем гарантии, что если две трети нод “живы и здоровы” - блокчейн продолжает функционировать. Кроме того, благодаря обязательной криптографической подписи, мы сразу видим, какая сторона ведёт себя некорректно. Это легко решаемая административно проблема.

Третья проблема - логические ошибки в коде сервисов. Если сервис написан некорректно, ни консенсус, ни блокчейн не спасут. Однако в случае независимого приватного блокчейна не потребуется хардфорк или уговаривание большого комьюнити, чтобы исправить баг в сервисе.

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

Дальше уже вопрос, что за BaaS вы желаете предоставлять. Если вы пишете код целиком сами (усилиями одной организации, предоставляющей сервис) - это одно: у вас есть возможность контролировать его и проводить аудит безопасности. Если код пишут третьи лица, а вам в лучшем случае попадают в руки исходники - это совсем другое, и другая цена вопроса проведения аудита такого софта и возможно это выходит за рамки окупаемости “блокчейна для бедных”. Но всё это уже организационные вопросы, прямо не касающиеся блокчейна.

2 лайка
10

В этом нет необходимости. Экзонум конфигурируется для работы на разных портах и с независимыми базами. В этом можно убедиться с первого же hello world (cryptocurrency), в котором запускается четыре ноды на одном хосте (на машине разработчика) с базами лежащими по разным путям.

2 лайка
11

Хочу “убедиться” прежде чем продолжу вопросы задавать. Всё таки надо самому пощупать, а не самонадеянно считать, что понял работу системы по обзорам и кратким мануалам :slight_smile: Очень большое спасибо, irbis и blandger за участие !

1 лайк