Две функции отправителя в смарт-контрактах Dusk привлекли мое внимание: caller() и public_sender().
Они звучат как два способа ответить на один и тот же вопрос — кто инициировал это действие, — но при этом могут указывать на разных участников. Этот нюанс важен, потому что Dusk стремится вывести финансовые рынки onchain с организациями, имеющими лицензии ЕС, где авторизация должна переживать более сложные взаимодействия контрактов, не теряя след за первоначальным участником. caller() идентифицирует контракт, который делает непосредственный вызов, тогда как public_sender() все еще может ссылаться на учетную запись Moonlight, которая начала транзакцию.
Я пока не знаю, будут ли контракты Dusk последовательно авторизовать пользователя, который действительно инициировал действие, или же добавление промежуточных контрактов может незаметно изменить ту личность, которую логика авторизации «видит». Механизмы, за которыми стоит следить, просты: когда контракты полагаются на caller(), когда полагаются на public_sender(), и что происходит, когда посредине оказываются batchers или forwarders.
То, что транзакция выполняется успешно, недостаточно, чтобы ответить на этот вопрос. Более сильная проверка — будут ли те же правила авторизации по-прежнему ссылаться на предполагаемого участника даже при изменении пути выполнения.
Меня гораздо меньше волнует, через скольких промежуточных контрактов проходит действие, чем то, разрешается ли авторизация все так же на того участника, который фактически инициировал его.
Это важно, потому что добавление посредника может изменить то, кого видит контракт, не меняя того, кто реально авторизовал действие.
Вопрос в том, сможет ли Dusk добавить более компонуемые пути выполнения, не делая авторизацию зависимой от того, какой именно контракт оказался посередине.
Я слежу за тем, как используются caller() и public_sender() по мере развития этих шаблонов.
@Dusk $DUSK #dusk
Они звучат как два способа ответить на один и тот же вопрос — кто инициировал это действие, — но при этом могут указывать на разных участников. Этот нюанс важен, потому что Dusk стремится вывести финансовые рынки onchain с организациями, имеющими лицензии ЕС, где авторизация должна переживать более сложные взаимодействия контрактов, не теряя след за первоначальным участником. caller() идентифицирует контракт, который делает непосредственный вызов, тогда как public_sender() все еще может ссылаться на учетную запись Moonlight, которая начала транзакцию.
Я пока не знаю, будут ли контракты Dusk последовательно авторизовать пользователя, который действительно инициировал действие, или же добавление промежуточных контрактов может незаметно изменить ту личность, которую логика авторизации «видит». Механизмы, за которыми стоит следить, просты: когда контракты полагаются на caller(), когда полагаются на public_sender(), и что происходит, когда посредине оказываются batchers или forwarders.
То, что транзакция выполняется успешно, недостаточно, чтобы ответить на этот вопрос. Более сильная проверка — будут ли те же правила авторизации по-прежнему ссылаться на предполагаемого участника даже при изменении пути выполнения.
Меня гораздо меньше волнует, через скольких промежуточных контрактов проходит действие, чем то, разрешается ли авторизация все так же на того участника, который фактически инициировал его.
Это важно, потому что добавление посредника может изменить то, кого видит контракт, не меняя того, кто реально авторизовал действие.
Вопрос в том, сможет ли Dusk добавить более компонуемые пути выполнения, не делая авторизацию зависимой от того, какой именно контракт оказался посередине.
Я слежу за тем, как используются caller() и public_sender() по мере развития этих шаблонов.
@Dusk $DUSK #dusk
