el atardecer tiene dos entornos de contrato, pero lo interesante no es que haya dos.
duskvm se ejecuta directamente en la l1; la ejecución del contrato y la liquidación de dusk ocurren en el mismo lugar. duskevm
parece separado a simple vista: solidez, carteras evm, su propio rpc, pero una transacción de duskevm en realidad pasa por cuatro etapas antes de quedar realmente liquidada. primero va al secuenciador, se incluye en un bloque de l2, el.
el batcher publica esos datos de transacción en duskds y solo entonces los compromisos de estado y las pruebas de fallos conectan el estado resultante nuevamente con la liquidación en duskds.
es fácil pasar por alto que la inclusión y la liquidación son.
explícitamente dos etapas diferentes aquí, no una. una transacción puede aparecer rápido en un bloque de l2 mientras que la etapa de liquidación real aún está alcanzándola.
esa distinción importa más de lo que suena.
los documentos advierten específicamente contra inferir la finalidad a partir del tiempo transcurrido y dicen que las apps que mueven valor entre duskevm y la l1 deberían comprobar el estado del protocolo o de la billetera en su lugar. no esperaba que ese hueco entre inclusión y.
setlement se señalara de forma tan directa; se siente como exactamente el lugar donde se esconderían los bugs si un equipo asumiera que una transacción rápida ya es definitiva.
si estuvieras construyendo sobre duskevm, ¿revisarías el estado de liquidación antes o después de mostrarle al usuario una pantalla de éxito??
#dusk @Dusk $DUSK
duskvm se ejecuta directamente en la l1; la ejecución del contrato y la liquidación de dusk ocurren en el mismo lugar. duskevm
parece separado a simple vista: solidez, carteras evm, su propio rpc, pero una transacción de duskevm en realidad pasa por cuatro etapas antes de quedar realmente liquidada. primero va al secuenciador, se incluye en un bloque de l2, el.
el batcher publica esos datos de transacción en duskds y solo entonces los compromisos de estado y las pruebas de fallos conectan el estado resultante nuevamente con la liquidación en duskds.
es fácil pasar por alto que la inclusión y la liquidación son.
explícitamente dos etapas diferentes aquí, no una. una transacción puede aparecer rápido en un bloque de l2 mientras que la etapa de liquidación real aún está alcanzándola.
esa distinción importa más de lo que suena.
los documentos advierten específicamente contra inferir la finalidad a partir del tiempo transcurrido y dicen que las apps que mueven valor entre duskevm y la l1 deberían comprobar el estado del protocolo o de la billetera en su lugar. no esperaba que ese hueco entre inclusión y.
setlement se señalara de forma tan directa; se siente como exactamente el lugar donde se esconderían los bugs si un equipo asumiera que una transacción rápida ya es definitiva.
si estuvieras construyendo sobre duskevm, ¿revisarías el estado de liquidación antes o después de mostrarle al usuario una pantalla de éxito??
#dusk @Dusk $DUSK