Одно из применений криптовалют, которым мы не устаём восхищаться – распределённые вычисления. До появления криптовалют мой ноутбук не мог перевести оплату стороннему устройству в качестве благодарности за эксплуатацию программы машинного обучения. Криптовалюты, наконец, подарили нам возможность совершать автоматизированные платежи между машинами, компенсируя узлам их участие в выполнении вычислительных задач.
В июне я написал обзор типов проектов распределённых вычислений. С тех пор прошло не так много времени, но эта область очень быстро развивается, поэтому я продолжу делиться тем, что мы узнали за этот период.
Изолированные сети и открытые протоколы
Есть два способа выполнения распределённых вычислений. В одной модели мира существует доминирующий протокол распределённых вычислений, который создаёт общую сеть компьютеров, на базе которой любой желающий может построить интерфейс и привлекать пользователей. Сюда можно отнести Heroku и EC2. Оба сервиса работают на базе AWS-серверов, но предлагают два совершенно разных интерфейса, созданных для решения кардинально отличающихся задач, направленных на разные аудитории.
В другой модели мира есть несколько доминирующих проектов распределённых вычислений, каждый из которых имеет свою сеть узлов.
Обе модели мира позволяют сосуществовать нескольким проектам, направленным на разные аудитории. Но в одной из них проекты являются клиентами, созданными на базе одного и того же пула ресурсов, а в другой каждый из таких проектов использует собственную независимую сеть. Обе модели мира могут сосуществовать, но, на мой взгляд, это маловероятно из-за сетевых эффектов. Проектам, имея такую возможность, предпочтительнее подключиться к существующей сети компьютеров, а не создавать собственную, так как благодаря доступу к более мощному CPU их клиенты получат лучшее качество сервиса в первый же день, чего нельзя добиться, начиная строить сеть с нуля.
В настоящее время существуют попытки создания обеих моделей. SONM – один из проектов, который создаёт платформу совместного пользования. Другой пример этой же модели – Distributed Compute Protocol (DCP), создаваемый компанией Distributed Compute Labs. Большинство других проектов на сегодняшний день создают собственные сети. Хотя, поскольку это проекты с открытым протоколом, любой желающий может создать альтернативный интерфейс к ним. Зачастую проекты начинают в качестве самостоятельных систем, а затем естественным образом становятся лишь одним из клиентов на базе своей теперь уже совместно используемой платформы. Меня радует потенциал единых вычислительных ресурсов, а также команды и проекты, которые их развивают.
Многие считают, что в области создания программ-клиентов на базе открытого протокола царит высокая конкуренция, так как пользователи легко могут перемещаться от одной программы к другой. Вспомните: когда Twitter только появился, создавалось множество Twitter-клиентов. У пользователей был огромный выбор подобных программ, поэтому в этой нише было сложно достичь успеха. Однако в сфере вычислений, где продуктом является интерфейс, всё по-другому. Если окажется, что API программ-клиентов отличаются, поскольку разработчики интегрировали их в свой программный код и CI/CD процессы, программы могут быть очень привлекательны для пользователей, даже если в них используется одно и то же серверное приложение. Я считаю, что это важная особенность вычислений, которая будет только стимулировать разработчиков создавать проекты на базе единого пула ресурсов.
Проблема токенов
Один из вопросов, который нас волнует: какие токены будут использоваться разработчиками и какие токены будут использоваться конечными пользователями. То есть: если пользователь взаимодействует с децентрализованным приложением, созданным на базе распределённой вычислительной сети, в каких токенах он производит оплату? В тех же самых, что используются для внутренних расчётов приложения с сетью, или в других?
На сегодняшний день, как правило, это разные токены. Например, такие проекты, как Akash, Render, Perlin, Enigma и SONM, используют для транзакций собственные токены. Эта же схема используется в проекте IPFS/Filecoin, где пользователи предположительно будут оплачивать услуги в одной из основных криптовалют (сейчас это, по всей видимости, должны быть ETH или BTC), а приложения затем самостоятельно будут обменивать их на внутренние токены, необходимые для предоставления услуги.
С другой стороны, Hypernet и Truebit являют собой примеры вычислительных проектов, использующих два типа токенов. В Truebit, например, покупатели могут оплачивать услуги в ETH, а родной токен проекта Truebit, TRU, используется только для подтверждения и урегулирования разногласий, возможных в рамках реализации протокола проекта. Эта же схема применяется в новых инфраструктурных проектах, запущенных в этом году, таких как The Graph и Augur. Для транзакций в них используется основная популярная валюта, а собственный токен применяется только для внутреннего управления, подтверждения и решения возникающих разногласий. Я считаю, что в будущем будет появляться больше проектов с моделью, построенной на использовании двух токенов, так как она позволяет увеличивать стоимость управления приложениями по мере роста сети, при этом не затрагивая стоимость услуги для пользователей.
Модели EC2 и Lambda
В сфере веб 2.0 есть два основных типа вычислительных сервисов. В EC2 разработчики предоставляют ресурсы для функционирования и хостинга серверов. В лямбда-архитектуре разработчики прописывают функции, которые потом в нужный момент запускаются и выполняются.
Эти две категории применимы и для распределённых вычислительных проектов. Некоторые из них можно сравнить с лямбда-архитектурой (или с Cloudflare Workers
), когда пользователь пишет скрипт, который затем выполняется на компьютерах, участвующих в проекте. Другой подход – это EC2 модель или «использование чужого компьютера». Пользователь соединяется с другим пользователем в сети и использует свободную мощность его компьютера.
Заметим, что лямбда-подход здесь отличается от реальной лямбда-архитектуры: компьютеры в вычислительных сетях, созданных по принципу лямбда-архитектуры, не хранят все когда-либо загруженные в них функции. Наоборот, эти сети предназначены для обработки данных в офлайн режиме, а также асинхронных скриптов для таких областей, как научные расчёты и построение графиков. По мере развития, этот подход всё больше напоминает внесерверную обработку данных.
Экосистеме нужны обе модели: хостинг пользовательского интерфейса децентрализованных приложений требует наличия постоянного хоста, а выполнение разовых вычислений лучше производить на платформах с внесерверной обработкой данных.
Примеры проектов, созданных по хостинговой модели – Akash и DADI. С точки зрения пользователей, у Akash очень много общего с традиционными вычислительными сервисами. Разработчики управляют контейнерами на компьютерах, подключенных к сети Akash и входящих в кластер Kubernetes, который может быть объединён с компьютерами Akash. (Неслучайно проект Akash был создан Грегом Осури, одним из участников Federated Kubernetes). Если вам захочется попробовать сервис Akash, недавно они запустили тестовую версию.
Примеры проектов, использующих внесерверные платформы – Ankr и DCP.
Устройства пользователей
Распределённые внесерверные вычислительные проекты отличаются от криптовалютных распределённых вычислительных сетей тем, что они могут запустить код на любом телефоне или ноутбуке, так как им не требуется постоянно поддерживать данные вычислительной среды, кроме разовой обработки одного небольшого скрипта.
Идея в том, что эти проекты могут объединить все неиспользуемые мощности CPU конечных пользователей, чтобы создать гигантский суперкомпьютер, пользоваться которым будет дешевле, чем современными облачными разработками.
[Кстати о цене: в качестве главного аргумента здесь приводят то, что вычислительные сети будут дешевле, так как им не нужно оплачивать физическое пространство для размещения оборудования, а капитальные затраты на «железо» уже учтены. Но по мнению Mario @ Placeholder, стоимость услуг облачных вычислений итак постоянно снижается, и если появятся поставщики распределённых вычислений, предоставляющие услуги по ещё меньшей цене, облачные провайдеры, скорее всего, тоже понизят стоимость до минимального уровня и сохранят конкурентоспособность.]
Мне очень нравятся проекты, которые могут предоставить доступ к среде с высоким уровнем вычислительной мощности, объединяя доступные CPU на устройствах конечных пользователей.
Но выполнение кода на девайсах пользователей требует решения трёх главных проблем. Первая из них состоит в том, чтобы привлечь к участию в проекте достаточное количество пользователей. Об этом мы писали в предыдущем посте.
Вторая проблема в том, что устройства пользователей имеют относительно низкую мощность. Для её решения разработчики проектов внедряют принцип параллельной обработки данных, что позволяет выполнять код на нескольких устройствах одновременно. В проекте Ankr пользователи сами разбивают код на блоки и по отдельности отправляют в сеть, где они распределяются между несколькими компьютерами. DCP автоматически распределяет подзадачи приложения между компьютерами в форме JavaScript объектов, которые выполняются в web workers (с целью увеличения скорости обработки DCP также разумно использует WebGL для подключения к GPU на устройствах пользователей).
Третья проблема заключается в незащищённости устройств пользователей. Сейчас широко используется SGX, надёжное аппаратное окружение, встроенное в чипы Intel. Enigma запустила тестовую сеть, использующую SGX для вычислений, Golem запустил Graphene-ng, чтобы разработчикам в написании кода с поддержкой SGX, а Oasis Labs при поддержке нового криптофонда a16z, собрали 45 миллионов долларов для создания проекта распределённых вычислений с интеграцией SGX. Ноутбуки трёх ведущих производителей, HP, Lenovo и Dell поддерживают SGX. У макбуков есть чипы, поддерживающие SGX, но настройки BIOS не включают поддержку этого расширения операционной системой. Когда Apple добавит SGX, уже 4 ведущих производителя ноутбуковвнедрят SGX-поддерживаемые вычисления. Я горячо поддерживаю внедрение SGX, так как эта технология обеспечивает хороший уровень защиты и доступна на ноутбуках пользователей.
Помимо SGX, верификация вычислений в распределённых вычислительных протоколах может производиться через устранение разногласий. Truebit – один из вычислительных проектов с протоколом устранения разногласий, который они называют “verification game” (верификацией в игровой форме). В этой системе верификатор вносит депозит в токенах TRU, чтобы проверить результат вычислений. В «игровом» устранении разногласий в Truebit результаты вычислений «решателя» хэшируются на каждом шаге выполнения программы (на самом деле любое задание может оказаться невыполнимым из-за превышения лимита газа, установленного в сети Эфириум, поэтому TrueBit разбивает каждое задание на 12 подшагов). Затем верификатор проверяет получившиеся части решения, используя бинарный поиск для нахождения конкретной операции, которая вызвала расхождения. Вызвавший разногласия шаг или подшаг затем направляется в сеть Эфириум для получения окончательного решения. Сторона, предоставившая неверный результат, теряет свой депозит, который начисляется выигравшей стороне.
Место вычислительных технологий в структуре сети
Остаётся открытым вопрос: решением первого или второго уровня будут являться вычислительные сервисы? То есть будет ли блокчейн следующей крупной сети включать вычисления на уровне встроенного сервиса или же они будут производиться исключительно офчейн?
Сейчас они выполняются офчейн, потому что основные блокчейны, в которых они доступны – это либо Биткойн (ограничиваемый скриптовым языком, на котором он написан), либо Эфириум (вычисления в котором очень затратны и медленны). Очень может быть, что в будущем на 1 уровне блокчейна будет возможность производить вычисления без необходимости задействовать в выполнении одних и тех же расчётов каждый узел. Это сделает блокчейн-технологию дешевле и быстрее. Одним из проектов, разрабатывающих это направление, является Perlin, хотя даже в нём вычислительные сервисы реализованы в сайдчейне.
Большинство проектов создают либо боковые цепи к существующим блокчейнам, либо внешние офчейн-сети, независимые от базового блокчейна. Render – пример первого подхода. Render реализован как смарт-контракт Эфириума, который взаимодействует с сетью Render. Примером второго подхода является Akash: это совершенно отдельная сеть.
Мне больше по душе лёгкие, горизонтальные протоколы, которые могут быть наложены друг на друга, нежели суперсложные блокчейн-протоколы, созданные для решения абсолютно любых задач. Именно так сейчас работает интернет. Он состоит из небольших протоколов, которые наложены друг на друга (SMTP > STARTTLS > TCP > IP). Это позволяет применять многоразовые модули (и QUIC, и DNS могут использовать UDP без необходимости внесения изменений в UDP для его поддержки). А также уровни легко заменять и обновлять (HTTP может быть заменён на SPDY или обновлён до новых версий без изменения уровней под ним).
Географический рынок
И последнее, о чём я хочу написать – это о высоком потенциале развития проектов, которые фокусируются на одном географическом рынке. Например, DCP стартует с предоставления вычислительных услуг канадским университетам и лабораториям (хотя по мере своего развития этот проект вызвал широкую заинтересованность и за пределами Канады). А, например, Ankr прикладывает особые усилия для выхода именно на китайский рынок вычислений, на котором стремительно растёт спрос на эти услуги (валовой доход компании Aliyun с каждым годом увеличивается на 104%), а AWS не может похвастаться крепкими позициями в этой области (в отличие от Aliyun). По нашему мнению, такой таргетированный подход может дать хороший результат.
Заключение
Эта сфера находится ещё на очень ранней стадии своего развития, и в ней много неизвестных, но очень оптимистично смотрим на её будущее.
Источник
В июне я написал обзор типов проектов распределённых вычислений. С тех пор прошло не так много времени, но эта область очень быстро развивается, поэтому я продолжу делиться тем, что мы узнали за этот период.
Изолированные сети и открытые протоколы
Есть два способа выполнения распределённых вычислений. В одной модели мира существует доминирующий протокол распределённых вычислений, который создаёт общую сеть компьютеров, на базе которой любой желающий может построить интерфейс и привлекать пользователей. Сюда можно отнести Heroku и EC2. Оба сервиса работают на базе AWS-серверов, но предлагают два совершенно разных интерфейса, созданных для решения кардинально отличающихся задач, направленных на разные аудитории.
В другой модели мира есть несколько доминирующих проектов распределённых вычислений, каждый из которых имеет свою сеть узлов.
Обе модели мира позволяют сосуществовать нескольким проектам, направленным на разные аудитории. Но в одной из них проекты являются клиентами, созданными на базе одного и того же пула ресурсов, а в другой каждый из таких проектов использует собственную независимую сеть. Обе модели мира могут сосуществовать, но, на мой взгляд, это маловероятно из-за сетевых эффектов. Проектам, имея такую возможность, предпочтительнее подключиться к существующей сети компьютеров, а не создавать собственную, так как благодаря доступу к более мощному CPU их клиенты получат лучшее качество сервиса в первый же день, чего нельзя добиться, начиная строить сеть с нуля.
В настоящее время существуют попытки создания обеих моделей. SONM – один из проектов, который создаёт платформу совместного пользования. Другой пример этой же модели – Distributed Compute Protocol (DCP), создаваемый компанией Distributed Compute Labs. Большинство других проектов на сегодняшний день создают собственные сети. Хотя, поскольку это проекты с открытым протоколом, любой желающий может создать альтернативный интерфейс к ним. Зачастую проекты начинают в качестве самостоятельных систем, а затем естественным образом становятся лишь одним из клиентов на базе своей теперь уже совместно используемой платформы. Меня радует потенциал единых вычислительных ресурсов, а также команды и проекты, которые их развивают.
Многие считают, что в области создания программ-клиентов на базе открытого протокола царит высокая конкуренция, так как пользователи легко могут перемещаться от одной программы к другой. Вспомните: когда Twitter только появился, создавалось множество Twitter-клиентов. У пользователей был огромный выбор подобных программ, поэтому в этой нише было сложно достичь успеха. Однако в сфере вычислений, где продуктом является интерфейс, всё по-другому. Если окажется, что API программ-клиентов отличаются, поскольку разработчики интегрировали их в свой программный код и CI/CD процессы, программы могут быть очень привлекательны для пользователей, даже если в них используется одно и то же серверное приложение. Я считаю, что это важная особенность вычислений, которая будет только стимулировать разработчиков создавать проекты на базе единого пула ресурсов.
Проблема токенов
Один из вопросов, который нас волнует: какие токены будут использоваться разработчиками и какие токены будут использоваться конечными пользователями. То есть: если пользователь взаимодействует с децентрализованным приложением, созданным на базе распределённой вычислительной сети, в каких токенах он производит оплату? В тех же самых, что используются для внутренних расчётов приложения с сетью, или в других?
На сегодняшний день, как правило, это разные токены. Например, такие проекты, как Akash, Render, Perlin, Enigma и SONM, используют для транзакций собственные токены. Эта же схема используется в проекте IPFS/Filecoin, где пользователи предположительно будут оплачивать услуги в одной из основных криптовалют (сейчас это, по всей видимости, должны быть ETH или BTC), а приложения затем самостоятельно будут обменивать их на внутренние токены, необходимые для предоставления услуги.
С другой стороны, Hypernet и Truebit являют собой примеры вычислительных проектов, использующих два типа токенов. В Truebit, например, покупатели могут оплачивать услуги в ETH, а родной токен проекта Truebit, TRU, используется только для подтверждения и урегулирования разногласий, возможных в рамках реализации протокола проекта. Эта же схема применяется в новых инфраструктурных проектах, запущенных в этом году, таких как The Graph и Augur. Для транзакций в них используется основная популярная валюта, а собственный токен применяется только для внутреннего управления, подтверждения и решения возникающих разногласий. Я считаю, что в будущем будет появляться больше проектов с моделью, построенной на использовании двух токенов, так как она позволяет увеличивать стоимость управления приложениями по мере роста сети, при этом не затрагивая стоимость услуги для пользователей.
Модели EC2 и Lambda
В сфере веб 2.0 есть два основных типа вычислительных сервисов. В EC2 разработчики предоставляют ресурсы для функционирования и хостинга серверов. В лямбда-архитектуре разработчики прописывают функции, которые потом в нужный момент запускаются и выполняются.
Эти две категории применимы и для распределённых вычислительных проектов. Некоторые из них можно сравнить с лямбда-архитектурой (или с Cloudflare Workers
), когда пользователь пишет скрипт, который затем выполняется на компьютерах, участвующих в проекте. Другой подход – это EC2 модель или «использование чужого компьютера». Пользователь соединяется с другим пользователем в сети и использует свободную мощность его компьютера.Заметим, что лямбда-подход здесь отличается от реальной лямбда-архитектуры: компьютеры в вычислительных сетях, созданных по принципу лямбда-архитектуры, не хранят все когда-либо загруженные в них функции. Наоборот, эти сети предназначены для обработки данных в офлайн режиме, а также асинхронных скриптов для таких областей, как научные расчёты и построение графиков. По мере развития, этот подход всё больше напоминает внесерверную обработку данных.
Экосистеме нужны обе модели: хостинг пользовательского интерфейса децентрализованных приложений требует наличия постоянного хоста, а выполнение разовых вычислений лучше производить на платформах с внесерверной обработкой данных.
Примеры проектов, созданных по хостинговой модели – Akash и DADI. С точки зрения пользователей, у Akash очень много общего с традиционными вычислительными сервисами. Разработчики управляют контейнерами на компьютерах, подключенных к сети Akash и входящих в кластер Kubernetes, который может быть объединён с компьютерами Akash. (Неслучайно проект Akash был создан Грегом Осури, одним из участников Federated Kubernetes). Если вам захочется попробовать сервис Akash, недавно они запустили тестовую версию.
Примеры проектов, использующих внесерверные платформы – Ankr и DCP.
Устройства пользователей
Распределённые внесерверные вычислительные проекты отличаются от криптовалютных распределённых вычислительных сетей тем, что они могут запустить код на любом телефоне или ноутбуке, так как им не требуется постоянно поддерживать данные вычислительной среды, кроме разовой обработки одного небольшого скрипта.
Идея в том, что эти проекты могут объединить все неиспользуемые мощности CPU конечных пользователей, чтобы создать гигантский суперкомпьютер, пользоваться которым будет дешевле, чем современными облачными разработками.
[Кстати о цене: в качестве главного аргумента здесь приводят то, что вычислительные сети будут дешевле, так как им не нужно оплачивать физическое пространство для размещения оборудования, а капитальные затраты на «железо» уже учтены. Но по мнению Mario @ Placeholder, стоимость услуг облачных вычислений итак постоянно снижается, и если появятся поставщики распределённых вычислений, предоставляющие услуги по ещё меньшей цене, облачные провайдеры, скорее всего, тоже понизят стоимость до минимального уровня и сохранят конкурентоспособность.]
Мне очень нравятся проекты, которые могут предоставить доступ к среде с высоким уровнем вычислительной мощности, объединяя доступные CPU на устройствах конечных пользователей.
Но выполнение кода на девайсах пользователей требует решения трёх главных проблем. Первая из них состоит в том, чтобы привлечь к участию в проекте достаточное количество пользователей. Об этом мы писали в предыдущем посте.
Вторая проблема в том, что устройства пользователей имеют относительно низкую мощность. Для её решения разработчики проектов внедряют принцип параллельной обработки данных, что позволяет выполнять код на нескольких устройствах одновременно. В проекте Ankr пользователи сами разбивают код на блоки и по отдельности отправляют в сеть, где они распределяются между несколькими компьютерами. DCP автоматически распределяет подзадачи приложения между компьютерами в форме JavaScript объектов, которые выполняются в web workers (с целью увеличения скорости обработки DCP также разумно использует WebGL для подключения к GPU на устройствах пользователей).
Третья проблема заключается в незащищённости устройств пользователей. Сейчас широко используется SGX, надёжное аппаратное окружение, встроенное в чипы Intel. Enigma запустила тестовую сеть, использующую SGX для вычислений, Golem запустил Graphene-ng, чтобы разработчикам в написании кода с поддержкой SGX, а Oasis Labs при поддержке нового криптофонда a16z, собрали 45 миллионов долларов для создания проекта распределённых вычислений с интеграцией SGX. Ноутбуки трёх ведущих производителей, HP, Lenovo и Dell поддерживают SGX. У макбуков есть чипы, поддерживающие SGX, но настройки BIOS не включают поддержку этого расширения операционной системой. Когда Apple добавит SGX, уже 4 ведущих производителя ноутбуковвнедрят SGX-поддерживаемые вычисления. Я горячо поддерживаю внедрение SGX, так как эта технология обеспечивает хороший уровень защиты и доступна на ноутбуках пользователей.
Помимо SGX, верификация вычислений в распределённых вычислительных протоколах может производиться через устранение разногласий. Truebit – один из вычислительных проектов с протоколом устранения разногласий, который они называют “verification game” (верификацией в игровой форме). В этой системе верификатор вносит депозит в токенах TRU, чтобы проверить результат вычислений. В «игровом» устранении разногласий в Truebit результаты вычислений «решателя» хэшируются на каждом шаге выполнения программы (на самом деле любое задание может оказаться невыполнимым из-за превышения лимита газа, установленного в сети Эфириум, поэтому TrueBit разбивает каждое задание на 12 подшагов). Затем верификатор проверяет получившиеся части решения, используя бинарный поиск для нахождения конкретной операции, которая вызвала расхождения. Вызвавший разногласия шаг или подшаг затем направляется в сеть Эфириум для получения окончательного решения. Сторона, предоставившая неверный результат, теряет свой депозит, который начисляется выигравшей стороне.
Место вычислительных технологий в структуре сети
Остаётся открытым вопрос: решением первого или второго уровня будут являться вычислительные сервисы? То есть будет ли блокчейн следующей крупной сети включать вычисления на уровне встроенного сервиса или же они будут производиться исключительно офчейн?
Сейчас они выполняются офчейн, потому что основные блокчейны, в которых они доступны – это либо Биткойн (ограничиваемый скриптовым языком, на котором он написан), либо Эфириум (вычисления в котором очень затратны и медленны). Очень может быть, что в будущем на 1 уровне блокчейна будет возможность производить вычисления без необходимости задействовать в выполнении одних и тех же расчётов каждый узел. Это сделает блокчейн-технологию дешевле и быстрее. Одним из проектов, разрабатывающих это направление, является Perlin, хотя даже в нём вычислительные сервисы реализованы в сайдчейне.
Большинство проектов создают либо боковые цепи к существующим блокчейнам, либо внешние офчейн-сети, независимые от базового блокчейна. Render – пример первого подхода. Render реализован как смарт-контракт Эфириума, который взаимодействует с сетью Render. Примером второго подхода является Akash: это совершенно отдельная сеть.
Мне больше по душе лёгкие, горизонтальные протоколы, которые могут быть наложены друг на друга, нежели суперсложные блокчейн-протоколы, созданные для решения абсолютно любых задач. Именно так сейчас работает интернет. Он состоит из небольших протоколов, которые наложены друг на друга (SMTP > STARTTLS > TCP > IP). Это позволяет применять многоразовые модули (и QUIC, и DNS могут использовать UDP без необходимости внесения изменений в UDP для его поддержки). А также уровни легко заменять и обновлять (HTTP может быть заменён на SPDY или обновлён до новых версий без изменения уровней под ним).
Географический рынок
И последнее, о чём я хочу написать – это о высоком потенциале развития проектов, которые фокусируются на одном географическом рынке. Например, DCP стартует с предоставления вычислительных услуг канадским университетам и лабораториям (хотя по мере своего развития этот проект вызвал широкую заинтересованность и за пределами Канады). А, например, Ankr прикладывает особые усилия для выхода именно на китайский рынок вычислений, на котором стремительно растёт спрос на эти услуги (валовой доход компании Aliyun с каждым годом увеличивается на 104%), а AWS не может похвастаться крепкими позициями в этой области (в отличие от Aliyun). По нашему мнению, такой таргетированный подход может дать хороший результат.
Заключение
Эта сфера находится ещё на очень ранней стадии своего развития, и в ней много неизвестных, но очень оптимистично смотрим на её будущее.
Источник
