Белая книга NEAR

Yazan Alex Skidanov and Illia Polosukhin · 2019

🇺🇸 English (Orijinal)

🇷🇺 Русский (Çeviri)

Parçalama Temelleri

Parçalamaya en basit yaklaşımla başlayalım. Bu yaklaşımda bunun yerine bir blockchain çalıştırıyorsak, birden fazla çalıştıracağız ve bunların her birine blockchain a adını vereceğiz "parça". Her parçanın kendine ait validator kümesi olacaktır. Burada ve aşağıda kullanıyoruz işlemleri doğrulayan katılımcılara atıfta bulunmak için genel bir terim olan “validator” ve Proof of Work gibi madencilik yoluyla veya oylamaya dayalı bir yöntemle bloklar üretin 1Bu bölüm daha önce https://near.ai/shard1. adresinde yayınlanmıştı. Daha önce okuduysanız, sonraki bölüme geçin.

mekanizma. Şimdilik parçaların hiçbir zaman birbiriyle iletişim kurmadığını varsayalım. diğer. Bu tasarım, basit olmasına rağmen, parçalamadaki başlangıçtaki bazı büyük zorlukların ana hatlarını çizmek için yeterlidir. 1.1 Doğrulayıcı bölümleme ve Beacon zincirleri Sistemin 10 parçadan oluştuğunu varsayalım. İlk zorluk, her biriyle kendi validator'lerine sahip olan her bir parça artık 10 kat daha az güvenli tüm zincir. Yani X validators içeren parçalanmamış bir zincir hard fork yapmaya karar verirse parçalanmış bir zincire ayırır ve X validator'yi 10 parçaya böler, her parça şimdi yalnızca X/10 validators var ve bir parçayı bozmak yalnızca bozmayı gerektirir Toplam validators sayısının %5,1'i (%51 / 10) (bkz. şekil 1), Şekil 1: validator'leri parçalara bölme bu da bizi ikinci noktaya getiriyor: kim her parça için validators seçer? validators'nin %5,1'ini kontrol etmek, yalnızca validators'nin %5,1'inin tamamının olması durumunda zarar verir aynı parçanın içindeler. validators hangi parçayı doğrulayacaklarını seçemiyorsa validator'lerin %5,1'ini kontrol eden bir katılımcının tümünü alması pek olası değil validator'leri aynı parçada bulunuyor ve bu da uzlaşma yeteneklerini büyük ölçüde azaltıyor sistem. Bugün neredeyse tüm parçalama tasarımları, bazı rastgelelik kaynaklarına dayanmaktadır. Parçalara validators atayın. blockchain üzerindeki rastgelelik başlı başına oldukça zorlu bir konudur ve bu belgenin kapsamı dışındadır. Şimdilik var olduğunu varsayalım kullanabileceğimiz bir tür rastlantısallık kaynağı. validator'in ödevini şu bölümde ele alacağız: Bölüm 2.1'de daha fazla ayrıntı verilmiştir. Hem rastgelelik hem de validator ataması, herhangi bir parçaya özeldir. Bu hesaplama için, pratik olarak mevcut tüm tasarımlarda, işlemleri gerçekleştirmekle görevli ayrı bir blockchain bulunur tüm ağın bakımı için gereklidir. Rastgele üretmenin yanı sırasayılar ve parçalara validator atama, bu işlemler genellikle aynı zamanda Parçalardan güncelleme almayı ve bunların anlık görüntülerini almayı, işlemeyi içerir Hisse Kanıtı sistemlerinde kazıklar ve kesintiler ve bu durumlarda parçaların yeniden dengelenmesi özelliği desteklenmektedir. Böyle bir zincire Ethereum'de Beacon zinciri, bir Röle denir PolkaDot'taki zincir ve Cosmos'deki Cosmos Hub. Bu belge boyunca böyle bir zincire Beacon zinciri olarak değineceğiz. Beacon zincirinin varlığı bizi bir sonraki ilginç konuya getiriyor: ikinci dereceden parçalama. 1.2 İkinci dereceden parçalama Parçalama genellikle sayıya göre sonsuz ölçeklenen bir çözüm olarak tanıtılır. Ağ işlemine katılan düğümlerin sayısı. Teorik olarak mümkün olmakla birlikte böyle bir parçalama çözümü tasarlayın, Beacon konseptine sahip herhangi bir çözüm zincirin sonsuz ölçeklenebilirliği yoktur. Nedenini anlamak için Beacon'a dikkat edin. zincirin, validator'ları atamak gibi bazı muhasebe hesaplamaları yapması gerekiyor sayısıyla orantılı olan parçalar veya anlık parça zincir blokları sistemdeki parçaların sayısı. Beacon zincirinin kendisi tek bir blockchain olduğundan, hesaplama, onu çalıştıran düğümlerin hesaplama yetenekleriyle sınırlıdır, parça sayısı doğal olarak sınırlıdır. Bununla birlikte, bölünmüş bir ağın yapısı çarpımsal bir değer verir. düğümlerindeki iyileştirmeleri etkiler. Keyfi bir durumun olduğu durumu düşünün Ağdaki düğümlerin verimliliğinde iyileştirmeler yapılarak daha hızlı işlem işlem süreleri sağlarlar. Beacon zincirindeki düğümler de dahil olmak üzere ağı işleten düğümler, dört kat daha hızlı hale gelirse her parça dört kat daha fazla işleyebilecek Beacon zinciri 4 kat daha fazla parçayı koruyabilecek. Sistem genelinde verim 4 × 4 = 16 faktörüyle artacaktır — dolayısıyla ikinci dereceden parçalama adı. Kaç parça olduğuna dair doğru bir ölçüm sağlamak zordur. bugün uygulanabilir, ancak öngörülebilir bir gelecekte üretim hacminin artması pek olası değildir. blockchain kullanıcılarının ihtiyaçları, ikinci dereceden parçalamanın sınırlamalarını aşacaktır. Bu kadar çok parçayı güvenli bir şekilde çalıştırmak için gereken çok sayıda düğüm var muhtemelen tüm düğümleri çalıştıran düğümlerin sayısından daha büyük mertebelerdedir. blockchains bugün birleşti. 1.3 Durum paylaşımı Şu ana kadar tam olarak neyin ayrılıp ayrılmadığını çok iyi tanımlamadık. bir ağ parçalara bölündüğünde. Özellikle, blockchain içindeki düğümler üç önemli görevi yerine getirirler: yalnızca 1) işlemleri işlemekle kalmazlar, ayrıca 2) doğrulanmış işlemleri ve tamamlanan blokları diğer düğümlere iletmek ve 3) tüm ağ defterinin durumunu ve geçmişini saklayın. Bu üçünün her biri görevler, ağı işleten düğümlere artan bir gereksinim getirmektedir:1. İşlemleri işleme zorunluluğu daha fazla bilgi işlem gücü gerektirir işlenen işlemlerin artan sayısı; 2. İşlemlerin ve blokların aktarılması gerekliliği, aktarılan işlem sayısının artmasıyla birlikte daha fazla ağ bant genişliği gerektirir; 3. Verilerin saklanması zorunluluğu, devlet büyüdükçe daha fazla depolama gerektirir. Daha da önemlisi, işlem gücü ve ağdan farklı olarak, işlem oranı (işlenen işlem sayısı) ne kadar yüksek olsa bile depolama gereksinimi artar. saniyede) sabit kalır. Yukarıdaki listeden depolama gereksiniminin şu şekilde olduğu görünebilir: en acil olanı, çünkü zamanla artan tek şey bu Saniyedeki işlem sayısı değişmese de pratikte günümüzün en acil gereksinimi bilgi işlem gücüdür. Tüm durumu Ethereum bu yazının yazıldığı an itibarıyla 100 GB'tır ve düğümlerin çoğu tarafından kolaylıkla yönetilebilir. Ancak Ethereum'in işleyebileceği işlem sayısı 20 civarındadır. birçok pratik kullanım durumu için gerekenden daha az büyüklük. Zilliqa, parça işlemeyi ancak depolamayı değil, en bilinen projedir. İşlemenin parçalanması daha kolay bir sorundur çünkü her düğüm tüm Bu, sözleşmelerin serbestçe diğer sözleşmeleri başlatabileceği ve herhangi bir veriyi okuyabileceği anlamına gelir blockchain'den. Güncellemelerin yapıldığından emin olmak için dikkatli bir mühendislik gereklidir. Durumun aynı bölümlerini güncelleyen birden fazla parçadan alınan bilgiler çakışmaz. içinde Zilliqa bu konuda nispeten basit bir yaklaşım benimsiyor2. İşlemenin parçalanması olmadan depolamanın parçalanması önerilmiş olsa da, son derece nadir. Bu nedenle pratikte depolamanın parçalanması veya Durum Parçalaması, neredeyse her zaman işlemenin parçalanması ve ağın parçalanması anlamına gelir. Pratik olarak, Durum Parçalaması altında her bir parçadaki düğümler kendi yalnızca yerel kısmını etkileyen işlemleri içeren kendi blockchain söz konusu parçaya atanan küresel durum. Bu nedenle, validator'ler Shard'ın yalnızca küresel durumun yerel bölümünü depolaması ve yalnızca yürütmesi gerekir, ve bu nedenle yalnızca devletin kendilerine ait kısmını etkileyen işlemleri aktarır. Bu bölümleme, tüm bilgi işlem gücü, depolama ve depolama gereksinimlerine olan gereksinimi doğrusal olarak azaltır. ağ bant genişliği, ancak veri kullanılabilirliği ve Her ikisini de aşağıda ele alacağımız çapraz parçalar arası işlemler. 1.4 Parçalar arası işlemler Şu ana kadar anlattığımız parçalama modeli pek kullanışlı değil çünkü eğer bireysel Parçalar birbirleriyle iletişim kuramazlar, birden fazla parçadan daha iyi değiller bağımsız blockchains. Bugün bile, parçalamanın mevcut olmadığı durumlarda, çeşitli blockchain'lar arasında birlikte çalışabilirlik konusunda büyük talep. Şimdilik yalnızca her katılımcının tam olarak bir parça üzerinde hesabının olduğu basit ödeme işlemlerini ele alalım. Eğer biri para transferi yapmak isterse 2Yaklaşımlarına ilişkin analizimizi burada bulabilirsiniz: https://medium.com/nearprotocol/ 8f9efae0ce3baynı parça içindeki bir hesaptan diğerine geçiş yapıldığında işlem gerçekleştirilebilir tamamen o parçadaki validator'ler tarafından. Ancak eğer parçada ikamet eden Alice

1, validators parçasının hiçbiri değil, #2 numaralı parçada ikamet eden Bob'a para göndermek istiyor

1 numaralı parçada (Bob'un hesabına para yatıramayacaklar) veya validator'lerde 2 numaralı parça (Alice'in hesabını borçlandıramayacaklar) tüm verileri işleyebilir işlem. Parçalar arası işlemlere yönelik iki yaklaşım ailesi vardır: • Eşzamanlı: Parçalar arası bir işlemin yürütülmesi gerektiğinde, ile ilgili durum geçişini içeren birden fazla parçadaki bloklar işlemlerin tümü aynı anda üretilir ve birden çok parçadan oluşan validator'ler bu tür işlemlerin yürütülmesinde işbirliği yapar.3 • Eşzamansız: birden fazla parçayı etkileyen, parçalar arası bir işlem bu parçalarda eşzamansız olarak yürütülür, "Kredi" parçası yürütülür "Borç" parçasının kendi payına düşeni yerine getirdiğine dair yeterli kanıt bulunduğunda yarısı. Bu yaklaşım daha yaygın olma eğilimindedir çünkü basitlik ve koordinasyon kolaylığı. Bu sistem bugün Cosmos, Ethereum Serenity, Near, Kadena ve diğerlerinde önerilmektedir. Bununla ilgili bir sorun Yaklaşım, eğer bloklar bağımsız olarak üretilirse, birden fazla bloktan birinin yetim kalma şansının sıfır olmadığı, dolayısıyla işlem yalnızca kısmen uygulandı. İkisini gösteren şekil 2'yi düşünün. her ikisi de çatalla karşılaşan parçalar ve parçalar arası işlem bu sırasıyla A ve X' bloklarına kaydedildi. A-B zincirleri ise ve V'-X'-Y'-Z' ilgili parçalarda kanonik hale gelir, işlem tamamen sonuçlandırılmıştır. A'-B'-C'-D' ve V-X kanonik hale gelirse, daha sonra işlem tamamen iptal edilir ve bu kabul edilebilir bir durumdur. Ama eğer, için Örneğin, A-B ve V-X kanonik hale gelir, daha sonra işlemin bir kısmı sonlandırılır ve bir kısmı terk edilir, bu da atomite hatası yaratır. Biz İkinci bölümde, çatal seçimi kuralları ve fikir birliğinde yapılan değişiklikleri ele alırken, önerilen protokollerde bu sorunun nasıl ele alındığı ele alınacaktır. Parçalanmış protokoller için önerilen algoritmalar. Zincirler arasındaki iletişimin parçalanmış blockchains dışında yararlı olduğunu unutmayın çok. Zincirler arasındaki birlikte çalışabilirlik, birçok projenin karşılaştığı karmaşık bir sorundur. çözmeye çalışıyoruz. Parçalanmış blockchains'de sorun biraz daha kolaydır çünkü Blok yapısı ve fikir birliği tüm parçalarda aynıdır ve koordinasyon için kullanılabilecek bir işaret zinciri vardır. Ancak parçalanmış bir blockchain'da, tüm parça zincirleri aynıdır, küresel blockchains ekosisteminde ise farklı hedef kullanım durumları ve merkezi olmayan çok sayıda farklı blockchain var ve gizlilik garantileri. Bir dizi zincirin farklı özelliklere sahip olduğu ancak yeterince benzer fikir birliği ve blok yapısı kullanmak ve ortak bir işaret zincirine sahip olmak, heterojen blockchain'lerden oluşan bir ekosistemi mümkün kılabilir. 3The çoğu detaylı teklif bilinen için the yazarlar arasında bu belge öyle Birleştir Bloklar, tarif edildi burada: https://ethresear.ch/t/ birleştirme blokları ve eşzamanlı çapraz parça durumu yürütme/1240Şekil 2: Eşzamansız parçalar arası işlemler Birlikte çalışabilirlik alt sistemi. Bu tür bir sistemin validator rotasyon özelliğine sahip olması pek olası değildir, bu nedenle güvenliği sağlamak için bazı ekstra önlemlerin alınması gerekir. Her ikisi de Cosmos ve PolkaDot bu tür sistemlerdir4 1.5 Kötü niyetli davranış Bu bölümde hangi düşmanca davranışların validators'ye zarar verebileceğini inceleyeceğiz. bir parçayı bozmayı başarırlarsa egzersiz yapın. Klasik yaklaşımları gözden geçireceğiz bölüm 2.1'deki parçaların bozulmasını önlemek için. 1.5.1 Kötü amaçlı çatallar Bir grup kötü niyetli validators bir çatal oluşturmaya çalışabilir. öyle olmadığını unutmayın Temel fikir birliğinin BFT olup olmadığı önemli değil, yeterli sayıyı bozuyor validators'nin sayısı her zaman bir çatal oluşturmayı mümkün kılacaktır. Tek bir parçanın %50'sinden fazlasının bozulması, tüm ağın %50'sinden fazlasının bozulmasından çok daha olasıdır (biz Bölüm 2.1'de bu olasılıkları daha derinlemesine inceleyin. Bölüm 1.4'te tartışıldığı gibi, Parçalar arası işlemler, birden fazla parçadaki belirli durum değişikliklerini içerir ve bu tür durum değişikliklerini uygulayan bu tür parçalardaki karşılık gelen blokların ya hepsi sonlandırılacak (yani ilgili zincirlerde seçilen zincirlerde görünecek) parçalar) veya tümü yetim kalmış (yani karşılık gelen parçalarda seçilen zincirlerde görünmüyor). Genel olarak parçaların bozulma olasılığı olduğundan 4Zaki Manian'ın Cosmos adresinden yazdığı şu yazıya bakın: https://forum.cosmos.network/ t/polkadot-vs-cosmos/1397/2 ve bu belgenin ilk yazarının yazdığı şu tweet fırtınası: Ayrıntılı bir karşılaştırma için https://twitter.com/AlexSkidanov/status/1129511266660126720 ikisinden

ihmal edilebilir değil, validators parçaları arasında Bizans'a özgü bir fikir birliğine varılsa veya birçok blok bloke edilse bile çatallanmaların gerçekleşmeyeceğini varsayamayız. durum değişikliği ile bloğun üstünde üretilir. Bu sorunun birden fazla çözümü var; en yaygın olanı ara sıra olanıdır. en son parça zinciri bloğunun işaret zincirine çapraz bağlanması. Çatal Parça zincirlerindeki seçim kuralı daha sonra her zaman aşağıdaki zinciri tercih edecek şekilde değiştirilir. çapraz bağlantılıdır ve yalnızca parçaya özgü çatal seçimi kuralını bloklar için uygular. son çapraz bağlantıdan bu yana yayınlandı. 1.5.2 Geçersiz blokları onaylama Bir validator kümesi, durum geçiş fonksiyonunu yanlış uygulayan bir blok oluşturmaya çalışabilir. Örneğin, Alice'in bulunduğu bir durumdan başlayarak 10 tokens ve Bob'un 0 tokens'si varsa, blok şu şekilde bir işlem içerebilir: Alice'ten Bob'a 10 tokens gönderir, ancak sonunda Alice'in sahip olduğu bir durumla karşılaşır. Şekil 3'te gösterildiği gibi 0 tokens ve Bob'un 1000 tokens'si var. Şekil 3: Geçersiz blok örneği Parçalı olmayan klasik bir blockchain'de böyle bir saldırı mümkün değildir, çünkü hepsi ağdaki katılımcı tüm blokları ve buna sahip bloğu doğrular geçersiz bir durum geçişi diğer blok üreticilerinin her ikisi tarafından da reddedilecektir ve Ağın blok oluşturmayan katılımcıları. Kötü niyetli olsa bile validators, böyle geçersiz bir bloğun üzerinde bloklar oluşturmaya daha hızlı devam ediyor dürüst validator'ler doğru zinciri oluşturur, böylece geçersiz zincire sahip olurlar bloğun daha uzun olması önemli değil, çünkü bloğu kullanan her katılımcı blockchain herhangi bir amaç için tüm blokları doğrular ve tüm blokları atar geçersiz bloğun üzerine inşa edilmiştir. Şekil 4'te beş validator var ve bunların üçü kötü niyetli. onlar geçersiz bir A' bloğu oluşturdu ve ardından üstüne yeni bloklar oluşturmaya devam etti ondan. İki dürüst validator, A'yı geçersiz olarak değerlendirdi ve üstüne ekleme yaptılarŞekil 4: Parçalanmamış bir blockchain içinde geçersiz bir blok oluşturma girişimi Bildikleri son geçerli bloğun bir çatal oluşturmasını sağlar. Daha az sayıda olduğundan validators dürüst çataldadır, zincirleri daha kısadır. Ancak klasik parçalanmamış blockchain'da herhangi bir amaç için blockchain kullanan her katılımcı aldıkları tüm blokları doğrulamaktan ve durumu yeniden hesaplamaktan sorumludur. Dolayısıyla blockchain ile ilgisi olan herhangi bir kişi A' geçersizdir ve bu nedenle B', C' ve D'yi de derhal atın; A-B zincirini mevcut en uzun geçerli zincir olarak seçin. Bununla birlikte, parçalı bir blockchain'de hiçbir katılımcı tüm parçalardaki tüm işlemleri doğrulayamaz; bu nedenle, bunu hiçbir durumda onaylamak için bir yola sahip olmaları gerekir. blockchain parçasının herhangi bir parçasının tarihinde hiçbir geçersiz blok dahil edilmedi. Çatallardan farklı olarak Beacon zincirine çapraz bağlanmanın yeterli bir çözüm olmadığını unutmayın, çünkü Beacon zincirinin doğrulama kapasitesi yoktur. bloklar. Yalnızca söz konusu parçada yeterli sayıda validator olduğunu doğrulayabilir bloğu imzaladı (ve bu nedenle doğruluğunu onayladı). Bu sorunun çözümlerini aşağıdaki bölüm 2.2'de tartışacağız.

Основы шардинга

Начнем с самого простого подхода к шардингу. В этом подходе вместо запустив один blockchain, мы запустим несколько и вызовем каждый такой blockchain a «осколок». Каждый шард будет иметь свой собственный набор validator. Здесь и ниже мы используем общий термин «validator» для обозначения участников, которые проверяют транзакции и производить блоки либо путем майнинга, например, в Proof of Work, либо с помощью голосования на основе голосования. 1Этот раздел ранее был опубликован по адресу https://near.ai/shard1.. Если вы читали его раньше, перейти к следующему разделу.

механизм. А пока давайте предположим, что шарды никогда не общаются друг с другом. другое. Несмотря на свою простоту, эта схема достаточна для того, чтобы обозначить некоторые первоначальные основные проблемы шардинга. 1.1 Разделение валидаторов и цепочки маяков Допустим, система состоит из 10 шардов. Первая проблема заключается в том, что с каждым имеет свои собственные validator, каждый шард теперь в 10 раз менее безопасен, чем вся цепочка. Итак, если несегментированная цепочка с X validators решит провести хард-форк в сегментированную цепочку и разбивает X validator на 10 сегментов, каждый из которых теперь имеет только X/10 validator, и для повреждения одного фрагмента требуется только повреждение 5,1% (51% / 10) от общего количества validators (см. рисунок 1), Рисунок 1: Разделение validator на сегменты что подводит нас ко второму моменту: кто выбирает validators для каждого шарда? Контроль над 5,1% validators наносит ущерб только в том случае, если все эти 5,1% validators находятся в одном шарде. Если validator не могут выбрать, какой осколок они получат для проверки в, участник, контролирующий 5,1% validators, вряд ли получит все их validator в одном шарде, что значительно снижает их способность к компрометации система. Сегодня почти все конструкции шардинга основаны на некотором источнике случайности. назначьте validators осколкам. Случайность на blockchain сама по себе является очень сложной темой и выходит за рамки этого документа. А пока предположим, что есть некоторый источник случайности, который мы можем использовать. Мы рассмотрим задание validators в подробнее в разделе 2.1. Как случайность, так и присвоение validator требуют вычислений, которые не специфичный для любого конкретного шарда. Для этого расчета практически все существующие проекты имеют отдельный blockchain, которому поручено выполнять операции необходимые для обслуживания всей сети. Помимо генерации случайныхномера и присвоение осколкам validator, эти операции часто также включают получение обновлений от шардов и создание их снимков, обработку ставки и сокращение в системах Proof-of-Stake, а также ребалансировку шардов, когда это функция поддерживается. Такая цепочка называется цепочкой маяков в Ethereum, релейной цепочка в PolkaDot и концентратор Cosmos в Cosmos. В этом документе мы будем называть такую цепочку Beacon-цепочкой. Существование цепочки Beacon подводит нас к следующей интересной теме: квадратичный шардинг. 1.2 Квадратичный шардинг Шардинг часто рекламируется как решение, которое бесконечно масштабируется в зависимости от числа узлов, участвующих в работе сети. Хотя теоретически возможно разработайте такое решение для шардинга, любое решение, имеющее концепцию маяка Chain не имеет бесконечной масштабируемости. Чтобы понять почему, обратите внимание, что Маяк цепочка должна выполнить некоторые бухгалтерские вычисления, например назначить validators осколки или блоки цепочки осколков моментальных снимков, пропорциональные количеству шардов в системе. Поскольку цепочка Beacon сама по себе представляет собой единый blockchain, с вычисление ограничено вычислительными возможностями узлов, управляющих им, количество осколков естественно ограничено. Однако структура сегментированной сети действительно обеспечивает мультипликативную влияние на любые улучшения его узлов. Рассмотрим случай, когда произвольный улучшена эффективность узлов в сети, что позволит им более быстрое время обработки транзакций. Если узлы, управляющие сетью, включая узлы в цепочке Beacon, станет в четыре раза быстрее, тогда каждый шард сможет обработать в четыре раза больше транзакций, а цепочка Beacon сможет поддерживать в 4 раза больше шардов. Пропускная способность системы увеличится в 4 × 4 = 16 — отсюда и название квадратичного шардинга. Трудно дать точную оценку количества осколков. жизнеспособна сегодня, но маловероятно, что в обозримом будущем пропускная способность потребности пользователей blockchain перерастут ограничения квадратичного сегментирования. Огромное количество узлов, необходимых для безопасной работы с таким объемом шардов. вероятно, на порядки превышает количество узлов, работающих на всех Сегодня blockchains вместе взятых. 1.3 Государственное шардинг До сих пор мы не очень хорошо определили, что именно является отделенным и неразделенным. когда сеть разделена на сегменты. В частности, узлы в blockchain выполняют три важные задачи: они не только 1) обрабатывают транзакции, но и также 2) ретранслировать проверенные транзакции и завершенные блоки на другие узлы и 3) хранить состояние и историю всей сетевой книги. Каждый из этих трёх задач предъявляет возрастающие требования к узлам, эксплуатирующим сеть:1. Необходимость обработки транзакций требует большей вычислительной мощности с увеличение количества обрабатываемых транзакций; 2. Необходимость ретрансляции транзакций и блоков требует увеличения пропускной способности сети с увеличением количества ретранслируемых транзакций; 3. Необходимость хранения данных требует большего объема памяти по мере роста штата. Важно отметить, что в отличие от вычислительной мощности и сети, требования к хранилищу растут, даже если скорость транзакций (количество обработанных транзакций) в секунду) остается постоянным. Из приведенного выше списка может показаться, что требования к хранению будут самый актуальный, поскольку он единственный, который со временем увеличивается даже если количество транзакций в секунду не изменится, но на практике Самым насущным требованием сегодня является вычислительная мощность. Все состояние Ethereum на момент написания этой статьи имеет размер 100 ГБ, которым легко управляет большинство узлов. Но количество транзакций, которые Ethereum может обработать, составляет около 20, заказы величина меньше, чем это необходимо для многих практических случаев использования. Zilliqa — самый известный проект, который занимается обработкой, а не хранением данных. Разделение обработки является более простой задачей, поскольку каждый узел имеет всю состояние, что означает, что контракты могут свободно вызывать другие контракты и читать любые данные. из blockchain. Для обеспечения обновлений необходимы некоторые тщательные инженерные разработки. из нескольких шардов, обновляющих одни и те же части состояния, не конфликтуют. В В этом отношении Zilliqa придерживается относительно упрощенного подхода2. Хотя было предложено сегментирование хранилища без сегментирования обработки, это крайне редко. Таким образом, на практике шардинг хранилища, или State Sharding, почти всегда подразумевает сегментирование обработки и сегментирование сети. Практически при государственном шардинге узлы в каждом шарде строят свои собственный blockchain, содержащий транзакции, затрагивающие только локальную часть глобальное состояние, назначенное этому осколку. Следовательно, validator в шарду нужно только хранить свою локальную часть глобального состояния и только выполнять, и, как таковые, только ретранслируют транзакции, которые затрагивают их часть состояния. Это раздел линейно снижает требования ко всем вычислительным мощностям, хранилищам и пропускной способности сети, но создает новые проблемы, такие как доступность данных и транзакции между сегментами, обе из которых мы рассмотрим ниже. 1,4 Межсегментные транзакции Модель сегментирования, которую мы описали до сих пор, не очень полезна, потому что, если отдельные осколки не могут общаться друг с другом, они не лучше, чем несколько независимые blockchains. Даже сегодня, когда шардинг недоступен, существует огромный спрос на совместимость между различными blockchain. Давайте пока рассмотрим только простые платежные транзакции, где каждый участник имеет счет ровно на одном шарде. Если вы хотите перевести деньги с 2Наш анализ их подхода можно найти здесь: https://medium.com/nearprotocol/. 8f9efae0ce3bодин аккаунт на другой в пределах одного шарда, транзакция может быть обработана полностью validator в этом осколке. Однако если Алиса, находящаяся на шарде

