Polkadot: Heterojen Çok Zincirli Çerçeve Vizyonu

بقلم Gavin Wood · 2016

وضع فردي polkadot.com

خلاصة

بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 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

Özet

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 DR. GAVİN AHŞAP KURUCU, ETHEREUM & PARİTE [email protected] Özet. Günümüzün blockchain mimarilerinin tümü, özellikle pratik genişletilebilirlik ve ölçeklenebilirlik araçlarının yanı sıra bir dizi sorundan muzdariptir. Bunun, fikir birliği mimarisinin çok önemli iki parçasını birbirine bağlamasından kaynaklandığına inanıyoruz: kanoniklik ve geçerlilik birbirine çok yakındır. Bu makale, heterojen çoklu zincir mimarisini tanıtmaktadır. bu ikisini temelde birbirinden ayırıyor. Bu iki parçayı bölümlere ayırarak ve sağlanan genel işlevselliği mutlak minimumda tutarak Güvenlik ve ulaşım açısından, çekirdeğin yerinde genişletilebilirliğine yönelik pratik araçlar sunuyoruz. Ölçeklenebilirlik şu şekilde ele alınır: bu iki işleve böl ve yönet yaklaşımı, bağlı çekirdeğin ölçeğini, teşvik yoluyla genişletiyor güvenilmeyen genel düğümler. Bu mimarinin heterojen doğası, çok farklı türden konsensüs sistemlerinin güvene dayalı olmayan, tamamen merkezi olmayan bir "federasyon" içinde birlikte çalışmasına olanak tanıyarak, açık ve kapalı ağların güvensiz erişime sahip olmasına olanak tanır. Birbirimiz. Aşağıdakiler gibi önceden var olan bir veya daha fazla ağ ile geriye dönük uyumluluk sağlamanın bir yolunu ortaya koyduk: Ethereum. Böyle bir sistemin pratik olarak genel arayışta temel düzeyde yararlı bir bileşen sağladığına inanıyoruz. Küresel ticarette ölçeklenebilirlik ve gizlilik düzeylerine ulaşabilen uygulanabilir bir sistem. 1. Önsöz Bunun teknik bir “vizyon” özeti olması amaçlanmıştır blockchain paradigmasını daha da geliştirmek için alınabilecek olası bir yön ve bu yönün neden mantıklı olduğuna dair bazı gerekçeler. Şurada yer alıyor: Gelişimin bu aşamasında mümkün olduğu kadar fazla ayrıntı somut bir iyileşme sağlayabilecek bir sistem blockchain teknolojisinin çeşitli yönleri. Resmi veya başka türlü bir spesifikasyon olması amaçlanmamıştır. Kapsamlı olması ya da bir olması amaçlanmamıştır. son tasarım. Temel olmayan hususları kapsaması amaçlanmamıştır. API'ler, bağlamalar, diller ve kullanım. Bu özellikle deneyseldir; nerede parametreler belirtilirse, değişmeleri muhtemeldir. Mekanizmalar topluluğa yanıt olarak eklenebilir, geliştirilebilir ve kaldırılabilir fikirler ve eleştiriler. Bu makalenin büyük bir kısmı muhtemelen Deneysel kanıt ve prototiplemenin sağladığı gibi revize edilebilir Neyin işe yarayıp neyin yaramayacağına dair bize bilgi verin. Bu belge, protokolün temel bir tanımını ve alınabilecek talimatlara ilişkin fikirleri içerir. çeşitli yönleri geliştirmek. Çekirdek olması öngörülüyor açıklama bir başlangıç için başlangıç noktası olarak kullanılacaktır bir dizi kavram kanıtı. Son bir “versiyon 1.0” şu şekilde olacaktır: kanıtlanmış ve kararlı hale gelen ek fikirlerle birlikte bu rafine protokole dayanmaktadır. Projenin hedeflerine ulaşması için gerekli olan 1.1. Tarih. • 09/10/2016: 0.1.0'a dayanıklı1 • 20/10/2016: 0.1.0'a dayanıklı2 • 01/11/2016: 0.1.0'a dayanıklı3 • 10/11/2016: 0.1.0 2. Giriş Blok zincirleri, “Nesnelerin İnterneti” de dahil olmak üzere birçok alanda büyük fayda vaat ediyor (IoT), finans, yönetişim, kimlik yönetimi, web merkezi olmayanlaştırma ve varlık takibi. Ancak buna rağmen teknolojik vaat ve büyük konuşma, henüz göremedik mevcut teknolojinin önemli gerçek dünyaya yayılması. Bunun günümüzün beş önemli başarısızlığından kaynaklandığına inanıyoruz. teknoloji yığınları: Ölçeklenebilirlik: Küresel olarak ne kadar kaynak harcanıyor? sistemin tek bir işlemi işlemesi için işleme, bant genişliği ve depolama ve kaç tane işlemler makul bir şekilde gerçekleştirilebilir zirve koşulları? Yalıtılabilirlik: Çoklu bireylerin farklı ihtiyaçları Taraflar ve başvurular aynı çerçeve altında optimuma yakın bir düzeyde ele alınabiliyor mu? Geliştirilebilirlik: Araçlar ne kadar iyi çalışıyor? Yap API'ler geliştiricilerin ihtiyaçlarını karşılıyor mu? Eğitim materyalleri mevcut mu? Doğru entegrasyonlar mevcut mu? Yönetişim: Ağ esnek kalabilir mi? zaman içinde gelişip uyum sağlıyor mu? Kararlar olabilir mi Yeterli kapsayıcılık, meşruluk ve etkili bir liderlik sağlamak için şeffaflık merkezi olmayan sistem? Uygulanabilirlik: Teknoloji gerçekten kendi başına yakıcı bir ihtiyacı karşılıyor mu? Aradaki boşluğu kapatmak için başka bir "ara katman yazılımı" gerekli mi? gerçek uygulamalar? Bu çalışmamızda ilk ikisini ele almayı amaçlıyoruz. Sorunlar: ölçeklenebilirlik ve yalıtılabilirlik. Bununla birlikte, inanıyoruz Polkadot çerçevesi bu sorun sınıflarının her birinde anlamlı iyileştirmeler sağlayabilir. Modern, verimli blockchain uygulamalar gibi Eşlik Ethereum istemcisi [17] işlem yapabilirfazla Performanslı tüketici donanımı üzerinde çalışırken saniyede 3.000 işlem. Ancak mevcut gerçek dünya blockchain ağlar pratik olarak yaklaşık 30 ile sınırlıdır saniye başına işlemler. Bu sınırlama temel olarak mevcut eşzamanlı konsensüs mekanizmalarının geniş zamanlama güvenlik marjları gerektirmesinden kaynaklanmaktadır. nedeniyle daha da kötüleşen beklenen işlem süresi 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 نشارك بعض أوجه التشابه العابرة التي نعتقد أنها هدفها النهائي مختلفة إلى حد كبير، وذلك بدلا من التنافس، من المرجح أن يتعايش البروتوكولان في النهاية تحت عنوان علاقة منفعة متبادلة في المستقبل المنظور.

giriiş

Blok zincirleri, “Nesnelerin İnterneti” de dahil olmak üzere birçok alanda büyük fayda vaat ediyor (IoT), finans, yönetişim, kimlik yönetimi, web merkezi olmayanlaştırma ve varlık takibi. Ancak buna rağmen teknolojik vaat ve büyük konuşma, henüz göremedik mevcut teknolojinin önemli gerçek dünyaya yayılması. Bunun günümüzün beş önemli başarısızlığından kaynaklandığına inanıyoruz. teknoloji yığınları: Ölçeklenebilirlik: Küresel olarak ne kadar kaynak harcanıyor? sistemin tek bir işlemi işlemesi için işleme, bant genişliği ve depolama ve kaç tane işlemler makul bir şekilde gerçekleştirilebilir zirve koşulları? Yalıtılabilirlik: Çoklu bireylerin farklı ihtiyaçları Taraflar ve başvurular aynı çerçeve altında optimuma yakın bir düzeyde ele alınabiliyor mu? Geliştirilebilirlik: Araçlar ne kadar iyi çalışıyor? Yap API'ler geliştiricilerin ihtiyaçlarını karşılıyor mu? Eğitim materyalleri mevcut mu? Doğru entegrasyonlar mevcut mu? Yönetişim: Ağ esnek kalabilir mi? zaman içinde gelişip uyum sağlıyor mu? Kararlar olabilir mi Yeterli kapsayıcılık, meşruluk ve etkili bir liderlik sağlamak için şeffaflık merkezi olmayan sistem? Uygulanabilirlik: Teknoloji gerçekten kendi başına yakıcı bir ihtiyacı karşılıyor mu? Aradaki boşluğu kapatmak için başka bir "ara katman yazılımı" gerekli mi? gerçek uygulamalar? Bu çalışmamızda ilk ikisini ele almayı amaçlıyoruz. Sorunlar: ölçeklenebilirlik ve yalıtılabilirlik. Bununla birlikte, inanıyoruz Polkadot çerçevesi bu sorun sınıflarının her birinde anlamlı iyileştirmeler sağlayabilir. Modern, verimli blockchain uygulamalar gibi Eşlik Ethereum istemcisi [17] şunu aşabilir: Performanslı tüketici donanımı üzerinde çalışırken saniyede 3.000 işlem. Ancak mevcut gerçek dünya blockchain ağlar pratikte yaklaşık 30 ile sınırlıdır saniye başına işlemler. Bu sınırlama temel olarak mevcut eşzamanlı konsensüs mekanizmalarının geniş zamanlama güvenlik marjları gerektirmesinden kaynaklanmaktadır. nedeniyle daha da kötüleşen beklenen işlem süresiPOLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 2 Daha yavaş uygulamaları destekleme arzusu. Bunun nedeni altta yatan fikir birliği mimarisi: durum geçiş mekanizması veya tarafların bir araya geldiği araçlar ve işlemleri yürütür, mantığı temelden birbirine bağlıdır fikir birliğine varılmış “kanonikleştirme” mekanizmasına veya Tarafların çeşitli seçeneklerden biri üzerinde anlaşmaya vardıkları araç mümkün, geçerli, geçmişler. Bu, hem Bitcoin [15] ve Ethereum [5,23] gibi proof-of-work (PoW) sistemleri hem de NXT [8] ve Bitshares [12] gibi stake kanıtı (PoS) sistemleri için eşit derecede geçerlidir: sonuçta hepsi aynı handikaptan muzdariptir. Bu basit bir blockchains'nin başarıya ulaşmasına yardımcı olan strateji. Ancak, bu iki mekanizmayı tek bir ünitede sıkı bir şekilde birleştirerek protokolün yanı sıra birden fazla farklı öğeyi de bir araya getiriyoruz farklı risk profillerine, farklı ölçeklenebilirlik gereksinimlerine ve farklı gizlilik ihtiyaçlarına sahip aktörler ve uygulamalar. Tek beden herkese uymaz. Çoğu zaman durum böyledir Geniş bir kitleye ulaşma arzusunda olan bir ağ, en düşük ortak paydayla sonuçlanan bir muhafazakarlık derecesini benimser optimal olarak az sayıda kişiye hizmet vermek ve sonuçta başarısızlığa yol açmak Bazen yenilik yapma, performans gösterme ve uyum sağlama yeteneğinde dramatik bir şekilde öyle. Örneğin bazı sistemler. Factom [21] durum geçiş mekanizmasını tamamen bırakın. Ancak çoğu Arzuladığımız fayda, geçiş durumuna geçme yeteneğini gerektirir paylaşılan bir durum makinesine göre. Bırakmak çözer alternatif bir sorun; bir alternatif sunmuyor çözüm. Bu nedenle, makul bir yönün olduğu açık görünüyor ölçeklenebilir merkezi olmayan bir bilişime giden yolu keşfetmek platform, fikir birliği mimarisini birbirinden ayırmaktır. durum geçiş mekanizması. Ve belki de şaşırtıcı olmayan bir şekilde bu, Polkadot'nın ölçeklenebilirliğe çözüm olarak benimsediği stratejidir. 2.1. Protokol, Uygulama ve Ağ. Beğen Bitcoin ve Ethereum, Polkadot aynı anda bir ağ protokolüne ve (şimdiye kadar varsayılan) birincil ağ protokolüne atıfta bulunur Bu protokolü çalıştıran genel ağ. Polkadot ücretsiz ve açık bir proje olarak tasarlanmıştır; protokol spesifikasyonu Creative Commons lisansı altındadır ve kod FLOSS lisansı altına yerleştiriliyor. Proje açık bir şekilde geliştirildi ve katkıları kabul etti nerede faydalı olurlarsa olsunlar. RFC'lerden oluşan bir sistem, pek de farklı değil Python Geliştirme Önerileri, bir araç sağlayacaktır Protokol değişiklikleri ve yükseltmeleri üzerinde kamuya açık işbirliği yapmak. Polkadot protokolünü ilk uygulamamız Parite Polkadot Platformu olarak bilinecek ve API ile birlikte tam bir protokol uygulamasını içerir bağlamalar. Diğer Eşlik blockchain uygulamalarında olduğu gibi, PPP, genel amaçlı bir blockchain teknoloji yığını olacak şekilde tasarlanmıştır; ne yalnızca genel bir ağ için ne de özel/konsorsiyum operasyonu. Gelişimi bu şekilde far dahil olmak üzere çeşitli taraflarca finanse edildi İngiliz hükümetinden bir hibe. Yine de bu belgede Polkadot şu şekilde açıklanmaktadır: halka açık bir ağın bağlamı. Genel bir ağda öngördüğümüz işlevsellik, gerekli olanın bir üst kümesidir. alternatif (örn. özel ve/veya konsorsiyum) ayarlar. Ayrıca bu bağlamda Polkadot'nin tam kapsamı daha net bir şekilde tanımlanıp tartışılacaktır. Bu şu anlama geliyor okuyucu belirli mekanizmaların olabileceğinin farkında olmalıdır. Polkadot ile doğrudan alakalı olmayan şekilde tanımlanmalı (örneğin diğer genel ağlarla birlikte çalışma) kamuya açık olmayan (“izin verilen”) durumlarda konuşlandırıldığında. 2.2. Önceki çalışma. Temel fikir birliğinin devlet geçişinden ayrılması gayri resmi olarak önerildi en az iki yıl boyunca özel olarak - Max Kaye, devrimin ilk günlerinde böyle bir stratejinin savunucusuydu. Ethereum. Zincir olarak bilinen daha karmaşık ölçeklenebilir bir çözüm tarihi Haziran 2014'e kadar uzanan ve ilk kez daha sonra yayınlanan lifler o yıl1, şeffaf bir zincirler arası yürütme mekanizması sağlayan tek bir aktarma zinciri ve birden fazla homojen zincirin gerekliliği ortaya çıktı. Uyumsuzluğun bedeli ödendi işlem gecikmesi yoluyla - işlem gerektiren işlemler sistemin farklı bölümlerinin koordinasyonu işlenmesi daha uzun sürer. Polkadot mimarisinin çoğunu bundan ve takip eden görüşmelerden alıyor Tasarımı ve hükümleri açısından büyük farklılıklar gösterse de çeşitli insanlar tarafından tercih edilir. Polkadot ile karşılaştırılabilecek bir sistem olmasa da aslında üretimde, bazı alakalı birkaç sistem önemli düzeyde az da olsa önerilmiştir. detay. Bu öneriler şunlar olabilir:sistemlere ayrılmış küresel olarak tutarlılık kavramını düşüren veya azaltan küresel bir hizmet sağlamaya çalışan devlet makinesi homojen parçalar aracılığıyla tutarlı tekli makine ve yalnızca heterojenliği hedefleyenler. 2.2.1. Küresel Devleti olmayan sistemler. Factom [21], uygun olmayan şekilde kanoniklik gösteren bir sistemdir geçerlilik, verilerin kronikleştirilmesine etkili bir şekilde izin verir. Küresel devletten kaçınma ve zorluklar nedeniyle bunun getirdiği ölçeklendirme ile ölçeklenebilir bir çözüm sayılabilir. Ancak daha önce de belirtildiği gibi set çözdüğü problemlerin sayısı kesinlikle ve önemli ölçüde daha azdır. Tangle [18] fikir birliği sistemlerine yeni bir yaklaşımdır. İşlemleri bloklar halinde düzenlemek ve durum değişikliklerine küresel olarak kanonik bir sıralama vermek için sıkı bir şekilde bağlantılı bir liste üzerinde fikir birliği oluşturmak yerine, yoğun şekilde yapılandırılmış bir sıralama fikrinden büyük ölçüde vazgeçilir ve bunun yerine daha önceki öğelerin kanonikleştirilmesine yardımcı olan daha sonraki öğelerle birlikte bağımlı işlemlerin yönlendirilmiş, döngüsel olmayan bir grafiğini zorlar açık referans yoluyla. Keyfi durum değişiklikleri için, bu bağımlılık grafiği hızla kontrol edilemez hale gelecektir, ancak çok daha basit olan UTXO model2 için bu şu şekilde olur: oldukça makul. Çünkü sistem sadece gevşek bir şekilde tutarlıdır ve işlemler genellikle birbirinden bağımsızdır. Öte yandan, büyük miktarda küresel paralellik oldukça doğal. UTXO modelini kullanmanın etkisi var Tangle'ı tamamen değer aktarımı sağlayan bir "para birimi" ile sınırlamak daha genel veya genişletilebilir bir şey yerine sistem. Üstelik katı küresel tutarlılık olmadan, mutlak bir kontrole ihtiyaç duyma eğiliminde olan diğer sistemlerle etkileşim Sistem durumu hakkında derece bilgisi pratik hale gelir. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2harcanmamış işlem çıktısı, Bitcoin'nin kullandığı model, burada durum etkin olarak bir değerle ilişkili adres kümesidir; işlemler bu tür adresleri bir araya getirir ve bunları toplamı eşdeğer olan yeni bir adres kümesi halinde yeniden düzenler

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 3 2.2.2. Heterojen Zincir Sistemleri. Yan zincirler [3] bir ana Bitcoin zinciri arasında güvenilmez etkileşime izin verecek Bitcoin protokolüne önerilen ekleme ve ek yan zincirler. Herhangi bir hüküm bulunmamaktadır Yan zincirler arasındaki 'zengin' etkileşimin derecesi: etkileşim, yan zincirlerin birbirine bağlanmasına izin vermekle sınırlı olacaktır. yerel düzeyde birbirlerinin varlıklarının koruyucuları jargon—iki yönlü sabit 3. Nihai vizyon, Bitcoin para biriminin sağlanabileceği bir çerçeveye yöneliktir. sabitleme yoluyla ek, eğer çevresel ise, işlevsellik daha egzotik durum geçişiyle diğer bazı zincirlere Bitcoin protokolünün izin verdiği sistemler. Bu anlamda, Yan zincirler ölçeklenebilirlikten ziyade genişletilebilirliğe yöneliktir. Aslında yan zincirlerin geçerliliğine ilişkin temelde hiçbir hüküm yoktur; Bir zincirden tokens (ör. Bitcoin) bir yan zincir adına tutulanlar yalnızca Yan zincirin madencileri kanonikleştirmeye teşvik etme yeteneği geçerli geçişler Bitcoin ağının güvenliği başkaları adına çalışmaya kolaylıkla geçiş yapılamaz blockchains. Ayrıca Bitcoin sağlanmasına yönelik bir protokol Madenciler madeni birleştiriyor (yani kanonikleştirme güçlerini yan zincirinkine kopyalıyorlar) ve daha da önemlisi, yan zincirin geçişlerinin yan zincirin dışında olduğunu doğruluyorlar bu teklifin kapsamı. Cosmos [10] önerilen bir çok zincirli sistemdir. Yan zincirlerle aynı damar, Nakamoto PoW'u değiştiriyor Jae Kwon'un Tendermint algoritması için fikir birliği yöntemi. Esasen birden fazla zinciri tanımlar (birbirinde faaliyet gösteren) bölgeleri) her biri ayrı ayrı Tendermint örneklerini ve bir ağ üzerinden güven gerektirmeyen iletişim aracını kullanıyor ana göbek zinciri. Bu zincirler arası iletişim, keyfi bilgilerden ziyade dijital varlıkların (“özellikle tokens hakkında”) aktarımıyla sınırlıdır, ancak bu tür zincirler arası iletişimin veriler için bir dönüş yolu vardır, örneğin Göndericiye aktarımın durumu hakkında rapor vermek. Bölgelere ayrılmış zincirler için doğrulayıcı kümeler ve özellikle onları teşvik etmenin araçları yan zincirler gibi bırakıldı çözülmemiş bir sorun olarak Genel varsayım şudur her bölgeli zincirin kendisi token değerinde bir değere sahip olacak ve bu değerin enflasyonu validators'yi ödemek için kullanılacak. Hala erken aşamalarda Tasarım konusunda şu anda teklif, ölçeklenebilir hedefe ulaşmanın ekonomik araçlarına ilişkin kapsamlı ayrıntılardan yoksundur. Küresel geçerliliğin kesinliği. Ancak bölgeler ile merkez arasında gereken gevşek tutarlılık, bölgelere ayrılmış parametreler üzerinde ilave esneklik için daha güçlü bir sistem uygulayan bir sistemle karşılaştırıldığında zincirler tutarlılık. 2.2.3. Casper. Casper [6] ve Polkadot arasında henüz kapsamlı bir inceleme veya yan yana karşılaştırma yok oldukça kapsamlı bir inceleme yapılabilir ancak ikisinin (ve buna bağlı olarak yanlış) karakterizasyonu. Casper, PoS konsensüs algoritmasının nasıl yeniden tasarlandığını gösteriyor katılımcıların hangi çatala dair bahis oynadıkları temeline dayanabilir. sonuçta kanonik hale gelecektir. Ağa karşı dayanıklı olmasını sağlamak için büyük önem verildi çatallar, uzatıldığında bile ve temel Ethereum modelinin üzerinde bir miktar ek ölçeklenebilirliğe sahiptir. olarak Casper bugüne kadar önemli ölçüde daha fazla olma eğilimindeydi. Polkadot ve atalarından daha karmaşık bir protokol ve temel blockchain biçiminden önemli sapma. o Casper'ın gelecekte nasıl yineleneceği henüz bilinmiyor ve nihayet konuşlandırıldığında neye benzeyeceği. Casper ve Polkadot her ikisi de ilginç yeni protokolleri ve bir anlamda Ethereum, aralarında önemli farklar var Nihai hedefler ve dağıtım yolları. Casper bir Ethereum Orijinal olarak tasarlanmış temel merkezli proje istemeden protokolde PoS değişikliği yapmak temelde ölçeklenebilir bir blockchain oluşturun. Önemli olan, daha kapsamlı bir şey olmaktan ziyade bir hard fork olacak şekilde tasarlandı ve bu nedenle tüm Ethereum istemcileri ve kullanıcıları Yükseltilmesi veya belirsiz bir benimseme çatalında kalması gerekiyor. Bu nedenle, sıkı kuralların olduğu merkezi olmayan bir projenin doğasında olduğu gibi dağıtım önemli ölçüde daha zor hale gelir. koordinasyon gereklidir. Polkadot birkaç açıdan farklılık gösterir; her şeyden önce, Polkadot tamamen genişletilebilir ve ölçeklenebilir olacak şekilde tasarlanmıştır blockchain geliştirme, dağıtım ve etkileşim testi yatak. Büyük ölçüde geleceğe yönelik bir emniyet kemeri olacak şekilde inşa edilmiştir. yeni blockchain asimile etaşırı karmaşık merkezi olmayan koordinasyon olmadan kullanılabilir hale gelen teknoloji veya sert çatallar. Halihazırda bunun gibi çeşitli kullanım senaryolarını öngörüyoruz. şifrelenmiş konsorsiyum zincirleri ve yüksek frekanslı zincirler olarak yapılması gerçekçi olmayan çok düşük blok süreleriyle Ethereum'nin şu anda öngörülen gelecekteki herhangi bir sürümü. Son olarak, onunla Ethereum arasındaki bağlantı son derece yüksektir gevşek; Ethereum tarafından herhangi bir işlem yapılmasına gerek yoktur. ikisi arasında güvenilir işlem iletimini etkinleştir ağlar. Kısacası Casper/Ethereum 2.0 ve Polkadot Nihai hedeflerine inandığımız bazı geçici benzerlikleri paylaşıyoruz önemli ölçüde farklıdır ve rekabet etmek yerine, iki protokolün sonuçta bir arada var olması muhtemeldir öngörülebilir gelecek için karşılıklı yarar sağlayan ilişkiler.

