Buku Putih NEAR

Por Alex Skidanov and Illia Polosukhin · 2019

🇺🇸 English (Original)

🇮🇩 Bahasa Indonesia (Tradução)

Noções básicas de fragmentação

Vamos começar com a abordagem mais simples de fragmentação. Nesta abordagem, em vez de executando um blockchain, executaremos vários e chamaremos cada um desses blockchain de “fragmento”. Cada fragmento terá seu próprio conjunto de validators. Aqui e abaixo usamos um termo genérico “validator” para se referir aos participantes que verificam transações e produzir blocos, seja por mineração, como em Prova de Trabalho, ou por meio de votação 1Esta seção foi publicada anteriormente em https://near.ai/shard1. Se você leu antes, pule para a próxima seção.

mecanismo. Por enquanto, vamos supor que os fragmentos nunca se comuniquem entre si outro. Este design, embora simples, é suficiente para delinear alguns grandes desafios iniciais na fragmentação. 1.1 Particionamento de validador e cadeias de beacon Digamos que o sistema compreenda 10 fragmentos. O primeiro desafio é que com cada shard tendo seus próprios validators, cada shard agora é 10 vezes menos seguro que o cadeia inteira. Portanto, se uma cadeia não fragmentada com X validators decidir fazer um hard fork em uma cadeia de fragmentos e divide X validators em 10 fragmentos, cada fragmento agora tem apenas X/10 validators, e corromper um fragmento requer apenas corromper 5,1% (51%/10) do número total de validators (ver figura 1), Figura 1: Dividindo os validators entre fragmentos o que nos leva ao segundo ponto: quem escolhe validators para cada fragmento? Controlar 5,1% de validators só será prejudicial se todos esses 5,1% de validators estão no mesmo fragmento. Se validators não puderem escolher qual fragmento eles validarão em, é altamente improvável que um participante que controle 5,1% dos validators obtenha todos seus validators no mesmo fragmento, reduzindo fortemente sua capacidade de comprometer o sistema. Quase todos os designs de sharding hoje dependem de alguma fonte de aleatoriedade para atribua validators aos fragmentos. A aleatoriedade em blockchain por si só é um tópico muito desafiador e está fora do escopo deste documento. Por enquanto vamos supor que haja alguma fonte de aleatoriedade que possamos usar. Abordaremos a tarefa de validator em mais detalhes na seção 2.1. Tanto a aleatoriedade quanto a atribuição validator requerem computação que não é específico para qualquer fragmento em particular. Para esse cálculo, praticamente todos os existentes projetos têm um blockchain separado encarregado de executar operações necessário para a manutenção de toda a rede. Além de gerar aleatoriamentenúmeros e atribuindo validators aos fragmentos, essas operações geralmente também incluem receber atualizações de fragmentos e tirar instantâneos deles, processar apostas e cortes em sistemas de prova de aposta e rebalanceamento de fragmentos quando isso recurso é suportado. Essa cadeia é chamada de cadeia Beacon em Ethereum, uma cadeia de relé cadeia em PolkaDot e o Hub Cosmos em Cosmos. Ao longo deste documento nos referiremos a essa cadeia como cadeia Beacon. A existência da cadeia Beacon nos leva ao próximo tópico interessante, o fragmentação quadrática. 1.2 Fragmentação quadrática A fragmentação é frequentemente anunciada como uma solução que se adapta infinitamente ao número de nós participantes da operação da rede. Embora seja em teoria possível projetar tal solução de sharding, qualquer solução que tenha o conceito de Beacon cadeia não tem escalabilidade infinita. Para entender o porquê, observe que o Beacon chain precisa fazer alguns cálculos contábeis, como atribuir validators a fragmentos, ou instantâneos de blocos de cadeia de fragmentos, que são proporcionais ao número de fragmentos no sistema. Como a própria cadeia Beacon é um único blockchain, com computação limitada pelas capacidades computacionais dos nós que a operam, o número de fragmentos é naturalmente limitado. No entanto, a estrutura de uma rede fragmentada confere um efeito multiplicativo afetará quaisquer melhorias em seus nós. Considere o caso em que um arbitrário melhoria é feita na eficiência dos nós da rede, o que permitirá proporcionando tempos de processamento de transações mais rápidos. Se os nós que operam a rede, incluindo os nós da cadeia Beacon, se tornar quatro vezes mais rápido, então cada fragmento será capaz de processar quatro vezes mais transações, e a cadeia Beacon será capaz de manter 4 vezes mais fragmentos. A taxa de transferência em todo o sistema aumentará pelo fator de 4 × 4 = 16 — daí o nome fragmentação quadrática. É difícil fornecer uma medida precisa de quantos fragmentos estão viável hoje, mas é improvável que num futuro próximo o rendimento as necessidades dos usuários blockchain superarão as limitações da fragmentação quadrática. O grande número de nós necessários para operar tal volume de fragmentos com segurança é provavelmente ordens de magnitude maior do que o número de nós operando em todos os blockchains combinados hoje. 1.3 Fragmentação de estado Até agora não definimos muito bem o que exatamente é e o que não é separado quando uma rede é dividida em fragmentos. Especificamente, nós no blockchain realizam três tarefas importantes: eles não apenas 1) processam transações, eles também 2) retransmitir transações validadas e blocos concluídos para outros nós e 3) armazenar o estado e o histórico de todo o livro-razão da rede. Cada um desses três tarefas impõe uma exigência crescente aos nós que operam a rede:1. A necessidade de processar transações requer mais poder computacional com o aumento do número de transações processadas; 2. A necessidade de retransmitir transações e blocos requer mais largura de banda de rede com o aumento do número de transações retransmitidas; 3. A necessidade de armazenar dados exige mais armazenamento à medida que o estado cresce. É importante ressaltar que, diferentemente do poder de processamento e da rede, a necessidade de armazenamento aumenta mesmo que a taxa de transação (número de transações processadas por segundo) permanece constante. Da lista acima pode parecer que o requisito de armazenamento seria o mais urgente, pois é o único que vem aumentando ao longo do tempo mesmo que o número de transações por segundo não mude, mas na prática o requisito mais urgente hoje é o poder de computação. Todo o estado de Ethereum no momento em que este livro foi escrito tinha 100 GB, facilmente gerenciável pela maioria dos nós. Mas o número de transações que Ethereum pode processar é cerca de 20, ordens de magnitude menor do que o necessário para muitos casos de uso prático. Zilliqa é o projeto mais conhecido que fragmenta o processamento, mas não o armazenamento. A fragmentação do processamento é um problema mais fácil porque cada nó possui todo o estado, o que significa que os contratos podem invocar livremente outros contratos e ler quaisquer dados do blockchain. É necessária alguma engenharia cuidadosa para garantir atualizações de vários fragmentos atualizando as mesmas partes do estado não entram em conflito. Em nestes aspectos, Zilliqa está a adoptar uma abordagem relativamente simplista2. Embora tenha sido proposta a fragmentação do armazenamento sem a fragmentação do processamento, é extremamente incomum. Assim, na prática, a fragmentação de armazenamento, ou fragmentação de estado, quase sempre implica fragmentação de processamento e fragmentação de rede. Praticamente, no State Sharding, os nós em cada shard estão construindo seus próprio blockchain que contém transações que afetam apenas a parte local do estado global atribuído a esse fragmento. Portanto, os validators no o fragmento só precisa armazenar sua parte local do estado global e apenas executar, e, como tal, apenas retransmitem transações que afetam a sua parte do Estado. Isto partição reduz linearmente o requisito de todo o poder de computação, armazenamento e largura de banda da rede, mas introduz novos problemas, como disponibilidade de dados e transações entre fragmentos, ambas abordadas abaixo. 1.4 Transações entre fragmentos O modelo de fragmentação que descrevemos até agora não é muito útil, porque se fragmentos não podem se comunicar entre si, eles não são melhores do que vários blockchains independentes. Ainda hoje, quando a fragmentação não está disponível, há uma enorme demanda por interoperabilidade entre vários blockchains. Por enquanto, vamos considerar apenas transações de pagamento simples, onde cada participante possui conta em exatamente um fragmento. Se alguém deseja transferir dinheiro de 2Nossa análise de sua abordagem pode ser encontrada aqui: https://medium.com/nearprotocol/ 8f9efa0ce3buma conta para outra dentro do mesmo fragmento, a transação pode ser processada inteiramente pelos validators naquele fragmento. Se, no entanto, Alice que reside no fragmento

1 deseja enviar dinheiro para Bob, que reside no fragmento #2, nem validators

no fragmento nº 1 (eles não poderão creditar a conta de Bob) nem os validators em o fragmento nº 2 (eles não poderão debitar a conta de Alice) pode processar todo o transação. Existem duas famílias de abordagens para transações entre fragmentos: • Síncrono: sempre que uma transação entre fragmentos precisa ser executada, os blocos em vários fragmentos que contêm transição de estado relacionada ao a transação é produzida ao mesmo tempo, e os validators de vários fragmentos colaboram na execução de tais transações.3 • Assíncrona: uma transação entre fragmentos que afeta vários fragmentos é executado nesses fragmentos de forma assíncrona, o fragmento “Crédito” em execução sua metade assim que tiver evidências suficientes de que o fragmento “Débito” executou sua parte. Esta abordagem tende a ser mais prevalente devido à sua simplicidade e facilidade de coordenação. Este sistema é hoje proposto em Cosmos, Ethereum Serenity, Near, Kadena e outros. Um problema com isso abordagem reside no fato de que, se os blocos forem produzidos independentemente, há uma chance diferente de zero de que um dos vários blocos fique órfão, tornando assim a transação foi aplicada apenas parcialmente. Considere a figura 2 que representa dois fragmentos que encontraram uma bifurcação e uma transação entre fragmentos que foi registrado nos blocos A e X’ correspondentemente. Se as cadeias A-B e V'-X'-Y'-Z' acabam sendo canônicos nos fragmentos correspondentes, o a transação está totalmente finalizada. Se A'-B'-C'-D' e V-X se tornarem canônicos, então a transação é totalmente abandonada, o que é aceitável. Mas se, por Por exemplo, A-B e V-X tornam-se canônicos, então uma parte da transação é finalizada e a outra é abandonada, criando uma falha de atomicidade. Nós abordará como esse problema é abordado nos protocolos propostos na segunda parte, ao cobrir mudanças nas regras de escolha bifurcada e no consenso algoritmos propostos para protocolos fragmentados. Observe que a comunicação entre cadeias é útil fora de blockchains fragmentados também. A interoperabilidade entre cadeias é um problema complexo que muitos projetos estão tentando resolver. Em blockchains fragmentados, o problema é um pouco mais fácil, pois a estrutura do bloco e o consenso são os mesmos entre os fragmentos e há uma cadeia de beacons que pode ser usada para coordenação. Em um blockchain fragmentado, no entanto, todas as cadeias de fragmentos são iguais, enquanto no ecossistema global blockchains existe existem muitos blockchains diferentes, com diferentes casos de uso alvo, descentralização e garantias de privacidade. Construir um sistema no qual um conjunto de cadeias tem propriedades diferentes, mas usar consenso e estrutura de bloco suficientemente semelhantes e ter uma cadeia de beacon comum poderia permitir um ecossistema de blockchains heterogêneos que têm um 3O mais detalhado proposta conhecido para o autores de isso documento é Mesclar Blocos, descrito aqui: https://ethresear.ch/t/ merge-blocks-and-synchronous-cross-shard-state-execution/1240Figura 2: Transações assíncronas entre fragmentos subsistema de interoperabilidade funcional. É improvável que tal sistema apresente rotação validator, portanto, algumas medidas extras precisam ser tomadas para garantir a segurança. Ambos Cosmos e PolkaDot são efetivamente esses sistemas4 1,5 Comportamento malicioso Nesta seção, revisaremos qual comportamento adversário pode validators maliciosos exercício se conseguirem corromper um fragmento. Revisaremos abordagens clássicas para evitar a corrupção de fragmentos na seção 2.1. 1.5.1 Garfos maliciosos Um conjunto de validators maliciosos pode tentar criar uma bifurcação. Observe que isso não importa se o consenso subjacente é BFT ou não, corrompendo um número suficiente de validators sempre possibilitará a criação de um fork. É significativamente mais provável que mais de 50% de um único fragmento seja corrompido do que mais de 50% de toda a rede seja corrompida (vamos aprofunde-se nessas probabilidades na seção 2.1). Conforme discutido na seção 1.4, transações entre fragmentos envolvem certas mudanças de estado em vários fragmentos e os blocos correspondentes em tais fragmentos que aplicam tais mudanças de estado devem ser todos finalizados (ou seja, aparecer nas cadeias selecionadas em seus correspondentes fragmentos), ou todos serão órfãos (ou seja, não aparecerão nas cadeias selecionadas em seus fragmentos correspondentes). Como geralmente a probabilidade de os fragmentos serem corrompidos 4Consulte este artigo de Zaki Manian de Cosmos: https://forum.cosmos.network/ t/polkadot-vs-cosmos/1397/2 e esta tempestade de tweets do primeiro autor deste documento: https://twitter.com/AlexSkidanov/status/1129511266660126720 para uma comparação detalhada dos dois

não é insignificante, não podemos presumir que as bifurcações não acontecerão mesmo se um consenso bizantino for alcançado entre os fragmentos validators, ou se muitos blocos forem produzido no topo do bloco com a mudança de estado. Este problema tem múltiplas soluções, sendo a mais comum a ocasional ligação cruzada do bloco de cadeia de shard mais recente à cadeia de beacon. O garfo a regra de escolha nas cadeias de fragmentos é então alterada para sempre preferir a cadeia que é reticulado e aplica apenas a regra de escolha de bifurcação específica do shard para blocos que foram publicados desde a última ligação cruzada. 1.5.2 Aprovando blocos inválidos Um conjunto de validators pode tentar criar um bloco que aplique a função de transição de estado incorretamente. Por exemplo, começando com um estado em que Alice tem 10 tokens e Bob tem 0 tokens, o bloco pode conter uma transação que envia 10 tokens de Alice para Bob, mas termina com um estado em que Alice tem 0 tokens e Bob tem 1000 tokens, conforme mostrado na figura 3. Figura 3: Um exemplo de bloco inválido Em um blockchain clássico não fragmentado, tal ataque não é possível, uma vez que todos o participante da rede valida todos os blocos, e o bloco com tal uma transição de estado inválida será rejeitada por ambos os outros produtores de blocos, e os participantes da rede que não criam blocos. Mesmo que o malicioso validators continuam criando blocos em cima de um bloco inválido mais rápido do que validators honestos constroem a cadeia correta, tendo assim a cadeia com o inválido bloco sendo mais longo, não importa, pois cada participante que estiver usando o blockchain para qualquer finalidade valida todos os blocos e descarta todos os blocos construído em cima do bloco inválido. Na figura 4 existem cinco validators, três dos quais são maliciosos. Eles criou um bloco A’ inválido e continuou construindo novos blocos no topo disso. Dois validators honestos descartaram A’ como inválido e estavam construindo em cimaFigura 4: Tentativa de criar um bloco inválido em um blockchain não fragmentado do último bloco válido conhecido por eles, criando uma bifurcação. Como há menos validators na bifurcação honesta, sua cadeia é mais curta. No entanto, no blockchain clássico não fragmentado, todo participante que usa blockchain para qualquer finalidade é responsável por validar todos os blocos que recebe e recalcular o estado. Assim, qualquer pessoa que tenha algum interesse no blockchain observaria que A’ é inválido e, portanto, também descarta imediatamente B', C' e D', como tal, tomando o cadeia AB como a cadeia válida mais longa atual. Em um blockchain fragmentado, entretanto, nenhum participante pode validar todas as transações em todos os fragmentos, então eles precisam ter alguma forma de confirmar que em nenhum ponto na história de qualquer fragmento de blockchain nenhum bloco inválido foi incluído. Observe que, diferentemente dos forks, a ligação cruzada com a cadeia Beacon não é uma solução suficiente, uma vez que a cadeia Beacon não tem a capacidade de validar a cadeia Beacon. blocos. Ele só pode validar que há um número suficiente de validators naquele fragmento assinou o bloco (e como tal atestou a sua veracidade). Discutiremos soluções para este problema na seção 2.2 abaixo.

Dasar-dasar Berbagi

Mari kita mulai dengan pendekatan sharding yang paling sederhana. Dalam pendekatan ini, bukan menjalankan satu blockchain, kita akan menjalankan beberapa, dan memanggil masing-masing blockchain a "pecahan". Setiap pecahan akan memiliki kumpulan validatornya sendiri. Di sini dan di bawah kami menggunakan istilah umum “validator” untuk merujuk pada peserta yang memverifikasi transaksi dan menghasilkan blok, baik dengan menambang, seperti di Proof of Work, atau melalui pemungutan suara 1Bagian ini sebelumnya diterbitkan pada https://near.ai/shard1. Jika Anda pernah membacanya sebelumnya, lewati ke bagian berikutnya.

