Seele. Russian Whitepaper.

0
177
views

 


Команда ICOdaily подготовила перевод официального Whitepaper проекта Seele на русский язык.

Еще больше новых проектов, переводов интересных статьей и новостей на нашем телеграм канале


Seele – новая инновационная эра интернета ценностей.

Seele позволяет осуществлять высокопропускное согласование, при помощи высокомасштабируемого протокола Neural Consensus, между гетерогенными узлами высокого масштаба, а также способна формировать уникальный гетерогенный лес, мультичейн экосистемы.

Содержание

0. Резюме
1. Вопрос с именем

2. Цель и задачи
3. Принципы разработки
4. Алгоритм Neural Consensus

4.1. Предпосылка
4.2. Представление
4.3. Принципы
4.4. Особенности
4.5. Анализ безопасности
4.6. Эксперементальные результаты

4.6.1. Влияние Node Failure (Ошибок узла) на Concensus Process (Процесс консенсуса)
4.6.2.     Общий охват множественной выборки
4.6.3.     Число коммуникаций для выборки
4.6.4.     Масштабируемость
4.6.5.     Fault Tollerance
4.6.6.     Заключение

5. Сеть гетерогенного леса

5.1. Общие сведения
5.2. Единая структура блокчейна
5.3. Множественная структура блокчейна
5.4. Структура леса блокчейна

6. Value Transport Protocol (Протокол транспортировки ценностей)

6.1. Internet Protocol (Интернет протокол)
6.2. Нынешний статус
6.3. Протокол VTP

6.3.1.     Механизм присвоения имен
6.3.2.     Адресация содержимого
6.3.3.     Кэш маршрутиризации
6.3.4.     VHTTP

7. Быстрое соединение Интернета Ценностей

7.1. Представление
7.2. Технические преимущества
7.3. Фреймворк
7.4. Экспериментальное сравнение

7.4.1. Транспортная пропускная способность
7.4.2. Стабильность

8. Вычислительная интеграция

8.1. Нынешняя ситуация

8.2. Определение ресурса On-chain

8.2.1. Metadata Directory Specification(Спецификация Каталогов Метаданных)
8.2.2. Метод описания каталогов метаданных

8.3. Хранение и вычисление

8.3.1. Интернет хранение
8.3.2. Грид-вычисление
8.3.3. Многодоменное и многоуровневое планирование

8.4. Клиентская разработка

8.4.1. Ончейн метадата

8.5. Приватность и конфиденциальность данных

8.5.1. Шифрование на основе атрибутов
8.5.2. Многостороннее вычисление  безопасности

9. Экология. Управление. Инициатива.

9.1. Экология разработки

9.1.1. Проблемы
9.1.2. Решения

9.2. Экология индустрианальных приложений
9.3. Экономическая система

9.3.1. Токены
9.3.2. Стимулы
9.3.3. Структура управления

10. Костяк команды разработчиков
11. Техническая дорожная карта
12. Постскриптум
13. Ссылки на источники



Резюме

В последние годы, разнообразные блокчейн системы и приложения, написанные для них, продолжают открывать границы более широкой области применения и более глубокой разработке приложений. Blockchanin, Ethereum и прочие общественные блокчейны и криптовалюты, так же как и блокчейны консорциума, продолжают возникать создавая конкурентную среду.

Вместе с разработками технологий блокчейн и приложениями, работающими с ними, проблемы, связанные с этой сферой, постепенно обнажаются. Такие проблемы как неспособность масштабировать для высокомасштабированного представления, неспособность поддерживать разнообразные сценарии для бизнеса, а также неспособность обмена информацией и отсутствие возможности делить активы между разными блокчейн сетями становится все более видной.

В ответ на эти проблемы, мы возвращаемся к базовым ценностям блокчейна и пытаемся решить вышеуказанные проблемы, отталкиваясь от основных проблем, которые существуют в сети блокчейн: алгоритм консенсуса, экологические топологии, протоколы интернета вещей, основополагающие протоколы сети, совместные вычисления конвергенции и экосистемы приложений и т.д., чтобы способствовать более широкому распространению блокчейн приложений и интернета вещей.

В ответ на эти проблемы, мы пытаемся добиться прогресса в других аспектах блокчейна, таких как основные проблемы блокчейна, основополагающие протоколы коммуникации, инфраструктура сети, кроссчейн соглашения, алгоритм консенсуса и высшая экосистема приложений, а также мы собираемся приложить усилия, чтобы способствовать разработке блокчейна и широкому использованию интернета ценностей.

  • Предложенный новейший алгоритм нейроконсенсуса направлен на то, чтобы улучшить отказоустойчивость с 33% до 40%, без потери производительности, по сравнению с алгоритмом Византийского соглашения.

— Предложенная архитектура сети Гетерогенный Лес, имеет хороший вычислительный потенциал, для огромного разнообразия сценариев для приложений, также, как и отличный ресурс для приложений и изоляцию безопасности для любого общего или частного требования.

— VTP и VHTTP протоколы предложены для использования в системе, чтобы осуществлять наименование, обнаруживать и обращаться к услугам активов и организаций интернета ценностей и беспроблемно интегрировать с интернет ресурсами для создания основополагающих протоколов и услуг инфраструктуры для блокчейн экосистемы.

— Предложенный протокол QVIC (Быстрого соединения интернета ценностей) с низкой задержкой, основывающийся на TCP/UDP, может быть лучше адаптирован и соответствовать требованиям блокчейн сети, чем обычные протоколы TCP/UDP, использующиеся в нынешних блокчейн сетях. Существует несколько очевидных преимуществ в обработке дополнительных подключений, безопасности и низкой задержки, особенно в передачи пакетов определенного размера блоков(1М,2М). В сравнении с UDP, эффективность передачи улучшена на один порядок величины.

  1. Вопрос с именем

Слово Seele, в переводе с немецкого, означает “Душа”, что отсылает не только к человеческой душе, но также и к сущности человеческой идеи или действия. Значение слова Seele заключает в себе нашу цель: улучшить новую эру интернета вещей.

  1. Цели и задачи

— Учредители стандартов, строители сети и эко-проповедники инфраструктуры интернета вещей.

— Интегрировать сущность многоуровневой модели фундаментального протокола интернета и обеспечить надежную гарантию соглашения для интероперабильности ресурсов и совместного вычисления гетерогенных сетей.

— Предоставить мощную фундаментальную платформу и высокоскоростную трубу для свободного и безопасного круговорота ресурсов и местоположения, обнаружения и передачи ценностей и изменений внутри и по всему глобальному блокчейну.

-Придерживаться экологически ориентированной, беспроигрышной кооперативной стратегии для разработчиков, поставщиков услуг и пользователей данных, регистрации активов, доставки ценностей и обмена на открытых платформах. Мы намерены посвятить нашу работу построению операционной системы интернета ценностей, которая обеспечит разработчиков интегрированным и гибким дизайном услуг, возможностью разработки, цепочкой для тестирования и внедрения услуг. Также мы предоставим наиболее эффективные каналы услуг пользователям для поставщиков услуг и простейшие каналы для пользователей для передачи ценностей и совершения обмена.

-Мы считаем, что использование экономики токенов для поощрения вкладчиков сообщества для участия и создания экосистемы лучше, чем централизованная платформа программного обеспечения.

-Нашей целью также является построение новых отношений продукции интернета ценностей, способствование тщательной разработке блокчейна и выпуск будущей производительности.

  1. Принципы разработки

Open System Architecture (OSA) (Архитектура Открытой Системы): соответствует требованиям портативности, авторского изменения и интероперабильности, которые выдвигают основные протоколы и стандарты, функциональные фреймворки и приложения наивысшего уровня.

Принцип Efficiency First (Эффективность на первом месте): данный принцип предоставляет эффективную и стабильную бизнес платформу и позволяет быстро и точно осуществлять передачу ценностей.

Динамичное расширение (Dynamic Expansion): поддержка динамичного расширения структуры сети блокчейн для достижения динамичного планирования и регулирования вычислительных ресурсов и емкости хранилища, которые требуются различным бизнес задачам.

Изоляцияресурсов (Resource Isolation): данный подход дает возможность использования способа иерархического деления мульти-цепи и блокчейна для бизнеса, чтобы избежать мультисервисного вмешательства.

Принцип Experience First (Опыт на первом месте): задачи данного подхода заключаются в том, чтобы предоставить полномасштабную, многоперспективную поддержку услуг и разработок пользователям, посредством использования стандартизированных протоколов коммуникации, спецификации интерфейса модуля, SDK и IDE, поддержки сообщества, конференций разработчиков, ассоциаций индустриальных приложений и так далее.

Являясь пионерами и практиками нового поколения блокчейнов, мы работаем сообща, чтобы создать систему ценностей и экосистему, совместно с нашими партнерами. Наша работа заключается в комбинировании гетерогенных лесов, алгоритмов консенсуса нейросетей, разделения вычислительной мощности внутри и снаружи сети и масштабируемыми TPS.

