Еще один свежий 🚸аудит небольшого контракта
***
🔥 [КРИТИЧНЫЕ]
не выявлено
***
❗ [СЕРЬЕЗНЫЕ]
не выявлено
📣 [ПРЕДУПРЕЖДЕНИЯ]
не выявлено
💡 [ЗАМЕЧАНИЯ]
1. Классы из библиотеки openzeppelin-solidity не самой последней версии
Изменения в новых версиях:
— незначительные оптимизации библиотеки SafeMath
— изменена проверка баланса пользователя при отправке токенов — теперь при ошибочном указании неправильного баланса не сжигается весь газ транзакции
2. Событие Transfer при создании токенов
Согласно стандарту при создании новых токенов следует вызывать метод Transfer с отправителем равным адресу 0x0
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md#transfer
> A token contract which creates new tokens SHOULD trigger a Transfer event with the _from address set to 0x0 when tokens are created.
3. Событие Transfer при сжигании токенов
По аналогии предыдущим пунктом в функции `burn` можно добавить вызов события Transfer с адресом назначения, равным address(0).
В библиотеке openzeppelin-solidity сделано именно так: https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/token/ERC20/BurnableToken.sol#L43
4. Тип decimals
Согласно стандарту тип для `decimals` должен быть uint8: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md#decimals
5. Запись больших чисел
Для наглядности и уменьшения риска ошибиться большие числа можно записывать так:
1925000000000000000000000000 = 1925000000 * 10**18
Topic: [Аудит] смарт контракта. Как выглядит отчет ? (Read 125 times)
Как выглядит #аудит #смарт_контракта?
Часто спрашивают или заказчики или молодые команды разработки.
Ниже пример реального отчета по аудиту кода одного из контрактов.
Естественно без имен.
Берите на вооружение.
***
[Что и как делаем]
Код контракта просматривается вручную на наличие известных уязвимостей, ошибок в логике, соответствие WhitePaper. При необходимости на сомнительные моменты пишутся юнит тесты.
***
🔥 [КРИТИЧНЫЕ]
не выявлено
***
❗ [СЕРЬЕЗНЫЕ]
1.
В технических характеристиках токена указано, что контракт токена должен иметь функцию «сожжения». Такая функция реализована, но сжигать можно только свои собственные токены. Судя по тех. характеристикам (остаток нераспроданных токенов можно будет вручную «сжечь» в конце всех мероприятий) должна быть функция сжигания токенов организаторами. Таким образом в текущей версии контракта нераспроданные токены останутся на контракте crowdsale без возможности вывода.
***
📣 [ПРЕДУПРЕЖДЕНИЯ]
1.
В используемой версии контракта StandardToken из библиотеки Zeppelin Solidity была найдена ошибка ошибка https://github.com/OpenZeppelin/zeppelin-solidity/issues/375 , позволяющая генерировать ложное событие о переводе самому себе любого количества токенов, даже превышающющего имеющиеся.
2.
Вероятно, в формуле лишнее деление на 1 ether. при текущей формуле, чтобы установить цену токена в 1 доллар, нужно вызвать метод setRate с параметром 300*10^18. Лучше реализовать rate без такого количества нулей, чтобы было меньше возможностей ошибиться.
3.
Рекомендуем добавить также генерацию события:
Transfer(burner, 0, _value);
для того, чтобы кошельки, etherscan.io и прочие клиенты увидели факт изменения баланса. Без этого, многие инвесторы просто не увидят свои токены в кошельках.
Похожая проблема есть и в конструкторе токена,
Transfer(0, ADDRESS_FOR_TOKENS, INITIAL_SUPPLY);
***
💡 [ЗАМЕЧАНИЯ]
1. Используется не самая последняя версия библиотеки Zeppelin Solidity. Изменения в новой версии:
исправлена ошибка в ф-ции transferFrom контракта StandardToken (см. п.1. предупреждений)
в функциях контрактов явно указаны модификаторы видимости
оптимизация в функции mul из SafeMath, немного уменьшающая потребление газа
в контрактах BasicToken, StandardToken, BurnableToken в функциях transfer, transferFrom и burn добавлены проверки входных параметров, не сжигающие весь газ при неудаче: проверка на перевод на нулевой контракт и на то, что значение для перевода/сжигания меньше баланса и допустимой для перевода суммы
2.
Поле digits в токене обычно делают типа uint8, это поле не описано в ERC20, но было предложено в ERC223 (https://github.com/ethereum/eips/issues/223). В примере на ethereum.org (https://ethereum.org/token) и в библиотеке Zeppelin Solidity в примере (https://github.com/OpenZeppelin/zeppelin-solidity/pull/490) используется именно uint8
Реализовано в<Ссылка>
3. <Ссылка>
В технических характеристиках токена указано, что контракт токена должен иметь такие функции как «Передача прав владельца» и «Являются Ownable». Для контракта токена это не сделано, но может понадобиться, если будет добавлена функция сжигания токенов в контракте самого токена.
4. В механике работы контракта есть упоминание «срока годности» контракта (который составляет 365 дней). Это не реализовано.
5. В комментариях к тех. описанию написано, почему не была реализована подпись тремя людьми действий с контрактами. Обычно, чтобы эти минусы были неактуальны, делают возможным совершать действия, подписанные не всеми владельцами. Например, подписанные двумя владельцами из трех.
6. В комментариях к тех. описанию написано, почему не было реализовано распределение средств на кошельки. Но узнать баланс любого адреса довольно просто: http://solidity.readthedocs.io/en/develop/units-and-global-variables.html#address-related
7. <Ссылка>
Нет проверки на количество переданного эфира, можно купить 0 токенов.
8. <Ссылка>
Заглушки ADDRESS_FOR_TOKENS, ADDRESS_FOR_ETH, START_DATETIME — плохая практика, т.к. потребует модификации кода перед развертыванием, что чревато ошибками.
9. <Ссылка>
modifier onlyOwner избыточен в Crowdsale
10. <Ссылка>
Бессмысленная строчка. Кроме того, rate по-умолчанию равняется 0 и его установка не контролируется перед/во время начала crowdsale — это чревато тем, что если забыть или не успеть его установить, пройдут платежи, за которые будет начислено по 0 токенов.
Необходимо указать в инструкции о необходимости задать rate в этой строке до деплоя контракта и выделить визуально.
Реализовано в <Ссылка>
👉👉👉 Пишите ЛС.
Если что ... )))
Часто спрашивают или заказчики или молодые команды разработки.
Ниже пример реального отчета по аудиту кода одного из контрактов.
Естественно без имен.
Берите на вооружение.
***
[Что и как делаем]
Код контракта просматривается вручную на наличие известных уязвимостей, ошибок в логике, соответствие WhitePaper. При необходимости на сомнительные моменты пишутся юнит тесты.
***
🔥 [КРИТИЧНЫЕ]
не выявлено
***
❗ [СЕРЬЕЗНЫЕ]
1.
В технических характеристиках токена указано, что контракт токена должен иметь функцию «сожжения». Такая функция реализована, но сжигать можно только свои собственные токены. Судя по тех. характеристикам (остаток нераспроданных токенов можно будет вручную «сжечь» в конце всех мероприятий) должна быть функция сжигания токенов организаторами. Таким образом в текущей версии контракта нераспроданные токены останутся на контракте crowdsale без возможности вывода.
***
📣 [ПРЕДУПРЕЖДЕНИЯ]
1.
В используемой версии контракта StandardToken из библиотеки Zeppelin Solidity была найдена ошибка ошибка https://github.com/OpenZeppelin/zeppelin-solidity/issues/375 , позволяющая генерировать ложное событие о переводе самому себе любого количества токенов, даже превышающющего имеющиеся.
2.
Вероятно, в формуле лишнее деление на 1 ether. при текущей формуле, чтобы установить цену токена в 1 доллар, нужно вызвать метод setRate с параметром 300*10^18. Лучше реализовать rate без такого количества нулей, чтобы было меньше возможностей ошибиться.
3.
Рекомендуем добавить также генерацию события:
Transfer(burner, 0, _value);
для того, чтобы кошельки, etherscan.io и прочие клиенты увидели факт изменения баланса. Без этого, многие инвесторы просто не увидят свои токены в кошельках.
Похожая проблема есть и в конструкторе токена,
Transfer(0, ADDRESS_FOR_TOKENS, INITIAL_SUPPLY);
***
💡 [ЗАМЕЧАНИЯ]
1. Используется не самая последняя версия библиотеки Zeppelin Solidity. Изменения в новой версии:
исправлена ошибка в ф-ции transferFrom контракта StandardToken (см. п.1. предупреждений)
в функциях контрактов явно указаны модификаторы видимости
оптимизация в функции mul из SafeMath, немного уменьшающая потребление газа
в контрактах BasicToken, StandardToken, BurnableToken в функциях transfer, transferFrom и burn добавлены проверки входных параметров, не сжигающие весь газ при неудаче: проверка на перевод на нулевой контракт и на то, что значение для перевода/сжигания меньше баланса и допустимой для перевода суммы
2.
Поле digits в токене обычно делают типа uint8, это поле не описано в ERC20, но было предложено в ERC223 (https://github.com/ethereum/eips/issues/223). В примере на ethereum.org (https://ethereum.org/token) и в библиотеке Zeppelin Solidity в примере (https://github.com/OpenZeppelin/zeppelin-solidity/pull/490) используется именно uint8
Реализовано в<Ссылка>
3. <Ссылка>
В технических характеристиках токена указано, что контракт токена должен иметь такие функции как «Передача прав владельца» и «Являются Ownable». Для контракта токена это не сделано, но может понадобиться, если будет добавлена функция сжигания токенов в контракте самого токена.
4. В механике работы контракта есть упоминание «срока годности» контракта (который составляет 365 дней). Это не реализовано.
5. В комментариях к тех. описанию написано, почему не была реализована подпись тремя людьми действий с контрактами. Обычно, чтобы эти минусы были неактуальны, делают возможным совершать действия, подписанные не всеми владельцами. Например, подписанные двумя владельцами из трех.
6. В комментариях к тех. описанию написано, почему не было реализовано распределение средств на кошельки. Но узнать баланс любого адреса довольно просто: http://solidity.readthedocs.io/en/develop/units-and-global-variables.html#address-related
7. <Ссылка>
Нет проверки на количество переданного эфира, можно купить 0 токенов.
8. <Ссылка>
Заглушки ADDRESS_FOR_TOKENS, ADDRESS_FOR_ETH, START_DATETIME — плохая практика, т.к. потребует модификации кода перед развертыванием, что чревато ошибками.
9. <Ссылка>
modifier onlyOwner избыточен в Crowdsale
10. <Ссылка>
Бессмысленная строчка. Кроме того, rate по-умолчанию равняется 0 и его установка не контролируется перед/во время начала crowdsale — это чревато тем, что если забыть или не успеть его установить, пройдут платежи, за которые будет начислено по 0 токенов.
Необходимо указать в инструкции о необходимости задать rate в этой строке до деплоя контракта и выделить визуально.
Реализовано в <Ссылка>
👉👉👉 Пишите ЛС.
Если что ... )))
Jump to: