Forbid conditional contract creation about fuel-specs HOT 9 CLOSED

Wait though, so your saying we cant have contract factories in our system?

What does the replacement look like for this functionality?

Practically, I can still create contracts with contracts using restrictive programming and new contract UTXO's of some kind right?

from fuel-specs.

After doing some reading and discussing around contract factories: no, this change wouldn't mean we can't have contract factories.

Contract factories are on-chain contracts that can produce new contracts. Essentially, factory_logic(input, factory_logic.state) -> new_bytecode. We note that the factory logic (which is just code), input, and the factory contract's state are all known at compile time of the new contract. Blockchains have no secrets, so we can simply download the data and simulate it locally to produce the final bytecode ourselves, then deploy the bytecode.

There is exactly one case that we can't reproduce directly: atomic conditions on state, where the deployment parameters of the contract factory are dependent on some invariant of the factory's state. This can be accomplished with a level of indirection, by first "locking in" the state (e.g. a deposit amount), then deploying the contract and assigning the locked state to the contract.

Overall, this will probably be more conducive to better programming and sustainability, since it will discourage frivolous use of state (which will be very expensive).

from fuel-specs.

@Arachnid I know this is a little separate from previous conversation, but any thoughts on the proposed above?

from fuel-specs.

It's not really clear to me what the extra complexity from contracts that may or may not exist is, given that that's already true for externally-deployed contracts. And what John is saying seems like a roundabout way of saying "we can't have contract factories" while still trying to say "we can have contract factories".

The workarounds seem viable, but I don't understand why contract factories introduce additional complexity.

from fuel-specs.

Actually, with some of the logic in #60, it shouldn't be too hard to extend to cover the case of conditional contract creation. My initial worries around complexity may have been jumping the gun.

from fuel-specs.

Reopening this. I had a gut feeling there was something afoot but couldn't place it until I started working on the specification for CREATE. We have two choices: contract ID assigning similar to Ethereum's CREATE (uncontrollable), or similar to CREATE2 (controllable). We want the latter because it supports strictly more usecases, e.g. counterfactual contracts.

The issue here is that we have to forbid creating two contracts with the same contract ID (contract address on Ethereum). But this implies that the results of a transaction (gas used, among other things) depends on the other transactions in a block. In other words, block proposers can no longer validate transactions in parallel even if they seemingly have disjoint access lists. Intuitively, creating a contract also counts as accessing it; and if created contracts are not known before validating the transaction then in fact the access list of the transaction is unknown.

My recommendation is to, as in the OP, remove conditional and programmatic contract creation, such that the contract ID of all (well, the one) created contracts of a transaction is known simply by looking at the transaction without executing it.

from fuel-specs.

from fuel-specs.

The issue here is that we have to forbid creating two contracts with the same contract ID (contract address on Ethereum). But this implies that the results of a transaction (gas used, among other things) depends on the other transactions in a block. In other words, block proposers can no longer validate transactions in parallel even if they seemingly have disjoint access lists. Intuitively, creating a contract also counts as accessing it; and if created contracts are not known before validating the transaction then in fact the access list of the transaction is unknown.

Can't you just include the address of the created contract in the access list to avoid this issue?

from fuel-specs.

Can't you just include the address of the created contract in the access list to avoid this issue?

We could actually now that you mention it! But avoiding this one issue opens up new ones. A CREATE opcode in general brings with it a huge number of downsides while not enabling any features that can't be replicated otherwise (as mentioned earlier in this post, anything you can do with a CREATE opcode can be done with in-state mutexes and transaction-level contract creation):

• Unlike Ethereum, there's no such thing as an EOA for us. So we can't hash in the sender address to get the contract ID. This means anyone can frontrun any contract creation---another thing we have to analyze and contract developers have to be worried about.
• More complexity around interacting with contracts that are created in the same transaction. You could forbid this, but then what's even the point of creating a contract in the VM. Just do it at the transaction level. On the other hand, if you allow it: if the contract isn't listed as an input, then interacting with a contract that is created in the same transaction now requires special case logic, so that calling a contract can be done with both existing contracts and the new contracts. If the contract is listed as an input, then there's more complexity to reason about input existence. The guarantee we want is that a transaction is invalid if any of its inputs doesn't exist. So we would need a special case to handle contracts that may-or-may-not-exist.
• Worse performance. A CREATE opcode needs to be executed in the VM's interpreter instead of natively. This means higher costs for end users for doing the same work ultimately.
• In line with the above, a CREATE opcode means we need a different context to handle returning successfully from a create-flavored call frame.

TL;DR: unlike regular UTXOs, contract state elements are updatable. Because of this, the logic around updating them is, understandably, complex. Having a CREATE opcode means a whole boatload of special cases and extra accounting/logic around transaction validity conditions, while having worse performance and not actually enabling anything new.

from fuel-specs.