#dusk decepcionado mi rango no mejora probé absolutamente de todo ahora ya estoy listo $TREE n $HEMI ¿son la estrella en ascenso de hoy?
Pasé la tarea del Crepúsculo excavando en una actualización de ingeniería y me quedé atascado en un mecanismo de transferencia en el que genuinamente no había pensado: un contrato inteligente no tiene que aceptar DUSK solo porque otro contrato se lo envíe.
Dusk agregó transfer_to_contract, donde un contrato puede transferir DUSK a otro y adjuntar datos arbitrarios a la llamada. El contrato receptor puede inspeccionar esos datos y aceptar o rechazar la transferencia.
Parece algo pequeño. No lo es.
Un modelo de transferencia normal trata el dinero que se recibe como algo pasivo. Si alguien envía valor a una dirección, el valor llega. Aquí, recibir puede convertirse en parte de la lógica de la aplicación. Un contrato puede, en efecto, decir “acepto este pago solo si la información adjunta cumple mis reglas”.
Volví una y otra vez a lo que esto significa para los flujos financieros. Un pago podría necesitar corresponder a una instrucción, estado o condición en particular antes de que la aplicación receptora deba tratarlo como válido. En lugar de aceptar fondos primero y averiguar para qué eran después, el receptor puede hacer que la aceptación sea parte de la propia ejecución.
Eso es más limpio, pero también significa que los pagos ya no son universalmente neutrales. El contrato de destino tiene capacidad de decisión sobre si la transferencia se completa, y una lógica de aceptación mal diseñada puede rechazar flujos perfectamente legítimos.
Lo extraño es que la parte interesante no es que los contratos puedan enviar dinero. Eso se esperaba. Lo interesante es que el lado receptor obtiene un voto.
Entonces, ¿la aceptación explícita del receptor es la primitiva correcta para contratos financieros que necesitan pagos condicionales, o permitir que los contratos rechacen un valor entrante agrega complejidad a algo que las transferencias deberían mantener simple??
#dusk $DUSK @Dusk
Pagos condicionales de DUSK: ¿mejor primitiva o complejidad extra?
Pasé la tarea del Crepúsculo excavando en una actualización de ingeniería y me quedé atascado en un mecanismo de transferencia en el que genuinamente no había pensado: un contrato inteligente no tiene que aceptar DUSK solo porque otro contrato se lo envíe.
Dusk agregó transfer_to_contract, donde un contrato puede transferir DUSK a otro y adjuntar datos arbitrarios a la llamada. El contrato receptor puede inspeccionar esos datos y aceptar o rechazar la transferencia.
Parece algo pequeño. No lo es.
Un modelo de transferencia normal trata el dinero que se recibe como algo pasivo. Si alguien envía valor a una dirección, el valor llega. Aquí, recibir puede convertirse en parte de la lógica de la aplicación. Un contrato puede, en efecto, decir “acepto este pago solo si la información adjunta cumple mis reglas”.
Volví una y otra vez a lo que esto significa para los flujos financieros. Un pago podría necesitar corresponder a una instrucción, estado o condición en particular antes de que la aplicación receptora deba tratarlo como válido. En lugar de aceptar fondos primero y averiguar para qué eran después, el receptor puede hacer que la aceptación sea parte de la propia ejecución.
Eso es más limpio, pero también significa que los pagos ya no son universalmente neutrales. El contrato de destino tiene capacidad de decisión sobre si la transferencia se completa, y una lógica de aceptación mal diseñada puede rechazar flujos perfectamente legítimos.
Lo extraño es que la parte interesante no es que los contratos puedan enviar dinero. Eso se esperaba. Lo interesante es que el lado receptor obtiene un voto.
Entonces, ¿la aceptación explícita del receptor es la primitiva correcta para contratos financieros que necesitan pagos condicionales, o permitir que los contratos rechacen un valor entrante agrega complejidad a algo que las transferencias deberían mantener simple??
#dusk $DUSK @Dusk
Pagos condicionales de DUSK: ¿mejor primitiva o complejidad extra?
🔘 Receiver acceptance makes s
100%
🔘 Transfers should stay simpl
0%
🔘 Useful for financial apps
0%
🔘 Depends on contract design
0%
5 Votos • Votación cerrada