Как работает MPC-подписант в Codono Enterprise и почему пороговое хранение надёжнее сейфа, полного ключей

Содержание

• Кратчайшее возможное объяснение
• Почему биржевое хранение продолжает давать сбои
• Что такое многосторонние вычисления на самом деле
• От академической диковинки к основе биржевой инфраструктуры
• Внутри MPC-подписанта Codono Enterprise
• Генерация ключей: церемония, на которой ключ не рождается
• Поток подписания, шлюз за шлюзом
• Вывод адресов без прикосновения к ключам
• MPC против мультиподписи, HSM и одиночного ключа
• Почему MPC подходит биржам лучше всего остального
• Насколько это безопасно на самом деле: разбор модели угроз
• Чего MPC не решает и что Codono надстраивает вокруг
• Комплаенс-дивиденд
• Ежедневная эксплуатация MPC
• Оценка MPC-хранения: чек-лист покупателя
• Краткий глоссарий

Кратчайшее возможное объяснение

MPC-подписант Codono Enterprise — это self-hosted сервис на Go, который хранит криптографические доли ключей вместо приватных ключей. Три доли генерируются на разных машинах в ходе распределённой церемонии; любые две из них могут совместно создать валидную подпись через интерактивный протокол — но полный приватный ключ не существует ни на одной машине, ни в один момент времени, включая момент своего «создания». Украдите один узел подписанта — и вы не украли ничего, что можно потратить.

Одно это свойство — ключ никогда не существует — устраняет сценарий отказа, стоящий за крупнейшими кастодиальными потерями в истории бирж. Остальная часть статьи объясняет, как подписант этого достигает, как выглядит конвейер подписания шлюз за шлюзом, как он соотносится с мультиподписью и HSM и — поскольку текст о безопасности, перечисляющий только сильные стороны, это маркетинг, а не инженерия, — даёт откровенную оценку того, от чего MPC не защищает, и как окружающая архитектура безопасности биржи закрывает эти пробелы.

Почему биржевое хранение продолжает давать сбои

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

Mt. Gox потеряла около 850 000 BTC, потому что ключи горячего кошелька годами были доступны скомпрометированной инфраструктуре. Атака 2022 года на мост Ronin выкачала около $625 миллионов, потому что пять из девяти ключей валидаторов — полных, пригодных для траты ключей — оказались под контролем одного оператора, и этого оператора сфишили. Chainalysis оценила общий объём украденной в 2022 году криптовалюты в $3,8 миллиарда. Детали различаются; примитив — нет. Полный ключ — это полная кража, ожидающая одной ошибки.

Традиционные ответы индустрии каждый по-своему смягчают примитив, не устраняя его:

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

Пороговый MPC — первый широко развёрнутый подход, устраняющий сам примитив. Нечего красть — ни в холодном, ни в горячем контуре, ни в железе, ни в софте, — потому что ключ никогда не собирается: он существует лишь как математическая абстракция, распределённая по долям. Вот почему технология за несколько лет прошла путь от академических статей до защиты институционального хранения в компаниях вроде Fireblocks и Zengo, и почему Codono Enterprise сделал её кастодиальной основой платформы, а не опциональным дополнением.

Что такое многосторонние вычисления на самом деле

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

В применении к подписям «функция» — это алгоритм подписания, а «приватные входы» — доли ключа:

1. Генерация. N сторон выполняют протокол распределённой генерации ключей (DKG). Каждая в итоге держит одну долю. Соответствующий публичный ключ — а значит, и депозитные адреса — известен всем, но приватный ключ не вычисляется никем. Он неявно определён долями — так же, как точка определена пересекающимися в ней прямыми, ни одна из которых её не «содержит».
2. Подписание. Когда нужна подпись, пороговое число сторон (t из n — в развёртывании Codono это 2 из 3) вступает в интерактивный протокол. Каждая сторона вычисляет частичные результаты, используя только свою долю, и обменивается ослеплёнными промежуточными значениями. Из взаимодействия выпадает совершенно стандартная подпись ECDSA или EdDSA — неотличимая ончейн от подписи обычного кошелька.
3. Ключевой инвариант. Ни на одном шаге — ни при генерации, ни при хранении, ни при подписании, ни при восстановлении — доли не объединяются в приватный ключ. Ниже порога вы получаете нулевую способность подписывать, и точка. По части секретности точная формулировка тоньше, и её стоит дать честно: сырое разделение секрета даёт долям ниже порога совершенную (информационно-теоретическую) бесполезность, а развёрнутый протокол порогового ECDSA надстраивает поверх коммитменты, шифротексты и доказательства — поэтому его безопасность вычислительная и зависит от корректного выполнения протокола каждым участником. Свойство, на которое можно положиться: пассивный атакующий, владеющий меньше порогового числа долей, против честно выполняемого протокола не узнаёт ничего применимого и не может подписать ничего. Это качественное улучшение по сравнению с «где-то существует целый ключ» — а не заявление о математической неуязвимости.

