Хочешь доказать, что ты чист, но не хочешь раскрывать список клиентов? Решение есть
Самое неудобное для институционального игрока, выходящего на рынок, — доказать свою добросовестность, не передавая список клиентов. Сейчас для этого есть два основных подхода. Первый — передать адреса и историю транзакций аналитической компании, которая работает с блокчейном, чтобы та выставила оценку. По сути, ты раскрываешь все карты третьей стороне. Второй — создать список разрешённых адресов на основе дерева Меркла. Так можно доказать, что конкретный адрес входит в набор, но нельзя доказать, что сам набор чистый. На приватном пути обработки данных SXT я попробовал третий вариант: поместил внутренний список и публичный перечень ограниченных адресов в одну систему таблиц, чтобы запрос возвращал логическое значение и доказательство. Внешним сторонам раскрывается только итог, ни одна отдельная запись не показывается. Возможности такого подхода гораздо шире, чем многие думают: так можно подтверждать резервы, проверять наличие в санкционных списках и даже доказывать, что размер активов клиента превышает определённый порог. Во всех случаях результат — только ответ «да» или «нет». Настоящая техническая сложность — актуальность данных: списки меняются каждый день, и доказательства нужно пересоздавать, иначе ты подтверждаешь, что всё было чисто на прошлой неделе. Я однажды на этом обжёгся: проверил новый список старым доказательством, а смарт-контракт сообщил, что всё в порядке. У меня тогда мороз пробежал по спине. После этого я научился включать в доказательство хеш версии данных: если версия не совпадает, запрос сразу отклоняется. Проблема не в криптографии, а в самом списке. Кто его ведёт, как часто обновляет и можно ли проверить историю изменений — всё это операционные вопросы. Если в списке полно ошибок, вся затея бесполезна. Кроме того, законность криптографических доказательств пока остаётся серой зоной: специалистам по комплаенсу всё ещё привычнее видеть отчёт с печатью. По сравнению с доказательством резервов Chainlink этот подход гибче: он позволяет выполнять произвольные SQL-запросы, а не только суммировать балансы. Но за это приходится платить инженерными затратами на создание доказательств, которые ложатся на тебя. Думаю, первыми этот путь освоят проекты RWA и кастодиальные организации, потому что им особенно нужен способ подтвердить всё самостоятельно, ничего не раскрывая. Если же развивать решение всерьёз, придётся сочетать доказательства диапазона и агрегированные доказательства — например, одновременно подтверждать, что общая сумма обязательств ниже лимита, а по каждому отдельному контрагенту превышения лимита нет. Готовых инструментов для этого пока нет, всё придётся собирать самим. Когда этот механизм заработает как надо, изменится и то, как учреждения продают свои услуги: вместо «у нас очень строгий риск-менеджмент» они смогут сказать: «Вы сами можете это проверить». #sxt $SXT @SpaceandTime
Самое неудобное для институционального игрока, выходящего на рынок, — доказать свою добросовестность, не передавая список клиентов. Сейчас для этого есть два основных подхода. Первый — передать адреса и историю транзакций аналитической компании, которая работает с блокчейном, чтобы та выставила оценку. По сути, ты раскрываешь все карты третьей стороне. Второй — создать список разрешённых адресов на основе дерева Меркла. Так можно доказать, что конкретный адрес входит в набор, но нельзя доказать, что сам набор чистый. На приватном пути обработки данных SXT я попробовал третий вариант: поместил внутренний список и публичный перечень ограниченных адресов в одну систему таблиц, чтобы запрос возвращал логическое значение и доказательство. Внешним сторонам раскрывается только итог, ни одна отдельная запись не показывается. Возможности такого подхода гораздо шире, чем многие думают: так можно подтверждать резервы, проверять наличие в санкционных списках и даже доказывать, что размер активов клиента превышает определённый порог. Во всех случаях результат — только ответ «да» или «нет». Настоящая техническая сложность — актуальность данных: списки меняются каждый день, и доказательства нужно пересоздавать, иначе ты подтверждаешь, что всё было чисто на прошлой неделе. Я однажды на этом обжёгся: проверил новый список старым доказательством, а смарт-контракт сообщил, что всё в порядке. У меня тогда мороз пробежал по спине. После этого я научился включать в доказательство хеш версии данных: если версия не совпадает, запрос сразу отклоняется. Проблема не в криптографии, а в самом списке. Кто его ведёт, как часто обновляет и можно ли проверить историю изменений — всё это операционные вопросы. Если в списке полно ошибок, вся затея бесполезна. Кроме того, законность криптографических доказательств пока остаётся серой зоной: специалистам по комплаенсу всё ещё привычнее видеть отчёт с печатью. По сравнению с доказательством резервов Chainlink этот подход гибче: он позволяет выполнять произвольные SQL-запросы, а не только суммировать балансы. Но за это приходится платить инженерными затратами на создание доказательств, которые ложатся на тебя. Думаю, первыми этот путь освоят проекты RWA и кастодиальные организации, потому что им особенно нужен способ подтвердить всё самостоятельно, ничего не раскрывая. Если же развивать решение всерьёз, придётся сочетать доказательства диапазона и агрегированные доказательства — например, одновременно подтверждать, что общая сумма обязательств ниже лимита, а по каждому отдельному контрагенту превышения лимита нет. Готовых инструментов для этого пока нет, всё придётся собирать самим. Когда этот механизм заработает как надо, изменится и то, как учреждения продают свои услуги: вместо «у нас очень строгий риск-менеджмент» они смогут сказать: «Вы сами можете это проверить». #sxt $SXT @SpaceandTime
