There’s no existing protocol we’re trying to preserve compatibility with; I’m saying that if you try and hardcode the verification mechanism into the protocol, it becomes useless as a general-purpose protocol, which makes it more or less useless full-stop.
But a naive developer can do this right now without EIP 3668. They can fetch data from a URL and supply it as an argument to a smart contract function.
If you’re sending a transaction using EIP 3668, it will show up as input on Etherscan.
I’ve made some changes in response to review here, adding support for POST requests back if desired by the gateway, and adding some further security considerations.
Hi @Arachnid
What are the gas implications of this call? This is very crucial as it may allow an abuse of Ethereum if it costs almost zero gas to make this call.
For example instead of balanceOf, how about if I used this for transfer? i.e I call myToken.transfer on L1 and it is passed on as a http://mytoken.io/transfer to my L2. L2 is my private Ethereum network.
I will be able to create an ERC20 token on Ethereum and transfer at will at very low gas costs etc.
As the token contract will actually be executing arbitrary code on my own L2 server. So any contract functionality can be executed on L2 at almost zero gas cost on Ethereum, where Ethereum is used as a “stub server” and all code executed on L2. (This may be a considered a good feature or a serious bug)
The more serious matter is that if updation of data on L2 and simply mirroring it on L1 is allowed, then Ethereum will simply throw exceptions if the L2 server is shut down and all the contracts on L1 will appear to be invalidated.
Hope that makes sense. Interested to know your thoughts.
On another note, I was looking to implement a few nice features on top of ENS using this type of a utility. Will be happy to discuss with you.
Cheers
Rajesh