🕺🏾 👨🏽‍🤝‍👨🏼 🏂🏼 سلسلة النقدية البلازما كحل لمشكلة قابلية التوسع لـ blockchain 💸 👩🏼‍⚕️ 👩🏻‍🔬

مساء الخير أيها القراء الأعزاء!

تتناول هذه المقالة السلسلة النقدية للبلازما وتلقي الضوء على الموضوعات التالية:

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

استخدمت الفرصة لغة برمجة Javascript لتنفيذ السلسلة الفرعية ، وكذلك Solidity لسلسلة الجذر. يتم توفير أمثلة التعليمات البرمجية بهذه اللغات.

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

العقود الذكية تجلب منطق الأعمال إلى الشبكات اللامركزية. يتيح لك ذلك إنشاء تطبيقات DAPP جديدة.

لا يمكن تنفيذ العقود الذكية والتشغيل السريع للتطبيقات مع قاعدة بيانات موزعة إلا إذا تم استيفاء شرط قابلية التوسع.

السلاسل اللامركزية الحديثة لها عيوب عديدة. الشيء الرئيسي هو قابلية التوسع. يعالج Ethereum حوالي 20 tx / s. هذا لا يكفي في الواقع المالي الحديث. في الوقت نفسه ، تتمتع Ethereum بأعلى درجة ممكنة من الحماية ضد القرصنة وانهيار الشبكات. العملات والنظم المشفرة الأخرى المبنية على blockchain لا تتمتع بدرجة عالية من اللامركزية ، مما يقلل من الثقة في الشبكة.

ثلاثية التدرجية

هناك ثلاثية قابلية للتوسع في blockchain تتضمن ثلاثة مكونات:

اللامركزية؛
الأمن؛
التدرجية.

اللامركزية في المأزق

اللامركزية ، كما يوحي المصطلح ، تعكس درجة تنوع ملكية النشاط في blockchain ، وكذلك درجة تنويع إنشاء الكتل وإنشاء إدخالات دفتر الأستاذ جديدة.

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

في الشبكات اللامركزية بالكامل ، يمكن لكل مستخدم المشاركة في بناء الشبكة.

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

السلامة في المأزق

إنها تتعلق بقدرة blockchain على مقاومة الهجمات من المصادر الخارجية والحفاظ على النظام في حالة غير متغيرة. تخضع معظم القيود إلى العديد من التهديدات الأمنية المحتملة. لا بد من معرفة أكثر نواقل الهجوم وخيارات الدفاع الأكثر شيوعًا.

في هذه الحالة ، تسير اللامركزية والأمن جنبا إلى جنب. كلما زاد العقد ، كلما كانت الشبكة تعتمد على الجانب المركزي ، وبالتالي ، خطر وجود نقطة فشل مركزية. ومع ذلك ، هناك العديد من متجهات الهجوم الأخرى التي تشكل تهديدًا للشبكات اللامركزية ، بما في ذلك:
> هجوم 50٪ - كائن يمتلك أكثر من 50٪ من إجمالي عدد الرموز المميزة غير المدفوعة التي تمتلك الشبكة بالفعل ؛
> Sybil Attack - يمكن للمستخدم إنشاء العديد من المعرفات في النظام للتحكم بشكل فعال في مشاركة كبيرة في ملكية و / أو صنع القرار على الشبكة ؛
> DDoS - يحدث هجوم رفض الخدمة الموزع (DDoS) عندما يكون هناك نية لتعطيل حركة المرور على الشبكة ، وملء الشبكة بالمعاملات الضارة ؛
> هجوم التواطؤ - يقرر واحد أو عدة كائنات (أو عقد) التوحيد لإجراء أي عملية ضارة على الشبكة.

قابلية التوسع في المأزق

تعد درجة قابلية التوسع مهمة لأنها تحدد الإنتاجية القصوى ، أي الحد الأعلى لحجم الشبكة. والسؤال الأكثر أهمية الذي يجب طرحه عند تقييم الشبكة هو: "كم عدد المستخدمين الذين يمكن لهذا النظام تحمله؟" تمتلك Bitcoin حاليًا ما بين 2.9 و 5.8 مليون حامل محفظة. EOS لديها عدة آلاف من الأعضاء.

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

"الكأس المقدسة" في تكنولوجيا blockchain

بحكم التعريف ، يحتوي blockchain فقط على اثنين من الخصائص الثلاثة التالية:

اللامركزية (كل مشارك لديه حق الوصول فقط إلى موارد O © ، أي إلى كمبيوتر محمول عادي أو VPS صغير) ؛
قابلية التوسع (القدرة على معالجة المعاملات O (n)> O ©) ؛
الأمن (الحماية ضد المتسللين باستخدام موارد O (n)).

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

"الكأس المقدسة" في تكنولوجيا blockchain تعني الجمع بين الجوانب الثلاثة.
في معظم المشاريع الحالية التي تعمل باستخدام cryptocurrency ، يتم تحقيق خاصيتين أساسيتين: اللامركزية والأمن. قابلية يعاني.

