Topic: Большие данные с защитой от подделки (Read 847 times)

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

Когда наступит это будущее? Интересно чем закончилось!

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

Ну я об этом и говорю.

Блокчейн никаким боком не вписывается в эту схему.

Разве что поясню про "на каких основаниях" - тут все просто: основание - это физическая возможность. У меня нет физической возможности записать в базу росреестра что квартира по адресу "третья улица строителей, 25, 12" принадлежит мне. Но где-то есть клерк, который получив договор купли-продажи сделает эту запись.

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

Здесь блокчейн вообще не нужен, все организуется при помощи софта.

Ну как сложно спрогнозировать? Это элементарно, Ватсон!
Кто-то имеющий доступ к редактированию базы запишет в базу число "3", хотя кто-то другой хотел бы, чтобы было записано число "2". Это я вам, естественно, условный пример демонстрирую. Я вот хочу, чтобы из бюджета России на армию выделялось Х денег. А случается какой-нибудь теракт и президент своим росчерком пера цифру меняет, потому как надо это по его мнению.

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

Если смотреть шире, то приходит понимание, что доверие само по себе не эффективно. Уверенность в том, что никто не может исправить данные - дорогого стоит. Если вдруг Вася Пупкин обнаружит в какой-то момент несостыковку в базе, то это может привести к неприятным последствиям. Сложно спрогнозировать, по какой причине может появиться несостыковка. Но если есть возможность избежать любого рода несостыковок, то ее стоит использовать. К тому же твердые гарантии хороши для маркетинга. Чем меньше узких мест тем лучше. А лучше если их вообще нет.

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

Еще в 80-ых годах рулил хеш файла, это было гарантом от изменения, нынешние мошенники пытаются всё привязять к блокчейну все что угодно, даже то, что в этом не нуждается. Глав.цель срубить бабло!

И все-таки я не понимаю зачем вам блокчейн.
Валидатор сам единолично строит базу.
Каждую запись в базе валидатор подписывает своим приватным ключом.
База где-то расположена и у всех есть к ней доступ, может даже платный.
Каждый имеет право и техническую возможность скачать себе любую интересующую его выборку.
Если в какой-то момент Вася Пупкин обнаруживает, что какой-то записи нет в базе, он предъявляет общественности подписанную запись, которую Вася у себя хранил локально и которой нет в оригинальной базе или она конфликтует по смыслу - значит валидатор намухлевал.

Зачем вам блокчейн?

Большое спасибо за ссылку! Вдоль и поперек изучил их сайт и просмотрел выступление создателя. После выступления, зрители задали доктору Bela Gipp вопросы, которые навели меня на новые мысли.

По их продукту:
У них уже есть решение для коммерческого использования с API, dashboard. В принципе можно уже внедрять и тестить.

Минус1: они держат хеши в блокчейне Bitcoin
Минус2: они отправляют данные с хешами с интервалом в 24 часа.

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


Последний - крайний бекап, хеш которого последним был отправлен в блокчейн биткойна
Текущий - тот что будет отправлен в конце дня.

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


Несколькими постами ранее, Neiros дал реф на алгоритм DAG. За что ему тоже спасибо! На основе этого алгоритма построена технололгия Tangle, а на ней монета IOTA. Проект IOTA позиционирует себя, как средство коммуникации устройств в "интернете вещей".

ref
https://ru.wikipedia.org/wiki/Интернет_вещей
https://ru.wikipedia.org/wiki/IOTA_(технология)

Примечательно вот что:

- Транзакции являются бесплатными вне зависимости от их размера
- Время подтверждения транзакций невелико
- Количество одновременно обрабатываемых транзакций не ограничено
- Сама система легко поддается масштабированию
- Нет майнинга

Получается что это решение лишено всех недостатков. Транзакции можно создавать и сразу отправлять в неизменяемый реестр (в Iota не блокчейн, но ключевые характеристики системы схожи и соотвествуют, на мой взгляд, требованиям).
В описании сказано, что в транзакцию можно вложить 2000 символов описания. Мне кажется, что это решение возможно самое удачное. Почему бы не заносить все транзы в свою ноду построенную по принципу IOTA.

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

