Форматы gVM
Конечная цель gVM - полноценная реализация в виде чипа или FPGA.
Для этого при создании ядра мы должны учитывать наличие конвейера исполнения инструкций (на пространстве FUPE).
Это порождает ограничение при создании SW версии для gVM ядра. SW версия gVM должна быть "синтезируема" или функционально эквивалентна HW версии gVM. По крайней мере, для точной формальной верификации.
В начальной базовой конфигурации gVMcore реализует поддержу 4-х кластеров:
- Turing complete кластер для C++ (скорее всего, на основе VEX набора команд)
- Поддержка команд контрактов Ethereum Solidity
- Поддержка команд контрактов NEO
- Поддержка языка верхнего уровня - GOL
Про много-кластерность (общая теория), например тут: [rVEX - http://rvex.ewi.tudelft.nl/wp/wp-content/uploads/2015/05/Delft_Reconf_VLIW_Processor_v2.0.pdf]
Много-кластерность дает возможность внутри одного ядра последовательно запускать контракты разных блокчейнов.
Кластер1
- Turing complete кластер для C++. Обычные инструкции - например открытый VEX. Кластер для сложных вычислений (как подмога блокчейнам).
Кластер2
- Ethereum и Solidity. Полная совместимость
Кластер3
- NEO. Полностью поддерживаем контракты NEO.
Кластер4
- Контракты верхнего уровня на языке GOL.
Для реализации законченной версии gVM мы должны покрыть все дерево вариантов SW-HW реализаций.
GOL - язык смарт-контрактов верхнего уровня для gVM, основанный на "обходе" онтологического дерева смыслов транзакций.
Обычная версия регистровой машины для поддержки сложных языков типа C++ и Solidity. Выбираем Turing complete набор команд. Например, открытую ISA от HP - VEX (для поддержки C++ кода). Первый кластер gVM машины будет заточен только для поддержки данной ISA. На данном кластере можно запустить также RTOS для поддержки сложных алгоритмов на блокчейне (вычисление матриц и т.п.).
Функционал любого сложного FUPE блока может быть разложен на процессорный конвейер (очевидный пример - FPU вычисления с плавающей точкой - нужен длинный конвейер). Для SW версии Pipe не нужен (FPU можно симулировать и без конвейера на SW ядре). А HW версию без конвейера синтезировать невозможно.
На HW версии также можно поддерживать языки типа Solidity.
Ключевая инновация gVM внедряется на этом уровне - через язык GOL.
Но дальнейшая классификация подразумевает возможность "синтезируемых" и "не синтезируемых" блоков FUPE.
Введение языка GOL значительно нарушает обычную парадигму виртуальных машин и симуляторов (для которых критична эквивалентность SW и HW вплоть до тактов).
В парадигме GOL "Инструкция = транзакция" и данная концепция становится больше похожа на концепцию микрокода у Интел.
Что происходит в данной концепции при реализации gVM?
Non-Turing Complete в случае gVM означает, что мы работаем с языком программирования в виде машины состояний на пространстве транзакций.
Рассмотрим GONT Tree, описывающее все пространство транзакций. А также любой конечный узел дерева GONT Tree (конечный узел является "смыслом" и транзакцией одновременно).
При вызове команды "NODE A" вызываются также исполнительные контракты данного узла в любом количестве и последовательности.
Программа смарт-контракта для gVM становится гибридной.
Есть контракт первого уровня - проход состояний на дереве транзакций. Контракты же второго уровня (обычный Solidity и т.п.) вызываются как функции из контракта первого уровня.
Поэтому, gVM вынуждена поддерживать сразу множество байт кодов (но отображая их на разные кластеры внутри gVM).
Каждый такой микро контракт имеет оценочную стоимость своего выполнения. И это является экономической базой AlGas как функционального газа сервисов.
Типичный сценарий для TREVAL в этом примере:
- Почему придется строить канал транзакции в GONT VM?
Контракты для "Node A" создаются постепенно (растянутый срок по времени). А сборка и deploy для gVM ядер происходит одномоментно или периодически.
Следовательно, контракты с одного "Node A" могут быть "разбросаны" по разным gVM машинам.
Концепция TREVAL решает данную ситуацию. И это самый простой случай, когда нужно строить канал транзакции.
"Синтезируемый FUPE"
Данный вариант необходим для поддержки языка GOL.
Единственная нагрузка на FUPE - самомодификация байт кода GOL программы. И такой FUPE можно сделать синтезируемым. При этом пакет кода программы находится по известному адресу в памяти. Специальный регистр "отслеживает" конец пакета. И единственная задача для FUPE - сделать запись в память.
Модель выполнения контракта. Схема
Модель исполнения единичной инструкции контракта GOL на дереве онтологий для кластера с "Синтезируемый FUPE"
"Не синтезируемый FUPE"
Пример Не синтезируемого FUPE.
Например, мы не можем разложить на "элементарный pipe" вычисление сложной матрицы:
Вычисление матрицы для ранжирования поиска сложно разложить на атомарные FUPE
Для вычисления такой матрицы нужны сложные конструкции C++ для работы с памятью и Turing complete кластер с наличием OS.
Но в случае SW мы можем реализовать Не синтезируемый FUPE, который не будет никак использоваться при синтезе HW версии. Этот FUPE будет быстро вычислять матрицу как часть кода самого симулятора VM.
Что мы имеем в итоге?
Нам нужно рассчитывать матрицу в каждой инструкции.
В итоге мы имеем "не синтезируемый FUPE"
Вычисление такой матрицы можно реализовать только на turing complete кластере?
Потому что нужно эффективно управление памятью при расширении матрицы.
Как сделать правильно?
- Кластер1 (GOL) пишет извлекаемые (pre-compiled) вектора в область памяти
- Кластер 2 (C++ контракт с Blockchain OS) расширяет матрицу и вычисляет.
Для упрощения же можно сделать просто не синтезируемый FUPE.
Про Software Pipelines:
[Accelerating Software Pipelines Using Streaming Caches] [http://ce-publications.et.tudelft.nl/publication/view/id/1668]
Пример использования SW Pipe - конвейерная обработка изображений - по примеру GPU. Многостадийное наложение фильтров и т.п.
Такую задачу можно эмулировать как конвейер внутри ядра (что сложнее), а можно просто как последовательные вызовы смарт-контрактов с переносом состояния контракта (данные изображения). Второй способ более универсален - т.к. он полностью в рамках общей идеологии.
Но функционал SW Pipe также можно реализовать.
SW Pipe для абстрактной задачи с переносом состояния между стадиями Pipe
Для такой задачи более подходят специализированные gVM ядра, т.к. описание State становится не универсальным, а адаптируется под задачу. И это может повлиять на форматы самого Блокчейна (например, на формат Block Header - придется добавлять Merkel root и т.п.)
Для случая "Синтезируемый FUPE" синтез HW версии ядра происходит обычным способом.
Для случая "НЕ синтезируемый FUPE" синтез HW версии ядра происходит через адаптацию.
Для отработки случая сложных алгоритмов будет введена специальная Блокчейн-операционная система и алгоритмы будут портированы на Turing-complete кластер, поддерживающий эту OS.
Таким образом, мы покроем все возможные случаи смарт-контрактов при переходе от SW к HW.
Author: Hakomoto (antosha.hakomoto@gmail.com)