פיתוח מנוע מדיניות לניהול עסקאות

תארו לעצמכם: ארנק רב-חתימות (multi-sig) עם 5 חותמים, מגבלה יומית של 2 מיליון דולר. עובד יוזם משיכה של 1.8 מיליון דולר לכתובת שנוספה לרשימת הסנקציות של OFAC לפני שעה. החתימות נאספות, אך מנוע המדיניות בשלב הבדיקה המקדימה קורא ל-Chainalysis KYT, מקבל ציון סיכון של 85—העסקה נחסמת. ללא מנוע כזה, הכספים היו קפואים למשך שבועות, והחברה עלולה הייתה לעמוד בפני קנס של עד 500,000 דולר. אנו מתכננים ומיישמים מערכת חוקים לארנקי שמירה (custodial) ולחתימות מרובות ארגוניות. המנוע מפעיל סט חוקים לפני החתימה—זהו ההבדל המרכזי מעיבוד לאחר מעשה. לצוות שלנו ניסיון של 8 שנים בפיתוח בלוקצ'יין ומעל 40 הטמעות לפתרונות שמירה מרכזיים.

כיצד פועלת מערכת ניהול העסקאות?

מנוע מדיניות—שכבה בין היוזם לביצוע. הוא מעריך חוקים לפני שהעסקה הולכת לחתימה ואל ה-mempool. החוקים בודקים פרמטרים, הקשר (תפקיד השולח, זמן), נתונים חיצוניים (API של ציות), ומצב על-השרשרת. תוצאה: אישור, דחייה, בקשת חתימות נוספות, או עיכוב.

לפי מפרט Safe{Core} Protocol, ה-preCheck של Hooks נקרא לפני ביצוע העסקה.

ארכיטקטורת מערכת החוקים

רמות יישום מדיניות—עיצוב מערכת מדיניות

מנוע המדיניות יכול להתקיים במספר רמות—לעיתים קרובות הן מעורבות, מה שגורם לבעיות:

• ביצוע מקדים מחוץ לשרשרת—הנפוץ ביותר. החוקים נבדקים בשירות לפני החתימה. גמיש, זול, תומך בכל לוגיקה. חיסרון: דורש אמון בשירות זה.
• אכיפה על-השרשרת—חוזה חכם, נקודת הכניסה לכל העסקאות. Safe{Core} Protocol Hooks הוא דוגמה. ערבויות חזקות יותר, אך הלוגיקה מוגבלת על-השרשרת: אין גישה לנתונים חיצוניים ללא oracles, כל בדיקה עולה גז.
• היברידי—המדיניות מאומתת מחוץ לשרשרת, החוזה מקבל הוכחה (scheme התחייבות או אישור חותם מהימן).

למה לשלב מחוץ לשרשרת ועל-השרשרת?

הערכה מחוץ לשרשרת מהירה פי 10 ואינה צורכת גז, אך על-השרשרת מספקת ערבויות בלתי ניתנות לשינוי. הפתרון האופטימלי הוא ארכיטקטורה היברידית: חוקים מהירים מחוץ לשרשרת כמסנן ראשון, מדיניות קריטית (מגבלות פרוטוקול) בחוזים חכמים. בפרויקט אחד, אנו מעבדים 500+ חוקים עם זמן השהיה מתחת ל-5 אלפיות השנייה, וחוסכים עד 70% זמן במודרציה ידנית. עלות הפיתוח מוערכת באופן פרטני אך משתלמת דרך הפחתת אירועי ציות. עסקה אחת לא חסומה יכולה לחסוך מעל מיליון דולר, והחיסכון השנתי יכול להגיע ל-5 מיליון דולר.

מודל חוק

חוק מורכב מתנאי ופעולה. תנאים יכולים להיות:

• פרמטריים: amount > threshold, recipient in whitelist, token == USDC
• הקשרים: sender.role == OPERATOR, time_of_day in 09:00-18:00, daily_volume + amount <= limit
• חיצוניים: chainalysis_risk_score(recipient) < 70, ofac_check(recipient) == CLEAR
• על-השרשרת: recipient.is_contract == false, token.paused == false

פעולות: ALLOW, DENY, REQUIRE_APPROVAL(n_signers), DELAY(duration), NOTIFY(channels).

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

interface PolicyRule { id: string; priority: number; conditions: Condition[]; conditionLogic: 'AND' | 'OR'; action: PolicyAction; metadata: { name: string; owner: string; updatedAt: number }; } interface PolicyAction { type: 'ALLOW' | 'DENY' | 'REQUIRE_APPROVAL' | 'DELAY'; params?: { requiredApprovers?: string[]; minApprovals?: number; delaySeconds?: number; notifyChannels?: string[]; }; } 

מעריך: סדר הערכה

המנוע חייב לעבד חוקים ביעילות—במיוחד כאשר יש מאות חוקים וחלקם דורשים קריאות חיצוניות (API של ספק ציות).

האסטרטגיה האופטימלית: הערכת short-circuit עם מטמון. ראשית, נבדקים תנאים מקומיים זולים (פרמטרי עסקה, תפקידים), לאחר מכן נתונים חיצוניים במטמון, ולבסוף קריאות API טריות עם timeout.

class PolicyEvaluator: def evaluate(self, tx: Transaction, context: EvalContext) -> PolicyDecision: sorted_rules = sorted(self.rules, key=lambda r: r.priority, reverse=True) for rule in sorted_rules: cheap_conditions = [c for c in rule.conditions if c.type == 'PARAMETRIC'] if not self._eval_conditions(cheap_conditions, tx, context): continue expensive_conditions = [c for c in rule.conditions if c.type == 'EXTERNAL'] cache_key = self._cache_key(expensive_conditions, tx) cached = self.cache.get(cache_key) results = cached if cached else self._eval_external(expensive_conditions, tx) self.cache.set(cache_key, results, ttl=300) if self._eval_conditions_with_results(rule.conditions, results, rule.conditionLogic): return PolicyDecision(action=rule.action, rule_id=rule.id) return PolicyDecision(action=DEFAULT_ACTION) 

