Мультиподписной кошелек

Этот набор контрактов обеспечивает функциональность «N-из-M мультиподписей»: по крайней мере N сторон из предопределенного набора M подписантов должны одобрить Order для его выполнения.

Каждый Order может содержать произвольное количество действий: исходящие сообщения и обновления параметров. Поскольку содержание сообщений произвольно, Order может выполнять произвольные высокоуровневые взаимодействия на TON: отправка TON, отправка/чеканка жетонов, выполнение административных обязанностей и т.д.

⚠️ Multisig не ограничивает содержание действий Order, поэтому Order может включать в себя абсолютно любые действия, включая те, которые создают новые multisig заказы или утверждают существующие multisig заказы или изменяют конфигурацию multisig (например, список подписантов).

UI и другие инструменты для работы с multisig должны полностью анализировать содержимое заказов и четко сообщать обо всех действиях, которые будут выполнены заказом. Такие инструменты также должны явно сообщать об ошибках парсинга или действиях неизвестного типа.

Подписанты должны одобрять заказ только после полного прочтения его содержания.

⚠️ Пользовательский интерфейс multisig должен отображать все созданные и невыполненные заказы (их можно найти в исходящих сообщениях multisig), а также соответствие их списка подписантов текущему списку исполнителей multisig, чтобы пользователи четко видели все активные заказы, которые могут быть выполнены.

Такие параметры, как пороговое значение N, список signers и другие, могут быть обновлены только с согласия текущих владельцев N-из-M.

Любой signers может предложить новый Order. Кошелек Multisignature также позволяет назначать роль proposer: proposer может предлагать новые заказы, но не может их утверждать.

Каждый Order имеет срок действия, по истечении которого он не может быть исполнен.

Каждый signer может быть кошельком, аппаратным кошельком, мультиподписывать себя, а также другими смарт-контрактами со своей собственной логикой.

Этот кошелек Multisignature был разработан с учетом требований Safe{Wallet} .

Гарантии

• Никто, кроме лиц, proposers и signers, не может инициировать создание нового распоряжения, никто, кроме лиц, signers, не может одобрить новый распоряжение.
• Изменение набора signers делает недействительными все заказы с другим набором. Строго говоря, заказ действителен только тогда, когда текущие signers Multisig равны signers заказа.
• Компрометация signers, в частности, компрометация менее signers.length - N , не препятствует выполнению заказов или предложению новых (включая заказы, которые удалят скомпрометированных signers из списка подписантов)
• Компрометация Proposer не препятствует выполнению заказов или предложению новых (включая заказы, которые удалят скомпрометированного Proposer из списка предлагающих)
• Логика кошелька с мультиподписью не может быть изменена после развертывания

Архитектура

Вся система состоит из четырех частей:

• Signers (Подписанты) — независимые деятели, которые утверждают исполнение приказов.
• Proposers (Предлагающие) — вспомогательные деятели, которые могут предлагать новые приказы для исполнения.
• Multisig — контракт, который выполняет утвержденные заказы, таким образом, это адрес, которому будут принадлежать активы и разрешения; контракт Multisig также хранит информацию о количестве заказов, текущих наборах подписавших и предлагающих лиц.
• Orders (Заказы) - дочерние контракты, каждый из которых содержит информацию об одном заказе: содержание заказа и утверждения.

Поток выглядит следующим образом:

1. Предлагающий новый заказ (адрес из наборов Предлагающих или Подписавших) создает новый заказ, который состоит из произвольных числовых переводов с адреса Multisig и отправляет запрос в Multisig для начала утверждения этого заказа.
2. Multisig получает запрос, проверяет, что он отправлен уполномоченным субъектом, и развертывает дочерний субконтракт Order, содержащий содержимое заказа.
3. Подписанты независимо отправляют сообщения об одобрении заказа на контракт
4. Как только заказ получает достаточное количество одобрений, он отправляет запрос на выполнение заказа в Multisig.
5. Мультиподпись подтверждает подлинность заказа (что он действительно отправлен заказом, а не кем-то другим), а также что набор подписантов все еще актуален, и выполняет заказ (отправляет переводы из заказа)
6. Если заказу необходимо более 255 переводов (лимит переводов за один tx), избыточные транзакции могут быть упакованы в последний перевод из Multisig в ​​себя как
   internal_execute
7. Multisig получает
   internal_execute
   , проверяет, что он отправлен от себя, и продолжает выполнение.

Все комиссии за обработку заказа (за исключением самого исполнения заказа): создание договора заказа и комиссии за его хранение несет лицо, предлагающее этот заказ (будь то Предлагающая сторона или Подписант).

Помимо переводов, заказ может также содержать запросы на обновление Multisig.

Структура проекта

• contracts
  - исходный код всех смарт-контрактов проекта и их зависимостей.
• wrappers
  - классы-оболочки (реализованные Contract из ton-core) для контрактов, включая любые примитивы [де]сериализации и функции компиляции.
• tests
  - тесты по контрактам.
• scripts
  - скрипты, используемые проектом, в основном скрипты развертывания.

Как использовать

Сборка

или

yarn blueprint build

Тест

или

yarn blueprint test

Развернуть или запустить другой скрипт

или

yarn blueprint run

используйте API Toncenter:

API_KEY можно получить на https://toncenter.com или https://testnet.toncenter.com

Примечания:

• Пороговое значение должно быть > 0 и <= signers_num.

• По замыслу заказы смарт-контрактов не уведомляют об обновлении конфигурации мультиподписи (подписавший, предлагающие, пороговое число). Такой заказ будет продолжать принимать одобрения, но при исполнении он будет отклонен, поскольку конфигурация мультиподписи изменилась.

• Баланс TON просроченного ордера можно вернуть в multisig. Для этого ордер должен собрать достаточно одобрений - он будет отправлен на исполнение, исполнения не будет, но TON будут возвращены в multisig.

• approve_accepted
  - Вспомогательное уведомление не отправляется, если заказ инициализируется и выполняется немедленно (approve_on_init с порогом = 1).