Извините, но я тупой и ничего не понимаю про транзакции. Можете то же самое обьяснить на примере скачивания файла хэш которого не известен?
Я нашел 3 пира которые врут (или не врут) в ответе, что у них есть видео с названием "мамамылараму".
Я спросил у пиров список хэшей для всех кусков файла
Пиры прислали в ответе 3 разных набора хэшей.
Мои действия?
Topic: Асикостойкий алгоритм PoW - page 25. (Read 6250 times)
А я все о торрентах: зачем хэш предыдущего блока спрашиваете? А зачем хэш всего файла понятно?
Вообще говоря, нет. То есть, понятно, конечно же - но это не единственный, да и далеко не лучший вариант.Quote
Вроде уже договорились, что мы хотим быть уверены в том, что качаем файл в описании которого "трах вовы с алиной в кремле на 48 минуте". Убедиться в правильности скачанного можно включив плеер и перемотав на 48 минуту, но если плеер или формат видео не поддерживает перемотку, то можно посчитать хэш файла и сравнить его с хэшем из магнет ссылки...
Все верно?
Тогда если верно то предложите способ, как в каждый момент времени оставаться уверенным в правильности качаемого если хэша всего файла нет и быть не может? Вдруг узел с которого вы качнули первоначальную таблицу хэшей принадлежит рпц и они вместо порнухи всем подключившимся шлют свои проповеди?
Как я уже сказал, нам интересен порядок транзакций лишь в пределах одного счёта. Для этого есть, как ни банально, последовательная нумерация. Ну да, сама транзакция может включать в себя хэш предыдущей транзакции - а может и не включать, можно эту связь вынести на уровень DHT, например. Тогда упомянутый выше Вася может сколько угодно переписывать свои транзакции задним числом - исключительно на своём компе. Все верно?
Тогда если верно то предложите способ, как в каждый момент времени оставаться уверенным в правильности качаемого если хэша всего файла нет и быть не может? Вдруг узел с которого вы качнули первоначальную таблицу хэшей принадлежит рпц и они вместо порнухи всем подключившимся шлют свои проповеди?
А я все о торрентах: зачем хэш предыдущего блока спрашиваете? А зачем хэш всего файла понятно? Вроде уже договорились, что мы хотим быть уверены в том, что качаем файл в описании которого "трах вовы с алиной в кремле на 48 минуте". Убедиться в правильности скачанного можно включив плеер и перемотав на 48 минуту, но если плеер или формат видео не поддерживает перемотку, то можно посчитать хэш файла и сравнить его с хэшем из магнет ссылки...
Все верно?
Тогда если верно то предложите способ, как в каждый момент времени оставаться уверенным в правильности качаемого если хэша всего файла нет и быть не может? Вдруг узел с которого вы качнули первоначальную таблицу хэшей принадлежит рпц и они вместо порнухи всем подключившимся шлют свои проповеди?
Все верно?
Тогда если верно то предложите способ, как в каждый момент времени оставаться уверенным в правильности качаемого если хэша всего файла нет и быть не может? Вдруг узел с которого вы качнули первоначальную таблицу хэшей принадлежит рпц и они вместо порнухи всем подключившимся шлют свои проповеди?
Фикус в том, что в рамках поставленной задачи нам не нужно спасать весь мир упорядочивать
ВЕСЬ "поток" (или "блокчейн", как угодно) - достаточно упорядочить транзакции по каждому счёту/"кошельку".
Ну вообще-то это (как мне кажется) эквивалентные задачи.ВЕСЬ "поток" (или "блокчейн", как угодно) - достаточно упорядочить транзакции по каждому счёту/"кошельку".
То есть имея решение одной - вы получаете и решение второй.
Но вы почему-то упорно не желаете видеть проблемы дабл-спендинга
Когда Вася одновременно со своего счета отправляет транзакцию Пете и публикует её в сеть из Окленда
И в то же самое время отправляет те же самые бабки (условно говоря, не обязательно децентрализованная
система должна являться системой переводов) Коле. Вторую транзакцию Вася публикует из Антверпена
(я выбрал удаленные друг от друга точки). Разумеется, если Васе дать право самому нумеровать свои
транзакции - то обеим он дает одинаковый порядковый номер - он именно и заинтересован в дабл-спендинге.
2. В каждом блоке кроме собственного хэша, номера и времени будем хранить хэш предыдущего блока.
Нравится вам такое решение?
Совет: отвлекитесь от блоков.Нравится вам такое решение?
Не все ли равно - записывать блоки или транзакции или вообще наборы байтов?
С точки зрения програмиста - содержимое/контент вообще не имеет значения.
Просто ради фана пытаюсь по шагам привести оппонента к изобретению блокчейна и PoW
Ну-ну. И как, получается? 2. В каждом блоке кроме собственного хэша, номера и времени будем хранить хэш предыдущего блока.
Нравится вам такое решение?
Совет: отвлекитесь от блоков.Нравится вам такое решение?
Не все ли равно - записывать блоки или транзакции или вообще наборы байтов?
С точки зрения програмиста - содержимое/контент вообще не имеет значения.
Представьте себе что 100500 узлов посылают отдельные транзакции и их надо
записать в некий "поток" в "правильном" (едином для всех нод) порядке, причем
не затратив на это PoW-работу, верно?
Это невозможно. Следствие второго закона термодинамики и Закона неубывания энтропии
Другими словами вы хотите отсортировать массив (уменьшить энтропию)
и ничего не заплатить за это? Это невозможно исходя из сегодняшней физики.
Причем каждая нода - является собственной "замкнутой системой". И любые
несколько нод тоже являются "замкнутой системой"
Вы спросите - а как же в централизованных системах? Да, и там сервер один
раз отсортировывает транзакции. Один раз. А не 100500 раз.
В описанном алгоритме проблем нет и он четко работает на файлах...
Давайте теперь представим, что у нас не файл, а поток видео. У потока есть начало, но нет конца. Хэш всего потока мы значит посчитать не можем, но технология торрентов в принципе нам нравится. Как сохранить алгоритм скачивания торрента не имея хэша всего файла и все равно имея возможность в любой момент убедиться в подлинности скачанного?
Я предлагаю следующее решение:
1. Вместо хэша файла распространять хэш первого блока. Название тоже посмешнее
- генезис мне нравится.
2. В каждом блоке кроме собственного хэша, номера и времени будем хранить хэш предыдущего блока.
Нравится вам такое решение?
Давайте теперь представим, что у нас не файл, а поток видео. У потока есть начало, но нет конца. Хэш всего потока мы значит посчитать не можем, но технология торрентов в принципе нам нравится. Как сохранить алгоритм скачивания торрента не имея хэша всего файла и все равно имея возможность в любой момент убедиться в подлинности скачанного?
Я предлагаю следующее решение:
1. Вместо хэша файла распространять хэш первого блока. Название тоже посмешнее
- генезис мне нравится.
2. В каждом блоке кроме собственного хэша, номера и времени будем хранить хэш предыдущего блока.
Нравится вам такое решение?
Давайте про транзакции вам амаклин будет объяснять, а со мной про способ хранения базы данных поговорим?
Как организовать надежное хранение и синхронное изменение некой базы данных на 100500 узлах? Я предлагаю разбить базу на блоки, каждый блок хэшировать и хранить и передавать хэши вместе с блоками. Ваши предложения какие?
Тебе для чего? Если речь о распределённой бухгалтерской книге для недоверенного окружения, то всё гораздо тривиальнее и я несколько месяцев назад набросал вполне годную схему, но не забывай чем больше нод, тем выше задержки до наступления консенсуса, поэтому между совершением и подтверждением транзакции придётся ждать. Производительность на глаз 150 TPS на любом пылесосе, думаю можно вытянуть и 300 TPS без особых проблем, требования к дисковому пространству до 75Гб на 1млрд. активных адресов, OTP как в банках, можно проё*ывать приватный ключ без последствий.Как организовать надежное хранение и синхронное изменение некой базы данных на 100500 узлах? Я предлагаю разбить базу на блоки, каждый блок хэшировать и хранить и передавать хэши вместе с блоками. Ваши предложения какие?
Если же требуется чтобы все ноды перманентно находились в синхронном состоянии, то это фантастика даже в централизованных системах и я джва года хочу такую
Хорошо. Будем считать, что порядок нужен и значит кроме хэша нужны еще номера и на всякий случай время...
Допустим теперь, что в фильме 1000 блоков. Я подключился к сидерам и начал качать куски. Но какой-то из сидеров оказался юмористрм и поменял блок 500 с самой важной сценой, на совсем другой блок... Хэш, номер и время правильные, а данные другие. Как мне убедиться, что все блоки правильные?
В торренте для этого кроме хэшей блоков, хранится хэш всего файла. Вам нравится такое решение или можете предложить что-то получше?
Допустим теперь, что в фильме 1000 блоков. Я подключился к сидерам и начал качать куски. Но какой-то из сидеров оказался юмористрм и поменял блок 500 с самой важной сценой, на совсем другой блок... Хэш, номер и время правильные, а данные другие. Как мне убедиться, что все блоки правильные?
В торренте для этого кроме хэшей блоков, хранится хэш всего файла. Вам нравится такое решение или можете предложить что-то получше?
Ну значит договорились: разбиение на блоки и хэширование блоков это хорошо и правильно
Я не очень понимаю, обо что мы спорим.Транзакция == блок. И 10 (100, 487) транзакций - тоже могут быть блоком.
И даже таблицы в БД могут храниться поблочно.
Quote
Продолжим.
Если я первый раз качаю к себе базу, валидность блоков я проверю хэшем, но откуда я узнаю где первый блок, где второй и так далее? Предлагаю кроме блоков и их хэшей хранить в базе и передавать друг другу еще номера блоков. Вы не против?
В общем случае - ну, как в том же торренте - порядок [получения/записи] блоков не важен - важен он только в том случае, если мы будем проверять баланс по счёту путём суммирования выходов/вычитания входов транзакций по этому счёту. Если я первый раз качаю к себе базу, валидность блоков я проверю хэшем, но откуда я узнаю где первый блок, где второй и так далее? Предлагаю кроме блоков и их хэшей хранить в базе и передавать друг другу еще номера блоков. Вы не против?
Давайте про транзакции вам амаклин будет объяснять, а со мной про способ хранения базы данных поговорим?
Дак, вы сами первый начали, впрочем, как хотите.Quote
Как организовать надежное хранение и синхронное изменение некой базы данных на 100500 узлах? Я предлагаю разбить базу на блоки, каждый блок хэшировать и хранить и передавать хэши вместе с блоками. Ваши предложения какие?
Дак, торрент вроде так и работает, не? Только хэши вроде там отдельно в DHT лежат, а в чём смысл хэша непременно вместе с блоком, его заново посчитать так сложно...?Ну значит договорились: разбиение на блоки и хэширование блоков это хорошо и правильно ))
Продолжим.
Если я первый раз качаю к себе базу, валидность блоков я проверю хэшем, но откуда я узнаю где первый блок, где второй и так далее? Предлагаю кроме блоков и их хэшей хранить в базе и передавать друг другу еще номера блоков. Вы не против?
Давайте про транзакции вам амаклин будет объяснять, а со мной про способ хранения базы данных поговорим?
Дак, вы сами первый начали, впрочем, как хотите.Quote
Как организовать надежное хранение и синхронное изменение некой базы данных на 100500 узлах? Я предлагаю разбить базу на блоки, каждый блок хэшировать и хранить и передавать хэши вместе с блоками. Ваши предложения какие?
Дак, торрент вроде так и работает, не? Только хэши вроде там отдельно в DHT лежат, а в чём смысл хэша непременно вместе с блоком, его заново посчитать так сложно...? Jump to: