Polkadot: Visi untuk Kerangka Multi-Rantai yang Heterogen
Resumo
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 DR. MADEIRA GAVIN FUNDADOR, ETHEREUM E PARIDADE [email protected] Resumo. Todas as arquiteturas blockchain atuais sofrem de uma série de problemas, incluindo meios práticos de extensibilidade e escalabilidade. Acreditamos que isto decorre da ligação de duas partes muito importantes da arquitectura de consenso, nomeadamente canonicidade e validade, muito próximas. Este artigo apresenta uma arquitetura, a multicadeia heterogênea, o que fundamentalmente diferencia os dois. Ao compartimentar estas duas partes e ao manter a funcionalidade geral fornecida a um mínimo absoluto de segurança e transporte, introduzimos meios práticos de extensibilidade central in situ. A escalabilidade é abordada através uma abordagem de dividir e conquistar para estas duas funções, expandindo-se para fora do seu núcleo ligado através do incentivo de nós públicos não confiáveis. A natureza heterogênea desta arquitetura permite que muitos tipos altamente divergentes de sistemas de consenso interoperem em uma “federação” totalmente descentralizada e sem confiança, permitindo que redes abertas e fechadas tenham acesso livre de confiança a um ao outro. Apresentamos um meio de fornecer compatibilidade retroativa com uma ou mais redes pré-existentes, como Ethereum. Acreditamos que tal sistema fornece um componente de nível básico útil na busca geral por um sistema praticamente sistema implementável capaz de atingir níveis de escalabilidade e privacidade no comércio global. 1. Prefácio Este pretende ser um resumo técnico da “visão” de uma possível direção que pode ser tomada no desenvolvimento do paradigma blockchain, juntamente com alguma justificativa sobre por que essa direção é sensata. Ele se estabelece em tantos detalhes quanto possível neste estágio de desenvolvimento um sistema que possa proporcionar uma melhoria concreta num vários aspectos da tecnologia blockchain. Não pretende ser uma especificação, formal ou não. Não pretende ser abrangente nem ser uma projeto final. Não se destina a cobrir aspectos não essenciais da estrutura, como APIs, ligações, linguagens e uso. Isto é notavelmente experimental; onde parâmetros são especificados, eles provavelmente mudarão. Os mecanismos irão ser adicionado, refinado e removido em resposta às necessidades da comunidade ideias e críticas. Grandes porções deste documento provavelmente serão ser revisado à medida que evidências experimentais e prototipagem fornecem nos informações sobre o que funcionará e o que não funcionará. Este documento inclui uma descrição básica do protocolo, juntamente com ideias de orientações que podem ser tomadas para melhorar vários aspectos. Prevê-se que o núcleo descrição será usada como ponto de partida para uma série de provas de conceito. Uma “versão 1.0” final seria baseado neste protocolo refinado, juntamente com as ideias adicionais que foram comprovadas e estão determinadas a necessários para que o projeto atinja seus objetivos. 1.1. História. • 10/09/2016: 0.1.0-prova1 • 20/10/2016: 0.1.0-prova2 • 11/01/2016: 0.1.0-prova3 • 11/10/2016: 0.1.0 2. Introdução Blockchains demonstraram grande promessa de utilidade em vários campos, incluindo “Internet das Coisas” (IoT), finanças, governança, gestão de identidade, descentralização da web e rastreamento de ativos. No entanto, apesar do promessa tecnológica e grande conversa, ainda não vimos implantação significativa no mundo real da tecnologia atual. Acreditamos que isto se deve a cinco falhas principais da actual pilhas de tecnologia: Escalabilidade: quantos recursos são gastos globalmente sobre processamento, largura de banda e armazenamento para o sistema processar uma única transação e quantas as transações podem ser razoavelmente processadas sob condições de pico? Isolabilidade: As necessidades divergentes de múltiplos as partes e as candidaturas sejam abordadas num grau quase óptimo no âmbito do mesmo enquadramento? Capacidade de desenvolvimento: quão bem as ferramentas funcionam? Faça as APIs atendem às necessidades dos desenvolvedores? Existem materiais educativos disponíveis? As integrações certas estão aí? Governança: A rede pode permanecer flexível para evoluir e se adaptar ao longo do tempo? As decisões podem ser feito com suficiente inclusão, legitimidade e transparência para fornecer liderança eficaz de um sistema descentralizado? Aplicabilidade: A tecnologia realmente atende a uma necessidade premente por si só? É necessário outro “middleware” para preencher a lacuna para aplicações reais? No presente trabalho pretendemos abordar os dois primeiros questões: escalabilidade e isolabilidade. Dito isto, acreditamos a estrutura Polkadot pode fornecer melhorias significativas em cada uma dessas classes de problemas. Implementações blockchain modernas e eficientes, como o cliente Paridade Ethereum [17] pode processarmenos em excesso 3.000 transações por segundo quando executado em hardware de consumo de alto desempenho. No entanto, o mundo real atual blockchain redes estão praticamente limitadas a cerca de 30 transações por segundo. Esta limitação tem origem principalmente no facto de os actuais mecanismos de consenso síncrono exigirem amplas margens temporais de segurança em o tempo de processamento esperado, que é agravado pela 1
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
Introdução
Blockchains demonstraram grande promessa de utilidade em vários campos, incluindo “Internet das Coisas” (IoT), finanças, governança, gestão de identidade, descentralização da web e rastreamento de ativos. No entanto, apesar do promessa tecnológica e grande conversa, ainda não vimos implantação significativa no mundo real da tecnologia atual. Acreditamos que isto se deve a cinco falhas principais da actual pilhas de tecnologia: Escalabilidade: quantos recursos são gastos globalmente sobre processamento, largura de banda e armazenamento para o sistema processar uma única transação e quantas as transações podem ser razoavelmente processadas sob condições de pico? Isolabilidade: As necessidades divergentes de múltiplos as partes e as candidaturas sejam abordadas num grau quase óptimo no âmbito do mesmo enquadramento? Capacidade de desenvolvimento: quão bem as ferramentas funcionam? Faça as APIs atendem às necessidades dos desenvolvedores? Existem materiais educativos disponíveis? As integrações certas estão aí? Governança: A rede pode permanecer flexível para evoluir e se adaptar ao longo do tempo? As decisões podem ser feito com suficiente inclusão, legitimidade e transparência para fornecer liderança eficaz de um sistema descentralizado? Aplicabilidade: A tecnologia realmente atende a uma necessidade premente por si só? É necessário outro “middleware” para preencher a lacuna para aplicações reais? No presente trabalho pretendemos abordar os dois primeiros questões: escalabilidade e isolabilidade. Dito isto, acreditamos a estrutura Polkadot pode fornecer melhorias significativas em cada uma dessas classes de problemas. Implementações blockchain modernas e eficientes, como o cliente Parity Ethereum [17] pode processar mais de 3.000 transações por segundo quando executado em hardware de consumo de alto desempenho. No entanto, o mundo real atual blockchain redes estão praticamente limitadas a cerca de 30 transações por segundo. Esta limitação tem origem principalmente no facto de os actuais mecanismos de consenso síncrono exigirem amplas margens temporais de segurança em o tempo de processamento esperado, que é agravado pelaPOLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 2 desejo de apoiar implementações mais lentas. Isto é devido a a arquitetura de consenso subjacente: o mecanismo de transição do estado, ou os meios pelos quais as partes agrupam e executar transações, tem sua lógica fundamentalmente ligada no mecanismo de “canonização” de consenso, ou no meio pelo qual as partes acordam uma de uma série de histórias possíveis e válidas. Isso se aplica igualmente a sistemas proof-of-work (PoW), como Bitcoin [15] e Ethereum [5,23] e sistemas de prova de aposta (PoS), como NXT [8] e Bitshares [12]: em última análise, todos sofrem da mesma deficiência. É um simples estratégia que ajudou a tornar blockchains um sucesso. No entanto, acoplando firmemente esses dois mecanismos em uma única unidade do protocolo, também agrupamos vários diferentes atores e aplicações com diferentes perfis de risco, diferentes requisitos de escalabilidade e diferentes necessidades de privacidade. Um tamanho não serve para todos. Acontece com demasiada frequência que, num desejo de amplo apelo, uma rede adota um grau de conservadorismo que resulta em um menor denominador comum servindo de forma otimizada a poucos e, em última análise, levando a um fracasso na capacidade de inovar, executar e adaptar, às vezes dramaticamente. Alguns sistemas, como por ex. Factom [21] abandona completamente o mecanismo de transição de estado. No entanto, grande parte utilidade que desejamos requer a capacidade de transição de estado de acordo com uma máquina de estados compartilhada. Deixar cair resolve um problema alternativo; não oferece uma alternativa solução. Parece claro, portanto, que uma direção razoável explorar como um caminho para uma computação descentralizada e escalonável plataforma é dissociar a arquitetura de consenso da o mecanismo de transição de estado. E, talvez sem surpresa, esta é a estratégia que Polkadot adota como solução para escalabilidade. 2.1. Protocolo, Implementação e Rede. Gosto Bitcoin e Ethereum, Polkadot referem-se ao mesmo tempo a um protocolo de rede e ao (até então pressuposto) primário rede pública que executa este protocolo. Polkadot pretende ser um projeto gratuito e aberto, a especificação do protocolo está sob uma licença Creative Commons e o código sendo colocado sob uma licença FLOSS. O projeto é desenvolvido de forma aberta e aceita contribuições onde quer que sejam úteis. Um sistema de RFCs, não muito diferente as propostas de melhoria do Python, permitirão um meio de colaborar publicamente em mudanças e atualizações de protocolo. Nossa implementação inicial do protocolo Polkadot será conhecida como Plataforma Parity Polkadot e será inclui uma implementação completa do protocolo junto com API ligações. Como outras implementações de Paridade blockchain, O PPP foi projetado para ser uma pilha de tecnologia blockchain de uso geral, não exclusivamente para uma rede pública nem para operação privada/consorciada. O seu desenvolvimento assim até agora foi financiado por vários partidos, inclusive através de uma subvenção do governo britânico. Este artigo, no entanto, descreve Polkadot sob o contexto de uma rede pública. A funcionalidade que imaginamos em uma rede pública é um superconjunto daquela exigida em configurações alternativas (por exemplo, privadas e/ou consórcios). Além disso, neste contexto, o escopo completo de Polkadot pode ser mais claramente descritas e discutidas. Isso significa o leitor deve estar ciente de que certos mecanismos podem ser descritos (por exemplo, interoperação com outras redes públicas) que não são diretamente relevantes para Polkadot quando implantado em situações não públicas (“permitidas”). 2.2. Trabalho anterior. A dissociação do consenso subjacente da transição do Estado foi proposta informalmente em privado durante pelo menos dois anos - Max Kaye foi um defensor de tal estratégia durante os primeiros dias de Ethereum. Uma solução escalável mais complexa conhecida como Chain fibras, que remonta a junho de 2014 e publicado pela primeira vez mais tarde naquele ano1, defendeu uma única cadeia de retransmissão e múltiplas cadeias homogêneas, fornecendo um mecanismo transparente de execução intercadeias. A decoerência foi paga através da latência de transação – transações que exigem o coordenação de porções díspares do sistema demorar mais para processar. Polkadot tira grande parte de sua arquitetura disso e das conversas de acompanhamento com várias pessoas, embora seja muito diferente em grande parte do seu design e disposições. Embora não existam sistemas comparáveis a Polkadot atualmente em produção, vários sistemas de alguma relevância foram propostas, embora poucas em qualquer nível substancial de detalhe. Estas propostas podem serdividido em sistemas que eliminam ou reduzem a noção de um mundo globalmente coerente máquina estatal, aquelas que tentam fornecer uma solução global máquina singleton coerente por meio de fragmentos homogêneos e aqueles que visam apenas a heterogeneidade. 2.2.1. Sistemas sem Estado Global. Factom [21] é um sistema que demonstra canonicidade sem o acordo validade, permitindo efetivamente o registro dos dados. Devido à evitação do estado global e às dificuldades com o dimensionamento que isso traz, pode ser considerada uma solução escalonável. No entanto, como mencionado anteriormente, o conjunto de problemas que resolve é estrita e substancialmente menor. Tangle [18] é uma nova abordagem para sistemas de consenso. Em vez de organizar as transacções em blocos e formar consenso sobre uma lista estritamente ligada para fornecer uma ordenação globalmente canónica das mudanças de estado, abandona em grande parte a ideia de uma ordenação fortemente estruturada e, em vez disso, busca um gráfico acíclico direcionado de transações dependentes com itens posteriores ajudando a canonizar itens anteriores através de referências explícitas. Para mudanças de estado arbitrárias, este gráfico de dependência se tornaria rapidamente intratável, no entanto, para o modelo UTXO2 muito mais simples, isso se torna bastante razoável. Como o sistema é apenas vagamente coerente e as transações são geralmente independentes uma da outra outro, uma grande quantidade de paralelismo global torna-se bastante natural. Usar o modelo UTXO tem o efeito de limitar o Tangle a uma “moeda” puramente de transferência de valor sistema em vez de algo mais geral ou extensível. Além disso, sem a dura coerência global, a interacção com outros sistemas – que tendem a necessitar de uma conhecimento de grau sobre o estado do sistema - torna-se impraticável. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2saída de transação não gasta, o modelo que Bitcoin usa, em que o estado é efetivamente o conjunto de endereços associados a algum valor; as transações agrupam esses endereços e os transformam em um novo conjunto de endereços cuja soma total é equivalente
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 3 2.2.2. Sistemas de Cadeias Heterogêneas. Cadeias laterais [3] é um adição proposta ao protocolo Bitcoin que permitiria interação sem confiança entre a cadeia Bitcoin principal e cadeias laterais adicionais. Não há previsão de qualquer grau de interação “rica” entre cadeias laterais: a interação seria limitada a permitir que as cadeias laterais fossem custodiantes dos bens uns dos outros, efetuando - no local jargão - uma indexação bidirecional 3. A visão final é para uma estrutura onde a moeda Bitcoin possa ser fornecida com funcionalidade adicional, se periférica, por meio de sua vinculação em algumas outras cadeias com transição de estado mais exótica sistemas do que o protocolo Bitcoin permite. Nesse sentido, as cadeias laterais abordam a extensibilidade em vez da escalabilidade. Na verdade, não há fundamentalmente nenhuma disposição sobre a validade das cadeias laterais; tokens de uma cadeia (por exemplo, Bitcoin) mantidos em nome de uma cadeia lateral são garantidos apenas pelo a capacidade da cadeia lateral de incentivar os mineradores a canonizar transições válidas. A segurança da rede Bitcoin não pode ser facilmente transferido para trabalhar em nome de outros blockchains. Além disso, um protocolo para garantir Bitcoin os mineradores fundem a mina (isto é, duplicam seu poder de canonização no da cadeia lateral) e, mais importante, validam que as transições da cadeia lateral estão fora do âmbito desta proposta. Cosmos [10] é um sistema multi-cadeia proposto no mesma linha das cadeias laterais, trocando o Nakamoto PoW método de consenso para o algoritmo Tendermint de Jae Kwon. Essencialmente, descreve múltiplas cadeias (operando em zonas) cada uma usando instâncias individuais do Tendermint, juntamente com um meio de comunicação livre de confiança através de um cadeia de cubo mestre. Esta comunicação entre cadeias é limitada à transferência de ativos digitais (“especificamente sobre tokens”) em vez de informações arbitrárias, no entanto, tal comunicação entre cadeias tem um caminho de retorno para dados, por exemplo para informar ao remetente o status da transferência. Conjuntos de validadores para as cadeias zoneadas e, em particular os meios de incentivá-los, são, como cadeias laterais, deixadas como um problema não resolvido. A suposição geral é que cada cadeia zoneada conterá ela própria um token de valor cuja inflação é usada para pagar por validators. Ainda nos estágios iniciais de design, atualmente a proposta carece de detalhes abrangentes sobre os meios económicos para alcançar a escalabilidade certeza sobre a validade global. Contudo, a fraca coerência necessária entre as zonas e o centro permitirá para flexibilidade adicional sobre os parâmetros do zoneamento cadeias em comparação com um sistema que impõe medidas mais fortes coerência. 2.2.3. Cásper. Ainda não há revisão abrangente ou comparação lado a lado entre Casper [6] e Polkadot foram feitas, embora se possa fazer uma análise bastante abrangente caracterização (e, portanto, imprecisa) dos dois. Casper é uma reimaginação de como um algoritmo de consenso PoS poderia ser baseado em participantes apostando em qual garfo acabaria por se tornar canônico. Consideração substancial foi dada para garantir que ele fosse robusto para a rede forks, mesmo quando prolongados, e possuem algum grau adicional de escalabilidade além do modelo Ethereum básico. Como tal, Casper até agora tendeu a ser um substancialmente mais protocolo complexo do que Polkadot e seus antepassados, e um desvio substancial do formato blockchain básico. Isso permanece sem saber como Casper irá iterar no futuro e como será se finalmente for implantado. Embora Casper e Polkadot representem novos protocolos interessantes e, em certo sentido, aumentos de Ethereum, existem diferenças substanciais entre seus objetivos finais e caminhos para implantação. Cásper é um Ethereum Projeto centrado na fundação originalmente concebido ser uma alteração PoS no protocolo sem desejo de crie um blockchain fundamentalmente escalável. Crucialmente, é projetado para ser um hard fork, em vez de algo mais expansivo e, portanto, todos os Ethereum clientes e usuários seriam necessário atualizar ou permanecer em uma bifurcação de adoção incerta. Como tal, a implementação torna-se substancialmente mais difícil, como é inerente a um projecto descentralizado onde coordenação é necessária. Polkadot difere de várias maneiras; em primeiro lugar, Polkadot foi projetado para ser totalmente extensível e escalável blockchain teste de desenvolvimento, implantação e interação cama. Ele foi construído para ser um arnês amplamente preparado para o futuro, capaz de assimilar novo blockchaintecnologia à medida que se torna disponível, sem coordenação descentralizada excessivamente complicada ou garfos rígidos. Já imaginamos vários casos de uso, como como cadeias de consórcio criptografadas e cadeias de alta frequência com tempos de bloqueio muito baixos que são irrealistas de fazer em qualquer versão futura de Ethereum atualmente prevista. Finalmente, o acoplamento entre ele e Ethereum é extremamente solto; nenhuma ação por parte de Ethereum é necessária para permitir o encaminhamento de transações sem confiança entre os dois redes. Resumindo, enquanto Casper/Ethereum 2.0 e Polkadot compartilham algumas semelhanças passageiras, acreditamos que seu objetivo final é substancialmente diferente e que, em vez de competir, os dois protocolos provavelmente coexistirão sob um relacionamento mutuamente benéfico para o futuro previsível.
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.
Resumo
Polkadot é uma multicadeia heterogênea escalável. Isto significa que, diferentemente das implementações anteriores de blockchain que se concentraram em fornecer uma única cadeia de diversos graus de generalidade sobre aplicações potenciais, Polkadot em si foi projetado para não fornecer nenhuma funcionalidade inerente ao aplicativo. Em vez disso, Polkadot fornece a base “cadeia de retransmissão” sobre a qual um grande número de informações validáveis, estruturas de dados dinâmicas globalmente coerentes podem ser hospedadas lado a lado. Chamamos essas estruturas de dados de “paralelizadas” correntes ou parachains, embora não haja necessidade específica de eles sejam de natureza blockchain. Em outras palavras, Polkadot pode ser considerado equivalente a um conjunto de cadeias independentes (por exemplo, o conjunto contendo Ethereum, Ethereum Classic, Namecoin e Bitcoin), exceto por dois pontos muito importantes: • Segurança conjunta; • transacionalidade entre cadeias sem confiança. É por esses pontos que consideramos Polkadot “escalável”. Em princípio, um problema a ser implantado em Polkadot pode ser substancialmente paralelizado - ampliado - ao longo de um grande número de pára-quedas. Como todos os aspectos de cada parachain pode ser conduzido em paralelo por um segmento diferente da rede Polkadot, o sistema tem alguma capacidade para escalar. Polkadot fornece um pedaço bastante básico de 3em oposição a uma fixação unilateral que é essencialmente a ação de destruir tokens em uma cadeia para criar tokens em outra sem o mecanismo para fazer o inverso a fim de recuperar os tokens originaisPOLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 4 infraestrutura, deixando grande parte da complexidade para ser abordada no nível do middleware. Esta é uma decisão consciente que visa reduzir o risco de desenvolvimento, permitindo que a software necessário a ser desenvolvido em um curto espaço de tempo e com um bom nível de confiança sobre sua segurança e robustez. 3.1. A Filosofia de Polkadot. Polkadot deveria fornecer uma base absolutamente sólida sobre a qual construir a próxima onda de sistemas de consenso, através o espectro de risco de projetos maduros com capacidade de produção às ideias nascentes. Ao fornecer fortes garantias de segurança, isolamento e comunicação, Polkadot pode permitir parachains para selecionar entre uma variedade de propriedades. Na verdade, prevemos vários blockchains experimentais empurrando as propriedades do que poderia ser considerado sensato hoje. Vemos conservadores, cadeias de alto valor semelhantes a Bitcoin ou Z-cash [20] coexistindo com valores mais baixos “cadeias temáticas” (como marketing, tão divertido) e redes de teste com taxas zero ou quase zero. Vemos totalmente criptografado, cadeias de consórcios “obscuras” operando lado a lado – e até mesmo fornecendo serviços para cadeias altamente funcionais e abertas como aqueles como Ethereum. Vemos novos experimentos Cadeias baseadas em VM, como um wasm subjetivo com cobrança de tempo cadeia sendo usada como um meio de terceirizar problemas de computação difíceis de uma cadeia mais madura do tipo Ethereum ou uma cadeia mais restrita do tipo Bitcoin. Para gerenciar atualizações em cadeia, Polkadot irá inerentemente apoiar algum tipo de estrutura de governança, provavelmente baseada nos sistemas políticos estáveis existentes e com um aspecto bicameral semelhante ao Conselho do Livro Amarelo [24]. Como a autoridade final, os detentores subjacentes de token teriam o controle do “referendo”. Para refletir a opinião dos usuários necessidade de desenvolvimento, mas a necessidade de legitimidade dos desenvolvedores, esperamos que uma direção razoável seja formar as duas câmaras de um comitê “usuário” (composto por vinculados validators) e um comitê “técnico” composto dos principais desenvolvedores de clientes e participantes do ecossistema. O corpo de titulares de token manteria a legitimidade final e formaria uma maioria absoluta para aumentar, reparametrizar, substituir ou dissolver esta estrutura, algo que não duvide da eventual necessidade de: nas palavras de Twain “Governos e fraldas devem ser trocadas com frequência, e para pelo mesmo motivo”. Embora a reparametrização seja normalmente trivial de organizar dentro de um mecanismo de consenso mais amplo, mudanças mais qualitativas, como substituição e aumento, seriam necessárias. provavelmente precisarão ser “decretos suaves” não automatizados (por exemplo, através da canonização de um número de bloco e da hash de um documento especificando formalmente o novo protocolo) ou exigir que o mecanismo central de consenso contenha um linguagem suficientemente rica para descrever qualquer aspecto de si mesmo que pode precisar mudar. Este último é um objetivo eventual, no entanto, é mais provável que o primeiro seja escolhido para facilitar um cronograma de desenvolvimento razoável. Os princípios primários de Polkadot e as regras dentro das quais avaliamos todas as decisões de design são: Mínimo: Polkadot deve ter o mínimo de funcionalidade possível. Simples: nenhuma complexidade adicional deve estar presente no protocolo base do que pode razoavelmente ser transferido para middleware, colocado através de um parachain ou introduzido em uma otimização posterior. Geral: nenhum requisito desnecessário, restrição ou limitação deve ser colocada em pára-quedas; Polkadot deve ser uma plataforma de teste para o desenvolvimento de sistema de consenso que pode ser otimizado por meio de tornando o modelo no qual as extensões se enquadram o mais abstrato possível. Robusto: Polkadot deve fornecer fundamentalmente camada base estável. Além da solidez económica, isto também significa descentralizar para minimizar os vetores para ataques de alta recompensa.
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.
Participação em Polkadot
Existem quatro funções básicas na manutenção de um Polkadot rede: coletor, pescador, nomeador e validator. Em uma possível implementação de Polkadot, a última função na verdade, pode ser dividido em duas funções: validator básico e fiador de disponibilidade; isso é discutido na seção 6.5.3. Coletor Pescador Validadores (este grupo) Validadores (outros grupos) aprova torna-se monitores relatórios ruim comportamento para fornece bloco candidatos para Nomeador Figura 1. A interação entre o quatro funções de Polkadot. 4.1. Validadores. Um validator é a cobrança mais alta e ajuda a selar novos blocos na rede Polkadot. O papel do validator depende de um título suficientemente alto sendo depositado, embora permitamos que outras partes vinculadas nomear um ou mais validators para agir em seu nome e como tal parte do título do validator pode não ser necessariamente propriedade do próprio validator, mas sim destes nomeadores. Um validator deve executar uma implementação de cliente de cadeia de retransmissão com alta disponibilidade e largura de banda. Em cada bloco o nó deve estar pronto para aceitar o papel de ratificar um novo bloco em um parachain nomeado. Este processo envolve receber, validar e republicar candidatos blocos. A nomeação é determinística, mas virtualmente imprevisível com muita antecedência. Como o validator não pode razoavelmente esperado que mantenha um sistema totalmente sincronizado banco de dados de todos os parachains, espera-se que o validator nomeie a tarefa de elaborar uma nova sugestão bloco parachain para terceiros, conhecido como agrupador. Uma vez que todos os novos blocos de parachain tenham sido devidamente ratificados por seus subgrupos validator designados, validators deve então ratificar o próprio bloco da cadeia de relés. Isso envolve atualizando o estado das filas de transação (essencialmente mover dados da fila de saída de um parachain para outra fila de entrada do parachain), processando as transações de o conjunto de transações ratificadas em cadeia de retransmissão e ratificando o bloco final, incluindo as alterações finais do parachain.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 5 Um validator não cumprindo seu dever de encontrar consenso sob as regras do nosso algoritmo de consenso escolhido é punido. Para falhas iniciais e não intencionais, isso ocorre através retendo a recompensa de validator. Falhas repetidas resultam na redução do seu título de segurança (através da queima). Ações provavelmente maliciosas, como assinatura dupla ou conspirar para fornecer um bloqueio inválido resultará na perda de todo o vínculo (que está parcialmente queimado, mas principalmente dado ao informante e aos atores honestos). Em certo sentido, validators são semelhantes aos pools de mineração dos PoW atuais blockchains. 4.2. Nomeadores. Um nominador é uma parte interessada que contribui para a caução de um validator. Eles não têm qualquer função adicional, exceto a de colocar capital de risco e como tal para sinalizar que eles confiam em um determinado validator (ou conjunto deles) a agir com responsabilidade na manutenção do rede. Eles recebem um aumento ou redução proporcional em seu depósito de acordo com o crescimento do título ao qual eles contribuem. Juntamente com os agrupadores, em seguida, os nomeadores estão em alguns sentido semelhante aos mineradores das redes PoW atuais. 4.3. Coletores. Agrupadores de transações (abreviadamente agrupadores) são partes que auxiliam validators na produção de blocos de pára-quedas. Eles mantêm um “nó completo” para um parachain específico; o que significa que eles retêm todos os recursos necessários informações para poder criar novos blocos e executar transações da mesma maneira que os mineradores fazem nos PoW blockchains atuais. Em circunstâncias normais, eles irá agrupar e executar transações para criar um não selado bloquear e fornecê-lo, junto com um conhecimento zero prova, para um ou mais validators atualmente responsáveis por propondo um bloco parachain. A natureza precisa do relacionamento entre agrupadores, nomeadores e validators provavelmente mudará ao longo tempo. Inicialmente, esperamos que os agrupadores trabalhem em estreita colaboração com validators, já que haverá apenas alguns (talvez apenas um) parachain(s) com pouco volume de transações. O a implementação inicial do cliente incluirá RPCs para permitir um nó de agrupamento parachain para fornecer incondicionalmente um nó (relaychain) validator com um parachain comprovadamente válido bloco. Como o custo de manutenção de uma versão sincronizada do todos esses parachains aumentam, esperamos ver infra-estrutura existente que ajudará a separar o deveres para com partidos independentes e com motivação económica. Eventualmente, esperamos ver pools de agrupamentos que disputam coletar o máximo de taxas de transação. Esses agrupadores podem ser contratados para atender validators específicos durante um período de tempo por uma participação contínua nos rendimentos da recompensa. Alternativamente, os agrupadores “freelance” podem simplesmente criar um mercado que oferece blocos de parachain válidos em troca de uma parcela competitiva da recompensa pagável imediatamente. Da mesma forma, os grupos de nominadores descentralizados permitiriam múltiplos participantes vinculados para coordenar e compartilhar o dever de um validator. Esta capacidade de reunir garante uma participação aberta levando a um sistema mais descentralizado. 4.4. Pescadores. Ao contrário dos outros dois partidos activos, pescadores não estão diretamente relacionados com a autoria do bloco processo. Em vez disso, eles são “caçadores de recompensas” independentes motivado por uma grande recompensa única. Precisamente devido a existência de pescadores, esperamos que eventos de mau comportamento aconteçam raramente, e quando acontecem apenas devido a a parte vinculada sendo descuidada com a segurança da chave secreta, e não através de intenção maliciosa. O nome vem desde a frequência esperada da recompensa, os requisitos mínimos para participar e o eventual tamanho da recompensa. Os pescadores obtêm a sua recompensa através de uma prova atempada de que pelo menos uma parte vinculada agiu ilegalmente. Ações ilegais incluem assinar dois blocos cada um com o mesmo pai ratificado ou, no caso de parachains, ajudar a ratificar um inválido bloco. Para evitar recompensas excessivas ou o compromisso e uso ilícito da chave secreta de uma sessão, a recompensa básica para fornecer uma única mensagem assinada ilegalmente por validator é mínimo. Esta recompensa aumenta assintoticamente à medida que mais corroborar assinaturas ilegais de outros validators são desde que implique um ataque genuíno. A assíntota está definida em 66% seguindo nossa afirmação básica de segurança de que pelo menos dois terços dos validators agem com benevolência. Os pescadores são um pouco semelhantes aos “nós completos” em sistemas blockchain atuais que os recursos necessários são relativamente pequenos e o compromisso de tempo de atividade estável e largura de banda não é necessária. Os pescadores diferem tanto tanto quanto eles devem pagar uma pequena fiança.Esse vínculo impede ataques Sybil desperdiçam tempo e computação de validators recursos. É imediatamente retirável, provavelmente não mais do que o equivalente a alguns dólares e pode levar para colher uma grande recompensa por detectar um mau comportamento validator.
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.
Visão geral do projeto
Esta seção tem como objetivo fornecer uma breve visão geral do sistema como um todo. Uma exploração mais aprofundada do sistema é fornecido na seção seguinte. 5.1. Consenso. Na cadeia de retransmissão, Polkadot atinge consenso de baixo nível sobre um conjunto de regras válidas mutuamente acordadas blocos por meio de um algoritmo moderno assíncrono bizantino tolerante a falhas (BFT). O algoritmo será inspirado pelo simples Tendermint [11] e pelo substancialmente mais envolvido HoneyBadgerBFT [14]. Este último fornece uma consenso eficiente e tolerante a falhas sobre um acordo arbitrariamente infraestrutura de rede defeituosa, dado um conjunto de autoridades em sua maioria benignas ou validators. Para uma rede estilo prova de autoridade (PoA), só isso seria suficiente, no entanto, Polkadot é imaginado como sendo também implantável como uma rede em um ambiente totalmente aberto e público situação sem qualquer organização específica ou confiável autoridade necessária para mantê-lo. Como tal precisamos de um meio de determinar um conjunto de validators e incentivar para serem honestos. Para isso utilizamos seleção baseada em PoS critérios. 5.2. Provando a aposta. Supomos que a rede terá alguns meios de medir quanto “aposta” qualquer conta específica possui. Para facilitar a comparação com sistemas pré-existentes, chamaremos a unidade de medida “tokens”. Infelizmente, o termo não é o ideal para uma uma série de razões, inclusive por ser simplesmente um escalar valor associado a uma conta, não há noção de individualidade. Imaginamos que validators sejam eleitos, raramente (no máximo uma vez por dia, mas talvez tão raramente quanto uma vez por trimestre), através de um esquema de Prova de Participação Nomeada (NPoS). O incentivo pode acontecer através de uma alocação proporcional dePOLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 6 Relé corrente Enxame de validadores (cada um colorido por seu pára-quedas designado) Transação (enviado por ator externo) Parachain ponte Parachain virtual (por exemplo, Ethereum) Parachain Parachain filas e E/S Transações propagadas Bloquear envio de candidato 2ª ordem Cadeia de relés Comunidade Parachain Conta Transação de entrada Transação de saída Transações intercadeias (gerenciado por validators) Coletor Bloco propagado Pescador Figura 2. Um esquema resumido do sistema Polkadot. Isso mostra agrupadores coletando e propagando transações de usuários, bem como propagando candidatos a blocos para pescadores e validators. Também mostra como uma conta pode lançar uma transação que é realizada em seu parachain, através da cadeia de retransmissão e em outro parachain onde pode ser interpretado como uma transação para uma conta lá. fundos provenientes de uma expansão de base token (até 100% por ano, embora mais provavelmente em torno de 10%), juntamente com quaisquer taxas de transação cobradas. Embora a expansão da base monetária normalmente leve à inflação, uma vez que todos os proprietários de token teria uma oportunidade justa de participação, nenhum titular de token precisaria sofrer uma redução no valor de seus participações ao longo do tempo, desde que estivessem felizes em assumir um papel no mecanismo de consenso. Uma proporção específica de tokens seriam direcionados para o processo staking; o a expansão efetiva da base token seria ajustada através um mecanismo baseado no mercado para atingir esta meta. Os validadores estão fortemente vinculados às suas apostas; saindo Os títulos dos validators permanecem em vigor por muito tempo após o término das obrigações dos validators (talvez cerca de 3 meses). Tanto tempo período de liquidação de títulos permite que mau comportamento futuro seja punido até a verificação periódica da cadeia. O mau comportamento resulta em punição, como redução de recompensa ou, nos casos que comprometam intencionalmente a integridade da rede, o validator perdendo parte ou todos os seus interesse para outros validators, informantes ou partes interessadas como um todo (através da queima). Por exemplo, um validator que tenta ratificar ambos os ramos de uma bifurcação (às vezes conhecido como ataque de “curto alcance”) pode ser identificado e punido desta última forma. Ataques de longo alcance “nada em jogo”4 são contornados através de um simples bloqueio de “ponto de verificação” que impede uma reorganização perigosa da cadeia de mais de um profundidade de cadeia específica. Para garantir clientes recém-sincronizados não podem ser enganados na corrente errada, regular ocorrerão “hard forks” (no máximo no mesmo período do validators’ liquidação de títulos) que codifica o bloco de ponto de verificação recente hashes nos clientes. Isto funciona bem com uma medida adicional de redução da pegada de “comprimento finito da cadeia” ou reinicialização periódica do bloco genesis. 5.3. Parachains e coladores. Cada pára-quedas recebe recursos de segurança semelhantes à cadeia de relés: o os cabeçalhos dos parachains são selados dentro do bloco da cadeia de relés garantir que nenhuma reorganização ou “gasto duplo” seja possível após a confirmação. Esta é uma garantia de segurança semelhante à oferecida pelas cadeias laterais e fusão de Bitcoin. Polkadot, no entanto, também fornece fortes garantias de que as transições de estado dos parachains são válidas. Isto acontece através do conjunto de validators sendo segmentado criptograficamente aleatoriamente em subconjuntos; um subconjunto por parachain, os subconjuntos potencialmente diferentes por bloco. Isto a configuração geralmente implica que os tempos de bloqueio dos parachains serão ser pelo menos tão longo quanto o da cadeia de relés. O específico meio de determinar o particionamento está fora do escopo 4É neste tipo de ataque que o adversário forja uma cadeia histórica inteiramente nova, a partir do bloco génese. Através do controle de um parcela relativamente insignificante da aposta na compensação, eles são capazes de aumentar gradativamente sua parcela da aposta em relação a todos os outros partes interessadas, pois são os únicos participantes activos na sua história alternativa. Como não existe nenhuma limitação física intrínseca na criação de blocos (ao contrário do PoW, onde a energia computacional bastante real deve ser gasta), eles são capazes de criar uma cadeia mais longa do que a cadeia real em um intervalo de tempo relativamente curto e potencialmente torná-lo o mais longo e melhor, assumindo o estado canônico da rede.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 7 deste documento, mas provavelmente seria baseado em torno uma estrutura de confirmação-revelação semelhante ao RanDAO [19] ou use dados combinados de blocos anteriores de cada parachain sob um hash criptograficamente seguro. Esses subconjuntos de validators são necessários para fornecer um candidato de bloco parachain que é garantido como válido (em dor de confisco de títulos). A validade gira em torno de dois pontos importantes; primeiro, que é intrinsecamente válido – que todas as transições de estado foram executadas fielmente e que todas os dados externos referenciados (ou seja, transações) são válidos para inclusão. Em segundo lugar, que quaisquer dados extrínsecos à sua candidato, como aquelas transações externas, tem disponibilidade suficientemente alta para que os participantes possam baixe-o e execute o bloco manualmente.5 Os validadores podem fornecer apenas um bloco “nulo” que não contém dados de “transações” externas, mas podem correr o risco de obter uma recompensa reduzida se o fizerem. Eles trabalham ao lado um protocolo de fofoca parachain com agrupadores - indivíduos que agrupam transações em blocos e fornecem uma prova não interativa e de conhecimento zero de que o bloco constitui um filho válido de seu pai (e aceitando qualquer transação taxas por seus problemas). Resta aos protocolos parachain especificar seus próprios meios de prevenção de spam: não existe uma noção fundamental de “medição de recursos computacionais” ou “taxa de transação” imposta pela cadeia de retransmissão. Também não há aplicação direta disso pelo protocolo de cadeia de retransmissão (embora é improvável que as partes interessadas optem por adotar um parachain que não fornecia um mecanismo decente). Este é um aceno explícito à possibilidade de cadeias diferentes Ethereum, por ex. uma cadeia semelhante a Bitcoin que tem um modelo de taxas muito mais simples ou algum outro modelo de prevenção de spam ainda a ser proposto. A própria cadeia de relés de Polkadot provavelmente existirá como um Contas e cadeia de estados semelhantes a Ethereum, possivelmente um derivado de EVM. Como os nós da cadeia de relés serão obrigados a fazer outros processamentos substanciais, taxa de transferência de transações será minimizado em parte através de grandes taxas de transação e, caso nossos modelos de pesquisa exijam, um limite de tamanho de bloco. 5.4. Comunicação Intercadeia. O ingrediente final crítico de Polkadot é a comunicação entre cadeias. Desde parachains podem ter algum tipo de canal de informação entre eles, nos permitimos considerar Polkadot um multi-cadeia escalável. No caso de Polkadot, a comunicação é tão simples quanto possível: transações executadas em um parachain são (de acordo com a lógica dessa cadeia) capazes de efetuar o envio de uma transação para um segundo parachain ou, potencialmente, a cadeia de retransmissão. Como transações externas na produção blockchains, eles são totalmente assíncronos e não há capacidade intrínseca para eles retornarem qualquer tipo de informação de volta à sua origem. Destino: recebe dados de anteriores validators do bloco. A conta recebe postagem: entrada removida de entrada Merkle tree A conta envia postagem: entrada colocada em saída Merkle tree para destino pára-quedas saída Fonte: ações dados com o próximo bloco validators comprovante postal armazenado em saída de pára-quedas Merkle árvore referência roteada colocada no parachain de destino entrada Merkle tree ingresso Figura 3. Um esquema básico mostrando as principais partes do roteamento para postagem transações (“postagens”). Para garantir complexidade mínima de implementação, risco e mínimo camisa de força de futuro arquiteturas parachain, essas transações interchain são efetivamente indistinguível de transações padrão assinadas externamente. A transação possui um segmento de origem, proporcionando a capacidade de identificar um parachain, e um endereço que pode ser de tamanho arbitrário. Ao contrário dos sistemas atuais comuns, como Bitcoin e Ethereum, as transações interchain não vêm com qualquer tipo de “pagamento” de taxa associada; qualquer pagamento desse tipo deve ser gerenciado por meio de lógica de negociação nos parachains de origem e destino. Um sistema como o proposto para O lançamento do Serenity de Ethereum [7] seria um meio simples de gerenciar esse pagamento de recursos entre cadeias, embora presumimos que outros poderão vir à tona no devido tempo. As transações entre cadeias são resolvidas usando um simples mecanismo de enfileiramento baseado em Merkle tree para garantir fidelidade. É tarefa dos mantenedores da cadeia de retransmissão mover transações na fila de saída de um parachain na fila de entrada do parachain de destino. O as transações passadas são referenciadas na cadeia de retransmissão, mas não são relevantesas próprias transações em cadeia. Para evitar que um parachain envie spam para outro parachain com transações, para que uma transação seja enviada, é necessário que a fila de entrada do destino não seja muito grande em a hora do final do bloco anterior. Se a entrada a fila for muito grande após o processamento do bloco, então ela será considerada “saturada” e nenhuma transação poderá ser roteada para dentro dos blocos subsequentes até ser reduzido abaixo do limite. Essas filas são administradas na cadeia de retransmissão permitindo que parachains determinem a saturação um do outro estado; desta forma, uma tentativa fracassada de postar uma transação para um destino paralisado pode ser relatado de forma síncrona. (Embora não exista nenhum caminho de retorno, se uma transação secundária falhar por esse motivo, ela não poderá ser relatada de volta para o chamador original e alguns outros meios de recuperação teria que acontecer.) 5.5. Polkadot e Ethereum. Devido à integridade de Turing de Ethereum, esperamos que haja ampla oportunidade para Polkadot e Ethereum serem interoperáveis com entre si, pelo menos dentro de alguns limites de segurança facilmente dedutíveis. Em suma, prevemos que as transações de Polkadot pode ser assinado por validators e depois inserido 5Tal tarefa pode ser compartilhada entre validators ou pode se tornar a tarefa designada de um conjunto de validators fortemente ligados, conhecido como fiadores de disponibilidade.
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 8 Ethereum onde podem ser interpretados e promulgados por um contrato de encaminhamento de transação. Na outra direção, prevemos o uso de logs (eventos) especialmente formatados provenientes de um “contrato break-out” para permitir uma verificação rápida de que uma determinada mensagem deve ser encaminhada. 5.5.1. Polkadot a Ethereum. Através da escolha de um BFT mecanismo de consenso com validators formado a partir de um conjunto de partes interessadas determinado através de uma votação de aprovação mecanismo, somos capazes de obter um consenso seguro com uma mudando com pouca frequência e número modesto de validators. Em um sistema com um total de 144 validators, um tempo de bloqueio de 4 segundos e uma finalidade de 900 blocos (permitindo ataques maliciosos). comportamento como votos duplos a serem relatados, punidos e reparado), a validade de um bloqueio pode ser razoavelmente considerado comprovado através de apenas 97 assinaturas (dois terços de 144 mais uma) e um período de verificação subsequente de 60 minutos onde nenhuma contestação é depositada. Ethereum é capaz de hospedar um “contrato de invasão” que pode manter os 144 signatários e ser controlado por eles. Como a recuperação da assinatura digital da curva elíptica (ECDSA) leva apenas 3.000 gás sob o EVM, e desde provavelmente só quereríamos que a validação acontecesse em um supermaioria de validators (em vez de unanimidade total), o custo base de Ethereum confirmando que uma instrução foi devidamente validado como proveniente da rede Polkadot não seria superior a 300.000 gás - apenas 6% do o limite total de gás do bloco em 5,5M. Aumentar o número de validators (conforme seria necessário para lidar com dezenas de redes) inevitavelmente aumenta esse custo, no entanto espera-se que a largura de banda de transação de Ethereum cresça ao longo do tempo à medida que a tecnologia amadurece e a infraestrutura melhora. Juntamente com o facto de não todos os validators precisam estar envolvidos (por exemplo, apenas os mais altos validators apostados podem ser chamados para tal tarefa) o os limites deste mecanismo se estendem razoavelmente bem. Supondo uma rotação diária de tais validators (que é bastante conservador (semanalmente ou mesmo mensalmente pode ser aceitável), então o custo para a rede de manutenção esta ponte de encaminhamento Ethereum seria em torno de 540.000 gás por dia ou, aos preços atuais do gás, US$ 45 por ano. Uma transação básica encaminhada sozinha pela ponte custaria cerca de US$ 0,11; o cálculo adicional do contrato custaria mais, é claro. Ao armazenar em buffer e agrupar transações juntos, os custos de autorização de arrombamento podem ser facilmente compartilhada, reduzindo substancialmente o custo por transação; se 20 transações foram necessárias antes do encaminhamento, então o custo do encaminhamento de uma transação básica cairia para cerca de US$ 0,01. Uma alternativa interessante e mais barata a este modelo de contrato com múltiplas assinaturas seria a utilização de assinaturas limiares, a fim de alcançar a semântica de propriedade multilateral. Embora os esquemas de assinatura de limite para ECDSA são computacionalmente caros, aqueles para outros esquemas como as assinaturas de Schnorr são muito razoáveis. Ethereum planeja introduzir primitivos que tornariam tal esquemas baratos para usar no próximo hardfork Metropolis. Se tal meio pudesse ser utilizado, os custos do gás para encaminhar uma transação Polkadot para o Ethereum rede seria drasticamente reduzida a quase zero despesas gerais além dos custos básicos para validação do assinatura e execução da transação subjacente. Neste modelo, os nós validator de Polkadot teriam fazer pouco além de assinar mensagens. Para que as transações sejam realmente roteadas para a rede Ethereum, nós suponha que os próprios validators também residiriam em a rede Ethereum ou, mais provavelmente, que pequenas recompensas ser oferecido ao primeiro ator que encaminha a mensagem para a rede (a recompensa poderia ser paga trivialmente ao originador da transação). 5.5.2. Ethereum a Polkadot. Fazer com que as transações sejam encaminhado de Ethereum para Polkadot usa a noção simples de logs. Quando um contrato Ethereum deseja despachar uma transação para um parachain específico de Polkadot, basta simplesmente celebrar um “contrato de rescisão” especial. O contrato de ruptura exigiria qualquer pagamento que pudesse ser exigido e emitir uma instrução de registro para que sua existência possa ser comprovada através de uma prova Merkle e uma afirmação de que o cabeçalho do bloco correspondente é válido e canônico. Das duas últimas condições, a validade é talvez a mais simples de provar. Em princípio, o único requisito épara cada nó Polkadot que precisa da prova (ou seja, nós validator designados) para executar uma instância totalmente sincronizada de um nó Ethereum padrão. Infelizmente, esta é em si uma dependência bastante pesada. Um mais método leve seria usar uma prova simples de que o cabeçalho foi avaliado corretamente fornecendo apenas o parte da tentativa de estado de Ethereum necessária para executar corretamente as transações do bloco e verificar se os logs (contidos no recibo do bloco) são válidos. Tal “tipo SPV”6 as provas podem ainda exigir uma quantidade substancial de informações; convenientemente, eles normalmente não seriam necessários em todos: um sistema de títulos dentro de Polkadot permitiria títulos terceiros enviem cabeçalhos sob o risco de perder seus título caso algum terceiro (como um “pescador”, ver 6.2.3) forneça uma prova de que o cabeçalho é inválido (especificamente que a raiz estatal ou as raízes receptoras eram impostoras). Em uma rede PoW não finalizada como Ethereum, o a canonicidade é impossível de ser provada de forma conclusiva. Para resolver isso, os aplicativos que tentam contar com qualquer tipo de causa-efeito dependente da cadeia, espere por uma série de “confirmações” ou até que a transação dependente esteja em algum momento. profundidade específica dentro da cadeia. Em Ethereum, este a profundidade varia de 1 bloco para as transações menos valiosas sem problemas de rede conhecidos até 1.200 blocos como era o caso durante o lançamento inicial do Frontier para trocas. Na rede estável “Homestead”, este número fica em 120 blocos para a maioria das exchanges, e provavelmente levaríamos um parâmetro semelhante. Então nós pode imagine nosso Lado Polkadot Ethereuminterface tenha algumas funções simples: poder aceitar um novo cabeçalho da rede Ethereum e validar o PoW, para poder aceitar alguma prova de que um log específico foi emitido pelo contrato de breakout do lado Ethereum para um cabeçalho de profundidade suficiente (e encaminhamento a mensagem correspondente dentro de Polkadot) e finalmente ser capaz de aceitar provas de que um documento anteriormente aceito, mas o cabeçalho ainda não promulgado contém uma raiz de recibo inválida. Para realmente obter os próprios dados do cabeçalho Ethereum (e quaisquer provas de SPV ou refutações de validade/canonicidade) em a rede Polkadot, um incentivo ao encaminhamento 6SPV refere-se à Verificação Simplificada de Pagamento em Bitcoin e descreve um método para os clientes verificarem transações, mantendo apenas uma cópia de todos os cabeçalhos de blocos da cadeia PoW mais longa.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 9 são necessários dados. Isso pode ser tão simples quanto um pagamento (financiado por taxas cobradas do lado Ethereum) pago para qualquer pessoa capaz de encaminhar um bloco útil cujo cabeçalho seja válido. Os validadores seriam chamados a reter informações relativas aos últimos milhares de blocos, a fim de ser capaz de gerenciar forks, seja através de algum meio protocolar intrínseco ou através de um contrato mantido no cadeia de relé. 5.6. Polkadot e Bitcoin. Bitcoin interoperação apresenta um desafio interessante para Polkadot: um chamado “ligação bidirecional” seria uma peça útil de infraestrutura ter do lado de ambas as redes. No entanto, devido as limitações de Bitcoin, fornecer tal pino com segurança é um empreendimento nada trivial. Entregando uma transação de Bitcoin a Polkadot pode, em princípio, ser feito com um processo semelhante ao de Ethereum; um “endereço de ruptura” controlado de alguma forma pelos Polkadot validators poderia receber tokens transferidos (e dados enviados junto com eles). As provas de SPV podem ser fornecidas por oracles incentivados e, juntamente com um período de confirmação, uma recompensa dada por identificação de blocos não canônicos que implicam a transação foi “gasto em dobro”. Quaisquer tokens de propriedade do O “endereço de fuga” seria então, em princípio, controlado por esses mesmos validators para dispersão posterior. O problema, entretanto, é como os depósitos podem ser controlados com segurança a partir de um conjunto rotativo validator. Ao contrário Ethereum que é capaz de tomar decisões arbitrárias com base mediante combinações de assinaturas, Bitcoin é substancialmente mais limitado, com a maioria dos clientes aceitando apenas transações com múltiplas assinaturas com no máximo 3 partes. Estender este número para 36, ou mesmo para milhares, como seria desejável, é impossível no âmbito do protocolo actual. Uma opção é alterar o protocolo Bitcoin para ativar tal funcionalidade, porém os chamados “hard forks” no Bitcoin mundo são difíceis de organizar a julgar pelas tentativas recentes. Uma possibilidade é o uso de assinaturas de limite, esquemas criptográficos para permitir um público unicamente identificável chave para ser efetivamente controlada por múltiplas “partes” secretas, alguns ou todos eles devem ser utilizados para criar uma assinatura válida. Infelizmente, assinaturas de limite compatíveis com ECDSA de Bitcoin são computacionalmente caros para criar e de complexidade polinomial. Outros esquemas como as assinaturas Schnorr oferecem custos muito mais baixos, no entanto, o cronograma em que eles podem ser introduzidos no Bitcoin protocolo é incerto. Dado que a segurança final dos depósitos cabe uma série de validators ligados, uma outra opção é reduzir os porta-chaves com múltiplas assinaturas a apenas um número fortemente subconjunto vinculado do total de validators tal que limite assinaturas tornam-se viáveis (ou, na pior das hipóteses, o nativo de Bitcoin multi-assinatura é possível). Isto naturalmente reduz o valor total de títulos que poderiam ser deduzidos em indenizações caso os validators se comportassem ilegalmente, no entanto, este é uma degradação graciosa, simplesmente estabelecendo um limite superior de a quantidade de fundos que pode circular com segurança entre o duas redes (ou mesmo, na% de perdas caso um ataque dos validators bem-sucedidos). Como tal, acreditamos que não é irrealista colocar um “parachain virtual” de interoperabilidade Bitcoin razoavelmente seguro entre as duas redes, embora ainda assim seja um esforço substancial com um cronograma incerto e muito possivelmente exigindo a cooperação das partes interessadas dentro desse rede.
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.
Protocolo em detalhes
O protocolo pode ser dividido em três partes: o mecanismo de consenso, a interface parachain e roteamento de transações entre cadeias. 6.1. Cadeia de relés Operação. O cadeia de relés vontade provavelmente será uma cadeia muito semelhante a Ethereum no sentido de que é baseado no estado com o endereço de mapeamento do estado para a conta informações, principalmente saldos e (para evitar replays) um contador de transações. Colocar contas aqui cumpre um propósito: fornecer contabilidade para a qual a identidade possui qual a quantidade de participação no sistema.7 No entanto, haverá diferenças notáveis: • Os contratos não podem ser implementados através de transações; seguindo o desejo de evitar a funcionalidade da aplicação na cadeia de relés, não será apoiar a implantação pública de contratos. • O uso de recursos computacionais (“gás”) não é contabilizado; já que as únicas funções disponíveis para uso público será corrigido, a lógica por trás da contabilidade do gás não se sustenta mais. Como tal, será aplicada uma taxa fixa em todos os casos, permitindo mais desempenho de qualquer execução dinâmica de código que pode precisar ser feita e um formato de transação mais simples. • Funcionalidade especial é suportada para contratos listados que permite execução automática e saída de mensagens de rede. Caso a cadeia de retransmissão tenha uma VM e seja baseado em EVM, teria uma série de modificações para garantir a máxima simplicidade. Provavelmente seria têm uma série de contratos integrados (semelhantes aos de endereços 1-4 em Ethereum) para permitir especificações específicas da plataforma deveres a serem gerenciados, incluindo um contrato de consenso, um validator contrato e um contrato parachain. Se não for o EVM, então um backend WebAssembly [2] (wasm) é a alternativa mais provável; neste caso o total estrutura seria semelhante, mas não haveria necessidade para os contratos integrados com Wasm sendo um alvo viável para linguagens de uso geral, em vez de imaturas e idiomas limitados para EVM. Outros desvios prováveis do atual protocolo Ethereum são bem possíveis, por exemplo, uma simplificação do formato de recebimento de transação que permite a execução paralela de transações não conflitantes dentro do mesmo bloco, conforme proposto para a série de mudanças Serenity. É possível, embora improvável, que uma situação semelhante à Serenidade cadeia “pura” seja implantada como cadeia de retransmissão, permitindo uma contrato específico para gerenciar coisas como staking token equilíbrio, em vez de fazer disso uma parte fundamental do o protocolo da cadeia. Actualmente, sentimos que é improvável que isso aconteça. oferecerá uma simplificação de protocolo suficientemente grande para ser vale a pena a complexidade adicional e a incerteza envolvidas em desenvolvê-lo. 7Como forma de representar o montante que um determinado titular é responsável pela segurança geral do sistema, estas contas de participação serão inevitavelmente codificam algum valor econômico. No entanto, deve ser entendido que, uma vez que não há intenção de que tais valores sejam utilizados em de qualquer forma, com a finalidade de troca por bens e serviços do mundo real, deve-se notar, portanto, que os tokens não devem ser comparados a moeda e, como tal, a cadeia de retransmissão mantém a sua filosofia niilista em relação às aplicações.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 10 Há uma série de pequenas funcionalidades necessárias para administrar o mecanismo de consenso, conjunto validator, mecanismo de validação e parachains. Estes poderiam ser implementados em conjunto sob um protocolo monolítico. No entanto, por razões de modularidade, descrevemos estes como “contratos” da cadeia de retransmissão. Isso deveria ser entendido como significando que eles são objetos (no sentido de programação orientada a objetos) gerenciada pelo mecanismo de consenso da cadeia de retransmissão, mas não necessariamente isso eles são definidos como programas em opcodes do tipo EVM, nem mesmo que sejam individualmente endereçáveis através do sistema de contas. 6.2. Contrato de piquetagem. Este contrato mantém o conjunto validator. Ele gerencia: • quais contas são atualmente validators; • que estão disponíveis para se tornarem validators em breve aviso prévio; • quais contas colocaram indicação de aposta para um validator; • propriedades de cada um, incluindo volume staking, taxas de pagamento e endereços aceitáveis e identidades de curto prazo (sessão). Ele permite que uma conta registre o desejo de se tornar um validator vinculados (junto com seus requisitos), para nomear alguma identidade, e para validators vinculados pré-existentes registrar seu desejo de sair desse status. Também inclui o próprio mecanismo de validação e canonização. 6.2.1. Participação-token Liquidez. Geralmente é desejável ter o máximo possível do total de staking tokens para ser apostado nas operações de manutenção da rede desde isso vincula diretamente a segurança da rede à “capitalização de mercado” geral de staking token. Isto pode facilmente ser incentivado através da inflação da moeda e da distribuição dos rendimentos para aqueles que participam como validators. No entanto, fazer isso apresenta um problema: se o token está bloqueado no Contrato de Stake sob pena de redução, como pode uma parte substancial permanecer suficientemente líquido para permitir a descoberta de preços? Uma resposta para isso é permitir um contrato de derivativo direto, garantindo tokens fungíveis em um token apostado subjacente. Isso é difícil de organizar de maneira livre de confiança. Além disso, estes derivados tokens não podem ser tratados de forma igual pela mesma razão que diferentes obrigações governamentais da zona euro não são fungíveis: há é uma chance de o ativo subjacente falhar e se tornar inútil. Com os governos da zona euro, poderia haver uma padrão. Com validator com tokens apostados, o validator pode agir maliciosamente e ser punido. Mantendo nossos princípios, optamos pela solução mais simples: nem todos os tokens podem ser apostados. Isso significaria que alguma proporção (talvez 20%) de tokens permanecerá forçosamente líquida. Embora isto seja imperfeito do ponto de vista da segurança, é pouco provável que faça uma diferença fundamental na a segurança da rede; 80% das reparações possíveis decorrentes do confisco de títulos ainda poderiam ser feitas em comparação com o “caso perfeito” de 100% staking. A proporção entre tokens apostados e líquidos pode ser alcançada de forma bastante simples por meio de um mecanismo de leilão reverso. Essencialmente, titulares de token interessados em ser validator cada um postaria uma oferta para o contrato staking declarando a taxa de pagamento mínima que eles exigiriam para assumir parte. No início de cada sessão (as sessões seriam acontecem regularmente, talvez até uma vez por hora) o validator as vagas seriam preenchidas de acordo com cada pretenso Aposta e taxa de pagamento de validator. Um algoritmo possível pois isso seria aceitar aqueles com as ofertas mais baixas que representam uma aposta não superior à aposta total visada dividido pelo número de slots e não inferior a um limite inferior de metade desse valor. Se as vagas não puderem ser preenchidas, o limite inferior pode ser repetidamente reduzido por algum fator para ser satisfeito. 6.2.2. Nomeando. É possível nomear sem confiança uns staking tokens para um validator ativo, dando-lhes a responsabilidade dos deveres de validator. Nomeando trabalhos através de um sistema de votação de aprovação. Cada candidato a nomeador pode postar uma instrução no contrato staking expressando uma ou mais identidades validator sob cujas responsabilidade que estão preparados para confiar seu vínculo. A cada sessão, os títulos dos nominadores são dispersos para serem representado por um ou mais validators. O algoritmo de dispersão otimiza para um conjunto de validators de total equivalente títulos. Os títulos dos nominadores passam a ser de responsabilidade efetiva do validator ae ganhar interesse ou sofrer um redução da punição em conformidade. 6.2.3. Confisco/queima de títulos. Certo comportamento de validator resulta em uma redução punitiva de seu vínculo. Se o título for reduzido abaixo do mínimo permitido, o sessão é encerrada prematuramente e outra iniciada. Uma lista não exaustiva de mau comportamento validator punível inclui: • Fazer parte de um grupo de pára-quedas incapaz de fornecer consenso sobre a validade de um bloco parachain; • assinar ativamente a validade de um documento inválido bloco de pára-quedas; • incapacidade de fornecer cargas úteis de saída anteriormente votado como disponível; • inatividade durante o processo de consenso; • validação de blocos de cadeia de retransmissão em bifurcações concorrentes. Alguns casos de mau comportamento ameaçam a integridade da rede (como a assinatura de blocos de parachain inválidos e a validação de vários lados de uma bifurcação) e, como tal, resultam num exílio efetivo através da redução total do vínculo. Em outros casos menos graves (por exemplo, inatividade no consenso processo) ou casos em que a culpa não pode ser atribuída com precisão (fazer parte de um grupo ineficaz), uma pequena parte do título pode, em vez disso, ser multado. Neste último caso, este funciona bem com a rotatividade de subgrupos para garantir que os nodos sofrem substancialmente mais perdas do que os nodos benevolentes danificados colateralmente. Em alguns casos (por exemplo, validação multi-fork e inválida assinatura de sub-bloco) validators não conseguem detectar facilmente o mau comportamento uns dos outros, pois a verificação constante de cada bloco de parachain seria uma tarefa muito árdua. Aqui é necessário angariar o apoio de partes externas ao o processo de validação para verificar e relatar tal mau comportamento. As partes recebem uma recompensa por denunciar tal atividade; seu termo, “pescadores”, deriva da improbabilidade de tal recompensa. Dado que estes casos são tipicamente muito graves, prevemos que quaisquer recompensas possam ser facilmente pagas a partir do título confiscado. Em geral preferimos equilibrar a queima (ou seja, redução a nada) com realocação, em vez de tentativa de realocação por atacado. Isto tem o efeito de
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 11 aumentando o valor global do token, compensando o até certo ponto, a rede em geral, e não a rede específica. parte envolvida na descoberta. Isto é principalmente como uma segurança mecanismo: as grandes quantias envolvidas poderiam levar a um incentivo extremo e agudo ao comportamento, se todas elas concedido a um único alvo. Em geral, é importante que a recompensa seja suficientemente grande para fazer com que a verificação valha a pena para a rede, mas não tão grande a ponto de compensar os custos de enfrentar um problema. crime de “nível industrial” bem financiado e bem orquestrado ataque de hacking a algum validator azarado para forçar o mau comportamento. Desta forma, o montante reclamado geralmente não deve ser maior que o vínculo direto do errante validator, para que um surgem incentivos perversos de se comportar mal e se reportar à recompensa. Isto pode ser combatido explicitamente através de um requisito mínimo de títulos diretos para ser um validator ou implicitamente, educando os nomeadores que validators com poucos títulos depositados não têm grande incentivo comportar-se bem. 6.3. Registro Parachain. Cada parachain é definido em este registro. É uma construção relativamente simples, semelhante a um banco de dados, e contém informações estáticas e dinâmicas sobre cada cadeia. As informações estáticas incluem o índice da cadeia (um simples inteiro), junto com a identidade do protocolo de validação, um meio de distinguir entre as diferentes classes de parachain para que o algoritmo de validação correto possa ser dirigido por validators encarregados de apresentar um candidato válido. Uma prova de conceito inicial se concentraria em colocar os novos algoritmos de validação nos próprios clientes, exigindo efetivamente um hard fork do protocolo cada vez que um classe adicional de corrente foi adicionada. Em última análise, porém, pode ser possível especificar o algoritmo de validação em de uma forma rigorosa e eficiente o suficiente para que os clientes sejam capaz de trabalhar efetivamente com novos pára-quedas sem garfo duro. Um caminho possível para isso seria especificar o algoritmo de validação parachain de uma forma bem estabelecida, linguagem compilada nativamente e de plataforma neutra, como WebAssembly. Pesquisas adicionais são necessárias para determinar se isso é realmente viável, no entanto, se for, poderia trazer com isso a tremenda vantagem de banir hard-forks para sempre. As informações dinâmicas incluem aspectos do sistema de roteamento de transações que devem ter um acordo global, como como a fila de entrada do parachain (descrita na seção 6.6). O registro só pode adicionar parachains através de votação em referendo completo; isso poderia ser gerenciado internamente, mas seria mais provável que fosse colocado em um ambiente externo contrato de referendo, a fim de facilitar a reutilização sob componentes de governação mais gerais. Os parâmetros a requisitos de votação (por exemplo, qualquer quórum necessário, maioria obrigatório) para registro de cadeias adicionais e outros, atualizações de sistema menos formais serão definidas em um “mestre constituição”, mas provavelmente seguirão uma abordagem bastante tradicional caminho, pelo menos inicialmente. A formulação precisa está fora de escopo para o presente trabalho, mas, e. uma maioria absoluta de dois terços para aprovar com mais de um terço do sistema total votar positivamente pode ser um ponto de partida sensato. As operações adicionais incluem a suspensão e remoção de pára-quedas. Esperançosamente, a suspensão nunca acontecer, no entanto, foi concebido para ser uma salvaguarda menos há algum problema intratável no sistema de validação de um parachain. O exemplo mais óbvio em que poderia necessária é uma diferença crítica de consenso entre as implementações, levando validators a não conseguirem chegar a um acordo sobre validade ou bloqueios. Os validadores seriam incentivados a usar múltiplas implementações de clientes para que eles possam identificar esse problema antes do confisco dos títulos. Sendo a suspensão uma medida emergencial, seria sob os auspícios da votação dinâmica validator, em vez do que um referendo. A reintegração seria possível tanto dos validators ou de um referendo. A remoção total dos pára-quedas viria apenas após um referendo e com o qual seria necessária uma período de carência substancial para permitir uma transição ordenada para uma cadeia independente ou para se tornar parte de alguma outra sistema de consenso. O período de carência provavelmente seria de na ordem de meses e provavelmente será estabelecido por cadeia no registro de parachain para que diferentes parachains podem desfrutar de diferentes períodos de carência de acordo com sua necessidade. 6.4. Vedação de blocos de relés. Vedação refere-se, em essência, ao processo de canonização; isto é, um dado básico transformar o quemapeia o original em algo fundamentalmente singular e significativo. Sob uma cadeia PoW, vedação é efetivamente sinônimo de mineração. No nosso caso, envolve a coleta de declarações assinadas de validators sobre a validade, disponibilidade e canonicidade de um bloco específico da cadeia de retransmissão e os blocos parachain que ele representa. A mecânica do algoritmo de consenso BFT subjacente está fora do escopo do presente trabalho. Nós iremos em vez disso, descreva-o usando uma primitiva que assume um máquina de estado criadora de consenso. Em última análise, esperamos ser inspirado por uma série de consensos BFT promissores algoritmos no núcleo; Tangaora [9] (uma variante BFT de Jangada [16]), Tendermint [11] e HoneyBadgerBFT [14]. O algoritmo terá que chegar a um acordo sobre múltiplos parachains em paralelo, diferindo assim do habitual blockchain mecanismos de consenso. Assumimos que uma vez o consenso é alcançado, somos capazes de registrar o consenso numa prova irrefutável que pode ser fornecida por qualquer um dos os participantes a ele. Também assumimos que o mau comportamento dentro do protocolo pode ser geralmente reduzido a um pequeno grupo contendo participantes malcomportados para minimizar o dano colateral ao aplicar a punição.8 A prova, que assume a forma de nossas declarações assinadas, é colocada no cabeçalho do bloco da cadeia de retransmissão junto com com alguns outros campos, entre eles a raiz da tentativa de estado da cadeia de retransmissão e a raiz da tentativa de transação. O vedação processo leva lugar sob um solteiro gerador de consenso mecanismo endereçamento ambos o bloco da cadeia de relés e os blocos dos parachains que fazem parte do conteúdo do revezamento: os parachains não são “comprometidos” separadamente por seus subgrupos e depois agrupados mais tarde. Isso resulta em um processo mais complexo para a cadeia de retransmissão, mas nos permite completar todo o consenso do sistema em um único estágio, minimizando a latência e permitindo para requisitos de disponibilidade de dados bastante complexos que são útil para o processo de roteamento abaixo. 8Os esquemas de consenso BFT existentes baseados em PoS, como o Tendermint BFT e o Slasher original, atendem a essas afirmações.
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 12 O estado da máquina de consenso de cada participante pode ser modelado como uma tabela simples (bidimensional). Cada participante (validator) possui um conjunto de informações, no formato de declarações assinadas (“votos”) de outros participantes, em relação a cada candidato de bloco parachain, bem como ao candidato de bloco de retransmissão. O conjunto de informações é composto por duas peças de dados: Disponibilidade: faz isso validator tem saída informações de postagem de transação deste bloco, então eles são capazes de validar adequadamente os candidatos parachain no bloco seguinte? Eles podem votar 1 (conhecido) ou 0 (ainda não conhecido). Uma vez que eles voto 1, eles se comprometem a votar de forma semelhante para o resto deste processo. Votos posteriores que não respeitar isso são motivos para punição. Validade: o bloco parachain é válido e é tudo dados referenciados externamente (por ex. transações) disponível? Isso é relevante apenas para validators atribuídos ao parachain no qual estão votando. Eles podem votar 1 (válido), -1 (inválido) ou 0 (ainda não conhecido). Uma vez que votam diferente de zero, eles estão empenhados em votar desta forma durante o resto do o processo. Votos posteriores que não respeitam isso são motivo de punição. Todos os validators devem enviar votos; poderão ser reapresentados votos, qualificados pelas regras acima. A progressão de o consenso pode ser modelado como vários algoritmos de consenso BFT padrão sobre cada parachain acontecendo em paralelo. Uma vez que estas são potencialmente frustradas por uma situação relativamente pequena minoria de atores maliciosos concentrados em um único grupo parachain, existe um consenso geral para estabelecer um mecanismo de apoio, limitando o pior cenário possível impasse para apenas um ou mais blocos de parachain vazios (e uma rodada de punição para os responsáveis). As regras básicas para validade dos blocos individuais (que permitem que o conjunto total de validators como um todo chegue a consenso sobre ele se tornar o único candidato parachain a ser referenciado a partir do relé canônico): • deve ter pelo menos dois terços dos seus validators votando positivamente e nenhum votando negativamente; • deve ter mais de um terço dos validators votando positivamente quanto à disponibilidade de informações da fila de saída. Se houver pelo menos um voto positivo e pelo menos um negativo sobre a validade, é criada uma condição excepcional e todo o conjunto de validators deve votar para determinar se houver partes maliciosas ou se houver um acidente garfo. Além de válidos e inválidos, um terceiro tipo de votos são permitidos, equivalente a votar em ambos, o que significa que o nó tem opiniões conflitantes. Isto pode ser devido ao proprietário do nó executando múltiplas implementações que fazem discordo, indicando uma possível ambiguidade no protocolo. Depois que todos os votos forem contados do conjunto completo validator, se a opinião perdedora tem pelo menos uma pequena proporção (para ser parametrizado; no máximo metade, talvez significativamente menos) dos votos do parecer vencedor, presume-se então será um fork acidental do parachain e o parachain será automaticamente suspenso do processo de consenso. Caso contrário, assumimos que é um ato malicioso e punimos o minoria que votou a favor da opinião divergente. A conclusão é um conjunto de assinaturas demonstrando canonicidade. O bloco da cadeia de relés pode então ser selado e iniciado o processo de selagem do próximo bloco. 6.5. Melhorias para blocos de relé de vedação. Enquanto este método de vedação oferece fortes garantias sobre a operação do sistema, não tem uma escalabilidade particularmente boa uma vez que as principais informações de cada parachain devem ter seu disponibilidade garantida por mais de um terço de todos os validators. Isso significa que a pegada de responsabilidade de cada validator cresce à medida que mais cadeias são adicionadas. Embora a disponibilidade de dados em redes abertas de consenso é essencialmente um problema não resolvido, existem maneiras de mitigar a sobrecarga colocada nos nós validator. Um simples solução é perceber que embora validators devam assumir assumem a responsabilidade pela disponibilidade dos dados, eles próprios não precisam de armazenar, comunicar ou replicar os dados. Silos de dados secundários, possivelmente relacionados (ou mesmo com o próprio mesmo) os compiladores que compilam esses dados, podem gerenciar o tarefa de garantir a disponibilidade com os validators fornecendo uma parcela de seus juros/receitas em pagamento. No entanto, embora isso possa adquirir alguma escalabilidade intermediária, ainda não ajuda no problema subjacente; desde adicionar mais cadeias geralmente exigirá validators adicionais, o consumo contínuo de recursos de rede (particularmente em termos de largura de banda) cresce com o quadrado de ocorrentes, uma propriedade insustentável a longo prazo. Em última análise, é provável que continuemos a bater a cabeça contra a limitação fundamental que afirma que, para uma rede de consenso para ser considerada disponível como segura, o os requisitos contínuos de largura de banda são da ordem do total validators vezes o total de informações de entrada. Isto é devido a a incapacidade de uma rede não confiável de distribuir adequadamente a tarefa de armazenamento de dados entre muitos nós, que fica além da tarefa eminentemente distribuível de processamento. 6.5.1. Apresentando Latência. Um meio de suavizar isso A regra é relaxar a noção de imediatismo. Ao exigir que 33%+1 validators votem pela disponibilidade apenas eventualmente, e não imediatamente, podemos utilizar melhor a propagação exponencial de dados e ajudar a equilibrar os picos no intercâmbio de dados. Uma igualdade razoável (embora não comprovada) pode ser: (1) latência = participantes × cadeias No modelo atual, o tamanho do sistema aumenta com o número de cadeias para garantir que o processamento seja distribuído; já que cada cadeia exigirá pelo menos um validator e fixamos o atestado de disponibilidade para uma constante proporção de validators, então os participantes crescem de forma semelhante com o número de cadeias. Terminamos com: (2) latência = tamanho2 O que significa que à medida que o sistema cresce, a largura de banda necessária e a latência até que a disponibilidade seja conhecida em todo o rede, que também pode ser caracterizada como o número de blocos antes da finalidade, aumenta com seu quadrado. Isto é um factor de crescimento substancial e pode revelar-se um obstáculo notável e forçar-nos a paradigmas “não planos” como compor vários “Polkadotes” em uma hierarquia para roteamento multinível de postagens por meio de uma árvore de cadeias de retransmissão.
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 13 6.5.2. Participação Pública. Mais uma direção possível é conseguir a participação pública no processo através de uma sistema de micro-reclamações. Semelhante aos pescadores, há poderiam ser partes externas para policiar os validators que reivindicam disponibilidade. A sua tarefa é encontrar alguém que pareça incapaz de demonstrar tal disponibilidade. Ao fazer isso eles pode apresentar uma micro-reclamação a outros validators. PoW ou um título apostado pode ser usado para mitigar o ataque de sibila o que tornaria o sistema em grande parte inútil. 6.5.3. Fiadores de Disponibilidade. Um caminho final seria nomear um segundo conjunto de validators vinculados como “disponibilidade fiadores”. Eles seriam ligados da mesma forma que os validators normais e podem até ser retirados do mesmo conjunto (embora, nesse caso, seriam escolhidos durante um período de longo prazo, pelo menos por sessão). Ao contrário dos validators normais, eles não mudaria entre parachains, mas sim formar um único grupo para atestar a disponibilidade de todos os dados intercadeias importantes. Isto tem a vantagem de relaxar a equivalência entre participantes e cadeias. Essencialmente, as cadeias podem crescer (junto com o conjunto original da cadeia validator), enquanto os participantes, e especificamente aqueles que participam do testamento de disponibilidade de dados, podem permanecer pelo menos sublineares e possivelmente constante. 6.5.4. Preferências do agrupador. Um aspecto importante deste sistema é garantir que haja uma seleção saudável de agrupadores criando os blocos em qualquer parachain. Se um único agrupador dominou um parachain e depois alguns ataques tornar-se mais viável, uma vez que a probabilidade da falta de a disponibilidade de dados externos seria menos óbvia. Uma opção é pesar artificialmente blocos de parachain em um mecanismo pseudo-aleatório para favorecer uma ampla variedade de agrupadores. No primeiro caso, precisaríamos como parte do mecanismo de consenso que validators favorece candidatos do bloco parachain determinados como “mais pesados”. Da mesma forma, devemos incentivar validators a tentar sugerir o bloco mais pesado que puderem encontrar - isso pode ser feito através de uma parcela de sua recompensa proporcional ao peso de seu candidato. Para garantir que os agrupadores recebam uma avaliação justa e razoável chance de seu candidato ser escolhido como vencedor candidato em consenso, fazemos o peso específico de um candidato de bloco parachain determinado em uma função aleatória conectada a cada agrupador. Por exemplo, tomando a medida da distância XOR entre o endereço do ordenador e algum número pseudoaleatório criptograficamente seguro determinado próximo ao ponto do bloco que está sendo criado (um “bilhete vencedor” nocional). Isso efetivamente dá a cada agrupador (ou, mais especificamente, o endereço de cada agrupador) um chance aleatória de seu bloco candidato “ganhar” todos os outros. Para mitigar o ataque sybil de um único agrupador “minerando” um endereço próximo ao bilhete vencedor e assim sendo um favorito em cada bloco, adicionaríamos alguma inércia ao endereço de um agrupador. Isso pode ser tão simples quanto exigir que eles ter uma quantia básica de fundos no endereço. Um mais abordagem elegante seria ponderar a proximidade com o bilhete vencedor com o valor dos fundos estacionados no endereço em questão. Embora a modelagem ainda não tenha sido feita, é bem possível que este mecanismo permita até mesmo pequenas partes interessadas contribuam como compiladores. 6.5.5. Blocos de excesso de peso. Se um conjunto validator for comprometido, eles podem criar e propor um bloco que, embora válido, leva uma quantidade excessiva de tempo para ser executado e validar. Isto é um problema já que um grupo validator poderia razoavelmente formar um bloco que leva muito tempo para executar, a menos que alguma informação específica já seja conhecida, permitindo um atalho, por ex. fatorando um grande principal. Se um único compilador conhecesse essa informação, então eles teriam uma clara vantagem em obter o seu próprio os candidatos aceitaram desde que os demais estivessem ocupados processando o bloco antigo. Chamamos esses blocos de excesso de peso. A proteção contra o envio e validação desses blocos por validators cai em grande parte sob o mesmo disfarce que para blocos inválidos, embora com uma ressalva adicional: já que o tempo necessário para executar um bloco (e, portanto, seu status como excesso de peso) é subjetivo, o resultado final de uma votação sobre o mau comportamento cairá essencialmente em três campos. Um possibilidade é que o bloco definitivamente não esteja acima do peso - neste caso, mais de dois terços declaram que poderiam execute o bloco dentro de algum limite (por exemplo, 50% do tempo total permitido entre blocos). Outra é que o bloco é ddefinitivamente acima do peso - isso aconteceria se mais de dois terços declaram que não conseguiram executar o bloco dentro do referido limite. Uma última possibilidade é uma situação razoavelmente igual divisão de opinião entre validators. Neste caso, podemos escolha fazer alguma punição proporcional. Para garantir que validators possam prever quando poderão ser propondo um bloco com excesso de peso, poderá ser sensato exigir-lhes que publiquem informações sobre o seu próprio desempenho para cada bloco. Durante um período de tempo suficiente, isso deve permitir que eles avaliem sua velocidade de processamento em relação aos pares que os julgariam. 6.5.6. Seguro de Colador. Um problema permanece para validators: ao contrário das redes PoW, para verificar o bloco para validade, eles devem realmente executar as transações nele. Coletores maliciosos podem alimentar blocos inválidos ou com excesso de peso para validators, causando-lhes sofrimento (desperdiçando seus recursos) e cobrando um custo de oportunidade potencialmente substancial. Para mitigar esta situação, propomos uma estratégia simples sobre o parte de validators. Em primeiro lugar, os candidatos ao bloco parachain foram enviados para validators devem ser assinados a partir de uma conta de cadeia de retransmissão com fundos; se não estiverem, então o validator deve cair isso imediatamente. Em segundo lugar, esses candidatos devem ser ordenados em prioridade por uma combinação (por exemplo, multiplicação) de a quantidade de fundos na conta até certo limite, o número de blocos anteriores que o ordenador propôs com sucesso no passado (sem mencionar qualquer bloco anterior punições), e o fator de proximidade com o vencedor bilhete conforme discutido anteriormente. A tampa deve ser a mesma como os danos punitivos pagos ao validator no caso deles enviando um bloco inválido. Para desincentivar os agrupadores de enviar candidatos de bloco inválidos ou com excesso de peso para validators, qualquer validator pode colocar no próximo bloco uma transação incluindo o bloco infrator, alegando mau comportamento com o efeito de transferir alguns ou todos os fundos na conta do ordenador que se comportou mal. conta ao lesado validator. Este tipo de transação antecipa qualquer outra para garantir que o ordenador não possa remover os fundos antes da punição. A quantidade de fundos transferidos como indenização é um parâmetro dinâmico ainda
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 14 a ser modelado, mas provavelmente será uma proporção da recompensa do bloco validator para refletir o nível de sofrimento causado. Para evitar que validators maliciosos confisquem arbitrariamente os fundos dos agrupadores, o agrupador poderá apelar da decisão do validator com um júri de validators escolhidos aleatoriamente em troca para fazer um pequeno depósito. Se eles acharem a favor de validator, o depósito será consumido por eles. Se não, o o depósito é devolvido e o validator é multado (já que o validator estiver em uma posição muito mais abobadada, a multa será provavelmente será bastante pesado). 6.6. Intercadeia Transação Roteamento. Intercadeia o roteamento de transações é uma das manutenções essenciais tarefas da cadeia de relés e seus validators. Este é o lógica que governa como uma transação lançada (muitas vezes abreviada para simplesmente “post”) deixa de ser uma saída desejada de um parachain de origem para ser uma entrada não negociável de outro parachain de destino sem qualquer confiança requisitos. Escolhemos cuidadosamente o texto acima; notavelmente nós não exige que tenha havido uma transação na origem parachain por ter sancionado explicitamente esta postagem. O único restrições que colocamos em nosso modelo é que parachains devem fornecer, embalados como parte de seu bloco geral saída de processamento, as postagens que são o resultado do execução do bloco. Essas postagens são estruturadas como diversas filas FIFO; o número de listas é conhecido como base de roteamento e pode ser cerca de 16. Notavelmente, este número representa a quantidade de pára-quedas que podemos apoiar sem ter que recorrer a roteamento multifásico. Inicialmente, Polkadot apoiará isso tipo de roteamento direto, no entanto, descreveremos um possível processo de roteamento multifásico (“hiper-roteamento”) como meio de expandir muito além do conjunto inicial de parachains. Nós assumir isso tudo participantes sabe o subgrupos para os próximos dois blocos n, n + 1. Em resumo, o O sistema de roteamento segue estas etapas: • CollatorS: entre em contato com membros dos Validadores[n][S] • Agrupadores: PARA CADA subgrupo: garantir pelo menos pelo menos 1 membro dos validadores[n][s] em contato • Coletores: PARA CADA subgrupo: assumir egress[n −1][s][S] está disponível (todas as postagens recebidas dados para 'S' do último bloco) • Coletores: Componha o bloco candidato b para S: (b.cabeçalho, b.ext, b.prova, b.recibo, b.egress) • Coletores: Enviar prova informação prova[S] = (b.cabeçalho, b.ext, b.prova, b.recibo) para Validadores[n][S] • CollatorS: Garante dados de transações externas b.ext é disponibilizado para outros agrupadores e validators • Coletores: PARA CADA subgrupo é: Enviar saída informação saída[n][S][s] = (b.cabeçalho, b.recibo, b.egress[s]) para o recebendo subgrupo membros de próximo bloquear Validadores[n + 1][s] • ValidadorV: pré-conecta todos os membros do mesmo conjunto para o próximo bloco: seja N = Chain[n + 1][V ]; conectar todos os validators v tais que Chain[n + 1][v] = N • ValidadorV: Agrupe toda a entrada de dados para isso bloco: PARA CADA subgrupo é: Recuperar egress[n −1][s][Chain[n][V ]], obtém de outros validators v tal que Chain[n][v] = Chain[n][V ]. Possivelmente passando por outros validators selecionados aleatoriamente para prova de tentativa. • ValidadorV: Aceite provas de candidato para isso prova de bloco[Cadeia[n][V]]. Validade do bloco de votação • ValidadorV: Aceitar dados de saída de candidatos para próximo bloco: PARA CADA subgrupo s, aceite saída[n][s][N]. Disponibilidade de saída do bloco de votação; republicar entre validators interessados v de forma que Cadeia[n + 1][v] = Cadeia[n + 1][V ]. • ValidadorV: ATÉ CONSENSO Onde: egress[n][from][to] é a fila de saída atual informações para postagens que vão do parachain ‘de’, para parachain ‘to’ no número do bloco ‘n’. CollatorS é um agrupador para parachain S. V alidators[n][s] é o conjunto de validators para parachain s no bloco número n. Por outro lado, Chain[n][v] é o parachain ao qual validator v é atribuído no bloco número n. block.egress[to] é a saída fila de postagens de algum bloco parachain cujo parachain de destino é. Como os agrupadores cobram taxas (de transação) com base em seus blocos se tornando canônicos, eles são incentivados a garantir que, para cada destino do próximo bloco, o subgrupo os membros são informados da fila de saída do presente bloco. Os validadores são incentivados apenas a formar um consenso sobre um bloco (parachain), portanto, eles pouco se importam com qual bloco do ordenador finalmente se torna canônico. Em princípio, um validator poderia formar uma aliança com um agrupador e conspirar para reduzir as chances de outros agrupadores bloqueia se tornar canônico, no entanto, isso é difícil para organizar devido à seleção aleatóriaação de validators para parachains e poderia ser defendido com uma redução nas taxas a pagar por blocos de parachain que resistem o processo de consenso. 6.6.1. Disponibilidade de dados externos. Garantindo um paraquedas dados externos estão realmente disponíveis é um problema perene com sistemas descentralizados com o objetivo de distribuir a carga de trabalho entre a rede. No centro da questão está a disponibilidade problema que afirma que, como não é possível fazer uma prova de disponibilidade não interativa nem qualquer tipo de prova de indisponibilidade, para que um sistema BFT funcione adequadamente validar qualquer transição cuja correção dependa do disponibilidade de alguns dados externos, o número máximo de nós aceitavelmente bizantinos, mais um, do sistema deve atestar que os dados estão disponíveis. Para que um sistema seja dimensionado corretamente, como Polkadot, isso convida a um problema: se uma proporção constante de validators deve atestar a disponibilidade dos dados, e assumindo que validators desejarão realmente armazenar os dados antes de afirmar que estão disponíveis, então como podemos evitar o problema dos requisitos de largura de banda/armazenamento aumentando com o tamanho do sistema (e, portanto, o número de validators)? Uma resposta possível seria ter um conjunto separado de validators (garantidores de disponibilidade), cujo pedido cresce sublinearmente com o tamanho de Polkadot como um todo. Isto é descrito em 6.5.3. Também temos um truque secundário. Como grupo, os agrupadores têm um incentivo intrínseco para garantir que todos os dados sejam disponível para o parachain escolhido, pois sem ele eles não são capazes de criar mais blocos a partir dos quais possam cobrar taxas de transação. Os agrupadores também formam um grupo cuja composição é variada (devido à natureza aleatória do parachain validator grupos) não trivial de entrar e fácil
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 15 para provar. Os agrupadores recentes (talvez dos últimos milhares de blocos) estão, portanto, autorizados a emitir desafios para a disponibilidade de dados externos para um determinado parachain bloco para validators para um pequeno título. Os validadores devem entrar em contato com aqueles do subgrupo aparentemente infrator validator que testemunharam e adquirir e devolver os dados ao compilador ou escalar o questão, testemunhando a falta de disponibilidade (a recusa direta em fornecer os dados conta como um crime de confisco de títulos, portanto, o mau comportamento validator provavelmente apenas interromper a conexão) e entrar em contato com validators adicionais para executar o mesmo teste. Neste último caso, a caução do colator é retornado. Assim que for alcançado um quórum de validators que possam fazer tais depoimentos de indisponibilidade, eles serão liberados, o o subgrupo que se comporta mal é punido e o bloqueio é revertido. 6.6.2. Roteamento de postagens. Cada cabeçalho parachain inclui um saída-trie-root; esta é a raiz de uma tentativa contendo o compartimentos de base de roteamento, sendo cada compartimento uma lista concatenada de postos de saída. As provas Merkle podem ser fornecidas em parachain validators para provar que um determinado parachain O bloco tinha uma fila de saída específica para um parachain de destino específico. No início do processamento de um bloco parachain, cada a fila de saída de outro parachain com destino ao referido bloco é mesclado na fila de entrada do nosso bloco. Assumimos forte, provavelmente CSPR9, ordenação de subbloco para alcançar uma operação determinística que não oferece favoritismo entre quaisquer emparelhamento de blocos parachain. Os agrupadores calculam a nova fila e drenar as filas de saída de acordo com o parachain lógica. O conteúdo da fila de entrada é escrito explicitamente no bloco de pára-quedas. Isto tem dois propósitos principais: em primeiro lugar, significa que o parachain pode ser sincronizado sem confiança, isoladamente dos outros parachains. Em segundo lugar, simplifica a logística de dados caso todo o ingresso a fila não pode ser processada em um único bloco; validators e agrupadores são capazes de processar os seguintes blocos sem ter que obter os dados da fila especialmente. Se a fila de entrada do parachain estiver acima de um limite valor no final do processamento do bloco, então ele é marcado saturado na cadeia de retransmissão e nenhuma mensagem adicional pode ser entregue a ele até que seja liberado. As provas de Merkle são usado para demonstrar a fidelidade da operação do alceador em a prova do bloco parachain. 6.6.3. Crítica. Uma pequena falha relacionada a este mecanismo é o ataque pós-bomba. É aqui que todos parachains enviam o máximo de posts possíveis para um parachain específico. Embora isso amarre o alvo fila de entrada de uma só vez, nenhum dano é causado além um ataque DoS de transação padrão. Operando normalmente, com um conjunto de sinais bem sincronizados e agrupadores não maliciosos e validators, para N parachains, N × M total de validators e L agrupadores por parachain, nós pode dividir o total de caminhos de dados por bloco para: Validador: M −1+L+L: M −1 para os outros validators no conjunto de parachain, L para cada ordenador fornecendo um bloco de parachain candidato e um segundo L para cada ordenador do próximo bloco exigindo as cargas de saída do bloco anterior. (Este último é na verdade mais parecido com o pior caso operação, uma vez que é provável que os agrupadores compartilhem tais dados.) Collator: M +kN: M para uma conexão com cada bloco parachain validator, kN para semear as cargas úteis de saída para algum subconjunto de cada grupo parachain validator para o próximo bloco (e possivelmente algum(s) agrupador(es) preferido(s)). Como tal, os caminhos dos dados por nó crescem linearmente com a complexidade geral do sistema. Enquanto isso é razoável, à medida que o sistema se expande para centenas ou milhares de parachains, alguma latência de comunicação pode ser absorvido em troca de uma taxa de crescimento de menor complexidade. Neste caso, um algoritmo de roteamento multifásico pode ser usado para reduzir o número de caminhos instantâneos ao custo da introdução de buffers de armazenamento e latência. 6.6.4. Roteamento hipercubo. O roteamento hipercubo é um mecanismo que pode ser construído principalmente como uma extensão do mecanismo básico de roteamento descrito acima. Essencialmente, em vez de aumentar a conectividade do nó com o número de parachains e nós de subgrupos, crescemos apenas com o logaritmo dos parachains. As postagens podem transitar entre várias filas de parachains a caminho da entrega final. O roteamento em si é determinístico e simples. Começamos por limitar o número de compartimentos nas filas de entrada/saída; em vez de serem o número total de pára-quedas, eles são osbase de roteamento (b) . Isso será corrigido como o número de mudanças de parachains, com o expoente de roteamento (e) sendo aumentado. Sob este modelo, nosso volume de mensagens cresce com O (ser), com os caminhos permanecendo constantes e a latência (ou número de blocos necessários para entrega) com O(e). Nosso modelo de roteamento é um hipercubo de dimensões e, com cada lado do cubo tendo b localizações possíveis. Cada bloco roteamos mensagens ao longo de um único eixo. Nós alterne o eixo de forma round-robin, garantindo assim o pior tempo de entrega dos blocos e. Como parte do processamento de parachain, com destino ao exterior as mensagens encontradas na fila de entrada são roteadas imediatamente para o compartimento apropriado da fila de saída, considerando o número do bloco atual (e, portanto, dimensão de roteamento). Isto o processo necessita de transferência de dados adicional para cada salto na rota de entrega, no entanto, isso é um problema em si que pode ser mitigado usando alguns meios alternativos de entrega de carga útil de dados e incluindo apenas uma referência, em vez da carga útil completa da postagem no pós-teste. Um exemplo de roteamento hipercubo para um sistema com 4 parachains, b = 2 e e = 2 pode ser: Fase 0, em cada mensagem M: • sub0: se Mdest ∈{2, 3} então sendTo(2) senão mantém • sub1: se Mdest ∈{2, 3} então sendTo(3) senão mantém • sub2: se Mdest ∈{0, 1} então sendTo(0) senão mantém • sub3: se Mdest ∈{0, 1} então sendTo(1) senão mantém Fase 1, em cada mensagem M: • sub0: se Mdest ∈{1, 3} então sendTo(1) senão mantém • sub1: se Mdest ∈{0, 2} então sendTo(0) senão mantém • sub2: se Mdest ∈{1, 3} então sendTo(3) senão mantém • sub3: se Mdest ∈{0, 2} então sendTo(2) senão mantém As duas dimensões aqui são fáceis de ver como a primeira dois bits do índice de destino; para o primeiro bloco, o apenas um bit de ordem superior é usado. O segundo bloco trata com o bit de ordem inferior. Uma vez que ambos acontecem (de forma arbitrária ordem) então a postagem será roteada. 9pseudo-aleatório criptograficamente seguro
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 16 6.6.5. Maximizando a Serendipidade. Uma alteração do básico proposta veria um total fixo de c2 −c validators, com c−1 validators em cada subgrupo. Cada bloco, em vez de havendo um reparticionamento não estruturado de validators entre parachains, em vez de para cada subgrupo de parachains, cada validator seria atribuído a um único e diferente subgrupo parachain no bloco seguinte. Isso seria levam ao invariante que entre quaisquer dois blocos, para qualquer dois pares de parachain, existem dois validators que trocaram as responsabilidades do parachain. Embora isto não possa ser usado para obter garantias absolutas sobre a disponibilidade (um único validator ocasionalmente ficará off-line, mesmo se benevolente), pode, no entanto, otimizar o caso geral. Esta abordagem não é isenta de complicações. A adição de um parachain também exigiria uma reorganização do conjunto validator. Além disso o número de validators, estando vinculado ao quadrado do número de parachains, começaria inicialmente muito pequeno e eventualmente cresceria muito muito rápido, tornando-se insustentável após cerca de 50 parachains. Nenhum destes são problemas fundamentais. No primeiro caso, reorganização dos conjuntos validator é algo que deve ser feito regularmente de qualquer maneira. Em relação ao tamanho do validator definido, quando muito pequeno, vários validators podem ser atribuídos para o mesmo parachain, aplicando um fator inteiro ao total geral de validators. Um mecanismo de roteamento multifásico, como o roteamento hipercubo, discutido em 6.6.4, aliviar a necessidade de um grande número de validators quando há um grande número de cadeias. 6.7. Validação Parachain. O objetivo principal de um validator é testemunhar, como um ator bem vinculado, que o parachain bloco é válido, incluindo, mas não limitado a, qualquer transição de estado, quaisquer transações externas incluídas, a execução de quaisquer postos de espera na fila de entrada e o estado final da fila de saída. O processo em si é bastante simples. Uma vez que o validator selou o bloco anterior, eles estão livres para começar a trabalhar para fornecer um bloco de parachain candidato candidato para a próxima rodada de consenso. Inicialmente, o validator encontra um candidato a bloco parachain por meio de um agrupamento de parachain (descrito a seguir) ou um de seus co-validators. Os dados do candidato do bloco parachain inclui o cabeçalho do bloco, o cabeçalho do bloco anterior, quaisquer dados de entrada externos incluídos (para Ethereum e Bitcoin, tais dados seriam chamados de transações, no entanto, em princípio, podem incluir estruturas de dados arbitrárias para fins arbitrários), dados de fila de saída e dados internos para provar a validade da transição de estado (para Ethereum estes seriam os vários nós de teste de estado/armazenamento necessários para executar cada transação). Evidências experimentais mostram este conjunto de dados completo para um bloco Ethereum recente ter no máximo algumas centenas de KiB. Simultaneamente, se ainda não for feito, o validator será tentando recuperar informações relativas à transição do bloco anterior, inicialmente a partir do bloco anterior validators e posteriores de todos os validators que assinam o disponibilidade dos dados. Depois que validator receber esse bloco de candidato, eles então o validam localmente. O processo de validação está contido no módulo validator da classe parachain, um módulo de software sensível ao consenso que deve ser escrito para qualquer implementação de Polkadot (embora em princípio uma biblioteca com C ABI poderia permitir que uma única biblioteca ser compartilhado entre implementações com o apropriado redução na segurança resultante de ter apenas uma única implementação de “referência”). O processo pega o cabeçalho do bloco anterior e verifica sua identidade através da cadeia de retransmissão recentemente acordada. bloco no qual seu hash deve ser gravado. Uma vez verificada a validade do cabeçalho pai, o parachain específico a função de validação da classe pode ser chamada. Esta é uma função única que aceita vários campos de dados (aproximadamente aqueles fornecidos anteriormente) e retornando um booleano simples proclamando a validade do bloqueio. A maioria dessas funções de validação verificará primeiro o campos de cabeçalho que podem ser derivados diretamente de o bloco pai (por exemplo, pai hash, número). Seguindo isso, eles preencherão quaisquer estruturas de dados internas como necessários para processar transações e/ou postagens. Para uma cadeia do tipo Ethereum, isso equivale a preencher um teste o banco de dados com os nós que serão necessários para o execução completa das transações. Outros tipos de cadeia podem ter outro pmecanismos reparatórios. Uma vez feito isso, os posts de entrada e as transações externas (ou o que quer que os dados externos representem) serão promulgada, equilibrada de acordo com a especificação da cadeia. (Um o padrão sensato pode ser exigir que todas as postagens de entrada sejam processado antes que as transações externas sejam atendidas, no entanto, isso deve ser decidido pela lógica do parachain.) Através desta lei, uma série de postos de saída serão criados e será verificado se estes realmente correspondem o candidato do colador. Finalmente, o devidamente preenchido o cabeçalho será verificado em relação ao cabeçalho do candidato. Com um bloco candidato totalmente validado, o validator pode então votar no hash de seu cabeçalho e enviar todas as informações de validação necessárias para os co-validators em seu subgrupo. 6.7.1. Coladores Parachain. Os agrupadores de parachain são operadores não vinculados que cumprem grande parte da tarefa dos mineradores nas redes blockchain atuais. Eles são específicos para um parachain específico. Para funcionarem devem manter a cadeia de relés e o totalmente sincronizado pára-quedas. O significado preciso de “totalmente sincronizado” dependerá da classe do parachain, embora sempre inclua o estado atual da fila de entrada do parachain. No caso de Ethereum também envolve pelo menos manter um banco de dados Merkle-tree dos últimos blocos, mas pode também inclui várias outras estruturas de dados, incluindo Bloom filtros para existência de conta, informações familiares, registro saídas e tabelas de pesquisa reversa para número de bloco. Além de manter as duas cadeias sincronizadas, também deve “pescar” transações mantendo uma fila de transações e aceitando transações devidamente validadas da rede pública. Com a fila e a cadeia, é capaz de criar novos blocos candidatos para os validators escolhidos em cada bloco (cuja identidade é conhecida desde que a cadeia de relés esteja sincronizada) e submetê-los, juntamente com o diversas informações auxiliares, como prova de validade, via a rede peer. Por seu problema, cobra todas as taxas relativas às transações que inclui. Várias economias flutuam em torno disso arranjo. Num mercado fortemente competitivo onde há houver um excedente de coladores, é possível que a transação taxas serão compartilhadas com o parachain validators para incentivar a inclusão de um bloco de agrupamento específico. De forma similar,
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 17 alguns agrupadores podem até aumentar as taxas exigidas que precisam a ser pago para tornar o bloco mais atrativo para validators. Neste caso, um mercado natural deve se formar com transações que pagam taxas mais altas evitando a fila e ter uma inclusão mais rápida na cadeia. 6.8. Rede. Rede em blockchains tradicionais como Ethereum e Bitcoin tem requisitos bastante simples. Todas as transações e bloqueios são transmitidos em uma simples fofoca não direcionada. A sincronização está mais envolvida, especialmente com Ethereum mas na realidade esta lógica estava contida em a estratégia de pares, em vez do protocolo em si, que resolve alguns tipos de mensagens de solicitação e resposta. Embora Ethereum tenha feito progresso nas ofertas atuais de protocolo com o protocolo devp2p, o que permitiu muitos subprotocolos sejam multiplexados em uma única conexão de ponto e, portanto, tenham a mesma sobreposição de ponto, suportam muitos protocolos p2p simultaneamente, a parte Ethereum de o protocolo ainda permaneceu relativamente simples e o p2p protocolo por um tempo permanece inacabado com importantes funcionalidade ausente, como suporte QoS. Infelizmente, o desejo de criar um protocolo “web 3” mais onipresente, em grande parte falhou, com os únicos projetos que o utilizam sendo aqueles explicitamente financiado pela venda coletiva Ethereum. Os requisitos para Polkadot são bastante mais substanciais. Em vez de uma rede totalmente uniforme, Polkadot tem vários tipos de participantes, cada um com requisitos diferentes em relação à composição de seus pares e diversas redes “avenidas” cujos participantes tenderão a conversar sobre dados específicos. Isso significa uma sobreposição de rede substancialmente mais estruturada – e um protocolo que suporta isso – provavelmente será necessário. Além disso, a extensibilidade para facilitar adições futuras, como novos tipos de “cadeia”, pode eles próprios exigem uma nova estrutura de sobreposição. Embora uma discussão aprofundada sobre como a rede protocolo pode parecer estar fora do escopo deste documento, algumas análises de requisitos são razoáveis. Nós podemos dividir aproximadamente os participantes da nossa rede em dois conjuntos (relay-chain, parachains) cada um dos três subconjuntos. Nós podemos também afirmam que cada um dos participantes do parachain são apenas interessados em conversar entre si em vez de participantes de outros parachains: • Participantes da cadeia de retransmissão: • Validadores: P, dividido em subconjuntos P[s] para cada pára-quedas • Fiadores de Disponibilidade: A (podem ser representados por Validadores na forma básica do protocolo) • Clientes de cadeia de retransmissão: M (observe os membros de cada conjunto parachain também tenderá a ser membros de M) • Participantes do Parachain: • Coletores Parachain: C[0], C[1], . . . • Pescadores de paraquedas: F[0], F[1], . . . • Clientes Parachain: S[0], S[1], . . . • Clientes leves Parachain: L[0], L[1], . . . Em geral, nomeamos classes específicas de comunicação tenderá a ocorrer entre membros desses conjuntos: • P | Um <-> P | R: O cheio definir de validators/fiadores deve ser bem conectado para alcançar consenso. • P[s] <-> C[s] | P[s]: Cada validator como membro de um determinado grupo parachain tenderá a fofocar com outros membros, bem como com os compiladores desse parachain para descobrir e compartilhar candidatos de bloco. • A <-> P[s] | C | R: Cada fiador de disponibilidade precisará coletar dados de cadeia cruzada sensíveis ao consenso dados dos validators atribuídos a ele; agrupadores também pode otimizar a chance de consenso sobre seus bloquear anunciando-o aos fiadores de disponibilidade. Assim que os tiverem, os dados serão desembolsados para outro fiador para facilitar o consenso. • P[s] <-> A | P[s']: Parachain validators irá precisa coletar dados de entrada adicionais do conjunto anterior de validators ou dos fiadores de disponibilidade. • F[s] <-> P: Ao reportar, os pescadores podem colocar uma reclamação com qualquer participante. • M <-> M | P | R: Os clientes gerais da cadeia de retransmissão desembolsam dados de validators e fiadores. • S[s] <-> S[s] | P[s] | R: Os clientes Parachain desembolsam dados dos validator/fiadores. • L[s] <-> L[s] | S[s]: Clientes leves Parachain desembolsar dados dos clientes completos. Para garantir um mecanismo de transporte eficiente, um “plano” rede de sobreposição - como o devp2p de Ethereum - onde cada nó não diferencia (não arbitrariamente) a aptidão de seu é improvável que os pares sejam adequados. Um razoavelmente extensível o mecanismo de seleção e descoberta de pares provavelmente precisará a serem incluídos no protocolo, bem como agressivos planejando uma previsão para garantir o tipo certo de pares são “acidentalmente” connectado no momento certo. A estratégia precisa de composição de pares será diferente para cada turma de participantes: para uma escalação adequada multi-cadeias, os alceadores precisarão ser continuamente reconectando-se aos validators devidamente eleitos, ou irá precisa de acordos contínuos com um subconjunto de validators para garantir que eles não sejam desconectados durante a grande maioria das vezes em que são inúteis para isso validator. Os agrupadores também tentarão naturalmente manter um ou conexões mais estáveis no garantidor de disponibilidade definido para garantir a rápida propagação de suas ideias sensíveis ao consenso dados. Os fiadores de disponibilidade terão como objetivo principal manter um conexão estável entre si e com validators (para consenso e dados parachain críticos de consenso aos quais eles atestam), bem como a alguns coladores (para o parachain dados) e alguns pescadores e clientes plenos (para dispersão informações). Os validadores tenderão a procurar outros validators, especialmente aqueles do mesmo subgrupo e qualquer agrupadores que podem fornecer-lhes candidatos a blocos de parachain. Pescadores, bem como redes de revezamento e paraquedas em geral os clientes geralmente terão como objetivo manter uma conexão aberta a um validator ou fiador, mas muitos outros nós semelhantes para si mesmos de outra forma. Os clientes Parachain Light terão como objetivo semelhante estar conectados a um cliente completo do parachain, se não apenas outros clientes leves de parachain. 6.8.1. O problema da rotatividade de pares. Na proposta básica do protocolo, cada um desses subconjuntos se altera constantemente de forma aleatória a cada bloco conforme os validators atribuídos para verificar as transições parachain são eleitas aleatoriamente. Isso pode ser um problema caso nós díspares (não pares) precisem passar dados entre si. É preciso confiar em uma rede de pares bem distribuída e bem conectada para
POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 18 garantir que a distância do salto (e, portanto, a latência do pior caso) só cresça com o logaritmo do tamanho da rede (um protocolo semelhante ao Kademlia [13] pode ajudar aqui), ou deve-se introduzir tempos de bloqueio mais longos para permitir que a negociação de conexão necessária ocorra para manter um conjunto de pares que reflete as necessidades atuais de comunicação do nó. Nenhuma dessas são ótimas soluções: longos tempos de bloqueio ser forçado na rede pode torná-la inútil para aplicações e cadeias específicas. Mesmo uma situação perfeitamente justa e rede conectada resultará em desperdício substancial de largura de banda à medida que aumenta devido a nós desinteressados tendo para encaminhar dados inúteis para eles. Embora ambas as direções possam fazer parte da solução, uma otimização razoável para ajudar a minimizar a latência seria ser para restringir a volatilidade desses parachain validator conjuntos, reatribuindo a associação apenas entre séries de blocos (por exemplo, em grupos de 15, que em 4 segundos o tempo de bloqueio significaria alterar as conexões apenas uma vez por minuto) ou rotacionando os membros de forma incremental, por ex. mudando por um membro de cada vez (por exemplo, se houver são 15 validators atribuídos a cada parachain, então, em média, seria um minuto inteiro entre completamente único conjuntos). Ao limitar a quantidade de rotatividade entre pares e garantir que conexões vantajosas entre pares sejam bem feitas em avançar através da previsibilidade parcial do parachain conjuntos, podemos ajudar a garantir que cada nó mantenha um permanentemente seleção fortuita de pares. 6.8.2. Caminho para um protocolo de rede eficaz. Provavelmente o o esforço de desenvolvimento mais eficaz e razoável se concentrará na utilização de um protocolo pré-existente, em vez de continuar o nosso. Existem vários protocolos base peer-to-peer que podemos usar ou aumentar, incluindo o próprio devp2p de Ethereum [22], libp2p [1] do IPFS e GNUnet [4] do GNU. Uma revisão completa desses protocolos e sua relevância para a construção de um rede modular de pares que suporta certas garantias estruturais, orientação dinâmica entre pares e subprotocolos extensíveis está muito além do escopo deste documento, mas será um passo importante na implementação de Polkadot. 7. Aspectos práticos do Protocolo 7.1. Pagamento de transações intercadeias. Embora um ótimo quantidade de liberdade e simplicidade é obtida eliminando a necessidade de uma estrutura holística de contabilidade de recursos de computação como o gás de Ethereum, isso levanta uma questão importante: sem gás, como um parachain evitar que outro parachain o force a fazer cálculos? Embora possamos contar com a fila de entrada pós-transação buffers para evitar que uma cadeia envie spam para outra com dados de transação, não há mecanismo equivalente fornecido pelo protocolo para evitar spam no processamento de transações. Este é um problema deixado para o nível superior. Desde cadeias são livres para anexar semântica arbitrária à entrada dados de postagem de transação, podemos garantir que o cálculo deve ser pago antes de começar. Numa linha semelhante à modelo adotado por Ethereum Serenity, podemos imaginar um contrato de “arrombamento” dentro de um parachain que permite um validator terá pagamento garantido em troca do fornecimento de um determinado volume de recursos de processamento. Esses recursos podem ser medidos em algo como gás, mas também pode ser algum modelo totalmente novo, como tempo de execução subjetivo ou um modelo de taxa fixa semelhante a Bitcoin. Por si só, isso não é tão útil, pois não podemos presumir prontamente que o chamador fora da cadeia tenha disponível para ele qualquer que seja o mecanismo de valor reconhecido pela invasão contrato. No entanto, podemos imaginar um contrato secundário de “ruptura” na cadeia de origem. Os dois contratos juntos formariam uma ponte, reconhecendo-se e fornecendo equivalência de valor. (Estaqueamento-tokens, disponível para cada um, poderia ser usado para liquidar o balanço de pagamentos.) Ligar para outra cadeia desse tipo significaria proxy através desta ponte, que forneceria os meios de negociar a transferência de valor entre cadeias para pagar pelos recursos de computação necessários no parachain de destino. 7.2. Adicional Correntes. Enquanto o adição de um parachain é uma operação relativamente barata, não é gratuita. Mais parachains significa menos validators por parachain e, eventualmente, um número maior de validators, cada um com um título médio reduzido. Embora a questão de um menor custo de coerção para atacar um parachain seja mitigada através de pescadores, o crescente conjunto validator essencialmente força um maior grau de latência devido à mecânica do consenso subjacenteisso. Além disso, cada parachain traz consigo o potencial de lamentar validators com um algoritmo de validação excessivamente pesado. Como tal, haverá algum “preço” que validators e/ou a comunidade interessada extrairá para o adição de um novo parachain. Este mercado de correntes possivelmente veja a adição de: • Cadeias que provavelmente terão pagamento de contribuição líquida zero (em termos de bloqueio ou queima de staking tokens) a serem incluídas (por exemplo, cadeias de consórcio, Doge-chains, cadeias específicas de aplicativos); • cadeias que entregam valor intrínseco à rede através da adição de funcionalidades específicas difíceis para chegar a outro lugar (por exemplo, confidencialidade, escalabilidade interna, vínculos de serviço). Essencialmente, a comunidade de partes interessadas precisará ser incentivado a adicionar cadeias infantis - seja financeiramente ou através do desejo de adicionar cadeias funcionais ao relé. Prevê-se que novas cadeias adicionadas terão um impacto muito curto prazo para remoção, permitindo que novas cadeias sejam ser experimentado sem qualquer risco de comprometer a proposta de valor de médio ou longo prazo. 8. Conclusão Descrevemos uma direção que se pode tomar para criar um protocolo multicadeia escalável e heterogêneo com potencial para ser compatível com versões anteriores de determinados protocolos pré-existentes blockchain redes. Sob tal protocolo, os participantes trabalhar com interesse próprio e esclarecido para criar um sistema global que possa ser estendido de maneira excepcionalmente gratuita e sem o custo típico para os usuários existentes que vem de um design padrão blockchain. Nós demos um esboço da arquitetura que seria necessária, incluindo a natureza dos participantes, seus incentivos econômicos e os processos sob os quais eles devem se envolver. Nós temos identificou um projeto básico e discutiu seus pontos fortes e limitações; portanto, temos outras orientações que pode aliviar essas limitações e fornecer mais terreno para uma solução blockchain totalmente escalonável.POLKADOT: VISÃO PARA UMA ESTRUTURA MULTI-CADEIA HETEROGÊNEA ESBOÇO 1 19 8.1. Material faltante e questões abertas. A bifurcação da rede é sempre uma possibilidade devido a implementações divergentes do protocolo. A recuperação de tal condição excepcional não foi discutida. Dado que a rede terá necessariamente um período de finalização diferente de zero, não deve ser um grande problema recuperar-se da bifurcação da cadeia de retransmissão, no entanto, exigirá uma integração cuidadosa no o protocolo de consenso. O confisco de títulos e, inversamente, a provisão de recompensas não foi profundamente explorado. Atualmente assumimos recompensas são fornecidos na base de que o vencedor leva tudo: isso pode não fornecer o melhor modelo de incentivo para os pescadores. Um processo de compromisso-revelação de curto prazo permitiria a muitos pescadores reivindicar o prêmio dando uma distribuição mais justa de recompensas, no entanto, o processo pode levar a latência adicional no descoberta de mau comportamento. 8.2. Agradecimentos. Muito obrigado a todos revisores que ajudaram a colocar isso em uma forma vagamente forma apresentável. Em particular, Peter Czaban, Bjorn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler e Jack Petersson. Obrigado a todos as pessoas que contribuíram com ideias ou o início disso, Marek Kotewicz e Aeron Buchanan merecem menção especial. E obrigado a todos pela ajuda ao longo do caminho. Todos os erros são meus. Partes deste trabalho, incluindo pesquisas iniciais sobre algoritmos de consenso, foi financiado em parte pelos britânicos Governo no âmbito do programa Innovate UK.
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.