Возможно, немного не понял вас, но попробую какой-то контекст выдать: 1) При вызове от EOA -> SC, механизм ограничения опирается только `gasLimit` в самой транзакции, а вот если при выполнении транзакции предполагается execute логики в контракте, в котором происходит вызов из 1 контракта в другой с помощью low level .call(), то расходуется 64/65 газа, направленного вместе с .call(), там же можно ставить ограничения на кол-во газа направляемого на выполнение кода в другом контракте.
2) Есть большое количество gas griefing векторов атак, при которых юзеры могут специально заполнять, допустим, массивы объектов, чтобы при итерации по ним, условно админ терял очень много газа. Предположим, юзер вызывает функцию в смарт-контракте, который печатает ему фантики за депозит эфира. Допустим, есть еще пара на dex, где эти фантики можно приобрести с небольшой наценкой(тк. чтобы их получить, нужно потратиться на газ). И если есть возможность каким-то образом сделать так, чтобы функция депозита начала потреблять вдвое больше газа, то цена на dex на эти фантики вырастет(ибо lp провайдерам нужно больше денег за газ платить, чтобы печатать фантики). На таких вещах могут строиться всякие профитные стратегии.
3) Можно симулировать транзакции перед отправкой на текущем стейте эфира, и это на самом деле хорошая практика.
У меня вопрос, не только к автору, буду очень благодарен услышать разные мнения...
Вот вы сами андроид разработке, учились как? Смотря за тем, как кто-то другой что-то делает или брали документацию и расширяли свои знания, подкрепляя это на практике? Мне кажется, что первый вариант более актуален, но с другой стороны - менее эффективен, возможно, ошибаюсь...
Спасибо, у нас была лабораторная в вузе, просто считать грани и выдать последовательность ходов, либо какое-нибудь исключение, характеризующее невалидность входных данных. Так вот, я за целый день научился собирать его так себе по формулам и напедалил 1к+ кода на плюсах. До сих пор помню то чувство экстаза, когда я нонстопом прогал эту штуку. Еще и в openGL пришлось немного расшарить для графики. В итоге, ушло около 30часов непрерывного труда, но было жутко интересно!
Здравствуйте! Учел ваш комментарий, кажется, статья стала немного лучше выглядеть :) С 1-ым пунктом абсолютно согласен, исправил свою ошибку. Со 2-ым пунктом тоже согласен, но вот попытка объяснить все то, что возможно на неформальном языке, кажется, провалилась :) С 3-им пунктом согласен полностью - поправил.
По исходному графу строим производный граф, который и будем называть остаточной сетью. Остаточная сеть, в отличие от исходного, может иметь обратные ребра. Проще говоря, ребра, по котором можно вернуть жидкость, которую вы отправили из одной точки в другую. То есть, вы не только можете отправлять жидкость из одной точки в другую, но и можете, при необходимости, вернуть.
Советую почитать комментарий сверху, где коллега рассказал про то, для чего нужны обратные ребра.
Я долго думал над этим, а именно стоит ли добавлять реализацию!? Но потом решил, что не стоит, ибо идея самой статьи - изложить саму сущность алгоритма на очень примитивном уровне. С минимальным уровнем математики и формального языка. Если хотите углубиться в алгоритм, то можете посмотреть лекцию Павла Маврина на ютубе по этой теме. Всего хорошего! :)
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Возможно, немного не понял вас, но попробую какой-то контекст выдать:
1) При вызове от EOA -> SC, механизм ограничения опирается только `gasLimit` в самой транзакции, а вот если при выполнении транзакции предполагается execute логики в контракте, в котором происходит вызов из 1 контракта в другой с помощью low level .call(), то расходуется 64/65 газа, направленного вместе с .call(), там же можно ставить ограничения на кол-во газа направляемого на выполнение кода в другом контракте.
2) Есть большое количество gas griefing векторов атак, при которых юзеры могут специально заполнять, допустим, массивы объектов, чтобы при итерации по ним, условно админ терял очень много газа. Предположим, юзер вызывает функцию в смарт-контракте, который печатает ему фантики за депозит эфира. Допустим, есть еще пара на dex, где эти фантики можно приобрести с небольшой наценкой(тк. чтобы их получить, нужно потратиться на газ). И если есть возможность каким-то образом сделать так, чтобы функция депозита начала потреблять вдвое больше газа, то цена на dex на эти фантики вырастет(ибо lp провайдерам нужно больше денег за газ платить, чтобы печатать фантики). На таких вещах могут строиться всякие профитные стратегии.
3) Можно симулировать транзакции перед отправкой на текущем стейте эфира, и это на самом деле хорошая практика.
В правилах написано, что любая игра в онлайн казино - это игра с отрицательным мат. ожиданием :D
Спасибо за статью, отличная работа!
Не понимаю, почему я 4 года учусь в ИТМО, чтобы писать под Android, когда можно зп 3 месяца "выучить" все
Где тег "Я пиарюсь" ?
И ещё очень сильно бесит то, что вы не пытаетесь понять смысла комментария выше...
У меня вопрос, не только к автору, буду очень благодарен услышать разные мнения...
Вот вы сами андроид разработке, учились как?
Смотря за тем, как кто-то другой что-то делает или брали документацию и расширяли свои знания, подкрепляя это на практике?
Мне кажется, что первый вариант более актуален, но с другой стороны - менее эффективен, возможно, ошибаюсь...
В целом, идея в корне та же самая, а так неплохое решение!
Kudos :D
Good job, thanks!
Спасибо, у нас была лабораторная в вузе, просто считать грани и выдать последовательность ходов, либо какое-нибудь исключение, характеризующее невалидность входных данных. Так вот, я за целый день научился собирать его так себе по формулам и напедалил 1к+ кода на плюсах. До сих пор помню то чувство экстаза, когда я нонстопом прогал эту штуку. Еще и в openGL пришлось немного расшарить для графики. В итоге, ушло около 30часов непрерывного труда, но было жутко интересно!
Спасибо за статью, хоть и мало понял, но зато интересно!
Кто знает, сколько еще лжи в этой статье...(
Работаю над этим, спасибо большое за ваш отзыв!
Добрый день! Спасибо большое за ваш фидбек, статью поправляю!
Здравствуйте! Учел ваш комментарий, кажется, статья стала немного лучше выглядеть :)
С 1-ым пунктом абсолютно согласен, исправил свою ошибку.
Со 2-ым пунктом тоже согласен, но вот попытка объяснить все то, что возможно на неформальном языке, кажется, провалилась :)
С 3-им пунктом согласен полностью - поправил.
Огромное спасибо, без вас бы данная опечатка осталась бы незамеченной! :D
Уже поправил!
Попробую объяснить.
По исходному графу строим производный граф, который и будем называть остаточной сетью.
Остаточная сеть, в отличие от исходного, может иметь обратные ребра. Проще говоря, ребра, по котором можно вернуть жидкость, которую вы отправили из одной точки в другую. То есть, вы не только можете отправлять жидкость из одной точки в другую, но и можете, при необходимости, вернуть.
Советую почитать комментарий сверху, где коллега рассказал про то, для чего нужны обратные ребра.
Я долго думал над этим, а именно стоит ли добавлять реализацию!?
Но потом решил, что не стоит, ибо идея самой статьи - изложить саму сущность алгоритма на очень примитивном уровне. С минимальным уровнем математики и формального языка.
Если хотите углубиться в алгоритм, то можете посмотреть лекцию Павла Маврина на ютубе по этой теме. Всего хорошего! :)