Lo que finalmente encajó en mí sobre Moonlight y Phoenix en DuskVM es que los distintos modelos de estado no necesitan modelos de finalidad distintos.
Moonlight llega con un rastro público de cuentas: balances, remitente, destinatario, cantidad, nonce.
Phoenix llega mediante notas cifradas, salidas protegidas y anuladores.
Seguí asumiendo que esas dos formas de alguna manera requerirían dos maneras diferentes de llegar a la finalidad después de DuskVM.
Pero ese no es realmente el trabajo de DuskDS.
Moonlight puede seguir con forma de cuenta. Phoenix puede seguir con forma de nota. DuskVM puede aceptar ambas sin obligar a una a convertirse en la otra, mientras que Dusk L1 aún ofrece a ese estado resultante un límite de finalidad determinista.
Así que el error fue asumir que distintas representaciones de estado necesitan distintos finales.
No los necesitan.
Dusk puede permitir que Moonlight y Phoenix sigan siendo fundamentalmente distintos por debajo y, aun así, dar a ambos la misma respuesta a la única pregunta que importa al final:
¿cuándo es final este estado?
#dusk $DUSK @Dusk
Moonlight llega con un rastro público de cuentas: balances, remitente, destinatario, cantidad, nonce.
Phoenix llega mediante notas cifradas, salidas protegidas y anuladores.
Seguí asumiendo que esas dos formas de alguna manera requerirían dos maneras diferentes de llegar a la finalidad después de DuskVM.
Pero ese no es realmente el trabajo de DuskDS.
Moonlight puede seguir con forma de cuenta. Phoenix puede seguir con forma de nota. DuskVM puede aceptar ambas sin obligar a una a convertirse en la otra, mientras que Dusk L1 aún ofrece a ese estado resultante un límite de finalidad determinista.
Así que el error fue asumir que distintas representaciones de estado necesitan distintos finales.
No los necesitan.
Dusk puede permitir que Moonlight y Phoenix sigan siendo fundamentalmente distintos por debajo y, aun así, dar a ambos la misma respuesta a la única pregunta que importa al final:
¿cuándo es final este estado?
#dusk $DUSK @Dusk