الاقتراض هو حجر الزاوية في تطبيقات blockchain القائمة على Ethereum. مع إقراض المليارات من الأصول، يعد فهم كيفية عمل الاقتراض أمرًا بالغ الأهمية للمطورين أو المهندسين المعماريين أو الباحثين.

تمامًا مثل تطور نماذج البرمجة، تتميز تطبيقات DeFi هذه بتصميمات معمارية متنوعة تعكس الأولويات المتغيرة التي تتراوح من الأمان إلى الكفاءة وتجربة المستخدم.

يبحث هذا التحليل في بنية تطبيقات مثل MakerDAO و Compound و Aave و Euler و Yield. سنسلط الضوء على الابتكارات الرئيسية وأنماط التصميم، والتي تعد دروسًا مهمة لتطوير تطبيقات الإقراض المستقبلية.

إذا كنت مطورًا أو مهندسًا معماريًا أو باحثًا أمنيًا، فهذه المقالة مناسبة لك. في النهاية، ستتمكن بسهولة من فهم تطبيقات الاقتراض الجديدة على إيثريوم، واستيعاب بنيتها بسرعة وبشكل شامل. تعمق لترى كيف تم بناء عمالقة DeFi من الألف إلى الياء.

الاقتراض في DeFi

معظم اقتراض DeFi مضمون بشكل مفرط. يمكن للمستخدم اقتراض أصل معين إذا قدم ضمانات تزيد قيمتها عن القرض. على عكس القروض التقليدية، لا يتم سداد العديد من هذه القروض بانتظام أو تواريخ انتهاء محددة. في الأساس، يمكنك الاقتراض وعدم السداد أبدًا.

ومع ذلك، هناك مشكلة.

يجب أن تتجاوز قيمة الضمان دائمًا قيمة القرض بهامش محدد مسبقًا.

إذا انخفضت قيمة الضمان عن هذا، تتم تصفية القرض.

أثناء التصفية، يسدد شخص آخر جزءًا من قرضك أو كله، ويتلقى جزءًا أو كل ضماناتك في المقابل.

تحتاج جميع طلبات الاقتراض التي تتبع هذا الهيكل المالي إلى نفس اللبنات الأساسية، والتي يمكن ترتيبها بعد ذلك بعدة طرق:

• خزينة لتخزين ضمانات المستخدم والأصول المقترضة
• نظام محاسبة يتتبع ضمانات وديون كل مستخدم
• الوظائف التي تحدد معدل فائدة المقترضين
• آلية للتحقق مما إذا كان القرض مضمونًا بما فيه الكفاية، وعادة ما يتضمن ذلك أسعار خارجية
• مسار تصفية للقروض غير المضمونة
• أنظمة إدارة المخاطر التي تسجل إجمالي المبالغ المقترضة ومقاييس السلامة الأخرى، مثل حدود الاقتراض العالمية لكل مستخدم، والحد الأدنى للضمانات، ونسب الإفراط في الضمانات المحددة
• واجهة للمستخدمين لإضافة وإزالة الضمانات والاقتراض والسداد الأساسي

عملية الاقتراض في MakerDAO. تشترك جميع التطبيقات في نفس الخطوات والوظائف.

يمكن اعتبار الاقتراض والإقراض كميزات منفصلة. في DeFi، نجد كلتا الميزتين في معظم تطبيقات الاقتراض، ولكنها ليست دائمًا متكاملة جيدًا.

هم في كومباوند وآيف وأويلر. ترتبط أسعار الفائدة للمقترضين والمقرضين داخليًا؛ في الواقع، هذا هو ما يجعل هذه التطبيقات تعمل بأقل قدر من التدخل.

من ناحية أخرى، فإن MakerDAO و Yield هما منشئو الأصول التي يقرضونها للمقترضين.

لا تتطلب من المستخدمين توفير الأصول حتى يتمكن المستخدمون الآخرون من الاقتراض.

ستركز هذه المقالة على الاقتراض عبر السلسلة وستتجاهل الإقراض إلى حد كبير. يعد الاقتراض أكثر تعقيدًا بسبب متطلبات الضمان، وعادة ما يؤدي فهم نمط الاقتراض إلى فهم أفضل للبروتوكول بأكمله.

التطور المعماري لـ MakerDAO

شعار ميكرداو

تم إطلاق MakerDAO ، القديمة من حيث مصطلحات Ethereum،بشكلها الحالي في نوفمبر 2019 ، ولديها ضمانات بقيمة 4.95 مليار دولار. على الرغم من بنيته المعيارية ذات العقود المميزة لكل وظيفة والمصطلحات الفريدة، إلا أنه يظل من السهل فهمه والتحقق منه.

تتم إدارة وظيفة الخزانة في MakerDAO من خلال عقود الانضمام.

هناك عقد منفصل لكل رمز تمت الموافقة عليه كأصل ضمان.

على العكس من ذلك، لا تمتلك MakerDAO أي DAI، أصل الاقتراض.

بدلاً من ذلك، يقوم فقط بسك وحرق DAI حسب الحاجة.

تتم معالجة المحاسبة ضمن عقد vat.sol. تقوم شركة Joins بتحديث هذا العقد عندما تدخل الضمانات أو تخرج من النظام. إذا قام المستخدم بالاقتراض، فإنه يتفاعل مع عقد vat.sol مباشرة.

يعمل هذا الإجراء على تحديث رصيد ديون المستخدم ويسمح له بسك DAI في DAI Join.

للسداد، يحرق المستخدمون DAI في DAI Join. تقوم هذه العملية بعد ذلك بتحديث ضريبة القيمة المضافة، مما يمكّن المستخدم من تسوية قرضه.

بالإضافة إلى ذلك، يعمل عقد vat.sol كمحرك لإدارة المخاطر. وهي تحافظ على حدود الاقتراض العالمية، وتضع الحدود الدنيا لكل مستخدم، وتشرف على نسب الضمان.

عندما يتم إجراء تغييرات على ديون المستخدم أو رصيد الضمانات، يقوم عقد vat.sol بتقييم السعر والسعر الفوري.

تشير هذه إلى سعر الفائدة بناءً على الضمانات المستخدمة ونسبة سعر DAI إلى الضمان السائدة. ومن المثير للاهتمام أن هذه القيم يتم إدخالها في عقد vat.sol من خلال عقود MakerDAO الأخرى، وهي طريقة متميزة عن معظم التطبيقات الأخرى.

أعطت MakerDAO الأولوية للسلامة خلال مرحلة التصميم - في الوقت الذي كانت فيه عوامل مثل تكاليف الغاز ثانوية، وكانت تجربة المستخدم مصدر قلق بسيط، وكانت المنافسة ضئيلة.

وبالتالي، قد يبدو الأمر غريبًا ومكلفًا للاستخدام وصعبًا للتنقل.

ومع ذلك، فإن الأصول الضخمة التي تديرها وسجل عملياتها دون انتهاكات كبيرة تؤكد تصميمها القوي وتنفيذها.

أبرز الملامح:

• كل أصل له عقده الخاص في وظيفة الخزانة ذات الانتشار الأقصى
• تتمركز وظيفة المحاسبة في عقد واحد يقوم أيضًا بتوثيق معايير المخاطر وإنفاضها، بما في ذلك فحوصات الضمان.
• على عكس التطبيقات الأخرى، تقوم Oracle بتحديث العقد والإشراف على الضمانات
• تستخدم أوراكل السعر وسعر الفائدة واجهات متميزة
• ينشأ سعر الفائدة خارجيًا
• للاقتراض، يجب على المستخدمين التفاعل مع عقود متعددة

التطور المعماري لبروتوكول العائد

كان Yield v1 بمثابة دليل على مفهوم الأسعار الثابتة باستخدام YieldSpace. قامت هذه النسخة ببناء محرك الديون المضمونة على رأس MakerDAO. ومع ذلك، كان Yield v1 مكلفًا للاستخدام وصعبًا في زيادته بالميزات الجديدة.

إدراكًا لإمكانات YieldSpace، انتقلنا بسرعة إلى تطوير Yield v2. لا يزال Yield v2 يستمد الإلهام من MakerDAO، ولكنه الآن مستقل تمامًا، وتم إطلاقه في أكتوبر 2021؛ أعطى Yield v2 الأولوية لتكاليف الغاز المخفضة وتجربة المستخدم المحسنة.

تأثرت عملية الاقتراض في Yield v2 بشدة بـ MakerDAO

تم دمج جميع فحوصات المحاسبة وإدارة المخاطر والضمانات في عقد واحد: Cauldron. انعكاسًا لنهج MakerDAO، قمنا بتوزيع وظائف الخزانة عبر عقود Join ، كل منها مخصص لأصل معين.

قمنا بتجديد تكامل Oracle الخاص بنا، ودمج أوراكل السعر وسعر الفائدة في واجهة مشتركة. لقد عكسنا تدفق أوراكل من MakerDAO بحيث يستشير Cauldron أوراكل حسب الحاجة لفحوصات الضمان. على حد علمي، هذا هو التدفق المفضل في كل مكان باستثناء MakerDAO.

كان الانحراف المهم الآخر عن نهج MakerDAO هو إدخالنا للمغرفة. يعمل هذا العقد كوسيط وحيد بين المستخدمين وYield. وهي تتمتع بسيطرة واسعة على الخزانة والمحاسبة، ولكنها في المقابل توفر مرونة هائلة لتطوير الميزات.

باختصار، يعمل الاقتراض في Yield v2 على النحو التالي:

• يحتوي كل أصل على عقد خزانة مخصص خاص به، مما يضمن أقصى توزيع لوظيفة الخزانة.
• يعمل العقد المفرد على تركيز وظيفة المحاسبة. يشرف هذا العقد أيضًا على تدابير إدارة المخاطر ويقوم بإجراء فحوصات الضمان.
• تستشير وظيفة الضمانات أوراكل لتحديد الأسعار وأسعار الفائدة.
• تشترك كل من أوراكل السعر وسعر الفائدة في واجهة موحدة.
• يتم إنشاء أسعار الفائدة خارجيًا.
• يمكن للمستخدمين الاقتراض من خلال تقديم طلب واحد لعقد واحد فقط.

التطور المعماري للتمويل المركب

كان الإصدار الأول من Compound بمثابة إثبات للمفهوم، مما يدل على أنه يمكن إنشاء سوق المال على Ethereum. لهذا السبب، تم إعطاء الأولوية للبساطة في تصميمها. يشمل عقد MoneyMarket.sol جميع الوظائف، بما في ذلك الإقراض.

عملية الاستعارة في المركب v1. بسيطة لكنها فعالة.

• يتم دمج مهام الخزانة والمحاسبة وإدارة المخاطر، مثل شيكات الضمان، في عقد واحد.
• يسترد هذا العقد الأسعار من أوراكل ولكنه يحدد أسعار الفائدة بناءً على استخدام الأصول.
• يتفاعل المستخدمون فقط مع هذا العقد، على الرغم من أنه يجب عليهم إجراء مكالمات منفصلة لتوفير الضمانات واقتراض الأصول.

مركب v2

تم إطلاق Compound v2 في مايو 2019، مما أدى إلى إشعال عصر زراعة المحاصيل وإلهام عدد لا يحصى من الشوكات. لقد عملت أيضًا كسوق نقدي، مما يسمح للمستخدمين بإقراض الأصول واقتراضها.

استنادًا إلى الورقة البيضاء وهيكلها، من الواضح أن الهدف الرئيسي لـ Compound v2 كان استخدام معيار ERC20 لتمثيل مراكز الإقراض. وقد ضمن ذلك قابلية التركيب، مما سمح للمستخدمين بإقراض Compound ثم استخدام تلك المراكز ذات الفائدة في تطبيقات بلوكتشين الأخرى.

ومن المثير للاهتمام أن الورقة البيضاء لم تسلط الضوء على أن Compound v2 أدرجت المكافآت في عقودها الذكية. نظرًا لهذا الإغفال، ربما لم يكن التأثير الهائل لهذه الميزة متوقعًا.

عملية الاستعارة في المركب v2. أول دخول في مراكز الإقراض الرمزية.

• لكل أصل عقد خزانة خاص به، مما يزيد من توزيع وظيفة الخزانة.
• يتم توزيع وظيفة المحاسبة أيضًا، حيث يشير كل رمز cToken إلى ضمانات المستخدم والديون.
• يقوم العقد الوحيد، المراقب المالي، بتسجيل وإنفاذ معايير إدارة المخاطر، بما في ذلك فحوصات الضمان.
• يشير العقد المسؤول عن عمليات التحقق من الضمانات إلى أوراكل الأسعار و cToken لأسعار الفائدة.
• تعمل أوراكل السعر وسعر الفائدة بواجهات مختلفة.
• يُستمد معدل الفائدة داخليًا من استخدام الأصول.
• يجب على المستخدمين التفاعل مع عقود متعددة للاقتراض.

مركب v3

تم إصدارCompound v3 في عام 2022 ، وهو يتبنى استراتيجية أكثر تحفظًا لإدارة المخاطر، حيث يقوم بفصل السيولة إلى مجمع لكل أصل قابل للاقتراض. يكشف التصميم أيضًا عن مخاوف بشأن سهولة الاستخدام وتكاليف الغاز.

عملية الاستعارة في المركب v3 (Comet). العودة إلى الأساسيات والعودة إلى الأمان. مع تجربة مستخدم أفضل، على الرغم من ذلك.

يعد النظام أكثر سهولة لكل من المطورين والمستخدمين بسبب انخفاض عدد المكالمات المطلوبة. بالإضافة إلى ذلك، يعمل تصميم العقد الفردي على تقليل تكاليف الغاز عن طريق تقليل المكالمات بين العقود. تعد أسواق المال المنفصلة بمثابة دفاع ضد الهجمات القائمة على Oracle، والتي أصبحت الآن مصدر قلق أمني كبير.

تشمل الميزات الأخرى ذات الصلة المذكورة في ملاحظات الإصدار ما يلي:

• محرك تم تجديده بالكامل لإدارة المخاطر والتصفية. يعزز هذا التصميم أمان الأموال مع كونه أكثر ملاءمة للمقترض.
• ضع حدودًا في جميع أنحاء السوق لأصول الضمان الفردية للتخفيف من المخاطر.
• أصبحت نماذج أسعار الفائدة للكسب والاقتراض منفصلة الآن، حيث تتمتع الحوكمة بالسيطرة الكاملة على السياسات الاقتصادية.

ومن المثير للاهتمام أن Compound v3 يعكس بنية Compound v1 من خلال وجود عقد واحد يتعامل مع جميع الوظائف لكل أصل قابل للاقتراض. تشمل الميزات البارزة الأخرى ما يلي:

• يمكن اقتراض الأصول المقرضة فقط؛ ولا يمكن اقتراض الأصول المضمونة.
• لا تحقق الضمانات عوائد في المركب v3.

يعزز حظر اقتراض الضمانات سلامة أولئك الذين يودعون الضمان. هذا يقلل من احتمالية تعرض أخطاء الحوكمة أو الهجمات المتعمدة للخطر.

قد يكون إلغاء العوائد على الضمانات المقدمة نتيجة تمكن المركب من جمع الكثير من السيولة في الإصدار 2. لدي حدس مفاده أن حدود الاقتراض في Compound v2 كانت إما أقل أو ليست أعلى بكثير من الأصول التي أقرضها المستخدمون للتطبيق.

على افتراض أنهم سيديرون مستويات مماثلة من السيولة لـ v3، فإن عدم السماح بإقراض الضمانات يجعل التطبيق آمنًا، وهو أحد الأهداف الأساسية لـ v3.

من وجهة نظر معمارية:

• كل سوق مالي هو عقد فردي مع الخزانة والمحاسبة وإدارة المخاطر
• يحتفظ كل سوق مالي بالأصول القابلة للاقتراض جنبًا إلى جنب مع جميع رموز الأصول المضمونة المعتمدة، مما يتسبب في توزيع الأصول عبر التطبيق
• تغذية الأسعار هي المدخلات الخارجية الوحيدة؛ يتم إنشاء أسعار الفائدة للاقتراض والإقراض داخليًا
• تم دمج الوظائف التقليدية مثل التوريد/السحب/الاقتراض/السداد بذكاء. الآن، يعني سحب الأصول القابلة للاقتراض من سوق المال الاقتراض، بينما يشير توريدها إلى السداد أو الإقراض بناءً على ديون المستخدم
• تم دمج عقد التوجيه، مما يسمح بعمليات متعددة في مكالمة واحدة

التطور المعماري لـ Aave

