Сегодня мой дядя спросил меня кое-что, что звучало просто. «Если финансовая система говорит, что транзакция прошла успешно, почему кто-то вообще будет это оспаривать?»
Честно говоря, этот вопрос остался со мной, пока я разбирался, как Dusk обрабатывает транзакции.
Раньше я думал, что успех — это просто успех. Но Dusk разделяет процесс на разные этапы. Транзакция может быть принята для маршрутизации, попасть в локальный mempool, выполниться в блоке и только позже достичь финальности.
Это заставило меня на секунду задуматься.
Настоящая проблема не в том, что у системы несколько состояний. Проблема в том, что происходит, когда приложение обращается с этими состояниями так, будто они все означают одно и то же.
Меня удивило, насколько практичен этот риск. Если приложение видит «успех» и сразу освобождает актив, обновляет залог или закрывает обязательство, оно может действовать до того, как протокол фактически достиг того состояния, которое требуется для этого действия.
Рекомендации Dusk для обмена делают то же различие очевидным. То, что транзакция принята для маршрутизации, не означает, что вывод завершён. Важны и выполнение, и финальность.
Моя обеспокоенность — не в сложности. Финансовые системы и так сложные.
Главный Trade-off — между тем, чтобы API было легко использовать, и тем, чтобы разработчикам было достаточно информации для правильного экономического решения.
Моё желание простое. API должен сообщать
разработчикам не только то, что произошло, но
что они на самом деле могут безопасно делать дальше.
Я говорю честно. Я бы предпочёл видеть несколько понятных состояний, а не одно простое сообщение об успехе, которое может означать разное в разных точках.
Так что, должны ли финансовые API скрывать сложность протокола или показывать разработчикам то состояние, которое им реально нужно увидеть прежде чем совершать следующее финансовое действие? 🤔
#dusk $DUSK $BTC $ETH @Dusk
#Blockchain #DeFi #Web3
Честно говоря, этот вопрос остался со мной, пока я разбирался, как Dusk обрабатывает транзакции.
Раньше я думал, что успех — это просто успех. Но Dusk разделяет процесс на разные этапы. Транзакция может быть принята для маршрутизации, попасть в локальный mempool, выполниться в блоке и только позже достичь финальности.
Это заставило меня на секунду задуматься.
Настоящая проблема не в том, что у системы несколько состояний. Проблема в том, что происходит, когда приложение обращается с этими состояниями так, будто они все означают одно и то же.
Меня удивило, насколько практичен этот риск. Если приложение видит «успех» и сразу освобождает актив, обновляет залог или закрывает обязательство, оно может действовать до того, как протокол фактически достиг того состояния, которое требуется для этого действия.
Рекомендации Dusk для обмена делают то же различие очевидным. То, что транзакция принята для маршрутизации, не означает, что вывод завершён. Важны и выполнение, и финальность.
Моя обеспокоенность — не в сложности. Финансовые системы и так сложные.
Главный Trade-off — между тем, чтобы API было легко использовать, и тем, чтобы разработчикам было достаточно информации для правильного экономического решения.
Моё желание простое. API должен сообщать
разработчикам не только то, что произошло, но
что они на самом деле могут безопасно делать дальше.
Я говорю честно. Я бы предпочёл видеть несколько понятных состояний, а не одно простое сообщение об успехе, которое может означать разное в разных точках.
Так что, должны ли финансовые API скрывать сложность протокола или показывать разработчикам то состояние, которое им реально нужно увидеть прежде чем совершать следующее финансовое действие? 🤔
#dusk $DUSK $BTC $ETH @Dusk
#Blockchain #DeFi #Web3
