Bewertung von Transaktionsrichtlinien

Vorschau

Dieses Produkt unterliegt den „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Bevor Multi-Party Compute eine Transaktion signiert, wird sie anhand der Transaktionsrichtlinien in Ihrer Instanz geprüft. In diesem Dokument wird beschrieben, welche Richtlinien ausgewertet werden, wie eine Richtlinie ihren Lebenszyklus durchläuft, was eine Richtlinie prüfen kann und warum eine Transaktion abgelehnt wird.

So wird eine Transaktion bewertet

Eine Transaktionsrichtlinie ist eine einzelne Cedar-Anweisung vom Typ permit oder forbid. Wenn ein Signer CreateTransaction aufruft, decodiert die Instanz die nicht signierte Transaktion in Transaction.payload mit dem Parser für Transaction.schema und wertet jede erzwungene Richtlinie für die Transaktion aus, bevor eine Schlüsselfreigabe verwendet wird. Eine Richtlinie wird erzwungen, wenn ihr Status ACTIVE oder PENDING_DISABLED ist. Weitere Informationen finden Sie unter Richtlinienlebenszyklus.

Die Entscheidung folgt drei Regeln:

1. Standardmäßig ablehnen. Eine Transaktion ist nur zulässig, wenn mindestens eine permit-Richtlinie mit ihr übereinstimmt. Ohne erzwungene Richtlinien wird jede Transaktion abgelehnt.
2. Forbid gewinnt. Wenn eine forbid-Richtlinie übereinstimmt, wird die Transaktion abgelehnt, auch wenn permit-Richtlinien ebenfalls übereinstimmen.
3. Eine Richtlinie, die nicht ausgewertet werden kann, stimmt nicht überein. Beispiel: Eine Richtlinie, die ein optionales Kontextattribut liest, das die Transaktion nicht hat, kann nicht ausgewertet werden. Die Instanz zeichnet den Fehler auf, überspringt diese Richtlinie und entscheidet anhand der verbleibenden erzwungenen Richtlinien. Dies gilt auch für forbid-Richtlinien. Schreiben Sie daher forbid-Richtlinien, die bei einem fehlenden Attribut nicht fehlschlagen können. Beispiele finden Sie unter Szenario 8 und Szenario 9.

Eine Transaktion, die mehrere Übertragungen enthält, z. B. eine Solana-Transaktion mit mehreren Übertragungsanweisungen, wird für jede Übertragung einmal ausgewertet. Die Transaktion ist nur zulässig, wenn jede Übertragung zulässig ist. Wenn eine Übertragung abgelehnt oder nicht decodiert werden kann, wird die gesamte Transaktion abgelehnt.

Bei jeder Bewertung, ob Zulassung oder Ablehnung, wird ein Bewertungseintrag erstellt, der für die Transaktion in Transaction.policyEvaluationRecord zurückgegeben wird.

Die Entscheidung bestimmt, ob die Instanz die Transaktion signieren kann, ohne auf weitere Unterzeichner zu warten:

• PERMIT: Wenn die CreateTransaction-Anfrage bereits genügend Signierer-Autorisierungen enthält, um die Schlüsselrichtlinie des KeyRings zu erfüllen, wird die Transaktion sofort in den Status SIGNING verschoben. Andernfalls wird sie in PENDING_AUTHORIZATION erstellt und wartet auf weitere Unterzeichner.
• DENY: Die Instanz signiert die Transaktion nicht automatisch. Die Transaktion wird in PENDING_AUTHORIZATION erstellt, wobei policyEvaluationRecord.decision auf DENY festgelegt ist. Die Unterzeichner können den Bewertungsdatensatz prüfen und die Transaktion ablehnen (RecordSignerDecision mit DENY) oder sie trotzdem autorisieren (AUTHORIZE). Die Transaktion wird nur signiert, wenn genügend Unterzeichner sie autorisieren, um die Schlüsselrichtlinie zu erfüllen.

Eine Transaktionsrichtlinie ist eine Schutzmaßnahme für die automatische Signierung, keine Blockierung für Signierer: Signierer können eine Transaktion autorisieren, die von den Richtlinien abgelehnt wird. Die ursprüngliche PolicyEvaluationRecord bleibt für die Prüfung an die Transaktion angehängt.

Lebenszyklus von Richtlinien

Transaktionsrichtlinien können nicht geändert werden. TransactionPolicy hat keine Aktualisierungsmethode und die zugehörige rule ist unveränderlich. Wenn Sie eine Regel ändern möchten, deaktivieren Sie die Richtlinie mit DisableTransactionPolicy und erstellen Sie eine neue Richtlinie mit CreateTransactionPolicy.

Zum Aktivieren oder Deaktivieren einer Richtlinie ist die Genehmigung einer bestimmten Anzahl von Richtlinienautoren (Nutzer mit einer aktiven POLICY_AUTHOR-Rolle in User.roleStatuses) erforderlich. Jeder Richtlinienautor signiert eine TransactionPolicySigningPayload, in der die Richtlinie (oder für CreateTransactionPolicy die Instanz), die Aktion (ACTIVATE oder DISABLE) und rule.cedarDocument angegeben sind. Die Anfrage, die eine Änderung vorschlägt, zählt als erste Genehmigung. Andere Richtlinienautoren genehmigen mit ApproveTransactionPolicy. Die Anzahl der erforderlichen Genehmigungen liegt zwischen activationInfo.requiredApprovals und deactivationInfo.requiredApprovals. Wenn für die Instanz nur eine Genehmigung erforderlich ist, wird die Änderung sofort wirksam.

In der folgenden Tabelle werden die einzelnen Richtlinienstatus beschrieben und ob Richtlinien in diesem Status erzwungen werden:

Bundesland	Bedeutung	Erzwungen?
PENDING_ACTIVE	Die Richtlinie wurde vorgeschlagen und wartet auf die Genehmigung durch den Richtlinienautor.	Nein
ACTIVE	Die Richtlinie hat activationInfo.requiredApprovals Genehmigungen.	Ja
PENDING_DISABLED	Ein Richtlinienautor hat die Deaktivierung der Richtlinie beantragt und die Anfrage wartet auf Genehmigungen.	Ja, bis die Anfrage deactivationInfo.requiredApprovals Genehmigungen hat
DISABLED	Die Richtlinie wurde deaktiviert oder zurückgezogen, bevor sie aktiv wurde. Deaktivierte Richtlinien werden für Audits aufbewahrt.	Nein

Eine Richtlinie durchläuft diese Status in einer Richtung:

• PENDING_ACTIVE bis ACTIVE: Die Aktivierung hat genügend Genehmigungen.
• PENDING_ACTIVE bis DISABLED: Ein Richtlinienautor zieht die Richtlinie mit DisableTransactionPolicy zurück, bevor sie aktiv wird.
• ACTIVE bis PENDING_DISABLED: Ein Richtlinienautor ruft DisableTransactionPolicy auf.
• PENDING_DISABLED bis DISABLED: Die Deaktivierungsanfrage hat genügend Genehmigungen.

Eine Richtlinie wechselt höchstens einmal in den Status „Ausstehend“. Eine deaktivierte Richtlinie kann nicht wieder aktiviert werden. Erstellen Sie stattdessen eine neue Richtlinie.

Informationen dazu, wer diese Methoden aufrufen kann, finden Sie unter Nutzerrollen.

Version des Richtliniensets

Das Richtlinienset ist die Gruppe von Richtlinien, die zu einem bestimmten Zeitpunkt erzwungen werden (ACTIVE oder PENDING_DISABLED). Jedes Mal, wenn eine Aktivierung oder Deaktivierung abgeschlossen wird, weist die Instanz diesem Übergang die nächste Nummer in einem Zähler für die Instanz zu und zeichnet sie in activationInfo.transitionSequence oder deactivationInfo.transitionSequence auf. Diese Nummer ist die Version des Richtliniensatzes, die durch die Umstellung erstellt wurde.

In der folgenden Tabelle sehen Sie, wie sich die Version des Richtliniensatzes im Laufe einer Abfolge von Ereignissen ändert:

