Refactor how the next available nonce is obtained

未关闭
  • 哪里不对？
#5,666 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
活跃
技术栈
go
领域
backend, distributed-systems

调研方向

Start by reading nextNonce() in the transaction package and the transaction send flows that call it, including how the mutex is acquired and pending transactions are stored on disk. Trace how concurrent sends obtain nonces and where each flow broadcasts and persists its transaction. Done means nonce allocation handles parallel sends without requiring each caller to manage the transaction lifecycle around an external mutex.

由索引模型根据 Issue 内容生成。

描述

Task

How it works now:
Before send any transaction, we need its nonce. nextNonce() in transaction package checks the latest nonce known onchain and among the pending transactions stored on disk. It picks the highest of them and then does +1

The problem:

  1. Two parallel calls receive the same nonce.
    This forces a mutex that blocks every transaction send until the current transaction has been broadcast and stored on disk. Because of that, all transaction sends line up in a queue.

  2. Contextual complexity.
    nextNonce() cannot be used as a black box: the mutex has to be taken outside the method. In each transaction flow developer must keep in mind transaction lifecycle.

AI Disclosure
  • This issue contains suggestions and text generated by an LLM.
  • I have reviewed the AI generated content thoroughly.
  • I possess the technical expertise to responsibly review the AI generated content mentioned in this issue.
主要语言
Go
星标
1.5k
派生
390
平均合并
3 天 5 小时
30 天内合并 PR
16

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ethersphere/bee 的其他 Issue

查看 ethersphere/bee 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。