Erstellen Sie eine Policy

Eine Policy ist eine Gruppe von Regeln, die Signaturanforderungen blockieren können. Signieranforderungen umfassen Blockchain-Transaktionen und Anforderungen zum Unterzeichnen von Daten, wie typisierte EIP-712-Daten. Jede gespeicherte Regel hat einen Geltungsbereich, Bedingungen und eine BLOCK-Antwort. Aktivierte Regeln werden kumulativ angewendet: Wenn eine gültige Regel übereinstimmt, wird die Anforderung abgelehnt.

Wenn die Policy-Auswertung erfolgreich abgeschlossen wurde und keine anwendbare Regel eine BLOCK-Antwort zurückgibt, kann die Anforderung fortgesetzt werden, nachdem UWaaS Wallet Manager (UWM) den Aufrufer authentifiziert, das Wallet und den Schlüssel autorisiert und die Signaturanforderung validiert hat.

Informationen zum UWaaS Wallet Manager finden Sie unter Universal Wallet as a Service (UWaaS). Informationen zu API-Anforderungsfeldern und Vorgängen finden Sie unter Universal Wallet Manager-APIs, einschließlich:

Regelbedingungen definieren

Eine Regel kombiniert Bedingungen mit all, any und not. Sie können diese Gruppen verschachteln, um eine Einschränkung zu definieren:

all entspricht, wenn jede untergeordnete Bedingung übereinstimmt.
any entspricht, wenn mindestens eine untergeordnete Bedingung übereinstimmt.
not stimmt überein, wenn die untergeordnete Bedingung nicht übereinstimmt.

Bedingungsgruppen inline definieren Benannte Bedingungsreferenzen werden für UWM-Signaturregeln nicht unterstützt.

Ein Bedingungsblatt gibt einen Fakt, einen Operator und einen Wert an. Verwenden Sie path, um eine verschachtelte Eigenschaft aus einem Fakt auszuwählen. Höhere priority-Werte werden zuerst ausgewertet.

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

Der Operator in stimmt überein, wenn der Fakt einem der aufgelisteten Werte entspricht. Verwenden Sie all, um diese Bedingung mit einer operation-Bedingung zu kombinieren. Verwenden Sie any, wenn eine von mehreren Bedingungen die Einschränkung auslösen kann.

Operatoren

Bediener	Verwenden Sie es, wenn
`equal`, `notEqual`	Ein skalarer Fakt muss einem Wert desselben Typs entsprechen oder davon abweichen.
`in`, `notIn`	Ein skalarer Fakt muss in einer Werteliste angezeigt werden oder nicht.
`contains`, `doesNotContain`	Ein Arrayfakt muss einen Wert enthalten oder nicht.
`lessThan`, `lessThanEquals` (`lessThanInclusive`)	Ein numerischer Fakt muss kleiner oder gleich einem numerischen Wert sein.
`greaterThan`, `greaterThanEquals` (`greaterThanInclusive`)	Ein numerischer Fakt muss größer oder gleich einem numerischen Wert sein.

Bestellte Vergleiche in amount, amount_atomic und native_value_atomic verwenden genaue Dezimalarithmetik sowohl in /evaluate als auch in /internal/v1/authorize.

Verwenden Sie Dezimalzeichenfolgen für atomare Mengen und große Schwellenwerte. Beispiel:

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

UWM stellt amount_atomic in Basiseinheiten bereit und konvertiert sie nicht in Tokendezimale. Der Fakt amount wird unterstützt, wenn er von einem Aufrufer von /evaluate bereitgestellt wird. UWM fügt ihn nicht zu den Signaturfakten hinzu.

JSON-Dezimalzahlen innerhalb des sicheren numerischen Bereichs werden akzeptiert. Senden Sie größere numerische Werte als Zeichenfolgen. Größere numerische Literale werden abgelehnt. Die Operatornamen greaterThanInclusive und lessThanInclusive werden weiterhin unterstützt. Die Operatoren equal und notEqual vergleichen Werte nach Typ. Andere Fakten behalten ihr bestehendes Vergleichsverhalten.

Arraydekorateure

Stellen Sie einem Operator einen Dekorator und einen Doppelpunkt voran, wie someFact:equal. Dekoratoren ändern, wie der Bediener mit Arrays oder deren Ergebnissen umgeht.

Dekorator	Verwenden Sie es, wenn
`someFact`	Mindestens ein Element in einem Arrayfakt stimmt überein.
`everyFact`	Jedes Element in einem Array-Fakt stimmt überein.
`someValue`	Der Fakt entspricht mindestens einem Element in einem Arraywert.
`everyValue`	Der Fakt stimmt mit jedem Element in einem Arraywert überein.
`swap`	Der Vergleich verwendet den Wert als Fakt und den Fakt als Wert.
`not`	Das Basisoperatorergebnis muss negiert werden.

Beispiel: someFact:equal kann mit einer Token-ID im token_ids-Array übereinstimmen, die für einen entschlüsselten ERC-1155-Batchaufruf bereitgestellt wird:

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

Verwenden Sie die Bedingungsgruppe not für boolesche Logik und den Dekorator not:, um einen einzelnen Operator zu negieren. Bedingungs- und Regelprioritäten legen die Auswertungsreihenfolge fest. Sie lassen nicht zu, dass eine Regel eine andere übereinstimmende BLOCK außer Kraft setzt.

Regelgeltungsbereich festlegen

Legen Sie scopelevels und targets fest, um anzugeben, welche Signaturanforderungen eine Regel abdeckt. Jeder ausgewählte Geltungsbereich muss übereinstimmen. Ziele in einem Geltungsbereich sind Alternativen.

Geltungsbereich	Erforderliches Ziel	Verwenden Sie es für
`global`	Keine; angeben `scopelevels: ["global"]` von sich selbst.	Eine Einschränkung, die für jede Signaturanforderung gilt.
`org`	`targets.orgIds`	Eine Einschränkung für eine oder mehrere Organisationen.
`wallet`	`targets.walletIds`	Eine Einschränkung für eine oder mehrere Brieftaschen.
`instance`	`targets.instanceIds`	Eine Einschränkung für eine oder mehrere Netzwerkinstanzen.
`asset`	`targets.assetIds`	Vorhandene Regeln mit Assetbereich; aus Kompatibilität beibehalten.

Geltungsbereiche kombinieren, wenn eine Regel von mehreren Dimensionen abhängt Beispiel:

scopelevels: ["org",
        "wallet"]

erfordert, dass sowohl die Organisations- als auch die Wallet-Ziele übereinstimmen. Eine reine Wallet-Regel hat keine implizite Organisationsgrenze. Verwenden Sie von UWM zurückgegebene IDs, keine Anzeigenamen.

Um eine Vertragsmethode einzuschränken, müssen Sie contract_address und function_selector in den Bedingungen abgleichen. Fügen Sie den Geltungsbereich instance hinzu, wenn für dieselbe Methode unterschiedliche Einschränkungen für verschiedene Netzwerke erforderlich sind. Der Geltungsbereich asset wird für vorhandene Regeln beibehalten. Für diese Bedingungen ist er nicht erforderlich.

Verwenden Sie für targets.instanceIds die öffentliche instanceId, die vom Wallet oder der Netzwerk-API der UWM angezeigt wird. Dies ist die registrierte infra_instance_id, nicht der numerische Datenbankschlüssel oder die Ketten-ID. Aktualisieren Sie ältere instanzbezogene Regeln, die einen Datenbankschlüssel verwenden. UWM sendet jetzt nur die öffentliche Instanz-ID.

Abzeichnungsanforderung zuordnen

Bedingungen können nur Fakten verwenden, die für die operation der Anforderung angegeben wurden. Der Fakt operation ist für jede Signaturanforderung verfügbar.

`operation`	Weitere Fakten
`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 erkennt kanonische ERC-20 transfer(address,uint256)-Aufrufe ohne nativen Wert ohne Tokenregistrierung. UWM liest capability.approved-token-contracts nicht mehr.

Das erc20-transfer-Profil stellt auch native_value_atomic ("0"), function_selector ("0xa9059cbb") und calldata_hash bereit. Mit diesen Fakten können bestehende contract-call-Regeln ihre vollständigen Einschränkungen beibehalten.

Ein erc20-transfer-Vorgang ist auch ein contract-call für Vorgangsbedingungen. Beide Regeltypen können mit derselben Anforderung übereinstimmen, und jeder übereinstimmende BLOCK lehnt sie ab. Dieses Verhalten gilt für equal, notEqual, in, notIn und verschachtelte boolesche Bedingungen für beide Auswertungsendpunkte. Andere Fakten behalten ihre normale Gleichheitssemantik.

Der Vorgang erc20-transfer entspricht den Methoden transfer, nicht den Methoden transferFrom oder ERC-1155. Nehmen Sie immer die beabsichtigte contract_address in Tokenregeln auf.

Canonical ERC-20 transferFrom, ERC-1155 safeTransferFrom und ERC-1155 safeBatchTransferFrom-Aufrufe liefern zusätzliche contract-call-Fakten:

Anruf	Weitere Fakten
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`-, parallele `token_ids`- und `amounts`-Arrays

UWM decodiert nur Aufrufe mit einem unterstützten kanonischen ABI-Layout. Bei anderen Aufrufen werden die allgemeinen contract-call-Fakten beibehalten.

owner_address ist die Quelladresse in den Anrufdaten, nicht das Signatur-Wallet. Ein Selektor identifiziert das Anrufdatenlayout, nicht das Verhalten des bereitgestellten Vertrags. ERC-20 und ERC-721 teilen den transferFrom-Selektor. Wenden Sie daher Betragsbedingungen nur auf einen Vertrag an, von dem bekannt ist, dass er ERC-20 implementiert. Adressen und Selektoren werden in Kleinbuchstaben normalisiert. Verwenden Sie Werte für Kleinbuchstaben. Bei Batchaufrufen keine Summen für verschiedene Token-IDs.

amount_atomic und native_value_atomic sind Dezimalzeichenfolgen in Basiseinheiten. Der native Wert ist in wei. EIP-712 Ganzzahlwerte sind auch Dezimalzeichenfolgen. Bei EIP-712 enthält typed_data die signierte Domain und Nachricht. Eine path ist relativ zu diesem Fakt: Verwenden Sie $.message.value als Nachrichtenwert und $.domain.chainId als signierte Ketten-ID.

Wallet-, Organisations- und Netzwerkeinschränkungen gehören zu den Geltungsbereichen wallet, org und instance. Signaturgeber-, Gas- und Nonce-Metadaten sind keine Bedingungsfakten. Das Geltungsbereichsziel asset fügt keinen Bedingungsfakt asset hinzu.

Bevor Sie eine Signaturregel aktivieren

Verwenden Sie nur die Fakten, die für den Vorgang unter "Signaturanforderung zuordnen" aufgeführt sind. Nehmen Sie eine operation-Bedingung auf, wenn eine Regel Vorgangsspezifische Fakten verwendet.

Durch das Speichern einer Regel wird nicht bestätigt, dass UWM sie beim Abzeichnen auswerten kann. Beispiel: UWM gibt keinen tier-Fakt an. Eine Regel, die prüft, ob tier gleich gold ist, kann dazu führen, dass das Signieren mit einem generischen 500-Fehler nicht erfolgreich verläuft.

Wenn das Signieren nach dem Aktivieren einer Regel nicht erfolgreich verläuft, prüfen Sie die zugehörigen Fakten, Bedingungen und den Geltungsbereich. Korrigieren Sie die Regel, oder bitten Sie einen autorisierten Administrator, sie zu deaktivieren, wenn es sich um einen unbeabsichtigten Platzhalter handelt. Wenn Sie eine erforderliche Einschränkung deaktivieren, wird ihr Schutz entfernt.

Bevor Sie die Regel in der Produktion aktivieren, aktivieren Sie sie für den beabsichtigten Geltungsbereich in einem Testkontext, und prüfen Sie, ob tatsächliche Signaturanforderungen beim Weiterleiten wie vorgesehen zulässig oder blockiert sind. Der /evaluate-Endpunkt allein überprüft das Verhalten beim Signieren nicht, da er vom Benutzer bereitgestellte Fakten akzeptiert, die sich von denen unterscheiden können, die beim Signieren angegeben wurden.

Regel erstellen

In diesem Beispiel werden native Übertragungen an eine Adresse für eine Organisation blockiert. Ersetzen Sie die Beispiel-IDs und die Adresse durch die Werte für Ihre Umgebung. Die Regel ist deaktiviert und blockiert Anforderungen erst, wenn Sie sie aktivieren. Prüfen Sie den Geltungsbereich und die Bedingungen, bevor Sie die Regel aktivieren.

{
  "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"
    }
  }
}

Setzen Sie die operation-Bedingung an die erste Stelle, und weisen Sie ihr eine höhere Priorität als Vorgangs-spezifischen Fakten zu. Während der Signaturautorisierung verläuft die Auswertung nicht erfolgreich, wenn ein fehlender Fakt gelesen wird. Die Anforderung ist nicht stillschweigend zulässig.

Die Bewertungsendpunkte prüfen Regeln anhand der weitergeleiteten Fakten. Bei der Live-Signatur werden Fakten aus den validierten Anforderungs- und Geltungsbereichszielen von UWM aus dem aufgelösten Wallet verwendet. Mit der Auswertung können Sie eine Bedingung prüfen und das Ergebnis dann über den beabsichtigten Signaturfluss bestätigen.