Comments 8
Учитывая все эти числа, мы можем вспомнить, что создание контракта — это единовременный процесс, поэтому могу заключить, что оптимизация развёртывания смарт-контрактов не является сейчас важным вопросом для Ethereum. Уверен, что ещё вернусь к этому вопросу в будущем, а сейчас есть ещё много интересных проблем оптимизации, связанных с байт-кодом самих контрактов.
Мне в практике достаточно часто попадаются огромные, монолитные контракты, деплой которых не помещается в блок. Это я просто к возможным темам)
На прошлой неделе Alex Beregszaszi упомянул сжатие в контексте экономии газа, но для больших контрактов это может быть одним из решений github.com/ethereum/solidity/issues/3432
Спасибо за идею темы! Надо будет поискать подобные контракты. А начать можно с построения графа связей между контрактами, если этого уже кто-нибудь не сделал.
Спасибо за идею темы! Надо будет поискать подобные контракты. А начать можно с построения графа связей между контрактами, если этого уже кто-нибудь не сделал.
Название «Экономия газа в смарт-контрактах Ethereum» наталкивает на мысль, что статья будет об экономии газа при работе контракта.
Ну а по сути вопроса:
О чем стоит помнить:
1)Экономить на газе можно создавая новые экземпляры контракта из уже загруженного байт-кода. И/или используя в контракте байткод библиотек уже загруженных в эфир. Но тут главное, чтобы не получилось как с Parity
2)Стараться не усложнять. За «грамотное ООП» придется платить.
3)Подумать о том чтобы больше вынести оффчейн. В конечном итоге, когда кто-то с вами вступает в отношения с использованием контракта — скорее всего без действий с вашей стороны всё-равно работать не будет, а значит и офчейн вполне может быть подходящим решением.
4)Чем больше для выполнения метода контракта потребуется газа — тем выше будет gas price. Дело в том что у каждого блока в блокчейне есть лимит газа и как следствие то количество операций которое может быть выполнено. А значит если для выполнения метода вам требуется 10% всего газа блока, то в условии высокой конкуренции (как с недавними криптокотиками, например) — чтобы получить такое количество газа — придется заплатить за него дороже чем участникам с менее прожорливыми транзакциями
Ну а по сути вопроса:
О чем стоит помнить:
1)Экономить на газе можно создавая новые экземпляры контракта из уже загруженного байт-кода. И/или используя в контракте байткод библиотек уже загруженных в эфир. Но тут главное, чтобы не получилось как с Parity
2)Стараться не усложнять. За «грамотное ООП» придется платить.
3)Подумать о том чтобы больше вынести оффчейн. В конечном итоге, когда кто-то с вами вступает в отношения с использованием контракта — скорее всего без действий с вашей стороны всё-равно работать не будет, а значит и офчейн вполне может быть подходящим решением.
4)Чем больше для выполнения метода контракта потребуется газа — тем выше будет gas price. Дело в том что у каждого блока в блокчейне есть лимит газа и как следствие то количество операций которое может быть выполнено. А значит если для выполнения метода вам требуется 10% всего газа блока, то в условии высокой конкуренции (как с недавними криптокотиками, например) — чтобы получить такое количество газа — придется заплатить за него дороже чем участникам с менее прожорливыми транзакциями
Название «Экономия газа в смарт-контрактах Ethereum» наталкивает на мысль, что статья будет об экономии газа при работе контракта.
Обязательно доберусь и до этой темы. Там много всего интересного. Будем "поедать слона частями".
О чем стоит помнить:
Полезные замечания. Спасибо. Культура программирования на Solidity всё ещё формируется, и многие учатся лишь на собственных "шишках". К счастью, всё чаще используют наработки и сложившиеся практики.
Думаю, что начинать следует с оценки и подходов к трансформации бизнеса в контексте блокчейна. А в этом вопросе сейчас очень много неизвестных.
Лучше бы и правда газ экономили, который сжигается, чтобы электричество выработать, которое расходуется на все эти расчёты. :) Вот скажите, кто хорошо в этом разбирается: это что же, теперь мы так и будем дальше тратить кучу энергии, чтобы вот эти рассчёты считать в блокчейновых системах?! Я понимаю, что это их обязательное условие — сложность рассчёта, чтобы невозможно (точнее, очень трудно) было подделать несколько предыдущих транзакций, но как-то это не правильно, что столько энергии и вычислительных мощностей уходит просто на то, чтобы участники этих систем могли доверять системе (полагаясь на то, что подделать почти невозможно). Как-то подругому нельзя доверять друг-другу?
Как-то подругому нельзя доверять друг-другу?
Точнее «не доверять друг другу»)
Не доверять друг-другу «по-другому» можно. Зависит от того сколько именно «недоверия» нам нужно и сколько его мы готовы оплатить.
Больше децентрализации — выше «налог» на недоверие)
Если представить себе «шкалу недоверия» на одном конце которой расположено «абсолютное недоверия» (те самые популярные лозунги «децентрализация»,«анонимность» и прочая анархия), а на другом — «централизация», и разместим на ней все существующие решения, то увидим, что у нас есть
Решения на основе POA(Proof-of-Work) — максимальное недоверие, большие комиссии, большая ресурсоемкость.Эфир, Биткоин и прочее такое.
Решения на основе POA (Proof-of-Authority) — доверие «арбитру». Система при которой есть «главные» узлы, которые проводят транзакции и все остальные желающие — наблюдатели. Полная централизация, низкие комиссии, высокая пропускная способность, Ripple, Visa и т.д.
И Proof-of-Stake — POS — где-то по средине шкалы.
Я о том, чтобы расчёт очередного блока не был таким ресурсоёмким. Если я правильно Вас понял, то все приведённые варианты блокчейновых систем отличаются лишь тем — где будет производиться расчёт блока. А сама затратность этого расчёта не меняется. Она может меняться для конкретного участника системы того или иного типа, но не для системы в целом. А я спрашивал о том, нет ли возможности также «не доверять друг-другу», также децентрализовано, но чтобы не нужно было тратить столько энергии и столько вычислительных мощностей? Полная централизация с VISA и проч. тоже не хорошо, но и вот это расходование мощностей для блокчейна это как-то глупо выглядит… Неужели нельзя как-то не менее эффективно защититься от подделки блоков другим, сильно менее ресурсоёмким, способом?
Это что-то «кармическое»)
«Технически» да — POW от POS от POA, в крупную клетку, отличается только тем кто именно может участвовать в формировании очередного блока.
Но тут вопрос больше психологии и экономики. Пока решения только такие: максимально-децентрализовано, но очень большие издержки, либо ближе к реальности и удобнее пользоваться, но не такие яркие заголовки в СМИ.
И предположу, что массовыми всё же станут более централизованные системы. (И судя по дрифту от POW к POS/POA авторы решений тоже это понимают).
Если, конечно, не найдется принципиально нового решения, которое сбалансировало бы интересы всех участников более «экономным» способом.
«Технически» да — POW от POS от POA, в крупную клетку, отличается только тем кто именно может участвовать в формировании очередного блока.
Но тут вопрос больше психологии и экономики. Пока решения только такие: максимально-децентрализовано, но очень большие издержки, либо ближе к реальности и удобнее пользоваться, но не такие яркие заголовки в СМИ.
И предположу, что массовыми всё же станут более централизованные системы. (И судя по дрифту от POW к POS/POA авторы решений тоже это понимают).
Если, конечно, не найдется принципиально нового решения, которое сбалансировало бы интересы всех участников более «экономным» способом.
Sign up to leave a comment.
Экономия газа в смарт-контрактах Ethereum