How does Transactions work in Ethereum Virtual Machine?

Question

While reading the transactions sections of EVM documentation many questions raised in my head:

If the target account is not set (the transaction does not have a recipient or the recipient is set to null), the transaction creates a new contract (The payload should be the code of the contract, correct ? ). As already mentioned, the address of that contract is not the zero address but an address derived from the sender and its number of transactions sent (the “nonce”) (But Doesn't the nonce represent a number that combined with block data provides the hash of the next block ? ) . The payload of such a contract creation transaction is taken to be EVM bytecode and executed (Do they mean the compiled bytecode of the contract ? and what do they mean by "and executed" ? ) . The output data of this execution is permanently stored as the code of the contract. This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code when executed (Which code returns what ? We have contract code and the compiled contract I missed this one entirely ) .

Sorry for embedding the question the quote but I think this is for better understanding what I really when asking the questions.

Answer 1

I believe that https://programtheblockchain.com/posts/2018/01/09/how-smart-contract-deployment-works/ answers all of these questions.

Regarding the code that's deployed:

The data field of a contract deployment transaction is code to be executed during contract initialization. It is not the code that is executed on subsequent transactions sent to the contract. That code is returned by the initialization code. Essentially, the code in the data field is a program that is going to write a program that gets deployed as a smart contract. Although that sounds fairly open-ended and complex, in practice it is typically quite straightforward. The standard initialization code generated by the Solidity compiler does the following:

1. Runs the code in the contract’s constructor, setting storage values, etc.
2. Copies the code for the rest of the contract into memory and returns it. The code to be copied is simply appended to the constructor’s code in the data field.

Constructor parameters are handled similarly. They are stored last in the data field, and the initialization code reads them from there.

Regarding the nonce, it's a per-account nonce, not the nonce used in the block headers:

Once a contract is deployed, it is referenced by its address, which is guaranteed to be unique. Computing the address requires only the address of the sender account and the sender’s nonce.