Skip to content

FAQ Architecture

Altgas-io edited this page Mar 26, 2019 · 53 revisions

FAQ Архитектура (частые вопросы по архитектуре ALTGAS)

Вопрос 1

Почему виртуальные машины (для Блокчейн-цепочек) генерируются автоматически, а не создаются руками программистов?

✔️

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

Вопрос 2

Чем крипто-кошелек AWAL в ALTGAS лучше других кошельков?

"Задачу качественного кошелька актуальной считают многие компании, работающие над этим более 5 лет, например ledger.com, trezor и другие. "Железные" кошельки не новость и проблема сохранности в них криптоактивов уже не стоит. Имхо, выходить на этот рынок, с точки зрения бизнеса, нужно с чем-то большим чем "качественный кошелек". По-моему делать что-то надо не потому что это сложно "форкать" или "копипастить", а потому что это решает конкретную проблему, которую не могут решить другие. Тогда это становится похоже на бизнес."

✔️

  • Упомянутые кошельки - это не совсем кошельки. Это просто "оболочки-брелки" поверх TPM модуля от ARM, который изначально был создан совсем не для крипты. Т.е. там все еще нет никакой специализации под задачи (крипто-биржи, крипто-IoT и т.п.).

AWAL - изначально кошелек со специализацией под крипто-биржи и крипто-IoT [ALTGAS для IoT].


Вопрос 3

Зачем нужен Оракул ALTGAS-OLAP?

✔️

  • Оракул инкапсулирует любые знания и смыслы, которые клиент хочет использовать при построении сервиса.

С точки зрения архитектуры, Оракул является "системой координат" для систем команд (ISA) создаваемых VM. Во многом, это определяет подход ALTGAS к закреплению "частной собственности на Блокчейне". Для этого достаточно "закрепить" владение частью Оракула ALTGAS-OLAP и "включить" иерархическую целостность ("Майнинг целостности")

  • Оракул отображается непосредственно на пул из виртуальных машин Блокчейн цепочки

Отображение Оракула на VM

Отображение ALTGAS-OLAP на Блокчейн


Вопрос 4

Что такое "состояние VM" и что такое транзакция?

✔️

  • Состояние VM - это состояние регистров и состояние памяти данной VM. Т.к. ничего "другого" в VM невозможно хранить (в понимании именно "состояния"). Чтобы воспроизвести состояние VM1, нужно в полностью совместимую другую VM2 передать "снимок" всех регистров и "снимок" рабочей памяти.
  • Транзакцией можно считать любой набор инструкций AlGas. Т.к. у каждой инструкции есть исполнительная семантика в ядре VM по умолчанию. Нельзя создать новый AlGas на Оракуле, не указав хоть какую-то исполнительную семантику (или просто NOP инструкцию).

Вопрос 5

Про корректность промежуточных состояний (по аналогии с Ethereum)

В Эфире транзакция переводит одно разрешенное состояние в другое: tx: s(t+1) = f(s(t), tx) при помощи некой функции трансформации f, определяющей эволюцию системы. Если отталкиваться от определения ALTGAS, то транзакция - это любая композиция мини-трансформаций, производимых единственной инструкцией VM. Понятно, что любая инструкция VM неявно предполагает перевод одного легитимного состояния в другое легитимное состояние.

Вопрос: нужны ли какие-то ограничения на совместимость промежуточных состояний s0 -(i1)-> s1 -(i2)-> s2 .... -> sN, чтобы последовательность инструкций (i1, i2,...,iN) образовала транзакцию?

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

✔️ Промежуточные состояния нужно рассматривать в рамках совместимости последовательных VM по архитектуре. Это базовое требование.

TREVAL канал и микро-состояния

TREVAL Channel

"DNA-совместимость" для последовательных STATES

  • необходимость технологии для "сборки" сервиса из разных молекул газа.

Каждая aVM может иметь собственный набор FUPE ресурсов для работы газа и ее состояние STATE может отличаться от других aVM в TREVAL канале.

Точная архитектура aVM определяется на этапе создания ALTGAS-сервиса.

Для проверки совместимости последовательных aVM по форматам газа можно ввести понятие "DNA сервиса".

GPS протокол должен обеспечивать "туннелирование" состояний между машинами. Специализированные инструкции протокола обеспечивают инициализацию STATE при создании машины и ее конфигурации.


Вопрос 6

Что такое "бомба криптографической сложности F8"?

✔️

  • Технология класса "know-how" (patent) от ALTGAS, позволяющая планомерно наращивать защиту объектов криптосистемы.

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

В ALTGAS технология F8 используется как составная часть "майнинга целостности" - также "know-how" и patent.


Вопрос 7

Почему в ALTGAS необходим переход к регистровой виртуальной машине?

