Адрес кошелька выглядит простой вещью: строка, которую вы копируете, вставляете и на которую отправляете деньги. В Bitcoin он почти так и устроен. В Solana поставить за адресом общий кошелёк — мультисиг — на удивление сложно. Эта статья объясняет почему и ставит вопрос, на который отвечает остальная часть серии.
Что должен пообещать адрес мультисига
Мультисиг-кошелёк — это кошелёк, которым управляют несколько ключей и где фиксированное их число должно согласиться, прежде чем деньги придут в движение. У мультисига «2 из 3», например, три ключа, и для одобрения платежа нужны любые два. Цель — устранить единые точки отказа: вы теряете один ключ или один ключ крадут, а ваши средства всё равно в безопасности.
Чтобы это было полезно, адрес должен сдержать два обещания. Во-первых, он должен быть известен заранее — вы хотите передать кому-то адрес для пополнения ещё до того, как закончите любую настройку. Во-вторых, он должен быть честным: тот, кто отправляет деньги на этот адрес, должен иметь возможность доверять, что только согласованная группа ключей по согласованному правилу когда-либо сможет с него тратить. Запомните эти два обещания. Они — нить, проходящая через всё дальнейшее.
В Bitcoin адрес — это правило
Bitcoin делает это лёгким на вид. Мультисиг в Bitcoin описывается небольшим скриптом: список открытых ключей плюс правило «M из N». Чтобы получить адрес, вы берёте этот скрипт и хешируете его. Адрес (адрес P2WSH) буквально является хешем правил траты.
У этого есть тихо мощное следствие. Любой может вычислить адрес офлайн, на ноутбуке без интернета, до того как будет передана хотя бы одна транзакция. Нет шага «создать кошелёк» — кошельку не нужно существовать в сети, чтобы получать деньги. Скрипт раскрывается лишь позже, при трате средств, и сеть проверяет, что раскрытый скрипт соответствует адресу и что есть достаточно действительных подписей. Адрес известен заранее: да. Честен: да — потому что адрес выводится из самого правила, иной набор ключей даёт иной адрес.
В Solana адрес — это аккаунт, который нужно создать
Solana работает иначе. В Solana всё является аккаунтом — ячейкой ончейн-хранилища с владельцем. Ваши средства живут в аккаунтах, программы живут в аккаунтах, и конфигурация мультисига тоже живёт в аккаунте. Важно, что аккаунты не возникают бесплатно. Аккаунт должен быть явно создан и оплачен: кто-то финансирует его небольшим количеством SOL, называемым «рента», чтобы сеть хранила его данные.
Поэтому мультисиг в Solana — это не просто адрес, а управляемый программой аккаунт, в котором хранятся список участников и порог. И этот аккаунт должен быть создан транзакцией, прежде чем мультисиг сможет что-либо сделать. В этом корень сложности: у общего кошелька в Solana есть шаг настройки, которого у Bitcoin попросту нет.
PDA: адреса без приватного ключа
У Solana есть для этого изящный инструмент — Program Derived Address, или PDA. У обычного адреса Solana есть соответствующий приватный ключ — кто владеет ключом, тот управляет адресом. PDA намеренно построен так, чтобы лежать вне кривой: это правдоподобно выглядящий адрес, для которого не существует приватного ключа и не может существовать. Никто не может подписать за него лично.
Вместо этого PDA выводится детерминированно. Вы берёте несколько входных значений — их называют «сидами» (seeds) — плюс идентификатор программы, прогоняете их через одностороннюю функцию, и на выходе получается адрес. Те же сиды и та же программа всегда дают тот же PDA, так что любой может его воспроизвести. И поскольку приватного ключа нет, только программа-владелец может авторизовать действия для этого адреса — она делает это через механизм под названием межпрограммный вызов с invoke_signed: программа предъявляет сиды среде выполнения Solana, и среда наделяет её правом подписи для PDA. Криптографическая подпись никогда не создаётся — право действовать исходит из знания сидов, а не из владения ключом.
PDA — именно правильный дом для мультисига: адрес, управляемый логикой программы, а не каким-либо одним человеком. Пока всё хорошо. Сложность в том, что выбирается в качестве сидов.
Проблема «профинансировать до создания»
Вот где доминирующие мультисиги Solana сталкиваются с трудностью. В отличие от детерминированной модели Bitcoin, наиболее используемые мультисиги Solana — Squads V4 является ведущим примером, зрелым и тщательно проверенным аудитами — выводят адрес мультисига из свежесгенерированного случайного значения, выбираемого в момент создания, а не из набора участников. В Squads V4 это значение называется create_key — эфемерный ключ, создаваемый, когда создатель выполняет транзакцию создания.
Выводить адрес из случайного create_key — осознанный, разумный выбор проектирования: он обходит неудобный краевой случай, когда две разные группы хотят в точности один и тот же состав участников. Но у него есть два следствия, которые стоит ясно понимать:
- Вы не можете узнать адрес заранее. Сид не существует, пока кто-то не выполнит транзакцию создания, а значит, и адреса нет. Нет способа напечатать адрес для пополнения и профинансировать его до настройки — проблема «профинансировать до создания». Первое обещание рушится.
- Создатель — единая точка доверия на этапе настройки. Конкретный аккаунт должен выполнить эту транзакцию создания и выбрать это случайное значение. На короткое окно настройки вы доверяете этой стороне сделать всё правильно.
Ничто из этого не делает Squads V4 небезопасным — это самый проверенный в бою мультисиг Solana, и он защищает очень крупные суммы. Это просто иная форма доверия, чем в Bitcoin. Адрес больше не «хеш правила»; он — «то, что произвела транзакция создания».
Ethereum нашёл срединный путь
Ethereum столкнулся со схожей проблемой и ответил на неё функцией под названием CREATE2. Она позволяет вычислить адрес смарт-контракта до того, как контракт развёрнут, из фиксированных входных данных. Кошельки вроде Safe используют это, чтобы дать вам так называемый контрфактический адрес: настоящий, пополняемый адрес, которым можно поделиться и на который можно получать деньги, тогда как сам контракт разворачивается лениво — лишь когда средствам впервые нужно прийти в движение. Более новый стандарт абстракции аккаунтов ERC-4337 формализует ту же идею. Так Ethereum возвращает обещание «известен заранее», хотя ему, как и Solana, в итоге нужен ончейн-объект.
Вопрос, на который отвечает эта серия
Поставьте три модели рядом. Bitcoin: адрес — это хеш правила, его можно вычислить офлайн, он честен по построению, шага создания нет. Ethereum: контрфактический адрес — известен заранее, развёртывание отложено. Универсальные мультисиги Solana: адрес берётся из случайности момента создания — заранее не известен, с создателем, которому нужно доверять при настройке.
И вот вопрос. Solana нужны аккаунты, а аккаунты нужно создавать — это никуда не денется. Но обязан ли мультисиг Solana отказаться от свойства Bitcoin? Не может ли адрес вместо этого выводиться чисто из набора участников и порога — из самого правила — так, чтобы он был вычислим офлайн, пополняем до настройки и честен, потому что иная группа ключей даёт иной адрес?
Именно это свойство команда SSP встроила в собственную программу мультисига для Solana. Следующая статья показывает как: адрес, который является набором участников, хранилище, которое можно профинансировать до того, как что-либо зарегистрировано ончейн, и шаг регистрации, которому вообще не нужен создатель. Дизайн был выпущен вместе с поддержкой Solana в SSP Wallet — см. анонс релиза — и, в духе того, как SSP относится к безопасности, программа сейчас только в devnet и ожидает внешнего аудита перед mainnet. Если сам мультисиг для вас ещё нов, начните с того, что такое мультисиг и почему он важен; иначе читайте дальше.