Протоколы, на которых строит Codono, происходят из открытого, независимо проаудированного семейства tss-lib — конструкций порогового ECDSA, восходящих к линии работ Геннаро–Голдфедера, плюс пороговый EdDSA для сетей на ed25519. (Проаудировано не значит безупречно: в tss-lib были раскрытые уязвимости извлечения ключей, которые нашли и исправили — а это ровно та прозрачная, состязательная проверка, которая вам нужна и которую невозможно получить от проприетарной кастодиальной математики.) Это важно для должной проверки: криптография опубликована, рецензирована и проверена боем по всей индустрии, а не является проприетарной математикой, которую вам предлагают принять на веру. Ваша техническая команда может проаудировать реализацию напрямую, потому что Codono Enterprise поставляет исходный код подписанта вместе с остальной платформой.

От академической диковинки к основе биржевой инфраструктуры

Полезно знать, насколько необычно хорошо изъезжена эта криптография, потому что «новая криптография» — обычно тревожный сигнал для хранения, а пороговое подписание — что угодно, только не новинка.

Основания старше большей части интернета. Ади Шамир опубликовал разделение секрета в 1979 году — математический приём разбиения секрета так, что любые t фрагментов восстанавливают его, а t−1 не раскрывают ничего. Эндрю Яо сформулировал безопасные многосторонние вычисления в 1982 году в своей знаменитой задаче миллионеров: две стороны вычисляют, кто богаче, не раскрывая своё состояние. В 1980-е и 90-е протоколы GMW и BGW установили, что любую функцию в принципе можно вычислять совместно над приватными входами. Десятилетиями не хватало практичности — ранний MPC был в тысячи раз медленнее, чем нужно реальным системам.

Две вещи это изменили. Во-первых, поколение протокольной инженерии: пороговый EdDSA сравнительно естественен, потому что подписи в стиле Шнорра линейны, а пороговый ECDSA — долгое время трудный случай и именно тот, что требуется Bitcoin и Ethereum, — стал практичным благодаря линии протоколов Геннаро–Голдфедера (GG18, GG20) и её преемникам. Во-вторых, появилась индустрия с неотложной, хорошо профинансированной причиной интересоваться: после каждой волны потерь бирж и мостов кастодиальные команды искали архитектуру, в которой кража ключей структурно невозможна, а не процедурно не поощряется.

Результат: к середине 2020-х пороговый MPC стал тихим стандартом институционального хранения цифровых активов — технологией под продуктами вроде Fireblocks и кошельковой инфраструктурой нескольких крупных бирж — с открытыми, проаудированными реализациями (среди них семейство tss-lib), которые может изучить любой. Когда Codono Enterprise принял то же семейство протоколов для своего подписанта, решение было сознательно консервативным: использовать конструкции, которые индустрия уже десятилетие атакует, а инновационный бюджет потратить на интеграцию — шлюзы, политики и церемонии вокруг криптографии, — где биржевая инженерия действительно окупается.

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

Внутри MPC-подписанта Codono Enterprise

Подписант намеренно скучен снаружи — небольшой изолированный сервис с узким аутентифицированным API, — потому что кастодиальные компоненты должны быть наименее хитроумными и наиболее аудируемыми частями биржи. Важные свойства:

Отдельный сервис, на отдельном языке, с отдельной поверхностью атаки. Подписант написан на Go и работает как собственный процесс — обычно на отдельном хосте или в усиленном контейнере — в стороне от торгового бэкенда на Java и движка на Node.js, составляющих остальную часть платформы. Уязвимость в веб-ориентированном компоненте не превращается в исполнение кода рядом с долями ключей; чтобы достичь подписанта, нужно пересечь ещё одну границу аутентификации.

