Pages:
Author

Topic: Децентрализованное хранение данных - page 2. (Read 762 times)

full member
Activity: 411
Merit: 135
Также Вы не раскрыли мотивы участников сети, почему они будут поддерживать работу сети, каковы их стимулы.



Также вот мое видение такой системы. Я считаю, что ничего лучше, чем система торрентов для хранение информации пока не придумали.

Поэтому, общий принцип хранения нужно брать у торрентов.


Дмитрий, привет, а какая мотивация у торрентов, интересно как ты думаешь?



jr. member
Activity: 154
Merit: 6
При таком методе получается зашифрованная сеть, где каждый участник может создавать сайты (и не только), а контролировать трафик становится проще, так как каждый участник содержит свой публичный ключ, которым он «просматривает сайт», ip адреса при этом вырезаются из запросов и ответов, делая сеть анонимной. Тем самым изначально есть авторизация, а так же возможно посмотреть баланс пользователя, баланс токенов (связанных с сайтом, например) и совершать процесс оплаты не уходя с сайта и из сети. Единственным минусом на момент тестов была производительность — в таком виде сайты грузятся в 10 раз медленнее, так как пересылаются по децентрализованной сети. Описанный выше механизм это всего лишь концепт, но уже наполовину реализованный.
Идея конечно хорошая, но уже есть похожий проект I2P
legendary
Activity: 2534
Merit: 1510

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

Я считаю, что Вы перегорели потому, как охватили слишком большой объем работы, в то время чтобы сосредоточиться на главном. Вы же должны понимать, что если не зайдет ваша идея, то и всё остальное не зайдет.

А по тому было бы оптимально Вам, вначале найти главное в своей идеи, что всех привлекает и потом уже вокруг этого что-то достраивать.


Теперь начнем с консенсуса. Я Вам предлагаю рассмотреть для себя мой Алгоритм распределенного доверия.

В чем его фишка - это общая синхронизация только при построении блока 1 раз в час, а дальше асинхронное распостранение информации, идея как у обходного листа при увольнении, только подписи можно получать ото всех параллельно, а не по одиночке.

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


Идем далее. Мне кажеться, что пробовать вписывать в классический блокчейн информацию для хранения идея не очень, как -то наверное мало её можно вместить.


Также Вы не раскрыли мотивы участников сети, почему они будут поддерживать работу сети, каковы их стимулы.



Также вот мое видение такой системы. Я считаю, что ничего лучше, чем система торрентов для хранение информации пока не придумали.

Поэтому, общий принцип хранения нужно брать у торрентов.

Далее это управление сетью, вот тут нам и понадобиться децентрализация с моим консенсусом, так как она позволяет легко отбиваться от многих атак, а также заставляет всех участвовать в работе сети, тем самым поддерживая её хорошую работоспособность и численность.

Настоящая децентрализация исключает централизованную часть у торрентов, как сейчас.

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

copper member
Activity: 36
Merit: 11
Часть текста не влезла


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


Размещу список ссылок на составные части крипты на гитхабе, надеюсь что не будет бана. Каждую часть вы можете форкнуть и сделать что-то свое, весь код по MIT лицензией
Виртуальная машина - https://github.com/gettocat/orwelldb
Модуль консенсуса (поддерживает 5 консенсусов на данный момент) - https://github.com/gettocat/consensusjs
Парсинг блоков и транзакций биткоина на nodejs - https://github.com/gettocat/bitPony
Шифрование и дешифрование в основу datascript - https://github.com/gettocat/bitowl, сам datascript описан в виртуальной машине.
Децентрализованные выборы - https://github.com/gettocat/democracyjs
Старая версия криптовалюты - https://github.com/gettocat/orwell
SPV клиент - https://github.com/gettocat/orwell-spv
Примитивы (TX, BLOCK и их сериализация/десериализация) - https://github.com/gettocat/friday-primitives
Актуальная версия кода криптовалюты - https://github.com/gettocat/friday

Немного документации:
По виртуальной машине и datascript: https://github.com/gettocat/orwelldb/wiki
Общая документация, правда первой версии, но большая часть +- актуальна и в новой - https://github.com/gettocat/orwell/blob/master/docs/intro.md