יישום על-השרשרת: Safe Hooks

ה-Safe{Core} Protocol (תואם EIP-7579) מספק מנגנון hooks:

interface ISafeProtocolHooks { function preCheck( Safe safe, SafeTransaction calldata tx, uint256 executionType, bytes calldata executionMeta ) external returns (bytes memory preCheckData); function postCheck( Safe safe, bool success, bytes calldata preCheckData ) external; } 

interface PolicyRule { id: string; priority: number; conditions: Condition[]; conditionLogic: 'AND' | 'OR'; action: PolicyAction; metadata: { name: string; owner: string; updatedAt: number }; } interface PolicyAction { type: 'ALLOW' | 'DENY' | 'REQUIRE_APPROVAL' | 'DELAY'; params?: { requiredApprovers?: string[]; minApprovals?: number; delaySeconds?: number; notifyChannels?: string[]; }; } נקרא לפני הביצוע. אם הוא חוזר (revert)—העסקה נכשלת. כאן ניתן: לבדוק רשימה לבנה/שחורה (המאוחסנת באחסון ה-hook), לבדוק מגבלות (באמצעות accumulators לפי כתובות/טוקנים), לדרוש אישור נוסף באמצעות timelock.

דוגמת hook מגבלה:

contract DailyLimitHook is ISafeProtocolHooks { mapping(address => mapping(address => uint256)) public dailyVolume; mapping(address => mapping(address => uint256)) public lastResetDay; mapping(address => mapping(address => uint256)) public dailyLimit; function preCheck(Safe safe, SafeTransaction calldata tx, uint256, bytes calldata) external returns (bytes memory) { address token = _extractToken(tx.data); uint256 amount = _extractAmount(tx.data); uint256 today = block.timestamp / 1 days; address safeAddr = address(safe); if (lastResetDay[safeAddr][token] < today) { dailyVolume[safeAddr][token] = 0; lastResetDay[safeAddr][token] = today; } require( dailyVolume[safeAddr][token] + amount <= dailyLimit[safeAddr][token], "DailyLimitExceeded" ); return abi.encode(token, amount); } function postCheck(Safe safe, bool success, bytes calldata preCheckData) external { if (success) { (address token, uint256 amount) = abi.decode(preCheckData, (address, uint256)); dailyVolume[address(safe)][token] += amount; } } } 

כיצד לשלב API של ציות?

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

• Chainalysis—API של KYT בודק כתובות (ציון סיכון) ועסקאות (חשיפה לאשכולות ידועים). זמן השהיה: 200–800ms, יש צורך במטמון ובירידה הדרגתית (graceful degradation).
• Elliptic—פונקציונליות דומה, מודל הערכת סיכון שונה. בשימוש ב-Fireblocks.
• TRM Labs—מתמחה בניתוח חוצה-שרשרת, כיסוי טוב של Solana ו-Tron.
• סינון OFAC—ניתן לבצע דרך אותם ספקים או באמצעות snapshot עצמי של רשימת SDN (מתעדכן לעיתים רחוקות, ניתן לאחסון מקומי ועדכון דרך webhook).

חשוב: ל-API של ציות יש SLAs והם עלולים להיות לא זמינים. למנוע המדיניות חייבת להיות מדיניות ברורה למקרה של EXTERNAL_CHECK_TIMEOUT: fail-open (אישור עם לוג) לעומת fail-closed (חסימה). זו החלטה עסקית, אך היא חייבת להיות מתועדת.

כיצד אנו מיישמים את מנוע המדיניות?

1. ניתוח דרישות—קביעת חוקים עסקיים, חובות ציות, אילוצים טכניים (זמן השהיה, תפוקה).
2. עיצוב מודל חוקים—עיצוב היררכיית חוקים, תנאים, פעולות, מדיניות פתרון קונפליקטים.
3. פיתוח מעריך—כתיבת ליבת המנוע עם הערכת short-circuit, מטמון, ואינטגרציה עם API חיצוני.
4. אינטגרציה ובדיקות—חיבור המנוע לארנק או ל-multisig, ביצוע בדיקות עומס ורגרסיה.

הזמינו פיתוח מנוע מדיניות כדי להגן על הנכסים שלכם.

ניטור וביקורת

מערכת חוקים ללא לוג ביקורת מלא היא חסרת ערך לציות. כל החלטה חייבת להכיל:

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

זהו לוג בלתי ניתן לשינוי. אחסון: PostgreSQL עם טבלת append-only + שכפול ל-S3/Arweave לשימור ארוך טווח. לדרישות רגולטוריות—מינימום 5 שנים.

מה כלול בפיתוח

• תיעוד פרויקט (ארכיטקטורה, מודל חוקים)
• קוד מקור של המנוע (מעריך מחוץ לשרשרת ו-hooks על-השרשרת)
• אינטגרציה עם ספקי ציות (Chainalysis, Elliptic וכו')
• הגדרת מטמון וירידה הדרגתית
• הקמת לוג ביקורת והגדרתו
• הדרכת צוות ותיעוד מנהלים
• 3 חודשי תמיכה לאחר השחרור

קבלו ייעוץ על יישום מנוע מדיניות—אנו נעזור לתכנן ולפרוס פתרון מפתח ביד.