feat(reservations): escrow-backed reservations
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
調査の方向性
Read quantum_backend_v2/reservations/service.py and reservations/models.py to understand the reservation transitions, then inspect the credit ledger work in issue #3 and recovery in runtime/recovery.py. Define and test how each terminal state produces exactly one ledger outcome, how holds appear in the reservation API response, and how restart recovery restores or releases them. The issue calls for state-machine tests across transitions and recovery; on-chain escrow is a separate optional phase.
索引モデルが issue の本文から書いたものです。
説明
Summary
Tie the reservation state machine to funds: lock on COMMITTED, release on EXECUTED, refund on EXPIRED or CANCELED.
Motivation
Reservations already model intent to use a node. Backing them with a hold makes no-shows and cancellations costly and protects workers.
Current state in this repo
quantum_backend_v2/reservations/service.pyandreservations/models.pyimplement REQUESTED -> PREPARED -> COMMITTED -> EXECUTED/EXPIRED/CANCELED.
Proposal
- Phase 1: ledger-only holds using the credit ledger (#3).
- Phase 2 (optional, separate PR): on-chain escrow on a registry EVM chain, reusing the Aave-based escrow pattern from proposals or a minimal escrow contract.
- Define timeouts so holds cannot be stuck: expiry always results in release or refund.
Acceptance criteria
- Every terminal reservation state results in exactly one ledger outcome (capture, release or refund).
- Holds are visible on the reservation API response.
- Crash recovery (
runtime/recovery.py) restores or releases holds.
Out of scope
- Writing production-audited smart contracts; any contract in Phase 2 stays testnet-only until audited.
Dependencies
- #3
- #8
Testing plan
- State-machine tests covering every transition and restart recovery.
Part of ##1. Ground rules for all issues in this roadmap are listed there (testnet-first, no secrets in the repo, chain logic behind the registry, tests and docs with every PR).
- 主要言語
- Python
- スター
- 2
- フォーク
- 4
- 平均マージ
- 6時間 14分
- マージ済み PR（30日）
- 18
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
QMeshPy/distributed-quantum のほかの issue
-
enhancement good first issue helia storage tier-1
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
QMeshPy/distributed-quantum#53 ·
メンテナーはふだん 1 日以内に返信
-
chain-integration enhancement payments research-spike tier-2
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
QMeshPy/distributed-quantum#78 ·
メンテナーはふだん 1 日以内に返信
-
chain-integration enhancement payments research-spike tier-2
難易度 3/5 1〜2日 初心者へのやさしさ 66/100
QMeshPy/distributed-quantum#77 ·
メンテナーはふだん 1 日以内に返信
-
documentation good first issue kubo storage tier-1
難易度 2/5 1〜3時間 初心者へのやさしさ 42/100
QMeshPy/distributed-quantum#75 ·
メンテナーはふだん 1 日以内に返信
-
enhancement kubo storage tier-2
難易度 4/5 3〜5日 初心者へのやさしさ 56/100
QMeshPy/distributed-quantum#74 ·
メンテナーはふだん 1 日以内に返信
QMeshPy/distributed-quantum の issue をすべて見る
似ている issue
-
Project submission:オープン
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
slavakurilyak/awesome-ai-agents#845 ·
メンテナーはふだん 1 日以内に返信
-
tests: pin that the atomic writers in utils/paths.py stage the temporary file in the target's directory対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンdifficulty:2 enhancement good first issue
難易度 1/5 1〜3時間 初心者へのやさしさ 92/100
MakazhanAlpamys/Soup#2178 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] dcg.waggr permutation p-values are folded twice, so near-zero scores get the smallest p-valuesオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
scverse/rapids-singlecell#854 ·
メンテナーはふだん 1 日以内に返信
-
Slang input: int8_t4_packed and uint8_t4_packed are copied into CrossGL対応中かも @ninglinLiu が今日担当しました。 オープンarea:frontend backend:slang bug direction:input
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 13 日以内に返信