@JoeJoeJoe 其实就算 $v2ex 交易频繁，由于所有的交易（打赏操作，交易 swap 操作）都只获取代币的账户的读锁，相当于打赏操作和愿意给更高 gas 费的交易 swap 操作并没有竞争关系，所以理论上来说 $v2ex 交易是否频繁对打赏交易的速度没有什么影响。

试了下现在的 $v2ex 打赏操作还是没有调用 SetComputeUnitLimit 指令，站长方便加上吗。
加上这条指令后，若保持设置的 Compute Unit Price 不变，总的 gas 费能省不少；若想给相同的 gas 费，平摊下来的 Compute Unit Price 也能提高不少，能够增加验证者处理打赏操作的意愿。
详见 https://ex.noerr.eu.org/t/1152743#r_16632641

@Cedric341561 #14 设置 cu price 这个指令消耗固定 150 的 cu ，打错了 https://i.imgur.com/Iy0taMy.png

https://solscan.io/tx/29K1qkR9U3v636KyBDyQ8Z49M4HZaJeaMgeLJbugQjffqD6EeYxnW2FhbN4FAkAhdVtUQRNr84EB3pEFJuHvVtfK
以这个打赏 $v2ex 的交易为例，有 4 条指令（设置 cu price ； Token Program 转账；和两条 Phantom 插件生成的断言指令）。

如果不设置 cu limit ，对于 builtin instruction （如设置 cu price/ 设置 cu limit / SOL 转账），默认是 3000 ；
对于非 builtin instruction （如 Token 转账，Phantom 插件生成的断言）默认是 200000.

所以上述交易默认是 3000 + 200000 + 200000 + 200000 = 603000 的 cu 上限。
计算下交易的优先费是 603000 (cu) x 5000 (micro lamports/cu) = 3015 lamports ，和 solscan 上的一致。

但是实际上真正消耗的有用的 cu 只有设置 cu price （固定的 300 ），Token 转账（ 4644 ），总共 4944 ，浪费了超过 100 倍。

建议在提交之前，先用 simulateTransaction 算一下要消耗多少 cu ，然后设置 cu limit ，这样就可以给较高的 cu price 了。

@Cedric341561 #8 诶，不对。构造的交易里应该全是 builtin instruction ，理论上不设置 cu limit 是没问题的。但是 phantom 插件自动给签名的交易加一个 lighthouse 的断言指令，这不是 builtin instruction ，导致增加了额外的 200000 cu limit.

另外现在 websocket 订阅交易状态用的 commitment 是 finalized ，这个需要等 32 个 block 。按平均 0.4s 一个 block 算，就要约 13s 了。其实用 confirmed 也就够了

可以给 txn 加一个 cu limit ，不加默认是 200000 ，但打赏远用不了这么多。这样就可以在保持总优先费不变的情况下给到更高的 cu price

支持一下