Open think-in-universe opened 2 years ago
What you have stated is correct! This is designed explicitly this way, if your implicit account id on aurora
has some tokens (or other special permissions) it is not expected to allow arbitrary contract calls to aurora.call
method.
One possible solution is to add assert_one_yocto() in call() to make sure only full access key can call the function.
Attaching one_yocto_near
won't necessarily solve this problem. The contract itself may attach one yocto near. And more importantly, it is possible that some behaviours requires attaching more than one yocto near! Also if you allow arbitrary calls to this function, in the logic of your code it will be required for you to attach one yocto NEAR which defeats the whole idea of attaching it in the first place.
If you want to allow more restrictive arbitrary cross contract calls from your account, one potential solution would be to only call a proxy contract that will run a delegate call. msg.sender
won't be your implicit account id when it hits the real target contract.
I won't expect allowing arbitrary calls from a NEAR account to become a common pattern.
Attaching
one_yocto_near
won't necessarily solve this problem. The contract itself may attach one yocto near. And more importantly, it is possible that some behaviours requires attaching more than one yocto near! Also if you allow arbitrary calls to this function, in the logic of your code it will be required for you to attach one yocto NEAR which defeats the whole idea of attaching it in the first place.
that's right. maybe we can add assert_one_yocto_or_more()
to ensure at least one yocto is attached, but you can still attach more. how do you think?
I won't expect allowing arbitrary calls from a NEAR account to become a common pattern.
I see. what's the typical scenarios when call()
is used today?
I see. what's the typical scenarios when call() is used today?
I don't think it is being used much yet. But in general as in NEAR, you would use it to call a particular contract with a particular payload that don't put at risk your balance.
Attaching
one_yocto_near
won't necessarily solve this problem. The contract itself may attach one yocto near. And more importantly, it is possible that some behaviours requires attaching more than one yocto near! Also if you allow arbitrary calls to this function, in the logic of your code it will be required for you to attach one yocto NEAR which defeats the whole idea of attaching it in the first place.
There is a definite requirement to have a safe and express way for transferring assets from implicit account back to its near corresponding near account. That would allow near native users to safely and implicitly enjoy aurora contracts service.
The think-in-universe solution (with one or more yocto near deposit) may enhance the security but may sacrifice some user experience (from my side, I won't expect jumping to near wallet when the action is only to transfer assets among my own accounts). Could we figure out an interface that can be called using access key but only allow token transfer to the specific near account id, that is, the one that implicit account generated from.
I'm building one demo of swap wNEAR to USDT on Trisolaris on Aurora with your NEAR account, and noticed one potential security risk if a good number of applications tries to use the
call()
method on Aurora Engine. (Checkout the demo here: https://github.com/think-in-universe/aurora-defi-on-near (live version: https://think-in-universe.github.io/aurora-defi-on-near/))Because with the
call()
method on Aurora Engine, your NEAR account is able to control the assets of the virtual aurora account mapped from your NEAR account, this gives thecall()
method really high privilege even with a function call key.For example, if someone is using the demo I have built here, and created a function call for
aurora
contract, and if the app is evil, and steals the created function call from local storage, then the attacker is able to move the assets from the user's virtual aurora account to anywhere.So if the practice of calling Aurora contract with the NEAR account is adopt widely, the risk will be quite high. One possible solution is to add
assert_one_yocto()
incall()
to make sure only full access key can call the function. However, I'm not sure whether this will impact the current usage ofcall()
in other scenarios.