Skip to content

📝 Inline fix most egregious typos #1984

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
JFWooten4 wants to merge 2 commits into
base: master
Choose a base branch
from
+2 −3
Open

📝 Inline fix most egregious typos #1984

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e19b29b
Remove duplicative `correct_entry` defintion
JFWooten4 Oct 20, 2025
1c0d3ac
Remove repeteated adverb confusion
JFWooten4 Oct 20, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 2 additions & 3 deletions core/cap-0076.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,8 +72,7 @@ Specifically, for every `ledger_key` in [corrupted_hot_archive_entries](./../con
- An entry `E` corresponding to the `ledger_key` exists in the Hot Archive
- `E == archived_entry` (where `archived_entry` is the corresponding value from the corrupted_hot_archive_entries table)

If the entry is amendable, then a new ledger entry with value ``correct_entry` - base64 encoded `LedgerEntry` XDR, the correct value that should have been archived (i.e. the value of the affected entry at the moment when it has been archived)
` (from the table) will be written to the Hot Archive and thus become the most recent state of the entry that will be used for the restoration.
If the entry is amendable, then a new ledger entry with value `correct_entry` (defined above) from the table will be written to the Hot Archive and thus become the most recent state of the entry that will be used for the restoration.

Note, that since the amendment only occurs in the Hot Archive, the change will not be reflected in `LedgerCloseMeta`, as it can not contain Hot Archive changes. The change will only be observable due to the `bucketListHash` change in the upgrade ledger header. After the upgrade the amended changes will be observable at the moment of restoration (and they will have the state that matches the state they had prior to archival).

Expand All @@ -99,7 +98,7 @@ The upgrade ledger will need to do a few hundred additional disk lookups, but th
As mentioned in the 'Motivation' section this CAP performs modification of the ledger state that is not directly owned by the validators, which comes with the inherent risk of malicious modifications, or non-malicious erroneous modifications that lead to the further state corruption that can then be abused by the attackers.

In order to resolve these concerns to some degree, and in order to ensure that the amendments only bring back the entries to their valid state, the Stellar Core build that performs the upgrade will contain the tools that allow anyone to ensure that:
- During the replay of protocol 23 *only* the entries from [corrupted_hot_archive_entries](./../contents/cap-0076/corrupted_hot_archive_entries.csv) table are incorrectly incorrectly archived, and that their correct and archived states match those in the table
- During the replay of protocol 23 *only* the entries from [corrupted_hot_archive_entries](./../contents/cap-0076/corrupted_hot_archive_entries.csv) table are incorrectly archived, and that their correct and archived states match those in the table
- Ensure that *every* entry from the table has indeed been incorrectly archived
- Ensure that during the protocol upgrade only the entries from the table have been updated, and that the update has brought them back to the correct state

Expand Down
Loading