Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Évaluation des règles avec Cedar

Cette page explique comment le moteur de stratégies de calcul multipartite (MPC) évalue les règles de transaction écrites dans le langage de règles Cedar, gère les scénarios inter-chaînes et résout les champs de métadonnées facultatifs ou omis.

Principes d'évaluation fondamentaux

Le moteur de stratégies utilise le langage de stratégie Cedar pour autoriser les opérations de signature cryptographique. Le moteur évalue les stratégies de manière déterministe à l'aide de trois axiomes fondamentaux :

Refus par défaut : toutes les opérations sont implicitement refusées. Pour qu'une opération soit autorisée, elle doit correspondre à au moins une règle permit active. Si aucune règle permit correspondante n'est trouvée, la décision finale est DENY.
Interdiction explicite : une règle forbid agit comme un remplacement absolu. Si une opération correspond à une règle forbid active, la décision est immédiatement résolue en DENY, quelles que soient les règles permit correspondantes qui autoriseraient l'opération.
Les champs manquants signifient simplement "Aucune correspondance" (ignorer) : si une règle recherche un champ qui n'est pas présent dans la charge utile de la transaction (par exemple, un champ facultatif qui a été omis), Cedar ne plante pas. Elle traite cette règle spécifique comme une "non-correspondance" (renvoie la valeur "false") et passe à la règle suivante.

Matrice d'évaluation logique

Le tableau suivant montre comment le moteur de stratégies évalue les combinaisons de règles.

Pour tous les scénarios, supposons que :

