2-of-2 vs 2-of-3 vs m-of-n multisig: выбор правильного порога

В предыдущей статье мы разобрали, что такое multisig: правило траты, в котором m из n ключей должны подписать, прежде чем деньги двинутся. SSP по умолчанию ставит тебя в 2-of-2 — два устройства, оба обязательны, никакого кворума, который надо обсуждать. Этот дефолт верен для большинства solo-пользователей, сидящих между «первой тысячей долларов» и «это уже настоящие деньги для меня». Он верен не для всех.

Эта статья — селектор. Три конфигурации покрывают подавляющее большинство реальных multisig-сетапов: 2-of-2, 2-of-3 и 3-of-5 (или выше). Каждая честно лучше остальных при определённых условиях и честно хуже при других. К концу этой статьи ты должен уметь ответить: какой m-of-n соответствует тому, что я реально пытаюсь защитить?

TL;DR

• 2-of-2 — дефолт персонального стека. Лучший вариант для одного пользователя с двумя устройствами, низкие затраты на координацию, умеренные суммы. Весь продукт SSP построен вокруг этого.
• 2-of-3 — ход, когда пользователь хочет планировать потерю ключа — потерянный телефон, потерянный бэкап, сценарии семейного наследства. «Резервированная» версия solo-multisig.
• 3-of-5 или выше — ответ, когда подписывать должны более одного человека, когда важна география или когда средства принадлежат компании / DAO / семейному офису, а не лицу.
• Повышение m не просто добавляет безопасность — оно добавляет liveness-риск (больше ключей должны быть доступны) и стоимость координации. Правильное m-of-n минимизирует сумму обоих.
• Идти выше 2-of-3 для одного пользователя — обычно ошибка. Маргинальная защита маленькая; операционная боль большая.

Три вопроса, определяющие m-of-n

Пропусти формальный threat modeling на секунду. На практике три вопроса решают, какая конфигурация подходит:

1. Кто должен подписать? Один человек? Двое? Команда, которая ротируется? Организация, где подписанты приходят и уходят?
2. Какой доминирующий отказ ты защищаешь — потеря или кража? Multisig справляется с обоими, но правильное соотношение m к n склоняет одно на другое. Более высокое n — больше избыточности против потери; более высокое m (относительно n) — больше сопротивления краже.
3. Какова операционная стоимость потери одного подписанта? Если ответ «я не могу добраться до телефона день», стоимость мягкая. Если ответ «CFO в самолёте, когда должна выйти зарплата», стоимость огромная.

Эти три линии достаточно чисто отображаются на три конфигурации ниже.

2-of-2: solo-с-резервированием дефолт

Setup: Существуют два ключа. Оба должны подписать. Дефолт SSP — один ключ в расширении браузера, один ключ в мобильном приложении SSP Key.

Лучше всего для: Один человек, один кошелёк, два устройства, не разделяющих поверхность атаки (ноутбук Mac и iPhone, Android и Windows-машина и т.п.). Защита приходит от разделения устройств: malware на ноутбуке не дотянется до телефона, и наоборот.

Сильные стороны:

• Самая низкая стоимость координации среди всех multisig. Оба устройства твои, оба обычно в кармане или на столе.
• Резко поднимает планку для кражи. Атакующий, полностью скомпрометировавший одно из двух устройств, всё ещё не может двинуть деньги. Ему надо скомпрометировать другое — почти всегда другая ОС, другая цепочка атаки — чтобы выиграть.
• Заставляет тебя держать два seed, в двух местах, с двумя отдельными бэкапами. Это куда лучшая дефолтная позиция, чем типичный сетап «один seed на бумажке в ящике».

Слабые стороны:

• Оба ключа несущие. Потеряй любое из двух устройств и его seed, и кошелёк мёртв. Поэтому чек-лист Self-Custody Fundamentals уделяет столько веса бэкапу обоих seed по отдельности. Это не опционально в 2-of-2.
• Нет кворума, чтобы «перевесить» плохого подписанта. Если оба подписанта — ты, это не проблема; если бы ты когда-либо разделил ключ с другим человеком в 2-of-2, у вас обоих было бы право заложника.

Это конфигурация, которую существующий пост What is 2-of-2 multisig? разбирает в деталях. Прочитай его после этой статьи для механики, специфичной для SSP; эта статья только калибрует, когда это правильный выбор.

2-of-3: когда пользователь хочет планировать потерю

Setup: Существуют три ключа. Любые два должны подписать. Распространённое расположение для solo-пользователя: один на «горячем» устройстве для повседневного использования, один на hardware wallet, держимом дома, один на recovery-устройстве, держимом где-то ещё (банковская ячейка, дом родителя, банковский сейф — где-то географически отдельно).

Лучше всего для: Одного человека, но того, кто пересёк границу «если сгорит любой одиночный предмет, я хочу всё равно восстановиться». Self-custody пользователи между ~$10k и ~$100k часто мигрируют сюда.

Сильные стороны:

