Подтверждение резервов

Аудит

Узнайте о процессе аудита в Kraken

Процесс Аудита резервов в Kraken  

Введение

Этот документ содержит информацию и рекомендации относительно процесса аудита в Kraken.

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

За последние несколько недель Kraken успешно разработал и провел ведущий в отрасли независимый криптографически проверенный аудит. Мы с гордостью представляем этот обзор нашего процесса глобальному сообществу цифровых валют. Мы считаем, что Bitcoin-индустрия способна обеспечить уровень уверенности и подотчетности, который превосходит традиционную индустрию финансовых услуг, и мы стремимся вести процесс к оптимальной прозрачности.

Текущий вид

Стимулом для этой инициативы является предложение Грега Максвелла об обменниках/кошельках, для доказательств Bitcoin-резервов. [1]

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

Качество процесса

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

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

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

Обзор процесса

  • Этап 1 - Аудитор проверяет средства всего кошелька Kraken

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

    Код, необходимый для этого этапа, был написан Майклом Гронагером, операционным директором Payward, и в будущем код может быть полностью в открытом доступе. Однако, большая часть кода уже в открытом доступе, так как код основан на libcoin. [2]

  • Этап 2 - Аудитор проверяет, совпадают ли балансы пользователей Kraken со средствами на кошельке Kraken

    Kraken предоставляет аудитору балансы BTC каждого из наших пользователей и генерирует дерево Меркле. Аудитор опубликует хэш корневого узла, чтобы все могли видеть, и подтвердит, если это правда, что общее количество активов, представленное корневым хешем, максимально равно величине нашего кошелька на блокчейне. Этот этап также гарантирует, что Kraken ничего не скрывает ни в одном из узлов, ведущих к корневому узлу.

    На этом этапе аудита, аудитор будет иметь доступ к исходному коду программы, генерирующей дерево, и к файлу с данными по сальдо отдельных счетов. Kraken выпустил код C ++ для этого этапа под лицензией MIT: https://github.com/payward/krakendb

  • Этап 3 - Пользователи самостоятельно проверяют, что остатки их счетов были включены в данные, используемые аудитором

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

    Это позволит пользователям самостоятельно проверить, включена ли их учетная запись в данные, проверенные аудитором.

Недостатки

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

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

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

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

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

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

Аудитор может вступать в сговор или поддаваться угрозам со стороны проверяемого.

Постоянная основа

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

Будущие изменения и улучшения

Мы надеемся получить обратную связь от сообщества, которая поможет нам и другим улучшить этот процесс для будущих проверок. Будучи членами этого сообщества, мы также надеемся работать с такими отраслевыми организациями, как DATA (www.datauthority.org) чтобы помочь в разработке основных стандартов, масштабируемых инструментов и всестороннего руководства для других в отрасли для проведения подобных аудитов.

Рекомендации

[1] Краткое содержение Зака Уилкокса: https://iwilcox.me.uk/2014/proving-bitcoin-reserves. Мы хотим поблагодарить Грега Максвелла за его идеи.

[2] libcoin - это преобразование биткойнов в модульные, многоразовые библиотеки: https://github.com/libcoin/libcoin

Как проверить баланс Вашего Kraken аккаунта в отчете об аудите Kraken

Также ознакомьтесь: Процесс аудита резервов Kraken.

В этих инструкциях объясняется, как выполнить криптографическую проверку баланса Вашего аккаунта Kraken и включение его в аудит.

Эта проверка будет отражать Ваш баланс Bitcoin (XBT) на момент аудита.

 

  • Шаг 1

    Войдите в свой аккаунт Kraken.

    Перейдите на https://www.kraken.com/ и убедитесь, что адресная строка Вашего браузера показывает "https://www.kraken.com/"

  • Шаг 2

    Перейдите в раздел "Переводы" -> "Аудит" подраздел -> "Bitcoin (XBT)"на панели слева.

    Рисунок 1. Bitcoin Страница аудита Kraken

  • Шаг 3

    Ознакомьтесь с информацией о Вашем аккаунте, подтвержденной аудитором

    •  Время аудита, которое является меткой времени, используемой аудитором.

    •  Код подачи, представляющий собой 64-битную систему.

    •  Количество Bitcoin, находящихся на Вашем счете на момент проведения аудита. Это информация, которую мы предоставляем аудитору.

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

    •  Хэши . Обозначения хеш-функции в Вашем прямом пути показаны звездочкой (*), чтобы отличить их от хэша соседнего узла. С помощью этих хэшей Вы можете проверить, что Ваш узел включен в корень:

    • Самая первая строка должна соответствовать значению корневого хеша, заданному аудитором.

      Чтобы проверить свой собственный хэш узла (самый последний хэш с * в списке), надо:

      sha256(sha256(<submission code> || ":" || <сумма с удаленной десятичной точкой и последующими 0>))

      Это значение должно соответствовать самому последнему значению, указанному в хешах.

      Пример

      Код подачи: 379377cd8190f9bf

      Количество: 0.01500000

      Python

      import hashlib; print(hashlib.sha256(hashlib.sha256(b'379377cd8190f9bf:1500000').digest()).hexdigest());
      

      PHP

      echo hash('sha256', hash('sha256', '379377cd8190f9bf:1500000', true));
      

      Результат

      66b51ba0f4a5cf8278acac6782ffdfb9a64b9f7c895bc308266b0757c7025b27
      

      Вы можете полностью проверить свои ветви Merkle, выполнив хэш каждой пары хешей (или «кортеж»). Формат:

      sha256(left-hash || right-hash)
      

      Результат должен соответствовать предыдущему хешу кортежа (или корневому хешу) с * в нем. Это будет сделано для всех кортежей.

      За исключением корневого хеша, все хеши даны в виде кортежей, представляющих левый и правый хэш в этом порядке. * Дается хешам, которые представляют Ваши прямые узлы.

      Пример:

      Хэши:

      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3* c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b* 5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c
      

      Python

      import hashlib; print(hashlib.sha256(b'c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'.decode('hex'))).hexdigest();
      

      PHP

      echo hash('sha256', hex2bin('c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'));
      

      Результат

      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3