الجميع يتحدث عن مجرد تجريد الحساب (AA) وإمكاناته في ثورة تجربة المستخدم في مجال سلسلة الكتل. ومع ذلك، التفاهم الرئيسي بشأن AA هو أنه يتجاوز مجرد تجريد رسوم الغاز أو تمكين المعاملات الدفعية. كيف؟ من خلال أنظمة إدارة المفاتيح القابلة للبرمجة.

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

التحرك بعيدا عن 12 كلمة

تحب صناعتنا الكلمات الشائعة، و "خالٍ من البذور" هو واحد من أحدثها للفت الانتباه. بينما نتفق جميعًا على أن توقع المستخدمين بتخزين مفاتيحهم الخاصة بشكل آمن غير عملي وأدى إلى فقدان ملايين الدولارات، فإن السؤال يبقى: إذا لم نظهر للمستخدمين عبارات البذور، فأين نخزن المفاتيح؟

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

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

إذا كنت تريد معرفة المزيد حول كيفية فتح AA الطريق للحسابات القابلة للبرمجة وتدوير المفاتيح ، فيمكنك ذلكتحقق من مقالتي.

1. حسابات قابلة للبرمجة بالكامل: تجريد الحساب

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

مع AA، يتم تخزين الأموال في العقود الذكية، ويتم تحديد ملكية الحساب بواسطة هذه العقود الذكية. الحسابات المتوافقة مع EIP-4337 لها جزأين في معاملاتها.

1. الجزء الأول هو التحقق، حيث يتم التحقق من ملكية الحساب على السلسلة الرئيسية.
2. الجزء الثاني هو التنفيذ، الذي ينفذ الرسالة.

يمكن برمجة الجزئين بالكامل؛ على سبيل المثال، يمكنك تعريف مفتاحين (i، ii)، ويمكن للمفتاح الأول (i) تنفيذ المعاملات الفورية، بينما يمكن للمفتاح الثاني (ii) تنفيذ المعاملات فقط بعد قفل زمني. يعني هذا أننا يمكننا تحديد قوة المفاتيح، وإضافة قفل زمني، أو تمكين شروط أخرى لتنفيذ معاملة.

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

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

مزايا وعيوب أنظمة إدارة المفاتيح المختلفة

سألخص بسرعة مفاتيح العبور (الحاويات الآمنة للمستهلكين) ، وحلول MPC القائمة على المجموعات ، وحلول TEE القائمة على السحابة ، والحلول الودائعية ، والكلمات التقليدية 12 كلمة ومفاتيح الجلسة. بعد ذلك ، سأشرح أفضل التركيبات.

1. الكلمات التقليدية المكونة من 12 كلمة - (secp256k1) -

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

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

ومع ذلك، هناك بعض العيوب:

1. من الصعب تعليم المستخدمين كيفية تخزين مفاتيحهم بشكل آمن في حال فقدان أجهزتهم.
2. يمكن لبرامج التجسس أو البرامج الضارة سرقة المفتاح الخاص من أجهزة المستخدمين نظرًا لأنه يتم تخزينه في التخزين المشترك.

لا يدعم NIST منحنى secp256k1، مما يعني أنه غير مدعوم بشكل شائع من قبل الأطر الشهيرة ومعظم الأجهزة.

2. تمريرات المفاتيح الخاصة (المخازن الآمنة للعملاء)

تقريبًا جميع الأجهزة الحديثة تحتوي على عنصرين أساسيين: نظام تشغيل (مع التخزين المشترك المرتبط) ومخبأ آمن. يتولى نظام التشغيل معظم العمليات باستثناء المهام الحساسة مثل حماية البيانات البيومترية والمفاتيح التشفيرية والتشفير وفتح الجهاز.

