Multisig-контракты и адреса в Bitcoin и Ethereum

Автор: admin от 30-05-2018, 13:50, посмотрело: 299

Multisig-контракты и адреса в Bitcoin и Ethereum

Multisig-контракты в современных децентрализованных сетях — это мощный инструмент, который позволяет просто и надёжно защищать средства на коллективных счетах, а также проводить сделки с несколькими участниками. Если вам интересно, как использовать такие адреса, то вы попросту обязаны понимать механику владения ими и прекрасно представлять себе порядок транзакций. Для работы с такими адресами требуется участие нескольких аккаунтов.



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



Мы будем говорить о двух сетях: Bitcoin и Ethereum. В других блокчейнах multisig-доступ к криптоактивам может быть реализован совершенно иначе.

статье Bitcoinwiki), то есть при обычной транзакции отправитель даже не знает публичного ключа получателя. Поэтому Вася, подписывая input, кроме самой подписи, предъявляет биткоиновскому Script’у ещё и свой публичный ключ, тем самым раскрывая его. Естественно, зная публичный ключ, можно без проблем сгенерировать Bitcoin-адрес.



Помимо подписи inputs, Вася ещё и ставит условие для каждого output’а, как можно потратить BTC с этого конкретного output’а. Но «требования» ему предоставил тот, кто получит биткоины: это его забота, как он будет тратить свои BTC. Это крайне важный момент. Адрес Bitcoin содержит в себе хеш от кода, который будет принимать решение, разрешить ли тратить BTC с этого адреса.



Если ещё искать аналогии, то Вася к каждому output’у (который ему сообщили те, кто получит BTC) прицепляет данные, которые отвечают на вопрос «Какой код и на каких данных должен вернуть true, чтобы подписывающий считался владельцем этого output’а?». Вот ещё аналогия для питонистов: можно представить, что каждый output содержит lambda-функцию, которая, исполненная Петей, предоставившим ей аргументы, вернёт true либо false. Если возвращается true, то Петя может использовать output как input для последующих транзакций. В default’ном варианте программа может взять два предоставленных Петей аргумента — подпись output’a и Петин public key — и проверить подпись. Если вернулось true, значит, Петя имеет право на output и может его потратить; следовательно, транзакция валидна. Глубже в рамках данной статьи в Script нырять необязательно, но крайне желательно. Кстати, redeem script — это и есть тот самый smart contract, то есть формальное правило, по которому право на BTC переходит от одного адреса к другому. Клиенты сети, процесся транзакции, исполняют каждый script в каждой транзакции, проверяя, валидна ли она. Если валидна — валидна и неоспорима трата биткоинов с определённого адреса.



Вот первая отличная статья по этой теме, сильно рекомендую прочитать, там отлично расписан весь raw-механизм с примерами на питоне: Bitcoins the hard way: Using the raw Bitcoin protocol. А вот ещё одна: Bitcoin in a nutshell — Transaction.



Вернёмся к мультисигу 2/3, отметив, что обычную транзакцию с переводом биткоинов можно рассматривать и как multisig 1/1. Предположим, Петя хочет, чтобы Вася просто перевёл ему BTC. Петя выдаёт Васе адрес, в который зашит хеш default’ного script’а, и биткоины с этого адреса Петя сможет забрать, предоставив стандартный код проверки подписи и саму подпись. Такие «традиционные» адреса в Bitcoin начинаются с цифры 1 (единицы). Адреса, в которые зашит «нетрадиционный» код (проверяющий multisig script), называются pay-to-script и начинаются с 3 (тройки).



Bitcoin позволяет нам создать адрес, в который будет зашит хеш НАШЕГО СОБСТВЕННОГО redeem script’a. Ведь это наша проблема, как мы потом будем тратить свои BTC, а не отправляющего. Нам неважно, кто переведёт биткоины на адрес, а важно, что, когда мы захотим их потратить, нам придётся предоставить код, соответствующий адресу. То есть, попросив перевести мне BTC на pay-to-script адрес, я обязуюсь предоставить сам скрипт потом, в транзакции, использующей данный input.



Согласно документации, для multisig используется код такого вида:



-----------------------------------------------------------
Pubkey script: OP_HASH160 <Hash160(redeemScript)> OP_EQUAL
Signature script: <sig> [sig] [sig...] <redeemScript>
-----------------------------------------------------------


