Chainlink: Mạng Oracle phi tập trung
خلاصة
في هذا المستند التقني، نوضح رؤية لتطور 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.
Tóm tắt
Trong báo cáo chính thức này, chúng tôi trình bày rõ tầm nhìn về sự phát triển của Chainlink ngoài quan niệm ban đầu trong báo cáo chính thức Chainlink ban đầu. Chúng tôi thấy trước vai trò ngày càng mở rộng của oracle mạng, một vai trò trong đó chúng bổ sung và nâng cao blockchain hiện có và mới bằng cách cung cấp tốc độ nhanh, đáng tin cậy và kết nối phổ quát và tính toán ngoài chuỗi đảm bảo tính bảo mật cho smart contracts. Nền tảng kế hoạch của chúng tôi là cái mà chúng tôi gọi là Mạng Oracle phi tập trung, hoặc Viết tắt là DONs. DON là mạng được duy trì bởi ủy ban Chainlink nút. Nó hỗ trợ bất kỳ chức năng oracle nào được chọn cho triển khai của ủy ban. Do đó DON hoạt động như một lớp trừu tượng mạnh mẽ, cung cấp giao diện cho smart contract cho các tài nguyên ngoài chuỗi mở rộng và có chất lượng cao tài nguyên điện toán ngoài chuỗi hiệu quả nhưng được phân cấp trong chính DON. Với DON làm bàn đạp, Chainlink có kế hoạch tập trung vào những tiến bộ trong bảy lĩnh vực chính: • smart contract kết hợp: Cung cấp một khuôn khổ chung, mạnh mẽ để tăng cường các khả năng smart contract hiện có bằng cách soạn thảo an toàn trên chuỗi và tài nguyên điện toán ngoài chuỗi thành cái mà chúng tôi gọi là smart contract lai. • Loại bỏ sự phức tạp: Trình bày cho các nhà phát triển và người dùng những cách đơn giản chức năng loại bỏ sự cần thiết phải làm quen với cơ bản phức tạp các giao thức và ranh giới hệ thống. • Mở rộng quy mô: Đảm bảo rằng các dịch vụ oracle đạt được độ trễ và thông lượng được yêu cầu bởi các hệ thống phi tập trung hiệu suất cao. • Tính bảo mật: Kích hoạt các hệ thống thế hệ tiếp theo kết hợp blockchains' tính minh bạch vốn có với các biện pháp bảo vệ bí mật mới mạnh mẽ cho các thông tin nhạy cảm dữ liệu. • Tính công bằng trong giao dịch: Hỗ trợ sắp xếp trình tự giao dịch theo cách công bằng cho người dùng cuối và ngăn chặn các cuộc tấn công chạy trước và các cuộc tấn công khác bằng cách bot và thợ mỏ bóc lột. • Giảm thiểu sự tin cậy: Tạo ra một lớp hỗ trợ có độ tin cậy cao cho smart contracts và các hệ thống phụ thuộc oracle khác bằng phương pháp phân cấp, neo chặt ở mức độ bảo mật cao blockchains, mật mã kỹ thuật và đảm bảo kinh tế mật mã. • Bảo mật dựa trên khuyến khích (kinh tế tiền điện tử): Các cơ chế thiết kế nghiêm ngặt và triển khai mạnh mẽ nhằm đảm bảo các nút trong DON có động lực kinh tế mạnh mẽ để hành xử một cách đáng tin cậy và chính xác, ngay cả khi đối mặt với các đối thủ có nguồn lực tốt. Chúng tôi giới thiệu những cải tiến sơ bộ và đang diễn ra của cộng đồng Chainlink trong mỗi lĩnh vực này, cung cấp một bức tranh về sự mở rộng và ngày càng tăng các khả năng mạnh mẽ được lên kế hoạch cho mạng 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.
Giới thiệu
Blockchain oracle ngày nay thường được xem là dịch vụ phi tập trung với một mục tiêu: để chuyển tiếp dữ liệu từ các tài nguyên ngoài chuỗi tới blockchains. Tuy nhiên, đó là một bước ngắn, từ chuyển tiếp dữ liệu đến tính toán, lưu trữ hoặc truyền dữ liệu hai chiều. Quan sát này biện minh cho khái niệm rộng hơn nhiều về chức năng của oracles. Vì vậy, quá thực hiện các yêu cầu dịch vụ ngày càng tăng của smart contract và ngày càng đa dạng công nghệ dựa trên mạng oracle. Tóm lại, oracle có thể và sẽ cần là một giao diện có mục đích chung, hai chiều, hỗ trợ tính toán giữa và giữa các hệ thống trên chuỗi và ngoài chuỗi. Vai trò của Oracles trong hệ sinh thái blockchain là nâng cao hiệu suất, chức năng và khả năng tương tác của smart contract để chúng có thể mang lại các mô hình tin cậy mới và tính minh bạch cho nhiều ngành công nghiệp. Sự chuyển đổi này sẽ diễn ra thông qua việc mở rộng việc sử dụng smart contract kết hợp, hợp nhất Thuộc tính đặc biệt của blockchains với khả năng độc đáo của các hệ thống ngoài chuỗi chẳng hạn như oracle mạng và do đó đạt được phạm vi tiếp cận và sức mạnh lớn hơn nhiều so với các hệ thống trên chuỗi trong sự cô lập. Trong sách trắng này, chúng tôi trình bày rõ tầm nhìn về cái mà chúng tôi gọi là Chainlink 2.0, một sự phát triển của Chainlink ngoài quan niệm ban đầu trong sách trắng ban đầu Chainlink [98]. Chúng tôi thấy trước vai trò ngày càng mở rộng của các mạng oracle, trong đó chúng bổ sung và nâng cao blockchain hiện có và mới bằng cách cung cấp kết nối và tính toán phổ quát nhanh chóng, đáng tin cậy và bảo mật cho kết hợp smart contracts. Chúng tôi tin rằng oracle mạng thậm chí sẽ phát triển để trở thành tiện ích để xuất dữ liệu cấp blockchain có tính toàn vẹn cao sang các hệ thống ngoài blockchain hệ sinh thái. Ngày nay, các nút Chainlink do một nhóm thực thể đa dạng điều hành kết hợp với nhau trong các mạng oracle để chuyển tiếp dữ liệu tới smart contract trong cái được gọi là báo cáo. Chúng ta có thể xem như vậy oracle nút như một ủy ban tương tự như ủy ban trong sự đồng thuận cổ điển blockchain [72], nhưng với mục tiêu hỗ trợ blockchain hiện có thay vì cung cấp chức năng độc lập. Với các chức năng ngẫu nhiên có thể xác minh (VRF) và Báo cáo Off-Chain (OCR), Chainlink đã phát triển theo hướng khung và cơ sở hạ tầng có mục đích chung để cung cấp tài nguyên tính toán mà smart contract yêu cầu cho chức năng nâng cao. Nền tảng kế hoạch của chúng tôi cho Chainlink 2.0 là cái mà chúng tôi gọi là Oracle phi tập trung Mạng hoặc gọi tắt là DON. Kể từ khi chúng tôi giới thiệu thuật ngữ “oracle mạng” trong bản gốc Chainlink sách trắng [98], oracle đã phát triển chức năng phong phú hơn bao giờ hết và bề rộng của ứng dụng. Trong bài viết này, chúng tôi đưa ra một định nghĩa mới cho thuật ngữ này theo tới tầm nhìn tương lai của chúng tôi về hệ sinh thái Chainlink. Trong chế độ xem này, DON là một mạng được duy trì bởi một ủy ban gồm Chainlink nút. Bắt nguồn từ một giao thức đồng thuận, nó hỗ trợ bất kỳ chức năng oracle nào trong phạm vi không giới hạn được chọn để triển khai bởi ủy ban. Do đó, DON hoạt động như một lớp trừu tượng blockchain, cung cấp giao diện tới các tài nguyên ngoài chuỗi cho cả smart contract và các hệ thống khác. Nó cũng cung cấp truy cập vào các tài nguyên điện toán ngoài chuỗi phi tập trung nhưng hiệu quả cao. Nói chung, a DON hỗ trợ các hoạt động trên chuỗi chính. Mục tiêu của nó là cho phép an toàn và linh hoạtble lai smart contracts, kết hợp tính toán trên chuỗi và ngoài chuỗi với kết nối với các tài nguyên bên ngoài. Chúng tôi nhấn mạnh rằng ngay cả khi sử dụng ủy ban trong DONs, chính Chainlink vốn dĩ vẫn không được phép. DON đóng vai trò là nền tảng của quyền không cần cấp phép khung trong đó các nút có thể kết hợp với nhau để triển khai các mạng oracle tùy chỉnh với chế độ riêng của họ để bao gồm nút, có thể được phép hoặc không được phép. Với DON làm nền tảng, chúng tôi dự định tập trung vào Chainlink 2.0 dựa trên những tiến bộ trong bảy các lĩnh vực chính: smart contract kết hợp, loại bỏ sự phức tạp, mở rộng quy mô, tính bảo mật, tính công bằng trong trật tự cho các giao dịch, giảm thiểu sự tin cậy và bảo mật (kinh tế tiền điện tử) dựa trên khuyến khích. Trong phần giới thiệu bài viết này, chúng tôi trình bày tổng quan về Phi tập trung Oracle Networks trong Phần 1.1 và sau đó là bảy lĩnh vực đổi mới chính của chúng tôi trong Phần 1.2. Chúng tôi mô tả cách tổ chức phần còn lại của bài viết này trong Phần 1.3. 1.1 Mạng Oracle phi tập trung Mạng Oracle phi tập trung được thiết kế để nâng cao và mở rộng khả năng trong số smart contract trên mục tiêu blockchain hoặc chuỗi chính thông qua các chức năng không có sẵn nguyên bản. Họ làm như vậy bằng cách cung cấp ba nguồn lực cơ bản được tìm thấy trong Hệ thống máy tính: mạng, lưu trữ và tính toán. DON nhằm mục đích cung cấp những tài nguyên này có đặc tính bảo mật, toàn vẹn và sẵn có mạnh mẽ,1 như cũng như trách nhiệm giải trình. DON được thành lập bởi ủy ban của các nút oracle hợp tác để thực hiện một mục tiêu cụ thể việc làm hoặc chọn thiết lập mối quan hệ lâu dài để cung cấp dịch vụ lâu dài tới khách hàng. DON được thiết kế theo cách blockchain bất khả tri. Họ hứa sẽ phục vụ như một công cụ mạnh mẽ và linh hoạt dành cho các nhà phát triển ứng dụng để tạo ra sự hỗ trợ ngoài chuỗi cho smart contract của họ trên bất kỳ chuỗi chính nào được hỗ trợ. Hai loại chức năng nhận ra khả năng của DON: thực thi và bộ điều hợp. Tệp thực thi là các chương trình chạy liên tục và theo cách phi tập trung trên DON. Mặc dù chúng không trực tiếp lưu trữ tài sản trên chuỗi chính nhưng chúng có những lợi ích quan trọng, bao gồm hiệu suất cao và khả năng thực hiện bảo mật. tính toán. Các tệp thực thi chạy tự động trên DON và thực hiện xác định hoạt động. Chúng hoạt động cùng với các bộ điều hợp liên kết DON với các tài nguyên bên ngoài và có thể được gọi bởi các tệp thực thi. Bộ điều hợp, như chúng tôi hình dung cho DON, là một tổng quát về bộ điều hợp bên ngoài trong Chainlink ngày hôm nay. Trong khi các bộ điều hợp hiện có thường chỉ lấy dữ liệu từ các nguồn dữ liệu, bộ điều hợp có thể hoạt động hai chiều; trong DONs, họ có thể tận dụng thêm khả năng tính toán chung của các nút DON để đạt được các tính năng bổ sung, chẳng hạn như mã hóa báo cáo để sử dụng bảo vệ quyền riêng tư bằng cách một tệp thực thi. Để cung cấp ý nghĩa về hoạt động cơ bản của DON, Hình 1 cho thấy một cách khái niệm cách một DON có thể được sử dụng để gửi báo cáo tới blockchain và do đó đạt được chức năng oracle truyền thống, hiện có. Tuy nhiên, DON có thể cung cấp nhiều tính năng bổ sung 1“Bộ ba CIA” về bảo mật thông tin [123, tr. 26, §2.3.5].Mạng hiện có của Chainlink. Ví dụ, trong cấu trúc chung của Hình 1, tệp thực thi có thể ghi lại dữ liệu giá tài sản được tìm nạp trên DON, sử dụng dữ liệu đó để tính toán, ví dụ: trung bình kéo dài cho các báo cáo của nó. Hình 1: Hình minh họa dưới dạng ví dụ về cách Mạng Oracle phi tập trung có thể nhận ra chức năng oracle cơ bản, tức là chuyển tiếp dữ liệu ngoài chuỗi sang hợp đồng. Một thực thi sử dụng bộ điều hợp để tìm nạp dữ liệu ngoài chuỗi mà nó tính toán, gửi đầu ra qua một bộ chuyển đổi khác tới mục tiêu blockchain. (Bộ điều hợp được khởi tạo bằng mã trong DON, được biểu thị bằng các hộp nhỏ màu xanh; mũi tên chỉ hướng của luồng dữ liệu cho việc này ví dụ cụ thể.) Ngoài ra, tệp thực thi có thể đọc và ghi vào cục bộ DON lưu trữ để giữ trạng thái và/hoặc liên lạc với các tệp thực thi khác. Kết nối mạng, tính toán và lưu trữ linh hoạt trong DON giây, tất cả đều được trình bày ở đây, cho phép một loạt tính năng mới ứng dụng. Lợi ích chính của DON là khả năng khởi động các dịch vụ blockchain mới. DONs là phương tiện giúp các mạng oracle hiện có có thể nhanh chóng triển khai các ứng dụng dịch vụ điều đó ngày nay đòi hỏi phải tạo ra các mạng lưới được xây dựng có mục đích. Chúng tôi đưa ra một số ví dụ về các ứng dụng như vậy trong Phần 4. Trong Phần 3, chúng tôi cung cấp thêm chi tiết về DONs, mô tả khả năng của họ trong về giao diện mà họ trình bày cho nhà phát triển và người dùng. 1.2 Bảy mục tiêu thiết kế chính Ở đây chúng tôi xem xét ngắn gọn bảy trọng tâm chính được liệt kê ở trên về sự phát triển của Chainlink, cụ thể là:Lai smart contracts: Trọng tâm trong tầm nhìn của chúng tôi đối với Chainlink là ý tưởng về sự an toàn kết hợp các thành phần trên chuỗi và ngoài chuỗi trong smart contract giây. Chúng tôi đề cập đến hợp đồng hiện thực hóa ý tưởng này dưới dạng hợp đồng kết hợp smart contract hoặc hợp đồng kết hợp.2 Blockchain đang và sẽ tiếp tục đóng hai vai trò quan trọng trong dịch vụ phi tập trung hệ sinh thái: Cả hai đều là nơi thể hiện quyền sở hữu tiền điện tử và những mỏ neo vững chắc cho các dịch vụ phi tập trung. Do đó, các hợp đồng thông minh phải được thể hiện hoặc thực thi trên chuỗi, nhưng khả năng trên chuỗi của chúng bị hạn chế nghiêm trọng. hoàn toàn Mã hợp đồng trên chuỗi chậm, đắt tiền và thiếu chính xác, không thể hưởng lợi từ thế giới thực dữ liệu và nhiều chức năng vốn không thể thực hiện được trên chuỗi, bao gồm nhiều hình thức tính toán bí mật khác nhau, tạo ra tính bảo mật (giả) ngẫu nhiên chống lại thao tác khai thác / validator, v.v. Do đó, để smart contract phát huy hết tiềm năng của mình, cần phải có smart contracts được cấu trúc gồm hai phần: phần trên chuỗi (mà chúng tôi thường ký hiệu là SC) và một phần ngoài chuỗi, một phần thực thi chạy trên DON (mà chúng tôi thường biểu thị bằng thực thi). Mục tiêu là đạt được sự kết hợp an toàn của chức năng trên chuỗi với sự đa dạng của các dịch vụ ngoài chuỗi mà DON hướng tới cung cấp. Cùng nhau, hai phần tạo nên một hợp đồng lai. Chúng tôi trình bày ý tưởng này một cách khái niệm trong Hình 2. Ngày nay, Chainlink các dịch vụ3 như nguồn cấp dữ liệu và VRF đang bật nhưng không thể thực hiện được smart contract ứng dụng, từ DeFi đến NFT được tạo công bằng cho đến bảo hiểm phi tập trung, là những bước đầu tiên hướng tới một khuôn khổ tổng quát hơn. Là dịch vụ Chainlink mở rộng và phát triển hiệu quả hơn theo tầm nhìn của chúng tôi trong sách trắng này sức mạnh của hệ thống smart contract trên tất cả blockchains. Sáu trọng tâm chính khác của chúng tôi trong sách trắng này có thể được coi là hoạt động trong dịch vụ đầu tiên, bao quát một trong các hợp đồng kết hợp. Những trọng tâm này liên quan đến việc loại bỏ những gì có thể nhìn thấy sự phức tạp từ các hợp đồng kết hợp, tạo ra các dịch vụ ngoài chuỗi bổ sung cho phép xây dựng các hợp đồng kết hợp có năng lực cao hơn bao giờ hết, và trong trường hợp giảm thiểu lòng tin, củng cố các đặc tính bảo mật đạt được bằng các hợp đồng kết hợp. Chúng tôi để lại ý tưởng hợp đồng kết hợp tiềm ẩn trong phần lớn bài viết, nhưng bất kỳ sự kết hợp nào của Logic MAINCHAIN có DON có thể được xem là hợp đồng kết hợp. Trừu tượng hóa sự phức tạp: DON được thiết kế để tận dụng cơ chế phi tập trung hệ thống dễ dàng cho các nhà phát triển và người dùng bằng cách loại bỏ bộ máy thường phức tạp đằng sau mảng dịch vụ mạnh mẽ và linh hoạt của DONs. Dịch vụ Chainlink hiện có đã có tính năng này rồi. Ví dụ: nguồn cấp dữ liệu trong Chainlink ngày nay trình bày các giao diện onchain không yêu cầu nhà phát triển phải quan tâm đến chi tiết cấp độ giao thức, chẳng hạn như phương tiện mà OCR thực thi báo cáo đồng thuận giữa một 2Ý tưởng về thành phần hợp đồng trên chuỗi/ngoài chuỗi đã xuất hiện trước đây ở nhiều quốc gia bị ràng buộc khác nhau. các biểu mẫu, ví dụ: hệ thống lớp 2, blockchains [80] dựa trên TEE, v.v. Mục tiêu của chúng tôi là hỗ trợ và khái quát hóa những cách tiếp cận này và đảm bảo rằng chúng có thể bao gồm quyền truy cập dữ liệu ngoài chuỗi và khóa khác oracle dịch vụ. Các dịch vụ 3Chainlink bao gồm nhiều dịch vụ và chức năng phi tập trung có sẵn thông qua mạng lưới. Chúng được cung cấp bởi nhiều nhà khai thác nút được tạo thành các mạng oracle khác nhau khắp hệ sinh thái.Hình 2: Hình khái niệm mô tả thành phần hợp đồng trên chuỗi/ngoài chuỗi. A lai smart contract 3⃝bao gồm hai thành phần bổ sung: một trên chuỗi thành phần SC 1⃝, cư trú trên blockchain và người thực thi thành phần ngoài chuỗi 2⃝đó thực thi trên DON. DON cũng đóng vai trò là cầu nối giữa hai thành phần như kết nối hợp đồng lai với các tài nguyên ngoài chuỗi như dịch vụ web, các dịch vụ khác blockchains, lưu trữ phi tập trung, v.v. tập hợp các nút phi tập trung. DON tiến thêm một bước nữa theo nghĩa là chúng mở rộng phạm vi dịch vụ mà Chainlink có thể cung cấp cho nhà phát triển một lớp trừu tượng với đi kèm các giao diện được sắp xếp hợp lý cho các dịch vụ cấp cao. Chúng tôi trình bày một số ví dụ ứng dụng trong Phần 4 làm nổi bật cách tiếp cận này. Ví dụ: chúng tôi hình dung các doanh nghiệp sử dụng DON như một dạng phần mềm trung gian an toàn để kết nối các hệ thống cũ của họ với blockchains. (Xem Phần 4.2.) Việc sử dụng DON này giúp loại bỏ sự phức tạp của động lực chung blockchain (phí, tổ chức lại, v.v.). Nó cũng trừu tượng hóa các tính năng của blockchain cụ thể, từ đó cho phép doanh nghiệp kết nối các hệ thống hiện có của họ với một loạt các hệ thống blockchain ngày càng mở rộng mà không cần nhu cầu về chuyên môn chuyên môn trong các hệ thống này hoặc nói chung hơn là phát triển hệ thống phi tập trung. Cuối cùng, tham vọng của chúng tôi là nâng cao mức độ trừu tượng mà Chainlink đạt được đến mức triển khai những gì chúng tôi gọi là một siêu dữ liệu phi tập trung. Một lớp như vậy sẽ loại bỏ sự khác biệt trên chuỗi/ngoài chuỗi đối với tất cả các tầng lớp nhà phát triển và người dùng DApps, cho phép tạo và sử dụng liền mạch các dịch vụ phi tập trung.Để đơn giản hóa quá trình phát triển, các nhà phát triển có thể chỉ định chức năng DApp trong siêu dữ liệu dưới dạng một ứng dụng ảo trong mô hình máy thống nhất. Họ có thể sau đó sử dụng trình biên dịch siêu dữ liệu phi tập trung để tự động khởi tạo DApp như một tập hợp các chức năng phi tập trung tương tác trải dài blockchains, DONs và dịch vụ bên ngoài. (Một trong những dịch vụ bên ngoài này có thể là hệ thống doanh nghiệp, làm cho siêu lớp trở nên hữu ích cho các ứng dụng liên quan đến hệ thống doanh nghiệp cũ.) quá trình biên dịch giống như cách các trình biên dịch và bộ công cụ phát triển phần mềm (SDK) hiện đại hỗ trợ các lập trình viên tổng quát trong việc sử dụng toàn bộ tiềm năng của phần cứng không đồng nhất kiến trúc bao gồm CPU có mục đích chung và phần cứng chuyên dụng như GPU, máy gia tốc học máy hoặc các khu vực đáng tin cậy. Hình 3 trình bày ý tưởng này ở mức độ khái niệm. smart contract lai là bước đầu tiên trên con đường hướng tới tầm nhìn này và tới một khái niệm mà chúng tôi gọi là hợp đồng meta. Hợp đồng meta là các ứng dụng được mã hóa trên cơ sở phi tập trung metalayer và hoàn toàn bao gồm logic trên chuỗi (smart contracts), cũng như tính toán và kết nối ngoài chuỗi giữa các blockchain khác nhau và chuỗi ngoài hiện có dịch vụ. Do nhu cầu hỗ trợ ngôn ngữ và trình biên dịch, các mô hình bảo mật mới và Tuy nhiên, sự hài hòa về mặt khái niệm và kỹ thuật của các công nghệ khác nhau của một siêu dữ liệu phi tập trung thực sự là một mục tiêu đầy tham vọng mà chúng tôi mong muốn trong một thời gian dài chân trời thời gian. Tuy nhiên, đây là một mô hình lý tưởng hữu ích cần ghi nhớ khi đọc bài viết này, không được trình bày chi tiết ở đây, nhưng là điều chúng tôi dự định tập trung vào trong công việc tương lai của mình. Chainlink. Chia tỷ lệ: Mục tiêu có tầm quan trọng vượt trội trong các thiết kế đang phát triển của chúng tôi là cho phép Chainlink mạng để đáp ứng nhu cầu mở rộng quy mô ngày càng tăng của hệ sinh thái blockchain. Với tình trạng tắc nghẽn mạng đang trở thành một vấn đề tái diễn ở các nền tảng không được phép hiện có blockchains [86], các thiết kế mới và hiệu quả hơn blockchain sắp được đưa vào sử dụng, ví dụ: [103, 120, 203], cũng như các công nghệ chia tỷ lệ lớp 2 bổ sung, ví dụ: [5, 12, 121, 141, 169, 186, 187]. Các dịch vụ của Oracle phải đạt được độ trễ và thông lượng đáp ứng nhu cầu về hiệu suất của các hệ thống này đồng thời giảm thiểu phí trên chuỗi (ví dụ: chi phí gas) cho người vận hành hợp đồng cũng như người dùng thông thường. Với DONs, Chainlink chức năng nhằm mục đích tiến xa hơn và mang lại hiệu suất đủ cao cho các hệ thống thuần túy dựa trên web. DON nhận được phần lớn hiệu suất đạt được từ việc sử dụng các giao thức đồng thuận nhanh, dựa trên ủy ban hoặc không được phép mà họ kết hợp với blockchains họ hỗ trợ. Chúng tôi mong đợi nhiều DON với cấu hình khác nhau sẽ chạy song song; các DApp và người dùng khác nhau có thể điều hướng sự đánh đổi trong các lựa chọn đồng thuận cơ bản theo yêu cầu ứng dụng của họ. DONs có thể được xem dưới dạng công nghệ lớp 2. Chúng tôi kỳ vọng rằng trong số các dịch vụ khác, DONs sẽ hỗ trợ Khung thực thi giao dịch (TEF), khung này tạo điều kiện tích hợp hiệu quả DON và do đó oracle với các hiệu suất cao khác hệ thống lớp 2—ví dụ: rollups, các hệ thống kết hợp các giao dịch ngoài chuỗi để đạt được cải tiến hiệu suất. Chúng tôi giới thiệu TEF ở Phần 6.
Hình 3: Hình vẽ khái niệm cho thấy sự hiện thực hóa lý tưởng của một siêu dữ liệu phi tập trung. cho dễ phát triển, nhà phát triển chỉ định DApp, được đánh dấu bằng màu hồng, là một ứng dụng ảo ứng dụng trong mô hình máy thống nhất. Trình biên dịch siêu lớp phi tập trung sẽ tự động tạo ra các chức năng tương tác tương ứng: smart contracts (ký hiệu là bởi SC), logic (được biểu thị bằng exec) trên DONs, bộ điều hợp kết nối với các dịch vụ bên ngoài mục tiêu, v.v., như được biểu thị bằng phần đánh dấu màu vàng. Hình 4 thể hiện một cách khái niệm cách DON cải thiện tỷ lệ blockchain (smart contract) bằng cách tập trung giao dịch và xử lý báo cáo ngoại tuyến oracle, thay vì trên chuỗi. Sự thay đổi trong vị trí tính toán chính này làm giảm độ trễ giao dịch và phí trong khi thúc đẩy thông lượng giao dịch. Tính bảo mật: Chuỗi khối cung cấp tính minh bạch chưa từng có cho smart contract và các ứng dụng mà chúng hiện thực hóa. Nhưng có một sự căng thẳng cơ bản giữa tính minh bạch và tính bảo mật. Ví dụ, ngày nay, giao dịch trao đổi phi tập trung của người dùngHình 4: Hình khái niệm cho thấy Mạng Oracle phi tập trung cải thiện chia tỷ lệ blockchain được kích hoạt smart contract giây. Hình A ⃝hiển thị oracle thông thường kiến trúc. Giao dịch được gửi trực tiếp tới blockchain, cũng như báo cáo oracle. Do đó blockchain được đánh dấu màu vàng là vị trí chính để xử lý giao dịch. Hình B⃝cho thấy việc sử dụng DON để hỗ trợ các hợp đồng trên blockchain. Một DON thực thi xử lý các giao dịch cùng với dữ liệu từ các hệ thống bên ngoài và chuyển tiếp kết quả—ví dụ: giao dịch theo nhóm hoặc thay đổi trạng thái hợp đồng do tác động của giao dịch—đối với blockchain. Do đó, DON, được đánh dấu bằng màu vàng, là thông tin chính địa điểm xử lý giao dịch. các hành động được ghi lại trên chuỗi, giúp dễ dàng theo dõi hành vi trao đổi, nhưng cũng làm cho các giao dịch tài chính của người dùng được hiển thị công khai. Tương tự, dữ liệu được chuyển tiếp tới thiết bị thông minh hợp đồng vẫn còn trong chuỗi. Điều này làm cho dữ liệu đó có thể kiểm tra được một cách thuận tiện, nhưng hoạt động như không khuyến khích các nhà cung cấp dữ liệu muốn cung cấp smart contract thông tin nhạy cảm hoặc dữ liệu độc quyền. Chúng tôi tin rằng mạng oracle sẽ đóng vai trò then chốt trong việc thúc đẩy thế hệ tiếp theo các hệ thống kết hợp tính minh bạch vốn có của blockchains với các biện pháp bảo vệ bí mật mới. Trong bài viết này, chúng tôi chỉ ra cách họ sẽ làm như vậy bằng cách sử dụng ba phương pháp chính: • Bộ điều hợp bảo mật: Hai công nghệ được triển khai theo kế hoạch trong mạng của Chainlink, DECO [234] và Town Crier [233], hãy bật các nút oracle để truy xuất dữ liệu từ các hệ thống ngoài chuỗi theo cách bảo vệ dữ liệu và quyền riêng tư của người dùng tính bảo mật. Chúng sẽ đóng vai trò quan trọng trong việc thiết kế bộ điều hợp cho DONs. (Xem Phần 3.6.2 để biết chi tiết về hai công nghệ này.) • Tính toán bí mật: DONs có thể đơn giản che giấu tính toán của chúng khỏi việc dựa vào blockchains. Bằng cách sử dụng môi trường tính toán an toàn của nhiều bên và/hoặc môi trường thực thi đáng tin cậy, cũng có thể có tính bảo mật mạnh mẽ hơn trong đó các nút DON tính toán dữ liệu mà bản thân họ không có khả năng hiển thị.
• Hỗ trợ các hệ thống lớp 2 bí mật: TEF được thiết kế để hỗ trợ nhiều hệ thống lớp 2 khác nhau, nhiều hệ thống trong số đó sử dụng bằng chứng không có kiến thức để cung cấp các hình thức bảo mật giao dịch khác nhau. Chúng tôi thảo luận về các phương pháp này trong Phần 3 (với các chi tiết bổ sung trong Phần 6, Phụ lục B.1 và Phụ lục B.2). Hình 5 trình bày quan điểm khái niệm về cách dữ liệu nhạy cảm có thể truyền từ các nguồn bên ngoài đến smart contract bằng các bộ điều hợp bảo toàn bí mật và tính toán bí mật trong DON. Hình 5: Sơ đồ khái niệm về các hoạt động bảo mật trong DON trên dữ liệu nhạy cảm (được đánh dấu màu vàng). Dữ liệu nguồn nhạy cảm (vòng tròn đen) trên web máy chủ được trích xuất tới DON bằng cách sử dụng bộ điều hợp bảo mật (dòng màu xanh lam, mũi tên đôi). DON nhận dữ liệu dẫn xuất (vòng tròn rỗng) từ các bộ điều hợp này— kết quả của việc áp dụng một chức năng hoặc, ví dụ: chia sẻ bí mật, đối với nguồn nhạy cảm dữ liệu. Tệp thực thi trên DON có thể áp dụng tính toán bí mật cho dữ liệu dẫn xuất để tạo một báo cáo (vòng tròn kép), báo cáo này sẽ gửi qua bộ chuyển đổi tới blockchain. Chúng tôi tin rằng các công cụ mạnh mẽ để xử lý dữ liệu bí mật sẽ mở ra toàn bộ phạm vi ứng dụng. Trong số này có tài chính phi tập trung (và tập trung) tư nhân, danh tính phi tập trung, cho vay theo chuỗi dựa trên tín dụng, v.v. các quy trình nhận biết khách hàng và công nhận thân thiện với người dùng, như chúng tôi thảo luận trong Phần 4. Tính công bằng trong giao dịch: Thiết kế blockchain ngày nay có hơi bẩn một chút bí mật mở: Chúng được tập trung nhất thời. Người khai thác và validator có thể yêu cầu chuyểnhành động theo cách họ chọn. Lệnh giao dịch cũng có thể bị người dùng thao túng như một chức năng của phí mạng mà họ phải trả (ví dụ: giá gas ở Ethereum) và đối với một số phạm vi bằng cách tận dụng các kết nối mạng nhanh. Sự thao túng như vậy có thể, đối với Ví dụ: sử dụng hình thức chạy trước, trong đó tác nhân chiến lược như thợ mỏ quan sát giao dịch của người dùng và chèn giao dịch khai thác của chính nó vào giao dịch trước đó vị trí trong cùng một khối—đánh cắp tiền của người dùng một cách hiệu quả bằng cách tận dụng kiến thức nâng cao về giao dịch của người dùng. Ví dụ: bot có thể đặt lệnh mua trước của người dùng. Sau đó nó có thể tận dụng sự tăng giá tài sản do giao dịch của người dùng. Chạy trước bởi một số bot gây hại cho người dùng thông thường—tương tự như tần số cao giao dịch trên Phố Wall—đã phổ biến và được ghi chép rõ ràng [90], cũng như có liên quan các cuộc tấn công như chạy ngược [159] và bắt chước giao dịch tự động [195]. Các đề xuất nhằm hệ thống hóa việc khai thác đơn hàng của thợ mỏ thậm chí còn xuất hiện gần đây [110]. Các công nghệ lớp 2 như rollup không giải quyết được vấn đề mà chỉ tái tập trung hóa đặt hàng, đặt nó vào tay thực thể tạo ra rollup. Một trong những mục tiêu của chúng tôi là giới thiệu vào Chainlink một dịch vụ có tên là Sắp xếp theo thứ tự hợp lý Dịch vụ (FSS) [137]. FSS giúp smart contract nhà thiết kế đảm bảo thứ tự công bằng cho sản phẩm của họ giao dịch và tránh các cuộc tấn công chạy trước, chạy sau và các cuộc tấn công có liên quan vào giao dịch của người dùng cũng như các loại giao dịch khác, chẳng hạn như truyền báo cáo oracle. FSS cho phép DON triển khai các ý tưởng như khái niệm nghiêm ngặt, tạm thời về trật tự công bằng được giới thiệu trong [144]. Là một lợi ích ngẫu nhiên, FSS cũng có thể hạ thấp mạng của người dùng. phí (ví dụ: chi phí gas). Tóm lại, trong FSS, các giao dịch đi qua DON, thay vì truyền trực tiếp đến mục tiêu smart contract. DON yêu cầu giao dịch rồi chuyển tiếp chúng vào hợp đồng. Hình 6: Ví dụ về lợi ích của FSS. Hình A ⃝cho thấy cách một thợ mỏ khai thác nó quyền tập trung để đặt lệnh giao dịch, có thể hoán đổi một cặp giao dịch: giao dịch 1⃝ đến trước 2⃝, nhưng thay vào đó, người khai thác sẽ sắp xếp nó sau 2⃝. Ngược lại, Hình B⃝cho thấy cách DON phân quyền quy trình đặt hàng giữa các nút DON. Nếu số đại biểu các nút trung thực nhận được 1⃝trước 2⃝, FSS khiến 1⃝xuất hiện trước 2⃝trên chuỗi— ngăn chặn việc sắp xếp lại thứ tự của thợ mỏ bằng cách đính kèm các số thứ tự có thể thực thi theo hợp đồng. Hình 6 so sánh việc khai thác tiêu chuẩn với FSS. Nó cho thấy cách khai thác tiêu chuẩn,quá trình đặt hàng giao dịch được tập trung vào người khai thác và do đó phải tuân theo thao tác, chẳng hạn như sắp xếp lại một cặp giao dịch liên quan đến thời điểm chúng đến lần. Ngược lại, trong FSS, quy trình được phân cấp giữa các nút DON. Giả sử một nhóm các nút trung thực, FSS giúp thực thi các chính sách như sắp xếp thứ tự thời gian của giao dịch, giảm cơ hội thao túng của thợ mỏ và các thực thể khác. Ngoài ra, do người dùng không cần phải cạnh tranh để được ưu đãi đặt hàng dựa trên giá gas, họ có thể trả giá xăng tương đối thấp (trong khi các giao dịch từ DON có thể được thực hiện theo đợt để tiết kiệm gas). Giảm thiểu sự tin cậy: Mục đích chung của chúng tôi khi thiết kế DON là tạo điều kiện thuận lợi cho lớp hỗ trợ đáng tin cậy cho smart contract và các hệ thống phụ thuộc oracle khác bằng phương pháp phân cấp, công cụ mật mã và đảm bảo kinh tế mật mã. Bản thân DON đã được phân cấp và người dùng có thể chọn từ bất kỳ DON nào có sẵn hỗ trợ chuỗi chính mà họ muốn vận hành hoặc sinh ra thêm DONs với ủy ban của các nút mà họ tin tưởng. Tuy nhiên, đối với một số ứng dụng, đặc biệt là smart contracts, Chainlink người dùng có thể ưu tiên mô hình tin cậy coi chuỗi chính được DON hỗ trợ là đáng tin cậy hơn hơn chính DON. Đối với những người dùng như vậy, chúng tôi đã có hoặc có kế hoạch kết hợp vào kiến trúc của mạng Chainlink một số cơ chế cho phép hợp đồng trên chuỗi chính để tăng cường đảm bảo an ninh do DONs cung cấp, trong khi tại đồng thời cũng thực thi các biện pháp bảo vệ chống lại khả năng nguồn dữ liệu bị hỏng chẳng hạn như máy chủ web mà DON lấy dữ liệu từ đó. Chúng tôi mô tả các cơ chế này trong Phần 7. Chúng thuộc năm tiêu đề chính: • Xác thực nguồn dữ liệu: Công cụ cho phép nhà cung cấp dữ liệu ký điện tử dữ liệu của họ và do đó tăng cường chuỗi hành trình sản phẩm giữa nguồn gốc và hợp đồng dựa vào. • DON báo cáo thiểu số: Cờ được phát hành bởi một tập hợp con thiểu số của DON nút quan sát thấy sự sai trái của đa số trong DON. • Đường ray bảo vệ: Logic trên chuỗi chính phát hiện các điều kiện bất thường và tạm dừng hoặc tạm dừng thực hiện hợp đồng (hoặc đưa ra các biện pháp khắc phục khác). • Quản trị giảm thiểu sự tin cậy: Sử dụng các bản cập nhật phát hành dần dần để hỗ trợ việc kiểm tra cộng đồng cũng như các biện pháp can thiệp khẩn cấp phi tập trung để nhanh chóng ứng phó với các lỗi hệ thống. • Xác thực thực thể phi tập trung: Sử dụng cơ sở hạ tầng khóa công khai (PKI) để xác định các thực thể trong mạng Chainlink. Hình 7 trình bày sơ đồ khái niệm về các mục tiêu giảm thiểu lòng tin của chúng tôi. Bảo mật dựa trên khuyến khích (kinh tế tiền điện tử): Phân quyền tạo báo cáo trên các nút oracle giúp đảm bảo tính bảo mật ngay cả khi một số nút bị hỏng.
Hình 7: Mô tả khái niệm về mục tiêu giảm thiểu sự tin cậy của Chainlink, đó là giảm thiểu nhu cầu của người dùng về hành vi chính xác của DON và các nguồn dữ liệu như web máy chủ. Điểm nổi bật màu vàng trong hình biểu thị các locus giảm thiểu độ tin cậy: DON và bộ máy chủ web cá nhân hoặc thiểu số. Điểm nổi bật màu hồng biểu thị các thành phần hệ thống có độ tin cậy cao theo giả định: hợp đồng trên blockchain và phần lớn của các máy chủ web, tức là các máy chủ web tổng hợp. Tuy nhiên, điều quan trọng không kém là đảm bảo rằng các nút có động cơ tài chính để hoạt động đúng đắn. Đặt cược, tức là yêu cầu các nút cung cấp tiền gửi LINK và cắt giảm (tịch thu) số tiền gửi này trong trường hợp có hành vi sai trái, sẽ đóng vai trò quan trọng trong Chainlink. Đây là một thiết kế khuyến khích quan trọng đã được sử dụng ở một số blockchain, ví dụ: [81, 103, 120, 204]. Tuy nhiên, việc đặt cược vào Chainlink trông rất khác so với staking ở chế độ độc lập blockchains. Đặt cược vào blockchain nhằm mục đích ngăn chặn các cuộc tấn công vào sự đồng thuận. Nó có một mục tiêu khác nhau trong Chainlink: đảm bảo gửi kịp thời các báo cáo chính xác oracle. Hệ thống staking được thiết kế tốt cho mạng oracle sẽ thực hiện các cuộc tấn công như hối lộ không có lợi cho đối thủ, ngay cả khi mục tiêu là smart contract có chỉ số cao giá trị tiền tệ. Trong bài viết này, chúng tôi trình bày cách tiếp cận chung với staking trong Chainlink bằng ba khóa đổi mới:1. Một mô hình đối nghịch mạnh mẽ bao gồm các cuộc tấn công bị bỏ qua trong cách tiếp cận. Một ví dụ là cái mà chúng tôi gọi là hối lộ tiềm năng. Đây là một hình thức hối lộ xác định nút nào nhận hối lộ trên cơ sở có điều kiện, ví dụ: đưa ra các khoản hối lộ được đảm bảo trước cho các nút mà cơ chế staking chọn tại ngẫu nhiên cho các vai trò cụ thể (chẳng hạn như kích hoạt việc xét xử báo cáo). 2. Tác động siêu tuyến tính staking, nghĩa là một cách không chính thức rằng để thành công, đối thủ phải có ngân sách $B lớn hơn tổng số tiền gửi của tất cả oracle nút. Chính xác hơn, chúng tôi muốn nói rằng đó là một hàm của n, \(B(n) ≫\)dn trong một mạng gồm n oracle nút, mỗi nút có số tiền gửi cố định $d (chính thức hơn, \(B(n) is asymptotically larger in n than \)dn). Hình 8 đưa ra một cái nhìn khái niệm về tài sản này. 3. Khung khuyến khích tiềm ẩn (IIF), một mô hình khuyến khích mà chúng tôi đã nghĩ ra để bao gồm các ưu đãi có thể đo lường được theo kinh nghiệm ngoài khoản tiền gửi rõ ràng staking tiền, bao gồm cả cơ hội tính phí trong tương lai của các nút. IIF mở rộng khái niệm về cổ phần ngoài tiền gửi nút rõ ràng. Hình 8: Sơ đồ khái niệm mô tả tỷ lệ siêu tuyến tính trong Chainlink staking. các hối lộ $B(n) mà đối thủ yêu cầu tăng nhanh hơn về n so với số tiền gửi tổng hợp $dn trong số tất cả các nút oracle. Chúng tôi cho thấy tác động của IIF và siêu tuyến tính staking cùng nhau tạo ra những gì chúng tôi gọi một chu kỳ an toàn kinh tế hiệu quả cho các mạng oracle. Khi người dùng mới vào
hệ thống, tăng thu nhập tiềm năng trong tương lai từ việc chạy các nút Chainlink, chi phí cận biên của an ninh kinh tế giảm đối với người sử dụng hiện tại và tương lai. Trong một chế độ cầu co giãn, chi phí giảm dần này sẽ khuyến khích thêm người dùng sử dụng mạng lưới, liên tục duy trì việc áp dụng trong một chu kỳ đạo đức đang diễn ra. Lưu ý: Mặc dù báo cáo chính thức này phác thảo các yếu tố quan trọng trong tầm nhìn của chúng tôi đối với sự phát triển của Chainlink nhưng nó không chính thức và bao gồm một số thông số kỹ thuật chi tiết. Chúng tôi dự định phát hành các tài liệu kỹ thuật tập trung vào các tính năng và phương pháp tiếp cận bổ sung khi chúng phát triển. Hơn nữa, điều quan trọng cần nhấn mạnh là nhiều yếu tố của tầm nhìn được trình bày ở đây (cải tiến quy mô, công nghệ bảo mật, FSS, v.v.) có thể và sẽ được triển khai ở dạng sơ bộ ngay cả trước khi DON nâng cao trở thành tính năng cơ bản của Chainlink. 1.3 Tổ chức của bài viết này Chúng tôi trình bày mô hình và ký hiệu bảo mật của mình trong Phần 2 và phác thảo Mô hình phi tập trung. API mạng Oracle trong Phần 3. Trong Phần 4, chúng tôi trình bày một số ví dụ về các ứng dụng mà DON cung cấp nền tảng triển khai hấp dẫn. Người đọc có thể tìm hiểu hầu hết các khái niệm chính của bài viết bằng cách đọc đến thời điểm này. Phần còn lại của bài viết có thêm chi tiết. Chúng tôi mô tả Trình tự hợp lý Dịch vụ (FSS) trong Phần 5 và Khung Thực thi Giao dịch (TEF) trong Phần 6. Chúng tôi mô tả cách tiếp cận của mình để giảm thiểu độ tin cậy trong Phần 7. Chúng tôi xem xét một số các yêu cầu triển khai DON quan trọng, cụ thể là triển khai tăng dần các tính năng, tư cách thành viên sổ cái động và trách nhiệm giải trình trong Phần 8. Cuối cùng, trong Phần 9, chúng tôi cung cấp tổng quan về cách tiếp cận đang phát triển của chúng tôi đối với thiết kế khuyến khích. Chúng tôi kết luận ở Phần 10. Để giúp những độc giả còn ít hiểu biết về các khái niệm trong bài viết này, chúng tôi cung cấp bảng chú giải thuật ngữ trong Phụ lục A. Chúng tôi trình bày chi tiết hơn về giao diện DON và chức năng trong Phụ lục B và trình bày một số bộ điều hợp mẫu trong Phụ lục C. Trong Phụ lục D, chúng tôi mô tả nguyên hàm mật mã cho nguồn dữ liệu được giảm thiểu độ tin cậy xác thực được gọi là chữ ký chức năng và giới thiệu một biến thể mới gọi là chữ ký chức năng rời rạc. Chúng tôi thảo luận về một số cân nhắc liên quan đến ủy ban lựa chọn cho DON trong Phụ lục 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 من خلال آليات تقليل الثقة في السلاسل الرئيسية التي يدعمونها.
Mô hình và mục tiêu bảo mật
Mạng Oracle phi tập trung là một hệ thống phân tán riêng biệt mà chúng tôi mong đợi sẽ ban đầu được thực hiện một cách thông thường—mặc dù không nhất thiết—bởi một ủy ban giao thức đồng thuận và được điều hành bởi một tập hợp các nút oracle. DON được thiết kế chủ yếu để tăng cường khả năng của smart contract trên chuỗi chính với báo cáo oracle và các dịch vụ khác, nhưng nó có thể cung cấp các dịch vụ hỗ trợ tương tự cho các hệ thống không phảiblockchain khác và do đó không cần phải liên kết với một chuỗi chính cụ thể.
Do đó, mô hình và các đặc tính mà chúng tôi xem xét phần lớn độc lập với việc sử dụng các ứng dụng cụ thể của DON. 2.1 Mô hình kiến trúc hiện tại Điều quan trọng cần nhấn mạnh là Chainlink ngày nay không phải là một dịch vụ nguyên khối mà là một khuôn khổ không cần cấp phép trong đó có thể khởi chạy các ứng dụng độc lập, khác biệt mạng gồm oracle nút [77]. Mạng có tập hợp các toán tử nút không đồng nhất và thiết kế. Họ cũng có thể khác nhau về loại dịch vụ họ cung cấp, có thể bao gồm, ví dụ: nguồn cấp dữ liệu, Bằng chứng dự trữ, tính ngẫu nhiên có thể kiểm chứng, v.v. Khác sự khác biệt có thể bao gồm mức độ phân cấp, quy mô của mạng về mặt giá trị bị khóa mà nó hỗ trợ và các tham số cấp dịch vụ khác nhau, chẳng hạn như tần số dữ liệu và độ chính xác. Mô hình không được phép của Chainlink khuyến khích sự phát triển của một hệ sinh thái trong đó các nhà cung cấp chuyên về các dịch vụ mà họ có thể cung cấp tốt nhất cho cộng đồng. Cái này mô hình có khả năng mang lại chi phí thấp hơn cho người dùng và chất lượng dịch vụ cao hơn mô hình yêu cầu tất cả các nút và mạng cung cấp đầy đủ các dịch vụ, một cách tiếp cận có thể dễ dàng chuyển sang áp dụng trên toàn hệ thống các dịch vụ đại diện cho ít nhất mẫu số chung của tài nguyên có sẵn cho các nút. Khi Chainlink phát triển theo hướng thiết kế dựa trên DON trong Chainlink 2.0, chúng tôi tiếp tục hỗ trợ mô hình của một khuôn khổ mở, không được phép, theo dõi mục tiêu của cung cấp cho người dùng nhiều lựa chọn dịch vụ mang lại kết quả phù hợp nhất trên toàn cầu với các yêu cầu ứng dụng cụ thể. 2.2 Giả định đồng thuận Chúng tôi sử dụng thuật ngữ Mạng Oracle phi tập trung để bao gồm đầy đủ chức năng của hệ thống oracle mà chúng tôi mô tả: cả cấu trúc dữ liệu mà các nút oracle duy trì và API cốt lõi được xếp chồng lên trên nó. Chúng tôi sử dụng thuật ngữ sổ cái (chữ thường), ký hiệu là L, để chỉ dữ liệu cơ bản cấu trúc được duy trì bởi DON và được sử dụng để hỗ trợ các dịch vụ cụ thể mà nó cung cấp. Chúng tôi nhấn mạnh rằng khung DON của chúng tôi không coi L là một hệ thống độc lập như a blockchain: Mục đích của nó là hỗ trợ blockchains và các hệ thống khác. Blockchain là, tất nhiên, có một cách để tạo ra một sổ cái đáng tin cậy, nhưng vẫn có những cách khác. Chúng tôi mong đợi DONs trong nhiều trường hợp để nhận ra sổ cái cơ bản của họ bằng cách sử dụng Byzantine Fault Tolerant (BFT) hệ thống có trước đáng kể các hệ thống blockchain như Bitcoin [174]. Chúng tôi sử dụng BFT-loại ký hiệu và thuộc tính xuyên suốt bài viết để thuận tiện, mặc dù chúng tôi nhấn mạnh rằng DONs có thể được thực hiện bằng cách sử dụng các giao thức đồng thuận không được phép. Về mặt khái niệm, sổ cái L là một bảng thông báo trên đó dữ liệu được sắp xếp tuyến tính. Nhìn chung, chúng tôi xem sổ cái có một số thuộc tính chính thường được gán cho blockchains [115]. Một sổ cái là: • Chỉ nối thêm: Dữ liệu sau khi được thêm vào sẽ không thể bị xóa hoặc sửa đổi.• Công khai: Bất kỳ ai cũng có thể đọc được nội dung nhất quán theo thời gian trong chế độ xem của tất cả người dùng.4 • Có sẵn: Sổ cái luôn có thể được người viết được ủy quyền viết và đọc bởi bất cứ ai một cách kịp thời. Các thuộc tính thay thế có thể có trong sổ cái cho DON khi được nhận ra bởi một ủy ban. Ví dụ: quyền truy cập ghi sổ cái có thể bị hạn chế đối với một số người dùng nhất định, vì có thể truy cập đọc đối với một số ứng dụng, tức là sổ cái không cần phải công khai như được xác định ở trên. Tương tự, các quy tắc sổ cái có thể cho phép sửa đổi hoặc biên tập lại dữ liệu. Chúng tôi không Tuy nhiên, hãy xem xét rõ ràng các biến thể như vậy trong bài viết này. Thiết kế mô-đun của DON có thể hỗ trợ bất kỳ loại BFT hiện đại nào các giao thức, ví dụ: Hotstuff[231]. Sự lựa chọn chính xác sẽ phụ thuộc vào các giả định về độ tin cậy và đặc điểm mạng giữa các nút oracle. Về nguyên tắc, DON có thể thay thế sử dụng blockchain không được phép có hiệu suất cao cho sổ cái của nó với vai trò hỗ trợ hệ thống lớp 2 hoặc blockchain có khả năng mở rộng tương đương. Tương tự, sự lai tạo cũng có thể xảy ra: Về nguyên tắc, DON có thể bao gồm các nút là validator trong một mạng hiện có blockchain, ví dụ: trong hệ thống Bằng chứng cổ phần trong đó các ủy ban được chọn để thực thi giao dịch, ví dụ: [8, 81, 120, 146, 204]. Chế độ hoạt động đặc biệt này đòi hỏi các nút hoạt động theo cách sử dụng kép, tức là hoạt động cả dưới dạng nút blockchain và DON nút. (Xem Phần 8.2 để thảo luận về các kỹ thuật nhằm đảm bảo tính liên tục trong việc thay đổi ủy ban và Phụ lục F về một số lưu ý khi lựa chọn ủy ban ngẫu nhiên.) Trong thực tế, trong thuật toán BFT hiện đại, các nút ký điện tử vào các thông báo trên sổ cái. Chúng ta giả sử để thuận tiện rằng L có một khóa công khai pkL liên quan và nội dung của nó được ký bởi khóa riêng tương ứng. Ký hiệu chung này áp dụng ngay cả khi dữ liệu trên L được ký bằng chữ ký ngưỡng.5 Chữ ký ngưỡng rất thuận tiện, vì chúng kích hoạt danh tính lâu dài cho DON ngay cả khi thay đổi tư cách thành viên trong các nút đang chạy nó. (Xem Phụ lục B.1.3.) Do đó, chúng tôi giả định rằng skL được chia sẻ bí mật theo cách ngưỡng (k, n) đối với một số tham số an toàn k, ví dụ: k = 2f + 1 và n = 3f + 1, trong đó f là số nút có khả năng bị lỗi. (Bằng cách chọn k ở đây theo cách này, chúng tôi đảm bảo rằng các nút bị lỗi không thể học skL cũng như không thể thực hiện việc từ chối dịch vụ cuộc tấn công ngăn chặn việc sử dụng nó.) Một thông báo trên L có dạng M = (m, z), trong đó m là một chuỗi và z là duy nhất số chỉ mục tuần tự. Nếu có thể, chúng ta viết tin nhắn dưới dạng m = ⟨MessageType : tải trọng⟩. Loại thông báo MessageType là cú pháp cho biết chức năng của một thông báo cụ thể. 4Trong trường hợp blockchain không có số cuối cùng nhận ra một sổ cái, sự không nhất quán thường bị loại trừ tránh xa bằng cách bỏ qua các khối không đủ sâu hoặc “cắt tỉa” [115]. 5Trong thực tế, một số cơ sở mã, ví dụ: LibraBFT [205], một biến thể của Hotstuff, hiện đã áp dụng đa chữ ký, thay vì chữ ký ngưỡng, giảm bớt độ phức tạp trong giao tiếp cho kỹ thuật đơn giản hơn. Với một số chi phí bổ sung, các nút oracle có thể thêm chữ ký ngưỡng vào tin nhắn được ghi vào L ngay cả khi giao thức đồng thuận được sử dụng cho L không sử dụng chúng.2.3 Ký hiệu Chúng ta biểu thị tập hợp n oracle nút chạy sổ cái bằng O = {Oi}n tôi = 1. Như vậy tập hợp các nút thường được gọi là một ủy ban. Để đơn giản, chúng ta giả sử rằng tập hợp oracle đang triển khai chức năng DON, tức là các dịch vụ trên L, giống hệt với duy trì L, nhưng chúng có thể khác biệt. Chúng ta đặt pki biểu thị khóa công khai của người chơi Oi và trượt khóa riêng tương ứng. Hầu hết các thuật toán BFT yêu cầu ít nhất n = 3f + 1 nút, trong đó f là số lượng các nút có khả năng bị lỗi; các nút còn lại là trung thực, theo nghĩa là chúng tuân theo giao thức chính xác như được chỉ định. Chúng tôi coi ủy ban O là trung thực nếu nó đáp ứng được điều này yêu cầu, tức là có nhiều hơn 2/3 số nút trung thực. Trừ khi có cách khác đã nêu, chúng tôi cho rằng O là trung thực (và là một mô hình tham nhũng tĩnh). Chúng tôi sử dụng pkO / skO có thể hoán đổi cho nhau bằng pkL / skL, tùy theo ngữ cảnh. Chúng ta đặt σ = Sigpk[m] biểu thị chữ ký trên thông báo m đối với pk, tức là sử dụng sk khóa riêng tương ứng. Đặt verify(pk, σ, m) →{false, true} biểu thị thuật toán xác minh chữ ký tương ứng. (Chúng tôi ngầm định việc tạo khóa trong suốt bài viết.) Chúng tôi sử dụng ký hiệu S để biểu thị nguồn dữ liệu và S để biểu thị toàn bộ nguồn nS trong một bối cảnh nhất định. Chúng tôi biểu thị bằng MAINCHAIN một hợp đồng thông minh được kích hoạt blockchain được hỗ trợ bởi DON. Chúng tôi sử dụng thuật ngữ hợp đồng dựa trên để biểu thị bất kỳ thông minh nào hợp đồng trên MAINCHAIN giao tiếp với DON và sử dụng ký hiệu SC để biểu thị một hợp đồng như vậy. Chúng tôi thường giả định rằng DON hỗ trợ một MAINCHAIN chuỗi chính duy nhất, mặc dù nó có thể hỗ trợ nhiều chuỗi như vậy, như chúng tôi trình bày trong các ví dụ ở Phần 4. A DON có thể và thường sẽ hỗ trợ nhiều hợp đồng dựa trên MAINCHAIN. (Như đã lưu ý ở trên, DON có thể hỗ trợ các dịch vụ không phải blockchain.) 2.4 Lưu ý về Mô hình Tin cậy Như đã lưu ý ở trên, DON có thể được xây dựng dựa trên các giao thức đồng thuận dựa trên ủy ban và chúng tôi mong đợi họ sẽ thường xuyên sử dụng các giao thức như vậy. Có nhiều lập luận mạnh mẽ cho rằng một trong hai lựa chọn thay thế, blockchain dựa trên ủy ban hoặc không được phép, cung cấp bảo mật mạnh hơn cái kia. Điều quan trọng là phải nhận ra rằng tính bảo mật của dựa trên ủy ban và không được phép hệ thống phi tập trung là không thể so sánh được. Thỏa hiệp PoW hoặc PoS blockchain thông qua tấn công 51% yêu cầu đối thủ phải có được phần lớn tài nguyên một cách nhất thời và có khả năng ẩn danh, chẳng hạn như bằng cách thuê nguồn điện hash trong hệ thống PoW. Như vậy các cuộc tấn công trong thực tế đã ảnh hưởng đến một số blockchains [200, 34]. Ngược lại, xâm phạm một hệ thống dựa trên ủy ban có nghĩa là làm hỏng một số ngưỡng (thường là một phần ba) các nút của nó, trong đó các nút có thể được biết đến công khai, có nguồn lực tốt, và các đơn vị đáng tin cậy. Mặt khác, các hệ thống dựa trên ủy ban (cũng như các hệ thống không cần cấp phép “kết hợp” hệ thống hỗ trợ các ủy ban) có thể hỗ trợ nhiều chức năng hơn so vớicác hệ thống phi nhiệm vụ. Điều này bao gồm khả năng duy trì các bí mật lâu dài, chẳng hạn như khóa ký và/hoặc mã hóa—một khả năng trong thiết kế của chúng tôi. Chúng tôi nhấn mạnh rằng DON về nguyên tắc có thể được xây dựng trên nền tảng dựa trên ủy ban hoặc giao thức đồng thuận không được phép và DON người triển khai cuối cùng có thể chọn áp dụng một trong hai cách tiếp cận. Củng cố các mô hình niềm tin: Tính năng chính của Chainlink ngày nay là khả năng người dùng chọn các nút dựa trên các bản ghi phi tập trung về lịch sử hiệu suất của chúng, như đã thảo luận ở Mục 3.6.4. Cơ chế staking và Khung khuyến khích ngầm định mà chúng tôi giới thiệu trong Phần 9 cùng nhau tạo thành một thiết kế cơ chế nghiêm ngặt và có phạm vi rộng khuôn khổ sẽ trao quyền cho người dùng khả năng mở rộng đáng kể để đánh giá tính bảo mật của DONs. Khung tương tự này cũng sẽ giúp chính DONs có thể thực hiện được để thực thi các yêu cầu bảo mật khác nhau trên các nút tham gia và đảm bảo hoạt động trong các mô hình niềm tin mạnh mẽ. Cũng có thể sử dụng các công cụ được mô tả trong bài viết này cho DON để thực thi các yêu cầu về mô hình tin cậy đặc biệt, chẳng hạn như tuân thủ các yêu cầu quy định. cho Ví dụ, bằng cách sử dụng các kỹ thuật được thảo luận trong Phần 4.3, các nút có thể đưa ra bằng chứng về các đặc điểm của nhà điều hành nút, ví dụ: lãnh thổ hoạt động, có thể được sử dụng để trợ giúp thực thi việc tuân thủ, ví dụ: Quy định chung về bảo vệ dữ liệu (GDPR) Điều 3 (“Phạm vi lãnh thổ”) [105]. Việc tuân thủ như vậy có thể là thách thức đối với gặp nhau trong các hệ thống phi tập trung [45]. Ngoài ra, trong Phần 7, chúng tôi thảo luận về kế hoạch tăng cường độ bền của DONs thông qua các cơ chế giảm thiểu niềm tin trên các chuỗi chính mà họ hỗ trợ.
واجهة شبكة أوراكل اللامركزية و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.
Giao diện mạng Oracle phi tập trung và Ca-
khả năng Ở đây chúng tôi phác thảo ngắn gọn các khả năng của DON theo cách đơn giản nhưng mạnh mẽ giao diện mà chúng được thiết kế để hiện thực hóa. Các ứng dụng trên DON bao gồm các tệp thực thi và bộ điều hợp. Một tệp thực thi là một chương trình có logic cốt lõi là chương trình xác định, tương tự như smart contract. Một tệp thực thi cũng có một số bộ khởi tạo đi kèm, các chương trình gọi mục nhập chỉ vào logic của tệp thực thi khi xảy ra các sự kiện được xác định trước—ví dụ: tại một số thời điểm nhất định (như công việc định kỳ), khi giá vượt qua một ngưỡng, v.v.—giống như Người giữ (xem Phần 3.6.3). Bộ điều hợp cung cấp giao diện cho các tài nguyên ngoài chuỗi và có thể được gọi bởi hoặc là bộ khởi tạo hoặc logic cốt lõi trong các tệp thực thi. Vì hành vi của họ có thể phụ thuộc vào điều đó của các tài nguyên bên ngoài, bộ khởi tạo và bộ điều hợp có thể hoạt động không mang tính xác định. Chúng tôi mô tả giao diện nhà phát triển DON cũng như chức năng của các tệp thực thi và bộ điều hợp theo ba tài nguyên thường được sử dụng để mô tả các hệ thống máy tính: mạng, tính toán và lưu trữ. Chúng tôi cung cấp một cái nhìn tổng quan ngắn gọn về mỗi trong số này các nguồn bên dưới và cung cấp thêm chi tiết trong Phụ lục B.
3.1 Mạng Bộ điều hợp là các giao diện mà qua đó các tệp thực thi chạy trên DON có thể gửi và nhận dữ liệu từ hệ thống off-DON. Bộ điều hợp có thể được xem như là sự khái quát hóa của các bộ chuyển đổi được sử dụng trong Chainlink hôm nay [20]. Bộ điều hợp có thể là hai chiều—tức là chúng không thể chỉ kéo mà còn đẩy dữ liệu từ DON tới máy chủ web. Họ cũng có thể tận dụng các giao thức phân tán cũng như chức năng mã hóa như bảo mật đa bên tính toán. Hình 9: Bộ điều hợp kết nối DON, ký hiệu là DON1, với nhiều loại tài nguyên khác nhau, bao gồm một DON khác, ký hiệu là DON2, blockchain (chuỗi chính) và của nó mempool, bộ nhớ ngoài, máy chủ web và thiết bị IoT (thông qua máy chủ web). Ví dụ về các tài nguyên bên ngoài mà bộ điều hợp có thể được tạo được hiển thị trong Hình 9. Chúng bao gồm: • Chuỗi khối: Bộ chuyển đổi có thể xác định cách gửi giao dịch tới blockchain và cách đọc các khối, giao dịch riêng lẻ hoặc trạng thái khác từ nó. Một bộ chuyển đổi cũng có thể được xác định cho mempool của blockchain. (Xem Phần 3.5.) • Máy chủ web: Bộ điều hợp có thể xác định API thông qua đó dữ liệu có thể được truy xuất từ các máy chủ web, bao gồm cả các hệ thống cũ không được điều chỉnh đặc biệt cho giao tiếp với DONs. Các bộ điều hợp như vậy cũng có thể bao gồm các API để gửi dữ liệu tới những máy chủ như vậy. Các máy chủ web mà DON kết nối có thể đóng vai trò là cổng tới các tài nguyên bổ sung, chẳng hạn như các thiết bị Internet-of-Things (IoT).• Bộ nhớ ngoài: Bộ điều hợp có thể xác định các phương thức đọc và ghi vào bộ lưu trữ dịch vụ bên ngoài DON, chẳng hạn như hệ thống tệp phi tập trung [40, 188] hoặc đám mây lưu trữ. • Các DON khác: Bộ điều hợp có thể truy xuất và truyền dữ liệu giữa DON. Chúng tôi hy vọng rằng việc triển khai ban đầu DON sẽ bao gồm một tập hợp các khối xây dựng bộ điều hợp cho các tài nguyên bên ngoài được sử dụng phổ biến như vậy và sẽ tiếp tục cho phép DON-cụ thể bộ điều hợp sẽ được xuất bản bởi nút DON. Khi smart contract nhà phát triển viết bộ điều hợp hôm nay, chúng tôi hy vọng rằng họ sẽ xây dựng các bộ điều hợp mạnh mẽ hơn nữa bằng cách sử dụng công cụ nâng cao này chức năng. Chúng tôi hy vọng rằng cuối cùng người dùng sẽ có thể tạo các bộ điều hợp mới theo cách cách không được phép. Một số bộ điều hợp phải được xây dựng theo cách đảm bảo tính ổn định và sẵn có của các tài nguyên bên ngoài do DON kiểm soát. Ví dụ: lưu trữ đám mây có thể yêu cầu duy trì tài khoản dịch vụ đám mây. Ngoài ra, DON có thể thực hiện quản lý phi tập trung các khóa riêng thay mặt cho người dùng (như trong, ví dụ: [160]) và/hoặc thực thi. Do đó, DON có khả năng kiểm soát các tài nguyên, chẳng hạn như tiền điện tử, có thể được sử dụng, ví dụ: để gửi giao dịch trên mục tiêu blockchain. Xem Phụ lục B.1 để biết thêm chi tiết về bộ điều hợp DON, như Phụ lục C cho một số bộ điều hợp bộ điều hợp ví dụ. 3.2 tính toán Tệp thực thi là đơn vị mã cơ bản trên DON. Một tệp thực thi là một cặp exec = (lôgic, khởi tạo). Ở đây, logic là một chương trình xác định với một số mục được chỉ định các điểm (logic1, logic2, . . . , logicℓ) và init là tập hợp các điểm khởi tạo tương ứng (init1, init2,..., inite). Để đảm bảo khả năng kiểm tra đầy đủ của DON, logic của tệp thực thi sử dụng sổ cái cơ bản L cho tất cả các đầu vào và đầu ra. Vì vậy, ví dụ, bất kỳ bộ chuyển đổi nào dữ liệu phục vụ làm đầu vào cho một tệp thực thi phải được lưu trữ trước tiên trên L. Người khởi xướng: Những người khởi tạo trong Chainlink hôm nay thực hiện các công việc phụ thuộc vào sự kiện trên Chainlink nút [21]. Các bộ khởi tạo trong DONs hoạt động theo cách tương tự. Tuy nhiên, trình khởi tạo DON được liên kết cụ thể với một tệp thực thi. Người khởi xướng có thể phụ thuộc trên một sự kiện hoặc trạng thái bên ngoài, vào thời điểm hiện tại hoặc trên một vị từ trên trạng thái DON. Với sự phụ thuộc vào các sự kiện, những người khởi xướng tất nhiên có thể hành xử không mang tính xác định. (tất nhiên là có thể có bộ điều hợp). Trình khởi tạo có thể thực thi trong các nút DON riêng lẻ và do đó không cần phải dựa vào bộ chuyển đổi. (Xem ví dụ 1 bên dưới.) Trình khởi tạo là một tính năng quan trọng để phân biệt các tệp thực thi với smart contracts. Bởi vì một tập tin thực thi có thể chạy để phản hồi lại một bộ khởi tạo nên nó có thể hoạt động một cách hiệu quả. một cách tự chủ, tất nhiên bằng cách mở rộng, một hợp đồng kết hợp có thể kết hợp với tệp thực thi. Một dạng người khởi xướng hiện nay là Chainlink Người giữ, cung cấp giao dịchdịch vụ tự động hóa, kích hoạt smart contract thực thi—chẳng hạn như thanh lý các khoản vay không được thế chấp và thực hiện các giao dịch theo lệnh giới hạn—dựa trên báo cáo oracle. Thuận tiện, những người khởi xướng trong DON cũng có thể được xem như một cách chỉ định các thỏa thuận dịch vụ áp dụng cho một tệp thực thi, vì chúng xác định các trường hợp theo mà DON phải gọi nó. Ví dụ sau minh họa cách hoạt động của các trình khởi tạo trong một tệp thực thi: Ví dụ 1 (Nguồn cấp giá kích hoạt sai lệch). smart contract SC có thể yêu cầu mới dữ liệu nguồn cấp giá (xem Phần 3.6.3) bất cứ khi nào có thay đổi đáng kể, ví dụ: 1%, trong tỷ giá hối đoái giữa một cặp tài sản, ví dụ: ETH-USD. Giá nhạy cảm với biến động nguồn cấp dữ liệu được hỗ trợ trong Chainlink ngày hôm nay nhưng sẽ mang tính hướng dẫn để xem chúng có thể hoạt động như thế nào được thực hiện trên DON bằng nguồn cấp dữ liệu thực thi. Nguồn cấp dữ liệu thực thi duy trì giá ETH-USD gần đây nhất r trên L, trong dạng một chuỗi gồm ⟨NewPrice : j, r⟩entries, trong đó j là chỉ số tăng theo mỗi lần cập nhật giá. Trình khởi tạo init1 khiến mỗi nút Oi theo dõi giá ETH-USD hiện tại cho sai lệch ít nhất 1% so với giá lưu trữ gần đây nhất r với chỉ số j. Khi phát hiện ra sự sai lệch như vậy, Oi viết quan điểm hiện tại của mình về giá mới vào L bằng cách sử dụng mục nhập có dạng ⟨PriceView : i, j + 1, ri⟩. Trình khởi tạo thứ hai init2 kích hoạt khi có ít nhất k mục nhập PriceView như vậy với giá mới các giá trị cho chỉ mục j + 1 được tạo bởi các nút riêng biệt đã tích lũy trên L. Sau đó, init2 gọi một điểm vào logic2 để tính trung bình ρ của k giá trị xem giá hợp lệ, mới đầu tiên và ghi một giá trị mới ⟨NewPrice : j + 1, ρ⟩to L . (Về mặt hoạt động, các nút có thể thay phiên nhau làm người viết được chỉ định.) Trình khởi tạo thứ ba init3 theo dõi các mục NewPrice trên L. Bất cứ khi nào có báo cáo mới ⟨NewPrice : j, r⟩xuất hiện ở đó, nó gọi một điểm vào logic3 đẩy (j, r) tới SC sử dụng một bộ chuyển đổi. Như chúng tôi đã lưu ý, một tệp thực thi có khả năng tương tự như smart contract. Tuy nhiên, ngoài hiệu suất cao hơn, nó khác với hợp đồng chuỗi chính điển hình theo hai cách thiết yếu: 1. Tính bảo mật: Một tệp thực thi có thể thực hiện tính toán bí mật, tức là một chương trình bí mật có thể xử lý các đầu vào văn bản rõ ràng hoặc một chương trình đã xuất bản có thể xử lý dữ liệu đầu vào bí mật hoặc kết hợp cả hai. Trong một mô hình đơn giản, dữ liệu bí mật có thể được truy cập bởi các nút DON, nút này che giấu các kết quả trung gian và chỉ tiết lộ các giá trị được xử lý và khử trùng vào MAINCHAIN. Cũng có thể che giấu dữ liệu nhạy cảm khỏi chính DON: DON nhằm hỗ trợ các phương pháp tiếp cận như dưới dạng tính toán nhiều bên, ví dụ: [42, 157] và môi trường thực thi đáng tin cậy (TEE) [84, 133, 152, 229] cho mục đích này.6 6Bằng tiện ích mở rộng, cũng có thể giữ bí mật các tệp thực thi đối với các nút DON, mặc dù ngày nay điều này chỉ thực tế đối với các tệp thực thi không tầm thường sử dụng TEE.2. Vai trò hỗ trợ: Một tệp thực thi có nghĩa là hỗ trợ smart contract trên main chuỗi, thay vì thay thế chúng. Một tệp thực thi có một số hạn chế mà một smart contract không: (a) Mô hình tin cậy: Một tệp thực thi hoạt động trong mô hình tin cậy được xác định bởi DON: Việc thực thi chính xác dựa vào hành vi trung thực của O. (A main Tuy nhiên, chuỗi có thể cung cấp một số biện pháp bảo vệ chống lại sự cố DON, như được thảo luận trong Phần 7.3.) (b) Quyền truy cập tài sản: DON có thể kiểm soát tài khoản trên blockchain—và do đó kiểm soát tài sản trên đó thông qua một bộ chuyển đổi. Nhưng DON không thể có thẩm quyền đại diện cho các tài sản được tạo trên chuỗi chính, ví dụ: Ether hoặc ERC20 tokens, vì chuỗi gốc của họ duy trì hồ sơ có thẩm quyền về quyền sở hữu của họ. (c) Vòng đời: DON có thể được thiết lập có chủ ý với thời gian tồn tại giới hạn, vì được xác định bởi các thỏa thuận cấp độ dịch vụ trên chuỗi giữa DONs và chủ sở hữu dựa vào các hợp đồng. Ngược lại, chuỗi khối có nghĩa là hoạt động như hệ thống lưu trữ cố định. Xem Phụ lục B.2 để biết thêm chi tiết về tính toán DON. 3.3 Lưu trữ Là một hệ thống dựa trên ủy ban, DON có thể lưu trữ lượng dữ liệu vừa phải một cách liên tục trên L với chi phí thấp hơn nhiều so với blockchain không được phép. Ngoài ra, thông qua bộ điều hợp, DONs có thể tham chiếu các hệ thống phi tập trung bên ngoài để lưu trữ dữ liệu, ví dụ: Filecoin [85], và do đó có thể kết nối các hệ thống đó với smart contracts. Tùy chọn này đặc biệt hấp dẫn đối với dữ liệu số lượng lớn như một phương tiện giải quyết vấn đề phổ biến về “sự phình to” trong blockchain hệ thống. DONs do đó có thể lưu trữ dữ liệu cục bộ hoặc bên ngoài để sử dụng trong các dịch vụ được hỗ trợ cụ thể của chúng. DON cũng có thể sử dụng dữ liệu đó theo cách bí mật, tính toán trên dữ liệu: (1) được chia sẻ bí mật trên DON nút hoặc được mã hóa theo khóa được quản lý bởi các nút DON theo cách phù hợp để tính toán an toàn cho nhiều bên hoặc mã hóa đồng cấu một phần hoặc toàn bộ; hoặc (2) được bảo vệ bằng cách thực thi đáng tin cậy môi trường. Chúng tôi hy vọng rằng DONs sẽ áp dụng mô hình quản lý bộ nhớ đơn giản phổ biến cho hệ thống hợp đồng thông minh: Một tệp thực thi chỉ có thể ghi vào bộ nhớ của chính nó. Thực thi tuy nhiên, có thể đọc từ bộ nhớ của các tệp thực thi khác. Xem Phụ lục B.3 để biết thêm chi tiết về bộ lưu trữ DON. 3,4 Khung thực thi giao dịch (TEF) DON nhằm mục đích hỗ trợ các hợp đồng trên chuỗi chính MAINCHAIN (hoặc trên nhiều chuỗi chính). Khung thực thi giao dịch (TEF), được thảo luận chi tiếttrong Phần 6, là một cách tiếp cận có mục đích chung để thực hiện hợp đồng một cách hiệu quả SC trên MAINCHAIN và DON. TEF nhằm hỗ trợ FSS và lớp 2 công nghệ—đồng thời, nếu muốn. Thật vậy, nó có khả năng đóng vai trò là phương tiện chính để sử dụng FSS (và vì lý do đó, chúng tôi không thảo luận thêm về FSS trong phần này). Tóm lại, trong TEF, hợp đồng mục tiêu ban đầu được SC thiết kế hoặc phát triển cho MAINCHAIN được tái cấu trúc thành một hợp đồng lai. Việc tái cấu trúc này tạo ra hai khả năng tương tác các phần của hợp đồng kết hợp: hợp đồng MAINCHAIN SCa mà chúng tôi đề cập đến để hiểu rõ hơn trong bối cảnh TEF dưới dạng hợp đồng cố định và người thực thi có thể thực thi trên DON. các hợp đồng SCa giám sát tài sản của người dùng, thực hiện chuyển đổi trạng thái có thẩm quyền, đồng thời cung cấp các thanh chắn bảo vệ (xem Phần 7.3) chống lại các hư hỏng trong DON. Các nhà thực thi thực thi sắp xếp các giao dịch và cung cấp dữ liệu oracle liên quan cho chúng. Nó có thể bó giao dịch cho SCa theo bất kỳ cách nào—ví dụ: sử dụng dựa trên bằng chứng xác thực hoặc lạc quan rollups, thực thi bí mật bởi DON, v.v. Chúng tôi mong muốn phát triển các công cụ giúp nhà phát triển dễ dàng phân chia hợp đồng SC được viết bằng ngôn ngữ cấp cao thành các phần logic MAINCHAIN và DON, SCa và thực thi tương ứng, soạn thảo một cách an toàn và hiệu quả. Sử dụng TEF để tích hợp các sơ đồ giao dịch hiệu suất cao với các chương trình hiệu suất cao oracles là không thể thiếu đối với phương pháp mở rộng quy mô oracle của chúng tôi. 3,5 Dịch vụ Mempool Một tính năng quan trọng của lớp ứng dụng mà chúng tôi dự định triển khai trên DON để hỗ trợ của FSS và TEF là Dịch vụ Mempool (MS). MS có thể được xem như một bộ chuyển đổi, nhưng một với sự hỗ trợ hạng nhất. MS cung cấp hỗ trợ cho việc xử lý giao dịch tương thích với kế thừa. Trong việc sử dụng này, MS nhập vào từ bộ nhớ của chuỗi chính những giao dịch dành cho hợp đồng mục tiêu SC trên MAINCHAIN. Sau đó MS chuyển các giao dịch này tới một tệp thực thi trên DON, nơi chúng được xử lý theo cách mong muốn. Dữ liệu MS có thể được sử dụng bởi DON để soạn các giao dịch mà sau đó có thể được chuyển trực tiếp tới SC từ DON hoặc tới một hợp đồng khác gọi SC. Ví dụ: DON có thể chuyển tiếp giao dịch được thu thập thông qua MS hoặc nó có thể sử dụng dữ liệu MS để đặt giá gas cho các giao dịch mà nó gửi tới CHUỖI MAIN. Vì nó giám sát mempool nên MS có thể thu được các giao dịch từ người dùng tương tác trực tiếp với SC. Do đó, người dùng có thể tiếp tục tạo giao dịch của mình bằng cách sử dụng phần mềm cũ, tức là các ứng dụng không biết đến sự tồn tại của MS và được cấu hình MS hợp đồng. (Trong trường hợp này, SC phải được thay đổi để bỏ qua các giao dịch ban đầu và chỉ chấp nhận những dữ liệu được MS xử lý để tránh xử lý kép.) Để sử dụng với hợp đồng mục tiêu SC, MS có thể được sử dụng với FSS và/hoặc TEF.3.6 Bước đệm: Khả năng Chainlink hiện có 3.6.1 Báo cáo ngoài chuỗi (OCR) Báo cáo chuỗi Off (OCR) [60] là một cơ chế trong Chainlink để tổng hợp và truyền báo cáo oracle tới SC hợp đồng dựa trên. Được triển khai gần đây với giá Chainlink mạng nguồn cấp dữ liệu, nó thể hiện bước đầu tiên trên đường dẫn đến DON đầy đủ. Về cốt lõi, OCR là giao thức BFT được thiết kế để hoạt động ở chế độ đồng bộ một phần mạng. Nó đảm bảo tính sống động và đúng đắn khi có mặt f < n/3 một cách tùy ý các nút bị lỗi, đảm bảo các đặc tính của chương trình phát sóng đáng tin cậy của Byzantine, nhưng không phải vậy một giao thức đồng thuận BFT hoàn chỉnh. Các nút không duy trì nhật ký tin nhắn nhất quán theo nghĩa đại diện cho một sổ cái giống hệt nhau về mọi quan điểm của họ, và người đứng đầu giao thức có thể lập lờ mà không vi phạm an toàn. OCR hiện được thiết kế cho một loại thông báo cụ thể: tổng hợp trung bình của (ít nhất 2f +1) giá trị được báo cáo bởi các nút tham gia. Nó cung cấp một sự đảm bảo quan trọng về các báo cáo mà nó xuất ra cho SC, được gọi là các báo cáo được chứng thực: Giá trị trung bình trong một báo cáo được chứng thực báo cáo bằng hoặc nằm giữa các giá trị được báo cáo bởi hai nút trung thực. Tài sản này là điều kiện an toàn chính cho OCR. Người lãnh đạo có thể có một số ảnh hưởng ở mức trung bình giá trị trong một báo cáo được chứng thực, nhưng chỉ tuân theo điều kiện về tính chính xác này. OCR có thể được mở rộng cho các loại thông báo tổng hợp các giá trị theo nhiều cách khác nhau. Mặc dù mục tiêu về tính chính xác và hoạt động của mạng Chainlink ngày nay không yêu cầu OCR là một giao thức đồng thuận toàn diện, chúng yêu cầu OCR cung cấp một số dạng chức năng bổ sung không có trong các giao thức BFT thông thường, đáng chú ý nhất là: 1. Phát báo cáo ngoài chuỗi tất cả hoặc không có gì: OCR đảm bảo rằng báo cáo được chứng thực được cung cấp nhanh chóng cho tất cả các nút trung thực hoặc không nút nào trong số chúng. Đây là một sự công bằng thuộc tính giúp đảm bảo rằng các nút trung thực có cơ hội tham gia trong việc truyền báo cáo được chứng thực. 2. Đường truyền đáng tin cậy: OCR đảm bảo, ngay cả khi có lỗi hoặc độc hại các nút, rằng tất cả các báo cáo và tin nhắn OCR được truyền đến SC trong một khoảng thời gian nhất định, khoảng thời gian được xác định trước. Đây là một tài sản sống động. 3. Giảm thiểu độ tin cậy dựa trên hợp đồng: SC lọc ra các báo cáo do OCR tạo có khả năng sai sót, ví dụ: nếu giá trị được báo cáo của chúng sai lệch đáng kể so với các báo cáo khác những cái đã nhận được gần đây. Đây là một hình thức thực thi tính đúng đắn của giao thức bổ sung. Cả ba thuộc tính này sẽ đóng vai trò tự nhiên trong DONs. Chương trình phát sóng tất cả hoặc không có gì trên chuỗi (DON) là một khối xây dựng quan trọng để đảm bảo kinh tế tiền điện tử xung quanh việc truyền tải đáng tin cậy, do đó đây là một thuộc tính thiết yếu của bộ điều hợp. Tin tưởng giảm thiểu trong SC là một loại đường ray bảo vệ, như được thảo luận trong Phần 7.3. OCR cũng cung cấp cơ sở cho việc triển khai hoạt động và cải tiến các giao thức BFT trong mạng oracle của Chainlink và do đó, như đã lưu ý ở trên, một đường dẫn đến toàn bộ chức năng của DONs.3.6.2 DECO và Town Crier DECO [234] và Town Crier [233] là một cặp công nghệ liên quan hiện đang được sử dụng được phát triển trong mạng Chainlink. Hầu hết các máy chủ web ngày nay đều cho phép người dùng kết nối qua kênh bảo mật bằng giao thức được gọi là Bảo mật lớp vận chuyển (TLS) [94]. (HTTPS biểu thị một biến thể của HTTP được bật bằng TLS, tức là các URL có tiền tố “https” biểu thị việc sử dụng TLS để bảo mật.) Tuy nhiên, hầu hết các máy chủ hỗ trợ TLS đều có một hạn chế đáng chú ý: Chúng không ký điện tử dữ liệu. Do đó, người dùng hoặc Prover không thể hiển thị dữ liệu cô ấy nhận được từ máy chủ cho bên thứ ba hoặc Người xác minh, chẳng hạn như oracle hoặc smart contract, theo cách đảm bảo tính xác thực của dữ liệu. Ngay cả khi máy chủ ký dữ liệu bằng chữ ký điện tử thì vẫn có vấn đề về tính bảo mật. Nhà cung cấp có thể muốn biên tập lại hoặc sửa đổi dữ liệu nhạy cảm trước khi trình bày nó với Người xác minh. Tuy nhiên, chữ ký số được thiết kế đặc biệt để vô hiệu hóa dữ liệu đã sửa đổi. Do đó, chúng ngăn cản Prover thực hiện các thay đổi bảo đảm tính bảo mật tới dữ liệu. (Xem Phần 7.1 để thảo luận thêm.) DECO và Town Crier được thiết kế để cho phép Prover lấy dữ liệu từ trang web máy chủ và trình nó cho Người xác minh theo cách đảm bảo tính toàn vẹn và bảo mật. Hai hệ thống duy trì tính toàn vẹn theo nghĩa là chúng đảm bảo rằng dữ liệu được trình bày bởi Prover cho Verifier có nguồn gốc xác thực từ máy chủ mục tiêu. Họ hỗ trợ tính bảo mật theo nghĩa cho phép Prover biên tập lại hoặc sửa đổi dữ liệu (trong khi vẫn bảo toàn tính toàn vẹn). Đặc điểm chính của cả hai hệ thống là chúng không yêu cầu bất kỳ sửa đổi nào đối với máy chủ web mục tiêu. Họ có thể hoạt động với bất kỳ máy chủ hỗ trợ TLS hiện có nào. Trên thực tế, chúng minh bạch đối với máy chủ: Từ quan điểm của máy chủ, Prover là thiết lập một kết nối thông thường. Hai hệ thống này có các mục tiêu tương tự nhau, nhưng khác nhau về mô hình tin cậy và cách triển khai như chúng tôi sẽ giải thích ngắn gọn. DECO sử dụng cơ bản các giao thức mã hóa để đạt được tính toàn vẹn của nó và các thuộc tính bảo mật. Trong khi thiết lập phiên với máy chủ mục tiêu bằng DECO, Prover đồng thời tham gia vào một giao thức tương tác với Người xác minh. Giao thức này cho phép Người chứng minh chứng minh với Người xác minh rằng nó đã nhận được một phần dữ liệu D nhất định từ máy chủ trong phiên hiện tại của nó. Người Prover có thể hoặc đưa ra cho Người xác minh bằng chứng không có kiến thức về một số thuộc tính của D và do đó không tiết lộ trực tiếp D. Trong cách sử dụng DECO thông thường, người dùng hoặc một nút có thể xuất dữ liệu D từ một máy chủ riêng tư. phiên với máy chủ web tới tất cả các nút trong DON. Kết quả là toàn bộ DON có thể chứng thực tính xác thực của D (hoặc một sự thật bắt nguồn từ D thông qua bằng chứng không có kiến thức). Ngoài các ứng dụng ví dụ được đưa ra sau trong bài viết, khả năng này có thể được được sử dụng để khuếch đại quyền truy cập có tính toàn vẹn cao vào nguồn dữ liệu bằng DON. Ngay cả khi chỉ có một nút có quyền truy cập trực tiếp vào nguồn dữ liệu—ví dụ: do một thỏa thuận độc quyền với nhà cung cấp dữ liệu—toàn bộ DON vẫn có thể chứng thực tính đúng đắn củacác báo cáo được phát ra bởi nút đó. Town Crier dựa vào việc sử dụng môi trường thực thi đáng tin cậy (TEE) như Intel SGX. Tóm lại, TEE hoạt động như một loại hộp đen thực thi các ứng dụng trong một môi trường cách chống giả mạo và bí mật. Về nguyên tắc, ngay cả chủ sở hữu máy chủ lưu trữ trên đó TEE đang chạy không thể (không thể phát hiện) làm thay đổi ứng dụng được bảo vệ bởi TEE cũng như không xem trạng thái của ứng dụng, có thể bao gồm dữ liệu bí mật. Town Crier có thể đạt được tất cả chức năng của DECO và hơn thế nữa. DECO hạn chế Nhà cung cấp tương tác với một Người xác minh duy nhất. Ngược lại, Town Crier cho phép Nhà cung cấp tạo ra bằng chứng có thể xác minh công khai về dữ liệu D được tìm nạp từ máy chủ mục tiêu, tức là bằng chứng cho thấy bất kỳ ai, kể cả smart contract, đều có thể xác minh trực tiếp. Town Crier có thể cũng nhập và sử dụng các bí mật một cách an toàn (ví dụ: thông tin xác thực của người dùng). Hạn chế chính của Town Crier là sự phụ thuộc vào TEE. TEE sản xuất có gần đây đã được chứng minh là có một số lỗ hổng nghiêm trọng, mặc dù công nghệ này vẫn còn ở giai đoạn sơ khai và chắc chắn sẽ trưởng thành. Xem Phụ lục B.2.1 và B.2.2 để biết thảo luận thêm về TEE. Để biết một số ứng dụng mẫu của DECO và Town Crier, hãy xem Phần 4.3, 4.5 và 9.4.3 và Phụ lục C.1. 3.6.3 Dịch vụ trên chuỗi hiện có Chainlink Chainlink oracle mạng cung cấp một số dịch vụ chính trên nhiều mạng blockchains và các hệ thống phi tập trung khác hiện nay. Sự tiến hóa hơn nữa như mô tả trong sách trắng này sẽ cung cấp cho các dịch vụ hiện có này những khả năng và đạt được. Ba ví dụ là: Nguồn cấp dữ liệu: Ngày nay, phần lớn Chainlink người dùng dựa vào smart contracts thực hiện việc sử dụng nguồn cấp dữ liệu. Đây là những báo cáo về giá trị hiện tại của các phần dữ liệu quan trọng theo đến các nguồn có thẩm quyền ngoài chuỗi. Ví dụ: nguồn cấp dữ liệu giá là nguồn cấp dữ liệu báo cáo giá về tài sản—tiền điện tử, hàng hóa, ngoại hối, chỉ số, cổ phiếu, v.v.—theo dịch vụ trao đổi hoặc tổng hợp dữ liệu. Những nguồn cấp dữ liệu như vậy ngày nay đã giúp đảm bảo hàng tỷ giá trị đô la trên chuỗi thông qua việc sử dụng chúng trong các hệ thống DeFi như Aave [147] và Tổng hợp [208]. Các ví dụ khác về nguồn cấp dữ liệu Chainlink bao gồm dữ liệu thời tiết cho bảo hiểm cây trồng tham số [75] và dữ liệu bầu cử [93], cùng một số dữ liệu khác. Việc triển khai DON và các công nghệ khác được mô tả trong bài viết này sẽ tăng cường việc cung cấp nguồn cấp dữ liệu trong mạng Chainlink theo nhiều cách, bao gồm: • Mở rộng quy mô: OCR và sau đó là DON nhằm mục đích cho phép các dịch vụ Chainlink mở rộng quy mô đáng kể trên nhiều blockchain mà họ hỗ trợ. Ví dụ, chúng tôi mong đợi DON sẽ giúp tăng số lượng nguồn cấp dữ liệu do các nút cung cấp bằng cách sử dụng Chainlink từ 100 đến 1000 và hơn thế nữa. Việc chia tỷ lệ như vậy sẽ giúp Chainlink hệ sinh thái đạt được mục tiêu cung cấp dữ liệu liên quan đến smart contract một cách toàn diện, đồng thời vừa đáp ứng vừa dự đoán các nhu cầu hiện tại và tương lai.• Bảo mật nâng cao: Bằng cách lưu trữ các báo cáo trung gian, DONs sẽ giữ lại các bản ghi về hành vi của nút để theo dõi và đo lường độ chính xác cao về hiệu suất và độ chính xác của chúng, tạo nền tảng thực nghiệm vững chắc cho các hệ thống danh tiếng cho các nút Chainlink. FSS và TEF sẽ cho phép kết hợp nguồn cấp dữ liệu giá với dữ liệu giao dịch theo những cách linh hoạt để ngăn chặn các cuộc tấn công như chạy trước. (Rõ ràng) staking sẽ tăng cường bảo vệ an ninh kinh tế tiền điện tử hiện có của nguồn cấp dữ liệu. • Tính linh hoạt của nguồn cấp dữ liệu: Vì blockchain hệ thống bất khả tri (thực ra, rộng hơn là hệ thống bất khả tri về người tiêu dùng), DONs có thể tạo điều kiện thuận lợi cho việc cung cấp nguồn cấp dữ liệu cho nhiều nơi của các hệ thống dựa vào. Một DON có thể đẩy đồng thời một nguồn cấp dữ liệu nhất định vào một tập hợp của blockchain khác nhau, loại bỏ nhu cầu về mạng oracle trên mỗi chuỗi và cho phép triển khai nhanh chóng các nguồn cấp dữ liệu hiện có trên blockchain mới và các nguồn cấp dữ liệu bổ sung nguồn cấp dữ liệu trên blockchain hiện được phục vụ. • Tính bảo mật: Khả năng thực hiện tính toán tổng quát trong DON cho phép tính toán trên dữ liệu nhạy cảm diễn ra ngoài chuỗi, tránh xảy ra trên chuỗi tiếp xúc. Ngoài ra, bằng cách sử dụng DECO hoặc Town Crier, có thể đạt được tính bảo mật thậm chí còn mạnh mẽ hơn, cho phép tạo báo cáo dựa trên dữ liệu không chính xác tiếp xúc ngay cả với các nút DON. Xem Phần 4.3 và Phần 4.5 để biết ví dụ. Hàm ngẫu nhiên có thể xác minh (VRF): Một số loại DApp yêu cầu nguồn ngẫu nhiên chính xác có thể xác minh được để cho phép xác minh hoạt động công bằng của chính chúng. Mã thông báo không thể thay thế (NFTs) là một ví dụ. Độ hiếm của các tính năng NFT trong Aavegotchi [23] và Axie Infinity [35] được xác định bởi Chainlink VRF, cũng như sự phân bố trong số NFT bằng cách rút thăm dựa trên vé trong Thẻ Ether [102]; sự đa dạng của DApp chơi game có kết quả ngẫu nhiên; và các công cụ tài chính độc đáo, ví dụ: trò chơi tiết kiệm không thua lỗ như PoolTogether [89], phân bổ vốn cho người chiến thắng ngẫu nhiên. Các ứng dụng blockchain và không phảiblockchain khác cũng yêu cầu bảo mật nguồn ngẫu nhiên, bao gồm việc lựa chọn các ủy ban hệ thống phi tập trung và thực hiện xổ số. Mặc dù các khối hash có thể đóng vai trò là nguồn ngẫu nhiên không thể đoán trước nhưng chúng dễ bị thao túng bởi những người khai thác đối nghịch (và ở một mức độ nào đó bởi người dùng gửi giao dịch). Chainlink VRF [78] cung cấp giải pháp thay thế an toàn hơn đáng kể. Một oracle có cặp khóa riêng/chung được liên kết (sk, pk) có khóa riêng được duy trì ngoài chuỗi và khóa chung pk được công bố. Để xuất ra một giá trị ngẫu nhiên, nó áp dụng sk cho hạt giống x không thể đoán trước được cung cấp bởi một hợp đồng dựa trên (ví dụ: khối hash và các tham số dành riêng cho DApp) bằng cách sử dụng hàm F, mang lại y = Fsk(x) cùng với a bằng chứng về tính đúng đắn. (Xem [180] để biết VRF có sẵn trên Chainlink.) Điều gì tạo nên một VRF có thể kiểm chứng được là thực tế là với kiến thức về pk, có thể kiểm tra tính đúng đắn của chứng minh và do đó của y. Do đó, giá trị y không thể đoán trước được đối với một đối thủ không thể dự đoán x hoặc tìm hiểu sk và dịch vụ không thể thao túng.Chainlink VRF có thể được xem chỉ là một trong nhóm ứng dụng liên quan đến việc giám sát các khóa riêng tư trên chuỗi. Tổng quát hơn, DON có thể cung cấp tính bảo mật, lưu trữ phi tập trung các khóa riêng lẻ cho ứng dụng và/hoặc người dùng và kết hợp khả năng này với tính toán tổng quát. Kết quả là một loạt các ứng dụng, mà chúng tôi đưa ra một số ví dụ trong bài viết này, bao gồm quản lý khóa cho Bằng chứng về Dự trữ (xem Phần 4.1) và thông tin xác thực phi tập trung của người dùng (và các thông tin kỹ thuật số khác tài sản) (xem Phần 4.3). Người giữ: Chainlink Keepers [87] cho phép các nhà phát triển viết mã cho phi tập trung thực thi các công việc ngoài chuỗi, thường là để kích hoạt thực thi các smart contract dựa vào. Trước khi Keepers ra đời, các nhà phát triển thường vận hành những ứng dụng ngoài chuỗi như vậy logic, tạo ra các điểm thất bại tập trung (cũng như nỗ lực phát triển trùng lặp đáng kể). Thay vào đó, Keepers cung cấp một khuôn khổ dễ sử dụng cho gia công phần mềm phi tập trung cho các hoạt động này, cho phép chu kỳ phát triển ngắn hơn và đảm bảo mạnh mẽ về tính sống động và các đặc tính bảo mật khác. Người giữ có thể hỗ trợ bất kỳ của nhiều mục tiêu kích hoạt khác nhau, bao gồm việc thanh lý các khoản vay hoặc thực hiện các giao dịch tài chính, bắt đầu các đợt airdrop hoặc thanh toán phụ thuộc vào thời gian trong các hệ thống thu hoạch năng suất, v.v. Trong khuôn khổ DON, người khởi xướng có thể được xem là sự khái quát hóa của Người quản lý theo một số nghĩa. Người khởi xướng có thể sử dụng các bộ điều hợp và do đó có thể tận dụng thư viện giao diện được mô-đun hóa cho các hệ thống trên chuỗi và ngoài chuỗi, cho phép nhanh chóng phát triển các chức năng an toàn, phức tạp. Người khởi xướng bắt đầu tính toán trong các tệp thực thi, bản thân chúng cung cấp tính linh hoạt đầy đủ của DON, cho phép phạm vi rộng một loạt các dịch vụ phi tập trung mà chúng tôi trình bày trong bài viết này dành cho các ứng dụng trên chuỗi và ngoài chuỗi. 3.6.4 Danh tiếng nút / Lịch sử hiệu suất Hệ sinh thái Chainlink hiện tại ghi lại lịch sử hiệu suất của các nút đóng góp trên chuỗi. Tính năng này đã tạo ra một tập hợp các tài nguyên định hướng danh tiếng để thu thập, lọc và trực quan hóa dữ liệu hiệu suất trên từng cá nhân. nhà khai thác nút và nguồn cấp dữ liệu. Người dùng có thể tham khảo các tài nguyên này để cung cấp thông tin quyết định trong việc lựa chọn các nút và giám sát hoạt động của các mạng hiện có. Khả năng tương tự sẽ giúp người dùng chọn DONs. Ví dụ: các thị trường không được phép ngày nay như market.link cho phép nút nhà khai thác liệt kê các dịch vụ oracle của họ và chứng thực danh tính ngoài chuỗi của họ thông qua các dịch vụ như Keybase [4], liên kết hồ sơ của một nút trong Chainlink với nó tên miền và tài khoản truyền thông xã hội hiện có của chủ sở hữu. Ngoài ra, hiệu suất các công cụ phân tích, chẳng hạn như các công cụ có sẵn tại market.link và uy tín.link, cho phép người dùng xem số liệu thống kê về hiệu suất lịch sử của các nút riêng lẻ, bao gồm cả nút của họ độ trễ phản hồi trung bình, độ lệch của các giá trị trong báo cáo của họ so với giá trị đồng thuận được chuyển tiếp trên chuỗi, doanh thu được tạo ra, công việc được hoàn thành, v.v. Những công cụ phân tích này cũng cho phép người dùng theo dõi việc sử dụng các mạng oracle khác nhau của những người dùng khác, một dạngsự chứng thực ngầm định của các nút bảo vệ các mạng như vậy. Kết quả là một “mạng lưới” phẳng tin cậy”, trong đó, bằng cách sử dụng các nút cụ thể, các ứng dụng phi tập trung có giá trị cao sẽ tạo ra một tín hiệu về sự tin tưởng của họ đối với các nút đó mà người dùng khác có thể quan sát và tính đến quyết định lựa chọn nút riêng. Với DONs (và ban đầu là OCR) dẫn đến sự thay đổi trong xử lý giao dịch và hoạt động hợp đồng nói chung hơn là ngoài chuỗi. Một mô hình phi tập trung cho nút ghi vẫn có thể thực hiện được hiệu suất trong chính DON. Quả thực, hiệu suất cao và dung lượng dữ liệu DONs giúp có thể xây dựng các bản ghi ở dạng chi tiết cách và cũng để thực hiện tính toán phi tập trung trên các hồ sơ này, mang lại những bản tóm tắt đáng tin cậy có thể được sử dụng bởi các dịch vụ danh tiếng và được kiểm tra trên CHUỖI MAIN. Mặc dù về nguyên tắc DON có thể trình bày sai hành vi của các nút cấu thành nếu một phần lớn các nút bị hỏng, chúng tôi lưu ý rằng tập thể hiệu suất của chính DON trong việc phân phối dữ liệu trên chuỗi được hiển thị trên MAINCHAIN và do đó không thể bị trình bày sai. Ngoài ra, chúng tôi dự định khám phá các cơ chế khuyến khích báo cáo nội bộ chính xác về hành vi của nút trong DON. Ví dụ: bằng cách báo cáo tập hợp con các nút có hiệu suất cao trả về dữ liệu đóng góp nhanh nhất đối với một báo cáo được chuyển tiếp trên chuỗi, DON tạo động lực cho các nút tranh chấp không chính xác báo cáo: Việc bao gồm các nút trong tập hợp con này không chính xác có nghĩa là loại trừ các nút không chính xác điều đó lẽ ra phải được đưa vào và do đó trừng phạt họ một cách vô hiệu. Việc DON báo cáo lỗi lặp đi lặp lại cũng sẽ tạo ra động cơ khuyến khích các nút trung thực rời khỏi DON. Biên soạn phi tập trung lịch sử hiệu suất chính xác và hậu quả khả năng của người dùng trong việc xác định các nút có hiệu suất cao và để người vận hành nút xây dựng danh tiếng là đặc điểm phân biệt quan trọng của hệ sinh thái Chainlink. Chúng tôi trình bày trong Phần 9 cách chúng ta có thể suy luận về chúng như một phần quan trọng của một hệ thống chặt chẽ và cái nhìn mở rộng về an ninh kinh tế được cung cấp bởi 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].
Dịch vụ phi tập trung được kích hoạt bởi phi tập trung
Mạng Oracle Để minh họa tính linh hoạt của DON và cách chúng kích hoạt một loạt dịch vụ mới, chúng tôi trình bày năm ví dụ về các ứng dụng dựa trên DON trong phần này và mô tả hợp đồng kết hợp hiện thực hóa chúng: (1) Bằng chứng dự trữ, một hình thức dịch vụ chuỗi chéo; (2) Giao tiếp với các hệ thống doanh nghiệp/cũ, tức là tạo ra một ứng dụng dựa trên phần mềm trung gian lớp trừu tượng tạo điều kiện phát triển các ứng dụng blockchain với chi phí tối thiểu blockchain-mã hoặc chuyên môn cụ thể; (3) Nhận dạng phi tập trung, các công cụ cho phép người dùng có được và quản lý các tài liệu nhận dạng và thông tin xác thực của riêng họ; (4) Các kênh ưu tiên, một dịch vụ đảm bảo đưa vào kịp thời các giao dịch cơ sở hạ tầng quan trọng (ví dụ: oracle báo cáo) trên blockchain; và (5) Bảo đảm bí mật DeFi, nghĩa là tài chính smart contract che giấu dữ liệu nhạy cảm của các bên tham gia. Ở đây, chúng tôi
sử dụng SC để biểu thị phần MAINCHAIN của hợp đồng kết hợp và mô tả DON thành phần riêng biệt hoặc dưới dạng một chương trình thực thi có thể thực thi được. 4.1 Bằng chứng dự trữ Đối với nhiều ứng dụng, việc chuyển tiếp trạng thái giữa hoặc giữa blockchains là rất hữu ích. A ứng dụng phổ biến của các dịch vụ như vậy là gói tiền điện tử. Những đồng xu được bọc như vậy vì WBTC [15] đang trở thành tài sản phổ biến trong Tài chính phi tập trung (DeFi). Họ liên quan đến việc gửi tài sản hỗ trợ “được bao bọc” vào nguồn của nó blockchain MAINCHAIN(1) và tạo token tương ứng trên một mục tiêu khác, blockchain MAINCHAIN(2). Ví dụ: WBTC là ERC20 token trên Ethereum blockchain tương ứng tới BTC trên Bitcoin blockchain. Vì các hợp đồng trên MAINCHAIN(2) không hiển thị trực tiếp vào MAINCHAIN(1), họ phải dựa một cách rõ ràng hoặc ngầm định vào oracle để báo cáo về khoản tiền gửi của gói được bao bọc nội dung trong smart contract, tạo ra cái mà đôi khi được gọi là Bằng chứng dự trữ. trong Ví dụ: WBTC [15], người giám sát BitGo nắm giữ BTC và phát hành WBTC, với Chainlink mạng cung cấp Bằng chứng dự trữ [76]. DON có thể tự cung cấp Bằng chứng dự trữ. Tuy nhiên, với DON, có thể để đi xa hơn DON có thể quản lý bí mật và thông qua việc sử dụng bộ điều hợp thích hợp, có thể giao dịch trên bất kỳ blockchain nào mong muốn. Do đó, DON có thể hành động với tư cách là một trong số những người giám hộ—hoặc thậm chí là người giám hộ duy nhất, phi tập trung—cho một tài sản được bọc. DON do đó có thể đóng vai trò là nền tảng để nâng cao tính bảo mật của các dịch vụ hiện có sử dụng Bằng chứng dự trữ. Ví dụ: giả sử MAINCHAIN(1) là Bitcoin và MAINCHAIN(2) là Ethereum. Trên MAINCHAIN(2), SC hợp đồng phát hành tokens đại diện cho BTC được bao bọc. DON kiểm soát địa chỉ BTC (1) DON. Sau đó, để bọc BTC, người dùng U gửi X BTC từ địa chỉ (1) bạn để thêm (1) DON cùng với địa chỉ MAINCHAIN(2)-địa chỉ (2) bạn. Màn hình DON địa chỉ (1) DON thông qua bộ chuyển đổi sang MAINCHAIN(1). Khi quan sát tiền gửi của U, với xác nhận có xác suất đủ cao, nó sẽ gửi một tin nhắn đến SC thông qua bộ chuyển đổi tới CHUỖI CHÍNH(2). Thông báo này hướng dẫn SC đúc X tokens cho addr(2) bạn. Để U giải phóng X tokens thì điều ngược lại sẽ xảy ra. Tuy nhiên, trên MAINCHAIN(1), địa chỉ (1) DON gửi X BTC tới addr(1) U (hoặc đến địa chỉ khác, nếu người dùng yêu cầu). Tất nhiên, các giao thức này có thể được điều chỉnh để hoạt động với các sàn giao dịch, thay vì trực tiếp. với người dùng. 4.2 Giao diện với hệ thống doanh nghiệp / kế thừa DON có thể đóng vai trò là cầu nối giữa và giữa blockchain, như trong ví dụ về Bằng chứng của Dự trữ, nhưng một mục tiêu khác là để chúng đóng vai trò là cầu nối hai chiều giữa blockchains và các hệ thống kế thừa [176] hoặc các hệ thống tương tự blockchain chẳng hạn như ngân hàng trung ương tiền kỹ thuật số [30]. Các doanh nghiệp phải đối mặt với một số thách thức trong việc kết nối các hệ thống hiện có của họ và quy trình cho các hệ thống phi tập trung, bao gồm:• Tính linh hoạt của chuỗi khối: Hệ thống chuỗi khối thay đổi nhanh chóng. Doanh nghiệp có thể phải đối mặt với sự xuất hiện mới nhanh chóng hoặc mức độ phổ biến ngày càng tăng của blockchains các đối tác mong muốn thực hiện giao dịch nhưng doanh nghiệp không có hỗ trợ cơ sở hạ tầng hiện có của nó. Nhìn chung, sự năng động của blockchains tạo nên rất khó để các doanh nghiệp riêng lẻ có thể theo kịp hệ sinh thái đầy đủ. • Nguồn lực phát triển dành riêng cho chuỗi khối: Đối với nhiều tổ chức, việc tuyển dụng hoặc ươm tạo chuyên môn blockchain tiên tiến là rất khó khăn, đặc biệt là khi xét đến thử thách sự nhanh nhẹn. • Quản lý khóa riêng: Quản lý khóa riêng cho blockchain hoặc tiền điện tử yêu cầu chuyên môn vận hành khác với chuyên môn về an ninh mạng truyền thống thực tiễn và không có sẵn cho nhiều doanh nghiệp. • Tính bảo mật: Các doanh nghiệp rất thận trọng khi tiết lộ thông tin nhạy cảm và độc quyền của mình dữ liệu trên chuỗi. Để giải quyết ba khó khăn đầu tiên, nhà phát triển chỉ cần sử dụng DON như một lớp phần mềm trung gian an toàn để cho phép các hệ thống doanh nghiệp đọc từ hoặc ghi vào blockchains. DON có thể tóm tắt những cân nhắc kỹ thuật chi tiết như động lực khí, tổ chức lại chuỗi, v.v. cho cả nhà phát triển và người dùng. Bởi trình bày giao diện blockchain được sắp xếp hợp lý cho các hệ thống doanh nghiệp, do đó DON có thể đơn giản hóa đáng kể việc phát triển các ứng dụng doanh nghiệp nhận biết blockchain, loại bỏ gánh nặng cho các doanh nghiệp trong việc mua hoặc ươm tạo các tài nguyên phát triển cụ thể blockchain. Việc sử dụng DON như vậy đặc biệt hấp dẫn ở chỗ nó cho phép các nhà phát triển doanh nghiệp tạo các ứng dụng hợp đồng thông minh phần lớn là blockchain bất khả tri. Kết quả là, lớn hơn tập hợp blockchain trong đó DON được thiết kế để hoạt động như phần mềm trung gian, lớn hơn tập hợp blockchain mà người dùng doanh nghiệp có thể dễ dàng truy cập. Nhà phát triển có thể chuyển các ứng dụng từ blockchain hiện có sang ứng dụng mới với sự sửa đổi tối thiểu cho các ứng dụng được phát triển nội bộ của họ. Để giải quyết vấn đề bổ sung về tính bảo mật, các nhà phát triển có thể khiếu nại lên cơ quan các công cụ chúng tôi giới thiệu trong bài viết này và dự kiến sẽ triển khai để hỗ trợ các ứng dụng DON. Chúng bao gồm DECO và Town Crier Mục 3.6.2 cũng như bảo vệ bí mật Các sửa đổi API được thảo luận trong Phần 7.1.2 và một số cách tiếp cận dành riêng cho ứng dụng được đề cập trong phần còn lại của phần này. Những hệ thống DON này có thể cung cấp chứng thực trực tuyến, có tính toàn vẹn cao về trạng thái hệ thống doanh nghiệp mà không tiết lộ dữ liệu nguồn doanh nghiệp nhạy cảm trên chuỗi. 4.3 Nhận dạng phi tập trung Danh tính phi tập trung là một thuật ngữ chung cho khái niệm mà người dùng có thể lấy và quản lý thông tin xác thực của riêng họ, thay vì dựa vào bên thứ ba để thực hiện vậy. Thông tin xác thực phi tập trung là sự chứng thực cho các thuộc tính hoặc xác nhận của chủ sở hữu,thường được gọi là yêu cầu bồi thường. Thông tin xác thực được ký điện tử bởi các thực thể, thường được gọi là nhà phát hành, có thể liên kết chính xác các khiếu nại với người dùng. Trong hầu hết các phương án được đề xuất, các khiếu nại được liên kết với Mã định danh phi tập trung (DID), một mã định danh chung cho một người dùng nhất định. Thông tin xác thực được liên kết với khóa chung mà người dùng nắm giữ khóa riêng. Do đó, người dùng có thể chứng minh quyền sở hữu yêu cầu bằng cách sử dụng khóa riêng của mình. Có tầm nhìn xa trông rộng như bản sắc phi tập trung, các kế hoạch hiện có và được đề xuất, ví dụ: [14, 92, 129, 216], có ba hạn chế nghiêm trọng: • Thiếu khả năng tương thích kế thừa: Các hệ thống nhận dạng phi tập trung hiện tại dựa vào một cộng đồng các cơ quan có thẩm quyền, được gọi là tổ chức phát hành, để tạo ra thông tin xác thực DID. Bởi vì các dịch vụ web hiện tại thường không ký điện tử dữ liệu, các tổ chức phát hành phải được triển khai như các hệ thống có mục đích đặc biệt. Bởi vì không có động cơ để làm điều này mà không có hệ sinh thái nhận dạng phi tập trung sẽ dẫn đến vấn đề con gà và quả trứng. Ở nơi khác Nói cách khác, vẫn chưa rõ cách khởi động hệ sinh thái của nhà phát hành. • Quản lý khóa không thể thực hiện được: Hệ thống nhận dạng phi tập trung yêu cầu người dùng quản lý khóa riêng, điều mà trải nghiệm với tiền điện tử đã cho thấy là một trách nhiệm không thể thực hiện được. Người ta ước tính có khoảng 4.000.000 Bitcoin đã được bị mất vĩnh viễn do lỗi quản lý khóa [194] và nhiều người dùng lưu trữ tài sản tiền điện tử với các sàn giao dịch [193], do đó làm suy yếu tính phân cấp. • Thiếu khả năng chống lại Sybil bảo vệ quyền riêng tư: Yêu cầu bảo mật cơ bản của các ứng dụng như bỏ phiếu, phân bổ công bằng tokens trong khi bán token, v.v. là người dùng không thể xác nhận nhiều danh tính. Các đề xuất nhận dạng phi tập trung hiện tại yêu cầu người dùng tiết lộ danh tính trong thế giới thực của họ để đạt được điều đó. Khả năng chống lại âm thanh, do đó làm suy yếu các đảm bảo quyền riêng tư quan trọng. Có thể giải quyết những vấn đề này bằng cách sử dụng sự kết hợp của một ủy ban các nút thực hiện tính toán phân tán trong DON và sử dụng các công cụ như DECO hoặc Town Crier, như được hiển thị trong hệ thống có tên CanDID [160]. DECO hoặc Town Crier có thể thiết kế để biến đổi các dịch vụ web hiện có mà không cần sửa đổi vào các nhà phát hành thông tin xác thực bảo mật. Chúng cho phép DON xuất có liên quan dữ liệu cho mục đích này thành thông tin xác thực đồng thời che giấu dữ liệu nhạy cảm không được phép xuất hiện trong thông tin xác thực. Ngoài ra, để tạo thuận lợi cho việc khôi phục khóa cho người dùng, từ đó giải quyết vấn đề quản lý khóa. vấn đề, DON có thể cho phép người dùng lưu trữ khóa riêng tư ở dạng chia sẻ bí mật. Người dùng có thể khôi phục khóa của họ bằng cách chứng minh cho các nút trong DON—tương tự, sử dụng Town Crier hoặc DECO—khả năng đăng nhập vào tài khoản với một nhóm nhà cung cấp web được xác định trước (ví dụ: Twitter, Google, Facebook). Lợi ích của việc sử dụng Town Crier hoặc DECO, trái ngược với OAUTH, là quyền riêng tư của người dùng. Hai công cụ đó cho phép người dùng tránh tiết lộ cho DON một mã định danh nhà cung cấp web—từ đó thường có thể lấy được danh tính trong thế giới thực. Cuối cùng, để cung cấp khả năng kháng Sybil, như được hiển thị trong [160], DON có thể thực hiện chuyển đổi bảo vệ quyền riêng tư của các mã nhận dạng duy nhất trong thế giới thực cho người dùng (ví dụ: Số An sinh Xã hội (SSN)) thành số nhận dạng trên chuỗi khi đăng ký người dùng.Do đó, hệ thống có thể phát hiện các đăng ký trùng lặp mà không có dữ liệu nhạy cảm như SSN được tiết lộ cho các nút DON riêng lẻ.7 DON có thể cung cấp bất kỳ dịch vụ nào trong số này thay mặt cho danh tính phi tập trung bên ngoài các hệ thống trên blockchains không được phép hoặc được phép, ví dụ: các phiên bản của Hyperledger Ấn Độ [129]. Ứng dụng ví dụ: KYC: Bản sắc phi tập trung hứa hẹn sẽ là một phương tiện để hợp lý hóa các yêu cầu đối với các ứng dụng tài chính trên blockchains đồng thời cải thiện khả năng sử dụng của người dùng sự riêng tư. Hai thách thức mà nó có thể giúp giải quyết là các nghĩa vụ công nhận và tuân thủ theo các quy định chống rửa tiền/biết khách hàng (AML/KYC). Các quy định về AML ở nhiều quốc gia yêu cầu các tổ chức tài chính (và các doanh nghiệp khác) thiết lập và xác minh danh tính của các cá nhân và doanh nghiệp liên quan. họ thực hiện các giao dịch. KYC là một thành phần của tổ chức tài chính chính sách AML rộng hơn, thường liên quan đến việc giám sát hành vi của người dùng và theo dõi dòng vốn, cùng nhiều hoạt động khác. KYC thường yêu cầu người dùng trình bày thông tin xác thực danh tính dưới một số hình thức (ví dụ: nhập vào một biểu mẫu web trực tuyến, giơ tài liệu nhận dạng trước mặt người dùng trong một phiên video, v.v.). Tạo và trình bày an toàn thông tin xác thực phi tập trung về nguyên tắc có thể là một giải pháp thay thế có lợi ở một số khía cạnh, cụ thể là bằng cách: (1) Tạo quy trình KYC hiệu quả hơn đối với người dùng và tổ chức tài chính, bởi vì một khi có được thông tin xác thực, nó có thể được trình bày liền mạch cho bất kỳ tổ chức tài chính nào; (2) Giảm gian lận bằng cách giảm cơ hội đánh cắp danh tính thông qua thỏa hiệp thông tin nhận dạng cá nhân (PII) và giả mạo trong quá trình xác minh video; và (3) Giảm nguy cơ xâm phạm PII trong các tổ chức tài chính, khi người dùng giữ quyền kiểm soát dữ liệu của chính họ. Với các khoản phạt trị giá hàng tỷ đô la mà các tổ chức tài chính phải trả vì không tuân thủ AML và nhiều tổ chức tài chính chi hàng triệu đô la hàng năm cho KYC, các cải tiến có thể mang lại khoản tiết kiệm đáng kể cho các tổ chức tài chính. và nói rộng ra là dành cho người tiêu dùng [196]. Trong khi khu vực tài chính truyền thống chậm để áp dụng các công cụ tuân thủ mới, các hệ thống DeFi đang ngày càng áp dụng công cụ này [43]. Ứng dụng ví dụ: Các khoản vay không được thế chấp: Hầu hết DeFi ứng dụng hỗ trợ cho vay ngày nay chỉ bắt nguồn từ các khoản vay có thế chấp đầy đủ. Đây là những khoản vay được thực hiện cho những người đi vay gửi tài sản tiền điện tử có giá trị vượt quá giá trị của khoản vay. Gần đây đã nảy sinh sự quan tâm đến điều mà cộng đồng DeFi thường gọi là các khoản vay không được thế chấp. Ngược lại, đây là những khoản vay có tài sản thế chấp tương ứng có giá trị nhỏ hơn giá trị gốc của khoản vay. Các khoản vay không có tài sản thế chấp giống với các khoản vay thường được thực hiện bởi các tổ chức tài chính truyền thống. Thay vì dựa vào trên tài sản thế chấp ký gửi như một sự đảm bảo trả nợ, thay vào đó họ căn cứ vào việc cho vay quyết định về lịch sử tín dụng của người vay. 7Việc chuyển đổi này dựa trên hàm giả ngẫu nhiên phân tán (PRF).Các khoản vay không được thế chấp là một phần non trẻ nhưng đang phát triển của thị trường cho vay DeFi. Họ dựa vào các cơ chế giống như các cơ chế được sử dụng bởi các tổ chức tài chính truyền thống các tổ chức, chẳng hạn như hợp đồng pháp lý [91]. Một yêu cầu thiết yếu cho sự phát triển của họ sẽ là khả năng cung cấp dữ liệu về mức độ tín nhiệm của người dùng—yếu tố chính trong các quyết định cho vay thông thường—đến các hệ thống DeFi theo cách cung cấp tính toàn vẹn mạnh mẽ, tức là, đảm bảo số liệu chính xác. Hệ thống nhận dạng phi tập trung được kích hoạt DON sẽ cho phép những người đi vay tương lai tạo ra các thông tin có độ đảm bảo cao chứng thực mức độ tin cậy của họ trong khi vẫn bảo toàn tính bảo mật của thông tin nhạy cảm. Cụ thể, người đi vay có thể tạo ra những thông tin xác thực dựa trên hồ sơ từ các nguồn trực tuyến có thẩm quyền trong khi chỉ hiển thị thông tin dữ liệu được chứng thực bởi DON mà không làm lộ dữ liệu có thể nhạy cảm khác. cho Ví dụ: người đi vay có thể tạo thông tin xác thực cho biết rằng điểm tín dụng của cô ấy có nhóm văn phòng tín dụng vượt quá một ngưỡng cụ thể (ví dụ: 750) mà không tiết lộ thông tin của cô ấy điểm chính xác hoặc bất kỳ dữ liệu nào khác trong hồ sơ của cô ấy. Ngoài ra, nếu muốn, thông tin xác thực đó có thể được tạo ẩn danh, tức là tên người dùng có thể được coi là dữ liệu nhạy cảm và bản thân nó không được tiếp xúc với các nút oracle hoặc trong thông tin xác thực phi tập trung của cô ấy. Thông tin xác thực bản thân nó có thể được sử dụng trên chuỗi hoặc ngoài chuỗi, tùy thuộc vào ứng dụng. Tóm lại, người đi vay có thể cung cấp thông tin cần thiết cho người cho vay về tín dụng của họ. lịch sử có tính toàn vẹn cao và không có nguy cơ phơi bày những thông tin nhạy cảm, không cần thiết dữ liệu. Người vay cũng có thể cung cấp nhiều loại thông tin xác thực bảo mật khác hữu ích trong việc đưa ra quyết định cho vay. Ví dụ: thông tin xác thực có thể chứng thực quyền sở hữu của người đi vay sở hữu tài sản (ngoài chuỗi), như chúng tôi trình bày trong ví dụ tiếp theo. Ứng dụng ví dụ: Chứng nhận: Nhiều khu vực pháp lý giới hạn loại nhà đầu tư có thể bán chứng khoán chưa đăng ký. Ví dụ: ở Mỹ, SEC Quy định D quy định rằng để được công nhận cho những cơ hội đầu tư như vậy, cá nhân phải sở hữu tài sản ròng trị giá 1 triệu USD, đáp ứng các yêu cầu về thu nhập tối thiểu nhất định hoặc có trình độ chuyên môn nhất định [209, 210]. Sự công nhận hiện tại các quy trình rườm rà và kém hiệu quả, thường đòi hỏi phải có thư xác nhận từ kế toán viên hoặc bằng chứng tương tự. Một hệ thống nhận dạng phi tập trung sẽ cho phép người dùng tạo thông tin xác thực từ các tài khoản dịch vụ tài chính trực tuyến hiện có chứng minh sự tuân thủ chứng nhận các quy định, tạo điều kiện cho quy trình KYC hiệu quả hơn và bảo vệ quyền riêng tư hơn. các Hơn nữa, các đặc tính bảo vệ quyền riêng tư của DECO và Town Crier sẽ cho phép những điều này thông tin xác thực được tạo với sự đảm bảo mạnh mẽ về tính toàn vẹn mà không tiết lộ trực tiếp chi tiết về tình trạng tài chính của người dùng. Ví dụ: người dùng có thể tạo thông tin xác thực chứng minh rằng cô ấy có tài sản ròng ít nhất là 1 triệu đô la mà không tiết lộ thêm bất kỳ điều gì thông tin về tình trạng tài chính của cô ấy. 4.4 Kênh ưu tiên Kênh ưu tiên là một dịch vụ mới hữu ích, dễ xây dựng bằng DON. của họ
Mục tiêu là cung cấp các giao dịch có chọn lọc, có mức độ ưu tiên cao một cách kịp thời trên MAINCHAIN trong thời gian tắc nghẽn mạng. Các kênh ưu tiên có thể được xem như một dạng hợp đồng tương lai trên không gian khối và do đó là một loại tiền điện tử, một thuật ngữ được đặt ra như một phần của Dự án Chicago [61, 136]. Các kênh ưu tiên được dành riêng cho người khai thác để kích hoạt các dịch vụ cơ sở hạ tầng, chẳng hạn như oracles, chức năng quản trị cho hợp đồng, v.v.—không dành cho các hoạt động ở cấp độ người dùng thông thường như giao dịch tài chính. Trên thực tế, như được thiết kế ở đây, ưu tiên kênh được thực hiện bởi ít hơn 100% công suất khai thác trong mạng chỉ có thể cung cấp các giới hạn lỏng lẻo về thời gian giao hàng, ngăn cản việc sử dụng nó cho các hoạt động phụ thuộc nhiều vào tốc độ các mục tiêu như chạy trước. Hình 10: Kênh ưu tiên là sự đảm bảo của người khai thác M—hay nói chung hơn là một tập hợp các công cụ khai thác M—cho người dùng U rằng giao dịch τ của cô ấy sẽ được khai thác trong các khối D đưa vào mempool. SC hợp đồng có thể sử dụng giám sát DON để thực thi điều khoản dịch vụ của kênh. Kênh ưu tiên có dạng thỏa thuận giữa người khai thác hoặc tập hợp người khai thác (hoặc nhóm khai thác) M cung cấp kênh và người dùng U trả phí để truy cập. M đồng ý rằng khi U gửi giao dịch τ tới mempool (với bất kỳ giá gas nào,nhưng giới hạn gas đã được thỏa thuận trước), M sẽ đặt nó trên chuỗi trong các khối D tiếp theo.8 Ý tưởng này được mô tả dưới dạng sơ đồ trong Hình 10. Mô tả hợp đồng kênh ưu tiên: Một kênh ưu tiên có thể được thực hiện như một lai smart contract đại khái như sau. Chúng tôi để SC biểu thị logic trên MAINCHAIN và điều đó trên DON bởi người thực thi. SC chấp nhận khoản tiền gửi / cổ phần \(d from M and an advance payment \)p từ U. A DON người thực thi thực thi giám sát mempool, kích hoạt vị trí của giao dịch bởi U. Nó gửi thông báo thành công tới SC nếu U gửi giao dịch mà M khai thác một cách kịp thời và một thông báo lỗi trong trường hợp dịch vụ bị lỗi. SC gửi khoản thanh toán $p tới M với thông báo thành công và gửi tất cả số tiền còn lại, bao gồm $d, tới U nếu nó nhận được thông báo lỗi. Sau khi chấm dứt thành công, nó phát hành khoản tiền gửi $d cho M. Tất nhiên, công cụ khai thác M có thể cung cấp các kênh ưu tiên đồng thời cho nhiều người dùng và có thể mở kênh ưu tiên bằng U cho số lượng tin nhắn đã thỏa thuận trước. 4,5 Bảo quản bí mật DeFi / Hỗn hợp Ngày nay, DeFi ứng dụng [1] cung cấp rất ít hoặc không có tính bảo mật cho người dùng: Tất cả các giao dịch đều hiển thị trên chuỗi. Các cách tiếp cận dựa trên kiến thức không khác nhau, ví dụ: [149, 217], có thể cung cấp quyền riêng tư cho giao dịch và TEF đủ chung để hỗ trợ chúng. Nhưng những cách tiếp cận này không toàn diện và chẳng hạn, thường không che giấu được tài sản mà giao dịch dựa trên đó. Tập hợp rộng rãi các công cụ tính toán mà chúng tôi dự định hỗ trợ trong DONs sẽ cho phép quyền riêng tư theo một số cách khác nhau có thể lấp đầy những khoảng trống đó, giúp bổ sung cho việc đảm bảo quyền riêng tư của các hệ thống khác. Ví dụ: Mixicles, một công cụ bảo mật DeFi được đề xuất bởi Chainlink Các nhà nghiên cứu của Labs [135], có thể che giấu loại tài sản hỗ trợ một công cụ tài chính và rất phù hợp với DON khuôn khổ. Hỗn hợp được giải thích dễ dàng nhất về mặt sử dụng của chúng để nhận ra một hệ nhị phân đơn giản tùy chọn. Quyền chọn nhị phân là một công cụ tài chính trong đó hai người dùng, chúng ta sẽ tham khảo tại đây để biết tính nhất quán với [135] với tư cách là người chơi, đặt cược vào một sự kiện có hai khả năng kết quả, ví dụ: liệu một tài sản có vượt quá giá mục tiêu tại một thời điểm được chỉ định trước hay không. Ví dụ sau đây minh họa ý tưởng. Ví dụ 2. Alice và Bob là các bên tham gia quyền chọn nhị phân dựa trên giá trị của tài sản được gọi là Mã thông báo bong bóng của Carol (CBT). Alice đặt cược rằng CBT sẽ có giá thị trường ở mức tối thiểu 250 USD vào thời điểm T = trưa ngày 21/6/2025; Bob đặt cược ngược lại. Mỗi người chơi gửi 100 ETH theo thời hạn định trước. Người chơi có vị trí chiến thắng nhận được 200 ETH (tức là tăng 100 ETH). 8D tất nhiên phải đủ lớn để đảm bảo M có thể tuân thủ với xác suất cao. cho Chẳng hạn, nếu M kiểm soát 20% công suất khai thác trong mạng, nó có thể chọn D = 100, đảm bảo xác suất thất bại là ≈2 × 10−10, tức là nhỏ hơn một phần tỷ.Với Chainlink oracle mạng O hiện có, thật dễ dàng để triển khai một mạng thông minh hợp đồng SC thực hiện thỏa thuận trong Ví dụ 2. Hai người chơi mỗi bên gửi tiền 100 ETH trong SC. Một thời gian sau T, một truy vấn q được gửi đến O yêu cầu giá r của CBT tại thời điểm T. O gửi báo cáo r về mức giá này cho SC. SC sau đó gửi tiền cho Alice nếu r ≥250 và Bob nếu không. Tuy nhiên, cách tiếp cận này tiết lộ r trên chuỗi—làm cho việc này trở nên dễ dàng để người quan sát suy ra tài sản cơ bản của tùy chọn nhị phân. Trong thuật ngữ của Mixicles, sẽ rất hữu ích khi nghĩ về kết quả một cách khái niệm của SC dưới dạng Switch truyền giá trị nhị phân được tính toán dưới dạng vị từ chuyển đổi (r). Trong ví dụ của chúng tôi, switch(r) = 0 nếu r ≥250; với kết quả này, Alice thắng. Ngược lại switch(r) = 1 và Bob thắng. DON có thể nhận ra Mixicle cơ bản dưới dạng hợp đồng kết hợp bằng cách chạy một tệp thực thi exec tính toán switch(r) và báo cáo nó trên chuỗi cho SC. Chúng tôi hiển thị công trình này trong hình 11. Hình 11: Sơ đồ Mixicle cơ bản trong Ví dụ 2. Để cung cấp bí mật trên chuỗi cho báo cáo r và do đó, nội dung cơ bản của tùy chọn nhị phân, oracle sẽ gửi tới hợp đồng SC thông qua Chỉ chuyển đổi giá trị nhị phân switch(r). Chúng tôi chỉ định một bộ chuyển đổi ConfSwitch trong Phụ lục C.3 để giúp bạn dễ dàng đạt được điều này mục tiêu trong DON. Ý tưởng cơ bản đằng sau ConfSwitch khá đơn giản. Thay vì báo cáo giá trị r, ConfSwitch chỉ báo cáo giá trị chuyển đổi nhị phân switch(r). SC có thể được thiết kế để thực hiện thanh toán chính xác chỉ dựa trên switch(r) và chính switch(r) không tiết lộ thông tin nào về tài sản cơ bản—CBT trong ví dụ của chúng tôi. Ngoài ra, bằng cách đặt một bản mã vào (q, r) trên sổ cái được mã hóa bằng pkaud, khóa chung của kiểm toán viên, bộ điều hợp ConfSwitch tạo ra một quy trình kiểm tra bảo mật. Mixicle cơ bản mà chúng tôi đã chọn để mô tả đơn giản ở đây chỉ che giấu tài sản và đặt cược đằng sau tùy chọn nhị phân trong ví dụ của chúng tôi. Một Mixicle toàn diện [135] có thể cung cấp hai hình thức bảo mật. Nó che giấu những người quan sát: (1) Sự kiện gì người chơi đặt cược vào (tức là q và r) nhưng cũng có (2) Người chơi nào đã thắng cược. Vì Mixicles được thực thi trên MAINCHAIN nên một trong hai người chơi sẽ cần chuyển tiếp switch(r) từ DON sang MAINCHAIN hoặc có thể tạo một trình thực thi thực thi được
được kích hoạt ở đầu ra bởi ConfSwitch và gọi một bộ chuyển đổi khác để gửi switch(r) tới CHUỖI MAIN. Loại bảo mật tinh tế thứ ba cũng đáng được xem xét. Trong quá trình triển khai cơ bản của ConfSwitch, O đang chạy bộ điều hợp trên DON và do đó học được tài sản—CBT trong ví dụ của chúng tôi—và do đó là bản chất của quyền chọn nhị phân. Như đã thảo luận tuy nhiên, trong Phụ lục C.3, có thể sử dụng thêm DECO hoặc Town Crier để che giấu ngay cả thông tin này với O. Trong trường hợp này, O không biết thêm thông tin hơn là một người quan sát công khai của SC. Để biết thêm chi tiết về Mixicles, chúng tôi giới thiệu độc giả tới [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 قد يسمح البيع بمعاملة واحدة فقط لكل مستخدم مسجل، حيث يتم التسجيل يتطلب إثباتًا على تفرد المعرف الوطني، مثل رقم الضمان الاجتماعي. مثل هذا النهج ليس مضمونا، ولكنه قد يكون سياسة مفيدة للتخفيف من هجمات غمر المعاملات.
Dịch vụ sắp xếp công bằng
Một dịch vụ quan trọng mà chúng tôi mong đợi DON sẽ cung cấp nhằm tận dụng khả năng kết nối mạng, tính toán và lưu trữ của họ được gọi là Dịch vụ tuần tự công bằng (FSS). Mặc dù FSS có thể được xem đơn giản là một ứng dụng được triển khai trong khuôn khổ DON nhưng chúng tôi nhấn mạnh đây là một dịch vụ mà chúng tôi tin rằng sẽ có nhu cầu cao trên toàn thế giới. blockchains và chúng tôi mong đợi mạng Chainlink sẽ tích cực hỗ trợ. Khi được thực thi trên các mạng blockchain công cộng, nhiều ứng dụng DeFi ngày nay tiết lộ thông tin mà người dùng có thể khai thác vì lợi ích riêng của họ, tương tự như các loại rò rỉ nội bộ và các cơ hội thao túng đang tràn lan trong thị trường [64, 155]. Thay vào đó, FSS mở đường hướng tới một hệ sinh thái DeFi công bằng. FSS giúp các nhà phát triển xây dựng các hợp đồng DeFi được bảo vệ khỏi sự thao túng thị trường do rò rỉ thông tin. Với những vấn đề chúng tôi nêu dưới đây, FSS là đặc biệt hấp dẫn đối với các dịch vụ lớp 2 và phù hợp trong khuôn khổ các dịch vụ đó mà chúng ta thảo luận ở Phần 6. Thử thách: Trong các hệ thống không được phép hiện có, các giao dịch được sắp xếp hoàn toàn theo quyết định của thợ mỏ. Trong các mạng được phép, các nút validator có thể phát huy tác dụng sức mạnh như nhau. Đây là một hình thức tập trung nhất thời phần lớn không được công nhận trong các hệ thống phi tập trung khác. Người khai thác có thể (tạm thời) kiểm duyệt các giao dịch của mình lợi ích riêng [171] hoặc sắp xếp lại chúng để tối đa hóa lợi ích của chính nó, một khái niệm được gọi là giá trị có thể khai thác được (MEV) [90]. Thuật ngữ MEV hơi gây nhầm lẫn: Nó không đề cập đến chỉ với giá trị mà người khai thác có thể nắm bắt: Một số MEV có thể được người dùng thông thường nắm bắt. Tuy nhiên, do thợ đào có nhiều quyền lực hơn người dùng thông thường nên MEV đại diện cho giới hạn trên về lượng giá trị mà bất kỳ thực thể nào có thể có được thông qua việc sắp xếp lại đối nghịch. và chèn giao dịch bổ sung. Ngay cả khi thợ mỏ yêu cầu giao dịch một cách đơn giản dựa trên phí (gas), không cần thao túng, người dùng có thể tự mình thao túng giá gas để tạo thuận lợi cho các giao dịch của họ so với những giao dịch kém tinh vi hơn. Daian và cộng sự. [90] ghi lại và định lượng các cách mà bot (không phải thợ mỏ) thực hiện lợi dụng động lực học khí theo cách gây hại cho người dùng hệ thống DeFi ngày nay và cách thức MEV thậm chí còn đe dọa sự ổn định của lớp đồng thuận cơ bản trong blockchain. Các ví dụ khác về thao túng lệnh giao dịch thường xuyên xuất hiện, ví dụ: [50, 154].Các phương thức xử lý giao dịch mới như rollups là một cách tiếp cận rất hứa hẹn đối với các vấn đề mở rộng quy mô của blockchains thông lượng cao. Tuy nhiên, họ không đề cập đến vấn đề MEV Thay vào đó, họ chuyển nó sang thực thể tạo ra rollup. Đó thực thể, dù là người vận hành smart contract hay người dùng cung cấp (zk-)rollup với bằng chứng hợp lệ, có quyền ra lệnh và chèn các giao dịch. Nói cách khác, rollups hoán đổi MEV lấy REV: Giá trị có thể trích xuất tổng hợp. MEV ảnh hưởng đến các giao dịch sắp tới đã được gửi tới mempool nhưng chưa được cam kết trên chuỗi. Thông tin về các giao dịch như vậy được phổ biến rộng rãi có sẵn trong mạng. Người khai thác, validator và người tham gia mạng thông thường có thể do đó khai thác kiến thức này và tạo ra các giao dịch phụ thuộc. Ngoài ra, người khai thác và validator có thể ảnh hưởng đến thứ tự của các giao dịch mà họ thực hiện và khai thác điều này để có lợi cho mình. Vấn đề ảnh hưởng quá mức của lãnh đạo đến việc sắp xếp giao dịch theo sự đồng thuận các giao thức đã được biết đến trong tài liệu từ những năm 1990 [71, 190], nhưng chưa thỏa mãn các giải pháp đã được hiện thực hóa trong thực tế cho đến nay [97]. Lý do chính là các giải pháp được đề xuất – ít nhất cho đến gần đây – không thể dễ dàng tích hợp với các giải pháp công cộng. blockchains, vì chúng dựa vào nội dung của các giao dịch được giữ bí mật cho đến sau đó thứ tự của chúng đã được xác định. Tổng quan về Dịch vụ tuần tự công bằng (FSS): DONs sẽ cung cấp các công cụ để phân cấp việc đặt hàng giao dịch và triển khai nó theo chính sách được chỉ định bởi một cơ quan phụ thuộc người tạo hợp đồng, lý tưởng nhất là người tạo ra hợp đồng công bằng và không mang lại lợi ích cho những người muốn Thao tác đặt hàng giao dịch. Nói chung, các công cụ này tạo thành FSS. FSS bao gồm ba thành phần. Đầu tiên là giám sát các giao dịch. Trong FSS, Các nút oracle trong O đều giám sát bộ nhớ của MAINCHAIN và cho phép (nếu muốn) gửi các giao dịch ngoài chuỗi thông qua một kênh chuyên biệt. Thứ hai là trình tự các giao dịch. Các nút trong giao dịch theo thứ tự O cho một hợp đồng dựa trên theo chính sách được xác định cho hợp đồng đó. Thứ ba là đăng tải các giao dịch. Sau khi các giao dịch được sắp xếp, các nút trong O cùng nhau gửi các giao dịch đến chuỗi chính. Những lợi ích tiềm năng của FSS bao gồm: • Tính công bằng của đơn hàng: FSS bao gồm các công cụ giúp nhà phát triển đảm bảo rằng các giao dịch đầu vào của một hợp đồng cụ thể được sắp xếp theo cách không gây ra sự thiếu công bằng lợi thế cho người dùng có nguồn lực tốt và/hoặc hiểu biết về kỹ thuật. Chính sách đặt hàng có thể được chỉ định cho mục đích này. • Giảm hoặc loại bỏ rò rỉ thông tin: Bằng cách đảm bảo rằng những người tham gia mạng không thể khai thác kiến thức về các giao dịch sắp tới, FSS có thể giảm bớt hoặc loại bỏ các cuộc tấn công như chạy trước dựa trên thông tin có sẵn trong mạng trước khi giao dịch được thực hiện. Ngăn chặn việc khai thác như vậy rò rỉ đảm bảo rằng các giao dịch đối nghịch phụ thuộc vào bản gốc đang chờ xử lý giao dịch không thể vào sổ cái trước khi giao dịch ban đầu được thực hiện.• Giảm chi phí giao dịch: Bằng cách loại bỏ yêu cầu của người chơi về tốc độ gửi giao dịch của họ tới smart contract, FSS có thể giảm đáng kể chi phí xử lý giao dịch. • Thứ tự ưu tiên: FSS có thể tự động ưu tiên đặc biệt cho các giao dịch quan trọng đặt hàng. Ví dụ: để ngăn chặn các cuộc tấn công trực tiếp chống lại oracle báo cáo, ví dụ: [79], FSS có thể chèn báo cáo oracle vào luồng giao dịch hồi tố. Mục tiêu bao quát của FSS trong DONs là trao quyền cho DeFi người sáng tạo để thực hiện công bằng hệ thống tài chính, nghĩa là các hệ thống không mang lại lợi ích cho người dùng (hoặc thợ mỏ) cụ thể hơn người khác trên cơ sở tốc độ, kiến thức nội bộ hoặc khả năng thực hiện kỹ thuật thao túng. Trong khi một khái niệm chung chung và sắc nét về sự công bằng là khó nắm bắt, thì sự công bằng hoàn hảo trong mọi ý nghĩa hợp lý đều không thể đạt được, FSS nhằm mục đích cung cấp cho các nhà phát triển một giải pháp mạnh mẽ bộ công cụ để họ có thể thực thi các chính sách giúp đáp ứng mục tiêu thiết kế của họ cho DeFi. Chúng tôi lưu ý rằng mặc dù mục tiêu chính của FSS là hoạt động như một dịch vụ giải trình tự công bằng cho MAINCHAIN mà DON nhắm tới, một số mong muốn công bằng tương tự như FSS đảm bảo cũng có thể phù hợp với các giao thức (phi tập trung) được chạy giữa DON bữa tiệc. Do đó, FSS có thể được xem rộng hơn như một dịch vụ được cung cấp bởi một tập hợp con trong số DON nút có trình tự khá hợp lý, không chỉ các giao dịch được gửi bởi người dùng MAINCHAIN mà còn cả các giao dịch (tức là tin nhắn) được chia sẻ giữa các nút DON khác. Trong phần này, chúng tôi sẽ tập trung chủ yếu vào mục tiêu sắp xếp thứ tự các giao dịch MAINCHAIN. Tổ chức phần: Trong Phần 5.1, chúng tôi mô tả hai ứng dụng cấp cao thúc đẩy thiết kế FSS: ngăn chặn việc chạy trước các báo cáo oracle và ngăn chặn chạy trước các giao dịch của người dùng. Sau đó chúng tôi cung cấp thêm chi tiết về thiết kế của FSS trong Phần 5.2. Phần 5.3 mô tả các ví dụ về đảm bảo trật tự công bằng và các biện pháp để đạt được chúng. Cuối cùng, Phần 5.4 và Phần 5.5 thảo luận về các mối đe dọa ở cấp độ mạng đối với các chính sách và phương tiện đó để giải quyết chúng, tương ứng với tình trạng tràn mạng và Sybil các cuộc tấn công. 5.1 Vấn đề chạy trước Để giải thích các mục tiêu và thiết kế của FSS, chúng tôi mô tả hai dạng chung của hoạt động chạy trước các cuộc tấn công và những hạn chế của các giải pháp hiện có. Chạy trước minh họa một lớp về các cuộc tấn công đặt hàng giao dịch: Có một số cuộc tấn công liên quan như chạy ngược và xen kẽ (chạy trước và chạy sau) [237] mà chúng tôi không đề cập đến ở đây, nhưng FSS nào cũng giúp giải quyết. 5.1.1 Oracle chạy trước Với vai trò truyền thống là cung cấp dữ liệu ngoài chuỗi cho blockchain ứng dụng, oracles trở thành mục tiêu tự nhiên cho các cuộc tấn công trực diện.Hãy xem xét mẫu thiết kế phổ biến về việc sử dụng oracle để cung cấp các nguồn cấp dữ liệu giá khác nhau đến trao đổi trên chuỗi: định kỳ (giả sử mỗi giờ), oracle thu thập dữ liệu giá cho các tài sản khác nhau và gửi chúng tới một hợp đồng trao đổi. Các giao dịch dữ liệu giá này đưa ra các cơ hội chênh lệch giá rõ ràng: Ví dụ: nếu báo cáo oracle mới nhất liệt kê giá cao hơn nhiều cho một số nội dung, đối thủ có thể chạy trước báo cáo oracle tới mua tài sản và bán lại ngay sau khi báo cáo của oracle được xử lý. Giảm tốc độ và định giá hồi tố: Một giải pháp tự nhiên cho vấn đề chạy trước oracle là ưu tiên đặc biệt cho các báo cáo của oracle so với các giao dịch khác. cho ví dụ: oracle báo cáo có thể được gửi với mức phí cao để khuyến khích người khai thác xử lý họ đầu tiên. Nhưng điều này sẽ không ngăn cản việc chạy trước nếu cơ hội kinh doanh chênh lệch giá cao, nó cũng không thể ngăn chặn sự chênh lệch giá của chính những người khai thác. Do đó, một số sàn giao dịch đã phải sử dụng đến việc triển khai các “tốc độ tăng tốc” nặng nề hơn, chẳng hạn như xếp hàng các giao dịch của người dùng cho một số khối trước khi xử lý. chúng hoặc điều chỉnh giá trở về trước khi có báo cáo oracle mới. Nhược điểm của các giải pháp này là chúng làm tăng thêm độ phức tạp cho việc thực hiện trao đổi, tăng yêu cầu lưu trữ và do đó chi phí giao dịch, đồng thời làm gián đoạn trải nghiệm người dùng vì việc trao đổi tài sản chỉ được xác nhận sau một khoảng thời gian đáng kể. Cõng: Trước khi chuyển sang FSS, chúng ta thảo luận về việc cõng, một cách khá đơn giản và giải pháp tinh tế cho vấn đề chạy trước oracle. Nó không áp dụng cho địa chỉ Tuy nhiên, chạy trước trong các tình huống khác. Tóm lại, thay vì gửi báo cáo định kỳ tới hợp đồng trên chuỗi, oracles xuất bản các báo cáo đã ký mà người dùng thêm vào giao dịch của họ khi mua hoặc bán tài sản trên chuỗi. Sau đó, sàn giao dịch chỉ cần kiểm tra xem báo cáo có hợp lệ và mới không (ví dụ: oracle có thể ký một phạm vi khối mà báo cáo hợp lệ) và trích xuất nguồn cấp dữ liệu giá có liên quan từ nó. Cách tiếp cận đơn giản này có một số ưu điểm so với cách “tăng tốc” ở trên cách tiếp cận: (1) Hợp đồng trao đổi không cần giữ trạng thái nguồn cấp giá, điều này sẽ dẫn đến chi phí giao dịch thấp hơn; (2) Vì các báo cáo oracle được đăng trên chuỗi khi cần thiết, oracles có thể tạo ra các cập nhật thường xuyên hơn (ví dụ: mỗi phút), do đó giảm thiểu cơ hội chênh lệch giá từ việc chạy trước một báo cáo9; (3) Giao dịch có thể được xác thực ngay lập tức vì chúng luôn bao gồm nguồn cấp dữ liệu giá mới. Tuy nhiên, cách tiếp cận này không hoàn hảo. Đầu tiên, giải pháp cõng này đặt trách nhiệm của người dùng sàn giao dịch là tìm nạp các báo cáo oracle cập nhật và đính kèm chúng vào giao dịch. Thứ hai, mặc dù việc cõng làm giảm thiểu cơ hội kinh doanh chênh lệch giá nhưng nó không thể ngăn chặn hoàn toàn chúng mà không ảnh hưởng đến tính tồn tại của hợp đồng trên chuỗi. Thật vậy, nếu một oracle báo cáo có hiệu lực cho đến khi khối số n nào đó, sau đó giao dịch được gửi tới khối n + 1 sẽ yêu cầu một báo cáo hợp lệ mới. Do sự chậm trễ cố hữu trong việc truyền bá báo cáo từ oracle tới người dùng, báo cáo mới hợp lệ cho khối n + 1 sẽ có 9 Kinh doanh chênh lệch giá chỉ có giá trị nếu chênh lệch có thể khai thác được trong giá tài sản vượt quá chênh lệch không liên quan phí cần thiết để mua và bán tài sản, ví dụ: phí do người khai thác và sàn giao dịch thu.được công bố một khoảng thời gian trước khi khối n + 1 được khai thác, chẳng hạn tại khối n −k, do đó tạo ra một chuỗi k khối trong đó tồn tại cơ hội chênh lệch giá trong thời gian ngắn. Chúng tôi bây giờ hãy mô tả cách FSS khắc phục những hạn chế này. Ưu tiên oracle báo cáo với FSS: FSS có thể giải quyết oracle chạy trước vấn đề bằng cách xây dựng dựa trên giải pháp hỗ trợ ở trên nhưng đẩy mạnh thêm công việc tăng cường các giao dịch với oracle báo cáo cho Mạng Oracle phi tập trung. Ở mức cao, các nút oracle thu thập các giao dịch dành cho trao đổi trên chuỗi, đồng ý về nguồn cấp giá theo thời gian thực và đăng nguồn cấp giá cùng với các giao dịch đã thu thập lên hợp đồng chuỗi chính. Về mặt khái niệm, người ta có thể coi cách tiếp cận này như một “phân nhóm giao dịch tăng cường dữ liệu”, trong đó oracle đảm bảo rằng giao dịch được cập nhật nguồn cấp dữ liệu giá luôn được thêm vào các giao dịch. Các giải pháp FSS có thể được triển khai một cách minh bạch cho người dùng sàn giao dịch và với những thay đổi tối thiểu đối với logic hợp đồng, như chúng tôi mô tả chi tiết hơn trong Phần 5.2. Đảm bảo các báo cáo oracle mới luôn được ưu tiên hơn các giao dịch của người dùng chỉ là một ví dụ của chính sách đặt hàng mà FSS có thể áp dụng và thực thi. Chính sách của FSS nhằm đảm bảo trật tự sự công bằng được mô tả tổng quát hơn ở Phần 5.3. 5.1.2 Giao dịch người dùng chạy trước Bây giờ chúng ta chuyển sang chạy trước trong các ứng dụng chung, trong đó phương pháp bảo vệ ở trên không hoạt động. Vấn đề có thể được nắm bắt rộng rãi thông qua kịch bản sau: Kẻ tấn công nhìn thấy một số giao dịch tx1 của người dùng được gửi vào mạng P2P và tiêm vào giao dịch đối nghịch tx2 của chính nó, do đó tx2 được xử lý trước tx1 (ví dụ: bằng cách thanh toán phí giao dịch cao hơn). Ví dụ, kiểu chạy trước này phổ biến ở các bot khai thác cơ hội chênh lệch giá trong DeFi hệ thống [90] và đã ảnh hưởng đến người dùng các ứng dụng phi tập trung khác nhau [101]. Thiết lập trật tự công bằng giữa các giao dịch được xử lý trên blockchain sẽ giải quyết được vấn đề này. Cơ bản hơn, việc xem chi tiết tx1 đôi khi còn không cần thiết và biết về sự tồn tại đơn thuần của nó có thể cho phép kẻ thù chiếm ưu thế trước tx1 thông qua nó. sở hữu tx2 và lừa gạt người dùng vô tội đã tạo ra tx1. Ví dụ, người dùng có thể được biết là giao dịch một tài sản cụ thể vào thời điểm thường xuyên. Ngăn chặn các cuộc tấn công như vậy đòi hỏi các biện pháp giảm thiểu cũng tránh rò rỉ siêu dữ liệu [62]. Một số giải pháp cho vấn đề này tồn tại, nhưng chúng gây ra sự chậm trễ và những lo ngại về khả năng sử dụng. Từ đơn hàng mạng đến đơn hàng cuối cùng với FSS: Cơ hội đi trước phát sinh do các hệ thống hiện tại không có cơ chế để đảm bảo rằng thứ tự trong đó các giao dịch xuất hiện trên chuỗi tôn trọng thứ tự của các sự kiện và luồng thông tin bên ngoài mạng. Điều này thể hiện sự cố phát sinh từ những thiếu sót trong việc triển khai ứng dụng (ví dụ: nền tảng giao dịch) trên blockchain. Lý tưởng nhất là người ta sẽ đảm bảo rằng các giao dịch được cam kết trên blockchain theo đúng thứ tự như trước đây được tạo và gửi tới mạng P2P của blockchain. Nhưng vì mạng blockchain
được phân phối thì không thể nắm bắt được thứ tự như vậy. Do đó FSS giới thiệu các cơ chế
để bảo vệ khỏi những hành vi vi phạm sự công bằng phát sinh chỉ vì sự phân bổ
bản chất của mạng blockchain.
5.2
Chi tiết FSS
Hình 12:
Mempool hợp lý với hai đường dẫn giao dịch khác nhau:
trực tiếp và
dựa trên mempool.
Hình 12 thể hiện sơ đồ chung của FSS. Để đảm bảo tính công bằng, DON cung cấp FSS phải can thiệp vào luồng giao dịch khi chúng tham gia MAINCHAIN.
Có thể cần phải điều chỉnh đối với khách hàng, đối với smart contract trên MAINCHAIN hoặc đối với cả hai. Ở mức độ cao, việc xử lý các giao dịch bằng FSS có thể được chia thành ba
các giai đoạn được mô tả dưới đây: (1) Giám sát giao dịch; (2) Trình tự giao dịch; và
(3) Đăng tải giao dịch. Tùy thuộc vào phương thức đặt hàng được sử dụng để sắp xếp trình tự giao dịch, cần có các bước giao thức bổ sung, như được mô tả trong phần tiếp theo.
5.2.1
Xử lý giao dịch
Giám sát giao dịch:
Chúng tôi hình dung ra hai cách tiếp cận khác nhau để FSS giám sát
giao dịch của người dùng dành cho một smart contract cụ thể, trực tiếp và dựa trên mempool:
• Trực tiếp: Cách tiếp cận trực tiếp đơn giản nhất về mặt khái niệm nhưng đòi hỏi phải thay đổi
khách hàng người dùng để các giao dịch được gửi trực tiếp đến Oracle phi tập trungCác nút mạng, thay vì các nút của chuỗi chính. DON thu thập
giao dịch của người dùng hướng đến một smart contract SC cụ thể và sắp xếp chúng dựa trên
về một số chính sách đặt hàng. DON sau đó gửi các giao dịch đã đặt hàng tới
smart contract trên chuỗi chính. Một số cơ chế đặt hàng cũng yêu cầu cách tiếp cận trực tiếp vì người dùng tạo giao dịch phải sử dụng mật mã
bảo vệ nó trước khi gửi nó đến FSS.
• Dựa trên Mempool: Để tạo điều kiện thuận lợi cho việc tích hợp FSS với các máy khách cũ, DON
có thể sử dụng Dịch vụ Mempool (MS) để giám sát mempool của chuỗi chính và thu thập
giao dịch.
Truyền trực tiếp có thể là cách thực hiện được ưu tiên cho nhiều hợp đồng,
và chúng tôi tin rằng nó sẽ khá thực tế trong nhiều trường hợp.
Chúng tôi thảo luận ngắn gọn về cách các DApp hiện tại có thể được sửa đổi ở mức tối thiểu để hỗ trợ
truyền trực tiếp trong khi vẫn duy trì trải nghiệm tốt cho người dùng. Chúng tôi mô tả các phương pháp tiếp cận
sử dụng Ethereum và MetaMask [6] vì đây là những lựa chọn phổ biến nhất hiện nay, nhưng
các kỹ thuật được đề cập sẽ mở rộng sang các chuỗi và ví khác. Ethereum gần đây
Đề xuất cải tiến, “EIP-3085: Ví thêm Ethereum phương thức RPC chuỗi” [100],
sẽ giúp dễ dàng nhắm mục tiêu các chuỗi Ethereum tùy chỉnh (sử dụng ID CHAIN khác với
của MAINCHAIN để ngăn chặn các cuộc tấn công lặp lại) từ MetaMask và các ví dựa trên trình duyệt khác. Sau khi triển khai đề xuất này, DApp đang tìm cách sử dụng DON
chỉ cần thêm một lệnh gọi phương thức vào giao diện người dùng của họ để có thể truyền trực tiếp
giao dịch với bất kỳ DON nào có API tương thích với Ethereum. Trong khi đó,
“EIP-712: Ethereum đã nhập dữ liệu có cấu trúc hash nhập và ký” [49] cung cấp một chút
giải pháp thay thế có liên quan nhiều hơn nhưng đã được triển khai rộng rãi, nơi người dùng DApp có thể sử dụng
MetaMask để ký dữ liệu có cấu trúc chỉ định giao dịch DON. DApp có thể gửi
dữ liệu có cấu trúc đã được ký này vào DON.
Cuối cùng, chúng tôi lưu ý rằng các phương pháp kết hợp cũng có thể thực hiện được.
Ví dụ, di sản
khách hàng có thể tiếp tục gửi giao dịch vào mempool của chuỗi chính, nhưng điều quan trọng là
các giao dịch (ví dụ: báo cáo oracle) được gửi trực tiếp đến DON nút (cụ thể là
tập hợp các nút cung cấp oracle báo cáo chẳng hạn như cập nhật nguồn cấp dữ liệu giá và tập hợp các nút
việc cung cấp FSS có thể trùng lặp hoặc giống hệt nhau).
Trình tự giao dịch:
Mục đích chính của FSS là đảm bảo rằng các giao dịch của người dùng được sắp xếp theo chính sách được xác định trước. Bản chất của chính sách này sẽ
tùy thuộc vào nhu cầu của ứng dụng và các loại lệnh giao dịch không công bằng mà nó
nhằm mục đích ngăn chặn.
Vì FSS trên DON có khả năng xử lý dữ liệu và duy trì trạng thái cục bộ,
họ có thể áp đặt chính sách sắp xếp thứ tự tùy ý dựa trên thông tin được
có sẵn tại oracles.
Các chính sách đặt hàng cụ thể và việc triển khai chúng sẽ được thảo luận sau trong Phần 5.3.Đăng giao dịch:
Sau khi thu thập và sắp xếp các giao dịch của người dùng, nhận trực tiếp từ người dùng hoặc được thu thập từ mempool, DON sẽ gửi các giao dịch này đến chuỗi chính. Do đó, các tương tác của DON với chuỗi chính vẫn được duy trì
tùy thuộc vào thứ tự giao dịch (có khả năng không công bằng) được quản lý bởi các thợ mỏ của chuỗi chính. Để khai thác lợi ích của việc đặt hàng giao dịch phi tập trung, mục tiêu thông minh
do đó, hợp đồng SC phải được thiết kế để đối xử với DON như một công dân “hạng nhất”. Chúng tôi
phân biệt hai cách tiếp cận:
• Hợp đồng chỉ DON: Tùy chọn thiết kế đơn giản nhất là có chuỗi chính thông minh
hợp đồng SC chỉ chấp nhận các giao dịch đã được xử lý bởi DON. Cái này
đảm bảo rằng smart contract xử lý các giao dịch theo thứ tự được đề xuất bởi
DON, nhưng trên thực tế hạn chế smart contract hoạt động trong hệ thống dựa trên ủy ban (tức là ủy ban DON hiện có quyền liên tục để xác định
đặt hàng và bao gồm các giao dịch).
• Hợp đồng hai lớp: Thiết kế được ưu tiên, chi tiết hơn có chuỗi chính thông minh
hợp đồng SC chấp nhận các giao dịch có nguồn gốc từ cả DON và từ kế thừa
người dùng,10 nhưng đặt những "gờ giảm tốc" truyền thống đối với các giao dịch không được DON xử lý. Ví dụ: các giao dịch từ DON có thể được xử lý
ngay lập tức, trong khi các giao dịch kế thừa được smart contract “đệm” cho
một khoảng thời gian nhất định. Các cơ chế tiêu chuẩn khác để ngăn chặn việc chạy trước
chẳng hạn như các kế hoạch tiết lộ cam kết hoặc VDF [53] cũng có thể được áp dụng cho các kế hoạch cũ
giao dịch. Điều này đảm bảo rằng các giao dịch theo thứ tự DON được xử lý trong
mệnh lệnh đã được thống nhất mà không trao cho DON quyền kiểm duyệt không mong muốn
giao dịch.
Do việc FSS áp dụng thứ tự giao dịch yêu cầu các giao dịch phải được tổng hợp “ngoài chuỗi”, nên giải pháp này được kết hợp một cách tự nhiên với các kỹ thuật tổng hợp khác nhằm giảm chi phí xử lý trên chuỗi. Ví dụ, sau khi thu thập và
đặt hàng các giao dịch, DON có thể gửi các giao dịch này đến chuỗi chính dưới dạng
"giao dịch theo đợt" duy nhất (ví dụ: rollup), do đó làm giảm giao dịch tổng hợp
phí.
Thực thi lệnh giao dịch:
Dù ở thiết kế chỉ DON hay thiết kế hai lớp,
chuỗi chính smart contract SC và DON phải được đồng thiết kế để đảm bảo rằng thứ tự giao dịch của DON được duy trì. Ở đây cũng vậy, chúng tôi hình dung khác nhau
tùy chọn thiết kế:
• Số thứ tự: DON có thể thêm số thứ tự vào mỗi giao dịch và gửi các giao dịch này vào mempool của chuỗi chính.
chính
10Nếu việc giám sát giao dịch của DON dựa trên mempool thì các giao dịch kế thừa phải được phân biệt với các giao dịch DON để chúng không bị DON thu thập, ví dụ: thông qua một thẻ đặc biệt
được nhúng vào giao dịch hoặc bằng cách chỉ định một mức giá gas cụ thể, ví dụ: DON giao dịch có gas
giá dưới một ngưỡng nhất định.chuỗi smart contract SC bỏ qua các giao dịch đến “không theo trình tự”. Chúng tôi
lưu ý rằng trong cài đặt này, người khai thác chuỗi chính có thể quyết định bỏ qua DON
đặt hàng giao dịch, do đó làm cho giao dịch thất bại. Có thể bằng cách giữ trạng thái (đắt) để SC thực thi thứ tự giao dịch chính xác, phần nào
tương tự như cách TCP đệm các gói không đúng thứ tự cho đến khi các gói bị thiếu được
đã nhận được.
• Giao dịch nonce: Đối với nhiều blockchain và đặc biệt đối với Ethereum,
Cách tiếp cận đánh số thứ tự ở trên có thể tận dụng giao dịch tích hợp nonces để
buộc chuỗi chính smart contract SC xử lý các giao dịch theo trình tự.
Tại đây, các nút DON gửi giao dịch đến chuỗi chính thông qua một tài khoản chuỗi chính duy nhất, được bảo vệ bằng khóa được chia sẻ giữa các nút DON. Tài khoản của
giao dịch nonce đảm bảo rằng các giao dịch được khai thác và xử lý theo đúng thứ tự.
• Tổng hợp các giao dịch: DON có thể tổng hợp nhiều giao dịch trong rollup
(hoặc trong một gói tương tự như rollup). Chuỗi chính smart contract cần phải được
được thiết kế để xử lý các giao dịch tổng hợp như vậy.
• Tổng hợp các giao dịch bằng proxy chuỗi chính: Ở đây, DON tương tự gói các giao dịch thành một “giao dịch meta” cho chuỗi chính, nhưng dựa vào một
proxy tùy chỉnh smart contract để giải nén các giao dịch và chuyển tiếp chúng tới
hợp đồng mục tiêu SC. Kỹ thuật này có thể hữu ích cho khả năng tương thích cũ. Siêu giao dịch hoạt động giống như rollup nhưng khác ở chỗ chúng bao gồm một giao dịch không nén
danh sách các giao dịch được đăng một lần lên chuỗi chính.
Thiết kế cuối cùng có ưu điểm là hỗ trợ liền mạch các giao dịch của người dùng
bản thân họ được ủy quyền thông qua hợp đồng chuỗi chính trước khi đạt được mục tiêu của DON
hợp đồng SC. Ví dụ: hãy xem xét một người dùng gửi giao dịch đến một số ví
hợp đồng, sau đó sẽ gửi một giao dịch nội bộ tới SC. Chỉ định một trình tự
số lượng giao dịch như vậy sẽ rất phức tạp, trừ khi hợp đồng ví của người dùng được
được thiết kế đặc biệt để chuyển tiếp số thứ tự với mọi giao dịch nội bộ tới
SC.
Tương tự, các giao dịch nội bộ như vậy không thể dễ dàng tổng hợp thành siêu giao dịch được gửi trực tiếp đến SC. Chúng tôi thảo luận thêm về những cân nhắc thiết kế cho
các giao dịch ủy quyền dưới đây.
5.2.2
Tính nguyên tử của giao dịch
Cuộc thảo luận của chúng ta cho đến nay đã ngầm giả định rằng các giao dịch tương tác với một
trên chuỗi smart contract (ví dụ: người dùng gửi yêu cầu mua tới một sàn giao dịch). Tuy nhiên, trong
các hệ thống như Ethereum, một giao dịch có thể bao gồm nhiều giao dịch nội bộ, ví dụ: một smart contract gọi một hàm trong một hợp đồng khác. Dưới đây, chúng tôi
mô tả hai chiến lược cấp cao để sắp xếp các giao dịch “nhiều hợp đồng”, trong khi
duy trì tính nguyên tử của giao dịch (tức là chuỗi hành động được quy định bởi
tất cả các giao dịch đều được thực hiện theo đúng thứ tự hoặc hoàn toàn không).Tính nguyên tử mạnh:
Giải pháp đơn giản nhất là áp dụng FSS, như được mô tả ở trên, trực tiếp cho toàn bộ giao dịch “nhiều hợp đồng”. Nghĩa là, người dùng gửi giao dịch của họ
vào mạng và FSS giám sát, sắp xếp và đăng các giao dịch này lên
chuỗi chính.
Cách tiếp cận này đơn giản về mặt kỹ thuật nhưng có một hạn chế tiềm ẩn: Nếu người dùng
giao dịch tương tác với hai hợp đồng SC1 và SC2 đều muốn tận dụng công bằng
các dịch vụ sắp xếp thứ tự thì chính sách sắp xếp thứ tự của hai hợp đồng này phải nhất quán. Nghĩa là, với hai giao dịch tx1 và tx2 khác nhau mà mỗi giao dịch tương tác với
cả SC1 và SC2, không được xảy ra trường hợp chính sách của SC1 đặt hàng tx1 trước tx2
trong khi chính sách của SC2 lại quy định thứ tự ngược lại.
Đối với phần lớn các kịch bản quan tâm, chúng tôi hình dung rằng các chính sách trình tự được áp dụng bởi các hợp đồng khác nhau sẽ nhất quán. Ví dụ: cả SC1 và SC2
có thể muốn các giao dịch được sắp xếp theo thời gian đến gần đúng của chúng trong mempool,
và SC1 có thể muốn một số báo cáo oracle nhất định luôn được gửi trước. Như
sau đó oracle báo cáo các giao dịch không tương tác với SC2, các chính sách đều nhất quán.
Tính nguyên tử yếu:
Nói chung, FSS có thể được áp dụng ở cấp độ cá nhân
giao dịch nội bộ.
Xét các giao dịch có dạng tx = { ˜txpre, ˜txSC, ˜txpost}, bao gồm một số giao dịch ban đầu
(các) giao dịch ˜txpre, dẫn đến một giao dịch nội bộ ˜txSC tới SC, do đó
phát hành (các) giao dịch nội bộ ˜txpost. Chính sách giải trình tự của SC có thể xác định cách thức
giao dịch nội bộ ˜txSC phải được sắp xếp theo các giao dịch khác được gửi
tới SC, nhưng để ngỏ thứ tự tuần tự cho txpre vàtxpost.
Do bản chất của việc xử lý giao dịch trong các hệ thống như Ethereum, việc phát triển dịch vụ tuần tự hướng tới các giao dịch nội bộ cụ thể không hề đơn giản. Với hợp đồng SC được thiết kế đặc biệt, điều này có thể được thực hiện như sau:
1. Giao dịch tx được gửi vào mạng và được khai thác (không có bất kỳ trình tự nào
được thực hiện bởi FSS). ˜txpre ban đầu được thực thi và gọi ˜txSC.
2. SC không thực thi txSC và trả về.
3. FSS giám sát các giao dịch nội bộ tới SC, sắp xếp chúng và gửi lại chúng
tới SC (tức là bằng cách gửi giao dịch ˜txSC trực tiếp đến SC).
4. SC xử lý các giao dịchtxSC nhận được từ FSS và phát hành các giao dịch nội bộ txpost phát sinh từtxSC.
Với cách tiếp cận này, các giao dịch không được thực hiện hoàn toàn nguyên tử (tức là giao dịch gốc
giao dịch tx được chia thành nhiều giao dịch trên chuỗi), nhưng thứ tự của
giao dịch nội bộ được bảo tồn.
Giải pháp này đòi hỏi một số hạn chế về thiết kế. Ví dụ: ‘txpre không thể
giả sử rằng ˜txSC và ˜txpost sẽ được thực thi. Hơn nữa, SC nên được thiết kế sao cho
thực hiện các giao dịch ˜txSC và ˜txpost thay mặt cho một người dùng nhất định, ngay cả khi họđược gửi bởi FSS. Vì những lý do này, giải pháp “Tính nguyên tử mạnh” chi tiết hơn
ở trên có thể thích hợp hơn trong thực tế.
Để tôn trọng sự phụ thuộc phức tạp hơn, liên quan đến nhiều giao dịch và
các giao dịch nội bộ tương ứng của họ, bộ lập lịch giao dịch của FSS có thể chứa
các chức năng phức tạp giống với các chức năng được tìm thấy trong các trình quản lý giao dịch của quan hệ
những người quản lý cơ sở dữ liệu.
5.3
Trình tự giao dịch công bằng
Ở đây chúng ta thảo luận về hai khái niệm về tính công bằng trong trình tự giao dịch và các triển khai tương ứng, có thể được FSS nhận ra: tính công bằng của trật tự dựa trên chính sách
do FSS áp đặt và bảo toàn quan hệ nhân quả, đòi hỏi các phương pháp mã hóa bổ sung trong FSS.
Trật tự-công bằng:
Công bằng trật tự là một khái niệm về sự công bằng tạm thời trong các giao thức đồng thuận
lần đầu tiên được giới thiệu chính thức bởi Kelkar et al. [144].
Kelkar và cộng sự. nhằm đạt được một hình thức chính sách tự nhiên trong đó các giao dịch được thực hiện
được sắp xếp dựa trên thời gian chúng được nhận lần đầu tiên bởi DON (hoặc mạng P2P,
trong trường hợp FSS dựa trên mempool). Tuy nhiên, trong một hệ thống phi tập trung, khác nhau
các nút có thể thấy các giao dịch đến theo thứ tự khác nhau.
Thiết lập một trật tự tổng thể
trên tất cả các giao dịch chính là vấn đề được giải quyết bằng giao thức đồng thuận cơ bản
CHUỖI MAIN.
Kelkar và cộng sự. [144] do đó đưa ra một khái niệm yếu hơn có thể
đạt được với sự trợ giúp của Mạng Oracle phi tập trung, được gọi là “sự công bằng theo thứ tự khối”.
Nó nhóm các giao dịch mà DON đã nhận được trong một khoảng thời gian thành một
“chặn” và chèn tất cả các giao dịch của khối một cách đồng thời và ở cùng một vị trí
(tức là chiều cao) vào MAINCHAIN. Do đó, chúng được sắp xếp cùng nhau và phải có thể thực thi được
song song mà không tạo ra bất kỳ xung đột nào giữa chúng.
Nói một cách đại khái, tính công bằng trật tự phát biểu rằng nếu một phần lớn các nút nhìn thấy giao dịch τ1 trước τ2, thì
τ1 sẽ được sắp xếp trước hoặc trong cùng khối với τ2. Bằng cách áp đặt một cách thô thiển như vậy
mức độ chi tiết của lệnh giao dịch, cơ hội cho các cuộc tấn công chạy trước và các cuộc tấn công liên quan đến lệnh khác sẽ giảm đi đáng kể.
Kelkar và cộng sự. đề xuất một họ giao thức có tên là Aequitas [144], địa chỉ
các mô hình triển khai khác nhau, bao gồm cài đặt mạng đồng bộ, đồng bộ một phần và không đồng bộ. Các giao thức Aequitas áp đặt chi phí liên lạc đáng kể so với sự đồng thuận cơ bản BFT và do đó không lý tưởng để sử dụng thực tế.
Tuy nhiên, chúng tôi tin rằng các biến thể thực tế của Aequitas sẽ xuất hiện và có thể được sử dụng
để giải trình tự giao dịch trong FSS và các ứng dụng khác. Một số sơ đồ liên quan có
đã được đề xuất có ít chủ nghĩa hình thức đi kèm hơn và các đặc tính yếu hơn,
ví dụ: [36, 151, 236], nhưng hiệu suất thực tế tốt hơn. Những kế hoạch này có thể được hỗ trợ
trong FSS cũng vậy.
Cũng cần lưu ý rằng thuật ngữ “công bằng” xuất hiện ở nơi khác trong blockchain
văn học với một ý nghĩa khác, cụ thể là sự công bằng trong ý nghĩa cơ hội chocông cụ khai thác tỷ lệ thuận với tài nguyên đã cam kết của họ [106, 181] hoặc cho validators tính theo
cơ hội bình đẳng [153].
Bảo toàn nhân quả:
Cách tiếp cận được biết đến rộng rãi nhất để ngăn chặn việc chạy trước và các hành vi vi phạm trật tự khác trong các nền tảng phân tán dựa vào mật mã.
kỹ thuật. Đặc điểm chung của chúng là ẩn dữ liệu giao dịch, đợi đến khi
trật tự ở lớp đồng thuận đã được thiết lập và tiết lộ dữ liệu giao dịch
sau để xử lý. Điều này duy trì trật tự nhân quả giữa các giao dịch được thực hiện
được thực thi bởi blockchain. Các khái niệm bảo mật và giao thức mật mã có liên quan
đã được phát triển đáng kể trước sự ra đời của blockchains [71, 190].
Các điều kiện bảo mật của “quan hệ nhân quả đầu vào” [190] và “bảo toàn quan hệ nhân quả” [71, 97] yêu cầu chính thức rằng không có thông tin nào về giao dịch được biết đến
trước khi vị trí của giao dịch này trong trật tự toàn cầu được xác định. Kẻ thù không được phép suy ra bất kỳ thông tin nào cho đến thời điểm đó, dưới dạng mật mã.
giác quan mạnh mẽ.
Người ta có thể phân biệt bốn kỹ thuật mật mã để bảo toàn quan hệ nhân quả:
• Giao thức tiết lộ cam kết [29, 142, 145]: Thay vì công bố giao dịch
rõ ràng, chỉ có cam kết mật mã đối với giao dịch được phát đi. Sau khi tất cả các giao dịch đã cam kết nhưng bị ẩn đã được đặt hàng (vào đầu blockchain
hệ thống trên chính MAINCHAIN, nhưng ở đây là bởi FSS), người gửi phải mở cam kết và tiết lộ dữ liệu giao dịch trong một khoảng thời gian định trước.
Sau đó, mạng sẽ xác minh rằng việc mở có đáp ứng được cam kết trước đó hay không. các
nguồn gốc của phương pháp này có từ trước khi blockchains ra đời.
Mặc dù nó đặc biệt đơn giản nhưng cách tiếp cận này có những hạn chế đáng kể và không dễ áp dụng vì hai lý do. Đầu tiên, vì chỉ có cam kết tồn tại ở cấp độ giao thức đặt hàng nên ngữ nghĩa của giao dịch
không thể được xác nhận trong quá trình đồng thuận. Một chuyến khứ hồi bổ sung cho khách hàng
được yêu cầu. Tuy nhiên, nghiêm trọng hơn, cân nhắc khả năng không có sự mở cửa nào có thể
bao giờ đến, điều này có thể dẫn đến một cuộc tấn công từ chối dịch vụ. Hơn nữa, nó
thật khó để xác định liệu phần mở đầu có hợp lệ trong một cách nhất quán, phân tán hay không
theo cách này bởi vì tất cả những người tham gia phải đồng ý về việc liệu thời điểm khai mạc đã đến
thời gian.
• Các giao thức tiết lộ cam kết có quá trình khôi phục bị trì hoãn [145]: Một thách thức với
Cách tiếp cận cam kết tiết lộ là khách hàng có thể cam kết thực hiện một giao dịch theo cách suy đoán và chỉ tiết lộ nó sau này nếu các giao dịch tiếp theo mang lại lợi nhuận. A
biến thể gần đây của phương pháp tiết lộ cam kết cải thiện khả năng phục hồi chống lại điều này
loại hành vi sai trái. Đặc biệt, giao thức TEX [145] giải quyết vấn đề này
sử dụng một cách tiếp cận thông minh trong đó các giao dịch được mã hóa bao gồm khóa giải mã
có thể đạt được bằng cách tính toán hàm trễ có thể kiểm chứng (VDF) [53, 221]. Nếu một khách hàng
không giải mã được giao dịch của mình kịp thời, những người khác trong hệ thống sẽ giải mã
nó thay mặt cô ấy bằng cách giải một câu đố mật mã có độ khó vừa phải.• Mã hóa ngưỡng [71, 190]: Phương pháp này khai thác rằng DON có thể thực hiện
hoạt động ngưỡng mật mã. Giả sử FSS duy trì mã hóa công khai
khóa pkO và oracle chia sẻ khóa riêng tương ứng với nhau.
Sau đó, khách hàng mã hóa các giao dịch theo pkO và gửi chúng đến FSS. Đơn đặt hàng FSS
giao dịch trên DON, sau đó giải mã chúng và cuối cùng đưa chúng vào
MAINCHAIN theo thứ tự cố định. Do đó, mã hóa đảm bảo rằng việc đặt hàng được
không dựa trên nội dung giao dịch mà chính dữ liệu đó có sẵn khi
cần thiết.
Phương pháp này ban đầu được đề xuất bởi Reiter và Birman [190] và sau đó được Cachin et al cải tiến. [71], nơi nó được tích hợp với sự đồng thuận được phép
giao thức. Công việc gần đây hơn đã khám phá việc sử dụng mật mã ngưỡng như một
cơ chế mức đồng thuận cho các thông báo chung [33, 97] và cho các tính toán chung với dữ liệu được chia sẻ [41].
So với các giao thức tiết lộ cam kết, mã hóa ngưỡng ngăn chặn các cuộc tấn công từ chối dịch vụ đơn giản (mặc dù cần phải cẩn thận do chi phí tính toán của việc giải mã). Nó cho phép DON hoạt động tự động, theo tốc độ riêng của nó và không cần
chờ đợi những hành động tiếp theo của khách hàng. Các giao dịch có thể được xác thực ngay sau khi chúng được giải mã. Hơn nữa, khách hàng mã hóa tất cả các giao dịch bằng một
khóa cho DON và kiểu giao tiếp vẫn giống như các kiểu khác
giao dịch. Quản lý khóa ngưỡng một cách an toàn và với các nút thay đổi trong
Tuy nhiên, O có thể gây thêm khó khăn.
• Chia sẻ bí mật đã cam kết [97]: Thay vì mã hóa dữ liệu giao dịch theo
khóa được giữ bởi DON, khách hàng cũng có thể chia sẻ bí mật khóa đó cho các nút trong O.
Sử dụng sơ đồ chia sẻ bí mật kết hợp, an toàn về mặt tính toán, giao dịch
được mã hóa đầu tiên bằng mật mã đối xứng với khóa ngẫu nhiên. Chỉ có khóa đối xứng tương ứng mới được chia sẻ và bản mã được gửi tới DON.
Máy khách phải gửi một khóa chia sẻ tới mỗi nút trong O bằng một tin nhắn được mã hóa riêng. Các bước giao thức còn lại tương tự như với ngưỡng
mã hóa, ngoại trừ dữ liệu giao dịch được giải mã bằng cơ chế đối xứng
thuật toán sau khi xây dựng lại khóa cho mỗi giao dịch từ các chia sẻ của nó.
Phương pháp này không yêu cầu thiết lập hoặc quản lý hệ thống mật mã khóa công khai
được liên kết với DON. Tuy nhiên, khách hàng phải nhận thức được các nút trong
O và liên lạc trong bối cảnh an toàn với từng người trong số họ, nơi đặt
thêm gánh nặng cho khách hàng.
Mặc dù các phương pháp mật mã cung cấp sự bảo vệ hoàn toàn chống lại thông tin
rò rỉ từ các giao dịch đã gửi lên mạng, chúng không che giấu siêu dữ liệu. cho
ví dụ: địa chỉ IP hoặc địa chỉ Ethereum của người gửi vẫn có thể được sử dụng bởi
một đối thủ để thực hiện các cuộc tấn công chạy trước và các cuộc tấn công khác. Tăng cường quyền riêng tư khác nhau
các kỹ thuật được triển khai ở lớp mạng, ví dụ: [52, 95, 107] hoặc lớp giao dịch,
ví dụ: [13, 65] sẽ cần thiết để hoàn thành mục tiêu này. Tác động của một phần cụ thể
siêu dữ liệu, cụ thể là giao dịch được gửi đến hợp đồng nào, có thể được che giấu (một phần)thông qua việc ghép nhiều hợp đồng trên cùng một DON. Che giấu mật mã
bản thân các giao dịch cũng không ngăn cản việc ưu tiên các giao dịch do lỗi
DON nút thông đồng với người gửi giao dịch.
Đảm bảo tính nhân quả được đảm bảo bởi các giao thức mật mã bổ sung cho các đảm bảo về tính công bằng trật tự cho bất kỳ chính sách nào và chúng tôi dự định khám phá sự kết hợp của cả hai
phương pháp, nếu điều này có thể. Nếu đối thủ không thể đạt được lợi thế đáng kể từ
quan sát siêu dữ liệu, các giao thức bảo toàn quan hệ nhân quả an toàn có thể được sử dụng cùng với
cũng là một cách tiếp cận đặt hàng ngây thơ. Ví dụ: nút oracle có thể ghi giao dịch
tới L ngay khi họ nhận được chúng mà không bị trùng lặp. Các giao dịch sau đó sẽ được
được sắp xếp theo sự xuất hiện của chúng trên L và sau đó được giải mã.
Chúng tôi cũng có kế hoạch xem xét việc sử dụng TEE như một cách giúp thực thi trật tự công bằng; cho
ví dụ: Tesseract [44] có thể được xem là đạt được một dạng trật tự nhân quả, nhưng một
được củng cố bởi khả năng của TEE xử lý các giao dịch ở dạng rõ ràng trong khi
duy trì tính bảo mật của chúng.
5,4
Những cân nhắc về lớp mạng
Cho đến nay, mô tả của chúng tôi về FSS chủ yếu tập trung vào vấn đề thực thi
thứ tự cuối cùng của các giao dịch khớp với thứ tự được quan sát của chúng trong mạng. Sau đây,
chúng tôi xem xét các vấn đề công bằng có thể phát sinh ở chính lớp mạng.
Các nhà giao dịch tần số cao trong các thị trường điện tử thông thường đầu tư đáng kể
tài nguyên để có được tốc độ mạng vượt trội [64] và các nhà giao dịch trong các sàn giao dịch tiền điện tử thể hiện hành vi tương tự [90]. Tốc độ mạng mang lại lợi thế cả về mặt
giám sát các giao dịch của các bên khác và gửi các giao dịch cạnh tranh.
Một biện pháp khắc phục được triển khai trong thực tế và phổ biến trong cuốn sách Flash Boys [155] là
“tăng tốc” được giới thiệu ban đầu trong sàn giao dịch IEX [128] và sau đó ở sàn giao dịch khác
trao đổi [179] (với kết quả hỗn hợp [19]). Cơ chế này áp đặt độ trễ (350 micro giây trong IEX) khi tiếp cận thị trường, nhằm mục đích vô hiệu hóa các lợi thế trong
tốc độ. Bằng chứng thực nghiệm, ví dụ: [128], hỗ trợ hiệu quả của nó trong việc giảm giao dịch nhất định
chi phí cho các nhà đầu tư thông thường. FSS có thể được sử dụng đơn giản để thực hiện một cơ chế bất đối xứng
giảm tốc độ—làm trì hoãn các giao dịch đến.
Budish, Cramton và Shim [64] cho rằng việc khai thác lợi thế về tốc độ
là không thể tránh khỏi trong các thị trường thời gian liên tục và tranh luận về một biện pháp khắc phục mang tính cơ cấu trong
hình thức thị trường đấu giá hàng loạt. Nhưng cách tiếp cận này chưa được áp dụng rộng rãi
trong các nền tảng giao dịch hiện có.
Các hệ thống giao dịch thông thường được tập trung hóa, thường nhận giao dịch thông qua
một kết nối mạng duy nhất. Ngược lại, trong một hệ thống phi tập trung, có thể
quan sát việc truyền bá giao dịch từ nhiều điểm thuận lợi. Do đó, có thể quan sát các hành vi như tràn mạng trong mạng P2P.
chúng tôi dự định
để khám phá các cách tiếp cận lớp mạng đối với FSS giúp các nhà phát triển chỉ định các chính sách
cấm các hành vi mạng không mong muốn như vậy.5,5
Chính sách công bằng ở cấp độ thực thể
Tính công bằng trong trật tự và tính nhân quả an toàn nhằm mục đích thực thi trật tự đối với các giao dịch
tôn trọng thời điểm chúng được tạo và lần đầu tiên được gửi lên mạng. Hạn chế của khái niệm công bằng này là nó không ngăn chặn được các cuộc tấn công mà đối thủ
đạt được lợi thế bằng cách làm tràn ngập một hệ thống có nhiều giao dịch, một chiến lược được quan sát
ngoài tự nhiên như một cách để thực hiện việc theo dõi giao dịch hiệu quả trong token doanh số [159] và để
tạo ra tắc nghẽn dẫn đến việc thanh lý các vị trí nợ thế chấp (CDP) [48].
Nói cách khác, sự công bằng trong trật tự đảm bảo sự công bằng đối với các giao dịch chứ không phải đối với người chơi.
Như được hiển thị trong hệ thống CanDID [160], có thể sử dụng các công cụ oracle như DECO
hoặc Town Crier kết hợp với một ủy ban gồm các nút (chẳng hạn như DON) để đạt được
nhiều hình thức kháng Sybil khác nhau trong khi vẫn bảo vệ quyền riêng tư. Người dùng có thể đăng ký danh tính
và cung cấp bằng chứng về tính độc đáo của họ mà không tiết lộ danh tính.
Thông tin xác thực chống lại âm thanh cung cấp một cách tiếp cận khả thi để làm phong phú thêm việc đặt hàng giao dịch
chính sách theo cách có thể hạn chế cơ hội cho các cuộc tấn công tràn ngập. Ví dụ, một
token chương trình giảm giá chỉ có thể cho phép một giao dịch cho mỗi người dùng đã đăng ký, trong trường hợp đăng ký
yêu cầu bằng chứng về tính duy nhất của mã định danh quốc gia, chẳng hạn như Số An sinh Xã hội.
Cách tiếp cận như vậy không phải là hoàn hảo nhưng có thể chứng tỏ là một chính sách hữu ích để giảm thiểu các cuộc tấn công tràn ngập giao dịch.
إطار عمل تنفيذ المعاملات 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.
Khung thực thi giao dịch DON
(DON-TEF) DONs sẽ cung cấp oracle và hỗ trợ tài nguyên phi tập trung cho các giải pháp lớp 2 trong cái mà chúng tôi gọi là Khung thực thi giao dịch mạng Oracle phi tập trung (DONTEF) hay gọi tắt là TEF. Ngày nay, tần suất cập nhật các hợp đồng DeFi bị giới hạn bởi độ trễ của chuỗi chính, ví dụ: khoảng thời gian chặn trung bình là 10-15 giây trong Ethereum [104]—cũng như chi phí của đẩy lượng lớn dữ liệu trên chuỗi và thông lượng tính toán/tx bị hạn chế— thúc đẩy các phương pháp mở rộng quy mô như sharding [148, 158, 232] và thực thi lớp 2 [5, 12, 121, 141, 169, 186, 187]. Kể cả blockchain có thời gian giao dịch nhanh hơn nhiều, ví dụ: [120], đã đề xuất các chiến lược mở rộng quy mô liên quan đến tính toán ngoài chuỗi [168]. TEF có nghĩa là hoạt động như một tài nguyên lớp 2 cho bất kỳ hệ thống lớp 1 / MAINCHAIN nào như vậy. Sử dụng TEF, DONs có thể hỗ trợ cập nhật nhanh hơn trong hợp đồng MAINCHAIN trong khi giữ lại các đảm bảo tin cậy quan trọng được cung cấp bởi chuỗi chính. TEF có thể hỗ trợ bất kỳ kỹ thuật và mô hình thực thi lớp 2 nào, bao gồm rollups,11 lạc quan rollups, Validium, v.v., cũng như mô hình ngưỡng tin cậy trong đó DON các nút thực hiện giao dịch. TEF bổ sung cho FSS và nhằm hỗ trợ nó. Nói cách khác, bất kỳ ứng dụng chạy trong TEF có thể sử dụng FSS. 11Thường được gọi là “zk-rollups”, một cách gọi sai vì chúng không nhất thiết cần bằng chứng không có kiến thức.
6.1 Tổng quan về TEF TEF là một mẫu thiết kế để xây dựng và thực hiện một hệ thống hybrid hiệu suất smart contract SC. Theo ý tưởng chính đằng sau smart contracts lai, TEF bao gồm một phân tách SC thành hai phần: (1) Cái mà chúng ta gọi trong ngữ cảnh TEF là mỏ neo hợp đồng SCa trên MAINCHAIN và logic (2) DON yêu cầu chúng tôi gọi là tệp thực thi TEF. Chúng ta sử dụng SC ở đây để biểu thị hợp đồng logic được thực hiện bằng sự kết hợp của SCa và mong đợi. (Như đã lưu ý ở trên, chúng tôi mong đợi phát triển các công cụ biên dịch để phân tách một tự động ký hợp đồng SC vào các thành phần này.) Phần thực thi TEF là công cụ xử lý các giao dịch của người dùng trong SC. Nó có thể thực thi một cách hiệu quả vì nó chạy trên DON. Nó có một số chức năng: • Nhập giao dịch: yêu cầu nhận hoặc tìm nạp giao dịch của người dùng. Nó có thể làm như vậy trực tiếp, tức là thông qua việc gửi giao dịch trên DON hoặc qua MAINCHAIN mempool bằng MS. • Thực hiện giao dịch nhanh: yêu cầu xử lý các giao dịch liên quan đến tài sản trong SC. Nó thực hiện điều đó cục bộ, tức là trên DON. • Truy cập bộ chuyển đổi / nhanh chóng và chi phí thấp oracle: exect có quyền truy cập riêng vào báo cáo oracle và dữ liệu bộ điều hợp khác dẫn đến nội dung, ví dụ: nhanh hơn, rẻ hơn và chính xác hơn định giá hơn so với việc thực hiện MAINCHAIN. Hơn nữa, quyền truy cập oracle ngoài chuỗi giảm chi phí vận hành của oracle, do đó chi phí sử dụng hệ thống, bằng cách tránh lưu trữ trên chuỗi đắt tiền. • Đồng bộ hóa: yêu cầu đẩy các bản cập nhật định kỳ từ DON lên MAINCHAIN, cập nhật SCa. Hợp đồng neo là giao diện người dùng MAINCHAIN của SC. Là thành phần có độ tin cậy cao hơn của SC, nó phục vụ một số mục đích: • Giám sát tài sản: Tiền của người dùng được gửi vào, giữ và rút khỏi SCa. • Đồng bộ hóa xác minh: SCa có thể xác minh tính chính xác của các cập nhật trạng thái khi được kích hoạt đồng bộ hóa, ví dụ: SNARK được đính kèm với rollups. • Đường ray bảo vệ: SCa có thể bao gồm các điều khoản để bảo vệ chống tham nhũng hoặc hư hỏng mong đợi. (Xem Phần 7 để biết thêm chi tiết.) Trong TEF, tiền của người dùng được lưu giữ trên MAINCHAIN, nghĩa là DON bản thân nó không được giám sát. Tùy thuộc vào việc lựa chọn cơ chế đồng bộ hóa (xem bên dưới), người dùng có thể cần chỉ tin cậy DON để có báo cáo oracle chính xác và đồng bộ hóa kịp thời với MAINCHAIN. Mô hình tin cậy thu được rất giống với mô hình dành cho DEX dựa trên sổ đặt hàng, ví dụ: [2], mà ngày nay thường bao gồm một thành phần ngoài chuỗi để khớp lệnh và một thành phần trên chuỗi để thanh toán bù trừ.Để sử dụng từ vựng về hệ thống thanh toán, người ta có thể coi exect là thành phần của SC chịu trách nhiệm thanh toán bù trừ, trong khi SCa xử lý việc quyết toán. Xem Hình 13 để biết sơ đồ mô tả của TEF. Hình 13: Sơ đồ TEF. Trong ví dụ này, các giao dịch đi qua mempool của MAINCHAIN qua MS tới DON. Lợi ích của TEF: TEF mang lại ba lợi ích chính: • Hiệu suất cao: SC kế thừa thông lượng cao hơn nhiều của DON so với MAINCHAIN cho cả giao dịch và báo cáo oracle. Ngoài ra, exect có thể xử lý các giao dịch nhanh hơn và phản hồi các báo cáo oracle một cách kịp thời hơn so với việc chỉ triển khai trên MAINCHAIN. • Phí thấp hơn: Quá trình đồng bộ hóa ít nhạy cảm về thời gian hơn so với xử lý giao dịch và các giao dịch có thể được gửi từ DON tới MAINCHAIN theo đợt. Do đó, phí trên mỗi giao dịch trên chuỗi (ví dụ: chi phí gas) với phương pháp này thấp hơn nhiều so với hợp đồng chỉ chạy trên MAINCHAIN. • Tính bảo mật: Cơ chế bảo mật của DON có thể được áp dụng chịu đựng SC.
Giới hạn của TEF: Một hạn chế của TEF là nó không hỗ trợ tức thời rút tiền, vì chúng chỉ xảy ra trên MAINCHAIN: Khi gửi yêu cầu rút tiền tới SCa, người dùng có thể phải chờ đợi để thực hiện cập nhật trạng thái bao gồm giao dịch rút tiền trước khi nó có thể được phê duyệt. Chúng tôi thảo luận về một số biện pháp khắc phục từng phần, tuy nhiên, trong Phần 6.2. Một hạn chế khác của TEF là nó không hỗ trợ thành phần nguyên tử DeFi hợp đồng trên MAINCHAIN, cụ thể là khả năng định tuyến tài sản qua nhiều DeFi hợp đồng trong một giao dịch duy nhất. Tuy nhiên, TEF có thể hỗ trợ tính nguyên tử như vậy giữa DeFi hợp đồng chạy trên cùng DON. Chúng tôi cũng thảo luận về một số cách để giải quyết vấn đề này vấn đề trong Phần 6.2. 6.2 Định tuyến giao dịch Giao dịch cho SC có thể được người dùng gửi trực tiếp tới DON hoặc có thể được chuyển qua mempool trong MAINCHAIN (thông qua FSS). Có bốn loại giao dịch riêng biệt, mỗi loại trong đó yêu cầu xử lý khác nhau: Giao dịch trong hợp đồng: Bởi vì nó tránh được sự phức tạp của động lực khí, TEF mang lại cho SC sự linh hoạt hơn trong việc xử lý các giao dịch so với trước đây. có sẵn trong hợp đồng lớp 1. Ví dụ: trong khi giao dịch mempool trong Ethereum có thể bị ghi đè bằng một giao dịch mới với giá gas cao hơn, SC có thể coi giao dịch hoạt động trên các tài sản trong SC là có thẩm quyền ngay khi nó hiển thị trong mempool. Do đó, SC không cần đợi giao dịch được xác nhận trong một khối, dẫn đến độ trễ giảm đáng kể. Ủy quyền: Người dùng có thể muốn gửi giao dịch τ tới SC thông qua hợp đồng ví hoặc hợp đồng khác trên MAINCHAIN. DON có thể mô phỏng việc thực thi τ trên MAINCHAIN để xác định xem liệu nó có dẫn đến giao dịch tiếp theo với SC hay không. Nếu vậy, τ có thể được sắp xếp theo trình tự với các giao dịch khác dành cho SC thực hiện. Có một vài khả năng về cách DON xác định các giao dịch đó: (1) DON có thể mô phỏng tất cả các giao dịch trong mempool (một cách tiếp cận tốn kém); (2) Một số hợp đồng hoặc các loại hợp đồng, ví dụ: ví, có thể được liệt kê để theo dõi bởi DON; hoặc (3) Người dùng có thể chú thích các giao dịch để kiểm tra DON. Vấn đề trở nên phức tạp hơn khi một giao dịch đơn lẻ tương tác với hai hợp đồng SC1 và SC2, cả hai đều sử dụng Dịch vụ sắp xếp thứ tự công bằng và có chính sách đặt hàng không tương thích. Ví dụ: DON có thể là chuỗi τ vào thời điểm gần nhất đó là tương thích với cả hai. Tiền gửi: Giao dịch gửi tài sản MAINCHAIN vào SC cần phải được xác nhận trong một khối trước khi SC có thể coi nó là hợp lệ. Khi nó phát hiện việc khai thác một giao dịch gửi tài sản (ví dụ: Ether) vào SCa, có thể xác nhận ngay lập tứctiền gửi. Ví dụ: nó có thể áp dụng giá được báo cáo oracle hiện tại trên DON cho tài sản. Rút tiền: Như đã lưu ý ở trên, hạn chế của TEF là việc rút tiền không phải lúc nào cũng được thực hiện ngay lập tức. Trong mô hình thực thi loại rollup, việc rút tiền yêu cầu phải được sắp xếp theo thứ tự với các giao dịch khác, tức là được cuộn lại, để được an toàn đã được xử lý. Tuy nhiên, có một số biện pháp khắc phục một phần hạn chế này. Nếu DON có thể nhanh chóng tính toán bằng chứng hợp lệ rollup cho giao dịch rút tiền thì việc quan sát giao dịch của người dùng τ trong mempool có thể gửi giao dịch cập nhật trạng thái τ ′ với giá gas cao hơn, một kiểu chạy trước có lợi. Với điều kiện là τ không được khai thác trước khi τ ′ đến mempool, τ ′ sẽ đứng trước τ và τ sẽ có hiệu lực đối với việc rút tiền đã được phê duyệt. Trong biến thể TEF trong đó DON được dựa vào để tính toán các cập nhật trạng thái (xem biến thể ký ngưỡng bên dưới), DON có thể xác định ngoài chuỗi liệu τ có nên được phê duyệt dựa trên trạng thái của SC khi thực thi nó hay không. DON sau đó có thể gửi một giao dịch τ ′ phê duyệt việc rút tiền τ—mà không ảnh hưởng đến toàn bộ giao dịch cập nhật trạng thái. Nếu cách tiếp cận này không thể thực hiện được hoặc trong trường hợp nó không thành công, thì DON đã bắt đầu giao dịch τ ′ có thể gửi tiền cho người dùng để phản hồi lại τ để người dùng không cần phải bắt đầu một giao dịch bổ sung. 6.3 Đang đồng bộ hóa Tệp thực thi TEF đẩy các bản cập nhật định kỳ từ DON lên MAINCHAIN, cập nhật trạng thái của SCa trong quy trình mà chúng tôi gọi là đồng bộ hóa. Đồng bộ hóa có thể được nghĩ đến như việc truyền bá các giao dịch lớp 2 sang lớp 1, do đó TEF có thể rút ra bất kỳ số nào kỹ thuật hiện có cho mục đích này, bao gồm rollups [5, 12, 16, 69], lạc quan rollups [10, 11, 141], Validium [201] hoặc ký ngưỡng cơ bản, ví dụ: BLS ngưỡng, Schnorr hoặc ECDSA [24, 54, 116, 202]. Về nguyên tắc, môi trường thực thi đáng tin cậy cũng có thể chứng thực tính đúng đắn của các thay đổi trạng thái, mang lại hiệu suất cao hơn nhiều thay thế cho rollups, nhưng với mô hình tin cậy phụ thuộc vào phần cứng. (Xem ví dụ: [80].) Dưới đây chúng tôi so sánh các tùy chọn đồng bộ hóa này với ba thuộc tính chính trong TEF: • Tính sẵn có của dữ liệu: Trạng thái của SC được lưu trữ ở đâu? Ít nhất ba lựa chọn là có sẵn dưới dạng TEF: trên MAINCHAIN, trên DON hoặc bởi một số bộ lưu trữ của bên thứ ba các nhà cung cấp như IPFS. Họ đạt được các đảm bảo an ninh, tính sẵn sàng khác nhau cấp độ và hồ sơ thực hiện. Tóm lại, việc lưu trữ trạng thái trên MAINCHAIN cho phép khả năng kiểm toán trực tuyến và loại bỏ sự phụ thuộc vào bất kỳ bên nào về tính khả dụng của trạng thái; mặt khác, việc lưu trữ trạng thái ngoài chuỗi có thể giảm chi phí lưu trữ và cải thiện thông lượng, với chi phí phải trả là tin tưởng nhà cung cấp dịch vụ lưu trữ (DON hoặc bên thứ ba) cho tính sẵn có của dữ liệu. Tất nhiên, các mô hình linh hoạt kết hợp các tùy chọn này cũng có thể. Chúng tôi chỉ ra dạng yêu cầu sẵn có của dữ liệu trong Bảng 1.• Đảm bảo tính chính xác: SCa xác định tính chính xác của các bản cập nhật bằng cách nào được thúc đẩy bởi sự mong đợi? Điều này ảnh hưởng đến tải tính toán trên exect và SCa và độ trễ đồng bộ hóa (xem bên dưới). • Độ trễ: Độ trễ đồng bộ hóa có ba yếu tố góp phần: (1) Thời gian thực hiện để mong đợi tạo giao dịch đồng bộ hóa τsync; (2) Thời gian cần thiết cho τsync được xác nhận trên MAINCHAIN; và (3) Thời gian để τsync phát huy tác dụng SCa. Trong TEF, độ trễ đặc biệt quan trọng đối với việc rút tiền (nhưng ít hơn đối với giao dịch trong hợp đồng) vì việc rút tiền nhất thiết phải có (ít nhất đồng bộ hóa trạng thái một phần). Đang đồng bộ hóa tùy chọn dữ liệu sẵn có Tính đúng đắn đảm bảo Độ trễ Tổng hợp [5, 12, 16, 69] Trên chuỗi Bằng chứng hiệu lực Thời gian thực hiện để tạo ra bằng chứng hợp lệ (ví dụ: số phút trong hệ thống hiện tại) Xác thực [201] Chuỗi Off Bằng chứng hiệu lực Tương tự như trên Lạc quan rollup [10, 11, 141] Trên chuỗi bằng chứng gian lận Độ dài của thử thách thời kỳ (ví dụ: ngày hoặc tuần) Ngưỡng ký [24, 54, 116, 202] Linh hoạt Ngưỡng chữ ký của DON tức thời Môi trường thực thi đáng tin cậy [80] Linh hoạt Dựa trên phần cứng chứng thực tức thời Bảng 1: Các tùy chọn đồng bộ hóa khác nhau trong TEF và các thuộc tính của chúng. Bảng 1 tóm tắt các thuộc tính này trong năm tùy chọn đồng bộ hóa chính trong TEF. (Lưu ý rằng chúng tôi không có ý định so sánh các công nghệ này như việc mở rộng quy mô lớp 2 độc lập giải pháp. Vì lý do đó, chúng tôi giới thiệu người đọc đến ví dụ: [121].) Bây giờ chúng ta thảo luận về từng tùy chọn đồng bộ hóa. Bản tổng hợp: rollup [69] là một giao thức trong đó quá trình chuyển đổi trạng thái được thực hiện bởi một lô giao dịch được tính toán ngoài chuỗi. Sự thay đổi trạng thái sau đó được lan truyền lên MAINCHAIN. Để triển khai rollups, neo smart contract SCa lưu trữ trạng thái đại diện thu gọn Rstate (ví dụ: gốc Merkle) của trạng thái thực tế. Để đồng bộ, exect gửi τsync = (T, R' state) tới SCa trong đó T là tập hợp các giao dịch được xử lý kể từ lần cuối cùngđồng bộ và R′ trạng thái là biểu diễn thu gọn của trạng thái mới được tính bằng cách áp dụng các giao dịch trong T sang trạng thái R trước đó. Có hai biến thể phổ biến khác nhau về cách SCa xác minh cập nhật trạng thái trong τsync. Đầu tiên, (zk-)rollups, đính kèm một lập luận ngắn gọn về tính đúng đắn, đôi khi được gọi là một bằng chứng hợp lệ cho quá trình chuyển đổi Rstate →R′ trạng thái. Để triển khai biến thể này, hãy mong đợi tính toán và gửi bằng chứng hợp lệ (ví dụ: bằng chứng zk-SNARK) cùng với τsync, chứng minh rằng R’ state là kết quả của việc áp dụng T vào trạng thái hiện tại của SCa. mỏ neo hợp đồng chỉ chấp nhận cập nhật trạng thái sau khi nó đã xác minh bằng chứng. Những rollup lạc quan không bao gồm những lập luận về tính đúng đắn nhưng có staking và thách thức các thủ tục tạo điều kiện thuận lợi cho việc xác minh phân tán các chuyển đổi trạng thái. Vì điều này rollup biến thể, SCa tạm chấp nhận τsync giả sử nó đúng (do đó mang lại sự lạc quan) nhưng τsync không có hiệu lực cho đến sau thời gian thử thách, trong thời gian đó bất kỳ bên nào giám sát MAINCHAIN có thể xác định các cập nhật trạng thái sai sót và thông báo cho SCa để thực hiện các hành động cần thiết (ví dụ: khôi phục trạng thái và đưa ra một hình phạt theo yêu cầu.) Cả hai biến thể rollup đều đạt được tính khả dụng của dữ liệu trên chuỗi khi các giao dịch được đăng trên chuỗi, từ đó trạng thái đầy đủ có thể được xây dựng. Độ trễ của zk-rollups là bị chi phối bởi thời gian cần thiết để tạo ra các bằng chứng hợp lệ, thường là về thứ tự phút trong các hệ thống hiện có [16] và có thể sẽ thấy sự cải thiện theo thời gian. Mặt khác, rollup lạc quan có độ trễ cao hơn (ví dụ: ngày hoặc tuần) bởi vì thời gian thử thách cần phải đủ dài để các bằng chứng gian lận có thể phát huy tác dụng. các hàm ý của việc xác nhận chậm là tinh tế và đôi khi cụ thể đối với sơ đồ, do đó một phân tích kỹ lưỡng là nằm ngoài phạm vi. Ví dụ: một số chương trình nhất định coi việc thanh toán giao dịch là "cuối cùng không cần sự tin cậy" [109] trước khi cập nhật trạng thái được xác nhận, vì một người dùng thông thường có thể xác minh rollup nhanh hơn nhiều so với MAINCHAIN. Xác thực: Validium là một dạng (zk-)rollup chỉ cung cấp dữ liệu ngoài chuỗi và không duy trì tất cả dữ liệu trên MAINCHAIN. Cụ thể, exect chỉ gửi cái mới nêu và bằng chứng nhưng không giao dịch với SCa. Với đồng bộ hóa kiểu Validium, ngoại trừ và DON thực thi nó là các bên duy nhất lưu trữ trạng thái hoàn chỉnh và thực hiện các giao dịch. Giống như zk-rollups, độ trễ đồng bộ hóa bị chi phối bởi tính hợp lệ thời gian tạo bằng chứng. Tuy nhiên, không giống như zk-rollups, đồng bộ hóa kiểu Validium làm giảm chi phí lưu trữ và tăng thông lượng. Ngưỡng ký bởi DON: Giả sử ngưỡng DON nút là trung thực, tùy chọn đồng bộ hóa đơn giản và nhanh chóng là có các nút DON ký tên chung vào trạng thái mới. Cách tiếp cận này có thể hỗ trợ cả tính khả dụng của dữ liệu trên chuỗi và ngoài chuỗi. Lưu ý rằng nếu người dùng tin cậy DON cho oracle cập nhật, họ không cần phải tin cậy hơn nữa để chấp nhận cập nhật trạng thái, vì chúng đã ở trong mô hình ngưỡng tin cậy. Một lợi ích khác của ngưỡng ký là độ trễ thấp. Hỗ trợ các định dạng chữ ký giao dịch mới như được đề xuất trong EIP-2938 [70] và được gọi là trừu tượng hóa tài khoản sẽ tạo ra ngưỡng việc ký kết dễ thực hiện hơn nhiều vì nó sẽ loại bỏ sự cần thiết của ngưỡng ECDSA, bao gồm các giao thức phức tạp hơn đáng kể (ví dụ: [116, 117, 118])hơn các lựa chọn thay thế như chữ ký ngưỡng Schnorr [202] hoặc BLS [55]. Môi trường thực thi đáng tin cậy (TEE): TEE là môi trường thực thi biệt lập (thường được thực hiện bằng phần cứng) nhằm mục đích cung cấp các biện pháp bảo vệ an ninh mạnh mẽ cho các chương trình đang chạy bên trong. Một số TEE (ví dụ: Intel SGX [84]) có thể tạo ra bằng chứng, được gọi là chứng thực, rằng đầu ra được tính toán chính xác bởi một chương trình cụ thể cho một đầu vào cụ thể12. Một biến thể đồng bộ hóa TEF dựa trên TEE có thể được triển khai bởi thay thế bằng chứng trong (zk-)rollups hoặc Validium bằng chứng thực TEE bằng kỹ thuật từ [80]. So với bằng chứng không có kiến thức được sử dụng trong rollups và Validium, TEE có nhiều hiệu quả hơn. So với việc ký ngưỡng, TEE loại bỏ sự phức tạp của tạo ra các chữ ký ECDSA ngưỡng vì về nguyên tắc chỉ cần một TEE có liên quan. Tuy nhiên, việc sử dụng TEE sẽ đưa ra thêm các giả định về độ tin cậy phụ thuộc vào phần cứng. Người ta cũng có thể kết hợp TEE với việc ký ngưỡng để tạo khả năng phục hồi chống lại sự xâm phạm của một phần nhỏ các trường hợp TEE, mặc dù biện pháp bảo vệ này giới thiệu lại sự phức tạp của việc tạo chữ ký ECDSA ngưỡng. Tính linh hoạt bổ sung: Các tùy chọn đồng bộ hóa này có thể được tinh chỉnh để mang lại sự linh hoạt hơn theo những cách sau. • Kích hoạt linh hoạt: Ứng dụng TEF có thể xác định các điều kiện đồng bộ hóa được kích hoạt. Ví dụ: việc đồng bộ hóa có thể dựa trên hàng loạt, ví dụ: xảy ra sau mọi N giao dịch, dựa trên thời gian, ví dụ: cứ sau 10 khối hoặc dựa trên sự kiện, ví dụ: xảy ra bất cứ khi nào giá tài sản mục tiêu thay đổi đáng kể. • Đồng bộ hóa một phần: Có thể và trong một số trường hợp là mong muốn (ví dụ: với rollups, đồng bộ hóa một phần có thể giảm độ trễ) để mong muốn cung cấp khả năng đồng bộ hóa nhanh các nội dung nhỏ lượng trạng thái, có lẽ chỉ thực hiện đồng bộ hóa đầy đủ theo định kỳ. Ví dụ, ngoại trừ có thể phê duyệt yêu cầu rút tiền bằng cách cập nhật số dư của người dùng trong SCa mà không cập nhật trạng thái MAINCHAIN. 6,4 tổ chức lại Tổ chức lại chuỗi khối do mất ổn định mạng hoặc thậm chí từ các cuộc tấn công 51% có thể gây ra mối đe dọa cho tính toàn vẹn của chuỗi chính. Trong thực tế, đối thủ đã sử dụng chúng để thực hiện các cuộc tấn công chi tiêu gấp đôi [34]. Trong khi các cuộc tấn công như vậy vào các chuỗi lớn là thách thức để gắn kết, chúng vẫn khả thi đối với một số chuỗi [88]. Vì nó hoạt động độc lập với MAINCHAIN nên DON mang đến những điều thú vị khả năng quan sát và cung cấp một số biện pháp bảo vệ chống lại việc tổ chức lại liên quan đến các cuộc tấn công. Ví dụ: DON có thể báo cáo cho một hợp đồng dựa trên SC trên MAINCHAIN về sự tồn tại của một nhánh phân nhánh cạnh tranh có độ dài ngưỡng nào đó τ. Ngoài ra DON có thể 12Chi tiết bổ sung có thể được tìm thấy trong Phụ lục B.2.1. Họ không cần thiết cho sự hiểu biết.
cung cấp bằng chứng—trong cài đặt PoW hoặc PoS—về sự tồn tại của một đợt phân nhánh như vậy. các hợp đồng SC có thể thực hiện các hành động phòng thủ phù hợp, chẳng hạn như tạm dừng thực hiện giao dịch tiếp theo trong một khoảng thời gian (ví dụ: để cho phép các sàn giao dịch đưa vào danh sách đen chi tiêu gấp đôi tài sản). Lưu ý rằng mặc dù đối thủ tiến hành tấn công 51% có thể tìm cách kiểm duyệt báo cáo từ DON, biện pháp đối phó trong SC là yêu cầu báo cáo định kỳ từ DON để xử lý các giao dịch (tức là nhịp tim) hoặc để yêu cầu báo cáo mới cho xác thực một giao dịch có giá trị cao. Mặc dù các cảnh báo phân nhánh như vậy về nguyên tắc là một dịch vụ chung mà DON có thể cung cấp vì bất kỳ mục đích nào, kế hoạch của chúng tôi là kết hợp chúng với 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.
Giảm thiểu sự tin cậy
Là một hệ thống phi tập trung với sự tham gia của một tập hợp các thực thể không đồng nhất, Mạng Chainlink cung cấp khả năng bảo vệ mạnh mẽ chống lại các lỗi về cả tính khả dụng (tính khả dụng) và độ an toàn (tính toàn vẹn của báo cáo). Tuy nhiên, hầu hết các hệ thống phi tập trung đều khác nhau về mức độ mà các thành phần cấu thành của chúng được phân cấp. Cái này đúng ngay cả với các hệ thống lớn, nơi có sự phân quyền hạn chế giữa các thợ mỏ [32] và trung gian [51] đã có mặt từ lâu. Mục tiêu của bất kỳ nỗ lực phân cấp nào là giảm thiểu sự tin cậy: Chúng tôi tìm cách giảm tác động bất lợi của tham nhũng hoặc trục trặc hệ thống trong mạng Chainlink, thậm chí cả điều đó do DON độc hại. Nguyên tắc chỉ đạo của chúng tôi là Nguyên tắc đặc quyền tối thiểu [197]. Các thành phần và tác nhân hệ thống trong hệ thống phải có đặc quyền trong phạm vi nghiêm ngặt chỉ cho phép hoàn thành thành công vai trò được giao của họ. Ở đây chúng tôi trình bày một số cơ chế cụ thể để Chainlink áp dụng trong quá trình phát triển của nó hướng tới việc giảm thiểu sự tin cậy ngày càng lớn hơn. Chúng tôi mô tả các cơ chế này theo thuật ngữ của locus, tức là các thành phần hệ thống mà chúng có gốc rễ, được hiển thị trong Hình 14. Chúng ta giải quyết từng địa điểm trong một tiểu mục tương ứng. 7.1 Xác thực nguồn dữ liệu Mô hình hoạt động hiện tại cho oracle bị hạn chế bởi thực tế là có ít nguồn dữ liệu ký điện tử vào dữ liệu họ bỏ qua, phần lớn là do TLS không ký tự nhiên dữ liệu. TLS sử dụng chữ ký số trong giao thức “bắt tay” của nó (để thiết lập khóa chung giữa máy chủ và máy khách). Do đó, các máy chủ hỗ trợ HTTPS có chứng chỉ trên các khóa công khai về nguyên tắc có thể dùng để ký dữ liệu, nhưng chúng thường không sử dụng những chứng chỉ này để hỗ trợ việc ký dữ liệu. Do đó, tính bảo mật của DON, như trong các mạng oracle ngày nay, dựa vào các nút oracle chuyển tiếp dữ liệu một cách trung thực từ một mạng dữ liệu nguồn cho một hợp đồng. Một thành phần quan trọng lâu dài trong tầm nhìn của chúng tôi nhằm giảm thiểu sự tin cậy trong Chainlink liên quan đến việc xác thực nguồn dữ liệu mạnh mẽ hơn thông qua việc hỗ trợ các công cụ và tiêu chuẩn để ký dữ liệu. Việc ký dữ liệu có thể giúp thực thi các đảm bảo tính toàn vẹn từ đầu đến cuối. Về nguyên tắc, nếu một hợp đồng chấp nhận đầu vào là một phần dữ liệu D được ký trực tiếp bởi bên dữ liệu.
Hình 14: Các cơ chế giảm thiểu sự tin cậy được thảo luận trong phần này. 1⃝Dữ liệu các nguồn cung cấp dữ liệu cho 2⃝DON, chuyển tiếp chức năng của dữ liệu đến bộ phận phụ thuộc 3⃝smart contract. Ngoài ra, mạng DON hoặc oracle bao gồm 4⃝nút quản lý smart contract trên MAINCHAIN, ví dụ: các nút bù, bảo vệ đường ray, vân vân. nguồn thì mạng oracle không thể giả mạo D. Có nhiều lời khuyến khích khác nhau những nỗ lực cho phép việc ký dữ liệu như vậy đã xuất hiện, bao gồm cả OpenID Connect, được thiết kế chủ yếu để xác thực người dùng [9], TLS-N, một dự án học thuật nhằm mục đích mở rộng TLS [191] bằng cách sử dụng lại chứng chỉ TLS và Tiện ích mở rộng bằng chứng TLS [63]. Tuy nhiên, mặc dù OpenID Connect đã được áp dụng một số, nhưng Tiện ích mở rộng bằng chứng TLS và TLS-N vẫn chưa được áp dụng. Một cách xác thực nguồn dữ liệu tiềm năng khác là sử dụng Trao đổi HTTP đã ký (SXG) [230], họ có thể lưu vào bộ nhớ đệm trên mạng phân phối nội dung như một phần của giao thức Trang di động tăng tốc (AMP) [225]. Trình duyệt dành cho thiết bị di động Chrome hiển thị nội dung từ SXG được lưu trong bộ nhớ đệm AMP như thể chúng được phân phát từ miền mạng riêng của nhà xuất bản của họ thay vì miền máy chủ bộ đệm. Khuyến khích xây dựng thương hiệu này, cùng với việc tương đối dễ dàng cho phép nó sử dụng các dịch vụ như URL thực của CloudFlare [83] và amppackager [124] của Google, có thể dẫn đến việc áp dụng rộng rãi SXG trong nội dung tin tức được lưu trong bộ nhớ đệm, điều này sẽ cho phép một quy trình đơn giản, chống giả mạo cách để Chainlink oracle kích hoạt các sự kiện đáng chú ý được báo cáo trong SXG hợp lệ. Mặc dù SXG được lưu trong bộ nhớ đệm AMP từ các nhà xuất bản tin tức sẽ không hữu ích cho các ứng dụng có nhịp độ cao. các ứng dụng như báo cáo về dữ liệu giao dịch, chúng có thể là nguồn an toàn cho các giao dịch tùy chỉnh. các hợp đồng liên quan đến các sự kiện trong thế giới thực như thời tiết khắc nghiệt hoặc kết quả bầu cử. Chúng tôi tin rằng việc triển khai đơn giản, các công cụ hoàn thiện và tính linh hoạt sẽ rất quan trọng đối với tăng tốc việc ký nguồn dữ liệu. Cho phép nhà cung cấp dữ liệu sử dụng các nút Chainlink làm giao diện người dùng API được xác thực có vẻ là một cách tiếp cận đầy hứa hẹn. Chúng tôi dự định tạo ra mộttùy chọn cho các nút hoạt động ở chế độ này, có hoặc không có sự tham gia vào mạng dưới dạng oracle toàn diện. Chúng tôi gọi khả năng này là nguồn gốc dữ liệu được xác thực (ADO). Bằng cách sử dụng các nút Chainlink với ADO, các nguồn dữ liệu sẽ có thể được hưởng lợi từ kinh nghiệm và công cụ do cộng đồng Chainlink phát triển trong việc bổ sung kỹ thuật số khả năng ký kết vào bộ API ngoài chuỗi hiện có của họ. Liệu họ có nên chọn chạy các nút của họ dưới dạng oracle, họ cũng có thể mở ra các luồng doanh thu mới tiềm năng theo cùng mô hình với các nhà cung cấp dữ liệu hiện có, ví dụ: Kraken [28], Kaiko [140] và những người khác chạy các nút Chainlink để bán dữ liệu API trên chuỗi. 7.1.1 Những hạn chế của nguồn gốc dữ liệu được xác thực Ký kỹ thuật số bằng nguồn dữ liệu, mặc dù có thể giúp tăng cường xác thực nhưng bản chất nó không đủ để thực hiện tất cả các mục tiêu hoạt động hoặc bảo mật tự nhiên của oracle mạng. Đầu tiên, một phần dữ liệu D nhất định vẫn phải được chuyển tiếp một cách mạnh mẽ và kịp thời. cách từ nguồn dữ liệu tới smart contract hoặc người tiêu dùng dữ liệu khác. Tức là ngay cả trong một cài đặt lý tưởng trong đó tất cả dữ liệu được ký bằng các khóa được lập trình sẵn thành phụ thuộc hợp đồng, vẫn cần có DON để truyền đạt dữ liệu một cách đáng tin cậy từ các nguồn đến các hợp đồng. Ngoài ra, có một số trường hợp trong đó hợp đồng hoặc dữ liệu oracle khác người tiêu dùng muốn truy cập vào đầu ra được xác thực của các chức năng khác nhau được tính toán trên dữ liệu nguồn vì hai lý do chính: • Tính bảo mật: API nguồn dữ liệu có thể cung cấp dữ liệu nhạy cảm hoặc độc quyền cần phải được biên tập lại hoặc khử trùng trước khi nó được hiển thị công khai trên chuỗi. Tuy nhiên, bất kỳ sửa đổi nào đối với dữ liệu đã ký đều làm mất hiệu lực của chữ ký. Đặt cái khác Nói cách khác, ADO ngây thơ và việc dọn dẹp dữ liệu không tương thích. Chúng tôi hiển thị trong ví dụ 3 làm thế nào cả hai có thể được dung hòa thông qua một hình thức ADO nâng cao. • Lỗi nguồn dữ liệu: Cả lỗi và lỗi đều có thể ảnh hưởng đến nguồn dữ liệu và chữ ký số không giải quyết được vấn đề gì. Từ khi thành lập [98], Chainlink đã đã bao gồm một cơ chế để khắc phục những lỗi đó: sự dư thừa. Báo cáo do mạng oracle đưa ra thường trình bày dữ liệu kết hợp của nhiều nguồn. Bây giờ chúng tôi thảo luận về các kế hoạch mà chúng tôi đang khám phá trong cài đặt ADO để nâng cao tính bảo mật của dữ liệu nguồn và kết hợp dữ liệu từ nhiều nguồn một cách an toàn. 7.1.2 Tính bảo mật Các nguồn dữ liệu có thể không dự đoán và cung cấp đầy đủ các API mong muốn bởi người dùng. Cụ thể, người dùng có thể muốn truy cập dữ liệu được xử lý trước để giúp đảm bảo tính bảo mật. Ví dụ sau đây minh họa vấn đề.Ví dụ 3. Alice mong muốn có được thông tin xác thực danh tính phi tập trung (DID) nêu rõ rằng cô ấy trên 18 tuổi (và do đó, chẳng hạn, có thể vay tiền). để làm vì vậy, cô ấy cần phải chứng minh sự thật này về tuổi của mình với tổ chức cấp chứng chỉ DID. Alice hy vọng sẽ sử dụng dữ liệu từ Bộ phương tiện cơ giới (DMV) của bang cô ấy trang web cho mục đích này. DMV có hồ sơ về ngày sinh của cô ấy và sẽ phát ra một chứng thực được ký điện tử A trên đó có dạng sau: A = {Tên: Alice, DoB: 16/02/1999}. Trong ví dụ này, chứng thực A có thể đủ để Alice chứng minh cho DID nhà cấp chứng chỉ xác thực rằng cô ấy trên 18 tuổi. Nhưng nó không cần thiết làm rò rỉ thông tin nhạy cảm: của Alice DoB chính xác. Lý tưởng nhất là điều Alice muốn từ DMV thay vào đó là chữ ký trên một câu nói đơn giản A′ rằng “Alice trên 18 tuổi.” Nói cách khác, cô ấy muốn đầu ra của hàm G vào ngày sinh của cô ấy X, trong đó (một cách không chính thức), A′ = G(X) = True nếu Ngày hiện tại −X ≥18 năm; ngược lại, G(X) = Sai. Để khái quát hóa, Alice muốn có thể yêu cầu từ nguồn dữ liệu một chứng thực A′ có dạng: A′ = {Tên: Alice, Func:G(X), Kết quả: Đúng}, trong đó G(X) biểu thị đặc tả của hàm G và (các) đầu vào X của nó. Chúng ta hình dung rằng người dùng sẽ có thể cung cấp G(X) mong muốn làm đầu vào cho yêu cầu của mình về chứng thực tương ứng A′. Lưu ý rằng chứng thực của nguồn dữ liệu A′ phải bao gồm thông số G(X) để đảm bảo rằng A′ được giải thích chính xác. Trong ví dụ trên, G(X) định nghĩa ý nghĩa của giá trị Boolean trong A′ và do đó True biểu thị chủ đề của chứng thực trên 18 tuổi. Chúng tôi đề cập đến các truy vấn linh hoạt trong đó người dùng có thể chỉ định G(X) làm truy vấn chức năng. Để hỗ trợ các trường hợp sử dụng như trong Ví dụ 3, cũng như các trường hợp liên quan đến truy vấn trực tiếp từ hợp đồng, chúng tôi dự định bao gồm hỗ trợ cho các truy vấn chức năng liên quan đến các hàm đơn giản G như một phần của ADO. 7.1.3 Kết hợp dữ liệu nguồn Để giảm chi phí trên chuỗi, các hợp đồng thường được thiết kế để sử dụng dữ liệu kết hợp từ nhiều nguồn, như được minh họa trong ví dụ sau. Ví dụ 4 (Trung gian hóa dữ liệu giá). Để cung cấp nguồn cấp giá, tức là giá trị của một tài sản (ví dụ: ETH) so với tài sản khác (ví dụ: USD), mạng oracle thường sẽ có được giá hiện tại từ một số nguồn, chẳng hạn như trao đổi. Mạng oracle thường gửi đến SC hợp đồng phụ thuộc giá trị trung bình của các giá trị này. Trong môi trường có ký dữ liệu, mạng oracle hoạt động chính xác sẽ nhận được từ nguồn dữ liệu S = {S1, . . . , SnS} dãy các giá trị V = {v1, v2, . . . , vnS} từ nS nguồn có chữ ký nguồn cụ thể đi kèm Σ = {σ1, σ2, . . . , σnS}. Khi xác minh chữ ký, nó truyền giá v = trung vị (V ) tới SC.Thật không may, không có cách đơn giản nào để mạng oracle truyền giá trị trung vị giá trị v trong Ví dụ 4 đến SC cùng với bằng chứng ngắn gọn σ∗rằng v đã được tính toán chính xác trên đầu vào đã ký. Một cách tiếp cận ngây thơ sẽ là mã hóa trong SC các khóa chung của tất cả các nguồn dữ liệu nS. Mạng oracle sau đó sẽ chuyển tiếp (V, Σ) và cho phép SC tính toán trung vị của V . Tuy nhiên, điều này sẽ dẫn đến một bằng chứng σ có kích thước O(nS)—tức là, σ∗sẽ không ngắn gọn. Nó cũng sẽ phải chịu chi phí gas cao cho SC, cần phải xác minh tất cả chữ ký trong Σ. Ngược lại, việc sử dụng SNARK cho phép chứng minh ngắn gọn về các giá trị nguồn được xác thực được kết hợp chính xác. Nó có thể khả thi trong thực tế, nhưng áp đặt khá cao chi phí tính toán trên bộ chuẩn và chi phí gas hơi cao trên dây chuyền. Sử dụng Town Crier cũng là một lựa chọn, nhưng yêu cầu sử dụng TEE, không phù hợp với tất cả mọi người. mô hình niềm tin của người dùng. Một khái niệm hữu ích để đưa ra các giải pháp cho vấn đề chung về ký dữ liệu kết hợp từ các nguồn là một công cụ mật mã được gọi là chữ ký chức năng [59, 132]. Tóm lại, chữ ký chức năng cho phép người ký ủy quyền khả năng ký, sao cho người được ủy quyền chỉ có thể ký các tin nhắn trong phạm vi chức năng F do người ký chọn. Chúng tôi trình bày trong Phụ lục D cách ràng buộc chức năng này có thể dùng để giới hạn phạm vi của các giá trị báo cáo do DON phát ra dưới dạng hàm của các giá trị được ký bởi nguồn dữ liệu. Chúng tôi cũng giới thiệu một dạng nguyên thủy mới, được gọi là chữ ký hàm rời rạc, bao gồm yêu cầu thoải mái về độ chính xác nhưng có khả năng hoạt động hiệu quả hơn nhiều. hơn các phương pháp tiếp cận như SNARK. Bài toán kết hợp các nguồn dữ liệu theo cách bao gồm xác thực nguồn của đầu ra cũng áp dụng cho các công cụ tổng hợp dữ liệu, ví dụ: CoinCap, CoinMarketCap, CoinGecko, CryptoCompare, v.v., thu thập dữ liệu từ nhiều sàn giao dịch mà chúng trọng lượng dựa trên khối lượng, sử dụng các phương pháp mà trong một số trường hợp họ công bố và trong các trường hợp khác là độc quyền. Một trình tổng hợp muốn xuất bản một giá trị với xác thực nguồn phải đối mặt với thách thức tương tự như việc tập hợp các nút tổng hợp dữ liệu nguồn. 7.1.4 Đang xử lý dữ liệu nguồn smart contract phức tạp có thể phụ thuộc vào số liệu thống kê tổng hợp tùy chỉnh trên nguồn dữ liệu chính, chẳng hạn như sự biến động trong lịch sử giá gần đây của nhiều tài sản hoặc văn bản và hình ảnh từ tin tức về các sự kiện thích hợp. Vì khả năng tính toán và băng thông tương đối rẻ trong DON nên những thống kê này— ngay cả các mô hình học máy phức tạp có nhiều đầu vào—cũng có thể được xử lý một cách tiết kiệm, miễn là mọi giá trị đầu ra dành cho blockchain đều đủ ngắn gọn. Đối với các công việc đòi hỏi tính toán chuyên sâu trong đó DON người tham gia có thể có các ý kiến khác nhau quan điểm về đầu vào phức tạp, các vòng giao tiếp bổ sung giữa những người tham gia DON có thể được yêu cầu thiết lập sự đồng thuận về đầu vào trước khi tính toán kết quả. Miễn là giá trị cuối cùng được xác định đầy đủ bởi đầu vào, khi sự đồng thuận đầu vào được thiết lập, mỗi người tham gia có thể chỉ cần tính giá trị và truyền nó cho người khácngười tham gia bằng chữ ký một phần của họ hoặc gửi nó đến một công cụ tổng hợp. 7.2 DON Giảm thiểu sự tin cậy Chúng tôi hình dung hai cách chính để giảm thiểu sự tin cậy đặt vào các thành phần của DON: khách hàng chuyển đổi dự phòng và báo cáo thiểu số. 7.2.1 Khách hàng chuyển đổi dự phòng Các mô hình đối nghịch trong tài liệu về mật mã và hệ thống phân tán thường xem xét một đối thủ có khả năng làm hỏng (tức là xâm phạm) một tập hợp con các nút, ví dụ: ít hơn một phần ba đối với nhiều giao thức BFT. Tuy nhiên, người ta thường quan sát thấy, rằng nếu tất cả các nút chạy phần mềm giống hệt nhau, kẻ thù xác định được một lỗi khai thác nghiêm trọng có thể về nguyên tắc thỏa hiệp tất cả các nút ít nhiều cùng một lúc. Cài đặt này thường được gọi là độc canh phần mềm [47]. Nhiều đề xuất khác nhau về việc tự động đa dạng hóa phần mềm và cấu hình phần mềm đã được đưa ra để giải quyết vấn đề, ví dụ: [47, 113]. Như đã lưu ý trong [47], tuy nhiên, tính đa dạng của phần mềm là một vấn đề phức tạp và cần được xem xét cẩn thận. Ví dụ, đa dạng hóa phần mềm có thể dẫn đến tình trạng bảo mật kém hơn so với độc canh nếu nó tăng bề mặt tấn công của hệ thống và do đó các vectơ tấn công có thể vượt quá những lợi ích bảo mật mà nó mang lại. Chúng tôi tin rằng sự hỗ trợ dành cho các ứng dụng khách chuyển đổi dự phòng mạnh mẽ—tức là các ứng dụng khách với nút nào có thể chuyển đổi khi đối mặt với một sự kiện thảm khốc—là một hình thức đặc biệt hấp dẫn của đa dạng hóa phần mềm. Máy khách chuyển đổi dự phòng không làm tăng số lượng vectơ tiềm năng bị tấn công vì chúng không được triển khai như phần mềm chính. Chúng mang lại lợi ích rõ ràng, tuy nhiên, như một tuyến phòng thủ thứ hai. Chúng tôi dự định hỗ trợ các máy khách chuyển đổi dự phòng trong DONs như một phương tiện chính để giảm sự phụ thuộc vào bảo mật của họ vào một khách hàng. Chainlink đã có sẵn một hệ thống máy khách chuyển đổi dự phòng mạnh mẽ. Cách tiếp cận của chúng tôi liên quan đến việc duy trì các phiên bản máy khách đã được thử nghiệm trong trận chiến trước đó. Ví dụ: ngày nay, các nút Chainlink với Báo cáo chuỗi Off (OCR) là khách hàng chính của họ bao gồm hỗ trợ cho hệ thống FluxMonitor trước đó của Chainlink nếu cần. Đã được sử dụng một số hiện tại, FluxMonitor đã nhận được kiểm tra bảo mật và thử nghiệm hiện trường. Nó cung cấp tương tự chức năng như OCR, nhưng với chi phí cao hơn—chi phí chỉ phát sinh khi cần thiết. 7.2.2 Báo cáo thiểu số Với một tập hợp thiểu số đủ lớn Ominority—một phần nhỏ các nút trung thực quan sát thấy sự sai trái của đa số—việc chúng tạo ra thiểu số có thể hữu ích. báo cáo. Đây là một báo cáo hoặc cờ song song, được chuyển tiếp đến hợp đồng phụ thuộc SC trên chuỗi của Ominority. SC có thể sử dụng cờ này theo chính sách dành riêng cho hợp đồng của mình. Ví dụ: đối với một hợp đồng trong đó sự an toàn quan trọng hơn tính sống động hoặc khả năng đáp ứng, báo cáo thiểu số có thể khiến hợp đồng yêu cầu báo cáo bổ sung. từ DON khác hoặc kích hoạt cầu dao (xem phần tiếp theo).Báo cáo của thiểu số có thể đóng một vai trò quan trọng ngay cả khi đa số là trung thực, bởi vì bất kỳ sơ đồ tổng hợp báo cáo nào, ngay cả khi nó sử dụng chữ ký chức năng, đều phải hoạt động theo ngưỡng để đảm bảo khả năng phục hồi trước oracle hoặc lỗi dữ liệu. trong nói cách khác, phải có khả năng tạo ra một báo cáo hợp lệ dựa trên thông tin đầu vào của kS < nS oracles, đối với một số ngưỡng kS. Điều này có nghĩa là DON bị hỏng có một số vĩ độ trong việc thao tác các giá trị báo cáo bằng cách chọn các giá trị kS ưa thích của nó trong số nS được báo cáo trong V bởi tập hợp đầy đủ oracles, ngay cả khi tất cả các nguồn đều trung thực. Ví dụ, giả sử nS = 10 và kS = 7 trong hệ thống sử dụng hàm chữ ký để xác thực tính toán trung bình trên V đối với giá ETH bằng USD. Giả sử có năm nguồn báo cáo mức giá \(500, while the other five report \)1000. Sau đó, bằng cách tính trung bình 7 báo cáo thấp nhất, DON có thể tạo ra giá trị hợp lệ v = $500, và bằng cách tính trung bình mức cao nhất, nó có thể tạo ra v = $1000. Bằng cách nâng cao giao thức DON để tất cả các nút đều biết dữ liệu nào được có sẵn và dữ liệu nào được sử dụng để xây dựng báo cáo, các nút có thể phát hiện và gắn cờ xu hướng có ý nghĩa thống kê để ưu tiên một tập hợp báo cáo hơn tập hợp khác và tạo ra kết quả là một báo cáo thiểu số. 7.3 Đường ray bảo vệ Mô hình tin cậy của chúng tôi dành cho DON coi MAINCHAIN là đặc quyền cao hơn, bảo mật cao hơn hệ thống hơn DONs. (Mặc dù mô hình tin cậy này có thể không phải lúc nào cũng đúng nhưng nó dễ dàng hơn để điều chỉnh cơ chế kết quả cho phù hợp với các tình huống trong đó DON có độ bảo mật cao hơn nền tảng hơn là ngược lại.) Do đó, chiến lược giảm thiểu sự tin cậy tự nhiên bao gồm việc triển khai các cơ chế giám sát và an toàn dự phòng trong smart contracts—trong giao diện người dùng MAINCHAIN cho DON hoặc trực tiếp trong hợp đồng phụ thuộc SC. Chúng tôi gọi những cơ chế này là lan can bảo vệ và liệt kê một số điều quan trọng nhất ở đây: • Bộ ngắt mạch: SC có thể tạm dừng hoặc dừng cập nhật trạng thái do chức năng của các đặc điểm của chính bản cập nhật trạng thái đó (ví dụ: phương sai lớn giữa các lần cập nhật trạng thái báo cáo) hoặc dựa trên các đầu vào khác. Ví dụ, một cầu dao có thể ngắt điện các trường hợp trong đó báo cáo oracle thay đổi đáng kể theo thời gian. Bộ ngắt mạch có thể cũng bị vấp ngã bởi một báo cáo thiểu số. Do đó, bộ ngắt mạch có thể ngăn chặn DONs khỏi việc đưa ra những báo cáo sai lầm trầm trọng. Bộ ngắt mạch có thể cung cấp thời gian để xem xét các biện pháp can thiệp bổ sung hoặc tập thể dục. Một sự can thiệp như vậy là cửa thoát hiểm. • Cửa thoát hiểm: Trong các trường hợp bất lợi, được xác định bởi một nhóm người giám hộ, chủ sở hữu token cộng đồng hoặc các cơ quan quản trị khác, hợp đồng có thể viện dẫn cơ sở khẩn cấp đôi khi được gọi là cửa thoát hiểm [163]. Một lối thoát hiểm khiến SC tắt theo cách nào đó và/hoặc chấm dứt đang chờ xử lý và có thể các giao dịch trong tương lai. Ví dụ: nó có thể trả lại tiền được lưu ký cho người dùng [17]),có thể chấm dứt các điều khoản hợp đồng [162] hoặc có thể hủy các giao dịch đang chờ xử lý và/hoặc trong tương lai [173]. Cửa thoát hiểm có thể được triển khai trong bất kỳ loại hợp đồng nào, không chỉ một cái dựa trên DON, nhưng chúng được quan tâm như một bộ đệm tiềm năng chống lại DON sự cố. • Chuyển đổi dự phòng: Trong các hệ thống mà SC dựa vào DON cho các dịch vụ thiết yếu, SC có thể cung cấp cơ chế chuyển đổi dự phòng để đảm bảo dịch vụ luôn được tiếp tục trong trường hợp DON thất bại hoặc hành vi sai trái. Ví dụ: trong TEF (Phần 6), hợp đồng neo SCa có thể cung cấp giao diện kép trong đó cả trên chuỗi và Giao diện thực thi ngoài chuỗi được hỗ trợ cho một số hoạt động quan trọng nhất định (ví dụ: rút tiền) hoặc đối với các giao dịch thông thường, với độ trễ phù hợp để ngăn chặn việc chạy trước các giao dịch DON. Trong trường hợp nguồn dữ liệu ký dữ liệu, người dùng có thể cũng cung cấp báo cáo cho SCa khi DON không thực hiện được. Bằng chứng gian lận, như được đề xuất cho các hình thức lạc quan khác nhau rollup (xem Phần 6.3), có hương vị tương tự và bổ sung cho các cơ chế mà chúng tôi liệt kê ở trên. Họ cũng cung cấp một hình thức giám sát và bảo vệ trên chuỗi chống lại các lỗi tiềm ẩn trong các thành phần hệ thống ngoài chuỗi. 7.4 Quản trị tối thiểu hóa niềm tin Giống như tất cả các hệ thống phi tập trung, mạng Chainlink yêu cầu cơ chế quản trị để điều chỉnh các thông số theo thời gian, ứng phó với các trường hợp khẩn cấp và hướng dẫn sự phát triển của nó. Một số cơ chế này hiện có trên MAINCHAIN và có thể tiếp tục làm như vậy ngay cả khi triển khai DONs. Một ví dụ là cơ chế thanh toán dành cho nhà cung cấp nút oracle (DON nút). DON hợp đồng giao diện người dùng trên MAINCHAIN chứa các cơ chế bổ sung, chẳng hạn như đường ray bảo vệ, có thể phải chịu sự kiểm soát định kỳ sửa đổi. Chúng tôi thấy trước hai loại cơ chế quản trị: tiến hóa và khẩn cấp. Quản trị tiến hóa: Nhiều sửa đổi đối với hệ sinh thái Chainlink được thực hiện sao cho việc thực hiện chúng không phải là vấn đề cấp bách: Cải thiện hiệu suất, cải tiến tính năng, nâng cấp bảo mật (không khẩn cấp), v.v. Khi Chainlink dần dần hướng tới nhiều người tham gia hơn nữa vào việc quản trị, chúng tôi mong đợi nhiều hoặc hầu hết những thay đổi như vậy sẽ được phê chuẩn bởi cộng đồng DON cụ thể bị ảnh hưởng bởi những thay đổi đó những thay đổi. Tạm thời và có lẽ cuối cùng là một cơ chế song song, chúng tôi tin rằng rằng khái niệm về đặc quyền tối thiểu tạm thời có thể là một phương tiện hữu ích để thực hiện quản trị tiến hóa. Rất đơn giản, ý tưởng là những thay đổi sẽ được triển khai dần dần, đảm bảo cộng đồng có cơ hội đáp ứng lại chúng. Ví dụ: di chuyển sang một nơi mới Hợp đồng MAINCHAIN có thể bị hạn chế để hợp đồng mới phải được triển khai ít nhất ba mươi ngày trước khi kích hoạt.Quản lý khẩn cấp: Các lỗ hổng có thể bị khai thác hoặc bị khai thác trong MAINCHAIN hợp đồng hoặc các hình thức mất an toàn hoặc sự sống khác có thể yêu cầu can thiệp ngay lập tức để đảm bảo chống lại các hậu quả thảm khốc. Mục đích của chúng tôi là hỗ trợ multisig cơ chế can thiệp trong đó, để đảm bảo chống lại hành vi sai trái của bất kỳ tổ chức nào, người ký sẽ được phân tán khắp các tổ chức. Đảm bảo sự sẵn có nhất quán của người ký và tiếp cận kịp thời các chuỗi lệnh thích hợp để cấp phép cho tình huống khẩn cấp những thay đổi rõ ràng sẽ yêu cầu lập kế hoạch hoạt động cẩn thận và xem xét thường xuyên. Những cái này những thách thức tương tự như những thách thức liên quan đến việc thử nghiệm khả năng ứng phó với sự cố an ninh mạng khác khả năng [134], với nhu cầu tương tự để chống lại các vấn đề thường gặp như suy giảm cảnh giác [223]. Việc quản trị DON khác với nhiều hệ thống phi tập trung trong đó mức độ tiềm tàng của sự không đồng nhất. Mỗi DON có thể có các nguồn dữ liệu, tệp thực thi, yêu cầu cấp độ dịch vụ như thời gian hoạt động và người dùng riêng biệt. Mạng Chainlink Cơ chế quản trị phải đủ linh hoạt để thích ứng với những thay đổi trong mục tiêu và thông số hoạt động. Chúng tôi đang tích cực khám phá các ý tưởng thiết kế và lên kế hoạch công bố nghiên cứu về chủ đề này trong tương lai. 7,5 Cơ sở hạ tầng khóa công khai Với sự phân cấp tiến bộ sẽ xuất hiện nhu cầu xác định rõ ràng các những người tham gia mạng, bao gồm các nút DON. Đặc biệt, Chainlink yêu cầu mạnh mẽ Cơ sở hạ tầng khóa công khai (PKI). PKI là một hệ thống liên kết các khóa với danh tính. cho Ví dụ: PKI hỗ trợ hệ thống kết nối an toàn (TLS) của Internet: Khi bạn kết nối với một trang web qua HTTPS (ví dụ: https://www.chainlinklabs.com) và một lock xuất hiện trong trình duyệt của bạn, điều đó có nghĩa là khóa chung của chủ sở hữu tên miền có được cơ quan có thẩm quyền ràng buộc với chủ sở hữu đó—cụ thể là thông qua chữ ký số trong cái gọi là chứng chỉ. Một hệ thống phân cấp của các cơ quan cấp chứng chỉ (CA), có các cơ quan cấp cao nhất được cài đặt sẵn vào các trình duyệt phổ biến, giúp đảm bảo rằng các chứng chỉ chỉ được cấp cho chủ sở hữu hợp pháp của tên miền. Chúng tôi hy vọng rằng Chainlink cuối cùng sẽ sử dụng các dịch vụ tên phi tập trung, ban đầu là Ethereum Dịch vụ tên (ENS) [22], làm nền tảng cho PKI của chúng tôi. Như Tên của nó gợi ý, ENS tương tự như DNS, Hệ thống tên miền ánh xạ (người có thể đọc được) thành địa chỉ IP trên internet. Tuy nhiên, thay vào đó, ENS ánh xạ các tên Ethereum mà con người có thể đọc được tới các địa chỉ blockchain. Bởi vì ENS hoạt động trên Ethereum blockchain, ngăn chặn việc xâm phạm khóa, giả mạo khóa của nó không gian tên về nguyên tắc cũng khó như việc giả mạo hợp đồng quản lý nó và/hoặc blockchain cơ bản. (Ngược lại, DNS trước đây dễ bị tấn công để giả mạo, chiếm quyền điều khiển và các cuộc tấn công khác.) Chúng tôi đã đăng ký data.eth với ENS trên mạng chính Ethereum và dự định thiết lập nó như một không gian tên gốc, trong đó danh tính của các dịch vụ dữ liệu oracle và Chainlink thực thể mạng khác cư trú. Các miền trong ENS có tính phân cấp, nghĩa là mỗi miền có thể chứa các tham chiếu với các tên khác dưới nó. Tên miền phụ trong ENS có thể dùng như một cách để tổ chức vàủy thác sự tin tưởng. Vai trò chính của data.eth sẽ là phục vụ như một dịch vụ thư mục trên chuỗi cho nguồn cấp dữ liệu. Theo truyền thống, các nhà phát triển và người dùng oracle thường sử dụng các nguồn ngoài chuỗi (ví dụ: các trang web như docs.chain.link hoặc data.chain.link hoặc các mạng xã hội như Twitter) để xuất bản và lấy oracle địa chỉ nguồn cấp dữ liệu (chẳng hạn như giá ETH-USD thức ăn). Với không gian tên gốc có độ tin cậy cao như data.eth, thay vào đó, có thể thiết lập ánh xạ eth-usd.data.eth tới địa chỉ smart contract của công cụ tổng hợp mạng oracle trên chuỗi cho nguồn cấp dữ liệu giá ETH-USD. Điều này sẽ tạo đường dẫn an toàn để mọi người tham khảo blockchain làm nguồn thông tin chính xác cho nguồn cấp dữ liệu của cặp giá/tên đó (ETH-USD). Do đó, việc sử dụng ENS như vậy nhận ra hai lợi ích không có sẵn trong các nguồn dữ liệu ngoài chuỗi: • Bảo mật mạnh mẽ: Mọi thay đổi, cập nhật tên miền đều được ghi lại bất biến và được bảo mật bằng mật mã, trái ngược với địa chỉ văn bản trên một trang web, không được hưởng cả hai đặc tính bảo mật này. • Tuyên truyền tự động trên chuỗi: Cập nhật địa chỉ cơ bản của smart contract của nguồn cấp dữ liệu có thể kích hoạt thông báo truyền đến thông minh phụ thuộc hợp đồng và có thể, ví dụ, tự động cập nhật các hợp đồng phụ thuộc với các địa chỉ mới.13 Tuy nhiên, các không gian tên như ENS không tự động xác thực quyền sở hữu hợp pháp của những cái tên đã được khẳng định. Vì vậy, ví dụ, nếu không gian tên bao gồm mục ⟨“Acme Oracle Node Co.”, addr⟩, sau đó người dùng nhận được sự đảm bảo rằng addr thuộc về người yêu cầu tên Acme Oracle Node Co. Nếu không có cơ chế bổ sung về quản trị vùng tên, tuy nhiên, cô ấy không có được sự đảm bảo rằng tên đó thuộc về một thực thể một cách hợp pháp được gọi là Acme Oracle Node Co. theo nghĩa có ý nghĩa trong thế giới thực. Cách tiếp cận của chúng tôi để xác thực tên, tức là đảm bảo quyền sở hữu của chúng bởi các thực thể hợp pháp, tương ứng trong thế giới thực, dựa vào một số thành phần. Hôm nay, Chainlink Phòng thí nghiệm hoạt động hiệu quả như một CA cho mạng Chainlink. Trong khi Chainlink Lab sẽ tiếp tục để xác thực tên, PKI của chúng tôi sẽ phát triển thành một mô hình phi tập trung hơn theo hai cách: • Mô hình web-of-trust: Đối tác phi tập trung của PKI phân cấp thường được gọi là web-of-trust.14 Các biến thể đã được đề xuất từ những năm 1990, ví dụ: [98] và một số nhà nghiên cứu đã quan sát thấy rằng blockchain có thể tạo điều kiện thuận lợi cho việc sử dụng ý tưởng, ví dụ: [227] bằng cách ghi lại các chứng chỉ theo cách nhất quán trên toàn cầu sổ cái. Chúng tôi đang khám phá các biến thể của mô hình này để xác thực danh tính của các thực thể trong mạng Chainlink theo cách phi tập trung hơn. Hợp đồng phụ thuộc 13A có thể tùy chọn bao gồm thời gian trì hoãn được xác định trước để cho phép kiểm tra thủ công và sự can thiệp của các quản trị viên hợp đồng phụ thuộc. 14Thuật ngữ do Phil Zimmermann đặt ra cho PGP [238].• Liên kết với dữ liệu xác thực: Ngày nay, một lượng đáng kể dữ liệu hiệu suất nút oracle được hiển thị trên chuỗi và do đó được liên kết lưu trữ với các địa chỉ nút. Dữ liệu đó có thể được xem là làm phong phú thêm danh tính trong PKI bằng cách cung cấp bằng chứng lịch sử về sự tham gia (đáng tin cậy) của nó trong mạng. Ngoài ra, công cụ để nhận dạng phi tập trung dựa trên DECO và Town Crier [160] kích hoạt các nút để tích lũy thông tin xác thực có nguồn gốc từ dữ liệu trong thế giới thực. Chỉ là một ví dụ, một nhà điều hành nút có thể đính kèm thông tin xác thực vào danh tính PKI của nó để chứng minh quyền sở hữu theo xếp hạng của Dun và Bradstreet. Những hình thức xác nhận bổ sung này có thể bổ sung staking trong việc tạo sự đảm bảo an ninh mạng. Nút oracle có danh tính trong thế giới thực đã được thiết lập có thể được xem là có cổ phần trong một hệ thống xuất phát từ danh tiếng của nó. (Xem Phần 4.3 và Phần 9.6.3.) Yêu cầu cuối cùng đối với Chainlink PKI là khởi động an toàn, tức là an toàn xuất bản tên gốc cho mạng Chainlink, hiện tại là data.eth (tương tự nối cứng các tên miền cấp cao nhất trong trình duyệt). Nói cách khác, làm thế nào để Chainlink người dùng xác định rằng data.eth thực sự là miền cấp cao nhất được liên kết với Chainlink dự án? Giải pháp cho vấn đề này cho mạng Chainlink là đa hướng và có thể liên quan đến: • Thêm bản ghi TXT [224] vào bản ghi tên miền của chúng tôi cho chain.link chỉ định data.eth làm miền gốc cho hệ sinh thái Chainlink. (Chainlink do đó ngầm tận dụng PKI cho các miền internet để xác thực miền ENS gốc của nó.) • Liên kết tới data.eth từ trang web hiện tại của Chainlink, ví dụ: từ https://docs.chain.link. (Một cách sử dụng PKI ngầm khác cho các miền internet.) • Sử dụng data.eth được biết đến qua nhiều tài liệu khác nhau, bao gồm cả báo cáo chính thức này. • Đăng công khai data.eth trên các kênh truyền thông xã hội của chúng tôi, chẳng hạn như Twitter và blog Chainlink [18]. • Đặt một số lượng lớn LINK dưới sự kiểm soát của cùng một địa chỉ người đăng ký như 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 في الوقت المناسب، وما إلى ذلك.
DON Cân nhắc triển khai
Mặc dù không phải là một phần trong thiết kế cốt lõi của chúng tôi nhưng có một số cân nhắc kỹ thuật quan trọng trong việc nhận ra DON đáng được điều trị ở đây.
8.1 Phương pháp triển khai Bài viết này đưa ra một tầm nhìn đầy tham vọng về chức năng Chainlink nâng cao mà Việc hiện thực hóa sẽ đòi hỏi các giải pháp cho nhiều thách thức trên đường đi. Sách trắng này xác định một số thách thức, nhưng những thách thức không lường trước được chắc chắn sẽ phát sinh. Chúng tôi dự định triển khai các yếu tố của tầm nhìn này theo cách tăng dần theo thời gian. khoảng thời gian kéo dài. Kỳ vọng của chúng tôi là DON ban đầu sẽ khởi chạy với hỗ trợ cho các thành phần dựng sẵn cụ thể được các nhóm trong nhóm hợp tác xây dựng Chainlink cộng đồng. Mục đích là sử dụng DONs rộng rãi hơn, ví dụ: khả năng khởi chạy các tệp thực thi tùy ý, sẽ thấy hỗ trợ sau. Một lý do cần thận trọng như vậy là thành phần của smart contract có thể có những tác dụng phụ phức tạp, ngoài ý muốn và nguy hiểm, như các cuộc tấn công dựa trên khoản vay nhanh gần đây đã gây ra ví dụ được hiển thị [127, 189]. Tương tự, thành phần của smart contract, bộ điều hợp và các tệp thực thi sẽ yêu cầu hết sức cẩn thận. Trong quá trình triển khai DON ban đầu, chúng tôi dự định chỉ bao gồm một tập hợp các bộ điều hợp và thực thi được tạo khuôn mẫu dựng sẵn. Điều này sẽ cho phép nghiên cứu về an ninh thành phần của các chức năng này bằng cách sử dụng các phương pháp hình thức [46, 170] và các cách tiếp cận khác. Nó sẽ cũng đơn giản hóa việc định giá: Việc định giá chức năng có thể được thiết lập bởi các nút DON trên cơ sở chức năng, thay vì thông qua đo lường tổng quát, một cách tiếp cận được áp dụng trong, ví dụ: [156]. Chúng tôi cũng mong muốn cộng đồng Chainlink tham gia vào quá trình tạo các mẫu bổ sung, kết hợp nhiều bộ điều hợp và tệp thực thi khác nhau để ngày càng các dịch vụ phi tập trung hữu ích có thể được điều hành bởi hàng trăm, nếu không phải hàng nghìn cá nhân DONs. Ngoài ra, cách tiếp cận này có thể giúp ngăn ngừa sự phình to của trạng thái, tức là nhu cầu DON các nút để giữ lại một lượng trạng thái không thể thực hiện được trong bộ nhớ làm việc. Vấn đề này là đã phát sinh trong blockchains không được phép, thúc đẩy các phương pháp tiếp cận như “không quốc tịch khách hàng” (xem ví dụ: [206]). Nó có thể gay gắt hơn trong các hệ thống thông lượng cao hơn, thúc đẩy một cách tiếp cận trong đó DON chỉ triển khai các tệp thực thi được tối ưu hóa theo quy mô trạng thái. Khi DON phát triển và hoàn thiện, đồng thời bao gồm các rào chắn bảo vệ mạnh mẽ, như được thảo luận trong Phần 7, các cơ chế bảo mật dựa trên danh tiếng và kinh tế tiền điện tử như được thảo luận trong Phần 9, cũng như các tính năng khác cung cấp mức độ đảm bảo cao cho người dùng DON, chúng tôi cũng mong muốn phát triển một khuôn khổ và các công cụ để tạo điều kiện cho việc triển khai và sử dụng rộng rãi hơn DON bởi cộng đồng. Lý tưởng nhất là những công cụ này sẽ cho phép một tập hợp các toán tử nút kết hợp với nhau thành một mạng oracle và khởi chạy DON của riêng họ theo cách không cần cấp phép hoặc theo cách tự phục vụ, nghĩa là họ có thể đơn phương thực hiện việc đó. 8.2 Năng động DON Tư cách thành viên Tập hợp các nút chạy DON nhất định có thể thay đổi theo thời gian. Có hai cách tiếp cận quản lý khóa cho skL với tư cách thành viên năng động trong O. Đầu tiên là cập nhật phần chia sẻ của skL do các nút nắm giữ khi có thay đổi về tư cách thành viên, trong khi vẫn giữ pkL không thay đổi. Cách tiếp cận này, được khám phá trong [41, 161, 198], có giá trị không yêu cầu các bên liên quan cập nhật pkL.Kỹ thuật chia sẻ lại chia sẻ cổ điển, được giới thiệu trong [122], cung cấp một cách đơn giản và cách hiệu quả để hiện thực hóa các cập nhật chia sẻ đó. Nó cho phép một bí mật được chuyển giao giữa một tập hợp các nút O(1) và một giây, có thể giao nhau với một O(2). Trong này cách tiếp cận, mỗi nút O(1) tôi thực hiện (k(2), n(2)) chia sẻ bí mật việc chia sẻ bí mật của nó trên các nút trong O(2) với n(2) = |O(2)| và ngưỡng mong muốn (có thể là mới) k(2). Các sơ đồ chia sẻ bí mật có thể xác minh (VSS) khác nhau [108] có thể cung cấp bảo mật chống lại kẻ thù chủ động làm hỏng các nút, tức là đưa hành vi nguy hiểm vào giao thức. Các kỹ thuật trong [161] nhằm mục đích thực hiện điều đó đồng thời giảm độ phức tạp trong giao tiếp và cung cấp khả năng phục hồi chống lại các thất bại trong các giả định về độ cứng của mật mã. Cách tiếp cận thứ hai là cập nhật khóa sổ cái pkL. Điều này có lợi ích về phía trước bảo mật: Việc thỏa hiệp các cổ phiếu cũ của pkL (tức là các nút ủy ban cũ) sẽ không dẫn đến sự thỏa hiệp của khóa hiện tại. Tuy nhiên, các bản cập nhật lên pkL có hai nhược điểm: (1) Dữ liệu được mã hóa theo pkL cần được mã hóa lại trong quá trình làm mới khóa và (2) Các cập nhật quan trọng cần được phổ biến tới các bên tin cậy. Chúng tôi dự định khám phá cả hai cách tiếp cận cũng như sự kết hợp của cả hai. 8.3 DON Trách nhiệm Giống như các mạng Chainlink oracle hiện có, DON sẽ bao gồm các cơ chế về trách nhiệm giải trình, tức là ghi lại, giám sát và thực thi hành vi chính xác của nút. DONs sẽ có dung lượng dữ liệu đáng kể hơn nhiều so với nhiều blockchain không được phép hiện có, đặc biệt là khả năng kết nối với bộ lưu trữ phi tập trung bên ngoài. Do đó, họ sẽ có thể ghi lại lịch sử hiệu suất của các nút một cách chi tiết, cho phép cơ chế trách nhiệm giải trình chi tiết hơn. Ví dụ: tính toán ngoài chuỗi của giá tài sản có thể liên quan đến các yếu tố đầu vào bị loại bỏ trước khi kết quả trung bình được gửi đi chuỗi. Trong DON, những kết quả trung gian này có thể được ghi lại. Do đó, hành vi sai trái hoặc mất hiệu suất của các nút riêng lẻ trong DON có thể được khắc phục hoặc bị phạt đối với DON một cách chi tiết. Chúng tôi cũng đã thảo luận thêm về các phương pháp xây dựng lan can bảo vệ trong Phần 7.3 đề cập đến tác động cụ thể theo hợp đồng của các lỗi hệ thống. Tuy nhiên, điều quan trọng là phải có cơ chế an toàn cho chính DON, tức là, các biện pháp bảo vệ chống lại các lỗi hệ thống, có khả năng gây thảm họa DON, cụ thể là các lỗi phân nhánh/không rõ ràng và thỏa thuận cấp độ dịch vụ (SLA), như chúng tôi giải thích hiện nay. Phân nhánh/không rõ ràng: Với đủ nhiều nút bị lỗi, DON có thể phân nhánh hoặc lập lờ, tạo ra hai khối hoặc chuỗi khối riêng biệt, không nhất quán trong L. Tuy nhiên, vì DON ký điện tử vào nội dung của L nên có thể tận dụng chuỗi chính MAINCHAIN để ngăn chặn và/hoặc trừng phạt hành vi không rõ ràng. DON có thể kiểm tra định kỳ trạng thái điểm từ L trong hợp đồng kiểm tra trên MAINCHAIN. Nếu trạng thái trong tương lai của nó khác với trạng thái được kiểm tra, người dùng/kiểm toán viên có thể đưa ra bằng chứng về hành vi sai trái này đối với hợp đồng kiểm toán. Bằng chứng như vậy có thể được sử dụng để tạo ra một cảnh báo hoặc phạt DON nút bằng cách gạch chéo trong hợp đồng. Cách tiếp cận sau này giới thiệu một vấn đề thiết kế khuyến khích tương tự như vấn đề đối với các nguồn cấp dữ liệu oracle cụ thể và có thể xây dựng dựa trên công việc của chúng tôi được nêu trong Phần 9.Thực thi các thỏa thuận cấp độ dịch vụ: Mặc dù DON không nhất thiết nhằm mục đích chạy vô thời hạn, điều quan trọng là chúng phải tuân thủ các thỏa thuận cấp độ dịch vụ (SLA) với người dùng của họ. Có thể thực thi SLA cơ bản trên chuỗi chính. Ví dụ, Các nút DON có thể cam kết duy trì DON cho đến một ngày nhất định hoặc cung cấp thông báo trước về việc chấm dứt dịch vụ (ví dụ: thông báo trước ba tháng). Một hợp đồng trên MAINCHAIN có thể cung cấp việc thực thi SLA kinh tế tiền điện tử cơ bản. Ví dụ: hợp đồng SLA có thể cắt giảm số tiền ký gửi DON nếu điểm kiểm tra không được cung cấp ở những khoảng thời gian cần thiết. Người dùng có thể gửi tiền và thách thức DON để chứng minh rằng điểm kiểm tra thể hiện chính xác một chuỗi các khối hợp lệ (theo cách tương tự như, ví dụ: [141]). Tất nhiên, sản xuất khối không đồng nghĩa với giao dịch. xử lý, nhưng hợp đồng SLA cũng có thể dùng để thực thi quy trình sau. Ví dụ, trong phiên bản tương thích cũ của FSS trong đó các giao dịch được tìm nạp từ mempool (xem Phần 5.2), các giao dịch cuối cùng sẽ được khai thác và đặt trên chuỗi. Một người dùng có thể chứng minh DON hành vi sai trái bằng cách cung cấp cho hợp đồng SLA một giao dịch đã được khai thác nhưng không được DON truyền đi để hợp đồng mục tiêu xử lý trong khoảng thời gian thích hợp.15 Cũng có thể chứng minh sự tồn tại và xử phạt SLA chi tiết hơn các lỗi, bao gồm các lỗi trong tính toán sử dụng các tệp thực thi (ví dụ: thông qua các cơ chế để chứng minh các giao dịch trạng thái ngoài chuỗi chính xác được nêu trong Phần 6.3) hoặc không chạy được các tệp thực thi dựa trên các trình khởi tạo hiển thị trên DON, không thể chuyển tiếp dữ liệu trên DON tới MAINCHAIN một cách kịp thời, v.v.
الاقتصاد والاقتصاد المشفر
لكي تتمكن شبكة 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 أن تساعد في تحقيق اقتصاد متصل بالسلسلة من أجل اللامركزية الخدمات.
Kinh tế và kinh tế tiền điện tử
Để mạng Chainlink đạt được mức độ bảo mật mạnh mẽ trong mô hình tin cậy phi tập trung, điều cần thiết là các nút phải thể hiện hành vi đúng đắn một cách tập thể, nghĩa là chúng tuân thủ phần lớn thời gian đều chính xác với các giao thức DON. Trong phần này, chúng tôi thảo luận về các phương pháp để giúp thực thi hành vi đó bằng các biện pháp khuyến khích kinh tế, hay còn gọi là kinh tế tiền điện tử khuyến khích. Những ưu đãi này được chia thành hai loại: rõ ràng và tiềm ẩn, được thực hiện tương ứng thông qua staking và cơ hội thu phí trong tương lai (FFO). Đặt cọc: Đặt cược vào Chainlink, giống như trong các hệ thống blockchain khác, bao gồm những người tham gia mạng, tức là các nút oracle, gửi tiền bị khóa dưới dạng LINK tokens. Những cái này quỹ mà chúng tôi còn gọi là cổ phần hoặc cổ phần rõ ràng là một động lực rõ ràng. Họ có thể bị mất khi nút bị lỗi hoặc trục trặc. Trong ngữ cảnh blockchain, thủ tục này thường được gọi là chém. Tuy nhiên, việc đặt cược bởi các nút oracle trong Chainlink về cơ bản khác với staking bởi validator giây trong blockchain giây không được phép. Người xác nhận có thể hoạt động sai bằng cách đặt hàng các giao dịch không rõ ràng hoặc đối nghịch. Giao thức đồng thuận cơ bản trong một 15Vì người dùng có thể thay thế các giao dịch trong mempool nên cần phải cẩn thận để đảm bảo sự tương ứng chính xác giữa các giao dịch được khai thác và DON đã gửi.Tuy nhiên, blockchain không được phép sử dụng các quy tắc xác thực khối nhanh chóng và nguyên gốc bằng mật mã để ngăn validator tạo các khối không hợp lệ. Ngược lại, các biện pháp bảo vệ có lập trình không thể ngăn mạng oracle gian lận tạo ra báo cáo không hợp lệ. Lý do là sự khác biệt chính giữa hai loại hệ thống: xác thực giao dịch trong blockchains là thuộc tính của tính nhất quán nội bộ, trong khi tính chính xác của oracle báo cáo về blockchain là thuộc tính của dữ liệu bên ngoài, tức là dữ liệu ngoài chuỗi. Chúng tôi đã thiết kế cơ chế staking sơ bộ cho mạng Chainlink dựa trên trên giao thức tương tác giữa các nút oracle có thể sử dụng dữ liệu bên ngoài. Cái này cơ chế tạo ra các khuyến khích tài chính cho hành vi đúng đắn bằng cách sử dụng các phần thưởng và hình phạt (chém). Vì cơ chế này mang tính kinh tế nên nó được thiết kế để ngăn chặn nút tham nhũng bởi kẻ thù sử dụng nguồn tài chính để làm hỏng các nút bằng cách hối lộ. (Đối thủ như vậy rất chung chung và mở rộng, ví dụ: tới các nút hợp tác với rút ra giá trị từ hành vi sai trái tập thể của họ.) Cơ chế Chainlink staking mà chúng tôi đã thiết kế có một số cơ chế mạnh mẽ và mới lạ tính năng.16 Tính năng chính như vậy là tác động siêu tuyến tính staking (cụ thể là bậc hai). Đối thủ phải có tài nguyên vượt quá đáng kể số tiền gửi của các nút trong nhằm phá hoại cơ chế. Cơ chế staking của chúng tôi còn cung cấp thêm khả năng bảo vệ chống lại đối thủ mạnh hơn so với những gì đã được xem xét trước đây trong các hệ thống tương tự, cụ thể là một kẻ thù có thể đưa ra hối lộ điều chỉnh hành vi trong tương lai của các nút. Ngoài ra, chúng tôi còn thảo luận về cách các công cụ Chainlink như DECO có thể giúp củng cố staking của chúng tôi cơ chế bằng cách tạo điều kiện cho việc xét xử chính xác trong trường hợp nút hoạt động bị lỗi. Cơ hội thu phí trong tương lai (FFO): blockchains không được phép—của cả PoW và sự đa dạng của PoS—ngày nay chủ yếu dựa vào cái mà chúng tôi gọi là động cơ ngầm. Đây là khuyến khích kinh tế cho hành vi trung thực không xuất phát từ những phần thưởng rõ ràng, mà là từ chính sự tham gia của nền tảng. Ví dụ: cộng đồng thợ mỏ Bitcoin được khuyến khích chống lại việc thực hiện cuộc tấn công 51% do nguy cơ làm suy yếu niềm tin vào Bitcoin, làm giảm giá trị của nó và do đó làm xói mòn giá trị tập thể của họ đầu tư vốn vào cơ sở hạ tầng khai thác mỏ [150]. Mạng Chainlink được hưởng lợi từ động cơ ngầm tương tự mà chúng tôi đề cập đến như cơ hội phí trong tương lai (FFO). Các nút Oracle có lịch sử hiệu suất mạnh mẽ hoặc danh tiếng thu hút phí từ người dùng. Hành vi sai trái của nút oracle gây nguy hiểm cho tương lai thanh toán phí và do đó phạt nút bằng chi phí cơ hội về mặt tiềm năng doanh thu kiếm được thông qua việc tham gia vào mạng lưới. Bằng cách tương tự với cổ phần rõ ràng, FFO có thể được xem như một dạng cổ phần tiềm ẩn, một động cơ khuyến khích hành vi trung thực bắt nguồn từ lợi ích chung của việc duy trì niềm tin vào nền tảng mà trên đó Hoạt động kinh doanh của nhà khai thác nút phụ thuộc vào, tức là hiệu suất tích cực và danh tiếng của mạng. Khuyến khích này vốn có nhưng không được thể hiện rõ ràng trong mạng Chainlink giao thức. Trong Bitcoin, duy trì giá trị của hoạt động khai thác như đã đề cập ở trên 16Cơ chế staking mà chúng tôi mô tả ở đây hiện chỉ nhằm mục đích thực thi việc gửi báo cáo chính xác bởi oracle mạng. Chúng tôi hy vọng trong công việc tương lai sẽ mở rộng nó để đảm bảo thực hiện đúng nhiều các chức năng khác DON sẽ cung cấp.tương tự có thể được xem như một hình thức cổ phần tiềm ẩn. Chúng tôi nhấn mạnh rằng FFO đã tồn tại trong Chainlink và giúp bảo mật mạng hôm nay. Đóng góp chính của chúng tôi trong việc phát triển hơn nữa Chainlink sẽ là cách tiếp cận có nguyên tắc, dựa trên kinh nghiệm để đánh giá các biện pháp khuyến khích ngầm như FFO thông qua cái mà chúng tôi gọi là Khung khuyến khích tiềm ẩn (IIF). Để ước tính số lượng như cơ hội thu phí trong tương lai của các nút, IIF sẽ liên tục dựa trên toàn diện dữ liệu hiệu suất và thanh toán được mạng Chainlink tích lũy. Những ước tính như vậy sẽ cho phép tham số hóa dựa trên IIF của các hệ thống staking phản ánh khuyến khích nút với độ chính xác cao hơn các mô hình heuristic và/hoặc tĩnh hiện tại. Tóm lại, hai động lực kinh tế chính cho nút oracle chính xác hành vi trong mạng Chainlink đang phát triển sẽ là: • Đặt cọc (đặt cọc) ồ Khuyến khích rõ ràng • Cơ hội thu phí trong tương lai (FFO) ồ Khuyến khích ngầm Hai hình thức khuyến khích này bổ sung cho nhau. Các nút Oracle có thể đồng thời tham gia vào giao thức Chainlink staking, tận hưởng luồng doanh thu liên tục từ người dùng và cùng được hưởng lợi từ hành vi tốt liên tục của họ. Như vậy cả hai biện pháp khuyến khích góp phần bảo mật kinh tế tiền điện tử do mạng oracle cung cấp. Ngoài ra, hai động cơ khuyến khích này có thể củng cố và/hoặc được trao đổi với nhau. Ví dụ, toán tử oracle mới không có lịch sử hiệu suất và luồng doanh thu có thể đặt cược số lượng lớn LINK như một sự đảm bảo cho hành vi trung thực, từ đó thu hút người dùng và phí. Ngược lại, một toán tử oracle đã được thiết lập có thời gian dài, tương đối không có lỗi lịch sử hiệu suất có thể tính phí đáng kể từ cơ sở người dùng lớn và do đó dựa vào nặng nề hơn vào FFO của nó như một hình thức khuyến khích ngầm. Nói chung, cách tiếp cận mà chúng tôi xem xét ở đây nhằm vào số lượng oracle mạng nhất định nguồn lực để tạo ra các khuyến khích kinh tế lớn nhất có thể trong Chainlink cho hợp lý các đại lý—tức là các nút tối đa hóa tiện ích tài chính của họ—hành xử trung thực. Đặt cái khác theo cách này, mục tiêu là tối đa hóa nguồn tài chính cần thiết để đối thủ tấn công mạng thành công. Bằng cách xây dựng giao thức staking với tính toán tốt an ninh kinh tế được xác định và cũng sử dụng IIF, chúng tôi mong muốn đo lường sức mạnh của Ưu đãi của Chainlink chính xác nhất có thể. Những người tạo ra các hợp đồng dựa trên sẽ sau đó có thể xác định một cách chắc chắn liệu mạng oracle có đáp ứng được không mức độ bảo mật kinh tế tiền điện tử cần thiết của họ. Chu kỳ đạo đức của an ninh kinh tế: Các biện pháp khuyến khích mà chúng ta thảo luận trong phần này, staking và FFO, có tác động vượt ra ngoài việc tăng cường tính bảo mật của DONs. Họ hứa sẽ tạo ra cái mà chúng ta gọi là một chu kỳ an ninh kinh tế có đạo đức. Tác động siêu tuyến tính staking (và tính kinh tế theo quy mô khác) dẫn đến hiệu quả hoạt động thấp hơn chi phí khi mức độ bảo mật của DON tăng lên. Chi phí thấp hơn sẽ thu hút thêm người dùng vào DON,tăng cường thanh toán phí. Sự gia tăng trong thanh toán phí tiếp tục khuyến khích sự tăng trưởng của mạng lưới, giúp duy trì chu kỳ đạo đức. Chúng tôi tin rằng chu kỳ lành mạnh của an ninh kinh tế chỉ là một ví dụ về tính kinh tế theo quy mô và hiệu ứng mạng trong số những vấn đề khác mà chúng ta sẽ thảo luận sau trong phần này. Tổ chức phần: Đặt cọc đưa ra những thách thức đáng chú ý về mặt kỹ thuật và khái niệm cho mà chúng tôi đã thiết kế một cơ chế với các tính năng mới. Do đó, việc đặt cược sẽ được trọng tâm chính của chúng tôi trong phần này. Chúng tôi cung cấp tổng quan về cách tiếp cận staking mà chúng tôi giới thiệu trong bài viết này ở Phần 9.1, sau đó là thảo luận chi tiết trong Phần 9.2 đến 9.5. Chúng tôi trình bày IFF trong Phần 9.6. Chúng tôi trình bày quan điểm tóm tắt về Chainlink ưu đãi mạng trong Phần 9.7. Trong Phần 9.8, chúng tôi thảo luận về chu kỳ hợp lý của an ninh kinh tế mà phương pháp staking được đề xuất của chúng tôi có thể mang lại cho các mạng oracle. Cuối cùng, chúng tôi mô tả ngắn gọn các tiềm năng khác tác động thúc đẩy sự phát triển của mạng Chainlink trong Phần 9.9. 9.1 Tổng quan về đặt cược Thiết kế cơ chế staking mà chúng tôi giới thiệu ở đây, như đã lưu ý ở trên, bao gồm một giao thức tương tác giữa các nút oracle cho phép giải quyết sự không nhất quán trong báo cáo dữ liệu bên ngoài. Đặt cược nhằm mục đích đảm bảo hành vi trung thực từ các nút oracle hợp lý. Do đó, chúng ta có thể lập mô hình đối thủ tấn công giao thức staking dưới dạng kẻ hối lộ: Chiến lược của kẻ thù là mua chuộc các nút oracle bằng cách sử dụng các biện pháp khuyến khích tài chính. Kẻ thù có thể lấy được nguồn tài chính từ việc giả mạo thành công với báo cáo oracle, ví dụ: đề nghị chia sẻ lợi nhuận thu được với các nút bị hỏng. Chúng tôi hướng tới thiết kế cơ chế staking của mình đồng thời hai mục tiêu đầy tham vọng: 1. Chống lại kẻ thù hùng mạnh: Cơ chế staking được thiết kế để bảo vệ oracle mạng lưới chống lại một nhóm đối thủ rộng lớn có khả năng phức tạp, chiến lược hối lộ có điều kiện, bao gồm cả hối lộ tiềm năng, đưa hối lộ tới oracle có danh tính được xác định sau sự việc (ví dụ: đưa hối lộ cho oracle được chọn ngẫu nhiên để cảnh báo mức độ ưu tiên cao). Trong khi các thiết kế oracle khác đã xem xét một loạt các cuộc tấn công hẹp mà không có đầy đủ khả năng thực tế đối thủ, theo hiểu biết tốt nhất của chúng tôi, cơ chế đối nghịch mà chúng tôi giới thiệu đây là lần đầu tiên đề cập một cách rõ ràng một loạt các chiến lược hối lộ và chỉ ra kháng cự trong mô hình này. Mô hình của chúng tôi giả định rằng các nút bên cạnh kẻ tấn công là hợp lý về mặt kinh tế (trái ngược với trung thực) và chúng tôi giả định sự tồn tại của một nguồn sự thật cực kỳ tốn kém cho việc sử dụng thông thường nhưng có sẵn trong trường hợp không đồng ý (được thảo luận thêm bên dưới). 2. Đạt được tác động siêu tuyến tính staking: Mục tiêu của chúng tôi là đảm bảo rằng mạng oracle bao gồm các báo cáo tác nhân hợp lý trung thực ngay cả khi có sự hiện diện của kẻ tấn công với ngân sách siêu tuyến tínhtrong tổng số cổ phần được gửi bởi toàn bộ mạng lưới. Trong các hệ thống staking hiện có, nếu mỗi nút trong số n nút đặt cược $d, kẻ tấn công có thể đưa ra một khoản hối lộ đáng tin cậy yêu cầu các nút đó hành xử không trung thực để đổi lấy khoản thanh toán nhiều hơn một chút \(d to each node, using a total budget of about \)dn. Đây đã là một thanh cao như kẻ tấn công phải có một ngân sách thanh khoản theo thứ tự tổng số tiền gửi của tất cả các staker trong mạng. Mục tiêu của chúng tôi là mức độ an ninh kinh tế cao hơn nữa hơn trở ngại vốn đã đáng kể này. Chúng tôi mong muốn thiết kế hệ thống staking đầu tiên có thể đạt được sự bảo mật cho kẻ tấn công thông thường với ngân sách siêu tuyến tính trong n. Mặc dù những cân nhắc thực tế có thể đạt được tác động thấp hơn, như chúng tôi thảo luận dưới đây, thiết kế sơ bộ của chúng tôi đạt được yêu cầu ngân sách đối nghịch lớn hơn $dn2/2, tức là, chia tỷ lệ bậc hai theo n, thậm chí khiến việc hối lộ hầu như không thực tế khi các nút chỉ đặt cược số tiền vừa phải. Để đạt được hai mục tiêu này đòi hỏi sự kết hợp sáng tạo giữa thiết kế khuyến khích và mật mã. Ý tưởng chính: Cách tiếp cận staking của chúng tôi xoay quanh một ý tưởng mà chúng tôi gọi là ưu tiên của cơ quan giám sát. Báo cáo được tạo bởi mạng Chainlink oracle và được gửi tới hợp đồng phụ thuộc (ví dụ: về giá tài sản) được tổng hợp từ các báo cáo riêng lẻ do các nút tham gia đóng góp (ví dụ: bằng cách lấy giá trị trung bình). Điển hình là thỏa thuận cấp độ dịch vụ (SLA) chỉ định giới hạn độ lệch có thể chấp nhận được cho các báo cáo, tức là báo cáo của nút có thể đi được bao xa đi chệch khỏi báo cáo tổng hợp và mức độ tổng hợp được phép lệch khỏi giá trị thực thì được coi là đúng. Trong hệ thống staking của chúng tôi, đối với một vòng báo cáo nhất định, mỗi nút oracle có thể hoạt động như cơ quan giám sát đưa ra cảnh báo nếu họ tin rằng báo cáo tổng hợp là không chính xác. Trong mỗi vòng báo cáo, mỗi nút oracle được chỉ định một mức độ ưu tiên công khai xác định thứ tự cảnh báo của nó (nếu có) sẽ được xử lý. Cơ chế của chúng tôi nhằm mục đích khen thưởng tập trung, có nghĩa là cơ quan giám sát có mức độ ưu tiên cao nhất đưa ra cảnh báo sẽ nhận được toàn bộ phần thưởng thu được bằng cách tịch thu tiền gửi của các nút bị lỗi. Thiết kế hệ thống staking của chúng tôi bao gồm hai cấp: cấp đầu tiên, mặc định và cấp thứ hai, tầng cản trở. Tầng đầu tiên chính là mạng oracle, một tập hợp n nút. (Để đơn giản, chúng tôi giả sử n là số lẻ.) Nếu phần lớn các nút báo cáo giá trị không chính xác, cơ quan giám sát trong cấp đầu tiên được khuyến khích mạnh mẽ để đưa ra cảnh báo. Nếu cảnh báo được đưa ra, báo cáo quyết định của mạng sau đó được chuyển lên cấp thứ hai—một hệ thống có chi phí cao, độ tin cậy tối đa có thể được người dùng chỉ định trong thỏa thuận cấp độ dịch vụ mạng. Ví dụ, đây có thể là một hệ thống chỉ bao gồm các nút có điểm số về độ tin cậy lịch sử hoặc điểm có độ lớn hơn oracles so với bậc đầu tiên. Ngoài ra, như đã thảo luận trong Phần 9.4.3, DECO hoặc Town Crier có thể phục vụ là những công cụ mạnh mẽ giúp đảm bảo việc xét xử hiệu quả và có tính kết luận ở cấp độ thứ hai. Để đơn giản, chúng tôi giả định rằng hệ thống cấp hai này đưa ra một báo cáo chính xác giá trị. Mặc dù việc dựa vào cấp thứ hai để tạo tất cả các báo cáo có vẻ hấp dẫn, Lợi ích của thiết kế của chúng tôi là nó luôn đạt được các đặc tính bảo mật củahệ thống cấp hai trong khi chỉ phải trả chi phí vận hành, trong trường hợp điển hình, của hệ thống cấp một. Mức độ ưu tiên của cơ quan giám sát dẫn đến tác động staking siêu tuyến tính theo cách sau: nếu mạng oracle cấp một đưa ra kết quả không chính xác và một số nút cơ quan giám sát cảnh báo, cơ chế khuyến khích staking thưởng cho cơ quan giám sát có mức độ ưu tiên cao nhất hơn $dn/2 được rút từ tiền gửi của (phần lớn) các nút hoạt động sai. các do đó, tổng phần thưởng tập trung vào tay cơ quan giám sát duy nhất này, do đó xác định mức tối thiểu mà đối thủ phải hứa với một cơ quan giám sát tiềm năng để khuyến khích nó không cảnh báo. Vì cơ chế của chúng tôi đảm bảo rằng mọi oracle đều nhận được cơ hội đóng vai trò là cơ quan giám sát nếu các cơ quan giám sát có mức độ ưu tiên cao hơn đã nhận hối lộ của họ (và được chọn không cảnh báo), do đó đối thủ phải đưa hối lộ nhiều hơn $dn/2 tới mọi nút để ngăn chặn bất kỳ cảnh báo nào được đưa ra. Vì có n nút nên Ngân sách cần thiết của đối phương để hối lộ thành công lên tới hơn $dn2/2, tức là là bậc hai của số n nút trong mạng. 9,2 Nền Cách tiếp cận của chúng tôi đối với staking dựa trên nghiên cứu trong lĩnh vực lý thuyết và cơ chế trò chơi thiết kế (MD) (để tham khảo sách giáo khoa, xem [177]). Lý thuyết trò chơi là lý thuyết toán học nghiên cứu chính thức về tương tác chiến lược. Trong bối cảnh này, trò chơi là một mô hình của một sự tương tác, điển hình là trong thế giới thực, mã hóa các tập hợp hành động có sẵn để người tham gia trò chơi, được gọi là người chơi. Trò chơi cũng chỉ định số tiền nhận được bởi từng người chơi—phần thưởng phụ thuộc vào hành động được lựa chọn của người chơi và hành động của những người chơi khác. Có lẽ ví dụ nổi tiếng nhất về trò chơi được nghiên cứu trong trò chơi lý thuyết là Thế tiến thoái lưỡng nan của tù nhân [178]. Các nhà lý thuyết trò chơi thường hướng tới việc hiểu trạng thái cân bằng hoặc cân bằng (nếu có) thể hiện trong một trò chơi nhất định. Một trạng thái cân bằng là một tập hợp các chiến lược (mỗi người chơi một chiến lược) sao cho không người chơi nào có thể đạt được điểm cao hơn thanh toán bằng cách đơn phương đi chệch khỏi chiến lược của mình. Trong khi đó, thiết kế cơ chế là khoa học thiết kế các biện pháp khuyến khích sao cho trạng thái cân bằng của một tương tác (và trò chơi liên quan của nó) có một số đặc tính mong muốn. MD có thể được coi là nghịch đảo của lý thuyết trò chơi: Câu hỏi kinh điển trong trò chơi lý thuyết là “với các động cơ và mô hình được đưa ra, trạng thái cân bằng sẽ như thế nào?” Ở MD, Thay vào đó, câu hỏi là “những khuyến khích nào sẽ mang lại một trò chơi có trạng thái cân bằng mong muốn?” Mục tiêu điển hình của người thiết kế cơ chế là tạo ra một cơ chế 'tương thích khuyến khích', nghĩa là những người tham gia cơ chế (ví dụ: đấu giá hoặc thông tin khác) hệ thống gợi ý [228]) được khuyến khích báo cáo sự thật về một số vấn đề (ví dụ: làm thế nào họ đánh giá cao một mặt hàng cụ thể). Cuộc đấu giá Vickrey (giá thứ hai) có lẽ là cơ chế khuyến khích tương thích được biết đến nhiều nhất, trong đó người tham gia nộp hồ sơ dự thầu kín cho một món hàng và người trả giá cao nhất sẽ thắng món hàng đó nhưng phải trả mức giá cao thứ hai [214]. Kinh tế học mật mã là một dạng MD dành riêng cho từng miền, tận dụng kỹ thuật mã hóa kỹ thuật để tạo ra sự cân bằng mong muốn trong các hệ thống phi tập trung. Hối lộ và thông đồng tạo ra những thách thức đáng kể trong lĩnh vực MD. Hầu như tất cả các cơ chế đều bị phá vỡ khi có sự thông đồng, được định nghĩa là các hợp đồng phụgiữa các bên tham gia cơ chế [125, 130]. Hối lộ, trong đó một bên bên ngoài đưa các khuyến khích mới vào trò chơi, gây ra một vấn đề thậm chí còn khó khăn hơn hơn là thông đồng; thông đồng có thể được coi là một trường hợp đặc biệt của hối lộ trong trò chơi người tham gia. Các hệ thống chuỗi khối thường có thể được khái niệm hóa như một trò chơi với các khoản thanh toán bằng tiền (dựa trên tiền điện tử). Một ví dụ đơn giản là khai thác Bằng chứng công việc: thợ mỏ có không gian hành động trong đó họ có thể chọn tỷ lệ hash để khai thác khối. Lợi ích của việc khai thác là phần thưởng âm được đảm bảo (chi phí điện và thiết bị) cộng với chi phí ngẫu nhiên phần thưởng tích cực (trợ cấp khai thác) phụ thuộc vào số lượng người khai thác đang hoạt động khác [106, 172] và phí giao dịch. oracle được cộng đồng đóng góp như SchellingCoin [68] là một ví dụ khác: không gian hành động là tập hợp các báo cáo có thể có mà oracle có thể gửi, trong khi khoản thanh toán là phần thưởng được chỉ định bởi cơ chế oracle, ví dụ: khoản thanh toán có thể phụ thuộc vào về mức độ gần gũi giữa báo cáo của oracle với giá trị trung bình của các báo cáo khác [26, 68, 119, 185]. Trò chơi chuỗi khối mang lại cơ hội chín muồi cho các cuộc tấn công thông đồng và hối lộ; thực sự, smart contracts thậm chí có thể tạo điều kiện thuận lợi cho các cuộc tấn công như vậy [96, 165]. Có lẽ được biết đến nhiều nhất cuộc tấn công hối lộ vào oracle được cộng đồng sử dụng là cuộc tấn công p-plus-epsilon [67]. Cuộc tấn công này phát sinh trong bối cảnh cơ chế giống như SchellingCoin trong đó người chơi gửi báo cáo có giá trị boolean (nghĩa là sai hoặc đúng) và được thưởng p nếu họ đồng ý với sự đệ trình của đa số. Trong cuộc tấn công p-plus-epsilon, kẻ tấn công hứa hẹn một cách đáng tin cậy: ví dụ: trả tiền cho người dùng $p + ϵ để bỏ phiếu sai khi và chỉ khi ý kiến đa số là đúng. Kết quả là một trạng thái cân bằng, trong đó tất cả người chơi được khuyến khích báo cáo sai bất kể người chơi khác làm gì; do đó, kẻ hối lộ có thể xúi giục các nút thông qua việc hối lộ đã hứa để báo cáo sai sự thật mà không thực sự trả tiền hối lộ (!). Tuy nhiên, việc khám phá các chiến lược hối lộ khác trong bối cảnh oracle—và đặc biệt là oracle không sử dụng nguồn lực từ cộng đồng—đã bị giới hạn ở đối thủ khá yếu các mô hình. Ví dụ, trong bối cảnh PoW, các nhà nghiên cứu đã nghiên cứu các yếu tố phụ thuộc vào kết quả hối lộ, tức là hối lộ chỉ được trả nếu thông điệp mục tiêu được kiểm duyệt thành công và không xuất hiện trong một khối, bất kể hành động của từng người khai thác [96, 165]. Trong trường hợp Tuy nhiên, trong số oracle, ngoài cuộc tấn công p-plus-epsilon, chúng tôi chỉ biết về công việc trong một mô hình hối lộ có giới hạn nghiêm ngặt, trong đó người đưa hối lộ gửi hối lộ với điều kiện hành động của từng người chơi chứ không phải kết quả đạt được. Ở đây chúng tôi phác thảo các thiết kế của cơ chế khơi gợi thông tin vẫn mang tính khuyến khích tương thích ngay cả trong một mô hình đối nghịch mạnh, như được mô tả trong tiểu mục tiếp theo. 9,3 Giả định mô hình hóa Trong tiểu mục này, chúng tôi giải thích cách chúng tôi mô hình hóa hành vi và khả năng của người chơi trong hệ thống của chúng tôi, cụ thể là các nút oracle cấp một, các nút ở cấp hai (xác định) lớp và đối thủ.9.3.1 Mô hình khuyến khích cấp một: Tác nhân hợp lý Nhiều hệ thống blockchain dựa vào tính bảo mật dựa trên giả định về một số thông tin trung thực các nút tham gia. Các nút được xác định là trung thực nếu chúng tuân theo giao thức ngay cả khi khi việc làm đó không mang lại lợi ích tài chính cho họ. Hệ thống Bằng chứng công việc thường yêu cầu phần lớn quyền lực hash phải trung thực, hệ thống Bằng chứng cổ phần thường yêu cầu 2/3 tổng số cổ phần tham gia phải trung thực và thậm chí cả các hệ thống lớp 2 như Trọng tài [141] yêu cầu ít nhất một người tham gia trung thực. Khi lập mô hình cho cơ chế staking, chúng tôi đưa ra giả định yếu hơn nhiều. (Trở thành các giả định rõ ràng, yếu hơn có nghĩa là các thuộc tính bảo mật mạnh hơn và do đó được ưu tiên hơn.) Chúng tôi cho rằng đối thủ đã làm hỏng, tức là các quyền kiểm soát, một số (thiểu số) một phần của nút oracle cấp một. Chúng tôi lập mô hình các nút còn lại không phải là tác nhân trung thực, mà là tối đa hóa tiện ích kỳ vọng hợp lý. Các nút này hoạt động hoàn toàn theo các khuyến khích tài chính mang tính tư lợi, lựa chọn các hành động mang lại hiệu quả tài chính dự kiến. đạt được. Ví dụ: nếu một nút được đưa hối lộ lớn hơn phần thưởng thu được từ hành vi trung thực thì sẽ nhận hối lộ. Lưu ý về các nút đối nghịch: Theo mô hình tin cậy phổ biến cho hệ thống phi tập trung, chúng tôi giả định rằng tất cả các nút đều hợp lý, tức là tìm cách tối đa hóa doanh thu ròng, thay vì bị kiểm soát bởi một đối thủ độc hại. Tuy nhiên, những tuyên bố của chúng tôi— tác động đặc biệt là siêu tuyến tính hoặc bậc hai staking—giữ được cung cấp tiệm cận rằng tập hợp các nút bị kiểm soát đối nghịch tối đa là (1/2 −c)n, đối với một số giá trị dương hằng số c. 9.3.2 Mô hình xét xử cấp hai: Tính đúng đắn dựa trên giả định Hãy nhớ rằng một tính năng quan trọng của cơ chế staking của chúng tôi giúp đạt được bảo mật chống lại các nút hợp lý là hệ thống cấp hai của nó. Trong cơ chế staking được đề xuất của chúng tôi, bất kỳ oracle nào cũng có thể đưa ra cảnh báo cho biết rằng nó tin rằng đầu ra của cơ chế này là không chính xác. Một cảnh báo mang lại độ tin cậy cao hệ thống cấp hai kích hoạt và báo cáo kết quả chính xác. Vì vậy, một mô hình chính yêu cầu đối với cách tiếp cận của chúng tôi là sự đánh giá chính xác, tức là báo cáo chính xác của hệ thống bậc hai. Mô hình staking của chúng tôi giả định hệ thống cấp hai hoạt động như một nguồn sự thật không thể bị hỏng, có độ tin cậy tối đa. Một hệ thống như vậy có thể sẽ tốn kém và chậm, và do đó không phù hợp để sử dụng cho trường hợp điển hình. Tuy nhiên, trong trường hợp cân bằng, tức là khi hệ thống cấp một hoạt động chính xác thì hệ thống cấp hai sẽ không được gọi. Thay vào đó, sự tồn tại của nó giúp tăng cường tính bảo mật của toàn bộ hệ thống oracle bằng cách cung cấp một backstop có độ đảm bảo cao. Việc sử dụng lớp xét xử có độ tin cậy cao, chi phí cao tương tự như quy trình kháng cáo trung tâm của hầu hết các hệ thống tư pháp. Nó cũng đã phổ biến trong thiết kế của oracle hệ thống, ví dụ: [119, 185]. Chúng tôi thảo luận ngắn gọn các cách tiếp cận để hiện thực hóa cấp độ thứ hai trong cơ chế của chúng tôi ở Mục 9.4.3.Giao thức staking của chúng tôi sử dụng phán đoán chính xác giả định của hệ thống cấp hai như một mối đe dọa đáng tin cậy để buộc các nút oracle báo cáo chính xác. giao thức tịch thu một phần hoặc toàn bộ cổ phần của các nút oracle tạo báo cáo được xác định bởi hệ thống cấp hai là không chính xác. Do đó, các nút của Oracle bị ngăn chặn hoạt động sai bởi hình phạt tài chính phát sinh. Cách tiếp cận này có tính chất tương tự như cách được sử dụng trong lạc quan rollups, ví dụ: [141, 10]. 9.3.3 Mô hình đối nghịch Cơ chế staking của chúng tôi được thiết kế để thu thập thông tin trung thực đồng thời đạt được sự bảo mật trước một nhóm đối thủ được xác định rõ ràng và rộng rãi. Nó cải thiện các tác phẩm trước đó, hoặc bỏ qua mô hình đối thủ rõ ràng hoặc tập trung vào các phân nhóm đối thủ hẹp, ví dụ: đối thủ p-plus-epsilon đã thảo luận ở trên. Mục tiêu của chúng tôi là thiết kế staking cơ chế bảo mật đã được chứng minh chính thức chống lại đầy đủ các đối thủ có khả năng phải gặp trong thực tế. Chúng ta mô hình đối thủ của mình là có ngân sách cố định (có thể tham số hóa), ký hiệu là $B. Kẻ thù có thể liên lạc riêng lẻ và bí mật với mỗi oracle trong mạng và có thể bí mật đưa ra bất kỳ cá nhân nào oracle khoản hối lộ được đảm bảo phụ thuộc vào các kết quả có thể quan sát được một cách công khai của cơ chế. Kết quả xác định hối lộ có thể bao gồm, ví dụ: giá trị được báo cáo bởi oracle, bất kỳ tin nhắn công khai nào được gửi bởi bất kỳ oracle nào tới cơ chế (ví dụ: cảnh báo), các giá trị được báo cáo bởi người khác oracles và giá trị đầu ra theo cơ chế. Không có cơ chế nào có thể bảo mật trước kẻ tấn công với khả năng không giới hạn. Do đó, chúng tôi coi một số hành vi là không thực tế hoặc nằm ngoài phạm vi. Chúng tôi cho rằng kẻ tấn công của chúng tôi không thể phá vỡ các nguyên tắc mã hóa tiêu chuẩn và, như đã lưu ý ở trên, có một điểm cố định (nếu có khả năng lớn) ngân sách $B. Chúng tôi còn giả định thêm rằng đối thủ không kiểm soát liên lạc trong mạng oracle, cụ thể là nó không thể trì hoãn đáng kể lưu lượng giữa các nút cấp một và/hoặc cấp hai. (Việc đối phương có thể quan sát được hoạt động giao tiếp như vậy hay không còn tùy thuộc vào cơ chế cụ thể, như chúng tôi giải thích bên dưới.) Tuy nhiên, một cách không chính thức, như đã lưu ý ở trên, chúng tôi cho rằng đối thủ có thể: (1) Tham nhũng một phần của oracle nút ((1/2 −c)-phân số cho một số hằng số c), tức là kiểm soát hoàn toàn họ, và (2) Đưa hối lộ cho bất kỳ nút nào mong muốn, với khoản thanh toán được đảm bảo về các kết quả do đối thủ quy định, như được mô tả ở trên. Mặc dù chúng tôi không cung cấp một mô hình chính thức hoặc phân loại đầy đủ về đối thủ nhiều khả năng hối lộ trong báo cáo nghiên cứu chuyên sâu này, sau đây là ví dụ về các loại những kẻ hối lộ nằm trong mô hình của chúng tôi. Để đơn giản, chúng tôi giả sử rằng oracle phát ra Boolean báo cáo có giá trị đúng (w.l.o.g.) là đúng và kết quả cuối cùng được tính là tổng hợp các báo cáo này sẽ được sử dụng bởi smart contract. Của kẻ hối lộ mục đích là làm cho kết quả cuối cùng không chính xác, tức là sai. • Kẻ hối lộ vô điều kiện: Kẻ hối lộ đưa hối lộ $b cho bất kỳ oracle nào báo cáo sai. • Kẻ hối lộ xác suất: Kẻ hối lộ đưa hối lộ $b với xác suất q nào đó cho bất kỳ oracle nào báo cáo đó là sai.• Kẻ hối lộ có điều kiện đưa ra kết quả sai: Kẻ hối lộ đưa hối lộ $b cho bất kỳ oracle nào báo cáo sai với điều kiện là kết quả cuối cùng là sai. • Kẻ hối lộ không có cảnh báo: Kẻ hối lộ đưa hối lộ $b cho bất kỳ oracle nào báo cáo sai miễn là không có cảnh báo nào được đưa ra. • p-plus-epsilon Kẻ hối lộ: Kẻ hối lộ đề nghị hối lộ $b cho bất kỳ oracle nào báo cáo sai là miễn là phần lớn oracle không báo cáo sai. • Người hối lộ tiềm năng: Kẻ hối lộ đưa hối lộ trước $b cho bất kỳ oracle nào được chọn cho một vai trò ngẫu nhiên và báo cáo sai. Trong giao thức staking được đề xuất của chúng tôi, tất cả các nút hoạt động như cơ quan giám sát tiềm năng và chúng tôi có thể chỉ ra rằng sự ngẫu nhiên trong số các ưu tiên của cơ quan giám sát không có khả năng dẫn đến hối lộ. Nhiều bằng chứng công việc, proof-of-stake và các hệ thống được cấp phép dễ bị tấn công tuy nhiên, hối lộ cho thấy tầm quan trọng của việc xem xét vấn đề này trong bối cảnh đối thủ của chúng ta mô hình và đảm bảo rằng các giao thức staking của chúng tôi có khả năng phục hồi theo mô hình đó. Xem Phụ lục E để biết thêm chi tiết. 9.3.4 Bao nhiêu bảo mật kinh tế tiền điện tử là đủ? Một đối thủ hợp lý sẽ chỉ chi tiền để tấn công một hệ thống nếu nó có thể thu được lợi nhuận lớn hơn chi phí của nó. Do đó, đối với mô hình đối nghịch của chúng tôi và đề xuất staking cơ chế, $B có thể được xem như thước đo lợi nhuận tiềm năng mà đối thủ có thể có được để trích xuất từ việc dựa vào smart contract bằng cách làm hỏng mạng oracle và khiến nó để tạo ra một báo cáo hoặc tập hợp các báo cáo không chính xác. Khi quyết định xem mạng oracle cung cấp mức độ bảo mật kinh tế tiền điện tử phù hợp cho mục đích của mình, người dùng nên đánh giá mạng từ quan điểm này. Đối với những đối thủ đáng tin cậy trong bối cảnh thực tế, chúng tôi kỳ vọng rằng $B nhìn chung sẽ nhỏ hơn đáng kể so với tổng tài sản tính theo smart contracts. Trong hầu hết các trường hợp, nó Đối phương không thể chiếm được toàn bộ tài sản này. 9,4 Cơ chế đặt cược: Phác thảo Ở đây chúng tôi trình bày các ý chính và cấu trúc chung của cơ chế staking mà chúng tôi hiện đang xem xét. Để dễ trình bày, chúng tôi mô tả một cách đơn giản nhưng chậm (nhiều vòng) trong tiểu mục này. Tuy nhiên, chúng tôi lưu ý rằng kế hoạch này khá thiết thực. Với những đảm bảo kinh tế được cung cấp bởi cơ chế, tức là việc trừng phạt và khuyến khích các nút bị lỗi, nhiều người dùng có thể sẵn sàng chấp nhận báo cáo một cách lạc quan. Nói cách khác, những người dùng như vậy có thể chấp nhận báo cáo trước khi sự xét xử tiềm năng của cấp thứ hai. Người dùng không muốn chấp nhận báo cáo một cách lạc quan có thể chọn đợi cho đến khi giao thức việc thực thi chấm dứt, tức là cho đến khi xảy ra bất kỳ sự leo thang tiềm năng nào lên tầng thứ hai. Cái này, tuy nhiên, có thể làm chậm đáng kể thời gian xác nhận báo cáo. Do đó chúng tôi tóm tắtHình 15: Sơ đồ lược đồ staking có cảnh báo. Trong ví dụ này, 1⃝a đa số của các nút bị hỏng/bị mua chuộc và phát ra giá trị ˜r không chính xác, thay vì giá trị chính xác giá trị báo cáo r. Nút cơ quan giám sát 2⃝ gửi cảnh báo đến ủy ban cấp hai, 3⃝xác định và đưa ra giá trị báo cáo chính xác r, dẫn đến các nút bị hỏng mất tiền gửi của họ—mỗi $d vào nút cơ quan giám sát 4⃝. phác thảo một số tối ưu hóa mang lại kết quả nhanh hơn (một vòng) nếu nhiều hơn một chút thiết kế phức tạp trong Phần 9.5. Hãy nhớ lại rằng tầng đầu tiên trong cơ chế staking của chúng tôi bao gồm oracle cơ bản bản thân mạng. Cấu trúc chính của cơ chế của chúng tôi, như được mô tả ở trên, là trong mỗi vòng, mỗi nút có thể hoạt động như một “cơ quan giám sát” với mức độ ưu tiên nhất định và do đó nó có khả năng đưa ra cảnh báo nếu cơ chế đạt được đầu ra không chính xác ˜r, thay vì đầu ra đúng một r. Cảnh báo này gây ra độ phân giải cấp hai mà chúng tôi cho rằng đạt đến độ phân giải chính xác báo cáo. Các nút có báo cáo không chính xác sẽ bị trừng phạt, theo nghĩa là cổ phần của họ bị chém và trao cho cơ quan giám sát. Cấu trúc cơ bản này phổ biến trong các hệ thống oracle, như trong, ví dụ: [119, 185]. Sự đổi mới quan trọng trong thiết kế của chúng tôi, được đề cập ngắn gọn ở trên, là mọi nút đều được giao một mức độ ưu tiên riêng biệt trong việc sắp xếp các cơ quan giám sát tiềm năng. Tức là cơ quan giám sát được tạo cơ hội để cảnh báo theo thứ tự ưu tiên. Hãy nhớ lại rằng nếu một nút có ưu tiên cao nhất để đưa ra cảnh báo, nó sẽ nhận được khoản tiền gửi bị cắt giảm $d cho mỗi hành vi sai trái nút, với tổng số lớn hơn \(dn/2 = \)d × n/2, vì một báo cáo không chính xác ngụ ý một phần lớn các nút xấu. Do đó, đối thủ ít nhất phải trả phần thưởng này cho hối lộ một nút tùy ý. Do đó, để hối lộ phần lớn các nút, đối thủ phải trả một khoản tiền hối lộ lớn cho phần lớn các nút, cụ thể là hơn $dn2/2. Chúng tôi trình bày dưới dạng sơ đồ cách thức hoạt động của cảnh báo và cơ quan giám sát trong Hình 15.9.4.1 Chi tiết cơ chế khác Hệ thống chống hối lộ mà chúng tôi mô tả chi tiết hơn bây giờ là một bản phác thảo đơn giản về công trình hai tầng mà chúng tôi dự định xây dựng. Hầu hết trọng tâm của chúng tôi sẽ là mô tả mạng cấp một (từ đây gọi đơn giản là “mạng” nếu không phù hợp với ngữ cảnh) cùng với cơ chế khuyến khích và thủ tục chuyển lên cấp thứ hai. Hãy xem xét một mạng Chainlink bao gồm n nút oracle chịu trách nhiệm thường xuyên (ví dụ: mỗi phút một lần) báo cáo giá trị boolean (ví dụ: liệu thị trường có vốn hóa của BTC vượt quá ETH). Là một phần của cơ chế staking, các nút phải cung cấp hai khoản đặt cọc: một khoản đặt cọc $d có thể bị cắt giảm trong trường hợp không đồng ý với phần lớn và khoản đặt cọc của cơ quan giám sát $dw có thể bị cắt giảm trong trường hợp có lỗi leo thang. Chúng tôi giả định rằng các nút không thể sao chép nội dung gửi của các nút khác, ví dụ: thông qua sơ đồ tiết lộ cam kết như được thảo luận trong Phần 5.3. Trong mỗi vòng, các nút đầu tiên cam kết với báo cáo của họ và khi tất cả các nút đã cam kết (hoặc hết thời gian chờ), các nút tiết lộ báo cáo của họ. Đối với mỗi báo cáo được tạo, mọi nút cũng được cấp mức độ ưu tiên theo dõi từ 1 đến n được chọn ngẫu nhiên, trong đó 1 là mức độ ưu tiên hàng đầu. Ưu tiên này cho phép tập trung phần thưởng vào tay một cơ quan giám sát. Sau khi tất cả các báo cáo được công khai, một giai đoạn cảnh báo xảy ra sau đó. Qua một chuỗi n vòng (đồng bộ), nút có ưu tiên tôi có cơ hội cảnh báo ở vòng i. Chúng ta hãy xem xét các kết quả có thể xảy ra đối với cơ chế sau khi các nút được tiết lộ báo cáo của họ. Một lần nữa giả sử một báo cáo nhị phân, giả sử giá trị đúng là đúng và cái sai là sai. Cũng giả sử rằng cơ chế bậc một tạo ra đầu ra giá trị đa số theo các nút làm báo cáo cuối cùng r. Có ba kết quả có thể xảy ra trong cơ chế này: • Thỏa thuận hoàn chỉnh: Trong trường hợp tốt nhất, các nút đều hoàn toàn đồng ý: tất cả các nút có sẵn và đã cung cấp báo cáo kịp thời có cùng giá trị r (hoặc đúng hoặc sai). Trong trường hợp này, mạng chỉ cần chuyển tiếp r tới các hợp đồng dựa trên và thưởng cho mỗi nút một khoản thanh toán cố định cho mỗi vòng $p, số tiền này nhỏ hơn nhiều hơn $d. • Thỏa thuận một phần: Có thể một số nút đang ngoại tuyến hoặc có sự bất đồng về giá trị nào là đúng, nhưng hầu hết các nút đều báo cáo là đúng và chỉ có một báo cáo thiểu số sai. Trường hợp này cũng đơn giản thôi. Giá trị đa số (đúng) được tính toán, dẫn đến báo cáo đúng r. Tất cả các nút báo cáo r đều được thưởng $p trong khi oracle được báo cáo không chính xác có tiền gửi của họ giảm một cách khiêm tốn, ví dụ: 10 xu. • Cảnh báo: Trong trường hợp cơ quan giám sát tin rằng đầu ra của mạng không chính xác, nó công khai kích hoạt cảnh báo, chuyển cơ chế này sang mạng cấp hai. Khi đó có hai kết quả có thể xảy ra: – Cảnh báo đúng: Nếu mạng cấp hai xác nhận rằng đầu ra củaHình 16: Tăng chi phí của kẻ hối lộ thông qua các phần thưởng cảnh báo tập trung. Một sự hối lộ đối thủ phải hối lộ mỗi nút nhiều hơn phần thưởng mà nó có thể nhận được bằng cách cảnh báo (hiển thị dưới dạng thanh màu đỏ). Nếu phần thưởng cảnh báo được chia sẻ thì phần thưởng này có thể tương đối nhỏ. Phần thưởng cảnh báo tập trung làm tăng phần thưởng mà bất kỳ nút đơn lẻ nào cũng có thể có được (thanh cao màu đỏ). Do đó, tổng số tiền mà đối phương phải trả cho một khoản hối lộ khả thi (vùng màu xám) lớn hơn nhiều với phần thưởng cảnh báo tập trung hơn so với phần thưởng cảnh báo được chia sẻ. mạng cấp một không chính xác, nút cơ quan giám sát cảnh báo sẽ nhận được phần thưởng bao gồm tất cả các khoản tiền gửi bị cắt giảm, và do đó nhiều hơn $dn/2. – Cảnh báo lỗi: Nếu oracle cấp hai và cấp một đồng ý, thì mức tăng sẽ là được coi là bị lỗi và nút cảnh báo sẽ mất khoản tiền gửi $dw. Trong trường hợp chấp nhận báo cáo một cách lạc quan, cảnh báo của cơ quan giám sát không gây ra bất kỳ sự thay đổi nào trong việc thực hiện các hợp đồng căn cứ. Đối với các hợp đồng được thiết kế để chờ đợi khả năng được phân xử bởi ủy ban cấp hai, cơ quan giám sát sẽ trì hoãn cảnh báo nhưng không đình chỉ việc thực hiện hợp đồng. Hợp đồng cũng có thể chỉ định một chuyển đổi dự phòng DON trong thời gian xem xét. 9.4.2 Tác động đặt cược bậc hai Khả năng cho mọi nút hoạt động như một cơ quan giám sát, kết hợp với mức độ ưu tiên nghiêm ngặt của nút đảm bảo phần thưởng tập trung, cho phép cơ chế đạt được bậc hai staking tác động đối với từng loại kẻ tấn công hối lộ được mô tả trong Phần 9.3.3. Hãy nhớ lại rằng điều này có nghĩa cụ thể trong cài đặt của chúng tôi là, đối với một mạng có n nút, mỗi nút có tiền gửi $d, kẻ hối lộ thành công (thuộc bất kỳ loại nào ở trên) phải có ngân sách lớn hơn $dn2/2. Nói chính xác, kẻ hối lộ phải làm hỏng ít nhất (n+1)/2 nút, vì kẻ hối lộ phải làm hỏng phần lớn n nút (đối với n lẻ, theo giả định). Vì vậy, một cơ quan giám sát đứng ra kiếm được phần thưởng $d(n + 1)/2. Do đó, người hối lộ phải trả số tiền này cho mọi người.nút để đảm bảo rằng không có nút nào hoạt động như cơ quan giám sát. Chúng tôi đang làm việc để chứng tỏ một cách chính thức rằng nếu người hối lộ có ngân sách tối đa là $d(n2 + n)/2, khi đó trò chơi con sẽ có trạng thái cân bằng hoàn hảo của trò chơi giữa những kẻ hối lộ và oracle—nói cách khác, điểm cân bằng tại bất kỳ thời điểm nào trong quá trình chơi trò chơi—là người đưa hối lộ không được đưa hối lộ và mỗi oracle báo cáo giá trị thực của nó một cách trung thực. Ở trên chúng tôi đã giải thích tại sao một kẻ hối lộ thành công có thể yêu cầu một ngân sách lớn hơn đáng kể so với tổng số tiền gửi của nút. Để minh họa điều này kết quả trực quan, Hình 16 cho thấy tác động của phần thưởng cảnh báo tập trung bằng đồ họa. Như chúng ta thấy ở đó, nếu phần thưởng cho việc cảnh báo cơ quan giám sát—cụ thể là tiền gửi hối lộ các nút báo cáo sai)—được chia cho tất cả các cảnh báo tiềm năng, tổng số tiền bất kỳ nút cảnh báo riêng lẻ nào có thể mong đợi sẽ tương đối nhỏ, theo thứ tự $d. Một kẻ hối lộ biết rằng khoản tiền lớn hơn $d là không thể xảy ra nên có thể sử dụng một khoản hối lộ có điều kiện có kết quả sai để hối lộ từng nút trong số n nút nhiều hơn một chút $d + ϵ. Ngược lại, Hình 16 cho thấy rằng một hệ thống phân phối phần thưởng một cách rộng rãi giữa các nút báo hiệu cảnh báo yếu hơn nhiều so với nút tập trung phần thưởng vào bàn tay của một cơ quan giám sát duy nhất. Các tham số ví dụ: Hãy xem xét một mạng (cấp đầu tiên) có n = 100 nút, mỗi nút gửi tiền \(d = \)20K. Mạng này sẽ có tổng số tiền gửi là 2 triệu USD nhưng sẽ được bảo vệ khỏi kẻ hối lộ với ngân sách \(100M = \)dn2/2. Tăng số lượng Tất nhiên, oracles sẽ hiệu quả hơn việc tăng $d và có thể có tác động mạnh mẽ: một mạng có n = 300 nút và tiền gửi \(d = \)20K sẽ được bảo vệ chống lại một kẻ hối lộ với ngân sách lên tới 900 triệu USD. Lưu ý rằng trong nhiều trường hợp, hệ thống staking có thể bảo vệ smart contract đại diện có giá trị cao hơn mức độ bảo vệ chống hối lộ được đưa ra. Điều này là do đối thủ tấn công các hợp đồng này không thể trích xuất toàn bộ giá trị trong nhiều trường hợp. Ví dụ, một Hợp đồng do Chainlink cung cấp đảm bảo giá trị 1 tỷ USD chỉ có thể yêu cầu bảo đảm chống lại một kẻ hối lộ với nguồn lực 100 triệu đô la vì kẻ thù như vậy có thể kiếm được lợi nhuận chỉ 10% giá trị hợp đồng. Lưu ý: Ý tưởng rằng giá trị của một mạng có thể tăng theo phương pháp bậc hai được thể hiện trong Định luật Metcalfe nổi tiếng [167, 235], trong đó nêu rõ rằng giá trị của một mạng tăng bậc hai về số lượng thực thể được kết nối. Tuy nhiên, định luật Metcalfe phát sinh từ sự tăng trưởng về số lượng kết nối mạng theo cặp tiềm năng, một hiện tượng khác với tác động bậc hai cơ bản staking trong khuyến khích của chúng tôi cơ chế. 9.4.3 Hiện thực hóa tầng thứ hai Hai tính năng vận hành tạo điều kiện thuận lợi cho việc hiện thực hóa tầng thứ hai có độ tin cậy cao: (1) Việc phân xử cấp hai phải là một sự kiện hiếm gặp trong các mạng oracle và do đó có thể tốn kém hơn đáng kể so với hoạt động bình thường của cấp một và (2) Giả sửnhững báo cáo được chấp nhận một cách lạc quan—hoặc những hợp đồng mà việc thực hiện có thể chờ phân xử— tầng thứ hai không cần thực thi trong thời gian thực. Những đặc điểm này dẫn đến một loạt các các tùy chọn cấu hình cho tầng thứ hai để đáp ứng các yêu cầu của DON cụ thể. Theo cách tiếp cận ví dụ, một ủy ban cấp hai có thể bao gồm các nút được chọn bởi một DON (tức là cấp đầu tiên) từ các nút hoạt động lâu nhất và đáng tin cậy nhất trong Chainlink mạng. Ngoài kinh nghiệm hoạt động có liên quan đáng kể, các nhà khai thác trong số các nút như vậy có động cơ ngầm đáng kể trong FFO thúc đẩy mong muốn để đảm bảo rằng mạng Chainlink vẫn có độ tin cậy cao. Họ cũng đã công khai lịch sử hiệu suất có sẵn cung cấp sự minh bạch về độ tin cậy của chúng. Điều đáng chú ý là các nút cấp hai không cần phải là người tham gia vào mạng cấp một và có thể phân xử các lỗi trên nhiều mạng cấp một. Các nút trong DON nhất định có thể chỉ định trước và cam kết công khai với một tập hợp n′ như vậy các nút cấu thành ủy ban cấp hai cho DON đó. Ngoài ra, DON các nút xuất bản tham số k′ ≤n′ xác định số phiếu bầu cấp hai cần thiết để trừng phạt nút cấp một. Khi cảnh báo được tạo cho một báo cáo nhất định, các thành viên của cấp thứ hai bỏ phiếu về tính chính xác của các giá trị do mỗi người cung cấp của các nút lớp đầu tiên. Bất kỳ nút cấp 1 nào nhận được k′ phiếu bầu tiêu cực sẽ bị mất quyền tiền gửi đến nút cơ quan giám sát. Bởi vì hiếm có cơ hội xét xử và cơ hội thi hành án kéo dài đã lưu ý ở trên, trái ngược với tầng thứ nhất, các nút ở tầng thứ hai có thể: 1. Được trả thù lao cao khi tiến hành xét xử. 2. Sử dụng các nguồn dữ liệu bổ sung, thậm chí vượt ra ngoài tập hợp đa dạng được sử dụng đầu tiên. 3. Dựa vào sự kiểm tra và can thiệp thủ công và/hoặc chuyên gia, ví dụ: để xác định và điều chỉnh các lỗi trong dữ liệu nguồn và phân biệt giữa một nút chuyển tiếp trung thực dữ liệu bị lỗi và một nút hoạt động sai. Chúng tôi nhấn mạnh rằng cách tiếp cận mà chúng tôi vừa mô tả để lựa chọn các nút cấp hai và việc xét xử quản lý chính sách chỉ đại diện cho một điểm trong một phạm vi rộng lớn. không gian thiết kế của các khả năng thực hiện của tầng thứ hai. Cơ chế khuyến khích của chúng tôi cung cấp hoàn toàn linh hoạt về cách thực hiện tầng thứ hai. Do đó, DON cá nhân có thể cấu thành và đặt ra các quy tắc cho cấp thứ hai đáp ứng các yêu cầu cụ thể và kỳ vọng của các nút tham gia và người dùng. DECO và Town Crier làm công cụ xét xử: Nó rất cần thiết cho tầng thứ hai trong cơ chế của chúng tôi để có thể phân biệt giữa các nút cấp một đối thủ cố ý tạo ra các báo cáo không chính xác và các nút cấp một trung thực vô tình chuyển tiếp dữ liệu không chính xác tại nguồn. Chỉ khi đó tầng thứ hai mới có thể thực hiện chém để ngăn chặn gian lận, mục tiêu của cơ chế của chúng tôi. DECO và Town Crier là những công cụ mạnh mẽ có thể cho phép các nút cấp hai tạo ra sự khác biệt quan trọng này đáng tin cậy.Trong một số trường hợp, các nút cấp hai có thể truy vấn trực tiếp nguồn dữ liệu được sử dụng bởi nút cấp một hoặc sử dụng ADO Mục 7.1 để kiểm tra xem báo cáo không chính xác có do nguồn dữ liệu bị lỗi. Tuy nhiên, trong các trường hợp khác, các nút cấp hai có thể thiếu truy cập trực tiếp vào nguồn dữ liệu của nút cấp một. Trong những trường hợp như vậy, việc xét xử đúng sẽ dường như không khả thi hoặc đòi hỏi phải dựa vào đánh giá chủ quan. Trước oracle các hệ thống tranh chấp đã dựa vào các vòng bỏ phiếu leo thang, không hiệu quả để giải quyết các vấn đề đó những thách thức. Tuy nhiên, bằng cách sử dụng DECO hoặc Town Crier, nút cấp một có thể chứng minh hành vi đúng tới các nút lớp thứ hai. (Xem Phần 3.6.2 để biết chi tiết về hai hệ thống.) Cụ thể, nếu nút cấp thứ hai xác định nút cấp một có giá trị báo cáo bị lỗi ˜r, nút cấp một có thể sử dụng DECO hoặc Town Crier để tạo ra bằng chứng chống giả mạo cho các nút cấp hai đang chuyển tiếp chính xác từ nguồn (kích hoạt TLS) được công nhận là có thẩm quyền bởi DON. Điều quan trọng là nút cấp một có thể thực hiện việc này không có các nút cấp hai yêu cầu quyền truy cập trực tiếp vào nguồn dữ liệu.17 Do đó, việc đánh giá chính xác là khả thi ở Chainlink đối với bất kỳ nguồn dữ liệu mong muốn nào. 9.4.4 Báo cáo sai bảo hiểm Khả năng chống hối lộ mạnh mẽ mà cơ chế staking của chúng tôi đạt được về cơ bản phụ thuộc vào về số tiền bị cắt giảm được trao cho người cảnh báo. Nếu không có phần thưởng bằng tiền, người cảnh báo sẽ không có động cơ trực tiếp để từ chối hối lộ. Tuy nhiên, kết quả là số tiền bị cắt giảm không phải là có sẵn để bồi thường cho người dùng bị tổn hại do báo cáo không chính xác, ví dụ: người dùng bị mất tiền khi dữ liệu giá không chính xác được chuyển tiếp tới smart contract. Theo giả định, các báo cáo không chính xác sẽ không gây ra vấn đề gì nếu báo cáo được một cơ quan chấp nhận. chỉ ký hợp đồng sau khi có sự phân xử tiềm năng, tức là hành động của cấp thứ hai. Như đã giải thích Tuy nhiên, ở trên, để đạt được hiệu suất tốt nhất có thể, thay vào đó, hợp đồng có thể dựa vào lạc quan về cơ chế thực thi việc báo cáo đúng, nghĩa là họ chấp nhận báo cáo trước khi xét xử cấp hai tiềm năng. Quả thực, hành vi lạc quan như vậy là an toàn trong mô hình của chúng tôi giả sử các đối thủ hợp lý có ngân sách không vượt quá staking tác động của cơ chế. Người dùng lo ngại về khả năng xảy ra lỗi cơ chế do, ví dụ: đối thủ có nguồn tài chính dồi dào, có thể muốn sử dụng một lớp bảo đảm kinh tế bổ sung dưới hình thức bảo hiểm báo cáo sai. Chúng tôi biết về nhiều công ty bảo hiểm đã có ý định cung cấp các chính sách hỗ trợ hợp đồng thông minh thuộc loại này cho các giao thức được bảo mật Chainlink trong tương lai gần, bao gồm thông qua các cơ chế cải tiến như DAOs, ví dụ: [7]. Sự tồn tại của lịch sử hiệu suất cho Chainlink các nút và dữ liệu khác về các nút, chẳng hạn như số tiền đặt cọc của chúng, cung cấp cơ sở đặc biệt mạnh mẽ để đánh giá rủi ro theo mô hình thống kê, giúp cho việc định giá chính sách có thể thực hiện được. theo những cách không tốn kém cho người mua bảo hiểm nhưng vẫn bền vững cho các công ty bảo hiểm. 17Với Town Crier, các nút cấp một cũng có thể tạo chứng thực cục bộ về tính chính xác của các báo cáo mà họ xuất ra và cung cấp những chứng thực này cho các nút cấp hai trên một cơ sở theo nhu cầu.Các hình thức báo cáo sai cơ bản về bảo hiểm có thể được thực hiện một cách đáng tin cậy và cách hiệu quả bằng cách sử dụng smart contracts. Một ví dụ đơn giản, một bảo hiểm tham số SCins hợp đồng có thể tự động bồi thường cho các chủ hợp đồng nếu cơ chế khuyến khích của chúng tôi cấp thứ hai xác định lỗi trong báo cáo được tạo ở cấp đầu tiên. Người dùng U mong muốn mua hợp đồng bảo hiểm, ví dụ: người tạo mục tiêu hợp đồng SC, có thể gửi yêu cầu tới một công ty bảo hiểm phi tập trung về số tiền hợp đồng $M trên hợp đồng. Khi phê duyệt U, công ty bảo hiểm có thể đặt ra thời hạn liên tục (ví dụ: hàng tháng) phí bảo hiểm $P trong SCins. Trong khi U trả phí bảo hiểm, hợp đồng của cô ấy vẫn có hiệu lực. Nếu xảy ra lỗi báo cáo trong SC thì kết quả sẽ là phát ra một cặp (r1, r2) về các báo cáo xung đột cho SC, trong đó r1 được ký bởi cấp đầu tiên trong cơ chế của chúng tôi và r2, báo cáo đã sửa tương ứng, được cấp thứ hai ký. Nếu U cung cấp một cặp hợp lệ (r1, r2) cho SCins, hợp đồng sẽ tự động trả cho cô ấy M $, với điều kiện là các khoản thanh toán phí bảo hiểm của cô ấy được cập nhật. 9,5 Biến thể một vòng Giao thức được mô tả trong tiểu mục trước yêu cầu ủy ban cấp hai đợi n vòng để xác định xem cơ quan giám sát có đưa ra cảnh báo hay không. Cái này yêu cầu vẫn đúng ngay cả trong trường hợp lạc quan, tức là khi tầng đầu tiên hoạt động một cách chính xác. Đối với người dùng không muốn chấp nhận các báo cáo một cách lạc quan, tức là trước khi có khả năng xảy ra xét xử, sự chậm trễ liên quan đến cách tiếp cận đó sẽ không thể thực hiện được. Vì lý do này, chúng tôi cũng đang khám phá các giao thức thay thế chỉ yêu cầu một tròn. Theo cách tiếp cận này, tất cả các nút oracle gửi các bit bí mật cho biết có hay không họ muốn đưa ra một cảnh báo. Ủy ban cấp hai sau đó sẽ kiểm tra các giá trị này trong thứ tự ưu tiên. Để cung cấp một bản phác thảo thô, sơ đồ như vậy có thể bao gồm những điều sau đây: các bước: 1. Gửi bit cơ quan giám sát: Mỗi nút Oi chia sẻ bí mật một giá trị cơ quan giám sát một bit wi ∈{không có cảnh báo, cảnh báo} giữa các nút ở cấp thứ hai cho mỗi báo cáo mà nó tạo ra. 2. Mẹo ẩn danh: Bất kỳ nút oracle nào cũng có thể gửi mẹo ẩn danh α tới ủy ban cấp hai trong cùng vòng mà các bit cơ quan giám sát được gửi. Mẹo này à là thông báo cho biết cảnh báo đã được đưa ra cho báo cáo hiện tại. 3. Kiểm tra bit cơ quan giám sát: Ủy ban cấp hai tiết lộ cơ quan giám sát của nút oracle các bit theo thứ tự ưu tiên. Lưu ý rằng các nút không được gửi các bit cơ quan giám sát cảnh báo khi chúng không cảnh báo: nếu không, phân tích lưu lượng sẽ tiết lộ tất cả các bit của nút. Giao thức không tiết lộ cảnh báo không các bit cơ quan giám sát của các nút có mức độ ưu tiên cao hơn cơ quan giám sát cảnh báo có mức ưu tiên cao nhất. Quan sát rằng những gì được tiết lộ giống hệt với giao thức vòng n của chúng tôi. Phần thưởng cũng được phân phối giống hệt với chương trình đó, tức là cơ quan giám sát được xác định đầu tiên nhận được khoản tiền gửi bị cắt giảm của các nút đã gửi báo cáo không chính xác.Việc sử dụng các mẹo ẩn danh cho phép ủy ban cấp hai duy trì trạng thái không tương tác trong trường hợp không có cảnh báo nào được đưa ra, giảm độ phức tạp trong giao tiếp trong trường hợp thông thường. Lưu ý rằng bất kỳ cơ quan giám sát nào đưa ra cảnh báo đều có động cơ kinh tế để gửi mẹo ẩn danh: Nếu không gửi mẹo nào, sẽ không có phần thưởng nào được trả cho bất kỳ ai. nút. Để đảm bảo rằng người gửi Oi của một mẹo ẩn danh α không thể được xác định bởi đối thủ dựa trên dữ liệu mạng, mẹo ẩn danh có thể được gửi qua địa chỉ ẩn danh kênh, ví dụ: thông qua Tor hoặc thực tế hơn là được ủy quyền thông qua nhà cung cấp dịch vụ đám mây. Đến xác thực mẹo có nguồn gốc từ O, Oi có thể ký α bằng chữ ký vòng [39, 192]. Ngoài ra, để ngăn chặn các cuộc tấn công từ chối dịch vụ không thể phân bổ nhằm vào ủy ban cấp hai bằng nút oracle độc hại, α có thể là thông tin xác thực ẩn danh với ẩn danh có thể hủy bỏ [73]. Giao thức này, mặc dù có thể đạt được trên thực tế, nhưng có kỹ thuật hơi nặng nề yêu cầu (mà chúng tôi đang tìm cách giảm bớt). Ví dụ, các nút cấp một, phải giao tiếp trực tiếp với các nút cấp hai, yêu cầu duy trì một thư mục. Nhu cầu về các kênh ẩn danh và chữ ký vòng làm tăng thêm kỹ thuật sự phức tạp của sơ đồ. Cuối cùng, có một yêu cầu tin cậy đặc biệt được thảo luận ngắn gọn trong ghi chú dưới đây. Do đó, chúng tôi cũng đang khám phá các kế hoạch đơn giản hơn mà vẫn đạt được tác động siêu tuyến tính staking, nhưng có lẽ ít hơn bậc hai, chẳng hạn, trong đó kẻ hối lộ tiệm cận cần tài nguyên ít nhất $n log n. Một số phương án theo việc xem xét liên quan đến việc lựa chọn ngẫu nhiên một tập hợp con nghiêm ngặt các nút để hoạt động như cơ quan giám sát, trong trường hợp đó việc hối lộ tiềm năng sẽ trở thành một cuộc tấn công đặc biệt mạnh mẽ. Nhận xét: Tính bảo mật của cơ chế staking một vòng này yêu cầu không thể truy cập được các kênh giữa oracle và các nút cấp hai—một yêu cầu tiêu chuẩn trong các hệ thống chống cưỡng chế, ví dụ: biểu quyết [82, 138] và một yêu cầu hợp lý trong thực tế. Tuy nhiên, ngoài ra, nút Oi tìm cách hợp tác với kẻ hối lộ có thể xây dựng các chia sẻ bí mật của nó theo cách để cho kẻ hối lộ thấy rằng nó đã mã hóa một thông tin cụ thể giá trị. Ví dụ: nếu Oi không biết kẻ hối lộ kiểm soát nút nào thì Oi có thể gửi cổ phiếu có giá trị 0 cho tất cả các thành viên ủy ban. Sau đó, kẻ hối lộ có thể xác minh Oi tuân thủ theo xác suất. Để tránh vấn đề này trong bất kỳ giao thức một vòng nào, chúng tôi yêu cầu Oi biết danh tính của ít nhất một nút cấp hai trung thực. Với giao thức tương tác trong đó mỗi nút cấp hai thêm một sự ngẫu nhiên yếu tố chia sẻ, điều tốt nhất mà kẻ hối lộ có thể làm là ép buộc Oi lựa chọn ngẫu nhiên chút canh gác. 9,6 Khung khuyến khích tiềm ẩn (IIF) FFO là một hình thức khuyến khích ngầm cho hành vi đúng trong mạng Chainlink. Nó các chức năng như cổ phần rõ ràng, tức là tiền gửi, trong đó nó giúp thực thi an ninh kinh tế cho mạng lưới. Nói cách khác, FFO nên được đưa vào như một phần của khoản tiền gửi (có hiệu lực) $d của một nút trong mạng.Câu hỏi đặt ra là: Làm cách nào để đo lường FFO và các hình thức khuyến khích tiềm ẩn khác? trong mạng Chainlink? Khung khuyến khích tiềm ẩn (IIF) là một tập hợp các nguyên tắc và kỹ thuật mà chúng tôi dự định phát triển cho mục đích này. Hệ thống chuỗi khối cung cấp nhiều hình thức minh bạch chưa từng có và các bản ghi có độ tin cậy cao của nút hiệu suất mà họ tạo ra là bàn đạp cho tầm nhìn của chúng tôi về cách thức hoạt động của IIF. Ở đây chúng tôi phác thảo rất ngắn gọn các ý tưởng về các yếu tố chính của IIF. Bản thân IIF sẽ bao gồm một tập hợp các yếu tố mà chúng tôi xác định là quan trọng trong việc đánh giá các biện pháp khuyến khích tiềm ẩn, cùng với các cơ chế xuất bản dữ liệu liên quan ở dạng có độ bảo đảm cao để các thuật toán phân tích sử dụng. Những người dùng Chainlink khác nhau có thể muốn sử dụng IIF theo nhiều cách khác nhau, ví dụ: đưa ra trọng số khác nhau cho các yếu tố khác nhau. Chúng tôi hy vọng các dịch vụ phân tích sẽ xuất hiện trong cộng đồng giúp người dùng áp dụng IIF theo sở thích đánh giá rủi ro cá nhân của họ và mục tiêu của chúng tôi là tạo điều kiện thuận lợi các dịch vụ đó bằng cách đảm bảo quyền truy cập của họ vào dữ liệu hỗ trợ kịp thời và có độ bảo đảm cao, như chúng ta thảo luận dưới đây (Phần 9.6.4). 9.6.1 Cơ hội phí trong tương lai Các nút tham gia vào hệ sinh thái Chainlink để kiếm được một phần phí mà mạng chi trả cho bất kỳ dịch vụ nào trong số các dịch vụ khác nhau mà chúng tôi đã mô tả trong bài viết này, từ nguồn cấp dữ liệu thông thường đến các dịch vụ nâng cao như nhận dạng phi tập trung, sắp xếp công bằng, và bảo mật DeFi. Các khoản phí trong mạng Chainlink hỗ trợ chi phí của người vận hành nút, ví dụ: chạy máy chủ, lấy giấy phép dữ liệu cần thiết và duy trì một đội ngũ nhân viên toàn cầu để đảm bảo thời gian hoạt động cao. FFO biểu thị phí dịch vụ, chi phí ròng, rằng một nút sẽ được lợi trong tương lai—hoặc bị mất nếu nó thể hiện hành vi bị lỗi. FFO là một hình thức stake giúp bảo mật mạng. Một tính năng hữu ích của FFO là dữ liệu trên chuỗi (được bổ sung bởi các dữ liệu ngoài chuỗi data) thiết lập bản ghi có độ tin cậy cao về lịch sử của nút, cho phép tính toán FFO một cách minh bạch, mang tính thực nghiệm. Một phép đo FFO đơn giản, bậc nhất có thể được lấy từ doanh thu ròng trung bình của một nút trong một khoảng thời gian (tức là tổng doanh thu trừ đi chi phí hoạt động). FFO có thể sau đó được tính như sau, ví dụ: giá trị hiện tại ròng [114] của doanh thu ròng tích lũy trong tương lai, nói cách khác, giá trị chiết khấu theo thời gian của tất cả thu nhập trong tương lai. Tuy nhiên, doanh thu từ nút có thể không ổn định, như minh họa trong Hình 17. Quan trọng hơn, doanh thu từ nút có thể không tuân theo sự phân phối cố định theo thời gian. Do đó, các yếu tố khác mà chúng tôi dự định khám phá khi ước tính FFO bao gồm: • Lịch sử hiệu suất: Lịch sử hiệu suất của nhà điều hành—bao gồm tính chính xác và kịp thời của các báo cáo cũng như thời gian hoạt động của nó—cung cấp một mục tiêu tiêu chuẩn để người dùng đánh giá độ tin cậy của nó. Do đó, lịch sử hiệu suất sẽ cung cấp yếu tố quan trọng trong việc người dùng lựa chọn các nút oracle (hoặc, với sự xuất hiện trong số DONs, lựa chọn DONs của họ). Một lịch sử hiệu suất mạnh mẽ có thể tương quan với doanh thu liên tục cao.18 18Một câu hỏi nghiên cứu quan trọng mà chúng tôi dự định giải quyết là phát hiện khối lượng dịch vụ giả mạo.Hình 17: Doanh thu kiếm được từ các nút Chainlink trên một nguồn cấp dữ liệu duy nhất (ETH-USD) trong một tuần điển hình vào tháng 3 năm 2021. • Truy cập dữ liệu: Mặc dù oracles có thể lấy nhiều dạng dữ liệu từ các API mở, một số dạng dữ liệu nhất định hoặc một số nguồn chất lượng cao nhất định có thể chỉ có sẵn trên một cơ sở đăng ký hoặc thông qua các thỏa thuận hợp đồng. Quyền truy cập đặc quyền vào một số nguồn dữ liệu có thể đóng vai trò tạo ra nguồn doanh thu ổn định. • Sự tham gia của DON: Với sự xuất hiện của DONs, cộng đồng các nút sẽ xuất hiện cùng nhau cung cấp các dịch vụ cụ thể. Chúng tôi hy vọng rằng nhiều DON sẽ bao gồm các nhà khai thác trên cơ sở chọn lọc, thiết lập sự tham gia vào các DON có uy tín với tư cách là một vị trí thị trường đặc quyền giúp đảm bảo nguồn doanh thu ổn định. • Hoạt động đa nền tảng: Một số nhà khai thác nút có thể có sự hiện diện và hồ sơ theo dõi hiệu suất được thiết lập tốt trong các bối cảnh khác, ví dụ: như PoS validators hoặc nhà cung cấp dữ liệu trong ngữ cảnh không phải blockchain. Hiệu suất của chúng trong các hệ thống khác này (khi dữ liệu trên đó có sẵn ở dạng đáng tin cậy) có thể đưa ra đánh giá lịch sử hoạt động của họ. Tương tự, hành vi bị lỗi trong mạng Chainlink có thể gây nguy hiểm cho doanh thu trong các hệ thống khác này bằng cách khiến người dùng rời xa, tức là FFO có thể mở rộng trên các nền tảng. 9.6.2 FFO đầu cơ Các nhà khai thác nút tham gia vào mạng Chainlink không chỉ để tạo doanh thu từ mà là tạo dựng và định vị bản thân để tận dụng các cơ hội mới để thực hiện công việc. Nói cách khác, chi tiêu của các nút oracle trong mạng cũng tuyên bố tích cực về tương lai của DeFi và ứng dụng hợp đồng thông minh khác các miền cũng như các ứng dụng không thuộc blockchain mới nổi của mạng oracle. Các nhà khai thác nút ngày nay kiếm được khoản phí có sẵn trên các mạng Chainlink hiện có và đồng thời Những điều này gần giống với các đánh giá giả mạo trên các trang internet, ngoại trừ vấn đề dễ xảy ra hơn ở phần oracle cài đặt vì chúng tôi có hồ sơ chính xác về việc hàng hóa, tức là các báo cáo, đã được đặt hàng và chưa được giao—trái ngược với, ví dụ: hàng hóa vật chất được đặt hàng trong các cửa hàng trực tuyến. Nói cách khác, trong oracle cài đặt, hiệu suất có thể được xác thực, ngay cả khi tính xác thực của khách hàng không thể.xây dựng danh tiếng, lịch sử hoạt động và chuyên môn điều hành sẽ định vị họ một cách thuận lợi để kiếm được phí sẵn có trong các mạng trong tương lai (tất nhiên, về hành vi trung thực). Các nút hoạt động trong hệ sinh thái Chainlink ngày nay sẽ tham gia vào việc này cảm thấy có lợi thế hơn người mới trong việc kiếm thêm phí Chainlink dịch vụ trở nên sẵn có. Lợi thế này áp dụng cho các nhà khai thác mới cũng như các công ty công nghệ đã có danh tiếng; ví dụ: T-Systems, một công ty truyền thống nhà cung cấp công nghệ (công ty con của Deutsche Telekom) và Kraken, một công ty tập trung lớn Exchange, đã thiết lập sự hiện diện sớm trong hệ sinh thái Chainlink [28, 143]. Sự tham gia như vậy của các nút oracle trong các cơ hội trong tương lai có thể được coi là chính nó như một loại FFO đầu cơ và do đó tạo thành một dạng cổ phần trong Chainlink mạng. 9.6.3 Danh tiếng bên ngoài IIF như chúng tôi đã mô tả, nó có thể hoạt động trong một mạng có biệt danh hoàn toàn các nhà điều hành, tức là không tiết lộ những người hoặc các thực thể trong thế giới thực có liên quan. Tuy nhiên, một yếu tố quan trọng tiềm tàng đối với việc người dùng lựa chọn nhà cung cấp là bên ngoài. danh tiếng. Khi nói đến danh tiếng bên ngoài, chúng tôi muốn nói đến nhận thức về độ tin cậy gắn liền với danh tính trong thế giới thực chứ không phải là bút danh. Rủi ro danh tiếng gắn liền với danh tính trong thế giới thực có thể được xem như một hình thức khuyến khích ngầm. Chúng tôi xem danh tiếng thông qua lăng kính của IIF, tức là theo nghĩa kinh tế học mật mã, như một phương tiện để thiết lập hoạt động đa nền tảng có thể được đưa vào ước tính FFO. Lợi ích của việc sử dụng danh tiếng bên ngoài làm yếu tố ước tính FFO, trái ngược với với liên kết biệt danh, là danh tiếng bên ngoài liên kết hiệu quả hoạt động không chỉ với các hoạt động hiện tại của nhà điều hành cũng như các hoạt động trong tương lai. Ví dụ, nếu mang tiếng xấu gắn liền với một cá nhân, nó có thể làm hoen ố doanh nghiệp tương lai của người đó. Nói cách khác, danh tiếng bên ngoài có thể nắm bắt được phạm vi FFO rộng hơn so với bút danh hồ sơ hoạt động, vì tác động của hành vi sai trái gắn liền với một người hoặc tổ chức công ty khó trốn thoát hơn công ty liên quan đến hoạt động dưới danh nghĩa. Chainlink tương thích với các công nghệ nhận dạng phi tập trung (Phần 4.3) có thể cung cấp hỗ trợ cho việc sử dụng danh tiếng bên ngoài trong IIF. Những công nghệ như vậy có thể xác nhận và do đó giúp đảm bảo tính xác thực của các nhà khai thác trong thế giới thực được khẳng định danh tính.19 9.6.4 Mở phân tích IIF IIF, như chúng tôi đã lưu ý, nhằm mục đích cung cấp các công cụ và dữ liệu nguồn mở đáng tin cậy cho phân tích khuyến khích ngầm. Mục tiêu là cho phép các nhà cung cấp trong cộng đồng để phát triển các phân tích phù hợp với nhu cầu đánh giá rủi ro của các bộ phận khác nhau trong Chainlink cơ sở người dùng. 19Thông tin xác thực danh tính phi tập trung cũng có thể, nếu muốn, tô điểm cho các bút danh bằng các tên đã được xác thực thông tin bổ sung. Ví dụ: về nguyên tắc, người vận hành nút có thể sử dụng thông tin xác thực đó để chứng minh rằng đó là công ty Fortune 500 mà không tiết lộ đó là công ty nào.Một lượng dữ liệu lịch sử đáng kể liên quan đến doanh thu và hiệu suất của các nút nằm trên chuỗi ở dạng có độ tin cậy cao, không thể thay đổi. Tuy nhiên, mục tiêu của chúng tôi là cung cấp dữ liệu toàn diện nhất có thể, bao gồm dữ liệu về các hành vi chỉ có thể nhìn thấy được chuỗi, chẳng hạn như hoạt động Báo cáo Off-Chain (OCR) hoặc DON. Những dữ liệu như vậy có khả năng hãy đồ sộ. Cách tốt nhất để lưu trữ và đảm bảo tính toàn vẹn của nó, tức là bảo vệ nó khỏi chúng tôi tin rằng việc giả mạo sẽ được thực hiện với sự trợ giúp của DONs, sử dụng các kỹ thuật được thảo luận trong Phần 3.3. Một số khuyến khích phù hợp với các hình thức đo lường trực tiếp, chẳng hạn như staking tiền gửi và FFO cơ bản. Những thứ khác, chẳng hạn như FFO đầu cơ và danh tiếng, khó bị ảnh hưởng hơn. đo lường một cách khách quan, nhưng chúng tôi tin rằng các dạng dữ liệu hỗ trợ, bao gồm sự phát triển lịch sử của hệ sinh thái Chainlink, số liệu về danh tiếng trên mạng xã hội, v.v., có thể hỗ trợ các mô hình phân tích IIF ngay cả đối với các yếu tố khó định lượng hơn này. Chúng ta có thể tưởng tượng rằng DON chuyên dụng phát sinh đặc biệt để giám sát, xác thực và ghi lại dữ liệu liên quan đến bản ghi hiệu suất ngoài chuỗi của các nút, cũng như các dữ liệu khác được sử dụng trong IIF, chẳng hạn như thông tin nhận dạng được xác thực. Những DON này có thể cung cấp dữ liệu IIF thống nhất, có độ tin cậy cao cho bất kỳ nhà cung cấp phân tích nào phục vụ cộng đồng Chainlink. Họ cũng sẽ cung cấp một bản ghi vàng đưa ra tuyên bố của các nhà cung cấp phân tích được cộng đồng xác minh độc lập. 9,7 Kết hợp tất cả lại với nhau: Khuyến khích người vận hành nút Tổng hợp các cuộc thảo luận của chúng tôi ở trên về các ưu đãi rõ ràng và tiềm ẩn đối với các nhà khai thác nút cung cấp cái nhìn toàn diện về cách mà các nhà khai thác nút tham gia và hưởng lợi từ mạng Chainlink. Theo hướng dẫn khái niệm, chúng tôi có thể biểu thị tổng tài sản đang bị đe dọa bằng Chainlink nhất định toán tử nút $S ở dạng thô, cách điệu như: \(S ≈\)D + \(F + \)FS + $R, ở đâu: • $D là tổng hợp của tất cả cổ phần được ký gửi rõ ràng trên tất cả các mạng trong đó người điều hành tham gia; • $F là giá trị hiện tại ròng của tổng hợp tất cả FFO trên tất cả các mạng trong mà nhà điều hành tham gia; • $FS là giá trị hiện tại ròng của FFO đầu cơ của nhà điều hành; và • $R là giá trị danh tiếng của nhà điều hành bên ngoài hệ sinh thái Chainlink có thể bị nguy hiểm do hành vi sai trái được xác định trong các nút oracle của nó. Mặc dù phần lớn chỉ mang tính khái niệm, nhưng sự bình đẳng sơ bộ này cho thấy một cách hữu ích rằng có rất nhiều yếu tố kinh tế ủng hộ hiệu suất có độ tin cậy cao của các nút Chainlink. Tất cả những yếu tố này ngoài $D đều có trong mạng Chainlink ngày nay.9,8 Chu kỳ đạo đức của an ninh kinh tế Sự kết hợp giữa tác động siêu tuyến tính staking với việc thể hiện các khoản thanh toán phí vì cơ hội phí trong tương lai (FFO) trong IIF có thể dẫn đến cái mà chúng ta gọi là chu kỳ đạo đức về an ninh kinh tế trong mạng oracle. Đây có thể coi là một loại hình kinh tế về quy mô. Khi tổng số tiền được bảo đảm bởi một mạng cụ thể tăng lên, số lượng số cổ phần bổ sung cần có để tăng thêm một lượng cố định về an ninh kinh tế sẽ giảm đi chi phí trung bình cho mỗi người dùng. Do đó, về mặt phí, người dùng tham gia sẽ rẻ hơn một mạng lưới đã tồn tại hơn là đạt được mức tăng trưởng kinh tế mạng tương tự bảo mật bằng cách tạo ra một mạng mới. Điều quan trọng là việc thêm mỗi người dùng mới sẽ làm giảm chi phí dịch vụ cho tất cả người dùng trước đây của mạng đó. Với một cấu trúc phí cụ thể (ví dụ: tỷ suất lợi nhuận cụ thể trên số tiền đặt cược), nếu tổng phí mà mạng kiếm được tăng lên, điều này sẽ khuyến khích dòng tiền bổ sung tham gia vào mạng để bảo mật nó ở mức cao hơn. Cụ thể, nếu tổng số cổ phần một nút riêng lẻ có thể giữ trong hệ thống bị giới hạn, sau đó khi thanh toán phí mới vào hệ thống, tăng FFO của nó, số lượng nút n sẽ tăng lên. Nhờ có tác động siêu tuyến tính staking của thiết kế hệ thống khuyến khích của chúng tôi, an ninh kinh tế của hệ thống sẽ tăng nhanh hơn n, ví dụ như n2 trong cơ chế chúng ta phác họa ở Phần 9.4. Kết quả là, chi phí trung bình cho an ninh kinh tế - tức là lượng cổ phần đóng góp một đô la an ninh kinh tế – sẽ giảm. Do đó, mạng có thể tính phí người dùng của nó phí thấp hơn. Giả sử rằng nhu cầu về dịch vụ oracle co giãn (xem ví dụ: [31] để biết thông tin tóm tắt giải thích), nhu cầu sẽ tăng lên, tạo ra phí bổ sung và FFO. Chúng tôi minh họa điểm này bằng ví dụ sau. Ví dụ 5. Vì tính bảo mật kinh tế của mạng oracle với sự khuyến khích của chúng tôi kế hoạch là \(dn2 for stake \)dn, an ninh kinh tế được đóng góp bởi một đô la cổ phần là n và do đó chi phí trung bình trên mỗi đô la của an ninh kinh tế—tức là số lượng cổ phần đóng góp vào một đô la an ninh kinh tế - là 1/n. Hãy xem xét một mạng lưới trong đó các khuyến khích kinh tế bao gồm toàn bộ FFO, có giới hạn ở mức \(d ≤\)10K mỗi nút. Giả sử mạng có n = 3 nút. Khi đó chi phí trung bình mỗi đô la an ninh kinh tế là khoảng 0,33 đô la. Giả sử tổng FFO của mạng tăng lên trên \(30K (e.g., to \)31K). Cho giới hạn trên FFO mỗi nút, mạng sẽ tăng lên (ít nhất) n = 4. Bây giờ chi phí trung bình mỗi đô la an ninh kinh tế giảm xuống còn khoảng 0,25 đô la. Chúng tôi minh họa chu trình tốt đẹp đầy đủ của an ninh kinh tế trong các mạng oracle một cách sơ đồ trong Hình 18. Chúng tôi nhấn mạnh rằng chu kỳ lành mạnh của an ninh kinh tế bắt nguồn từ hiệu ứng người dùng gộp phí của họ. Đó là FFO tập thể của họ hoạt động vì lợi ích lớn hơn quy mô mạng và do đó an ninh tập thể lớn hơn. Chúng tôi cũng lưu ý rằng chu kỳ đạo đức của an ninh kinh tế hoạt động có lợi cho DON đạt được sự bền vững về tài chính. Một lần đã tạo, DON đáp ứng nhu cầu của người dùng sẽ tăng lên đến mức mà tại đó doanh thu từ phí vượt quá chi phí hoạt động cho oracle nút.
Hình 18: Sơ đồ chu trình đạo đức của Chainlink staking. Phí sử dụng tăng thanh toán cho mạng oracle 1⃝ khiến mạng này phát triển, dẫn đến tăng trưởng về mặt kinh tế an ninh 2⃝. Sự tăng trưởng siêu tuyến tính này hiện thực hóa tính kinh tế theo quy mô trong mạng Chainlink 3⃝. Cụ thể, nó có nghĩa là giảm chi phí trung bình của an ninh kinh tế, tức là, đảm bảo kinh tế trên mỗi đô la phát sinh từ việc thanh toán phí hoặc các nguồn cổ phần khác tăng lên. Chi phí thấp hơn, được chuyển tới người dùng, kích thích nhu cầu tăng lên đối với oracle dịch vụ 4⃝. 9,9 Các yếu tố bổ sung thúc đẩy tăng trưởng mạng lưới Khi hệ sinh thái Chainlink tiếp tục mở rộng, chúng tôi tin rằng sức hấp dẫn của nó đối với người dùng và tầm quan trọng của cơ sở hạ tầng đối với nền kinh tế blockchain sẽ tăng tốc. Giá trị do mạng oracle cung cấp là siêu tuyến tính, nghĩa là giá trị này tăng nhanh hơnhơn kích thước của mạng. Sự tăng trưởng về giá trị này xuất phát từ cả tính kinh tế theo quy mô—hiệu quả chi phí cho mỗi người dùng lớn hơn khi khối lượng dịch vụ tăng lên—và hiệu ứng mạng—sự gia tăng tiện ích mạng khi người dùng áp dụng DON rộng rãi hơn. Vì smart contract hiện tại tiếp tục nhận được nhiều giá trị được bảo đảm hơn và hoàn toàn mới smart contract các ứng dụng được thực hiện nhờ nhiều dịch vụ phi tập trung hơn, tổng cộng việc sử dụng và tổng phí trả cho DON sẽ tăng lên. Tăng các khoản phí trong biến dịch thành phương tiện và động lực để tạo ra nhiều dịch vụ phi tập trung hơn, dẫn đến một chu kỳ đạo đức. Chu kỳ đạo đức này giải quyết vấn đề con gà và quả trứng quan trọng vấn đề trong hệ sinh thái lai smart contract: Các tính năng smart contract đổi mới thường yêu cầu các dịch vụ phi tập trung chưa tồn tại (ví dụ: các thị trường DeFi mới thường yêu cầu nguồn cấp dữ liệu mới) nhưng vẫn cần có đủ nhu cầu kinh tế để tồn tại. Việc gộp phí theo nhiều smart contract khác nhau cho DON hiện tại sẽ báo hiệu nhu cầu về các dịch vụ phi tập trung bổ sung từ cơ sở người dùng ngày càng tăng, dẫn đến sự sáng tạo của chúng bởi DONs và sự hỗ trợ liên tục của smart contracts kết hợp mới và đa dạng. Tóm lại, chúng tôi tin rằng sự tăng trưởng về an ninh mạng được thúc đẩy bởi đạo đức các chu kỳ trong cơ chế Chainlink staking minh họa cho các mô hình tăng trưởng lớn hơn mạng Chainlink có thể giúp mang lại nền kinh tế trực tuyến cho phi tập trung dịch vụ.
خاتمة
في هذه الورقة، وضعنا رؤية لتطور Chainlink. الموضوع الرئيسي في هذه الرؤية تكمن قدرة الشبكات oracle على توفير نطاق أوسع بكثير من الخدمات smart contracts أكثر من مجرد تسليم البيانات. باستخدام DONs كأساس للخدمات اللامركزية في المستقبل، سيهدف Chainlink إلى توفير وظائف oracle عالية الأداء ومعززة للسرية. ستوفر شبكات oracle الخاصة بها تقليلًا قويًا للثقة من خلال مجموعة من آليات الاقتصاد المشفر المبدئية مثل staking و حواجز حماية مصممة بعناية وإنفاذ على مستوى الخدمة يعتمد على السلاسل الرئيسية. سيساعد DONs أيضًا أنظمة الطبقة الثانية على فرض سياسات طلب مرنة وعادلة على المعاملات، بالإضافة إلى تقليل تكاليف الغاز للمعاملات الموجهة بواسطة الذاكرة. مجتمعة، كل هذه القدرات تقود في اتجاه نظام ذكي هجين آمن وغني بالوظائف العقود. ستؤدي مرونة DONs إلى تحسين خدمات Chainlink الحالية وتؤدي إلى العديد من الميزات والتطبيقات الإضافية smart contract. ومن بين هذه سلسة الاتصال بمجموعة واسعة من الأنظمة خارج السلسلة، وإنشاء الهوية اللامركزية من البيانات الحالية، والقنوات ذات الأولوية للمساعدة في ضمان تسليم البنية التحتية الحيوية في الوقت المناسب المعاملات وأدوات الحفاظ على السرية DeFi. إن الرؤية التي طرحناها هنا طموحة. وعلى المدى القصير، نسعى إلى التمكين عقود هجينة لتحقيق أهداف بعيدة عن متناول smart contracts اليوم، بينما على المدى الطويل، نهدف إلى تحقيق طبقة معدنية لا مركزية. لحسن الحظ يمكننا الرسم على أدوات وأفكار جديدة، تتراوح من خوارزميات الإجماع إلى إثبات المعرفة الصفرية الأنظمة - التي يتطورها المجتمع كثمرة لأبحاث سريعة التطور.
وبالمثل، نتوقع إعطاء الأولوية لتنفيذ الأفكار الواردة في هذه الورقة ردًا على ذلك لتلبية احتياجات مجتمع مستخدمي Chainlink. ونحن نتطلع إلى المرحلة التالية في سعينا لتمكين smart contracts من خلال الاتصال العالمي والتأسيس التكنولوجيات اللامركزية باعتبارها العمود الفقري للجيل القادم من الخدمات المالية في العالم والأنظمة القانونية. شكر وتقدير شكرًا لجوليان ألتريني وشون لي على تقديم الأرقام الواردة في هذه الورقة.
Phần kết luận
Trong bài viết này, chúng tôi đã đặt ra tầm nhìn về sự phát triển của Chainlink. Chủ đề chính trong tầm nhìn này là khả năng của các mạng oracle trong việc cung cấp phạm vi dịch vụ rộng hơn nhiều cho smart contracts hơn là chỉ phân phối dữ liệu. Sử dụng DON làm nền tảng cho các dịch vụ phi tập trung trong tương lai, Chainlink sẽ nhằm mục đích cung cấp chức năng oracle được nâng cao hiệu quả, bảo mật. Mạng oracle của nó sẽ cung cấp khả năng giảm thiểu tin cậy mạnh mẽ thông qua sự kết hợp của các cơ chế kinh tế mật mã nguyên tắc như staking và các đường ray bảo vệ được hình thành cẩn thận và thực thi cấp độ dịch vụ dựa trên các chuỗi chính. DONs cũng sẽ giúp các hệ thống lớp 2 thực thi các chính sách đặt hàng công bằng, linh hoạt đối với các giao dịch cũng như giảm chi phí gas cho các giao dịch được định tuyến theo mempool. Gộp lại với nhau, tất cả những khả năng này đều hướng tới sự an toàn và đa chức năng kết hợp thông minh hợp đồng. Tính linh hoạt của DON sẽ nâng cao các dịch vụ Chainlink hiện có và làm phát sinh nhiều tính năng và ứng dụng smart contract bổ sung. Trong số này là liền mạch kết nối với nhiều hệ thống ngoài chuỗi, tạo danh tính phi tập trung từ dữ liệu hiện có, các kênh ưu tiên để giúp đảm bảo cung cấp kịp thời các cơ sở hạ tầng quan trọng giao dịch và các công cụ DeFi bảo mật bí mật. Tầm nhìn chúng tôi đặt ra ở đây đầy tham vọng. Trong ngắn hạn, chúng tôi tìm cách trao quyền hợp đồng kết hợp để hoàn thành các mục tiêu ngoài tầm với của smart contract giây hôm nay, trong khi về lâu dài, chúng tôi mong muốn hiện thực hóa một lớp kim loại phi tập trung. Thật hạnh phúc khi chúng ta có thể vẽ về các công cụ và ý tưởng mới—từ thuật toán đồng thuận đến bằng chứng không có kiến thức hệ thống—mà cộng đồng đang phát triển là thành quả của nghiên cứu đang phát triển nhanh chóng.
Tương tự, chúng tôi hy vọng sẽ ưu tiên thực hiện các ý tưởng trong bài viết này để đáp ứng đáp ứng nhu cầu của cộng đồng người dùng Chainlink. Chúng tôi mong chờ giai đoạn tiếp theo trong nỗ lực của chúng tôi nhằm trao quyền cho smart contract thông qua kết nối toàn cầu và thiết lập công nghệ phi tập trung như là xương sống của thế hệ tài chính tiếp theo của thế giới và các hệ thống pháp luật. Lời cảm ơn Cảm ơn Julian Alterini và Shawn Lee đã đưa ra các số liệu trong bài viết này.