Refactor how the next available nonce is obtained

オープン
#5,666 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go

調査の方向性

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
平均マージ
2日 22時間
マージ済み PR(30日)
24

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ethersphere/bee のほかの issue

ethersphere/bee の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。