Chainlink: شبكة أوراكل اللامركزية

خلاصة

في هذا المستند التقني، نوضح رؤية لتطور Chainlink بما يتجاوز تصوره الأولي في المستند التقني Chainlink الأصلي. نحن نتوقع دور متزايد التوسع لشبكات oracle، وهو الدور الذي تكمل فيه وتعزز شبكات blockchain الحالية والجديدة من خلال توفير خدمات سريعة وموثوقة ومفيدة السرية - الحفاظ على الاتصال العالمي والحساب خارج السلسلة لـ smart contracts. أساس خطتنا هو ما نسميه شبكات أوراكل اللامركزية، أو DONs للاختصار. DON هي شبكة تتم صيانتها بواسطة لجنة مكونة من Chainlink العقد. وهو يدعم أي نطاق غير محدود من وظائف oracle المختارة النشر من قبل اللجنة. وبالتالي فإن DON بمثابة طبقة تجريد قوية، تقديم واجهات لـ smart contracts لموارد واسعة النطاق خارج السلسلة وبدرجة عالية موارد حوسبة فعالة وغير مركزية خارج السلسلة داخل DON نفسها. باستخدام DONs كنقطة انطلاق، تخطط Chainlink للتركيز على التقدم في سبعة المجالات الرئيسية: • smart contracts المختلط: تقديم إطار عام قوي لزيادة إمكانات smart contract الحالية من خلال الإنشاء الآمن على السلسلة وموارد الحوسبة خارج السلسلة إلى ما نسميه smart contracts الهجين. • التخلص من التعقيد: تقديم معلومات بسيطة للمطورين والمستخدمين تلغي الوظيفة الحاجة إلى الإلمام بالأساسيات المعقدة البروتوكولات وحدود النظام. • القياس: التأكد من أن خدمات oracle تحقق زمن الاستجابة والإنتاجية التي تتطلبها الأنظمة اللامركزية عالية الأداء. • السرية: تمكين أنظمة الجيل التالي التي تجمع بين blockchains' الشفافية الفطرية مع حماية قوية جديدة لسرية الأشخاص الحساسين data. • عدالة ترتيب المعاملات: دعم تسلسل المعاملات بطرق مختلفة التي تكون عادلة للمستخدمين النهائيين وتمنع الهجمات الأمامية والهجمات الأخرى الروبوتات وعمال المناجم الاستغلاليين. • تقليل الثقة: إنشاء طبقة دعم جديرة بالثقة للغاية smart contracts والأنظمة الأخرى التي تعتمد على oracle عن طريق اللامركزية، والتثبيت القوي في blockchains عالية الأمان، والتشفير التقنيات والضمانات الاقتصادية المشفرة. • الأمن القائم على الحوافز (الاقتصاد المشفر): التصميم الصارم والنشر القوي للآليات التي تضمن أن العقد في DON لديها حوافز اقتصادية قوية للتصرف بشكل موثوق وصحيح، حتى في مواجهة الخصوم ذوي الموارد الجيدة. نقدم ابتكارات أولية ومستمرة من قبل مجتمع Chainlink في كل من هذه المجالات، مما يوفر صورة للتوسع وبشكل متزايد الإمكانات القوية المخطط لها لشبكة Chainlink.

مقدمة

غالبًا ما يُنظر إلى Blockchain oracles اليوم على أنها خدمات لا مركزية ذات هدف واحد: لإعادة توجيه البيانات من الموارد خارج السلسلة إلى blockchains. إنها خطوة قصيرة، على أية حال، من إعادة توجيه البيانات إلى الحوسبة عليها أو تخزينها أو نقلها ثنائي الاتجاه. تبرر هذه الملاحظة فكرة أوسع بكثير عن وظائف oracles. كذلك أيضا تلبية متطلبات الخدمة المتزايدة لـ smart contracts والمتعددة الأوجه بشكل متزايد التقنيات التي تعتمد على شبكات oracle. باختصار، يمكن لـ oracle أن تفعل ذلك وسوف تحتاج إلى ذلك أن تكون واجهة ذات أغراض عامة وثنائية الاتجاه وممكّنة للحوسبة بين الأنظمة onchain والأنظمة خارج السلسلة. يتمثل دور Oracles في النظام البيئي blockchain في التحسين الأداء والوظائف وقابلية التشغيل التفاعلي لـ smart contracts حتى يتمكنوا من ذلك جلب نماذج ثقة جديدة وشفافية إلى العديد من الصناعات. سيأتي هذا التحول من خلال توسيع استخدام smart contracts الهجين، الذي يندمج خصائص blockchains الخاصة مع الإمكانات الفريدة للأنظمة خارج السلسلة مثل oracle الشبكات وبالتالي تحقيق وصول وقوة أكبر بكثير من الأنظمة الموجودة على السلسلة في عزلة. في هذا المستند التقني، نوضح رؤية لما نطلق عليه Chainlink 2.0، وهو تطور لـ Chainlink يتجاوز تصوره الأولي في Chainlink المستند التقني الأصلي [98]. نتوقع دورًا موسعًا بشكل متزايد لشبكات oracle، وهو دور فيه إنها تكمل وتعزز blockchains الحالية والجديدة من خلال توفير اتصال وحساب عالمي سريع وموثوق به ويحافظ على السرية للأنظمة الهجينة smart contracts. نحن نعتقد أن شبكات oracle سوف تتطور لتصبح أدوات مساعدة لتصدير بيانات عالية التكامل من فئة blockchain إلى أنظمة تتجاوز blockchain النظام البيئي. اليوم، Chainlink العقد التي تديرها مجموعة متنوعة من الكيانات تجتمع معًا في شبكات oracle لنقل البيانات إلى smart contract فيما يعرف بالتقارير. يمكننا أن نرى مثل هذا oracle العقد كلجنة مماثلة لتلك الموجودة في الإجماع الكلاسيكي blockchain [72]، ولكن بهدف دعم blockchains الموجودة، بدلاً من توفير وظائف قائمة بذاتها. مع وظائف عشوائية يمكن التحقق منها (VRF) وإعداد التقارير خارج السلسلة (OCR)، Chainlink يتطور بالفعل نحو إطار عمل وبنية تحتية للأغراض العامة لتوفير الموارد الحسابية التي تتطلبها smart contracts وظائف متقدمة. أساس خطتنا لـ Chainlink 2.0 هو ما نسميه أوراكل اللامركزية الشبكات، أو DONs للاختصار. منذ أن قدمنا مصطلح "شبكة oracle" في لقد طورت Chainlink الوثيقة البيضاء [98]، oracles وظائف ووظائف أكثر ثراءً من أي وقت مضى اتساع التطبيق. وفي هذه المقالة، نقدم تعريفًا جديدًا للمصطلح وفقًا لرؤيتنا المستقبلية للنظام البيئي Chainlink. في طريقة العرض هذه، DON عبارة عن شبكة تحتفظ بها لجنة مكونة من Chainlink العقد. متجذر في بروتوكول الإجماع، فإنه يدعم أيًا من مجموعة غير محدودة من وظائف oracle المختارة للنشر بواسطة اللجنة. وبالتالي فإن DON بمثابة طبقة تجريد blockchain، مما يوفر واجهات إلى الموارد خارج السلسلة لكل من smart contracts والأنظمة الأخرى. كما يوفر الوصول إلى موارد الحوسبة خارج السلسلة عالية الكفاءة ولكن لامركزية. بشكل عام، DON يدعم العمليات على السلسلة الرئيسية. هدفها هو تمكين آمنة ومرنةبلي هجين smart contracts، والذي يجمع بين العمليات الحسابية على السلسلة وخارج السلسلة مع الاتصال بالموارد الخارجية. نؤكد أنه حتى مع استخدام اللجان في DONs، فإن Chainlink نفسها يبقى بطبيعته غير مسموح به. DONs بمثابة أساس غير مسموح به إطار عمل يمكن أن تجتمع فيه العقد معًا لتنفيذ شبكات oracle المخصصة أنظمتهم الخاصة لإدراج العقدة، والتي قد تكون مسموحة أو غير مسموح بها. مع DONs كأساس، نخطط للتركيز في Chainlink 2.0 على التقدم في سبعة المجالات الرئيسية: smart contracts الهجين، وتجريد التعقيد، والتوسع، والسرية، وعدالة ترتيب المعاملات، وتقليل الثقة، والأمن القائم على الحوافز (الاقتصاد المشفر). في هذه المقدمة، نقدم لمحة عامة عن اللامركزية شبكات Oracle في القسم 1.1 ثم مجالات الابتكار السبعة الرئيسية لدينا في القسم 1.2. وصفنا تنظيم بقية هذه الورقة في القسم 1.3. 1.1 شبكات أوراكل اللامركزية تم تصميم شبكات أوراكل اللامركزية لتعزيز القدرات وتوسيعها من smart contracts على الهدف blockchain أو السلسلة الرئيسية من خلال الوظائف التي غير متوفر محليا. يفعلون ذلك من خلال توفير الموارد الأساسية الثلاثة الموجودة في أنظمة الحوسبة: الشبكات والتخزين والحساب. يهدف DON إلى العرض تتمتع هذه الموارد بخصائص قوية تتعلق بالسرية والنزاهة والتوافر،1 كما فضلا عن المساءلة. يتم تشكيل DONs من قبل لجان مكونة من oracle العقد التي تتعاون لتحقيق هدف محدد وظيفة أو اختيار إقامة علاقة طويلة الأمد من أجل تقديم خدمات مستمرة للعملاء. تم تصميم DONs بطريقة blockchain بطريقة ملحدة. يعدون بالعمل أداة قوية ومرنة لمطوري التطبيقات لإنشاء دعم خارج السلسلة لـ smart contracts الخاصة بهم على أي سلسلة رئيسية مدعومة. هناك نوعان من الوظائف يدركان قدرات DON: الملفات التنفيذية و محولات. الملفات التنفيذية هي برامج يتم تشغيلها بشكل مستمر وبطريقة لا مركزية على DON. على الرغم من أنها لا تقوم بتخزين أصول السلسلة الرئيسية بشكل مباشر، إلا أنها تتمتع بفوائد مهمة، بما في ذلك الأداء العالي والقدرة على أداء عمليات سرية حساب. تعمل الملفات التنفيذية بشكل مستقل على DON وتؤدي أداءً حتميًا العمليات. وهي تعمل جنبًا إلى جنب مع المحولات التي تربط DON بالموارد الخارجية ويمكن استدعاؤها بواسطة الملفات التنفيذية. المحولات، كما نتصورها لـ DONs، هي أ تعميم المحولات الخارجية في Chainlink اليوم. بينما المحولات الموجودة عادةً ما يتم جلب البيانات من مصادر البيانات فقط، وقد تعمل المحولات بشكل ثنائي الاتجاه؛ في DONs، يمكنهم أيضًا الاستفادة من الحساب المشترك بواسطة DON العقد لتحقيقه ميزات إضافية، مثل تشفير التقارير للاستهلاك الذي يحافظ على الخصوصية قابل للتنفيذ. لتوفير فكرة عن العملية الأساسية لـ DON، يوضح الشكل 1 من الناحية النظرية كيف يمكن لـ DON أن يمكن استخدام DON لإرسال التقارير إلى blockchain وبالتالي تحقيق وظيفة oracle التقليدية الموجودة. ومع ذلك، يمكن أن يوفر DONs العديد من الميزات الإضافية 1"ثالوث وكالة المخابرات المركزية" لأمن المعلومات [123، ص. 26، §2.3.5].شبكات Chainlink الحالية. على سبيل المثال، ضمن الهيكل العام للشكل 1، يمكن للملف القابل للتنفيذ تسجيل بيانات أسعار الأصول التي تم جلبها على DON، باستخدام هذه البيانات حساب، على سبيل المثال، متوسط زائدة لتقاريرها. الشكل 1: شكل مفاهيمي يوضح كمثال كيف يمكن لشبكة Oracle اللامركزية تحقيق وظائف oracle الأساسية، أي ترحيل البيانات خارج السلسلة إلى العقد. ان يستخدم الملف القابل للتنفيذ محولات لجلب البيانات خارج السلسلة، والتي يحسب عليها، ويرسل المخرجات عبر محول آخر إلى الهدف blockchain. (يتم بدء تشغيل المحولات بواسطة التعليمات البرمجية الموجودة في ملف DON، ممثلة بمربعات زرقاء صغيرة؛ تظهر الأسهم اتجاه تدفق البيانات لهذا الغرض مثال محدد.) يمكن للملف القابل للتنفيذ أيضًا القراءة والكتابة إلى DON المحلي تخزين للحفاظ على الحالة و/أو التواصل مع الملفات التنفيذية الأخرى. تتيح الشبكات المرنة والحسابات والتخزين في DONs، كلها ممثلة هنا، مجموعة كبيرة من الروايات التطبيقات. تتمثل إحدى المزايا الرئيسية لـ DONs في قدرتها على تشغيل خدمات blockchain الجديدة. DONs هي وسيلة يمكن من خلالها لشبكات oracle الحالية أن تدعم تطبيقات الخدمة بسرعة وهذا يتطلب اليوم إنشاء شبكات مصممة لهذا الغرض. نعطي عددا من أمثلة على هذه التطبيقات في القسم 4. في القسم 3، نقدم المزيد من التفاصيل حول DONs، مع وصف قدراتها في شروط الواجهة التي يقدمونها للمطورين والمستخدمين. 1.2 سبعة أهداف التصميم الرئيسية نحن هنا نراجع بإيجاز النقاط الرئيسية السبعة المذكورة أعلاه لتطور Chainlink، وهي:الهجين smart contracts: من الأمور المركزية في رؤيتنا لـ Chainlink هي فكرة الأمان الجمع بين المكونات الموجودة على السلسلة وخارجها في smart contracts. نشير إلى العقود تحقيق هذه الفكرة على أنها smart contracts هجينة أو عقود هجينة.2 بلوكتشين ستستمر في لعب دورين حاسمين في الخدمة اللامركزية الأنظمة البيئية: كلاهما المكان الذي يتم فيه تمثيل ملكية العملة المشفرة ومرتكزات قوية للخدمات اللامركزية. ولذلك يجب تمثيل العقود الذكية أو تنفيذها على السلسلة، ولكن قدراتها على السلسلة محدودة للغاية. بحتة رمز العقد على السلسلة بطيء ومكلف ومنعزل وغير قادر على الاستفادة من العالم الحقيقي البيانات ومجموعة متنوعة من الوظائف التي لا يمكن تحقيقها بطبيعتها على السلسلة، بما في ذلك الأشكال المختلفة للحساب السري، وتوليد العشوائية (الزائفة) الآمنة ضد التلاعب بعامل المنجم / validator وما إلى ذلك. لكي يحقق smart contracts إمكاناتهم الكاملة، يتطلب الأمر smart contracts سيتم تصميمه من جزأين: جزء متصل بالسلسلة (والذي نشير إليه عادةً بـ SC) وجزء خارج السلسلة، وهو ملف قابل للتنفيذ يعمل على DON (والذي نشير إليه عادةً بـ تنفيذي). الهدف هو تحقيق تكوين آمن للوظائف الموجودة على السلسلة باستخدام تعدد الخدمات خارج السلسلة التي تهدف DON إلى توفيرها. معا، الجزأين تكوين عقد هجين. نقدم الفكرة من الناحية المفاهيمية في الشكل 2. واليوم بالفعل، Chainlink خدمات 3 مثل خلاصات البيانات وVRFs لا يمكن تحقيقها بأي طريقة أخرى smart contract التطبيقات، التي تتراوح من DeFi إلى NFTs التي تم إنشاؤها بشكل عادل إلى التأمين اللامركزي، كخطوات أولى نحو إطار عمل أكثر عمومية. كخدمات Chainlink التوسع والنمو بشكل أكثر أداءً وفقًا لرؤيتنا الواردة في هذا المستند التقني، وكذلك الأمر بالنسبة لنا ستعمل قوة أنظمة smart contract عبر جميع blockchains. يمكن النظر إلى نقاط التركيز الرئيسية الستة الأخرى في هذا التقرير على أنها تعمل في الخدمة من الأول، وهو شامل للعقود الهجينة. تتضمن هذه التركيزات إزالة المرئية التعقيد من العقود المختلطة، مما يؤدي إلى إنشاء خدمات إضافية خارج السلسلة تمكن وبناء عقود هجينة أكثر قدرة من أي وقت مضى، وفي حالة تقليل الثقة، تعزيز الخصائص الأمنية التي تحققها العقود الهجينة. نترك الفكرة من العقود الهجينة الضمنية في جزء كبير من الورقة، ولكن أي مزيج من يمكن اعتبار منطق MAINCHAIN مع DON بمثابة عقد مختلط. تجريد التعقيد: تم تصميم DONs للاستفادة من اللامركزية أنظمة سهلة للمطورين والمستخدمين من خلال استخلاص الآلات المعقدة في كثير من الأحيان وراء مجموعة خدمات DONs القوية والمرنة. خدمات Chainlink الموجودة لديك بالفعل هذه الميزة. على سبيل المثال، تقدم خلاصات البيانات في Chainlink اليوم واجهات onchain لا تتطلب من المطورين الاهتمام بالتفاصيل على مستوى البروتوكول، مثل الوسائل التي يفرض بها التعرف الضوئي على الحروف (OCR) إعداد التقارير المتفق عليها بين 2 لقد نشأت فكرة تكوين العقود على السلسلة / خارج السلسلة سابقًا في العديد من القيود المقيدة النماذج، على سبيل المثال، أنظمة الطبقة الثانية، المستندة إلى TEE blockchains [80]، وما إلى ذلك. هدفنا هو الدعم والتعميم هذه الأساليب والتأكد من أنها يمكن أن تشمل الوصول إلى البيانات خارج السلسلة والمفاتيح الأخرى oracle الخدمات. تشتمل خدمات 3Chainlink على مجموعة متنوعة من الخدمات والوظائف اللامركزية المتاحة من خلال الشبكة. يتم تقديمها من قبل العديد من مشغلي العقد المكونة من شبكات oracle المختلفة عبر النظام البيئي.الشكل 2: شكل مفاهيمي يصور تكوين العقد على السلسلة / خارج السلسلة. أ هجين smart contract 3⃝يتكون من مكونين متكاملين: متصل بالسلسلة المكون SC 1⃝، المقيم في blockchain، والمكون خارج السلسلة exec 2⃝ذلك ينفذ على DON. يعمل DON كجسر بين المكونين أيضًا مثل ربط العقد المختلط بموارد خارج السلسلة مثل خدمات الويب وغيرها blockchains، والتخزين اللامركزي، وما إلى ذلك. مجموعة لامركزية من العقد. DONs يذهبون إلى أبعد من ذلك بمعنى أنهم يوسعون مجموعة من الخدمات التي يمكن لـ Chainlink أن يقدم للمطورين طبقة تجريد بها واجهات مبسطة مصاحبة للخدمات عالية المستوى. نقدم العديد من الأمثلة التطبيقية في القسم 4 التي تسلط الضوء على هذا النهج. نحن نتصور أن المؤسسات، على سبيل المثال، تستخدم DONs كشكل من أشكال البرامج الوسيطة الآمنة قم بتوصيل أنظمتهم القديمة بـ blockchains. (انظر القسم 4.2.) يؤدي هذا الاستخدام لملخصات DON إلى التخلص من تعقيد ديناميكيات blockchain العامة (الرسوم، وعمليات إعادة التنظيم، وما إلى ذلك). إنه أيضًا يلخص ميزات blockchains المحددة، وبالتالي تمكين المؤسسات من ربط أنظمتها الحالية بمجموعة متزايدة باستمرار من أنظمة blockchain بدون الحاجة إلى خبرة متخصصة في هذه الأنظمة، أو بشكل أعم، في تطوير الأنظمة اللامركزية. في نهاية المطاف، طموحنا هو دفع درجة التجريد التي حققها Chainlink إلى درجة تنفيذ ما نشير إليه بطبقة معدنية لامركزية. مثل هذه الطبقة من شأنه أن يزيل التمييز على السلسلة / خارج السلسلة لجميع فئات المطورين ومستخدمي التطبيقات اللامركزية، مما يسمح بإنشاء واستخدام الخدمات اللامركزية بشكل سلس.لتبسيط عملية التطوير، يمكن للمطورين تحديد وظيفة DApp في الطبقة المعدنية كتطبيق افتراضي في نموذج جهاز موحد. يمكنهم ذلك ثم استخدم مترجم طبقة ميتا لامركزية لإنشاء مثيل DApp تلقائيًا مجموعة من الوظائف اللامركزية المتداخلة التي تمتد على blockchains، DONs، و الخدمات الخارجية. (يمكن أن تكون إحدى هذه الخدمات الخارجية نظامًا مؤسسيًا، مما يجعل الطبقة المعدنية مفيدة للتطبيقات التي تتضمن أنظمة مؤسسية قديمة). يشبه التجميع كيفية قيام المترجمين الحديثين ومجموعات تطوير البرامج (SDKs) دعم المبرمجين العموميين في استخدام الإمكانات الكاملة للأجهزة غير المتجانسة معماريات تتكون من وحدة معالجة مركزية للأغراض العامة وأجهزة متخصصة مثل وحدات معالجة الرسومات، مسرعات التعلم الآلي، أو الجيوب الموثوقة. يعرض الشكل 3 هذه الفكرة على المستوى المفاهيمي. تعد العقود الهجينة smart contracts خطوة أولى على الطريق نحو هذه الرؤية وإلى مفهوم نسميه العقود الوصفية. العقود الوصفية هي تطبيقات مشفرة على اللامركزية طبقة ميتالية وتشمل ضمنيًا منطق السلسلة (smart contracts)، بالإضافة إلى حساب خارج السلسلة والاتصال بين مختلف blockchains وداخل السلسلة الحالية الخدمات. نظرا للحاجة إلى دعم اللغة والمترجم، ونماذج الأمان الجديدة، و ولكن تحقيق المواءمة المفاهيمية والتقنية للتكنولوجيات المتباينة أمر ممكن إن إنشاء طبقة معدنية لامركزية حقيقية هو هدف طموح نطمح إليه على مدى فترة طويلة الأفق الزمني. ومع ذلك فهو نموذج مثالي مفيد يجب أخذه في الاعتبار أثناء القراءة هذه الورقة، ليست مفصلة هنا، ولكنها شيء نخطط للتركيز عليه في عملنا المستقبلي Chainlink. التحجيم: أحد الأهداف ذات الأهمية البارزة في تصميماتنا المتطورة هو تمكين شبكة Chainlink لتلبية احتياجات التوسع المتزايدة للنظام البيئي blockchain. مع تحول ازدحام الشبكة إلى مشكلة متكررة في القائمة غير المسموح بها blockchains [86]، تصميمات blockchain الجديدة والأكثر أداءً تدخل حيز الاستخدام، على سبيل المثال، [103، 120، 203]، بالإضافة إلى تقنيات قياس الطبقة الثانية التكميلية، على سبيل المثال، [5، 12، 121، 141، 169، 186، 187]. يجب أن تحقق خدمات Oracle زمن الاستجابة والإنتاجية التي تلبي متطلبات أداء هذه الأنظمة مع تقليل الرسوم على السلسلة (على سبيل المثال، تكاليف الغاز) لمشغلي العقود والمستخدمين العاديين على حد سواء. مع DONs، Chainlink تهدف الوظيفة إلى المضي قدمًا وتقديم أداء عالٍ بما يكفي للأنظمة المستندة إلى الويب تمامًا. تستمد DONs الكثير من مكاسب أدائها من استخدامها لبروتوكولات الإجماع السريعة أو القائمة على اللجان أو غير المسموح بها، والتي تدمجها مع blockchains إنهم يدعمون. نتوقع تشغيل العديد من DONs ذات التكوينات المختلفة بالتوازي؛ يمكن للتطبيقات اللامركزية والمستخدمين المختلفين التنقل بين المفاضلات في خيارات الإجماع الأساسية وفقا لمتطلبات التطبيق الخاصة بهم. يمكن عرض DONs بشكل فعال كتقنيات الطبقة الثانية. نتوقع أن بين الخدمات الأخرى، DONs ستدعم إطار عمل تنفيذ المعاملات (TEF)، والذي يسهل التكامل الفعال لـ DONs وبالتالي oracles مع غيرها من الأداء العالي أنظمة الطبقة الثانية - على سبيل المثال، rollups، الأنظمة التي تجمع المعاملات خارج السلسلة لتحقيقها تحسينات في الأداء. نقدم TEF في القسم 6.

الشكل 3: شكل مفاهيمي يوضح الإدراك المثالي لطبقة معدنية لا مركزية. ل لسهولة التطوير، يحدد المطور التطبيق اللامركزي، المميز باللون الوردي، باعتباره تطبيقًا افتراضيًا التطبيق في نموذج الآلة الموحدة يقوم المترجم اللامركزي ذو الطبقة المعدنية تلقائيًا بإنشاء وظائف التشغيل البيني المقابلة: smart contracts (يُشار إليه بواسطة SC)، المنطق (المشار إليه بواسطة exec) على DONs، والمحولات التي تتصل بالخدمات الخارجية المستهدفة، وما إلى ذلك، كما هو موضح في التمييز باللون الأصفر. يوضح الشكل 4 من الناحية النظرية كيف تعمل DONs على تحسين مقياس blockchain (smart contract) من خلال تركيز المعاملات وoracle-معالجة التقارير خارج السلسلة، بدلاً من التركيز عليها سلسلة. هذا التحول في الموقع الرئيسي للحساب يقلل من زمن الوصول للمعاملة الرسوم مع زيادة إنتاجية المعاملات. السرية: توفر Blockchains شفافية غير مسبوقة لـ smart contracts والتطبيقات التي تنفذها. ولكن هناك توتراً أساسياً بين الشفافية والسرية. واليوم، على سبيل المثال، أصبحت عمليات التبادل اللامركزية للمستخدمينالشكل 4: شكل مفاهيمي يوضح كيفية تحسين شبكات أوراكل اللامركزية تحجيم blockchain smart contracts الممكنة. الشكل أ ⃝يظهر تقليدي oracle الهندسة المعمارية. يتم إرسال المعاملات مباشرة إلى blockchain، وكذلك التقارير oracle. وبالتالي فإن blockchain، المميز باللون الأصفر، هو الموقع الرئيسي لمعالجة المعاملات. يوضح الشكل ب⃝ استخدام DON لدعم العقود على blockchain. أ DON المعاملات العملياتية القابلة للتنفيذ جنبًا إلى جنب مع البيانات من الأنظمة الخارجية والأمام النتائج - على سبيل المثال، المعاملات المجمعة أو تغييرات حالة العقد الناتجة عن تأثيرات المعاملات - إلى blockchain. وبالتالي فإن DON، المظلل باللون الأصفر، هو العنصر الرئيسي مكان لمعالجة المعاملات. يتم تسجيل الإجراءات على السلسلة، مما يجعل من السهل مراقبة سلوك التبادل، ولكن أيضًا جعل المعاملات المالية للمستخدمين مرئية للعامة. وبالمثل، يتم نقل البيانات إلى الأجهزة الذكية العقود لا تزال على السلسلة. وهذا يجعل هذه البيانات قابلة للتدقيق بشكل ملائم، ولكنها تعمل أيضًا وهو عامل مثبط لموفري البيانات الراغبين في تزويد smart contracts ببيانات حساسة أو بيانات الملكية. نعتقد أن شبكات oracle ستلعب دورًا محوريًا في تحفيز الجيل التالي الأنظمة التي تجمع بين الشفافية الفطرية لـ blockchains ووسائل حماية السرية الجديدة. وفي هذه الورقة، نوضح كيف سيفعلون ذلك باستخدام ثلاثة أساليب رئيسية: • محولات الحفاظ على السرية: تقنيتان مع التخطيط للنشر في شبكات Chainlink، DECO [234] وTown Crier [233]، قم بتمكين العقد oracle لـ استرداد البيانات من الأنظمة خارج السلسلة بطرق تحمي خصوصية المستخدم وبياناته السرية. سوف يلعبون دورًا رئيسيًا في تصميم المحولات الخاصة بـ DONs. (انظر القسم 3.6.2 للحصول على تفاصيل حول هاتين التقنيتين.) • الحساب السري: يمكن لـ DONs ببساطة إخفاء حساباتهم من الاعتماد على blockchains. باستخدام حساب آمن متعدد الأطراف و/أو بيئات تنفيذ موثوقة، من الممكن أيضًا توفير سرية أقوى في DON العقد حساب البيانات التي لا يمكنهم رؤيتها بأنفسهم.

• دعم أنظمة الطبقة الثانية السرية: تم تصميم TEF لدعم مجموعة متنوعة من أنظمة الطبقة الثانية، والتي يستخدم الكثير منها براهين المعرفة الصفرية لتوفير أشكال مختلفة من سرية المعاملات. نناقش هذه الأساليب في القسم 3 (مع تفاصيل إضافية في القسم 6، الملحق ب.1، والملحق ب.2). يقدم الشكل 5 وجهة نظر مفاهيمية لكيفية تدفق البيانات الحساسة من مصادر خارجية إلى smart contract عن طريق محولات الحفاظ على السرية و حساب سري في DON. الشكل 5: رسم تخطيطي مفاهيمي لعمليات الحفاظ على السرية في DON على البيانات الحساسة (مظللة باللون الأصفر). بيانات المصدر الحساسة (الدوائر السوداء) في الويب يتم استخراج الخوادم إلى DON باستخدام محولات الحفاظ على السرية (الخطوط الزرقاء ذات الأسهم المزدوجة). يتلقى DON البيانات المشتقة (دوائر مجوفة) من هذه المحولات— نتيجة تطبيق وظيفة أو، على سبيل المثال، مشاركة سرية، على المصدر الحساس data. قد يطبق الملف القابل للتنفيذ على DON حسابًا سريًا على البيانات المشتقة لإنشاء تقرير (دائرة مزدوجة)، يتم إرساله عبر محول إلى blockchain. ونحن نعتقد أن الأدوات القوية للتعامل مع البيانات السرية ستفتح المجال أمام الجميع مجموعة من التطبيقات. ومن بين هذه العوامل التمويل اللامركزي (والمركزي) الخاص، والهوية اللامركزية، والإقراض القائم على الائتمان، وتوفير المزيد من الكفاءة والفعالية. بروتوكولات "اعرف عميلك" و"الاعتماد" سهلة الاستخدام، كما نناقش في القسم 4. عدالة الطلب في المعاملات: تصميمات blockchain اليوم بها القليل من الأشياء القذرة سر مفتوح: إنها مركزية بشكل سريع الزوال. يمكن لعمال المناجم وvalidators طلب التحويلالإجراءات التي يختارونها. يمكن أيضًا للمستخدمين التلاعب بأمر المعاملة وظيفة رسوم الشبكة التي يدفعونها (على سبيل المثال، أسعار الغاز في Ethereum) وبالنسبة للبعض المدى من خلال الاستفادة من اتصالات الشبكة السريعة. مثل هذا التلاعب يمكن أن يكون على سبيل المثال، خذ شكل المنافسة الأمامية، حيث يكون هناك ممثل استراتيجي مثل عامل المناجم يراقب معاملة المستخدم ويدرج المعاملة الاستغلالية الخاصة به في معاملة سابقة الموضع في نفس الكتلة - سرقة الأموال بشكل فعال من المستخدم من خلال الاستفادة من المعرفة المسبقة بمعاملة المستخدم. على سبيل المثال، قد يقوم الروبوت بوضع أمر شراء قبل المستخدم. ويمكنه بعد ذلك الاستفادة من الزيادة في أسعار الأصول الناجمة عن تجارة المستخدم. تشغيل بعض الروبوتات في المقدمة مما يضر بالمستخدمين العاديين، وهو ما يشبه التردد العالي التداول في وول ستريت — هو أمر سائد بالفعل وموثق جيدًا [90]، كما هو مرتبط هجمات مثل التشغيل الخلفي [159] ومحاكاة المعاملات الآلية [195]. وقد ظهرت مؤخرًا مقترحات لتنظيم استغلال الطلب من قبل القائمين بالتعدين [110]. تقنيات الطبقة الثانية مثل rollups لا تحل المشكلة، ولكنها مجرد إعادة مركزية الطلب، ووضعه في يد الكيان الذي يقوم بإنشاء rollup. أحد أهدافنا هو تقديم خدمة تسمى "التسلسل العادل" إلى Chainlink الخدمات (FSS) [137]. تساعد FSS مصممي smart contract على ضمان الترتيب العادل لأعمالهم المعاملات وتجنب الهجمات الأمامية والخلفية والهجمات ذات الصلة على معاملات المستخدم بالإضافة إلى أنواع أخرى من المعاملات، مثل oracle إرسال التقرير. الخدمة الثابتة الساتلية يمكّن DON من تنفيذ أفكار مثل المفهوم الدقيق والمؤقت لعدالة النظام المقدم في [144]. وكميزة عرضية، يمكن للخدمة الثابتة الساتلية أيضًا أن تخفض شبكة المستخدمين الرسوم (مثل تكاليف الغاز). باختصار، في الخدمة الثابتة الساتلية، تمر المعاملات عبر DON، بدلاً من الانتشار مباشرة إلى الهدف smart contract. يقوم DON بطلب المعاملات ثم إعادة توجيهها لهم بالعقد. الشكل 6: مثال على مدى فائدة الخدمة الثابتة الساتلية. الشكل أ ⃝يبين كيف يقوم عامل المناجم باستغلاله السلطة المركزية لطلب المعاملات، قد تقوم بتبديل زوج من المعاملات: المعاملة 1⃝ يصل قبل 2⃝، لكن عامل التعدين يقوم بتسلسله بعد 2⃝. في المقابل، يظهر الشكل B⃝ كيف يقوم DON بإضفاء اللامركزية على عملية الطلب بين DON العقد. إذا اكتمل النصاب القانوني تستقبل العقد الصادقة 1⃝قبل 2⃝، يتسبب FSS في ظهور 1⃝قبل 2⃝على السلسلة— منع إعادة ترتيب المُعدنين عن طريق إرفاق أرقام تسلسلية قابلة للتنفيذ بموجب العقد. يقارن الشكل 6 التعدين القياسي مع الخدمة الثابتة الساتلية. ويبين كيف في التعدين القياسي،تتم عملية طلب المعاملات بشكل مركزي مع القائم بالتعدين وبالتالي تخضع لـ التلاعب، مثل إعادة ترتيب زوج من المعاملات فيما يتعلق بوصولها مرات. في المقابل، في FSS، تكون العملية لا مركزية بين العقد DON. على افتراض النصاب القانوني للعقد الصادقة، FSS يساعد على فرض سياسات مثل الترتيب الزمني لل المعاملات، مما يقلل من فرص التلاعب من قبل عمال المناجم والكيانات الأخرى. بالإضافة إلى ذلك، نظرًا لأن المستخدمين لا يحتاجون إلى التنافس للحصول على طلبات تفضيلية بناءً على سعر الغاز، يمكنهم دفع أسعار غاز منخفضة نسبيًا (بينما يمكن تجميع المعاملات من DON على دفعات لتوفير الغاز). تقليل الثقة: هدفنا العام في تصميم DONs هو تسهيل عملية للغاية طبقة دعم جديرة بالثقة لـ smart contracts والأنظمة الأخرى المعتمدة على oracle عن طريق اللامركزية وأدوات التشفير وضمانات الاقتصاد المشفر. DON في حد ذاته لا مركزي، ويمكن للمستخدمين الاختيار من بين أي DON متاح يدعم السلسلة الرئيسية التي يرغبون في تشغيلها أو إنتاج DONs إضافية عليها بلجان العقد التي يثقون بها. ومع ذلك، بالنسبة لبعض التطبيقات، وخاصة smart contracts، يجوز لمستخدمي Chainlink تفضيل نموذج الثقة الذي يتعامل مع السلسلة الرئيسية المدعومة بـ DON على أنها أكثر جدارة بالثقة من DON نفسها. بالنسبة لهؤلاء المستخدمين، لدينا بالفعل أو نخطط لدمجهم في بنية شبكة Chainlink عدد من الآليات التي تمكن العقود على سلسلة رئيسية لتعزيز الضمانات الأمنية المقدمة من DONs، أثناء وجوده في وفي نفس الوقت يتم أيضًا فرض الحماية ضد احتمالية وجود مصادر بيانات تالفة مثل خوادم الويب التي يحصل منها DON على البيانات. نصف هذه الآليات في القسم 7. وهي تقع تحت خمسة عناوين رئيسية: • مصادقة مصدر البيانات: أدوات تمكن موفري البيانات من التوقيع رقميًا بياناتهم وبالتالي تعزيز سلسلة العهدة بين الأصل و عقد الاعتماد. • DON تقارير الأقلية: العلامات الصادرة عن مجموعة فرعية من DON العقد التي لاحظ مخالفات الأغلبية في DON. • حواجز الحماية: المنطق الموجود على السلسلة الرئيسية الذي يكتشف الظروف الشاذة والتوقف المؤقت أو يوقف تنفيذ العقد (أو يستدعي علاجات أخرى). • الحوكمة التي تقلل من الثقة: استخدام تحديثات الإصدار التدريجي لتسهيل التفتيش المجتمعي، بالإضافة إلى التدخلات اللامركزية في حالات الطوارئ من أجل التدخل السريع الاستجابة لفشل النظام. • مصادقة الكيان اللامركزي: استخدام البنية التحتية للمفتاح العام (PKI) من أجل تحديد الكيانات في شبكة Chainlink. يعرض الشكل 7 مخططًا مفاهيميًا لأهدافنا المتعلقة بتقليل الثقة. الأمن القائم على الحوافز (الاقتصاد المشفر): تساعد اللامركزية في إنشاء التقارير عبر العقد oracle على ضمان الأمان حتى في حالة تلف بعض العقد.

الشكل 7: تصوير مفاهيمي لهدف تقليل الثقة لدى Chainlink، وهو تقليل حاجة المستخدمين إلى السلوك الصحيح لـ DON ومصادر البيانات مثل الويب الخوادم. تشير النقاط المميزة باللون الأصفر في الشكل إلى مواقع تقليل الثقة: DON و مجموعات فردية أو أقلية من خوادم الويب. تشير النقاط المميزة باللون الوردي إلى مكونات النظام التي تعتبر جديرة بالثقة للغاية من خلال الافتراض: العقود على blockchain والأغلبية من خوادم الويب، أي خوادم الويب في المجمل. لكن من المهم بنفس القدر ضمان أن يكون لدى العقد حافز مالي للتصرف بشكل صحيح. التوقيع المساحي، أي مطالبة العقد بتوفير ودائع الارتباط والقطع (مصادرة) هذه الودائع في حالة سوء السلوك، ستلعب دورًا رئيسيًا في Chainlink. إنه تصميم حوافز مهم تم استخدامه بالفعل في عدد من blockchains، على سبيل المثال، [81، 103، 120، 204]. ومع ذلك، يبدو التخزين في Chainlink مختلفًا تمامًا عن staking في الوضع المستقل blockchains. يهدف التخزين في blockchains إلى منع الهجمات على الإجماع. لديها هدف مختلف في Chainlink: ضمان تسليم تقارير oracle الصحيحة في الوقت المناسب. يجب أن يؤدي نظام staking المصمم جيدًا لشبكة oracle إلى التصدي لهجمات مثل الرشوة غير مربحة للخصم، حتى عندما يكون الهدف هو smart contract ذو مستوى عالٍ القيمة النقدية. نقدم في هذا البحث منهجًا عامًا لـ staking في Chainlink بثلاثة مفاتيح الابتكارات:1. نموذج عدائي قوي يشمل الهجمات التي تم التغاضي عنها في الوقت الحالي النهج. أحد الأمثلة على ذلك هو ما نسميه الرشوة المحتملة. هذا هو شكل من أشكال الرشوة التي تحدد العقد التي تتلقى الرشاوى على أساس مشروط، على سبيل المثال، يقدم رشاوى مضمونة مقدمًا للعقد التي تحددها آلية staking في عشوائي لأدوار معينة (مثل تفعيل الفصل في التقرير). 2. التأثير الخطي الفائق staking، مما يعني بشكل غير رسمي أنه لكي ينجح الخصم، يجب أن تكون لديه ميزانية قدرها مليار دولار أكبر من الودائع المجمعة لجميع oracle العقد. بتعبير أدق، نعني أنه كدالة لـ n، \(B(n) ≫\)dn في a شبكة مكونة من عدد n oracle من العقد لكل منها مبلغ إيداع ثابت $d (بشكل أكثر رسمية، \(B(n) is asymptotically larger in n than \)dn). الشكل 8 يعطي نظرة مفاهيمية ل هذه الخاصية. 3. إطار الحوافز الضمنية (IIF)، وهو نموذج حوافز صممناه من أجله تشمل حوافز قابلة للقياس تجريبيًا تتجاوز الحوافز المودعة بشكل صريح staking الأموال، بما في ذلك فرص الرسوم المستقبلية للعقد. يوسع معهد التمويل الدولي مفهوم حصة تتجاوز ودائع العقدة الصريحة. الشكل 8: رسم تخطيطي مفاهيمي يصور القياس الخطي الفائق في Chainlink staking. ال تنمو الرشوة $B(n) التي يطلبها الخصم بشكل أسرع في n من الودائع المجمعة $dn لجميع العقد oracle. نوضح كيف أن تأثير IIF والخط الفائق staking معًا يؤدي إلى ما نحن عليه استدعاء دورة حميدة من الأمن الاقتصادي لشبكات oracle. عندما يدخل مستخدمون جدد

النظام، وزيادة الأرباح المستقبلية المحتملة من تشغيل Chainlink العقد، و تنخفض التكلفة الحدية للأمن الاقتصادي للمستخدمين الحاليين والمستقبليين. في نظام الطلب المرن، فإن هذه التكلفة المنخفضة تحفز المزيد من المستخدمين على الاستفادة من الشبكة، مما يؤدي إلى إدامة التبني بشكل مستمر في دورة حميدة مستمرة. ملاحظة: على الرغم من أن هذا التقرير يوضح العناصر المهمة لرؤيتنا لتطور Chainlink، إلا أنه غير رسمي ويتضمن القليل من المواصفات الفنية التفصيلية. نحن نخطط ل إصدار أوراق فنية مركزة حول الميزات والأساليب الإضافية مع تطورها. علاوة على ذلك، من المهم التأكيد على أن العديد من عناصر الرؤية المقدمة هنا (تحسينات القياس، وتقنيات السرية، والخدمة الثابتة الساتلية، وما إلى ذلك) يمكن أن يحدث وسوف يحدث تم نشرها في شكل أولي حتى قبل أن تصبح DONs المتقدمة سمة أساسية لـ Chainlink. 1.3 تنظيم هذه الورقة نقدم نموذج الأمان الخاص بنا والترميز في القسم 2 ونحدد اللامركزية Oracle Network API في القسم 3. في القسم 4، نقدم عددًا من الأمثلة على ذلك التطبيقات التي توفر DONs لها نظامًا أساسيًا للنشر جذابًا. يمكن للقراء تعلم معظم المفاهيم الأساسية للورقة من خلال القراءة حتى هذه النقطة. يحتوي الجزء المتبقي من الورقة على مزيد من التفاصيل. وصفنا التسلسل العادل الخدمات (FSS) في القسم 5 وإطار تنفيذ المعاملات (TEF) في القسم 6. نوضح نهجنا لتقليل الثقة في القسم 7. ونأخذ في الاعتبار بعض متطلبات النشر المهمة DON، وهي النشر المتزايد للميزات، وعضوية دفتر الأستاذ الديناميكي، والمساءلة في القسم 8. وأخيرًا، في القسم 9، نقدم نظرة عامة على نهجنا المتطور لتصميم الحوافز. ننتهي في القسم 10. لمساعدة القراء الذين لديهم معرفة محدودة بالمفاهيم الواردة في هذه الورقة، نحن قم بتوفير مسرد في الملحق أ. ونقدم المزيد من التفاصيل حول واجهة DON والوظائف في الملحق ب وتقديم بعض أمثلة المحولات في الملحق ج. في الملحق د، وصفنا طريقة تشفير أولية لمصدر البيانات ذي الثقة المنخفضة تسمى المصادقة بالتوقيعات الوظيفية وتقدم متغيرًا جديدًا يسمى التوقيعات الوظيفية المنفصلة. نناقش بعض الاعتبارات التي تؤثر على اللجنة تحديد DONs في الملحق F.

نموذج الأمن والأهداف

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

وبالتالي فإن النموذج والخصائص التي نعتبرها مستقلة إلى حد كبير عن استخدام التطبيقات الخاصة بـ DON. 2.1 النموذج المعماري الحالي من المهم التأكيد على أن Chainlink اليوم ليست خدمة متجانسة، بل بالأحرى إطار عمل غير مسموح به يمكن من خلاله إطلاق متميز ومستقل شبكات oracle العقد [77]. تحتوي الشبكات على مجموعات غير متجانسة من مشغلي العقد و التصاميم. وقد يختلفون أيضًا من حيث أنواع الخدمات التي يقدمونها، وهو ما قد يختلف أيضًا تشمل، على سبيل المثال، خلاصات البيانات، وإثبات الاحتياطيات، والعشوائية القابلة للتحقق، وما إلى ذلك. أخرى يمكن أن تشمل الاختلافات درجة اللامركزية وحجم الشبكة من حيث القيمة المقفلة التي يدعمها، ومعلمات مستوى الخدمة المختلفة، مثل تردد البيانات والدقة. يشجع نموذج Chainlink غير المسموح به على نمو النظام البيئي الذي يتخصص مقدمو الخدمة في الخدمات التي هم أكثر قدرة على تقديمها للمجتمع. هذا من المرجح أن يؤدي النموذج إلى تكاليف أقل للمستخدمين وجودة خدمة أعلى من النموذج يتطلب ذلك من جميع العقد والشبكات توفير مجموعة كاملة من الخدمات، وهذا النهج والتي يمكن أن تتحول بسهولة إلى اعتماد على مستوى النظام للخدمات التي تمثل الأقل القاسم المشترك للموارد المتاحة للعقد. مع تطور Chainlink نحو التصميمات المستندة إلى DON في Chainlink 2.0، فإننا نواصل دعم نموذج الإطار المفتوح غير المسموح به، مع مراعاة هدف تزويد المستخدمين بمجموعة من خيارات الخدمة التي تؤدي عالميًا إلى أفضل تطابق مع متطلبات التطبيق الخاصة. 2.2 افتراضات الإجماع نحن نستخدم مصطلح شبكة أوراكل اللامركزية ليشمل الوظائف الكاملة لـ نظام oracle الذي نصفه: كل من بنية البيانات التي تحافظ عليها عقد oracle و واجهة برمجة التطبيقات الأساسية موجودة فوقها. نحن نستخدم مصطلح دفتر الأستاذ (الأحرف الصغيرة)، الذي يُشار إليه بالحرف L، للإشارة إلى البيانات الأساسية البنية التي يحتفظ بها DON وتستخدم لدعم الخدمات المحددة التي تقدمها. نؤكد على أن إطار عملنا DON لا يتعامل مع L كنظام قائم بذاته أ blockchain: الغرض منه هو دعم blockchains والأنظمة الأخرى. بلوكتشين هي، وبطبيعة الحال، هذه إحدى الطرق لتحقيق دفتر أستاذ جدير بالثقة، ولكن هناك طرق أخرى. نحن نتوقع DONs في كثير من الحالات لتحقيق دفاتر الأستاذ الأساسية الخاصة بهم باستخدام Byzantine Fault Tolerant (BFT) الأنظمة، التي تسبق إلى حد كبير blockchain مثل Bitcoin [174]. نحن نستخدم BFT - اكتب التدوين والخصائص في جميع أنحاء الورقة للراحة، على الرغم من أننا أكد على أنه يمكن تحقيق DONs باستخدام بروتوكولات الإجماع غير المسموح بها. من الناحية النظرية، دفتر الأستاذ L عبارة عن لوحة إعلانات يتم ترتيب البيانات عليها خطيًا. نحن ننظر إلى دفتر الأستاذ بشكل عام على أنه يحتوي على بعض الخصائص الأساسية التي تُنسب إليه عادةً blockchains [115]. دفتر الأستاذ هو: • إلحاق فقط: البيانات، بمجرد إضافتها، لا يمكن إزالتها أو تعديلها.• عامة: يمكن لأي شخص قراءة محتوياته، والتي تكون متسقة عبر الزمن في عرض لجميع المستخدمين.4 • متاح: يمكن دائمًا كتابة دفتر الأستاذ بواسطة كتاب معتمدين وقراءته من قبل أي شخص في الوقت المناسب. الخصائص البديلة ممكنة في دفتر الأستاذ لـ DON عند تحقيقها بواسطة a اللجنة. على سبيل المثال، قد يقتصر الوصول إلى الكتابة في دفتر الأستاذ على مستخدمين معينين، مثل قد يكون الوصول للقراءة لبعض التطبيقات، أي أنه لا يلزم أن يكون دفتر الأستاذ عامًا كما هو محدد أعلاه. وبالمثل، قد تسمح قواعد دفتر الأستاذ بتعديل البيانات أو تنقيحها. نحن لا نفعل ذلك ومع ذلك، فكر صراحةً في مثل هذه المتغيرات في هذه الورقة. يمكن للتصميم المعياري لـ DONs أن يدعم أيًا من مجموعة واسعة من BFT الحديثة protocols, e.g., Hotstuff[231]. سيعتمد الاختيار الدقيق على افتراضات الثقة و خصائص الشبكة بين العقد oracle. يمكن لـ DON من حيث المبدأ أن يكون بديلاً استخدم blockchain عالي الأداء بدون إذن لدفتر الأستاذ الخاص به في دوره الداعم طبقة 2 قابلة للتطوير بشكل متساوٍ أو نظام blockchain. وبالمثل، فإن التهجين ممكن أيضًا: يمكن أن يتكون DON من حيث المبدأ من العقد التي هي validators في موجودة blockchain، على سبيل المثال، في أنظمة إثبات الملكية التي يتم فيها اختيار اللجان للتنفيذ المعاملات، على سبيل المثال، [8، 81، 120، 146، 204]. يتطلب وضع التشغيل هذا ذلك تعمل العقد بطريقة الاستخدام المزدوج، أي تعمل كعقد blockchain و DON العقد. (انظر القسم 8.2 لمناقشة التقنيات لضمان الاستمرارية في التغيير اللجان والملحق و لبعض المحاذير بشأن الاختيار العشوائي للجنة.) من الناحية العملية، في خوارزميات BFT الحديثة، تقوم العقد بتوقيع الرسائل رقميًا على دفتر الأستاذ. نحن نفترض من أجل الراحة أن L لديه مفتاح عام مرتبط pkL وأن محتوياته يتم توقيعها بواسطة المفتاح الخاص المقابل. ينطبق هذا التدوين العام حتى عندما يتم توقيع البيانات الموجودة على L باستخدام توقيعات العتبة.5 تعتبر توقيعات العتبة ملائمة، لأنها تتيح هوية ثابتة لـ DON حتى مع تغييرات العضوية العقد التي تعمل عليه. (انظر الملحق ب.1.3.) وبالتالي فإننا نفترض أن skL مشترك بشكل سري بطريقة العتبة (k, n) لبعض معلمات الأمان k، على سبيل المثال، k = 2f + 1 و n = 3f + 1، حيث f هو عدد العقد التي يحتمل أن تكون معيبة. (باختيار k في هذا بهذه الطريقة، نحن نضمن أن العقد المعيبة لا يمكنها تعلم skL ولا تؤدي إلى رفض الخدمة هجوم يمنع استخدامه.) تأخذ الرسالة على L الشكل M = (m, z)، حيث m عبارة عن سلسلة وz فريدة رقم الفهرس التسلسلي. حيثما ينطبق ذلك، نكتب الرسائل في النموذج م = ⟨نوع الرسالة: الحمولة⟩. نوع الرسالة messageType هو السكر النحوي الذي يشير إلى وظيفة رسالة معينة. 4في الحالات التي يحقق فيها blockchain بدون نهائية دفتر الأستاذ، يتم عادةً تجريد التناقض بعيدًا عن طريق تجاهل الكتل العميقة غير الكافية أو "التقليم" [115]. 5In practice, some code bases, e.g., LibraBFT [205], a variant of Hotstuff, have currently adopted التوقيعات المتعددة، بدلاً من توقيعات العتبة، أدى التداول إلى تقليل تعقيد الاتصال هندسة أبسط. مع بعض التكلفة الإضافية، يمكن للعقد oracle إلحاق الحد الأدنى من التوقيعات بالرسائل مكتوبة إلى L حتى لو كان بروتوكول الإجماع المستخدم لـ L لا يستخدمها.2.3 التدوين نشير إلى مجموعة n oracle العقد التي تقوم بتشغيل دفتر الأستاذ بواسطة O = {Oi}n أنا = 1. مثل هذا غالبًا ما تسمى مجموعة العقد باللجنة. للتبسيط، نفترض أن مجموعة oracles التي تنفذ وظيفة DON، أي الخدمات الموجودة أعلى L، متطابقة مع أن الحفاظ على L، ولكن يمكن أن تكون متميزة. نسمح لـ pki بالإشارة إلى المفتاح العام لـ لاعب Oi، والتزلج على المفتاح الخاص المقابل. تتطلب معظم خوارزميات BFT ما لا يقل عن n = 3f + 1 عقد، حيث f هو عدد العقد العقد التي يحتمل أن تكون معيبة. العقد المتبقية صادقة، بمعنى أنها تتبع البروتوكول بالضبط كما هو محدد. ونشير إلى اللجنة يا صادقة إذا استوفت ذلك المتطلبات، أي أن لديها أكثر من 2/3 جزء من العقد الصادقة. ما لم يكن خلاف ذلك ذكرنا، نفترض أن يا صادق (ونموذج ثابت للفساد). نستخدم pkO/ skO بالتبادل مع pkL / skL، اعتمادا على السياق. ندع σ = Sigpk[m] تشير إلى التوقيع على الرسالة m فيما يتعلق بـ pk، أي باستخدام المفتاح الخاص المقابل sk. دع التحقق (pk، σ، m) → {false، true} يشير إلى خوارزمية التحقق من التوقيع المقابلة. (نترك الجيل الرئيسي ضمنيًا في جميع أنحاء الورقة.) نستخدم الرمز S للإشارة إلى مصدر البيانات وS للإشارة إلى المجموعة الكاملة مصادر nS في سياق معين. نشير بواسطة MAINCHAIN إلى تمكين العقد الذكي blockchain مدعوم بـ DON. نستخدم مصطلح عقد الاعتماد للدلالة على أي عقد ذكي عقد على MAINCHAIN الذي يتصل بـ DON، واستخدم الرمز SC لـ تشير إلى مثل هذا العقد. نحن نفترض بشكل عام أن DON يدعم سلسلة رئيسية واحدة MAINCHAIN، على الرغم من أنه يمكن أن يدعم العديد من هذه السلاسل، كما نوضح في الأمثلة في القسم 4. يمكن لـ DON أن يدعم عادةً عقودًا متعددة الاعتماد على MAINCHAIN. (كما كما هو مذكور أعلاه، يمكن أن يدعم DON بدلاً من ذلك الخدمات غير blockchain.) 2.4 ملاحظة حول نماذج الثقة كما هو مذكور أعلاه، قد يتم إنشاء DONs فوق بروتوكولات الإجماع القائمة على اللجنة، ونحن نتوقع أنهم سيستخدمون مثل هذه البروتوكولات بشكل شائع. هناك العديد من الحجج القوية التي يوفر أحد البديلين، القائم على اللجنة أو غير المسموح به blockchains أمان أقوى من الآخر. من المهم أن ندرك أن الأمن يعتمد على اللجنة مقابل عدم الإذن الأنظمة اللامركزية غير قابلة للقياس. المساس بإثبات العمل (PoW) أو إثبات الحصة (PoS) blockchain يتطلب الهجوم بنسبة 51% أن يحصل الخصم على أغلبية الموارد بشكل سريع الزوال و من المحتمل أن يكون مجهول الهوية، على سبيل المثال عن طريق استئجار hash الطاقة في نظام إثبات العمل (PoW). مثل هذا لقد أثرت الهجمات عمليًا بالفعل على العديد من blockchains [200، 34]. في المقابل، إن المساس بالنظام القائم على اللجان يعني إفساد عدد العتبة (عادة الثلث) من عقده، حيث قد تكون العقد معروفة للعامة، ومزودة بموارد جيدة، والجهات الجديرة بالثقة. ومن ناحية أخرى، فإن الأنظمة القائمة على اللجان (وكذلك الأنظمة "الهجينة" غير مسموح بها الأنظمة التي تدعم اللجان) يمكن أن تدعم وظائف أكثر مما هو مطلوب بشكل صارمأنظمة بلا مهمة. يتضمن ذلك القدرة على الحفاظ على الأسرار المستمرة، مثل التوقيع و/أو مفاتيح التشفير — أحد الاحتمالات في تصميماتنا. نؤكد على أنه يمكن من حيث المبدأ بناء DONs على مستوى اللجنة أو قد يختار بروتوكول الإجماع غير المسموح به وموزعي DON في النهاية اعتماده إما النهج. نماذج تعزيز الثقة: إحدى الميزات الرئيسية لـ Chainlink اليوم هي قدرة المستخدمين على ذلك حدد العقد بناءً على السجلات اللامركزية لسجلات أدائها، كما تمت مناقشته في القسم 3.6.4. تشكل آلية staking وإطار الحوافز الضمنية الذي نقدمه في القسم 9 معًا تصميمًا صارمًا وواسع النطاق للآلية إطار عمل من شأنه تمكين المستخدمين بقدرة موسعة بشكل كبير على قياس أمان DONs. هذا الإطار نفسه سيجعل من الممكن أيضًا لـ DONs أنفسهم لفرض متطلبات الأمان المختلفة على العقد المشاركة وضمان التشغيل ضمن نماذج الثقة القوية. من الممكن أيضًا استخدام الأدوات الموضحة في هذا البحث لـ DONs لفرض متطلبات نموذج الثقة الخاصة، مثل الامتثال للمتطلبات التنظيمية. ل على سبيل المثال، باستخدام التقنيات التي تمت مناقشتها في القسم 4.3، يمكن للعقد تقديم دليل على ذلك خصائص مشغل العقدة، على سبيل المثال، منطقة التشغيل، التي يمكن استخدامها للمساعدة فرض الامتثال، على سبيل المثال، المادة 3 من اللائحة العامة لحماية البيانات (GDPR) ("النطاق الإقليمي") [105]. قد يكون مثل هذا الامتثال أمرًا صعبًا يجتمع في الأنظمة اللامركزية [45]. بالإضافة إلى ذلك، نناقش في القسم 7 خططًا لتعزيز قوة DONs من خلال آليات تقليل الثقة في السلاسل الرئيسية التي يدعمونها.

واجهة شبكة أوراكل اللامركزية وCa-

القدرات نحن هنا نرسم بإيجاز قدرات DONs من حيث البساطة ولكن القوية الواجهة التي تم تصميمها لتحقيقها. تتكون التطبيقات الموجودة على DON من ملفات تنفيذية ومحولات. الملف القابل للتنفيذ هو برنامج منطقه الأساسي هو برنامج حتمي، مشابه لـ smart contract. يحتوي الملف القابل للتنفيذ أيضًا على عدد من البادئين المصاحبين، وهي البرامج التي تستدعي الدخول نقاط في منطق الملف القابل للتنفيذ عند وقوع أحداث محددة مسبقًا، على سبيل المثال، في أوقات معينة (مثل وظيفة كرون)، عندما يتجاوز السعر الحد الأدنى، وما إلى ذلك - يشبه إلى حد كبير الحراس (انظر القسم 3.6.3). توفر المحولات واجهات للموارد خارج السلسلة ويمكن استدعاؤها بواسطة إما البادئين أو المنطق الأساسي في الملفات التنفيذية. لأن سلوكهم قد يعتمد على ذلك من الموارد الخارجية، قد يتصرف البادئون والمحولون بطريقة غير حتمية. نحن نصف واجهة المطور DON وعمل الملفات التنفيذية و المحولات من حيث الموارد الثلاثة المستخدمة عادةً لوصف أنظمة الحوسبة: الشبكات والحوسبة والتخزين. ونقدم لمحة موجزة عن كل واحدة منها الموارد أدناه وتقديم المزيد من التفاصيل في الملحق ب.

3.1 الشبكات المحولات هي واجهات يمكن من خلالها إرسال الملفات التنفيذية التي تعمل على DON و تلقي البيانات من أنظمة DON خارج. يمكن النظر إلى المحولات على أنها تعميم لـ المحولات المستخدمة في Chainlink اليوم [20]. قد تكون المحولات ثنائية الاتجاه، أي أنها لا يمكن سحب البيانات فحسب، بل دفعها من DON إلى خادم الويب. يمكنهم أيضًا الاستفادة البروتوكولات الموزعة بالإضافة إلى وظائف التشفير مثل تعدد الأطراف الآمن حساب. الشكل 9: المحولات التي تربط DON، يُشار إليه بـ DON1، مع مجموعة من الموارد المختلفة، بما في ذلك DON آخر، يُشار إليه بـ DON2، وblockchain (السلسلة الرئيسية) وملحقاتها mempool ووحدة التخزين الخارجية وخادم الويب وأجهزة إنترنت الأشياء (عبر خادم الويب). يتم عرض أمثلة للموارد الخارجية التي يمكن إنشاء محولات لها في الشكل 9. وهي تشمل: • Blockchains: يمكن للمحول تحديد كيفية إرسال المعاملات إلى blockchain و كيفية قراءة الكتل أو المعاملات الفردية أو أي حالة أخرى منها. محول يمكن أيضًا تعريفه لمجمع الذاكرة blockchain. (انظر القسم 3.5.) • خوادم الويب: يمكن للمحولات تحديد واجهات برمجة التطبيقات التي يمكن من خلالها استرداد البيانات من خوادم الويب، بما في ذلك الأنظمة القديمة التي لم يتم تكييفها خصيصًا لها التواصل مع DONs. يمكن أن تتضمن هذه المحولات أيضًا واجهات برمجة التطبيقات لإرسال البيانات إليها مثل هذه الخوادم. قد تكون خوادم الويب التي يتصل بها DON بمثابة بوابات إلى موارد إضافية، مثل أجهزة إنترنت الأشياء (IoT).• وحدة التخزين الخارجية: يمكن للمحول تحديد طرق القراءة والكتابة إلى وحدة التخزين خدمات خارج DON، مثل نظام الملفات اللامركزي [40، 188] أو السحابة تخزين. • DONs أخرى: يمكن للمحولات استرداد البيانات ونقلها بين DONs. نتوقع أن تتضمن عمليات النشر الأولية لـ DONs مجموعة من الكتل البرمجية الإنشائية محولات لمثل هذه الموارد الخارجية شائعة الاستخدام وستسمح أيضًا بـ DON-محدد المحولات التي سيتم نشرها بواسطة العقد DON. كما يكتب مطورو smart contract المحولات اليوم، نتوقع أن يقوموا ببناء محولات أكثر قوة باستخدام هذا المتقدم الوظيفة. نتوقع أنه في النهاية سيكون من الممكن للمستخدمين إنشاء محولات جديدة في ملف بطريقة غير مسموح بها. يجب إنشاء بعض المحولات بطريقة تضمن استمرارية وتوافر الموارد الخارجية التي يتحكم فيها DON. على سبيل المثال، قد يكون التخزين السحابي تتطلب صيانة حساب الخدمات السحابية. بالإضافة إلى ذلك، يمكن تنفيذ DON الإدارة اللامركزية للمفاتيح الخاصة نيابة عن المستخدمين (كما في، على سبيل المثال، [160]) و/أو الملفات التنفيذية. وبالتالي، فإن DON قادر على التحكم في الموارد، مثل العملة المشفرة، التي يمكن استخدامها، على سبيل المثال، لإرسال المعاملات على الهدف blockchain. راجع الملحق ب.1 لمزيد من التفاصيل حول محولات DON، كما هو الحال في الملحق ج لعدد قليل محولات المثال. 3.2 الحساب الملف القابل للتنفيذ هو الوحدة الأساسية للتعليمات البرمجية في DON. الملف القابل للتنفيذ هو زوج exec = (المنطق، الحرف الأول). هنا، المنطق هو برنامج حتمي مع عدد من المدخلات المعينة النقاط (logic1، logic2،...، logicℓ) وinit عبارة عن مجموعة من البادئات المقابلة (init1، init2،...، inite). لضمان إمكانية التدقيق الكامل لمنطق الملف القابل للتنفيذ DON يستخدم دفتر الأستاذ الأساسي L لجميع المدخلات والمخرجات. وهكذا، على سبيل المثال، أي محول يجب تخزين البيانات التي تعمل كمدخل للملف القابل للتنفيذ أولاً على L. المبادرون: يتسبب البادئون في Chainlink اليوم في تنفيذ عمليات تنفيذ مهام تعتمد على الحدث Chainlink العقد [21]. تعمل البادئات في DONs بنفس الطريقة تقريبًا. ومع ذلك، فإن البادئ DON يرتبط بشكل خاص بملف قابل للتنفيذ. قد يعتمد البادئ على حدث أو حالة خارجية، في الوقت الحالي، أو على مسند على حالة DON. ومع اعتمادهم على الأحداث، قد يتصرف المبادرون بالطبع بطريقة غير حتمية (وبطبيعة الحال قد محولات). يمكن للبادئ التنفيذ ضمن العقد الفردية DON ولذا لا داعي للاعتماد على المحول. (انظر المثال 1 أدناه.) تعد البادئات ميزة مهمة تميز الملفات التنفيذية عن smart contracts. نظرًا لأن الملف القابل للتنفيذ يمكن تشغيله استجابةً للبادئ، فإنه يمكن أن يعمل بشكل فعال بشكل مستقل، كما هو الحال بالطبع، يمكن لعقد مختلط يتضمن ما هو قابل للتنفيذ. أحد أشكال المبادرين اليوم هو Chainlink Keepers، الذي يوفر المعاملاتخدمات التشغيل الآلي، مما يؤدي إلى تنفيذ smart contract - مثل تصفية القروض غير المضمونة وتنفيذ عمليات التداول ذات الأوامر المحددة - استنادًا إلى تقارير oracle. ومن الملائم أيضًا أن يتم النظر إلى البادئين في DONs كطريقة لتحديد اتفاقيات الخدمة التي تنطبق على الملف القابل للتنفيذ، لأنها تحدد الظروف في ظلها والذي يجب أن يطلق عليه DON. يوضح المثال التالي كيفية عمل البادئين ضمن ملف قابل للتنفيذ: المثال 1 (موجز الأسعار الناتج عن الانحراف). قد يتطلب smart contract SC طازجًا بيانات تغذية الأسعار (انظر القسم 3.6.3) عندما يكون هناك تغيير جوهري، على سبيل المثال، 1%، في سعر الصرف بين زوج من الأصول، على سبيل المثال، ETH-USD. سعر حساس للتقلب يتم دعم الخلاصات في Chainlink اليوم، ولكن من المفيد أن نرى كيف يمكن أن تكون كذلك تم تحقيقه على DON عن طريق ملف تنفيذي قابل للتنفيذ. يحتفظ الملف التنفيذي القابل للتنفيذ بأحدث سعر لـ ETH-USD r على L، في شكل تسلسل ⟨NewPrice : j، r⟩entries، حيث j هو مؤشر متزايد بـ كل تحديث للسعر. يتسبب البادئ init1 في قيام كل عقدة Oi بمراقبة السعر الحالي لـ ETH-USD انحرافات لا تقل عن 1٪ من أحدث سعر مخزن r مع الفهرس j. على عند اكتشاف مثل هذا الانحراف، يكتب Oi وجهة نظره الحالية ri للسعر الجديد إلى L باستخدام إدخال النموذج ⟨PriceView : i, j + 1, ri⟩. يتم تشغيل البادئ الثاني عند تشغيل إدخالات PriceView على الأقل بسعر جديد تراكمت قيم الفهرس j + 1 التي تم إنشاؤها بواسطة العقد المميزة على L. ثم، init2 يستدعي منطق نقطة الدخول 2 لحساب الوسيط ρ لقيم عرض الأسعار الجديدة والصالحة الأولى k ويكتب قيمة جديدة ⟨NewPrice : j + 1, ρ⟩to L . (من الناحية التشغيلية، العقد قد يتناوبون ككتاب معينين.) يراقب البادئ الثالث init3 إدخالات NewPrice على L. كلما ظهر تقرير جديد ⟨سعر جديد: يظهر j, r⟩ هناك، وهو يستدعي منطق نقطة الدخول 3 الذي يدفع (j, r) إلى SC باستخدام محول. وكما لاحظنا، فإن الملف القابل للتنفيذ يشبه في قدراته smart contract. وبصرف النظر عن أدائها العالي، فهي تختلف عن عقد السلسلة الرئيسية النموذجي بطريقتين أساسيتين: 1. السرية: يمكن للملف القابل للتنفيذ إجراء عمليات حسابية سرية، أي أن برنامجًا سريًا قد يعالج مدخلات نص واضح، أو قد يقوم برنامج منشور بمعالجة بيانات الإدخال السرية، أو مزيج من الاثنين معا. في نموذج بسيط، يمكن للبيانات السرية يمكن الوصول إليها عن طريق العقد DON، والتي تخفي النتائج المتوسطة وتكشف فقط القيم المعالجة والمعقمة إلى MAINCHAIN. من الممكن أيضًا إخفاء البيانات الحساسة عن DONs أنفسهم: DONs تهدف إلى دعم الأساليب مثل كحساب متعدد الأطراف، على سبيل المثال، [42، 157]، وبيئات التنفيذ الموثوقة (TEEs) [84، 133، 152، 229] لهذا الغرض.6 6بالإضافة إلى ذلك، من الممكن أيضًا الحفاظ على سرية الملفات التنفيذية فيما يتعلق بالعقد DON، على الرغم من أن هذا أمر عملي فقط اليوم بالنسبة للملفات التنفيذية غير التافهة التي تستخدم TEEs.2. الدور الداعم: الملف القابل للتنفيذ يهدف إلى دعم smart contracts على الملف الرئيسي سلسلة، بدلا من استبدالها. يحتوي الملف القابل للتنفيذ على العديد من القيود التي أ smart contract لا: (أ) نموذج الثقة: يعمل الملف القابل للتنفيذ ضمن نموذج الثقة المحدد بواسطة DON: يعتمد تنفيذها الصحيح على السلوك الصادق لـ O. (A main ومع ذلك، يمكن للسلسلة توفير بعض حواجز الحماية ضد DON المخالفات، كما تمت مناقشته في القسم 7.3.) (ب) الوصول إلى الأصول: يمكن لـ DON التحكم في حساب على blockchain - وبالتالي السيطرة على الأصول عليه من خلال محول. لكن DON لا يمكن أن يكون بشكل رسمي تمثل الأصول التي تم إنشاؤها على سلسلة رئيسية، على سبيل المثال، Ether أو ERC20 tokens، منذ ذلك الحين تحتفظ سلسلتهم الأصلية بالسجل الرسمي لملكيتهم. (ج) دورة الحياة: قد يتم إيقاف DONs عمدًا مع فترات حياة محدودة، كما يتم تحديدها من خلال اتفاقيات مستوى الخدمة على السلسلة بين DONs والمالكين من الاعتماد على العقود. في المقابل، تهدف سلاسل الكتل إلى العمل أنظمة أرشفة دائمة. راجع الملحق ب.2 لمزيد من التفاصيل حول حساب DON. 3.3 التخزين باعتباره نظامًا قائمًا على اللجان، يستطيع DON تخزين كميات معتدلة من البيانات بشكل مستمر على L بتكلفة أقل بكثير من blockchain غير المسموح به. بالإضافة إلى ذلك، عبر المحولات، يمكن لـ DONs الرجوع إلى الأنظمة اللامركزية الخارجية لتخزين البيانات، على سبيل المثال، Filecoin [85]، وبالتالي يمكن توصيل هذه الأنظمة بـ smart contracts. هذا الخيار على وجه الخصوص جذابة للبيانات المجمعة كوسيلة لمعالجة مشكلة "الانتفاخ" المنتشرة في العالم أنظمة blockchain. وبالتالي يمكن لـ DONs تخزين البيانات محليًا أو خارجيًا لاستخدامها في الخدمات المدعومة بشكل خاص. يمكن لـ DON أيضًا الاستفادة من هذه البيانات بطريقة سرية، الحوسبة على البيانات التي: (1) تمت مشاركتها بشكل سري عبر عقد DON أو مشفرة بموجب مفتاح تتم إدارته بواسطة العقد DON بطرق مناسبة للحساب الآمن متعدد الأطراف أو التشفير المتماثل الجزئي أو الكامل؛ أو (2) محمي باستخدام تنفيذ موثوق به بيئة. نتوقع أن يتبنى DONs نموذجًا بسيطًا لإدارة الذاكرة شائعًا أنظمة العقود الذكية: لا يجوز كتابة الملف القابل للتنفيذ إلا في ذاكرته الخاصة. الملفات التنفيذية ومع ذلك، يمكن قراءتها من ذاكرة الملفات التنفيذية الأخرى. راجع الملحق ب.3 لمزيد من التفاصيل حول تخزين DON. 3.4 إطار تنفيذ المعاملات (TEF) DONs تهدف إلى دعم العقود على سلسلة رئيسية MAINCHAIN (أو على سلاسل رئيسية متعددة). تمت مناقشة إطار تنفيذ المعاملات (TEF) بالتفصيلفي القسم 6، هو نهج للأغراض العامة للتنفيذ الفعال للعقد SC عبر MAINCHAIN وDON. والمقصود من TEF هو دعم الخدمة الثابتة الساتلية (FSS) والطبقة الثانية التقنيات - في وقت واحد، إذا رغبت في ذلك. في الواقع، من المرجح أن تكون بمثابة الوسيلة الرئيسية لاستخدام الخدمة الثابتة الساتلية (ولهذا السبب، فإننا لا نناقش الخدمة الثابتة الساتلية بشكل أكبر في هذا القسم). باختصار، في TEF، تم تصميم أو تطوير عقد SC الأصلي لـ MAINCHAIN يتم إعادة هيكلتها في عقد هجين. تنتج عملية إعادة البناء هذه العملين المتداخلين أجزاء من العقد المختلط: عقد MAINCHAIN SCa الذي نشير إليه للتوضيح في سياق TEFs كعقد أساسي وعقد تنفيذي قابل للتنفيذ على DON. ال يتولى عقد SCa حراسة أصول المستخدمين، وتنفيذ عمليات نقل الحالة الرسمية، وأيضًا يوفر قضبان حماية (انظر القسم 7.3) ضد الأعطال في DON. التنفيذيين القابل للتنفيذ تسلسل المعاملات ويوفر بيانات oracle المرتبطة بها. يمكن أن حزمة معاملات SCa بأي من الطرق العديدة - على سبيل المثال، باستخدام إثبات الصلاحية أو rollups متفائل، والتنفيذ السري بواسطة DON، وما إلى ذلك. نتوقع تطوير أدوات تسهل على المطورين تقسيم العقد SC مكتوبة بلغة عالية المستوى إلى أجزاء من منطق MAINCHAIN وDON وSCa و execs على التوالي، والتي يتم الإنشاء بشكل آمن وفعال. استخدام TEF لدمج أنظمة المعاملات عالية الأداء مع الأداء العالي يعد oracles جزءًا لا يتجزأ من نهجنا في التوسع oracle. 3.5 خدمات ميمبول إحدى ميزات طبقة التطبيق المهمة التي نعتزم نشرها على DONs لدعمها FSS وTEF هما خدمات Mempool (MS). يمكن النظر إلى MS كمحول، ولكن مع دعم من الدرجة الأولى. يوفر MS الدعم لمعالجة المعاملات المتوافقة مع التراث. في هذا الاستخدام، MS يستوعب من مجموعة ذكريات السلسلة الرئيسية تلك المعاملات المخصصة لعقد مستهدف SC على مينشين. يقوم MS بعد ذلك بتمرير هذه المعاملات إلى ملف قابل للتنفيذ على DON، حيث تتم معالجتها بالطريقة المطلوبة. يمكن استخدام بيانات MS بواسطة DON لإنشاء المعاملات التي يمكن بعد ذلك تمريرها مباشرة إلى SC من DON أو إلى عقد آخر يدعو SC. على سبيل المثال، يمكن لـ DON إعادة توجيه المعاملات يتم حصادها عبر MS، أو يمكنها استخدام بيانات MS لتحديد أسعار الغاز للمعاملات التي ترسلها مينشين. ولأنه يراقب مجمع الذاكرة، يستطيع MS الحصول على المعاملات من المستخدمين الذين يتفاعلون مباشرة مع SC. وبالتالي يمكن للمستخدمين الاستمرار في إنشاء معاملاتهم باستخدام البرامج القديمة، أي التطبيقات غير المدركة لوجود MS وMS العقود. (في هذه الحالة، يجب تغيير SC لتجاهل المعاملات الأصلية و تقبل فقط تلك التي تتم معالجتها بواسطة MS، وذلك لتجنب المعالجة المزدوجة.) للاستخدام مع العقد المستهدف SC، يمكن استخدام MS مع FSS و/أو TEF.3.6 نقطة الانطلاق: قدرات Chainlink الموجودة 3.6.1 التقارير خارج السلسلة (OCR) تعد التقارير خارج السلسلة (OCR) [60] آلية في Chainlink لتجميع التقارير oracle ونقلها إلى عقد معتمد SC. تم نشره مؤخرًا بسعر Chainlink شبكات التغذية، فهي تمثل خطوة أولى على الطريق إلى DONs الكاملة. في جوهره، يعد التعرف الضوئي على الحروف (OCR) بمثابة بروتوكول BFT مصمم للعمل بشكل متزامن جزئيًا شبكة. إنه يضمن الحيوية والصحة في وجود f < n/3 بشكل تعسفي العقد المعيبة التي تضمن خصائص البث البيزنطي الموثوق به، لكنها ليست كذلك بروتوكول إجماع BFT كامل. لا تحتفظ العقد بسجلات الرسائل الموجودة متسقة بمعنى تمثيل دفتر أستاذ متطابق في جميع وجهات نظرهم، ويجوز لقائد البروتوكول المراوغة دون انتهاك السلامة. تم تصميم تقنية التعرف الضوئي على الحروف (OCR) حاليًا لنوع معين من الرسائل: التجميع المتوسط لـ (على الأقل 2f +1) القيم التي أبلغت عنها العقد المشاركة. ويوفر ضمانًا أساسيًا بشأن وتسمى التقارير التي تخرجها لـ SC التقارير المعتمدة: القيمة المتوسطة في الشهادة التقرير يساوي أو يقع بين القيم التي تم الإبلاغ عنها بواسطة عقدتين صادقتين. هذه الخاصية شرط السلامة الرئيسي للتعرف الضوئي على الحروف. قد يكون للقائد بعض التأثير على الوسيط القيمة في تقرير مصدق، ولكن تخضع فقط لشرط الصحة هذا. يمكن التعرف الضوئي على الحروف يمكن توسيعها لتشمل أنواع الرسائل التي تجمع القيم بطرق مختلفة. في حين أن أهداف حيوية وصحة الشبكة Chainlink اليوم لا تتطلب ذلك نظرًا لأن تقنية التعرف الضوئي على الحروف (OCR) عبارة عن بروتوكول إجماع كامل، فإنها تتطلب تقنية التعرف الضوئي على الحروف (OCR) لتوفير بعض الأشكال الإضافية من الوظائف غير الموجودة في بروتوكولات BFT التقليدية، وأبرزها: 1. بث تقرير الكل أو لا شيء خارج السلسلة: يضمن التعرف الضوئي على الحروف (OCR) أن التقرير المصدق أصبح متاحًا بسرعة لجميع العقد الصادقة أو لا شيء منهم. هذا هو الإنصاف خاصية تساعد على ضمان حصول العقد الصادقة على فرصة المشاركة في نقل التقرير الموثق. 2. نقل موثوق: يضمن التعرف الضوئي على الحروف (OCR)، حتى في حالة وجود خلل أو ضار العقد، حيث يتم نقل جميع تقارير ورسائل التعرف الضوئي على الحروف إلى SC خلال فترة معينة، فترة زمنية محددة مسبقا. هذه خاصية حيوية. 3. تقليل الثقة على أساس العقد: تقوم SC بتصفية التقارير التي يحتمل أن تكون خاطئة من خلال التعرف الضوئي على الحروف، على سبيل المثال، إذا كانت قيمها المُبلغ عنها تنحرف بشكل كبير عن القيم الأخرى تلك التي تم استلامها مؤخرًا. يعد هذا أحد أشكال تطبيق صحة البروتوكول الإضافي. ستلعب كل هذه الخصائص الثلاثة دورًا طبيعيًا في DONs. يعد بث الكل أو لا شيء خارج السلسلة (DON) لبنة بناء مهمة لضمانات الاقتصاد المشفر حول ناقل الحركة الموثوق به، والذي يعد بدوره خاصية محول أساسية. الثقة إن التقليل في SC هو نوع من حاجز الحماية، كما تمت مناقشته في القسم 7.3. يوفر التعرف الضوئي على الحروف (OCR) أيضًا أساسًا للنشر التشغيلي وتحسين بروتوكولات BFT في شبكات oracle الخاصة بـ oracle وبالتالي، كما هو مذكور أعلاه، مسارًا إلى التنفيذ الكامل وظائف DONs.3.6.2 ديكو وتاون كريير DECO [234] وTown Crier [233] هما زوج من التقنيات ذات الصلة التي يتم حاليًا تطويرها تم تطويره في شبكات Chainlink. تسمح معظم خوادم الويب اليوم للمستخدمين بالاتصال عبر قناة آمنة باستخدام بروتوكول يُسمى أمان طبقة النقل (TLS) [94]. (HTTPS يشير إلى متغير HTTP الذي تم تمكينه باستخدام TLS، أي أن عناوين URL التي تسبقها "https" تشير إلى استخدام TLS للأمان.) على الرغم من ذلك، فإن معظم الخوادم التي تدعم TLS لديها قيود ملحوظة: فهي لا تقوم بالتوقيع رقميًا data. وبالتالي، لا يمكن للمستخدم أو المُثبت تقديم البيانات التي يتلقاها من الخادم إلى طرف ثالث أو جهة التحقق، مثل oracle أو smart contract، بطريقة تضمن صحة البيانات. وحتى لو قام الخادم بتوقيع البيانات رقميًا، تظل هناك مشكلة تتعلق بالسرية. قد يرغب المُثبت في تنقيح البيانات الحساسة أو تعديلها قبل تقديمها إلى أ المتحقق. ومع ذلك، تم تصميم التوقيعات الرقمية خصيصًا لإبطال البيانات المعدلة. وبالتالي، فإنها تمنع المُثبِّت من إجراء تعديلات للحفاظ على السرية إلى البيانات. (انظر القسم 7.1 لمزيد من المناقشة.) تم تصميم DECO وTown Crier للسماح للمثبت بالحصول على البيانات من الويب الخادم وتقديمها إلى جهة التحقق بطريقة تضمن النزاهة والسرية. يحافظ النظامان على النزاهة بمعنى أنهما يضمنان أن البيانات المقدمة من قبل ينشأ المثبت إلى المدقق بشكل أصلي من الخادم الهدف. إنهم يدعمون السرية بمعنى السماح للمحقق بتنقيح البيانات أو تعديلها (في حين لا يزال الحفاظ على النزاهة). الميزة الرئيسية لكلا النظامين هي أنهما لا يتطلبان أي تعديلات على أي منهما خادم الويب المستهدف. يمكنهم العمل مع أي خادم موجود يدعم TLS. في الواقع، فهي شفافة بالنسبة للخادم: من وجهة نظر الخادم، يكون Prover كذلك إنشاء اتصال عادي. لدى النظامين أهداف متشابهة، لكنهما يختلفان في نماذج الثقة وتطبيقاتهما كما نوضح الآن بإيجاز. يستخدم DECO بشكل أساسي بروتوكولات التشفير لتحقيق سلامته وخصائص السرية. أثناء إنشاء جلسة مع خادم مستهدف باستخدام DECO، يشارك Prover في نفس الوقت في بروتوكول تفاعلي مع المتحقق. يتيح هذا البروتوكول للمحقق أن يثبت للمدقق أنه قد استلمه جزء معين من البيانات D من الخادم أثناء جلسته الحالية. يستطيع البرهان وبدلاً من ذلك، قدم للمدقق دليلاً على عدم المعرفة ببعض خصائص D وبالتالي لا تكشف د مباشرة. في الاستخدام النموذجي لـ DECO، يمكن لمستخدم أو عقدة واحدة تصدير البيانات D من عقدة خاصة جلسة مع خادم الويب لجميع العقد في DON. ونتيجة لذلك، يمكن DON الكامل يشهد على صحة D (أو حقيقة مشتقة من D عبر إثبات المعرفة الصفرية). بالإضافة إلى أمثلة التطبيقات الواردة لاحقًا في هذه الورقة، يمكن أن تكون هذه الإمكانية يُستخدم لتضخيم الوصول عالي التكامل إلى مصدر البيانات بواسطة DON. حتى لو عقدة واحدة فقط لديه إمكانية الوصول المباشر إلى مصدر البيانات، على سبيل المثال، بسبب اتفاق حصري معه مزود البيانات - يظل من الممكن لـ DON بأكمله أن يشهد على صحةالتقارير المنبعثة من تلك العقدة. يعتمد Town Crier على استخدام بيئة تنفيذ موثوقة (TEE) مثل Intel سغس. باختصار، يعمل TEE كنوع من الصندوق الأسود الذي ينفذ التطبيقات في ملف واحد طريقة سرية ومضادة للتلاعب. من حيث المبدأ، حتى صاحب المضيف الذي لا يمكن لـ TEE قيد التشغيل (بشكل غير قابل للاكتشاف) تغيير تطبيق محمي بـ TEE ولا عرض حالة التطبيق، والتي قد تتضمن بيانات سرية. يمكن لـ Town Crier تحقيق جميع وظائف DECO والمزيد. يقيد DECO المُثبت على التفاعل مع مدقق واحد. في المقابل، تاون كراير تمكن مُثبت لإنشاء دليل يمكن التحقق منه بشكل عام على البيانات D التي تم جلبها من خادم مستهدف، أي دليل على أن أي شخص، حتى smart contract، يمكنه التحقق مباشرة. يستطيع تاون كريير وأيضًا استيعاب الأسرار واستخدامها بشكل آمن (على سبيل المثال، بيانات اعتماد المستخدم). القيد الرئيسي في Town Crier هو اعتمادها على TEEs. TEEs الإنتاج لديها وقد ثبت مؤخرًا أنها تحتوي على عدد من نقاط الضعف الخطيرة، على الرغم من أن التكنولوجيا لا تزال في مهدها وسوف تنضج بلا شك. انظر الملحقين B.2.1 وB.2.2 للاطلاع على مزيد من المناقشة حول TEEs. للحصول على بعض الأمثلة على تطبيقات DECO وTown Crier، راجع الأقسام 4.3 و4.5 و9.4.3 والملحق ج.1. 3.6.3 الخدمات الموجودة على السلسلة Chainlink توفر شبكات Chainlink oracle عددًا من الخدمات الرئيسية عبر عدد كبير من blockchains والأنظمة اللامركزية الأخرى اليوم. مزيد من التطور كما هو موضح في هذا المستند التقني، ستمنح هذه الخدمات الحالية إمكانات وميزات إضافية الوصول. ثلاثة أمثلة هي: خلاصات البيانات: اليوم، يعتمد غالبية مستخدمي Chainlink على smart contracts. استخدام خلاصات البيانات. هذه تقارير عن القيمة الحالية للأجزاء الرئيسية من البيانات وفقًا لذلك إلى مصادر موثوقة خارج السلسلة. على سبيل المثال، خلاصات الأسعار هي خلاصات تبلغ عن الأسعار الأصول - العملات المشفرة، والسلع، والعملات الأجنبية، والمؤشرات، والأسهم، وما إلى ذلك - وفقًا لـ خدمات التبادل أو تجميع البيانات. تساعد مثل هذه الخلاصات اليوم بالفعل في تأمين المليارات من الدولارات من القيمة على السلسلة من خلال استخدامها في أنظمة DeFi مثل Aave [147] و سينثيتيكس [208]. تتضمن الأمثلة الأخرى لخلاصات بيانات Chainlink بيانات الطقس لـ التأمين على المحاصيل البارامترية [75] وبيانات الانتخابات [93]، من بين عدد آخر. سيؤدي نشر DONs والتقنيات الأخرى الموضحة في هذه المقالة إلى تحسين توفير خلاصات البيانات في شبكات Chainlink بعدة طرق، بما في ذلك: • القياس: يهدف التعرف الضوئي على الحروف (OCR) ومن ثم DONs إلى تمكين خدمات Chainlink على نطاق واسع بشكل كبير عبر العديد من blockchains التي يدعمونها. على سبيل المثال، نتوقع أن DONs سيساعد في زيادة عدد خلاصات البيانات التي توفرها العقد التي تستخدمها Chainlink من 100 إلى 1000 وما بعدها. سيساعد هذا القياس Chainlink يحقق النظام البيئي هدفه المتمثل في توفير البيانات ذات الصلة بـ smart contracts بشكل شامل وتلبية وتوقع الاحتياجات الحالية والمستقبلية.• أمان محسّن: من خلال تخزين التقارير المتوسطة، سيحتفظ DONs بالسجلات سلوكيات العقدة لمراقبة عالية الدقة وقياس أدائها ودقتها، مما يتيح أسسًا تجريبية قوية لأنظمة السمعة للعقد Chainlink. وسيعمل FSS وTEF على تمكين دمج خلاصات الأسعار مع بيانات المعاملات بطرق مرنة تمنع الهجمات مثل التشغيل الأمامي. (صريح) staking سيعزز الحماية الاقتصادية المشفرة الحالية للأمن من خلاصات البيانات. • سرعة التغذية: نظرًا لأن blockchain أنظمة غير محددة (في الواقع، على نطاق أوسع، أنظمة غير محددة للمستهلك)، فإن DON يمكن أن تسهل توفير خلاصات البيانات لعدد كبير من الأشخاص من أنظمة الاعتماد. يمكن لـ DON واحد أن يدفع خلاصة معينة في وقت واحد إلى مجموعة من blockchains المختلفة، مما يلغي الحاجة إلى شبكات oracle لكل سلسلة و تمكين النشر السريع للخلاصات الموجودة على blockchains الجديدة والإضافية الخلاصات عبر blockchains التي تتم خدمتها حاليًا. • السرية: تتيح القدرة على إجراء عمليات حسابية معممة في DON إجراء العمليات الحسابية على البيانات الحساسة خارج السلسلة، مما يتجنب إجراء العمليات الحسابية على السلسلة التعرض. بالإضافة إلى ذلك، باستخدام DECO أو Town Crier، من الممكن تحقيقه وسرية أكبر، مما يسمح بإنشاء التقارير بناءً على بيانات غير موجودة يتعرض حتى لعقد DON. انظر القسم 4.3 والقسم 4.5 للحصول على أمثلة. وظائف عشوائية يمكن التحقق منها (VRFs): تتطلب العديد من أنواع التطبيقات اللامركزية (DApps) مصدرًا عشوائيًا صحيحًا يمكن التحقق منه لتمكين التحقق من عملها العادل. تعتبر الرموز غير القابلة للاستبدال (NFTs) مثالاً على ذلك. يتم تحديد ندرة ميزات NFT في Aavegotchi [23] وAxie Infinity [35] بواسطة Chainlink VRF، كما هو الحال مع التوزيع من NFTs عن طريق الرسومات المستندة إلى التذاكر في بطاقات الأثير [102]؛ مجموعة واسعة من تطبيقات الألعاب اللامركزية التي تكون نتائجها عشوائية؛ والأدوات المالية غير التقليدية، على سبيل المثال، ألعاب الادخار بدون خسارة مثل PoolTogether [89]، والتي تخصص الأموال الفائزين عشوائي. تتطلب التطبيقات الأخرى blockchain وغير blockchain أيضًا أمانًا مصادر العشوائية، بما في ذلك اختيار لجان النظام اللامركزي و تنفيذ اليانصيب. على الرغم من أن الكتلة hashes يمكن أن تكون بمثابة مصدر للعشوائية التي لا يمكن التنبؤ بها، إلا أنها عرضة للتلاعب من قبل القائمين بالتعدين المنافسين (وإلى حد ما من قبل المستخدمين الذين يرسلون المعاملات). يقدم Chainlink VRF [78] بديلاً أكثر أمانًا إلى حد كبير. ان يحتوي oracle على زوج مفاتيح خاص/عام مرتبط (sk, pk) يتم الاحتفاظ بمفتاحه الخاص خارج السلسلة ويتم نشر مفتاحه العام pk. لإخراج قيمة عشوائية، فإنه يطبق sk على بذرة x غير متوقعة مقدمة من عقد الاعتماد (على سبيل المثال، كتلة hash) والمعلمات الخاصة بـ DApp) باستخدام الدالة F، مما يؤدي إلى y = Fsk(x) مع a دليل على صحة. (راجع [180] للتعرف على VRF المتوفر على Chainlink.) ما الذي يجعل VRF الذي يمكن التحقق منه هو حقيقة أنه من خلال معرفة pk، من الممكن التحقق من صحة الدليل وبالتالي صحة y. وبالتالي فإن القيمة y لا يمكن التنبؤ بها بالنسبة لـ an خصم لا يمكنه التنبؤ بـ x أو تعلم sk ولا يمكن للخدمة التلاعب به.Chainlink يمكن النظر إلى VRF على أنه مجرد واحد من مجموعة من التطبيقات التي تتضمن رعاية المفاتيح الخاصة خارج السلسلة. وبشكل أكثر عمومية، يمكن لـ DONs توفير الأمان، التخزين اللامركزي للمفاتيح الفردية للتطبيقات و/أو المستخدمين والجمع بينها هذه القدرة مع الحساب المعمم. والنتيجة هي مجموعة من التطبيقات، من والتي نعطيها بعض الأمثلة في هذه الورقة، بما في ذلك الإدارة الرئيسية لإثبات الاحتياطيات (انظر القسم 4.1) وبالنسبة لبيانات الاعتماد اللامركزية للمستخدمين (وغيرها من البيانات الرقمية). الأصول) (انظر القسم 4.3). الحراس: Chainlink Keepers [87] يمكّن المطورين من كتابة التعليمات البرمجية للأنظمة اللامركزية تنفيذ المهام خارج السلسلة، بشكل عام لتحفيز تنفيذ الاعتماد على smart contracts. قبل ظهور Keepers، كان من الشائع بالنسبة للمطورين تشغيل مثل هذه الخدمات خارج السلسلة المنطق نفسه، مما يخلق نقاط فشل مركزية (فضلاً عن جهود تطوير مكررة كبيرة). يوفر Keepers بدلاً من ذلك إطار عمل سهل الاستخدام لـ الاستعانة بمصادر خارجية لامركزية لهذه العمليات، مما يتيح دورات تطوير أقصر و ضمان قوي للحيوية والخصائص الأمنية الأخرى. يمكن للحافظين دعم أي لمجموعة واسعة من الأهداف المحفزة، بما في ذلك تصفية القروض المعتمدة على السعر أو تنفيذ المعاملات المالية، وبدء عمليات الإنزال الجوي أو المدفوعات التي تعتمد على الوقت في الأنظمة التي تعتمد على حصاد المحصول، وما إلى ذلك. في إطار عمل DON، يمكن النظر إلى البادئين على أنهم تعميم لـ Keepers بعدة معانٍ. يمكن للبادئين الاستفادة من المحولات، وبالتالي يمكنهم الاستفادة من أ مكتبة نمطية من الواجهات للأنظمة الموجودة على السلسلة وخارجها، مما يسمح بسرعة تطوير وظائف آمنة ومتطورة. يبدأ المبادرون الحساب في الملفات التنفيذية، والتي توفر بحد ذاتها التنوع الكامل لـ DONs، مما يسمح بالنطاق الواسع مجموعة من الخدمات اللامركزية التي نقدمها في هذه الورقة للتطبيقات المتصلة بالسلسلة وخارجها. 3.6.4 سمعة العقدة / تاريخ الأداء يوثق النظام البيئي الحالي Chainlink أصلاً تاريخ أداء العقد المساهمة على السلسلة. وقد أدت هذه الميزة إلى ظهور مجموعة من الموارد الموجهة نحو السمعة والتي تستوعب بيانات الأداء وتصفيتها وتصورها على الأفراد. مشغلي العقدة وخلاصات البيانات. يمكن للمستخدمين الرجوع إلى هذه الموارد لجعلها على علم اتخاذ القرارات في اختيار العقد ومراقبة تشغيل الشبكات الحالية. ستساعد الإمكانيات المماثلة المستخدمين على اختيار DONs. على سبيل المثال، تسمح الأسواق غير المسموح بها اليوم مثلmarket.link بالعقدة يقوم المشغلون بإدراج خدمات oracle الخاصة بهم والشهادة على هوياتهم خارج السلسلة من خلال خدمات مثل Keybase [4]، والتي تربط ملف تعريف العقدة في Chainlink بـها أسماء النطاقات الحالية للمالك وحسابات الوسائط الاجتماعية. بالإضافة إلى ذلك، الأداء تسمح أدوات التحليلات، مثل تلك المتاحة علىmarket.link وreputation.link للمستخدمين لعرض إحصائيات حول الأداء التاريخي للعقد الفردية، بما في ذلك متوسط زمن الاستجابة، وانحراف القيم في تقاريرهم عن القيم المتفق عليها يتم ترحيلها على السلسلة، والإيرادات المولدة، والوظائف التي تم إنجازها، والمزيد. أدوات التحليل هذه أيضًا السماح للمستخدمين بتتبع اعتماد شبكات oracle المختلفة من قبل مستخدمين آخرين، وهو شكل من أشكالتأييد ضمني للعقد التي تؤمن هذه الشبكات. والنتيجة هي "شبكة مسطحة من". الثقة" التي يتم من خلالها إنشاء تطبيقات لامركزية عالية القيمة باستخدام عقد معينة إشارة إلى ثقتهم في تلك العقد التي يمكن للمستخدمين الآخرين مراقبتها وأخذها في الاعتبار قرارات اختيار العقدة الخاصة. مع DONs (وفي البداية مع التعرف الضوئي على الحروف) يأتي تحول في معالجة المعاملات و نشاط العقد بشكل عام خارج السلسلة. نموذج لامركزي لتسجيل العقدة يظل الأداء ممكنًا داخل DON نفسه. والواقع أن الأداء العالي وسعة البيانات DONs تجعل من الممكن إنشاء سجلات بطريقة دقيقة الطريقة وأيضًا لإجراء عمليات حسابية لا مركزية على هذه السجلات، مما ينتج عنه ملخصات جديرة بالثقة يمكن أن تستهلكها خدمات السمعة ويتم فحصها مينشين. في حين أنه من الممكن أن يقوم DON من حيث المبدأ بتحريف سلوك العقد المكونة في حالة تلف جزء كبير من العقد، إلا أننا نلاحظ أن المجموعة أداء DON نفسه في تقديم البيانات على السلسلة مرئي على MAINCHAIN وبالتالي لا يمكن تحريفها. بالإضافة إلى ذلك، نحن نخطط لاستكشاف الآليات التي تحفيز إعداد تقارير داخلية دقيقة عن سلوكيات العقدة في DON. على سبيل المثال، من خلال الإبلاغ عن المجموعة الفرعية من العقد عالية الأداء التي تقوم بإرجاع البيانات المساهمة بشكل أسرع إلى تقرير تم ترحيله على السلسلة، يُنشئ DON حافزًا للعقد للاعتراض على الخطأ التقارير: تضمين العقد بشكل غير صحيح في هذه المجموعة الفرعية يعني استبعاد العقد بشكل غير صحيح كان ينبغي إدراجها وبالتالي معاقبتهم بشكل غير صحيح. سيؤدي فشل الإبلاغ المتكرر بواسطة DON أيضًا إلى خلق حافز للعقد الصادقة لمغادرة DON. التجميع اللامركزي لسجلات الأداء الدقيقة وما يترتب على ذلك قدرة المستخدمين على تحديد العقد عالية الأداء ومشغلي العقد للبناء تعد السمعة من السمات المميزة المهمة للنظام البيئي Chainlink. نحن أظهر في القسم 9 كيف يمكننا التفكير فيها باعتبارها جزءًا أساسيًا من خطة صارمة ودقيقة نظرة موسعة للأمن الاقتصادي الذي توفره DONs.

الخدمات اللامركزية التي تم تمكينها من خلال اللامركزية

شبكات أوراكل لتوضيح مدى تعدد استخدامات DONs وكيفية تمكينها لمجموعة من الخدمات الجديدة، نقدم خمسة أمثلة للتطبيقات المستندة إلى DON في هذا القسم ونصفها العقود الهجينة التي تحققها: (1) إثبات الاحتياطيات، وهو شكل من أشكال الخدمة عبر السلسلة؛ (2) التفاعل مع أنظمة المؤسسة/الأنظمة القديمة، أي إنشاء نظام قائم على البرمجيات الوسيطة طبقة تجريد تسهل تطوير تطبيقات blockchain بأقل قدر ممكن blockchain-رمز أو خبرة محددة؛ (3) الهوية اللامركزية، الأدوات التي تمكن المستخدمين من ذلك الحصول على وثائق الهوية وبيانات الاعتماد الخاصة بهم وإدارتها؛ (4) القنوات ذات الأولوية، خدمة تضمن تضمين معاملات البنية التحتية الحيوية في الوقت المناسب (على سبيل المثال، oracle التقارير) على blockchain؛ و(5) الحفاظ على السرية DeFi، أي الشؤون المالية smart contracts التي تخفي البيانات الحساسة للأطراف المشاركة. هنا، نحن

استخدم SC للإشارة إلى جزء MAINCHAIN من العقد المختلط ووصف DON مكون بشكل منفصل أو من حيث exec القابل للتنفيذ. 4.1 إثبات الاحتياطيات بالنسبة للعديد من التطبيقات، من المفيد ترحيل الحالة بين أو بين blockchains. أ التطبيق الشائع لمثل هذه الخدمات هو تغليف العملات المشفرة. عملات ملفوفة من هذا القبيل نظرًا لأن WBTC [15] أصبحت أحد الأصول الشائعة في التمويل اللامركزي (DeFi). هم تتضمن إيداع الأصل الداعم "المغلف" على مصدره blockchain MAINCHAIN(1) وإنشاء token مطابق على هدف مختلف blockchain MAINCHAIN(2). على سبيل المثال، WBTC هو ERC20 token على Ethereum blockchain الذي يتوافق إلى BTC على Bitcoin blockchain. نظرًا لأن العقود الموجودة على MAINCHAIN(2) ليس لها رؤية مباشرة في MAINCHAIN(1)، يجب عليهم الاعتماد صراحةً أو ضمنًا على oracle للإبلاغ عن رواسب التغليف الأصل في smart contract، مما يؤدي إلى إنتاج ما يسمى أحيانًا إثبات الاحتياطيات. في WBTC [15]، على سبيل المثال، يحتفظ الحافظ BitGo بـ BTC ويصدر WBTC، مع Chainlink شبكة تقدم إثباتات الاحتياطي [76]. يمكن لـ DON أن يقدم في حد ذاته إثباتًا للاحتياطيات. مع DON، فمن الممكن للذهاب أبعد من ذلك. يستطيع DON إدارة الأسرار، ومن خلال استخدام المحولات المناسبة، يمكن التعامل على أي blockchain المطلوب. وبالتالي، من الممكن أن يقوم DON بالتصرف كواحد من بين عدد من أمناء الحفظ - أو حتى كوصي وحيد لا مركزي - لـ أصل ملفوف. وبالتالي يمكن أن يكون DONs بمثابة منصة لتعزيز أمان الخدمات الحالية التي تستخدم إثباتات الاحتياطيات. على سبيل المثال، لنفترض أن MAINCHAIN(1) هو Bitcoin وأن MAINCHAIN(2) هو Ethereum. في MAINCHAIN(2)، يصدر عقد SC tokens الذي يمثل BTC المغلف. DON يتحكم في عنوان عنوان BTC(1) DON. لتغليف BTC، يرسل المستخدم U X BTC منه العنوان(1) ش إلى العنوان (1) DON مع عنوان العنوان الرئيسي (2) MAINCHAIN(2)(2) ش . شاشات DON العنوان(1) DON عبر محول إلى MAINCHAIN(1). عند ملاحظة إيداع U، مع تأكيد عالي الاحتمال بدرجة كافية، فإنه يرسل رسالة إلى SC عبر محول إلى مينشين(2). توجه هذه الرسالة SC إلى سك X tokens لـ addr(2) ش . لكي تقوم U بإصدار X tokens، يحدث العكس. على MAINCHAIN(1)، ومع ذلك، العنوان(1) DON يرسل X BTC إلى العنوان(1) U (أو إلى عنوان آخر، إذا طلب المستخدم ذلك). يمكن بالطبع تكييف هذه البروتوكولات للعمل مع البورصات، وليس بشكل مباشر مع المستخدمين. 4.2 التفاعل مع أنظمة المؤسسات / الأنظمة القديمة يمكن أن تكون DONs بمثابة جسور بين blockchains وفيما بينها، كما في مثال الإثبات من الاحتياطيات، ولكن الهدف الآخر هو أن تكون بمثابة جسور ثنائية الاتجاه بينهما blockchains والأنظمة القديمة [176] أو blockchain الأنظمة المشابهة مثل البنك المركزي العملات الرقمية [30]. تواجه الشركات عددًا من التحديات في ربط أنظمتها الحالية و العمليات للأنظمة اللامركزية، بما في ذلك:• مرونة سلسلة الكتل: تتغير أنظمة سلسلة الكتل بسرعة. قد تواجه المؤسسة المظهر الجديد السريع أو ترتفع شعبيتها blockchains يرغب الأطراف المقابلة في إجراء المعاملات، ولكن ليس لدى المؤسسة أي منها الدعم في البنية التحتية القائمة. بشكل عام، ديناميكية blockchains هي التي تصنع فمن الصعب على المؤسسات الفردية أن تظل على اطلاع على النظام البيئي الكامل. • موارد التطوير الخاصة بـ Blockchain: بالنسبة للعديد من المؤسسات، يعد توظيف أو احتضان الخبرات المتطورة blockchain أمرًا صعبًا، لا سيما في ضوء تحدي خفة الحركة. • إدارة المفتاح الخاص: تتطلب إدارة المفاتيح الخاصة لـ blockchain أو العملات المشفرة خبرة تشغيلية متميزة عن تلك الخاصة بالأمن السيبراني التقليدي الممارسات وغير متاحة للعديد من الشركات. • السرية: تخشى الشركات الكشف عن معلوماتها الحساسة وملكيتها البيانات على السلسلة. لمعالجة الثلاثة الأولى من هذه الصعوبات، يمكن للمطورين ببساطة استخدام DON كطبقة وسيطة آمنة لتمكين أنظمة المؤسسة من القراءة منها أو الكتابة إليها blockchains. يمكن لـ DON تجريد الاعتبارات الفنية التفصيلية مثل ديناميكيات الغاز، وإعادة تنظيم السلسلة، وما إلى ذلك، لكل من المطورين والمستخدمين. بواسطة من خلال تقديم واجهة blockchain مبسطة لأنظمة المؤسسة، يمكن لـ DON بالتالي تبسيط عملية تطوير تطبيقات المؤسسات المدركة blockchain إلى حد كبير، مما يزيل العبء عن المؤسسات المتمثل في الحصول على موارد التطوير المحددة أو احتضانها blockchain. يعد هذا الاستخدام لـ DONs جذابًا بشكل خاص لأنه يمكّن مطوري المؤسسات من ذلك إنشاء تطبيقات العقود الذكية التي تكون blockchain حيادية إلى حد كبير. ونتيجة لذلك، أكبر مجموعة blockchains التي تم تجهيز DON لها لتكون بمثابة برامج وسيطة، أكبر مجموعة blockchains التي يمكن لمستخدمي المؤسسة الوصول إليها بسهولة. المطورين يمكن نقل التطبيقات من blockchains الموجودة إلى تطبيقات جديدة بأقل قدر من التعديل لتطبيقاتهم المطورة داخليًا. ولمعالجة المشكلة الإضافية المتعلقة بالسرية، يمكن للمطورين اللجوء إلى الأدوات التي نقدمها في هذه الورقة ونتوقع نشرها لدعم تطبيقات DON. وتشمل هذه DECO وTown Crier القسم 3.6.2 بالإضافة إلى الحفاظ على السرية تعديلات واجهة برمجة التطبيقات (API) التي تمت مناقشتها في القسم 7.1.2 وعدد من الأساليب الخاصة بالتطبيقات التي تمت تغطيتها في الجزء المتبقي من هذا القسم. يمكن أن توفر أنظمة DON هذه شهادات عالية النزاهة على السلسلة حول حالة نظام المؤسسة دون الكشف عنها بيانات مصدر المؤسسة الحساسة على السلسلة. 4.3 الهوية اللامركزية الهوية اللامركزية هي مصطلح عام لفكرة أن المستخدمين يجب أن يكونوا قادرين على ذلك الحصول على بيانات الاعتماد الخاصة بهم وإدارتها، بدلاً من الاعتماد على أطراف ثالثة للقيام بذلك هكذا. أوراق الاعتماد اللامركزية هي شهادات على سمات أو تأكيدات صاحبها،والتي غالبا ما تسمى المطالبات. يتم توقيع بيانات الاعتماد رقميًا من قبل الكيانات، والتي غالبًا ما تسمى المصدرون، الذين يمكنهم ربط المطالبات بشكل رسمي بالمستخدمين. في معظم المخططات المقترحة، ترتبط المطالبات بمعرف لامركزي (DID)، وهو معرف عالمي لـ مستخدم معين. ترتبط بيانات الاعتماد بمفتاح عام يحمل المستخدم مفتاحه الخاص. وبالتالي يمكن للمستخدم إثبات حيازة المطالبة باستخدام مفتاحه الخاص. الرؤية باعتبارها هوية لامركزية هي المخططات الحالية والمقترحة، على سبيل المثال، [14، 92، 129، 216]، لها ثلاثة قيود شديدة: • عدم التوافق مع التراث: تعتمد أنظمة الهوية اللامركزية الحالية على أ مجتمع السلطات، الذي يطلق عليه جهات الإصدار، لإنتاج بيانات اعتماد DID. لان لا تقوم خدمات الويب الحالية عمومًا بتوقيع البيانات رقميًا، ويجب إطلاق جهات الإصدار كأنظمة ذات أغراض خاصة. لأنه لا يوجد حافز للقيام بذلك دون النظام البيئي اللامركزي للهوية، ينتج عنه مشكلة الدجاجة والبيضة. في غيرها بعبارة أخرى، من غير الواضح كيفية تمهيد النظام البيئي للمصدر. • إدارة المفاتيح غير العملية: تتطلب أنظمة الهوية اللامركزية من المستخدمين القيام بذلك إدارة المفاتيح الخاصة، وهو ما أظهرته تجربة العملات المشفرة ليكون عبئا غير عملي. تشير التقديرات إلى وجود حوالي 4,000,000 Bitcoin فقدت إلى الأبد بسبب فشل إدارة المفاتيح [194]، ويقوم العديد من المستخدمين بتخزين ملفاتهم الأصول المشفرة مع البورصات [193]، مما يقوض اللامركزية. • عدم وجود مقاومة Sybil للحفاظ على الخصوصية: أحد المتطلبات الأمنية الأساسية للتطبيقات مثل التصويت، والتخصيص العادل لـ tokens خلال مبيعات token، وما إلى ذلك هو أن لا يتمكن المستخدمون من تأكيد هويات متعددة. تتطلب مقترحات الهوية اللامركزية الحالية من المستخدمين الكشف عن هوياتهم الحقيقية من أجل تحقيق ذلك مقاومة Sybil، مما يقوض ضمانات الخصوصية المهمة. من الممكن معالجة هذه المشكلات باستخدام مجموعة من لجنة العقد إجراء عمليات حسابية موزعة داخل DON واستخدام أدوات مثل DECO أو Town Crier، كما هو موضح في نظام يسمى CanDID [160]. يمكن لـ DECO أو Town Crier حسب التصميم تشغيل خدمات الويب الحالية دون تعديل إلى جهات إصدار أوراق الاعتماد التي تحافظ على السرية. إنها تمكن DON من التصدير ذات الصلة البيانات لهذا الغرض إلى بيانات اعتماد مع إخفاء البيانات الحساسة التي لا ينبغي ذلك تظهر في بيانات الاعتماد. بالإضافة إلى ذلك، لتسهيل استرداد المفاتيح للمستخدمين، وبالتالي معالجة إدارة المفاتيح المشكلة، DON يمكن أن يسمح للمستخدمين بتخزين المفاتيح الخاصة في نموذج مشترك سري. يمكن للمستخدمين استعادة مفاتيحهم عن طريق إثبات العقد الموجودة في DON - وبالمثل، باستخدام Town Crier أو DECO - القدرة على تسجيل الدخول إلى الحسابات مع مجموعة من موفري الويب المحددين مسبقًا (على سبيل المثال، تويتر، جوجل، فيسبوك). فائدة استخدام Town Crier أو DECO، بدلاً من OAUTH، هي خصوصية المستخدم. تمكّن هاتان الأداتان المستخدم من تجنب الكشف لـ DON معرف مزود الويب - والذي غالبًا ما يمكن استخلاص هويات العالم الحقيقي منه. أخيرًا، لتوفير مقاومة Sybil، كما هو موضح في [160]، من الممكن لـ DON أن إجراء تحويل للحفاظ على الخصوصية لمعرفات العالم الحقيقي الفريدة للمستخدمين (على سبيل المثال، أرقام الضمان الاجتماعي (SSNs)) في المعرفات الموجودة على السلسلة عند تسجيل المستخدم.وبالتالي يمكن للنظام اكتشاف التسجيلات المكررة بدون بيانات حساسة مثل يتم الكشف عن أرقام الضمان الاجتماعي إلى العقد الفردية DON.7 يمكن لـ DON تقديم أي من هذه الخدمات نيابة عن الهوية اللامركزية الخارجية الأنظمة الموجودة على blockchains غير المسموح بها أو المسموح بها، على سبيل المثال، مثيلات Hyperledger إندي [129]. مثال للتطبيق: KYC: الهوية اللامركزية تبشر بالخير كوسيلة لتحقيق ذلك تبسيط متطلبات التطبيقات المالية على blockchains مع تحسين المستخدم الخصوصية. هناك تحديان يمكن أن تساعد في معالجتهما، وهما التزامات الاعتماد والامتثال بموجب لوائح مكافحة غسل الأموال / معرفة عميلك (AML / KYC). تتطلب لوائح مكافحة غسل الأموال في العديد من البلدان من المؤسسات المالية (وغيرها من الشركات) تحديد هويات الأفراد والشركات التي تتعامل معها والتحقق منها. يقومون بالمعاملات. يشكل "اعرف عميلك" (KYC) أحد مكونات المؤسسة المالية سياسة مكافحة غسيل الأموال الأوسع نطاقًا، والتي تتضمن أيضًا عادةً مراقبة سلوكيات المستخدم ومراقبة تدفقات الأموال، من بين أمور أخرى. تتضمن عملية اعرف عميلك (KYC) عادةً تقديم المستخدم لبيانات اعتماد الهوية بشكل ما (على سبيل المثال، الدخول إلى نموذج ويب عبر الإنترنت، مع رفع وثيقة هوية أمام وجه المستخدم في جلسة فيديو، وما إلى ذلك). تأمين إنشاء وعرض بيانات الاعتماد اللامركزية يمكن من حيث المبدأ أن يكون بديلاً مفيدًا في عدة جوانب، وبالتحديد من خلال: (1) التصنيع تعتبر عملية "اعرف عميلك" (KYC) أكثر كفاءة للمستخدمين والمؤسسات المالية، لأنه بمجرد وبعد الحصول على بيانات الاعتماد، يمكن تقديمها بسهولة إلى أي مؤسسة مالية؛ (2) الحد من الاحتيال عن طريق تقليل فرص سرقة الهوية من خلال التسوية ومعلومات التعريف الشخصية (PII) والانتحال أثناء التحقق بالفيديو؛ و (3) تقليل مخاطر تعرض معلومات تحديد الهوية الشخصية للخطر في المؤسسات المالية، مع احتفاظ المستخدمين بالسيطرة من بياناتهم الخاصة. ونظراً للعقوبات التي تبلغ مليارات الدولارات والتي تدفعها المؤسسات المالية بسبب الإخفاق في الامتثال لمكافحة غسل الأموال، وإنفاق العديد من المؤسسات المالية ملايين الدولارات سنوياً على "اعرف عميلك"، فإن التحسينات يمكن أن تحقق وفورات كبيرة للمؤسسات المالية وبالتالي، للمستهلكين [196]. في حين أن القطاع المالي التقليدي بطيء لاعتماد أدوات امتثال جديدة، تتبنى أنظمة DeFi هذه الأداة بشكل متزايد [43]. مثال على التطبيق: القروض غير المضمونة: معظم تطبيقات DeFi التي دعم الإقراض اليوم تنشأ فقط القروض المضمونة بالكامل. هذه هي القروض المقدمة للمقترضين الذين يقومون بإيداع أصول العملات المشفرة بقيمة تتجاوز قيمة القروض. لقد نشأ الاهتمام مؤخرًا بما يشير إليه مجتمع DeFi عمومًا بالقروض غير المضمونة. هذه، على النقيض من ذلك، هي القروض التي لها ضمانات المقابلة أن تكون قيمته أقل من أصل القرض. القروض غير المضمونة تشبه القروض التي غالبا ما تقدمها المؤسسات المالية التقليدية. بدلا من الاعتماد على الضمانات المودعة كضمان لسداد القرض، فإنهم بدلاً من ذلك يعتمدون على الإقراض القرارات المتعلقة بالتاريخ الائتماني للمقترضين. 7 يعتمد هذا التحويل على دالة عشوائية زائفة موزعة (PRF).تشكل القروض غير المضمونة جزءًا ناشئًا ولكنه متنامي من سوق الإقراض DeFi. وهي تعتمد على آليات مثل تلك التي تستخدمها المؤسسات المالية التقليدية المؤسسات، مثل العقود القانونية [91]. مطلب أساسي لنموهم ستكون القدرة على تقديم بيانات حول الجدارة الائتمانية للمستخدم - وهو عامل رئيسي في قرارات الإقراض التقليدية - لأنظمة DeFi بطريقة توفر نزاهة قوية، على سبيل المثال، ضمان البيانات الصحيحة. إن نظام الهوية اللامركزي الذي يدعم DON سيمكن المقترضين المحتملين من إنشاء بيانات اعتماد عالية الضمان تشهد على جدارتها الائتمانية مع الحفاظ عليها سرية المعلومات الحساسة. وعلى وجه التحديد، يمكن للمقترضين إنشاء هذه تعتمد بيانات الاعتماد على سجلات من مصادر موثوقة عبر الإنترنت مع الكشف فقط عن البيانات الموثقة بواسطة DON، دون الكشف عن بيانات أخرى قد تكون حساسة. ل على سبيل المثال، يمكن للمقترض إنشاء بيانات اعتماد تشير إلى أن درجة الائتمان الخاصة به تبلغ درجة تتجاوز مجموعة مكاتب الائتمان حدًا معينًا (على سبيل المثال، 750)، دون الكشف عنها النتيجة الدقيقة أو أي بيانات أخرى في سجلاتها. بالإضافة إلى ذلك، إذا رغبت في ذلك، أوراق الاعتماد هذه يمكن إنشاؤها بشكل مجهول، أي أنه يمكن التعامل مع اسم المستخدم على أنه بيانات حساسة وهي نفسها غير معرضة للعقد oracle أو في بيانات اعتمادها اللامركزية. الاعتماد نفسها يمكن استخدامها على السلسلة أو خارج السلسلة، اعتمادًا على التطبيق. باختصار، يمكن للمقترض تقديم معلومات أساسية للمقرضين بشأن ائتمانهم تاريخ يتمتع بنزاهة قوية ودون التعرض لخطر التعرض لأشياء حساسة وغير ضرورية data. ويمكن للمقترض أيضًا تقديم مجموعة متنوعة من بيانات الاعتماد الأخرى التي تحافظ على السرية مفيدة في اتخاذ قرارات الإقراض. على سبيل المثال، يمكن أن تشهد بيانات الاعتماد على المقترض حيازة الأصول (خارج السلسلة)، كما نوضح في مثالنا التالي. مثال على التطبيق: الاعتماد: تحدد العديد من الولايات القضائية فئة المستثمر التي يمكن بيع الأوراق المالية غير المسجلة لها. على سبيل المثال، في الولايات المتحدة، SEC تنص اللائحة د على أنه لكي يتم اعتمادك لمثل هذه الفرص الاستثمارية، أ يجب أن يمتلك الفرد قيمة صافية قدرها مليون دولار، أو يستوفي بعض متطلبات الحد الأدنى للدخل، أو أن يكون لديه مؤهلات مهنية معينة [209، 210]. الاعتماد الحالي العمليات مرهقة وغير فعالة، وغالبًا ما تتطلب خطاب تصديق من محاسب أو ما شابه ذلك. سيمكن نظام الهوية اللامركزي المستخدمين من إنشاء بيانات الاعتماد من حسابات الخدمات المالية الحالية عبر الإنترنت التي تثبت الامتثال للاعتماد اللوائح التنظيمية، وتسهيل عملية "اعرف عميلك" (KYC) الأكثر كفاءة والحفاظ على الخصوصية. ال علاوة على ذلك، فإن خصائص الحفاظ على الخصوصية الخاصة بـ DECO وTown Crier، ستسمح بذلك سيتم إنشاء بيانات الاعتماد مع ضمان قوي بالنزاهة دون الكشف بشكل مباشر عن تفاصيل الوضع المالي للمستخدم. على سبيل المثال، يمكن للمستخدم إنشاء بيانات اعتماد إثبات أن ثروتها الصافية لا تقل عن مليون دولار دون الكشف عن أي مبلغ إضافي معلومات عن وضعها المالي. 4.4 القنوات ذات الأولوية تعتبر القنوات ذات الأولوية خدمة جديدة مفيدة يسهل إنشاؤها باستخدام DON. بهم

الهدف هو تقديم معاملات مختارة وذات أولوية عالية في الوقت المناسب على MAINCHAIN خلال فترات ازدحام الشبكة. يمكن النظر إلى القنوات ذات الأولوية كشكل من أشكال العقود الآجلة على مساحة الكتلة وبالتالي كسلعة مشفرة، وهو مصطلح تمت صياغته كجزء لمشروع شيكاغو [61، 136]. القنوات ذات الأولوية مخصصة خصيصًا للقائمين بالتعدين لتمكين خدمات البنية التحتية، مثل oracles، ووظائف إدارة العقود، وما إلى ذلك - وليس للأنشطة العادية على مستوى المستخدم مثل المعاملات المالية. في الواقع، كما هو مصمم هنا، أولوية يمكن تنفيذ القناة بأقل من 100% من طاقة التعدين في الشبكة فقط توفر حدودًا فضفاضة على أوقات التسليم، مما يمنع استخدامها بشكل كبير يعتمد على السرعة أهداف مثل الجري الأمامي. الشكل 10: القناة ذات الأولوية هي ضمان من قبل عامل التعدين M - أو بشكل عام أ مجموعة من عمال المناجم M—إلى المستخدم U الذي سيتم تعدين معاملته τ ضمن الكتل D من التضمين في mempool. يمكن لعقد SC استخدام مراقبة DON لفرض شروط خدمة القناة. تأخذ القناة ذات الأولوية شكل اتفاقية بين القائم بالتعدين أو مجموعة من المعدنين (أو مجمعات التعدين) M التي توفر القناة والمستخدم U الذي يدفع رسوم الوصول. يوافق M على أنه عندما يرسل U معاملة τ إلى مجموعة الذاكرة (مع أي سعر للغاز،ولكن بحد الغاز المتفق عليه مسبقًا)، سيضعه M على السلسلة ضمن الكتل D التالية.8 تم توضيح الفكرة بشكل تخطيطي في الشكل 10. وصف عقد قناة الأولوية: يمكن تحقيق القناة ذات الأولوية باعتبارها الهجين smart contract تقريبًا على النحو التالي. نسمح لـ SC بالإشارة إلى المنطق الموجود على MAINCHAIN وذلك على DON بواسطة exec. تقبل SC إيداعًا/حصة \(d from M and an advance payment \)p من الولايات المتحدة DON يقوم exec القابل للتنفيذ بمراقبة مجمع الذاكرة، مما يؤدي إلى تشغيل المعاملة بواسطة U. يرسل رسالة نجاح إلى SC إذا أرسل U معاملة قام M بالتنقيب فيها طريقة في الوقت المناسب ورسالة فشل في حالة فشل الخدمة. ترسل SC الدفع $p إلى M مع إعطاء رسالة نجاح وترسل جميع الأموال المتبقية، بما في ذلك $d، إلى U إذا تلقى رسالة فشل. عند الإنهاء الناجح، فإنه إيداع الإصدارات $d إلى M. يمكن لعامل التعدين M بالطبع توفير قنوات ذات أولوية متعددة في وقت واحد المستخدمين ويمكنهم فتح قناة ذات أولوية مع U لعدد متفق عليه مسبقًا من الرسائل. 4.5 الحفاظ على السرية DeFi / المختلطات اليوم، توفر تطبيقات DeFi [1] القليل من السرية للمستخدمين: جميع المعاملات مرئية على السلسلة. مختلف المناهج القائمة على المعرفة الصفرية، على سبيل المثال، [149، 217]، يمكن أن توفر خصوصية المعاملات، وTEF عام بما يكفي لدعمها. لكن هذه الأساليب ليست شاملة، ولا تخفي، على سبيل المثال، عادة الأصول التي تعتمد عليها الصفقة. المجموعة الواسعة من الأدوات الحسابية التي نعتزم دعمها في النهاية في DONs تمكين الخصوصية بعدد من الطرق المختلفة التي يمكنها سد هذه الثغرات، مما يساعد في استكمال ضمانات الخصوصية للأنظمة الأخرى. على سبيل المثال، يمكن لـ Mixicles، وهي أداة للحفاظ على السرية DeFi اقترحها Chainlink الباحثون في المختبرات [135]، إخفاء نوع الأصل الذي يدعم الأداة المالية، ويتناسب بشكل طبيعي جدًا مع DON إطار العمل. يتم شرح Mixicles بسهولة أكبر من حيث استخدامها لتحقيق ثنائي بسيط الخيار. الخيار الثنائي هو أداة مالية فيها مستخدمان، وسنقوم بذلك قم بالرجوع هنا للتأكد من الاتساق مع [135] كلاعبين، يراهنون على حدث مع احتمالين النتائج، على سبيل المثال، ما إذا كان الأصل يتجاوز السعر المستهدف في وقت محدد مسبقًا أم لا. المثال التالي يوضح الفكرة. مثال 2. أليس وبوب طرفان في خيار ثنائي يعتمد على قيمة الأصل يُسمى رمز فقاعة كارول (CBT). تراهن أليس على أن سعر السوق للـ CBT سيكون عند ما لا يقل عن 250 دولارًا أمريكيًا في الوقت T = ظهر يوم 21 يونيو 2025؛ يراهن بوب على العكس. كل لاعب إيداع 100 ETH في الموعد النهائي المحدد مسبقًا. اللاعب ذو المركز الفائز يتلقى 200 ETH (أي يكسب 100 ETH). يجب أن يكون 8D كبيرًا بما يكفي لضمان توافق M مع الاحتمالية العالية. ل على سبيل المثال، إذا كان M يتحكم في 20% من طاقة التعدين في الشبكة، فقد يختار D = 100، مما يضمن احتمال الفشل ≈2 × 10−10، أي أقل من واحد في المليار.نظرًا لوجود شبكة Chainlink oracle O، فمن السهل تنفيذ شبكة ذكية عقد SC الذي يحقق الاتفاق في المثال 2. يقوم اللاعبان بإيداع كل منهما 100 إيثيريوم في SC. في وقت ما بعد T، يتم إرسال استعلام q إلى O لطلب سعر r يرسل CBT في الوقت T. O تقريرًا بهذا السعر إلى SC. ثم يرسل SC الأموال إلى أليس إذا ص ≥250 وبوب إذا لم يكن كذلك. ومع ذلك، يكشف هذا النهج عن السلسلة، مما يجعل الأمر سهلاً للمراقب لاستنتاج الأصول الكامنة وراء الخيار الثنائي. في مصطلحات Mixicles، من المفيد التفكير بشكل مفاهيمي في النتيجة من SC من حيث المحول الذي ينقل قيمة ثنائية محسوبة كمسند التبديل (ص). في مثالنا، Switch(r) = 0 إذا r ≥250؛ وبالنظر إلى هذه النتيجة، تفوز أليس. وإلا فإن التبديل (ص) = 1 ويفوز بوب. يمكن لـ DON أن يحقق Mixicle أساسي كعقد مختلط عن طريق تشغيل ملف قابل للتنفيذ exec الذي يحسب التبديل (r) ويبلغ عنه في السلسلة إلى SC. نعرض هذا البناء في الشكل 11. الشكل 11: رسم تخطيطي لـ Mixicle الأساسي في المثال 2. لتوفير السرية على السلسلة التقرير r، وبالتالي الأصل الذي يقوم عليه الخيار الثنائي، يرسل oracle إلى عقد SC عبر التبديل فقط مفتاح القيمة الثنائية (ص). لقد قمنا بتحديد محول ConfSwitch في الملحق C.3 الذي يجعل من السهل تحقيق ذلك هدف في DON. الفكرة الأساسية وراء ConfSwitch بسيطة للغاية. بدلا من الإبلاغ القيمة r، تقوم ConfSwitch بالإبلاغ فقط عن قيمة التبديل الثنائي (r). يمكن أن يكون SC مصممة لإجراء الدفع الصحيح بناءً على المفتاح (r) وحده، والمفتاح (r) بمفرده لا يكشف عن أي معلومات حول الأصل الأساسي — CBT في مثالنا. بالإضافة إلى ذلك، عن طريق وضع نص مشفر على (q, r) على دفتر الأستاذ المشفر تحت pkaud، المفتاح العام لـ مدققًا، يقوم المحول ConfSwitch بإنشاء مسار تدقيق يحافظ على السرية. إن Mixicle الأساسي الذي اخترناه للبساطة لوصفه هنا يخفي فقط الأصول والرهان وراء الخيار الثنائي في مثالنا. علبة Mixicle كاملة [135] توفير شكلين من السرية. ويخفي عن الناظرين: (1) ما حدث يراهن اللاعبون على (أي q وr) ولكن أيضًا (2) اللاعب الذي فاز بالرهان. نظرًا لأنه يتم تنفيذ Mixicles على MAINCHAIN، فسيحتاج أي من اللاعبين إلى التتابع قم بالتبديل (r) من DON إلى MAINCHAIN، أو يمكن إنشاء ملف exec قابل للتنفيذ لذلك

يتم تشغيله عند الإخراج بواسطة ConfSwitch ويستدعي محولًا آخر لإرسال المفتاح (r) إليه مينشين. وهناك نوع ثالث دقيق من السرية يستحق النظر فيه أيضًا. في التنفيذ الأساسي لـ ConfSwitch، يقوم O بتشغيل المحول على DON وبالتالي يتعلم الأصول - CBT في مثالنا - وبالتالي طبيعة الخيار الثنائي. كما نوقش ومع ذلك، في الملحق C.3، من الممكن أيضًا استخدام DECO أو Town Crier من أجل قم بإخفاء هذه المعلومات حتى عن O. وفي هذه الحالة، لن يتعلم O المزيد من المعلومات من المراقب العام للSC. لمزيد من التفاصيل حول Mixicles، نحيل القراء إلى [135].

خدمات التسلسل العادل

إحدى الخدمات المهمة التي نتوقع أن تقدمها DONs والتي تعمل على تعزيز إمكانات الشبكات والحوسبة والتخزين الخاصة بها تسمى خدمات التسلسل العادل (FSS). على الرغم من أنه قد يُنظر إلى الخدمة الثابتة الساتلية (FSS) ببساطة على أنها تطبيق تم تحقيقه ضمن إطار عمل DON، إلا أننا نسلط الضوء عليها كخدمة نعتقد أنها ستحظى بطلب مرتفع عبر جميع أنحاء العالم blockchains، والتي نتوقع أن تدعمها شبكة Chainlink بشكل نشط. عند تنفيذها على شبكات blockchain العامة، فإن العديد من تطبيقات DeFi الحالية الكشف عن المعلومات التي يمكن استغلالها من قبل المستخدمين لمصلحتهم الخاصة، على غرار هذا النوع من التسريبات الداخلية وفرص التلاعب السائدة في الوقت الحالي الأسواق [64، 155]. بدلاً من ذلك، تمهد خدمة FSS الطريق نحو نظام بيئي عادل DeFi. الخدمة الثابتة الساتلية يساعد المطورين على إنشاء عقود DeFi محمية من التلاعب بالسوق الناتجة عن تسرب المعلومات. وبالنظر إلى المشاكل التي نسلط الضوء عليها أدناه، فإن FSS كذلك جذابة بشكل خاص لخدمات الطبقة الثانية وتناسبها في إطار هذه الخدمات التي نناقشها في القسم 6. التحدي: في الأنظمة الحالية غير المسموح بها، يتم طلب المعاملات بالكامل حسب تقدير عمال المناجم. في الشبكات المرخصة، قد يتم تطبيق العقد validator نفس القوة. وهذا شكل من أشكال المركزية المؤقتة غير المعترف بها إلى حد كبير في خلاف ذلك الأنظمة اللامركزية. يمكن لعامل التعدين (مؤقتًا) فرض رقابة على المعاملات الخاصة به المنفعة الخاصة [171] أو إعادة ترتيبها لتعظيم مكاسبها الخاصة، وهي فكرة تسمى القيمة القابلة للاستخراج (MEV) [90]. مصطلح MEV خادع بعض الشيء: فهو لا يشير فقط للقيمة التي يمكن لعمال المناجم التقاطها: يمكن للمستخدمين العاديين التقاط بعض MEV. نظرًا لأن القائمين بالتعدين يتمتعون بقدرة أكبر من القوة التي يتمتع بها المستخدمون العاديون، فإن MEV تمثل حدًا أعلى لمقدار القيمة التي يمكن لأي كيان الحصول عليها من خلال إعادة الترتيب التنافسي وإدخال المعاملات التكميلية. حتى عندما يقوم عمال المناجم بطلب المعاملات ببساطة على أساس الرسوم (الغاز)، وبدون تلاعب، يمكن للمستخدمين أنفسهم التلاعب بأسعار الغاز لتفضيل معاملاتهم على المعاملات الأقل تعقيدًا. ديان وآخرون. [90] توثيق وقياس الطرق التي تتخذها الروبوتات (وليس عمال المناجم) الاستفادة من ديناميكيات الغاز بطريقة تضر مستخدمي أنظمة DeFi اليوم وكيف حتى أن MEV يهدد استقرار طبقة الإجماع الأساسية في blockchain. تظهر أمثلة أخرى للتلاعب بأوامر المعاملات بانتظام، على سبيل المثال، [50، 154].تعد أساليب معالجة المعاملات الجديدة مثل rollups طريقة واعدة للغاية لمشاكل تحجيم الإنتاجية العالية blockchains. ومع ذلك، فإنها لا تعالج مشكلة MEV. وبدلاً من ذلك، يقومون بنقله إلى الكيان الذي يقوم بإنشاء rollup. ذلك الكيان، سواء كان مشغل smart contract أو مستخدمًا يقدم (zk-)rollup مع إثبات الصلاحية، لديه القدرة على طلب وإدراج المعاملات. بمعنى آخر، rollups مبادلة MEV بـ REV: القيمة المجمعة القابلة للاستخراج. تؤثر MEV على المعاملات القادمة التي تم إرسالها إلى مجمع الذاكرة لكن لم يلتزموا بعد بالسلسلة. المعلومات حول مثل هذه المعاملات على نطاق واسع المتاحة في الشبكة. يمكن لعمال المناجم وvalidators والمشاركين العاديين في الشبكة ولذلك استغلال هذه المعرفة وإنشاء المعاملات التابعة. بالإضافة إلى ذلك، قد يؤثر القائمون بالتعدين وvalidator على ترتيب تلك المعاملات التي يقومون بها أنفسهم ويستغلون ذلك لصالحهم. مشكلة التأثير غير المبرر من قبل القادة على طلب المعاملات بالإجماع البروتوكولات معروفة في الأدبيات منذ التسعينيات [71، 190]، ولكن لا يوجد مرض مرضي لقد تم تنفيذ الحلول عمليًا حتى الآن [97]. والسبب الرئيسي هو أن الحلول المقترحة - على الأقل حتى وقت قريب جدًا - لا يمكن دمجها بسهولة مع الجمهور blockchains، حيث يعتمدون على بقاء محتوى المعاملات سريًا إلى ما بعد تم تحديد ترتيبهم. نظرة عامة على خدمات التسلسل العادل (FSS): ستوفر DONs أدوات لتحقيق اللامركزية في طلب المعاملات وتنفيذها وفقًا لسياسة محددة من خلال الاعتماد منشئ العقد، ومن الأفضل أن يكون عادلاً، ولا يفيد الجهات الفاعلة التي ترغب في ذلك التلاعب في ترتيب المعاملات. وتشكل هذه الأدوات مجتمعة الخدمة الثابتة الساتلية. يتضمن FSS ثلاثة مكونات. الأول هو مراقبة المعاملات. في الخدمة الثابتة الساتلية، oracle العقد الموجودة في O كلاهما تراقب مجمع ذاكرة MAINCHAIN وتسمح (إذا رغبت في ذلك) تقديم المعاملات خارج السلسلة من خلال قناة متخصصة. والثاني هو تسلسل المعاملات. العقد في معاملات أمر O لعقد الاعتماد وفقا للسياسة المحددة لهذا العقد. والثالث هو نشر المعاملات. بعد طلب المعاملات، تقوم العقد الموجودة في O بإرسال المعاملات بشكل مشترك إلى السلسلة الرئيسية. تشمل الفوائد المحتملة للخدمة الثابتة الساتلية ما يلي: • عدالة الطلب: تشتمل الخدمة الثابتة الساتلية (FSS) على أدوات لمساعدة المطورين على ضمان إتمام المعاملات يتم طلب الإدخال في عقد معين بطريقة لا تعطي ظلمًا ميزة للمستخدمين ذوي الموارد الجيدة و/أو الأذكياء تقنيًا. سياسات الطلب يمكن تحديدها لهذا الغرض. • الحد من تسرب المعلومات أو القضاء عليه: من خلال ضمان عدم تمكن المشاركين في الشبكة من استغلال المعرفة المتعلقة بالمعاملات القادمة، يمكن للخدمات المالية الثابتة أن تخفف أو القضاء على الهجمات مثل التشغيل الأمامي التي تعتمد على المعلومات المتوفرة في الشبكة قبل تنفيذ المعاملات. منع استغلال مثل هذه ويضمن التسرب المعاملات الخصومة التي تعتمد على الأصل المعلق لا يمكن للمعاملات إدخال دفتر الأستاذ قبل تنفيذ المعاملات الأصلية.• انخفاض تكلفة المعاملات: من خلال القضاء على حاجة اللاعبين إلى السرعة في الإرسال معاملاتهم إلى smart contract، FSS يمكن أن تقلل بشكل كبير من تكلفة معالجة المعاملات. • ترتيب الأولويات: يمكن للخدمات المالية الثابتة (FSS) أن تمنح المعاملات الهامة أولوية خاصة تلقائيًا الطلب. على سبيل المثال، لمنع الهجمات الأولية ضد oracle التقارير، على سبيل المثال، [79]، يمكن لخدمة FSS إدراج تقرير oracle في تدفق المعاملات بأثر رجعي. الهدف الشامل لـ FSS في DONs هو تمكين DeFi منشئي المحتوى من تحقيق العدالة الأنظمة المالية، أي الأنظمة التي لا تفيد مستخدمين معينين (أو عمال المناجم) على الآخرين على أساس السرعة أو المعرفة الداخلية أو القدرة على الأداء الفني التلاعب. في حين أن المفهوم العام الواضح للعدالة بعيد المنال، فإن العدالة الكاملة موجودة أي معنى معقول لا يمكن تحقيقه، تهدف FSS إلى تزويد المطورين بأداة قوية مجموعة من الأدوات حتى يتمكنوا من فرض السياسات التي تساعد في تحقيق أهداف التصميم الخاصة بهم لـ DeFi. نلاحظ أنه على الرغم من أن الهدف الرئيسي لـ FSS هو العمل كخدمة تسلسل عادلة MAINCHAIN الذي تستهدفه DONs، بعضًا من نفس العدالة التي ترغب فيها FSS يمكن أن تكون الضمانات مناسبة أيضًا للبروتوكولات (اللامركزية) التي يتم تشغيلها فيما بينها DON الحفلات. وبالتالي، يمكن النظر إلى الخدمة الثابتة الساتلية (FSS) على نطاق أوسع باعتبارها خدمة تقدمها مجموعة فرعية من DON العقد للتسلسل العادل ليس فقط للمعاملات المرسلة من قبل مستخدمي MAINCHAIN ولكن أيضًا المعاملات (أي الرسائل) المشتركة بين عقد DON الأخرى. في هذا القسم، سنركز في المقام الأول على هدف تسلسل معاملات MAINCHAIN. تنظيم القسم: في القسم 5.1، نصف تطبيقين عاليي المستوى يحفزان تصميم FSS: منع التشغيل الأمامي لتقارير oracle ومنع التشغيل الأمامي لمعاملات المستخدم. ثم نقدم المزيد من التفاصيل حول تصميم الخدمة الثابتة الساتلية في القسم 5.2. يصف القسم 5.3 أمثلة على ضمانات ووسائل النظام العادل لتحقيقها. أخيرًا، يناقش القسم 5.4 والقسم 5.5 التهديدات على مستوى الشبكة مثل هذه السياسات والوسائل لمعالجتها، على التوالي لفيضانات الشبكة وسيبيل الهجمات. 5.1 مشكلة التشغيل الأمامي لشرح أهداف وتصميم FSS، وصفنا شكلين عامين من السباق الأمامي الهجمات والقيود المفروضة على الحلول القائمة. الجري في المقدمة يمثل فئة من هجمات طلب المعاملات: هناك عدد من الهجمات ذات الصلة مثل الهجوم الخلفي والتداخل (التشغيل الأمامي بالإضافة إلى التشغيل الخلفي) [237] التي لا نغطيها هنا، ولكن الذي FSS يساعد أيضا على معالجة. 5.1.1 أوراكل للتشغيل الأمامي في دورهم التقليدي المتمثل في توفير البيانات خارج السلسلة لتطبيقات blockchain، oracles تصبح هدفا طبيعيا للهجمات الأمامية.ضع في اعتبارك نمط التصميم الشائع لاستخدام oracle لتوفير خلاصات الأسعار المختلفة إلى بورصة على السلسلة: بشكل دوري (على سبيل المثال كل ساعة)، يقوم oracle بجمع بيانات الأسعار لـ أصول مختلفة ويرسلها إلى عقد الصرف. هذه المعاملات بيانات الأسعار تقديم فرص واضحة للمراجحة: على سبيل المثال، إذا كان أحدث تقرير oracle يسرد سعر أعلى بكثير لبعض الأصول، يمكن للخصم أن يتقدم بتقرير oracle إلى شراء الأصول وإعادة بيعها على الفور بمجرد معالجة تقرير oracle. مطبات السرعة والتسعير بأثر رجعي: الحل الطبيعي لمشكلة التشغيل الأمامي oracle هو إعطاء تقارير oracle أولوية خاصة على المعاملات الأخرى. ل على سبيل المثال، يمكن إرسال تقارير oracle برسوم عالية لتشجيع القائمين بالتعدين على المعالجة لهم أولا. ولكن هذا لن يمنع التقدم إذا كانت فرصة المراجحة عالية، ولا يمكنها منع المراجحة من قبل عمال المناجم أنفسهم. وبالتالي، لجأت بعض البورصات إلى تنفيذ "مطبات سريعة" أكثر ثقلاً، مثل وضع معاملات المستخدم في قائمة الانتظار لعدد من الكتل قبل المعالجة. لهم، أو تعديل الأسعار بأثر رجعي عند وصول تقرير oracle جديد. عيوب هذه الحلول هي أنها تضيف تعقيدًا إلى تنفيذ التبادل، زيادة متطلبات التخزين وبالتالي تكاليف المعاملات، وتعطيل تجربة المستخدم حيث لا يتم تأكيد تبادل الأصول إلا بعد فترة زمنية طويلة. الحمولة على الظهر: قبل الانتقال إلى الخدمة الثابتة الساتلية (FSS)، نناقش مسألة التحميل على الظهر، وهي طريقة بسيطة للغاية حل أنيق لمشكلة التشغيل الأمامي oracle. لا ينطبق على معالجة ومع ذلك، في المقدمة في سيناريوهات أخرى. باختصار، بدلاً من إرسال التقارير بشكل دوري إلى العقد الموجود على السلسلة، oracles نشر التقارير الموقعة التي يلحقها المستخدمون بمعاملاتهم عند الشراء أو البيع الأصول على السلسلة. تقوم البورصة بعد ذلك بالتحقق ببساطة من أن التقرير صالح وحديث (على سبيل المثال، يمكن لـ oracle التوقيع على نطاق من الكتل التي يكون التقرير صالحًا لها)، والمقتطفات تغذية السعر ذات الصلة منه. يتمتع هذا الأسلوب البسيط بعدد من المزايا مقارنة بـ "مطب السرعة" المذكور أعلاه المنهج: (1) لا يحتاج عقد الصرف إلى الحفاظ على حالة الأسعار، وهو ما ينبغي يؤدي إلى انخفاض تكاليف المعاملات؛ (2) بما أن تقارير oracle يتم نشرها على السلسلة على أساس الحاجة، يمكن لـ oracles إنشاء تحديثات أكثر تكرارًا (على سبيل المثال، كل دقيقة)، وبالتالي تقليل فرص المراجحة من خلال إعداد التقرير مسبقًا9؛ (3) يمكن المعاملات سيتم التحقق من صحتها على الفور، لأنها تتضمن دائمًا موجزًا جديدًا للأسعار. لكن النهج ليس مثاليا. أولاً، يضع هذا الحل البديل المسؤولية تقع على عاتق مستخدمي البورصة لجلب تقارير oracle المحدثة وإرفاقها بملفاتهم المعاملات. وثانيا، في حين أن الاعتماد على الفائض من شأنه أن يقلل من فرص المراجحة، فإنه لا يفعل ذلك منعها تمامًا دون التأثير على حيوية العقد الموجود على السلسلة. في الواقع، إذا تقرير oracle صالح حتى رقم الكتلة n، ثم يتم إرسال المعاملة للحظر سيتطلب n + 1 تقريرًا صالحًا جديدًا. بسبب التأخير المتأصل في نشر التقارير من oracles إلى المستخدمين، فإن التقرير الجديد الصالح للكتلة n + 1 سيكون له 9. لا تكون المراجحة جديرة بالاهتمام إلا إذا كان الفارق القابل للاستغلال في أسعار الأصول يتجاوز الفارق الدخيل. الرسوم المطلوبة لشراء وبيع الأصول، على سبيل المثال، تلك التي يتم جمعها من قبل عمال المناجم والبورصة.ليتم نشرها في فترة ما قبل استخراج الكتلة n + 1، على سبيل المثال في الكتلة n -k، وبالتالي إنشاء سلسلة من الكتل k حيث توجد فرصة للمراجحة قصيرة الأجل. نحن صف الآن كيف يتغلب FSS على هذه القيود. تحديد أولويات تقارير oracle مع FSS: يمكن لـ FSS معالجة التشغيل الأمامي oracle المشكلة من خلال البناء على الحل البديل المذكور أعلاه، ولكن مع دفع الحل الإضافي العمل على زيادة المعاملات من خلال تقارير oracle إلى شبكة Oracle اللامركزية. على مستوى عالٍ، تجمع العقد oracle المعاملات الموجهة للتبادل على السلسلة، الاتفاق على موجز الأسعار في الوقت الفعلي، ونشر موجز الأسعار جنبًا إلى جنب مع المعاملات المجمعة في عقد السلسلة الرئيسية. من الناحية النظرية، يمكن للمرء أن يفكر في هذا النهج باعتباره "تجميع المعاملات المعززة بالبيانات"، حيث يضمن oracle أن يتم تحديث تتم إضافة خلاصة الأسعار دائمًا إلى المعاملات. يمكن تنفيذ حلول الخدمة الثابتة الساتلية (FSS) بشفافية لمستخدمي البورصة، ومع الحد الأدنى من التغييرات في منطق العقد، كما نوضح بمزيد من التفصيل في القسم 5.2. ضمان إن تقارير oracle الجديدة التي يتم منحها الأولوية دائمًا على معاملات المستخدم هي مجرد مثال واحد لسياسة الطلب التي يمكن لـ FSS اعتمادها وتنفيذها. سياسات FSS لضمان النظام يتم وصف العدالة بشكل أكثر عمومية في القسم 5.3. 5.1.2 معاملات المستخدم التي يتم تشغيلها مسبقًا ننتقل الآن إلى التشغيل الأمامي في التطبيقات العامة، حيث طريقة الدفاع أعلاه لا يعمل. يمكن التقاط المشكلة على نطاق واسع من خلال السيناريو التالي: يرى الخصم بعض معاملات المستخدم tx1 مرسلة إلى شبكة P2P ويقوم بحقنها معاملتها الخصومة tx2، بحيث تتم معالجة tx2 قبل tx1 (على سبيل المثال، عن طريق الدفع رسوم معاملة أعلى). على سبيل المثال، هذا النوع من التقدم شائع بين الروبوتات التي تستغل فرص المراجحة في أنظمة DeFi [90] وقد أثرت على مستخدمي التطبيقات اللامركزية المختلفة [101]. فرض نظام عادل بين المعاملات معالجتها على blockchain يعالج هذه المشكلة. والأهم من ذلك، أن رؤية تفاصيل tx1 ليست ضرورية في بعض الأحيان إن المعرفة بمجرد وجودها قد تسمح للخصم بتشغيل tx1 من خلاله امتلاك tx2 والاحتيال على المستخدم البريء الذي أنشأ tx1. على سبيل المثال، يمكن للمستخدم أن يكون معروفًا بتداول أصل معين في أوقات منتظمة. يتطلب منع مثل هذه الهجمات عمليات التخفيف التي تتجنب تسرب بيانات التعريف أيضًا [62]. بعض الحلول لهذه المشكلة موجودة، ولكنها تسبب تأخيرات ومخاوف بشأن سهولة الاستخدام. من ترتيب الشبكة إلى الترتيب النهائي مع الخدمة الثابتة الساتلية: فرص للتقدم للأمام تنشأ لأن الأنظمة القائمة ليس لديها آليات لضمان النظام الذي تظهر المعاملات على نحو متسلسلة فيما يتعلق بترتيب الأحداث وتدفق المعلومات خارج الشبكة. يمثل هذا مشكلة ناشئة عن أوجه القصور في تنفيذ التطبيقات (على سبيل المثال، منصات التداول) على blockchain. من الناحية المثالية، يمكن للمرء أن يفعل ذلك تأكد من تنفيذ المعاملات على blockchain بنفس الترتيب الذي كانت عليه تم إنشاؤها وإرسالها إلى شبكة P2P الخاصة بـ blockchain. ولكن منذ شبكة blockchain

يتم توزيعها، ولا يمكن التقاط مثل هذا الطلب. لذلك يقدم FSS الآليات للحماية من انتهاكات العدالة، التي تنشأ فقط بسبب التوزيع طبيعة شبكة blockchain. 5.2 تفاصيل الخدمة الثابتة الساتلية الشكل 12: مجموعة ذاكرة عادلة للطلب مع مسارين مختلفين للمعاملات: مباشر و على أساس mempool. ويبين الشكل 12 مخططاً عاماً للخدمة الثابتة الساتلية. لضمان العدالة، يجب أن يتداخل DON الذي يوفر خدمة FSS مع تدفق المعاملات عند دخولها إلى MAINCHAIN. قد يكون من الضروري إجراء تعديلات على العملاء، على smart contracts على MAINCHAIN، أو على كليهما. على مستوى عالٍ، يمكن تقسيم معالجة المعاملات بواسطة الخدمة الثابتة الساتلية (FSS) إلى ثلاثة المراحل الموضحة أدناه: (1) مراقبة المعاملات؛ (2) تسلسل المعاملات؛ و (3) ترحيل المعاملات. اعتمادًا على طريقة الطلب المستخدمة لتسلسل المعاملات، هناك حاجة إلى خطوات بروتوكول إضافية، كما هو موضح في القسم التالي. 5.2.1 معالجة المعاملات مراقبة المعاملات: نحن نتصور طريقتين مختلفتين لرصد الخدمة الثابتة الساتلية معاملات المستخدم المخصصة لـ smart contract محدد ومباشر ومستند إلى مجمع الذاكرة: • المباشر: النهج المباشر هو أبسط من الناحية المفاهيمية، ولكنه يتطلب إجراء تغييرات عليه عملاء المستخدمين بحيث يتم إرسال المعاملات مباشرة إلى Oracle اللامركزيةعقد الشبكة، بدلاً من عقد السلسلة الرئيسية. يتم تجميع DON معاملات المستخدم الموجهة إلى smart contract SC محددة وأوامرها بناءً على ذلك على بعض سياسة الطلب. يقوم DON بعد ذلك بإرسال المعاملات المطلوبة إلى smart contract على السلسلة الرئيسية. تتطلب بعض آليات الطلب أيضًا النهج المباشر لأن المستخدم الذي يقوم بإنشاء المعاملة يجب أن يكون مشفرًا حمايته قبل إرساله إلى FSS. • مستند إلى Mempool: لتسهيل تكامل FSS مع العملاء القديمين، DON يمكن استخدام Mempool Services (MS) لمراقبة مجمع الذاكرة الخاص بالسلسلة الرئيسية وجمعه المعاملات. من المرجح أن يكون النقل المباشر هو التنفيذ المفضل للعديد من العقود، ونعتقد أنه ينبغي أن يكون عمليًا إلى حد ما في كثير من الحالات. نناقش بإيجاز كيف يمكن تعديل التطبيقات اللامركزية الحالية إلى الحد الأدنى لدعمها النقل المباشر مع الحفاظ على تجربة مستخدم جيدة. وصفنا النهج استخدام Ethereum وMetaMask [6] نظرًا لأن هذه هي الخيارات الأكثر شيوعًا اليوم، ولكن يجب أن تمتد التقنيات المذكورة إلى السلاسل والمحافظ الأخرى. حديثة Ethereum اقتراح التحسين، "EIP-3085: تضيف المحفظة Ethereum طريقة سلسلة RPC" [100]، سيجعل من السهل استهداف سلاسل Ethereum المخصصة (باستخدام معرف سلسلة مختلف عن تلك الخاصة بـ MAINCHAIN لمنع هجمات إعادة التشغيل) من MetaMask والمحافظ الأخرى المستندة إلى المتصفح. بعد تنفيذ هذا الاقتراح، يسعى تطبيق DApp إلى استخدام DON سيضيف ببساطة استدعاء أسلوب واحد إلى الواجهة الأمامية ليتمكن من الإرسال مباشرة المعاملات إلى أي DON يعرض واجهة برمجة التطبيقات المتوافقة مع Ethereum. في هذه الأثناء، "EIP-712: Ethereum البيانات المنظمة المكتوبة hash للتوقيع والتوقيع" [49] يوفر قليلاً بديل أكثر مشاركة ولكنه منتشر بالفعل على نطاق واسع، حيث يمكن لمستخدم DApp استخدامه MetaMask لتوقيع البيانات المنظمة التي تحدد معاملة DON. يمكن للتطبيق اللامركزي إرسال وقعت هذه البيانات المنظمة على DON. وأخيرا، نلاحظ أن النهج الهجين ممكن أيضا. على سبيل المثال، التراث يمكن للعملاء الاستمرار في إرسال المعاملات إلى مجمع ذكريات السلسلة الرئيسية، ولكن الأمر بالغ الأهمية يتم إرسال المعاملات (على سبيل المثال، تقارير oracle) إلى العقد DON مباشرة (على وجه الخصوص، مجموعة من العقد توفر تقارير oracle مثل تحديثات موجز الأسعار ومجموعة العقد قد يتداخل توفير الخدمة الثابتة الساتلية (FSS) أو يكون متطابقًا). تسلسل المعاملات: الغرض الرئيسي من FSS هو ضمان ترتيب معاملات المستخدم وفقًا لسياسة محددة مسبقًا. طبيعة هذه السياسة سوف تعتمد على احتياجات التطبيق وأنواع أوامر المعاملات غير العادلة التي يقدمها يهدف إلى منع. نظرًا لأن FSS الموجود على DON قادر على معالجة البيانات والحفاظ على الحالة المحلية، فقد يفرضون سياسة تسلسل تعسفية بناءً على المعلومات الموجودة متاح على oracles. تتم مناقشة سياسات الطلب الخاصة وتنفيذها لاحقًا في القسم 5.3.ترحيل المعاملات: بعد جمع وترتيب معاملات المستخدم، سواء المستلمة مباشرة من المستخدمين أو التي تم جمعها من مجمع الذاكرة، يرسل DON هذه المعاملات إلى السلسلة الرئيسية. وعلى هذا النحو، تظل تفاعلات DON مع السلسلة الرئيسية قائمة تخضع لطلبات المعاملات (التي قد تكون غير عادلة) والتي يحكمها القائمون بالتعدين في السلسلة الرئيسية. للاستفادة من فوائد طلب المعاملات اللامركزية، الهدف ذكي وبالتالي، يجب تصميم عقد SC بحيث يعامل DON كمواطن من "الدرجة الأولى". نحن التمييز بين نهجين: • DON- العقود فقط: أبسط خيار للتصميم هو جعل السلسلة الرئيسية ذكية لا يقبل عقد SC إلا المعاملات التي تمت معالجتها بواسطة DON. هذا يضمن أن smart contract يعالج المعاملات بالترتيب الذي يقترحه DON، ولكن بحكم الأمر الواقع يقيد smart contract للعمل في نظام قائم على اللجنة (على سبيل المثال، تتمتع لجنة DON الآن بسلطة مستمرة لتحديد ترتيب وإدراج المعاملات). • العقود ذات الفئة المزدوجة: التصميم المفضل والأكثر تفصيلاً يحتوي على السلسلة الرئيسية الذكية يقبل عقد SC المعاملات الناشئة من DON ومن التراث المستخدمين،10 ولكنها تضع "مطبات السرعة" التقليدية على المعاملات التي لم تتم معالجتها بواسطة DON. على سبيل المثال، قد تتم معالجة المعاملات من DON على الفور، بينما يتم "تخزين" المعاملات القديمة بواسطة smart contract لـ فترة زمنية محددة. آليات قياسية أخرى لمنع التشغيل الأمامي مثل مخططات الكشف عن الالتزام أو VDFs [53] يمكن أيضًا تطبيقها على الإصدارات القديمة المعاملات. وهذا يضمن معالجة المعاملات المطلوبة DON الأمر المتفق عليه، دون إعطاء DON السلطة غير المرغوب فيها للرقابة المعاملات. نظرًا لأن فرض طلب المعاملات بواسطة الخدمة الثابتة الساتلية (FSS) يتطلب تجميع المعاملات "خارج السلسلة"، فمن الطبيعي أن يتم دمج هذا الحل مع تقنيات التجميع الأخرى التي تهدف إلى تقليل تكاليف المعالجة على السلسلة. على سبيل المثال، بعد جمع و لطلب المعاملات، قد يرسل DON هذه المعاملات إلى السلسلة الرئيسية باعتبارها "معاملة مجمعة" واحدة (على سبيل المثال، rollup)، مما يقلل من إجمالي المعاملة رسوم. تنفيذ أمر المعاملة: سواء كان في تصميم DON فقط أو تصميم ثنائي الفئة، يجب أن يتم تصميم السلسلة الرئيسية smart contract SC وDON بشكل مشترك لضمان دعم طلب المعاملات الخاص بـ DON. وهنا أيضًا، نتصور مختلفًا خيارات التصميم: • الأرقام التسلسلية: يمكن لـ DON إلحاق رقم تسلسلي بكل معاملة، وإرسال هذه المعاملات إلى مجمع ذكريات السلسلة الرئيسية. الرئيسي 10إذا كانت مراقبة معاملات DON تعتمد على مجمع الذاكرة، فيجب تمييز المعاملات القديمة عن معاملات DON بحيث لا يتم جمعها بواسطة DON، على سبيل المثال، عبر علامة خاصة جزءا لا يتجزأ من الصفقة أو عن طريق تحديد سعر معين للغاز، على سبيل المثال. DON المعاملات بها غاز الأسعار تحت عتبة معينة.تتجاهل السلسلة smart contract SC المعاملات التي تصل "خارج التسلسل". نحن لاحظ أنه في هذا الإعداد، يمكن للقائمين بالتعدين في السلسلة الرئيسية أن يقرروا تجاهل DON طلب المعاملات، مما يؤدي إلى فشل المعاملات. من الممكن عن طريق الاحتفاظ بحالة (باهظة الثمن) لـ SC فرض ترتيب المعاملات الصحيح إلى حد ما بشكل مشابه لكيفية قيام بروتوكول TCP بتخزين الحزم خارج الترتيب حتى تصبح الحزم المفقودة تلقى. • المعاملات nonces: بالنسبة للعديد من blockchains، وعلى وجه الخصوص لـ Ethereum، يمكن لنهج الترقيم التسلسلي أعلاه الاستفادة من المعاملة المضمنة nonces فرض أن السلسلة الرئيسية smart contract SC تعالج المعاملات بالتسلسل. هنا، ترسل العقد DON المعاملات إلى السلسلة الرئيسية من خلال حساب mainchain واحد، محمي بمفتاح مشترك بين العقد DON. الحساب تضمن المعاملة nonce استخراج المعاملات ومعالجتها بالترتيب الصحيح. • تجميع المعاملات: يمكن لـ DON تجميع معاملات متعددة في rollup (أو في حزمة مشابهة لـ rollup). يجب أن تكون السلسلة الرئيسية smart contract مصممة للتعامل مع مثل هذه المعاملات الإجمالية. • تجميع المعاملات باستخدام وكيل السلسلة الرئيسية: هنا، يقوم DON بالمثل بتجميع المعاملات في "معاملة تعريفية" واحدة للسلسلة الرئيسية، ولكنها تعتمد على الوكيل المخصص smart contract لتفريغ المعاملات وترحيلها إلى العقد المستهدف SC. يمكن أن تكون هذه التقنية مفيدة للتوافق القديم. تعمل المعاملات الوصفية مثل rollup ولكنها تختلف من حيث أنها تتكون من ملف غير مضغوط قائمة المعاملات المنشورة مرة واحدة على السلسلة الرئيسية. يتمتع التصميم الأخير بميزة دعم معاملات المستخدم بسلاسة هم أنفسهم وكيلون من خلال عقد السلسلة الرئيسية قبل الوصول إلى هدف DON عقد SC. على سبيل المثال، فكر في مستخدم يرسل معاملة إلى بعض المحافظ العقد، والذي بدوره يرسل معاملة داخلية إلى SC. تعيين تسلسل سيكون رقم مثل هذه المعاملة صعبًا، ما لم يكن عقد محفظة المستخدم كذلك مصمم خصيصًا لإعادة توجيه الرقم التسلسلي مع كل معاملة داخلية إلى SC. وبالمثل، لا يمكن تجميع هذه المعاملات الداخلية بسهولة في معاملة وصفية يتم إرسالها مباشرة إلى SC. نناقش المزيد من اعتبارات التصميم ل مثل هذه المعاملات بالوكالة أدناه. 5.2.2 الذرية الصفقة لقد افترضت مناقشتنا حتى الآن ضمنيًا أن المعاملات تتفاعل مع واحدة على السلسلة smart contract (على سبيل المثال، يرسل المستخدم طلب شراء إلى البورصة). ومع ذلك، في أنظمة مثل Ethereum، يمكن أن تتكون المعاملة الواحدة من معاملات داخلية متعددة، على سبيل المثال، واحدة smart contract تستدعي وظيفة في عقد آخر. أدناه، نحن وصف استراتيجيتين رفيعتي المستوى لتسلسل المعاملات "متعددة العقود"، بينما الحفاظ على ذرية المعاملة (أي تسلسل الإجراءات المنصوص عليها من قبل يتم تنفيذ جميع المعاملات بالترتيب الصحيح، أو لا يتم تنفيذها على الإطلاق).الذرية القوية: الحل الأبسط هو تطبيق الخدمة الثابتة الساتلية، كما هو موضح أعلاه، مباشرة على المعاملات "متعددة العقود" بأكملها. أي أن المستخدمين يرسلون معاملاتهم في الشبكة ويقوم FSS بمراقبة وتسلسل هذه المعاملات ونشرها على السلسلة الرئيسية. هذا الأسلوب بسيط من الناحية الفنية، ولكن له قيد محتمل واحد: إذا كان المستخدم تتفاعل المعاملة مع عقدين SC1 وSC2 يرغب كلاهما في الاستفادة بشكل عادل خدمات التسلسل، فإن سياسة التسلسل لهذين العقدين يجب أن تكون متسقة. وهذا يعني أنه في ضوء معاملتين مختلفتين tx1 وtx2 يتفاعل كل منهما معهما لكل من SC1 وSC2، يجب ألا تكون سياسة SC1 هي التي تطلب tx1 قبل tx2 في حين أن سياسة SC2 تنص على الأمر المعاكس. بالنسبة للغالبية العظمى من السيناريوهات محل الاهتمام، فإننا نتصور أن سياسات التسلسل المعتمدة في العقود المختلفة ستكون متسقة. على سبيل المثال، كل من SC1 وSC2 قد ترغب في أن يتم ترتيب المعاملات حسب وقت وصولها التقريبي إلى مجمع الذاكرة، وقد يرغب SC1 أيضًا في تسليم تقارير معينة oracle أولاً دائمًا. كما معاملات التقرير oracle الأخيرة لا تتفاعل مع SC2، والسياسات متسقة. الذرية الضعيفة: في عموميتها الكاملة، يمكن تطبيق الخدمة الثابتة الساتلية على المستوى الفردي المعاملات الداخلية. خذ بعين الاعتبار المعاملات بالصيغة tx = {˜txpre, ˜txSC, ˜txpost}، والتي تتكون من بعض العناصر الأولية المعاملة (المعاملات) ˜txpre، والتي تؤدي إلى معاملة داخلية ˜txSC إلى SC، والتي بدورها يصدر المعاملة (المعاملات) الداخلية ˜txpost. قد تحدد سياسة التسلسل الخاصة بـ SC كيفية القيام بذلك يجب أن يتم طلب المعاملة الداخلية ˜txSC فيما يتعلق بالمعاملات الأخرى المرسلة إلى SC، ولكن اترك ترتيب التسلسل مفتوحًا لـ "txpre" و"txpost". نظرًا لجوهر معالجة المعاملات في أنظمة مثل Ethereum، فإن تطوير خدمة تسلسل تستهدف معاملات داخلية محددة ليس بالأمر السهل. مع عقد SC المصمم خصيصًا، يمكن تحقيق ذلك على النحو التالي: 1. يتم إرسال المعاملة tx إلى الشبكة واستخراجها (بدون أي تسلسل يؤديها FSS). يتم تنفيذ الأمر ˜txpre الأولي، ويستدعي ˜txSC. 2. SC لا ينفذ "txSC" ويعود. 3. يقوم FSS بمراقبة المعاملات الداخلية إلى SC، وتسلسلها، ثم إرسالها مرة أخرى إلى SC (أي عن طريق إرسال المعاملات ˜txSC مباشرة إلى SC). 4. تقوم SC بمعالجة المعاملات ˜txSC المستلمة من FSS، وتصدر المعاملات الداخلية ˜txpost الناتجة عن ˜txSC. باستخدام هذا النهج، لا يتم تنفيذ المعاملات بشكل ذري بالكامل (أي النسخة الأصلية يتم تقسيم المعاملة tx إلى معاملات متعددة على السلسلة)، ولكن ترتيب يتم الحفاظ على المعاملات الداخلية. يتضمن هذا الحل عددًا من قيود التصميم. على سبيل المثال، لا يمكن لـ txpre افترض أنه سيتم تنفيذ ˜txSC و ˜txpost. وعلاوة على ذلك، ينبغي تصميم SC بحيث تنفيذ المعاملات ˜txSC و ˜txpost نيابة عن مستخدم معين، على الرغم من أنها كانت كذلكأرسلت بواسطة FSS. لهذه الأسباب، الحل الأكثر خشونة هو "الذرية القوية". من المرجح أن يكون ما سبق هو الأفضل في الممارسة العملية. لاحترام التبعيات الأكثر تعقيدًا، والتي تتضمن معاملات متعددة و المعاملات الداخلية الخاصة بكل منها، قد يحتوي برنامج جدولة المعاملات في FSS وظائف معقدة تشبه تلك الموجودة في مديري المعاملات العلائقية مديري قواعد البيانات. 5.3 تسلسل المعاملات العادلة نناقش هنا فكرتين للعدالة فيما يتعلق بتسلسل المعاملات والتطبيقات المقابلة، والتي يمكن أن تحققها الخدمة الثابتة الساتلية: عدالة الطلب على أساس سياسة ما تفرضها الخدمة الثابتة الساتلية (FSS) والحفاظ على العلاقة السببية الآمنة، الأمر الذي يتطلب طرق تشفير إضافية في الخدمة الثابتة الساتلية (FSS). عدالة النظام: عدالة النظام هي فكرة العدالة الزمنية في بروتوكولات الإجماع تم تقديمه رسميًا لأول مرة بواسطة Kelkar et al. [144]. كيلكار وآخرون. تهدف إلى تحقيق شكل من أشكال السياسة الطبيعية التي تتم فيها المعاملات تم طلبها بناءً على وقت استلامها لأول مرة بواسطة DON (أو شبكة P2P، في حالة FSS المستندة إلى mempool). لكن الأمر مختلف في النظام اللامركزي قد ترى العقد وصول المعاملات بترتيب مختلف. إنشاء النظام الإجمالي في جميع المعاملات هي المشكلة نفسها التي تم حلها من خلال بروتوكول الإجماع الأساسي مينشين. كيلكار وآخرون. [144] لذلك يقدم فكرة أضعف يمكن أن تكون تم تحقيقه بمساعدة شبكة أوراكل اللامركزية، والتي تسمى "عدالة أوامر الكتلة". يقوم بتجميع المعاملات التي تلقاها DON خلال فترة زمنية في ملف "block" ويقوم بإدراج جميع معاملات الكتلة بشكل متزامن وفي نفس الموضع (أي الارتفاع) إلى MAINCHAIN. وبالتالي يتم ترتيبها معًا ويجب أن تكون قابلة للتنفيذ بالتوازي، دون خلق أي صراعات فيما بينها. بشكل تقريبي، تنص عدالة الطلب على أنه إذا رأى جزء كبير من العقد المعاملة τ1 قبل τ2، إذن سيتم تسلسل τ1 قبل أو في نفس الكتلة مثل τ2. بفرض مثل هذه الخشنة التفاصيل المتعلقة بأمر المعاملة، تقل فرص الهجوم الأمامي والهجمات الأخرى المتعلقة بالأمر بشكل كبير. كيلكار وآخرون. يقترح عائلة من البروتوكولات تسمى Aequitas [144]، والتي تعالج نماذج نشر مختلفة، بما في ذلك إعدادات الشبكة المتزامنة والمتزامنة جزئيًا وغير المتزامنة. تفرض بروتوكولات Aequitas أعباء اتصال كبيرة مقارنة بالإجماع الأساسي BFT وبالتالي فهي ليست مثالية للاستخدام العملي. ومع ذلك، نعتقد أن المتغيرات العملية لـ Aequitas ستظهر والتي يمكن استخدامها لتسلسل المعاملات في الخدمة الثابتة الساتلية والتطبيقات الأخرى. بعض المخططات ذات الصلة لديها تم بالفعل اقتراحها والتي تحتوي على شكليات أقل وخصائص أضعف، على سبيل المثال، [36، 151، 236]، لكن الأداء العملي أفضل. يمكن دعم هذه المخططات في الخدمة الثابتة الساتلية كذلك. ومن الجدير بالذكر أيضًا أن مصطلح "العدالة" يظهر في مكان آخر في blockchain الأدب ذو معنى مختلف، وهو الإنصاف بمعنى الفرصةالقائمين بالتعدين يتناسب مع مواردهم الملتزم بها [106، 181] أو validators من حيث تكافؤ الفرص [153]. تأمين الحفاظ على السببية: يعتمد الأسلوب الأكثر شهرة لمنع التجاوزات وانتهاكات الطلب الأخرى في الأنظمة الأساسية الموزعة على التشفير التقنيات. السمة المشتركة بينهما هي إخفاء بيانات المعاملة نفسها، والانتظار حتى تم إنشاء الطلب في طبقة الإجماع والكشف عن بيانات المعاملة لاحقا للمعالجة. وهذا يحافظ على الترتيب السببي بين المعاملات التي تتم تم تنفيذه بواسطة blockchain. مفاهيم الأمان وبروتوكولات التشفير ذات الصلة تم تطويرها بشكل كبير قبل ظهور blockchains [71، 190]. تتطلب الشروط الأمنية الخاصة بـ "سببية الإدخال" [190] و"الحفاظ على السببية الآمنة" [71، 97] رسميًا عدم معرفة أي معلومات حول المعاملة قبل أن يتم تحديد موقع هذه الصفقة في النظام العالمي. يجب ألا يتمكن الخصم من استنتاج أي معلومات حتى ذلك الوقت بطريقة مشفرة شعور قوي. يمكن للمرء أن يميز بين أربع تقنيات تشفير للحفاظ على العلاقة السببية: • بروتوكولات الكشف عن الالتزام [29، 142، 145]: بدلاً من الإعلان عن المعاملة في الوضوح، يتم بث فقط التزام التشفير بالمعاملة. بعد أن يتم طلب جميع المعاملات الملتزمة ولكن المخفية (في أوائل blockchain الأنظمة الموجودة على MAINCHAIN نفسها، ولكن هنا بواسطة FSS)، يجب على المرسل فتح الالتزام والكشف عن بيانات المعاملة خلال فترة زمنية محددة مسبقًا. ثم تتحقق الشبكة من أن الافتتاح يفي بالالتزام السابق. ال تعود أصول هذه الطريقة إلى ما قبل ظهور blockchains. وعلى الرغم من بساطة هذا النهج بشكل خاص، إلا أنه ينطوي على عيوب كبيرة وليس من السهل استخدامه لسببين. أولاً، بما أن الالتزام موجود فقط على مستوى بروتوكول الطلب، فإن دلالات المعاملة لا يمكن التحقق من صحتها أثناء الإجماع. رحلة إضافية ذهابًا وإيابًا إلى العميل مطلوب. لكن الأمر الأكثر خطورة هو احتمال عدم فتح أبوابها قد تصل إلى أي وقت مضى، الأمر الذي قد يصل إلى مستوى هجوم رفض الخدمة. علاوة على ذلك، فإنه من الصعب تحديد ما إذا كان الافتتاح صالحًا بشكل متسق وموزع بطريقة لأنه يجب على جميع المشاركين الاتفاق على ما إذا كان الافتتاح قد وصل أم لا الوقت. • بروتوكولات الكشف عن الالتزام مع تأخير الاسترداد [145]: أحد التحديات مع نهج الالتزام والكشف هو أن العميل قد يلتزم بمعاملة مضاربة ويكشف عنها لاحقًا فقط إذا كانت المعاملات اللاحقة تجعلها مربحة. أ يعمل البديل الأخير من نهج الكشف عن الالتزام على تحسين المرونة ضد هذا نوع من سوء السلوك. وعلى وجه الخصوص، يعالج بروتوكول TEX [145] هذه المشكلة باستخدام أسلوب ذكي تتضمن فيه المعاملات المشفرة مفتاح فك التشفير يمكن الحصول عليها عن طريق حساب دالة تأخير يمكن التحقق منها (VDF) [53، 221]. إذا كان العميل إذا فشلت في فك تشفير معاملتها في الوقت المناسب، فسيقوم الآخرون في النظام بفك التشفير نيابة عنها عن طريق حل لغز تشفير صعب إلى حد ما.• تشفير العتبة [71، 190]: تستغل هذه الطريقة ما قد يؤديه DON عمليات عتبة التشفير. افترض أن FSS يحتفظ بتشفير عام يتشارك المفتاحان pkO وoracles المفتاح الخاص المقابل فيما بينهما. يقوم العملاء بعد ذلك بتشفير المعاملات بموجب pkO وإرسالها إلى FSS. أوامر الخدمة الثابتة الساتلية المعاملات على DON، ثم يقوم بفك تشفيرها وإدخالها أخيرًا في MAINCHAIN بالترتيب الثابت. التشفير بالتالي يضمن أن الطلب لا يعتمد على محتوى المعاملة، بل على أن البيانات نفسها تكون متاحة متى مطلوب. تم اقتراح هذه الطريقة في الأصل بواسطة رايتر وبيرمان [190] وتم تحسينها لاحقًا بواسطة Cachin et al. [71]، حيث تم دمجه بإجماع مسموح به البروتوكول. لقد استكشفت الأعمال الحديثة استخدام تشفير العتبة كطريقة آلية على مستوى الإجماع للرسائل العامة [33، 97] وللحسابات العامة مع البيانات المشتركة [41]. بالمقارنة مع بروتوكولات كشف الالتزام، يمنع تشفير العتبة هجمات رفض الخدمة البسيطة (على الرغم من أن الحذر مطلوب نظرًا للتكلفة الحسابية لفك التشفير). فهو يتيح لـ DON المضي قدمًا بشكل مستقل وبسرعته الخاصة وبدون ذلك في انتظار المزيد من إجراءات العميل. يمكن التحقق من صحة المعاملات فورًا بعد فك تشفيرها. علاوة على ذلك، يقوم العملاء بتشفير كافة المعاملات باستخدام أداة واحدة مفتاح DON ويظل نمط الاتصال كما هو مع الآخرين المعاملات. إدارة مفتاح العتبة بشكل آمن ومع تغيير العقد ومع ذلك، قد يطرح صعوبات إضافية. • المشاركة السرية الملتزم بها [97]: بدلاً من تشفير بيانات المعاملة تحتها المفتاح الذي يحتفظ به DON، يجوز للعميل أيضًا مشاركته سرًا للعقد الموجودة في O. باستخدام نظام مشاركة سري مختلط وآمن حسابيًا، تتم المعاملة يتم تشفيره أولاً باستخدام تشفير متماثل بمفتاح عشوائي. تتم مشاركة المفتاح المتماثل المقابل فقط ويتم إرسال النص المشفر إلى DON. يجب على العميل إرسال مشاركة مفتاح واحدة إلى كل عقدة في O باستخدام رسالة مشفرة بشكل منفصل. خطوات البروتوكول المتبقية هي نفسها كما هو الحال مع العتبة التشفير، إلا أنه يتم فك تشفير بيانات المعاملة بطريقة متماثلة الخوارزمية بعد إعادة بناء مفتاح كل معاملة من مشاركاتها. لا تتطلب هذه الطريقة إعداد أو إدارة نظام تشفير المفتاح العام المرتبطة بـ DON. ومع ذلك، يجب أن يكون العملاء على علم بالعقد الموجودة في O والتواصل في سياق آمن مع كل واحد منهم في أي مكان عبء إضافي على العملاء. على الرغم من أن طرق التشفير توفر حماية كاملة ضد المعلومات تتسرب من المعاملات المقدمة إلى الشبكة، فهي لا تخفي البيانات الوصفية. ل على سبيل المثال، لا يزال من الممكن استخدام عنوان IP أو عنوان Ethereum الخاص بالمرسل خصمًا لأداء الهجمات الأمامية والهجمات الأخرى. تعزيز الخصوصية المختلفة التقنيات المنتشرة في طبقة الشبكة، على سبيل المثال، [52، 95، 107]، أو طبقة المعاملات، على سبيل المثال، [13، 65]، ستكون هناك حاجة لتحقيق هذا الهدف. تأثير قطعة معينة من الممكن إخفاء البيانات الوصفية (جزئيًا)، أي العقد الذي يتم إرسال المعاملة إليهمن خلال مضاعفة العديد من العقود على نفس DON. إخفاء التشفير المعاملات في حد ذاتها لا تمنع أيضًا تحديد أولويات المعاملات عن طريق التالف DON العقد المتواطئة مع مرسلي المعاملات. إن السببية الآمنة التي تضمنها بروتوكولات التشفير تكمل ضمانات عدالة الطلب لأي سياسة، ونحن نعتزم استكشاف مزيج من الاثنين الأساليب، حيثما كان ذلك ممكنا. إذا لم يتمكن الخصم من الحصول على ميزة كبيرة منه ومن خلال مراقبة البيانات الوصفية، يمكن استخدام بروتوكولات الحفاظ على العلاقة السببية الآمنة جنبًا إلى جنب نهج الطلب الساذج أيضًا. على سبيل المثال، يمكن للعقد oracle كتابة المعاملات إلى L بمجرد استلامها، دون ازدواجية. المعاملات ستكون بعد ذلك تم طلبها وفقًا لظهورها على L وتم فك تشفيرها لاحقًا. ونخطط أيضًا للنظر في استخدام TEEs كوسيلة للمساعدة في فرض النظام العادل؛ ل على سبيل المثال، يمكن النظر إلى Tesseract [44] على أنه يحقق شكلاً من أشكال الترتيب السببي، ولكن أحد معززة بقدرة TEE على معالجة المعاملات بشكل واضح أثناء الحفاظ على سريتهم. 5.4 اعتبارات طبقة الشبكة حتى الآن، ركز وصفنا للخدمة الثابتة الساتلية (FSS) بشكل أساسي على مشكلة فرض ذلك يتطابق الترتيب النهائي للمعاملات مع ترتيبها الملحوظ في الشبكة. الآخرة، نحن نأخذ في الاعتبار مشكلات العدالة التي قد تنشأ في طبقة الشبكة نفسها. يستثمر المتداولون عالي التردد في الأسواق الإلكترونية التقليدية قدرًا كبيرًا من المال الموارد اللازمة للحصول على سرعة شبكة فائقة [64]، ويظهر المتداولون في بورصات العملات المشفرة سلوكًا مشابهًا [90]. تمنح سرعة الشبكة ميزة في كل من مراقبة معاملات الأطراف الأخرى وتقديم المعاملات المتنافسة. أحد العلاجات التي تم نشرها عمليًا وتم نشرها في كتاب Flash Boys [155] هو "مطب السرعة" الذي تم تقديمه في البداية في بورصة IEX [128] ولاحقًا في بورصات أخرى التبادلات [179] (مع نتائج مختلطة [19]). وتفرض هذه الآلية تأخيرا (350 ميكروثانية في IEX) على الوصول إلى السوق، وذلك بهدف تحييد المزايا في السرعة. الأدلة التجريبية، على سبيل المثال. [128]، يدعم فعاليته في تقليل تداولات معينة التكاليف بالنسبة للمستثمرين العاديين. يمكن استخدام FSS ببساطة لتنفيذ نظام غير متماثل مطب السرعة - الذي يؤخر المعاملات الواردة. يرى بوديش وكرامتون وشيم [64] أن استغلال المزايا في السرعة لا مفر منه في الأسواق المستمرة، ويجادلون من أجل علاج هيكلي في شكل من أشكال الأسواق القائمة على المزاد دفعة واحدة. لكن هذا النهج لم يترسخ على نطاق واسع في منصات التداول الحالية. أنظمة التداول التقليدية مركزية، وعادة ما تتلقى المعاملات من خلالها اتصال شبكة واحدة. على النقيض من ذلك، في النظام اللامركزي، من الممكن مراقبة انتشار المعاملة من نقاط مراقبة متعددة. وبالتالي، من الممكن ملاحظة سلوكيات مثل غمر الشبكة في شبكة P2P. نحن ننوي لاستكشاف أساليب طبقة الشبكة للخدمة الثابتة الساتلية (FSS) التي تساعد المطورين على تحديد السياسات حظر مثل هذه السلوكيات الشبكة غير المرغوب فيها.5.5 سياسات العدالة على مستوى الكيان تهدف عدالة النظام والسببية الآمنة إلى فرض أمر على المعاملات يحترم الوقت الذي تم فيه إنشائها وإرسالها لأول مرة إلى الشبكة. أحد القيود على فكرة العدالة هذه هو أنها لا تمنع الهجمات التي يقوم بها الخصم تكتسب ميزة من خلال إغراق النظام بالعديد من المعاملات، وهي استراتيجية تمت ملاحظتها في البرية كوسيلة لإجراء عمليات قنص فعالة للمعاملات في token المبيعات [159] ول خلق ازدحام يؤدي إلى تصفية مراكز الديون المضمونة (CDPs) [48]. وبعبارة أخرى، فإن عدالة النظام تفرض العدالة فيما يتعلق بالمعاملات، وليس اللاعبين. كما هو موضح في نظام CanDID [160]، من الممكن استخدام أدوات oracle مثل DECO أو Town Crier بالاشتراك مع لجنة العقد (مثل DON) لتحقيق أشكال مختلفة من مقاومة العرافة مع حماية الخصوصية. يمكن للمستخدمين تسجيل الهويات وتقديم دليل على تفردهم دون الكشف عن الهويات نفسها. توفر بيانات الاعتماد المقاومة لـ Sybil طريقة محتملة لإثراء طلب المعاملات السياسات بطريقة من شأنها أن تحد من فرص الهجمات الفيضانات. على سبيل المثال، أ token قد يسمح البيع بمعاملة واحدة فقط لكل مستخدم مسجل، حيث يتم التسجيل يتطلب إثباتًا على تفرد المعرف الوطني، مثل رقم الضمان الاجتماعي. مثل هذا النهج ليس مضمونا، ولكنه قد يكون سياسة مفيدة للتخفيف من هجمات غمر المعاملات.

إطار عمل تنفيذ المعاملات DON

(DON-TEF) ستوفر DONs oracle ودعم الموارد اللامركزية لحلول الطبقة الثانية داخل ما نسميه إطار عمل تنفيذ المعاملات لشبكة أوراكل اللامركزية (DONTEF) أو TEF للاختصار. اليوم، أصبح تكرار التحديثات لعقود DeFi محدودًا بزمن استجابة السلسلة الرئيسية، على سبيل المثال، متوسط الفاصل الزمني للكتلة 10-15 ثانية في Ethereum [104] - بالإضافة إلى تكلفة دفع كميات كبيرة من البيانات على السلسلة وإنتاجية حسابية/إرسالية محدودة— تحفيز أساليب التوسع مثل التجزئة [148، 158، 232] وتنفيذ الطبقة الثانية [5، 12، 121، 141، 169، 186، 187]. حتى blockchains تتميز بأوقات معاملات أسرع بكثير، على سبيل المثال، [120]، اقترحوا إستراتيجيات قياس تتضمن عمليات حسابية خارج السلسلة [168]. والمقصود من TEF هو أن يكون بمثابة مورد الطبقة الثانية لأي من أنظمة الطبقة الأولى / MAINCHAIN. باستخدام TEF، يمكن لـ DONs دعم التحديثات الأسرع في عقد MAINCHAIN أثناء الاحتفاظ بضمانات الثقة الرئيسية التي تقدمها السلسلة الرئيسية. TEF يمكن أن تدعم أي عدد من تقنيات ونماذج تنفيذ الطبقة الثانية، بما في ذلك rollups,11 متفائل rollups، Validium، وما إلى ذلك، بالإضافة إلى نموذج عتبة الثقة الذي DON العقد تنفذ المعاملات. يعتبر TEF مكملاً للخدمة الثابتة الساتلية ويهدف إلى دعمها. وبعبارة أخرى، أي يمكن للتطبيق الذي يعمل في TEF استخدام FSS. 11غالبًا ما يطلق عليها "zk-rollups"، وهي تسمية خاطئة، لأنها لا تحتاج بالضرورة إلى إثباتات المعرفة الصفرية.

6.1 نظرة عامة على TEF TEF هو نمط تصميمي لبناء وتنفيذ سيارة هجينة عالية الأداء smart contract SC. وفقًا للفكرة الرئيسية وراء الهجين smart contracts، يتضمن TEF أ تحلل SC إلى قطعتين: (1) ما نسميه في سياق TEF مرساة عقد SCa على MAINCHAIN و(2) DON المنطق باستثناء أننا نطلق على TEF القابل للتنفيذ. نستخدم SC هنا للإشارة إلى العقد المنطقي الذي يتم تنفيذه من خلال الجمع بين SCa ونتوقع. (كما هو مذكور أعلاه، نتوقع تطوير أدوات التحويل البرمجي لتحليل ملف التعاقد مع SC تلقائيًا في هذه المكونات.) إن الملف القابل للتنفيذ TEF هو المحرك الذي يعالج معاملات المستخدمين في SC. ذلك يمكن تنفيذه بطريقة فعالة، لأنه يعمل على DON. لديها عدة وظائف: • استيعاب المعاملات: يتم استلام أو جلب معاملات المستخدمين. يمكنها أن تفعل ذلك مباشرة، أي من خلال تقديم المعاملة على DON، أو عبر MAINCHAIN mempool باستخدام MS. • تنفيذ المعاملات بسرعة: تنفيذ المعاملات التي تنطوي على الأصول داخل SC. ويتم ذلك محليًا، أي على DON. • وصول سريع ومنخفض التكلفة إلى oracle / الوصول إلى المحول: يتمتع بإمكانية الوصول الأصلي إلى تقارير oracle وبيانات المحول الأخرى التي تؤدي، على سبيل المثال، إلى أصول أسرع وأرخص وأكثر دقة التسعير من تنفيذ MAINCHAIN. علاوة على ذلك، يتم تقليل الوصول خارج السلسلة oracle التكلفة التشغيلية لـ oracle، وبالتالي تكلفة استخدام النظام، عن طريق تجنب تخزين باهظ الثمن على السلسلة. • المزامنة: يتم إرسال التحديثات بشكل دوري من DON إلى MAINCHAIN، وتحديث SCa. عقد التثبيت هو الواجهة الأمامية لـ MAINCHAIN ​​لـ SC. وباعتباره عنصر الثقة الأعلى في SC، فإنه يخدم عدة أغراض: • حفظ الأصول: يتم إيداع أموال المستخدمين والاحتفاظ بها وسحبها من SCA. • التحقق من المزامنة: قد تتحقق SCa من صحة تحديثات الحالة عند الضرورة عمليات المزامنة، على سبيل المثال، SNARKs المرفقة بـ rollups. • حواجز الحماية: قد تتضمن SCa أحكامًا للحماية من الفساد أو الفشل في التنفيذ. (انظر القسم 7 لمزيد من التفاصيل.) في TEF، يتم حفظ أموال المستخدمين على MAINCHAIN، مما يعني أن DON هو في حد ذاته غير وصاية. اعتمادا على اختيار آلية المزامنة (انظر أدناه)، قد يحتاج المستخدمون للوثوق في DON فقط للحصول على تقارير oracle الدقيقة والمزامنة في الوقت المناسب مع MAINCHAIN. نموذج الثقة الناتج مشابه جدًا لنموذج DEXes القائم على دفتر الطلبات، على سبيل المثال، [2]، والتي تشتمل اليوم بشكل عام على مكون خارج السلسلة لمطابقة الطلبات ومكون onchain للمقاصة والتسوية.لاستخدام مفردات أنظمة الدفع، يمكن للمرء أن يفكر في "التوقع" باعتباره المكون SC مسؤولة عن المقاصة، في حين تتولى SCA التسوية. انظر الشكل 13 للحصول على رسم تخطيطي تصوير TEF. الشكل 13: تخطيطي TEF. في هذا المثال، تمر المعاملات عبر مجمع الذاكرة من MAINCHAIN عبر MS إلى DON. فوائد TEF: يحمل TEF ثلاث فوائد رئيسية: • الأداء العالي: يرث SC إنتاجية DON الأعلى بكثير من MAINCHAIN لكل من المعاملات وتقارير oracle. بالإضافة إلى ذلك، يمكن لـ Exect معالجة المعاملات بشكل أسرع والاستجابة لتقارير oracle بطريقة أكثر توقيتًا من التنفيذ على MAINCHAIN ​​وحده. • رسوم أقل: تعتبر عملية المزامنة أقل حساسية للوقت من معالجة المعاملات، ويمكن إرسال المعاملات من DON إلى MAINCHAIN ​​على دفعات. وبالتالي، فإن الرسوم لكل معاملة على السلسلة (على سبيل المثال، تكاليف الغاز) مع هذا النهج أقل بكثير من العقد الذي يتم تشغيله فقط على MAINCHAIN. • السرية: يمكن جلب آليات السرية الخاصة بـ DON إلى تحمل على SC.

قيود TEF: أحد قيود TEF هو أنه لا يدعم اللحظية عمليات السحب، حيث أنها تتم فقط على شبكة MAINCHAIN: عند إرسال طلب السحب إلى SCa، قد يحتاج المستخدم إلى الانتظار حتى يتم إجراء تحديث الحالة الذي يتضمن معاملة السحب قبل أن تتم الموافقة عليها. نناقش بعض العلاجات الجزئية، ومع ذلك، في القسم 6.2. هناك قيود أخرى على TEF وهي أنه لا يدعم التركيب الذري لـ DeFi العقود على MAINCHAIN، وتحديدًا القدرة على توجيه الأصول عبر عدة DeFi العقود في صفقة واحدة. ومع ذلك، يمكن لـ TEF دعم هذه الذرية بين DeFi العقود التي تعمل على نفس DON. نناقش أيضًا بعض الطرق لمعالجة هذا الأمر المشكلة في القسم 6.2. 6.2 توجيه المعاملات يمكن للمستخدمين إرسال المعاملات الخاصة بـ SC مباشرة إلى DON أو يمكن توجيهها عبر مجمع الذاكرة في MAINCHAIN (عبر FSS). هناك أربعة أنواع مختلفة من المعاملات، لكل منها والتي تتطلب معالجة مختلفة: المعاملات ضمن العقد: ونظرًا لأنه يتجنب تعقيدات ديناميكيات الغاز، فإن TEF يوفر لشركة SC مرونة أكبر في التعامل مع المعاملات مما قد تكون عليه متوفر في عقد الطبقة الأولى. على سبيل المثال، أثناء معاملة mempool في Ethereum يمكن استبدالها بمعاملة جديدة بسعر غاز أعلى، يمكن لـ SC التعامل مع المعاملة التي تعمل على الأصول داخل SC باعتبارها معاملة موثوقة بمجرد أن تصبح مرئية في المذكرة. وبالتالي، لا تحتاج SC إلى الانتظار حتى يتم تأكيد المعاملة داخل كتلة، مما أدى إلى انخفاض كبير في زمن الوصول. الوكيل: قد يرغب المستخدم في إرسال معاملة τ إلى SC عبر عقد محفظة أو عقد آخر على MAINCHAIN. من الممكن أن يقوم DON بمحاكاة تنفيذ τ على MAINCHAIN لتحديد ما إذا كان سيؤدي إلى معاملة متابعة إلى SC. إذا كان الأمر كذلك، فيمكن تسلسل τ مع معاملات أخرى لـ SC تقوم بذلك. هناك عدد قليل إمكانيات كيفية تحديد DON لمثل هذه المعاملات: (1) يمكن لـ DON محاكاة جميع المعاملات في mempool (نهج مكلف)؛ (2) بعض العقود أو يمكن إدراج أنواع العقود، على سبيل المثال، المحافظ، للمراقبة بواسطة DON؛ أو (3) يمكن للمستخدمين قم بإضافة تعليق توضيحي للمعاملات الخاصة بفحص DON. تصبح الأمور أكثر تعقيدًا عندما تتفاعل معاملة واحدة مع اثنتين العقود، SC1 وSC2، وكلاهما يستخدم خدمات التسلسل العادل ولديهما سياسات طلب غير متوافقة. قد يقوم DON، على سبيل المثال، بالتسلسل τ في آخر وقت الذي يتوافق مع كليهما. الودائع: يجب تأكيد المعاملة التي تقوم بإيداع أصل MAINCHAIN في SC في كتلة قبل أن تتمكن SC من التعامل معها على أنها صالحة. عندما يكتشف التعدين أ المعاملة التي ترسل الأصول (على سبيل المثال، الأثير) إلى SCa، يمكن أن تؤكد على الفورإيداع. على سبيل المثال، يمكن تطبيق السعر الحالي الذي تم الإبلاغ عنه oracle على DON على الأصول. عمليات السحب: كما هو مذكور أعلاه، فإن أحد قيود TEF هو أنه لا يمكن دائمًا تنفيذ عمليات السحب على الفور. في نموذج التنفيذ من النوع rollup، يتم السحب يجب أن يكون الطلب متسلسلًا مع المعاملات الأخرى، أي أن يتم تجميعه، حتى يكون آمنًا معالجتها. ومع ذلك، هناك بعض العلاجات الجزئية لهذا القيد. إذا كان DON يمكنه حساب إثبات صحة rollup بسرعة حتى معاملة السحب، فإن مراقبة معاملة المستخدم τ في مجموعة الذاكرة باستثناء يمكن أن ترسل معاملة تحديث الحالة τ ′ لـ τ بسعر غاز أعلى، وهو نوع من التشغيل المسبق المفيد. بشرط ألا يتم تعدين τ قبل أن تصل τ ′ إلى مجمع الذاكرة، فإن τ ′ ستسبق τ، و τ سوف يؤدي إلى انسحاب معتمد. في متغير TEF حيث يتم الاعتماد على DON لحساب تحديثات الحالة (راجع متغير توقيع العتبة أدناه)، يمكن لـ DON تحديد خارج السلسلة بدلاً من ذلك ما إذا كان يجب الموافقة على τ نظرًا لحالة SC عند تنفيذها. DON يمكن بعد ذلك إرسال معاملة τ ′ توافق على السحب τ — دون إجراء كامل تحديث الدولة. إذا لم يكن هذا النهج ممكنًا، أو في الحالات التي لم ينجح فيها، فسيتم بدء DON يمكن للمعاملة τ ′ إرسال أموال إلى المستخدم ردًا على τ بحيث لا يحتاج المستخدم بدء معاملة إضافية. 6.3 المزامنة يقوم الملف القابل للتنفيذ TEF بدفع التحديثات بشكل دوري من DON إلى MAINCHAIN، تحديث حالة SCa في عملية نشير إليها بالمزامنة. يمكن التفكير في المزامنة كانتشار لمعاملات الطبقة الثانية إلى الطبقة الأولى، لذلك يمكن لـ TEF الاعتماد على أي رقم التقنيات الموجودة لهذا الغرض، بما في ذلك rollups [5، 12، 16، 69]، متفائلة rollups [10، 11، 141]، Validium [201]، أو توقيع الحد الأساسي، على سبيل المثال، عتبة BLS، شنور، أو ECDSA [24، 54، 116، 202]. من حيث المبدأ، بيئات التنفيذ الموثوقة يمكن أيضًا أن يشهد على صحة تغييرات الحالة، مما يوفر أداءً أفضل بكثير بديل لـ rollups، ولكن مع نموذج ثقة يعتمد على الأجهزة. (انظر، على سبيل المثال، [80].) نقارن أدناه خيارات المزامنة هذه فيما يتعلق بثلاث خصائص رئيسية في تيف: • توفر البيانات: أين يتم تخزين حالة SC؟ هناك ثلاثة خيارات على الأقل متوفر في TEF: على MAINCHAIN، أو على DON، أو عن طريق وحدة تخزين خارجية مقدمي الخدمات مثل IPFS. إنها تحقق ضمانات أمنية وتوافرًا مختلفًا المستويات وخصائص الأداء. باختصار، يتم تمكين حالة التخزين على MAINCHAIN إمكانية التدقيق على السلسلة ويلغي الاعتماد على أي طرف فيما يتعلق بتوفر الحالة؛ من ناحية أخرى، يمكن أن يؤدي تخزين الحالة خارج السلسلة إلى تقليل تكلفة التخزين وتحسينه الإنتاجية، على حساب موفري خدمات التخزين الموثوقين (DON أو الجهات الخارجية). توفر البيانات. وبطبيعة الحال، هناك أيضًا نماذج مرنة تجمع بين هذه الخيارات ممكن. نشير إلى الشكل المطلوب لتوافر البيانات في الجدول 1.• ضمانات الصحة: كيف تتأكد هيئة الرقابة المالية من صحة التحديثات مدفوعة بالتنفيذ؟ يؤثر هذا على الحمل الحسابي على exect وSCa و مزامنة الكمون (انظر أدناه). • الكمون: هناك ثلاثة عوامل مساهمة في زمن الاستجابة للمزامنة: (1) الوقت المستغرق لتوقع إنشاء معاملة مزامنة τsync؛ (2) الوقت المستغرق لـ τsync للتأكيد على MAINCHAIN؛ و (3) الوقت المناسب لتفعيل المزامنة SCA. في TEF، يعد زمن الوصول مهمًا بشكل خاص لعمليات السحب (لكنه أقل أهمية بالنسبة لعمليات السحب). المعاملات ضمن العقد) لأن عمليات السحب تتطلب بالضرورة (على الأقل جزئي) مزامنة الحالة. المزامنة خيارات البيانات التوفر صحة الضمانات الكمون التراكمي [5، 12، 16، 69] على السلسلة إثباتات الصلاحية الوقت المستغرق لتوليد إثباتات الصلاحية (على سبيل المثال، الدقائق في الأنظمة الحالية) فاليديوم [201] خارج السلسلة إثباتات الصلاحية نفس ما ورد أعلاه متفائل rollup [10، 11، 141] على السلسلة أدلة الاحتيال طول التحدي فترة (على سبيل المثال، أيام أو أسابيع) توقيع العتبة [24، 54، 116، 202] مرنة توقيعات العتبة بواسطة DON لحظية بيئات التنفيذ الموثوقة [80] مرنة على أساس الأجهزة الشهادات لحظية الجدول 1: خيارات المزامنة المختلفة في TEF وخصائصها. يلخص الجدول 1 هذه الخصائص في خيارات المزامنة الرئيسية الخمسة في TEF. (ملاحظة أننا لا ننوي مقارنة هذه التقنيات كقياس مستقل للطبقة الثانية الحلول. ولهذا نحيل القراء إلى، على سبيل المثال، [121].) الآن نناقش كل خيار من خيارات المزامنة. التجميعات: rollup [69] هو بروتوكول يتم فيه انتقال الحالة بواسطة يتم حساب مجموعة المعاملات خارج السلسلة. ثم يتم نشر تغيير الحالة على مينشين. لتنفيذ rollups، يقوم المرساة smart contract SCa بتخزين تمثيل مضغوط Rstate (على سبيل المثال، جذر Merkle) للحالة الفعلية. للمزامنة، يرسل exext τsync = (ت، ر' State) إلى SCa حيث T هي مجموعة المعاملات التي تمت معالجتها منذ آخر مرةالمزامنة وR' الحالة هي التمثيل المضغوط للحالة الجديدة المحسوبة عن طريق التطبيق المعاملات في T إلى الحالة السابقة Rstate. هناك نوعان مختلفان شائعان يختلفان في كيفية قيام SCa بالتحقق من تحديثات الحالة في τsync. الأول، (zk-)rollups، يرفق حجة موجزة للصحة، تسمى أحيانًا دليل صحة للانتقال Rstate →R′ الدولة. لتنفيذ هذا البديل، توقع يحسب ويقدم إثبات الصلاحية (على سبيل المثال، إثبات zk-SNARK) مع τsync، إثبات أن R' الحالة هي نتيجة تطبيق T على الحالة الحالية لـ SCa. المرساة لا يقبل العقد تحديث الحالة إلا بعد التحقق من الدليل. لا تتضمن rollups المتفائلة حجج الصحة، ولكنها تحتوي على staking و إجراءات التحدي التي تسهل التحقق الموزع من تحولات الحالة. لهذا متغير rollup، يقبل SCa مبدئيًا τsync على افتراض أنه صحيح (وبالتالي التفاؤل) لكن τsync لا يصبح ساري المفعول إلا بعد فترة التحدي التي يستطيع خلالها أي طرف يمكن لمراقبة MAINCHAIN تحديد تحديثات الحالة الخاطئة وإبلاغ SCa لاتخاذها الإجراءات الضرورية (على سبيل المثال، التراجع عن الحالة وإيقاع عقوبة على التنفيذ.) يحقق كلا المتغيرين rollup توفر البيانات على السلسلة، حيث يتم ترحيل المعاملات على السلسلة، والتي يمكن من خلالها بناء الحالة الكاملة. زمن الوصول لـ zk-rollups هو يهيمن عليها الوقت اللازم لإنشاء أدلة الصلاحية، والتي عادةً ما تكون على ترتيب الدقائق في الأنظمة الحالية [16] ومن المرجح أن تشهد تحسينات بمرور الوقت. من ناحية أخرى، تتمتع rollups المتفائلة بزمن وصول أعلى (على سبيل المثال، أيام أو أسابيع) لأن فترة التحدي يجب أن تكون طويلة بما يكفي حتى تنجح إثباتات الاحتيال. ال إن الآثار المترتبة على التأكيد البطيء تكون خفية وفي بعض الأحيان خاصة بالمخطط، لذلك التحليل الشامل خارج النطاق. على سبيل المثال، بعض المخططات تأخذ بعين الاعتبار الدفع المعاملات باعتبارها "نهائية غير موثوق بها" [109] قبل تأكيد تحديث الحالة، نظرًا لأن يمكن للمستخدم العادي التحقق من rollup بسرعة أكبر بكثير من MAINCHAIN. فاليديوم: Validium هو شكل من أشكال (zk-)rollup الذي يجعل البيانات متاحة خارج السلسلة فقط ولا يحتفظ بجميع البيانات الموجودة على MAINCHAIN. على وجه التحديد، exect يرسل الجديد فقط الدولة والدليل ولكن ليس المعاملات إلى SCa. مع المزامنة على غرار Validium، توقع وDON الذي ينفذها هما الطرفان الوحيدان اللذان يخزنان الحالة الكاملة و التي تنفذ المعاملات. كما هو الحال مع zk-rollups، تهيمن الصلاحية على زمن وصول المزامنة وقت توليد الإثبات. على عكس zk-rollups، فإن مزامنة نمط Validium تقلل من تكلفة التخزين ويزيد من الإنتاجية. توقيع الحد بواسطة DON: بافتراض أن عتبة العقد DON صادقة، أ خيار المزامنة البسيط والسريع هو جعل العقد DON توقع بشكل جماعي على الحالة الجديدة. يمكن أن يدعم هذا النهج توفر البيانات على السلسلة وخارجها. لاحظ أنه إذا يثق المستخدمون في DON لتحديثات oracle، ولا يحتاجون إلى الوثوق بها أكثر لقبولها تحديثات الحالة، لأنها موجودة بالفعل في نموذج ثقة العتبة. فائدة أخرى من توقيع العتبة هو الكمون المنخفض. دعم تنسيقات توقيع المعاملات الجديدة مثل المقترح في EIP-2938 [70] والمعروف باسم تجريد الحساب من شأنه أن يجعل العتبة التوقيع أسهل بكثير في التنفيذ، لأنه من شأنه أن يلغي الحاجة إلى العتبة ECDSA، والذي يتضمن بروتوكولات أكثر تعقيدًا إلى حد كبير (على سبيل المثال، [116، 117، 118])من البدائل مثل عتبة Schnorr [202] أو BLS [55] التوقيعات. بيئات التنفيذ الموثوقة (TEEs): TEEs هي بيئات تنفيذ معزولة (يتم تحقيقها عادةً بواسطة الأجهزة) تهدف إلى توفير حماية أمنية قوية للبرامج التي تعمل بالداخل. يمكن لبعض TEEs (على سبيل المثال، Intel SGX [84]) إنتاج أدلة، المعروفة باسم الشهادات، والتي يتم حساب المخرجات بشكل صحيح بواسطة برنامج محدد مدخلات معينة12. يمكن تنفيذ متغير قائم على TEE لمزامنة TEF بواسطة استبدال البراهين في (zk-)rollups أو Validium بشهادات TEE باستخدام التقنيات من [80]. بالمقارنة مع براهين المعرفة الصفرية المستخدمة في rollups وValidium، فإن TEEs أكثر أهمية أكثر أداء. بالمقارنة مع توقيع العتبة، فإن TEEs تزيل التعقيد توليد توقيعات عتبة ECDSA حيث يلزم من حيث المبدأ أن يكون هناك TEE واحد فقط المعنية. ومع ذلك، فإن استخدام TEEs يقدم افتراضات ثقة إضافية تعتمد على الأجهزة. يمكن للمرء أيضًا الجمع بين TEEs وتوقيع العتبة لخلق المرونة ضد التنازل عن جزء صغير من حالات TEE، على الرغم من أن هذا الإجراء الوقائي يعيد تقديم تعقيد إنشاء توقيعات عتبة ECDSA. مرونة إضافية: يمكن تحسين خيارات المزامنة هذه لتوفير المزيد من المرونة بالطرق التالية. • التشغيل المرن: يمكن لتطبيق TEF تحديد الظروف التي يتم بموجبها يتم تشغيل المزامنة. على سبيل المثال، يمكن أن تكون المزامنة مبنية على دفعات، على سبيل المثال، يمكن أن تتم بعد ذلك كل N من المعاملات، على أساس الوقت، على سبيل المثال، كل 10 كتل، أو على أساس الحدث، على سبيل المثال، تحدث كلما تحركت أسعار الأصول المستهدفة بشكل كبير. • المزامنة الجزئية: من الممكن، وفي بعض الحالات، مرغوبة (على سبيل المثال، مع rollups، يمكن أن تؤدي المزامنة الجزئية إلى تقليل زمن الوصول) لتوفير مزامنة سريعة للملفات الصغيرة كميات من الحالة، وإجراء المزامنة الكاملة ربما بشكل دوري فقط. على سبيل المثال، يمكن الموافقة على طلب السحب عن طريق تحديث رصيد المستخدم في SCa دون تحديث حالة MAINCHAIN. 6.4 يعيد التنظيم عمليات إعادة تنظيم Blockchain الناتجة عن عدم استقرار الشبكة أو حتى من هجمات 51٪ يمكن أن يشكل تهديدًا لسلامة السلسلة الرئيسية. ومن الناحية العملية، استخدم الخصوم لهم لشن هجمات الإنفاق المزدوج [34]. في حين أن مثل هذه الهجمات على السلاسل الرئيسية هي من الصعب تركيبها، تظل ممكنة بالنسبة لبعض السلاسل [88]. نظرًا لأنه يعمل بشكل مستقل عن MAINCHAIN، فإن DON يقدم الميزات المثيرة للاهتمام إمكانية مراقبة وتوفير بعض الحماية ضد عمليات إعادة التنظيم المرتبطة بها الهجمات. على سبيل المثال، يمكن لـ DON أن يبلغ عقدًا معتمدًا SC على MAINCHAIN ​​بوجود شوكة منافسة بطول حد معين τ. يمكن لـ DON بالإضافة إلى ذلك 12يمكن الاطلاع على التفاصيل التكميلية في الملحق ب.2.1. ليست مطلوبة للتفاهم.

تقديم دليل - سواء في إعداد إثبات العمل (PoW) أو إثبات الحصة (PoS) - على وجود مثل هذه الشوكة. ال يمكن لعقد SC تنفيذ إجراءات دفاعية مناسبة، مثل تعليق تنفيذ المزيد من المعاملات لفترة من الوقت (على سبيل المثال، للسماح للتبادلات بإدراج عمليات الإنفاق المزدوج في القائمة السوداء الأصول). لاحظ أنه على الرغم من أن الخصم الذي يشن هجومًا بنسبة 51% يمكنه أن يسعى إلى فرض الرقابة التقارير من DON، الإجراء المضاد في SC هو طلب تقارير دورية من DON لمعالجة المعاملات (أي نبضات القلب) أو لطلب تقرير جديد التحقق من صحة صفقة ذات قيمة عالية. في حين أن تنبيهات التفرع هذه هي من حيث المبدأ خدمة عامة يمكن أن يقدمها DON ولأي عدد من الأغراض، فإن خطتنا هي دمجها مع TEF.

التقليل من الثقة

باعتباره نظامًا لا مركزيًا بمشاركة مجموعة غير متجانسة من الكيانات، فإن توفر شبكة Chainlink حماية قوية ضد حالات الفشل في كل من الحيوية (التوفر) والسلامة (تكامل التقرير). ومع ذلك، تختلف معظم الأنظمة اللامركزية الدرجة التي تكون فيها المكونات المكونة لها هي نفسها لا مركزية. هذا وهذا ينطبق حتى على الأنظمة الكبيرة، حيث اللامركزية محدودة بين القائمين بالتعدين [32] و الوسطاء [51] موجودون منذ فترة طويلة. الهدف من أي جهد لتحقيق اللامركزية هو تقليل الثقة: نسعى إلى تقليل الثقة الآثار السلبية للفساد النظامي أو الفشل داخل شبكة Chainlink، حتى تلك بسبب DON الخبيثة. المبدأ التوجيهي لدينا هو مبدأ الامتياز الأقل [197]. يجب أن تتمتع مكونات النظام والجهات الفاعلة داخل النظام بامتيازات محددة النطاق بشكل صارم للسماح فقط بإكمال الأدوار المخصصة لهم بنجاح. نعرض هنا العديد من الآليات الملموسة التي يجب على Chainlink اعتمادها في مسيرتها نحو تقليل الثقة بشكل أكبر من أي وقت مضى. نحن نميز هذه الآليات من حيث للمواقع، أي مكونات النظام، التي تتجذر فيها، كما هو موضح في الشكل 14. نحن معالجة كل موضع في القسم الفرعي المعني. 7.1 مصادقة مصدر البيانات نماذج التشغيل الحالية لـ oracles مقيدة بحقيقة قلة مصادر البيانات قم بالتوقيع رقميًا على البيانات التي حذفوها، ويرجع ذلك إلى حد كبير إلى أن TLS لا يوقع أصلاً data. يستخدم TLS التوقيعات الرقمية في بروتوكول "المصافحة" الخاص به (لتأسيس مفتاح مشترك بين الخادم والعميل). وبالتالي فإن الخوادم التي تدعم HTTPS لديها شهادات على المفاتيح العامة التي يمكن من حيث المبدأ أن تعمل على توقيع البيانات، لكنها لا تستخدم بشكل عام هذه الشهادات لدعم توقيع البيانات. وبالتالي، فإن أمان DON، مثل في شبكات oracle اليوم، يعتمد على oracle العقد التي تنقل البيانات بأمانة من البيانات مصدر للعقد. يتضمن أحد المكونات المهمة طويلة المدى لرؤيتنا لتقليل الثقة في Chainlink مصادقة أقوى لمصدر البيانات من خلال دعم الأدوات والمعايير لتوقيع البيانات. يمكن أن يساعد توقيع البيانات في فرض ضمانات السلامة الشاملة. من حيث المبدأ، إذا كان العقد يقبل كمدخل قطعة من البيانات D موقعة مباشرة بواسطة البيانات

الشكل 14: مواقع آليات تقليل الثقة التي تمت مناقشتها في هذا القسم. 1⃝البيانات توفر المصادر البيانات إلى 2⃝DON، الذي ينقل وظيفة البيانات إلى تابع 3⃝smart contract. بالإضافة إلى ذلك، تتضمن شبكة DON أو oracle 4⃝ عقدة إدارة smart contracts على MAINCHAIN، على سبيل المثال، العقد التعويضية، والحماية القضبان، وما إلى ذلك. المصدر، فإن شبكة oracle لا يمكنها التلاعب بـ D. العديد من المشجعات وقد ظهرت جهود لتمكين مثل هذا التوقيع على البيانات، بما في ذلك OpenID Connect، الذي تم تصميمه بشكل أساسي لمصادقة المستخدم [9]، TLS-N، وهو مشروع أكاديمي يهدف إلى قم بتمديد TLS [191] عن طريق إعادة استخدام شهادات TLS وامتدادات أدلة TLS [63]. على الرغم من أن OpenID Connect قد شهد بعض التبني، إلا أن TLS Evidence Extensions و TLS-N لم يتم اعتمادهما بعد. هناك طريقة أخرى محتملة للتحقق من مصدر البيانات وهي استخدام مصادر البيانات الخاصة بالناشرين تبادلات HTTP الموقعة (SXG) [230]، والتي يمكنهم تخزينها مؤقتًا على شبكات تسليم المحتوى كجزء من بروتوكول Accelerated Mobile Pages (AMP) [225]. يعرض متصفح Chrome للجوال المحتوى من SXGs المخزنة مؤقتًا لـ AMP كما لو تم تقديمها منه مجالات الشبكة الخاصة بالناشرين بدلاً من مجال خادم ذاكرة التخزين المؤقت. قد يؤدي حافز العلامة التجارية هذا، إلى جانب السهولة النسبية لتمكينه باستخدام خدمات مثل عنوان URL الحقيقي الخاص بـ CloudFlare [83] وGoogle amppackager [124]، إلى اعتماد واسع النطاق لـ SXGs في محتوى الأخبار المخزن مؤقتًا، مما قد يؤدي إلى تمكين عملية بسيطة ومقاومة للتلاعب طريقة لـ Chainlink oracles لتشغيل الأحداث الجديرة بالنشر التي تم الإبلاغ عنها في SXGs الصالحة. في حين أن ملفات SXG المخزنة مؤقتًا لـ AMP من ناشري الأخبار لن تكون مفيدة للإيقاع العالي التطبيقات مثل التقارير الخاصة ببيانات التداول، يمكن أن تكون مصدرًا آمنًا للتخصيص العقود المتعلقة بأحداث العالم الحقيقي مثل الطقس القاسي أو نتائج الانتخابات. نحن نؤمن بأن النشر البسيط والأدوات الناضجة والمرونة ستكون أمرًا حيويًا تسريع توقيع مصدر البيانات. تمكين موفري البيانات من استخدام العقد Chainlink كـ تبدو الواجهة الأمامية لواجهة برمجة التطبيقات (API) المصادق عليها بمثابة نهج واعد. نحن نعتزم إنشاءخيار للعقد للعمل في هذا الوضع، مع أو بدون المشاركة في الشبكة باعتباره oracle كاملًا. ونحن نشير إلى هذه القدرة على أنها إنشاء بيانات موثقة (أدو). باستخدام عقد Chainlink مع ADO، ستتمكن مصادر البيانات من الاستفادة من الخبرة والأدوات التي طورها مجتمع Chainlink في الإضافة الرقمية إمكانات التوقيع على مجموعتهم الحالية من واجهات برمجة التطبيقات خارج السلسلة. هل يجب أن يختاروا الركض؟ عقدها كـ oracles، يمكنها بالإضافة إلى ذلك فتح مصادر دخل جديدة محتملة وفقًا لنفس النموذج مثل موفري البيانات الحاليين، على سبيل المثال، Kraken [28]، Kaiko [140]، و والبعض الآخر، الذي يقوم بتشغيل Chainlink العقد لبيع بيانات API على السلسلة. 7.1.1 القيود المفروضة على إنشاء البيانات المصادق عليها التوقيع الرقمي من خلال مصادر البيانات، على الرغم من أنه يمكن أن يساعد في تعزيز المصادقة، إلا أنه لا يكفي في حد ذاته لتحقيق جميع الأهداف الأمنية أو التشغيلية الطبيعية لـ oracle شبكة. للبدء، يجب أن يتم نقل جزء معين من البيانات بطريقة قوية وفي الوقت المناسب من مصدر البيانات إلى smart contract أو مستهلك بيانات آخر. أي حتى في إعداد مثالي يتم فيه توقيع جميع البيانات باستخدام مفاتيح مبرمجة مسبقًا لتصبح تابعة العقود، ستظل هناك حاجة إلى DON لتوصيل البيانات بشكل موثوق من المصادر إلى العقود. بالإضافة إلى ذلك، هناك عدد من الحالات التي تكون فيها العقود أو بيانات oracle الأخرى يريد المستهلكون الوصول إلى المخرجات المصادق عليها لمختلف الوظائف المحسوبة مصدر البيانات لسببين رئيسيين: • السرية: قد توفر واجهة برمجة تطبيقات مصدر البيانات بيانات حساسة أو خاصة التي يجب تنقيحها أو تطهيرها قبل أن تصبح مرئية للعامة على السلسلة. ومع ذلك، فإن أي تعديل على البيانات الموقعة يبطل التوقيع. ضع آخر الطريقة، ADO السذاجة وتعقيم البيانات غير متوافقة. نعرض في المثال 3 كيف يمكن التوفيق بين الاثنين من خلال نموذج محسّن من ADO. • أخطاء مصدر البيانات: يمكن أن تؤثر الأخطاء والفشل على مصادر البيانات، ولا تعالج التوقيعات الرقمية أي مشكلة. منذ بدايتها [98]، Chainlink لديها لقد أدرجت بالفعل آلية لمعالجة مثل هذه الأخطاء: التكرار. عادةً ما تمثل التقارير الصادرة عن شبكات oracle البيانات المجمعة المتعددة مصادر. نناقش الآن المخططات التي نستكشفها في إعداد ADO لتعزيز سرية البيانات المصدر ودمج البيانات من مصادر متعددة بشكل آمن. 7.1.2 السرية قد لا تتوقع مصادر البيانات النطاق الكامل لواجهات برمجة التطبيقات المطلوبة وتتيحه من قبل المستخدمين. وعلى وجه التحديد، قد يرغب المستخدمون في الوصول إلى البيانات المعالجة مسبقًا للمساعدة في ضمان ذلك السرية. يوضح المثال التالي المشكلة.مثال 3. ترغب أليس في الحصول على بيانات اعتماد الهوية اللامركزية (DID). أن عمرها يتجاوز 18 عامًا (وبالتالي يمكنها، على سبيل المثال، الحصول على قرض). للقيام به لذا، فهي بحاجة إلى إثبات هذه الحقيقة المتعلقة بعمرها إلى جهة إصدار أوراق اعتماد اضطراب الشخصية الانفصامية. تأمل أليس في استخدام البيانات من إدارة المركبات الآلية (DMV) في ولايتها موقع الكتروني لهذا الغرض. لدى DMV سجل بتاريخ ميلادها وسوف ينبعث منها ملف شهادة موقعة رقميا (أ) عليها بالنموذج التالي: أ = {الاسم: أليس، DoB: 16/02/1999}. في هذا المثال، قد تكون الشهادة A كافية لإثبات أليس لاضطراب الشخصية الانفصامية مصدر أوراق الاعتماد أن عمرها يزيد عن 18 عامًا. لكنها تسرب معلومات حساسة بلا داعٍ: معلومات أليس DoB بالضبط. من الناحية المثالية، ما تريده أليس من DMV بدلاً من ذلك هو التوقيع على ملف عبارة بسيطة أ′ مفادها أن "عمر أليس يزيد عن 18 عامًا." وبعبارة أخرى، فهي تريد إخراج الدالة G في تاريخ ميلادها X، حيث (بشكل غير رسمي)، A′ = G(X) = True if التاريخ الحالي −X ≥18 سنة؛ وبخلاف ذلك، G(X) = خطأ. للتعميم، تود أليس أن تكون قادرة على طلب توقيع من مصدر البيانات الإقرار "أ" من النموذج: A′ = {الاسم: أليس، الوظيفة:G(X)، النتيجة: صحيح}، حيث تشير G(X) إلى مواصفات الدالة G ومدخلاتها (مدخلاتها) X. نحن نتصور أن المستخدم يجب أن يكون قادرًا على تقديم G(X) المطلوب كمدخل مع طلبه للحصول على الشهادة المقابلة أ'. لاحظ أن شهادة مصدر البيانات A′ يجب أن تتضمن المواصفات G(X) الخاصة بها تأكد من تفسير A′ بشكل صحيح. في المثال أعلاه، يحدد G(X) المعنى للقيمة المنطقية في A′ وبالتالي فإن True يدل على موضوع الشهادة يزيد عمره عن 18 عامًا. نشير إلى الاستعلامات المرنة التي يمكن للمستخدم من خلالها تحديد G(X) كاستعلامات وظيفية. من أجل دعم حالات الاستخدام مثل تلك الموجودة في المثال 3، بالإضافة إلى تلك التي تتضمن استعلامات مباشرة من العقود، نعتزم تضمين الدعم للاستفسارات الوظيفية التي تنطوي على وظائف بسيطة G كجزء من ADO. 7.1.3 الجمع بين بيانات المصدر لتقليل التكاليف على السلسلة، تم تصميم العقود بشكل عام لاستهلاك البيانات المجمعة من مصادر متعددة، كما هو موضح في المثال التالي. المثال 4 (توسيط بيانات الأسعار). لتوفير تغذية الأسعار، أي قيمة واحدة الأصل (على سبيل المثال، ETH) فيما يتعلق بأصل آخر (على سبيل المثال، الدولار الأمريكي)، فإن شبكة oracle ستتم بشكل عام الحصول على الأسعار الحالية من عدد من المصادر، مثل البورصات. شبكة oracle يرسل عادةً إلى العقد التابع SC متوسط هذه القيم. في بيئة تحتوي على توقيع البيانات، يتم الحصول على شبكة oracle تعمل بشكل صحيح من مصادر البيانات S = {S1, . . . , SnS} سلسلة من القيم V = {v1, v2, . . . ، vnS} من مصادر nS المصاحبة للتوقيعات الخاصة بالمصدر Σ = {σ1, σ2, . . . ، σnS}. على التحقق من التوقيعات، فإنه ينقل السعر v = الوسيط (V ) إلى SC.لسوء الحظ، لا توجد طريقة بسيطة لشبكة oracle لنقل الوسيط القيمة v في المثال 4 إلى SC مع دليل موجز σ∗ أنه تم حساب v بشكل صحيح على المدخلات الموقعة. قد يكون النهج الساذج هو تشفير المفاتيح العامة لجميع مصادر بيانات nS في SC. ستقوم الشبكة oracle بعد ذلك بترحيل (V, Σ) وتسمح لـ SC بحساب متوسط ​​V . ومع ذلك، قد يؤدي هذا إلى إثبات σ للحجم O(nS) — أي أن σ∗ لن يكون موجزًا. كما أنه سيتكبد تكاليف غاز عالية بالنسبة لشركة SC، والتي ستحتاج إلى التحقق من جميع التوقيعات فيها Σ. في المقابل، يتيح استخدام SNARKs دليلاً موجزًا ​​لقيم المصدر الموثقة المدمجة بشكل صحيح. قد يكون الأمر قابلاً للتطبيق في الممارسة العملية، لكنه يفرض نسبة عالية إلى حد ما التكاليف الحسابية على المُثبِّت، وتكاليف الغاز المرتفعة إلى حدٍ ما على السلسلة. استخدام يعد Town Crier أيضًا احتمالًا، ولكنه يتطلب استخدام TEEs، وهو ما لا يناسب الجميع نماذج ثقة المستخدمين. أحد المفاهيم المفيدة التي يمكن من خلالها وضع حلول للمشكلة العامة المتمثلة في توقيع البيانات المجمعة من المصادر هو أداة التشفير المعروفة باسم التوقيعات الوظيفية [59، 132]. باختصار، تسمح التوقيعات الوظيفية للموقّع بتفويض القدرة على التوقيع، على هذا النحو يمكن للمفوض فقط التوقيع على الرسائل في نطاق الوظيفة F التي اختارها الموقع. نوضح في الملحق د كيف يمكن لهذا القيد الوظيفي أن يعمل على تقييد النطاق لقيم التقرير المنبعثة من DON كدالة للقيم الموقعة بواسطة مصادر البيانات. نقدم أيضًا بدائيًا جديدًا، يُسمى التوقيع الوظيفي المنفصل، والذي يتضمن متطلبًا مريحًا للدقة، ولكنه من المحتمل أن يكون أكثر أداءً من الأساليب مثل SNARKs. مشكلة دمج مصادر البيانات بطريقة تتضمن توثيق المصدر من المخرجات تنطبق أيضًا على مجمعي البيانات، على سبيل المثال، CoinCap، وCoinMarketCap، وCoinGecko، CryptoCompare، وما إلى ذلك، التي تحصل على البيانات من عدد كبير من البورصات، والتي تقوم بها الوزن على أساس المجلدات، باستخدام المنهجيات التي يعلنونها في بعض الحالات وتكون في حالات أخرى مملوكة. المجمع الذي يرغب في نشر قيمة معه تواجه مصادقة المصدر نفس التحدي الذي تواجهه مجموعة من العقد المجمعة بيانات المصدر. 7.1.4 معالجة بيانات المصدر من المرجح أن تعتمد smart contracts المتطورة على إحصائيات مجمعة مخصصة مصادر البيانات الأولية، مثل التقلبات في تاريخ الأسعار الحديث على العديد من الأصول، أو النصوص والصور من الأخبار حول الأحداث ذات الصلة. نظرًا لأن الحساب وعرض النطاق الترددي رخيصان نسبيًا في DON، فإن هذه الإحصائيات — حتى نماذج التعلم الآلي المعقدة التي تحتوي على العديد من المدخلات - يمكن معالجتها اقتصاديًا، طالما أن أي قيمة مخرجات مخصصة لـ blockchain موجزة بدرجة كافية. بالنسبة للمهام الحسابية المكثفة حيث قد يختلف المشاركون في DON وجهات النظر حول المدخلات المعقدة، قد تكون هناك حاجة إلى جولات إضافية من الاتصال بين المشاركين في DON للتوصل إلى توافق في الآراء حول المدخلات قبل حساب النتيجة. وطالما تم تحديد القيمة النهائية بالكامل من خلال المدخلات، بمجرد التوصل إلى إجماع على المدخلات، يمكن لكل مشارك ببساطة حساب القيمة وبثها إلى الآخرالمشاركين مع توقيعهم الجزئي، أو إرساله إلى المجمع. 7.2 DON تقليل الثقة نحن نتصور طريقتين رئيسيتين لتقليل الثقة الموضوعة في مكونات DON: عملاء تجاوز الفشل وتقارير الأقلية. 7.2.1 عملاء تجاوز الفشل النماذج العدائية في علم التشفير وأدبيات الأنظمة الموزعة عادةً النظر في وجود خصم قادر على إفساد (أي المساومة) مجموعة فرعية من العقد، على سبيل المثال، أقل من الثلث للعديد من بروتوكولات BFT. ومع ذلك، فمن الملاحظ عادة، أنه إذا كانت جميع العقد تشغل برنامجًا متطابقًا، فإن الخصم الذي يتعرف على استغلال مميت يمكن أن يفعل ذلك من حيث المبدأ، فإنه يؤدي إلى تسوية جميع العقد بشكل أو بآخر في وقت واحد. هذا الإعداد في كثير من الأحيان يشار إليها باسم الثقافة الأحادية البرمجية [47]. تم طرح مقترحات مختلفة للتنويع التلقائي للبرامج وتكوينات البرامج لمعالجة المشكلة، على سبيل المثال، [47، 113]. كما هو مذكور في [47]، ومع ذلك، يعد تنوع البرامج مسألة معقدة وتتطلب دراسة متأنية. على سبيل المثال، قد يؤدي تنويع البرمجيات إلى ظروف أمنية أسوأ من الثقافة الأحادية يزيد من سطح هجوم النظام وبالتالي يزيد من ناقلات الهجوم المحتملة المزايا الأمنية التي تقدمها. نحن نؤمن بأن دعم عملاء تجاوز الفشل الأقوياء — أي العملاء الذين تنتمي إليهم العقد يمكن أن يتحول في مواجهة حدث كارثي - وهو شكل جذاب بشكل خاص تنويع البرمجيات. لا يقوم عملاء تجاوز الفشل بزيادة عدد المتجهات المحتملة للهجوم، حيث لم يتم نشرها كبرامج رئيسية. أنها توفر فوائد واضحة، ومع ذلك، كخط دفاع ثان. نعتزم دعم عملاء تجاوز الفشل في DONs كـ وسيلة رئيسية لتقليل اعتمادهم على عميل واحد للأمان. Chainlink لديه بالفعل نظام قوي لعملاء تجاوز الفشل. نهجنا يتضمن الحفاظ على إصدارات العميل السابقة التي تم اختبارها في المعركة. اليوم، على سبيل المثال، Chainlink العقد مع التقارير خارج السلسلة (OCR) كعميلها الأساسي تتضمن الدعم لنظام FluxMonitor السابق الخاص بـ Chainlink إذا لزم الأمر. وقد تم استخدامها لبعض بمرور الوقت، تلقت FluxMonitor عمليات تدقيق أمنية واختبارات ميدانية. وهو يوفر نفس الشيء وظيفة مثل التعرف الضوئي على الحروف، بتكلفة أعلى - وهي تكلفة يتم تكبدها فقط على أساس الحاجة. 7.2.2 تقارير الأقليات بالنظر إلى وجود أقلية كبيرة بما فيه الكفاية في مجموعة "الأهمية" - وهي جزء صغير من العقد الصادقة التي تراقب المخالفات من قبل الأغلبية - فقد يكون من المفيد بالنسبة لهم إنشاء أقلية تقرير. هذا عبارة عن تقرير أو علامة موازية، يتم ترحيلها إلى عقد تابع لـ SC على السلسلة بواسطة الأومية. يمكن للجنة العليا الاستفادة من هذا العلم وفقًا لسياستها الخاصة بالعقد. على سبيل المثال، بالنسبة للعقد الذي تكون فيه السلامة أكثر أهمية من الحيوية أو الاستجابة، قد يؤدي تقرير الأقلية إلى مطالبة العقد بتقارير تكميلية من DON آخر، أو قم بتشغيل قاطع الدائرة الكهربائية (انظر القسم التالي).يمكن لتقارير الأقلية أن تلعب دوراً هاماً حتى عندما تكون الأغلبية صادقة، لأن أي نظام لتجميع التقارير، حتى لو كان يستخدم التوقيعات الوظيفية، يجب أن يكون كذلك تعمل بطريقة عتبة، لضمان المرونة ضد oracle أو فشل البيانات. في وبعبارة أخرى، يجب أن يكون من الممكن إنتاج تقرير صالح بناءً على مدخلات kS < nS oracles، بالنسبة لبعض العتبات kS. وهذا يعني أن DON تالف به بعض خط العرض في معالجة قيم التقرير عن طريق تحديد قيم kS المفضلة له من بين تم الإبلاغ عن nS في V بواسطة المجموعة الكاملة من oracles، حتى لو كانت جميع المصادر صادقة. على سبيل المثال، لنفترض أن nS = 10 وkS = 7 في نظام يستخدم وظيفة التوقيع لمصادقة حساب الوسيط على V لسعر ETH بالدولار الأمريكي. لنفترض أن خمسة مصادر أبلغت عن سعر \(500, while the other five report \)1000. ثم من خلال توسط التقارير السبعة الأدنى، يمكن لـ DON إخراج قيمة صالحة v = $500، ومن خلال توسط الأعلى، يمكن إخراج v = 1000 دولار. من خلال تعزيز بروتوكول DON بحيث تكون جميع العقد على علم بالبيانات الموجودة المتاحة، والبيانات التي تم استخدامها لإنشاء تقرير، يمكن للعقد اكتشافها ووضع علامة عليها ميول ذات دلالة إحصائية لتفضيل مجموعة واحدة من التقارير على أخرى، وإنتاجها تقرير أقلية نتيجة لذلك. 7.3 قضبان الحراسة نموذج الثقة الخاص بنا لـ DONs يعامل MAINCHAIN باعتباره أمانًا أعلى وامتيازًا أعلى النظام من DONs. (على الرغم من أن نموذج الثقة هذا قد لا يكون صحيحًا دائمًا، إلا أنه أسهل لتكييف الآلية الناتجة مع المواقف التي يكون فيها DON هو الأمان الأعلى منصة وليس العكس.) وبالتالي، تتضمن إستراتيجية تقليل الثقة الطبيعية تنفيذ آليات المراقبة والتأمين من الفشل في smart contracts — إما في الواجهة الأمامية لـ MAINCHAIN لـ DON أو مباشرة في عقد تابع SC. ونشير إلى هذه الآليات باسم قضبان الحماية، ونذكر بعضًا من أهمها هنا: • قواطع الدائرة: قد تقوم SC بإيقاف تحديثات الحالة مؤقتًا أو إيقافها كوظيفة لأي من خصائص تحديثات الحالة نفسها (على سبيل المثال، التباين الكبير عبر التسلسل التقارير) أو بناءً على مدخلات أخرى. على سبيل المثال، قد يتعطل قاطع الدائرة الكهربائية الحالات التي تختلف فيها تقارير oracle بشكل غير معقول بمرور الوقت. قد يكون قاطع الدائرة الكهربائية أيضا أن تتعثر من خلال تقرير الأقلية. وبالتالي، يمكن أن تمنع قواطع الدائرة DONs من تقديم تقارير خاطئة بشكل صارخ. يمكن أن توفر قواطع الدائرة الوقت اللازم للنظر في تدخلات إضافية أو تمارس. أحد هذه التدخلات هو فتحات الهروب. • فتحات الهروب: في ظل الظروف المعاكسة، كما تحددها مجموعة من الأمناء أو أصحاب token المجتمع أو هيئات الأمناء الأخرى، قد يتم استدعاء العقد منشأة الطوارئ تسمى أحيانًا فتحة الهروب [163]. فتحة الهروب يتسبب في إغلاق SC بطريقة ما و/أو إنهاء الأمر المعلق وربما المعاملات المستقبلية. على سبيل المثال، قد تقوم بإرجاع الأموال المحفوظة إلى المستخدمين [17])،يجوز له إنهاء شروط العقد [162]، أو يجوز له إلغاء المعاملات المعلقة و/أو المعاملات المستقبلية [173]. يمكن نشر فتحات الهروب في أي نوع من العقود، وليس فقط واحدة تعتمد على DON، ولكنها ذات أهمية كمنطقة عازلة محتملة ضد DON المخالفات. • تجاوز الفشل: في الأنظمة التي تعتمد فيها SC على DON للخدمات الأساسية، من الممكن أن توفر SC آليات تجاوز الفشل التي تضمن استمرار الخدمة حتى في حالة DON الفشل أو سوء السلوك. على سبيل المثال، في TEF (القسم 6)، قد يوفر عقد الارتساء SCa واجهات مزدوجة حيث يمكن لكل من السلسلة و يتم دعم واجهات التنفيذ خارج السلسلة لبعض العمليات الهامة (على سبيل المثال، السحب)، أو للمعاملات العادية، مع تأخير مناسب لمنع التشغيل الأولي لمعاملات DON. في الحالات التي تقوم فيها مصادر البيانات بالتوقيع على البيانات، يمكن للمستخدمين ذلك قم أيضًا بتقديم التقارير إلى SCa عندما يفشل DON في القيام بذلك. أدلة الاحتيال، كما هو مقترح لأشكال مختلفة من التفاؤل rollup (انظر القسم 6.3)، متشابهة في النكهة ومكملة للآليات التي ذكرناها أعلاه. هم توفر أيضًا شكلاً من أشكال المراقبة والحماية على السلسلة ضد الأعطال المحتملة في مكونات النظام خارج السلسلة. 7.4 الحوكمة قليلة الثقة مثل كافة الأنظمة اللامركزية، تتطلب شبكة Chainlink آليات حوكمة لضبط المعلمات مع مرور الوقت، والاستجابة لحالات الطوارئ، وتوجيه تطورها. بعض هذه الآليات موجودة حاليًا على MAINCHAIN، وقد تستمر افعل ذلك حتى مع نشر DONs. أحد الأمثلة على ذلك هو آلية الدفع لموفري العقد oracle (DON العقد). DON العقود الأمامية على MAINCHAIN تحتوي على آليات إضافية، مثل حواجز الحماية، التي قد تخضع للفحص الدوري التعديل. نتوقع فئتين من آليات الحكم: التطورية والطارئة. الحكم التطوري: العديد من التعديلات على النظام البيئي Chainlink موجودة بحيث لا يكون تنفيذها مسألة ملحة: تحسينات الأداء، تحسينات الميزات، وترقيات الأمان (غير العاجلة)، وما إلى ذلك. مع تحرك Chainlink تدريجيًا نحو المزيد من المشاركين في إدارتها، نتوقع وجود عدد كبير أو يجب أن يتم التصديق على معظم هذه التغييرات من قبل مجتمع DON المحدد المتأثر بتلك التغييرات التغييرات. في هذه الأثناء، وربما في نهاية المطاف كآلية موازية، نعتقد أن فكرة الامتياز الزمني الأقل يمكن أن تكون وسيلة مفيدة لتنفيذ الحكم التطوري. بكل بساطة، الفكرة هي نشر التغييرات تدريجيًا، وضمان ذلك فرصة للمجتمع للرد عليها. على سبيل المثال، الهجرة إلى مكان جديد يمكن تقييد عقد MAINCHAIN بحيث يجب نشر العقد الجديد قبل ثلاثين يومًا على الأقل من التنشيط.إدارة الطوارئ: نقاط الضعف القابلة للاستغلال أو المستغلة في MAINCHAIN قد تتطلب العقود أو غيرها من أشكال الفشل في الحياة أو السلامة تدخلاً فوريًا لضمان عدم حدوث نتائج كارثية. هدفنا هو دعم multisig آلية التدخل التي من خلالها، لضمان ضد المخالفات من قبل أي منظمة، سيتم توزيع الموقعين عبر المنظمات. ضمان التوافر المستمر للموقعين والوصول في الوقت المناسب إلى التسلسل القيادي المناسب للتصريح بحالات الطوارئ من الواضح أن التغييرات ستتطلب تخطيطًا تشغيليًا دقيقًا ومراجعة منتظمة. هذه التحديات مماثلة لتلك المشاركة في اختبار الاستجابة لحوادث الأمن السيبراني الأخرى القدرات [134]، مع حاجة مماثلة لمكافحة المشاكل الشائعة مثل انخفاض اليقظة [223]. تختلف إدارة DONs عن العديد من الأنظمة اللامركزية في الدرجة المحتملة من عدم التجانس. قد يحتوي كل DON على مصادر بيانات مميزة، وملفات قابلة للتنفيذ، ومتطلبات مستوى الخدمة مثل وقت التشغيل، والمستخدمين. شبكة Chainlink ويجب أن تكون آليات الإدارة مرنة بما يكفي لاستيعاب مثل هذه الاختلافات الأهداف والمعايير التشغيلية. نحن نستكشف بنشاط أفكار التصميم ونخطط لذلك نشر بحث حول هذا الموضوع في المستقبل. 7.5 البنية التحتية للمفتاح العام ومع اللامركزية التقدمية ستأتي الحاجة إلى تحديد قوي لـ المشاركون في الشبكة، بما في ذلك العقد DON. على وجه الخصوص، Chainlink يتطلب قويًا البنية التحتية للمفتاح العام (PKI). PKI هو نظام يربط المفاتيح بالهويات. ل على سبيل المثال، تدعم البنية التحتية للمفاتيح العمومية (PKI) نظام الاتصالات الآمنة (TLS) على الإنترنت: متى تتصل بموقع ويب عبر HTTPS (على سبيل المثال، https://www.chainlinklabs.com) و يظهر القفل في متصفحك، وهذا يعني أن المفتاح العام لمالك النطاق موجود تم ربطها بهذا المالك من خلال سلطة ما - على وجه التحديد، من خلال التوقيع الرقمي في ما يسمى بالشهادة. يساعد النظام الهرمي للمراجع المصدقة (CAs)، التي تم ربط سلطاتها الجذرية ذات المستوى الأعلى في المتصفحات الشائعة، على ضمان أن الشهادات يتم إصدارها فقط للمالكين الشرعيين للنطاقات. نتوقع أن يستفيد Chainlink في النهاية من خدمات الأسماء اللامركزية، في البداية Ethereum خدمة الأسماء (ENS) [22]، كأساس لبنية المفاتيح العمومية الخاصة بنا. كما يشير اسمها إلى أن ENS يشبه DNS، وهو نظام اسم المجال الذي يقوم بالتخطيط (يمكن قراءتها بواسطة الإنسان) إلى عناوين IP على الإنترنت. ومع ذلك، يقوم ENS بدلاً من ذلك بتعيين أسماء Ethereum القابلة للقراءة بواسطة الإنسان إلى عناوين blockchain. لأن إنس يعمل على Ethereum blockchain، باستثناء التسوية الرئيسية، والتلاعب به تعتبر مساحة الاسم من حيث المبدأ صعبة مثل التلاعب بالعقد الذي يديرها و/أو blockchain الأساسي. (في المقابل، كان نظام أسماء النطاقات (DNS) عرضة للخطر تاريخياً للانتحال والاختطاف والهجمات الأخرى.) لقد قمنا بتسجيل data.eth مع ENS على الشبكة الرئيسية Ethereum، ونعتزم القيام بذلك قم بتأسيسها كمساحة اسم جذر يتم بموجبها تحديد هويات خدمات البيانات oracle و توجد كيانات شبكة Chainlink أخرى. المجالات في ENS هرمية، مما يعني أن كل مجال قد يحتوي على مراجع إلى غير ذلك من الأسماء تحته. يمكن أن تكون النطاقات الفرعية في ENS بمثابة وسيلة لتنظيم وتفويض الثقة. سيكون الدور الرئيسي لـ data.eth هو العمل كخدمة دليل على السلسلة خلاصات البيانات. تقليديًا، استخدم مطورو ومستخدمو oracles مصادر خارج السلسلة (على سبيل المثال، مواقع الويب مثل docs.chain.link أو data.chain.link، أو الشبكات الاجتماعية مثل Twitter) لنشر والحصول على عناوين خلاصة البيانات oracle (مثل سعر ETH-USD تغذية). باستخدام مساحة اسم جذر جديرة بالثقة للغاية مثل data.eth، من الممكن بدلاً من ذلك إنشاء تعيين لـ eth-usd.data.eth، على سبيل المثال، العنوان smart contract لمجمع شبكة oracle على السلسلة لموجز أسعار ETH-USD. هذا من شأنه إنشاء مسار آمن لأي شخص للإشارة إلى blockchain كمصدر الحقيقة تغذية البيانات الخاصة بزوج السعر/الاسم (ETH-USD). ونتيجة لذلك، مثل هذا الاستخدام لـ ENS يحقق فائدتين غير متوفرتين في مصادر البيانات خارج السلسلة: • أمان قوي: يتم تسجيل كافة التغييرات والتحديثات التي يتم إجراؤها على المجال بشكل ثابت وتأمينها بطريقة مشفرة، على عكس العناوين النصية الموجودة على موقع الويب، والتي لا تتمتع بأي من هاتين الخاصيتين الأمنيتين. • النشر الآلي على السلسلة: يمكن أن تؤدي التحديثات على العنوان الأساسي لملف البيانات smart contract إلى تشغيل إشعارات تنتشر إلى الأجهزة الذكية التابعة العقود، ويمكنه، على سبيل المثال، تحديث العقود التابعة تلقائيًا باستخدام العناوين الجديدة.13 ومع ذلك، فإن مساحات الأسماء مثل ENS لا تتحقق تلقائيًا من صحة الملكية الشرعية من الأسماء المؤكدة. وبالتالي، على سبيل المثال، إذا كانت مساحة الاسم تتضمن الإدخال ⟨"شركة Acme Oracle Node Co."، العنوان⟩، ثم يحصل المستخدم على تأكيد بأن العنوان ينتمي إلى المدعي بالاسم Acme Oracle Node Co. بدون آليات إضافية حول إدارة مساحة الاسم، ومع ذلك، فهي لا تحصل على تأكيد بأن الاسم ينتمي إلى كيان بشكل قانوني تسمى Acme Oracle Node Co. بالمعنى الحقيقي للمعنى. يعتمد نهجنا في التحقق من صحة الأسماء، أي ضمان ملكيتها من قبل كيانات العالم الحقيقي الشرعية المقابلة، على عدة مكونات. اليوم، Chainlink مختبرات يعمل بشكل فعال كمرجع مصدق لشبكة Chainlink. بينما ستستمر Chainlink المختبرات وللتحقق من صحة الأسماء، ستتطور البنية التحتية للمفاتيح العمومية (PKI) الخاصة بنا إلى نموذج أكثر لامركزية بطريقتين: • نموذج شبكة الثقة: يُشار غالبًا إلى النظير اللامركزي لبنية المفاتيح العمومية الهرمية باسم شبكة الثقة. وقد تم اقتراح متغيرات منذ التسعينيات، على سبيل المثال، [98]، وقد لاحظ عدد من الباحثين أن blockchains يمكنها تسهيل استخدام الفكرة، على سبيل المثال، [227] من خلال تسجيل الشهادات بطريقة متسقة عالميًا دفتر الأستاذ. نحن نستكشف المتغيرات لهذا النموذج للتحقق من هويات الكيانات في شبكة Chainlink بطريقة أكثر لامركزية. يمكن أن يتضمن العقد التابع 13A بشكل اختياري تأخيرًا محددًا مسبقًا للسماح بالفحص اليدوي والتدخل من قبل مسؤولي العقود التابعة. 14مصطلح صاغه فيل زيمرمان لـ PGP [238].• الارتباط بالتحقق من صحة البيانات: اليوم، هناك قدر كبير من بيانات أداء العقدة oracle مرئية على السلسلة، وبالتالي مرتبطة أرشيفيًا بعناوين العقد. يمكن النظر إلى مثل هذه البيانات على أنها إثراء للهوية في البنية التحتية للمفاتيح العمومية من خلال تقديم دليل تاريخي على مشاركتها (الموثوقة) في الشبكة. بالإضافة إلى الأدوات للهوية اللامركزية المستندة إلى DECO وTown Crier [160] تمكين العقد لتجميع بيانات الاعتماد المستمدة من بيانات العالم الحقيقي. وكمثال واحد فقط، أ يمكن لمشغل العقدة إرفاق بيانات اعتماد بهوية PKI الخاصة به والتي تثبت الحيازة من تصنيف دون وبرادستريت. يمكن لهذه الأشكال التكميلية من التحقق من الصحة ملحق staking في إنشاء ضمان أمان الشبكة. قد يُنظر إلى العقدة oracle ذات الهوية الواقعية الراسخة على أنها تمتلك حصة في نظام مستمد من سمعتها. (انظر القسم 4.3 والقسم 9.6.3.) الشرط النهائي لـ Chainlink PKI هو التمهيد الآمن، أي بشكل آمن نشر اسم الجذر لشبكة Chainlink، حاليًا data.eth (قياسيًا لتوصيل نطاقات المستوى الأعلى في المتصفحات). بمعنى آخر، كيف يفعل مستخدمو Chainlink تحديد أن data.eth هو بالفعل نطاق المستوى الأعلى المرتبط بـ Chainlink المشروع؟ الحل لهذه المشكلة لشبكة Chainlink متعدد الجوانب و قد تشمل: • إضافة سجل TXT [224] إلى سجل النطاق الخاص بنا لـ chain.link الذي يحدد data.eth باعتباره المجال الجذر للنظام البيئي Chainlink. (Chainlink وبالتالي يعزز ضمنيًا البنية التحتية للمفاتيح العامة (PKI) لنطاقات الإنترنت للتحقق من صحة مجال ENS الجذري الخاص به.) • الارتباط بـ data.eth من موقع Chainlink الحالي، على سبيل المثال، من https://docs.chain.link. (استخدام ضمني آخر لـ PKI لنطاقات الإنترنت.) • جعل استخدام data.eth معروفًا من خلال وثائق مختلفة، بما في ذلك هذه الوثيقة التقنية. • نشر data.eth علنًا على قنوات التواصل الاجتماعي الخاصة بنا، مثل Twitter و المدونة Chainlink [18]. • وضع كمية كبيرة من LINK تحت سيطرة نفس عنوان المسجل مثل data.eth.

DON اعتبارات النشر

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

8.1 نهج الطرح تضع هذه الورقة رؤية طموحة لوظيفة Chainlink المتقدمة التي وسيتطلب تحقيق ذلك حلولاً للعديد من التحديات على طول الطريق. هذه الورقة البيضاء يحدد بعض التحديات، ولكن من المؤكد أن تظهر تحديات غير متوقعة. ونحن نخطط لتنفيذ عناصر هذه الرؤية بطريقة تدريجية على مدار فترة زمنية فترة زمنية ممتدة. توقعاتنا هي أن DONs سيتم إطلاقه في البداية مع دعم لمكونات محددة معدة مسبقًا تم إنشاؤها بشكل تعاوني بواسطة فرق داخل Chainlink المجتمع. والقصد من ذلك هو أن الاستخدامات الأوسع لـ DONs، على سبيل المثال، القدرة على إطلاق الملفات التنفيذية التعسفية، وسوف نرى الدعم في وقت لاحق. أحد أسباب هذا الحذر هو أن تكوين smart contracts يمكن أن يكون له آثار جانبية معقدة وغير مقصودة وخطيرة، كما حدث مؤخرًا مع الهجمات المعتمدة على القروض السريعة على سبيل المثال هو مبين [127، 189]. وبالمثل، فإن تكوين smart contracts، والمحولات، و سوف تتطلب الملفات التنفيذية عناية فائقة. في النشر الأولي لـ DONs، نخطط لتضمين فقط مجموعة معدة مسبقًا من الملفات التنفيذية والمحولات النموذجية. وهذا سيمكن من دراسة الأمن التركيبي من هذه الوظائف باستخدام الأساليب الرسمية [46، 170] وغيرها من الأساليب. سوف تبسيط التسعير أيضًا: يمكن تحديد تسعير الوظائف من خلال DON العقد على أساس الأداء الوظيفي، وليس من خلال القياس العام، وهو النهج المعتمد في، على سبيل المثال، [156]. نتوقع أيضًا أن يشارك مجتمع Chainlink في الإنشاء من القوالب الإضافية، والجمع بين مختلف المحولات والملفات التنفيذية في شكل متزايد خدمات لامركزية مفيدة يمكن تشغيلها بواسطة مئات، إن لم يكن الآلاف من الأفراد DONs. بالإضافة إلى ذلك، يمكن أن يساعد هذا الأسلوب في منع انتفاخ الحالة، أي الحاجة إلى DON العقد للاحتفاظ بكمية غير قابلة للتطبيق من الحالة في الذاكرة العاملة. هذه المشكلة تنشأ بالفعل في blockchains غير المسموح بها، مما يحفز الأساليب مثل "عديمي الجنسية". العملاء" (راجع، على سبيل المثال، [206]). يمكن أن يكون أكثر حدة في أنظمة الإنتاجية العالية، مما يحفز أسلوب يقوم من خلاله DON بنشر الملفات التنفيذية المحسنة لحجم الحالة فقط. نظرًا لأن DON تتطور وتنضج وتتضمن حواجز حماية قوية، كما تمت مناقشته في القسم 7، وآليات الأمان المستندة إلى الاقتصاد المشفر والسمعة كما تمت مناقشتها في القسم 9، والميزات الأخرى التي توفر درجة عالية من الضمان لمستخدمي DON، فإننا ونتوقع أيضًا تطوير إطار عمل وأدوات لتسهيل إطلاقه واستخدامه على نطاق أوسع DONs من قبل المجتمع. ومن الناحية المثالية، ستمكن هذه الأدوات مجموعة من مشغلي العقد للاجتماع معًا كشبكة oracle وإطلاق DONs الخاصة بهم بطريقة غير مسموح بها أو بطريقة الخدمة الذاتية، مما يعني أنه يمكنهم القيام بذلك من جانب واحد. 8.2 العضوية الديناميكية DON قد تتغير مجموعة العقد التي تعمل على DON مع مرور الوقت. هناك نهجان للإدارة الرئيسية لـ skL نظرًا للعضوية الديناميكية في O. الأول هو تحديث حصص skL التي تحتفظ بها العقد عند حدوث تغييرات في العضوية، مع الحفاظ على pkL دون تغيير. وهذا النهج، الذي تم استكشافه في [41، 161، 198]، له ميزة عدم مطالبة الأطراف المعتمدة بتحديث pkL.توفر التقنية الكلاسيكية لإعادة مشاركة المشاركة، والتي تم تقديمها في [122]، طريقة بسيطة وطريقة فعالة لتحقيق تحديثات المشاركة هذه. أنها تمكن من نقل سر بين مجموعة واحدة من العقد O(1) والثانية، وربما تتقاطع مع O(2). في هذا النهج، كل عقدة O(1) أنا ينفذ (k(2), n(2)) مشاركة سرية لحصته السرية عبر العقد في O(2) لـ n(2) = |O(2)| والعتبة المطلوبة (ربما الجديدة) k (2). يمكن لأنظمة المشاركة السرية المختلفة (VSS) التي يمكن التحقق منها [108] أن توفر الأمان ضد الخصم الذي يفسد العقد بشكل فعال، أي يقدم سلوكًا ضارًا في البروتوكول. تهدف التقنيات الموجودة في [161] إلى القيام بذلك مع تقليل تعقيد الاتصال وتوفيره المرونة ضد الفشل في افتراضات صلابة التشفير. الطريقة الثانية هي تحديث مفتاح دفتر الأستاذ pkL. وهذا له فائدة للأمام الأمان: لن يتم التنازل عن الأسهم القديمة لـ pkL (أي عقد اللجنة السابقة). يؤدي إلى اختراق المفتاح الحالي. ومع ذلك، فإن تحديثات pkL تحمل عيبين: (1) تحتاج البيانات المشفرة بموجب pkL إلى إعادة تشفيرها أثناء تحديث المفتاح و(2) يجب نشر التحديثات الرئيسية إلى الأطراف المعتمدة. ونحن نعتزم استكشاف كلا النهجين، فضلا عن التهجين بين الاثنين. 8.3 DON المساءلة كما هو الحال مع شبكات Chainlink oracle الحالية، ستتضمن DONs آليات للمساءلة، أي تسجيل سلوك العقدة الصحيح ومراقبته وإنفاذه. DONs سيكون لها سعة بيانات أكبر بكثير من العديد من blockchains الموجودة غير المسموح بها، خاصة بالنظر إلى قدرتها على الاتصال بالتخزين اللامركزي الخارجي. وبالتالي، سيكونون قادرين على تسجيل تاريخ أداء العقد بالتفصيل، مما يسمح بذلك المزيد من آليات المساءلة الدقيقة. على سبيل المثال، حساب خارج السلسلة قد تتضمن أسعار الأصول مدخلات يتم التخلص منها قبل إرسال النتيجة المتوسطة سلسلة. في DON، يمكن تسجيل هذه النتائج المتوسطة. وبالتالي يمكن معالجة سوء السلوك أو هفوات الأداء من قبل العقد الفردية في DON أو معاقبتها على DON بطريقة دقيقة الحبيبات. لقد ناقشنا أيضًا طرق البناء قضبان الحماية في القسم 7.3 والتي تتناول التأثير المحدد للعقد الناتج عن الأعطال النظامية. ومع ذلك، فمن المهم أيضًا وجود آليات آمنة للفشل في DONs نفسها، على سبيل المثال، الحماية ضد حالات الفشل النظامية، والتي قد تكون كارثية DON، على وجه التحديد فشل التفرع/المراوغة واتفاقية مستوى الخدمة (SLA)، كما نوضح الآن. التشعب/ المراوغة: نظرًا لوجود عدد كافٍ من العقد المعيبة، يمكن أن يتفرع DON أو المراوغة، مما يؤدي إلى إنتاج كتلتين أو تسلسلتين متميزتين وغير متناسقتين من الكتل في L. نظرًا لأن DON يوقع رقميًا على محتويات L، فمن الممكن الاستفادة من السلسلة الرئيسية MAINCHAIN لمنع و/أو معاقبة المراوغة. يمكن لـ DON التحقق من الحالة بشكل دوري من L في عقد التدقيق على MAINCHAIN. إذا انحرفت حالتها المستقبلية عن حالة نقطة التفتيش، فيمكن للمستخدم/المدقق تقديم دليل عن هذا السلوك السيئ في عقد التدقيق. يمكن استخدام هذا الدليل لإنشاء تنبيه أو معاقبة DON العقد عن طريق القطع في العقد. يقدم هذا النهج الأخير مشكلة تصميم الحوافز مشابهة لتلك الخاصة بخلاصات oracle المحددة، ويمكن البناء عليها عملنا المبين في القسم 9.إنفاذ اتفاقيات مستوى الخدمة: في حين أن DONs ليس المقصود منه بالضرورة تشغيلها إلى أجل غير مسمى، فمن المهم أن تلتزم باتفاقيات مستوى الخدمة (SLAs) مع مستخدميها. تطبيق SLA الأساسي ممكن على السلسلة الرئيسية. على سبيل المثال، قد تلتزم العقد DON بالحفاظ على DON حتى تاريخ معين، أو بتقديم إشعار مسبق بإنهاء الخدمة (على سبيل المثال، إشعار لمدة ثلاثة أشهر). عقد على يمكن أن توفر MAINCHAIN تطبيقًا أساسيًا لاتفاقية مستوى الخدمة (SLA) للاقتصاد المشفر. على سبيل المثال، يمكن لعقد SLA أن يخفض DON الأموال المودعة إذا كانت نقاط التفتيش لم يتم توفيرها على فترات زمنية مطلوبة. يمكن للمستخدم إيداع الأموال والطعن في DON لإثبات أن نقطة التفتيش تمثل بشكل صحيح سلسلة من الكتل الصالحة (بطريقة مماثل ل، على سبيل المثال [141]). وبطبيعة الحال، إنتاج الكتلة لا يعني المعاملة المعالجة، ولكن عقد SLA يمكن أن يعمل أيضًا على إنفاذ الأخير. على سبيل المثال، في الإصدار المتوافق مع التراث من الخدمة الثابتة الساتلية (FSS) والذي يتم فيه جلب المعاملات من مجمع الذاكرة (انظر القسم 5.2)، ويتم في النهاية استخراج المعاملات ووضعها في السلسلة. مستخدم يمكن إثبات DON المخالفات من خلال تزويد عقد SLA بمعاملة تم تعدينه ولكن لم يتم إرساله بواسطة DON للمعالجة بواسطة العقد المستهدف خلال الفترة الزمنية المناسبة.15 ومن الممكن أيضًا إثبات وجود المزيد من جيش تحرير السودان (SLA) الدقيق والمعاقبة عليه حالات الفشل، بما في ذلك الأخطاء في الحساب باستخدام الملفات التنفيذية (عبر، على سبيل المثال، الآليات لإثبات معاملات الحالة الصحيحة خارج السلسلة الموضحة في القسم 6.3) أو الفشل في التشغيل الملفات التنفيذية المستندة إلى البادئات المرئية على DON، الفشل في ترحيل البيانات على DON إلى MAINCHAIN في الوقت المناسب، وما إلى ذلك.

الاقتصاد والاقتصاد المشفر

لكي تتمكن شبكة Chainlink من تحقيق أمان قوي ضمن نموذج ثقة لامركزي، من الضروري أن تظهر العقد بشكل جماعي السلوك الصحيح، مما يعني أنها تلتزم في أغلب الأحيان بالضبط إلى بروتوكولات DON. في هذا القسم، نناقش الأساليب للمساعدة في فرض مثل هذا السلوك عن طريق الحوافز الاقتصادية، المعروفة أيضًا باسم الاقتصاد المشفر الحوافز. وتنقسم هذه الحوافز إلى فئتين: صريحة وضمنية، محققة على التوالي من خلال staking وفرصة الرسوم المستقبلية (FFO). التوقيع المساحي: يتضمن التخزين Chainlink، كما هو الحال في أنظمة blockchain الأخرى، المشاركين في الشبكة، أي oracle العقد، وإيداع الأموال المقفلة في شكل LINK tokens. هذه الأموال، والتي نشير إليها أيضًا باسم الحصة أو الحصة الصريحة هي حافز صريح. هم تخضع للمصادرة عند فشل العقدة أو المخالفات. في سياق blockchain، غالبًا ما يسمى هذا الإجراء بالقطع. ومع ذلك، فإن التوقيع المساحي بواسطة oracle العقد في Chainlink يختلف بشكل أساسي عن staking بواسطة validators في blockchains غير المسموح بها. يمكن أن يسيء المدققون التصرف عن طريق المراوغة أو طلب المعاملات بشكل عدائي. بروتوكول الإجماع الأساسي في أ 15 بما أنه يمكن للمستخدمين استبدال المعاملات في مجمع الذاكرة، يلزم الحذر لضمان المراسلات الصحيحة بين المعاملات المستخرجة والمعاملات المقدمة DON.ومع ذلك، فإن blockchain غير المسموح به يستخدم قواعد صارمة وسريعة للتحقق من صحة الكتلة وأساسيات التشفير لمنع validators من إنشاء كتل غير صالحة. في المقابل، لا يمكن للحماية البرمجية أن تمنع إنشاء شبكة oracle للغش تقارير غير صالحة. السبب هو الاختلاف الرئيسي بين نوعي النظام: التحقق من صحة المعاملة في blockchains هو خاصية الاتساق الداخلي، في حين أن الصحة من oracle التقارير على blockchain هي خاصية خارجية، أي بيانات خارج السلسلة. لقد قمنا بتصميم آلية staking الأولية لشبكة Chainlink القائمة على على بروتوكول تفاعلي بين العقد oracle التي قد تستفيد من البيانات الخارجية. هذا تخلق الآلية حوافز مالية للسلوك الصحيح باستخدام مكافآت صريحة و العقوبات (القطع). وبما أن الآلية اقتصادية، فهي مصممة لمنع العقدة الفساد من قبل خصم يستخدم الموارد المالية لإفساد العقد عن طريق رشوة. (مثل هذا الخصم عام جدًا، ويمتد، على سبيل المثال، إلى العقد المتعاونة معها استخراج القيمة من سوء سلوكهم الجماعي.) تتميز آلية Chainlink staking التي صممناها ببعض القوة والرواية الميزات.16 الميزة الرئيسية هي التأثير الخطي الفائق staking (على وجه التحديد، التربيعي). يجب أن يكون لدى الخصم موارد تزيد بشكل كبير عن الأموال المودعة في العقد من أجل تخريب الآلية. بالإضافة إلى ذلك، توفر آلية staking الخاصة بنا الحماية ضد خصم أقوى مما كان مذكورًا سابقًا في أنظمة مماثلة، وهي خصم يمكنه إنشاء رشاوى تتكيف مع سلوك العقد المستقبلي. بالإضافة إلى ذلك، نناقش كيف يمكن لأدوات Chainlink مثل DECO أن تساعد في تعزيز staking لدينا آلية من خلال تسهيل الفصل الصحيح في حالة سلوك العقدة الخاطئ. فرصة الرسوم المستقبلية (FFO): blockchains غير مسموح بها — لكل من إثبات العمل (PoW). وتنوع إثبات الحصة (PoS) – يعتمد اليوم بشكل حاسم على ما نسميه الحوافز الضمنية. هذه هي الحوافز الاقتصادية للسلوك الصادق التي لا تستمد من المكافآت الصريحة، ولكن من مشاركة المنصة نفسها. على سبيل المثال، يتم تحفيز مجتمع عمال المناجم Bitcoin ضد شن هجوم بنسبة 51% بسبب خطر تقويض الثقة في Bitcoin، مما يؤدي إلى خفض قيمتها، وبالتالي تآكل قيمة جمعيتها الاستثمارات الرأسمالية في البنية التحتية للتعدين [150]. تستفيد شبكة Chainlink من الحافز الضمني المماثل الذي نشير إليه كفرصة للرسوم المستقبلية (FFO). عقد Oracle ذات تاريخ أداء قوي أو السمعة تجذب الرسوم من المستخدمين. سوء التصرف من قبل عقدة oracle يعرض المستقبل للخطر دفع الرسوم وبالتالي معاقبة العقدة بتكلفة الفرصة البديلة من حيث الإمكانات الإيرادات المكتسبة من خلال المشاركة في الشبكة. قياسا على حصة صريحة، قد يُنظر إلى FFO على أنه شكل من أشكال الحصة الضمنية، أو حافز للسلوك الصادق مستمد من المنفعة المشتركة المتمثلة في الحفاظ على الثقة في المنصة التي تعمل عليها تعتمد أعمال مشغلي العقد، على سبيل المثال، على الأداء الإيجابي والسمعة الإيجابية للعقدة شبكة. هذا الحافز متأصل في شبكة Chainlink ولكن لم يتم التعبير عنه صراحةً البروتوكولات. وفي Bitcoin الحفاظ على قيمة عمليات التعدين كما ذكرنا أعلاه 16إن آلية staking التي نصفها هنا تهدف حاليًا فقط إلى فرض تسليم التقارير الصحيحة بواسطة شبكات oracle. ونتوقع في العمل المستقبلي توسيع نطاقه لضمان التنفيذ الصحيح للكثيرين سيتم توفير وظائف أخرى DONs.قد يُنظر إليها بالمثل على أنها شكل من أشكال الحصة الضمنية. نؤكد على أن FFO موجود بالفعل في Chainlink ويساعد في تأمين الشبكة اليوم. ستكون مساهمتنا الرئيسية في التطوير الإضافي لـ Chainlink هي اتباع نهج مبدئي مدفوع تجريبيًا لتقييم الحوافز الضمنية مثل FFO من خلال ما نسميه إطار الحوافز الضمنية (IIF). لتقدير الكميات مثل فرصة الرسوم المستقبلية للعقد، سوف يعتمد معهد التمويل الدولي بشكل مستمر على النطاق الشامل بيانات الأداء والدفع التي تم جمعها بواسطة شبكة Chainlink. مثل هذه التقديرات سيتم تمكين المعلمات المستندة إلى IIF لأنظمة staking التي تعكس حوافز العقدة بدقة أكبر من النماذج الإرشادية و/أو الثابتة الحالية. لتلخيص الحافزين الاقتصاديين الرئيسيين للعقدة oracle الصحيحة السلوك في شبكة Chainlink النامية سيكون: • التوقيع المساحي (الحصة المودعة) س الحافز الصريح • فرصة الرسوم المستقبلية (FFO) س الحافز الضمني وهذان الشكلان من الحوافز متكاملان. يمكن للعقد أوراكل في وقت واحد شارك في بروتوكول Chainlink staking، واستمتع بتدفق مستمر للإيرادات من المستخدمين، والاستفادة بشكل جماعي من سلوكهم الجيد المستمر. وبالتالي كلا الحوافز المساهمة في أمن الاقتصاد المشفر الذي توفره شبكة oracle. بالإضافة إلى ذلك، ويمكن تعزيز الحافزين و/أو تبادلهما ضد بعضهما البعض. على سبيل المثال، يمكن لمشغل oracle جديد بدون سجل أداء وتدفق إيرادات أن يشارك في كمية كبيرة من LINK كضمان للسلوك الصادق، وبالتالي جذب المستخدمين والرسوم. وعلى العكس من ذلك، فإن مشغل oracle الذي تم تأسيسه يتمتع بمشغل طويل وخالي من الأخطاء نسبيًا يمكن أن يتقاضى سجل الأداء رسومًا كبيرة من قاعدة مستخدمين كبيرة وبالتالي يعتمد عليه بشكل أكبر على FFO كشكل من أشكال الحوافز الضمنية. بشكل عام، يهدف النهج الذي ندرسه هنا إلى قدر معين من oracle-الشبكة مورد لإنشاء أكبر قدر ممكن من الحوافز الاقتصادية في Chainlink للعقلانية الوكلاء - أي العقد التي تزيد من فائدتهم المالية - إلى التصرف بأمانة. ضع آخر وبطريقة ما، فإن الهدف هو تعظيم الموارد المالية اللازمة لكي يقوم الخصم بالهجوم الشبكة بنجاح. من خلال صياغة بروتوكول staking بطريقة رياضية جيدة الأمن الاقتصادي المحدد وأيضا باستخدام معهد التمويل الدولي، ونحن نهدف إلى قياس قوة حوافز Chainlink بأكبر قدر ممكن من الدقة. المبدعين من الاعتماد على العقود سوف ثم تكون قادرًا على التحديد بثقة قوية ما إذا كانت شبكة oracle تجتمع أم لا المستويات المطلوبة من الأمن الاقتصادي المشفر. الدورة الحميدة للأمن الاقتصادي: إن الحوافز التي نناقشها في هذا القسم، staking وFFO، لها تأثير يتجاوز تعزيزها لأمن DONs. وهي تَعِد بتحفيز ما نسميه بالدورة الحميدة للأمن الاقتصادي. يؤدي التأثير الخطي الفائق staking (ووفورات الحجم الأخرى) إلى انخفاض التشغيل التكلفة مع نمو أمان DON. التكلفة المنخفضة تجذب المزيد من المستخدمين إلى DON،تعزيز مدفوعات الرسوم. ويستمر الارتفاع في مدفوعات الرسوم في تحفيز النمو في الشبكة، التي تديم الدورة الحميدة. ونحن نعتقد أن الدورة الحميدة للأمن الاقتصادي هي مجرد مثال واحد على ذلك وفورات الحجم وتأثير الشبكة من بين أشياء أخرى سنناقشها لاحقًا في هذا القسم. تنظيم القسم: يمثل التوقيع المساحي تحديات فنية ومفاهيمية ملحوظة والتي قمنا بتصميم آلية ذات ميزات جديدة. لذلك سيكون التوقيع المساحي تركيزنا الرئيسي في هذا القسم. نقدم نظرة عامة على نهج staking الذي نقدمه في هذه الورقة في القسم 9.1، تليها مناقشة مفصلة في الأقسام 9.2 إلى 9.5. نحن نقدم IFF في القسم 9.6. نقدم عرضًا ملخصًا لحوافز شبكة Chainlink في القسم 9.7. في القسم 9.8، نناقش الدورة الحميدة للأمن الاقتصادي التي يمكن أن يجلبها نهجنا staking المقترح إلى شبكات oracle. وأخيرًا، سنصف بإيجاز الإمكانات الأخرى التأثيرات الدافعة لنمو شبكة Chainlink في القسم 9.9. 9.1 نظرة عامة على التوقيع المساحي يتضمن تصميم آلية staking الذي نقدمه هنا، كما هو مذكور أعلاه، بروتوكولًا تفاعليًا بين العقد oracle مما يسمح بحل التناقضات في الإبلاغ عن البيانات الخارجية. يهدف التوقيع المساحي إلى ضمان السلوك الصادق من العقد oracle العقلانية. يمكننا بالتالي أن نصمم خصمًا يهاجم بروتوكول staking باعتباره الراشي: تتمثل استراتيجية الخصم في إفساد oracle العقد باستخدام الحوافز المالية. وقد يستمد الخصم موارد مالية بأثر رجعي من التلاعب الناجح مع تقرير oracle، على سبيل المثال، عرض مشاركة الأرباح الناتجة مع العقد التالفة. نحن نهدف في تصميم آلية staking إلى تحقيق هدفين طموحين في وقت واحد: 1. مقاومة خصم قوي: تم تصميم آلية staking للحماية oracle شبكات ضد فئة واسعة من الخصوم القادرين على القيام بعمليات معقدة، استراتيجيات الرشوة المشروطة، بما في ذلك الرشوة المحتملة، التي تقدم الرشاوى إلى oracle الذين يتم تحديد هوياتهم بعد وقوع الحدث (على سبيل المثال، يقدم رشاوى لـ oracles تم اختيارها عشوائيًا للتنبيه ذي الأولوية العالية). بينما تصميمات oracle أخرى وقد اعتبرت مجموعة ضيقة من الهجمات دون كامل القدرات الواقعية الخصم، على حد علمنا آلية الخصومة التي نقدمها هنا هو أول من تناول بشكل صريح مجموعة واسعة من استراتيجيات الرشوة والعروض المقاومة في هذا النموذج يفترض نموذجنا أن العقد بجانب المهاجم موجودة عقلاني اقتصاديًا (على عكس الصادق)، ونفترض وجود أ مصدر الحقيقة باهظ التكلفة للاستخدام النموذجي ولكنه متاح في حالة الخلاف (تتم مناقشته أدناه). 2. تحقيق تأثير خطي فائق staking: هدفنا هو التأكد من أن شبكة oracle المكونة من وكلاء عقلانيين تقدم التقارير بصدق حتى في وجود مهاجم بميزانية فائقة الخطيةفي إجمالي الحصة المودعة من قبل الشبكة بأكملها. في أنظمة staking الموجودة، إذا تبلغ قيمة كل عقدة n $d، ويمكن للمهاجم إصدار رشوة موثوقة تطلبها أن العقد تتصرف بطريقة غير شريفة مقابل دفع مبلغ يزيد قليلاً عن \(d to each node, using a total budget of about \)dn. وهذا بالفعل شريط مرتفع يجب أن يكون لدى المهاجم ميزانية سائلة بناءً على الودائع المجمعة جميع أصحاب المصلحة في الشبكة. وهدفنا هو تحقيق درجة أقوى من الأمن الاقتصادي من هذه العقبة الكبيرة بالفعل. نحن نهدف إلى تصميم أول نظام staking يمكنها تحقيق الأمان لمهاجم عام بميزانية خطية فائقة في n. في حين أن الاعتبارات العملية قد تحقق تأثيرًا أقل، كما نناقش أدناه، يحقق تصميمنا الأولي متطلبات ميزانية تنافسية أكبر من $dn2/2، أي تحجيم التربيعية في n، مما يجعل الرشوة غير عملية إلى حد كبير حتى عندما تشترك العقد بكميات معتدلة فقط. ويتطلب تحقيق هذين الهدفين مزيجاً مبتكراً من تصميم الحوافز والتشفير. الأفكار الرئيسية: يعتمد نهجنا staking على فكرة نطلق عليها أولوية المراقبة. تقرير تم إنشاؤه بواسطة شبكة Chainlink oracle وإرساله إلى عقد الاعتماد (على سبيل المثال، على سعر الأصل) يتم تجميعها من التقارير الفردية التي تساهم بها العقد المشاركة (على سبيل المثال، عن طريق أخذ المتوسط). عادةً ما تكون اتفاقية مستوى الخدمة (SLA) يحدد حدود الانحراف المقبولة للتقارير، أي إلى أي مدى يمكن أن يصل تقرير العقدة الانحراف عن التقرير الإجمالي وإلى أي مدى ينبغي السماح للتجميع بذلك تنحرف عن القيمة الحقيقية لاعتبارها صحيحة. في نظام staking الخاص بنا، بالنسبة لجولة تقارير معينة، يمكن لكل عقدة oracle أن تعمل كـ هيئة رقابية لتوجيه تنبيه إذا اعتقدت أن التقرير الإجمالي غير صحيح. في كل جولة إعداد التقارير، يتم تعيين أولوية عامة لكل عقدة oracle تحدد الترتيب الذي ستتم به معالجة تنبيهه (إن وجد). آليتنا تهدف إلى المكافأة التركيز، مما يعني أن الجهة الرقابية ذات الأولوية القصوى لرفع التنبيه تحصل على المكافأة الكاملة الناتجة عن مصادرة رواسب العقد المعيبة. تشتمل تصميمات نظامنا staking على مستويين: الأول، المستوى الافتراضي، والثاني، الطبقة الخلفية. الطبقة الأولى هي شبكة oracle نفسها، وهي مجموعة من العقد n. (من أجل البساطة، نحن نفترض أن n أمر فردي.) إذا أبلغت غالبية العقد عن قيم غير صحيحة، فستقوم هيئة رقابية في يتم تحفيز المستوى الأول بقوة لرفع مستوى التنبيه. إذا تم رفع تنبيه، الإبلاغ يتم بعد ذلك تصعيد القرار المتعلق بالشبكة إلى المستوى الثاني، وهو نظام عالي التكلفة وأقصى قدر من الموثوقية يمكن تحديده من قبل المستخدم في اتفاقية مستوى خدمة الشبكة. يمكن أن يكون هذا النظام، على سبيل المثال، يتكون فقط من العقد ذات القوة القوية درجات الموثوقية التاريخية، أو تلك التي لها ترتيب أكبر من oracles الطبقة الأولى. بالإضافة إلى ذلك، كما تمت مناقشته في القسم 9.4.3، يمكن أن يخدم DECO أو Town Crier كأدوات قوية للمساعدة في ضمان إصدار أحكام قضائية فعالة وحاسمة في المستوى الثاني. ومن أجل التبسيط، فإننا نفترض أن نظام المستوى الثاني هذا قد وصل إلى التقرير الصحيح قيمة. على الرغم من أنه قد يبدو جذابًا الاعتماد على المستوى الثاني لإنشاء كافة التقارير، إلا أنه تكمن فائدة تصميمنا في أنه يحقق باستمرار الخصائص الأمنية للشبكةنظام من المستوى الثاني مع دفع تكاليف التشغيل فقط، في الحالة النموذجية، لل نظام الطبقة الأولى. تؤدي أولوية الوكالة الدولية للطاقة إلى تأثير خطي فائق staking بالطريقة التالية: إذا كان تُخرج شبكة oracle من المستوى الأول نتيجة غير صحيحة وعددًا من عقد المراقبة تنبيه، فإن آلية الحوافز staking تكافئ هيئة المراقبة ذات الأولوية القصوى أكثر من $dn/2 مأخوذة من ودائع العقد (الأغلبية) التي تسيء التصرف. ال وبالتالي فإن المكافأة الإجمالية تتركز في أيدي هذه الوكالة الرقابية الواحدة، والتي بالتالي يحدد الحد الأدنى الذي يجب على الخصم أن يعد به هيئة رقابية محتملة تحفيزه على عدم التنبيه. نظرًا لأن آليتنا تضمن حصول كل oracle على فرصة للعمل كرقيب إذا قبلت هيئات المراقبة ذات الأولوية العليا رشاويهم (واختار عدم التنبيه)، لذلك يجب على الخصم أن يقدم رشوة بأكثر من $dn/2 إلى كل عقدة لمنع إثارة أي تنبيه. نظرًا لوجود n عقد، فإن تبلغ الميزانية المطلوبة للخصم من أجل الحصول على رشوة ناجحة ما يزيد عن 2/2 دولار أمريكي، وهو ما يعادل 2/2 دولار أمريكي هو تربيعي في عدد n من العقد في الشبكة. 9.2 الخلفية يعتمد نهجنا في staking على الأبحاث في مجالات نظرية اللعبة وآلياتها التصميم (MD) (للحصول على مرجع كتاب مدرسي، راجع [177]). نظرية اللعبة هي رياضيا دراسة رسمية للتفاعل الاستراتيجي. وفي هذا السياق، تعتبر اللعبة نموذجًا لذلك تفاعل، عادة ما يكون في العالم الحقيقي، يقنن مجموعات من الإجراءات المتاحة المشاركين في اللعبة، والمعروفين باللاعبين. تحدد اللعبة أيضًا المكاسب التي تم الحصول عليها من قبل اللاعبين الفرديين - المكافآت التي تعتمد على الإجراءات التي يختارها اللاعب و تصرفات اللاعبين الآخرين. ولعل أفضل مثال معروف للعبة تمت دراستها في اللعبة النظرية هي معضلة السجناء [178]. يهدف منظرو الألعاب عمومًا إلى الفهم التوازن أو التوازنات (إن وجدت) الممثلة في لعبة معينة. التوازن هو مجموعة من الاستراتيجيات (واحدة لكل لاعب) بحيث لا يستطيع أي لاعب الحصول على أعلى المكافأة عن طريق الانحراف من جانب واحد عن استراتيجيتها. وفي الوقت نفسه، فإن تصميم الآلية هو علم تصميم الحوافز بحيث يتم يتمتع توازن التفاعل (واللعبة المرتبطة به) ببعض الخصائص المرغوبة. يمكن النظر إلى MD على أنه عكس نظرية اللعبة: السؤال الأساسي في اللعبة النظرية هي: "في ضوء الحوافز والنموذج، ماذا سيكون التوازن؟" في دكتوراه في الطب، والسؤال هو بدلاً من ذلك: "ما هي الحوافز التي ستؤدي إلى لعبة ذات توازن مرغوب؟" الهدف النموذجي لمصمم الآلية هو إنشاء آلية "متوافقة مع الحوافز"، مما يعني أن المشاركين في الآلية (على سبيل المثال، مزاد أو معلومات أخرى) يتم تحفيز نظام الاستنباط [228]) للإبلاغ عن الحقيقة بشأن بعض الأمور (على سبيل المثال، كيف كثيرًا ما يقدرون عنصرًا معينًا). ربما يكون مزاد فيكري (السعر الثاني) هو أفضل آلية معروفة متوافقة مع الحوافز، حيث يقدم المشاركون عطاءات مختومة لعنصر ما، ويفوز أعلى مزايد بالعنصر ولكنه يدفع ثاني أعلى سعر [214]. اقتصاديات التشفير هي شكل خاص بالمجال من أشكال MD الذي يعزز التشفير تقنيات لخلق التوازنات المرغوبة داخل الأنظمة اللامركزية. تخلق الرشوة والتواطؤ تحديات كبيرة في جميع أنحاء مجال الطب. تتعطل جميع الآليات تقريبًا في ظل وجود التواطؤ، الذي يُعرف بأنه عقود جانبية.بين الأطراف المشاركة في الآلية [125، 130]. وتمثل الرشوة، حيث يقدم طرف خارجي حوافز جديدة إلى اللعبة، مشكلة أكثر صعوبة مما يفعله التواطؤ. يمكن النظر إلى التواطؤ على أنه حالة خاصة من الرشوة بين اللعبة المشاركين. غالبًا ما يمكن تصور أنظمة Blockchain على أنها ألعاب ذات عوائد نقدية (قائمة على العملات المشفرة). مثال بسيط هو تعدين إثبات العمل: يتمتع عمال المناجم بمساحة عمل حيث يمكنهم اختيار hashالمعدل الذي سيتم من خلاله تعدين الكتل. إن مكافأة التعدين هي مكافأة سلبية مضمونة (تكلفة الكهرباء والمعدات) بالإضافة إلى مؤشر ستوكاستيك مكافأة إيجابية (دعم التعدين) تعتمد على عدد عمال المناجم النشطين الآخرين [106، 172] ورسوم المعاملات. يعد التعهيد الجماعي oracles مثل SchellingCoin [68] مثالًا آخر: مساحة الإجراء هي مجموعة التقارير المحتملة التي قد يرسلها oracle، بينما الدفع هو المكافأة المحددة بواسطة آلية oracle، على سبيل المثال، قد يعتمد الدفع حول مدى قرب تقرير oracle من متوسط التقارير الأخرى [26، 68، 119، 185]. توفر ألعاب البلوكشين فرصًا ناضجة لهجمات التواطؤ والرشوة؛ في الواقع، يمكن لـ smart contracts تسهيل مثل هذه الهجمات [96، 165]. ولعل أشهرها هجوم الرشوة على التعهيد الجماعي oracles هو هجوم p-plus-epsilon [67]. هذا الهجوم ينشأ في سياق آلية شبيهة بـ SchellingCoin حيث يقدم اللاعبون تقارير ذات قيمة منطقية (أي كاذبة أو صحيحة) ويتم مكافأتهم بـ p إذا وافقوا على تقديم الأغلبية. في هجوم p-plus-epsilon، يعد المهاجم بمصداقية بما يلي: على سبيل المثال، ادفع للمستخدمين $p + ϵ مقابل التصويت الخاطئ إذا كان تقديم الأغلبية صحيحًا فقط. والنتيجة هي التوازن، حيث يتم تحفيز جميع اللاعبين على الإبلاغ عن الأخطاء بغض النظر عما يفعله اللاعبون الآخرون؛ وبالتالي يستطيع الراشي أن يحفز العقد من خلال رشوتها الموعودة للإبلاغ عن الكذب دون دفع الرشوة فعليًا (!). ومع ذلك، فإن استكشاف استراتيجيات الرشوة الأخرى في سياق oracles، وخاصة oracles التي لا يتم التعهيد الجماعي لها، اقتصر على خصومة ضعيفة إلى حد ما نماذج. على سبيل المثال، في إعداد إثبات العمل (PoW)، قام الباحثون بدراسة النتائج المشروطة الرشاوى، أي الرشاوى المدفوعة فقط إذا تمت مراقبة الرسالة المستهدفة بنجاح ولم يتم إخضاعها للرقابة تظهر في كتلة، بغض النظر عن تصرفات عامل التعدين الفردي [96، 165]. في هذه الحالة من oracles، ومع ذلك، بخلاف هجوم p-plus-epsilon، فنحن على علم فقط بالعمل في نموذج محدود للغاية من الرشوة حيث يرسل الراشي رشوة مشروطة ب تصرفات اللاعب الفردية، وليس على النتيجة الناتجة. نرسم هنا تصميمات لآليات استنباط المعلومات التي تظل حافزًا متوافق حتى في نموذج الخصم القوي، كما هو موضح في القسم الفرعي التالي. 9.3 افتراضات النمذجة في هذا القسم الفرعي، نوضح كيف نقوم بنمذجة سلوك وقدرات اللاعبين نظامنا، على وجه التحديد عقد المستوى الأول oracle، والعقد في المستوى الثاني (التحكيم) الطبقة، والأعداء.9.3.1 نموذج الحوافز من المستوى الأول: الجهات الفاعلة العقلانية تعتمد العديد من أنظمة blockchain للأمان على افتراض وجود عدد من الصدق العقد المشاركة. يتم تعريف العقد على أنها صادقة إذا اتبعت البروتوكول حتى عندما لا يكون من مصلحتهم المالية القيام بذلك. أنظمة إثبات العمل عادةً تتطلب أغلبية hash السلطة لتكون صادقة، وتتطلب أنظمة إثبات الملكية عادةً 2/3 أو أكثر من جميع الحصص المشاركة لتكون صادقة، وحتى أنظمة الطبقة الثانية مثل تتطلب Arbitrum [141] مشاركًا واحدًا صادقًا على الأقل. في نمذجة آلية staking، قمنا بوضع افتراض أضعف بكثير. (ليكون إن الافتراضات الواضحة والأضعف تعني خصائص أمنية أقوى وبالتالي فهي مفضلة.) نحن نفترض أن الخصم قد أفسد، أي الضوابط، بعض (الأقلية) جزء من عقد الطبقة الأولى oracle. نحن نصمم العقد المتبقية وليس كوكلاء صادقين، ولكن كمعظمات عقلانية متوقعة للمنفعة. تعمل هذه العقد بالكامل وفقًا لحوافز مالية ذاتية، وتختار الإجراءات التي تؤدي إلى مكاسب مالية متوقعة كسب. على سبيل المثال، إذا عُرضت على العقدة رشوة أكبر من المكافأة الناتجة عنها السلوك الصادق، فإنه سيقبل الرشوة. ملاحظة على العقد الخصومة: وفقا لنموذج الثقة المشترك ل الأنظمة اللامركزية، نفترض أن جميع العقد عقلانية، أي تسعى إلى تعظيمها صافي الإيرادات، بدلاً من السيطرة عليها من قبل خصم خبيث. مطالباتنا، ومع ذلك - التأثير الخطي الفائق أو التربيعي staking على وجه التحديد - يتم توفيره بشكل مقارب أن مجموعة العقد التي يتم التحكم فيها بشكل عدائي تكون على الأكثر (1/2 -c)n، بالنسبة للبعض إيجابية ثابت ج. 9.3.2 نموذج التحكيم من المستوى الثاني: الصحة بالافتراض تذكر أن إحدى الميزات المهمة لآلية staking التي تساعد في تحقيق الأمان ضد العقد العقلانية هو نظام الطبقة الثانية. في آلية staking المقترحة، فإن أي oracle قد يثير تنبيهًا يشير إلى ذلك تعتقد أن مخرجات الآلية غير صحيحة. يؤدي التنبيه إلى درجة عالية من الثقة تفعيل نظام المستوى الثاني والإبلاغ عن النتيجة الصحيحة. وبالتالي، النمذجة الرئيسية الشرط لنهجنا هو الحكم الصحيح، أي الإبلاغ الصحيح من قبل نظام الدرجة الثانية. يفترض نموذج staking الخاص بنا نظامًا من المستوى الثاني يعمل كمصدر للحقيقة غير قابل للفساد وموثوق به إلى أقصى حد. ومن المرجح أن يكون مثل هذا النظام مكلفًا وبطيئًا، وبالتالي غير مناسب للاستخدام في الحالة النموذجية. ولكن في حالة التوازن، أي متى إذا كان نظام المستوى الأول يعمل بشكل صحيح، فلن يتم استدعاء نظام المستوى الثاني. وبدلاً من ذلك، فإن وجوده يعزز أمان نظام oracle بالكامل من خلال توفير ملف مساندة عالية الضمان. إن استخدام طبقة تحكيم عالية الثقة وعالية التكلفة يشبه عملية الاستئناف في قلب معظم الأنظمة القضائية. كما أنه شائع بالفعل في تصميم oracle النظم، على سبيل المثال، [119، 185]. نحن نناقش بإيجاز طرق تحقيق المستوى الثاني في آليتنا في القسم 9.4.3.يستخدم بروتوكول staking الخاص بنا الفصل الصحيح المفترض لنظام المستوى الثاني كتهديد موثوق به لفرض الإبلاغ الصحيح بواسطة العقد oracle. البروتوكول يصادر جزءًا أو كلًا من حصة oracle العقد التي تولد التقارير المحددة بواسطة نظام الطبقة الثانية غير صحيح. وبالتالي يتم ردع عقد أوراكل عن سوء التصرف بالعقوبة المالية الناتجة. يشبه هذا الأسلوب في النكهة ما تم استخدامه في متفائل rollups، على سبيل المثال، [141، 10]. 9.3.3 نموذج عدائي تم تصميم آليتنا staking للحصول على معلومات صادقة مع تحقيق الأمان ضد فئة واسعة ومحددة جيدًا من الخصوم. ويحسن من الأعمال السابقة، والتي إما تتجاهل نموذجًا عدائيًا صريحًا أو تركز على فئات فرعية ضيقة من الخصوم، على سبيل المثال، خصم p-plus-epsilon الذي تمت مناقشته أعلاه. هدفنا هو تصميم staking آلية ذات أمان مثبت رسميًا ضد مجموعة كاملة من الخصوم المحتملين التي يجب مواجهتها في الممارسة العملية. نحن نمثل خصمنا على أنه يمتلك ميزانية ثابتة (قابلة للقياس)، يُشار إليها بـ $ ب. يمكن للخصم التواصل بشكل فردي وسري مع كل oracle في الشبكة، ويمكن أن يعرض سرًا على أي فرد oracle دفع رشوة مضمونة ويتوقف ذلك على النتائج العامة التي يمكن ملاحظتها للآلية. تحديد النتائج يمكن أن تشمل الرشاوى، على سبيل المثال، القيمة التي تم الإبلاغ عنها بواسطة oracle، وأي رسائل عامة يتم إرسالها بواسطة أي oracle إلى الآلية (على سبيل المثال، تنبيه)، والقيم التي تم الإبلاغ عنها من قبل الآخرين oracles، والقيمة الناتجة عن الآلية. لا توجد آلية يمكنها الحماية ضد مهاجم بقدرات غير محدودة. ولذلك فإننا نعتبر بعض السلوكيات غير واقعية أو خارجة عن النطاق. نحن نفترض مهاجمنا لا يمكنه كسر أساسيات التشفير القياسية، وكما هو مذكور أعلاه، لديه علامة ثابتة (if يحتمل أن تكون كبيرة) الميزانية $B. ونفترض كذلك أن الخصم لا يسيطر الاتصال في شبكة oracle، خاصة أنه لا يمكن تأخيره بشكل كبير حركة المرور بين عقد الطبقة الأولى و/أو عقد الطبقة الثانية. (إن قدرة الخصم على مراقبة مثل هذا التواصل تعتمد على الآلية المحددة، كما سنوضح أدناه). ولكن بشكل غير رسمي، كما ذكرنا أعلاه، نفترض أن الخصم يمكنه: (1) الفساد جزء من oracle العقد ((1/2 −c)- جزء لبعض الثابت c)، أي التحكم الكامل لهم، و(2) تقديم الرشاوى إلى أي عقد مرغوبة، مع ضمان الدفع المشروط على النتائج التي يحددها الخصم، كما هو موضح أعلاه. بينما لا نقدم نموذجًا رسميًا أو تصنيفًا كاملاً للخصم نطاق إمكانيات الرشوة في هذا المستند التقني، فيما يلي أمثلة على هذه الأنواع الرشاوى التي يشملها نموذجنا. للتبسيط، نفترض أن oracles يصدر قيمة منطقية التقارير التي تكون قيمتها الصحيحة (w.l.o.g) صحيحة، ويتم حساب النتيجة النهائية على أنها سيتم استخدام إجمالي هذه التقارير بواسطة smart contract المستهلك. الراشي الهدف هو أن تكون النتيجة النهائية غير صحيحة، أي كاذبة. • الرشوة غير المشروطة: يقدم مقدم الرشوة رشوة بقيمة $b لأي oracle يقدم تقريرًا كاذبًا. • مقدم الرشوة الاحتمالي: يقدم مقدم الرشوة رشوة $b مع بعض الاحتمالية q إلى أي oracle أن تقارير كاذبة.• رشوة مشروطة بنتيجة كاذبة: يقدم مقدم الرشوة رشوة $b لأي oracle يبلغ عن خطأ بشرط أن تكون النتيجة النهائية خاطئة. • مقدم رشوة مشروط بعدم التنبيه: يعرض مقدم الرشوة مبلغ $b على أي oracle يقوم بالإبلاغ كاذبة طالما لم يتم رفع أي تنبيه. • p-plus-epsilon Briber: يقدم مقدم الرشوة رشوة $b لأي oracle يبلغ عن خطأ باسم طالما أن غالبية oracles لم يبلغوا عن خطأ. • مقدم الرشوة المحتمل: يقدم مقدم الرشوة مبلغ $b مقدمًا لأي جهة تم تحديدها oracle لدور عشوائي وتقارير كاذبة. في بروتوكولنا staking المقترح، كل شيء تعمل العقد كهيئات رقابة محتملة، ونحن قادرون على إظهار هذا التوزيع العشوائي من أولويات الوكالة الرقابية لا تصلح للرشوة المحتملة. العديد من أعمال إثبات العمل، proof-of-stake، والأنظمة المرخصة عرضة للاحتمالات ولكن الرشوة مما يدل على أهمية أخذها في الاعتبار في خصومنا النموذج والتأكد من أن بروتوكولات staking لدينا مرنة تجاهه. انظر الملحق ه لمزيد من التفاصيل. 9.3.4 ما مقدار الأمن الاقتصادي المشفر الكافي؟ لن ينفق الخصم العقلاني الأموال لمهاجمة النظام إلا إذا كان بإمكانه الحصول على الربح أكبر من نفقاتها. وهكذا بالنسبة لنموذجنا العدائي والمقترح staking في هذه الآلية، قد يُنظر إلى $B على أنه مقياس للربح المحتمل الذي يمكن أن يحققه الخصم للاستخراج من الاعتماد على smart contracts عن طريق إتلاف شبكة oracle والتسبب في ذلك لإنشاء تقرير أو مجموعة تقارير غير صحيحة. في تحديد ما إذا كانت شبكة oracle توفر درجة كافية من الأمان الاقتصادي المشفر لأغراضها، كما ينبغي للمستخدم تقييم الشبكة من هذا المنظور. بالنسبة للخصوم المحتملين في الإعدادات العملية، نتوقع أن يكون $B بشكل عام أصغر بكثير من إجمالي الأصول في الاعتماد على smart contracts. في معظم الحالات، فإنه من غير الممكن للخصم أن ينتزع هذه الأصول في مجملها. 9.4 آلية التوقيع المساحي: رسم نقدم هنا الأفكار الرئيسية والهيكل العام لآلية staking التي نقوم بها تدرس حاليا. لسهولة العرض، وصفنا بسيطة ولكنها بطيئة (متعدد الجولة) البروتوكول في هذا القسم الفرعي. ومع ذلك، نلاحظ أن هذا المخطط تماما عملي. ونظرًا للضمانات الاقتصادية التي توفرها الآلية، أي المعاقبة والحوافز اللاحقة ضد العقد المعيبة، فقد يكون العديد من المستخدمين على استعداد لـ قبول التقارير بتفاؤل. بمعنى آخر، قد يقبل هؤلاء المستخدمون التقارير قبل ذلك حكم محتمل من الدرجة الثانية. يمكن للمستخدمين غير الراغبين في قبول التقارير بتفاؤل أن يختاروا الانتظار حتى البروتوكول وينتهي التنفيذ، أي حتى يحدث أي تصعيد محتمل إلى المستوى الثاني. هذا، ومع ذلك، يمكن أن يؤدي ذلك إلى إبطاء وقت تأكيد التقارير بشكل كبير. لذلك نحن باختصارالشكل 15: رسم تخطيطي لنظام staking مع التنبيه. في هذا المثال، 1⃝أغلبية من العقد تالفة/مرشوشة وتصدر قيمة غير صحيحة ˜r، بدلاً من القيمة الصحيحة قيمة التقرير ص. تقوم عقدة المراقبة 2⃝ بإرسال تنبيه إلى لجنة المستوى الثاني، الذي يحدد ويصدر قيمة التقرير الصحيحة r، مما يؤدي إلى تلف العقد مصادرة ودائعهم — كل $d إلى عقدة المراقبة 4⃝. حدد بعض التحسينات التي تؤدي إلى سرعة (جولة واحدة) إذا كانت أكثر إلى حد ما التصميم المعقد في القسم 9.5. تذكر أن الطبقة الأولى في آليتنا staking تتكون من oracle الأساسية الشبكة نفسها. الهيكل الرئيسي لآليتنا، كما هو موضح أعلاه، هو أنه في كل جولة، يمكن لكل عقدة أن تعمل بمثابة "المراقبة" مع بعض الأولوية، وبالتالي لديها القدرة على القيام بذلك قم بإطلاق تنبيه إذا وصلت الآلية إلى مخرج غير صحيح، بدلاً من الصحيح ص واحد. يؤدي هذا التنبيه إلى دقة المستوى الثاني، والتي نفترض أنها تصل إلى الحل الصحيح تقرير. تتم معاقبة العقد التي تحتوي على تقارير غير صحيحة، بمعنى أن مخاطرها قطعت ومنحتها لهيئات المراقبة. هذه البنية الأساسية شائعة في أنظمة oracle، كما في مثلا [119، 185]. الابتكار الرئيسي في تصميمنا، المذكور بإيجاز أعلاه، هو أن كل عقدة أعطيت أولوية مميزة في ترتيب هيئات المراقبة المحتملة. وهذا هو، المراقبين يتم منح فرص للتنبيه في تسلسل الأولوية. تذكر أنه إذا كانت العقدة تحتوي على الأولوية القصوى لرفع التنبيه، فإنه يتلقى الوديعة المقطوعة $d لكل سوء تصرف العقدة، بإجمالي أكثر من \(dn/2 = \)d × n/2، حيث يشير التقرير غير الصحيح إلى غالبية العقد السيئة. وبالتالي، يجب على الخصم أن يدفع هذه المكافأة على الأقل رشوة عقدة تعسفية. وبالتالي، لرشوة غالبية العقد، يجب على الخصم أن يدفع أ رشوة كبيرة لغالبية العقد، أي أكثر من $dn2/2. نعرض بشكل تخطيطي كيفية عمل التنبيه وتصعيد المراقبة في الشكل 15.9.4.1 مزيد من تفاصيل الآلية إن نظام مقاومة الرشوة الذي نصفه الآن بمزيد من التفصيل هو رسم مبسط لـ البناء ذو المستويين الذي نعتزم بناءه. سيكون معظم تركيزنا على الوصف شبكة المستوى الأول (من الآن فصاعدا ببساطة "الشبكة" حيث يكون ذلك واضحا من السياق) جنبا إلى جنب مع آلية الحوافز وإجراءات التصعيد إلى المستوى الثاني. خذ بعين الاعتبار شبكة Chainlink مكونة من عدد oracle من العقد المسؤولة عن يتم الإبلاغ بانتظام (على سبيل المثال، مرة واحدة في الدقيقة) عن قيمة منطقية (على سبيل المثال، ما إذا كان السوق القيمة السوقية لـ BTC تتجاوز قيمة ETH). كجزء من آلية staking، العقد يجب تقديم وديعتين: وديعة $d قابلة للقطع في حالة الخلاف مع إيداع الأغلبية والمراقبة $dw الخاضع للتخفيض في حالة حدوث خلل التصعيد. نحن نفترض أن العقد لا يمكنها نسخ إرسالات العقد الأخرى، على سبيل المثال، من خلال مخطط الالتزام والكشف كما تمت مناقشته في القسم 5.3. في كل جولة، العقد أولاً الالتزام بتقريرهم، وبمجرد التزام جميع العقد (أو انتهاء المهلة)، العقد تكشف تقاريرها. بالنسبة لكل تقرير يتم إنشاؤه، يتم منح كل عقدة أيضًا أولوية مراقبة بين 1 وn يتم اختيارها عشوائيًا، مع كون 1 أولوية قصوى. هذه الأولوية تمكن تركيز المكافأة في يد جهة رقابية واحدة. بعد أن أصبحت جميع التقارير علنية، وتتبع ذلك مرحلة تنبيه. على مدى سلسلة من جولات n (متزامنة)، العقدة مع الأولوية لدي الفرصة للتنبيه في الجولة الأولى. دعونا نفكر في النتائج المحتملة للآلية بعد الكشف عن العقد تقاريرهم. مرة أخرى بافتراض وجود تقرير ثنائي، لنفترض أن القيمة الصحيحة صحيحة و الخطأ هو كاذب. لنفترض أيضًا أن آلية المستوى الأول تقوم بإخراج إخراج قيمة الأغلبية بواسطة العقد كالتقرير النهائي r. هناك ثلاث نتائج محتملة في الآلية: • اتفاق كامل: في أفضل الأحوال، تكون العقد في اتفاق كامل: جميع العقد متوفرة وقدمت تقريرًا في الوقت المناسب بنفس القيمة r (إما صحيحًا أو كاذبة). في هذه الحالة، تحتاج الشبكة فقط إلى إعادة توجيه العقود المعتمدة ومكافأة كل عقدة بدفعة ثابتة لكل جولة $p، وهي أصغر بكثير من $د. • اتفاق جزئي: من الممكن أن تكون بعض العقد غير متصلة بالإنترنت أو أن هناك خلافًا حول القيمة الصحيحة، ولكن معظم العقد تفيد بأنها صحيحة وفقط تقارير الأقلية كاذبة. هذه الحالة واضحة أيضًا. قيمة الأغلبية (صحيح) يتم حسابها، مما يؤدي إلى تقرير صحيح ص. جميع العقد التي ذكرت r هي تمت مكافأتهم بـ $p بينما oracles الذين أبلغوا بشكل غير صحيح لديهم ودائعهم تم تخفيضها بشكل متواضع، على سبيل المثال، بمقدار 10 بنس. • تنبيه: في حالة اعتقاد جهة المراقبة أن مخرجات الشبكة غير صحيحة، فهو يطلق تنبيهًا علنيًا، مما يؤدي إلى تصعيد الآلية إلى شبكة المستوى الثاني. ثم هناك نتيجتان محتملتان: - التنبيه الصحيح: إذا أكدت شبكة المستوى الثاني أن إخراجالشكل 16: تضخيم تكلفة الرشوة من خلال مكافآت التنبيه المركزة. رشوة يجب على الخصم رشوة كل عقدة بأكثر من المكافأة التي يمكنها الحصول عليها من خلال التنبيه (يظهر كشريط أحمر). إذا تمت مشاركة مكافآت التنبيه، فقد تكون هذه المكافأة نسبيًا صغير. تعمل مكافآت التنبيه المركزة على زيادة المكافأة التي قد تحصل عليها أي عقدة واحدة الحصول على (شريط أحمر طويل القامة). ومن ثم فإن المبلغ الإجمالي الذي يدفعه الخصم مقابل رشوة قابلة للتطبيق (المناطق الرمادية) أكبر بكثير وتحتوي على مكافآت تنبيه مركزة أكثر من المشتركة. كانت شبكة المستوى الأول غير صحيحة، وتتلقى عقدة المراقبة التنبيهية مكافأة تتكون من جميع الودائع المقطوعة، وبالتالي أكثر من $dn/2. – تنبيه خاطئ: إذا وافق المستوى الثاني والمستوى الأول oracles، فسيتم التصعيد تعتبر معيبة وتفقد عقدة التنبيه إيداعها $dw. في حالة القبول المتفائل للتقارير، لا تسبب تنبيهات المراقبة أي تغيير في تنفيذ عقود الاعتماد. للعقود المصممة للانتظار التحكيم المحتمل من قبل لجنة المستوى الثاني، تنبيهات الوكالة الرقابية تأخير ولكن لا تجميد تنفيذ العقد. من الممكن أيضًا أن تحدد العقود أ تجاوز الفشل DON لفترات الفصل في الأحكام. 9.4.2 تأثير التوقيع المساحي التربيعي قدرة كل عقدة على العمل كجهة رقابية، بالإضافة إلى أولوية العقدة الصارمة ضمان المكافآت المركزة، يمكّن الآلية من تحقيق المعادلة التربيعية staking تأثير كل نوع من مهاجمي الرشوة الموصوفين في القسم 9.3.3. أذكر أن هذا يعني على وجه التحديد في إعدادنا أنه بالنسبة لشبكة تحتوي على عدد n من العقد لكل منها إيداع $d، يجب أن يكون لدى الراشي الناجح (من أي من الأنواع المذكورة أعلاه) ميزانية أكبر من $dn2/2. على وجه الدقة، يجب على الراشي أن يفسد ما لا يقل عن (n+1)/2 عقدة، حيث يجب على الراشي أن يفسد إفساد غالبية العقد n (بالنسبة إلى n الفردية، حسب الافتراض). وهكذا تقف جهة المراقبة احصل على مكافأة قدرها $d(n + 1)/2. وبالتالي يجب على الراشي أن يدفع هذا المبلغ لكل شخصعقدة للتأكد من أن لا أحد يعمل كرقيب. نحن نعمل على إظهار ذلك رسميًا إذا يمتلك مقدم الرشوة ميزانية قدرها $d(n2 + n)/2 على الأكثر، ومن ثم تحقق التوازن المثالي للعبة الفرعية للعبة بين المرتشيين وoracle، وبعبارة أخرى، التوازن عند أي نقطة أثناء ممارسة اللعبة — هي ألا يقوم الراشي بإصدار الرشوة و كل oracle للإبلاغ عن قيمه الحقيقية بأمانة. لقد أوضحنا أعلاه كيف أنه من الممكن أن يطلب الراشي الناجح الحصول على الميزانية أكبر بكثير من مجموع ودائع العقدة. لتوضيح هذا نتيجة بديهية، يوضح الشكل 16 تأثير مكافآت التنبيه المركزة بيانياً. كما نرى هناك، إذا كانت مكافأة الوكالة الرقابية على التنبيه — وهي ودائع الرشوة العقد التي أبلغت عن خطأ) - تم تقسيمها بين جميع التنبيهات المحتملة، المبلغ الإجمالي لذلك أي عقدة تنبيه فردية يمكن أن تتوقعها ستكون صغيرة نسبيًا، حسب ترتيب $د. يمكن أن يستخدمه الراشي، وهو يعلم أن دفع تعويضات أكبر من $d أمر غير محتمل رشوة مشروطة ذات نتيجة كاذبة لرشوة كل من العقد n بأكثر قليلاً من $ د + ϵ. وعلى عكس ما هو متوقع، يوضح الشكل 16 أن النظام يقوم بتوزيع المكافأة على نطاق واسع بين العقد التي تشير إلى التنبيه أضعف بكثير من تلك التي تركز المكافأة فيها أيدي رقيب واحد. معلمات المثال: خذ بعين الاعتبار شبكة (من المستوى الأول) تحتوي كل منها على عدد = 100 عقدة إيداع \(d = \)20K. سيكون لهذه الشبكة ما مجموعه 2 مليون دولار مودعة ولكنها ستفعل ذلك كن محميًا ضد الراشي بميزانية \(100M = \)dn2/2. زيادة عدد oracles أكثر فعالية من زيادة $d، بالطبع، ويمكن أن يكون لها تأثير كبير: سيتم حماية الشبكة التي تحتوي على n = 300 عقدة وودائع \(d = \)20K ضد رشوة بميزانية تصل إلى 900 مليون دولار. لاحظ أن نظام staking يمكنه في كثير من الحالات حماية smart contracts التي تمثل قيمة أكبر من المستوى المعروض للحماية من الرشوة. وذلك لأن الخصم فمهاجمة هذه العقود لا يمكنها انتزاع القيمة الكاملة في كثير من الحالات. على سبيل المثال، أ Chainlink قد يتطلب العقد المدعوم بقيمة 1 مليار دولار ضمانًا فقط مقابل أ رشوة بموارد تبلغ 100 مليون دولار لأن مثل هذا الخصم يمكنه استخلاص الربح بشكل عملي 10% فقط من قيمة العقد. ملحوظة: يتم التعبير عن فكرة أن قيمة الشبكة يمكن أن تنمو بشكل تربيعي قانون ميتكالف المعروف [167، 235]، والذي ينص على أن قيمة الشبكة ينمو بشكل تربيعي في عدد الكيانات المتصلة. لكن قانون ميتكالف تنشأ من النمو في عدد اتصالات الشبكة الزوجية المحتملة، وهي ظاهرة مختلفة عن التأثير التربيعي الأساسي staking في حافزنا آلية. 9.4.3 تحقيق الطبقة الثانية هناك ميزتان تشغيليتان تسهلان تحقيق مستوى ثانٍ عالي الموثوقية: (1) يجب أن يكون التحكيم من المستوى الثاني حدثًا نادرًا في شبكات oracle وبالتالي يمكن ذلك تكون أكثر تكلفة بكثير من التشغيل العادي للطبقة الأولى و(2) بافتراضالتقارير المقبولة بتفاؤل – أو العقود التي يمكن أن ينتظر تنفيذها التحكيم – لا يلزم تنفيذ المستوى الثاني في الوقت الفعلي. هذه الميزات تؤدي إلى مجموعة من خيارات التكوين للطبقة الثانية لتلبية متطلبات DONs معينة. وكمثال على ذلك، يمكن أن تتكون لجنة المستوى الثاني من العقد التي يختارها أ DON (أي الطبقة الأولى) من العقد الأطول خدمة والأكثر موثوقية في Chainlink شبكة. بالإضافة إلى الخبرة التشغيلية الكبيرة ذات الصلة، فإن المشغلين من هذه العقد لديها حافز ضمني كبير في FFO الذي يحفز الرغبة للتأكد من أن شبكة Chainlink تظل موثوقة للغاية. لديهم أيضا علنا سجلات الأداء المتاحة التي توفر الشفافية في موثوقيتها. تجدر الإشارة إلى أن عقد المستوى الثاني لا تحتاج إلى أن تكون مشاركين في شبكة المستوى الأول، و قد يفصل في الأخطاء عبر شبكات متعددة من الدرجة الأولى. يمكن للعقد الموجودة في DON أن تحدد مسبقًا وتلتزم علنًا بمجموعة من هذه العناصر العقد باعتبارها تشكل لجنة المستوى الثاني لذلك DON. بالإضافة إلى ذلك، DON تنشر العقد المعلمة k ′ ≥n ′ التي تحدد عدد أصوات الطبقة الثانية مطلوب لمعاقبة عقدة من الدرجة الأولى. عندما يتم إنشاء تنبيه لتقرير معين، يصوت أعضاء الطبقة الثانية على صحة القيم المقدمة من كل منهم من عقد الطبقة الأولى. أي عقدة من الدرجة الأولى تحصل على أصوات سلبية k′ ستفقد حقها الودائع إلى عقدة المراقبة. بسبب ندرة إصدار الأحكام وفرصة التنفيذ لمدة طويلة المذكورة أعلاه، وعلى النقيض من الطبقة الأولى، يمكن للعقد في الطبقة الثانية: 1. أن يحصل على أجر كبير مقابل إجراء التحكيم. 2. اعتمد على مصادر بيانات إضافية، تتجاوز حتى المجموعة المتنوعة التي يستخدمها المستوى الأول. 3. الاعتماد على التفتيش والتدخل اليدوي و/أو الخبراء، على سبيل المثال، لتحديد و التوفيق بين الأخطاء في بيانات المصدر والتمييز بين ترحيل العقدة الصادق بيانات خاطئة وعقدة تتصرف بشكل غير صحيح. نؤكد على أن النهج الذي وصفناه للتو لاختيار العقد من الدرجة الثانية والفصل في السياسات التي تحكم السياسة لا يمثل سوى نقطة ضمن نطاق كبير مساحة التصميم للإنجازات المحتملة للطبقة الثانية. تقدم آلية الحوافز لدينا المرونة الكاملة فيما يتعلق بكيفية تحقيق المستوى الثاني. يمكن للأفراد DONs القيام بذلك تشكل وتضع قواعد للمستويات الثانية التي تلبي المتطلبات الخاصة وتوقعات العقد والمستخدمين المشاركين. DECO وTown Crier كأدوات تحكيمية: إنه ضروري للطبقة الثانية في آليتنا لنكون قادرين على التمييز بين عقد الطبقة الأولى المتعارضة إنتاج تقارير غير صحيحة عن عمد وعقد من الدرجة الأولى صادقة عن غير قصد ترحيل البيانات غير الصحيحة في المصدر. عندها فقط يمكن تنفيذ المستوى الثاني القطع لتثبيط الغش، هو هدف آليتنا. ديكو وتاون كريير هي أدوات قوية يمكنها تمكين العقد من المستوى الثاني من تحقيق هذا التمييز الحاسم بشكل موثوق.قد تتمكن عقد الطبقة الثانية في بعض الحالات من الاستعلام مباشرة عن مصدر البيانات المستخدم بواسطة عقدة من الدرجة الأولى أو استخدم قسم ADO 7.1 للتحقق مما إذا كان التقرير غير صحيح نتجت عن مصدر بيانات خاطئ. ومع ذلك، في حالات أخرى، قد لا توجد عقد من المستوى الثاني الوصول المباشر إلى مصدر بيانات عقدة الطبقة الأولى. وفي مثل هذه الحالات يكون الحكم الصحيح تبدو غير ممكنة أو تتطلب الاعتماد على حكم شخصي. السابق oracle وقد اعتمدت أنظمة حل النزاعات على جولات تصويت متصاعدة وغير فعالة لمعالجة هذه المشكلة التحديات. ومع ذلك، باستخدام DECO أو Town Crier، يمكن لعقدة المستوى الأول أن تثبت السلوك الصحيح إلى عقد الطبقة الثانية. (انظر القسم 3.6.2 للحصول على تفاصيل حول النظامين.) على وجه التحديد، إذا تحدد عقدة المستوى الثاني عقدة المستوى الأول على أنها قامت بإخراج قيمة تقرير خاطئة ˜r، يمكن لعقدة المستوى الأول استخدام DECO أو Town Crier لإنشاء دليل مضاد للتلاعب عقد الطبقة الثانية التي تقوم بنقلها بشكل صحيح من مصدر (ممكّن لـ TLS). معترف بها على أنها موثوقة بواسطة DON. والأهم من ذلك أن عقدة المستوى الأول يمكنها القيام بذلك دون عقد من المستوى الثاني تتطلب الوصول المباشر إلى مصدر البيانات.17 وبالتالي، من الممكن إصدار قرار صحيح في Chainlink لأي مصدر بيانات مرغوب فيه. 9.4.4 الإبلاغ الخاطئ عن التأمين إن المقاومة القوية للرشوة التي حققتها آلية staking تعتمد بشكل أساسي على الأموال المقطوعة الممنوحة للمنبهين. وبدون مكافأة مالية، فإن التنبيهات سوف تفعل ذلك ليس لديهم حافز مباشر لرفض الرشاوى. ونتيجة لذلك، فإن الأموال المقطوعة ليست كذلك متاحة لتعويض المستخدمين المتضررين من التقارير غير الصحيحة، على سبيل المثال، المستخدمين الذين يخسرون أموالاً عندما يتم ترحيل بيانات السعر غير الصحيحة إلى smart contract. من المفترض أن التقارير غير الصحيحة لا تشكل مشكلة إذا تم قبول التقارير من قبل أ العقد فقط بعد صدور حكم محتمل، أي الإجراء الذي يتخذه المستوى الثاني. كما هو موضح أعلاه، على الرغم من ذلك، لتحقيق أفضل أداء ممكن، قد تعتمد العقود بدلاً من ذلك متفائلون بآلية فرض الإبلاغ الصحيح، أي أنهم يقبلون التقارير قبل الفصل المحتمل من الدرجة الثانية. في الواقع، مثل هذا السلوك المتفائل هو آمن في نموذجنا بافتراض وجود خصوم عقلانيين لا تتجاوز ميزانياتهم staking تأثير الآلية. المستخدمون يشعرون بالقلق إزاء الحدث غير المحتمل لفشل الآلية الناتج عن، على سبيل المثال، قد يرغب الخصوم الذين لديهم موارد مالية هائلة في استخدام طبقة إضافية من الأمن الاقتصادي في شكل الإبلاغ الخاطئ عن التأمين. نحن نعرف وتعتزم العديد من شركات التأمين بالفعل تقديم وثائق تأمين مدعومة بعقود ذكية من هذا النوع لـ Chainlink-البروتوكولات الآمنة في المستقبل القريب، بما في ذلك من خلال آليات مبتكرة مثل DAOs، على سبيل المثال، [7]. وجود سجل الأداء لـ Chainlink توفر العقد والبيانات الأخرى حول العقد، مثل مبالغ حصصها، أساسًا قويًا بشكل استثنائي للتقييمات الاكتوارية للمخاطر، مما يجعل من الممكن سياسات التسعير بطرق غير مكلفة لحاملي وثائق التأمين ولكنها مستدامة بالنسبة لشركات التأمين. 17 باستخدام Town Crier، من الممكن أيضًا لعقد المستوى الأول إنشاء الشهادات محليًا من صحة التقارير التي يصدرونها ويقدمون هذه الشهادات إلى العقد من المستوى الثاني على أساس حسب الحاجة.يمكن تنفيذ الأشكال الأساسية لتأمين الإبلاغ الخاطئ بطريقة جديرة بالثقة بطريقة فعالة باستخدام smart contracts. كمثال بسيط، التأمين البارامترى يمكن لعقود SCins تعويض حاملي وثائق التأمين تلقائيًا إذا كانت آلية الحوافز لدينا يحدد المستوى الثاني خطأً في التقرير الذي تم إنشاؤه في المستوى الأول. المستخدم U الذي يرغب في شراء بوليصة تأمين، على سبيل المثال، منشئ الهدف يمكن للعقد SC، تقديم طلب إلى شركة تأمين لامركزية للحصول على مبلغ السياسة مليون دولار على العقد. عند الموافقة على U، يمكن لشركة التأمين تعيين مبلغ مستمر (على سبيل المثال، شهري) علاوة $P في SCins. بينما تدفع U القسط، تظل سياستها نشطة. في حالة حدوث فشل في الإبلاغ في SC، ستكون النتيجة انبعاث زوج (r1، r2) التقارير المتضاربة لـ SC، حيث يتم توقيع r1 بواسطة المستوى الأول في آليتنا و r2، التقرير المصحح المقابل، موقع من قبل الطبقة الثانية. إذا قدمت U مثل هذا الزوج الصالح (r1، r2) إلى SCins، يدفع لها العقد تلقائيًا مليون دولار، بشرط مدفوعات أقساطها محدثة. 9.5 البديل جولة واحدة يتطلب البروتوكول الموصوف في القسم الفرعي السابق أن تنتظر لجنة المستوى الثاني عددًا من الجولات لتحديد ما إذا كانت هيئة المراقبة قد أطلقت تنبيهًا أم لا. هذا ويظل هذا المتطلب قائمًا حتى في الحالة المتفائلة، أي عندما يعمل المستوى الأول بشكل صحيح. للمستخدمين غير الراغبين في قبول التقارير بتفاؤل، أي قبل الإمكانات الحكم، فإن التأخير المرتبط بهذا النهج سيكون غير عملي. ولهذا السبب، فإننا نستكشف أيضًا بروتوكولات بديلة تتطلب بروتوكولًا واحدًا فقط جولة. في هذا الأسلوب، ترسل كافة العقد oracle بتات سرية تشير إلى ما إذا كان سيتم ذلك أم لا يرغبون في رفع مستوى التنبيه. ثم تقوم لجنة المستوى الثاني بالتحقق من هذه القيم ترتيب الأولوية. لتقديم رسم تقريبي، قد يتضمن هذا المخطط ما يلي الخطوات: 1. تقديم بتات الوكالة الدولية للطاقة: تشترك كل عقدة سرية في Oi في قيمة مراقبة مكونة من بتة واحدة wi ∈{no تنبيه، تنبيه} بين العقد في المستوى الثاني لكل تقرير ينشئه. 2. نصائح مجهولة المصدر: يمكن لأي عقدة oracle تقديم نصيحة مجهولة المصدر α إلى لجنة المستوى الثاني في نفس الجولة التي يتم فيها تقديم بتات المراقبة. هذه النصيحة α هي رسالة تشير إلى أنه قد تم رفع تنبيه للتقرير الحالي. 3. فحص بتات الوكالة الدولية للطاقة: تكشف لجنة المستوى الثاني عن هيئة مراقبة العقد oracle البتات حسب الأولوية. لاحظ أن العقد يجب ألا ترسل أي بتات رقابية للتنبيه عندما لا تنبه: وإلا فإن تحليل حركة المرور يكشف عن بتات جميع العقد. يكشف البروتوكول عن حالة عدم التنبيه بتات الوكالة الرقابية للعقد ذات أولوية أعلى من الوكالة الرقابية للتنبيه ذات الأولوية القصوى. لاحظ أن ما تم الكشف عنه مطابق لما ورد في بروتوكول n-round الخاص بنا. يتم أيضًا توزيع المكافآت بشكل مماثل لهذا المخطط، أي أول جهة رقابية يتم تحديدها يتلقى الودائع المقطوعة للعقد التي قدمت تقارير غير صحيحة.إن استخدام النصائح مجهولة المصدر يمكّن لجنة المستوى الثاني من البقاء غير تفاعلية في الحالات التي لم يتم فيها رفع أي تنبيه، مما يقلل من تعقيد الاتصال في الحالة المشتركة. لاحظ أن أي جهة رقابية ترفع تنبيهًا لديها حافز اقتصادي لتقديم نصيحة مجهولة المصدر: إذا لم يتم تقديم أي نصيحة، فلن يتم دفع أي مكافأة لأي شخص عقدة. للتأكد من أنه لا يمكن التعرف على المرسل Oi للطرف المجهول α بواسطة الخصم بناءً على بيانات الشبكة، يمكن إرسال معلومات مجهولة المصدر عبر مجهول القناة، على سبيل المثال، عبر Tor، أو، بشكل أكثر عملية، وكيل عبر مزود خدمة سحابية. ل مصادقة الطرف على أنه نشأ بـ O، يمكن لـ Oi التوقيع على α باستخدام التوقيع الدائري [39، 192]. وبدلاً من ذلك، لمنع هجمات رفض الخدمة غير المنسوبة ضد لجنة المستوى الثاني بواسطة عقدة oracle ضارة، يمكن أن تكون α بيانات اعتماد مجهولة مع عدم الكشف عن هويته القابلة للإلغاء [73]. ورغم أن هذا البروتوكول قابل للتحقيق عمليا، إلا أنه يتمتع بهندسة ثقيلة الوزن إلى حد ما المتطلبات (التي نستكشف طرقًا لتقليلها). العقد من الدرجة الأولى، على سبيل المثال، يجب أن تتواصل مباشرة مع عقد المستوى الثاني، مما يتطلب صيانة الدليل. تضيف الحاجة إلى قنوات مجهولة وتوقيعات حلقية إلى الهندسة تعقيد المخطط. وأخيرًا، هناك متطلب ثقة خاص تمت مناقشته بإيجاز في المذكرة أدناه. ولذلك فإننا نستكشف أيضًا مخططات أبسط لا تزال تحقق النجاح تأثير خطي فائق staking، ولكن ربما أقل من تأثير تربيعي، حيث يحتاج مقدم الرشوة بشكل غير مقارب إلى موارد لا تقل عن $n log n، على سبيل المثال. بعض المخططات تحت يتضمن الاعتبار اختيارًا عشوائيًا لمجموعة فرعية صارمة من العقد لتكون بمثابة هيئات رقابة، وفي هذه الحالة تصبح الرشوة المحتملة هجومًا قويًا بشكل خاص. ملاحظة: يتطلب أمان آلية staking ذات الجولة الواحدة عدم إمكانية استغلالها القنوات بين oracle وعقد المستوى الثاني - وهو مطلب قياسي في الأنظمة المقاومة للإكراه، على سبيل المثال، التصويت [82، 138]، وهو مطلب معقول في الممارسة العملية. بالإضافة إلى ذلك، يمكن إنشاء عقدة Oi التي تسعى إلى التعاون مع الراشي أسهمها السرية بطريقة تُظهر للرشوة أنها قامت بتشفير شيء معين قيمة. على سبيل المثال، إذا كان Oi لا يعرف العقد التي يتحكم فيها الرشاوي، فيمكن لـ Oi ذلك تقديم أسهم بقيمة 0 إلى جميع أعضاء اللجنة. يمكن للرشاوي بعد ذلك التحقق من Oi الامتثال احتماليا. ولتجنب هذه المشكلة في أي بروتوكول أحادي الجولة، فإننا تتطلب أن تعرف Oi هوية عقدة واحدة صادقة من الدرجة الثانية على الأقل. باستخدام بروتوكول تفاعلي تضيف فيه كل عقدة من المستوى الثاني توزيعًا عشوائيًا عامل الأسهم، أفضل ما يمكن أن يفعله مقدم الرشوة هو فرض الاختيار بواسطة Oi بشكل عشوائي قليلا الوكالة الدولية للطاقة. 9.6 إطار الحوافز الضمنية (IIF) يعد FFO أحد أشكال الحوافز الضمنية للسلوك الصحيح في شبكة Chainlink. ذلك وظائف مثل الحصة الصريحة، أي الودائع، من حيث أنها تساعد في فرض الأمن الاقتصادي الشبكة. وبعبارة أخرى، ينبغي إدراج FFO كجزء من الوديعة (الفعالة). $d للعقدة في الشبكة.والسؤال هو: كيف يمكننا قياس FFO وغيرها من أشكال الحوافز الضمنية داخل شبكة Chainlink؟ إطار الحوافز الضمنية (IIF) عبارة عن مجموعة من المبادئ والتقنيات التي نخطط لتطويرها لهذا الغرض. أنظمة البلوكشين توفير العديد من أشكال الشفافية غير المسبوقة، وسجلات الثقة العالية للعقدة إن الأداء الذي يقدمونه يشكل نقطة انطلاق لرؤيتنا لكيفية عمل معهد التمويل الدولي. نعرض هنا بإيجاز شديد الأفكار حول العناصر الأساسية لمعهد التمويل الدولي. وسوف يتكون معهد التمويل الدولي نفسه من مجموعة من العوامل التي نعتبرها مهمة في التقييم الحوافز الضمنية، إلى جانب آليات نشر البيانات ذات الصلة في شكل عالي التأكيد لاستهلاكها بواسطة خوارزميات التحليل. يمكن لمستخدمي Chainlink المختلفين ترغب في استخدام معهد التمويل الدولي بطرق مختلفة، على سبيل المثال، إعطاء وزن مختلف لعوامل مختلفة. نتوقع ظهور خدمات تحليلية في المجتمع تساعد المستخدمين على تطبيق IIF وفقًا لتفضيلاتهم الفردية لتقييم المخاطر، وهدفنا هو تسهيل ذلك هذه الخدمات من خلال ضمان وصولهم إلى البيانات الداعمة عالية الجودة وفي الوقت المناسب، كما نناقش أدناه (القسم 9.6.4). 9.6.1 فرصة الرسوم المستقبلية تشارك العقد في النظام البيئي Chainlink لكسب حصة من الرسوم التي تدفعها الشبكات مقابل أي من الخدمات المتنوعة التي وصفناها في هذه الورقة، من تغذي البيانات العادية الخدمات المتقدمة مثل الهوية اللامركزية، والتسلسل العادل، والحفاظ على السرية DeFi. الرسوم في Chainlink تكاليف مشغلي عقدة دعم الشبكة، على سبيل المثال، تشغيل الخوادم، والحصول على تراخيص البيانات اللازمة، والحفاظ على فريق عمل عالمي لضمان وقت تشغيل عالي. يشير FFO إلى رسوم الخدمة، صافي النفقات، التي يمكن للعقدة أن تكسبها في المستقبل - أو تخسرها إذا أظهرت سلوكًا خاطئًا. FFO هو شكل من أشكال الحصة التي تساعد في تأمين الشبكة. الميزة المفيدة لـ FFO هي حقيقة أن البيانات الموجودة على السلسلة (المكملة بالبيانات خارج السلسلة) data) إنشاء سجل عالي الثقة لتاريخ العقدة، مما يتيح حساب FFO بطريقة شفافة مدفوعة تجريبيا. يمكن استخلاص مقياس بسيط من الدرجة الأولى لـ FFO من متوسط ​​صافي الإيرادات لـ a عقدة على مدار فترة زمنية (أي إجمالي الإيرادات مطروحًا منها نفقات التشغيل). FFO قد ثم يتم حسابها على سبيل المثال، صافي القيمة الحالية [114] لصافي الإيرادات المستقبلية التراكمية، وبعبارة أخرى، القيمة المخصومة زمنيا لجميع الأرباح المستقبلية. ومع ذلك، يمكن أن تكون إيرادات العقدة متقلبة، كما هو موضح على سبيل المثال في الشكل 17. والأهم من ذلك، أن إيرادات العقدة قد لا تتبع توزيعًا ثابتًا مع مرور الوقت. وبالتالي، فإن العوامل الأخرى التي نخطط لاستكشافها في تقدير FFO تشمل ما يلي: • سجل الأداء: يوفر سجل أداء المشغل - بما في ذلك صحة تقاريره وتوقيتها، بالإضافة إلى وقت تشغيله - هدفًا المحك للمستخدمين لتقييم موثوقيتها. وهكذا فإن تاريخ الأداء توفير عامل حاسم في اختيار المستخدمين للعقد oracle (أو، مع ظهور من DONs، اختيارهم لـ DONs). ومن المرجح أن يكون هناك سجل أداء قوي ترتبط مع ارتفاع الإيرادات الجارية.18 18أحد الأسئلة البحثية المهمة التي نعتزم معالجتها هو الكشف عن أحجام الخدمات المزيفة.الشكل 17: الإيرادات المكتسبة بواسطة Chainlink العقد على خلاصة بيانات واحدة (ETH-USD) خلال أسبوع تمثيلي في مارس 2021. • الوصول إلى البيانات: بينما قد تحصل oracles على العديد من نماذج البيانات من واجهات برمجة التطبيقات المفتوحة، قد تكون بعض أشكال البيانات أو بعض المصادر عالية الجودة متاحة فقط على أساس الاشتراك أو من خلال الاتفاقيات التعاقدية. امتياز الوصول إلى بعض يمكن أن تلعب مصادر البيانات دورًا في إنشاء تدفق ثابت للإيرادات. • مشاركة DON: مع ظهور DONs، ستأتي مجتمعات العقد معا لتقديم خدمات معينة. نتوقع أن يتم تضمين العديد من DONs المشغلين على أساس انتقائي، مع تحديد المشاركة في DONs ذات السمعة الطيبة باعتبارها مكانة متميزة في السوق تساعد على ضمان مصدر ثابت للدخل. • النشاط عبر الأنظمة الأساسية: قد يكون لدى بعض مشغلي العقد تواجد راسخ وسجلات تتبع الأداء في سياقات أخرى، على سبيل المثال، PoS validators أو موفري البيانات في سياقات غير blockchain. ويمكن لأدائها في هذه الأنظمة الأخرى (عندما تكون البيانات المتعلقة بها متاحة في شكل جدير بالثقة) أن يفيد التقييم من تاريخ أدائهم. وبالمثل، السلوك الخاطئ في شبكة Chainlink يمكن أن يعرض الإيرادات في هذه الأنظمة الأخرى للخطر عن طريق إبعاد المستخدمين، أي FFO يمكن أن تمتد عبر المنصات. 9.6.2 FFO المضاربة يشارك مشغلو العقد في شبكة Chainlink ليس فقط لتوليد الإيرادات منها العمليات، ولكن لخلق أنفسهم ووضعهم للاستفادة من الفرص الجديدة لإدارة الوظائف. بمعنى آخر، الإنفاق بواسطة oracle العقد في الشبكة أيضًا بيان إيجابي حول مستقبل DeFi وتطبيق العقود الذكية الأخرى المجالات بالإضافة إلى التطبيقات الناشئة غير blockchain لشبكات oracle. يكسب مشغلو العقد اليوم الرسوم المتاحة على شبكات Chainlink الحالية وفي وقت واحد تشبه هذه بشكل عام المراجعات المزيفة على مواقع الإنترنت، إلا أن المشكلة أسهل في oracle لأنه لدينا سجل نهائي حول ما إذا كانت البضائع، أي التقارير، قد تم طلبها أم لا يتم تسليمها - على عكس، على سبيل المثال، السلع المادية المطلوبة في المتاجر عبر الإنترنت. وبعبارة أخرى، في oracle الإعداد، يمكن التحقق من صحة الأداء، حتى لو لم يكن ذلك ممكنًا.بناء سمعة وتاريخ أداء وخبرة تشغيلية من شأنها أن تحدد مكانتك لهم بشكل مفيد لكسب الرسوم المتاحة في الشبكات المستقبلية (المشروطة، بالطبع، على السلوك الصادق). العقد العاملة في النظام البيئي Chainlink اليوم سوف تفعل ذلك يتمتع Sense بميزة على القادمين الجدد في كسب الرسوم كرسوم إضافية Chainlink تصبح الخدمات متاحة. وتنطبق هذه الميزة على المشغلين الجدد، فضلاً عن شركات التكنولوجيا ذات السمعة الطيبة؛ على سبيل المثال، T-Systems، وهو نظام تقليدي مزود التكنولوجيا (شركة تابعة لشركة Deutsche Telekom)، وKraken، وهي شركة مركزية كبيرة التبادل، أسسوا تواجدًا مبكرًا في النظام البيئي Chainlink [28، 143]. يمكن اعتبار مثل هذه المشاركة بواسطة العقد oracle في الفرص المستقبلية بحد ذاتها كنوع من FFO المضاربة، وبالتالي يشكل شكلاً من أشكال الحصة في Chainlink شبكة. 9.6.3 السمعة الخارجية يمكن لمعهد التمويل الدولي كما وصفناه أن يعمل في شبكة بأسماء مستعارة تمامًا المشغلين، أي دون الكشف عن الأشخاص أو كيانات العالم الحقيقي المعنية. ومع ذلك، فإن أحد العوامل المهمة المحتملة لاختيار المستخدم لمقدمي الخدمات هو عامل خارجي السمعة. ونعني بالسمعة الخارجية تصور الجدارة بالثقة المرتبط بهويات العالم الحقيقي، وليس الأسماء المستعارة. مخاطر السمعة المرتبطة يمكن النظر إلى هويات العالم الحقيقي على أنها شكل من أشكال الحوافز الضمنية. نحن ننظر إلى السمعة من خلال عدسة معهد التمويل الدولي، أي بالمعنى الاقتصادي المشفر، كوسيلة للتأسيس النشاط عبر الأنظمة الأساسية الذي يمكن دمجه في تقديرات FFO. فائدة استخدام السمعة الخارجية كعامل في تقديرات FFO، على العكس من ذلك إلى الارتباط بأسماء مستعارة، هو أن السمعة الخارجية تربط الأداء ليس فقط بـ الأنشطة الحالية للمشغل، ولكن أيضًا للأنشطة المستقبلية. إذا، على سبيل المثال، سمعة سيئة عندما يتعلق الأمر بفرد ما، فإنه يمكن أن يلوث مشاريع ذلك الشخص المستقبلية. وبعبارة أخرى، يمكن للسمعة الخارجية أن تستحوذ على نطاق أوسع من FFO مقارنة بالأسماء المستعارة سجلات الأداء، وتأثير المخالفات المرتبطة بشخص أو المنشأة من الصعب الهروب من الشركة أكثر من تلك المرتبطة بعملية اسم مستعار. Chainlink متوافق مع تقنيات الهوية اللامركزية (القسم 4.3). يمكن أن يقدم الدعم لاستخدام السمعة الخارجية في معهد التمويل الدولي. مثل هذه التقنيات يمكن التحقق من صحة وبالتالي المساعدة في ضمان صحة العالم الحقيقي المؤكد للمشغلين الهويات.19 9.6.4 افتح تحليلات IIF يهدف معهد التمويل الدولي، كما أشرنا، إلى توفير بيانات وأدوات موثوقة مفتوحة المصدر تحليلات الحوافز الضمنية. الهدف هو تمكين مقدمي الخدمات داخل المجتمع لتطوير تحليلات مصممة خصيصًا لتلبية احتياجات تقييم المخاطر لأجزاء مختلفة من المنظمة Chainlink قاعدة المستخدمين. 19. يمكن أيضًا لأوراق اعتماد الهوية اللامركزية، عند الرغبة، تزيين الأسماء المستعارة بأسماء مستعارة تم التحقق من صحتها. معلومات تكميلية. على سبيل المثال، يمكن لمشغل العقدة من حيث المبدأ استخدام بيانات الاعتماد هذه من أجل إثبات أنها إحدى شركات Fortune 500، دون الكشف عن أي منها.كمية كبيرة من البيانات التاريخية المتعلقة بإيرادات العقد وأدائها يوجد في سلسلة في شكل عالي الثقة وغير قابل للتغيير. ولكن هدفنا هو توفير البيانات الممكنة الأكثر شمولاً، بما في ذلك البيانات المتعلقة بالسلوكيات التي لا يمكن رؤيتها إلا من الخارج سلسلة، مثل التقارير خارج السلسلة (OCR) أو نشاط DON. من المحتمل أن تكون مثل هذه البيانات تكون ضخمة. الطريقة الأفضل لتخزينها والتأكد من سلامتها، أي حمايتها من نعتقد أن التلاعب سيتم بمساعدة DONs، باستخدام التقنيات التي تمت مناقشتها في القسم 3.3. بعض الحوافز تصلح لأشكال القياس المباشرة، مثل staking الودائع و FFO الأساسية. أما البعض الآخر، مثل المضاربة الأجنبية المباشرة والسمعة، فيصعب القيام بها قياس بطريقة موضوعية، ولكننا نعتقد أن أشكال البيانات الداعمة، بما في ذلك النمو التاريخي للنظام البيئي Chainlink، ومقاييس السمعة على وسائل التواصل الاجتماعي، وما إلى ذلك، يمكن أن تدعم نماذج تحليلات IIF حتى بالنسبة لهذه العناصر التي يصعب تحديدها كميًا. يمكننا أن نتخيل أن DONs مخصصة تنشأ خصيصًا للمراقبة والتحقق من الصحة تسجيل البيانات المتعلقة بسجلات الأداء خارج السلسلة للعقد، بالإضافة إلى البيانات الأخرى المستخدمة في IIF، مثل معلومات الهوية التي تم التحقق من صحتها. يمكن أن توفر DONs بيانات IIF موحدة وعالية الثقة لأي موفري تحليلات يخدمون مجتمع Chainlink. وسيوفرون أيضًا سجلاً ذهبيًا يقدم ادعاءات موفري التحليلات يمكن التحقق منها بشكل مستقل من قبل المجتمع. 9.7 تجميع كل ذلك معًا: حوافز مشغل العقدة تجميع مناقشاتنا أعلاه حول الحوافز الصريحة والضمنية لمشغلي العقد يوفر نظرة شاملة للطرق التي يشارك بها مشغلو العقد ويستفيدون منها شبكة Chainlink. كدليل مفاهيمي، يمكننا التعبير عن إجمالي الأصول المعنية من خلال Chainlink معين مشغل العقدة $S في شكل تقريبي ومنمق على النحو التالي: \(S ≈\)D + \(F + \)FS + $R، حيث: • $D هو إجمالي الحصص المودعة بشكل صريح عبر جميع الشبكات التي فيها يشارك المشغل؛ • $F هو صافي القيمة الحالية لمجموع جميع FFO عبر جميع الشبكات التي يشارك فيها المشغل؛ • $FS هو صافي القيمة الحالية لـ FFO المضاربة للمشغل. و • $R هو قيمة سمعة المشغل خارج النظام البيئي Chainlink التي قد تتعرض للخطر بسبب سوء السلوك الذي تم تحديده في عقدها oracle. على الرغم من أنها مفاهيمية إلى حد كبير، إلا أن هذه المساواة التقريبية تظهر بشكل مفيد أن هناك العديد من العوامل الاقتصادية التي تفضل الأداء عالي الموثوقية بواسطة Chainlink العقد. كل هذه العوامل بخلاف $D موجودة في شبكات Chainlink اليوم.9.8 الدورة الفاضلة للأمن الاقتصادي مزيج من التأثير الخطي الفائق staking مع تمثيل مدفوعات الرسوم حيث أن فرصة الرسوم المستقبلية (FFO) في معهد التمويل الدولي يمكن أن تؤدي إلى ما نسميه الدورة الحميدة للأمن الاقتصادي في شبكة oracle. ويمكن اعتبار هذا نوعا من الاقتصاد من الحجم. ومع ارتفاع المبلغ الإجمالي المضمون بواسطة شبكة معينة، يزداد مقدار هناك حاجة إلى حصة إضافية لإضافة مقدار ثابت من انخفاض الأمن الاقتصادي كما هو الحال متوسط التكلفة لكل مستخدم. لذلك، يعد انضمام المستخدم أرخص من حيث الرسوم شبكة موجودة بالفعل من تحقيق نفس الزيادة في الشبكة الاقتصادية الأمن عن طريق إنشاء شبكة جديدة. الأهم من ذلك، أن إضافة كل مستخدم جديد يخفض تكلفة الخدمة لجميع المستخدمين السابقين لتلك الشبكة. بالنظر إلى هيكل رسوم معين (على سبيل المثال، معدل عائد معين على المبلغ المراهن عليه)، إذا زاد إجمالي الرسوم التي تكسبها الشبكة، فإن هذا يحفز تدفق الرسوم الإضافية حصة في الشبكة لتأمينها بمعدل أعلى. على وجه التحديد، إذا كانت الحصة الإجمالية يتم تغطية العقدة الفردية التي قد تعقد في النظام، ثم عند دفع الرسوم الجديدة أدخل النظام، ورفع FFO، وسوف يزيد عدد العقد n. شكرا ل فائقة الخطية staking تأثير تصميم نظام الحوافز لدينا، والأمن الاقتصادي ل سوف يرتفع النظام بشكل أسرع من n، على سبيل المثال، كما هو الحال مع n2 في الآلية التي نرسمها في القسم 9.4. ونتيجة لذلك، فإن متوسط تكلفة الأمن الاقتصادي - أي مقدار المساهمة في الحصة دولار من الأمن الاقتصادي – سينخفض. وبالتالي يمكن للشبكة فرض رسوم على مستخدميها رسوم أقل. بافتراض أن الطلب على خدمات oracle مرن (انظر، على سبيل المثال، [31] للحصول على ملخص) تفسيرا)، سيرتفع الطلب، مما يولد رسوما إضافية و FFO. ونوضح هذه النقطة بالمثال التالي. مثال 5. منذ الأمن الاقتصادي لشبكة oracle مع حافزنا المخطط هو \(dn2 for stake \)dn، الأمن الاقتصادي الذي ساهم به دولار من الحصة هو n، وبالتالي متوسط تكلفة كل دولار من الأمن الاقتصادي، أي مقدار الحصة المساهمة في دولار واحد من الأمن الاقتصادي — هو 1/ن. لننظر إلى شبكة تتكون فيها الحوافز الاقتصادية بالكامل من FFO، ذات حد أقصى عند \(d ≤\)10K لكل عقدة. لنفترض أن الشبكة بها n = 3 عقد. ثم متوسط التكلفة ويبلغ كل دولار من الأمن الاقتصادي حوالي 0.33 دولار. لنفترض أن إجمالي FFO للشبكة يرتفع فوق \(30K (e.g., to \)31K). نظرا الحد الأقصى لكل عقدة FFO، تنمو الشبكة إلى (على الأقل) n = 4. الآن متوسط التكلفة وينخفض كل دولار من الأمن الاقتصادي إلى نحو 0.25 دولار. نوضح الدورة الحميدة الكاملة للأمن الاقتصادي في شبكات oracle بشكل تخطيطي في الشكل 18. ونؤكد على أن الدورة الحميدة للأمن الاقتصادي تنبع من التأثير من المستخدمين تجميع رسومهم. إن FFO الجماعي الخاص بهم هو الذي يعمل لصالح الأكبر أحجام الشبكات وبالتالي قدر أكبر من الأمن الجماعي. ونلاحظ أيضا أن الدورة الفاضلة يعمل الأمن الاقتصادي لصالح DON لتحقيق الاستدامة المالية. مرة واحدة تم إنشاؤها، DONs التي تلبي احتياجات المستخدم يجب أن تنمو إلى ما هو أبعد من النقطة التي عندها تتجاوز الإيرادات من الرسوم تكاليف التشغيل لـ oracle العقد.

الشكل 18: رسم تخطيطي للدورة الفاضلة لـ Chainlink staking. ارتفاع في رسوم المستخدم تؤدي المدفوعات إلى شبكة oracle 1⃝ إلى نموها، مما يؤدي إلى نمو اقتصادها الأمن 2⃝. يحقق هذا النمو الخطي الفائق وفورات الحجم في شبكات Chainlink 3⃝. ويعني على وجه التحديد انخفاضًا في متوسط تكلفة الأمن الاقتصادي، أي: الأمن الاقتصادي لكل دولار الناشئ عن دفع الرسوم أو مصادر الحصص الأخرى يزيد. تؤدي التكاليف المنخفضة، التي يتم تمريرها إلى المستخدمين، إلى تحفيز الطلب المتزايد على oracle الخدمات 4⃝. 9.9 عوامل إضافية تقود نمو الشبكة مع استمرار توسع النظام البيئي Chainlink، فإننا نؤمن بجاذبيته للمستخدمين والأهمية مع تسارع البنية التحتية لاقتصاد blockchain. القيمة التي توفرها شبكات oracle هي قيمة خطية للغاية، مما يعني أنها تنمو بشكل أسرعمن حجم الشبكات نفسها. وهذا النمو في القيمة مستمد من كليهما وفورات الحجم - زيادة كفاءة التكلفة لكل مستخدم مع زيادة حجم الخدمة - و تأثيرات الشبكة - زيادة في فائدة الشبكة حيث يتبنى المستخدمون DONs على نطاق أوسع. مع استمرار smart contracts الحاليين في رؤية المزيد من القيمة المضمونة والجديدة تمامًا smart contract أصبحت التطبيقات ممكنة من خلال المزيد من الخدمات اللامركزية، المجموع يجب أن ينمو استخدام الرسوم الإجمالية المدفوعة إلى DONs. زيادة مجمعات الرسوم في تحويلها إلى وسائل وحوافز لخلق المزيد من الخدمات اللامركزية، مما أدى إلى دورة حميدة. هذه الدورة الفاضلة تحل مشكلة الدجاجة والبيضة الحرجة المشكلة في النظام البيئي smart contract المختلط: ميزات smart contract المبتكرة غالبًا ما تتطلب خدمات لا مركزية غير موجودة بعد (على سبيل المثال، أسواق DeFi الجديدة غالبًا تتطلب خلاصات بيانات جديدة) ولكنها تحتاج إلى طلب اقتصادي كافٍ لكي تظهر إلى الوجود. إن تجميع الرسوم من خلال smart contracts المختلفة لـ DONs الحالية سيشير إلى الطلب على خدمات لامركزية إضافية من قاعدة مستخدمين متنامية، مما أدى إلى إنشائها بواسطة DONs والتمكين المستمر لـ smart contracts الهجين الجديد والمتنوع. باختصار، نحن نعتقد أن النمو في أمن الشبكات مدفوع بالفاضلة الدورات في آلية Chainlink staking تمثل أنماطًا أكبر من النمو يمكن لشبكة Chainlink أن تساعد في تحقيق اقتصاد متصل بالسلسلة من أجل اللامركزية الخدمات.

خاتمة

في هذه الورقة، وضعنا رؤية لتطور Chainlink. الموضوع الرئيسي في هذه الرؤية تكمن قدرة الشبكات oracle على توفير نطاق أوسع بكثير من الخدمات smart contracts أكثر من مجرد تسليم البيانات. باستخدام DONs كأساس للخدمات اللامركزية في المستقبل، سيهدف Chainlink إلى توفير وظائف oracle عالية الأداء ومعززة للسرية. ستوفر شبكات oracle الخاصة بها تقليلًا قويًا للثقة من خلال مجموعة من آليات الاقتصاد المشفر المبدئية مثل staking و حواجز حماية مصممة بعناية وإنفاذ على مستوى الخدمة يعتمد على السلاسل الرئيسية. سيساعد DONs أيضًا أنظمة الطبقة الثانية على فرض سياسات طلب مرنة وعادلة على المعاملات، بالإضافة إلى تقليل تكاليف الغاز للمعاملات الموجهة بواسطة الذاكرة. مجتمعة، كل هذه القدرات تقود في اتجاه نظام ذكي هجين آمن وغني بالوظائف العقود. ستؤدي مرونة DONs إلى تحسين خدمات Chainlink الحالية وتؤدي إلى العديد من الميزات والتطبيقات الإضافية smart contract. ومن بين هذه سلسة الاتصال بمجموعة واسعة من الأنظمة خارج السلسلة، وإنشاء الهوية اللامركزية من البيانات الحالية، والقنوات ذات الأولوية للمساعدة في ضمان تسليم البنية التحتية الحيوية في الوقت المناسب المعاملات وأدوات الحفاظ على السرية DeFi. إن الرؤية التي طرحناها هنا طموحة. وعلى المدى القصير، نسعى إلى التمكين عقود هجينة لتحقيق أهداف بعيدة عن متناول smart contracts اليوم، بينما على المدى الطويل، نهدف إلى تحقيق طبقة معدنية لا مركزية. لحسن الحظ يمكننا الرسم على أدوات وأفكار جديدة، تتراوح من خوارزميات الإجماع إلى إثبات المعرفة الصفرية الأنظمة - التي يتطورها المجتمع كثمرة لأبحاث سريعة التطور.

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