(Продолжение статьи о script и multisig: [/url]http://www.soroushjp.com/2014/12/20/bitcoin-multisig-the-hard-way-understanding-raw-multisignature-bitcoin-transactions/)



Нам нужен такой script, чтобы все необходимые подписи сразу были представлены в тратящей транзакции. Если, к примеру, наш multisig 2/3 содержит адреса трёх участников (генерального директора, главного бухгалтера и сисадмина) и секретные ключи для подписей лежат на их компьютерах раздельно, то для формирования тратящей транзакции сисадмину придётся:




  • сформировать тратящую транзакцию;

  • сформировать собственную подпись;

  • передать содержимое транзакции второму подписанту (например, сходить в бухгалтерию или к генеральному с флешкой);

  • попросить второго подписанта добавить подпись к транзакции;

  • отправить в сеть транзакцию с двумя из трёх подписей.



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



Ethereum multisig



Реализация multisig в Ethereum сильно отличается от таковой в Bitcoin из-за разного дизайна внутренних алгоритмов клиента сети, но есть и параллели. В Ethereum специальная транзакция типа "create_contract" создаёт в сети адрес, к которому привязан код конкретного контракта. У этого адреса также есть баланс эфира. Если послать туда эфир — адрес «примет его на баланс». И наоборот, если выслать с адреса эфир — тот «снимется с баланса».



Я сразу накидаю несколько довольно точных аналогий для понимания весьма простой и логичной кухни. Если забыть о консенсусе и о том, как ноды обновляют цепочку блоков, и рассматривать блокчейн как абстрактное хранилище, то размещение контракта можно сравнить, например, с инстанцированием объекта, то есть превращением класса в реальный объект в оперативной памяти. В аналогии память — это блокчейн, а код класса — код контракта. После инстанцирования объект (контракт) получает собственный адрес в «памяти», и сети известен интерфейс к нему, представленный в виде описанных в классе методов.



Приходящие на адрес транзакции в такой схеме — это методы-writer’ы, они изменяют внутреннее состояние объекта контракта. Методы-reader’ы, которые просто читают данные из состояния контракта, любой клиент сети выполняет локально, ибо уверен, что его копия объекта верна и подтверждена консенсусом block-producer’ов. Очень важно также понимать, что код контракта выполняется тогда, когда майнер «применяет» пришедшую транзакцию к существующему контракту, а в нашем варианте — попросту вызывает один из методов контракта с аргументами, вложенными в транзакцию.



Ну а раз у контракта есть внутреннее состояние (поля объекта в нашей аналогии), то он может реализовывать мультисиг без необходимости присылать подписи одной транзакцией. Создаём контракт, в нём хардкодим адреса подписантов, когда приходят транзакции на вывод — переводим контракт последовательно в состояние ожидания нужного числа подтверждений. Если речь идёт о multisig 2/3, всё может выглядеть примерно так:




  • сисадмин деплоит в сеть multisig-контракт и кладёт в него адреса генерального директора и главного бухгалтера;

  • счастливые клиенты шлют тонны эфира в контракт;

  • главный бухгалтер собирается сделать большой платёж и шлёт в контракт транзакцию с желанием перевести сколько-то эфира на внешний адрес;

  • multisig-контракт переходит в состояние «ожидаю N подтверждений», в нашем случае достаточно одного;

  • генеральный директор хочет помочь главному бухгалтеру, но забыл, в каком ноутбуке нужный секретный ключ;

  • сисадмин шлёт транзакцию — подтверждение вывода средств в контракт;

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



В зависимости от реализации multisig-контракта много вещей можно реализовать по-разному. Это касается складирования неисполненных заявок на вывод, интервала времени ожидания вывода, удобных ограничений. Например, можно разрешать выводить суммы до определённого лимита без мультиподписи и требовать подтверждения, если лимит превышен.



Есть несколько вариантов кода контрактов multisig-кошельков, вы без проблем найдёте их. Самый официальный из них этот: [url=https://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol]https://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol. Существует ещё множество модификаций multisig-контрактов, а также контракты, которые представляют собой multisig, но даже не знают об этом, ибо любой контракт с несколькими ролями в философском смысле и есть multisig.



Заключение



Мы рассмотрели схему работы одного из самых важных кирпичиков для построения сложных систем контрактов и организации многосторонних сделок. Где проще всего пощупать multisig-адреса вживую:




  • для Bitcoin: в кошельке Electrum есть подробная пошаговая инструкция со скриншотами, как создать и сконфигурировать multisig-адрес и как им воспользоваться. Просто поищите «Electrum multisig»;




  • для Ethereum: в стандартном кошельке «Ethereum wallet» есть раздел «Contracts», и там можно легко создать multisig. Также multisig наверняка будет во многих видах представлен на платформах для запуска стандартных контрактов, например на нашей Smartz.io сейчас уже один есть.



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



Источник: Хабр / Интересные публикации

Категория: Криптография

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *