Я провёл часть сегодняшнего дня, разбираясь в fork-handling и дизайнe приватности Dusk, и в итоге соединил два направления, которые поначалу считал не связанными: поощрения в механизме консенсуса и приватные транзакции.
Сначала внимание привлекло правило fork. Dusk использует номер итерации при разрешении конкурирующих блоков, отдавая предпочтение меньшей итерации. Я понимаю базовую логику, но почему именно итерация является самым сильным сигналом того, какой блок должен сохраниться? Какие предположения это делает относительно тайминга в сети и добросовестного участия?
Затем я посмотрел на проблему future-generator. Если провижионер знает, что в более поздней итерации он может стать генератором, может ли ему быть выгодно допускать, чтобы более ранние попытки проваливались? Это создаёт странную проблему стимулов, особенно когда речь идёт о вознаграждениях за блок.
Модель отказов тоже лучше укладывается в этот контекст. Почему дабл-вайтинг (двойное голосование) должны наказывать строже, чем невыполнение рассылки кандидата? Моё прочтение такое: умышленное конфликтующее поведение напрямую угрожает консенсусу, тогда как бездействие в основном влияет на живучесть (liveness), но эта разница важна для экономики валидаторов.
Phoenix вернул разговор к финансам. Понимаю, почему приватные транзакции могут быть значимыми для ценных бумаг, институциональных переводов или чувствительных финансовых операций. Его ZK-доказательства могут подтвердить, что балансы, право собственности и правила расходования корректны, не раскрывая лежащие в основе детали.
Но делегирование добавляет ещё один слой доверия. Если пользователи полагаются на третьи стороны, чтобы те сканировали их транзакции с использованием view keys (ключей просмотра), какую информацию эти стороны в действительности смогут узнать?
Я остаюсь с вопросом, где Dusk проводит практическую границу между приватностью, безопасностью, стимулами и операционным удобством.
#dusk $DUSK @Dusk
Сначала внимание привлекло правило fork. Dusk использует номер итерации при разрешении конкурирующих блоков, отдавая предпочтение меньшей итерации. Я понимаю базовую логику, но почему именно итерация является самым сильным сигналом того, какой блок должен сохраниться? Какие предположения это делает относительно тайминга в сети и добросовестного участия?
Затем я посмотрел на проблему future-generator. Если провижионер знает, что в более поздней итерации он может стать генератором, может ли ему быть выгодно допускать, чтобы более ранние попытки проваливались? Это создаёт странную проблему стимулов, особенно когда речь идёт о вознаграждениях за блок.
Модель отказов тоже лучше укладывается в этот контекст. Почему дабл-вайтинг (двойное голосование) должны наказывать строже, чем невыполнение рассылки кандидата? Моё прочтение такое: умышленное конфликтующее поведение напрямую угрожает консенсусу, тогда как бездействие в основном влияет на живучесть (liveness), но эта разница важна для экономики валидаторов.
Phoenix вернул разговор к финансам. Понимаю, почему приватные транзакции могут быть значимыми для ценных бумаг, институциональных переводов или чувствительных финансовых операций. Его ZK-доказательства могут подтвердить, что балансы, право собственности и правила расходования корректны, не раскрывая лежащие в основе детали.
Но делегирование добавляет ещё один слой доверия. Если пользователи полагаются на третьи стороны, чтобы те сканировали их транзакции с использованием view keys (ключей просмотра), какую информацию эти стороны в действительности смогут узнать?
Я остаюсь с вопросом, где Dusk проводит практическую границу между приватностью, безопасностью, стимулами и операционным удобством.
#dusk $DUSK @Dusk