L'appelant de la transaction (représenté par le compte principal dans les stratégies Cedar) est Alice (User::"alice"). Dans le calcul multipartite, un compte principal représente le persona ou l'identité qui demande l'autorisation pour une opération de signature cryptographique (par exemple, un signataire humain, un client de service automatisé ou un compte de système backend).
La transaction transfère exactement 1 ETH (représenté par 1 000 000 000 unités de nanocoin mises à l'échelle dans context.transaction.spend_amount_scaled).

Scénario	Règles actives	Résultat	Motif
Scénario 1 : État vide	Aucune règle active.	`DENY`	Par défaut, toutes les opérations sont bloquées, sauf si elles sont explicitement autorisées par une règle `permit` correspondante.
Scénario 2 : Correspondance avec une seule autorisation	permit( principal == User::"alice", action, resource ) when { context.transaction.spend_amount_scaled < 10000000000 }; Autorise jusqu'à 10 ETH	`PERMIT`	Les paramètres de transaction remplissent la condition de la règle. Comme il n'y a pas de règles `forbid` en conflit, la requête est autorisée.
Scénario 3 : Non-concordance d'une seule autorisation	permit( principal == User::"alice", action, resource ) when { context.transaction.spend_amount_scaled < 500000000 }; Autorise jusqu'à 0,5 ETH	`DENY`	Le montant du transfert (1 ETH) dépasse la limite de la règle. Comme aucune règle `permit` correspondante n'est respectée, le refus par défaut bloque la transaction.
Scénario 4 : Plusieurs règles d'autorisation	Règle A : permit( principal == User::"alice", action, resource ) when { context.transaction.spend_amount_scaled < 500000000 }; Autorise jusqu'à 0,5 ETH Règle B : permit( principal == User::"alice", action, resource ) when { context.transaction.spend_amount_scaled < 5000000000 }; Jusqu'à 5 ETH	`PERMIT`	Bien que la règle A ne corresponde pas, la règle B correspond. Il suffit d'une seule règle `permit` correspondante pour autoriser la transaction.
Scénario 5 : Conflit entre autorisation et interdiction	Règle A (autoriser) : permit( principal == User::"alice", action, resource ) when { context.transaction.spend_amount_scaled < 5000000000 }; Jusqu'à 5 ETH Règle B (interdire) : forbid( principal == User::"alice", action, resource ) when { context.transaction.recipient == "0xBlockedAddress" }; Suppose que la destination est `0xBlockedAddress`	`DENY`	Le transfert est envoyé à `0xBlockedAddress`. Même si la règle A autorise le montant de la transaction, la destination correspond aux critères de la règle B. La règle `forbid` explicite remplace la règle A et bloque la transaction.
Scénario 6 : Règle d'interdiction sans correspondance	Mêmes règles que dans le scénario précédent	`PERMIT`	Le transfert est envoyé à une adresse sécurisée (par exemple, `0xSafeAddress`). La règle A correspond, mais pas la règle B, car la destination n'est pas `0xBlockedAddress`. En l'absence de règle d'interdiction correspondante, la règle d'autorisation est appliquée.

Scénarios multichaînes et avec champs facultatifs

Bien que la matrice précédente illustre la priorité logique de base des règles autorisées et interdites, les scénarios suivants montrent comment le moteur de stratégies évalue les règles dans un environnement multichaîne, en particulier lors de l'exécution sur des champs facultatifs ou différents schémas de réseau de blockchain.

Remarque : Normalisation des données de valeur zéro Pour éviter les erreurs d'évaluation inattendues et garantir la prévisibilité des stratégies, la couche d'analyse du moteur de stratégies normalise les champs de chaîne et d'octets non renseignés dans le contexte d'évaluation en fonction de leurs valeurs zéro spécifiques au type (comme une chaîne vide "" ou un tableau d'octets vide) au lieu de les omettre.

Ce comportement vous permet de rédiger des règles explicites ciblant des champs non renseignés sans risquer d'erreurs d'évaluation Cedar. Toutefois, l'accès à des champs qui ne sont pas du tout définis dans le schéma d'une blockchain (comme gas_limit, qui n'est disponible que sur EVM, sur une transaction Bitcoin, ou outputs, qui n'est disponible que sur Bitcoin, sur une transaction EVM) entraînera une erreur d'évaluation Cedar sur cette stratégie spécifique, ce qui l'évaluera à false (aucune correspondance) et entraînera un échec sécurisé.

Scénario 7 : Évaluation des règles inter-chaînes et attributs de schéma non mappés

Contexte : un appelant envoie une transaction Bitcoin. Toutefois, l'ensemble de règles actif contient une règle spécifique à Ethereum :

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

Résultat : DENY
Raison : Les attributs d'intention universels (comme spend_amount_scaled, recipient et max_fee_atomic) sont évalués de manière cohérente pour les transactions Ethereum et Bitcoin. Lorsqu'une règle fait référence à des attributs spécifiques à une chaîne qui n'existent pas dans le schéma de la transaction envoyée (par exemple, gas_limit sur une transaction Bitcoin), Cedar traite l'attribut non mis en correspondance comme un échec d'évaluation, en résolvant cette règle spécifique sur false (aucune correspondance) sans arrêter le moteur. Comme aucune autre règle permit active ne correspond à la transaction Bitcoin, l'opération est refusée par défaut.

Scénario 8 : Champ facultatif manquant dans une règle `permit`

Contexte : un appelant envoie un transfert ETH standard (qui n'utilise pas de contrats intelligents). L'ensemble de règles actif contient une règle qui vérifie les interactions du contrat :
```
permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == "0x1111111111111111111111111111111111111111"
};
```
Résultat : DENY
Motif : Pour un transfert ETH standard, le champ facultatif asset_contract_address n'est pas renseigné. L'analyseur normalise cette valeur en chaîne vide de valeur zéro "" dans le contexte d'évaluation. L'évaluation de la comparaison "" == "0x1111..." renvoie false (aucune correspondance) au lieu de générer une erreur. Comme aucune autre règle n'autorise le transfert, l'opération est refusée par défaut.

Scénario 9 : Champ facultatif manquant dans une règle `forbid`

Contexte : un appelant envoie un transfert ETH standard de 10 ETH. L'ensemble de règles comprend les éléments suivants :

Règle A (autoriser) :

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

Règle B (interdire) :

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

Résultat : PERMIT
Raison : la règle A correspond, car 10 ETH est inférieur à la limite. La règle B vérifie si l'adresse du contrat correspond à une adresse interdite. En raison de la normalisation des valeurs nulles, l'adresse de contrat non renseignée est résolue en "". L'évaluation de la comparaison "" == "0xBannedContract" renvoie false. Étant donné que la stratégie d'interdiction ne correspond pas, mais que la stratégie d'autorisation correspond, la transaction est autorisée.

Scénario 10 : Vérification explicite des champs vides ou manquants

Contexte : un appelant envoie un transfert ETH standard (qui n'est pas envoyé à un contrat intelligent). L'ensemble de règles comprend les éléments suivants :