أنشأ المطورون شريحة دقيقة مخصصة تسمى Secure Enclave لإدارة هذه العمليات الحساسة بشكل منفصل. يعمل Secure Enclave بشكل مشابه لمحفظة الأجهزة. فهو يعمل بشكل مستقل، معالجة البيانات الحساسة بشكل آمن، ولا يمكن لمالك الجهاز حتى الوصول إلى محتوياته. لحسن الحظ، يدعم Secure Enclave العمليات الكريبتوغرافية، مثل إنشاء المفاتيح الخاصة وتوقيع الرسائل بها. للأسف، لا يدعم Secure Enclave المنحنى الذي يدعمه Ethereum (secp256k1)، بل يدعم المنحنى p256. لتمكين التحقق الأساسي P256، نحن (@getclave"">فريق @getclave)قدم الاقتراحRIP-7212وتدعم الآن تقريبًا جميع الرول أب الكبيرة ذلك.

وأفضل جزء عن Secure Enclaves هو أنه يمكننا إنشاء مفتاح خاص داخل Secure Enclaves باستخدام مصادقة البيومترية فقط مما يتيح تجربة التسجيل بنقرة واحدة مع أفضل أمان متاح على الأجهزة الحديثة - مستوى الأجهزة. ولكن لديها أيضًا بعض العيوب:

• التحقق من P256 دون RIP-7212 مكلف ويزيد من مخاطر الخطأ.
• نظرًا لعدم إمكانية استخراج المفتاح ، فإن القدرة على الاسترداد هي ميزة مفقودة هنا (تمكن مفاتيح الوصول من الاسترداد المحدود ولكنها غير كافية)
• إذا توقف نطاق ويب مفتاح المرور أو تطبيق Secure Enclave (SE) عن العمل، فلا يمكن للمستخدمين الوصول إلى المفتاح الخاص لأن Secure Enclave مصمم ليكون معزولًا ومستقلاً. بدون التطبيق أو نطاق الويب المرتبط، لا يوجد طريقة لاسترداد أو التفاعل مع المفتاح الخاص، مما يترك المستخدمين غير قادرين على القيام بالعمليات التشفيرية الضرورية. - سأشرح كيفية حل هذه المشكلة.

3. حلول إدارة المفاتيح القائمة على SSS

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

لنلق نظرة على المكان الذي يتم فيه تخزين المفاتيح وكيفية بلوغ النصاب للوصول إلى المفتاح الخاص. يستخدم معظم البروتوكولات الحالية ثلاثة حصص للمفتاح: يتم تخزين حصة واحدة على جهاز المستخدم، وتُحتفظ حصة واحدة على خادمهم (أو ضمن شبكة MPC)، وتُحجز حصة واحدة كنسخة احتياطية. تستخدم بعض التطبيقات، مثل Google Drive، حلول تخزين السحابة لتخزين هذه الحصص.

لذا، يفوض المستخدمون التحكم في محفظتهم إلى أطراف أخرى بنسبة. MPC (الحساب المتعدد الأطراف) قوي لتفويض مسؤوليات إدارة المفاتيح إلى أطراف مختلفة، ولكن لديه أيضًا بعض العيوب:

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

عيب رئيسي آخر لـSSS هو أنه يعيد بناء المفتاح الخاص، عادة في المتصفح. إنه خطر أمني كبير أن يكون المفتاح النصي متاحًا على جانب العميل. TSS لا يعيد بناء المفتاح ويستخدم MPC لتوحيد التوقيع عبر حصص المفتاح.

4. حلول TEE القائمة على السحابة

لا أعتقد أن بيئات التنفيذ الموثوقة القائمة على السحابة (TEEs) وحلول SSS مختلفة كثيرًا، ولكنني لا زلت أرغب في شرح كيفية عملها. تعمل بيئات التنفيذ الموثوقة بالضبط كما تم ترميزها؛ فهي لا تتغير (على الأقل يُزعم ذلك)، ولا تظهر TEEs ما بداخلها حتى لصاحب TEE. تم تصميمها للعمل بنزاهة - فعل الشيء الصحيح حتى لو لم يكن هناك أحد يراقب. لذا، لا تتعرض المفاتيح أبدًا للعميل بمجرد أن تقوم بيئات التنفيذ الموثوقة بعملها بشكل صحيح.

