Changes for Economic Protocol scenario 3 - "contract pays for gas"

[miloszm]

Changes for Economic Protocol scenario 3 - "contract pays for gas" and "contract earns fee" parts

Implements issues #350 and #353

[ureeves]

I've got some things I''d like to see some work on, and also some broader remarks.

My main concern this mechanism's implementation is that the contract must remember to always set the value of the economic buffer at the end of a function it exports. This because otherwise the previous value will be used. This is and of itself is not a problem, but it does become an issue when we don't make this clear/ergonomic to the user.

We can choose one of two options afaics:

• Have the host set the "default" value every time the contract is called, erasing the need for the contract to do it.
• Modify the wrap_call functions to make this ergonomic to the user.

There's other things interspersed below, but one thing I'd like to mention is an aesthetic concern - what do we name what is now called "buffer b"? Certainly we don't want to just keep that name. Maybe "economic buffer"?

[miloszm]

Re: My main concern this mechanism's implementation is that the contract must remember to always set the value of the economic buffer at the end of a function it exports. This because otherwise the previous value will be used. This is and of itself is not a problem, but it does become an issue when we don't make this clear/ergonomic to the user.

Problem of previous value is taken care of, but only for the top call (in call_inner, see session.rs line 765). I should fix it for ICC calls, good catch.

As for other remarks, they are good remarks IMO and I will follow on most of them. Not sure about CallReceipt remark yet, will need to analyse it more and provide feedback after that.

[miloszm]

I addressed all Ed's review suggestions except for 2: (please also see the comments above)

1. left set_allowance and set_charge as separate methods
2. left setting spent in call_inner
   With 1) I am open to suggestions, while with 2) I evaluated the suggestion and concluded that it is a good suggestion - we need to pass spent along with allowance and charge downstream via CallReceipt and let block generator have access to the original spent - otherwise block generator could make wrong decisions and pack too many "free" transactions into one block. Block. generator does not care who paid for the transaction, but it does care about actual spent and a price, thus we need to pass this information to it unchanged. I will enrich the CallReceipt with data about allowance and charge given.

[ureeves]

I think we should introduce an easy way for the contract to set the economic mode after each exposed function. My proposal would be to have it be done using the wrap_call helpers that we already have.

This is because the economic buffer is copied from any contract called, and then passed along. To make sure that no contract makes a decision on how to spend the funds for another, I think this should definitely be provided.

[ureeves]

LGTM!