Одна фраза в выпуске Dusk Hyperlane, посвящённом утверждению производства, особенно привлекла моё внимание: "no admin recovery path."
Это звучит как чистый выбор в пользу минимизации доверия. Если нет привилегированного административного ключа, который может вывести или перенаправить ожидаемое эскроу, один очевидный источник вмешательства исчезает.
Но это также убирает один из очевидных способов вмешаться, когда законные средства застревают. Это важно, поскольку Dusk стремится вывести финансовые рынки в блокчейн вместе с учреждениями, лицензированными в ЕС, где зависший перевод — это не просто технический крайний случай, а часть операционной надёжности, которую должна обеспечивать инфраструктура.
Что я пока не знаю, так это сможет ли Dusk Hyperlane убрать широкое административное управление, при этом сохранив узкий, детерминированный способ восстановления после законных сбоев, или же некоторые ошибки просто станут необратимыми блокировками.
Детали, за которыми стоит следить, довольно конкретны: восстановление при совпадении получателя, случаи с утерянным ключом и неверные данные получателя или хэша.
Отсутствие аварийного административного механизма — полезное свидетельство того, что привилегированный контроль был сокращён. Но это слабое свидетельство того, что средства остаются доступными к восстановлению, когда что-то идёт не так.
Я бы оценивал дизайн не столько по тому, может ли администратор вмешаться, сколько по тому, сохраняется ли у законного восстановления предсказуемый путь без повторного открытия широкого дискреционного контроля.
Устранение органа восстановления может снизить одно допущение о доверии, одновременно делая другой режим отказа более необратимым.
Вопрос в том, сможет ли Dusk Hyperlane минимизировать привилегированное восстановление, не превращая исправимые ошибки в постоянное состояние.
Я слежу за дизайном восстановления pending-escrow, особенно за тем, как Dusk обрабатывает утерянные ключи и неверные данные получателя.
@Dusk $DUSK #dusk
Это звучит как чистый выбор в пользу минимизации доверия. Если нет привилегированного административного ключа, который может вывести или перенаправить ожидаемое эскроу, один очевидный источник вмешательства исчезает.
Но это также убирает один из очевидных способов вмешаться, когда законные средства застревают. Это важно, поскольку Dusk стремится вывести финансовые рынки в блокчейн вместе с учреждениями, лицензированными в ЕС, где зависший перевод — это не просто технический крайний случай, а часть операционной надёжности, которую должна обеспечивать инфраструктура.
Что я пока не знаю, так это сможет ли Dusk Hyperlane убрать широкое административное управление, при этом сохранив узкий, детерминированный способ восстановления после законных сбоев, или же некоторые ошибки просто станут необратимыми блокировками.
Детали, за которыми стоит следить, довольно конкретны: восстановление при совпадении получателя, случаи с утерянным ключом и неверные данные получателя или хэша.
Отсутствие аварийного административного механизма — полезное свидетельство того, что привилегированный контроль был сокращён. Но это слабое свидетельство того, что средства остаются доступными к восстановлению, когда что-то идёт не так.
Я бы оценивал дизайн не столько по тому, может ли администратор вмешаться, сколько по тому, сохраняется ли у законного восстановления предсказуемый путь без повторного открытия широкого дискреционного контроля.
Устранение органа восстановления может снизить одно допущение о доверии, одновременно делая другой режим отказа более необратимым.
Вопрос в том, сможет ли Dusk Hyperlane минимизировать привилегированное восстановление, не превращая исправимые ошибки в постоянное состояние.
Я слежу за дизайном восстановления pending-escrow, особенно за тем, как Dusk обрабатывает утерянные ключи и неверные данные получателя.
@Dusk $DUSK #dusk