mekanisme. Untuk saat ini mari kita asumsikan bahwa pecahan tidak pernah berkomunikasi satu sama lain lainnya. Desain ini, meskipun sederhana, cukup untuk menguraikan beberapa tantangan besar awal dalam sharding. 1.1 Partisi validator dan rantai Beacon Katakanlah sistem terdiri dari 10 pecahan. Tantangan pertama adalah tantangan masing-masing shard memiliki validator sendiri, setiap shard kini 10 kali lebih aman dibandingkan seluruh rantai. Jadi jika rantai non-sharded dengan X validators memutuskan untuk melakukan hard-fork menjadi rantai pecahan, dan membagi X validator menjadi 10 pecahan, masing-masing pecahan sekarang hanya memiliki X/10 validators, dan merusak satu pecahan hanya memerlukan kerusakan 5,1% (51% / 10) dari jumlah total validators (lihat gambar 1), Gambar 1: Membagi validator menjadi pecahan yang membawa kita ke poin kedua: siapa yang memilih validator untuk setiap pecahan? Mengontrol 5,1% dari validator hanya akan merugikan jika 5,1% dari validator tersebut semuanya berada di pecahan yang sama. Jika validators tidak dapat memilih pecahan mana yang akan divalidasi di, peserta yang menguasai 5,1% dari validator sangat kecil kemungkinannya untuk mendapatkan semuanya validator mereka di pecahan yang sama, sangat mengurangi kemampuan mereka untuk berkompromi sistem. Hampir semua desain sharding saat ini bergantung pada sumber keacakan tetapkan validators ke pecahan. Keacakan pada blockchain sendiri merupakan topik yang sangat menantang dan berada di luar cakupan dokumen ini. Untuk saat ini mari kita asumsikan ada beberapa sumber keacakan yang bisa kita gunakan. Kami akan membahas tugas validator di lebih detail di bagian 2.1. Baik keacakan maupun penugasan validator memerlukan perhitungan yang tidak memerlukan perhitungan khusus untuk pecahan tertentu. Untuk perhitungan itu, praktis semuanya ada desain memiliki blockchain terpisah yang bertugas melakukan operasi diperlukan untuk pemeliharaan seluruh jaringan. Selain menghasilkan secara acakangka dan menugaskan validator ke pecahan, operasi ini juga sering terjadi termasuk menerima pembaruan dari pecahan dan mengambil cuplikannya, serta memprosesnya taruhan dan pemotongan dalam sistem Proof-of-Stake, dan menyeimbangkan kembali pecahan saat itu fitur didukung. Rantai seperti itu disebut rantai Beacon di Ethereum, Relay rantai di PolkaDot, dan Hub Cosmos di Cosmos. Sepanjang dokumen ini kami akan menyebut rantai tersebut sebagai rantai Beacon. Keberadaan rantai Beacon membawa kita ke topik menarik berikutnya, yaitu pecahan kuadrat. 1.2 Pecahan kuadrat Sharding sering kali diiklankan sebagai solusi yang berskala tanpa batas dengan jumlah yang ada node yang berpartisipasi dalam operasi jaringan. Meskipun secara teori mungkin saja demikian rancang solusi sharding seperti itu, solusi apa pun yang memiliki konsep Beacon rantai tidak memiliki skalabilitas yang tak terbatas. Untuk memahami alasannya, perhatikan Beacon itu rantai harus melakukan beberapa perhitungan pembukuan, seperti menugaskan validators ke pecahan, atau memotret blok rantai pecahan, yang sebanding dengan jumlahnya pecahan dalam sistem. Karena rantai Beacon itu sendiri merupakan blockchain tunggal, dengan komputasi dibatasi oleh kemampuan komputasi node yang mengoperasikannya, jumlah pecahan secara alami terbatas. Namun, struktur jaringan sharding memang memberikan perkalian berpengaruh pada perbaikan apa pun pada nodenya. Pertimbangkan kasus yang bersifat sewenang-wenang perbaikan dilakukan pada efisiensi node dalam jaringan yang memungkinkan mereka waktu pemrosesan transaksi lebih cepat. Jika node yang mengoperasikan jaringan, termasuk node dalam rantai Beacon, menjadi empat kali lebih cepat, maka setiap pecahan akan mampu diproses empat kali lebih banyak transaksi, dan rantai Beacon akan mampu mempertahankan pecahan 4 kali lebih banyak. Throughput di seluruh sistem akan meningkat dengan faktor 4 × 4 = 16 — demikianlah namanya sharding kuadrat. Sulit untuk memberikan pengukuran yang akurat mengenai berapa banyak pecahannya dapat dilakukan saat ini, namun kecil kemungkinannya untuk mencapai throughput di masa mendatang kebutuhan blockchain pengguna akan melampaui keterbatasan sharding kuadrat. Banyaknya node yang diperlukan untuk mengoperasikan pecahan sebanyak itu dengan aman kemungkinan besarnya lebih tinggi dari jumlah node yang beroperasi secara keseluruhan blockchain digabungkan hari ini. 1.3 Pecahan negara Sampai saat ini kita belum dapat mendefinisikan dengan baik apa sebenarnya yang bisa dipisahkan dan apa yang tidak ketika jaringan dibagi menjadi pecahan. Secara khusus, node di blockchain melakukan tiga tugas penting: mereka tidak hanya 1) memproses transaksi, mereka juga juga 2) menyampaikan transaksi yang divalidasi dan menyelesaikan blok ke node lain dan 3) menyimpan keadaan dan sejarah seluruh buku besar jaringan. Masing-masing dari ketiganya tugas-tugas ini membebankan kebutuhan yang semakin besar pada node-node yang mengoperasikan jaringan:1. Kebutuhan untuk memproses transaksi memerlukan daya komputasi yang lebih besar peningkatan jumlah transaksi yang diproses; 2. Kebutuhan untuk merelay transaksi dan memblokir memerlukan lebih banyak bandwidth jaringan seiring dengan meningkatnya jumlah transaksi yang direlai; 3. Kebutuhan untuk menyimpan data memerlukan lebih banyak penyimpanan seiring dengan pertumbuhan negara. Yang penting, tidak seperti kekuatan pemrosesan dan jaringan, kebutuhan penyimpanan bertambah meskipun tingkat transaksi (jumlah transaksi yang diproses per detik) tetap konstan. Dari daftar di atas mungkin tampak bahwa kebutuhan penyimpanannya adalah yang paling mendesak, karena ini adalah satu-satunya hal yang terus meningkat seiring berjalannya waktu walaupun jumlah transaksi per detiknya tidak berubah, namun dalam praktiknya persyaratan paling mendesak saat ini adalah kekuatan komputasi. Seluruh negara bagian Ethereum pada tulisan ini adalah 100GB, mudah dikelola oleh sebagian besar node. Namun jumlah transaksi yang dapat diproses Ethereum adalah sekitar 20 pesanan besarnya kurang dari apa yang dibutuhkan untuk banyak kasus penggunaan praktis. Zilliqa adalah proyek paling terkenal yang memproses pecahan tetapi tidak menyimpan. Sharding pemrosesan adalah masalah yang lebih mudah karena setiap node memiliki keseluruhannya menyatakan, artinya kontrak dapat dengan bebas meminta kontrak lain dan membaca data apa pun dari blockchain. Diperlukan rekayasa yang cermat untuk memastikan pembaruan dari beberapa pecahan yang memperbarui bagian negara yang sama tidak bertentangan. Di dalam hal ini Zilliqa mengambil pendekatan yang relatif sederhana2. Meskipun sharding penyimpanan tanpa sharding pemrosesan telah diusulkan, namun memang demikian sangat jarang. Jadi dalam praktiknya sharding penyimpanan, atau State Sharding, hampir selalu menyiratkan sharding pemrosesan dan sharding jaringan. Praktisnya, di bawah State Sharding, node di setiap shard membangunnya sendiri memiliki blockchain yang berisi transaksi yang hanya mempengaruhi bagian lokal dari keadaan global yang ditugaskan ke pecahan itu. Oleh karena itu, validators di shard hanya perlu menyimpan bagian lokalnya dari status global dan hanya mengeksekusi, dan dengan demikian hanya relay, transaksi yang mempengaruhi bagian negara mereka. Ini partisi secara linear mengurangi kebutuhan pada semua daya komputasi, penyimpanan, dan bandwidth jaringan, namun menimbulkan masalah baru, seperti ketersediaan data dan transaksi lintas pecahan, keduanya akan kami bahas di bawah. 1.4 Transaksi lintas pecahan Model sharding yang kami jelaskan sejauh ini tidak terlalu berguna, karena bersifat individual pecahan tidak dapat berkomunikasi satu sama lain, mereka tidak lebih baik dari banyak mandiri blockchains. Bahkan saat ini, ketika sharding tidak tersedia, ada a permintaan besar untuk interoperabilitas antara berbagai blockchains. Untuk saat ini, mari kita pertimbangkan transaksi pembayaran sederhana saja, di mana setiap peserta memiliki akun tepat pada satu shard. Jika seseorang ingin mentransfer uang dari 2Analisis kami mengenai pendekatan mereka dapat ditemukan di sini: https://medium.com/nearprotocol/ 8f9efae0ce3bsatu akun ke akun lain dalam shard yang sama, transaksi dapat diproses seluruhnya dengan validator di pecahan itu. Namun, jika Alice berada di beling

1 ingin mengirim uang kepada Bob yang berada di pecahan #2, tidak juga validators

pada pecahan #1 (mereka tidak akan dapat mengkredit akun Bob) atau validator pada pecahan #2 (mereka tidak akan bisa mendebit rekening Alice) dapat memproses keseluruhannya transaksi. Ada dua kelompok pendekatan untuk transaksi lintas pecahan: • Sinkron: setiap kali transaksi lintas pecahan perlu dijalankan, blok dalam beberapa pecahan yang berisi transisi keadaan terkait dengan semua transaksi diproduksi secara bersamaan, dan validator dari beberapa pecahan berkolaborasi dalam mengeksekusi transaksi tersebut.3 • Asynchronous: transaksi lintas shard yang memengaruhi banyak shard dieksekusi dalam pecahan tersebut secara asinkron, pecahan “Kredit” dijalankan setengahnya setelah memiliki cukup bukti bahwa pecahan “Debit” telah melaksanakan bagiannya. Pendekatan ini cenderung lebih lazim karena sifatnya kesederhanaan dan kemudahan koordinasi. Sistem ini saat ini diusulkan di Cosmos, Ethereum Serenity, Near, Kadena, dan lainnya. Ada masalah dengan ini Pendekatannya terletak pada bahwa jika blok diproduksi secara independen, ada kemungkinan bukan nol bahwa salah satu dari beberapa blok akan menjadi yatim piatu, sehingga membuat transaksi hanya diterapkan sebagian. Perhatikan gambar 2 yang menggambarkan dua pecahan yang keduanya mengalami fork, dan transaksi lintas pecahan yang dicatat di blok A dan X’ secara berurutan. Jika rantai A-B dan V'-X'-Y'-Z' menjadi kanonik di pecahan yang sesuai, yaitu transaksi telah selesai sepenuhnya. Jika A’-B’-C’-D’ dan V-X menjadi kanonik, maka transaksi tersebut sepenuhnya ditinggalkan, yang dapat diterima. Tapi jika, untuk Misalnya, A-B dan V-X menjadi kanonik, lalu satu bagian transaksi diselesaikan dan satu lagi ditinggalkan, sehingga menimbulkan kegagalan atomisitas. Kami akan membahas bagaimana masalah ini diatasi dalam protokol yang diusulkan di bagian kedua, ketika membahas perubahan pada aturan pilihan fork dan konsensus algoritma yang diusulkan untuk protokol sharded. Perhatikan bahwa komunikasi antar rantai berguna di luar blockchains yang dipecah juga. Interoperabilitas antar rantai adalah masalah kompleks yang banyak diproyeksikan sedang mencoba menyelesaikannya. Di blockchains yang dipecah, masalahnya menjadi lebih mudah struktur blok dan konsensusnya sama di seluruh shard, dan terdapat rantai suar yang dapat digunakan untuk koordinasi. Namun, dalam blockchain yang dipecah, semua rantai pecahannya sama, sedangkan di ekosistem global blockchains ada Ada banyak blockchain yang berbeda, dengan kasus penggunaan target yang berbeda, desentralisasi dan jaminan privasi. Membangun sistem di mana sekumpulan rantai memiliki sifat yang berbeda tetapi menggunakan konsensus dan struktur blok yang cukup mirip serta memiliki rantai suar yang sama dapat memungkinkan terciptanya ekosistem blockchain heterogen yang memiliki 3Itu paling rinci usulan diketahui untuk itu penulis dari ini dokumen adalah Gabungkan Blok, dijelaskan di sini: https://ethresear.ch/t/ gabung-blok-dan-sinkronisasi-lintas-pecahan-eksekusi/1240Gambar 2: Transaksi lintas pecahan asinkron subsistem interoperabilitas yang berfungsi. Sistem seperti ini kemungkinan tidak menampilkan rotasi validator, sehingga beberapa tindakan tambahan perlu diambil untuk memastikan keamanan. Keduanya Cosmos dan PolkaDot adalah sistem yang efektif4 1.5 Perilaku berbahaya Di bagian ini kami akan meninjau perilaku permusuhan apa yang dapat menyebabkan validators berbahaya latihan jika mereka berhasil merusak pecahan. Kami akan meninjau pendekatan klasik untuk menghindari kerusakan pecahan di bagian 2.1. 1.5.1 Garpu berbahaya Sekumpulan validator yang berbahaya mungkin mencoba membuat fork. Perhatikan bahwa tidak masalah apakah konsensus yang mendasarinya adalah BFT atau tidak, akan merusak jumlah yang cukup dari validators akan selalu memungkinkan untuk membuat garpu. Secara signifikan lebih mungkin terjadi kerusakan pada lebih dari 50% satu shard, dibandingkan lebih dari 50% keseluruhan jaringan yang rusak (kita akan selami lebih dalam probabilitas ini di bagian 2.1). Seperti yang dibahas di bagian 1.4, transaksi lintas pecahan melibatkan perubahan keadaan tertentu di beberapa pecahan, dan blok yang sesuai dalam pecahan tersebut yang menerapkan perubahan status tersebut harus baik semuanya sudah diselesaikan (yaitu muncul di rantai yang dipilih pada rantai yang sesuai pecahan), atau semuanya menjadi yatim piatu (yaitu tidak muncul dalam rantai yang dipilih pada pecahan yang sesuai). Karena umumnya kemungkinan pecahannya rusak 4Lihat artikel ini oleh Zaki Manian dari Cosmos: https://forum.cosmos.network/ t/polkadot-vs-cosmos/1397/2 dan tweet-storm ini oleh penulis pertama dokumen ini: https://twitter.com/AlexSkidanov/status/1129511266660126720 untuk perbandingan detail dari keduanya

tidak dapat diabaikan, kita tidak dapat berasumsi bahwa percabangan tidak akan terjadi bahkan jika konsensus Bizantium tercapai di antara validator pecahan, atau banyak blok yang dihancurkan diproduksi di atas blok dengan perubahan keadaan. Masalah ini memiliki banyak solusi, solusi yang paling umum adalah solusi sesekali tautan silang blok rantai pecahan terbaru ke rantai suar. Garpu aturan pilihan dalam rantai pecahan kemudian diubah untuk selalu memilih rantai yang ada terhubung silang, dan hanya menerapkan aturan pilihan garpu khusus pecahan untuk blok yang ada diterbitkan sejak cross-link terakhir. 1.5.2 Menyetujui blok yang tidak valid Sekumpulan validator mungkin mencoba membuat blok yang menerapkan fungsi transisi status secara tidak benar. Misalnya, dimulai dengan keadaan dimana Alice memiliki 10 tokens dan Bob memiliki 0 tokens, blok tersebut mungkin berisi transaksi yang mengirimkan 10 token dari Alice ke Bob, tetapi berakhir dengan keadaan di mana Alice memiliki 0 tokens dan Bob memiliki 1000 tokens, seperti yang ditunjukkan pada gambar 3. Gambar 3: Contoh blok yang tidak valid Dalam blockchain non-sharded klasik, serangan seperti itu tidak mungkin dilakukan, karena semuanya peserta dalam jaringan memvalidasi semua blok, dan blok dengan itu transisi keadaan yang tidak valid akan ditolak oleh produsen blok lainnya, dan peserta jaringan yang tidak membuat blok. Sekalipun itu jahat validators terus membuat blok di atas blok yang tidak valid tersebut lebih cepat dari validators yang jujur membangun rantai yang benar, sehingga memiliki rantai dengan yang tidak valid blok menjadi lebih panjang, tidak masalah, karena setiap peserta yang menggunakan blockchain untuk tujuan apa pun memvalidasi semua blok, dan membuang semua blok dibangun di atas blok yang tidak valid. Pada gambar 4 ada lima validator, tiga di antaranya berbahaya. Mereka membuat blok A' yang tidak valid, dan kemudian melanjutkan pembuatan blok baru di atasnya itu. Dua validator yang jujur membuang A' karena tidak valid dan dibangun di atasnyaGambar 4: Mencoba membuat blok yang tidak valid di blockchain yang tidak di-shard dari blok valid terakhir yang mereka ketahui, menciptakan garpu. Karena jumlahnya lebih sedikit validator berada di garpu yang jujur, rantainya lebih pendek. Namun, dalam blockchain nonsharded klasik, setiap peserta yang menggunakan blockchain untuk tujuan apa pun adalah bertanggung jawab untuk memvalidasi semua blok yang mereka terima dan menghitung ulang statusnya. Jadi siapa pun yang berkepentingan dengan blockchain akan mengamati bahwa A' tidak valid, dan dengan demikian segera membuang B', C' dan D', sehingga mengambil rantai A-B sebagai rantai valid terpanjang saat ini. Namun, dalam blockchain shard, tidak ada peserta yang dapat memvalidasi semua transaksi di semua shard, jadi mereka perlu memiliki cara untuk mengonfirmasinya kapan pun titik dalam riwayat pecahan apa pun dari blockchain tidak ada blok yang tidak valid yang disertakan. Perhatikan bahwa tidak seperti fork, tautan silang ke rantai Beacon bukanlah solusi yang memadai, karena rantai Beacon tidak memiliki kapasitas untuk memvalidasi blok. Itu hanya dapat memvalidasi bahwa jumlah validator yang cukup dalam pecahan itu menandatangani blok tersebut (dan dengan demikian membuktikan kebenarannya). Kami akan membahas solusi untuk masalah ini di bagian 2.2 di bawah.

Validade estadual e disponibilidade de dados

A ideia central em blockchains fragmentados é que a maioria dos participantes operando ou usar a rede não pode validar blocos em todos os shards. Como tal, sempre que qualquer participante precisa interagir com um fragmento específico, eles geralmente não podem baixe e valide todo o histórico do shard. O aspecto de particionamento do sharding, no entanto, levanta um potencial significativo problema: sem baixar e validar todo o histórico de um determinado fragmento, o participante não pode necessariamente ter certeza de que o estado com o qual 5Esta seção, exceto a subseção 2.5.3, foi publicada anteriormente em https://near.ai/ fragmento2. Se você leu antes, pule para a próxima seção.

eles interagem é o resultado de alguma sequência válida de blocos e que tal sequência de blocos é de fato a cadeia canônica no fragmento. Um problema que não existe em um blockchain não fragmentado. Apresentaremos primeiro uma solução simples para este problema que foi proposta por muitos protocolos e depois analisar como essa solução pode falhar e o que foram feitas tentativas para resolvê-lo. 2.1 Rotação de validadores A solução ingênua para a validade do estado é mostrada na figura 5: digamos que assumimos que todo o sistema possui da ordem de milhares de validators, dos quais não mais do que 20% são maliciosos ou irão falhar de outra forma (como por não serem online para produzir um bloco). Então, se amostrarmos 200 validators, a probabilidade de mais de 1 3 a falha para fins práticos pode ser assumida como zero. Figura 5: Amostragem de validators 1 3 é um limite importante. Existe uma família de protocolos de consenso, chamada BFT protocolos de consenso, que garantem que por menos de 1 3 de participantes falham, seja por bater ou por agir de alguma forma que viole o protocolo, o consenso será alcançado. Com esta suposição de porcentagem honesta de validator, se o conjunto atual de validators em um fragmento nos fornece algum bloqueio, a solução ingênua assume que o bloco é válido e que é construído sobre o que os validators acreditam ser a cadeia canônica desse fragmento quando eles começaram a validar. Os validators aprendeu a cadeia canônica do conjunto anterior de validators, que pelo mesmo suposição construída no topo do bloco que era o topo da cadeia canônica antes disso. Por indução, toda a cadeia é válida e, como nenhum conjunto de validators em qualquer ponto produziu garfos, a solução ingênua também é certa de que o atual chain é a única cadeia no fragmento. Veja a figura 6 para uma visualização.

Figura 6: Um blockchain com cada bloco finalizado via consenso BFT Esta solução simples não funciona se assumirmos que os validators podem ser corrompido adaptativamente, o que não é uma suposição irracional6. Adaptativamente corromper um único fragmento em um sistema com 1.000 fragmentos é significativamente mais barato do que corromper todo o sistema. Portanto, a segurança do protocolo diminui linearmente com o número de shards. Para ter certeza da validade um bloco, devemos saber que em qualquer momento da história nenhum fragmento do sistema foi a maioria dos validators conspirando; com adversários adaptativos, não temos mais tanta certeza. Como discutimos na seção 1.5, validators coniventes podem exercer dois comportamentos maliciosos básicos: criar bifurcações e produzir blocos inválidos. Forks maliciosos podem ser resolvidos por blocos interligados à cadeia Beacon, que geralmente é projetada para ter segurança significativamente maior do que as cadeias de fragmentos. Produzir blocos inválidos, no entanto, é uma tarefa significativamente mais problema desafiador para resolver. 2.2 Validade do Estado Considere a figura 7 na qual o fragmento nº 1 está corrompido e um agente malicioso produz bloco inválido B. Suponha que neste bloco B 1000 tokens foram cunhados ir ao ar por conta de Alice. O ator malicioso então produz o bloco C válido (em um sentido de que as transações em C são aplicadas corretamente) em cima de B, ofuscando o bloco inválido B e inicia uma transação entre fragmentos para o fragmento #2 que transfere esses 1.000 tokens para a conta de Bob. A partir deste momento o indevidamente tokens criados residem em um blockchain completamente válido no fragmento #2. Algumas abordagens simples para resolver esse problema são: 6Leia isso artigo para detalhes ligado como adaptativo corrupção pode ser carregado fora: https://medium.com/nearprotocol/d859adb464c8. Para mais detalhes ligado adaptativo corrupção, leia https://github.com/ethereum/wiki/wiki/Sharding-FAQ# quais são os modelos de segurança sob os quais estamos operandoFigura 7: Uma transação entre fragmentos de uma cadeia que possui um bloco inválido 1. Para validators do Shard #2 para validar o bloco do qual a transação é iniciado. Isso não funcionará nem no exemplo acima, pois o bloco C parece ser completamente válido. 2. Para validators no Shard #2 para validar um grande número de blocos anteriores ao bloco a partir do qual a transação é iniciada. Naturalmente, por qualquer número de blocos N validados pelo fragmento receptor do malicioso validators podem criar N+1 blocos válidos em cima do bloco inválido que eles produzido. Uma ideia promissora para resolver esse problema seria organizar os fragmentos em um gráfico não direcionado em que cada fragmento está conectado a vários outros fragmentos, e permitir apenas transações entre fragmentos vizinhos (por exemplo, é assim que A fragmentação de Vlad Zamﬁr funciona essencialmente7, e uma ideia semelhante é usada na fragmentação de Kadena. Chainweb [1]). Se uma transação entre fragmentos for necessária entre fragmentos que são não vizinhos, tal transação é roteada através de vários fragmentos. Neste projeto espera-se que um validator em cada fragmento valide todos os blocos em seu fragmento bem como todos os blocos em todos os fragmentos vizinhos. Considere uma figura abaixo com 10 fragmentos, cada um com quatro vizinhos, e não há dois fragmentos que exijam mais mais de dois saltos para uma comunicação entre fragmentos mostrada na figura 8. O fragmento nº 2 não está apenas validando seu próprio blockchain, mas também blockchains de todos os vizinhos, incluindo o Shard #1. Então, se um ator malicioso no Shard #1 está tentando criar um bloco B inválido e, em seguida, construir o bloco C sobre ele e iniciar uma transação entre fragmentos, tal transação entre fragmentos não ocorrerá desde o Shard #2 terá validado toda a história do Shard #1 que fará com que ele identifique o bloco B inválido. 7Leia mais sobre o design aqui: https://medium.com/nearprotocol/37e538177ed9

