Comments 21
Спасибо за статью, ждем последующие части. К теме front-running в биржах можно добавить хороший пример такой проблемы в Bancor: https://hackernoon.com/front-running-bancor-in-150-lines-of-python-with-ethereum-api-d5e2bfd0d798.
Для поиска уязвимостей в PRNG реализациях на Solidity можно использовать простое правило: если случайное число получается в той же транзакции, когда определяется победитель, то такой алгоритм определенно уязвим.
Да, про bancor статья хорошая. Я указал ее в статье :) Видимо стоит более явно давать ссылки. Учту)
Похоже на то, хорошего решения нет в одну транзакцию вообще нет. Я думаю, максимум что можно достигнуть — в один блок.
если случайное число получается в той же транзакции, когда определяется победитель, то такой алгоритм определенно уязвим.
Похоже на то, хорошего решения нет в одну транзакцию вообще нет. Я думаю, максимум что можно достигнуть — в один блок.
А вот хорошая идея защиты от front running: hackingdistributed.com/2017/08/28/submarine-sends
От front-running защититься очень просто. Достаточно запускать свои транзакции через контракт-прокси.
Вместо curl раз в 10 быстрее и безопаснее использовать чтение и запись в пайпы geth.ipc или parity.ipc
Это же пример просто :)
Но все же. Чем ipc безопасне rpc в этих условиях?
Но все же. Чем ipc безопасне rpc в этих условиях?
К ipc возможен доступ только с локальной машины, а rpc открыт для всех. Если на rpc включены api для отправки транзакций, то ими может воспользоваться любой желающий.
Либо можно заддосить ноду тяжелыми запросами по RPC, например, из разряда debug_*, либо eth_call, eth_compile
Либо можно заддосить ноду тяжелыми запросами по RPC, например, из разряда debug_*, либо eth_call, eth_compile
«Front-running» (к слову сказать, он всё же без дефиса) уже давно переводится и как «опережающая сделка», и как «сделка на опережение», и даже как «игра на опережение». Выбирайте любой.
Если их более 25, то придется принудительно рвать соединения до известных IP, например, с помощью iptables, и так собрать их все.
А сколько их? Например, у меня постоянно запущена нода rinkeby. Есть подозрение, что порядок величины — десятки тысяч и более. Трудоемкая задача получается.
Как вариант защиты — майнеру отправлять блоки с write-only ноды. Тогда ддосать придется ip целиком.
Есть подозрение, что порядок величины — десятки тысяч и более
Зачем тясячи то? десятка за глаза
майнеру отправлять блоки с write-only ноды. Тогда ддосать придется ip целиком
вот это вообще не понял
Зачем тясячи то? десятка за глаза
Насколько понимаю, Вами предлагается найти всех майнеров, перебрав участников сети. Подозреваю, участников сети десятки тысяч и более — трудно будет искать майнеров. Или можно определить их ip, не перебирая всех участников?
майнеру отправлять блоки с write-only ноды
Уточню: майнер может «читать» сеть с одного ip, а посылать новый блок с другого, на котором он вообще не слушает никакие порты.
Подозреваю, участников сети десятки тысяч и более — трудно будет искать майнеров
Да, это не так понял сначала. Действительно участников может быть много. Но тут 2 фактора:
- 25 это софтварное ограничение клиентов сети (geth, parity). Его можно естественно повысить до тех что позволяет ОС и железо (как раз порядки тысяч)
- В сетях чуть более закрытых чем rinkbey (типо PoA network) учасников будет еще меньше (может и меньше 25)
Уточню: майнер может «читать» сеть с одного ip, а посылать новый блок с другого, на котором он вообще не слушает никакие порты.
Хорошая мысль, согласен.
ethereum.stackexchange.com/questions/34988/honest-lottery-winner-generation-pseudo-random-number-obtaining
Вот тут предлагал вариант для розыгрыша в лотерею. Относительно безопасного.
Комбинация использования blockhash с идеями commit-reveal.
1. На старте организатор задает некое число — ключ которое будет использоваться при розыгрыше. И выдает его хэш (само число до розагрыша закрыто).
2. Для всех покупателей билетов берется blockhash и сохраняется
3. При розыгрыше число выдается организатором и складывается с числами покупателей билетов.
4. результат используется при определении blockhash по которому вычисляется победитель.
Чтобы убрать сомнения в честности организатора каждый может за увеличенную плату тоже забросить свое число (хэш при покупке билета, само число при розыгрыше).
Либо просто купить билет.
Те кто закидывал свое число выдают депозит. При открытии числа депозит возвращается. Билет для них стоит чуть дешевле, чтобы стимулировать выдачу. Если проверяльщик не открывает свое число депозит присоединятеся к розыгрышу из оставшихся. Если организатор не открывает число всем возвращаются деньги.
Вот тут предлагал вариант для розыгрыша в лотерею. Относительно безопасного.
Комбинация использования blockhash с идеями commit-reveal.
1. На старте организатор задает некое число — ключ которое будет использоваться при розыгрыше. И выдает его хэш (само число до розагрыша закрыто).
2. Для всех покупателей билетов берется blockhash и сохраняется
3. При розыгрыше число выдается организатором и складывается с числами покупателей билетов.
4. результат используется при определении blockhash по которому вычисляется победитель.
Чтобы убрать сомнения в честности организатора каждый может за увеличенную плату тоже забросить свое число (хэш при покупке билета, само число при розыгрыше).
Либо просто купить билет.
Те кто закидывал свое число выдают депозит. При открытии числа депозит возвращается. Билет для них стоит чуть дешевле, чтобы стимулировать выдачу. Если проверяльщик не открывает свое число депозит присоединятеся к розыгрышу из оставшихся. Если организатор не открывает число всем возвращаются деньги.
Sign up to leave a comment.
Attention! S in Ethereum stands for Security. Part 1. Blockchain things