تمإطلاق Aave v1 في أكتوبر 2019 ، خلفًا لـ EthLend. بدلاً من نهج نظير إلى نظير الخاص بـ EthLend، قدم Aave v1 تجمع سيولة مشترك.

عملية الاقتراض في Aave v1. السيولة المجمعة تعني الكفاءة المالية والحسابية.

كما هو الحال في Yield v2، احتفظ عقد جهاز التوجيه أيضًا بمنطق الأعمال. نفذت LendingPoolCore وظائف المحاسبة وإدارة المخاطر والخزينة. كان تجميع الخزانة في عقد واحد نقطة مميزة عن Compound v2.

يبدو قرار ترك شيكات الضمان في عقده الخاص، والذي تم استدعاؤه من جهاز التوجيه وليس عقد المحاسبة، ضعيفًا، ولكن ربما كان مناسبًا للغرض حيث تم إصدار Aave v2 بعد عامين فقط من إصدار v1.

• يتعامل عقد LendingPoolCore مع الخزانة والمحاسبة
• LendingPoolDataProvider يدير عمليات التحقق من الضمانات ويتفاعل مع أوراكل
• يعمل LendingPool كنقطة دخول للمستخدم وينفذ منطق الأعمال
• يتم تحديد أسعار الفائدة للاقتراض والإقراض داخليًا، بالاعتماد فقط على تغذية الأسعار.

احفظ الإصدار 2

تمإصدار Aave v2 في ديسمبر 2021. على الرغم من احتفاظه بميزات مشابهة لـ Aave v1، إلا أنه قدم بنية محسنة وأبسط مقارنة بكل من Aave v1 و Compound v2. مع هذا الإصدار، قدمت Aave أيضًا ATokens (على غرار cTokens من Compound) و vTokens، والتي تمثل دينًا مرموزًا.

يحتوي Aave v2 على بنية نظيفة للغاية، مشفرة بالكامل.

تم حذف بعض الميزات من Aave v1، والتي كانت ذات استخدام محدود، من أجل البساطة. تمت معالجة المشكلات في Aave v1، مثل التمثيل المعقد للفائدة المتراكمة، في Aave v2.

• يدمج عقد LendingPool وظائف المحاسبة وإدارة المخاطر العالمية، مثل فحوصات الضمان. وهي بمثابة نقطة الوصول الأساسية للمستخدمين
• تشير ATokens إلى الضمانات وتشبه مراكز الإقراض. تنعكس ضمانات المستخدمين من خلال مقتنيات Atoken الخاصة بهم، ويتم توزيع وظيفة الخزانة عبر جميع AtTokens
• يتم استخدام vTokens لتمثيل مراكز الديون. يتم تمثيل ديون المستخدم من خلال vTokens التي يمتلكها

الموجة v3

تمإصدار Aave v3 في يناير 2023 مع دعم متعدد السلاسل وميزات أخرى. لا تغير هذه الإضافات البنية الأساسية. يتميز التحديث أيضًا بتحسين إدارة المخاطر وكفاءة الغاز.

على الرغم من التطورات العديدة، لأغراض هذه الدراسة، لا يختلف Aave v3 ماديًا عن Aave v2. في الواقع، قد يشير ذلك إلى أن بنية Aave v2 تظل قوية في عام 2023.

التطور المعماري لأويلر

تم إطلاق Euler في ديسمبر 2022 ، بهدف تزويد أسواق المال بميزات غير مصرح بها والحد الأدنى من الحوكمة.

السمة المميزة لتصميمها هي النمط الشبيه بالماس. يحتفظ عقد واحد بكل مساحة تخزين التطبيق. يمكن الوصول إلى هذا التخزين من خلال بروكسيات متميزة، كل منها يدير عنصرًا مفاهيميًا مختلفًا للنظام.

على الرغم من أن عقدًا واحدًا يخزن جميع الأصول والمحاسبة وبيانات إدارة المخاطر، فلا تزال هناك رموز إلكترونية للضمان والإقراض، و dTokens للديون، على غرار Aave v2. ومع ذلك، فإن هذه العقود الرمزية هي مجرد وجهات نظر لعقد التخزين المركزي.

• يقوم عقد التخزين بإدارة المتغيرات المحاسبية.
• يعمل عقد BaseLogic كخزانة.
• يشرف عقد RiskManager على متغيرات ووظائف إدارة المخاطر، بما في ذلك فحوصات الضمان.

يكشف تحليل الكود أن الحد الأدنى من تكلفة الغاز كان أولوية، مما أدى إلى التصميم المتجانس الذي يلغي الحاجة إلى المكالمات بين العقود. تم ضمان الأمن من خلال الاختبارات الصارمة والتدقيق. تم توزيع المنطق فقط عبر وحدات مختلفة، حيث كان بمثابة تنفيذ لعقد التخزين، والذي كان بمثابة عقد وكيل في المقام الأول.

يدعم هذا التصميم الموحد أيضًا الترقيات السهلة. يمكن استبدال الوحدات بسرعة لتعديل الميزات أو تقديمها إذا لم تكن هناك حاجة لتغييرات التخزين.

تم اختراق Euler بعد خمسة عشر شهرًا من إصداره وستة أشهر بعد أن أدخلت الترقية الثغرة الأمنية المستغلة.

لا أعتقد أن البنية المتجانسة لعبت دورًا في استنزاف الأصول؛ بل كانت الرقابة غير كافية على تحديثات التعليمات البرمجية.

الاستنتاج

تم إنجاز العمل الشاق، دعونا نراجع ما تعلمناه

وقد أظهرت تطبيقات إيثريوم المبكرة مثل MakerDAO وCompound وAave إمكانات الاقتراض المفرط في الضمانات على إيثريوم. بمجرد أن أثبتت أدلة المفهوم هذه نجاحها، تحول التركيز إلى تقديم مزيج من الميزات الجديدة للحصول على حصة في السوق. قدمت الإصدارات اللاحقة من Compound and Aave زراعة المحاصيل وقابلية التركيب والسيولة المجمعة، والتي ازدهرت بشكل خاص خلال ظروف السوق الصاعدة.

كان التطور المهم هو إدخال Compound v2 لمراكز الإقراض الرمزية، مما مكّن من الاعتراف بهذه المراكز كأصول قياسية من خلال تطبيقات أخرى. اتخذت كل من Aave v2 و Euler خطوة إلى الأمام من خلال تنفيذ مراكز الديون الرمزية، والتي تظل فائدتها الأوسع موضوعًا للنقاش.

ظهرت تكاليف الغاز المرتفعة كمصدر قلق كبير خلال السوق الصاعدة، مما أدى إلى تعديلات تجربة المستخدم كما هو موضح في Yield v2 و Aave v2 و Euler. ساعدت عقود أجهزة التوجيه والتطبيقات المتجانسة على تقليل التكاليف التي يتكبدها المستخدمون للمعاملات. ومع ذلك، جاء ذلك على حساب التعليمات البرمجية الأكثر تعقيدًا، وبالتالي الأكثر خطورة.

يبدو أن المركب v3 يشكل سابقة، حيث يعطي الأولوية للسلامة على الكفاءة المالية. إنه ينحرف عن نموذج مجمع السيولة التقليدي لتوفير حماية أفضل ضد الاختراقات المحتملة. من المرجح أن يؤدي ظهور شبكات L2، حيث أصبحت تكاليف الغاز ضئيلة بشكل متزايد، إلى تشكيل تصميم تطبيقات الاقتراض المضمونة المستقبلية.

في هذه المقالة، قدمت نظرة عامة شاملة على تطبيقات الاقتراض المضمونة الرئيسية على إيثريوم. يمكن أيضًا تطبيق النهج الذي استخدمته لتحليل كل تطبيق لفهم تعقيدات تطبيقات الاقتراض المضمونة الأخرى بسرعة.

عند تطوير تطبيق اقتراض بلوكتشين، ضع في اعتبارك دائمًا تخزين الأصول، ووضع السجلات المحاسبية، وطرق تقييم المخاطر والضمانات. أثناء العمل على هذه الاعتبارات، يمكنك الاعتماد على تاريخ التطبيقات السابقة والرؤى من هذه النظرة العامة لاتخاذ قراراتك.

شكرا لك على القراءة، ونتمنى لك التوفيق.

شكرًا لـ Calnix لمراجعة وتحرير هذه المقالة.

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [hackernoon]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [alcueca]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. يقوم فريق Gate Learn بترجمة المقالة إلى لغات أخرى. ما لم يُذكر، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.