Я снова и снова ошибался, когда продумывал Moonlight и Phoenix: я относился к форме состояния так, будто она также определяет окончательность.
Эта предпосылка начала меня беспокоить.
Moonlight приходит с моделью публичного аккаунта: Balances, Sender, Receiver, Amount и Nonce Progression. #DuskVM
Phoenix построен вокруг совершенно другого следа: Encrypted Notes, Shielded Outputs, Nullifiers и Private State.
Мой первый инстинкт был таким: раз это две настолько разные системы, им, вероятно, нужны и два разных способа стать финальными.
Но, возможно, именно там я добавлял сложности, которых на самом деле нет.
Moonlight может оставаться аккаунт-образным. Phoenix может оставаться note-образным. #DuskVM не нужно сводить ни один из них в некий универсальный формат состояния только ради того, чтобы решить, когда выполнение завершено.
Это также заставило меня пересмотреть #DuskDS .
Я предполагал, что ему нужно создать одно общее $DUSK состояние под обеими моделями. Теперь я в этом менее уверен.
Логика выполнения может оставаться специализированной, тогда как Dusk L1 всё равно будет давать получившемуся состоянию одну детерминированную границу окончательности.
И честно говоря, такая раздельность мне интереснее, чем отдельные модели состояния.
Разные способы представления состояния не обязательно требуют разных ответов на вопрос о том, когда это состояние наконец считается завершённым.
То, о чём я всё ещё думаю, — насколько чисто эта раздельность сохраняется по мере того, как Moonlight и Phoenix становятся более сложными.
#dusk $DUSK @Dusk
Эта предпосылка начала меня беспокоить.
Moonlight приходит с моделью публичного аккаунта: Balances, Sender, Receiver, Amount и Nonce Progression. #DuskVM
Phoenix построен вокруг совершенно другого следа: Encrypted Notes, Shielded Outputs, Nullifiers и Private State.
Мой первый инстинкт был таким: раз это две настолько разные системы, им, вероятно, нужны и два разных способа стать финальными.
Но, возможно, именно там я добавлял сложности, которых на самом деле нет.
Moonlight может оставаться аккаунт-образным. Phoenix может оставаться note-образным. #DuskVM не нужно сводить ни один из них в некий универсальный формат состояния только ради того, чтобы решить, когда выполнение завершено.
Это также заставило меня пересмотреть #DuskDS .
Я предполагал, что ему нужно создать одно общее $DUSK состояние под обеими моделями. Теперь я в этом менее уверен.
Логика выполнения может оставаться специализированной, тогда как Dusk L1 всё равно будет давать получившемуся состоянию одну детерминированную границу окончательности.
И честно говоря, такая раздельность мне интереснее, чем отдельные модели состояния.
Разные способы представления состояния не обязательно требуют разных ответов на вопрос о том, когда это состояние наконец считается завершённым.
То, о чём я всё ещё думаю, — насколько чисто эта раздельность сохраняется по мере того, как Moonlight и Phoenix становятся более сложными.
#dusk $DUSK @Dusk