Рисунок 3.1. Seele-блокчейн поколения 4.0

  1. Алгоритм Neural Consensus

 4.1. Предпосылка

Нынешние алгоритмы консенсуса не совместимы с Масштабированием, Безопасностью и Эффективностью, что создает SSE парадокс. Например, PoW отвечает требованиям масштабирования и безопасности, но у него большие вычислительные расходы; PoS отвечает требованиям эффективности, но несовершенен в плане масштабирования и безопасности; DPoS отвечает требованиям масштабирования и эффективности, но его безопасность является недостаточной; pBFT отвечает требованиям безопасности, потребляет мало мощности, но в случае, если размер узла слишком большой, то проблема накладных расходов сети становится очень заметной. Система  Hashgraph  отвечает требованиям масштабирования и эффективности, но имеет недостаточно безопасности, но из-за своих структурных и технологических ограничений, например подключение и разделение сетевых узлов, задержка подтверждения транзакций может быть относительно большой; система Algorand отвечает требованиям масштабирования, безопасности и требованиям потребляемой мощности, но имеет строгие требования на общие подключения сети, в случае деления сети, задержка схождения становится непредсказуемой.

4.2. Представление

Seele синтезирует преимущества и недостатки нынешних алгоритмов консенсуса первого эшелона и предлагает новое ε-дифференциальное соглашение(EDA), основанное на “микро-настоящих числах”, которые трансформируют проблемы консенсуса в обработку асинхронного запроса и сортирования данных в среде крупного масштабирования. Также у Seele есть крайняя надежность для подключения сети, для неполностью подключенных сетей. Даже любое сетевое подключение, составляющее менее 50% от части системы, может нормально работать. Одним из наиболее значимых преимуществ алгоритма консенсуса является линейная масштабируемость, которая означает, что производительность растет линейно, вместе с размером узла. Чем больше будет размер узла, тем быстрее будет сходимость и лучше производительность. В сети 100к окружения, TPS достигнет 100к, задержка подтверждения транзакций уменьшится до нескольких секунд.

4.3. Принципы

Посредством неполной случайной выборки, все преимущества системы будут постепенно покрываться и дискретное голосование [T/F], присущее традиционному консенсусному соглашению будет трансформировано в консенсусное голосование [0%,100%]. Используя функцию сходимости, в случае того, что каждая голосующая ценность будет сжата, а диапазон будет меньше, чем заданный порог ε, то действия системы будут определены следующим образом – голосование будет последовательным и голосующая ценность будет использована в качестве базиса для сортировки.

Процесс консенсуса добавляет новый параметр V, для подтверждения порядка блоков, согласовывает этот параметр в процессе консенсуса с помощью алгоритма, который работает в соответствии с требованиями и когда радиус этого параметра сходится к меньшему, чем требует точность ε, то есть, чтобы гарантировать то, что только один единственный блок существует внутри радиуса масштабирования. Для множества узлов, ситуация следующая, блоки постоянно расположены на осях, проходящих через самостоятельные и независимые петли, завершая сортировку.

Алгоритм использует позицию координат на виртуальных осях в качестве базы для упорядочивания блоков, таким образом, процесс упорядочивания больше не зависит от консенсуса, следующего до формирования блока и полностью исключается из узких мест производительности, так что существующий протокол последовательности не может быть парализован. Обработка предоставляет метод, позволяющий значительно улучшить эффективность системы. Посредством разделения архитектуры, соглашение будет постоянным с согласованностью перед тестом на повторяемость, от которого отделена технология конечного хранения, с хорошей портативностью. В связи с тем, что в системе нет обработки данных и доступа к процессу консенсуса, независимость данных, которая есть в данной системе, делает ее очень привлекательной для разработки приложений для таких сфер как финансы, электронное управление и отслеживаемость.

Рисунок 4.1 Модель консенсуса

4.4. Особенности

Дискретное голосование изменено на непрерывное голосование, в процессе консенсуса.

В традиционном алгоритме консенсуса, голосование на блоках между узлами представляет собой заключение узла с 0 или 1, само же голосование является дискретным.

Параметры эффективности могут быть заданы в соответствии с разнообразными требованиями.

Параллельный консенсус должен улучшить операционную эффективность асинхронных систем, дать полный простор параллельным системам распределенных вычислительных возможностей. При помощи разработки многоузловой асинхронной системы, вы, в дальнейшем, можете усилить конкурентную эффективность системы.

Низкое потребление энергии.

В нашей схеме отсутствует процесс выбора главного узла, а также не требуются PoS и PoW, чтобы уменьшить потребление энергии во время работы нецентральной системы. Стоит сказать, что в дополнение к извлечению абстрактной информации, число с плавающей запятой должно участвовать в схеме. Остальные операции и последовательности основаны на целочислительной арифметике, которая требует чрезвычайно низкой производительности узлов и в будущем снизит социальные и экономические затраты.

Низкая стоимость передачи.

Наша схема не нуждается в соединении с большинством узлов, во время процесса консенсуса, а получает голос(PBFT), благодаря которому можно спасти расходы передачи данных системы и уменьшить зависимость узла от структуры сети системы, настолько, насколько возможно.

Устанавливаемые параметры.

Эффективность консенсуса данного алгоритма основана на выборе таких параметров, как интервал сходимости ε и частота дискретизации s. Оптимальная эффективность системы может быть достигнута при помощи установки соответствующих параметров в реальном времени.

Совместимость с разнообразными структурами сети.

Наш алгоритм консенсуса наделен высокой адаптивностью к традиционным структурам цепочек и структурам DAG.

4.5. Анализ безопасности

Анализ безопасности для атаки Sybil. В соответствии с ценностью валюты, имеющейся у пользователей консенсуса, присваивая им вес и используя случайные множественные выборки, функции, шаг за шагом должны покрывать, пока узел Sybil имеет полную монетарную стоимость меньшую, чем полная стоимость. Для чейн алгоритма, во время атаки Sybil есть абсолютна устойчивость и иммунитет, чтобы избежать разветвления и двойных затрат.

Для случайного выбора узлов, в процессе консенсуса, метаметод использует случайно вычисляемую функцию. Пользователь, используя свой закрытый ключ, вычисляет, был ли или нет выбран узел, отзывается ли он и передает результаты другим пользователям. Такой процесс случайного выбора нелинеен, атакующий не может заранее узнать, какие узлы выбраны. В каждом раунде консенсуса, узлы, которые будут выбраны, всегда случайные и разные, что также повышает стоимость атаки.

4.6. Экспериментальные результаты

Seele ссылается на pBFT алгоритм, использует EMC облачные узлы 2К Amazon, параметр управления диапазоном сходимости алгоритма ε <0,001%.

4.6.1. Влияние Node Failure (Ошибок узла) на Concensus Process (Процесс консенсуса)

Три тестовых сценария:

А: Общее число неисправных узлов 10%, то есть 200 неисправных узлов.
B: Общее число неисправных узлов 33%, то есть 660 узлов.
C: Общее число неисправных узлов 40%, что составляет 800 неисправных узлов.

Для алгоритма pBFT, система является неисправной, когда общее число неисправных узлов (включая злонамеренные и неисправные узлы) составляет более 33%, что означает, что в случае со сценарием C, решение, которое предоставляет алгоритм pBFT не будет работать. Схема EDA проверяет эффективность схемы, используя разные чистоты выборки S, для каждых возрастающих 10% и 20 для каждого значения S.

Для сценария А, процесс займет 6 голосов, чтобы завершить консенсус и установить порядок.

Рисунок 4.2. Эффект выборки диапазона S на число консенсуса(число узлов неисправности составляет 10 процентов).

Для сценария B, процесс займет 7 голосов, чтобы завершить консенсус и установить порядок.

Рисунок 4.3. Влияние выборки диапазона S на число консенсуса (число узлов неисправности составляет 33 процента).

Для сценария С, при котором S не меньше, чем 20% процесс займет 8 голосов, чтобы закончить консенсус и определить порядок. Как и для pBFT, существует возможность не закончить консенсус в данном контексте из-за того, что число неисправных узлов выше, чем основные требования.

Рисунок 4.4. Влияние выборки диапазона S на число консенсуса (число узлов неисправности составляет 40 процентов).

4.6.2. Общий охват множественной выборки

Среда крупного масштабирования узла(N=10К), чистота дискретизации 3%(n=300). После двух раундов EDA, любой нормальный узел уже сможет достигнуть голосования всего узла r-2 раундов; среда среднего масштабирования узла, среда выборки была 30%(n=30), который также после двух раундов, достиг раунды r-2 раундов.

Рисунок 4.5. Общий охват множественной выборки.

4.6.3. Число коммуникаций для выборки

