Author

Topic: [ARDR] Nxt: Ardor - масштабируемая ChildChain-платформа - page 346. (Read 1749583 times)

sr. member
Activity: 376
Merit: 300
А вот дальше - надо как-то моделировать атаки. Предположим, что аккаунт нехорошего человека имеет Х%. И смотреть, что он может сделать, и получится ли это у него. CfB, ты можешь сформулировать какой-нибудь конкретный сценарий, насчёт чем этот нехороший человек занимается?

Я делал немного по-другому. Разбивал миллиард монет по 100K-10M по рандому, а потом генерировал 1440 блоков считая, что никто не пропустил свой ход (эталон). А дальше я повторно (с того же генезис-блока) генерировал 1440 блоков, но на этот раз с вероятность P кто-то пропускал свой ход. Таким образом получались другие цепочки, которые сравнивались с эталоном по различным параметрам типа кумулятивной сложности или среднего интервала между блоками. Данный подход позволял сэкономить много ресурсов, заменяя полный перебор методом Монте-Карло. Считая, что злоумышленники могут объединить усилия и построить самую оптимальную ветку, я выбирал самый худший для нас вариант.

Понятно. Ты оценивал т.н. вероятности больших уклонений. Но про них известно as a более-менее general fact, что чем больше дисперсия - тем они больше.

Я думаю, всё-таки важно (даже для маркетинга) придумать какой-нибудь реальный сценарий атаки, и просимулировать его.
legendary
Activity: 2142
Merit: 1009
Newbie
А вот дальше - надо как-то моделировать атаки. Предположим, что аккаунт нехорошего человека имеет Х%. И смотреть, что он может сделать, и получится ли это у него. CfB, ты можешь сформулировать какой-нибудь конкретный сценарий, насчёт чем этот нехороший человек занимается?

Я делал немного по-другому. Разбивал миллиард монет по 100K-10M по рандому, а потом генерировал 1440 блоков считая, что никто не пропустил свой ход (эталон). А дальше я повторно (с того же генезис-блока) генерировал 1440 блоков, но на этот раз с вероятность P кто-то пропускал свой ход. Таким образом получались другие цепочки, которые сравнивались с эталоном по различным параметрам типа кумулятивной сложности или среднего интервала между блоками. Данный подход позволял сэкономить много ресурсов, заменяя полный перебор методом Монте-Карло. Считая, что злоумышленники могут объединить усилия и построить самую оптимальную ветку, я выбирал самый худший для нас вариант.
sr. member
Activity: 376
Merit: 300
Как-то всё это просимулировать бы надо, но я не умею   Sad

Тут я не помогу, сейчас все имеющиеся мощности рассчитывают топологию отдельных фрагментов Jinn'а.

А какие мощности нужны?
Это я не знаю. Но могу примерно описать модель. Итак, берём N нод (считаем, что 1 аккаунт на каждой ноде), и распределяем между ними все монетки, как-нибудь примерно по Парето. Можно моделировать "статичную" ситуацию, т.е., трансакций нет. Скажем, N=1000 сойдёт для начала. Далее, моделируем ситуацию что не все ноды онлайн: каждая нода уходит в оффлайн независимо от других, сидит там случайное время, и возвращается. Это нам позволит хорошенько протестировать разные алгоритмы изменения бейзтаргета. Для каждого алгоритма собираем статистику: количество блоков в минуту и их распределение, вес субцепочек из 10, скажем, блоков, и распределение оного, и т.д.  Посмотреть на такие данные, наверное, уже будет полезно.

А вот дальше - надо как-то моделировать атаки. Предположим, что аккаунт нехорошего человека имеет Х%. И смотреть, что он может сделать, и получится ли это у него. CfB, ты можешь сформулировать какой-нибудь конкретный сценарий, насчёт чем этот нехороший человек занимается?
legendary
Activity: 2142
Merit: 1009
Newbie
А какие мощности нужны?

Надо mthcl спрашивать, но, думаю, эквивалентные единицам, если не десяткам, биткоинов.
legendary
Activity: 1005
Merit: 1002
work hard, die young (c)
Как-то всё это просимулировать бы надо, но я не умею   Sad

