请教一个关于 priority fee 的问题

[Livid]

目前在实现 V2EX 的打赏功能的过程中，有一个可以设置的变量 priority fee 。

目前 V2EX 用的是一个非常低的值，来尽量让打赏不会消耗用户的太多 gas 。

但我不确定这个值是否会影响交易确认速度？也就是按下打赏按钮之后的那个等待时间。

有熟悉 Solana 系统的大佬可以指点一下吗？

[xiaxiao]

正常情况下不会。除非链上交易拥堵

[JoeJoeJoe]

我给你打赏的那个确实很慢, 比 sol 慢很多, 我都以为没点到.

我点完钱包的确认之后, 等了好一会, v 站的界面才刷过来.

[Tink]

刚试了一下体感上要比 solana 慢得多

[Livid]

@JoeJoeJoe
@Tink

考虑在界面上暴露这个值的设定让用户可以自己试验，目前默认值是 5000 micro-lamports 。

[JoeJoeJoe]

@Livid 这个 5000 好像是 solana 的默认值, 用户不一定知道是啥意思😂 但是我觉得我不是很关心这个事情的快慢, 除非我是批量打赏.

[yuhuazhu]

@Livid

建议把优先费暴露出来让用户选填，
我用 okx 钱包兑换的时候，走市价，虽然交易迅速但是优先费普遍很贵，
我修改为 0.00001 也能进行交易，后面又试了不同的都能正常交易，
在前两天 btc 猛涨的时候，交易量很多，优先费太小就很难成功交易了，大部分都是失败

[userlogin]

除了默认值，统计一下最近区块的计算一下最低，最高，均值？

[Cedric341561]

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

[Cedric341561]

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

[lucifer518]

是会影响的，越高越快
类似 evm ，priority fee = compute unit (micro lamports) * compute limit / 10^15 SOL
转账的话 compute limit 就默认 20W 就可以了
如果要参照链上的拥堵程度来变化，可以用 helius / quicknode 的 api 去获取

[Cedric341561]

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

[terryso]

priority fee 是给矿工的小费, 也就是在相同基础交易费（ base fee ）的情况下, priority fee 越高, 矿工就会越优先打包你的.
简单说, 在网络不堵塞的情况下, priority fee 设置多少是不是对于交易速度没多大影响.

但是一旦 sol 的网络节点堵塞你就要提高 priority fee 了, 要不没人帮你打包, 你要等很久.

[xspoco]

https://www.quicknode.com/gas-tracker/solana

[Cedric341561]

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]

@Cedric341561 #14 设置 cu price 这个指令消耗固定 150 的 cu ，打错了

[0x93ee]

其实可以参考有一下钱包的做法，提供三个交易上联速度，快，普通，慢，用户自己选择。对应的设置好 fee 的值。

[zankard]

solana 链在拥堵的时候，priority fee 基本上也没什么影响，这个链是有 Stake-Weighted Quality of Service 机制，
"This mechanism prioritizes network traffic based on the stake held by validators, ensuring those with more stake can send transactions with higher priority. SWQoS was designed to prevent low-staked validators from overwhelming the network, enhancing Solana’s resilience and efficiency."
https://www.helius.dev/blog/stake-weighted-quality-of-service-everything-you-need-to-know

就需要找像 helius 或者 jito 的服务来发交易，是比较有保障，且快一些。

[lyric]

不做交易的话低点没问题，慢点没关系。

[luozhsky]

priority fee 的运作机制就是激励矿工优先打包。
但是更多还是用于打狗和交易，v2 这种打赏场景实际用户都不一定在线，对于成交速度没那么高的要求吧。
按 solana 的 tps 差个几秒的成交速度对用户来说是没有感知的。
比如站长昨天的打赏今天我才看到。。😂