Находясь под влиянием состояния крупномасштабного узла, передача EDA имеет очевидный эффект на сохранение пропускной способности. В сети мелкого масштаба, EDA не сильно отличается от pBFT и явялется превосходящей pBFT, в случае, если r*s<2. В сети мелкого масштабирования, потребление пропускной способности сети – незначительно.

Рисунок 4.6. Сравнение числа соединений.

4.6.4. Масштабирование

Узел N=100K, S=0.9%, два раунда EDA покрывают 100% компонентов голосования, также как это делает pBFT.

Узел N=100K, S=0.9%, R<=10, число передач гораздо меньше, чем pBFT.

pBFT в параллельном голосе, произведенные результаты голосования бессмысленны, вам необходимо пересортировать и провести повторный консенсус на сортировку.

EDA в параллельном голосе, полученные результаты голосования могут быть прямо использованы, в качестве основы для сортировки.

Рисунок 4.7. Сравнение масштабирования

4.6.5. Fault Tollerance

Блокировка случается в том случае, когда коэффициент отказов pBFT превышает 33% и EDA позволяет узлу продолжить голосовать, пока неисправный узел не вернется к нормальному состоянию.

Рисунок 4.8. Сравнение фактора Fault Tollerance между pBFT и EDA.

EDA в мелкомасштабируемой среде:

Определить образец S=100%, Е=100%: неиспользованная  способность параллельной сортировки ухудшается до состояния типичного pBFT;

Определить образец S=100%, Е<100%: расход сети увеличивается(множественные раунды), остается возможность параллельной выборки.

Определить образец S=100%, Е=0%: уменьшается фактор fault tolerance, параллельная выборка возможна;

Рисунок 4.9. Сравнение коэффициента отказов между pBFT и EDA.

4.6.6. Выводы

На основании данных, полученных из экспериментов выше, мы можем сделать вывод, что для систем, при s не менее 20%, неисправности узлов которых не превышают 40%, можно достигнуть обшей конвергации системы. Если значение s высоко, меньшее число требуемой конвергации, лучше.


Сеть гетерогенного леса

 5.1. Общие сведения

Развитие человеческого общества испытало примитивную одноплеменную модель, многоплеменную модель, различные культурные места обитания, а затем различные институциональные страны. Развитие интернета также испытало автономную эру, простое соединение между множеством машин, LAN соединение между множеством машин, различные гетерогенные LAN соединения, ПК интернет, в самом конце прошлого столетия и, наконец, мобильный интернет и интернет вещей, который мы сейчас имеем. Разработка блокчейна, начавшаяся с первой версии Bitcoin, продолжившийся второй версией Ethereum, содержащей смарт-контракты, в настоящее время колоссальный рынок блокчейн продуктов.

5.2. Единая структура блокчейна

Традиционные блокчейн сети, такие как Ethereum и Bitcoin, представляют собой структуру одиночной цепочки и, таким образом, все транзакции могут быть осуществлены только на одной цепочке. Преимущества одиночной цепочки состоят в том, что все транзакции и процесс консенсуса, довольно просты, на ранней стадии разработки, блокчейн может отлично соответствовать требования пользователей. Однако, с развитием блокчейн технологий и требованиями рынка, у архитектуры, имеющей под собой одну цепочку, постепенно обнажились слабые стороны:

— В пропускной способности и производительности создаются заторы: у Bitcoin’а число TPS достигает 7, вследствие чего приходится ждать несколько блоков (рекомендуется 6) для обеспечения того, чтобы транзакция оставалась на авторитетной цепочке. Процесс производства нового блока на Ethereum занимает 10-20 секунд. Все эти факторы сильно тормозят растущий спрос на услуги блокчейнов.

— Бизнес внутри цепочек мешает друг другу: одиночные цепочки могут легко подавлять всю систему при помощи занятых индивидуальными предприятиями, такими, к примеру, как например модная игра Crypto Kitties, пользователи которой наводнили сеть Ethereum. Множество нормальных транзакций не могут быть быстро обработаны и подтверждены.

— Закрытая структура сети: невозможно достигнуть кроссчейн взаимодействия между разными цепочками, а также невозможно соответствовать требованиям бизнес взаимодействия между множеством платформ.

5.3. Множественная структура блокчейна

Для того, чтобы преодолеть ограничения, содержащиеся в структуре одиночной цепи, была предложена новая множественная структура сети. Основные формы представляют собой множественные параллельные цепочки, основные/сторонние цепочки и так далее, которые частично отвечают требованиям многоотраслевого бизнеса. Однако, с точки зрения гибкости и пользовательской настройки, все равно существуют недостатки.

— Проблема для множественных параллельных цепочек: функция каждой цепочки предварительно настроена, системе сложно отвечать быстро сменяющимся разнообразным бизнес требованиям; а также вопрос того, как делить вычислительные ресурсы и ресурсы данных на множественных цепочка, все еще остается нерешенным.

— Проблема основных/сторонних структур цепей, различные сторонние цепи могут быть получены в соответствии с ростом и изменением бизнеса. Однако, консенсус сторонней цепочки более близко связан с основной цепью, таким образом основная цепь может стать новым центром и создать затор.

5.4. Структура леса блокчейна

Давайте представим себе традиционный интернет, мы открываем браузер и пишем имя сайта, заходим на сайт, кликаем по ссылке, чтобы получить доступ к ресурсам внутри или за пределами сайта. На профессиональном языке это доступ к информации или интернет-серфинг. Позади данных действий остается DNS (Система Имени Доменов), протокол, внесший огромный вклад во все это.

Интернет ценностей, созданный блокчейном, как огромная сеть кластеров по всему миру. Каждый блокчейн, каждая подсеть создают одинаковые или разные бизнесы, предоставляют разные услуги, так же существует огромное число различных кроссчейн запросов, стабильных операций кластера, чтобы предоставить передачу услуг для пользователя. Основываясь на позитивный опыт DNS, мы представляем архитектуру сети гетерогенного леса, которая проложит мост между цифровым миром и миром реальным, для того чтобы позволить хранение, определение, передачу и трансформацию ресурсов и активов в интернете ценностей, для содействия интеграции услуг интернета ценностей и традиционного интернет бизнеса.

Рисунок 5.1. Сеть гетерогенного леса

Сеть гетерогенного леса состоит из разных подсетей, каждая подсеть может быть рассмотрена как дерево иерархического деления, верхушка цепочки дерева — это цепочка глобальных услуг, которая называется “Метацепь”, которая предоставляет глобальные конфигурации и планирует услуги. Пространство от верхушки до нижней части, это цепь разнообразных биснес форм. Эта часть разделена, в соответствии с бизнес сценариями, механизмами изоляции и стоимостью выполнения. Верхний слой предоставляет услуги адресации и планирования, слоя, которые находятся ниже. Каждый слой может настроить механизмы независимого управления, права доступа, управление потоком, механизмы безопасности. Каждый слой формирует множество независимых малых экологий. Комбинация разнообразных малых экологий составляет одну большую законченную экосистему.

В связи с разнообразными особенностями всевозможных бизнесов в реальном мире, как это уже было упомянуто ранее, структуре с одиночной цепочкой очень сложно в совершенстве поддерживать множественные гетерогенные услуги. Каждая цепь, в сети гетерогенного леса, работает только с услугами наименьшего набора функций и каждая из связующих услуг работает на отдельной цепи. Благодаря этому система может не только обеспечить эффективную изоляцию безопасности, но также позволит достичь максимального значения вычисления и ресурсов и кросс-чейн соглашений между различными цепочками, для передачи ценностей.

Структура сети гетерогенного леса может отвечать различным типам сложных бизнес требований, в реальном мире. Различные типы бизнеса, имеющие различные характеристики, работают на разных подцепях. Так, например, ресурсоемкие подцепи, IO-интенсивные и подцепи смешанного вида, соответственно, работают отлично на разнообразных цепях. Разнообразные уровни требований безопасности бизнеса, также могут работать на разных уровнях сети. Например, для банковского дела, требующего высокого уровня безопасности данных и строгой согласованности транзакций, процесс выполнения может быть изолирован для выполнения на уровне наибольшей безопасности.

  1. Value Transport Protocol (Протокол транспортировки ценностей)

6.1. Internet Protocol (Интернет протокол)

Широкое принятие и успех традиционного интернета обусловлен полным набором нормативных протоколов. Благодаря ему, возможно соединение всех типов устройств и сетей, объединение идентификации ресурсов. Также это делает обмен ресурсами чрезвычайно удобным.

— IP (Интернет Протокол): любое устройство, программное обеспечение может легко получить доступ к интернету и делить интернет ресурсы, если это согласовано с протоколом IP.

— URI (Унифицированный Индикатор Ресурса): однозначно идентифицирует интернет ресурсы, такие как картинки, текст, видео и так далее. Идентификация позволяет пользователям, при помощи специального протокола, взаимодействовать с любыми ресурсами.

6.2. Нынешний статус

Нынешнее разнообразие блокчейн сетей, каждая из которых имеет свои собственные данные, транзакции, коды и ссылки, не могут делиться данными и связываться друг с другом, формируя, тем самым, блокчейн острова, такие как Bitcoin и Ethereum. Модель данных и протокол взаимодействия этих сетей абсолютно разные, полностью независимые у этих несовместимых систем.

Для пользователей Bitcoin’а, адрес это фигура, которая выглядит подобным образом:

33YV5wC11kF67AuGSwTpUSpDTHBPTS4qDh

Пользователи Ethereum’а также имеют подобную форму адреса. Такие строки являются удобными для машин и программ, но крайне неудобны для человеческого восприятия и памяти, что существенно ограничивает передачу ценностей в блокчейн сети. Несмотря на то, что ENS сервис, расположенный на Ethereum, предоставляет DNS подобную услуг наименования, все еще существует множество недостатков, с точки зрения эффективности и покрытия.

6.3. Протокол VTP

Для того, чтобы решить проблему, основную проблему, передача ценностей между блокчейн сетями не может быть эффективно выполнена, Seele, для решения, предлагает Протокол Передачи Ценностей(VTP), основанный на архитектуре гетерогенного леса. Соглашение покрывает единую идентификацию активов в цепочке и направляет стратегию для открытия активов. VTP представляет собой полный набор транспортного протокола для блокчейн сети ценностей.

6.3.1. Механизм присвоения имен

Данные, находящиеся в цепочке, для блокчейн сетей, представляет собой активы. Наименование каждого актива и уникальность его идентификации, является очень важным фактором для регистрации, открытия, передачи и взаимодействия активов.

Основывая нашу технологию на протоколе VTP, мы задаем UAI (Единый Идентификатор Активов). Иерархично структурированное наименование активов гораздо больше подходит для человеческого восприятия и памяти, а также имеет уникальность, доступность и масштабируемость и другие характеристики.

Например, CHAIN://edu.pku.cs/account/data

В данном примере, CHAIN:// явяляется заголовком протокола по умолчанию, edu, pku, cs это идентификатор цепи на каждом уровне, account это аккаунт в цепи или контракте, data это аккаунт некоторой информации, это значение также может быть аккаунтом баланса, записью и даже интерфейсом контракта. В сети гетерогенного леса, различные пространства имен используются между цепями и одинаковые пространства имен родительских цепей, что способствует адресации и прокладыванию маршрута содержимого, посредством связи родитель-ребенок.

6.3.2. Адресация содержимого

Каждая сеть предоставляет подцепи услугу просмотра адреса, которая осуществляется контрактом системы и инициализируется во время создания цепи. Во время того, как добавляется новая подцепь, она отправляет регистрационный запрос родительской цепи и родительская цепь записывает адрес подсети. “Метацепь” это цепь глобальной конфигурации, которая управляет адресом записи всех в сеть гетерогенного леса. Когда, в соответствии с UAI, запрашивается сообщение, сначала находится запись на мецепочке, потом, мы возвращаемся к поиску, пока вы не найдете желаемую подцепь, после чего будет предоставлено содержимое аккаунта и поля данных, предназначенные для конкретных активов. Метацепь не может послужить причиной заторов производительности из-за того, что маршрутиризация информации может быть кэширована в соответствии с принципами локальности.

6.3.3. Кэш маршрутиризации

Для того, чтобы обеспечить более эффективную утилизацию сети, улучшить доступность данных, эффективность доступа и повысить опыт работы с услугами высшего порядка, Seele представляет механизм кэша маршрутиризации. В каждой цепи, встроенный системный контракт управляет кэширование маршрута и инициализируется, когда цепь построена. Существуют несколько основных способов, для стратегии замены кэша:

Стратегия замены, основанная на последнем обработанном временном интервале.
Стратегия замены, основанная на частоте доступа.
Стратегия замены, основанная на интервале последнего визита и частоте доступа.
Стратегия, основанная на случайной замене.

Кэш немедленно очищается, в случае того, если кешированная адресации маршрутиризации неисправна. Когда новая подсеть присоединяется к сети гетерогенного леса, то необходимо зарегистрировать информацию при помощи метацепи. Передать сообщение через метацепь на следующий уровень и обновить маршрут.

6.3.4. VHTTP

Для того чтобы предоставить легкий доступ к кроссчейну для приложений навысшего уровня, Seele обращается к традиционному для интернета протоколу HTTP и представляет Value-HTTP, HTTP протокол для интернета ценностей. Данный протокол осуществяляет передачу ценностей между цепей (ончейн и оффчейн). VHTTP протокол совместим с HTTP протоколом и может распознавать формат пакетов запросов HTTP. Таким образом пользователи вне цепи могут получить доступ к активам и данным цепи, непосредственно через HTTP протокол. Для HTTP запросов, идущих в сеть блокчейна, отображения между методами автоматически установлены.

Запрос протокола VHTTP состоит из трех частей: заголовок запроса, заголовок сообщения, основная часть.

Заголовок запроса начинается с имени метода, разделенного в пространстве, а запрошенный адрес и версия актива, запрошенная UAI, находятся в конце. Общий вид имеет следующий формат:

Метод UAI Version CRLF

Типы методов запросов выглядят следующим образом:

GET (Получать): запрос осуществляется для того, чтобы получить информацию, идентифицированную при помощи UAI

POST (Вносить): создавать активы (хранить активы в сети)

TRANSFER (Передавать): передавать активы между двух UAI

  1. Быстрое соединение Интернета Ценностей

7.1. Представление

Узлы блокчейнов распространены по всему миру, это говорит о сложной сетевой среде. Большое дрожание сети и латентность могут серьезно повлиять на производительность алгоритмов консенсуса и синхронизацию блоков между узлами. По сравнению с обычными интернет протоколами TCP и UDP, используемыми нынешними блокчейн сетями, мы представляем новый протокол QVIC (Быстрое Соединение Интернета Ценностей), который лучше адаптируется к сети и отвечает тем требованиям, с которыми сталкивается интернет ценностей на транспортных слоях и слоях приложений. В работе с большим количеством подключений, безопасности, низкой латентностью есть очевидные преимущества, особенно для определенного размера блока (1М,2М) в передаче особой оптимизации, эффективность передачу увеличилась почти на один порядок величины.

7.2. Технические преимущества

— Использование непрозрачного прокси-режима, клиент подключается к серверу поблизости и принимается QVIC.

— Данные отправляются из источника до места назначения для обеспечения безопасности без кеширования.

— Шифрование источников данных, передача данных с сервера на сервер через пакеты UDP, и повышение безопасности.

— Загрузка балансировки может быть использована для улучшения работоспособности.

— Высокая толерантность для потери пакетов.

7.3. Фреймворк

На случай широкой зоны сети, колебания сети, потери пакетов и других нестабильностей в сети, QVIC проводит целенаправленную оптимизацию. Это не только быстро и эффективно сохраняет особенности UDP протокола, но также сохраняет целостность TCP передачи данных.

Рисунок 7.1. Фреймворк QVIC

Из-за того, что QVIC протокол использует режим до соединения, контроль заключения сделки осуществляется на отправляющем конце, время на заключение сделки может быть игнорировано. В связи с прямой передачей пакетов данных, скорость передачи данных и эффективность были значительно улучшены.

Рисунок 7.2. Сравнения механизмов заключения сделок

7.4. Экспериментальное сравнение

Мы использовали 50 компьютеров, в разных центрах данных в Пекине, Шанхае, Гуаньчжоу и Лондоне для тестирования передачи данных. В условиях использования протокола QVIC, скорость передачи одного файла, весом 1Гб, была увеличена от 100 Кбит/с до 1 Мбит/с. В четырех других центрах данных, чтобы построить тестовую сеть блокчейна, 1К узлов для тестирования, работающей на протоколе QVIC, вследствие эффективности консенсуса передачи данных и эффективности процесса синхронизации блока, время подтверждения одной транзакции сокращено на 70%.

7.4.1. Транспортная пропускная способность

Как мы можем видеть, исходя из приведенного выше рисунка, в сравнении с TCP, протокол QVIC наилучшим образом улучшил скорость передачи и коэффициент ускорения достиг 500% в случае передачи 1Гб.

Рисунок 7.3. Сравнение коэффициента ускорения

7.4.2. Стабильность

Основанный на UDP протоколе, QVIC улучшает стабильность и эффективность в несколько раз, настраивая алгоритм контроля передачи и механизм динамичной компенсации FEC.

  1. Вычислительная интеграция

8.1. Нынешняя ситуация

