Polkadot：异构多链框架的愿景
خلاصة
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 د. جافين وود مؤسس الإيثيريوم والتكافؤ جافين@PARITY.IO مجردة. تعاني جميع بنيات blockchain الحالية من عدد من المشكلات ليس أقلها الوسائل العملية لقابلية التوسعة وقابلية التوسع. ونعتقد أن هذا ينبع من ربط جزأين مهمين للغاية في بنية الإجماع، وهما الشرعية والصلاحية، قريبان جدًا من بعضهما البعض. تقدم هذه الورقة بنية، السلاسل المتعددة غير المتجانسة، الذي يميز بين الاثنين بشكل أساسي. في تقسيم هذين الجزأين، ومن خلال الحفاظ على الوظائف العامة المقدمة إلى الحد الأدنى المطلق فيما يتعلق بالأمن والنقل، فإننا نقدم وسائل عملية للتوسعة الأساسية في الموقع. تتم معالجة قابلية التوسع من خلال نهج فرق تسد في هاتين الوظيفتين، والخروج من جوهره المستعبد من خلال تحفيز العقد العامة غير الموثوق بها. إن الطبيعة غير المتجانسة لهذه البنية تمكن العديد من الأنواع المتباينة للغاية من أنظمة الإجماع التي تتفاعل في "اتحاد" غير موثوق به ولامركزي بالكامل، مما يسمح للشبكات المفتوحة والمغلقة بالوصول دون ثقة إلى بعضها البعض. لقد طرحنا وسيلة لتوفير التوافق العكسي مع واحدة أو أكثر من الشبكات الموجودة مسبقًا مثل Ethereum. ونحن نعتقد أن مثل هذا النظام يوفر مكونًا مفيدًا على المستوى الأساسي في البحث الشامل عن عملية نظام قابل للتنفيذ قادر على تحقيق مستويات التجارة العالمية من قابلية التوسع والخصوصية. 1. المقدمة يهدف هذا إلى أن يكون ملخص "رؤية" فنية لاتجاه واحد محتمل يمكن اتخاذه في مواصلة تطوير نموذج blockchain مع بعض الأسباب المنطقية لسبب كون هذا الاتجاه معقولًا. انها تضع في أكبر قدر ممكن من التفاصيل في هذه المرحلة من التطوير النظام الذي قد يعطي تحسنا ملموسا على أ عدد جوانب تقنية blockchain. وليس المقصود أن تكون مواصفات رسمية أو غير ذلك. وليس المقصود أن تكون شاملة ولا أن تكون التصميم النهائي. وليس المقصود منه تغطية الجوانب غير الأساسية للإطار مثل واجهات برمجة التطبيقات والارتباطات واللغات و الاستخدام. هذا تجريبي بشكل خاص. حيث المعلمات محددة، فمن المرجح أن تتغير. الآليات سوف تتم إضافتها وصقلها وإزالتها استجابة للمجتمع الأفكار والانتقادات. من المحتمل أن تكون أجزاء كبيرة من هذه الورقة يمكن تنقيحها كأدلة تجريبية ونماذج أولية لنا معلومات حول ما سيعمل وما لا. تتضمن هذه الوثيقة وصفًا أساسيًا للبروتوكول بالإضافة إلى أفكار حول التوجيهات التي يمكن اتخاذها لتحسين الجوانب المختلفة. ومن المتصور أن الأساسية سيتم استخدام الوصف كنقطة بداية للبداية سلسلة من البراهين على المفهوم. سيكون "الإصدار 1.0" النهائي استنادًا إلى هذا البروتوكول المكرر جنبًا إلى جنب مع الأفكار الإضافية التي تم إثباتها وعقد العزم على تحقيقها اللازمة حتى يصل المشروع إلى أهدافه. 1.1. تاريخ. • 10/09/2016: 0.1.0-proof1 • 20/10/2016: 0.1.0-proof2 • 11/01/2016: 0.1.0-proof3 • 10/11/2016: 0.1.0 2. مقدمة لقد أظهرت Blockchains وعدًا كبيرًا بالفائدة في العديد من المجالات بما في ذلك "إنترنت الأشياء" (إنترنت الأشياء)، والتمويل، والحوكمة، وإدارة الهوية، ولامركزية الويب، وتتبع الأصول. ومع ذلك، على الرغم من الوعد التكنولوجي والحديث الكبير، لم نر بعد نشر كبير في العالم الحقيقي للتكنولوجيا الحالية. ونحن نعتقد أن هذا يرجع إلى خمسة إخفاقات رئيسية في الوقت الحاضر مكدسات التكنولوجيا: قابلية التوسع: مقدار الموارد التي يتم إنفاقها على مستوى العالم حول المعالجة وعرض النطاق الترددي والتخزين للنظام لمعالجة معاملة واحدة وكم عددها يمكن معالجة المعاملات بشكل معقول بموجب ظروف الذروة؟ قابلية العزلة: يمكن أن تكون الاحتياجات المتباينة متعددة هل تتم معالجة الأطراف والطلبات بدرجة قريبة من المستوى الأمثل ضمن نفس الإطار؟ قابلية التطوير: ما مدى جودة عمل الأدوات؟ افعل هل تلبي واجهات برمجة التطبيقات احتياجات المطورين؟ هل المواد التعليمية متوفرة؟ هل التكامل الصحيح موجود؟ الحوكمة: هل يمكن أن تظل الشبكة مرنة؟ تتطور وتتكيف مع مرور الوقت؟ هل يمكن أن تكون القرارات مصنوعة بالشمولية والشرعية الكافية الشفافية لتوفير القيادة الفعالة ل النظام اللامركزي؟ قابلية التطبيق: هل تعالج التكنولوجيا بالفعل حاجة ملحة من تلقاء نفسها؟ هل هناك حاجة إلى "برامج وسيطة" أخرى من أجل سد الفجوة التطبيقات الفعلية؟ في العمل الحالي، ونحن نهدف إلى معالجة الأولين القضايا: قابلية التوسع والعزلة. وقيل: نحن نؤمن يمكن لإطار عمل Polkadot أن يوفر تحسينات ذات معنى في كل فئة من هذه الفئات من المشاكل. تطبيقات blockchain الحديثة والفعالة مثل يمكن لعميل التكافؤ Ethereum [17] إجراء العمليةيس ما يزيد على 3000 معاملة في الثانية عند التشغيل على أجهزة استهلاكية عالية الأداء. ومع ذلك، العالم الحقيقي الحالي تقتصر شبكات blockchain عمليًا على حوالي 30 شبكة المعاملات في الثانية الواحدة. ينشأ هذا القيد أساسًا من حقيقة أن آليات الإجماع المتزامن الحالية تتطلب هوامش توقيت واسعة من الأمان وقت المعالجة المتوقع، والذي يتفاقم بسبب 1
摘要
Polkadot：异构多链框架的愿景 草案1 博士。加文·伍德 以太坊和 Parity 创始人 加文@PARITY.IO 摘要。当今的 blockchain 架构都存在许多问题，尤其是可扩展性和可伸缩性的实用方法。我们相信这源于共识架构的两个非常重要的部分，即 规范性和有效性过于紧密地结合在一起。本文介绍了一种架构，异构多链， 这从根本上将两者区分开来。 将这两部分分开，并将提供的整体功能保持在绝对最低限度 在安全和运输方面，我们引入了核心可扩展性的实用方法。可扩展性是通过以下方式解决的 对这两个功能采取分而治之的方法，通过激励来扩展其粘合核心 不受信任的公共节点。 这种架构的异构性使得许多高度不同类型的共识系统能够在一个不信任的、完全去中心化的“联盟”中互操作，从而允许开放和封闭的网络能够无信任地访问 彼此。 我们提出了一种提供与一个或多个预先存在的网络的向后兼容性的方法，例如 Ethereum。我们相信，这样的系统在总体搜索实际应用中提供了有用的基础组件。 能够实现全球商务级别的可扩展性和隐私性的可实施系统。 一、前言 这是一个技术“愿景”摘要 进一步开发 blockchain 范式时可能采取的一个可能方向，以及为什么这个方向是明智的一些基本原理。它布置在 在此开发阶段尽可能详细 一个可以具体改进的系统 blockchain 技术的多个方面。 它无意成为正式或其他形式的规范。它的目的不是全面的，也不是 最终设计。它无意涵盖非核心方面 框架，例如 API、绑定、语言和 用法。 这显然是实验性的；其中参数 已被指定，它们很可能会改变。机制将 根据社区的需求进行添加、完善和删除 想法和批评。本文的大部分内容可能会 作为实验证据和原型进行修改给出 我们提供有关什么有效、什么无效的信息。 本文档包括协议的核心描述以及可能采取的方向的想法 以改善各方面。据设想，核心 描述将用作初始的起点 系列概念验证。最终的“版本 1.0”将是 基于这个完善的协议以及经过验证并确定的其他想法 是项目实现其目标所必需的。 1.1.历史。 • 2016 年 9 月 10 日：0.1.0-proof1 • 2016 年 10 月 20 日：0.1.0-proof2 • 2016 年 1 月 11 日：0.1.0-proof3 • 2016 年 10 月 11 日：0.1.0 2. 简介 区块链在包括“物联网”在内的多个领域展示了巨大的实用前景 （物联网）、财务、治理、身份管理、网络去中心化和资产跟踪。然而，尽管 技术承诺和宏大的言论，我们还没有看到 当前技术在现实世界中的重大部署。 我们认为，这归因于当前的五个关键失败 技术栈： 可扩展性：全球花费了多少资源 系统处理单笔交易的处理能力、带宽和存储以及多少 交易可以合理地处理 峰值条件？ 隔离性：能否满足多个人的不同需求 各方和应用程序是否可以在同一框架下达到近乎最佳的程度？ 可开发性：这些工具的工作效果如何？做 API 满足了开发人员的需求吗？有教育材料吗？那里有正确的集成吗？ 治理：网络能否保持灵活性 随着时间的推移而发展和适应？ 决策可以是 具有足够的包容性、合法性和 透明度，以提供有效的领导 去中心化系统？ 适用性：该技术本身是否真的能够满足迫切的需求？是否需要其他“中间件”来弥补差距 实际应用？ 在目前的工作中，我们的目标是解决前两个问题 问题：可扩展性和隔离性。也就是说，我们相信 Polkadot 框架可以为每一类问题提供有意义的改进。 现代、高效的 blockchain 实现，例如 Parity Ethereum 客户端 [17] 可以处理es 超过 在高性能消费类硬件上运行时每秒处理 3,000 个事务。 然而，目前的现实世界 blockchain 网络实际上仅限于 30 个左右 每秒交易数。 这种限制主要源于当前的同步共识机制需要广泛的时间安全裕度。 预期的处理时间，这会因 1
مقدمة
لقد أظهرت Blockchains وعدًا كبيرًا بالفائدة في العديد من المجالات بما في ذلك "إنترنت الأشياء" (إنترنت الأشياء)، والتمويل، والحوكمة، وإدارة الهوية، ولامركزية الويب، وتتبع الأصول. ومع ذلك، على الرغم من الوعد التكنولوجي والحديث الكبير، لم نر بعد نشر كبير في العالم الحقيقي للتكنولوجيا الحالية. ونحن نعتقد أن هذا يرجع إلى خمسة إخفاقات رئيسية في الوقت الحاضر مكدسات التكنولوجيا: قابلية التوسع: مقدار الموارد التي يتم إنفاقها على مستوى العالم حول المعالجة وعرض النطاق الترددي والتخزين للنظام لمعالجة معاملة واحدة وكم عددها يمكن معالجة المعاملات بشكل معقول بموجب ظروف الذروة؟ قابلية العزلة: يمكن أن تكون الاحتياجات المتباينة متعددة هل تتم معالجة الأطراف والطلبات بدرجة قريبة من المستوى الأمثل ضمن نفس الإطار؟ قابلية التطوير: ما مدى جودة عمل الأدوات؟ افعل هل تلبي واجهات برمجة التطبيقات احتياجات المطورين؟ هل المواد التعليمية متوفرة؟ هل التكامل الصحيح موجود؟ الحوكمة: هل يمكن أن تظل الشبكة مرنة؟ تتطور وتتكيف مع مرور الوقت؟ هل يمكن أن تكون القرارات مصنوعة بالشمولية والشرعية الكافية الشفافية لتوفير القيادة الفعالة ل النظام اللامركزي؟ قابلية التطبيق: هل تعالج التكنولوجيا بالفعل حاجة ملحة من تلقاء نفسها؟ هل هناك حاجة إلى "برامج وسيطة" أخرى من أجل سد الفجوة التطبيقات الفعلية؟ في العمل الحالي، ونحن نهدف إلى معالجة الأولين القضايا: قابلية التوسع والعزلة. وقيل: نحن نؤمن يمكن لإطار عمل Polkadot أن يوفر تحسينات ذات معنى في كل فئة من هذه الفئات من المشاكل. تطبيقات blockchain الحديثة والفعالة مثل يمكن لعميل التماثل Ethereum [17] معالجة ما يزيد عن 3000 معاملة في الثانية عند التشغيل على أجهزة استهلاكية عالية الأداء. ومع ذلك، العالم الحقيقي الحالي تقتصر شبكات blockchain عمليًا على حوالي 30 شبكة المعاملات في الثانية الواحدة. ينشأ هذا القيد أساسًا من حقيقة أن آليات الإجماع المتزامن الحالية تتطلب هوامش توقيت واسعة من الأمان وقت المعالجة المتوقع، والذي يتفاقم بسبببولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 2 الرغبة في دعم عمليات التنفيذ الأبطأ. هذا يرجع إلى بنية التوافق الأساسية: آلية انتقال الدولة، أو الوسائل التي يتم من خلالها تجميع الأحزاب وتنفيذ المعاملات، له منطق مرتبط بشكل أساسي في آلية "التحديد الأساسي" المتفق عليها، أو الوسائل التي تتفق الأطراف من خلالها على واحد من عدد من ممكن، صحيح، التواريخ. ينطبق هذا بالتساوي على كل من أنظمة proof-of-work (PoW) مثل Bitcoin [15] و Ethereum [5,23] وأنظمة إثبات الحصة (PoS) مثل NXT [8] وBitshares [12]: جميعهم يعانون في النهاية من نفس الإعاقة. إنها بسيطة الإستراتيجية التي ساعدت في إنجاح blockchains. ومع ذلك، عن طريق ربط هاتين الآليتين بإحكام في وحدة واحدة من البروتوكول، نقوم أيضًا بتجميع العديد من العناصر المختلفة معًا الجهات الفاعلة والتطبيقات ذات ملفات تعريف المخاطر المختلفة ومتطلبات قابلية التوسع المختلفة واحتياجات الخصوصية المختلفة. حجم واحد لا يناسب الجميع. في كثير من الأحيان يكون الأمر كذلك في أ الرغبة في الحصول على جاذبية واسعة، تتبنى الشبكة درجة من المحافظة مما يؤدي إلى القاسم المشترك الأدنى يخدم القليل على النحو الأمثل ويؤدي في النهاية إلى الفشل في القدرة على الابتكار والأداء والتكيف، في بعض الأحيان بشكل كبير جدا. بعض الأنظمة مثل على سبيل المثال. Factom [21] أسقط آلية انتقال الحالة تمامًا. ومع ذلك، فإن الكثير من المنفعة التي نرغب فيها تتطلب القدرة على الانتقال إلى الحالة وفقا لآلة الدولة المشتركة. إسقاطه يحل مشكلة بديلة؛ ولا يوفر بديلاً الحل. لذلك يبدو من الواضح أن هناك اتجاهًا واحدًا معقولًا للاستكشاف كطريق إلى حوسبة لامركزية قابلة للتطوير النظام الأساسي هو فصل بنية الإجماع عن آلية انتقال الدولة وربما ليس من المستغرب أن هذه هي الإستراتيجية التي يتبناها Polkadot كحل لقابلية التوسع. 2.1. البروتوكول والتنفيذ والشبكة. مثل Bitcoin و Ethereum، Polkadot يشير في الوقت نفسه إلى بروتوكول الشبكة والبروتوكول الأساسي (المفترض حتى الآن) الشبكة العامة التي تقوم بتشغيل هذا البروتوكول. Polkadot يهدف إلى أن يكون مشروعًا حرًا ومفتوحًا، حيث تكون مواصفات البروتوكول خاضعة لترخيص المشاع الإبداعي و يتم وضع الكود تحت ترخيص FLOSS. المشروع هو تم تطويره بطريقة مفتوحة ويقبل المساهمات أينما كانت مفيدة. نظام RFCs، لا يختلف ستسمح مقترحات تحسين بايثون بوسيلة لـ التعاون علنًا في تغييرات البروتوكول وترقياته. تنفيذنا الأولي لبروتوكول Polkadot سيعرف باسم منصة التكافؤ Polkadot وسوف تضمين تنفيذ بروتوكول كامل مع واجهة برمجة التطبيقات (API). الارتباطات. مثل تطبيقات Parity blockchain الأخرى، تم تصميم PPP لتكون مجموعة تقنية blockchain ذات أغراض عامة، وليست مخصصة بشكل فريد لشبكة عامة ولا لـ عملية خاصة/كونسورتيوم. تطوره هكذا تم تمويل Far من قبل عدة أطراف بما في ذلك من خلال منحة من الحكومة البريطانية. مع ذلك، تصف هذه الورقة Polkadot ضمن سياق الشبكة العامة. الوظائف التي نتصورها في الشبكة العامة هي مجموعة شاملة من تلك المطلوبة في إعدادات بديلة (مثل القطاع الخاص و/أو الاتحاد). علاوة على ذلك، في هذا السياق، يمكن للنطاق الكامل لـ Polkadot أن يتم وصفها ومناقشتها بشكل أكثر وضوحًا. هذا يعني يجب أن يدرك القارئ أن بعض الآليات قد تفعل ذلك سيتم وصفها (على سبيل المثال، التشغيل البيني مع الشبكات العامة الأخرى) والتي لا تتعلق بشكل مباشر بـ Polkadot عند نشرها في مواقف غير عامة ("مسموح بها"). 2.2. العمل السابق. لقد تم اقتراح فصل الإجماع الأساسي عن عملية انتقال الدولة بشكل غير رسمي على انفراد لمدة عامين على الأقل - كان ماكس كاي من أنصار مثل هذه الإستراتيجية خلال الأيام الأولى من الثورة Ethereum. حل أكثر تعقيدًا وقابل للتطوير يُعرف باسم Chain ألياف، يعود تاريخه إلى يونيو 2014 وتم نشره لأول مرة لاحقًا في ذلك العام 1، قدمت الحجة لسلسلة ترحيل واحدة وسلاسل متعددة متجانسة توفر آلية تنفيذ شفافة بين السلاسل. تم دفع ثمن فك الترابط من خلال زمن استجابة المعاملة - المعاملات التي تتطلب تنسيق أجزاء متباينة من النظام سوف يستغرق وقتا أطول للمعالجة. Polkadot يأخذ الكثير من بنيته من ذلك ومن محادثات المتابعة معه مختلف الناس، على الرغم من أنها تختلف بشكل كبير في الكثير من تصميمها وأحكامها. في حين لا توجد أنظمة مماثلة لـ Polkadot في الواقع في الإنتاج، عدة أنظمة ذات أهمية معينة تم اقتراحها، على الرغم من قلة عددها في أي مستوى كبير من التفاصيل. هذه المقترحات يمكن أن تكونمقسمة إلى أنظمة مما يسقط أو يقلل من فكرة التماسك العالمي آلة الدولة، تلك التي تحاول توفير عالميًا آلة مفردة متماسكة من خلال شظايا متجانسة وتلك التي تستهدف عدم التجانس فقط. 2.2.1. أنظمة بدون دولة عالمية. Factom [21] هو نظام يوضح القانون الأساسي دون المطابقة الصلاحية، مما يسمح بشكل فعال بتأريخ البيانات. بسبب تجنب الدولة العالمية والصعوبات ومع التوسع الذي يجلبه هذا، يمكن اعتباره حلاً قابلاً للتطوير. ومع ذلك، كما ذكرنا سابقًا، المجموعة من المشاكل التي يحلها أصغر بشكل صارم وجوهري. يعد Tangle [18] أسلوبًا جديدًا لأنظمة الإجماع. فبدلاً من ترتيب المعاملات في كتل وتشكيل إجماع حول قائمة مرتبطة بشكل صارم لإعطاء ترتيب عالمي عالمي لتغييرات الحالة، فإنه يتخلى إلى حد كبير عن فكرة الترتيب شديد التنظيم وبدلاً من ذلك يدفع للحصول على رسم بياني حلقي موجه للمعاملات التابعة مع العناصر اللاحقة مما يساعد في تحديد العناصر السابقة من خلال الإشارة الصريحة. لإجراء تغييرات تعسفية في الحالة، هذا الرسم البياني للتبعية سيصبح سريعًا مستعصيًا على الحل، ولكن بالنسبة للطراز UTXO model2 الأبسط بكثير، يصبح هذا الأمر معقول جدا. لأن النظام متماسك بشكل فضفاض فقط والمعاملات مستقلة بشكل عام عن كل منها أخرى، يصبح قدر كبير من التوازي العالمي تماما طبيعي. إن استخدام النموذج UTXO له التأثير قصر Tangle على "عملة" نقل القيمة البحتة النظام بدلا من أي شيء أكثر عمومية أو قابلة للتوسيع. علاوة على ذلك، من دون التماسك العالمي الصعب، فإن التفاعل مع الأنظمة الأخرى - والذي يميل إلى الحاجة إلى المطلق درجة المعرفة بحالة النظام - تصبح غير عملية. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2مخرجات المعاملات غير المنفقة، النموذج الذي يستخدمه Bitcoin حيث تكون الحالة بشكل فعال مجموعة العناوين المرتبطة ببعض القيمة؛ تقوم المعاملات بجمع هذه العناوين وإصلاحها في مجموعة جديدة من العناوين التي يكون مجموعها مكافئًا
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 3 2.2.2. أنظمة السلسلة غير المتجانسة. السلاسل الجانبية [3] هي أ الإضافة المقترحة إلى بروتوكول Bitcoin والتي من شأنها أن تسمح بالتفاعل غير الموثوق به بين سلسلة Bitcoin الرئيسية وسلاسل جانبية إضافية. لا يوجد أي شرط لأي درجة التفاعل "الغني" بين السلاسل الجانبية: سيقتصر التفاعل على السماح بوجود السلاسل الجانبية أوصياء على أصول بعضهم البعض، ويؤثرون على المستوى المحلي المصطلحات - ربط ثنائي الاتجاه 3. الرؤية النهائية هي لإطار يمكن من خلاله توفير عملة Bitcoin وظائف إضافية، إذا كانت طرفية، من خلال ربطها إلى بعض السلاسل الأخرى التي تتمتع بانتقال حالة أكثر غرابة الأنظمة التي يسمح بها بروتوكول Bitcoin. وبهذا المعنى، تتناول السلاسل الجانبية قابلية التوسعة بدلاً من قابلية التوسع. في الواقع، لا يوجد أي نص أساسي على صحة السلاسل الجانبية؛ tokens من سلسلة واحدة (على سبيل المثال Bitcoin) يتم الاحتفاظ بها نيابة عن سلسلة جانبية ويتم تأمينها فقط من خلال قدرة السلسلة الجانبية على تحفيز القائمين بالتعدين على تحديد المعايير الأساسية التحولات صالحة. أمان شبكة Bitcoin لا يمكن بسهولة أن تنتقل للعمل نيابة عن الآخرين blockchains. علاوة على ذلك، بروتوكول لضمان Bitcoin يقوم القائمون بالتعدين بدمج منجمي (أي تكرار قوة تحديد المعايير الخاصة بهم على تلك الخاصة بالسلسلة الجانبية)، والأهم من ذلك، التحقق من صحة انتقالات السلسلة الجانبية خارج نطاق نطاق هذا الاقتراح. Cosmos [10] هو نظام متعدد السلاسل مقترح في على نفس المنوال مثل السلاسل الجانبية، مبادلة ناكاموتو PoW طريقة الإجماع لخوارزمية Tendermint لـ Jae Kwon. بشكل أساسي، فهو يصف سلاسل متعددة (تعمل في المناطق) تستخدم كل منها مثيلات فردية من Tendermint، جنبًا إلى جنب مع وسيلة للاتصال الخالي من الثقة عبر a سلسلة المحور الرئيسي. يقتصر هذا الاتصال بين السلاسل على نقل الأصول الرقمية ("على وجه التحديد حول tokens") بدلاً من المعلومات التعسفية، ومع ذلك فإن هذا الاتصال بين السلاسل لديه مسار عودة للبيانات، على سبيل المثال لإبلاغ المرسل بحالة النقل. مجموعات المدقق للسلاسل المخصصة، وعلى وجه الخصوص وسائل تحفيزهم، مثل السلاسل الجانبية، لم تعد موجودة باعتبارها مشكلة لم يتم حلها. الافتراض العام هو ذلك ستحتوي كل سلسلة مخصصة بحد ذاتها على token من القيمة التي يستخدم تضخمها لدفع ثمن validators. لا تزال في المراحل المبكرة فيما يتعلق بالتصميم، يفتقر الاقتراح في الوقت الحالي إلى تفاصيل شاملة حول الوسائل الاقتصادية لتحقيق ما هو قابل للتطوير اليقين بشأن الصلاحية العالمية. ومع ذلك، فإن التماسك الفضفاض المطلوب بين المناطق والمحور سوف يسمح بذلك لمزيد من المرونة على المعلمات المخصصة للمنطقة سلاسل مقارنة بنظام فرض أقوى التماسك. 2.2.3. كاسبر. حتى الآن لا توجد مراجعة شاملة أو مقارنة جانبية بين Casper [6] وPolkadot تم إجراؤها، على الرغم من أنه يمكن للمرء أن يقوم بعملية كاسحة إلى حد ما (وبالتالي غير دقيق) توصيف الاثنين. يعد Casper بمثابة إعادة تصور لكيفية خوارزمية إجماع PoS يمكن أن يعتمد على مراهنة المشاركين على أي شوكة سيصبح في النهاية قانونيًا. وقد تم إيلاء اهتمام كبير لضمان أن تكون قوية للتواصل الشوكات، حتى عندما تطول، وتتمتع بدرجة إضافية من قابلية التوسع أعلى النموذج الأساسي Ethereum. كما على هذا النحو، يميل كاسبر حتى الآن إلى أن يكون أكثر بكثير بروتوكول معقد من Polkadot وأسلافه، و أ انحراف كبير عن تنسيق blockchain الأساسي. ذلك لا يزال غير واضح بشأن كيفية تكرار كاسبر في المستقبل وكيف سيبدو إذا تم نشره أخيرًا. بينما يمثل كل من Casper و Polkadot بروتوكولات جديدة مثيرة للاهتمام، وإلى حد ما، تعزيزات لـ Ethereum، هناك اختلافات جوهرية بينهما الأهداف النهائية ومسارات النشر. كاسبر هو Ethereum تم تصميم المشروع الذي يتمحور حول المؤسسة في الأصل أن يكون تغييرًا في إثبات الحصة (PoS) للبروتوكول دون الرغبة في ذلك إنشاء blockchain قابل للتطوير بشكل أساسي. إنه أمر حاسم تم تصميمه ليكون بمثابة شوكة صلبة، بدلاً من أي شيء أكثر توسعية، وبالتالي سيكون جميع عملاء ومستخدمي Ethereum مطلوب للترقية أو البقاء على مفترق اعتماد غير مؤكد. على هذا النحو، يصبح النشر أكثر صعوبة إلى حد كبير كما هو متأصل في المشروع اللامركزي حيث يكون ضيقًا التنسيق ضروري. Polkadot يختلف بعدة طرق؛ أولا وقبل كل شيء، تم تصميم Polkadot ليكون قابلاً للتوسيع والتوسع بشكل كامل blockchain اختبار التطوير والنشر والتفاعل سرير. لقد تم تصميمه ليكون بمثابة حزام مقاوم للمستقبل إلى حد كبير استيعاب blockchain الجديدالتكنولوجيا عندما تصبح متاحة دون التنسيق اللامركزي المعقد أو الشوكات الصلبة. نحن نتصور بالفعل العديد من حالات الاستخدام مثل كسلاسل الكونسورتيوم المشفرة والسلاسل عالية التردد مع أوقات حظر منخفضة للغاية ومن غير الواقعي القيام بها أي إصدار مستقبلي من Ethereum متصور حاليًا. وأخيرًا، فإن الاقتران بينه وبين Ethereum كبير للغاية فضفاضة؛ ليس من الضروري اتخاذ أي إجراء من جانب Ethereum تمكين إعادة توجيه المعاملات غير الموثوقة بين الاثنين الشبكات. باختصار، بينما Casper/Ethereum 2.0 وPolkadot نشارك بعض أوجه التشابه العابرة التي نعتقد أنها هدفها النهائي مختلفة إلى حد كبير، وذلك بدلا من التنافس، من المرجح أن يتعايش البروتوكولان في النهاية تحت عنوان علاقة منفعة متبادلة في المستقبل المنظور.
介绍
区块链在包括“物联网”在内的多个领域展示了巨大的实用前景 （物联网）、财务、治理、身份管理、网络去中心化和资产跟踪。然而，尽管 技术承诺和宏大的言论，我们还没有看到 当前技术在现实世界中的重大部署。 我们认为，这归因于当前的五个关键失败 技术栈： 可扩展性：全球花费了多少资源 系统处理单笔交易的处理能力、带宽和存储以及多少 交易可以合理地处理 峰值条件？ 隔离性：能否满足多个人的不同需求 各方和应用程序是否可以在同一框架下达到近乎最佳的程度？ 可开发性：这些工具的工作效果如何？做 API 满足了开发人员的需求吗？有教育材料吗？那里有正确的集成吗？ 治理：网络能否保持灵活性 随着时间的推移而发展和适应？ 决策可以是 具有足够的包容性、合法性和 透明度，以提供有效的领导 去中心化系统？ 适用性：该技术本身是否真的能够满足迫切的需求？是否需要其他“中间件”来弥补差距 实际应用？ 在目前的工作中，我们的目标是解决前两个问题 问题：可扩展性和隔离性。也就是说，我们相信 Polkadot 框架可以为每一类问题提供有意义的改进。 现代、高效的 blockchain 实现，例如 Parity Ethereum 客户端 [17] 可以处理超过 在高性能消费类硬件上运行时每秒处理 3,000 个事务。 然而，目前的现实世界 blockchain 网络实际上仅限于 30 个左右 每秒交易数。 这种限制主要源于当前的同步共识机制需要广泛的时间安全裕度。 预期的处理时间，这会因Polkadot：异构多链框架的愿景 草案1 2 希望支持较慢的实现。这是由于 底层共识架构：状态转换机制，或者各方核对的方式 并执行交易，其逻辑从根本上联系在一起 进入共识“规范化”机制，或者 指各方就多项协议中的一项达成一致的方式 可能的、有效的、历史的。 这同样适用于 proof-of-work (PoW) 系统，例如 Bitcoin [15] 和 Ethereum [5,23] 以及股权证明 (PoS) 系统，例如 NXT [8] 和 Bitshares [12]： 所有人最终都会遭受同样的障碍。这是一个简单的 帮助 blockchain 取得成功的策略。然而， 通过将这两种机制紧密耦合成一个单元 协议中，我们还将多个不同的协议捆绑在一起 具有不同风险状况、不同可扩展性要求和不同隐私需求的参与者和应用程序。 一种尺寸并不适合所有情况。很多时候，情况是在一个 为了获得广泛的吸引力，网络采取了一定程度的保守主义，从而导致了最低公分母 只为少数人提供最佳服务，最终导致失败 有时表现在创新、执行和适应的能力上 戏剧性地如此。 一些系统，例如Factom [21] 完全放弃了状态转换机制。然而，大部分 我们想要的效用需要能够转换状态 根据共享状态机。丢掉就可以解决 一个替代问题；它没有提供替代方案 解决方案。 因此，似乎很清楚，一个合理的方向 探索可扩展的去中心化计算的途径 平台的目的是将共识架构与 状态转换机制。而且，也许并不奇怪，这就是 Polkadot 所采用的可扩展性解决方案的策略。 2.1.协议、实施和网络。喜欢 Bitcoin 和 Ethereum、Polkadot 同时指网络协议和（迄今为止假定的）主协议 运行该协议的公共网络。 Polkadot 旨在成为一个免费和开放的项目，协议规范采用知识共享许可，并且 代码被置于 FLOSS 许可证之下。该项目是 以开放的方式开发并接受贡献 无论它们在哪里有用。 RFC 系统，与 Python 增强提案将允许一种方法 就协议变更和升级进行公开合作。 我们最初实施 Polkadot 协议 将被称为 Parity Polkadot 平台，并将 包括完整的协议实现和 API 绑定。与其他 Parity blockchain 实现一样， PPP 被设计为通用的 blockchain 技术堆栈，既不是公共网络独有的，也不是 私人/财团运营。它的发展是这样的 Far 已由多方资助，包括通过 英国政府的拨款。 尽管如此，本文仍然描述了 Polkadot 公共网络的上下文。我们在公共网络中设想的功能是公共网络中所需功能的超集 替代（例如私人和/或联盟）设置。此外，在这种情况下，Polkadot 的完整范围可以 进行更清晰的描述和讨论。这确实意味着 读者应该意识到某些机制可能 与 Polkadot 不直接相关的描述（例如与其他公共网络的互操作） 在非公开（“许可”）情况下部署时。 2.2.以前的工作。已经非正式地提议将基本共识与状态转换脱钩 私下里至少有两年的时间——马克斯·凯伊 (Max Kaye) 在公司成立之初就是这种策略的支持者。 Ethereum。 一种更复杂的可扩展解决方案，称为“链” Fibers，可追溯到 2014 年 6 月，随后首次发布 那一年1，提出了使用单个中继链和多个同质链提供透明的链间执行机制的案例。 退相干是付费的 通过交易延迟——交易需要 系统不同部分的协调将 需要更长的时间来处理。 Polkadot 的大部分架构都来自于此以及后续对话 尽管它的设计和规定有很大不同，但它却适用于不同的人。 虽然没有可与 Polkadot 相媲美的系统 实际上在生产中，有一些相关的系统 已提出建议，尽管很少有实质性的建议 细节。这些建议可以是分解成系统 它放弃或减少了全球一致的概念 状态机，那些试图提供全局的 通过同质分片实现连贯的单例机器 以及仅针对异质性的那些。 2.2.1.没有全局状态的系统。 Factom [21] 是一个无需遵循规范即可证明规范性的系统 有效性，有效地允许记录数据。由于避免全局状态和困难 通过这带来的扩展，它可以被认为是一个可扩展的解决方案。然而，正如前面提到的，集合 它解决的问题数量严格来说要小得多。 Tangle [18] 是一种新颖的共识系统方法。 它不是将交易安排到区块中并就严格链接的列表达成共识以给出状态更改的全球规范排序，而是在很大程度上放弃了高度结构化排序的想法，而是 推动依赖事务的有向无环图，其中后面的项目有助于规范化早期的项目 通过显式引用。对于任意状态变化， 这个依赖图很快就会变得棘手， 然而对于更简单的 UTXO model2 这变成 相当合理。因为系统只是松散地连贯，并且事务通常彼此独立 另外，大量的全局并行性变得相当 自然的。 使用 UTXO 模型确实有效果 将 Tangle 限制为纯粹的价值转移“货币” 系统而不是任何更通用或可扩展的东西。 此外，如果没有硬性的全球一致性，与其他系统的交互——这往往需要绝对的 对系统状态的程度了解变得不切实际。 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2未花费的交易输出，Bitcoin 使用的模型，其中状态实际上是与某个值关联的地址集； 交易将这些地址进行整理，并将其重组为一组总和相等的新地址
Polkadot：异构多链框架的愿景 草案1 3 2.2.2.异构链系统。侧链 [3] 是 提议对 Bitcoin 协议进行补充，该协议将允许主 Bitcoin 链之间进行无需信任的交互 和额外的侧链。没有任何规定 侧链之间“丰富”相互作用的程度：相互作用将仅限于允许侧链 彼此资产的托管人，在当地发挥作用 行话——双向挂钩 3. 最终愿景是建立一个可以提供 Bitcoin 货币的框架 通过挂钩附加的（如果是外围的）功能 到其他一些具有更奇特状态转换的链上 Bitcoin 协议允许的系统。从这个意义上说， 侧链解决的是可扩展性而不是可扩展性。 事实上，侧链的有效性基本上没有规定；来自一条链的 tokens（例如 Bitcoin） 代表侧链持有的数据仅由 侧链激励矿工标准化的能力 有效的转换。 Bitcoin 网络的安全 不能轻易地转为代表其他人工作 blockchains。此外，还有一个用于确保 Bitcoin 的协议 矿工合并挖矿（即将其规范化能力复制到侧链上），更重要的是，验证侧链的转换是否在 本提案的范围。 Cosmos [10] 是提议的多链系统 与侧链相同，交换了 Nakamoto PoW Jae Kwon 的 Tendermint 算法的共识方法。 本质上，它描述了多个链（在 区域），每个区域都使用 Tendermint 的单独实例，以及通过 主轮毂链。这种链间通信仅限于数字资产的传输（“具体是关于tokens”）而不是任意信息，但是这种链间通信确实有数据的返回路径， 例如向发件人报告传输状态。 分区链的验证器集，特别是 激励他们的手段，就像侧链一样，被留下了 作为一个未解决的问题。一般假设是 每个分区链本身都会持有 token 的价值，其通货膨胀用于支付 validator 的费用。仍处于早期阶段 设计方面，目前该提案缺乏关于实现可扩展的经济手段的全面细节 全球有效性的确定性。然而，区域和中心之间所需的松散一致性将允许 为分区参数提供额外的灵活性 与执行力更强的系统相比，链条 连贯性。 2.2.3.卡斯帕。迄今为止，Casper [6] 和 Polkadot 之间尚未进行全面审查或并排比较 已经制定了，尽管人们可以做出相当全面的 （因此不准确）两者的表征。 Casper 重新构想了 PoS 共识算法 可以基于参与者对哪个分叉的投注 最终将成为规范。充分考虑确保其对网络的鲁棒性 分叉，即使延长，并且在基本 Ethereum 模型之上具有一定程度的可扩展性。作为 因此，Casper 迄今为止往往是一个更 比 Polkadot 及其祖先更复杂的协议，以及 与基本 blockchain 格式有很大偏差。它 Casper 未来将如何迭代仍不得而知 以及最终部署后会是什么样子。 虽然 Casper 和 Polkadot 都代表了有趣的新协议，并且在某种意义上，增强了 Ethereum，它们之间存在显着差异 最终目标和部署路径。 卡斯帕是一个 Ethereum 最初设计的以基金会为中心的项目 是对协议的 PoS 更改，但不希望 创建一个基本可扩展的 blockchain。关键的是，它是 设计为硬分叉，而不是任何更广泛的东西，因此所有 Ethereum 客户和用户都将 需要升级或保留在不确定采用的分叉上。因此，部署变得更加困难，这是分散式项目所固有的，在这种情况下， 协调是必要的。 Polkadot 在几个方面有所不同；首先也是最重要的， Polkadot 被设计为完全可扩展和可扩展的 blockchain 开发、部署和交互测试 床。它是一款基本上面向未来的安全带，能够 同化新的blockchain无需过于复杂的去中心化协调即可使用的技术 或硬分叉。我们已经设想了几个用例，例如 如加密联盟链和高频链 出块时间非常短，这是不现实的 当前设想的 Ethereum 的任何未来版本。最后，它和Ethereum之间的耦合度非常高 松动； Ethereum 无需采取任何行动 启用两者之间的去信任交易转发 网络。 简而言之，虽然 Casper/Ethereum 2.0 和 Polkadot 有一些短暂的相似之处，我们相信他们的最终目标 本质上是不同的，而不是竞争， 这两个协议最终可能会在一个协议下共存 在可预见的未来建立互惠互利的关系。
ملخص
Polkadot عبارة عن سلسلة متعددة غير متجانسة وقابلة للتطوير. هذا يعني أنه على عكس تطبيقات blockchain السابقة التي ركزت على توفير سلسلة واحدة متفاوتة درجات العمومية على التطبيقات المحتملة، Polkadot تم تصميمه في حد ذاته بحيث لا يوفر أي وظيفة تطبيق متأصلة على الإطلاق. بل إن Polkadot يوفر الأساس المتين "سلسلة الترحيل" التي يعتمد عليها عدد كبير من التحقق من الصحة، يمكن استضافة هياكل البيانات الديناميكية المتماسكة عالميًا جنبا إلى جنب. نحن نطلق على هياكل البيانات هذه اسم "المتوازية" السلاسل أو المظلات، على الرغم من عدم وجود حاجة محددة لها أن تكون blockchain بطبيعتها. بمعنى آخر، يمكن اعتبار Polkadot مكافئًا لمجموعة من السلاسل المستقلة (على سبيل المثال، المجموعة التي تحتوي على Ethereum، Ethereum Classic، Namecoin و Bitcoin) باستثناء نقطتين مهمتين للغاية: • الأمن المجمع. • إمكانية التعامل بين السلاسل دون ثقة. هذه النقاط هي سبب اعتبارنا Polkadot "قابلة للتطوير". من حيث المبدأ، قد تكون المشكلة التي سيتم نشرها على Polkadot متوازية إلى حد كبير - أو متدرجة - على مدى عدد كبير من المظلات. وبما أن جميع جوانب كل منهما يمكن إجراء سلسلة المظلة بالتوازي بواسطة جزء مختلف من شبكة Polkadot، يتمتع النظام ببعض القدرة على نطاق واسع. Polkadot يوفر قطعة مجردة إلى حد ما 3 على عكس الربط أحادي الاتجاه والذي هو في الأساس عملية تدمير tokens في سلسلة واحدة لإنشاء tokens في سلسلة أخرى بدون آلية لإجراء العكس من أجل استعادة tokens الأصليةبولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 4 البنية التحتية تترك الكثير من التعقيد ليتم معالجتها على مستوى البرمجيات الوسيطة. وهذا قرار واعي يهدف إلى الحد من مخاطر التنمية، وتمكين البرامج المطلوبة التي سيتم تطويرها خلال فترة زمنية قصيرة ومع مستوى جيد من الثقة في أمنها و المتانة. 3.1. فلسفة Polkadot. Polkadot ينبغي توفير أساس متين مطلق يمكن القيام به قم ببناء الموجة التالية من أنظمة الإجماع، حتى النهاية طيف المخاطر من التصاميم الناضجة القادرة على الإنتاج إلى الأفكار الناشئة. من خلال توفير ضمانات قوية بشأن الأمان والعزل والتواصل، يمكن أن يسمح Polkadot بذلك المظلات للاختيار من بين مجموعة من الخصائص بأنفسهم. في الواقع، نتوقع أن تقوم العديد من التجارب التجريبية بدفع خصائص ما يمكن اعتباره معقولًا اليوم. نرى المحافظين سلاسل ذات قيمة عالية مماثلة ل Bitcoin أو Z-cash [20] تتواجد جنبًا إلى جنب مع القيمة الأقل "سلاسل المواضيع" (مثل هذا التسويق، ممتع جدًا) وشبكات الاختبار مع رسوم صفر أو قريبة من الصفر. نرى مشفرة بالكامل، سلاسل الكونسورتيوم "المظلمة" تعمل جنبًا إلى جنب - وحتى تقديم الخدمات لسلاسل مفتوحة وفعالة للغاية مثل تلك مثل Ethereum. نرى تجريبية جديدة السلاسل المستندة إلى VM مثل الـWasm المشحون بالوقت يتم استخدام السلسلة كوسيلة لالاستعانة بمصادر خارجية لمشاكل الحوسبة الصعبة من سلسلة أكثر نضجًا تشبه Ethereum أو سلسلة تشبه Bitcoin أكثر تقييدًا. لإدارة ترقيات السلسلة، سيتم Polkadot بطبيعته دعم نوع ما من هيكل الإدارة، على الأرجح على الأنظمة السياسية المستقرة القائمة ولها جانب من مجلسين مماثل لمجلس الورقة الصفراء [24]. كما السلطة النهائية، سيكون لأصحاب token الأساسيين سيطرة "الاستفتاء". لتعكس المستخدمين الحاجة إلى التطوير ولكن حاجة المطورين إلى الشرعية، نتوقع أن يكون هناك اتجاه معقول للتشكيل الغرفتين من لجنة "المستخدمين" (المكونة من المستعبدين validators) وتشكيل لجنة "فنية". من مطوري العملاء الرئيسيين واللاعبين في النظام البيئي. ال ستحافظ هيئة حاملي token على الشرعية النهائية وتشكل أغلبية ساحقة لزيادة هذا الهيكل أو إعادة قياسه أو استبداله أو حله، وهو أمر نحن لا تشك في الحاجة النهائية إلى: على حد تعبير توين "يجب تغيير الحفاضات والحفاضات بشكل متكرر، ومن أجل ذلك نفس السبب". في حين أن إعادة تحديد المعايير عادة ما تكون تافهة للترتيب ضمن آلية إجماع أكبر، فإن المزيد من التغييرات النوعية مثل الاستبدال والزيادة من شأنها أن تكون مفيدة. من المحتمل أن تكون إما "مراسيم ناعمة" غير آلية (على سبيل المثال. من خلال تحديد رقم الكتلة و hash لوثيقة تحدد البروتوكول الجديد رسميًا) أو تستلزم آلية الإجماع الأساسية أن تحتوي على أ لغة غنية بما فيه الكفاية لوصف أي جانب من جوانب نفسها والتي قد تحتاج إلى التغيير. والأخير هو هدف نهائي، ومع ذلك، فمن المرجح أن يتم اختيار الأول من أجل ذلك تسهيل جدول زمني معقول للتنمية. مبادئ Polkadot الأساسية والقواعد التي يتم من خلالها نقوم بتقييم جميع قرارات التصميم هي: الحد الأدنى: Polkadot يجب أن يتمتع بأقل قدر ممكن من الوظائف. بسيط: لا ينبغي أن يكون هناك أي تعقيد إضافي في البروتوكول الأساسي مما يمكن أن يكون بشكل معقول تم تفريغها في البرامج الوسيطة، وضعت من خلال أ parachain أو تم تقديمه في تحسين لاحق. عام: لا يوجد شرط غير ضروري، القيد أو ينبغي وضع قيود على المظلات؛ يجب أن يكون Polkadot بمثابة اختبار لتطوير نظام الإجماع الذي يمكن تحسينه من خلاله جعل النموذج الذي تتناسب معه الامتدادات مجردًا قدر الإمكان. قوية: Polkadot يجب أن توفر بشكل أساسي طبقة أساسية مستقرة. وبالإضافة إلى السلامة الاقتصادية، فإن هذا يعني أيضًا تقليل المركزية ناقلات للهجمات ذات المكافأة العالية.
概括
Polkadot 是一个可扩展的异构多链。这个 意味着与之前的 blockchain 实现不同 其重点是提供不同的单一链 潜在应用的通用性程度，Polkadot 其本身根本不提供任何固有的应用程序功能。 相反，Polkadot 提供了基础 “中继链”上有大量可验证的、 可以托管全球一致的动态数据结构 并排。我们将这些数据结构称为“并行” 链或平行链，尽管没有特殊需要 它们本质上是blockchain。 换句话说， Polkadot 可以被认为等同于一组独立的链（例如包含 Ethereum、Ethereum Classic、Namecoin 和 Bitcoin），但有两点非常重要： • 集中安全； • 免信任的链间交易性。 这些点就是我们认为 Polkadot 是“可扩展的”的原因。原则上，要在 Polkadot 上部署的问题可以基本上并行化（横向扩展） 大量的平行链。由于各个方面 平行链可以由 Polkadot 网络的不同部分并行进行，系统具有一定的能力 规模化。 Polkadot 提供了一个相当简单的部分 3 与单向挂钩相反，单向挂钩本质上是销毁一条链中的 tokens 以在另一条链中创建 tokens 的操作，而无需 执行相反操作以恢复原始 tokens 的机制Polkadot：异构多链框架的愿景 草案1 4 基础设施使大部分复杂性需要在中间件级别解决。这是一个有意识的决定，旨在降低开发风险，使 需要在短时间内开发出必要的软件 并对其安全性和安全性充满信心 鲁棒性。 3.1. Polkadot 的哲学。 Polkadot 应该 提供绝对坚如磐石的基础 建立下一波共识系统，通过 可生产的成熟设计的风险范围 到新生的想法。通过提供安全、隔离和通信方面的强有力保证，Polkadot 可以允许 平行链可以从一系列属性本身中进行选择。 事实上，我们预见到各种实验性的 blockchain 会推动被认为合理的特性 今天。 我们看到保守派， 高价值链类似于 Bitcoin 或 Z-cash [20] 与较低价值共存 “主题链”（这样的营销，很有趣）和测试网 零或接近零费用。 我们看到完全加密的， “黑暗”的联盟链并肩运作，甚至 提供服务——功能强大的开放链 例如 Ethereum 之类的。我们看到实验性的新 基于虚拟机的链，例如主观计时的 wasm 链被用作从更成熟的 Ethereum 类链外包困难计算问题的手段 或更受限制的类似 Bitcoin 的链。 为了管理链升级，Polkadot 本质上将 支持某种治理结构，可能基于 现有稳定的政治制度，并具有类似于黄皮书理事会[24]的两院制。作为 作为最终权力，潜在的 token 持有者将拥有“公投”控制权。为了反映用户的 发展的需要，但开发商需要合法性，我们预计合理的方向是形成 来自“用户”委员会的两个议院（由 保税validators）和一个“技术”委员会组成 主要客户开发人员和生态系统参与者。 的 token 持有者的主体将保持最终的合法性，并形成绝对多数来扩大、重新参数化、替换或解散这个结构，我们 不要怀疑最终的需要：用吐温的话来说 “政府和尿布必须经常更换，并且为了 同样的理由”。 虽然重新参数化通常在更大的共识机制中安排起来很简单，但更多的质变（例如替换和增强）将 可能需要是非自动化的“软法令”（例如 通过块号的规范化和 正式指定新协议的文档的 hash） 或者需要核心共识机制来包含 足够丰富的语言来描述其自身的任何方面 这可能需要改变。后者是最终目标， 然而，前者更有可能被选择，以便 制定合理的开发时间表。 Polkadot 的主要原则和规则 我们评估所有设计决策是： 最小：Polkadot 应具有尽可能少的功能。 简单：不应出现额外的复杂性 在基本协议中比可以合理地 o加载到中间件中， 通过放置 平行链或在以后的优化中引入。 一般：没有不必要的要求、约束 或者应该对平行链进行限制； Polkadot 应该是共识系统开发的测试平台，可以通过以下方式进行优化： 使适合扩展的模型尽可能抽象。 稳健：Polkadot 应该提供一个基本的 稳定的基层。除了经济稳健之外，这还意味着去中心化以最大限度地减少 高回报攻击的向量。
المشاركة في Polkadot
هناك أربعة أدوار أساسية في صيانة Polkadot الشبكة: المتعاون والصياد والمرشح وvalidator. في أحد التطبيقات المحتملة لـ Polkadot، الدور الأخير يمكن تقسيمها فعليًا إلى دورين: validator الأساسي وضامن التوفر؛ تمت مناقشة هذا في القسم 6.5.3. جامع صياد المدققون (هذه المجموعة) المدققون (مجموعات أخرى) يوافق يصبح المراقبين التقارير سيئة السلوك ل يوفر كتلة المرشحين ل المرشح الشكل 1. التفاعل بين أربعة أدوار Polkadot. 4.1. المدققون. validator هو أعلى شحن و يساعد في إغلاق الكتل الجديدة على شبكة Polkadot. يتوقف دور validator على وجود رابطة عالية بما فيه الكفاية يتم إيداعها، على الرغم من أننا نسمح للأطراف المستعبدة الأخرى بذلك قم بترشيح واحد أو أكثر من validator لتمثيلهم وبصفتهم قد لا يكون هذا الجزء من سند validator مملوكًا بالضرورة لـ validator نفسه ولكن بالأحرى من قبل هؤلاء الترشيحات. يجب أن يقوم validator بتشغيل تطبيق عميل سلسلة الترحيل مع توفر عالي وعرض النطاق الترددي. عند كل كتلة يجب أن تكون العقدة جاهزة لقبول دور التصديق كتلة جديدة على المظلة المرشحة. هذه العملية يتضمن تلقي المرشح والتحقق من صحته وإعادة نشره كتل. إن الترشيح أمر حتمي ولكن لا يمكن التنبؤ به تقريبًا مقدمًا. نظرًا لأن validator لا يمكن ذلك ومن المتوقع بشكل معقول للحفاظ على متزامنة بالكامل قاعدة بيانات لجميع المظلات، من المتوقع أن يرشح validator مهمة ابتكار قاعدة بيانات جديدة مقترحة كتلة المظلة لطرف ثالث، والمعروفة باسم المجمع. بمجرد التصديق على جميع كتل المظلات الجديدة بشكل صحيح من خلال مجموعاتها الفرعية validator، validators يجب بعد ذلك التصديق على كتلة سلسلة التتابع نفسها. هذا ينطوي على تحديث حالة قوائم انتظار المعاملات (بشكل أساسي نقل البيانات من قائمة انتظار إخراج سلسلة Parachain إلى أخرى قائمة انتظار إدخال Parachain)، ومعالجة المعاملات مجموعة معاملات سلسلة الترحيل المعتمدة والتصديق على الكتلة النهائية، بما في ذلك تغييرات الباراشين النهائية.بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 5 validator لا يقومون بواجبهم في التوصل إلى توافق في الآراء بموجب قواعد خوارزمية الإجماع التي اخترناها يعاقب. بالنسبة لحالات الفشل الأولية غير المقصودة، يتم ذلك حجز مكافأة validator. يؤدي الفشل المتكرر إلى تقليل سندات الضمان الخاصة بهم (من خلال الحرق). من المحتمل أن تكون الإجراءات الضارة مثل التوقيع المزدوج أو التآمر لتقديم كتلة غير صالحة يؤدي إلى خسارة السند بأكمله (الذي يتم حرقه جزئيًا ولكن يتم تقديمه في الغالب إلى المخبرين والفاعلين الصادقين). إلى حد ما، validators تشبه مجمعات التعدين من إثبات العمل الحالي blockchains. 4.2. الترشيحات. المرشح هو طرف صاحب مصلحة الذي يساهم في السند الضماني لـ validator. هم ليس لها دور إضافي سوى وضع رأس المال المخاطر وكما للإشارة إلى أنهم يثقون في validator معين (أو مجموعة منها) للتصرف بمسؤولية في صيانتها شبكة. ويحصلون على زيادة أو تخفيض تناسبي في ودائعهم وفقا لنمو السند الذي يساهمون. جنبا إلى جنب مع المتعاونين، التالي، المرشحون في بعض يشبه عمال المناجم في شبكات إثبات العمل (PoW) الحالية. 4.3. المقارنات. جامعو المعاملات (جامعو المعاملات باختصار) هي الأطراف التي تساعد validators في إنتاج صالحة كتل المظلة. إنهم يحافظون على "عقدة كاملة" لسلسلة باراشين معينة؛ وهذا يعني أنهم يحتفظون بكل ما هو ضروري المعلومات لتكون قادرة على تأليف كتل جديدة وتنفيذها المعاملات بنفس الطريقة التي يقوم بها القائمون بالتعدين على إثبات العمل (PoW) blockchains الحالي. في الظروف العادية هم سوف نقوم بجمع وتنفيذ المعاملات لإنشاء ملف مفتوح كتلة، وتوفيرها، جنبا إلى جنب مع المعرفة الصفرية إثبات، إلى واحد أو أكثر من validator المسؤولين حاليًا عن اقتراح كتلة المظلة. من المرجح أن تتغير الطبيعة الدقيقة للعلاقة بين المتعاونين والمرشحين وvalidators بمرور الوقت الوقت. في البداية، نتوقع أن يعمل المترجمون بشكل وثيق جدًا مع validators، نظرًا لأنه لن يكون هناك سوى عدد قليل (ربما سلسلة (سلاسل) واحدة فقط ذات حجم معاملات صغير. ال سيتضمن التنفيذ الأولي للعميل RPCs للسماح بـ عقدة ربط سلسلة Parachain لتزويد عقدة (سلسلة ترحيل) validator بشكل غير مشروط بسلسلة Parachain صالحة بشكل مثبت كتلة. كتكلفة الحفاظ على نسخة متزامنة من كل هذه المظلات تتزايد، ونتوقع أن نرى المزيد البنية التحتية الموجودة والتي ستساعد في فصل واجبات الأطراف المستقلة ذات الدوافع الاقتصادية. في نهاية المطاف، نتوقع أن نرى مجموعات من المتعاونين الذين يتنافسون عليها جمع معظم رسوم المعاملات. قد يتم التعاقد مع هؤلاء المجمعين لخدمة validator معينة على مدى فترة زمنية مقابل حصة مستمرة في عائدات المكافأة. وبدلاً من ذلك، يمكن للمجمعين "المستقلين" ببساطة إنشاء ملف يقدم السوق كتل باراشين صالحة مقابل حصة تنافسية من المكافأة تدفع على الفور. وبالمثل، فإن مجمعات الترشيح اللامركزية ستسمح بالتعددية المشاركون المستعبدين للتنسيق وتقاسم واجب أ validator. تضمن هذه القدرة على التجميع المشاركة المفتوحة مما يؤدي إلى نظام أكثر لامركزية. 4.4. الصيادين. على عكس الحزبين النشطين الآخرين، لا يرتبط الصيادون مباشرة بتأليف الكتلة عملية. بل هم "صائدو جوائز" مستقلون بدافع من مكافأة كبيرة. على وجه التحديد بسبب بوجود الصيادين، نتوقع أن حوادث سوء السلوك نادرًا ما تحدث، وعندما تحدث فقط بسبب كون الطرف المستعبد مهملاً بأمن المفتاح السري، وليس من خلال النوايا الخبيثة. يأتي الاسم من التكرار المتوقع للمكافأة، والحد الأدنى من متطلبات المشاركة وحجم المكافأة النهائية. يحصل الصيادون على أجرهم من خلال إثبات ذلك في الوقت المناسب تصرف طرف مستعبد واحد على الأقل بشكل غير قانوني. أعمال غير قانونية تتضمن التوقيع على كتلتين مع نفس الوالد المعتمد، أو، في حالة المظلات، المساعدة في التصديق على غير صالح كتلة. لمنع الإفراط في المكافأة أو التسوية و الاستخدام غير المشروع للمفتاح السري للجلسة، المكافأة الأساسية مقابل تقديم رسالة واحدة موقعة بشكل غير قانوني من validator هو الحد الأدنى. وتزداد هذه المكافأة بشكل مقارب أكثر يتم إثبات التوقيعات غير القانونية من validators الأخرى بشرط أن يكون ذلك بمثابة هجوم حقيقي. تم تعيين الخط المقارب بنسبة 66% بعد تأكيدنا الأمني الأساسي على الأقل ثلثا validators يتصرفون بشكل خيري. يشبه الصيادون إلى حد ما "العقد الكاملة" في أنظمة blockchain الحالية التي تحتاج إلى الموارد صغيرة نسبيًا والالتزام بوقت تشغيل مستقر وعرض النطاق الترددي ليس ضروريا. ويختلف الصيادون في ذلك بقدر ما يجب عليهم نشر سند صغير.يمنع هذا السند هجمات sybil من إضاعة وقت وحساب validators الموارد. يمكن سحبه على الفور، ربما لا أكثر من ما يعادل بضعة دولارات وربما يؤدي لجني مكافأة ضخمة من اكتشاف سوء التصرف validator.
参与 Polkadot
Polkadot 的维护有四个基本角色 网络：整理者、渔夫、提名者和 validator。在 Polkadot 的一种可能实现，后一个角色 实际上可以分为两个角色：基本validator和可用性保证人；这将在一节中讨论 6.5.3. 校订者 渔夫 验证者 （本组） 验证者 （其他团体） 批准 变成 监视器 报告 坏 行为 提供块 候选人 为了 提名人 图 1. 之间的交互 Polkadot 的四个角色。 4.1.验证者。 validator 是最高费用， 帮助密封 Polkadot 网络上的新区块。 validator 的角色取决于足够高的债券 正在存入，尽管我们允许其他担保方 提名一名或多名 validator 代表他们行事并担任 validator 债券的此类部分不一定由 validator 本身拥有，而是由这些人拥有 提名者。 validator 必须运行具有高可用性和带宽的中继链客户端实现。在每个街区 节点必须准备好接受批准的角色 指定平行链上的新区块。 这个过程 涉及接收、验证和重新发布候选人 块。提名是确定性的，但实际上是无法提前预测的。由于 validator 不能 合理地期望保持完全同步 所有平行链的数据库，预计 validator 将提名设计一个建议的新的任务 平行链区块交给第三方，称为整理者。 一旦所有新的平行链区块都被指定的 validator 子组正确批准，validators 然后必须批准中继链区块本身。这涉及到 更新事务队列的状态（本质上是 将数据从平行链的输出队列移动到另一个 平行链的输入队列），处理交易 批准的中继链交易集并批准 最终区块，包括最终的平行链更改。Polkadot：异构多链框架的愿景 草案1 5 A validator 没有履行寻求共识的职责 根据我们选择的共识算法的规则受到惩罚。对于最初的、无意的失败，这是通过 扣留 validator 的奖励。反复失败会导致其安全保证金减少（通过销毁）。可证明的恶意行为，例如双重签名或 合谋提供无效区块导致损失 整个债券（部分被烧毁，但大部分被给予 告密者和诚实的行为者）。 从某种意义上来说，validator类似于矿池 当前 PoW blockchains。 4.2.提名人。提名人是股东 谁为 validator 的保证金出资。他们 除了投入风险资本外没有其他作用 这样表明他们信任特定的 validator （或 集）以负责任的方式维护 网络。 他们获得按比例增加或减少 根据债券的增长在存款中 他们做出了贡献。 接下来，提名者与整理者一起参与一些 感觉类似于当今 PoW 网络的矿工。 4.3.校勘者。交易整理者（简称整理者） 协助 validators 出示有效文件的各方是 平行链区块。他们为特定的平行链维护一个“全节点”；这意味着他们保留了所有必要的 能够创作新块并执行的信息 交易方式与矿工在当前 PoW blockchain 上的交易方式大致相同。正常情况下，他们 将整理并执行交易以创建未密封的 块，并与零知识一起提供它 证明，交给目前负责的一个或多个 validator 提出平行链区块。 整理者、提名者和 validator 之间关系的确切性质可能会发生变化 时间。最初，我们希望整理者能够非常密切地合作 与 validators，因为只有少数（也许 只有一个）交易量很小的平行链。的 初始客户端实现将包括 RPC，以允许 平行链整理节点无条件地向（中继链）validator 节点提供可证明有效的平行链 块。 由于维护同步版本的成本 所有此类平行链都会增加，我们预计会看到更多 基础设施到位，这将有助于分离 对独立的、有经济动机的各方的义务。 最终，我们期望看到收集者池相互竞争 收取最多的交易费用。此类整理者可能会签订合同，在一段时间内为特定的 validator 提供服务，以获得奖励收益的持续份额。 或者，“自由职业者”整理者可以简单地创建一个 市场提供有效的平行链区块，以换取立即支付的有竞争力的奖励份额。同样，去中心化的提名人池将允许多个 债券参与者协调并分担责任 validator。这种汇集能力确保了开放参与 导致更加去中心化的系统。 4.4.渔民。与另外两个活跃的政党不同， 渔民与区块创作没有直接关系 过程。相反，他们是独立的“赏金猎人” 受到巨大的一次性奖励的激励。 正是由于 由于渔民的存在，我们预计不当行为事件很少发生，而发生这种情况只是由于 担保方对密钥安全不重视， 而不是出于恶意。名字来了 从预期的奖励频率、参与的最低要求以及最终的奖励规模。 渔民通过及时证明来获得奖励 至少有一个担保方有非法行为。违法行为 包括签署两个区块，每个区块都具有相同的批准父级，或者在平行链的情况下，帮助批准无效的区块 块。为了防止过度奖励或妥协 非法使用会话的密钥，即基本奖励 提供单个 validator 的非法签名消息是 最小。随着更多的增加，这种奖励逐渐增加 证实其他 validator 的非法签名是 提供暗示真正的攻击。渐近线已设定 66% 遵循我们的基本安全主张，至少 三分之二的 validator 表现得仁慈。 渔民有点类似于“全节点” 当前的 blockchain 系统需要资源 相对较小并且承诺稳定的正常运行时间 并且不需要带宽。渔民们意见不一 就像他们必须缴纳一小笔保证金一样。这种结合可以防止 女巫攻击浪费 validators 的时间和计算 资源。可以立即撤回，可能不会 超过几美元，可能会导致 从发现不当行为中获得丰厚的回报 validator。
نظرة عامة على التصميم
يهدف هذا القسم إلى تقديم لمحة موجزة عن النظام ككل. استكشاف أكثر شمولا لل النظام موجود في القسم الذي يليه 5.1. إجماع. على سلسلة التتابع، Polkadot يحقق توافق منخفض المستوى حول مجموعة صالحة متفق عليها بشكل متبادل الكتل من خلال خوارزمية التسامح مع الأخطاء البيزنطية غير المتزامنة (BFT). سيتم إلهام الخوارزمية بواسطة Tendermint البسيط [11] وأكثر من ذلك بكثير المعنية HoneyBadgerBFT [14]. هذا الأخير يوفر إجماع فعال ومتسامح مع الأخطاء على نحو تعسفي بنية تحتية معيبة للشبكة، نظرًا لمجموعة من السلطات الحميدة في الغالب أو validators. بالنسبة لشبكة نمط إثبات السلطة (PoA)، هذا وحده سيكون كافيًا، ولكن من المفترض أن يكون Polkadot كذلك كما يمكن نشرها كشبكة مفتوحة بالكامل وعامة الوضع دون أي منظمة معينة أو موثوق بها السلطة اللازمة للحفاظ عليه. وعلى هذا النحو نحن بحاجة إلى وسائل تحديد مجموعة من validator والتحفيز لهم أن يكونوا صادقين. ولهذا نستخدم الاختيار القائم على إثبات الحصة (PoS). المعايير. 5.2. إثبات الحصة. نحن نفترض أن الشبكة سيكون لديه بعض الوسائل لقياس مقدار "الحصة" أي حساب معين لديه. لسهولة المقارنة الأنظمة الموجودة مسبقًا، سوف نسميها وحدة القياس "tokens". لسوء الحظ فإن المصطلح أقل من مثالي لـ أ لعدد من الأسباب، ليس أقلها كونها مجرد عددية القيمة المرتبطة بالحساب، لا توجد فكرة عنها الفردية. نحن نتخيل أن يتم انتخاب validator، بشكل غير متكرر (على الأكثر مرة واحدة يوميًا ولكن ربما نادرًا مثل مرة واحدة كل ربع سنة)، من خلال نظام إثبات الحصة المرشح (NPoS). يمكن أن يحدث التحفيز من خلال التخصيص التناسبي لـبولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 6 تتابع سلسلة سرب المدقق (كل لون حسب لونه المظلة المعينة) الصفقة (مقدم من ممثل خارجي) باراشين جسر المظلة الافتراضية (على سبيل المثال Ethereum) باراشين باراشين قوائم الانتظار والإدخال/الإخراج المعاملات المنتشرة منع تقديم المرشح الترتيب الثاني سلسلة التتابع مجتمع باراشين الحساب المعاملة الواردة المعاملة الصادرة المعاملات بين السلاسل (تتم إدارته بواسطة validators) جامع كتلة منتشرة صياد الشكل 2. ملخص تخطيطي لنظام Polkadot. يُظهر هذا أن المتعاونين يقومون بجمع ونشر معاملات المستخدم، بالإضافة إلى نشر مرشحي الكتلة للصيادين وvalidators. إنه أيضًا يوضح كيف يمكن للحساب نشر معاملة يتم تنفيذها من سلسلة Parachain الخاصة به، عبر سلسلة الترحيل ثم إلى سلسلة باراشين أخرى حيث يمكن تفسيرها على أنها معاملة لحساب هناك. الأموال القادمة من توسيع القاعدة token (حتى 100% سنويًا، على الرغم من أنه من المرجح أن يصل إلى حوالي 10٪) مع أي رسوم المعاملات التي تم جمعها. في حين أن توسع القاعدة النقدية يؤدي عادة إلى التضخم، حيث أن جميع مالكي token سيكون لديهم فرصة عادلة للمشاركة، فلن يحتاج أي مالك token إلى أن يعاني من انخفاض في قيمة أسهمه المقتنيات بمرور الوقت بشرط أن يكونوا سعداء بالحصول على دور في آلية التوافق. نسبة معينة من tokens سيتم استهدافها لعملية staking؛ ال سيتم تعديل توسيع القاعدة الفعال token من خلال آلية قائمة على السوق للوصول إلى هذا الهدف. يتم ربط المدققين بشكل كبير بحصصهم؛ الخروج تظل سندات validators سارية لفترة طويلة بعد توقف واجبات validators (ربما حوالي 3 أشهر). هذا طويل تسمح فترة تصفية السندات بحدوث سوء سلوك في المستقبل يعاقب حتى التفتيش الدوري للسلسلة. يؤدي سوء السلوك إلى العقوبة، مثل تقليل مكافأة أو، في الحالات التي تضر عمدا سلامة الشبكة، حيث يفقد validator بعضًا أو كلًا منها حصة validators أو المخبرين أو أصحاب المصلحة الآخرين ككل (من خلال الحرق). على سبيل المثال، validator الذي يحاول التصديق على فرعي الشوكة (أحيانًا المعروف باسم هجوم "قصير المدى") يمكن تحديده و يعاقب بالطريقة الأخيرة. يتم التحايل على هجمات "لا شيء على المحك" بعيدة المدى4 من خلال مزلاج "نقطة تفتيش" بسيط يمنع إعادة تنظيم سلسلة خطيرة لأكثر من عمق سلسلة معينة. لضمان مزامنة العملاء حديثًا لا يمكن أن ينخدعوا بالسلسلة الخاطئة، العادية سيحدث "الهارد فورك" (في نفس الفترة على الأكثر). تصفية سندات validators) التي تقوم بحظر نقطة تفتيش حديثة ذات كود ثابت hashes في العملاء. يلعب هذا بشكل جيد مع مقياس إضافي لتقليل البصمة وهو "طول السلسلة المحدودة" أو إعادة ضبط دورية لكتلة التكوين. 5.3. المظلات والمجمعات. يحصل كل مظلة معايير أمنية مماثلة لسلسلة الترحيل: ال يتم إغلاق رؤوس المظلات داخل كتلة سلسلة التتابع ضمان عدم إمكانية إعادة التنظيم أو "الإنفاق المزدوج" بعد التأكيد. يعد هذا ضمانًا أمنيًا مشابهًا لذلك الذي توفره السلاسل الجانبية والدمج لـ Bitcoin. ومع ذلك، فإن Polkadot يوفر أيضًا ضمانات قوية بأن انتقالات حالة المظلات صالحة. هذا يحدث من خلال مجموعة validators التي يتم تقسيمها بشكل عشوائي إلى مجموعات فرعية؛ مجموعة فرعية واحدة لكل Parachain، من المحتمل أن تختلف المجموعات الفرعية لكل كتلة. هذا يشير الإعداد عمومًا إلى أن أوقات حظر سلاسل المظلات ستفعل ذلك تكون على الأقل بنفس طول سلسلة التتابع. المحدد وسائل تحديد التقسيم خارج النطاق 4مثل هذا الهجوم هو حيث يقوم الخصم بصياغة سلسلة جديدة تمامًا من التاريخ بدءًا من كتلة التكوين وما بعده. من خلال التحكم أ حصة ضئيلة نسبيًا من الحصة في المقابل، فإنهم قادرون على زيادة حصتهم من الحصة بشكل تدريجي مقارنة بجميع الحصص الأخرى أصحاب المصلحة لأنهم المشاركون النشطون الوحيدون في تاريخهم البديل. نظرًا لعدم وجود قيود مادية جوهرية على الخلق من الكتل (على عكس إثبات العمل (PoW) حيث يجب إنفاق طاقة حسابية حقيقية تمامًا)، فإنهم قادرون على صياغة سلسلة أطول من السلسلة الحقيقية في فترة زمنية قصيرة نسبيًا وربما تجعلها الأطول والأفضل، وتتولى الحالة الأساسية للشبكة.بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 7 من هذه الوثيقة ولكن من المرجح أن تستند إما حولها إطار عمل كشف الالتزام مشابه لـ RanDAO [19] أو استخدم البيانات المجمعة من الكتل السابقة لكل سلسلة باراشين تحت hash آمن تشفيريًا. هذه المجموعات الفرعية من validators مطلوبة لتوفير أ مرشح كتلة الباراشين الذي يضمن صلاحيته (on ألم مصادرة السندات). الصلاحية تدور حول اثنين نقاط مهمة؛ أولاً أنه صحيح جوهريًا – ذلك تم تنفيذ جميع التحولات في الدولة بأمانة وهذا كل شيء البيانات الخارجية المشار إليها (أي المعاملات) صالحة للتضمين. ثانياً: أن أي بيانات خارجية عنه المرشح، مثل تلك المعاملات الخارجية، يتمتع بتوافر عالٍ بدرجة كافية حتى يتمكن المشاركون من ذلك قم بتنزيله وتنفيذ الكتلة يدويًا.5 قد يقدم المدققون كتلة "خالية" فقط لا تحتوي على بيانات "معاملات" خارجية، ولكنهم قد يتعرضون لخطر الحصول على مكافأة مخفضة إذا فعلوا ذلك. إنهم يعملون جنبا إلى جنب بروتوكول ثرثرة باراشين مع المتعاونين - الأفراد الذي يجمع المعاملات في كتل ويقدم دليلاً غير تفاعلي وصفر المعرفة على أن الكتلة تشكل فرعًا صالحًا لوالدها (ويأخذ أي معاملة رسوم على متاعبهم). يُترك الأمر لبروتوكولات Parachain لتحديد البروتوكولات الخاصة بها وسائل منع البريد العشوائي: لا توجد فكرة أساسية عن "قياس موارد الكمبيوتر" أو "رسوم المعاملات" التي تفرضها سلسلة التتابع. لا يوجد أيضًا تطبيق مباشر لهذا الأمر من خلال بروتوكول سلسلة الترحيل (على الرغم من أنه ومن غير المرجح أن يختار أصحاب المصلحة اعتمادها المظلة التي لم توفر آلية لائقة). هذه إشارة صريحة إلى إمكانية وجود سلاسل مختلفة Ethereum، على سبيل المثال. سلسلة تشبه Bitcoin ولها نموذج رسوم أبسط بكثير أو نموذج آخر لمنع البريد العشوائي لم يتم اقتراحه بعد. من المحتمل أن تكون سلسلة الترحيل الخاصة بـ Polkadot نفسها موجودة كـ Ethereum-حسابات شبيهة وسلسلة الحالة، من المحتمل أن تكون EVMمشتقة. نظرًا لأن عقد سلسلة التتابع ستكون مطلوبة القيام بمعالجة كبيرة أخرى، وإنتاجية المعاملات سيتم تقليلها جزئيًا من خلال رسوم المعاملات الكبيرة وإذا كانت نماذجنا البحثية تتطلب حدًا لحجم الكتلة. 5.4. الاتصالات بين السلاسل. العنصر الأخير الحاسم في Polkadot هو التواصل بين السلاسل. منذ يمكن أن تحتوي المظلات على نوع من قناة المعلومات فيما بينها، ونحن نسمح لأنفسنا بالنظر في Polkadot أ متعددة السلاسل قابلة للتطوير. في حالة Polkadot، يكون الاتصال بسيطًا قدر الإمكان: يتم تنفيذ المعاملات في المظلة (وفقًا لمنطق تلك السلسلة) قادرة على ذلك يؤثر على إرسال المعاملة إلى سلسلة Parachain ثانية أو ربما سلسلة التتابع. مثل المعاملات الخارجية في الإنتاج blockchains، فهي غير متزامنة تمامًا وليس هناك قدرة جوهرية لهم على العودة أي نوع من المعلومات يعود إلى أصله. الوجهة: يحصل البيانات من السابقة الكتلة validators. يتلقى الحساب منشورًا: تمت إزالة الإدخال من دخول Merkle tree يرسل الحساب منشورًا: تم وضع الإدخال في الخروج Merkle tree للوجهة المظلة الخروج المصدر: أسهم البيانات مع الكتلة التالية validators إثبات البريد المخزن في خروج المظلة ميركل شجرة تم وضع المرجع الموجه في باراتشين الوجهة دخول Merkle tree دخول الشكل 3. عرض تخطيطي أساسي الأجزاء الرئيسية من التوجيه لنشرها المعاملات ("المشاركات"). لضمان الحد الأدنى من تعقيد التنفيذ، الحد الأدنى خطر و الحد الأدنى سترات مستقيمة من المستقبل أبنية Parachain، هذه المعاملات بين السلاسل هي لا يمكن تمييزها بشكل فعال عن المعاملات القياسية الموقعة خارجيا. تحتوي المعاملة على جزء أصل، مما يوفر القدرة على تحديد سلسلة Parachain، و عنوان قد يكون ذو حجم تعسفي. على عكس الأنظمة الحالية الشائعة مثل Bitcoin وEthereum، لا تأتي المعاملات بين السلاسل مع أي نوع من "الدفع" للرسوم المرتبطة بها؛ ويجب إدارة أي دفع من هذا القبيل من خلال منطق التفاوض على سلاسل المصدر والوجهة. نظام مثل ذلك المقترح ل سيكون إصدار Serenity الخاص بـ Ethereum [7] وسيلة بسيطة لإدارة مثل هذا الدفع للموارد عبر السلسلة نحن نفترض أن الآخرين قد يبرزون إلى الواجهة في الوقت المناسب. يتم حل المعاملات Interchain باستخدام بسيطة آلية الانتظار تعتمد على Merkle tree لضمان ذلك الإخلاص. إنها مهمة مشرفي سلسلة التتابع نقل المعاملات في قائمة انتظار الإخراج لسلسلة باراشين واحدة في قائمة انتظار الإدخال لسلسلة المظلة الوجهة. ال تتم الإشارة إلى المعاملات التي تم تمريرها في سلسلة الترحيل، ولكنها ليست ذات صلةمعاملات ay-chain نفسها. لمنع سلسلة مظلة من إرسال رسائل غير مرغوب فيها إلى سلسلة مظلة أخرى المعاملات، ليتم إرسال المعاملة، هو مطلوب أن قائمة انتظار إدخال الوجهة ليست كبيرة جدًا وقت نهاية الكتلة السابقة. إذا كان الإدخال قائمة الانتظار كبيرة جدًا بعد معالجة الكتلة، وبالتالي تعتبر "مشبعة" ولا يمكن توجيه أي معاملات إليها ضمن الكتل اللاحقة حتى يتم تخفيضها مرة أخرى إلى ما دون الحد. تتم إدارة قوائم الانتظار هذه على سلسلة الترحيل السماح للمظلات بتحديد تشبع بعضها البعض الحالة؛ بهذه الطريقة محاولة فاشلة لنشر المعاملة إلى وجهة متوقفة قد يتم الإبلاغ عنها بشكل متزامن. (على الرغم من عدم وجود مسار إرجاع، إذا فشلت معاملة ثانوية لهذا السبب، فلا يمكن الإبلاغ عنها مرة أخرى للمتصل الأصلي وبعض وسائل الاسترداد الأخرى يجب أن يحدث.) 5.5. Polkadot و Ethereum. نظرًا لاكتمال تورينج Ethereum، نتوقع أن تكون هناك فرصة كبيرة لـ Polkadot وEthereum للتشغيل المتبادل مع بعضها البعض، على الأقل ضمن بعض الحدود الأمنية التي يمكن استنتاجها بسهولة. باختصار، نحن نتصور أن المعاملات من يمكن توقيع Polkadot بواسطة validators ثم إدخاله في 5قد تتم مشاركة مثل هذه المهمة بين validators أو يمكن أن تصبح المهمة المعينة لمجموعة من validators المرتبطة بشكل كبير والمعروفة باسم ضمانات التوفر.
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 8 Ethereum حيث يمكن تفسيرها وسنها عقد إعادة توجيه المعاملة. وفي الاتجاه الآخر، نتوقع استخدام السجلات (الأحداث) المنسقة خصيصًا القادمة من "عقد الاختراق" للسماح بالتحقق السريع من ضرورة إعادة توجيه رسالة معينة. 5.5.1. Polkadot إلى Ethereum. من خلال اختيار أ BFT آلية الإجماع مع validators المكونة من أ مجموعة من أصحاب المصلحة يتم تحديدهم من خلال التصويت بالموافقة آلية، نحن قادرون على الحصول على إجماع آمن مع عدد قليل ومتواضع من validators. في نظام يحتوي على إجمالي 144 validators، فإن وقت الكتلة يبلغ 4 ثوانٍ ونهاية 900 كتلة (مما يسمح بالبرامج الضارة سيتم الإبلاغ عن السلوكيات مثل الأصوات المزدوجة ومعاقبتها وإصلاحها)، يمكن أن تكون صلاحية الكتلة معقولة تعتبر مثبتة من خلال ما لا يقل عن 97 توقيعًا (ثلثي 144 زائد واحد) وفترة تحقق تالية مدتها 60 دقيقة حيث لا يتم إيداع أي اعتراضات. Ethereum قادر على استضافة "عقد اقتحام" والذي ويمكن الحفاظ على الموقعين الـ 144 والسيطرة عليهم لهم. نظرًا لأن استرداد التوقيع الرقمي للمنحنى الإهليلجي (ECDSA) لا يتطلب سوى 3000 غاز تحت EVM، ومنذ ذلك الحين من المحتمل أننا نريد فقط أن يتم التحقق من الصحة على الأغلبية العظمى من validators (بدلاً من الإجماع الكامل)، التكلفة الأساسية لـ Ethereum لتأكيد تلك التعليمات تم التحقق من صحتها بشكل صحيح حيث أن القادمة من شبكة Polkadot لن تزيد عن 300000 غاز - أي 6% فقط من الحد الإجمالي للغاز عند 5.5 م. زيادة عدد validators (كما هو ضروري للتعامل معها العشرات من السلاسل) يزيد حتما من هذه التكلفة من المتوقع على نطاق واسع أن ينمو النطاق الترددي لمعاملات Ethereum بمرور الوقت مع نضوج التكنولوجيا و تتحسن البنية التحتية. جنبا إلى جنب مع حقيقة أن لا يجب مشاركة جميع validators (على سبيل المثال، الأعلى فقط قد يتم استدعاء validators المثبت لمثل هذه المهمة). وتمتد حدود هذه الآلية بشكل جيد إلى حد معقول. بافتراض التناوب اليومي لمثل هذه validators (وهو متحفظ إلى حد ما - أسبوعيًا أو حتى شهريًا قد يكون مقبولاً)، ثم التكلفة التي تتحملها الشبكة للصيانة سيكون هذا الجسر Ethereum-إعادة التوجيه حوالي 540.000 الغاز يوميًا أو، بأسعار الغاز الحالية، 45 دولارًا سنويًا. ستتكلف المعاملة الأساسية التي يتم إرسالها بمفردها عبر الجسر حوالي 0.11 دولار؛ سيكلف حساب العقد الإضافي أكثر، بطبيعة الحال. عن طريق التخزين المؤقت وتجميع المعاملات معا، يمكن بسهولة أن تكون تكاليف ترخيص الاقتحام المشتركة، مما يقلل تكلفة المعاملة بشكل كبير؛ إذا كانت هناك حاجة إلى 20 معاملة قبل إعادة التوجيه، إذن ستنخفض تكلفة إعادة توجيه المعاملة الأساسية إلى حوالي 0.01 دولار. أحد البدائل المثيرة للاهتمام والأرخص لنموذج العقد متعدد التوقيع هو استخدام توقيعات العتبة من أجل تحقيق دلالات الملكية متعددة الأطراف. بينما مخططات توقيع العتبة لـ ECDSA باهظة الثمن من الناحية الحسابية، كتلك الخاصة بالمخططات الأخرى مثل توقيعات شنور معقولة جدًا. Ethereum تخطط لإدخال البدائيين التي من شأنها أن تفعل ذلك مخططات رخيصة للاستخدام في شوكة متروبوليس الصلبة القادمة. إذا كان من الممكن استخدام مثل هذه الوسيلة، فستكون تكلفة الغاز لإعادة توجيه معاملة Polkadot إلى Ethereum سيتم تخفيض الشبكة بشكل كبير إلى ما يقرب من الصفر النفقات العامة بالإضافة إلى التكاليف الأساسية للتحقق من صحة التوقيع وتنفيذ المعاملة الأساسية. في هذا النموذج، سيكون لعقد Polkadot validator لفعل القليل بخلاف توقيع الرسائل. لتوجيه المعاملات فعليًا إلى شبكة Ethereum، نحن افترض أن أيًا من validators نفسها ستتواجد أيضًا شبكة Ethereum أو على الأرجح تلك المكافآت الصغيرة يتم عرضه على الممثل الأول الذي يقوم بإعادة توجيه الرسالة إلى الشبكة (يمكن دفع المكافأة بشكل تافه إلى منشئ المعاملة). 5.5.2. Ethereum إلى Polkadot. الحصول على المعاملات لتكون تستخدم إعادة التوجيه من Ethereum إلى Polkadot المفهوم البسيط للسجلات. عندما يرغب عقد Ethereum في إرسال معاملة إلى سلسلة معينة من Polkadot، إنها تحتاج ببساطة إلى إبرام "عقد انفصال" خاص. سيتطلب عقد الاختراق أي دفعة قد تكون تكون مطلوبة وإصدار تعليمات التسجيل بحيث يمكن إثبات وجودها من خلال إثبات Merkle والتأكيد على أن رأس الكتلة المقابلة صالح و الكنسي. ومن بين الشرطين الأخيرين، ربما تكون الصلاحية هي الأكثر وضوحا لإثبات. من حيث المبدأ، فإن الشرط الوحيد هولكل عقدة Polkadot تحتاج إلى الإثبات (أي العقد validator المعينة) لتشغيل نسخة متزامنة بالكامل من عقدة Ethereum القياسية. لسوء الحظ، هذا في حد ذاته تبعية ثقيلة إلى حد ما. أكثر ستكون الطريقة خفيفة الوزن هي استخدام دليل بسيط على أن تم تقييم الرأس بشكل صحيح من خلال توفير فقط يلزم تنفيذ جزء من محاولة حالة Ethereum بشكل صحيح المعاملات في الكتلة والتحقق من صحة السجلات (الواردة في إيصال الكتلة). مثل هذه "الشبيهة بـ SPV"6 قد تتطلب البراهين قدرًا كبيرًا من المعلومات؛ بشكل ملائم، لن تكون هناك حاجة إليها عادةً الكل: نظام السندات داخل Polkadot سيسمح بالارتباط أطراف ثالثة لتقديم رؤوس مع خطر فقدانها يجب أن يقدم طرف ثالث آخر (مثل "الصياد"، انظر 6.2.3) دليلاً على أن الرأس غير صالح (على وجه التحديد أن جذر الحالة أو جذور الاستلام كانوا محتالين). على شبكة إثبات العمل (PoW) غير النهائية مثل Ethereum، فإن من المستحيل إثبات الشرعية بشكل قاطع. ولمعالجة ذلك، يجب على التطبيقات التي تحاول الاعتماد على أي نوع من السبب المعتمد على السلسلة انتظر عددًا من "التأكيدات"، أو حتى تصل المعاملة التابعة إلى مرحلة ما. عمق خاص داخل السلسلة. على Ethereum، هذا يتراوح العمق من كتلة واحدة للمعاملات الأقل قيمة مع عدم وجود مشكلات معروفة في الشبكة إلى 1200 كتلة كما كان القضية أثناء إصدار Frontier الأولي للتبادلات. على شبكة "Homestead" المستقرة، يقع هذا الرقم عند 120 قطعة لمعظم البورصات، ومن المحتمل أن نتقبلها معلمة مماثلة. هكذا نحن يمكن تخيل لدينا Polkadot-الجانب Ethereumواجهة تحتوي على بعض الوظائف البسيطة: لتكون قادرًا على ذلك قبول رأس جديد من شبكة Ethereum والتحقق من صحة إثبات العمل، لتتمكن من قبول بعض الأدلة على أن تم إصدار سجل معين بواسطة عقد الاختراق من الجانب Ethereum لرأس ذو عمق كافٍ (وإلى الأمام الرسالة المقابلة داخل Polkadot) وأخيرًا لتكون قادرة على قبول البراهين التي سبق قبولها ولكن يحتوي الرأس الذي لم يتم تفعيله بعد على جذر إيصال غير صالح. للحصول فعليًا على بيانات الرأس Ethereum نفسها (و أي أدلة SPV أو تفنيد الصلاحية/القانونية) إلى شبكة Polkadot، تحفيز لإعادة التوجيه يشير 6SPV إلى التحقق المبسط من الدفع في Bitcoin ويصف طريقة للعملاء للتحقق من المعاملات مع الاحتفاظ فقط نسخة من جميع رؤوس الكتل لأطول سلسلة إثبات العمل (PoW).بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 9 هناك حاجة إلى البيانات. يمكن أن يكون هذا بسيطًا مثل الدفع (ممولة من الرسوم المحصلة من جهة Ethereum) المدفوعة لأي شخص قادر على إعادة توجيه كتلة مفيدة رأسها صالح. وسيُطلب من المدققين الاحتفاظ بالمعلومات المتعلقة بالآلاف القليلة الأخيرة من الكتل من أجل تكون قادرًا على إدارة الانقسامات، إما من خلال بعض الوسائل الجوهرية للبروتوكول أو من خلال عقد يتم الاحتفاظ به على سلسلة التتابع. 5.6. Polkadot و Bitcoin. Bitcoin التشغيل البيني يمثل تحديًا مثيرًا للاهتمام لـ Polkadot: ما يسمى ومن شأن "الربط المتبادل" أن يشكل جزءاً مفيداً من البنية الأساسية ليكون على جانب كلا الشبكتين. ومع ذلك، بسبب قيود Bitcoin، مع توفير مثل هذا الربط بشكل آمن مشروع غير تافه. تسليم المعاملة من يمكن من حيث المبدأ إجراء Bitcoin إلى Polkadot بعملية مشابهة لتلك الخاصة بـ Ethereum؛ "عنوان الانفصال" يمكن التحكم فيه بطريقة ما بواسطة Polkadot validators تلقي tokens المنقولة (والبيانات المرسلة بجانبها). يمكن تقديم أدلة SPV عن طريق oracles و، جنبًا إلى جنب مع فترة التأكيد، والمكافأة الممنوحة مقابل ذلك تحديد الكتل غير القانونية التي تنطوي على المعاملة لقد تم "الإنفاق المزدوج". أي tokens مملوكة بعد ذلك في سيتم بعد ذلك، من حيث المبدأ، التحكم في "عنوان الاختراق" بواسطة نفس validator لتوزيعه لاحقًا. لكن المشكلة تكمن في كيفية التحكم بشكل آمن في الودائع من خلال مجموعة دوارة validator. على عكس Ethereum والتي يمكنها اتخاذ قرارات تعسفية بناء على ذلك بناء على مجموعات من التوقيعات، Bitcoin هو إلى حد كبير أكثر محدودية، حيث يقبل معظم العملاء فقط المعاملات متعددة التوقيع بحد أقصى 3 أطراف. وتوسيع هذا العدد إلى 36، أو في الواقع الآلاف كما هو مطلوب في نهاية المطاف، أمر مستحيل بموجب البروتوكول الحالي. أحد الخيارات هو تغيير بروتوكول Bitcoin للتمكين مثل هذه الوظيفة، ولكن ما يسمى بـ "الهارد فورك" في Bitcoin من الصعب ترتيب العالم بناءً على المحاولات الأخيرة. أحد الاحتمالات هو استخدام توقيعات العتبة، مخططات التشفير للسماح لجمهور محدد الهوية المفتاح ليتم التحكم فيه بشكل فعال من خلال "أجزاء" سرية متعددة، يجب استخدام بعضها أو جميعها لإنشاء توقيع صالح. لسوء الحظ، عتبة التوقيعات متوافقة مع Bitcoin's ECDSA باهظة الثمن من الناحية الحسابية إنشاء والتعقيد متعدد الحدود. مخططات أخرى من هذا القبيل توفر توقيعات شنور تكاليف أقل بكثير، إلا أن الجدول الزمني الذي يمكن تقديمهم فيه إلى Bitcoin البروتوكول غير مؤكد. منذ الأمن النهائي للودائع تقع على عاتق عدد من validators المستعبدين، هناك خيار آخر هو تقليل حاملي المفاتيح متعددي التوقيعات إلى عدد كبير فقط مجموعة فرعية مستعبدة من إجمالي validators مثل تلك العتبة تصبح التوقيعات ممكنة (أو، في أسوأ الأحوال، موطن Bitcoin الأصلي التوقيع المتعدد ممكن). وهذا بالطبع يقلل من المبلغ الإجمالي للسندات التي يمكن خصمها كتعويضات في حالة تصرف validator بشكل غير قانوني، ولكن هذا هو تدهور رشيق، ببساطة وضع حد أعلى ل مقدار الأموال التي يمكن تشغيلها بشكل آمن بين شبكتان (أو في الواقع، على نسبة الخسائر في حالة حدوث هجوم من validators تنجح). على هذا النحو، نعتقد أنه ليس من غير الواقعي وضع Bitcoin قابلية التشغيل البيني "سلسلة مظلات افتراضية" آمنة بشكل معقول بين الشبكتين، على الرغم من أنه جهد كبير بجدول زمني غير مؤكد، ومن المحتمل جدًا مما يتطلب تعاون الجهات المعنية في ذلك شبكة.
设计概述
本节旨在简要概述 系统作为一个整体。更彻底的探索 系统在后面的部分中给出。 5.1.共识。在中继链上，Polkadot实现了 就一组共同商定的有效规则达成低级别共识 通过现代异步拜占庭容错 (BFT) 算法进行阻止。算法将受到启发 通过简单的 Tendermint [11] 和更多 涉及蜜獾BFT [14]。后者提供了一个 对任意的问题达成有效且容错的共识 有缺陷的网络基础设施，给定一组大多良性的权威或 validators。 对于权威证明（PoA）风格的网络来说，仅此一点 就足够了，但是 Polkadot 被认为是 也可以作为完全开放和公共的网络进行部署 没有任何特定组织或信任的情况 维护它所需的权限。 因此我们需要一个 确定一组 validator 并进行激励的方法 他们说实话。为此，我们利用基于 PoS 的选择 标准。 5.2.证明赌注。我们假设网络 将有一些方法来衡量“赌注”的程度 任何特定帐户都有。 为了便于比较 预先存在的系统，我们称之为测量单位 “tokens”。不幸的是，这个词对于 有很多原因，尤其是简单的标量 与账户相关的价值，没有概念 个性。 我们想象 validator 很少被选举（最多 每天一次，但可能少至每季度一次）， 通过指定股权证明（NPoS）计划。激励可以通过按比例分配来实现Polkadot：异构多链框架的愿景 草案1 6 继电器 链条 验证者群体 （每个颜色由其 指定平行链） 交易 （提交者： 外部演员） 平行链 桥 虚拟平行链 （例如 Ethereum） 平行链 平行链 队列和 I/O 传播交易 阻止候选人提交 二阶 中继链 平行链社区 账户 入境交易 出境交易 链间交易 （由 validators 管理） 校订者 传播块 渔夫 图 2. Polkadot 系统的概要示意图。这显示了整理者收集和传播用户交易，以及向渔民和 validator 传播候选区块。它还 显示账户如何通过中继链发布在其平行链中执行的交易 然后进入另一个平行链，可以将其解释为那里账户的交易。 来自 token 基地扩张的资金（最多 100% 每年，尽管更有可能在 10% 左右）以及 收取的任何交易费用。虽然基础货币扩张通常会导致通货膨胀，但由于所有 token 所有者 将有公平的参与机会，任何token持有者都不需要遭受其价值的减少 随着时间的推移，只要他们乐意接受 在共识机制中的作用。特定比例 token 的目标将是 staking 进程；的 有效的 token 碱基扩展将通过以下方式进行调整 以市场为基础的机制来实现这一目标。 验证者的权益与他们紧密相连；退出 在 validator 的职责终止后很长一段时间（可能大约 3 个月），validator 的债券仍然有效。这么长 债券清算期允许未来的不当行为 受到惩罚，直到链的定期检查点为止。 不当行为会导致惩罚，例如减少 奖励，或者在故意损害的情况下 网络的完整性，validator 失去部分或全部 向其他validator、线人或利益相关者提供股份 作为一个整体（通过燃烧）。例如，validator 谁试图批准分叉的两个分支（有时 被称为“短程”攻击）可以被识别并且 按后一种方式处罚。 远程“无利害关系”攻击4可以通过一个简单的“检查点”闩锁来规避，该闩锁可以防止超过一个的危险链重组。 特定的链深度。 确保新同步的客户端 不能被骗到错误的链上，常规的 “硬分叉”将会发生（最多在同一时期） validators 的债券清算）将最近的检查点块 hashes 硬编码到客户端中。这与进一步减少足迹的“有限链长”措施或 创世块的定期重置。 5.3.平行链和收集者。每个平行链都会获得 与中继链类似的安全功能： 的 平行链的标头被密封在中继链区块内 确保确认后不可能进行重组或“双重支出”。这与 Bitcoin 的侧链和合并挖矿提供的安全保证类似。然而，Polkadot 也提供了平行链状态转换有效的有力保证。这个 通过将 validator 集合以加密方式随机分割成子集而发生；每一个子集 平行链，每个块的子集可能不同。这个 设置通常意味着平行链的区块时间将 至少与中继链一样长。具体的 确定分区的方法超出了范围 4这种攻击是对手从创世区块开始打造一条全新的历史链的地方。通过控制一个 尽管他们的股权比例相对较小，但他们能够相对于所有其他人逐步增加自己的股权比例 利益相关者，因为他们是另类历史中唯一的积极参与者。由于创作不存在内在的物理限制 区块（与必须花费相当真实的计算能量的 PoW 不同），他们能够在 相对较短的时间跨度，并有可能使其成为最长和最好的，接管网络的规范状态。Polkadot：异构多链框架的愿景 草案1 7 本文件的但可能基于 类似于 RanDAO [19] 的提交-显示框架或 使用每个平行链的先前区块组合的数据 在加密安全的 hash 下。 validator 的此类子集需要提供 保证有效的平行链候选区块（在 债券被没收的痛苦）。有效性围绕两个 要点；首先，它本质上是有效的—— 所有状态转换均忠实执行，并且所有 引用的外部数据（即交易）对于包含有效。其次，任何与其无关的数据 候选者，例如那些外部交易，具有足够高的可用性，以便参与者能够 下载它并手动执行该块。5 验证者可能只提供一个不包含外部“交易”数据的“空”块，但如果这样做，可能会面临奖励减少的风险。他们并肩工作 与收集者（个人）的平行链八卦协议 他们将交易整理成区块，并提供非交互式、零知识证明，证明该区块构成其父区块的有效子区块（并采取任何交易） 为他们的麻烦付费）。 由平行链协议来指定自己的 预防垃圾邮件的手段：没有“计算资源计量”或“交易费用”的基本概念 由中继链强加。中继链协议也没有对此进行直接强制执行（尽管它 利益相关者不太可能选择采用 一条没有提供像样机制的平行链）。 这是对链条可能性的明确认可，与链条不同 Ethereum，例如类似 Bitcoin 的链，具有更简单的费用模型或其他一些尚未提出的垃圾邮件预防模型。 Polkadot 的中继链本身可能会作为一个 类似 Ethereum 的账户和状态链，可能是 EVM 的衍生品。由于中继链节点需要 进行大量其他处理、事务吞吐量 将通过巨额交易费用部分最小化 并且，如果我们的研究模型需要区块大小限制。 5.4.链间通信。 Polkadot 的最后一个关键要素是链间通信。自从 平行链之间可以有某种信息通道，我们允许自己考虑 Polkadot a 可扩展的多链。在 Polkadot 的情况下，通信非常简单：在 平行链（根据该链的逻辑）能够 影响将交易分派到第二条平行链中 或者，可能是中继链。就像外部交易一样 在生产 blockchains 上，它们是完全异步的 他们没有内在能力返回任何 某种信息回到其起源。 目的地：获取 之前的数据 块的 validators。 帐户收到邮件： 条目已删除自 入口 Merkle tree 帐户发送帖子： 条目放置在 出口 Merkle tree 目的地 平行链 出口 来源：股票 下一个块的数据 validators 邮寄证明存储在 平行链出口 Merkle 树 已放置路由参考 在目的地平行链中 入口 Merkle tree 入口 图 3. 基本示意图 发布路由的主要部分 交易（“帖子”）。 为了确保最小的实现复杂性，最小 风险 和 最小的 直夹克 的 未来 平行链架构中，这些链间交易是 与标准的外部签名交易实际上没有区别。 该交易有一个原始段，提供识别平行链的能力，并且 可以是任意大小的地址。与 Bitcoin 和 Ethereum 等常见的当前系统不同，链间交易不附带任何类型的相关费用“支付”；任何此类支付都必须通过源平行链和目标平行链上的协商逻辑进行管理。诸如提议的系统 Ethereum 的 Serenity 版本 [7] 将是一个简单的方法 管理这样的跨链资源支付，但是 我们假设其他人可能会在适当的时候脱颖而出。 链间交易通过简单的方式解决 基于 Merkle tree 的排队机制以确保 保真度。中继链维护者的任务是 将交易移动到一个平行链的输出队列上 进入目标平行链的输入队列。的 传递的交易在中继链上被引用，但不是相关的y-chain 交易本身。为了防止平行链向另一个平行链发送垃圾邮件 交易，对于要发送的交易，需要 目的地的输入队列不要太大 前一个块的结束时间。如果输入 块处理后队列太大，那么它被认为是“饱和”并且没有事务可以路由到 它在后续块中，直到降回低于 限制。这些队列在中继链上进行管理 允许平行链确定彼此的饱和度 状态；这样尝试发布交易失败 可以同步报告到停止的目的地。 （尽管由于不存在返回路径，如果辅助交易因此失败，则无法报告回来 发送给原始调用者以及其他一些恢复方式 必须发生。） 5.5. Polkadot 和 Ethereum。由于 Ethereum 的图灵完备性，我们预计 Polkadot 和 Ethereum 有足够的机会与 彼此，至少在一些容易推断的安全范围内。简而言之，我们预计交易来自 Polkadot 可以由 validators 签名，然后送入 5这样的任务可能在 validator 之间共享，或者可能成为一组紧密结合的 validator 的指定任务，称为 可用性保证人。
Polkadot：异构多链框架的愿景 草案1 8 Ethereum 可以由以下人员解释和制定 交易转发合约。在另一个方向上， 我们预计会使用特殊格式的日志（事件） 来自“突破合同”，以允许快速验证是否应转发特定消息。 5.5.1. Polkadot 至 Ethereum。通过选择一个 BFT 共识机制由 validator 组成 通过批准投票确定的一组利益相关者 机制，我们能够与 validator 的变化不频繁且数量适中。 在总共 144 validators 的系统中，出块时间为 4 秒和 900 个区块的最终结果（允许恶意 双重投票等行为须举报、处罚 并修复），块的有效性可以合理地表示 仅需 97 个签名（144 个签名的三分之二加 1）以及随后 60 分钟的验证期（不存在任何质疑）即可被视为已得到验证。 Ethereum 能够主持一份“闯入合同” 可以维持144个签署者并由其控制 他们。由于椭圆曲线数字签名 (ECDSA) 恢复在 EVM 下仅需要 3,000 个 Gas，并且由于 我们可能只希望验证发生在 validator 的绝大多数（而不是完全一致）， Ethereum 的基本成本确认一条指令 经过正确验证，来自 Polkadot 网络的 Gas 不会超过 300,000，仅占 6% 总区块 Gas 限制为 5.5M。增加 validator 的数量（对于处理 然而，数十家连锁店）不可避免地增加了这一成本 人们普遍预计 Ethereum 的交易带宽会随着技术的成熟而增长 基础设施改善。再加上事实并非如此 所有 validator 都需要参与（例如，只有最高的 可能会要求质押的 validators 来执行此类任务） 这种机制的局限性相当好。 假设每天轮换此类 validator（即 相当保守——每周甚至每月都可以接受），那么维护网络的成本 这个 Ethereum-转发桥大约有 540,000 每天天然气，或者目前的天然气价格为每年 45 美元。单独通过桥转发的基本交易将花费 约 0.11 美元；额外的合同计算将花费 当然还有更多。通过缓冲和捆绑交易 总之，闯入授权成本可以很容易地计算出来 共享，大幅降低每笔交易的成本； 如果转发前需要 20 笔交易，则 转发基本交易的成本将降至 约 0.01 美元。 这种多重签名合约模型的一种有趣且更便宜的替代方案是使用门限签名来实现多边所有权语义。而 ECDSA 的门限签名方案 与其他方案相比，计算成本较高 比如Schnorr签名就非常合理。 Ethereum 计划引入原语，这将使这样的 在即将到来的 Metropolis 硬分叉中使用成本低廉的方案。如果能够使用这种手段，天然气成本 用于将 Polkadot 交易转发到 Ethereum 网络将急剧减少到接近于零 超出验证基本成本的开销 签名并执行基础交易。 在此模型中，Polkadot 的 validator 节点将具有 除了签署消息之外别无其他。为了让交易实际路由到 Ethereum 网络上，我们 假设 validator 本身也将驻留在 Ethereum 网络，或者更有可能的是，小额赏金 被提供给第一个转发消息的参与者 到网络（赏金可以简单地支付给 交易发起人）。 5.5.2. Ethereum 至 Polkadot。让交易成为 从 Ethereum 转发到 Polkadot 使用日志的简单概念。当 Ethereum 合约希望将交易分派到 Polkadot 的特定平行链时， 它只需要签订一份特殊的“突破合同”即可。 突破合同将收取任何可能的付款 被要求并发出记录指令，以便可以通过 Merkle 证明和相应块头有效的断言来证明其存在，并且 规范的。 在后两个条件中，有效性可能是最重要的 最容易证明。原则上，唯一的要求是对于每个需要证明的 Polkadot 节点 （即指定的 validator 节点）运行标准 Ethereum 节点的完全同步实例。不幸的是，这本身就是一个相当严重的依赖。一个更多 轻量级方法是使用一个简单的证明 通过仅提供 正确执行所需的 Ethereum 状态树的一部分 块中的交易并检查日志（包含在块收据中）是否有效。这种“类似 SPV”6 证明可能还需要大量信息；方便的是，通常不需要它们 all：Polkadot 内的绑定系统将允许绑定 第三方提交标头可能会面临丢失其标头的风险 bond 如果其他第三方（例如“渔夫”，参见 6.2.3）提供标头无效的证明 （具体来说，州根或收据根是冒名顶替者）。 在像 Ethereum 这样的非最终 PoW 网络上， 规范性无法得到最终证明。 为了解决这个问题，尝试依赖任何类型的应用程序 链相关的因果关系等待多个“确认”，或者直到相关交易处于某个状态 链内的特定深度。 在 Ethereum 上，这 深度从 1 个区块（无已知网络问题的最不有价值的交易）到 1200 个区块不等 Frontier 首次发布交易所期间的情况。 在稳定的“Homestead”网络上，这个数字位于 大多数交易所需要 120 个区块，我们可能会采取 类似的参数。 所以 我们 可以 想象 我们的 Polkadot-侧 Ethereum接口有一些简单的功能：能够 接受来自 Ethereum 网络的新标头并验证 PoW，以便能够接受一些证明 Ethereum 侧突破合约发出了特定的日志，以获得足够深度的标头（并且向前 Polkadot 中的相应消息），最后 能够接受先前接受过的证据，但 尚未制定的标头包含无效的收据根。 实际获取 Ethereum 标头数据本身（以及 任何 SPV 证明或有效性/规范性反驳） Polkadot 网络，转发激励 6SPV 指的是 Bitcoin 中的简化支付验证，并描述了一种让客户端验证交易的方法，同时只保留 最长 PoW 链的所有区块头的副本。Polkadot：异构多链框架的愿景 草案1 9 需要数据。 这可以像付款一样简单 (funded from fees collected on the Ethereum side) paid to anyone able to forward a useful block whose header is 有效。验证者将被要求保留与最后几千个区块相关的信息，以便 be able to manage forks, either through some protocolintrinsic means or through a contract maintained on the 中继链。 5.6. Polkadot 和 Bitcoin。 Bitcoin 互操作 presents an interesting challenge for Polkadot: a so-called “双向挂钩”将是一个有用的基础设施 两个网络都有。然而，由于 the limitations of Bitcoin, providing such a peg securely is 这是一项不平凡的事业。交付交易自 Bitcoin to Polkadot can in principle be done with a process similar to that for Ethereum; “突破地址” controlled in some way by the Polkadot validators could receive transferred tokens (and data sent alongside them). SPV 证明可以通过激励 oracle 提供，并且， together with a confirmation period, a bounty given for 识别暗示交易的非规范区块 已被“双花”。然后拥有的任何 tokens “break-out address” would then, in principle, be controlled by those same validators for later dispersal. 然而问题是如何通过旋转的 validator 装置安全地控制存款。 不像 Ethereum 能够根据 upon combinations of signatures, Bitcoin is substantially 更有限，大多数客户仅接受最多 3 方的多重签名交易。 Extending this to 36, or indeed thousands as might ultimately be desired, is impossible under the current protocol.一种选择是更改 Bitcoin 协议以启用 此类功能，但是所谓的“硬分叉” 从最近的尝试来看，Bitcoin 世界很难安排。一种可能性是使用门限签名， 允许单一可识别公众的加密方案 密钥由多个秘密“部分”有效控制， 必须使用其中的部分或全部来创建有效的签名。 不幸的是，阈值签名兼容 使用 Bitcoin 的 ECDSA 的计算成本很高 创建多项式复杂度的 和 。其他方案如 a Schnorr 签名的成本要低得多，但是 它们可能被引入 Bitcoin 的时间表 协议是不确定的。 由于存款的最终安全取决于 多个绑定的 validator，另一种选择是 将多重签名密钥持有者减少到仅大量 bonded subset of the total validators such that threshold 签名变得可行（或者，在最坏的情况下，Bitcoin 的原生 多重签名是可能的）。 这当然减少了 如果 validator 的行为违法，则可以在赔偿中扣除的保证金总额，但是这 是一种优雅的降级，只需设置一个上限 可以在两者之间安全运行的资金量 两个网络（或者实际上，攻击造成的损失百分比 从 validator 成功）。 因此，我们认为放置一个相当安全的 Bitcoin 互操作性“虚拟平行链”并非不现实 两个网络之间，尽管仍然需要付出巨大的努力，但时间表不确定，而且很可能 需要利益相关者的合作 网络。
البروتوكول بالتفصيل
يمكن تقسيم البروتوكول تقريبًا إلى ثلاثة الأجزاء: آلية التوافق، واجهة الباراشين وتوجيه المعاملات بين السلاسل. 6.1. سلسلة التتابع العملية. ال سلسلة التتابع سوف من المحتمل أن تكون سلسلة مشابهة إلى حد كبير لـ Ethereum من حيث أنها يعتمد على الحالة مع عنوان تعيين الحالة للحساب المعلومات، وبشكل رئيسي الأرصدة و(لمنع الإعادة) أ عداد المعاملات. إن وضع الحسابات هنا يحقق غرضًا واحدًا: توفير المحاسبة التي تمتلكها الهوية ما هو حجم الحصة في النظام.7 ومع ذلك، ستكون هناك اختلافات ملحوظة: • لا يمكن نشر العقود من خلال المعاملات. بناءً على الرغبة في تجنب وظائف التطبيق على سلسلة الترحيل، فلن يحدث ذلك دعم النشر العام للعقود. • حساب استخدام الموارد ("الغاز") لا يتم احتسابه؛ منذ الوظائف الوحيدة المتاحة للاستخدام العام سيتم إصلاح الأساس المنطقي وراء حساب الغاز لم يعد يحمل. وعلى هذا النحو، سيتم تطبيق رسوم ثابتة جميع الحالات، مما يسمح بمزيد من الأداء من أي تنفيذ التعليمات البرمجية الديناميكية التي قد يلزم القيام بها وتنسيق معاملة أبسط. • يتم دعم وظيفة خاصة للعقود المدرجة التي تسمح بالتنفيذ التلقائي ومخرجات رسائل الشبكة. في حالة أن سلسلة التتابع تحتوي على جهاز افتراضي ويكون كذلك استنادًا إلى EVM، سيكون لها عدد من التعديلات لضمان أقصى قدر من البساطة. من المحتمل لديك عدد من العقود المضمنة (على غرار تلك الموجودة في العناوين 1-4 في Ethereum) للسماح بالنظام الأساسي المحدد الواجبات التي يجب إدارتها بما في ذلك عقد الإجماع، أ validator العقد وعقد الباراشين. إذا لم يكن EVM، فإن الواجهة الخلفية WebAssembly [2] (wasm) هي البديل الأكثر احتمالاً؛ في هذه الحالة عموما سيكون الهيكل مماثلا، ولكن لن تكون هناك حاجة لكون العقود المضمنة مع Wasm هدفًا قابلاً للتطبيق للغات الأغراض العامة بدلا من اللغات غير الناضجة ولغات محدودة لـ EVM. الانحرافات المحتملة الأخرى عن بروتوكول Ethereum الحالي ممكنة تمامًا، على سبيل المثال تبسيط البروتوكول تنسيق إيصال المعاملة الذي يسمح بالتنفيذ المتوازي للمعاملات غير المتعارضة داخل نفس الكتلة، كما هو مقترح لسلسلة تغييرات Serenity. من الممكن، على الرغم من أنه من غير المحتمل، أن يكون مثل الصفاء يتم نشر السلسلة "النقية" كسلسلة ترحيل، مما يسمح بـ عقد خاص لإدارة أشياء مثل staking token أرصدة بدلا من جعل ذلك جزءا أساسيا من بروتوكول السلسلة. في الوقت الحاضر، نشعر أنه من غير المرجح أن يحدث هذا سيوفر تبسيطًا رائعًا للبروتوكول بشكل كافٍ يستحق التعقيد الإضافي وعدم اليقين الذي ينطوي عليه الأمر في تطويره. 7 كوسيلة لتمثيل المبلغ الذي يكون حامل معين مسؤولاً عن الأمن العام للنظام، فإن حسابات الحصص هذه ستكون كذلك حتما ترميز بعض القيمة الاقتصادية. ومع ذلك، ينبغي أن يكون مفهوما أنه نظرا لعدم وجود نية لاستخدام هذه القيم في بأي طريقة بغرض التبادل بسلع وخدمات في العالم الحقيقي، تجدر الإشارة وفقًا لذلك إلى أنه لا يمكن تشبيه tokens بـ العملة وعلى هذا النحو تحتفظ سلسلة الترحيل بفلسفتها العدمية فيما يتعلق بالتطبيقات.بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 10 هناك عدد من الأجزاء الصغيرة من الوظائف المطلوبة لإدارة آلية الإجماع، ومجموعة validator، وآلية التحقق من الصحة، والمظلات. هذه يمكن تنفيذها معًا بموجب بروتوكول متجانس. ومع ذلك، ولأسباب تتعلق بالنموذجية، فإننا نصفها بأنها "عقود" لسلسلة الترحيل. ينبغي لهذا يجب أن تؤخذ على أنها أشياء (بمعنى برمجة موجهة للكائنات) تتم إدارتها بواسطة آلية الإجماع الخاصة بسلسلة الترحيل، ولكن ليس ذلك بالضرورة يتم تعريفها كبرامج في أكواد التشغيل التي تشبه EVM، ولا حتى أنها يمكن معالجتها بشكل فردي من خلال نظام الحساب. 6.2. عقد التوقيع المساحي. يحافظ هذا العقد على مجموعة validator. يدير: • ما هي الحسابات حاليًا validators؛ • والتي هي متاحة لتصبح validators باختصار إشعار؛ • الحسابات التي وضعت حصة الترشيح لها أ validator؛ • خصائص كل منها بما في ذلك staking الحجم ومعدلات الدفع المقبولة والعناوين وهويات (الجلسة) قصيرة المدى. يسمح للحساب بتسجيل الرغبة في أن يصبح المستعبدين validator (مع متطلباته)، للترشيح لبعض الهوية، وللمستعبدين الموجودين مسبقًا validators لتسجيل رغبتهم في الخروج من هذه الحالة. إنه أيضًا يتضمن الآلية نفسها لآلية التحقق من الصحة وتحديد المعايير الأساسية. 6.2.1. الحصة-token السيولة. ومن المرغوب فيه عموما أن الحصول على أكبر قدر ممكن من إجمالي staking tokens وتشارك ضمن عمليات صيانة الشبكة منذ ذلك الحين وهذا يربط بشكل مباشر أمان الشبكة بـ "القيمة السوقية" الإجمالية لـ staking token. هذا يمكن بسهولة سيتم تحفيزك من خلال تضخيم العملة وتسليم العائدات لأولئك الذين يشاركون باسم validators. ومع ذلك، فإن القيام بذلك يمثل مشكلة: إذا كان token مقفل في عقد التوقيع المساحي تحت عقوبة التخفيض، فكيف يمكن أن يظل جزء كبير كافيًا السائل من أجل السماح باكتشاف الأسعار؟ إحدى الإجابات على ذلك هي السماح بعقد مشتق مباشر، وتأمين tokens القابلة للاستبدال على token المرهونة الأساسية. ومن الصعب ترتيب ذلك بطريقة خالية من الثقة. علاوة على ذلك، لا يمكن معاملة هذه المشتقات token على قدم المساواة لنفس السبب الذي يجعل سندات حكومات منطقة اليورو المختلفة غير قابلة للاستبدال: هناك هي فرصة لفشل الأصول الأساسية وتصبح لا قيمة لها. مع حكومات منطقة اليورو، يمكن أن يكون هناك default. مع validator-s tokens، يجوز validator التصرف بشكل ضار ويعاقب. تمشيًا مع مبادئنا، اخترنا الحل الأبسط: ألا يتم الرهان على جميع token. وهذا يعني ذلك ستبقى نسبة معينة (ربما 20%) من tokens سائلة بالقوة. وعلى الرغم من أن هذا غير مثالي من منظور أمني، فمن غير المرجح أن يحدث فرقًا جوهريًا أمن الشبكة؛ وسيظل من الممكن تقديم 80% من التعويضات الممكنة نتيجة لمصادرة السندات مقارنة بـ "الحالة المثالية" بنسبة 100% staking. يمكن استهداف النسبة بين tokens المرهونة والسائلة بكل بساطة من خلال آلية المزاد العكسي. بشكل أساسي، أصحاب token مهتمون بأن يكونوا validator سينشر كل منهم عرضًا لعقد staking ينص على ذلك الحد الأدنى لمعدل الدفع الذي سيطلبون الحصول عليه جزء. في بداية كل جلسة (ستكون الجلسات يحدث بانتظام، ربما مرة واحدة في الساعة). سيتم ملء الخانات validator وفقًا لكل مرشح محتمل حصة validator ومعدل العائد. خوارزمية واحدة محتملة لأن هذا سيكون بمثابة قبول أولئك الذين لديهم أقل العروض تمثل حصة لا تزيد عن إجمالي الحصة المستهدفة مقسومًا على عدد الفتحات وما لا يقل عن الحد الأدنى لنصف هذا المبلغ. إذا لم يكن من الممكن ملء الفتحات، يمكن تخفيض الحد الأدنى بشكل متكرر بعامل ما من أجل الإرضاء. 6.2.2. ترشيح. من الممكن الترشيح دون ثقة منها staking tokens إلى validator نشط، مما يمنحهم مسؤولية واجبات validators. أعمال الترشيح من خلال نظام التصويت بالموافقة. يستطيع كل مرشح محتمل نشر تعليمات لعقد staking التعبير عن هوية واحدة أو أكثر validator تحت من المسؤولية وهم على استعداد لتكليف سنداتهم. في كل جلسة، يتم توزيع سندات المرشحين على أن تكون ممثلة بواحد أو أكثر من validators. تعمل خوارزمية التشتيت على تحسين مجموعة من validators من الإجمالي المكافئ السندات. تصبح سندات الترشيح تحت المسؤولية الفعلية لـ validator أوكسب الفائدة أو المعاناة أ تخفيف العقوبة وفقا لذلك. 6.2.3. مصادرة/حرق السندات. يؤدي سلوك validator المعين إلى تخفيض عقابي لسنداتهم. إذا يتم تخفيض السند إلى أقل من الحد الأدنى المسموح به، و انتهت الجلسة قبل الأوان وبدأت جلسة أخرى. تتضمن القائمة غير الشاملة لسوء السلوك الذي يعاقب عليه validator ما يلي: • أن تكون جزءًا من مجموعة غير قادرة على تقديم الدعم الإجماع على صحة كتلة المظلة؛ • التوقيع الفعال على صلاحية التوقيع كتلة المظلة • عدم القدرة على توريد حمولات الخروج سابقاً تم التصويت عليه حسب المتاح؛ • عدم النشاط أثناء عملية الإجماع. • التحقق من صحة كتل سلسلة الترحيل على الشوكات المتنافسة. تهدد بعض حالات سوء السلوك سلامة الشبكة (مثل التوقيع على كتل سلسلة غير صالحة والتحقق من صحة جوانب متعددة من الشوكة) وبالتالي تؤدي إلى نفي فعال من خلال التخفيض الكلي للسند. في حالات أخرى أقل خطورة (مثل عدم النشاط في الإجماع العملية) أو الحالات التي لا يمكن فيها تخصيص اللوم بدقة (كونك جزءًا من مجموعة غير فعالة)، جزء صغير يجوز بدلاً من ذلك تغريم السند. وفي الحالة الأخيرة هذا يعمل بشكل جيد مع زبد المجموعة الفرعية للتأكد من أن البرامج الضارة تعاني العقد من خسارة أكبر بكثير من العقد الخيرية المتضررة بشكل جانبي. في بعض الحالات (على سبيل المثال، التحقق من صحة الشوكة المتعددة وغير الصالح توقيع الكتلة الفرعية) لا يستطيع validators اكتشاف سوء سلوك بعضهم البعض بسهولة منذ التحقق المستمر ستكون مهمة كل كتلة باراشين مهمة شاقة للغاية. هنا من الضروري حشد دعم الأطراف الخارجية عملية التحقق للتحقق من سوء السلوك والإبلاغ عنه. يحصل الطرفان على مكافأة مقابل الإبلاغ عن مثل هذا النشاط؛ مصطلحهم "الصيادون" ينبع من عدم الاحتمال من مثل هذه المكافأة. وبما أن هذه الحالات عادة ما تكون خطيرة للغاية، فإننا نتصور أنه يمكن بسهولة دفع أي مكافآت من السند المصادر. بشكل عام نحن نفضل تحقيق التوازن في الحرق (أي التخفيض إلى لا شيء) مع إعادة التخصيص، بدلاً من محاولة إعادة التخصيص بالجملة. وهذا له تأثير
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 11 زيادة القيمة الإجمالية لـ token، وتعويض الشبكة بشكل عام إلى حد ما وليس على وجه التحديد الطرف المشارك في الاكتشاف. هذا هو في المقام الأول بمثابة السلامة الآلية: يمكن أن تؤدي الكميات الكبيرة المعنية إلى تحفيز السلوك المتطرف والحاد إذا كانت جميعها منح لهدف واحد. بشكل عام، من المهم أن تكون المكافأة كبيرة بما يكفي لجعل عملية التحقق جديرة بالاهتمام بالنسبة للشبكة، ولكن ليست كبيرة بحيث تعوض تكاليف مواجهة مشكلة ما. مجرم "على المستوى الصناعي" ممول بشكل جيد وجيد التنظيم هجوم قرصنة على بعض الأشخاص غير المحظوظين validator لإجبارهم على سوء السلوك. بهذه الطريقة، يجب أن يكون المبلغ المطالب به بشكل عام لا أكبر من الرابطة المباشرة للمخطئ validator، لئلا أ ينشأ الحافز الضار من سوء التصرف والإبلاغ عن المكافأة. ويمكن مكافحة هذا إما بشكل صريح من خلال الحد الأدنى من متطلبات السندات المباشرة لكونها validator أو ضمنيًا من خلال تثقيف المرشحين بأن validator الذين لديهم سندات قليلة مودعة ليس لديهم حافز كبير أن تتصرف بشكل جيد. 6.3. سجل الباراشين. يتم تعريف كل مظلة في هذا التسجيل. إنها بنية بسيطة نسبيًا تشبه قاعدة البيانات وتحتوي على معلومات ثابتة وديناميكية كل سلسلة. تتضمن المعلومات الثابتة فهرس السلسلة (ملف بسيط عدد صحيح)، إلى جانب هوية بروتوكول التحقق من الصحة، أ وسائل التمييز بين الفئات المختلفة Parachain بحيث يمكن أن تكون خوارزمية التحقق الصحيحة يتم تشغيله بواسطة validators المخصص لتقديم مرشح صالح. سيركز إثبات المفهوم الأولي على الوضع خوارزميات التحقق الجديدة في العملاء أنفسهم، مما يتطلب بشكل فعال شوكة صلبة للبروتوكول في كل مرة تمت إضافة فئة إضافية من السلسلة. في نهاية المطاف، على أية حال، قد يكون من الممكن تحديد خوارزمية التحقق من الصحة في طريقة صارمة وفعالة بما يكفي للعملاء قادرة على العمل بفعالية مع المظلات الجديدة دون شوكة صلبة. أحد السبل الممكنة لذلك هو التحديد خوارزمية التحقق من صحة Parachain في راسخة، لغة مجمعة محليًا ومحايدة للنظام الأساسي مثل WebAssembly. من الضروري إجراء بحث إضافي لتحديد إذا كان هذا ممكنا حقا، ولكن إذا كان الأمر كذلك، فإنه يمكن أن يحقق معها الميزة الهائلة المتمثلة في استبعاد الشوكات الصلبة من أجل الخير. تتضمن المعلومات الديناميكية جوانب من نظام توجيه المعاملات التي يجب أن تحظى باتفاقية عالمية كقائمة انتظار دخول المظلة (الموصوفة في القسم 6.6). السجل قادر على إضافة المظلات فقط من خلال التصويت في الاستفتاء الكامل؛ يمكن إدارة هذا داخليًا ولكن من المرجح أن يتم وضعها في الخارج عقد الاستفتاء من أجل تسهيل إعادة الاستخدام بموجب المزيد من مكونات الحوكمة العامة. المعلمات ل متطلبات التصويت (على سبيل المثال، أي نصاب قانوني مطلوب، الأغلبية مطلوب) لتسجيل سلاسل إضافية وغيرها، سيتم تحديد ترقيات النظام الأقل رسمية في ملف "master الدستور" ولكن من المرجح أن يتبعوا دستورًا تقليديًا إلى حد ما المسار، على الأقل في البداية. الصياغة الدقيقة خارج نطاق العمل الحالي، ولكن على سبيل المثال. أغلبية الثلثين لتمرير أكثر من ثلث إجمالي النظام قد يكون التصويت على الحصة بشكل إيجابي نقطة انطلاق معقولة. وتشمل العمليات الإضافية تعليق وإزالة المظلات. ونأمل أن التعليق أبدا يحدث ذلك، إلا أنه مصمم ليكون أقل ضمانًا هناك بعض المشاكل المستعصية في نظام التحقق من صحة سلسلة الباراتشين. المثال الأكثر وضوحا حيث قد يكون ذلك ما يلزم هو وجود اختلاف حاسم بالإجماع بين التطبيقات التي تؤدي إلى عدم قدرة validators على الاتفاق عليها صلاحية أو كتل. سيتم تشجيع المصادقين على استخدامها تطبيقات العميل المتعددة حتى يتمكنوا من ذلك لاكتشاف مثل هذه المشكلة قبل مصادرة السندات. وبما أن التعليق هو إجراء طارئ، فإنه سيكون كذلك تحت رعاية الديناميكية validator- التصويت بالأحرى من الاستفتاء. إعادة التثبيت ستكون ممكنة على حد سواء من validators أو الاستفتاء. إن إزالة المظلات تمامًا لن تأتي إلا بعد الاستفتاء والذي سيكون مطلوبا أ فترة سماح كبيرة للسماح بالانتقال المنظم إلى إما سلسلة مستقلة أو أن تصبح جزءًا من سلسلة أخرى نظام الإجماع. من المحتمل أن تكون فترة السماح من ترتيب الأشهر ومن المرجح أن يتم تحديده على أساس كل سلسلة في سجل الباراشين من أجل أن تكون مختلفة يمكن أن تتمتع سلاسل المظلات بفترات سماح مختلفة وفقًا لـ حاجتهم. 6.4. ختم كتل التتابع. يشير الختم، في جوهره، إلى عملية تحديد المعايير القانونية؛ وهذا هو، البيانات الأساسية تحويل الذييرسم الأصل إلى شيء فريد وذو معنى بشكل أساسي. تحت سلسلة PoW، الختم هو بشكل فعال مرادف للتعدين. في حالتنا، يتضمن جمع البيانات الموقعة من validators حول صحة وتوافر وقانونية ملف كتلة سلسلة تتابع معينة وكتل المظلة ذلك إنه يمثل. إن آليات خوارزمية الإجماع BFT الأساسية خارج نطاق العمل الحالي. سوف نقوم بذلك بدلاً من ذلك وصفها باستخدام بدائية والتي تفترض أ آلة الدولة التي تخلق الإجماع. في النهاية نتوقع للاستلهام من عدد من الإجماع الواعد BFT الخوارزميات في القلب؛ Tangaora [9] (أ BFT متغير من الطوافة [16])، النعناع [11] وعسل الغريرBFT [14]. سيتعين على الخوارزمية التوصل إلى اتفاق بشأن سلاسل مظلات متعددة بالتوازي، وبالتالي تختلف عن المعتاد blockchain آليات الإجماع. نحن نفترض ذلك مرة واحدة وبعد التوصل إلى الإجماع، أصبحنا قادرين على تسجيل الإجماع في دليل قاطع يمكن أن يقدمه أي من المشاركين إليها. ونحن نفترض أيضا أن سوء السلوك ضمن البروتوكول يمكن عموما تخفيضها إلى صغيرة مجموعة تحتوي على مشاركين يسيئون التصرف لتقليلها 8. الأضرار الجانبية عند تطبيق العقوبة يتم وضع الدليل، الذي يأخذ شكل بياناتنا الموقعة، في رأس كتلة سلسلة التتابع معًا مع بعض المجالات الأخرى، ليس أقلها جذر Statetrie لسلسلة الترحيل وجذر محاولة المعاملة. ال الختم عملية يأخذ مكان تحت أ واحد توليد الإجماع آلية معالجة على حد سواء ال كتلة سلسلة التتابع وكتل المظلات التي تصنعها جزء من محتوى التتابع: لا يتم "ارتكاب" المظلات بشكل منفصل من قبل مجموعاتها الفرعية ثم يتم تجميعها في وقت لاحق. يؤدي هذا إلى عملية أكثر تعقيدًا لسلسلة الترحيل، ولكنه يسمح لنا بإكمال إجماع النظام بأكمله في مرحلة واحدة، مما يقلل من زمن الوصول ويسمح لمتطلبات توافر البيانات المعقدة للغاية والتي مفيدة لعملية التوجيه أدناه. 8إن مخططات الإجماع القائمة على إثبات الحصة (PoS) BFT مثل Tendermint BFT وSlasher الأصلي تفي بهذه التأكيدات.
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 12 قد تكون حالة آلة الإجماع الخاصة بكل مشارك يمكن تصميمه على شكل جدول بسيط (ثنائي الأبعاد). كل مشارك (validator) لديه مجموعة من المعلومات في النموذج من البيانات الموقعة ("الأصوات") من المشاركين الآخرين، فيما يتعلق بكل مرشح كتلة سلسلة المظلات وكذلك مرشح كتلة سلسلة التتابع. مجموعة المعلومات مكونة من قطعتين من البيانات: التوفر: هل هذا validator لديك الخروج معلومات ما بعد المعاملة من هذه الكتلة لذلك هل هم قادرون على التحقق بشكل صحيح من صحة مرشحي الباراشين في الكتلة التالية؟ يمكنهم التصويت إما 1 (معروف) أو 0 (غير معروف بعد). مرة واحدة التصويت 1، وهم ملتزمون بالتصويت بالمثل بقية هذه العملية. الأصوات في وقت لاحق التي لا تفعل ذلك احترام هذا هو سبب للعقاب. الصلاحية: هل الكتلة المظلية صالحة وهي كلها البيانات المرجعية خارجيًا (على سبيل المثال. المعاملات) متاح؟ هذا ينطبق فقط على validator المعينين لسلسلة الباراشين التي يصوتون عليها. يمكنهم التصويت إما بـ 1 (صالح)، أو -1 (غير صالح) أو 0 (لم يعرف بعد). بمجرد أن يصوتوا بغير الصفر، فإنهم ملتزمون بالتصويت بهذه الطريقة لبقية هذه العملية. الأصوات اللاحقة التي لا تحترم هذا هي أسباب للعقاب. يجب على جميع validators تقديم الأصوات؛ ويجوز إعادة تقديم الأصوات، المؤهلة بموجب القواعد المذكورة أعلاه. تطور يمكن صياغة الإجماع على أنه خوارزميات إجماع قياسية متعددة BFT على كل سلسلة باراشين تحدث بالتوازي. نظرًا لأنه من المحتمل أن يتم إحباطها نسبيًا أقلية صغيرة من الجهات الفاعلة الخبيثة تتركز فيها مجموعة باراشين واحدة، يوجد إجماع عام على ذلك إنشاء مساندة، مما يحد من السيناريو الأسوأ طريق مسدود إلى واحد أو أكثر من كتل المظلة الفارغة (و جولة عقابية للمسؤولين). القواعد الأساسية لصحة الكتل الفردية (التي تسمح بوصول إجمالي مجموعة validators ككل الإجماع على أن يصبح المرشح الفريد من نوعه ليتم الرجوع إليها من التتابع الكنسي): • يجب أن يكون تصويت ثلثي validators على الأقل إيجابيًا وعدم تصويت أي منهم سلبيًا؛ • يجب أن يحصل أكثر من ثلث validator على تصويت إيجابي على توفر معلومات قائمة انتظار الخروج. إذا كان هناك صوت إيجابي واحد على الأقل وصوت سلبي واحد على الأقل بشأن الصلاحية، يتم إنشاء حالة استثنائية ويجب على مجموعة validators بأكملها التصويت لتحديد ذلك إذا كانت هناك أطراف كيدية أو إذا كان هناك حادث عرضي شوكة. فإلى جانب الصحيح والباطل، هناك نوع ثالث من الأصوات مسموح بها، أي ما يعادل التصويت لكليهما، وهذا يعني ذلك العقدة لديها آراء متضاربة. قد يكون هذا بسبب يقوم مالك العقدة بتشغيل تطبيقات متعددة والتي تقوم بذلك لا أتفق، مما يشير إلى الغموض المحتمل في البروتوكول. بعد احتساب جميع الأصوات من مجموعة validator الكاملة، إذا الرأي الخاسر له على الأقل نسبة صغيرة (إلى تكون ذات معلمات؛ على الأكثر النصف، وربما أقل بكثير) من أصوات الرأي الفائز، فيفترض ذلك يكون شوكة المظلة عرضية ويتم تعليق المظلة تلقائيًا من عملية الإجماع. وإلا فإننا نفترض أنه عمل خبيث ونعاقب عليه الأقلية الذين صوتوا للرأي المخالف. والختام عبارة عن مجموعة من التوقيعات الدالة الكنسية. قد يتم بعد ذلك إغلاق كتلة سلسلة الترحيل وبدأت عملية إغلاق الكتلة التالية. 6.5. تحسينات لختم كتل التتابع. بينما تعطي طريقة الختم هذه ضمانات قوية على تشغيل النظام، ولا تتوسع بشكل جيد نظرًا لأن المعلومات الأساسية لكل سلسلة باراشين يجب أن تحتوي على معلوماتها الخاصة التوفر مضمون بأكثر من ثلث جميع validators. وهذا يعني أن كل validator له بصمة المسؤولية ينمو مع إضافة المزيد من السلاسل. بينما توفر البيانات ضمن شبكات الإجماع المفتوحة هي في الأساس مشكلة لم يتم حلها، وهناك طرق لتخفيف الحمل الموضوع على العقد validator. واحدة بسيطة الحل هو إدراك أنه بينما يجب على validators تحمله يتحملون مسؤولية توفر البيانات، فهم لا يحتاجون فعليًا إلى تخزين البيانات أو توصيلها أو تكرارها بأنفسهم. صوامع البيانات الثانوية، ربما تتعلق بـ (أو حتى ذات الصلة). نفسه) يمكن للمجمعين الذين يقومون بتجميع هذه البيانات إدارة مهمة ضمان التوفر مع validators الذين يقدمون جزءًا من فوائدهم/دخلهم في الدفع. ومع ذلك، في حين أن هذا قد يشتري بعض قابلية التوسع المتوسطة، إلا أنه لا يزال لا يساعد في حل المشكلة الأساسية؛ منذ ذلك الحين ستتطلب إضافة المزيد من السلاسل بشكل عام validators إضافية، وينمو استهلاك موارد الشبكة المستمر (خاصة فيما يتعلق بعرض النطاق الترددي) مع مربع الالسلاسل، خاصية لا يمكن الدفاع عنها على المدى الطويل. في نهاية المطاف، من المرجح أن نستمر في ضرب رؤوسنا ضد القيد الأساسي الذي ينص على ذلك شبكة توافقية تعتبر آمنة ومتاحة متطلبات النطاق الترددي المستمر هي في حدود الإجمالي validators مرات إجمالي معلومات الإدخال. هذا يرجع إلى عدم قدرة شبكة غير موثوقة على توزيع مهمة تخزين البيانات بشكل صحيح عبر العديد من العقد، والتي تقع بصرف النظر عن مهمة المعالجة القابلة للتوزيع بشكل بارز. 6.5.1. تقديم الكمون. إحدى وسائل تخفيف هذا القاعدة هي تخفيف فكرة الفورية. من خلال المطالبة بنسبة 33%+1 validators للتصويت على التوفر فقط في نهاية المطاف، وليس على الفور، يمكننا الاستفادة بشكل أفضل من نشر البيانات الأسية والمساعدة في تجاوز الذروة في تبادل البيانات. مساواة معقولة (على الرغم من عدم إثباتها) قد يكون: (1) الكمون = المشاركين × السلاسل في ظل النموذج الحالي، يتم تغيير حجم النظام مع عدد السلاسل للتأكد من أن المعالجة موزعة؛ نظرًا لأن كل سلسلة ستتطلب validator واحدًا على الأقل ونصلح شهادة التوفر إلى ثابت نسبة validators، ثم ينمو المشاركون بالمثل مع عدد السلاسل ننتهي بـ: (2) الكمون = الحجم 2 وهذا يعني أنه مع نمو النظام، يصبح النطاق الترددي المطلوب وزمن الوصول حتى التوفر معروفًا عبر الشبكة الشبكة، والتي يمكن أيضًا وصفها بالرقم من الكتل قبل النهاية، يزيد مع مربعها. هذا هو عامل نمو كبير وقد يتحول إلى عائق ملحوظ ويجبرنا على اتباع نماذج "غير مسطحة" مثل إنشاء عدة "Polkadotes" في تسلسل هرمي لتوجيه المشاركات متعدد المستويات من خلال شجرة من سلاسل التتابع.
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 13 6.5.2. المشاركة العامة. اتجاه آخر ممكن هو تجنيد المشاركة العامة في العملية من خلال أ نظام الشكاوى الصغيرة. على غرار الصيادين، هناك يمكن أن تكون أطرافًا خارجية لضبط validators الذين يطالبون التوفر. وتتمثل مهمتهم في العثور على شخص يبدو غير قادر على إثبات هذا التوافر. في القيام بذلك هم يمكنه تقديم شكوى صغيرة إلى validators الآخرين. إثبات العمل أو يمكن استخدام السندات المرصعة للتخفيف من هجوم سيبيل الأمر الذي من شأنه أن يجعل النظام عديم الفائدة إلى حد كبير. 6.5.3. ضمانات التوفر. سيكون الطريق النهائي هو قم بترشيح مجموعة ثانية من validators المستعبدة كـ "مدى التوفر الضامنين”. سيتم ربطها تمامًا كما هو الحال مع validators العادية، وقد يتم أخذها من نفس المجموعة (على الرغم من أنه إذا كان الأمر كذلك، فسيتم اختيارهم على مدى فترة طويلة، على الأقل لكل جلسة). على عكس validators العادية، فهي لن يقوم بالتبديل بين المظلات بل سيفعل ذلك قم بتشكيل مجموعة واحدة للتأكيد على توفر جميع البيانات المهمة بين السلاسل. وهذا له ميزة تخفيف التكافؤ بين المشاركين والسلاسل. في الأساس، يمكن للسلاسل Grow (مع مجموعة السلسلة الأصلية validator)، بينما يمكن للمشاركين، وعلى وجه التحديد أولئك الذين يشاركون في اختبار توافر البيانات، أن يظلوا على الأقل خطيًا فرعيًا وربما ثابت. 6.5.4. تفضيلات المنسق. جانب واحد مهم من هذا النظام هو التأكد من وجود اختيار صحي لل يقوم المجمعون بإنشاء الكتل في أي سلسلة معينة. إذا أ سيطر المنسق الفردي على المظلة ثم بعض الهجمات تصبح أكثر جدوى نظرا لاحتمال عدم وجود سيكون توافر البيانات الخارجية أقل وضوحًا. أحد الخيارات هو وزن كتل المظلات بشكل اصطناعي آلية شبه عشوائية من أجل تفضيل مجموعة واسعة من المجمعات. في الحالة الأولى، سوف نطلب كجزء من آلية الإجماع التي يفضلها validator تم تحديد مرشحي كتلة المظلة على أنهم "أثقل". وبالمثل، يجب علينا تحفيز validators لمحاولة القيام بذلك يقترحون الكتلة الأثقل التي يمكنهم العثور عليها، وقد تكون هذه هي الكتلة يتم ذلك من خلال جعل جزء من مكافأتهم يتناسب مع وزن مرشحهم. لضمان حصول المحصلين على عادلة معقولة فرصة اختيار مرشحهم على أنه الفائز المرشح بالإجماع، فإننا نحدد الوزن المحدد لـ أ يتم تحديد مرشح كتلة المظلة على وظيفة عشوائية متصلة بكل أداة تجميع. على سبيل المثال، أخذ قياس مسافة XOR بين عنوان المُجمِّع وبعض الأرقام العشوائية الزائفة الآمنة تشفيرًا يتم تحديدها بالقرب من نقطة الكتلة التي يتم إنشاؤها ("التذكرة الفائزة" الافتراضية). وهذا يعطي كل منهما بشكل فعال المُجمِّع (أو، بشكل أكثر تحديدًا، عنوان كل مُجمِّع) أ فرصة عشوائية لفوز كتلة مرشحيهم جميع الآخرين. للتخفيف من هجوم سيبيل الذي يقوم به مُجمِّع واحد "ينقب" عن عنوان قريب من التذكرة الفائزة، وبالتالي مفضلًا لكل كتلة، سنضيف بعض القصور الذاتي إلى عنوان المجمّع. قد يكون هذا بسيطًا مثل طلبهم للحصول على مبلغ أساسي من الأموال في العنوان. أكثر سيكون النهج الأنيق هو وزن القرب من التذكرة الفائزة بمبلغ الأموال المتوقفة في العنوان المعني. في حين لم يتم بعد النمذجة، فمن الممكن تماما أن هذه الآلية تمكن حتى جدا أصحاب المصلحة الصغار للمساهمة كمجمع. 6.5.5. كتل الوزن الزائد. إذا تم اختراق مجموعة validator، فيمكنهم إنشاء واقتراح كتلة بالرغم من ذلك صالحة، وتستغرق قدرا هائلا من الوقت للتنفيذ و التحقق من صحة. هذه مشكلة نظرًا لأن مجموعة validator يمكنها ذلك تشكيل كتلة بشكل معقول والتي تستغرق وقتًا طويلاً جدًا التنفيذ ما لم تكن بعض المعلومات المعينة معروفة بالفعل مما يسمح بالاختصار، على سبيل المثال. التخصيم كبير رئيس الوزراء. إذا كان أحد المتعاونين يعرف هذه المعلومات، إذن سيكون لديهم ميزة واضحة في الحصول على ميزة خاصة بهم تم قبول المرشحين طالما كان الآخرون مشغولين بمعالجة الكتلة القديمة. نحن نسمي هذه الكتل الوزن الزائد. الحماية ضد validator التي تقوم بإرسال هذه الكتل والتحقق من صحتها تقع إلى حد كبير تحت نفس المظهر كما في كتل غير صالحة، ولكن مع تحذير إضافي: منذ ذلك الحين الوقت المستغرق لتنفيذ الكتلة (وبالتالي حالتها الوزن الزائد) أمر شخصي، النتيجة النهائية للتصويت على سوف ينقسم سوء السلوك إلى ثلاثة معسكرات أساسية. واحد الاحتمال هو أن الكتلة بالتأكيد ليست زائدة الوزن - وفي هذه الحالة يعلن أكثر من الثلثين أنهم قادرون على ذلك تنفيذ الكتلة ضمن حد معين (على سبيل المثال، 50% من إجمالي الوقت المسموح به بين الكتل). آخر هو أن الكتلة هي دزيادة الوزن بالتأكيد - سيكون هذا إذا كان أكثر من يعلن الثلثان أنهم لا يستطيعون تنفيذ الكتلة ضمن الحد المذكور. هناك احتمال أخير وهو متساوٍ إلى حد ما انقسام في الرأي بين validators. في هذه الحالة يجوز لنا اختيار القيام ببعض العقوبة المتناسبة. للتأكد من أن validators يمكنها التنبؤ بموعد حدوثها باقتراح كتلة ذات وزن زائد، قد يكون من المعقول أن نطلب منهم نشر معلومات عن أدائهم لكل كتلة. وعلى مدى فترة زمنية كافية، وهذا من شأنه أن يسمح لهم بتحديد سرعة المعالجة الخاصة بهم مقارنة بأقرانهم الذين سيحكمون عليهم. 6.5.6. التأمين المجمع. تبقى مشكلة واحدة لـ validators: على عكس شبكات إثبات العمل (PoW)، للتحقق من المجمّع من أجل الصلاحية، يجب عليهم تنفيذ المعاملات فيه فعليًا. يمكن للمجمعين الضارين تغذية كتل غير صالحة أو زائدة الوزن إلى validators مما يسبب لهم الحزن (إهدار مواردهم) وفرض تكلفة فرصة كبيرة محتملة. للتخفيف من هذا، نقترح استراتيجية بسيطة على جزء من validators. أولاً، تم إرسال مرشحي كتلة الباراشين يجب التوقيع على validators من حساب سلسلة الترحيل بالأموال إذا لم تكن كذلك، فيجب أن ينخفض validator ذلك على الفور. ثانيًا، ينبغي ترتيب هؤلاء المرشحين حسب الأولوية من خلال مجموعة (مثل الضرب) من مبلغ الأموال في الحساب يصل إلى بعض الحد الأقصى، و عدد الكتل السابقة التي اقترحها المُجمِّع بنجاح في الماضي (ناهيك عن أي كتل سابقة العقوبات)، وعامل القرب من الفوز تذكرة كما نوقش سابقا. يجب أن يكون الغطاء هو نفسه مثل التعويضات الجزائية المدفوعة إلى validator في هذه القضية منهم إرسال كتلة غير صالحة. لتثبيط المتعاونين من إرسال مرشحي الكتلة غير الصالحين أو ذوي الوزن الزائد إلى validators، يجوز لأي validator ضع في الكتلة التالية معاملة تتضمن الكتلة المخالفة التي تدعي سوء التصرف مع تأثير تحويل بعض أو كل الأموال الموجودة في المتعاقد الذي يسيء التصرف حساب للمتضرر validator. يقوم هذا النوع من المعاملات بتشغيل أي معاملات أخرى للتأكد من عدم قدرة المُجمِّع على ذلك إزالة الأموال قبل العقوبة. كمية الأموال المحولة كتعويضات هي معلمة ديناميكية حتى الآن
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 14 ليتم تصميمها ولكن من المحتمل أن تكون نسبة من مكافأة الكتلة validator لتعكس مستوى الحزن الناتج. ل منع validators الخبيثة من مصادرة أموال المتعاونين بشكل تعسفي، يجوز للمنسق استئناف قرار validator أمام هيئة محلفين مكونة من validators تم اختيارها عشوائيًا في المقابل لوضع وديعة صغيرة. إذا وجدوا في صالح validator، فسيتم استهلاك الوديعة من قبلهم. إذا لم يكن الأمر كذلك، فإن يتم إرجاع الوديعة ويتم تغريم validator (منذ validator في وضع مقبب أكثر بكثير، الإرادة الجميلة من المرجح أن تكون ضخمة إلى حد ما). 6.6. إنترشين الصفقة التوجيه. إنترشين يعد توجيه المعاملات أحد أعمال الصيانة الأساسية مهام سلسلة التتابع وvalidators. هذا هو المنطق الذي يحكم كيفية تحول المعاملة المنشورة (التي غالبًا ما يتم اختصارها إلى "نشر") إلى ناتج مرغوب من سلسلة باراتشين مصدر واحد إلى مدخلات غير قابلة للتفاوض لسلسلة باراتشين وجهة أخرى دون أي ثقة المتطلبات. نختار الصياغة أعلاه بعناية؛ ولا سيما نحن لا تتطلب أن تكون هناك معاملة في المصدر Parachain قد وافق صراحة على هذا المنصب. الوحيد القيود التي نضعها على نموذجنا هي تلك المظلات يجب توفيرها وتعبئتها كجزء من الكتلة الشاملة الخاصة بها معالجة الإخراج، والمشاركات التي هي نتيجة تنفيذ الكتلة. تم تنظيم هذه المنشورات على هيئة عدة قوائم انتظار FIFO؛ ال يُعرف عدد القوائم بقاعدة التوجيه وقد يكون كذلك حوالي 16. والجدير بالذكر أن هذا الرقم يمثل الكمية من المظلات التي يمكننا دعمها دون الحاجة إلى اللجوء إليها التوجيه متعدد المراحل. في البداية، Polkadot سيدعم هذا نوع من التوجيه المباشر، ولكننا سنحدد واحدًا ممكنًا عملية توجيه متعددة المراحل ("التوجيه الفائق") كوسيلة من التوسع إلى ما هو أبعد من المجموعة الأولية من المظلات. نحن نفترض ذلك الكل المشاركين أعرف ال مجموعات فرعية للكتلتين التاليتين n، n + 1. باختصار، يتبع نظام التوجيه هذه المراحل: • CollatorS: اتصل بأعضاء V alidators[n][S] • المتعاونون: لكل مجموعة فرعية: تأكد من ذلك عضو واحد على الأقل من V alidators[n][s] على اتصال • المقارنات: لكل مجموعة فرعية: نفترض الخروج [n −1] [s] [S] متاح (جميع المشاركات الواردة البيانات إلى 'S' من الكتلة الأخيرة) • المقارنات: إنشاء مرشح الكتلة b لـ S: (b.header، b.ext، b.proof، b.receipt، b.egress) • المقارنات: أرسل دليل معلومات إثبات [S] = (b.header، b.ext، b.proof، b.receipt) إلى أدوات تعديل V [ن] [S] • CollatorS: ضمان بيانات المعاملات الخارجية b.ext أصبح متاحًا للمجمعين وvalidators الآخرين • المقارنات: ل لكل منهما مجموعة فرعية الصورة: أرسل الخروج معلومات الخروج [ن] [S] [ق] = (b.header، b.receipt، b.egress[s]) ل ال تلقي المجموعة الفرعية أعضاء من التالي كتلة أدوات تعديل V[n + 1][s] • V alidatorV: قم بتوصيل جميع أعضاء المجموعة نفسها مسبقًا للكتلة التالية: Let N = Chain[n + 1][V ]; الاتصال جميع validators v بحيث تكون السلسلة[n + 1][v] = N • الإضافة الخامسة : جمع كافة إدخال البيانات لهذا الغرض كتلة: ل لكل منهما مجموعة فرعية الصورة: استرداد egress[n −1][s][Chain[n][V ]]، احصل عليه من validators v الأخرى بحيث Chain[n][v] = Chain[n][V ]. من المحتمل أن يتم المرور عبر validators أخرى تم اختيارها عشوائيًا لإثبات المحاولة. • الإضافة الخامسة : قبول البراهين المرشحة لهذا إثبات الكتلة [سلسلة [ن] [V ]]. صلاحية كتلة التصويت • الإضافة الخامسة : قبول بيانات خروج المرشح ل الكتلة التالية: بالنسبة لكل مجموعة فرعية، اقبل الخروج [ن] [ق] [ن]. توفر مخرج كتلة التصويت؛ إعادة النشر بين المهتمين validators v هكذا السلسلة[n + 1][v] = السلسلة[n + 1][V ]. • المصادقة الخامسة: حتى يتم الإجماع حيث: الخروج [ن] [من] [إلى] هو قائمة انتظار الخروج الحالية معلومات للمشاركات التي تنتقل من Parachain "من"، إلى المظلة "إلى" في الكتلة رقم "ن". CollatorS عبارة عن أداة تجميع لـ parachain S. V alidators[n][s] هي مجموعة validators لـ parachain s عند الكتلة رقم n. على العكس من ذلك، Chain[n][v] هي المظلة التي تم تعيين validator v لها على الكتلة رقم n. block.egress[to] هو الخروج قائمة انتظار المشاركات من بعض كتلة المظلة التي الوجهة باراشين هو. نظرًا لأن المجامعين يجمعون رسوم (المعاملة) بناءً على ذلك تصبح كتلهم أساسية ويتم تحفيزهم عليها تأكد من أنه بالنسبة لكل وجهة للكتلة التالية، فإن المجموعة الفرعية يتم إبلاغ الأعضاء بقائمة انتظار الخروج من الحاضر كتلة. يتم تحفيز المصادقين فقط لتشكيل إجماع على كتلة (المظلة)، وبالتالي فإنهم لا يهتمون بها كثيرًا والتي تصبح كتلة المترجم في النهاية أساسية. في من حيث المبدأ، يمكن لـ validator أن يشكل ولاءً مع أحد المتعاونين ويتآمر لتقليل فرص المتعاونين الآخرين تصبح الكتل أساسية، ولكن هذا أمر صعب للترتيب بسبب الاختيار العشوائيإجراء validators لـ ويمكن الدفاع ضد سلاسل المظلات من خلال تخفيض الرسوم المستحقة على كتل المظلات التي تصمد عملية الإجماع. 6.6.1. توفر البيانات الخارجية. ضمان المظلة تعتبر البيانات الخارجية المتوفرة بالفعل مشكلة دائمة الأنظمة اللامركزية التي تهدف إلى توزيع عبء العمل عبر الشبكة. في قلب المشكلة هو التوفر المشكلة التي تنص على أنه لأنه ليس من الممكن تقديم دليل غير تفاعلي على التوفر ولا من أي نوع دليل على عدم التوفر، لنظام BFT للعمل بشكل صحيح التحقق من صحة أي انتقال تعتمد صحته على توافر بعض البيانات الخارجية، والحد الأقصى لعددها من العقد البيزنطية المقبولة، بالإضافة إلى واحدة، من النظام يجب أن تشهد على البيانات المتاحة. لكي يتم توسيع نطاق النظام بشكل صحيح، مثل Polkadot، هذا يدعو إلى مشكلة: إذا كانت نسبة ثابتة من validators يجب أن يشهد على توافر البيانات، وعلى افتراض أن validators سيرغب في تخزين البيانات فعليًا قبل التأكد من توفرها، فكيف نتجنب مشكلة زيادة عرض النطاق الترددي/متطلبات التخزين مع حجم النظام (وبالتالي عدد validators)؟ إحدى الإجابات المحتملة هي أن يكون لديك مجموعة منفصلة من validators (ضامني التوفر)، الذين ينمو طلبهم خط فرعي بحجم Polkadot ككل. هذا هو الموصوفة في 6.5.3. لدينا أيضًا خدعة ثانوية. كمجموعة، لدى المجمعين حافز جوهري للتأكد من أن جميع البيانات صحيحة متاح للمظلة التي اختاروها لأنه بدونها غير قادرين على تأليف المزيد من الكتل التي يمكنهم منها جمع رسوم المعاملات. يشكل المتعاونون أيضًا مجموعة تتنوع عضويتها (بسبب الطبيعة العشوائية). Parachain validator مجموعات) غير تافهة للدخول وسهلة
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 15 لإثبات. لذلك يُسمح للمجمعين الجدد (ربما من الآلاف القليلة الأخيرة من الكتل) بإصدار تحديات توافر البيانات الخارجية لسلسلة معينة كتلة إلى validators لسندات صغيرة. يجب على المصادقين الاتصال بأولئك الذين ينتمون إلى المجموعة الفرعية validator التي أدلت بشهادتها على ما يبدو، وإما الحصول على البيانات وإعادتها إلى المتعاون أو تصعيد الأمر الأمر من خلال الشهادة على عدم التوفر (الرفض المباشر لتقديم البيانات يعتبر جريمة تستلزم مصادرة السندات، وبالتالي فإن سوء التصرف validator من المرجح أن يكون مجرد قم بإسقاط الاتصال) والاتصال بـ validators الإضافيين لإجراء نفس الاختبار. وفي الحالة الأخيرة، سند المجمع يتم إرجاعها. بمجرد اكتمال النصاب القانوني المكون من validator الذين يمكنهم تقديم شهادات عدم التوفر هذه، يتم إطلاق سراحهم، تتم معاقبة المجموعة الفرعية التي تسيء التصرف، ويتم إرجاع الحظر. 6.6.2. توجيه المشاركات. يتضمن كل رأس باراشين خروج-جذر-جذر؛ هذا هو جذر المحاولة التي تحتوي على ملف صناديق قاعدة التوجيه، كل حاوية عبارة عن قائمة متسلسلة من مراكز الخروج. قد يتم توفير أدلة ميركل عبر Parachain validators لإثبات أن Parachain معينة تحتوي الكتلة على قائمة انتظار خروج معينة لسلسلة Parachain لوجهة معينة. في بداية تجهيز كتلة المظلة لكل منها قائمة انتظار الخروج الخاصة بـ Parachain الأخرى المرتبطة بالكتلة المذكورة هي تم دمجها في قائمة انتظار الدخول الخاصة بالكتلة الخاصة بنا. نحن نفترض قوية، ربما CSPR9، ترتيب الكتلة الفرعية لتحقيق عملية حتمية لا تقدم أي محاباة بين أي الاقتران كتلة المظلة. يقوم Collators بحساب قائمة الانتظار الجديدة وتصريف طوابير الخروج حسب المظلة المنطق. تتم كتابة محتويات قائمة انتظار الدخول بشكل صريح في كتلة المظلة. وهذا له غرضين رئيسيين: أولاً، هذا يعني أنه يمكن مزامنة المظلات بشكل موثوق بمعزل عن المظلات الأخرى. ثانيا، إنه يبسط لوجستيات البيانات في حالة الدخول بالكامل لا يمكن معالجة قائمة الانتظار في كتلة واحدة؛ validators والمجمعون قادرون على معالجة الكتل التالية دون الحاجة إلى مصدر بيانات قائمة الانتظار بشكل خاص. إذا كانت قائمة انتظار دخول الباراشين أعلى من العتبة المبلغ في نهاية معالجة الكتلة، ثم يتم وضع علامة عليه مشبعة على سلسلة التتابع ولا يجوز إرسال رسائل أخرى تسليمه إليها حتى يتم تطهيرها. البراهين ميركل هي تستخدم لإثبات دقة عملية المجمع في دليل كتلة المظلة. 6.6.3. نقد. عيب بسيط يتعلق بهذا الأساسي الآلية هي هجوم ما بعد القنبلة. هذا هو المكان الذي كل شيء ترسل سلاسل المظلات أكبر عدد ممكن من المشاركات إلى باراشين معين. في حين أن هذا يربط الهدف قائمة انتظار الدخول مرة واحدة، ولا يحدث أي ضرر أكثر من ذلك هجوم DoS القياسي للمعاملات. تعمل بشكل طبيعي، مع مجموعة من متزامنة بشكل جيد و أدوات تجميع غير ضارة وvalidators، لسلاسل N parachains، إجمالي N × M validators وL لكل مظلة، نحن يمكن تقسيم إجمالي مسارات البيانات لكل كتلة إلى: المدقق: M −1+L+L: M −1 للـ validators الأخرى في مجموعة المظلة، L لكل مُجمِّع يوفر كتلة باراشين مرشحة وL ثاني لكل مُجمِّع من الكتلة التالية التي تتطلب حمولات الخروج من الكتلة السابقة. (الأخير هو في الواقع أشبه بأسوأ الحالات العملية لأنه من المحتمل أن يشاركها المجمعون البيانات.) Collator: M +kN: M للاتصال بكل ذي صلة كتلة المظلة validator، كيلو نيوتن لبذر حمولات الخروج إلى مجموعة فرعية من كل مجموعة المظلة validator لـ الكتلة التالية (وربما بعض المجمّعات المفضلة). على هذا النحو، تنمو طرق مسار البيانات لكل عقدة بشكل خطي مع التعقيد العام للنظام. بينما هذا معقول، مع توسع النظام إلى مئات أو آلاف المظلات، قد يكون هناك بعض الكمون في الاتصالات استيعابها في مقابل معدل نمو أقل تعقيدا. في هذه الحالة، يمكن استخدام خوارزمية توجيه متعددة المراحل من أجل تقليل عدد المسارات اللحظية على حساب إدخال مخازن التخزين المؤقتة وزمن الوصول. 6.6.4. توجيه المكعب الفائق. توجيه المكعب الفائق عبارة عن آلية يمكن إنشاؤها في الغالب كامتداد لـ آلية التوجيه الأساسية الموضحة أعلاه. في الأساس، بدلاً من زيادة اتصال العقدة بعدد المظلات وعقد المجموعة الفرعية، فإننا ننمو فقط باستخدام لوغاريتم المظلات. قد تنتقل المشاركات بين العديد من طوابير المظلات في طريقهم إلى التسليم النهائي. التوجيه في حد ذاته أمر حتمي وبسيط. نبدأ بها الحد من عدد الصناديق في طوابير الدخول/الخروج؛ بدلاً من أن تكون العدد الإجمالي للمظلات، فهي هيقاعدة التوجيه (ب). سيتم تثبيت هذا كرقم من التغييرات في المظلات، مع رفع أس التوجيه (e) بدلاً من ذلك. وفي ظل هذا النموذج، حجم رسالتنا ينمو مع O(be)، مع بقاء المسارات ثابتة والكمون (أو عدد الكتل المطلوبة للتسليم) مع يا (ه). نموذج التوجيه الخاص بنا هو عبارة عن مكعب زائد ذو أبعاد e، مع وجود كل جانب من جوانب المكعب ب مواقع محتملة. في كل كتلة، نقوم بتوجيه الرسائل على طول محور واحد. نحن قم بتبديل المحور بطريقة دائرية، وبالتالي ضمان وقت تسليم الكتل الإلكترونية في أسوأ الحالات. كجزء من تجهيز الباراشين، متجهة إلى الخارج يتم توجيه الرسائل الموجودة في قائمة انتظار الدخول على الفور إلى حاوية قائمة انتظار الخروج المناسبة، نظرًا لـ رقم الكتلة الحالي (وبالتالي بُعد التوجيه). هذا تتطلب العملية نقل بيانات إضافية لكل قفزة على طريق التسليم، ولكن هذه مشكلة في حد ذاتها والتي يمكن تخفيفها باستخدام بعض الوسائل البديلة تسليم حمولة البيانات بما في ذلك مرجع فقط، بدلاً من الحمولة الكاملة للمنشور في مرحلة ما بعد المحاولة. مثال على توجيه المكعب الفائق لنظام ما مع 4 سلاسل، b = 2 و e = 2 يمكن أن تكون: المرحلة 0، في كل رسالة M: • sub0: إذا كان Mdest ∈{2, 3} ثم أرسل إلى(2) وإلا احتفظ به • sub1: إذا كان Mdest ∈{2, 3} ثم أرسل إلى(3) وإلا احتفظ به • sub2: إذا كان Mdest ∈{0, 1} ثم أرسل إلى(0) وإلا احتفظ به • sub3: إذا كان Mdest ∈{0, 1} ثم أرسل إلى(1) وإلا احتفظ به المرحلة 1، في كل رسالة م: • sub0: إذا كان Mdest ∈{1, 3} ثم أرسل إلى(1) وإلا احتفظ به • sub1: إذا كان Mdest ∈{0, 2} ثم أرسل إلى(0) وإلا احتفظ به • sub2: إذا كان Mdest ∈{1, 3} ثم أرسل إلى(3) وإلا احتفظ به • sub3: إذا كان Mdest ∈{0, 2} ثم أرسل إلى(2) وإلا احتفظ به من السهل رؤية البعدين هنا باعتبارهما البعد الأول قطعتين من فهرس الوجهة؛ للكتلة الأولى، ويتم استخدام البت ذو الترتيب الأعلى وحده. صفقات الكتلة الثانية مع البت ذو الترتيب المنخفض. بمجرد حدوث كلاهما (بشكل تعسفي الطلب) ثم سيتم توجيه المنشور. 9. آمن بشكل عشوائي زائف
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 16 6.6.5. تعظيم الصدفة. تعديل واحد من الأساسي سيشهد الاقتراح إجماليًا ثابتًا قدره c2 -c validators، مع c−1 validators في كل مجموعة فرعية. كل كتلة، بدلا من هناك إعادة تقسيم غير منظمة لـ validators بين المظلات، بدلاً من ذلك لكل مجموعة فرعية من المظلات، سيتم تعيين كل validator إلى فريد ومختلف المجموعة الفرعية المظلية على الكتلة التالية. هذا من شأنه يؤدي إلى الثابت الذي بين أي كتلتين، لأي اثنين من أزواج المظلة، يوجد اثنان من validators لقد تبادلنا مسؤوليات الباراشين. في حين لا يمكن استخدام هذا للحصول على ضمانات مطلقة بشأن التوفر (سوف ينقطع اتصال validator واحد أحيانًا، حتى لو كان خيرية)، ومع ذلك يمكنها تحسين الحالة العامة. وهذا النهج لا يخلو من التعقيدات. إن إضافة المظلة ستتطلب أيضًا إعادة التنظيم من المجموعة validator. علاوة على ذلك، فإن عدد validators، مرتبط بمربع عدد المظلات، سيبدأ في البداية صغيرًا جدًا وينمو في النهاية بعيدًا سريع جدًا، وأصبح لا يمكن الدفاع عنه بعد حوالي 50 مظلة. ولا تعتبر أي من هذه المشاكل أساسية. في الحالة الأولى، إعادة تنظيم مجموعات validator أمر لا بد منه القيام به بانتظام على أي حال. فيما يتعلق بحجم validator المحددة، عندما تكون صغيرة جدًا، قد يتم تعيين عدة validators إلى نفس المظلة، مع تطبيق عامل عدد صحيح على الإجمالي الإجمالي validators. آلية التوجيه متعددة المراحل مثل Hypercube Routing، التي تمت مناقشتها في 6.6.4 ستكون كذلك تخفيف متطلبات عدد كبير من validators عندما يكون هناك عدد كبير من السلاسل. 6.7. التحقق من صحة الباراشين. الغرض الرئيسي لـ validator هو أن يشهد، كممثل جيد الارتباط، أن باراشين الكتلة صالحة، بما في ذلك على سبيل المثال لا الحصر، أي انتقال للحالة، وأي معاملات خارجية متضمنة، وتنفيذ أي مشاركات انتظار في قائمة انتظار الدخول والحالة النهائية من صف الخروج. العملية نفسها بسيطة إلى حد ما. بمجرد إغلاق validator للكتلة السابقة، يصبحون أحرارًا لبدء العمل على توفير كتلة المظلة المرشحة مرشح للجولة القادمة من الإجماع. في البداية، يجد validator مرشحًا لكتلة باراشين من خلال مُجمِّع باراشين (الموصوف لاحقًا) أو واحد من validators المشتركة. بيانات المرشح كتلة Parachain يتضمن رأس الكتلة، ورأس الكتلة السابقة، تم تضمين أي بيانات إدخال خارجية (بالنسبة لـ Ethereum وBitcoin، ستتم الإشارة إلى هذه البيانات على أنها معاملات، ولكن من حيث المبدأ قد تتضمن هياكل بيانات عشوائية لأغراض عشوائية)، وبيانات قائمة انتظار الخروج والبيانات الداخلية لإثبات صحة انتقال الحالة (لـ Ethereum سيكون هذا هو عقد محاولة الحالة/التخزين المختلفة المطلوبة لتنفيذ كل معاملة). تُظهر الأدلة التجريبية مجموعة البيانات الكاملة هذه لكتلة Ethereum حديثة أن تكون على الأكثر بضع مئات من الكي بايت. في الوقت نفسه، إذا لم يتم ذلك بعد، فسيكون validator محاولة استرجاع المعلومات المتعلقة بانتقال الكتلة السابقة، مبدئيًا من الكتلة السابقة validators والإصدارات الأحدث من جميع validators الموقعة على توافر البيانات. بمجرد أن يتلقى validator كتلة المرشح هذه، ثم يقومون بالتحقق من صحتها محليًا. تم تضمين عملية التحقق من الصحة ضمن وحدة validator الخاصة بفئة الباراشين، أ وحدة برمجية حساسة للإجماع والتي يجب كتابتها لأي تنفيذ لـ Polkadot (على الرغم من أنه من حيث المبدأ يمكن للمكتبة التي تحتوي على C ABI تمكين مكتبة واحدة من ذلك أن تكون مشتركة بين التطبيقات مع المناسب انخفاض في السلامة يأتي من وجود تطبيق "مرجعي" واحد فقط). تأخذ العملية رأس الكتلة السابقة وتتحقق من هويتها من خلال سلسلة الترحيل المتفق عليها مؤخرًا الكتلة التي يجب تسجيل hash بها. بمجرد التأكد من صحة الرأس الأصلي، يتم استخدام سلسلة الباراشين المحددة يمكن استدعاء وظيفة التحقق من صحة الفصل. هذه وظيفة واحدة تقبل عددًا من حقول البيانات (تقريبًا تلك المقدمة سابقًا) وإرجاع قيمة منطقية بسيطة إعلان صلاحية الكتلة. ستقوم معظم وظائف التحقق هذه أولاً بالتحقق من حقول الرأس التي يمكن استخلاصها مباشرة من الكتلة الأصلية (على سبيل المثال الأصل hash، الرقم). متابعة هذا، وسوف يقومون بملء أي هياكل البيانات الداخلية كما ضرورية لمعالجة المعاملات و/أو المشاركات. بالنسبة لسلسلة تشبه Ethereum، فإن هذا يصل إلى ملء ملف حاول قاعدة البيانات مع العقد التي ستكون مطلوبة لـ التنفيذ الكامل للمعاملات. قد يكون هناك أنواع أخرى من السلسلة أخرى صآليات تعويضية. بمجرد الانتهاء من ذلك، ستكون منشورات الدخول والمعاملات الخارجية (أو ما تمثله البيانات الخارجية). سنت ومتوازنة وفقا لمواصفات السلسلة. (أ قد يكون الافتراضي المعقول هو المطالبة بجميع مشاركات الدخول تتم معالجتها قبل خدمة المعاملات الخارجية، ولكن هذا يجب أن يقرره منطق سلسلة المفاتيح.) من خلال هذا التشريع، سيتم إنشاء سلسلة من نقاط الخروج تم إنشاؤها وسيتم التحقق من تطابقها بالفعل مرشح المجمع. وأخيرا، المأهولة بالسكان بشكل صحيح سيتم فحص الرأس مقابل رأس المرشح. مع كتلة مرشح تم التحقق من صحتها بالكامل، validator يمكنه بعد ذلك التصويت لصالح hash لرأسه وإرسال كافة معلومات التحقق المطلوبة إلى المشاركين في validators في مجموعته الفرعية. 6.7.1. كولاتور باراشين. مُجمعو Parachain هم مشغلون غير مقيدين يقومون بمعظم مهام عمال المناجم على شبكات blockchain الحالية. فهي محددة إلى باراشين معين. لكي تعمل يجب عليهم الحفاظ على كل من سلسلة التتابع والمزامنة الكاملة المظلة. سيعتمد المعنى الدقيق لعبارة "متزامن بالكامل" على فئة سلسلة Parachain، على الرغم من أنه سيتضمن دائمًا الحالة الحالية لقائمة انتظار دخول سلسلة Parachain. في حالة Ethereum، يتضمن الأمر أيضًا الصيانة على الأقل قاعدة بيانات Merkle-tree للكتل القليلة الأخيرة، ولكن ربما تشمل أيضًا العديد من هياكل البيانات الأخرى بما في ذلك Bloom مرشحات لوجود الحساب والمعلومات العائلية والتسجيل المخرجات وجداول البحث العكسي لرقم الكتلة. بالإضافة إلى الحفاظ على تزامن السلسلتين، فإنه يجب أيضًا "البحث" عن المعاملات عن طريق الاحتفاظ بقائمة انتظار المعاملات وقبول المعاملات التي تم التحقق من صحتها بشكل صحيح من الشبكة العامة. مع قائمة الانتظار والسلسلة، هو عليه قادر على إنشاء كتل مرشحة جديدة لـ validators المختارة في كل كتلة (التي تعرف هويتها منذ مزامنة سلسلة التتابع) وإرسالها مع المعلومات المساعدة المختلفة مثل إثبات الصلاحية، عبر شبكة الأقران. ولمشكلتها، فإنها تقوم بجمع كافة الرسوم المتعلقة بالمعاملات التي تتضمنها. وتدور اقتصاديات مختلفة حول هذا الأمر الترتيب. في سوق تنافسية للغاية حيث هناك هو فائض من المجمعين، فمن الممكن أن الصفقة تتم مشاركة الرسوم مع سلسلة Parachain validators للتحفيز إدراج كتلة مجمعة معينة. بصورة مماثلة،
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 17 قد يقوم بعض المجمعين برفع الرسوم المطلوبة التي تحتاجها ليتم دفعها من أجل جعل الكتلة أكثر جاذبية ل validators. وفي هذه الحالة، يجب أن يتشكل سوق طبيعي مع المعاملات التي تدفع رسومًا أعلى تتخطى قائمة الانتظار وإدراجها بشكل أسرع في السلسلة. 6.8. الشبكات. التواصل على blockchains التقليدية مثل Ethereum وBitcoin لها متطلبات بسيطة إلى حد ما. يتم بث جميع المعاملات والكتل في ثرثرة بسيطة غير موجهة. التزامن أكثر مشاركة، على وجه الخصوص مع Ethereum ولكن في الواقع تم تضمين هذا المنطق في استراتيجية النظير بدلاً من البروتوكول نفسه الذي يتم حله حول عدد قليل من أنواع رسائل الطلب والإجابة. بينما أحرز Ethereum تقدمًا في عروض البروتوكول الحالية باستخدام بروتوكول devp2p، والذي سمح للكثيرين يتم مضاعفة البروتوكولات الفرعية عبر اتصال نظير واحد وبالتالي يكون لها نفس تراكب النظير الذي يدعم العديد من البروتوكولات الفرعية بروتوكولات p2p في وقت واحد، الجزء Ethereum من لا يزال البروتوكول بسيطًا نسبيًا ولا يزال بروتوكول p2p بروتوكول لفترة من الوقت لا يزال غير مكتمل مع المهم وظائف مفقودة مثل دعم جودة الخدمة. للأسف، هناك رغبة في إنشاء بروتوكول "ويب 3" أكثر انتشارًا إلى حد كبير فشل، والمشاريع الوحيدة التي تستخدمه هي تلك صراحة تم تمويله من عملية البيع الجماعي Ethereum. تعتبر متطلبات Polkadot أكثر أهمية. بدلاً من ذلك شبكة موحدة تمامًا، Polkadot لديه عدة أنواع من المشاركين لكل منهم متطلبات مختلفة فيما يتعلق بتركيبة أقرانهم والعديد من الشبكات "الطرق" التي يميل المشاركون إلى التحدث عنها بيانات معينة. وهذا يعني تراكب شبكة أكثر تنظيماً إلى حد كبير - وبروتوكول يدعم ذلك - من المرجح أن يكون ضروريا. علاوة على ذلك، قد تكون قابلية التوسعة لتسهيل الإضافات المستقبلية مثل الأنواع الجديدة من "السلسلة". تتطلب نفسها بنية تراكب جديدة. في حين مناقشة متعمقة لكيفية التواصل قد يبدو البروتوكول خارج نطاق هذه الوثيقة، إلا أن تحليل بعض المتطلبات معقول. نستطيع قم بتقسيم المشاركين في شبكتنا تقريبًا إلى مجموعتين (سلسلة التتابع، المظلات) كل من ثلاث مجموعات فرعية. نستطيع أذكر أيضًا أن كل من المشاركين في الباراشين هم فقط مهتمون بالتحدث فيما بينهم بدلاً من المشاركون في المظلات الأخرى: • المشاركون في سلسلة التتابع: • المصادقون: P، مقسمة إلى مجموعات فرعية P[s] لكل منها المظلة • الجهات الضامنة للتوفر: أ (قد يتم تمثيلها بواسطة جهات المصادقة في الشكل الأساسي للبروتوكول) • عملاء سلسلة الترحيل: م (ملاحظة أعضاء كل مجموعة المظلة سوف تميل أيضًا إلى أن تكون أعضاء M) • المشاركون في الباراشين: • مُجمّعات المظلات: C[0], C[1], . . . • صيادو المظلات: F[0], F[1], . . . • عملاء Parachain: S[0], S[1], . . . • عملاء المظلة الخفيفة: L[0]، L[1]، . . . بشكل عام، نقوم بتسمية فئات معينة من الاتصالات تميل إلى أن تتم بين أعضاء هذه المجموعات: • ف | أ <-> ف | ج: ال كامل مجموعة من validators/الضامنون يجب يكون على اتصال جيد ل تحقيق الإجماع. • P[s] <-> C[s] | P[s]: كل validator كعضو في مجموعة باراشين معينة سوف يميل إلى النميمة مع غيرهم من الأعضاء وكذلك المتعاونين من تلك المظلة لاكتشاف ومشاركة مرشحي الكتلة. • أ <-> P[s] | ج | ج: كل ضامن للتوافر سوف تحتاج إلى جمع سلسلة عبر سلسلة حساسة للإجماع البيانات من validators المخصصة لها؛ المجامع قد يؤدي أيضًا إلى تحسين فرصة التوصل إلى توافق في الآراء بشأنها قم بالحظر عن طريق الإعلان عنه أمام الجهات الضامنة للتوافر. بمجرد حصولهم عليها، سيتم صرف البيانات إلى ضامنون آخرون لتسهيل التوصل إلى توافق في الآراء. • P[s] <-> A | P[s']: المظلة validators سوف تحتاج إلى جمع بيانات إدخال إضافية من المجموعة السابقة من validators أو الجهات الضامنة للتوفر. • F[s] <-> P: عند الإبلاغ، يجوز للصيادين أن يضعوا مكانهم مطالبة مع أي مشارك. • م <-> م | ف | ج: يقوم عملاء سلسلة الترحيل العامة بتوزيع البيانات من validators والجهات الضامنة. • S[s] <-> S[s] | ص[ق] | ج: يقوم عملاء Parachain بتوزيع البيانات من validator/الضامنين. • L[s] <-> L[s] | S[s]: عملاء ضوء المظلة صرف البيانات من العملاء الكاملين. لضمان آلية نقل فعالة، "مسطحة" شبكة التراكب - مثل devp2p الخاص بـ Ethereum - حيث كل منها العقدة لا (بشكل غير تعسفي) تفرق بين صلاحيتها من غير المرجح أن يكون الأقران مناسبين. قابلة للتوسعة بشكل معقول من المحتمل أن تحتاج آلية اختيار الأقران واكتشافهم ليتم تضمينها في البروتوكول وكذلك العدوانية التخطيط للمستقبل لضمان النوع المناسب من الأقران هي "بالصدفة" conneCT في الوقت المناسب. ستكون الإستراتيجية الدقيقة لتكوين الأقران مختلفة لكل فئة من المشاركين: من أجل توسيع نطاقها بشكل صحيح متعددة السلاسل، سوف تحتاج المجمعات إما إلى أن تكون بشكل مستمر إعادة الاتصال بـ validators المنتخب وفقًا لذلك، أو سوف بحاجة إلى اتفاقيات مستمرة مع مجموعة فرعية من validators للتأكد من عدم فصلها خلال الغالبية العظمى من الوقت بحيث تكون غير مجدية لذلك validator. ومن الطبيعي أيضًا أن يحاول المُجمِّعون الحفاظ على واحدة أو اتصالات أكثر استقرارًا في ضامن التوفر تم تعيينها لضمان النشر السريع لتوافقها الحساس data. يهدف ضامنو التوفر في الغالب إلى الحفاظ على اتصال مستقر ببعضها البعض وبـ validators (للإجماع وبيانات الباراشين الحاسمة للإجماع التي يشهدون)، وكذلك لبعض المتعاونين (للباراشين البيانات) وبعض الصيادين والعملاء الكاملين (للتفريق المعلومات). سوف يميل المدققون إلى البحث عن validators أخرى، وخاصة تلك الموجودة في نفس المجموعة الفرعية وأي منها المقارنات التي يمكنها تزويدهم بمرشحات كتلة المظلات. الصيادين، فضلا عن سلسلة التتابع العامة والمظلة سيهدف العملاء عمومًا إلى إبقاء الاتصال مفتوحًا لـ validator أو الضامن، ولكن هناك الكثير من العقد الأخرى المشابهة لأنفسهم غير ذلك. سيهدف عملاء Parachain Light بالمثل إلى أن يكونوا متصلين بالعميل الكامل لـ Parachain، إن لم يكن فقط عملاء ضوء المظلة الآخرين. 6.8.1. مشكلة عنف الأقران. في مقترح البروتوكول الأساسي، تتغير كل مجموعة من هذه المجموعات الفرعية باستمرار بشكل عشوائي مع كل كتلة حيث تم تعيين validators للتحقق يتم اختيار التحولات المظلية بشكل عشوائي. هذا يمكن تكون مشكلة يجب أن تحتاج إليها العقد المتباينة (غير النظيرة). تمرير البيانات بين بعضها البعض. يجب على المرء إما الاعتماد على شبكة نظير موزعة إلى حد ما ومتصلة بشكل جيد
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 18 تأكد من أن مسافة القفزة (وبالتالي زمن الوصول في أسوأ الحالات) تنمو فقط مع لوغاريتم حجم الشبكة (قد يساعد البروتوكول المشابه لـ Kademlia [13] هنا)، أو لا بد من ذلك تقديم أوقات حظر أطول للسماح بإجراء مفاوضات الاتصال اللازمة للحفاظ على مجموعة نظير يعكس احتياجات الاتصال الحالية للعقدة. لا يعد أي من هذين الحلين رائعًا: أوقات الحظر الطويلة قد يؤدي فرضها على الشبكة إلى جعلها عديمة الفائدة تطبيقات وسلاسل معينة. حتى عادلة تماما والشبكة المتصلة ستؤدي إلى هدر كبير من عرض النطاق الترددي لأنه يتوسع بسبب وجود العقد غير المهتمة لإعادة توجيه البيانات غير المفيدة لهم. وفي حين أن كلا الاتجاهين قد يشكلان جزءاً من الحل، سيكون التحسين المعقول للمساعدة في تقليل زمن الوصول يكون لتقييد تقلبات هذه المظلات validator مجموعات، إما إعادة تعيين العضوية فقط بين سلسلة من الكتل (على سبيل المثال، في مجموعات مكونة من 15 شخصًا، والتي في 4 ثوانٍ وقت الحظر يعني تغيير الاتصالات مرة واحدة فقط في كل مرة دقيقة) أو عن طريق تناوب العضوية بطريقة تدريجية، على سبيل المثال. يتغير بواسطة عضو واحد في كل مرة (على سبيل المثال، إذا كان هناك تم تخصيص 15 validators لكل مظلة، ففي المتوسط ستكون دقيقة كاملة بين فريدة تمامًا مجموعات). من خلال الحد من مقدار تقلب الأقران، والتأكد من إجراء اتصالات مفيدة مع الأقران بشكل جيد التقدم من خلال القدرة على التنبؤ الجزئي للباراشين مجموعات، يمكننا المساعدة في ضمان احتفاظ كل عقدة بشكل دائم اختيار الصدفة من أقرانهم. 6.8.2. المسار إلى بروتوكول الشبكة الفعال. من المحتمل أن ستركز جهود التطوير الأكثر فعالية ومعقولة على استخدام بروتوكول موجود مسبقًا بدلاً من التدوير منطقتنا. توجد العديد من البروتوكولات الأساسية من نظير إلى نظير يجوز لنا استخدام أو تعزيز ما يتضمنه Ethereum من أدوات تطوير devp2p [22]، libp2p الخاص بـ IPFS [1] وGNUnet الخاص بـ GNU [4]. مراجعة كاملة لهذه البروتوكولات وأهميتها لبناء أ شبكة نظيرة معيارية تدعم ضمانات هيكلية معينة وتوجيه ديناميكي نظير وبروتوكولات فرعية قابلة للتوسيع يتجاوز نطاق هذه الوثيقة بكثير ولكنه سيكون بمثابة خطوة مهمة في تنفيذ Polkadot. 7. الجوانب العملية للبروتوكول 7.1. دفع المعاملات Interchain. بينما عظيم يتم اكتساب قدر من الحرية والبساطة من خلال إسقاط الحاجة إلى إطار شامل لمحاسبة الموارد الحسابية مثل غاز Ethereum، وهذا يثير سؤالًا مهمًا: بدون غاز، كيف يمكن لسلسلة واحدة أن تعمل تجنب Parachain آخر من إجبارها على القيام بالحساب؟ بينما يمكننا الاعتماد على قائمة انتظار الدخول بعد المعاملة المخازن المؤقتة لمنع إحدى السلاسل من إرسال بريد عشوائي إلى أخرى بيانات المعاملات، لا توجد آلية مكافئة يوفرها البروتوكول لمنع إرسال البريد العشوائي أثناء معالجة المعاملات. هذه مشكلة متروكة للمستوى الأعلى. منذ السلاسل لهم الحرية في إرفاق دلالات تعسفية بالوارد بيانات ما بعد المعاملة، يمكننا التأكد من أن الحساب يجب أن يتم دفع ثمنها قبل البدء. وعلى نفس المنوال النموذج الذي يتبناه Ethereum الصفاء، يمكننا أن نتخيله عقد "اقتحام" ضمن سلسلة Parachain يسمح بـ validator لضمان الدفع مقابل توفير حجم معين من موارد المعالجة. ويمكن قياس هذه الموارد بشيء مثل الغاز، ولكن يمكن أيضًا أن يكون نموذجًا جديدًا تمامًا مثل وقت التنفيذ الشخصي أو نموذج الرسوم الثابتة الذي يشبه Bitcoin. هذا في حد ذاته ليس مفيدًا جدًا لأننا لا نستطيع أن نفترض بسهولة أن المتصل خارج السلسلة متاح لهم مهما كانت آلية القيمة التي يتم التعرف عليها من خلال الاقتحام العقد. ومع ذلك، يمكننا أن نتخيل عقد "اختراق" ثانوي في سلسلة المصدر. سيشكل العقدان معًا جسرًا، يعترف كل منهما بالآخر توفير معادلة القيمة. (التكديس-tokens، متاح لـ يمكن استخدام كل منها لتسوية ميزان المدفوعات.) إن الاتصال بسلسلة أخرى من هذا القبيل يعني التوكيل من خلال هذا الجسر الذي من شأنه أن يوفر وسائل التفاوض على نقل القيمة بين السلاسل من أجل ادفع مقابل موارد الحساب المطلوبة في سلسلة Parachain الوجهة. 7.2. إضافية سلاسل. بينما ال إضافة من أ تعتبر عملية الباراشين عملية رخيصة نسبيًا، وليست مجانية. المزيد من المظلات يعني عددًا أقل من validators لكل مظلة وفي النهاية، عدد أكبر من validators لكل منها علامة انخفاض متوسط السندات. في حين يتم تخفيف مسألة تكلفة الإكراه الأصغر لمهاجمة سلسلة المظلة الصيادين، مجموعة validator المتنامية تجبر بشكل أساسي على أ درجة أعلى من الكمون بسبب آليات الإجماع الأساسيthod. علاوة على ذلك كل مظلة يجلب معه احتمالية الحزن validators بـ خوارزمية التحقق المرهقة. على هذا النحو، سيكون هناك بعض "السعر" الذي validators و/أو سيقوم مجتمع أصحاب المصلحة بالاستخراج من أجل إضافة مظلة جديدة. هذا السوق للسلاسل سوف ربما نرى إضافة إما: • السلاسل التي من المحتمل أن يكون صافي المساهمة فيها صفرًا (من حيث الحبس أو الحرق staking tokens) التي سيتم جعلها جزءًا (على سبيل المثال، سلاسل الكونسورتيوم، سلاسل دوجي، سلاسل خاصة بالتطبيق)؛ • السلاسل التي تقدم قيمة جوهرية للشبكة من خلال إضافة وظائف معينة صعبة للوصول إلى مكان آخر (على سبيل المثال، السرية، وقابلية التوسع الداخلي، وارتباطات الخدمة). في الأساس، سيحتاج مجتمع أصحاب المصلحة إلى ذلك سيتم تحفيزهم لإضافة سلاسل فرعية - إما ماليًا أو من خلال الرغبة في إضافة سلاسل مميزة إلى التتابع. ومن المتصور أن السلاسل الجديدة المضافة سيكون لها جدا فترة إشعار قصيرة للإزالة، مما يسمح بسلاسل جديدة يتم تجربتها دون أي خطر للمساومة عرض القيمة المتوسطة أو الطويلة الأجل. 8. الاستنتاج لقد حددنا الاتجاه الذي يمكن للمرء أن يتخذه للمؤلف أ بروتوكول متعدد السلاسل قابل للتطوير وغير متجانس مع إمكانية أن يكون متوافقًا مع الإصدارات السابقة لبعض البروتوكولات الموجودة مسبقًا blockchain الشبكات. وبموجب هذا البروتوكول، المشاركين العمل من أجل المصلحة الذاتية المستنيرة لإنشاء نظام شامل يمكن توسيعه بطريقة مجانية بشكل استثنائي ودون تكلفة نموذجية للمستخدمين الحاليين يأتي من تصميم قياسي blockchain. لقد قدمنا مخطط تقريبي للهندسة المعمارية التي ستستغرقها بما في ذلك طبيعة المشاركين وحوافزهم الاقتصادية والعمليات التي يجب أن يشاركوا فيها. لدينا حددت التصميم الأساسي وناقشت نقاط قوته و القيود؛ وفقا لذلك لدينا المزيد من التوجيهات التي قد يخفف هذه القيود ويؤدي إلى مزيد من التقدم نحو حل blockchain قابل للتطوير بالكامل.بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 19 8.1. المواد المفقودة والأسئلة المفتوحة. يعد تفرع الشبكة دائمًا احتمالًا من خلال التطبيقات المتباينة للبروتوكول. التعافي من مثل هذا لم تتم مناقشة حالة استثنائية. نظرًا لأن الشبكة سيكون لها بالضرورة فترة غير صفرية من الانتهاء، لا ينبغي أن يكون التعافي من تشعب سلسلة الترحيل مشكلة كبيرة، ولكنه سيتطلب دمجًا دقيقًا فيها بروتوكول الإجماع. وقد تم توفير مصادرة السندات والمكافأة على العكس من ذلك لم يتم استكشافها بعمق. في الوقت الحاضر نحن نفترض المكافآت يتم توفيرها على أساس أن الفائز يأخذ كل شيء: وهذا قد لا يكون كذلك تقديم أفضل نموذج تحفيزي للصيادين. ومن شأن عملية الكشف عن الالتزام قصيرة المدة أن تسمح للعديد من الصيادين للمطالبة بالجائزة مع توزيع أكثر عدالة للمكافآت، ومع ذلك، قد تؤدي هذه العملية إلى زمن انتقال إضافي في اكتشاف سوء السلوك. 8.2. شكر وتقدير. الشكر الجزيل لجميع المراجعين الذين ساعدوا في الحصول على هذا بشكل غامض شكل جيد. وعلى وجه الخصوص، بيتر تشابان، بيورن فاغنر، وكين كابلر، وروبرت هابرماير، وفيتاليك بوتيرين، وريتو ترينكلر، وجاك بيترسون. شكرا للجميع الأشخاص الذين ساهموا بالأفكار أو البدايات ولذلك يستحق ماريك كوتيويتز وإيرون بوكانان إشارة خاصة. والشكر للجميع على مساعدتهم على طول الطريق. كل الأخطاء هي بلدي. أجزاء من هذا العمل، بما في ذلك البحث الأولي في تم تمويل خوارزميات الإجماع جزئيًا من قبل البريطانيين الحكومة في إطار برنامج Innovate UK.
协议详细信息
该协议大致可以分为三部分 部分：共识机制、平行链接口 和链间交易路由。 6.1.中继链 操作。的 中继链 会 可能是一个与 Ethereum 大致相似的链，因为它 是基于状态的，将状态映射地址到帐户 信息，主要是余额和（防止重播） 交易柜台。在这里放置账户可以实现一个目的：提供身份所拥有的记账服务 系统中的权益数量是多少。7 不过，会有显着差异： • 合约不能通过交易来部署；由于希望避免中继链上的应用程序功能，因此不会 支持合约的公开部署。 • 不计算计算资源使用量（“gas”）； 因为唯一可供公众使用的功能 将被修复，天然气核算背后的基本原理 不再成立。因此，将收取固定费用 所有情况下，允许从任何情况下获得更多性能 可能需要完成的动态代码执行 以及更简单的交易格式。 • 列出的合约支持特殊功能，允许自动执行和网络消息输出。 如果中继链有一个虚拟机并且它是 基于 EVM，它将进行许多修改以确保最大程度的简单性。 很可能会 有许多内置合约（类似于 地址 Ethereum 中的 1-4）以允许特定于平台的 要管理的职责包括共识合同、 validator 合约和平行链合约。 如果不是 EVM，那么 WebAssembly [2] (wasm) 后端是最有可能的替代方案；在这种情况下总体 结构类似，但没有必要 以 Wasm 为可行目标的内置合约 适用于通用语言而不是不成熟的语言 以及 EVM 的有限语言。 与当前 Ethereum 协议的其他可能偏差也是很可能的，例如对 交易收据格式允许在同一块内并行执行非冲突交易， 正如针对 Serenity 系列变更所提议的那样。 尽管不太可能，但有可能出现类似宁静的情况 “纯”链被部署为中继链，允许 管理 staking token 等事物的特定合同 平衡而不是使其成为一个基本部分 链的协议。目前我们觉得这种可能性不大 将提供足够好的协议简化 值得承担额外的复杂性和不确定性 在开发它的过程中。 7作为代表特定持有人对系统整体安全负责的金额的一种方式，这些权益账户将 不可避免地编码了一些经济价值。然而，应该理解的是，由于无意将这些值用于 以任何方式交换现实世界的商品和服务，应相应注意的是 token 不能比作 货币和中继链保留了其关于应用的虚无主义哲学。Polkadot：异构多链框架的愿景 草案1 10 管理共识机制、validator 集、验证机制和平行链需要许多小功能。这些 可以在单一协议下一起实现。然而，出于模块化的原因，我们将这些描述为中继链的“合约”。这应该 被认为意味着它们是对象（在某种意义上 面向对象编程）由中继链的共识机制管理，但不一定 它们被定义为类似于 EVM 的操作码中的程序，也不 即使它们可以通过 帐户系统。 6.2.质押合约。该合约维护 validator 集。它管理： • 当前哪些帐户是validator； • 短期内可成为validators 通知； • 哪些账户已下注股权提名 validator； • 每个属性包括staking 数量、可接受的支付率和地址以及短期（会话）身份。 它允许帐户注册成为 保税 validator （及其要求），提名某些身份，并让先前存在的保税 validator 登记其退出此状态的愿望。它还 包括用于验证和规范化机制的机制本身。 6.2.1.股权-token 流动性。通常希望 拥有尽可能多的 staking token 总数 自从在网络维护操作中投入以来 这将网络安全与 staking token 的整体“市值”直接联系起来。这可以轻松地 通过货币膨胀并将收益分发给以 validators 身份参与的人来获得激励。然而，这样做会带来一个问题：如果 token 被锁在Stake合约中，受到减持惩罚，如何才能保留足够的大部分 流动性以便发现价格？ 对此的一个答案是允许直接的衍生品合约，在基础质押的 token 上确保可替代的 token。这很难以无信任的方式进行安排。 此外，这些衍生品 token 不能受到同等对待，原因与不同欧元区政府的债券不可互换的原因相同： 是标的资产失败并成为的机会 毫无价值。对于欧元区政府来说，可能会有 默认。通过 validator 质押 token，validator 可能会 做出恶意行为并受到惩罚。 遵循我们的原则，我们选择最简单的解决方案：并非所有 token 都被质押。这意味着 token 的一定比例（可能是 20%）将强制保持液态。尽管从安全角度来看这并不完美，但它不太可能对安全产生根本性的影响。 网络的安全； 80% 的债券没收赔偿仍可得到 与 100% staking 的“完美情况”相比。 通过反向拍卖机制可以相当简单地确定质押和流动 token 之间的比率。 本质上，token 持有者有兴趣成为 validator 每个人都会向 staking 合同发布一份报价，说明 他们需要采取的最低支付率 部分。 在每次会议开始时（会议将 定期发生，也许每小时一次） validator 槽位将根据每个潜在的 validator 的股份和支付率。一种可能的算法 因为这将是接受那些出价最低的人 所代表的股份不高于目标股份总额 除以插槽数量，且不低于该数量一半的下限。如果槽位无法填满， 下限可以通过某个因子反复减小以满足。 6.2.2.提名。可以不信任地提名 staking tokens 到活跃的 validator，给他们 validator 的职责。提名作品 通过批准投票系统。每个潜在提名人都可以向 staking 合约发布指令 表达一个或多个 validator 身份 他们准备将责任托付给他们。 每届会议，提名人的债券都被分散到 由一个或多个 validator 表示。分散算法针对一组 validator 的等效总数进行优化 债券。提名人的债券由 validator a 负责并获得利益或遭受 相应减轻处罚。 6.2.3.债券没收/烧毁。某些 validator 行为会导致其债券受到惩罚性减少。如果 债券减少到允许的最低限度以下， 会议提前结束，另一个会议开始。应受惩罚的 validator 不当行为的非详尽清单包括： • 作为平行链团体的一部分，无法提供 对平行链区块有效性的共识； • 主动签署无效的有效性 平行链区块； • 之前无法提供出口有效负载 投票为可用； • 在共识过程中不活动； • 验证竞争分叉上的中继链区块。 某些不当行为会威胁到网络的完整性（例如签署无效的平行链区块和验证分叉的多个侧面），并因此通过债券的总量减少而导致有效的流放。在 其他不太严重的情况（例如，共识中不活跃） 过程）或无法精确分配责任的情况（作为无效群体的一部分），一小部分 债券的金额可能会被罚款。在后一种情况下，这 与子组流失配合良好，以确保恶意 节点遭受的损失比附带损坏的仁慈节点要大得多。 在某些情况下（例如多分叉验证和无效 子块签名）validators 本身无法轻易检测到彼此的不当行为，因为不断进行验证 分析每个平行链区块的任务太艰巨了。这里 需要争取外部各方的支持 验证和报告此类不当行为的验证过程。当事人因举报此类活动而获得奖励；他们的术语“渔民”源于不可能 的这样的奖励。 由于这些案件通常非常严重，我们预计任何奖励都可以轻松地从没收的债券中支付。 一般来说，我们更喜欢平衡燃烧 （即减少到零）通过重新分配，而不是 尝试大规模重新分配。这有以下效果：
Polkadot：异构多链框架的愿景 草案1 11 增加 token 的整体价值，补偿 在某种程度上，网络是一般性的，而不是特定的 参与发现的一方。 这主要是为了安全 机制：如果涉及的金额很大，可能会导致极端和剧烈的行为激励 授予单一目标。 一般来说，重要的是奖励足够大以使网络验证值得，但又不能大到抵消正面验证的成本。 资金充足、精心策划的“工业级”犯罪 对一些不幸的 validator 进行黑客攻击，以强制其行为不当。 这样一来，索赔的金额一般应该是没有的 大于错误 validator 的直接键，以免 行为不端和举报自己以获得赏金会产生不正当的激励。这可以明确地解决 通过最低直接债券要求成为 validator 或通过教育提名人隐含地表明，存入少量债券的 validator 没有很大的激励 表现良好。 6.3.平行链注册表。每个平行链的定义如下 这个注册表。它是一个相对简单的类似数据库的结构，并且保存静态和动态信息 每条链。 静态信息包括链索引（一个简单的 整数），以及验证协议身份， 区分不同类别的方法 平行链，以便可以使用正确的验证算法 由 validators 运行，负责提出有效的候选人。最初的概念验证将侧重于放置 将新的验证算法引入客户端本身，实际上每次都需要对协议进行硬分叉 添加了额外的链条类别。但最终， 可以在中指定验证算法 一种既严格又有效的方式，让客户 能够有效地使用新的平行链，而无需 硬分叉。一种可能的途径是指定 平行链验证算法采用完善的、 本机编译的、平台中立的语言，例如 WebAssembly。需要额外的研究来确定 这是否真的可行，但如果是的话，它可能会带来 随之而来的是消除硬分叉的巨大优势 永远。 动态信息包括交易路由系统的各个方面，这些系统必须具有全局协议，例如 作为平行链的入口队列（第 6.6 节中描述）。 注册表只能添加平行链 通过全民公决投票；这是可以管理的 内部，但更可能被放置在外部 公投合同，以促进重新使用 更一般的治理组件。参数为 投票要求（例如所需的任何法定人数、多数票 需要）用于注册附加链和其他， 不太正式的系统升级将在“主版本”中列出 宪法”，但很可能遵循相当传统的 路径，至少最初是这样。精确的公式是由 当前工作的范围，但是例如三分之二的绝对多数通过，超过整个系统的三分之一 积极投票可能是一个明智的起点。 其他操作包括暂停和删除平行链。 希望永远不会被暂停 发生，但它的设计目的是最少的保障 平行链的验证系统中存在一些棘手的问题。最明显的例子可能是 需要的是导致 validators 无法达成一致的实现之间的共识关键差异 有效性或块。鼓励验证者使用 多个客户端实现，以便他们能够 在没收债券之前发现此类问题。 由于暂停是紧急措施，因此 在动态 validator 投票的支持下 比公投。两者都可以恢复 来自 validators 或公投。 完全删除平行链只会发生 公投后，需要 相当长的宽限期，以允许有序过渡 要么是一个独立的链，要么成为其他链的一部分 共识系统。 宽限期可能是 几个月的顺序，并且可能会在平行链注册表中以每个链为基础进行设置，以便不同的 平行链可以根据情况享受不同的宽限期 他们的需要。 6.4.密封继电器块。密封本质上是指， 规范化过程；也就是一个基本数据 变换哪个将原作映射为根本上独特且有意义的东西。在 PoW 链下， 密封实际上是采矿的同义词。在我们的例子中， 它涉及收集 validators 就某项的有效性、可用性和规范性签署的声明 特定的中继链区块和平行链区块 它代表。 底层 BFT 共识算法的机制超出了当前工作的范围。 我们会 相反，使用原语来描述它，该原语假设 创造共识的状态机。最终我们期望 受到许多有希望的 BFT 共识的启发 核心算法； Tangaora [9] （BFT 变体 Raft [16])、Tendermint [11] 和 HoneyBadgerBFT [14]。 该算法必须并行地在多个平行链上达成一致，因此与通常的算法不同 blockchain 共识机制。我们假设有一次 达成共识，我们可以记录共识 任何人都可以提供无可辩驳的证据 其参与者。我们还假设不当行为 协议内通常可以减少到一个小的 包含行为不端的参与者的小组，以尽量减少 实施惩罚时的附带损害。8 证明采用我们签名声明的形式，一起放置在中继链区块的标头中 某些其他字段，尤其是中继链的状态树根和交易树根。 的 密封 过程 需要 地方 下 一个 单身 达成共识 机制 寻址 两者 的 中继链的区块和平行链的区块使得 转发部分内容：平行链不是由其子组单独“提交”然后整理的 稍后。这导致中继链的过程更加复杂，但允许我们在一个阶段完成整个系统的共识，最大限度地减少延迟并允许 对于相当复杂的数据可用性要求 对下面的路由过程有帮助。 8现有的基于 PoS 的 BFT 共识方案（例如 Tendermint BFT 和原始的 Slasher）满足了这些断言。
Polkadot：异构多链框架的愿景 草案1 12 每个参与者共识机的状态可能 被建模为一个简单的（二维）表。每个参与者 (validator) 都有一组信息，格式为 来自其他参与者的关于每个平行链候选块以及中继链候选块的签名声明（“投票”）。该组信息有两部分 数据： 可用性： 确实 这个 validator 有 出口 来自该块的交易发布信息 他们能够在下一个区块上正确验证平行链候选者吗？他们可能会投票 1（已知）或 0（未知）。一旦他们 投票 1，他们承诺同样投票给 这个过程的其余部分。后来的投票没有 尊重这一点是惩罚的理由。 有效性：平行链区块是否有效，是否全部 外部参考数据（例如 交易） 可用吗？这仅与分配给其投票的平行链的 validator 相关。 他们可以投票 1（有效）、-1（无效）或 0 （尚不清楚）。一旦他们投票非零，他们 致力于以这种方式为其余的人投票 的过程。后来的投票不尊重这一点 是惩罚的理由。 所有 validator 必须提交投票；符合上述规则的投票可以重新提交。的进展 共识可以建模为并行发生的每个平行链上的多个标准 BFT 共识算法。由于这些可能会受到相对 少数恶意行为者集中在 单个平行链组，存在总体共识 建立后盾，限制最坏情况的发生 死锁仅限于一个或多个无效平行链区块（以及 对相关责任人进行一轮处罚）。 The basic rules for validity of the individual blocks （这使得 validator 的总集合作为一个整体来达到 一致认为它成为唯一的平行链候选者 从规范继电器中引用）： • 必须有至少三分之二的validator 投票赞成，且无投票反对； • 必须有超过三分之一的validator 对出口队列信息的可用性进行积极投票。 如果对有效性有至少一票赞成票和至少一票反对票，则创建特殊条件 并且整个 validator 集合必须投票决定 如有恶意或意外 叉子。除了有效票和无效票之外，还有第三种票 被允许，相当于投票给两者，这意味着 节点有相互矛盾的意见。这可能是由于 节点的所有者运行多个实现，这些实现 not agree, indicating a possible ambiguity in the protocol. 从完整的 validator 集中计算所有选票后，如果 失败的意见至少有一小部分（到 被参数化；最多一半，也许少得多） 获胜意见的票数，那么假设 be an accidental parachain fork and the parachain is automatically suspended from the consensus process. Otherwise, we assume it is a malicious act and punish the minority who were voting for the dissenting opinion. The conclusion is a set of signatures demonstrating 规范性。然后可以密封中继链区块 并开始密封下一个区块的过程。 6.5.密封继电器块的改进。同时 this sealing method gives strong guarantees over the system’s operation, it does not scale out particularly well 因为每条平行链的关键信息都必须有其 availability guaranteed by over one-third of all validators. This means that every validator’s responsibility footprint 随着更多连锁店的添加而增长。 While data availability within open consensus networks 本质上是一个未解决的问题，有一些方法可以减轻 validator 节点上的开销。一个简单的 solution is to realise that while validators must shoulder the responsibility for data availability, they need not actually store, communicate or replicate the data themselves. Secondary data silos, possibly related to (or even the very same) collators who compile this data, may manage the task of guaranteeing availability with the validators providing a portion of their interest/income in payment. However, while this might buy some intermediate scalability, it still doesn’t help the underlying problem;自从 添加更多链通常需要额外的 validators，持续的网络资源消耗（特别是在带宽方面）随着 的链条，从长远来看是难以维持的财产。 最终，我们可能会不断地摇头 反对基本限制，即 一个被认为可用安全的共识网络， 持续的带宽需求是总带宽的数量级 validators 次输入信息总量。这是由于 不受信任的网络无法在许多节点之间正确分配数据存储任务，这就是 除了明显可分配的处理任务之外。 6.5.1.引入延迟。软化这种情况的一种方法 规则是放松即时性的概念。 通过仅最终而不是立即要求 33%+1 validators 对可用性进行投票，我们可以更好地利用指数数据传播并帮助平衡数据交换的峰值。 合理的平等（尽管未经证实） 可能是： (1) 延迟=参与者×链 在当前模型下，系统规模可扩展 与链的数量，以确保处理是 分布式；因为每个链至少需要一个 validator 并且我们将可用性证明固定为一个常量 validators 的比例，那么参与者同样会增长 与链的数量。我们最终得到： (2) 延迟 = 大小2 这意味着随着系统的增长，整个系统都知道可用性所需的带宽和延迟 网络，也可以表征为数字 最终确定之前的区块数量随其平方增加。这是 一个重要的增长因素，可能会成为一个显着的障碍，迫使我们进入“非扁平”范式 比如将几个“Polkadotes”组成一个层次结构 用于通过中继链树对帖子进行多级路由。
Polkadot：异构多链框架的愿景 草案1 13 6.5.2.公众参与。又一个可能的方向 是通过一种方式让公众参与这一过程 微投诉系统。和渔民一样， 可能是外部人士对声称的 validator 进行监管 可用性。 他们的任务是找到一个似乎无法表现出这种可用性的人。 在这样做的过程中，他们 可以向其他 validator 提出微投诉。工作量证明或 质押债券可用于减轻女巫攻击 这将使该系统基本上毫无用处。 6.5.3.可用性保证人。最终路线是 指定第二组保税 validator 作为“可用性” 担保人”。这些将像普通的 validator 一样进行绑定，甚至可以取自同一组 （尽管如果是这样，他们将在长期内被选择，至少在每次会议中）。与正常的 validator 不同，它们 不会在平行链之间切换，而是会 组成一个小组来证明所有重要的链间数据的可用性。 这样做的好处是放宽了参与者和链之间的等价性。 本质上，链条可以 增长（与原始链 validator 集一起），而 参与者，特别是那些参与数据可用性测试的人，可以至少保持亚线性 并且很可能是恒定的。 6.5.4.校对者偏好。这其中的一个重要方面 系统的目的是确保有一个健康的选择 整理者在任何给定的平行链中创建区块。如果一个 单个整理者主导了一条平行链，然后发生了一些攻击 变得更加可行，因为缺乏的可能性 外部数据的可用性不太明显。 一种选择是对平行链区块进行人工加权 一种伪随机机制，以支持各种整理者。在第一种情况下，我们需要 作为 validator 青睐的共识机制的一部分 平行链候选区块被确定为“更重”。 同样，我们必须激励 validators 尝试 建议他们能找到的最重的块——这可能是 通过将一部分奖励与候选人的体重成比例来完成。 确保给予整理者合理的公平 他们的候选人被选为获胜者的机会 在协商一致的候选人中，我们给出了一个特定的权重 平行链区块候选由与每个收集者连接的随机函数确定。 例如，采取 整理者地址之间的 XOR 距离度量 和一些加密安全的伪随机数 确定在靠近正在创建的块的点处 （名义上的“中奖彩票”）。这有效地为每个 整理者（或者更具体地说，每个整理者的地址） 他们的候选区块“获胜”的随机机会 所有其他人。 为了减轻单个核对者“挖掘”靠近中奖彩票的地址的女巫攻击，从而 对于每个最喜欢的块，我们都会为整理者的地址添加一些惯性。这可能就像要求他们一样简单 地址中有基准资金量。一个更多 优雅的方法是权衡与 中奖彩票的金额与停放在 有问题的地址。虽然模型还没有完成， 这种机制很可能甚至可以使非常 小利益相关者作为整理者做出贡献。 6.5.5。超重块。如果 validator 集合受到损害，他们可能会创建并提出一个块，尽管 有效，需要大量时间来执行并且 验证。这是一个问题，因为 validator 组可能 合理地形成一个块需要很长时间 执行，除非已知某些特定信息，允许走捷径，例如因式分解大 总理。 如果单个整理者知道该信息，那么 他们在拥有自己的产品方面将拥有明显的优势 只要其他人忙于处理旧区块，候选人就会接受。我们称这些块为超重。 针对 validator 提交和验证这些块的保护很大程度上与 无效块，但有一个额外的警告：因为 执行一个块所花费的时间（因此它的状态为 超重）是主观的，投票的最终结果 不当行为基本上可分为三个阵营。一 可能性是该块绝对没有超重—— 在这种情况下，超过三分之二的人宣称他们可以 在一定限制内执行块（例如块之间允许的总时间的 50%）。 另一个是 块是d绝对超重——如果超过 三分之二的人声明他们无法执行该块 在上述限度内。 最后一种可能性是相当平等的 validator 之间存在意见分歧。在这种情况下，我们可以 选择做一些相应的惩罚。 确保 validators 能够预测它们何时会出现 提议超重区块时，要求他们发布每个区块的性能信息可能是明智的。在足够长的时间内， 这应该允许他们分析他们的处理速度 相对于评判他们的同行。 6.5.6。整理者保险。 validators 仍存在一个问题： 与 PoW 网络不同，检查整理者的 为了保证区块的有效性，他们必须实际执行其中的交易。恶意整理者可以向 validator 提供无效或超重的块，导致他们悲伤（浪费 他们的资源）并要求潜在的巨大机会成本。 为了缓解这个问题，我们提出了一个简单的策略 validators 的一部分。首先，平行链候选区块发送 至 validators 必须由中继链账户签名 有资金；如果不是，那么 validator 应该下降 立即吧。其次，这些候选者应该通过组合（例如乘法）进行优先排序 帐户中的资金金额达到一定上限， 整理者过去成功提议的先前区块的数量（更不用说任何先前的区块） 惩罚），以及与获胜者的接近因素 如前所述。帽子应该是一样的 作为本案中向 validator 支付的惩罚性赔偿 其中发送了无效块。 为了阻止整理者向 validator 发送无效或超重的区块候选者，任何 validator 都可以 在下一个区块中放置一项交易，其中包括涉嫌不当行为的违规区块，其结果是转移行为不当的整理者的部分或全部资金 向受害人 validator 负责。 这种类型的交易优先于任何其他交易，以确保整理者无法 在处罚前移走资金。金额 作为损害赔偿转移的资金仍是一个动态参数
Polkadot：异构多链框架的愿景 草案1 14 进行建模，但可能是 validator 区块奖励的一部分，以反映造成的悲伤程度。至 为了防止恶意 validator 任意没收整理者的资金，整理者可以对 validator 的决定提出上诉，并由随机选择的 validator 组成的陪审团作为回报 用于存入小额存款。 如果他们发现 validator 对他们有利，则押金将被他们消耗。如果没有，则 押金被退回，validator 被罚款（因为 validator 处于更加拱形的位置，罚款将 可能相当重）。 6.6.跨链 交易 路由。跨链 交易路由是必不可少的维护之一 中继链及其 validator 的任务。 这是 控制已发布交易（通常简称为“发布”）如何成为所需输出的逻辑 从一个源平行链到成为另一个目标平行链的不可协商的输入，无需任何信任 要求。 我们仔细选择了上面的措辞；尤其是我们 不要求源中存在交易 平行链明确批准了这篇文章。唯一的 我们对模型施加的约束是平行链 必须提供，打包为整体块的一部分 处理输出，帖子是结果 块的执行。 这些帖子被构造为几个 FIFO 队列；的 列表的数量称为路由基础，可以是 16 左右。值得注意的是，这个数字代表的是数量 我们无需求助即可支持的平行链数量 多阶段路由。最初，Polkadot 将支持此 一种直接路由，但是我们将概述一种可能的 多阶段路由过程（“超级路由”）作为一种手段 远远超出最初的一组平行链。 我们 假设 那个 全部 参与者 知道 的 接下来的两个块 n, n + 1 的子组。总而言之， 路由系统遵循以下阶段： • CollatorS：验证者的联系成员[n][S] • 整理者：对于每个子组：确保 至少 1 名 V 验证者[n][s] 成员保持联系 • 整理者： 对于每个子组： 假设 egress[n −1][s][S] 可用（所有传入帖子 数据从最后一个块到“S”） • 整理者： 为 S 构建候选块 b： （b.标头、b.ext、b.proof、b.receipt、b.egress） • 整理者： 发送 证明 信息 证明[S] = (b.header, b.ext, b.proof, b.receipt) 到 验证器[n][S] • CollatorS：确保外部交易数据b.ext 可供其他整理者和 validators 使用 • 整理者： 为 每个 子群 s: 发送 出口 信息 出口[n][S][s] = （b.标头、b.收据、b.出口[s]） 到 的 接收 子组的 会员 的 下一个 块 验证器[n + 1][s] • ValidatorV：预连接所有同组成员 对于下一个块：让 N = Chain[n + 1][V ];连接 所有 validators v 使得 Chain[n + 1][v] = N • 验证器V： 为此整理所有数据入口 块： 为 每个 子群 s: 检索 egress[n −1][s][Chain[n][V ]]，从其他 validators v 获取，使得 Chain[n][v] = Chain[n][V ]。 可能会通过随机选择的其他 validator 作为尝试证明。 • 验证器V： 接受候选人的证明 区块证明[Chain[n][V]]。投票块有效性 • 验证器V： 接受候选出口数据 下一个块： 对于每个子组，接受 出口[n][s][N]。投票区块出口可用性；在感兴趣的 validators v 中重新发布，以便 链[n + 1][v] = 链[n + 1][V ]。 • 验证器V：直到达成共识 其中： egress[n][from][to] 是当前的出口队列 从平行链‘from’到的帖子信息 平行链“to”位于区块号“n”中。 CollatorS 是平行链 S 的整理者。Validators[n][s] 是区块编号 n 处平行链 s 的 validators 集合。相反， Chain[n][v] 是在区块号 n 上分配 validator v 的平行链。 block.egress[to] 是出口 来自某个平行链区块的帖子队列，其 目的地平行链是 to。 由于整理者收取（交易）费用是基于 他们的区块成为规范，他们受到激励 确保对于每个下一个块目的地，子组的 成员被告知当前的出口队列 块。验证者只会被激励在（平行链）区块上达成共识，因此他们很少关心 哪个整理者的区块最终成为规范。在 原则上，validator 可以与整理者结盟，并合谋减少其他整理者的机会 区块成为规范，但这都很困难 由于随机选择而安排validators 的作用 平行链，并且可以通过减少维持平行链区块的应付费用来防御 共识过程。 6.6.1.外部数据可用性。确保平行链的 外部数据实际上可用是一个长期存在的问题 去中心化系统旨在将工作负载分配给 网络。问题的核心是可用性 问题指出，因为不可能 进行非交互式可用性证明或任何类型的证明 不可用性的证明，以便 BFT 系统正确地 验证其正确性依赖于的任何转换 一些外部数据的可用性，最大数量 系统中可接受的拜占庭节点数，再加上一个 必须证明数据可用。 对于正确扩展的系统，例如 Polkadot，这 引发一个问题：如果 validators 的比例恒定 必须证明数据的可用性，并假设 validators 在断言数据可用之前想要实际存储数据，那么我们如何避免 带宽/存储需求随着系统规模（以及 validator 数量）的增加而增加的问题？一个可能的答案是拥有一套单独的 validators（可用性保证人），其订单不断增长 与 Polkadot 的整体大小呈次线性关系。这是 6.5.3 中描述。 我们还有第二个技巧。 作为一个群体，整理者有一种内在的动机来确保所有数据都是正确的 可用于他们选择的平行链，因为没有它他们 无法创作更多的区块 收取交易费用。收集者也形成一个团体，其成员是多种多样的（由于随机性） 平行链 validator 组）的输入并不简单且简单
Polkadot：异构多链框架的愿景 草案1 15 来证明。因此，最近的整理者（也许是最后几千个区块）被允许向 特定平行链的外部数据的可用性 阻止 validators 以获得少量债券。 验证者必须联系那些来自明显违规的 validator 小组的作证者，要么获取数据并将其返回给整理者，要么升级 通过证明缺乏可用性来解决问题（直接拒绝提供数据将被视为没收债券的罪行，因此行为不当的 validator 可能只是 断开连接）并联系其他 validators 运行相同的测试。在后一种情况下，整理人的保证金 被返回。 一旦达到可以做出此类不可用性证明的 validator 的法定人数，他们就会被释放， 行为不当的子组会受到惩罚，并且区块会被恢复。 6.6.2.帖子路由。每个平行链标头都包含一个 出口特里树根；这是包含以下内容的 trie 的根 路由基础 bin，每个 bin 都是一个串联列表 出口职位。 Merkle 证明可以跨 平行链 validators 来证明特定平行链的 区块对于特定的目标平行链有一个特定的出口队列。 在处理平行链区块开始时，每个 其他平行链的出口队列绑定到该块是 合并到我们块的入口队列中。我们假设强， 可能是 CSPR9，子块排序以实现确定性操作，在任何操作之间都没有偏袒 平行链区块配对。整理者计算新队列 并根据平行链排出出口队列 逻辑。 显式写入入口队列的内容 进入平行链区块。 这样做有两个主要目的： 首先，这意味着平行链可以与其他平行链隔离地进行无需信任的同步。其次， 它简化了整个入口的数据逻辑 队列无法在单个块中处理； validators 和整理者能够处理以下块 无需专门获取队列的数据。 如果平行链的入口队列高于阈值 块处理结束时的金额，然后对其进行标记 中继链饱和，无法再发送任何消息 交付给它，直到它被清除为止。 默克尔证明是 用于证明整理者操作的保真度 平行链区块的证明。 6.6.3.批判。与此基本相关的一个小缺陷 机制是炸弹后攻击。 这就是所有 平行链发送尽可能多的帖子 到特定的平行链。虽然这会限制目标的 立即进入队列，不会造成任何损坏 标准事务 DoS 攻击。 运行正常，具有一组良好同步和 非恶意收集者和 validators，对于 N 个平行链， 每个平行链共有 N × M validator 和 L 个整理者，我们 可以将每个块的总数据路径分解为： 验证者：M −1+L+L：其他 validator 为 M −1 在平行链集合中，L 代表每个提供候选平行链区块的收集者，第二个 L 代表每个收集者 下一个块需要前一个块的出口有效负载。 （后者实际上更像是最坏情况 操作，因为整理者很可能会共享此类 数据。） Collator: M +kN: M 用于连接到每个相关的 平行链块 validator，kN 用于将出口有效负载播种到每个平行链 validator 组的某个子集 下一个区块（可能还有一些受青睐的整理者）。 因此，每个节点的数据路径呈线性增长 与系统的整体复杂性。虽然这是 合理的，当系统扩展到数百或数千条平行链时，可能会出现一些通信延迟 吸收以换取较低的复杂性增长率。 在这种情况下，可以使用多阶段路由算法 为了减少瞬时路径的数量 以引入存储缓冲区和延迟为代价。 6.6.4.超立方体路由。超立方体路由是一种机制，主要可以作为对 基本路由机制如上所述。 本质上， 我们不是通过平行链和子组节点的数量来增加节点连接性，而是仅通过 平行链的对数。帖子可能会在以下之间传输 几个平行链的队列正在等待最终交付。 路由本身是确定性的且简单的。我们从 限制入口/出口队列中的垃圾箱数量； 它们不是平行链的总数，而是 是路由基础 (b) 。这将被固定为数字 平行链的数量发生了变化，路由指数 (e) 反而被提高。在这个模型下，我们的消息量 随着 O(be) 增长，路径保持不变 和延迟（或交付所需的块数） 与 O(e)。 我们的路由模型是 e 维的超立方体， 立方体的每一面都有 b 个可能的位置。 每个块，我们沿着单个轴路由消息。我们 以循环方式交替轴，从而保证 e 块在最坏情况下的交付时间。 作为平行链处理的一部分，国外绑定 在入口队列中找到的消息将立即路由到适当的出口队列的容器，给定 当前块号（以及路由尺寸）。这个 过程需要为每一跳进行额外的数据传输 在送货路线上，但这本身就是一个问题 可以通过使用一些替代方法来缓解 数据有效负载传输并且仅包括参考， 而不是 post-trie 中帖子的完整有效负载。 此类系统超立方体路由的示例 对于 4 个平行链，b = 2 且 e = 2 可能是： 阶段 0，在每条消息 M 上： • sub0: 如果 Mdest ∈{2, 3} 则 sendTo(2) 否则保留 • sub1: 如果 Mdest ∈{2, 3} 则 sendTo(3) 否则保留 • sub2：如果 Mdest ∈{0, 1} 则 sendTo(0)，否则保留 • sub3：如果 Mdest ∈{0, 1} 则 sendTo(1)，否则保留 第 1 阶段，在每条消息 M 上： • sub0：如果 Mdest ∈{1, 3} 则 sendTo(1)，否则保留 • sub1：如果 Mdest ∈{0, 2} 则 sendTo(0)，否则保留 • sub2：如果 Mdest ∈{1, 3} 则 sendTo(3)，否则保留 • sub3：如果 Mdest ∈{0, 2} 则 sendTo(2)，否则保留 这里的两个维度很容易看出，就像第一个维度一样 目标索引的两位；对于第一个块， 单独使用高阶位。 第二块交易 与低位。一旦两者都发生（任意 order）然后帖子将被路由。 9加密安全的伪随机
Polkadot：异构多链框架的愿景 草案1 16 6.6.5。最大化偶然性。基本的一处改动 提案将看到 c2 −c validators 的固定总数，其中 每个子组中有 c−1 validators。每个块，而不是 validators 存在非结构化重新分区 在平行链之间，而不是对于每个平行链子组， 每个 validator 将被分配给一个唯一且不同的 以下区块上的平行链子组。这会 导致任意两个块之间的不变性，对于任意 两对平行链，存在两个 validator 交换了平行链的职责。虽然这不能用于获得可用性的绝对保证 （单个 validator 有时会掉线，即使 仁慈的），但它仍然可以优化一般情况。 这种方法并非没有并发症。添加平行链也需要进行重组 validator 组的。此外，validator 的数量与平行链数量的平方相关， 最初会很小，最终会长得很远 太快了，大约 50 个平行链后就变得难以维持。 这些都不是根本问题。在第一种情况下， validator 集的重组是必须的 无论如何，定期进行。关于 validator 的大小 设置，当太小时，可能会分配多个 validator 对于同一个平行链，将整数因子应用于 总计 validators。 6.6.4 中讨论的多阶段路由机制（例如超立方路由）将 减轻对大量 validator 的要求 当链条数量较多时。 6.7.平行链验证。 validator 的主要目的 是作为一个关系良好的参与者来证明平行链的 区块有效，包括但不限于任何状态转换、任何外部交易、执行 入口队列中的任何等待帖子和最终状态 出口队列的。 这个过程本身相当简单。 一旦 validator 密封了前一个区块，它们就自由了 开始努力提供候选平行链区块 下一轮共识的候选人。 最初，validator 通过平行链整理器（如下所述）或一个找到平行链区块候选者 其共同validators。平行链区块候选数据 包括块的标头、前一个块的标头， 包括任何外部输入数据（对于 Ethereum 和 Bitcoin，此类数据将被称为事务，但原则上它们可以包括用于任意目的的任意数据结构）、出口队列数据和内部数据以证明状态转换有效性（对于 Ethereum 这将是执行每个事务所需的各种状态/存储特里节点）。 实验证据显示了最近 Ethereum 区块的完整数据集 最多几百 KiB。 同时，如果尚未完成，validator 将是 尝试检索与前一个块的转换有关的信息，最初是从前一个块的 validators 及之后所有 validators 签署 数据的可用性。 一旦 validator 收到这样的候选块， 然后他们在本地验证它。验证过程包含在平行链类的 validator 模块中， 必须编写的共识敏感软件模块 对于 Polkadot 的任何实现（尽管原则上 具有 C ABI 的库可以使单个库能够 与适当的实现之间共享 由于只有一个“参考”实施而导致安全性降低）。 该过程获取前一个块的标头并通过最近商定的中继链验证其身份 应记录其 hash 的块。一旦确定了父标头的有效性，特定的平行链 可以调用类的验证函数。这是一个接受多个数据字段（大致为 那些之前给出的）并返回一个简单的布尔值 宣告区块的有效性。 大多数此类验证函数将首先检查 可以直接派生的头字段 父块（例如父块 hash，编号）。正在关注 这样，他们将填充任何内部数据结构 处理交易和/或过账所必需的。 对于类似 Ethereum 的链，这相当于填充 包含所需节点的 trie 数据库 交易的全面执行。其他链条类型可能有 其他p修复机制。 完成后，入口帖子和外部交易（或外部数据代表的任何内容）将被 根据链的规范制定、平衡。 （一 明智的默认设置可能是要求所有入口帖子 在提供外部交易服务之前进行处理，但这应该由平行链的逻辑来决定。） 通过这项立法，一系列出口岗位将被 创建并且将验证它们确实匹配 整理者的候选人。最后，正确填充 标题将与候选人的标题进行检查。 有了经过充分验证的候选块，validator 然后可以对其标头的 hash 进行投票，并将所有必需的验证信息发送到其子组中的 co-validator。 6.7.1.平行链整理者。平行链整理者是无约束的运营商，他们完成了矿工的大部分任务 在当今的 blockchain 网络上。它们是具体的 到特定的平行链。为了运作，他们必须 保持中继链和完全同步 平行链。 “完全同步”的确切含义将取决于平行链的类别，但始终包括平行链入口队列的当前状态。 在 Ethereum 的情况下，它还至少涉及维护 最后几个区块的默克尔树数据库，但可能 还包括各种其他数据结构，包括 Bloom 过滤帐户存在、家庭信息、日志记录 块号的输出和反向查找表。 除了保持两条链同步之外，它 还必须通过维护交易队列并接受经过正确验证的交易来“钓鱼”交易 来自公共网络。有了队列和链，就是 能够为每个区块选择的 validator 创建新的候选区块（由于中继链已同步，其身份是已知的），并将它们与 各种辅助信息，例如有效性证明，通过 对等网络。 为了避免麻烦，它收取与其所包含的交易相关的所有费用。各种经济学都围绕这个展开 安排。在竞争激烈的市场中 整理者有剩余，有可能交易 与平行链 validators 共享费用以激励 包含特定整理者的块。 相似地，
Polkadot：异构多链框架的愿景 草案1 17 号 一些整理者甚至可能会提高所需的费用 为了使该区块更具吸引力而支付 validators。 在这种情况下，就应该形成一个自然市场 支付更高费用的交易无需排队 并更快地融入链条中。 6.8。联网。传统 blockchain 上的网络 像 Ethereum 和 Bitcoin 有相当简单的要求。 所有交易和区块都以简单的无向八卦形式广播。同步涉及的比较多，尤其是 与 Ethereum 但实际上这个逻辑包含在 对等策略而不是协议本身，它围绕一些请求和应答消息类型进行解析。 虽然 Ethereum 通过 devp2p 协议在当前协议产品上取得了进展，这使得许多 子协议在单个对等连接上复用，因此具有相同的对等覆盖支持许多 同时使用 p2p 协议，Ethereum 部分 协议仍然相对简单，p2p 协议暂时尚未完成，其中有重要内容 缺少 QoS 支持等功能。可悲的是，创建一个更普遍的“web 3”协议的愿望在很大程度上 失败了，唯一使用它的项目是那些明确的项目 由 Ethereum 众筹资助。 Polkadot 的要求相当严格。而不是一个完全统一的网络，Polkadot 有多种类型的参与者，每种类型对其同伴构成和多个网络都有不同的要求 参与者倾向于谈论的“途径” 特定数据。这意味着一个更加结构化的网络覆盖——以及支持该网络的协议—— 可能是必要的。此外，可扩展性可以促进未来的添加，例如新型“链” 它们本身需要一种新颖的覆盖结构。 在深入讨论如何网络化的同时 协议可能看起来超出了本文档的范围，但某些需求分析是合理的。我们可以 粗略地将我们的网络参与者分为两组 （中继链、平行链）三个子集中的每一个。我们可以 还声明每个平行链参与者都只是 对彼此之间的交谈感兴趣，而不是 其他平行链的参与者： • 中继链参与者： • 验证者： P，分成子集 P[s]，每个 平行链 • 可用性保证人：A（这可以由协议基本形式中的验证人表示） • 中继链客户端： M（注意每个成员 平行链集合也往往是 M 的成员） • 平行链参与者： • 平行链整理者：C[0]、C[1]、。 。 。 • 平行链渔民：F[0]、F[1]、。 。 。 • 平行链客户端：S[0]、S[1]、。 。 。 • 平行链轻客户端：L[0]、L[1]、。 。 。 一般来说，我们命名特定类别的通信 往往会发生在这些集合的成员之间： • P |一个 <-> 普 |答： 的 满 设置 的 validators/担保人 必须 是 人脉广泛 到 达成共识。 • P[s] <-> C[s] | P[s]：每个 validator 作为给定平行链组的成员都会倾向于八卦 与其他此类成员以及整理者 该平行链的发现和共享候选块。 • A <-> P[s] | C | A：每个可用性保证人 需要收集共识敏感的跨链 来自分配给它的 validator 的数据；整理者 也可能会优化他们达成共识的机会 通过将其广告给可用性保证人来阻止。 一旦他们获得了数据，数据将被分配给 其他此类担保人以促进达成共识。 • P[s] <-> A | P[s']：平行链 validators 将 需要从前一组 validator 或可用性保证人收集额外的输入数据。 • F[s] <-> P：报告时，渔民可以将 向任何参与者提出索赔。 • M <-> M |普 |答：一般中继链客户端从 validator 和担保人那里分配数据。 • S[s] <-> S[s] | P[s] |答：平行链客户从 validator/担保人分配数据。 • L[s] <-> L[s] | S[s]：平行链轻客户端 分配来自完整客户的数据。 为确保高效的运输机制，“扁平化” 覆盖网络 - 就像 Ethereum 的 devp2p - 其中每个 节点不会（非任意地）区分其适应度 同行不太可能适合。一个合理可扩展的 对等选择和发现机制可能需要 包含在协议中以及积极的 规划前瞻性以确保正确的同行类型 是“偶然”连接在正确的时间进行了治疗。 对于每一类参与者，同伴组成的精确策略将有所不同：为了适当地横向扩展 多链，整理者要么需要连续 重新连接到相应选择的 validators，或者将 需要与 validator 的子集达成持续协议 以确保它们在绝大多数时间内不会断开连接，因为它们对于 validator 毫无用处。整理者自然也会尝试维护一个 或更稳定的连接到可用性保证人 旨在确保其共识敏感的迅速传播 数据。 可用性保证人的主要目标是维持 彼此之间以及与 validators 的稳定连接（用于共识以及对共识至关重要的平行链数据 他们证明），以及一些整理者（对于平行链 数据）和一些渔民和完整的客户（用于分散 信息）。验证者会倾向于寻找其他 validator，特别是那些在同一子组中的以及任何 可以为他们提供平行链候选区块的整理者。 渔民，以及一般中继链和平行链 客户通常会致力于保持连接开放 validator 或担保人，但还有很多其他类似的节点 否则对他们自己来说。平行链轻客户端同样致力于连接到平行链的完整客户端， 如果不仅仅是其他平行链轻客户端。 6.8.1.同行流失问题。在基本协议提案中，每个子集随着分配给验证的 validators 不断随机改变每个块 平行链转换是随机选择的。这个可以 不同（非对等）节点需要 相互之间传递数据。一个人必须要么依赖 一个公平分布且连接良好的对等网络
Polkadot：异构多链框架的愿景 草案1 18 确保跳跃距离（以及最坏情况下的延迟）仅随着网络大小的对数而增长 （类似 Kademlia 的协议 [13] 可能会有所帮助），或者必须 引入更长的阻塞时间，以允许进行必要的连接协商，以保持对等组 反映节点当前的通信需求。 这些都不是很好的解决方案：阻塞时间长 强制网络可能会使其无用 特定的应用程序和链条。即使是完全公平的 和连接的网络将导致大量的浪费 由于不感兴趣的节点具有扩展带宽 转发对他们无用的数据。 虽然两个方向都可能构成解决方案的一部分， 合理的优化有助于最大限度地减少延迟 是为了限制这些平行链validator的波动性 集，或者仅在一系列块之间重新分配成员资格（例如，以 15 个为一组，在 4 秒后 阻塞时间意味着每次只改变一次连接 分钟）或以增量方式轮换成员资格，例如一次由一名成员更改（例如，如果有 为每个平行链分配了 15 个 validator，那么平均而言，完全唯一的之间将需要整整一分钟的时间 集）。通过限制对等点的流失量，并确保有利的对等点连接在 通过平行链的部分可预测性取得进展 集，我们可以帮助确保每个节点永久保留 偶然选择的同伴。 6.8.2.有效网络协议的路径。很可能是 最有效和合理的开发工作将集中于利用预先存在的协议而不是滚动 我们自己的。 存在多种点对点基本协议 我们可以使用或增强包括 Ethereum 自己的 devp2p [22]、IPFS 的 libp2p [1] 和 GNU 的 GNUnet [4]。对这些协议及其与构建 支持某些结构保证、动态对等引导和可扩展子协议的模块化对等网络 远远超出了本文档的范围，但将是一个 实施 Polkadot 的重要一步。 7. 议定书的实用性 7.1.链间交易支付。虽然一个伟大的 通过放弃对像 Ethereum 的 Gas 这样的整体计算资源核算框架的需求，可以获得大量的自由和简单性，这确实提出了一个重要的问题：没有 Gas，一条平行链如何运作？ 避免另一个平行链强迫它进行计算？虽然我们可以依赖事务后入口队列 缓冲区以防止一条链向另一条链发送垃圾邮件 交易数据，协议没有提供等效机制来防止交易处理的垃圾邮件。 这是留给上级的问题。自连锁 可以自由地将任意语义附加到传入的 交易后数据，我们可以确保计算 必须在开始前付款。与此类似 Ethereum Serenity所拥护的模型，我们可以想象 平行链内的“闯入”合约允许 validator 保证付款以换取 提供特定数量的处理资源。 这些资源可以用天然气之类的东西来衡量， 但也可能是一些全新的模型，例如主观执行时间或类似 Bitcoin 的固定费用模型。 就其本身而言，这并不是那么有用，因为我们不能轻易假设链外调用者可以使用它们 闯入所识别的任何价值机制 合同。然而，我们可以想象源链中存在二次“突破”合约。两份合同共同构成一座桥梁，相互承认并 提供价值对等。 （质押-tokens，可用于 每一个都可以用来结算国际收支。） 调用另一个这样的链将意味着代理 通过这座桥，这将提供 协商链之间的价值转移，以便 支付目标平行链上所需的计算资源。 7.2.附加 链子。同时 的 加法 的 一个 平行链是一种相对便宜的操作，它不是免费的。 更多平行链意味着每个平行链更少的 validator 最终，会产生大量 validator，每个都有一个 平均债券减少。虽然攻击平行链的强制成本较小的问题可以通过 渔民们，不断增长的 validator 组本质上迫使 由于底层共识的机制，延迟程度较高方法。此外，每个平行链 它有可能使 validators 悲伤 过于繁琐的验证算法。 因此，将会有一些“价格”，validators 和/或利益相关团体将提取 添加新的平行链。这个连锁市场将 可能会看到添加以下任一内容： • 可能净贡献为零的链（就锁定或燃烧 staking token 而言）将成为其中的一部分（例如联盟链、 Doge 链、特定于应用程序的链）； • 为网络提供内在价值的链 通过添加特定的功能困难 到其他地方（例如保密性、内部可扩展性、服务捆绑）。 从本质上讲，利益相关者社区需要 被激励添加子链——无论是经济上还是 通过向中继添加功能链的愿望。 预计新添加的连锁店将具有非常大的 拆除通知期很短，允许新的连锁店 进行试验，没有任何妥协的风险 中期或长期价值主张。 八、结论 我们已经概述了人们可以采取的方向来创作 可扩展的异构多链协议，具有向后兼容某些预先存在的潜力 blockchain 网络。在这样的协议下，参与者 本着开明的自身利益创建一个整体系统，该系统可以以极其自由的方式进行扩展，并且无需为现有用户支付通常的成本 来自标准 blockchain 设计。我们已经给了 所需架构的粗略轮廓，包括 参与者的性质，他们的经济动机 以及他们必须参与的流程。我们有 确定了基本设计并讨论了其优点和 限制；因此我们有进一步的指示 可以缓解这些限制，并进一步为完全可扩展的 blockchain 解决方案奠定基础。Polkadot：异构多链框架的愿景 草案1 19 8.1.缺少材料和悬而未决的问题。协议的不同实现始终有可能导致网络分叉。从这样的情况中恢复 没有讨论特殊情况。鉴于网络必然有一个非零的终结周期， 从中继链分叉中恢复应该不是一个大问题，但是需要仔细集成 共识协议。 债券没收和相反的奖励规定 没有被深入探讨。目前我们假设奖励 在赢家通吃的基础上提供：这可能不会 为渔民提供最佳的激励模式。短期的提交-披露过程将允许许多渔民 为了获得更公平的奖励分配奖品， 然而，该过程可能会导致额外的延迟 发现不当行为。 8.2.致谢。非常感谢所有的 校对员帮助将其模糊化 美观的形状。 特别是 Peter Czaban、Bjorn 瓦格纳、肯·卡普勒、罗伯特·哈伯迈尔、维塔利克·布特林、雷托·特林克勒和杰克·彼得森。 感谢大家 贡献想法或开端的人 其中，Marek Kotewicz 和 Aeron Buchanan 值得特别提及。感谢其他人的帮助 一路上。所有错误都是我自己造成的。 这项工作的部分内容，包括初步研究 共识算法，部分由英国资助 政府根据创新英国计划。