Solidity output: emit contract creation in factory function

[fare]

We need to track the contracts that are created by the factory, because 1- That solves asynchronous confirmation issues in the JS code 2- That enables doing without an out-of-band messaging mechanism

function make should emit an event with pA and pB, and the created contract address, and all the parameters.

Indeed, the web3.js interface (and underlying geth JSON-RPC API) does not make it possible hard to find the "internal transactions" of a given transaction (as visible e.g. on the blockchain explorer etherscan.io), so we cannot see the internal transaction that creates the contract, and the one that emits an event via msg0.

As a result, the emit of msg0 becomes redundant and can be eliminated. And so #70 could probably be fixed at the same time, too.

[jeapostrophe]

I don't understand why this is necessary. The factory method says return ctc; Where does that value go?

[fare]

The value returned goes nowhere on the blockchain. It is only useful if your contract is called by another contract (via the CALL, or DELEGATECALL, or CALLCODE or STATICCALL opcodes), that can then use the return value—or as an informative debug value when computed via the eth_call JSON RPC API.

To be able to see something on the blockchain using the provided API (and we have no resources to build a better one at this point), it needs to be emitted as an event (via the LOGn opcodes). Actually, any contract created is included on the blockchain (unlike, say, the parameters pA and pB, except in very roundabout ways not fit to read with the existing API), but it is created by an "internal" transaction, and there is unhappily no API to go from the external transaction (on which we have a handle, since we issued it) to the internal transaction, so we cannot rely on that.

In other words, the API is limited, and emitting an event to the log is our only hope to receive data from the blockchain within our limited resources.

[jeapostrophe]

Tabling this for now. In the long run, a factory is really a special kind of infinitely long contract. In the short run, If it turns out we can show that factories are much more efficient than standalone deployments, then it is possible to special case this in the compiler. But it is an optimization that is out-of-scope for demo

[fare]

Well, if you table that, you need an alternative, which is more buck for less bang: either embedding the compiler in the client using e.g. ghcjs, so the client can verify the contract, or more "pragmatically" having the compiler output a template that gets filled in with the parameters (which, if you use solidity, can work by injecting multiple random values as each parameter, and seeing where they land, assuming solidity represents the parameters trivially, which it does).

[fare]

That said, I've seen people systematically using this "decompiling patterns by injecting random data" method for fun and profit to automatically build JIT compilers from C source code patterns... that's cool technology, but not the kind that will be useful in the future of this project, unlike emitting events from a factory.

[fare]

Ah, apparently no need to decompile, as the solidity documentation at https://solidity.readthedocs.io/en/v0.5.3/contracts.html claims that there's a standard trivial encoding:

Internally, constructor arguments are passed ABI encoded after the code of the contract itself, but you do not have to care about this if you use web3.js.

Therefore the template is big code constant followed by an concatenation of the arguments each as a 32-byte chunk.