Видео доступно на Youtube по ссылке. Таймкод - 5:30:00.

Во время презентации Алекс рассказал о ключевых особенностях решения zkSync, zkEVM, а так же о проблемах, которые данные технологии призваны решить.

В первую очередь, Алекс предлагает разобраться в концепциях совместимости и эквивалентности. zkSync - это первая zkEVM-сеть, которая развернется в основной сети уже менее чем через 2 месяца (команда сконцентрирована на этом).

Миссия zkSync - ускорить принятие блокчейна в качестве мейнстрим-технологии для личностного суверенитета. В практическом смысле, это значит ускорение принятия Эфириума, полное сохранение качеств Эфириума, но при этом выйти в настоящий мейнстрим - на многие миллионы и миллиарды людей. zkSync - это не компания, это - миссия.

Единственным возможным инструментом достижения этих целей мы видим zkEVM. Почему?

1. Потому что zk (zero-knowledge proofs) - единственная на данный момент имеющаяся технология, позволяющая масштабировать ценности Эфириума до бесконечности. Которая полностью сохраняет безопасность ВСЕХ транзакций, несмотря на количество пользователей или этих самых транзакций. Мы считаем, что ни одна другая технология этого не позволяет.

2. В свою очередь, EVM - это Lingua Franca (общепризнанный стандарт) блокчейна\веб3\интернета ценности. Это как JavaScript раннего интернета. Слишком много инфраструктуры создано вокруг и для EVM, чтобы отказаться от нее. Как пример, мы видим, как альтернативные L1-решения, изначально строящие не на EVM в конечном итоге все равно перешли на EVM. EVM - это стандарт, и он должен им оставаться.

Однако, “поженить” zk-proofs и EVM - вот что является основной задачей. EVM был построен для обычной компьютерной архитектуры, а zk-окружение - далеко от обычного. Профиль операций у этих двух технологий совершенно разный.

Так вот, мы стараемся достичь некоторой степени совместимости. И мы можем это сделать. Многие команды работают над этим, мы работаем над этим в течение последних двух лет. Разработаны множество трюков, оптимизаций, которые позволяют реализовать нашу идею, да и также есть некоторые прорывы в протоколах. Однако, вопрос в следующем - мы способны достичь лишь общей совместимости с EVM или все же можем замахнуться на эквивалентеность (полное соответствие)? На эту тему развернулся большой дискурс, в котором некоторые участники, особенно сторонники оптимистических решений, утверждают, что единственный путь - это полная эквивалентность, иначе ничего не имеет смысла.

Давайте исследуем эти два концепта. Если приглядеться, то мы увидим, что это не бинарный выбор, а спектр. Можно иметь определенную степень совместимости, где-то между 0 и 100%.

Алекс ссылается на недавний пост Виталика Бутерина о zk-решениях, в которых он (Виталик) описывает различные типы zk-роллапов, по факту относя их к той или иной части спектра.

Каждый тип имеет свое место в координатной сетке Совместимости\Производительности. Здесь имеет место быть обратная пропорциональность, т.е. чем выше совместимость, тем ниже производительность, и наоборот.

4й тип - самый производительный. Здесь zkSync будет соместим с EVM на уровне исходного кода. Мы можем взять любой код, написанный для EVM, развернуть в виртуальной среде и он будет работать. В большей или меньшей степени, но будет работать. Это УЖЕ нетривиальная задача. Реализация такого решения требует огромных усилий. Тому же Cairo (прим. язык программирования Starkware) будет сложно стать совместимым по типу 4, потому что нужно определенным образом спроектировать интерфейс взаимодействия, спроектировать определенные парадигмы, например, как вы будете возвращать транзакции, как верифицировать транзакции с Layer-1 (ETH Mainnet) и т.д.. Это УЖЕ сложно. Но несмотря на эти сложности, такой подход дает максимальную производительность. Таким образом, 4й тип позволяет построить максимально эффективную zk-среду.

Говоря о производительности мы имеем в виду строимость. Все упирается в стоимость. В случае с zk-proofs - они отлично параллелятся. Теоретически, вы просто добавляете “железа” для бОльшего количества параллельных потоков, и затем рекурсивно их компилируете для достижения ЛЮБОГО уровня пропускной способности при низкой задержке.

3й тип позволяет говорить об исполнении кода, который уже скомпилирован в нативный Эфириумовский байткод. Возможно, не со 100% совместимостью, возможно некоторые хэши будут исполняться по-другому, некоторые прекомпилированные коды могут не работать. Такой подход уже заставляет пойти на компромисс с производительностью, т.к. интерпретация кода EVM - это очень ресурсоемкая задача. EVM - не лучшая виртуальная машина, даже для обычной компьютерной архитектуры. А ее исполнение на zk усложняет задачу еще сильнее.

