Bump curve25519 test (do not merge)

[samkim-crypto]

Experimental PR to test CI on curve25519-dalek upgrade.

[samkim-crypto]

Sorry for the delay on this, but here is what I have found about the curve25519-dalek crate v4 slow-down:

• The slow down only occurs for the simd backend. It seems that with dalek-v3, the serial backend is chosen as default (hence no slow-down) while with dalek-v4, the simd backend is chosen as default (hence slowdown). If we override the default to the serial backend for dalek-v4, the slow-down does not occur.
• The simd slow-down occurs only in debug mode. If we actually test with release builds, then the dalek-v4 (or more precisely the simd backend) is actually ~30% faster.

We will generally always build with release mode for deployed code, so I think it is safe to make the upgrade to dalek-v4 (and it will actually be faster by ~30%). In the meanwhile, I will dig into the specific debug_assertions that may be causing the slow-down.

The question is how we should satisfy the CI tests. One option is to have the following line in .cargo/config.toml:

[target.'cfg(debug_assertions)']
rustflags = ['--cfg=curve25519_dalek_backend="serial"']

But .cargo is part of gitignore and it will not be ideal to add .cargo/config.toml to the repo. One option is to write .cargo/config.toml during the execution of downstream-project-spl-common.sh as is done in fa9163b above. We can see that the downstream CI now passes.

Wdyt @yihau @ilya-bobyr?

[yihau]

I think removing it from gitignore or writing it in the runtime are both work for me.

I’m just curious, which part got slow? iirc we encountered a POH record timeout. do we have any idea why the transaction execution time increase?

[samkim-crypto]

Transaction execution times do not increase with release build. It should actually be faster.

The transaction execution in tests increases because there the code is run in debug mode. It seems like there are a bunch of expensive debug_asserts that should be optimized away in release builds.