#dusk $TRUMP $DASH $DUSK @Dusk
aún sigo dándole vueltas a esto: si Moonlight DUSK y Phoenix DUSK llegan a DuskVM con un aspecto completamente distinto, entonces Dusk probablemente también necesite dos formas diferentes de darles final a ambas.
Moonlight está ahí con el saldo de una cuenta pública, el remitente, el receptor, el importe, el nonce avanzando. Phoenix viene de notas cifradas, salidas protegidas y nullifiers.
ni siquiera remotamente tienen la misma forma.
entonces, ¿por qué Moonlight no necesitaría una finalidad con forma de Moonlight y Phoenix algo completamente distinto después de DuskVM?
esa es la parte que seguía mezclando.
estaba asumiendo que el rastro de la cuenta pública de Moonlight y el rastro de las notas cifradas de Phoenix, de algún modo, tendrían que seguir decidiendo la forma de la finalización después de DuskVM también.
aparentemente no.
Moonlight puede mantener el modelo de cuenta. Phoenix puede mantener el modelo de notas. DuskVM puede aceptar lo que venga de cualquiera de los dos lados sin hacer que Moonlight se convierta primero en Phoenix o que Phoenix se “desenvuelva” para volverse Moonlight.
y ahí es donde creo que le estaba dando a DuskDS un trabajo equivocado.
DuskDS no necesita un único modelo compartido de estado de DUSK debajo de todo solo para terminarlos. el lado de Moonlight puede llegar con la progresión de la cuenta pública, el lado de Phoenix puede llegar con el historial de notas cifradas, y Dusk L1 aún puede darle al estado resultante un límite de finalización determinista.
y se siente raro porque seguía esperando que diferentes formas de estado necesitaran también finales diferentes.
pero aparentemente eso era algo que me inventé en la cabeza.
que Phoenix tenga forma de nota y Moonlight tenga forma de cuenta no significa que Dusk necesite dos respuestas distintas para cuando finalmente termine cualquiera de los dos.
aún sigo dándole vueltas a esto: si Moonlight DUSK y Phoenix DUSK llegan a DuskVM con un aspecto completamente distinto, entonces Dusk probablemente también necesite dos formas diferentes de darles final a ambas.
Moonlight está ahí con el saldo de una cuenta pública, el remitente, el receptor, el importe, el nonce avanzando. Phoenix viene de notas cifradas, salidas protegidas y nullifiers.
ni siquiera remotamente tienen la misma forma.
entonces, ¿por qué Moonlight no necesitaría una finalidad con forma de Moonlight y Phoenix algo completamente distinto después de DuskVM?
esa es la parte que seguía mezclando.
estaba asumiendo que el rastro de la cuenta pública de Moonlight y el rastro de las notas cifradas de Phoenix, de algún modo, tendrían que seguir decidiendo la forma de la finalización después de DuskVM también.
aparentemente no.
Moonlight puede mantener el modelo de cuenta. Phoenix puede mantener el modelo de notas. DuskVM puede aceptar lo que venga de cualquiera de los dos lados sin hacer que Moonlight se convierta primero en Phoenix o que Phoenix se “desenvuelva” para volverse Moonlight.
y ahí es donde creo que le estaba dando a DuskDS un trabajo equivocado.
DuskDS no necesita un único modelo compartido de estado de DUSK debajo de todo solo para terminarlos. el lado de Moonlight puede llegar con la progresión de la cuenta pública, el lado de Phoenix puede llegar con el historial de notas cifradas, y Dusk L1 aún puede darle al estado resultante un límite de finalización determinista.
y se siente raro porque seguía esperando que diferentes formas de estado necesitaran también finales diferentes.
pero aparentemente eso era algo que me inventé en la cabeza.
que Phoenix tenga forma de nota y Moonlight tenga forma de cuenta no significa que Dusk necesite dos respuestas distintas para cuando finalmente termine cualquiera de los dos.
