В рамках концепции Web 3.0 принято считать, что мы находимся в инфраструктурной фазе, и сейчас самое время работать над созданием инфраструктуры: улучшать базовые цепи, оперативную совместимость между цепями, кошельки и браузеры. Объясняют это так: сначала нам нужны инструменты, которые будут упрощать создание и использование приложений, работающих на блокчейне, а когда у нас появятся эти инструменты, мы сможем начать создавать приложения.
Но разговаривая с людьми, строящими инфраструктуру, мы узнаем, что по-прежнему самая большая проблема — заставить разработчиков создавать на ней приложения. То есть если мы действительно находимся в инфраструктурной фазе, с чего бы такому происходить?
Наша гипотеза состоит в том, что на самом деле все работает иначе. Мы находимся не в инфраструктурной фазе, а на вираже цикла «приложения—инфраструктура». И в действительности история новых технологий демонстрирует, что приложения порождают инфраструктуру, а не наоборот. Мы не строим всю необходимую инфраструктуру, чтобы потом начать создавать приложения. Все наоборот.
Все знают, что «платформы» часто дают самые большие возможности для зарабатывания (это верно для Facebook, Amazon/AWS, Twilio и т. д.), так что вполне понятно стремление создать крупную платформу, которая будет приносить доход. Еще более верно это может быть для распределенной сети, где доход часто, хоть и не всегда, накапливается на уровне протокола, а не приложений, работающих на платформе.
Но, как мы увидим, платформы эволюционируют в процессе повторения цикла «приложения => инфраструктура => приложения => инфраструктура» и редко создаются на голом месте.
Изначально приложения побуждают создать инфраструктуру. Затем эта инфраструктура позволяет создавать новые приложения.
На примере ряда крупных платформ мы видим, что сначала возникает прорывное приложение, затем это приложение вдохновляет на создание инфраструктуры, которая упрощает создание похожих приложений, и инфраструктуры, которая позволяет широкому кругу потребителей использовать эти приложения. Это выглядит примерно так:
Например, лампочки (приложение) изобрели до того, как появилась электрическая сеть (инфраструктура). Для лампочек электрическая сеть не нужна. Но для широкого использования ламп накаливания сеть нужна, поэтому сначала в 1879 году была лампочка (прорывное приложение), а за ней в 1882 году появилась электрическая сеть.
Другой пример: самолеты (приложение) изобрели до того, как появились аэропорты (инфраструктура). Чтобы иметь самолет, не нужен аэропорт. Но для широкого применения самолетов аэропорты нужны, поэтому сначала появился самолет в 1903 году, это подвигло людей создать первую авиакомпанию в 1919 году, затем появились аэропорты — в 1928-м и управление воздушным движением в 1930-м. Но вначале был самолет.
Та же картина с интернетом. Сначала появились приложения: обмен сообщениями (1970) и электронная почта (1972), они побудили создать инфраструктуру, упрощающую широкое распространение обмена сообщениями и электронной почтой: Ethernet (1973), TCP / IP (1973) и провайдеры интернет-услуг (1974). Затем появилась следующая волна приложений — веб-порталов (Prodigy в 1990 году, AOL в 1991 году), а веб-порталы вдохновили на создание инфраструктуры (поисковые системы и веб-браузеры в начале 1990-х годов). Следующая волна приложений — сайты, такие как Amazon.com (1994), они подтолкнули к созданию инфраструктуры языков программирования (PHP в 1994 году, Javascript и Java в 1995 году), которые упрощали создание сайтов. За этим последовала новая волна более сложных приложений, таких как Napster (1999), Pandora (2000), Gmail (2004) и Facebook (2004), что привело к созданию инфраструктуры, упрощающей разработку более сложных приложений (NGINX и Ruby on Rails в 2004, AWS в 2006 году). И цикл продолжается.
Этот же шаблон мы видим в области мобильных приложений: например, сначала был набор популярных мобильных приложений, которые в значительной степени полагались на потоковое видео: Snapchat (2011), Periscope (2014), Meerkat (2015) и Instagram Stories (2016). А потом компании создали инфраструктуру, позволяющую мобильным приложениям добавлять видео: Ziggeo (2014), Agora.io (2014), Mux (2017), Twilio Video API (2017), Cloudflare Stream (2018).
Этот цикл позволяет правильно расставить и порядок событий в Web 3.0. Мы начали с первого прорывного приложения — BTC (2008), работающего в сети Bitcoin (первая инфраструктура). Вскоре появился Silk Road (2011) — печально известное криптографическое приложение. Это побудило создать новую инфраструктуру, например Sidechains и Drivechain (2015), Ethereum Smart Contracts и ERC20 (2015), Lightning (2015), позволяющую легко создавать новые приложения, и такую инфраструктуру, как Coinbase (2012) и Metamask (2016), позволяющую потребителям пользоваться этими новыми приложениями. Новая инфраструктура породила следующую волны приложений: токены/ICO (2017) и первые децентрализованные приложения (Rouleth и vDice в 2016 году, CryptoKitties в 2017 году), которые привели к созданию новой инфраструктуры: Infura (2016) и Web3js и Zeppelin (2017). Теперь остается ждать следующих заметных приложений, которые послужат ориентирами для новой инфраструктурной волны.
Смежные возможности
Общее в развитии каждой крупной платформы (будь то электричество, автомобили, самолеты, интернет или мобильные устройства) то, что строим мы то, что можем, используя те инструменты, которые доступны нам в этот момент. В книге Where Do Good Ideas Come From («Откуда берутся хорошие идеи»), Стивен Джонсон называет это «смежной возможностью». Другими словами, можно открыть дверь в соседнюю комнату, но нельзя сразу открыть заднюю дверь с переднего крыльца. Сложно построить успешную инфраструктуру, если она сильно опережает рынок приложений.
При каждом повторении цикла «приложения => инфраструктура» создание новых приложений становится возможным благодаря инфраструктуре, построенной в предыдущих циклах. Например, YouTube мог возникнуть в 2005-м, но не в 1995 году, потому что YouTube имеет смысл только после развертывания такой инфраструктуры, как широкополосная связь в начале 2000-х годов. Это произошло в инфраструктурную фазу, последовавшую за взлетом успешных «доткомовских» сайтов, таких как eBay, Amazon, AskJeeves и моего любимого Neopets.
Крис Диксон и Фред Уилсон рассказывают об этой концепции в недавнем эпизоде подкаста a16z. У Криса есть настольная игра времен доткомов под названием Dot Bomb, в которой высмеиваются нелепые доткомы конца 1990-х. Так вот он заметил, что все «нелепые» идеи эпохи доткомов сегодня превратились в «единорогов» с миллиардными оборотами. То, что возможно сейчас, после нескольких циклов «приложения => инфраструктура» в сфере интернета, не имело смысла один-два цикла назад.
В этом основная проблема мифа об инфраструктурной фазе: если думать об «инфраструктурной фазе» в отрыве от приложений, которые будут использовать инфраструктуру, то мы рискуем забежать слишком далеко, в гипотетическую пустоту. Для надежности нам нужен цикл «приложения => инфраструктура => приложения => инфраструктура».
Чем больше циклов для каждой новой платформы, тем дешевле создавать и использовать эти приложения. Создание usv.com в 1995 году стоило бы нам на порядки больше, чем сегодня, а создание приложений Web 3.0 требует больше денег, усилий и времени сейчас, чем через 15 лет.
Технологические принципы против инвестиционных
Примерим на себя на минуту роль инвестора. Важно различать технологические принципы, которые объясняют, когда что-то можно создать, и инвестиционные, которые определяют, когда на чем-то можно хорошо заработать.
Цикл «приложения => инфраструктура => приложения => инфраструктура» объясняет, когда могут быть созданы приложения или инфраструктура, но не обязательно объясняет, когда инвестировать в приложения, а когда инвестировать в инфраструктуру.
Возьмем, например, лампочки. Да, они были изобретены до возникновения электросети, но, в разрезе инвестиций, лампочки отвратительно продавались, пока не построили электросеть.
Подводя черту
Главный вопрос: почему цикл начинается с приложений, а не с инфраструктуры? Одна из причин заключается в том, что нет смысла создавать инфраструктуру до того, как появятся приложения с потребностью решить их проблемы с инфраструктурой. Как можно узнать, что создаваемая инфраструктура будет решать реальные проблемы, пока нет приложений, для которых эти решения предназначены? Сложно сейчас создать криптоинфраструктуру, пока нет прорывного криптоприложения, которому другие разработчики захотят подражать, для чего им понадобятся более эффективные инструменты разработки и инфраструктура.
В криптопространстве бытует мнение, что сначала нужно создать отличные инструменты, а когда они будут, мы сможем создавать приложения. Но, как мы продемонстрировали примерами из других областей, необходимо создать первые несколько приложений, прежде чем появятся отличные инструменты (хотя это и более затратно и по деньгам, и по времени), а уж затем эти ранние приложения вдохновят на создание инструментов. А потом цикл повторится.
Удачи в разработке!
***
Обновление (5 октября 2018 г.).
Было верно замечено, что криптосети, по сути, размывают границы между приложениями и инфраструктурой благодаря своей природе открытости и взаимозаменяемости. И это то, что нам в них больше всего нравится. Так, например, «приложение» (будь то CryptoKitties или любой смарт-контракт, или сам биткоин) может быть инфраструктурой, если кто-то разрабатывает на его основе. Конечно, есть компоненты этих сетей, являющиеся только инфраструктурой (Lightning, Zeppelin и т. д.), но граница размыта. В то время, как ранее платформы (например, Amazon или Facebook) должны были принять сознательное решение открыть API-интерфейсы и стать платформой, криптографические приложения, как правило, открыты и совместимы с первого дня. Это только сокращает цикл «приложения => инфраструктура => приложения => инфраструктура». Благодарим Дениса Назарова и Ютту Стайнер за то, что осветили этот момент.
***
