Универсальный cмарт-контракт мультиподписи в Ethereum

Несколько дней назад мы в компании BitClave ^[1] прочли о недавнем инциденте с мультиподписными кошельками ^[2] компании Parity Technologies, решили пригляделся к коду их смарт-контракта. Свежий пост ^[3] в блоге компании Zeppelin Solutions детально описывает произошедший инцидент с технической стороны, поэтому мы хотели бы в нашей статье больше сфокусироваться на принципах проектирования смарт-контрактов.

Есть несколько широко известных принципов ООП, входящих в аббревиатуру SOLID ^[4]:

• Single responsibility principle ^[5] (принцип единственной ответственности ^[6])
• Open/closed principle ^[7] (принцип открытости/закрытости ^[8])
• Liskov substitution principle ^[9] (принцип подстановки Барбары Лисков ^[10])
• Interface segregation principle ^[11] (принцип разделения интерфейса ^[12])
• Dependency inversion principle ^[13] (принцип инверсии зависимостей ^[14])

Есть множество приверженцев и противников использования этих принципов, но мы просмотрели множество библиотек на языке Solidity и пришли к выводу, что подход Zeppelin Solutions является наиболее удобным и безопасным. Их библиотека OpenZeppelin.org ^[15] предоставляет множество небольших смарт-контрактов, которые могут быть скомпилированы для достижения более сложного поведения по паттерну примесей ^[16] (англ. mixin ^[17]) через использование множественного наследования в языке Solidity. Вам необходимо произвести декомпозицию обязанностей вашего финального смарт-контракта на множество смарт-контрактов с единственными ответственностями – каждый смарт-контракт должен служить единственной цели. Причем часть необходимых вам контрактов вы скорее всего обнаружите в библиотеках вроде той, что предлагает компания Zeppelin Solutions. Помимо всего прочего вы к тому же сможете протестировать каждый из контрактов по отдельности.

Руководствуясь этими принципами мы разработали смарт-контракты для проведения распродажи токенов: github.com/bitclave/crowdsale ^[18]. Вы можете заметить в репозитории смарт-контракты BonusCrowdsale и TokensCappedCrowdsale, которые были разработаны таким образом чтобы обрабатывать такие аспекты нашей распродажи, как обработку бонусов участников в зависимости от времени и суммы инвестиций, а также контролировать суммарное число продаваемых токенов. На наш код мы получили довольно хвалебный отзыв аудитора безопасности смарт-контрактов:

«Великолепная работа по повторному использованию существующих контрактов библиотек OpenZeppelin! Дополнительные контракты выглядят очень продуманно спроектированными и выглядят хорошим расширением этого фреймвока» («Great work reusing the existing OpenZeppelin libraries! The additional contracts are very thoughtfully designed, and are a good extension of the framework») — Zeppelin Solutions. С полным заключением можно ознакомиться по ссылке ^[19].

Для того чтобы успешно применять эти принципы на практике необходимо четко понимать как именно работает множественное наследование. На деле компилятор Solidity преобразует множественное наследование в одиночное наследование. Таки образом после компиляции у каждого смарт-контракта будет всего 1 родитель, обращаться к которому можно через ключевое слово super. Возможно следующий пример дополнительно поможет понять как именно работает линеаризация множественного наследования C3 ^[20]:

contract A { }
contract B { }
contract C is A, B { } // C(A,B) = ABC
contract D is C, A { } // D(C(A,B),A) = D(ABC,A) = ABCAD !!! Error !!!
contract E is A, C { } // E(A,C(A,B)) = E(A,ABC) = ABCE

Проблема в том, что смарт-контракт A не может переопределять C, потому что C переопределяет B, который в свою очередь переопределяет A:

TypeError: Linearization of inheritance graph impossible
contract D is C, A { }
^ — — — — — — — — — — ^
Compiliation failed. See above.

Так же необходимо учитывать, что любое непосредственное наследование контрактов может быть превано в процессе наследования дочерних классов. Обратите внимание, как в следующем примере компилируется контракт W, и его родительский контракт Z становится наследником контракта Y(который является наследником X), вместо непосредственного наследования от X:

contract X {}
contract Y is X {}    // Y(X) = XY
contract Z is X {}    // Z(X) = XZ
contract W is Y, Z {} // W(Y(X),Z(X)) = W(XY, XZ) = XYZW

Возвращаясь к смарт-контракту мультиподписного кошелька Parity Technologies мы ообратили внимание, что он совершенно не декомпозирован. Единственное архитектурное решение замеченное нами: вынос общего кода всех кошельков в единую библиотеку с целью уменьшить стоимость загрузки контракта. Кстати, именно эта особенность и позволила случайному разработчику нарушить работу всех кошельков, сломав единственную библиотеку с общим кодом. Мы поразмышляли на тему множественного владения ресурсом и подготовили своё решение этой задачи в манере библиотек OpenZeppelin. Мы рады представить вам
контракт Multiownable.sol ^[21], который позволит вам с легкостью добавить функциональность мультиподписи в любые ваши контракты. Его использование так же просто как и использование обычного контракта Ownable — нужно лишь отнаследоваться от него и добавить модификаторы onlyAnyOwner и onlyManyOwners к необходимым функциям:

contract SimplestMultiWallet is Multiownable {
    function transferTo(address to, uint256 amount) onlyManyOwners {
        to.transfer(amount);
    }
}

Метод transferTo смарт-контракта будет вызван только после того как все владельцы кошелька вызовут его с одинаковыми аргументами. Вы не поверите, но это полный код простейшего мультиподписного кошелька для валюты Эфир. Дополнительно можно реализовать поддержку любых токенов совместимых со спецификацией ERC20, вот такой метод:

function transferTokens(address token, address to, uint256 amount) onlyManyOwners {
    ERC20(token).transfer(to, amount);
}

Будем рабы любому фидбеку сообщества: github.com/bitclave/Multiownable ^[21]

Автор: Антон Буков

Источник ^[22]