حلول واعدة لمعضلة

إثبات المخاطر (PoS)

يوفر Proof of Stake (PoS) تحسينات قابلة للتوسعة. POS يستبدل التعدين cryptocurrency على أساس نظام إثبات العمل (PoW). اختيار المدقق سريع للغاية - بطريقة حتمية. في الوقت نفسه ، لا توجد تكلفة للطاقة وهي صديقة للبيئة.

Sidechains

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

عملية التجزئة

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

زيادة حجم الكتلة

Litecoin و Bitcoin Cash (BCH) هما "شوك" لسلسلة البيتكوين blockchain. Forking ينسخ أساسا blockchain واحد. بعد المتفرعة ، يمكنك إجراء تغييرات. زاد كل من LTC و BCH من حجم كل فدرة ، مما سمح بتخزين المزيد من المعاملات لكل فدرة ، وبالتالي زيادة سرعة معالجة المعاملات.

شبكة البرق

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

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

شبكة ريدن

بالنسبة إلى Ethereum ، فإن النظير الأكثر شهرة في Lightning هو شبكة Raiden.
هذا هو الحل للتحجيم خارج blockchain الرئيسي. وهو متوافق مع تحويل الرموز المميزة ERC-20 في قنوات الدفع ثنائية الاتجاه.

هيكلها الأساسي معقد ، لكن التفاعل مع Raiden يتطلب من المطورين التفاعل فقط مع API لإنشاء تطبيقات قابلة للتطوير على Raiden.

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

الحل الأمثل

ابتكر علماء الفكر البرق مفهوم جديد لسلسلة المفاتيح يحل مشاكل سرعة البلوك.

تطبق الفرصة عمليًا مفهوم Plasma and Plasma Cash.

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

وهذا هو ، يتم استخدام أمان جذر Ethereum لتحسين قابلية التوسع.

النقدية البلازما: خيار الفرصة

فرصة تستخدم تطبيق Plasma Cash في الإصدار الأول.

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

ميزات البلازما النقدية:

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

العيب:

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

هيكل المعاملات في فرصة النقدية البلازما

فرصة تستخدم Javascript لتنفيذ childchain. كل معاملة في الفرصة النقدية بلازما هي بنية مماثلة:

const transactionFields = [ {name: 'prevHash'}, {name: 'prevBlock', int: true, default: 0}, {name: 'tokenId', isDecimal: true}, {name: 'newOwner'}, {name: 'type'}, {name: 'signature'}, ]

العناصر الرئيسية هنا هي رابط للكتلة prevBlock السابقة (هناك حاجة للتنقل حول سلسلة الكتل) ، ومعرف الرمز المميز tokenId (يجب أن يكون فريدًا) ، وأيضًا newOwner آخر مالك الرمز المميز.

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

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

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

الكتلة هي كما يلي:

 const blockFields = [ {name: 'prevHash'}, {name: 'blockNum', isDecimal: true}, {name: 'transactions'}, {name: 'merkleRoot'}, {name: 'time'} ]

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

في سلسلة الجذر ، على مستوى العقد الذكي ، يبدو هذا (لغة الصلابة):

 /* * Block structure (represents one block in a chain) */ struct Block { uint block_num; bytes32 merkle_root; uint time; /* * Transaction structure (decoded from RLP form) */ struct Transaction { bytes32 prevhash; uint prev_block; uint token_id; address new_owner; }

يتم تنفيذ التشفير باستخدام تشفير / فك تشفير - وظائف RLP التسلسل / إلغاء التسلسل.

طرق لدخول البلازما النقدية

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

هنا هو التنفيذ في صلابة:

 function deposit() public payable { uint token_id = uint(keccak256(msg.sender, msg.value, deposit_blk)); // token.index = deposit_blk; tokens[token_id] = msg.value; deposit_blk += 1; emit DepositAdded(msg.sender, msg.value, token_id, current_blk); }

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

طرق الانسحاب إلى Plasma Cash

يمكن لكل شخص سحب الرمز المميز الخاص به من خلال توفير آخر معاملاتين في سجل ملكية الرمز المميز.

تنفيذ الخروج من سلسلة الجذر:

 function startExit(uint block_num, bytes tx1, bytes tx0, bytes proof1, bytes proof0) public returns (uint exit_id) { require(checkPatriciaProof(keccak256(tx1), childChain[block_num].merkle_root, proof1)); bytes32 prev_hash; uint prev_blk; uint token_id; address new_owner; (prev_hash, prev_blk, token_id, new_owner,) = getTransactionFromRLP(tx1); require(msg.sender == new_owner); require(tokens[token_id] > 0); bytes32 hashPrevTx = keccak256(tx0); require(checkPatriciaProof(hashPrevTx, childChain[prev_blk].merkle_root, proof0)); require(prev_hash == hashPrevTx); Exit storage record = exitRecords[token_id]; require(record.block_num == 0); record.block_num = block_num; record.new_owner = msg.sender; record.prev_block = prev_blk; if (childChain[block_num].time > block.timestamp - week) record.priority = childChain[block_num].time; else record.priority = block.timestamp - week; exits.add(record.priority); exit_ids[record.priority].push(token_id); emit ExitAdded(msg.sender, record.priority, token_id); return token_id; }

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

يمكن الطعن في الاستنتاج بثلاث طرق:

تقديم تأكيد للإنفاق على المعاملات:

 function challengeSpent(uint exit_id, uint blk_num, bytes tx1, bytes proof) public { require(checkPatriciaProof(keccak256(tx1), childChain[blk_num].merkle_root, proof)); Exit memory record = exitRecords[exit_id]; require(record.block_num > 0); uint prev_block; uint token_id; (, prev_block , token_id, ) = getTransactionFromRLP(tx1); require(tokens[token_id] > 0); require(prev_block == record.block_num && record.block_num < blk_num); require(token_id == exit_id); exit_ids[record.priority].remove(exit_id); delete exitRecords[exit_id]; emit ExitChallengedEvent(exit_id); }

إذا كانت هناك معاملة تنفق الرمز المميز المعروض بالفعل ، فسيتم إلغاء هذا السحب!

إثبات مصاريف المعاملة السابقة:

 /* * Challenge exit by providing * a proof of a transaction spending P(C) that appears before C */ function challengeDoubleSpend(uint exit_id, uint blk_num, bytes tx1, bytes proof) public { require(checkPatriciaProof(keccak256(tx1), childChain[blk_num].merkle_root, proof)); Exit memory record = exitRecords[exit_id]; require(record.block_num > 0); // bytes32 prev_hash; uint prev_block; uint token_id; (, prev_block , token_id, ) = getTransactionFromRLP(tx1); require(tokens[token_id] > 0); // check if token double spent require(prev_block == record.prev_block && blk_num < record.block_num); // require(token_id == exit_id); exit_ids[record.priority].remove(exit_id); delete exitRecords[exit_id]; emit ExitChallengedEvent(exit_id); }

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

توفير معاملة في محفوظات المعاملة من الرمز المميز قبله.

قد تكون هذه قصة خاطئة ، لذلك تحتاج إلى تأكيدها من خلال معاملة تابعة:

 // */ function challengeInvalidHistory(uint exit_id, uint blk_num, bytes tx0, bytes proof) public { // check if proof is valid require(checkPatriciaProof(keccak256(tx0), childChain[blk_num].merkle_root, proof)); Exit memory record = exitRecords[exit_id]; require(record.block_num > 0); bytes32 prev_hash; uint token_id; (prev_hash, , token_id, ) = getTransactionFromRLP(tx0); //require(exit_id == token_id); require(tokens[token_id] > 0); // transaction should be before exit tx in history require(blk_num < record.block_num - 1); challenged[exit_id] = blk_num; emit ChallengedInvalidHistory(exit_id, token_id); }

استدعاء البرنامج النصي الأول والثاني بحظر الإخراج على الفور.

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

 /* * Respond to invalid history challenge by providing * the direct child of C*, which must be either equal to or before P( C ) */ function respondChallenge(uint exit_id, uint blk_num, bytes childtx, bytes proof) public { require(challenged[exit_id] > 0); Exit memory record = exitRecords[exit_id]; require(record.block_num > 0); require(checkPatriciaProof(keccak256(childtx), childChain[blk_num].merkle_root, proof)); // get transaction from rlpencoded form bytes32 prev_hash; uint prev_block; uint token_id; (prev_hash, prev_block, token_id, ) = getTransactionFromRLP(childtx); // if direct child if (prev_block == challenged[exit_id] ) { if (blk_num <= record.prev_block && token_id == exit_id ) { delete challenged[exit_id]; emit ExitRespondedEvent(exit_id); } else { exit_ids[record.priority].remove(exit_id); delete exitRecords[exit_id]; emit ExitChallengedEvent(exit_id); } } }

وهذا هو ، إذا تم تلقي المعاملة التابعة الصحيحة ، يتم التنازع على الإخراج ويبقى في قائمة الانتظار!
بعد بناء جزء من بروتوكول الفرصة النقدية ، تم التوصل إلى النتيجة التالية:
يوفر هذا البروتوكول الأمان من خلال سلسلة جذر Ethereum.

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

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

على الرغم من بعض مشاكل توفر البيانات ، يوفر المشغل مستوى عالًا من الاستقرار في blockchain ويمكّن من إجراء معاملات تجارية دولية فعالة.

البلازما كاش يجلب زيادة كبيرة في قابلية التوسع. لذلك ، تستخدم "الفرصة" بلازما كجزء من بروتوكول PoE الخاص بها.

سلسلة النقدية البلازما كحل لمشكلة قابلية التوسع لـ blockchain