Ресурсы в блокчейне основаны на консенсусе, поскольку он имеет надежность, безопасность, устойчивость к несанкционированному вмешательству, так что больше данных может быть передано из центра хранилища в цепь. Однако, когда это идет в хранилище данных в цепи, стоимость для самого блокчейна довольно высока. Стоит добавить, что крупные агентства, включая правительство и предприятия, имеют большие количества крайне ценных данных. Однако, основная проблема и проблема обмена данными ставят вопрос о том, как обеспечить безопасность и частность данных. С одной стороны, традиционный способ работы с приложениями, для вычисления, не может гарантировать безопасность данных и правильность результатов в процессе вычисления. С другой стороны, виртуальная машина может не предоставить высокую вычислительную мощность, для обеспечения вычислительными ресурсами, что соответствовать все более растущим вычислительным потребностям.

Интеграция вычислительных ресурсов, основанная на протоколах Seele, устанавливает новый тип технологии, которая интегрирует оффчейн хранилище и вычислительные ресурсы поверх блокчейна и смарт-контрактов. Интернет хранилище решает следующие проблемы блокчейна:

  1. Посредством превосходной комбинации блокчейна и IPFS, система компенсирует нехватку в хранилище файлов в системе блокчейн, шифрует значение хэша расположения файла на блокчейне и экономит стоимость хранения блокчейна. Шифрование файла может постоянно храниться в распределенной системе обмена IPFS.
  2. SC используется для того, чтобы решить проблему с островами данных, основанная на блокчейне технология децентрализации данных, направленная на обеспечение безопасности данных, защита конфиденциальности для открытых данных для предоставления решения. В случае, если данных находятся оффчейн, предоставляется надежный обмен данных внутри сети, чтобы гарантировать конфиденциальность данных и собственность в распределенном обмене.

Интернет вычисление представляет новую форму распределенной облачной системы вычисления, основанной на технологии Seele, которая позволяет производить вычисления на блокчейне с низкими операционными затратами. Seele предоставляет два разных метода вычисления, где множественные вычисления безопасности контракта на ончейн виртуальной машине являются подходящими для сценариев, где приложения с низким требованием ресурсов являются безопасными для передачи данных. Стоит сказать, что есть также способ контролировать как настольные системы и распределенные кластеры, вне цепи, контролируют вычислительные ресурсы, через юридических лиц, действия которых согласованы с контрактом.

8.2. Определение ресурса On-chain

Протокол Передачи Значений Наименования (Naming Value Transfer Protocol) устанавливает полный набор Протокола Передачи Данных(NVTP), который использует метод иерархично структурированного наименования, для наименования информации в сети. Эта структурированная схема наименования устанавливает заголовок протокола, идентификацию цепи, аккаунт и ресурсы. Данная секция, в основном, описывает определение хранилища ресурсов в цепи.

8.2.1. Metadata Directory Specification (Спецификация Каталогов Метаданных)

MDDS (Спецификация Каталогов Метаданных) используется для описания первоначальных особенностей данных оффчейн хранилища, включая статическое определение семантических особенностей и базовых атрибутов данных и динамическое описание для механизма хранения данных. MDDS был наилучшим образом прошел проверку для работы с существующими сценариями. Мы используем MDDS на платформе доверенных данных, основывающейся на блокчейне и интеллектуальных контрактах (intelligent contracts), чтобы уникальным образом идентифицировать изначальное описание информации данных.

8.2.2. Метод описания каталогов метаданных

Seele использует MDDS. Также предложен протокол RDF (Фреймворк Определения Ресурса). Протокл RDF это описательный протокол для специфичной информации, содержащейся в UAI. Помимо включения статического и динамического описания ресурсов данных частью MDDS, добавляется описание вычислительных ресурсов, и расчет характеристик ресурсов через блокчейн описание, включая память, ЦПУ, жесткий диск и так далее. Описание для вычисления запросов ресурсов, это выполнение задач шардинга, необходимое для выполнения минимального объема ресурсов, таких как минимальная память, минимальное число ядер ЦПУ и другой информации.

Как важный компонент распределенного хранилища и вычисления Seele, автоматическая адресация используется чтобы адресовать содержимое через контракт системы. В соответствии с идентификацией UAI, сначала мы находим точку входа из корневой цепи, затем поиск спускается вниз, пока не найдем желаемую подцепь, для того чтобы найти информацию о источнике данных RDF, соответствующему аккаунту, после чего инициируется запрос для ресурса ончейн или оффчейн, отмеченный RDF. После того, как ресурс будет подтвержден подписью владельца данных, смарт-контракт может соединить поставщика и потребителя ресурса. В практическом сценарии приложения, автоматическому согласованию поставщика и потребителя необходимо выбрать разные стратегии, в соответствии с актуальными потребностями пользователей. Каждая цепь предоставляет подцепи службу поиска адресов, который может быть выполнен контрактом системы и инициализирован во время построения цепи. Когда добавлена новая подцепь, подцепь отправляет регистрационный запрос родительской цепи, затем родительская цепь записывает адрес подцепи. Корневая цепь это цепь глобальной конфигурации, также она отвечает за управление всей системой леса, всеми адресами доступа, при получении запроса информации. Следуя идентификации URD, сначала ищется точка доступа корневой цепи, затем спускаемся вниз, до тез пор. Пока не найдем желаемую подцепь, следуя URDI в поле данных и аккаунте, чтобы получить доступ к ресурсам цепи.

8.3. Хранение и вычисление

8.3.1. Интернет хранение

При помощи MDDS, мы предоставляем два типа методов распределенного хранения, основанных на технологии блокчейна. IPFS в качестве ядра хранения и метаданных в цепи хранения. IPFS-централизованное хранилище предназначено, чтобы предоставлять децентрализованную сеть, где пользователи смогут хранить данные в IPFS. Это структура каталогов, которая позволяет пользователям определять файлы, а также это структура каталогов, которая включает ссылки на другие IPFS файлы и другие описания файлов. Пользователь загружает данные на блокчейн, поставщик определяет, что данные приняты, при помощи передачи, после чего другие блокчейн узлы копируют файлы, поверх IPFS сети. Что качается блокчейна, то тут вычисляется хэш всего опубликованного контента, формируется адрес индекса хэша. Когда пользователь получает доступ к файлу, это запустит процесс запроса хэша, после чего найдет узел, который хранит файл и отправит его пользователю.

В условиях общедоступной сети, собственные данные которой, для сценария доверенного обмена данных, подходят для использования метаданных в цепочки хранения. Посредством протокола интерсвязи, предоставленным общественной цепью, пользователь может также синхронизировать изначальную информацию данных о файле, в собственном хранилище данных на блокчейне и установить отношения отображения между расположением данных на блокчейне и данных, которыми владеет пользователь, иcпользуя MDDS.

Безопасность и конфиденциальность данных или метаданных, хранящиеся в цепочке, должны быть обеспечена, в дополнение к использованию традиционной технологии шифрования данных, для обеспечения гарантии того, что данные не были скомпрометированы в процессе передачи и обеспечения гарантии того, что одни и те же данные, к которым разные пользователи имеют доступ и возможность чтения не были скомпрометированы так же. То есть, нам нужно шифрование данных, основанное на детальном контроле доступа, общественная цепь, использующая атрибуты шифрования и технологию безопасности sandbox, для шифрования данных, основанных на детальном контроле доступа.

8.3.2. Грид-вычисление

Интеграция вычислительных ресурсов предоставляет распределенные вычислительные мощности, на основе блокчейна. Основываясь на интеллектуальных контрактах, с которыми работают виртуальным машины на узлах в общедоступных сетевых средах, крупномасштабные контракты составляют проверяемую, распределенную вычислительную среду, подобную той, что имеет Ethereum. Разница в том, что в течении интеграции вычислительных ресурсов, что данные безопасно консервируются внутри песочницы, которая работает на виртуальной машине, действия которой основываются на контракты, для гарантии того, что данные вычисляются в безопасной среде.

Следуя традиционному сценарию обмена данными, С использует данные из S1, S2 и S3, использует алгоритм М, предоставленный поставщиком алгоритма, чтобы предоставить данные поставщику алгоритма, которые поставщик алгоритма обрабатывает на данных, предоставленных S. Алгоритм отправляет результат обратно к С, но таким образом, данные S просочились поставщику алгоритма. Интеграция вычисления ресурсов, на основе безопасного многостороннего вычисления предоставляет новый способ работы. Поставщик данных загружает зашифрованные данные на контракт расчета виртуальной машины, данные разделяются на N составные, распределенные на N контракт виртуальной машины и, наконец, в соответствии с контрактом виртуальной машины, начинается выполнение протокола. Средние результаты, полученные на этапе, реорганизовываются для получения конечного результата расчета.

Рисунок 8.1. Фреймворк грид-вычисления

Основываясь на совместном вычислении, Seele, предоставляет новый метод вычисления. Посредством контроля контракта и координации, процесс распределенного вычисления может быть доведен до оффчейн поставщиков вычислительных ресурсов и данные могут быть распределены до настольных систем через песочницу или распределенную кластерную вычислительную платформу. Также может быть проверена корректность вычислительного процесса и результат через блокчейн.

8.3.3. Многодоменное и многоуровневое планирование

