Несколько дней назад мы в компании BitClave прочли о недавнем инциденте с мультиподписными кошельками компании Parity Technologies, решили пригляделся к коду их смарт-контракта. Свежий пост в блоге компании Zeppelin Solutions детально описывает произошедший инцидент с технической стороны, поэтому мы хотели бы в нашей статье больше сфокусироваться на принципах проектирования смарт-контрактов.
Есть несколько широко известных принципов ООП, входящих в аббревиатуру SOLID:
S
ingle responsibility principle (принцип единственной ответственности)O
pen/closed principle (принцип открытости/закрытости)L
iskov substitution principle (принцип подстановки Барбары Лисков)I
nterface segregation principle (принцип разделения интерфейса)D
ependency inversion principle (принцип инверсии зависимостей)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. С полным заключением можно ознакомиться по ссылке.
super
. Возможно следующий пример дополнительно поможет понять как именно работает линеаризация множественного наследования C3: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
Ownable
—?нужно лишь отнаследоваться от него и добавить модификаторы onlyAnyOwner
и onlyManyOwners
к необходимым функциям:contract SimplestMultiWallet is Multiownable {
function () payable { }
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);
}
К сожалению, не доступен сервер mySQL