Александр Диденко
Почему так важны
протоколы консенсуса?
Финансовый университет при Правительстве РФ
Александр Диденко, Финансовый университет при Правительстве РФ
Алгоритмы консенсуса
Поговорим об алгоритмах, или протоколах, консенсуса — о том, что это такое, зачем это нужно, почему так много протоколов, чем отличаются разные ситуации применения этих протоколов. Рассмотрим для примера следующую теоретическую ситуацию: есть крепость, окружённая с разных сторон частями армии, которые возглавляются генералами. Некоторые из генералов — предатели. Если все армии одновременно нападут на крепость, то их ждёт победа; генералам необходимо решить, когда нападать. Если армии нападут одновременно, будет хорошо, если неодновременно, то армии будут разбиты поодиночке. Поскольку некоторые генералы — предатели, им выгодно сообщать другим генералам ложную информацию (между собой генералы общаются с помощью гонцов). Это — классическая постановка задачи, известной как «Проблема византийских генералов» и впервые озвученной в работе Лампорта, Шостака и Пиза как некоторое обобщение «ситуации двух генералов», поставленной в более ранней работе.

Результат Лампорта, Шостака и Пиза заключается в том, что при работе в синхронной среде (здесь — генералы одновременно принимают решения) и при условии, что 2/3 (или более) генералов — не предатели, они могут, рассылая гонцов и не прибегая к шифрованию, достичь консенсуса и напасть одновременно. Если они используют некое подобие криптографии — всё совсем замечательно. Вы спросите, какое отношение это имеет к распределённому реестру? А вот какое. Одно из моих самых любимых определений распределённого реестра (далее — РР) гласит: РР — система, позволяющая группе участников, которые не доверяют друг другу, приходить к взаимному согласию о существовании, природе и развитии некоторого набора коллективных фактов без необходимости полагаться на помощь доверенной третьей стороны, которая централизовала бы их работу. Вот что такое РР.

В общем, теперь понятно, что в ситуации РР и в ситуации византийских генералов есть определённые параллели: есть набор фактов (или мнений относительно фактов), которые могут отличаться. Всем участникам нужно выбрать одно мнение. У византийских генералов это мнение — нападать или не нападать; в случае с процессорами и сенсорами (для которых изначально и была сформулирована задача византийских генералов) нужно договориться о значении некоторого параметра, измеряемого сенсорами, при этом некоторые из сенсоров неисправны, а исправные как раз должны договориться; в случае с криптовалютами фактами являются транзакции, совершённые с каждого кошелька на другие, необходимо выбрать набор фактов, исключающий возможность двойного расходования, то есть траты одной единицы валюты на два различных кошелька. В других приложениях — не криптовалютных РР — тоже имеются определённые наборы фактов: значения сенсоров в защищённом промышленном Интернете вещей или Интернете энергии, информация о том, что происходит с товаром в РР, используемых для управления цепочками поставок, информация о том, какие сделки совершаются сторонами в реестрах, используемых в трейдинге, — везде существуют наборы фактов, относительно которых нужно достичь консенсуса.

Для этого используется определённый набор правил, или протокол, о котором уместно думать как о некоторой игре. В этой игре есть правила, если игроки следуют правилам, то рано или поздно придут к одному мнению о наборе фактов. Если подключить экономическую мотивацию к этому протоколу, то есть делаем так, что игрокам по какой-либо причине выгодно следовать тем или иным правилам, то мы попадаем в сферу ответственности дисциплины, известной как «дизайн механизмов». Если мы при это принимаем во внимание, что имеется несовершенство компьютерного, технического свойства, то мы попадаем в «дизайн алгоритмических механизмов». Здесь очень важно обратиться к результату, сформулированному в работе Фишера, Линча и Патерсона «Impossibility of Distributed Consensus with One Faulty Process».

