Me llamaron la atención dos funciones de remitente en los contratos inteligentes de Dusk: caller() y public_sender().
Suena como si fueran dos formas de responder a la misma pregunta, quién inició esta acción, pero pueden apuntar a actores diferentes. Esa distinción importa mientras Dusk impulsa llevar los mercados financieros onchain con instituciones con licencia de la UE, donde la autorización tiene que resistir interacciones de contratos más complejas sin perder de vista al actor original. caller() identifica el contrato que realiza la llamada inmediata, mientras que public_sender() aún puede señalar de vuelta a la cuenta de Moonlight que inició la transacción.
Lo que todavía no sé es si los contratos de Dusk autorizarán de manera consistente al usuario que realmente inició una acción, o si al añadir contratos intermedios se puede cambiar silenciosamente qué identidad ve la lógica de autorización. Las mecánicas que vale la pena observar son sencillas: cuándo los contratos dependen de caller(), cuándo dependen de public_sender() y qué ocurre una vez que los batchers o forwarders quedan en medio.
Que una transacción se ejecute correctamente no es suficiente para responder a eso. La prueba más sólida es si las mismas reglas de autorización siguen apuntando al actor previsto incluso cuando cambia la ruta de ejecución.
Me importa menos cuántos contratos intermedios atraviesa una acción que si la autorización sigue resolviéndose al actor que realmente la inició.
Eso importa porque añadir un intermediario puede cambiar a quién ve un contrato sin cambiar quién autorizó realmente la acción.
La pregunta es si Dusk puede añadir más rutas de ejecución componibles sin hacer que la autorización dependa de cualquiera de los contratos que casualmente estén en el medio.
Estoy observando cómo se usan caller() y public_sender() a medida que esos patrones se desarrollan.
@Dusk $DUSK #dusk
Suena como si fueran dos formas de responder a la misma pregunta, quién inició esta acción, pero pueden apuntar a actores diferentes. Esa distinción importa mientras Dusk impulsa llevar los mercados financieros onchain con instituciones con licencia de la UE, donde la autorización tiene que resistir interacciones de contratos más complejas sin perder de vista al actor original. caller() identifica el contrato que realiza la llamada inmediata, mientras que public_sender() aún puede señalar de vuelta a la cuenta de Moonlight que inició la transacción.
Lo que todavía no sé es si los contratos de Dusk autorizarán de manera consistente al usuario que realmente inició una acción, o si al añadir contratos intermedios se puede cambiar silenciosamente qué identidad ve la lógica de autorización. Las mecánicas que vale la pena observar son sencillas: cuándo los contratos dependen de caller(), cuándo dependen de public_sender() y qué ocurre una vez que los batchers o forwarders quedan en medio.
Que una transacción se ejecute correctamente no es suficiente para responder a eso. La prueba más sólida es si las mismas reglas de autorización siguen apuntando al actor previsto incluso cuando cambia la ruta de ejecución.
Me importa menos cuántos contratos intermedios atraviesa una acción que si la autorización sigue resolviéndose al actor que realmente la inició.
Eso importa porque añadir un intermediario puede cambiar a quién ve un contrato sin cambiar quién autorizó realmente la acción.
La pregunta es si Dusk puede añadir más rutas de ejecución componibles sin hacer que la autorización dependa de cualquiera de los contratos que casualmente estén en el medio.
Estoy observando cómo se usan caller() y public_sender() a medida que esos patrones se desarrollan.
@Dusk $DUSK #dusk
