-
Notifications
You must be signed in to change notification settings - Fork 973
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.
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
Config Setting upgrades #3674
Config Setting upgrades #3674
Conversation
@@ -252,6 +330,12 @@ Upgrades::toString(LedgerUpgrade const& upgrade) | |||
upgrade.newBaseReserve()); | |||
case LEDGER_UPGRADE_FLAGS: | |||
return fmt::format(FMT_STRING("flags={:d}"), upgrade.newFlags()); | |||
#ifdef ENABLE_NEXT_PROTOCOL_VERSION_UNSAFE_FOR_PRODUCTION | |||
case LEDGER_UPGRADE_CONFIG: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this has the same format as all the other entries (with '='). Also, this will return JSON, right? So the formatting might be a bit weird due to it being multiline. Not sure though where we're using the toString though...
src/herder/test/UpgradesTests.cpp
Outdated
auto upgradeHash = autocheck::generator<Hash>()(5); | ||
auto ledgerUpgrade = LedgerUpgrade{LEDGER_UPGRADE_CONFIG}; | ||
ledgerUpgrade.newConfig() = ConfigUpgradeKey{contractID, upgradeHash}; | ||
REQUIRE_THROWS_AS(executeUpgrade(*app, ledgerUpgrade), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NB: I believe exception is fine here as we shouldn't get to upgrade execution for the invalid/unknown upgrades. But we need to make sure we don't crash during validation itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is still an open question I have. If a valid configUpgrade is nominated, is it possible so change the underlying ContractData entry that holds the ConfigUpgradeSet before the upgrade is applied? If so, that scenario needs to be handled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, yeah, it might change, so we need to verify that hash in the key matches the content hash. That can happen at validation time though, as upgrades happen after all the transactions. At apply time the upgrade set should be guaranteed to be correct and hence it should be ok to throw an exception (as that would be a bug)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The hash is already verified in ConfigUpgradeSetFrame::isValidXDR
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we should be good, right? Also we load the actual entry just once anyway, so there shouldn't be mismatch between the config upgrade set at validation and application time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We load the entry at validation and at apply (every time we call makeFromKey
). It's possible that the ledger the upgrade should be included in changes the entry, making the upgrade invalid. In that case, an exception would be thrown here -
stellar-core/src/ledger/LedgerManagerImpl.cpp
Line 744 in 53ea43a
throw std::runtime_error( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated code to ignore invalid upgrades instead of throwing an exception.
a07289b
to
b330107
Compare
src/herder/test/UpgradesTests.cpp
Outdated
auto upgradeHash = autocheck::generator<Hash>()(5); | ||
auto ledgerUpgrade = LedgerUpgrade{LEDGER_UPGRADE_CONFIG}; | ||
ledgerUpgrade.newConfig() = ConfigUpgradeKey{contractID, upgradeHash}; | ||
REQUIRE_THROWS_AS(executeUpgrade(*app, ledgerUpgrade), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, yeah, it might change, so we need to verify that hash in the key matches the content hash. That can happen at validation time though, as upgrades happen after all the transactions. At apply time the upgrade set should be guaranteed to be correct and hence it should be ok to throw an exception (as that would be a bug)
auto ltxe = ltx.loadWithoutRecord(ConfigUpgradeSetFrame::getLedgerKey(key)); | ||
if (!ltxe) | ||
{ | ||
return nullptr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wanted to make sure, how the downstream code handles nullptr here? Would it just act as if we didn't have such upgrade armed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It depends. In the CommandHandler
, we actually check after setting to make sure something was set. In applyTo
, we throw an exception (this shouldn't happen, but if it does, it'll be caught). In isValidForApply
, we return XDR_INVALID
. In isValidForNomination
, we return false.
78a46c4
to
7e47c86
Compare
hexAbbrev(key.contentHash)); | ||
return false; | ||
} | ||
if (std::adjacent_find( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is_sorted
above already does not allow for duplicates
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not true - it 'Checks if the elements in range [first, last) are sorted in non-descending order'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bleh yes! I always get is_sorted wrong
So I guess the suggestion becomes: as we use a custom predicate we should just use >=
for adjacent_find
which should do what we want (can't use this with is_sorted
as >=
is not Compare
).
80b11d3
to
77bcdd3
Compare
Change looks good now! |
14f73ba
to
ed002c2
Compare
This is to support how the new XDR is generated.
While this can be supported from the ledger standpoint, I think that semantically these shouldn't be removed and hence it's better to introduce some harness to make sure we don't accidentally remove it.
- Add methods to generate unique entries, so that we don't need to exclude `CONFIG_SETTING` entry from the fuzzer due to them having key collisions - Add methods to generate entries of given type and entries with exclusions to be more explicit about including/excluding the entry types where relevant
…of `CONFIG_SETTING` entries.
ed002c2
to
1b2f664
Compare
I cleaned up history and merged in the xdr change. One thing I'm trying to figure out though - I only updated the C++ and not env, but the xdr mismatch check isn't triggering for me locally. |
1b2f664
to
27bf0bd
Compare
@graydon do you think this is related to the fix you made? |
Looks like the github action correctly failed though. Weird. |
Ah I see this in my make output. I got a new laptop recently which is why I haven't run into this before. I'll try to get this to fail the build.
|
29f2490
to
cd3d956
Compare
r+ cd3d956 |
(@MonsieurNicolas is on vacation but I believe all his concerns were addressed, I'm going to dismiss his change-request) |
on vacation, all changes addressed
Description
Resolves stellar/rs-soroban-env#664.
Add a mechanism to propose upgrades that are stored in ContractData ledger entries. This PR is built on top of #3522, and starts with the "ConfigSettingEntry upgrades" commit.
Related xdr change - stellar/stellar-xdr#75.
xdr has not been merged in yet so this PR will fail until that happens.
Checklist
clang-format
v8.0.0 (viamake format
or the Visual Studio extension)