Merge contract creation and first message

[fare]

In some compiler pass before code emission, merge contract creation and sending of first message, so the constructor also handles the first message.

This will save on the order of ~700 gas (700 cost of an extra call, plus some administrative stack manipulation; the cost of massaging arguments to and from memory is about the same whether it's in one or two messages).

This is not high priority, as there are many more important problems or sources of waste. But it is probably a nice hack to introduce a new employee to the compiler.

[jeapostrophe]

Right now, the code goes make -> constructor -> msg0_m. You are saying that all this code should be inlined into make and this is because the function calls are slower?

make (in the factory) doesn't have access to the internal state of the contract, so we must at least have make -> constructor, right?

[fare]

You got it right.

The manual contract shows how it can be done.

[jeapostrophe]

Can you explain why it is necessary to have the factory? Why don't we just deploy the contract freshly for each game?

[fare]

We could indeed have a new contract for each game, but 1- it would cost more gas, 2- the code to check that the correct contract was used would be more complex, and 3- it would be much more hassle to listen to the chain to discover contracts, so we'd need an offchain messaging mechanism that would put us back a few weeks.

[fare]

When we deploy on Bitcoin and its descendants, the situation will be different. There will be no factory, and indeed doing it the way you say will make more sense.

[fare]

Checking that the correct code was used would be a matter of generating a template where the parameters are filled in, and pattern matching against this template. Which is easier to do if we produce EVM bytecode directly, though we could have Solidity generate variants with parameters changing according to easily recognizable values, and deduce where the parameters are.

The event log has a much better interface, that allows you to search for events matching a given filter, so you don't have to process each and every transaction with a comb to find the one you want. Also, the events only appear if the transaction did go through, so you don't have to precisely emulate the EVM and its gas behavior to ascertain that it all worked out, and you don't need to recursively evaluate everything to find contracts that were indirectly created by other contracts. Also concerns we won't face on Bitcoin.

[fare]

In other words, Bitcoin's UTXO model makes the state apparent, so it's easy (though still a hassle) to pattern match the state of a UTXO against the desired script template. With Ethereum's account model, there is a lot of hidden state and opaque transactions, and the event log is how users watching the chain can ascertain what did or didn't happen. And so we need to emit events to the log anytime anything happens.

[fare]

(These are excellent questions, and it took me months to figure out how things did or didn't work.)

[jeapostrophe]

We could indeed have a new contract for each game, but 1- it would cost more gas, 2- the code to check that the correct contract was used would be more complex, and 3- it would be much more hassle to listen to the chain to discover contracts, so we'd need an offchain messaging mechanism that would put us back a few weeks.

1 --- Why does it cost more gas? When the Factory constructs the instance for the game, isn't that the same thing as deploying?

2 --- There is a lot of existing machinery to check that contract source at an address corresponds to certain source code. We can certainly just check that the bytecode is the same as the bytecode we generated.

3 --- At this point, whether we have a factory or not, the contract addresses are communicated out-of-band (i.e. copy & paste in the demo.)

[fare]

It's worth it measuring how much more or less gas it costs to use a factory:

• with the usual factories that Solidity gives you, you build the init code for the new contract in memory using bytes from your code, then create it with the 1.6% tax.
• with a direct creation, you use new bytes, that each cost more to create, but you don't pay the 1.6% tax
• unless your code is less than 800 bytes or so, you start paying quadratic cost for that big array of bytes you created, which may dominate the costs, anyway. Better reuse memory when you cons the event, then.
• If we use a proxy factory, we only pay the quadratic memory cost once, and each new contract can be quite small in size.
• using lots of smaller indirect library contracts for the various rare independent unhappy paths, we can save a lot on gas for the happy path and contract creation, with the bad guys paying squared 3.2% tax.

[jeapostrophe]

By my reading, this means the answer is "We have no idea if a factory is really necessary, but it seems like it might". Given that it is definitely more complicated and the answer is not clear, I say delay until the future.

[jeapostrophe]

Tabling this for now. In the long run, when there are choices, it makes sense for the contract to exist and have two different possible first messages. Doing this now would be more work that might need to be reverted.

[fare]

If the choice is made by the first participant, then it should probably be merged as "first message" using a sum type. If the choice is made by another participant, then it's already a second message.

In the short run, we should probably focus on two-player interactions, anyway, at which point standard game semantics apply.