Comments 13
Но одна компания имеет право иметь только одну активную заявку на кредит в одном банке.
Звучит как простая задача для централизованной базы данных с доступом через API.
Можно создавать реплики для ускорения производительности, но лишь при необходимости.
Мы предложили решить эту задачу через блокчейн. Ведь с помощью смарт-контрактов уже на этапе заявки на кредит мы можем создать фундаментальный инвариант: «от одного уникального ИНН двух активных заявок быть не может».
А зачем?
В случае с централизованной базой Смарт-контракты эквивалентны либо слою бизнес-логики при доступе к данным, либо примитивным триггерам, если логика простая.
Может я что-то недопонял, но:
1. консенсус в вашем примере совсем не нужен т.к. single source of truth - централизованная база.
2. Этап №4 (проверка на дубликат через смарт-контракт) звучит как overkill - обычный уникальный индекс в RDBMS решает эту задачу на уровне engine.
3. Этап №5 (стейт блокчейна) на уровне БД решается более гибко - можно создавать логи, можно шустро анализировать попытки мошенничества.
Не поймите превратно, я не против блокчейн, более того, используем в банковской индустрии как гарант document tamper seal (есть такая проблема - править задним числом), но в вашем случае примерение блокчейн спорно. Как по мне - проще решить через RDBMS с соответствующими дочерними таблицами в схеме БД.
Безусловно, классическим подходом к проектированию систем такого рода является централизованный. Однако, использование технологии блокчейн по сравнению с ним имеет ряд преимуществ.
Использование блокчейна дает ультимативную прозрачность для всех участников. А в централизованном решении Банк вынужден верить на слово держателю централизованной системы, например, что заявка уже заведена ранее.
Предположим, мы через классический подход разработали централизованное решение которое решает некоторую проблему, например контроль уникальности заявки.
Дальше у нас появляется следующая задача - и мы опять строим очередное инфраструктурное решение с API, длительным сроком подключения и новым ответственным, которому нужно реализовать все с нуля. Блокчейн же еще на первом этапе позволил бы организовать "операционную систему" с прозрачными механизмами проверки всех вычислений, куда мы можем с существенно меньшими затратами выводить новые приложения и процессы. Таким образом блокчейн не только существенно повышает прозрачность для всех участников, но и позволяет снизить косты для разработки новых приложений и продуктов.
Стоит оценить так же и со стороны сети. Предположим, есть у нас блокчейн-сеть, к которой уже подключены участники A, B, C, D. Появлется новый участник E, которому нужно взаимодействовать с A и B. Вместо построения собственной системы с нуля, к которой нужно еще подключить А и B, ему проще подключиться к общей блокчейн-сети. Мало того что это будет дешевле (есть уже готовые инфраструктура и базовые сервисы), но подключившись сам, он увеличит ценность сети для будущих новых участников. Такой подход как нельзя лучше подходит как раз для построения сетей, объединяющих органы государственной власти, с их большим, но конечным числом участников и постоянно растущим числом взаимодействий.
Этот комментарий больше для новичков:
Статья полностью аффилирована и утрирована проектом Wave. Многие высказывания справедливы только для проекта Wave, учтите это про чтение.
Третий вариант — на рынок приходит разработчик отраслевого решения, заявляющий, что способен решить все проблемы с бизнес-процессами
Наконец, мы приходим к решению через блокчейн.
Чую мухлёж. Разработчик блокчейна и есть третий вариант. У него все те же возможности, что у "разработчика отраслевого решения без блокчейна", те же плюсы и минусы. Только слова модного нет в названии, а значит нельзя х10 за услуги брать.
Разница здесь в том, что участники сами смогут создавать новые процессы на основе созданной нами сети. У нас есть для этого удобные инструменты. Это реально уменьшает косты.
Т.е. они могут на каком-то DSL писать "программы" для вашего "облака". Таких вариантов 100 лет в обед без блокчейна. От геймдева для бизнесовых систем.
У нас нет специфичного DSL, смарт-контракты контейнеризированные, поэтому можно использовать любой удобный популярный язык.
Тогда чем такой "смарт контракт" отличается от обычного контейнеризированного приложения, которое общается через API?
Смысл смарт-контрактов на публичных блокчейнах ещё в том, что они обеспечивают гарантию, что их результат работы не подделан.
Гарантию того, что результат не подделан, обеспечивает блокчейн, результаты работы смарт-контрактов проходят через слой консенсуса. А контейнеризированные смарт-контракты - это удобный формат для создания нужных сценариев на основе блокчейна. Подробней про них можно почитать у нас в документации.
участники сами смогут создавать новые процессы на основе созданной нами сети
Так это и без блокчейна много раз реализовано - у этой новой системы просто должен быть открытый API и, опционально, какой-нибудь DSL, если представители бизнеса сами хотят какие-то свои скрипты писать
хмм. Какой нить условный SAP за разработку десятка форм и БД под них возьмет в разы больше, чем команда блокчейн-разработчиков, так что это миф - цены на разработку здеь такие же, или даже меньше, если брать каких нить крупных интеграторов
Если трубы переправлять с актом передачи с указанными в нём юрлицами и физлицами, к которым можно предъявить судебные претензии, то доверие в сети трубоперевозчиков повышается.
Блокчейн в корпоративной архитектуре: дань моде или необходимость?