Updates and add auth

core/cap-0046-02.md

@@ -52,14 +52,14 @@ unique contract sources.
 
 This CAP defines two possible kinds of contract sources:
 
-- WASM source: a blob of WASM code that is stored in a separate ledger entry and
-  is deduplicated based on contents. This is installed to ledger by the users.
+- Wasm source: a blob of Wasm code that is stored in a separate ledger entry and
+  is deduplicated based on contents. This is uploaded to ledger by the users.
 - Built-in contract: this is a 'source' compiled into host directly that has a
   protocol-defined interface and behavior.
 
 #### Contract executable
 
-The Contract executable contains a pointer to the WASM source or a tag of a built-in
+The Contract executable contains a pointer to the Wasm source or a tag of a built-in
 contract.
 
 #### Contract instance
@@ -91,31 +91,31 @@ ensure that every network has unique set of contract identifiers, along with a
 - `CONTRACT_ID_PREIMAGE_FROM_ASSET`: built from a Stellar `Asset`
   structure.
 
-### Installing WASM sources using `InvokeHostFunctionOp`
+### Uploading Wasm sources using `InvokeHostFunctionOp`
 
-WASM contract sources can be uploaded to the network without instantiating a
+Wasm contract sources can be uploaded to the network without instantiating a
 contract via `InvokeHostFunctionOp`(defined in [CAP-0046-04](./cap-0046-04.md))
 with `HOST_FUNCTION_TYPE_UPLOAD_CONTRACT_WASM` host function type in
 `hostFunction`.
 
-This function accepts `opaque wasm<>` that contains the WASM
+This function accepts `opaque wasm<>` that contains the Wasm
 contract code.
 
 Uploaded contracts are stored in `ContractCodeEntry` ledger entries. These
-entries are keyed by the hash of the WASM used to upload
+entries are keyed by the hash of the Wasm used to upload
 them.
 
 The contract upload host function will compute the hash of
-the WASM and check if such a contract code already exists. If
+the Wasm and check if such a contract code already exists. If
 the entry exists, the operation will immediately succeed. If it doesn't, the
 new `ContractCodeEntry` will be created.
 
-Core does not perform any validation on the installed contract code, besides
+Core does not perform any validation on the uploaded contract code, besides
 checking its size.
 
 #### Max contract size setting
 
