使用 Cedar 評估政策

本頁面說明多方運算 (MPC) 政策引擎如何評估以 Cedar 政策語言編寫的交易政策、處理跨鏈情境，以及解析選用或省略的中繼資料欄位。

核心評估原則

政策引擎會使用 Cedar 政策語言，授權加密簽署作業。引擎會使用三個基本公理，以確定性方式評估政策：

  1. 預設拒絕：所有作業都會隱含拒絕。作業必須至少與一項有效的 permit 政策相符，才能執行。如果找不到相符的 permit 政策，最終決策會是 DENY。
  2. 明確禁止：forbid 政策會絕對覆寫其他政策。如果作業符合任何有效的 forbid 政策，系統會立即將決策解析為 DENY，無論是否有任何相符的 permit 政策允許該作業。
  3. Missing Fields Just Mean "No Match" (Skip)：如果規則尋找的欄位不存在於交易酬載中 (例如省略的選項欄位)，Cedar 不會當機，系統會將該規則視為「不相符」(評估結果為 false)，並繼續評估下一項規則。

邏輯評估矩陣

下表說明政策引擎如何評估規則組合。

所有情境皆假設：

  • 交易呼叫端 (在 Cedar 政策中以主體表示) 是 Alice (User::"alice")。在多方運算中，主體代表要求授權加密簽署作業的角色或身分 (例如人類簽署者、自動化服務用戶端或後端系統帳戶)。
  • 這筆交易會轉移剛好 1 ETH (在 context.transaction.spend_amount_scaled 中以 1,000,000,000 個縮放奈米幣單位表示)。
情境 有效政策 結果 原因
情境 1：空白狀態 沒有任何執行中的政策。 DENY 根據預設，除非相符的 permit 政策明確允許，否則所有作業都會遭到封鎖。
情境 2：單一許可證相符 
permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 10000000000
};

最多可存入 10 ETH

 PERMIT 交易參數符合政策條件。由於沒有衝突的 forbid 政策，因此要求獲准。
情境 3：單一許可證不符 
permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 500000000
};

最多可存入 0.5 ETH

 DENY 轉帳金額 (1 ETH) 超出政策限制。由於不符合任何相符的 permit 規則，預設拒絕規則會封鎖交易。
情境 4：多項允許政策

政策 A：

permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 500000000
};

最多可存入 0.5 ETH

政策 B：

permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 5000000000
};

最多 5 ETH

 PERMIT 雖然政策 A 不符合，但政策 B 符合。只要有一項相符的 permit 政策，即可允許交易。
情境 5：允許和禁止衝突

政策 A (允許)：

permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 5000000000
};

最多 5 ETH

政策 B (禁止)：

forbid(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.recipient == "0xBlockedAddress"
};

假設目的地為 0xBlockedAddress

 DENY 轉移作業會傳送至 0xBlockedAddress。雖然政策 A 允許交易金額，但目的地符合政策 B 的條件。明確的 forbid 規則會覆寫政策 A，並封鎖交易。
情境 6：不相符的禁止政策

與前一個情境相同的政策

 PERMIT 轉移作業會傳送至安全地址 (例如 0xSafeAddress)。政策 A 成功比對，政策 B 則因目的地不是 0xBlockedAddress 而未比對。如果沒有相符的禁止規則，系統會套用允許規則。

多鏈和選填欄位情境

雖然上述矩陣展示了允許和禁止規則的核心邏輯優先順序，但以下情境說明瞭政策引擎如何在多鏈環境中評估規則：特別是在針對選填欄位或不同區塊鏈網路結構定義執行時。

注意： 零值資料正規化 為避免發生非預期的評估錯誤，並確保政策可預測性，政策引擎的剖析層會將評估環境中未填入值的字串和位元組欄位，正規化為特定類型的零值 (例如空字串 "" 或空位元組陣列)，而非省略這些欄位。

這樣一來，您就能針對未填入資料的欄位，制定明確的政策，而不必擔心 Cedar 評估錯誤。不過，如果存取的欄位在區塊鏈結構定義中完全未定義 (例如比特幣交易中僅限 EVM 的 gas_limit，或 EVM 交易中僅限比特幣的 outputs)，會導致該特定政策發生 Cedar 評估錯誤，評估結果為 false (不相符)，並安全地失敗關閉。

情境 7：跨鏈政策評估和未對應的結構定義屬性

  • 背景資訊：呼叫端提交比特幣交易。不過，使用中的政策組合包含一項以太坊專屬政策：

    permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.schema == "ethereum.transaction.v2" &&
  context.transaction.gas_limit < 100000
};

  • 結果： DENY

  • 原因：通用意圖屬性 (例如 spend_amount_scaled、recipient 和 max_fee_atomic) 在以太坊和比特幣交易中，評估方式都一致。如果政策參照的鏈結專屬屬性不存在於提交交易的結構定義中 (例如比特幣交易的 gas_limit)，Cedar 會將不相符的屬性視為評估失敗，並將該特定政策解析為 false (不相符)，但不會停止引擎。由於沒有其他有效的 permit 政策與比特幣交易相符，因此系統預設會拒絕這項作業。

情境 8：permit 政策缺少選填欄位

  • 背景：呼叫端提交標準 ETH 轉帳 (不使用智慧型合約)。有效政策組合包含檢查合約互動的規則：

    permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == "0x1111111111111111111111111111111111111111"
};

  • 結果： DENY

  • 原因：標準 ETH 轉帳不會填入選用的 asset_contract_address。剖析器會將其正規化為評估情境中的零值空字串 ""。評估比較 "" == "0x1111..." 會傳回 false (不相符)，而不是引發錯誤。由於沒有其他政策允許轉移，因此系統預設會拒絕這項作業。

情境 9：forbid 政策缺少選填欄位

  • 背景：呼叫端提交 10 ETH 的標準 ETH 轉帳。政策組合包含：

    • 政策 A (允許)：

      permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled <= 100000000000
};

    • 政策 B (禁止)：

      forbid(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == "0xBannedContract"
};

  • 結果： PERMIT

  • 原因：10 ETH 低於上限，因此政策 A 成功比對。政策 B 會檢查合約地址是否與禁止地址相符。由於零值正規化，未填入的合約地址會解析為 ""。評估比較 "" == "0xBannedContract" 會傳回 false。由於禁止政策不相符，而允許政策相符，因此交易獲准。

情境 10：明確檢查空白或缺少的欄位

  • 背景資訊：呼叫端提交標準 ETH 轉帳 (未傳送至智慧型合約)。政策組合包含：

    • 政策 A (允許)：

      permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled <= 1000000000000
};

    • 政策 B (禁止)：

      forbid(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == ""
};

  • 結果： DENY

  • 原因：由於剖析器正規化，缺少的 asset_contract_address 在評估情境中會顯示為空字串 ""。評估政策 B 後，條件會解析為 true ("" == "")。forbid 政策相符，因此交易遭拒。

預先評估驗證 (快速失敗閘道)

政策引擎會強制執行嚴格的資料驗證。在將酬載傳遞給 Cedar 進行政策評估之前，基礎剖析器會驗證交易結構、RLP 編碼和密碼編譯完整性。

情境 11：交易酬載格式錯誤和無效

  • 背景：用戶端提交格式錯誤的位元組序列、結構無效的酬載，或缺少必要密碼編譯欄位的交易 (例如 RLP 結構無效或缺少 gas 參數的 EVM 交易)。
  • 結果： gRPC InvalidArgument
  • 原因：內部交易剖析器在 API Gateway 層偵測到無效輸入。作業會立即失敗並關閉，向用戶端傳回 gRPC InvalidArgument 錯誤，並完全略過 Cedar 政策引擎的評估。