Конфиденциальность Dusk действительно заслуживает доверия только тогда, когда сеть находится под нагрузкой
То, что изменило мой взгляд на Phoenix, — это понимание: «не видно» не означает «не подлежит проверке»
Для shielded-транзакций наблюдатель публично не видит ни отправителя, ни получателя, ни сумму — как в Moonlight, — но сама сеть всё равно должна подтвердить транзакцию, прежде чем состояние будет принято. Затем DuskDS передаёт блок через proposal, validation и ratification, чтобы добиться детерминированной финальности.
В обычных условиях эта модель довольно компактная. Но то, что мне хочется рассмотреть внимательнее, — это момент, когда сеть перегружена.
Если и public, и confidential-транзакции одновременно создают давление на систему, комитет постоянно меняется, а некоторые provisioner начинают отставать по темпу — приватность перестаёт быть единственным вопросом. Сеть ещё должна сохранять liveness и finality, не снижая планку верификации.
Точка, которая кажется мне разумной, — что Dusk не считает все ошибки одинаковыми. Provisioner, который пропустил выполнение задачи, может получить soft-penalty, а поведение, которое можно доказуемо считать неверным — например, недействительное голосование или конфликтующая подпись — способно привести к hard-penalty.
По-моему, именно это — более интересный тест, чем просто приватная транзакция, которая проходит гладко.
Хорошая система приватности должна не только скрывать данные, когда всё работает нормально. Она должна сохранять возможность верификации, когда узлы сбиваются с ритма, committee меняется по кругу и когда сетевой трафик резко растёт.
Если Dusk удержит эту границу, то приватность будет по-настоящему свойством инфраструктуры, а не просто пользовательским опытом.
@Dusk $DUSK #dusk
$RICE $BTW
То, что изменило мой взгляд на Phoenix, — это понимание: «не видно» не означает «не подлежит проверке»
Для shielded-транзакций наблюдатель публично не видит ни отправителя, ни получателя, ни сумму — как в Moonlight, — но сама сеть всё равно должна подтвердить транзакцию, прежде чем состояние будет принято. Затем DuskDS передаёт блок через proposal, validation и ratification, чтобы добиться детерминированной финальности.
В обычных условиях эта модель довольно компактная. Но то, что мне хочется рассмотреть внимательнее, — это момент, когда сеть перегружена.
Если и public, и confidential-транзакции одновременно создают давление на систему, комитет постоянно меняется, а некоторые provisioner начинают отставать по темпу — приватность перестаёт быть единственным вопросом. Сеть ещё должна сохранять liveness и finality, не снижая планку верификации.
Точка, которая кажется мне разумной, — что Dusk не считает все ошибки одинаковыми. Provisioner, который пропустил выполнение задачи, может получить soft-penalty, а поведение, которое можно доказуемо считать неверным — например, недействительное голосование или конфликтующая подпись — способно привести к hard-penalty.
По-моему, именно это — более интересный тест, чем просто приватная транзакция, которая проходит гладко.
Хорошая система приватности должна не только скрывать данные, когда всё работает нормально. Она должна сохранять возможность верификации, когда узлы сбиваются с ритма, committee меняется по кругу и когда сетевой трафик резко растёт.
Если Dusk удержит эту границу, то приватность будет по-настоящему свойством инфраструктуры, а не просто пользовательским опытом.
@Dusk $DUSK #dusk
$RICE $BTW
