Меня сейчас больше всего волнует @Dusk не то, можно ли это технически сделать, а то, осмелятся ли обычные пользователи этим пользоваться.
Недавно я снова прошёл фактический процесс по шагам: со стороны разработки обновления выходят довольно активно, но когда это реально доходит до пользователя, такие базовые действия, как миграция, кроссчейн и стейкинг, всё ещё имеют невысокую отказоустойчивость.
Например, перенос ERC20/BEP20 DUSK в основную сеть — это не “нажал кнопочку и готово”. Сначала нужно сделать Approve, затем Execute. Пропустить любой шаг — значит перенос не считается завершённым. Типичное время ожидания, указанное в официальных материалах, — около 1 часа, и при этом заранее нужно подготовить ETH/BNB для оплаты gas.
Ещё сильнее меня беспокоит перевод из основной сети в BSC. Адрес получения требуется задавать через memo. Официальная документация прямо предупреждает: если memo будет заполнено с ошибкой или окажется недействительным, транзакция может не обработаться автоматически, а также существует риск, что активы невозможно будет восстановить.
Для старых игроков это, возможно, кажется: “просто внимательнее и всё”. Но если продукт рассчитан на более широкую аудиторию, нельзя вечно перекладывать ответственность за защиту от ошибок на пользователя.
Стейкинг тоже похожая история. Непосредственно стейкать можно от 1000 DUSK, но при этом пользователю нужно самому запускать provisioner. Узел должен оставаться онлайн, синхронизироваться и иметь правильную версию; активация работает корректно только после примерно 6—12 часов. Технически всё ок, но с точки зрения обычного держателя монет это явно не самый простой сценарий.
Плюс в январе этого года сервис моста уже подвергался атаке: взламывали подписные кошельки. Официально позже чётко сказали, что это не уязвимость консенсусного слоя Dusk, но обычные пользователи всё равно не будут различать “безопасность протокола” и “безопасность сервиса”. Их волнует только одно: если я сделаю что-то не так или система даст сбой — деньги вернутся или нет?
Поэтому сейчас я, наоборот, думаю, что на следующем этапе Dusk надо восполнить не только базовую производительность.
А сделать “не ошибёшься при заполнении, состояние можно понять, а при ошибке есть шанс спасти ситуацию” реальным продуктовым поведением по умолчанию.
Техническая сложность пусть будет, но пользовательский опыт не должен быть сложным.
#dusk $DUSK @Dusk
Недавно я снова прошёл фактический процесс по шагам: со стороны разработки обновления выходят довольно активно, но когда это реально доходит до пользователя, такие базовые действия, как миграция, кроссчейн и стейкинг, всё ещё имеют невысокую отказоустойчивость.
Например, перенос ERC20/BEP20 DUSK в основную сеть — это не “нажал кнопочку и готово”. Сначала нужно сделать Approve, затем Execute. Пропустить любой шаг — значит перенос не считается завершённым. Типичное время ожидания, указанное в официальных материалах, — около 1 часа, и при этом заранее нужно подготовить ETH/BNB для оплаты gas.
Ещё сильнее меня беспокоит перевод из основной сети в BSC. Адрес получения требуется задавать через memo. Официальная документация прямо предупреждает: если memo будет заполнено с ошибкой или окажется недействительным, транзакция может не обработаться автоматически, а также существует риск, что активы невозможно будет восстановить.
Для старых игроков это, возможно, кажется: “просто внимательнее и всё”. Но если продукт рассчитан на более широкую аудиторию, нельзя вечно перекладывать ответственность за защиту от ошибок на пользователя.
Стейкинг тоже похожая история. Непосредственно стейкать можно от 1000 DUSK, но при этом пользователю нужно самому запускать provisioner. Узел должен оставаться онлайн, синхронизироваться и иметь правильную версию; активация работает корректно только после примерно 6—12 часов. Технически всё ок, но с точки зрения обычного держателя монет это явно не самый простой сценарий.
Плюс в январе этого года сервис моста уже подвергался атаке: взламывали подписные кошельки. Официально позже чётко сказали, что это не уязвимость консенсусного слоя Dusk, но обычные пользователи всё равно не будут различать “безопасность протокола” и “безопасность сервиса”. Их волнует только одно: если я сделаю что-то не так или система даст сбой — деньги вернутся или нет?
Поэтому сейчас я, наоборот, думаю, что на следующем этапе Dusk надо восполнить не только базовую производительность.
А сделать “не ошибёшься при заполнении, состояние можно понять, а при ошибке есть шанс спасти ситуацию” реальным продуктовым поведением по умолчанию.
Техническая сложность пусть будет, но пользовательский опыт не должен быть сложным.
#dusk $DUSK @Dusk