Они говорят, что ситуация с византийскими генералами прекрасна тем, что они принимают решения в синхронной среде: не бывает такого, что один из генералов сломался и не говорит вообще ничего. Он не может сломаться, он человек. Но если он всё же сломался? Получается асинхронная среда, в которой можно вечно ждать сообщения от одного из генералов. Фишер, Линч и Патерсон говорят, что если хотя бы одна нода неисправна, консенсус может так и не быть достигнут. Они выделяют два очень важных параметра: liveness/termination (если какая-то система гарантирует свойство liveness, то в этой системе игроки не застрянут и рано или поздно придут к окончательному решению) и safety/agreement (если один генерал решил нападать, то остальные рано или поздно тоже решат нападать; не получится разделения во мнениях 50/50; не будет существовать две версии одной и той же истории транзакции). Оба свойства не могут быть достигнуты с гарантией при работе в асинхронном режиме.

В системах с разным уровнем синхронности, доверия участников друг к другу нужно сделать так, чтобы они как-то приходили к консенсусу. Самый распространённый алгоритм — «proof-of-work», предложенный Сатоши Накамото. Имеются участники, соревнующиеся в скорости решения некой криптографической задачи, не имеющей никакого смысла. Но для её решения нужно потратить много ресурсов, а для проверки правильности — немного. Похожим образом действует патентная система США, где для получения патента нужно затратить около десяти тысяч долларов, а чтобы проверить или оспорить — около трёхсот долларов. Получается, что один участник решает, какой набор фактов правильный, и все его слушаются, но если кто-то обнаружит ошибку, то тот, кто предложил ложное решение, потеряет деньги. Выходит, что преднамеренно обманывать систему невыгодно.

Чем хороши такие системы? Они легко масштабируются и успешно функционируют, даже если «генералов-предателей» 49%; однако при этом они очень энергозатратны и работают медленно, но всё же на них работает большая часть криптовалют. Другая группа алгоритмов — «proof-of-weight». Там происходит реальное голосование (как в акционерном обществе) пропорционально чему-то (токенам у ноды — «proof-of-stake», дисковому объёму — «proof-of-spacetime» и т. д.). Но это не объёмы вычислительной силы, а объёмы чего-то ещё.
Есть особый подвид этого алгоритма, названный «делегированный proof-of-stake». Здесь участники сначала выбирают выборщиков, которые имеют право достигать консенсуса. Атаки на такого рода алгоритмы очень дорогие, сами алгоритмы быстрые, энергоэффективные и децентрализованные. Проблема заключается в том, что участники ничем не рискуют: им выгодно делать ставку на различные взгляды, чтобы хотя бы одна из ставок выиграла. Более продвинутые версии алгоритма делают поведение участников рискованным.

Существует ещё целое семейство алгоритмов под «зонтиком» византийского соглашения, более подробно о них — в нашем лонгриде.

Распределенный реестр — система, позволяющая группе участников без всякого доверия друг к другу приходить к взаимному согласию
о существовании, природе и развитии того или иного набора коллективных фактов без необходимости полагаться на помощь некоего доверенного, централизующего их работу стороннего участника.

Источник
Распределенный реестр — система, позволяющая группе участников без всякого доверия друг к другу приходить к взаимному согласию о существовании, природе и развитии того или иного набора коллективных фактов без необходимости полагаться на помощь некоего доверенного, централизующего их работу стороннего участника.

Источник
Распределенный реестр — система, позволяющая группе участников без всякого доверия друг к другу приходить к взаимному согласию о существовании, природе
и развитии того или иного набора коллективных фактов
без необходимости полагаться
на помощь некоего доверенного, централизующего их работу стороннего участника.

Источник
Распределенный реестр — система, позволяющая группе участников без всякого доверия друг к другу приходить к взаимному согласию о существовании, природе и развитии того или иного набора коллективных фактов без необходимости полагаться на помощь некоего доверенного, централизующего их работу стороннего участника.

