Асикостойкий алгоритм PoW

[kzv]

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

Ну, вы торрентом-то хоть иногда пользовались?
Можно, кстати, для экономии места чуток усложнить алгоритм - организовать блоки по типу raid 5 или 6.

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

Сильно глубоко в детали kademlia или чего-то подобного не втыкал, признаю. На данном этапе обсуждения достаточно эмпирического знания о том, что bittorent и ему подобные сети худо-бедно с задачей "точные копии ... в разных частях света на 100500 нодах" справляются.

Ну если вы не знаете, как устроен торрент, то я вам расскажу.
Торрент это такой файл, в котором записаны хэши нескольких кусков того файла, который передается торрентом.
Что делать, если передаваемый файл все время растет? Правильно: надо все время в торрент добавлять новые хэши... Ой, где-то я уже что-то подобное слышал..? )))

[amaclin1]

На данном этапе обсуждения достаточно эмпирического знания о том, что bittorent
и ему подобные сети худо-бедно с задачей "точные копии ... в разных частях света
на 100500 нодах" справляются.

Сильно сказано. Внушает.

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

[amaclin1]

Ну и на здоровье: как только происходит такой конфликт - обе транзакции объявляются недействительными, а Вася - "недостоверным" участником на сутки. Прикол в том, что всё это делается in real time, т.е., в пределах единиц секунд - а не раз в 10 минут, и то, если повезёт.

Кто их объявляет недействительными?
Обе части сети (Петина часть и Колина часть) живут себе и не знают, что существует
коллизия. Об этом знает только Вася, но ему как раз на это срать с большой колокольни.

[DevilOper]

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

Ну, вы торрентом-то хоть иногда пользовались?
Можно, кстати, для экономии места чуток усложнить алгоритм - организовать блоки по типу raid 5 или 6.

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

Сильно глубоко в детали kademlia или чего-то подобного не втыкал, признаю. На данном этапе обсуждения достаточно эмпирического знания о том, что bittorent и ему подобные сети худо-бедно с задачей "точные копии ... в разных частях света на 100500 нодах" справляются.

Ну если вы не знаете, как устроен торрент, то я вам расскажу.
Торрент это такой файл, в котором записаны хэши нескольких кусков того файла, который передается торрентом.
Что делать, если передаваемый файл все время растет? Правильно: надо все время в торрент добавлять новые хэши... Ой, где-то я уже что-то подобное слышал..? )))

Не, ну чё смеяться-то, на таком уровне и я, конечно, "знаю" - речь-то не об этом, а именно о деталях протокола, ну, например, как там потом ноды по этим хэшам ищутся. А в чём, собственно, проблема с хэшами вообще, а не с именно "красивыми"? От одних и тех же данных он хоть на асике, хоть на калькуляторе (достаточной разрядности) будет одним и тем же.

[kzv]

Не, ну чё смеяться-то, на таком уровне и я, конечно, "знаю" - речь-то не об этом, а именно о деталях протокола, ну, например, как там потом ноды по этим хэшам ищутся. А в чём, собственно, проблема с хэшами вообще, а не с именно "красивыми"? От одних и тех же данных он хоть на асике, хоть на калькуляторе (достаточной разрядности) будет одним и тем же.

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

[DevilOper]

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

А в чём, собственно, принципиальная разница? Вновь присоединившаяся нода - скачивает "точную копию базы" завершённых транзакций. А новые транзакции (записи) - добавляются способом, как я написал выше. Ну, какая-нибудь спецально сделанная нода может, конечно, "забить" на кофликт и продолжить броадкастить в сеть конфликтующие транзакции - в таком случае, её надо тоже банить, вот и всё.

Ну и на здоровье: как только происходит такой конфликт - обе транзакции объявляются недействительными, а Вася - "недостоверным" участником на сутки. Прикол в том, что всё это делается in real time, т.е., в пределах единиц секунд - а не раз в 10 минут, и то, если повезёт.

Кто их объявляет недействительными?

Любая полная нода, обнаружившая этот конфликт.

Обе части сети (Петина часть и Колина часть) живут себе и не знают, что существует
коллизия. Об этом знает только Вася, но ему как раз на это срать с большой колокольни.

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

[DevilOper]

Не, ну чё смеяться-то, на таком уровне и я, конечно, "знаю" - речь-то не об этом, а именно о деталях протокола, ну, например, как там потом ноды по этим хэшам ищутся. А в чём, собственно, проблема с хэшами вообще, а не с именно "красивыми"? От одних и тех же данных он хоть на асике, хоть на калькуляторе (достаточной разрядности) будет одним и тем же.

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

