Ungate CAP-0083 and CAP-0085, bump to protocol 28 - #5397
Open
sisuresh wants to merge 12 commits into
Open
Conversation
Removes the CAP_0083 and CAP_0085_EXECUTABLE_REF ifdefs and their configure.ac / common.mk / Makefile.am wiring, so both CAPs compile unconditionally. EMPTY_TX_SET_PROTOCOL_VERSION and EXTERNAL_EXECUTABLE_REF_PROTOCOL_VERSION are now always V_28 rather than falling back to V_UINT32_MAX; activation stays gated at runtime by protocolVersionStartsFrom. Bumps Config::CURRENT_LEDGER_PROTOCOL_VERSION to 28. Repins src/protocol-curr/xdr to stellar/stellar-xdr#311 (9c9c145, where the ifdefs were removed) and the p28 soroban host to stellar/rs-soroban-env#1715 (eec5eea2). The host bump also brings in CAP-0086 (sparse Symbol-keyed map host functions), which needs no ungating of its own: it has no XDR changes and landed in the host unconditionally, gated only by min_supported_protocol 28.
The XDR identity check was commented out pending the p28 bump; this commit does that bump, so re-enable it. p28-expect.txt picks up the new stellar-xdr rev from the host repin. The only change is the rev itself, in both places it appears; p21-p27 are untouched.
Bumping CURRENT_LEDGER_PROTOCOL_VERSION to 28 is not enough on its own: p28 was wired throughout as a next-only host, so a plain build had no p28 host at all and aborted in check_sensible_soroban_config_for_protocol with max_host_module_proto (27) < core_max_proto (28). Ungates the p28 module itself, the soroban_curr alias, its HOST_MODULES entry, the two v1-unsupported stub macros it relies on, and its SorobanModuleCache field and dispatch arms. Clears WIP_SOROBAN_PROTOCOL, since p28 is no longer work-in-progress. That also means --features=next now reaches p28 (it is applied only to SOROBAN_MAX_PROTOCOL), so under a vnext build the same submodule reports protocol 29 and matches core's max of 29. The dispatch test is re-gated accordingly: 28 without the feature, 29 with it.
Conflict in src/util/ProtocolVersion.h: stellar#5393 added TX_ED25519_VERIFY_BUDGET_PROTOCOL_VERSION in the same place this branch removed the #ifdef CAP_0085_EXECUTABLE_REF. Resolution keeps both -- the new constant, and EXTERNAL_EXECUTABLE_REF_PROTOCOL_VERSION ungated. Also bumps stellar-quorum-analyzer to 502a354 (stellar#23), which repins its stellar-xdr to the same git rev as the p28 host so their XDR_FILES_SHA256 agree and checkXDRFileIdentity passes.
The fastdev build takes its hosts from the optional soroban-env-host-p2x dependencies rather than the per-protocol submodule rlibs, so it never sees the --features=next that src/Makefile.am passes to SOROBAN_MAX_PROTOCOL. With core now at protocol 28, a fastdev+next build therefore had core_max_proto 29 against a p28 host still reporting 28, and aborted in check_sensible_soroban_config_for_protocol. This worked before only by coincidence: core_max_proto was also 28 there (27 + 1), so the comparison happened to hold. Forward the feature with weak-dependency syntax so it stays a no-op when the optional dependency is not enabled, leaving the non-fastdev path alone. Verified: plain build reports protocol 28 with 8 hosts, fastdev+next reports 29 with p28 itself reporting 29; both exit 0.
…line Under "next" the p28 host reports protocol 29, so SorobanModuleCache's dispatch on hm.max_proto fell through to "unsupported protocol". Add next-gated 29 arms pointing at the same cache, mirroring what "fix next" (4986b42) did for 28 -> p27_cache during the p27 bump. Take features = ["next"] on the p28 dependency rather than forwarding core's own "next" to it, matching 706f5ff. That dependency is only reachable through "fastdev", which implies "next", so the host is always wanted at its next-protocol number there. Re-record test-tx-meta-baseline-current: it recorded protocol 27 and core now reports 28, which failed every "current" CI leg. The next baseline still needs re-recording; it cannot be captured until the test harness stops requiring an exact linked host per protocol.
…aseline With core at protocol 28 and no p29 submodule, a vnext build has the p28 host reporting 29, so protocol 28 had no exact linked host and isProtocolBackedByLinkedSorobanHost rejected it -- failing 70 of 131 [tx] cases. rs-soroban-env explicitly supports this: Host::maybe_check_protocol_version bypasses its protocol check under "next" because "a 'next' host can be used as the current host for both its base protocol and the next one", and ParsedModule's meta-section check does the same. Accept the highest linked host for protocolVersion + 1 on that basis. Restricting it to the highest host keeps fastdev's collapse of historical protocols onto a newer host detectable, which is what the exact-match rule is there to catch. Uncomment moduleCacheProtocolCount -= 1 in "Module cache across protocol versions", as that test's own comment instructs when the next protocol points at another copy of the current host: soroban_module_cache.rs routes 29 to p28_cache, so 29 adds no cache of its own. Re-record test-tx-meta-baseline-next, which recorded protocol 28 and now records 29. All 131 [tx] cases pass.
LedgerCloseMetaStreamTests reads a reference JSON per protocol version and REQUIRE(inJson) fails when one is absent. Coverage stopped at 28; a vnext build now runs at 29, so the four protocol-29 variants were missing. Generated with GENERATE_TEST_LEDGER_CLOSE_META=1 for --version 29 only, as the test's own comment directs, so no existing version's golden data moves.
sisuresh
marked this pull request as ready for review
July 30, 2026 04:28
sisuresh
enabled auto-merge
July 30, 2026 05:10
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Removes the
CAP_0083andCAP_0085_EXECUTABLE_REFifdefs and theirconfigure.ac/common.mk/Makefile.amwiring, so both compile unconditionally. The two protocol constants are now alwaysV_28instead of falling back toV_UINT32_MAX; activation is still gated at runtime byprotocolVersionStartsFrom. BumpsCURRENT_LEDGER_PROTOCOL_VERSIONto 28.Repins
src/protocol-curr/xdrto stellar/stellar-xdr#311 and the p28 host to stellar/rs-soroban-env#1715. The host bump also brings in CAP-0086, which needs no ungating of its own — no XDR changes, and it landed in the host unconditionally.Last of the P28 ungating stack (stellar-xdr#311 → rs-stellar-xdr#565 → rs-soroban-env#1715 → this).