Ereignis	Übergangssequenz	Erzwungene Richtlinien
Richtlinie A ist aktiviert.	A: activationInfo.transitionSequence = 1	A
Richtlinie B ist aktiviert.	B: activationInfo.transitionSequence = 2	A, B
Richtlinie C wird vorgeschlagen (PENDING_ACTIVE) und dann zurückgezogen.	Keine	A, B
Eine Deaktivierungsanfrage für Richtlinie A wird genehmigt.	A: deactivationInfo.transitionSequence = 3	B

Wenn Sie eine PENDING_ACTIVE-Richtlinie zurückziehen, ändert sich die Gruppe der erzwungenen Richtlinien nicht. Daher wird keine Übergangssequenz erstellt und die Version des Richtliniensatzes wird nicht geändert. Während eine Umstellung auf Genehmigungen wartet, ist ihr transitionSequence nicht festgelegt.

Bei jeder Auswertung werden die Richtlinien, KeyLists und Schlüssel zum Zeitpunkt des createTime der Transaktion gelesen und die höchste abgeschlossene Übergangssequenz zu diesem Zeitpunkt in policyEvaluationRecord.policySetVersion aufgezeichnet. Wenn zwei Bewertungen dieselbe Version des Richtliniensatzes haben, wurden dieselben Richtlinien verwendet.

Die Cedar-Anfrage

Eine Cedar-Anfrage enthält ein Hauptkonto, eine Aktion, eine Ressource und einen Kontext. Beispiel:

permit (
  principal == User::"[e-mail]",
  action == Action::"buy_transaction",
  resource == Resource::"transaction_management"
)
when {
  context.principal_keyring == "institutional-treasury" &&
  context has fiat_amount && context.fiat_amount <= 10000
};

Zuordnung eines Nutzers zum Cedar-Hauptkonto

Das Hauptkonto ist der Initiator der Transaktion: der Nutzer, dessen principal mit der authentifizierten Identität des Aufrufers von CreateTransaction übereinstimmt. Der Nutzer muss eine aktive SIGNER-Rolle haben. In Cedar ist das Hauptkonto eine User-Entität, deren ID das Feld principal des Nutzers ist, z. B. User::"[e-mail]".

Die Instanz übergibt keine Entitätsdaten an Cedar. Eine User-Entität hat keine Attribute und keine übergeordneten Elemente:

• principal == User::"[e-mail]" stimmt mit Transaktionen überein, die Alice initiiert.
• principal in Team::"treasury" stimmt nie überein. Wenn Sie einschränken möchten, wer mit einem Schlüssel signieren kann, verwenden Sie die Schlüsselrichtlinie des Schlüsselbunds. Wenn Sie eine Regel auf eine Gruppe von Schlüsseln beschränken möchten, setzen Sie ein Häkchen bei context.principal_keyring.
• Eine Regel, die ein Attribut von principal liest, z. B. principal.team, kann nicht ausgewertet werden.

Die principal eines Nutzers kann nicht geändert werden. Eine Regel, die ein Hauptkonto benennt, bezieht sich also immer auf dieselbe Identität.

Aktion und Ressource

• action: Der Wert von Transaction.action in der CreateTransaction-Anfrage, formatiert als Cedar-Action-Entität. CreateTransaction akzeptiert die folgenden Aktionen:

  Aktion	Verwendet für
  Action::"buy_transaction"	Eine Transaktion, bei der ein Asset erworben wird.
  Action::"sell_transaction"	Eine Transaktion, bei der ein Asset veräußert wird.
  Action::"internal_transfer_transaction"	Eine Übertragung eines Assets, z. B. eine Zahlung oder ein Sweep zwischen Schlüsseln.

  Der Initiator wählt die Aktion aus. Multi-Party Computation leitet sie nicht aus der Nutzlast ab. Eine Regel kann mit einer Aktion (action == Action::"buy_transaction") oder einer Liste von Aktionen (action in [Action::"buy_transaction", Action::"sell_transaction"]) übereinstimmen. Wenn Sie action nicht einschränken, stimmt die Regel mit jeder Aktion überein.

• resource: immer Resource::"transaction_management" für Transaktionsbewertungen. Eine Regel kann resource == Resource::"transaction_management" prüfen oder resource uneingeschränkt lassen.

Kontextattribute

Der Kontext enthält die Attribute, die von Richtlinien geprüft werden. Sie stammen aus zwei Quellen:

• Die Transaktionsnutzlast und der Signaturschlüssel. Die Instanz decodiert Transaction.payload und fügt die IDs des Signaturschlüssels und seines Schlüsselbunds hinzu. Diese Attribute sind principal_keyring, principal_key, blockchain, schema, secondary_key, amount_token_scaled, token_symbol, contract_address, chain_id, max_fee_atomic, payload und time_stamp. Die vollständige Tabelle und das Verhalten für jede Blockchain finden Sie unter Regeln für Schreibtransaktionsrichtlinien.
• Das Feld metadata der Transaktion,das der Initiator in CreateTransaction festlegt.

In der folgenden Tabelle werden die Metadatenattribute beschrieben:

Feld Transaction.metadata	Cedar-Attribut	Cedar-Typ	Wert
fiatAmount	context.fiat_amount	Long	Der Wert der Transaktion in ganzen US-Dollar (google.type.Money). currencyCode muss USD sein, units muss null oder größer sein und nanos muss 0 sein.
validity	context.validity	Long	Wie lange die Transaktion gültig ist (google.protobuf.Duration), in ganzen Sekunden. Muss mehr als 0 Sekunden betragen, ohne Sekundenbruchteile.
principalValue1	context.principal_value1	String	Ein beliebiger Wert, den Sie definieren, mit bis zu 256 Zeichen, z. B. ein Trading Desk oder eine Kostenstelle.
principalValue2	context.principal_value2	String	Ein beliebiger Wert, den Sie definieren, mit bis zu 256 Zeichen, z. B. eine interne Ticket- oder Gegenpartei-ID.

Für Metadaten gelten die folgenden Regeln:

• Nicht festgelegte Felder sind nicht im Kontext enthalten. Wenn eine Transaktion keinen fiatAmount hat, ist context.fiat_amount nicht vorhanden und eine Richtlinie, die ihn liest, kann nicht ausgewertet werden. Prüfen Sie zuerst mit has auf das Attribut, wie in context has fiat_amount && context.fiat_amount <= 10000.
• Ungültige Metadaten führen dazu, dass die Anfrage fehlschlägt. Wenn ein Feld gegen die Regeln in der vorherigen Tabelle verstößt, z. B. ein fiatAmount in EUR oder mit einem nanos ungleich null, ein validity von 0 Sekunden oder ein principalValue1 mit mehr als 256 Zeichen, schlägt CreateTransaction mit INVALID_ARGUMENT fehl und es wird keine Richtlinie ausgewertet.
• Die Instanz prüft die Metadaten nicht anhand der Transaktion. fiatAmount ist der Wert, den der Initiator der Transaktion zuweist. Andere Unterzeichner sehen die Metadaten in Transaction.metadata und policyEvaluationRecord.evaluationContext, bevor sie sie autorisieren. Wenn Sie die On-Chain-Mengen unabhängig von den Metadaten begrenzen möchten, prüfen Sie context.amount_token_scaled und context.contract_address.
• Metadaten können nicht mehr geändert werden, nachdem die Transaktion erstellt wurde.

KeyRings

Ein KeyRing gruppiert Schlüssel. Der Kontext jeder Transaktion enthält principal_keyring und principal_key. Eine Regel kann also auf jeden Schlüssel in einem Schlüsselbund angewendet werden, einschließlich später erstellter Schlüssel. Ein Schlüsselbund kann ein Eintrag in einer KeyList sein. Weitere Informationen und eine Beispielregel finden Sie unter KeyRings.

KeyLists

Eine KeyList ist eine benannte Liste von Blockchain-Adressen, auf die Richtlinien verweisen können, z. B. als Zulassungsliste von Zielen. Jeder Eintrag ist einer der folgenden:

• Ein manueller Eintrag (manualEntry): eine Adresse, die nicht von der Instanz verwaltet wird, mit optionalen Feldern source und reason.
• Ein Schlüssel in der Instanz (key): stimmt mit den Adressen des Schlüssels überein.
• Ein KeyRing in der Instanz (keyRing): Entspricht den Adressen aller aktiven Schlüssel im KeyRing, einschließlich der Schlüssel, die nach dem Hinzufügen des Eintrags erstellt wurden.

KeyLists können sich ändern, nachdem eine Richtlinie genehmigt wurde. Wenn Sie einen Eintrag mit AddKeyListEntries oder RemoveKeyListEntries hinzufügen oder entfernen, wird für jede Richtlinie, die auf die KeyList verweist, ab der nächsten Auswertung der neue Eintrag verwendet, ohne dass neue Genehmigungen von Richtlinienautoren erforderlich sind. Eine KeyList kann nicht mit DeleteKeyList gelöscht werden, wenn eine PENDING_ACTIVE-, ACTIVE- oder PENDING_DISABLED-Richtlinie darauf verweist.

KeyLists im Cedar-Kontext

Bei der Auswertung erweitert die Instanz jede KeyList in eine flache Set mit String Blockchain-Adressen: die manuellen Einträge sowie die Adressen, die von jedem Schlüssel- und KeyRing-Eintrag abgeleitet werden. Jeder Satz wird als context.key_lists["<var>KEY_LIST_ID</var>"] an Cedar übergeben, wobei KEY_LIST_ID die {keyList}-ID im Ressourcennamen der KeyList ist, z. B. trusted-destinations für projects/my-project/locations/us-central1/instances/my-instance/keyLists/trusted-destinations.

Eine Regel prüft die Mitgliedschaft mit dem Cedar-Operator contains anhand der decodierten Zieladresse context.secondary_key. So lassen Sie beispielsweise nur Übertragungen an Adressen in der KeyList trusted-destinations zu:

// Assuming you created a KeyList with ID "trusted-destinations":
permit (principal, action, resource)
when { context.key_lists["trusted-destinations"].contains(context.secondary_key) };

So lehnen Sie Übertragungen an eine beliebige Adresse in der KeyList blocked-addresses ab:

// Assuming you created a KeyList with ID "blocked-addresses":
forbid (principal, action, resource)
when { context.key_lists["blocked-addresses"].contains(context.secondary_key) };

Beachten Sie Folgendes:

• Verwenden Sie für die KeyList-ID die Klammer- und nicht die Punktsyntax. Die Punkt-Syntax von Cedar (context.key_lists.trusted-destinations) kann nicht geparst werden, wenn die ID einen Bindestrich enthält, den Cedar als Subtraktion liest, oder mit einer Ziffer beginnt, wie es bei einer vom Server generierten UUID der Fall sein kann. Die Klammersyntax context.key_lists["<var>KEY_LIST_ID</var>"] funktioniert für jede ID.
• key_lists ist immer vorhanden und eine Regel kann eine KeyList darin direkt lesen. CreateTransactionPolicy prüft, ob jede KeyList, auf die sich die Regel bezieht, vorhanden ist. DeleteKeyList weigert sich, eine KeyList zu löschen, während eine Richtlinie darauf verweist. Verwenden Sie context.key_lists has "<var>KEY_LIST_ID</var>" nur, wenn sich eine Regel auf eine KeyList bezieht, die möglicherweise noch nicht vorhanden ist.
• Adressen werden als Strings verglichen. secondary_key verwendet das Format, das unter Richtlinienregeln für Schreibtransaktionen für jede Blockchain beschrieben wird, z. B. das EIP-55-Prüfsummenformat mit Groß- und Kleinschreibung für Ethereum. Fügen Sie manuelle Einträge im selben Format hinzu.
• Der secondary_key einer Solana-Tokenübertragung ist das Ziel-Tokenkonto, nicht die Wallet des Inhabers. Wenn Sie eine Wallet zulassen möchten, fügen Sie für jede zugelassene Mint das entsprechende Token-Konto hinzu.

Bei jeder Auswertung wird die KeyList-Mitgliedschaft zum Zeitpunkt der Transaktion (createTime) aufgelöst, also zur selben Zeit wie die Richtlinien. Das Ergebnis wird in policyEvaluationRecord.keyListMemberships aufgezeichnet: die KeyList, die getestete Adresse, ob sie Mitglied war, und der übereinstimmende Eintrag.

Da eine KeyList die Berechtigungen einer Richtlinie ändert, sollten Sie einschränken, wer sie ändern darf. KeyList-Methoden erfordern roles/mpc.admin. Weitere Informationen finden Sie unter IAM-Berechtigungen.

Gründe für die Ablehnung

Wenn policyEvaluationRecord.decision den Wert DENY hat, wird in policyEvaluationRecord.denyReason der Grund angegeben. In der folgenden Tabelle werden die einzelnen Ablehnungsgründe beschrieben:

Grund für Ablehnung	Wann	Richtlinien festlegen
FORBID_RULE_MATCHED	Mindestens eine erzwungene forbid-Richtlinie hat übereingestimmt.	Die forbid Richtlinien, die übereinstimmen.
NO_PERMIT_RULE_MATCHED	Die Nutzlast wurde decodiert, keine forbid-Richtlinie stimmte überein, keine Richtlinie konnte nicht ausgewertet werden und keine permit-Richtlinie stimmte überein.	Keine
EVALUATION_ERROR	Keine permit- oder forbid-Richtlinie hat übereingestimmt und mindestens eine Richtlinie konnte nicht ausgewertet werden, z. B. weil sie ein optionales Attribut liest, das nicht im Kontext enthalten ist.	Keine. In evaluationErrors sind die Fehler aufgeführt.
UNRECOGNIZED_PAYLOAD	Die Instanz konnte Transaction.payload nicht decodieren oder in einen Kontext projizieren, z. B. aufgrund fehlerhafter Byte, einer nicht unterstützten Anweisung oder eines nicht unterstützten Vertragsvorgangs oder einer Bitcoin-Transaktion mit mehreren Empfängern. Es wird keine Richtlinie ausgewertet.	Keine. evaluationErrors listet den Parserfehler auf.

Die Gründe werden in der folgenden Reihenfolge ermittelt:

1. Wenn die Nutzlast nicht decodiert oder in einen Kontext projiziert werden kann, lautet die Entscheidung DENY mit UNRECOGNIZED_PAYLOAD.
2. Andernfalls wird jede erzwungene Richtlinie ausgewertet. Wenn eine forbid-Richtlinie übereinstimmt, lautet die Entscheidung DENY mit FORBID_RULE_MATCHED, auch wenn permit-Richtlinien ebenfalls übereinstimmen oder andere Richtlinien nicht ausgewertet werden konnten.
3. Andernfalls, wenn mindestens eine permit-Richtlinie übereinstimmt, lautet die Entscheidung PERMIT. Fehler aus anderen Richtlinien werden weiterhin in evaluationErrors aufgezeichnet.
4. Andernfalls lautet die Entscheidung DENY mit EVALUATION_ERROR, wenn eine Richtlinie nicht ausgewertet werden konnte, oder NO_PERMIT_RULE_MATCHED, wenn jede Richtlinie ohne Übereinstimmung ausgewertet wurde.

Fehler werden auch dann aufgezeichnet, wenn die Entscheidung PERMIT lautet. Prüfen Sie daher den Bewertungsdatensatz auf Richtlinien, die nie übereinstimmen, weil sie immer fehlschlagen.

Szenarien

In den Szenarien 1 bis 9 erstellt Alice (User::"[e-mail]") eine gültige Ethereum-Übertragung, wobei action auf Action::"internal_transfer_transaction" festgelegt ist und die folgenden Metadaten verwendet werden, sofern im Szenario nichts anderes angegeben ist:

"metadata": {
  "fiatAmount": {"currencyCode": "USD", "units": "5000"},
  "principalValue1": "treasury-desk"
}

Die Transaktion hat weder validity noch principalValue2.

In der folgenden Tabelle sind die einzelnen Szenarien zusammengefasst:

Szenario	Erzwungene Richtlinien oder Nutzlast	Entscheidung	Grund für Ablehnung
1	Keine	DENY	NO_PERMIT_RULE_MATCHED
2	Ein permit, das übereinstimmt	PERMIT
3	Eine permit, die nicht übereinstimmt	DENY	NO_PERMIT_RULE_MATCHED
4	Zwei permit, eine Übereinstimmung	PERMIT
5	Ein permit und ein forbid, die beide übereinstimmen	DENY	FORBID_RULE_MATCHED
6	Ein permit, der ein fehlendes Attribut liest	DENY	EVALUATION_ERROR
7	permit mit has	DENY	NO_PERMIT_RULE_MATCHED
8	Ein forbid, der ein fehlendes Attribut liest, und ein permit, der übereinstimmt	PERMIT
9	Ein forbid, für das ein Attribut erforderlich ist	DENY	FORBID_RULE_MATCHED
10	Eine Nutzlast, die nicht decodiert werden kann	DENY	UNRECOGNIZED_PAYLOAD

Szenario 1: Keine erzwungenen Richtlinien

Die Instanz hat keine ACTIVE- oder PENDING_DISABLED-Richtlinien.

Entscheidung: DENY, NO_PERMIT_RULE_MATCHED. Ohne eine übereinstimmende permit-Richtlinie wird jede Transaktion abgelehnt. In einer neuen Instanz wird keine Transaktion automatisch signiert, bis Richtlinienautoren eine permit-Richtlinie aktivieren. Signierer müssen jede Transaktion autorisieren.

Szenario 2: Eine Genehmigung, die übereinstimmt

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 10000 };

Entscheidung: PERMIT. Der Betrag von 5.000 ist höchstens 10.000. determiningPolicyIds führt diese Richtlinie auf.

Szenario 3: Eine Genehmigung, die nicht übereinstimmt

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 1000 };

Entscheidung: DENY, NO_PERMIT_RULE_MATCHED. Der Betrag von 5.000 ist höher als 1.000 und keine andere Richtlinie lässt die Transaktion zu.

Szenario 4: Zwei Genehmigungen, eine stimmt überein

Richtlinie A:

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 1000 };

Richtlinie B:

permit (
  principal == User::"[e-mail]",
  action == Action::"internal_transfer_transaction",
  resource == Resource::"transaction_management"
)
when {
  context has fiat_amount && context.fiat_amount <= 25000 &&
  context has principal_value1 && context.principal_value1 == "treasury-desk"
};

Entscheidung: PERMIT. Richtlinie A stimmt nicht überein, Richtlinie B jedoch schon. Eine übereinstimmende permit-Richtlinie reicht aus. determiningPolicyIds listet nur Richtlinie B auf.

Szenario 5: Ein Verbot überschreibt eine Erlaubnis

Richtlinie A:

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 10000 };

Richtlinie B:

forbid (principal, action, resource)
when { context has principal_value1 && context.principal_value1 == "treasury-desk" };

Entscheidung: DENY, FORBID_RULE_MATCHED. Beide Richtlinien stimmen überein und forbid gewinnt. determiningPolicyIds listet nur Richtlinie B auf.

Szenario 6: Eine Genehmigung liest ein fehlendes Attribut

permit (principal, action, resource)
when { context.validity <= 3600 };

Entscheidung: DENY, EVALUATION_ERROR. Die Transaktion hat kein validity, daher ist context.validity nicht vorhanden und die Richtlinie kann nicht ausgewertet werden. Keine andere Richtlinie lässt die Transaktion zu. evaluationErrors listet den Fehler auf.

Szenario 7: Dieselbe Genehmigung, mit „has“

permit (principal, action, resource)
when { context has validity && context.validity <= 3600 };

Entscheidung: DENY, NO_PERMIT_RULE_MATCHED. context has validity ist „false“, sodass die Richtlinie als „false“ ausgewertet wird, anstatt fehlzuschlagen. Die Transaktion wird weiterhin abgelehnt, aber der Grund zeigt, dass die Richtlinie ausgewertet wurde und nicht übereinstimmte.

Szenario 8: Eine Forbid-Anweisung liest ein fehlendes Attribut

Richtlinie A:

permit (principal, action, resource)
when { context has fiat_amount && context.fiat_amount <= 10000 };

Richtlinie B:

forbid (principal, action, resource)
when { context.principal_value2 == "sanctioned-counterparty" };

Entscheidung: PERMIT. Die Transaktion hat kein principalValue2, sodass Richtlinie B nicht ausgewertet werden kann und übersprungen wird. Richtlinie A stimmt überein. determiningPolicyIds listet Richtlinie A auf und evaluationErrors den Fehler aus Richtlinie B.

Achtung: Eine forbid-Richtlinie, die nicht ausgewertet werden kann, lehnt die Transaktion nicht ab. Ein Initiator kann ein Metadatenfeld weglassen, um eine forbid-Richtlinie zu überspringen, die es liest. Wenn Sie Transaktionen ohne das Attribut ablehnen möchten, verwenden Sie has oder unless, wie in Szenario 9 gezeigt.

Szenario 9: Verbot, das ein Attribut erfordert

Richtlinie A ist die Richtlinie permit aus Szenario 8. Richtlinie B:

forbid (principal, action, resource)
unless { context has fiat_amount };

Entscheidung: PERMIT für die Transaktion in diesen Szenarien, die einen fiatAmount hat. Wenn Alice fiatAmount weglässt, lautet die Entscheidung DENY, FORBID_RULE_MATCHED: context has fiat_amount ist falsch, sodass die Richtlinie forbid übereinstimmt. Diese Richtlinie kann nicht fehlschlagen, da sie nur has verwendet.

Wenn Sie ein erforderliches Attribut mit einer Prüfung seines Werts in einer forbid-Richtlinie kombinieren möchten, prüfen Sie zuerst das Attribut:

forbid (principal, action, resource)
unless { context has fiat_amount && context.fiat_amount <= 10000 };

Szenario 10: Eine Nutzlast, die nicht decodiert werden kann

Alice erstellt eine Transaktion, deren payload nicht vom Parser für Transaction.schema decodiert werden kann, z. B. abgeschnittene RLP-Bytes, eine Bitcoin-PSBT mit mehreren Empfängern oder eine Solana-Transaktion mit einer nicht unterstützten Anweisung.

Entscheidung: DENY, UNRECOGNIZED_PAYLOAD. Es wird keine Richtlinie ausgewertet. evaluationErrors listet den Parserfehler auf und determiningPolicyIds ist leer.

Bewertungseintrag

Bei jeder Bewertung wird ein PolicyEvaluationRecord erstellt, das nicht geändert werden kann. Es wird in Transaction.policyEvaluationRecord zurückgegeben und hat die folgenden Felder:

Feld	Wert
decision	PERMIT oder DENY.
denyReason	Einer der Ablehnungsgründe. Nicht festgelegt, wenn die Entscheidung PERMIT ist.
determiningPolicyIds	In PERMIT die IDs der übereinstimmenden permit-Richtlinien. In FORBID_RULE_MATCHED die IDs der übereinstimmenden forbid-Richtlinien. Andernfalls leer.
evaluationErrors	Die Fehler von Richtlinien, die nicht ausgewertet werden konnten, oder der Parserfehler, wenn denyReason den Wert UNRECOGNIZED_PAYLOAD hat.
evaluationContext	Der Cedar-Kontext, anhand dessen die Richtlinien ausgewertet wurden, als google.protobuf.Struct. 64-Bit-Ganzzahlen werden als Dezimalstrings gespeichert, um ihre Genauigkeit beizubehalten.
policySetVersion	Die Version des Richtliniensatzes, die für die Bewertung verwendet wurde.
keyListMemberships	Die KeyList-Mitgliedschaften, die während der Auswertung aufgelöst wurden.
intentDigest	Der hexadezimal codierte Digest der Transaktionsnutzlast, die ausgewertet wurde, in Kleinbuchstaben. Der Hash hängt vom Schema der Nutzlast ab: Keccak-256 der Transaktion für ETHEREUM_TX_V2, der Sighash der ersten Eingabe für BITCOIN_TX_V2, SHA-256 der unsignierten Nachricht für SOLANA_TX_V1 und der EIP-712-Signatur-Digest, keccak256(0x1901 ++ domainSeparator ++ hashStruct(message)), für EIP712_TYPED_DATA_V1.
evaluationTime	Wann die Bewertung ausgeführt wurde.