정책 생성

정책은 서명 요청을 차단할 수 있는 일련의 규칙입니다. 서명 요청에는 블록체인 거래와 EIP-712 입력 데이터와 같은 서명 데이터 요청이 포함됩니다. 저장된 각 규칙에는 범위, 조건 및 BLOCK 응답이 있습니다. 사용으로 설정된 규칙은 누적적으로 적용됩니다. 적용 가능한 규칙이 일치하면 요청이 거부됩니다.

정책 평가가 성공적으로 완료되고 적용 가능한 규칙이 BLOCK 응답을 반환하지 않는 경우 UWM(UWaaS Wallet Manager)이 호출자를 인증하고, 전자 지갑 및 키를 인증하고, 서명 요청을 검증한 후 요청을 계속할 수 있습니다.

UWaaS Wallet Manager에 대한 자세한 내용은 Universal Wallet as a Service(UWaaS)를 참조하십시오. API 요청 필드 및 작업의 경우 다음을 포함한 범용 전자 지갑 관리자 API를 참조하십시오.

규칙 조건 정의

규칙은 조건을 all, any 및 not와 결합합니다. 이러한 그룹을 중첩하여 제한을 정의할 수 있습니다.

all는 모든 하위 조건이 일치하는 경우 일치합니다.
any는 하나 이상의 하위 조건이 일치하는 경우 일치합니다.
not는 하위 조건이 일치하지 않을 때 일치합니다.

조건 그룹을 인라인으로 정의합니다. UWM 서명 규칙에 대해서는 이름이 지정된 조건 참조가 지원되지 않습니다.

조건 리프는 팩트, 연산자 및 값을 지정합니다. 팩트에서 중첩된 속성을 선택하려면 path를 사용합니다. 더 높은 priority 값이 먼저 평가됩니다.

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

in 연산자는 팩트가 나열된 값 중 하나와 같을 때 일치합니다. 이 조건을 operation 조건과 결합하려면 all를 사용합니다. 여러 조건 중 하나가 제한을 트리거할 수 있는 경우 any를 사용합니다.

연산자

연산자	다음 경우에 사용합니다.
`equal`, `notEqual`	스칼라 팩트는 동일한 유형의 값과 같거나 달라야 합니다.
`in`, `notIn`	스칼라 팩트는 값 목록에 나타나거나 나타나지 않아야 합니다.
`contains`, `doesNotContain`	배열 팩트는 값을 포함하거나 포함하지 않아야 합니다.
`lessThan`, `lessThanEquals` (`lessThanInclusive`)	숫자 팩트는 숫자 값보다 작거나 같아야 합니다.
`greaterThan`, `greaterThanEquals` (`greaterThanInclusive`)	숫자 팩트는 숫자 값보다 크거나 같아야 합니다.

amount, amount_atomic 및 native_value_atomic에서 순서가 지정된 비교는 /evaluate 및 /internal/v1/authorize 모두에서 정확한 십진수 산술을 사용합니다.

원자 수량 및 큰 임계값에 십진수 문자열을 사용합니다. 예:

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

UWM은 amount_atomic를 기본 단위로 제공하며 토큰 소수점으로 변환하지 않습니다. amount 팩트는 /evaluate 호출자가 제공한 경우 지원됩니다. UWM은 서명 팩트에 추가하지 않습니다.

안전한 숫자 범위 내의 십진수 JSON 숫자가 허용됩니다. 더 큰 숫자 값을 문자열로 보냅니다. 더 큰 숫자 리터럴은 거부됩니다. greaterThanInclusive 및 lessThanInclusive 연산자 이름은 계속 지원됩니다. equal 및 notEqual 연산자는 값을 유형별로 비교합니다. 다른 팩트는 기존 비교 동작을 유지합니다.

배열 데코레이터

연산자 앞에 데코레이터와 콜론(예: someFact:equal)을 추가합니다. 데코레이터는 연산자가 배열 또는 그 결과를 처리하는 방법을 변경합니다.

데코레이터	다음 경우에 사용합니다.
`someFact`	배열 팩트에서 하나 이상의 품목이 대응합니다.
`everyFact`	배열 팩트의 모든 항목이 일치합니다.
`someValue`	팩트가 배열 값의 하나 이상의 항목과 대응합니다.
`everyValue`	팩트는 배열 값의 모든 항목과 일치합니다.
`swap`	비교에서는 값을 팩트로 사용하고 팩트를 값으로 사용합니다.
`not`	기본 연산자 결과를 부정해야 합니다.

예를 들어, someFact:equal는 디코딩된 ERC-1155 일괄 처리 호출에 대해 제공된 token_ids 배열에서 하나의 토큰 ID와 일치할 수 있습니다.

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

부울 논리에 not 조건 그룹을 사용하고 개별 연산자를 부정하려면 not: 데코레이터를 사용합니다. 조건 및 규칙 우선순위 세트 평가 순서입니다. 하나의 규칙이 일치하는 다른 BLOCK를 대체하도록 허용하지 않습니다.

규칙 범위 설정

scopelevels 및 targets를 설정하여 규칙에 적용되는 서명 요청을 지정합니다. 선택한 모든 범위가 일치해야 합니다. 한 범위 내의 대상은 대안입니다.

범위	필수 대상	기본 제공
`global`	없음; 지정 `scopelevels: ["global"]` 그 자체로.	모든 서명 요청에 적용되는 제한입니다.
`org`	`targets.orgIds`	하나 이상의 조직에 대한 제한입니다.
`wallet`	`targets.walletIds`	하나 이상의 전자 지갑에 대한 제한입니다.
`instance`	`targets.instanceIds`	하나 이상의 네트워크 인스턴스에 대한 제한입니다.
`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은 토큰 등록 없이 고유 값이 0인 표준 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는 기본 단위의 십진수 문자열입니다. 고유 값은 wei에 있습니다. EIP-712 정수 값도 십진수 문자열입니다. EIP-712의 경우 typed_data에는 서명된 도메인 및 메시지가 포함됩니다. path는 메시지 값에 $.message.value를 사용하고 서명된 체인 ID에 $.domain.chainId를 사용합니다.

전자 지갑, 조직 및 네트워크 제한은 wallet, org 및 instance 범위에 속합니다. 서명자, 가스 및 nonce 메타데이터는 조건 팩트가 아닙니다. asset 범위 대상이 asset 조건 팩트를 추가하지 않습니다.

서명 규칙을 활성화하기 전에

서명 요청 일치 아래에 있는 작업에 대해 나열된 팩트만 사용하십시오. 규칙에서 작업별 팩트를 사용하는 경우 operation 조건을 포함합니다.

규칙을 저장해도 UWM이 서명하는 동안 규칙을 평가할 수 있는지 확인되지 않습니다. 예를 들어, UWM은 tier 팩트를 제공하지 않습니다. tier가 gold인지 확인하는 규칙으로 인해 일반 500 오류로 인해 서명이 실패할 수 있습니다.

규칙을 사용으로 설정한 후 서명이 실패하면 해당 사실, 조건 및 범위를 검토합니다. 규칙을 수정하거나 권한이 부여된 관리자에게 의도하지 않은 위치 표시자인 경우 사용 안함으로 설정하도록 요청하십시오. 필수 제한을 사용 안함으로 설정하면 보호 기능이 제거됩니다.

운용에서 규칙을 사용으로 설정하기 전에 테스트 컨텍스트에서 의도한 범위에 대해 사용으로 설정하고 실제 서명 요청이 제출될 때 의도한 대로 허용되거나 차단되었는지 확인합니다. /evaluate 끝점만으로는 서명 중 동작을 확인할 수 없습니다. 서명 중 제공된 것과 다를 수 있는 사용자 제공 사실을 수락하기 때문입니다.

규칙 생성

이 예에서는 한 조직에 대해 하나의 주소로 기본 이전을 차단합니다. 예제 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의 검증된 요청의 사실과 해결된 전자 지갑의 범위 대상을 사용합니다. 평가를 사용하여 조건을 검사한 다음 의도한 서명 플로우를 통해 결과를 확인합니다.