# Some thoughts on this proposal
## Unique Integer Identifiers
As currently proposed, every contract gets a unique integer contractID. The proposal does not specify it, so I am going to assume that identifiers are drawn from `LedgerHeader.idPool`. The main advantage of this approach is that a contract can be identified using only 8 bytes. The main disadvantage of this approach is that the contractID assigned depends on execution order. Specifically, it is not trivial to parallelize contract creation because it will conflict on idPool. Is this the best approach?
## Account-Contract Pairing
Why should an account own a contract? What happens if an account owns multiple contracts? What exactly does ownership confer? For context, in Ethereum an account can be either externally owned or a contract.
CAP-0050 proposes a model in which Stellar accounts are logically separated from addresses used in contracts. In this model, both public keys and contracts are first class addresses. Philosophically speaking, one would then expect a contract to have no owner. What are the implications of such a model for contract lifecycle?
While I believe that mutable contracts are valuable, I'm not convinced that we need to support this in the initial version. Proxy contracts are an established way to achieve upgradeability in contracts.
My first concern relates to ownership (see "Account-Contract Pairing" above). Why should the owner always be able to update a contract? Can you change the owner if you want to change who can update it? What are the consequences of this design? This seems unnecessarily prescriptive. For example, if ownership confers the ability to update a contract then contracts with complex update logic will need to disable this in order to implement their own logic.
My next concern relates to updating contracts from a contract. This capability is required for contracts with complex update logic, as already noted. Presumably, this update logic would reside in the contract that you want to update. But what does it mean to update code that is currently running? Does the code only update at the end of the transaction? Or does updating the code terminate contract execution? These are questions that we would need to address in order to generally support updates.
It's not obvious to me that mutable contracts are better than immutable contracts with a fast proxy or a fast routing layer. There is always time for optimizations and improvements later, but it's more important to quickly deploy something that works.
My concerns here are similar to my concerns about UpdateContractOp regarding ownership. Why should the owner always be able to delete a contract? What about the case where a contract wants to control when it can be deleted and/or by whom?
The same question about deleting code that is currently running applies? Does it run to completion then delete? Or does deleting the code terminate contract execution?
## Contract Metadata
I'm not convinced that we need to support this in the initial version. It would be helpful if the design rationale went into greater detail about the advantages and disadvantages of including contract metadata. For example, suppose we don't include contract metadata. Is it possible to identify what interfaces a contract supports? See https://eips.ethereum.org/EIPS/eip-165
. What would be the consequences of this approach? Would contract metadata have any advantages over a EIP-165 approach (or any other you can think of)?
I do think that contract metadata as a fast router could be very useful, but I see that as an optimization as noted above. Would there be any compatibility issues if we were to add this later?
## Maximum Contract Size
Should the maximum contract size even be configurable? The maximum contract size is really a reflection of technical limitations: burden on the overlay, the cost of loading WASM, etc. In the unlikely case that we did need to switch to a variable maximum size later, we could always do so by changing `typedef opaque WASMCode<MAX_CODE_SIZE>` to `typedef opaque WASMCode<>` and adding the appropriate checks, or by introducing a new type of contract code entry if we were concerned about backwards compatibility.
It is always possible to build arbitrarily large contracts by delegating functionality to other contracts. For example, a contract could be a thin wrapper that only forwards calls to other contracts. This design automatically forces deployers to "upload their contract in smaller chunks" if the contract is large, without requiring any native protocol support.
## Global Flags
We should consider reusing the enum values from the liquidity pool flags. They were intended to be removed if they were never needed, see https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md#ledger-header-flags
# Some thoughts on other comments
## Gradually Open Up the Network
Nicolas suggests "While we're ramping up smart contracts on Stellar, we probably need a (temporary) way to gradually open up the network to new authors." I'm not certain that this achieves the network goals. The most important thing for success will be rapid adoption, and people will not adopt anything if they aren't even able to deploy. If we are concerned that our design or implementation is too risky, then we probably need to do more work before opening access to anyone.
Siddharth's flags approach, which would be used by validators in response to a crisis, is probably a better fit.
# One nitpick
I think something went wrong with the formatting of your subsection titled "Create/update/delete operations are used to manage a contract instead of a single operation".