Polkadot: Tầm nhìn về Khung đa chuỗi không đồng nhất
خلاصة
بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 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
Tóm tắt
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 DR. GỖ GAVIN NGƯỜI SÁNG LẬP, ETHEREUM & PARITY [email protected] Trừu tượng. Các kiến trúc blockchain ngày nay đều gặp phải một số vấn đề, đặc biệt là các phương tiện thực tế về khả năng mở rộng và khả năng mở rộng. Chúng tôi tin rằng điều này bắt nguồn từ việc ràng buộc hai phần rất quan trọng của cấu trúc đồng thuận, đó là tính chuẩn tắc và tính giá trị quá chặt chẽ với nhau. Bài viết này giới thiệu một kiến trúc đa chuỗi không đồng nhất, về cơ bản làm cho hai điều này trở nên khác biệt. Trong việc chia thành hai phần này và bằng cách giữ cho chức năng tổng thể được cung cấp ở mức tối thiểu về an ninh và vận tải, chúng tôi giới thiệu các phương tiện thực tế về khả năng mở rộng cốt lõi tại chỗ. Khả năng mở rộng được giải quyết thông qua một cách tiếp cận phân chia và chinh phục đối với hai chức năng này, mở rộng ra khỏi cốt lõi liên kết của nó thông qua việc khuyến khích các nút công khai không đáng tin cậy. Bản chất không đồng nhất của kiến trúc này cho phép nhiều loại hệ thống đồng thuận rất khác nhau tương tác trong một “liên đoàn” phi tập trung hoàn toàn, không cần tin cậy, cho phép các mạng mở và đóng có quyền truy cập không cần tin cậy vào lẫn nhau. Chúng tôi đưa ra phương tiện cung cấp khả năng tương thích ngược với một hoặc nhiều mạng có sẵn như Ethereum. Chúng tôi tin rằng một hệ thống như vậy cung cấp một thành phần cấp cơ sở hữu ích trong việc tìm kiếm tổng thể một giải pháp thực tế. hệ thống có thể triển khai có khả năng đạt được mức độ thương mại toàn cầu về khả năng mở rộng và quyền riêng tư. 1. Lời nói đầu Đây được coi là bản tóm tắt “tầm nhìn” kỹ thuật về một hướng khả thi có thể được thực hiện để phát triển hơn nữa mô hình blockchain cùng với một số lý do căn bản giải thích tại sao hướng này lại hợp lý. Nó đặt ra trong càng nhiều chi tiết càng tốt ở giai đoạn phát triển này một hệ thống có thể mang lại sự cải thiện cụ thể về số khía cạnh của công nghệ blockchain. Nó không nhằm mục đích cụ thể hóa, hình thức hay cách khác. Nó không nhằm mục đích toàn diện cũng như không phải là một thiết kế cuối cùng. Nó không nhằm mục đích bao gồm các khía cạnh không cốt lõi của khung như API, ràng buộc, ngôn ngữ và cách sử dụng. Điều này đáng chú ý là mang tính thử nghiệm; thông số ở đâu được chỉ định, chúng có thể thay đổi. Cơ chế sẽ được thêm vào, tinh chỉnh và loại bỏ để đáp ứng với cộng đồng ý tưởng và phê bình. Phần lớn của bài viết này có thể sẽ được sửa đổi như bằng chứng thực nghiệm và nguyên mẫu cung cấp cho chúng tôi thông tin về điều gì sẽ hiệu quả và điều gì không. Tài liệu này bao gồm mô tả cốt lõi của giao thức cùng với các ý tưởng về các hướng dẫn có thể được thực hiện để cải thiện các khía cạnh khác nhau. Người ta hình dung rằng cốt lõi mô tả sẽ được sử dụng làm điểm bắt đầu cho lần đầu tiên một loạt các bằng chứng về khái niệm. “Phiên bản 1.0” cuối cùng sẽ là dựa trên giao thức được cải tiến này cùng với các ý tưởng bổ sung đã được chứng minh và quyết tâm thực hiện cần thiết để dự án đạt được mục tiêu của nó. 1.1. Lịch sử. • 10/09/2016: 0.1.0-proof1 • 20/10/2016: 0.1.0-proof2 • 11/01/2016: 0.1.0-proof3 • 11/10/2016: 0.1.0 2. Giới thiệu Blockchain đã chứng tỏ nhiều hứa hẹn về tiện ích trên một số lĩnh vực bao gồm “Internet of Things” (IoT), tài chính, quản trị, quản lý danh tính, phân quyền web và theo dõi tài sản. Tuy nhiên, mặc dù hứa hẹn về công nghệ và những cuộc nói chuyện hoành tráng, chúng ta vẫn chưa thấy triển khai đáng kể trong thế giới thực của công nghệ hiện tại. Chúng tôi tin rằng đây là do năm thất bại chính của hiện tại. ngăn xếp công nghệ: Khả năng mở rộng: Bao nhiêu tài nguyên được chi tiêu trên toàn cầu về xử lý, băng thông và lưu trữ để hệ thống xử lý một giao dịch và có bao nhiêu giao dịch giao dịch có thể được xử lý hợp lý theo điều kiện cao điểm? Tính cô lập: Liệu nhu cầu khác nhau của nhiều người có thể các bên và đơn đăng ký có được giải quyết ở mức độ gần như tối ưu trong cùng một khuôn khổ không? Khả năng phát triển: Các công cụ này hoạt động tốt như thế nào? làm API có giải quyết được nhu cầu của nhà phát triển không? Tài liệu giáo dục có sẵn không? Có sự tích hợp phù hợp ở đó không? Quản trị: Mạng có thể duy trì tính linh hoạt để phát triển và thích nghi theo thời gian? Liệu các quyết định có thể được được thực hiện với tính toàn diện, hợp pháp và minh bạch để cung cấp sự lãnh đạo hiệu quả của một hệ thống phi tập trung? Khả năng ứng dụng: Công nghệ này có thực sự giải quyết được nhu cầu cấp bách không? “Phần mềm trung gian” khác có cần thiết để thu hẹp khoảng cách với ứng dụng thực tế? Trong công việc hiện tại, chúng tôi mong muốn giải quyết hai vấn đề đầu tiên vấn đề: khả năng mở rộng và khả năng cô lập. Điều đó nói lên rằng, chúng tôi tin khuôn khổ Polkadot có thể cung cấp những cải tiến có ý nghĩa cho từng loại vấn đề này. Triển khai blockchain hiện đại, hiệu quả như ứng dụng Parity Ethereum [17] có thể sản xuấtess vượt quá 3.000 giao dịch mỗi giây khi chạy trên phần cứng tiêu dùng hiệu suất cao. Tuy nhiên, thực tế hiện nay blockchain mạng thực tế bị giới hạn ở khoảng 30 giao dịch mỗi giây. Hạn chế này chủ yếu bắt nguồn từ thực tế là các cơ chế đồng thuận đồng bộ hiện tại yêu cầu biên độ an toàn về thời gian rộng. thời gian xử lý dự kiến, điều này càng trở nên trầm trọng hơn do 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 نشارك بعض أوجه التشابه العابرة التي نعتقد أنها هدفها النهائي مختلفة إلى حد كبير، وذلك بدلا من التنافس، من المرجح أن يتعايش البروتوكولان في النهاية تحت عنوان علاقة منفعة متبادلة في المستقبل المنظور.
Giới thiệu
Blockchain đã chứng tỏ nhiều hứa hẹn về tiện ích trên một số lĩnh vực bao gồm “Internet of Things” (IoT), tài chính, quản trị, quản lý danh tính, phân quyền web và theo dõi tài sản. Tuy nhiên, mặc dù hứa hẹn về công nghệ và những cuộc nói chuyện hoành tráng, chúng ta vẫn chưa thấy triển khai đáng kể trong thế giới thực của công nghệ hiện tại. Chúng tôi tin rằng đây là do năm thất bại chính của hiện tại. ngăn xếp công nghệ: Khả năng mở rộng: Bao nhiêu tài nguyên được chi tiêu trên toàn cầu về xử lý, băng thông và lưu trữ để hệ thống xử lý một giao dịch và có bao nhiêu giao dịch giao dịch có thể được xử lý hợp lý theo điều kiện cao điểm? Tính cô lập: Liệu nhu cầu khác nhau của nhiều người có thể các bên và đơn đăng ký có được giải quyết ở mức độ gần như tối ưu trong cùng một khuôn khổ không? Khả năng phát triển: Các công cụ này hoạt động tốt như thế nào? làm API có giải quyết được nhu cầu của nhà phát triển không? Tài liệu giáo dục có sẵn không? Có sự tích hợp phù hợp ở đó không? Quản trị: Mạng có thể duy trì tính linh hoạt để phát triển và thích nghi theo thời gian? Liệu các quyết định có thể được được thực hiện với tính toàn diện, hợp pháp và minh bạch để cung cấp sự lãnh đạo hiệu quả của một hệ thống phi tập trung? Khả năng ứng dụng: Công nghệ này có thực sự giải quyết được nhu cầu cấp bách không? “Phần mềm trung gian” khác có cần thiết để thu hẹp khoảng cách với ứng dụng thực tế? Trong công việc hiện tại, chúng tôi mong muốn giải quyết hai vấn đề đầu tiên vấn đề: khả năng mở rộng và khả năng cô lập. Điều đó nói lên rằng, chúng tôi tin khuôn khổ Polkadot có thể cung cấp những cải tiến có ý nghĩa cho từng loại vấn đề này. Triển khai blockchain hiện đại, hiệu quả như ứng dụng Parity Ethereum [17] có thể xử lý vượt quá 3.000 giao dịch mỗi giây khi chạy trên phần cứng tiêu dùng hiệu suất cao. Tuy nhiên, thực tế hiện nay blockchain mạng thực tế bị giới hạn ở khoảng 30 giao dịch mỗi giây. Hạn chế này chủ yếu bắt nguồn từ thực tế là các cơ chế đồng thuận đồng bộ hiện tại yêu cầu biên độ an toàn về thời gian rộng. thời gian xử lý dự kiến, điều này càng trở nên trầm trọng hơn doPOLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 2 mong muốn hỗ trợ việc triển khai chậm hơn. Điều này là do kiến trúc đồng thuận cơ bản: cơ chế chuyển đổi trạng thái hoặc phương tiện để các bên đối chiếu và thực hiện các giao dịch, về cơ bản logic của nó gắn liền với vào cơ chế “chuẩn hóa” đồng thuận, hoặc có nghĩa là các bên đồng ý về một trong số các có thể, hợp lệ, lịch sử. Điều này áp dụng như nhau cho cả hai hệ thống proof-of-work (PoW) như Bitcoin [15] và Ethereum [5,23] và các hệ thống bằng chứng cổ phần (PoS) như NXT [8] và Bitshares [12]: cuối cùng tất cả đều phải chịu đựng những bất lợi giống nhau. Nó đơn giản chiến lược đã giúp blockchain thành công. Tuy nhiên, bằng cách kết hợp chặt chẽ hai cơ chế này thành một đơn vị duy nhất của giao thức, chúng tôi cũng kết hợp nhiều giao thức khác nhau các tác nhân và ứng dụng có hồ sơ rủi ro khác nhau, yêu cầu về khả năng mở rộng khác nhau và nhu cầu riêng tư khác nhau. Một kích thước không phù hợp với tất cả. Trường hợp này thường xảy ra là trong một mong muốn thu hút rộng rãi, mạng lưới áp dụng một mức độ bảo thủ dẫn đến mẫu số chung thấp nhất phục vụ tối ưu cho một số ít và cuối cùng dẫn đến thất bại trong khả năng đổi mới, thực hiện và thích ứng, đôi khi đột ngột như vậy. Một số hệ thống như v.d. Factom [21] bỏ hoàn toàn cơ chế chuyển trạng thái. Tuy nhiên, phần lớn các tiện ích mà chúng tôi mong muốn đòi hỏi khả năng chuyển trạng thái theo một máy trạng thái dùng chung. Bỏ nó đi là giải quyết được một vấn đề thay thế; nó không cung cấp một sự thay thế giải pháp. Do đó, có vẻ rõ ràng rằng một hướng đi hợp lý để khám phá như một lộ trình dẫn đến một máy tính phi tập trung có thể mở rộng nền tảng là tách rời kiến trúc đồng thuận khỏi cơ chế chuyển trạng thái. Và có lẽ không có gì đáng ngạc nhiên, đây là chiến lược mà Polkadot áp dụng như một giải pháp cho khả năng mở rộng. 2.1. Giao thức, triển khai và mạng. thích Bitcoin và Ethereum, Polkadot đề cập ngay đến giao thức mạng và giao thức chính (cho đến nay được giả định trước) mạng công cộng chạy giao thức này. Polkadot được dự định là một dự án mở và miễn phí, đặc tả giao thức theo giấy phép Creative Commons và mã được đặt theo giấy phép FLOSS. Dự án là được phát triển một cách cởi mở và chấp nhận sự đóng góp bất cứ nơi nào chúng hữu ích. Một hệ thống RFC, không khác gì Đề xuất cải tiến Python, sẽ cho phép một phương tiện cộng tác công khai về các thay đổi và nâng cấp giao thức. Triển khai ban đầu của chúng tôi về giao thức Polkadot sẽ được gọi là Nền tảng chẵn lẻ Polkadot và sẽ bao gồm việc triển khai giao thức đầy đủ cùng với API ràng buộc. Giống như các triển khai Parity blockchain khác, PPP được thiết kế để trở thành một ngăn xếp công nghệ blockchain có mục đích chung, không dành riêng cho mạng công cộng cũng như cho hoạt động tư nhân/liên doanh. Sự phát triển của nó vì thế cho đến nay đã được tài trợ bởi một số bên bao gồm thông qua một khoản trợ cấp từ chính phủ Anh. Tuy nhiên, bài viết này mô tả Polkadot theo bối cảnh của một mạng công cộng. Chức năng mà chúng ta hình dung trong một mạng công cộng là một tập hợp siêu chức năng được yêu cầu trong cài đặt thay thế (ví dụ: tư nhân và/hoặc tập đoàn). Hơn nữa, trong bối cảnh này, phạm vi đầy đủ của Polkadot có thể được mô tả và thảo luận rõ ràng hơn. Điều này có nghĩa người đọc nên biết rằng một số cơ chế nhất định có thể được mô tả (ví dụ: tương tác với các mạng công cộng khác) không liên quan trực tiếp đến Polkadot khi được triển khai trong các tình huống không công khai (“được phép”). 2.2. Công việc trước đây. Việc tách rời sự đồng thuận cơ bản khỏi quá trình chuyển đổi trạng thái đã được đề xuất một cách không chính thức riêng tư trong ít nhất hai năm—Max Kaye là người đề xuất chiến lược như vậy trong những ngày đầu của Ethereum. Một giải pháp có thể mở rộng phức tạp hơn được gọi là Chuỗi bers, có từ tháng 6 năm 2014 và được xuất bản lần đầu sau đó Năm đó1, đã đưa ra trường hợp về một chuỗi chuyển tiếp duy nhất và nhiều chuỗi đồng nhất cung cấp cơ chế thực thi liên chuỗi minh bạch. Sự mất kết hợp đã được trả giá cho thông qua độ trễ giao dịch—các giao dịch yêu cầu sự phối hợp của các phần khác nhau của hệ thống sẽ mất nhiều thời gian hơn để xử lý. Polkadot lấy phần lớn kiến trúc của nó từ đó và các cuộc trò chuyện tiếp theo với nhiều người khác nhau, mặc dù nó khác nhau rất nhiều về phần lớn thiết kế và quy định. Mặc dù không có hệ thống nào có thể so sánh được với Polkadot thực tế trong sản xuất, một số hệ thống có liên quan đã được đề xuất, mặc dù rất ít ở mức độ đáng kể chi tiết. Những đề xuất này có thểchia thành các hệ thống loại bỏ hoặc làm giảm khái niệm về một hệ thống thống nhất toàn cầu máy trạng thái, những máy cố gắng cung cấp một cách toàn cầu máy đơn kết hợp thông qua các mảnh đồng nhất và những mục tiêu chỉ nhắm đến sự không đồng nhất. 2.2.1. Hệ thống không có trạng thái toàn cầu. Factom [21] là một hệ thống thể hiện tính chuẩn mực mà không cần tuân theo giá trị, cho phép ghi chép dữ liệu một cách hiệu quả. Bởi vì sự tránh né trạng thái toàn cầu và những khó khăn với khả năng mở rộng mà điều này mang lại, nó có thể được coi là một giải pháp có thể mở rộng. Tuy nhiên, như đã đề cập trước đó, bộ số vấn đề mà nó giải quyết được nhỏ hơn đáng kể và nghiêm ngặt. Tangle [18] là một cách tiếp cận mới đối với các hệ thống đồng thuận. Thay vì sắp xếp các giao dịch thành các khối và hình thành sự đồng thuận về một danh sách được liên kết chặt chẽ để đưa ra thứ tự chuẩn mực toàn cầu về các thay đổi trạng thái, nó phần lớn từ bỏ ý tưởng về một trật tự có cấu trúc chặt chẽ và thay vào đó thúc đẩy biểu đồ tuần hoàn có hướng của các giao dịch phụ thuộc với các mục sau giúp chuẩn hóa các mục trước đó thông qua tài liệu tham khảo rõ ràng. Đối với những thay đổi trạng thái tùy ý, biểu đồ phụ thuộc này sẽ nhanh chóng trở nên khó hiểu, tuy nhiên đối với UTXO model2 đơn giản hơn nhiều thì điều này trở thành khá hợp lý. Bởi vì hệ thống chỉ có tính mạch lạc lỏng lẻo và các giao dịch thường độc lập với nhau. mặt khác, một lượng lớn sự song song toàn cầu trở nên khá tự nhiên. Sử dụng mô hình UTXO có tác dụng về việc giới hạn Tangle thành một loại “tiền tệ” chuyển giao giá trị thuần túy hệ thống hơn là bất cứ điều gì chung chung hoặc có thể mở rộng. Hơn nữa, nếu không có sự gắn kết chặt chẽ toàn cầu, sự tương tác với các hệ thống khác có xu hướng cần một sự kết nối tuyệt đối. kiến thức về trạng thái hệ thống—trở nên không thực tế. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2đầu ra giao dịch chưa được chi tiêu, mô hình mà Bitcoin sử dụng, theo đó trạng thái thực sự là tập hợp địa chỉ được liên kết với một số giá trị; các giao dịch đối chiếu các địa chỉ đó và cải tổ chúng thành một bộ địa chỉ mới có tổng số tiền tương đương
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 3 2.2.2. Hệ thống chuỗi không đồng nhất. Chuỗi bên [3] là một đề xuất bổ sung vào giao thức Bitcoin sẽ cho phép tương tác không đáng tin cậy giữa chuỗi Bitcoin chính và các chuỗi bên bổ sung. Không có quy định nào cho bất kỳ mức độ tương tác 'phong phú' giữa các chuỗi bên: sự tương tác sẽ bị giới hạn ở việc cho phép các chuỗi bên được người giám sát tài sản của nhau, có hiệu lực—ở địa phương biệt ngữ—một chốt hai chiều 3. Tầm nhìn cuối cùng là về một khuôn khổ trong đó loại tiền tệ Bitcoin có thể được cung cấp chức năng bổ sung, nếu là ngoại vi, thông qua việc chốt nó lên một số chuỗi khác với sự chuyển đổi trạng thái kỳ lạ hơn hệ thống hơn giao thức Bitcoin cho phép. Theo nghĩa này, chuỗi bên giải quyết khả năng mở rộng hơn là khả năng mở rộng. Thật vậy, về cơ bản không có quy định nào về tính hợp lệ của chuỗi bên; tokens từ một chuỗi (ví dụ: Bitcoin) được tổ chức thay mặt cho chuỗi bên chỉ được bảo mật bởi khả năng của chuỗi bên để khuyến khích các thợ mỏ chuẩn hóa chuyển tiếp hợp lệ. Tính bảo mật của mạng Bitcoin không thể dễ dàng chuyển sang làm việc thay mặt cho người khác blockchains. Hơn nữa, một giao thức để đảm bảo Bitcoin các công cụ khai thác hợp nhất khai thác (nghĩa là nhân đôi sức mạnh chuẩn hóa của họ lên sức mạnh của chuỗi bên) và quan trọng hơn là xác thực các chuyển đổi của chuỗi bên nằm ngoài phạm vi phạm vi của đề xuất này. Cosmos [10] là một hệ thống đa chuỗi được đề xuất trong cùng một mạch với chuỗi bên, hoán đổi Nakamoto PoW phương pháp đồng thuận cho thuật toán Tendermint của Jae Kwon. Về cơ bản, nó mô tả nhiều chuỗi (hoạt động trong vùng) mỗi vùng sử dụng các phiên bản riêng lẻ của Tendermint, cùng với phương tiện liên lạc không tin cậy thông qua chuỗi trung tâm chính. Giao tiếp giữa các chuỗi này được giới hạn ở việc chuyển giao tài sản kỹ thuật số (“cụ thể là về tokens”) thay vì thông tin tùy ý, tuy nhiên, giao tiếp giữa các chuỗi như vậy có đường dẫn trở lại cho dữ liệu, ví dụ: để báo cáo cho người gửi về tình trạng chuyển tiền. Bộ xác thực cho các chuỗi được khoanh vùng và đặc biệt phương tiện khuyến khích họ, giống như chuỗi bên, được để lại như một bài toán chưa được giải quyết. Giả định chung là mỗi chuỗi được phân vùng sẽ tự giữ token giá trị mà lạm phát được sử dụng để thanh toán cho validators. Vẫn đang ở giai đoạn đầu về thiết kế, hiện tại đề xuất thiếu chi tiết toàn diện về các phương tiện kinh tế để đạt được khả năng mở rộng sự chắc chắn về giá trị toàn cầu. Tuy nhiên, sự gắn kết lỏng lẻo cần có giữa các vùng và trung tâm sẽ cho phép để có thêm tính linh hoạt đối với các tham số của vùng được khoanh vùng chuỗi so với chuỗi của một hệ thống thực thi mạnh hơn sự mạch lạc. 2.2.3. Casper. Chưa có đánh giá toàn diện hoặc so sánh song song giữa Casper [6] và Polkadot đã được thực hiện, mặc dù người ta có thể thực hiện khá sâu rộng (và do đó không chính xác) đặc tính của cả hai. Casper là sự mô phỏng lại cách thức thuật toán đồng thuận PoS có thể dựa trên việc người tham gia đặt cược vào ngã ba nào cuối cùng sẽ trở thành kinh điển. Sự xem xét đáng kể đã được đưa ra để đảm bảo rằng nó mạnh mẽ cho mạng phân nhánh, ngay cả khi được kéo dài và có một số mức độ mở rộng bổ sung dựa trên mô hình Ethereum cơ bản. Như như vậy, Casper cho đến nay có xu hướng trở thành một giải pháp đáng kể hơn giao thức phức tạp hơn Polkadot và các giao thức trước đó của nó, và một sai lệch đáng kể so với định dạng blockchain cơ bản. Nó vẫn chưa rõ Casper sẽ lặp lại như thế nào trong tương lai và cuối cùng nó sẽ trông như thế nào nếu được triển khai. Trong khi Casper và Polkadot đều đại diện cho các giao thức mới thú vị và, theo một nghĩa nào đó, là sự gia tăng của Ethereum, có sự khác biệt đáng kể giữa chúng mục tiêu cuối cùng và con đường để triển khai. Casper là một Ethereum Dự án lấy nền tảng làm trung tâm được thiết kế ban đầu là một sự thay đổi PoS đối với giao thức mà không mong muốn về cơ bản tạo ra blockchain có thể mở rộng quy mô. Điều quan trọng là nó được thiết kế để trở thành một hard-fork, thay vì bất kỳ thứ gì mở rộng hơn và do đó tất cả khách hàng và người dùng Ethereum sẽ cần phải nâng cấp hoặc duy trì một nhánh của việc áp dụng không chắc chắn. Do đó, việc triển khai trở nên khó khăn hơn đáng kể như vốn có trong một dự án phi tập trung có yêu cầu chặt chẽ. sự phối hợp là cần thiết. Polkadot khác nhau ở một số điểm; đầu tiên và quan trọng nhất, Polkadot được thiết kế để có thể mở rộng và thay đổi quy mô hoàn toàn blockchain thử nghiệm phát triển, triển khai và tương tác giường. Nó được chế tạo để trở thành một dây đai an toàn cho tương lai, có khả năng đồng hóa mới blockchaincông nghệ khi nó trở nên sẵn có mà không cần sự phối hợp phi tập trung quá phức tạp hoặc hard fork. Chúng tôi đã hình dung ra một số trường hợp sử dụng như như chuỗi liên minh được mã hóa và chuỗi tần số cao với thời gian chặn rất thấp, điều này không thực tế để thực hiện trong bất kỳ phiên bản tương lai nào của Ethereum hiện được hình dung. Cuối cùng, sự kết hợp giữa nó và Ethereum là vô cùng lỏng lẻo; không cần thực hiện hành động nào từ phía Ethereum để cho phép chuyển tiếp giao dịch không đáng tin cậy giữa hai mạng. Tóm lại, trong khi Casper/Ethereum 2.0 và Polkadot chia sẻ một số điểm tương đồng thoáng qua mà chúng tôi tin rằng mục tiêu cuối cùng của họ về cơ bản là khác nhau và thay vì cạnh tranh, hai giao thức cuối cùng có khả năng cùng tồn tại dưới một mối quan hệ đôi bên cùng có lợi trong tương lai gần.
ملخص
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 يجب أن توفر بشكل أساسي طبقة أساسية مستقرة. وبالإضافة إلى السلامة الاقتصادية، فإن هذا يعني أيضًا تقليل المركزية ناقلات للهجمات ذات المكافأة العالية.
Bản tóm tắt
Polkadot là một chuỗi đa chuỗi không đồng nhất có thể mở rộng. Cái này có nghĩa là không giống như các lần triển khai blockchain trước đây đã tập trung vào việc cung cấp một chuỗi duy nhất các sản phẩm khác nhau mức độ tổng quát về các ứng dụng tiềm năng, Polkadot bản thân nó được thiết kế để không cung cấp chức năng ứng dụng vốn có nào cả. Đúng hơn, Polkadot cung cấp nền tảng “chuỗi chuyển tiếp” trên đó có một số lượng lớn các thông tin có thể xác nhận, cấu trúc dữ liệu động mạch lạc toàn cầu có thể được lưu trữ bên cạnh nhau. Chúng tôi gọi những cấu trúc dữ liệu này là “song song” chuỗi hoặc parachain, mặc dù không có nhu cầu cụ thể về về bản chất chúng là blockchain. Nói cách khác, Polkadot có thể được coi là tương đương với một tập hợp các chuỗi độc lập (ví dụ: tập hợp chứa Ethereum, Ethereum Classic, Namecoin và Bitcoin) ngoại trừ hai điểm rất quan trọng: • Bảo mật tổng hợp; • khả năng giao dịch liên chuỗi không cần tin cậy. Những điểm này là lý do tại sao chúng tôi coi Polkadot là “có thể mở rộng”. Về nguyên tắc, một vấn đề được triển khai trên Polkadot có thể được thực hiện song song—mở rộng quy mô—trên một số lượng lớn parachain. Vì tất cả các khía cạnh của mỗi parachain có thể được tiến hành song song bởi một phân đoạn khác nhau của mạng Polkadot, hệ thống có một số khả năng để mở rộng quy mô. Polkadot cung cấp một thông tin khá đơn giản 3trái ngược với chốt một chiều về cơ bản là hành động phá hủy tokens trong một chuỗi để tạo tokens trong một chuỗi khác mà không có cơ chế thực hiện ngược lại để khôi phục tokens ban đầuPOLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 4 cơ sở hạ tầng khiến phần lớn sự phức tạp phải được giải quyết ở cấp độ phần mềm trung gian. Đây là một quyết định có ý thức nhằm giảm thiểu rủi ro phát triển, tạo điều kiện cho phần mềm cần thiết được phát triển trong một khoảng thời gian ngắn và với mức độ tin cậy cao về tính bảo mật và sự vững chãi. 3.1. Triết lý của Polkadot. Polkadot nên cung cấp một nền tảng vững chắc tuyệt đối để xây dựng làn sóng hệ thống đồng thuận tiếp theo, ngay thông qua phổ rủi ro từ các thiết kế trưởng thành có khả năng sản xuất đến những ý tưởng non trẻ. Bằng cách cung cấp sự đảm bảo mạnh mẽ về bảo mật, cách ly và liên lạc, Polkadot có thể cho phép parachains để tự mình chọn từ một loạt thuộc tính. Thật vậy, chúng tôi đã thấy trước nhiều blockchain thử nghiệm khác nhau sẽ thúc đẩy các thuộc tính của những gì có thể được coi là hợp lý hôm nay. Chúng tôi thấy bảo thủ, chuỗi giá trị cao tương tự như Bitcoin hoặc Z-cash [20] cùng tồn tại cùng với giá trị thấp hơn “chuỗi chủ đề” (tiếp thị như vậy, rất thú vị) và mạng thử nghiệm với mức phí bằng 0 hoặc gần bằng 0. Chúng tôi thấy được mã hóa đầy đủ, “đen tối”, các chuỗi liên minh hoạt động song song—và thậm chí cung cấp dịch vụ cho—các chuỗi mở và có chức năng cao chẳng hạn như những thứ như Ethereum. Chúng tôi thấy thử nghiệm mới Các chuỗi dựa trên VM chẳng hạn như wasm tính phí theo thời gian chủ quan chuỗi đang được sử dụng như một phương tiện để gia công các vấn đề tính toán khó khăn từ chuỗi giống Ethereum hoàn thiện hơn hoặc một chuỗi giống Bitcoin bị hạn chế hơn. Để quản lý việc nâng cấp chuỗi, Polkadot vốn sẽ hỗ trợ một số loại cơ cấu quản trị, có thể dựa trên về các hệ thống chính trị ổn định hiện có và có khía cạnh lưỡng viện tương tự như Hội đồng Sách Vàng [24]. Như có thẩm quyền tối cao, những người nắm giữ token có thể đặt cược cơ bản sẽ có quyền kiểm soát "trưng cầu dân ý". Để phản ánh ý kiến của người dùng nhu cầu phát triển nhưng nhà phát triển cần tính hợp pháp, chúng tôi mong đợi một hướng đi hợp lý sẽ hình thành hai viện từ một ủy ban “người sử dụng” (gồm ngoại quan validators) và một ủy ban “kỹ thuật” được thành lập của các nhà phát triển khách hàng lớn và người chơi trong hệ sinh thái. các nhóm chủ sở hữu token sẽ duy trì tính hợp pháp cao nhất và hình thành đại đa số để tăng cường, điều chỉnh lại tham số, thay thế hoặc giải thể cấu trúc này, điều mà chúng tôi đừng nghi ngờ sự cần thiết cuối cùng của: theo lời của Twain “Chính phủ và tã lót phải được thay đổi thường xuyên, và để lý do giống nhau”. Trong khi việc tái tham số hóa thường không quan trọng để sắp xếp trong một cơ chế đồng thuận lớn hơn, thì những thay đổi về chất hơn như thay thế và tăng cường sẽ có thể cần phải là “nghị định mềm” không tự động hóa (ví dụ: thông qua việc chuẩn hóa số khối và hash của tài liệu chỉ định chính thức giao thức mới) hoặc yêu cầu cơ chế đồng thuận cốt lõi để chứa một ngôn ngữ đủ phong phú để mô tả bất kỳ khía cạnh nào của chính nó mà có thể cần phải thay đổi. Cái sau là mục đích cuối cùng, tuy nhiên, cái trước có nhiều khả năng được chọn hơn để tạo điều kiện cho một mốc thời gian phát triển hợp lý. Nguyên lý chính của Polkadot và các quy tắc trong đó chúng tôi đánh giá mọi quyết định thiết kế là: Tối thiểu: Polkadot phải có càng ít chức năng càng tốt. Đơn giản: không có sự phức tạp bổ sung nào trong giao thức cơ sở hơn mức có thể hợp lý được tải vào phần mềm trung gian, được đặt thông qua một parachain hoặc được giới thiệu trong lần tối ưu hóa sau này. Tổng quát: không có yêu cầu, ràng buộc không cần thiết hoặc nên áp dụng giới hạn đối với parachain; Polkadot phải là nơi thử nghiệm để phát triển hệ thống đồng thuận có thể được tối ưu hóa thông qua làm cho mô hình có phần mở rộng phù hợp càng trừu tượng càng tốt. Mạnh mẽ: Polkadot sẽ cung cấp cơ bản lớp nền ổn định. Ngoài sự lành mạnh về kinh tế, điều này còn có nghĩa là phân cấp để giảm thiểu các vectơ cho các cuộc tấn công có phần thưởng cao.
المشاركة في 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.
Tham gia Polkadot
Có bốn vai trò cơ bản trong việc duy trì Polkadot mạng: người đối chiếu, ngư dân, người đề cử và validator. trong một khả năng triển khai Polkadot, vai trò thứ hai thực tế có thể được chia thành hai vai trò: validator cơ bản và người bảo đảm tính sẵn có; điều này được thảo luận trong phần 6.5.3. đối chiếu ngư dân Trình xác nhận (nhóm này) Trình xác nhận (các nhóm khác) chấp thuận trở thành màn hình báo cáo xấu hành vi để cung cấp khối ứng viên cho Người đề cử Hình 1. Sự tương tác giữa bốn vai trò của Polkadot. 4.1. Trình xác nhận. validator là mức phí cao nhất và giúp niêm phong các khối mới trên mạng Polkadot. Vai trò của validator phụ thuộc vào mức độ liên kết đủ cao được ký gửi, mặc dù chúng tôi cho phép các bên liên kết khác đề cử một hoặc nhiều validator hành động thay mặt họ và với tư cách là một phần nào đó trong trái phiếu của validator có thể không nhất thiết phải thuộc sở hữu của chính validator mà là của những người này người đề cử. validator phải chạy triển khai ứng dụng khách chuỗi chuyển tiếp với độ khả dụng và băng thông cao. Tại mỗi khối nút phải sẵn sàng chấp nhận vai trò phê chuẩn một khối mới trên parachain được chỉ định. Quá trình này liên quan đến việc tiếp nhận, xác nhận và xuất bản lại ứng cử viên khối. Việc đề cử mang tính quyết định nhưng hầu như không thể đoán trước được nhiều. Vì validator không thể được mong đợi một cách hợp lý là sẽ duy trì một hệ thống được đồng bộ hóa hoàn toàn cơ sở dữ liệu của tất cả các parachain, dự kiến validator sẽ chỉ định nhiệm vụ đưa ra một đề xuất mới khối parachain cho bên thứ ba, được gọi là đối tác. Sau khi tất cả các khối parachain mới đã được phê duyệt hợp lệ bởi các nhóm con validator được chỉ định của chúng, validators sau đó phải phê chuẩn chính khối chuỗi chuyển tiếp. Điều này liên quan đến cập nhật trạng thái của hàng đợi giao dịch (về cơ bản di chuyển dữ liệu từ hàng đợi đầu ra của parachain sang hàng đợi khác hàng đợi đầu vào của parachain), xử lý các giao dịch của bộ giao dịch chuỗi chuyển tiếp đã được phê duyệt và phê chuẩn khối cuối cùng, bao gồm cả những thay đổi cuối cùng của parachain.POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 5 validator không hoàn thành nghĩa vụ tìm kiếm sự đồng thuận theo các quy tắc của thuật toán đồng thuận đã chọn của chúng tôi sẽ bị trừng phạt. Đối với những thất bại ban đầu, không chủ ý, điều này là thông qua giữ lại phần thưởng của validator. Những thất bại lặp đi lặp lại dẫn đến việc giảm liên kết bảo mật của họ (thông qua việc đốt cháy). Các hành động có hại có thể xảy ra như ký hai lần hoặc âm mưu cung cấp một khối không hợp lệ dẫn đến việc mất toàn bộ trái phiếu (bị đốt cháy một phần nhưng phần lớn được trao cho cho người cung cấp thông tin và người trung thực). Theo một nghĩa nào đó, validator tương tự như nhóm khai thác của PoW hiện tại blockchains. 4.2. Người đề cử. Người được đề cử là bên nắm giữ cổ phần người đóng góp vào trái phiếu bảo đảm của validator. Họ không có vai trò bổ sung nào ngoại trừ việc bố trí vốn rủi ro và như như vậy để báo hiệu rằng họ tin tưởng một validator cụ thể (hoặc được thiết lập) để hành động có trách nhiệm trong việc duy trì mạng. Họ nhận được sự tăng hoặc giảm theo tỷ lệ trong khoản tiền gửi của họ tùy theo mức tăng trưởng của trái phiếu họ đóng góp. Cùng với những người đối chiếu, tiếp theo, những người được đề cử nằm trong một số có ý nghĩa tương tự như các công cụ khai thác của mạng PoW ngày nay. 4.3. Người hợp tác. Đối chiếu giao dịch (gọi tắt là đối chiếu) là các bên hỗ trợ validator tạo ra các khối parachain. Họ duy trì một “nút đầy đủ” cho một parachain cụ thể; có nghĩa là họ giữ lại tất cả những gì cần thiết thông tin để có thể tạo các khối mới và thực thi giao dịch theo cách tương tự như cách các thợ mỏ thực hiện trên PoW blockchain hiện tại. Trong hoàn cảnh bình thường, họ sẽ đối chiếu và thực hiện các giao dịch để tạo ra một bản ghi chưa được niêm phong chặn và cung cấp nó cùng với kiến thức bằng không bằng chứng cho một hoặc nhiều validator hiện chịu trách nhiệm về đề xuất một khối parachain. Bản chất chính xác của mối quan hệ giữa người đối chiếu, người đề cử và validator có thể sẽ thay đổi theo thời gian. Ban đầu, chúng tôi mong đợi những người cộng tác sẽ hợp tác rất chặt chẽ với validators, vì sẽ chỉ có một vài (có lẽ chỉ một) parachain với khối lượng giao dịch ít. các Việc triển khai ứng dụng khách ban đầu sẽ bao gồm các RPC để cho phép nút đối chiếu parachain để cung cấp vô điều kiện nút (chuỗi chuyển tiếp) validator với một parachain hợp lệ có thể được chứng minh khối. Vì chi phí duy trì phiên bản được đồng bộ hóa của tất cả các parachain như vậy đều tăng lên, chúng tôi hy vọng sẽ thấy thêm cơ sở hạ tầng sẵn có sẽ giúp tách biệt các nghĩa vụ đối với các đảng độc lập, có động cơ kinh tế. Cuối cùng, chúng tôi hy vọng sẽ thấy các nhóm đối tác cạnh tranh thu nhiều phí giao dịch nhất. Những người đối chiếu như vậy có thể ký hợp đồng để phục vụ validator cụ thể trong một khoảng thời gian để được chia sẻ liên tục trong số tiền thưởng. Ngoài ra, những người cộng tác “tự do” có thể chỉ cần tạo một thị trường cung cấp các khối parachain hợp lệ để đổi lấy phần thưởng cạnh tranh được trả ngay lập tức. Tương tự, nhóm đề cử phi tập trung sẽ cho phép nhiều những người tham gia liên kết để phối hợp và chia sẻ nhiệm vụ của một validator. Khả năng tập hợp này đảm bảo sự tham gia cởi mở dẫn đến một hệ thống phi tập trung hơn. 4.4. Ngư dân. Không giống như hai bên hoạt động còn lại, ngư dân không liên quan trực tiếp đến việc tạo khối quá trình. Đúng hơn họ là những “thợ săn tiền thưởng” độc lập được thúc đẩy bởi một phần thưởng lớn. Chính xác là do sự tồn tại của ngư dân, chúng tôi cho rằng những hành vi sai trái hiếm khi xảy ra và khi chúng xảy ra chỉ do bên liên quan bất cẩn với việc bảo mật khóa bí mật, chứ không phải thông qua mục đích xấu. Cái tên đến từ tần suất thưởng dự kiến, yêu cầu tối thiểu để tham gia và quy mô phần thưởng cuối cùng. Ngư dân nhận được phần thưởng thông qua việc chứng minh kịp thời rằng ít nhất một bên liên quan đã hành động trái pháp luật. Hành động trái pháp luật bao gồm việc ký hai khối với cùng một khối gốc đã được phê duyệt hoặc, trong trường hợp của parachain, giúp phê chuẩn một khối không hợp lệ khối. Để ngăn chặn việc khen thưởng quá mức hoặc sự thỏa hiệp và sử dụng trái phép khóa bí mật của phiên, phần thưởng cơ bản cho việc cung cấp tin nhắn được ký bất hợp pháp của một validator là tối thiểu. Phần thưởng này tăng tiệm cận khi càng nhiều chứng thực chữ ký bất hợp pháp từ validator khác là được cung cấp ngụ ý một cuộc tấn công thực sự. Đường tiệm cận được thiết lập ở mức 66% theo khẳng định bảo mật cơ sở của chúng tôi rằng ít nhất hai phần ba validator hành động nhân từ. Fishermen có phần giống với “các nút đầy đủ” trong hệ thống blockchain ngày nay mà tài nguyên cần thiết tương đối nhỏ và cam kết về thời gian hoạt động ổn định và băng thông là không cần thiết. Ngư dân có sự khác biệt ở điểm này nhiều như họ phải đăng một trái phiếu nhỏ.Liên kết này ngăn cản các cuộc tấn công sybil do lãng phí validators thời gian và tính toán tài nguyên. Có thể rút ngay lập tức, có lẽ là không nhiều hơn số tiền tương đương với một vài đô la và có thể dẫn đến để gặt hái một phần thưởng khổng lồ từ việc phát hiện ra hành vi sai trái 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 قابلية التشغيل البيني "سلسلة مظلات افتراضية" آمنة بشكل معقول بين الشبكتين، على الرغم من أنه جهد كبير بجدول زمني غير مؤكد، ومن المحتمل جدًا مما يتطلب تعاون الجهات المعنية في ذلك شبكة.
Tổng quan về thiết kế
Phần này nhằm mục đích cung cấp một cái nhìn tổng quan ngắn gọn về toàn bộ hệ thống. Sự thăm dò kỹ lưỡng hơn về hệ thống được đưa ra trong phần tiếp theo nó. 5.1. Sự đồng thuận. Trên chuỗi chuyển tiếp, Polkadot đạt được sự đồng thuận ở mức độ thấp đối với một tập hợp các thông tin có giá trị được các bên đồng ý chặn thông qua thuật toán chịu lỗi Byzantine không đồng bộ hiện đại (BFT). Thuật toán sẽ được lấy cảm hứng bởi Tendermint đơn giản [11] và hơn thế nữa có liên quan đến HoneyBadgerBFT [14]. Cái sau cung cấp một sự đồng thuận hiệu quả và có khả năng chấp nhận sai sót đối với một hành động tùy tiện cơ sở hạ tầng mạng bị lỗi, được cung cấp một tập hợp các cơ quan có thẩm quyền hầu như lành tính hoặc validator. Đối với mạng kiểu bằng chứng xác thực (PoA), riêng điều này sẽ là đủ, tuy nhiên Polkadot được cho là cũng có thể triển khai như một mạng hoàn toàn mở và công khai tình huống mà không có bất kỳ tổ chức cụ thể hoặc đáng tin cậy nào thẩm quyền cần thiết để duy trì nó. Như vậy chúng ta cần một phương tiện xác định một tập hợp validator và khuyến khích họ phải thành thật. Đối với điều này, chúng tôi sử dụng lựa chọn dựa trên PoS tiêu chí. 5.2. Chứng minh tiền đặt cược. Chúng tôi giả sử rằng mạng sẽ có một số phương tiện để đo lường “cổ phần” là bao nhiêu bất kỳ tài khoản cụ thể nào cũng có. Để dễ so sánh với các hệ thống có sẵn, chúng ta sẽ gọi đơn vị đo là “tokens”. Thật không may, thuật ngữ này ít lý tưởng hơn cho một nhiều lý do, nhất là việc chỉ đơn giản là một đại lượng vô hướng giá trị liên quan đến một tài khoản, không có khái niệm về tính cá nhân. Chúng tôi cho rằng validator sẽ được bầu không thường xuyên (nhiều nhất là một lần mỗi ngày nhưng có lẽ hiếm khi một lần mỗi quý), thông qua chương trình Bằng chứng cổ phần được đề cử (NPoS). Việc khuyến khích có thể xảy ra thông qua việc phân bổ theo tỷ lệPOLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 6 Rơle chuỗi Nhóm xác thực (mỗi màu được tô màu bởi nó parachain được chỉ định) Giao dịch (gửi bởi tác nhân bên ngoài) Parachain cầu parachain ảo (ví dụ: Ethereum) Parachain Parachain hàng đợi và I/O Giao dịch lan truyền Chặn việc nộp hồ sơ ứng viên đơn hàng thứ 2 Chuỗi rơle cộng đồng parachain Tài khoản Giao dịch trong nước Giao dịch đi Giao dịch liên chuỗi (được quản lý bởi validators) đối chiếu Khối lan truyền ngư dân Hình 2. Sơ đồ tóm tắt của hệ thống Polkadot. Điều này cho thấy các bộ đối chiếu đang thu thập và truyền bá các giao dịch của người dùng, cũng như truyền bá các ứng cử viên khối cho ngư dân và validators. Nó cũng cho thấy cách một tài khoản có thể đăng một giao dịch được thực hiện từ parachain của nó, thông qua chuỗi chuyển tiếp và vào một parachain khác, nơi nó có thể được hiểu là một giao dịch đối với một tài khoản ở đó. số tiền đến từ việc mở rộng cơ sở token (tối đa 100% mỗi năm, mặc dù nhiều khả năng là khoảng 10%) cùng với bất kỳ khoản phí giao dịch nào được thu thập. Trong khi việc mở rộng cơ sở tiền tệ thường dẫn đến lạm phát, vì tất cả chủ sở hữu token sẽ có cơ hội tham gia công bằng, không chủ sở hữu token nào sẽ phải chịu sự giảm giá trị tài sản của mình nắm giữ theo thời gian miễn là họ vui vẻ chấp nhận vai trò trong cơ chế đồng thuận Một tỷ lệ cụ thể trong số token sẽ được nhắm mục tiêu cho quy trình staking; cái việc mở rộng cơ sở token hiệu quả sẽ được điều chỉnh thông qua một cơ chế dựa trên thị trường để đạt được mục tiêu này. Những người xác nhận được liên kết chặt chẽ bởi cổ phần của họ; thoát ra Trái phiếu của validator vẫn được giữ nguyên lâu sau khi nhiệm vụ của validator chấm dứt (có thể là khoảng 3 tháng). Dài thế này thời gian thanh lý trái phiếu cho phép hành vi sai trái trong tương lai có thể xảy ra bị trừng phạt cho đến khi kiểm tra dây chuyền định kỳ. Hành vi sai trái dẫn đến hình phạt, chẳng hạn như giảm thưởng hoặc, trong trường hợp cố ý làm tổn hại đến tính toàn vẹn của mạng, validator mất một phần hoặc toàn bộ cổ phần cho validator khác, người cung cấp thông tin hoặc các bên liên quan nói chung (thông qua việc đốt cháy). Ví dụ: validator người cố gắng phê chuẩn cả hai nhánh của một ngã ba (đôi khi được gọi là cuộc tấn công “tầm ngắn”) có thể được xác định và bị trừng phạt theo cách thứ hai. Các cuộc tấn công tầm xa “không có gì đáng đe dọa”4 bị phá vỡ thông qua một chốt “điểm kiểm tra” đơn giản nhằm ngăn chặn việc tổ chức lại chuỗi nguy hiểm của nhiều hơn một độ sâu chuỗi cụ thể. Để đảm bảo các máy khách mới được đồng bộ hóa không thể bị lừa vào chuỗi sai, thường xuyên “hard fork” sẽ xảy ra (nhiều nhất là trong cùng thời kỳ của validators' thanh lý trái phiếu) mã hóa cứng khối điểm kiểm tra gần đây hash vào khách hàng. Điều này hoạt động tốt với một biện pháp giảm dấu chân hơn nữa là “độ dài chuỗi hữu hạn” hoặc thiết lập lại định kỳ khối Genesis. 5.3. Parachains và Collators. Mỗi parachain được các điều kiện bảo mật tương tự như chuỗi chuyển tiếp: cái Các tiêu đề của parachains được niêm phong trong khối chuỗi chuyển tiếp đảm bảo không tổ chức lại hoặc "chi tiêu gấp đôi" sau khi được xác nhận. Đây là sự đảm bảo an ninh tương tự như sự đảm bảo an ninh được cung cấp bởi chuỗi bên và hoạt động khai thác hợp nhất của Bitcoin. Tuy nhiên, Polkadot cũng cung cấp sự đảm bảo mạnh mẽ rằng việc chuyển đổi trạng thái của parachain là hợp lệ. Cái này xảy ra thông qua tập hợp validator được phân chia ngẫu nhiên bằng mật mã thành các tập hợp con; một tập hợp con cho mỗi parachain, các tập hợp con có khả năng khác nhau trên mỗi khối. Cái này thiết lập thường ngụ ý rằng thời gian chặn của parachains sẽ ít nhất phải dài bằng chuỗi chuyển tiếp. cụ thể phương tiện xác định phân vùng nằm ngoài phạm vi 4Cuộc tấn công như vậy là lúc đối thủ tạo ra một chuỗi lịch sử hoàn toàn mới từ khối khởi đầu trở đi. Thông qua việc kiểm soát một phần cổ phần tương đối không đáng kể khi bù đắp, họ có thể tăng dần phần cổ phần của mình so với tất cả những người khác các bên liên quan vì họ là những người tham gia tích cực duy nhất trong lịch sử thay thế của họ. Vì không có giới hạn vật lý nội tại nào tồn tại trong quá trình tạo ra của các khối (không giống như PoW nơi phải tiêu tốn năng lượng tính toán khá thực), họ có thể tạo ra một chuỗi dài hơn chuỗi thực trong một khoảng thời gian tương đối ngắn và có khả năng làm cho nó dài nhất và tốt nhất, tiếp quản trạng thái chuẩn của mạng.POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 7 của tài liệu này nhưng có thể sẽ dựa trên khung tiết lộ cam kết tương tự như RanDAO [19] hoặc sử dụng dữ liệu kết hợp từ các khối trước của mỗi parachain theo mật mã hash được bảo mật. Các tập hợp con validator như vậy được yêu cầu để cung cấp ứng cử viên khối parachain được đảm bảo hợp lệ (trên nỗi đau của sự tịch thu trái phiếu). Hiệu lực xoay quanh hai điểm quan trọng; trước hết là nó có giá trị về bản chất—rằng tất cả các chuyển đổi trạng thái đều được thực hiện một cách trung thực và tất cả dữ liệu bên ngoài được tham chiếu (tức là các giao dịch) có giá trị để đưa vào. Thứ hai, bất kỳ dữ liệu nào nằm ngoài phạm vi của nó ứng viên, chẳng hạn như các giao dịch bên ngoài, có tính sẵn sàng cao để người tham gia có thể tải xuống và thực thi khối theo cách thủ công.5 Người xác thực chỉ có thể cung cấp khối “null” không chứa dữ liệu “giao dịch” bên ngoài, nhưng có thể gặp rủi ro bị giảm phần thưởng nếu họ làm như vậy. Họ làm việc bên cạnh một giao thức tin đồn parachain với các đối tác—các cá nhân người đối chiếu các giao dịch thành các khối và cung cấp bằng chứng không tương tác, không có kiến thức rằng khối đó cấu thành một phần tử con hợp lệ của phần tử mẹ của nó (và thực hiện bất kỳ giao dịch nào phí cho rắc rối của họ). Các giao thức parachain phải tự xác định phương tiện ngăn chặn thư rác: không có khái niệm cơ bản nào về “đo lường tài nguyên máy tính” hoặc “phí giao dịch” được áp đặt bởi chuỗi chuyển tiếp. Giao thức chuỗi chuyển tiếp cũng không có sự thực thi trực tiếp nào về vấn đề này (mặc dù nó khó có khả năng các bên liên quan sẽ chọn áp dụng một parachain không cung cấp một cơ chế phù hợp). Đây là một sự đồng ý rõ ràng về khả năng của các chuỗi không giống như Ethereum, ví dụ: một chuỗi giống Bitcoin có mô hình tính phí đơn giản hơn nhiều hoặc một số mô hình ngăn chặn thư rác khác chưa được đề xuất. Bản thân chuỗi chuyển tiếp của Polkadot có thể sẽ tồn tại dưới dạng Ethereum giống như tài khoản và chuỗi trạng thái, có thể là phái sinh EVM. Vì các nút chuỗi chuyển tiếp sẽ được yêu cầu thực hiện các xử lý đáng kể khác, thông lượng giao dịch sẽ được giảm thiểu một phần thông qua phí giao dịch lớn và nếu mô hình nghiên cứu của chúng tôi yêu cầu, giới hạn kích thước khối. 5.4. Truyền thông liên chuỗi. Thành phần quan trọng cuối cùng của Polkadot là giao tiếp giữa các chuỗi. Kể từ khi parachains có thể có một số loại kênh thông tin giữa chúng, chúng tôi cho phép mình xem xét Polkadot một đa chuỗi có thể mở rộng. Trong trường hợp Polkadot, việc giao tiếp càng đơn giản càng tốt: các giao dịch được thực hiện trong một parachain (theo logic của chuỗi đó) có thể ảnh hưởng đến việc gửi một giao dịch vào parachain thứ hai hoặc có thể là chuỗi chuyển tiếp. Giống như các giao dịch bên ngoài trên blockchains sản xuất, chúng hoàn toàn không đồng bộ và không có khả năng nội tại để họ trả lại bất kỳ loại thông tin trở lại nguồn gốc của nó. Điểm đến: được dữ liệu từ trước validator của khối. Tài khoản nhận được bài viết: mục nhập bị xóa khỏi xâm nhập Merkle tree Tài khoản gửi bài: mục được đặt trong đi ra Merkle tree cho điểm đến parachain đi ra Nguồn: chia sẻ dữ liệu với khối tiếp theo validators bằng chứng của bài viết được lưu trữ trong lối ra parachain Merkle cây tham chiếu định tuyến được đặt trong parachain đích xâm nhập Merkle tree xâm nhập Hình 3. Sơ đồ cơ bản thể hiện các phần chính của định tuyến cho bài đăng giao dịch (“bài đăng”). Để đảm bảo độ phức tạp thực hiện tối thiểu, tối thiểu rủi ro và tối thiểu áo khoác thẳng của tương lai kiến trúc parachain, các giao dịch liên chuỗi này được thực sự không thể phân biệt được với các giao dịch được ký kết bên ngoài tiêu chuẩn. Giao dịch có phân đoạn gốc, cung cấp khả năng xác định parachain và một địa chỉ có thể có kích thước tùy ý. Không giống như các hệ thống phổ biến hiện nay như Bitcoin và Ethereum, các giao dịch liên chuỗi không đi kèm với bất kỳ hình thức “thanh toán” phí liên quan nào; mọi khoản thanh toán như vậy phải được quản lý thông qua logic đàm phán trên parachain nguồn và đích. Một hệ thống như vậy được đề xuất cho Bản phát hành Serenity của Ethereum [7] sẽ là một phương tiện đơn giản Tuy nhiên, việc quản lý việc thanh toán tài nguyên xuyên chuỗi như vậy chúng tôi cho rằng những người khác có thể chiếm ưu thế vào thời điểm thích hợp. Các giao dịch liên chuỗi được giải quyết bằng cách sử dụng một cách đơn giản cơ chế xếp hàng dựa trên Merkle tree để đảm bảo sự chính xác. Nhiệm vụ của người bảo trì chuỗi chuyển tiếp là di chuyển các giao dịch trên hàng đợi đầu ra của một parachain vào hàng đợi đầu vào của parachain đích. các các giao dịch đã được thông qua sẽ được tham chiếu trên chuỗi chuyển tiếp, tuy nhiên không liên quanbản thân các giao dịch chuỗi ay. Để ngăn chặn một parachain gửi thư rác cho một parachain khác bằng giao dịch, để một giao dịch được gửi đi, cần phải có hàng đợi đầu vào của đích không quá lớn thời điểm kết thúc khối trước đó. Nếu đầu vào hàng đợi quá lớn sau khi xử lý khối thì nó được coi là “bão hòa” và không có giao dịch nào có thể được chuyển đến nó trong các khối tiếp theo cho đến khi giảm trở lại dưới mức giới hạn. Những hàng đợi này được quản lý trên chuỗi chuyển tiếp cho phép các parachain xác định độ bão hòa của nhau tình trạng; theo cách này, một nỗ lực thất bại trong việc đăng một giao dịch đến một đích bị đình trệ có thể được báo cáo đồng bộ. (Mặc dù không có đường dẫn trở lại tồn tại nên nếu giao dịch thứ cấp không thành công vì lý do đó thì nó không thể được báo cáo lại tới người gọi ban đầu và một số phương tiện phục hồi khác sẽ phải diễn ra.) 5.5. Polkadot và Ethereum. Do tính hoàn thiện Turing của Ethereum, chúng tôi hy vọng có nhiều cơ hội để Polkadot và Ethereum có thể tương tác với nhau, ít nhất là trong một số giới hạn an ninh dễ dàng được khấu trừ. Nói tóm lại, chúng tôi hình dung rằng các giao dịch từ Polkadot có thể được ký bởi validators và sau đó được đưa vào 5Nhiệm vụ như vậy có thể được chia sẻ giữa các validator hoặc có thể trở thành nhiệm vụ được chỉ định của một tập hợp các validator được liên kết chặt chẽ được gọi là người bảo đảm sẵn có.
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 8 Ethereum nơi chúng có thể được diễn giải và ban hành bởi một hợp đồng chuyển tiếp giao dịch. Ở hướng khác, chúng tôi thấy trước việc sử dụng nhật ký (sự kiện) được định dạng đặc biệt đến từ một “hợp đồng đột phá” để cho phép xác minh nhanh chóng rằng một tin nhắn cụ thể sẽ được chuyển tiếp. 5.5.1. Polkadot đến Ethereum. Thông qua việc lựa chọn một BFT cơ chế đồng thuận với validator được hình thành từ một tập hợp các bên liên quan được xác định thông qua bỏ phiếu phê duyệt cơ chế, chúng ta có thể đạt được sự đồng thuận an toàn với một thay đổi không thường xuyên và số lượng khiêm tốn validators. Trong một hệ thống có tổng cộng 144 validators, thời gian khối là 4 giây và độ chính xác 900 khối (cho phép mã độc hành vi như bỏ phiếu hai lần sẽ bị báo cáo, bị trừng phạt và được sửa chữa), tính hợp lệ của một khối có thể được xác định một cách hợp lý được coi là đã được chứng minh thông qua ít nhất 97 chữ ký (hai phần ba của 144 cộng một) và thời gian xác minh kéo dài 60 phút sau đó mà không có khiếu nại nào được đưa ra. Ethereum có thể lưu trữ một “hợp đồng đột nhập” có thể duy trì 144 bên ký kết và được kiểm soát bởi họ. Vì việc khôi phục chữ ký số theo đường cong elip (ECDSA) chỉ mất 3.000 gas trong EVM và kể từ đó chúng tôi có thể chỉ muốn việc xác thực diễn ra trên một siêu đa số validators (thay vì hoàn toàn nhất trí), chi phí cơ bản của Ethereum xác nhận rằng một lệnh đã được xác thực hợp lệ vì đến từ mạng Polkadot sẽ tiêu tốn không quá 300.000 gas—chỉ 6% trong số đó tổng giới hạn khí khối ở mức 5,5M. Tăng số lượng validators (cần thiết để xử lý hàng chục chuỗi) chắc chắn sẽ làm tăng chi phí này, tuy nhiên Người ta mong đợi băng thông giao dịch của Ethereum sẽ tăng theo thời gian khi công nghệ hoàn thiện và cơ sở hạ tầng được cải thiện. Cùng với thực tế là không tất cả validator đều cần được tham gia (ví dụ: chỉ có mức cao nhất validator đã đặt cược có thể được yêu cầu thực hiện một nhiệm vụ như vậy) giới hạn của cơ chế này mở rộng khá tốt. Giả sử luân chuyển hàng ngày validators như vậy (tức là khá thận trọng—hàng tuần hoặc thậm chí hàng tháng có thể được chấp nhận), thì chi phí cho mạng lưới duy trì cầu chuyển tiếp Ethereum này sẽ có giá khoảng 540.000 gas mỗi ngày hoặc, theo giá gas hiện tại, là 45 USD mỗi năm. Một giao dịch cơ bản được chuyển tiếp qua cầu sẽ có chi phí khoảng 0,11 USD; việc tính toán hợp đồng bổ sung sẽ tốn kém tất nhiên là nhiều hơn nữa. Bằng cách đệm và đóng gói các giao dịch cùng với nhau, chi phí ủy quyền đột nhập có thể dễ dàng được tính toán được chia sẻ, giảm đáng kể chi phí cho mỗi giao dịch; nếu cần 20 giao dịch trước khi chuyển tiếp thì chi phí để chuyển tiếp một giao dịch cơ bản sẽ giảm xuống khoảng 0,01 USD. Một giải pháp thay thế thú vị và rẻ hơn cho mô hình hợp đồng đa chữ ký này là sử dụng chữ ký ngưỡng để đạt được ngữ nghĩa quyền sở hữu đa phương. Trong khi các sơ đồ chữ ký ngưỡng cho ECDSA đắt tiền về mặt tính toán, đối với các chương trình khác chẳng hạn như chữ ký Schnorr là rất hợp lý. Ethereum có kế hoạch giới thiệu những thứ nguyên thủy sẽ tạo ra những thứ như vậy các chương trình rẻ tiền để sử dụng trong đợt hardfork Metropolis sắp tới. Nếu một phương tiện như vậy có thể được sử dụng, chi phí khí đốt để chuyển tiếp giao dịch Polkadot vào Ethereum mạng sẽ giảm đáng kể xuống gần bằng không chi phí chung vượt quá chi phí cơ bản để xác nhận ký và thực hiện giao dịch cơ bản. Trong mô hình này, các nút validator của Polkadot sẽ có không làm gì khác ngoài việc ký tin nhắn. Để các giao dịch thực sự được định tuyến trên mạng Ethereum, chúng tôi giả sử chính validator cũng sẽ cư trú trên mạng Ethereum hoặc nhiều khả năng là những khoản tiền thưởng nhỏ đó được cung cấp cho tác nhân đầu tiên chuyển tiếp tin nhắn trên vào mạng (tiền thưởng có thể được trả một cách tầm thường cho người khởi tạo giao dịch). 5.5.2. Ethereum tới Polkadot. Bắt các giao dịch được thực hiện được chuyển tiếp từ Ethereum đến Polkadot sử dụng khái niệm nhật ký đơn giản. Khi hợp đồng Ethereum muốn gửi giao dịch đến một parachain cụ thể của Polkadot, nó chỉ cần gọi đến một “hợp đồng đột phá” đặc biệt. Hợp đồng đột phá sẽ nhận bất kỳ khoản thanh toán nào có thể được yêu cầu và đưa ra hướng dẫn ghi nhật ký để sự tồn tại của nó có thể được chứng minh thông qua bằng chứng Merkle và xác nhận rằng tiêu đề của khối tương ứng là hợp lệ và kinh điển. Trong hai điều kiện sau, tính hợp lệ có lẽ là điều kiện dễ chứng minh nhất. Về nguyên tắc, yêu cầu duy nhất làcho mỗi nút Polkadot cần bằng chứng (tức là các nút validator được chỉ định) để chạy một phiên bản được đồng bộ hóa hoàn toàn của nút Ethereum tiêu chuẩn. Thật không may, bản thân điều này lại là một sự phụ thuộc khá nặng nề. Thêm nữa phương pháp nhẹ nhàng sẽ là sử dụng một bằng chứng đơn giản rằng tiêu đề được đánh giá chính xác thông qua việc chỉ cung cấp cần có một phần trạng thái của Ethereum để thực thi đúng cách các giao dịch trong khối và kiểm tra xem nhật ký (có trong biên lai khối) có hợp lệ hay không. Những thứ “giống SPV”6 bằng chứng có thể vẫn yêu cầu một lượng thông tin đáng kể; một cách thuận tiện, chúng thường không cần thiết ở tất cả: hệ thống liên kết bên trong Polkadot sẽ cho phép liên kết bên thứ ba gửi tiêu đề có nguy cơ bị mất mối ràng buộc nếu một số bên thứ ba khác (chẳng hạn như “ngư dân”, xem 6.2.3) cung cấp bằng chứng rằng tiêu đề không hợp lệ (cụ thể là gốc nhà nước hoặc gốc nhận là kẻ mạo danh). Trên mạng PoW chưa hoàn thiện như Ethereum, tính kinh điển không thể được chứng minh một cách thuyết phục. Để giải quyết vấn đề này, các ứng dụng cố gắng dựa vào bất kỳ loại nguyên nhân-kết quả phụ thuộc vào chuỗi, hãy đợi một số “xác nhận” hoặc cho đến khi giao dịch phụ thuộc ở một mức nào đó độ sâu cụ thể trong chuỗi. Vào Ethereum, cái này độ sâu thay đổi từ 1 khối đối với các giao dịch ít giá trị nhất mà không có sự cố mạng nào được xác định đến 1200 khối như trước đây trường hợp này trong lần phát hành Frontier đầu tiên cho các sàn giao dịch. Trên mạng “Homestead” ổn định, hình này nằm ở 120 khối cho hầu hết các sàn giao dịch và chúng tôi có thể sẽ lấy một tham số tương tự. Vì vậy chúng tôi có thể tưởng tượng của chúng tôi Polkadot bên Ethereumgiao diện có một số chức năng đơn giản: có thể chấp nhận tiêu đề mới từ mạng Ethereum và xác thực PoW, để có thể chấp nhận một số bằng chứng cho thấy nhật ký cụ thể được phát ra bởi hợp đồng đột phá bên Ethereum cho tiêu đề có đủ độ sâu (và chuyển tiếp tin nhắn tương ứng trong Polkadot) và cuối cùng để có thể chấp nhận bằng chứng rằng một bằng chứng đã được chấp nhận trước đó nhưng tiêu đề chưa được ban hành chứa gốc biên nhận không hợp lệ. Để thực sự có được dữ liệu tiêu đề Ethereum (và bất kỳ bằng chứng SPV hoặc sự bác bỏ tính hợp lệ/kinh điển nào) vào mạng Polkadot, một sự khuyến khích chuyển tiếp 6SPV đề cập đến Xác minh thanh toán đơn giản hóa trong Bitcoin và mô tả phương pháp để khách hàng xác minh giao dịch trong khi chỉ giữ lại một bản sao của tất cả các tiêu đề khối của chuỗi PoW dài nhất.POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 9 dữ liệu là cần thiết. Điều này có thể đơn giản như một khoản thanh toán (được tài trợ từ phí thu được từ phía Ethereum) đã thanh toán cho bất kỳ ai có thể chuyển tiếp một khối hữu ích có tiêu đề là hợp lệ. Người xác thực sẽ được yêu cầu lưu giữ thông tin liên quan đến vài nghìn khối cuối cùng để có thể quản lý các nhánh, thông qua một số phương tiện giao thức nội tại hoặc thông qua hợp đồng được duy trì trên chuỗi rơle. 5.6. Polkadot và Bitcoin. Bitcoin tương tác đưa ra một thử thách thú vị dành cho Polkadot: cái gọi là “chốt hai chiều” sẽ là một phần cơ sở hạ tầng hữu ích có ở phía của cả hai mạng. Tuy nhiên, do những hạn chế của Bitcoin, việc cung cấp chốt như vậy một cách an toàn là một công việc không tầm thường. Thực hiện giao dịch từ Bitcoin tới Polkadot về nguyên tắc có thể được thực hiện bằng quy trình tương tự như quy trình dành cho Ethereum; một “địa chỉ đột phá” được kiểm soát theo cách nào đó bởi Polkadot validator có thể nhận token được chuyển (và dữ liệu được gửi cùng với chúng). Bằng chứng SPV có thể được cung cấp bởi oracle được khuyến khích và, cùng với thời gian xác nhận, tiền thưởng được trao cho xác định các khối không chuẩn ngụ ý giao dịch đã được “chi tiêu gấp đôi”. Bất kỳ token nào sau đó được sở hữu trong Về nguyên tắc, “địa chỉ đột phá” sẽ được kiểm soát bởi chính validator đó để phân tán sau này. Tuy nhiên, vấn đề là làm thế nào để có thể kiểm soát khoản tiền gửi một cách an toàn từ bộ validator luân phiên. Không giống Ethereum có thể đưa ra quyết định tùy ý dựa trên dựa trên sự kết hợp của chữ ký, Bitcoin về cơ bản là hạn chế hơn, với hầu hết khách hàng chỉ chấp nhận các giao dịch đa chữ ký với tối đa 3 bên. Việc mở rộng con số này lên 36, hoặc thậm chí hàng nghìn như mong muốn cuối cùng, là không thể theo giao thức hiện tại. Một tùy chọn là thay đổi giao thức Bitcoin để kích hoạt chức năng như vậy, tuy nhiên cái gọi là “hard fork” trong Bitcoin thế giới rất khó sắp xếp việc đánh giá bằng những nỗ lực gần đây. Một khả năng là việc sử dụng chữ ký ngưỡng, các sơ đồ mật mã cho phép một công chúng có thể nhận dạng được một cách duy nhất khóa được kiểm soát hiệu quả bởi nhiều “bộ phận” bí mật, một số hoặc tất cả trong số đó phải được sử dụng để tạo chữ ký hợp lệ. Thật không may, chữ ký ngưỡng tương thích với ECDSA của Bitcoin rất tốn kém về mặt tính toán tạo và có độ phức tạp đa thức. Các phương án khác như chữ ký Schnorr mang lại chi phí thấp hơn nhiều, tuy nhiên dòng thời gian mà chúng có thể được đưa vào Bitcoin giao thức không chắc chắn. Vì sự an toàn cuối cùng của tiền gửi phụ thuộc vào một số validator được liên kết, một tùy chọn khác là giảm số lượng người nắm giữ khóa đa chữ ký xuống chỉ còn rất nhiều tập hợp con liên kết của tổng validators sao cho ngưỡng đó chữ ký trở nên khả thi (hoặc tệ nhất là chữ ký gốc của Bitcoin có thể có nhiều chữ ký). Điều này tất nhiên làm giảm tổng số tiền trái phiếu có thể được khấu trừ để bồi thường nếu validator hành xử bất hợp pháp, tuy nhiên điều này là một sự xuống cấp duyên dáng, chỉ đơn giản là thiết lập giới hạn trên của số tiền có thể chạy một cách an toàn giữa hai mạng (hoặc thực tế là trên % tổn thất nếu một cuộc tấn công từ validators thành công). Vì vậy, chúng tôi tin rằng sẽ không phi thực tế khi đặt một “parachain ảo” có khả năng tương tác an toàn hợp lý Bitcoin giữa hai mạng, mặc dù vậy vẫn là một nỗ lực đáng kể với thời gian không chắc chắn và hoàn toàn có thể đòi hỏi sự hợp tác của các bên liên quan trong đó mạng.
البروتوكول بالتفصيل
يمكن تقسيم البروتوكول تقريبًا إلى ثلاثة الأجزاء: آلية التوافق، واجهة الباراشين وتوجيه المعاملات بين السلاسل. 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.
Giao thức chi tiết
Giao thức có thể được chia đại khái thành ba các bộ phận: cơ chế đồng thuận, giao diện parachain và định tuyến giao dịch liên chuỗi. 6.1. Chuỗi rơle Hoạt động. các chuỗi chuyển tiếp sẽ có thể là một chuỗi tương tự như Ethereum ở chỗ nó dựa trên trạng thái với địa chỉ ánh xạ trạng thái tới tài khoản thông tin, chủ yếu là số dư và (để tránh lặp lại) quầy giao dịch. Việc đặt tài khoản ở đây nhằm đáp ứng một mục đích: cung cấp thông tin kế toán mà danh tính sở hữu số lượng cổ phần trong hệ thống là bao nhiêu.7 Tuy nhiên, sẽ có những khác biệt đáng chú ý: • Hợp đồng không thể triển khai thông qua giao dịch; xuất phát từ mong muốn tránh chức năng ứng dụng trên chuỗi chuyển tiếp, nó sẽ không hỗ trợ triển khai công khai các hợp đồng. • Tính toán việc sử dụng tài nguyên (“gas”) không được tính; vì các chức năng duy nhất có sẵn cho mục đích sử dụng công cộng sẽ được khắc phục, cơ sở lý luận đằng sau việc tính toán khí đốt không còn giữ được nữa. Do đó, một khoản phí cố định sẽ được áp dụng trong mọi trường hợp, cho phép đạt được hiệu suất cao hơn từ bất kỳ thực thi mã động có thể cần phải được thực hiện và một hình thức giao dịch đơn giản hơn. • Chức năng đặc biệt được hỗ trợ cho các hợp đồng được liệt kê cho phép thực hiện tự động và xuất ra thông báo mạng. Trong trường hợp chuỗi chuyển tiếp có VM và nó được dựa trên EVM, nó sẽ có một số sửa đổi để đảm bảo tính đơn giản tối đa. Nó có thể sẽ có một số hợp đồng được xây dựng sẵn (tương tự như ở địa chỉ 1-4 trong Ethereum) để cho phép nền tảng cụ thể nhiệm vụ phải được quản lý bao gồm một hợp đồng đồng thuận, một hợp đồng validator và hợp đồng parachain. Nếu không phải là EVM thì phần phụ trợ WebAssembly [2] (wasm) là lựa chọn thay thế phù hợp nhất; trong trường hợp này tổng thể cấu trúc sẽ tương tự, nhưng sẽ không cần vì các hợp đồng tích hợp với Wasm là mục tiêu khả thi cho các ngôn ngữ có mục đích chung hơn là ngôn ngữ chưa trưởng thành và ngôn ngữ hạn chế cho EVM. Những sai lệch có thể xảy ra khác so với giao thức Ethereum hiện tại là hoàn toàn có thể xảy ra, ví dụ như việc đơn giản hóa định dạng biên nhận giao dịch cho phép thực hiện song song các giao dịch không xung đột trong cùng một khối, như đề xuất cho chuỗi thay đổi Serenity. Có thể, mặc dù không chắc chắn, rằng một thứ giống như Serenity Chuỗi “thuần túy” được triển khai như chuỗi chuyển tiếp, cho phép hợp đồng cụ thể để quản lý những thứ như staking token cân đối hơn là biến nó thành một phần cơ bản của giao thức của chuỗi. Hiện tại, chúng tôi cảm thấy điều này khó có thể xảy ra sẽ cung cấp một sự đơn giản hóa giao thức đủ lớn để đáng giá thêm sự phức tạp và sự không chắc chắn liên quan trong việc phát triển nó. 7Là phương tiện thể hiện số tiền mà một chủ sở hữu nhất định chịu trách nhiệm về tính bảo mật chung của hệ thống, các tài khoản cổ phần này sẽ chắc chắn mã hóa một số giá trị kinh tế. Tuy nhiên, cần hiểu rằng vì không có ý định sử dụng những giá trị đó trong bằng bất kỳ cách nào nhằm mục đích trao đổi hàng hóa và dịch vụ trong thế giới thực, cần lưu ý rằng token không được so sánh với tiền tệ và do đó, chuỗi chuyển tiếp vẫn giữ nguyên triết lý hư vô về các ứng dụng.POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 10 Có một số phần chức năng nhỏ cần thiết để quản lý cơ chế đồng thuận, bộ validator, cơ chế xác thực và parachain. Những cái này có thể được thực hiện cùng nhau theo một giao thức nguyên khối. Tuy nhiên, vì lý do tăng cường tính mô-đun, chúng tôi mô tả đây là “hợp đồng” của chuỗi chuyển tiếp. Điều này nên được hiểu là chúng là đối tượng (theo nghĩa lập trình hướng đối tượng) được quản lý bởi cơ chế đồng thuận của chuỗi chuyển tiếp, nhưng không nhất thiết phải như vậy chúng được định nghĩa là các chương trình có mã opcode giống EVM, cũng như thậm chí chúng có thể được định địa chỉ riêng lẻ thông qua hệ thống tài khoản. 6.2. Hợp đồng đặt cọc. Hợp đồng này duy trì bộ validator. Nó quản lý: • tài khoản nào hiện là validators; • có sẵn để trở thành validator trong thời gian ngắn thông báo; • tài khoản nào đã đặt cược đề cử vào một validator; • thuộc tính của từng loại bao gồm staking khối lượng, tỷ lệ thanh toán và địa chỉ được chấp nhận cũng như danh tính (phiên) ngắn hạn. Nó cho phép một tài khoản đăng ký mong muốn trở thành một validator được liên kết (cùng với các yêu cầu của nó), để đề cử một số danh tính và để các validator được liên kết trước đó đăng ký mong muốn thoát khỏi trạng thái này. Nó cũng bao gồm chính bộ máy dành cho cơ chế xác nhận và chuẩn hóa. 6.2.1. Cổ phần-token Thanh khoản. Nói chung là mong muốn có tổng số staking token càng nhiều càng tốt tham gia vào các hoạt động bảo trì mạng kể từ điều này liên kết trực tiếp an ninh mạng với “vốn hóa thị trường” tổng thể của staking token. Điều này có thể dễ dàng được khuyến khích thông qua việc lạm phát tiền tệ và trao số tiền thu được cho những người tham gia với tư cách validators. Tuy nhiên, làm như vậy sẽ có một vấn đề: nếu token bị khóa trong Hợp đồng đặt cược với hình phạt giảm bớt, làm sao một phần đáng kể có thể vẫn còn đủ thanh khoản để cho phép khám phá giá? Một câu trả lời cho vấn đề này là cho phép một hợp đồng phái sinh chuyển tiếp thẳng, đảm bảo token có thể thay thế được trên token đặt cược cơ bản. Điều này rất khó để sắp xếp một cách không tin cậy. Hơn nữa, các token phái sinh này không thể được đối xử bình đẳng vì cùng một lý do khiến các trái phiếu chính phủ khác nhau của các chính phủ Eurozone không thể thay thế được: ở đó là khả năng tài sản cơ bản thất bại và trở thành vô giá trị. Với các chính phủ khu vực đồng Euro, có thể có một mặc định. Với validator đặt cọc token, validator có thể hành động ác ý và bị trừng phạt. Tuân thủ các nguyên lý của mình, chúng tôi chọn giải pháp đơn giản nhất: không phải tất cả token đều được đặt cược. Điều này có nghĩa là một số tỷ lệ (có lẽ là 20%) trong số token sẽ buộc phải duy trì trạng thái thanh khoản. Mặc dù điều này không hoàn hảo xét từ góc độ bảo mật nhưng nó khó có thể tạo ra sự khác biệt cơ bản trong sự an toàn của mạng; 80% số tiền bồi thường có thể từ việc tịch thu trái phiếu vẫn có thể được thực hiện so với “trường hợp hoàn hảo” 100% staking. Tỷ lệ giữa số tiền đặt cọc và số tiền thanh khoản token có thể được nhắm mục tiêu khá đơn giản thông qua cơ chế đấu giá ngược. Về cơ bản, những người nắm giữ token quan tâm đến việc trở thành validator mỗi người sẽ đăng một lời đề nghị cho hợp đồng staking nêu rõ tỷ lệ thanh toán tối thiểu mà họ sẽ yêu cầu thực hiện một phần. Vào đầu mỗi buổi học (các buổi học sẽ xảy ra thường xuyên, có lẽ thường xuyên như một lần mỗi giờ) validator các vị trí sẽ được lấp đầy theo từng vị trí validator cổ phần và tỷ lệ xuất chi. Một thuật toán có thể vì điều này có nghĩa là sẽ nhận những người có giá chào hàng thấp nhất đại diện cho số cổ phần không cao hơn tổng số cổ phần được nhắm mục tiêu chia cho số lượng vị trí và không thấp hơn giới hạn dưới của một nửa số tiền đó. Nếu các khe không thể lấp đầy, giới hạn dưới có thể được giảm đi nhiều lần bởi một số yếu tố để thỏa mãn. 6.2.2. Đề cử. Có thể đề cử một cách đáng tin cậy những cái staking token thành validator đang hoạt động, mang lại cho chúng trách nhiệm về nhiệm vụ của validator. Đề cử tác phẩm thông qua hệ thống bỏ phiếu phê duyệt. Mỗi người đề cử tương lai có thể đăng hướng dẫn lên hợp đồng staking thể hiện một hoặc nhiều validator danh tính dưới quyền của ai trách nhiệm mà họ sẵn sàng giao phó mối quan hệ của mình. Mỗi phiên, trái phiếu của người đề cử được phân tán để được đại diện bởi một hoặc nhiều validators. Thuật toán phân tán tối ưu hóa cho tập hợp validator có tổng số tương đương trái phiếu. Trái phiếu của người đề cử trở thành trách nhiệm thực sự của validator avà thu được lãi suất hoặc phải gánh chịu một giảm nhẹ hình phạt cho phù hợp. 6.2.3. Tịch thu/đốt trái phiếu. Một số hành vi validator nhất định dẫn đến việc giảm bớt mối quan hệ ràng buộc của họ. Nếu trái phiếu bị giảm xuống dưới mức tối thiểu cho phép, phiên kết thúc sớm và một phiên khác bắt đầu. Danh sách không đầy đủ các hành vi sai trái validator có thể bị trừng phạt bao gồm: • Là thành viên của nhóm parachain không thể cung cấp sự đồng thuận về tính hợp lệ của khối parachain; • chủ động ký xác nhận tính hợp lệ của giấy tờ không hợp lệ khối parachain; • không có khả năng cung cấp tải trọng đầu ra trước đó được bình chọn là có sẵn; • không hoạt động trong quá trình đồng thuận; • xác nhận các khối chuỗi chuyển tiếp trên các nhánh cạnh tranh. Một số trường hợp hành vi sai trái đe dọa tính toàn vẹn của mạng (chẳng hạn như ký các khối parachain không hợp lệ và xác thực nhiều mặt của một fork) và do đó dẫn đến việc bị lưu đày hiệu quả thông qua việc giảm tổng số trái phiếu. trong các trường hợp khác ít nghiêm trọng hơn (ví dụ: không hoạt động trong thỏa thuận đồng thuận quy trình) hoặc những trường hợp trách nhiệm không được phân bổ một cách chính xác (là một phần của một nhóm kém hiệu quả), một phần nhỏ thay vào đó, trái phiếu có thể bị phạt. Trong trường hợp sau, điều này hoạt động tốt với việc rời bỏ nhóm phụ để đảm bảo rằng các nút chịu thiệt hại nhiều hơn đáng kể so với các nút nhân từ bị thiệt hại tài sản thế chấp. Trong một số trường hợp (ví dụ: xác thực nhiều nhánh và không hợp lệ ký khối phụ) validator bản thân họ không thể dễ dàng phát hiện hành vi sai trái của nhau do việc xác minh liên tục của mỗi khối parachain sẽ là một nhiệm vụ quá khó khăn. đây cần tranh thủ sự ủng hộ của các bên bên ngoài quá trình xác nhận để xác minh và báo cáo hành vi sai trái đó. Các bên nhận được phần thưởng khi báo cáo hoạt động đó; thuật ngữ của họ, “ngư dân” bắt nguồn từ sự khó có thể xảy ra về phần thưởng như vậy. Vì những trường hợp này thường rất nghiêm trọng nên chúng tôi hình dung rằng bất kỳ phần thưởng nào cũng có thể được thanh toán dễ dàng từ trái phiếu bị tịch thu. Nói chung, chúng tôi muốn cân bằng việc đốt cháy (tức là giảm xuống không có gì) bằng cách tái phân bổ, thay vì đang cố gắng tái phân bổ bán buôn. Điều này có tác dụng
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 11 tăng giá trị tổng thể của token, bù đắp cho mạng nói chung ở một mức độ nào đó hơn là cụ thể bên tham gia khám phá. Điều này chủ yếu là để đảm bảo an toàn cơ chế: số lượng lớn có liên quan có thể dẫn đến việc khuyến khích hành vi cực đoan và gay gắt ban cho một mục tiêu duy nhất. Nói chung, điều quan trọng là phần thưởng phải đủ lớn để khiến việc xác minh trở nên có giá trị đối với mạng, nhưng không quá lớn để bù đắp chi phí cho việc trả trước một tội phạm "cấp công nghiệp" được tài trợ tốt, được tổ chức tốt hack tấn công vào một số validator không may mắn để ép buộc hành vi sai trái. Bằng cách này, số tiền yêu cầu nói chung sẽ là không lớn hơn mối ràng buộc trực tiếp của người phạm tội validator, kẻo động cơ sai trái phát sinh từ hành vi sai trái và báo cáo bản thân để nhận tiền thưởng. Điều này có thể được giải quyết một cách rõ ràng thông qua yêu cầu trái phiếu trực tiếp tối thiểu để trở thành một validator hoặc ngầm giáo dục những người được đề cử rằng validator với ít trái phiếu được ký gửi sẽ không có động lực lớn để cư xử tốt. 6.3. Cơ quan đăng ký Parachain. Mỗi parachain được xác định trong sổ đăng ký này. Nó là một cấu trúc giống cơ sở dữ liệu tương đối đơn giản và chứa cả thông tin tĩnh và động trên mỗi chuỗi. Thông tin tĩnh bao gồm chỉ số chuỗi (một cách đơn giản số nguyên), cùng với nhận dạng giao thức xác nhận, một phương pháp phân biệt giữa các loại khác nhau của parachain để có thể có được thuật toán xác thực chính xác được điều hành bởi validators được giao nhiệm vụ đưa ra một ứng cử viên hợp lệ. Bằng chứng khái niệm ban đầu sẽ tập trung vào việc đặt các thuật toán xác thực mới vào chính các máy khách, đòi hỏi phải có một phân nhánh cứng của giao thức mỗi lần lớp chuỗi bổ sung đã được thêm vào. Tuy nhiên, cuối cùng, có thể chỉ định thuật toán xác nhận trong một cách vừa nghiêm ngặt vừa hiệu quả để khách hàng có thể có thể làm việc hiệu quả với các parachain mới mà không cần cái nĩa cứng. Một con đường khả thi cho việc này là chỉ định thuật toán xác thực parachain được thiết lập tốt, ngôn ngữ trung lập về nền tảng, được biên dịch nguyên bản như WebAssembly. Nghiên cứu bổ sung là cần thiết để xác định liệu điều này có thực sự khả thi hay không, tuy nhiên nếu vậy, nó có thể mang lại cùng với đó là lợi thế to lớn của việc loại bỏ hard fork mãi mãi. Thông tin động bao gồm các khía cạnh của hệ thống định tuyến giao dịch phải có sự thống nhất toàn cầu như như hàng đợi vào của parachain (được mô tả trong phần 6.6). Cơ quan đăng ký chỉ có thể thêm parachains thông qua bỏ phiếu trưng cầu dân ý đầy đủ; điều này có thể được quản lý nội bộ nhưng nhiều khả năng sẽ được đặt ở bên ngoài hợp đồng trưng cầu dân ý để tạo thuận lợi cho việc tái sử dụng theo các thành phần quản trị tổng quát hơn. Các thông số để yêu cầu bỏ phiếu (ví dụ: bất kỳ số đại biểu cần thiết, đa số bắt buộc) để đăng ký chuỗi bổ sung và các chuỗi khác, nâng cấp hệ thống ít chính thức hơn sẽ được đặt ra trong một “bản chính hiến pháp” nhưng có khả năng tuân theo một cách khá truyền thống con đường, ít nhất là ban đầu. Công thức chính xác không còn nữa phạm vi cho công việc hiện tại, nhưng ví dụ: hai phần ba đại đa số sẽ vượt qua với hơn một phần ba tổng số hệ thống bỏ phiếu tích cực có thể là điểm khởi đầu hợp lý. Các hoạt động bổ sung bao gồm việc đình chỉ và loại bỏ parachains. Việc đình chỉ hy vọng sẽ không bao giờ xảy ra, tuy nhiên nó được thiết kế để ít nhất là một biện pháp bảo vệ có một số vấn đề khó giải quyết trong hệ thống xác thực của parachain. Ví dụ rõ ràng nhất nơi nó có thể cần có sự khác biệt quan trọng về mặt đồng thuận giữa các cách triển khai khiến validator không thể đồng ý về tính hợp lệ hoặc khối. Người xác nhận sẽ được khuyến khích sử dụng triển khai nhiều ứng dụng khách để họ có thể để phát hiện vấn đề như vậy trước khi tịch thu trái phiếu. Vì đình chỉ là một biện pháp khẩn cấp nên nó sẽ dưới sự bảo trợ của validator-bỏ phiếu năng động hơn một cuộc trưng cầu dân ý. Có thể cài đặt lại cả hai từ validator hoặc một cuộc trưng cầu dân ý. Việc loại bỏ hoàn toàn parachain sẽ chỉ đến sau một cuộc trưng cầu dân ý và với điều đó sẽ được yêu cầu thời gian ân hạn đáng kể để cho phép chuyển đổi có trật tự sang hoặc là một chuỗi độc lập hoặc trở thành một phần của chuỗi khác hệ thống đồng thuận. Thời gian ân hạn có thể sẽ là thứ tự các tháng và có thể được đặt ra trên cơ sở perchain trong sổ đăng ký parachain theo thứ tự khác nhau parachains có thể tận hưởng thời gian ân hạn khác nhau tùy theo nhu cầu của họ. 6.4. Niêm phong khối chuyển tiếp. Về bản chất, niêm phong đề cập đến đến quá trình phong thánh hóa; tức là dữ liệu cơ bản biến đổi cái nàoánh xạ bản gốc thành một cái gì đó về cơ bản là duy nhất và có ý nghĩa. Trong chuỗi PoW, niêm phong thực sự là một từ đồng nghĩa với khai thác mỏ. Trong trường hợp của chúng tôi, nó liên quan đến việc thu thập các tuyên bố đã được ký từ validator về tính hợp lệ, tính sẵn có và tính chuẩn mực của một khối chuỗi chuyển tiếp cụ thể và các khối parachain nó đại diện. Cơ chế của thuật toán đồng thuận BFT cơ bản nằm ngoài phạm vi của công việc hiện tại. chúng tôi sẽ thay vào đó hãy mô tả nó bằng cách sử dụng một nguyên thủy giả định một máy trạng thái tạo ra sự đồng thuận. Cuối cùng chúng tôi mong đợi được truyền cảm hứng từ một số sự đồng thuận đầy hứa hẹn BFT các thuật toán trong lõi; Tangaora [9] (một biến thể BFT của Bè [16]), Tendermint [11] và HoneyBadgerBFT [14]. Thuật toán sẽ phải đạt được thỏa thuận song song trên nhiều parachain, do đó khác với thông thường blockchain cơ chế đồng thuận. Chúng tôi cho rằng một lần đạt được sự đồng thuận, chúng tôi có thể ghi lại sự đồng thuận bằng chứng không thể chối cãi có thể được cung cấp bởi bất kỳ ai trong số những người tham gia vào nó. Chúng tôi cũng cho rằng hành vi sai trái trong giao thức nói chung có thể được giảm xuống một lượng nhỏ nhóm chứa những người tham gia có hành vi sai trái để giảm thiểu thiệt hại tài sản thế chấp khi xử lý hình phạt.8 Bằng chứng, ở dạng tuyên bố đã ký của chúng tôi, được đặt cùng nhau trong tiêu đề của khối chuỗi chuyển tiếp với một số trường nhất định khác, nhất là gốc trạng thái và gốc tri giao dịch của chuỗi chuyển tiếp. các niêm phong quá trình mất địa điểm dưới một độc thân tạo sự đồng thuận cơ chế địa chỉ cả hai cái khối chuỗi chuyển tiếp và khối parachains tạo nên một phần nội dung của chuyển tiếp: parachains không được các nhóm phụ của chúng “cam kết” riêng biệt và sau đó được đối chiếu sau này. Điều này dẫn đến một quy trình phức tạp hơn cho chuỗi chuyển tiếp, nhưng cho phép chúng tôi hoàn thành sự đồng thuận của toàn bộ hệ thống trong một giai đoạn duy nhất, giảm thiểu độ trễ và cho phép đối với các yêu cầu về tính sẵn có của dữ liệu khá phức tạp, hữu ích cho quá trình định tuyến dưới đây. 8Các chương trình đồng thuận BFT dựa trên PoS hiện có như Tendermint BFT và Slasher ban đầu đáp ứng các xác nhận này.
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 12 Trạng thái của máy đồng thuận của mỗi người tham gia có thể được mô hình hóa dưới dạng bảng (2 chiều) đơn giản. Mỗi người tham gia (validator) có một tập hợp thông tin, ở dạng các tuyên bố đã ký (“phiếu bầu”) từ những người tham gia khác, liên quan đến từng ứng cử viên khối parachain cũng như ứng cử viên khối chuỗi chuyển tiếp. Tập hợp thông tin gồm hai phần của dữ liệu: Sẵn có: có cái này validator có đi ra thông tin bài đăng giao dịch từ khối này vì vậy họ có thể xác thực chính xác các ứng cử viên parachain trên khối sau không? Họ có thể bỏ phiếu 1 (đã biết) hoặc 0 (chưa biết). Một khi họ bỏ phiếu 1, họ cam kết bỏ phiếu tương tự cho phần còn lại của quá trình này. Phiếu bầu sau đó không tôn trọng điều này là căn cứ để trừng phạt. Hiệu lực: khối parachain có hợp lệ không và là tất cả dữ liệu được tham chiếu bên ngoài (ví dụ: giao dịch) có sẵn? Điều này chỉ liên quan đến validator được chỉ định cho parachain mà họ đang bỏ phiếu. Họ có thể bỏ phiếu 1 (hợp lệ), -1 (không hợp lệ) hoặc 0 (chưa biết). Một khi họ bỏ phiếu khác 0, họ cam kết bỏ phiếu theo cách này cho phần còn lại của quá trình này. Những phiếu bầu sau này không tôn trọng điều này là căn cứ để xử phạt. Tất cả validator phải gửi phiếu bầu; phiếu bầu có thể được gửi lại, đủ điều kiện theo các quy tắc trên. Sự tiến triển của sự đồng thuận có thể được mô hình hóa thành nhiều thuật toán đồng thuận BFT tiêu chuẩn trên mỗi parachain diễn ra song song. Vì những điều này có khả năng bị cản trở bởi một tương đối thiểu số nhỏ các tác nhân độc hại tập trung ở một nhóm parachain duy nhất, có sự đồng thuận chung thiết lập một điểm dừng, hạn chế trường hợp xấu nhất xảy ra bế tắc đối với chỉ một hoặc nhiều khối parachain trống (và một hình phạt dành cho những người có trách nhiệm). Các quy tắc cơ bản về tính hợp lệ của các khối riêng lẻ (cho phép toàn bộ tập hợp validator đạt tới sự đồng thuận về việc nó trở thành ứng cử viên parachain duy nhất được tham chiếu từ rơle chính tắc): • phải có ít nhất hai phần ba số validator bỏ phiếu tích cực và không có phiếu bầu tiêu cực; • phải có hơn một phần ba validator bỏ phiếu ủng hộ tính khả dụng của thông tin hàng đợi đi ra. Nếu có ít nhất một phiếu thuận và ít nhất một phiếu phản đối về tính hợp lệ thì một điều kiện ngoại lệ sẽ được tạo và toàn bộ validator phải bỏ phiếu để xác định nếu có các bên có ác ý hoặc nếu có sự cố tình cờ cái nĩa. Ngoài loại phiếu hợp lệ và không hợp lệ, còn có loại phiếu bầu thứ ba được phép, tương đương với việc bỏ phiếu cho cả hai, nghĩa là nút có những ý kiến trái ngược nhau. Điều này có thể là do chủ sở hữu của nút đang chạy nhiều triển khai không đồng ý, cho thấy có thể có sự mơ hồ trong giao thức. Sau khi tất cả phiếu bầu được tính từ bộ validator đầy đủ, nếu ý kiến thua cuộc ít nhất cũng có một tỷ lệ nhỏ nào đó (so với được tham số hóa; nhiều nhất là một nửa, có lẽ ít hơn đáng kể) số phiếu của ý kiến thắng cuộc thì được coi là là một sự phân nhánh parachain ngẫu nhiên và parachain đó sẽ tự động bị đình chỉ khỏi quá trình đồng thuận. Nếu không, chúng tôi cho rằng đó là hành động ác ý và trừng phạt thiểu số bỏ phiếu cho ý kiến bất đồng. Kết luận là một tập hợp các chữ ký chứng minh tính kinh điển. Khối chuỗi chuyển tiếp sau đó có thể được niêm phong và quá trình niêm phong khối tiếp theo bắt đầu. 6.5. Những cải tiến cho khối chuyển tiếp niêm phong. Trong khi phương pháp niêm phong này mang lại sự đảm bảo chắc chắn cho hoạt động của hệ thống, nhưng nó không mở rộng quy mô một cách đặc biệt vì thông tin chính của mỗi parachain phải có tính khả dụng được đảm bảo bởi hơn một phần ba tổng số validator. Điều này có nghĩa là dấu ấn trách nhiệm của mỗi validator phát triển khi có nhiều chuỗi được thêm vào. Mặc dù tính sẵn có của dữ liệu trong các mạng đồng thuận mở về cơ bản là một vấn đề chưa được giải quyết, có nhiều cách để giảm thiểu chi phí hoạt động trên các nút validator. Một điều đơn giản giải pháp là nhận ra rằng trong khi validator phải gánh vác trách nhiệm về tính sẵn có của dữ liệu, họ không thực sự cần phải lưu trữ, truyền đạt hoặc sao chép dữ liệu. Kho chứa dữ liệu thứ cấp, có thể liên quan đến (hoặc thậm chí chính tương tự) những người đối chiếu biên soạn dữ liệu này, có thể quản lý nhiệm vụ đảm bảo tính khả dụng với validator cung cấp một phần tiền lãi/thu nhập của họ để thanh toán. Tuy nhiên, mặc dù điều này có thể mang lại khả năng mở rộng trung gian nhưng nó vẫn không giúp giải quyết được vấn đề cơ bản; kể từ khi việc thêm nhiều chuỗi nói chung sẽ yêu cầu thêm validators, mức tiêu thụ tài nguyên mạng liên tục (đặc biệt là về băng thông) sẽ tăng theo bình phương của cáidây chuyền, một tài sản không thể bảo vệ được về lâu dài. Cuối cùng, chúng ta có xu hướng tiếp tục đập đầu mình chống lại giới hạn cơ bản nói rằng đối với một mạng lưới đồng thuận được coi là có sẵn an toàn, các yêu cầu về băng thông hiện tại có tổng số validators lần tổng thông tin đầu vào. Điều này là do mạng không đáng tin cậy không có khả năng phân phối hợp lý nhiệm vụ lưu trữ dữ liệu trên nhiều nút. ngoài nhiệm vụ xử lý được phân phối rõ ràng. 6.5.1. Giới thiệu độ trễ. Một phương tiện để làm dịu đi điều này quy tắc là để nới lỏng khái niệm về tính tức thời. Bằng cách yêu cầu 33%+1 validator bỏ phiếu cho tính khả dụng cuối cùng chứ không phải ngay lập tức, chúng tôi có thể tận dụng tốt hơn việc truyền dữ liệu theo cấp số nhân và thậm chí giúp đạt được mức cao nhất trong trao đổi dữ liệu. Một sự bình đẳng hợp lý (mặc dù chưa được chứng minh) có thể là: (1) độ trễ = người tham gia × chuỗi Theo mô hình hiện tại, quy mô của hệ thống với số lượng chuỗi để đảm bảo rằng quá trình xử lý được thực hiện phân phối; vì mỗi chuỗi sẽ yêu cầu ít nhất một validator và chúng tôi cố định chứng thực tính khả dụng thành một hằng số tỷ lệ validator giây thì số người tham gia sẽ tăng lên tương tự với số lượng chuỗi. Chúng tôi kết thúc với: (2) độ trễ = kích thước2 Có nghĩa là khi hệ thống phát triển, băng thông được yêu cầu và độ trễ cho đến khi biết được tính khả dụng trên toàn mạng. mạng, cũng có thể được mô tả là số của các khối trước khối cuối cùng, tăng theo bình phương của nó. Đây là một yếu tố tăng trưởng đáng kể và có thể trở thành vật cản đường đáng chú ý và buộc chúng ta đi vào các mô hình “không phẳng” chẳng hạn như soạn một số “Polkadotes” thành một hệ thống phân cấp để định tuyến các bài đăng đa cấp thông qua một cây chuỗi chuyển tiếp.
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 13 6.5.2. Sự tham gia của công chúng. Một hướng đi khả thi hơn là huy động sự tham gia của công chúng vào quá trình này thông qua một hệ thống khiếu nại vi mô. Tương tự như các ngư dân, có có thể là các bên bên ngoài để giám sát validator những người khiếu nại sự sẵn có. Nhiệm vụ của họ là tìm ra một người dường như không thể chứng minh được khả năng sẵn sàng đó. Khi làm như vậy họ có thể gửi khiếu nại vi mô tới validators khác. PoW hoặc một trái phiếu đặt cược có thể được sử dụng để giảm thiểu cuộc tấn công sybil điều này sẽ khiến hệ thống phần lớn trở nên vô dụng. 6.5.3. Người bảo lãnh sẵn có. Con đường cuối cùng sẽ là chỉ định một bộ validator ngoại quan thứ hai là “khả năng sẵn sàng người bảo lãnh”. Chúng sẽ được liên kết giống như validators bình thường và thậm chí có thể được lấy từ cùng một bộ (mặc dù nếu vậy, chúng sẽ được chọn trong thời gian dài, ít nhất là mỗi phiên). Không giống như validator thông thường, chúng sẽ không chuyển đổi giữa các parachain mà thay vào đó sẽ thành lập một nhóm duy nhất để chứng thực sự sẵn có của tất cả dữ liệu liên chuỗi quan trọng. Điều này có ưu điểm là nới lỏng sự tương đương giữa người tham gia và chuỗi. Về cơ bản, chuỗi có thể phát triển (cùng với chuỗi ban đầu validator được đặt), trong khi những người tham gia, và cụ thể là những người tham gia vào chứng thực tính sẵn có của dữ liệu, có thể duy trì ở mức độ tuyến tính ít nhất và có thể là hằng số. 6.5.4. Tùy chọn Collator. Một khía cạnh quan trọng của điều này Hệ thống là đảm bảo rằng có sự lựa chọn lành mạnh các người đối chiếu tạo các khối trong bất kỳ parachain cụ thể nào. Nếu một người đối chiếu duy nhất thống trị một parachain sau đó một số cuộc tấn công trở nên khả thi hơn vì khả năng thiếu sự sẵn có của dữ liệu bên ngoài sẽ ít rõ ràng hơn. Một lựa chọn là cân các khối parachain một cách giả tạo một cơ chế giả ngẫu nhiên để hỗ trợ nhiều loại đối chiếu. Trong trường hợp đầu tiên, chúng tôi sẽ yêu cầu như một phần của cơ chế đồng thuận mà validator ủng hộ Các ứng cử viên khối parachain được xác định là “nặng hơn”. Tương tự, chúng ta phải khuyến khích validator cố gắng đề xuất khối nặng nhất mà họ có thể tìm thấy—đây có thể là được thực hiện thông qua việc chia một phần phần thưởng tương ứng với trọng lượng của ứng cử viên của họ. Để đảm bảo rằng các nhà đối chiếu được hưởng sự công bằng hợp lý cơ hội ứng cử viên của họ được chọn là người chiến thắng ứng cử viên đồng thuận, chúng tôi đưa ra trọng số cụ thể của Ứng viên khối parachain xác định dựa trên một hàm ngẫu nhiên được kết nối với mỗi bộ đối chiếu. Ví dụ, lấy thước đo khoảng cách XOR giữa địa chỉ của đối chiếu và một số số giả ngẫu nhiên được bảo mật bằng mật mã được xác định gần với điểm của khối được tạo (một “vé trúng thưởng” mang tính khái niệm). Điều này mang lại hiệu quả cho mỗi người đối chiếu (hoặc cụ thể hơn là địa chỉ của mỗi người đối chiếu) a cơ hội ngẫu nhiên để khối ứng cử viên của họ “chiến thắng” tất cả những người khác. Để giảm thiểu cuộc tấn công sybil của một người đối chiếu duy nhất “khai thác” một địa chỉ gần với vé trúng thưởng và do đó mỗi khối được yêu thích, chúng tôi sẽ thêm một số quán tính vào địa chỉ của người đối chiếu. Điều này có thể đơn giản như việc yêu cầu họ để có số tiền cơ bản trong địa chỉ. Thêm nữa cách tiếp cận tao nhã sẽ là cân nhắc sự gần gũi với vé trúng thưởng với số tiền đậu tại địa chỉ trong câu hỏi. Trong khi việc lập mô hình vẫn chưa được thực hiện, rất có thể cơ chế này cho phép thậm chí rất các bên liên quan nhỏ đóng góp với tư cách là người đối chiếu. 6.5.5. Khối thừa cân. Nếu bộ validator bị xâm phạm, họ có thể tạo và đề xuất một khối, tuy nhiên hợp lệ, mất nhiều thời gian để thực hiện và xác thực. Đây là sự cố vì nhóm validator có thể hợp lý tạo thành một khối mà phải mất một thời gian rất dài để thực thi trừ khi một số thông tin cụ thể đã được biết cho phép cắt ngắn, ví dụ: bao thanh toán lớn nguyên tố. Nếu một người đối chiếu biết thông tin đó thì họ sẽ có lợi thế rõ ràng trong việc có được các ứng cử viên được chấp nhận miễn là những người khác đang bận xử lý khối cũ. Chúng tôi gọi những khối này là thừa cân. Việc bảo vệ chống lại việc validator gửi và xác thực các khối này phần lớn có cùng chiêu bài như đối với các khối không hợp lệ, mặc dù có một cảnh báo bổ sung: Vì thời gian thực hiện một khối (và do đó trạng thái của nó là thừa cân) mang tính chủ quan, kết quả cuối cùng của cuộc bỏ phiếu về hành vi sai trái về cơ bản sẽ rơi vào ba phe. một khả năng là khối đó chắc chắn không nặng— trong trường hợp này hơn hai phần ba tuyên bố rằng họ có thể thực thi khối trong một số giới hạn (ví dụ: 50% tổng thời gian được phép giữa các khối). Một điều nữa là khối là dchắc chắn là thừa cân—điều này sẽ xảy ra nếu nhiều hơn hai phần ba tuyên bố rằng họ không thể thực thi khối trong giới hạn nói trên. Một khả năng cuối cùng là khá bình đẳng sự chia rẽ quan điểm giữa validators. Trong trường hợp này, chúng ta có thể chọn thực hiện một số hình phạt tương xứng. Để đảm bảo validator có thể dự đoán khi nào họ có thể đề xuất một khối thừa cân, có thể hợp lý nếu yêu cầu họ công bố thông tin về hiệu suất của chính họ đối với từng khối. Trong một khoảng thời gian đủ dài, điều này sẽ cho phép họ lập hồ sơ tốc độ xử lý của mình so với những người ngang hàng sẽ đánh giá họ. 6.5.6. Bảo hiểm Collator. Vẫn còn một vấn đề đối với validators: không giống như mạng PoW, để kiểm tra khối để có hiệu lực, họ phải thực sự thực hiện các giao dịch trong đó. Những người đối chiếu độc hại có thể cung cấp các khối không hợp lệ hoặc thừa cân cho validator khiến họ đau buồn (lãng phí nguồn lực của họ) và đòi hỏi chi phí cơ hội tiềm tàng đáng kể. Để giảm thiểu điều này, chúng tôi đề xuất một chiến lược đơn giản về một phần của validators. Đầu tiên, các ứng cử viên khối parachain đã gửi tới validator phải được ký từ tài khoản chuỗi chuyển tiếp bằng tiền; nếu không thì validator sẽ bị loại bỏ nó ngay lập tức. Thứ hai, các ứng cử viên như vậy nên được sắp xếp thứ tự ưu tiên bằng cách kết hợp (ví dụ: phép nhân) của số tiền trong tài khoản lên đến một giới hạn nhất định, số khối trước đó mà đối chiếu đã đề xuất thành công trong quá khứ (chưa kể bất kỳ khối nào trước đó hình phạt), và yếu tố gần gũi với chiến thắng vé như đã thảo luận trước đó. Mũ phải giống nhau như số tiền bồi thường mang tính trừng phạt được trả cho validator trong vụ án trong số họ gửi một khối không hợp lệ. Để ngăn cản người cộng tác gửi các ứng cử viên bị chặn không hợp lệ hoặc thừa cân tới validator, bất kỳ validator nào cũng có thể đặt vào khối tiếp theo một giao dịch bao gồm khối vi phạm cáo buộc hành vi sai trái dẫn đến việc chuyển một phần hoặc toàn bộ số tiền vào tài khoản của người đối chiếu có hành vi sai trái. tài khoản cho người bị hại validator. Loại giao dịch này chạy trước bất kỳ giao dịch nào khác để đảm bảo người đối chiếu không thể rút tiền trước khi bị trừng phạt. Số lượng của tiền được chuyển dưới dạng thiệt hại là một tham số động
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 14 được mô hình hóa nhưng có thể sẽ là một phần của phần thưởng khối validator để phản ánh mức độ đau buồn gây ra. Đến ngăn chặn validator độc hại tự ý tịch thu quỹ của người cộng tác, người cộng tác có thể kháng cáo quyết định của validator với bồi thẩm đoàn gồm validator được chọn ngẫu nhiên để đổi lại để đặt một khoản tiền gửi nhỏ. Nếu họ có lợi cho validator, họ sẽ tiêu hết số tiền đặt cọc. Nếu không, tiền đặt cọc được trả lại và validator bị phạt (vì validator ở vị trí hình vòm hơn nhiều, mức phạt sẽ có thể là khá nặng). 6.6. liên chuỗi Giao dịch Định tuyến. liên chuỗi định tuyến giao dịch là một trong những công việc bảo trì thiết yếu nhiệm vụ của chuỗi chuyển tiếp và validator của nó. Đây là logic chi phối cách một giao dịch được đăng (thường được rút ngắn thành “đăng”) để trở thành đầu ra mong muốn từ một parachain nguồn trở thành đầu vào không thể thương lượng của một parachain đích khác mà không có bất kỳ sự tin tưởng nào yêu cầu. Chúng tôi chọn từ ngữ ở trên một cách cẩn thận; đáng chú ý là chúng tôi không yêu cầu phải có giao dịch trong nguồn parachain đã phê chuẩn rõ ràng bài đăng này. duy nhất những hạn chế mà chúng tôi đặt ra cho mô hình của mình là parachains phải cung cấp, đóng gói như một phần của khối tổng thể của họ xử lý đầu ra, các bài đăng là kết quả của việc thực thi khối. Những bài đăng này được cấu trúc như một số hàng đợi FIFO; cái số lượng danh sách được gọi là cơ sở định tuyến và có thể khoảng 16. Đáng chú ý, con số này thể hiện số lượng của parachains mà chúng ta có thể hỗ trợ mà không cần phải dùng đến định tuyến nhiều pha. Ban đầu, Polkadot sẽ hỗ trợ việc này loại định tuyến trực tiếp, tuy nhiên chúng tôi sẽ phác thảo một cách có thể quá trình định tuyến nhiều pha (“siêu định tuyến”) như một phương tiện mở rộng quy mô vượt xa nhóm parachain ban đầu. Chúng tôi giả sử đó tất cả người tham gia biết cái các nhóm con cho hai khối tiếp theo n, n + 1. Tóm lại, Hệ thống định tuyến trải qua các giai đoạn sau: • CollatorS: Liên hệ với các thành viên của V alidators[n][S] • Đối chiếu: CHO MỖI nhóm con: đảm bảo tại ít nhất 1 thành viên của V alidators[n][s] có liên hệ • Người hợp tác: ĐỐI VỚI MỖI nhóm con: giả sử egress[n −1][s][S] có sẵn (tất cả bài đăng đến dữ liệu đến 'S' từ khối cuối cùng) • Người hợp tác: Soạn đề cử khối b cho S: (b.header, b.ext, b.proof, b.receipt, b.egress) • Người hợp tác: Gửi bằng chứng thông tin proof[S] = (b.header, b.ext, b.proof, b.receipt) thành Trình xác thực V[n][S] • CollatorS: Đảm bảo dữ liệu giao dịch bên ngoài b.ext được cung cấp cho những người đối chiếu khác và validators • Người hợp tác: CHO MỖI nhóm con s: Gửi đi ra thông tin đi ra[n][S][s] = (b.header, b.receipt, b.egress[s]) để cái nhận được nhóm phụ thành viên của tiếp theo khối Trình xác thực V[n + 1][s] • V alidatorV : Kết nối trước tất cả các thành viên cùng tập hợp đối với khối tiếp theo: đặt N = Chuỗi[n + 1][V ]; kết nối tất cả validators v sao cho Chuỗi[n + 1][v] = N • V alidatorV : Đối chiếu tất cả dữ liệu nhập vào cho việc này khối: CHO MỖI nhóm con s: Truy xuất egress[n −1][s][Chain[n][V ]], lấy từ validators v khác sao cho Chain[n][v] = Chain[n][V ]. Có thể đi qua các validator khác được chọn ngẫu nhiên để làm bằng chứng cho nỗ lực. • V alidatorV : Chấp nhận bằng chứng ứng cử viên cho việc này bằng chứng khối[Chuỗi[n][V ]]. Hiệu lực của khối biểu quyết • V alidatorV : Chấp nhận dữ liệu đầu ra của ứng viên cho khối tiếp theo: CHO MỖI nhóm con, chấp nhận đi ra[n][s][N]. Tính khả dụng của khối bỏ phiếu đầu ra; xuất bản lại giữa những validators quan tâm sao cho Chuỗi[n + 1][v] = Chuỗi[n + 1][V ]. • V alidatorV : ĐẾN ĐẾN ĐỒNG Ý Trong đó: egress[n][from][to] là hàng đợi đi ra hiện tại thông tin cho các bài đăng từ parachain ‘from‘, đến parachain ‘to‘ trong số khối ‘n‘. CollatorS là một công cụ đối chiếu cho parachain S. V alidators[n][s] là tập hợp validators cho parachain s ở số khối n. Ngược lại, Chain[n][v] là parachain mà validator v được gán trên số khối n. block.egress[to] là lối ra hàng bài đăng từ một số khối khối parachain có đích đến là parachain. Vì người đối chiếu thu phí (giao dịch) dựa trên các khối của họ trở thành chuẩn, họ được khuyến khích đảm bảo rằng đối với mỗi đích đến của khối tiếp theo, nhóm con các thành viên được thông báo về hàng đợi đi ra từ hiện tại khối. Người xác thực chỉ được khuyến khích để hình thành sự đồng thuận về một khối (parachain), vì vậy họ ít quan tâm đến khối đối chiếu nào cuối cùng sẽ trở thành chuẩn. trong về nguyên tắc, validator có thể hình thành lòng trung thành với người đối chiếu và âm mưu làm giảm cơ hội của những người đối chiếu khác' các khối trở thành chuẩn, tuy nhiên điều này vừa khó khăn sắp xếp do chọn ngẫu nhiênhành động của validator giây cho parachains và có thể được bảo vệ bằng cách giảm phí phải trả cho các khối parachain tồn tại quá trình đồng thuận. 6.6.1. Tính sẵn có của dữ liệu bên ngoài. Đảm bảo parachain dữ liệu bên ngoài thực sự có sẵn là một vấn đề lâu năm với các hệ thống phi tập trung nhằm phân phối khối lượng công việc trên mạng lưới. Trọng tâm của vấn đề là sự sẵn có vấn đề nói rằng vì không thể tạo bằng chứng không tương tác về tính khả dụng cũng như bất kỳ loại nào bằng chứng về tính không khả dụng để hệ thống BFT hoạt động bình thường xác nhận bất kỳ quá trình chuyển đổi nào có tính chính xác phụ thuộc vào sự sẵn có của một số dữ liệu bên ngoài, số lượng tối đa của các nút Byzantine có thể chấp nhận được, cộng với một, của hệ thống phải chứng thực dữ liệu có sẵn. Để hệ thống có thể mở rộng quy mô đúng cách, như Polkadot, điều này gây ra sự cố: nếu tỷ lệ cố định validators phải chứng thực sự sẵn có của dữ liệu và giả sử validator thực sự muốn lưu trữ dữ liệu trước khi xác nhận rằng nó có sẵn, thì làm cách nào để chúng ta tránh được vấn đề về yêu cầu băng thông/lưu trữ ngày càng tăng theo kích thước hệ thống (và do đó là số validators)? Một câu trả lời có thể là có một bộ riêng trong số validators (người bảo đảm tính sẵn có), có đơn đặt hàng tăng lên tuyến tính với kích thước tổng thể là Polkadot. Đây là được mô tả trong 6.5.3. Chúng tôi cũng có một thủ thuật phụ. Với tư cách là một nhóm, những người đối chiếu có động lực nội tại để đảm bảo rằng tất cả dữ liệu đều được có sẵn cho parachain đã chọn của họ vì nếu không có nó thì họ không thể tạo thêm các khối để từ đó họ có thể thu phí giao dịch. Những người cộng tác cũng tạo thành một nhóm, thành viên trong đó rất đa dạng (do tính chất ngẫu nhiên của parachain validator nhóm) không tầm thường để tham gia và dễ dàng
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 15 để chứng minh. Do đó, các nhà đối chiếu gần đây (có lẽ trong số vài nghìn khối cuối cùng) được phép đưa ra các thách thức đối với sự sẵn có của dữ liệu bên ngoài cho một parachain cụ thể chặn tới validators để có một trái phiếu nhỏ. Người xác thực phải liên hệ với những người thuộc nhóm phụ validator có vẻ vi phạm đã làm chứng và thu thập cũng như trả lại dữ liệu cho người đối chiếu hoặc chuyển lên cấp trên vấn đề bằng cách chứng minh sự thiếu sẵn có (từ chối trực tiếp cung cấp dữ liệu được coi là hành vi phạm tội tịch thu trái phiếu, do đó hành vi sai trái validator có thể sẽ chỉ ngắt kết nối) và liên hệ với validators khác để chạy thử nghiệm tương tự. Trong trường hợp sau, trái phiếu thế chấp được trả lại. Khi đã đạt đến số đại biểu validator người có thể đưa ra những lời chứng thực không có sẵn như vậy, họ sẽ được giải phóng, nhóm phụ có hành vi sai trái sẽ bị trừng phạt và khối được hoàn nguyên. 6.6.2. Định tuyến bài viết. Mỗi tiêu đề parachain bao gồm một đi ra-trie-root; đây là gốc của một thử nghiệm có chứa các thùng cơ sở định tuyến, mỗi thùng là một danh sách được nối của bài viết đi ra. Bằng chứng Merkle có thể được cung cấp trên parachain validators để chứng minh rằng một parachain cụ thể khối có một hàng đợi đầu ra cụ thể cho một parachain đích cụ thể. Khi bắt đầu xử lý một khối parachain, mỗi khối hàng đợi đầu ra của parachain khác bị ràng buộc cho khối nói trên là đã được hợp nhất vào hàng đợi vào của khối của chúng tôi. Chúng tôi cho rằng mạnh mẽ, có lẽ là CSPR9, thứ tự khối phụ để đạt được một hoạt động xác định không mang lại sự thiên vị giữa bất kỳ ghép nối khối parachain. Collators tính toán hàng đợi mới và rút hết hàng đợi đi ra theo parachain logic. Nội dung của hàng đợi vào được viết rõ ràng vào khối parachain. Điều này có hai mục đích chính: đầu tiên, điều đó có nghĩa là parachain có thể được đồng bộ hóa một cách đáng tin cậy và tách biệt với các parachain khác. Thứ hai, nó đơn giản hóa việc hậu cần dữ liệu nên toàn bộ quá trình xâm nhập hàng đợi không thể được xử lý trong một khối duy nhất; validators và người đối chiếu có thể xử lý các khối sau mà không cần phải tìm nguồn dữ liệu đặc biệt của hàng đợi. Nếu hàng đợi vào của parachain vượt quá ngưỡng số tiền ở cuối quá trình xử lý khối, sau đó nó được đánh dấu đã bão hòa trên chuỗi chuyển tiếp và không có thông báo nào khác có thể được thực hiện được chuyển đến nó cho đến khi nó được thông quan. Bằng chứng Merkle là được sử dụng để chứng minh tính chính xác của hoạt động của bộ đối chiếu trong bằng chứng của khối parachain. 6.6.3. Phê bình. Một sai sót nhỏ liên quan đến cơ bản này cơ chế là cuộc tấn công sau bom. Đây là nơi tất cả parachains gửi số lượng bài viết tối đa có thể đến một parachain cụ thể. Trong khi điều này ràng buộc mục tiêu hàng đợi vào cùng một lúc, không có thiệt hại nào xảy ra nhiều lần một cuộc tấn công DoS giao dịch tiêu chuẩn. Hoạt động bình thường, với bộ thiết bị đồng bộ tốt và trình đối chiếu không độc hại và validators, dành cho N parachain, Tổng cộng N × M validator số bộ đối chiếu và L trên mỗi parachain, chúng tôi có thể chia nhỏ tổng đường dẫn dữ liệu trên mỗi khối thành: Trình xác thực: M −1+L+L: M −1 cho validators khác trong bộ parachain, L cho mỗi bộ đối chiếu cung cấp khối parachain ứng cử viên và L thứ hai cho mỗi bộ đối chiếu của khối tiếp theo yêu cầu tải trọng đầu ra của khối trước đó. (Cái sau thực sự giống trường hợp xấu nhất hoạt động vì có khả năng các nhà đối chiếu sẽ chia sẻ những điều đó dữ liệu.) Collator: M +kN: M để kết nối với từng liên quan khối parachain validator, kN để gieo tải trọng đầu ra vào một số tập hợp con của mỗi nhóm parachain validator cho khối tiếp theo (và có thể một số đối chiếu được ưa thích). Như vậy, các đường dẫn dữ liệu trên mỗi nút phát triển tuyến tính với độ phức tạp tổng thể của hệ thống. Trong khi đây là hợp lý, vì hệ thống có quy mô thành hàng trăm hoặc hàng nghìn parachain, một số độ trễ giao tiếp có thể được hấp thụ để đổi lấy tốc độ tăng trưởng phức tạp thấp hơn. Trong trường hợp này, thuật toán định tuyến nhiều pha có thể được sử dụng để giảm số lượng đường truyền tức thời với chi phí giới thiệu bộ đệm lưu trữ và độ trễ. 6.6.4. Định tuyến siêu khối. Định tuyến siêu khối là một cơ chế có thể được xây dựng chủ yếu như một phần mở rộng cho cơ chế định tuyến cơ bản được mô tả ở trên. Về cơ bản, thay vì phát triển khả năng kết nối nút bằng số lượng nút parachain và nút nhóm phụ, chúng tôi chỉ phát triển với logarit của parachains. Bài viết có thể chuyển tiếp giữa hàng đợi của một số parachains đang trên đường đến khâu giao hàng cuối cùng. Bản thân việc định tuyến là xác định và đơn giản. Chúng tôi bắt đầu bằng giới hạn số lượng thùng trong hàng đợi vào/ra; thay vì là tổng số parachain, chúng làcơ sở định tuyến (b) . Điều này sẽ được cố định là số thay đổi của parachain, với số mũ định tuyến (e) thay vào đó được nâng lên. Theo mô hình này, khối lượng tin nhắn của chúng tôi phát triển với O(be), với đường đi không đổi và độ trễ (hoặc số khối cần thiết để phân phối) với O(e). Mô hình định tuyến của chúng tôi là một siêu khối có kích thước e, với mỗi cạnh của khối lập phương có b vị trí có thể. Mỗi khối, chúng tôi định tuyến tin nhắn dọc theo một trục. Chúng tôi luân phiên trục theo kiểu vòng tròn, do đó đảm bảo thời gian giao hàng trong trường hợp xấu nhất của các khối e. Là một phần của quá trình xử lý parachain, liên kết nước ngoài các tin nhắn được tìm thấy trong hàng đợi đi vào sẽ được chuyển ngay đến thùng của hàng đợi đi ra thích hợp, với điều kiện là số khối hiện tại (và do đó kích thước định tuyến). Cái này quá trình yêu cầu truyền dữ liệu bổ sung cho mỗi bước nhảy trên đường giao hàng, tuy nhiên bản thân đây cũng là một vấn đề có thể được giảm thiểu bằng cách sử dụng một số phương tiện thay thế phân phối tải trọng dữ liệu và chỉ bao gồm một tài liệu tham khảo, thay vì toàn bộ tải trọng của bài đăng trong lần thử sau. Một ví dụ về định tuyến siêu khối cho hệ thống với 4 parachain, b = 2 và e = 2 có thể là: Giai đoạn 0, trên mỗi tin nhắn M: • sub0: nếu Mdest ∈{2, 3} thì sendTo(2) nếu không giữ nguyên • sub1: nếu Mdest ∈{2, 3} thì sendTo(3) nếu không giữ nguyên • sub2: nếu Mdest ∈{0, 1} thì sendTo(0) nếu không giữ nguyên • sub3: nếu Mdest ∈{0, 1} thì sendTo(1) nếu không giữ nguyên Giai đoạn 1, trên mỗi tin nhắn M: • sub0: nếu Mdest ∈{1, 3} thì sendTo(1) nếu không giữ nguyên • sub1: nếu Mdest ∈{0, 2} thì sendTo(0) nếu không giữ nguyên • sub2: nếu Mdest ∈{1, 3} thì sendTo(3) nếu không giữ nguyên • sub3: nếu Mdest ∈{0, 2} thì sendTo(2) nếu không giữ nguyên Hai chiều ở đây dễ dàng được coi là chiều đầu tiên hai bit của chỉ mục đích; đối với khối đầu tiên, chỉ bit bậc cao hơn được sử dụng. Giao dịch khối thứ hai với bit bậc thấp. Một khi cả hai xảy ra (tùy ý order) thì bài viết sẽ được định tuyến. 9 giả ngẫu nhiên an toàn bằng mật mã
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 16 6.6.5. Tối đa hóa sự may mắn. Một sự thay đổi cơ bản đề xuất sẽ có tổng số cố định là c2 −c validators, với c−1 validators trong mỗi nhóm phụ. Mỗi khối, thay vì đang có sự phân vùng lại không có cấu trúc của validators giữa các parachain, thay vào đó cho từng nhóm con parachain, mỗi validator sẽ được gán cho một địa chỉ duy nhất và khác nhau nhóm con parachain trên khối sau. Điều này sẽ dẫn đến bất biến giữa hai khối bất kỳ, đối với bất kỳ khối nào hai cặp parachain, tồn tại hai validators đã hoán đổi trách nhiệm của parachain. Mặc dù điều này không thể được sử dụng để đạt được sự đảm bảo tuyệt đối về tính khả dụng (một validator thỉnh thoảng sẽ ngừng hoạt động, ngay cả khi nhân từ), tuy nhiên nó có thể tối ưu hóa trường hợp chung. Cách tiếp cận này không phải là không có biến chứng. Việc bổ sung parachain cũng sẽ đòi hỏi phải tổ chức lại của bộ validator. Hơn nữa, số validator, được gắn với bình phương của số lượng parachain, ban đầu sẽ bắt đầu rất nhỏ và cuối cùng phát triển xa quá nhanh, trở nên không thể trụ được sau khoảng 50 parachain. Không có vấn đề nào trong số này là vấn đề cơ bản. Trong trường hợp đầu tiên, việc sắp xếp lại các bộ validator là điều cần phải làm dù sao cũng được thực hiện thường xuyên. Về kích thước của validator được đặt, khi quá nhỏ, nhiều validator có thể được chỉ định cho cùng một parachain, áp dụng hệ số nguyên cho tổng cộng là validator giây. Cơ chế định tuyến nhiều pha như Định tuyến Hypercube, được thảo luận trong phần 6.6.4 sẽ giảm bớt yêu cầu về số lượng lớn validators khi có một số lượng lớn các chuỗi. 6.7. Xác thực Parachain. Mục đích chính của validator là để chứng minh, với tư cách là một tác nhân có mối quan hệ tốt, rằng hoạt động của parachain khối là hợp lệ, bao gồm nhưng không giới hạn ở bất kỳ chuyển đổi trạng thái nào, bao gồm mọi giao dịch bên ngoài, việc thực hiện bất kỳ bài đăng đang chờ nào trong hàng đợi vào và trạng thái cuối cùng của hàng đợi đi ra. Quá trình này khá đơn giản. Khi validator đã niêm phong khối trước đó, chúng sẽ miễn phí bắt đầu làm việc để cung cấp khối parachain ứng viên ứng cử viên cho vòng đồng thuận tiếp theo. Ban đầu, validator tìm thấy ứng viên khối parachain thông qua bộ đối chiếu parachain (mô tả tiếp theo) hoặc một trong số đồngvalidator của nó. Dữ liệu ứng cử viên khối parachain bao gồm tiêu đề của khối, tiêu đề của khối trước đó, bất kỳ dữ liệu đầu vào bên ngoài nào được bao gồm (đối với Ethereum và Bitcoin, dữ liệu đó sẽ được gọi là giao dịch, tuy nhiên về nguyên tắc, chúng có thể bao gồm các cấu trúc dữ liệu tùy ý cho các mục đích tùy ý), dữ liệu hàng đợi đầu ra và dữ liệu nội bộ để chứng minh tính hợp lệ của quá trình chuyển đổi trạng thái (đối với Ethereum đây sẽ là các nút trie trạng thái/lưu trữ khác nhau cần thiết để thực hiện mỗi giao dịch). Bằng chứng thực nghiệm cho thấy tập dữ liệu đầy đủ này cho khối Ethereum gần đây nhiều nhất là vài trăm KiB. Đồng thời, nếu chưa thực hiện thì validator sẽ là cố gắng truy xuất thông tin liên quan đến quá trình chuyển đổi của khối trước đó, ban đầu từ khối trước đó validator giây trở đi từ tất cả validator ký kết sự sẵn có của dữ liệu. Khi validator đã nhận được khối ứng cử viên như vậy, sau đó họ xác nhận nó tại địa phương. Quá trình xác thực được chứa trong mô-đun validator của lớp parachain, một mô-đun phần mềm nhạy cảm với sự đồng thuận phải được viết đối với bất kỳ việc triển khai Polkadot nào (mặc dù về nguyên tắc một thư viện có C ABI có thể cho phép một thư viện duy nhất được chia sẻ giữa các lần thực hiện với giảm độ an toàn do chỉ thực hiện một “tài liệu tham khảo” duy nhất). Quá trình lấy tiêu đề của khối trước đó và xác minh danh tính của nó thông qua chuỗi chuyển tiếp đã được thống nhất gần đây khối trong đó hash của nó sẽ được ghi lại. Khi tính hợp lệ của tiêu đề gốc được xác định chắc chắn, parachain cụ thể chức năng xác nhận của lớp có thể được gọi. Đây là một hàm duy nhất chấp nhận một số trường dữ liệu (khoảng những cái đã cho trước đó) và trả về một giá trị Boolean đơn giản công bố tính hợp lệ của khối. Hầu hết các chức năng xác nhận như vậy trước tiên sẽ kiểm tra các trường tiêu đề có thể được lấy trực tiếp từ khối cha (ví dụ: cha hash, số). Đang theo dõi điều này, họ sẽ điền bất kỳ cấu trúc dữ liệu nội bộ nào dưới dạng cần thiết để xử lý các giao dịch và/hoặc bài viết. Đối với một chuỗi giống Ethereum, điều này tương đương với việc điền vào một thử cơ sở dữ liệu với các nút sẽ cần thiết cho thực hiện đầy đủ các giao dịch. Các loại chuỗi khác có thể có p kháccác cơ chế khắc phục. Sau khi hoàn tất, các bài đăng nhập và các giao dịch bên ngoài (hoặc bất kỳ dữ liệu bên ngoài nào thể hiện) sẽ được được ban hành, cân bằng theo đặc điểm kỹ thuật của chuỗi. (A mặc định hợp lý có thể là yêu cầu tất cả các bài viết xâm nhập phải được được xử lý trước khi các giao dịch bên ngoài được thực hiện, tuy nhiên điều này phải do logic của parachain quyết định.) Thông qua đạo luật này, một loạt các bài đăng đi ra sẽ được được tạo ra và nó sẽ được xác minh rằng những điều này thực sự phù hợp ứng cử viên của người đối chiếu. Cuối cùng, dân số hợp lý tiêu đề sẽ được kiểm tra dựa trên tiêu đề của ứng viên. Với khối ứng cử viên được xác thực đầy đủ, validator sau đó có thể bỏ phiếu cho hash của tiêu đề của nó và gửi tất cả thông tin xác thực cần thiết đến các co-validator trong nhóm con của nó. 6.7.1. Bộ sưu tập Parachain. Người đối chiếu Parachain là những người vận hành không liên kết, hoàn thành phần lớn nhiệm vụ của người khai thác trên các mạng blockchain ngày nay. Chúng cụ thể đến một parachain cụ thể. Để hoạt động họ phải duy trì cả chuỗi chuyển tiếp và đồng bộ hóa hoàn toàn parachain. Ý nghĩa chính xác của “được đồng bộ hóa hoàn toàn” sẽ phụ thuộc vào loại parachain, mặc dù sẽ luôn bao gồm trạng thái hiện tại của hàng đợi vào của parachain. Trong trường hợp của Ethereum, ít nhất nó cũng liên quan đến việc duy trì cơ sở dữ liệu cây Merkle của vài khối cuối cùng, nhưng có thể cũng bao gồm nhiều cấu trúc dữ liệu khác bao gồm Bloom bộ lọc để tồn tại tài khoản, thông tin gia đình, ghi nhật ký kết quả đầu ra và bảng tra cứu ngược cho số khối. Ngoài việc giữ cho hai chuỗi được đồng bộ hóa, nó cũng phải “câu” các giao dịch bằng cách duy trì hàng đợi giao dịch và chấp nhận các giao dịch được xác thực hợp lệ từ mạng công cộng. Với hàng đợi và chuỗi, nó là có thể tạo các khối ứng cử viên mới cho validator được chọn ở mỗi khối (có danh tính được biết do chuỗi chuyển tiếp được đồng bộ hóa) và gửi chúng cùng với thông tin phụ trợ khác nhau như bằng chứng về tính hợp lệ, thông qua mạng ngang hàng. Vì rắc rối của mình, nó thu tất cả các khoản phí liên quan đến các giao dịch mà nó bao gồm. Nhiều nền kinh tế khác nhau xoay quanh vấn đề này sắp xếp. Trong một thị trường cạnh tranh khốc liệt, nơi có là sự dư thừa của người đối chiếu, có thể giao dịch phí được chia sẻ với parachain validators để khuyến khích sự bao gồm của một khối đối chiếu cụ thể. Tương tự,
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 17 một số đối tác thậm chí có thể tăng các khoản phí cần thiết được trả tiền để làm cho khối này trở nên hấp dẫn hơn đối với validator giây. Trong trường hợp này, một thị trường tự nhiên sẽ hình thành với các giao dịch trả phí cao hơn, bỏ qua hàng đợi và tham gia vào chuỗi nhanh hơn. 6.8. Kết nối mạng. Kết nối mạng trên blockchains truyền thống như Ethereum và Bitcoin có những yêu cầu khá đơn giản. Tất cả các giao dịch và khối được phát đi trong một tin đồn đơn giản, không có định hướng. Đồng bộ hóa được tham gia nhiều hơn, đặc biệt là với Ethereum nhưng trên thực tế logic này được chứa trong chiến lược ngang hàng thay vì chính giao thức giải quyết xung quanh một số loại thông báo yêu cầu và trả lời. Trong khi Ethereum đã đạt được tiến bộ trong việc cung cấp giao thức hiện tại với giao thức devp2p, điều này cho phép nhiều các giao thức con được ghép kênh trên một kết nối ngang hàng duy nhất và do đó có cùng lớp phủ ngang hàng hỗ trợ nhiều p2p đồng thời, phần Ethereum của giao thức vẫn còn tương đối đơn giản và p2p giao thức trong một thời gian vẫn chưa được hoàn thành với những điều quan trọng thiếu chức năng như hỗ trợ QoS. Đáng buồn thay, mong muốn tạo ra một giao thức “web 3” phổ biến hơn phần lớn đã thất bại, với những dự án duy nhất sử dụng nó là những dự án rõ ràng được tài trợ từ đợt bán hàng cộng đồng Ethereum. Các yêu cầu đối với Polkadot khá quan trọng hơn. Thay vào đó là một mạng thống nhất hoàn toàn, Polkadot có nhiều loại người tham gia, mỗi loại có những yêu cầu khác nhau về thành phần ngang hàng của họ và một số mạng lưới “đại lộ” mà những người tham gia sẽ có xu hướng thảo luận về dữ liệu cụ thể. Điều này có nghĩa là lớp phủ mạng có cấu trúc chặt chẽ hơn—và một giao thức hỗ trợ điều đó— có thể sẽ cần thiết. Hơn nữa, khả năng mở rộng để tạo thuận lợi cho việc bổ sung trong tương lai chẳng hạn như các loại “chuỗi” mới có thể bản thân chúng đòi hỏi một cấu trúc lớp phủ mới. Trong khi thảo luận chuyên sâu về cách mạng giao thức có thể nằm ngoài phạm vi của tài liệu này, một số phân tích yêu cầu là hợp lý. Chúng tôi có thể chia nhỏ những người tham gia mạng lưới của chúng tôi thành hai nhóm (chuỗi chuyển tiếp, chuỗi parachain) mỗi tập hợp con trong số ba tập hợp con. Chúng tôi có thể cũng tuyên bố rằng mỗi người tham gia parachain chỉ quan tâm đến việc trò chuyện giữa họ chứ không phải người tham gia các parachain khác: • Những người tham gia chuỗi chuyển tiếp: • Trình xác nhận: P, chia thành các tập con P[s] cho mỗi tập parachain • Người bảo đảm tính khả dụng: A (điều này có thể được thể hiện bởi Người xác nhận ở dạng cơ bản của giao thức) • Máy khách chuỗi chuyển tiếp: M (lưu ý các thành viên của mỗi bộ parachain cũng sẽ có xu hướng là thành viên của M) • Người tham gia Parachain: • Bộ hợp tác Parachain: C[0], C[1], . . . • Ngư dân Parachain: F[0], F[1], . . . • Khách hàng Parachain: S[0], S[1], . . . • Các ứng dụng khách nhẹ của Parachain: L[0], L[1], . . . Nói chung, chúng tôi đặt tên cho các lớp giao tiếp cụ thể sẽ có xu hướng diễn ra giữa các thành viên của các tập hợp này: • P | A <-> P | Đáp: các đầy đủ đặt của validators/người bảo lãnh phải được kết nối tốt để đạt được sự đồng thuận. • P[s] <-> C[s] | P[s]: Mỗi validator với tư cách là thành viên của một nhóm parachain nhất định sẽ có xu hướng buôn chuyện với các thành viên khác cũng như các đối tác của parachain đó để khám phá và chia sẻ các ứng cử viên khối. • A <-> P[s] | C | A: Mỗi người bảo đảm tính sẵn có sẽ cần thu thập chuỗi chéo nhạy cảm với sự đồng thuận dữ liệu từ validator được gán cho nó; người đối chiếu cũng có thể tối ưu hóa cơ hội đồng thuận về chặn bằng cách quảng cáo nó cho những người bảo đảm tính sẵn có. Sau khi họ có nó, dữ liệu sẽ được chuyển tới người bảo lãnh khác để tạo thuận lợi cho sự đồng thuận. • P[s] <-> A | P[s']: Parachain validators sẽ cần thu thập dữ liệu đầu vào bổ sung từ tập validator trước đó hoặc những người bảo đảm tính khả dụng. • F[s] <-> P: Khi báo cáo, ngư dân có thể đặt một yêu cầu với bất kỳ người tham gia. • M <-> M | P | Đáp: Các khách hàng chuỗi chuyển tiếp chung giải ngân dữ liệu từ validator và người bảo lãnh. • S[s] <-> S[s] | P[s] | Trả lời: Khách hàng Parachain giải ngân dữ liệu từ validator/người bảo lãnh. • L[s] <-> L[s] | S[s]: Máy khách nhẹ Parachain giải ngân dữ liệu từ các khách hàng đầy đủ. Để đảm bảo một cơ chế vận chuyển hiệu quả, một “phẳng” mạng lớp phủ—như devp2p của Ethereum—trong đó mỗi mạng nút không (không tùy ý) phân biệt tính phù hợp của nó đồng nghiệp có thể sẽ không phù hợp. Có khả năng mở rộng hợp lý cơ chế lựa chọn và khám phá ngang hàng có thể sẽ cần được đưa vào trong giao thức cũng như tích cực lập kế hoạch nhìn về phía trước để đảm bảo chọn đúng loại đồng nghiệp là một cách tình cờct vào đúng thời điểm. Chiến lược chính xác của việc thành lập bạn bè sẽ khác nhau đối với mỗi lớp người tham gia: để có quy mô phù hợp đa chuỗi, các bộ đối chiếu sẽ cần phải liên tục kết nối lại với validator được bầu tương ứng, hoặc sẽ cần các thỏa thuận đang diễn ra với một tập hợp con validators để đảm bảo chúng không bị ngắt kết nối trong phần lớn thời gian chúng vô dụng đối với validator đó. Người hợp tác đương nhiên cũng sẽ cố gắng duy trì một hoặc kết nối ổn định hơn vào người bảo đảm sẵn có được thiết lập để đảm bảo truyền bá nhanh chóng các thông tin nhạy cảm với sự đồng thuận của họ dữ liệu. Những người bảo đảm tính sẵn sàng sẽ chủ yếu nhằm mục đích duy trì một kết nối ổn định với nhau và với validators (để có được sự đồng thuận và dữ liệu parachain quan trọng đồng thuận mà họ chứng thực), cũng như với một số đối tác (đối với parachain dữ liệu) và một số ngư dân và khách hàng đầy đủ (để phân tán thông tin). Người xác nhận sẽ có xu hướng tìm kiếm validator khác, đặc biệt là những người trong cùng một nhóm phụ và bất kỳ các đối tác có thể cung cấp cho họ các ứng viên khối parachain. Ngư dân, cũng như chuỗi chuyển tiếp và parachain nói chung khách hàng thường sẽ hướng tới mục tiêu duy trì kết nối mở cho một validator hoặc người bảo lãnh, nhưng có nhiều nút khác tương tự đối với chính họ bằng cách khác. Tương tự, các máy khách nhẹ của Parachain sẽ hướng tới mục tiêu được kết nối với một máy khách đầy đủ của parachain, nếu không chỉ các client ánh sáng parachain khác. 6.8.1. Vấn đề về sự rời bỏ ngang hàng. Trong đề xuất giao thức cơ bản, mỗi tập hợp con này liên tục thay đổi ngẫu nhiên theo từng khối dưới dạng validator được chỉ định để xác minh quá trình chuyển đổi parachain được chọn ngẫu nhiên. Điều này có thể là một vấn đề nên các nút khác nhau (không ngang hàng) cần phải truyền dữ liệu cho nhau. Người ta hoặc phải dựa vào một mạng ngang hàng được phân phối khá tốt và được kết nối tốt với
POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 18 đảm bảo rằng khoảng cách hop (và do đó độ trễ trong trường hợp xấu nhất) chỉ tăng theo logarit của kích thước mạng (giao thức giống Kademlia [13] có thể hữu ích ở đây) hoặc người ta phải giới thiệu thời gian chặn dài hơn để cho phép diễn ra quá trình đàm phán kết nối cần thiết nhằm duy trì một tập hợp ngang hàng phản ánh nhu cầu liên lạc hiện tại của nút. Cả hai đều không phải là giải pháp tuyệt vời: thời gian chặn dài bị ép buộc vào mạng có thể khiến nó trở nên vô dụng đối với các ứng dụng và chuỗi cụ thể. Thậm chí là hoàn toàn công bằng và mạng được kết nối sẽ gây lãng phí đáng kể băng thông khi nó tăng quy mô do các nút không quan tâm có để chuyển tiếp dữ liệu vô dụng cho họ. Mặc dù cả hai hướng có thể tạo thành một phần của giải pháp, tối ưu hóa hợp lý để giúp giảm thiểu độ trễ sẽ nhằm hạn chế tính biến động của các parachain này validator các bộ, hoặc chỉ gán lại tư cách thành viên giữa các chuỗi khối (ví dụ: trong nhóm 15, với tốc độ 4 giây thời gian chặn có nghĩa là chỉ thay đổi kết nối một lần mỗi lần phút) hoặc bằng cách luân phiên thành viên theo kiểu tăng dần, ví dụ: thay đổi bởi một thành viên tại một thời điểm (ví dụ: nếu có là 15 validator được gán cho mỗi parachain, thì trung bình sẽ mất trọn một phút giữa các chuỗi hoàn toàn duy nhất bộ). Bằng cách hạn chế số lượng rời bỏ ngang hàng và đảm bảo rằng các kết nối ngang hàng thuận lợi được thực hiện tốt trong tiến lên nhờ khả năng dự đoán một phần của parachain các bộ, chúng tôi có thể giúp đảm bảo mỗi nút duy trì vĩnh viễn sự lựa chọn tình cờ của các đồng nghiệp. 6.8.2. Đường dẫn đến một giao thức mạng hiệu quả. Có khả năng nỗ lực phát triển hợp lý và hiệu quả nhất sẽ tập trung vào việc sử dụng giao thức có sẵn thay vì triển khai của riêng chúng tôi. Một số giao thức cơ sở ngang hàng tồn tại chúng tôi có thể sử dụng hoặc bổ sung thêm devp2p của chính Ethereum [22], libp2p [1] của IPFS và GNUnet [4] của GNU. Đánh giá đầy đủ về các giao thức này và sự liên quan của chúng đối với việc xây dựng một mạng ngang hàng mô-đun hỗ trợ các đảm bảo về cấu trúc nhất định, định hướng ngang hàng năng động và các giao thức phụ có thể mở rộng vượt xa phạm vi của tài liệu này nhưng sẽ là một bước quan trọng trong việc triển khai Polkadot. 7. Tính thực tiễn của Nghị định thư 7.1. Thanh toán giao dịch liên chuỗi. Trong khi tuyệt vời mức độ tự do và đơn giản đạt được thông qua việc loại bỏ nhu cầu về khung kế toán tài nguyên tính toán tổng thể như gas của Ethereum, điều này đặt ra một câu hỏi quan trọng: không có gas, làm thế nào một parachain tránh việc parachain khác buộc nó thực hiện tính toán? Mặc dù chúng ta có thể dựa vào hàng đợi nhập sau giao dịch bộ đệm để ngăn chặn một chuỗi gửi thư rác cho một chuỗi khác bằng dữ liệu giao dịch, không có cơ chế tương đương nào được cung cấp bởi giao thức để ngăn chặn việc gửi thư rác trong quá trình xử lý giao dịch. Đây là một vấn đề còn lại ở cấp độ cao hơn. Vì chuỗi được tự do đính kèm ngữ nghĩa tùy ý vào dữ liệu đến dữ liệu sau giao dịch, chúng tôi có thể đảm bảo rằng việc tính toán phải được thanh toán trước khi bắt đầu. Theo cách tương tự như người mẫu được tán thành bởi Ethereum Serenity, chúng ta có thể tưởng tượng một hợp đồng “đột nhập” trong parachain cho phép validator được đảm bảo thanh toán để đổi lấy cung cấp một khối lượng tài nguyên xử lý cụ thể. Những tài nguyên này có thể được đo bằng thứ gì đó như khí đốt, nhưng cũng có thể là một số mô hình hoàn toàn mới, chẳng hạn như thời gian thực hiện chủ quan hoặc mô hình phí cố định giống Bitcoin. Bản thân điều này không hữu ích lắm vì chúng ta không thể dễ dàng cho rằng người gọi ngoài chuỗi có sẵn cho họ bất kỳ cơ chế giá trị nào được nhận ra khi đột nhập hợp đồng. Tuy nhiên, chúng ta có thể tưởng tượng một hợp đồng “đột phá” thứ cấp trong chuỗi nguồn. Hai bản hợp đồng với nhau sẽ tạo thành cầu nối, nhận biết nhau và cung cấp giá trị tương đương. (Stake-tokens, có sẵn cho mỗi khoản, có thể được sử dụng để giải quyết cán cân thanh toán.) Gọi vào một chuỗi khác như vậy có nghĩa là ủy quyền thông qua cây cầu này, nó sẽ cung cấp phương tiện đàm phán về việc chuyển giao giá trị giữa các chuỗi để trả tiền cho các tài nguyên tính toán cần thiết trên parachain đích. 7.2. bổ sung Dây chuyền. Trong khi cái phép cộng của một parachain là một hoạt động tương đối rẻ và không miễn phí. Nhiều parachain hơn có nghĩa là ít validator trên mỗi parachain hơn và cuối cùng, số lượng validator lớn hơn, mỗi số có một trái phiếu trung bình giảm. Mặc dù vấn đề về chi phí ép buộc nhỏ hơn khi tấn công parachain được giảm thiểu thông qua ngư dân, bộ validator ngày càng tăng về cơ bản buộc phải độ trễ cao hơn do cơ chế đồng thuận cơ bản của tôithod. Hơn nữa, mỗi parachain mang theo nó khả năng gây đau buồn cho validator với một thuật toán xác nhận quá nặng nề. Như vậy sẽ có một số “giá” validators và/hoặc cộng đồng nắm giữ cổ phần sẽ khai thác để bổ sung một parachain mới. Thị trường dây chuyền này sẽ có thể thấy việc bổ sung một trong hai: • Các chuỗi có khả năng không đóng góp ròng (về mặt khóa hoặc đốt staking tokens) để trở thành một phần (ví dụ: chuỗi liên minh, Chuỗi Doge, chuỗi dành riêng cho ứng dụng); • chuỗi mang lại giá trị nội tại cho mạng thông qua việc thêm chức năng cụ thể khó khăn để đi nơi khác (ví dụ: tính bảo mật, khả năng mở rộng nội bộ, liên kết dịch vụ). Về cơ bản, cộng đồng các bên liên quan sẽ cần phải được khuyến khích thêm các chuỗi con—về mặt tài chính hoặc thông qua mong muốn bổ sung thêm các chuỗi tính năng vào rơle. Người ta hình dung rằng các chuỗi mới được thêm vào sẽ có tác dụng rất thời gian thông báo ngắn để loại bỏ, cho phép các chuỗi mới được thử nghiệm mà không có bất kỳ nguy cơ ảnh hưởng nào đề xuất giá trị trung hoặc dài hạn. 8. Kết luận Chúng tôi đã vạch ra một hướng đi mà người ta có thể thực hiện để viết một giao thức đa chuỗi không đồng nhất, có thể mở rộng, có khả năng tương thích ngược với một số giao thức nhất định đã tồn tại từ trước blockchain mạng. Theo một giao thức như vậy, những người tham gia làm việc vì lợi ích cá nhân rõ ràng để tạo ra một hệ thống tổng thể có thể được mở rộng theo cách đặc biệt miễn phí và không phải trả chi phí thông thường cho người dùng hiện tại đến từ thiết kế blockchain tiêu chuẩn. Chúng tôi đã đưa ra một phác thảo sơ bộ về kiến trúc cần bao gồm bản chất của những người tham gia, động cơ kinh tế của họ và các quá trình mà họ phải tham gia. Chúng tôi có xác định một thiết kế cơ bản và thảo luận về điểm mạnh và những hạn chế; theo đó chúng tôi có thêm hướng dẫn có thể giảm bớt những hạn chế đó và mang lại nền tảng vững chắc hơn cho giải pháp blockchain có thể mở rộng hoàn toàn.POLKADOT: TẦM NHÌN VỀ KHUNG KHUNG ĐA CHUỖI KHÔNG ĐỒNG THỂ DỰ THẢO 1 19 8.1. Thiếu tài liệu và câu hỏi mở. Việc phân nhánh mạng luôn có thể xảy ra do việc triển khai giao thức khác nhau. Sự phục hồi từ tình trạng như vậy tình trạng đặc biệt đã không được thảo luận. Do mạng nhất thiết phải có thời gian hoàn thiện khác 0, việc khôi phục sau quá trình phân nhánh chuỗi chuyển tiếp không phải là vấn đề lớn, tuy nhiên sẽ yêu cầu tích hợp cẩn thận vào giao thức đồng thuận. Việc tịch thu trái phiếu và ngược lại, cung cấp phần thưởng có chưa được tìm hiểu sâu. Hiện tại chúng tôi giả định phần thưởng được cung cấp theo nguyên tắc người thắng được tất cả: điều này có thể không đưa ra mô hình khuyến khích tốt nhất cho ngư dân. Một quá trình tiết lộ cam kết trong thời gian ngắn sẽ cho phép nhiều ngư dân để nhận giải thưởng và phân phối phần thưởng công bằng hơn, tuy nhiên quá trình này có thể dẫn đến độ trễ bổ sung trong việc phát hiện hành vi sai trái. 8.2. Lời cảm ơn. Rất cám ơn tất cả các những người đọc thử đã giúp giải quyết vấn đề này một cách mơ hồ hình dạng có thể trình bày. Đặc biệt, Peter Czaban, Bj¨orn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler và Jack Petersson. Cảm ơn tất cả những người đã đóng góp ý tưởng hoặc sự khởi đầu vì vậy, Marek Kotewicz và Aeron Buchanan xứng đáng được đề cập đặc biệt. Và cảm ơn mọi người vì sự giúp đỡ của họ trên đường đi. Tất cả các lỗi là của riêng tôi. Các phần của công việc này, bao gồm cả nghiên cứu ban đầu về thuật toán đồng thuận, được tài trợ một phần bởi người Anh Chính phủ theo chương trình Đổi mới của Vương quốc Anh.