Pull to refresh

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 защититься очень просто. Достаточно запускать свои транзакции через контракт-прокси.
А поподробнее? Не забываем, что я могу увидеть конечный эффект любой незамайненой транзакции, применив ее к текущему состоянию БЧ, как бы глубоко обфусцирована она ни была.
Согласен. Если прогнать в симуляторе все транзакции из txpool, то да, можно найти искомый CALL и его «опередить».
Вместо curl раз в 10 быстрее и безопаснее использовать чтение и запись в пайпы geth.ipc или parity.ipc
Это же пример просто :)

Но все же. Чем ipc безопасне rpc в этих условиях?
К ipc возможен доступ только с локальной машины, а rpc открыт для всех. Если на rpc включены api для отправки транзакций, то ими может воспользоваться любой желающий.
Либо можно заддосить ноду тяжелыми запросами по RPC, например, из разряда debug_*, либо eth_call, eth_compile
а rpc открыт для всех

Это же как запустишь, можно на localhost. Я так и делалаю всегда…
UFO just landed and posted this here
«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, а посылать новый блок с другого, на котором он вообще не слушает никакие порты.

Хорошая мысль, согласен.
В ванильной сборке такой функциональности нет. Можно подхачить немного в месте где валидируется блок и выводить на консоль не только его номер но и ip с коротого пришел…
ethereum.stackexchange.com/questions/34988/honest-lottery-winner-generation-pseudo-random-number-obtaining

Вот тут предлагал вариант для розыгрыша в лотерею. Относительно безопасного.

Комбинация использования blockhash с идеями commit-reveal.
1. На старте организатор задает некое число — ключ которое будет использоваться при розыгрыше. И выдает его хэш (само число до розагрыша закрыто).
2. Для всех покупателей билетов берется blockhash и сохраняется
3. При розыгрыше число выдается организатором и складывается с числами покупателей билетов.
4. результат используется при определении blockhash по которому вычисляется победитель.

Чтобы убрать сомнения в честности организатора каждый может за увеличенную плату тоже забросить свое число (хэш при покупке билета, само число при розыгрыше).

Либо просто купить билет.

Те кто закидывал свое число выдают депозит. При открытии числа депозит возвращается. Билет для них стоит чуть дешевле, чтобы стимулировать выдачу. Если проверяльщик не открывает свое число депозит присоединятеся к розыгрышу из оставшихся. Если организатор не открывает число всем возвращаются деньги.
Нет. После указания способа было добавлено в описание алгоритма — возможность каждого покупателя билета заложить key number. Это не даст организатору читить т.к. он не знает этого числа.
Sign up to leave a comment.