In Ethereum, a tx that deploys a new smart contract contains a blob of EVM bytecode in its data field. This code is executed, and its output is what is saved as the bytecode of the newly-deployed contract. In particular, this bytecode can do anything that any smart contract can do inside EVM, including reading and writing state, deploying other code, etc. It's fully turing complete (within the limits of the provided gas).
For specifics, see section 7 in the Eth yellow paper, and these additional resources:
Do we want template deploy transactions to be fully dynamic and turing complete, after Ethereum's fashion? Why not?
Do we want a strict dichotomy between app (smart contract) spawn transactions and template deploy transactions, and between templates and spawned app instances? Or do we want to allow any deployed app to spawn new child apps?
In Ethereum, a tx that deploys a new smart contract contains a blob of EVM bytecode in its
datafield. This code is executed, and its output is what is saved as the bytecode of the newly-deployed contract. In particular, this bytecode can do anything that any smart contract can do inside EVM, including reading and writing state, deploying other code, etc. It's fully turing complete (within the limits of the provided gas).For specifics, see section 7 in the Eth yellow paper, and these additional resources:
Do we want template deploy transactions to be fully dynamic and turing complete, after Ethereum's fashion? Why not?
Do we want a strict dichotomy between app (smart contract) spawn transactions and template deploy transactions, and between templates and spawned app instances? Or do we want to allow any deployed app to spawn new child apps?
CC @avive, @YaronWittenstein