Пост
Цей пост за його id.
https://api.web3aggregator.io/api/v1/posts/20042 curl -H "Authorization: Bearer $W3A_API_KEY" 'https://api.web3aggregator.io/api/v1/posts/20042'Потрібен ключ: W3A_API_KEY в оточенні.
API віддає одне це повідомлення: інші частини альбому там — окремі пости, пов'язані полем album.
Документація APIЧасть 2: Газовая модель - «Защита блока»
В предыдущей части мы обсудили только то, что касается изменений в области расчета газа и газ-лимита.
Газ-лимит — это инвариант: «В блоке не больше X работы и не больше Y байт». Но сейчас это можно легко обойти тремя способами, и Glamsterdam закрывает их своими EIPs.
TLDR
EIP-7976 описывает главную проблему блока, который может быть раздут данными, а не только вычислениями. Решает проблему повышением стоимости calldata в блоке.
EIP-7981 повышает стоимость за данные, передаваемые через Access List (это список адресов Ethereum и конкретных слотов их storage, к которым транзакция потенциально будет обращаться при выполнении транзакции).
EIP-7778 отменяет применение рефанда газа к лимиту блока (количество газа минусуется при выполнении, когда sstore обнуляет слот).
Зачем это все?
Ключевая проблема в том, что важны не только вычисления в блоке, но и сами данные блока.
Планируется, что газ-лимит блока будет расти, а вместе с ним будет увеличиваться влияние проблемы: блок можно раздуть данными через calldata, access lists или выполнить больше вычислений за счет рефанда газа, обходя газ-лимит.
В плане увеличивать газ-лимит блока до 200 млн, что однозначно усугубит описанные проблемы.
Glamsterdam закрывает все три уже сейчас, до того, как лимит поднимут.
1️⃣ EIP-7976
Это предложение затрагивает те данные транзакции, которые можно отправить через calldata.
Исторически, calldata — это входные данные транзакции: какую функцию смарт-контракта вызвать и с какими аргументами. Все это в байтах и лежит прямо в блоке, а значит вместе с ним и распространяется по сети.
До обновления Pectra было все просто: 4 единицы газа за нулевой байт, 16 — за ненулевой.
Потом подкрутили это так, чтобы экономически было невыгодно в calldata класть много данных, так как уже для этого вовсю можно было использовать blob объекты.
Каждая транзакция считается двумя способами, и платит она по максимальному тарифу:
1. Обычный расчет — 4/16 газа за байт + исполнение;
2. Минимальная планка — 10/40 газа за байт (в Pectra).
Ниже расценки и пример с учетом Glamsterdam, который поднимает минимальную планку.
Обычная цена | 4 | 16
Floor в EIP-7623 (Pectra) | 10 | 40
Floor в EIP-7976 (Glamsterdam) | 64 | 64
Пример
Если речь об обычном трансфере ERC-20, его calldata - это плюс/минус 68 байт.
По обычной цене будет посчитано, как 68 * 16 = 1_088 (для простоты считаем, что там все 68 байт ненулевые) + газ за исполнение.
По Glamsterdam нижняя граница будет посчитана, как 68 * 64 = 4_352. Это меньше, чем обычный расчет + исполнение. Поэтому транзакция платит по большему из двух: в нашем случае дешевая calldata + исполнение.
P.S. А вот транзакция, которая почти ничего не вычисляет, но несёт 100 КБ данных, заплатит не меньше 100_000 × 64 = 6,4M газа.
Подобное повышение позволяет уменьшить количество данных в блоке. Считаем легко: газ-лимит блока / 64 газа за байт (это минимальная стоимость за байт информации).
При газ-лимите 200M это ~3,1 МБ вместо ~5 МБ при Pectra, что безусловно снижает объем данных.
2️⃣ EIP-7981
Помимо calldata другой тип данных, который может раздуть блок - Access List. Это наследие EIP-2930 (Berlin). До сих пор - это необязательное поле транзакции.
В нём транзакция заранее перечисляет адреса и слоты хранилища, к которым собирается обращаться. За каждый элемент она платит при входе:
• адрес — 2 400 газа;
• слот — 1 900 газа.
Взамен эти адреса и слоты становятся тёплыми с самого начала транзакции, и обращение к ним стоит 100 газа вместо холодных 2_600 / 2_100. Задумка прекрасная, как способ немного сэкономить.
Вам напоминает это чем-то фаворита Glamsterdam обновления BAL, где мы прокидываем адреса, состояния в слотах, которые транзакция планирует менять?😅
Проблема с Access List
Можно разбавить в транзакции calldata при помощи access list так, чтобы повышенная минималка (EIP-7976) перестала действовать.
И вуаля! Calldata снова стоит дёшево, 16 газа за байт, а в блок влезает больше байт, чем позволяет минималка. Блок снова раздут данными.
Решение
Бахнуть надбавку в те же 64 газа за байт, что и для calldata.
| Байт | Было (EIP-2930) | Стало
Адрес | 20 | 2_400 | 2_400 + 20 * 64 = 3 680
Ключ слота | 32 | 1_900 | 1_900 + 32 * 64 = 3 948
Только в отличие от calldata, здесь надбавка действует на любой Access List. Заранее «нагреть» слот теперь сильно дороже, чем просто прочитать его холодным.
Вот теперь считайте сами выгодно ли вам в вашем случае прогревать слоты или проще обращаться к холодному слоту?
❗️По моим расчетам прогревать больше нет смысла.
3️⃣ EIP-7778
Рефанд - это возврат части газа за то, что транзакция очистила состояние. Обычно
🔥 Немного истории
Помните про такую модную штуку, как газовые токены? Такие токены занимали слоты при дешёвом газе, а при дорогом очищали их и получали возврат.
Получается в момент дорогого газа ты вместе со своей транзой сжигал часть данных и получал рефанд, что делало твою целевую транзакцию как бы дешевле.
Когда-то это был крутой концепт, пока его не прикрыли в обновлении London, ограничив refund газа до 20% от потраченного.
В чем проблема сейчас?
Рефанд не просто делает возврат, он уменьшает газ, который засчитывается в лимит блока.
Так как рефанд ограничен 20% от всего потраченного газа, то засчитанный блоку газ - это 80% реальной работы.
При газ-лимите 200 млн реальная работа = 200 / 0,8 = 250 млн. А это уже много для окна 6-9 секунд, которые даются на проверку блока.
Решение
Убрать рефанд из газ-лимита блока, но оставить его для уменьшения платы за транзакцию.
Получается, что для пользователя ничего не меняется, его рефанд сохранен, а в блок не влезет больше работы сверх газ-лимита.
Общий вывод
Чтобы безопасно поднимать газ-лимит блока, сначала нужно сделать его честным. Исключить возможность обойти лимит или раздуть за счет данных. Три предложения (7976, 7981, 7778) направлены именно на это.
Раздуть блок через calldata, access list будет экономически невыгодно. Рефанд перестанет влиять на газ-лимит блока.
Вишенка этой группы предложений: заранее «нагреть» слот теперь почти вдвое дороже, чем прочитать его холодным. Поэтому как способ сэкономить газ access list (EIP-2930) после Glamsterdam перестаёт работать, и всем, кто это использует, стоит отказаться от него.
#павел_найданов
🤟 Сайт | ТГ-канал | Наш чат
В предыдущей части мы обсудили только то, что касается изменений в области расчета газа и газ-лимита.
Газ-лимит — это инвариант: «В блоке не больше X работы и не больше Y байт». Но сейчас это можно легко обойти тремя способами, и Glamsterdam закрывает их своими EIPs.
TLDR
EIP-7976 описывает главную проблему блока, который может быть раздут данными, а не только вычислениями. Решает проблему повышением стоимости calldata в блоке.
EIP-7981 повышает стоимость за данные, передаваемые через Access List (это список адресов Ethereum и конкретных слотов их storage, к которым транзакция потенциально будет обращаться при выполнении транзакции).
EIP-7778 отменяет применение рефанда газа к лимиту блока (количество газа минусуется при выполнении, когда sstore обнуляет слот).
Зачем это все?
Ключевая проблема в том, что важны не только вычисления в блоке, но и сами данные блока.
Планируется, что газ-лимит блока будет расти, а вместе с ним будет увеличиваться влияние проблемы: блок можно раздуть данными через calldata, access lists или выполнить больше вычислений за счет рефанда газа, обходя газ-лимит.
В плане увеличивать газ-лимит блока до 200 млн, что однозначно усугубит описанные проблемы.
Glamsterdam закрывает все три уже сейчас, до того, как лимит поднимут.
1️⃣ EIP-7976
Это предложение затрагивает те данные транзакции, которые можно отправить через calldata.
Посыл тот же, что и раньше: большим данным место в blobs, а не в calldata.
Исторически, calldata — это входные данные транзакции: какую функцию смарт-контракта вызвать и с какими аргументами. Все это в байтах и лежит прямо в блоке, а значит вместе с ним и распространяется по сети.
До обновления Pectra было все просто: 4 единицы газа за нулевой байт, 16 — за ненулевой.
Потом подкрутили это так, чтобы экономически было невыгодно в calldata класть много данных, так как уже для этого вовсю можно было использовать blob объекты.
Каждая транзакция считается двумя способами, и платит она по максимальному тарифу:
1. Обычный расчет — 4/16 газа за байт + исполнение;
2. Минимальная планка — 10/40 газа за байт (в Pectra).
Ниже расценки и пример с учетом Glamsterdam, который поднимает минимальную планку.
Обычная цена | 4 | 16
Floor в EIP-7623 (Pectra) | 10 | 40
Floor в EIP-7976 (Glamsterdam) | 64 | 64
Пример
Если речь об обычном трансфере ERC-20, его calldata - это плюс/минус 68 байт.
По обычной цене будет посчитано, как 68 * 16 = 1_088 (для простоты считаем, что там все 68 байт ненулевые) + газ за исполнение.
По Glamsterdam нижняя граница будет посчитана, как 68 * 64 = 4_352. Это меньше, чем обычный расчет + исполнение. Поэтому транзакция платит по большему из двух: в нашем случае дешевая calldata + исполнение.
P.S. А вот транзакция, которая почти ничего не вычисляет, но несёт 100 КБ данных, заплатит не меньше 100_000 × 64 = 6,4M газа.
Подобное повышение позволяет уменьшить количество данных в блоке. Считаем легко: газ-лимит блока / 64 газа за байт (это минимальная стоимость за байт информации).
При газ-лимите 200M это ~3,1 МБ вместо ~5 МБ при Pectra, что безусловно снижает объем данных.
2️⃣ EIP-7981
Помимо calldata другой тип данных, который может раздуть блок - Access List. Это наследие EIP-2930 (Berlin). До сих пор - это необязательное поле транзакции.
В нём транзакция заранее перечисляет адреса и слоты хранилища, к которым собирается обращаться. За каждый элемент она платит при входе:
• адрес — 2 400 газа;
• слот — 1 900 газа.
Взамен эти адреса и слоты становятся тёплыми с самого начала транзакции, и обращение к ним стоит 100 газа вместо холодных 2_600 / 2_100. Задумка прекрасная, как способ немного сэкономить.
Вам напоминает это чем-то фаворита Glamsterdam обновления BAL, где мы прокидываем адреса, состояния в слотах, которые транзакция планирует менять?😅
Проблема с Access List
Можно разбавить в транзакции calldata при помощи access list так, чтобы повышенная минималка (EIP-7976) перестала действовать.
И вуаля! Calldata снова стоит дёшево, 16 газа за байт, а в блок влезает больше байт, чем позволяет минималка. Блок снова раздут данными.
Решение
Бахнуть надбавку в те же 64 газа за байт, что и для calldata.
| Байт | Было (EIP-2930) | Стало
Адрес | 20 | 2_400 | 2_400 + 20 * 64 = 3 680
Ключ слота | 32 | 1_900 | 1_900 + 32 * 64 = 3 948
Только в отличие от calldata, здесь надбавка действует на любой Access List. Заранее «нагреть» слот теперь сильно дороже, чем просто прочитать его холодным.
Вот теперь считайте сами выгодно ли вам в вашем случае прогревать слоты или проще обращаться к холодному слоту?
❗️По моим расчетам прогревать больше нет смысла.
3️⃣ EIP-7778
Рефанд - это возврат части газа за то, что транзакция очистила состояние. Обычно
SSTORE обнуляет слот, который до этого был ненулевым. 🔥 Немного истории
Помните про такую модную штуку, как газовые токены? Такие токены занимали слоты при дешёвом газе, а при дорогом очищали их и получали возврат.
Получается в момент дорогого газа ты вместе со своей транзой сжигал часть данных и получал рефанд, что делало твою целевую транзакцию как бы дешевле.
Когда-то это был крутой концепт, пока его не прикрыли в обновлении London, ограничив refund газа до 20% от потраченного.
В чем проблема сейчас?
Рефанд не просто делает возврат, он уменьшает газ, который засчитывается в лимит блока.
Так как рефанд ограничен 20% от всего потраченного газа, то засчитанный блоку газ - это 80% реальной работы.
При газ-лимите 200 млн реальная работа = 200 / 0,8 = 250 млн. А это уже много для окна 6-9 секунд, которые даются на проверку блока.
Решение
Убрать рефанд из газ-лимита блока, но оставить его для уменьшения платы за транзакцию.
Получается, что для пользователя ничего не меняется, его рефанд сохранен, а в блок не влезет больше работы сверх газ-лимита.
Общий вывод
Чтобы безопасно поднимать газ-лимит блока, сначала нужно сделать его честным. Исключить возможность обойти лимит или раздуть за счет данных. Три предложения (7976, 7981, 7778) направлены именно на это.
Раздуть блок через calldata, access list будет экономически невыгодно. Рефанд перестанет влиять на газ-лимит блока.
Вишенка этой группы предложений: заранее «нагреть» слот теперь почти вдвое дороже, чем прочитать его холодным. Поэтому как способ сэкономить газ access list (EIP-2930) после Glamsterdam перестаёт работать, и всем, кто это использует, стоит отказаться от него.
#павел_найданов
🤟 Сайт | ТГ-канал | Наш чат