Figura 8: Uma transação cruzada inválida em um sistema tipo chainweb que irá ser detectado Embora corromper um único fragmento não seja mais um ataque viável, corromper um poucos fragmentos continuam sendo um problema. Na figura 9, um adversário corrompendo ambos os Shard

1 e Shard #2 executam com sucesso uma transação entre fragmentos para o Shard #3

com fundos de um bloco B inválido: Figura 9: Uma transação cruzada inválida em um sistema tipo chainweb que irá não ser detectado O Shard #3 valida todos os blocos no Shard #2, mas não no Shard #1, e não tem como detectar o bloco malicioso. Existem duas direções principais para resolver adequadamente a validade do estado: os pescadores

e provas criptográficas de computação. 2.3 Pescador A ideia por trás da primeira abordagem é a seguinte: sempre que um cabeçalho de bloco é comunicado entre cadeias para qualquer finalidade (como ligação cruzada com o cadeia de beacon ou uma transação entre fragmentos), há um período de tempo durante qual qualquer validator honesto pode fornecer uma prova de que o bloqueio é inválido. Lá são diversas construções que permitem provas muito sucintas de que os blocos são inválido, então a sobrecarga de comunicação para os nós receptores é bem menor do que receber um bloco completo. Com esta abordagem, enquanto houver pelo menos um validator honesto no fragmento, o sistema é seguro. Figura 10: Pescador Esta é a abordagem dominante (além de fingir que o problema não existe) entre os protocolos propostos hoje. Esta abordagem, no entanto, tem duas principais desvantagens: 1. O período de desafio precisa ser suficientemente longo para o honesto validator reconhecer que um bloco foi produzido, baixá-lo, verificá-lo completamente e preparar o desafio se o bloco for inválido. A introdução de tal período seria retardar significativamente as transações entre fragmentos. 2. A existência do protocolo de desafio cria um novo vetor de ataques quando nós maliciosos enviam spam com desafios inválidos. Uma solução óbvia para este problema é fazer com que os desafiantes depositem alguma quantia de tokens que são retornados se o desafio for válido. Esta é apenas uma solução parcial, pois ainda pode ser benéfico para o adversário enviar spam ao sistema (e queimar os depósitos) com desafios inválidos, por exemplo, para evitar o válidodesafio de um validator honesto de passar. Esses ataques são chamados ataques de luto. Consulte a seção 3.7.2 para saber como contornar o último ponto. 2.4 Argumentos de conhecimento sucintos e não interativos A segunda solução para a corrupção de múltiplos fragmentos é usar algum tipo de construção criptográfica que permita provar que um determinado cálculo (como como calcular um bloco de um conjunto de transações) foi realizado corretamente. Tais construções existem, por ex. zk-SNARKs, zk-STARKs e alguns outros, e alguns são usados ativamente em protocolos blockchain hoje para pagamentos privados, mais notavelmente ZCash. O principal problema com tais primitivas é que elas são notoriamente lentos para calcular. Por exemplo Protocolo Coda, que usa zk-SNARKs especificamente para provar que todos os blocos em blockchain são válidos, dito em um das entrevistas que pode levar 30 segundos por transação para criar uma prova (este número provavelmente é menor agora). Curiosamente, uma prova não precisa ser computada por uma parte confiável, uma vez que a prova não apenas atesta a validade do cálculo para o qual foi construída, mas também a validade da própria prova. Assim, o cálculo de tais provas pode ser dividido entre um conjunto de participantes com significativamente menos redundância do que seria necessário para realizar alguma computação sem confiança. Também permite aos participantes que computam zk-SNARKs para rodar em hardware especial sem reduzir o descentralização do sistema. Os desafios dos zk-SNARKs, além do desempenho, são: 1. Dependência de primitivas criptográficas menos pesquisadas e testadas ao longo do tempo; 2. “Resíduos tóxicos” – zk-SNARKs dependem de uma configuração confiável na qual um grupo de pessoas realiza alguns cálculos e depois descarta o intermediário valores desse cálculo. Se todos os participantes do procedimento conspirarem e manter os valores intermediários, podem ser criadas provas falsas; 3. Complexidade extra introduzida no design do sistema; 4. zk-SNARKs funcionam apenas para um subconjunto de cálculos possíveis, portanto, um protocolo com uma linguagem Turing-completa smart contract não seria capaz de usar SNARKs para provar a validade da cadeia. 2,5 Disponibilidade de dados O segundo problema que abordaremos é a disponibilidade de dados. Geralmente nós operando um determinado blockchain são separados em dois grupos: Full Nodes, aqueles que baixam cada bloco completo e validam cada transação, e Light Nós, aqueles que baixam apenas cabeçalhos de bloco e usam provas Merkle para peças do estado e das transações nas quais estão interessados, conforme mostrado na figura 11.

Figura 11: Árvore Merkel Agora, se a maioria dos nós completos conspirar, eles podem produzir um bloco, válido ou inválido e envia seu hash para os nós leves, mas nunca divulga o conteúdo completo do bloco. Existem várias maneiras pelas quais eles podem se beneficiar disso. Por exemplo, considere a figura 12: Figura 12: Problema de disponibilidade de dados Existem três blocos: o anterior, A, é produzido por validators honestos; o atual, B, tem validators conspirando; e o próximo, C, também será produzido por validators honestos (o blockchain está representado no canto inferior direito). Você é um comerciante. Os validators do bloco atual (B) receberam o bloco A dos validators anteriores, calculou um bloco no qual você recebe dinheiro,e enviei a você um cabeçalho desse bloco com uma prova Merkle do estado em que você tem dinheiro (ou uma prova Merkle de uma transação válida que envia o dinheiro para você). Confiante de que a transação foi finalizada, você fornece o serviço. Porém, os validators nunca distribuem o conteúdo completo do bloco B para qualquer um. Como tal, os validators honestos do bloco C não podem recuperar o bloco e são forçados a paralisar o sistema ou a construir em cima de A, privando você como comerciante de dinheiro. Quando aplicamos o mesmo cenário à fragmentação, as definições de completo e nó leve geralmente se aplica por fragmento: validators em cada download de fragmento a cada bloquear nesse fragmento e validar todas as transações nesse fragmento, mas outros nós no sistema, incluindo aqueles que capturam o estado das cadeias de fragmentos no cadeia de beacon, baixe apenas os cabeçalhos. Assim, os validators no fragmento são nós efetivamente completos para esse fragmento, enquanto outros participantes do sistema, incluindo a cadeia de beacon, operam como nós leves. Para que a abordagem do pescador que discutimos acima funcione, validators honestos precisa ser capaz de baixar blocos que estão interligados à cadeia de beacon. Se validators maliciosos vinculassem um cabeçalho de um bloco inválido (ou o usassem para iniciar uma transação entre fragmentos), mas nunca distribuiu o bloco, o honesto validators não têm como criar um desafio. Abordaremos três abordagens para resolver este problema que complementam um ao outro. 2.5.1 Provas de Custódia O problema mais imediato a ser resolvido é se um bloco estará disponível uma vez está publicado. Uma ideia proposta é ter os chamados Notários que façam rodízio entre fragmentos com mais frequência do que validators cuja única tarefa é baixar um bloquear e atestar que eles conseguiram baixá-lo. Eles podem ser girados com mais frequência porque não precisam baixar o estado inteiro do fragmento, ao contrário dos validators que não podem ser girados com frequência, pois devem baixar o estado do shard cada vez que eles giram, conforme mostrado na figura 13. O problema com esta abordagem ingénua é que é impossível provar mais tarde se o Tabelião conseguiu ou não fazer o download do bloco, então um Tabelião podem optar por sempre atestar que conseguiram baixar o bloco sem mesmo tentando recuperá-lo. Uma solução para isto é os Notários fornecerem alguma evidência ou apostar alguma quantidade de tokens atestando que o bloco foi baixado. Uma dessas soluções é discutida aqui: https://ethresear.ch/t/ Títulos de custódia compatíveis com agregação de 1 bit/2236. 2.5.2 Códigos de apagamento Quando um determinado nó light recebe um hash de um bloco, para aumentar a capacidade do nó confiança de que o bloco está disponível, ele pode tentar baixar alguns blocos aleatórios. pedaços do bloco. Esta não é uma solução completa, pois a menos que os nós de luz baixar coletivamente o bloco inteiro que os produtores de blocos maliciosos podem escolher

Figura 13: Os validadores precisam baixar o estado e, portanto, não podem ser girados frequentemente reter as partes do bloco que não foram baixadas por nenhum light node, assim ainda tornando o bloco indisponível. Uma solução é usar uma construção chamada Erasure Codes para tornar possível para recuperar o bloco completo mesmo que apenas uma parte do bloco esteja disponível, conforme mostrado na figura 14. Figura 14: Merkle tree criado com base em dados codificados para eliminação Tanto Polkadot quanto Ethereum Serenity têm designs em torno dessa ideia de que fornecer uma maneira para que os nós leves tenham confiança razoável de que os blocos estão disponíveis. A abordagem Ethereum Serenity tem uma descrição detalhada em [2].2.5.3 Abordagem de Polkadot para disponibilidade de dados Em Polkadot, como na maioria das soluções fragmentadas, cada fragmento (chamado parachain) captura seus blocos na cadeia de beacon (chamada cadeia de retransmissão). Digamos que existem 2f + 1 validators na cadeia de retransmissão. Os produtores de blocos de parachain, chamados agrupadores, uma vez que o bloco parachain é produzido, calcule uma versão codificada para apagamento do bloco que consiste em 2f +1 partes, de modo que quaisquer f partes sejam suficientes para reconstruir o bloco. Eles então distribuem uma parte para cada validator no cadeia de relé. Uma cadeia de retransmissão específica validator só assinaria em uma cadeia de retransmissão bloco se eles tiverem sua parte para cada bloco parachain que é capturado para tal bloco de cadeia de relé. Assim, se um bloco de cadeia de relés tiver assinaturas de 2f + 1 validators, e enquanto não mais do que f deles violarem o protocolo, cada o bloco parachain pode ser reconstruído buscando as partes dos validators que seguem o protocolo. Veja a figura 15. Figura 15: Disponibilidade de dados de Polkadot 2.5.4 Disponibilidade de dados a longo prazo Observe que todas as abordagens discutidas acima apenas atestam o fato de que um bloco foi publicado e está disponível agora. Os blocos podem ficar indisponíveis posteriormente por vários motivos: nós ficando off-line, nós apagando intencionalmente o histórico dados e outros. Um whitepaper que vale a pena mencionar que aborda esse problema é o Polyshard [3], que usa códigos de apagamento para disponibilizar blocos em fragmentos, mesmo que vários os fragmentos perdem completamente seus dados. Infelizmente, a sua abordagem específica exige todos os shards para baixar blocos de todos os outros shards, o que é proibitivamente caro. A disponibilidade a longo prazo não é uma questão tão premente: uma vez que nenhum participante espera-se que o sistema seja capaz de validar todas as cadeias em todos os

fragmentos, a segurança do protocolo fragmentado precisa ser projetada de tal forma maneira que o sistema é seguro, mesmo que alguns blocos antigos em alguns fragmentos se tornem completamente indisponível.

Validitas Negara dan Ketersediaan Data

Ide inti dalam blockchains yang dipecah adalah sebagian besar peserta mengoperasikan atau menggunakan jaringan tidak dapat memvalidasi blok di semua pecahan. Dengan demikian, kapan pun setiap peserta perlu berinteraksi dengan pecahan tertentu yang biasanya tidak bisa mereka lakukan unduh dan validasi seluruh riwayat beling. Namun, aspek partisi sharding memunculkan potensi yang signifikan masalah: tanpa mengunduh dan memvalidasi seluruh riwayat tertentu shard peserta belum tentu bisa memastikan negara bagian mana 5Bagian ini, kecuali subbagian 2.5.3, sebelumnya diterbitkan di https://near.ai/ pecahan2. Jika Anda membacanya sebelumnya, lewati ke bagian berikutnya.

mereka berinteraksi adalah hasil dari beberapa rangkaian blok yang valid dan rangkaian tersebut blok memang merupakan rantai kanonik dalam beling. Sebuah masalah yang tidak terjadi ada di blockchain yang tidak di-sharding. Pertama-tama kami akan menyajikan solusi sederhana untuk masalah yang telah diusulkan ini oleh banyak protokol dan kemudian menganalisis bagaimana solusi ini dapat rusak dan apa upaya telah dilakukan untuk mengatasinya. 2.1 Rotasi validator Solusi naif terhadap validitas negara ditunjukkan pada gambar 5: katakanlah kita berasumsi yang dimiliki seluruh sistem berjumlah ribuan validator, di antaranya tidak lebih dari 20% bersifat berbahaya atau akan gagal (misalnya gagal online untuk menghasilkan blok). Lalu jika kita mengambil sampel 200 validators, probabilitasnya lebih dari 1 3 kegagalan untuk tujuan praktis dapat diasumsikan nol. Gambar 5: Pengambilan sampel validatordtk 1 3 adalah ambang batas yang penting. Ada sekumpulan protokol konsensus, yang disebut BFT protokol konsensus, yang menjamin bahwa selama kurang dari 1 3 dari peserta gagal, baik karena menabrak atau bertindak dengan cara yang melanggar protokol, konsensus akan tercapai. Dengan asumsi persentase validator yang jujur, jika ditetapkan saat ini validators dalam pecahan memberi kita beberapa blok, asumsi solusi naif bahwa blok tersebut valid dan dibangun berdasarkan apa yang diyakini oleh validator rantai kanonik untuk pecahan tersebut ketika mereka mulai memvalidasi. validators mempelajari rantai kanonik dari kumpulan validator sebelumnya, yang juga melakukan hal yang sama asumsi yang dibangun di atas blok yang merupakan kepala rantai kanonik sebelum itu. Dengan induksi seluruh rantai valid, dan karena tidak ada himpunan validators pada titik mana pun dihasilkan garpu, solusi naifnya juga pasti arusnya rantai adalah satu-satunya rantai di pecahan. Lihat gambar 6 untuk visualisasinya.

Gambar 6: blockchain dengan setiap blok diselesaikan melalui konsensus BFT Solusi sederhana ini tidak akan berhasil jika kita berasumsi bahwa validator bisa berhasil dirusak secara adaptif, yang bukan merupakan asumsi yang tidak masuk akal6. Secara adaptif merusak satu pecahan dalam sistem dengan 1000 pecahan jauh lebih murah daripada merusak seluruh sistem. Oleh karena itu, keamanan protokol menurun secara linear seiring dengan jumlah shard. Untuk memperoleh kepastian keabsahan sebuah blok, kita harus tahu bahwa pada titik mana pun dalam sejarah tidak ada pecahan dalam sistem yang memilikinya mayoritas validator berkolusi; dengan musuh adaptif, kita tidak lagi memilikinya kepastian seperti itu. Seperti yang telah kita bahas di bagian 1.5, berkolusi validator dapat dilakukan dua perilaku dasar berbahaya: membuat fork, dan menghasilkan blok yang tidak valid. Garpu berbahaya dapat diatasi dengan menghubungkan blok ke rantai Beacon yang umumnya dirancang untuk memiliki keamanan yang jauh lebih tinggi daripada rantai pecahan. Namun, menghasilkan blok yang tidak valid adalah hal yang jauh lebih buruk masalah yang menantang untuk diatasi. 2.2 Validitas Negara Perhatikan gambar 7 di mana Shard #1 rusak dan dihasilkan oleh aktor jahat blok B tidak valid. Misalkan di blok ini 1000 token dicetak tipis mengudara di akun Alice. Aktor jahat kemudian menghasilkan blok C yang valid (dalam a merasakan bahwa transaksi di C diterapkan dengan benar) di atas B, membingungkan blok B yang tidak valid, dan memulai transaksi lintas pecahan ke Shard #2 itu mentransfer 1000 token itu ke rekening Bob. Mulai saat ini yang tidak semestinya token yang dibuat berada di blockchain yang sepenuhnya valid di Shard #2. Beberapa pendekatan sederhana untuk mengatasi masalah ini adalah: 6Baca ini artikel untuk detail pada bagaimana adaptif korupsi bisa menjadi dibawa keluar: https://medium.com/nearprotocol/d859adb464c8. Untuk lebih detail pada adaptif korupsi, membaca https://github.com/ethereum/wiki/wiki/Sharding-FAQ# model-keamanan-apa-yang-kami-operasikan-dibawahnyaGambar 7: Transaksi lintas pecahan dari rantai yang memiliki blok tidak valid 1. Untuk validators Shard #2 untuk memvalidasi blok tempat transaksi dimulai. Ini tidak akan berfungsi bahkan pada contoh di atas, karena blok C tampaknya sepenuhnya valid. 2. Untuk validators di Shard #2 untuk memvalidasi sejumlah besar blok sebelum blok tempat transaksi dimulai. Tentu saja untuk sejumlah blok N yang divalidasi oleh pecahan penerima yang berbahaya validators dapat membuat N+1 blok valid di atas blok tidak valid tersebut diproduksi. Ide yang menjanjikan untuk mengatasi masalah ini adalah dengan menyusun pecahan menjadi sebuah grafik tidak berarah di mana setiap pecahan terhubung ke beberapa pecahan lainnya, dan hanya mengizinkan transaksi lintas pecahan antar pecahan yang bertetangga (misalnya begini caranya Pecahan Vlad Zamfir pada dasarnya berhasil7, dan gagasan serupa digunakan dalam gagasan Kadena Jaringan rantai [1]). Jika diperlukan transaksi lintas shard antar shard yang ada bukan tetangga, transaksi tersebut disalurkan melalui banyak pecahan. Dalam desain ini a validator di setiap shard diharapkan memvalidasi semua blok di shardnya serta semua blok di semua pecahan di sekitarnya. Perhatikan gambar di bawah ini dengan 10 pecahan, masing-masing memiliki empat pecahan tetangga, dan tidak ada dua pecahan yang membutuhkan lebih banyak dari dua lompatan untuk komunikasi lintas pecahan yang ditunjukkan pada gambar 8. Pecahan #2 tidak hanya memvalidasi blockchain miliknya sendiri, tetapi juga blockchain dari semua tetangga, termasuk Shard #1. Jadi jika ada aktor jahat di Shard #1 sedang mencoba membuat blok B yang tidak valid, lalu membangun blok C di atasnya dan memulai transaksi lintas pecahan, transaksi lintas pecahan tersebut tidak akan berjalan melalui sejak Shard #2 akan memvalidasi seluruh sejarah Shard #1 yang mana akan menyebabkannya mengidentifikasi blok B yang tidak valid. 7Baca lebih lanjut tentang desain di sini: https://medium.com/nearprotocol/37e538177ed9