С ним говорит только бэкенд, и бэкенд обязан это доказать. Каждый запрос к API подписанта несёт HMAC от содержимого запроса, а транспорт — взаимно аутентифицированный TLS. Нет ни дашборда, ни публичного порта, ни «удобного» эндпоинта. Атакующий, захвативший веб-сервер, не получил тем самым возможности запрашивать подписи — у него нет ни транспортных учётных данных, ни секрета подписи запросов.

Доли зашифрованы даже при хранении. Горячие доли подписания хранятся под аутентифицированным шифрованием (AES-256-GCM) и расшифровываются только в памяти процесса на время раунда подписания. Образы дисков, бэкапы и украденные тома дают лишь шифротекст.

Два класса долей, две температуры хранения. Схема 2-из-3 развёрнута асимметрично: две операционные доли живут на разделённой инфраструктуре подписанта и участвуют в повседневном подписании для горячего контура, а третья — доля восстановления — генерируется на офлайн-церемонии, один раз экспортируется под собственным одноразовым шифрованием и хранится полностью вне производственной среды (банковская ячейка, хранение у сотрудника по безопасности или эквивалент в вашей юрисдикции). Повседневные операции её не касаются; касаются её аварийное восстановление и церемонии перевыпуска.

Обе семьи подписей, одна модель. Пороговый ECDSA покрывает мир secp256k1 — Bitcoin, Ethereum и каждую EVM-сеть, Tron, Litecoin, XRP, — а пороговый EdDSA покрывает сети на ed25519, такие как Solana и TON. Более 50 поддерживаемых блокчейнов биржи наследуют одну единообразную модель хранения вместо лоскутного одеяла из решений под каждую сеть.

Генерация ключей: церемония, на которой ключ не рождается

Всё последующее наследует свою безопасность от церемонии генерации, поэтому она заслуживает отдельного раздела.

Когда развёртывание Codono Enterprise инициализирует хранение, участвующие узлы подписанта вместе выполняют протокол DKG. Каждый узел независимо выбирает секретную случайность, узлы обмениваются криптографическими коммитментами и проверочными значениями, и каждый завершает церемонию, держа: свою долю, доказательство честного поведения всех остальных участников и коллективный публичный ключ. Три свойства стоит усвоить:

• Нет доверенного дилера. У наивного разделения секрета есть фатальный изъян начальной загрузки: кто-то генерирует ключ, а затем разбивает его — и в этот момент полный ключ существовал на машине дилера. DKG устраняет дилера. Ключ никогда не генерируется целиком, чтобы потом быть разбитым; он рождается распределённым.
• Проверяемое участие. Раунды коммитментов означают, что злонамеренный или сбоящий участник не может незаметно испортить церемонию — отклонения обнаруживаются, и церемония прерывается вместо того, чтобы породить слабый ключ.
• Детерминированные пути восстановления. Выходы церемонии включают всё необходимое для будущих церемоний перевыпуска долей: замена скомпрометированной доли, ротация инфраструктуры или изменение порога — всё без восстановления ключа и без перемещения средств или аннулирования депозитных адресов.

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

Поток подписания, шлюз за шлюзом

Запрос на подпись — самое опасное сообщение на бирже. Вот полный путь, который проходит вывод средств в Codono Enterprise, прежде чем подпись вообще появится:

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

Шлюз 2 — риск-конвейер платформы. Сначала отрабатывают лимиты по уровням и периодам, правила скорости и риск-скоринг; суммы и паттерны, превышающие настроенные пороги, уводятся в очередь двойного одобрения maker-checker, где живой администратор — с ролевыми разрешениями и неизменяемым аудит-логом — должен одобрить операцию, прежде чем что-либо продвинется. Аварийные выключатели могут заморозить весь исходящий контур одним действием.

Шлюз 3 — аутентифицированный запрос на подпись. Только после прохождения конвейера бэкенд строит саму транзакцию и вызывает подписант — по mTLS, с HMAC-подписью запроса. Некорректные, повторно воспроизведённые или неаутентифицированные запросы умирают здесь.

Шлюз 4 — проверки политик и пороговый раунд. Подписант применяет собственный уровень политик, прежде чем задействовать доли, — валидирует структуру запроса и принудительно исполняет ограничения на стороне подписанта, — затем две операционные доли исполняют интерактивный пороговый протокол. Частичные вычисления передаются между узлами; появляется стандартная подпись; ключ, как всегда, не появляется.

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

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

