Мне порой кажется, что пропадают неугодные комментарии)) Ну да ладно, повторим)))
у нас проблема с синхронизацией, и количество нод ее только усугубляет)
Это пять, полная децентрализация))))) Есси так, то ппц, надо срочно чинить ядро...
Ну или оставить одну надёжную ноду, чтоб ей не с кем было рассинхрон устраивать;)))
_cr.jpg)
смейся смейся, но ты вкурсе что наша сеть выдержит определенное количество одновременнно работающих нод?)
Так что вместо выстебывания, убедился бы что прав)
насколько мне не изменяет память, кто-то говаривал что в текущей архитектуре сеть потянет теоритически до 500 одновременно работающих нод, но скорее всего не более 200 на практике)
@t3ran13 Совершенно верно. И это проблема не протокола, а, скорее, фундаментальные недостатки архитектуры демона, фундаментальные физические ограничения и отсутствие более сложного роутинга и сетевого консенсуса, чем "Флуд все всем".
На практике при хорошем сетевом канале и текущих параметрах протокола, при полном графе топологии тестовой сети (что порождает сильную зашумленность) я выбивал около 380-ти нод. Однако, надо понимать, что граф топологии сети далеко не всегда полный (я бы сказал, его полнота - вырожденный случай), а это значит, что сеть способна выдержать столько нод, сколько потребуется при условии расчетливого построения графа сети сообществом.
Решение с автоматизированным технологическим и экономическим решением проблемы роутинга я представлю в рамках другого проекта, на который предположительно (только предположительно) перейдет Голос. Но подробней об этом чуть позже.
при росте размера блока, и при наличии постоянной скорости передачи данных между нодами, скорость синхронизации увы, будет падать) данные у нас пока со скоростью света, увы, не передаются) да и то,при наличии достаточного числа нод, даже скорость света не поможет)
в целом решения этой проблемы не существует, огрничено все фундаментальной физикой, поскольку данные передаются с конечной скоростью.
НО, оптимизировать некоторые вещи и ускориться - несомненно можно)
Та же архивация блоков даст знатный прирост в скорости синхронизации, поскольку данных будет передаваться меньше)
Так я ж архитектурных подробностей не знаю, вот как раз и появляются из диалога;) Знаю в битке 100500 тыщ нод, и всё пашет децентрализовано. В ефире тож нод мильёны, нет ограничений.
А на голосе рассинхрон на паре сотен нод выглядит странно, и смех и грех... Какая ж это децентрализация?;))
И на стимит так же? Там жеж объёмы на порядок выше, знач не должно быть так
@t3ran13, ну да, из лесу)) Внутренности крипты - штука непростая, чтоб так сразу въехать;)) Вот разобраться и пытаюсь.
Мне этот графен неведом. Хотя про затык из-за 3-секунд улавливаю. На сайте битшарес доки хотелось почитать, но мутно чего-то. Может подскажешь, где есть инфа понятная?
@nemo1369, спасиб, читаю ответ терану, проясняется немного. То есть в этом графене не решается задача построения оптимальной топологии, и это на усмотрение реализации демона?
ты как из леса вышел. сколько транзакций в стиме(у нас) и сколько на в эфире или битке? эфиру и битку как до луны такие показатели. Да и времени что у битка, что у эфира между блоками море, на фоне того же графена) потому да, чб распространить блок по сети - нужно время)
сам бы мог сообразить еслиб подумал
@html Ограничение на количество нод очень динамичное и на практике, на боевой сети, достигается очень сложно. В тестовом окружении - пожалуйста, на практике, на боевой сети при наших/Steemit размерах очень сложно.
Вот полностью согласен.
Все публичные блокчейны стараются максимально увеличить количество активных нод, так как это увеличивает безопасность и производительность сети.
@primus Распараллеливание API, и вообще, смена механизма многопоточности на лучшие практики индустрии (взамен доставшейся из Graphene безграмотной самоделки), поможет ускорить обработки входящих транзакций и вызовов API, что по большей части решит проблемы с недоступностью API при высокой нагрузке на демона. На протокол это никак не повлияет.
безопасность да, но производительность как? у анс что, параллельное подписание блоков?
вообще я говорил об этом
https://golos.id/ru--golos/@html/re-t3ran13-re-primus-o-maininge-golosa-zamovlyu-slovo-3-prichiny-pochemu-pow-sleduet-ostavit-na-golose-i-pochemu-reshenie-o-maininge-ne-dolzhno-vlyat-20171202t134825780z#@t3ran13/re-html-re-t3ran13-re-primus-o-maininge-golosa-zamovlyu-slovo-3-prichiny-pochemu-pow-sleduet-ostavit-na-golose-i-pochemu-reshenie-o-maininge-ne-dolzhno-vlyat-20171202t142654819z
По поводу производительности это вопрос к @goloscore, @kotbegemot и @nemo1369.
В их презентации как раз есть слайд, что они работают над распараллеливанием обработки API вызовов. Чтобы кошечки не по-очереди ели из миски, а все сразу.
Не уверен, как это влияет на взаимодействие нод между собой. Но, насколько я помню, в graphene количество активных нод напрямую влияет на производительность всей сети в целом. Т.е., одной/двух/десяти нод не хватит, чтобы достичь теоретической производительности блокчейна в 10-20,000 транзакций в секунду.
Конечно, Голосу пока рано до такой производительности, но в перспективе на будущее - почему не иметь дополнительный стимул в виде PoW в дополнение к DPoS?
Я вот вообще не понимаю - чем PoW может мешать?
По сути, даже PoW майнеры подписывают блоки на DPoS основе. Там же двух-факторная очередь, а не как в биткоине и других блокчейнах.
Нахождение PoW блока лишь ставит делегата-майнера в очередь на подписание блока. Сейчас длина этой очереди около 3-х часов. И только через это время майнер получает своё место в очереди подписать блок как обычный делегат и всё это время его нода должна быть рабочей.
Чем плохо-то?