Я заметил кое-что при сверке потока транзакций по @Dusk с активностью $DUSK EVM на прошлой неделе: транзакции подтверждались, но временной разрыв между подачей и окончательной финализацией постоянно смещался по повторяющемуся шаблону, который совершенно не соответствовал сетевой перегрузке. Мое первое предположение было простым: это могла быть ценовая политика перегрузки, такая, как на большинстве цепочек, когда объем свободного места в блоках становится востребованным.
Копнув глубже, я проследил это до того, как Dusk разделяет подтверждение выполнения (execution confirmation) и финализацию расчетов (settlement finality). Транзакция может быть принята и обработана на уровне сетевого взаимодействия, тогда как реальная финализация — та часть, которая важна для регулируемых или скрытых по требованиям конфиденциальности активов — проходит по отдельному консенсусному пути. Это не похоже на перегрузку. Это протокол, который действительно трактует состояния «processed» и «final» как разные, а не как два слова для одного и того же события.
Это полностью изменило то, как я думаю об индикаторах активности. Большинство людей, включая меня — по крайней мере до недавнего времени — смешивают пропускную способность (throughput) с гарантиями финализации (settlement guarantees). Но если выполнение и финализация намеренно разъединены, то всплеск видимого объема транзакций не обязательно означает всплеск подтвержденной экономической активности. Вторичный эффект в том, что панели мониторинга, показывающие «сырой» счетчик tx, могут завышать реальное использование в периоды, когда финализация отстает от выполнения.
Что мне пока не удалось выяснить — это, является ли это разъединение осознанным выбором ради устойчивости или просто побочным результатом того, как валидаторы выстраивают последовательность работы в условиях ограничений выборочного раскрытия (selective disclosure). Если это задумано, то это говорит о том, что сеть оптимизирует целостность финализации важнее броской скорости — это реальный компромисс, а не ошибка. Но мне пока не ясно, как именно валидаторов мотивируют при нагрузке отдавать приоритет одному пути над другим.
В дальнейшем я отслеживаю разницу между временными метками выполнения и временными метками расчетов при разных уровнях нагрузки, а не только среднее время финализации. Я также хочу понять, смещается ли участие валидаторов, когда этот разрыв увеличивается: это показало бы, управляют ли операторы этим активно или просто пассивно «поглощают» разницу.#dusk
Копнув глубже, я проследил это до того, как Dusk разделяет подтверждение выполнения (execution confirmation) и финализацию расчетов (settlement finality). Транзакция может быть принята и обработана на уровне сетевого взаимодействия, тогда как реальная финализация — та часть, которая важна для регулируемых или скрытых по требованиям конфиденциальности активов — проходит по отдельному консенсусному пути. Это не похоже на перегрузку. Это протокол, который действительно трактует состояния «processed» и «final» как разные, а не как два слова для одного и того же события.
Это полностью изменило то, как я думаю об индикаторах активности. Большинство людей, включая меня — по крайней мере до недавнего времени — смешивают пропускную способность (throughput) с гарантиями финализации (settlement guarantees). Но если выполнение и финализация намеренно разъединены, то всплеск видимого объема транзакций не обязательно означает всплеск подтвержденной экономической активности. Вторичный эффект в том, что панели мониторинга, показывающие «сырой» счетчик tx, могут завышать реальное использование в периоды, когда финализация отстает от выполнения.
Что мне пока не удалось выяснить — это, является ли это разъединение осознанным выбором ради устойчивости или просто побочным результатом того, как валидаторы выстраивают последовательность работы в условиях ограничений выборочного раскрытия (selective disclosure). Если это задумано, то это говорит о том, что сеть оптимизирует целостность финализации важнее броской скорости — это реальный компромисс, а не ошибка. Но мне пока не ясно, как именно валидаторов мотивируют при нагрузке отдавать приоритет одному пути над другим.
В дальнейшем я отслеживаю разницу между временными метками выполнения и временными метками расчетов при разных уровнях нагрузки, а не только среднее время финализации. Я также хочу понять, смещается ли участие валидаторов, когда этот разрыв увеличивается: это показало бы, управляют ли операторы этим активно или просто пассивно «поглощают» разницу.#dusk