Разработка и тестирование блокчейн систем для горизонтально-интегрированных структур
|
Введение 4
Постановка задачи 8
Обзор литературы 10
Глава 1. Горизонтально-интегрированные структуры 16
1.1. Централизованная система 16
1.2. Федеративная система 17
1.3. Распределенная система 17
Глава 2. Модели представления балансов 20
2.1. UTXO-модель 20
2.2. Модель аккаунтов 22
2.3. Сравнивая модели 23
Глава 3. Приватность и конфиденциальность 25
3.1. Пользовательская приватность 25
3.2. Конфиденциальность транзакций 27
Глава 4. Дифференциальная приватность 30
4.1. Архитектурные решения 31
4.1.1 Центральная модель 31
4.1.2 Локальная модель 32
4.1.3 Гибридная модель 34
4.2. Ключевые протоколы 35
4.2.1 Механизм Лапласа 35
4.2.2 Экспоненциальный механизм 38
Глава 5. Безопасность для вертикально-интегрированных структур 39
Глава 6. Эксперимент 44
6.1. Организация сети 44
6.2. Приватный протокол 46
6.3. Измерения 47
Глава 7. Выводы 50
Глава 8. Заключение 51
Список литературы 52
Постановка задачи 8
Обзор литературы 10
Глава 1. Горизонтально-интегрированные структуры 16
1.1. Централизованная система 16
1.2. Федеративная система 17
1.3. Распределенная система 17
Глава 2. Модели представления балансов 20
2.1. UTXO-модель 20
2.2. Модель аккаунтов 22
2.3. Сравнивая модели 23
Глава 3. Приватность и конфиденциальность 25
3.1. Пользовательская приватность 25
3.2. Конфиденциальность транзакций 27
Глава 4. Дифференциальная приватность 30
4.1. Архитектурные решения 31
4.1.1 Центральная модель 31
4.1.2 Локальная модель 32
4.1.3 Гибридная модель 34
4.2. Ключевые протоколы 35
4.2.1 Механизм Лапласа 35
4.2.2 Экспоненциальный механизм 38
Глава 5. Безопасность для вертикально-интегрированных структур 39
Глава 6. Эксперимент 44
6.1. Организация сети 44
6.2. Приватный протокол 46
6.3. Измерения 47
Глава 7. Выводы 50
Глава 8. Заключение 51
Список литературы 52
В последние годы тенденции цифровой трансформации очевидны. Повышение конкурентности, увеличение доли “цифровой” составляющей в бизнес-процессах способствуют усилению горизонтальной интеграции участников различных сегментов рынка с целью повышения эффективности и результативности межорганизационных процессов. Более тесное сотрудничество предоставляет новые возможности и взаимную выгоду для вовлеченных сторон, а также может улучшить их операционные и бизнес- показатели. В данном случае, вопросы прозрачности, конфиденциальности и приватности данных, которые возникают при внедрении горизонтальной интеграции, заслуживают отдельного внимания. Экосистемы должны быть подготовлены для совместного использования общих данных среди бизнес- партнеров или участников горизонтально-интегрированной структуры. А именно, возникает необходимость решить проблему совместимости систем, то есть их способность обмениваться информацией.
Взрывной рост генерируемых данных, тот объем, с которым приходится работать при современных задачах, снижает эффективность традиционных баз данных. Централизованные решения уже кажутся не столь рациональными; в такой ситуации стоит акцентировать свое внимание и отдать предпочтение DLT (Distributed Ledger Technology). Последнее имеет ряд преимуществ:
• во-первых, безопасность. Отсутствует централизация данных, за контроль и валидацию данных отвечают непосредственно участники сети;
• во-вторых, эффективность. Одноранговый обмен данными делает систему быстрой и высокоэффективной;
• в-третьих, функциональность. Технология распределенного реестра очень универсальна и находит применение во многих секторах. Различные отрасли, от здравоохранения до финансов, используют блок- чейн для дальнейшего продвижения на рынке [1].
Вопрос доверия в децентрализованных системах, в частности в распределенных реестрах, стоит крайне остро. Депозиты заменяют другие проявления доверия. Вместо явного ранжирования (например, количество звезд отдельного пользователя на GitHub, Amazon или величина кармы на Habr), агенты будут доверять друг другу только в том случае, если будет предоставлено достаточное количество активов для подтверждения операции. Ключевая идея состоит в том, что, если контрагент совершает нежелательные действия, система может наказать обманывающую сторону и возместить причиненный ущерб агенту, пострадавшему от этих действий.
Возникает вполне закономерный вопрос: все ли проблемы решены для блокчейн систем? Не совсем. Определить, какой депозит требуется агенту - непростой вопрос. Чем больший депозит должен предоставить агент, тем большую безопасность имеет протокол, так как это увеличивает потенциальное наказание в случае нежелательных действий. Однако появляется потенциальная проблема: чем больше требуется депозит, тем меньше множество агентов, у которых достаточно активов, чтобы претендовать на участие. Более того, в большинстве протоколов необходимо учитывать два основных источника неопределенности.
Во-первых, относительная величина депозита по отношению к риску может меняться с течением времени, то есть напрямую зависит от события. Например, для криптовалюты Dai [2] требуется обеспечение в долларовом эквиваленте не ниже 150% получаемой суммы Dai для учета внезапных скачков цены базового эфира по отношению к цене в долларах США. А это значит, чтобы получить 100 Dai, агенту придется заложить криптоактив, эквивалентный 150 долларам США.
Во-вторых, необходимо учитывать личную информацию. Например, агент может иметь неизвестные скрытые мотивы или какие-то внешние стимулы, например, подкуп.
Для отслеживания зависимостей от событий или личной информации отдельного агента требуется чрезмерное обеспечение протоколами. Проще говоря, если риск зависит от одного из описанных выше источников, разработчик протокола зачастую умножает значение риска на коэффициент F, который учитывает оба источника неопределенности. Это относится к большинству протоколов DeFi (децентрализованные финансовые сервисы), таких, как Dai или Compound [3]. В других протоколах, например TrueBit или PoS, риск не совсем ясен. В этих случаях нужно произвести оценку необходимого депозита. В любом случае, существует внутренняя дилемма между агентами, предоставляющими услуги (они же обязаны вносить депозит), и агентами, получающими услуги.
Децентрализованные платформы на основе блокчейн технологий в ближайшем будущем будут стремиться решить проблему доверия, в том числе путем добавления прозрачности. Самым ярким примером такой платформы является Ethereum, который предоставляет возможность разработки децентрализованных приложений (DApps) с помощью высокоуровневого объектно-ориентированного языка программирования Solidity. К сожалению, в рамках данной системы нет простого способа добавить значимый уровень приватности и конфиденциальности разрабатываемым приложениям. Рассмотрим классический пример - закрытый аукцион. Без каких- либо затруднений мы можем программно реализовать механизм открытых аукционов, но все ли так просто в случае с закрытыми аукционами? Логика, которая лежит в основе закрытых аукционов - отсутствие знаний у любого участника торгов о ставках других участников. Обычно процесс происходит в несколько этапов: сбор запечатанных предложений, вскрытие собранных предложений и определение победителя путем сравнения предложений. И здесь сразу возникает вопрос: как реализовать подобный механизм в блокчейн системе, где значения транзакций являются общедоступными?
Существует несколько способов решения данной проблемы. Во-первых, можно отправлять несколько заявок, часть которых является фиктивной. Во-вторых, служба имен Ethereum (ENS) предлагает пользователям отправлять только хеш своих ставок для регистрации имени у регистратора и вносить больше эфира, чем истинное значение ставки. Однако, ни один из приведенных выше механизмов не обеспечивает необходимый уровень приватности и конфиденциальности, и при этом ложится дополнительной нагрузкой на пользователя. В-третьих, можно прибегнуть к использованию криптографических решений для запуска произвольных смарт-контрактов с сохранением конфиденциальности, которые, к сожалению, не полностью децентрализованы или слишком дороги для простых контрактов [4, 5].
В действительности, стремление к конфиденциальности не ограничивается аукционами. Если бы существовал механизм конфиденциальной отправки внутренней валюты в той же системе Ethereum, возможно, разработчики могли бы использовать его, чтобы добиться необходимого уровня конфиденциальности в своих приложениях. К сожалению, почти все известные подходы для обеспечения конфиденциальности транзакций [6, 7, 8] относятся к UTXO-модели представления балансов, где входами для новой транзакции являются неизрасходованные выходы предыдущих транзакций. Модель UTXO плохо подходит для приложений, которым необходимо поддерживать какое-то внутреннее состояние, о чем говорит [9] Виталик Бутерин, основатель Ethereum. Поэтому платформы смарт-контрактов работают, используя модель на основе учетных записей. Подробнее о моделях представления балансов говорится в разделе “Модели представления балансов”.
Вышеописанные проблемы, которые свойственны горизонтально-интегрированным структурам, характерны и для вертикально-интегрированных структур, которым также уделено внимание в рамках данной работы. Прежде чем перейти к обзору существующих практик, сформулируем цель и задачи работы.
Взрывной рост генерируемых данных, тот объем, с которым приходится работать при современных задачах, снижает эффективность традиционных баз данных. Централизованные решения уже кажутся не столь рациональными; в такой ситуации стоит акцентировать свое внимание и отдать предпочтение DLT (Distributed Ledger Technology). Последнее имеет ряд преимуществ:
• во-первых, безопасность. Отсутствует централизация данных, за контроль и валидацию данных отвечают непосредственно участники сети;
• во-вторых, эффективность. Одноранговый обмен данными делает систему быстрой и высокоэффективной;
• в-третьих, функциональность. Технология распределенного реестра очень универсальна и находит применение во многих секторах. Различные отрасли, от здравоохранения до финансов, используют блок- чейн для дальнейшего продвижения на рынке [1].
Вопрос доверия в децентрализованных системах, в частности в распределенных реестрах, стоит крайне остро. Депозиты заменяют другие проявления доверия. Вместо явного ранжирования (например, количество звезд отдельного пользователя на GitHub, Amazon или величина кармы на Habr), агенты будут доверять друг другу только в том случае, если будет предоставлено достаточное количество активов для подтверждения операции. Ключевая идея состоит в том, что, если контрагент совершает нежелательные действия, система может наказать обманывающую сторону и возместить причиненный ущерб агенту, пострадавшему от этих действий.
Возникает вполне закономерный вопрос: все ли проблемы решены для блокчейн систем? Не совсем. Определить, какой депозит требуется агенту - непростой вопрос. Чем больший депозит должен предоставить агент, тем большую безопасность имеет протокол, так как это увеличивает потенциальное наказание в случае нежелательных действий. Однако появляется потенциальная проблема: чем больше требуется депозит, тем меньше множество агентов, у которых достаточно активов, чтобы претендовать на участие. Более того, в большинстве протоколов необходимо учитывать два основных источника неопределенности.
Во-первых, относительная величина депозита по отношению к риску может меняться с течением времени, то есть напрямую зависит от события. Например, для криптовалюты Dai [2] требуется обеспечение в долларовом эквиваленте не ниже 150% получаемой суммы Dai для учета внезапных скачков цены базового эфира по отношению к цене в долларах США. А это значит, чтобы получить 100 Dai, агенту придется заложить криптоактив, эквивалентный 150 долларам США.
Во-вторых, необходимо учитывать личную информацию. Например, агент может иметь неизвестные скрытые мотивы или какие-то внешние стимулы, например, подкуп.
Для отслеживания зависимостей от событий или личной информации отдельного агента требуется чрезмерное обеспечение протоколами. Проще говоря, если риск зависит от одного из описанных выше источников, разработчик протокола зачастую умножает значение риска на коэффициент F, который учитывает оба источника неопределенности. Это относится к большинству протоколов DeFi (децентрализованные финансовые сервисы), таких, как Dai или Compound [3]. В других протоколах, например TrueBit или PoS, риск не совсем ясен. В этих случаях нужно произвести оценку необходимого депозита. В любом случае, существует внутренняя дилемма между агентами, предоставляющими услуги (они же обязаны вносить депозит), и агентами, получающими услуги.
Децентрализованные платформы на основе блокчейн технологий в ближайшем будущем будут стремиться решить проблему доверия, в том числе путем добавления прозрачности. Самым ярким примером такой платформы является Ethereum, который предоставляет возможность разработки децентрализованных приложений (DApps) с помощью высокоуровневого объектно-ориентированного языка программирования Solidity. К сожалению, в рамках данной системы нет простого способа добавить значимый уровень приватности и конфиденциальности разрабатываемым приложениям. Рассмотрим классический пример - закрытый аукцион. Без каких- либо затруднений мы можем программно реализовать механизм открытых аукционов, но все ли так просто в случае с закрытыми аукционами? Логика, которая лежит в основе закрытых аукционов - отсутствие знаний у любого участника торгов о ставках других участников. Обычно процесс происходит в несколько этапов: сбор запечатанных предложений, вскрытие собранных предложений и определение победителя путем сравнения предложений. И здесь сразу возникает вопрос: как реализовать подобный механизм в блокчейн системе, где значения транзакций являются общедоступными?
Существует несколько способов решения данной проблемы. Во-первых, можно отправлять несколько заявок, часть которых является фиктивной. Во-вторых, служба имен Ethereum (ENS) предлагает пользователям отправлять только хеш своих ставок для регистрации имени у регистратора и вносить больше эфира, чем истинное значение ставки. Однако, ни один из приведенных выше механизмов не обеспечивает необходимый уровень приватности и конфиденциальности, и при этом ложится дополнительной нагрузкой на пользователя. В-третьих, можно прибегнуть к использованию криптографических решений для запуска произвольных смарт-контрактов с сохранением конфиденциальности, которые, к сожалению, не полностью децентрализованы или слишком дороги для простых контрактов [4, 5].
В действительности, стремление к конфиденциальности не ограничивается аукционами. Если бы существовал механизм конфиденциальной отправки внутренней валюты в той же системе Ethereum, возможно, разработчики могли бы использовать его, чтобы добиться необходимого уровня конфиденциальности в своих приложениях. К сожалению, почти все известные подходы для обеспечения конфиденциальности транзакций [6, 7, 8] относятся к UTXO-модели представления балансов, где входами для новой транзакции являются неизрасходованные выходы предыдущих транзакций. Модель UTXO плохо подходит для приложений, которым необходимо поддерживать какое-то внутреннее состояние, о чем говорит [9] Виталик Бутерин, основатель Ethereum. Поэтому платформы смарт-контрактов работают, используя модель на основе учетных записей. Подробнее о моделях представления балансов говорится в разделе “Модели представления балансов”.
Вышеописанные проблемы, которые свойственны горизонтально-интегрированным структурам, характерны и для вертикально-интегрированных структур, которым также уделено внимание в рамках данной работы. Прежде чем перейти к обзору существующих практик, сформулируем цель и задачи работы.
Современные блокчейн системы обещают и стремятся повысить прозрачность распределенных приложений для решения проблемы доверия. В настоящее время прозрачность зачастую достигается за счет значительного снижения уровня конфиденциальности. Результаты, полученные в процессе выполнения выпускной квалификационной работы показывают, что блокчейн системы могут добиться требуемого уровня конфиденциальности и приватности, не теряя при этом функциональности; предложенное решение ограничено лишь накладными расходами.
В ходе практической реализации системы была организована частная приватная сеть узлов, каждый из которых является участником сети Ethereum и имеет открытый API для взаимодействия извне. Для организованной сети Ethereum был представлен приватный и конфиденциальный протокол, который может быть использован в реальной сети в том числе. Было проведено тестирование и произведены измерения.
В результате работы были достигнуты поставленные цели и задачи. В полной мере изложены ключевые и актуальные практики для достижения приватности, конфиденциальности и дифференциальной приватности системы. В рамках работы была предложена гибридная модель системы, которая соответствует описанным выше характеристикам. Программно реализован [34] приватный протокол для частной сети Ethereum, соответствующие измерения представлены.
В ходе практической реализации системы была организована частная приватная сеть узлов, каждый из которых является участником сети Ethereum и имеет открытый API для взаимодействия извне. Для организованной сети Ethereum был представлен приватный и конфиденциальный протокол, который может быть использован в реальной сети в том числе. Было проведено тестирование и произведены измерения.
В результате работы были достигнуты поставленные цели и задачи. В полной мере изложены ключевые и актуальные практики для достижения приватности, конфиденциальности и дифференциальной приватности системы. В рамках работы была предложена гибридная модель системы, которая соответствует описанным выше характеристикам. Программно реализован [34] приватный протокол для частной сети Ethereum, соответствующие измерения представлены.