Планирование задач и ресурсов является очень важным компонентом распределенных систем. Разработка планирования алгоритма имеет прямое воздействие на коэффициент использования всего кластера. В распределенных системах планироание происходит через единичное планирование, второй уровень планирования, планирование поделенного состояния, полную распределенную эволюцию архитектуры и гибридные архитектуры. В кластире смарт-контрактов, мы разработали многоуровневое и многодоменное планирование. Основываясь на безопасности и доверии, мы разделяем блокчейн на разные домены. Мы разделяем такие индексы, как стоимость, производительность и безопасность, требуемая различными уровнями пользователей. Один и тот же алгоритм планирования может выбрать разные домены и разные уровни, чтобы распределить задачи и вычислительные ресурсы. Тонко настроенный планировщик может тонко прогнозировать производительность цели и уменьшить соседние помехи для поддержки специальных пользовательских потребностей в вычислении.

Следующие сценарии описывают различные способы планирования на основе различных потребностей пользователя: Пользователь А не имеет много времени на выполнение и не имеет требований безопасности для задания, тогда как время на вычисление довольно большое. Пользователю В требуется время на обработку данных, но не требуется слишком высокая степень безопасности, требования Пользователя С для безопасности данных очень высоки, в данном случае время выполнения задачи будет больше, стоимость вычсиления будет выше.

8.4. Клиентская разработка

8.4.1. Метаданные ончейн

Клиент предоставляет два интерфейса для расположения метаданных ончейн: извлечение расположения метаданных и обновления для расположения метаданных.

Извлечение расположения метаданных ссылается на описание структуры расположения метаданных, используя технические метода для оказания помощи мануальными методами, чтобы извлечь информацию о расположении метаданных из первоначальных данных. Расположение метаданных разделено на расположение общественных метаданных и полное расположение метаданных (включая частную информацию), соответственно, в цепи хранилища.

Рисунок 8.2. Процедура загрузки метаданных на блокчейн

Улучшение расположения метаданных означает, что, во время того, как изначальные данные изменяются, расположению метаданных нужно синхронизироваться, чтобы поддержать последовательность изначальных данных и расположения метаданных. Обработка основного процесса выглядит следующим образом:

Рисунок 8.3. Процедура обновления метаданных

  1. Ждем сигнала сигнала уведомления о смене оригинальных данных.
  2. Информация о расположении метаданных извлечена из сырых данных в соответствии с уведомлением изменения, следующим стандартам расположения метаданных.
  3. ETL (Извлечение, Трансформация, Загрузка) операции, в соответствии со стандартом расположения метаданных.
  4. Сгенерированные данные расположения метаданных хранятся, записанные в качестве V2 версии.
  5. Высшие приложения делают возможной новую V2 версию расположения метаданных.

8.5. Приватность и конфиденциальность данных

Через интеллектуальные контракты, данные отправляются в среду выполнения инкапсулированной песочницы, среда выполнения разделена на два типа случаев, ее выполнение осуществляется на виртуальной машине контракта и вычислительных ресурсах вне цепочки.

Через алгоритм обеспечения безопасности шифрования множественного вычисления, многостороннее вычисление комбинации данных осуществлено на виртуальной машине контракта кластера интеллектуального контракта, без возможности того, что первоначальные данные каждой стороны будут скомпраментированы. Бизнес обрабатывается в соответствии с предпосылкой обеспечения безопасности пользовательских данных. Для сценариев, которые выполняются на вычислительных ресурсах вне цепочки, смарт-контракт контролирует доставку и выполнение данных, инкапульсирует данные в песочнице, чтобы вычислить ресурсы и вернуть результаты пользователю через песочницу безопасности. Вычислительный процесс и информация, относящаяся к среде, загружаются в реальном времени для инспекции на сайте и постаудита.

8.5.1. Шифрование на основе атрибутов

Шифрование на основе атрибутов это, по сути, доступ авторизации и сервис аутентификации, который гарантирует то, что неавторизированные пользователи не смогут получить доступ с специфичным данным. Шифрование, основанное на атрибутах, принадлежит механизму шифрования с открытым ключом. Объекты, с которыми оно работает, это скорее объекты сообщества, чем одиночного пользователя. Оно использует комбинацию атрибутов сообщества в качестве открытого ключа сообщества. Все пользователи отправляют один и тот же открытый ключ сообществу.

Шифрование атрибута это тип системы шифрования с открытым ключом, но большое новшество состоит в том, что пользовательский закрытый ключ и зашифрованный текст зависят от определенных атрибутов, таких как пользовательская идентификационная информация. Только когда набор пользовательских атрибутов и свойства зашифрованного текста соответствуют, может произойти дешифрование.

Во время осуществления вычисления контракта, песочница безопасности расшифровывает полученные данные при помощи закрытого ключа пользователя. Во время процесса генерирования закрытого ключа пользователя, мы можем сгенерировать ключ, в соответствии с предопределенным разрешение пользователя и правилом доступа для осуществления линейных разрешений, временных рамок, лимита чистоты, лимита содержания контроля доступа безопасности.

Определение функций атрибутов на основе шифрования:

  1. Инициализация параметров: Заданный размер системыm, нужно инициализировать параметры, при выходе открытых параметров mpk и основном закрытом ключеmsk: Setup(m) ® (mpk,msk)
  2. Генерация ключа: Даны: основной закрытый ключmsk и назначение атрибутов А, в качестве входных данных, вычислить пользовательский закрытый ключ skkна выходе: KeyGen(msk,A) ® skk
  3. Алгоритм шифрования: Вносим открытые параметрыmpk и политику шифрования Policy(Политика), нужно вычислить ключ сессииek и зашифрованный текстc: Encrypt(mpk,Policy) ®(ek,c)
  4. Алгоритм расшифровки: Вносим открытые параметрыmpk, пользовательский закрытый ключskk, сделать вычисления, чтобы восстановить ключ сессииek: Decrypt(mpk,skk,C) ® ek iff Match(policy,A)=1.

Например:

Создайте группу следующих значений свойств:

Название университета: =  {……, «Harvard University», «Stanford University»,

«Tsinghua University», …},

Факультет: = {…, «College of Biology», «College of Chemistry», «School of

Information», …},

Год: = {…, «2013», «2014», «2015», «2016» …}

Роль: = {…, «Professor Committee,» «Academic Committee,» «Academic Degrees

Committee,» …}

Вышеупомянутая политика безопасности может быть переопределена для любых ресурсов (включая файлы, хранение, канал сети, процесс и так далее) в виде:

Политика: = (имя университета ∈ {«Harvard University», «Stanford University»}

И год = 2015 И роль = «degree committee»И факультет

{«Biology», «Chemistry»}).

Предположим, что у пользователя есть следующие атрибуты идентификации:

A: = {University Name: = «Stanford University», Year: = 2015, Role: = «Degree

Committee», Department: = «School of Information»}

Это означает, что пользователь состоял в Информационной академии Стэнфордского университете в 2015 году и является членом Комитета по Образованию. Очевидно, что пользователь может успешно пройти процесс идентификации через вышеупомянутую аутентификацию политики безопасности и, следовательно, ему будет предоставлен доступ к ресурсам, которые зашифрованы с помощь вышеупомянутой политики.

8.5.2. Многостороннее вычисление безопасности

Теоретическая модель мультифакторинга безопасности была предложена ранее. В 1982 году, доктор Эндрю Цичжи Яо предложил задачу, которая, впоследствии, стала называться проблема миллионера. С 1983 по 1987 годы, израильский ученый Гольдрих предложил несколько определений и улучшенных концепций многостороннего вычисления безопасности.

В сценарии совместного вычисления данных, на основании блокчейна и интеллектуальных сценариев, множество сторон, которым нужно обмениваться данными и вычислением, предполагают, что существует N сторон, P1 для PN, для того, чтобы закончить определенное задание для вычисления вместе. Также обе стороны надеются на то, чтобы выполнить совместные задания, но при этом хотят сохранить право собственности и контроль источника ресурсов, и открыть друг для друга ограниченный доступ к данным. Для такого типичного сценария мы используем технологию многостороннего вычисления безопасности. При помощи алгоритма многовычислительной криптографии, вычисление многосторонней комбинации данных осуществлено на контракте виртуальной машины кластера интеллектуального контракта, без угрозы изначальным данным каждой стороны, а бизнес осуществляется в соответствии с предпосылкой обеспечения конфиденциальности пользовательских данных.

  1. Экология. Управление. Инициатива

9.1. Экология разработки

Для получения лучшей разработки, общественному блокчейну нужно привлекать разработчиков, чтобы инвестировать в экологическую конструкцию платформы и разработку приложений, через основные технологии и хорошую среду для разработчиков и содействовать здоровому развитию сообщества.

9.1.1. Проблемы

Возьмем, к примеру, децентрализованные приложения Ethereum. У нас возникло несколько вопросов, приведенных ниже:

  1. Все еще существует много несовершенств, которые нужно устранить, вместо разработки инструментов и фреймворка. Сбор материала, фактически невозможен, из-за разницы использования различных языков и фреймворков.
  2. Документов не так уж и много, кроме того они беспорядочны и своевременно не обновляются. Из-за последующих обновлений версии, многие примеры в документах были просрочены. Таким образом, у системы много проблем, которые нужно решить.
  3. Нет никакого решения, относительно кроссплатформенного доступа. Хотя сейчас довольно просто написать веб-приложение, многие мобильные приложения не имеют функции мультитерминального доступа из-за несовершенства поддержки SDK.
  4. Идеальному руководству по-прежнему нужно производиться, для разработки, от начала, тестирования и развертывания целого контракта, хотя существует огромное количество благоприятных сред для разработки, такие как частный блокчейн, блокчейн для тестирования и основной блокчейн.

9.1.2. Решения

В ответ на эти проблемы, следуя опыту работы с движком Unity, в игровой индустрии, наша группа разрабатывает инструмент полной разработки контракта, SeeleEditor, который будет включать следующие функции:

  1. Цепь инструмента полной разработки приложения. Эта цепь будет поддерживать разработку, тестирование и развертывание контрактов, в одной среде.
  2. Кроссплатформенный протокол SDK поддерживает и способствует обновлению технических документов, чтобы улучшить эффективность разработки и разнообразие приложений на разных платформах.
  3. Создание подключаемого модуля, как Unity, для предоставления компонентов контракта и примеров программ для улучшения эффективности разработки. Следовательно разработчики смогут не только разрабатывать особенные приложения, но и разрабатывать компоненты поддержки для поступлений.
  4. Протокол IDE с модулями передачи. Любые проблемы, связанные с разработкой, могут быть переданы и незамедлительно решены.

9.2. Экология индустрианальных приложений

В настоящее время, технология блокчейн шагнула гораздо дальше функции заказа. Seele представляет собой облачный компьютер, с миллионом TPS и законченную систему хранения, так что, мы можем предоставить более высококачественные приложения, в дополнение к приложениям, которые работают с транзакциями финансовых активов, страхование токенов и рынки прогнозирования, предложенные блокчейн технологией.

  1. Социальная платформа. Построение социальной платформы, типа steemit, которая может поддерживать пользователей в создании более лучшего контента, при помощи токенов. Работающая блокчейн платформа может быть создана для пользователей, что обращаться к якорям напрямую. Прозрачность оплат может устранить множество проблем, существующих на платформе, таких как самопотребление и непрозрачная комиссия.
  2. Игры на блокчейне. Появление CryptKitties, на платформе Ethereum, предложило новое направление для игровой индустрии. Кот на блокчейне, рожденный в цепочке, выращенный и умерший в цепочке будет постоянным цифровым активом своего пользователя и никуда не денется в связи с закрытием издателей игры. Это открывает огромный простор для воображения разработчиков игр. Однако, кот может сделать Ethereum легкозасоряющимся и существенно повысить стоимость транзакций, что же тогда случится, если появится еще больше игр? Следовательно, индустрии срочно нужна лучшая инфраструктура для поддержки разработок игр. Seele может взять на себя эту ответственность.
  3. Интернет вещей. Блокчейн всегда был хорошим решением для интернета вещей из-за своего превосходства в распределенном расчете, управления данными, безопасности и прозрачности. Однако, из-за высокого потребления мощности и неэффективности традиционного блокчейна, это так и не получило должного развития. Система Seele, основанная на алгоритме консенсуса EDA, имеющая сверхнизкое энергопотребление и высокую конкурентную способность, очень хорошо подходит для этого сценария. Наш механизм иерархического консенсуса также имеет преимущества для алгоритма IOTA, которые не может полностью обойти двойные затраты и DDOS атаки.
  4. Другие приложения для развлечений. Очень легко разработать приложение для развлечения, основываясь на нашей структуре форрест-чейн. Огромное множество пользовательских услуг может быть разработано в нашей системе. Благодаря нашему протоколу NVTP, такие приложения могут прямо совершать кроссчейн соединение и доставку ценностей. Система очень гибка и удобна для приложений для развлечений.

9.3. Экономика токенов

9.3.1. Токены

Чем больше узлов вовлечено в работу нашего алгоритма консенсуса, тем будет выше эффективность консенсуса и короче время подтверждения транзакции. Зная это, мы должны заинтересовать как можно больше узлов, присоединиться к сети, чтобы улучшить ее безопасность и производительность.

С этой целью. Мы представляем Вам механизм токенов. Он будет использован, в основнов, в двух аспектах: первое, вознаграждать токенами узлы, участвующие в работе сети, что так же является способом выпуска основной валюты, второе – взимать сборы за транзакцию. Нам нужно приготовиться для атак Sybil при помощи взимания сборов, потому как пропускная способность и вычислительные ресурсы будут израсходованы во время транзакции. Сборы будут идти для вознаграждения консенсусного узла.

9.3.2. Стимулы

Блокчейны основного звена будут, в настоящее время, давать фиксированные вознаграждения блокам узлов, в качестве способа выдачи валюты. Кроме того, транзакционные сборы также используются в качестве стимулов.

Существует три основных способа оплаты транзакций:

  1. Механизм мелочи, принятый системой Bitcoin. Мелочь, после каждой транзакции используется для вознаграждения майнеров.
  2. Механизм газа Ethereum. Рассчитайте потребление значения газа, создайте, затем, на это цену, в строгом соответствии с расчетом и хранением, которое было сделано после транзакции. Значение газа, умноженное на цену, равно окончательной комиссии за транзакцию.
  3. Механизм освобождение от транзакционных сборов EOS. Суть заключается в том, что пользователь, инициирующий транзакцию, должен иметь определенные токены, чтобы пользоваться ресурсами в системе. Количество токенов определяет количество ресурсов.

После того, как майнеры увидят эти транзакции, будут они выбирать высокие транзакционные издержки, чтобы максимизировать прибыль. Следовательно, суть системы стимулирования — это распределение ресурсов. Как улучшить максимальное использование ресурсов в ограниченных ресурсах? Для решения этих проблем, системы основного звена, используют подход, который состоит из двух основных решений:

  1. У кого есть деньги, тот будет ответственным;
  2. Кто занимает место досрочно, будет ответственен;

Мы считаем, что распределение ресурсов не должно решаться таким простым способом. Выбор технологии блокчейна и программы, должны относиться к фактическим способам управления. Отсюда наши принципы: эффективность и надежность.

Что касается стимулов, то мы используем иерархический механизм стимулирования, основанный на участии и ценности. В основном это включает в себя следующие два аспекта:

  1. Стимулирование участия в консенсусе сделок.

Из-за расширения консенсуса выходит следующее, чем больше и стабильнее узлы, тем выше эффективность и производительность системы. Поэтому нам необходимо поощрять большее количество узлов к участию в сети и консенсусе транзакций, чтобы повысить производительность и безопасность сети. Узлы конечной конвергации награждаются токенами, что служит способом выдачи токенов. Токены. Полученные в качестве награды, будут уменьшаться со временем. Кроме того, узлы могут также получать определенные вознаграждения за транзакции.

Отличающийся от традиционного POW способа майнинга, нашему алгоритму консенсуса не нужна сильная вычислительная способность, но нужно хорошее подключение к сети и посредством соединения с узлами, мы можем выполнять разделение в консенсусе транзакции для получения награды. Следовательно, взимания с нашего узла зависят от производительности и сети. Производительность играет более важную роль, чем вычислительная мощность. Ресурсы пропускной способности это распределенные национальные ресурсы, избегающие концентрации вычислительной мощности. Более того, низший уровень наше сети имеет сильную проникающую способность, которая может заставить большое количество узлов интрасети участвовать во всем консенсусе транзакции, чтобы значительно увеличить размер узлов.

  1. Стимулирование стоимости блока паковки.

Каждый раз, когда узел генерирует блок, система будет награждать тех, кто предоставляет этот блок определенной суммой токенов, на основе стоимости транзакции. В данном случае система будет обеспечивать соответствующее измерение стоимости в соответствии с различными типами транзакций.

Таким образом, мы можем поощрять более ценные транзакции, которые будут идентифицироваться быстрее, что повысит эффективность сети.

Что касается платы за транзакцию, тут мы используем аналогичный режим работы с газом, который есть у Ethereum, а именно, вычисляя затраты газа на транзакцию. Но стоимость газа будет динамически регулироваться в соответствии с текущим состоянием системы, чтобы обеспечить определенную чистоту.

Используя механизм, о котором мы упомянули выше, мы надеемся уделять внимание эффективности и справедливости для повышения эффективности всей системы.

9.3.3. Структура управления

