Я всё время замечал, что @Dusk не заставляет каждую транзакцию проходить через одну модель.
Moonlight использует аккаунтную структуру, тогда как Phoenix придерживается подхода UTXO. Сначала это кажется ненужной сложностью. Зачем поддерживать два способа представления транзакций вместо того, чтобы выбрать один и сделать архитектуру проще?
Чем больше я это изучал, тем больше разделение начинало казаться логичным. Состояние на основе аккаунта напрямую подходит для балансов и логики приложений. Phoenix даёт Dusk другой формат транзакций, который может поддерживать более ориентированные на приватность сценарии.
Такая гибкость полезна.
Но есть компромисс, о котором, как мне кажется, недостаточно говорят. Каждая дополнительная модель транзакций добавляет ещё одну ментальную модель для разработчиков и пользователей, чтобы её понимать. Архитектура может становиться более способной, но при этом общей системе становится сложнее рассуждать.
Так в итоге наличие отдельных моделей транзакций действительно даёт Dusk полезную гибкость, или же дополнительная сложность со временем начинает перевешивать выгоду?
#dusk @Dusk $DUSK
Moonlight использует аккаунтную структуру, тогда как Phoenix придерживается подхода UTXO. Сначала это кажется ненужной сложностью. Зачем поддерживать два способа представления транзакций вместо того, чтобы выбрать один и сделать архитектуру проще?
Чем больше я это изучал, тем больше разделение начинало казаться логичным. Состояние на основе аккаунта напрямую подходит для балансов и логики приложений. Phoenix даёт Dusk другой формат транзакций, который может поддерживать более ориентированные на приватность сценарии.
Такая гибкость полезна.
Но есть компромисс, о котором, как мне кажется, недостаточно говорят. Каждая дополнительная модель транзакций добавляет ещё одну ментальную модель для разработчиков и пользователей, чтобы её понимать. Архитектура может становиться более способной, но при этом общей системе становится сложнее рассуждать.
Так в итоге наличие отдельных моделей транзакций действительно даёт Dusk полезную гибкость, или же дополнительная сложность со временем начинает перевешивать выгоду?
#dusk @Dusk $DUSK
Useful flexibility
Too much complexity
Depends on use case
Still worth the tradeoff
45 мин. осталось
