Repository navigation
feat(cli): use transaction v1 when writing program buffers - #5095
Conversation
|
@rute-sophie is attempting to deploy a commit to the OtterSec Team on Vercel. A member of the Team first needs to authorize it. |
|
Can you address the failures? |
|
Hi @jamie-osec , I analysed the test failures and found one blocker plus a rust MSRV that needs some input before further action. Currently, the most recent version of The template tests are failing due to rust MSVR. It is currently applied in 4 different places on that specific template matrix: Is it acceptable to have such a mix of versions (e.g. by defining a |
Which crates require this? Upstream still seems to pin 1.89.0 as the MSRV: https://github.com/anza-xyz/solana-sdk/blob/fc89c122394e003d05b52aca81a6fb8ba5a8d306/Cargo.toml#L125 You'll also need to rebase on master, as there were recently a lot of changes to dependencies, introducing 4.3.0 crates to the workspace behind a feature flag. |
|
hey @jamie-osec The 4.3.0 RPC/client crates come from the Agave workspace root 4.3.0, sets Each of this crates inherits it with
These are direct dependencies of |
|
Hi @rute-sophie, I think this PR depends on (and now partially duplicates) #5123, which bumps |
|
Oh I just noticed you're targeting anchor-next here. CLI development happens in master; please retarget your branch. This will likely produce a lot of conflicts, the anchor-next CLI is very out of date. We recently updated our toolchains, so we can look into bumping our MSRV to a more recent version. |
|
@jamie-osec @gwalen So I will first wait for #5123 to be merged, then I will rebase and resume my work |
|
I have closed that PR because it There shouldn't be any other Anchor-side blockers to this, just make sure to rebase and retarget the PR on master. |
|
@rute-sophie Are you currently working on this? |
|
Yes, almost done testing. I will update the PR today |
|
Hi @jamie-osec, I've updated the PR and retargeted the merge to Took me a while longer as I wanted to preserve the QUIC connection, but the API change to solana-tpu-client-next was too drastic and my initial implementation was not working properly. Let me know if you want any changes. |
|
This doesn't compile on v4 for me: $ cargo +stable build -p anchor-cli --locked --no-default-features --features solana-v4
[ ... ]
error[E0308]: mismatched types
--> cli/src/program.rs:2994:38
|
2994 | if instructions.len() == instructions_per_transaction {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `usize`, found `u32`
error[E0277]: can't compare `usize` with `u32`
--> cli/src/program.rs:2994:35
|
2994 | if instructions.len() == instructions_per_transaction {
| ^^ no implementation for `usize == u32`
|
= help: the trait `PartialEq<u32>` is not implemented for `usize`
help: `usize` implements trait `PartialEq<Rhs>`
--> /rustc/48a229ceaefd4985c50990b14116b6d856af0985/library/core/src/cmp.rs:1876:12
|
= note: `PartialEq`
::: /rustc/48a229ceaefd4985c50990b14116b6d856af0985/library/core/src/cmp.rs:1900:5
|
= note: in this macro invocation
|
::: /Users/jamie/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/serde_json-1.0.151/src/value/partial_eq.rs:76:13
|
76 | impl PartialEq<Value> for $ty {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `PartialEq<serde_json::Value>`
...
97 | / partialeq_numeric! {
98 | | eq_i64[i8 i16 i32 i64 isize]
99 | | eq_u64[u8 u16 u32 u64 usize]
100 | | eq_f32[f32]
101 | | eq_f64[f64]
102 | | eq_bool[bool]
103 | | }
| |_- in this macro invocation
= note: this error originates in the macro `partial_eq_impl` which comes from the expansion of the macro `partialeq_numeric` (in Nightly builds, run with -Z macro-backtrace for more info) |
- batch 3 write instructions per transaction with max data size (1232-bpf loader instruction overhead) - add new transaction v1 compute unit and data loaded size limits - adopt the new `send_and_confirm_transactions_in_parallel_v3` API from solana_client v4.3
…sion specific deploy logic
|
@jamie-osec rebased and implemented your suggestion. Let me know if you have more suggestions. |
| # anchor-lang/anchor-client and Cargo unifies features across the workspace, so | ||
| # it has to follow the same Solana cohort as everything else. See the comment | ||
| # block in the root Cargo.toml. | ||
| default = ["solana-v3"] |
There was a problem hiding this comment.
Just noting that this won't actually be enabled by default. However, I think we should explore potentially making solana-v4 the default for the CLI in the next release.
There was a problem hiding this comment.
For a followup PR of course
Summary
This PR changes the program deployment to use transaction V1 when writing the program buffers and chunks the
writeinstructions in 3 per transaction.In the future, when anza-xyz/agave#15356 (comment) is solved, we will be able to better use the transaction data.
Tested on devnet: https://explorer.solana.com/tx/jXzxi4C1sUkUcw7cBEnx6buMJoWdzJz3SzzMC6XxbJNRfFwAcs4nFQ3qv9KKUrDQ3mkGm7aptbofWcHY4Nysay2?cluster=devnet
Additional changes
The new
send_and_confirm_transactions_in_parallel_v3doesn't dedup like its predecessor nor it blocks in-place so it required some extra plumbing similar to what was in thesend_and_confirm_transactions_in_parallel_blocking_v2impl.Using the new compute unit limit and loaded data size limit in transaction v1 headers. Without a valid loaded data size the transaction is discarded.