各位有沒有發現任務的期限縮短了
---
**2026 年 1 月 20 日**

我們已調整 batch（批次）計畫。
目標是讓整體週轉時間更短。
多數系統都能在這個時間範圍內完成計算。

在新的驗證器（validator）機制下，
「截止時間（deadline）」的概念也明顯不同了。

現在的流程是：

* 只要我們手上有 **2 份結果**，就會「立即」嘗試驗證（validate）。
* 如果結果多於 2 份，也會一併使用額外結果。
* 接著會把**已完成運算並回報結果**的人算入積分。
* 然後把該 workunit（工作單元）標記為完成。

---

新的截止時間設計，重點是「更快把工作做完」。

因此：

* 最先拿到結果 _0 與 _1 的兩位 wingman，期限是 **3 天**。
* 過了期限後，transitioner 可能會注意到：

* 其中一個尚未回報，或
* 兩個都尚未回報。
* 這時，系統會補發（resend）。
* 下載補發 _2 的那位 wingman，也會有 **3 天**期限。
* 之後會每隔 **3 天**，重複這種補發與等待流程。

直到觸發以下任一上限為止：

* `maxError`（最多錯誤）= 5
* `maxCreatedForAnyReason`（不論原因最多建立次數）= 10
* `maxReturnedSuccessfully`（最多成功回傳數）= 7

---

我們不希望一直發送「不管誰拿到都只會錯誤」的 workunit。

例如：

* 如果已經建立到 10 次，還有人回傳 _9 結果，
代表狀況不正常。
應該停止。

又例如：

* 如果已經有 7 份成功結果，理論上都能驗證與給分，
那也代表不正常。
* 因為新系統強調：

* 正常應該在取得 2 份結果後就結束；
* 最多也只會因為「原本以為會超時的 wingman」在截止後不久才回傳，
因而接近 3 份結果就結束。

---

較短的截止時間，能讓補發（resend）更快把 workunit 收尾。

特別是未來我們開始跑：

* MAM1
* MCM2
-（以及 ARP1）

差異會更大。

原因是：

* 之後不再是「隨機搜尋」。
* 會改成「目標式搜尋」。
* 依據上一輪的最佳結果，來決定下一輪的搜尋方向。

因此：
同一組參數的結果回來越快，
我們探索搜尋空間的速度就越快。

---

補發（resend）也會沿用原 workunit 的延遲上限。
也就是 **3 天**。

transitioner 會參考資料庫中該 workunit 的建立紀錄。
因此它會「間接」引用同一個參數來源：
也就是從 batch plan 發佈到 Redpanda 的那些參數。

---

關於積分（credit），我們之前的說法沒有傳達清楚。

正確規則是：

* `IN_PROGRESS` 狀態的結果 **不會給分**。
* 在 deadline 之後才上傳的結果 **也不會給分**。

會拿到積分的是：

* 第一組達到 quorum（門檻）= 2 的成功結果（SUCCESS）。

另外還有一種情況也會給分：

* 如果有其他結果在 deadline 前就已上傳並回報，
* 且在 validator 重新掃描「eligible（可處理）」工作池、分批處理時，
剛好處理到這組結果之前，
那些「已回報」的額外結果也會一起獲得積分。

一旦 workunit 被結束：

* 那些「還在跑、但尚未回報結果」的 wingman，
會被標記為過期（expired）。

---

所以結論是：
並不是「所有目前正在處理的人都會拿到積分」。

真正的意思是：
**只有在 validator-assimilator daemon 檢查到至少 2 個 SUCCESS 結果、
並且實際強制執行 deadline 之前，
已經完成計算且成功回報結果的人，才會得到積分。**

---