Тут я не помогу, сейчас все имеющиеся мощности рассчитывают топологию отдельных фрагментов Jinn'а.

А какие мощности нужны?
legendary
Activity: 2142
Merit: 1009
Newbie
Как-то всё это просимулировать бы надо, но я не умею   Sad

Тут я не помогу, сейчас все имеющиеся мощности рассчитывают топологию отдельных фрагментов Jinn'а.
sr. member
Activity: 376
Merit: 300
Это только в том случае, если другие форжеры тоже участвуют в этом празднике жизни. Но если у нас изначально все этим занимаются, то как-бы лучшая возможная ветка уже победила, нет?

Затрудняюсь ответить.
Never mind. Ну, я могу примерно объяснить, почему меньшая дисперсия интервалов (на самом деле, дисперсия BaseTarget-1, но это сравнимые вещи) должна соответствовать большей безопасности, но это всё теория...  Как-то всё это просимулировать бы надо, но я не умею   Sad
legendary
Activity: 2142
Merit: 1009
Newbie
Это только в том случае, если другие форжеры тоже участвуют в этом празднике жизни. Но если у нас изначально все этим занимаются, то как-бы лучшая возможная ветка уже победила, нет?

Затрудняюсь ответить.
sr. member
Activity: 376
Merit: 300
Для биткойна я бы это понял, но для PoS-форжинга это не есть ясно. Имеется в виду, что вот у нас есть легальная ветка до блока N, а нехороший человек хочет создать лучшую по весу ветку от (скажем) N-10 своими собственными силами?

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

Это возможно за счет мультиветвистого форжинга.
Это только в том случае, если другие форжеры тоже участвуют в этом празднике жизни. Но если у нас изначально все этим занимаются, то как-бы лучшая возможная ветка уже победила, нет?
legendary
Activity: 2142
Merit: 1009
Newbie
Для биткойна я бы это понял, но для PoS-форжинга это не есть ясно. Имеется в виду, что вот у нас есть легальная ветка до блока N, а нехороший человек хочет создать лучшую по весу ветку от (скажем) N-10 своими собственными силами?

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

Это возможно за счет мультиветвистого форжинга.
sr. member
Activity: 376
Merit: 300
Хорошо бы определить понятие "безопасность" тогда (чтоб её доказывать).

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

S0.5 = f(Battacker, Bprotector, N) задает 50%-ю вероятность.

PS: Думаю, стоит добавить в параметры среднее время между блоками.
Для биткойна я бы это понял, но для PoS-форжинга это не есть ясно. Имеется в виду, что вот у нас есть легальная ветка до блока N, а нехороший человек хочет создать лучшую по весу ветку от (скажем) N-10 своими собственными силами?

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

legendary
Activity: 2142
Merit: 1009
Newbie
Хорошо бы определить понятие "безопасность" тогда (чтоб её доказывать).

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

S0.5 = f(Battacker, Bprotector, N) задает 50%-ю вероятность.

PS: Думаю, стоит добавить в параметры среднее время между блоками.
sr. member
Activity: 376
Merit: 300
A тогда почему бы наконец не подкрутить алгоритм?

А как его надо подкрутить? Пока не было ни одного предложения с доказательством, что оно улучшит безопасность (не дисперсию интервалов).
Хорошо бы определить понятие "безопасность" тогда (чтоб её доказывать).
legendary
Activity: 2142
Merit: 1009
Newbie
A тогда почему бы наконец не подкрутить алгоритм?

А как его надо подкрутить? Пока не было ни одного предложения с доказательством, что оно улучшит безопасность (не дисперсию интервалов).
sr. member
Activity: 376
Merit: 300

Эммм... это в хорошем смысле?..

Это в плохом смысле.
A тогда почему бы наконец не подкрутить алгоритм?
legendary
Activity: 2142
Merit: 1009
Newbie
A что такое timestampmin?

Это время когда только-только Target выросла настолько, чтобы Hit попал в неё.


Эммм... это в хорошем смысле?..

Это в плохом смысле.
sr. member
Activity: 376
Merit: 300
Можно, кстати, подробнее про "самую последнюю ловушку"?

