Compass Investments

Короче, из двух концепций, более близкой по срокам EIP-7864, над которым работают @gballet и коллеги. Он предусматривает смену текущего гексадерева Меркла Патриции Ethereum на двоичное дерево с более производительной хэш-функцией.

Нынешняя гексадеревянная схема была выработана в соответствии с другими приоритетами, а не для будущего Proof-of-Stake Ethereum. Переход на бинарное дерево даст нам вчетверо более короткие ветви Меркла, поскольку двоичная структура имеет логарифмическую зависимость от размера $32 \times \log(n)$, а гексадерево $512 \times \log(n) / 4$. Уменьшение длины веток значительно удешевит клиентскую проверку и снизит требования к пропускной способности каналов передачи данных для инструментов вроде Helios и PIR.

Теперь к изменениям на уровне исполнения. Я уже упоминал абстракцию счетов, многомерный газ, BAL и ZK-EVM.

Отсюда начинается реальный прирост эффективности доказательств. Улучшение в 34 раза за счет укороченных веток не зависит от смены хэш-функции, которая может дать дополнительный 3-кратный прирост при использовании blake3 вместо keccak, или даже стократный с вариантом Poseidon, хотя Бутерин предупреждает о необходимости доработок безопасности, прежде чем Poseidon можно будет внедрять.

Двоичная структура дерева также вводит концепцию страничной организации хранения, объединяя смежные ячейки в страницы по 64256 слотов, что составляет около 28 КБ. Заголовок блока и первые 14 КБ кода и памяти делят одну и ту же страницу. Это обеспечивает пакетную эффективность для контрактов, обращающихся к начальным слотам памяти, вместо оплаты за каждый доступ по отдельности. Бутерин подсчитал, что это может сэкономить более 10 000 газа за транзакцию для dApps, которые уже подгружают данные из первых хранилищ а это большинство активных контрактов.

Бинарные деревья также легче кодировать и проверять. Более предсказуемая глубина доступа для больших и малых контрактов уменьшает разброс в стоимости исполнения, а сама структура логично оставляет место для внедрения метаданных, необходимых для работы с отложенным изменением состояния.

Вторая концепция более долгоиграющая, и, по признанию самого Бутерина, пока не набрала консенсуса. Идея в том, что архитектура EVM не лучшая база для блокчейна, ориентированного на доказательства. Замена ее на более подходящую ВМ, например, RISC-V, позволит решить проблему фундаментально, а не маскировать ее накоплением прекомпиляций и обходных путей.

Аргументы Бутерина строятся на четырех преимуществах RISC-V перед EVM. Первый производительность исполнения: RISC-V превосходит EVM настолько, что многие прекомпиляции станут не нужны, поскольку базовые вычисления, для которых они были нужны, смогут эффективно выполняться самой виртуальной машиной. Второй эффективность доказательств: Сегодня ZK-доказательства создаются на RISC-V, что означает нативную совместимость ВМ на RISC-V с существующей инфраструктурой провинг-систем.

Третье клиентская верификация: ВМ на RISC-V позволяет пользователям локально создавать ZK-доказательства того, что происходит при обращении к их аккаунту с определенным набором данных. Это открывает возможности для сценариев конфиденциальности и верификации, недостижимых для EVM без внешних надстроек. И четвертое простота: интерпретатор RISC-V это всего пара сотен строк кода, что как раз соответствует желаемому объему для блокчейн-ВМ.