Модель исполнения контракта GONT
Приветствую, коллеги! В сегодняшней статье говорим о модели исполнения контракта в GONT. Расскажем про общий подход к разработке данной модели, о вариантах её реализации, а также ответим на вопрос о том, что такое GONT-контракт. Обсудим сиги и Web-сервисы и расскажем, что такое Bactions и Actions. Продуктивного чтения!
Общий подход к разработке модели исполнения кода контракта
Варианты реализации:
- Без LLVM (простой компилятор).
- С LLVM (сложный оптимизирующий компилятор, как для Solidity).
Предлагаем для начала рассмотреть вариант без LLVM и без ввода функционального языка GOL.
Вариант реализации без LLVM представляет собой простой компилятор. Фактически, это генератор ELF файла для исполнения в ядре gVM.
GONT реализует и поддерживает как полную обратную совместимость с Ethereum (контракты Solidity), так и собственную модель контрактов.
1. Контракт
Что есть GONT-контракт?
Это совокупность (любое количество) транзакций (TR) из описаний на GONT Tree. Контракт всегда находится в состоянии одной из TR, а затем переходит в следующую TR под влиянием внешних параметров. Данная модель похожа на «The smart contract language in ZILLIQA«.
2. God-given эволюция контракта
Смарт контракт GONT можно рассматривать как эволюцию между существенными состояниями программы-контракта (эволюция смыслов). Эволюция обычным, нативным образом вытекает из смысла экономической деятельности, которую описывает контракт. Это определение контракта вытекает из способа ввода газа AlGas в GONT.
При вводе AlGas любая транзакция «превращается» в инструкцию процессора (ядра gVM) и является одной из множества инструкций глобального «газа». При этом сама инструкция описывает какой-то смысл, заданный пользователем.
Транзакции вводятся через дерево оракула «GONT Tree». В визуальном режиме пользователь может выбрать на GONT Tree «смыслы программы» и задать эволюцию контракта. Фактически, это FSM (Finite State Machine) программы в точных терминах.
3. Сигнатура
По мере «прохода» контрактом состояний, формируется сигнатура, которая является объектом консенсуса на Блокчейне. Консенсус можно вводить по- разному. Сигнатура дает объект для формулы сравнения на разных майнерах.
GONT Tree – это онтология смыслов транзакций. Программа контракта – это переходы между состояниями смыслов под воздействием внешних условий.
Преимущество подхода заключается в возможности «визуального» (простого) программирования без глубоких экспертиз в языке написания контрактов.
4. Модель выполнения контракта.
Схема:
Модель исполнения единичной инструкции контракта
Pre-Exec модель
После выполнения текущей инструкции и достижения состояния Commit, сигнатура должна расшириться (путем самомодификации) для того, чтобы задать следующую инструкцию, куда перейдет состояние. Физически эта инструкция дописывается в сигнатуру, но с флагами «Pre-Commit» и «Pre-Exec». Это означает, что инструкция еще не выполнялась и не была подтверждена. После этого состояние сигнатуры может быть сохранено в блок БЧ.
После возобновления выполнения сигнатуры (в любой момент времени), эта инструкция будет выполнена и аналогично расширена новой инструкцией.
5. Сиги и Web сервисы
GONT предлагает подход для реализации Web-сервисов при необходимости их взаимодействия с БЧ.
При нормальной работе сайт реализует огромное количество состояний, которые отрабатывает MVC контроллер. Не все из них должны «зеркалиться» в блокчейне. При запуске Web-сервиса важные для блокчейн состояния должны быть рассмотрены отдельно.
При этом, web-сервис рассматривается как машина состояний (FSM + множество состояний + модель эволюции), которые «перетекают» между собой под воздействием поведения пользователя. Не все состояния сайта могут иметь какую-то ценность для записи их в глобальный БЧ.
Сига же описывает эволюцию состояния микросервиса со старта его локального Genesis, т.е блока (начало работы микросервиса), постоянно самомодифицируя себя (самомодификация сиги ядром gVM) добавлением в конец сиги нового состояния (по модели эволюции).
Понятие доверенной сиги сервиса
По мере исполнения Actions и Bactions сервис достраивает сигу сервиса. Сига должна быть синхронизована на стороне сервиса (OFF-Chain сторона) с сигой, сохраняемой в блок БЧ. После верификации и синхронизации (по одному из алгоритмов) сига может считаться доверенной и готовой для следующей команды.
6. Bactions и Actions
Общая методология для всех GONT Web-сервисов (не только для сервиса GONT-«Выборы»).
State Machine – Машина состояний сайта.
На сайте возможно большое множество действий пользователя – т.е Actions. Однако эти действия имеют значимые смысловые пики и должны быть отражены в блокчейне (важные транзакции). При этом необходимо выравнивание машины состояний сайта и соответствующего блокчейн-сервиса сайта. Т.е. необходимо строить корректное отображение сайта на блокчейн.
Частично наш подход сопрягается с подходом Бутерина в Plasma [plasma.io]. Мы строим консенсусную модель для вложенных блокчейнов.
Реализация через GONT VM
Для сокращения расхода ресурсов GONT VM не работает непрерывно. Фактически, GONT VM включается, выполняет новые транзакции и выключается. При этом последнее состояние GONT VM сохраняется в сигнатуре сервиса (она же — локальный GONT BlockChain).
BActions = Blockchain Actions
Bactions – действия пользователя для Блокчейна.
Таким образом, мы приходим к модели эволюции состояний.
Пример модели эволюции для Выборов
BActions:
INIT
Registration
Vote {Vote options}
Stamp
WriteBack
Эволюция:
Каждый BAction имеет выделенный уникальный адрес в GONT Space.
Вывод:
При разработке любого нового сервиса необходимо четко прописать Эволюцию и Actions. Эволюция реализуется через смарт-контракт сервиса в ядре GONT VM.
Спасибо за внимание! Успехов!
GONT