Как известно, при определенной разнице между текущим временем и временем генерации последнего блока какой-то из аккаунтов может сгенерировать блок. В оригинальной версии NRS разрешалось генерировать блоки с timestamp > timestampmin. Генератор мог это сделать с разбежкой до момента, когда еще кто-то получал такое же право. Этот трюк позволял манипулировать изменениями BaseTarget, снижая безопасность системы за счет уменьшения кумулятивной сложности и увеличения количества степеней свободы при подборе альтернативной ветви с чуть большей сложностью. Сейчас timestamp может быть только равен timestampmin.

A что такое timestampmin?

Кстати, при 120 секундах безопасность практически нулевая, ...
Эммм... это в хорошем смысле?..
sr. member
Activity: 376
Merit: 300
.. самое важное (равно как и самое простое) - запретить бейзтаргету слишком уменьшаться  - поставить ему нижний предел процентов на 70-80, и никаких. Это именно тот момент, где проявляется отличие PoS от PoW: совокупная мощность майнеров может быть сколь угодно большой, тогда как total forging stake ограничено сверху изначальным количеством монет.

- а на это C-f-B ответил здесь:

168->84->42->21->10->5?
Heh, fixing this issue would be very easy - just setting a limit on the lowest possible value. But it was decided to keep it limitless as a reminder that TF is waiting for implementation...
Ну да, это мы уже обсуждали давно и многократно. Но чтобы такое проделать, для начала нужен hard fork.
legendary
Activity: 1792
Merit: 1038
.. самое важное (равно как и самое простое) - запретить бейзтаргету слишком уменьшаться  - поставить ему нижний предел процентов на 70-80, и никаких. Это именно тот момент, где проявляется отличие PoS от PoW: совокупная мощность майнеров может быть сколь угодно большой, тогда как total forging stake ограничено сверху изначальным количеством монет.

- а на это C-f-B ответил здесь:

168->84->42->21->10->5?
Heh, fixing this issue would be very easy - just setting a limit on the lowest possible value. But it was decided to keep it limitless as a reminder that TF is waiting for implementation...
legendary
Activity: 2142
Merit: 1009
Newbie
Можно, кстати, подробнее про "самую последнюю ловушку"?

Как известно, при определенной разнице между текущим временем и временем генерации последнего блока какой-то из аккаунтов может сгенерировать блок. В оригинальной версии NRS разрешалось генерировать блоки с timestamp > timestampmin. Генератор мог это сделать с разбежкой до момента, когда еще кто-то получал такое же право. Этот трюк позволял манипулировать изменениями BaseTarget, снижая безопасность системы за счет уменьшения кумулятивной сложности и увеличения количества степеней свободы при подборе альтернативной ветви с чуть большей сложностью. Сейчас timestamp может быть только равен timestampmin.


Что касается безопасности: а для нынешнего алгоритма есть какие-либо расчёты, насчёт насколько он безопасен?

Математических расчетов нет. В свое время я моделировал разные ситуации и пытался провести атаки. Я заметил, что количество вычислений, требуемых для нахождения более "тяжелой" ветви, значительно уменьшается, если удается поддерживать симметрию колокола (в координатах ИнтервалМеждуБлоками : КоличествоБлоков). Также, вероятность успешной атаки уменьшается, если среднее время стремится к 60 секундам. Кстати, при 120 секундах безопасность практически нулевая, а у нас сейчас примерно 110 секунд между блоками. Отвечая на вопрос насколько безопасен нынешний алгоритм - настолько, насколько форжеры готовы потратиться на multibranch forging. Планировалось, что будет работать Economic Clustering* и благодаря "time warp" время между блоками будет практически всегда 60 секунд, но, видимо, создатель системы слишком оптимистично подошел к оценке процента тех, кто интересуется чем-то еще кроме как возможностью заработать побольше долларов на Nxt'е...

--------
* - На начальном этапе безопасность планировалась быть обеспечена держателями крупных сумм, поэтому у них и остался бонус в виде повышенного шанса на генерацию блоков (нелинейная зависимость от эффективного баланса).
Jump to: