#dusk $DUSK @Dusk
我得把這段內容讀了兩遍，因爲 HTTP 202 Accepted 通常會讓我大腦放鬆。
但在 Dusk 上，這可能不應該。
當 /transactions/propagate 返回 202 Accepted 時，該節點已經接受了該交易用於路由。
僅憑這點，並不能證明該交易：
已進入真實的內存池（memPool），
已到達各個節點（peers），
已成功執行，
或已最終確認（finalized）。
起初我覺得這只是過於技術化的區別。
後來我發現了更詭異的邊緣情況。
一個具有未來 nonce（隨機數/序號）的有效交易，可能會在預隊列（prequeue）中等待，直到缺失的 nonce 缺口被補齊。
所以你可能會收到一個“乾淨”的 API 返回，但此時交易仍然還沒到你大概率在意的那個階段。
這一點讓我不舒服。
很多基礎設施都建立在一種非常人類的捷徑之上：
API 說是（yes）→ 工作就完成了。
Dusk 的交易所集成指南卻做了相反的假設。
不能僅因爲傳播端點（propagation endpoint）返回了 202 Accepted，就把一次提幣（withdrawal）視爲已完成。執行與最終確認（finality）仍然需要被覈查。
而且如果傳輸層超時，更安全的恢復路徑是重新廣播同一個已簽名的交易（same signed transaction），而不是盲目再創建一個新的。
這就是爲什麼這裏不再只是對 HTTP 狀態碼的好奇。
如果交易所或錢包把傳輸層的接受（transport acceptance）誤認爲賬本已完成（ledger completion），那麼一個小小的集成捷徑就可能演變成記賬問題。
也許我是在夜裏把一個無聊的 API 響應想得太複雜了。
但我認爲有用的區別很簡單：
傳輸成功 ≠ 賬本成功。
在鏈上確認之前，API 也許就會先說“可以”。
我得把這段內容讀了兩遍，因爲 HTTP 202 Accepted 通常會讓我大腦放鬆。
但在 Dusk 上，這可能不應該。
當 /transactions/propagate 返回 202 Accepted 時，該節點已經接受了該交易用於路由。
僅憑這點，並不能證明該交易：
已進入真實的內存池（memPool），
已到達各個節點（peers），
已成功執行，
或已最終確認（finalized）。
起初我覺得這只是過於技術化的區別。
後來我發現了更詭異的邊緣情況。
一個具有未來 nonce（隨機數/序號）的有效交易，可能會在預隊列（prequeue）中等待，直到缺失的 nonce 缺口被補齊。
所以你可能會收到一個“乾淨”的 API 返回，但此時交易仍然還沒到你大概率在意的那個階段。
這一點讓我不舒服。
很多基礎設施都建立在一種非常人類的捷徑之上：
API 說是（yes）→ 工作就完成了。
Dusk 的交易所集成指南卻做了相反的假設。
不能僅因爲傳播端點（propagation endpoint）返回了 202 Accepted，就把一次提幣（withdrawal）視爲已完成。執行與最終確認（finality）仍然需要被覈查。
而且如果傳輸層超時，更安全的恢復路徑是重新廣播同一個已簽名的交易（same signed transaction），而不是盲目再創建一個新的。
這就是爲什麼這裏不再只是對 HTTP 狀態碼的好奇。
如果交易所或錢包把傳輸層的接受（transport acceptance）誤認爲賬本已完成（ledger completion），那麼一個小小的集成捷徑就可能演變成記賬問題。
也許我是在夜裏把一個無聊的 API 響應想得太複雜了。
但我認爲有用的區別很簡單：
傳輸成功 ≠ 賬本成功。
在鏈上確認之前，API 也許就會先說“可以”。
