search

coral-xyz / anchor

⚓ Solana Sealevel Framework
https://anchor-lang.com
Apache License 2.0
3.35k stars 1.24k forks source link

Solana 2.0.0 breaks a lot of things #3044

Open cryptopapi997 opened 1 week ago

cryptopapi997 commented 1 week ago

I wrote a twitter thread about this explaining the issue, but wanted to open it here too to get people's takes on what's the best way forward. Solana 2.0.0 just dropped with a bunch of breaking changes, and a good number of spl programs restrict their solana version using <= 2.0.0 rather than <2.0.0 (e.g. https://github.com/solana-labs/solana-program-library/blob/master/token/program/Cargo.toml#L21). This means that these resolve to 2.0.0 where other dependencies resolve to 1.18.17 as they should, meaning a lot of things break.

One solution is to switch all dependencies with this from 3.0.2 to 1.0.1 (or whichever the last release was when these dependencies used <) but this probably breaks a bunch of other things. Another is to make anchor use 2.0.0, but this isn't a good solution for obvious reasons, as this means anchor programs won't be deployable until 2.0.0 hits mainnet. Last thing I can think of would be for Solana to release e.g. 3.0.3 which has < and 4.0.0 which has =, and anchor using 3.0.3, but this isn't likely either.

Would love to get your thoughts on this @acheroncrypto

acheroncrypto commented 1 week ago

Hey, thanks for creating the issue.

Having SemVer incompatible versions of the same package can lead to type incompatibilities since they are treated as different types, as also mentioned in https://github.com/solana-labs/solana-program-library/pull/6182.

We would also need to have the same requirements as SPL to make this work by default, which makes v2 completely pointless.

In the meantime, the easiest solution is to downgrade Solana dependencies to 1.18.17 by either manually editing the lock file, or simply running:

cargo update -p solana-zk-token-sdk@2.0.0 --precise 1.18.17
cryptopapi997 commented 1 week ago

Sounds good. Do you know what the path forward here looks like? Upgrade everything in anchor? Or should Anza/Labs release another spl version (that doesn't depend on 2.0.0) to address this?

acheroncrypto commented 1 week ago

I don't know how many other crates broke because of this, but Anchor is certainly not the only one. If we upgrade, then everybody else also needs to upgrade (recursively), which is what v2 should have aimed to solve (https://github.com/solana-labs/solana/issues/32503).

On the other hand, Solana and SPL repos have a circular dependency issue, making it difficult for Solana crates to bump breaking versions.

I think the best solution would be for SPL crates to publish a patch release to revert https://github.com/solana-labs/solana-program-library/pull/6182 and upgrade SPL crates to v2 (only v2) with a major release that Solana v2 crates should depend on. This way, however many downstream projects that broke because of this don't need to do anything.

While this solution is also not perfect, as it would result in type incompatibilities due to various dependencies depending on different versions of Solana crates, it's still much better than breaking existing crates that worked perfectly fine before v2 was out.

DemidovVladimir commented 2 days ago

Use spl-transfer-hook-interface v0.6.3 And cargo update -p solana-zk-token-sdk@2.0.1 --precise 1.18.17