В разработке блокчейна, некоторые проблемы, которые не могут быть решены при помощи алгоритма, люди должны заключать соглашение для некоторых субъективных вопросов. В противном случае во всей системе появится много непредсказуемых проблем. Вот несколько примеров:

  1. Серьезное расхождение во мнениях между командой разработчиков и сообществом сети Bitcoin послужило причиной того, что все сообщество разделилось и теперь появляется множество форккоинов, после появления биткоина.
  2. Bitcoin аккаунт или аккаунт Ethereum будут полностью бесполезен, как только вы забудете закрытый ключ. Поэтому биткойны ниже многих адресов будут потеряны навсегда и не будут участвовать в обращении всей системы.
  3. Форк был вызван DAO, в истории развития системы Bitcoin’a.
  4. Непосладки, связанные с воровством и заморозкой паритета Bitcoin’a.

Нынешние неудачные решения данных проблем вызвали много серьезных последствий, и, таким образом, многие люди потеряли уверенность в технологии блокчейн. Нам по-прежнему необходимо принять некоторые меры для решения таких проблем, следуя некоторым решениям в реальном мире.

В Seele, управления происходит владельцами токенов, которые делегируют полномочия строителям блоков. Разработчикам блоков предоставляются ограниченные и контролируемые привилегии для блокировки учетных записей, обновления дефектных приложений и внесения изменений в базовый протокол.

Владельцы токенов генерируются случайным образом с помощью нашего алгоритма консенсуса, который будет случайным образом выбирать группу людей из самых быстродействующих узлов, получать окончательный список, взвешивать токены приемника и регулярно обновлять это. Эти узлы будут выполнять функции управления в течение данного временного периода. Те узлы, которые имеют хорошее сетевое подключение и быстрый ответ, получат наибольшую вероятность быть выбранными, в качестве узлов управления. Они сочетают преимущества PoS и PoW и учитывают участие узлов в рассмотрении, что гарантирует справедливость и предотвращают атаки сговора.

Выборы строителя блока являются частью Seele. Цепь блоков может быть изменена только тогда, когда все строители блоков будут одобрены. Кандидатура строителей может быть отклонена, если они откажутся от ожидаемых изменений. Если строители блоков внесут некоторые изменения в блокчейн без разрешения владельца токена, все другие непродуктивные верификаторы с полным узлом (переключатели и т. Д.) откажутся от изменения. Таким образом, определенный вопрос может быть разрешен путем голосования.

  1. Команда разработчиков

Доктор Bi Wei, главный ученый
Кандидат в области визуальной науки, Лондонский университет
Магистр компьютерных наук, Оксфордский университет
Заместитель генерального секретаря в China Blockchain Technology Innovation Application Alliance
Первый автор 8 патентов на технологии, связанный с технологией блокчейн, (Статус ожидается, представлен в 2017 году)
Окончил докторант Лондонского университета.
Научные интересы: блокчейн, криптография, анализ данных, обработка изображений и визуальная наука.
Принимал участие в международных академических конференциях.
Его научные работы была опубликована в журналах, таких как New England Journal of Medicine.
Его статьи были предметом обсуждения на BBC, London Chinese Radio, Complex UK и других медиа.

Доктор Gong Hui, специалист по цифровой криптовалюте
Кандидат наук в сфере финансовой математике UCL
Работает исследователем в исследовательском центре технологии блокчейн UCL
Создатель ассоциации китайско-британских блокчейнов
Генеральный директор Yuen Long Financial Information Services (Shanghai) Co., Ltd.

Доктор Maolin Zheng
Отвечает за: большие вычисления данных, математическое моделирование, интеллектуальную аналитику, управление кредитным риском, оптимизацию решений, дискретную оптимизацию
Является научным сотрудником NSERC, GERAD, Университет Монреаля
Эксперт по оптимизации принятия решений в FICO, Сан-Франциско
Бывший технический директор и главный ученый, Beijing Guozhengtong Technologies, Пекин
Бывший главный ученый в области управления кредитными рисками, Creditease, Пекин.

Доктор Nick Smith, аналитик медицинских данных
Отвечает за распределенные вычисления, облачные вычисления, грид-вычисления
Закончил докторнатуру университета Лондона.
Имеет многолетний опыт работы с распределенными системами и облачными вычислениями
Хорошо разбирается в распределенной сетевой архитектуре, тестировании производительности, имеет многолетний опыт анализа данных, моделирования данных, обработки изображений и данных
Почетный научный сотрудник UK Moorfields Eye Hospital Великобритания

Доктор Fiona Glen, старший аналитик данных по здравоохранению
Исследователь, закончила докторант в университете Лондона.
Почетный научный сотрудник UK Moorfields Eye Hospital, Великобритания
Специалист в количественном анализе и моделировании реальных медицинских данных пациента
Участвовала в разработке и реализации ряда крупных исследовательских проектов для британских национальных систем медицинского обслуживания.

Liu Wensi, архитектор больших платформ данных
Магистр, Пекинский университет
14 лет опыта разработки технологий
Старший менеджер по разработке программного обеспечения / старший инженер-программист, Microsoft
Архитектор поисковых систем в China Mobile Feixin
Главный инженер, блокчейн проекта в Лонгбанге.

Zheng Junjie, архитектор платформ на основе блокчейна
17 лет опыта разработки технологий и управления командой
Технический эксперт в экспертной группе в Tencent
Ведущий R&D менеджер таких приложений как QQmusic, QQ reading, Qzone, которые используются миллионами людей.
Ведущий R&D менеджер таких феноменальных игра как Tencent QQ Sword, Legend of Swordsman OL и так далее;
Член группы разработчиков центра исследований и разработок CDC в Avanquest; имеет ряд независимых разработок и патентов на изобретения

Hong Zhixiong блокчейн эксперт
Магистр, Пекинский университет
Более 10 лет опыта разработки интернет-продуктов
Занимается распределенными сетями, облачными вычислениями, играми, а также работает в других областях.
Бывший старший R&D инженер в Tencent.
Имеет три года непрерывного предпринимательского опыта, поставил на рынок несколько продуктов, связанные с технологией блокчейн.

Qiao Zhigang, специалист по сетям и распределенным системам
Магистр информатики, Пекинский университет
Более 15 лет опыта в области исследований и разработок модулей на базе интернета
Углубленно изучал сеть P2p, технологию поиска и распределенные системы.
Директор по инфраструктуре в Beijing East Jiahe Cultural Development Co., Ltd.
Заместитель генерального директора Shanghai Di Alliance Information Technology Co., Ltd.
Технический директор в Beijing Guangsheng Mastery Network Technology Co., Ltd.

Чжоу Лэй Хао архитектор платформ больших данных
Северо-восточный университет, бакалавр
Старший инженер в компании Baidu
Имеет многолетний опыт разработки архитектур распределенных систем
Специалист в больших инфраструктурах данных, распределенных автономных вычислениях, в вычислениях в режиме реального времени, распределенном хранение и так далее.

Ma Yongxing, архитектор платформ со смарт-контрактами
Магистр, Университет Бейхана
11 лет опыта разработки технологий
Старший инженер по разработке тестов в Baidu

Qiu Bo, старший инженер платформы
Магистр, Университет Бейхана
8 лет опыта разработки технологий
Разработчик платформы вычисления больших данных, Microsoft
Старший разработчик программного обеспечения для платформы обработки данных, Microsoft
Старший инженер-программист, CA Technologies

Duan Wei, старший инженер, работает с алгоритмом консенсуса
Бакалавр, Университет Цзилинь
Старший инженер, Baidu

Гун Ляоан, старший инженер, работает с алгоритмом консенсуса
Магистр, Пекинский университет сообщений и телекоммуникаций
Старший инженер, Baidu

Jia Zhiwei, старший инженер, работает с блокчейном
Бакалавр, Пекинский технологический институт
Инженер-программист, Dangdang
Старший инженер-программист в команде Microsoft Bigdata

  1. Техническая дорожная карта

 

  1. Постскриптум

Данный вайтпепер частично охватывает ключевые технологии и экосистемы, предлагаемы Seele. Разработка и прогресс технологии не имею конца, новые формы приложений будут также появляться. Наш вайтпепер будет постоянно обновляться, по мере того, как технология будет улучшаться и расширяться для приложений. В соответствии с амбициозной задачей разработки новой эры интернета ценностей, Seele приветствует участие разработчиков и поставщиков услуг для присоединения к экосистеме и создания новой инновационной экосистемы, развития и взаимовыгодного сотрудничества.

  1. Ссылки

1. Vitalik Buterin, Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform, 2013, http://ethereum.org/ethereum.html

2. https://en.wikipedia.org/wiki/Smart_contract

3. Oded Goldreich and A Warning, Secure multi-party computation, 1998

4. https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

5. https://en.wikipedia.org/wiki/Attribute-based_encryption

 

 

 


Еще больше новых проектов, интересных статьей и новостей на нашем телеграм канале

Предыдущая статьяAgora
Следующая статьяimusify
ПОДЕЛИТЬСЯ

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here