1 хочет отправить деньги Бобу, который находится на шарде #2, ни validators

на шарде №1 (они не смогут пополнить счет Боба), ни validator на шард №2 (списать со счета Алисы они не смогут) может обработать весь транзакция. Существует два семейства подходов к межсегментным транзакциям: • Синхронный: всякий раз, когда необходимо выполнить транзакцию между сегментами, блоки в нескольких осколках, которые содержат переход состояния, связанный с Все транзакции производятся одновременно, и validator нескольких шардов совместно выполняют такие транзакции.3 • Асинхронный: транзакция между сегментами, которая затрагивает несколько сегментов. выполняется в этих сегментах асинхронно, при этом сегмент «Кредит» выполняется свою половину, как только у него будет достаточно доказательств того, что «Дебетовый» осколок выполнил свою часть. Этот подход имеет тенденцию быть более распространенным из-за его простота и удобство координации. Сегодня эта система предлагается в Cosmos, Ethereum Serenity, Near, Kadena и других. Проблема с этим подход заключается в том, что если блоки создаются независимо, существует ненулевая вероятность того, что один из нескольких блоков окажется осиротевшим, что делает сделка применена лишь частично. Рассмотрим рисунок 2, на котором изображены два шарды, оба из которых столкнулись с форком, и транзакция между шардами что было записано в блоках А и Х’ соответственно. Если цепи A-B и V’-X’-Y’-Z’ становятся каноническими в соответствующих осколках, сделка полностью завершена. Если A’-B’-C’-D’ и V-X станут каноническими, тогда транзакция полностью прекращается, что приемлемо. Но если для Например, A-B и V-X становятся каноническими, затем одна часть транзакции завершается, а другая отменяется, что приводит к сбою атомарности. Мы во второй части будет рассмотрено, как эта проблема решается в предлагаемых протоколах, при освещении изменений в правилах выбора форка и консенсусе. алгоритмы, предложенные для сегментированных протоколов. Обратите внимание, что связь между цепочками полезна за пределами сегментированных blockchains. тоже. Взаимодействие между цепочками — сложная проблема, которую решают многие проекты. пытаются решить. В сегментированных blockchain проблема несколько проще, поскольку структура блоков и консенсус одинаковы во всех шардах, и есть цепочка маяков, которую можно использовать для координации. Однако в сегментированном blockchain все шардчейны одинаковы, тогда как в глобальной экосистеме blockchains есть множество разных blockchain с разными целевыми вариантами использования, децентрализацией и гарантии конфиденциальности. Построение системы, в которой набор цепей имеет разные свойства, но использовать достаточно похожий консенсус и структуру блоков, а также иметь общую цепочку маяков, что может создать экосистему гетерогенных blockchain, которые имеют 3The большинство подробный предложение известный чтобы тот авторы из это документ есть Объединить Блоки, описал здесь: https://ethresear.ch/t/ слияние блоков и синхронное выполнение между состояниями сегментов / 1240Рисунок 2: Асинхронные транзакции между сегментами рабочая подсистема взаимодействия. Такая система вряд ли будет поддерживать ротацию validator, поэтому необходимо принять некоторые дополнительные меры для обеспечения безопасности. оба Cosmos и PolkaDot являются такими системами4. 1,5 Вредоносное поведение В этом разделе мы рассмотрим, какое состязательное поведение может привести к вредоносным validators. упражнения, если им удастся повредить осколок. Мы рассмотрим классические подходы чтобы избежать повреждения осколков в разделе 2.1. 1.5.1 Вредоносные форки Набор вредоносных validator может попытаться создать форк. Обратите внимание, что это не так имеет значение, является ли основной консенсус BFT или нет, искажая достаточное число из validators всегда позволит создать вилку. Значительно более вероятно, что будет повреждено более 50% одного шарда, чем более 50% всей сети (мы будем углубимся в эти вероятности в разделе 2.1). Как обсуждалось в разделе 1.4, Транзакции между сегментами включают определенные изменения состояния в нескольких сегментах, и соответствующие блоки в таких шардах, которые применяют такие изменения состояния, должны либо все будут финализированы (т.е. появятся в выбранных цепочках в соответствующих им местах). шарды), либо все станут сиротами (т.е. не появятся в выбранных цепочках на соответствующих шардах). Поскольку обычно вероятность повреждения осколков 4Обратитесь к этой статье Заки Маниана из Cosmos: https://forum.cosmos.network/. t/polkadot-vs-cosmos/1397/2 и этот твит-шторм от первого автора этого документа: https://twitter.com/AlexSkidanov/status/1129511266660126720 для подробного сравнения из двух

не является незначительным, мы не можем предполагать, что форков не произойдет, даже если среди шардов validator был достигнут византийский консенсус или было много блоков. производится поверх блока с изменением состояния. Эта проблема имеет несколько решений, наиболее распространенным из которых является случайный перекрестное связывание последнего блока шардчейна с маяковой цепочкой. Вилка правило выбора в цепочках шардов затем изменяется, чтобы всегда отдавать предпочтение той цепочке, которая перекрестными ссылками и применять правило выбора форка, специфичное для сегмента, только для блоков, которые были опубликовано с момента последней перекрестной ссылки. 1.5.2 Утверждение недействительных блоков Набор validator может попытаться создать блок, который неправильно применяет функцию перехода состояния. Например, начиная с состояния, в котором Алиса имеет 10 token, а у Боба 0 token, блок может содержать транзакцию, которая отправляет 10 token от Алисы Бобу, но в конечном итоге оказывается в состоянии, в котором Алиса 0 tokens, а у Боба 1000 tokens, как показано на рисунке 3. Рисунок 3: Пример недопустимого блока В классическом нешардинговом blockchain такая атака невозможна, так как все участник сети проверяет все блоки, а блок с таким недопустимый переход состояния будет отклонен обоими другими производителями блоков, и участники сети, не создающие блоки. Даже если злонамеренный validator продолжают создавать блоки поверх такого недействительного блока быстрее, чем честные validators строят правильную цепочку, таким образом получая цепочку с невалидной если блок длиннее, это не имеет значения, поскольку каждый участник, использующий blockchain для любых целей проверяет все блоки и отбрасывает все блоки. построен поверх недействительного блока. На рисунке 4 показаны пять validator, три из которых вредоносные. Они создал недопустимый блок A’, а затем продолжил создавать новые блоки сверху этого. Два честных validators отбросили A’ как недействительный и начали строить сверхуРисунок 4: Попытка создать недопустимый блок в несегментированном blockchain. последнего известного им действующего блока, создавая форк. Поскольку их меньше validators в честном развилке, их цепочка короче. Однако в классическом несегментированном blockchain каждый участник, использующий blockchain для каких-либо целей, отвечает за проверку всех полученных блоков и пересчет состояния. Таким образом, любой человек, проявляющий интерес к blockchain, заметит, что A’ недействителен, и поэтому также немедленно отбрасываем B’, C’ и D’ как таковые, принимая цепочка A-B как текущая самая длинная действительная цепочка. Однако в сегментированном blockchain ни один участник не может проверить все транзакции на всех сегментах, поэтому у них должен быть какой-то способ подтвердить это ни при каких обстоятельствах. точка в истории любого фрагмента blockchain, ни один недопустимый блок не был включен. Обратите внимание, что в отличие от форков, перекрестная привязка к цепочке Beacon не является достаточным решением, поскольку цепочка Beacon не имеет возможности проверять блоки. Он может только подтвердить, что достаточное количество __PH_0006____ в этом сегменте подписал блок (и тем самым подтвердил его правильность). Мы обсудим решения этой проблемы в разделе 2.2 ниже.

Durum Geçerliliği ve Veri Kullanılabilirliği

Parçalanmış blockchain'lerdeki temel fikir, çoğu katılımcının işletim veya ağı kullanmak tüm parçalardaki blokları doğrulayamaz. Bu nedenle, ne zaman olursa olsun herhangi bir katılımcının genellikle yapamadığı belirli bir parçayla etkileşime girmesi gerekir Parçanın tüm geçmişini indirin ve doğrulayın. Bununla birlikte, parçalamanın bölümleme yönü önemli bir potansiyel ortaya çıkarmaktadır. sorun: belirli bir uygulamanın tüm geçmişini indirmeden ve doğrulamadan katılımcının parçanın bulunduğu durumdan mutlaka emin olması mümkün değildir. 5Bu bölüm, alt bölüm 2.5.3 hariç, daha önce https://near.ai/ adresinde yayınlanmıştır. parça2. Daha önce okuduysanız bir sonraki bölüme geçin.

etkileşime girmeleri bazı geçerli blok dizilerinin sonucudur ve bu dizi Blok sayısı gerçekten de parçadaki kanonik zincirdir. Çözülmeyen bir sorun parçalanmamış bir blockchain içinde mevcut. Öncelikle bu soruna önerilen basit bir çözüm sunacağız. birçok protokole göre analiz edin ve ardından bu çözümün nasıl bozulabileceğini ve ne olacağını analiz edin. giderilmesine yönelik girişimlerde bulunuldu. 2.1 Doğrulayıcıların rotasyonu Durum geçerliliğine yönelik saf çözüm şekil 5'te gösterilmektedir: diyelim ki tüm sistemde binlerce validators var, bunlardan %20'den fazlası kötü niyetli değildir veya başka şekilde başarısız olacaktır (örneğin, Bir blok oluşturmak için çevrimiçi). O zaman 200 validators örnek alırsak olasılık 1'den fazla 3 pratik amaçlar açısından başarısızlığın sıfır olduğu varsayılabilir. Şekil 5: Örnekleme validators 1 3 önemli bir eşik. Bir mutabakat protokolü ailesi var. BFT fikir birliği protokolleri; bu, 1'den az olduğu sürece bunu garanti eder 3'ü Katılımcılar ya kaza yaparak ya da kuralları ihlal eden bir şekilde hareket ederek başarısız olurlar. Protokolde fikir birliğine varılacak. Bu dürüst validator yüzdelik varsayımla, eğer mevcut Saf çözüm, bir parçadaki validators'nin bize bir miktar blok sağladığını varsayar bloğun geçerli olduğunu ve validators olduğuna inanılanlar üzerine inşa edildiğini doğrulamaya başladıklarında söz konusu parçanın standart zinciri. validator'lar kanonik zinciri önceki validators kümesinden öğrendi; Kanonik zincirin başı olan bloğun üzerine inşa edilen varsayım ondan önce. Tümevarımla zincirin tamamı geçerlidir ve validators kümesi olmadığından Çatal üretilen herhangi bir noktada, naif çözüm aynı zamanda mevcut olanın da kesin olduğudur. zincir, parçadaki tek zincirdir. Görselleştirme için şekil 6'ya bakın.