ملخص

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 يجب أن توفر بشكل أساسي طبقة أساسية مستقرة. وبالإضافة إلى السلامة الاقتصادية، فإن هذا يعني أيضًا تقليل المركزية ناقلات للهجمات ذات المكافأة العالية.

Özet

Polkadot ölçeklenebilir, heterojen bir çoklu zincirdir. Bu önceki blockchain uygulamalarından farklı olduğu anlamına gelir değişen tek bir zincir sağlamaya odaklanmış olan potansiyel uygulamalara göre genellik dereceleri, Polkadot kendisi hiçbir şekilde doğal bir uygulama işlevselliği sağlamak üzere tasarlanmıştır. Aksine, Polkadot ana kayayı sağlar Çok sayıda doğrulanabilir bilginin yer aldığı “aktarma zinciri”, küresel olarak tutarlı dinamik veri yapıları barındırılabilir yan yana. Bu veri yapılarına “paralelleştirilmiş” diyoruz özel bir ihtiyaç olmasa da zincirler veya parachainler doğası gereği blockchain olmaları. Başka bir deyişle, Polkadot, bir dizi bağımsız zincire (ör. Ethereum, Ethereum Classic, Namecoin ve Bitcoin) çok önemli iki nokta hariç: • Havuzlanmış güvenlik; • güven gerektirmeyen zincirler arası işlem yapılabilirlik. Bu noktalar, Polkadot öğesinin "ölçeklenebilir" olduğunu düşünmemizin nedenidir. Prensip olarak, Polkadot üzerinde konuşlandırılacak bir sorun büyük ölçüde paralelleştirilebilir (ölçeği genişletilebilir) çok sayıda parachain. Çünkü her birinin tüm yönleri parachain Polkadot ağının farklı bir bölümü tarafından paralel olarak yürütülebilir, sistemin bazı yetenekleri vardır ölçeklendirmek için. Polkadot oldukça basit bir parça sağlar 3aslında bir zincirdeki tokens'yi yok ederek başka bir zincirde tokens'yi oluşturmadan oluşan tek yönlü sabitlemenin aksine Orijinal tokens'yi kurtarmak için bunun tersini yapacak mekanizmaPOLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 4 karmaşıklığın çoğunu ara yazılım düzeyinde ele almayı bırakan altyapı. Bu, kalkınma riskini azaltmayı amaçlayan bilinçli bir karardır. Kısa sürede geliştirilecek gerekli yazılımlar ve güvenliği konusunda iyi düzeyde bir güven ile sağlamlık. 3.1. Polkadot Felsefesi. Polkadot gerekir üzerine oturulacak mutlak kaya gibi sağlam bir temel sağlar. bir sonraki mutabakat sistemi dalgasını oluşturun üretim kapasitesine sahip olgun tasarımlardan kaynaklanan risk spektrumu yeni oluşan fikirlere. Polkadot, güvenlik, izolasyon ve iletişim konusunda güçlü garantiler sunarak aşağıdakilere izin verebilir: bir dizi özellik arasından seçim yapmak için parachainler. Aslında, çeşitli deneysel blockchain'lerin mantıklı kabul edilebilecek özellikleri zorladığını öngörüyoruz bugün. muhafazakar görüyoruz benzer yüksek değerli zincirler Bitcoin veya Z-cash [20] daha düşük değerle birlikte mevcut “Tema zincirleri” (böyle pazarlama, çok eğlenceli) ve test ağları sıfır veya sıfıra yakın ücretlerle. Tamamen şifrelenmiş görüyoruz, "karanlık", birlikte çalışan konsorsiyum zincirleri - ve hatta son derece işlevsel ve açık zincirlere hizmet sağlamak Ethereum gibi olanlar gibi. Deneysel yeni görüyoruz Sübjektif zaman yüklü wasm gibi VM tabanlı zincirler zincir, zorlu bilgi işlem sorunlarını daha olgun Ethereum benzeri bir zincirden dış kaynak olarak sağlama aracı olarak kullanılıyor veya daha kısıtlı Bitcoin benzeri bir zincir. Zincir yükseltmelerini yönetmek için Polkadot doğası gereği muhtemelen dayalı bir tür yönetim yapısını desteklemek mevcut istikrarlı siyasi sistemlere ilişkindir ve Sarı Kağıt Konseyi'ne benzer iki meclisli bir yapıya sahiptir [24]. olarak nihai otorite, temel stake edilebilir token sahipleri "referandum" kontrolüne sahip olacaktır. Kullanıcıların düşüncelerini yansıtmak için Geliştirme ihtiyacı ama geliştiricilerin meşruiyet ihtiyacı, makul bir yönlendirmenin oluşmasını bekliyoruz bir “kullanıcı” komitesinin iki odası (aşağıdakilerden oluşur) validators teminatlı) ve bir “teknik” komite oluşturuldu büyük müşteri geliştiricileri ve ekosistem oyuncularından oluşan bir ekip.

token sahiplerinden oluşan bir grup nihai meşruiyeti koruyacak ve bu yapıyı geliştirmek, yeniden parametrelendirmek, değiştirmek veya feshetmek için bir süper çoğunluk oluşturacaktır; Nihai ihtiyaçtan şüphe etmeyin: Twain'in sözleriyle “Hükümetler ve bebek bezleri sık sık değiştirilmeli ve aynı sebep”. Yeniden parametrelendirmenin daha geniş bir konsensüs mekanizması içinde düzenlenmesi tipik olarak önemsiz olsa da, değiştirme ve genişletme gibi daha niteliksel değişiklikler büyük ihtimalle otomatik olmayan “yumuşak kararnameler” (ör. Bir blok numarasının kanonikleştirilmesi yoluyla ve hash resmi olarak yeni protokolü belirten bir belge) veya bir temel konsensüs mekanizmasının bulunmasını gerektirir. kendisinin herhangi bir yönünü tanımlayacak kadar zengin bir dil bunun değişmesi gerekebilir. İkincisi nihai bir amaçtır, ancak birincisinin seçilme olasılığı daha yüksektir Makul bir geliştirme zaman çizelgesini kolaylaştırmak. Polkadot'nin temel ilkeleri ve içinde yer aldığı kurallar Tüm tasarım kararlarını değerlendiriyoruz: Minimal: Polkadot mümkün olduğunca az işlevselliğe sahip olmalıdır. Basit: Hiçbir ek karmaşıklık mevcut olmamalıdır temel protokolde makul olarak olabileceğinden ara yazılıma yüklenmiş, aracılığıyla yerleştirildi parachain veya daha sonraki bir optimizasyonda tanıtıldı. Genel: gereksiz gereksinim yok, kısıtlama veya parachainlere sınırlama getirilmeli; Polkadot, fikir birliği sistemi geliştirme için optimize edilebilecek bir test ortamı olmalıdır. Uzantıların yer aldığı modeli mümkün olduğunca soyut hale getirmek. Sağlam: Polkadot temel olarak bir sağlamalıdır kararlı taban katmanı. Ekonomik sağlamlığın yanı sıra bu aynı zamanda merkezi olmayan yönetim anlamına da gelir. yüksek ödüllü saldırıların vektörleri.

المشاركة في Polkadot

هناك أربعة أدوار أساسية في صيانة Polkadot الشبكة: المتعاون والصياد والمرشح وvalidator. في أحد التطبيقات المحتملة لـ Polkadot، الدور الأخير يمكن تقسيمها فعليًا إلى دورين: validator الأساسي وضامن التوفر؛ تمت مناقشة هذا في القسم 6.5.3. جامع صياد المدققون (هذه المجموعة) المدققون (مجموعات أخرى) يوافق يصبح المراقبين التقارير سيئة السلوك ل يوفر كتلة المرشحين ل المرشح الشكل 1. التفاعل بين أربعة أدوار Polkadot. 4.1. المدققون. validator هو أعلى شحن و يساعد في إغلاق الكتل الجديدة على شبكة Polkadot. يتوقف دور validator على وجود رابطة عالية بما فيه الكفاية يتم إيداعها، على الرغم من أننا نسمح للأطراف المستعبدة الأخرى بذلك قم بترشيح واحد أو أكثر من validator لتمثيلهم وبصفتهم قد لا يكون هذا الجزء من سند validator مملوكًا بالضرورة لـ validator نفسه ولكن بالأحرى من قبل هؤلاء الترشيحات. يجب أن يقوم validator بتشغيل تطبيق عميل سلسلة الترحيل مع توفر عالي وعرض النطاق الترددي. عند كل كتلة يجب أن تكون العقدة جاهزة لقبول دور التصديق كتلة جديدة على المظلة المرشحة. هذه العملية يتضمن تلقي المرشح والتحقق من صحته وإعادة نشره كتل. إن الترشيح أمر حتمي ولكن لا يمكن التنبؤ به تقريبًا مقدمًا. نظرًا لأن validator لا يمكن ذلك ومن المتوقع بشكل معقول للحفاظ على متزامنة بالكامل قاعدة بيانات لجميع المظلات، من المتوقع أن يرشح validator مهمة ابتكار قاعدة بيانات جديدة مقترحة كتلة المظلة لطرف ثالث، والمعروفة باسم المجمع. بمجرد التصديق على جميع كتل المظلات الجديدة بشكل صحيح من خلال مجموعاتها الفرعية validator، validators يجب بعد ذلك التصديق على كتلة سلسلة التتابع نفسها. هذا ينطوي على تحديث حالة قوائم انتظار المعاملات (بشكل أساسي نقل البيانات من قائمة انتظار إخراج سلسلة Parachain إلى أخرى قائمة انتظار إدخال Parachain)، ومعالجة المعاملات مجموعة معاملات سلسلة الترحيل المعتمدة والتصديق على الكتلة النهائية، بما في ذلك تغييرات الباراشين النهائية.بولكادوت: رؤية لإطار عمل متعدد السلاسل غير متجانس المسودة 1 5 validator لا يقومون بواجبهم في التوصل إلى توافق في الآراء بموجب قواعد خوارزمية الإجماع التي اخترناها يعاقب. بالنسبة لحالات الفشل الأولية غير المقصودة، يتم ذلك حجز مكافأة validator. يؤدي الفشل المتكرر إلى تقليل سندات الضمان الخاصة بهم (من خلال الحرق). من المحتمل أن تكون الإجراءات الضارة مثل التوقيع المزدوج أو التآمر لتقديم كتلة غير صالحة يؤدي إلى خسارة السند بأكمله (الذي يتم حرقه جزئيًا ولكن يتم تقديمه في الغالب إلى المخبرين والفاعلين الصادقين). إلى حد ما، validators تشبه مجمعات التعدين من إثبات العمل الحالي blockchains. 4.2. الترشيحات. المرشح هو طرف صاحب مصلحة الذي يساهم في السند الضماني لـ validator. هم ليس لها دور إضافي سوى وضع رأس المال المخاطر وكما للإشارة إلى أنهم يثقون في validator معين (أو مجموعة منها) للتصرف بمسؤولية في صيانتها شبكة. ويحصلون على زيادة أو تخفيض تناسبي في ودائعهم وفقا لنمو السند الذي يساهمون. جنبا إلى جنب مع المتعاونين، التالي، المرشحون في بعض يشبه عمال المناجم في شبكات إثبات العمل (PoW) الحالية. 4.3. المقارنات. جامعو المعاملات (جامعو المعاملات باختصار) هي الأطراف التي تساعد validators في إنتاج صالحة كتل المظلة. إنهم يحافظون على "عقدة كاملة" لسلسلة باراشين معينة؛ وهذا يعني أنهم يحتفظون بكل ما هو ضروري المعلومات لتكون قادرة على تأليف كتل جديدة وتنفيذها المعاملات بنفس الطريقة التي يقوم بها القائمون بالتعدين على إثبات العمل (PoW) blockchains الحالي. في الظروف العادية هم سوف نقوم بجمع وتنفيذ المعاملات لإنشاء ملف مفتوح كتلة، وتوفيرها، جنبا إلى جنب مع المعرفة الصفرية إثبات، إلى واحد أو أكثر من validator المسؤولين حاليًا عن اقتراح كتلة المظلة. من المرجح أن تتغير الطبيعة الدقيقة للعلاقة بين المتعاونين والمرشحين وvalidators بمرور الوقت الوقت. في البداية، نتوقع أن يعمل المترجمون بشكل وثيق جدًا مع validators، نظرًا لأنه لن يكون هناك سوى عدد قليل (ربما سلسلة (سلاسل) واحدة فقط ذات حجم معاملات صغير. ال سيتضمن التنفيذ الأولي للعميل RPCs للسماح بـ عقدة ربط سلسلة Parachain لتزويد عقدة (سلسلة ترحيل) validator بشكل غير مشروط بسلسلة Parachain صالحة بشكل مثبت كتلة. كتكلفة الحفاظ على نسخة متزامنة من كل هذه المظلات تتزايد، ونتوقع أن نرى المزيد البنية التحتية الموجودة والتي ستساعد في فصل واجبات الأطراف المستقلة ذات الدوافع الاقتصادية. في نهاية المطاف، نتوقع أن نرى مجموعات من المتعاونين الذين يتنافسون عليها جمع معظم رسوم المعاملات. قد يتم التعاقد مع هؤلاء المجمعين لخدمة validator معينة على مدى فترة زمنية مقابل حصة مستمرة في عائدات المكافأة. وبدلاً من ذلك، يمكن للمجمعين "المستقلين" ببساطة إنشاء ملف يقدم السوق كتل باراشين صالحة مقابل حصة تنافسية من المكافأة تدفع على الفور. وبالمثل، فإن مجمعات الترشيح اللامركزية ستسمح بالتعددية المشاركون المستعبدين للتنسيق وتقاسم واجب أ validator. تضمن هذه القدرة على التجميع المشاركة المفتوحة مما يؤدي إلى نظام أكثر لامركزية. 4.4. الصيادين. على عكس الحزبين النشطين الآخرين، لا يرتبط الصيادون مباشرة بتأليف الكتلة عملية. بل هم "صائدو جوائز" مستقلون بدافع من مكافأة كبيرة. على وجه التحديد بسبب بوجود الصيادين، نتوقع أن حوادث سوء السلوك نادرًا ما تحدث، وعندما تحدث فقط بسبب كون الطرف المستعبد مهملاً بأمن المفتاح السري، وليس من خلال النوايا الخبيثة. يأتي الاسم من التكرار المتوقع للمكافأة، والحد الأدنى من متطلبات المشاركة وحجم المكافأة النهائية. يحصل الصيادون على أجرهم من خلال إثبات ذلك في الوقت المناسب تصرف طرف مستعبد واحد على الأقل بشكل غير قانوني. أعمال غير قانونية تتضمن التوقيع على كتلتين مع نفس الوالد المعتمد، أو، في حالة المظلات، المساعدة في التصديق على غير صالح كتلة. لمنع الإفراط في المكافأة أو التسوية و الاستخدام غير المشروع للمفتاح السري للجلسة، المكافأة الأساسية مقابل تقديم رسالة واحدة موقعة بشكل غير قانوني من validator هو الحد الأدنى. وتزداد هذه المكافأة بشكل مقارب أكثر يتم إثبات التوقيعات غير القانونية من validators الأخرى بشرط أن يكون ذلك بمثابة هجوم حقيقي. تم تعيين الخط المقارب بنسبة 66% بعد تأكيدنا الأمني الأساسي على الأقل ثلثا validators يتصرفون بشكل خيري. يشبه الصيادون إلى حد ما "العقد الكاملة" في أنظمة blockchain الحالية التي تحتاج إلى الموارد صغيرة نسبيًا والالتزام بوقت تشغيل مستقر وعرض النطاق الترددي ليس ضروريا. ويختلف الصيادون في ذلك بقدر ما يجب عليهم نشر سند صغير.يمنع هذا السند هجمات sybil من إضاعة وقت وحساب validators الموارد. يمكن سحبه على الفور، ربما لا أكثر من ما يعادل بضعة دولارات وربما يؤدي لجني مكافأة ضخمة من اكتشاف سوء التصرف validator.

Polkadot katılımı

Polkadot bakımında dört temel rol vardır ağ: derleyici, balıkçı, aday gösteren ve validator. içinde Polkadot'nin olası bir uygulaması, ikinci rol aslında iki role ayrılabilir: temel validator ve kullanılabilirlik garantörü; bu bölümde tartışılıyor 6.5.3. Harmanlayıcı Balıkçı Doğrulayıcılar (bu grup) Doğrulayıcılar (diğer gruplar) onaylıyor olur monitörler raporlar kötü davranış blok sağlar adaylar için Aday gösteren Şekil 1. Polkadot'nin dört rolü. 4.1. Doğrulayıcılar. validator en yüksek ücrettir ve Polkadot ağında yeni blokların kapatılmasına yardımcı olur. validator'nın rolü yeterince yüksek bir bağa bağlıdır diğer bağlı tarafların ödeme yapmasına izin vermemize rağmen yatırılıyor onlar adına hareket etmek üzere bir veya daha fazla validator aday gösterin ve validator tahvilinin bu tür bir kısmının mutlaka validator'ya ait olması gerekmeyebilir, bunun yerine bu kişilere ait olabilir aday gösterenler. Bir validator, yüksek kullanılabilirlik ve bant genişliğine sahip bir aktarma zinciri istemci uygulamasını çalıştırmalıdır. Her blokta düğüm onaylama rolünü kabul etmeye hazır olmalıdır aday gösterilen bir parachain üzerinde yeni bir blok. Bu süreç adayın alınmasını, doğrulanmasını ve yeniden yayınlanmasını içerir bloklar. Adaylık deterministiktir ancak çok önceden tahmin edilmesi neredeyse imkansızdır. validator yapamadığı için tam senkronizasyonu sürdürmesi makul olarak beklenebilir tüm parachain'lerin veri tabanına göre, validator'nin önerilen yeni bir zincir tasarlama görevini aday göstermesi bekleniyor Parachain bloğunu harmanlayıcı olarak bilinen üçüncü bir tarafa aktarır. Tüm yeni parachain blokları atanmış validator alt grupları tarafından uygun şekilde onaylandıktan sonra, validators daha sonra aktarma zinciri bloğunu kendisinin onaylaması gerekir. Bu şunları içerir: işlem kuyruklarının durumunun güncellenmesi (esasen verileri bir parachain'in çıktı kuyruğundan diğerine taşımak parachain'in giriş kuyruğu), işlemleri işleme Onaylanmış aktarma zinciri işlem seti ve onaylanması son parachain değişiklikleri de dahil olmak üzere son blok.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 5 validator fikir birliği bulma görevini yerine getirmiyor seçtiğimiz fikir birliği algoritmasının kurallarına göre cezalandırılır. Başlangıçtaki kasıtsız arızalar için bu, validator ödülünün durdurulması. Tekrarlanan arızalar güvenlik bağlarının azalmasına (yanma yoluyla) neden olur. Çift imzalama gibi muhtemelen kötü niyetli eylemler veya Geçersiz bir blok sağlamak için komplo kurmak, bağın tamamı (kısmen yanmış ancak çoğunlukla verilmiştir) muhbirlere ve dürüst aktörlere). Bir bakıma validator'ler madencilik havuzlarına benziyor mevcut PoW'un blockchains'si. 4.2. Aday gösterenler. Aday gösteren, hisse sahibi bir partidir validator'nin teminat tahviline katkıda bulunan kişi. onlar Risk sermayesi yerleştirmek dışında ek bir rolü yoktur ve belirli bir validator (veya bunların bakımında sorumlu bir şekilde hareket etmek ağ. Orantılı bir artış veya azalma alırlar tahvilin büyümesine göre mevduatlarında katkıda bulunurlar. Sıralayıcılarla birlikte aday gösterenler de bazı ülkelerde günümüz PoW ağlarındaki madencilere benzer bir his veriyor. 4.3. Harmanlayıcılar. İşlem harmanlayıcıları (kısaca harmanlayıcılar) validators'nin geçerli bilgiler üretmesine yardımcı olan taraflar mı? Parachain blokları. Belirli bir parachain için “tam düğüm” sağlarlar; gerekli olan her şeyi muhafaza ettikleri anlamına gelir Yeni bloklar yazabilmek ve yürütebilmek için gerekli bilgiler işlemler, madencilerin mevcut PoW blockchains üzerinde yaptıklarıyla hemen hemen aynı şekilde yapılır. Normal şartlarda onlar mühürsüz bir kayıt oluşturmak için işlemleri toplayacak ve yürütecek sıfır bilgiyle birlikte engelleyin ve sağlayın şu anda sorumlu olan bir veya daha fazla validators'ye kanıt bir parachain bloğu öneriyor. Düzenleyenler, aday gösterenler ve validator'ler arasındaki ilişkinin kesin niteliği muhtemelen değişecek zaman. Başlangıçta, derleyicilerin çok yakın çalışmasını bekliyoruz validators ile, çünkü yalnızca birkaç tane olacak (belki küçük işlem hacmine sahip yalnızca bir) parachain(ler). İlk istemci uygulaması, RPC'leri içerecektir. Parachain harmanlayıcı düğümü, bir (aktarma zinciri) validator düğümüne koşulsuz olarak geçerli olduğu kanıtlanabilen bir parachain sağlamak için Blok. Senkronize edilmiş bir sürümünü sürdürmenin maliyeti olarak bu tür parachainlerin tümü artıyor, ek görmeyi bekliyoruz ayırmaya yardımcı olacak altyapı mevcuttur. Bağımsız, ekonomik motivasyona sahip taraflara yönelik görevler. Sonunda, rekabet eden harmanlayıcı havuzlarını görmeyi bekliyoruz. En fazla işlem ücretini toplayın. Bu tür düzenleyicilerle, ödül gelirlerinden sürekli bir pay almak için belirli bir süre boyunca belirli validator'lere hizmet vermek üzere sözleşme yapılabilir. Alternatif olarak, "serbest" derleyiciler basitçe bir Piyasa, anında ödenecek ödülün rekabetçi bir payı karşılığında geçerli parachain blokları sunuyor. Benzer şekilde, merkezi olmayan aday havuzları birden fazla adaya izin verecektir. katılımcıları koordine etmek ve görevini paylaşmak üzere bir araya getirdi. validator. Bu havuzlama yeteneği açık katılımı garanti eder daha merkezi olmayan bir sisteme yol açmaktadır. 4.4. Balıkçılar. Diğer iki aktif partinin aksine, balıkçılar blok yazarlığıyla doğrudan ilişkili değil süreç. Daha ziyade bağımsız “ödül avcıları”dırlar büyük bir tek seferlik ödülle motive edildi. Tam olarak nedeniyle Balıkçıların varlığı nedeniyle, uygunsuz davranış olaylarının nadiren meydana gelmesini bekleriz ve bunlar yalnızca balıkçılar nedeniyle gerçekleştiğinde bağlı tarafın gizli anahtar güvenliği konusunda dikkatsiz olması, kötü niyetle değil. İsim geliyor Beklenen ödül sıklığından, katılım için gereken minimum gereksinimlerden ve nihai ödül boyutundan. Balıkçılar ödüllerini zamanında kanıtlayarak alıyorlar en az bir bağlı taraf yasa dışı hareket etti. Yasa dışı eylemler her biri aynı onaylı ebeveynle iki blok imzalamayı veya parachain durumunda geçersiz bir anlaşmanın onaylanmasına yardımcı olmayı içerir Blok. Aşırı ödüllendirmeyi veya taviz vermeyi önlemek ve bir oturumun gizli anahtarının yasa dışı kullanımı, temel ödül tek bir validator'nin yasa dışı olarak imzalanmış mesajını sağlamak minimum. Bu ödül asimptotik olarak arttıkça artar. diğer validator'lerden gelen yasa dışı imzaları doğrulamak gerçek bir saldırıyı ima ediyor. Asimptot ayarlandı en azından temel güvenlik iddiamızı takiben %66 oranında validator'ların üçte ikisi iyiliksever davranıyor. Balıkçılar bir bakıma “tam düğümlere” benzerler. kaynakların ihtiyaç duyduğu günümüz blockchain sistemleri nispeten küçüktür ve istikrarlı çalışma süresi taahhüdü ve bant genişliği gerekli değildir. Balıkçılar bu konuda farklılık gösteriyor küçük bir tahvil yatırmaları gerektiği kadar.Bu bağ engelliyor validators'nin zamanını ve hesaplamasını boşa harcayan sybil saldırıları kaynaklar. Hemen geri çekilebilir, muhtemelen hayır birkaç dolara eşdeğerden daha fazla ve yol açabilir yaramaz bir davranışı fark ederek büyük bir ödül elde etmek 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 قابلية التشغيل البيني "سلسلة مظلات افتراضية" آمنة بشكل معقول بين الشبكتين، على الرغم من أنه جهد كبير بجدول زمني غير مؤكد، ومن المحتمل جدًا مما يتطلب تعاون الجهات المعنية في ذلك شبكة.

Tasarıma Genel Bakış

Bu bölüm, konuyla ilgili kısa bir genel bakış sunmayı amaçlamaktadır. bir bütün olarak sistem. Konunun daha kapsamlı bir araştırması Sistemi takip eden bölümde verilmiştir. 5.1. Konsensüs. Aktarma zincirinde Polkadot şunu başarır: karşılıklı olarak kabul edilen geçerli bir dizi karar üzerinde düşük düzeyde fikir birliği modern bir eşzamansız Bizans hataya dayanıklı (BFT) algoritması aracılığıyla bloklar. Algoritma ilham alacak basit Tendermint [11] ve çok daha fazlası ile HoneyBadgerBFT [14] dahil. İkincisi bir sağlar keyfi bir şekilde etkin ve hataya dayanıklı bir fikir birliği çoğunlukla zararsız otoriteler veya validators kümesi göz önüne alındığında kusurlu ağ altyapısı. Yetki kanıtı (PoA) tarzı bir ağ için yalnızca bu yeterli olacaktır, ancak Polkadot olduğu düşünülüyor tamamen açık ve halka açık bir ağ olarak da dağıtılabilir belirli bir kuruluş veya güvenilir olmayan durum sürdürmek için gerekli olan yetkidir. Bu nedenle bir ihtiyacımız var validators kümesini belirleme ve teşvik etme araçları dürüst olmaları. Bunun için PoS tabanlı seçimi kullanıyoruz Kriterler. 5.2. Bahsi Kanıtlamak. Ağın olduğunu varsayıyoruz ne kadar "bahis" olduğunu ölçmek için bazı araçlara sahip olacak herhangi bir hesabın olması. Karşılaştırma kolaylığı için önceden var olan sistemlere ölçü birimi diyeceğiz “tokens”. Ne yazık ki bu terim ideal olmaktan uzaktır. pek çok neden var, en azından bunun basit bir skaler olması bir hesapla ilişkili değer, hiçbir kavram yoktur bireysellik. validator'lerin nadiren (en fazla) seçildiğini hayal ediyoruz günde bir kez ama belki üç ayda bir kadar nadiren), Aday Hisse Kanıtı (NPoS) şeması aracılığıyla. Teşvik, oranlı bir tahsis yoluyla gerçekleşebilir.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 6 Röle zincir Doğrulayıcı sürüsü (her biri kendi rengine göre renklendirilmiştir) belirlenmiş parachain) İşlem (tarafından gönderildi dış aktör) Parachain köprü Sanal parachain (örneğin Ethereum) Parachain Parachain kuyruklar ve G/Ç Yayılan işlemler Aday gönderimini engelle 2. sıra Röle zinciri Parachain topluluğu Hesap Gelen işlem Giden işlem Zincirler arası işlemler (validators tarafından yönetilmektedir) Harmanlayıcı Yayılan blok Balıkçı Şekil 2. Polkadot sisteminin özet şeması. Bu, harmanlayıcıların kullanıcı işlemlerini toplayıp yaymasının yanı sıra blok adaylarını balıkçılara ve validator'lere yaydığını gösteriyor. Aynı zamanda bir hesabın kendi parachain'inden gerçekleştirilen bir işlemi aktarma zinciri aracılığıyla nasıl yayınlayabileceğini gösterir ve oradaki bir hesaba yapılan bir işlem olarak yorumlanabileceği başka bir parachain'e. token temel genişletmeden gelen fonlar (%100'e kadar) yılda, ancak daha büyük ihtimalle %10 civarındadır. toplanan işlem ücretleri. Tüm token sahipler olduğundan, para tabanı genişlemesi genellikle enflasyona yol açsa da katılımda adil bir fırsata sahip olacak, hiçbir tokensahibinin değerinin düşmesine maruz kalması gerekmeyecek almaktan mutlu olmaları koşuluyla, zaman içinde holdingleri Konsensüs mekanizmasındaki rolü. Belirli bir oran tokens sayısı staking süreci için hedeflenecektir; the etkili token temel genişletme şu şekilde ayarlanacaktır: Bu hedefe ulaşmak için piyasaya dayalı bir mekanizma. Doğrulayıcılar büyük ölçüde çıkarlarına bağlı; çıkıyor validators'nin tahvilleri, validators'nin görevleri sona erdikten uzun süre sonra (belki yaklaşık 3 ay) yerinde kalır. Bu uzun tahvil tasfiye süresi gelecekteki uygunsuz davranışlara izin verir zincirin periyodik kontrol noktasına kadar cezalandırılır. Kötü davranış, cezanın azaltılması gibi cezalarla sonuçlanır. Ödül veya kasıtlı olarak taviz veren durumlarda ağın bütünlüğünün bozulması, validator bağlantısının bir kısmını veya tamamını kaybetmesi diğer validator'lere, muhbirlere veya paydaşlara pay bir bütün olarak (yanma yoluyla). Örneğin, bir validator bir çatalın her iki dalını da onaylamaya çalışan kişi (bazen "kısa menzilli" saldırı olarak bilinir) tanımlanabilir ve ikinci şekilde cezalandırılır. Uzun menzilli "tehlikede olmayan" saldırılar4, basit bir "kontrol noktası" mandalı aracılığıyla atlatılır ve bu, zincirin tehlikeli bir şekilde yeniden düzenlenmesini engeller. özellikle zincir derinliği. İstemcilerin yeni senkronize edilmesini sağlamak için yanlış zincire aldanamazlar, düzenli olarak “Sert çatallanmalar” meydana gelecektir (en fazla validators'nin tahvil tasfiyesi), son kontrol noktası bloğunu hashes istemcilere sabit kodlayan. Bu, ayak izini azaltan başka bir "sonlu zincir uzunluğu" ölçüsüyle iyi bir uyum sağlar veya oluşum bloğunun periyodik olarak sıfırlanması. 5.3. Parachain'ler ve Harmanlayıcılar. Her parachain alır aktarma zincirine benzer güvenlik düzenlemeleri: the Parachain'lerin başlıkları röle zinciri bloğunun içinde mühürlenmiştir Onayın ardından yeniden düzenlemenin veya "çifte harcamanın" mümkün olmamasını sağlamak. Bu, Bitcoin'nin yan zincirleri ve birleştirme madenciliği tarafından sunulana benzer bir güvenlik garantisidir. Ancak Polkadot aynı zamanda parachainlerin durum geçişlerinin geçerli olduğuna dair güçlü garantiler de sağlar. Bu validator kümesinin kriptografik olarak rastgele alt kümelere bölünmesi yoluyla gerçekleşir; başına bir alt küme parachain'de alt kümeler blok başına potansiyel olarak farklılık gösterir. Bu kurulum genellikle parachainlerin blok sürelerinin artacağını ima eder en az röle zincirininki kadar uzun olmalıdır. spesifik bölümlendirmenin kapsam dışında olduğunu belirleme araçları 4Böyle bir saldırı, düşmanın başlangıç bloğundan itibaren tamamen yeni bir tarih zinciri oluşturduğu yerdir. Bir kontrol yoluyla dengede göreceli olarak önemsiz bir paya sahip olsalar da, diğer tüm paylara göre kendi paylarına düşen payı kademeli olarak artırabilirler Paydaşlar, alternatif tarihlerinin tek aktif katılımcılarıdır. Yaratılışta hiçbir içsel fiziksel sınırlama bulunmadığından (oldukça gerçek hesaplama enerjisinin harcanması gereken PoW'un aksine), gerçek zincirden daha uzun bir zincir oluşturabilirler. nispeten kısa bir zaman aralığına sahiptir ve ağın kanonik durumunu devralarak onu potansiyel olarak en uzun ve en iyi hale getirir.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 7 bu belgenin ancak muhtemelen aşağıdakilere dayalı olması muhtemeldir: RanDAO [19] benzeri bir taahhüt-açıklama çerçevesi veya her parachain'in önceki bloklarından birleştirilmiş verileri kullanın kriptografik olarak güvenli bir hash altında. validator'lerin bu tür alt kümelerinin aşağıdakileri sağlaması gerekir: Geçerliliği garanti edilen parachain blok adayı (açık) tahvillere el konulmasının acısı). Geçerlilik iki etrafında döner önemli noktalar; ilk olarak özünde geçerli olduğu - yani tüm durum geçişleri aslına sadık kalınarak gerçekleştirildi ve hepsi Referans verilen harici veriler (yani işlemler) dahil edilmek üzere geçerlidir. İkincisi, kendi dışsal olan herhangi bir verinin harici işlemler gibi adayın yeterince yüksek kullanılabilirliğe sahip olması, böylece katılımcıların indirin ve bloğu manuel olarak çalıştırın.5 Doğrulayıcılar yalnızca hiçbir harici "işlem" verisi içermeyen "boş" bir blok sağlayabilir, ancak bunu yapmaları halinde daha düşük bir ödül alma riskiyle karşı karşıya kalabilirler. Birlikte çalışıyorlar derleyiciler (bireyler) ile bir parachain dedikodu protokolü İşlemleri bloklar halinde toplayan ve bloğun ebeveyninin geçerli bir alt öğesi olduğuna dair etkileşimli olmayan, sıfır bilgili bir kanıt sağlayan (ve herhangi bir işlemi üstlenen) sıkıntıları için ücretler). Kendilerini belirlemek parachain protokollerine bırakılmıştır. Spam önleme araçları: "bilgi işlem kaynağı ölçümü" veya "işlem ücreti" gibi temel bir kavram yoktur röle zinciri tarafından empoze edilir. Aktarma zinciri protokolü tarafından da bu konuda doğrudan bir yaptırım bulunmamaktadır (gerçi Paydaşların benimsemeyi seçmesi pek olası değil düzgün bir mekanizma sağlamayan bir parachain). Bu, zincirlerin farklı olma ihtimaline açık bir işarettir. Ethereum, ör. çok daha basit bir ücret modeline veya henüz önerilmemiş başka bir spam önleme modeline sahip Bitcoin benzeri bir zincir. Polkadot'in aktarma zincirinin kendisi muhtemelen bir Ethereum-benzeri hesaplar ve durum zinciri, muhtemelen bir EVMtürevi. Röle zinciri düğümlerinin gerekli olacağından önemli miktarda başka işlem ve işlem hacmi yapmak büyük işlem ücretleri yoluyla kısmen en aza indirilecek ve araştırma modellerimizin gerektirmesi durumunda bir blok boyutu sınırı. 5.4. Zincirler Arası İletişim. Polkadot'nin kritik son bileşeni zincirler arası iletişimdir. O zamandan beri Parachain'ler aralarında bir tür bilgi kanalına sahip olabilir, biz de Polkadot a olarak düşünmemize izin veriyoruz. ölçeklenebilir çoklu zincir. Polkadot durumunda iletişim olabildiğince basittir: parachain (bu zincirin mantığına göre) yapabilir Bir işlemin ikinci bir parachain'e gönderilmesini sağlamak veya potansiyel olarak röle zinciri. Harici işlemler gibi blockchains üretiminde tamamen eşzamansızdırlar ve onların herhangi bir şeyi geri döndürme konusunda içsel bir yetenekleri yoktur. bir tür bilginin kökenine geri dönmesi. Hedef: alır önceki veriler bloğun validators. Hesap şu gönderiyi alır: giriş kaldırıldı giriş Merkle tree Hesap gönderi gönderir: giriş yerleştirildi çıkış Merkle tree hedef için paraşütle atlama çıkış Kaynak: paylaşımlar sonraki bloktaki veriler validators posta kanıtının saklandığı yer Parachain çıkışı Merkle ağaç yönlendirilmiş referans yerleştirildi hedef parachain'de giriş Merkle tree giriş Şekil 3. Temel şematik gösterim gönderilenler için yönlendirmenin ana bölümleri işlemler (“gönderiler”). Minimum uygulama karmaşıklığını sağlamak için minimum risk ve asgari düz ceket arasında gelecek Parachain mimarilerinde bu zincirler arası işlemler standart harici imzalı işlemlerden etkili bir şekilde ayırt edilemez. İşlemin bir parachain tanımlama yeteneği sağlayan bir kaynak segmenti vardır ve isteğe bağlı boyutta olabilecek bir adres. Bitcoin ve Ethereum gibi yaygın mevcut sistemlerin aksine, zincirler arası işlemler herhangi bir türde ücret "ödemesi" ile birlikte gelmez; Bu tür herhangi bir ödemenin kaynak ve hedef parachainler üzerindeki müzakere mantığı yoluyla yönetilmesi gerekir. Bunun için önerilene benzer bir sistem Ethereum'in Serenity sürümü [7] basit bir yöntem olabilir böyle bir zincirler arası kaynak ödemesini yönetme zamanı gelince başkalarının da öne çıkabileceğini varsayıyoruz. Zincirler arası işlemler basit bir çözüm kullanılarak çözülür sağlamak için Merkle tree temeline dayalı kuyruklama mekanizması sadakat. Röle zinciri bakımcılarının görevi işlemleri bir parachain'in çıkış kuyruğunda taşıyın hedef parachain'in giriş kuyruğuna. aktarılan işlemlere aktarma zincirinde başvurulur, ancak bunlar ilgili değildiray-chain işlemlerinin kendisi. Bir parachain'in başka bir parachain'e spam göndermesini önlemek için işlemler, bir işlemin gönderilebilmesi için gereklidir hedefin giriş kuyruğunun çok büyük olmaması önceki bloğun bitiş zamanı. Giriş ise Blok işleme sonrasında sıra çok büyükse, bu durumda "doymuş" olarak kabul edilir ve hiçbir işlem şu adrese yönlendirilemez: tekrar altına düşene kadar sonraki bloklar içinde Sınır. Bu kuyruklar aktarma zincirinde yönetilir Parachainlerin birbirlerinin doygunluğunu belirlemesine izin vermek durum; bu şekilde bir işlemi yayınlamak için başarısız bir girişim Durmuş bir varış noktasına eşzamanlı olarak rapor edilebilir. (Geri dönüş yolu bulunmadığından ikincil bir işlemin bu nedenle başarısız olması durumunda geri bildirim yapılamamaktadır.) ilk arayana ve diğer bazı kurtarma yollarına gerçekleşmesi gerekirdi.) 5.5. Polkadot ve Ethereum. Ethereum'nin Turing bütünlüğü nedeniyle, Polkadot ve Ethereum'nin birlikte çalışabilmesi için bol miktarda fırsat olmasını bekliyoruz en azından kolayca çıkarılabilecek bazı güvenlik sınırları dahilinde. Kısaca, işlemlerin şu andan itibaren gerçekleşmesini öngörüyoruz: Polkadot, validators tarafından imzalanıp daha sonra beslenebilir 5Böyle bir görev validator'ler arasında paylaşılabilir veya yoğun biçimde bağlı validator'ler kümesinin atanmış görevi haline gelebilir. kullanılabilirlik garantörleri.

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 8 Ethereum burada yorumlanıp yürürlüğe konulabilirler bir işlem yönlendirme sözleşmesi. Diğer yönde ise özel olarak biçimlendirilmiş günlüklerin (olayların) kullanımını öngörüyoruz belirli bir mesajın iletilmesi gerektiğinin hızlı bir şekilde doğrulanmasına olanak tanıyan bir "kaçış sözleşmesi"nden geliyor. 5.5.1. Polkadot - Ethereum arası. Bir seçim yoluyla BFT fikir birliği mekanizması, validator'lerin oluşturduğu bir Onay oylamasıyla belirlenen paydaşlar grubu mekanizma ile güvenli bir fikir birliğine varabiliriz. nadiren değişen ve mütevazı sayıda validators. Toplam 144 validators olan bir sistemde blok süresi 4 saniye ve 900 blokluk sonluluk (kötü amaçlı yazılımlara izin verir) Çift oy verme gibi davranışların bildirilmesi, cezalandırılması ve onarılmış), bir bloğun geçerliliği makul bir şekilde 97 kadar az imzayla (144'ün üçte ikisi artı bir) ve ardından hiçbir sorgulamanın yapılmadığı 60 dakikalık doğrulama süresiyle kanıtlanmış sayılır. Ethereum bir "zorla girme sözleşmesi" düzenleyebilir 144 imza sahibini koruyabilir ve onlar tarafından kontrol edilebilir onlar. Eliptik eğri dijital imza (ECDSA) kurtarma işlemi EVM altında yalnızca 3.000 gaz gerektirdiğinden ve muhtemelen doğrulamanın yalnızca bir tarihte gerçekleşmesini isteriz. validators'lik süper çoğunluk (tam oybirliği yerine), bir talimatın onaylandığını doğrulayan Ethereum tutarındaki taban maliyet Polkadot ağından gelen gazın 300.000'den fazla olmayacağı, yani gazın yalnızca %6'sı olacağı gerektiği şekilde doğrulandı toplam blok gaz limiti 5,5M'dir. validators sayısını artırmak (sorunlarla başa çıkmak için gerekli olacak şekilde) düzinelerce zincir) bu maliyeti kaçınılmaz olarak artırıyor ancak Ethereum'nin işlem bant genişliğinin teknoloji olgunlaştıkça ve zaman içinde büyümesi genel olarak bekleniyor altyapı iyileşiyor. Olmadığı gerçeğiyle birlikte tüm validator'lerin dahil olması gerekir (ör. yalnızca en yüksek stake edilen validator'ler böyle bir görev için çağrılabilir) Bu mekanizmanın sınırları oldukça geniştir. Bu tür validator'lerin günlük rotasyonunu varsayarsak (ki bu Oldukça ihtiyatlı (haftalık, hatta aylık kabul edilebilir), o zaman bakım ağının maliyeti bu Ethereum-yönlendirme köprüsünün sayısı 540.000 civarında olacaktır günlük gaz veya mevcut gaz fiyatlarıyla yıllık 45 dolar. Köprü üzerinden tek başına iletilen temel bir işlemin maliyeti yaklaşık 0,11 dolar; ek sözleşme hesaplamasının maliyeti olacaktır elbette daha fazlası. İşlemleri tamponlayarak ve paketleyerek birlikte, izinsiz girme yetkilendirme maliyetleri kolaylıkla karşılanabilir. paylaşılarak işlem başına maliyetin önemli ölçüde azaltılması; yönlendirmeden önce 20 işlem gerekiyorsa, o zaman temel bir işlemin iletilmesinin maliyeti yaklaşık 0,01 dolar. Bu çoklu imza sözleşme modeline ilginç ve daha ucuz bir alternatif, çok taraflı sahiplik semantiğine ulaşmak için eşik imzaların kullanılması olacaktır. ECDSA için eşik imza şemaları hesaplama açısından pahalıdır, diğer planlar için olanlar Schnorr imzaları gibi imzalar oldukça makul. Ethereum bunu sağlayacak ilkelleri tanıtmayı planlıyor Yaklaşan Metropolis hardfork'unda kullanımı ucuz planlar. Eğer böyle bir yöntem kullanılabilseydi, gaz maliyetleri Polkadot işlemini Ethereum'ye iletmek için ağ önemli ölçüde sıfıra yakın bir seviyeye düşecek doğrulama için temel maliyetlerin ötesinde genel giderler imza ve temel işlemin yürütülmesi. Bu modelde, Polkadot'nin validator düğümleri mesajları imzalamaktan başka çok az şey yapmak. İşlemlerin gerçekte Ethereum ağına yönlendirilmesini sağlamak için, validator'lardan herhangi birinin kendisinin de burada ikamet edeceğini varsayalım Ethereum ağı veya daha büyük ihtimalle o küçük ödüller mesajı ileten ilk aktöre sunulacaktır. ağa (ödül önemsiz bir şekilde ödenebilir) işlem yaratıcısı). 5.5.2. Ethereum - Polkadot arası. İşlemlerin gerçekleşmesi Ethereum'den Polkadot'ye iletilen basit günlük kavramını kullanır. Bir Ethereum sözleşmesi belirli bir Polkadot parachain'ine bir işlem göndermek istediğinde, sadece özel bir "ayrılma sözleşmesi" imzalaması yeterli. Ayrılma sözleşmesi olabilecek her türlü ödemeyi alacaktır. gerekli olmalı ve bir Merkle kanıtı ve karşılık gelen bloğun başlığının geçerli olduğuna dair bir iddia yoluyla varlığının kanıtlanabilmesi için bir kayıt talimatı yayınlayın ve kanonik. Son iki koşuldan geçerlilik belki de kanıtlamak en basiti. Prensip olarak tek şartkanıta ihtiyaç duyan her Polkadot düğüm için (yani atanmış validator düğümleri), standart bir Ethereum düğümünün tamamen senkronize edilmiş bir örneğini çalıştıracak şekilde. Ne yazık ki, bu oldukça ağır bir bağımlılıktır. bir daha hafif yöntem, basit bir kanıt kullanmak olacaktır. başlık yalnızca sağlanarak doğru şekilde değerlendirildi Ethereum'nin düzgün bir şekilde yürütülmesi için gereken durum denemesinin bir kısmı bloktaki işlemleri yapın ve günlüklerin (blok makbuzunda bulunan) geçerli olup olmadığını kontrol edin. Böyle “SPV benzeri”6 Kanıtlar henüz önemli miktarda bilgi gerektirebilir; uygun bir şekilde, genellikle bunlara ihtiyaç duyulmaz hepsi: Polkadot içindeki bir tahvil sistemi tahvillere izin verir üçüncü tarafların başlıklarını kaybetme riskiyle karşı karşıya kalmaları başka bir üçüncü tarafın (“balıkçı” gibi, bkz. 6.2.3) başlığın geçersiz olduğuna dair bir kanıt sunması durumunda tahvil (özellikle devlet kökü veya makbuz köklerinin sahtekar olduğu). Ethereum gibi sonlandırılmayan bir PoW ağında, kanonikliğin kesin olarak kanıtlanması imkansızdır. Bu sorunu çözmek için her türlü veriye güvenmeye çalışan uygulamalar Zincire bağlı neden-sonuç ilişkileri için bir dizi “onay” bekleyin veya bağımlı işlem belli bir seviyeye gelinceye kadar bekleyin. Zincir içindeki belirli derinlik. Ethereum tarihinde bu derinlik, bilinen ağ sorunu olmayan en az değerli işlemler için 1 bloktan, olduğu gibi 1200 bloğa kadar değişir borsalar için ilk Frontier sürümü sırasındaki durum. Sabit “Homestead” ağında bu rakam Çoğu borsa için 120 blok ve muhtemelen bunu alırız benzer bir parametre. Yani biz yapabilir hayal et bizim Polkadot tarafı Ethereumarayüzünün bazı basit işlevlere sahip olmasını sağlamak: Ethereum ağından yeni bir başlık kabul edin ve PoW'u doğrulayın; belirli bir günlük, yeterli derinliğe (ve ileriye doğru) sahip bir başlık için Ethereum tarafı koparma sözleşmesi tarafından yayınlandı Polkadot içindeki ilgili mesajı) ve son olarak daha önce kabul edilmiş ancak kabul edilmiş kanıtları kabul edebilmek henüz etkinleştirilmemiş başlık, geçersiz bir makbuz kökü içeriyor. Aslında Ethereum başlık verilerinin kendisini almak için (ve herhangi bir SPV kanıtı veya geçerlilik/kanoniklik reddi) Polkadot ağı, yönlendirme için bir teşvik 6SPV, Bitcoin'de Basitleştirilmiş Ödeme Doğrulamasına atıfta bulunur ve müşterilerin yalnızca tutarken işlemleri doğrulaması için bir yöntem açıklar. En uzun PoW zincirinin tüm blok başlıklarının bir kopyası.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 9 veriye ihtiyaç var. Bu bir ödeme kadar basit olabilir (Ethereum tarafında toplanan ücretlerden finanse edilir) ödendi başlığı olan yararlı bir bloğu iletebilen herkese geçerlidir. Doğrulayıcılardan son birkaç bin bloğa ilişkin bilgileri saklamaları istenecektir. bazı protokole özgü araçlarla veya üzerinde tutulan bir sözleşme aracılığıyla çatalları yönetebilme röle zinciri. 5.6. Polkadot ve Bitcoin. Bitcoin karşılıklı çalışma Polkadot için ilginç bir zorluk sunuyor: sözde “İki yönlü bağlantı” faydalı bir altyapı parçası olabilir her iki ağın da tarafında olmak. Ancak nedeniyle böyle bir sabitleyicinin güvenli bir şekilde sağlanması koşuluyla Bitcoin sınırlamaları önemsiz olmayan bir girişim. Bir işlemin teslim edilmesi Bitcoin ila Polkadot arası prensipte Ethereum için olana benzer bir işlemle yapılabilir; bir “çıkış adresi” Polkadot validator'ler tarafından bir şekilde kontrol ediliyor olabilir aktarılan token'leri (ve onlarla birlikte gönderilen verileri) alın. SPV kanıtları teşvikli oracle'ler tarafından sağlanabilir ve, bir onay süresiyle birlikte verilen bir ödül işlemi ima eden kanonik olmayan blokların tanımlanması “çifte harcandı”. Daha sonra sahip olunan tüm token'ler Bu durumda "kaçış adresi" prensipte daha sonra dağıtılmak üzere aynı validator'lar tarafından kontrol edilecektir. Ancak sorun, birikintilerin dönen bir validator setinden nasıl güvenli bir şekilde kontrol edilebileceğidir. aksine Ethereum dayalı olarak keyfi kararlar alabilen imza kombinasyonları üzerine Bitcoin büyük ölçüde çoğu müşteri yalnızca maksimum 3 tarafla çoklu imza işlemlerini kabul ettiğinden daha sınırlıdır. Bunu 36'ya, hatta istenildiği gibi binlerce kişiye çıkarmak mevcut protokol uyarınca imkansızdır. Seçeneklerden biri, etkinleştirmek için Bitcoin protokolünü değiştirmektir. bu tür işlevsellik, ancak buna "sert çatallar" da denir Bitcoin dünyasında son girişimlere göre değerlendirme yapmak zor. Olasılıklardan biri eşik imzaların kullanılmasıdır. tek olarak tanımlanabilir bir kamuya izin veren kriptografik şemalar birden fazla gizli "parça" tarafından etkin bir şekilde kontrol edilebilecek anahtar, geçerli bir imza oluşturmak için bunların bir kısmı veya tamamı kullanılmalıdır. Maalesef eşik imzaları uyumlu Bitcoin'nin ECDSA'sı hesaplama açısından pahalıdır polinom karmaşıklığı yaratır ve oluşturur. Bunun gibi diğer planlar a Schnorr imzaları çok daha düşük maliyetler sağlar, ancak Bitcoin'ya dahil edilebilecekleri zaman çizelgesi protokol belirsizdir. Mevduatın nihai güvenliği, bir dizi bağlı validators, diğer bir seçenek de Çoklu imza anahtar sahiplerini yalnızca büyük ölçüde azaltın toplam validators'nin bağlı alt kümesi öyle ki eşik imzalar mümkün hale gelir (veya en kötü ihtimalle Bitcoin'nin yerel imzası) çoklu imza mümkündür). Bu elbette azaltır validator'lerin yasa dışı davranması durumunda tazminatlardan düşülebilecek toplam teminat tutarı, ancak bu zarif bir bozulmadır, sadece bir üst sınır belirler arasında güvenli bir şekilde çalıştırılabilecek fon miktarı iki ağ (ya da aslında bir saldırı durumunda kayıp yüzdesi) validator'lerden başarılı). Bu nedenle, makul derecede güvenli bir Bitcoin birlikte çalışabilirlik “sanal parachain” yerleştirmenin gerçekçi olmadığına inanıyoruz. iki ağ arasında, yine de belirsiz bir zaman çizelgesine sahip önemli bir çaba ve büyük olasılıkla paydaşların işbirliğini gerektiren ağ.

البروتوكول بالتفصيل

يمكن تقسيم البروتوكول تقريبًا إلى ثلاثة الأجزاء: آلية التوافق، واجهة الباراشين وتوجيه المعاملات بين السلاسل. 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.

Ayrıntılı Protokol

Protokol kabaca üçe ayrılabilir Parçalar: fikir birliği mekanizması, parachain arayüzü ve zincirler arası işlem yönlendirme. 6.1. Röle zinciri Operasyon. röle zinciri irade büyük ihtimalle Ethereum'a genel olarak benzeyen bir zincir olabilir, çünkü hesaba durum eşleme adresi ile durum tabanlıdır bilgi, esas olarak bakiyeler ve (tekrar oynatmayı önlemek için) işlem sayacı. Hesapları buraya yerleştirmek tek bir amaca hizmet eder: Kimliğin sahip olduğu muhasebeyi sağlamak sistemdeki payın miktarı.7 Ancak dikkate değer farklılıklar olacaktır: • Sözleşmeler işlemler yoluyla dağıtılamaz; Aktarma zincirindeki uygulama işlevselliğinden kaçınma arzusundan dolayı, sözleşmelerin kamuya açık hale getirilmesini desteklemek. • Bilgi işlem kaynağı kullanımı (“gaz”) hesaba katılmaz; kamusal kullanıma açık tek işlevler olduğundan gaz muhasebesinin arkasındaki mantık düzeltilecek artık tutmuyor. Bu nedenle sabit bir ücret uygulanacaktır. her durumda daha fazla performansa olanak tanır yapılması gerekebilecek dinamik kod yürütme ve daha basit bir işlem formatı. • Listelenen sözleşmeler için otomatik yürütmeye ve ağ mesajı çıktılarına izin veren özel işlevsellik desteklenir. Aktarma zincirinin bir VM'ye sahip olması durumunda ve bu EVM temel alınarak, maksimum basitliği sağlamak için bir dizi değişiklik yapılacaktır. Muhtemelen bir dizi yerleşik sözleşmeye sahiptir (şu adrestekilere benzer) platforma özel izin vermek için Ethereum içindeki 1-4 adresleri) Bir fikir birliği sözleşmesi de dahil olmak üzere yönetilmesi gereken görevler, validator sözleşmesi ve parachain sözleşmesi. EVM değilse, WebAssembly [2] (wasm) arka ucu en olası alternatiftir; bu durumda genel yapı benzer olurdu ama gerek olmazdı Wasm'ın geçerli bir hedef olduğu yerleşik sözleşmeler için olgunlaşmamış diller yerine genel amaçlı diller için ve EVM için sınırlı diller. Mevcut Ethereum protokolünden diğer olası sapmalar da oldukça mümkündür; örneğin, protokolün basitleştirilmesi. Aynı blok içerisinde çakışmayan işlemlerin paralel olarak yürütülmesine olanak tanıyan işlem-makbuz formatı, Serenity değişiklik serisi için önerildiği gibi. Pek olası olmasa da, Serenity benzeri bir şeyin olması mümkündür. "saf" zincir, aktarma zinciri olarak konuşlandırılabilir ve staking token gibi şeyleri yönetmek için özel bir sözleşme bunu temel bir parçası haline getirmek yerine dengeler zincirin protokolü. Şu anda bunun pek olası olmadığını düşünüyoruz yeterince mükemmel bir protokol basitleştirmesi sunacak içerdiği ek karmaşıklık ve belirsizliğe değer onu geliştirmede. 7Sistemin genel güvenliğinden belirli bir sahibinin sorumlu olduğu tutarı temsil etmenin bir yolu olarak, bu hisse hesapları kaçınılmaz olarak bazı ekonomik değerleri kodlar. Ancak şunu da anlamak gerekir ki, bu tür değerlerin kullanılmasına yönelik bir niyet söz konusu değildir. herhangi bir şekilde gerçek dünya mal ve hizmetleriyle takas amacıyla token'lerin şunlara benzetilemeyeceği belirtilmelidir: para birimidir ve bu nedenle aktarma zinciri, uygulamalara ilişkin nihilist felsefesini korur.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 10 Konsensüs mekanizmasını, validator setini, doğrulama mekanizmasını ve parachainleri yönetmek için gereken bir dizi küçük işlevsellik vardır. Bunlar yekpare bir protokol altında birlikte uygulanabilir. Bununla birlikte, modülerliğin göstergesi olarak bunları aktarma zincirinin "sözleşmeleri" olarak tanımlıyoruz. Bu gerekir nesneler oldukları anlamına gelecek şekilde alınmalıdır (anlamında) nesne yönelimli programlama) aktarma zincirinin konsensüs mekanizması tarafından yönetilir, ancak bu zorunlu değildir. EVM benzeri işlem kodlarındaki programlar olarak tanımlanırlar veya aracılığıyla ayrı ayrı adreslenebilir olsalar bile hesap sistemi. 6.2. Bahis Sözleşmesi. Bu sözleşme validator kümesini korur. Şunları yönetir: • şu anda hangi hesapların validators olduğu; • kısaca validators olmaya müsait olanlar uyarı; • hangi hesaplara hisse adaylığı yerleştirildi bir validator; • staking hacmi, kabul edilebilir ödeme oranları ve adresleri ve kısa vadeli (oturum) kimliklerini içeren her birinin özellikleri. Bir hesabın üye olma arzusunu kaydetmesine olanak tanır. bağlı validator (gereksinimleriyle birlikte), bir kimliğe aday olmak ve önceden mevcut bağlı validators için bu durumdan çıkma isteklerini kaydetmek için. Aynı zamanda doğrulama ve kanonikleştirme mekanizması için makinenin kendisini içerir. 6.2.1. Stake-token Likidite. Genellikle arzu edilir toplam staking tokens'nin mümkün olduğu kadar çoğuna sahip olmak beri ağ bakım operasyonlarında görevlendirildi bu, ağ güvenliğini doğrudan staking token'nin genel "piyasa değerine" bağlar. Bu kolayca yapılabilir para biriminin şişirilmesi ve gelirlerin katılımcılara validators olarak dağıtılması yoluyla teşvik edilebilir. Ancak bunu yapmak bir sorun yaratır: token ise Staking Sözleşmesinde indirim cezasıyla kilitlenmişse, önemli bir kısmı nasıl yeterince kalabilir? Fiyat keşfine izin vermek için sıvı mı? Buna bir yanıt, temel hisseli token üzerinde değiştirilebilir token'leri güvence altına alan basit bir türev sözleşmesine izin vermektir. Bunu güvene dayalı olmayan bir şekilde düzenlemek zordur. Ayrıca, bu türev token'ler, farklı Avro Bölgesi hükümetlerinin tahvillerinin takas edilebilir olmaması nedeniyle aynı nedenle eşit olarak ele alınamaz: dayanak varlığın başarısızlığa uğraması ve yeniden oluşması ihtimalidir değersiz. Avro Bölgesi hükümetleri ile varsayılan. validator-bahisli tokens ile validator olabilir kötü niyetli davranın ve cezalandırılın. İlkelerimize sadık kalarak en basit çözümü seçiyoruz: token'ların tümü stake edilmeyecektir. Bu şu anlama gelir token'lerin bir kısmı (belki %20) zorunlu olarak sıvı kalacaktır. Bu, güvenlik açısından kusurlu olsa da, güvenlik açısından temel bir fark yaratması pek olası değildir. ağın güvenliği; Tahvillere el konulmasından kaynaklanabilecek tazminatların yüzde 80'i hala yapılabilecek %100 staking "mükemmel durum" ile karşılaştırıldığında. Stacked ve likit token'ler arasındaki oran, ters açık artırma mekanizması yoluyla oldukça basit bir şekilde hedeflenebilir. Temel olarak, token sahipleri validator olmakla ilgileniyorlar her biri staking sözleşmesine şunu belirten bir teklif gönderir: almaları gereken minimum ödeme oranı parçası. Her oturumun başında (oturumlar düzenli olarak, belki saatte bir kez kadar sıklıkta meydana gelir) validator yuva her isteğe göre doldurulacak validator'nın bahis miktarı ve ödeme oranı. Olası bir algoritma çünkü bu, en düşük teklifleri verenleri almak olacaktır. hedeflenen toplam hisseden daha yüksek olmayan bir hisseyi temsil eder yuva sayısına bölünür ve bu miktarın yarısının alt sınırından daha az olamaz. Yuvalar doldurulamıyorsa, alt sınır, tatmin etmek için bazı faktörlerle tekrar tekrar azaltılabilir. 6.2.2. Aday gösterme. Güvenle aday gösterilmek mümkündür staking tokens olanları aktif bir validator'ye bağlayarak onlara veririz validator'nin görevlerinin sorumluluğu. Eserlerin aday gösterilmesi onay-oylama sistemi aracılığıyla. Her aday aday staking sözleşmesine bir talimat gönderebilir altında bir veya daha fazla validator kimliği ifade eden sorumluluklarını emanet etmeye hazırdırlar. Her oturumda adayların tahvilleri dağıtılır. bir veya daha fazla validator ile temsil edilir. Dağıtma algoritması, eşdeğer toplamın validators kümesi için optimize eder tahviller. Aday gösterenlerin tahvilleri validator a'nın etkin sorumluluğu altına girer.ya faiz kazanırsın ya da acı çekersin buna göre ceza indirimi. 6.2.3. Senetlere El Koyma/Yakma. Belirli validator davranışları, teminatlarının cezai olarak azaltılmasıyla sonuçlanır. Eğer Tahvilin izin verilen minimum seviyenin altına düşürülmesi, oturum zamanından önce sonlandırıldı ve başka bir oturum başlatıldı. Cezalandırılabilir validator uygunsuz davranışların kapsamlı olmayan listesi şunları içerir: • Sağlayamayan bir parachain grubunun parçası olmak parachain bloğunun geçerliliği konusunda fikir birliği; • geçersiz bir belgenin geçerliliği için aktif olarak imza atmak parachain bloğu; • çıkış yüklerini önceden sağlayamama uygun olarak oylandı; • fikir birliği süreci sırasında hareketsizlik; • rakip çatallardaki aktarma zinciri bloklarının doğrulanması. Bazı hatalı davranış vakaları ağın bütünlüğünü tehdit eder (geçersiz parachain bloklarının imzalanması ve bir çatalın birden fazla tarafının doğrulanması gibi) ve dolayısıyla bağın tamamen azaltılması yoluyla etkili bir şekilde sürgüne yol açar. içinde diğer, daha az ciddi durumlar (örn. fikir birliğinde hareketsizlik) süreç) veya suçun kesin olarak dağıtılamadığı durumlarda (etkisiz bir grubun parçası olmak), küçük bir kısım Bunun yerine teminat para cezasına çarptırılabilir. İkinci durumda, bu kötü amaçlı olduğundan emin olmak için alt grup karmaşasıyla iyi çalışır düğümler, ikincil olarak hasar görmüş hayırsever düğümlerden önemli ölçüde daha fazla kayba uğrar. Bazı durumlarda (örneğin, çoklu çatal doğrulaması ve geçersiz alt blok imzalama) validator'ler sürekli doğrulama nedeniyle birbirlerinin hatalı davranışlarını kendileri kolayca tespit edemiyorlar Her bir parachain bloğunun kaldırılması çok zorlu bir görev olacaktır. Burada dışındaki tarafların desteğinin sağlanması gerekmektedir. Bu tür hatalı davranışları doğrulamak ve raporlamak için doğrulama süreci. Taraflar bu tür bir faaliyeti bildirdikleri için bir ödül alırlar; "Balıkçı" terimi, bu durumun pek mümkün olmamasından kaynaklanıyor böyle bir ödülden. Bu vakalar genellikle çok ciddi olduğundan, el konulan tahvilden her türlü ödülün kolayca ödenebileceğini öngörüyoruz. Genelde yanmayı dengelemeyi tercih ederiz (yani hiçbir şeye indirgeme) yerine yeniden tahsis ile toptan yeniden tahsis girişiminde bulunuldu. Bunun etkisi var

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 11 token'nin genel değerini artırarak, ağ belirli bir düzeyden ziyade genel olarak bir dereceye kadar keşifte yer alan taraf. Bu esas olarak bir güvenlik amaçlıdır Mekanizma: İlgili büyük miktarlar, hepsi aşırı ve akut davranış teşviklerine yol açabilir tek bir hedefe bahşedilmiştir. Genel olarak, ödülün ağ için doğrulamayı değerli kılacak kadar büyük olması, ancak bir doğrulamanın karşılanmasının maliyetini karşılayacak kadar da büyük olmaması önemlidir. iyi finanse edilmiş, iyi organize edilmiş “endüstriyel düzeyde” suç Kötü davranışlara zorlamak için bazı şanssız validator'ya hack saldırısı. Bu şekilde, talep edilen tutarın genellikle hatalı validator'nin doğrudan bağından daha büyük, öyle ki yaramazlık yapmaktan ve ödül için kendini ihbar etmekten kaynaklanan sapkın teşvikler. Bu durumla açıkça mücadele edilebilir olmak için asgari doğrudan tahvil şartı aracılığıyla validator veya dolaylı olarak aday gösterenleri, yatırılmış küçük tahvilleri olan validator'ların büyük bir teşvikinin olmadığı konusunda eğiterek iyi davranmak. 6.3. Parachain Kaydı. Her parachain şu şekilde tanımlanır: bu kayıt defteri. Nispeten basit bir veritabanı benzeri yapıdır ve hem statik hem de dinamik bilgileri tutar. her zincir. Statik bilgiler zincir indeksini (basit bir tamsayı), doğrulama protokolü kimliğiyle birlikte bir farklı sınıfları birbirinden ayırmanın bir yolu doğru doğrulama algoritmasının olabilmesi için parachain geçerli bir aday öne sürmekle görevli validators tarafından yönetiliyor. İlk kavram kanıtı yerleştirmeye odaklanacaktır. yeni doğrulama algoritmalarını istemcilerin kendilerine aktarır ve her seferinde protokolün sert bir şekilde çatallanmasını gerektirir. ek zincir sınıfı eklendi. Sonuçta yine de doğrulama algoritmasını belirtmek mümkün olabilir Müşterilerin kullanabileceği kadar titiz ve etkili bir yol yeni parachain'lerle etkili bir şekilde çalışabilmektedir. sert çatal. Bunun olası bir yolu şunu belirtmek olacaktır: köklü bir parachain doğrulama algoritması, WebAssembly gibi yerel olarak derlenmiş, platformdan bağımsız bir dil. Belirlemek için ek araştırma gereklidir bunun gerçekten mümkün olup olmadığı, ancak eğer öyleyse, bununla birlikte sert çatalları ortadan kaldırmanın muazzam avantajı kesinlikle. Dinamik bilgi, işlem yönlendirme sisteminin küresel anlaşmaya sahip olması gereken yönlerini içerir. Parachain'in giriş kuyruğu olarak (bölüm 6.6'da açıklanmıştır). Kayıt defteri yalnızca parachain'lerin eklenmesini sağlayabilir tam referandum oylaması yoluyla; bu yönetilebilir dahili olarak ancak daha büyük olasılıkla harici bir yere yerleştirilir kapsamında yeniden kullanımı kolaylaştırmak amacıyla referandum sözleşmesi daha genel yönetişim bileşenleri. Parametreler oylama gereklilikleri (örneğin gerekli yeter çoğunluk, çoğunluk ek zincirlerin ve diğerlerinin kaydı için gerekli) daha az resmi sistem yükseltmeleri bir “ana anayasa” ama muhtemelen oldukça geleneksel bir anayasayı takip edecekler. en azından başlangıçta yol. Kesin formülasyon bitti mevcut çalışmanın kapsamı, ancak ör. toplam sistemin üçte birinden fazlasıyla geçecek üçte ikilik bir çoğunluk Hisselerin olumlu oylanması mantıklı bir başlangıç noktası olabilir. Ek işlemler arasında parachainlerin askıya alınması ve kaldırılması yer alır. Uzaklaştırma umarım hiçbir zaman olmaz olur, ancak en azından bir koruma olacak şekilde tasarlanmıştır Parachain'in doğrulama sisteminde bazı zorlu problemler var. Bunun olabileceği en bariz örnek validators'nin üzerinde anlaşamamasına yol açan uygulamalar arasında fikir birliği açısından kritik bir farka ihtiyaç duyulmaktadır. geçerlilik veya bloklar. Doğrulayıcıların kullanması teşvik edilecektir. birden fazla istemci uygulamasını gerçekleştirebilmeleri için tahvillere el konulmadan önce böyle bir sorunu tespit etmek. Askıya alma acil bir tedbir olduğundan, dinamik validator-oylamanın himayesi altında referandumdan daha fazlası. Yeniden etkinleştirme her ikisi de mümkün olabilir validators'den veya referandumdan. Parachainlerin tamamen ortadan kaldırılması ancak referandumdan sonra gerekli olacak düzenli bir geçişe izin vermek için önemli miktarda ödemesiz süre ya bağımsız bir zincir ya da başka bir zincirin parçası olmak fikir birliği sistemi. Ek süre muhtemelen Ayların sırasına göre düzenlenir ve farklı sıralamaların yapılabilmesi için parachain kayıt defterinde her zincir bazında düzenlenmesi muhtemeldir. Parachain'ler duruma göre farklı ödemesiz sürelerden yararlanabilirler onların ihtiyacı. 6.4. Sızdırmazlık Rölesi Blokları. Sızdırmazlık, özünde, kanonikleştirme sürecine; yani temel bir veri hangisini dönüştürorijinali temelde tekil ve anlamlı bir şeye dönüştürür. PoW zinciri altında, mühürleme aslında madencilikle eşanlamlıdır. Bizim durumumuzda, validators'den bir belgenin geçerliliği, kullanılabilirliği ve kanonikliğine ilişkin imzalı ifadelerin toplanmasını içerir. belirli röle zinciri bloğu ve parachain blokları temsil ediyor. Temel BFT fikir birliği algoritmasının mekaniği mevcut çalışmanın kapsamı dışındadır. Yapacağız bunun yerine bunu varsayan bir ilkel kullanarak tanımlayın. fikir birliği yaratan devlet makinesi. Sonuçta bekliyoruz bir dizi umut verici BFT fikir birliğinden ilham almak çekirdekteki algoritmalar; Tangaora [9] (BFT çeşidi) Raft [16]), Tendermint [11] ve HoneyBadgerBFT [14]. Algoritmanın paralel olarak birden fazla parachain üzerinde anlaşmaya varması gerekecek, bu da alışılagelmiş olandan farklı olacaktır. blockchain fikir birliği mekanizmaları. Bir kez olduğunu varsayıyoruz fikir birliğine varıldığında fikir birliğini kaydedebiliriz herhangi biri tarafından sağlanabilecek reddedilemez bir kanıtla Katılımcılar buna. Ayrıca hatalı davranışı da varsayıyoruz. protokol dahilinde genellikle küçük bir miktara indirgenebilir en aza indirmek için yaramazlık yapan katılımcıları içeren grup cezayı verirken ikincil hasar.8 İmzalı ifadelerimizin şeklini alan kanıt, röle zinciri bloğunun başlığına birlikte yerleştirilir aktarma zincirinin durum kökü ve işlem deneme kökü başta olmak üzere bazı diğer alanlarla birlikte.

sızdırmazlık süreç alır yer altında bir bekar fikir birliği yaratan mekanizma adresleme ikisi de the röle zincirinin bloğu ve parachainlerin blokları aktarıcının içeriğinin bir kısmı: parachain'ler alt grupları tarafından ayrı ayrı "taahhüt edilmez" ve daha sonra harmanlanmaz daha sonra. Bu, aktarma zinciri için daha karmaşık bir süreçle sonuçlanır, ancak gecikmeyi en aza indirerek ve tüm sistemin fikir birliğini tek bir aşamada tamamlamamıza olanak tanır. oldukça karmaşık veri kullanılabilirliği gereksinimleri için aşağıdaki yönlendirme işlemi için faydalıdır. 8Tendermint BFT ve orijinal Slasher gibi mevcut PoS tabanlı BFT fikir birliği şemaları bu iddiaları karşılamaktadır.

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 12 Her katılımcının fikir birliği makinesinin durumu basit (2 boyutlu) bir tablo olarak modellenebilir. Her katılımcının (validator) formda bir dizi bilgisi vardır. Her bir parachain blok adayı ve aktarma zinciri blok adayı ile ilgili olarak diğer katılımcıların imzalı beyanlarının (“oyları”). Bilgi seti iki parçadan oluşmaktadır veri sayısı: Kullanılabilirlik: var bu validator sahip olmak çıkış bu bloktan işlem sonrası bilgiler Aşağıdaki blokta parachain adaylarını doğru şekilde doğrulayabiliyorlar mı? Oy verebilirler 1(bilinen) veya 0 (henüz bilinmiyor). Bir kez onlar 1 oy, benzer şekilde oy vermeye kararlılar bu sürecin geri kalanı. Daha sonra geçerli olmayan oylar buna saygı duymak cezanın gerekçesidir. Geçerlilik: parachain bloğu geçerli mi ve hepsi geçerli mi? harici referanslı veriler (ör. işlemler) müsait mi? Bu yalnızca oy verdikleri parachain'e atanan validator'ler için geçerlidir. 1 (geçerli), -1 (geçersiz) veya 0 şeklinde oy verebilirler. (henüz bilinmiyor). Sıfır dışında oy verdiklerinde, geri kalan süre boyunca bu şekilde oy kullanmaya kararlıyız süreç. Daha sonra buna saygı göstermeyen oylar ceza gerekçesidir. Tüm validator'ler oy vermelidir; Yukarıdaki kurallara uygun olarak oylar yeniden gönderilebilir. ilerlemesi Konsensüs, paralel olarak gerçekleşen her bir parachain üzerinde birden fazla standart BFT konsensüs algoritması olarak modellenebilir. Bunlar potansiyel olarak göreceli olarak engellendiğinden kötü niyetli aktörlerin küçük bir azınlığı yoğunlaşıyor tek bir parachain grubu için genel fikir birliği mevcuttur En kötü senaryoyu sınırlayan bir geri durdurma noktası oluşturun yalnızca bir veya daha fazla geçersiz parachain bloğuna kilitlenme (ve Sorumlulara bir dizi ceza). Bireysel blokların geçerliliği için temel kurallar (toplam validators kümesinin bir bütün olarak elde edilmesine olanak sağlar) benzersiz parachain adayı olma konusunda fikir birliği kanonik röleden referans alınacak): • validator üyelerinin en az üçte ikisinin olumlu oy kullanması ve hiçbirinin olumsuz oy kullanmaması gerekir; • çıkış kuyruğu bilgilerinin kullanılabilirliği konusunda üçte birden fazla validator olumlu oy kullanmalıdır. Geçerliliğe ilişkin en az bir olumlu ve en az bir olumsuz oy olması halinde istisnai bir durum yaratılır ve validator'lerden oluşan grubun tamamı karar vermek için oy kullanmalı kötü niyetli taraflar varsa veya kazara bir durum varsa çatal. Geçerli ve geçersiz oyların dışında üçüncü tür oylar izin veriliyor, her ikisine de oy vermeye eşdeğer, yani Düğümün çelişkili görüşleri var. Bunun nedeni şunlar olabilir: düğümün sahibi birden fazla uygulamayı çalıştırıyor katılmıyorum, bu da protokolde olası bir belirsizliğe işaret ediyor. Tüm oylar tam validator kümesinden sayıldıktan sonra, eğer kaybedilen görüşün en azından küçük bir oranı vardır ( parametrelendirilebilir; en fazla yarısı, belki de önemli ölçüde daha az) kazanan görüşün oylarının, o zaman olduğu varsayılır kazara bir parachain çatalı olursa, parachain otomatik olarak konsensüs sürecinden askıya alınır. Aksi takdirde bunun kötü niyetli bir davranış olduğunu varsayarız ve cezalandırırız. muhalif görüşe oy veren azınlık. Sonuç, aşağıdakileri gösteren bir dizi imzadır: kanoniklik. Röle zinciri bloğu daha sonra kapatılabilir ve bir sonraki bloğun mühürlenmesi süreci başladı. 6.5. Sızdırmazlık Röle Bloklarına yönelik iyileştirmeler. iken bu sızdırmazlık yöntemi sistemin çalışması konusunda güçlü garantiler verir, çok iyi ölçeklenmez çünkü her parachain'in anahtar bilgisinin kendine ait olması gerekir kullanılabilirlik, tüm validator'lerin üçte birinden fazlası tarafından garanti edilir. Bu, her validator'nin sorumluluk ayak izinin olduğu anlamına gelir daha fazla zincir eklendikçe büyür. Açık fikir birliği ağlarında veri kullanılabilirliği özünde çözülmemiş bir sorun olduğundan, validator düğümlerine yerleştirilen yükü azaltmanın yolları vardır. Basit bir çözüm, validators'nin omuz vermesi gerektiğini fark etmektir. Veri kullanılabilirliği sorumluluğu kendilerine ait olduğundan, verileri kendilerinin saklaması, iletmesi veya çoğaltması gerekmez. Muhtemelen ilişkili (ya da hatta tam olarak) ikincil veri siloları aynı) bu verileri derleyen derleyiciler şunları yönetebilir: validator'lerin faiz/gelirlerinin bir kısmını ödeme olarak sunarak kullanılabilirliği garanti etme görevi. Ancak bu, bir miktar orta düzeyde ölçeklenebilirlik satın alsa da, yine de altta yatan soruna yardımcı olmuyor; o zamandan beri daha fazla zincir eklemek genel olarak ek validator gerektirecektir; devam eden ağ kaynağı tüketimi (özellikle bant genişliği açısından) karesi ile birlikte artar. thezincirler uzun vadede savunulamaz bir özelliktir. Eninde sonunda kafamızı vurmaya devam edeceğiz şunu belirten temel sınırlamaya karşı: Güvenli olarak kabul edilebilecek bir fikir birliği ağı, devam eden bant genişliği gereksinimleri toplam mertebesindedir validators çarpı toplam giriş bilgisi. Bunun nedeni güvenilmeyen bir ağın, veri depolama görevini birçok düğüme düzgün bir şekilde dağıtamaması fazlasıyla dağıtılabilir işleme görevi dışında. 6.5.1. Gecikme ile tanışın. Bunu yumuşatmanın bir yolu Kural, aciliyet kavramını gevşetmektir. validators'nin %33+1 validators'nin kullanılabilirlik için oy vermesini hemen değil, yalnızca eninde sonunda zorunlu kılarak, üstel veri yayılımından daha iyi yararlanabilir ve veri alışverişindeki zirve noktaların dengelenmesine yardımcı olabiliriz. Makul bir eşitlik (kanıtlanmamış olsa da) şunlar olabilir: (1) gecikme = katılımcılar × zincirler Mevcut modelde sistemin boyutu ölçekleniyor İşlemenin yapılmasını sağlamak için zincir sayısıyla dağıtılmış; her zincir en az bir validator gerektireceğinden ve kullanılabilirlik kanıtını sabit bir değere sabitledik oranı validators ise katılımcılar da benzer şekilde büyür zincir sayısı ile. Sonuç olarak: (2) gecikme = boyut2 Bu, sistem büyüdükçe gerekli bant genişliğinin ve kullanılabilirliğe kadar olan gecikmenin tüm ağ genelinde bilindiği anlamına gelir. numara olarak da nitelendirilebilecek ağ kesinlikten önceki blok sayısı karesiyle birlikte artar. bu önemli bir büyüme faktörüdür ve önemli bir engel teşkil edebilir ve bizi “düz olmayan” paradigmalara zorlayabilir birkaç “Polkadotes”i bir hiyerarşi halinde oluşturmak gibi direklerin bir aktarma zinciri ağacı aracılığıyla çok seviyeli yönlendirilmesi için.

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 13 6.5.2. Halkın Katılımı. Bir olası yön daha sürece halkın katılımını sağlamaktır. Mikro şikayet sistemi. Balıkçılara benzer şekilde, iddia eden validator'leri denetleyen harici taraflar olabilir kullanılabilirlik. Görevleri bu tür bir uygunluğu gösteremeyen birini bulmaktır. Bunu yaparken onlar diğer validator'lere mikro şikayette bulunabilir. PoW veya Sybil saldırısını azaltmak için hisseli tahvil kullanılabilir bu da sistemi büyük ölçüde işe yaramaz hale getirecektir. 6.5.3. Kullanılabilirlik Garantörleri. Son bir rota şu olacaktır: ikinci bir bağlı validator kümesini "kullanılabilirlik" olarak aday gösterin garantörler”. Bunlar normal validator'lerde olduğu gibi bağlanır ve hatta aynı kümeden bile alınabilir. (eğer öyleyse, en azından oturum başına, uzun vadeli bir süre boyunca seçileceklerdir). Normal validator'lerin aksine, onlar Parachain'ler arasında geçiş yapmazdım ama bunun yerine Tüm önemli zincirler arası verilerin kullanılabilirliğini doğrulamak için tek bir grup oluşturun. Bunun katılımcılar ve zincirler arasındaki denkliği gevşetme avantajı vardır. Esas olarak zincirler büyür (orijinal zincir validator seti ile birlikte), oysa katılımcılar ve özellikle veri kullanılabilirliği vasiyetinde yer alanlar en azından alt doğrusal kalabilirler ve muhtemelen sabit. 6.5.4. Harmanlayıcı Tercihleri. Bunun önemli bir yönü Sistemin amacı sağlıklı seçim yapılmasını sağlamaktır. herhangi bir parachain'de blokları oluşturan harmanlayıcılar. eğer bir tek bir harmanlayıcı bir parachain'e hakim oldu, ardından bazı saldırılar oldu eksikliği olasılığı nedeniyle daha uygulanabilir hale gelir. dış verilerin mevcudiyeti daha az belirgin olacaktır. Bir seçenek parachain bloklarını yapay olarak ağırlıklandırmaktır. çok çeşitli derleyicileri tercih etmek için sözde rastgele bir mekanizma. İlk etapta şunu isteriz: validators'nin desteklediği fikir birliği mekanizmasının bir parçası olarak Parachain blok adaylarının “daha ağır” olduğu belirlendi. Benzer şekilde, validators'yi şunu yapmaya teşvik etmeliyiz: bulabilecekleri en ağır bloğu önerin; bu olabilir ödüllerinin bir kısmını adaylarının ağırlığına orantılı hale getirerek yapılır. Harmanlayıcılara makul bir adalet sağlanmasını sağlamak adaylarının kazanan olarak seçilme şansı Adayın fikir birliği içinde olması durumunda, belirli bir ağırlığı belirleriz. Parachain blok adayı, her bir harmanlayıcıya bağlı rastgele bir fonksiyon üzerinde belirlenir. Örneğin, alarak harmanlayıcının adresi arasındaki XOR mesafe ölçüsü ve bazı kriptografik olarak güvenli sahte rastgele numaralar oluşturulan bloğun noktasına yakın olarak belirlenir (kavramsal bir “kazanan bilet”). Bu, her birine etkili bir şekilde verir harmanlayıcı (veya daha spesifik olarak her harmanlayıcının adresi) aday bloğunun "kazanması" için rastgele şans diğerleri. Tek bir harmanlayıcının kazanan bilete yakın bir adresi "madencilik" yapmasının ve böylece her bloğun favorisi olsaydı, harmanlayıcının adresine bir miktar atalet eklerdik. Bu onları istemek kadar basit olabilir adreste temel miktarda para bulunması. bir daha Zarif yaklaşım, yakınlığa ağırlık vermek olacaktır. park edilen para miktarıyla bilet kazanma söz konusu adres. Modelleme henüz yapılmamışken, bu mekanizmanın çok fazla olanak sağlaması oldukça mümkündür. Küçük paydaşların derleyici olarak katkıda bulunmaları. 6.5.5. Aşırı Kilolu Bloklar. Bir validator kümesinin güvenliği ihlal edilirse, bir blok oluşturabilir ve önerebilirler. geçerlidir, yürütülmesi aşırı miktarda zaman alır ve doğrulayın. Bu bir validator grubunun yapabileceği bir sorundur. makul bir şekilde çok uzun zaman alan bir blok oluşturur Kısa yola izin veren belirli bir bilgi parçası zaten bilinmiyorsa, örneğin; büyük çarpanlara ayırma birinci sınıf. Eğer tek bir derleyici bu bilgiyi biliyorsa, o zaman kendilerininkini alma konusunda açık bir avantaja sahip olacaklar diğerleri eski bloğu işlemekle meşgul olduğu sürece adaylar kabul edildi. Bu bloklara fazla kilolu diyoruz. validator'lerin bu blokları göndermesine ve doğrulamasına karşı koruma, büyük ölçüde aşağıdakilerle aynı kisvenin altında kalır: geçersiz bloklar, ancak ek bir uyarıyla: Çünkü bir bloğun yürütülmesi için geçen süre (ve dolayısıyla durumu aşırı kilo) subjektiftir, oylamanın nihai sonucu Kötü davranışlar esasen üç kampa ayrılacaktır. Bir olasılık bloğun kesinlikle aşırı kilolu olmamasıdır. bu durumda üçte ikiden fazlası yapabileceklerini beyan ediyor bloğu belirli bir limit dahilinde yürütün (örneğin, bloklar arasında izin verilen toplam sürenin %50'si). Bir diğeri ise blok d'dirkesinlikle fazla kilolu - eğer daha fazlaysa bu olurdu üçte ikisi bloğu yürütemediklerini beyan ediyor söz konusu limit dahilinde. Son bir olasılık oldukça eşit validators arasında fikir ayrılığı. Bu durumda şunları yapabiliriz: orantılı bir ceza uygulamayı seçin. validators'nin ne zaman olabileceklerini tahmin edebilmelerini sağlamak için Aşırı ağırlıklı bir blok önerirken, her blok için kendi performanslarına ilişkin bilgi yayınlamalarını talep etmek mantıklı olabilir. Yeterli bir süre boyunca, bu onların işlem hızlarının profilini çıkarmalarına olanak sağlamalıdır onları yargılayacak akranlarına göre. 6.5.6. Harmanlayıcı Sigortası. validators için bir sorun kaldı: PoW ağlarından farklı olarak, bir harmanlayıcının bilgilerini kontrol etmek için Geçerlilik için bloğun içindeki işlemleri gerçekten yürütmeleri gerekir. Kötü niyetli harmanlayıcılar validator'lere geçersiz veya aşırı ağırlıklı bloklar besleyerek onların sıkıntı yaşamasına neden olabilir (boşa harcama) kaynakları) ve potansiyel olarak önemli bir fırsat maliyeti talep etmektedir. Bunu azaltmak için basit bir strateji öneriyoruz. validators'nin bir parçası. İlk olarak parachain blok adayları gönderildi validators'ye geçiş zinciri hesabından imza atılmalıdır fonlarla; değilse validator düşmelidir hemen. İkinci olarak, bu tür adaylar, aşağıdakilerin bir kombinasyonu (örneğin çarpma) yoluyla öncelik sırasına konmalıdır: belirli bir sınıra kadar hesaptaki fon miktarı, derleyicinin geçmişte başarılı bir şekilde önerdiği önceki blokların sayısı (önceki bloklardan bahsetmeye bile gerek yok) cezalar) ve kazanmaya yakınlık faktörü daha önce tartışıldığı gibi bilet. Kapak aynı olmalı davada validator'ye ödenen cezai tazminat olarak geçersiz bir blok gönderiyorlar. Düzenleyicileri geçersiz veya fazla kilolu blok adaylarını validators'ye göndermekten caydırmak için herhangi bir validator Bir sonraki bloğa, hatalı davranış iddiasında bulunan ve hatalı davranan toplayıcının hesabındaki fonların bir kısmının veya tamamının transfer edilmesi sonucunu doğuran kusurlu bloğu içeren bir işlem yerleştirir mağdur validator adına hesap verin. Bu tür işlemler, harmanlayıcının işlem yapamayacağını garantilemek için diğer işlemleri önden çalıştırır. cezadan önce fonları kaldırın. miktarı Hasar olarak aktarılan fonlar henüz dinamik bir parametredir

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 14 modellenecek ancak neden olunan kederin düzeyini yansıtacak şekilde muhtemelen validator blok ödülünün bir oranı olacaktır. Kime Kötü niyetli validator'lerin, toplayıcıların fonlarına keyfi olarak el koymasını önlemek için, düzenleyici, validator'nin kararına, karşılığında rastgele seçilmiş validator'lardan oluşan bir jüri ile itiraz edebilir. küçük bir depozito yatırmak için. validator'nin lehine karar verirlerse depozito onlar tarafından tüketilir. Değilse, depozito iade edilir ve validator para cezasına çarptırılır (çünkü validator çok daha kubbeli bir konumda, ceza kesilecek muhtemelen oldukça ağır olacaktır). 6.6. Zincirler arası İşlem Yönlendirme. Zincirler arası işlem yönlendirme temel bakımlardan biridir Aktarma zincirinin görevleri ve validator'leri. Bu Gönderilen bir işlemin (genellikle basitçe "göndermek" olarak kısaltılır) istenen çıktı olmaktan nasıl çıkacağını yöneten mantık bir kaynak parachain'den başka bir hedef parachain'in herhangi bir güven olmadan pazarlık edilemez girdisi olmaya gereksinimleri. Yukarıdaki ifadeleri dikkatle seçiyoruz; özellikle biz kaynakta bir işlem olmasını gerektirmez Parachain bu gönderiyi açıkça onayladı. Tek Modelimize koyduğumuz kısıtlamalar parachainlerin genel bloklarının bir parçası olarak paketlenmiş olarak sağlamalıdır işlem çıktısı, sonucu olan gönderiler bloğun yürütülmesi. Bu gönderiler birkaç FIFO kuyruğu olarak yapılandırılmıştır; the listelerin sayısı yönlendirme tabanı olarak bilinir ve 16 civarında. Özellikle bu sayı miktarı temsil ediyor başvurmak zorunda kalmadan destekleyebileceğimiz parachain sayısı çok fazlı yönlendirme. Başlangıçta Polkadot bunu destekleyecektir bir çeşit doğrudan yönlendirme, ancak biz olası bir yönlendirmeyi özetleyeceğiz bir araç olarak çok aşamalı yönlendirme süreci (“hiper yönlendirme”) Başlangıçtaki parachain setinin çok ötesine ölçeklendirme. Biz varsaymak bu hepsi katılımcılar biliyorum the sonraki iki blok için alt gruplamalar n, n + 1. Özetle, Yönlendirme sistemi şu aşamaları takip eder: • CollatorS: Doğrulayıcıların iletişim üyeleri[n][S] • Harmanlayıcılar: HER ALT GRUP İÇİN: Doğrulayıcıların[n][s] en az 1 üyesi temas halinde • Harmanlayıcılar: HER alt grup İÇİN: varsaymak çıkış[n −1][s][S] mevcut (tüm gelen gönderiler) verileri son bloktan 'S'ye aktarın) • Harmanlayıcılar: S için blok adayı b'yi oluşturun: (b.başlık, b.ext, b.kanıt, b.makbuz, b.çıkış) • Harmanlayıcılar: Gönder kanıt bilgi kanıt[S] = (b.başlık, b.ext, b.kanıt, b.makbuz) ila Doğrulayıcılar[n][S] • CollatorS: Harici işlem verilerinin b.ext olmasını sağlayın diğer derleyicilerin ve validator'lerin kullanımına sunulur • Harmanlayıcılar: İÇİN HER BİRİ alt grup s: Gönder çıkış bilgi çıkış[n][S][s] = (b.başlık, b.makbuz, b.çıkış[lar]) için the alma alt grup üyeler arasında sonraki blok Doğrulayıcılar[n + 1][s] • V alidatorV : Aynı kümedeki tüm üyeleri önceden bağlayın sonraki blok için: N = Zincir[n + 1][V ]; bağlanmak tüm validators v öyle ki Zincir[n + 1][v] = N • DoğrulayıcıV : Bunun için tüm veri girişlerini toplayın blok: İÇİN HER BİRİ alt grup s: Al çıkış[n −1][s][Zincir[n][V ]], diğer validators v'den Zincir[n][v] = Zincir[n][V ] olacak şekilde alın. Muhtemelen girişimin kanıtı için rastgele seçilmiş diğer validator'lerden geçiyoruz. • DoğrulayıcıV : Bunun için aday kanıtlarını kabul edin blok kanıtı[Zincir[n][V ]]. Oy bloğunun geçerliliği • DoğrulayıcıV : Şunun için aday çıkış verilerini kabul edin: sonraki blok: HER alt grup İÇİN, kabul et çıkış[n][s][N]. Oy engelleme çıkış kullanılabilirliği; ilgilenen validator'ler arasında yeniden yayınlayın, öyle ki Zincir[n + 1][v] = Zincir[n + 1][V ]. • DoğrulayıcıV : UZLAŞMAYA KADAR Burada: egress[n][from][to] geçerli çıkış kuyruğudur Parachain'den 'başlangıç'a giden gönderiler için bilgi 'n' blok numarasındaki parachain 'to'. CollatorS, parachain S için bir harmanlayıcıdır. V alidators[n][s], n blok numarasındaki parachain s için validators kümesidir. Tam tersine, Zincir[n][v], n numaralı blokta validator v'nin atandığı parachaindir. Block.egress[to] çıkıştır bazı parachain blok bloklarından gelen gönderi kuyruğu hedef parachain'dir. Harmanlayıcılar (işlem) ücretlerini topladıkları için blokları kanonik hale geliyor, teşvik ediliyorlar her bir sonraki blok hedefi için alt grubun üyeler mevcut çıkış kuyruğu hakkında bilgilendirilir Blok. Doğrulayıcılar yalnızca bir (parachain) blok üzerinde fikir birliği oluşturmaya teşvik edilir, bu nedenle pek umursamazlar hangi harmanlayıcının bloğu sonuçta kanonik hale gelir. içinde prensip olarak, bir validator bir derleyiciyle bağlılık oluşturabilir ve diğer derleyicilerin şansını azaltmak için komplo kurabilir blokların kanonik hale gelmesi, ancak bu hem zordur rastgele seçim nedeniyle düzenlemek içinvalidators'nin işlemi için Parachain'lere karşı, dayanıklı parachain blokları için ödenecek ücretlerde indirim yapılarak bu savunma yapılabilir. fikir birliği süreci. 6.6.1. Harici Veri Kullanılabilirliği. Parachain'in sağlanması harici verilerin aslında mevcut olması kalıcı bir sorundur İş yükünü dağıtmayı amaçlayan merkezi olmayan sistemler ağ. Sorunun merkezinde kullanılabilirlik var mümkün olmadığı için bunu belirten sorun etkileşimli olmayan bir kullanılabilirlik kanıtı veya herhangi bir türde ibraz etmek BFT sisteminin düzgün bir şekilde çalışması için kullanılabilir olmadığının kanıtı Doğruluğu aşağıdakilere dayanan herhangi bir geçişi doğrulamak bazı harici verilerin kullanılabilirliği, maksimum sayı kabul edilebilir Bizans düğümlerinin sayısı artı sistemin bir tanesi mevcut verilerin doğrulanması gerekir. Polkadot gibi bir sistemin ölçeğinin düzgün şekilde genişletilmesi için bu bir soruna davetiye çıkarıyor: eğer sabit bir oran validators ise Verilerin kullanılabilirliğini doğrulamalıdır ve varsayarak validators, verilerin mevcut olduğunu iddia etmeden önce verileri gerçekten depolamak isteyecekse, o zaman bu durumdan nasıl kaçınabiliriz? sistem boyutu (ve dolayısıyla validators sayısı) arttıkça bant genişliği/depolama gereksinimlerinin artması sorunu mu var? Olası bir cevap ayrı bir sete sahip olmak olabilir Siparişleri artan validators (kullanılabilirlik garantörleri) sayısı bir bütün olarak Polkadot boyutunda alt çizgisel olarak. bu 6.5.3'te açıklanmıştır. Ayrıca ikincil bir numaramız da var. Bir grup olarak derleyiciler, tüm verilerin doğrulanmasını sağlamak için içsel bir teşvike sahiptir. seçtikleri parachain için uygunlar çünkü onsuz yapabilecekleri başka bloklar yazamazlar işlem ücretlerini toplayın. Düzenleyiciler ayrıca üyelikleri değişkenlik gösteren bir grup oluşturur (rastgele doğası nedeniyle) parachain validator grupları) girişi önemsiz ve kolay

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 15 kanıtlamak. Bu nedenle son derleyicilerin (belki de son birkaç bin bloğun) meydan okumalarına izin veriliyor. belirli bir parachain için harici verilerin kullanılabilirliği küçük bir tahvil için validators'ye blok yapın. Doğrulayıcılar, açıkça suç teşkil eden validator alt grubundan ifade veren kişilerle iletişime geçmeli ve ya verileri alıp derleyiciye iade etmeli ya da durumu üst kademeye iletmelidir. mevcudiyetin bulunmadığına dair ifade vererek meseleyi ifade etmek (veri sayımlarını sağlamanın doğrudan reddedilmesi tahvillere el koyma suçu olarak kabul edilir, bu nedenle uygunsuz davranış validator muhtemelen sadece bağlantıyı kes) ve ek validator'lerle iletişim kurma aynı testi yapmak için. İkinci durumda, teminat verenin tahvili iade edilir. Bu tür müsaitlik durumu olmayan referansları sunabilecek validator yeter sayısına ulaşıldığında serbest bırakılırlar, yaramazlık yapan alt grup cezalandırılır ve engelleme geri alınır. 6.6.2. Mesaj Yönlendirme. Her parachain başlığı bir içerir çıkış-üçlü-kök; bu, şunu içeren bir try'nin köküdür yönlendirme tabanı bölmeleri, her bölme birleştirilmiş bir listedir çıkış direkleri. Merkle kanıtları her yerde sunulabilir belirli bir parachain'in olduğunu kanıtlamak için parachain validators bloğun belirli bir hedef parachain için belirli bir çıkış kuyruğu vardı. Bir parachain bloğunun işlenmesinin başlangıcında, her biri söz konusu bloğa bağlı diğer parachain'in çıkış kuyruğu: bloğumuzun giriş kuyruğuna birleştirildi. Güçlü sanıyoruz, muhtemelen CSPR9, herhangi biri arasında herhangi bir kayırmacılık sunmayan deterministik bir operasyon elde etmek için alt blok sıralaması Parachain blok eşleştirmesi. Harmanlayıcılar yeni kuyruğu hesaplar ve çıkış kuyruklarını parachain'in kurallarına göre boşaltın mantık. Giriş kuyruğunun içeriği açıkça yazılmıştır parachain bloğuna. Bunun iki ana amacı vardır: İlk olarak, bu, parachain'in diğer parachain'lerden ayrı olarak güvenilir bir şekilde senkronize edilebileceği anlamına gelir. İkincisi, tüm girişin gerçekleşmesi durumunda veri lojistiğini basitleştirir kuyruk tek bir blokta işlenemiyor; validator'ler ve harmanlayıcılar aşağıdaki blokları işleyebilir kuyruğun verilerini özel olarak kaynaklamak zorunda kalmadan. Parachain'in giriş kuyruğu bir eşiğin üzerindeyse blok işlemenin sonunda miktar, ardından işaretlenir Aktarma zinciri doygun hale gelir ve başka mesaj gönderilemez. temizlenene kadar kendisine teslim edilecektir. Merkle kanıtları harmanlayıcının işleminin doğruluğunu göstermek için kullanılır Parachain bloğunun kanıtı. 6.6.3. Eleştiri. Bu temelle ilgili küçük bir kusur Mekanizma bomba sonrası saldırıdır. Burası her şeyin olduğu yer Parachain'ler mümkün olan maksimum miktarda gönderi gönderir belirli bir parachain'e. Bu hedefin bağlantısını sağlarken giriş kuyruğuna tek seferde girer, tekrar tekrar hasar verilmez standart bir işlem DoS saldırısı. Bir dizi iyi senkronize edilmiş ve normal şekilde çalışıyor N parachain için kötü amaçlı olmayan harmanlayıcılar ve validator'ler, Parachain başına N × M toplam validators ve L harmanlayıcı, biz blok başına toplam veri yollarını şu şekilde parçalayabilir: Doğrulayıcı: M −1+L+L: diğer validator'ler için M −1 Parachain setinde, bir aday parachain bloğu sağlayan her bir harmanlayıcı için L ve her bir harmanlayıcı için ikinci bir L önceki bloğun çıkış yüklerini gerektiren sonraki bloğun. (İkincisi aslında daha çok en kötü duruma benziyor Harmanlayıcıların bu tür bilgileri paylaşması muhtemel olduğundan operasyon veriler.) Harmanlayıcı: M +kN: İlgili her bir bağlantı için M parachain bloğu validator, çıkış yüklerini her parachain validator grubunun bazı alt kümelerine dağıtmak için kN bir sonraki blok (ve muhtemelen bazı tercih edilen harmanlayıcı(lar)). Bu nedenle, düğüm başına veri yolu yolları doğrusal olarak büyür sistemin genel karmaşıklığı ile. Bu iken makul, sistem yüzlerce veya binlerce parachain'e ölçeklendiğinden bir miktar iletişim gecikmesi olabilir daha düşük bir karmaşıklık büyüme oranı karşılığında emilir. Bu durumda çok aşamalı bir yönlendirme algoritması kullanılabilir. anlık yolların sayısını azaltmak için depolama arabellekleri ve gecikmenin eklenmesi pahasına. 6.6.4. Hyper-cube Yönlendirme. Hyper-cube yönlendirme çoğunlukla bir uzantı olarak oluşturulabilen bir mekanizmadır. Yukarıda açıklanan temel yönlendirme mekanizması. Esasen, Parachain ve alt grup düğümlerinin sayısıyla düğüm bağlantısını artırmak yerine yalnızca Parachainlerin logaritması. Gönderiler şu tarihler arasında geçiş yapabilir: Birkaç parachain kuyruğu nihai teslimata doğru ilerliyor. Yönlendirmenin kendisi deterministik ve basittir. Şununla başlıyoruz: giriş/çıkış kuyruklarındaki kutu sayısının sınırlandırılması; toplam parachain sayısı yerine bunlaryönlendirme tabanı (b) . Bu numara olarak sabitlenecek Parachainlerin sayısı değişir, bunun yerine yönlendirme üssü (e) yükseltilir. Bu modelde mesaj hacmimiz O(be) ile büyür, yollar sabit kalır ve gecikme (veya teslimat için gereken blok sayısı) O(e) ile. Yönlendirme modelimiz e boyutlu bir hiperküptür, küpün her iki tarafı da b olası konuma sahiptir. Her blokta mesajları tek bir eksen boyunca yönlendiririz. Biz Ekseni sıralı olarak değiştirerek blokların en kötü durumda teslim süresini garanti altına alırsınız. Parachain işlemenin bir parçası olarak, yurtdışına bağlı Giriş kuyruğunda bulunan mesajlar, verilen gereklilik dikkate alınarak derhal uygun çıkış kuyruğunun bölmesine yönlendirilir. geçerli blok numarası (ve dolayısıyla yönlendirme boyutu). Bu süreç her atlama için ek veri aktarımı gerektirir teslimat rotasında, ancak bu başlı başına bir sorun bazı alternatif yöntemler kullanılarak hafifletilebilecek olan veri yükünün teslimi ve yalnızca bir referans içermesi, deneme sonrası gönderinin tam yükü yerine. Bir sistem için böyle bir hiper küp yönlendirme örneği 4 parachain ile b = 2 ve e = 2 şöyle olabilir: Aşama 0, her M mesajında: • sub0: eğer Mdest ∈{2, 3} ise sendTo(2) yoksa devam et • sub1: eğer Mdest ∈{2, 3} ise sendTo(3) yoksa devam et • sub2: eğer Mdest ∈{0, 1} ise sendTo(0) yoksa devam et • sub3: eğer Mdest ∈{0, 1} ise sendTo(1) yoksa devam et Aşama 1, her M mesajında: • sub0: eğer Mdest ∈{1, 3} ise sendTo(1) yoksa devam et • sub1: eğer Mdest ∈{0, 2} ise sendTo(0) yoksa devam et • sub2: eğer Mdest ∈{1, 3} ise sendTo(3) yoksa devam et • sub3: eğer Mdest ∈{0, 2} ise sendTo(2) yoksa devam et Buradaki iki boyutu ilk boyut olarak görmek kolaydır. hedef indeksin iki biti; ilk blok için yüksek dereceli bit tek başına kullanılır. İkinci blok anlaşmaları düşük dereceli bit ile. Her ikisi de gerçekleştiğinde (keyfi olarak sipariş) ardından gönderi yönlendirilecektir. 9kriptografik olarak güvenli sözde rastgele

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 16 6.6.5. Serendipity'yi en üst düzeye çıkarmak. Temelde bir değişiklik teklifte sabit toplam c2 −c validators görülecektir; her alt grupta c−1 validators. Her blok yerine validators'nin yapılandırılmamış bir yeniden bölümlenmesi var Parachain'ler arasında, bunun yerine her parachain alt grubu için, her validator benzersiz ve farklı bir numaraya atanacaktır Aşağıdaki blokta parachain alt grubu. Bu herhangi iki blok arasında herhangi bir değişken için değişmezliğe yol açar iki parachain çifti var, iki validators var Parachain sorumluluklarını değiştirdik. Bu, kullanılabilirlik konusunda mutlak garantiler elde etmek için kullanılamasa da (tek bir validator ara sıra devre dışı kalacaktır, hatta yardımsever), yine de genel durumu optimize edebilir. Bu yaklaşım komplikasyonsuz değildir. Parachain'in eklenmesi aynı zamanda yeniden yapılanmayı da gerektirecektir. validator kümesinin. Ayrıca validators sayısı parachain sayısının karesine bağlıdır, başlangıçta çok küçük başlayacak ve sonunda çok büyüyecekti çok hızlı, yaklaşık 50 parachain'den sonra savunulamaz hale geliyor. Bunların hiçbiri temel sorunlar değil. İlk durumda, validator kümelerinin yeniden düzenlenmesi olması gereken bir şeydir zaten düzenli olarak yapılıyor. validator boyutuyla ilgili olarak ayarlandı, çok küçük olduğunda birden fazla validator atanabilir aynı parachain'e bir tam sayı faktörü uygulayarak genel toplam validators. 6.6.4'te tartışılan Hypercube Routing gibi çok aşamalı bir yönlendirme mekanizması, çok sayıda validators gereksinimini hafifletmek çok sayıda zincir olduğunda. 6.7. Parachain Doğrulaması. A validator'in asıl amacı iyi ilişkilere sahip bir aktör olarak bir parachain'in Blok, herhangi bir durum geçişi, herhangi bir harici işlem dahil ancak bunlarla sınırlı olmamak üzere geçerlidir. giriş kuyruğundaki tüm bekleme noktaları ve son durum çıkış kuyruğundan. Sürecin kendisi oldukça basittir. validator önceki bloğu mühürledikten sonra özgürdürler aday parachain bloğu sağlamak için çalışmaya başlamak bir sonraki konsensüs turuna aday. Başlangıçta, validator bir parachain harmanlayıcı (sonraki bölümde anlatılacaktır) veya bir parachain harmanlayıcı aracılığıyla bir parachain blok adayını bulur. eş-validators. Parachain bloğu aday verileri bloğun başlığını, önceki bloğun başlığını içerir, dahil edilen tüm harici giriş verileri (Ethereum ve Bitcoin için, bu tür veriler işlemler olarak anılacaktır, ancak prensipte keyfi amaçlar için rastgele veri yapıları içerebilirler), çıkış kuyruğu verileri ve durum geçişi geçerliliğini kanıtlamak için dahili veriler (Ethereum için) bu, her bir işlemi yürütmek için gereken çeşitli durum/depolama düğümleri olacaktır). Deneysel kanıtlar, yeni bir Ethereum bloğu için bu tam veri kümesini gösteriyor en fazla birkaç yüz KiB olacaktır. Eş zamanlı olarak, henüz yapılmadıysa validator Başlangıçta önceki bloğun geçişinden önceki bloğun geçişine ilişkin bilgileri almaya çalışmak validators ve sonrası için imza atan tüm validators'den verilerin kullanılabilirliği. validator böyle bir aday bloğu aldığında, daha sonra bunu yerel olarak doğrularlar. Doğrulama işlemi parachain sınıfının validator modülünde bulunur; yazılması gereken fikir birliğine duyarlı yazılım modülü Polkadot'nin herhangi bir uygulaması için (prensipte olsa da) C ABI'ye sahip bir kütüphane, tek bir kütüphanenin uygulamalar arasında uygun şekilde paylaştırılmalıdır. yalnızca tek bir “referans” uygulamaya sahip olmaktan kaynaklanan güvenlik azalması). Süreç, önceki bloğun başlığını alır ve yakın zamanda üzerinde anlaşmaya varılan aktarma zinciri aracılığıyla kimliğini doğrular. hash kaydedilmesi gereken blok. Ana başlığın geçerliliği doğrulandıktan sonra özel parachain sınıfın doğrulama işlevi çağrılabilir. Bu, bir dizi veri alanını kabul eden tek bir işlevdir (kabaca daha önce verilenler) ve basit bir Boole değeri döndürmek bloğun geçerliliğini ilan ediyor. Bu tür doğrulama işlevlerinin çoğu ilk olarak doğrudan türetilebilen başlık alanları ana blok (örn. ebeveyn hash, sayı). Takip ediliyor bunu yaparak, herhangi bir dahili veri yapısını şu şekilde dolduracaklar: işlemleri ve/veya gönderileri işlemek için gerekli. Ethereum benzeri bir zincir için bu, bir için ihtiyaç duyulacak düğümleri içeren veritabanını deneyin. işlemlerin tam olarak yürütülmesi. Diğer zincir türlerinde şunlar olabilir: diğer ponarıcı mekanizmalar. İşlem tamamlandıktan sonra, giriş gönderileri ve harici işlemler (veya harici verilerin temsil ettiği şey) zincirin spesifikasyonuna göre dengelenmiş, yürürlüğe konmuştur. (Bir mantıklı varsayılan, tüm giriş gönderilerinin olmasını gerektirmek olabilir harici işlemlere hizmet verilmeden önce işlenir, ancak buna parachain mantığının karar vermesi gerekir.) Bu yasayla bir dizi çıkış noktası oluşturulacak. oluşturuldu ve bunların gerçekten eşleştiği doğrulanacak derleyicinin adayı. Son olarak, uygun şekilde doldurulmuş başlık, adayın başlığına göre kontrol edilecektir. Tamamen doğrulanmış bir aday blokla validator daha sonra başlığının hash'sına oy verebilir ve gerekli tüm doğrulama bilgilerini alt grubundaki ortak validator'lere gönderebilir. 6.7.1. Parachain Düzenleyicileri. Parachain harmanlayıcıları madencilerin görevlerinin çoğunu yerine getiren bağımsız operatörlerdir günümüzün blockchain ağlarında. Bunlar spesifiktir belirli bir parachain'e. Çalıştırmak için şunları yapmaları gerekir: hem röle zincirini hem de tam senkronizeyi koruyun Parachain. "Tam senkronize"nin kesin anlamı parachain sınıfına bağlı olacaktır ancak her zaman parachain giriş kuyruğunun mevcut durumunu içerecektir. Ethereum durumunda bu aynı zamanda en azından bakımı da içerir son birkaç bloğun Merkle ağacı veri tabanı, ancak ayrıca Bloom dahil çeşitli diğer veri yapılarını da içerir Hesabın varlığı, aile bilgileri, günlük kaydı için filtreler blok numarası için çıkışlar ve geriye doğru arama tabloları. İki zinciri senkronize tutmanın yanı sıra, ayrıca bir işlem kuyruğunu koruyarak ve uygun şekilde doğrulanmış işlemleri kabul ederek işlemler için "avlanmalı" halka açık ağdan. Sıra ve zincirle, her blokta seçilen validator'ler için (aktarma zinciri senkronize olduğundan kimliği bilinen) yeni aday bloklar oluşturabilir ve bunları geçerlilik kanıtı gibi çeşitli yardımcı bilgiler eş ağ. Zahmetine karşılık, içerdiği işlemlere ilişkin tüm ücretleri tahsil eder. Bunun etrafında çeşitli ekonomiler dönüyor düzenleme. Yoğun rekabetin olduğu bir piyasada teminat verenlerin fazlalığı varsa, işlemin gerçekleşmesi mümkündür ücretler teşvik amacıyla validators parachain ile paylaşılacaktır belirli bir harmanlayıcı bloğunun dahil edilmesi. Benzer şekilde,

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 17 bazı düzenleyiciler ihtiyaç duyulan ücretleri bile artırabilir bloğun daha çekici hale getirilmesi için ödeme yapılması validators. Bu durumda doğal bir pazarın oluşması gerekmektedir. daha yüksek ücretler ödeyen işlemler kuyruğu atlıyor ve zincire daha hızlı dahil olma. 6.8. Ağ oluşturma. Geleneksel blockchains üzerinde ağ oluşturma Ethereum ve Bitcoin gibi oldukça basit gereksinimlere sahiptir. Tüm işlemler ve bloklar basit, yönlendirilmemiş bir dedikoduyla yayınlanır. Senkronizasyon daha kapsamlıdır, özellikle Ethereum ile ancak gerçekte bu mantık şunun içinde yer alıyordu: birkaç istek ve yanıt mesajı türü etrafında çözümlenen protokolün kendisinden ziyade akran stratejisi. Ethereum devp2p protokolüyle mevcut protokol teklifleri konusunda ilerleme kaydederken, bu da birçok kişiye olanak sağladı alt protokoller tek bir eş bağlantı üzerinden çoğaltılacak ve dolayısıyla aynı eş katman paylaşımına sahip olacak ve birçok p2p protokolleri aynı anda, Ethereum kısmı protokol hala nispeten basit kaldı ve p2p protokol bir süredir önemli konularla tamamlanmamış durumda QoS desteği gibi işlevsellik eksik. Ne yazık ki, daha yaygın bir "web 3" protokolü oluşturma arzusu büyük ölçüde başarısız oldu, bunu kullanan tek proje açıkça bunlardı Ethereum toplu satıştan finanse edildi. Polkadot ile ilgili gereksinimler oldukça daha önemlidir. Tamamen tek tip bir ağ yerine, Polkadot her birinin akran yapısından ve çeşitli ağlardan farklı gereksinimleri olan çeşitli katılımcı türleri vardır Katılımcıların hakkında sohbet etme eğiliminde olacağı “yollar” özel veriler. Bu, önemli ölçüde daha yapılandırılmış bir ağ katmanı ve bunu destekleyen bir protokol anlamına gelir. muhtemelen gerekli olacaktır. Ayrıca, yeni tür “zincir” gibi gelecekteki eklemeleri kolaylaştıracak genişletilebilirlik, kendileri yeni bir katman yapısı gerektirir. Ağ oluşturmanın nasıl yapıldığına dair derinlemesine bir tartışma protokol bu belgenin kapsamı dışında görünebilir, bazı gereksinim analizleri makul olabilir. Yapabiliriz ağ katılımcılarımızı kabaca iki gruba ayırın (röle zinciri, parachainler) her biri üç alt kümeden oluşur. Yapabiliriz ayrıca parachain katılımcılarının her birinin yalnızca aksine kendi aralarında sohbet etmekle ilgileniyorlar diğer parachainlerdeki katılımcılar: • Aktarma zinciri katılımcıları: • Doğrulayıcılar: P, her biri için P[s] alt kümelerine bölünür paraşütle atlama • Kullanılabilirlik Garantörleri: A (bu, protokolün temel formunda Doğrulayıcılar tarafından temsil edilebilir) • Aktarma zinciri istemcileri: M (her birinin üyelerini not edin) Parachain seti aynı zamanda M'nin üyesi olma eğiliminde olacaktır) • Parachain katılımcıları: • Parachain Düzenleyicileri: C[0], C[1], . . . • Parachain Balıkçıları: F[0], F[1], . . . • Parachain istemcileri: S[0], S[1], . . . • Parachain ışık istemcileri: L[0], L[1], . . . Genel olarak belirli iletişim sınıflarını adlandırırız bu kümelerin üyeleri arasında gerçekleşme eğiliminde olacaktır: • P | bir <-> P | C:

dolu ayarlamak arasında validators/garantörler zorunluluk olmak iyi bağlantılara sahip için fikir birliğine varmak. • P[s] <-> C[s] | P[s]: Belirli bir parachain grubunun üyesi olan her validator dedikodu yapma eğiliminde olacaktır bu tür diğer üyelerle ve derleyicilerle Blok adaylarını keşfetmek ve paylaşmak için bu parachain'in. • A <-> P[s] | C | A: Her kullanılabilirlik garantörü fikir birliğine duyarlı çapraz zincirleri toplaması gerekecek kendisine atanan validator'lardan gelen veriler; derleyiciler aynı zamanda fikir birliği şansını da optimize edebilir kullanılabilirlik garantörlerine reklam vererek engelleyin. Ellerine geçtikten sonra veriler şu adrese dağıtılacak: fikir birliğini kolaylaştırmak için bu tür başka garantörler. • P[s] <-> A | P[s']: Parachain validators olacak önceki validator grubundan veya kullanılabilirlik garantörlerinden ek giriş verileri toplaması gerekiyor. • F[s] <-> P: Balıkçılar rapor verirken herhangi bir katılımcıyla ilgili bir hak talebi. • M <-> M | P | C: Genel aktarma zinciri istemcileri, verileri validator'lerden ve garantörlerden dağıtır. • S[s] <-> S[s] | P[ler] | C: Parachain istemcileri verileri validator/garantörlerden dağıtır. • L[s] <-> L[s] | S[s]: Parachain ışık istemcileri Verileri tam istemcilerden dağıtın. Verimli bir taşıma mekanizması sağlamak için “düz” bir yer paylaşımlı ağ (Ethereum'nin devp2p'si gibi) burada her biri düğüm, kendi uygunluk değerini (keyfi olmayan bir şekilde) farklılaştırmaz. akranlarının uygun olması muhtemel değildir. Makul ölçüde genişletilebilir akran seçimi ve keşif mekanizması muhtemelen ihtiyaç duyacaktır agresif olmasının yanı sıra protokole dahil edilecek Doğru türden akranları sağlamak için ileriye yönelik bir planlama planlamak "tesadüfen" bağlanıyorlardoğru zamanda harekete geçtik. Akran oluşturmanın kesin stratejisi her katılımcı sınıfı için farklı olacaktır: uygun şekilde ölçeklendirilmiş bir çoklu zincir, harmanlayıcıların ya sürekli olması gerekecek buna uygun olarak seçilen validator'lere yeniden bağlanılıyor veya validators alt kümesiyle devam eden anlaşmalara ihtiyaç var validator için işe yaramaz oldukları çoğu zaman bağlantılarının kesilmediğinden emin olmak için. Düzenleyiciler aynı zamanda doğal olarak bir tanesini korumaya çalışacaklardır. veya kullanılabilirlik garantörüne daha istikrarlı bağlantılar fikir birliğine duyarlı yaklaşımlarının hızlı bir şekilde yayılmasını sağlamak üzere kurulmuştur. veri. Kullanılabilirlik garantörleri çoğunlukla bir birbirleriyle ve validators ile istikrarlı bağlantı (konsensüs ve konsensüs açısından kritik parachain verileri için) onaylıyorlar) ve bazı derleyicilere (parachain için) veriler) ve bazı balıkçılar ve tam müşteriler (dağıtım için) bilgi). Doğrulayıcılar diğer validator'leri, özellikle de aynı alt gruptakileri ve herhangi bir onlara parachain blok adayları sağlayabilecek harmanlayıcılar. Balıkçılar ve genel bayrak zinciri ve parachain istemciler genellikle bağlantıyı açık tutmayı hedeflerler. validator veya garantör, ancak benzer birçok başka düğüm var aksi takdirde kendilerine. Parachain hafif istemcileri de benzer şekilde parachain'in tam istemcisine bağlanmayı hedefleyecektir. sadece diğer parachain ışık istemcileri olmasa da. 6.8.1. Akran Kaybı Sorunu. Temel protokol teklifinde, bu alt kümelerin her biri, doğrulama için atanan validator'ler olarak her blokta rastgele olarak değişir. Parachain geçişleri rastgele seçilir. Bu olabilir farklı (eş olmayan) düğümlerin bir sorun olması gerekir birbirleri arasında veri aktarımı. Ya güvenmek gerekir adil bir şekilde dağıtılmış ve iyi bağlanmış bir eş ağ

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 18 Atlama mesafesinin (ve dolayısıyla en kötü durumdaki gecikmenin) yalnızca ağ boyutunun logaritmasıyla arttığından emin olun (Kademlia benzeri bir protokol [13] burada yardımcı olabilir) veya bir eş kümesini korumak için gerekli bağlantı anlaşmasının gerçekleşmesine izin vermek amacıyla daha uzun blok süreleri uygulayın. düğümün mevcut iletişim ihtiyaçlarını yansıtır. Bunların hiçbiri mükemmel çözüm değil: uzun blok süreleri ağa zorlanmak onu işe yaramaz hale getirebilir özel uygulamalar ve zincirler. Hatta mükemmel bir adil ve bağlı ağ önemli miktarda israfa neden olacaktır İlgisiz düğümlerin sahip olması nedeniyle ölçeklendikçe bant genişliği onlara faydası olmayan verileri iletmek. Her iki yön de çözümün bir parçasını oluştursa da, Gecikmeyi en aza indirmeye yardımcı olacak makul bir optimizasyon bu parachain'in volatilitesini kısıtlamak için validator üyeliği yalnızca blok serileri arasında yeniden atayarak (örneğin 15'li gruplar halinde, 4 saniyede bir blok süresi, bağlantıların yalnızca bir kez değiştirilmesi anlamına gelir dakika) veya üyeliği kademeli olarak değiştirerek, örn. bir seferde bir üye tarafından değiştiriliyor (örneğin eğer varsa) Her bir parachain'e 15 validator atanmışsa, bu durumda ortalama olarak tamamen benzersiz olanlarla arasında tam bir dakika olacaktır. setleri). Akran kaybının miktarını sınırlayarak ve avantajlı akran bağlantılarının iyi bir şekilde kurulmasını sağlayarak Parachain'in kısmi öngörülebilirliği yoluyla ilerlemek ayarlar, her düğümün kalıcı olarak korunmasına yardımcı olabiliriz tesadüfen akran seçimi. 6.8.2. Etkili Bir Ağ Protokolüne Giden Yol. Muhtemelen En etkili ve makul geliştirme çabası, yuvarlanmak yerine önceden var olan bir protokolün kullanılmasına odaklanacaktır. bizim. Çeşitli eşler arası temel protokoller mevcuttur Ethereum'nin kendi devp2p'sini kullanabilir veya artırabiliriz [22], IPFS'nin libp2p'si [1] ve GNU'nun GNUnet'i [4]. Bu protokollerin tam bir incelemesi ve bunların bir Belirli yapısal garantileri, dinamik eş yönlendirmeyi ve genişletilebilir alt protokolleri destekleyen modüler eş ağ bu belgenin kapsamı dışındadır ancak bir Polkadot'nin uygulanmasında önemli bir adım. 7. Protokolün Uygulanabilirliği 7.1. Zincirler Arası İşlem Ödemesi. Harika bir zaman Ethereum'nin gazı gibi bütünsel bir hesaplama kaynağı muhasebe çerçevesine olan ihtiyacın ortadan kaldırılmasıyla bir miktar özgürlük ve basitlik kazanılır, bu önemli bir soruyu gündeme getirir: Gaz olmadan bir parachain nasıl yapılır? Başka bir parachain'in onu hesaplama yapmaya zorlamasını önlemek mi istiyorsunuz? İşlem sonrası giriş kuyruğuna güvenebiliriz Bir zincirin diğerine spam göndermesini önlemek için tamponlar işlem verileri, işlem sırasında spam gönderilmesini önlemek için protokol tarafından sağlanan eşdeğer bir mekanizma yoktur. Bu daha üst seviyeye bırakılmış bir sorundur. Zincirlerden beri gelen mesajlara keyfi anlambilim eklemekte özgürdürler. işlem sonrası veriler, hesaplamanın yapılmasını sağlayabiliriz başlamadan önce ödenmesi gerekmektedir. Buna benzer bir şekilde Ethereum Serenity'nin benimsediği model, hayal edebiliyoruz izin veren bir parachain içindeki "zorla girme" sözleşmesi validator karşılığında ödeme garanti edilecek belirli bir hacimde işlem kaynağının sağlanması. Bu kaynaklar gaz gibi bir şeyle ölçülebilir, ancak aynı zamanda öznel uygulama süresi veya Bitcoin benzeri sabit ücret modeli gibi tamamen yeni bir model de olabilir. Bu tek başına o kadar da kullanışlı değil çünkü zincir dışı arayanın onlara ulaşabildiğini kolayca varsayamayız. Hırsızlık tarafından tanınan değer mekanizması ne olursa olsun sözleşme. Ancak kaynak zincirinde ikincil bir “kırılma” sözleşmesi hayal edebiliriz. İki sözleşme birlikte birbirini tanıyan bir köprü oluşturacak ve değer eşdeğerliği sağlar. (Stake etme-tokens, mevcut her biri ödemeler dengesini dengelemek için kullanılabilir.) Böyle başka bir zincire çağrı yapmak, vekillik yapmak anlamına gelir ulaşımı sağlayacak olan bu köprüden zincirler arasında değer aktarımının müzakere edilmesi Hedef parachain'de gereken hesaplama kaynakları için ödeme yapın. 7.2. Ek Zincirler. iken the ekleme arasında bir parachain nispeten ucuz bir işlemdir, ücretsiz değildir. Daha fazla parachain, parachain başına daha az validators anlamına gelir ve sonunda her biri bir değere sahip daha fazla sayıda validator azaltılmış ortalama tahvil. Parachain'e saldırmanın daha küçük bir zorlama maliyeti sorunu, balıkçılar, büyüyen validator grubu aslında bir altta yatan fikir birliğinin mekaniği nedeniyle daha yüksek gecikme derecesiama. Ayrıca her parachain validators'yi üzme potansiyelini de beraberinde getiriyor aşırı külfetli doğrulama algoritması. Bu nedenle, validators tutarında bir "fiyat" olacaktır. ve/veya paydaş topluluğunun çıkaracağı yeni bir parachain eklenmesi. Zincirlere yönelik bu pazar muhtemelen aşağıdakilerden birinin eklendiğini görebilirsiniz: • Bir parçası haline getirilecek net katkı payı ödemesi muhtemelen sıfır olan zincirler (staking tokens'nin kilitlenmesi veya yakılması açısından) (örn. konsorsiyum zincirleri, Doge zincirleri, uygulamaya özel zincirler); • ağa gerçek değer sağlayan zincirler belirli işlevlerin eklenmesi zor başka bir yere ulaşmak (örneğin gizlilik, dahili ölçeklenebilirlik, hizmet bağlantıları). Esasen, paydaş topluluğunun şunları yapması gerekecektir: finansal veya finansal olarak alt zincirler eklemeye teşvik edilebilir röleye özellikli zincirler ekleme arzusuyla. Eklenen yeni zincirlerin çok büyük bir etki yaratacağı öngörülüyor. yeni zincirlerin çıkarılmasına olanak tanıyan kısa bir çıkarma süresi taviz verme riski olmadan denenebilir orta veya uzun vadeli değer teklifi. 8. Sonuç Bir kişinin bir makale yazmak için izleyebileceği bir yönü özetledik önceden var olan belirli protokollerle geriye doğru uyumlu olma potansiyeline sahip, ölçeklenebilir, heterojen çok zincirli protokol blockchain ağlar. Böyle bir protokol kapsamında katılımcılar İstisnai derecede özgür bir şekilde genişletilebilecek ve mevcut kullanıcılar için tipik bir maliyet olmaksızın genişletilebilecek genel bir sistem oluşturmak için aydınlanmış kişisel çıkarlar doğrultusunda çalışın. standart bir blockchain tasarımından gelir. biz verdik dahil olacak mimarinin kaba bir taslağı katılımcıların doğası, ekonomik teşvikleri ve dahil olmaları gereken süreçler. bizde temel bir tasarım tanımladı ve onun güçlü yönlerini tartıştı ve sınırlamalar; buna göre başka talimatlarımız da var bu sınırlamaları hafifletebilir ve tamamen ölçeklenebilir bir blockchain çözümüne doğru daha fazla zemin sağlayabilir.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 19 8.1. Eksik Materyal ve Açık Sorular. Ağ çatallanması, protokolün farklı uygulamalarından dolayı her zaman bir olasılıktır. Böyle bir durumdan iyileşme olağanüstü durum tartışılmadı. Ağın zorunlu olarak sıfırdan farklı bir sonuçlandırma periyoduna sahip olacağı göz önüne alındığında, Aktarım zinciri çatallanmasından kurtulmak büyük bir sorun olmasa da, dikkatli bir entegrasyon gerektirecektir. fikir birliği protokolü. Tahvillere el konulması ve bunun tersine ödül hükmü derinlemesine araştırılmamıştır. Şu anda ödülleri varsayıyoruz kazanan her şeyi alır esasına göre sağlanır: bu Balıkçılara en iyi teşvik modelini verin. Kısa süreli bir taahhüt-açıklama süreci birçok balıkçının Ödüllerin daha adil dağılımını sağlayarak ödülü talep etmek, ancak süreç ek gecikmeye yol açabilir uygunsuz davranışın tespiti. 8.2. Teşekkürler. Hepsine çok teşekkürler Bunu belli belirsiz bir hale getirmeye yardımcı olan düzeltmenler prezentabl şekil. Özellikle Peter Czaban, Bjorn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler ve Jack Petersson. Herkese teşekkürler Fikirlere veya başlangıçlara katkıda bulunan insanlar Bu konuda Marek Kotewicz ve Aeron Buchanan özel olarak anılmayı hak ediyor. Ve yardımları için herkese teşekkürler yol boyunca. Tüm hatalar bana aittir. Bu çalışmanın bazı bölümleri, ilk araştırmalar da dahil olmak üzere fikir birliği algoritmaları kısmen İngilizler tarafından finanse edildi Innovate UK programı kapsamında hükümet.