-The maximum WASM contract size will be introduced as a `ConfigSettingEntry`(see
+The maximum Wasm contract size will be introduced as a `ConfigSettingEntry`(see
 [CAP-0046-09](./cap-0046-09.md) for details on config entries). 
 
 It is set during the protocol version upgrade using a new `ConfigSettingEntry`,
@@ -132,6 +132,13 @@ The function accepts `CreateContractArgs` struct that defines the input for
 building the contract identifier preimage (`contractIDPreimage` field) and the
 contract executable reference (`executable` field).
 
+`InvokeHostFunctionOp`'s `auth` vector will also require a
+`SorobanAuthorizationEntry` of type `SOROBAN_CREDENTIALS_SOURCE_ACCOUNT`, with
+`rootInvocation` set to a `SorobanAuthorizedInvocation` where `function` is of
+type `SOROBAN_AUTHORIZED_FUNCTION_TYPE_CREATE_CONTRACT_HOST_FN`.
+`function.createContractHostFn` should be set to the `CreateContractArgs` used
+under the `HOST_FUNCTION_TYPE_CREATE_CONTRACT` host function mentioned above.
+
 The executable and identifier arguments are normally independent of each other
 with an exception: identifiers that are built from
 `CONTRACT_ID_PREIMAGE_FROM_ASSET` may only be used in conjunction with built-in
@@ -146,21 +153,21 @@ identifier already exists, the operation fails.
 If the identifier is new, the host will create a new Persistent
 `ContractDataEntry` from [CAP-0046-05](./CAP-0046-05.md) with a
 `SCV_LEDGER_KEY_CONTRACT_INSTANCE` key value. The value of the entry is
-`ScContractInstance` that either refers to the WASM code entry or to a built-in
+`ScContractInstance` that either refers to the Wasm code entry or to a built-in
 contract (according to the value of the `executable` field in `CreateContractArgs`).
 
 ### Instantiating a contract from a contract
 
 Factory contracts are quite popular already on other networks, so this CAP adds
 functionality to support them. 
 
-The following host functions are provided to instantiate contracts:
+The following host functions are provided to instantiate contracts and upload Wasm:
 
 ```rust
-// Uploads the WASM. Returns the SHA-256 hash of the WASM code.
+// Uploads the Wasm. Returns the SHA-256 hash of the Wasm code.
 fn upload_wasm(wasm: Bytes) -> Bytes
 
-// Creates a WASM instance using the deployer, SHA-256 hash of the WASM, and a user specified salt.
+// Creates a Wasm instance using the deployer, SHA-256 hash of the Wasm, and a user specified salt.
 // Returns the Address of the newly created contract.
 fn create_contract(deployer: Address, wasm_hash: Bytes, salt:Bytes) -> Address
 
@@ -173,16 +180,25 @@ The contractIDs for the contracts created with `create_contract` and
 `create_asset_contract` are derived from `CONTRACT_ID_PREIMAGE_FROM_ADDRESS` and
 `CONTRACT_ID_PREIMAGE_FROM_ASSET` respectively.
 
+Similar to how contract creation through `HOST_FUNCTION_TYPE_CREATE_CONTRACT`
+requires authorization mentioned
+[above](#instantiating-contracts-using-invokehostfunctionop), invoking the
+`create_contract` host function requires authorization as well. The difference
+is that the `SorobanAuthorizationEntry` will be of type
+`SOROBAN_CREDENTIALS_ADDRESS`, and the `address` must contain the `SCAddress` of
+the deployer, the `nonce` being consumed, the `signatureExpirationLedger`, and
+the `SCVal` `signature`.
+
 ### Updating a contracts code
 
 We also provide a host function that allows contract instances to update the
-WASM executable by first uploading the new code, and then calling
-`update_current_contract_wasm` with the hash of the newly uploaded WASM.The
+Wasm executable by first uploading the new code, and then calling
+`update_current_contract_wasm` with the hash of the newly uploaded Wasm.The
 update happens only after the current contract invocation has successfully
 finished, so this can be safely called in the middle of a function.
 
 ```rust
-// Updated the current contracts WASM executable.
+// Updated the current contracts Wasm executable.
 fn update_current_contract_wasm(wasm_hash: Bytes)
 ```
 
@@ -205,8 +221,8 @@ the contract creator chooses.
 
 ### `ContractCodeEntry` has no owner associated with it
 
-Contract source code entries with the WASM code don't have any ownership. Anyone
-can install contract sources to the ledger and then anyone can use them. This
+Contract source code entries with the Wasm code don't have any ownership. Anyone
+can upload contract sources to the ledger and then anyone can use them. This
 encourages sharing the contract code and allows contracts that use it to be
 sure that their implementation can't unexpectedly change.
 
@@ -223,7 +239,7 @@ The validators do not have a mechanism to ban specific contracts. Any kind of
 targeted banning mechanism can be worked around quite easily by creating new
 accounts and contracts.
 
-### Maximum WASM contract code size is configurable
+### Maximum Wasm contract code size is configurable
 
 The maximum contract size will be set during the protocol upgrade, and can be
 updated by the validators. This allows to adjust the contract sizes depending
@@ -245,9 +261,4 @@ may not exist (for example, some general contracts like tokens or AMMs).
 
 The security concerns from CAP-0046
 (https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046.md#security-concerns)
-apply here as well.
-
-In addition to those concerns, this CAP does not provide validators with much
-control over contracts on the network. The only mechanism they have is disabling
-all Soroban transactions, which should only be used in drastic situations. This
-CAP does not define a way for validators to block specific contracts.
+apply here as well.