Merge branch 'master' into token

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,26 @@ 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`, and will only vote
+for upgrades that follow this rule. Validators should however still apply any
+valid hash the network accepts (even if that specific validator didn't vote for
+the upgrade).
 
 #### `ConfigUpgradeSet` validation
 
@@ -110,28 +118,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
 

ecosystem/sep-0006.md

@@ -6,8 +6,8 @@ Title: Deposit and Withdrawal API
 Author: SDF
 Status: Active (Interactive components are deprecated in favor of SEP-24)
 Created: 2017-10-30
-Updated: 2023-01-13
-Version 3.18.1
+Updated: 2023-08-15
+Version 3.19.0
 ```
 
 ## Simple Summary
@@ -114,7 +114,7 @@ sequenceDiagram
 * [`GET /deposit-exchange`](#deposit-exchange): optional
 * [`GET /withdraw-exchange`](#withdraw-exchange): optional
 * [`GET /info`](#info): required
-* [`GET /fee`](#fee): optional
+- [`GET /fee`](#fee): **deprecated** optional (only needed for complex fee structures).
 * [`GET /transactions`](#transaction-history): required
 * [`GET /transaction`](#single-historical-transaction): required
 
@@ -1004,6 +1004,8 @@ The default values for the features listed above have been selected based on the
 
 ## Fee
 
+**This endpoint is deprecated. The [SEP-38] `GET /price` endpoint should be used to fetch fees instead.**
+
 The fee endpoint allows an anchor to report the fee that would be charged when using the `/deposit` or `/withdraw` endpoints.
 
 This endpoint is important to allow an anchor to accurately report fees to a user even when the fee schedule is complex. If a fee can be fully expressed with the `fee_fixed` and `fee_percent` fields in the `/info` response, then an anchor should not implement this endpoint.
@@ -1420,6 +1422,7 @@ If the information was malformed, or if the sender tried to update data that isn
 
 ## Changelog
 
+* `v3.19.0`: Deprecate `/fee` endpoint
 * `v3.18.1`: Fix the missing types of the `withdraw` request parameters and some typo.  ([#1365](https://github.com/stellar/stellar-protocol/pull/1365))
 * `v3.18.0`: Added `refunded` status and `updated_at` transaction fields to match other SEPs (24, 31) ([#1336](https://github.com/stellar/stellar-protocol/pull/1336))
 * `v3.17.1`: Allow anchors to omit the deprecated `X-Stellar-Signature` header ([#1335](https://github.com/stellar/stellar-protocol/pull/1335))

ecosystem/sep-0024.md

@@ -1387,7 +1387,7 @@ There is a small set of changes when upgrading from SEP-6 to SEP-24.
 ## Changelog
 
 - `v3.3.0`: Add support for [SEP-38] API. Add optional `quote_id` parameter to `post /transactions/deposit/interactive`
-  and `POST /transactions/deposit/interactive` requests. Add `quote_id` to the transaction object schema.
+  and `POST /transactions/deposit/interactive` requests. Add `quote_id` to the transaction object schema. Deprecate `/fee` endpoint.
   ([#1358](https://github.com/stellar/stellar-protocol/pull/1358))
 - `v3.2.0`: Deprecate the `wallet_name` and `wallet_url` parameters of `POST /transactions/deposit/interactive` and
   `POST /transactions/withdrawal/interactive` requests ([#1364](https://github.com/stellar/stellar-protocol/pull/1364))