Источник
Распределенный реестр — система, позволяющая группе участников без всякого доверия друг к другу приходить
к взаимному согласию
о существовании, природе
и развитии того или иного набора коллективных фактов без необходимости полагаться на помощь некоего доверенного, централизующего их работу стороннего участника.

Источник
Каждый участник может обладать полноценной копией реестра.
Особенности технологии:

1.
2.
3.
Синхронизация копий реестра происходит на основе протокола достижения распределенного консенсуса, то есть соглашения
среди участников на добавление новой информации.
Каждый участник взаимодействия может иметь доступ к истории транзакций.
Каждый участник может обладать полноценной копией реестра.
Особенности технологии:

1.
2.
3.
Синхронизация копий реестра происходит
на основе протокола достижения распределенного консенсуса, то есть соглашения среди участников на добавление новой информации.
Каждый участник взаимодействия может иметь доступ к истории транзакций.
Каждый участник может обладать полноценной копией реестра.
Особенности технологии:

1.
2.
3.
Синхронизация копий реестра происходит на основе протокола достижения распределенного консенсуса, то есть соглашения среди участников на добавление новой информации.
Каждый участник взаимодействия может иметь доступ к истории транзакций.
Каждый участник может обладать полноценной копией реестра.
Особенности технологии:

1.
2.
3.
Синхронизация копий реестра происходит
на основе протокола достижения распределенного консенсуса,
то есть соглашения
среди участников
на добавление новой информации.
Каждый участник взаимодействия может иметь доступ к истории транзакций.
Каждый участник может обладать полноценной копией реестра.
Особенности технологии:

1.
2.
3.
Синхронизация копий реестра происходит
на основе протокола достижения распределенного консенсуса,
то есть соглашения
среди участников
на добавление новой информации.
Каждый участник взаимодействия может иметь доступ к истории транзакций.
Оба определения указывают на протокол достижения консенсуса (согласия) как существенную особенность технологии РР.
Но они оба или не исчерпывающие, или описывают свойства,
не всегда присущие распределенным реестрам.
Уже сейчас существует множество вполне рабочих кейсов,
когда участники различных экономических, политических
или — шире — социальных взаимодействий достигают взаимного согласия о некоторых важных для них фактах, и эти эпизоды достижения согласия фиксируются в распределенных реестрах, приобретая свойства неизменности и аутентичности.
Оба определения указывают на протокол достижения консенсуса (согласия) как существенную особенность технологии РР. Но они оба или не исчерпывающие,
или описывают свойства, не всегда присущие распределенным реестрам.
Уже сейчас существует множество вполне рабочих кейсов, когда участники различных экономических, политических или — шире — социальных взаимодействий достигают взаимного согласия
о некоторых важных для них фактах, и эти эпизоды достижения согласия фиксируются в распределенных реестрах, приобретая свойства неизменности
и аутентичности.
Оба определения указывают
на протокол достижения консенсуса (согласия) как существенную особенность технологии РР.
Но они оба или не исчерпывающие,
или описывают свойства, не всегда присущие распределенным реестрам.
Уже сейчас существует множество вполне рабочих кейсов, когда участники различных экономических, политических или — шире — социальных взаимодействий достигают взаимного согласия о некоторых важных для них фактах, и эти эпизоды достижения согласия фиксируются
в распределенных реестрах, приобретая свойства неизменности
и аутентичности.
Оба определения указывают
на протокол достижения консенсуса (согласия)
как существенную особенность технологии РР. Но они оба
или не исчерпывающие,
или описывают свойства,
не всегда присущие распределенным реестрам.
Уже сейчас существует множество вполне рабочих кейсов, когда участники различных экономических, политических или — шире — социальных взаимодействий достигают взаимного согласия о некоторых важных для них фактах, и эти эпизоды достижения согласия фиксируются
в распределенных реестрах, приобретая свойства неизменности
и аутентичности.
Оба определения указывают
на протокол достижения консенсуса (согласия)
как существенную особенность технологии РР. Но они оба
или не исчерпывающие,
или описывают свойства,
не всегда присущие распределенным реестрам.
Уже сейчас существует множество вполне рабочих кейсов, когда участники различных экономических, политических или — шире — социальных взаимодействий достигают взаимного согласия о некоторых важных для них фактах,
и эти эпизоды достижения согласия фиксируются
в распределенных реестрах, приобретая свойства неизменности и аутентичности.
Например
Направление
Кейсы
Примеры фиксируемых фактов
Управление цепочками поставок/Логистика
BHP Billiton, IBM, EverLedger, Trade Connect, Maersk, Walmart
Прибытие товара в пункт назначения; целостность контейнера и соблюдение условий транспортировки (напр. t) в пути и т.п.
Голосование
НРД, Nasdaq
(для Эстонии),
штаты Делавер
и Западная Вирджиния, A.D.X.
Отдача голосующим голоса за решение
или кандидата; участие голосующего
в голосовании
Права собственности
BHP Billiton, Thomas Reuters, Georgia Land Registry, Estonia e-Residence
Переход права собственности
на недвижимость
Smart Grid / интернет энергии
Consensus Systems
(для City of Brooklyn), Onder
Потребление
или генерация определенного объема энергии определенным узлом
Системы лояльности
IBM, Royal Bank
of Canada, UnionPay
Эмиссия
и использование токена
Страхование
Сбербанк, B3i Consortium, EverLedger, Socratus
Заключение договора, поступление средств, наступление страхового случая и др.
Торговое финансирование, факторинг
Сбербанк, АльфаБанк, DigitalTradeChain, HSBC, Barclays, UBS, Bank of America
и многие другие
Обмен финансовыми сообщениями
Сбербанк, ЦБ РФ, SWIFT, VISA
KYC
Сбербанк, АкБарсБанк, Rabobank, FidorBank, Dutchbunq
Биометрическая идентификация, биография
и трудовой путь клиента, источники происхождения
его средств и т.п.
Трейдинг
и клиринг
Goldman Sachs, JP Morgan, HSBC, Deutsche Bundesbank, PTDL Group Barclays, HSBC
Заключение сделок
и исполнение по ним
Управление активами
и токенизация
JPMorgan, IBM
Содержание и бэктест торговой модели, индивидуальные ограничения клиентских счетов, трек-рекорды и т.п.
Криптовалюты
История сделок
Типы
и особенности бизнес-процессов
Многоролевые процессы; обмен документацией; много участников, разделение прав доступа; среднее время жизни объектов
Поддержка биометрии, национального законодательства, различных типов голосования, поддержка ролевых моделей
Большой объем операций чтения/малый объем операций записи, длительное время хранения, возможность доступа к внешним данным
Очень большое количество пользователей, большой объем трансакций, поддержка смарт-контрактов
Большой объем трансакций, возможность доступа
к внешним данным
Смарт-контракты, возможность доступа
к внешним данным
Поддержка ролевых моделей, смарт-контракты
Большой объем трансакций, скорость
Поддержка биометрии, сложная криптография, разделение доступа контрибьюторов информации
Нежелательность хранения полной копии реестра на всех узлах (раскрытие информации о сделках
и контрагентах)
Сложные смарт-контракты, ролевые модели
Большое количество трансакций, высокие требования к скорости
Направление
Кейсы
Примеры фиксируемых фактов
Управление цепочками поставок/Логистика
BHP Billiton, IBM, EverLedger, Trade Connect, Maersk, Walmart
Прибытие товара в пункт назначения; целостность контейнера
и соблюдение условий транспортировки (напр. t) в пути
и т.п.
Голосование
НРД, Nasdaq
(для Эстонии),
штаты Делавер
и Западная Вирджиния, A.D.X.
Отдача голосующим голоса
за решение
или кандидата; участие голосующего
в голосовании
Права собственности
BHP Billiton, Thomas Reuters, Georgia Land Registry, Estonia e-Residence
Переход права собственности
на недвижимость
Smart Grid / интернет энергии
Consensus Systems
(для City
of Brooklyn), Onder
Потребление или генерация определенного объема энергии определенным узлом
Системы лояльности
IBM, Royal Bank
of Canada, UnionPay
Эмиссия
и использование токена
Страхование
Сбербанк, B3i Consortium, EverLedger, Socratus
Заключение договора, поступление средств, наступление страхового случая и др.
Торговое финансирование, факторинг
Сбербанк, АльфаБанк, DigitalTradeChain, HSBC, Barclays, UBS, Bank of America
и многие другие
Обмен финансовыми сообщениями
Сбербанк, ЦБ РФ, SWIFT, VISA
KYC
Сбербанк, АкБарсБанк, Rabobank, FidorBank, Dutchbunq
Биометрическая идентификация, биография
и трудовой путь клиента, источники происхождения
его средств и т.п.
Трейдинг
и клиринг
Goldman Sachs, JP Morgan, HSBC, Deutsche Bundesbank, PTDL Group Barclays, HSBC
Заключение сделок
и исполнение по ним
Управление активами
и токенизация
JPMorgan, IBM
Содержание и бэктест торговой модели, индивидуальные ограничения клиентских счетов, трек-рекорды
и т.п.
Криптовалюты
История сделок
Типы
и особенности бизнес-процессов
Многоролевые процессы; обмен документацией; много участников, разделение прав доступа; среднее время жизни объектов
Поддержка биометрии, национального законодательства, различных типов голосования, поддержка ролевых моделей
Большой объем операций чтения/малый объем операций записи, длительное время хранения, возможность доступа к внешним данным
Очень большое количество пользователей, большой объем трансакций, поддержка смарт-контрактов
Большой объем трансакций, возможность доступа
к внешним данным
Смарт-контракты, возможность доступа
к внешним данным
Поддержка ролевых моделей, смарт-контракты
Большой объем трансакций, скорость
Поддержка биометрии, сложная криптография, разделение доступа контрибьюторов информации
Нежелательность хранения полной копии реестра
на всех узлах (раскрытие информации
о сделках
и контрагентах)
Сложные
смарт-контракты, ролевые модели
Большое количество трансакций, высокие требования
к скорости
Например
Направ-
ление
Кейсы
Примеры фиксируе-
мых
фактов
Управ-
ление цепоч-
ками поставок/Логистика
BHP Billiton, IBM, EverLedger, Trade Connect, Maersk, Walmart
Прибытие
товара в пункт назначения; целостность контейнера
и соблюдение условий транспорти-
ровки
(напр. t)
в пути и т.п.
Голосо-
вание
НРД, Nasdaq
(для Эстонии),
штаты Делавер и
Западная Вирджи-
ния
, A.D.X.
Отдача голосующим голоса
за решение
или
кандидата; участие голосующего
в голосовании
Права собствен-
ности
BHP Billiton, Thomas Reuters, Georgia Land Registry, Estonia
e-Residence
Переход права собственности
на недвижимость
Smart Grid
/ интернет энергии
Consensus Systems
(для City
of Brooklyn), Onder
Потребление или генерация определен-
ного объема энергии определен-
ным узлом
Системы лояльности
IBM, Royal Bank
of Canada, UnionPay
Эмиссия
и использо-
вание
токена
Страхова-
ние
Сбербанк, B3i Consortium, EverLedger, Socratus
Заключение договора, поступление средств, наступление страхового случая и др.
Торговое
финанси-
рование,
факторинг
Сбербанк,
АльфаБанк, DigitalTrade-
Chain, HSBC, Barclays, UBS, Bank
of America
и многие другие
Обмен финансо-
выми сообще-
ниями
Сбербанк, ЦБ РФ, SWIFT, VISA
KYC
Сбербанк, АкБарсБанк, Rabobank, FidorBank, Dutchbunq
Биометри-
ческая идентифи-
кация, биография
и трудовой
путь клиента, источники происхож-
дения
его средств
и т.п.
Трейдинг
и клиринг
Goldman Sachs, JP Morgan, HSBC, Deutsche Bundes-
bank, PTDL Group Barclays, HSBC
Заключение сделок
и исполнение по ним
Управ-
ление активами
и токени-
зация
JPMorgan,
IBM
Содержание
и бэктест торговой модели, индиви-
дуальные ограничения клиентских счетов,
трек-рекорды
и т.п.
Крипто-
валюты
История сделок
Типы
и особенности бизнес-процессов
Многоролевые
процессы; обмен документацией; много участников, разделение прав доступа; среднее время
жизни объектов
Поддержка биометрии, национального
законода-
тельства, различных
типов
голосования,
поддержка ролевых
моделей
Большой объем операций чтения/малый объем операций записи, длительное время хранения, возможность доступа
к внешним данным
Очень большое количество пользователей, большой объем трансакций, поддержка смарт-контрактов
Большой объем трансакций, возможность доступа
к внешним данным
Смарт-
контракты, возможность доступа
к внешним данным
Поддержка ролевых моделей, смарт-контракты
Большой объем трансакций, скорость
Поддержка биометрии, сложная криптография,
разделение доступа контрибью-
торов информации
Нежела-
тельность хранения
полной копии
реестра на всех
узлах (раскрытие информации
о сделках
и контрагентах)
Сложные
смарт-контракты, ролевые модели
Большое количество трансакций, высокие требования
к скорости
Например
Направ-
ление
Кейсы
Примеры фиксируе-
мых
фактов
Управ-
ление цепоч-
ками поставок/Логис-
тика
BHP Billiton, IBM, EverLedger, Trade Connect, Maersk, Walmart
Прибытие
товара
в пункт назначения; целостность контейнера
и соблюде-
ние условий транспорти-
ровки
(напр. t)
в пути и т.п.
Голосо-
вание
НРД, Nasdaq
(для Эстонии),
штаты Делавер
и
Западная Вирджи-
ния
, A.D.X.
Отдача голосую-
щим голоса
за решение
или кандидата; участие голосую-
щего в голосо-
вании
Права собствен-
ности
BHP Billiton, Thomas Reuters, Georgia Land Registry, Estonia e-Residence
Переход права собствен-
ности
на недвижи-
мость
Smart Grid / интернет энергии
Consensus Systems
(для City
of Brooklyn), Onder
Потребле-
ние или генерация определен-
ного
объема энергии определен-
ным узлом
Системы лояль-
ности
IBM, Royal Bank
of Canada, UnionPay
Эмиссия
и использо-
вание
токена
Страхо-
вание
Сбербанк, B3i Con-
sortium, Ever-
Ledger, Socratus
Заклю-
чение договора, поступле-
ние средств, наступ-
ление страхового случая и др.
Торговое
финанси-
рование,
факто-
ринг
Сбербанк,
Альфа-
Банк, Digital-
Trade-
Chain, HSBC, Barclays, UBS, Bank of America
и многие другие
Обмен финансо-
выми сообще-
ниями
Сбербанк, ЦБ РФ, SWIFT, VISA
KYC
Сбербанк, АкБарс-
Банк, Rabobank, FidorBank, Dutchbunq
Биометри-
ческая идентифи-
кация, биография
и трудовой
путь клиента, источники происхож-
дения
его средств и т.п.
Трейдинг
и клиринг
Goldman Sachs, JP Morgan, HSBC, Deutsche Bundes-
bank, PTDL Group Barclays, HSBC
Заключе-
ние сделок
и исполнение по ним
Управле-
ние активами
и токени-
зация
JPMorgan,
IBM
Содержание
и бэктест торговой модели, индиви-
дуальные ограни-
чения клиентских счетов,
трек-рекорды
и т.п.
Крипто-
валюты
История сделок
Типы и особен-
ности бизнес-процессов
Многороле-
вые
процессы; обмен документа-
цией; много участников, разделение прав
доступа; среднее
время
жизни объектов
Поддержка биометрии, националь-
ного
законода-
тельства, различных
типов
голосо-
вания,
поддержка ролевых
моделей
Большой объем операций чтения/малый объем операций записи, длительное время хранения, возмож-
ность доступа к внешним данным
Очень большое количество пользова-
телей, большой объем трансакций, поддержка смарт-контрактов
Большой объем трансакций, возмож-
ность доступа
к внешним данным
Смарт-контракты, возмож-
ность доступа
к внешним данным
Поддержка ролевых моделей, смарт-контракты
Большой объем трансакций, скорость
Поддержка биометрии, сложная криптогра-
фия,
разделение доступа контрибью-
торов инфор-
мации
Нежела-
тельность хранения
полной
копии
реестра
на всех
узлах (раскрытие инфор-
мации
о сделках и контраген-
тах)
Сложные
смарт-контракты, ролевые модели
Большое количество трансакций, высокие требования
к скорости
Например
На-
прав-
ление
Кейсы
Приме-
ры фик-
сируе-
мых
фактов
Управ-
ление цепоч-
ками поста-
вок/Логис-
тика
BHP Billiton, IBM,
Ever-
Ledger, Trade Con-
nect, Maersk, Wal-
mart
Прибы-
тие
товара
в пункт назна-
чения; целост-
ность конте-йнера
и соблю-
дение условий транспор-тировки
(напр. t)
в пути
и т.п.
Голо-
сова-
ние
НРД, Nasdaq
(для Эсто-
нии),
штаты Дела-
вер
и
Запад-ная Вирджи-
ния
, A.D.X.
Отдача голосую-
щим голоса
за решение
или кандида-
та; участие голосую-
щего в голосо-
вании
Права собст-
вен-
ности
BHP Billiton, Thomas Reuters, Georgia Land Registry, Estonia e-Resi-
dence
Переход права собствен-
ности
на недвижи-
мость
Smart Grid / интер-
нет энер-
гии
Consen-
sus Systems
(для City
of Brook-
lyn), Onder
Потреб-
ление или генера-
ция опреде-
ленного
объема энергии опреде-
ленным узлом
Систе-
мы лояль-
ности
IBM, Royal Bank
of Canada, Union-
Pay
Эмиссия
и исполь-
зование
токена
Стра-
хова-
ние
Сбер-
банк, B3i Con-
sortium, Ever-
Ledger, Socra-
tus
Заклю-
чение договора, поступ-
ление средств, наступ-
ление страхо-
вого случая и др.
Торго-
вое
фи-
нанси-
рова-
ние,
факто-
ринг
Сбер-
банк,
Альфа-
Банк, Digital-
Trade-
Chain, HSBC, Barclays, UBS, Bank of America
и многие другие
Обмен фи-
нансо-
выми сооб-
ще-
ниями
Сбер-
банк, ЦБ РФ, SWIFT, VISA
KYC
Сбер-
банк, АкБарс-
Банк, Rabo-
bank, Fidor-
Bank, Dutch-
bunq
Биомет-
рическая иденти-
фикация, биогра-
фия
и трудовой
путь клиента, источни-
ки происхож-
дения
его средств и т.п.
Трей-
динг
и кли-
ринг
Gold-
man Sachs, JP Morgan, HSBC, Deutsc-
he Bundes-
bank, PTDL Group Barclays, HSBC
Заключе-
ние сделок
и испол-
нение по ним
Уп-
равле-
ние акти-
вами
и токе-
низа-
ция
JPMor-
gan,
IBM
Содер-
жание
и бэктест торговой модели, индиви-
дуальные ограни-
чения клиентс-
ких счетов,
трек-рекорды
и т.п.
Крип-
това-люты
История сделок
Типы и особен-
ности бизнес-процес-
сов
Много-
ролевые
процес-
сы; обмен доку-
мента-
цией; много участни-
ков, разделе-
ние прав
доступа; среднее
время
жизни объектов
Под-
держка биомет-
рии, нацио-
нально-
го
законо-
дательст-
ва, различ-
ных
типов
голосо-
вания,
под-
держка ролевых
моделей
Боль-
шой объем опера-
ций чтения/малый объем опера-
ций записи, длитель-
ное время хране-
ния, возмож-
ность доступа к внеш-
ним данным
Очень большое коли-
чество пользо-
вателей, большой объем трансак-
ций, под-
держка смарт-контрак-
тов
Боль-
шой объем тран-
сакций, возмож-
ность доступа
к внешним данным
Смарт-конт-
ракты, возмож-
ность доступа
к внеш-
ним данным
Под-
держка ролевых моделей, смарт-конт-
ракты
Боль-
шой объем тран-
сакций, скорость
Под-
держка биомет-
рии, сложная криптог-
рафия,
разделе-
ние доступа конт-
рибью-
торов инфор-
мации
Нежела-
тель-
ность хране-
ния
полной
копии
реестра
на всех
узлах (раскры-
тие инфор-
мации
о сделках и контра-
гентах)
Слож-
ные
смарт-конт-
ракты, ролевые модели
Боль-
шое коли-
чество тран-
сакций, высокие требо-
вания
к ско-
рости
время жизни и размеры объектов;
Как видите, на определенном уровне абстракции различные кейсы применения реестров отличаются тем, каковы:

