diff --git a/core/cap-0046-09.md b/core/cap-0046-09.md index 28000b6b9..6a5fb1ac2 100644 --- a/core/cap-0046-09.md +++ b/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 diff --git a/ecosystem/sep-0006.md b/ecosystem/sep-0006.md index a0008a9aa..9a33c7a8e 100644 --- a/ecosystem/sep-0006.md +++ b/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)) diff --git a/ecosystem/sep-0024.md b/ecosystem/sep-0024.md index f4d145235..1cd95ddf5 100644 --- a/ecosystem/sep-0024.md +++ b/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))