ポリシーの作成

ポリシーは、リクエストの署名をブロックできる一連のルールです。署名リクエストには、ブロックチェーン・トランザクションと、EIP-712型付きデータなどのデータへの署名リクエストが含まれます。各ストアド・ルールには、スコープ、条件およびBLOCKレスポンスがあります。有効化されたルールは累積的に適用されます。適用可能なルールが一致した場合、リクエストは拒否されます。

ポリシー評価が正常に完了し、適用可能なルールがBLOCKレスポンスを返さない場合、UWaaS Wallet Manager (UWM)によってコール元が認証され、ウォレットとキーが認可されて署名リクエストが検証された後、リクエストを続行できます。

UWaaS Wallet Managerの詳細は、Universal Wallet as a Service (UWaaS)を参照してください。APIリクエスト・フィールドおよび操作については、次を含むUniversal Wallet Manager APIを参照してください:

ルール条件の定義

ルールは、条件をall、anyおよびnotと組み合せます。次のグループをネストして制限を定義できます。

allは、すべての子条件が一致する場合に一致します。
anyは、少なくとも1つの子条件が一致する場合に一致します。
notは、その子条件が一致しない場合に一致します。

条件グループをインラインで定義します。名前付き条件参照は、UWM署名ルールではサポートされていません。

条件リーフでは、ファクト、演算子および値を指定します。pathを使用して、ファクトからネストされたプロパティを選択します。高いpriority値が最初に評価されます。

{
  "fact": "to_address",
  "operator": "in",
  "value": ["<blocked-address>"]
}

in演算子は、ファクトがリストされた値のいずれかに等しい場合に一致します。allを使用して、この条件をoperation条件と結合します。制限をトリガーできる条件が複数ある場合は、anyを使用します。

演算子

演算子	使用するタイミング
`equal`, `notEqual`	スカラー・ファクトは、同じ型の値と等しいか、または異なる必要があります。
`in`, `notIn`	スカラー・ファクトは、値リストに表示されるかどうかに関係なく指定する必要があります。
`contains`, `doesNotContain`	配列ファクトには、値が含まれているか、含まれていない必要があります。
`lessThan`, `lessThanEquals` (`lessThanInclusive`)	数値ファクトは、数値以下である必要があります。
`greaterThan`, `greaterThanEquals` (`greaterThanInclusive`)	数値ファクトは、数値以上である必要があります。

amount、amount_atomicおよびnative_value_atomicでの順序付き比較では、/evaluateと/internal/v1/authorizeの両方で正確な10進数演算が使用されます。

原子量と大きなしきい値には10進文字列を使用します。たとえば:

{ "fact": "amount_atomic", "operator": "greaterThanEquals", "value": "1000000000000000000" }

UWMは、amount_atomicを基本単位で指定し、トークン小数に変換しません。amountファクトは、/evaluateのコール元によって指定される場合にサポートされ、UWMは署名ファクトに追加しません。

安全な数値範囲内の10進数のJSON番号が受け入れられます。大きい数値を文字列として送信します。大きい数値リテラルは拒否されます。greaterThanInclusiveおよびlessThanInclusive演算子名は、引き続きサポートされます。equalおよびnotEqual演算子は、値をタイプ別に比較します。その他のファクトは、既存の比較動作を保持します。

配列デコレータ

演算子の前にデコレータとコロンを付けます(someFact:equalなど)。デコレータは、演算子による配列またはその結果の処理方法を変更します。

デコレータ	使用するタイミング
`someFact`	配列ファクトの少なくとも1つの項目が一致します。
`everyFact`	配列ファクト内のすべての項目が一致します。
`someValue`	ファクトは、配列値の少なくとも1つのアイテムと一致します。
`everyValue`	ファクトは、配列値内のすべてのアイテムに一致します。
`swap`	比較では、値がファクトとして使用され、ファクトが値として使用されます。
`not`	基本演算子の結果は否定する必要があります。

たとえば、someFact:equalは、デコードされたERC-1155バッチ・コールに対して指定されたtoken_ids配列内の1つのトークンIDと一致できます。

{
  "fact": "token_ids",
  "operator": "someFact:equal",
  "value": "42"
}

ブール論理にはnot条件グループを使用し、個々の演算子を否定するにはnot:デコレータを使用します。条件およびルールの優先度によって評価順序が設定されます。一致する別のBLOCKを1つのルールでオーバーライドすることはできません。

ルール・スコープの設定

scopelevelsおよびtargetsを設定して、ルールの対象となる署名リクエストを指定します。選択したすべてのスコープが一致する必要があります。1つのスコープ内のターゲットは代替です。

スコープ	必要なターゲット	次に使用:
`global`	なし。指定 `scopelevels: ["global"]` 単独。	すべての署名リクエストに適用される制限。
`org`	`targets.orgIds`	1つ以上の組織に対する制限。
`wallet`	`targets.walletIds`	1つ以上のウォレットの制限。
`instance`	`targets.instanceIds`	1つ以上のネットワーク・インスタンスの制限。
`asset`	`targets.assetIds`	既存のアセット・スコープ付きルール。互換性のために保持されます。

ルールが複数のディメンションに依存している場合は、スコープを結合します。例

scopelevels: ["org",
        "wallet"]

組織ターゲットとウォレット・ターゲットの両方を一致させる必要があります。ウォレットのみのルールには、暗黙的な組織境界がありません。表示名ではなく、UWMによって返されたIDを使用します。

契約メソッドを制限するには、条件でcontract_addressとfunction_selectorを照合します。同じメソッドで異なるネットワークで異なる制限が必要な場合は、instanceスコープを追加します。assetスコープは既存のルールに対して保持されます。これらの条件では必要ありません。

targets.instanceIdsには、UWMのウォレットまたはネットワークAPIで示されるパブリックinstanceIdを使用します。これは、数値データベース・キーまたはチェーンIDではなく、登録済のinfra_instance_idです。データベース・キーを使用する古いインスタンス・スコープ・ルールを更新します。UWMでは、パブリック・インスタンス識別子のみが送信されるようになりました。

署名要求に一致

条件では、リクエストのoperationに指定されたファクトのみを使用できます。operationファクトは、すべての署名リクエストで使用できます。

`operation`	追加事実
`native-transfer`	`amount_atomic`, `to_address`
`erc20-transfer`	`amount_atomic`, `to_address`, `contract_address`
`contract-deployment`	`amount_atomic`, `init_code_hash`
`contract-call`	`contract_address`, `native_value_atomic`, `function_selector`, `calldata_hash`
`eip712`	`primary_type`, `verifying_contract`, `typed_data`

UWMは、トークン登録なしでネイティブ値がゼロの正規ERC-20 transfer(address,uint256)コールを認識します。UWMはcapability.approved-token-contractsを読み取れなくなりました。

erc20-transferプロファイルには、native_value_atomic ("0")、function_selector ("0xa9059cbb")およびcalldata_hashも用意されています。これらのファクトを使用すると、既存のcontract-callルールで完全な制限を保持できます。

erc20-transfer操作は、操作条件のcontract-callでもあります。どちらのルール・タイプも同じリクエストと一致でき、一致するBLOCKはそれを拒否します。この動作は、両方の評価エンドポイントのequal、notEqual、in、notInおよびネストされたブール条件に適用されます。他の事実は、通常の等価性セマンティクスを保持している。

erc20-transfer操作は、transferFromまたはERC-1155メソッドではなく、transferと一致します。トークン・ルールには、必ず目的のcontract_addressを含めてください。

正規のERC-20 transferFrom、ERC-1155 safeTransferFrom、およびERC-1155 safeBatchTransferFrom呼び出しは、追加の contract-callファクトを提供します。

コール	追加事実
ERC-20 `transferFrom`	`owner_address`, `to_address`, `amount_atomic`
ERC-1155 `safeTransferFrom`	`owner_address`, `to_address`, `token_id`, `amount_atomic`
ERC-1155 `safeBatchTransferFrom`	`owner_address`、`to_address`、パラレル`token_ids`および`amounts`配列

UWMは、サポートされている正規ABIレイアウトの呼び出しのみをデコードします。その他のコールでは、汎用のcontract-callファクトが保持されます。

owner_addressは、署名ウォレットではなく、コール・データ内のソース・アドレスです。セレクタは、デプロイされた契約の動作ではなく、コール・データ・レイアウトを識別します。ERC-20およびERC-721はtransferFromセレクタを共有するため、ERC-20を実装することがわかっている契約にのみ金額条件を適用します。アドレスとセレクタは小文字に正規化され、小文字の条件値を使用します。バッチ・コールの場合、異なるトークンIDの金額を合計しないでください。

amount_atomicおよびnative_value_atomicは、基本単位の10進文字列で、ネイティブ値はweiです。EIP-712整数値も10進文字列です。EIP-712の場合、typed_dataには署名済ドメインおよびメッセージが含まれます。pathは、メッセージ値に$.message.valueを使用し、署名付きチェーンIDに$.domain.chainIdを使用します。

Wallet、組織およびネットワークの制限は、wallet、orgおよびinstanceスコープに属します。署名者、ガスおよびnonceメタデータは条件ファクトではありません。assetスコープ・ターゲットでは、asset条件ファクトは追加されません。

署名ルールを有効にする前に

「Match the Signing Request」で操作にリストされているファクトのみを使用します。ルールが操作固有のファクトを使用する場合、operation条件を含めます。

ルールを保存しても、UWMが署名時に評価できるかどうかは確認されません。たとえば、UWMはtierファクトを提供しません。tierがgoldと等しいかどうかをチェックするルールは、一般的な500エラーで署名に失敗する可能性があります。

ルールを有効にした後に署名に失敗した場合は、そのファクト、条件およびスコープを確認します。ルールを修正するか、意図しないプレースホルダである場合は、認可された管理者に無効化を依頼してください。必要な制限を無効にすると、その保護が解除されます。

本番でルールを有効にする前に、テスト・コンテキストで目的のスコープに対してルールを有効にし、実際の署名リクエストが送信されたときに意図したとおりに許可またはブロックされることを確認します。/evaluateエンドポイントのみでは、署名時に指定されたものとは異なるユーザー指定のファクトを受け入れるため、署名時の動作は検証されません。

ルールの作成

この例では、1つの組織の1つの住所へのネイティブ転送をブロックします。サンプルIDおよびアドレスを環境の値に置き換えます。ルールは無効になっており、有効化するまでリクエストをブロックしません。ルールを有効にする前に、スコープと条件を確認します。

{
  "name": "block-restricted-native-recipient",
  "description": "Block native transfers to the restricted recipient",
  "category": "transaction-policy",
  "enabled": false,
  "scopelevels": ["org"],
  "targets": {
    "orgIds": ["<organization-id>"]
  },
  "conditions": {
    "all": [
      {
        "fact": "operation",
        "operator": "equal",
        "value": "native-transfer",
        "priority": 100
      },
      {
        "fact": "to_address",
        "operator": "equal",
        "value": "0x3333333333333333333333333333333333333333",
        "priority": 1
      }
    ]
  },
  "response": {
    "type": "BLOCK",
    "params": {
      "reason": "restricted-recipient"
    }
  }
}

operation条件を先に配置し、操作固有のファクトよりも高い優先度を割り当てます。署名承認中に、欠落したファクトを読み取ると評価は失敗し、リクエストはサイレントに許可されません。

評価エンドポイントは、送信したファクトに対してルールをチェックします。ライブ署名では、UWMの検証済リクエストおよびスコープ・ターゲットからのファクトが解決済ウォレットから使用されます。評価を使用して条件を検査し、意図した署名フローで結果を確認します。