Это не стыкуется с Вашей постановкой задачи.  И что такое "последний" и "текущий" бэкап?
Кто фальсифицирует данные, бэкап которых еще не сделан?
Но у Вас и так централизованный валидатор. То, что бэкапы держит валидатор, не так страшно. Главное, что он не может уже изменить их. Даже если захочет.

Адрес, блокчейн и правила публикуется валидатором. Это все равно надо сделать, используя какие-то доверенные источники.

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

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

Есть несколько подобных проектов. Работающих.
Например, https://originstamp.org
Конечно, вам надо делать своё, но идею понять не мешает.

Но я сходу вижу тут две заминочки.
1. Что если биткойн закончится? Вот закончится и всё тут? Вы считаете, что это невозможно, в крайнем случае можно перепрыгнуть в другой блокчейн? Ваше право. Я устал спрорить на эту тему. Решайте сами с теми, кто заинтересован в хранении ваших бекапов в неизменности. Я на месте ваших вассалов послал бы вас в пешее эротическое, если вы заикнулись бы о преимуществах такого подхода.
2. Что если валидатор данных просто в какой-то момент заявит, что ему похуй на все ранее сказанное, надо изменить данные, не обязательно лезть в исторические бэкапы, просто запишем в сегодняшний бэкап базы "правильные" сведения и продолжим дальше. Поймите, история базы на самом деле интересна только историкам и аналитикам. Людей интересует "здесь" и "сейчас". В таком случае зачем вам (нам, если представить что я ваш вассал) вообще неизменность исторических данных и блокчейн? Если у валидатора и так полнота власти менять сегодняшний срез данных?

Я и предполагаю фиксировать в блокчейне хеш каждого бекапа (см. первую страницу темы). Инструмент будет сравнивать и сами бекапы и цепочку хешей с той что в блокчейне.


Мне пока не нравятся в этой схеме следующие места:

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

2. Врятли пользователи будут держать у себя наши бекапы. Чтобы обезопасить себя от их утраты, нужно будет поднимать дополнительные сервера для репликации по IPFS. Получается не совсем децентрализованно т.к. основные хранилища будут наши. С первого взгляда, выглядит немного подозрительно.

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

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

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

Аналог атаки 51% - можно подменить все бэкапы, кроме первого. То, что у "Васи" что-то там зафиксировано, для остальных не играет роли. Лично я не смогу проверить целостность всех бэкапов в конкретный момент времени.

В любой момент пересобираем всю цепочку бэкапов. Можем менять количество бэкапов, удаляя или добавляя новые в середину.

Это невозможно без фиксации в блокчейне хэша каждого бэкапа.

Сейчас серверные компы с террабайтом ОЗУ уже не редкость, так что пересчитать хеш одного террабайта, не просто, а очень просто.

Ну и кто мешает сделать систему, где доступ каждого пользователя логгируется, особенно тех, кто делает записи. Это же элементарно и просто.
Ну пересчитывать хеш, можно только тех мест (файлов), где была перезапись. У вас же там, не один файл длинной террабайт (а множество мелких)? Значит надо пересчитывать хеш только тех файлов, где было изменение, причем ПО должно быть настроено таким образом, что бы был лог по пользователям вносящим правки.

Спасибо за ссылки! Я изучаю технологию. Потребуется время, чтобы написать ответ.

Apxu это решил с того, что ты пытаешься прикрутить лохчейн туда где он не требуется, о чём я тебе изначально и написал. Хеш не является 100% гарантией, но это не всегда является проблемой.


О каком опыте речь? Общеизвестный факт - ICO без продвижения соберёт 3 копейки, примеров предостаточно.

