@Dusk_Foundation
Меня кое-что удивило в whitepaper’е Dusk: он открыто признаёт изъян в собственном дизайне, а не просто продаёт видение. Блок-генераторы выбираются по детерминированной формуле, поэтому провайдер иногда может заранее понять, что они заготовлены на более позднюю попытку того же блока, если предыдущие попытки не сработают — а это создаёт странный стимул просто позволить этим попыткам рушиться.
В документе это названо проблемой будущего генератора, и вместо того чтобы замалчивать её, предлагаются реальные исправления: награждать людей только за голосование, привязать часть награды генератора к тому, сколько голосов они включили, и исключать следующего по очереди генератора из текущего голосования. Такая откровенность, похоже, адресована тем, кто живёт аудитом систем, а не тем, кто гонится за нарративом — что хорошо сочетается с общим позиционированием Dusk в сторону регулируемых финансов.
Но исправление — это не панацея. Награды меняют поведение, но не убирают лежащую в основе предсказуемость, и хорошо финансируемый провайдер, которому безразлична репутация, всё равно может решить, что риск стоит того. Это тот же тип разрыва, который возникает между кодом и правом: протокол может сделать плохое поведение дорогим, но только суд или регулятор способны сделать его значимым независимо от того, насколько глубоки чьи-то карманы.
Всё это не делает подход Dusk менее вдумчивым — просто интересная часть whitepaper’а часто не та, что продаёт результат, а тот абзац, где признаётся слабое место. Сначала прочитайте ограничения, которые проект называет сам, а затем решите, насколько остальному можно доверять.
Всё ещё учусь этому по одной статье за раз — и честно, в этом и есть самое интересное.
@Dusk_Foundation #dusk $DUSK
Меня кое-что удивило в whitepaper’е Dusk: он открыто признаёт изъян в собственном дизайне, а не просто продаёт видение. Блок-генераторы выбираются по детерминированной формуле, поэтому провайдер иногда может заранее понять, что они заготовлены на более позднюю попытку того же блока, если предыдущие попытки не сработают — а это создаёт странный стимул просто позволить этим попыткам рушиться.
В документе это названо проблемой будущего генератора, и вместо того чтобы замалчивать её, предлагаются реальные исправления: награждать людей только за голосование, привязать часть награды генератора к тому, сколько голосов они включили, и исключать следующего по очереди генератора из текущего голосования. Такая откровенность, похоже, адресована тем, кто живёт аудитом систем, а не тем, кто гонится за нарративом — что хорошо сочетается с общим позиционированием Dusk в сторону регулируемых финансов.
Но исправление — это не панацея. Награды меняют поведение, но не убирают лежащую в основе предсказуемость, и хорошо финансируемый провайдер, которому безразлична репутация, всё равно может решить, что риск стоит того. Это тот же тип разрыва, который возникает между кодом и правом: протокол может сделать плохое поведение дорогим, но только суд или регулятор способны сделать его значимым независимо от того, насколько глубоки чьи-то карманы.
Всё это не делает подход Dusk менее вдумчивым — просто интересная часть whitepaper’а часто не та, что продаёт результат, а тот абзац, где признаётся слабое место. Сначала прочитайте ограничения, которые проект называет сам, а затем решите, насколько остальному можно доверять.
Всё ещё учусь этому по одной статье за раз — и честно, в этом и есть самое интересное.
@Dusk_Foundation #dusk $DUSK