I wanted bring up a topic I believe to be important, and this board seemed like the right place for it.
First I will run through why I believe it to be important, and then I will detail 2 different methods which I believe can achieve that goal.
With this, I refer to not cheap transactions, but transactions that can be executed without holding the chain coin, in this case ICX, at all. This seems to be even more important with BTP and the interoperatability goals of ICX. On Ethereum, the concept is implemented via the
approve method and basically allowing a 3rd party to submit ‘transfer’ transactions on your behalf. This may also be accompanied by the same ‘approve’ method allowing the 3rd party to be renumerated in some other token.
This heading may merely be a headline, but I believe the raw elegence of parties being able to transact via ICX while paying gas fees in the chain coin they are used to and comfortable with, and even moreso, to contrast the fees they are paying now in their current chain coin, with the fees via ICX+BTP again in their current chain coin, to be very alluring.
To actually service these gasless transactions would require services, potentially run by P-Reps or other parties that actually submit these transactions on chain.
dApps can also choose to subsidise transactions, only in their platform token. The permutations are endless.
approve method comes with flaws, most notably, the initial approve requires an on-chain transaction and the limit for transfers is traditionally set to a functionally infinite value. Alternatively setting the correct limits requires a on-chain transaction each time. However it appears that there are some EIPs that may serve as references addressing this exact issue.
Strictly from a cryptographical view, there should be no difference to a message submitted to the chain from the owner of the tokens, versus a 3rd party that comes bearing a signed message from that owner.
I believe this functionality would greatly benefit from core developer support. This is where my lack of familiarity of the inner workings comes up so I would love any corrections here. I believe such a cryptographic operation could be fairly heavy, or even if not, trusting every token creator to implement it correctly seems risky.
I believe a core developer 1st party supplied implementation of that function can greatly increase adoption and trustworthiness of this method.
As an addition to the previous point, with such an implementation, it will be possible to test for the bare minimum in token contracts via static analysis, and this can potentially be marked in the explorer, automatically.
This leads on from the previous idea, and is an even more radical, but (to my untrained eye), incredibly powerful tool. With just the addition of some sort of timeout block field, to me there is no cryptographic reason that we cannot fully decouple the contents of the transaction with the person submitting it. This would allow, at a base level, all methods ever, past, present and future, to be called by submitting the signed transaction payload on behalf of someone else.
No modifications to contracts or logic would be required.
This is a superset of what is required for gasless transactions, and I cannot personally grasp the extent of its applications.
- Order book style methods stored offchain ( I believe some dApps tried this on Ethereum?)
- Time delayed off-chain execution of methods, without the off-chain source having access to private keys.Potentially suitable for hot-cold wallet links, similar to contract wallets.
- Conditional execution of methods with explicit exclusions. It should be possible to sign 2 or more transactions, where only 1 of the many can succeed.
I believe many of the above usecases or functionality are not unique or fresh, and have been tried by building such fuctionality into the contract itself. The raw difference in power from being able to do this natively I think is very desireable, and this automatically gives the functionality the same security confidence as the security of the underlying system itself, as it will be the system itself at that time.
I think this capability will be extremely beneficial when the explosion of tokens comes about due to BTP. It can also allow the best possible onboarding experience, no onboarding at all. I hope this can be taken on by the experienced folk here and improved to be viable.