Чем отличаются главные zkEVM: Scroll, Polygon, zkSync и Starknet
Пост для умных и тех, кто хочет таким казаться: разбор основных zk-решений масштабируемости Ethereum и объяснение, почему использующаяся сегодня терминология не совсем корректна.
zkEVM стал консенсусным термином, используемым как экспертами, так и новичками в Web3 для обозначения EVM-совместимости или эквивалентности. Однако если коротко, ни одно из существующих решений таковым сейчас не является, хотя все и стремятся к этому.
🥷 Более того, из всех L2-решений, которые называют себя zk-роллапами, конфиденциальность как свойство включает в себя только Aztec, в то время как остальные ограничиваются лаконичностью (succinctness). По этой причине их корректнее называть валидити-роллапами. Однако это тема для отдельной статьи, здесь же мы разберём, в чём тонкости EVM-эквивалентности/совместимости.
🔀 К основным zkEVM сейчас относятся: Scroll, Polygon, zkSync и Starknet. Scroll и Polygon совместимы с EVM на уровне байткода, а zkSync и Starknet — на уровне языка. Это два разных подхода, каждый из которых предполагает компромиссы между совместимостью и производительностью (Виталик писал о них здесь).
📝 Перечисленные проекты будут располагаться на диаграмме в следующем порядке: Scroll — Polygon Hermez — zkSync — Starkware, где Scroll наиболее совместимый и медленный, а Starkware самый быстрый и наименее совместимый. То есть производительность имеет тенденцию к снижению по мере увеличения EVM-совместимости.
✅ Совместимость на уровне байткода предполагает, что разработчикам не нужны дополнительные инструменты или специальная версия компилятора. Они могут транспилировать код Solidity или Vyper на уровень байткода и доказать корректность выполнения в zk-среде. При достижении EVM-эквивалентности разработчики смогут транспилировать сам байткод и доказывать его валидность в zk-среде, а затем — валидность его выполнения.
🛠 Совместимость на уровне языка предполагает использование дополнительных инструментов и LLVM (low level virtual machine) вместо EVM. В таком случае необходим интерпретатор или компилятор, который отражает все функции байткода EVM, но не является его полным эквивалентом. Таким образом, совместимые на уровне языка zkEVM компилируют Solidity/Vyper в байткод, ориентированный на LLVM.
⚖️ Неизбежный компромисс между совместимостью и производительностью связан с тем, что EVM недружелюбна к zk. Многие части Ethereum требуют большого объема вычислений для валидации zk-схемы. Однако это можно смягчить с помощью аппаратных средств: GPU, FPGA или ASIC. Более подробно об этом можно прочитать в этом треде. Однако в любом случае важно запомнить, что все существующие zk-решения предполагают этот компромисс, который косвенно сказывается и на других свойствах, и в частности, на безопасности: чем больше дополнительных инструментов требуется для переноса кода, тем сложнее становится система.
🔮 Сам Бутерин считает, что со временем все решения будут стремиться к полной Ethereum-эквивалентности. Однако сейчас единственным примером такого проекта является ZK-EVM Community Edition, который ещё далёк до рабочего состояния. Все же существующие zk-решения ещё в течение неопределённого времени будут дрейфовать между совместимостью и производительностью, где и будут возникать инновации ближайших лет.
Понравился пост? Ставьте лайки, подписывайтесь на канал, заходите в чат👇
🧑🚀 Канал | Чат | Twitter | 1inch
Пост для умных и тех, кто хочет таким казаться: разбор основных zk-решений масштабируемости Ethereum и объяснение, почему использующаяся сегодня терминология не совсем корректна.
zkEVM стал консенсусным термином, используемым как экспертами, так и новичками в Web3 для обозначения EVM-совместимости или эквивалентности. Однако если коротко, ни одно из существующих решений таковым сейчас не является, хотя все и стремятся к этому.
🥷 Более того, из всех L2-решений, которые называют себя zk-роллапами, конфиденциальность как свойство включает в себя только Aztec, в то время как остальные ограничиваются лаконичностью (succinctness). По этой причине их корректнее называть валидити-роллапами. Однако это тема для отдельной статьи, здесь же мы разберём, в чём тонкости EVM-эквивалентности/совместимости.
🔀 К основным zkEVM сейчас относятся: Scroll, Polygon, zkSync и Starknet. Scroll и Polygon совместимы с EVM на уровне байткода, а zkSync и Starknet — на уровне языка. Это два разных подхода, каждый из которых предполагает компромиссы между совместимостью и производительностью (Виталик писал о них здесь).
📝 Перечисленные проекты будут располагаться на диаграмме в следующем порядке: Scroll — Polygon Hermez — zkSync — Starkware, где Scroll наиболее совместимый и медленный, а Starkware самый быстрый и наименее совместимый. То есть производительность имеет тенденцию к снижению по мере увеличения EVM-совместимости.
✅ Совместимость на уровне байткода предполагает, что разработчикам не нужны дополнительные инструменты или специальная версия компилятора. Они могут транспилировать код Solidity или Vyper на уровень байткода и доказать корректность выполнения в zk-среде. При достижении EVM-эквивалентности разработчики смогут транспилировать сам байткод и доказывать его валидность в zk-среде, а затем — валидность его выполнения.
🛠 Совместимость на уровне языка предполагает использование дополнительных инструментов и LLVM (low level virtual machine) вместо EVM. В таком случае необходим интерпретатор или компилятор, который отражает все функции байткода EVM, но не является его полным эквивалентом. Таким образом, совместимые на уровне языка zkEVM компилируют Solidity/Vyper в байткод, ориентированный на LLVM.
⚖️ Неизбежный компромисс между совместимостью и производительностью связан с тем, что EVM недружелюбна к zk. Многие части Ethereum требуют большого объема вычислений для валидации zk-схемы. Однако это можно смягчить с помощью аппаратных средств: GPU, FPGA или ASIC. Более подробно об этом можно прочитать в этом треде. Однако в любом случае важно запомнить, что все существующие zk-решения предполагают этот компромисс, который косвенно сказывается и на других свойствах, и в частности, на безопасности: чем больше дополнительных инструментов требуется для переноса кода, тем сложнее становится система.
🔮 Сам Бутерин считает, что со временем все решения будут стремиться к полной Ethereum-эквивалентности. Однако сейчас единственным примером такого проекта является ZK-EVM Community Edition, который ещё далёк до рабочего состояния. Все же существующие zk-решения ещё в течение неопределённого времени будут дрейфовать между совместимостью и производительностью, где и будут возникать инновации ближайших лет.
Понравился пост? Ставьте лайки, подписывайтесь на канал, заходите в чат👇
🧑🚀 Канал | Чат | Twitter | 1inch