✔️

  • Виртуальная машина EVM Ethereum построена по типу JVM (Java) машины и является стековой (stack-based). Это сделано для скорости и безопасности приложений dApps в Ethereum.

  • Конечной же целью ALTGAS является создание "железной" (реализованной в виде FPGA) виртуальной машины. Которую, по сути, уже можно считать отдельным процессором. Применения таких машин гораздо шире - вплоть до "Блокчейн-телефонов", "Блокчейн-смарт-карт" и Блокчейн-IoT-устройств.

  • Последовательно мы реализуем SW VM машину и полностью эквивалентную (с точностью до цикла) HW машину. Машина же HW может быть только регистровой (как и любой процессор).


Вопрос 8

Что такое "транзакция" в ALTGAS?

✔️

Рассмотрим как сравнение с Ethereum:

  • В Блокчейне Ethereum транзакция вводится просто как “подписанное сообщение”, которое переводит состояние системы в новое состояние (в результате исполнения):

APPLY(S,TX) -> S' or ERROR

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

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


Вопрос 9

Про "добычу" газа ALTGAS

"Вот gas тот же самый: в Эфире все понятно - это некое универсальное "топливо", на котором работают вычислительные мощности. Независимо от того, что контракт делает, он тратит определенное количество топлива == gas. Gas стоит денег (eth), но прямой связи нет. Поэтому gas != eth. Изначальная мотивация введения концепции газа - противодействие DDOS-атакам (злонамеренным и просто плохо написанным контрактам с циклами и т.п.).

Теперь ALTGAS. У каждого сервиса свой AlGas. Назначение у него то же: "топливо" для вычислений на VM? Только не универсальное, а исключительно для этого сервиса? Тогда как и где пользователи будут его добывать, чтобы платить за сервис? Если покупать, то должна быть какая-то мера стоимости, чтобы за тот же eth его купить.

Или все вообще не так? Пример в реальном мире можно привести, с парой-тройкой сервисов?

Еще в Эфире, например, каждая инструкция eVM стоит сколько-то газа - так и рассчитывается общий расход. TxFee получает майнер, как раз, собрав плату за потраченный газ с автора транзакции. В концепции мульти-VM, где контракт представляет собой цепочку (композицию) микро-ядер виртуальных машин, там вообще будет смесь разных видов gas, получается. Кто кому и в каких единицах платит за вычисление кода VM при этом?"

✔️

  • Мерой стоимости альтернативного газа AlGas является Джоуль (единица энергии). Мы же EnergyCoin строим фактически (энергетический StableCoin)!

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

  • Платит всегда тот, кто вычисление (транзакцию) запускает. Только в ALTGAS он платит сразу всем кто газ дал (т.е. всем создателям AlGas, который был задействован в транзакции). В массивно-параллельных вычислениях схема немного упрощается (например, в поиске ALSEARCH), т.к. цепочка вознаграждений получается слишком длинной.


Вопрос 10

Какой консенсус предполагается использовать для построения цепочек?

✔️

  • Консенсус класса "Proof of Kernel Work"

  • Предполагается использовать "адаптивный консенсус"


Вопрос 11

Про "передачу" газа AlGas

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

✔️


Вопрос 12

Про "подмену" газа в Ethereum на AlGas

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

✔️

  • В Ethereum расход газа является частью консенсуса и простая подмена "нового типа рабочего газа" работать не будет.
  • Если же сам вызов контракта считать "новым" газом (поверх "старого" газа EVM). Но так невозможно сделать нормальные сервисы. Типа "Поиска". Например, когда индекс поиска принадлежит сразу всем. Тогда нужен мета-контракт который сразу запустит 1000 контрактов и соберет как-то результат. Что очень "неизящно" и экономически невыгодно в Ethereum.

Вопрос 13

Про "приводимость" ALTGAS к Ethereum

"А есть про то, как, допустим, в тривиальном вырожденном случае вся архитектура ALTGAS сводится к примитивному Эфиру? Чтобы совместимость была."

✔️

  • Приводимость к Ethereum очень простая - одна плоскость Оракула [ALTGAS-OLAP] с кодами команд Эфира. И одна VM, в итоге.
  • И один "уровень VM". В расширенном состоянии в ALTGAS - сейчас - два "уровня VM". Первый - чисто под AlGas команды. А второй - под газ, но который не считается в статистике. Типа инструкций MOV, ADD, .. Для Ethereum первый уровень не нужен.

Вопрос 14

Какие уровни архитектуры виртуальной машины aVM существуют?

✔️

Модель расширения VM:

  • Кластеризация [внутри одной VM - несколько кластеров независимых вычислительных ресурсов]
  • Широкое командное слово (VLIW) - для захвата длинных данных Ethereum (256 бит или 512 бит)
  • Модель параллельности. Одна VM разбивается на множество "совместных" VM - sharding на уровне инструкций (некий аналог ILP).

