Skip to content

Protocol 28 (CAP-0083) #789

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
sisuresh wants to merge 17 commits into
base: protocol-next
Choose a base branch
from
Open

Protocol 28 (CAP-0083) #789

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
64ecb7e
Protocol 28 (CAP-0083) support
sisuresh Jun 15, 2026
72ac247
golangci-lint: allow go-stellar-sdk SPIKE replace directive
sisuresh Jun 15, 2026
dbd841c
Re-pin go-stellar-sdk to CAP-0083 review head (4615d5e8)
sisuresh Jun 16, 2026
d961132
Re-pin go-stellar-sdk to merged upstream CAP-0083; drop SPIKE lint ex…
sisuresh Jun 16, 2026
28aeea2
check-dependencies: read top-level xdr-version on the git-rev path
sisuresh Jun 16, 2026
4b1f050
CI: shift integration matrix to {P27, P28-vnext}; drop P26
sisuresh Jun 17, 2026
f5dca26
CI: bump P28 leg to vnext 3348 to match horizon's pin
sisuresh Jun 17, 2026
fd44198
integrationtest: add P28 upgrade fixtures (copy of P27)
sisuresh Jun 17, 2026
79fae9a
CI: switch P28 deb to plain vnext to mirror P27's variant
sisuresh Jun 17, 2026
93c9c49
preflight: enable rs-soroban-env 'next' feature for P28 support
sisuresh Jun 17, 2026
2c48e12
preflight: shift host window — -prev=27.0.0, -curr=git@main with 'next'
sisuresh Jun 17, 2026
502c521
scripts: dep-checker handles -prev/-curr from different sources
sisuresh Jun 17, 2026
0997c7c
CI: pin rpc P28 core to 3312 to dodge QueryServer catchup abort
sisuresh Jun 17, 2026
32d9a12
scripts: relax XDR-rev check when Rust/Go are on same ancestry
sisuresh Jun 17, 2026
a49f53f
CI: bump P28 captive-core deb to 3367 (includes stellar-core#5329)
sisuresh Jun 18, 2026
e8733a2
CI: bump P28 docker image to 3367.3589a696b.jammy-vnext
sisuresh Jun 18, 2026
b8ad8b1
preflight test: shift supportedProtocolVersions to {27, 28}
sisuresh Jun 18, 2026
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
23 changes: 15 additions & 8 deletions .github/workflows/stellar-rpc.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -84,14 +84,6 @@ jobs:
CGO_ENABLED: 1
GOARCH: ${{ matrix.go_arch }}

integration-p26-pkg:
name: Integration tests (P26)
uses: ./.github/workflows/integration-tests.yml
with:
protocol_version: '26'
core_deb_version: '26.0.0-3089.8e43a2d3b.jammy'
core_docker_img: 'stellar/stellar-core:26.0.0-3089.8e43a2d3b.jammy'

integration-p27-pkg:
name: Integration tests (P27)
uses: ./.github/workflows/integration-tests.yml
Expand All @@ -100,6 +92,21 @@ jobs:
core_deb_version: '27.0.0-3288.7696c069d.jammy'
core_docker_img: 'stellar/stellar-core:27.0.0-3288.7696c069d.jammy'

integration-p28-pkg:
name: Integration tests (P28)
uses: ./.github/workflows/integration-tests.yml
with:
protocol_version: '28'

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Add P28 upgrade fixtures before enabling P28 tests

When this new job runs with protocol_version: '28', the reusable workflow exports that value as STELLAR_RPC_INTEGRATION_TESTS_CORE_MAX_SUPPORTED_PROTOCOL; NewTest then defaults to protocol 28 and upgradeLimits() reads unlimited.p28.xdr. The embedded upgrade directory only contains p26/p27 limit files, so default integration tests in the P28 leg fail during startup before exercising CAP-0083. Add p28 fixtures or skip the limit-upgrade step for this consensus-only protocol.

Useful? React with 👍 / 👎.

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Map P28 to an available preflight host

When this job sets STELLAR_RPC_INTEGRATION_TESTS_CORE_MAX_SUPPORTED_PROTOCOL=28, integration tests create protocol-28 ledgers and the RPC simulation/submission paths pass that ledger protocol into preflight. The Rust FFI currently only accepts proto <= prev::PROTOCOL or proto == curr::PROTOCOL, and curr is still soroban-env-host 27.0.0, so any Soroban preflight on P28 returns unsupported protocol version: 28. Please either treat consensus-only P28 as the current host protocol or bump the host before enabling the P28 leg.

Useful? React with 👍 / 👎.

# Protocol 28 (CAP-0083) runs against the vnext (next-protocol-enabled)
# core build. Plain vnext (no `~buildtests`) to mirror the plain
# release deb / docker image used by the P27 leg above.
#
# Pinned to 3367 (3589a696b), which includes stellar-core#5329 — the
# fix for the QueryServer.cpp:124 contiguous-snapshot assertion that
# aborted captive-core catchup on builds 3313..3366.
core_deb_version: '27.0.1-3367.3589a696b.jammy~vnext'
core_docker_img: 'stellar/unsafe-stellar-core:27.0.1-3367.3589a696b.jammy-vnext'

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Use the published vnext core image repo

In the P28 leg, the reusable workflow runs docker pull "$CORE_DOCKER_IMG" before any tests start. The vnext tag 27.0.1-3367.3589a696b.jammy-vnext is published under Docker Hub's stellar/unsafe-stellar-core-next repository, not stellar/unsafe-stellar-core, so this new job will fail at the image pull (or stop exercising the next-protocol image if a similarly named non-next tag appears). Point this at stellar/unsafe-stellar-core-next:27.0.1-3367.3589a696b.jammy-vnext to run the intended P28 core container.

Useful? React with 👍 / 👎.


# integration-p25-src:
# name: Integration tests (p25, core from source)
# uses: ./.github/workflows/integration-tests.yml
Expand Down
145 changes: 81 additions & 64 deletions Cargo.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

20 changes: 15 additions & 5 deletions Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,26 +14,36 @@ serde_json = "1.0"

[workspace.dependencies.soroban-env-host-prev]
package = "soroban-env-host"
version = "=26.1.2"
version = "=27.0.0"

# Shift the window: `-prev` is now the released P27 host (crates.io 27.0.0),
# and `-curr` is the next-protocol-aware host pulled from upstream main with
# `next` enabled, declaring P28. Using a git rev (instead of crates.io
# 27.0.0 + `next`) lets cargo treat -prev and -curr as separate compilation
# units — otherwise it refuses two aliases to the same crate+version.
# Bump the rev as rs-soroban-env evolves on its protocol-next track.
[workspace.dependencies.soroban-env-host-curr]
package = "soroban-env-host"
version = "=27.0.0"
git = "https://github.com/stellar/rs-soroban-env"

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Disambiguate the git current host in dependency checks

With the current host coming from this git source while soroban-env-host-prev remains the crates.io 27.0.0, Cargo.lock now contains two soroban-env-host v27.0.0 packages from different sources. The dependency-sanity-checker still parses only 27 from Cargo.toml and runs cargo tree -p soroban-env-host@$PROTO, which is ambiguous for same-name/same-version packages from separate sources (verified against Cargo package selection), so the required dependency-check workflow fails before reaching the XDR comparisons. Please make the checker use a fully-qualified package ID/source, or otherwise avoid the duplicate soroban-env-host@27 package spec.

Useful? React with 👍 / 👎.

rev = "883fd56374fc619afaa4c4c7489563555b7173f2"
Comment on lines +27 to +28

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 18, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Make the soroban-env updater source-qualified

This git curr dependency now has the same package name and version as the new crates.io -prev dependency, but the scheduled .github/workflows/update-soroban-env.yml still runs scripts/update-soroban-env.sh, which calls cargo update -p "soroban-env-host@${current_host_version}". I checked cargo +1.95.0 update -p soroban-env-host@27.0.0 --dry-run --offline, and Cargo reports that spec is ambiguous and asks for the registry/git source-qualified package IDs, so the every-12-hours protocol-next updater will fail until the script targets the git pkgid explicitly.

Useful? React with 👍 / 👎.

features = ["next"]

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Preserve P27 preflight when enabling next

With this feature enabled, soroban_env_host::meta::INTERFACE_VERSION.protocol becomes 28, but the preflight dispatcher still only routes proto <= prev::PROTOCOL or proto == curr::PROTOCOL. Since prev::PROTOCOL is 26, any protocol-27 ledger now falls through to unsupported protocol version: 27; the P27 integration job kept in .github/workflows/stellar-rpc.yml and any P27 simulation/submission paths will fail. This is fresh evidence beyond the earlier P28 unsupported issue: the new next feature flips the current host protocol to 28 without preserving the 27 mapping.

Useful? React with 👍 / 👎.

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Use AddressV2 when recording P28 auth

With this line, curr::PROTOCOL becomes 28, but curr::recording_auth_mode in cmd/stellar-rpc/lib/preflight/src/lib.rs still calls recording(..., false) for use_address_v2 even though that comment says the legacy setting is only until v28. For P28 simulateTransaction calls that default to record mode when no auth is supplied, RPC will return legacy Address credentials instead of AddressV2 credentials, so clients get auth entries that cannot be used for a P28 submission. Please flip only the curr/P28 recording path to use_address_v2 = true.

Useful? React with 👍 / 👎.


[workspace.dependencies.soroban-simulation-prev]
package = "soroban-simulation"
version = "=26.1.2"
version = "=27.0.0"

[workspace.dependencies.soroban-simulation-curr]
package = "soroban-simulation"
git = "https://github.com/stellar/rs-soroban-env"
rev = "883fd56374fc619afaa4c4c7489563555b7173f2"
features = ["unstable-next-api"]
version = "=27.0.0"

[workspace.dependencies.stellar-xdr]
version = "=27.0.0"
# `type_enum` provides the `Type`/`TypeVariant` reflection enums used by
# xdr2json. It was enabled by default in stellar-xdr v26 but is opt-in in v27.
features = ["serde", "type_enum"]
# `cap_0083` gates the Protocol 28 EmptyTxSet StellarValueType variant.
features = ["serde", "type_enum", "cap_0083"]

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Pin Rust XDR to the CAP-0083 revision

Adding cap_0083 here leaves the Rust crate at stellar-xdr =27.0.0, whose recorded xdr-version is still 68fa1ac..., while the new Go SDK records the CAP-0083 XDR commit 8521b97.... The dependency-sanity-checker runs scripts/check-dependencies.bash and compares those exact Stellar XDR revisions, so this PR fails that workflow before tests run and the Rust/Go sides are no longer pinned to the same generated XDR metadata. Please pin stellar-xdr to a release or git rev generated from the CAP-0083 commit, or update the checker if this feature build is intentionally equivalent.

Useful? React with 👍 / 👎.


[workspace.dependencies.rand]
version = "0.8.5"
Expand Down
Loading
Loading