[RU] Использование промежуточного хаба в протоколе Голос

18.02.2020 19:24:45

Опыт современных сетей указывает на один из недостатков децентрализованного подхода, а именно дублирование информации.

Экономически выгоднее хранить две-три копии данных. Одна копия для непосредственного использования, другая бекап на случай потери или повреждения первой копии. Бекап (резервная копия) хранится в другом дата-центре, параноики хранят ещё одну копию в дополнительном дата-центре.

Исторически и практически сложилась такая ситуация, что пользовательские данные никак не защищены. То один случай, то другой. Провайдеры лишь пожимали плечами и создавали пресс-релиз, где извинялись перед пострадавшими пользователями. Всякое бывает. Учитывая, что данные теряют довольно крупные компании возникает предположение, что бекапа вовсе и не было.

Что же с блокчейном? Каждый делегат хранит копию всех блоков в цепи. Все данные которые туда были записаны, как критические для состояния системы, так и необязательные. Если допустить идею создания протокола для децентрализованной социальной сети, то возникает резонный вопрос — а что делать с данными? Посмотрим на данные от Facebook, там петабайты данных, более десяти дата центров по всему миру. Даже если рассматривать в теории малюсенькую часть популярности децентрализованной социальной сети, например, с данными которые займут один дата-центр — что делать делегатам?

Каждому делегату строить по дата-центру? Это банально неэффективно и проигрывает в экономической целесообразности частным решениям.

Ответ есть.

Не нужно хранить данные в блоках. Можно хранить ссылку на файл, хэш от данных для проверки подлинности и адресации контента. Да и о какой мы можем говорить децентрализации, если ожидаем, что кто-то будет хранить данные за нас?

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

Это может быть одно и тоже — использовать сервер для себя и сдавать оставшееся место кому-то ещё. Назовем это сервер-шеринг :)

Назовем подобную инициативу VIZ Hub. Место, где пользователь может предоставлять или покупать услугу для хранения, обработки и передачи данных, будь то тело действий в протоколе Голос или десяток фотографий с дружеской посиделки. Эти данные могут быть совместимы с протоколом Голос или представлять собой аналог IPFS (для миниатюр можно использовать хэш от конкатенации хэша файла с определенным суффиксом).

Это также в теории решает проблему с GDPR, масштабированием сети и поддержкой такого объема данных в самом блокчейне. Пользователь в панели управлении сможет удалить данные, ограничить доступ к ним, скачать в виде отдельного архива или переехать к другому провайдеру в случае расширения потребностей. Как указать в блокчейне, что пользователь доверил обработку своих данных определенному хабу? Можно просто написать адрес хаба в метаданных аккаунта.

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

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

Ну что, посмотрим, станут ли подобные мечты когда-нибудь реальностью?


4
6 Awards
11.291991 Ƶ
Show comment form
Comments

18.02.2020 19:39:12

Это частичное решение проблемы. Все блокчейны со временем будут сталкиваться с огромным размером чейна, и им придётся это решать. Как именно - варианты разные. Это может быть prune старых данных + снапшоты стэйта, или что-то другое.

19.02.2020 05:31:30

Действительно, если тебе что-то нужно, то и храни эти данные. В таком ключе многие DLT постепенно перейдут к слепку стэйта системы и хранение истории будет необязательным. Важен стейт, а не строгие данные можно "выкинуть". Но не в истории, где есть custom операции и на их основе существуют другие протоколы и dapps. В статье я немного заглядываю в будущее, когда распределенная система столкнется с проблемой хранения данных. Пропускная способность не резиновая. Да и упираемся в скорость передачи данных/скорость света. Поэтому хабы — отличное возможное решение.

Много споров про то, что хранить в блокчейне. Есть определенная шкала разумности. Видео в 4k, как мне кажется, хранить не разумно. Конечно, зависит от позиционирования самой технологии и системы. Но блокчейн придумали для критически важной информации, аудита в виде криптографического доказательства действий идентифицированных ключей.

19.02.2020 18:45:27

Но не в истории, где есть custom операции и на их основе существуют другие протоколы и dapps.

Да тут тоже можно придумать как это утащить в стэйт. Но вообще надо пробовать разные подходы, экспериментировать.

Думаю, через какое-то время кто-нибудь озадачится проектированием архитектуры блокчейна на большое кол-во данных. "Что если наш блокчейн разрастётся то терабайт, а потом и петабайт данных? Как это поддерживать? Какие методики можем применить?" Может быть, кто-то имплементирует нарезку block_log на chunk-и, которые будут храниться на разных нодах, с заданным уровнем избыточности? Или другие варианты.

20.02.2020 05:34:12

Не будут же "делегаты" отвечать за каждый придуманный кем-то протокол. Я склоняюсь больше к сайд-чейнам/сайд-проектам - которые как оракулы формируют свой стэйт и его можно через api запросить, проверить подписи при желании. А может и вовсе вынесут активность в кросс-состояние, без записи в бч. Это всё теории, сейчас достаточно того, что есть для работы и эволюции.