> For the complete documentation index, see [llms.txt](https://wiki.relictum.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.relictum.pro/ru/baza-znanii/reshenie.-proof-of-tsar.md).
# Решение. Proof of Tsar
С целью решения существующих проблем мы предлагаем ряд изменений в архитектуре блокчейна, затрагивающие протоколы связи, сетевую инфраструктуру, межсетевые соглашения, консенсусные алгоритмы и прочее.
Платформа Relictum Pro не зависит от способа коммуникаций, просто есть нода, а каким образом доставлено сообщение, не имеет значения.
На данный момент используется собственная технология коммуникаций — \_HyperNet, которая работает над или поверх Интернет.
Следующий способ организации сети в будущем может быть использован на базе Bluetooth, WiFi, спутниковая связь, т.е. коммутации каналов на базе Bluetooth и/или WiFi и других перспективных протоколов.
### Организация сети — первый отличительный механизм
Существующая организация сети современных блокчейнов — это пиринговые сети (P2P). В блокчейн-платформе Relictum Pro используется уникальный протокол, в основе которого лежит протокол TCP/IP, в котором виртуальный канал связи с каждой нодой образуется поверх сети Интернет. Преимущества данной сети в ее надежной устойчивости и изолированности от общего сегмента сети Интернет. В этом виртуальном канале передается только информация Relictum Pro, что в несколько раз увеличивает скорость передачи данных.
В качестве транспорта мы используем новый тип сети, на основе сети передачи данных четвертого уровня модели OSI. HyperNet — сеть коммутации виртуальных каналов. HyperNet дает постоянное устойчивое соединение между всеми нодами на маленький ограниченный промежуток времени (от 0.5 до 10 с), в зависимости от нагрузки сети. При малой загруженности сети этот промежуток может быть до 10 с, а при загруженной сети уменьшаться до менее 0.5 с.
### Как это работает
Узлы сети (ноды) полностью одинаковые и представляют собой бинарный файл с возможностью подгрузки и управления реестром.
Нода, при первом запуске, автоматически определяет к какому типу она относится:
### Механизм организации Proof of Tsar
Каждые 0.5 сек происходит регенерация сети (перекоммутация всех узлов), наподобие регенерации оперативной памяти ЭВМ, во главе с одной главной нодой – «Царем» и стоящими под ним «Генералами», которые собирают транзакции и передают их «Царю» для обработки. После этого «Царем» раздаются блоки «Генералам», а они раздают дальше всем по цепочке. «Царь» и «Генералы» выбираются автоматически и постоянно меняются.
«Генералом» и «Царем» может быть любая нода. Но «Царь», в следующую генерацию, после регенерации сети, уже не может быть ни «Царем» ни «Генералом». Как и “Генерал”, в свою очередь, не может быть генералом два раза подряд.
### Мы решили проблему неоднозначности
Таким образом, исчезают коллизии двойных трат и других паразитных событий. При этом «Царь» не знает, что он «Царь» в момент того, когда он «Царь». Расчетные данные показывают, что, вероятность коллизии хешей блоков может наступить через 100 лет, но эта коллизия может быть только с тем хешем, который был 100 лет назад, что делает ее не актуальной. Достигается это благодаря сквозной нумерации каждого блока Master\_Chain.
Если произошел разрыв соединения с нодой, то нода уходит в слип-режим (режим 4). Когда устанавливается связь с нодой, нода проходит проверку на целостность, проверяется актуальность блоков и начинает подгружать недостающие блоки. После этого нода переходит в режим соединения с сетью.
Ранжирование нод зависит от числа транзакций, которые складываются из:
* Количества обращений к ноде — к распределенному хранилищу за документами;
* Времени присутствия в сети;
* Количества сгенерированных транзакций;
* Количества проходящих транзакций через ноду.
### Организация блоков — второй отличительный механизм
Нецелесообразно в один блок вмещать все транзакции, которые невозможно поместить в один блок. Это ведет к уменьшению скорости передачи данных, а также к снижению скорости поиска необходимой информации.
### Отличительный механизм заключается в том, что в блок записывается только хеш одного события (транзакции), которую изменить уже нельзя
Таким образом, отметаются всякого рода коллизии. Помимо записи в блок хеша события, при формировании нового блока, берется целиком хеш предыдущего блока + целое значение (впереди блока ставим сквозной порядковый номер блока). Есть главная цепочка блоков – Master\_Chain, в которой записывается только хеш какого-либо блока из нижестоящих и боковых смарт-контрактов.
Параллельно с главным Master\_Chain формируются различные независимые цепочки — это смарт-контракты, которые организуют трехмерное распределение, например:
* **первый смарт-контракт** — генерация токенов
* **второй смарт-контракт** — продажа товаров через магазин
* **третий** — криптобиржа;
* **четвертый** — доставка товара и др.
Таким образом, организация цепочек смарт-контрактов и главной цепочки Master\_Chain приводит к четырехмерной модели организации распределения блоков.
### Возникают следующие особенности платформы Relictum Pro:
* Смарт-контракт самостоятельно отслеживает были ли в полной мере исполнены все условия контракта;
* Возможность проводить операции с разными типами и видами смарт-контрактов, возможность генерации новых смарт-контрактов с новыми типо-свойствами или свойство-типами;
* Уже сегодня в платформе Relictum Pro может быть заключен смарт-контракт одновременно между 10 контрагентами.
### Принципиальная схема Блока смарт-контракта:
Каждая цепочка (смарт-контракт) имеет индекс и каждый блок этой цепочки имеет свой индекс в Master\_Chain. В Master\_ Chain указывается из какого индекса этой цепочки было обращение, но, на самом деле, они идут один за другим. Количество возможных новых встраиваемых смарт-контрактов неограничено по количеству.
### Нода (узел сети) — динамичность и функционал
Все ноды идентичные. Каждая нода при инициации определяет сама себя и к какой группе она относится (как опция, выбирается владельцем ноды вручную).
Полноценные ноды — бинарные исполняемые файлы, которые могут автоматически инициализироваться в:
Нода является, в том числе, и портфелем, в который входит:
* Возможность создания собственного ICO;
* Возможность создания своей биржи;
* Возможность создания собственной валюты (смарт-контракт коинов, смарт-контракт майнера).
### Внутренние возможности
Relictum Pro позволяет производить подтверждения транзакций внутри сети текущих криптовалют: Биткойна, Эфира, Латкоина, ДогКоина и др. Подтверждения транзакций происходит мгновенно. Даже если Биткойн не дошел до владельца, пользователь уже сразу может распоряжаться Биткойном.
Возможность интеграции в платформу Relictum Pro сторонних систем учета, документирования и т.д.
### Внешние возможности Relictum Pro (сети):
Сеть платформы имеет собственный SDK под все платформы на динамических библиотеках и API с примерами под все типы языков программирования ( Modula, Delphi, Python, C/C++ и т.д.)
Relictum Pro предоставляет работу с протоколами не только SDK и API, но и с собственным протоколом блокчейн-платформы на низком уровне сокетный протокол: высокая степень защиты, скорость.
Используются собственные методы передачи данных, которые могут передавать не только информацию, но и блоки, байты, целиком файлы для внешних потребителей. Могут использоваться для организации внешнего хранилища.
### Механизм хеширования
Relictum Pro — это дополненная модификация математики хеширования на основе SHA1. Главное преимущество в преобразовании из 20 байт в 32 байт (в собственный хеш). Это дает высокую криптоустойчивость, в том числе и от перспективного квантового компьютера.
### Решение проблемы атаки 51% и других неоднозначностей
Одна единственная нода, в пределах от 0.5 до 10 сек принимает решение, сеть обновляется (регенерирует) и выбирается другая главная нода, которая собирает инструкции, формирует блоки и раздает всем нодам, т.е. сеть динамически меняется каждую секунду. Это дает преимущество, которое исключает различного рода неоднозначности – коллизии, двойные траты и другое. Отсутствие стандартных принципов консенсуса. Чем больше нод в сети, тем выше производительность. Достигается это уникальной архитектурой Proof of Tsar и организацией сети коммутации виртуальных каналов.
### Распределенное хранилище
Распределенное хранилище не требует подтверждения получения данных. Благодаря организации различных цепочек смарт-контрактов ускоряется поиск раздробленных файлов и их просмотр. По эмпирическим данным, скорость скачивания существенно быстрее P2Р сети.
### **Приемущества:**
Хранение любых оцифрованных документов и набора данных, файлов в любом объеме с мгновенным доступом к любой хранящейся информации. Распределенные данные остаются пожизненно в системе, в отличие от какого-либо хостинга.
Автоматически организуется авторское право с распознаванием интеллектуального оцифрованного труда и пиратской копией. Автоматизируется вознаграждение автору за использование произведения, минуя посредников (использование смарт-контракта «Авторское право».
### Безопасное хранение и управление ключами
Ник Сабо, основатель понятия “смарт-контракта”, выделил три нерешенные проблемы:
* Безопасное хранение и управление ключами;
* Децентрализованные биржи;
* Сделать решения второго уровня более дружелюбным, по отношению к пользователю, особенно посредством автоматического роутинга, в то же время, не пренебрегая минимизацией доверия.
### Как работает наша разработка биометрического распознавания лица:
Берется хеш лица, совместно с SecureCall подтверждение транз акции при помощи звонка на телефон. Во время вызова вводится пароль, используя DTMF сигнал совместно со следующими решениями:
* После удачной транзакции приватный ключ теряет актуальность, а клиент неизбежно обязан генерировать новый ключ (или это делается автоматически);
* В цепочку смарт-контракта записывается публичный хеш от хеша конкатенации \[Token pass phrase] или \[Token + random text] в бинарном виде;
* Предусмотрена возможность использования 2-х коротких ключей с последовательной проверкой. После проверки 1-го ключа (независимо от результата проверки) предлагается ввод второго ключа. Механизм предполагает после 1-й проверки выдать строку, которая является хешем 2-го ключа, а значит хакеру понадобится подбирать 2-й ключ, не зная вообще, верный ли хеш 1-го ключа. Для исключения взлома предусмотрена возможность ограничения количества попыток.