2
2
name = " stellar-core"
3
3
version = " 0.1.0"
4
4
edition = " 2021"
5
- rust-version = " 1.74 "
5
+ rust-version = " 1.79.0 "
6
6
publish = false
7
7
8
8
[lib ]
@@ -23,64 +23,75 @@ petgraph = "=0.6.4"
23
23
toml = " =0.7.8"
24
24
itertools = " =0.11.0"
25
25
26
- # This copy of the soroban host is always enabled, and should always point to a
27
- # version that supports stellar-core's Config::CURRENT_LEDGER_PROTOCOL_VERSION.
28
- # When upgrading from protocol N to N+1, this copy will therefore have its
29
- # version advance first (to enable support for N+1) even before the network has
30
- # voted to upgrade to it. In order to avoid divergence during such an upgrade,
31
- # we will simultaneously enable the `prev` copy of soroban (below), continuing
32
- # to point to the previous already-released soroban that only supported protocol
33
- # N.
26
+ # Stellar-core supports multiple versions of the Soroban host linked in
27
+ # simultaneously. Each host is labeled with the _maximum_ protocol that it
28
+ # supports. The minimum protocol supported by each host is implicitly one more
29
+ # than the less-higher-numbered host's maximum protocol, though in some cases a
30
+ # host may also be configured with an explicit minimum supported protocol, in
31
+ # which case we have to keep extra hosts around to fill in any gaps in support.
32
+ #
33
+ # As an example: if we have hosts labeled -p21 and -p23, then the -p21 host will
34
+ # be used to apply ledgers with protocol 20 and 21, and the -p23 host will be
35
+ # used to apply ledgers with protocol 22 and 23.
36
+ #
37
+ # We add new hosts when performing a protocol upgrade. This allows us to hold
38
+ # back any changes to the host's dependencies to the next protocol transition
39
+ # and then simultaneously transition the entire network from one set of
40
+ # dependencies to another at the (consensus) protocol upgrade boundary.
41
+ #
42
+ # We remove hosts -- when possible -- _after_ a protocol upgrade, once no more
43
+ # ledgers with the previous protocol N-1 are being closed, and only when we have
44
+ # convinced ourselves that the host everyone is now running, that supports the
45
+ # new protocol N, can also faithfully replay all ledgers recorded under the
46
+ # previous protocol N-1. If there is any divergence during replay, then either
47
+ # the protocol N host has to be patched with some backward-compatibility code,
48
+ # or else we have to keep the protocol N-1 host around indefinitely. If we can
49
+ # get a clean replay with the new protocol N host, then we can remove the
50
+ # protocol N-1 host from the codebase.
51
+ #
52
+ # Each additional copy of the soroban host adds a small amount of complexity to
53
+ # the build and about 1.5MB of object code to the resulting binary. So we want
54
+ # to keep the number of hosts down when and if it's easy to, but having the
55
+ # number grow gradually is also not the end of the world.
34
56
35
- [dependencies .soroban-env-host-curr ]
36
- version = " =21.2 .0"
57
+ [dependencies .soroban-env-host-p22 ]
58
+ version = " =22.0 .0"
37
59
git = " https://github.com/stellar/rs-soroban-env"
38
60
package = " soroban-env-host"
39
- rev = " 8809852dcf8489f99407a5ceac12625ee3d14693"
40
-
41
- # This copy of the soroban host is _optional_ and only enabled during protocol
42
- # transitions. When transitioning from protocol N to N+1, the `curr` copy
43
- # (above) will bump its version to one that supports protocol N+1, and we will
44
- # simultaneously enable this `prev` copy by building with
45
- # `--feature=soroban-env-host-prev` and pointing its version and git rev to the
46
- # last soroban released to the network that speaks protocol N. When we deploy
47
- # this to a network running protocol N it will run on `prev` until the upgrade,
48
- # then switch from `prev` to `curr` at the upgrade, and then in the next release
49
- # we can turn `prev` off again.
50
- #
51
- # A note on `rev` hashes: When `prev` is disabled, the rust-analyzer IDE will
52
- # still want it to point to some version of soroban just for auto-completion
53
- # (because it builds with `--all-features`). To make this work, the `rev` spec
54
- # below has to be different from the `rev` spec in the `curr` copy of soroban
55
- # above. The easiest way to make this work is to just point to one git rev
56
- # before the rev specified for `curr`.
61
+ rev = " 81a4239f3e1ab5e4030140310faa64aba28dfdcb"
57
62
58
- [dependencies .soroban-env-host-prev ]
59
- optional = true
60
- version = " =20.3.0"
63
+ [dependencies .soroban-env-host-p21 ]
64
+ version = " =21.2.0"
61
65
git = " https://github.com/stellar/rs-soroban-env"
62
66
package = " soroban-env-host"
63
- rev = " 93120b6b32cd910fcc224cbf6aec1333f771a8bc"
67
+ rev = " 8809852dcf8489f99407a5ceac12625ee3d14693"
68
+
69
+ # The test wasms and synth-wasm crate should usually be taken from the highest
70
+ # supported host, since test material usually just grows over time.
64
71
65
72
[dependencies .soroban-test-wasms ]
66
- version = " =21.2 .0"
73
+ version = " =22.0 .0"
67
74
git = " https://github.com/stellar/rs-soroban-env"
68
- rev = " 8809852dcf8489f99407a5ceac12625ee3d14693 "
75
+ rev = " 81a4239f3e1ab5e4030140310faa64aba28dfdcb "
69
76
70
77
[dependencies .soroban-synth-wasm ]
71
- version = " =21.2 .0"
78
+ version = " =22.0 .0"
72
79
git = " https://github.com/stellar/rs-soroban-env"
73
- rev = " 8809852dcf8489f99407a5ceac12625ee3d14693 "
80
+ rev = " 81a4239f3e1ab5e4030140310faa64aba28dfdcb "
74
81
75
82
[dependencies .cargo-lock ]
76
83
version = " =9.0.0"
77
84
git = " https://github.com/rustsec/rustsec"
78
85
rev = " a5c69fc6e4b6068b43d7143f3a2f68c3f3de37d8"
79
86
features = [" dependency-tree" ]
80
87
81
- # This feature definition is implied by the optional=true line in the dep, but
82
- # writing it out in full here cross-checks that nobody _removed_ that line.
83
88
[features ]
84
- soroban-env-host-prev = [" dep:soroban-env-host-prev" ]
85
- tracy = [" dep:tracy-client" , " soroban-env-host-curr/tracy" ]
86
- core-vnext = [" soroban-env-host-curr/next" ]
89
+
90
+ # The tracy feature should enable the tracy features of all supported hosts.
91
+ tracy = [" dep:tracy-client" , " soroban-env-host-p21/tracy" , " soroban-env-host-p22/tracy" ]
92
+
93
+ # The "vnext" feature enables not-yet-released features that (a) break protocol
94
+ # but (b) are still under development, in between protocol releases. This
95
+ # feature is not enabled by default, and is only intended for temporary use when
96
+ # staging work across intra-protocol releases.
97
+ core-vnext = [" soroban-env-host-p22/next" ]
0 commit comments