Сеть IRIS Межсетевая инфраструктура обслуживания и протокол для построения надежных и распределенных бизнес-приложений
ПРИМЕЧАНИЕ: Если Вы читаете это на GitHub, то мы все еще активно разрабатываем этот документ. Пожалуйста, проверяйте регулярно обновления!
Оглавление Отказ от ответственности Обзор сети IRIS Cosmos и Tendermint Инновации сети IRIS Проектирование сети IRIS Сетевые агенты IRIS услуги Случаи применения Экономика Токенов Первоначальное распределение Токенов Дорожная карта Команда Основные участники Советники Рекомендации Отказ от ответственности
Этот отчет и любые другие документы, опубликованные в связи с данным отчетом, касаются предполагаемой разработки и использования сети IRIS. Они носят информационный характер и могут быть изменены. Этот отчет описывает развивающийся проект. Этот отчет содержит прогнозы, основанные на убеждениях IRIS Foundation Limited, а также определенные предположения, сделанные на основании доступной информации IRIS Foundation Limited. Сеть IRIS, как это предусмотрено в данном отчете, находится в стадии разработки и постоянно обновляется, включая, но не ограничиваясь, ключевые принципы управления и технические характеристики. Идентификатор IRIS включает в себя и связан с разработкой и использованием экспериментальных платформ (программ) и технологий, которые могут не реализоваться или не достичь целей, указанных в этом отчете. Если и когда сеть IRIS будет завершена, она может значительно отличаться от сети, изложенной в этом отчете. Отчет не дает никаких заявлений или гарантий в отношении достижения или обоснованности любых планов, будущих прогнозов или перспектив, ничто в этом отчете не может и не должно рассматриваться как обещание или заявление о будущем. Отчет не содержит предложения по регулированию продукта. Токены IRIS не предназначены для представления безопасности или любого другого регулируемого продукта в любой юрисдикции. Настоящий документ не является предложением или запросом ценных бумаг или любого другого регулируемого продукта, а также поощрением, приглашением или приглашением для инвестиционных целей. Условия покупки не предназначены для предоставления документа, предлагающего финансовые услуги, или проспекта любого вида. Токены IRIS не представляют собой акции, единицы, привилегированные акции или права на капитал, прибыль, доход или доход на платформе или программном обеспечении или в IRIS Foundation Limited или любую другую компанию или интеллектуальную собственность, связанную с платформой или любым другим государственным или частным предприятия, корпорации, фонда или другого лица в любой юрисдикции. Данный документ - это не совет. Этот отчет не является советом для покупки IRIS. На него нельзя полагаться в связи с любым договором или решением о покупке. Предупреждение о рисках. Покупка токенов IRIS и участие в сети IRIS несет в себе значительные риски. Прежде чем покупать токены IRIS, вы должны тщательно оценить и принять во внимание риски, в том числе перечисленные на https://www.irisnet.org и в любой другой документации. Мнения IRIS Foundation Limited Взгляды и мнения, выраженные в этом документе, относятся к документам IRIS Foundation Limited и не обязательно отражают официальную политику или позицию любого правительства, квази государственного, полномочного или государственного органа (включая, но не ограничиваясь, любой регулирующий орган любой юрисдикции) в любой юрисдикции. Информация, содержащаяся в этом документе, основана на источниках, считающихся надежными для IRIS Foundation Limited, но нет никаких гарантий относительно их точности или полноты. Английский является официальным языком данного технического документа. Этот технический документ и связанные с ним материалы выпускаются только на английском языке. Любой перевод предназначен только для справочных целей и не сертифицирован IRIS Foundation Limited или любым другим лицом. Невозможно гарантировать точность и полноту любых переводов. Если есть какие-либо несоответствия между переводом и английская версия этого документа, англоязычная версия превалирует. Согласование или одобрение не требуется. Ссылки в этом документе для конкретных компаний и платформ предназначены только для иллюстрации. Использование любых имен компаний и / или платформ и товарных знаков не подразумевает какой-либо связи или одобрения любой из этих сторон. Вы должны получить все необходимые профессиональные консультации. Вы должны проконсультироваться с адвокатом, бухгалтером и / или налоговым специалистом, а также с любыми другими профессиональными консультантами, если это необходимо, до определения того, следует ли покупать токены IRIS или иным образом участвовать в сети IRIS.
ОБЗОР IRIS Сеть IRIS названа в честь греческой богини Ирис, названной олицетворением радуги и верного посланника между небом и человечеством. Договорные отношения являются фундаментальным строительным блоком человеческого общества, и важность технологии blockchain заключается в обеспечении наиболее эффективного и рентабельного способа реализации надежных договорных отношений: во-первых, доверие (которое также очень дорого стоит), когда несколько сторон участвуют в сложных деловых взаимодействиях. Было сказано, что технология blockchain обеспечивает наиболее важные элементы для распределенного бизнеса: подъем сетевого эффекта и очень низкие транзакционные издержки. Все больше и больше людей видят потенциал blockchain как новый интернет-ценность и постепенно превращают текущие бизнес-модели в более эффективные распределенные. В частности механизм Токена, встроенный в большинство современных blockchain, подчеркивает право каждого участника сети и бизнеса в его нынешнем виде [1] Однако технология blockchain все еще находится на ранней стадии. Как и в случае с любой новой технологией, в ней есть недостатки. К ним относятся ограниченная производительность и неразвитые механизмы управления. В настоящее время эти недостатки затрудняют блокирование поддержки бизнес-сотрудничества в реальном мире. Цепочки консорциума, такие как Hyperledger Fabric и R3 Corda, и такие организации, как Ethereum Enterprise Alliance, пытались решить эти проблемы производительности и управления, чтобы технология blockchain стала более подходящей для предприятий. Однако сегодня цепи консорциум преобладают огромные компании. Кроме того, их система управления цепочкой на основе цепочки очень неэффективна. Без маркерной модели экономики и открытости и волнения в общественных цепочках цепи консорциума могут рассматриваться как недостающие жизненные силы. Мы хотели бы улучшить существующую технологию blockchain и позволить тысячам и миллионам малых предприятий среднего бизнеса («SMBs») и даже отдельным независимым бизнес-провайдерам предоставлять свои услуги и получать вознаграждения в открытой сети. Для достижения этой цели мы определили следующие проблемы и последующие возможности для технологических инноваций:
Не все вычисления могут или должны быть реализованы в виде сетевых вычислений, например такие как интеллектуальные контракты.
Виртуальная машина Turing, предоставляемая Ethereum [2], запускает Smart Contracts, дает людям много надежд на разработку децентрализованных приложений. Однако смарт-контракты могут обрабатывать только детерминированную логику (поэтому каждый узел может достичь идентичного состояния после обработки каждой транзакции и блока), в то время как огромное количество существующей бизнес-логики не является детерминированным и может меняться в разное время и при различных параметрах окружающей среды. Особенно в эти дни бизнес-системы все больше полагаются на компьютерные алгоритмы, в том числе на обработку естественного языка (NLP), машинное обучение и алгоритмы исследования операций, для оптимизации решений. В этих алгоритмах очень часто мы намеренно добавляем некоторую случайность, чтобы принять решение не застревать в локальных оптимальных состояниях при попытке найти лучший субоптимальный результат. С другой стороны, некоторые из бизнес-логик реального мира предназначены для запуска по сети и не должны реализовываться как интеллектуальные контракты такого типа реплицированных вычислений. Интеграция и взаимодействие служб и ресурсов вне сети с распределенной книгой является ключом к дальнейшему продвижению внедрения технологии блокчейн для более реальных сценариев использования.
Как повторно использовать существующий блокчейн ресурсов, в том числе и государственных цепи и цепочки консорциума. Невозможно использовать одну общественную сеть для рассмотрения всех случаев использования. Каждый день в сети происходят разные цепочки, которые фокусируются на одном аспекте решения проблем, таких как распределенное хранилище, владение активами или прогнозирование рынка и т.д. По данным coinmarketcap.com, в настоящее время на разных биржах действует более 2000 криптовалют. Создание бизнес-приложений связано с обработкой хранилища, а также с различными источниками данных. Еще одна мотивация нашей работы заключается в том, как поддерживать создание распределенных бизнес-приложений путем повторного использования некоторых существующих работ, таких как хранение (IPFS, SIA, Storj.io и т. Д.), канал данных (Augur, Gnosis, Oraclize и т. Д.) и IoT (IOTA и т. Д.) .), предоставление выделенного блокчейна, а не изобретение колеса.
Кроме того, существует множество бизнес-транзакций в режиме реального времени, которые нуждаются в более тесном сотрудничестве с консорциумом / правами доступа / частными сетями для удовлетворения требований к производительности, безопасности и управлению бизнесом. Наше видение распределенной бизнес-инфраструктуры должно иметь возможность взаимодействия многих разнородных цепей, в том числе публичных/консорциум/разрешение/частная цепи. Межцепная технология - это очень естественный ответ на это требование. Однако, до сегодняшнего дня, существующие цепи технологий, предназначены в основном для обеспечения совместимости между существующими блокчейнами и их внимание сосредоточено на передаче стоимости токенов. Вопрос о том, как потреблять ресурсы, представленные в разных сетях по-прежнему остается без ответа.
Сравнивая предлагаемые межцелевые технологии, такие как Cosmos [3] и Polkadot [4], мы выяснили, что Cosmos обеспечивает более зрелую базу для интероперабельности и масштабируемости. В частности, мы нашли дизайн «многих хабов и многих зон», а «каждая зона - независимые блокчейны с независимыми моделями управления» от Cosmos - это очень подходящая архитектура для моделирования сложности реального мира в SOC. Чтобы лучше использовать существующую инфраструктуру, мы представляем сеть IRIS, децентрализованную межцепочечную сеть, составляющую концентратор и зоны, с внедрением слоя инфраструктуры обслуживания на основе Cosmos / Tendermint [5] с расширенным использованием токена. Поскольку сеть IRIS спроектирована поверх Cosmos / Tendermint, мы сначала обсудим Cosmos / Tendermint, подытожим функции, которые мы наследуем от Cosmos / Tendermint, и суммируем нововведения, которые мы создали. Cosmos и Tendermint Cosmos [3] намерен построить «интернет блокировок». Это сеть из многих независимых блокштейнов, называемых «зонами». Каждая зона питается от классических византийских отказоустойчивых («BFT») консенсусных протоколов, таких как Tendermint. Tendermint обеспечивает высокопроизводительный, последовательный, безопасный механизм согласования BFT, где жесткие гарантии удерживают поведение злоумышленников. Tendermint хорошо подходит для масштабирования гетерогенных цепочечных блоков, включая публичные блоксхемы, такие как Ethermint [6], который представляет собой сверкающую быстродействующую реализацию Ethereum Proof-of-Stake, а также критически важных сетей разрешения / консорциума. Успешные рассказы об использовании Tendermint в домене с правом доступа / консорциума, включая Oracle [7], CITA [8] и Hyperledger Burrow [9].
Tendermint используется в качестве консенсусного протокола для построения первой зоны в Cosmos Hub. Hub может подключаться ко многим различным типам зон, и связь достигается посредством протокола межблочной связи («IBC»), своего рода виртуального UDP или TCP для цепочки блоков. Токены могут быть переданы из одной зоны в другую безопасно через Cosmos Hub, без необходимости обмена или доверенной третьей стороны между зонами.
Для разработки надежных совместимых блокчейнами и применения блокчейн с Cosmos Hub, Cosmos SDK предоставляет стартовый пакет развития блокчейн в общих модулей блокчейн пока не применяет пользовательские истории, таким образом, давая максимальную гибкость для настройки приложения.
Инновации IRIS Сеть IRIS нацелена на создание основы технологий, которая способствует созданию распределенных бизнес-приложений. Он выходит за рамки сегодняшних блокчейн систем, которые в основном предназначены для оцифрованных активов. Ключевыми задачами, которые мы стремимся решать через сеть IRIS, являются:
Интеграция и совместное использование вычислений и ресурсов вне сети в распределенной книге; функциональная совместимость сервисов по гетерогенным цепям. Мы решаем эти проблемы путем включения инфраструктуры, ориентированной на обслуживание, в Cosmos / Tendermint.
Наш дизайн наследует шаблон мышления от многолетней практики сервис-ориентированной архитектуры («SOA»). SOA - это архитектурный подход для создания систем, построенных из автономных служб, которые имеют явные границы, разделяют схемы и контракты [13]. Более ранняя практика SOA была сосредоточена на внедрении Enterprise Service Bus («ESB»), который обеспечивает связь между службами через общую коммуникационную шину, которая состоит из множества двухточечных соединений между поставщиками и потребителями. Тем не менее, централизованное управление услугами через ESB может привести к одной точке отказа, а также добавит зависимость развертывания служб. Недавний всплеск архитектурного стиля микросервисов можно рассматривать как развитие SOA, не фокусируясь на ESB, вместо того чтобы использовать светлые очереди сообщений для межсервисной коммуникации. В сети IRIS межсервисная коммуникация предназначена для реализации по блочной цепочке, чтобы использовать блок-цепочку как надежную машину для посредничества в совместной работе. Он работает без предпосылки существующего доверия между поставщиком услуг и потребителем услуг, который очень сложно установить. Сеть IRIS использует протокол Tendermint как высокопроизводительный механизм согласования. Используя гибкость, предоставляемую платформой Application BlockChain Interface («ABCI»), мы определяем набор типов транзакций инфраструктуры обслуживания, включая предоставление услуг, потребление услуг и управление сервисами. Как объяснялось ранее, большинство бизнес-логики не подходят для реализации в качестве детерминированных интеллектуальных контрактов на блокчейне, мы используем этот уровень обслуживания для перемещения конкретных бизнес-приложений и обработки транзакций с самой блокчейне и использования блокчейна только для достижения консенсуса по результатам генерируемых этими службами. Эта идея также вдохновлена существующей работой сообщества блокчейн, когда проблемы с производительностью адресов связаны с перемещением некоторых сложных вычислений с основной цепочки, такими как каналы состояния непрямой сети Lightning Network [10], а также боковые цепи защиты от мошенничества Plasma [11]. Несмотря на то, что мы не реализуем боковые цепи, мы разорвали традиционную бизнес-логику с помощью блокчейна и использовали ее как надежную шину посредничества для сложного делового сотрудничества. Для межцепочечной связи Cosmos IBC [12] определяет протокол для передачи значений из одной учетной записи в учетную запись в другой цепочке. Сеть IRIS разрабатывает новую семантику, позволяющую вызывать межцепочечное вычисление за счет использования IBC. Мы считаем, что эта возможность очень важна при создании масштабируемых бизнес-приложений. Более подробная информация о потенциальных вариантах использования приведена ниже. Сеть IRIS предназначена для предоставления инфраструктуры обслуживания для передачи и координации обработки транзакций по цепочке с обработкой данных вне сети и выполнением бизнес-логики. Усовершенствованная возможность IBC позволяет, если это необходимо, использовать эту непереходную обработку при перекрестном соединении. В настоящее время сеть IRIS также включает в себя инструменты на стороне клиента, в том числе смарт-кошелек, позволяющий хранить многопользовательские активы в нескольких цепях, а также потреблять и предоставлять iServices. Мы планируем предоставить SDK для легкого построения iServices. Например, для определенного определения службы клиентский SDK будет генерировать скелет поставщика, а также заглушку на стороне пользователя для основных языков программирования.
Проектирование сетей IRIS Рисунок сети IRIS
Как показано на рисунке выше, сеть IRIS должна иметь ту же топологию, что и сеть Cosmos. Мы планируем подключить IRIS Hub к Cosmos Hub как к одной из его зон и региональных концентраторов. Полноценные узлы IRIS, разработанные с помощью IRIS SDK (который сам является плановым расширением SDK Cosmos), предлагаются для предоставления инфраструктуры обслуживания, а также для интеграции со встроенным узлом InterPlanetary File System («IPFS»). Службы IRIS (a.k.a. «iServices») намерены преодолеть разрыв между целым блочным миром и обычным миром бизнес-приложений, опосредовав полный жизненный цикл услуг вне сети - от их определения, привязки (регистрации провайдера), вызова к их (профилирование и разрешение споров). Расширяя логику обработки IBC для поддержки семантики обслуживания, IRIS SDK предназначен для предоставления доступным распределенным бизнес-службам через Интернет блокировку. Хотя сеть IRIS фокусируется на предоставлении инновационного решения для распределенных бизнес-приложений, она по-прежнему входит в более широкую сеть Cosmos. Все зоны, подключенные к нашему предлагаемому концентратору IRIS, смогут взаимодействовать с любой другой зоной в сети Cosmos по стандарту IBC-протокола. Кроме того, вводя слой семантики обслуживания, который, как мы полагаем, может обеспечить целый новый набор бизнес-сценариев, запланированная сеть IRIS будет представлять собой увеличение масштаба и разнообразия сети Cosmos.
Сетевые агенты Потребителями являются те пользователи, которые могут потреблять услуги вне сети, отправляя запросы в сеть и получая ответы от сети. Поставщики - это те пользователи, которые могут предлагать реализацию одного или нескольких определений iService и часто выступают в качестве адаптеров услуг и ресурсов вне сети, расположенных в других сетях общественного и консорциума, а также в корпоративных устаревших системах. Поставщики контролируют и обрабатывают входящие запросы и отправляют ответы обратно в сеть. Поставщик может одновременно действовать как потребитель, отправляя запросы другим провайдерам. Как и планировалось, провайдеры должны будут взимать плату за любые услуги, которые они могут предлагать, а плата за обслуживание по умолчанию будет оцениваться в местном марке платы IRIS, известном как «IRIS»; провайдеры могут также заплатить за свои услуги в других жетонах номинантов Cosmos, которые будут учтены в установленном порядке. Профайлер - специальный пользователь, который работает от имени IRIS Foundation Limited («Фонд»), объединенной компании в Гонконге, ограниченной гарантией. Фонд будет играть ведущую роль в создании сети IRIS. Профайлер является единственным пользователем, которому разрешено вызывать iServices в режиме профилирования, который призван помочь создавать и поддерживать объективные профили поставщиков, которые потребители используют для выбора подходящих поставщиков.
Услуги IRIS В этом разделе мы изложим предполагаемые технические параметры для развертывания iServices в сети IRIS.
Определение Сервиса Метод состоит из: Идентификатор (типа int): уникальный идентификатор данного метода в охватывающей iService Имя (строка): уникальное имя этого метода в iService Описание (строка): описание этого метода Ввода (строка): структурированное определение входных параметров Выходные данные (строки): структурированное определение конечного результата Ошибка (строка): структурированное определение все возможные ошибки OutputPrivacy (перечисление): может быть одним из NoPrivacy или PubKeyEncryption Файл servicedefinition состоит из: Имя (строка): имя этого iService Описание (строка): описание iService Теги (строковые): через запятую ключевые слова об этом iService Создатель (строки): самоучитель-описание iService Творца. Chain ID (строки): идентификатор блокчейн, где этот iService был первоначально определен Обмен сообщениями (перечисление): может быть одним из Одноадресный или многоадресный Методы (метод): определение методов, доступных в этом iService Сделки Create Service Definition Tx состоит из: Определение (файл service definition): определение сервиса, которое будет создано Сервис Привязки: Сделки Create Service Binding Tx состоит из: Definition Hash (byte): хэш-сервиса определение поставщика, является обязательным для ChainID (строки): идентификатор блокчейн, где провайдер подключен Provider Address (byte): блокчейн адрес поставщика.
BindingType (enum): может быть одним из локального или глобального; выберите Global, если поставщик хочет, чтобы привязка была подвержена воздействию остального мира; в противном случае используйте Local
ProviderDeposit (int 64): для создания эффективного привязки поставщик должен внести депозит (с точки зрения количества токенов IRIS), который больше, чем значение системного параметра Min Provider Deposit; более крупный депозит может предполагать большую надежность поставщика ServicePricing (строка): структурированное определение модели ценообразования на услуги для каждого метода, включая стоимость за звонок, скидку на объем, рекламные условия и т.д.; плата за обслуживание по умолчанию указана в маркере IRIS, но также может быть указана в других токенах с бонусами.
ServiceLevel (строка): структурированное определение уровня обслуживания, которое поставщик соглашается связать себя с точки зрения времени ответа, доступности и т. Д.
BindingExpiration (int64): высота цепочки, где это обязательство истекает; отрицательное число означает «никогда не истекает», Операция Update Service Binding Tx состоит из:
Определение Hash (byte): хэш определения службы, с которым поставщик
ChainID (строка): идентификатор блок-цепи, в которой подключен провайдер
Provider Address (byte): адрес цепи цепочки провайдера
ChangeSet (строка): структурированное определение желаемых изменений существующего привязки, идентифицированное предыдущими тремя полями
Рисунок iService Определение и привязки
Поставщик может в любой момент обновить тарифы на услуги, уровень обслуживания и срок действия Binding Expiration, но небольшая сумма их депозита будет сокращена для изменения последних двух (указанные в разделе Slash Update Service Slash и Binding Expiration Update Slash соответственно). Установка Binding Expiration на высоту, которая ниже текущей высоты, будет интерпретироваться как немедленное аннулирование привязки.
Обновления к депозиту поставщика всегда будут рассматриваться как добавление к текущему депозиту. Всякий раз, когда баланс падает ниже Min Provider Deposit, привязка будет отключена до тех пор, пока поставщик не увеличит баланс выше порога. По истечении срока действия или аннулирование привязки поставщик автоматически возвращает оставшийся остаток своего депозита.
Тип привязки можно изменить с локального на глобальный, но не наоборот. Чтобы понизить привязку с Global на Local, поставщик должен сначала аннулировать привязку, о которой идет речь, а затем создать новую локальную привязку.
Если провайдер каким-то образом должен переместить привязку к новому адресу, не разрешается напрямую обновлять адрес поставщика; вместо этого поставщик должен аннулировать текущую привязку и создать другую с требуемым новым адресом поставщика.
После успешного выполнения этих двух транзакций приложением (т.е. Бизнес-логикой iService в SDK IRIS) будет создан или обновлен объект привязки службы. Служба привязки состоит из: Определение Хэш (byte) Идентификатор цепи (строка) Адрес поставщика (byte) Уровень обслуживания (строка) Стоимость услуги (строка) Истечение привязки (int64) Is Valid (перечисление): может быть одним из True или False Сервисный вызов Рисунок вызова службы
Потребителям и поставщикам предлагается взаимодействовать друг с другом через конечные точки. Существует два типа конечных точек: таблица запроса и таблица ответов (см. Рисунок выше). Запросы услуг отправляются для запроса таблиц, контролируемых заинтересованным поставщиком (поставщиками), которые собирают и обрабатывают запросы, адресованные им; результаты обслуживания (или ошибки) отправляются обратно в таблицы ответов, которые, в свою очередь, контролируются соответствующими потребителями.
Для службы многоадресной передачи все свои привязки имеют одну таблицу запросов; однако для службы одноадресной рассылки создается и поддерживается отдельная таблица запросов для каждого из своих привязок. Что касается другого направления, для каждого потребителя будет создана и управляться специальная таблица ответов.
Запрос на обслуживание состоит из:
Идентификатор цепочки (строка): идентификатор цепочки блоков, где подключен потребитель
Потребительский адрес (byte): адрес цепочки для потребителя
Определение Hash (byte): хэш определения службы
Идентификатор метода (int): идентификатор метода для вызова
Входное значение (строка): структурированное представление входных значений
Binding Hash (byte): хэш привязки к цели, в случае службы Unicast. Необязательный
Максимальная плата за обслуживание (int64): максимальная сумма платы за обслуживание, которую потребитель готов заплатить за запрос многоадресной рассылки. Необязательный
Тайм-аут (int): максимальное количество блоков, которое потребитель готов ждать ответа (-ов), чтобы вернуться
Запрос на транзакцию запроса на обслуживание Tx состоит из:
Запросы ( Запрос услуги): запросы на обслуживание, которые должны быть отправлены
Запрос депозитов ( int64): потребитель должен подавать для каждого запроса депозит (с точки зрения количества IRIS), который больше, чем стоимость депозита Min Request; этот депозит предназначен для стимулирования потребителя к своевременному подтверждению получения ответов на обслуживание (см. Подтверждение ответа службы Tx).
Приложение будет проверять, что каждый запрос поступает от потребителя с соответствующим идентификатором цепочки и адресом потребителя, целевое привязное действие действительно, размер депозита запроса достаточен, остаток на счете пользователя достаточно для покрытия депозитов и сборов за обслуживание, и что общее количество запросов в транзакции меньше Max Request PostBatch.
Когда к таблице запроса добавляется подтвержденный запрос, соответствующая плата за услугу (максимальная плата за обслуживание в случае запроса Multi-cast) будет вычтена со счета потребителя и заблокирована в условном депонировании.
Запрос запроса на получение запроса состоит из:
Определение Hash (byte): хэш определения службы
Binding Hash (byte): хэш привязки этого провайдера к рассматриваемой услуге; приложение проверит, что привязка действительна, и вызывающий абонент сопоставляет идентификатор цепочки привязки и адрес поставщика
Начальная высота (uint64): высота цепочки блоков, где приложение должно начинать получать запросы для провайдера, до общего количества, которое меньше размера партии и максимального количества запросов.
Размер партии (int): максимальное количество возвращаемых запросов
Ответ службы состоит из:
Request Hash (byte): хеш совпадающего запроса
Binding Hash (byte): хэш привязки сервиса этого провайдера
Выходное значение (byte): структурированное (потенциально зашифрованное) представление результата вывода. Необязательный
Ошибка Msg (строка): структурированное представление сообщений об ошибках. Необязательный
Ответ службы сообщений на транзакцию состоит из:
Ответы ( Ответ службы): ответы службы, которые должны быть отправлены Приложение проверяет, что каждый ответ поступает от поставщика с соответствующим идентификатором цепочки и адресом провайдера и что количество ответов в транзакции меньше, чем максимальное. Ответная почта. Проверенный запрос будет добавлен в таблицу ответов для предполагаемого потребителя.
Запрос получения ответа от службы состоит из: Запрос хэша (byte): хэш исходного запроса; приложение проверит, что вызывающий абонент соответствует идентификатору цепочки и адреса потребителя
Начальная высота (uint64): высота блока цепочки, из которой приложение должно начинать получать ответы для потребителя, до общего числа, которое меньше размера партии и максимальной реакции получения пакета
Размер партии (int): максимальное количество ответов, подлежащих возврату
Операция подтверждения транзакции подтверждения транзакции состоит из:
Хэш ответа (byte): хеш ответов, подлежащих подтверждению Приложение проверяет, что каждый ответ, который должен быть подтвержден, действительно предназначен для запроса, инициированного вызывающим абонентом, и что количество ответов в транзакции меньше, чем максимальная реакция получения партии.
Ответы, которые выпадают из окна «Тайм-аут» (и в случае ответов многоадресной рассылки, когда максимальная плата за обслуживание заканчивается с возвратом большего количества ответов), приложение не будет принято. Потребитель начинает обработку ответа сразу после его получения. Тем не менее, для ответов многоадресной рассылки потребителю нужно будет подождать, пока не истечет время ожидания, прежде чем приступать к обработке всех полученных ответов, если они есть.
Когда ответ на одноадресную рассылку подтверждается потребителем, соответствующая плата за услугу будет освобождена от условного депонирования до соответствующей учетной записи поставщика - после того, как небольшой налог (определенный налоговой ставкой налога на услуги) будет вычтен и добавлен в резерв системы; и связанный с ним запрос будет возвращен потребителю.
В случае запроса многоадресной рассылки ситуация немного сложнее: когда ответ подтвержден, только часть депозита запроса возвращается потребителю пропорционально комиссии за услуги, связанной с ответом, за максимальную плату за обслуживание; и после того, как все ответы будут подтверждены, оставшийся остаток условного депонирования для запроса будет возвращен потребителю.
Если тайм-ауты запроса, не видя ответа, возвращаются, приложение вернет связанный остаток, хранящийся в депозитном листе, плюс депозит запроса, в полном объеме, обратно к потребителю. Однако, если потребитель не подтвердит ответ вовремя (до момента ответа на подтверждение ответа + высота цепочки для ответа), небольшой штраф (определенный в соответствии с ответом на подтверждение отсрочки ответа) будет применен до того, как запрос будет возвращен потребителю, в то время как соответствующая плата за услуги будет предоставлена провайдеру, как обычно. Разрешение спора
В любом случае, когда потребитель не удовлетворен ответом на обслуживание, должен существовать механизм, позволяющий потребителю подавать жалобу и, следовательно, получать приемлемое решение этой жалобы, не прибегая к централизованному полномочию, такому как правовая система. Кроме того, этот механизм должен избегать введения субъективной оценки, которая может быть нарушена любой из сторон.
Процесс разрешения спора, который возникает в сети IRIS, похож на процесс вызова службы, за исключением того, что потребитель отправляет жалобу поставщику, а поставщик отвечает разрешением. Эти взаимодействия предполагаются через пару глобальных конечных точек, известных как таблица жалоб и таблица разрешений.
В соответствии с настоящим проектом для сети IRIS для подачи жалобы требуется депозит для клиентов. Если потребитель не подтвердит решение своевременно, штраф будет вычитаться из этого депозита. Аналогичным образом, депозит поставщика будет частично сокращен, если он не сможет своевременно ответить на жалобу.
Жалоба состоит из: Ответ хэша (байт): хеш ответа в споре
Проблема (строка): описание проблемы с ответом службы
Предпочтительное удаление (перечисление): может быть одним из возврата или повтора
Резолюция состоит из:
Жалоба хэша (байт): Хэш согласованной жалобы
Утилизация (перечисление): может быть одним из возврата или повтора
Возврат средств (uint64): возврат платы за обслуживание. Необязательная.
Выходное значение (byte): структурированное (потенциально зашифрованное) представление результата вывода.
Необязательный
Наш предполагаемый процесс разрешения споров, как указано выше, не может быть юридически обязательным. Тем не менее, мы считаем, что это обеспечит эффективные способы разрешения общих споров в сети IRIS.
Профилирование услуг
Возбуждение экосистемы iService представляет собой несколько проблем. Основная задача - найти способ облегчить потребителям поиск подходящих поставщиков - потребители нуждаются в показателях производительности для оценки и выбора поставщика, но без использования потребителя показатели производительности не будут доступны.
С целью решения этой круглой проблемы мы планируем ввести механизм профилирования, когда пользователь привилегированной системы, профилировщик, вызывает все активные службы по регулярному графику. Это оставит объективные данные о производительности в сети (например, время отклика, доступность, обработку жалоб и т. Д.), Которые полезны для реальных потребителей.
Запросы на профилирование услуг будут освобождаться от платы за услуги и вкладов клиентов, но они будут взимать плату за транзакции в сети. Эти вызовы исходят из нескольких зарезервированных адресов, которые должны быть признаны и удостоены приложением.
Профилирование будет оставаться на относительно стабильном уровне для новых услуг и постепенно снижаться для отдельных услуг, поскольку они начинают привлекать реальные потребительские звонки, которые, как ожидается, будут генерировать больше данных о производительности сами по себе.
Плата за транзакцию, взимаемая во время профилирования, будет выплачена по умолчанию из резерва системы, и резерв Фонда будет действовать, если необходимо.
Запрос
Все связанные с обслуживанием объекты жизненного цикла, описанные выше, могут быть запрошены с использованием интерфейса ABCI Query [3]. Эти запросы будут выполняться через соединение «Запрос» и не будут участвовать в процессе консенсуса. Мы уже видели, как запросы «Отправить запрос на обслуживание» и «Получить ответ службы» работают как часть процесса вызова службы.
Ниже приведено не полное резюме наших текущих запланированных запросов:
Объекты обслуживания Объект Часто используемые фильтры Авторизация Описание сервиса Имя, ключевые слова, источник (идентификатор цепи), тип обмена сообщениями, с активными привязками ... Любой может запросить Сервисное Закрепление (для данного определения) Расположение (локальный или удаленный), цены, уровень обслуживания, срок действия ... Любой может запросить Запрос на обслуживание Определение и привязка услуги, высота блока, размер партии Только подобранные поставщики Сервисный ответ Запрос услуги, высота блока, размер партии Только согласованный потребитель
Показатели эффективности Область Метрика Авторизация Провайдер (адрес) Количество предоставляемых услуг (всегда и активно), время отклика (Мин., Макс. и среднее), поданные запросы (местные и удаленные), пропущенные запросы, поступившие жалобы, жалобы игнорируются, ... Любой может запросить Поставщик (Привязка) Активное время, время отклика (Мин., Макс. и среднее), запросы (местные и удаленные), пропущенные запросы, поступившие жалобы, жалобы игнорируются, ... Любой может запросить Потребитель Количество услуг, когда-либо используемых, сделанных запросов, подтвержденных запросов (вовремя и пропущенных), заявленных жалоб, подтвержденных резолюций, … Любой может запросить Потребитель (обслуживание, спривязка) Выполненные просьбы, подтвержденные заявки (со временем и пропущенные), жалобы, утвержденные резолюции, ... Любой может запросить
Улучшение IBC
Одно уникальное преимущество создания нашей сервисной инфраструктуры на вершине Cosmos - это возможность для развертывания служб один раз и вызываться повсюду, через интернет блокировок. В частности, наш план состоит в том, чтобы выполнить следующее: Ответы служб передаются в каждую зону сети IRIS; Глобальные привязки услуг транслируются в каждую зону сети IRIS; Запросы на обслуживание или жалобы, адресованные удаленному провайдеру; маршрутизируются в блокчейн, к которой подключен провайдер; Ответы служб или разрешение, предназначенные для удаленного пользователя, перенаправляются обратно в блокчейн, к которой подключен потребитель; В процессе создания транзакций, приложение предназначено для первой проверки и сохранения объекта определения службы локально, прежде чем создавать пакет IBC, содержащий определение для каждой соседней цепи. Каждый сосед в конечном итоге получает - от соответствующего ретрансляционного процесса - пакет IBC пакета Tx, содержащий пакет; если определение еще не существует в цепочке приема, последний будет передавать определение, создав IBC-пакет для каждого из своих соседей - кроме исходной цепочки, из которой он получил пакет в первую очередь; если определение уже существует, цепочка приема перестает передавать определение. Аналогичным образом, когда связывание служб создается или обновляется с помощью его типа привязки, установленного или обновленного до глобального, пакет IBC, содержащий привязку, создается для каждой соседней цепи и распространяется по всей сети IRIS.
Смарт-контракты были реализованы для поддержки регистрации и вызова в сети. Одним из примеров обработки данных вне сети может быть поддержка службы аналитической группировки, связанной с диагностикой («DRG»). Более конкретно, когда пользователь больницы вызывает службу DRG, необработанная медицинская запись обрабатывается вне сети с использованием поставщика услуг, предоставляемого на стороне клиента NLP (реализованного как SQL и Python), для точного ввода структурированных данных для приема услуг DRG по блочной цепочке без прохождения высоко конфиденциальные исходные медицинские записи.
Сценарий BEAN демонстрирует более сложный случай использования службы, включая внедрение распределенной аналитики и подключение поставщиков услуг, а также потребителей услуг, используя блок-цепочку для обеспечения слышимого вывода транзакций, а также надежную распределенную вычислительную основу.
База данных и аналитика электронного рынка Изучая несколько предложенных проектов AI + Blockchain, похоже, что большинство проектов направлены на предоставление рынков обмена данными и рынков аналитических API. С предлагаемой инфраструктурой IRIS эти сети потенциально могут быть легко построены путем публикации данных в виде сервисов передачи данных и переноса API аналитики в виде аналитических услуг, использующих SDK поставщика услуг IRIS.
Распределенная электронная коммерция. Благодаря предлагаемой инфраструктуре IRIS интеграция с традиционными системами, такими как ERP для получения информации инвентаризации, или межцепочечный запрос по доверенным источникам данных для получения информации, такой как данные о транспортировке и погоде, будет очень похожа на подход, с которым многие разработчики корпоративных приложений уже знакомы. Благодаря тому, что эти сервисы интегрированы для поддержки распределенных приложений электронной коммерции, распространение распределенных приложений электронной коммерции может обеспечить аналогичный пользовательский интерфейс, такой как централизованные системы, такие как Amazon или Alibaba.
Совмещение публичных цепей и консорциум сетей. Для многих бизнес-сценариев гибридная архитектура сочетания хороших функций публичной сети и цепочки консорциума может дать полезные результаты, особенно в отношении производительности, безопасности и экономических стимулов.
Например, больницы и страховые компании могут сформировать блокчейн консорциума для поддержки высокоэффективных медицинских страховых операций, одновременно идентифицируя другую информацию, такую как статистика относительно некоторых заболеваний как глобальной службы, которую можно использовать из других общественных сетей. Токены, полученные от общественных сетей, могут быть возвращены тем поставщикам информации в цепочке консорциума, которые мотивируют участников системы совершенствовать и продвигать услуги. Благодаря этой инфраструктуре, предоставляемой IRIS, крупномасштабное спонтанное сотрудничество может стать возможным, при этом поддерживая жесткие требования к производительности и безопасности. Существует много вариантов использования инфраструктуры IRIS, такие как более эффективные системы безопасности на основе активов, технологии распределенного регулирования, такие как юридические экспертизы, рынок взаимопомощи и т.д. Один из планов проекта IRIS это тесно сотрудничать с проектами разрабатывающих приложения, чтобы поддерживать и обеспечивать их необходимой инфраструктурой цепочки, и позволить им сосредоточиться на более эффективном предоставлении ожидаемой стоимости бизнеса.
Работа сети IRIS:
Токен стакинга (pos) токен платы
Токен стакинга (pos) Приняв один и тот же дизайн механизма разметки, который используется в сети Cosmos [15], IRIS Hub будет иметь свой собственный локальный токен для стакинга (pos) . Этот токен будет называться «IRIS». У нас есть ряд идей в отношении конкретной функциональности токена IRIS, в том числе:
интеграция маркера IRIS в систему проверки подлинности сети IRIS, через систему валидаторов и делегатов;
право голоса для участия в управлении сетью IRIS
Токены оплаты
Существует два типа токенов в сети IRIS:
Токен сетевой платы предназначен для предотвращения спама и оплаты валидаторов при ведении бухгалтерской книги; Токен платы за услуги используется для оплаты поставщикам услуг, которые используют iServices, а токен платежной службы по умолчанию - это токен IRIS. Сеть IRIS предназначена для поддержки всех маркеров токена в белом списке из сети Cosmos, например Photon, плюс токен IRIS.
Поддержка разнообразных жетонов с бонусами в белых тонах - это функция, которую мы планируем принять от Cosmos. Он может обеспечить расширенный опыт для участников сети. В Cosmos для токена сетевой платы каждый валидатор имеет конфигурационный файл, который определяет его личный вес, насколько он ценит каждый токен. Валидатор может запускать отдельное задание cron для обновления файла конфигурации на основе предпочтительных данных на основе валидатора или, возможно, просто использовать значение конфигурации по умолчанию.
Для дизайна токена платы за обслуживание планируется поддержка модели с несколькими маркерами. Поэтому поставщик услуг в сети IRIS должен иметь свободу взимать плату за свои услуги в своих предпочтительных жетонах при условии, что он отображается в белом списке.
Чтобы помочь участникам сети IRIS смягчить волатильность цен на криптовалюты, Фонд намеревается облегчить развертывание глобальных iServices для извлечения рыночных данных с разных обменов или путем потенциального внедрения оракулов.
Токены (стейкинг (pos) и оплаты) подлежат дальнейшей доработке, чтобы обеспечить соблюдение правовых и нормативных обязательств.
Первоначальное распределение токенов В Genesis исходный токен будет составлять 2 000 000 000 токенов IRIS. Распределение токенов IRIS планируется следующим образом:
Частная распродажа: 20%
Основная команда разработчиков: 20% (период перехода на 4 года, начиная с запуска IRIS Hub, в течение которого команда будет ежемесячно набирать 1/48 своих токенов IRIS)
Фонд IRIS: 15% (зарезервировано для поддержки деятельности Фонда)
Развитие экосистемы: 45% (обмен с зонами, соединяющимися с IRIS Hub, грант для потенциальных пользователей, награды выдающимся партнерам, потенциальная публичная продажа)
Если и когда сеть IRIS будет полностью развернута, годовая инфляция токенов IRIS будет скорректирована с учетом того факта, что значительная часть жетонов IRIS в обращении может быть добровольно поставлена участниками для участия в системе согласования.
Доходы от частной продажи жетонов IRIS будут использоваться, в первую очередь, для развития сети IRIS. Планируемое распределение использования выглядит следующим образом:
Организационные операции: 10% (включая оплату услуг поставщиков и подрядчиков, например, аудиторские, консалтинговые, юридические и другие платежи за третьих лиц и прочие накладные расходы)
Разработка программного обеспечения: 50% (включая затраты, сборы и расходы, непосредственно связанные с разработкой запуска)
Поддержка разработчика: 10% (включая финансирование хакатонов, награды добровольцам и учебные программы)
Спонсорство в области исследований и разработок: 10% (включая конференцию, исследовательские программы и информационно-просветительскую работу в университетах)
Маркетинг и продвижение: 20% (включая развитие бизнеса, общественные программы и пропаганда, а также связанные с ними поездки, связь, публикацию, распространение и другие расходы)
Дорожная карта
Ожидаемый проект IRIS приведен ниже. Мы повторяем, что дорожная карта является ориентировочной и может быть изменена.
PANGU (январь 2018 года - сентябрь 2018 года). На первом этапе проекта IRIS основное внимание будет уделено запуску и запуску концентратора IRIS и подключению к концентратору Cosmos. Мы также намерены выпустить первоначальную версию мобильного клиента для сети IRIS.
NUWA (октябрь 2018 года - декабрь 2018 года). Второй этап будет посвящен созданию базового уровня обслуживания IRIS. Это предполагает включение определения, привязки, вызова и запроса. На этом этапе мы также стремимся предоставить бета-версию IRIS SDK для разработчиков.
KUAFU (январь 2018 года - июнь 2019 года). Третий этап будет посвящен дополнительным обновлениям сети IRIS, чтобы поддержать наши запланированные расширенные функции управления IRIS Service.
HOUYI (за июль 2019 года) Четвертый этап будет посвящен новым технологическим инновациям в сети IRIS, IRIS SDK и мобильному клиенту, а также привлечению разработчиков.
Команда Tendermint (команда, которая разработала двигатель согласия Tendermint и в настоящее время строит Cosmos), Wancloud (дочерняя компания Wanxiang Blockchain и Bianjie AI будет работать вместе над созданием инфраструктуры сети IRIS.
Предполагаемая роль Tendermint в предоставлении технической поддержки и поддержки развитию команды проекта IRIS в расширении технологий Tendermint ABCI и Cosmos IBC. Wancloud рассматривается как ключевой стратегический партнер как для экосистем Космоса, так и для ИРИС, и мы понимаем, что он намерен участвовать в развитии Космоса и ИРИС в Азии.
Bianjie AI будет основной командой разработчиков для сети IRIS, используя опыт команды, созданный при создании распределенных аналитических услуг AI для анализа и обмена данными в области здравоохранения. Bianjie AI - это старт в Шанхае, основанный в 2016 году. Он фокусируется на разработке инновационных продуктов и решений для здравоохранения и финансовых отраслей, используя передовые технологии Blockchain и AI. Один из основных продуктов Bianjie, BEAN (Blockchain Edge Analytics Network) BEAN (Blockchain Edge Analytics Network) - это цепочка разрешений, которая предоставляет распределенные службы аналитики данных для конфиденциальности, сохраняя анализ и обмен данными в области здравоохранения с использованием технологий НЛП и машинного обучения. Bianjie AI в настоящее время расширяет возможности BEAN для создания сети IRIS. Bianjie AI также является операционным и сервисным партнером Cosmos Network в Китае.
Основные члены команды:
Harriet Cao
Harriet является основателем Bianjie AI, стартап в Шанхае, специализирующийся на создании интеллектуальных сервисов для цепочки блоков, которые обеспечивают надежное и эффективное сотрудничество в бизнесе с использованием распределенной технологии AI. Харриет является удостоенным наград практиком в области аналитики данных и технологий искусственного интеллекта, и стала лауреатом премии INFORMS Даниэля Х. Вагнера 2010 года. До создания Bianjie AI Харриет работала в IBM Research более 16 лет в различных областях, включая директора IBM Research Shanghai Lab и лидера Big Data Analytics для IBM Global Labs. Харриет имеет степень магистра в области робототехники в Университете Карнеги-Меллона и степень магистра. степень в области автоматизации управления Университета Цинхуа.
Haifeng Xi
Haifeng - старший технолог и предприниматель. С возвращением в Китай из США в 2009 году он работал в качестве главного технологического директора для трех компаний, одним из которых является в списоке NASDAQ. Он также стал одним из основателей двух стартапов в Шанхае, где он играет активную роль технического руководителя и инженера-чемпиона. Хайфэн имеет степень магистра в области электротехники и вычислительной техники в Университете штата Мэриленд, а также степень магистра и бакалавра по автоматическому управлению в Университете Цинхуа.
Jae Kwon
После окончания Корнелла в 2005 году с получением степени бакалавра в области компьютерных наук, Jae работал разработчиком программного обеспечения в Силиконовой долине, сначала на Amazon (где он работал над цифровым помощником Alexa), а затем в Yelp, где он руководил разработкой мобильных приложений команда. Получив ошибку blockchain, Jae создал консенсусный алгоритм Tendermint BFT и механизм Blockchain ядра Tendermint Core с целью создания доказуемо безопасного алгоритма проверки цены. В дополнение к Tendermint, Jae также является создателем Cosmos.
Tom Tao
С момента присоединения к Wanxiang в августе 2016 года Tom отвечает за консультационную службу Wanxiang Blockhain Group, платформу Wancloud BaaS, а также за ускоритель ChainBase и инкубатор. До Wanxiang Tom работал в сфере управления услугами и управления бизнесом более 18 лет в ряде ведущих мировых компаний. Том возглавил внедрение облачных сервисов, платформ обработки данных IoT и технологий творческого ускорителя на китайский рынок. Том следит за тенденциями в блокчейне, облачных вычислениях, IoT и умных отраслях обрабатывающей промышленности с 2013 года. Tom имеет степень магистра физики в Университете Фудана и степень бакалавра в области электротехники в Университете Нанкай.
Советники: Dr. Shuo Bai
Dr. Shuo Bai является директором технического комитета ChinaLedger и бывшим главным архитектором Шанхайской фондовой биржи. Он старший профессионал блокчин, который окончил Пекинский университет с докторантурой. Он работал в различных организациях, включая исследователя, советника докторанта, директора отдела программного обеспечения и главного ученого в Институте вычислительной техники Академии наук Китая. Он также возглавлял создание Китайского национального интернет-центра по чрезвычайным ситуациям (CNCERT / CC) с 2000 года. Д-р Бай обладает богатым опытом в области теоретических исследований и технической практики в области финансовых обменов, консорциума и общественных блокцепей.
Jim Yang
Jim Yang проводит стратегию для Tendermint. Он был основателем и генеральным директором ChatX, студии мобильных сообщений. ChatX разработала различные мобильные сообщения / социальные приложения. Он также был соучредителем Identyx, где он занимал должность генерального директора до его приобретения Red Hat. Identyx разработала программное обеспечение для управления идентификационными данными с открытым исходным кодом.
Zaki Manian
Zaki Manian, исполнительный директор Trusted IoT Alliance, является плодовитым вкладчиком в разработку технологии blockchain и cryptocurrency. Заки обладает глубокими знаниями в области криптографии и распределенной системы консенсуса. Он также является советником проекта Cosmos, а также несколькими другими инвестиционными фондами и стартапом в космосе.
Adrian Brink
Adrian Brink, главный разработчик и руководитель сообщества сети Tendermint / Cosmos.
Michael Yuan
Michael Yuan является директором Фонда CyberMiles. Майкл получил степень PhD в области астрофизики в Техасском университете в Остине. Он является автором 5 книг по разработке программного обеспечения, опубликованных Prentice Hall, Addison-Wesley и O'Reilly. Майкл был активным коммиттером кода в крупных проектах с открытым исходным кодом, таких как Firefox, Fedora, JBoss и другие. Он является экспертом в области корпоративного и мобильного программного обеспечения и является основным исследователем в нескольких исследовательских проектах, финансируемых правительством США.
Yubo Ruan Yubo является основателем 8 Decimal Capital. Фонд инвестировал в IRISnet, 0x,Kyber, Ontology, Fcoin, Zilliqa, ICON, Wanchain, Bibox, BiShiJie. Yubo является соучредителем Skylight Investment, венчурного фонда на основе бостона, поддерживаемого New Oriental (NYSE: EDU). Ранее Юбо начал две успешные компании, в том числе Alisimba (приобретал TopHacker Group), состоял из 4 национальных патентов и выиграл 2017 AACYF 30 до 30, Серебряный медаль Winner, iENA International Inventions Competition, 2012.
Cсылки:
1 Wanxiang Blochchain Inc., Distributed Business Value Research Institute, "Blockchain and Distributed Business Whitepaper", September 2017.
2 Ethereum Foundation, "Ethereum Homestead Documentation", http://ethdocs.org/en/latest
3 Jae Kwon, Ethan Buchman,"Cosmos, A Network of Distributed Ledgers", https://cosmos.network/whitepaper
4 Gavin Wood, "Polkadot: Vision For a Heterogeneous Muilti-chain Framework", https://polkadot.io/
5 Tendermint, https://tendermint.readthedocs.io/en/master/
6 Ethermint, https://ethermint.zone/
7 Oracle International Corporation, "Accountability and Trust in Distributed Ledger Systems", USA Patent Application 20170236120, August 17, 2017, http://www.freepatentsonline.com/y2017/0236120.html
8 Jan Xie, "CITA Technical Whitepaper", https://github.com/cryptape/cita-whitepaper/blob/master/en/technical-whitepaper.md
9 Hyperledger Burrow, https://github.com/hyperledger/burrow
10 Joseph Poon, Thaddeus Dryja, "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments", January 14, 2016, https://lightning.network/lightning-network-paper.pdf
11 Joseph Poon, Vitalik Buterin, "Plasma: Scalable Autonomous Smart Contracts", August 11, 2017, https://www.plasma.io/plasma.pdf
12 Ethan Frey, "Cosmos IBC Specification", Sep. 29, 2017, https://github.com/cosmos/ibc/blob/master/README.md
13 Thomas Erl, "SOA: Principles of Service Design", Prentice Hall; 1st edition (July 28, 2007)
14 Dean, J., Corrado, G.S., Monga, R., et al, Ng, A. Y. "Large Scale Distributed Deep Networks". In Proceedings of the Neural Information Processing Systems (NIPS'12) (Lake Tahoe, Nevada, United States, December 3--6, 2012). Curran Associates, Inc, 57 Morehouse Lane, Red Hook, NY, 2013, 1223-1232.
15 Tendermint Blog, "Cosmos Validator Economics -- Revenue Streams", January 2018, https://medium.com/@tendermint/b5b2c682a292
16 Sunny Aggarwal, "Cosmos Token Model", December 2017, https://drive.google.com/file/d/1jtyYtx7t1xy9gxEi2T5lXFNd8xUY7bhJ/view