Вы будете таки смеяться, но "хэш" и "блокчейн" - это как Карл Маркс и Фридрих Энгельс, даже не муж и жена.
Обычные банковские транзакции (точнее, транзакционные сообщения - в SWIFT, например) - точно так же хэшируются и подписываются ЭЦП отправителя (и на них таки да, проиходит точно так же подписанное ЭЦП подтверждение получателя) без всякого блокчейна.
А проверить/удостоверить платёжный баланс, например, адреса (кошелька) - есть разные способы, "блокчейн" только один из них.

[kzv]

Вы будете таки смеяться, но "хэш" и "блокчейн" - это как Карл Маркс и Фридрих Энгельс, даже не муж и жена.
Обычные банковские транзакции (точнее, транзакционные сообщения - в SWIFT, например) - точно так же хэшируются и подписываются ЭЦП отправителя (и на них таки да, проиходит точно так же подписанное ЭЦП подтверждение получателя) без всякого блокчейна.
А проверить/удостоверить платёжный баланс, например, адреса (кошелька) - есть разные способы, "блокчейн" только один из них.

Давайте про транзакции вам амаклин будет объяснять, а со мной про способ хранения базы данных поговорим?
Как организовать надежное хранение и синхронное изменение некой базы данных на 100500 узлах? Я предлагаю разбить базу на блоки, каждый блок хэшировать и хранить и передавать хэши вместе с блоками. Ваши предложения какие?

[DevilOper]

Давайте про транзакции вам амаклин будет объяснять, а со мной про способ хранения базы данных поговорим?

Дак, вы сами первый начали, впрочем, как хотите.

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

Дак, торрент вроде так и работает, не? Только хэши вроде там отдельно в DHT лежат, а в чём смысл хэша непременно вместе с блоком, его заново посчитать так сложно...?

[kzv]

Давайте про транзакции вам амаклин будет объяснять, а со мной про способ хранения базы данных поговорим?

Дак, вы сами первый начали, впрочем, как хотите.

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

Дак, торрент вроде так и работает, не? Только хэши вроде там отдельно в DHT лежат, а в чём смысл хэша непременно вместе с блоком, его заново посчитать так сложно...?

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

[DevilOper]

Ну значит договорились: разбиение на блоки и хэширование блоков это хорошо и правильно

Я не очень понимаю, обо что мы спорим.
Транзакция == блок. И 10 (100, 487) транзакций - тоже могут быть блоком.
И даже таблицы в БД могут храниться поблочно.

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

В общем случае - ну, как в том же торренте - порядок [получения/записи] блоков не важен - важен он только в том случае, если мы будем проверять баланс по счёту путём суммирования выходов/вычитания входов транзакций по этому счёту.

[kzv]

Ну значит договорились: разбиение на блоки и хэширование блоков это хорошо и правильно

Я не очень понимаю, об чём мы спорим.
Транзакция == блок. И 10 (100, 487) транзакций - тоже могут быть блоком.
И даже таблицы в БД могут храниться поблочно.

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

В общем случае - ну, как в том же торренте - порядок [получения/записи] блоков не важен - важен он только в том случае, если мы будем проверять баланс по счёту путём суммирования выходов/вычитания входов транзакций по этому счёту.

Ну на примере порнофильма в торренте давайте, что нам какие-то транзакции? ))
Нам ведь важно чтобы кадры в фильме шли правильным порядком, в не как попало? А то получится сначала порево потом прелюдия... Хотя для порно может так и лучше будет )))
Так вот, торренте кроме хэшей кусков есть обязательно информация о том, в какое место файла данный кусок запихнуть. Я не помню точно номер куска там записан или нет, вроде номер. Но на всякий случай с вами советуюсь: нужно номер блока вместе с хэшем  и остальными данными передавать?

[DevilOper]

Ну на примере порнофильма в торренте давайте, что нам какие-то транзакции? ))
Нам ведь важно чтобы кадры в фильме шли правильным порядком, в не как попало? А то получится сначала порево потом прелюдия... Хотя для порно может так и лучше будет )))
Так вот, торренте кроме хэшей кусков есть обязательно информация о том, в какое место файла данный кусок запихнуть. Я не помню точно номер куска там записан или нет, вроде номер. Но на всякий случай с вами советуюсь: нужно номер блока вместе с хэшем  и остальными данными передавать?

Ну, если на примере [порно]фильма - то помимо порядкового номера блока, там ещё "унутри" таймштамп у каждого видеофрейма есть в контейнере. То есть, собрать-то мы его можем в "правильном" порядке - а покажет он в итоге фигню передом на зад.

С другой стороны, допустим, для восстановления цепочки платежей того же Васи нам достаточно блоков 142, 378 и 9532.

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

[kzv]

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

[DevilOper]

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

