Optimization proposal from Sculptex
- 主要语言
- Go
- 星标
- 28
- 派生
- 23
- PR 合并指标
- 30 天内没有已合并 PR
描述
https://discord.com/channels/992566329632641056/1045060754103078933/1373235805459316816
Quotes from the discord message from Sculptex:
I have an app that uses the cli tools on the back end to post transactions to the Blockchain (Solana + Züs). Now the miner Active Set is much smaller, just a small number of inactive miners has a more dramatic effect on tx times.
My understanding is that each tx is sent to a random subset of miners. If inoperative miners are included in this subset, then there is a 30s timeout experienced. This can clearly and consistently be seen, the times for cli tx commands to complete consistently falls in the range around 5-7 seconds, 35-37 seconds or even 65-67 seconds. This shows instances of timeouts. The 5+ odd seconds is consistent with a minimum number of blocks passing to ensure finalization which is fine, it's the clear stepping of additional 30 seconds that is a problem.
The simple fix is to reduce the default timeout for miner response in the order of a few seconds max, this way the tx will be retried much quicker with a different set of miners.
This will result in a much more consistent UX.
A different approach that I have had success with is to curate the Active Set list of miners to only include ones that are recently active, so instead of using mainnet/dns/network that returns the entire Active Set, you would have a service running that excludes any miners that are currently inactive, such as active/dns/network.


贡献指南
这个仓库没有索引到贡献指南
调研方向
查看 CLI 工具的交易发送逻辑(可能在 GoSDK 中),以找到选择矿工子集和设置超时的地方。该问题提到减少矿工响应的默认超时时间,并可能筛选 Active Set。首先检查网络调用函数和超时配置。测试更改需要理解交易流程,并可能需要设置测试环境来模拟矿工响应。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- go, shell
- 领域
- backend, cli, performance
- Issue 类型
- 功能
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 基本清楚
- 新手友好度
- 45/100