Pages:
Author

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

newbie
Activity: 17
Merit: 0
Quote
Quote from: ollsanek
2. перезаливать всю базу - некруто, надо чтоб была возможность скачивать/проверять только изменения. Но этот способ тоже имеет недостатки. Всегда компромис, который можно решить только зная все детали задачи.

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

вот есть у вас бекап номер К , его хеш - ХШ(К).
Есть бекап К+1 и его хеш ХШ(К+1), всё чётко, но в К+1 на самом деле данные уже искажены. Как это обнаружить?
Нужно для каждого шага бекапов провадить полное сравнение и анализ баз на предмет конфликтов и подделок, а данные "большие" и это ОЧЕНЬ дорого, так что никто этим заниматьсе не будет.
jr. member
Activity: 52
Merit: 10
Quote
Возможно лучше нарисовать схему для лучшего визуального восприятия? Что думаете?
Я думаю, что у вас ничего не получится хоть со схемой, хоть без нее. Знаний материала у вас с гулькин хуй, а мифам о том что блокчейн является решением всех проблем вы верите. Мифы для того и распространяют.

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

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

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

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

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

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

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

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

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

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

Тут есть настоящие специалисты, которые помогут мне решить задачу. С удовольствием заплачу за решение. Если нужен контакт, пишите в личку.
sr. member
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
Quote
Возможно лучше нарисовать схему для лучшего визуального восприятия? Что думаете?
Я думаю, что у вас ничего не получится хоть со схемой, хоть без нее. Знаний материала у вас с гулькин хуй, а мифам о том что блокчейн является решением всех проблем вы верите. Мифы для того и распространяют.

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

Согласен, очередная попытка ввернуть лохчейн туда где он нахуй не нужен, чтобы развести влошенцев на бабло. Потенциально прибыльных идей как грязи, делай и зарабатывай, но не модно без лохчейна и ICO на продвижение которого потребуется чемодан денег, а его наверняка нихуя нет.
member
Activity: 980
Merit: 48
member
Activity: 229
Merit: 13
Quote
Возможно лучше нарисовать схему для лучшего визуального восприятия? Что думаете?
Я думаю, что у вас ничего не получится хоть со схемой, хоть без нее. Знаний материала у вас с гулькин хуй, а мифам о том что блокчейн является решением всех проблем вы верите. Мифы для того и распространяют.

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

ICO Grin

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

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

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

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

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

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

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

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

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


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

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

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

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

Quote
валидатор не заинтересован в мошенничестве.
Он у вас генно-модифицированный или бессмертный идиот? Как вы себе представляете работу такого валидатора?
jr. member
Activity: 52
Merit: 10
fxpc, apxu, ollsanek, спасибо за участие в решение задачи!

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Quote from: ollsanek
2. перезаливать всю базу - некруто, надо чтоб была возможность скачивать/проверять только изменения. Но этот способ тоже имеет недостатки. Всегда компромис, который можно решить только зная все детали задачи.

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

Quote from: ollsanek
ээээHuh ну клади в точку доверия кроме хеша ещё и ссылки на базу в нескольких р2р сетях .....
Если бекапы никто не скачает?
newbie
Activity: 17
Merit: 0
Пока у меня такие вопросы:
1. Что думаете о точке доверия?
2. Видите ли вы в моей схеме узкие места?
3. Как защитить бекапы от взлома?

1. клади в биткоин
2. перезаливать всю базу - некруто, надо чтоб была возможность скачивать/проверять только изменения. Но этот способ тоже имеет недостатки. Всегда компромис, который можно решить только зная все детали задачи.
3. ээээHuh ну клади в точку доверия кроме хеша ещё и ссылки на базу в нескольких р2р сетях .....
sr. member
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
Quote
Права зафиксированы в правоустанавливающих документах, а реестр это всего лишь дубликат.
Вопрос был о том - может ли блокчейн заменить собой правоустанавливающие документы, обычную базу данных росреестра или какой-то там кадастровой палаты мер и весов.

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

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

При расхождении реестра с правоустанавливающими документами руководствуются решением суда. Реестр используется чтобы свести частоту расхождений к минимуму.
member
Activity: 229
Merit: 13
Quote
Права зафиксированы в правоустанавливающих документах, а реестр это всего лишь дубликат.
Вопрос был о том - может ли блокчейн заменить собой правоустанавливающие документы, обычную базу данных росреестра или какой-то там кадастровой палаты мер и весов.

Ибо если блокчейн является дубликатом документов - зачем он нужен? При расхождении сведений между оригиналом и дубликатом чем мы будем руководствоваться? А если и пока сведения не расходятся - зачем вам блокчейн?
sr. member
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
Quote
Вести ничего не помешает, но вассалы не согласятся с такой подменой
Почему не согласятся? Практика создания форков биткойна как раз говорит, что была бы выгода или иллюзия выгоды, а за последователями дело не заржавеет. Пример: допустим у нас база данных по недвижимости - кому в стране какой дом принадлежит. С учетом всех продаж и покупок мы эту базу дополняем каждый день. Первого января 2020 года валидатор выбирает 20% самых ненужных на его взгляд членов общества: пьяниц, алкоголиков, тунеядцев и их имущество перераспределяет всем остальным. Вам лично тоже что-то с этого перепадает. Откажетесь? Да не вопрос! Другим больше достанется!

Потому что у него централизованная система где все доверяют валидатору. Если консенсус утрачен, значит валидатор решил сам себе выстрелить в ногу или взломан. Про реестр полный бред. Права зафиксированы в правоустанавливающих документах, а реестр это всего лишь дубликат. Если государство на эти документы положит хуй, то совершенно не важно что написано в реестре и существует ли он вообще. Делиться отжатым имуществом с тобой никто не будет и повлиять на это ты никак не сможешь.
member
Activity: 229
Merit: 13
Quote
Вести ничего не помешает, но вассалы не согласятся с такой подменой
Почему не согласятся? Практика создания форков биткойна как раз говорит, что была бы выгода или иллюзия выгоды, а за последователями дело не заржавеет. Пример: допустим у нас база данных по недвижимости - кому в стране какой дом принадлежит. С учетом всех продаж и покупок мы эту базу дополняем каждый день. Первого января 2020 года валидатор выбирает 20% самых ненужных на его взгляд членов общества: пьяниц, алкоголиков, тунеядцев и их имущество перераспределяет всем остальным. Вам лично тоже что-то с этого перепадает. Откажетесь? Да не вопрос! Другим больше достанется!
sr. member
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
Quote from: fxpc
Если он выложит хеш подправленной БД, то всем придётся использовать её, централизация же, но с прошлыми бэкапами конечно может не сойтись.

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

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

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

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

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

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

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

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

Поясняю: недопущение этой ситуации в биткойне достигается на какое-то время (уже на 10 лет) майнингом. В вашей системе есть майнинг? Если да, то кто оплачивает банкет электрикам?
jr. member
Activity: 52
Merit: 10
Quote from: fxpc
Если он выложит хеш подправленной БД, то всем придётся использовать её, централизация же, но с прошлыми бэкапами конечно может не сойтись.

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

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

Я пока не вижу вариантов возможной фальсификации при таком раскладе. Даже с учетом централизации при валидации каждого нового бекапа.
sr. member
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
jr. member
Activity: 52
Merit: 10
Идея бессмысленная, как практически, так и теориетически. Что-то вроде запихивания в багажник лошади для того, чтобы авто ехало быстрее. БД кто валидирует? Насколько я понял, валидация происходит централизованно, следовательно вполне достаточно подписать приватным ключом хеш текущей версии и раздать остальным. Зачем здесь лохчеин? Кстати, выложить что-то в IPFS невозможно, это не хранилище, а оверлейная сеть, данные лежат у того у кого они есть, в твоём случае изначально только у валидатора и если он ляжет до того как их кто-то скачает, то клиенты останутся без базы.

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

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

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

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

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

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

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

Спасибо!
sr. member
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
Идея бессмысленная, как практически, так и теориетически. Что-то вроде запихивания в багажник лошади для того, чтобы авто ехало быстрее. БД кто валидирует? Насколько я понял, валидация происходит централизованно, следовательно вполне достаточно подписать приватным ключом хеш текущей версии и раздать остальным. Зачем здесь лохчеин? Кстати, выложить что-то в IPFS невозможно, это не хранилище, а оверлейная сеть, данные лежат у того у кого они есть, в твоём случае изначально только у валидатора и если он ляжет до того как их кто-то скачает, то клиенты останутся без базы.
Pages:
Jump to: