הערכת מדיניות באמצעות Cedar

בדף הזה מוסבר איך מנוע המדיניות של חישוב רב-משתתפים (MPC) מעריך את מדיניות העסקאות שנכתבה בשפת המדיניות Cedar, מטפל בתרחישים של שרשראות שונות ופותר שדות מטא-נתונים אופציונליים או כאלה שהושמטו.

עקרונות ההערכה הבסיסיים

מנוע המדיניות משתמש בשפת המדיניות Cedar כדי לאשר פעולות של חתימה קריפטוגרפית. המנוע מעריך את כללי המדיניות באופן דטרמיניסטי באמצעות שלוש אקסיומות בסיסיות:

  1. דחיית כל מה שלא מפורש: כל הפעולות נדחות באופן משתמע. כדי שפעולה תאושר, היא צריכה להתאים לפחות למדיניות פעילה אחת של permit. אם לא נמצאה מדיניות permit תואמת, ההחלטה הסופית היא DENY.
  2. איסור מפורש: מדיניות forbid פועלת כשינוי מוחלט. אם פעולה תואמת למדיניות forbid פעילה כלשהי, ההחלטה מתקבלת מיד כ-DENY, בלי קשר לכללי מדיניות permit תואמים שהיו מאפשרים את הפעולה.
  3. שדות חסרים פירושם "אין התאמה" (דילוג): אם כלל מחפש שדה שלא קיים במטען הייעודי (payload) של העסקה (כמו שדה אופציונלי שהושמט), Cedar לא קורס. הוא מתייחס לכלל הספציפי הזה כאל "אין התאמה" (מחזיר False) ועובר לכלל הבא.

מטריצת הערכה לוגית

בטבלה הבאה מוסבר איך Policy Engine מעריך שילובים של כללים.

בכל התרחישים, נניח ש:

  • הגורם שמבצע את הטרנזקציה (מיוצג כחשבון המשתמש במדיניות של Cedar) הוא אליס (User::"alice"). בחישוב רב-משתתפים, חשבון משתמש מייצג את הפרסונה או הזהות שמבקשת הרשאה לפעולת חתימה קריפטוגרפית (כמו חותם אנושי, לקוח של שירות אוטומטי או חשבון מערכת לקצה העורפי).
  • העסקה מעבירה בדיוק 1 ETH (מיוצג כ-1,000,000,000 יחידות ננו-מטבעות מותאמות ב-context.transaction.spend_amount_scaled).
תרחיש כללי מדיניות פעילים תוצאה סיבה
תרחיש 1: מצב ריק אין כללי מדיניות פעילים. DENY כברירת מחדל, כל הפעולות חסומות, אלא אם הן מותרות באופן מפורש על ידי מדיניות permit תואמת.
תרחיש 2: התאמה להיתר אחד 
permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 10000000000
};

עד 10 ETH

 PERMIT הפרמטרים של העסקה עומדים בתנאי המדיניות. מכיוון שאין כללי מדיניות סותרים של forbid, הבקשה מותרת.
תרחיש 3: חוסר התאמה בהיתר יחיד 
permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 500000000
};

מאפשר עד 0.5 ETH

 DENY סכום ההעברה (1 ETH) חורג מהמגבלה שנקבעה במדיניות. מכיוון שאין כללי permit תואמים, ברירת המחדל של הדחייה חוסמת את העסקה.
תרחיש 4: כמה כללי מדיניות של הרשאות

מדיניות א':

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

מאפשר עד 0.5 ETH

מדיניות ב':

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

אפשר להעביר עד 5 ETH

 PERMIT למרות שמדיניות א' לא תואמת, מדיניות ב' כן תואמת. כדי לאשר את העסקה, צריך רק כלל מדיניות תואם אחד של permit.
תרחיש 5: התנגשות בין הרשאה לאיסור

מדיניות א' (אישור):

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

אפשר להעביר עד 5 ETH

מדיניות ב' (איסור):

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

ההנחה היא שהיעד הוא 0xBlockedAddress

 DENY ההעברה נשלחת אל 0xBlockedAddress. למרות שסכום העסקה מותר לפי מדיניות א', היעד תואם לקריטריונים של מדיניות ב'. הכלל המפורש forbid מבטל את מדיניות א' וחוסם את העסקה.
תרחיש 6: מדיניות איסור שלא תואמת

אותם כללי מדיניות כמו בתרחיש הקודם

 PERMIT ההעברה נשלחת לכתובת בטוחה (למשל, 0xSafeAddress). כלל מדיניות א' תואם בהצלחה, וכלל מדיניות ב' לא תואם כי היעד הוא לא 0xBlockedAddress. אם אין כלל חסימה תואם, המערכת תחיל את כלל ההרשאה.

תרחישים של רשתות מרובות ושדות אופציונליים

הטבלה שלמעלה מציגה את סדר הקדימויות הלוגי הבסיסי של כללים מותרים ואסורים. התרחישים הבאים ממחישים איך Policy Engine מעריך כללים בסביבה עם כמה רשתות בלוקצ'יין: באופן ספציפי, כשמבצעים הרצה מול שדות אפשרויות או סכימות שונות של רשתות בלוקצ'יין.

