هندسة التطبيقات اللامركزية: أنماط الخلفية والأمان والتصميم

تتطلب التطبيقات اللامركزية ، أو ÐApps ، تصميم نظام خاص لتحقيق درجة عالية من الأمان والموثوقية. سأغطي في هذه المقالة العديد من المبادئ الرئيسية حول كيفية تصميم وتنفيذ العقود الخلفية والعقود الذكية للتطبيقات اللامركزية بشكل صحيح ، مع الأخذ Ethereum كمثال أساسي ، على الرغم من أن الكثير من ذلك ينطبق على EOS و Tron وغيرها من منصات البيانات اللامركزية.

أبرز المقالات:

  • كيفية تخزين المفاتيح الخاصة في النهاية الخلفية دون مخاوف أمنية
  • كيف تصمم العقود الذكية بشكل صحيح وماذا "لا مركزية"
  • أمثلة هندسة التطبيقات اللامركزية وشبه المركزية
  • كيفية التعامل مع الاشياء ذات المستوى المنخفض مثل تحميل الشبكة والفشل

ستكون كبيرة ، دعونا نفعل ذلك!

البرامج اللامركزية و Blockchain

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

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

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

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

التطبيقات اللامركزية

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

إذا طلب مني شخص ما أن أرسم كيفية عمل DApps اليوم ، فربما كنت سأرسم هذا

لتخيل ما نسميه التطبيقات اللامركزية اليوم ، خذ أي مورد ويب مركزي موجود مثل _YouTube_ أو _Instagram_ كمثال وتخيل أنه بدلاً من حساب مركزي محمي بكلمة مرور ، يكون لديك "هوية تشفير" مرتبطة بمورد الويب / الجوال.

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

اليوم ، أصبحت القدرات الحاسوبية والتخزينية للشبكات اللامركزية التي تتحمل الأخطاء مثل Ethereum أو EOS أو Tron محدودة. إذا كانت قابلة للتطوير ، فيمكننا استخدام الشبكات اللامركزية لتخزين التطبيق اللامركزي بأكمله ، بما في ذلك واجهة المستخدم الرسومية والبيانات ومنطق العمل. في هذه الحالة ، فإننا نسمي هذه التطبيقات حقًا لامركزية / موزعة.

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

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

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

(دي) المركزية والرموز

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

بينما تحدد العقود الذكية المميزة كيفية قيام المستخدمين بنقل الرموز المميزة ، يمكن للعقود الذكية للتطبيق تمديد كل شيء مفقود في العقود الذكية المميزة. يعمل كلا العقدين الأذكياء على رأس الشبكات اللامركزية

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

هناك العديد من الأمثلة للتطبيقات التي يتم إنشاؤها حول الرموز: من العديد من الألعاب القابلة للتحصيل مثل CryptoKitties (الرموز المميزة لـ ERC721) إلى تطبيقات أكثر توجهاً نحو الخدمة مثل LOOM Network أو حتى المتصفحات مثل Brave ومنصات الألعاب مثل DreamTeam (الرموز المميزة المتوافقة مع ERC20).

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

النهاية الخلفية للشبكات اللامركزية

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

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

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

  1. الاستماع إلى أحداث الشبكة (مثل عمليات النقل الرمزية) / قراءة حالة الشبكة.
  2. نشر المعاملات (استدعاء وظائف العقد الذكية المتغيرة للدولة مثل نقل الرمز المميز).

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

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

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

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

مراقبة النهاية الخلفية للإيثيروم. توضح الشاشة الأنشطة المتعلقة بشكل أساسي بميزة الفوترة المتكررة (على الرغم من أنه يمكنك رؤية القمم تحدث كل ساعة).

هندسة التطبيقات اللامركزية

يعتمد هذا الجزء من المقالة اعتمادًا كبيرًا على احتياجات تطبيق لامركزي معين ، لكننا سنحاول فرز بعض أنماط التفاعل الأساسية التي صُممت عليها هذه التطبيقات (ÐPlatform = Platform اللامركزية = Ethereum / EOS / Tron / Whatever):

برنامج العميل: التطبيقات اللامركزية بالكامل.

يتحدث العميل (المتصفح أو تطبيق الهاتف المحمول) إلى النظام الأساسي اللامركزي مباشرةً بمساعدة برنامج Ethereum "wallet" مثل Metamask أو Trust أو محافظ الأجهزة مثل Trezor أو Ledger. ومن أمثلة تطبيقات DApps التي يتم إنشاؤها بهذه الطريقة CryptoKitties ، و Loom’s Delegated Call ، ومحافظ التشفير نفسها (Metamask ، و Trust ، و Tron Wallet ، وغيرها) ، وعمليات تبادل التشفير اللامركزي مثل Etherdelta وما إلى ذلك.

lPlatform ⬌ Client ⬌ Back End ⬌Platform: تطبيقات مركزية أو شبه مركزية.

تفاعل العميل مع النظام الأساسي اللامركزي والخادم لديه القليل من القواسم المشتركة. مثال جيد على ذلك هو أي تبادل تشفير (مركزي) اليوم ، مثل BitFinex أو Poloniex: يتم ببساطة تسجيل العملات التي تتاجر بها في البورصات في قاعدة البيانات التقليدية. يمكنك "زيادة" رصيد قاعدة البيانات الخاصة بك عن طريق إرسال الأصول إلى عنوان محدد (lPlatform ⬌ Client) ثم سحب الأصول بعد بعض الإجراءات في التطبيق (Back End ⬌Platform) ، ومع ذلك ، كل ما تفعله من حيث "ÐApp" نفسه (عميل ⬌ Back End) لا يعني تفاعلك المباشر مع lPlatform.

مثال آخر هو Etherscan.io ، الذي يستخدم منهجية شبه مركزية: يمكنك القيام بجميع الإجراءات اللامركزية المفيدة هناك ، لكن التطبيق نفسه لا معنى له دون أن تكون النهاية الخلفية شاملة له (تقوم Etherscan بمزامنة المعاملات باستمرار ، وتحليل البيانات وتخزينها ، في نهاية المطاف توفير API / واجهة مستخدم شاملة).

هناك شيء ما بين: التطبيقات الثابتة أو المركزية أو شبه المركزية.

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

نأمل أن لا يثير نمط التفاعل بين التطبيقات اللامركزية بالكامل (Client ⬌ ÐPlatform) أي أسئلة. من خلال الاعتماد على مثل هذه الخدمات المدهشة مثل Infura أو Trongrid ، يمكن للمرء ببساطة إنشاء تطبيق لا يتطلب خادمًا على الإطلاق. يمكن لجميع مكتبات العميل تقريبًا مثل Ethers.js لـ Ethereum أو Tron-Web for Tron الاتصال بهذه الخدمات العامة والتواصل مع الشبكة. ومع ذلك ، للحصول على استفسارات ومهام أكثر تعقيدًا ، فقد تحتاج إلى تخصيص الخادم الخاص بك على أي حال.

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

مثال على تدفق ردود فعل الخادم على تصرف المستخدم في الشبكة اللامركزية

من وجهة النظر الخلفية ، إليك ما يحدث:

  1. نستمع إلى حدث شبكة معين عن طريق الاقتراع المستمر للشبكة.
  2. بمجرد أن نحصل على حدث ، نقوم بتنفيذ بعض منطق الأعمال ثم نقرر نشر معاملة استجابة لذلك.
  3. قبل نشر المعاملة ، نريد التأكد من أنه سيتم استخراجها على الأرجح (في Ethereum ، يعني تقدير الغاز الناجح للمعاملة أنه لا توجد أخطاء ضد حالة الشبكة الحالية). ومع ذلك ، لا يمكننا أن نضمن أن المعاملة سيتم بنجاح.
  4. باستخدام مفتاح خاص ، نقوم بتسجيل المعاملة ونشرها. في Ethereum ، يتعين علينا أيضًا تحديد سعر الغاز وحد الغاز للمعاملة.
  5. بعد نشر المعاملة ، نقوم باستمرار باستطلاع الشبكة لمعرفة حالتها.
  6. إذا استغرق الأمر وقتًا طويلاً ولم نتمكن من الحصول على حالة المعاملة ، يتعين علينا إعادة نشرها أو تشغيل "سيناريو فشل". يمكن أن تفقد المعاملات لأسباب متعددة: ازدحام الشبكة ، إسقاط الأقران ، زيادة حمل الشبكة ، إلخ.
  7. بعد أن نتخلص من معاملاتنا أخيرًا ، يمكننا تنفيذ منطق عمل أكثر إذا لزم الأمر. على سبيل المثال ، يمكننا إخطار خدمات النهاية الخلفية بحقيقة اكتمال المعاملة. أيضًا ، فكر في انتظار بضع تأكيدات قبل اتخاذ القرارات النهائية بشأن المعاملة: يتم توزيع الشبكة وبالتالي يمكن أن تتغير النتيجة في غضون ثوانٍ.

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

التطبيقات اللامركزية

أود هنا تسليط الضوء على بعض النقاط التي تثير معظم الأسئلة ، وهي:

  • الاستماع إلى أحداث الشبكة وقراءة البيانات من الشبكة
  • نشر المعاملات وكيفية القيام بذلك بشكل آمن

الاستماع إلى أحداث الشبكة

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

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

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

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

موثوق تسليم أحداث Ethereum لجميع الخدمات الخلفية

تعمل هذه المكونات بالطريقة التالية:

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

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

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

نشر المعاملات

هناك بضع خطوات يتعين علينا تنفيذها من أجل نشر معاملة على الشبكة اللامركزية:

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

من خلال استخدام الأساليب المذكورة أعلاه ، يمكنك في نهاية المطاف بناء شيء مشابه للشيء الوارد في الرسم البياني التسلسلي أدناه. في هذا المخطط التسلسلي المحدد ، أوضح (بشكل عام!) كيفية عمل الفوترة المتكررة لـ blockchain (يوجد المزيد في مقالة مرتبطة):

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

النهاية الخلفية الأمن والعقود الذكية

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

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

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

بهذه الطريقة ، في حالة الطوارئ:

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

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

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

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