Решение. Proof of Tsar
Last updated
Last updated
С целью решения существующих проблем мы предлагаем ряд изменений в архитектуре блокчейна, затрагивающие протоколы связи, сетевую инфраструктуру, межсетевые соглашения, консенсусные алгоритмы и прочее.
Платформа Relictum Pro не зависит от способа коммуникаций, просто есть нода, а каким образом доставлено сообщение, не имеет значения.
На данный момент используется собственная технология коммуникаций — _HyperNet, которая работает над или поверх Интернет.
Следующий способ организации сети в будущем может быть использован на базе Bluetooth, WiFi, спутниковая связь, т.е. коммутации каналов на базе Bluetooth и/или WiFi и других перспективных протоколов.
Существующая организация сети современных блокчейнов — это пиринговые сети (P2P). В блокчейн-платформе Relictum Pro используется уникальный протокол, в основе которого лежит протокол TCP/IP, в котором виртуальный канал связи с каждой нодой образуется поверх сети Интернет. Преимущества данной сети в ее надежной устойчивости и изолированности от общего сегмента сети Интернет. В этом виртуальном канале передается только информация Relictum Pro, что в несколько раз увеличивает скорость передачи данных.
В качестве транспорта мы используем новый тип сети, на основе сети передачи данных четвертого уровня модели OSI. HyperNet — сеть коммутации виртуальных каналов. HyperNet дает постоянное устойчивое соединение между всеми нодами на маленький ограниченный промежуток времени (от 0.5 до 10 с), в зависимости от нагрузки сети. При малой загруженности сети этот промежуток может быть до 10 с, а при загруженной сети уменьшаться до менее 0.5 с.
Узлы сети (ноды) полностью одинаковые и представляют собой бинарный файл с возможностью подгрузки и управления реестром.
Нода, при первом запуске, автоматически определяет к какому типу она относится:
Каждые 0.5 сек происходит регенерация сети (перекоммутация всех узлов), наподобие регенерации оперативной памяти ЭВМ, во главе с одной главной нодой – «Царем» и стоящими под ним «Генералами», которые собирают транзакции и передают их «Царю» для обработки. После этого «Царем» раздаются блоки «Генералам», а они раздают дальше всем по цепочке. «Царь» и «Генералы» выбираются автоматически и постоянно меняются.
«Генералом» и «Царем» может быть любая нода. Но «Царь», в следующую генерацию, после регенерации сети, уже не может быть ни «Царем» ни «Генералом». Как и “Генерал”, в свою очередь, не может быть генералом два раза подряд.
Таким образом, исчезают коллизии двойных трат и других паразитных событий. При этом «Царь» не знает, что он «Царь» в момент того, когда он «Царь». Расчетные данные показывают, что, вероятность коллизии хешей блоков может наступить через 100 лет, но эта коллизия может быть только с тем хешем, который был 100 лет назад, что делает ее не актуальной. Достигается это благодаря сквозной нумерации каждого блока Master_Chain.
Если произошел разрыв соединения с нодой, то нода уходит в слип-режим (режим 4). Когда устанавливается связь с нодой, нода проходит проверку на целостность, проверяется актуальность блоков и начинает подгружать недостающие блоки. После этого нода переходит в режим соединения с сетью.
Ранжирование нод зависит от числа транзакций, которые складываются из:
Количества обращений к ноде — к распределенному хранилищу за документами;
Времени присутствия в сети;
Количества сгенерированных транзакций;
Количества проходящих транзакций через ноду.
Нецелесообразно в один блок вмещать все транзакции, которые невозможно поместить в один блок. Это ведет к уменьшению скорости передачи данных, а также к снижению скорости поиска необходимой информации.
Таким образом, отметаются всякого рода коллизии. Помимо записи в блок хеша события, при формировании нового блока, берется целиком хеш предыдущего блока + целое значение (впереди блока ставим сквозной порядковый номер блока). Есть главная цепочка блоков – Master_Chain, в которой записывается только хеш какого-либо блока из нижестоящих и боковых смарт-контрактов.
Параллельно с главным Master_Chain формируются различные независимые цепочки — это смарт-контракты, которые организуют трехмерное распределение, например:
первый смарт-контракт — генерация токенов
второй смарт-контракт — продажа товаров через магазин
третий — криптобиржа;
четвертый — доставка товара и др.
Таким образом, организация цепочек смарт-контрактов и главной цепочки Master_Chain приводит к четырехмерной модели организации распределения блоков.
Смарт-контракт самостоятельно отслеживает были ли в полной мере исполнены все условия контракта;
Возможность проводить операции с разными типами и видами смарт-контрактов, возможность генерации новых смарт-контрактов с новыми типо-свойствами или свойство-типами;
Уже сегодня в платформе Relictum Pro может быть заключен смарт-контракт одновременно между 10 контрагентами.
Каждая цепочка (смарт-контракт) имеет индекс и каждый блок этой цепочки имеет свой индекс в Master_Chain. В Master_ Chain указывается из какого индекса этой цепочки было обращение, но, на самом деле, они идут один за другим. Количество возможных новых встраиваемых смарт-контрактов неограничено по количеству.
Все ноды идентичные. Каждая нода при инициации определяет сама себя и к какой группе она относится (как опция, выбирается владельцем ноды вручную).
Полноценные ноды — бинарные исполняемые файлы, которые могут автоматически инициализироваться в:
Нода является, в том числе, и портфелем, в который входит:
Возможность создания собственного ICO;
Возможность создания своей биржи;
Возможность создания собственной валюты (смарт-контракт коинов, смарт-контракт майнера).
Relictum Pro позволяет производить подтверждения транзакций внутри сети текущих криптовалют: Биткойна, Эфира, Латкоина, ДогКоина и др. Подтверждения транзакций происходит мгновенно. Даже если Биткойн не дошел до владельца, пользователь уже сразу может распоряжаться Биткойном.
Возможность интеграции в платформу Relictum Pro сторонних систем учета, документирования и т.д.
Сеть платформы имеет собственный SDK под все платформы на динамических библиотеках и API с примерами под все типы языков программирования ( Modula, Delphi, Python, C/C++ и т.д.)
Relictum Pro предоставляет работу с протоколами не только SDK и API, но и с собственным протоколом блокчейн-платформы на низком уровне сокетный протокол: высокая степень защиты, скорость.
Используются собственные методы передачи данных, которые могут передавать не только информацию, но и блоки, байты, целиком файлы для внешних потребителей. Могут использоваться для организации внешнего хранилища.
Relictum Pro — это дополненная модификация математики хеширования на основе SHA1. Главное преимущество в преобразовании из 20 байт в 32 байт (в собственный хеш). Это дает высокую криптоустойчивость, в том числе и от перспективного квантового компьютера.
Одна единственная нода, в пределах от 0.5 до 10 сек принимает решение, сеть обновляется (регенерирует) и выбирается другая главная нода, которая собирает инструкции, формирует блоки и раздает всем нодам, т.е. сеть динамически меняется каждую секунду. Это дает преимущество, которое исключает различного рода неоднозначности – коллизии, двойные траты и другое. Отсутствие стандартных принципов консенсуса. Чем больше нод в сети, тем выше производительность. Достигается это уникальной архитектурой Proof of Tsar и организацией сети коммутации виртуальных каналов.
Распределенное хранилище не требует подтверждения получения данных. Благодаря организации различных цепочек смарт-контрактов ускоряется поиск раздробленных файлов и их просмотр. По эмпирическим данным, скорость скачивания существенно быстрее P2Р сети.
Хранение любых оцифрованных документов и набора данных, файлов в любом объеме с мгновенным доступом к любой хранящейся информации. Распределенные данные остаются пожизненно в системе, в отличие от какого-либо хостинга.
Автоматически организуется авторское право с распознаванием интеллектуального оцифрованного труда и пиратской копией. Автоматизируется вознаграждение автору за использование произведения, минуя посредников (использование смарт-контракта «Авторское право».
Ник Сабо, основатель понятия “смарт-контракта”, выделил три нерешенные проблемы:
Безопасное хранение и управление ключами;
Децентрализованные биржи;
Сделать решения второго уровня более дружелюбным, по отношению к пользователю, особенно посредством автоматического роутинга, в то же время, не пренебрегая минимизацией доверия.
Берется хеш лица, совместно с SecureCall подтверждение транз акции при помощи звонка на телефон. Во время вызова вводится пароль, используя DTMF сигнал совместно со следующими решениями:
После удачной транзакции приватный ключ теряет актуальность, а клиент неизбежно обязан генерировать новый ключ (или это делается автоматически);
В цепочку смарт-контракта записывается публичный хеш от хеша конкатенации [Token pass phrase] или [Token + random text] в бинарном виде;
Предусмотрена возможность использования 2-х коротких ключей с последовательной проверкой. После проверки 1-го ключа (независимо от результата проверки) предлагается ввод второго ключа. Механизм предполагает после 1-й проверки выдать строку, которая является хешем 2-го ключа, а значит хакеру понадобится подбирать 2-й ключ, не зная вообще, верный ли хеш 1-го ключа. Для исключения взлома предусмотрена возможность ограничения количества попыток.