Şekil 6: Her bloğun BFT fikir birliğiyle sonlandırıldığı bir blockchain validators'nin olabileceğini varsayarsak bu basit çözüm işe yaramaz. uyumsal olarak bozulmuştur ki bu mantıksız bir varsayım değildir6. Uyarlanabilir 1000 parçadan oluşan bir sistemde tek bir parçayı bozmak çok daha ucuzdur tüm sistemi bozmak yerine. Bu nedenle protokolün güvenliği, parça sayısı arttıkça doğrusal olarak azalır. Geçerliliğinden emin olmak için bir blok, tarihin herhangi bir noktasında sistemdeki hiçbir parçanın olmadığını bilmeliyiz. validator'ların çoğunluğu gizli anlaşma yapıyor; uyarlanabilir düşmanlarla artık elimizde değil öyle bir kesinlik ki. Bölüm 1.5'te tartıştığımız gibi, validators ile gizli anlaşma yapmak işe yarayabilir iki temel kötü niyetli davranış: çatallar oluşturmak ve geçersiz bloklar üretmek. Kötü niyetli çatallanmalar, blokların genel olarak diğerlerine göre önemli ölçüde daha yüksek güvenliğe sahip olacak şekilde tasarlanan Beacon zincirine çapraz bağlanmasıyla ele alınabilir. kırık zincirler. Geçersiz bloklar üretmek ise önemli ölçüde daha fazla bir sorundur. üstesinden gelinmesi zor bir sorun. 2.2 Durum Geçerliliği 1. Parçanın bozulduğu ve kötü niyetli bir aktörün ürettiği Şekil 7'yi düşünün. geçersiz blok B. Diyelim ki bu B bloğunda 1000 tokens yoktan basıldı Alice'in hesabında yayın. Kötü niyetli aktör daha sonra geçerli C bloğunu üretir (bir C'deki işlemlerin doğru bir şekilde uygulandığını hissetmek) B'nin yanı sıra kafa karıştırıcı geçersiz B bloğunu kullanır ve Parça #2'ye bir çapraz parça işlemi başlatır. bu 1000 tokens'yi Bob'un hesabına aktarır. Bu andan itibaren uygunsuz bir şekilde oluşturulan token'ler, Parça #2'deki tamamen geçerli bir blockchain üzerinde bulunuyor. Bu sorunu çözmeye yönelik bazı basit yaklaşımlar şunlardır: 6Oku bu makale için ayrıntılar üzerinde nasıl uyarlanabilir yolsuzluk yapabilir olmak taşınan dışarı: https://medium.com/nearprotocol/d859adb464c8. için daha fazla ayrıntılar üzerinde uyarlanabilir yolsuzluk, okumak https://github.com/ethereum/wiki/wiki/Sharding-FAQ# altında-çalıştığımız-güvenlik modelleri nelerdirŞekil 7: Geçersiz bloğu olan bir zincirden gelen parçalar arası işlem 1. İşlemin yapıldığı bloğu doğrulamak amacıyla validators Parça #2 için başlatılır. Bu yukarıdaki örnekte bile işe yaramayacaktır çünkü C bloğu tamamen geçerli olduğu görülmektedir. 2. İşlemin başlatıldığı bloktan önceki çok sayıda bloğu doğrulamak için Parça #2'deki validators için. Doğal olarak, kötü niyetli alıcı parça tarafından doğrulanan herhangi bir sayıda blok N validators, geçersiz bloğun üstünde N+1 geçerli blok oluşturabilir üretildi. Bu sorunu çözmek için umut verici bir fikir, parçaları bir düzende düzenlemek olacaktır. her bir parçanın diğer birkaç parçaya bağlandığı yönlendirilmemiş grafik ve yalnızca komşu parçalar arasında çapraz parça işlemlerine izin ver (ör. Vlad Zamfir'in parçalaması esasen işe yarıyor7 ve benzer fikir Kadena'nınkinde de kullanılıyor Chainweb [1]). Parçalar arasında parçalar arası bir işlem gerekiyorsa komşular değil, bu tür işlemler birden fazla parça aracılığıyla yönlendirilir. Bu tasarımda Her bir parçadaki bir validator'nin, kendi parçalarındaki tüm blokları doğrulaması bekleniyor ve ayrıca tüm komşu parçalardaki tüm bloklar. Aşağıdaki şekli düşünün 10 parçadan oluşan, her birinin dört komşusu olan ve daha fazlasını gerektiren iki parçanın olmadığı Şekil 8'de gösterilen çapraz parça iletişimi için ikiden fazla atlama. Parça #2 yalnızca kendi blockchain parçasını değil aynı zamanda blockchain parçasını da doğruluyor 1 numaralı Parça dahil tüm komşular. Yani Parça #1'de kötü niyetli bir aktör varsa geçersiz bir B bloğu oluşturmaya çalışıyor, ardından bunun üzerine C bloğunu inşa ediyor ve parçalar arası bir işlem başlatın, bu tür parçalar arası işlem gerçekleşmeyecek Parça #2'den beri Parça #1'in tüm geçmişi doğrulanmış olacak. geçersiz B bloğunu tanımlamasına neden olacaktır. 7Tasarım hakkında daha fazla bilgiyi burada bulabilirsiniz: https://medium.com/nearprotocol/37e538177ed9

Şekil 8: Chainweb benzeri sistemde geçersiz bir çapraz parça işlemi tespit edilmek Tek bir parçayı bozmak artık geçerli bir saldırı olmasa da, bir parçayı bozmak artık geçerli bir saldırı değildir. birkaç parça sorun olmaya devam ediyor. Şekil 9'da bir düşman her iki Shard'ı da bozuyor

1 ve Parça #2, Parça #3'e yönelik bir çapraz parça işlemini başarıyla yürütür

geçersiz bir B bloğundan gelen fonlarla: Şekil 9: Chainweb benzeri sistemde geçersiz bir çapraz parça işlemi tespit edilmemek Parça #3, Parça #2'deki tüm blokları doğrular ancak Parça #1'deki tüm blokları doğrular ve kötü amaçlı bloğu tespit etmenin bir yolu yoktur. Durum geçerliliğini doğru şekilde çözmenin iki ana yönü vardır: balıkçılar

ve hesaplamanın kriptografik kanıtları. 2.3 Balıkçı İlk yaklaşımın arkasındaki fikir şudur: ne zaman bir blok başlığı Herhangi bir amaç için zincirler arasında iletilir (örneğin çapraz bağlanma gibi). işaret zinciri veya parçalar arası bir işlem), bu sırada belirli bir süre vardır dürüst herhangi bir validator bloğun geçersiz olduğuna dair kanıt sağlayabilir. Orada blokların çok kısa ve öz kanıtlarını sağlayan çeşitli yapılardır. geçersiz olduğundan alıcı düğümlerin iletişim yükü çok daha küçüktür tam bir blok almaktan daha fazla. En az bir dürüst validator olduğu sürece bu yaklaşımla Shard, sistem güvenlidir. Şekil 10: Balıkçı Bu, bugün önerilen protokoller arasında (sorun yokmuş gibi davranmanın yanı sıra) baskın yaklaşımdır. Ancak bu yaklaşımın iki önemli dezavantajlar: 1. Dürüst validator için meydan okuma süresinin yeterince uzun olması gerekir Bir bloğun üretildiğini tanımak, onu indirmek, tamamen doğrulamak ve hazırlamak blok geçersizse meydan okuma. Böyle bir dönemin getirilmesi Parçalar arası işlemleri önemli ölçüde yavaşlatır. 2. Challenge protokolünün varlığı yeni bir saldırı vektörü yaratıyor Kötü niyetli düğümler geçersiz sorgulamalarla spam yaptığında. Açık bir çözüm Bu sorunun çözümü, meydan okuyanların bir miktar tokens yatırmasını sağlamaktır. meydan okuma geçerliyse iade edilir. Bu yalnızca kısmi bir çözümdür, çünkü saldırganın sisteme spam göndermesi (ve yakması) yine de faydalı olabilir. örneğin geçerli işlemleri engellemek için geçersiz sorgulamalarla yapılan para yatırma işlemleri)dürüst bir validator'dan gelen meydan okuma. Bu saldırılar Kederli Saldırılar denir. İkinci noktayı aşmanın bir yolu için bölüm 3.7.2'ye bakın. 2.4 Kısa ve Etkileşimli Olmayan Bilgi Argümanları Çoklu parça bozulmasına karşı ikinci çözüm, belirli bir hesaplamanın (örneğin, bir dizi işlemden bir bloğun hesaplanması gibi) doğru bir şekilde gerçekleştirildi. Bu tür yapılar mevcuttur; zk-SNARK'lar, zk-STARK'lar ve birkaç kişi daha, ve bazıları bugün blockchain protokollerinde özel ödemeler için aktif olarak kullanılıyor, en önemlisi ZCash. Bu tür ilkellerle ilgili temel sorun, onların hesaplamanın oldukça yavaş olduğu biliniyor. Örn. zk-SNARK'ları kullanan Coda Protokolü özellikle blockchain içindeki tüm blokların geçerli olduğunu kanıtlamak için, birinde söylendi Kanıt oluşturmanın işlem başına 30 saniye sürebileceği görüşmelerden (bu sayı muhtemelen şimdiye kadar daha küçüktür). İlginç bir şekilde, bir kanıtın güvenilir bir tarafça hesaplanmasına gerek yoktur, çünkü Kanıt yalnızca oluşturulduğu hesaplamanın geçerliliğini kanıtlamakla kalmaz, aynı zamanda kanıtın kendisinin geçerliliği. Dolayısıyla bu tür kanıtların hesaplanması bölünebilir önemli ölçüde daha az yedekliliğe sahip bir grup katılımcı arasında bazı güvenilir hesaplamalar yapmak için gereklidir. Aynı zamanda katılımcıların zk-SNARK'ları özel donanım üzerinde çalışacak şekilde hesaplayanlar sistemin ademi merkeziyetçiliği. zk-SNARK'ların performansın yanı sıra karşılaştığı zorluklar şunlardır: 1. Daha az araştırılmış ve daha az zaman içinde test edilmiş kriptografik temellere bağımlılık; 2. “Zehirli atık” — zk-SNARK'lar, bir grubun içinde bulunduğu güvenilir bir kuruluma bağlıdır İnsanların oranı bir miktar hesaplama yapıyor ve ardından ara hesaplamayı atıyor bu hesaplamanın değerleri. Prosedürün tüm katılımcıları gizli anlaşma yaparsa ve ara değerleri koruyarak sahte deliller oluşturulabilir; 3. Sistem tasarımına eklenen ekstra karmaşıklık; 4. zk-SNARK'lar yalnızca olası hesaplamaların bir alt kümesi için çalışır, dolayısıyla bir protokol Turing-complete smart contract dilini kullanamazsınız Zincirin geçerliliğini kanıtlamak için SNARK'lar. 2.5 Veri Kullanılabilirliği Değineceğimiz ikinci sorun veri kullanılabilirliğidir. Genellikle düğümler belirli bir blockchain çalıştıran iki gruba ayrılır: Tam Düğümler, her tam bloğu indiren ve her işlemi doğrulayanlar ve Light Yalnızca blok başlıklarını indiren ve parçalar için Merkle kanıtlarını kullanan düğümler Şekil 11'de gösterildiği gibi ilgilendikleri durum ve işlemler.

Şekil 11: Merkle Ağacı Artık tam düğümlerin çoğunluğu gizli anlaşma yaparsa geçerli veya geçerli bir blok üretebilirler. geçersizdir ve hash dosyasını hafif düğümlere gönderin, ancak içeriğin tamamını hiçbir zaman açıklamayın bloğun. Bundan faydalanabilecekleri çeşitli yollar vardır. Örneğin, Şekil 12'yi düşünün: Şekil 12: Veri Kullanılabilirliği sorunu Üç blok vardır: önceki A, dürüst validators tarafından üretilmiştir; mevcut B'nin validators gizli anlaşması var; ve bir sonraki C de üretilecek dürüst validators tarafından (blockchain sağ alt köşede gösterilmektedir). Sen bir tüccarsın. Geçerli bloğun (B) validator'leri alınan blok Önceki validator'lerden A, içinde para aldığınız bir blok hesapladı,ve size o bloğun başlığını, içinde bulunulan durumun Merkle kanıtıyla birlikte gönderdim. paranız var (veya parayı gönderen geçerli bir işlemin Merkle kanıtı) sana). İşlemin tamamlandığından emin olduğunuzda hizmeti sağlarsınız. Ancak validator'ler hiçbir zaman B bloğunun tam içeriğini dağıtmaz. herhangi biri. Bu nedenle, C bloğunun dürüst validator'leri bloğu geri alamaz ve ya sistemi durdurmaya zorlanırlar ya da A'nın üzerine inşa ederek sizi bir sistem olarak mahrum bırakırlar. para tüccarı. Aynı senaryoyu parçalamaya uyguladığımızda tam ve hafif düğüm genellikle parça başına uygulanır: her parça indirmesinde validators o parçada bloke edin ve o parçadaki her işlemi doğrulayın, ancak diğer parça zincirlerinin anlık görüntüsünü alan düğümler de dahil olmak üzere sistemdeki düğümler işaret zinciri, yalnızca başlıkları indirin. Böylece parçadaki validator'ler sistemdeki diğer katılımcılar bu parça için etkili bir şekilde tam düğümler oluştururken, işaret zinciri de dahil olmak üzere ışık düğümleri olarak çalışır. Yukarıda tartıştığımız balıkçı yaklaşımının işe yaraması için dürüst validators işaret zincirine çapraz bağlı blokları indirebilmeniz gerekir. Kötü niyetli validator'ler geçersiz bir bloğun başlığını çapraz bağladıysa (veya bunu kullandıysa) parçalar arası bir işlem başlatır), ancak bloğu asla dağıtmaz, dürüst validator'lerin bir meydan okuma oluşturmanın hiçbir yolu yok. Bu sorunu çözmek için birbirini tamamlayan üç yaklaşımı ele alacağız. Birbirimiz. 2.5.1 Velayet Kanıtları Çözülmesi gereken en acil sorun, bir bloğun bir kez kullanılabilir olup olmadığıdır. yayınlandı. Önerilen fikirlerden biri dönüşümlü Noterlere sahip olmaktır. tek işi bir dosya indirmek olan validator'lerden daha sık parçalar arasında engelleyin ve indirebildiklerini doğrulayın. Onlar olabilir tüm durumu indirmeleri gerekmediği için daha sık dönüşümlü olarak kullanılıyor parçanın aksine, sık sık döndürülemeyen validator'lerin aksine şekilde gösterildiği gibi her döndüklerinde parçanın durumunu indirmeleri gerekir 13. Bu naif yaklaşımın sorunu daha sonra kanıtlamanın imkansız olmasıdır. Noterin bloğu indirip indiremediğine bağlı olarak Noter bloğu indirebildiklerini her zaman onaylamayı seçebilirler. hatta onu geri almaya çalışıyorum. Bunun bir çözümü Noterlerin sağlamasıdır. bloğun olduğunu kanıtlayan bazı kanıtlar veya bir miktar tokens stake etmek indirildi. Böyle bir çözüm burada tartışılmaktadır: https://ethresear.ch/t/ 1 bitlik toplama dostu saklama tahvilleri/2236. 2.5.2 Silme Kodları Belirli bir ışık düğümü bir bloğun hash değerini aldığında, düğümün Bloğun mevcut olduğundan emin olmak için rastgele birkaç tane indirmeyi deneyebilir bloğun parçaları. Bu tam bir çözüm değil çünkü ışık düğümleri Kötü niyetli blok üreticilerinin seçebileceği bloğun tamamını toplu olarak indirin

Şekil 13: Doğrulayıcıların durumu indirmesi gerekir ve bu nedenle döndürülemez sık sık bloğun herhangi bir ışık düğümü tarafından indirilmeyen kısımlarını alıkoymak, böylece bloğu hala kullanılamaz hale getiriyoruz. Çözümlerden biri, bunu mümkün kılmak için Silme Kodları adı verilen bir yapıyı kullanmaktır. gösterildiği gibi bloğun yalnızca bir kısmı mevcut olsa bile tüm bloğu kurtarmak için Şekil 14'te. Şekil 14: Merkle tree silme kodlu veriler üzerine inşa edilmiştir Hem Polkadot hem de Ethereum Serenity'nin tasarımları bu fikir etrafında şekilleniyor: Hafif düğümlerin blokların mevcut olduğundan makul ölçüde emin olmaları için bir yol sağlar. Ethereum Serenity yaklaşımının ayrıntılı açıklaması [2]'da bulunmaktadır.2.5.3 Polkadot'nin veri kullanılabilirliğine yaklaşımı Polkadot'de, çoğu parçalı çözümde olduğu gibi, her parça (parachain olarak adlandırılır) bloklarının anlık görüntüsünü işaret zincirine (aktarma zinciri olarak adlandırılır) alır. Diyelim ki 2f + 1 var Aktarma zincirinde validators. Parachain bloklarının blok üreticileri, harmanlayıcılar, parachain bloğu üretildiğinde, herhangi bir f parçası yeterli olacak şekilde 2f +1 parçadan oluşan bloğun silme kodlu versiyonunu hesaplarlar. bloğu yeniden inşa etmek için. Daha sonra her validator'e bir parça dağıtırlar. röle zinciri. Belirli bir geçiş zinciri validator yalnızca bir geçiş zincirinde imza atar anlık görüntüsü alınan her parachain bloğu için kendi paylarına sahiplerse bloklayın böyle bir röle zinciri bloğu. Dolayısıyla, eğer bir aktarma zinciri bloğu 2f + 1'den imzalara sahipse validators ve bunlardan en fazla f tanesi protokolü ihlal etmediği sürece, her biri parachain bloğu validators'den parçalar alınarak yeniden oluşturulabilir protokolü takip edenler. Bkz. şekil 15. Şekil 15: Polkadot'nin veri kullanılabilirliği 2.5.4 Uzun vadeli veri kullanılabilirliği Yukarıda tartışılan tüm yaklaşımların yalnızca bir bloğun olduğu gerçeğini doğruladığını unutmayın. yayınlandı ve şu anda mevcut. Bloklar daha sonra kullanılamayabilir çeşitli nedenlerden dolayı: düğümlerin devre dışı kalması, düğümlerin kasıtlı olarak geçmişi silmesi veriler ve diğerleri. Bu sorunu ele alan bahsetmeye değer bir teknik inceleme Polyshard [3]'dir, birden fazla parça olsa bile blokların parçalar arasında kullanılabilir olmasını sağlamak için silme kodlarını kullanan Parçalar verilerini tamamen kaybeder. Ne yazık ki onların özel yaklaşımı şunu gerektirir: diğer tüm parçalardan blok indirmek için tüm parçalar, bu da yasaklayıcı bir şekilde pahalı. Uzun vadeli kullanılabilirlik o kadar acil bir sorun değil: hiçbir katılımcı olmadığı için Sistemin tüm zincirlerdeki tüm zincirleri doğrulayabilmesi bekleniyor.

Parçalanmış protokollerin güvenliğinin böyle bir şekilde tasarlanması gerekir. bazı parçalardaki bazı eski bloklar bozulsa bile sistemin güvenli kalmasının bir yolu tamamen kullanılamaz.

Государственная достоверность и доступность данных

Основная идея сегментированных blockchain заключается в том, что большинство участников, работающих или использование сети не может проверить блоки во всех сегментах. Таким образом, всякий раз, когда любому участнику необходимо взаимодействовать с конкретным шардом, который он обычно не может загрузите и проверьте всю историю осколка. Однако аспект секционирования при шардинге открывает значительный потенциал. проблема: без скачивания и проверки всей истории конкретного шард участник не обязательно может быть уверен, что состояние, с которым 5Данный раздел, за исключением подраздела 2.5.3, ранее был опубликован по адресу https://near.ai/. осколок2. Если вы читали это раньше, перейдите к следующему разделу.

они взаимодействуют, является результатом некоторой допустимой последовательности блоков, и эта последовательность блоков действительно является канонической цепочкой в шарде. Проблема, которой нет существуют в несегментированном blockchain. Сначала мы представим простое решение этой проблемы, которое было предложено по множеству протоколов, а затем проанализировать, как это решение может сломаться и что были предприняты попытки решить эту проблему. 2.1 Ротация валидаторов Наивное решение проблемы валидности состояния показано на рисунке 5: скажем, мы предположим, что что вся система имеет порядка тысяч validator, из которых не более 20% являются вредоносными или потерпят неудачу по другим причинам (например, из-за невозможности онлайн для создания блока). Тогда, если мы выберем 200 validators, вероятность более 1 3 для практических целей можно принять равным нулю. Рисунок 5: Выборка validators 1 3 – важный порог. Существует семейство консенсусных протоколов, называемое BFT протоколы консенсуса, которые гарантируют, что до тех пор, пока меньше 1 3 из участники терпят неудачу либо из-за сбоя, либо из-за действий, нарушающих правила. протокол, консенсус будет достигнут. При этом предположении о честном validator проценте, если текущий набор validators в шарде предоставляют нам некоторый блок, предполагает наивное решение что блок действителен и что он построен на основе того, что считали validators каноническую цепочку для этого шарда, когда они начали проверять. validators изучил каноническую цепочку из предыдущего набора validators, которые тем же предположение, построенное на вершине блока, который был главой канонической цепочки до этого. По индукции вся цепочка действительна, и поскольку ни один набор validators в любой момент создаются вилки, наивное решение также уверено, что текущий Chain — единственная цепочка в шарде. См. рисунок 6 для визуализации.

