---
title: "فك ترميز Calldata في المحفظة"
description: "دليل يبدأ بالتحقق من Calldata للمعاملات، وكلمات ABI وإزاحاتها، وتصادم المحددات، والوكلاء، والدفعات، والموافقات، وتصاريح البيانات المهيكلة، والمحاكاة، والمطابقة بعد المعاملة."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# فك ترميز Calldata في المحفظة

> لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

<a id="answer"></a>

## الإجابة المباشرة

Calldata هي سلسلة البايتات الثابتة المقدمة كمدخل لمعاملة Ethereum من المستوى الأعلى أو لاستدعاء رسالة داخلي. يبدأ استدعاء دالة Solidity التقليدي بمحدد `4-byte` تتبعه وسائط مرمزة وفق ABI، لكن Calldata لا تصف نفسها: فقد تعني البايتات ذاتها أشياء مختلفة باختلاف الشيفرة المنفذة أو تطبيق الوكيل أو المخطط. ولا يلزم أن تتبع دوال fallback أو التجميع الخام أو البروتوكولات غير المكتوبة بـ Solidity واجهة الدوال التقليدية أصلًا.

لذلك ينبغي للمحفظة عرض ما هو أكثر من اسم دالة مرشح. تربط المراجعة الآمنة البايتات بـ `chainId` وكتلة و`from` و`to` و`value` الأصلي و`codeHash` للشيفرة المنفذة والتطبيق النشط وABI موثوق؛ وتفك كل استدعاء متداخل بصرامة؛ وتميز Calldata على السلسلة من توقيعات EIP-712؛ وتحاكي في حالة معلومة؛ ثم تطابق الإيصال الفعلي وتغيرات الحالة بعد الإدراج.

<a id="mechanism"></a>

## آلية العمل

1. ثبّت غلاف التوقيع ونقطة الملاحظة: `chainId` ورقم الكتلة وتجزئتها و`from` و`to` و`value` الأصلي وبايتات الإدخال والـ nonce وحقول الرسوم. احتفظ بمصدر المحفظة أو RPC؛ فالحمولة المفكوكة من سلسلة أو كتلة أخرى لا تمثل الادعاء نفسه.
2. صنّف الكائن قبل فك ترميزه. تستخدم المعاملة وبيانات EIP-712 المهيكلة وتصريح ERC-2612 وUserOperation في ERC-4337 ورسالة personal-sign الخام نطاقات ومخططات مختلفة؛ فلا تمررها جميعًا قسرًا عبر ABI المعاملات.
3. حدّد الهدف عند الكتلة المثبتة. اقرأ الشيفرة المنفذة و`codeHash`؛ وحدد الوكيل أو beacon أو التطبيق عند الاقتضاء؛ وسجل خانات التطبيق والمشرف؛ واحصل على ABI مطابق تمامًا لإصدار الشيفرة. سجل المحددات يقدم مرشحين لا مرجعًا حاسمًا.
4. فك الترميز بصرامة. المحدد هو أول `4 bytes` من Keccak-256 للتوقيع القانوني للدالة من دون أنواع الإرجاع. تشغل القيم الثابتة كلمات `32-byte`، وتحمل رؤوس القيم الديناميكية إزاحات من كتلة الوسائط بعد المحدد. ارفض البيانات المبتورة والإزاحات الخارجة عن الحدود والأطوال المستحيلة والحشو غير الصالح والبايتات اللاحقة غير المفسرة.
5. وسّع استدعاءات multicall وCalldata المتداخلة والتنفيذ المفوض بصورة متكررة. أدرج لكل استدعاء فرعي الهدف والقيمة الأصلية والمحدد والوسائط ونوع الاستدعاء وأي علامة `allowFailure`. مع `delegatecall` تعمل شيفرة التطبيق في سياق عنوان المستدعي ورصيده وتخزينه مع بقاء `msg.sender` و`msg.value` كما هما.
6. أنشئ سجلين منفصلين للصلاحيات والقيمة ثم حاكِ. سجل المستلمين والمنفقين ومشغلي NFT ووحدات الرموز الخام والمنازل العشرية والمواعيد النهائية وحدود الانزلاق والقيمة الأصلية. حاكِ باستخدام الكتلة والمرسل والقيمة نفسها، لكن اعتبر النتيجة لقطة مشروطة لأن الحالة والأسعار والوقت والشيفرة وترتيب المعاملات قد تتغير.
7. أكد كل حقل جوهري قبل التوقيع. بعد الإدراج افحص حالة الإيصال والسجلات وآثار التنفيذ إن توفرت وتغيرات الأرصدة والمخصصات وحالة المشغلين؛ وميز فشل الاستدعاء الفرعي الذي التقطته الشيفرة من نجاح المستوى الأعلى؛ واحسب الغاز حتى عند الارتداد؛ وانتظر النهائية المطلوبة؛ وتوقف بدل إعادة توقيع فشل غير مفسر.

<a id="example"></a>

## أمثلة محلولة

- **تحويل ERC-20 ثابت.** تستخدم `transfer(address,uint256)` عادة المحدد `0xa9059cbb`. محدد واحد مع كلمتي ABI يساوي `4 + 2 * 32 = 68 bytes`. تعرض كمية خام قدرها `1,500,000` لرمز جرى التحقق مستقلًا من أنه يستخدم `6 decimals` بوصفها `1.5 tokens`. المنازل العشرية بيانات وصفية خارجية للعقد وليست مشفرة في الوسيطين، كما أن المحدد وحده لا يعرّف العقد أو الدالة تعريفًا فريدًا.
- **إزاحة بايتات ديناميكية.** في `f(address,bytes)` مع حمولة `3-byte` يشغل الرأس المؤلف من كلمتين `64 bytes`. الإزاحة الديناميكية هي `0x40` وتقاس من بداية كتلة الوسائط مع استبعاد المحدد. يحتوي الذيل كلمة طول `32-byte` وكلمة بيانات محشوة `32-byte`، ولذلك يكون إجمالي Calldata هو `4 + 64 + 32 + 32 = 132 bytes`. إذا عوملت الإزاحة كموضع مطلق من البايت صفر فستصل متأخرًا بأربعة بايتات.
- **قيمة الدفعة خاصة بالتطبيق.** يحمل الاستدعاء الخارجي `1.00 ETH`، وتطلب ثلاثة استدعاءات فرعية مفكوكة صراحة `0.20 ETH` و`0.30 ETH` و`0.10 ETH`، أي `0.60 ETH` إجمالًا. قد يعيد كود الدفعة `0.40 ETH` المتبقية أو يحتفظ بها أو يمررها أو يرتد بسببها. وإذا فشل الاستدعاء الثالث مع `allowFailure=true` فقد تبقى الاستدعاءات السابقة نافذة، بينما قد يرتد تطبيق ذري بالكامل.
- **التصريح ليس Calldata الخاصة بالمرسِل الوسيط وقت التوقيع.** يوقع مالك لديه `1,000 USDC` تصريح ERC-2612 بقيمة `300 USDC` عند nonce يساوي `41`. التوقيع وحده لا يغير الرصيد ولا المخصص. بعد أن يقدمه وسيط بنجاح يصبح nonce هو `42` والمخصص `300`؛ وبعد إنفاق `180` يصبح الرصيد `820` والمخصص المتبقي `120`. قطع اتصال الموقع لا يلغي الصلاحية.

<a id="risks"></a>

## المخاطر

- فك الترميز اعتمادًا على سلسلة أو fork أو وسم كتلة أو غلاف معاملة خاطئ.
- التوقيع لنطاق أو عنوان هدف أو مستلم منتحل.
- اعتبار محدد `4-byte` فريدًا رغم احتمال التصادم.
- استخدام ABI مخمن أو قديم أو لم يتحقق منه بصورة صحيحة.
- الثقة بوسم مصدر موثق من دون مطابقته مع `codeHash` الحالي للشيفرة المنفذة.
- إغفال ترقية للتطبيق أو beacon أو المشرف بين المراجعة والتنفيذ.
- تجاهل دالة في الوكيل يتصادم محددها مع التطبيق.
- نسيان أن `delegatecall` يكتب في سياق تخزين المستدعي.
- قبول إزاحات أو أطوال أو حشو ديناميكي معيب أو بايتات لاحقة غير مفسرة.
- عدم توسيع دفعة متداخلة تخفي أهدافًا أو قيمًا أو صلاحيات.
- افتراض الذرية مع أن التطبيق يلتقط فشل الاستدعاءات الفرعية أو يسمح به.
- تجاهل `value` الأصلي في المستوى الأعلى لأن وسائط الرمز تبدو غير ضارة.
- تطبيق منازل عشرية خاطئة أو افتراض أن رموز رسوم التحويل وإعادة الأساس قياسية.
- منح مخصص ERC-20 غير محدود أو إساءة معالجة سباق تحديث المخصص.
- إغفال النطاق الشامل للمجموعة في `setApprovalForAll` الخاص بـ NFT.
- الخلط بين بيانات EIP-712 المهيكلة أو تصريح ERC-2612 وبين Calldata لمعاملة.
- إغفال حدود nonce والموعد النهائي والعقد المتحقق والنطاق المرتبط بالسلسلة وإعادة التشغيل.
- اعتبار المحاكاة مستقرة رغم تغير oracle أو الطابع الزمني أو الحالة المعلقة أو MEV أو الشيفرة.
- اعتبار حالة الإيصال أو السجلات أو آثار المزود دليلًا كاملًا على الحالة الاقتصادية.
- إعادة التوقيع بلا تدقيق عبر واجهة مخترقة أو تجاهل مخاطر الإدراج وإعادة التنظيم والنهائية.

<a id="misconceptions"></a>

## مفاهيم شائعة خاطئة

- محدد الدالة يعرّف بصورة فريدة ما سينفذه العقد.
- ملخص واجهة موثقة مطابق للبايتات والتطبيق الحالي محل التوقيع.
- لا يمكن لمعاملة ذات `value=0` نقل رموز أو NFT أو أصول مفوضة.
- نجاح المحاكاة أو الإيصال يثبت الأمان والنتيجة الاقتصادية المقصودة.
- قطع اتصال التطبيق اللامركزي يلغي الموافقات والتصاريح وصلاحيات مشغلي NFT.

<a id="related"></a>

## موضوعات ذات صلة

- [محاكاة المعاملات](/ar/crypto/transaction-simulation/)
- [موافقة المحفظة](/ar/crypto/wallet-approval/)
- [توقيع المحفظة](/ar/crypto/wallet-signature/)

<a id="sources"></a>

## المصادر

- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (تاريخ الاطلاع: 2026-08-12)
- [Introduction to Smart Contracts](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-and-libraries) - Solidity Documentation (تاريخ الاطلاع: 2026-08-12)
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (تاريخ الاطلاع: 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-12)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-12)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-12)
- [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (تاريخ الاطلاع: 2026-08-12)

Source: https://wiki.fcontext.com/ar/crypto/calldata-decoding-wallet/index.mdx