2.5 тип позволяет, плюс к вышеперечисленному, использовать полную совместимость с API (полная криптография EVM, прекомпайлы, keccak=keccak, SHA256=SHA256 и т.д.). Это накладывает немного меньший штраф на производительность (по сравнению с прыжком между 4м и 3м типами), т.к. этот штраф применим только в тех смарт-контрактах, в которых используются эти хэши\криптографические функции.

2й тип добавляет расчет газовой стоимости транзакций, точно такой же как в Эфириуме. Он дает максимальную совместимость на уровне приложений. Все инструменты и программы будут работать точно так же, как на Эфириуме. Он практически не влияет на производительность по сравнению с типом 2.5, т.к. в zk добавление арифметической операции (расчет газа) очень дешево.

1й тип - полная совместимость на корневом уровне блока. Вы исполняете блок,и кэш корня блока должен быть точно таким же, как если бы вы запускали его на L1. То есть, весь консенсус должен быть как на Эфириуме вместе с хранилищем. И основным штрафом в производительности тут выступает даже не консенсус, а именно хранение и доступ к данным.

Мы начинаем с 4го типа. Мы приняли осознанное мышление начать с 4го типа. Причиной этому послужила, снова, наша миссия ускорить массовое принятие. А для этого (привлечения миллионов, миллиардов людей) нужна соотвествующая технология. При таких показателях стоимость транзакций имеет решающее значение. Это сейчас транзакции в 0.10$ могут быть приемлемыми для DeFi-приложений. Однако, во многих других отраслях, например, микроплатежах, играх, социальных сетях - это неприменимо, там обрабатываются миллионы транзакций в день. И это было бы невобразимо дорого, поэтому цену транзакций необходимо свести к абсолютному минимуму. И мы хотим надеяться что доказательные технологии станут лучше, протоколы станут лучше, чтобы снижать стоимость транзакций все ниже и ниже до тех пор, пока мы не добьемся ценв 0.0000001$ за транзакцию. Поэтому мы ОБЯЗАНЫ начать с 4го типа, у нас нет выбора. Почему? Допустим, если у вас есть хорошее оборудование, вы всегда можете запустить эмулятор и запустить старые системы. Это обыденно запускать MS-DOS или Windows 3 в эмуляторе на MacBook Pro.

То же самое мы можем сделать и тут - запустить zkSync 3го типа внутри zkSync 4го типа. Нужно лишь написать смарт-контракт который будет интерпретировать байткод EVM, шаг за шагом считывающий байткод и исполняющий его. Это приведет нас к мощному базовому уровню 3го типа без серьезной головной боли. Мы можем написать смарт контракт на Solidity, может даже взять существующий код, который интерпретируется EVM. Оптимизм, Арбитрум имеет в этом наработки. ИЛИ мы даже можем применить код Rust и скомпилировать его в zk-совместимый код. В общем, это совсем небольшая надстройка, которая может перевести zkSync из 4го типа в 3й. Можем ли мы пойти дальше? Конечно! Это не так сложно добавить полноценную совместимость с API. По факту, мы будем поддерживать Keccak и SHA256 с первого дня. Так что, криптографические хэши будут на месте, их не так дорого имплементировать. Так zkSync станет типом 2.5 с минимальными усилиями.

Однако, если мы начнем с середины, с типа 2.5 - мы не сможем пойти вниз, на более производительные уровни. Вы можете эмулировать Mainframe на Macbook Pro, но не наоборот. Вам НЕОБХОДИМО начинать с базового наиболее производительного уровня, чтобы иметь возможность поставить эмулятор.

Можем ли мы пойти дальше? На типы 1 и 2? Дело в том, что они не релевантны для L2-решений. Для L2 решения не нужен корень блока из типа 1, т.к. он не позволяет использовать альтернативные методы консенсуса, которые нужны в L2. Так же расчеты газа тоже нерелевантны, т.к. профиль расчетов на L2 совсем другой. Тип ресурсов, которые мы потребляем на L1 & L2 - разный. Так что расчеты газа по типу L1 имеют очень специфические кейсы применения (например, валидация самого Эфириума, но зачем?).

Любой, кто любит Эфириум, хочет чтобы он мог обслуживать миллионы людей одновременно. И любая система, которая хочет этого достичь должна быть системой 4го типа изначально. Неважно, насколько эффективно решение 2го типа, решение 4го типа будет в сотни, а то и тысячи раз дешевле.

Алекс считает, что Эфириум в будущем должен стать более zk-Friendy. Но это должно решить комьюнити Эфириума. zkSync, начавшись как система 4го типа будет системой типа 2.5. Начинайте строить с нами!

v2.zksync.io

Встретимся в Mainnet’e!

