Большие данные с защитой от подделки

[ollsanek]

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

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

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

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

[neiros]

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

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

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

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

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

[fxpc]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Frankwood]

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

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

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

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

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

[#Cryptoman]

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

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

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

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

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

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

[Xtc]

2. Видите ли вы в моей схеме узкие места?

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

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

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

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

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

[GGUL]

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

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

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

[Frankwood]

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

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

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

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

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

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

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

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

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

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

[apxu]

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

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

[GGUL]

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

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

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

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

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

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

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

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

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

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

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

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

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

[Frankwood]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[apxu]

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

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

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

[#Cryptoman]

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

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

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

[Frankwood]

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

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

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

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

[apxu]

Сложно спрогнозировать, по какой причине может появиться несостыковка.

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

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

[#Cryptoman]

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

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

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

[apxu]

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

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

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

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

[fxpc]

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

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

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

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

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

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

Блажен кто верует.

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

https://aakilfernandes.github.io/whats-wrong-with-iota

Итого, централизованный шиткоин со 100% премайном, лохчейном без блоков, ложными заявлениями и умышленно оставленным бэкдором (мейнтейнер в этом сам признался). Какое отношение это имеет к бигдате?

[Frankwood]

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

[Blagotvori.tel]

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

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