# Решение. 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-го ключа. Для исключения взлома предусмотрена возможность ограничения количества попыток.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://wiki.relictum.pro/ru/baza-znanii/reshenie.-proof-of-tsar.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.