#dusk $DUSK @Dusk Я помню, как мой младший брат Уакас задал мне вопрос, который заставил меня по-новому взглянуть на дизайн приватности Dusk. Если пользователи могут выбирать, сколько информации раскрывать, разве это не усложняет разработку?
Честно говоря, я был удивлён тому, что вскрыл этот вопрос. Главная проблема не в том, что скрыты сами транзакции. Проблема в том, что разработчики не могут считать публичный реестр исчерпывающим источником состояния приложения.
Это предположение имеет значение уже на уровне инфраструктуры. Кошельки, индексаторы и финансовые системы должны учитывать случаи, когда информация, которую они обычно используют для обнаружения, восстановления или учёта, не доступна публично.
Меня особенно зацепило то, что происходит на один уровень выше. Разработчики должны различать функции, которым действительно нужны детали транзакций, и те, которые могут работать без них.
Вместо того чтобы строить всё вокруг максимальной видимости данных и добавлять приватность позже, приложения должны заранее определить свои зависимости по данным с учётом приватности. Именно этот архитектурный компромисс в Dusk мне кажется самым интересным. Приватность меняет то, что финансовое ПО может знать по умолчанию, а значит — то, как это ПО должно проектироваться.
Вы согласились бы пожертвовать некоторой простотой разработки ради модели приложения, в которой приватность заложена в базовые предположения с первого дня? 🤔
Честно говоря, я был удивлён тому, что вскрыл этот вопрос. Главная проблема не в том, что скрыты сами транзакции. Проблема в том, что разработчики не могут считать публичный реестр исчерпывающим источником состояния приложения.
Это предположение имеет значение уже на уровне инфраструктуры. Кошельки, индексаторы и финансовые системы должны учитывать случаи, когда информация, которую они обычно используют для обнаружения, восстановления или учёта, не доступна публично.
Меня особенно зацепило то, что происходит на один уровень выше. Разработчики должны различать функции, которым действительно нужны детали транзакций, и те, которые могут работать без них.
Вместо того чтобы строить всё вокруг максимальной видимости данных и добавлять приватность позже, приложения должны заранее определить свои зависимости по данным с учётом приватности. Именно этот архитектурный компромисс в Dusk мне кажется самым интересным. Приватность меняет то, что финансовое ПО может знать по умолчанию, а значит — то, как это ПО должно проектироваться.
Вы согласились бы пожертвовать некоторой простотой разработки ради модели приложения, в которой приватность заложена в базовые предположения с первого дня? 🤔