Polkadot: видение гетерогенной многоцепной структуры

Oleh Gavin Wood · 2016

Abstrak

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 dr. KAYU GAVIN PENDIRI, ETHEREUM & PARITAS [email protected] Abstrak. Arsitektur blockchain saat ini semuanya mengalami sejumlah masalah, paling tidak dalam hal praktik ekstensibilitas dan skalabilitas. Kami percaya hal ini berasal dari pengikatan dua bagian yang sangat penting dari arsitektur konsensus, yaitu: kanonikalitas dan validitas, terlalu erat hubungannya. Makalah ini memperkenalkan arsitektur, multi-rantai heterogen, yang pada dasarnya membedakan keduanya. Dengan mengelompokkan kedua bagian ini, dan dengan menjaga keseluruhan fungsi yang disediakan seminimal mungkin keamanan dan transportasi, kami memperkenalkan sarana praktis perluasan inti di lokasi. Skalabilitas diatasi melalui pendekatan bagi-dan-taklukkan kedua fungsi ini, dengan memperluas fungsi inti yang terikat melalui insentif node publik yang tidak tepercaya. Sifat heterogen dari arsitektur ini memungkinkan banyak jenis sistem konsensus yang sangat berbeda untuk saling beroperasi dalam “federasi” yang tidak dapat dipercaya dan sepenuhnya terdesentralisasi, memungkinkan jaringan terbuka dan tertutup untuk memiliki akses bebas kepercayaan ke satu sama lain. Kami mengedepankan sarana untuk menyediakan kompatibilitas mundur dengan satu atau lebih jaringan yang sudah ada seperti Ethereum. Kami percaya bahwa sistem seperti itu menyediakan komponen tingkat dasar yang berguna dalam pencarian keseluruhan secara praktis sistem yang dapat diterapkan yang mampu mencapai tingkat skalabilitas dan privasi perdagangan global. 1. Kata Pengantar Hal ini dimaksudkan sebagai ringkasan “visi” teknis satu kemungkinan arah yang dapat diambil dalam mengembangkan lebih lanjut paradigma blockchain beserta beberapa alasan mengapa arah ini masuk akal. Itu diatur dalam sedetail mungkin pada tahap pengembangan ini suatu sistem yang dapat memberikan perbaikan nyata pada a sejumlah aspek teknologi blockchain. Hal ini tidak dimaksudkan sebagai spesifikasi, formal atau lainnya. Hal ini tidak dimaksudkan untuk menjadi komprehensif atau a desain akhir. Hal ini tidak dimaksudkan untuk mencakup aspek-aspek non-inti kerangka kerja seperti API, binding, bahasa, dan penggunaan. Ini terutama bersifat eksperimental; di mana parameter ditentukan, kemungkinan besar akan berubah. Mekanisme akan melakukannya ditambahkan, disempurnakan, dan dihapus sebagai respons terhadap komunitas ide dan kritik. Kemungkinan besar sebagian besar makalah ini akan membahasnya direvisi sesuai bukti eksperimental dan pemberian prototipe kami informasi tentang apa yang akan berhasil dan apa yang tidak. Dokumen ini mencakup uraian inti protokol beserta gagasan arah yang dapat diambil untuk memperbaiki berbagai aspek. Hal ini dibayangkan sebagai inti deskripsi akan digunakan sebagai titik awal untuk inisial serangkaian pembuktian konsep. “Versi 1.0” terakhir adalah didasarkan pada protokol yang disempurnakan ini bersama dengan ide-ide tambahan yang telah terbukti dan bertekad untuk itu diperlukan agar proyek dapat mencapai tujuannya. 1.1. Sejarah. • 09/10/2016: 0.1.0-bukti1 • 20/10/2016: 0.1.0-bukti2 • 01/11/2016: 0.1.0-bukti3 • 11/10/2016: 0.1.0 2. Pendahuluan Blockchain telah menunjukkan manfaat yang besar di beberapa bidang termasuk “Internet of Things” (IoT), keuangan, tata kelola, manajemen identitas, desentralisasi web, dan pelacakan aset. Namun, meskipun demikian janji teknologi dan pembicaraan besar, kita belum melihatnya penyebaran teknologi saat ini yang signifikan di dunia nyata. Kami percaya bahwa hal ini disebabkan oleh lima kegagalan utama yang terjadi saat ini tumpukan teknologi: Skalabilitas: Berapa banyak sumber daya yang dihabiskan secara global pada pemrosesan, bandwidth dan penyimpanan agar sistem dapat memproses satu transaksi dan berapa banyak transaksi dapat diproses secara wajar berdasarkan kondisi puncak? Isolatabilitas: Dapat memenuhi kebutuhan yang berbeda-beda pihak dan permohonan ditangani hingga tingkat yang mendekati optimal dalam kerangka yang sama? Pengembangan: Seberapa baik alat tersebut bekerja? Lakukan apakah API memenuhi kebutuhan pengembang? Apakah materi pendidikan tersedia? Apakah ada integrasi yang tepat? Tata Kelola: Dapatkah jaringan tetap fleksibel terhadap berevolusi dan beradaptasi seiring berjalannya waktu? Bisakah keputusan menjadi dibuat dengan inklusivitas, legitimasi dan transparansi untuk memberikan kepemimpinan yang efektif a sistem desentralisasi? Penerapan: Apakah teknologi tersebut benar-benar mampu menjawab kebutuhan yang mendesak? Apakah “perangkat perantara” lain diperlukan untuk menjembatani kesenjangan tersebut aplikasi sebenarnya? Dalam penelitian ini, kami bertujuan untuk mengatasi dua hal pertama masalah: skalabilitas dan isolasi. Meski begitu, kami percaya kerangka Polkadot dapat memberikan perbaikan yang berarti pada setiap kelompok masalah ini. Implementasi blockchain yang modern dan efisien seperti klien Paritas Ethereum [17] dapat memproseses lebih dari 3.000 transaksi per detik saat dijalankan pada perangkat keras konsumen yang berkinerja baik. Namun, dunia nyata saat ini blockchain jaringan praktis dibatasi sekitar 30 transaksi per detik. Keterbatasan ini terutama berasal dari kenyataan bahwa mekanisme konsensus sinkron yang ada saat ini memerlukan batas waktu keselamatan yang besar waktu pemrosesan yang diharapkan, yang diperburuk oleh 1

Аннотация

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 ДР. ГЭВИН ВУД ОСНОВАТЕЛЬ ETHEREUM И PARITY ГЭВИН@PARITY.IO Аннотация. Все современные архитектуры blockchain страдают от ряда проблем, не в последнюю очередь связанных с практическими средствами расширения и масштабируемости. Мы считаем, что это связано с объединением двух очень важных частей архитектуры консенсуса, а именно: каноничность и действительность слишком тесно связаны друг с другом. В этой статье представлена архитектура гетерогенной мультицепи, что фундаментально отличает их друг от друга. Разделив эти две части на отдельные части и сведя общую функциональность к абсолютному минимуму. безопасности и транспорта, мы представляем практические средства расширения ядра на месте. Масштабируемость обеспечивается за счет подход к этим двум функциям по принципу «разделяй и властвуй», расширяя свое связанное ядро за счет стимулирования ненадежные публичные узлы. Гетерогенная природа этой архитектуры позволяет множеству сильно различающихся типов консенсусных систем взаимодействовать в не требующей доверия, полностью децентрализованной «федерации», позволяя открытым и закрытым сетям иметь свободный от доверия доступ к друг друга. Мы предлагаем средства обеспечения обратной совместимости с одной или несколькими ранее существовавшими сетями, такими как Ethereum. Мы считаем, что такая система представляет собой полезный компонент базового уровня в общем поиске практического решения. реализуемая система, способная достичь уровня масштабируемости и конфиденциальности глобальной коммерции. 1. Предисловие Это краткое изложение технического «видения» одного возможного направления, которое может быть выбрано для дальнейшего развития парадигмы blockchain, вместе с некоторым обоснованием того, почему это направление целесообразно. Оно лежит в как можно больше деталей на данном этапе разработки система, которая может дать конкретное улучшение ряд аспектов технологии blockchain. Оно не предназначено для использования в качестве спецификации, формальной или иной. Он не претендует на то, чтобы быть всеобъемлющим или представлять собой окончательный дизайн. Он не предназначен для освещения неосновных аспектов. инфраструктуры, такие как API, привязки, языки и использование. Это особенно экспериментально; где параметры определены, они, вероятно, изменятся. Механизмы будут добавлять, уточнять и удалять в ответ на запросы сообщества. идеи и критика. Большая часть этой статьи, скорее всего, будет быть пересмотрено по мере того, как экспериментальные данные и прототипирование дают нам информацию о том, что будет работать, а что нет. Этот документ включает основное описание протокола вместе с идеями относительно направлений, которые можно предпринять. для улучшения различных аспектов. Предполагается, что ядро описание будет использоваться в качестве отправной точки для первоначального серия доказательств концепции. Окончательная «версия 1.0» будет основанный на этом усовершенствованном протоколе вместе с дополнительными идеями, которые стали доказанными и полны решимости необходимы для того, чтобы проект достиг своих целей. 1.1. История. • 10.09.2016: 0.1.0-доказательство1 • 20.10.2016: 0.1.0-доказательство2 • 11.01.2016: 0.1.0-доказательство3 • 11.10.2016: 0.1.0 2. Введение Блокчейны продемонстрировали большие перспективы использования в нескольких областях, включая «Интернет вещей». (IoT), финансы, управление, управление идентификацией, веб-децентрализация и отслеживание активов. Однако, несмотря на технологические обещания и грандиозные разговоры, нам еще предстоит увидеть значительное реальное внедрение современных технологий. Мы считаем, что это связано с пятью ключевыми неудачами нынешней политики. технологические стеки: Масштабируемость: сколько ресурсов тратится по всему миру. об обработке, пропускной способности и хранилище, позволяющем системе обрабатывать одну транзакцию и сколько транзакции могут быть разумно обработаны в соответствии с пиковые условия? Изолируемость: могут ли различающиеся потребности нескольких Стороны и заявления будут рассматриваться в почти оптимальной степени в рамках одних и тех же рамок? Возможность разработки: насколько хорошо работают инструменты? Делай API отвечают потребностям разработчиков? Доступны ли учебные материалы? Есть ли нужные интеграции? Управление: может ли сеть оставаться гибкой для развиваться и адаптироваться с течением времени? Могут ли решения быть сделано с достаточной инклюзивностью, легитимностью и прозрачность для обеспечения эффективного руководства децентрализованная система? Применимость: действительно ли технология сама по себе решает острую потребность? Требуется ли другое «промежуточное программное обеспечение», чтобы устранить разрыв в реальные приложения? В настоящей работе мы стремимся рассмотреть первые два. проблемы: масштабируемость и изоляционность. Тем не менее, мы верим Платформа Polkadot может обеспечить значительные улучшения в каждом из этих классов проблем. Современные эффективные реализации blockchain, такие как клиент Parity Ethereum PH_0000 может обрабатыватьэто превышает 3000 транзакций в секунду при работе на производительном потребительском оборудовании. Однако нынешний реальный мир Сети blockchain практически ограничены примерно 30 транзакций в секунду. Это ограничение главным образом связано с тем, что современные механизмы синхронного консенсуса требуют больших временных запасов безопасности. ожидаемое время обработки, которое усугубляется 1

Perkenalan

Blockchain telah menunjukkan manfaat yang besar di beberapa bidang termasuk “Internet of Things” (IoT), keuangan, tata kelola, manajemen identitas, desentralisasi web, dan pelacakan aset. Namun, meskipun demikian janji teknologi dan pembicaraan besar, kita belum melihatnya penyebaran teknologi saat ini yang signifikan di dunia nyata. Kami percaya bahwa hal ini disebabkan oleh lima kegagalan utama yang terjadi saat ini tumpukan teknologi: Skalabilitas: Berapa banyak sumber daya yang dihabiskan secara global pada pemrosesan, bandwidth dan penyimpanan agar sistem dapat memproses satu transaksi dan berapa banyak transaksi dapat diproses secara wajar berdasarkan kondisi puncak? Isolatabilitas: Dapat memenuhi kebutuhan yang berbeda-beda pihak dan permohonan ditangani hingga tingkat yang mendekati optimal dalam kerangka yang sama? Pengembangan: Seberapa baik alat tersebut bekerja? Lakukan apakah API memenuhi kebutuhan pengembang? Apakah materi pendidikan tersedia? Apakah ada integrasi yang tepat? Tata Kelola: Dapatkah jaringan tetap fleksibel terhadap berevolusi dan beradaptasi seiring berjalannya waktu? Bisakah keputusan menjadi dibuat dengan inklusivitas, legitimasi dan transparansi untuk memberikan kepemimpinan yang efektif a sistem desentralisasi? Penerapan: Apakah teknologi tersebut benar-benar mampu menjawab kebutuhan yang mendesak? Apakah “perangkat perantara” lain diperlukan untuk menjembatani kesenjangan tersebut aplikasi sebenarnya? Dalam penelitian ini, kami bertujuan untuk mengatasi dua hal pertama masalah: skalabilitas dan isolasi. Meski begitu, kami percaya kerangka Polkadot dapat memberikan perbaikan yang berarti pada setiap kelompok masalah ini. Implementasi blockchain yang modern dan efisien seperti klien Paritas Ethereum [17] dapat memproses lebih dari 3.000 transaksi per detik saat dijalankan pada perangkat keras konsumen yang berkinerja baik. Namun, dunia nyata saat ini blockchain jaringan praktis dibatasi sekitar 30 transaksi per detik. Keterbatasan ini terutama berasal dari kenyataan bahwa mekanisme konsensus sinkron yang ada saat ini memerlukan batas waktu keselamatan yang besar waktu pemrosesan yang diharapkan, yang diperburuk olehPOLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 2 keinginan untuk mendukung implementasi yang lebih lambat. Hal ini disebabkan oleh arsitektur konsensus yang mendasarinya: mekanisme transisi negara, atau cara para pihak berkolaborasi dan mengeksekusi transaksi, logikanya terikat secara fundamental ke dalam mekanisme “kanonikalisasi” konsensus, atau cara yang digunakan para pihak untuk menyepakati salah satu dari beberapa hal mungkin, valid, sejarah. Hal ini berlaku sama untuk sistem proof-of-work (PoW) seperti Bitcoin [15] dan Ethereum [5,23] dan sistem proof-of-stake (PoS) seperti NXT [8] dan Bitshares [12]: semua pada akhirnya menderita cacat yang sama. Ini sederhana strategi yang membantu membuat blockchains sukses. Namun, dengan menggabungkan kedua mekanisme ini secara erat menjadi satu unit protokol, kami juga menggabungkan beberapa protokol yang berbeda aktor dan aplikasi dengan profil risiko berbeda, persyaratan skalabilitas berbeda, dan kebutuhan privasi berbeda. Satu ukuran tidak cocok untuk semua. Seringkali terjadi bahwa dalam a keinginan untuk mendapatkan daya tarik yang luas, suatu jaringan mengadopsi tingkat konservatisme yang menghasilkan kesamaan yang paling rendah secara optimal hanya melayani segelintir orang dan pada akhirnya berujung pada kegagalan dalam kemampuan untuk berinovasi, melakukan dan beradaptasi, terkadang secara dramatis begitu. Beberapa sistem seperti mis. Factom [21] menghilangkan mekanisme transisi status sama sekali. Namun, sebagian besar utilitas yang kita inginkan memerlukan kemampuan keadaan transisi menurut mesin negara bersama. Menjatuhkannya menyelesaikan masalah masalah alternatif; itu tidak memberikan alternatif solusi. Oleh karena itu, tampak jelas bahwa satu arah yang masuk akal untuk dijelajahi sebagai rute menuju komputasi terdesentralisasi yang dapat diskalakan platform adalah untuk memisahkan arsitektur konsensus dari mekanisme transisi negara. Dan, mungkin tidak mengejutkan, ini adalah strategi yang Polkadot terapkan sebagai solusi terhadap skalabilitas. 2.1. Protokol, Implementasi dan Jaringan. Suka Bitcoin dan Ethereum, Polkadot merujuk sekaligus ke protokol jaringan dan protokol utama (yang sampai sekarang dianggap) jaringan publik yang menjalankan protokol ini. Polkadot dimaksudkan sebagai proyek yang bebas dan terbuka, spesifikasi protokol berada di bawah lisensi Creative Commons dan kode ditempatkan di bawah lisensi FLOSS. Proyeknya adalah dikembangkan secara terbuka dan menerima kontribusi dimanapun mereka berguna. Sebuah sistem RFC, tidak berbeda dengan Proposal Peningkatan Python, akan memungkinkan sarana berkolaborasi secara publik atas perubahan dan peningkatan protokol. Implementasi awal kami terhadap protokol Polkadot akan dikenal sebagai Platform Paritas Polkadot dan akan menyertakan implementasi protokol lengkap bersama dengan API ikatan. Seperti implementasi Paritas blockchain lainnya, PPP dirancang untuk menjadi tumpukan teknologi blockchain yang bertujuan umum, tidak khusus untuk jaringan publik maupun untuk operasi swasta/konsorsium. Perkembangannya demikian sejauh ini telah didanai oleh beberapa pihak termasuk melalui hibah dari pemerintah Inggris. Namun makalah ini menjelaskan Polkadot di bawah konteks jaringan publik. Fungsionalitas yang kami bayangkan dalam jaringan publik adalah superset dari apa yang diperlukan dalam jaringan publik pengaturan alternatif (misalnya swasta dan/atau konsorsium). Selanjutnya dalam konteks ini, seluruh cakupan Polkadot bisa diuraikan dan didiskusikan dengan lebih jelas. Ini berarti pembaca harus menyadari bahwa mekanisme tertentu mungkin terjadi dijelaskan (misalnya interoperasi dengan jaringan publik lainnya) yang tidak relevan secara langsung dengan Polkadot ketika digunakan dalam situasi non-publik (“diizinkan”). 2.2. Pekerjaan sebelumnya. Pemisahan konsensus mendasar dari transisi negara telah diusulkan secara informal secara pribadi selama setidaknya dua tahun—Max Kaye adalah pendukung strategi semacam itu pada masa-masa awal Ethereum. Solusi terukur yang lebih kompleks dikenal sebagai Chain fibers, sejak Juni 2014 dan pertama kali diterbitkan kemudian pada tahun 1, mengajukan kasus untuk satu rantai relai dan beberapa rantai homogen yang menyediakan mekanisme eksekusi antar rantai yang transparan. Dekoherensi dibayar melalui latensi transaksi—transaksi yang memerlukan koordinasi bagian-bagian yang berbeda dari sistem akan membutuhkan waktu lebih lama untuk diproses. Polkadot mengambil sebagian besar arsitekturnya dari itu dan percakapan lanjutannya berbagai orang, meskipun desain dan ketentuannya sangat berbeda. Meskipun tidak ada sistem yang sebanding dengan Polkadot sebenarnya dalam produksi, beberapa sistem yang memiliki relevansi tertentu telah diusulkan, meskipun hanya sedikit pada tingkat substansial detail. Proposal ini bisa sajadipecah menjadi sistem yang menjatuhkan atau mengurangi gagasan koheren secara global mesin negara, mereka yang berupaya menyediakan solusi global mesin tunggal yang koheren melalui pecahan homogen dan yang hanya menargetkan heterogenitas. 2.2.1. Sistem tanpa Negara Global. Factom [21] adalah sistem yang menunjukkan kanonikalitas tanpa penyesuaian validitas, secara efektif memungkinkan pencatatan data. Karena penghindaran keadaan global dan kesulitannya dengan penskalaan yang dihasilkannya, ini dapat dianggap sebagai solusi yang terukur. Namun, seperti disebutkan sebelumnya, himpunan masalah yang dipecahkannya jauh lebih kecil dan ketat. Tangle [18] adalah pendekatan baru terhadap sistem konsensus. Daripada mengatur transaksi-transaksi ke dalam blok-blok dan membentuk konsensus mengenai daftar yang saling terkait untuk memberikan tatanan perubahan negara yang kanonik secara global, mereka lebih banyak meninggalkan gagasan tatanan yang sangat terstruktur dan sebaliknya mendorong grafik asiklik terarah dari transaksi dependen dengan item-item selanjutnya yang membantu mengkanonikalisasi item-item sebelumnya melalui referensi eksplisit. Untuk perubahan keadaan yang sewenang-wenang, grafik ketergantungan ini akan dengan cepat menjadi sulit diselesaikan, namun untuk UTXO model2 yang lebih sederhana ini menjadi cukup masuk akal. Karena sistemnya hanya koheren secara longgar dan transaksi pada umumnya independen satu sama lain Di sisi lain, sejumlah besar paralelisme global menjadi hal yang cukup serius alami. Menggunakan model UTXO memang memiliki efek membatasi Tangle pada “mata uang” transfer nilai murni sistem daripada sesuatu yang lebih umum atau diperluas. Terlebih lagi tanpa koherensi global yang sulit, interaksi dengan sistem lain—yang cenderung membutuhkan hal yang mutlak tingkat pengetahuan atas keadaan sistem—menjadi tidak praktis. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2output transaksi yang tidak terpakai, model yang digunakan Bitcoin dimana status secara efektif adalah kumpulan alamat yang terkait dengan beberapa nilai; transaksi menyusun alamat tersebut dan mengubahnya menjadi kumpulan alamat baru yang jumlah totalnya setara

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 3 2.2.2. Sistem Rantai Heterogen. Rantai samping [3] adalah a mengusulkan penambahan protokol Bitcoin yang akan memungkinkan interaksi tanpa kepercayaan antara rantai Bitcoin utama dan rantai samping tambahan. Tidak ada ketentuan untuk apapun tingkat interaksi 'kaya' antar rantai samping: interaksi akan dibatasi hanya pada rantai samping yang memungkinkan adanya penjaga aset masing-masing, yang berdampak—di tingkat lokal jargon—pasak dua arah 3. Visi akhirnya adalah kerangka kerja di mana mata uang Bitcoin dapat disediakan tambahan, jika bersifat periferal, fungsionalitas melalui mengelompokkannya ke beberapa rantai lain dengan transisi keadaan yang lebih eksotis sistem daripada yang diizinkan oleh protokol Bitcoin. Dalam pengertian ini, rantai samping membahas ekstensibilitas daripada skalabilitas. Memang benar, pada dasarnya tidak ada ketentuan mengenai validitas rantai samping; tokens dari satu rantai (misalnya Bitcoin) yang dipegang atas nama rantai samping hanya diamankan oleh kemampuan rantai samping untuk memberi insentif kepada penambang agar melakukan kanonikalisasi transisi yang valid. Keamanan jaringan Bitcoin tidak dapat dengan mudah dialihkan untuk bekerja atas nama orang lain blockchains. Selanjutnya, protokol untuk memastikan Bitcoin penambang menggabungkan-menambang (yaitu menduplikasi kekuatan kanonikalisasi mereka ke dalam rantai samping) dan, yang lebih penting, memvalidasi transisi rantai samping berada di luar ruang lingkup proposal ini. Cosmos [10] adalah sistem multi-rantai yang diusulkan di nada yang sama seperti rantai samping, menukar PoW Nakamoto metode konsensus untuk algoritma Tendermint Jae Kwon. Pada dasarnya, ini menggambarkan banyak rantai (beroperasi di zona) masing-masing menggunakan contoh Tendermint individual, bersama dengan sarana komunikasi bebas kepercayaan melalui a rantai hub utama. Komunikasi antarrantai ini terbatas pada transfer aset digital (“khususnya tentang tokens”) dan bukan informasi sewenang-wenang, namun komunikasi antarrantai tersebut memiliki jalur balik untuk data, misalnya untuk melaporkan kepada pengirim tentang status transfer. Set validator untuk rantai yang dikategorikan, dan khususnya sarana untuk memberikan insentif kepada mereka, seperti rantai samping, masih tersisa sebagai masalah yang belum terselesaikan. Asumsi umumnya adalah demikian setiap rantai yang dikategorikan akan memiliki nilai sebesar token yang inflasinya digunakan untuk membayar validators. Masih dalam tahap awal dari segi desain, saat ini proposal tersebut kurang memiliki rincian komprehensif mengenai cara ekonomi untuk mencapai skalabel kepastian validitas global. Namun, koherensi longgar yang diperlukan antara zona dan hub akan memungkinkan hal ini untuk fleksibilitas tambahan atas parameter yang dikategorikan rantai dibandingkan dengan sistem yang menegakkan lebih kuat koherensi. 2.2.3. Casper. Belum ada tinjauan komprehensif atau perbandingan berdampingan antara Casper [6] dan Polkadot telah dibuat, meskipun seseorang dapat melakukan penyisiran yang cukup besar (dan karenanya tidak akurat) karakterisasi keduanya. Casper adalah konsep ulang tentang bagaimana algoritma konsensus PoS dapat didasarkan pada peserta yang bertaruh pada garpu yang mana pada akhirnya akan menjadi kanonik. Pertimbangan substansial diberikan untuk memastikan bahwa jaringan tersebut kuat fork, meskipun diperpanjang, dan memiliki tingkat skalabilitas tambahan di atas model dasar Ethereum. Sebagai demikian, Casper hingga saat ini cenderung jauh lebih baik protokol yang kompleks dari Polkadot dan pendahulunya, dan a penyimpangan substansial dari format dasar blockchain. Itu masih belum terlihat bagaimana Casper akan mengulanginya di masa depan dan seperti apa tampilannya jika akhirnya diterapkan. Meskipun Casper dan Polkadot keduanya mewakili protokol baru yang menarik dan, dalam beberapa hal, penambahan Ethereum, ada perbedaan besar di antara keduanya tujuan akhir dan jalur menuju penerapan. Casper adalah seorang Ethereum Proyek yang berpusat pada yayasan awalnya dirancang menjadi perubahan PoS pada protokol tanpa keinginan untuk melakukannya buat blockchain yang secara fundamental dapat diskalakan. Yang terpenting, itu benar dirancang untuk menjadi hard-fork, bukan sesuatu yang lebih ekspansif dan dengan demikian semua Ethereum klien dan pengguna akan menjadi diperlukan untuk meningkatkan atau tetap berada pada jalur adopsi yang tidak pasti. Oleh karena itu, penerapannya menjadi lebih sulit karena hal ini melekat pada proyek yang terdesentralisasi koordinasi sangat diperlukan. Polkadot berbeda dalam beberapa hal; pertama dan terpenting, Polkadot dirancang agar dapat diperluas dan diperluas sepenuhnya blockchain uji pengembangan, penerapan, dan interaksi tempat tidur. Ini dibangun untuk menjadi alat pengaman yang mampu bertahan di masa depan mengasimilasi blockchain baruteknologi yang tersedia tanpa koordinasi desentralisasi yang terlalu rumit atau garpu keras. Kami sudah membayangkan beberapa kasus penggunaan seperti itu seperti rantai konsorsium terenkripsi dan rantai frekuensi tinggi dengan waktu blok yang sangat rendah sehingga tidak realistis untuk dilakukan versi masa depan apa pun dari Ethereum yang saat ini direncanakan. Terakhir, hubungan antara itu dan Ethereum sangatlah luar biasa longgar; tidak diperlukan tindakan apa pun dari Ethereum memungkinkan penerusan transaksi tanpa kepercayaan antara keduanya jaringan. Singkatnya, sementara Casper/Ethereum 2.0 dan Polkadot berbagi beberapa kesamaan sekilas yang kami yakini sebagai tujuan akhirnya sangat berbeda dan daripada bersaing, kedua protokol tersebut kemungkinan besar akan hidup berdampingan di bawah a hubungan yang saling menguntungkan di masa mendatang.

Введение