Отвечу на вопросы, предложения, улучшения – приветствуются новые идеи.
Кстати, не подскажете в какой раздел можно опубликовать похожий текст на английском языке на данном форуме? Какой подойдет лучше, если такой вообще есть?
copper member
Activity: 36
Merit: 11
Всем привет, я занимаюсь блокчейн-разработкой. Примерно 3 года назад начал делать свою криптовалюту: за 4 месяца сделал прототип, spv кошелек, майнинг пул и обзорщик блоков, потом пришлось притормозить на некоторое время. Где-то год назад продолжил разработку, вернее начал всё с начала и вот что получилось.

Внимание! В этом посте я ничего не рекламирую, публикую ссылки только на гитхаб код, который по сути является бесполезным и нигде не используется. Просто обсуждение идеи с уже готовым прототипом.



История

Начну издалека. В 2017 году я проникся технологией блокчейн (на самом деле раньше, но возможность что-то сделать появилась только в 17м), еще до биткоина по 20к. Начать изучение мне всегда проще на практике, поэтому я сразу решил, что буду писать что-то своё. Тогда меня заинтересовала мысль о том, что блокчейн это реестр, т.е. база данных. Но почему тогда в ней хранят в основном финансовые данные? Моя идея была в том, чтоб блокчейн использовать на ряду с финансовыми данными еще и произвольные.

На реализацию своей задумки (первый рабочий прототип) ушло примерно все лето и начало осени. Уже к зиме 2017 у меня был рабочая полная нода, так же я написал spv клиента, доработал сторонний майнинг пул (единственный проект из окружения, который я не писал сам), обзорщик блоков и написал тонну документации, иии… из-за обстоятельств пришлось положить всё в долгий ящик.

Факт того, что у меня была рабочая криптовалюта с определенной идеей и инфраструктурой и я пропустил момент, когда все, абсолютно все криптовалюты показывали свои максимумы и можно было запустить любую криптовалюту (даже какой-нибудь токен, обеспеченный кирпичами) — добавил немного разочарования в мои светлые замыслы, но я не отчаялся.

Спустя год я начал с нуля уже более основательно. Кстати время, которое не было занято проектированием и созданием криптовалют – я использовал так же с умом. Сделал телеграмм канал и разбирал криптовалюты из топа 10 в техническом плане, собирая информацию для будущей криптовалюты. Это очень пригодилось.


Суть

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



Datascript это одно или несколько обращений к базе данных, он позволяет хранить запросы к обычным реляционным базам данных (и не только) в блокчейне.  Каждая запись в datascript имеет поле dataset, что означает таблицу, operator, что означает тип обращения, возможные варианты create, write, settings. Create – создание dataset, write – добавление записей, settings – обновление настроек. Публичный ключ отправителя транзакции выступает в роли авторизационного ключа.
Каждый datascript имеет readScript и writeScript, на стек ориентированном языке, сходном с bitcoin script. readScript определяет кто может прочитать datascript содержимое, и по сути представляет из себя шифрование сообщения (либо его отсутствия для контента, который может быть прочитан всеми), readScript хранится в самом datascript. WriteScript указывается при создании/изменении настроек и указывает на то, кто может писать в определенный датасет  (например: все, все публичные ключи из списка привилегий). Список привилегий так же указывается в настройках dataset, так же туда входит владелец датасета, а также публичный ключ самого адреса.
По аналогии с Ethereum имеется VM (виртуальная машина), которая считывает все новые datascript с подтвержденных транзакций и импортирует их.

Что это означает – каждый участник может, имея приватный ключ – создать базу данных, и неограниченное количество датасетов (таблиц) в ней, и хранить в ней произвольную структурированную информацию.  
Эта модель позволяет хранить данные внутри самого блокчейна, что дает некоторую гибкость, но при этом добавляет проблем с хранением, ведь блокчейн биткоина разросся уже почти до 500 гигабайт, и это только на финансовых данных. Если добавить сюда еще и произвольные — получится избыточно. Поэтому хранение ограничилось лишь всякими ключами и связями для авторизации. И к слову, валидация всех правил происходит на уровне VM при создании, но необходимо синхронизировать её с блокчейном.

Например, сделал пару системных датасетов в системной базе данных: domain, masternode, token, dapp, тем самым можно создавать домены для каждого адреса/базы данных и оперировать не набором непонятных символов при отправках транзакций, а удобным ником (к примеру), кроме того, домены, по задумке могут использоваться в dapps (о которых напишу позже).
Что касается dataset token и masternode — в первом хранятся пользовательские токены, которые каждый участник может создать, а masternode хранит список публичных ключей участников, которые являются валидаторами сети. Тут необходимо небольшое отступление.


Consensus

