Пост
Этот пост по его id.
https://api.web3aggregator.io/api/v1/posts/17169 curl -H "Authorization: Bearer $W3A_API_KEY" 'https://api.web3aggregator.io/api/v1/posts/17169'Нужен ключ: W3A_API_KEY в окружении.
API отдаёт одно это сообщение: остальные части альбома там — отдельные посты, связанные полем album.
Документация APIBlock-Level Access Lists (BAL)
Следующий в Glamsterdam по важности: EIP-7928: Block-Level Access Lists.
Вместе ePBS и BAL создают основу для масштабирования производительности Ethereum.
Каким образом масштабируемся?
Сейчас валидатор для проверки транзакций в блоке может их исполнить только последовательно или применив собственные оптимизации, т.к. неизвестно, как транзакции будут менять состояние блокчейна и важен порядок выполнения.
Разработчики решили, что нужно исполнять транзакции параллельно, благодаря чему, блок проверяется быстрее и можно поднять лимит газа на блок. А это значит, можно запихать в него больше транзакций.
Как сделать параллельное исполнение?
Нужно, чтобы вместе с блоком заранее приходил результат его выполнения: какие слоты меняются и какими они станут после каждой транзакции.
Для этого разработали специальную структуру (BAL), чтобы хранить информацию о том, какие транзакции => какие слоты памяти будут изменять.
Таким образом, можно исполнять транзакции параллельно и изолированно друг от друга, потому что будет известно начальное и конечное состояние стейта блокчейна на момент запуска.
В BAL все транзакции пронумерованы от 1 до n. Если до n-й транзакции слот в блоке никто не менял, значение читается с диска ноды. Если менял, берётся последнее значение из BAL.
Что лежит в BAL?
BAL — это список адресов контрактов и акаунтов. Для каждого такого акаунта передается:
Как передается BAL?
В каждый заголовок блока добавляется поле
Сам BAL лежит не в теле блока, а в
Хранить его клиенты должны достаточно долго, не меньше 3533 эпох (это около 16 дней).
Кто формирует BAL и можно ли ему доверять?
BAL собирает билдер вместе с payload. Напихать туда он может что угодно, поэтому нода доверять этому не может и должна формировать свой BAL, проверяя его с переданным от билдера.
Получается, что BAL выступает, как подсказка для выполнения, а не замена полноценному исполнению блока. При этом, если что-то не сходится, то блок считается невалидным.
Пример
Дано: Алиса, Боб и USDC.
До блока у Алисы 100 USDC, у Боба 0.
В блоке две транзакции: Алиса отправляет Бобу 30, а Боб отправляет Алисе 10. Вторая транзакция зависит от первой: без неё Бобу просто нечего отправлять.
Без BAL валидатор обязан исполнить их строго по очереди. С BAL он уже знает, какими станут балансы после каждой транзакции: после tx1 — 70 и 30, после tx2 — 80 и 20.
Поэтому валидатор запускает обе транзакции одновременно. tx1 берёт балансы с диска (100 и 0, так как до tx1 эти слоты в блоке никто не менял), а tx2 берет балансы из BAL (70 и 30), не дожидаясь tx1.
В конце валидатор сверяет: совпали ли результаты с тем, что записано в BAL? Если да, блок валиден. Если билдер где-то соврал, проверка не сойдётся, и блок невалиден.
Вывод
Получается, что ePBS дает время, расширяя окно распространения данных блока до 6-9 секунд, а BAL позволяет эффективнее использовать это время для проверки транзакций за счет параллельного исполнения.
Из неочевидного, это то, что BAL дает не только возможность исполнить транзакции параллельно.
Также добавляется:
1. Параллельное чтение значений слотов из диска, потому что BAL перечисляет все слоты, которые будут прочитаны или изменены в рамках блока. И это даже более круто по производительности, чем исполнение.
2. Для билдера построение BAL обязательно, но код клиента ноды может исполнить блок и по старинке последовательно, а потом просто сравнить.
#павел_найданов
🤟 Сайт | ТГ-канал | Наш чат
Следующий в Glamsterdam по важности: EIP-7928: Block-Level Access Lists.
Вместе ePBS и BAL создают основу для масштабирования производительности Ethereum.
Каким образом масштабируемся?
Сейчас валидатор для проверки транзакций в блоке может их исполнить только последовательно или применив собственные оптимизации, т.к. неизвестно, как транзакции будут менять состояние блокчейна и важен порядок выполнения.
Разработчики решили, что нужно исполнять транзакции параллельно, благодаря чему, блок проверяется быстрее и можно поднять лимит газа на блок. А это значит, можно запихать в него больше транзакций.
Как сделать параллельное исполнение?
Нужно, чтобы вместе с блоком заранее приходил результат его выполнения: какие слоты меняются и какими они станут после каждой транзакции.
Для этого разработали специальную структуру (BAL), чтобы хранить информацию о том, какие транзакции => какие слоты памяти будут изменять.
Таким образом, можно исполнять транзакции параллельно и изолированно друг от друга, потому что будет известно начальное и конечное состояние стейта блокчейна на момент запуска.
В BAL все транзакции пронумерованы от 1 до n. Если до n-й транзакции слот в блоке никто не менял, значение читается с диска ноды. Если менял, берётся последнее значение из BAL.
Что лежит в BAL?
BAL — это список адресов контрактов и акаунтов. Для каждого такого акаунта передается:
storage_changes — какие слоты изменились и на какое значение после какой транзакции;storage_reads — слоты, которые только читали;balance_changes, nonce_changes, code_changes — новые значения после каждой транзакции.Как передается BAL?
В каждый заголовок блока добавляется поле
block_access_list_hash. который хранит хэш BAL. Сам BAL лежит не в теле блока, а в
ExecutionPayload и передаётся между CL и EL через Engine API.Хранить его клиенты должны достаточно долго, не меньше 3533 эпох (это около 16 дней).
Кто формирует BAL и можно ли ему доверять?
BAL собирает билдер вместе с payload. Напихать туда он может что угодно, поэтому нода доверять этому не может и должна формировать свой BAL, проверяя его с переданным от билдера.
Получается, что BAL выступает, как подсказка для выполнения, а не замена полноценному исполнению блока. При этом, если что-то не сходится, то блок считается невалидным.
Пример
Дано: Алиса, Боб и USDC.
До блока у Алисы 100 USDC, у Боба 0.
В блоке две транзакции: Алиса отправляет Бобу 30, а Боб отправляет Алисе 10. Вторая транзакция зависит от первой: без неё Бобу просто нечего отправлять.
Без BAL валидатор обязан исполнить их строго по очереди. С BAL он уже знает, какими станут балансы после каждой транзакции: после tx1 — 70 и 30, после tx2 — 80 и 20.
[
[ 0x..., # адрес контракта USDC
[ # storage_changes
[ баланс_Алисы, [[1, 70], [2, 80]] ], # слот: [[номер tx, значение после tx]]
[ баланс_Боба, [[1, 30], [2, 20]] ],
],
[], # storage_reads
[], # balance_changes (ETH)
[], # nonce_changes
[] # code_changes
]
]Поэтому валидатор запускает обе транзакции одновременно. tx1 берёт балансы с диска (100 и 0, так как до tx1 эти слоты в блоке никто не менял), а tx2 берет балансы из BAL (70 и 30), не дожидаясь tx1.
В конце валидатор сверяет: совпали ли результаты с тем, что записано в BAL? Если да, блок валиден. Если билдер где-то соврал, проверка не сойдётся, и блок невалиден.
Вывод
Получается, что ePBS дает время, расширяя окно распространения данных блока до 6-9 секунд, а BAL позволяет эффективнее использовать это время для проверки транзакций за счет параллельного исполнения.
Из неочевидного, это то, что BAL дает не только возможность исполнить транзакции параллельно.
Также добавляется:
1. Параллельное чтение значений слотов из диска, потому что BAL перечисляет все слоты, которые будут прочитаны или изменены в рамках блока. И это даже более круто по производительности, чем исполнение.
2. Для билдера построение BAL обязательно, но код клиента ноды может исполнить блок и по старинке последовательно, а потом просто сравнить.
#павел_найданов
🤟 Сайт | ТГ-канал | Наш чат
