Комментарии 17
Интересно, а для Solidity IDE со статическим анализатором ещё не придумали? Штуки вроде block.blockhash(block.number) бегут ловятся статически.
Нагуглил Solhint, который что-то умеет. В частности, ругается на любое использование block.blockhash
. Это, конечно, слишком глупо, но лучше чем ничего. И даже плагин к IDEA имеется.
Вопрос лишь в экономике
может искать такое решение которое даст такой хеш блока
Только если он может влиять на результат (что есть нонсенс, и исключено при правильно построенной схеме того же «коммит-раскрытия»).
Например, если все "ходы + сиды" каждого "игрока" (включая майнера если он тоже играет) во первых подписаны заранее (до опубликования/раскрытия сидов), во вторых ему неизвестны (он знает только их подписи), то он при всём желании не сможет повлиять на результат, от слова никак. Даже взлом SHA1 над сообщением 50% мое / 50% чужое (майнер против конторы) НО с последующим подбором его нового сида под уже готовую (им же заранее сделанную подпись) связан просто с чудовищными затратами (и временными, и ресурсными).
И если вообще реализуемо (в случае какого-нибудь доступного вектора атаки при ошибке проектирования), то как минимум затягивается (очень и очень надолго), т.е. вызывает подозрение у всех участников контракта. Т.е. кроме сомнительного результата, он еще и рискует доверием к нему как к честному майнеру.
Однако если хоть одна сторона откажется сообщить своё начальное число, то сервис даёт сбой.
А нельзя просто выкидывать из участия тех, кто не раскрыл число? Или тогда появляется возможность манипулирования через кучу аккаунтов и раскрытием определённого их числа?
Те кто не раскрыл свое число должны точно определяться. Транзакция может зависнуть в мемпуле и на это тоже можно повлиять, повышая стоимость газа и заливая в сеть новые транзакции.
Им бы хотелось но нет. Каждый майнер выполняет все транзакции сам, все параллельно делают одно и тоже. 10 майнеров или 1000 — вычислительная мощность сети не меняется. Вы не можете загрузить код который не сможет выполнить одна нода (точнее можете но либо ноды его отбросят либо вы потратите кучу бабла и вся сеть слегка встанет) То есть распределенных вычислений в эфире нет в принципе. И вряд ли будут при текущей схеме оплаты газом. Она собственно и введена для того что бы не заморачиваться на проблему тьюринга и сделать ресурсоемкие вычисления дорогими.
Однако ECDSA нельзя использовать в Signidice, поскольку контора может манипулировать входными параметрами (в частности, параметром k) и так влиять на получающуюся в результате подпись.
Можно её использовать… Всё дело в том, как именно...
… эта подпись затем используется для генерации случайного числа.
Если у вас есть еще один (второй) seed и энтропия его достаточно высока (пусть даже от urandom), даже простейшего миксина с этим вторым рандом НО уже после получения смарт-контракта от первой даже и "неблагонадежной" конторы будет достаточно, чтобы манипуляции этой конторы (не знающей заранее второй seed) не смогли оказать никакого предсказуемого влияния на конечный результат.
Т. е. грубо алгоритм выглядит так:
- Игроком генерируется случайный Pseed, но не публикуется, а подписывается его приватным ключом, после чего эта подпись Ps(Pseed) вместе со ставкой вызывает смарт-контракт.
- ...
- … все как в схеме выше ...
- ...
- Игрок публикует свой Pseed, который:
5.а. во первых, проверяется с помощью известного открытого ключа игрока и его ранее опубликованной подписью Ps(Pseed).
5.б. во вторых "замешивается", например AES-упаковкой, с подписью полученной от смарт-контракта, в результате создавая реальное случайное число.
5.в. подшивается к следующей транзакции (в качестве прува всей игры).
Т.е. это вовсе НЕ от алгоритма подписи (ECDSA, RSA, etc) собственно зависит, а от способа передачи информации от всех участвующих сторон, в идеальном случае — неизвестной ни одной из сторон до конца (до конечного опубликования).
Все остальные варианты от лукавого страдают тем же, что и в той ошибке от DAO.Casino, если не сейчас, то несколько позже, когда сложность алгоритма упадёт и/или появится какой-нибудь интересный/реализуемый вектор атаки.
Предсказание случайных чисел в умных контрактах Ethereum