من خلال استخدام TEEs ، يمكننا بناء طبقات إدارة المفاتيح حيث يمكن للمطورين استخدام طرق مصادقة مختلفة ، ويمكن لـ TEE التحقق منها. بعد التحقق ، يقوم TEE بتوقيع رسالة بالمفتاح الخاص المرتبط بالمستخدم والتحقق منها على السلسلة.

تم تخزين المفتاح الخاص الرئيسي الذي يتحكم في أموال المستخدمين داخل TEE ولا يمكن استخراجه. هذا يهدد اللامركزية لأنه إذا قررت الخدمة إغلاقها أو رقابة المستخدمين ، فلا يمكن لبنّاء dApp فعل أي شيء.

تبدو تقنيات الحماية الأمنية القائمة على السحابة واعدة في النظرية ، ولكن في الماضي ، رأينا ثغرات مثلsgx.failفي TEEs السحابية. ومع ذلك، الميزة في TEEs هي أنه حتى إذا كان هناك باب خلفي أو ثغرة، فإن المهاجم سيحتاج إلى الوصول الفعلي إلى TEE، وهذا هو السبب في أن الأجهزة الاستهلاكية (الحجرة الآمنة - مفاتيح المرور) قوية جدًا لأن الأجهزة الاستهلاكية تخزن المفتاح داخل الحجرة الآمنة للمستخدمين ويمكن للمالك فقط الوصول إلى المفتاح، بينما يخزن TEE السحابية المفاتيح داخل سحابة وهذا يجعلها عرضة للهجمات.

ليس ملجأك الآمن، وليست عملاتك.

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

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

مفاتيح الجلسة: طريقة جديدة للصلاحيات المحدودة

لقد تحدثنا عن المفاتيح الدائمة. ماذا لو يمكننا إنشاء مفتاح زمني له وصول محدود إلى الأصول ويختفي بعد وقت يحدده المستخدم؟ يتيح لنا مفتاح الجلسة القيام بذلك:

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

كما في عالم Web3، نحدد مفاتيح الجلسة كإطار يمكن أن يغير بشكل محتمل كيفية تفاعل المستخدمين مع تطبيقات الويب اللامركزية. هدف مفاتيح الجلسة هو السماح للمستخدمين بتعيين موافقات مسبقة لوقت محدد في مجموعة متنوعة من السيناريوهات وإجراء المعاملات بدون توقيع. ولكن كيف يعمل ذلك؟

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

أفضل توافقات لإدارة المصادقة والمفاتيح لحالات الاستخدام المختلفة

لقد شرحت أنظمة إدارة المفاتيح المختلفة ومزاياها وعيوبها. بفضل قوة AA ، يمكننا دمج هذه الأنظمة مع إنشاء هياكل قوية مع حد أدنى من التنازلات. دعونا نشرحها C.1) مفتاح المرور + الاسترداد بالتأمين الزمني - كلافي - تطبيق تكنولوجيا المال الذي يخزن الأموال القيمة.

أساليب المصادقة القائمة على Secure Enclave (passkeys) توفر أمان على مستوى الأجهزة؛ ومع ذلك، فإن قدرتها على الاسترداد غالبًا ما تكون غير كافية لمعظم المستخدمين. لحسن الحظ، يسمح AA للمطورين بدمج طرق التوقيع المختلفة واستخدامها في حساب واحد. من خلال إضافة موقع استرداد إلى حساب ذكي، يمكننا حل مشكلة القدرة على الاسترداد التي تواجهها passkeys.

هناك عدة خيارات للاستعادة مثل الاستعادة الاجتماعية والاستعادة العالمية (استعادة بناءً على البريد الإلكتروني ZK) واستعادة بناءً على MPC. ومع ذلك، في رأيي، بالنسبة لتطبيقات التكنولوجيا المالية التي تم تصميمها لتكون محافظة ذاتية بالكامل، تحل الاستعادة الاجتماعية معظم المشاكل. في كلافيه، قمنا ببناء وحدة استعادة اجتماعية ونعمل على الاستعادة العالمية.

تقوم هذه الطريقة بتحقيق أقصى قدر من الأمان، وهو أمر رائع لتطبيقات الأمور المالية. لكن لديها عيب مهم: يتطلب التطبيق المصادقة البيومترية لكل عملية يرغب المستخدم في القيام بها. تخيل أنك ترغب في مشاركة محتوى في تطبيق وسائل التواصل الاجتماعي ويظهر لك تطبيق شاشة تسجيل بيومترية... فظيع صحيح؟

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

1. مفتاح المرور + الاسترداد مع قفل الوقت + مفاتيح الجلسة - تطبيق اجتماعي محمول

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

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

مفاتيح الجلسة هي بديل أفضل لذلك. يمكن للمستخدمين التحقق من مدة صلاحية الجلسة والأصول التي يمكن للجلسة الوصول إليها، مما يقلل من الحاجة إلى الثقة في التطبيق اللامركزي. بعد انتهاء وقت الجلسة، لا يحتاج المستخدمون إلى القلق بشأن الموافقات = لا مزيد من الحاجةrevoke.cashمثل التطبيقات :)

2. الوقَّع القائم على MPC أو السحابة TEE + الوقَّع الذاتي للهروب.

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

هناك بالفعل العديد من التطبيقات التي تستخدم هذه الهندسة المعمارية لإدارة المفاتيح.

3. 12 كلمة + جهاز توقيع هاردوير لتعزيز الأمان - تجربة متصفح DeFi الممتدة

مستخدمو DeFi يحبون تجربة التمديد في المتصفح، وتغيير سلوك المستخدم هو واحد من أصعب الأشياء في العالم الحديثة. لذا، لماذا لا نبني بديلاً أفضل؟ يمكن أيضًا حل مشكلة تسرب المفاتيح الخاصة عند دمج جهاز التوقيع الأمني (Secure Enclave أو Passkey Signer) مع عبارات البذور المؤلفة من 12 كلمة يمكن الوصول إليها عبر تمديد. تعمل عدة فرق في صناعة AA على تمكين هذا (على سبيل المثال. @myBraavos)

الحسابات الذكية ليست ذكية بما فيه الكفاية

تخيل أنك مستخدم قد قمت بتوليد EOA لأول مرة مع @MetaMaskثم اكتشف بديلاً مثل Zerion. أنت تقرر استخدام@zerion, وكل ما عليك فعله هو استيراد عبارة البذرة الخاصة بك - بسيط. الآن، تخيل محاولة القيام بالشيء نفسه على Starknet، حيث أن جميع المحافظ هي حسابات ذكية. لا يمكنك، لأن Braavos و Argent ليست متوافقة. هذه المشكلة موجودة أيضًا في بيئة EIP-4337 و @zkSyncAA الأصلية لـ ’.

نحن بحاجة إلى معايير (وليس حراس البوابة) أو على الأقل وسيلة أفضل لتمويل المحافظ الجديدة. وإلا، فلن يحدث اعتماد واسع للمحافظ الذكية، وسيظل اللاعبون الحاليون هم صانعو القرار، مما يحكم ممارسات الصناعة حتى لو لم تكن صحيحة.

وبالإضافة إلى ذلك، يجب أن يكون "الانسحاب الغاضب" ميزة افتراضية، حيث يمكن إيقاف معظم الجهات المركزية في جميع أنظمة إدارة المفاتيح. يجب أن يكون من الأسهل على المستخدمين تغيير الحاملين أو التبديل بين العقود الذكية، ويجب أن يكون الاستضافة الذاتية الخيار الافتراضي للمستخدمين. هناك معياران لحساب ذكي متعدد الوحدات: ERC-6900 و ERC-7579. كلاهما يحاولان تحقيق هدف مماثل - جعل الحسابات الذكية أكثر ذكاءً.

شكر خاص ل Derek ,كونراد، ونوامللملاحظات والتعليقات!

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

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