Веб прошел долгий путь с 1989 года. То, что начиналось с простых статических страниц, превратилось в мир полноценных приложений, поддерживающих миллиарды пользователей.
Поскольку веб-приложения требовали динамического взаимодействия с элементами HTML-документа, был введен JavaScript. Он быстро стал популярным и некоторое время оставался единственным языком программирования, используемым в браузере.
Однако JavaScript, как стандарт, был полезен, но в то же время ограничен. Что, если некоторые разработчики не знали JavaScript? Что, если JavaScript не был самым лучшим языком для определенных задач?
Здесь на помощь пришел WebAssembly: низкоуровневый, портативный, бинарный формат и целевая компиляция для языков программирования высокого уровня. Он эффективен, безопасен и гибок.
Введение WebAssembly (Wasm) означало, что JavaScript больше не должен был быть единственным языком в вебе. Разработчики могли писать производительный код на таких языках, как Rust, Go, C, C++ и т. д., и компилировать их в модули Wasm для выполнения в браузере. Это открыло новые возможности для высокопроизводительных веб-приложений, таких как 3D-графика, видеомонтаж, игры и многое другое.
История Wasm не закончилась браузером. Со временем он вышел за пределы своих первоначальных задач и стал использоваться для создания самых сложных распределенных приложений.
Вот лишь несколько примеров того, как Wasm используется:
Электронная коммерция и оптимизация серверной части:
Shopify: Использует Wasm для оптимизации работы серверной части ради скорости и эффективности.
Инструменты для дизайна и сотрудничества:
Figma: Переход от asm.js к WebAssembly привел к тройному увеличению производительности.
Миграция AutoCAD: Подобно Figma, AutoCAD использует Wasm для решения сложных зависимостей Windows OS.
Мультимедиа и развлечения:
Netflix: Использует Wasm для создания интерактивных видеовзаимодействий, повышая вовлеченность пользователей.
Разработка ПО и инструменты:
Adobe: Инвестирует в WebAssembly, расширяя возможности разработки программного обеспечения в браузерной среде.
Microsoft: Интегрирует Wasm в Azure Functions, Visual Studio Code и Edge, формируя современные инструменты разработки.
Игры и интерактивные технологии:
Unity: Использует Wasm для создания высокопроизводительных игр на разных платформах.
Pinterest: Применяет Wasm для создания динамичного пользовательского опыта.
Инфраструктура и финансовые технологии:
Fastly/Cloudflare: Использует Wasm для повышения производительности сети, оптимизируя доставку контента.
Visa: Применяет Wasm для безопасной обработки платежей и защиты чувствительных данных пользователей.
Wasm способствовал инновациям в различных секторах. От электронной коммерции и развлечений до разработки ПО, игр, сетевых технологий и критически важных систем — влияние Wasm стало поистине преобразующим.
Переносимся в эпоху Web3, где Wasm также оказался крайне востребован. За последние пять лет он был принят как среда выполнения для многих крупных блокчейн-проектов. Вот несколько значимых примеров:
Cosmos для его L1 SDK
NEAR для его шардированного L1
Polkadot для его L1 SDK
Причины популярности Wasm в Web3 не сильно отличаются от причин его популярности в Web2. Это эффективность, стандартизация, безопасность и, конечно, гибкость выбора языков программирования. Вот как звучит видение Internet Computer, представленное техническим лидером Dfinity на тот момент Андреасом Россбергом, который также является соавтором Wasm:
«Наша цель — чтобы разработчики могли программировать в Internet Computer на любом языке, который им нравится.»
Поддержка языков общего назначения не только создает более интуитивно понятный опыт для разработчиков, работающих с Web3, но и позволяет миллионам новых разработчиков строить решения на блокчейне. Каждый из вышеупомянутых проектов (а также несколько других, таких как Tezos, EOS и др.) понимал, что выполнение через Wasm — это мощная идея.
Что же произошло? Почему миллионы разработчиков не строят решения на блокчейне? Почему Wasm не стал самой популярной средой выполнения в нашем еще довольно нишевом мире Web3?
Никто не выразил суть проблемы лучше, чем Шрирам Каннан из EigenLayer. Исторически, чтобы внедрять инновации в среды выполнения (а также любую другую основную инфраструктуру), нужно было создать децентрализованную сеть доверия. Необходимо было собрать группу валидаторов и привлечь капитальные вложения.
Это очень трудно сделать устойчивым способом. Создать действительно децентрализованную и разрешенную сеть доверия (которая не будет субсидироваться венчурными капиталистами или легкими деньгами) — это как начать революцию. Для этого нужно совершенно другое мастерство, чем для разработки распределенных систем.
«Создание децентрализованной сети доверия — это как найти единорога. Децентрализованное доверие не является общим свойством. Оно возникает из социального консенсуса, который формируется годами» — Шрирам Каннан.
Реальность такова, что лишь немногие блокчейн-проекты — даже те, у которых есть впечатляющие технические инновации — смогли создать устойчивые сети доверия. Можно утверждать, что только два блокчейна смогли это сделать на данный момент: Bitcoin и Ethereum. Это затрудняет достижение высоких темпов распространения таких новых сред выполнения, как Wasm.
Естественно, возникает вопрос: если выполнение через Wasm так желанно, почему Bitcoin и Ethereum не приняли эту технологию?
Для Bitcoin ответ прост. Сеть доверия Bitcoin дает несколько ключевых обещаний, одно из которых — «без хардфорков». Это сразу исключает возможность замены ограниченной скриптовой среды Bitcoin на более программируемую среду Wasm.
Для Ethereum необходимо немного углубиться в историю.
Ethereum flavored Wasm (Ewasm) был предложен в 2015 году и рассматривался в течение нескольких лет. Чтобы было понятно, Ewasm — это «ограниченный подмножество Wasm, которое должно было использоваться для контрактов в Ethereum».
Целями проекта Ewasm были создание транслятора EVM, реализация виртуальной машины, инжектор учета метрик и многое другое. Чтобы лучше понять концепцию Ewasm, ознакомьтесь с следующими ресурсами:
В конечном итоге Ethereum Foundation решила отказаться от Ewasm и остаться с выполнением через EVM. Несмотря на определенные проблемы с совместимостью и шардированием выполнения, решение стало частью более широкой стратегической переориентации. Эта переориентация была исследована Виталиком Бутериным и Кейси Детрио, а позже официально оформлена как «дорожная карта Ethereum, ориентированная на роллап».
Зачем произошел этот поворот?
Сообщество Ethereum не формулировало это так прямо в тот момент, но они осознали мощь модульной архитектуры блокчейна и как она открывает возможность для разрешенных инноваций на более высоких слоях стека. Они поняли, что это лучший подход.
Итак, мы подошли к сегодняшнему дню. Дорожная карта, ориентированная на роллап, в полном разгаре, так как Ethereum оптимизирует для достоверной нейтральности, проверяемости, безопасности и пропускной способности данных, в то время как тысячи (роллапов) расцветают.
Вместо одного эксперимента по шардированию выполнения любой человек в мире может настроить роллап, как угодно, для любого случая использования. Некоторые роллапы будут использовать EVM, другие — Wasm. Некоторые роллапы будут использовать доказательства мошенничества, а другие — доказательства с помощью ZK. Некоторые будут успешными, другие — нет. Но все они будут разрешенными для проб.
В Fluent наша миссия — воплотить выполнение через Wasm в Ethereum в реальность.
Мы считаем, что команды Wasm двигались в правильном направлении и глубоко разделяем ценности Ethereum. Мы уверены, что технологии ZK откроют новый способ решения проблемы, и что для открытия доступа к безопасному блокспейсу необходимо создать в 10 раз лучшие условия для разработчиков.
Если это вам откликается, присоединяйтесь и создавайте вместе с нами!