Рисунок 6: blockchain, где каждый блок завершается консенсусом BFT. Это простое решение не сработает, если мы предположим, что validators могут быть повреждаются адаптивно, что не является необоснованным предположением6. Адаптивно повреждение одного шарда в системе с 1000 шардами обходится значительно дешевле. чем развращать всю систему. Таким образом, безопасность протокола снижается линейно с увеличением количества шардов. Чтобы быть уверенным в достоверности блок, мы должны знать, что в любой момент истории ни один шард в системе не большинство validator в сговоре; с адаптивными противниками у нас больше нет такая уверенность. Как мы обсуждали в разделе 1.5, вступившие в сговор validator могут осуществлять два основных вредоносных действия: создание разветвлений и создание недействительных блоков. Вредоносные форки могут быть устранены путем присоединения блоков к цепочке Beacon, которая обычно спроектирована так, чтобы обеспечить значительно более высокий уровень безопасности, чем цепочки осколков. Однако создание недействительных блоков является значительно более сложной задачей. сложная проблема, требующая решения. 2.2 Государственная действительность Рассмотрим рисунок 7, на котором шард №1 поврежден и злоумышленник создает недействительный блок B. Предположим, в этом блоке B было отчеканено 1000 token из тонких air за счет Алисы. Затем злоумышленник создает действительный блок C (в ощущение, что транзакции в C применяются правильно) поверх B, что запутывает недействительный блок B и инициирует межшардовую транзакцию с шардом №2, которая переводит эти 1000 __PH_0006__s на счет Боба. С этого момента неправильно созданные token находятся на полностью допустимом в остальном blockchain в осколке №2. Вот несколько простых способов решения этой проблемы: 6Читать это статья для детали на как адаптивный коррупция может быть нес выход: https://medium.com/nearprotocol/d859adb464c8. Для больше детали на адаптивный коррупция, читать https://github.com/ethereum/wiki/wiki/Sharding-FAQ# какие-модели-безопасности-мы-действуемРисунок 7: Межшардовая транзакция из цепочки с недействительным блоком 1. Для validator шарда №2 для проверки блока, из которого была выполнена транзакция. инициируется. Это не сработает даже в примере выше, так как блок C представляется вполне верным. 2. Для validator в шарде №2 для проверки большого количества блоков, предшествующих блоку, из которого инициируется транзакция. Естественно, для любое количество блоков N, проверенное принимающим шардом, вредоносный validators могут создавать N+1 действительных блоков поверх недействительного блока, который они произведено. Многообещающей идеей решения этой проблемы было бы объединение шардов в неориентированный граф, в котором каждый шард связан с несколькими другими шардами, и разрешать только межшардовые транзакции между соседними шардами (например, так Шардинг Влада Замфира по существу работает7, и аналогичная идея используется в методе Кадены. Цепная паутина [1]). Если необходима межшардовая транзакция между шардами, которые не соседи, такая транзакция маршрутизируется через несколько сегментов. В этом дизайне Ожидается, что validator в каждом сегменте будет проверять оба блока в их сегменте. а также все блоки во всех соседних шардах. Рассмотрим рисунок ниже с 10 шардами, каждый из которых имеет по четыре соседа, и никакие два шарда не требуют больше чем два прыжка для связи между сегментами, показанной на рисунке 8. Шард №2 проверяет не только свой собственный blockchain, но и blockchain все соседи, включая Осколок №1. Итак, если злоумышленник на Осколке №1 пытается создать недопустимый блок B, а затем построить блок C поверх него и инициировать межшардовую транзакцию, такая межшардовая транзакция не пройдет поскольку Шард №2 подтвердит всю историю Шарда №1, которая заставит его идентифицировать недействительный блок B. 7Подробнее о дизайне читайте здесь: https://medium.com/nearprotocol/37e538177ed9

Рисунок 8: Недействительная межсегментная транзакция в системе, похожей на цепную сеть, которая будет быть обнаруженным Хотя повреждение одного осколка больше не является жизнеспособной атакой, повреждение несколько осколков остаются проблемой. На рисунке 9 противник портит оба Шарда №1 и шард №2 успешно выполняют межсегментную транзакцию с шардом №3. со средствами из невалидного блока Б: Рисунок 9: Недействительная межсегментная транзакция в системе, похожей на цепную сеть, которая будет не быть обнаруженным Шард №3 проверяет все блоки в Шарде №2, но не в Шарде №1, и не имеет возможности обнаружить вредоносный блок. Есть два основных направления правильного решения государственной действительности: рыбаки

и криптографические доказательства вычислений. 2.3 Рыбак Идея первого подхода заключается в следующем: всякий раз, когда заголовок блока передается между цепочками для любых целей (например, сшивание с цепочке маяков или транзакции между шардами), существует период времени, в течение которого который любой честный validator может предоставить доказательство того, что блок недействителен. Там представляют собой различные конструкции, которые позволяют очень кратко доказать, что блоки недействителен, поэтому накладные расходы на связь для принимающих узлов намного меньше чем получение полного блока. При таком подходе до тех пор, пока в сети есть хотя бы один честный validator осколок, система безопасна. Рисунок 10: Рыбак Это доминирующий подход (помимо притворства, что проблемы не существует) среди предлагаемых сегодня протоколов. Однако этот подход имеет два основные недостатки: 1. Период проверки должен быть достаточно длительным для честного validator. распознать, что блок был создан, загрузить его, полностью проверить и подготовить вызов, если блок недействителен. Введение такого периода позволит значительно замедляют межсегментные транзакции. 2. Существование протокола вызова создает новый вектор атак. когда злонамеренные узлы спамят недействительными вызовами. Очевидное решение Чтобы решить эту проблему, нужно заставить претендентов внести некоторую сумму tokens, которая возвращаются, если вызов действителен. Это лишь частичное решение, так как оно злоумышленнику все равно может быть выгодно рассылать спам по системе (и сжигать депозиты) с недействительными проблемами, например, для предотвращения действительноговызов от честного validator прохождения. Эти атаки называемые «Атаки скорби». См. раздел 3.7.2, чтобы узнать, как обойти последний пункт. 2.4 Краткие неинтерактивные аргументы знаний Второе решение проблемы повреждения нескольких сегментов — использовать какие-то криптографические конструкции, позволяющие доказать, что определенное вычисление (например, как вычисление блока из набора транзакций) было проведено корректно. Такие конструкции существуют, напр. zk-SNARKs, zk-STARKs и некоторые другие, а некоторые сегодня активно используются в протоколах blockchain для частных платежей, в первую очередь ZCash. Основная проблема с такими примитивами заключается в том, что они известны своей медленностью вычислений. Например. Протокол Coda, использующий zk-SNARK специально для того, чтобы доказать, что все блоки в blockchain действительны, сказано в одном интервью, что для создания доказательства может потребоваться 30 секунд на одну транзакцию (сейчас это число, вероятно, меньше). Интересно, что доказательство не обязательно должно быть вычислено доверенной стороной, поскольку доказательство не только подтверждает достоверность вычислений, для которых оно построено, но и достоверность самого доказательства. Таким образом, вычисление таких доказательств можно разделить среди набора участников со значительно меньшей избыточностью, чем было бы необходимо выполнить некоторые ненадежные вычисления. Это также позволяет участникам которые вычисляют zk-SNARK для работы на специальном оборудовании без снижения децентрализация системы. Проблемы zk-SNARK, помимо производительности, заключаются в следующем: 1. Зависимость от менее исследованных и менее проверенных временем криптографических примитивов; 2. «Токсичные отходы» — zk-SNARK зависят от доверенной установки, в которой группа людей выполняет некоторые вычисления, а затем отбрасывает промежуточные значения этого вычисления. Если все участники процедуры вступили в сговор и сохраняйте промежуточные значения, могут быть созданы фальшивые доказательства; 3. Дополнительная сложность, вносимая в конструкцию системы; 4. zk-SNARK работают только для подмножества возможных вычислений, поэтому протокол с полным по Тьюрингу языком smart contract невозможно было бы использовать SNARK для подтверждения достоверности цепочки. 2,5 Доступность данных Вторая проблема, которую мы затронем, — доступность данных. Обычно узлы эксплуатирующие конкретный blockchain, разделены на две группы: полные узлы, те, которые загружают каждый полный блок и проверяют каждую транзакцию, и Light Узлы, которые загружают только заголовки блоков и используют доказательства Меркла для частей. состояния и транзакций, в которых они заинтересованы, как показано на рисунке 11.

Рисунок 11: Дерево Меркла Теперь, если большинство полных узлов вступают в сговор, они могут создать блок, действительный или недействителен и отправляет его hash на легкие узлы, но никогда не раскрывает полное содержимое блока. Есть разные способы, которыми они могут извлечь из этого выгоду. Например, рассмотрим рисунок 12: Рисунок 12: Проблема с доступностью данных Есть три блока: предыдущий, A, создан честными validators; текущий B имеет в сговоре validators; и следующий, C, также будет произведен честными validators (blockchain изображен в правом нижнем углу). Вы торговец. validator текущего блока (B) получил блок A из предыдущих validators вычислил блок, в котором вы получаете деньги,и отправил вам заголовок этого блока с доказательством Меркла о состоянии, в котором у вас есть деньги (или подтверждение Merkle о действительной транзакции, которая отправляет деньги тебе). Уверенные, что транзакция завершена, вы предоставляете услугу. Однако validator никогда не передают полное содержимое блока B кто угодно. Таким образом, честные validator блока C не могут получить блок и вынуждены либо останавливать систему, либо строить на вершине А, лишая вас как торговец деньгами. Когда мы применяем тот же сценарий к сегментированию, определения полного и Легкий узел обычно применяется к каждому сегменту: validators в каждом сегменте загружается каждые блокировать в этом сегменте и проверять каждую транзакцию в этом сегменте, но другие узлы в системе, включая те, которые сохраняют состояние цепочек осколков моментальных снимков в цепочка маяков, загружайте только заголовки. Таким образом, validator в осколке фактически полные узлы для этого шарда, в то время как другие участники системы включая маяковую цепь, работают как легкие узлы. Чтобы подход рыбака, который мы обсуждали выше, работал, честные validators необходимо иметь возможность загружать блоки, связанные с цепочкой маяков. Если злонамеренные validators связали заголовок недопустимого блока (или использовали его для инициировать транзакцию между шардами), но никогда не распределял блок, честный validator не имеют возможности придумать испытание. Мы рассмотрим три подхода к решению этой проблемы, которые дополняют друг друга. 2.5.1 Доказательства содержания под стражей Самая неотложная проблема, которую необходимо решить, — доступен ли блок один раз. оно опубликовано. Одна из предложенных идей заключается в том, чтобы иметь так называемых нотариусов, которые чередуются. между шардами чаще, чем validators, единственная задача которых — загрузить заблокировать и подтвердить, что они смогли его скачать. Они могут быть ротируются чаще, потому что им не нужно загружать все состояние осколка, в отличие от validator, которых нельзя часто менять, поскольку они должен загружать состояние шардов каждый раз, когда они вращаются, как показано на рисунке 13. Проблема с этим наивным подходом в том, что позже невозможно доказать смог или не смог нотариус загрузить блок, поэтому нотариус могут всегда подтверждать, что они смогли загрузить блок без даже пытаясь его вернуть. Одним из решений этой проблемы является предоставление нотариусам некоторые доказательства или поставить некоторое количество tokens, подтверждающих, что блок был скачал. Одно из таких решений обсуждается здесь: https://ethresear.ch/t/. 1-битные депозитарные облигации, благоприятные для агрегации/2236. 2.5.2 Коды стирания Когда конкретный легкий узел получает hash блока, чтобы увеличить будучи уверенным в том, что блок доступен, он может попытаться загрузить несколько случайных кусочки блока. Это не полное решение, так как разве что легкие узлы коллективно загрузить весь блок, который могут выбрать производители вредоносных блоков

Рисунок 13: Валидаторам необходимо загрузить состояние, и поэтому их нельзя менять. часто удерживать части блока, которые не были загружены каким-либо легким узлом, тем самым делая блок недоступным. Одним из решений является использование конструкции под названием «Коды стирания», позволяющей восстановить весь блок, даже если доступна только некоторая часть блока, как показано на рисунке 14. Рисунок 14: Merkle tree построен на основе данных стирающего кодирования И Polkadot, и Ethereum Serenity используют эту идею, предоставить легким узлам возможность быть достаточно уверенными в доступности блоков. Подход Ethereum Serenity подробно описан в [2].2.5.3 Подход Polkadot к доступности данных В Polkadot, как и в большинстве сегментированных решений, каждый сегмент (называемый парачейном) передает свои блоки в цепочку маяков (называемую цепочкой реле). Скажем, есть 2f + 1. validators в цепи реле. Производители блоков парачейна, называемые средства сортировки, как только блок парачейна создан, вычисляют версию блока со стирающим кодом, состоящую из 2f +1 частей, так что любых f частей достаточно. реконструировать блок. Затем они раздают по одной части каждому validator на релейная цепь. Определенная цепочка ретрансляции validator будет только подписываться на цепочку ретрансляции. блокировать, если у них есть своя часть для каждого блока парачейна, снимок которого сделан в такой блок релейной цепи. Таким образом, если блок релейной цепи имеет сигнатуры от 2f + 1 validators, и до тех пор, пока не более f из них нарушили протокол, каждый Блок парачейна можно реконструировать, извлекая части из validators которые следуют протоколу. См. рисунок 15. Рисунок 15: Доступность данных Polkadot 2.5.4 Долгосрочная доступность данных Заметим, что все рассмотренные выше подходы свидетельствуют лишь о том, что блок вообще был опубликован и доступен сейчас. Блоки могут позже стать недоступными. по разным причинам: узлы отключаются от сети, узлы намеренно стирают историю данные и другие. Стоит упомянуть технический документ, посвященный этой проблеме, — Polyshard [3], который использует коды стирания, чтобы сделать блоки доступными для всех осколков, даже если их несколько. осколки полностью теряют свои данные. К сожалению, их специфический подход требует все шарды для скачивания блоков со всех остальных шардов, что непомерно дорого. Долгосрочная доступность не является столь острой проблемой: поскольку ни один участник Ожидается, что система будет способна проверять все цепочки во всех

сегментов, безопасность сегментированного протокола должна быть спроектирована таким образом, способ обеспечить безопасность системы, даже если некоторые старые блоки в некоторых шардах станут совершенно недоступен.

Nightshade

3.1 Parça zincirlerinden parça parçalara Parça zincirleri ve işaret zinciri içeren parçalama modeli çok güçlüdür ancak belirli karmaşıklıklara sahiptir. Özellikle çatal seçim kuralının uygulanması gerekiyor her zincirde ayrı ayrı, parça zincirlerinde ve işaretçide çatal seçim kuralı Zincir farklı şekilde oluşturulmalı ve ayrı olarak test edilmelidir. Nightshade'de sistemi tek bir blockchain olarak modelliyoruz; her biri blok mantıksal olarak tüm parçalar için tüm işlemleri içerir ve tüm parçaların tüm durumu. Ancak fiziksel olarak hiçbir katılımcı dosyayı indirmez. tam durum veya tam mantıksal blok. Bunun yerine, ağın her katılımcısı yalnızca İşlemleri doğruladıkları parçalara karşılık gelen durumu korur ve bloktaki tüm işlemlerin listesi fiziksel olarak bölünmüştür parçalar, parça başına bir parça. İdeal koşullar altında her blok, parça başına tam olarak bir parça içerir. kabaca parça zincirli modele karşılık gelen blok parça zincirleri işaret zinciriyle aynı hızda bloklar üretir. Ancak, ağ gecikmeleri nedeniyle bazı parçalar eksik olabilir; bu nedenle pratikte her blok parça başına bir veya sıfır parça içerir. Nasıl yapılacağına ilişkin ayrıntılar için bölüm 3.3'e bakın. bloklar üretilir. Şekil 16: Solda parça zincirleri ve tek zinciri olan bir model bloklar sağ tarafta parçalara bölünmüş