Вывод адресов без прикосновения к ключам

Бирже нужен уникальный депозитный адрес для каждого пользователя в каждой сети — потенциально миллионы адресов. Наивный дизайн хранения генерирует (и вынужден затем защищать) по ключу на адрес. Подписант Codono обходит всю проблему целиком с помощью иерархически-детерминированной деривации:

Церемония даёт расширенный публичный ключ (xpub). Из него бэкенд биржи выводит депозитные адреса для каждого пользователя, используя стандартную незакалённую деривацию BIP-32 — операцию только с публичным ключом. Бэкенд может чеканить неограниченное число адресов, никогда не держа ключевого материала, а подписант позже может создавать подписи для любого производного адреса, применяя тот же путь деривации внутри порогового протокола.

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

MPC против мультиподписи, HSM и одиночного ключа

Свойство	Одиночный ключ	Ончейн-мультиподпись	HSM	Пороговый MPC
Полный ключ где-то существует	Да	Да — по одному на подписанта	Да — внутри устройства	Никогда
Компрометация одной машины = кража	Да	Нет (нужно m из n)	Да, если можно запрашивать подписи	Нет — доли ниже порога бесполезны
Одинаково работает во всех сетях	Да	Нет — поддержка и семантика зависят от сети	В основном	Да — на выходе стандартная подпись
Ончейн-след	Обычный	Отдельный скрипт/адрес, выше комиссии, видимая политика	Обычный	Обычный — неотличим
Ротация ключей без перемещения средств	Нет	Нет — новый адрес, миграция средств	Ограниченно	Да — церемония перевыпуска, те же адреса
Доступность подписания	Хрупкая	Накладные расходы на координацию	Устройство — узкое место	Любые t из n долей; переживает потерю узла
Аудируемость механизма	Тривиальная	Ончейн-скрипт	Прошивка вендора — закрыта	Опубликованные протоколы; исходники поставляются в Codono Enterprise

Строка, которая решает реальные закупки, — обычно третья. Биржа, работающая с 50+ сетями, не может строить модель хранения на мультиподписи, потому что половина этих сетей реализует мультиподпись по-разному, а несколько почти не поддерживают её; какая бы история хранения ни работала для скриптовой мультиподписи Bitcoin, в том же виде она просто не существует на Tron или TON. MPC переносит многостороннее свойство из блокчейна в математику, что делает его независимым от сети по построению.

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

Почему MPC подходит биржам лучше всего остального

За пределами сравнительной таблицы четыре свойства точно совпадают с тем, как работают биржи:

1. Горячий контур — опасный контур, и MPC укрепляет именно его. Холодное хранение достаточно хорошо защищает казначейство; вечная слабость — горячий оборотный остаток, который должен подписывать выводы автоматически, круглосуточно, на розничной скорости. Это ровно тот контур, где «сервер держит ключ» исторически означало «сервер и есть ключ». Пороговое подписание сохраняет автоматическую доступность, устраняя единую точку кражи — свойство, которого никакой объём холодного хранения не даст средствам, обязанным двигаться по требованию. Codono дополняет это разделением горячего и холодного контуров и автоматическими свипами, так что защищённый MPC оборотный остаток остаётся тонким, а казначейство — в офлайне.

2. Обычные адреса, обычные комиссии, обычная приватность. Адреса под MPC-хранением неотличимы от обычных ончейн. Конкуренты и чейн-аналитики не могут перечислить вашу кастодиальную структуру по обозревателям; пользователи платят стандартные комиссии; ничто о вашей позиции безопасности не утекает в публичные данные.

3. Институциональные ожидания сошлись на нём. Кастодиальные технологии — один из вопросов, которые банковские партнёры, страховщики и лицензирующие органы теперь задают напрямую. «Пороговый MPC с офлайн-долей восстановления, шифрованным хранением долей, двойным одобрением и полными аудит-логами» — ответ, чисто ложащийся на ожидания к хранению эпохи VASP и MiCA — и на чек-листы должной проверки институциональных контрагентов, которых биржа рано или поздно захочет привлечь.

