Dois usos de funções de remetente em contratos inteligentes do Dusk chamaram minha atenção: caller() e public_sender().
Elas soam como duas maneiras de responder à mesma pergunta, quem iniciou esta ação, mas podem apontar para atores diferentes. Essa distinção importa à medida que o Dusk avança para trazer mercados financeiros onchain com instituições licenciadas pela UE, onde a autorização precisa sobreviver a interações mais complexas de contratos sem perder de vista o ator original. caller() identifica o contrato que faz a chamada imediata, enquanto public_sender() ainda pode apontar de volta para a conta Moonlight que iniciou a transação.
O que eu ainda não sei é se os contratos do Dusk vão autorizar de forma consistente o usuário que realmente iniciou uma ação, ou se adicionar contratos intermediários pode, de maneira silenciosa, mudar qual identidade a lógica de autorização enxerga. Os mecanismos a observar são simples: quando os contratos dependem de caller(), quando dependem de public_sender(), e o que acontece uma vez que batchers ou forwarders ficam no meio.
Uma transação executando com sucesso não basta para responder isso. O teste mais forte é se as mesmas regras de autorização ainda apontam de volta para o ator pretendido mesmo quando o caminho de execução muda.
Eu me importaria menos com quantos contratos intermediários uma ação atravessa do que com a questão de a autorização ainda resolver para o ator que de fato a iniciou.
Isso importa porque adicionar um intermediário pode mudar quem um contrato enxerga sem alterar quem de fato autorizou a ação.
A pergunta é se o Dusk consegue adicionar mais caminhos de execução componíveis sem fazer a autorização depender de qual contrato, por acaso, estiver no meio.
Estou acompanhando como caller() e public_sender() são usados conforme esses padrões evoluem.
@Dusk $DUSK #dusk
Elas soam como duas maneiras de responder à mesma pergunta, quem iniciou esta ação, mas podem apontar para atores diferentes. Essa distinção importa à medida que o Dusk avança para trazer mercados financeiros onchain com instituições licenciadas pela UE, onde a autorização precisa sobreviver a interações mais complexas de contratos sem perder de vista o ator original. caller() identifica o contrato que faz a chamada imediata, enquanto public_sender() ainda pode apontar de volta para a conta Moonlight que iniciou a transação.
O que eu ainda não sei é se os contratos do Dusk vão autorizar de forma consistente o usuário que realmente iniciou uma ação, ou se adicionar contratos intermediários pode, de maneira silenciosa, mudar qual identidade a lógica de autorização enxerga. Os mecanismos a observar são simples: quando os contratos dependem de caller(), quando dependem de public_sender(), e o que acontece uma vez que batchers ou forwarders ficam no meio.
Uma transação executando com sucesso não basta para responder isso. O teste mais forte é se as mesmas regras de autorização ainda apontam de volta para o ator pretendido mesmo quando o caminho de execução muda.
Eu me importaria menos com quantos contratos intermediários uma ação atravessa do que com a questão de a autorização ainda resolver para o ator que de fato a iniciou.
Isso importa porque adicionar um intermediário pode mudar quem um contrato enxerga sem alterar quem de fato autorizou a ação.
A pergunta é se o Dusk consegue adicionar mais caminhos de execução componíveis sem fazer a autorização depender de qual contrato, por acaso, estiver no meio.
Estou acompanhando como caller() e public_sender() são usados conforme esses padrões evoluem.
@Dusk $DUSK #dusk