Gambar 8: Transaksi lintas pecahan yang tidak valid dalam sistem seperti chainweb yang akan melakukannya terdeteksi Meskipun merusak satu pecahan bukan lagi serangan yang layak, namun merusak a beberapa pecahan masih menjadi masalah. Pada gambar 9 musuh merusak kedua Shard

1 dan Shard #2 berhasil mengeksekusi transaksi lintas shard ke Shard #3

dengan dana dari blok B yang tidak valid: Gambar 9: Transaksi lintas pecahan yang tidak valid dalam sistem seperti chainweb yang akan melakukannya tidak terdeteksi Shard #3 memvalidasi semua blok di Shard #2, tetapi tidak di Shard #1, dan tidak memiliki cara untuk mendeteksi blok berbahaya. Ada dua arah utama dalam menyelesaikan validitas negara dengan tepat: nelayan

dan bukti komputasi kriptografi. 2.3 Nelayan Ide di balik pendekatan pertama adalah sebagai berikut: setiap kali ada header blok dikomunikasikan antar rantai untuk tujuan apa pun (seperti tautan silang ke rantai suar, atau transaksi lintas pecahan), ada periode waktu selama itu yang mana validator yang jujur dapat memberikan bukti bahwa blok tersebut tidak valid. Di sana Ada berbagai konstruksi yang memungkinkan bukti yang sangat ringkas bahwa balok-balok tersebut memang ada tidak valid, sehingga overhead komunikasi untuk node penerima jauh lebih kecil daripada menerima blok penuh. Dengan pendekatan ini selama setidaknya ada satu validator yang jujur di dalamnya pecahan, sistem aman. Gambar 10: Nelayan Ini adalah pendekatan yang dominan (selain berpura-pura bahwa masalahnya tidak ada) di antara protokol-protokol yang diusulkan saat ini. Namun pendekatan ini memiliki dua hal kelemahan utama: 1. Periode tantangan harus cukup lama untuk validator yang jujur untuk mengenali suatu blok telah diproduksi, mengunduhnya, memverifikasinya sepenuhnya, dan mempersiapkannya tantangan jika blok tidak valid. Memperkenalkan periode seperti itu akan membantu secara signifikan memperlambat transaksi lintas pecahan. 2. Adanya protokol tantangan menciptakan vektor serangan baru ketika node jahat melakukan spam dengan tantangan yang tidak valid. Solusi yang jelas untuk masalah ini adalah membuat penantang menyetor sejumlah tokens itu dikembalikan jika tantangannya valid. Ini hanyalah solusi parsial mungkin masih bermanfaat bagi musuh untuk mengirim spam ke sistem (dan membakar deposito) dengan tantangan yang tidak valid, misalnya untuk mencegah validtantangan dari validator yang jujur dari yang dilalui. Serangan-serangan ini adalah disebut Serangan Berduka. Lihat bagian 3.7.2 untuk mengetahui cara menyiasati poin terakhir. 2.4 Argumen Pengetahuan Non-interaktif Ringkas Solusi kedua terhadap korupsi multiple-shard adalah dengan menggunakan semacam konstruksi kriptografi yang memungkinkan seseorang membuktikan bahwa perhitungan tertentu (seperti sebagai komputasi satu blok dari serangkaian transaksi) dilakukan dengan benar. Konstruksi seperti itu memang ada, mis. zk-SNARKs, zk-STARKs dan beberapa lainnya, dan beberapa saat ini secara aktif digunakan dalam protokol blockchain untuk pembayaran pribadi, terutama ZCash. Masalah utama dengan kaum primitif seperti itu adalah mereka terkenal lambat untuk dihitung. Misalnya. Protokol Coda, yang menggunakan zk-SNARKs khusus untuk membuktikan bahwa semua blok di blockchain valid, dikatakan dalam satu dari wawancara bahwa diperlukan waktu 30 detik per transaksi untuk membuat bukti (jumlah ini mungkin lebih kecil saat ini). Menariknya, sebuah pembuktian tidak perlu dihitung oleh pihak yang terpercaya buktinya tidak hanya membuktikan keabsahan penghitungan yang dibuatnya, tetapi juga membuktikannya keabsahan pembuktian itu sendiri. Dengan demikian, perhitungan pembuktian tersebut dapat dibagi di antara sekelompok peserta dengan redundansi yang jauh lebih sedikit dibandingkan yang seharusnya diperlukan untuk melakukan beberapa perhitungan yang tidak dapat dipercaya. Hal ini juga memungkinkan untuk peserta yang menghitung zk-SNARK untuk dijalankan pada perangkat keras khusus tanpa mengurangi desentralisasi sistem. Tantangan zk-SNARKs, selain kinerja, adalah: 1. Ketergantungan pada kriptografi primitif yang kurang diteliti dan kurang teruji waktu; 2. "Limbah beracun" - zk-SNARK bergantung pada pengaturan tepercaya di mana suatu grup orang melakukan beberapa perhitungan dan kemudian membuang perantara nilai perhitungan itu. Jika semua peserta dalam prosedur berkolusi dan mempertahankan nilai tengahnya, bukti palsu dapat dibuat; 3. Kompleksitas ekstra dimasukkan ke dalam desain sistem; 4. zk-SNARKs hanya berfungsi untuk sebagian dari kemungkinan komputasi, jadi sebuah protokol dengan bahasa smart contract lengkap Turing tidak akan dapat digunakan SNARK untuk membuktikan validitas rantai. 2.5 Ketersediaan Data Masalah kedua yang akan kami bahas adalah ketersediaan data. Umumnya node mengoperasikan blockchain tertentu dipisahkan menjadi dua kelompok: Node Penuh, mereka yang mengunduh setiap blok penuh dan memvalidasi setiap transaksi, dan Ringan Node, yang hanya mengunduh header blok, dan menggunakan bukti Merkle untuk bagian-bagiannya negara dan transaksi yang mereka minati, seperti yang ditunjukkan pada gambar 11.

Gambar 11: Pohon Merkle Sekarang jika mayoritas node penuh berkolusi, mereka dapat menghasilkan blok, valid atau tidak valid, dan kirimkan hash-nya ke node lampu, tetapi jangan pernah mengungkapkan konten lengkapnya dari blok tersebut. Ada berbagai cara yang dapat mereka manfaatkan. Misalnya, perhatikan gambar 12: Gambar 12: Masalah Ketersediaan Data Ada tiga blok: blok sebelumnya, A, diproduksi oleh validators yang jujur; arus, B, berkolusi validator; dan berikutnya, C, juga akan diproduksi dengan jujur validators (blockchain digambarkan di pojok kanan bawah). Anda adalah seorang pedagang. validators dari blok saat ini (B) menerima blok A dari validators sebelumnya, menghitung blok tempat Anda menerima uang,dan mengirimi Anda tajuk blok itu dengan bukti Merkle tentang negara bagiannya Anda memiliki uang (atau bukti Merkle dari transaksi sah yang mengirimkan uang tersebut kepada Anda). Yakin transaksi telah selesai, Anda menyediakan layanan tersebut. Namun, validators tidak pernah mendistribusikan seluruh konten blok B ke dalamnya siapa pun. Dengan demikian, validator yang jujur dari blok C tidak dapat mengambil blok tersebut, dan terpaksa menghentikan sistem atau membangun di atas A, sehingga membuat Anda kehilangan a pedagang uang. Saat kami menerapkan skenario yang sama pada sharding, definisi penuh dan light node umumnya berlaku per shard: validators di setiap unduhan shard memblokir di pecahan itu dan memvalidasi setiap transaksi di pecahan itu, tetapi lainnya node dalam sistem, termasuk node yang mengambil status rantai pecahan ke dalam rantai suar, hanya unduh headernya. Jadi validator yang ada di pecahan adalah node penuh secara efektif untuk pecahan itu, sementara peserta lain dalam sistem, termasuk rantai suar, beroperasi sebagai titik cahaya. Agar pendekatan nelayan yang kita bahas di atas berhasil, jujurlah validators harus dapat mengunduh blok yang terhubung silang ke rantai suar. Jika validators jahat menghubungkan header dari blok yang tidak valid (atau menggunakannya untuk memulai transaksi lintas pecahan), tetapi tidak pernah mendistribusikan blok, jujur validators tidak punya cara untuk membuat tantangan. Kami akan membahas tiga pendekatan untuk mengatasi masalah ini yang saling melengkapi satu sama lain. 2.5.1 Bukti Penitipan Masalah paling mendesak yang harus dipecahkan adalah apakah suatu blok tersedia satu kali itu diterbitkan. Salah satu ide yang diusulkan adalah untuk memiliki apa yang disebut Notaris yang melakukan rotasi antar pecahan lebih sering daripada validator yang tugasnya hanya mengunduh a memblokir dan membuktikan fakta bahwa mereka dapat mengunduhnya. Bisa jadi diputar lebih sering karena tidak perlu mengunduh seluruh negara bagian pecahan, tidak seperti validator yang tidak dapat sering diputar sejak saat itu harus mengunduh status pecahan setiap kali beling diputar, seperti yang ditunjukkan pada gambar 13. Masalah dengan pendekatan naif ini adalah tidak mungkin dibuktikan di kemudian hari apakah Notaris itu mampu atau tidak untuk mengunduh blok tersebut, jadi Notaris dapat memilih untuk selalu membuktikan bahwa mereka dapat mengunduh blok tersebut tanpa bahkan mencoba mengambilnya. Salah satu solusinya adalah Notaris yang menyediakan beberapa bukti atau mempertaruhkan sejumlah token untuk membuktikan bahwa blok tersebut benar diunduh. Salah satu solusi tersebut dibahas di sini: https://ethresear.ch/t/ Obligasi-penahanan-ramah-agregasi-1-bit/2236. 2.5.2 Kode Penghapusan Ketika node cahaya tertentu menerima hash dari sebuah blok, untuk meningkatkan node tersebut yakin bahwa blok tersebut tersedia, ia dapat mencoba mengunduh beberapa secara acak potongan blok. Ini bukan solusi yang lengkap, karena kecuali titik cahaya secara kolektif mengunduh seluruh blok yang dapat dipilih oleh produsen blok jahat

Gambar 13: Validator perlu mengunduh status sehingga tidak dapat dirotasi sering untuk menahan bagian blok yang tidak diunduh oleh node lampu mana pun, sehingga masih membuat blok tidak tersedia. Salah satu solusinya adalah dengan menggunakan konstruksi yang disebut Erasure Codes untuk mewujudkannya untuk memulihkan blok penuh meskipun hanya sebagian dari blok yang tersedia, seperti yang ditunjukkan pada gambar 14. Gambar 14: Merkle tree dibangun di atas data berkode penghapusan Baik Polkadot dan Ethereum Serenity memiliki desain seputar gagasan ini yang menyediakan cara bagi node cahaya untuk cukup yakin bahwa blok tersebut tersedia. Pendekatan Ethereum Serenity memiliki penjelasan rinci di [2].2.5.3 Pendekatan Polkadot terhadap ketersediaan data Di Polkadot, seperti pada sebagian besar solusi shard, setiap shard (disebut parachain) mengambil snapshot bloknya ke rantai suar (disebut rantai relai). Katakanlah ada 2f + 1 validators pada rantai relai. Produsen blok dari blok parachain, disebut collators, setelah blok parachain diproduksi, hitung versi blok yang diberi kode penghapusan yang terdiri dari 2f +1 bagian sedemikian rupa sehingga f bagian mana pun mencukupi untuk merekonstruksi blok tersebut. Mereka kemudian mendistribusikan satu bagian ke setiap validator di rantai relai. Rantai relai tertentu validator hanya akan masuk pada rantai relai blok jika mereka memiliki bagiannya untuk setiap blok parachain yang di-snapshot blok rantai relai tersebut. Jadi, jika blok rantai relai memiliki tanda tangan dari 2f + 1 validators, dan selama tidak lebih dari f yang melanggar protokol, masing-masing blok parachain dapat direkonstruksi dengan mengambil bagian dari validators yang mengikuti protokol. Lihat gambar 15. Gambar 15: ketersediaan data Polkadot 2.5.4 Ketersediaan data jangka panjang Perhatikan bahwa semua pendekatan yang dibahas di atas hanya membuktikan fakta bahwa sebuah blok telah diterbitkan sama sekali, dan tersedia sekarang. Blok nantinya bisa menjadi tidak tersedia karena berbagai alasan: node mati, node sengaja menghapus riwayat data, dan lain-lain. Whitepaper yang layak disebutkan untuk mengatasi masalah ini adalah Polyshard [3], yang menggunakan kode penghapusan untuk membuat blok tersedia di seluruh pecahan meskipun beberapa pecahan benar-benar kehilangan datanya. Sayangnya pendekatan khusus mereka memerlukan hal ini semua pecahan untuk mengunduh blok dari semua pecahan lainnya, yang merupakan penghalang mahal. Ketersediaan jangka panjang bukanlah suatu masalah yang mendesak: karena tidak ada peserta dalam sistem diharapkan mampu memvalidasi semua rantai di semua

pecahan, keamanan protokol shard perlu dirancang sedemikian rupa cara agar sistem tetap aman meskipun beberapa blok lama di beberapa pecahan menjadi sama sekali tidak tersedia.

Nightshade

3.1 De cadeias de fragmentos a pedaços de fragmentos O modelo de sharding com shard chains e beacon chain é muito poderoso, mas tem certas complexidades. Em particular, a regra de escolha do fork precisa ser executada em cada cadeia separadamente, a regra de escolha do fork nas cadeias de fragmentos e no beacon a corrente deve ser construída de forma diferente e testada separadamente. No Nightshade modelamos o sistema como um único blockchain, no qual cada bloco contém logicamente todas as transações para todos os fragmentos e altera o estado completo de todos os fragmentos. Fisicamente, no entanto, nenhum participante baixa o estado completo ou o bloco lógico completo. Em vez disso, cada participante da rede apenas mantém o estado que corresponde aos fragmentos para os quais eles validam as transações, e a lista de todas as transações no bloco é dividida em físicas pedaços, um pedaço por fragmento. Sob condições ideais, cada bloco contém exatamente um pedaço por fragmento por bloco, que corresponde aproximadamente ao modelo com cadeias de fragmentos em que o shard chains produzem blocos com a mesma velocidade que a beacon chain. No entanto, devido a atrasos na rede, alguns pedaços podem estar faltando, então, na prática, cada bloco contém um ou zero pedaços por fragmento. Consulte a seção 3.3 para obter detalhes sobre como blocos são produzidos. Figura 16: Um modelo com cadeias de fragmentos à esquerda e com uma cadeia tendo blocos divididos em pedaços à direita