4. Вы эксплуатируете его сами. Бо́льшая часть MPC-хранения на рынке продаётся как SaaS с оплатой за транзакцию или от объёма активов — отличные продукты, постоянная зависимость и постоянные комиссии. В Codono Enterprise подписант — ваша инфраструктура: self-hosted, с исходным кодом по лицензии, работающий в вашей среде под вашей лицензией, как и остальная платформа. Тот же аргумент владения, что применим к бирже, применим и к её хранению.

Насколько это безопасно на самом деле: разбор модели угроз

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

Украсть диск, бэкап или снапшот → шифротекст. Доли зашифрованы при хранении; ключ шифрования не лежит рядом с ними.

Полностью скомпрометировать один узел подписанта — root-доступ, доступ к памяти, всё → в лучшем случае одна расшифрованная доля на время раундов подписания. Ниже порога 2-из-3 эта доля несёт нулевую способность подписывать и — против честно выполняемого протокола — ничего, что атакующий мог бы превратить в ключ. Следующее требование атакующего — одновременная, независимая компрометация второго узла — разделённая инфраструктура, отдельные учётные данные, в идеале отдельные администраторы — до того, как обнаружение и церемония перевыпуска обратят его первый плацдарм в ничто.

Скомпрометировать сеть между бэкендом и подписантом → нужно перехватить mTLS плюс подделать HMAC каждого запроса. Владение сетевой позицией не даёт ни того, ни другого.

Скомпрометировать веб-уровень и попытаться запросить вредоносные подписи → это серьёзный сценарий, и именно поэтому существуют шлюзы 1–4. Запрос должен исходить от аутентифицированного бэкенда, пережить лимиты и правила скорости, пройти белый список, если он включён, пройти maker-checker для крупных сумм и удовлетворить политикам на стороне подписанта. Каждый шлюз — независимый контроль с независимым аудит-логом. Этот сценарий — также причина, по которой существует честный раздел ниже.

Сфишить или принудить администратора → RBAC означает, что ни одна роль администратора не настраивает лимиты и не одобряет выводы одновременно; maker-checker означает, что одобряющий не может быть инициатором; аудит-логи означают, что действие атрибутируемо; аварийные выключатели означают, что реакция — одно действие, а не штаб.

Атаковать саму криптографию → протоколы — это опубликованные, проаудированные конструкции tss-lib, используемые по всей индустрии институционального хранения. Не невозможно — ничто не невозможно, — но это наиболее изученный угол всей поверхности атаки.

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

Чего MPC не решает и что Codono надстраивает вокруг

Любой поставщик, продающий MPC как полную историю безопасности, продаёт неполную. Три пробела заслуживают прямых формулировок:

Проблема «подписываем что?». Пороговая криптография гарантирует, как создаётся подпись, а не должна ли она создаваться. Если атакующий может подсунуть запрос на вывод, выглядящий легитимным для каждого шлюза, математически совершенные доли произведут математически совершенную подпись на краже. Это самая глубокая истина кастодиальной безопасности, и именно поэтому бо́льшая часть защит этой архитектуры — белые списки, лимиты, maker-checker, политики на стороне подписанта, сигналы сверки — живёт до и после криптографии. Оценивайте любой MPC-продукт вопросом: что стоит между «атакующий контролирует сервер приложения» и «подписант получает запрос»? Если ответ — только «аутентификация», продолжайте оценивать.

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

Инженерия доступности. Схема 2-из-3 терпит потерю одной доли — но два одновременных инфраструктурных отказа останавливают подписание (безопасно: средства непотрачиваемы, но не потеряны, восстановимы через офлайн-долю). Мониторинг здоровья подписанта, тестирование церемоний восстановления до того, как они понадобятся, и репетиция ранбука — операционные обязанности, прилагающиеся к владению хранением, а не к его аренде.

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

Комплаенс-дивиденд

Кастодиальная архитектура всё чаще регуляторная тема, а не только инженерная. Пороговое хранение приносит несколько комплаенс-дивидендов:

• Заявки на лицензии в рамках VASP-подобных режимов спрашивают, как активы клиентов защищены и от внешних атак, и от внутреннего присвоения. «Полного ключа не существует; подписание требует двух разделённых систем; крупные выводы требуют двойного человеческого одобрения; каждое действие записывается в аудит-лог» отвечает на оба вопроса одной архитектурой.
• Travel Rule и мониторинг транзакций интегрируются на шлюзе 2 — риск-конвейере, — где инструменты KYC/AML скринят выводы до появления любого запроса на подпись.
• Доказательство резервов работает естественно: MPC-адреса — стандартные адреса, поэтому аттестации резервов, ончейн-проверка и выборка аудиторов проходят ровно так же, как с любым кошельком, — никаких экзотических скриптов, которые нужно объяснять.
• Аудируемость сквозная: реестр фиксирует изменение баланса, админ-лог фиксирует одобрение, подписант фиксирует событие подписания, а сеть фиксирует результат — четыре независимо проверяемые записи о каждой ушедшей монете.