3.2 Konsensüs Bugün blockchain'lerde fikir birliğine yönelik iki baskın yaklaşım şunlardır: En fazla işe veya hisseye sahip olan zincirin en uzun (veya en ağır) zincir oluşturmak için kullanılan kurallı kabul edilir ve BFT, burada her blok için bazı validator kümesi BFT fikir birliğine ulaştı. Son zamanlarda önerilen protokollerde ikincisi daha baskın bir yaklaşımdır, anında kesinlik sağladığından, en uzun zincirde daha fazla bloğa ihtiyaç duyulurken Kesinliği sağlamak için bloğun üzerine inşa edilecek. Çoğu zaman anlamlı Yeterli sayıda bloğun inşa edilmesi için gereken süre güvenlik gerektirir. saat sırası. Her blokta BFT fikir birliğini kullanmanın aşağıdaki gibi dezavantajları da vardır: 1. BFT fikir birliği önemli miktarda iletişim gerektirir. iken Son gelişmeler sayıca doğrusal zamanda fikir birliğine varılmasına olanak tanıyor katılımcıların sayısı (bkz. örneğin [4]), blok başına hala fark edilebilir bir yüktür; 2. Tüm ağ katılımcılarının BFT'ya katılması mümkün değildir. Blok başına fikir birliğine varılır, dolayısıyla genellikle yalnızca rastgele örneklenmiş bir katılımcı alt kümesi fikir birliğine varır. Rastgele örneklenmiş bir küme prensip olarak şu şekilde olabilir: uyarlanabilir bir şekilde bozulur ve teoride bir çatal oluşturulabilir. sistem her ikisinin de böyle bir olaya hazır olmak için modellenmesi gerekiyor ve bu nedenle hala BFT fikir birliğinin yanı sıra bir çatal seçeneği kuralına sahip olmak veya kapanacak şekilde tasarlanmış olmak böyle bir olayda aşağı. Bazı tasarımların olduğunu belirtmekte fayda var. Algorand [5], uyarlamalı yolsuzluk olasılığını önemli ölçüde azaltır. 3. En önemlisi şu durumlarda sistem durur: Tüm katılımcıların 3 veya daha fazlası çevrimdışı. Bu nedenle, herhangi bir geçici ağ arızası veya ağ bölünmesi, sistemi tamamen durdurabilir. İdeal olarak sistem devam edebilmelidir katılımcıların en az yarısı çevrimiçi olduğu sürece faaliyet göstermektedir (en yoğun Zincir tabanlı protokoller, katılımcıların yarısından azı çevrimiçi olsa bile çalışmaya devam eder, ancak bu özelliğin arzu edilirliği daha tartışmalıdır topluluk içinde). Kullanılan fikir birliğinin bir tür en ağır olduğu hibrit bir model zincir, ancak bazı bloklar BFT sonlandırma aracı kullanılarak periyodik olarak sonlandırılır ve her iki modelin de avantajları korunur. Bu tür BFT nihai gadget'lar Ethereum 2.0 8'de kullanılan Casper FFG [6], Casper CBC (bkz. https://vitalik.) ca/general/2018/12/05/cbc_casper.html) ve GRANDPA (bkz. https:// Medium.com/polkadot-network/d08a24a021b5) Polkadot'de kullanıldı. Nightshade en ağır zincir konsensüsünü kullanır. Özellikle bir blok Üretici bir blok ürettiğinde (bkz. Bölüm 3.3), imza toplayabilirler. diğer blok üreticileri ve önceki bloğu doğrulayan validator'lar. Bölüme bakın Bu kadar çok sayıda imzanın nasıl toplandığıyla ilgili ayrıntılar için 3.8'e bakınız. Ağırlık 8Ayrıca Casper'a derinlemesine bir genel bakış için Justin Drake ile yapılan beyaz tahta oturumuna bakın FFG ve GHOST en ağır zincir konsensüsüne nasıl entegre edildiği burada: https://www. youtube.com/watch?v=S262StTwkmobir bloğun payı, imzaları imzalanan tüm imzalayanların kümülatif hissesidir. bloğa dahil edilmiştir. Bir zincirin ağırlığı blok ağırlıklarının toplamıdır. En ağır zincir mutabakatının yanı sıra, aşağıdakileri kullanan bir nihai gadget kullanıyoruz: blokları sonlandırmak için onaylar. Sistemin karmaşıklığını azaltmak için, Çatal seçim kuralını hiçbir şekilde etkilemeyen bir sonlandırma aracı kullanıyoruz, ve bunun yerine yalnızca ekstra eğik çizgi koşulları getirir, öyle ki bir blok bir kez Nihai gadget tarafından sonlandırıldığında, çok büyük bir yüzde olmadıkça çatallanma imkansızdır. toplam bahis miktarı kesildi. Casper CBC son derece kaliteli bir cihazdır ve biz şu anda Casper CBC'yi göz önünde bulundurarak model oluşturuyorum. Ayrıca TxFlow adı verilen ayrı bir BFT protokolü üzerinde de çalışıyoruz. O sırada Bu belgeyi yazarken Casper yerine TxFlow'un kullanılıp kullanılmayacağı belli değil CBC. Ancak son cihaz seçiminin büyük ölçüde tasarımın geri kalanına dik olduğunu belirtmeliyiz. 3.3 Blok üretimi Nightshade'de iki rol vardır: blok yapımcıları ve validator'ler. herhangi bir zamanda sistemin w blok üreticilerini içerdiği nokta, modellerimizde w = 100 ve wv validators, modelimizde v = 100, wv = 10, 000. Sistem Proof-of-Stake'tir, bu, hem blok üreticilerinin hem de validator'lerin bir takım dahili bağlantılara sahip olduğu anlamına gelir para birimi ("tokens" olarak anılır) belirtilen süreyi aşan bir süre boyunca kilitlendi zinciri oluşturma ve doğrulama görevlerini yerine getirmek için harcadıkları zaman. Tüm Proof of Stake sistemlerinde olduğu gibi, tüm w blok üreticileri ve tüm wv validator'ler farklı varlıklardır, çünkü bu uygulanamaz. Her biri Bununla birlikte, w blok üreticilerinin ve wv validator'lerin ayrı bir hisse. Sistem n parça içeriyor, modelimizde n = 1000. Bahsedildiği gibi bölüm 3.1, Nightshade'de hiçbir parça zinciri yoktur, bunun yerine tüm blok üreticileri ve validator'ler tek bir blockchain inşa ediyor, biz bunu ana zincir. Ana zincirin durumu n parçaya bölünmüştür ve her blok yapımcı ve validator her an yerel olarak yalnızca bir alt kümesini indirdi bazı parçaların alt kümesine karşılık gelen ve yalnızca işlem ve Eyaletin bu kısımlarını etkileyen işlemleri doğrulamak. Bir blok üreticisi olmak için ağın bir katılımcısı bazı büyükleri kilitler tokens miktarı (bir hisse). Ağın bakımı dönemler halinde yapılır, burada bir dönem gün sırasına göre bir zaman dilimidir. Katılımcılar Belirli bir çağın başında en büyük riske sahip olan bloklar O dönemin yapımcıları. Her blok üreticisi yazılım parçalarına atanır (örneğin sw = 40, bu da sww/n = parça başına 4 blok üreticisi anlamına gelir). Blok yapımcı, atandığı parçanın çağdan önceki durumunu indirir başlar ve dönem boyunca söz konusu parçayı etkileyen işlemleri toplar, ve bunları devlete uygular. Ana zincirdeki her b bloğu ve her parça s için aşağıdakilerden biri vardır: blok üreticilerini b ile ilgili kısmı üretmekten sorumlu olanlara atadık parçaya. b'nin parçayla ilgili kısmına yığın denir ve şunları içerir: merkle'nin yanı sıra b'ye dahil edilecek parçaya ilişkin işlemlerin listesiortaya çıkan durumun kökü. b sonuçta yalnızca çok küçük bir başlık içerecektir parça, yani uygulanan tüm işlemlerin merkle kökü (bkz. bölüm Kesin ayrıntılar için 3.7.1) ve son durumun merkle kökü. Belgenin geri kalanında sıklıkla blok üreticisinden bahsediyoruz belirli bir parça için belirli bir zamanda bir parça üretmekten sorumlu olan bir parça üreticisi olarak. Parça üreticisi her zaman blok üreticilerinden biridir. Blok üreticileri ve parça üreticileri her bloğu ona göre döndürür. sabit bir programa göre. Blok üreticilerinin siparişi var ve tekrar tekrar üretim yapıyorlar. bu sırayla bloklar. Örn. 100 blok üreticisi varsa ilk blok üreticiler 1, 101, 201 vb. blokların üretiminden sorumludur, ikincisi ise 2, 102, 202 vb. üretmekten sorumludur. Parça üretimi, blok üretiminden farklı olarak bakım gerektirdiğinden durum ve her parça için yalnızca sww/n blok üreticileri durumu korur parça başına, buna uygun olarak yalnızca sww/n blok üreticileri, oluşturmak için dönüşümlü olarak çalışır. parçalar. Örn. dört blok üreticisinin atandığı yukarıdaki sabitlerle Her parça, her blok üreticisi her dört blokta bir parça oluşturacak. 3.4 Veri kullanılabilirliğinin sağlanması Veri kullanılabilirliğini sağlamak için Polkadot yaklaşımına benzer bir yaklaşım kullanıyoruz bölüm 2.5.3'te açıklanmıştır. Bir blok üreticisi bir parça ürettiğinde, optimal (w, ⌊w/6 + 1⌋) blok koduna sahip silme kodlu versiyonu yığın. Daha sonra silme kodlu parçanın bir parçasını gönderirler (bu tür parçalar diyoruz) her blok üreticisine parça parçaları veya sadece parçalar). Yapraklar gibi tüm parçaları içeren bir merkle ağacı hesaplıyoruz ve Her parçanın başlığı bu ağacın merkle kökünü içerir. Parçalar tek parça mesajları aracılığıyla validators'ye gönderilir. Bu tür mesajların her biri öbek başlığını, parçanın sırasını ve parça içeriğini içerir. mesaj aynı zamanda blok üreticisinin imzasını da içermektedir. parçanın başlığa karşılık geldiğini kanıtlamak için parça ve merkle yolu ve uygun blok üreticisi tarafından üretilmektedir. Bir blok üreticisi bir ana zincir bloğunu aldığında ilk olarak bu bloğun olup olmadığını kontrol eder. blokta yer alan her parça için tek parçalı mesajlar bulunur. Aksi takdirde blok eksik tek parçalı mesajlar alınana kadar işlenmez. Tüm tek parçalı mesajlar alındıktan sonra blok üreticisi, akranlarından kalan parçaları alır ve tuttukları parçaları yeniden yapılandırır devlet. Blok üreticisi en az bir ana zincir bloğunu işlemez. bloğa dahil edilen parçalarda karşılık gelen tek parçalı mesaj yoktur veya durumu korudukları en az bir parça için bunu yapamazlar tüm parçayı yeniden yapılandırın. Belirli bir parçanın mevcut olması için bloğun ⌊w/6⌋+1 olması yeterlidir Üreticiler kendi paylarına sahipler ve onlara hizmet ediyorlar. Böylece sayı kadar Kötü niyetli aktörler, yarım bloktan fazla bloğu olan hiçbir zincirin ⌊w/3⌋ değerini aşmaz bunu inşa eden üreticiler kullanılamayan parçalara sahip olabilir.Şekil 17: Her blok, parça başına bir veya sıfır parça içerir ve her parça silme kodludur. Silme kodlu yığının her bir parçası belirlenmiş bir yere gönderilir. özel bir tek bölümlü mesaj aracılığıyla yapımcıyı bloke etme 3.4.1 Tembel blok üreticileriyle uğraşmak Bir blok üreticisinin tek parçalı mesajın eksik olduğu bir bloğu varsa, yine de imzalamayı seçebilir, çünkü eğer blok zincire bağlanırsa blok üreticisinin ödülünü maksimuma çıkaracak. Blok için risk yok Daha sonra blok üreticisinin sahip olmadığını kanıtlamak imkansız olduğundan üretici tek parça mesajı. Bunu ele almak için, her bir parça üreticisini, parçayı oluştururken yapıyoruz. gelecekteki kodlanmış parçanın her bir parçası için bir renk (kırmızı veya mavi) seçin ve saklayın kodlanmadan önce yığındaki atanan rengin bit maskesi. Her bir parça mesaj parçaya atanan rengi içerir ve renk şu durumlarda kullanılır: kodlanmış parçaların merkle kökünün hesaplanması. Parça üreticisi saparsa protokole göre kolayca kanıtlanabilir, çünkü merkle kökü tek parça mesajlarına veya tek parça mesajlarındaki renklere karşılık gelir merkle köküne karşılık gelen, yığındaki maskeyle eşleşmeyecektir. Bir blok üreticisi bir bloğa imza attığında, tüm blokların bit maskesini ekler. bloğa dahil edilen parçalar için aldıkları kırmızı parçalar. Bir yayınlama yanlış bit maskesi kesilebilir bir davranıştır. Bir blok üreticisi bir sertifika almamışsa tek parçalı mesaj, mesajın rengini bilmelerinin hiçbir yolu yoktur ve dolayısıyla körü körüne imza atmaya kalkışmaları halinde %50 oranında kesintiye uğrama şansları vardır. Blok. 3.5 Durum geçiş başvurusu Parça üreticileri yalnızca parçaya hangi işlemlerin dahil edileceğini seçerler ancak bir yığın ürettiklerinde durum geçişini uygulamayın. Buna bağlı olarak,

yığın başlığı, daha önce olduğu gibi merkelize durumun merkle kökünü içerir yığındaki işlemler uygulanır. İşlemler yalnızca parçayı içeren tam bir blok olduğunda uygulanır işlenir. Bir katılımcı yalnızca şu durumlarda bir bloğu işler: 1. Önceki blok alındı ve işlendi; 2. Her parça için katılımcı sahip olduğu durumu korumaz tek parça mesajını gördüm; 3. Her parça için katılımcı, sahip oldukları durumu korur. tam yığın. Blok işlendikten sonra, katılımcının her bir parça için durumu korur, işlemleri uygular ve yeni durumu hesaplarlar işlemler uygulandıktan sonra üretime hazır hale gelirler herhangi bir parçaya atanmışlarsa bir sonraki bloğun parçaları yeni merkelleşmiş durumun merkle kökü. 3.6 Parçalar arası işlemler ve makbuzlar Bir işlemin birden fazla parçayı etkilemesi gerekiyorsa bunun ardışık olarak yapılması gerekir her parçada ayrı ayrı yürütülür. İşlemin tamamı ilk parçaya gönderilir etkilendiğinde ve işlem söz konusu parçanın öbeğine dahil edildiğinde ve öbek bir bloğa dahil edildikten sonra uygulanır, sözde bir makbuz üretir işlemin yapılması gereken bir sonraki parçaya yönlendirilen işlem idam edilecek. Daha fazla adımın gerekli olması halinde, alındı işleminin yürütülmesi yeni bir giriş hareketi oluşturur ve bu şekilde devam eder. 3.6.1 Makbuz işleminin ömrü Alış işleminin oluşturulduğu bloğun hemen ardından gelen blokta uygulanması arzu edilir. Makbuz işlemi yalnızca Önceki bloğun blok üreticileri tarafından alınıp uygulanmasından sonra oluşturulan kaynak parçayı koruyan ve o zamana kadar bilinmesi gereken Bir sonraki blok için parça, hedefin blok üreticileri tarafından üretilir kırık. Bu nedenle, makbuzun kaynak parçadan alıcıya iletilmesi gerekir. Bu iki olay arasındaki kısa zaman dilimindeki hedef parça. A, r girişini üreten bir t işlemini içeren son üretilen blok olsun. B bir sonraki üretilen blok olsun (yani A'yı içeren bir blok) r'yi içermek istediğimiz önceki bloğu). a ve r parçasında olsun kırıkta b. Şekil 18'de de gösterilen faturanın kullanım ömrü aşağıdaki gibidir: Makbuzların üretilmesi ve saklanması. Parça için parça üreticisi EBM'si a, A bloğunu alır, t işlemini uygular ve r makbuzunu oluşturur. EBM daha sonra üretilen tüm makbuzları dahili kalıcı depolama biriminde indekslenmiş olarak saklar kaynak parça kimliğine göre.Makbuzların dağıtılması. EBM, parçayı üretmeye hazır olduğunda B bloğu için a parçasını, a bloğu için A bloğundaki işlemlerin uygulanmasıyla oluşturulan tüm makbuzları getirir ve bunları parça için parçaya dahil ederler. B bloğunda a. Böyle bir yığın oluşturulduktan sonra, cpa onun silme kodunu üretir sürümü ve karşılık gelen tüm onepart mesajları. EBM, hangi blok üreticilerinin hangi parçalar için tam durumu koruduğunu bilir. Belirli bir blok üreticisi için bp cpa, A bloğundaki işlemlerin uygulanmasından kaynaklanan makbuzları içerir bp'nin hedef olarak önemsediği parçalardan herhangi birine sahip olan parça a için B bloğundaki a parçası için yığını dağıttıklarında tek parçalı mesajda (tek parçalı mesaja dahil edilen makbuzları gösteren şekil 17'ye bakın). Makbuzların alınması. Katılımcıların (hem blok üreticileri hem de validator'ler) tek parçalı mesajları alana kadar blokları işlemediklerini unutmayın. blokta yer alan her parça için. Böylece, herhangi bir katılımcı B bloğunu uyguladığında, B bloğuna karşılık gelen tüm tek parçalı mesajlara sahip olur. B'deki parçalar ve dolayısıyla parçaların bulunduğu tüm gelen makbuzlara sahipler katılımcı, varış yeri olarak durumunu korur. Uygularken belirli bir parça için durum geçişi, katılımcı hem makbuzları uygular tek parçalı mesajlarda parça için topladıklarının yanı sıra tüm yığının kendisinde yer alan işlemler. Şekil 18: Bir makbuz işleminin ömrü 3.6.2 Çok fazla makbuz işlemek Belirli bir parçayı hedefleyen faturaların sayısının belirli blok işlenemeyecek kadar büyük. Örneğin, şekil 19'u düşünün, her bir parçadaki her işlem, parça 1'i hedefleyen bir makbuz oluşturur. Bir sonraki blokta, parça 1'in işlemesi gereken faturaların sayısı şu şekilde olur: taşıma sırasında tüm parçaların bir araya getirdiği yükle karşılaştırılabilir önceki blok.

Şekil 19: Tüm faturalar aynı parçayı hedefliyorsa parçanın bunları işleme kapasitesi Bu sorunu çözmek için QuarkChain 9'da kullanılana benzer bir teknik kullanıyoruz. Spesifik olarak, her bir parça için son B bloğu ve onun içindeki son parça Fişlerin uygulandığı blok kaydedilir. Yeni parça ne zaman Oluşturulduğunda, fiş ilk önce B'de kalan parçalardan başlayarak uygulanır, ve sonra yeni yığın dolana kadar B'yi takip eden bloklar halinde. Normalin altında Dengeli bir yüke sahip koşullar altında, genellikle tüm tahsilatlar sonuçlanacaktır. uygulanıyor (ve böylece son bloğun son parçası kaydedilecek) her parça), ancak yükün dengeli olmadığı zamanlarda ve belirli bir Shard orantısız bir şekilde çok sayıda makbuz alıyor, bu teknik onların dahil edilen işlem sayısındaki sınırlara uyularak işlenecektir. Böyle dengesiz bir yükün uzun süre kalması durumunda gecikmenin Başvuruya kadar fiş oluşturma süresiz olarak büyümeye devam edebilir. Bir Bunu çözmenin yolu, bir hedefi hedefleyen bir makbuz oluşturan herhangi bir işlemi iptal etmektir. Belirli bir sabiti (ör. bir dönem) aşan bir işlem gecikmesine sahip olan parça. Şekil 20'yi düşünün. B bloğuna göre 4 numaralı parça tüm girişleri işleyemez, bu nedenle yalnızca A bloğundaki 3. parçaya kadar olan makbuzları işler ve onu kaydeder. C bloğunda B bloğundaki 5. parçaya kadar olan makbuzlar dahil edilir ve daha sonra D blokta parça yakalanır ve kalan tüm faturalar işlenir. B bloğu ve C bloğundaki tüm faturalar. 3.7 Parça doğrulama Belirli bir parça için üretilen bir parça (veya parça zincirli modelde belirli bir parça zinciri için üretilen bir parça bloğu) yalnızca şu şekilde doğrulanabilir: 9QuarkChain ile beyaz tahta bölümünü buradan izleyin: https://www.youtube.com/watch? v=opEtG6NM4x4, diğerlerinin yanı sıra parçalar arası işlemlere yaklaşımın tartışıldığı şeylerŞekil 20: Gecikmeli makbuz işleme Devleti koruyan katılımcılar. Blok üreticileri olabilirler, validators, veya yalnızca durumu indiren ve parçayı doğrulayan harici tanıklar varlıkları depoluyorlar. Bu belgede katılımcıların çoğunluğunun depolama yapamadığını varsayıyoruz. parçaların büyük bir kısmı için devlet. Ancak şunu belirtmekte yarar var varsayımıyla tasarlanmış parçalanmış blockchain'lerin bulunduğunu çoğu katılımcının durumunu saklama ve çoğu şeyi doğrulama kapasitesi vardır. QuarkChain gibi parçalar. Katılımcıların yalnızca bir kısmı parçayı doğrulama durumuna sahip olduğundan Parçalar halinde, yalnızca aşağıdaki özelliklere sahip olan katılımcıları uyarlanabilir şekilde yozlaştırmak mümkündür. durumu seçin ve geçersiz bir durum geçişi uygulayın. Her birkaç örnekte validators içeren birden fazla parçalama tasarımı önerildi gün ve bir gün içinde parça zincirinde 2/3'ten fazla olan herhangi bir blok söz konusu parçaya atanan validator'lerin imzalarının sayısı hemen dikkate alınır son. Böyle bir yaklaşımla, uyum sağlayabilen bir düşmanın yalnızca 2n/3+1'i yozlaştırması yeterlidir Geçersiz bir durum geçişi uygulamak için bir parça zincirindeki validator'lerin sayısı; Bunu başarmak muhtemelen zor olsa da, kamuya açık bir güvenlik düzeyi yeterli değil blockchain. Bölüm 2.3'te tartışıldığı gibi, ortak yaklaşım, durumu olan herhangi bir katılımcı için bir blok oluşturulduktan sonra belirli bir zaman aralığına izin vermektir (ister geçerliliğine meydan okuyan bir blok üreticisi, bir validator veya harici bir gözlemci). Bu tür katılımcılara Balıkçı denir. Bir balıkçının bunu yapabilmesi için Geçersiz bir bloğa itiraz edilmesi durumunda, böyle bir bloğun erişime açık olduğundan emin olunmalıdır. onlar. Nightshade'deki veri kullanılabilirliği bölüm 3.4'te tartışılmaktadır. Nightshade'de bir blok üretildiğinde parçalar gerçek parça üreticisi dışında herkes. Özellikle blok üreticisi bloğun doğal olarak çoğu parça için duruma sahip olmadığını öne sürdü veparçaları doğrulayamadı. Bir sonraki blok üretildiğinde, birden fazla blok üreticisinin ve validator'lerin onaylarını (bkz. bölüm 3.2) içerir, ancak blok üreticilerinin ve validator'lerin çoğunluğu durumu korumadığından çoğu kırık için de yalnızca bir geçersiz parçaya sahip bir blok, doğrulamaların yarısından önemli ölçüde fazlasını toplayacak ve en ağır blokta yer almaya devam edecek zincir. Bu sorunu çözmek için, durumunu koruyan herhangi bir katılımcıya izin veriyoruz. bu şekilde üretilen herhangi bir geçersiz parça için zincir üzerinde bir meydan okuma gönderecek bir parça kırık. 3.7.1 Devlet geçerliliği sorunu Bir katılımcı belirli bir parçanın geçersiz olduğunu tespit ettiğinde parçanın geçersiz olduğuna dair bir kanıt sunması gerekir. Ağ katılımcılarının çoğunluğu geçersiz parçanın bulunduğu parçanın durumunu korumadığından üretildiğinde, kanıtın bloğun doğrulandığını doğrulamak için yeterli bilgiye sahip olması gerekir. devlet olmadan geçersiz. Tek bir işlemin gerçekleştirebileceği durum miktarının (bayt cinsinden) Ls sınırını belirliyoruz. toplu olarak okuyabilir veya yazabilir. L'den daha fazlasına dokunan herhangi bir işlem durum geçersiz kabul edilir. Bölüm 3.5'ten hatırlayın ki yığın belirli bir B bloğunda yalnızca uygulanacak işlemleri içerir, ancak yeni durum kökü. B bloğundaki yığının içerdiği durum kökü durumdur root, bu tür işlemleri uygulamadan önce, ancak işlemleri uyguladıktan sonra B bloğundan önceki aynı parçadaki son parça. Kötü niyetli bir aktör geçersiz bir durum geçişi uygulamak istemeniz, yanlış bir durum kökü içerecektir uygulamadan kaynaklanan durum köküne karşılık gelmeyen B bloğunda önceki parçadaki işlemler. Bir parça üreticisinin parçaya dahil ettiği bilgiyi genişletiyoruz. Tüm işlemleri uyguladıktan sonra sadece durumu dahil etmek yerine, her bir bitişik işlem kümesi uygulandıktan sonra bir durum kökü içerir. toplu olarak Ls durum baytını okur ve yazar. Bu bilgilerle birlikte balıkçının devlet geçişinin yanlış uygulandığına dair bir zorluk yaratması Bu türden ilk geçersiz durum kökünü bulmak yeterlidir ve yalnızca Ls baytını içerir. son durum kökü arasındaki işlemlerden etkilenen durum (ki bu geçerli) ve merkle kanıtlarıyla birlikte mevcut durum kökü. Daha sonra herhangi bir katılımcı segmentteki işlemleri doğrulayabilir ve parçanın olduğunu doğrulayabilir geçersiz. Benzer şekilde, yığın üreticisi şunu okuyan işlemleri dahil etmeye çalışırsa: ve Ls bayttan daha fazla durum yazın, zorluk için dahil etmek yeterlidir Merkle kanıtlarıyla dokunduğu ilk Ls baytı, bu da yeterli olacaktır. işlemleri uygulayın ve bir girişimde bulunulacağı bir anın olduğunu onaylayın Ls bayt ötesinde içerik okuma veya yazma işlemi yapılır.

3.7.2 Balıkçılar ve hızlı çapraz parça işlemleri Bölüm 2.3'te tartışıldığı gibi, parça parçalarının (veya parçanın) modeldeki parça zincirli bloklar) geçersiz olabilir ve zorluk yaratabilir Bu durum nihailiği ve dolayısıyla parçalar arası iletişimi olumsuz etkiler. içinde özellikle herhangi bir çapraz parça işleminin hedef parçası kesin olamaz kaynak parça parçası veya blok, meydan okuma süresi bitene kadar nihaidir (bkz. şekil 21). Şekil 21: Makbuz uygulamadan önce sorgulama süresinin beklenmesi Bunu, parçalar arası işlemleri gerçekleştirecek şekilde ele almanın yolu hedef parçanın meydan okuma süresini beklememesi anlıktır kaynak parça işlemi yayınlandıktan sonra ve alındı işlemini uygulayın hemen, ancak daha sonra hedef parçayı kaynakla birlikte geri alın daha sonra kaynak parçanın veya bloğun geçersiz olduğu tespit edilirse parça (bkz. şekil 22). Bu, parçanın bulunduğu Nightshade tasarımı için çok doğal olarak geçerlidir. zincirler bağımsız değildir ancak bunun yerine parça parçalarının tümü yayınlanır birlikte aynı ana zincir bloğunda. Herhangi bir parçanın geçersiz olduğu tespit edilirse, bu parçaya sahip bloğun tamamı geçersiz kabul edilir ve üzerine inşa edilen tüm bloklar üstüne. Bkz. şekil 23. Yukarıdaki yaklaşımların her ikisi de, sorunun şu şekilde olduğu varsayılarak atomiklik sağlar: süre yeterince uzundur. Normal koşullar altında hızlı çapraz parça işlemlerinin sağlanması, hedef parça, aşağıdakilerden birinde geçersiz bir durum geçişi nedeniyle geri alınıyor son derece nadir bir olay olan kaynak parçaları. 3.7.3 validators gizleniyor Zorlukların varlığı, halihazırda bu olasılığı önemli ölçüde azaltıyor. uyarlanabilir yolsuzluk, çünkü bir yığını geçersiz bir durum geçiş gönderisiyle sonuçlandırmak içinŞekil 22: Makbuzların anında uygulanması ve varış noktasına geri alınması kaynak zincirinde geçersiz bir blok varsa zincir Şekil 23: Nightshade'de balıkçı mücadelesi Adaptif düşmanın tüm katılımcıları yozlaştırması gereken meydan okuma dönemi tüm validator'ler dahil olmak üzere parçanın durumunu koruyan. Böyle bir olayın olasılığını tahmin etmek son derece karmaşıktır, çünkü hiçbir Sharded blockchain bu tür bir saldırının denenmesine yetecek kadar uzun süredir yayında. Olasılığın son derece düşük olmasına rağmen hala yeterince yüksek olduğunu savunuyoruz. Milyonlarca işlemi yürütmesi beklenen bir sistem için büyük ve dünya çapında finansal operasyonlar yürütmek. Bu inancın iki temel nedeni vardır: 1. Proof-of-Stake zincirlerinin ve madencilerin validator'lerinin çoğu

İş Kanıtı zincirleri öncelikle finansal yükselişle teşvik ediliyor. Eğer Adaptif bir düşman onlara beklenen getiriden daha fazla para teklif eder dürüst bir şekilde faaliyet göstermekten dolayı, birçok validators'nin olmasını beklemek makul olacaktır. teklifi kabul edecek. 2. Birçok kuruluş Proof-of-Stake zincirlerinin doğrulamasını profesyonelce yapar ve Herhangi bir zincirdeki hisselerin büyük bir yüzdesinin bu tür kuruluşlardan. Bu tür varlıkların sayısı bir dönem için yeterince azdır. çoğunu kişisel olarak tanımak ve bozulmaya olan eğilimlerini iyi anlıyorlar. Hangi validator'lerin hangi parçaya atandığını gizleyerek uyarlamalı bozulma olasılığını azaltma konusunda bir adım daha ileri gidiyoruz. Fikir şu Algorand [5]'nin validators'yi gizlemesine uzaktan benzer. validator'ler, Algorand'da olduğu gibi gizlenmiş olsa bile, şunu unutmamak önemlidir: veya aşağıda açıklandığı gibi, uyarlanabilir bozulma teoride hala mümkündür. iken uyarlanabilir rakip, oluşturacak veya doğrulayacak katılımcıları tanımıyor Bir blok ya da yığın halinde, katılımcılar performans sergileyeceklerini kendileri biliyorlar. böyle bir görev ve bunun kriptografik bir kanıtı var. Böylece düşman yolsuzluk yapma niyetlerini yayınlayacak ve bunu sağlayacak herhangi bir katılımcıya ödeme yapacaktır. böyle bir kriptografik kanıt. Ancak şunu da belirtmeliyiz ki, rakip bunu yapmadığından bozmak istedikleri parçaya atanan validator'leri biliyorlarsa, belirli bir parçayı bozma niyetlerini yayınlamaktan başka seçeneği yok tüm topluluk. Bu noktada herhangi bir dürüst için ekonomik olarak faydalıdır. katılımcının bu parçayı doğrulayan tam bir düğümü döndürmesi için yüksek bir söz konusu parçada geçersiz bir bloğun görünme olasılığı; bir meydan okuma yaratın ve ilgili ödülü toplayın. Belirli bir parçaya atanan validator'leri açığa çıkarmamak için şunu yaparız: aşağıdakiler (bkz. şekil 24): Ödevi almak için VRF'yi kullanma. Her çağın başında her validator, validator'nin atandığı parçaların bit maskesini almak için bir VRF kullanır. Her validator'nin bit maskesi Sw bitlerine sahip olacaktır (tanım için bölüm 3.3'e bakın) Sw). validator daha sonra karşılık gelen parçaların durumunu getirir ve Alınan her blok için dönem boyunca karşılık gelen parçaları doğrular validator öğesinin atandığı parçalara. Parçalar yerine bloklar üzerinde oturum açın. Parça ataması gizlendiğinden validator parçalar üzerinde oturum açamaz. Bunun yerine her zaman bütünü imzalar böylece hangi parçaları doğruladığını açığa çıkarmıyor. Özellikle, validator bir blok alıp tüm parçaları doğruladığında ya bir mesaj oluşturur bu, validator öğesinin atandığı tüm parçalardaki tüm parçaların geçerli (bu parçaların ne olduğunu hiçbir şekilde belirtmeden) veya herhangi bir parçanın geçersiz olması durumunda geçersiz durum geçişinin kanıtını içerir. Bkz. Bu tür mesajların nasıl bir araya getirildiğine ilişkin ayrıntılar için bölüm 3.8, aşağıdakiler için bölüm 3.7.4: validators adlı kişinin gelen iletileri arka arkaya almasının nasıl önleneceğine ilişkin ayrıntılar nasıl ödüllendirileceği ve cezalandırılacağıyla ilgili ayrıntılar için diğer validators ve bölüm 3.7.5'e bakın validators başarılı bir geçersiz durum geçiş sorunu gerçekten meydana gelirse.Şekil 24: Nightshade'de validator'leri gizlemek 3.7.4 Taahhüt-Açıklama validators ile ilgili yaygın sorunlardan biri, validator'nin durumu indirmeyi ve aslında parçaları ve blokları doğrulamayı atlayabilmesi ve bunun yerine Ağı gözlemleyin, diğer validator'ların neler gönderdiğini görün ve yaptıklarını tekrarlayın. mesajlar. Böyle bir stratejiyi izleyen bir validator fazladan bir şey sağlamaz ağ için güvenlik sağlar, ancak ödüller toplar. Bu soruna yönelik yaygın bir çözüm, her validator için bir kanıt sağlamaktır örneğin benzersiz bir izleme sağlayarak bloğu gerçekten doğruladıklarını devlet geçişini uygulamak, ancak bu tür kanıtlar maliyeti önemli ölçüde artırıyor doğrulama. Şekil 25: Taahhüt-açıklama

