Ценность реплицированных, общих реестров от First Principles

«Цифровые валюты»T нужны, чтобы объяснить, почему распределенные реестры важны. В этой статье Ричард Джендал Браун из IBM развивает аргумент в пользу реплицированных общих реестров с первых принципов.

Это «образовательная статья», предназначенная для тех, особенно в Финансы отрасли, кто предпочитает, чтобы объяснения новых технологий основывались на описании реальной бизнес-проблемы, а не начинались с описания предполагаемого решения.

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

Начнем с банковских систем.

Начните с размышлений осегодняшниеБанковские системы. В дальнейшем я буду использовать пример банковского депозита и платежей. Но та же логика применима везде, куда бы вы ни посмотрели, о чем я буду говорить позже.

Давайте представим себе мир с тремя банками:Банк А,Банк Б и Банк Си два клиента,Клиент А и Клиент Б. Каждый банк использует собственные ИТ-системы, которые они используют для KEEP балансов. Это мир, очень похожий на сегодняшний.

Так Банк АСистемы регистрируют остатки на счетахБанк Аклиенты,Банк БСистемы регистрируют остатки на счетахБанк Бклиенты и т. д.

Возможно, картина LOOKS примерно так:

Сразу бросаются в глаза два наблюдения:

• Сначала посмотрите наБанки А и Б.Банк Асистемы фиксируют, что ему задолжал 1 млн фунтов стерлинговБанк Б. И Банк Бсистемытакже зафиксировать этот факт: они зафиксировали, чтоБанк Б должен1 млн фунтов стерлинговБанк А. Таким образом, одна и та же информация записывается дважды, двумя независимо разработанными, поддерживаемыми и эксплуатируемыми системами. А в других областях это дублирование гораздо больше и дороже, как мы обсудим ниже.
• Во-вторых, посмотрите наКлиент А. Им должны деньгиБанки А и Си имеют овердрафт наБанк Б. Другими словами,Банки А и Сдолжен денегКлиент А. Кто фиксирует этот факт?Банки А и С! Мы принимаем эту ситуацию как должное, но кажется очень странным, чтоКлиент Адолжен доверятьобачто банк будет хорош для денеги что записи банка будут точными. Это похоже на конфликт интересов, если ONE когда-либо был…

Итак, мы имеем два интересных явления: вкладчики должны доверять своим банкам, чтобы они хорошо относились к деньгам.ичтобы правильно все учесть. А сами банки должны тратить много времени и денег на разработку систем, которые все делают примерно одно и то же – а затем тратить еще больше времени и денег на сверку сдруг другачтобы убедиться, что их системы согласуются с общими фактами.

Даже в нашем простом примере потенциально необходимо проверить семь отдельных совпадающих записей.

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

Это не только банковские депозиты. Рынки ценных бумаг и деривативов имеют ту же модель

Эта история о банковских депозитах. Ноточно такой жеможно рассказать историю о системах ценных бумаг и системах деривативов.

На самом деле, в последнем случае проблема может быть еще хуже: нам не только нужно быть уверенными, что все согласны с тем, кто и с кем заключил какие сделки, нам также нужно быть уверенными, что их системы согласны с возникающими в результате обязательствами — они также должны договориться обизнес-логика.

Подумайте о том, сколько почти идентичных систем существует в финансовом ландшафте, каждая из ONE работает немного по-своему и выдает совсем немного отличающиеся результаты, которые необходимо исследовать и решать. Это очень дорого.

Вернуться к банковской истории

Но давайте сейчас сосредоточимся на примере банковской сферы.

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

Пять отдельных регистров слева могут быть записаны, совершенно эквивалентно, как одна таблица справа – и наоборот. Вы можете вывести ONE из другого. Единственное отличие в том, что таблица справа имеет дополнительный столбец, поэтому мы можем записать как эмитента, так и держателя требования.

Другими словами, вместо того, чтобы иметь частичное представление о мире, имеющееся в распоряжении каждого банка, мы могли бы иметь единую таблицу, которая записываетвсе и достичь того же результата.

Так почему бы просто не создать единый банковский реестр для всего мира?

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

В конце концов, как мы показали выше, любой банк, который захочет, может легко вывести свою собственную картину мира из этой мегатаблицы, совершенно тривиально.

