SP
@s_tikhomirov выглядит так, будто об этом можно выпуск записать с разбором
Size: a a a
2019 December 13
KP
Тут даже допущения "все майнеры сговорились" недостаточно
AP
сервер за 100 евро в месяц - нормально все запускается
Есть очень большая разница между dedicated servers & shared VM server в производительности. чем выше нагрузка на ноду тем существенне разницы и задержки обработке.
DK
Есть очень большая разница между dedicated servers & shared VM server в производительности. чем выше нагрузка на ноду тем существенне разницы и задержки обработке.
отдельный сервер конечно же
KP
Тут даже допущения "все майнеры сговорились" недостаточно
Надо "все майнеры И все полные ноды сети сговорились, и ещё потратили хешрейта за 10К блоков, и сделали это незаметно для сторонних наблюдателей".
Кажется, что с такими допущениями проще просто сеть форкнуть в irregular state transfer
Кажется, что с такими допущениями проще просто сеть форкнуть в irregular state transfer
KP
Надо "все майнеры И все полные ноды сети сговорились, и ещё потратили хешрейта за 10К блоков, и сделали это незаметно для сторонних наблюдателей".
Кажется, что с такими допущениями проще просто сеть форкнуть в irregular state transfer
Кажется, что с такими допущениями проще просто сеть форкнуть в irregular state transfer
Там всё то же самое, только не надо майнить две цепочки параллельно
KP
Что сильно дешевле
o
А как? Опиши атаку?
1. до блока #110000 генерируем стейт и блоки такими как мы его хотим видеть.
2. делаем атаку 51% на эфир на нужное количество блоков.
3. сибил атака на сеть с подменой стейта
2. делаем атаку 51% на эфир на нужное количество блоков.
3. сибил атака на сеть с подменой стейта
AS
Тут даже допущения "все майнеры сговорились" недостаточно
Тут нужны очень сложные асампашены конечно.
Вопрос - почему было принято решение не включать валидацию стейта до дженеса в фоне, если мы синхронизировались и знаем последний стейт но хотим убедится в его корректности?
Вопрос - почему было принято решение не включать валидацию стейта до дженеса в фоне, если мы синхронизировались и знаем последний стейт но хотим убедится в его корректности?
AS
В смысле на скорость синка ноды это не повлияет
AS
Разве что будет что-то лопатить на фоне первые пару недель работы ноды
AP
Следующий момент не нужно забывать что размер блокчейна на диске это база данных
- при увеличении количетсва транзакций и размера самого блокчена,
экспоненциально o(n^2) снижается проивзодительность, в количество поисков наростает... искать 100 записей в 100.000 базе , и 1500 записей в минуту в 10.000.000 базе совсем не тоже самое... так что тут не просто тупо размер диска.
- при увеличении количетсва транзакций и размера самого блокчена,
экспоненциально o(n^2) снижается проивзодительность, в количество поисков наростает... искать 100 записей в 100.000 базе , и 1500 записей в минуту в 10.000.000 базе совсем не тоже самое... так что тут не просто тупо размер диска.
KP
Тут нужны очень сложные асампашены конечно.
Вопрос - почему было принято решение не включать валидацию стейта до дженеса в фоне, если мы синхронизировались и знаем последний стейт но хотим убедится в его корректности?
Вопрос - почему было принято решение не включать валидацию стейта до дженеса в фоне, если мы синхронизировались и знаем последний стейт но хотим убедится в его корректности?
Потому что тем, кому надо, можно просто указать флаг
А для абсолютного большинства применений указанные допущения сильно превосходят их требования безопасности.
Вот и выходит что в переусложнённом механизме нету нужды.
--no-warp (или, как промежуточный вариант, поставить warp-barrier подальше).А для абсолютного большинства применений указанные допущения сильно превосходят их требования безопасности.
Вот и выходит что в переусложнённом механизме нету нужды.
AP
1. до блока #110000 генерируем стейт и блоки такими как мы его хотим видеть.
2. делаем атаку 51% на эфир на нужное количество блоков.
3. сибил атака на сеть с подменой стейта
2. делаем атаку 51% на эфир на нужное количество блоков.
3. сибил атака на сеть с подменой стейта
Каждый раз когда читаю теорию типа делаем 51% процент атаку... майним паралельно две сети 10.000 блоков... прям понимая как много теоретиков, и какой это разрыв от практики....
KP
1. до блока #110000 генерируем стейт и блоки такими как мы его хотим видеть.
2. делаем атаку 51% на эфир на нужное количество блоков.
3. сибил атака на сеть с подменой стейта
2. делаем атаку 51% на эфир на нужное количество блоков.
3. сибил атака на сеть с подменой стейта
А как мы до узла доносим именно наши 110000 первые блоков?
Они же не с варп-узла берутся, а просто "из сети"
Они же не с варп-узла берутся, а просто "из сети"
AP
чтобы паралельно майнить две ветки с тойже скоростью не теряя hashrate - нужно развернуть в 2 раза больше мощностей, что далеко не тривиальная задача и занимает месяцв упорной работы по 18-20 часов в сутки.
AP
Это крайняя теория... один процесс делает один поиск... поделите вашу скосроть на размер базы данных блокчейна, и потом еще раз поделите на количество запросов/транзакций в минуту, вот тогда вы получите с гулькин нос убывающую производиельность.
o
Каждый раз когда читаю теорию типа делаем 51% процент атаку... майним паралельно две сети 10.000 блоков... прям понимая как много теоретиков, и какой это разрыв от практики....
я согласен это ОЧЕНЬ сложно.
Но тут есть ключевое отличие от атаки на биткоин.
в случае атаки на биткоин я могу откатить только те транзакции которые производились ПОСЛЕ начала атаки. Что очень сужает количество способов извлечение прибыли от атаки.
Здесь же получается что я могу исказить нужным мне образом ВСЮ историю.
А это уже совсем другой спектр возможностей.
Но тут есть ключевое отличие от атаки на биткоин.
в случае атаки на биткоин я могу откатить только те транзакции которые производились ПОСЛЕ начала атаки. Что очень сужает количество способов извлечение прибыли от атаки.
Здесь же получается что я могу исказить нужным мне образом ВСЮ историю.
А это уже совсем другой спектр возможностей.
o
А как мы до узла доносим именно наши 110000 первые блоков?
Они же не с варп-узла берутся, а просто "из сети"
Они же не с варп-узла берутся, а просто "из сети"
пункт 3 - сибил атака на сеть
AP
3Tb HDD стоят 83$ с бесплатной доставкой.
Ну да, жители Зимбабве вряд ли могут себе позволить
Ну да, жители Зимбабве вряд ли могут себе позволить
Странно и почему это на хостинге люди ставят не дешевый 3TB в сервер, а дисковые массивы где теже 3TB собираются из кеша, SSD/SAS - и 10 дисков чтобы получить всего в 4-5 раз большую пропускную, но в разы более высокий IOPS.