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 (здесь о нём впервые услышал)
Но в совместном применении это возможно может оказаться более перспективным, но тут уже смотря какие большие данные будут использоваться.