Блокчейны продемонстрировали большие перспективы использования в нескольких областях, включая «Интернет вещей». (IoT), финансы, управление, управление идентификацией, веб-децентрализация и отслеживание активов. Однако, несмотря на технологические обещания и грандиозные разговоры, нам еще предстоит увидеть значительное реальное внедрение современных технологий. Мы считаем, что это связано с пятью ключевыми неудачами нынешней политики. технологические стеки: Масштабируемость: сколько ресурсов тратится по всему миру. об обработке, пропускной способности и хранилище, позволяющем системе обрабатывать одну транзакцию и сколько транзакции могут быть разумно обработаны в соответствии с пиковые условия? Изолируемость: могут ли различающиеся потребности нескольких Стороны и заявления будут рассматриваться в почти оптимальной степени в рамках одних и тех же рамок? Возможность разработки: насколько хорошо работают инструменты? Делай API отвечают потребностям разработчиков? Доступны ли учебные материалы? Есть ли нужные интеграции? Управление: может ли сеть оставаться гибкой для развиваться и адаптироваться с течением времени? Могут ли решения быть сделано с достаточной инклюзивностью, легитимностью и прозрачность для обеспечения эффективного руководства децентрализованная система? Применимость: действительно ли технология сама по себе решает острую потребность? Требуется ли другое «промежуточное программное обеспечение», чтобы устранить разрыв в реальные приложения? В настоящей работе мы стремимся рассмотреть первые два. проблемы: масштабируемость и изоляционность. Тем не менее, мы верим Платформа Polkadot может обеспечить значительные улучшения в каждом из этих классов проблем. Современные эффективные реализации blockchain, такие как клиент четности Ethereum [17] может обрабатывать более 3000 транзакций в секунду при работе на производительном потребительском оборудовании. Однако нынешний реальный мир Сети blockchain практически ограничены примерно 30 транзакций в секунду. Это ограничение главным образом связано с тем, что современные механизмы синхронного консенсуса требуют больших временных запасов безопасности. ожидаемое время обработки, которое усугубляетсяPOLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 2 желание поддерживать более медленные реализации. Это связано с базовая архитектура консенсуса: механизм перехода состояний или средства, с помощью которых стороны сопоставляют информацию и выполнять транзакции, его логика фундаментально связана в консенсусный механизм «канонизации», или средства, с помощью которых стороны договариваются об одном из ряда возможные, действительные, истории. Это в равной степени относится как к системам proof-of-work (PoW), таким как Bitcoin [15] и Ethereum [5,23], так и к системам доказательства ставки (PoS), таким как NXT [8] и Bitshares [12]: все в конечном итоге страдают от одного и того же недостатка. Это простой стратегия, которая помогла blockchains добиться успеха. Однако, за счет тесного соединения этих двух механизмов в единое целое протокола, мы также объединяем несколько различных субъекты и приложения с разными профилями риска, разными требованиями к масштабируемости и разными потребностями в конфиденциальности. Один размер не подходит всем. Слишком часто бывает так, что в Стремясь к широкой привлекательности, сеть принимает определенную степень консерватизма, что приводит к наименьшему общему знаменателю. оптимально обслуживает немногих и в конечном итоге приводит к провалу в способности внедрять инновации, действовать и адаптироваться, иногда резко так. Некоторые системы, такие как, например. Факт [21] полностью отменяет механизм перехода состояний. Однако большая часть полезность, которую мы желаем, требует способности переходного состояния в соответствии с общим конечным автоматом. Удаление решает проблему альтернативная проблема; это не дает альтернативы решение. Таким образом, кажется очевидным, что одно разумное направление изучить как путь к масштабируемым децентрализованным вычислениям платформа заключается в том, чтобы отделить консенсусную архитектуру от механизм перехода состояний. И, возможно, неудивительно, что именно эту стратегию Polkadot использует в качестве решения проблемы масштабируемости. 2.1. Протокол, реализация и сеть. Нравится Bitcoin и Ethereum, Polkadot относятся одновременно к сетевому протоколу и (предполагаемому до сих пор) первичному общедоступная сеть, в которой работает этот протокол. Polkadot задуман как бесплатный и открытый проект, спецификация протокола находится под лицензией Creative Commons, а код размещается под лицензией FLOSS. Проект разрабатывается открыто и принимает вклады где бы они ни были полезны. Система RFC, мало чем отличающаяся от Предложения по усовершенствованию Python, позволят публичное сотрудничество по поводу изменений и обновлений протокола. Наша первоначальная реализация протокола Polkadot будет называться Платформа Parity Polkadot и будет включить полную реализацию протокола вместе с API привязки. Как и другие реализации четности blockchain, PPP представляет собой стек технологий общего назначения blockchain, предназначенный не только для сети общего пользования, но и для частная/консорциумная деятельность. Развитие его таким образом далеко финансируется несколькими сторонами, в том числе через грант британского правительства. Тем не менее, в этой статье Polkadot описывается под контекст публичной сети. Функциональность, которую мы видим в общедоступной сети, представляет собой расширенный набор функций, необходимых в альтернативные (например, частные и/или консорциумные) настройки. Более того, в этом контексте полная область действия Polkadot может быть более четко описаны и обсуждены. Это значит читатель должен знать, что определенные механизмы могут быть описаны (например, взаимодействие с другими общедоступными сетями), которые не имеют прямого отношения к Polkadot при развертывании в закрытых («разрешенных») ситуациях. 2.2. Предыдущая работа. Было неофициально предложено отделить основополагающий консенсус от перехода государства. в частном порядке в течение как минимум двух лет — Макс Кэй был сторонником такой стратегии в самые первые дни Ethereum. Более сложное масштабируемое решение, известное как Chain. волокна, датированные июнем 2014 года и впервые опубликованные позже. в том же году1 обосновал необходимость использования одной релейной цепи и нескольких однородных цепочек, обеспечивающих прозрачный механизм выполнения между цепочками. За декогеренцию заплатили через задержку транзакции — транзакции, требующие координация разрозненных частей системы будет обработка займет больше времени. Polkadot взял большую часть своей архитектуры из этого и последующих разговоров с разные люди, хотя он сильно различается по большей части своей конструкции и положений. Пока нет систем, сравнимых с Polkadot. на самом деле в производстве несколько систем, имеющих какое-то значение были предложены, хотя лишь немногие на сколько-нибудь существенном уровне деталь. Эти предложения могут бытьразбит на системы которые отбрасывают или уменьшают понятие глобально согласованного государственная машина, те, которые пытаются обеспечить глобальную когерентная одноэлементная машина через однородные осколки и те, которые нацелены только на неоднородность. 2.2.1. Системы без глобального состояния. Фактом [21] является система, демонстрирующая каноничность без соответствующего достоверность, что позволяет эффективно вести хронику данных. Из-за избегания глобального состояния и трудностей с учетом масштабирования, которое это дает, это можно считать масштабируемым решением. Однако, как уже говорилось ранее, набор количество проблем, которые он решает, строго и существенно меньше. Клубок [18] — это новый подход к консенсусным системам. Вместо того, чтобы организовывать транзакции в блоки и формировать консенсус по строго связанному списку, чтобы обеспечить глобально канонический порядок изменений состояний, он в значительной степени отказывается от идеи сильно структурированного упорядочения и вместо этого продвигает направленный ациклический граф зависимых транзакций с более поздними элементами, помогая канонизировать более ранние элементы посредством явных ссылок. Для произвольных изменений состояния этот граф зависимостей быстро стал бы неразрешимым, однако для гораздо более простой модели __PH_0006____2 это становится вполне разумно. Поскольку система лишь слабо когерентна, а транзакции, как правило, независимы от каждого с другой стороны, большое количество глобального параллелизма становится вполне натуральный. Использование модели UTXO действительно дает эффект ограничить Tangle чисто «валютой» для передачи ценностей система, а не что-то более общее или расширяемое. Более того, без жесткой глобальной согласованности взаимодействие с другими системами, которые, как правило, требуют абсолютного степень знания состояния системы становится непрактичной. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2вывод неизрасходованных транзакций, модель, которую использует Bitcoin, согласно которой состояние фактически представляет собой набор адресов, связанных с некоторым значением; транзакции сопоставляют такие адреса и преобразуют их в новый набор адресов, общая сумма которых эквивалентна

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 3 2.2.2. Гетерогенные цепные системы. Боковые цепи [3] — это предлагаемое дополнение к протоколу Bitcoin, которое позволит осуществлять доверительное взаимодействие между основной цепочкой Bitcoin и дополнительные боковые цепи. Никакого положения не предусмотрено степень «богатого» взаимодействия между боковыми цепями: взаимодействие будет ограничиваться возможностью хранители активов друг друга, действуя – на местном уровне жаргон — двусторонняя привязка 3. Конечная цель — создать структуру, в которой валюта Bitcoin может быть обеспечена дополнительная, хотя и периферийная, функциональность за счет ее привязки на некоторые другие цепочки с более экзотическим переходом состояний системах, чем позволяет протокол Bitcoin. В этом смысле Боковые цепи ориентированы на расширяемость, а не на масштабируемость. Действительно, принципиально не существует условий для действительности сайдчейнов; tokens из одной цепочки (например, Bitcoin) хранящиеся от имени боковой цепи, защищены только способность сайдчейна стимулировать майнеров к канонизации действительные переходы. Безопасность сети Bitcoin не может быть легко переведен на работу от имени других blockchainс. Кроме того, протокол обеспечения Bitcoin майнеры объединяют майнинг (то есть дублируют свои возможности канонизации на мощности боковой цепи) и, что более важно, подтверждают, что переходы боковой цепи находятся за пределами объем этого предложения. Cosmos [10] — это предлагаемая многоцепная система в то же самое, что и сайдчейны, заменяя PoW Накамото метод консенсуса для алгоритма Tendermint Джэ Квона. По сути, он описывает несколько цепочек (работающих в зоны), каждая из которых использует отдельные экземпляры Tendermint вместе со средствами доверительной связи через главная ступичная цепь. Эта межцепочная связь ограничивается передачей цифровых активов («в частности, около 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 не требуется, чтобы включить бездоверительную пересылку транзакций между двумя сети. Короче говоря, пока Каспер/Ethereum 2.0 и Polkadot поделиться некоторыми мимолетными сходствами, которые, как мы считаем, являются конечной целью существенно отличается и что вместо того, чтобы конкурировать, эти два протокола, вероятно, в конечном итоге будут сосуществовать под взаимовыгодные отношения в обозримом будущем.

Ringkasan

Polkadot adalah multi-rantai heterogen yang dapat diskalakan. Ini artinya tidak seperti implementasi blockchain sebelumnya yang berfokus pada penyediaan satu rantai yang bervariasi tingkat keumuman atas penerapan potensial, Polkadot itu sendiri dirancang untuk tidak menyediakan fungsionalitas aplikasi bawaan sama sekali. Sebaliknya, Polkadot menyediakan batuan dasar "rantai relai" yang menjadi dasar sejumlah besar validasi, struktur data dinamis yang koheren secara global dapat dihosting berdampingan. Kami menyebut struktur data ini “paralel” rantai atau parachain, meskipun tidak ada kebutuhan khusus untuk itu mereka menjadi blockchain di alam. Dengan kata lain, Polkadot dapat dianggap setara dengan himpunan rantai independen (misalnya himpunan yang berisi Ethereum, Ethereum Klasik, Namecoin dan Bitcoin) kecuali dua poin yang sangat penting: • Keamanan gabungan; • kemampuan transaksi antar rantai yang bebas kepercayaan. Poin-poin inilah yang menjadi alasan kami menganggap Polkadot “dapat diskalakan”. Pada prinsipnya, masalah yang akan diterapkan pada Polkadot mungkin secara substansial diparalelkan—diperluas—di atas sejumlah besar parachain. Karena semua aspek masing-masing parachain dapat dilakukan secara paralel oleh segmen berbeda dari jaringan Polkadot, sistem memiliki beberapa kemampuan untuk menskalakan. Polkadot memberikan gambaran yang sederhana 3sebagai lawan dari pasak satu arah yang pada dasarnya adalah tindakan menghancurkan tokens dalam satu rantai untuk membuat tokens di rantai lain tanpa mekanisme untuk melakukan kebalikannya untuk memulihkan tokens yang asliPOLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 4 infrastruktur meninggalkan banyak kompleksitas yang harus ditangani pada tingkat middleware. Ini adalah keputusan sadar yang dimaksudkan untuk mengurangi risiko pembangunan, sehingga memungkinkan perangkat lunak yang diperlukan untuk dikembangkan dalam rentang waktu singkat dan dengan tingkat keyakinan yang baik atas keamanannya dan ketahanan. 3.1. Filosofi Polkadot. Polkadot seharusnya memberikan landasan yang kuat untuk melakukan hal tersebut membangun gelombang sistem konsensus berikutnya spektrum risiko dari desain matang yang mampu berproduksi pada ide-ide yang baru lahir. Dengan memberikan jaminan yang kuat atas keamanan, isolasi dan komunikasi, Polkadot dapat memungkinkan parachains untuk memilih dari berbagai properti itu sendiri. Memang benar, kami memperkirakan berbagai blockchain eksperimental mendorong sifat-sifat yang dianggap masuk akal hari ini. Kami melihat konservatif, rantai bernilai tinggi serupa dengan Bitcoin atau Z-cash [20] hidup berdampingan dengan nilai yang lebih rendah “rantai tema” (pemasaran seperti itu, sangat menyenangkan) dan jaringan pengujian dengan biaya nol atau mendekati nol. Kami melihat terenkripsi sepenuhnya, “gelap”, rantai konsorsium yang beroperasi berdampingan—dan bahkan menyediakan layanan ke—rantai yang sangat fungsional dan terbuka seperti yang seperti Ethereum. Kami melihat eksperimen baru Rantai berbasis VM seperti wasm bermuatan waktu subjektif rantai digunakan sebagai sarana untuk melakukan outsourcing masalah komputasi yang sulit dari rantai yang lebih matang seperti Ethereum atau rantai mirip Bitcoin yang lebih terbatas. Untuk mengelola peningkatan rantai, Polkadot akan secara inheren mendukung semacam struktur tata kelola, yang mungkin berbasis pada sistem politik stabil yang ada dan memiliki aspek bikameral yang mirip dengan Dewan Kertas Kuning [24]. Sebagai otoritas tertinggi, pemegang saham token yang mendasarinya akan memiliki kendali “referendum”. Untuk mencerminkan pengguna kebutuhan akan pembangunan namun kebutuhan pengembang akan legitimasi, kami berharap akan terbentuknya arah yang masuk akal dua kamar dari komite "pengguna" (terdiri dari terikat validators) dan komite “teknis” dibentuk pengembang klien besar dan pemain ekosistem. Itu badan pemegang token akan mempertahankan legitimasi tertinggi dan membentuk mayoritas super untuk menambah, mengubah parameter, mengganti atau membubarkan struktur ini, sesuatu yang kami jangan meragukan kebutuhan akhir akan hal ini: seperti kata Twain “Pemeran dan popok harus sering diganti, dan untuk itu alasan yang sama”. Meskipun reparameterisasi biasanya mudah dilakukan dalam mekanisme konsensus yang lebih besar, perubahan yang lebih kualitatif seperti penggantian dan augmentasi dapat dilakukan mungkin perlu berupa “keputusan lunak” yang tidak otomatis (mis. melalui kanonikalisasi nomor blok dan hash dari dokumen yang secara resmi menetapkan protokol baru) atau mengharuskan mekanisme konsensus inti untuk memuat a bahasa yang cukup kaya untuk menggambarkan aspek apa pun dari dirinya sendiri yang mungkin perlu diubah. Yang terakhir adalah tujuan akhirnya, Namun, yang pertama lebih mungkin untuk dipilih memfasilitasi jadwal pengembangan yang masuk akal. Prinsip utama Polkadot dan aturan di dalamnya kami mengevaluasi semua keputusan desain adalah: Minimal: Polkadot harus memiliki fungsionalitas sesedikit mungkin. Sederhana: tidak ada kerumitan tambahan yang harus ada dalam protokol dasar daripada yang seharusnya dimuat ke dalam middleware, ditempatkan melalui a parachain atau diperkenalkan dalam optimasi selanjutnya. Umum: tidak ada persyaratan yang tidak perlu, kendala atau pembatasan harus diterapkan pada parachain; Polkadot harus menjadi tempat uji coba untuk pengembangan sistem konsensus yang dapat dioptimalkan melalui membuat model yang sesuai dengan ekstensinya se-abstrak mungkin. Kuat: Polkadot harus memberikan dasar yang mendasar lapisan dasar yang stabil. Selain kesehatan ekonomi, hal ini juga berarti desentralisasi untuk meminimalkan vektor untuk serangan dengan imbalan tinggi.

Краткое содержание

Polkadot — это масштабируемая гетерогенная мультицепочка. Это означает, что в отличие от предыдущих реализаций blockchain которые сосредоточились на обеспечении единой цепочки различных степени общности потенциальных приложений, Polkadot сам по себе не предназначен для обеспечения каких-либо встроенных функций приложения. Скорее, Polkadot обеспечивает основу «релейная цепочка», на которой большое количество проверяемых, глобально-когерентные динамические структуры данных могут размещаться бок о бок. Мы называем эти структуры данных «параллельными». цепочки или парацепи, хотя особой необходимости в них нет. они должны быть blockchain по своей природе. Другими словами, Polkadot можно считать эквивалентным набору независимых цепочек (например, набору, содержащему Ethereum, Ethereum Classic, Namecoin и Bitcoin), за исключением двух очень важных моментов: • Объединенная безопасность; • межцепочечная транзакция без доверия. Именно по этим причинам мы считаем Polkadot «масштабируемым». В принципе, задача, которая будет развернута на Polkadot, может быть существенно распараллелена — масштабирована — через большое количество парачейнов. Поскольку все аспекты каждого парачейн может проводиться параллельно разными сегментами сети Polkadot, система имеет некоторую возможность масштабировать. Polkadot представляет собой довольно простой фрагмент 3в отличие от односторонней привязки, которая по сути представляет собой действие по уничтожению token в одной цепочке для создания token в другой без механизм, позволяющий сделать обратное, чтобы восстановить исходные tokensPOLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 4 инфраструктура, оставляя большую часть сложностей решать на уровне промежуточного программного обеспечения. Это сознательное решение, направленное на снижение риска развития, позволяющее необходимое программное обеспечение, которое будет разработано в короткие сроки и с хорошим уровнем уверенности в своей безопасности и надежность. 3.1. Философия Polkadot. Polkadot должен обеспечить абсолютную прочную основу для построить следующую волну консенсусных систем, вплоть до спектр рисков от готовых к производству зрелых проектов к зарождающимся идеям. Предоставляя надежные гарантии безопасности, изоляции и связи, Polkadot может позволить парачейны для самостоятельного выбора из ряда свойств. Действительно, мы предвидим, что различные экспериментальные blockchain будут расширять свойства того, что можно было бы считать разумным. сегодня. Мы видим консерваторов, цепочки высокой добавленной стоимости, подобные Bitcoin или Z-cash PH_0000, сосуществующие рядом с более низкой стоимостью «тема-цепочки» (такой маркетинг, так весело) и тест-сети с нулевой или близкой к нулевой комиссией. Мы видим полностью зашифрованные, «темные» сети консорциумов, действующие бок о бок – и даже предоставление услуг — высокофункциональным и открытым цепочкам например, Ethereum. Мы видим экспериментальные новинки Цепочки на основе виртуальных машин, такие как субъективный васм с оплатой по времени цепочка используется как средство передачи сложных вычислительных задач на аутсорсинг из более зрелой цепочки, подобной Ethereum. или более ограниченную цепочку, подобную Bitcoin. Для управления обновлениями цепочки Polkadot по своей сути будет поддерживать некую структуру управления, вероятно, основанную на существующих стабильных политических системах и имеет двухпалатный аспект, аналогичный Совету «Желтой книги» [24]. Как высший орган власти, базовые держатели token будут иметь контроль «референдума». Чтобы отразить мнение пользователей потребность в развитии, но потребность разработчиков в легитимности, мы ожидаем, что разумным направлением будет формирование две палаты из комитета «пользователей» (состоящего из облигационные validators) и «технический» комитет, составленный крупных разработчиков клиентов и игроков экосистемы.

группа владельцев token будет сохранять максимальную легитимность и формировать сверхбольшинство для расширения, изменения параметров, замены или роспуска этой структуры, что мы и делаем. не сомневайтесь в возможной необходимости: по словам Твена «Правительства и подгузники надо менять часто, а для та же причина». В то время как репараметризацию обычно легко организовать в рамках более крупного механизма консенсуса, более качественные изменения, такие как замена и дополнение, могли бы быть осуществлены. вероятно, потребуются либо неавтоматизированные «мягкие указы» (например, посредством канонизации номера блока и hash документа, официально определяющего новый протокол) или сделать необходимым наличие основного механизма консенсуса для сдерживания достаточно богатый язык, чтобы описать любой аспект самого себя который, возможно, придется изменить. Последнее является конечной целью, однако первое, скорее всего, будет выбрано для того, чтобы обеспечить разумные сроки разработки. Основные принципы Polkadot и правила, в соответствии с которыми мы оцениваем все проектные решения: Минимально: Polkadot должен иметь как можно меньше функций. Просто: никаких дополнительных сложностей быть не должно. в базовом протоколе, чем это может быть разумно выгружается в промежуточное программное обеспечение, размещенный через parachain или введен в более поздней оптимизации. Общие сведения: нет ненужных требований и ограничений. или ограничения должны быть наложены на парачейны; Polkadot должен стать испытательной площадкой для разработки системы консенсуса, которую можно оптимизировать с помощью сделать модель, в которую вписываются расширения, максимально абстрактной. Надежный: Polkadot должен обеспечивать фундаментальную стабильный базовый слой. Помимо экономической устойчивости, это также означает децентрализацию с целью минимизации векторы для атак с высокой наградой.

Partisipasi dalam Polkadot

Ada empat peran dasar dalam pemeliharaan Polkadot jaringan: kolator, nelayan, nominator dan validator. Di satu kemungkinan penerapan Polkadot, peran terakhir sebenarnya dapat dipecah menjadi dua peran: validator dasar dan penjamin ketersediaan; ini dibahas di bagian 6.5.3. Pengumpul Nelayan Validator (grup ini) Validator (kelompok lain) menyetujui menjadi monitor laporan buruk perilaku ke menyediakan blok kandidat untuk Nominator Gambar 1. Interaksi antar empat peran Polkadot. 4.1. Validator. validator adalah tagihan tertinggi dan membantu menyegel blok baru di jaringan Polkadot. Peran validator bergantung pada ikatan yang cukup tinggi dititipkan, meskipun kami mengizinkan pihak lain yang terikat untuk itu mencalonkan satu atau lebih validator untuk bertindak mewakili mereka dan sebagai sebagian dari obligasi validator tersebut belum tentu dimiliki oleh validator itu sendiri melainkan oleh mereka nominasi. validator harus menjalankan implementasi klien rantai relai dengan ketersediaan dan bandwidth tinggi. Di setiap blok node harus siap menerima peran ratifikasi blok baru pada parachain yang dinominasikan. Proses ini melibatkan penerimaan, validasi, dan penerbitan ulang kandidat blok. Pencalonannya bersifat deterministik namun hampir tidak dapat diprediksi sebelumnya. Karena validator tidak bisa cukup diharapkan untuk mempertahankan sinkronisasi penuh database semua parachain, diharapkan validator akan menominasikan tugas merancang usulan baru blok parachain ke pihak ketiga, yang dikenal sebagai collator. Setelah semua blok parachain baru telah diratifikasi dengan benar oleh subkelompok validator yang ditunjuk, validators kemudian harus meratifikasi blok rantai relai itu sendiri. Ini melibatkan memperbarui keadaan antrian transaksi (pada dasarnya memindahkan data dari antrean keluaran parachain ke antrean keluaran lainnya antrian input parachain), memproses transaksi rangkaian transaksi rantai relai yang diratifikasi dan meratifikasinya blok terakhir, termasuk perubahan parachain terakhir.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 5 validator tidak memenuhi tugas mereka untuk menemukan konsensus berdasarkan aturan algoritma konsensus yang kami pilih akan dihukum. Untuk kegagalan awal yang tidak disengaja, ini sudah selesai menahan hadiah validator. Kegagalan yang berulang mengakibatkan berkurangnya jaminan keamanan mereka (melalui pembakaran). Tindakan yang terbukti berbahaya seperti penandatanganan ganda atau bersekongkol untuk memberikan blok yang tidak valid mengakibatkan hilangnya seluruh obligasi (yang sebagian terbakar tetapi sebagian besar diberikan kepada informan dan pelaku yang jujur). Dalam beberapa hal, validator mirip dengan kumpulan penambangan dari PoW saat ini blockchains. 4.2. Nominator. Nominator adalah pihak yang memegang saham yang berkontribusi pada jaminan keamanan validator. Mereka tidak mempunyai peran tambahan kecuali menempatkan modal risiko dan sebagai seperti itu untuk menandakan bahwa mereka memercayai validator tertentu (atau kumpulannya) untuk bertindak secara bertanggung jawab dalam pemeliharaannya jaringan. Mereka menerima kenaikan atau pengurangan pro-rata dalam deposito mereka sesuai dengan pertumbuhan obligasi yang mana mereka berkontribusi. Bersama dengan kolator, selanjutnya ada nominator di beberapa mirip dengan para penambang jaringan PoW saat ini. 4.3. Kolator. Pengumpul transaksi (disingkat pengumpul) adalah pihak-pihak yang membantu validators dalam memproduksi sah blok parachain. Mereka mempertahankan “simpul penuh” untuk parachain tertentu; artinya mereka menyimpan semua yang diperlukan informasi untuk dapat menulis blok baru dan mengeksekusi transaksi dengan cara yang hampir sama seperti yang dilakukan penambang pada PoW blockchains saat ini. Dalam keadaan normal, mereka akan menyusun dan mengeksekusi transaksi untuk membuat yang tidak tersegel memblokir, dan menyediakannya, bersama dengan pengetahuan nol buktinya, kepada satu atau lebih validator yang saat ini menjadi tanggung jawabnya mengusulkan blok parachain. Sifat sebenarnya dari hubungan antara kolator, nominator, dan validator kemungkinan akan berubah seiring berjalannya waktu. waktu. Awalnya, kami mengharapkan kolator bekerja sangat erat dengan validators, karena hanya akan ada sedikit (mungkin hanya satu) parachain dengan volume transaksi kecil. Itu implementasi klien awal akan mencakup RPC untuk memungkinkan a node pengumpul parachain untuk memasok node (relaychain) validator tanpa syarat dengan parachain yang terbukti valid blok. Sebagai biaya pemeliharaan versi yang disinkronkan semua parachain tersebut meningkat, kami memperkirakan akan ada peningkatan tambahan infrastruktur yang ada yang akan membantu memisahkan kewajiban kepada pihak-pihak yang independen dan bermotivasi ekonomi. Pada akhirnya, kami berharap untuk melihat kumpulan kolator yang bersaing mengumpulkan biaya transaksi terbanyak. Kolektor tersebut dapat dikontrak untuk melayani validator tertentu selama jangka waktu tertentu untuk mendapatkan bagian berkelanjutan dari hasil hadiah. Alternatifnya, kolator “freelance” mungkin saja membuat a pasar menawarkan blok parachain yang valid dengan imbalan bagian kompetitif dari hadiah yang dibayarkan segera. Demikian pula, kumpulan nominator yang terdesentralisasi akan memungkinkan banyak nominasi peserta terikat untuk berkoordinasi dan berbagi tugas a validator. Kemampuan untuk menyatukan ini memastikan partisipasi terbuka mengarah pada sistem yang lebih terdesentralisasi. 4.4. Nelayan. Berbeda dengan dua partai aktif lainnya, nelayan tidak mempunyai hubungan langsung dengan pembuat blok proses. Sebaliknya mereka adalah “pemburu hadiah” yang mandiri. termotivasi oleh imbalan satu kali yang besar. Justru karena keberadaan nelayan, kami perkirakan kejadian-kejadian buruk jarang terjadi, dan bila hal itu terjadi hanya karena pihak yang terikat ceroboh dengan pengamanan kunci rahasia, bukan melalui niat jahat. Nama itu datang mulai dari frekuensi imbalan yang diharapkan, persyaratan minimal untuk ikut serta, dan besaran imbalan pada akhirnya. Nelayan mendapatkan imbalannya melalui bukti yang tepat waktu setidaknya satu pihak yang terikat bertindak secara ilegal. Tindakan ilegal termasuk menandatangani dua blok masing-masing dengan induk yang sama yang telah diratifikasi atau, dalam kasus parachains, membantu meratifikasi perjanjian yang tidak sah blok. Untuk mencegah pemberian imbalan yang berlebihan atau kompromi dan penggunaan kunci rahasia suatu sesi secara tidak sah, yang merupakan imbalan dasar memberikan satu pesan validator yang ditandatangani secara ilegal adalah minimal. Hadiah ini meningkat secara asimtotik seiring bertambahnya jumlah menguatkan tanda tangan ilegal dari validator lainnya asalkan menyiratkan serangan asli. Asimtotnya sudah diatur setidaknya sebesar 66% mengikuti pernyataan keamanan dasar kami dua pertiga dari validator bertindak baik hati. Nelayan agak mirip dengan “simpul penuh” di sistem blockchain saat ini yang membutuhkan sumber daya relatif kecil dan komitmen uptime yang stabil dan bandwidth tidak diperlukan. Nelayan berbeda dalam hal ini sebanyak mereka harus mengirimkan obligasi kecil.Ikatan ini mencegah serangan sybil karena membuang-buang waktu dan komputasi validators sumber daya. Ini dapat segera ditarik, mungkin tidak lebih dari setara dengan beberapa dolar dan dapat menyebabkan untuk menuai imbalan besar karena menemukan perilaku buruk validator.

Участие в Polkadot

В обслуживании Polkadot есть четыре основные роли. сеть: сборщик, рыбак, номинатор и validator. В одна возможная реализация Polkadot, последняя роль на самом деле может быть разбит на две роли: базовый validator и гарант доступности; это обсуждается в разделе 6.5.3. подборщик Рыбак Валидаторы (эта группа) Валидаторы (другие группы) одобряет становится мониторы отчеты плохой поведение к обеспечивает блокировку кандидаты для номинатор Рисунок 1. Взаимодействие между четыре роли Polkadot. 4.1. Валидаторы. validator — это самая высокая плата и помогает запечатать новые блоки в сети Polkadot. Роль validator зависит от достаточно высокой связи. депонируются, хотя мы разрешаем другим связанным сторонам назначить одного или нескольких validators, которые будут действовать от их имени и как такая некоторая часть облигации validator не обязательно может принадлежать самому validator, а скорее этим номинаторы. validator должен запускать реализацию клиента ретрансляционной цепочки с высокой доступностью и пропускной способностью. В каждом блоке узел должен быть готов принять роль ратифицирующего новый блок в назначенном парачейне. Этот процесс включает получение, проверку и повторную публикацию кандидата блоки. Номинация является детерминированной, но практически непредсказуемой заранее. Поскольку validator не может разумно ожидать поддержания полностью синхронизированного базе данных всех парачейнов, ожидается, что validator поставит перед собой задачу разработать предлагаемую новую блок парачейна третьей стороне, известной как сопоставление. Как только все новые блоки парачейна будут должным образом ратифицированы назначенными ими подгруппами validator, validators затем должен ратифицировать сам блок релейной цепи. Это включает в себя обновление состояния очередей транзакций (по сути перемещение данных из очереди вывода парачейна в другую входная очередь парачейна), обработка транзакций ратифицированный набор транзакций релейной цепи и ратификация финальный блок, включая окончательные изменения парачейна.POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 5 validator не выполняет свою обязанность по поиску консенсуса по правилам выбранного нами алгоритма консенсуса наказывается. В случае первоначальных непреднамеренных сбоев это происходит через удержание вознаграждения validator. Повторные сбои приводят к снижению их залога безопасности (за счет сжигания). Доказуемо вредоносные действия, такие как двойное подписание или сговор с целью предоставления недействительного блока приведет к потере вся связь (которая частично сгорела, но в основном отдана информатору и честным актерам). В некотором смысле validator похожи на пулы для майнинга. текущего PoW blockchains. 4.2. Номинаторы. Номинатор является стороной, владеющей долей который вносит свой вклад в залог validator. Они не имеют никакой дополнительной роли, кроме размещения рискового капитала и например, чтобы сигнализировать о том, что они доверяют конкретному validator (или их набор) действовать ответственно при поддержании сеть. Они получают пропорциональное увеличение или сокращение в свой депозит в зависимости от роста облигации, к которой они вносят свой вклад. Вместе с сопоставителями, далее в некоторых смысл аналогичен майнерам современных сетей PoW. 4.3. Подборщики. Сопоставители транзакций (сокращенно сопоставители) являются сторонами, которые помогают validators в составлении действительных блоки парачейна. Они поддерживают «полный узел» для конкретного парачейна; это означает, что они сохраняют все необходимое информация, позволяющая создавать новые блоки и выполнять транзакции почти так же, как это делают майнеры на текущих PoW blockchain. В обычных обстоятельствах они будет сопоставлять и выполнять транзакции для создания незапечатанного заблокировать и предоставить его вместе с функцией с нулевым разглашением доказательство одному или нескольким validators, в настоящее время ответственным за Предлагаю блок парачейна. Точный характер взаимоотношений между сопоставителями, номинаторами и validator, скорее всего, изменится со временем. время. Первоначально мы ожидаем, что подборщики будут работать очень тесно. с validators, так как их будет всего несколько (возможно только один) парачейн(ы) с небольшим объемом транзакций. первоначальная реализация клиента будет включать RPC, позволяющие узел сопоставления парачейна для безусловного предоставления узлу (релейной цепи) validator доказуемо действующего парачейна блок. Поскольку стоимость поддержки синхронизированной версии количество таких парачейнов увеличивается, мы ожидаем увидеть дополнительные наличие инфраструктуры, которая поможет отделить обязанности перед независимыми, экономически мотивированными сторонами. В конце концов, мы ожидаем увидеть пулы сопоставителей, которые соперничают за собирать максимальную комиссию за транзакции. С такими сборщиками может быть заключен контракт на обслуживание определенных validator в течение определенного периода времени с целью получения постоянной доли в доходах от вознаграждения. Альтернативно, «внештатные» подборщики могут просто создать рынок, предлагающий действительные блоки парачейна в обмен на конкурентоспособную долю вознаграждения, подлежащую немедленной выплате. Аналогичным образом, децентрализованные пулы номинаторов позволят множеству связанные участники координировать и разделять обязанности validator. Эта возможность объединения обеспечивает открытое участие. что приведет к более децентрализованной системе. 4.4. Рыбаки. В отличие от двух других активных партий, рыбаки не имеют прямого отношения к авторству блока процесс. Скорее они независимые «охотники за головами». мотивировано большой разовой наградой. Именно из-за существования рыбаков, мы ожидаем, что случаи плохого поведения будут происходить редко, а когда они происходят только из-за связанная сторона небрежна с безопасностью секретного ключа, а не со злым умыслом. Имя приходит от ожидаемой частоты вознаграждений, минимальных требований для участия и возможного размера вознаграждения. Рыбаки получают вознаграждение, если своевременно докажут, что по крайней мере одна связанная сторона действовала незаконно. Незаконные действия включать подписание двух блоков, каждый с одним и тем же ратифицированным родителем или, в случае парачейнов, помощь в ратификации недействительного блок. Чтобы предотвратить чрезмерное вознаграждение или компромисс и незаконное использование секретного ключа сеанса, базовая награда за предоставление одного незаконно подписанного сообщения validator является минимальный. Эта награда асимптотически возрастает по мере увеличения подтверждающие незаконные подписи других validator если это подразумевает настоящее нападение. Асимптота задана на 66 %, следуя нашему базовому утверждению безопасности, что по крайней мере две трети validator действуют доброжелательно. Рыбаки чем-то похожи на «полные узлы» в современные blockchain системы, необходимые ресурсы относительно небольшие и обеспечивают стабильное время безотказной работы и пропускная способность не обязательна. Рыбаки отличаются друг от друга так же, как они должны внести небольшой залог.Эта связь предотвращает Сивилла атакует, тратя validators время и вычислительные ресурсы ресурсы. Его сразу можно снять, наверное нет превышает сумму, эквивалентную нескольким долларам, и может привести получить огромную награду за обнаружение ненадлежащего поведения validator.

Ikhtisar Desain

Bagian ini dimaksudkan untuk memberikan gambaran singkat tentang sistem secara keseluruhan. Eksplorasi yang lebih menyeluruh terhadap sistem diberikan pada bagian berikutnya. 5.1. Konsensus. Pada rantai relai, Polkadot tercapai konsensus tingkat rendah atas seperangkat valid yang disepakati bersama blok melalui algoritma toleransi kesalahan Bizantium asinkron (BFT) modern. Algoritmanya akan terinspirasi dengan Tendermint sederhana [11] dan masih banyak lagi melibatkan HoneyBadgerBFT [14]. Yang terakhir menyediakan konsensus yang efisien dan toleran terhadap kesalahan atas keputusan yang sewenang-wenang infrastruktur jaringan yang rusak, mengingat sebagian besar otoritas yang baik atau validators. Untuk jaringan bergaya proof-of-authority (PoA), ini saja akan mencukupi, namun Polkadot dibayangkan juga dapat digunakan sebagai jaringan secara terbuka dan publik situasi tanpa organisasi tertentu atau terpercaya wewenang yang diperlukan untuk memeliharanya. Oleh karena itu kita memerlukan a cara untuk menentukan serangkaian validator dan pemberian insentif mereka jujur. Untuk ini kami menggunakan seleksi berbasis PoS kriteria. 5.2. Membuktikan Taruhannya. Kami berasumsi bahwa jaringan akan memiliki beberapa cara untuk mengukur berapa banyak “taruhan” dimiliki oleh akun tertentu. Untuk kemudahan perbandingan dengan sistem yang sudah ada sebelumnya, kita sebut satuan pengukuran “tokens”. Sayangnya istilah tersebut kurang ideal untuk a sejumlah alasan, paling tidak karena hanya skalar nilai yang terkait dengan akun, tidak ada gagasan tentangnya individualitas. Kami membayangkan validators terpilih, jarang sekali (paling banyak sekali per hari tetapi mungkin jarang sekali per kuartal), melalui skema Nominated Proof-of-Stake (NPoS). Insentivisasi dapat terjadi melalui alokasi pro-rataPOLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 6 Relai rantai Kawanan validator (masing-masing diwarnai menurut warnanya parachain yang ditunjuk) Transaksi (dikirim oleh aktor eksternal) Parachain jembatan Parachain virtual (misalnya Ethereum) Parachain Parachain antrian dan I/O Transaksi yang disebarkan Blokir pengajuan kandidat pesanan ke-2 Rantai relai Komunitas parachain Akun Transaksi masuk Transaksi keluar Transaksi antar rantai (dikelola oleh validators) Pengumpul Blok yang disebarkan Nelayan Gambar 2. Skema ringkasan sistem Polkadot. Hal ini menunjukkan kolektor mengumpulkan dan menyebarkan transaksi pengguna, serta menyebarkan kandidat blok ke nelayan dan validators. Itu juga menunjukkan bagaimana sebuah akun dapat memposting transaksi yang dilakukan dari parachainnya, melalui rantai relai dan masuk ke parachain lain yang bisa diartikan sebagai transaksi ke akun disana. dana yang berasal dari perluasan basis token (hingga 100% per tahun, meskipun kemungkinan besar sekitar 10%) bersama dengan biaya transaksi apa pun yang dikumpulkan. Meskipun ekspansi basis moneter biasanya menyebabkan inflasi, karena semua pemilik token akan memiliki kesempatan yang adil untuk berpartisipasi, tidak ada pemegang token yang perlu mengalami pengurangan nilai kepemilikan dari waktu ke waktu asalkan mereka senang untuk mengambil a peran dalam mekanisme konsensus. Proporsi tertentu dari tokens akan ditargetkan untuk proses staking; itu perluasan basis token yang efektif akan disesuaikan mekanisme berbasis pasar untuk mencapai target ini. Validator sangat terikat dengan taruhannya; keluar Obligasi validators tetap berlaku lama setelah tugas validators dihentikan (mungkin sekitar 3 bulan). Selama ini periode likuidasi obligasi memungkinkan terjadinya perilaku buruk di masa depan dihukum sampai pos pemeriksaan berkala rantai. Perilaku buruk menghasilkan hukuman, seperti pengurangan imbalan atau, dalam kasus yang dengan sengaja membahayakan integritas jaringan, validator kehilangan sebagian atau seluruhnya kepentingan kepada validator lain, informan atau pemangku kepentingan secara keseluruhan (melalui pembakaran). Misalnya, validator yang mencoba untuk meratifikasi kedua cabang percabangan (terkadang dikenal sebagai serangan “jarak pendek”) dapat diidentifikasi dan dihukum dengan cara yang terakhir. Serangan jangka panjang “tidak ada yang dipertaruhkan”4 dapat dielakkan melalui kaitan “pos pemeriksaan” sederhana yang mencegah terjadinya reorganisasi berantai yang berbahaya selama lebih dari satu tahun. kedalaman rantai tertentu. Untuk memastikan klien yang baru disinkronkan tidak bisa tertipu ke rantai yang salah, biasa “hard fork” akan terjadi (paling lama pada periode yang sama). validators (likuidasi obligasi) yang memblok pos pemeriksaan terbaru dengan kode keras hashes ke klien. Hal ini cocok dengan ukuran “panjang rantai terbatas” yang dapat mengurangi jejak lebih lanjut pengaturan ulang blok genesis secara berkala. 5.3. Parachain dan Collator. Setiap parachain mendapat perlengkapan keamanan serupa dengan rantai relai: itu header parachain disegel di dalam blok rantai relai memastikan tidak ada reorganisasi, atau “pembelanjaan ganda”, yang mungkin terjadi setelah konfirmasi. Ini adalah jaminan keamanan serupa dengan yang ditawarkan oleh rantai samping dan penggabungan Bitcoin. Namun, Polkadot juga memberikan jaminan kuat bahwa transisi status parachain adalah valid. Ini terjadi melalui himpunan validator yang disegmentasikan secara kriptografis secara acak menjadi himpunan bagian; satu subset per parachain, subset berpotensi berbeda per blok. Ini pengaturan umumnya menyiratkan bahwa waktu blok parachain akan demikian setidaknya sepanjang rantai relai. Yang spesifik cara menentukan partisi berada di luar cakupan 4Serangan seperti itu adalah saat musuh membentuk rantai sejarah yang benar-benar baru mulai dari blok genesis dan seterusnya. Melalui pengendalian a dengan porsi saham yang relatif kecil pada saat offset, mereka dapat secara bertahap meningkatkan porsi saham mereka dibandingkan dengan semua saham lainnya. pemangku kepentingan karena mereka adalah satu-satunya peserta aktif dalam sejarah alternatif mereka. Karena tidak ada batasan fisik yang hakiki dalam penciptaan blok (tidak seperti PoW di mana energi komputasi yang cukup nyata harus dikeluarkan), mereka mampu membuat rantai yang lebih panjang dari rantai sebenarnya dalam waktu singkat. rentang waktu yang relatif singkat dan berpotensi menjadikannya yang terlama dan terbaik, mengambil alih status kanonik jaringan.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 7 dokumen ini tetapi kemungkinan besar akan didasarkan pada hal tersebut kerangka komit-pengungkapan yang mirip dengan RanDAO [19] atau menggunakan data yang digabungkan dari blok sebelumnya dari setiap parachain di bawah hash yang aman secara kriptografis. Subkumpulan validators tersebut diperlukan untuk menyediakan a kandidat blok parachain yang dijamin valid (on rasa sakit karena penyitaan obligasi). Validitas berkisar pada dua poin penting; pertama bahwa hal itu secara intrinsik valid—itu semua transisi negara dilaksanakan dengan setia dan itu saja data eksternal yang direferensikan (yaitu transaksi) valid untuk dimasukkan. Kedua, data apa pun yang bersifat ekstrinsik kandidat, seperti transaksi eksternal tersebut, memiliki ketersediaan yang cukup tinggi sehingga peserta dapat melakukannya unduh dan jalankan blok secara manual.5 Validator mungkin hanya menyediakan blok “null” yang tidak berisi data “transaksi” eksternal, namun berisiko mendapatkan pengurangan reward jika mereka memberikannya. Mereka bekerja berdampingan protokol gosip parachain dengan kolator—individu yang menyusun transaksi ke dalam blok dan memberikan bukti non-interaktif dan tanpa pengetahuan bahwa blok tersebut merupakan anak sah dari induknya (dan melakukan transaksi apa pun biaya untuk masalah mereka). Terserah pada protokol parachain untuk menentukan protokolnya sendiri sarana pencegahan spam: tidak ada gagasan mendasar tentang “pengukuran sumber daya komputasi” atau “biaya transaksi” dikenakan oleh rantai relay. Juga tidak ada penegakan langsung terhadap hal ini melalui protokol rantai relai (meskipun demikian kecil kemungkinannya para pemangku kepentingan akan memilih untuk mengadopsinya parachain yang tidak menyediakan mekanisme yang layak). Ini adalah anggukan eksplisit terhadap kemungkinan rantai yang tidak sama Ethereum, mis. rantai mirip Bitcoin yang memiliki model biaya yang lebih sederhana atau model pencegahan spam lainnya yang belum diusulkan. Rantai relai Polkadot itu sendiri mungkin akan ada sebagai Akun dan rantai negara yang mirip Ethereum, kemungkinan merupakan turunan EVM. Karena node rantai relai akan diperlukan melakukan pemrosesan substansial lainnya, throughput transaksi akan diminimalkan sebagian melalui biaya transaksi yang besar dan, jika model penelitian kami memerlukannya, batas ukuran blok. 5.4. Komunikasi Antar Rantai. Bahan terakhir yang penting dari Polkadot adalah komunikasi antar rantai. Sejak parachain dapat memiliki semacam saluran informasi di antara mereka, kami membiarkan diri kami mempertimbangkan Polkadot a multi-rantai yang dapat diskalakan. Dalam kasus Polkadot, komunikasinya sesederhana mungkin: transaksi dijalankan dalam a parachain (menurut logika rantai itu) mampu mempengaruhi pengiriman transaksi ke parachain kedua atau, mungkin, rantai relai. Seperti transaksi eksternal pada produksi blockchains, keduanya sepenuhnya asinkron dan tidak ada kemampuan intrinsik bagi mereka untuk mengembalikannya jenis informasi kembali ke asalnya. Tujuan: mendapat data dari sebelumnya validators blok. Akun menerima kiriman: entri dihapus dari masuknya Merkle tree Akun mengirimkan kiriman: entri ditempatkan di jalan keluar Merkle tree untuk tujuan parachain jalan keluar Sumber: saham data dengan blok berikutnya validatordtk bukti kiriman disimpan di parachain jalan keluar Merkle pohon referensi yang diarahkan ditempatkan di parachain tujuan masuknya Merkle tree masuknya Gambar 3. Tampilan skema dasar bagian utama perutean untuk diposting transaksi (“postingan”). Untuk memastikan kompleksitas implementasi minimal, minimal risiko dan minimal jaket lurus dari masa depan arsitektur parachain, transaksi antar rantai ini secara efektif tidak dapat dibedakan dari transaksi standar yang ditandatangani secara eksternal. Transaksi memiliki segmen asal, memberikan kemampuan untuk mengidentifikasi parachain, dan alamat yang ukurannya mungkin berubah-ubah. Tidak seperti sistem umum saat ini seperti Bitcoin dan Ethereum, transaksi antar rantai tidak disertai dengan “pembayaran” biaya apa pun; pembayaran semacam itu harus dikelola melalui logika negosiasi pada parachain sumber dan tujuan. Sebuah sistem seperti yang diusulkan Rilisan Serenity Ethereum [7] akan menjadi cara yang sederhana Namun, cara mengelola pembayaran sumber daya lintas rantai tersebut kami berasumsi orang lain mungkin akan muncul pada waktunya. Transaksi antar rantai diselesaikan dengan menggunakan cara sederhana mekanisme antrian berdasarkan Merkle tree untuk memastikan kesetiaan. Ini adalah tugas pengelola rantai relai untuk melakukannya memindahkan transaksi pada antrian keluaran satu parachain ke dalam antrian input parachain tujuan. Itu transaksi yang diteruskan direferensikan pada rantai relai, namun tidak reltransaksi ay-chain itu sendiri. Untuk mencegah parachain mengirim spam ke parachain lain transaksi, agar suatu transaksi dapat dikirim, diperlukan agar antrian masukan tujuan tidak terlalu besar waktu akhir blok sebelumnya. Jika masukan antrian terlalu besar setelah pemrosesan blok, maka dianggap “jenuh” dan tidak ada transaksi yang dapat dialihkan itu dalam blok berikutnya sampai dikurangi kembali di bawah batas. Antrian ini dikelola pada rantai relai memungkinkan parachain untuk menentukan saturasi satu sama lain status; dengan cara ini upaya yang gagal untuk memposting transaksi ke tujuan yang terhenti dapat dilaporkan secara serempak. (Meskipun karena tidak ada jalur pengembalian, jika transaksi sekunder gagal karena alasan tersebut, transaksi tersebut tidak dapat dilaporkan kembali ke penelepon asli dan beberapa cara pemulihan lainnya harus terjadi.) 5.5. Polkadot dan Ethereum. Karena kelengkapan Turing Ethereum, kami berharap ada banyak peluang bagi Polkadot dan Ethereum untuk dapat dioperasikan dengan satu sama lain, setidaknya dalam batasan keamanan yang mudah dideduksi. Singkatnya, kami membayangkan transaksi dari Polkadot dapat ditandatangani oleh validators dan kemudian dimasukkan ke dalam 5Tugas seperti itu mungkin dibagi antara validators atau bisa menjadi tugas khusus dari sekumpulan validators yang dikenal sebagai penjamin ketersediaan.

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 8 Ethereum dimana hal tersebut dapat ditafsirkan dan diberlakukan oleh kontrak penerusan transaksi. Di arah lain, kami memperkirakan penggunaan log (peristiwa) yang diformat khusus berasal dari “kontrak terobosan” untuk memungkinkan verifikasi cepat bahwa pesan tertentu harus diteruskan. 5.5.1. Polkadot hingga Ethereum. Melalui pilihan a BFT mekanisme konsensus dengan validators terbentuk dari a sekelompok pemangku kepentingan yang ditentukan melalui pemungutan suara persetujuan mekanisme, kita bisa mendapatkan konsensus yang aman dengan jarang berubah dan jumlah validators sedikit. Dalam sistem dengan total 144 validators, waktu blok adalah 4 detik dan finalitas 900 blok (memungkinkan tindakan jahat perilaku seperti suara ganda untuk dilaporkan, dihukum dan diperbaiki), validitas suatu blok dapat dibenarkan dianggap terbukti melalui sedikitnya 97 tanda tangan (dua pertiga dari 144 ditambah satu) dan periode verifikasi 60 menit berikutnya dimana tidak ada keberatan yang diajukan. Ethereum dapat menjadi tuan rumah “kontrak pembobolan” yang dapat mempertahankan 144 penandatangan dan dikendalikan oleh mereka. Karena pemulihan tanda tangan digital kurva elips (ECDSA) hanya membutuhkan 3.000 gas di bawah EVM, dan sejak itu kami mungkin hanya ingin validasi terjadi pada a mayoritas super validators (bukan suara bulat penuh), biaya dasar Ethereum yang mengonfirmasi bahwa sebuah instruksi divalidasi dengan benar karena berasal dari jaringan Polkadot tidak lebih dari 300.000 gas—hanya 6% dari batas total blok gas pada 5,5M. Meningkatkan jumlah validator (sebagaimana diperlukan untuk menangani lusinan rantai) pasti akan meningkatkan biaya ini bandwidth transaksi Ethereum diperkirakan akan bertambah seiring waktu seiring dengan semakin matangnya teknologi dan infrastruktur membaik. Bersama dengan fakta bahwa tidak semua validator perlu dilibatkan (misalnya hanya yang tertinggi validators yang dipertaruhkan dapat dipanggil untuk tugas seperti itu) tersebut batasan mekanisme ini meluas dengan cukup baik. Dengan asumsi rotasi harian sebesar validators (yaitu cukup konservatif—mingguan atau bahkan bulanan mungkin dapat diterima), sehingga menimbulkan biaya pemeliharaan jaringan jembatan penerusan Ethereum ini akan berjumlah sekitar 540.000 gas per hari atau, pada harga gas saat ini, $45 per tahun. Transaksi dasar yang diteruskan sendiri melalui jembatan akan dikenakan biaya sekitar $0,11; perhitungan kontrak tambahan akan memakan biaya tentu saja lebih banyak lagi. Dengan buffering dan bundling transaksi bersama-sama, biaya otorisasi pembobolan dapat dengan mudah dikurangkan dibagikan, mengurangi biaya per transaksi secara signifikan; jika 20 transaksi diperlukan sebelum meneruskan, maka biaya untuk meneruskan transaksi dasar akan turun menjadi sekitar $0,01. Salah satu alternatif yang menarik dan lebih murah terhadap model kontrak multitanda tangan ini adalah dengan menggunakan tanda tangan ambang batas untuk mencapai semantik kepemilikan multilateral. Sedangkan skema tanda tangan ambang batas untuk ECDSA mahal secara komputasi, dibandingkan skema lainnya seperti tanda tangan Schnorr sangat masuk akal. Ethereum berencana untuk memperkenalkan primitif yang akan membuat seperti itu skema murah untuk digunakan di hardfork Metropolis yang akan datang. Jika cara seperti itu dapat dimanfaatkan, biaya gasnya akan mahal untuk meneruskan transaksi Polkadot ke Ethereum jaringan akan berkurang drastis hingga mendekati nol overhead melebihi biaya dasar untuk memvalidasi menandatangani dan melaksanakan transaksi yang mendasarinya. Dalam model ini, node validator Polkadot akan memiliki untuk melakukan apa pun selain menandatangani pesan. Agar transaksi benar-benar dirutekan ke jaringan Ethereum, kami asumsikan validator itu sendiri juga akan berada jaringan Ethereum atau, lebih mungkin, hadiah kecil itu ditawarkan kepada aktor pertama yang meneruskan pesan tersebut ke jaringan (hadiahnya bisa dengan mudah dibayarkan ke pencetus transaksi). 5.5.2. Ethereum hingga Polkadot. Menjadikan transaksi menjadi diteruskan dari Ethereum ke Polkadot menggunakan pengertian sederhana tentang log. Ketika kontrak Ethereum ingin mengirimkan transaksi ke parachain tertentu Polkadot, mereka hanya perlu mengadakan “kontrak break-out” khusus. Kontrak break-out akan menerima pembayaran berapa pun diperlukan dan mengeluarkan instruksi logging sehingga keberadaannya dapat dibuktikan melalui bukti Merkle dan pernyataan bahwa header blok terkait adalah valid dan kanonik. Dari dua syarat terakhir, validitas mungkin adalah yang utama paling mudah untuk dibuktikan. Pada prinsipnya, satu-satunya persyaratan adalahuntuk setiap node Polkadot yang memerlukan bukti (yaitu menunjuk validator node) untuk menjalankan instance node Ethereum standar yang sepenuhnya tersinkronisasi. Sayangnya, hal ini sendiri merupakan ketergantungan yang cukup berat. Lebih lanjut metode ringannya adalah dengan menggunakan bukti sederhana bahwa header dievaluasi dengan benar melalui penyediaan hanya bagian dari percobaan status Ethereum perlu dijalankan dengan benar transaksi di blok dan periksa apakah log (yang terdapat dalam tanda terima blok) valid. Seperti “SPV”6 pembuktian mungkin masih memerlukan sejumlah besar informasi; nyamannya, mereka biasanya tidak diperlukan semua: sistem ikatan di dalam Polkadot akan memungkinkan ikatan pihak ketiga untuk mengirimkan header dengan risiko kehilangannya jaminan jika pihak ketiga lainnya (seperti “nelayan”, lihat 6.2.3) memberikan bukti bahwa header tersebut tidak valid (khususnya akar negara atau akar penerimaan adalah penipu). Pada jaringan PoW yang belum terselesaikan seperti Ethereum, kanonikalitas tidak mungkin dibuktikan secara meyakinkan. Untuk mengatasi hal ini, aplikasi-aplikasi yang mencoba mengandalkan apapun jenisnya sebab-akibat yang bergantung pada rantai menunggu sejumlah “konfirmasi”, atau hingga transaksi dependen mencapai titik tertentu. kedalaman tertentu dalam rantai. Pada Ethereum, ini kedalamannya bervariasi dari 1 blok untuk transaksi yang paling tidak berharga tanpa masalah jaringan yang diketahui hingga 1200 blok seperti sebelumnya kasus ini selama rilis awal Frontier untuk pertukaran. Pada jaringan “Homestead” yang stabil, angka ini berada pada 120 blok untuk sebagian besar bursa, dan kemungkinan besar kami akan mengambilnya parameter serupa. Jadi kita bisa bayangkan milik kita Polkadot-sisi Ethereumantarmuka memiliki beberapa fungsi sederhana: untuk dapat menerima header baru dari jaringan Ethereum dan memvalidasi PoW, untuk dapat menerima beberapa bukti bahwa a log tertentu dikeluarkan oleh kontrak breakout sisi Ethereum untuk header dengan kedalaman yang cukup (dan meneruskan pesan terkait dalam Polkadot) dan terakhir untuk dapat menerima bukti-bukti yang sebelumnya diterima tetapi header yang belum diberlakukan berisi akar tanda terima yang tidak valid. Untuk benar-benar mendapatkan data header Ethereum itu sendiri (dan bukti SPV atau sanggahan validitas/kanonikalitas) ke dalam jaringan Polkadot, sebuah insentif untuk penerusan 6SPV mengacu pada Verifikasi Pembayaran yang Disederhanakan di Bitcoin dan menjelaskan metode bagi klien untuk memverifikasi transaksi sambil hanya menyimpan salinan semua header blok dari rantai PoW terpanjang.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 9 data diperlukan. Ini bisa sesederhana pembayaran (didanai dari biaya yang dikumpulkan di sisi Ethereum) dibayarkan kepada siapa pun yang dapat meneruskan blok berguna yang headernya sah. Validator akan diminta untuk menyimpan informasi terkait beberapa ribu blok terakhir dapat mengelola fork, baik melalui beberapa cara protokol intrinsik atau melalui kontrak yang dipertahankan di rantai relai. 5.6. Polkadot dan Bitcoin. Bitcoin interoperasi menghadirkan tantangan menarik untuk Polkadot: yang disebut “pasak dua arah” akan menjadi infrastruktur yang berguna untuk dimiliki di sisi kedua jaringan. Namun karena batasan Bitcoin, menyediakan pasak seperti itu dengan aman adalah sebuah usaha yang tidak sepele. Mengirimkan transaksi dari Bitcoin hingga Polkadot pada prinsipnya dapat dilakukan dengan proses serupa dengan Ethereum; sebuah “alamat pelarian” dikendalikan dalam beberapa cara oleh Polkadot validators bisa menerima tokens yang ditransfer (dan data dikirim bersamanya). Bukti SPV dapat diberikan dengan oracles yang diberi insentif dan, bersama dengan periode konfirmasi, hadiah yang diberikan mengidentifikasi blok non-kanonik yang menyiratkan transaksi telah “dibelanjakan ganda”. Setiap token yang kemudian dimiliki di “alamat pelarian” pada prinsipnya akan dikontrol oleh validator yang sama untuk penyebaran selanjutnya. Namun masalahnya adalah bagaimana deposit dapat dikontrol dengan aman dari set validator yang berputar. Berbeda dengan Ethereum yang mampu mengambil keputusan sewenang-wenang berdasarkan berdasarkan kombinasi tanda tangan, Bitcoin secara substansial lebih terbatas, sebagian besar klien hanya menerima transaksi multisignature dengan maksimal 3 pihak. Memperluasnya menjadi 36, atau bahkan ribuan seperti yang diinginkan, tidak mungkin dilakukan berdasarkan protokol saat ini. Salah satu opsinya adalah mengubah protokol Bitcoin menjadi aktif fungsionalitas seperti itu, namun apa yang disebut “hard fork” di dalamnya Bitcoin dunia sulit untuk diatur penilaiannya berdasarkan upaya baru-baru ini. Salah satu kemungkinannya adalah penggunaan tanda tangan ambang batas, skema kriptografi untuk memungkinkan publik yang dapat diidentifikasi secara tunggal kunci untuk dikontrol secara efektif oleh banyak “bagian” rahasia, sebagian atau seluruhnya harus dimanfaatkan untuk membuat tanda tangan yang sah. Sayangnya, tanda tangan ambang batas kompatibel dengan ECDSA Bitcoin secara komputasi mahal buat dan kompleksitas polinomial. Skema lain seperti itu Namun, tanda tangan Schnorr memberikan biaya yang jauh lebih rendah garis waktu di mana mereka dapat diperkenalkan ke Bitcoin protokol tidak pasti. Karena keamanan tertinggi dari simpanan ada pada sejumlah validator yang terikat, salah satu opsi lainnya adalah melakukannya mengurangi pemegang kunci multi-tanda tangan menjadi hanya banyak subset terikat dari total validators sedemikian rupa sehingga ambang batas tersebut tanda tangan menjadi layak (atau, paling buruk, tanda tangan asli Bitcoin multi-tanda tangan dimungkinkan). Hal ini tentu saja mengurangi jumlah total obligasi yang dapat dikurangi sebagai ganti rugi jika validator berperilaku ilegal, namun hal ini adalah degradasi yang baik, hanya dengan menetapkan batas atas jumlah dana yang dapat berjalan dengan aman di antara dua jaringan (atau bahkan, pada % kerugian jika terjadi serangan dari validators berhasil). Oleh karena itu, kami yakin tidak realistis untuk menempatkan “parachain virtual” interoperabilitas Bitcoin yang cukup aman antara kedua jaringan, meskipun tetap merupakan upaya besar dengan jangka waktu yang tidak pasti dan sangat mungkin terjadi memerlukan kerja sama dari para pemangku kepentingan di dalamnya jaringan.

Обзор конструкции

Цель этого раздела – дать краткий обзор система в целом. Более тщательное исследование система приведена в следующем за ней разделе. 5.1. Консенсус. В цепочке реле Polkadot достигает консенсус низкого уровня по набору взаимно согласованных действительных блокируется с помощью современного асинхронного византийского отказоустойчивого алгоритма (BFT). Алгоритм будет вдохновлен с помощью простого Tendermint [11] и значительно большего участвует HoneyBadgerBFT [14]. Последний обеспечивает эффективный и отказоустойчивый консенсус по произвольному дефектная сетевая инфраструктура, учитывая набор в основном безобидных органов власти или validator. Для сети в стиле доказательства авторитета (PoA) это само по себе было бы достаточно, однако Polkadot предполагается также можно развернуть в виде сети в полностью открытом и общедоступном режиме. ситуация без какой-либо конкретной организации или доверенного лица полномочия, необходимые для его поддержания. Таким образом, нам нужен средства определения набора validators и стимулирования им, если честно. Для этого мы используем отбор на основе PoS. критерии. 5.2. Доказательство ставки. Мы предполагаем, что сеть будут иметь некоторые средства измерения размера «ставки» какая-либо конкретная учетная запись имеет. Для удобства сравнения с ранее существовавших систем, мы будем называть единицу измерения «tokens». К сожалению, этот термин не идеален для ряд причин, не в последнюю очередь то, что это просто скаляр значение, связанное со счетом, нет понятия индивидуальность. Мы предполагаем, что validator избираются нечасто (в лучшем случае один раз в день, но, возможно, реже, чем раз в квартал), по схеме Nomination Proof-of-Stake (NPoS). Стимулирование может происходить за счет пропорционального распределенияPOLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 6 Реле цепь Рой валидаторов (каждый окрашен в свой цвет обозначенный парачейн) Транзакция (представлено внешний актер) Парачейн мост Виртуальный парачейн (например, Ethereum) Парачейн Парачейн очереди и ввод-вывод Распространяемые транзакции Заблокировать подачу кандидата 2-й порядок Релейная цепь Парачейн-сообщество Аккаунт Входящая транзакция Исходящая транзакция Межцепочные транзакции (управляется validators) подборщик Распространенный блок Рыбак Рисунок 2. Сводная схема системы Polkadot. На этом рисунке показаны сопоставители, собирающие и распространяющие пользовательские транзакции, а также распространяющие кандидатов на блоки рыбакам и validator. Это также показывает, как учетная запись может публиковать транзакцию, выполняемую из ее парачейна, через релейную цепь. и в другой парачейн, где это можно интерпретировать как транзакцию на счет там. средства, поступающие от расширения базы token (до 100 % в год, хотя более вероятно около 10%) вместе с любые взимаемые комиссии за транзакции. Хотя расширение денежной базы обычно приводит к инфляции, поскольку все владельцы token будут иметь справедливую возможность участия, ни одному держателю token не придется страдать от снижения стоимости своих холдингов с течением времени при условии, что они будут рады принять роль в механизме консенсуса. Особая пропорция из token будут предназначены для процесса staking; тот эффективное расширение базы token будет скорректировано через рыночный механизм для достижения этой цели. Валидаторы сильно связаны своими ставками; выход Облигации validators остаются в силе еще долгое время после прекращения исполнения обязанностей validators (возможно, около 3 месяцев). Это долго Период ликвидации облигаций позволяет предотвратить неправомерное поведение в будущем. наказываются вплоть до периодической проверки цепочки. Неправомерное поведение влечет за собой наказание, например, снижение вознаграждение или, в случаях, которые намеренно ставят под угрозу целостность сети, validator теряет часть или все свои ставка другим validator, информаторам или заинтересованным сторонам в целом (через горение). Например, validator который пытается ратифицировать обе ветви вилки (иногда известная как атака «ближнего радиуса действия»), могут быть идентифицированы и наказывалось последним способом. Дальние атаки «ничего не поставлено на карту»4 обходят с помощью простой блокировки «контрольной точки», которая предотвращает опасную реорганизацию цепочки длиной более определенную глубину цепи. Чтобы обеспечить новую синхронизацию клиентов не могут попасться не на ту цепочку, регулярные произойдут «хардфорки» (максимум того же периода ликвидация облигаций validators), которые жестко закодируют недавнюю контрольную точку, блокирующую hashes в клиентах. Это хорошо сочетается с дополнительной мерой уменьшения занимаемой площади «конечной длиной цепи» или периодический сброс генезис-блока. 5.3. Парачейны и колляторы. Каждый парачейн получает аналогичные средства безопасности для релейной цепи: тот заголовки парачейнов запечатаны внутри блока релейной цепи обеспечение невозможности реорганизации или «двойного расходования» после подтверждения. Это аналогичная гарантия безопасности, предлагаемая сайдчейнами Bitcoin и слиянием майнинга. Polkadot, однако, также предоставляет надежные гарантии того, что переходы состояний парачейнов действительны. Это происходит посредством криптографического случайного сегментирования набора validator на подмножества; одно подмножество на парачейн, подмножества которых потенциально различаются в каждом блоке. Это настройка обычно подразумевает, что время блокировки парачейнов будет быть по крайней мере такой же длины, как и длина релейной цепи. Конкретный средства определения разделения выходят за рамки 4Такая атака заключается в том, что противник создает совершенно новую историческую цепочку, начиная с блока генезиса. Посредством контроля относительно незначительную часть ставки при зачете, они могут постепенно увеличивать свою долю ставки относительно всех других заинтересованные стороны, поскольку они являются единственными активными участниками своей альтернативной истории. Поскольку не существует внутренних физических ограничений на создание блоков (в отличие от PoW, где должна быть затрачена вполне реальная вычислительная энергия), они способны создавать цепочку длиннее, чем реальная цепочка в относительно короткий промежуток времени и потенциально делает его самым длинным и лучшим, принимая на себя каноническое состояние сети.POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 7 этого документа, но, скорее всего, будет основан либо на фреймворк фиксации-раскрытия, аналогичный RanDAO [19] или использовать данные, объединенные из предыдущих блоков каждого парачейна под криптографически безопасным hash. Такие подмножества validator необходимы для предоставления кандидат на блок парачейна, который гарантированно действителен (на боль от конфискации облигаций). Срок действия вращается вокруг двух важные моменты; во-первых, что оно действительно действительно по своей сути — что все переходы состояний были выполнены добросовестно и что все внешние данные, на которые ссылаются (т. е. транзакции), действительны для включения. Во-вторых, любые данные, не относящиеся к его кандидаты, такие как внешние транзакции, имеют достаточно высокую доступность, чтобы участники могли загрузите его и выполните блок вручную.5 Валидаторы могут предоставить только «нулевой» блок, не содержащий данных о внешних «транзакциях», но в этом случае они рискуют получить уменьшенное вознаграждение. Они работают бок о бок протокол сплетен парачейна с сопоставителями — отдельными лицами которые объединяют транзакции в блоки и предоставляют неинтерактивное доказательство с нулевым разглашением того, что блок является действительным дочерним элементом своего родителя (и принимает любую транзакцию гонорары за свои хлопоты). Протоколам парачейна предоставлено право определять свои собственные средства предотвращения спама: не существует фундаментального понятия «учет вычислительных ресурсов» или «плата за транзакцию» налагаемые релейной цепью. Протокол ретрансляционной цепи также не обеспечивает прямого соблюдения этого правила (хотя он маловероятно, что заинтересованные стороны захотят принять парачейн, который не обеспечивал достойного механизма). Это явный намек на возможность существования цепочек в отличие от Ethereum, например. цепочка типа Bitcoin, которая имеет гораздо более простую модель оплаты или какую-либо другую, еще не предложенную модель предотвращения спама. Сама релейная цепь Polkadot, вероятно, будет существовать как Ethereum-подобные учетные записи и цепочка состояний, возможно, производная от EVM. Поскольку узлы релейной цепи должны будут выполнять существенную другую обработку, пропускную способность транзакций будет частично сведено к минимуму за счет больших комиссий за транзакции и, если наши исследовательские модели требуют ограничения размера блока. 5.4. Межсетевое общение. Важнейшим и последним ингредиентом Polkadot является межцепочечная связь. Поскольку между парачейнами может быть какой-то информационный канал, мы позволяем себе считать Polkadot масштабируемая мультицепочка. В случае Polkadot связь настолько проста, насколько это возможно: транзакции выполняются в парачейн (согласно логике этой цепочки) способны осуществить отправку транзакции во второй парачейн или, потенциально, релейная цепь. Как внешние транзакции на производстве blockchain они полностью асинхронны и у них нет внутренней способности возвращать какие-либо вид информации возвращается к ее источнику. Назначение: получает данные предыдущего validators блока. Аккаунт получает сообщение: запись удалена из вход Merkle tree Аккаунт отправляет сообщение: запись помещена в выход Merkle tree для назначения парачейн выход Источник: акции данные со следующим блоком validatorс подтверждение почты, хранящееся в выход парачейна Меркла дерево размещена маршрутизированная ссылка в пункте назначения парачейна вход Merkle tree проникновение Рисунок 3. Базовая схема, показывающая основные части маршрутизации для публикации транзакции («посты»). Чтобы обеспечить минимальную сложность реализации, минимальные риск и минимальный смирительная рубашка из будущее В парачейн-архитектурах эти межцепочные транзакции фактически неотличимы от стандартных транзакций, подписанных извне. Транзакция имеет сегмент происхождения, предоставляющий возможность идентифицировать парачейн, и адрес, который может иметь произвольный размер. В отличие от обычных текущих систем, таких как Bitcoin и Ethereum, межцепочные транзакции не связаны с какой-либо «оплатой» комиссии; любой такой платеж должен управляться посредством логики переговоров в парачейнах источника и назначения. Такая система, как предложенная для Выпуск Serenity Ethereum [7] будет простым средством управления такой межсетевой оплатой ресурсов, хотя мы предполагаем, что со временем на первый план могут выйти и другие. Межцепочные транзакции разрешаются с использованием простого механизм организации очередей, основанный на Merkle tree, чтобы гарантировать верность. Задачей специалистов по обслуживанию релейной цепи является перемещать транзакции в выходную очередь одного парачейна во входную очередь целевого парачейна. на пройденные транзакции ссылаются в цепочке реле, однако они не передаютсяСами транзакции ay-chain. Чтобы предотвратить спам-рассылку парачейна другому парачейну с помощью транзакции, для отправки транзакции необходимо чтобы очередь ввода адресата не была слишком большой время окончания предыдущего блока. Если вход очередь слишком велика после обработки блока, то она считается «насыщенной» и никакие транзакции не могут быть перенаправлены в нее в последующих блоках, пока не уменьшится снова ниже уровня предел. Эти очереди администрируются в цепочке реле. позволяя парачейнам определять насыщенность друг друга статус; таким образом, неудачная попытка опубликовать транзакцию в остановленный пункт назначения может быть сообщено синхронно. (Хотя, поскольку пути возврата не существует, если вторичная транзакция не удалась по этой причине, о ней нельзя будет сообщить обратно. исходному абоненту и некоторые другие средства восстановления должно было состояться.) 5.5. Polkadot и Ethereum. Учитывая полноту по Тьюрингу Ethereum, мы ожидаем, что у Polkadot и Ethereum есть широкие возможности взаимодействия с друг друга, по крайней мере, в пределах некоторых легко выводимых границ безопасности. Короче говоря, мы предполагаем, что транзакции из Polkadot может быть подписан validator и затем передан в 5Такая задача может быть разделена между validator или может стать назначенной задачей набора сильно связанных validator, известных как Гаранты наличия.

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 8 Ethereum, где их можно интерпретировать и применять договор о пересылке транзакций. В другом направлении, мы предусматриваем использование специально отформатированных журналов (событий) исходит из «прорывного контракта», чтобы обеспечить быструю проверку того, что конкретное сообщение должно быть перенаправлено. 5.5.1. От Polkadot до Ethereum. Через выбор А. Механизм консенсуса BFT с validators, сформированный из набор заинтересованных сторон, определенный путем одобрительного голосования механизм, мы можем достичь надежного консенсуса с нечасто меняющееся и скромное количество validators. В системе с общим числом 144 validators время блока 4 секунды и завершение в 900 блоков (что позволяет злонамеренным поведение, такое как двойное голосование, о котором следует сообщать, наказывается и восстановлен), достоверность блока может быть обоснованно считается доказанным, если имеется всего лишь 97 подписей (две трети из 144 плюс одна) и последующий 60-минутный период проверки, в течение которого не было предъявлено никаких возражений. Ethereum может организовать «контракт на взлом», который может сохранить 144 подписанта и контролироваться их. Поскольку для восстановления цифровой подписи по эллиптической кривой (ECDSA) требуется всего 3000 газа под номером EVM, и поскольку мы, вероятно, хотели бы, чтобы проверка происходила только на сверхбольшинство validator (вместо полного единогласия), базовая стоимость Ethereum, подтверждающая, что инструкция было правильно подтверждено, поскольку из сети Polkadot будет не более 300 000 газа — всего 6% общий лимит газа по блоку составляет 5,5М. Увеличение количества validator (что необходимо для работы с десятки сетей) неизбежно увеличивает эту стоимость, однако ожидается, что пропускная способность транзакций Ethereum со временем будет расти по мере развития технологии и инфраструктура улучшается. Вместе с тем, что не должны быть задействованы все validator (например, только самый высокий для выполнения такой задачи могут быть привлечены поставленные на карту validators) пределы этого механизма достаточно обширны. Предполагая ежедневную ротацию таких validator (что достаточно консервативны (может быть приемлемым еженедельное или даже ежемесячное обслуживание), тогда затраты сети на поддержание этот мост пересылки Ethereum будет около 540 000 газа в день или, при нынешних ценах на газ, 45 долларов в год. Базовая транзакция, пересылаемая через мост, будет стоить около 0,11 доллара США; дополнительные расчеты по контракту будут стоить больше, конечно. Путем буферизации и объединения транзакций вместе затраты на разрешение на взлом могут быть легко совместное использование, что существенно снижает стоимость транзакции; если перед пересылкой требовалось 20 транзакций, то стоимость пересылки базовой транзакции упадет до около $0,01. Одной интересной и более дешевой альтернативой этой модели контракта с несколькими подписями может быть использование пороговых подписей для достижения семантики многостороннего владения. В то время как схемы пороговой подписи для ECDSA являются вычислительно дорогими, для других схем такие как подписи Шнорра очень разумны. Ethereum планирует ввести примитивы, которые сделают такие дешевые схемы для использования в предстоящем хардфорке Metropolis. Если бы такое средство можно было использовать, стоимость газа для пересылки транзакции Polkadot в Ethereum сеть будет резко сокращена почти до нуля. накладные расходы сверх основных затрат на проверку подпись и выполнение базовой транзакции. В этой модели узлы Polkadot validator будут иметь ничего не делать, кроме как подписывать сообщения. Чтобы транзакции действительно направлялись в сеть Ethereum, мы предположим, что либо сами validator также будут находиться на сеть Ethereum или, что более вероятно, небольшие награды быть предложено первому актору, который передаст сообщение в сеть (награда может быть тривиально выплачена инициатор транзакции). 5.5.2. От Ethereum до Polkadot. Получение транзакций при пересылке с Ethereum на Polkadot используется простое понятие журналов. Когда контракт Ethereum желает отправить транзакцию в конкретный парачейн Polkadot, ему нужно просто заключить специальный «контракт о прорыве». Контракт о прорыве будет принимать любые платежи, которые могут потребуется и выдать инструкцию регистрации, чтобы ее существование можно было доказать с помощью доказательства Меркла и утверждения о том, что заголовок соответствующего блока действителен и канонический. Из последних двух условий достоверность, пожалуй, является проще всего доказать. В принципе, единственное требованиедля каждого узла Polkadot, требующего доказательства (т. е. назначенные узлы validator) для запуска полностью синхронизированного экземпляра стандартного узла Ethereum. К сожалению, это само по себе довольно сильная зависимость. Более Облегченным методом было бы использовать простое доказательство того, что заголовок был оценен правильно, поскольку был указан только часть дерева состояния Ethereum, необходимая для правильного выполнения транзакции в блоке и проверьте достоверность журналов (содержащихся в квитанции блока). Такие «СПВ-подобные»6 доказательства все же могут потребовать значительного объема информации; удобно, они обычно не нужны все: система облигаций внутри Polkadot позволит связывать третьим лицам отправлять заголовки с риском потери своих залог, если какая-либо третья сторона (например, «рыбак», см. 6.2.3) предоставит доказательство того, что заголовок недействителен. (в частности, что корень штата или корни квитанций были самозванцами). В незавершенной сети PoW, такой как Ethereum, каноничность невозможно доказать окончательно. Чтобы решить эту проблему, приложения, которые пытаются использовать какие-либо причинно-следственной цепочки дождитесь нескольких «подтверждений» или пока зависимая транзакция не достигнет некоторого определенную глубину внутри цепи. На Ethereum это Глубина варьируется от 1 блока для наименее ценных транзакций без известных проблем с сетью до 1200 блоков, как было раньше. случай во время первоначального выпуска Frontier для обмена. В стабильной сети «Homestead» эта цифра находится на отметке 120 блоков для большинства бирж, и мы, скорее всего, возьмем аналогичный параметр. Итак мы может представьте себе наш Polkadot сторона Ethereumинтерфейс, чтобы иметь несколько простых функций: иметь возможность принять новый заголовок из сети Ethereum и проверить PoW, чтобы иметь возможность принять некоторые доказательства того, что конкретный журнал был создан контрактом прорыва на стороне Ethereum для заголовка достаточной глубины (и прямого соответствующее сообщение в Polkadot) и, наконец, иметь возможность принимать доказательства, которые ранее были приняты, но Заголовок not-yet-enacted содержит недопустимый корень квитанции. Чтобы получить сами данные заголовка Ethereum (и любые доказательства SPV или опровержения действительности/каноничности) в сеть Polkadot, стимул для пересылки 6SPV относится к упрощенной проверке платежей в Bitcoin и описывает метод, позволяющий клиентам проверять транзакции, сохраняя при этом только копия заголовков всех блоков самой длинной цепочки PoW.POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 9 нужны данные. Это может быть так же просто, как оплата (финансируется за счет комиссий, собранных на стороне Ethereum) оплачено всем, кто может переслать полезный блок, заголовок которого действительный. Валидаторам будет предложено сохранять информацию, относящуюся к последним нескольким тысячам блоков, чтобы иметь возможность управлять форками либо с помощью некоторых встроенных в протокол средств, либо с помощью контракта, поддерживаемого на релейная цепь. 5.6. Polkadot и Bitcoin. Bitcoin взаимодействие представляет собой интересную задачу для Polkadot: так называемую «двусторонняя привязка» была бы полезной частью инфраструктуры иметь на стороне обеих сетей. Однако из-за ограничения Bitcoin, обеспечение такой привязки безопасным нетривиальное занятие. Осуществление транзакции от От PH_0011 до Polkadot в принципе можно выполнить с помощью процесса, аналогичного процессу для Ethereum; «адрес прорыва» каким-то образом контролируемые Polkadot validators могли получать переданные tokens (и данные, отправленные вместе с ними). Доказательства SPV могут быть предоставлены заинтересованными oracle и, вместе с периодом подтверждения, награда за выявление неканонических блоков, подразумевающих транзакцию был «израсходован дважды». Любые tokens, принадлежавшие тогда в Тогда «адрес прорыва», в принципе, будет контролироваться теми же validator для последующего распространения. Однако проблема заключается в том, как можно безопасно контролировать депозиты с помощью вращающегося набора validator. В отличие от Ethereum, который способен принимать произвольные решения на основе при сочетании подписей Bitcoin по существу более ограничен: большинство клиентов принимают только транзакции с мультиподписями, в которых участвуют максимум 3 стороны. Увеличение этого числа до 36 или даже до тысяч, как это в конечном итоге может быть желательно, невозможно в соответствии с текущим протоколом. Один из вариантов — изменить протокол Bitcoin, чтобы включить такая функциональность, однако так называемые «хард-форки» в Bitcoin мир сложно устроить, судя по недавним попыткам. Одной из возможностей является использование пороговых сигнатур, криптографические схемы, позволяющие однозначно идентифицировать публичные ключ для эффективного управления несколькими секретными «частями», некоторые или все из них должны быть использованы для создания действительной подписи. К сожалению, пороговые подписи совместимы с ECDSA Bitcoin требуют больших вычислительных затрат создания и полиномиальной сложности. Другие схемы, такие как Подписи Шнорра обеспечивают гораздо более низкие затраты, однако график, в котором они могут быть представлены в Bitcoin протокол неясен. Поскольку конечная безопасность депозитов зависит от несколько связанных validator, еще один вариант — сократить количество держателей ключей с несколькими подписями до связанное подмножество общего числа validators, такое что порог подписи становятся возможными (или, на худой конец, родными для Bitcoin возможна мультиподпись). Это, конечно, снижает общая сумма облигаций, которая может быть вычтена в качестве возмещения, если validator будут вести себя незаконно, однако это это изящная деградация, просто установка верхнего предела количество средств, которые могут безопасно перемещаться между две сети (вернее, на % потерь при атаке из __PH_0004__s удалось). Таким образом, мы считаем, что вполне реально разместить достаточно безопасный «виртуальный парачейн» с функциональной совместимостью Bitcoin. между двумя сетями, хотя, тем не менее, это значительные усилия с неопределенными сроками и, вполне возможно, требуя сотрудничества заинтересованных сторон в рамках этого сеть.

Protokol secara Detail

Protokol secara kasar dapat dipecah menjadi tiga bagian: mekanisme konsensus, antarmuka parachain dan perutean transaksi antar rantai. 6.1. Rantai relai Operasi. Itu rantai relai akan kemungkinan besar merupakan rantai yang mirip dengan Ethereum di dalamnya berbasis negara bagian dengan alamat pemetaan negara bagian ke akun informasi, terutama saldo dan (untuk mencegah terulangnya kembali) a loket transaksi. Menempatkan akun di sini memenuhi satu tujuan: untuk menyediakan akuntansi yang dimiliki oleh identitas berapa jumlah taruhan dalam sistem tersebut.7 Namun, akan ada perbedaan yang mencolok: • Kontrak tidak dapat disebarkan melalui transaksi; karena keinginan untuk menghindari fungsionalitas aplikasi pada rantai relai, hal itu tidak akan terjadi mendukung penerapan kontrak secara publik. • Menghitung penggunaan sumber daya (“gas”) tidak diperhitungkan; karena satu-satunya fungsi yang tersedia untuk penggunaan umum akan diperbaiki, alasan di balik penghitungan gas tidak lagi berlaku. Oleh karena itu, biaya tetap akan berlaku semua kasus, memungkinkan kinerja lebih dari apa pun eksekusi kode dinamis yang mungkin perlu dilakukan dan format transaksi yang lebih sederhana. • Fungsi khusus didukung untuk kontrak terdaftar yang memungkinkan eksekusi otomatis dan keluaran pesan jaringan. Jika rantai relai memiliki VM dan itu adalah berdasarkan EVM, ia akan memiliki sejumlah modifikasi untuk memastikan kesederhanaan maksimal. Kemungkinan besar akan terjadi memiliki sejumlah kontrak bawaan (mirip dengan yang ada di alamat 1-4 di Ethereum) untuk memungkinkan spesifik platform tugas yang harus dikelola termasuk kontrak konsensus, a Kontrak validator dan kontrak parachain. Jika bukan EVM, maka backend WebAssembly [2] (wasm) adalah alternatif yang paling mungkin; dalam hal ini keseluruhan strukturnya akan serupa, tetapi tidak diperlukan untuk kontrak bawaan dengan Wasm menjadi target yang layak untuk bahasa tujuan umum daripada yang belum matang dan bahasa terbatas untuk EVM. Kemungkinan penyimpangan lain dari protokol Ethereum saat ini sangat mungkin terjadi, misalnya penyederhanaan format tanda terima transaksi yang memungkinkan eksekusi paralel transaksi yang tidak bertentangan dalam blok yang sama, seperti yang diusulkan untuk rangkaian perubahan Serenity. Ada kemungkinan, meskipun tidak mungkin, bahwa hal itu mirip dengan Serenity rantai "murni" digunakan sebagai rantai relai, memungkinkan a kontrak khusus untuk mengelola hal-hal seperti staking token keseimbangan daripada menjadikannya sebagai bagian mendasar protokol rantai. Saat ini, kami merasa hal tersebut tidak mungkin terjadi akan menawarkan penyederhanaan protokol yang cukup bagus sepadan dengan kompleksitas dan ketidakpastian tambahan yang terlibat dalam mengembangkannya. 7Sebagai sarana untuk mewakili jumlah tanggung jawab pemegang tertentu atas keamanan sistem secara keseluruhan, akun pasak ini akan mewakilinya pasti menyandikan beberapa nilai ekonomi. Namun perlu dipahami karena tidak ada niat untuk menggunakan nilai-nilai tersebut dengan cara apa pun untuk tujuan pertukaran barang dan jasa di dunia nyata, perlu dicatat bahwa token tidak bisa disamakan dengan mata uang dan dengan demikian rantai relai mempertahankan filosofi nihilistiknya mengenai penerapannya.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 10 Ada sejumlah fungsi kecil yang diperlukan untuk mengatur mekanisme konsensus, set validator, mekanisme validasi, dan parachain. Ini dapat diimplementasikan bersama-sama di bawah protokol monolitik. Namun, untuk alasan menambah modularitas, kami menggambarkannya sebagai “kontrak” rantai relai. Ini seharusnya diartikan bahwa mereka adalah objek (dalam arti pemrograman berorientasi objek) yang dikelola oleh mekanisme konsensus rantai relai, namun belum tentu demikian mereka didefinisikan sebagai program dalam opcode mirip EVM, juga tidak bahkan mereka dapat ditangani secara individual melalui sistem akun. 6.2. Kontrak Taruhan. Kontrak ini mempertahankan set validator. Ia mengelola: • akun mana yang saat ini validators; • yang tersedia untuk menjadi validators singkatnya pemberitahuan; • akun mana yang telah menempatkan nominasi saham sebuah validator; • properti masing-masing termasuk volume staking, tingkat pembayaran dan alamat yang dapat diterima, serta identitas (sesi) jangka pendek. Memungkinkan akun untuk mendaftarkan keinginan menjadi a terikat validator (bersama dengan persyaratannya), untuk mencalonkan beberapa identitas, dan untuk validator terikat yang sudah ada sebelumnya untuk mendaftarkan keinginannya untuk keluar dari status ini. Itu juga mencakup mekanisme itu sendiri untuk mekanisme validasi dan kanonikalisasi. 6.2.1. Taruhan-token Likuiditas. Umumnya diinginkan untuk melakukan hal tersebut memiliki sebanyak mungkin total staking tokens dipertaruhkan dalam operasi pemeliharaan jaringan sejak itu ini secara langsung menghubungkan keamanan jaringan dengan “kapitalisasi pasar” keseluruhan dari staking token. Ini bisa dengan mudah mendapatkan insentif melalui penggelembungan mata uang dan membagikan hasilnya kepada mereka yang berpartisipasi sebagai validators. Namun, melakukan hal ini menimbulkan masalah: jika token terkunci dalam Kontrak Staking di bawah hukuman pengurangan, bagaimana sebagian besar bisa tetap mencukupi likuid untuk memungkinkan penemuan harga? Salah satu jawabannya adalah dengan mengizinkan kontrak derivatif langsung, mengamankan token yang sepadan pada token yang dipertaruhkan. Hal ini sulit diatur dengan cara yang bebas kepercayaan. Selain itu, token derivatif ini tidak dapat diperlakukan sama karena alasan yang sama bahwa obligasi pemerintah Zona Euro yang berbeda tidak dapat dipertukarkan: ada adalah kemungkinan aset yang mendasarinya gagal dan menjadi rusak tidak berharga. Dengan pemerintahan zona Euro, mungkin ada a bawaan. Dengan validator yang dipertaruhkan tokens, validator mungkin bertindak jahat dan dihukum. Sesuai dengan prinsip kami, kami memilih solusi paling sederhana: tidak semua token dipertaruhkan. Ini berarti demikian sebagian (mungkin 20%) dari tokens akan tetap cair secara paksa. Meskipun hal ini tidak sempurna dari sudut pandang keamanan, hal ini sepertinya tidak akan membuat perbedaan mendasar keamanan jaringan; 80% dari kemungkinan reparasi akibat penyitaan obligasi masih dapat dilakukan dibandingkan dengan “kasus sempurna” 100% staking. Rasio antara token yang dipertaruhkan dan likuid dapat ditargetkan dengan cukup sederhana melalui mekanisme lelang terbalik. Pada dasarnya, pemegang token tertarik menjadi validator masing-masing akan mengirimkan penawaran ke kontrak staking yang menyatakan tingkat pembayaran minimum yang harus mereka ambil bagian. Di awal setiap sesi (sesi akan terjadi secara teratur, mungkin sesering satu kali per jam) tersebut validator slot akan diisi sesuai dengan calon masing-masing Tingkat taruhan dan pembayaran validator. Salah satu algoritma yang mungkin karena ini berarti mengambil orang-orang dengan penawaran terendah mewakili taruhan yang tidak lebih tinggi dari total taruhan yang ditargetkan dibagi dengan jumlah slot dan tidak lebih rendah dari batas bawah setengah jumlah tersebut. Jika slot tidak dapat diisi, batas bawah dapat dikurangi berulang kali oleh beberapa faktor untuk memenuhi. 6.2.2. Mencalonkan. Dimungkinkan untuk mencalonkan diri tanpa rasa percaya yang staking tokens ke validator aktif, memberi mereka tanggung jawab tugas validators. Menominasikan karya melalui sistem pemungutan suara persetujuan. Setiap calon nominator dapat mengirimkan instruksi ke kontrak staking mengekspresikan satu atau lebih validator identitas di bawah siapa tanggung jawab mereka siap untuk mempercayakan obligasi mereka. Setiap sesi, obligasi nominator disebarkan diwakili oleh satu atau lebih validators. Algoritme penyebaran mengoptimalkan kumpulan validators dengan total setara obligasi. Obligasi nominator menjadi tanggung jawab efektif validator adan mendapatkan minat atau menderita a pengurangan hukuman yang sesuai. 6.2.3. Penyitaan/Pembakaran Obligasi. Perilaku validator tertentu mengakibatkan pengurangan ikatan mereka sebagai hukuman. Jika obligasi tersebut dikurangi di bawah batas minimum yang diijinkan, yaitu sesi diakhiri sebelum waktunya dan sesi lainnya dimulai. Daftar lengkap validator perilaku buruk yang dapat dihukum meliputi: • Menjadi bagian dari kelompok parachain yang tidak mampu menyediakan kebutuhan konsensus mengenai validitas blok parachain; • aktif menandatangani keabsahan yang tidak valid blok parachain; • ketidakmampuan untuk memasok muatan keluar sebelumnya memilih jika tersedia; • ketidakaktifan selama proses konsensus; • memvalidasi blok rantai relai pada fork pesaing. Beberapa kasus perilaku buruk mengancam integritas jaringan (seperti menandatangani blok parachain yang tidak valid dan memvalidasi beberapa sisi dari sebuah fork) dan dengan demikian mengakibatkan pengasingan yang efektif melalui pengurangan total obligasi. Di kasus lain yang tidak terlalu serius (misalnya ketidakaktifan dalam konsensus proses) atau kasus-kasus di mana kesalahan tidak dapat dilimpahkan secara tepat (karena menjadi bagian dari kelompok yang tidak efektif), sebagian kecil obligasi tersebut malah dapat didenda. Dalam kasus terakhir, ini bekerja dengan baik dengan churn sub-grup untuk memastikan bahwa itu berbahaya node menderita kerugian yang jauh lebih besar dibandingkan node baik hati yang terkena dampak kerusakan. Dalam beberapa kasus (misalnya validasi multi-fork dan tidak valid penandatanganan sub-blok) validators tidak dapat dengan mudah mendeteksi perilaku buruk satu sama lain sejak verifikasi terus-menerus setiap blok parachain akan menjadi tugas yang terlalu sulit. Di sini perlu adanya dukungan dari pihak eksternal proses validasi untuk memverifikasi dan melaporkan perilaku buruk tersebut. Para pihak mendapat imbalan karena melaporkan kegiatan tersebut; istilah mereka, “nelayan” berasal dari ketidaksukaan dari imbalan seperti itu. Karena kasus-kasus ini biasanya sangat serius, kami membayangkan imbalan apa pun dapat dengan mudah dibayarkan dari obligasi yang disita. Secara umum kami lebih memilih untuk menyeimbangkan pembakaran (yaitu pengurangan menjadi tidak ada) dengan realokasi, bukan mencoba realokasi grosir. Hal ini mempunyai dampak

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 11 meningkatkan nilai keseluruhan token, mengkompensasi jaringan secara umum sampai tingkat tertentu, bukan secara spesifik pihak yang terlibat dalam penemuan. Hal ini terutama sebagai pengaman mekanismenya: jumlah besar yang terlibat dapat menyebabkan insentif perilaku yang ekstrem dan akut diberikan pada satu sasaran. Secara umum, imbalan yang diberikan harus cukup besar agar verifikasi bermanfaat bagi jaringan, namun tidak terlalu besar untuk mengimbangi biaya menghadapi tantangan. kriminal “tingkat industri” yang didanai dengan baik dan diatur dengan baik serangan peretasan pada validator yang tidak beruntung untuk memaksakan perilaku buruk. Dengan cara ini, jumlah yang diklaim umumnya tidak lebih besar dari jaminan langsung pihak yang bersalah validator, jangan sampai a timbul insentif buruk karena berperilaku buruk dan melaporkan diri sendiri atas karunia tersebut. Hal ini dapat diatasi secara eksplisit melalui persyaratan obligasi langsung minimum untuk menjadi a validator atau secara implisit dengan mengedukasi nominator bahwa validator yang memiliki sedikit obligasi yang disetorkan tidak memiliki insentif yang besar untuk berperilaku baik. 6.3. Registri Parachain. Setiap parachain didefinisikan dalam registri ini. Ini adalah konstruksi seperti database yang relatif sederhana dan menyimpan informasi statis dan dinamis setiap rantai. Informasi statis mencakup indeks rantai (sederhana integer), beserta identitas protokol validasi, a cara untuk membedakan kelas-kelas yang berbeda parachain sehingga algoritma validasi yang benar dapat diperoleh dijalankan oleh validators yang ditugaskan untuk mengajukan calon yang sah. Pembuktian konsep awal akan fokus pada penempatan algoritma validasi baru ke dalam klien itu sendiri, yang secara efektif memerlukan hard fork protokol setiap kali kelas rantai tambahan ditambahkan. Namun pada akhirnya, dimungkinkan untuk menentukan algoritma validasi di cara yang cukup ketat dan efisien seperti yang dilakukan klien mampu bekerja secara efektif dengan parachain baru tanpa a garpu keras. Salah satu jalan yang mungkin untuk melakukan hal ini adalah dengan menentukan algoritma validasi parachain dengan cara yang mapan dan bahasa yang dikompilasi secara asli dan netral platform seperti WebAssembly. Penelitian tambahan diperlukan untuk menentukan apakah hal ini benar-benar layak dilakukan, namun jika demikian, hal ini dapat membawa hasil dengan itu keuntungan luar biasa dari membuang hard-fork untuk selamanya. Informasi dinamis mencakup aspek sistem perutean transaksi yang harus memiliki kesepakatan global tersebut sebagai antrian masuknya parachain (dijelaskan di bagian 6.6). Registri hanya dapat menambahkan parachain melalui pemungutan suara referendum penuh; ini bisa dikelola secara internal tetapi lebih mungkin ditempatkan di eksternal kontrak referendum untuk memfasilitasi penggunaan kembali di bawah komponen tata kelola yang lebih umum. Parameter ke persyaratan pemungutan suara (misalnya kuorum yang diperlukan, mayoritas diperlukan) untuk pendaftaran rantai tambahan dan lainnya, peningkatan sistem yang kurang formal akan ditetapkan dalam “master konstitusi” namun cenderung mengikuti konstitusi yang cukup tradisional jalan, setidaknya pada awalnya. Formulasi tepatnya sudah keluar ruang lingkup untuk pekerjaan ini, tetapi mis. dua pertiga supermayoritas lolos dengan lebih dari sepertiga total sistem pemungutan suara secara positif mungkin merupakan titik awal yang masuk akal. Operasi tambahan termasuk penangguhan dan pelepasan parachain. Mudah-mudahan penangguhan tidak akan pernah terjadi terjadi, namun hal ini dirancang untuk menjadi tindakan pengamanan ada beberapa masalah yang sulit diselesaikan dalam sistem validasi parachain. Contoh paling jelas yang mungkin terjadi yang diperlukan adalah perbedaan penting antara implementasi yang menyebabkan validators tidak dapat menyepakati validitas atau blok. Validator akan didorong untuk menggunakan beberapa implementasi klien agar mereka mampu untuk menemukan masalah seperti itu sebelum penyitaan obligasi. Karena penangguhan adalah tindakan darurat, maka hal itu akan terjadi di bawah naungan pemungutan suara validator yang dinamis daripada referendum. Pengaktifan kembali keduanya dapat dilakukan dari validators atau referendum. Penghapusan parachain sama sekali hanya akan terjadi setelah referendum dan yang diperlukan a masa tenggang yang substansial untuk memungkinkan transisi yang tertib ke baik rantai yang berdiri sendiri atau menjadi bagian dari rantai lainnya sistem konsensus. Masa tenggang kemungkinan besar akan berlangsung selama urutan bulan dan kemungkinan besar akan ditetapkan berdasarkan perchain di registri parachain agar berbeda parachain dapat menikmati masa tenggang yang berbeda-beda sesuai dengan kebutuhan mereka. 6.4. Blok Relai Penyegelan. Penyegelan pada dasarnya mengacu pada pada proses kanonikalisasi; yaitu data dasar mengubah yang manamemetakan yang asli menjadi sesuatu yang pada dasarnya tunggal dan bermakna. Di bawah rantai PoW, penyegelan secara efektif merupakan sinonim dari penambangan. Dalam kasus kami, ini melibatkan pengumpulan pernyataan yang ditandatangani dari validators mengenai validitas, ketersediaan, dan kanonikalitas suatu blok rantai relai tertentu dan blok parachain itu itu mewakili. Mekanisme algoritma konsensus BFT yang mendasarinya berada di luar cakupan penelitian ini. Kami akan melakukannya alih-alih mendeskripsikannya menggunakan primitif yang mengasumsikan a mesin negara yang menciptakan konsensus. Pada akhirnya kami berharap terinspirasi oleh sejumlah konsensus BFT yang menjanjikan algoritma pada intinya; Tangaora [9] (varian BFT dari Rakit [16]), Tendermint [11] dan HoneyBadgerBFT [14]. Algoritmenya harus mencapai kesepakatan mengenai beberapa parachain secara paralel, sehingga berbeda dari biasanya blockchain mekanisme konsensus. Kami berasumsi bahwa sekali konsensus tercapai, kita dapat mencatat konsensus tersebut dalam bukti yang tak terbantahkan yang dapat diberikan oleh siapa pun para peserta di dalamnya. Kami juga berasumsi bahwa perilaku buruk itu dalam protokol umumnya dapat dikurangi menjadi kecil kelompok yang berisi peserta nakal untuk diminimalkan kerusakan tambahan ketika memberikan hukuman.8 Buktinya, yang berupa pernyataan yang kami tandatangani, ditempatkan di header blok rantai relai bersama-sama dengan bidang-bidang tertentu lainnya, tidak terkecuali akar keadaan rantai relai dan akar percobaan transaksi. Itu penyegelan proses dibutuhkan tempat di bawah sebuah lajang menghasilkan konsensus mekanisme menangani keduanya itu blok rantai relai dan blok parachain yang membuatnya bagian dari konten relai: parachain tidak “dikomit” secara terpisah oleh sub-grupnya dan kemudian disusun nanti. Hal ini menghasilkan proses yang lebih kompleks pada rantai relai, namun memungkinkan kami menyelesaikan konsensus seluruh sistem dalam satu tahap, meminimalkan latensi dan memungkinkan untuk persyaratan ketersediaan data yang cukup kompleks berguna untuk proses perutean di bawah ini. 8Skema konsensus BFT berbasis PoS yang ada seperti Tendermint BFT dan Slasher asli memenuhi pernyataan ini.

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 12 Keadaan mesin konsensus masing-masing peserta mungkin berbeda dimodelkan sebagai tabel sederhana (2 dimensi). Setiap peserta (validator) memiliki sekumpulan informasi berupa pernyataan yang ditandatangani (“suara”) dari peserta lain, mengenai setiap kandidat blok parachain serta kandidat blok relaychain. Kumpulan informasinya ada dua bagian data: Ketersediaan: tidak ini validator punya jalan keluar informasi transaksi-posting dari blok ini jadi mereka dapat memvalidasi kandidat parachain dengan benar di blok berikut? Mereka mungkin memilih baik 1 (diketahui) atau 0 (belum diketahui). Sekali mereka memilih 1, mereka berkomitmen untuk memberikan suara yang sama sisa proses ini. Nanti suara yang tidak hormat ini adalah dasar untuk hukuman. Validitas: apakah blok parachain valid dan semuanya data yang direferensikan secara eksternal (mis. transaksi) tersedia? Ini hanya relevan untuk validator yang ditugaskan pada parachain tempat mereka memberikan suara. Mereka dapat memilih 1 (sah), -1 (tidak sah) atau 0 (belum diketahui). Begitu mereka memilih bukan nol, mereka berkomitmen untuk memberikan suara dengan cara ini selama sisa pemilu prosesnya. Nanti ada suara yang tidak menghormati hal ini merupakan dasar untuk hukuman. Semua validator harus menyerahkan suara; suara dapat diserahkan kembali, memenuhi syarat berdasarkan peraturan di atas. Kemajuan dari konsensus dapat dimodelkan sebagai beberapa algoritma konsensus BFT standar pada setiap parachain yang terjadi secara paralel. Karena hal ini berpotensi digagalkan oleh relatif sebagian kecil aktor jahat terkonsentrasi di dalamnya satu kelompok parachain, konsensus keseluruhan ada untuk itu membangun penghalang, membatasi skenario terburuk kebuntuan hanya pada satu atau lebih blok parachain kosong (dan putaran hukuman bagi mereka yang bertanggung jawab). Aturan dasar untuk validitas masing-masing blok (yang memungkinkan total kumpulan validator secara keseluruhan diperoleh konsensus untuk menjadi kandidat parachain yang unik untuk direferensikan dari relai kanonik): • harus memiliki setidaknya dua pertiga dari validator yang memberikan suara positif dan tidak ada yang memberikan suara negatif; • harus memiliki lebih dari sepertiga validator yang memberikan suara positif terhadap ketersediaan informasi antrian keluar. Jika terdapat setidaknya satu suara positif dan setidaknya satu suara negatif mengenai validitas, kondisi luar biasa akan tercipta dan seluruh validator harus memberikan suara untuk menentukan jika ada pihak jahat atau jika ada yang tidak disengaja garpu. Selain sah dan tidak sah, ada pula jenis suara yang ketiga diperbolehkan, setara dengan memilih keduanya, artinya simpul tersebut memiliki pendapat yang bertentangan. Hal ini mungkin disebabkan oleh pemilik node menjalankan beberapa implementasi yang dapat melakukannya tidak setuju, menunjukkan kemungkinan ambiguitas dalam protokol. Setelah semua suara dihitung dari set validator penuh, jika opini yang kalah memiliki setidaknya sebagian kecil (untuk diparameterisasi; paling banyak setengahnya, mungkin jauh lebih sedikit) dari suara pendapat yang menang, maka diasumsikan demikian menjadi parachain fork yang tidak disengaja dan parachain secara otomatis ditangguhkan dari proses konsensus. Jika tidak, kami menganggapnya sebagai tindakan jahat dan akan menghukumnya kelompok minoritas yang memberikan suara dissenting opinion. Kesimpulannya adalah demonstrasi serangkaian tanda tangan kanonikalitas. Blok rantai relai kemudian dapat disegel dan proses penyegelan blok berikutnya dimulai. 6.5. Perbaikan pada Blok Relai Penyegelan. Sementara metode penyegelan ini memberikan jaminan yang kuat atas pengoperasian sistem, namun skalanya tidak terlalu baik karena informasi penting setiap parachain pasti ada ketersediaan dijamin oleh lebih dari sepertiga dari seluruh validators. Artinya, setiap jejak tanggung jawab validator tumbuh seiring bertambahnya rantai. Sedangkan ketersediaan data dalam jaringan konsensus terbuka pada dasarnya adalah masalah yang belum terpecahkan, ada cara untuk mengurangi overhead yang ditempatkan pada validator node. Satu yang sederhana solusinya adalah dengan menyadari bahwa sementara validators harus memikulnya tanggung jawab atas ketersediaan data, mereka tidak perlu menyimpan, mengomunikasikan, atau mereplikasi data itu sendiri. Silo data sekunder, mungkin terkait dengan (atau bahkan sangat terkait). sama) kolektor yang mengumpulkan data ini, dapat mengelola tugas menjamin ketersediaan dengan validators memberikan sebagian dari bunga/pendapatan mereka sebagai pembayaran. Namun, meskipun hal ini mungkin memerlukan skalabilitas menengah, hal ini tetap tidak membantu masalah mendasar; sejak itu menambahkan lebih banyak rantai secara umum akan memerlukan validator tambahan, konsumsi sumber daya jaringan yang berkelanjutan (khususnya dalam hal bandwidth) tumbuh seiring dengan bertambahnya kuadrat iturantai, properti yang tidak dapat dipertahankan dalam jangka panjang. Pada akhirnya, kita cenderung terus-terusan memukul kepala terhadap batasan mendasar yang menyatakan bahwa untuk jaringan konsensus dianggap tersedia aman, itu kebutuhan bandwidth yang sedang berlangsung berada pada urutan total validators kali total informasi masukan. Hal ini disebabkan oleh ketidakmampuan jaringan yang tidak tepercaya untuk mendistribusikan tugas penyimpanan data dengan benar ke banyak node yang berada terlepas dari tugas pemrosesan yang sangat dapat didistribusikan. 6.5.1. Memperkenalkan Latensi. Salah satu cara untuk melunakkannya aturannya adalah melonggarkan gagasan kesegeraan. Dengan mewajibkan 33%+1 validators memberikan suara untuk ketersediaan pada akhirnya, dan tidak segera, kita dapat memanfaatkan propagasi data eksponensial dengan lebih baik dan membantu meratakan puncak dalam pertukaran data. Kesetaraan yang wajar (meskipun tidak terbukti) mungkin: (1) latensi = peserta × rantai Di bawah model saat ini, ukuran sistem berskala dengan jumlah rantai untuk memastikan bahwa pemrosesan dilakukan didistribusikan; karena setiap rantai akan memerlukan setidaknya satu validator dan kami menetapkan pengesahan ketersediaan menjadi konstan proporsi validators, maka peserta juga bertambah dengan jumlah rantai. Kami berakhir dengan: (2) latensi = ukuran2 Artinya seiring pertumbuhan sistem, bandwidth yang dibutuhkan dan latensi hingga ketersediaan diketahui di seluruh sistem jaringan, yang mungkin juga dicirikan sebagai angka blok sebelum finalitas, bertambah seiring dengan kuadratnya. Ini adalah merupakan faktor pertumbuhan yang substansial dan mungkin menjadi penghalang utama serta memaksa kita menerapkan paradigma yang “tidak datar” seperti menyusun beberapa “Polkadotes” ke dalam hierarki untuk perutean postingan multi-level melalui pohon rantai relai.

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 13 6.5.2. Partisipasi Masyarakat. Satu lagi kemungkinan arah adalah untuk menarik partisipasi masyarakat dalam proses tersebut melalui a sistem pengaduan mikro. Mirip dengan nelayan, di sana bisa jadi pihak eksternal yang mengawasi validator yang mengklaim ketersediaan. Tugas mereka adalah menemukan orang yang tampaknya tidak mampu menunjukkan ketersediaan tersebut. Dengan melakukan hal itu mereka dapat mengajukan keluhan mikro ke validator lainnya. PoW atau obligasi yang dipertaruhkan dapat digunakan untuk mengurangi serangan sybil yang akan membuat sebagian besar sistem tidak berguna. 6.5.3. Penjamin Ketersediaan. Rute terakhirnya adalah ke menominasikan set kedua validator terikat sebagai “ketersediaan penjamin”. Ini akan terikat seperti dengan validators normal, dan bahkan dapat diambil dari set yang sama (walaupun jika demikian, mereka akan dipilih dalam jangka waktu yang panjang, setidaknya per sesi). Tidak seperti validator biasa, mereka tidak akan beralih antar parachain melainkan akan melakukannya membentuk satu kelompok untuk membuktikan ketersediaan semua data antar rantai yang penting. Hal ini mempunyai keuntungan dalam melonggarkan kesetaraan antara peserta dan rantai. Pada dasarnya, rantai bisa tumbuh (bersama dengan set rantai asli validator), sedangkan para peserta, dan khususnya mereka yang mengambil bagian dalam perjanjian ketersediaan data, setidaknya dapat tetap berada pada kondisi sub-linear dan sangat mungkin konstan. 6.5.4. Preferensi Pengumpul. Salah satu aspek penting dari hal ini sistem adalah untuk memastikan bahwa ada pilihan yang sehat kolator membuat blok di parachain mana pun. Jika sebuah kolator tunggal mendominasi parachain kemudian beberapa serangan menjadi lebih layak karena kemungkinan kurangnya ketersediaan data eksternal akan menjadi kurang jelas. Salah satu opsinya adalah dengan memberi bobot buatan pada blok parachain mekanisme pseudo-acak untuk mendukung berbagai macam kolator. Dalam contoh pertama, kita memerlukannya sebagai bagian dari mekanisme konsensus yang menguntungkan validator kandidat blok parachain bertekad untuk menjadi “lebih berat”. Demikian pula, kita harus memberi insentif kepada validators untuk mencoba melakukan hal tersebut menyarankan hambatan terberat yang bisa mereka temukan—bisa jadi ini adalah halangan dilakukan dengan membuat sebagian imbalannya sebanding dengan bobot kandidatnya. Untuk memastikan bahwa kolektor diberikan keadilan yang wajar peluang calonnya terpilih sebagai pemenang kandidat secara konsensus, kami membuat bobot spesifik a kandidat blok parachain ditentukan pada fungsi acak yang terhubung dengan setiap kolator. Misalnya saja mengambil ukuran jarak XOR antara alamat kolektor dan beberapa nomor pseudorandom yang aman secara kriptografis ditentukan dekat dengan titik blok yang dibuat (sebuah “tiket kemenangan”). Ini secara efektif memberi masing-masing pengumpul (atau, lebih khusus lagi, alamat masing-masing pengumpul) a peluang acak dari blok kandidat mereka untuk “menang”. semua yang lain. Untuk mengurangi serangan sybil dari seorang kolator tunggal yang “menambang” alamat yang dekat dengan tiket pemenang dan dengan demikian keberadaannya menjadi favorit di setiap blok, kami akan menambahkan beberapa inersia ke alamat collator. Ini mungkin sesederhana mengharuskan mereka untuk memiliki jumlah dana dasar di alamat tersebut. Lebih lanjut pendekatan yang elegan adalah dengan mempertimbangkan kedekatannya dengan tiket pemenang dengan jumlah dana yang diparkir di alamat yang dimaksud. Meskipun pemodelan belum dilakukan, sangat mungkin mekanisme ini bahkan sangat memungkinkan pemangku kepentingan kecil untuk berkontribusi sebagai kolator. 6.5.5. Blok Kelebihan Berat Badan. Jika kumpulan validator dikompromikan, mereka dapat membuat dan mengusulkan blok yang mana valid, membutuhkan banyak waktu untuk mengeksekusi dan memvalidasi. Ini merupakan masalah karena grup validator dapat melakukannya wajar saja membentuk sebuah blok yang membutuhkan waktu yang sangat lama untuk melakukannya mengeksekusi kecuali beberapa informasi tertentu sudah diketahui sehingga memungkinkan jalan pintas, misalnya memfaktorkan yang besar prima. Jika seorang kolator mengetahui informasi itu, maka mereka akan memiliki keuntungan yang jelas jika mendapatkan milik mereka sendiri calon diterima asalkan yang lain sibuk mengolah blok lama. Kami menyebut blok ini kelebihan berat badan. Perlindungan terhadap validator yang mengirimkan dan memvalidasi blok ini sebagian besar berada di bawah kedok yang sama seperti untuk blok tidak valid, meskipun dengan peringatan tambahan: Sejak waktu yang dibutuhkan untuk mengeksekusi sebuah blok (dan dengan demikian statusnya sebagai kelebihan berat badan) bersifat subyektif, hasil akhir dari pemungutan suara perilaku buruk pada dasarnya akan terbagi dalam tiga kubu. Satu kemungkinannya adalah blok tersebut pastinya tidak kelebihan berat badan— dalam hal ini lebih dari dua pertiga menyatakan mampu mengeksekusi blok dalam batas tertentu (misalnya 50% dari total waktu yang diperbolehkan antar blok). Hal lainnya adalah bahwa blok adalah dbenar-benar kelebihan berat badan—ini akan terjadi jika lebih dari dua pertiga menyatakan bahwa mereka tidak dapat mengeksekusi blok tersebut dalam batas tersebut. Satu kemungkinan terakhir adalah sama perpecahan pendapat antara validators. Dalam hal ini, kita mungkin memilih untuk melakukan hukuman yang proporsional. Untuk memastikan validators dapat memprediksi kapan hal tersebut mungkin terjadi mengusulkan blok yang kelebihan berat badan, mungkin masuk akal untuk meminta mereka mempublikasikan informasi tentang kinerja mereka sendiri untuk setiap blok. Dalam jangka waktu yang cukup, ini akan memungkinkan mereka untuk memprofilkan kecepatan pemrosesan mereka relatif terhadap rekan-rekan yang akan menghakimi mereka. 6.5.6. Asuransi Pengumpul. Satu masalah tersisa untuk validators: tidak seperti jaringan PoW, untuk memeriksa collator blok untuk validitas, mereka harus benar-benar mengeksekusi transaksi di dalamnya. Kolator jahat dapat memberi makan blok yang tidak valid atau kelebihan berat badan ke validator yang menyebabkan mereka sedih (terbuang sia-sia) sumber daya mereka) dan menuntut potensi biaya peluang yang besar. Untuk mengurangi hal ini, kami mengusulkan strategi sederhana di bagian dari validators. Pertama, kandidat blok parachain dikirim hingga validators harus ditandatangani dari akun rantai relai dengan dana; jika tidak, maka validator akan hilang segera. Kedua, kandidat tersebut harus diurutkan berdasarkan prioritas dengan kombinasi (misalnya perkalian). jumlah dana di rekening sampai batas tertentu, yaitu jumlah blok sebelumnya yang berhasil diusulkan oleh kolator di masa lalu (belum lagi blok sebelumnya hukuman), dan faktor kedekatan dengan pemenang tiket seperti yang dibahas sebelumnya. Tutupnya harus sama sebagai hukuman ganti rugi yang dibayarkan kepada validator dalam kasus tersebut di antaranya mengirimkan blok yang tidak valid. Untuk mendisinsentifkan kolator agar tidak mengirimkan kandidat blok yang tidak valid atau kelebihan berat badan ke validators, validator mana pun dapat tempatkan di blok berikutnya sebuah transaksi termasuk blok yang menyinggung dugaan perilaku buruk yang berdampak pada transfer sebagian atau seluruh dana ke dalam rekening kolator yang berperilaku buruk. akun kepada validator yang dirugikan. Jenis transaksi ini dijalankan terlebih dahulu oleh orang lain untuk memastikan kolator tidak dapat melakukannya mengeluarkan dana sebelum hukuman. Jumlah dana yang ditransfer sebagai ganti rugi masih merupakan parameter yang dinamis

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 14 untuk dimodelkan tetapi kemungkinan besar akan menjadi proporsi dari hadiah blok validator untuk mencerminkan tingkat kesedihan yang ditimbulkan. Untuk mencegah validator jahat secara sewenang-wenang menyita dana kolektor, kolator dapat mengajukan banding atas keputusan validator dengan juri yang terdiri dari validator yang dipilih secara acak sebagai imbalannya untuk menempatkan deposit kecil. Jika mereka menguntungkan validator, deposit tersebut akan dikonsumsi oleh mereka. Jika tidak, itu deposit dikembalikan dan validator didenda (sejak validator berada dalam posisi yang jauh lebih berkubah, dendanya akan lebih besar mungkin agak besar dan kuat). 6.6. Antar rantai Transaksi Perutean. Antar rantai perutean transaksi adalah salah satu pemeliharaan penting tugas rantai relai dan validatorsnya. Ini adalah logika yang mengatur bagaimana transaksi yang diposting (sering disingkat menjadi “posting”) mendapatkan output yang diinginkan dari satu parachain sumber menjadi masukan yang tidak dapat dinegosiasikan dari parachain tujuan lain tanpa kepercayaan apa pun persyaratan. Kami memilih kata-kata di atas dengan hati-hati; terutama kita tidak mengharuskan adanya transaksi di sumbernya parachain telah secara eksplisit menyetujui postingan ini. Satu-satunya Kendala yang kami tempatkan pada model kami adalah parachain harus disediakan, dikemas sebagai bagian dari keseluruhan bloknya output pemrosesan, postingan yang merupakan hasil dari eksekusi blok. Pos-pos ini disusun sebagai beberapa antrian FIFO; itu jumlah daftar dikenal sebagai basis perutean dan mungkin sekitar 16. Khususnya, angka ini mewakili kuantitas parachain yang dapat kami dukung tanpa harus menggunakan bantuan apa pun perutean multi-fase. Awalnya, Polkadot akan mendukung hal ini jenis perutean langsung, namun kami akan menguraikan satu kemungkinan proses routing multi-fase (“hyper-routing”) sebagai sarana untuk memperluas jangkauannya melewati rangkaian parachain awal. Kami berasumsi itu semua peserta tahu itu subkelompok untuk dua blok berikutnya n, n + 1. Singkatnya, the sistem routing mengikuti tahapan berikut: • CollatorS: Hubungi anggota Validator[n][S] • Kolator: UNTUK SETIAP subgrup: pastikan pada setidaknya 1 anggota Validator[n][s] dalam kontak • Pengumpul: UNTUK SETIAP subgrup s: berasumsi egress[n −1][s][S] tersedia (semua postingan masuk data ke 'S' dari blok terakhir) • Pengumpul: Tulis kandidat blok b untuk S: (b.header, b.ext, b.proof, b.receipt, b.egress) • Pengumpul: Kirim bukti informasi bukti[S] = (b.header, b.ext, b.proof, b.receipt) ke V alidator[n][S] • CollatorS: Pastikan data transaksi eksternal b.ext tersedia untuk kolator lain dan validators • Pengumpul: UNTUK SETIAP subgrup s: Kirim jalan keluar informasi jalan keluar[n][S][s] = (b.header, b.kwitansi, b.egress[s]) untuk itu menerima subkelompok anggota dari berikutnya blok V alidator[n + 1][s] • ValidatorV : Pra-sambungkan semua anggota set yang sama untuk blok selanjutnya: misalkan N = Chain[n + 1][V ]; menghubungkan semua validators v sedemikian rupa sehingga Chain[n + 1][v] = N • V alidatorV : Susun semua data yang masuk untuk ini blok: UNTUK SETIAP subgrup s: Ambil egress[n −1][s][Chain[n][V ]], dapatkan dari validators v lain sedemikian rupa sehingga Chain[n][v] = Chain[n][V ]. Mungkin melalui validator lain yang dipilih secara acak sebagai bukti percobaan. • V alidatorV : Terima bukti kandidat untuk ini bukti blok[Rantai[n][V ]]. Validitas blok suara • V alidatorV : Terima data jalan keluar kandidat untuk blok berikutnya: UNTUK SETIAP subgrup, terima jalan keluar[n][s][N]. Ketersediaan jalan keluar blok suara; publikasikan ulang di antara validators v yang tertarik sedemikian rupa Rantai[n + 1][v] = Rantai[n + 1][V ]. • ValidatorV : SAMPAI KONSENSUS Dimana: egress[n][from][to] adalah antrian egress saat ini informasi untuk postingan mulai dari parachain 'dari', ke parachain 'ke' di blok nomor 'n'. CollatorS adalah collator untuk parachain S. V alidators[n][s] adalah himpunan validators untuk parachain s di blok nomor n. Sebaliknya, Chain[n][v] adalah parachain yang validator v ditugaskan pada blok nomor n. block.egress[to] adalah jalan keluar antrian posting dari beberapa blok parachain yang parachain tujuan adalah untuk. Karena kolektor memungut biaya (transaksi) berdasarkan blok mereka menjadi kanonik dan mereka diberi insentif memastikan bahwa untuk setiap tujuan blok berikutnya, subgrupnya anggota diberitahu tentang antrian keluar dari sekarang blok. Validator diberi insentif hanya untuk membentuk konsensus pada blok (parachain), sehingga mereka tidak terlalu peduli blok kolator mana yang pada akhirnya menjadi kanonik. Di prinsipnya, seorang validator dapat membentuk kesetiaan dengan seorang kolator dan bersekongkol untuk mengurangi kemungkinan kolator lain blok menjadi kanonik, namun hal ini sulit untuk mengatur karena pemilihan acaktindakan validators untuk parachain dan dapat dilindungi dengan pengurangan biaya yang harus dibayar untuk blok parachain yang bertahan proses konsensus. 6.6.1. Ketersediaan Data Eksternal. Memastikan parachain data eksternal sebenarnya tersedia adalah masalah abadi sistem terdesentralisasi yang bertujuan untuk mendistribusikan beban kerja jaringan. Inti permasalahannya adalah ketersediaan masalah yang menyatakan bahwa karena itu tidak mungkin buatlah bukti ketersediaan non-interaktif atau jenis apa pun bukti ketidaktersediaan, agar sistem BFT berfungsi dengan baik memvalidasi setiap transisi yang kebenarannya bergantung pada ketersediaan beberapa data eksternal, jumlah maksimum dari node Bizantium yang dapat diterima, ditambah satu, dari sistem harus membuktikan data yang tersedia. Agar sistem dapat melakukan penskalaan dengan benar, seperti Polkadot, ini mengundang masalah: jika proporsi konstan validators harus membuktikan ketersediaan data, dan berasumsi bahwa validators ingin benar-benar menyimpan data sebelum menyatakannya tersedia, lalu bagaimana kita menghindarinya masalah kebutuhan bandwidth/penyimpanan yang meningkat seiring dengan ukuran sistem (dan karenanya jumlah validators)? Salah satu jawaban yang mungkin adalah dengan memiliki set terpisah dari validators (penjamin ketersediaan), yang pesanannya bertambah secara sublinear dengan ukuran Polkadot secara keseluruhan. Ini adalah dijelaskan dalam 6.5.3. Kami juga memiliki trik sekunder. Sebagai sebuah kelompok, pengumpul memiliki insentif intrinsik untuk memastikan bahwa semua data ada tersedia untuk parachain pilihan mereka karena tanpa itu mereka tidak dapat membuat blok lebih jauh dari yang mereka bisa mengumpulkan biaya transaksi. Kolator juga membentuk suatu kelompok, yang keanggotaannya bervariasi (karena sifat acaknya parachain validator grup) tidak sepele untuk dimasuki dan mudah

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 15 untuk membuktikan. Oleh karena itu, kolator baru-baru ini (mungkin dari beberapa ribu blok terakhir) diperbolehkan untuk mengajukan gugatan ketersediaan data eksternal untuk parachain tertentu blok ke validators untuk obligasi kecil. Validator harus menghubungi orang-orang dari subkelompok validator yang tampaknya melakukan pelanggaran yang memberikan kesaksian dan memperoleh serta mengembalikan data ke pengumpul atau mengeskalasi masalah dengan memberikan kesaksian tentang kurangnya ketersediaan (penolakan langsung untuk memberikan data dianggap sebagai pelanggaran penyitaan obligasi, oleh karena itu validator yang berperilaku buruk kemungkinan besar hanya akan putuskan sambungan) dan hubungi validator tambahan untuk menjalankan tes yang sama. Dalam kasus terakhir, obligasi kolator dikembalikan. Setelah kuorum validator yang dapat membuat kesaksian ketidaktersediaan tersebut tercapai, mereka dibebaskan, subkelompok yang berperilaku buruk akan dihukum, dan pemblokiran dikembalikan. 6.6.2. Perutean Postingan. Setiap header parachain menyertakan jalan keluar-trie-root; ini adalah akar dari percobaan yang mengandung bin berbasis perutean, setiap bin menjadi daftar gabungan dari pos-pos jalan keluar. Bukti merekle dapat diberikan di seluruh parachain validators untuk membuktikan bahwa parachain tertentu blok memiliki antrian keluar tertentu untuk parachain tujuan tertentu. Pada awal pemrosesan blok parachain, masing-masing antrian keluar parachain lain yang menuju blok tersebut adalah digabungkan ke dalam antrian masuknya blok kami. Kami berasumsi kuat, mungkin CSPR9, sub-blok yang memerintahkan untuk mencapai operasi deterministik yang tidak menawarkan pilih kasih di antara siapa pun pasangan blok parachain. Collator menghitung antrian baru dan menguras antrian jalan keluar sesuai dengan parachain logika. Isi antrian ingress ditulis secara eksplisit ke dalam blok parachain. Ini memiliki dua tujuan utama: pertama, ini berarti bahwa parachain dapat disinkronkan secara terpisah dari parachain lainnya. Kedua, ini menyederhanakan logistik data jika seluruh masuknya antrian tidak dapat diproses dalam satu blok; validators dan collator dapat memproses blok berikut tanpa harus mengambil data antrian secara khusus. Jika antrian masuknya parachain berada di atas ambang batas jumlah di akhir pemrosesan blok, kemudian ditandai jenuh pada rantai relai dan mungkin tidak ada pesan lebih lanjut dikirim ke sana sampai dibersihkan. Bukti Merkle adalah digunakan untuk menunjukkan kesetiaan operasi collator di bukti blok parachain. 6.6.3. Kritik. Satu kelemahan kecil yang berkaitan dengan dasar ini mekanismenya adalah serangan pasca bom. Di sinilah semuanya parachain mengirim postingan sebanyak mungkin ke parachain tertentu. Sementara ini mengikat targetnya antrian masuk sekaligus, tidak ada kerusakan yang terjadi berulang-ulang serangan DoS transaksi standar. Beroperasi secara normal, dengan serangkaian tersinkronisasi dengan baik dan collators tidak berbahaya dan validators, untuk N parachain, N × M total validators dan L kolator per parachain, kami dapat memecah total jalur data per blok menjadi: Validator: M −1+L+L: M −1 untuk validators lainnya di set parachain, L untuk setiap kolator menyediakan calon blok parachain dan L kedua untuk setiap kolator dari blok berikutnya yang memerlukan muatan keluar dari blok sebelumnya. (Yang terakhir ini sebenarnya lebih mirip kasus terburuk operasi karena kemungkinan besar kolator akan berbagi hal tersebut data.) Collator: M +kN: M untuk koneksi ke setiap relevan blok parachain validator, kN untuk menyemai muatan keluar ke beberapa subset dari setiap grup parachain validator untuk blok berikutnya (dan mungkin beberapa kolator favorit). Dengan demikian, jalur jalur data per node tumbuh secara linier dengan kompleksitas sistem secara keseluruhan. Sementara ini masuk akal, karena sistem berskala menjadi ratusan atau ribuan parachain, mungkin ada beberapa latensi komunikasi diserap dengan imbalan tingkat pertumbuhan kompleksitas yang lebih rendah. Dalam hal ini, algoritma perutean multi-fase dapat digunakan untuk mengurangi jumlah jalur sesaat dengan biaya memperkenalkan buffer penyimpanan dan latensi. 6.6.4. Perutean hiper-kubus. Perutean hyper-cube adalah mekanisme yang sebagian besar dapat dibangun sebagai perpanjangan dari mekanisme perutean dasar yang dijelaskan di atas. Intinya, daripada mengembangkan konektivitas node dengan jumlah parachain dan node sub-grup, kami hanya mengembangkannya logaritma parachain. Postingan mungkin transit di antara keduanya antrian beberapa penerjun payung dalam perjalanan menuju pengiriman akhir. Perutean itu sendiri bersifat deterministik dan sederhana. Kita mulai dengan membatasi jumlah sampah pada antrian masuk/keluar; bukannya jumlah total parachain, mereka adalahbasis perutean (b) . Ini akan ditetapkan sebagai nomornya perubahan parachain, dengan eksponen perutean (e) malah dinaikkan. Di bawah model ini, volume pesan kami tumbuh dengan O(be), dengan jalurnya tetap konstan dan latensi (atau jumlah blok yang diperlukan untuk pengiriman) dengan O(e). Model perutean kami adalah hypercube berdimensi e, dengan setiap sisi kubus memiliki b kemungkinan lokasi. Setiap blok, kami merutekan pesan sepanjang satu sumbu. Kami ganti sumbu dengan cara round-robin, sehingga menjamin waktu pengiriman blok e dalam kasus terburuk. Sebagai bagian dari pemrosesan parachain, terikat ke luar negeri pesan yang ditemukan dalam antrean masuk akan segera dirutekan ke tempat antrean keluar yang sesuai, mengingat nomor blok saat ini (dan dengan demikian dimensi perutean). Ini proses memerlukan transfer data tambahan untuk setiap hop pada jalur pengiriman, namun hal ini menjadi masalah tersendiri yang dapat dikurangi dengan menggunakan beberapa cara alternatif pengiriman muatan data dan hanya menyertakan referensi, daripada muatan penuh postingan di pasca-trie. Contoh perutean hyper-cube untuk suatu sistem dengan 4 parachain, b = 2 dan e = 2 mungkin: Fase 0, pada setiap pesan M: • sub0: jika Mdest ∈{2, 3} maka sendTo(2) lain tetap simpan • sub1: jika Mdest ∈{2, 3} maka sendTo(3) lain tetap simpan • sub2: jika Mdest ∈{0, 1} maka sendTo(0) lain tetap simpan • sub3: jika Mdest ∈{0, 1} maka sendTo(1) lain tetap simpan Fase 1, pada setiap pesan M: • sub0: jika Mdest ∈{1, 3} maka sendTo(1) lain tetap simpan • sub1: jika Mdest ∈{0, 2} maka sendTo(0) lain tetap simpan • sub2: jika Mdest ∈{1, 3} maka sendTo(3) lain tetap simpan • sub3: jika Mdest ∈{0, 2} maka sendTo(2) lain tetap simpan Dua dimensi di sini mudah dilihat sebagai yang pertama dua bit indeks tujuan; untuk blok pertama, itu bit tingkat tinggi saja yang digunakan. Penawaran blok kedua dengan bit orde rendah. Setelah keduanya terjadi (secara sewenang-wenang order) maka postingan akan dialihkan. 9pseudo-acak yang aman secara kriptografis

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 16 6.6.5. Memaksimalkan Kebetulan. Satu perubahan dasar proposal akan menghasilkan total tetap c2 −c validators, dengan c−1 validators di setiap subgrup. Setiap blok, bukan ada partisi ulang validators yang tidak terstruktur di antara parachain, sebagai gantinya untuk setiap subkelompok parachain, setiap validator akan ditugaskan ke yang unik dan berbeda sub-grup parachain di blok berikut. Ini akan terjadi mengarah ke invarian antara dua blok mana pun, untuk apa pun dua pasang parachain, ada dua validator yang telah bertukar tanggung jawab parachain. Meskipun hal ini tidak dapat digunakan untuk mendapatkan jaminan mutlak atas ketersediaan (satu validator kadang-kadang akan offline, meskipun demikian baik hati), namun tetap dapat mengoptimalkan kasus umum. Pendekatan ini bukannya tanpa komplikasi. Penambahan parachain juga memerlukan reorganisasi dari kumpulan validator. Selanjutnya jumlah validator, diikat dengan kuadrat jumlah parachain, awalnya akan sangat kecil dan akhirnya berkembang jauh terlalu cepat, menjadi tidak dapat dipertahankan setelah sekitar 50 parachain. Tidak ada satu pun dari masalah-masalah tersebut yang merupakan masalah mendasar. Dalam kasus pertama, reorganisasi set validator adalah sesuatu yang harus dilakukan tetap dilakukan secara rutin. Mengenai ukuran validator disetel, jika terlalu kecil, beberapa validator dapat ditetapkan ke parachain yang sama, menerapkan faktor bilangan bulat ke total keseluruhan validators. Mekanisme perutean multi-fase seperti Perutean Hypercube, yang dibahas di 6.6.4 akan membantu meringankan kebutuhan validator dalam jumlah besar ketika ada sejumlah besar rantai. 6.7. Validasi Parachain. Tujuan utama validator adalah untuk bersaksi, sebagai aktor yang mempunyai ikatan kuat, bahwa parachain itu blok tersebut valid, termasuk namun tidak terbatas pada transisi keadaan apa pun, termasuk transaksi eksternal apa pun, pelaksanaannya setiap pos tunggu di antrian masuk dan keadaan akhir dari antrian keluar. Prosesnya sendiri cukup sederhana. Setelah validator menyegel blok sebelumnya, mereka bebas untuk mulai bekerja menyediakan calon blok parachain kandidat untuk putaran konsensus berikutnya. Awalnya, validator menemukan kandidat blok parachain melalui kolator parachain (dijelaskan selanjutnya) atau satu dari rekannya-validators. Parachain memblokir data kandidat termasuk header blok, header blok sebelumnya, data masukan eksternal apa pun yang disertakan (untuk Ethereum dan Bitcoin, data tersebut akan disebut sebagai transaksi, namun pada prinsipnya data tersebut dapat mencakup struktur data arbitrer untuk tujuan arbitrer), data antrean keluar, dan data internal untuk membuktikan validitas transisi keadaan (untuk Ethereum ini akan menjadi berbagai node percobaan status/penyimpanan yang diperlukan untuk mengeksekusi setiap transaksi). Bukti eksperimental menunjukkan kumpulan data lengkap ini untuk blok Ethereum terbaru menjadi paling banyak beberapa ratus KiB. Secara bersamaan, jika belum dilakukan, validator akan menjadi mencoba mengambil informasi yang berkaitan dengan transisi blok sebelumnya, awalnya dari blok sebelumnya validators dan setelahnya dari semua validators yang menandatangani ketersediaan datanya. Setelah validator menerima blok kandidat tersebut, mereka kemudian memvalidasinya secara lokal. Proses validasi terdapat dalam modul validator kelas parachain, a modul perangkat lunak sensitif konsensus yang harus ditulis untuk setiap implementasi Polkadot (meskipun pada prinsipnya perpustakaan dengan C ABI dapat mengaktifkan satu perpustakaan dibagi antara implementasi dengan yang sesuai pengurangan keselamatan karena hanya memiliki satu implementasi “referensi”). Proses ini mengambil header blok sebelumnya dan memverifikasi identitasnya melalui rantai relai yang baru saja disepakati blok di mana hash-nya harus dicatat. Setelah validitas header induk dipastikan, parachain tertentu fungsi validasi kelas dapat dipanggil. Ini adalah fungsi tunggal yang menerima sejumlah bidang data (kira-kira yang diberikan sebelumnya) dan mengembalikan Boolean sederhana menyatakan keabsahan blok tersebut. Sebagian besar fungsi validasi tersebut akan memeriksa terlebih dahulu bidang header yang dapat diturunkan langsung darinya blok induk (misalnya induk hash, nomor). Mengikuti ini, mereka akan mengisi struktur data internal apa pun sebagai diperlukan dalam rangka proses transaksi dan/atau postingan. Untuk rantai mirip Ethereum, jumlah ini sama dengan mengisi a coba database dengan node yang akan diperlukan untuk eksekusi penuh transaksi. Jenis rantai lain mungkin memilikinya hal lainnyamekanisme perbaikan. Setelah selesai, postingan masuk dan transaksi eksternal (atau apa pun yang diwakili oleh data eksternal) akan ditampilkan diberlakukan, seimbang sesuai dengan spesifikasi rantai. (A default yang masuk akal mungkin mengharuskan semua postingan masuk diproses sebelum transaksi eksternal dilayani, namun hal ini harus ditentukan oleh logika parachain.) Melalui pemberlakuan ini, akan ada serangkaian posko keluar dibuat dan akan diverifikasi bahwa ini memang cocok calon kolator. Akhirnya, penduduknya cukup header akan diperiksa terhadap header kandidat. Dengan blok kandidat yang divalidasi sepenuhnya, validator kemudian dapat memilih hash dari headernya dan mengirimkan semua informasi validasi yang diperlukan ke co-validators di subgrupnya. 6.7.1. Kolator Parachain. Kolator parachain adalah operator tidak terikat yang memenuhi sebagian besar tugas penambang pada jaringan blockchain saat ini. Mereka spesifik ke parachain tertentu. Untuk beroperasi mereka harus pertahankan rantai relai dan sinkronisasi penuh parachain. Arti sebenarnya dari “disinkronkan sepenuhnya” akan bergantung pada kelas parachain, meskipun akan selalu mencakup keadaan antrean masuknya parachain saat ini. Dalam kasus Ethereum, hal ini juga melibatkan setidaknya pemeliharaan database Merkle-tree dari beberapa blok terakhir, tapi mungkin juga menyertakan berbagai struktur data lainnya termasuk Bloom filter untuk keberadaan akun, informasi keluarga, pencatatan output dan tabel pencarian terbalik untuk nomor blok. Selain menjaga kedua rantai tetap sinkron, itu juga harus “memancing” transaksi dengan menjaga antrian transaksi dan menerima transaksi yang divalidasi dengan benar dari jaringan publik. Dengan antrian dan rantai, itu benar mampu membuat kandidat blok baru untuk validator yang dipilih di setiap blok (yang identitasnya diketahui sejak rantai relai disinkronkan) dan mengirimkannya, bersama dengan berbagai informasi tambahan seperti bukti validitas, via jaringan rekan. Untuk masalahnya, ia memungut semua biaya yang berkaitan dengan transaksi yang disertakannya. Berbagai ilmu ekonomi beredar seputar hal ini pengaturan. Di pasar yang sangat kompetitif di mana ada jika kelebihan kolator, kemungkinan transaksinya biaya dibagikan dengan parachain validators untuk memberi insentif dimasukkannya blok kolator tertentu. Demikian pula,

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 17 beberapa kolator bahkan mungkin menaikkan biaya yang diperlukan harus dibayar agar blok tersebut lebih menarik validators. Dalam hal ini, pasar alami harus terbentuk dengan transaksi yang membayar biaya lebih tinggi melewati antrian dan memiliki inklusi yang lebih cepat dalam rantai. 6.8. Jaringan. Jaringan pada blockchains tradisional seperti Ethereum dan Bitcoin memiliki persyaratan yang cukup sederhana. Semua transaksi dan blokir disiarkan dalam gosip sederhana yang tidak terarah. Sinkronisasi lebih terlibat, khususnya dengan Ethereum tetapi kenyataannya logika ini terkandung di dalamnya strategi rekan daripada protokol itu sendiri yang menyelesaikan beberapa jenis pesan permintaan dan jawaban. Meskipun Ethereum membuat kemajuan pada penawaran protokol saat ini dengan protokol devp2p, yang memungkinkan banyak hal subprotokol yang akan dimultipleks melalui satu koneksi peer dan dengan demikian memiliki banyak dukungan peer overlay yang sama protokol p2p secara bersamaan, bagian Ethereum dari protokolnya masih relatif sederhana dan p2p protokol untuk sementara waktu masih belum selesai dengan hal-hal penting fungsionalitas hilang seperti dukungan QoS. Sayangnya, ada keinginan untuk membuat protokol “web 3” yang lebih umum gagal, dengan satu-satunya proyek yang menggunakannya secara eksplisit didanai dari penjualan massal Ethereum. Persyaratan untuk Polkadot lebih substansial. Daripada jaringan yang sepenuhnya seragam, Polkadot memiliki beberapa jenis peserta yang masing-masing memiliki persyaratan berbeda mengenai susunan rekannya dan beberapa jaringan “jalan” yang cenderung dibicarakan oleh peserta data tertentu. Ini berarti hamparan jaringan yang jauh lebih terstruktur—dan protokol yang mendukungnya— kemungkinan besar akan diperlukan. Selain itu, perluasan untuk memfasilitasi penambahan di masa depan seperti “rantai” jenis baru mungkin terjadi sendiri memerlukan struktur overlay baru. Sedangkan pembahasan mendalam tentang cara networking protokol mungkin terlihat berada di luar cakupan dokumen ini, beberapa analisis persyaratan masuk akal. Kita bisa secara kasar membagi peserta jaringan kami menjadi dua set (rantai relai, parachain) masing-masing dari tiga himpunan bagian. Kita bisa juga menyatakan bahwa masing-masing peserta parachain saja tertarik untuk berbicara di antara mereka sendiri dan bukannya peserta di parachain lainnya: • Peserta rantai relai: • Validator: P, dibagi menjadi himpunan bagian P[s] untuk masing-masingnya parachain • Penjamin Ketersediaan: A (ini dapat diwakili oleh Validator dalam bentuk dasar protokol) • Klien rantai relai: M (perhatikan anggota masing-masing set parachain juga akan cenderung menjadi anggota M) • Peserta Parachain: • Pengumpul Parachain: C[0], C[1], . . . • Nelayan Parachain: F[0], F[1], . . . • Klien Parachain: S[0], S[1], . . . • Klien ringan Parachain: L[0], L[1], . . . Secara umum kami menyebutkan kelas-kelas komunikasi tertentu akan cenderung terjadi di antara anggota himpunan ini: • P | SEBUAH <-> P | J: Itu penuh mengatur dari validators/penjamin harus menjadi terhubung dengan baik untuk mencapai konsensus. • P[s] <-> C[s] | P[s]: Setiap validator sebagai anggota grup parachain tertentu akan cenderung bergosip dengan anggota lainnya serta kolator parachain itu untuk menemukan dan berbagi kandidat blok. • A <-> P[s] | C | A: Setiap penjamin ketersediaan perlu mengumpulkan lintas rantai yang sensitif terhadap konsensus data dari validator yang ditugaskan padanya; kolator juga dapat mengoptimalkan peluang konsensus mengenai hal tersebut memblokir dengan mengiklankannya ke penjamin ketersediaan. Begitu mereka punya, datanya akan dicairkan ke penjamin lainnya untuk memfasilitasi konsensus. • P[s] <-> A | P[s']: Parachain validators akan perlu mengumpulkan data masukan tambahan dari kumpulan validator sebelumnya atau penjamin ketersediaan. • F[s] <-> P: Saat melaporkan, nelayan boleh menempatkan klaim dengan peserta mana pun. • M <-> M | P | J: Klien rantai relai umum menyalurkan data dari validator dan penjamin. • S[s] <-> S[s] | P[s] | A: Klien Parachain mencairkan data dari validator/penjamin. • L[s] <-> L[s] | S[s]: Klien ringan Parachain menyalurkan data dari klien penuh. Untuk memastikan mekanisme transportasi yang efisien, “flat” jaringan overlay—seperti devp2p Ethereum—di mana masing-masing node tidak (secara tidak sewenang-wenang) membedakan kebugarannya teman sebaya sepertinya tidak cocok. Cukup dapat diperluas mekanisme seleksi dan penemuan rekan mungkin diperlukan untuk dimasukkan dalam protokol serta agresif merencanakan tinjauan ke depan untuk memastikan jenis rekan yang tepat adalah conne yang “secara kebetulan”.diperiksa pada waktu yang tepat. Strategi tata rias teman yang tepat akan berbeda untuk setiap kelas peserta: untuk skala yang tepat multi-rantai, collator harus terus menerus menghubungkan kembali ke validator yang dipilih, atau wasiat memerlukan perjanjian berkelanjutan dengan subkumpulan validators untuk memastikan mereka tidak terputus selama sebagian besar waktu mereka tidak berguna untuk validator itu. Collator juga secara alami akan berusaha mempertahankannya atau koneksi yang lebih stabil menjadi penjamin ketersediaan ditetapkan untuk memastikan penyebaran cepat dari isu-isu yang sensitif terhadap konsensus data. Penjamin ketersediaan sebagian besar bertujuan untuk mempertahankan a koneksi yang stabil satu sama lain dan ke validators (untuk konsensus dan data parachain yang penting bagi konsensus mereka membuktikannya), serta beberapa kolator (untuk parachain data) dan beberapa nelayan dan klien penuh (untuk menyebar informasi). Validator akan cenderung mencari validator lain, terutama yang berada dalam subgrup yang sama dan apa pun collators yang dapat memasok mereka dengan kandidat blok parachain. Nelayan, serta rantai estafet umum dan parachain klien umumnya bertujuan untuk menjaga koneksi tetap terbuka untuk a validator atau penjamin, tetapi banyak node lain yang serupa untuk diri mereka sendiri sebaliknya. Klien ringan parachain juga bertujuan untuk terhubung ke klien penuh parachain, jika bukan hanya klien ringan parachain lainnya. 6.8.1. Masalah Peer Churn. Dalam proposal protokol dasar, masing-masing himpunan bagian ini terus-menerus berubah secara acak dengan setiap blok ketika validator ditugaskan untuk memverifikasi transisi parachain dipilih secara acak. Ini bisa menjadi masalah jika node yang berbeda (non-peer) memerlukannya meneruskan data antara satu sama lain. Kita harus mengandalkannya jaringan rekan yang terdistribusi secara adil dan terhubung dengan baik

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 18 memastikan bahwa jarak hop (dan latensi terburuk) hanya bertambah seiring dengan logaritma ukuran jaringan (protokol seperti Kademlia [13] dapat membantu di sini), atau seseorang harus melakukannya memperkenalkan waktu blok yang lebih lama untuk memungkinkan negosiasi koneksi yang diperlukan berlangsung untuk mempertahankan kumpulan rekan itu mencerminkan kebutuhan komunikasi node saat ini. Tak satu pun dari solusi ini yang bagus: waktu blok yang lama dipaksakan pada jaringan dapat membuatnya tidak berguna aplikasi dan rantai tertentu. Bahkan sangat adil dan jaringan yang terhubung akan menghasilkan pemborosan yang besar bandwidth saat diskalakan karena adanya node yang tidak tertarik untuk meneruskan data yang tidak berguna bagi mereka. Meskipun kedua arah mungkin merupakan bagian dari solusi, pengoptimalan yang masuk akal untuk membantu meminimalkan latensi menjadi untuk membatasi volatilitas parachain ini validator set, baik menugaskan kembali keanggotaan hanya di antara rangkaian blok (misalnya dalam kelompok 15, yang dalam waktu 4 detik waktu blok berarti mengubah koneksi hanya sekali per menit) atau dengan merotasi keanggotaan secara bertahap, misalnya diubah oleh satu anggota pada satu waktu (misalnya jika ada adalah 15 validator yang ditugaskan ke setiap parachain, maka rata-rata akan memakan waktu satu menit penuh antara parachain yang benar-benar unik set). Dengan membatasi jumlah peer churn, dan memastikan bahwa koneksi peer yang menguntungkan terjalin dengan baik maju melalui prediktabilitas parsial parachain set, kami dapat membantu memastikan setiap node tetap permanen pemilihan rekan secara kebetulan. 6.8.2. Jalur menuju Protokol Jaringan yang Efektif. Kemungkinan besar upaya pembangunan yang paling efektif dan masuk akal akan fokus pada pemanfaatan protokol yang sudah ada milik kita sendiri. Ada beberapa protokol basis peer-to-peer yang ada kami dapat menggunakan atau menambah termasuk devp2p milik Ethereum [22], libp2p IPFS [1] dan GNUnet [4] GNU. Tinjauan lengkap mengenai protokol-protokol ini dan relevansinya untuk membangun a jaringan peer modular yang mendukung jaminan struktural tertentu, peer steering dinamis, dan sub-protokol yang dapat diperluas jauh di luar cakupan dokumen ini tetapi akan menjadi langkah penting dalam implementasi Polkadot. 7. Kepraktisan Protokol 7.1. Pembayaran Transaksi Antar Rantai. Meskipun bagus sejumlah besar kebebasan dan kesederhanaan diperoleh dengan menghilangkan kebutuhan akan kerangka akuntansi sumber daya komputasi holistik seperti gas Ethereum, hal ini menimbulkan pertanyaan penting: tanpa gas, bagaimana sebuah parachain bisa bekerja? menghindari parachain lain memaksanya melakukan komputasi? Sementara kita bisa mengandalkan antrian transaksi-pasca masuknya buffer untuk mencegah satu rantai mengirim spam ke rantai lainnya data transaksi, tidak ada mekanisme setara yang disediakan oleh protokol untuk mencegah spamming dalam pemrosesan transaksi. Ini adalah masalah yang diserahkan pada tingkat yang lebih tinggi. Sejak rantai bebas untuk melampirkan semantik sewenang-wenang ke yang masuk data transaksi-posting, kami dapat memastikan perhitungan itu harus dibayar sebelum memulai. Senada dengan itu model yang dianut oleh Ethereum Ketenangan, bisa kita bayangkan kontrak “pembobolan” dalam parachain yang memungkinkan a validator untuk mendapatkan jaminan pembayaran sebagai imbalan atas penyediaan sejumlah sumber daya pemrosesan tertentu. Sumber daya ini dapat diukur dalam bentuk seperti gas, namun bisa juga berupa model yang benar-benar baru seperti model waktu-untuk-eksekusi yang subyektif atau model biaya tetap seperti Bitcoin. Dengan sendirinya, hal ini tidak terlalu berguna karena kita tidak dapat langsung berasumsi bahwa penelepon off-chain telah tersedia untuk mereka mekanisme nilai apa pun yang dikenali oleh pembobolan tersebut kontrak. Namun, kita dapat membayangkan kontrak “breakout” sekunder dalam rantai sumber. Kedua kontrak tersebut bersama-sama akan membentuk jembatan, saling mengenal dan memberikan kesetaraan nilai. (Staking-tokens, tersedia untuk masing-masing, dapat digunakan untuk menyelesaikan neraca pembayaran.) Memanggil rantai lain seperti itu berarti melakukan proxy melalui jembatan ini, yang akan menyediakan sarana menegosiasikan transfer nilai antar rantai untuk membayar sumber daya komputasi yang diperlukan pada parachain tujuan. 7.2. Tambahan Rantai. Sementara itu tambahan dari sebuah parachain adalah operasi yang relatif murah, tidak gratis. Lebih banyak parachain berarti lebih sedikit validator per parachain dan, pada akhirnya, sejumlah validator yang lebih besar masing-masing dengan a obligasi rata-rata berkurang. Sementara masalah biaya paksaan yang lebih kecil untuk menyerang parachain dapat diatasi nelayan, pertumbuhan validator pada dasarnya memaksa a tingkat latensi yang lebih tinggi karena mekanisme konsensus yang mendasari sayaitu. Selanjutnya masing-masing parachain membawa serta potensi kesedihan validators dengan an algoritma validasi yang terlalu membebani. Dengan demikian, akan ada “harga” tertentu yang validators dan/atau komunitas pemangku kepentingan akan mengekstraksi untuk penambahan parachain baru. Pasar rantai ini akan melakukannya mungkin melihat penambahan: • Rantai yang kemungkinan besar tidak membayar kontribusi bersih (dalam hal mengunci atau membakar staking tokens) untuk dijadikan bagian (misalnya rantai konsorsium, Rantai Doge, rantai khusus aplikasi); • rantai yang memberikan nilai intrinsik pada jaringan melalui penambahan fungsionalitas tertentu yang sulit untuk mencapai tujuan lain (misalnya kerahasiaan, skalabilitas internal, ikatan layanan). Pada dasarnya, komunitas pemangku kepentingan perlu melakukan hal tersebut mendapatkan insentif untuk menambah rantai anak—baik secara finansial maupun melalui keinginan untuk menambahkan rantai fitur ke relai. Diharapkan bahwa penambahan rantai baru akan memberikan dampak yang sangat besar periode pemberitahuan singkat untuk penghapusan, memungkinkan rantai baru untuk melakukan penghapusan dapat dicoba tanpa risiko kompromi proposisi nilai jangka menengah atau panjang. 8. Kesimpulan Kami telah menguraikan arah yang mungkin diambil untuk penulis a protokol multi-rantai yang heterogen dan terukur dengan potensi untuk kompatibel dengan protokol tertentu yang sudah ada sebelumnya blockchain jaringan. Di bawah protokol seperti itu, para peserta bekerja demi kepentingan pribadi untuk menciptakan sistem keseluruhan yang dapat diperluas dengan cara yang sangat gratis dan tanpa biaya yang biasa bagi pengguna yang sudah ada. berasal dari desain standar blockchain. Kami telah memberi garis besar arsitektur yang diperlukan termasuk sifat peserta, insentif ekonomi mereka dan proses yang harus mereka ikuti. Kita punya mengidentifikasi desain dasar dan mendiskusikan kekuatannya dan keterbatasan; oleh karena itu kami memiliki petunjuk lebih lanjut yang mana dapat meringankan keterbatasan tersebut dan memberikan landasan lebih lanjut menuju solusi blockchain yang sepenuhnya dapat diskalakan.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 19 8.1. Materi Hilang dan Pertanyaan Terbuka. Forking jaringan selalu merupakan kemungkinan dari implementasi protokol yang berbeda. Pemulihan dari hal seperti itu kondisi luar biasa tidak dibahas. Mengingat jaringan akan mempunyai periode penyelesaian yang bukan nol, pemulihan dari forking rantai relai seharusnya tidak menjadi masalah besar, namun memerlukan integrasi yang cermat protokol konsensus. Penyitaan obligasi dan sebaliknya pemberian imbalan telah terjadi belum dieksplorasi secara mendalam. Saat ini kami menerima imbalan disediakan berdasarkan prinsip pemenang mengambil semuanya: hal ini mungkin tidak berlaku memberikan model insentif terbaik bagi nelayan. Proses pengungkapan komitmen jangka pendek akan memungkinkan banyak nelayan untuk mengklaim hadiah dengan memberikan distribusi hadiah yang lebih adil, namun proses tersebut dapat menyebabkan latensi tambahan di penemuan perilaku buruk. 8.2. Ucapan Terima Kasih. Terima kasih banyak untuk semuanya pembaca bukti yang telah membantu menjelaskan hal ini secara samar-samar bentuk yang rapi. Secara khusus, Peter Czaban, Bj¨orn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler dan Jack Petersson. Terima kasih untuk semuanya orang-orang yang telah menyumbangkan ide atau permulaan Oleh karena itu, Marek Kotewicz dan Aeron Buchanan layak mendapat perhatian khusus. Dan terima kasih kepada semua orang atas bantuan mereka sepanjang jalan. Semua kesalahan adalah kesalahan saya sendiri. Bagian dari pekerjaan ini, termasuk penelitian awal algoritma konsensus, sebagian didanai oleh Inggris Pemerintah di bawah program Innovate UK.

Протокол в деталях

Протокол можно условно разбить на три части: механизм консенсуса, интерфейс парачейна. и маршрутизация межцепочных транзакций. 6.1. Релейная цепь Операция. релейная цепь будет вероятно, это цепочка, во многом похожая на Ethereum тем, что она основан на состоянии с адресом сопоставления состояния учетной записи информация, в основном балансы и (во избежание повторов) счетчик транзакций. Размещение здесь учетных записей преследует одну цель: обеспечить учет, личность которого обладает какая доля участия в системе.7 Однако будут заметные различия: • Контракты не могут быть развернуты посредством транзакций; исходя из желания избежать функциональности приложения в релейной цепочке, оно не будет поддерживать публичное внедрение контрактов. • Использование вычислительных ресурсов («газ») не учитывается; поскольку единственные функции, доступные для публичного использования будет исправлено, обоснование учета газа больше не держится. Таким образом, взимается фиксированная плата. во всех случаях, что позволяет добиться большей производительности в любом динамическое выполнение кода, которое может потребоваться и более простой формат транзакции. • Для перечисленных контрактов поддерживается специальная функциональность, обеспечивающая автоматическое выполнение и вывод сетевых сообщений. В случае, если в релейной цепочке есть виртуальная машина и она будет основанный на EVM, он будет иметь ряд модификаций для обеспечения максимальной простоты. Вероятно, это было бы иметь ряд встроенных контрактов (аналогично тем, что есть в адреса 1–4 в Ethereum), чтобы обеспечить возможность специфичной для платформы обязанности, подлежащие управлению, включая консенсусный контракт, validator контракт и контракт парачейна. Если не EVM, то наиболее вероятной альтернативой является серверная часть WebAssembly [2] (wasm); в этом случае общий структура была бы аналогична, но не было бы необходимости для встроенных контрактов, где Wasm является жизнеспособной целью для языков общего назначения, а не для незрелых и ограниченное количество языков для EVM. Вполне возможны и другие вероятные отклонения от настоящего протокола Ethereum, например упрощение формат квитанции транзакции, позволяющий параллельное выполнение неконфликтных транзакций в одном блоке, как предложено для серии изменений Serenity. Возможно, хотя и маловероятно, что подобная Серенити «чистая» цепочка может быть развернута как релейная цепочка, что позволяет конкретный контракт для управления такими вещами, как staking token баланса, а не делать это фундаментальной частью протокол сети. В настоящее время мы считаем маловероятным, что это предложит достаточно большое упрощение протокола, чтобы стоит дополнительных сложностей и неопределенности, связанных с этим в его разработке. 7В качестве средства представления суммы, которую данный владелец несет ответственность за общую безопасность системы, эти счета ставок будут неизбежно кодируют некоторую экономическую ценность. Однако следует понимать, что, поскольку нет намерения использовать такие значения в любым способом с целью обмена на реальные товары и услуги, следует отметить, что token нельзя сравнивать с валюта и, как таковая, релейная цепь сохраняют свою нигилистическую философию в отношении приложений.POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 10 Существует ряд небольших функциональных возможностей, необходимых для администрирования механизма консенсуса, набора validator, механизма проверки и парачейнов. Эти могут быть реализованы вместе в рамках монолитного протокола. Однако из соображений модульности мы описываем их как «контракты» релейной цепи. Это должно можно понимать так, что они являются объектами (в смысле объектно-ориентированное программирование), управляемое механизмом консенсуса релейной цепи, но не обязательно они определяются как программы с кодами операций, подобными EVM, а также даже если к ним можно индивидуально обращаться через учетная система. 6.2. Контракт на стейкинг. Этот контракт поддерживает набор validator. Он управляет: • какие учетные записи в настоящее время являются validator; • которые в ближайшее время могут стать validators уведомление; • на каких счетах были размещены доли, номинированные на validator; • свойства каждого из них, включая объем staking, приемлемые ставки выплат и адреса, а также краткосрочные (сессионные) идентификаторы. Позволяет аккаунту зарегистрировать желание стать связанный validator (вместе с его требованиями), чтобы назначить какую-либо личность, а для ранее существовавших связанных validators зарегистрировать свое желание выйти из этого статуса. Это также включает в себя сам механизм проверки и канонизации. 6.2.1. Ставка-token Ликвидность. Как правило, желательно иметь как можно больше из общего числа staking tokens, чтобы быть участие в операциях по техническому обслуживанию сети, поскольку это напрямую связывает безопасность сети с общей «рыночной капитализацией» staking token. Это может легко стимулироваться путем раздувания валюты и раздачи доходов тем, кто участвует в качестве validators. Однако сделать это представляет проблему: если token заблокирован в Контракте о ставках под наказанием сокращения, как значительная часть может оставаться достаточной ликвидный, чтобы позволить обнаружение цен? Одним из ответов на это является разрешение прямого деривативного контракта, обеспечивающего взаимозаменяемые token на базовой ставке token. Это трудно организовать без доверия. Более того, эти производные token не могут рассматриваться одинаково по той же причине, по которой различные государственные облигации еврозоны не являются взаимозаменяемыми: существуют это вероятность того, что базовый актив потерпит неудачу и станет бесполезный. С правительствами еврозоны может произойти по умолчанию. При ставке validator tokens validator может действовать злонамеренно и быть наказанным. Следуя нашим принципам, мы выбираем самое простое решение: не все token будут поставлены на карту. Это означало бы, что некоторая часть (возможно, 20%) token будет принудительно оставаться жидким. Хотя это несовершенно с точки зрения безопасности, вряд ли это будет иметь фундаментальное значение для безопасность сети; 80% возможных репараций в результате конфискации облигаций все равно можно будет выплатить. по сравнению с «идеальным случаем» 100% staking. Соотношение между поставленными и ликвидными token можно довольно просто определить с помощью механизма обратного аукциона. По сути, владельцы token заинтересованы в том, чтобы стать validator. каждый из них разместит предложение по контракту staking с указанием минимальная ставка выплат, которую они потребуют принять часть. В начале каждой сессии (сессии будут происходят регулярно, возможно, раз в час) validator слотов будут заполнены в соответствии с каждым возможным Ставка validator и размер выплат. Один из возможных алгоритмов ибо это означало бы брать тех, у кого самые низкие предложения, представляют собой ставку, не превышающую общую целевую ставку делится на количество слотов и не может быть меньше половины этой суммы. Если места не могут быть заполнены, нижняя граница может быть неоднократно уменьшена на некоторый коэффициент, чтобы удовлетворить требованиям. 6.2.2. Номинирование. Можно безнадежно номинировать одни staking tokens на активный validator, давая им ответственность за выполнение обязанностей validator. Номинирование работ через систему одобрения-голосования. Каждый потенциальный номинатор может опубликовать инструкцию к контракту staking. выражающее одну или несколько validator личностей, под чьим именем ответственность, которую они готовы доверить своим обязательствам. На каждой сессии облигации номинаторов распределяются таким образом, чтобы представлены одним или несколькими validator. Алгоритм распределения оптимизирует набор из validator с эквивалентной суммой. облигации. Облигации номинаторов переходят под фактическую ответственность validator aи получить интерес или страдать наказание-смягчение соответственно. 6.2.3. Конфискация/сожжение облигаций. Определенное поведение validator приводит к штрафному сокращению их залога. Если облигация снижается ниже допустимого минимума, сеанс преждевременно завершился и начался другой. Неисчерпывающий список наказуемых validator проступков включает в себя: • Будучи частью группы парачейнов, неспособной предоставить консенсус относительно действительности блока парачейна; • активно подписываясь за действительность инвалида блок парачейна; • невозможность доставить исходящую полезную нагрузку ранее проголосовали как доступные; • бездействие во время процесса достижения консенсуса; • проверка блоков релейной цепи на конкурирующих вилках. Некоторые случаи неправомерного поведения угрожают целостности сети (например, подписание недействительных блоков парачейна и проверка нескольких сторон форка) и, как следствие, приводят к эффективному изгнанию за счет полного сокращения связи. В другие, менее серьезные случаи (например, бездействие в консенсусе процессе) или в случаях, когда вина не может быть точно распределена (будучи частью неэффективной группы), небольшая часть вместо этого может быть оштрафован на сумму залога. В последнем случае это хорошо работает с оттоком подгрупп, чтобы гарантировать, что вредоносные узлы несут значительно большие потери, чем сопутствующе поврежденные доброжелательные узлы. В некоторых случаях (например, проверка нескольких вилок и недействительный подписание субблока) validator сами не могут легко обнаружить неправомерное поведение друг друга, поскольку постоянная проверка каждого блока парачейна было бы слишком трудной задачей. Здесь необходимо заручиться поддержкой сторон, внешних по отношению к процесс проверки для проверки и сообщения о таком неправильном поведении. Стороны получают вознаграждение за сообщение о такой деятельности; их термин «рыбаки» проистекает из маловероятности такой награды. Поскольку эти случаи, как правило, очень серьезные, мы полагаем, что любые вознаграждения могут быть легко выплачены из конфискованной облигации. В целом мы предпочитаем балансировать горение (т.е. сведение на нет) с перераспределением, а не попытка массового перераспределения. Это имеет эффект

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 11 увеличивая общее значение token, компенсируя сети в целом, а не конкретной сторона, участвовавшая в открытии. Это в первую очередь в целях безопасности механизм: задействованные большие суммы могли бы привести к чрезвычайной и острой стимулировке поведения, если бы все они направлено на одну цель. В общем, важно, чтобы вознаграждение было достаточно большим, чтобы сделать верификацию полезной для сети, но не настолько большим, чтобы компенсировать затраты на противодействие хорошо финансируемый, хорошо организованный преступник «промышленного уровня» хакерская атака на какого-то неудачливого validator с целью заставить его вести себя неподобающе. Таким образом, требуемая сумма, как правило, не должна быть больше, чем прямая связь заблудшего validator, чтобы не возникают извращенные стимулы к плохому поведению и заявлению о награде. С этим можно бороться либо явно посредством минимального требования к прямым облигациям для того, чтобы быть validator или косвенно, объясняя номинаторам, что validator с небольшим количеством депонированных облигаций не имеют большого стимула вести себя хорошо. 6.3. Реестр Парачейна. Каждый парачейн определен в этот реестр. Это относительно простая конструкция, подобная базе данных, которая содержит как статическую, так и динамическую информацию. каждая цепочка. Статическая информация включает в себя индекс цепочки (простой целое число), а также идентификатор протокола проверки, средства различения разных классов парачейн, чтобы можно было использовать правильный алгоритм проверки. под руководством validators, призванных выдвинуть действительного кандидата. Первоначальная проверка концепции будет сосредоточена на размещении новые алгоритмы проверки в самих клиентах, что фактически требует хард-форка протокола каждый раз, когда добавлен дополнительный класс цепи. В конечном счете, однако, возможно, можно указать алгоритм проверки в одновременно строгий и достаточно эффективный способ, позволяющий клиентам способен эффективно работать с новыми парачейнами без хард-форк. Одним из возможных способов решения этой проблемы могло бы быть указание алгоритм проверки парачейна в хорошо зарекомендовавшей себя, скомпилированный в собственном коде, нейтральный к платформе язык, такой как WebAssembly. Необходимы дополнительные исследования, чтобы определить действительно ли это осуществимо, однако если это так, это может принести вместе с этим огромное преимущество в виде исключения хард-форков навсегда. Динамическая информация включает в себя аспекты системы маршрутизации транзакций, которые должны иметь глобальное соглашение, такие как в качестве входной очереди парачейна (описано в разделе 6.6). В реестр можно добавлять только парачейны. путем полного голосования на референдуме; этим можно было бы управлять внутри, но, скорее всего, будет размещен во внешнем контракт референдума, чтобы облегчить повторное использование в соответствии с более общие компоненты управления. Параметры для требования к голосованию (например, необходимый кворум, большинство требуется) для регистрации дополнительных цепочек и прочего, менее формальные обновления системы будут изложены в «основном конституции», но, скорее всего, будут следовать довольно традиционной путь, по крайней мере, на начальном этапе. Точная формулировка отсутствует. объем настоящей работы, но, например. квалифицированное большинство в две трети для принятия более одной трети всей системы положительное голосование по ставкам может быть разумной отправной точкой. Дополнительные операции включают подвешивание и удаление парацепей. Отстранение, надеюсь, никогда не произойдет случается, однако это призвано служить как минимум гарантией в системе проверки парачейна возникла какая-то неразрешимая проблема. Самый очевидный пример, когда это может быть необходимо критическое для консенсуса различие между реализациями, приводящее validator к неспособности прийти к согласию по действительность или блоки. Валидаторам будет предложено использовать несколько реализаций клиента, чтобы они могли чтобы обнаружить такую проблему до конфискации облигаций. Поскольку приостановка является экстренной мерой, это будет под эгидой динамического validator-голосования, а не чем референдум. Восстановление возможно как из validators или референдума. Полный отказ от парачейнов произойдет только после референдума и при котором потребуется существенный льготный период, позволяющий осуществить упорядоченный переход к либо создать отдельную сеть, либо стать частью какой-либо другой консенсус-система. Льготный период, скорее всего, будет длиться порядок месяцев и, вероятно, будет установлен для каждой цепочки в реестре парачейнов, чтобы разные парачейны могут пользоваться разными льготными периодами в зависимости от их потребность. 6.4. Пломбирование блоков реле. По сути, герметизация подразумевает к процессу канонизации; то есть базовые данные трансформировать которыйотображает оригинал в нечто принципиально уникальное и значимое. В цепочке PoW запечатывание фактически является синонимом добычи полезных ископаемых. В нашем случае он включает в себя сбор подписанных заявлений от validators о действительности, доступности и каноничности конкретный блок релейной цепи и блоки парачейна, которые оно представляет. Механика базового алгоритма консенсуса BFT выходит за рамки настоящей работы. Мы будем вместо этого опишите его, используя примитив, который предполагает государственная машина, создающая консенсус. В конечном итоге мы ожидаем вдохновиться рядом многообещающих BFT консенсусных алгоритмы в ядре; Тангаора [9] (вариант BFT Плот [16]), Tendermint [11] и HoneyBadgerBFT [14]. Алгоритму придется достичь соглашения по нескольким парачейнам параллельно, что отличается от обычного blockchain механизмы консенсуса. Мы предполагаем, что однажды консенсус достигнут, мы можем записать консенсус в неопровержимом доказательстве, которое может быть предоставлено любым из участников к нему. Мы также предполагаем, что неправильное поведение в рамках протокола можно вообще свести к небольшому группа, содержащая плохо себя ведущих участников, чтобы свести к минимуму сопутствующий ущерб при назначении наказания8. Доказательство, которое принимает форму наших подписанных утверждений, помещается в заголовок блока релейной цепи вместе. с некоторыми другими полями, в частности корнем дерева состояний релейной цепочки и корнем дерева транзакций.

уплотнение процесс берет место под а одинокий создание консенсуса механизм обращение оба тот блок релейной цепи и блоки парачейнов, которые составляют часть содержимого ретранслятора: парачейны не «фиксируются» по отдельности их подгруппами, а затем сопоставляются позже. Это приводит к более сложному процессу для релейной цепи, но позволяет нам завершить согласование всей системы за один этап, минимизируя задержку и позволяя для довольно сложных требований к доступности данных, которые полезно для процесса маршрутизации ниже. 8Существующие схемы консенсуса BFT на основе PoS, такие как Tendermint BFT и оригинальный Slasher, соответствуют этим утверждениям.

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 12 Состояние машины консенсуса каждого участника может моделироваться как простая (двумерная) таблица. Каждый участник (validator) имеет набор информации в виде подписанных заявлений («голосов») от других участников в отношении каждого кандидата на блок парачейна, а также кандидата на блок релейной цепи. Набор информации состоит из двух частей. данных: Наличие: есть это validator иметь выход информация о транзакции из этого блока, поэтому они могут правильно проверить кандидатов на парачейн в следующем блоке? Они могут голосовать либо 1 (известно), либо 0 (пока неизвестно). Как только они проголосовали 1, они обязуются проголосовать аналогичным образом за остальная часть этого процесса. Последующие голоса, которые не уважение это является основанием для наказания. Валидность: действителен ли блок парачейна и все ли данные с внешней ссылкой (например, транзакции) доступен? Это актуально только для validator, назначенных парачейну, в котором они голосуют. Они могут проголосовать 1 (действительно), -1 (недействительно) или 0. (пока не известно). Как только они проголосуют за ненулевое значение, они намерены голосовать таким образом до конца процесс. Последующие голоса, которые не соблюдают это являются основанием для наказания. Все validator должны проголосовать; голоса могут быть поданы повторно, если они соответствуют правилам, изложенным выше. Прогрессирование консенсус можно смоделировать как несколько стандартных BFT алгоритмов консенсуса в каждом парачейне, происходящих параллельно. Поскольку этому потенциально препятствует относительно небольшое меньшинство злоумышленников сосредоточено в единой группы парачейнов, существует общий консенсус в отношении установить ограничитель обратного хода, ограничивая худший сценарий от тупик всего лишь к одному или нескольким блокам пустотного парачейна (и наказание для виновных). Основные правила валидности отдельных блоков (которые позволяют всему набору validators в целом прийти к консенсус по поводу того, что он станет уникальным кандидатом на парачейн на которые можно ссылаться из канонического реле): • должно быть, чтобы не менее двух третей validator проголосовали положительно, и ни один из них не проголосовал бы отрицательно; • более трети validator должны проголосовать положительно за доступность информации об исходящей очереди. Если есть хотя бы один положительный и хотя бы один отрицательный голос о действительности, создается исключительное условие. и весь набор validators должен проголосовать, чтобы определить если есть злоумышленники или если произошел случайный вилка. Помимо действительных и недействительных, существует третий вид голосов. разрешены, что эквивалентно голосованию за обоих, а это означает, что узел имеет противоречивые мнения. Это может быть связано с владелец узла запускает несколько реализаций, которые не согласен, что указывает на возможную неясность протокола. После подсчета всех голосов из полного набора validator, если проигрышное мнение имеет, по крайней мере, незначительную долю (к быть параметризованными; максимум половина, а возможно и значительно меньше) голосов за выигравшее мнение, то предполагается, что будет случайным форком парачейна, и парачейн автоматически отключится от процесса консенсуса. В противном случае мы считаем, что это злонамеренное действие, и наказываем виновного. меньшинство, голосовавшее за особое мнение. Заключение представляет собой набор подписей, подтверждающих каноничность. Блок релейной цепи затем может быть опломбирован. и начался процесс запечатывания следующего блока. 6.5. Улучшения в герметизации блоков реле. Пока этот метод герметизации дает серьезные гарантии работы системы, он не особенно хорошо масштабируется поскольку ключевая информация каждого парачейна должна иметь свое доступность гарантирована более чем одной третью всех validator. Это означает, что ответственность каждого validator растет по мере добавления новых цепей. Хотя доступность данных в сетях открытого консенсуса по сути является нерешенной проблемой, существуют способы уменьшения накладных расходов, возникающих на узлах validator. Один простой решение состоит в том, чтобы осознать, что хотя validators должны взять на себя ответственность за доступность данных, им не нужно фактически хранить, передавать или тиражировать данные самостоятельно. Вторичные хранилища данных, возможно, связанные с (или даже с самой же) сопоставители, которые собирают эти данные, могут управлять задача гарантировать доступность, при этом validators предоставляют часть своих процентов/дохода в виде оплаты. Однако, хотя это и может обеспечить некоторую промежуточную масштабируемость, это все равно не решает основную проблему; с тех пор добавление большего количества цепочек, как правило, потребует дополнительных validator, текущее потребление сетевых ресурсов (особенно с точки зрения пропускной способности) растет с квадратом тотцепи, несостоятельная собственность в долгосрочной перспективе. В конце концов, мы, вероятно, продолжим ломать головы против фундаментального ограничения, которое гласит, что для консенсусную сеть, которую следует считать доступной и безопасной, текущие требования к полосе пропускания имеют порядок общего validators раз умножает общую входную информацию. Это связано с неспособность недоверенной сети правильно распределить задачу хранения данных по множеству узлов, которая сидит помимо в высшей степени распределяемой задачи обработки. 6.5.1. Представляем задержку. Один из способов смягчить это Правило состоит в том, чтобы ослабить понятие непосредственности. Требуя, чтобы 33%+1 validator голосовали за доступность только в конечном итоге, а не сразу, мы можем лучше использовать экспоненциальное распространение данных и помочь сгладить пики обмена данными. Разумное равенство (хотя и недоказанное) может быть: (1) задержка = участники × цепочки В рамках текущей модели размер системы масштабируется с количеством цепочек, чтобы гарантировать, что обработка распределенный; поскольку для каждой цепочки потребуется хотя бы один validator, и мы фиксируем константу подтверждения доступности доля validators, то участники аналогично растут с количеством цепей. В итоге мы имеем: (2) задержка = размер2 Это означает, что по мере роста системы требуемая полоса пропускания и задержка до момента доступности становятся известны по всей сети. сети, которую можно также охарактеризовать как количество блоков до завершения, увеличивается с увеличением его площади. Это существенный фактор роста и может оказаться заметным препятствием на пути и вынудить нас придерживаться «неплоских» парадигм например, объединение нескольких «Polkadotes» в иерархию для многоуровневой маршрутизации сообщений через дерево релейных цепочек.

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 13 6.5.2. Общественное участие. Еще одно возможное направление заключается в привлечении общественности к участию в этом процессе посредством система микрожалоб. Подобно рыбакам, здесь могут быть внешними сторонами, которые следят за validator, которые заявляют доступность. Их задача — найти того, кто не способен продемонстрировать такую ​​доступность. При этом они может подать микрожалобу другим validator. PoW или заложенная облигация может быть использована для смягчения атаки Сивиллы что сделало бы систему практически бесполезной. 6.5.3. Гарантии наличия. Конечный путь будет заключаться в том, чтобы назначить второй набор связанных validators как «доступность» гаранты». Они будут связаны так же, как и обычные validator, и даже могут быть взяты из того же набора. (хотя в этом случае они будут выбираться на длительный период, по крайней мере, за сеанс). В отличие от обычных validator, они не будет переключаться между парачейнами, а скорее будет сформировать единую группу, чтобы подтвердить доступность всех важных межцепочных данных. Это имеет то преимущество, что ослабляет эквивалентность между участниками и цепочками. По сути, цепи могут расти (вместе с исходным набором цепочек validator), тогда как участники, и особенно те, кто принимает участие в тестировании доступности данных, могут оставаться, по крайней мере, сублинейными. и, вполне возможно, постоянный. 6.5.4. Настройки подборщика. Один важный аспект этого система заключается в том, чтобы обеспечить здоровый выбор колляторы, создающие блоки в любом парачейне. Если один коллатор доминировал над парачейном, а затем несколько атак становится более осуществимым, поскольку вероятность отсутствия доступность внешних данных будет менее очевидной. Одним из вариантов является искусственное взвешивание блоков парачейна в псевдослучайный механизм, позволяющий отдавать предпочтение широкому кругу алгоритмов сопоставления. В первом случае нам потребуется как часть механизма консенсуса, который поддерживают validators Кандидаты в блоки парачейна определены как «более тяжелые». Точно так же мы должны стимулировать validators попытаться предложите самый весомый блок, который они смогут найти — это может быть Это делается путем выплаты части вознаграждения пропорционально весу кандидата. Чтобы гарантировать, что подборщикам предоставляется разумная справедливая вероятность того, что их кандидат будет выбран победителем кандидата в консенсусе, мы определяем удельный вес Кандидат в блок парачейна определяется случайной функцией, связанной с каждым коллатором. Например, взяв мера расстояния XOR между адресом сопоставления и некоторое криптографически безопасное псевдослучайное число определяется вблизи точки создаваемого блока (условный «выигрышный билет»). Это фактически дает каждому сопоставитель (или, более конкретно, адрес каждого сопоставителя) случайный шанс того, что их блок-кандидат «победит» над все остальные. Чтобы смягчить атаку Сивиллы, когда один сопоставитель «майнит» адрес, близкий к выигрышному билету и, таким образом, если каждый блок является избранным, мы бы добавили некоторую инерцию к адресу сопоставления. Это может быть так же просто, как потребовать их иметь базовую сумму средств на адресе. Более элегантным подходом было бы взвешивание близости к выигрышный билет с указанием суммы средств, припаркованных на адрес, о котором идет речь. Хотя моделирование еще не завершено, вполне возможно, что этот механизм позволяет даже очень мелкие заинтересованные стороны могут внести свой вклад в качестве сопоставителя. 6.5.5. Блоки с избыточным весом. Если набор validator скомпрометирован, они могут создать и предложить блок, который, хотя и действительны, требует слишком много времени для выполнения и подтвердить. Это проблема, поскольку группа validator может разумно сформировать блок, на создание которого уходит очень много времени выполняться, если уже не известна какая-то конкретная часть информации, позволяющая сократить путь, например. факторинг крупного премьер. Если бы хоть один сопоставитель знал эту информацию, то у них будет явное преимущество в получении своего собственного кандидаты соглашались, пока остальные были заняты обработкой старого блока. Мы называем эти блоки избыточным весом. Защита от validators, отправляющих и проверяющих эти блоки, в основном подпадает под ту же самую защиту, что и для недействительные блоки, хотя и с дополнительной оговоркой: поскольку время, необходимое для выполнения блока (и, следовательно, его статус как избыточный вес) является субъективным, окончательный результат голосования по плохое поведение разделится по существу на три лагеря. Один возможно, что блок определенно не имеет лишнего веса — в этом случае более двух третей заявляют, что они могли бы выполнить блок в пределах некоторого ограничения (например, 50 % от общего времени, разрешенного между блоками). Другое заключается в том, что блок dопределенно избыточный вес — это было бы, если бы более две трети заявляют, что не смогли выполнить блок в пределах указанного лимита. Последняя возможность — это довольно равная раскол мнений между validators. В этом случае мы можем решите применить соразмерное наказание. Чтобы validator могли предсказать, когда они могут оказаться Предлагая блок с избыточным весом, возможно, было бы разумно потребовать от них публиковать информацию о своей производительности для каждого блока. За достаточный период времени это должно позволить им профилировать скорость обработки относительно сверстников, которые будут их судить. 6.5.6. Коллекторное страхование. Для validators осталась одна проблема: в отличие от сетей PoW, для проверки коллятора для проверки достоверности, они должны фактически выполнять транзакции в нем. Злоумышленники могут передавать недействительные или слишком тяжелые блоки validator, вызывая у них беспокойство (растрачивание блоков). свои ресурсы) и требует потенциально существенных альтернативных издержек. Чтобы смягчить это, мы предлагаем простую стратегию на часть validators. Во-первых, кандидаты на блок парачейна были отправлены до validators необходимо подписать из учетной записи цепочки ретрансляции с фондами; если это не так, то validator должен отпасть это немедленно. Во-вторых, такие кандидаты должны быть упорядочены по приоритету путем комбинации (например, умножения) количество средств на счете до определенного предела, количество предыдущих блоков, которые коллятор успешно предложил в прошлом (не говоря уже о любых предыдущих наказания), а также фактор близости к победителю. билет, как обсуждалось ранее. Шапка должна быть такой же в качестве штрафных санкций, выплаченных validator по делу из них отправляют недействительный блок. Чтобы не стимулировать подборщики отправлять недействительных или перегруженных кандидатов на блоки validator, любой validator может поместить в следующий блок транзакцию, включающую блок-нарушитель, в котором утверждается о неправомерном поведении, что приведет к переводу некоторых или всех средств из некорректно работающего коллатора отчет потерпевшему validator. Этот тип транзакций опережает все остальные, чтобы гарантировать, что сборщик не сможет снять средства до наказания. Сумма средства, перечисленные в качестве возмещения ущерба, пока являются динамическим параметром

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 14 подлежит моделированию, но, вероятно, будет составлять часть вознаграждения за блок validator, чтобы отразить уровень причиненного горя. Чтобы предотвратить произвольную конфискацию средств злоумышленниками validators, сборщик может взамен обжаловать решение validator присяжных, состоящих из случайно выбранных validators. для внесения небольшого депозита. Если они примут решение в пользу validator, депозит будет использован ими. Если нет, то депозит возвращается, а validator оштрафован (поскольку validator находится в гораздо более опасной позиции, штраф будет вероятно, будет довольно здоровенным). 6.6. Интерчейн Транзакция Маршрутизация. Интерчейн маршрутизация транзакций является одним из важнейших процессов обслуживания задачи релейной цепи и ее validators. Это логика, которая управляет тем, как опубликованная транзакция (часто сокращенно просто «публикация») становится желаемым результатом из одного исходного парачейна в непередаваемый вход другого целевого парачейна без какого-либо доверия требования. Мы тщательно подбираем приведенную выше формулировку; особенно мы не требуют, чтобы в источнике была транзакция parachain явно санкционировал этот пост. Единственный ограничения, которые мы налагаем на нашу модель, заключаются в том, что парачейны должны предоставить упакованные как часть общего блока выходные данные обработки, сообщения, являющиеся результатом выполнение блока. Эти сообщения структурированы как несколько очередей FIFO; тот количество списков называется базой маршрутизации и может быть около 16. Примечательно, что это число представляет собой количество парачейнов, которые мы можем поддерживать, не прибегая к многофазная маршрутизация. Первоначально Polkadot будет поддерживать это вид прямой маршрутизации, однако мы опишем один из возможных процесс многофазной маршрутизации («гипермаршрутизация») как средство масштабирования далеко за пределы первоначального набора парачейнов. Мы предположить что все участники знать тот подгруппы для следующих двух блоков n, n + 1. Таким образом, Система маршрутизации проходит следующие этапы: • CollatorS: свяжитесь с членами Валидаторов[n][S] • Сортировщики: ДЛЯ КАЖДОЙ подгруппы: убедитесь, что минимум 1 член валидаторов[n][s] в контакте • Сопоставители: ДЛЯ КАЖДОЙ подгруппы: предположить egress[n −1][s][S] доступен (все входящие сообщения данные в «S» из последнего блока) • Сопоставители: Составьте кандидата блока b для S: (b.header, b.ext, b.proof, b.ceipt, b.egress) • Сопоставители: Отправить доказательство информация доказательство[S] = (b.header, b.ext, b.proof, b.receipt) на Валидаторы[n][S] • CollatorS: обеспечение данных внешних транзакций b.ext. доступен другим подборщикам и validators • Сопоставители: ДЛЯ КАЖДЫЙ подгруппа с: Отправить выход информация выход[n][S][s] = (b.заголовок, b.квитанция, b.выход[ы]) чтобы тот получение подгруппы члены из следующий блокировать Валидаторы[n + 1][s] • ValidatorV: предварительно соедините все элементы одного набора. для следующего блока: пусть N = Chain[n + 1][V ]; подключить все validators v такие, что Chain[n + 1][v] = N • ВалидаторV: Сопоставить все поступающие данные для этого блок: ДЛЯ КАЖДЫЙ подгруппа с: Получить egress[n −1][s][Chain[n][V ]], получить от других validators v таких, что Chain[n][v] = Chain[n][V ]. Возможно, пройдя через случайно выбранных других validator для доказательства попытки. • ВалидаторV: Примите кандидатские доказательства для этого доказательство блока[Chain[n][V ]]. Действительность блокировки голосования • ВалидаторV: Принять выходные данные кандидата для следующий блок: ДЛЯ КАЖДОЙ подгруппы примите выход[n][s][N]. Возможность блокировки выхода при голосовании; переопубликовать среди заинтересованных validators v так, чтобы Цепочка[n + 1][v] = Цепочка[n + 1][V ]. • ВалидаторV: ДО СОГЛАСИЯ Где: egress[n][from][to] — текущая выходная очередь. информация для сообщений, идущих из парачейна «от», в парачейн «to» в блоке номер «n». CollatorS — это средство сортировки для парачейна S. Validators[n][s] — это набор validators для парачейна 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) нетривиален для входа и прост

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 15 доказать. Таким образом, недавним сопоставлениям (возможно, из последних нескольких тысяч блоков) разрешено ставить задачи доступность внешних данных для конкретного парачейна заблокируйте validators за небольшой залог. Валидаторы должны связаться с лицами из явно нарушившей подгруппы validator, которые дали показания, и либо получить и вернуть данные сопоставителю, либо передать ситуацию на более высокий уровень. дело, свидетельствуя об отсутствии доступности (прямой отказ предоставить данные считается правонарушением, связанным с конфискацией облигаций, поэтому неправомерное поведение validator, скорее всего, просто разорвать соединение) и связаться с дополнительными validators чтобы запустить тот же тест. В последнем случае залог коллатора возвращается. Как только будет достигнут кворум validator, которые могут дать такие свидетельства о недоступности, они будут освобождены. плохо себя ведущая подгруппа наказывается, и блокировка отменяется. 6.6.2. Маршрутизация сообщений. Каждый заголовок парачейна включает в себя выходной-три-корень; это корень дерева, содержащего контейнеры базы маршрутизации, каждый контейнер представляет собой объединенный список выходных постов. Доказательства Меркла могут быть предоставлены через parachain validators, чтобы доказать, что конкретный парачейн у блока была определенная выходная очередь для определенного парачейна назначения. В начале обработки блока парачейна каждый выходная очередь другого парачейна, привязанная к указанному блоку, равна объединены во входную очередь нашего блока. Мы предполагаем сильными, вероятно, CSPR9, подблок, предназначенный для достижения детерминированной операции, которая не предполагает фаворитизма между какими-либо Спаривание блоков парачейна. Колляторы рассчитывают новую очередь и опустошить выходные очереди в соответствии с параметрами парачейна логика. Содержимое входной очереди записывается явно в блок парачейна. Это преследует две основные цели: во-первых, это означает, что парачейн можно без доверия синхронизировать изолированно от других парачейнов. Во-вторых, это упрощает логистику данных, если весь входной очередь не может быть обработана в одном блоке; validators и средства сортировки могут обрабатывать следующие блоки без необходимости специально получать данные очереди. Если входная очередь парачейна превышает пороговое значение сумма в конце обработки блока, затем она отмечается насыщена в релейной цепи, и никакие дальнейшие сообщения не могут быть быть доставлено ему до тех пор, пока оно не будет очищено. Доказательства Меркла используется для демонстрации точности работы сортировщика в Доказательство блока парачейна. 6.6.3. Критика. Один незначительный недостаток, связанный с этим основным механизмом является атака после взрыва. Здесь все парачейны отправляют максимально возможное количество постов к конкретному парачейну. Хотя это связывает цель входная очередь сразу, никакой ущерб не наносится сверх стандартная транзакционная DoS-атака. Работает нормально, с набором хорошо синхронизированных и незлонамеренные алгоритмы сортировки и validators для N парачейнов, Всего N × M validators и L колляторов на парачейн, мы может разбить общее количество путей передачи данных на блок на: Валидатор: M −1+L+L: M −1 для остальных validators в наборе парачейнов L для каждого сопоставления, предоставляющего блок-кандидат парачейна, и второй L для каждого сопоставления. следующего блока, требующего исходящих полезных данных предыдущего блока. (Последнее на самом деле больше похоже на худший случай. операции, поскольку вполне вероятно, что подборщики будут использовать такие данные.) Сборщик: M +kN: M для подключения к каждому соответствующему блок парачейна validator, кН для распределения исходящих полезных данных в некоторое подмножество каждой группы парачейна validator для следующий блок (и, возможно, какой-нибудь предпочтительный сопоставитель(и)). Таким образом, пути передачи данных на узел растут линейно. с общей сложностью системы. Хотя это разумно, поскольку система масштабируется до сотен или тысяч парачейнов, некоторая задержка связи может быть поглощены в обмен на более низкие темпы роста сложности. В этом случае может быть использован алгоритм многофазной маршрутизации. чтобы уменьшить количество мгновенных путей ценой введения буферов хранения и задержки. 6.6.4. Маршрутизация гиперкуба. Маршрутизация гиперкуба — это механизм, который в большинстве случаев можно построить как расширение базовый механизм маршрутизации, описанный выше. По сути, вместо того, чтобы увеличивать связность узлов с увеличением количества парачейнов и узлов подгрупп, мы растем только с логарифм парацепей. Сообщения могут перемещаться между очереди нескольких парачейнов на пути к окончательной доставке. Сама маршрутизация детерминирована и проста. Мы начинаем с ограничение количества ячеек во входных/выходных очередях; а не общее количество парачейнов, они являютсябаза маршрутизации (b) . Это будет зафиксировано как число изменений парачейнов, при этом показатель маршрутизации (e) вместо этого увеличивается. Согласно этой модели, объем нашего сообщения растет с ростом O(be), при этом пути остаются постоянными и задержка (или количество блоков, необходимых для доставки) с О(е). Наша модель маршрутизации представляет собой гиперкуб размером e, причем каждая сторона куба имеет b возможных мест. В каждом блоке мы маршрутизируем сообщения по одной оси. Мы чередуйте оси по кругу, гарантируя таким образом время доставки блоков e в наихудшем случае. В рамках обработки парачейна иностранные Сообщения, обнаруженные во входящей очереди, немедленно направляются в соответствующий контейнер исходящей очереди, учитывая текущий номер блока (и, следовательно, размер маршрутизации). Это процесс требует дополнительной передачи данных для каждого перехода на пути доставки, однако это само по себе проблема которые можно смягчить, используя некоторые альтернативные средства доставки полезной нагрузки данных и включая только ссылку, а не полную полезную нагрузку сообщения в post-trie. Пример такой маршрутизации гиперкуба для системы с 4 парачейнами b = 2 и e = 2 могут быть: Фаза 0, для каждого сообщения M: • sub0: если Mdest ∈{2, 3}, то sendTo(2), иначе сохраните • sub1: если Mdest ∈{2, 3}, то sendTo(3), иначе сохраните • sub2: если Mdest ∈{0, 1}, то sendTo(0), иначе сохраните • sub3: если Mdest ∈{0, 1}, то sendTo(1), иначе сохраните Фаза 1, по каждому сообщению M: • sub0: если Mdest ∈{1, 3}, то sendTo(1), иначе сохраните • sub1: если Mdest ∈{0, 2}, то sendTo(0), иначе сохраните • sub2: если Mdest ∈{1, 3}, то sendTo(3), иначе сохраните • sub3: если Mdest ∈{0, 2}, то sendTo(2), иначе сохраните Два измерения здесь легко увидеть как первое. два бита индекса назначения; для первого блока, используется только бит более высокого порядка. Второй блок занимается с младшим битом. Как только произойдет то и другое (в произвольном order), тогда сообщение будет перенаправлено. 9криптографически безопасный псевдослучайный

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 16 6.6.5. Максимизация случайности. Одно изменение основного предложение будет иметь фиксированную сумму c2 −c validators, при этом c-1 validators в каждой подгруппе. Каждый блок, а не происходит неструктурированное перераспределение validators среди парачейнов, вместо этого для каждой подгруппы парачейнов, каждый validator будет присвоен уникальному и различному подгруппу парачейна в следующем блоке. Это бы приводят к инварианту, что между любыми двумя блоками, для любого двух пар парачейна, существует два validator, которые поменялись обязанностями в сфере парачейна. Хотя это не может быть использовано для получения абсолютных гарантий доступности. (одиночный validator иногда будет отключен от сети, даже если доброжелательный), он, тем не менее, может оптимизировать общий случай. Этот подход не лишен осложнений. Добавление парачейна также потребует реорганизации. из набора validator. Кроме того, количество validator, привязанное к квадрату количества парацепей, сначала будет очень маленьким, а в конечном итоге вырастет далеко слишком быстро и становится несостоятельным примерно после 50 парачейнов. Ни одна из этих проблем не является фундаментальной. В первом случае реорганизация наборов validator - это то, что должно быть в любом случае делается регулярно. Что касается размера validator установлено, если слишком мало, можно назначить несколько validators к тому же парачейну, применяя целочисленный коэффициент к общее количество validatorс. Механизм многофазной маршрутизации, такой как маршрутизация гиперкуба, рассмотренный в разделе 6.6.4, будет смягчить требования к большому количеству validators когда имеется большое количество цепочек. 6.7. Проверка парачейна. Основное назначение validator как актер с хорошими связями засвидетельствовать, что парачейн блок действителен, включая, помимо прочего, любой переход состояния, любые включенные внешние транзакции, выполнение любые ожидающие посты во входной очереди и конечное состояние выходной очереди. Сам процесс довольно прост. Как только validator запечатает предыдущий блок, они становятся свободными. начать работу по предоставлению кандидата на блок парачейна кандидат на следующий раунд консенсуса. Первоначально validator находит кандидата на блок парачейна через механизм сортировки парачейна (описанный далее) или один его со-validators. Данные кандидата на блок парачейна включает заголовок блока, заголовок предыдущего блока, любые включенные внешние входные данные (для Ethereum и Bitcoin такие данные будут называться транзакциями, однако в принципе они могут включать произвольные структуры данных для произвольных целей), данные выходной очереди и внутренние данные для подтверждения достоверности перехода состояния (для Ethereum это будут различные узлы дерева состояния/хранилища, необходимые для выполнения каждой транзакции). Экспериментальные данные показывают этот полный набор данных для недавнего блока Ethereum. быть самое большее несколько сотен КиБ. Одновременно, если это еще не сделано, validator будет попытка получить информацию, относящуюся к переходу предыдущего блока, первоначально из предыдущего блока validators и позже от всех validators, подписавших контракт доступность данных. Как только validator получит такой блок-кандидат, затем они проверяют его локально. Процесс проверки содержится в модуле validator класса парачейн, чувствительный к консенсусу программный модуль, который необходимо написать для любой реализации Polkadot (хотя в принципе библиотека с C ABI может позволить одной библиотеке распределяться между реализациями с соответствующими снижение безопасности из-за наличия только одной «эталонной» реализации). Процесс берет заголовок предыдущего блока и проверяет его идентичность через недавно согласованную цепочку ретрансляции. блок, в котором должен быть записан его hash. Как только достоверность родительского заголовка установлена, конкретный парачейн может быть вызвана функция проверки класса. Это одна функция, принимающая несколько полей данных (примерно приведенные ранее) и возвращая простое логическое значение провозглашая валидность блока. Большинство таких функций проверки сначала проверяют поля заголовков, которые могут быть получены непосредственно из родительский блок (например, родительский hash, номер). Следование при этом они будут заполнять любые внутренние структуры данных как необходимо для обработки транзакций и/или сообщений. Для цепочки типа Ethereum это равносильно заполнению база данных trie с узлами, которые понадобятся для полное исполнение сделок. Другие типы цепей могут иметь другое препаративные механизмы. После этого входящие сообщения и внешние транзакции (или что бы то ни было, что представляют собой внешние данные) будут приняты, сбалансированы в соответствии со спецификацией сети. (А разумным по умолчанию может быть требование, чтобы все входящие сообщения были обрабатываются до обслуживания внешних транзакций, однако это должна решать логика парачейна.) Благодаря этому постановлению, ряд выходных постов будет созданы, и будет проверено, что они действительно соответствуют кандидат сборщика. Наконец, правильно заполненный заголовок будет сверяться с заголовком кандидата. При полностью проверенном блоке-кандидате validator затем может проголосовать за hash своего заголовка и отправить всю необходимую информацию для проверки со-validator в своей подгруппе. 6.7.1. Коллекторы парачейна. Коллаторы парачейна — это несвязанные операторы, которые выполняют большую часть задач майнеров. в современных сетях blockchain. Они специфичны к конкретному парачейну. Для того чтобы действовать, они должны поддерживать как релейную цепь, так и полностью синхронизированную парачейн. Точное значение слова «полная синхронизация» будет зависеть от класса парачейна, но всегда будет включать текущее состояние входной очереди парачейна. В случае Ethereum это также предполагает как минимум поддержание базу данных дерева Меркла последних нескольких блоков, но может также включает в себя различные другие структуры данных, включая Bloom фильтры для существования учетной записи, семейной информации, регистрации выходные данные и таблицы обратного поиска для номера блока. Помимо синхронизации двух цепочек, это также должен «ловить» транзакции, поддерживая очередь транзакций и принимая должным образом проверенные транзакции. из общедоступной сети. С очередью и цепочкой это способен создавать новые блоки-кандидаты для validator, выбранных в каждом блоке (чья личность известна, поскольку релейная цепь синхронизирована), и отправлять их вместе с различную вспомогательную информацию, такую как подтверждение действительности, через одноранговая сеть. К сожалению, он собирает все комиссии, связанные с включенными в него транзакциями. Вокруг этого вращаются различные экономические теории. аранжировка. На высококонкурентном рынке, где является излишек колляторов, возможно, что транзакция сборы будут разделены с парачейном validators для стимулирования включение определенного блока подборщика. Сходным образом,

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 17 некоторые подборщики могут даже поднять необходимые сборы, которые требуют платить, чтобы сделать блок более привлекательным для validatorс. В этом случае должен образоваться естественный рынок. с транзакциями с более высокой комиссией без очереди и имеющих более быстрое включение в цепочку. 6.8. Сеть. Сеть на традиционных blockchains например Ethereum и Bitcoin, имеют довольно простые требования. Все транзакции и блоки передаются в виде простой ненаправленной сплетни. Синхронизация более сложна, особенно с Ethereum, но на самом деле эта логика содержалась в одноранговая стратегия, а не сам протокол, который разрешается вокруг нескольких типов сообщений запроса и ответа. В то время как Ethereum добился прогресса в текущих предложениях протоколов с помощью протокола devp2p, который позволил многим подпротоколы, которые должны быть мультиплексированы по одному одноранговому соединению и, таким образом, иметь одно и то же наложение одноранговых узлов, поддерживают множество p2p-протоколов одновременно, часть Ethereum протокол по-прежнему оставался относительно простым, а p2p Протокол какое-то время остается незавершенным с важными отсутствуют функциональные возможности, такие как поддержка QoS. К сожалению, желание создать более распространенный протокол «web 3» во многом провалился, и единственные проекты, использующие его, были явно финансируется за счет краудсейла Ethereum. Требования к Polkadot гораздо более существенные. Вместо полностью однородной сети Polkadot имеет несколько типов участников, каждый из которых имеет разные требования к составу своих коллег и несколько сетевых «проспекты», участники которых будут склонны обсуждать конкретные данные. Это означает существенно более структурированное сетевое наложение — и протокол, поддерживающий это — скорее всего, будет необходимо. Кроме того, возможность расширения для облегчения будущих дополнений, таких как новые виды «цепочек», может сами по себе требуют новой структуры наложения. В то время как углубленное обсуждение того, как сеть Протокол может выглядеть выходит за рамки данного документа, поэтому некоторый анализ требований является разумным. Мы можем грубо разобьем участников нашей сети на две группы (релейная цепь, парачейны) каждое из трёх подмножеств. Мы можем также заявляют, что каждый из участников парачейна является только заинтересованы в общении между собой, а не участники других парачейнов: • Участники релейной цепи: • Валидаторы: P, разбить на подмножества P[s] для каждого парачейн • Гаранты доступности: A (могут быть представлены валидаторами в базовой форме протокола). • Клиенты релейной цепи: M (обратите внимание на членов каждого набор парачейнов также будет иметь тенденцию быть членами M) • Участники парачейна: • Сопоставители парачейна: C[0], C[1], . . . • Рыбаки-парачейны: F[0], F[1], . . . • Клиенты Парачейна: S[0], S[1], . . . • Легкие клиенты Parachain: L[0], L[1], . . . Обычно мы называем отдельные классы общения будет иметь место между членами этих наборов: • П | А <-> П | А:

полный набор из validators/гаранты должен быть хорошие связи чтобы достичь консенсуса. • P[s] <-> C[s] | P[s]: Каждый validator как член определенной группы парачейна будет склонен сплетничать. с другими такими участниками, а также сопоставителями этого парачейна, чтобы находить и делиться кандидатами на блоки. • A <-> P[s] | С | A: Каждый гарант доступности необходимо будет собрать чувствительные к консенсусу межсетевые данные из назначенных ему validators; подборщики может также оптимизировать вероятность достижения консенсуса по их заблокировать, объявив его гарантам доступности. Как только они будут получены, данные будут переданы другого такого гаранта для содействия достижению консенсуса. • P[s] <-> A | P[s']: Парачейн validators будет необходимо собрать дополнительные входные данные из предыдущего набора validator или гарантов доступности. • F[s] <-> P: При репортаже рыбаки могут размещать претензия к любому участнику. • М <-> М | П | A: Обычные клиенты ретрансляционной цепочки передают данные от validator и гарантов. • S[s] <-> S[s] | П[ы] | О: Клиенты Parachain передают данные от validator/гарантов. • L[s] <-> L[s] | S[s]: легкие клиенты Parachain выдавать данные от полных клиентов. Для обеспечения эффективного транспортного механизма используется «плоский» оверлейная сеть, например devp2p Ethereum, где каждый узел не (непроизвольно) дифференцирует пригодность своего сверстники вряд ли подойдут. Достаточно расширяемый механизм выбора и обнаружения одноранговых узлов, вероятно, потребует быть включенным в протокол, а также агрессивные планирование прогноза, чтобы обеспечить правильный тип пиров «по счастливой случайности» связаныпоступил в нужное время. Точная стратегия формирования равных будет разной для каждого класса участников: для правильно масштабированного мультичейн, подборщики должны либо работать постоянно, повторное подключение к соответствующим образом избранным validator, или будет нужны действующие соглашения с подмножеством validators чтобы гарантировать, что они не будут отключены в течение большей части времени, когда они бесполезны для этого validator. Сопоставители также, естественно, будут пытаться поддерживать один или более стабильные соединения с гарантом доступности призваны обеспечить быстрое распространение своих чувствительных к консенсусу данные. Гаранты доступности в основном будут стремиться поддерживать стабильное соединение друг с другом и с validators (для консенсуса и критически важных для консенсуса данных парачейна, к которым они подтверждают), а также некоторым коллаторам (для парачейна данные) и некоторые рыбаки и полные клиенты (для разгона информация). Валидаторы будут склонны искать другие validator, особенно находящиеся в той же подгруппе и любых сборщики, которые могут предоставить им кандидатов на блок парачейна. Рыбаки, а также общие реле-цепи и парацепи клиенты обычно стремятся сохранить соединение открытым для validator или гарант, но множество других подобных узлов себе иначе. Легкие клиенты парачейна также будут стремиться подключиться к полноценному клиенту парачейна. если не просто другие легкие клиенты парачейна. 6.8.1. Проблема оттока коллег. В предложении базового протокола каждое из этих подмножеств постоянно случайным образом меняется с каждым блоком, поскольку validator назначены для проверки. переходы парацепи выбираются случайным образом. Это может быть проблемой, если разрозненные (неодноранговые) узлы должны передавать данные между собой. Нужно либо полагаться на достаточно распределенная и хорошо связанная одноранговая сеть для

POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 18 убедитесь, что расстояние перехода (и, следовательно, задержка в худшем случае) увеличивается только с логарифмом размера сети (здесь может помочь протокол типа Kademlia [13]), или необходимо ввести более длительное время блокировки, чтобы обеспечить необходимое согласование соединения и сохранить набор одноранговых узлов, который отражает текущие коммуникационные потребности узла. Ни одно из этих решений не является отличным решением: длительное время блокировки. принудительное использование сети может сделать ее бесполезной для конкретные приложения и цепочки. Даже совершенно справедливый и подключенной сети приведет к значительным потерям пропускной способности по мере ее масштабирования из-за незаинтересованных узлов, имеющих пересылать бесполезные для них данные. Хотя оба направления могут стать частью решения, разумная оптимизация, помогающая минимизировать задержку, могла бы должно ограничить волатильность этих парачейнов validator наборов, либо переназначая членство только между сериями блоков (например, в группах по 15, что с интервалом в 4 секунды время блокировки будет означать изменение соединений только один раз в минуту) или путем постепенной ротации участников, например меняется по одному члену за раз (например, если есть каждому парачейну назначено 15 validator, то в среднем между совершенно уникальными наборы). Ограничивая количество оттока одноранговых узлов и гарантируя, что выгодные одноранговые соединения устанавливаются хорошо в продвигаться вперед благодаря частичной предсказуемости парачейна наборы, мы можем помочь обеспечить, чтобы каждый узел постоянно сохранял случайный выбор сверстников. 6.8.2. Путь к эффективному сетевому протоколу. Вероятно наиболее эффективные и разумные усилия по разработке будут сосредоточены на использовании уже существующего протокола, а не на его постоянном обновлении. наш собственный. Существует несколько одноранговых базовых протоколов, которые мы можем использовать или дополнять собственный devp2p Ethereum. [22], libp2p [1] IPFS и GNUnet [4] GNU. Полный обзор этих протоколов и их значимости для построения модульная одноранговая сеть, поддерживающая определенные структурные гарантии, динамическое управление одноранговыми узлами и расширяемые подпротоколы выходит далеко за рамки этого документа, но будет важный шаг в реализации Polkadot. 7. Практические аспекты Протокола 7.1. Оплата межсетевых транзакций. Хотя отличный количество свободы и простоты достигается за счет отказа от необходимости в целостной системе учета вычислительных ресурсов, такой как газ Ethereum, это поднимает важный вопрос: как без газа может работать один парачейн избежать того, чтобы другой парачейн заставил его выполнять вычисления? Хотя мы можем полагаться на входную очередь после транзакции буферы, чтобы предотвратить рассылку спама из одной цепочки в другую данных транзакции, в протоколе не существует эквивалентного механизма для предотвращения спама при обработке транзакций. Это проблема, оставленная на более высоком уровне. Поскольку цепи вольны придавать произвольную семантику входящему данные после транзакции, мы можем гарантировать, что вычисление должны быть оплачены до начала работы. В том же духе, что и модель, поддерживаемая Ethereum Безмятежность, которую мы можем себе представить контракт на «взлом» внутри парачейна, который позволяет validator будет гарантирована оплата в обмен на предоставление определенного объема перерабатывающих ресурсов. Эти ресурсы могут измеряться чем-то вроде газа, но это также может быть какая-то совершенно новая модель, такая как субъективное время выполнения или модель фиксированной оплаты, подобная Bitcoin. Само по себе это не так уж полезно, поскольку мы не можем с готовностью предположить, что вызывающая сторона, находящаяся вне сети, имеет доступ к какой бы механизм стоимости ни был распознан взломом контракт. Однако мы можем представить себе вторичный «прорывной» контракт в исходной цепочке. Два контракта вместе образуют мост, признавая друг друга и обеспечение эквивалентности стоимости. (Стейкинг-tokens, доступен каждый из них может быть использован для урегулирования платежного баланса.) Вызов другой такой цепочки будет означать проксирование через этот мост, который обеспечит средства переговоры о передаче стоимости между цепочками с целью оплатить вычислительные ресурсы, необходимые в целевом парачейне. 7.2. Дополнительно Цепи. Пока тот дополнение из а парачейн — относительно дешевая операция, она не бесплатна. Больше парачейнов означает меньше validators на парачейн и, в конечном итоге, большее количество validators, каждый с снижение средней облигации. Хотя проблема меньшей стоимости принуждения для атаки на парачейн смягчается за счет рыбаков, растущая группа validator по существу вынуждает более высокая степень задержки из-за механики основного консенсусаметод. Кроме того, каждый парачейн приносит с собой потенциальную возможность гореть validators с слишком обременительный алгоритм проверки. Таким образом, будет некоторая «цена», которую validators и/или заинтересованное сообщество будет извлекать для добавление нового парачейна. Этот рынок для сетей будет возможно, увидите добавление либо: • Цепочки, которые, скорее всего, не будут платить нулевой чистый взнос (с точки зрения блокировки или сжигания staking tokens), которые должны стать частью (например, цепочки консорциумов, Doge-chains, цепочки для конкретных приложений); • цепочки, которые приносят внутреннюю ценность сети путем добавления определенной функциональности сложно добиться чего-то еще (например, конфиденциальность, внутренняя масштабируемость, привязка к услугам). По сути, сообщество заинтересованных сторон должно будет быть заинтересованы в добавлении дочерних цепочек — либо финансово, либо из-за желания добавить в реле функциональные цепи. Предполагается, что добавление новых сетей будет иметь очень короткий период уведомления об удалении, что позволяет новым цепям можно экспериментировать без какого-либо риска компрометации среднесрочное или долгосрочное ценностное предложение. 8. Заключение Мы наметили направление, по которому можно пойти, чтобы создать масштабируемый, гетерогенный многоцепочный протокол с потенциалом обратной совместимости с определенными, уже существующими blockchain сетей. По такому протоколу участники работать в просвещенных собственных интересах, чтобы создать общую систему, которая может быть расширена исключительно бесплатно и без типичных затрат для существующих пользователей, которые исходит из стандартного дизайна blockchain. Мы дали приблизительный набросок архитектуры, которая потребуется, включая характер участников, их экономические стимулы и процессы, в рамках которых они должны участвовать. У нас есть определили базовую конструкцию и обсудили ее сильные стороны и ограничения; соответственно, у нас есть дальнейшие направления, которые может ослабить эти ограничения и проложить путь к полностью масштабируемому решению blockchain.POLKADOT: ВИДЕНИЕ ГЕТЕРОГЕННОЙ МНОГОЦЕПНОЙ СТРУКТУРЫ ПРОЕКТ 1 19 8.1. Недостающий материал и открытые вопросы. Разветвление сети всегда возможно из-за различных реализаций протокола. Восстановление после такого исключительное состояние не обсуждалось. Учитывая, что сеть обязательно будет иметь ненулевой период завершения, восстановление после разветвления релейной цепи не должно представлять собой большой проблемы, однако потребует тщательной интеграции в протокол консенсуса. Конфискация облигаций и, наоборот, предоставление вознаграждения не были глубоко исследованы. В настоящее время мы принимаем вознаграждения предоставляются по принципу «победитель получает все»: это может не предложить лучшую модель стимулирования рыбаков. Кратковременный процесс раскрытия информации позволил бы многим рыбакам претендовать на приз, обеспечивающий более справедливое распределение вознаграждений, однако этот процесс может привести к дополнительной задержке в обнаружение неправомерного поведения. 8.2. Благодарности. Большое спасибо всем корректоры, которые помогли донести это до смутного презентабельная форма. В частности, Петер Чабан, Бьёрн Вагнер, Кен Капплер, Роберт Хабермайер, Виталик Бутерин, Рето Тринклер и Джек Петерссон. Спасибо всем люди, которые внесли идеи или начинания в связи с этим особого упоминания заслуживают Марек Котевич и Аэрон Бьюкенен. И спасибо всем остальным за помощь по пути. Все ошибки мои собственные. Части этой работы, включая первоначальные исследования алгоритмов консенсуса, частично финансировался Великобританией. Правительство в рамках программы Innovate UK.