Comments 11
Bitcoin script не полнотьюринговый, язык смарт контрактов BitShares не полнотьюринговый. Каждйы для своей области ограничены и детерминистичны. Язык smart-контрактов должен быть детерминистичным, иначе это катастрофа. В этом году из за кривых контрактов уже 6 проблем на всю сеть было. Solidity ЯП на блокчейне, с соответствующими тормозами. Имея тюринг-полный ЯП, всегда можно найти возможность создать неявную проблему в смарт-контракте.
Но в функции
transferOwnership есть цикл, число итераций которого может оказаться порядка тысячи и более:for (i = 0; i < allPendingOperations.length; i++) {что приведет к достижению лимита газа блока и невозможности поменять владельцев контракта.
Мультиподпись ethereum wallet также этим страдает (функция
clearPending).В своей мультиподписи на базе МП ethereum wallet мы ввели принудительный сброс pending-операций в потенциально опасной ситуации, но я считаю это временным решением — планируем переработать алгоритм сброса в итерационный, который адаптивно учитывает
msg.gas.
Спасибо за ваш комментарий, думал насчёт этой проблемы. И видится мне нужно просто ограничить число операций. Можно конечно добавить еще один маппинг для исключения обхода цикла.
Что скажете про такой способ ухода от циклов по операциям? https://github.com/bitclave/Multiownable/pull/2
Вынесение всех переменных в структуру не помогло. При пересоздании структуры внутренние маппинги не очищаются! Зато помогли вложенные маппинги, первым ключом которых является фактически номер версии, которая растет при каждой передачи прав владения.
По идее можно убрать вложенные маппинги и операцию считать как хеш от мсгдата и поколения. Это снизит использование газа. С другой стороны непонятно насколько плохая идея не очищать маппинг, а только засорять его. С другой стороны методы для очистки то имеются и работают без циклов.
Универсальный cмарт-контракт мультиподписи в Ethereum