Do Solana validators prioritize transactions with security assertions?

[geoshak]

We have an app that interacts with our Solana program at:
https://explorer.solana.com/address/iLEPWontSkuaCDeg8psrxB3mVHAA39fWWRtinSJcrtJ

I'm signing solana transactions in typescript,
by two means:

1. transactions signed by native solana browser extensions (SolFlare, Phantom) when sent using @solana/wallet-adapter-react useWallet sendTransaction

2. transactions signed via Magic.link's magic-sdk and then sent using a connection to RPC node created with @solana/web3.js

Option 1 is super fast, validated/confirmed in 3 to 4s

Option 2 (Magic) takes forever (up to 1 min), and most often fails

while inspecting the differences, I found out that on option 1) the transaction object has a 'compiledInstructions' array with five (05) instructions

but on option 2), even after signing, 'compiledInstructions' has only one (02) instructions

I found out that the instructions that are added by the wallet extensions are:

setComputeUnitLimit instruction

The other two that talk to the Lighthouse (Assertion Solana Program), as below:

#4 - Unknown: Unknown
Raw Interact With Unknown

L2TExMFKdjpN9kozasaurPirfHy9P8sbXoAN1qA3S95
Input Accounts
#1 - Account: AZAh9d3pdD9JaMFy734T1p9Yi1bUjHeYHUv2m8oqgncm Writable Signer Fee Payer
Instruction Data
3zkF6GTy

#5 - Unknown: Unknown
Raw Interact With Unknown

L2TExMFKdjpN9kozasaurPirfHy9P8sbXoAN1qA3S95
Input Accounts
#1 - Account: EPbrYBp5oCEb7eb6FtULdizy5CuESJLsgdfhbiJonTfS Writable
Instruction Data
8A8uiXy3AqR3n36X8SDrAtaSmDj5DpjX3bSqGkDY2g5iayUejwhgx4BUHD6F3KU7V89M
The above transaction sent with wallet extension is:
https://solscan.io/tx/UYceY467QU39u9pb9eLkbwJ9kT9hUj2NAe1eMwHN3SpAwY6Vvm8ou28aT6q41JR4i2RmQZjVVcYAFvMxUoNkZC5

An example of the txn signed and then sent with Magic is:
https://solscan.io/tx/2dx9gHfb5CygoLUGpWm1Pwmcv2uPp7fojrtyxHJddi8SWbqHqM9XA4AhCbgDmPAtujy8iVfzb7sWdv566MQVMD7x
(already added the computeLimit instruction to this one, but didn't solve the issue)

I'm trying to add the Lighthouse assertion instructions to the txn to be sent with Magic too.
But after days debugging this, I'm not sure it's the right path.

I failed trying to run the latest lighthouse-sdk with our app, which uses @solana/web3.js 1.95 still.

I tried to install @solana/web3.js v2 and use it with lighthouse-sdk, but no good.

Then I copied over the code from the SDK into my local files, tried to import stuff directly from solana/web3 v2, no good.
I spent some 2 hours reading the source code, console.logging, trying to get a handle on the encoders logic.
I'm making process, but excruciatingly slowly. We lost a bunch of users cause Magic txns are not going through.
I'm asking for help anywhere I can.

Any pointers?

[geoshak]

Just saw the instructions on how to use lighthouse-sdk-legacy.
Trying it out now.

[geoshak]

Can´t use it out-of-the-box either, it seems, I get a:

Uncaught Error: Module not found: Package path ./dist/lib/client is not exported from package .../zbet-web/node_modules/rpc-websockets (see exports field in .../zbet-web/node_modules/rpc-websockets/package.json)

[geoshak]

Tried to install this repo and run the tests locally. But I'm getting a lot of crate compatibility errors.
Seems like rust compiler can't find compatible candidates on crates.io:

    Updating crates.io index
error: failed to select a version for the requirement `spl-pod = "^0.1.1"`
candidate versions found which didn't match: 0.5.0, 0.4.0, 0.3.1, ...
location searched: crates.io index
required by package `spl-token-2022 v2.0.1`
    ... which satisfies dependency `spl-token-2022 = "=2.0.1"` of package `lighthouse-program v2.0.0 (/media/st/Rígido/perion/lighthouse/programs/lighthouse)`

I'm running Linux Mint 21.1
kernel 5.15.0-126-generic

I have used this same env to compile and deploy Solana programs, so libraries/compilers are healthy afaik (cargo, rust, etc).

[geoshak]

For anyone facing a similar compiler issue, I had to manually patch 7 crate versions to get cargo update to work.
However, compilation with cargo build still failing. Some traits conflicts between crates.

[patch.crates-io]
solana-program = { git = "https://github.com/solana-labs/solana", tag = "v1.18.8" }
solana-program-test = { git = "https://github.com/anza-xyz/agave", tag = "v1.18.8" }
spl-pod = { git = "https://github.com/solana-labs/solana-program-library", rev = "950efde" }
spl-transfer-hook-interface = { git = "https://github.com/solana-labs/solana-program-library", rev = "950efde" }
spl-type-length-value = { git = "https://github.com/solana-labs/solana-program-library", rev = "950efde" }
solana_rbpf = { git = "https://github.com/solana-labs/rbpf", tag = "v0.8.0" }

[geoshak]

I was able to install lighthouse-sdk-legacy by manually editing the node_modules installed.
Specifically the solana web3 imports that were failing to identify .cjs files as default exports from a folder.

Adding the .cjs extension to the imports in the solana packages (in node_modules) solved the issue.

[Jac0xb]

Seeing this now, will look into it. Sorry for all the issues I will go individually and fix them. But no, solana validators do not prioritize lighthouse assertions, setting competitive priority fees, broadcasting to multiple RPCs, broadcasting to stake weighted RPCs, retry 0 in rpc method config, etc. See:

https://www.helius.dev/blog/how-to-land-transactions-on-solana
https://docs.helius.dev/guides/sending-transactions-on-solana#staked-connections

[geoshak]

Thanks @Jac0xb! We are now implementing dynamic.xyz.
Looking forward to see how they perform.

We are using the VeryHigh fees from Helius fees API, using a staked RPC node, with 0 retries. Haven't tried broadcasting to multiple RPCs though. Good to know that is possible.