$DUSK Я на практике прогнал через себя немало узлов, и главное, что обычно доводит до тряски, — это не то, что объём транзакций резко растёт, а то, что на уровне P2P начинается безумная рассылка и наступает настоящая катастрофа с широковещанием. Старая монолитная public chain едва пошевелится — и всё сразу подвисает: беда в той самой устаревшей Gossip-схеме. Она бездумно шлёт сообщения всем подряд; как только сеть хоть немного начинает «дергаться», повторяющиеся потери пакетов тут же запускают лавину — серверную память можно на месте «убить».
Потом я копнул базовый уровень у @Dusk и выяснил, что там в архитектуре Kadcast сделаны кое-какие хитрые ходы. Проект не пошёл по пути старого «залить всё водой»: вместо этого он прямо с помощью алгоритма XOR рисует сеть направленной раздачи. Каждое устройство занимается только своей небольшой зоной, где и проталкивает нужные данные; а с самого источника весь этот беспорядочный массовый спам загоняется в фиксированные линии. Даже если поток транзакций мгновенно взлетит, «мусорная» периферийная тараканья дичь всё равно будет удержана.
Но судя по тем граблям, на которые я наступал, как бы ни были чудесны на бумаге схемы разгрузки, в реальном машинном зале всё равно придётся пойти на компромиссы. Втыкать XOR-топологию в транспортный слой — на вид это обычная компьютера, где можно повесить узел; но проблема в том, что каждый день уйма людей отключается, разрывает соединение и выключает устройства. Когда масштабно выбиваешься из строя, маршрутизирующие таблицы просто не успевают отреагировать. Если вдруг случается разрыв сети, чинить такую «точную» трассу куда сложнее, чем устранять последствия широковещания: хочешь проверить потери пакетов — и тебя почти гарантированно доведут до безумия. $BTC
Прежде чем лезть и оценивать, насколько крепка «начинка» той или иной цепочки, не смотри только на завышенные тестами TPS. Смотри, выдержит ли нижний уровень, когда система реально разваливается. Когда математика расстояний жёстко фиксирует, куда именно разлетаются данные, — да, это действительно практичный подход. Но выдержит ли эта штука в экстремально нервной реальной эксплуатации — я думаю, ответ даст только время: нужно сначала влить туда по-настоящему громадный поток трафика и хорошенько «побить» его какое-то время. #dusk $ETH
Потом я копнул базовый уровень у @Dusk и выяснил, что там в архитектуре Kadcast сделаны кое-какие хитрые ходы. Проект не пошёл по пути старого «залить всё водой»: вместо этого он прямо с помощью алгоритма XOR рисует сеть направленной раздачи. Каждое устройство занимается только своей небольшой зоной, где и проталкивает нужные данные; а с самого источника весь этот беспорядочный массовый спам загоняется в фиксированные линии. Даже если поток транзакций мгновенно взлетит, «мусорная» периферийная тараканья дичь всё равно будет удержана.
Но судя по тем граблям, на которые я наступал, как бы ни были чудесны на бумаге схемы разгрузки, в реальном машинном зале всё равно придётся пойти на компромиссы. Втыкать XOR-топологию в транспортный слой — на вид это обычная компьютера, где можно повесить узел; но проблема в том, что каждый день уйма людей отключается, разрывает соединение и выключает устройства. Когда масштабно выбиваешься из строя, маршрутизирующие таблицы просто не успевают отреагировать. Если вдруг случается разрыв сети, чинить такую «точную» трассу куда сложнее, чем устранять последствия широковещания: хочешь проверить потери пакетов — и тебя почти гарантированно доведут до безумия. $BTC
Прежде чем лезть и оценивать, насколько крепка «начинка» той или иной цепочки, не смотри только на завышенные тестами TPS. Смотри, выдержит ли нижний уровень, когда система реально разваливается. Когда математика расстояний жёстко фиксирует, куда именно разлетаются данные, — да, это действительно практичный подход. Но выдержит ли эта штука в экстремально нервной реальной эксплуатации — я думаю, ответ даст только время: нужно сначала влить туда по-настоящему громадный поток трафика и хорошенько «побить» его какое-то время. #dusk $ETH