הערה: נורמליזציה של נתונים עם ערך אפס כדי למנוע שגיאות הערכה לא צפויות ולהבטיח את יכולת החיזוי של המדיניות, שכבת הניתוח של Policy Engine מבצעת נורמליזציה של שדות מחרוזת ובייטים לא מאוכלסים בהקשר ההערכה לערכי האפס הספציפיים לסוג שלהם (כמו מחרוזת ריקה "" או מערך בייטים ריק) במקום להשמיט אותם.

ההתנהגות הזו מאפשרת לכם לנסח כללי מדיניות מפורשים שמטרגטים שדות לא מאוכלסים, בלי להסתכן בשגיאות הערכה של Cedar. עם זאת, גישה לשדות שלא מוגדרים בכלל בסכימה של בלוקצ'יין (כמו gas_limit של EVM בלבד בעסקת ביטקוין, או outputs של ביטקוין בלבד בעסקת EVM) תגרום לשגיאת הערכה של Cedar במדיניות הספציפית הזו, וכתוצאה מכך היא תעריך ל-false (אין התאמה) ותיכשל באופן בטוח.

תרחיש 7: הערכת מדיניות בין שרשראות ומאפייני סכימה לא ממופים

  • הקשר: משתמש שולח עסקה בביטקוין. עם זאת, קבוצת המדיניות הפעילה מכילה מדיניות ספציפית ל-Ethereum:

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

  • התוצאה: DENY

  • הסיבה: מאפייני Intent אוניברסליים (כמו spend_amount_scaled,‏ recipient ו-max_fee_atomic) נבדקים באופן עקבי גם בעסקאות אתריום וגם בעסקאות ביטקוין. כשמדיניות מפנה למאפיינים ספציפיים לשרשרת שלא קיימים בסכימה של העסקה שנשלחה (כמו gas_limit בעסקת ביטקוין), Cedar מתייחס למאפיין שלא תואם ככשל בהערכה, ופותר את המדיניות הספציפית הזו ל-false (אין התאמה) בלי לעצור את המנוע. מכיוון שאין מדיניות פעילה אחרת של permit שתואמת לעסקת הביטקוין, הפעולה נדחית כברירת מחדל.

תרחיש 8: חסר שדה אופציונלי במדיניות permit

  • הקשר: מבצע קריאה שולח העברת ETH רגילה (שלא משתמשת בחוזים חכמים). קבוצת כללי המדיניות הפעילה מכילה כלל שבודק אינטראקציות של חוזים:

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

  • התוצאה: DENY

  • הסיבה: בהעברת ETH רגילה, השדה האופציונלי asset_contract_address לא מאוכלס. המנתח מנרמל את זה למחרוזת הריקה עם ערך אפס "" בהקשר של ההערכה. הערכת ההשוואה "" == "0x1111..." מחזירה את הערך false (אין התאמה) במקום להציג שגיאה. מכיוון שאין מדיניות אחרת שמאפשרת את ההעברה, הפעולה נדחית כברירת מחדל.

תרחיש 9: חסר שדה אופציונלי במדיניות forbid

  • הקשר: מישהו שולח העברה רגילה של 10 ETH. קבוצת כללי המדיניות כוללת:

    • מדיניות א' (אישור):

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

    • מדיניות ב' (איסור):

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

  • התוצאה: PERMIT

  • הסיבה: מדיניות א' תואמת כי 10 ETH נמוך מהמגבלה. מדיניות ב' בודקת אם כתובת החוזה תואמת לכתובת חסומה. בגלל נורמליזציה של ערכי אפס, כתובת החוזה הלא מאוכלסת הופכת ל-"". הערכת ההשוואה "" == "0xBannedContract" מחזירה את הערך false. מכיוון שמדיניות האיסור לא תואמת ומדיניות ההרשאה כן תואמת, העסקה מותרת.

תרחיש 10: בדיקה מפורשת של שדות ריקים או חסרים

  • הקשר: מבצע קריאה שולח העברת ETH רגילה (שלא נשלחת לחוזה חכם). קבוצת כללי המדיניות כוללת:

    • מדיניות א' (אישור):

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

    • מדיניות ב' (איסור):

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

  • התוצאה: DENY

  • הסיבה: בגלל נורמליזציה של המנתח, הערך החסר asset_contract_address מוצג בהקשר של ההערכה כמחרוזת ריקה "". הערכת מדיניות ב' פותרת את התנאי ל-true ("" == ""). מדיניות forbid תואמת, והטרנזקציה נדחית.

אימות לפני הערכה (שער Fail-Fast)

‫Policy Engine אוכף אימות נתונים קפדני. לפני שהמטען הייעודי (payload) מועבר ל-Cedar להערכת מדיניות, המנתח הבסיסי מאמת את מבנה העסקה, את קידוד ה-RLP ואת התקינות הקריפטוגרפית.

תרחיש 11: נתוני עסקאות לא תקינים או בפורמט שגוי

  • הקשר: לקוח שולח רצף בייטים בפורמט שגוי, מטען ייעודי (payload) עם מבנה לא תקין או עסקה שחסרים בה שדות קריפטוגרפיים חובה (למשל, עסקת EVM עם מבנה RLP לא תקין או פרמטרים חסרים של גז).
  • התוצאה: gRPC InvalidArgument
  • הסיבה: מנתח העסקאות הפנימי מזהה את הקלט הלא תקין בשכבת API Gateway. הפעולה נכשלת מיד, הלקוח מקבל שגיאת gRPC InvalidArgument והמערכת מדלגת לגמרי על הבדיקה של Cedar Policy Engine.