Конечно, нам придется подумать о том, как организовать доступ к реестру — кому разрешено просматривать и обновлять какие записи — но мы знаем, как это сделать... и это не неразрешимая проблема.

Вы с ума сошли?

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

Возможно, дорогостоящая, подверженная ошибкам, но принципиально децентрализованная и надежная (нехрупкая?) система, которую мы имеем сегодня, — это та цена, которую стоит заплатить.

Но возникает интересный вопрос: что, если существует способ воспользоваться преимуществами глобальной общей системы, не сталкиваясь при этом со сложным политическим вопросом о том, как контролировать всемогущего оператора или как справиться с риском отключения столь важной центральной части инфраструктуры?

Возможно, мы сможем этого добиться…

Дублированный, общий реестр

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

Но беспокойство в разделе выше было в том, что общий глобальный реестр будет контролироваться одним могущественным субъектом и что эта централизованная система может быть системным риском. Так можем ли мы сделать две корректировки модели?

• Первый, почему бы не повторить книгу учетамассово. Так что вместо ONE копии, сделайте много копий. Возможно, по ONE копии в каждом банке. Так что теперь T ни одной точки отказа. Нам пришлось бы беспокоиться о как Конечно, эти копии синхронизируются, так что это T однозначная «WIN», но наличие копий в каждом банке также может несколько облегчить интеграцию с существующей инфраструктурой. Возможно, это также поможет облегчить принятие.
• Во-вторых, почему бы не сделать так, чтобы те, кто участвует в системе — может быть, только банки или, может быть, их клиенты тоже — также совместно отвечали за ее поддержание и безопасность. В конце концов, мы знаем, кто все остальные в этом мире, поэтому мы знаем, кого наказывать, если они обманывают. Поэтому мы заменяем единую мощную организацию моделью, в которой всеспособствует безопасности системы.

Если так, то, возможно, картина будет выглядеть так:

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

Картинка выше внешне LOOKS на ту , что я нарисовал в начале статьи. Но есть одно принципиально важное отличие. В этотмодель, все участники имеют копию книги учета, но имеют право вносить изменения только в записи, имеющие отношение к ним. Так что это иреплицированный и поделился.

Вот почему я называю эту концепцию «реплицированный, общий реестр. Я думаю, что эта формулировка лучше вызывает правильную ментальную модель, чем, например, «распределенный реестр».

И в зависимости от того, хотите ли вы моделировать балансы, другие активы или дажесоглашениямежду сторонами есть стартапы, работающие над проектом. В прошлом году я написал статью, чтопопытался разобраться в различных игроках, которые там есть– и с тех пор появилось еще много других.

«Умные контракты»

Стоит обратить особое внимание на идею добавлениябизнес-логика к этой концепции: чтобы регистрируемые «факты» касались T только того, кто чем владеет, но и фактических соглашений между сторонами.

Это открывает интригующую возможность «умных контрактов»: мира, в котором контрагенты по деривативам соглашаются, что общая частькодпредставляет собой соглашение, которое они заключили друг с другом, и которое они реализуют в общем реплицированном реестре — возможно, полностью устраняя необходимость в создании, обслуживании, эксплуатации и согласовании своих собственных фирменных деривативных платформ?

Может быть, даже разрешить коду взять на себя управление активами в бухгалтерской книге, чтобы автоматически управлять денежными потоками и маржой?

Нерешенные вопросы

Я должен подчеркнуть, что этот подход поднимает множество технических вопросов: это не однозначно хорошая идея.

Например, знаем ли мы, что базовая Технологии репликации работает так, как описано? При всех вероятных сценариях угроз? Как мы можем быть уверены, что ONE банк (или клиент) T сможет увидеть (или изменить) информацию другого? Сколько данных будет хранить такая система? Будет ли она масштабироваться?Действительнохорошая ли идея моделировать юридические соглашения в коде, а не на английском языке?

Заключение

По-видимому, существуют многочисленные примеры дорогостоящего дублирования систем в различных областях банковской системы.

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

Примечание автора: Во избежание сомнений, в приведенной выше статье я былнет говоря о Bitcoin – этот пост о сфере, которую я иногда называю «не-Биткоин-подобным-миром», как определено в этом посте.

Этот пост изначально появился наБлог Ричарда. Он был переиздан здесь с разрешения.

Изображение книги учетачерез Shutterstock