本指南提供相關建議，確保 Universal Ledger 用戶端實作項目能安全可靠地與網路互動。您可以瞭解如何執行下列作業：
- 利用網路拓撲實現高可用性。
- 提交交易並瞭解執行結果。
- 實作輪詢、逾時和重試策略。
網路拓撲和高可用性
通用帳本網路是由多個驗證器組成，這些驗證器分布在多個區域和地區，因此可確保整個網路的高可用性。
區域故障：如果 Cloud 區域內的單一驗證器發生故障，同一區域內的其他驗證器會繼續處理要求，不會受到影響。
區域中斷：如果整個區域無法使用，其他區域的驗證器仍可運作。如要繼續提交交易，用戶可以安全地回溯，並嘗試透過其他端點重新提交交易。
交易執行特性
不可分割的執行作業：交易不是完全成功就是完全失敗。 系統絕不會執行部分交易，例如因餘額不足而只轉移部分要求金額。這包括交易鏈，可讓您將多個任意交易合併為單一原子序列。
不會自動重試：網路會嘗試執行提交的交易一次。如果執行失敗，帳本不會自動將交易排入佇列或重試。
冪等重新提交：每筆提交的交易都會根據確切的序列化酬載 (包括序號和傳送者) 產生專屬交易 ID。多次提交完全相同的酬載會產生相同的交易 ID。帳本可確保交易最多執行一次，因此如果其中一個端點無法使用，可安全地將相同交易酬載重新提交至其他端點。
詳情請參閱
SubmitTransactionRequest參考頁面。
延遲、輪詢和重試策略
提交交易時，驗證器會先快速檢查，確保簽章和序號有效。如果成功，通用帳本 API 會立即傳回 SubmitTransactionResponse，包括指派的交易 ID。
大多數交易會在 3 秒內完成。如要檢查交易狀態，請使用提供的交易 ID 輪詢 QueryTransactionState 方法。
如果交易狀態仍為
PENDING，請使用指數輪詢策略再次擷取狀態。例如，以 3 秒、9 秒、27 秒和 60 秒為間隔查詢。如果
QueryTransactionState傳回NOT_FOUND，請重新提交交易。
交易嘗試FINALIZED後，回應也會包含 TransactionCertificate，其中包含各種詳細資料，例如：
- 交易完成時的輪次 ID。
- 執行狀態 (正常或失敗)。
- 交易事件，包括任何交易輸出內容。
逾時通訊協定
萬一交易在 60 秒後仍處於 PENDING 或 NOT_FOUND 狀態，請假設為您提供要求的驗證器無法跟上網路中其他驗證器。請完成下列步驟：
- 在其他網路區域中選取其他端點。
- 重新提交完全相同的簽署交易酬載。
- 請傳送電子郵件至 gcul-help@google.com 回報問題，以便 Universal Ledger 團隊進行調查。
檢查交易狀態時，如果多次提交相同酬載，回應可能會包含多則 TransactionAttempt 訊息。最多只會有一筆交易嘗試以「OK」交易狀態完成，並顯示在 TransactionEffects 中，其他嘗試則會處於待處理狀態或失敗狀態。這是預期行為；帳本已成功執行其中一項交易提交作業，並正確拒絕或最終會拒絕重複提交的作業。
網路一致性
完成的交易：一旦某個驗證器將交易回報為完成，同一網路上的所有其他驗證器最終都會處理該交易，並產生完全相同的結果。提交
QueryAccountRequest時，請使用交易完成時的輪次 ID，因為該 ID 位於TransactionCertificate中， 所有已同步的驗證器都會產生相同的結果。未完成的交易：交易會在網路上非同步傳播，因此不同驗證器回報的交易完成狀態可能有所不同。
驗證器從中斷狀態恢復或發生同步延遲時，可能會暫時將最終交易回報為
PENDING或NOT_FOUND。驗證器趕上進度後，交易狀態就會解決。
用戶端責任和錯誤處理
交易追蹤：用戶端應用程式必須追蹤所有已提交交易的狀態，直到交易完成為止。
錯誤處理：如果交易失敗，請擷取並檢查
TransactionCertificate中包含的失敗詳細資料，以觸發適當的商家層級補救措施。
後續步驟
- 瞭解如何傳送 RPC 要求至 Universal Ledger API。
- 請參閱 Universal Ledger API 參考資料。