Might want a cap on Tx gas distributed or it would encourage gas inefficient contracts?
Is it still happening? Considering there is now a public good funding chain. I think that is a good solution.
1 Like
Maybe a good option is just GAS_TO_ETH opcode. It doesn’t require protocol changes, just a new opcode, and the semantics are clear. It also prevents the capture issues @owocki was referring to because the contract author sets any fee collection mechanism rather than it being governed by the protocol.
Lastly, it is also clean from a UX perspective, because users are already used to paying gas + there is already UX infrastructure around paying gas, and the concept of paying “slightly more” to the contract author is probably something that’s pretty understandable.
Would adding the payable modifier to a smart contract function call in an EVM chain be sufficient to accomplish what Canto is trying to do for public goods? This is already available in Solidity today, and Devs can opt in to add the modifier to any function as they please (as opposed to enforcing it for everything).
Nothing wrong with funding public goods (and we should definitely find ways to make them sustainable) but it feels to me that enforcing this at the L2 layer directly is not the best approach.
It’ll be cool to see an L2 experimenting with this EIP.
A couple of questions:
If I understand correctly the reward is paid to the current frame’s contract unless it calls SETREVENUERECIPIENT. Doesn’t it mean that all existing contracts end up accumulating eth unexpectedly? If the contract was not meant to receive eth, it might not have a way to withdraw it so this eth is effectively burnt. Would it make sense to allocate the reward to the last SETREVENUERECIPIENT-caller rather than have a default which would result in burning eth?
Sending the reward to an account set by SETREVENUERECIPIENT is effectively a call (with value) to a potentially cold account. Normally this would cost 9300 gas per account. Could even be 34300 gas per account if SETREVENUERECIPIENT points to a random empty account. If I understand correctly, these transfers are free in this EIP. Is there a DoS risk?
I.e. a transaction makes N calls to contracts that do RANDOM,GAS,ADD,SETREVENUERECIPIENT,RETURN. Cost to the attacker: 21000+2619N (N cold calls to such contracts) plus the one-time cost of deploying these contracts - but they can then be reused every block. Unpaid cost of reward distribution: 34300N. The “damage” is more than 10x the attack cost.
Would it make sense to deduct the cost of distribution from each account, and not reward if it goes down to zero or below? I think it would eliminate any DoS vector since the rewards pay for themselves and accounts are never touched if not fully paid.
Another interesting side effect - STATICCALL is no longer fully static because it can change the state at the end of the transaction - increasing the balance of a chosen account. Is that a problem? I’m not sure it has any implications, just changes semantics.
yes it is.
we are looking at building out an op-geth implementation of the EIP
more details in the telegram.