3.2 Consenso As duas abordagens dominantes para o consenso nos blockchains hoje são as cadeia mais longa (ou mais pesada), na qual a cadeia que tem mais trabalho ou participação usado para construí-lo é considerado canônico, e BFT, em que para cada bloco alguns conjunto de validators alcança um consenso BFT. Nos protocolos propostos recentemente, esta última é uma abordagem mais dominante, uma vez que fornece finalidade imediata, enquanto na cadeia mais longa mais blocos precisam a ser construído no topo do bloco para garantir a finalidade. Muitas vezes por um significado segurança o tempo que leva para que um número suficiente de blocos seja construído leva em conta ordem de horas. Usar o consenso BFT em cada bloco também tem desvantagens, como: 1. O consenso BFT envolve uma quantidade considerável de comunicação. Enquanto avanços recentes permitem que o consenso seja alcançado em tempo linear em número de participantes (ver, por exemplo, [4]), ainda é perceptível uma sobrecarga por bloco; 2. É inviável que todos os participantes da rede participem do BFT consenso por bloco, portanto, geralmente apenas um subconjunto de participantes amostrados aleatoriamente chega ao consenso. Um conjunto amostrado aleatoriamente pode ser, em princípio, corrompido adaptativamente e, em teoria, uma bifurcação pode ser criada. O sistema ou precisa ser modelado para estar pronto para tal evento e, portanto, ainda ter uma regra de escolha de bifurcação além do consenso BFT ou ser projetado para fechar cair em tal evento. Vale ressaltar que alguns projetos, como Algorand [5], reduzem significativamente a probabilidade de corrupção adaptativa. 3. Mais importante ainda, o sistema para se 1 3 ou mais de todos os participantes são off-line. Assim, qualquer falha temporária na rede ou divisão da rede pode paralisar completamente o sistema. Idealmente, o sistema deve ser capaz de continuar a operar enquanto pelo menos metade dos participantes estiver online (mais pesado protocolos baseados em cadeia continuam operando mesmo que menos da metade dos participantes estejam online, mas a conveniência desta propriedade é mais discutível dentro da comunidade). Um modelo híbrido em que o consenso utilizado é algum tipo de consenso mais pesado cadeia, mas alguns blocos são finalizados periodicamente usando um gadget de finalização BFT mantendo as vantagens de ambos os modelos. Esses BFT gadgets de finalidade são Casper FFG [6] usado em Ethereum 2.0 8, Casper CBC (ver https://vitalik. ca/general/2018/12/05/cbc_casper.html) e GRANDPA (consulte https:// Medium.com/polkadot-network/d08a24a021b5) usado em Polkadot. Nightshade usa o consenso da cadeia mais pesada. Especificamente quando um bloco produtor produz um bloco (ver seção 3.3), ele pode coletar assinaturas de outros produtores de bloco e validators atestando o bloco anterior. Veja a seção 3.8 para obter detalhes sobre como um número tão grande de assinaturas é agregado. O peso 8 Veja também a sessão do quadro branco com Justin Drake para uma visão geral detalhada de Casper FFG e como ele está integrado ao consenso da cadeia mais pesada do GHOST aqui: https://www. youtube.com/watch?v=S262StTwkmode um bloco é então a aposta cumulativa de todos os signatários cujas assinaturas são incluído no bloco. O peso de uma corrente é a soma dos pesos dos blocos. No topo do consenso da cadeia mais pesada, usamos um gadget de finalidade que usa os atestados para finalizar os blocos. Para reduzir a complexidade do sistema, usamos um gadget de finalidade que não influencia de forma alguma a regra de escolha do fork, e, em vez disso, apenas introduz condições de corte extras, de modo que, uma vez que um bloco seja finalizado pelo gadget de finalidade, um fork é impossível, a menos que uma porcentagem muito grande da aposta total é reduzida. Casper CBC é um gadget de finalidade, e nós atualmente modelo com Casper CBC em mente. Também trabalhamos em um protocolo BFT separado chamado TxFlow. Na hora de ao escrever este documento, não está claro se o TxFlow será usado em vez do Casper CBC. Notamos, no entanto, que a escolha do dispositivo final é em grande parte ortogonal ao resto do design. 3.3 Produção de blocos No Nightshade existem duas funções: produtores de blocos e validators. Em qualquer ponto em que o sistema contém w produtores de blocos, w = 100 em nossos modelos e wv validators, em nosso modelo v = 100, wv = 10.000. O sistema é Prova de Participação, o que significa que tanto os produtores de blocos quanto os validators têm algum número de recursos internos moeda (referida como ”tokens”) bloqueada por um período de tempo muito superior ao tempo que gastam no desempenho de suas funções de construção e validação da cadeia. Tal como acontece com todos os sistemas de Prova de Participação, nem todos os produtores de blocos w e nem todos os wv validators são entidades diferentes, uma vez que isso não pode ser aplicado. Cada dos produtores de bloco w e dos wv validators, no entanto, têm um separado aposta. O sistema contém n fragmentos, n = 1000 em nosso modelo. Como mencionado em seção 3.1, no Nightshade não há shard chains, em vez disso, todos os produtores de blocos e validators estão construindo um único blockchain, que chamamos de cadeia principal. O estado da cadeia principal é dividido em n fragmentos, e cada bloco produtor e validator a qualquer momento apenas baixaram localmente um subconjunto de o estado que corresponde a algum subconjunto dos fragmentos, e apenas processar e validar transações que afetam essas partes do estado. Para se tornar um produtor de blocos, um participante da rede bloqueia alguns grandes quantidade de tokens (uma aposta). A manutenção da rede é feita em épocas, onde uma época é um período de tempo da ordem de dias. Os participantes com as maiores apostas no início de uma época específica são o bloco produtores daquela época. Cada produtor de bloco é atribuído a fragmentos sw (digamos sw = 40, o que tornaria sww/n = 4 produtores de blocos por fragmento). O bloco o produtor baixa o estado do fragmento ao qual foi atribuído antes da época começa e, ao longo da época, coleta transações que afetam esse fragmento, e os aplica ao estado. Para cada bloco b na cadeia principal, e para cada fragmento s, há um dos atribuiu produtores de blocos a s, que é responsável por produzir a parte de b relacionada para o fragmento. A parte de b relacionada ao shard s é chamada de chunk e contém o lista das transações do shard a serem incluídas em b, bem como o merkleraiz do estado resultante. b acabará por conter apenas um cabeçalho muito pequeno de o pedaço, ou seja, a raiz merkle de todas as transações aplicadas (veja a seção 3.7.1 para detalhes exatos) e a raiz Merkle do estado final. Ao longo do restante do documento, frequentemente nos referimos ao produtor do bloco que é responsável por produzir um pedaço em um determinado momento para um determinado fragmento como produtor de pedaços. O produtor de pedaços é sempre um dos produtores de blocos. Os produtores de blocos e os produtores de pedaços giram cada bloco de acordo a um horário fixo. Os produtores de blocos têm um pedido e produzem repetidamente blocos nessa ordem. Por exemplo se houver 100 produtores de blocos, o primeiro bloco produtores é responsável pela produção dos blocos 1, 101, 201 etc, o segundo é responsável pela produção de 2, 102, 202 etc). Como a produção de pedaços, ao contrário da produção de blocos, exige a manutenção o estado, e para cada fragmento apenas os produtores de blocos sww/n mantêm o estado por fragmento, correspondentemente apenas os produtores de blocos sww/n giram para criar pedaços. Por exemplo com as constantes acima com quatro produtores de blocos atribuídos a cada fragmento, cada produtor de bloco criará pedaços uma vez a cada quatro blocos. 3.4 Garantindo a disponibilidade dos dados Para garantir a disponibilidade dos dados, usamos uma abordagem semelhante à de Polkadot descrito na seção 2.5.3. Depois que um produtor de bloco produz um pedaço, ele cria uma versão codificada para eliminação com um código de bloco ideal (w, ⌊w/6 + 1⌋) do pedaço. Eles então enviam um pedaço do pedaço codificado para eliminação (chamamos esses pedaços partes de pedaços, ou apenas partes) para cada produtor de bloco. Calculamos uma árvore Merkle que contém todas as partes como as folhas e as o cabeçalho de cada pedaço contém a raiz merkle dessa árvore. As peças são enviadas para validators por meio de mensagens onepart. Cada uma dessas mensagens contém o cabeçalho do bloco, o ordinal da parte e o conteúdo da parte. O mensagem também contém a assinatura do produtor do bloco que produziu o chunk e o caminho merkle para provar que a parte corresponde ao cabeçalho e é produzido pelo produtor de bloco adequado. Uma vez que um produtor de bloco recebe um bloco da cadeia principal, ele primeiro verifica se ele tenha mensagens únicas para cada pedaço incluído no bloco. Caso contrário, o bloco não é processado até que as mensagens onepart ausentes sejam recuperadas. Uma vez recebidas todas as mensagens onepart, o produtor do bloco busca o partes restantes dos pares e reconstrói os pedaços para os quais eles mantêm o estado. O produtor do bloco não processa um bloco da cadeia principal se por pelo menos um pedaço incluído no bloco eles não têm a mensagem onepart correspondente, ou se pelo menos um shard para o qual eles mantêm o estado eles não podem reconstruir todo o pedaço. Para que um determinado pedaço esteja disponível basta que ⌊w/6⌋+1 do bloco os produtores têm suas partes e as servem. Assim, enquanto o número de atores maliciosos não excedem ⌊w/3⌋nenhuma cadeia que tenha mais da metade do bloco os produtores que o constroem podem ter pedaços indisponíveis.Figura 17: Cada bloco contém um ou zero pedaços por fragmento, e cada pedaço é codificado para eliminação. Cada parte do pedaço codificado para eliminação é enviada para um determinado produtor de bloco através de uma mensagem especial onepart 3.4.1 Lidando com produtores de blocos preguiçosos Se um produtor de bloco tiver um bloco para o qual falta uma mensagem onepart, ele pode optar por ainda assiná-lo, porque se o bloco acabar sendo encadeado, maximizará a recompensa para o produtor do bloco. Não há risco para o bloqueio produtor, uma vez que é impossível provar posteriormente que o produtor do bloco não tinha a mensagem de uma parte. Para resolver isso, tornamos cada pedaço produtor ao criar o pedaço para escolha uma cor (vermelho ou azul) para cada parte do futuro bloco codificado e armazene a máscara de bits da cor atribuída no pedaço antes de ser codificada. Cada parte mensagem então contém a cor atribuída à peça, e a cor é usada quando calcular a raiz merkle das partes codificadas. Se o produtor do pedaço se desviar do protocolo, isso pode ser facilmente comprovado, já que a raiz merkle não correspondem a mensagens de uma parte ou às cores nas mensagens de uma parte que corresponder à raiz merkle não corresponderá à máscara no pedaço. Quando um produtor de bloco assina um bloco, ele inclui uma máscara de bits de todos os peças vermelhas que receberam pelos pedaços incluídos no bloco. Publicando um máscara de bits incorreta é um comportamento que pode ser cortado. Se um produtor de bloco não tiver recebido um mensagem única, eles não têm como saber a cor da mensagem e portanto, têm 50% de chance de serem cortados se tentarem assinar cegamente o bloco. 3.5 Pedido de transição de estado Os produtores de pedaços escolhem apenas quais transações incluir no pedaço, mas não aplique a transição de estado quando produzirem um pedaço. Correspondentemente,

o cabeçalho do bloco contém a raiz merkle do estado merkelizado de antes as transações no bloco são aplicadas. As transações só são aplicadas quando um bloco completo que inclui o pedaço é processado. Um participante só processa um bloco se 1. O bloco anterior foi recebido e processado; 2. Para cada pedaço, o participante não mantém o estado, pois possui vi a mensagem única; 3. Para cada pedaço, o participante mantém o estado, pois tem o pedaço inteiro. Depois que o bloco estiver sendo processado, para cada fragmento para o qual o participante mantém o estado, eles aplicam as transações e calculam o novo estado a partir da aplicação das transações, após o que elas estarão prontas para produzir os pedaços para o próximo bloco, se eles forem atribuídos a qualquer shard, uma vez que eles têm a raiz merkle do novo estado merkelizado. 3.6 Transações e recebimentos entre fragmentos Se uma transação precisar afetar mais de um fragmento, ela precisará ser consecutivamente executado em cada fragmento separadamente. A transação completa é enviada para o primeiro fragmento afetado, e uma vez que a transação é incluída no pedaço para tal fragmento, e é aplicado depois que o pedaço é incluído em um bloco, ele gera um chamado recibo transação, que é roteada para o próximo shard no qual a transação precisa ser executado. Se forem necessárias mais etapas, a execução da transação de recebimento gera uma nova transação de recebimento e assim por diante. 3.6.1 Vida útil da transação de recebimento É desejável que a transação de recebimento seja aplicada no bloco imediatamente seguinte ao bloco em que foi gerada. A transação de recebimento é apenas gerado após o bloco anterior ter sido recebido e aplicado pelos produtores do bloco que mantêm o fragmento de origem e precisa ser conhecido no momento em que o pedaço para o próximo bloco é produzido pelos produtores de bloco do destino fragmento. Assim, o recebimento deve ser comunicado do fragmento de origem ao fragmento de destino no curto período entre esses dois eventos. Seja A o último bloco produzido que contém uma transação t que gera um recibo r. Seja B o próximo bloco produzido (ou seja, um bloco que tem A como seu bloco anterior) que queremos conter r. Seja t no fragmento a e r no fragmento b. O tempo de vida do recibo, também representado na figura 18, é o seguinte: Produzir e armazenar os recibos. O CPA do produtor de pedaços para shard a recebe o bloco A, aplica a transação t e gera o recibo r. cpa em seguida, armazena todos esses recibos produzidos em seu armazenamento interno persistente indexado pelo ID do fragmento de origem.Distribuindo as receitas. Quando o cpa estiver pronto para produzir o pedaço para fragmento a para o bloco B, eles buscam todos os recibos gerados pela aplicação das transações do bloco A para o fragmento a e os incluem no bloco do fragmento a no bloco B. Uma vez gerado esse pedaço, cpa produz seu apagamento codificado versão e todas as mensagens onepart correspondentes. cpa sabe quais produtores de blocos mantêm o estado completo para quais fragmentos. Para um determinado produtor de blocos bp cpa inclui os recebimentos resultantes da aplicação de transações do bloco A para o fragmento a que possui qualquer um dos fragmentos com os quais bp se preocupa como destino na mensagem onepart quando eles distribuíram o pedaço para o fragmento A no bloco B (veja a figura 17, que mostra os recibos incluídos na mensagem onepart). Recebendo os recibos. Lembre-se de que os participantes (produtores de bloco e validators) não processam blocos até que tenham mensagens de uma parte para cada pedaço incluído no bloco. Assim, no momento em que qualquer participante em particular aplica o bloco B, ele possui todas as mensagens de uma parte que correspondem a pedaços em B e, portanto, eles têm todas as receitas recebidas que possuem os fragmentos o participante mantém o estado como destino. Ao aplicar o transição de estado para um fragmento específico, o participante aplica ambos os recibos que eles coletaram para o fragmento nas mensagens únicas, bem como todos as transações incluídas no próprio pedaço. Figura 18: A vida útil de uma transação de recebimento 3.6.2 Lidando com muitos recibos É possível que o número de recibos direcionados a um fragmento específico em um determinado bloco é muito grande para ser processado. Por exemplo, considere a figura 19, em em que cada transação em cada fragmento gera um recibo direcionado ao fragmento 1. No próximo bloco, o número de recibos que o fragmento 1 precisa processar é comparável à carga que todos os fragmentos combinados processaram durante o manuseio o bloco anterior.

Figura 19: Se todos os recibos forem direcionados ao mesmo fragmento, o fragmento poderá não ter a capacidade de processá-los Para resolver isso usamos uma técnica semelhante à usada no QuarkChain 9. Especificamente, para cada fragmento, o último bloco B e o último fragmento s dentro desse é registrado o bloco a partir do qual os recebimentos foram aplicados. Quando o novo fragmento for criado, os recibos são aplicados em ordem primeiro a partir dos fragmentos restantes em B, e depois nos blocos que seguem B, até que o novo pedaço esteja cheio. Sob normal circunstâncias com uma carga equilibrada, geralmente resultará em todos os recebimentos sendo aplicado (e assim o último fragmento do último bloco será gravado para cada pedaço), mas durante momentos em que a carga não está equilibrada e um determinado shard recebe muitas receitas desproporcionalmente, esta técnica permite que eles ser processado respeitando os limites do número de transações incluídas. Observe que se tal carga desequilibrada permanecer por muito tempo, o atraso de a criação de recibos até que a aplicação possa continuar crescendo indefinidamente. Um maneira de resolver isso é descartar qualquer transação que crie um recibo direcionado a um fragmento que possui um atraso de processamento que excede alguma constante (por exemplo, uma época). Considere a figura 20. No bloco B, o fragmento 4 não pode processar todos os recibos, portanto, ele processa apenas a origem de recibos de até o fragmento 3 no bloco A, e registra isso. No bloco C estão incluídos os recibos até o fragmento 5 do bloco B, e então, no bloco D, o fragmento alcança, processando todos os recibos restantes em bloco B e todas as receitas do bloco C. 3.7 Validação de pedaços Um pedaço produzido para um shard específico (ou um bloco de shard produzido para uma cadeia de shard específica no modelo com cadeias de shard) só pode ser validado pelo 9Veja o episódio do quadro branco com QuarkChain aqui: https://www.youtube.com/watch? v=opEtG6NM4x4, em que a abordagem para transações entre fragmentos é discutida, entre outros coisasFigura 20: Processamento de recibos atrasado participantes que mantêm o estado. Eles podem ser produtores de blocos, validators, ou apenas testemunhas externas que baixaram o estado e validaram o fragmento em quais eles armazenam ativos. Neste documento assumimos que a maioria dos participantes não consegue armazenar o estado para uma grande fração dos fragmentos. Vale ressaltar, porém, que existem blockchains fragmentados que são projetados com a suposição de que a maioria dos participantes tem capacidade de armazenar o estado e validar a maioria dos os fragmentos, como QuarkChain. Como apenas uma fração dos participantes tem estado para validar o fragmento pedaços, é possível corromper adaptativamente apenas os participantes que têm o estado e aplicar uma transição de estado inválida. Vários designs de fragmentação foram propostos para amostrar validators a cada poucos dias e dentro de um dia qualquer bloco na cadeia de fragmentos que tenha mais de 2/3 de assinaturas dos validators atribuídos a tal fragmento é imediatamente considerada final. Com tal abordagem, um adversário adaptativo só precisa corromper 2n/3+1 dos validators em uma cadeia de fragmentos para aplicar uma transição de estado inválida, que, embora seja provavelmente difícil de conseguir, não é um nível de segurança suficiente para um público blockchain. Conforme discutido na seção 2.3, a abordagem comum é permitir uma certa janela de tempo após a criação de um bloco para qualquer participante que tenha estado (seja é um produtor de bloco, um validator ou um observador externo) para desafiar sua validade. Esses participantes são chamados de Pescadores. Para que um pescador possa desafiar um bloco inválido, deve-se garantir que tal bloco esteja disponível para eles. A disponibilidade de dados no Nightshade é discutida na seção 3.4. No Nightshade, uma vez produzido um bloco, os pedaços não foram validados pelo qualquer um, exceto o próprio produtor do pedaço. Em particular, o produtor de blocos que sugeriu que o bloco naturalmente não tinha o estado para a maioria dos fragmentos, enão foi capaz de validar os pedaços. Quando o próximo bloco é produzido, ele contém atestados (ver seção 3.2) de múltiplos produtores de blocos e validators, mas como a maioria dos produtores de blocos e validators não mantêm o estado também para a maioria dos shards, um bloco com apenas um pedaço inválido coletará significativamente mais da metade dos atestados e continuará sendo o bloco mais pesado. cadeia. Para resolver esse problema, permitimos que qualquer participante que mantenha o estado de um fragmento para enviar um desafio na cadeia para qualquer pedaço inválido produzido naquele fragmento. 3.7.1 Desafio de validade do estado Depois que um participante detecta que um determinado pedaço é inválido, ele precisa fornecer uma prova de que o pedaço é inválido. Como a maioria dos participantes da rede não mantém o estado do fragmento no qual o pedaço inválido está produzido, a prova precisa ter informações suficientes para confirmar que o bloco é inválido sem ter o estado. Definimos um limite Ls da quantidade de estado (em bytes) que uma única transação pode ler ou escrever cumulativamente. Qualquer transação que toque mais de Ls estado é considerado inválido. Lembre-se da seção 3.5 que o pedaço em um determinado bloco B contém apenas as transações a serem aplicadas, mas não a nova raiz do estado. A raiz de estado incluída no pedaço do bloco B é o estado root antes de aplicar tais transações, mas depois de aplicar as transações de o último pedaço no mesmo fragmento antes do bloco B. Um ator malicioso que deseja aplicar uma transição de estado inválida incluiria uma raiz de estado incorreta no bloco B que não corresponde à raiz de estado resultante da aplicação as transações no bloco anterior. Estendemos as informações que um produtor de pedaços inclui no pedaço. Em vez de incluir apenas o estado depois de aplicar todas as transações, inclui uma raiz de estado após aplicar cada conjunto contíguo de transações que ler e escrever coletivamente Ls bytes de estado. Com essas informações para pescador criar o desafio de que uma transição de estado seja aplicada incorretamente, é suficiente para encontrar a primeira raiz de estado inválida e incluir apenas Ls bytes de estado que são afetados pelas transações entre a última raiz de estado (que foi válido) e a raiz do estado atual com as provas Merkle. Então qualquer participante pode validar as transações no segmento e confirmar que o pedaço está inválido. Da mesma forma, se o produtor do bloco tentasse incluir transações que leem e escrever mais de Ls bytes de estado, para o desafio basta incluir os primeiros Ls bytes que ele toca com as provas merkle, o que será suficiente para aplicar as transações e confirmar que há um momento em que uma tentativa de é feita a leitura ou gravação de conteúdo além de Ls bytes.

3.7.2 Pescadores e transações rápidas entre fragmentos Conforme discutido na seção 2.3, uma vez que assumimos que os pedaços de fragmento (ou fragmentos blocos no modelo com cadeias de fragmentos) podem ser inválidos e apresentar um desafio período, isso afeta negativamente a finalidade e, portanto, a comunicação entre fragmentos. Em em particular, o fragmento de destino de qualquer transação entre fragmentos não pode ser certo o fragmento ou bloco de origem é final até que o período de desafio termine (ver figura 21). Figura 21: Aguardando o período de desafio antes de aplicar um recibo A maneira de lidar com isso de uma forma que torne as transações entre fragmentos Instantâneo é para o fragmento de destino não esperar pelo período do desafio após a transação do fragmento de origem ser publicada e aplicar a transação de recebimento imediatamente, mas depois reverta o fragmento de destino junto com o fragmento de origem fragmento se posteriormente o pedaço ou bloco de origem for considerado inválido (veja a figura 22). Isso se aplica muito naturalmente ao design do Nightshade, no qual o fragmento as cadeias não são independentes, mas em vez disso, os fragmentos são todos publicados juntos no mesmo bloco da cadeia principal. Se algum pedaço for considerado inválido, o bloco inteiro com esse pedaço é considerado inválido e todos os blocos construídos nele topo disso. Veja a figura 23. Ambas as abordagens acima fornecem atomicidade, assumindo que o desafio período é suficientemente longo. Usamos a última abordagem, uma vez que fornecer transações cruzadas rápidas em circunstâncias normais supera a inconveniência de o fragmento de destino sendo revertido devido a uma transição de estado inválida em um dos os fragmentos de origem, o que é um evento extremamente raro. 3.7.3 Escondendo validators A existência dos desafios já reduz significativamente a probabilidade de corrupção adaptativa, já que para finalizar um pedaço com uma transição de estado inválida posteFigura 22: Aplicando recibos imediatamente e revertendo o destino cadeia se a cadeia de origem tiver um bloco inválido Figura 23: Desafio do pescador em Nightshade o período de desafio que o adversário adaptativo precisa para corromper todos os participantes que mantêm o estado do fragmento, incluindo todos os validators. Estimar a probabilidade de tal evento é extremamente complexo, uma vez que não sharded blockchain está ativo há tempo suficiente para que qualquer ataque desse tipo seja tentado. Argumentamos que a probabilidade, embora extremamente baixa, ainda é suficientemente grande para um sistema que deverá executar milhões de transações e executar operações financeiras em todo o mundo. Existem duas razões principais para esta crença: 1. A maioria dos validators das redes de Prova de Participação e mineradores do

As cadeias de prova de trabalho são incentivadas principalmente pela vantagem financeira. Se um adversário adaptativo oferece-lhes mais dinheiro do que o retorno esperado de operar honestamente, é razoável esperar que muitos validators aceitará a oferta. 2. Muitas entidades validam cadeias de Prova de Participação profissionalmente e espera-se que uma grande percentagem da participação em qualquer cadeia seja de tais entidades. O número de tais entidades é suficientemente pequeno para uma adversário adaptativo para conhecer a maioria deles pessoalmente e ter uma boa compreensão de sua inclinação para serem corrompidos. Damos um passo adiante na redução da probabilidade de corrupção adaptativa, ocultando quais validators estão atribuídos a qual fragmento. A ideia é remotamente semelhante à maneira como Algorand [5] esconde validators. É fundamental observar que mesmo que os validators estejam ocultos, como em Algorand ou conforme descrito abaixo, a corrupção adaptativa ainda é, em teoria, possível. Enquanto o adversário adaptativo não conhece os participantes que irão criar ou validar um bloco ou pedaço, os próprios participantes sabem que irão realizar tal tarefa e ter uma prova criptográfica disso. Assim, o adversário pode transmitir sua intenção de corromper e pagar a qualquer participante que forneça tal prova criptográfica. Notamos, no entanto, que como o adversário não conhecem os validators atribuídos ao fragmento que desejam corromper, eles não têm outra escolha a não ser transmitir sua intenção de corromper um fragmento específico para toda a comunidade. Nesse ponto, é economicamente benéfico para qualquer pessoa honesta. participante para criar um nó completo que valide esse fragmento, já que há um alto chance de um bloco inválido aparecer naquele fragmento, o que é uma oportunidade para crie um desafio e receba a recompensa associada. Para não revelar os validators atribuídos a um fragmento específico, fazemos o seguinte (ver figura 24): Usando VRF para obter a tarefa. No início de cada época cada validator usa um VRF para obter uma máscara de bits dos fragmentos aos quais validator está atribuído. A máscara de bits de cada validator terá bits Sw (veja seção 3.3 para a definição de Sw). O validator então busca o estado dos fragmentos correspondentes e durante a época para cada bloco recebido valida os pedaços que correspondem aos fragmentos aos quais validator está atribuído. Assine em blocos em vez de pedaços. Como a atribuição de fragmentos está oculta, validator não pode assinar fragmentos. Em vez disso, ele sempre assina por completo bloco, não revelando assim quais fragmentos ele valida. Especificamente, quando validator recebe um bloco e valida todos os pedaços, ele cria uma mensagem que atesta que todos os pedaços em todos os fragmentos aos quais validator está atribuído são válido (sem indicar de forma alguma quais são esses fragmentos) ou uma mensagem que contém uma prova de uma transição de estado inválida se algum pedaço for inválido. Veja o seção 3.8 para detalhes sobre como essas mensagens são agregadas, seção 3.7.4 para os detalhes sobre como evitar que validators pegue carona em mensagens de outros validators e seção 3.7.5 para detalhes sobre como recompensar e punir validators caso um desafio de transição de estado inválido bem-sucedido realmente aconteça.Figura 24: Escondendo os validators no Nightshade 3.7.4 Comprometer-Revelar Um dos problemas comuns com validators é que um validator pode pular o download do estado e realmente validar os pedaços e blocos e, em vez disso, observe a rede, veja o que os outros validators enviam e repita seus mensagens. Um validator que segue tal estratégia não fornece nenhum extra segurança para a rede, mas coleta recompensas. Uma solução comum para este problema é cada validator fornecer uma prova que eles realmente validaram o bloco, por exemplo, fornecendo um rastreamento exclusivo de aplicar a transição de estado, mas tais provas aumentam significativamente o custo de validação. Figura 25: Confirmar-revelar

Em vez disso, fazemos com que os validators primeiro se comprometam com o resultado da validação (seja a mensagem que atesta a validade dos pedaços, ou a prova de um inválido transição de estado), aguarde um determinado período, e só então revele o resultado real da validação, conforme mostrado na figura 25. O período de commit não se cruza com o período de revelação e, portanto, um validator preguiçoso não pode copiar validators honestos. Além disso, se um validator desonesto se comprometeu com uma mensagem que atesta a validade dos pedaços atribuídos, e pelo menos um pedaço era inválido, uma vez que é mostrado que o pedaço é inválido, o validator não pode evitar a redução, pois, como mostramos na seção 3.7.5, a única maneira de não ser cortado em tal situação é apresentar uma mensagem que contenha uma prova da transição de estado inválida que corresponde ao commit. 3.7.5 Lidando com desafios Conforme discutido acima, uma vez que um validator recebe um bloco com um pedaço inválido, eles primeiro preparam uma prova da transição de estado inválida (ver seção 3.7.1), depois comprometa-se com tal prova (ver 3.7.4) e, após algum período, revele o desafio. Uma vez que o desafio revelado é incluído em um bloco, acontece o seguinte: 1. Todas as transições de estado que aconteceram no bloco que contém o pedaço inválido até que o bloco no qual o desafio revelado está incluído seja obtido anulado. O estado antes do bloco que inclui o desafio revelado é considerado o mesmo que o estado antes do bloco que continha o pedaço inválido. 2. Dentro de um determinado período de tempo cada validator deve revelar sua bitmask dos fragmentos que eles validam. Como a máscara de bits é criada através de um VRF, se eles foram atribuídos ao fragmento que tinha a transição de estado inválida, eles não pode evitar revelá-lo. Qualquer validator que não revele a máscara de bits é considerado atribuído ao fragmento. 3. Cada validator que após esse período for atribuído ao shard, que se comprometeu com algum resultado de validação para o bloco que contém o pedaço inválido e que não revelou a prova de transição de estado inválida que corresponde ao seu commit é cortado. 4. Cada validator recebe uma nova atribuição de fragmentos e uma nova época é agendada para começar depois de algum tempo suficiente para que todos os validators baixem o estado, conforme mostrado na figura 26. Observe que a partir do momento em que os validators revelam os fragmentos aos quais são atribuídos até que a nova época comece, a segurança do sistema é reduzida, uma vez que o a atribuição de fragmentos é revelada. Os participantes da rede precisam mantê-la em mente ao usar a rede durante esse período. 3.8 Agregação de Assinatura Para que um sistema com centenas de fragmentos opere com segurança, queremos ter no ordem de 10.000 ou mais validators. Conforme discutido na seção 3.7, queremos que cadaFigura 26: Lidando com o desafio validator para publicar um commit para uma determinada mensagem e uma assinatura em média uma vez por bloco. Mesmo que as mensagens de commit fossem as mesmas, agregar tal A assinatura BLS e sua validação teriam sido proibitivamente caras. Mas naturalmente, as mensagens de confirmação e revelação não são as mesmas em validators, e, portanto, precisamos de alguma forma de agregar essas mensagens e as assinaturas em um maneira que permite uma validação rápida posteriormente. A abordagem específica que usamos é a seguinte: Validadores juntando-se aos produtores de blocos. Os produtores de blocos são conhecidos algum tempo antes do início da época, pois eles precisam de algum tempo para baixar o estado antes do início da época e, ao contrário dos validators, os produtores de blocos são não escondido. Cada produtor de bloco possui v validator slots. Validadores enviam propostas fora da cadeia aos produtores de blocos para serem incluídos como um de seus v validators. Se um produtor de bloco desejar incluir um validator, ele enviará um transação que contém a solicitação inicial fora da cadeia do validator e o assinatura do produtor do bloco que faz com que validator se junte ao produtor do bloco. Observe que os validators atribuídos aos produtores de blocos não necessariamente valide os mesmos fragmentos para os quais o produtor do bloco produz pedaços. Se um validator aplicado para ingressar em vários produtores de blocos, apenas a transação de o primeiro produtor de bloco terá sucesso. Os produtores de blocos coletam commits. O produtor do bloco coleta constantemente as mensagens de commit e revelação dos validators. Uma vez que um certo número dessas mensagens é acumulado, o produtor do bloco calcula um Merkle árvore dessas mensagens e envia para cada validator a raiz merkle e o merkle caminho para sua mensagem. O validator valida o caminho e faz login a raiz de merkle. O produtor do bloco então acumula uma assinatura BLS no raiz merkle de validators e publica apenas a raiz merkle e o assinatura acumulada. O produtor do bloco também assina a validade do multiassinatura usando uma assinatura ECDSA barata. Se a assinatura múltipla não corresponder à raiz merkle enviada ou à máscara de bits dos validators participantes, é um comportamento que pode ser cortado. Ao sincronizar a cadeia, um participante pode optar por validar todas as assinaturas BLS dos validators (o que é extremamente caro, pois envolve a agregação de chaves públicas de validators), ou apenasas assinaturas ECDMA dos produtores de blocos e contam com o fato de que o o produtor do bloco não foi desafiado e cortado. Usando transações on-chain e provas Merkle para desafios. Isso pode-se notar que não há valor em revelar mensagens de validators se não transição de estado inválida foi detectada. Somente as mensagens que contêm o real provas de transição de estado inválida precisam ser reveladas, e apenas para tais mensagens é preciso mostrar que eles correspondem ao commit anterior. A mensagem precisa ser revelado para dois propósitos: 1. Para realmente iniciar a reversão da cadeia para o momento anterior ao transição de estado inválida (ver seção 3.7.5). 2. Para provar que o validator não tentou atestar a validade do pedaço inválido. Em ambos os casos, precisamos abordar duas questões: 1. O commit real não foi incluído na cadeia, apenas a raiz merkle do commit agregado com outras mensagens. O validator precisa usar o caminho merkle fornecido pelo produtor do bloco e seu compromisso original com provar que eles se comprometeram com o desafio. 2. É possível que todos os validators atribuídos ao fragmento com o inválido transição de estado foi atribuída a produtores de blocos corrompidos que estão censurando-os. Para contornar isso, permitimos que eles enviem suas revelações como uma transação regular on-chain e ignorar a agregação. Este último só é permitido para as provas de transição de estado inválida, que são extremamente raro e, portanto, não deve resultar em spam nos blocos. A questão final que precisa ser abordada é que os produtores de blocos podem optar por não participar da agregação de mensagens ou censurar intencionalmente determinados validators. Tornamo-lo economicamente desvantajoso, ao tornar o bloco recompensa do produtor proporcional ao número de validators atribuídos a eles. Nós observe também que, uma vez que os produtores de blocos entre épocas se cruzam amplamente (já que são sempre os principais participantes com a aposta mais alta), os validators podem em grande parte, limitar-se a trabalhar com os mesmos produtores de blocos e, assim, reduzir o risco de serem atribuídos a um produtor de blocos que os censurou no passado. 3.9 Cadeia de instantâneos Como os blocos da cadeia principal são produzidos com muita frequência, o download o histórico completo pode ficar caro muito rapidamente. Além disso, uma vez que cada bloco contém uma assinatura BLS de um grande número de participantes, apenas a agregação das chaves públicas para verificar a assinatura pode se tornar proibitiva caro também. Finalmente, uma vez que em qualquer futuro previsível Ethereum 1.0 provavelmente permanecerá um dos blockchains mais usados, tendo uma maneira significativa de transferir ativos de

Perto de Ethereum é um requisito, e hoje verificar assinaturas BLS para garantir A validade de quase blocos no lado de Ethereum não é possível. Cada bloco na cadeia principal do Nightshade pode conter opcionalmente um Schnorr multiassinatura no cabeçalho do último bloco que incluía tal Schnorr multiassinatura. Chamamos esses blocos de blocos instantâneos. O primeiro bloco de cada época deve ser um bloco de instantâneo. Enquanto trabalhava em tal assinatura múltipla, os produtores de blocos também devem acumular as assinaturas BLS dos validators no último bloco de instantâneo e agregue-os da mesma maneira descrita em seção 3.8. Como o conjunto de produtores de blocos é constante ao longo da época, validando apenas os primeiros blocos de instantâneos em cada época são suficientes, assumindo que em nenhum momento apontam que uma grande porcentagem de produtores de blocos e validators conspiraram e criaram um garfo. O primeiro bloco da época deve conter informações suficientes para calcular os produtores de blocos e validators para a época. Chamamos a subcadeia da cadeia principal que contém apenas o instantâneo bloqueia uma cadeia de instantâneos. Criar uma multiassinatura Schnorr é um processo interativo, mas como só precisa executá-lo com pouca frequência, qualquer processo, não importa quão ineficiente, será suficiente. As multiassinaturas Schnorr podem ser facilmente validadas em Ethereum, fornecendo assim primitivas cruciais para uma maneira segura de realizar cross-blockchain comunicação. Para sincronizar com a cadeia Near, basta baixar todos os instantâneos blocos e confirme se as assinaturas Schnorr estão corretas (opcionalmente também verificando as assinaturas BLS individuais dos validators) e, em seguida, apenas sincronizando blocos da cadeia principal do último bloco de snapshot.

Nightshade

3.1 Dari rantai pecahan hingga pecahan pecahan Model sharding dengan rantai shard dan rantai suar sangat kuat namun mempunyai kompleksitas tertentu. Secara khusus, aturan pilihan garpu perlu dijalankan di setiap rantai secara terpisah, aturan pilihan garpu di rantai pecahan dan suar rantai harus dibuat secara berbeda dan diuji secara terpisah. Di Nightshade kami memodelkan sistem sebagai blockchain tunggal, yang masing-masingnya blok secara logis berisi semua transaksi untuk semua pecahan, dan mengubah seluruh keadaan dari semua pecahan. Namun secara fisik, tidak ada peserta yang mengunduhnya keadaan penuh atau blok logis penuh. Sebaliknya, masing-masing peserta jaringan saja mempertahankan status yang sesuai dengan pecahan yang transaksinya divalidasi, dan daftar semua transaksi di blok dibagi menjadi fisik potongan, satu potongan per pecahan. Dalam kondisi ideal, setiap blok berisi tepat satu bongkahan per pecahan per blok, yang kira-kira sesuai dengan model dengan rantai pecahan di mana rantai pecahan menghasilkan balok dengan kecepatan yang sama dengan rantai suar. Namun, karena penundaan jaringan, beberapa bagian mungkin hilang, jadi dalam praktiknya setiap blok berisi satu atau nol potongan per pecahan. Lihat bagian 3.3 untuk rincian tentang caranya blok diproduksi. Gambar 16: Model dengan rantai pecahan di sebelah kiri dan memiliki satu rantai blok terbelah menjadi beberapa bagian di sebelah kanan

3.2 Konsensus Dua pendekatan dominan terhadap konsensus di blockchains saat ini adalah rantai terpanjang (atau terberat), yaitu rantai yang mempunyai pekerjaan atau pasak paling banyak digunakan untuk membangunnya dianggap kanonik, dan BFT, di mana untuk setiap blok beberapa kumpulan validator mencapai konsensus BFT. Dalam protokol yang diusulkan baru-baru ini, pendekatan terakhir adalah pendekatan yang lebih dominan, karena hal ini memberikan penyelesaian langsung, sedangkan pada rantai terpanjang dibutuhkan lebih banyak blok untuk dibangun di atas blok untuk memastikan finalitas. Seringkali untuk sesuatu yang bermakna keamanan waktu yang dibutuhkan untuk membangun jumlah blok yang cukup urutan jam. Penggunaan konsensus BFT pada setiap blok juga memiliki kelemahan, seperti: 1. BFT konsensus melibatkan banyak komunikasi. Sementara kemajuan terkini memungkinkan konsensus dicapai dalam jumlah waktu yang linier peserta (lihat misalnya [4]), masih terlihat biaya overhead per blok; 2. Tidak mungkin semua peserta jaringan berpartisipasi dalam BFT konsensus per blok, sehingga biasanya hanya sebagian peserta yang diambil sampelnya secara acak yang mencapai konsensus. Himpunan sampel yang diambil secara acak, pada prinsipnya, dapat berupa dirusak secara adaptif, dan sebuah percabangan dalam teori dapat tercipta. Sistem keduanya perlu dicontohkan agar siap menghadapi peristiwa semacam itu, dan dengan demikian tetap saja memiliki aturan pilihan bercabang selain konsensus BFT, atau dirancang untuk ditutup turun dalam acara seperti itu. Perlu disebutkan bahwa beberapa desain, seperti Algorand [5], secara signifikan mengurangi kemungkinan korupsi adaptif. 3. Yang terpenting, sistem terhenti jika 1 3 atau lebih dari semua peserta adalah offline. Oleh karena itu, kesalahan jaringan sementara atau perpecahan jaringan dapat menghentikan sistem sepenuhnya. Idealnya sistem harus dapat terus berjalan beroperasi selama setidaknya setengah dari peserta sedang online (yang terberat protokol berbasis rantai terus beroperasi meskipun kurang dari separuh peserta sedang online, namun keinginan akan properti ini masih bisa diperdebatkan dalam komunitas). Model hibrida yang menggunakan konsensus adalah model yang paling berat rantai, tetapi beberapa blok diselesaikan secara berkala menggunakan gadget finalitas BFT mempertahankan keunggulan kedua model. Gadget finalitas BFT seperti itu Casper FFG [6] digunakan di Ethereum 2.0 8, Casper CBC (lihat https://vitalik. ca/general/2018/12/05/cbc_casper.html) dan GRANDPA (lihat https:// medium.com/polkadot-network/d08a24a021b5) digunakan di Polkadot. Nightshade menggunakan konsensus rantai terberat. Khususnya ketika sebuah blok produsen memproduksi sebuah blok (lihat bagian 3.3), mereka dapat mengumpulkan tanda tangan darinya produsen blok lain dan validators membuktikan blok sebelumnya. Lihat bagian 3.8 untuk rincian bagaimana sejumlah besar tanda tangan dikumpulkan. Beratnya 8Lihat juga sesi papan tulis bersama Justin Drake untuk gambaran mendalam tentang Casper FFG, dan bagaimana integrasinya dengan konsensus rantai terberat GHOST di sini: https://www. youtube.com/watch?v=S262StTwkmosuatu blok kemudian merupakan saham kumulatif dari semua penandatangan yang memiliki tanda tangan tersebut termasuk dalam blok tersebut. Berat suatu rantai adalah jumlah dari berat balok. Di atas konsensus rantai terberat, kami menggunakan gadget finalitas yang digunakan pengesahan untuk menyelesaikan blok. Untuk mengurangi kompleksitas sistem, kami menggunakan gadget finalitas yang tidak mempengaruhi aturan pilihan garpu dengan cara apa pun, dan sebagai gantinya hanya memperkenalkan kondisi pemotongan tambahan, sehingga satu blok menjadi satu diselesaikan oleh gadget finalitas, percabangan tidak mungkin dilakukan kecuali persentasenya sangat besar dari total taruhannya dipotong. Casper CBC adalah gadget finalitas, dan kami saat ini menjadi model dengan mempertimbangkan Casper CBC. Kami juga mengerjakan protokol BFT terpisah yang disebut TxFlow. Pada saat saat menulis dokumen ini, tidak jelas apakah TxFlow akan digunakan sebagai pengganti Casper KBK. Namun kami mencatat bahwa pilihan gadget finalitas sebagian besar ortogonal terhadap desain lainnya. 3.3 Blokir produksi Di Nightshade ada dua peran: produser blok dan validators. Kapan saja titik sistem berisi produsen blok w, w = 100 dalam model kita, dan wv validators, dalam model kami v = 100, wv = 10, 000. Sistemnya adalah Proof-of-Stake, artinya produsen blok dan validator memiliki sejumlah internal mata uang (disebut ”tokens”) dikunci untuk durasi waktu yang jauh melebihi waktu yang mereka habiskan untuk melaksanakan tugas mereka membangun dan memvalidasi rantai. Seperti semua sistem Proof of Stake, tidak semua produsen blok w dan tidak semua wv validator adalah entitas yang berbeda, karena hal tersebut tidak dapat diterapkan. Masing-masing dari produsen blok w dan wv validators, bagaimanapun, memiliki yang terpisah taruhan. Sistem berisi n pecahan, n = 1000 dalam model kami. Seperti disebutkan dalam bagian 3.1, di Nightshade tidak ada rantai pecahan, sebagai gantinya semua produsen blok dan validator sedang membangun satu blockchain, yang kami sebut sebagai rantai utama. Keadaan rantai utama dibagi menjadi n pecahan, dan setiap blok produser dan validator setiap saat hanya mengunduh sebagian dari secara lokal keadaan yang sesuai dengan beberapa subset pecahan, dan hanya memproses dan memvalidasi transaksi yang mempengaruhi bagian negara bagian tersebut. Untuk menjadi produsen blok, peserta jaringan mengunci beberapa blok besar jumlah tokens (satu taruhan). Pemeliharaan jaringan dilakukan dalam jangka waktu tertentu, di mana suatu zaman adalah periode waktu dalam urutan hari. Para peserta dengan taruhan terbesar pada awal periode tertentu adalah blok produsen untuk zaman itu. Setiap produser blok ditugaskan ke sw shards, (misalnya sw = 40, yang berarti sww/n = 4 produsen blok per pecahan). Blok produser mengunduh status shard yang ditugaskan kepada mereka sebelum epoch dimulai, dan sepanjang epoch mengumpulkan transaksi yang memengaruhi pecahan itu, dan menerapkannya pada negara. Untuk setiap blok b pada rantai utama, dan untuk setiap pecahan s, terdapat salah satu darinya menugaskan produser blok ke s yang bertanggung jawab memproduksi bagian b terkait ke pecahan. Bagian b yang berhubungan dengan shard s disebut chunk, dan berisi daftar transaksi pecahan yang akan dimasukkan ke dalam b, serta merkleakar dari keadaan yang dihasilkan. b pada akhirnya hanya akan berisi header yang sangat kecil chunk yaitu akar merkle dari semua transaksi yang diterapkan (lihat bagian 3.7.1 untuk rincian yang tepat), dan akar merkle dari keadaan akhir. Sepanjang sisa dokumen ini kita sering merujuk pada produsen blok yang bertanggung jawab untuk menghasilkan potongan pada waktu tertentu untuk pecahan tertentu sebagai produsen bongkahan. Produser bongkahan selalu menjadi salah satu produsen blok. Produsen blok dan produsen bongkahan merotasi setiap blok sesuai ke jadwal yang tetap. Produsen blok mendapat pesanan dan memproduksi berulang kali blok dalam urutan itu. Misalnya. jika ada 100 produsen blok, blok pertama produsen bertanggung jawab untuk memproduksi blok 1, 101, 201 dst, yang kedua adalah bertanggung jawab untuk memproduksi 2, 102, 202 dll). Karena produksi potongan, tidak seperti produksi blok, memerlukan pemeliharaan negara bagian, dan untuk setiap shard hanya produsen blok sww/n yang mempertahankan negara bagian tersebut per pecahan, hanya produsen blok sww/n yang dirotasi untuk membuat potongan. Misalnya. dengan konstanta di atas dengan empat produsen blok yang ditugaskan setiap pecahan, setiap produsen blok akan membuat potongan setiap empat blok. 3.4 Memastikan ketersediaan data Untuk memastikan ketersediaan data kami menggunakan pendekatan yang serupa dengan Polkadot dijelaskan di bagian 2.5.3. Setelah produsen blok memproduksi suatu bongkahan, mereka menciptakannya versi kode penghapusan dengan kode blok optimal (w, ⌊w/6 + 1⌋) dari potongan. Mereka kemudian mengirimkan satu bagian dari potongan kode penghapusan (kami menyebutnya potongan tersebut bagian potongan, atau hanya bagian) ke setiap produsen blok. Kami menghitung pohon merkle yang berisi semua bagian seperti daun, dan header setiap potongan berisi akar merkle dari pohon tersebut. Bagian-bagian tersebut dikirim ke validators melalui pesan satu bagian. Setiap pesan tersebut berisi header potongan, urutan bagian, dan isi bagian. Itu pesan juga berisi tanda tangan produser blok yang memproduksinya chunk dan jalur merkle untuk membuktikan bahwa bagian tersebut sesuai dengan header dan diproduksi oleh produsen blok yang tepat. Setelah produsen blok menerima blok rantai utama, pertama-tama mereka memeriksa apakah sudah diterima memiliki pesan satu bagian untuk setiap potongan yang disertakan dalam blok. Jika tidak, blokir tidak diproses sampai pesan satu bagian yang hilang diambil. Setelah semua pesan satu bagian diterima, produser blok mengambil pesan tersebut bagian yang tersisa dari rekan-rekannya dan merekonstruksi bagian-bagian yang mereka pegang negara bagian. Produsen blok tidak memproses blok rantai utama jika setidaknya untuk satu blok potongan yang termasuk dalam blok tersebut tidak memiliki pesan satu bagian yang sesuai, atau jika setidaknya untuk satu pecahan yang statusnya dipertahankan, mereka tidak dapat merekonstruksi seluruh potongan. Agar potongan tertentu tersedia, cukup ⌊w/6⌋+1 blok tersebut produsen memiliki bagiannya dan melayaninya. Jadi, selama jumlahnya aktor jahat tidak melebihi ⌊w/3⌋tidak ada rantai yang memiliki lebih dari setengah blok produsen yang membangunnya mungkin memiliki bagian yang tidak tersedia.Gambar 17: Setiap blok berisi satu atau nol bongkahan per pecahan, dan setiap bongkahan adalah kode penghapusan. Setiap bagian dari potongan kode penghapusan dikirim ke tempat yang ditunjuk blok produser melalui pesan satu bagian khusus 3.4.1 Berurusan dengan produsen blok yang malas Jika produsen blok mempunyai blok yang pesan satu bagiannya hilang, mereka mungkin memilih untuk tetap menandatanganinya, karena jika blok itu akhirnya dirantai akan memaksimalkan imbalan bagi produsen blok. Tidak ada risiko untuk pemblokiran tersebut produsen blok karena tidak mungkin untuk membuktikan kemudian bahwa produsen blok tidak memilikinya pesan satu bagian. Untuk mengatasinya kita membuat setiap potongan menjadi produser saat membuat potongan tersebut pilih warna (merah atau biru) untuk setiap bagian dari potongan yang dikodekan di masa depan, dan simpan bitmask warna yang ditetapkan dalam potongan sebelum dikodekan. Masing-masing bagian pesan kemudian berisi warna yang ditetapkan ke bagian tersebut, dan warna tersebut digunakan saat menghitung akar merkle dari bagian yang dikodekan. Jika produsen bongkahan menyimpang dari protokolnya bisa dibuktikan dengan mudah, karena root merkle juga tidak sesuai dengan pesan satu bagian, atau warna dalam pesan satu bagian itu sesuai dengan akar merkle tidak akan cocok dengan topeng di potongan. Ketika produsen blok menandatangani sebuah blok, mereka menyertakan bitmask dari semuanya bagian merah yang mereka terima untuk bongkahan yang termasuk dalam blok. Penerbitan sebuah bitmask yang salah adalah perilaku yang dapat disayat. Jika produsen blok belum menerima a pesan satu bagian, mereka tidak tahu warna pesannya, dan sehingga memiliki peluang 50% untuk ditebas jika mereka mencoba menandatangani secara membabi buta blok. 3.5 Aplikasi transisi negara Produsen bongkahan hanya memilih transaksi mana yang akan dimasukkan ke dalam bongkahan tersebut jangan menerapkan transisi keadaan ketika mereka menghasilkan potongan. Sejalan dengan itu,

header chunk berisi root merkle dari status merkel seperti sebelumnya transaksi dalam potongan diterapkan. Transaksi hanya diterapkan bila blok penuh yang mencakup potongan sedang diproses. Seorang peserta hanya memproses satu blok jika 1. Blok sebelumnya telah diterima dan diproses; 2. Untuk setiap bagian, peserta tidak mempertahankan status yang mereka miliki melihat pesan satu bagian; 3. Untuk setiap bagian, peserta mempertahankan status yang mereka miliki potongan penuh. Setelah blok diproses, untuk setiap pecahan yang menjadi peserta mempertahankan statusnya, mereka menerapkan transaksi dan menghitung status baru terhitung setelah transaksi diterapkan, setelah itu siap berproduksi potongan untuk blok berikutnya, jika ditugaskan ke pecahan apa pun, karena sudah ada akar merkle dari negara merkel baru. 3.6 Transaksi dan penerimaan lintas pecahan Jika suatu transaksi perlu memengaruhi lebih dari satu shard, transaksi tersebut harus dilakukan secara berurutan dieksekusi di setiap pecahan secara terpisah. Transaksi lengkap dikirim ke pecahan pertama terpengaruh, dan setelah transaksi dimasukkan dalam potongan untuk pecahan tersebut, dan diterapkan setelah potongan dimasukkan ke dalam blok, itu menghasilkan apa yang disebut tanda terima transaksi, yang dialihkan ke pecahan berikutnya yang memerlukan transaksi dieksekusi. Jika diperlukan lebih banyak langkah, eksekusi transaksi penerimaan menghasilkan transaksi penerimaan baru dan seterusnya. 3.6.1 Penerimaan transaksi seumur hidup Sebaiknya transaksi penerimaan diterapkan di blok yang segera mengikuti blok tempat transaksi tersebut dihasilkan. Transaksi resinya saja dihasilkan setelah blok sebelumnya diterima dan diterapkan oleh produsen blok yang mempertahankan pecahan asal, dan perlu diketahui pada saat itu potongan untuk blok berikutnya diproduksi oleh produsen blok tujuan pecahan. Oleh karena itu, tanda terima harus dikomunikasikan dari pecahan sumber ke pecahan tujuan dalam jangka waktu singkat antara kedua peristiwa tersebut. Misalkan A adalah blok terakhir yang diproduksi yang berisi transaksi t yang menghasilkan tanda terima r. Misalkan B adalah blok yang diproduksi berikutnya (yaitu blok yang mempunyai A sebagai blok sebelumnya) yang ingin kita tampung r. Misalkan t berada di pecahan a dan r dalam pecahan b. Masa berlaku kuitansi, juga digambarkan pada gambar 18, adalah sebagai berikut: Memproduksi dan menyimpan kuitansi. Cpa produsen bongkahan untuk shard a menerima blok A, menerapkan transaksi t dan menghasilkan tanda terima r. cpa kemudian menyimpan semua penerimaan yang dihasilkan dalam penyimpanan persisten internal yang diindeks dengan id pecahan sumber.Mendistribusikan kuitansi. Setelah cpa siap untuk menghasilkan potongannya shard a untuk blok B, mereka mengambil semua tanda terima yang dihasilkan dengan menerapkan transaksi dari blok A untuk shard a, dan memasukkannya ke dalam potongan untuk shrad a di blok B. Setelah potongan tersebut dibuat, cpa menghasilkan kode penghapusannya versi dan semua pesan satu bagian yang terkait. cpa mengetahui produsen blok mana yang mempertahankan status penuh untuk pecahan mana. Untuk produsen blok tertentu bp cpa mencakup penerimaan yang dihasilkan dari penerapan transaksi di blok A untuk shard a yang memiliki salah satu shard yang dipedulikan bp sebagai tujuannya dalam pesan satu bagian ketika mereka mendistribusikan potongan untuk pecahan a di blok B (lihat gambar 17, yang menunjukkan tanda terima yang disertakan dalam pesan satu bagian). Menerima kuitansi. Ingatlah bahwa peserta (produsen blok dan validators) tidak memproses blok sampai mereka memiliki pesan satu bagian untuk setiap potongan yang termasuk dalam blok. Jadi, pada saat peserta tertentu menerapkan blok B, mereka memiliki semua pesan satu bagian yang sesuai potongan di B, dan dengan demikian mereka memiliki semua tanda terima masuk yang memiliki pecahannya peserta mempertahankan negara bagian sebagai tujuannya. Saat menerapkan transisi status untuk pecahan tertentu, peserta menerapkan kedua tanda terima tersebut yang telah mereka kumpulkan untuk pecahan di pesan satu bagian, dan juga semuanya transaksi yang termasuk dalam potongan itu sendiri. Gambar 18: Seumur hidup transaksi penerimaan 3.6.2 Menangani terlalu banyak tanda terima Ada kemungkinan bahwa jumlah penerimaan yang menargetkan pecahan tertentu di a blok tertentu terlalu besar untuk diproses. Misalnya, perhatikan gambar 19, di yang mana setiap transaksi di setiap shard menghasilkan tanda terima yang menargetkan shard 1. Pada blok berikutnya, jumlah resi yang perlu diproses oleh shard 1 adalah sebanding dengan beban yang diproses gabungan semua pecahan saat ditangani blok sebelumnya.

Gambar 19: Jika semua tanda terima menargetkan shard yang sama, shard tersebut mungkin tidak memilikinya kemampuan untuk memprosesnya Untuk mengatasinya kami menggunakan teknik serupa dengan yang digunakan di QuarkChain 9. Khususnya, untuk setiap shard, blok B terakhir dan shard terakhir di dalamnya blok dari mana tanda terima diterapkan dicatat. Saat pecahan baru ada dibuat, tanda terima diterapkan secara berurutan terlebih dahulu dari sisa pecahan di B, dan kemudian di blok berikutnya B, sampai bongkahan baru penuh. Di bawah normal keadaan dengan beban seimbang maka umumnya akan menghasilkan semua penerimaan sedang diterapkan (dan dengan demikian pecahan terakhir dari blok terakhir akan dicatat setiap potongan), tetapi pada saat beban tidak seimbang, dan tertentu shard menerima banyak tanda terima yang tidak proporsional, teknik ini memungkinkannya diproses dengan tetap menghormati batasan jumlah transaksi yang disertakan. Perhatikan bahwa jika beban tidak seimbang tersebut bertahan dalam waktu yang lama, penundaan akan terjadi pembuatan tanda terima hingga aplikasi dapat terus berkembang tanpa batas. Satu cara untuk mengatasinya adalah dengan membatalkan transaksi apa pun yang menghasilkan tanda terima yang menargetkan a pecahan yang memiliki penundaan pemrosesan yang melebihi beberapa konstanta (misalnya satu zaman). Perhatikan gambar 20. Berdasarkan blok B pecahan 4 tidak dapat memproses semua kuitansi, jadi hanya memproses penerimaan asal hingga shard 3 di blok A, dan mencatatnya. Di blok C disertakan resi hingga pecahan 5 di blok B, dan kemudian di blok D pecahannya menyusul, memproses semua sisa kuitansi yang masuk blok B dan semua kuitansi dari blok C. 3.7 Validasi potongan Potongan yang dihasilkan untuk shard tertentu (atau blok shard yang diproduksi untuk rantai shard tertentu dalam model dengan rantai shard) hanya dapat divalidasi oleh 9Lihat episode papan tulis dengan QuarkChain di sini: https://www.youtube.com/watch? v=opEtG6NM4x4, yang didalamnya dibahas antara lain pendekatan transaksi cross-shard halGambar 20: Pemrosesan tanda terima tertunda peserta yang memelihara negara. Mereka dapat menjadi produsen blok, validators, atau hanya saksi eksternal yang mengunduh status dan memvalidasi pecahannya tempat mereka menyimpan aset. Dalam dokumen ini kami berasumsi bahwa mayoritas peserta tidak dapat menyimpan keadaan untuk sebagian besar pecahan. Namun perlu disebutkan, bahwa ada blockchain pecahan yang dirancang dengan asumsi bahwa sebagian besar peserta memiliki kapasitas untuk menyimpan status dan memvalidasi sebagian besarnya pecahannya, seperti QuarkChain. Karena hanya sebagian kecil peserta yang memiliki negara bagian untuk memvalidasi pecahan tersebut potongannya, dimungkinkan untuk adaptif korup hanya pada peserta yang memilikinya negara bagian, dan menerapkan transisi keadaan yang tidak valid. Beberapa desain sharding diusulkan dengan sampel validators setiap beberapa hari, dan dalam satu hari setiap blok dalam rantai pecahan yang memiliki lebih dari 2/3 tanda tangan validator yang ditugaskan pada pecahan tersebut segera dipertimbangkan terakhir. Dengan pendekatan seperti itu, musuh adaptif hanya perlu merusak 2n/3+1 dari validators dalam rantai pecahan untuk menerapkan transisi keadaan yang tidak valid, yang, Meskipun hal ini mungkin sulit dilakukan, namun tingkat keamanannya tidak memadai bagi masyarakat blockchain. Seperti yang dibahas di bagian 2.3, pendekatan umum adalah memberikan jangka waktu tertentu setelah blok dibuat untuk setiap peserta yang memiliki status (baik itu adalah produsen blok, validator, atau pengamat eksternal) yang menantang validitasnya. Peserta seperti ini disebut Nelayan. Agar seorang nelayan bisa menantang blok yang tidak valid, harus dipastikan bahwa blok tersebut tersedia mereka. Ketersediaan data di Nightshade dibahas di bagian 3.4. Di Nightshade, setelah blok diproduksi, potongan tersebut tidak divalidasi oleh siapa pun kecuali produser bongkahan sebenarnya. Khususnya, produsen blok itu menyarankan blok tersebut secara alami tidak memiliki status untuk sebagian besar pecahannya, dantidak dapat memvalidasi potongan tersebut. Ketika blok berikutnya diproduksi, blok tersebut berisi pengesahan (lihat bagian 3.2) dari beberapa produsen blok dan validators, tapi karena mayoritas produsen blok dan validator tidak mengelola negara untuk sebagian besar shard, sebuah blok yang hanya memiliki satu bongkahan yang tidak valid akan mengumpulkan lebih dari separuh pengesahan secara signifikan dan akan terus berada pada pengesahan terberat. rantai. Untuk mengatasi masalah ini, kami mengizinkan peserta mana pun yang mempertahankan status pecahan untuk mengirimkan tantangan secara on-chain untuk setiap potongan tidak valid yang dihasilkan di dalamnya pecahan. 3.7.1 Tantangan validitas negara Setelah peserta mendeteksi bahwa potongan tertentu tidak valid, mereka harus memberikan bukti bahwa potongan tersebut tidak valid. Karena sebagian besar peserta jaringan tidak mempertahankan status pecahan yang berisi potongan tidak valid dihasilkan, bukti tersebut perlu memiliki informasi yang cukup untuk memastikan blok tersebut tidak sah tanpa memiliki negara. Kami menetapkan batas Ls dari jumlah negara (dalam byte) yang satu transaksi dapat membaca atau menulis secara kumulatif. Setiap transaksi yang menyentuh lebih dari Ls negara dianggap tidak sah. Ingat dari bagian 3.5 bahwa potongan tersebut di blok B tertentu hanya berisi transaksi yang akan diterapkan, tapi tidak akar negara baru. Akar negara bagian yang termasuk dalam potongan di blok B adalah negara bagian root sebelum menerapkan transaksi tersebut, tetapi setelah menerapkan transaksi dari potongan terakhir di pecahan yang sama sebelum blok B. Aktor jahat itu ingin menerapkan transisi keadaan yang tidak valid akan mencakup akar keadaan yang salah di blok B yang tidak sesuai dengan state root yang dihasilkan dari penerapan transaksi pada potongan sebelumnya. Kami memperluas informasi yang disertakan oleh produsen bongkahan ke dalam bongkahan tersebut. Alih-alih hanya menyertakan negara setelah menerapkan semua transaksi, malahan menyertakan akar keadaan setelah menerapkan setiap rangkaian transaksi yang berdekatan itu secara kolektif membaca dan menulis Ls byte negara. Dengan informasi ini untuk nelayan untuk menciptakan tantangan bahwa transisi negara diterapkan secara tidak benar cukup untuk menemukan akar status pertama yang tidak valid, dan hanya menyertakan Ls byte keadaan yang dipengaruhi oleh transaksi antara akar keadaan terakhir (yang tadinya valid) dan akar status saat ini dengan bukti merkle. Lalu peserta mana saja dapat memvalidasi transaksi di segmen tersebut dan memastikan bahwa potongan tersebut benar tidak valid. Demikian pula, jika produsen potongan mencoba memasukkan transaksi yang terbaca dan menulis lebih dari Ls byte status, untuk tantangannya cukup dengan menyertakannya byte Ls pertama yang disentuhnya dengan bukti merkle, yang sudah cukup menerapkan transaksi dan memastikan bahwa ada saatnya upaya untuk melakukannya membaca atau menulis konten melebihi Ls byte dibuat.

3.7.2 Nelayan dan transaksi lintas pecahan yang cepat Seperti yang dibahas di bagian 2.3, setelah kita berasumsi bahwa potongan shard (atau shard blok dalam model dengan rantai pecahan) bisa jadi tidak valid dan menimbulkan tantangan periode, hal ini berdampak negatif pada finalitas, dan dengan demikian komunikasi lintas pecahan. Di khususnya, shard tujuan dari transaksi lintas shard tidak dapat dipastikan bongkahan atau blok pecahan asal bersifat final hingga periode tantangan selesai (lihat gambar 21). Gambar 21: Menunggu periode tantangan sebelum menerapkan tanda terima Cara mengatasinya dengan cara melakukan transaksi cross-shard instantenious adalah agar shard tujuan tidak menunggu periode tantangan setelah transaksi pecahan sumber dipublikasikan, dan terapkan transaksi tanda terima segera, tetapi kemudian kembalikan pecahan tujuan bersama dengan sumbernya shard jika kemudian potongan atau blok asal ditemukan tidak valid (lihat gambar 22). Ini berlaku secara alami pada desain Nightshade yang menggunakan beling rantai tidak independen, melainkan semua potongan pecahannya dipublikasikan bersama-sama dalam blok rantai utama yang sama. Jika ada potongan yang ditemukan tidak valid, maka seluruh blok dengan potongan itu dianggap tidak valid, dan semua blok dibangun di atasnya di atasnya. Lihat gambar 23. Kedua pendekatan di atas memberikan atomisitas dengan asumsi tantangan tersebut periodenya cukup lama. Kami menggunakan pendekatan terakhir karena menyediakan transaksi crossshard cepat dalam keadaan normal melebihi ketidaknyamanannya pecahan tujuan dibatalkan karena transisi status yang tidak valid di salah satu pecahan sumber, yang merupakan peristiwa yang sangat langka. 3.7.3 Menyembunyikan validators Adanya tantangan-tantangan tersebut sudah secara signifikan mengurangi kemungkinan terjadinya hal tersebut korupsi adaptif, karena menyelesaikan bagian dengan pos transisi keadaan yang tidak validGambar 22: Menerapkan tanda terima segera dan mengembalikan tujuan rantai jika rantai sumber memiliki blok yang tidak valid Gambar 23: Tantangan nelayan di Nightshade periode tantangan yang dibutuhkan musuh adaptif untuk merusak semua peserta yang mempertahankan status pecahan, termasuk semua validators. Memperkirakan kemungkinan kejadian seperti itu sangatlah rumit, karena tidak ada sharded blockchain telah berumur cukup lama untuk mencoba melakukan serangan seperti itu. Kami berpendapat bahwa kemungkinannya, walaupun sangat rendah, masih cukup besar besar untuk sistem yang diharapkan dapat mengeksekusi jutaan transaksi dan menjalankan operasi keuangan di seluruh dunia. Ada dua alasan utama keyakinan ini: 1. Sebagian besar validator rantai Proof-of-Stake dan penambang di

Rantai Proof-of-Work terutama diberi insentif oleh keuntungan finansial. Jika musuh yang adaptif menawarkan mereka lebih banyak uang daripada keuntungan yang diharapkan dari beroperasi dengan jujur, masuk akal untuk mengharapkan banyak validator akan menerima tawaran itu. 2. Banyak entitas melakukan validasi rantai Proof-of-Stake secara profesional, dan diperkirakan akan ada sebagian besar saham di rantai mana pun dari entitas tersebut. Jumlah entitas tersebut cukup kecil untuk sebuah musuh adaptif untuk mengenal sebagian besar dari mereka secara pribadi dan memiliki a pemahaman yang baik tentang kecenderungan mereka untuk dirusak. Kami mengambil satu langkah lebih jauh dalam mengurangi kemungkinan korupsi adaptif dengan menyembunyikan validator yang ditugaskan ke shard mana. Idenya adalah mirip dengan cara Algorand [5] menyembunyikan validators. Penting untuk dicatat bahwa meskipun validator disembunyikan, seperti pada Algorand atau seperti dijelaskan di bawah ini, korupsi adaptif secara teori masih mungkin terjadi. Sementara musuh adaptif tidak mengetahui peserta yang akan membuat atau memvalidasi satu blok atau satu bagian, para peserta sendiri mengetahui bahwa mereka akan tampil tugas seperti itu dan memiliki bukti kriptografiknya. Jadi, musuh bisa menyiarkan niatnya untuk melakukan korupsi, dan membayar kepada siapa saja peserta yang mau memberikan bukti kriptografi seperti itu. Namun kami mencatat, karena musuh tidak melakukannya mengetahui validator yang ditugaskan ke pecahan yang ingin mereka rusak, mereka tidak punya pilihan lain selain menyiarkan niat mereka untuk merusak pecahan tertentu seluruh komunitas. Pada titik ini, hal ini menguntungkan secara ekonomi bagi siapa pun yang jujur peserta untuk memutar node penuh yang memvalidasi pecahan tersebut, karena ada nilai high kemungkinan munculnya blok yang tidak valid di pecahan itu, yang merupakan peluang untuk itu buat tantangan dan kumpulkan hadiah terkait. Untuk tidak mengungkapkan validator yang ditetapkan ke pecahan tertentu, kami melakukannya berikut ini (lihat gambar 24): Menggunakan VRF untuk mendapatkan tugas. Di awal setiap zaman masing-masing validator menggunakan VRF untuk mendapatkan bitmask dari pecahan yang validator ditugaskan. Bitmask setiap validator akan memiliki bit Sw (lihat bagian 3.3 untuk definisinya dari Sw). validator kemudian mengambil status pecahan yang sesuai, dan selama masa untuk setiap blok yang diterima memvalidasi potongan yang sesuai ke pecahan tempat validator ditugaskan. Masuk dalam blok, bukan bongkahan. Karena penetapan pecahan disembunyikan, validator tidak dapat menandatangani pecahan. Sebaliknya, ia selalu memberi tanda secara keseluruhan blok, sehingga tidak mengungkapkan pecahan apa yang divalidasinya. Khususnya, ketika validator menerima sebuah blok dan memvalidasi semua potongan, ia akan membuat pesan yang membuktikan bahwa semua potongan di semua pecahan yang validator ditugaskan adalah valid (tanpa menunjukkan dengan cara apa pun pecahan itu), atau pesan itu berisi bukti transisi keadaan yang tidak valid jika ada bagian yang tidak valid. Lihat bagian 3.8 untuk rincian tentang bagaimana pesan-pesan tersebut dikumpulkan, bagian 3.7.4 untuk detail tentang cara mencegah validators membonceng pesan dari validator lainnya, dan bagian 3.7.5 untuk detail cara memberi penghargaan dan hukuman validators seandainya tantangan transisi keadaan tidak valid yang berhasil benar-benar terjadi.Gambar 24: Menyembunyikan validator di Nightshade 3.7.4 Pengungkapan Komitmen Salah satu masalah umum dengan validators adalah validator dapat melewatkan pengunduhan status dan benar-benar memvalidasi potongan dan blok, dan sebagai gantinya amati jaringannya, lihat apa yang dikirimkan validator lainnya dan ulangi pesan. validator yang mengikuti strategi seperti itu tidak memberikan tambahan apa pun keamanan untuk jaringan, tetapi mengumpulkan hadiah. Solusi umum untuk masalah ini adalah setiap validator memberikan bukti bahwa mereka benar-benar memvalidasi blok tersebut, misalnya dengan memberikan jejak unik penerapan transisi negara, namun bukti-bukti tersebut meningkatkan biaya secara signifikan validasi. Gambar 25: Pengungkapan komitmen

Sebaliknya kita membuat validator pertama yang berkomitmen pada hasil validasi (baik pesan yang membuktikan keabsahan potongan, atau bukti ketidakabsahan transisi keadaan), tunggu selama jangka waktu tertentu, baru kemudian tampilkan hasil validasi sebenarnya, seperti ditunjukkan pada gambar 25. Periode penerapan tidak bersinggungan dengan periode pengungkapan, dan dengan demikian validator yang malas tidak dapat meniru validator yang jujur. Terlebih lagi, jika validator yang tidak jujur berkomitmen pada pesan yang membuktikan hal tersebut validitas potongan yang ditetapkan, dan setidaknya satu potongan tidak valid, jika memang demikian ditunjukkan bahwa potongan tersebut tidak valid, validator tidak dapat menghindari pemotongan, karena, seperti yang kami tunjukkan di bagian 3.7.5, satu-satunya cara agar tidak terpotong dalam situasi seperti ini adalah menyajikan pesan yang berisi bukti transisi keadaan yang tidak valid itu cocok dengan komit. 3.7.5 Menangani tantangan Seperti dibahas di atas, setelah validator menerima blok dengan potongan yang tidak valid, mereka terlebih dahulu menyiapkan bukti transisi keadaan yang tidak sah (lihat bagian 3.7.1), kemudian berkomitmen pada bukti tersebut (lihat 3.7.4), dan setelah beberapa waktu ungkapkan tantangannya. Setelah tantangan yang terungkap dimasukkan ke dalam blok, hal berikut akan terjadi: 1. Semua transisi keadaan yang terjadi dari blok yang berisi potongan tidak valid sampai blok di mana tantangan yang terungkap disertakan, dapatkan dibatalkan. Keadaan sebelum blok yang mencakup tantangan yang terungkap dianggap sama dengan keadaan sebelum blok yang memuatnya potongan yang tidak valid. 2. Dalam jangka waktu tertentu setiap validator harus menampilkan bitmasknya pecahan yang mereka validasi. Karena bitmask dibuat melalui VRF, jika mereka ditugaskan ke pecahan yang memiliki transisi status tidak valid, mereka tidak bisa menghindari pengungkapannya. Setiap validator yang gagal menampilkan bitmask diasumsikan ditugaskan ke beling. 3. Setiap validator yang setelah periode tersebut ditemukan ditugaskan ke pecahan, yang melakukan komit pada beberapa hasil validasi untuk blok yang berisi potongan yang tidak valid dan itu tidak mengungkapkan bukti transisi keadaan yang tidak valid yang sesuai dengan komit mereka dipotong. 4. Setiap validator mendapat tugas pecahan baru, dan periode baru dijadwalkan untuk memulai setelah beberapa waktu yang cukup bagi semua validator untuk mengunduh keadaan, seperti yang ditunjukkan pada gambar 26. Perhatikan bahwa sejak validator mengungkapkan pecahan yang ditugaskan padanya hingga zaman baru dimulai, keamanan sistem berkurang sejak tugas pecahan terungkap. Para peserta jaringan perlu menjaganya diingat saat menggunakan jaringan selama periode tersebut. 3.8 Agregasi Tanda Tangan Agar sistem dengan ratusan pecahan dapat beroperasi dengan aman, kami ingin memilikinya pesanan 10.000 atau lebih validators. Seperti yang dibahas di bagian 3.7, kita menginginkan masing-masingGambar 26: Menangani tantangan validator untuk mempublikasikan rata-rata komit pada pesan dan tanda tangan tertentu sekali per blok. Meskipun pesan komitnya sama, menggabungkan a Menandatangani BLS dan memvalidasinya akan sangat mahal. Tapi tentu saja pesan komit dan pengungkapan tidak sama di validators, dan oleh karena itu kita memerlukan cara untuk menggabungkan pesan-pesan dan tanda tangan tersebut di a cara yang memungkinkan validasi cepat nanti. Pendekatan spesifik yang kami gunakan adalah sebagai berikut: Validator bergabung dengan produsen blok. Produsen blok sudah dikenal beberapa saat sebelum zaman dimulai, karena mereka memerlukan waktu untuk mengunduhnya menyatakan sebelum epoch dimulai, dan tidak seperti validators, produsen bloknya tidak disembunyikan. Setiap produser blok memiliki v validator slot. Validator mengirimkan proposal off-chain kepada produsen blok untuk dimasukkan sebagai salah satu dari v validatordtk. Jika produsen blok ingin memasukkan validator, mereka mengirimkan a transaksi yang berisi permintaan off-chain awal dari validator, dan tanda tangan produser blok yang membuat validator bergabung dengan produser blok. Perhatikan bahwa validator yang ditugaskan ke produsen blok belum tentu memvalidasi pecahan yang sama dengan yang dihasilkan oleh produsen blok. Jika sebuah validator diterapkan untuk bergabung dengan beberapa produsen blok, hanya transaksi dari produsen blok pertama akan berhasil. Produsen blok mengumpulkan komitmen. Produser blok terus-menerus mengumpulkan komit dan mengungkapkan pesan dari validators. Setelah sejumlah pesan tersebut terakumulasi, produsen blok menghitung merekle pohon pesan-pesan ini, dan mengirimkan ke setiap validator root merkle dan jalur merkle ke pesan mereka. validator memvalidasi jalur dan tanda masuk akar merkle. Produser blok kemudian mengumpulkan tanda tangan BLS di root merkle dari validators, dan hanya menerbitkan root merkle dan akumulasi tanda tangan. Produsen blok juga menandatangani keabsahan multisignature menggunakan tanda tangan ECDSA yang murah. Jika multisignature tidak cocok dengan root merkle yang dikirimkan atau bitmask dari validator yang berpartisipasi, ini merupakan perilaku yang dapat disayat. Saat menyinkronkan rantai, seorang peserta dapat memilih untuk memvalidasi semua tanda tangan BLS dari validator (yang sangat mahal karena melibatkan pengumpulan kunci publik validator), atau hanyatanda tangan ECDMA dari produsen blok dan mengandalkan fakta bahwa produsen blok tidak ditantang dan dipangkas. Menggunakan transaksi on-chain dan bukti merkle untuk tantangan. Itu dapat dicatat bahwa tidak ada gunanya mengungkapkan pesan dari validators jika tidak transisi keadaan yang tidak valid terdeteksi. Hanya pesan-pesan yang berisi hal yang sebenarnya bukti transisi negara yang tidak valid perlu diungkapkan, dan hanya untuk pesan-pesan seperti itu perlu ditunjukkan bahwa mereka cocok dengan komitmen sebelumnya. Pesannya perlu diungkapkan untuk dua tujuan: 1. Untuk benar-benar memulai rollback rantai ke momen sebelum transisi keadaan tidak valid (lihat bagian 3.7.5). 2. Untuk membuktikan bahwa validator tidak berusaha membuktikan keabsahan potongan tidak valid. Apa pun kasusnya, kita perlu mengatasi dua masalah: 1. Komit sebenarnya tidak disertakan pada rantai, hanya akar merkle saja komit dikumpulkan dengan pesan lain. validator perlu menggunakan jalur merkle yang disediakan oleh produsen blok dan komitmen awal mereka membuktikan bahwa mereka berkomitmen terhadap tantangan tersebut. 2. Ada kemungkinan bahwa semua validator yang ditugaskan ke beling dengan yang tidak valid transisi negara kebetulan ditugaskan ke produsen blok yang korup itu sedang menyensor mereka. Untuk menyiasatinya, kami mengizinkan mereka mengirimkan pengungkapannya sebagai transaksi reguler on-chain dan melewati agregasi. Yang terakhir ini hanya diperbolehkan untuk bukti transisi negara yang tidak sah, yaitu sangat jarang terjadi, sehingga tidak akan mengakibatkan pemblokiran spam. Masalah terakhir yang perlu diatasi adalah bahwa produsen blok dapat melakukan hal tersebut memilih untuk tidak berpartisipasi dalam pengumpulan pesan atau dengan sengaja menyensor validators tertentu. Kita buat yang tidak menguntungkan secara ekonomi, dengan membuat blok imbalan produser sebanding dengan jumlah validator yang ditugaskan kepada mereka. Kami juga mencatat bahwa karena produsen blok antar zaman sebagian besar berpotongan (sejak selalu menjadi peserta teratas dengan taruhan tertinggi), validator bisa sebagian besar tetap bekerja sama dengan produsen blok yang sama, dan dengan demikian mengurangi risiko ditugaskan ke produser blok yang pernah menyensornya di masa lalu. 3.9 Rantai Snapshot Karena blok pada rantai utama sangat sering diproduksi, pengunduhan sejarah lengkap mungkin menjadi mahal dengan sangat cepat. Apalagi sejak setiap blok berisi tanda tangan BLS dari sejumlah besar peserta, hanya agregasi kunci publik untuk memeriksa tanda tangan mungkin menjadi penghalang mahal juga. Terakhir, karena di masa mendatang Ethereum 1.0 kemungkinan besar akan tetap menjadi satu dari blockchain yang paling banyak digunakan, memiliki cara yang berarti untuk mentransfer aset

Mendekati Ethereum adalah persyaratan, dan hari ini memverifikasi tanda tangan BLS untuk memastikannya Validitas blok dekat pada sisi Ethereum tidak dimungkinkan. Setiap blok di rantai utama Nightshade secara opsional dapat berisi Schnorr multisignature pada header blok terakhir yang menyertakan Schnorr tersebut multitanda tangan. Kami menyebut blok tersebut sebagai blok snapshot. Blok pertama dari setiap zaman harus berupa blok snapshot. Saat mengerjakan multisignature seperti itu, produsen blok juga harus mengumpulkan tanda tangan BLS dari validators pada blok snapshot terakhir, dan menggabungkannya dengan cara yang sama seperti yang dijelaskan dalam bagian 3.8. Karena kumpulan produsen blok konstan sepanjang zaman, maka validasi hanya blok snapshot pertama di setiap epoch yang cukup dengan asumsi bahwa pada no menunjukkan sebagian besar produsen blok dan validator berkolusi dan berkreasi sebuah garpu. Blok pertama dari zaman tersebut harus berisi informasi yang cukup untuk dihitung produsen blok dan validators untuk zaman tersebut. Kami menyebut subrantai dari rantai utama yang hanya berisi snapshot memblokir rantai snapshot. Membuat multisignature Schnorr adalah proses interaktif, tapi sejak kami hanya perlu melakukannya secara jarang, proses apa pun, tidak peduli seberapa tidak efisiennya akan cukup. Multisignature Schnorr dapat dengan mudah divalidasi di Ethereum, sehingga memberikan primitif penting untuk cara yang aman dalam melakukan cross-blockchain komunikasi. Untuk menyinkronkan dengan rantai Dekat, seseorang hanya perlu mengunduh semua snapshot memblokir dan mengonfirmasi bahwa tanda tangan Schnorr sudah benar (opsional juga memverifikasi masing-masing tanda tangan BLS dari validators), dan kemudian hanya menyinkronkan blok rantai utama dari blok snapshot terakhir.

Conclusão

Neste documento discutimos abordagens para construir blockchains fragmentados e cobriu dois grandes desafios com as abordagens existentes, nomeadamente a validade do estado e disponibilidade de dados. Em seguida, apresentamos o Nightshade, um design de fragmentação que poderes NEAR Protocolo. O design está em andamento, se você tiver comentários, perguntas ou feedback neste documento, vá para https://near.chat.

Kesimpulan

Dalam dokumen ini kita membahas pendekatan untuk membangun blockchains dan mencakup dua tantangan besar dengan pendekatan yang ada, yaitu validitas negara dan ketersediaan data. Kami kemudian menghadirkan Nightshade, desain sharding itu kekuasaan NEAR Protokol. Desain sedang dalam proses, jika Anda memiliki komentar, pertanyaan, atau masukan pada dokumen ini, silakan buka https://near.chat.