.
требуемая скорость операций;
количество обращений на изменение и чтение объектов;
.
.
дополнительный функционал реестров (оракулы
и смарт-контракты различной сложности и т.п.).
.
время жизни и размеры объектов;
Как видите, на определенном уровне абстракции различные кейсы применения реестров отличаются тем, каковы:

.
требуемая скорость операций;
количество обращений на изменение и чтение объектов;
.
.
дополнительный функционал реестров (оракулы
и смарт-контракты различной сложности и т.п.).
.
время жизни и размеры объектов;
Как видите, на определенном уровне абстракции различные кейсы применения реестров отличаются тем, каковы:

.
требуемая скорость операций;
количество обращений
на изменение и чтение объектов;
.
.
дополнительный функционал реестров (оракулы и смарт-контракты различной сложности
и т.п.).
.
время жизни и размеры объектов;
Как видите, на определенном уровне абстракции различные кейсы применения реестров отличаются тем, каковы:

.
требуемая скорость
операций;
количество обращений
на изменение и чтение объектов;
.
.
дополнительный функционал реестров (оракулы и смарт-контракты
различной сложности и т.п.).
.
время жизни и размеры объектов;
Как видите, на определенном уровне абстракции различные кейсы применения реестров отличаются тем, каковы:

.
требуемая скорость
операций;
количество обращений
на изменение и чтение объектов;
.
.
дополнительный функционал реестров (оракулы
и смарт-контракты
различной сложности и т.п.).
.
Опираясь на описанные выше кейсы, мы можем выделить два аспекта, интересующие того, кто задумывается о решении своей задачи с помощью распределенного реестра: потенциал масштабирования (то есть насколько большой может быть конкретная реализация данного распределенного реестра) и функциональные возможности (что умеет делать данный распределенный реестр).
Что важно пользователю распределенного реестра?
Потенциал масштабирования фиксируется в максимальном количестве операций в секунду, максимальном количестве узлов с различными ролями, максимальной задержке на передачу данных между узлами, максимальной задержке на окончательное удостоверение данных в реестре, максимальном физическом расстоянии между узлами и устойчивости реестра
к неоднородности соединений между узлами.
Функциональные возможности реестров могут включать в себя поддержку оракулов и смарт-контрактов, возможность подключения новых узлов
«на лету», возможность хранения объектов большого размера, поддержку различных ролей у узлов.

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

Существует ли хорошее теоретическое основание этой догадки?