ECIP-1042: GASPAY

[splix]

Few moments to discuss:

• consume limit, current 0x0fffff
• fair operation cost, current a/4 + 5000
• should it support negative values to do opposite - provide extra gas for current execution

[pyskell]

I have a few initial thoughts:

• It's possible that making the cost of GASPAY to be 1/4th of the transaction cost (+5000) would reduce the usage of it. It also makes calculating the total amount paid to the contract a bit harder.

  • Could GASPAY not just have a fixed rate (21,000 like a normal transaction) or maybe a max cost?

• Is the intention of GASPAY to only be used for donations, or could a contract actually charge for providing a service. For example an oracle contract that charges 5,000 Wei to report the weather.

  • If the latter I wonder if a second proposal may be useful that standardizes an interface for asking a contract what it expects to receive (if anything) via GASPAY.

• Will the GASPAY amount be a global variable that a contract can know at runtime? Such as msg.gaspay.

[pyskell]

I may have misunderstood this, is the micropayment of a/4 + 5000 going to the miner and the rest going to the contract? The intent here being to incentivize miners to adopt while also allowing for a micropayment to a contract?

How does GASPAY provide easier micropayment over calling a contract function and sending a value with the call?

[elaineo]

Couldn't this be implemented in the contract itself, rather than at the EVM level?

[splix]

It can be implemented if a user would provide a value with transaction, but there is not incentive for a user to do that. It makes it complicated from code to pass value down to target contract that can accept tips. I mean, that's supposed to be used by a 3rd party contract, say an oracle that provides current exchange rate to usd, and when your contract reads that value it asks for extra gas as tips for usage.

Need to mention that I agree that that idea is very controversial. I wrote it a long time ago, didn't publish because I was not sure about it. Almost forgot about it, but recalled and decided to publish after yesterday's ETH GasToken. Maybe we can find some use of it

[pyskell]

Would the following design work?

GASPAY itself is opt-in at the contract level and the contract contains some sort of flag or variable that indicates it uses GASPAY (either at the contract level or specific function level)

However, GASPAY is opt-out at the wallet level a user goes to use a wallet like Emerald Wallet or MEW, the wallet detects that GASPAY exists, and opts-in (but provides the user the ability to opt-out if they deselect a check box or other toggle switch).

Now whether GASPAY works as an opcode in this kind of design is another question entirely, perhaps GASPAY could have a single boolean argument that is set at runtime. But this is really a more technical question for others.

The other concern is does any of the remainder gas go to the contract operator? Contract programmers provide a lot of value to ETC so encouraging them as well as miners is definitely beneficial to us in the long term.

Another thought, could we have a standard that doesn't require a new OPCODE? Sort of an opt-out that includes a small value transfer to the operator of a contract? So simply a way for a contract to tell a wallet that it wants to receive a payment. This of course comes with its own concerns (how do miners benefit, can this be misused and request large values, what's the protocol for when a value is requested but not sent, how do we ensure contract creators implement the standard correctly in their contracts).

[tzdybal]

I like the idea in general. I agree that it's a bit controversial to put such thing in EVM, and because of amount of software that needs to be updated.
For me, biggest advantages are:

• it's very easy to use by developers and end-users,
• developers don't need to handle tipping in code. no code = no bugs, and less review is required.

All levels of software needs update (from compilers, to EVM, to frontends like block-explorers) - this require attention from users and developers, but I think that it's not a big problem - clients needs to be updated anyways, because of hardforks, security issues, etc.

I think this change (if accepted) should be piggybacked to other/bigger changes.

[sorpaas]

I think there might be ways to do this "tipping" without protocol-level changes. What I think might also work is we make GASPAY work at ABI level, which results in the same end-user / contract-developer experience, and does not need a hard fork.

The first thing I want to note is that smart contracts on the Ethereum network, if not provided with its ABI, would be nearly impossible to use due to the particular way functions are encoded. Given the mandatory role ABI plays in smart contract interaction, we can add an additional field in a function's signature, and supported wallets can automatically handles "gas tipping" by sending a really small amount of value, even when "payable" field is false. See https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI#json. We add an additional field called "tippable", which specifies an integer value in Wei. When a wallet detects that function signature, it sends the "tippable" value in transaction, but only shows it as "tipping" but not the transferred value. On the contract itself, we can require the value sent is of certain amount, otherwise it "throw".

This GASPAY ABI gives the same experience at least for end-users compared with GASPAY EVM change.

---

And unrelated to the above idea, @pyskell's opt-in at the contract level idea is related to ECIP-1040 (#86), which we may also want to take a look, if we decide to go with that path.

[sorpaas]

I suggest we be more specific on this.

1. If a DELEGATECALL happened, does the payment goes to the parent contract (which has the address field set in context), or the delegated contract?
2. What is the case if we're in CREATE or a contract creation transaction?

[splix]

1. to delegated contract
2. not sure what you mean

[sorpaas]

Is this extra "gas" to contract paid a) at the end of the contract execution (like how miner gas works), or b) paid immediately at the GASPAY opcode? If it is a), does it do anything with refunded gas as well?

[splix]

you mean should it be paid if transaction has failed? no, only if succeeded. but "payment" should be registered at the moment of opcode

[pyskell]

When a wallet detects that function signature, it sends the "tippable" value in transaction, but only shows it as "tipping" but not the transferred value.

Would this mean that a function could be payable or tippable but not both?

[sorpaas]

@pyskell It can be both. You just deduct the tippable amount when showing the transferred values.

[pyskell]

@sorpaas Great, I like this idea a lot then.

[shanejonas]

I like the idea around having small sub-cent payments being the used to reward contracts for providing their service, but that could be maybe solved currently with a convention of payable and assert(msg.value == tx.gasprice * someFairConstant)

[splix]

Regarding ABI level. You can have multiple contracts A -> B -> C. If contract C wants some tip, you shouldn't really put it into your ABI for contract A. You can't even expect it will be same forever, contract C (or a developer of it) can change his mind and increase/decrease/remove/add tip at any moment