Задача очень абстрактно поставлена, а ставить диагноз по фотографии здесь никто не умеет. Нет никакой гарантии что при обязательном участии токенов возможно найти решение для твоего кейса, если возможно, то одно лишь проектирование (не разработка) будет стоить дорого, причём дорого не только для того у кого почти нет денег, но и для того у кого их более чем есть. Твой бюджет расчитан на это? Если нет, то проект провалится ещё на стадии анонса.

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

Как вариант взаимосвязи сюда хорошо вписывается DAG - https://wikiq.ru/blockchain-vs-dag/
Тупо для криптовалют DAG мало перспективен - https://bitcointalksearch.org/topic/m.17483526 (здесь о нём впервые услышал)
Но в совместном применении это возможно может оказаться более перспективным, но тут уже смотря какие большие данные будут использоваться.

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

вот есть у вас бекап номер К , его хеш - ХШ(К).
Есть бекап К+1 и его хеш ХШ(К+1), всё чётко, но в К+1 на самом деле данные уже искажены. Как это обнаружить?
Нужно для каждого шага бекапов провадить полное сравнение и анализ баз на предмет конфликтов и подделок, а данные "большие" и это ОЧЕНЬ дорого, так что никто этим заниматьсе не будет.

Apxu, вы играете словами. С чего вы решили что я верю в мифы о решении всех проблем по средствам блокчейна? Я такого не говорил. Это ваша фантазия. Не более.

Каких всех проблем? Есть одна проблема.

То что знаний у меня в этом вопросе нет, очевидно. Имея знания я бы не просил помощи.

Я предположил что blockchain будет являться железобетонной гарантией того, что данные не были изменены. Использование blockchain не есть обязательное требование. Просто я других не вижу.

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


Очень полезный и ценный комментарий. Вижу что вы уже получили опыт в инвестициях

Обращаюсь к участникам форума

Нужно сделать механизм благодаря которому, пользователи будут уверены в том, что исторические данные не были изменены никем включая владельцев сервиса. Обьем данных - большой. Выше в посте я описал собственные предположения, о том как это можно было бы сделать. Я не уверен что иду в правильном направлении. Не обладая глубокими знаниями в вопросе, прощу о помощи.

Тут есть настоящие специалисты, которые помогут мне решить задачу. С удовольствием заплачу за решение. Если нужен контакт, пишите в личку.

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

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

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

ICO


Есть информация(какой угодно файл бекапа в данном случае), хеш этой информации помещается в место где его нельзя будет исправить - https://www.youtube.com/watch?v=frAqyQoLJXM

Что такое - сумма хешей?

Я возможно не совсем правильно понимаю терминологию. По этому обозначу, что в моей реальности означает "Валидатор". Возможно я выбрал не правильное слово для обозначения того что имею ввиду.
Валидатор - тот узел системы который отвечает за то что данные верны, на момент бекапа. Если не вдаваться в подробности, то валидатор - это и есть сама система. Он централизованный. В текущем моменте ему доверяют.

Компания - это просто название сущности. Сам проект выпустит токен на базе Ethereum (ERC20), который будет использовать в системе для взаиморасчетов между пользователями.

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

Насколько я знаю в биткоин транзы можно вкладывать data. Какую либо информацию. Так-же при создании токенов на базе Ethereum можно дополнить их информацией.


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



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

Возможно лучше нарисовать схему для лучшего визуального восприятия? Что думаете?

Бред какой-то. Вы насыпали кучу новых терминов. Раньше у вас был валидатор. Теперь появилась "компания" у которой есть "публичный токен" (кстати, что это такое и чем он отличается от непубличного?). Как в токен вкладывать хэш? Что такое "доверительное место"? И почему, черт возьми, это что-то должно исключить?

Целостность базы мы не подвергаем сомнениям. Вопрос в единственности. Сегодня "Спартак" выиграл у "Динамо", но валидатор создал две базы, отличающиеся тем, что в фальсифицированной базе наоборот "Динамо" выиграло. Прошло три года. Как мне определить результат матча, если валидатор лично мне дает фальшивый бэкап?

Он у вас генно-модифицированный или бессмертный идиот? Как вы себе представляете работу такого валидатора?

fxpc, apxu, ollsanek, спасибо за участие в решение задачи!

Вернусь в начало и перефразирую задачку.

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

Уверенность должна быть в:

• Никто не может исправить результаты по прошлым контрактам даже путем взлома
  
• Никто не может добавить нового пользователя в прошлое и провести его в настоящее создав ему нужную историю (создать успешного исполнителя).
  

В теории все можно подделать, но сравнение бекапов баз данных сразу выявит нарушения (несоответствия).

1. В системе все доверяют валидатору
2. Валидатор делает публичный бекап базы данных раз в сутки
3. Каждый может провести сравнение бекапов с помощью открытого инструмента


Очень правильный вопрос. Действительно, можно вести сколько угодно баз.

Что можно с этим сделать:

1. Сделать подмену бекапов начиная с определенного момента в прошлом до текущего дня.
2. Сделать подмену всех бекапов, кроме первого, до текущего дня (считай заменить все, т.к первый ранний бекап может быть практически пустым и ни на что влиять).

Кто это заметит?
Те кто скачивали бекапы и фиксировали их хеши у себя. Они увидят что с определенного момента хеши перестали совпадать.

Будет ли кто-то этим заниматься?
Не думаю. По этому тот кейс о котором ты говоришь вполне прокатит.


Что можно сделать:

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

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

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

Сделать кошелек неизменным
Вложить его номер так-же в публичный токен компании. Тогда будет уверенность в том что именно эта история хешей верна.

При этой схеме, зачем валидатору ключ?
Какие возможности взлома или узкие места вы видите?


Да, сам валидатор не заинтересован в мошенничестве. Задача сделать механизм, который позволит это не доказывать.

Как неоспоримый факт: Здесь все данные верны. Никто в этом не сомневается. Открытую бд может проверить любой. Она никогда не была изменена.


Почему не круто?
Какие недостатки?

Если бекапы никто не скачает?

Пока у меня такие вопросы:
1. Что думаете о точке доверия?
2. Видите ли вы в моей схеме узкие места?
3. Как защитить бекапы от взлома?

1. клади в биткоин
2. перезаливать всю базу - некруто, надо чтоб была возможность скачивать/проверять только изменения. Но этот способ тоже имеет недостатки. Всегда компромис, который можно решить только зная все детали задачи.
3. ээээ ну клади в точку доверия кроме хеша ещё и ссылки на базу в нескольких р2р сетях .....

Ты сам зачем-то приплёл реестр к лохчейну и спрашиваешь зачем он там нужен. Топик про p2p синхронизацию БД на основе централизованного консенсуса.

При расхождении реестра с правоустанавливающими документами руководствуются решением суда. Реестр используется чтобы свести частоту расхождений к минимуму.

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

Ибо если блокчейн является дубликатом документов - зачем он нужен? При расхождении сведений между оригиналом и дубликатом чем мы будем руководствоваться? А если и пока сведения не расходятся - зачем вам блокчейн?

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

Почему не согласятся? Практика создания форков биткойна как раз говорит, что была бы выгода или иллюзия выгоды, а за последователями дело не заржавеет. Пример: допустим у нас база данных по недвижимости - кому в стране какой дом принадлежит. С учетом всех продаж и покупок мы эту базу дополняем каждый день. Первого января 2020 года валидатор выбирает 20% самых ненужных на его взгляд членов общества: пьяниц, алкоголиков, тунеядцев и их имущество перераспределяет всем остальным. Вам лично тоже что-то с этого перепадает. Откажетесь? Да не вопрос! Другим больше достанется!

Если после валидации внести правки в данные за прошедшие сутки, а потом выложить хеш, то сойдётся, плюс коллизии.


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

В биткоине недоверенное окружение, а у него доверенное, в котором все доверяют валидатору.