Видео доступно на Youtube по ссылке. Таймкод - 5:30:00.

Во время презентации Алекс рассказал о ключевых особенностях решения zkSync, zkEVM, а так же о проблемах, которые данные технологии призваны решить.

В первую очередь, Алекс предлагает разобраться в концепциях совместимости и эквивалентности. zkSync - это первая zkEVM-сеть, которая развернется в основной сети уже менее чем через 2 месяца (команда сконцентрирована на этом).

Миссия zkSync - ускорить принятие блокчейна в качестве мейнстрим-технологии для личностного суверенитета. В практическом смысле, это значит ускорение принятия Эфириума, полное сохранение качеств Эфириума, но при этом выйти в настоящий мейнстрим - на многие миллионы и миллиарды людей. zkSync - это не компания, это - миссия.

Единственным возможным инструментом достижения этих целей мы видим zkEVM. Почему?

1. Потому что zk (zero-knowledge proofs) - единственная на данный момент имеющаяся технология, позволяющая масштабировать ценности Эфириума до бесконечности. Которая полностью сохраняет безопасность ВСЕХ транзакций, несмотря на количество пользователей или этих самых транзакций. Мы считаем, что ни одна другая технология этого не позволяет.

2. В свою очередь, EVM - это Lingua Franca (общепризнанный стандарт) блокчейна\веб3\интернета ценности. Это как JavaScript раннего интернета. Слишком много инфраструктуры создано вокруг и для EVM, чтобы отказаться от нее. Как пример, мы видим, как альтернативные L1-решения, изначально строящие не на EVM в конечном итоге все равно перешли на EVM. EVM - это стандарт, и он должен им оставаться.

Однако, “поженить” zk-proofs и EVM - вот что является основной задачей. EVM был построен для обычной компьютерной архитектуры, а zk-окружение - далеко от обычного. Профиль операций у этих двух технологий совершенно разный.

Так вот, мы стараемся достичь некоторой степени совместимости. И мы можем это сделать. Многие команды работают над этим, мы работаем над этим в течение последних двух лет. Разработаны множество трюков, оптимизаций, которые позволяют реализовать нашу идею, да и также есть некоторые прорывы в протоколах. Однако, вопрос в следующем - мы способны достичь лишь общей совместимости с EVM или все же можем замахнуться на эквивалентеность (полное соответствие)? На эту тему развернулся большой дискурс, в котором некоторые участники, особенно сторонники оптимистических решений, утверждают, что единственный путь - это полная эквивалентность, иначе ничего не имеет смысла.

Давайте исследуем эти два концепта. Если приглядеться, то мы увидим, что это не бинарный выбор, а спектр. Можно иметь определенную степень совместимости, где-то между 0 и 100%.

Алекс ссылается на недавний пост Виталика Бутерина о zk-решениях, в которых он (Виталик) описывает различные типы zk-роллапов, по факту относя их к той или иной части спектра.

Каждый тип имеет свое место в координатной сетке Совместимости\Производительности. Здесь имеет место быть обратная пропорциональность, т.е. чем выше совместимость, тем ниже производительность, и наоборот.

4й тип - самый производительный. Здесь zkSync будет соместим с EVM на уровне исходного кода. Мы можем взять любой код, написанный для EVM, развернуть в виртуальной среде и он будет работать. В большей или меньшей степени, но будет работать. Это УЖЕ нетривиальная задача. Реализация такого решения требует огромных усилий. Тому же Cairo (прим. язык программирования Starkware) будет сложно стать совместимым по типу 4, потому что нужно определенным образом спроектировать интерфейс взаимодействия, спроектировать определенные парадигмы, например, как вы будете возвращать транзакции, как верифицировать транзакции с Layer-1 (ETH Mainnet) и т.д.. Это УЖЕ сложно. Но несмотря на эти сложности, такой подход дает максимальную производительность. Таким образом, 4й тип позволяет построить максимально эффективную zk-среду.

Говоря о производительности мы имеем в виду строимость. Все упирается в стоимость. В случае с zk-proofs - они отлично параллелятся. Теоретически, вы просто добавляете “железа” для бОльшего количества параллельных потоков, и затем рекурсивно их компилируете для достижения ЛЮБОГО уровня пропускной способности при низкой задержке.

3й тип позволяет говорить об исполнении кода, который уже скомпилирован в нативный Эфириумовский байткод. Возможно, не со 100% совместимостью, возможно некоторые хэши будут исполняться по-другому, некоторые прекомпилированные коды могут не работать. Такой подход уже заставляет пойти на компромисс с производительностью, т.к. интерпретация кода EVM - это очень ресурсоемкая задача. EVM - не лучшая виртуальная машина, даже для обычной компьютерной архитектуры. А ее исполнение на zk усложняет задачу еще сильнее.

2.5 тип позволяет, плюс к вышеперечисленному, использовать полную совместимость с API (полная криптография EVM, прекомпайлы, keccak=keccak, SHA256=SHA256 и т.д.). Это накладывает немного меньший штраф на производительность (по сравнению с прыжком между 4м и 3м типами), т.к. этот штраф применим только в тех смарт-контрактах, в которых используются эти хэши\криптографические функции.

2й тип добавляет расчет газовой стоимости транзакций, точно такой же как в Эфириуме. Он дает максимальную совместимость на уровне приложений. Все инструменты и программы будут работать точно так же, как на Эфириуме. Он практически не влияет на производительность по сравнению с типом 2.5, т.к. в zk добавление арифметической операции (расчет газа) очень дешево.

1й тип - полная совместимость на корневом уровне блока. Вы исполняете блок,и кэш корня блока должен быть точно таким же, как если бы вы запускали его на L1. То есть, весь консенсус должен быть как на Эфириуме вместе с хранилищем. И основным штрафом в производительности тут выступает даже не консенсус, а именно хранение и доступ к данным.

Мы начинаем с 4го типа. Мы приняли осознанное мышление начать с 4го типа. Причиной этому послужила, снова, наша миссия ускорить массовое принятие. А для этого (привлечения миллионов, миллиардов людей) нужна соотвествующая технология. При таких показателях стоимость транзакций имеет решающее значение. Это сейчас транзакции в 0.10$ могут быть приемлемыми для DeFi-приложений. Однако, во многих других отраслях, например, микроплатежах, играх, социальных сетях - это неприменимо, там обрабатываются миллионы транзакций в день. И это было бы невобразимо дорого, поэтому цену транзакций необходимо свести к абсолютному минимуму. И мы хотим надеяться что доказательные технологии станут лучше, протоколы станут лучше, чтобы снижать стоимость транзакций все ниже и ниже до тех пор, пока мы не добьемся ценв 0.0000001$ за транзакцию. Поэтому мы ОБЯЗАНЫ начать с 4го типа, у нас нет выбора. Почему? Допустим, если у вас есть хорошее оборудование, вы всегда можете запустить эмулятор и запустить старые системы. Это обыденно запускать MS-DOS или Windows 3 в эмуляторе на MacBook Pro.

То же самое мы можем сделать и тут - запустить zkSync 3го типа внутри zkSync 4го типа. Нужно лишь написать смарт-контракт который будет интерпретировать байткод EVM, шаг за шагом считывающий байткод и исполняющий его. Это приведет нас к мощному базовому уровню 3го типа без серьезной головной боли. Мы можем написать смарт контракт на Solidity, может даже взять существующий код, который интерпретируется EVM. Оптимизм, Арбитрум имеет в этом наработки. ИЛИ мы даже можем применить код Rust и скомпилировать его в zk-совместимый код. В общем, это совсем небольшая надстройка, которая может перевести zkSync из 4го типа в 3й. Можем ли мы пойти дальше? Конечно! Это не так сложно добавить полноценную совместимость с API. По факту, мы будем поддерживать Keccak и SHA256 с первого дня. Так что, криптографические хэши будут на месте, их не так дорого имплементировать. Так zkSync станет типом 2.5 с минимальными усилиями.

Однако, если мы начнем с середины, с типа 2.5 - мы не сможем пойти вниз, на более производительные уровни. Вы можете эмулировать Mainframe на Macbook Pro, но не наоборот. Вам НЕОБХОДИМО начинать с базового наиболее производительного уровня, чтобы иметь возможность поставить эмулятор.

Можем ли мы пойти дальше? На типы 1 и 2? Дело в том, что они не релевантны для L2-решений. Для L2 решения не нужен корень блока из типа 1, т.к. он не позволяет использовать альтернативные методы консенсуса, которые нужны в L2. Так же расчеты газа тоже нерелевантны, т.к. профиль расчетов на L2 совсем другой. Тип ресурсов, которые мы потребляем на L1 & L2 - разный. Так что расчеты газа по типу L1 имеют очень специфические кейсы применения (например, валидация самого Эфириума, но зачем?).

Любой, кто любит Эфириум, хочет чтобы он мог обслуживать миллионы людей одновременно. И любая система, которая хочет этого достичь должна быть системой 4го типа изначально. Неважно, насколько эффективно решение 2го типа, решение 4го типа будет в сотни, а то и тысячи раз дешевле.

Алекс считает, что Эфириум в будущем должен стать более zk-Friendy. Но это должно решить комьюнити Эфириума. zkSync, начавшись как система 4го типа будет системой типа 2.5. Начинайте строить с нами!

v2.zksync.io

Встретимся в Mainnet’e!