Я по-настоящему глубоко понимаю, насколько важно внедрять вычисления с полной децентрализацией — и за этим стоит одна довольно особенная история, которой стоит поделиться. Так что слушайте, я расскажу по порядку.
Ещё в 2015 году я уже занялся ранней криптовалютной средой, но при этом продолжал управлять созданной мной ранее «Fight My Monster» — MMO (массовая многопользовательская онлайн-игра) и социальной платформой с 3 миллионами пользователей, которая в финансовом плане могла существовать за счёт собственных средств и имела поддержку венчурных инвесторов.
Хотя я уже нашёл долгосрочное призвание в сфере децентрализованных вычислений, я не могу подвести игроков, которые всё это время поддерживали эту игру.
«Fight My Monster» разрабатывался в период с 2010 по 2012 годы и использовал архитектуру, которая тогда была крайне инновационной. Такая архитектура позволяла платформе масштабироваться с низкими затратами и при минимальном объёме операционной работы (то есть обслуживать миллионы пользователей).
По сути, система состоит из трёх ключевых компонентов бэкенда. Первый — простой веб‑хостинг, который раздаёт код фронтенд‑игры и ресурсы в браузер пользователя (тогда я использовал популярную сеть доставки контента — CDN).
Как и у веб‑хостинга, ещё два компонента бэкенда тоже должны уметь «горизонтально масштабироваться». Это означает, что чтобы обслуживать больше пользователей и их вычислительные и data‑потребности, мне нужно лишь добавлять аппаратные ресурсы — без переписывания кода бэкенда и без утомительных задач администрирования системы. Благодаря этому свой проект на раннем этапе я смог быстро масштабировать, имея очень мало людей и средств.
Второй компонент — горизонтально масштабируемый фреймворк игровой серверной архитектуры под названием «Starburst». Это результат моей прямой личной работы: я построил его на базе open‑source‑сервера, поддерживающего протокол RTMP. RTMP — это сетевой протокол, разработанный Adobe, который позволяет Flash‑медиа‑ресурсам (помните Flash?) — тем, что работают в веб‑браузере, — напрямую общаться с сервером. Starburst отвечает за логику игры и социального взаимодействия и почти в реальном времени маршрутизирует для пользователей огромное количество событий, генерируемых в игре.
Третий компонент — горизонтально масштабируемая NoSQL‑база данных Cassandra (если вы следите за миром баз данных, вы наверняка знаете её современную производную — ScyllaDB: она сейчас отлично справляется с требованиями реального времени для AI).
Стоит отметить, что в моей команде был единственный (помимо исходной компании‑разработчика Cassandra) «core committer» по Cassandra. Кроме того, я входил в число первых пользователей, кто действительно загрузил Cassandra beta в высоконагруженную продакшн‑среду. Когда аудитория достигла 800 тысяч, база данных повредилась. Последующие 24 часа были просто нервным кошмаром: мне пришлось в авральном режиме восстанавливать данные и поднимать систему заново (в тот момент я чувствовал, будто лечу в облака — а в следующую секунду казалось, что всё уже безвозвратно потеряно, но в итоге всё обошлось).
Cassandra лучше всего тем, что вы можете горизонтально масштабировать хранилище, пропускную способность чтения и — самое важное — пропускную способность записи просто добавляя узлы (серверы с большими объёмами жёстких дисков). Эта функция довольно редкая, но для моего приложения она была критически важной, потому что «Fight My Monster» генерирует колоссальные объёмы данных.
Конечно, у Cassandra есть ещё одно важное преимущество: отказоустойчивость. Я настроил 5 реплик (replication factor = 5), что означает, что данные каждого человека очень безопасны (по крайней мере, тогда я так считал…). Конфигурация с 5 репликами означает, что для любого конкретного «кворума» (quorum) система может успешно записывать данные при условии, что в сети онлайн находятся как минимум 3 узла.
В отличие от блокчейна, Cassandra не обладает функциями византийской отказоустойчивости — то есть мне нужно тщательно управлять безопасностью инфраструктуры, чтобы предотвратить атаки хакеров или вредоносного ПО. Однако тогда хакеров не интересовала MMO‑игра и социальная сеть, основной аудиторией которой были дети, и при этом она не была универсальной платформой, на которой другие могли бы что‑то строить.
Основное техническое давление на меня связано с тем, что из‑за огромных объёмов генерации данных узлы, несущие базу данных, испытывают колоссальную нагрузку — из‑за чего они постоянно «падают»! А это значит, что мне приходится время от времени заходить в инфраструктуру, выводить из строя отказавшие узлы и добавлять новые. К счастью, всё это несложно: благодаря механизму отказоустойчивости эта работа не требует аврала, а эти «голые» (bare metal) серверы можно единообразно планировать через моего облачного провайдера…
«Fight My Monster» использует архитектуру, опережающую своё время — благодаря ней мне было очень легко добиться масштабирования. Плюс его отказоустойчивость и лаконичная бэкенд‑архитектура всего из 3 ключевых компонентов означают, что управленческая нагрузка и объём работ по поддержанию системы минимальны. Итак — чему это было обусловлено: какая такая «одна вещь» оказалась настолько важной, что и сегодня глубоко влияет на мой образ мышления и на развитие ICP? Вы наверняка чувствуете, что тогда произошло нечто необычное: теперь я впервые публично расскажу об этой истории.
В то время я разъезжал по Азии. Я был участником раннего «путешествующего коллектива» ключевого сообщества Ethereum, ездил к соответствующим сторонам (люди часто недооценивают — особенно в случае Китая — ту важную поддержку, которую Азия сыграла в развитии раннего крипто‑сектора) и принимал участие в самых разных мероприятиях, связанных с Ethereum. На этих встречах я в основном обсуждал сложные технологии компьютерных наук, которые разрабатывал сам — чтобы повысить масштабируемость и производительность сетей вроде Bitcoin и Ethereum.
Мне не хочется долго расписывать «давние времена в мире криптовалют», но я скажу: это было волшебное время. Ранние участники оставили мне так много прекрасных воспоминаний — я искренне благодарен. Это время оказалось настолько увлекательным, что мне даже некогда было проверять почту.
В итоге в пути я пропустил сотни писем — все они предупреждали меня: кредитная карта, которой нужно платить за Cassandra‑узлы проекта Fight My Monster, уже просрочена…
Так что же сделал облачный провайдер, когда я не отвечал пару недель (точное время уже не помню, но это было недолго)? Да очень просто: они удалили все узлы!!!
Трудно описать, что я почувствовал, когда вернулся в Пало‑Альто (Palo Alto, штат Калифорния) и увидел всё это: тут было смешение шока и ужаса. Пустота в желудке, адреналин зашкаливал, страх расползался всё дальше. Я изо всех сил пытался спасти положение, но в итоге подтвердилось, что уже ничего не исправить. Любой, кто сталкивался с тем, как в крипто‑сфере взламывают людей, наверняка поймёт это ощущение.
Вот и всё. Fight My Monster полностью ушёл в небытие. В сообществе даже кто‑то поднял петицию на Change.org с просьбой вернуть его в строй.
Хотя я и упустил ту ценность, которую оно могло создать, мне всё равно было немного стыдно, но в некотором смысле это приносило облегчение: мне больше не нужно было нести ответственность за его поддержание (иначе я, возможно, поддерживал бы его для сообщества бесконечно). Кроме того, это стало прекрасной памятью для целого поколения детей (и части взрослых), которые поиграли в эту игру, и она завершилась ещё до того, как успела устареть и стать скучной. А ещё это позволило мне сосредоточиться на той области, которой я тогда был по‑настоящему увлечён: децентрализованных вычислительных сетях.
Однако я извлёк из этого очень глубокий урок: вы можете построить децентрализованную вычислительную инфраструктуру с масштабируемостью и отказоустойчивостью, но если в любой момент времени и на любом этапе существует единая точка отказа, то вся система может полностью рухнуть.
Именно поэтому, когда я слышу, что некоторые блокчейны зависят от администраторских ключей, находящихся у основного разработчика, или когда вижу, что из‑за отключений облачными провайдерами либо технических сбоев отключается (и даже оказывается на грани паралича) большое число узлов, я неизменно испытываю серьёзную тревогу. Эта сверхуязвимость в нашей отрасли встречается куда чаще, чем вы, вероятно, думаете.
Горький урок, полученный в ходе случая Fight My Monster, глубоко повлиял на философию дизайна Internet Computer. Важно не только количество узлов — есть и куда более критичные факторы. Если узлы анонимны, то число независимых субъектов, реально запускающих большую часть узлов, может оказаться намного меньше, чем вы ожидаете. Кроме того, даже когда узлов много, они нередко работают на платформах лишь у нескольких облачных провайдеров — и даже если узлы принадлежат разным сущностям и ими управляют разные организации, провайдеры всё равно могут внезапно решить больше их не поддерживать и «выключить» их за одну ночь (как это делал Hetzner с одним известным блокчейн‑проектом).
На практике по‑настоящему важно число независимых субъектов, которые запускают узлы, и то, насколько независимы узлы по физическому размещению и юрисдикции. Именно это простое наблюдение и является краеугольным камнем идеи «детерминированной децентрализации» (deterministic decentralization), которая в новом виде воплотится в расширении функциональности «облачных движков» (ICP cloud engines), которые скоро выйдут в Internet Computer.
Облачные движки ICP позволяют компаниям (как правило) создавать фактически принадлежащие им собственные подсети Internet Computer и самим контролировать их настройки. Компания может комбинировать узлы, выбирая их из пула узлов, который играет роль «рынка». На данный момент уже более 1500 узлов находятся в режиме ожидания, и это число продолжает расти.
«Движок» предоставляет серверless‑облачную платформу с выдающимися характеристиками — это идеальное место для разработки AI‑приложений и сервисов, потому что её технологический стек специально спроектирован для того, чтобы AI мог легко генерировать продвинутые AIware‑приложения, причём эти AIware‑решения одновременно и безопасны, и обладают высокой устойчивостью (韧性).
Эти приложения обладают защитой от подделки (то есть устойчивы к хакерским атакам на уровне инфраструктуры), всегда онлайн (а значит, очень устойчивы), поддерживают опциональное автономное выполнение (что означает отсутствие бэкдоров), нативно поддерживают цифровые активы и многое другое. Движок также может запускать AIware‑приложения вроде Open SaaS‑пакета, помогая компаниям реализовать сквозную бизнес‑операционку. А cloud engines делают установку и поддержку сложных приложений, например Open CRM или Open Email, такими же простыми, как установка приложения на телефон.
Узлы поддерживают горячую замену, то есть вы можете менять коэффициент репликации вычислений или заменять узлы, не прерывая сервисы, которые размещены движком в облаке. Это избавляет вас от зависимости от конкретного поставщика вычислительных услуг. Кроме того, вы можете выбрать новые типы узлов, размещённых у гипермасштабируемых облачных провайдеров (hyperscalers), а также традиционные узлы Internet Computer — и превратить это в универсальный рынок вычислительных ресурсов.
Фреймворк cloud engines подсказывает пользователю комбинировать узлы с независимостью, одновременно предоставляя гибкость, которой не хватает при «общем» хостинге Internet Computer. Например, немецкая компания может выбрать узлы только в пределах ЕС, чтобы соответствовать требованиям GDPR (Общего регламента по защите данных).
Однако автономная панель управления облачными движками, которые размещает сеть Internet Computer и которые обновляет NNS (Network Nervous System — глобально самый передовой DAO), подскажет пользователям. Если пользователь собрал узлы от одного провайдера, в одном дата‑центре или управляемые одним облачным оператором, панель выдаст резкие предупреждения.
Поэтому даже в контексте облачных движков ICP (Cloud Engines) уроки, полученные благодаря проекту «Fight My Monster», по‑прежнему имеют практическую ценность.
Люди могут задаваться вопросом, почему этот фреймворк так настойчиво продвигает объединение различных независимых узлов — на самом деле у этого есть веские причины. И эта причина для более широкого блокчейн‑сообщества сегодня так же важна, как и в 2015 году.
Скоро буду рад поделиться с вами подробностями о cloud engines.
Который вас интересует: контент про IC
Технический прогресс | Информация по проекту | Глобальные события
Сохранить и подписаться на канал IC — Binance
Осваиваю свежие новости