Для пользователя VM выглядит как единая машина - на уровне реализации существует очень широкая параллельность работы "совместных" VM.

Для реализации "совместных" VM вводится новый протокол GPS (Global Proressors States).


Вопрос 15

Вопрос про необходимость Оракула (дерево смыслов ALTGAS-OLAP)

"Понятно. Но если я хозяин VM, зачем мне дерево смыслов для избежания повторов инструкций? Я понимаю, если новую VM разрабатывает некая независимая группа, в которой каждый, по мере потребности, добавляет новую инструкцию, не зная о том, что делает другой. Тогда да, такое дерево теоретически может помочь избежать дублирования. А если я сам творец своей VM, то дерево для меня - только лишний труд."

✔️

  • Дерево нужно не программистам, а для экономики. Без альтернативного газа AlGas (описываемого деревом смыслов) нет криптоэкономики, нет потребителя.

  • "Ещё раз: что мешает мне, аки создателю VM безо всякого дерева вписать для каждой инструкции её цену в альтгаз?"

  • Нет сервисов. Можно считать, что оно (дерево) уже есть изначально. Вы приходите и пишете обычный код Solidity, как и всегда. Просто Вам дадут другую папку куда его складировать (т.е. плоскость Оракула).


Вопрос 16

Про "хаос" при построении дерева смыслов (Оракула)

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

✔️

  • Для этого мы вводим именно Куб смыслов [ALTGAS-OLAP]. В Кубе ALTGAS-OLAP каждому пользователю выдается (продается) отдельная плоскость, чтобы он там "царем" был, не выходя за рамки своей плоскости.

- "То есть я сам пишу себе дерево и сам на нем пишу себе инструкции?"

  • На одной плоскости можно сделать хоть "миллион разных проектов". Или можно выбирать из уже готовых плоскостей (не только своих) и использовать их.

Вопрос 17

Про реализацию дерева смыслов (ALTGAS-OLAP) для проекта "Выборы на Блокчейне" [ALTGAS для Голосования]

"Дерево смыслов, как оно сейчас есть в примере выборов ["Выборы на Блокчейне"], тоже вызывает вопросы. Главный вопрос: это дерево будет формироваться «руками» или генерироваться по шаблону? Потому, что прописывать несколько тысяч ТИКов ручками и для каждого ТИКа писать свой набор инструкций – это дешевле сразу застрелиться. Так делать никто не будет! Разумное решение: сделать шаблон инструкций, который потом с помощью автоматической генерации кастомизировать под каждый ТИК, вставив номер ТИКа или какие-то ещё специфические для каждого ТИКа данные. Но тогда вопрос: а чем подход автоматической генерации инструкций без аргументов на основе шаблонов инструкций (шаблонов с аргументами) лучше, чем просто написать инструкции с аргументами и положить их отдельно от дерева. А на листах дерева написать вызов конкретной инструкции с конкретным набором параметров. Хотя опять-таки даже вызов инструкции на каждом листе дерева – тот ещё геморрой. Проще описать, что у нас есть N УИКов в которых M ТИКов, сгенерировать для каждого ТИКа собственный файл конфигурации (идентификаторов) который и положить рядом с VM в конкретном ТИКе-УИКе."

✔️

  • Масштабные деревья должны экспортироваться из графовых баз данных (например, [Neo4j Graph Platform]). Такие базы можно получить, например, из официальных источников. А затем уже "включается" генерация кода по шаблонам.

  • Автоматизированное заполнение дерева Оракула. Например, прямой экспорт из Microsoft-OLAP в ALTGAS-OLAP.


Вопрос 18

Где можно узнать про модели потребления энергии VM-ядрами (если мы строим EnergyCoin)?

✔️ Статьи и диссертации на данную тему:

2012

1. Christos I. Kargas

Energy Efficient Instruction Decoding in Application-Specific Instruction-Set Processors


Вопрос 19

Какой ASIP-софт можно использовать для генерации VM ядер?

✔️ Например, LISATek.

См. например, главу "Implementation of a VEX synthesizable processor in LISATek" из диссертации:

Sergio Foresta : "PROGETTO DI UNA ARCHITETTURA VERY LONG INSTRUCTION WORD PER APPLICAZIONI A BASSO CONSUMO DI POTENZA"


Вопрос 20

Про сложность концепции ALTGAS

"Что мне не нравится в текущей концепции ALTGAS

Насколько я понимаю, цель стартапа – создать платформу для быстрого и дешевого проектирования Блокчейн-систем. И, следовательно, одним из ключевых конкурентных преимуществ ALTGAS-а должна быть простота разработки таких Блокчейн-систем. То есть, в финале мы должны получить простой лего-конструктор из набора «кубиков», который должен позволить легко и непринужденно построить Блокчейн со своими виртуальными машинами и криптовалютой для заданной задачи (или набора задач).

Однако пока я не вижу такой «простоты Лего» и вот почему:

Внутри каждой инструкции (причем не в аргументе, задаваемой программистом, а в семантике самой инструкции) прописывается следующая инструкция. По аналогии с «Лего», это означает, что мы берем некий кубик из коробки, а из этого кубика тянется нить с другого кубика, а из другого кубика к третьему и так далее. То есть по сути мы имеем не набор кубиков для вольного творчества, а связанные нитками кубики для создания конкретной предопределенной машинки/домика/самолетика. Только это немного не «Лего», это машинка-домик-самолетик, поставляемая покупателям в таком экзотическом виде.

Иными словами: по факту мы имеем готовую программу с фиксированной функциональностью, а не инструмент для создания собственных программ или систем. Пользователь запускает первую инструкцию, а дальше виртуальная машина через генерацию от инструкции к инструкции начинает жить своей жизнью. А если мне (аки разработчику системы) нужно чуть-чуть модифицировать базовую систему, то мне нужно будет пройтись по всем инструкциям, которые размазаны по дереву смыслов, и модифицировать все коды ручками. Так себе работка, что особенно хорошо заметно как раз на примере выборов – 5000 ТИКов, для каждого ТИКа по паре инструкций, и вот бегай по всем этим инструкциям – переписывай семантику. При этом есть прекрасная альтернатива, которая применяется во всех физических и виртуальных процессорах – инструкция делает какое-то действие, а что будет дальше – за это отвечает следующая инструкция. Зачем менять проверенный веками подход к проектированию виртуальных машин? Или мы все-таки имеем не инструкции, а транзакции переходов между состояниями? Но тогда мы не должны говорить о виртуальных машинах, а брать и использовать инструменты описания конечных автоматов. Это немного другая история, которая к VM не имеет никакого отношения. Может так и надо программировать Блокчейн, но к принципу «Лего» это не имеет никакого отношения."

✔️


Вопрос 21

Про необходимость построения Дерева-Оракула для новых сервисов

"Я так и не понял, почему всегда нужно начинать проектирование виртуальной машины с дерева смыслов. Вот возьмем те же "Выборы" [Выборы на Блокчейне]. Возможно, где-то для собственного понимания ситуации я и распишу такое дерево, но при разработке системы выборов я буду плясать не от дерева, а от процедуры проведения выборов. Я буду думать и программировать сразу в терминах процедур-транзакций, типа «для выборов мне нужно: процедура регистрации кандидатов, процедура регистрации избирателей с защитой от повторной регистрации одного и того же лица, процедуры собственно голосования (опроса кандидата) процедуры подсчета голосов». Каждая процедура – транзакция-инструкция. Структура ТИКов - УИКов мне нужна для определения аргументов процедур-инструкций.

Например, проверить, что избиратель N прикреплен к ТИКу M, если да, то зарегистрировать. Соответственно нужно задать где-то (например в конфиге рядом с VM) номер конкретного тика. Но для написания процедуры регистрации, опять таки, мне достаточно понимать, что есть ТИК, есть УИК, есть ЦИК. А зачем из всего этого рисовать какое-то дерево? Не понимаю, в чем профит от такого рисования, а затем ещё и разбрасывания инструкций по листьям дерева Чтобы потом специально обученная программа всё собирала обратно? Ведь проще писать программу, когда все функции рядом и видно вся картина целиком! Или программист будет писать всё вместе, а потом автоматом раскидывать код по листам для того, чтобы потом другим «автоматом» собрать всё заново? Единственное, для чего может пригодиться это дерево смыслов, это для обучения нейросети а-ля чатбот, чтобы в финале человек, незнакомый с программированием мог написать «хочу систему выборов» и этот чатбот выдал ему исходники-бинарники готовой Блокчейн-системы для запуска в боевую эксплуатацию. Но в этом случае возникает ещё 100500 вопросов из серии «как это реализовать» и тогда вообще надо начинать не с Блокчейна, а с вопросов построения сети и её обучения. Пока ничего подобного в «целях проекта» я не встретил."

✔️


Вопрос 22

Какие типы кошельков AWAL могут быть?

✔️

AWAL - это семейство сверх-защищенных кошельков с частично различным функционалом.

Например,

  • Структурный кошелек AWAL (AWAL-контентный кошелек)
  • Кошелек Создателя (AWAL-Creator-Wallet)

Полезные ссылки

  1. ALTGAS Foundation Whitepaper

Основы ALTGAS

FUPE

ALTGAS-Блокчейн

F8-Space

Микро-протоколы

ONTO-Оракул(GONT)

EnergyCoin-StableCoin

Инфраструктура

Приложения

Экономика

R&D

ALTGAS FLOWS

Whitepaper

Проекты (текущие)

AppNotes - все примеры

FAQ - все темы

Clone this wiki locally
You can’t perform that action at this time.