Основа блокчейна — это консенсус, т.е. договоренность между нодами, некоторый набор правил, которые действуют в сети, и все их исполняют чтобы сеть была работоспособной. Например — в биткоине действует консенсус Proof of Work. Суть консенсуса сводится к проверке новых блоков, публикуемых участниками сети. В биткоине участники сети в случайном порядке публикуют блоки — кто первый найдет, того и награда. В своей сети изначально делал так же, но позже решил, что это не рационально, так как хватит одного майнера из биткоина, чтобы нарушить работу моей сети и применить атаку 51%. Поэтому спустя какое-то время я реализовал модуль консенсуса consensusjs, который описал несколько разных консенсусов: centralized, PoW, PoS (PoW+PoS), static dpow, static dos, dynamic dpos. На последнем я и остановился.

Dynamic delegate pos (ddpos) предполагает, что в самом начале если определенное число делегатов (валидаторов) список которых сортируется по рейтингу и количеству монет в пользовании — и создается раунд, в течении которого каждый валидатор из списка публикует блок в строгом порядке. Когда раунд заканчивается рассчитывается новый, при этом каждый участник сети имеет возможность самостоятельно рассчитать текущий раунд и следующий раунд на основе открытых данных из сети.

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


Валидаторы и стекинг

Данная часть является недоработанной в данный момент
Каждый участник, который имеет 1000 монет может отправить свой публичный ключ в таблицу мастернод и участвовать в раундах валидации. Участники, имеющие менее 1000 монет, могут передать (делегировать) свои монеты (при этом монеты остаются на их кошельке, но ими невозможно воспользоваться без потери пассивного дохода от стекинга) любому валидатору, тем самым начав зарабатывать пассивный доход. Валидатор получает % от пассивного дохода участника и сам определяет свою награду за делегирование.


Democracy

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


Токены и Stock


Токены представляют собой отдельную базу данных с датасетом token, чтобы инициировать токен необходимо просто отправить транзакцию в системную базу данных и таблицу tokens, а так же создать датасет token в новой этой базе данных. Кроме того, произвести эмиссию токенов возможно отправкой одного write dataset где отправителем и получателем токена является эмитент, в этом случае система сгенерирует N токенов, указанных в параметре amount.
Кроме токенов так же существует сущность stock (акции), являющаяся копией токенов с тем отличием, что отправка монет основной криптовалюты на адрес базы данных токена генерирует «дивиденды» всем держателям этих «акций». Для примера:
Есть база данных stock1, содержащая акцию ST, и 3 держателя:
A – 1000
B – 2000
C – 7000 с общей эмиссией в 10 000 монет. При отправке 100 монет (не токенов!) на адрес stock1 – система генерирует всем участникам выплаты так же в монетах:
A – получит 10 монет
B – 20 монет
C – 70 монет

dApps

Концепцию dapps была придумана чуть погодя после пика bitcoin в начале 18го. Тогда была идея сделать её через регистрацию приложения (публичного ключа) в блокчейне, регистрацию воркеров (публичных ключей) в системные таблицы, связь воркеров с приложением и уже воркеры бы работали в своем, изолированном блокчейне. В этой концепции есть еще viewer, т.е. часть приложения с интерфейсом для общения с клиентом, в качестве viewer может выступать как браузер, так и отдельное приложение. Позже от этой идеи я отказался, так как довольно долго реализовывать и сделал несколько проще.

Вы так же можете зарегистрировать dApp в блокчейне, связать его с доменом, а участник, зная домен, который связан с публичным ключом приложения — взаимодействовать с этим приложением. При обращении к домену, прозрачный dns сервер в клиенте сети считывает запрос пользователя, шифрует его с помощью ecdh шифрования, так, что прочитать содержимое сможет только участник с публичным ключом приложения и отправляет в сеть. Приложение получает этот запрос, отправляет его на endpoint, указанный в конфиге для этого приложения, и возвращает результат в сеть, так же зашифрованным.

Кстати, забавный факт: так как ноды общение между собой шифруют с помощью ecdh шифрования и dApp отправляет и принимает данные зашифровано — в моменты пересылок между нодами часть сообщения зашифрована два раза.

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

В данный момент у моей сети есть прототип и с открытым исходным кодом, внизу этого поста вы можете найти ссылки на github аккаунт и посмотреть исходный код или сделать форк. Я ничего не рекламирую и не предлагаю, просто рассказываю о своей идее, так как нет средств (и желания, в связи с тем, что перегорел) продолжать конкретно эту идею. Возможно, в будущем вернусь к ней, но не факт.
Pages:
Jump to: