| 25 min | Discussion | Everyone | - Greg: We have to be able to deduct the cost to execute. I'm asking for a best guess of what it will take to do that.
- Can we deduct the cost to execute at the beginning? No - processes go back and forth.
- The moment the contract interacts with the outside world, it is no longer functional - this is Greg's point, this is why we need an estimator.
- The estimator has to give a reasonable fist blush of the amount of phlogiston that needs to be supplied to kick off execution.
- Simply dumping money in as the contract executes to keep it going isn't reasonable, as this is also a transaction with cost.
- Ethereum throws an out of gas error when a contract runs out of funds for execution.
- Your estimate will have 3 possible outcomes: nails it, money left over, out of funds.
- Kyle - we can arrange it such that recovery isn't a big deal, and if you over pay, you get your money back fairly easily.
- Joe - if you run the risk of throwing an out of gas error, the estimator becomes less important.
- We are going to need dynamic enforcement - and we will need a good story on what happens when your transaction is under-funded.
- If estimation is essentially us trying to run program - and count how much that is going to cost and have them deduct the cost.
- Run the contract locally on the machine - this execution had a cost associated with it. Doing that will give us the lower bound for execution. and now we don’t have to write an interpreter.
- We will need the dynamic enforcement anyway - and this way we can reuse the dynamic enforcement, and people will run the program locally anyway. This will provide an estimate.
- Greg: with respect to synchronization - it will happen on named classes, either the name will fit into this class or it doesn’t. You can create bucket estimates.
- For the estimation you give the estimate. At the time of running you give the actual cost.
- Mike: Get the initial state - get costs for the unit tests and come up with a cost. Run it on a test net on a test net derived from the current state. What does it look like right now according to my local node. A more specific form of simulating the program on a local machine with defined inputs.
- In terms of priority - Kyle - would like to see on what happens when something runs out. that will inform how accurate your estimates need to be. If you can get the rest back you can supply a whole bunch of rev - but that rev would be locked up until program execution is done.
|