У меня есть одна вещь, которую я осознал, когда попытался задать вопрос: если приватность — это лишь «дополнительный инструмент, когда уместно» в EVM-testnet Dusk, то что заставит разработчика действительно выбрать её вместо того, чтобы пропустить?
Для большинства девов по умолчанию всегда выигрывает — не потому, что им неинтересны расширенные функции, а потому что по умолчанию — самый беспрепятственный путь, когда вы пытаетесь вовремя выпустить продукт. Функция, которая находится в отдельной документации, требует освоения отдельного SDK и предполагает иной образ мышления, чем привычная EVM, неизбежно будет отправлена в список «сделать позже», если только не найдётся действительно срочная причина поставить её в приоритет прямо сейчас.
Это скорее поведенческая проблема, чем техническая. Каким бы мощным ни было решение Hedger или насколько бы сильной ни была конструкция гомоморфного шифрования, указанного в @Dusk mạnh, если путь по умолчанию всё ещё остаётся стандартной цепочкой OP Stack без шифрования, то большинство приложений, которые строятся на этом testnet в ранней фазе, с большой вероятностью не будут использовать слой privacy — просто потому, что никого не заставляют это делать. Если это продолжится и на mainnet, последствия могут быть в том, что экосистема приложений в основном не будет раскрывать ту ключевую ценность, для которой $DUSK была задумана.
Самооспоривание: возможно, это просто слишком ранние опасения — на testnet всегда в первую очередь делают то, что проще, и privacy может стать настройкой по умолчанию на этапе mainnet, когда у Dusk будет достаточно времени, чтобы довести dev-опыт для этой части до совершенства.
Я жду, чтобы увидеть, опубликует ли Dusk конкретный roadmap по тому, чтобы перевести privacy из статуса «дополнительного инструмента» в более близкий к дефолту вариант, прежде чем экосистема приложений сформируется в противоположном направлении.
#dusk $AKE $BTC
Для большинства девов по умолчанию всегда выигрывает — не потому, что им неинтересны расширенные функции, а потому что по умолчанию — самый беспрепятственный путь, когда вы пытаетесь вовремя выпустить продукт. Функция, которая находится в отдельной документации, требует освоения отдельного SDK и предполагает иной образ мышления, чем привычная EVM, неизбежно будет отправлена в список «сделать позже», если только не найдётся действительно срочная причина поставить её в приоритет прямо сейчас.
Это скорее поведенческая проблема, чем техническая. Каким бы мощным ни было решение Hedger или насколько бы сильной ни была конструкция гомоморфного шифрования, указанного в @Dusk mạnh, если путь по умолчанию всё ещё остаётся стандартной цепочкой OP Stack без шифрования, то большинство приложений, которые строятся на этом testnet в ранней фазе, с большой вероятностью не будут использовать слой privacy — просто потому, что никого не заставляют это делать. Если это продолжится и на mainnet, последствия могут быть в том, что экосистема приложений в основном не будет раскрывать ту ключевую ценность, для которой $DUSK была задумана.
Самооспоривание: возможно, это просто слишком ранние опасения — на testnet всегда в первую очередь делают то, что проще, и privacy может стать настройкой по умолчанию на этапе mainnet, когда у Dusk будет достаточно времени, чтобы довести dev-опыт для этой части до совершенства.
Я жду, чтобы увидеть, опубликует ли Dusk конкретный roadmap по тому, чтобы перевести privacy из статуса «дополнительного инструмента» в более близкий к дефолту вариант, прежде чем экосистема приложений сформируется в противоположном направлении.
#dusk $AKE $BTC