Bunun yerine validators'nin doğrulama sonucuna ilişkin ilk taahhüdünü yaparız (veya parçaların geçerliliğini doğrulayan mesaj veya geçersiz olduğunun kanıtı durum geçişi), belirli bir süre bekleyin ve ancak bundan sonra şekil 25'te gösterildiği gibi gerçek doğrulama sonucunu ortaya çıkarın. ortaya çıkma dönemidir ve bu nedenle tembel bir validator dürüst validator'leri taklit edemez. Ayrıca, dürüst olmayan bir validator şunu doğrulayan bir mesaj gönderirse: atanan parçaların geçerliliği ve en az bir parçanın geçersiz olması durumunda öbeğin geçersiz olduğu gösterildiğinde validator eğik çizgiden kaçınamaz, çünkü, Bölüm 3.7.5'te gösterdiğimiz gibi böyle bir durumda kesilmemenin tek yolu geçersiz durum geçişinin kanıtını içeren bir mesaj sunmaktır. taahhütle eşleşir. 3.7.5 Zorluklarla baş etme Yukarıda tartışıldığı gibi, validator geçersiz parçaya sahip bir blok aldığında, önce geçersiz durum geçişinin kanıtını hazırlarlar (bkz. bölüm 3.7.1), ardından böyle bir kanıtı taahhüt edin (bkz. 3.7.4) ve bir süre sonra zorluğu ortaya çıkarın. Ortaya çıkan zorluk bir bloğa dahil edildiğinde aşağıdakiler gerçekleşir: 1. Bloktan gerçekleşen tüm durum geçişleri Ortaya çıkan zorluğun dahil edildiği bloğa kadar geçersiz parça hükümsüz kılındı. Ortaya çıkan mücadeleyi içeren bloktan önceki durum içeren bloktan önceki durumla aynı olduğu kabul edilir geçersiz yığın. 2. Belirli bir süre içinde her validator kendi bit maskesini göstermelidir doğruladıkları parçalar. Bit maskesi bir VRF aracılığıyla oluşturulduğundan, geçersiz durum geçişine sahip olan parçaya atandılar, ifşa etmekten kaçınamaz. Bit maskesini ortaya çıkaramayan herhangi bir validator parçaya atandığı varsayılmaktadır. 3. Bu süre sonunda parçaya atandığı tespit edilen her validator, içeren blok için bazı doğrulama sonuçları taahhüt etti geçersiz yığın ve bu geçersiz durum geçişinin kanıtını ortaya çıkarmadı bu onların taahhütlerine karşılık gelir. 4. Her validator yeni bir parça ataması alır ve yeni bir dönem planlanır tüm validator'ların indirmesi için yeterli bir süre sonra başlamak üzere Şekil 26'da gösterildiği gibi. validator'lerin kendilerine atanan parçaları ortaya çıkardığı andan itibaren unutmayın yeni dönem başlayana kadar sistemin güvenliği azaltılmıştır. Shard'ın ataması ortaya çıktı. Ağın katılımcılarının bunu saklaması gerekir Bu dönemde ağı kullanırken aklınızda bulundurun. 3.8 İmza Toplama Yüzlerce parçaya sahip bir sistemin güvenli bir şekilde çalışabilmesi için, 10.000 veya daha fazla validators sırası. Bölüm 3.7'de tartışıldığı gibi, her birini istiyoruz.Şekil 26: Mücadeleyi ele almak validator ortalama olarak belirli bir mesaja ve imzaya yönelik bir taahhüt yayınlamak için blok başına bir kez. Taahhüt mesajları aynı olsa bile, böyle bir şeyin toplanması BLS imzası ve bunun doğrulanması son derece pahalı olurdu. Ama doğal olarak taahhüt ve açıklama mesajları validators genelinde aynı değildir, dolayısıyla bu tür mesajları ve imzaları bir araya getirmenin bir yoluna ihtiyacımız var. Daha sonra hızlı doğrulamaya izin veren bir yol. Kullandığımız özel yaklaşım şudur: Doğrulayıcılar blok üreticilerine katılıyor. Blok üreticileri biliniyor çağın başlamasından bir süre önce, çünkü indirmeleri için biraz zamana ihtiyaçları var. çağ başlamadan önceki durum ve validator'lerden farklı olarak blok üreticileri gizlenmedi. Her blok üreticisinin v validator yuvası vardır. Doğrulayıcılar gönderir Blok üreticilerine v'lerinden biri olarak dahil edilmeleri için zincir dışı teklifler validators. Bir blok üreticisi validator eklemek isterse, validator'den gelen ilk zincir dışı talebi içeren işlem ve validator öğesinin blok üreticisine katılmasını sağlayan blok üreticisinin imzası. Blok üreticilerine atanan validator'lerin zorunlu olarak atanmadığını unutmayın. Blok üreticisinin parçalar ürettiği aynı parçaları doğrulayın. eğer bir Birden fazla blok üreticisini birleştirmek için validator uygulandı, yalnızca işlem ilk blok üreticisi başarılı olacaktır. Blok üreticileri taahhütleri toplar. Blok üreticisi sürekli olarak validators'den taahhüt ve açıklama mesajlarını toplar. Bu tür mesajların belirli bir sayısı toplandığında, blok üreticisi bir merkle hesaplar. bu mesajların ağacını oluşturur ve her validator'e merkle kökünü ve mesajlarına giden merkle yolu. validator yolu doğrular ve imzalar merkle kökü. Blok üreticisi daha sonra blok üzerinde bir BLS imzası biriktirir. validators'den merkle kökü ve yalnızca merkle kökü ve birikmiş imza Blok üreticisi aynı zamanda sözleşmenin geçerliliğini de imzalar. Ucuz bir ECDSA imzası kullanarak çoklu imza. Çoklu imza çalışmıyorsa gönderilen merkle köküyle veya katılan validator'ların bit maskesiyle eşleşirse, bu eğik çizgi çizilebilir bir davranıştır. Zinciri senkronize ederken bir katılımcı validator'lerden gelen tüm BLS imzalarını doğrulamayı seçebilir (bu, validator'nin ortak anahtarlarının toplanmasını gerektirdiğinden son derece pahalıdır) veya yalnızcaBlok üreticilerinin ECDMA imzalarına güveniyoruz ve blok üreticisine meydan okunmadı ve kesildi. Zorluklar için zincir içi işlemleri ve merkle kanıtlarını kullanma. o eğer hayırsa validators'den gelen mesajları açığa çıkarmanın hiçbir değeri olmadığı belirtilebilir. geçersiz durum geçişi algılandı. Yalnızca gerçek bilgiyi içeren mesajlar Geçersiz durum geçişinin kanıtlarının açıklanması gerekir ve yalnızca bu tür mesajlar için önceki taahhütle eşleştiklerinin gösterilmesi gerekir. Mesajın ihtiyacı var iki amaçla ortaya çıkar: 1. Zincirin geri dönüşünü fiilen başlatmak için geçersiz durum geçişi (bkz. bölüm 3.7.5). 2. validator belgesinin geçerliliğini kanıtlamaya çalışmadığını kanıtlamak için geçersiz yığın. Her iki durumda da iki konuyu ele almamız gerekiyor: 1. Gerçek taahhüt zincire dahil edilmedi, yalnızca merkle kökü diğer mesajlarla birleştirilmiş taahhüt. validator öğesinin şunu kullanması gerekiyor: Blok üreticisi tarafından sağlanan merkle yolu ve orijinal taahhütleri bu mücadeleye kararlı olduklarını kanıtla. 2. Tüm validator'lerin geçersiz parçaya atanması mümkündür. durum geçişi bozuk blok üreticilerine atanacak bunları sansürlüyorlar. Bunu aşmak için onların açıklamalarını göndermelerine izin veriyoruz Zincir üzerinde düzenli bir işlem olarak ve toplamayı atlayarak. İkincisine yalnızca geçersiz durum geçişinin kanıtları için izin verilir; son derece nadirdir ve bu nedenle blokların spam gönderilmesiyle sonuçlanmamalıdır. Ele alınması gereken son konu, blok üreticilerinin iletilerin toplanmasına katılmamayı veya belirli validators'leri kasıtlı olarak sansürlememeyi tercih edin. Blok haline getirerek ekonomik açıdan dezavantajlı hale getiriyoruz üretici ödülü, kendilerine atanan validators sayısıyla orantılıdır. Biz ayrıca dönemler arasındaki blok üreticilerinin büyük ölçüde kesiştiğinden (çünkü her zaman en yüksek hisseye sahip olan en üstteki katılımcılardır), validator'ler yapabilir Büyük ölçüde aynı blok üreticileriyle çalışmaya devam edin ve böylece riski azaltın Geçmişte onları sansürleyen bir blok üreticisine atanmak. 3.9 Anlık Görüntü Zinciri Ana zincirdeki bloklar çok sık üretildiğinden indirme tarihin tamamı çok hızlı bir şekilde pahalı hale gelebilir. Üstelik her zamandan beri blok çok sayıda katılımcının BLS imzasını içeriyorsa, yalnızca imzayı kontrol etmek için ortak anahtarların toplanması engelleyici hale gelebilir aynı zamanda pahalı. Son olarak, öngörülebilir bir gelecekte Ethereum 1.0 muhtemelen bir tane olarak kalacak en çok kullanılan blockchain'lerden biridir ve varlıkları aktarmanın anlamlı bir yolunu sunar

Ethereum'ye yakın olması bir gerekliliktir ve bugün BLS imzalarının doğrulanması Ethereum tarafında yakın blokların geçerliliği mümkün değildir. Nightshade ana zincirindeki her blok isteğe bağlı olarak bir Schnorr içerebilir böyle bir Schnorr içeren son bloğun başlığındaki çoklu imza çoklu imza. Bu tür bloklara anlık görüntü blokları diyoruz. İlk blok her çağ bir anlık görüntü bloğu olmalıdır. Böyle bir çoklu imza üzerinde çalışırken, blok üreticileri ayrıca validators'nin BLS imzalarını da biriktirmelidir son anlık görüntü bloğuna yerleştirin ve bunları bölümünde açıklandığı şekilde toplayın. bölüm 3.8. Blok üreticilerinin belirlediği dönem boyunca sabit olduğundan doğrulama hiçbir çağda yalnızca ilk anlık görüntü blokları yeterlidir. blok üreticilerinin ve validator'lerin büyük bir yüzdesinin gizli anlaşma yapıp yarattığını gösteriyor bir çatal. Çağın ilk bloğu hesaplamaya yetecek bilgiyi içermelidir dönemin blok üreticileri ve validator'ler. Ana zincirin yalnızca anlık görüntüsünü içeren alt zincirine diyoruz. anlık görüntü zincirini engeller. Schnorr çoklu imzası oluşturmak etkileşimli bir süreçtir, ancak ne kadar verimsiz olursa olsun bunu nadiren gerçekleştirmeniz gerekir; yeterli olacaktır. Schnorr çoklu imzaları Ethereum üzerinde kolayca doğrulanabilir, böylece çapraz-blockchain gerçekleştirmenin güvenli bir yolu için önemli temel öğeler sağlanır iletişim. Yakın zincirle senkronizasyon için yalnızca tüm anlık görüntülerin indirilmesi gerekir bloklar ve Schnorr imzalarının doğru olduğunu onaylar (isteğe bağlı olarak validators'nin bireysel BLS imzalarını da doğrular) ve ardından yalnızca senkronizasyon son anlık görüntü bloğundan ana zincir blokları.

Nightshade

3.1 От цепочек осколков к чанкам осколков Модель шардинга с цепочками шардов и цепочкой маяков очень мощная, но имеет определенные сложности. В частности, необходимо выполнить правило выбора вилки. в каждой цепочке отдельно правило выбора форка в шардчейнах и маяке цепочка должна быть построена по-другому и протестирована отдельно. В Nightshade мы моделируем систему как единый blockchain, в котором каждый блок логически содержит все транзакции для всех шардов и изменяет целое состояние всех осколков. Однако физически ни один участник не загружает полное состояние или полный логический блок. Вместо этого каждый участник сети только поддерживает состояние, соответствующее шардам, для которых они проверяют транзакции, а список всех транзакций в блоке разбивается на физические куски, по одному куску на осколок. В идеальных условиях каждый блок содержит ровно один чанк на каждый шард. блок, что примерно соответствует модели с шардчейнами, в которых Цепочки осколков производят блоки с той же скоростью, что и цепочка маяков. Однако, из-за задержек в сети некоторые фрагменты могут отсутствовать, поэтому на практике каждый блок содержит один или ноль фрагментов на каждый сегмент. Подробную информацию о том, как производятся блоки. Рисунок 16: Модель с цепочками шардов слева и с одной цепочкой, имеющей блоки разделены на куски справа

3.2 Консенсус Сегодня в blockchains преобладают два подхода к консенсусу: самая длинная (или самая тяжелая) цепочка, в которой цепочка с наибольшим количеством работы или доли используемый для его построения, считается каноническим, а BFT, в котором для каждого блока несколько набор validator достигает консенсуса BFT. В предложенных недавно протоколах последний подход является более доминирующим. поскольку он обеспечивает немедленную завершенность, в то время как в самой длинной цепочке требуется больше блоков. будет построен поверх блока, чтобы обеспечить завершенность. Часто для значимого безопасность время, необходимое для построения достаточного количества блоков, берет на себя порядок часов. Использование консенсуса BFT для каждого блока также имеет недостатки, такие как: 1. BFT консенсус предполагает значительный объем общения. Пока последние достижения позволяют достичь консенсуса за линейное время по количеству участников (см., например, [4]), все равно заметные накладные расходы на блок; 2. Невозможно участие всех участников сети в BFT. консенсус для каждого блока, поэтому обычно только случайно выбранная подгруппа участников достигает консенсуса. В принципе, случайно выбранный набор может быть адаптивно повреждается, и теоретически может быть создан форк. Система либо необходимо смоделировать, чтобы быть готовым к такому событию, и, следовательно, по-прежнему иметь правило выбора вилки помимо консенсуса BFT или быть спроектировано так, чтобы закрывать вниз в таком случае. Стоит отметить, что некоторые конструкции, такие как Algorand [5], значительно снижают вероятность адаптивного повреждения. 3. Самое главное, система глохнет, если 1 3 или более из всех участников оффлайн. Таким образом, любой временный сбой в сети или ее раскол могут полностью остановить работу системы. В идеале система должна иметь возможность продолжать работать до тех пор, пока хотя бы половина участников онлайн (самый тяжелый протоколы на основе цепочки продолжают работать, даже если в сети менее половины участников, но желательность этого свойства более спорна внутри сообщества). Гибридная модель, в которой используется консенсус, является своего рода самым тяжелым цепочка, но некоторые блоки периодически дорабатываются с помощью гаджета окончательности BFT, сохраняя преимущества обеих моделей. Такие BFT гаджеты завершения Casper FFG [6] используется в Ethereum 2.0 8, Casper CBC (см. https://vitalik. ca/general/2018/12/05/cbc_casper.html) и ДЕДУШКА (см. https:// medium.com/polkadot-network/d08a24a021b5), используемый в Polkadot. Nightshade использует консенсус самой тяжелой цепи. В частности, когда блок производитель производит блок (см. раздел 3.3), он может собирать подписи от другие производители блоков и validator, подтверждающие предыдущий блок. См. раздел 3.8, где подробно описано, как агрегируется такое большое количество подписей. Вес 8. Также посмотрите сеанс с Джастином Дрейком, где представлен подробный обзор Casper. FFG и то, как он интегрирован с консенсусом по самой тяжелой цепи GHOST, здесь: https://www. youtube.com/watch?v=S262StTwkmoблока является тогда совокупной долей всех подписавших, чьи подписи включен в блок. Вес цепочки — это сумма весов блоков. Помимо консенсуса по самой тяжелой цепочке, мы используем гаджет окончательности, который использует аттестации для завершения блоков. Чтобы уменьшить сложность системы, мы используем гаджет окончательности, который никак не влияет на правило выбора вилки, и вместо этого только вводит дополнительные условия разрезания, например, когда блок завершено с помощью гаджета окончательности, форк невозможен, если не будет очень большого процента общая ставка сокращается. Casper CBC — такой гаджет окончательности, и мы в настоящее время модель с учетом Casper CBC. Мы также работаем над отдельным протоколом BFT под названием TxFlow. Во время при написании этого документа неясно, будет ли использоваться TxFlow вместо Casper ЦБК. Однако отметим, что выбор окончательного устройства во многом ортогонален остальной части конструкции. 3.3 Производство блоков В Nightshade есть две роли: производители блоков и validators. В любом точка, в которой система содержит w производителей блоков, w = 100 в наших моделях и wv validators, в нашей модели v = 100, wv = 10 000. Система Proof-of-Stake, это означает, что и производители блоков, и validator имеют некоторое количество внутренних валюта (именуемая «tokens») заблокирована на период времени, намного превышающий время, которое они тратят на выполнение своих обязанностей по построению и проверке цепочки. Как и во всех системах Proof of Stake, не все производители блоков и не все wv validator являются разными объектами, поскольку это невозможно обеспечить. Каждый однако производители блоков w и wv validator имеют отдельные ставка. Система содержит n шардов, в нашей модели n = 1000. Как упоминалось в раздел 3.1, в Nightshade нет цепочек сегментов, вместо этого все производители блоков и validator создают единый blockchain, который мы называем основная цепь. Состояние основной цепи разбито на n шардов, и каждый блок продюсер и validator в любой момент загрузили локально только часть состояние, которое соответствует некоторому подмножеству шардов, и только процесс и проверять транзакции, которые влияют на эти части состояния. Чтобы стать производителем блоков, участник сети блокирует какие-то крупные сумма tokens (ставка). Обслуживание сети осуществляется в эпохи, где эпоха – это период времени порядка дней. Участники с самыми большими ставками в начале определенной эпохи являются блоком продюсеры той эпохи. Каждый производитель блоков назначается шардам SW (скажем, sw = 40, что означает, что sww/n = 4 производителя блоков на шард). Блок продюсер загружает состояние шарда, которому он назначен, до начала эпохи запускается и на протяжении всей эпохи собирает транзакции, влияющие на этот шард, и применяет их к государству. Для каждого блока b в основной цепочке и для каждого шарда s существует один из назначил производителей блоков s, который отвечает за производство части b, связанной с к осколку. Часть b, связанная с шардом s, называется чанком и содержит список транзакций для шарда, которые будут включены в b, а также merkleкорень результирующего состояния. b в конечном итоге будет содержать только очень маленький заголовок чанк, а именно корень Меркла всех примененных транзакций (см. раздел 3.7.1 для получения точных деталей) и корень Меркле конечного состояния. В оставшейся части документа мы часто ссылаемся на производителя блоков. который отвечает за создание чанка в определенное время для определенного шарда в качестве производителя чанка. Производитель чанка всегда является одним из производителей блоков. Производители блоков и производители фрагментов вращают каждый блок в соответствии с по фиксированному графику. Производители блоков имеют заказ и неоднократно производят блоки в таком порядке. Например. если имеется 100 производителей блоков, первый блок производители отвечают за производство блоков 1, 101, 201 и т. д., второй — ответственный за производство 2, 102, 202 и т. д.). Поскольку производство кусков, в отличие от производства блоков, требует поддержания состояние, и для каждого шарда только производители блоков sww/n поддерживают состояние на каждый шард, соответственно, только те производители блоков sww/n вращаются для создания куски. Например. с константами, указанными выше, с четырьмя производителями блоков, назначенными каждый осколок, каждый производитель блоков будет создавать чанки каждые четыре блока. 3.4 Обеспечение доступности данных Чтобы обеспечить доступность данных, мы используем подход, аналогичный подходу Polkadot. описано в разделе 2.5.3. Как только производитель блоков создает чанк, он создает его версия со стирающим кодом с оптимальным (w, ⌊w/6 + 1⌋) блочным кодом кусок. Затем они отправляют один фрагмент фрагмента стирающего кода (мы называем такие фрагменты части фрагмента или только части) каждому производителю блока. Мы вычисляем дерево Меркла, которое содержит все части в виде листьев и заголовок каждого чанка содержит корень Меркла такого дерева. Детали отправляются на validator через сообщения onepart. Каждое такое сообщение содержит заголовок чанка, порядковый номер части и содержимое части. сообщение также содержит подпись производителя блока, создавшего чанк и путь Меркла, чтобы доказать, что часть соответствует заголовку и производится соответствующим производителем блоков. Как только производитель блоков получает блок основной цепи, он сначала проверяет, иметь одночастные сообщения для каждого фрагмента, включенного в блок. Если нет, то блок не обрабатывается до тех пор, пока не будут получены недостающие одночастные сообщения. Как только все одночастные сообщения получены, производитель блока извлекает оставшиеся части от одноранговых узлов и реконструирует фрагменты, для которых они хранятся государство. Производитель блока не обрабатывает блок основной цепи, если хотя бы один раз чанк, включенный в блок, у них нет соответствующего одночастного сообщения, или если хотя бы для одного шарда, для которого они поддерживают состояние, они не могут реконструировать весь кусок. Для того, чтобы конкретный чанк был доступен, достаточно, чтобы ⌊w/6⌋+1 блока продюсеры имеют свои роли и обслуживают их. Таким образом, до тех пор, пока количество злоумышленники не превышают ⌊w/3⌋нет цепочки, имеющей более половины блока производители, создающие его, могут иметь недоступные фрагменты.Рисунок 17: Каждый блок содержит один или ноль фрагментов на каждый сегмент, и каждый блок имеет стирающий код. Каждая часть фрагмента стирающего кода отправляется назначенному заблокировать производителя через специальное одночастное сообщение 3.4.1 Работа с ленивыми производителями блоков Если у производителя блока есть блок, для которого отсутствует одночастное сообщение, он может решить подписаться на него, потому что, если блок окажется в цепочке, он максимизирует вознаграждение для производителя блока. Риска для блока нет. производителя, так как впоследствии невозможно доказать, что у производителя блока не было одночастное сообщение. Чтобы решить эту проблему, мы заставляем каждого производителя чанка при создании чанка выберите цвет (красный или синий) для каждой части будущего закодированного фрагмента и сохраните битовая маска назначенного цвета в фрагменте перед его кодированием. Каждая часть сообщение затем содержит цвет, назначенный детали, и этот цвет используется, когда вычисление корня Меркле закодированных частей. Если производитель чанка отклоняется из протокола это легко доказывается, так как либо корень Меркле не будет соответствуют одночастным сообщениям или цветам одночастных сообщений, которые соответствующие корню Меркла, не будут соответствовать маске в чанк. Когда производитель блока подписывает блок, он включает битовую маску всех красные части они получили за чанки, включенные в блок. Публикация неправильная битовая маска — это поведение, допускающее косую черту. Если производитель блока не получил одночастное сообщение, у них нет возможности узнать цвет сообщения, и таким образом, они имеют 50% шанс быть порезанными, если попытаются вслепую подписать документ. блок. 3,5 Заявление о переходе состояния Производители чанка только выбирают, какие транзакции включать в чанк, но не применяйте переход состояния при создании фрагмента. Соответственно,

заголовок чанка содержит корень Меркла Меркелизованного состояния, как было раньше применяются транзакции в чане. Транзакции применяются только тогда, когда полный блок, включающий фрагмент, обрабатывается. Участник обрабатывает блок только в том случае, если 1. Предыдущий блок получен и обработан; 2. Для каждого фрагмента участник не поддерживает состояние, поскольку у него есть видел одночастное сообщение; 3. Для каждого фрагмента участник сохраняет состояние, поскольку у него есть полный кусок. После обработки блока для каждого шарда, по которому участник поддерживает состояние, они применяют транзакции и вычисляют новое состояние на момент применения транзакций, после чего они готовы производить чанки для следующего блока, если они назначены какому-либо шарду, поскольку у них есть Меркельский корень нового меркелизованного государства. 3.6 Межшардовые транзакции и квитанции Если транзакция должна затронуть более одного шарда, ее необходимо выполнить последовательно. выполняется в каждом шарде отдельно. Полная транзакция отправляется в первый шард затронуты, и как только транзакция будет включена в чанк такого шарда, и применяется после того, как чанк включен в блок, он генерирует так называемую квитанцию транзакция, которая направляется на следующий сегмент, в котором транзакция должна быть быть казнён. Если требуется больше шагов, выполнение транзакции поступления генерирует новую транзакцию получения и так далее. 3.6.1 Срок действия транзакции квитанции Желательно, чтобы транзакция получения применялась в блоке, который следует сразу за блоком, в котором она была сгенерирована. Операция прихода осуществляется только генерируется после того, как предыдущий блок был получен и применен производителями блоков которые поддерживают исходный шард, и должны быть известны к моменту создания чанк для следующего блока создается производителями блоков пункта назначения осколок. Таким образом, квитанция должна быть передана от исходного шарда к целевой осколок за короткий промежуток времени между этими двумя событиями. Пусть A — последний произведенный блок, содержащий транзакцию t, генерирующую квитанцию r. Пусть B будет следующим созданным блоком (т.е. блоком, в котором A является его предыдущий блок), который мы хотим содержать r. Пусть t будет в шарде a, а r будет в осколок б. Срок действия квитанции, также изображенной на рисунке 18, следующий: Изготовление и хранение чеков. Цена за конверсию производителя чанка для шарда a получает блок A, применяет транзакцию t и генерирует квитанцию r. цена за конверсию затем сохраняет все такие полученные квитанции в своем внутреннем постоянном хранилище, проиндексированном по идентификатору исходного шарда.Раздача квитанций. Как только cpa будет готов создать чанк для шард a для блока B, они извлекают все квитанции, сгенерированные применением транзакций из блока A для шарда a, и включают их в чанк для фрагмента a в блоке B. Как только такой фрагмент сгенерирован, cpa создает его код стирания version и все соответствующие одночастные сообщения. cpa знает, какие производители блоков поддерживают полное состояние тех или иных шардов. Для конкретного производителя блоков bp cpa включает поступления, возникшие в результате применения транзакций в блоке А. для шарда a, в котором есть любой из шардов, которые bp считает местом назначения в одночастном сообщении, когда раздавали чанк для шарда a в блоке B (см. рисунок 17, на котором показаны квитанции, включенные в одночастное сообщение). Получение квитанций. Помните, что участники (как производители блоков, так и validators) не обрабатывают блоки, пока не получат одночастные сообщения. для каждого фрагмента, включенного в блок. Таким образом, к тому моменту, когда какой-либо конкретный участник применит блок B, у него будут все одночастные сообщения, соответствующие куски в B, и, таким образом, у них есть все входящие квитанции, содержащие фрагменты участник сохраняет состояние в качестве пункта назначения. При применении переход состояния для конкретного шарда, участник применяет обе расписки которые они собрали для шарда в onepart сообщениях, а также все транзакции, включенные в сам чанк. Рисунок 18: Срок действия транзакции получения 3.6.2 Обработка слишком большого количества квитанций Возможно, что количество квитанций, нацеленных на конкретный шард в конкретный блок слишком велик для обработки. Например, рассмотрим рисунок 19, каждая транзакция в каждом сегменте генерирует квитанцию, предназначенную для сегмента 1. К следующему блоку количество квитанций, которые должен обработать шард 1, равно сопоставимо с нагрузкой, которую все шарды вместе обрабатывали при обработке предыдущий блок.

Рисунок 19: Если все квитанции нацелены на один и тот же сегмент, этот сегмент может не иметь способность их обрабатывать Чтобы решить эту проблему, мы используем технику, аналогичную той, которая использовалась в QuarkChain 9. В частности, для каждого шарда последний блок B и последний шард внутри него блок, из которого были применены поступления, фиксируется. Когда новый осколок созданы, квитанция применяется в порядке очереди от оставшихся осколков в B, а затем в блоках, следующих за B, пока новый чанк не заполнится. В норме обстоятельствах при сбалансированной нагрузке это вообще приведет ко всем поступлениям применяется (и, таким образом, последний осколок последнего блока будет записан для каждый фрагмент), но в периоды, когда нагрузка не сбалансирована и определенный шард получает непропорционально много квитанций, эта техника позволяет им обрабатываться с соблюдением ограничений на количество включенных транзакций. Обратите внимание, что если такая несбалансированная нагрузка сохраняется в течение длительного времени, задержка от создание квитанции до тех пор, пока приложение не сможет продолжать расти бесконечно. Один способ решить эту проблему — отменить любую транзакцию, которая создает квитанцию, нацеленную на осколок, задержка обработки которого превышает некоторую константу (например, одну эпоху). Рассмотрим рисунок 20. К блоку B шард 4 не может обработать все поступления, поэтому он обрабатывает только получение квитанций до сегмента 3 в блоке A, и записывает это. В блок C включены поступления до 5-го шарда в блоке B, и затем к блоку D шард догоняет его, обрабатывая все оставшиеся поступления в блок Б и все поступления из блока С. 3,7 Проверка кусков Чанк, созданный для конкретного шарда (или блок шарда, созданный для конкретной цепочки шардов в модели с цепочками шардов), может быть проверен только 9См. эпизод с доской с QuarkChain здесь: https://www.youtube.com/watch?. v=opEtG6NM4x4, в котором, среди прочего, обсуждается подход к межшардовым транзакциям. вещиРисунок 20: Задержка обработки чеков участники, поддерживающие государство. Это могут быть производители блоков, validators, или просто внешние свидетели, которые загрузили состояние и проверили осколок в где они хранят активы. В этом документе мы предполагаем, что большинство участников не могут хранить состояние для значительной части осколков. Однако стоит упомянуть, что существуют сегментированные blockchain, разработанные с учетом предположения, что большинство участников имеют возможность хранить состояние и проверять большую часть осколки, такие как QuarkChain. Поскольку только часть участников имеет состояние для проверки шарда куски, можно адаптивно испортить только тех участников, у которых есть состояние и применить недопустимый переход между состояниями. Было предложено несколько схем шардинга, в которых каждые несколько раз отбирались validators. дней, а в течение суток любой блок в цепочке шардов, имеющий более 2/3 подписей validators, присвоенных такому шарду, учитывается немедленно окончательный. При таком подходе адаптивному противнику достаточно испортить только 2n/3+1. validator в цепочке сегментов, чтобы применить недопустимый переход состояния, который, хотя это, вероятно, трудно осуществить, уровень безопасности не является достаточным для общественного blockchain. Как обсуждалось в разделе 2.3, общий подход заключается в том, чтобы предоставить определенное окно времени после создания блока для любого участника, у которого есть состояние (независимо от того, является ли он это производитель блока, validator или внешний наблюдатель), чтобы оспорить его достоверность. Таких участников называют Рыбаками. Чтобы рыбак мог оспорить недействительный блок, необходимо убедиться, что такой блок доступен для их. Доступность данных в Nightshade обсуждается в разделе 3.4. В Nightshade после создания блока фрагменты не проверялись кто угодно, кроме фактического производителя фрагментов. В частности, производитель блоков, который предположил, что блок, естественно, не имеет состояния большинства осколков, ине смог проверить фрагменты. Когда создается следующий блок, он содержит подтверждения (см. раздел 3.2) нескольких производителей блоков и validator, но поскольку большинство производителей блоков и validator не поддерживают состояние для большинства шардов блок всего с одним недействительным чанком соберет значительно больше половины аттестаций и продолжит находиться в самом тяжелом состоянии. цепь. Для решения этой проблемы мы разрешаем любому участнику, поддерживающему состояние осколок для отправки запроса в цепочке для любого недопустимого фрагмента, созданного в этом осколок. 3.7.1 Проблема государственной действительности Как только участник обнаруживает, что конкретный фрагмент недействителен, ему необходимо предоставить доказательство того, что этот фрагмент недействителен. Поскольку большинство участников сети не поддерживают состояние шарда, в котором находится недействительный чанк доказательство должно содержать достаточную информацию, чтобы подтвердить, что блок недействителен без наличия гос. Мы устанавливаем ограничение Ls на количество состояний (в байтах), которое может хранить одна транзакция. может кумулятивно читать или писать. Любая транзакция, которая касается более Ls состояние считается недействительным. Помните из раздела 3.5, что чанк в конкретном блоке B содержатся только транзакции, которые необходимо применить, но не новый корень государства. Корнем состояния, включенным в фрагмент блока B, является состояние root перед применением таких транзакций, но после применения транзакций из последний фрагмент того же шарда перед блоком B. Злоумышленник, который желает применить недопустимый переход состояния, будет включать неправильный корень состояния в блоке B, который не соответствует корню состояния, полученному в результате применения транзакции в предыдущем фрагменте. Мы расширяем информацию, которую производитель чанка включает в чанк. Вместо того, чтобы просто включать состояние после применения всех транзакций, вместо этого включает корень состояния после применения каждого непрерывного набора транзакций, которые коллективно читать и записывать Ls байтов состояния. Благодаря этой информации для рыбаку, чтобы создать проблему, что переход между состояниями применяется неправильно. достаточно найти первый такой недопустимый корень состояния и включить только Ls байтов состояния, на которые влияют транзакции между последним корнем состояния (который был действительный) и текущий корень состояния с доказательствами Меркла. Тогда любой участник может проверить транзакции в сегменте и подтвердить, что чанк недействителен. Аналогично, если производитель чанка попытается включить транзакции, которые читают и записать более Ls байт состояния, для вызова достаточно включить первые Ls байтов, которых он касается с помощью доказательств Меркла, которых будет достаточно, чтобы применить транзакции и убедиться, что наступает момент, когда попытка производится чтение или запись содержимого за пределами Ls байт.

3.7.2 Рыбаки и быстрые транзакции между шардами Как обсуждалось в разделе 2.3, если мы предположим, что фрагменты шарда (или шард блоки в модели с цепочками осколков) могут быть недействительными и создавать проблемы период, это отрицательно влияет на завершенность и, следовательно, на межсегментную коммуникацию. В в частности, не может быть определен целевой сегмент любой межсегментной транзакции. исходный фрагмент или блок является окончательным до тех пор, пока период вызова не закончится (см. рисунок 21). Рисунок 21: Ожидание периода вызова перед применением квитанции Способ решения этой проблемы таким образом, чтобы транзакции между сегментами Instantenious означает, что осколок назначения не должен ждать периода вызова. после публикации транзакции исходного сегмента и примените транзакцию получения немедленно, но затем откатите целевой сегмент вместе с исходным шард, если позже исходный чанк или блок оказался недействительным (см. рис. 22). Это очень естественно относится к дизайну Nightshade, в котором осколок цепочки не являются независимыми, вместо этого все фрагменты шардов публикуются. вместе в одном блоке основной цепи. Если какой-либо фрагмент окажется недействительным, весь блок с этим чанком считается недействительным, а все блоки, построенные на самое верхнее. См. рисунок 23. Оба вышеупомянутых подхода обеспечивают атомарность, предполагая, что задача период достаточно длительный. Мы используем последний подход, поскольку обеспечение быстрых перекрестных транзакций в обычных обстоятельствах перевешивает неудобства целевой сегмент откатывается из-за недопустимого перехода состояния в одном из исходные осколки, что является крайне редким событием. 3.7.3 Скрытие validators Наличие проблем уже существенно снижает вероятность адаптивное повреждение, поскольку для завершения фрагмента с недопустимым постом перехода состоянияРисунок 22: Немедленное применение квитанций и откат пункта назначения цепочка, если в исходной цепочке был недопустимый блок Рисунок 23: Испытание рыбака в Nightshade период испытания, который необходим адаптивному противнику, чтобы развратить всех участников которые поддерживают состояние шарда, включая все validator. Оценить вероятность такого события чрезвычайно сложно, поскольку нет sharded blockchain существует достаточно долго, чтобы можно было предпринять попытку такой атаки. Мы утверждаем, что вероятность, хотя и чрезвычайно мала, все же достаточно велика. большой для системы, которая, как ожидается, будет выполнять многомиллионные транзакции и управлять финансовыми операциями по всему миру. Есть две основные причины такого убеждения: 1. Большинство validator цепей Proof-of-Stake и майнеров

Цепочки Proof-of-Work в первую очередь стимулируются финансовым потенциалом. Если адаптивный противник предлагает им больше денег, чем ожидаемая прибыль от честной работы, разумно ожидать, что многие validators примет предложение. 2. Многие организации профессионально проводят проверку цепочек Proof-of-Stake, и ожидается, что большой процент акций в любой цепочке будет от таких субъектов. Число таких объектов достаточно мало для адаптивного противника, чтобы узнать большинство из них лично и получить хорошее понимание своей склонности к развращению. Мы делаем еще один шаг вперед в снижении вероятности адаптивного повреждения, скрывая, какие validator назначены какому шарду. Идея в том, отдаленно похоже на то, как Algorand [5] скрывает validators. Очень важно отметить, что даже если validator скрыты, как в Algorand, или, как описано ниже, адаптивное повреждение теоретически все еще возможно. Пока адаптивный противник не знает участников, которые будут создавать или проверять блок или чанк, участники сами знают, что будут выполнять такую задачу и иметь криптографическое доказательство этого. Таким образом, противник может сообщать о своем намерении совершить коррупцию и платить любому участнику, который предоставит такое криптографическое доказательство. Однако отметим, что, поскольку противник не знать validator, которые назначены на шард, который они хотят повредить, они не имеют другого выбора, кроме как передать свое намерение испортить конкретный осколок все сообщество. В этот момент это экономически выгодно для любого честного участнику развернуть полный узел, который проверяет этот шард, поскольку существует высокая вероятность появления недействительного блока в этом осколке, что дает возможность создайте испытание и получите соответствующую награду. Чтобы не раскрывать validator, назначенные конкретному шарду, мы делаем следующее (см. рисунок 24): Использование VRF для получения задания. В начале каждой эпохи каждый validator использует VRF для получения битовой маски сегментов, которым назначен validator. Битовая маска каждого validator будет иметь биты Sw (определение см. в разделе 3.3). Sw). Затем validator извлекает состояние соответствующих фрагментов и в течение эпохи для каждого полученного блока проверяет соответствующие фрагменты к шардам, которым назначен validator. Подписывайтесь на блоки, а не на куски. Поскольку назначение сегментов скрыто, validator не может подписывать фрагменты. Вместо этого он всегда подписывает всю блокировать, таким образом не раскрывая, какие шарды он проверяет. В частности, когда validator получает блок и проверяет все фрагменты, он либо создает сообщение это свидетельствует о том, что все чанки во всех шардах, которым назначен validator, являются действительным (без указания каким-либо образом, что это за осколки), или сообщение, которое содержит доказательство недопустимого перехода состояния, если какой-либо фрагмент недействителен. См. раздел 3.8 содержит подробную информацию о том, как агрегируются такие сообщения, раздел 3.7.4 — подробности о том, как предотвратить использование validators в сообщениях от другие validator и раздел 3.7.5, где подробно описано, как вознаграждать и наказывать. validators, если действительно произойдет успешный вызов недопустимого перехода состояния.Рисунок 24: Сокрытие validator в Nightshade 3.7.4 Фиксация-Раскрытие Одна из распространенных проблем с validator заключается в том, что validator может пропустить загрузку состояния и фактическую проверку фрагментов и блоков, а вместо этого понаблюдайте за сетью, посмотрите, что отправляют другие validator, и повторите свои сообщения. validator, следующий такой стратегии, не дает никаких дополнительных безопасность сети, но получает вознаграждение. Обычное решение этой проблемы состоит в том, чтобы каждый validator предоставил доказательство. что они действительно проверили блок, например, предоставив уникальную трассировку применения перехода состояний, но такие доказательства значительно увеличивают стоимость проверки. Рисунок 25: Фиксация-раскрытие

Вместо этого мы сначала делаем validator фиксацией результата проверки (либо сообщение, подтверждающее достоверность фрагментов или доказательство недействительности перехода состояния), подождите определенный период и только потом покажите фактический результат проверки, как показано на рисунке 25. Период фиксации не пересекается с период раскрытия, и поэтому ленивый validator не может подражать честным validator. Более того, если нечестный validator передал сообщение, подтверждающее достоверность назначенных фрагментов, и по крайней мере один фрагмент был недействителен, как только он будет показано, что чанк недействителен, validator не может избежать косой черты, поскольку как мы покажем в разделе 3.7.5, единственный способ не порезаться в такой ситуации состоит в том, чтобы представить сообщение, содержащее доказательство недопустимого перехода состояния, которое соответствует коммиту. 3.7.5 Решение проблем Как обсуждалось выше, как только validator получает блок с недопустимым чанком, сначала они готовят доказательство недопустимого перехода состояний (см. раздел 3.7.1), затем возьмите на себя такое доказательство (см. 3.7.4) и через некоторое время раскройте проблему. После включения выявленного вызова в блок происходит следующее: 1. Все переходы состояний, произошедшие из блока, содержащего недействительный фрагмент до тех пор, пока не будет получен блок, в который включен обнаруженный вызов. аннулировано. Состояние перед блоком, включающим обнаруженную задачу считается таким же, как состояние до блока, который содержал недействительный фрагмент. 2. В течение определенного периода времени каждый validator должен раскрыть свою битовую маску. осколков, которые они проверяют. Поскольку битовая маска создается через VRF, если они были назначены шарду с недопустимым переходом состояния, они не могу не раскрыть этого. Любой validator, который не раскрывает битовую маску. предполагается, что он назначен сегменту. 3. Каждый validator, который по истечении этого периода оказывается назначенным сегменту, который действительно зафиксировал некоторый результат проверки для блока, содержащего неверный фрагмент, и это не выявило доказательства недопустимого перехода состояния это соответствует их коммиту. 4. Каждый validator получает новое назначение осколков, и назначается новая эпоха. начать через некоторое время, достаточное для того, чтобы все validators загрузили состояние, как показано на рисунке 26. Обратите внимание, что с того момента, как validator раскрывают назначенные им шарды до тех пор, пока не начнется новая эпоха, безопасность системы снижается, поскольку Назначение осколков раскрыто. Участникам сети необходимо его сохранить иметь в виду при использовании сети в течение такого периода. 3,8 Агрегация подписей Чтобы система с сотнями шардов работала безопасно, мы хотим иметь порядка 10 000 или более validators. Как обсуждалось в разделе 3.7, мы хотим, чтобы каждыйРисунок 26: Решение проблемы validator для публикации коммита к определенному сообщению и подписи в среднем один раз за блок. Даже если сообщения о фиксации были одинаковыми, объединение таких BLS-подпись и ее проверка были бы непомерно дорогими. Но естественно, сообщения фиксации и раскрытия не одинаковы для validator, и поэтому нам нужен какой-то способ агрегировать такие сообщения и подписи в способ, позволяющий провести быструю проверку позже. Конкретный подход, который мы используем, заключается в следующем: Валидаторы присоединяются к производителям блоков. Известны производители блоков за некоторое время до начала эпохи, так как им нужно некоторое время, чтобы загрузить состояние до начала эпохи, и в отличие от validators производители блоков не скрыто. Каждый производитель блоков имеет v validator слотов. Валидаторы отправляют оффчейн предложения производителям блоков, чтобы они были включены в качестве одного из их v validatorс. Если производитель блока желает включить validator, он отправляет транзакция, которая содержит первоначальный запрос вне цепочки от validator и подпись производителя блока, которая заставляет validator присоединиться к производителю блока. Обратите внимание, что validator, назначенные производителям блоков, не обязательно проверять те же фрагменты, для которых производитель блоков создает фрагменты. Если validator применяется для объединения нескольких производителей блоков, только транзакция из первый производитель блоков добьется успеха. Производители блоков собирают коммиты. Производитель блоков постоянно собирает сообщения о фиксации и раскрытии от validator. Как только накапливается определенное количество таких сообщений, производитель блока вычисляет коэффициент Меркла. дерево этих сообщений и отправляет каждому validator корень Меркла и merkle путь к их сообщению. validator проверяет путь и регистрируется. корень Меркеля. Затем производитель блока накапливает подпись BLS на корень Меркла из validators и публикует только корень Меркла и накопленная подпись. Производитель блока также подписывает действительность мультиподпись с использованием дешевой подписи ECDSA. Если мультиподпись не соответствует отправленному корню Меркла или битовой маске участвующих validator, это поведение, допускающее косую черту. При синхронизации цепочки участник может выбрать проверку всех подписей BLS из validator (что чрезвычайно дорого, поскольку включает в себя агрегирование открытых ключей validator) или толькоподписи ECDMA от производителей блоков и полагаются на тот факт, что Продюсер блока не подвергся сомнению и не был порезан. Использование внутрисетевых транзакций и доказательств Меркла для решения проблем. Это можно отметить, что нет смысла раскрывать сообщения от validators, если нет Обнаружен недопустимый переход состояния. Только те сообщения, которые содержат реальные доказательства недопустимого перехода состояния должны быть выявлены, и только для таких сообщений необходимо показать, что они соответствуют предыдущему коммиту. Сообщение должно раскрываться с двумя целями: 1. Фактически инициировать откат цепочки к моменту перед недопустимый переход состояния (см. раздел 3.7.5). 2. Чтобы доказать, что validator не пытался подтвердить действительность недействительный фрагмент. В любом случае нам необходимо решить две проблемы: 1. Фактический коммит не был включен в цепочку, только корень Меркла commit в совокупности с другими сообщениями. validator необходимо использовать путь Меркла, предоставленный производителем блока, и их первоначальная фиксация доказать, что они приняли вызов. 2. Возможно, что все validator, назначенные шарду с невалидным переход состояния назначается поврежденным производителям блоков, которые подвергают их цензуре. Чтобы обойти это, мы позволяем им отправлять свои откровения. как обычная транзакция в цепочке и в обход агрегации. Последнее допускается только для доказательств недопустимого перехода состояния, которые крайне редко и, следовательно, не должно приводить к спаму блоков. Последний вопрос, который необходимо решить, заключается в том, что производители блоков могут отказаться от участия в агрегировании сообщений или намеренно подвергать цензуре отдельные validator. Мы делаем это экономически невыгодным, делая блок вознаграждение производителя, пропорциональное количеству назначенных ему validators. Мы также обратите внимание, что поскольку производители блоков между эпохами во многом пересекаются (поскольку это всегда лучшие участники с самой высокой ставкой), validators могут в основном придерживаться работы с одними и теми же производителями блоков и тем самым снизить риск о том, что их назначили производителю блоков, который подвергал их цензуре в прошлом. 3,9 Цепочка снимков Поскольку блоки в основной цепочке производятся очень часто, загрузка полная история может очень быстро стать дорогой. Более того, поскольку каждый блок содержит BLS-подпись большого количества участников, просто агрегирование открытых ключей для проверки подписи может стать непомерно высоким к тому же дорого. Наконец, поскольку в обозримом будущем Ethereum 1.0, скорее всего, так и останется из наиболее часто используемых blockchain, имеющих смысловой способ передачи активов из

Требуется близко к Ethereum, и сегодня проверка подписей BLS для обеспечения Действие ближних блоков на стороне Ethereum невозможно. Каждый блок в основной цепочке Nightshade может опционально содержать блок Шнорра. мультиподпись в заголовке последнего блока, в котором был такой Шнорр мультиподпись. Мы называем такие блоки блоками моментальных снимков. Самый первый блок каждая эпоха должна быть блоком моментального снимка. Работая над такой мультиподписью, производители блоков также должны накопить подписи BLS validator. в последнем блоке моментальных снимков и агрегируем их так же, как описано в разделе раздел 3.8. Поскольку набор производителей блоков постоянен на протяжении всей эпохи, проверка достаточно только первых блоков снимков в каждой эпохе, предполагая, что ни в одном случае указывает на то, что большой процент производителей блоков и validators вступили в сговор и создали вилка. Первый блок эпохи должен содержать информацию, достаточную для вычисления производители блоков и validators для эпохи. Мы вызываем подцепь основной цепочки, которая содержит только снимок. блокирует цепочку снимков. Создание мультиподписи Шнорра — интерактивный процесс, но поскольку мы только нужно выполнять его нечасто, любой, даже самый неэффективный процесс будет достаточно. Мультиподписи Шнорра можно легко проверить на Ethereum, тем самым предоставляя важные примитивы для безопасного выполнения перекрестного blockchain общение. Для синхронизации с цепочкой Near достаточно скачать весь снимок блоков и подтвердите правильность подписей Шнорра (при необходимости также проверьте отдельные подписи BLS validator), а затем только синхронизируйте блоки основной цепочки из последнего блока моментального снимка.

Çözüm

Bu belgede parçalı blockchains oluşturmaya yönelik yaklaşımları tartıştık ve mevcut yaklaşımlarla iki büyük zorluğu, yani durum geçerliliğini ele aldı ve veri kullanılabilirliği. Daha sonra bir parçalama tasarımı olan Nightshade'i sunduk. NEAR Protokolüne güç verir. Yorumlarınız, sorularınız veya geri bildirimleriniz varsa tasarım üzerinde çalışma devam etmektedir bu belgede lütfen https://near.chat. adresine gidin

Заключение

В этом документе мы обсудили подходы к созданию сегментированных blockchain и охватили две основные проблемы существующих подходов, а именно валидность состояния и доступность данных. Затем мы представили Nightshade, дизайн шардинга, который полномочия NEAR Протокола. Дизайн находится в стадии разработки, если у вас есть комментарии, вопросы или отзывы. в этом документе перейдите по адресу https://near.chat.