Ежедневная эксплуатация MPC

Что Enterprise-операторы реально делают после запуска:

• Депозиты: ничего. Деривация адресов свободна от ключей; подписант вообще не участвует в приёме средств.
• Обычные выводы: ничего. Конвейер работает автоматически в рамках настроенных лимитов; пороговый раунд добавляет миллисекунды, а не рабочий процесс.
• Крупные выводы: одобрить. Очереди maker-checker появляются в админ-панели с полным контекстом.
• Периодически: проверять. Отчёты сверки сравнивают реестр с блокчейном; метрики здоровья подписанта питают тот же стек наблюдаемости, что и остальная платформа.
• Редко: церемонии. Кадровые изменения, миграции инфраструктуры или подозрение в раскрытии запускают перевыпуск долей — плановую процедуру, а не аварийную миграцию.
• Никогда: бэкапы ключей. Нечего бэкапить. Процедуры хранения долей полностью заменяют полуночную панику «у кого сид-фраза».

Оценка MPC-хранения: чек-лист покупателя

Независимо от того, оцениваете вы Codono Enterprise или любую альтернативу, эти семь вопросов отделяют настоящее пороговое хранение от маркетинга:

1. Генерация ключей распределённая или через дилера? Если ключ сгенерировали, а потом разбили — он существовал. Настаивайте на DKG.
2. Каков порог и как разделены доли? 2-из-3 на действительно независимой инфраструктуре лучше, чем 3-из-5 на одном облачном аккаунте.
3. Что стоит между скомпрометированным сервером приложений и подписантом? Посчитайте независимые шлюзы. Меньше трёх — тонко.
4. Можно ли ротировать доли без перемещения средств? Перевыпуск — это разница между реагированием на инцидент и аварийной миграцией.
5. Какие кривые поддерживаются? Один ECDSA оставит ваши сети на ed25519 на другой модели хранения.
6. Может ли ваша команда проаудировать реализацию? Опубликованные протоколы и поставляемые исходники — или чёрный ящик?
7. Кто владеет этим на пятом году? Кастодиальные комиссии за транзакцию накапливаются так же, как комиссии SaaS-платформ. Собственная инфраструктура — нет.

Ответы Codono Enterprise: DKG; 2-из-3 с офлайн-долей восстановления; пять шлюзов; да, перевыпуск; обе семьи кривых; полные исходники; вы владеете безоговорочно.

Краткий глоссарий

• MPC (многосторонние вычисления) — криптография, позволяющая нескольким сторонам совместно вычислять результат над приватными входами, не раскрывая эти входы друг другу.
• Пороговая подпись (t-из-n) — схема подписи, в которой любые t из n долей ключа могут совместно создать валидную подпись, а меньше t не могут создать ничего.
• Доля ключа — фрагмент способности подписывать, принадлежащий одному участнику. Не кусок ключа ни в каком восстановимом смысле; ниже порога доли не раскрывают никакой информации о ключе.
• DKG (распределённая генерация ключей) — церемония, в которой доли генерируются совместно, так что полный приватный ключ никогда не существует, даже мгновенно, ни на одной машине.
• Перевыпуск долей (resharing) — церемония, выпускающая свежий набор долей для того же публичного ключа, выводя старые доли из обращения без перемещения средств и смены адресов.
• xpub (расширенный публичный ключ) — публичная половина дерева HD-кошелька; позволяет бирже выводить неограниченное число депозитных адресов без наличия ключевого материала.
• Maker-checker — процесс одобрения, в котором инициатор чувствительного действия никогда не может быть его одобряющим.

---

Оцените его в деле. Подписант поставляется с Codono Enterprise — смотрите актуальные уровни лицензий, пройдите по живому демо платформы или поговорите с командой развёртывания о кастодиальных церемониях для вашего запуска. Для более широкой картины безопасности продолжите с руководства по архитектуре безопасности биржи и корпоративного фреймворка безопасности.