Ну, насколько я понимаю, в DHT хранится хэш и "адрес" блока, т.е., у кого его искать. Т.е., юморист, конечно, может мне (и другим) вместо блока 500 отдать какую-то херню часть своего своп-файла, например - но я же хэш пересчитаю по получении. А блок этот лежит не у одного этого юмориста -> юморист банится всей сетью в течении считаных минут, если не секунд. А я переклюаюсь на другую ноду, и забираю блок у неё. В торренте, по крайней мере, как-то так, насколько я знаю.

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

[fxpc]

Давайте про транзакции вам амаклин будет объяснять, а со мной про способ хранения базы данных поговорим?
Как организовать надежное хранение и синхронное изменение некой базы данных на 100500 узлах? Я предлагаю разбить базу на блоки, каждый блок хэшировать и хранить и передавать хэши вместе с блоками. Ваши предложения какие?

Тебе для чего? Если речь о распределённой бухгалтерской книге для недоверенного окружения, то всё гораздо тривиальнее и я несколько месяцев назад набросал вполне годную схему, но не забывай чем больше нод, тем выше задержки до наступления консенсуса, поэтому между совершением и подтверждением транзакции придётся ждать. Производительность на глаз 150 TPS на любом пылесосе, думаю можно вытянуть и 300 TPS без особых проблем, требования к дисковому пространству до 75Гб на 1млрд. активных адресов, OTP как в банках, можно проё*ывать приватный ключ без последствий.

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

[kzv]

Ну, насколько я понимаю, в DHT хранится хэш и "адрес" блока, т.е., у кого его искать. Т.е., юморист, конечно, может мне (и другим) вместо блока 500 отдать какую-то херню часть своего своп-файла, например - но я же хэш пересчитаю по получении. А блок этот лежит не у одного этого юмориста -> юморист банится всей сетью в течении считаных минут, если не секунд. А я переклюаюсь на другую ноду, и забираю блок у неё. В торренте, по крайней мере, как-то так, насколько я знаю.

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

Если я ничего не путаю, в DHT хранится только таблица с адресами сидов и вроде таблица хэшей всех файлов (не кусков) для одного узла. Но это к теме не относится...
Ваш алгоритм забанивания работает если у вас перед загрузкой файла есть список хэшей всех кусков этого файла. Правильно?
Давайте подумаем, откуда получить правильные хэши всех кусков в случае если мы никому не доверяем и у нас нет файла .torrent?

Мое предложение:
1. Размещать на интернет форумах и сайтах не файлы .torrent, а только сообщения с названием и хэшем файлов. Придумать этим сообщениям какой-нибудь смешное название... magnet мне нравится например.
2. Написать программу, которая будет при щелчке по ссылке magnet искать в нашей P2P сети узел на котором есть файл с таким хэшем.
3. Когда узел найдем, спросим у него список хэшей для каждого куска.
4. Будем искать и скачивать куски с нужными хэшами в нашей P2P сети.
5. Когда все скачаем и соберем, проверим полученный результат на предмет совпадения с хэшем всего файла.

Как вам такой алгоритм? Есть что дополнить или исправить может быть?

[kzv]

Тебе для чего? Если речь о распределённой бухгалтерской книге для недоверенного окружения, то всё гораздо тривиальнее и я несколько месяцев назад набросал вполне годную схему, но не забывай чем больше нод, тем выше задержки до наступления консенсуса, поэтому между совершением и подтверждением транзакции придётся ждать. Производительность на глаз 150 TPS на любом пылесосе, думаю можно вытянуть и 300 TPS без особых проблем, требования к дисковому пространству до 75Гб на 1млрд. активных адресов, OTP как в банках, можно проё*ывать приватный ключ без последствий.

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

Я не видел того предложения. Можно ссылку? Или может поучаствуете в обсуждении тут?

[DevilOper]

Если я ничего не путаю, в DHT хранится только таблица с адресами сидов и вроде таблица хэшей всех файлов (не кусков) для одного узла. Но это к теме не относится...
Ваш алгоритм забанивания работает если у вас перед загрузкой файла есть список хэшей всех кусков этого файла. Правильно?
Давайте подумаем, откуда получить правильные хэши всех кусков в случае если мы никому не доверяем и у нас нет файла .torrent?

Мое предложение:
1. Размещать на интернет форумах и сайтах не файлы .torrent, а только сообщения с названием и хэшем файлов. Придумать этим сообщениям какой-нибудь смешное название... magnet мне нравится например.
2. Написать программу, которая будет при щелчке по ссылке magnet искать в нашей P2P сети узел на котором есть файл с таким хэшем.
3. Когда узел найдем, спросим у него список хэшей для каждого куска.
4. Будем искать и скачивать куски с нужными хэшами в нашей P2P сети.
5. Когда все скачаем и соберем, проверим полученный результат на предмет совпадения с хэшем всего файла.

Как вам такой алгоритм? Есть что дополнить или исправить может быть?

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

[kzv]

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