Addressing code initialisation

[JakeOShannessy]

NB: The eWASM spec as I understand it, loosely uses the same procedure for this as EVM1. While it may be a little less susceptible, I think the implications are the same.

Currently we must account for the fact that the code we receive in the beaker-preprocessor is initialisation code. For example, in Solidity code, initialisation code is preprended to the start of a contract. Hardcoded within this initialisation code is the length of the byte, which we need to update whenever we perform transformation. This can be done by recognising Solidity init code and doing the update (this is what we do at time of writing) but this will only work when the contract strictly follows that convention.

The problem is, no matter how many "init procedures" we recognise, there can be arbitrarily many and arbitrarily complex, producing arbitrary bytecode. This is a serious problem for validation. If we validate some code that includes storage protection, it is trivial for the init code to later overwrite/delete that protection (in an infinite number of ways, it cannot be analysed for).

I therefore believe that we when we validate code to determine it's capabilities, we cannot allow for arbitrary init code.

This is an OK compromise. It simply means that any code written for BeakerOS must satisfy certain init requirements. However, the challenge comes in specifying those requirements. Currently the beaker-preprocessor code recognises Solidity init, without a constructor. This is only optionally currently but needs to be enforced.

If we can't say exactly what the initialisation code is doing, then we cannot say anything about what the contract can do

[JakeOShannessy]

As of c9f1eed the preprocessor will only transform a specific recognised init code or throw an error. transformDeployed is also included in this commit to be used in testing. It ignore initialisation code completely.

[JakeOShannessy]

Jacob raised a good point in that once the contract is on chain, there is no initialisation code and we can verify everything fully. This means we could validate arbitrary code if we included deployment to the blockchain as part of the toolchain.

[Latrasis]

@JakeOShannessy: Do you want to documenting this?

[JakeOShannessy]

We currently haven't addressed initialisation in the Beaker spec, it might be worth thinking about.

[JakeOShannessy]

Let's change the workflow around procedure deployment. Verification will only be performed on deployed contracts. If we want to add a procedure to the kernel, first we deploy it (running any constructor code) then we verify that code, and add it to the procedure table if it passes verification.

We can either make this two transactions (i.e. the contract must be deployed separately by the developer) or a single transaction, where the kernel handles deployment as well.