Refresh network config CAP

core/cap-0046-09.md

@@ -5,7 +5,7 @@ CAP: 0046-09
 Title: Network Configuration Ledger Entries
 Working Group:
     Owner: Dmytro Kozhevin <@dmkozh>
-    Authors: Dmytro Kozhevin <@dmkozh>
+    Authors: Dmytro Kozhevin <@dmkozh>, Siddharth Suresh <@sisuresh>
     Consulted:
 Status: Draft
 Created: 2022-11-01
@@ -33,15 +33,15 @@ of kilobytes of space to be stored.
 ## Abstract
 
 This CAP introduces a special type of configuration `LedgerEntry` that can only
-be modified via a protocol upgrade. It also specifies the general rules for
-adding and modifying these entries.
+be modified via a validator vote. It also specifies the general rules for adding
+and modifying these entries.
 
 ## Specification
 
 ### XDR
 
 See the XDR diffs in the Soroban overview CAP, specifically those referring to
-the `ConfigSettingEntry` and `ConfigUpgradeSet`.
+the `ConfigSettingEntry`,`ConfigUpgradeSet`, and `ConfigUpgradeSetKey`.
 
 ### Configuration settings entries
 
@@ -86,18 +86,23 @@ is only being partially updated. This is done to simplify the upgrade format
 (otherwise we'd need to introduce some key-value mechanism of specifying
 upgraded fields).
 
-Multiple configuration setting entries may be upgraded at once using
+Multiple configuration setting entries may be upgraded at once using a
 `ConfigUpgradeSet` struct that contains all the updated `ConfigSettingEntry`
-entries. Similar to the transaction sets, the network needs to agree on hash of
-the `ConfigUpgradeSet`, hence only hash is added to `SCPValue`. While upgrades
-are rare events, the size of the setting entry is not bounded and the number of
-`SCPValues` in the network is large enough (thousands of messages per node as
-of writing this) to have a risk of significantly reducing the network bandwidth
-during the upgrade.
-
-The actual upgrade set contents are pulled from the peers in a similar fashion
-to the transaction sets (if needed at all; ideally all the validators would
-have exactly the same upgrade set).
+entries. The `LedgerUpgrade` in `StellarValue` that validators will vote on will
+contain only an `ConfigUpgradeSetKey`, which containts a contractID, and the
+SHA-256 hash of the `ConfigUpgradeSet`. The actual `ConfigUpgradeSet` will need
+to exist on ledger in a `ContractDataEntry`, and the validators will look it up
+using the `ConfigUpgradeSetKey`. This means that a WASM contract will need to be
+used to write the proposed upgrade. The specs of the entry written is as follows -
+- It should be a `TEMPORARY` entry, so make sure it's bumped to live long enough for the upgrade.
+- The `SCVal` `key` should be of type `SCV_BYTES`, where the value is the SHA-256 hash of the `ConfigUpgradeSet`.
+- The `SCVal` `val` should also be of type `SCV_BYTES`, where the value is the
+  serialized XDR of the `ConfigUpgradeSet`.
+
+Once the proposed upgrade is setup, you'll need to share the
+`ConfigUpgradeSetKey` with the other validators so they can vote for it. Note
+that the validators will verify that the hash in `ConfigUpgradeSetKey` matches
+the hash of the upgrade stored in the `ContractDataEntry`.
 
 #### `ConfigUpgradeSet` validation
 
@@ -110,28 +115,29 @@ have exactly the same upgrade set).
 Individual config settings are validated in the way defined by the CAPs
 introducing them.
 
-#### `ConfigUpgradeSet` acceptance
-
-In order to vote for the config upgrade set, besides validating the
-`ConfigUpgradeSet` contents, validators also need to be able to accept them
-according to their own scheduled upgrades. 
-
-The validator will accept a valid nominated `ConfigUpgradeSet` when it can
-accept every updated entry in it. As a general rule, the validator should
-accept a given updated `ConfigSettingEntry` when the validator has exactly the
-same upgrade scheduled. However, the acceptance rules can be adjusted by the
-CAP introducing the config entry. For example, if entries describe CPU costs of
-executing a host function, it could be viable to allow any of the nominated
-upgrade values to be within 1% of the scheduled upgrade.
-
-If there are ever multiple valid `ConfigUpgradeSet`s that validator can accept,
-the one that has the most entries should be picked. Ties are resolved in favor
-of the lowest hash value.
-
-Note, that unlike with regular ledger upgrades, the network won't try to build a
-viable set of upgrades if only some of the entries are valid or accepted. So
-the whole `ConfigUpgradeSet` can be considered to be atomic from the upgrade
-standpoint.
+#### Disabling Soroban Transactions
+
+The submission of Soroban transactions can be disabled by setting
+`ConfigSettingContractExecutionLanesV0::ledgerMaxTxCount` to 0 in under the
+`ConfigSettingID` `CONFIG_SETTING_CONTRACT_EXECUTION_LANES`. Doing this will
+lock the validators out from creating config setting upgrades using WASM
+contracts, which means the `ConfigUpgradeSet` mechanism cannot be used to
+re-enable Soroban.
+
+To allow increasing `ledgerMaxTxCount` from 0, we introduce the ability to set
+the value using the traditional upgrade mechanism. There's a new `LedgerUpgrade`
+type `LEDGER_UPGRADE_MAX_SOROBAN_TX_SET_SIZE`, which contains a `uint32
+newMaxSorobanTxSetSize` to update
+`ConfigSettingContractExecutionLanesV0::ledgerMaxTxCount`.
+
+#### Minimum values
+
+The protocol should define minimum values for every upgradeable config setting
+so that it should always be possible to install a contract (assuming
+`ledgerMaxTxCount` isn't 0) that saves enough state to write the largest
+`ConfigUpgradeEntry` to allow for any config setting upgrade. Any CAP that
+introduces a new case under `ConfigSettingEntry` should also define the minimum
+values.
 
 ## Resource Utilization