• Переживает потерю (или уничтожение) любого одного ключа. Пожар дома съел hardware wallet? У тебя всё ещё ноутбук + удалённое устройство — достаточно для кворума 2-of-3.
• Кража любого одного ключа всё ещё недостаточна — атакующему пришлось бы скомпрометировать два из трёх. Географическое разделение делает третий ключ значительно труднодоступнее.
• Даёт чистый путь наследования. Можно оставить третий ключ члену семьи или адвокату так, чтобы они не могли действовать односторонне (у них только один из трёх), но могли скомбинироваться с одним из твоих оставшихся ключей, чтобы восстановить кошелёк в заданном сценарии.

Слабые стороны:

• Больше ключей провижнить, бэкапить, тестировать. Каждый требует уникального seed и уникального места хранения. Seed phrase best practices — обязательное чтение перед этим.
• Чуть большая поверхность атаки — три ключа значат три места, где атакующий может попробовать скомпрометировать, даже если ему нужно скомпрометировать два.
• Более сложная репетиция восстановления. Тебе следует периодически проверять, что ты действительно можешь скомбинировать два из трёх ключей, чтобы потратить. Это операционная обязанность.

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

3-of-5 (и выше): когда команды и казначейства выходят на сцену

Setup: Существуют пять ключей, любые три должны подписать. Используется компаниями, партнёрствами, DAO, семейными офисами. Пять ключей обычно распределены между людьми, ролями и географиями.

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

Сильные стороны:

• Ни один человек не контролирует деньги. Двое скомпрометированных или мятежных подписантов всё ещё не могут двинуть средства.
• Операционная непрерывность. Любой один человек может быть недоступен (болен, в поездке, уволен), а остальные четверо всё равно имеют кворум.
• Естественно поддерживает разделение обязанностей — controller, CFO, CEO, внешний аудитор и горячий подписант все могут быть разными ролями. Порог можно настроить под governance компании.

Слабые стороны:

• Накладные расходы координации реальны. Заставить трёх из пяти людей действительно подписать транзакцию в определённое окно времени честно тяжелее, чем заставить одно-два устройства подписать в собственном кармане.
• Каждый новый подписант добавляет поверхность атаки. Пять ключей — это пять отдельных устройств, пять отдельных процедур бэкапа, пять отдельных планов преемственности при уходе подписанта.
• Кастомные workflow. Большинство потребительских кошельков не поставляют 3-of-5 по умолчанию; обычно после этого порога переходят к специализированному tooling (Safe, Casa, кастомные multisig-сетапы). SSP Wave 1 построен вокруг 2-of-2 и не подходит для такого масштаба.

Частый вариант — 2-of-3 с социальными подписантами — сидит между solo 2-of-3 и корпоративным 3-of-5. Ты держишь два ключа; доверенный член семьи или адвокат держит третий. Они не могут потратить в одиночку (одного ключа недостаточно), но могут помочь тебе восстановиться, если ты потеряешь один из своих.

Что размер исправляет — и не исправляет

Переход от 2-of-2 к 2-of-3 к 3-of-5 — не линейный ползунок «больше безопасности». Некоторые свойства улучшаются; другие ухудшаются.

Повышение n помогает с:

• Устойчивостью к потере (больше ключей — больше избыточности).
• Планированием наследства.
• Операционной доступностью с несколькими людьми.

Повышение n вредит:

• Объёму работы по гигиене seed-phrase, которую тебе придётся делать вечно.
• Числу мест, где атакующий должен провалить атаку, но также числу мест, где он должен преуспеть — что иногда хуже, если ключи не по-настоящему независимы.

Повышение m (порога) помогает с:

• Устойчивостью к краже (атакующему нужно больше ключей).
• Минимизацией доверия между подписантами (любое подмножество ниже m не может действовать).

Повышение m вредит:

• Liveness. Если m ключей должны быть доступны для траты, то n - m + 1 ключей оффлайн замораживает кошелёк. 4-of-5, требующее четырёх людей в координации, известно своей хрупкостью.

Искусство в том, чтобы выбрать m и n так, чтобы стоимость доступности необходимости m подписантов соответствовала выгоде безопасности необходимости m подписантов. Для большинства solo-пользователей 2-of-2 попадает в sweet spot. Для большинства команд — 3-of-5. Промежуточный случай — 2-of-3 для solo-пользователя, планирующего потерю — самая недоиспользуемая конфигурация в розничном self-custody.

Что это значит для тебя

Три вывода:

1. По умолчанию используй 2-of-2 для solo до пяти знаков. Это то, для чего создан SSP, что объясняет Meet SSP Wallet, и сетап с наименьшим трением, который материально поднимает твою позицию безопасности.
2. Переходи к 2-of-3, как только стоимость потери одного ключа превышает стоимость управления тремя. Грубо: когда ты пересёк границу «это настоящее богатство», когда у тебя ясный вопрос наследства или когда ты уже переживал близкий recovery-страх.
3. Не тянись к 3-of-5+, если не защищаешь средства, принадлежащие более чем одному человеку. Это правильный ответ для организаций и не очень для индивидов — даже состоятельные предпочитают 2-of-3 с custodial-помощником вместо полного 3-of-5.

Следующая статья в этой серии, BIP48 explained: the derivation path behind SSP, входит в то, как кошелёк 2-of-2 (или 2-of-3) на самом деле строится on-chain — стандарт, позволяющий нескольким ключам кооперироваться, и причина, по которой большинство современных multisig-кошельков взаимно совместимы.