Что помешает валидатору вести две базы одновременно? Одна типа честная, другая (или другие) имеют иное содержимое, но во всем остальном подписаны так же и теми же ключами? Первую запись в базе можно и прежней оставить в принципе. Это роли не играет. Фальсификацию можно вообще с любого места начинать.

В 2019 году все улыбаются и машут. А в ночь на 1 января 2020 валидатор раздает другую базу своим прикормленным вассалам. Да, кто-то может предъявить публике первую базу, но публике вторая база может оказаться выгоднее, поэтому крикунов заткнут на раз.

Поясняю: недопущение этой ситуации в биткойне достигается на какое-то время (уже на 10 лет) майнингом. В вашей системе есть майнинг? Если да, то кто оплачивает банкет электрикам?

Не "может не сойтись", а не сойдется. Насколько я это понимаю. Это и будет являться доказательством фальсификации.

1. Если валидатор выложит бекап базы где были подправлены исторические данные, то инструмент покажет несоответствия в данных с прошлыми бекапами.
2. Если валидатор захочет изменить любой исторический бекап - то хеш суммы хешей в следующих бекапах будет неверный.
3. Если валидатор захочет изменить перезалить все бекапы - то первый хеш не будет совпадать.

Я пока не вижу вариантов возможной фальсификации при таком раскладе. Даже с учетом централизации при валидации каждого нового бекапа.

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

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

Что вы имеете ввиду под "раздать остальным"? Как вы видите этот процесс?

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

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

С IPFS я не правильно выразился. Предполагаю сделать несколько серверов для репликации бекапов. Я понимаю что если бекапы никто не скачает и все сервера по какой-то причине лягут, то пользователи не смогут иметь доступ к бекапам.

Как вы видите идеальную схему работы для решения этой задачи?

Спасибо!

Идея бессмысленная, как практически, так и теориетически. Что-то вроде запихивания в багажник лошади для того, чтобы авто ехало быстрее. БД кто валидирует? Насколько я понял, валидация происходит централизованно, следовательно вполне достаточно подписать приватным ключом хеш текущей версии и раздать остальным. Зачем здесь лохчеин? Кстати, выложить что-то в IPFS невозможно, это не хранилище, а оверлейная сеть, данные лежат у того у кого они есть, в твоём случае изначально только у валидатора и если он ляжет до того как их кто-то скачает, то клиенты останутся без базы.

Привет, друзья!

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

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

Я изучил текущие решения и выбрал для себя IPFS + любой оптимальный блокчейн для подтверждения.

Хочу реализовать по следующей схеме.

Хранение данных

• Ежедневно база данных выкладывается в IPFS
• Хеш нового файла бекапа вписывается в каждый следующий бекап
• Сумма хешей всех предыдущих файлов бекапов вписывается в каждый файл бекапа кроме первого и второго

Валидация данных

• База данных не зашифрована
• Реализую открытый инструмент, который будет сравнивать записи в бд на сходство и показывать, что исторические данные в каждом бекапе совпадают
• Инструмент выложу на github

Точка доверия
Для того чтобы исключить возможность подделки всех файлов бекапа, зафиксирую хеш первого файла бекапа в месте где его нельзя будет исправить. Дата создания первого бекапа и его хеш будут совпадать с данными из опубликованной записи. По идее этого достаточно чтобы не было сомнений. Предполагаю создать транзакцию в одном из уже существующих блокчейнов: bitcoin, ethereum c официального кошелька компании. Или использовать этот хеш в токенах, которые будут выпущены проектом и разданы его пользователям.

Пока у меня такие вопросы:
1. Что думаете о точке доверия?
2. Видите ли вы в моей схеме узкие места?
3. Как защитить бекапы от взлома?

P.S. База бекапится ежедневно и теоритически возможность подделки есть только в промежутке времени между последним и предстоящим бекапами. В моем случае это не проблема.

Спасибо за внимание! Буду рад обратной связи!