Das NEAR-Whitepaper
Validez del estado y disponibilidad de datos
La idea central en blockchains fragmentados es que la mayoría de los participantes que operan o el uso de la red no puede validar bloques en todos los fragmentos. Como tal, siempre que cualquier participante necesita interactuar con un fragmento en particular que generalmente no puede descargue y valide el historial completo del fragmento. El aspecto de partición de la fragmentación, sin embargo, plantea un potencial significativo problema: sin descargar y validar el historial completo de un determinado fragmento, el participante no puede necesariamente estar seguro de que el estado con el que 5Esta sección, excepto la subsección 2.5.3, se publicó anteriormente en https://near.ai/ fragmento2. Si lo leíste antes, salta a la siguiente sección.
interactúan es el resultado de alguna secuencia válida de bloques y que dicha secuencia de bloques es de hecho la cadena canónica en el fragmento. Un problema que no existe en un blockchain no fragmentado. Primero presentaremos una solución simple a este problema que ha sido propuesta. por muchos protocolos y luego analizar cómo esta solución puede romperse y qué se han hecho intentos para abordarlo. 2.1 Rotación de validadores La solución ingenua a la validez del estado se muestra en la figura 5: digamos que asumimos que todo el sistema tiene del orden de miles de validators, de los cuales no más del 20% son maliciosos o fallarán de otra manera (por ejemplo, al no ser en línea para producir un bloque). Entonces, si tomamos una muestra de 200 validators, la probabilidad de más de 1 3 reprobados a efectos prácticos se puede suponer que es cero. Figura 5: Muestreo validators 1 3 es un umbral importante. Existe una familia de protocolos de consenso, llamados BFT protocolos de consenso, que garantizan que mientras menos de 1 3 de los participantes fallan, ya sea al estrellarse o al actuar de alguna manera que viole las protocolo, se alcanzará el consenso. Con esta suposición de porcentaje honesto validator, si el conjunto actual de validators en un fragmento nos proporciona algún bloque, la solución ingenua supone que el bloque es válido y que está construido sobre lo que los validators creían que era la cadena canónica para ese fragmento cuando comenzaron a validar. Los validators aprendió la cadena canónica del conjunto anterior de validators, quienes por el mismo suposición construida sobre el bloque que era la cabeza de la cadena canónica antes de eso. Por inducción toda la cadena es válida y dado que no hay un conjunto de validators en cualquier momento se producen bifurcaciones, la solución ingenua también es segura de que la corriente chain es la única cadena en el fragmento. Consulte la figura 6 para obtener una visualización.
Figura 6: Un blockchain con cada bloque finalizado mediante el consenso BFT Esta solución simple no funciona si asumimos que los validators pueden ser corrompidos adaptativamente, lo cual no es una suposición descabellada6. Adaptablemente corromper un solo fragmento en un sistema con 1000 fragmentos es significativamente más barato que corromper todo el sistema. Por tanto, la seguridad del protocolo disminuye linealmente con el número de fragmentos. Para tener certeza en la validez de un bloque, debemos saber que en cualquier momento de la historia ningún fragmento del sistema ha una mayoría de validators en connivencia; con adversarios adaptativos, ya no tenemos tal certeza. Como comentamos en la sección 1.5, los validator en colusión pueden ejercer dos comportamientos maliciosos básicos: crear bifurcaciones y producir bloques no válidos. Las bifurcaciones maliciosas pueden abordarse mediante bloques que se entrecruzan con la cadena Beacon, que generalmente está diseñada para tener una seguridad significativamente mayor que la cadena Beacon. las cadenas de fragmentos. Sin embargo, producir bloques no válidos es una tarea mucho más problema desafiante de abordar. 2.2 Validez del estado Considere la figura 7 en la que el fragmento #1 está dañado y un actor malicioso produce bloque B no válido. Supongamos que en este bloque B se acuñaron 1000 tokens de la nada aire en la cuenta de Alice. El actor malintencionado produce entonces un bloque C válido (en un sentido de que las transacciones en C se aplican correctamente) encima de B, ofuscando el bloque B no válido e inicia una transacción entre fragmentos al fragmento #2 que transfiere esos 1000 tokens a la cuenta de Bob. A partir de este momento el mal Los token creados residen en un blockchain completamente válido en el fragmento #2. Algunos enfoques simples para abordar este problema son: 6Leer esto artículo para detalles en como adaptativo corrupción puede ser llevado fuera: https://medium.com/nearprotocol/d859adb464c8. Para más detalles en adaptativo corrupción, leer https://github.com/ethereum/wiki/wiki/Sharding-FAQ# ¿Cuáles-son-los-modelos-de-seguridad-bajo-los-que-estamos-operando?Figura 7: Una transacción entre fragmentos de una cadena que tiene un bloque no válido 1. Para validators del fragmento #2 para validar el bloque desde el cual se realizó la transacción se inicia. Esto no funcionará ni siquiera en el ejemplo anterior, ya que el bloque C parece ser completamente válido. 2. Para validators en el fragmento #2 para validar una gran cantidad de bloques que preceden al bloque desde el cual se inicia la transacción. Naturalmente, para cualquier número de bloques N validados por el fragmento receptor el malicioso validators pueden crear N+1 bloques válidos además del bloque no válido que producido. Una idea prometedora para resolver este problema sería organizar los fragmentos en un gráfico no dirigido en el que cada fragmento está conectado a varios otros fragmentos, y solo permitir transacciones entre fragmentos entre fragmentos vecinos (por ejemplo, así es como La fragmentación de Vlad Zamfir esencialmente funciona7, y una idea similar se utiliza en la de Kadena. Chainweb [1]). Si se necesita una transacción entre fragmentos entre fragmentos que están no vecinos, dicha transacción se enruta a través de múltiples fragmentos. en este diseño Se espera que un validator en cada fragmento valide todos los bloques en su fragmento así como todos los bloques en todos los fragmentos vecinos. Considere una figura a continuación con 10 fragmentos, cada uno con cuatro vecinos y no hay dos fragmentos que requieran más de dos saltos para una comunicación entre fragmentos como se muestra en la figura 8. El fragmento #2 no solo valida su propio blockchain, sino también los blockchains de todos los vecinos, incluido el fragmento n.° 1. Entonces, si un actor malicioso en el fragmento #1 está intentando crear un bloque B no válido, luego construye el bloque C encima de él e inicia una transacción entre fragmentos, dicha transacción entre fragmentos no se realizará desde el Fragmento #2 habrá validado toda la historia del Fragmento #1 que hará que identifique el bloque B no válido. 7Lea más sobre el diseño aquí: https://medium.com/nearprotocol/37e538177ed9
Figura 8: Una transacción entre fragmentos no válida en un sistema tipo cadena web que ser detectado Si bien corromper un único fragmento ya no es un ataque viable, corromper un pocos fragmentos siguen siendo un problema. En la figura 9, un adversario corrompiendo ambos Shard
1 y el fragmento #2 ejecutan con éxito una transacción entre fragmentos al fragmento #3
con fondos de un bloque B no válido: Figura 9: Una transacción entre fragmentos no válida en un sistema tipo cadena web que no ser detectado El fragmento n.º 3 valida todos los bloques del fragmento n.º 2, pero no del fragmento n.º 1, y no tiene forma de detectar el bloque malicioso. Hay dos direcciones principales para resolver adecuadamente la validez estatal: los pescadores
y pruebas criptográficas de cómputo. 2.3 pescador La idea detrás del primer enfoque es la siguiente: siempre que un encabezado de bloque se comunica entre cadenas para cualquier propósito (como el enlace cruzado con el cadena de baliza, o una transacción entre fragmentos), hay un período de tiempo durante cual cualquier validator honesto puede proporcionar una prueba de que el bloqueo no es válido. allí Hay varias construcciones que permiten pruebas muy sucintas de que los bloques son no válido, por lo que la sobrecarga de comunicación para los nodos receptores es mucho menor que el de recibir un bloqueo completo. Con este enfoque, siempre que haya al menos un validator honesto en el fragmento, el sistema es seguro. Figura 10: pescador Este es el enfoque dominante (además de fingir que el problema no existe) entre los protocolos propuestos hoy. Este enfoque, sin embargo, tiene dos principales desventajas: 1. El período de desafío debe ser lo suficientemente largo para el validator honesto. para reconocer que se produjo un bloque, descargarlo, verificarlo completamente y preparar el desafío si el bloque no es válido. La introducción de ese período ralentizar significativamente las transacciones entre fragmentos. 2. La existencia del protocolo de desafío crea un nuevo vector de ataques cuando los nodos maliciosos envían spam con desafíos no válidos. Una solución obvia a este problema es hacer que los retadores depositen una cierta cantidad de tokens que se devuelven si el desafío es válido. Esta es sólo una solución parcial, ya que Todavía podría ser benéfico para el adversario enviar spam al sistema (y quemar los depósitos) con impugnaciones no válidas, por ejemplo para impedir la validezdesafío de un honesto validator de pasar. Estos ataques son llamados ataques de duelo. Consulte la sección 3.7.2 para conocer una forma de evitar este último punto. 2.4 Argumentos de conocimiento sucintos y no interactivos La segunda solución a la corrupción de múltiples fragmentos es utilizar algún tipo de construcción criptográfica que permita demostrar que un determinado cálculo (como como calcular un bloque a partir de un conjunto de transacciones) se realizó correctamente. Este tipo de construcciones existen, p. zk-SNARK, zk-STARK y algunos otros, y algunos se utilizan activamente en los protocolos blockchain actuales para pagos privados, más notablemente ZCash. El principal problema con tales primitivos es que son notoriamente lentos de calcular. P.ej. Protocolo Coda, que utiliza zk-SNARK específicamente para demostrar que todos los bloques en el blockchain son válidos, dijo en un de las entrevistas que puede tomar 30 segundos por transacción para crear una prueba (Este número probablemente sea menor ahora). Curiosamente, no es necesario que una parte de confianza calcule una prueba, ya que la prueba no sólo da fe de la validez del cálculo para el que está construida, sino también de la la validez de la prueba misma. Por tanto, el cálculo de tales pruebas se puede dividir entre un conjunto de participantes con significativamente menos redundancia de lo que sería necesario realizar algún cálculo sin confianza. También permite a los participantes que calculan zk-SNARK para ejecutarse en hardware especial sin reducir el descentralización del sistema. Los desafíos de los zk-SNARK, además del rendimiento, son: 1. Dependencia de primitivas criptográficas menos investigadas y menos probadas; 2. "Residuos tóxicos": los zk-SNARK dependen de una configuración confiable en la que un grupo de personas realiza algún cálculo y luego descarta el intermedio valores de ese cálculo. Si todos los participantes del procedimiento se confabulan y se mantienen los valores intermedios, se pueden crear pruebas falsas; 3. Se introduce complejidad adicional en el diseño del sistema; 4. Los zk-SNARK solo funcionan para un subconjunto de cálculos posibles, por lo que un protocolo con un lenguaje Turing completo smart contract no podría usar SNARK para demostrar la validez de la cadena. 2.5 Disponibilidad de datos El segundo problema que abordaremos es la disponibilidad de datos. Generalmente nodos que operan un blockchain particular se separan en dos grupos: nodos completos, aquellos que descargan cada bloque completo y validan cada transacción, y Light Nodos, aquellos que solo descargan encabezados de bloques y usan pruebas de Merkle para las partes del estado y las transacciones que les interesan, como se muestra en la figura 11.
Figura 11: árbol de merkle Ahora bien, si la mayoría de los nodos completos se confabulan, pueden producir un bloque, válido o no es válido y envía su hash a los nodos de luz, pero nunca revela el contenido completo del bloque. Hay varias maneras en que pueden beneficiarse de ello. Por ejemplo, considere la figura 12: Figura 12: Problema de disponibilidad de datos Hay tres bloques: el anterior, A, está producido por validators honestos; el actual, B, tiene validators en connivencia; y el siguiente, C, también se producirá por validators honestos (el blockchain se muestra en la esquina inferior derecha). Eres un comerciante. Los validators del bloque actual (B) recibieron el bloque A de los validators anteriores, calculó un bloque en el que recibe dinero,y le envié un encabezado de ese bloque con una prueba Merkle del estado en el que tiene dinero (o una prueba Merkle de una transacción válida que envía el dinero a ti). Con la seguridad de que la transacción está finalizada, usted brinda el servicio. Sin embargo, los validators nunca distribuyen el contenido completo del bloque B a cualquiera. Como tal, los validator__s honestos del bloque C no pueden recuperar el bloque y se ven obligados a detener el sistema o a construir sobre A, privándolo a usted como comerciante de dinero. Cuando aplicamos el mismo escenario a la fragmentación, las definiciones de completo y El nodo ligero generalmente se aplica por fragmento: validators en cada fragmento descarga cada bloquear en ese fragmento y validar cada transacción en ese fragmento, pero otros nodos del sistema, incluidos aquellos que capturan el estado de las cadenas de fragmentos en el cadena de balizas, descargue solo los encabezados. Por lo tanto, los validators en el fragmento son efectivamente nodos completos para ese fragmento, mientras que otros participantes en el sistema, incluida la cadena de balizas, funcionan como nodos luminosos. Para que funcione el enfoque del pescador que analizamos anteriormente, los validators honestos Debe poder descargar bloques que estén vinculados cruzadamente a la cadena de baliza. Si validators maliciosos vinculaban un encabezado de un bloque no válido (o lo usaban para iniciar una transacción entre fragmentos), pero nunca distribuyó el bloque, el honesto Los validators no tienen forma de crear un desafío. Cubriremos tres enfoques para abordar este problema que complementan unos a otros. 2.5.1 Pruebas de custodia El problema más inmediato a resolver es si un bloque está disponible una vez esta publicado. Una idea propuesta es tener los llamados Notarios que rotan entre fragmentos con más frecuencia que validators cuyo único trabajo es descargar un bloquear y dar fe de que pudieron descargarlo. pueden ser rotan con más frecuencia porque no necesitan descargar el estado completo del fragmento, a diferencia de los validators que no se pueden rotar con frecuencia ya que debe descargar el estado del fragmento cada vez que gira, como se muestra en la figura 13. El problema con este enfoque ingenuo es que es imposible demostrar más tarde si el Notario pudo o no descargar el bloque, por lo que un Notario pueden optar por dar fe siempre de que pudieron descargar el bloque sin incluso intentar recuperarlo. Una solución a esto es que los notarios proporcionen alguna evidencia o apostar alguna cantidad de tokens que acrediten que el bloque fue descargado. Una de esas soluciones se analiza aquí: https://ethresear.ch/t/ Bonos de custodia de 1 bit amigables con la agregación/2236. 2.5.2 Códigos de borrado Cuando un nodo de luz en particular recibe un hash de un bloque, para aumentar el valor del nodo Si está seguro de que el bloque está disponible, puede intentar descargar algunos archivos aleatorios. pedazos del bloque. Esta no es una solución completa, ya que a menos que los nodos de luz descargar colectivamente el bloque completo que los productores de bloques maliciosos pueden elegir
Figura 13: Los validadores necesitan descargar el estado y, por lo tanto, no se pueden rotar. frecuentemente retener las partes del bloque que no fueron descargadas por ningún nodo ligero, por lo que el bloque aún no está disponible. Una solución es utilizar una construcción llamada Códigos de borrado para que sea posible para recuperar el bloque completo incluso si solo una parte del bloque está disponible, como se muestra en la figura 14. Figura 14: Merkle tree construido sobre datos codificados de borrado Tanto Polkadot como Ethereum Serenity tienen diseños en torno a esta idea que Proporcionar una manera para que los nodos ligeros estén razonablemente seguros de que los bloques están disponibles. El enfoque Ethereum Serenity tiene una descripción detallada en [2].2.5.3 El enfoque de Polkadot respecto de la disponibilidad de datos En Polkadot, como en la mayoría de las soluciones fragmentadas, cada fragmento (llamado parachain) envía instantáneas de sus bloques a la cadena de baliza (llamada cadena de retransmisión). Digamos que hay 2f + 1 validators en la cadena de relés. Los productores de bloques de los bloques parachain, llamados Alzadores, una vez que se produce el bloque parachain, calcule una versión codificada de borrado del bloque que consta de 2f +1 partes, de modo que cualquier f partes sea suficiente. para reconstruir el bloque. Luego distribuyen una parte a cada validator en el cadena de relevo. Una cadena de retransmisión particular validator solo firmaría en una cadena de retransmisión bloque si tienen su parte para cada bloque de parachain que se captura en dicho bloque de cadena de relés. Por lo tanto, si un bloque de cadena de retransmisión tiene firmas de 2f + 1 validators, y mientras no más de f de ellos violen el protocolo, cada El bloque parachain se puede reconstruir obteniendo las piezas de validators. que siguen el protocolo. Ver figura 15. Figura 15: Disponibilidad de datos de Polkadot 2.5.4 Disponibilidad de datos a largo plazo Tenga en cuenta que todos los enfoques discutidos anteriormente solo dan fe del hecho de que un bloque se publicó y ya está disponible. Los bloques pueden dejar de estar disponibles más adelante por una variedad de razones: nodos que se desconectan, nodos que borran intencionalmente datos históricos datos, y otros. Un documento técnico que vale la pena mencionar y que aborda este problema es Polyshard [3], que utiliza códigos de borrado para hacer que los bloques estén disponibles en todos los fragmentos, incluso si hay varios Los fragmentos pierden completamente sus datos. Desafortunadamente, su enfoque específico requiere todos los fragmentos para descargar bloques de todos los demás fragmentos, lo cual es prohibitivamente caro. La disponibilidad a largo plazo no es un problema tan urgente: dado que ningún participante Se espera que el sistema sea capaz de validar todas las cadenas en todos los
fragmentos, la seguridad del protocolo fragmentado debe diseñarse de tal manera manera que el sistema sea seguro incluso si algunos bloques antiguos en algunos fragmentos se vuelven completamente no disponible.
Statusgültigkeit und Datenverfügbarkeit
Die Kernidee bei Sharded blockchains ist, dass die meisten Teilnehmer, die bzw Durch die Nutzung des Netzwerks können Blöcke in allen Shards nicht validiert werden. Also wann immer Jeder Teilnehmer muss mit einem bestimmten Shard interagieren, was ihm im Allgemeinen nicht möglich ist Laden Sie den gesamten Verlauf des Shards herunter und validieren Sie ihn. Der Partitionierungsaspekt des Shardings birgt jedoch ein erhebliches Potenzial Problem: ohne den gesamten Verlauf einer bestimmten Datei herunterzuladen und zu validieren Shard Der Teilnehmer kann nicht unbedingt sicher sein, dass der Staat mit dem 5Dieser Abschnitt, mit Ausnahme von Unterabschnitt 2.5.3, wurde zuvor unter https://near.ai/ veröffentlicht. shard2. Wenn Sie es schon einmal gelesen haben, fahren Sie mit dem nächsten Abschnitt fort.
Ihre Interaktion ist das Ergebnis einer gültigen Folge von Blöcken und dieser Folge der Blöcke ist tatsächlich die kanonische Kette im Shard. Ein Problem, das nicht der Fall ist existieren in einem nicht fragmentierten blockchain. Wir werden zunächst eine einfache Lösung für dieses vorgeschlagene Problem vorstellen durch viele Protokolle und analysieren Sie dann, wie diese Lösung kaputt gehen kann und was Es wurden Versuche unternommen, das Problem anzugehen. 2.1 Rotation der Validatoren Die naive Lösung zur Staatsgültigkeit ist in Abbildung 5 dargestellt: Nehmen wir an, wir nehmen an dass das gesamte System in der Größenordnung von Tausenden validators hat, davon nicht mehr als 20 % sind böswillig oder werden auf andere Weise scheitern (z. B. indem sie es nicht tun). online, um einen Block zu erstellen). Wenn wir dann 200 validators abtasten, ist die Wahrscheinlichkeit von mehr als 1 3 Aus praktischen Gründen kann davon ausgegangen werden, dass der Wert null ist. Abbildung 5: Probenahme validators 1 3 ist ein wichtiger Schwellenwert. Es gibt eine Familie von Konsensprotokollen, genannt BFT Konsensprotokolle, die dies für weniger als 1 garantieren 3 von Teilnehmer scheitern, entweder durch einen Absturz oder durch ein Verhalten, das gegen die Regeln verstößt Protokoll wird der Konsens erzielt. Mit dieser Annahme ehrlicher validator Prozent, wenn der aktuelle Satz von Die naive Lösung geht davon aus, dass validators in einem Shard uns einen Block geben dass der Block gültig ist und dass er auf dem aufbaut, was die validators glaubten die kanonische Kette für diesen Shard, als sie mit der Validierung begannen. Die validators lernte die kanonische Kette aus dem vorherigen Satz von validators, die von demselben Annahme, die auf dem Block aufgebaut ist, der der Kopf der kanonischen Kette war davor. Durch Induktion ist die gesamte Kette gültig, und da keine Menge von validators An jedem Punkt, an dem Gabeln hergestellt werden, ist die naive Lösung auch sicher, dass der Strom vorhanden ist Kette ist die einzige Kette im Shard. Eine Visualisierung finden Sie in Abbildung 6.
Abbildung 6: Ein blockchain, bei dem jeder Block über einen BFT-Konsens abgeschlossen wird Diese einfache Lösung funktioniert nicht, wenn wir davon ausgehen, dass die validators möglich sind adaptiv korrumpiert, was keine unvernünftige Annahme ist6. Adaptiv Die Beschädigung eines einzelnen Shards in einem System mit 1000 Shards ist deutlich günstiger als das gesamte System zu beschädigen. Daher nimmt die Sicherheit des Protokolls linear mit der Anzahl der Shards ab. Um Gewissheit über die Gültigkeit zu haben Um einen Block zu erstellen, müssen wir wissen, dass es zu keinem Zeitpunkt in der Geschichte einen Shard im System gibt eine Mehrheit der validators konspiriert; Mit adaptiven Gegnern haben wir das nicht mehr solche Gewissheit. Wie wir in Abschnitt 1.5 besprochen haben, können konspirative validators Ausübung ausüben zwei grundlegende böswillige Verhaltensweisen: Forks erstellen und ungültige Blöcke erzeugen. Schädliche Forks können dadurch bekämpft werden, dass Blöcke mit der Beacon-Kette vernetzt werden, die im Allgemeinen für eine deutlich höhere Sicherheit ausgelegt ist die Scherbenketten. Das Erzeugen ungültiger Blöcke ist jedoch ein wesentlich größerer Aufwand herausforderndes Problem, das es zu bewältigen gilt. 2.2 Staatliche Gültigkeit Betrachten Sie Abbildung 7, in der Shard Nr. 1 beschädigt ist und ein böswilliger Akteur produziert ungültiger Block B. Angenommen, in diesem Block B wurden 1000 tokens aus dem Nichts geprägt Luft auf Alices Konto. Der böswillige Akteur erstellt dann einen gültigen Block C (in a (das Gefühl, dass die Transaktionen in C korrekt angewendet werden) auf B, was verschleiert den ungültigen Block B und initiiert eine Shard-übergreifende Transaktion zu Shard Nr. 2 überweist diese 1000 tokens auf Bobs Konto. Von diesem Moment an ist das falsch Die erstellten tokens befinden sich auf einem ansonsten vollständig gültigen blockchain in Shard Nr. 2. Einige einfache Ansätze zur Lösung dieses Problems sind: 6Lesen dies Artikel für Details auf wie adaptiv Korruption kann sein getragen aus: https://medium.com/nearprotocol/d859adb464c8. Für mehr Details auf adaptiv Korruption, lesen https://github.com/ethereum/wiki/wiki/Sharding-FAQ# Was sind die Sicherheitsmodelle, nach denen wir arbeiten?Abbildung 7: Eine Shard-übergreifende Transaktion aus einer Kette, die einen ungültigen Block hat 1. Für validators von Shard Nr. 2, um den Block zu validieren, von dem aus die Transaktion erfolgt wird eingeleitet. Dies wird auch im obigen Beispiel nicht funktionieren, da Block C scheint völlig gültig zu sein. 2. Damit validators in Shard Nr. 2 eine große Anzahl von Blöcken vor dem Block validieren, von dem aus die Transaktion initiiert wird. Natürlich, z Eine beliebige Anzahl von Blöcken N wird vom empfangenden Shard des Böswilligen validiert validators können N+1 gültige Blöcke zusätzlich zu dem ungültigen Block erstellen, den sie verwenden produziert. Eine vielversprechende Idee zur Lösung dieses Problems wäre die Anordnung von Shards in einer ungerichteter Graph, in dem jeder Shard mit mehreren anderen Shards verbunden ist, und Lassen Sie nur Cross-Shard-Transaktionen zwischen benachbarten Shards zu (z. B. so geht's). Das Sharding von Vlad Zamfir funktioniert im Wesentlichen7, und eine ähnliche Idee wird bei Kadena verwendet Chainweb [1]). Wenn eine Shard-übergreifende Transaktion zwischen Shards erforderlich ist keine Nachbarn, eine solche Transaktion wird über mehrere Shards geleitet. In diesem Design Es wird erwartet, dass ein validator in jedem Shard alle Blöcke in seinem Shard validiert sowie alle Blöcke in allen benachbarten Shards. Betrachten Sie die folgende Abbildung mit 10 Shards, von denen jeder vier Nachbarn hat und keine zwei Shards, die mehr erfordern mehr als zwei Hops für eine Shard-übergreifende Kommunikation, wie in Abbildung 8 dargestellt. Shard Nr. 2 validiert nicht nur seine eigene blockchain, sondern auch blockchains von alle Nachbarn, einschließlich Shard #1. Wenn es sich also um einen böswilligen Akteur auf Shard Nr. 1 handelt versucht, einen ungültigen Block B zu erstellen und dann Block C darauf aufzubauen und eine Cross-Shard-Transaktion initiieren, eine solche Cross-Shard-Transaktion wird nicht durchgeführt durch, da Shard Nr. 2 die gesamte Geschichte von Shard Nr. 1 validiert hat führt dazu, dass der ungültige Block B identifiziert wird. 7Lesen Sie hier mehr über das Design: https://medium.com/nearprotocol/37e538177ed9
Abbildung 8: Eine ungültige Cross-Shard-Transaktion in einem Chainweb-ähnlichen System entdeckt werden Während das Korrumpieren eines einzelnen Shards kein brauchbarer Angriff mehr ist, ist das Korrumpieren eines Shards kein brauchbarer Angriff mehr Wenig Scherben bleiben ein Problem. In Abbildung 9 korrumpiert ein Gegner beide Shards
1 und Shard #2 führen erfolgreich eine Cross-Shard-Transaktion zu Shard #3 aus
mit Mitteln aus einem ungültigen Block B: Abbildung 9: Eine ungültige Cross-Shard-Transaktion in einem Chainweb-ähnlichen System nicht erkannt werden Shard Nr. 3 validiert alle Blöcke in Shard Nr. 2, jedoch nicht in Shard Nr. 1, und hat keine Möglichkeit, den bösartigen Block zu erkennen. Es gibt zwei Hauptrichtungen zur ordnungsgemäßen Lösung der Staatsvalidität: Fischer
und kryptografische Rechennachweise. 2.3 Fischer Die Idee hinter dem ersten Ansatz ist die folgende: Immer wenn ein Blockheader angezeigt wird wird zwischen Ketten zu irgendeinem Zweck kommuniziert (z. B. zur Vernetzung mit dem B. einer Beacon-Kette oder einer Cross-Shard-Transaktion), gibt es einen Zeitraum während womit jeder ehrliche validator einen Beweis dafür liefern kann, dass der Block ungültig ist. Da Es gibt verschiedene Konstruktionen, die sehr prägnante Beweise dafür ermöglichen, dass es sich um Blöcke handelt ungültig, sodass der Kommunikationsaufwand für die empfangenden Knoten viel geringer ist als das Erhalten eines vollständigen Blocks. Mit diesem Ansatz, solange es mindestens einen ehrlichen validator in der Shard, das System ist sicher. Abbildung 10: Fischer Dies ist der vorherrschende Ansatz (neben der Behauptung, dass das Problem nicht existiert) unter den heute vorgeschlagenen Protokollen. Dieser Ansatz hat jedoch zwei Hauptnachteile: 1. Der Herausforderungszeitraum muss für den ehrlichen validator ausreichend lang sein Um zu erkennen, dass ein Block erstellt wurde, laden Sie ihn herunter, überprüfen Sie ihn vollständig und bereiten Sie ihn vor die Challenge, wenn der Block ungültig ist. Die Einführung eines solchen Zeitraums würde verlangsamen die Cross-Shard-Transaktionen erheblich. 2. Die Existenz des Challenge-Protokolls schafft einen neuen Angriffsvektor wenn bösartige Knoten mit ungültigen Herausforderungen spammen. Eine naheliegende Lösung Dieses Problem besteht darin, die Herausforderer dazu zu bringen, einen bestimmten Betrag an tokens einzuzahlen werden zurückgegeben, wenn die Challenge gültig ist. Dies ist nur eine Teillösung, wie es heißt könnte für den Angreifer immer noch von Vorteil sein, das System zu spammen (und zu verbrennen). der Einlagen) mit ungültigen Anfechtungen, beispielsweise zur Verhinderung der gültigenHerausforderung von einem ehrlichen validator vom Durchgehen. Diese Angriffe sind sogenannte Trauerattacken. Eine Möglichkeit, den letztgenannten Punkt zu umgehen, finden Sie in Abschnitt 3.7.2. 2.4 Prägnante, nicht interaktive Wissensargumente Die zweite Lösung für die Beschädigung mehrerer Shards besteht darin, kryptografische Konstruktionen zu verwenden, mit denen man beweisen kann, dass eine bestimmte Berechnung (z. B (z. B. die Berechnung eines Blocks aus einer Reihe von Transaktionen) wurde korrekt durchgeführt. Es gibt solche Konstruktionen, z.B. zk-SNARKs, zk-STARKs und einige andere, und einige werden heute aktiv in blockchain-Protokollen für private Zahlungen verwendet, vor allem ZCash. Das Hauptproblem bei solchen Grundelementen besteht darin, dass sie sind notorisch langsam zu berechnen. Z.B. Coda-Protokoll, das zk-SNARKs verwendet Insbesondere um zu beweisen, dass alle Blöcke in blockchain gültig sind, in einem Aus den Interviews geht hervor, dass die Erstellung eines Beweises 30 Sekunden pro Transaktion dauern kann (Diese Zahl ist wahrscheinlich mittlerweile kleiner). Interessanterweise muss ein Beweis nicht von einer vertrauenswürdigen Partei berechnet werden Der Beweis bescheinigt nicht nur die Gültigkeit der Berechnung, für die er erstellt wurde, sondern auch die Gültigkeit des Beweises selbst. Daher kann die Berechnung solcher Beweise aufgeteilt werden unter einer Gruppe von Teilnehmern mit deutlich geringerer Redundanz, als es der Fall wäre notwendig, um eine vertrauenswürdige Berechnung durchzuführen. Es ermöglicht auch Teilnehmern die zk-SNARKs berechnen, um auf spezieller Hardware zu laufen, ohne die zu reduzieren Dezentralisierung des Systems. Die Herausforderungen von zk-SNARKs sind neben der Leistung: 1. Abhängigkeit von weniger erforschten und weniger bewährten kryptografischen Grundelementen; 2. „Giftiger Abfall“ – zk-SNARKs sind auf ein vertrauenswürdiges Setup angewiesen, in dem eine Gruppe vorhanden ist der Leute führt eine Berechnung durch und verwirft dann das Zwischenprodukt Werte dieser Berechnung. Wenn alle Verfahrensbeteiligten Absprachen treffen und die Zwischenwerte beibehalten, können gefälschte Beweise erstellt werden; 3. Zusätzliche Komplexität im Systemdesign; 4. zk-SNARKs funktionieren nur für eine Teilmenge möglicher Berechnungen, also ein Protokoll mit einer Turing-vollständigen smart contract-Sprache wäre dies nicht möglich SNARKs zum Beweis der Gültigkeit der Kette. 2.5 Datenverfügbarkeit Das zweite Problem, das wir ansprechen werden, ist die Datenverfügbarkeit. Im Allgemeinen Knoten Betrieb eines bestimmten blockchain sind in zwei Gruppen unterteilt: Vollständige Knoten, diejenigen, die jeden vollständigen Block herunterladen und jede Transaktion validieren, und Light Knoten, die nur Blockheader herunterladen und Merkle-Proofs für Teile verwenden des Zustands und der Transaktionen, an denen sie interessiert sind, wie in Abbildung 11 dargestellt.
Abbildung 11: Merkle-Baum Wenn nun die Mehrheit der vollständigen Knoten zusammenarbeitet, können sie einen Block erzeugen, gültig oder ungültig, und senden Sie seine hash an die Lichtknoten, geben Sie jedoch niemals den vollständigen Inhalt preis des Blocks. Es gibt verschiedene Möglichkeiten, wie sie davon profitieren können. Zum Beispiel, Betrachten Sie Abbildung 12: Abbildung 12: Problem mit der Datenverfügbarkeit Es gibt drei Blöcke: Der vorherige, A, wird von ehrlichen validators erzeugt; der Strom, B, hat validators, die konspirieren; und das nächste, C, wird ebenfalls produziert von ehrlichen validators (der blockchain ist in der unteren rechten Ecke abgebildet). Sie sind ein Händler. Die validators des aktuellen Blocks (B) empfangenen Blocks Ein aus den vorherigen validators berechneter Block, in dem Sie Geld erhalten,und habe Ihnen einen Header dieses Blocks mit einem Merkle-Beweis für den Zustand geschickt, in dem er sich befindet Sie haben Geld (oder einen Merkle-Nachweis einer gültigen Transaktion, die das Geld sendet). für dich). Im Vertrauen darauf, dass die Transaktion abgeschlossen ist, erbringen Sie den Service. Allerdings verteilen die validators niemals den gesamten Inhalt des Blocks B an irgendjemand. Daher können die ehrlichen validators von Block C den Block nicht abrufen, und sind entweder gezwungen, das System zum Stillstand zu bringen oder auf A aufzubauen, wodurch Sie als a benachteiligt werden Geldhändler. Wenn wir das gleiche Szenario auf Sharding anwenden, ergeben sich die Definitionen von vollständig und Light-Knoten gelten im Allgemeinen pro Shard: validators in jedem Shard-Download alle Blockieren Sie diesen Shard und validieren Sie jede Transaktion in diesem Shard, außer anderen Knoten im System, einschließlich derjenigen, die Snapshot-Shard-Ketten in den Status aufnehmen Beacon-Kette, laden Sie nur die Header herunter. So lauten die validators im Shard effektiv vollständige Knoten für diesen Shard, während andere Teilnehmer im System, einschließlich der Beacon-Kette, fungieren als Lichtknoten. Damit der oben besprochene Fisherman-Ansatz funktioniert, sind ehrliche validators erforderlich Sie müssen in der Lage sein, Blöcke herunterzuladen, die mit der Beacon-Kette vernetzt sind. Wenn böswillige validators einen Header eines ungültigen Blocks vernetzten (oder ihn dazu nutzten). eine Cross-Shard-Transaktion initiieren), aber niemals den Block verteilen, das ehrlich validators haben keine Möglichkeit, eine Herausforderung zu gestalten. Wir werden drei Ansätze zur Lösung dieses Problems behandeln, die sich ergänzen einander. 2.5.1 Sorgerechtsnachweise Das unmittelbarste zu lösende Problem ist, ob ein Block einmal verfügbar ist es wird veröffentlicht. Eine vorgeschlagene Idee besteht darin, so genannte Notare einzusetzen, die rotieren zwischen Shards häufiger als validators, deren einzige Aufgabe darin besteht, a herunterzuladen blockieren und bestätigen, dass sie es herunterladen konnten. Das können sie sein häufiger rotiert, da nicht der gesamte Bundesstaat heruntergeladen werden muss des Shards, im Gegensatz zu den validators, die seitdem nicht häufig rotiert werden können Sie müssen bei jeder Drehung den Status des Shards herunterladen, wie in der Abbildung dargestellt 13. Das Problem bei diesem naiven Ansatz ist, dass es unmöglich ist, ihn später zu beweisen ob der Notar den Block herunterladen konnte oder nicht, also ein Notar können sich dafür entscheiden, immer zu bestätigen, dass sie den Block auch ohne herunterladen konnten sogar versucht, es wiederzubekommen. Eine Lösung hierfür ist die Bereitstellung durch Notare einige Beweise oder eine gewisse Menge an tokens einzusetzen, die belegen, dass der Block vorhanden war heruntergeladen. Eine solche Lösung wird hier diskutiert: https://ethresear.ch/t/ 1-bit-aggregation-freundliche-custody-bonds/2236. 2.5.2 Löschcodes Wenn ein bestimmter Lichtknoten einen hash eines Blocks empfängt, um den Knoten zu erhöhen Wenn Sie sicher sind, dass der Block verfügbar ist, können Sie versuchen, einige zufällige herunterzuladen Stücke des Blocks. Dies ist keine vollständige Lösung, da es sich nicht um die Lichtknoten handelt Laden Sie gemeinsam den gesamten Block herunter, den die böswilligen Blockproduzenten auswählen können
Abbildung 13: Validatoren müssen den Status herunterladen und können daher nicht rotiert werden häufig um die Teile des Blocks zurückzuhalten, die von keinem Lichtknoten heruntergeladen wurden, Dadurch ist der Block immer noch nicht verfügbar. Eine Lösung besteht darin, eine Konstruktion namens Erasure Codes zu verwenden, um dies zu ermöglichen um den gesamten Block wiederherzustellen, auch wenn nur ein Teil des Blocks verfügbar ist, wie gezeigt auf Abbildung 14. Abbildung 14: Merkle tree basiert auf löschcodierten Daten Sowohl Polkadot als auch Ethereum Serenity haben Designs rund um diese Idee Bieten Sie Lichtknoten die Möglichkeit, einigermaßen sicher zu sein, dass die Blöcke verfügbar sind. Eine ausführliche Beschreibung des Ethereum Serenity-Ansatzes finden Sie in [2].2.5.3 Polkadots Ansatz zur Datenverfügbarkeit In Polkadot erstellt, wie in den meisten Shard-Lösungen, jeder Shard (Parachain genannt) einen Snapshot seiner Blöcke in der Beacon-Kette (Relay-Kette genannt). Angenommen, es gibt 2f + 1 validators in der Relaiskette. Die Blockproduzenten der Parachain-Blöcke, genannt Collatoren berechnen nach der Erstellung des Parachain-Blocks eine löschcodierte Version des Blocks, die aus 2f +1 Teilen besteht, sodass alle f-Teile ausreichen um den Block zu rekonstruieren. Anschließend verteilen sie einen Teil an jeden validator auf der Relaiskette. Eine bestimmte Relay-Kette validator würde sich nur an einer Relay-Kette anmelden Block, wenn sie ihren Teil für jeden Parachain-Block haben, auf den ein Snapshot erstellt wird ein solcher Relaiskettenblock. Wenn also ein Relay-Chain-Block Signaturen von 2f + 1 hat validators und solange jeweils nicht mehr als f von ihnen gegen das Protokoll verstoßen haben Der Parachain-Block kann durch Abrufen der Teile aus den validators rekonstruiert werden die dem Protokoll folgen. Siehe Abbildung 15. Abbildung 15: Datenverfügbarkeit von Polkadot 2.5.4 Langfristige Datenverfügbarkeit Beachten Sie, dass alle oben diskutierten Ansätze nur die Tatsache bestätigen, dass ein Block vorliegt wurde überhaupt veröffentlicht und ist jetzt verfügbar. Blöcke können später nicht mehr verfügbar sein Aus verschiedenen Gründen: Knoten gehen offline, Knoten löschen absichtlich historische Daten Daten und andere. Ein erwähnenswertes Whitepaper, das sich mit diesem Problem befasst, ist Polyshard [3], das Löschcodes verwendet, um Blöcke über Shards hinweg verfügbar zu machen, auch wenn es mehrere sind Shards verlieren ihre Daten vollständig. Leider erfordert ihr spezifischer Ansatz Alle Shards, um Blöcke von allen anderen Shards herunterzuladen, was unerschwinglich ist teuer. Die langfristige Verfügbarkeit ist kein so dringendes Problem: da kein Teilnehmer Es wird erwartet, dass das System in der Lage ist, alle Ketten in allen zu validieren
Shards, die Sicherheit des Shard-Protokolls muss so gestaltet sein So ist das System sicher, auch wenn einige alte Blöcke in einigen Shards beschädigt werden völlig nicht verfügbar.
Nightshade
3.1 De cadenas de fragmentos a fragmentos de fragmentos El modelo de fragmentación con cadenas de fragmentos y una cadena de balizas es muy poderoso pero tiene ciertas complejidades. En particular, es necesario ejecutar la regla de elección de la bifurcación. en cada cadena por separado, la regla de elección de bifurcación en las cadenas de fragmentos y la baliza La cadena debe construirse de manera diferente y probarse por separado. En Nightshade modelamos el sistema como un único blockchain, en el que cada El bloque contiene lógicamente todas las transacciones para todos los fragmentos y cambia el Estado completo de todos los fragmentos. Físicamente, sin embargo, ningún participante descarga el estado completo o el bloque lógico completo. En cambio, cada participante de la red sólo mantiene el estado que corresponde a los fragmentos para los que validan las transacciones, y la lista de todas las transacciones en el bloque se divide en físicas trozos, un trozo por fragmento. En condiciones ideales, cada bloque contiene exactamente un fragmento por fragmento por bloque, que corresponde aproximadamente al modelo con cadenas de fragmentos en el que el Las cadenas de fragmentos producen bloques con la misma velocidad que la cadena de baliza. Sin embargo, Debido a retrasos en la red, es posible que falten algunos fragmentos, por lo que en la práctica cada bloque contiene uno o cero fragmentos por fragmento. Consulte la sección 3.3 para obtener detalles sobre cómo Se producen bloques. Figura 16: Un modelo con cadenas de fragmentos a la izquierda y con una cadena que tiene bloques divididos en trozos a la derecha
3.2 Consenso Los dos enfoques dominantes para el consenso en la década de blockchains hoy son el cadena más larga (o más pesada), en la que la cadena que tiene más trabajo o participación utilizado para construirlo se considera canónico, y BFT, en el que para cada bloque algunos un conjunto de validator alcanzan un consenso BFT. En los protocolos propuestos recientemente, este último es el enfoque más dominante, ya que proporciona una finalidad inmediata, mientras que en la cadena más larga se necesitan más bloques. que se construirá encima del bloque para asegurar la finalidad. A menudo para un significado seguridad: el tiempo que lleva construir un número suficiente de bloques supone el orden de horas. Usar el consenso BFT en cada bloque también tiene desventajas, tales como: 1. El consenso BFT implica una cantidad considerable de comunicación. mientras Los avances recientes permiten alcanzar el consenso en tiempo lineal en número. de los participantes (ver, por ejemplo, [4]), todavía se nota una sobrecarga por bloque; 2. Es inviable que todos los participantes de la red participen en el BFT consenso por bloque, por lo que normalmente sólo un subconjunto de participantes muestreados aleatoriamente alcanza el consenso. Un conjunto muestreado aleatoriamente puede ser, en principio, se corrompe adaptativamente y, en teoría, se puede crear una bifurcación. el sistema cualquiera de los dos necesita ser modelado para estar listo para tal evento y, por lo tanto, aún tener una regla de elección de bifurcación además del consenso BFT, o estar diseñado para cerrar abajo en tal evento. Cabe mencionar que algunos diseños, como Algorand [5], reducen significativamente la probabilidad de corrupción adaptativa. 3. Lo más importante es que el sistema se detiene si 1 3 o más de todos los participantes son fuera de línea. Por lo tanto, cualquier falla temporal de la red o una división de la red puede detener completamente el sistema. Idealmente, el sistema debe poder continuar operar mientras al menos la mitad de los participantes estén en línea (la mayoría Los protocolos basados en cadena continúan funcionando incluso si menos de la mitad de los participantes están en línea, pero la conveniencia de esta propiedad es más discutible. dentro de la comunidad). Un modelo híbrido en el que el consenso utilizado es el más pesado La cadena, pero algunos bloques se finalizan periódicamente utilizando un dispositivo de finalidad BFT mantienen las ventajas de ambos modelos. Estos dispositivos de finalidad BFT son Casper FFG [6] usado en Ethereum 2.0 8, Casper CBC (ver https://vitalik. ca/general/2018/12/05/cbc_casper.html) y ABUELO (ver https:// medium.com/polkadot-network/d08a24a021b5) utilizado en Polkadot. Nightshade utiliza el consenso de cadena más pesado. Específicamente cuando un bloque productor produce un bloque (ver sección 3.3), puede recolectar firmas de otros productores de bloques y validators que acrediten el bloque anterior. Ver sección 3.8 para obtener detalles sobre cómo se agrega una cantidad tan grande de firmas. el peso 8Vea también la sesión de pizarra con Justin Drake para obtener una descripción detallada de Casper. FFG y cómo se integra con el consenso de la cadena más pesada de GHOST aquí: https://www. youtube.com/watch?v=S262StTwkmode un bloque es entonces la participación acumulada de todos los firmantes cuyas firmas son incluido en el bloque. El peso de una cadena es la suma de los pesos de los bloques. Además del consenso de cadena más pesado, utilizamos un dispositivo de finalidad que utiliza las certificaciones para finalizar los bloques. Para reducir la complejidad del sistema, utilizamos un dispositivo de finalidad que no influye de ninguna manera en la regla de elección de la bifurcación, y en su lugar sólo introduce condiciones de corte adicionales, de modo que una vez que un bloque es finalizado por el dispositivo de finalidad, una bifurcación es imposible a menos que un porcentaje muy grande del total de la apuesta se reduce drásticamente. Casper CBC es un dispositivo de finalidad, y Actualmente modela con Casper CBC en mente. También trabajamos en un protocolo BFT separado llamado TxFlow. En el momento de Al escribir este documento no está claro si se utilizará TxFlow en lugar de Casper. CBC. Sin embargo, observamos que la elección del dispositivo final es en gran medida ortogonal al resto del diseño. 3.3 producción de bloques En Nightshade hay dos roles: productores de bloques y validators. en cualquier punto el sistema contiene w productores de bloques, w = 100 en nuestros modelos, y wv validators, en nuestro modelo v = 100, wv = 10, 000. El sistema es Prueba de participación, lo que significa que tanto los productores de bloques como los validators tienen algún número de moneda (denominada "tokens") bloqueada por un período de tiempo que excede con creces el tiempo que dedican a realizar sus tareas de construcción y validación de la cadena. Como ocurre con todos los sistemas de Prueba de participación, no todos los productores de bloques w y no todos los wv validators son entidades diferentes, ya que eso no se puede hacer cumplir. cada uno de los productores de bloques w y los wv validators, sin embargo, tienen una estaca. El sistema contiene n fragmentos, n = 1000 en nuestro modelo. Como se menciona en sección 3.1, en Nightshade no hay cadenas de fragmentos; en cambio, todos los productores de bloques y validator están construyendo un único blockchain, al que nos referimos como cadena principal. El estado de la cadena principal se divide en n fragmentos y cada bloque productor y validator en cualquier momento solo han descargado localmente un subconjunto de el estado que corresponde a algún subconjunto de los fragmentos, y solo el proceso y validar transacciones que afecten a esas partes del estado. Para convertirse en productor de bloques, un participante de la red bloquea algunos grandes cantidad de tokens (una participación). El mantenimiento de la red se realiza en épocas, donde una época es un período de tiempo del orden de días. Los participantes con lo que está en juego más al comienzo de una época particular es el bloque productores de esa época. Cada productor de bloques se asigna a fragmentos sw (digamos sw = 40, lo que haría sww/n = 4 productores de bloques por fragmento). el bloque El productor descarga el estado del fragmento al que están asignados antes de la época. comienza, y a lo largo de la época recopila transacciones que afectan ese fragmento, y los aplica al Estado. Para cada bloque b en la cadena principal, y para cada fragmento s, hay uno de los productores de bloques asignados a s, quien es responsable de producir la parte de b relacionada al fragmento. La parte de b relacionada con el fragmento s se llama fragmento y contiene el lista de las transacciones para que el fragmento se incluya en b, así como el merkleraíz del estado resultante. b en última instancia sólo contendrá un encabezado muy pequeño de el fragmento, es decir, la raíz merkle de todas las transacciones aplicadas (consulte la sección 3.7.1 para detalles exactos), y la raíz merkle del estado final. A lo largo del resto del documento, a menudo nos referimos al productor de bloques. que es responsable de producir un fragmento en un momento particular para un fragmento en particular como productor de trozos. El productor de fragmentos es siempre uno de los productores de bloques. Los productores de bloques y los productores de trozos rotan cada bloque según a un horario fijo. Los productores de bloques tienen un pedido y producen repetidamente. bloques en ese orden. P.ej. Si hay 100 productores de bloques, el primer bloque Los productores son responsables de producir los bloques 1, 101, 201, etc., el segundo es responsable de producir 2, 102, 202, etc.). Dado que la producción de trozos, a diferencia de la producción de bloques, requiere mantener el estado, y para cada fragmento solo los productores de bloques sww/n mantienen el estado por fragmento, en consecuencia, solo los productores de bloques sww/n rotan para crear trozos. P.ej. con las constantes anteriores con cuatro productores de bloques asignados a En cada fragmento, cada productor de bloques creará fragmentos una vez cada cuatro bloques. 3.4 Garantizar la disponibilidad de datos Para garantizar la disponibilidad de datos utilizamos un enfoque similar al de Polkadot descrito en la sección 2.5.3. Una vez que un productor de bloques produce un fragmento, crea una versión codificada de borrado con un código de bloque óptimo (w, ⌊w/6 + 1⌋) del trozo. Luego envían una parte del fragmento codificado de borrado (a esas partes las llamamos partes de fragmentos, o solo partes) a cada productor de bloques. Calculamos un árbol merkle que contiene todas las partes como las hojas, y el El encabezado de cada fragmento contiene la raíz merkle de dicho árbol. Las piezas se envían a los validators mediante mensajes onepart. Cada uno de esos mensajes contiene el encabezado del fragmento, el ordinal de la parte y el contenido de la parte. el El mensaje también contiene la firma del productor del bloque que produjo el chunk y la ruta merkle para demostrar que la parte corresponde al encabezado y es producido por el productor de bloques adecuado. Una vez que un productor de bloques recibe un bloque de la cadena principal, primero verifica si tenga mensajes de una parte para cada fragmento incluido en el bloque. Si no, el bloque no se procesa hasta que se recuperan los mensajes de una parte que faltan. Una vez que se reciben todos los mensajes de una parte, el productor del bloque recupera el partes restantes de los pares y reconstruye los fragmentos que mantienen el estado. El productor de bloques no procesa un bloque de la cadena principal si es por al menos un fragmento incluido en el bloque no tienen el mensaje de una parte correspondiente, o si al menos para un fragmento para el cual mantienen el estado no pueden reconstruir todo el trozo. Para que un fragmento en particular esté disponible es suficiente que ⌊w/6⌋+1 del bloque los productores tienen sus partes y les sirven. Así, mientras el número de Los actores maliciosos no superan ⌊w/3⌋ninguna cadena que tenga más de medio bloque. los productores que lo construyen pueden tener fragmentos no disponibles.Figura 17: Cada bloque contiene uno o cero fragmentos por fragmento, y cada fragmento tiene un código de borrado. Cada parte del fragmento codificado de borrado se envía a un lugar designado productor de bloques a través de un mensaje especial de una parte 3.4.1 Tratar con productores de bloques perezosos Si un productor de bloques tiene un bloque al que le falta un mensaje de una parte, podría optar por firmar aún así, porque si el bloque termina en la cadena, maximizará la recompensa para el productor del bloque. No hay riesgo para el bloque. productor ya que es imposible probar posteriormente que el productor del bloque no tenía el mensaje de una parte. Para solucionarlo, hacemos que cada fragmento sea productor al crear el fragmento para elija un color (rojo o azul) para cada parte del futuro fragmento codificado y guárdelo la máscara de bits del color asignado en el fragmento antes de codificarlo. cada una de las partes El mensaje contiene el color asignado a la pieza y el color se utiliza cuando calcular la raíz merkle de las partes codificadas. Si el productor del trozo se desvía del protocolo, se puede probar fácilmente, ya que la raíz de merkle no corresponden a mensajes de una parte, o los colores en los mensajes de una parte que corresponden a la raíz de merkle no coincidirán con la máscara en el fragmento. Cuando un productor de bloques firma en un bloque, incluye una máscara de bits de todos los piezas rojas que recibieron por los trozos incluidos en el bloque. Publicar un la máscara de bits incorrecta es un comportamiento que se puede recortar. Si un productor de bloques no ha recibido un mensaje de una parte, no tienen forma de saber el color del mensaje, y Por lo tanto, tienen un 50% de posibilidades de ser eliminados si intentan firmar a ciegas el bloque. 3.5 Solicitud de transición de estado Los productores de fragmentos sólo eligen qué transacciones incluir en el fragmento, pero no aplique la transición de estado cuando produzcan un fragmento. En consecuencia,
el encabezado del fragmento contiene la raíz merkle del estado merkelizado como antes se aplican las transacciones en el fragmento. Las transacciones solo se aplican cuando un bloque completo que incluye el fragmento se procesa. Un participante solo procesa un bloque si 1. El bloque anterior fue recibido y procesado; 2. Para cada fragmento, el participante no mantiene el estado que tiene. visto el mensaje de una parte; 3. Para cada fragmento, el participante mantiene el estado porque tiene el trozo completo. Una vez que se procesa el bloque, para cada fragmento para el cual el participante mantiene el estado, aplican las transacciones y calculan el nuevo estado a partir de que se aplican las transacciones, después de lo cual están listas para producir los fragmentos para el siguiente bloque, si están asignados a algún fragmento, ya que tienen la raíz merkle del nuevo estado merkelizado. 3.6 Transacciones y recibos entre fragmentos Si una transacción necesita afectar a más de un fragmento, debe realizarse consecutivamente. ejecutado en cada fragmento por separado. La transacción completa se envía al primer fragmento. afectado, y una vez que la transacción se incluye en el fragmento de dicho fragmento, y se aplica después de que el fragmento se incluye en un bloque, genera el llamado recibo transacción, que se enruta al siguiente fragmento en el que la transacción debe ser ejecutado. Si se requieren más pasos, la ejecución de la transacción de recibo genera una nueva transacción de recibo y así sucesivamente. 3.6.1 Duración de la transacción del recibo Es deseable que la transacción de recibo se aplique en el bloque que sigue inmediatamente al bloque en el que se generó. La transacción del recibo es sólo generado después de que el bloque anterior fue recibido y aplicado por los productores de bloques que mantienen el fragmento de origen, y debe ser conocido en el momento en que El fragmento para el siguiente bloque es producido por los productores de bloques del destino. fragmento. Por lo tanto, el recibo debe comunicarse desde el fragmento de origen al fragmento de destino en el corto período de tiempo entre esos dos eventos. Sea A el último bloque producido que contiene una transacción t que genera un recibo r. Sea B el siguiente bloque producido (es decir, un bloque que tiene A como su bloque anterior) que queremos contener r. Sea t estar en el fragmento a y r en el fragmento b. La vida útil del recibo, también representada en la figura 18, es la siguiente: Elaborar y almacenar los recibos. El cpa del productor de fragmentos para fragmentos a recibe el bloque A, aplica la transacción t y genera el recibo r. cpa luego almacena todos los recibos producidos en su almacenamiento interno persistente indexado por la identificación del fragmento de origen.Distribuyendo los recibos. Una vez que cpa esté listo para producir el fragmento para fragmento a para el bloque B, obtienen todos los recibos generados al aplicar las transacciones del bloque A para el fragmento a y los incluyen en el fragmento para shrad a en el bloque B. Una vez que se genera dicho fragmento, cpa produce su borrado codificado versión y todos los mensajes onepart correspondientes. cpa sabe qué productores de bloques mantienen el estado completo para qué fragmentos. Para un productor de bloques en particular pb cpa incluye los ingresos que resultaron de aplicar las transacciones del bloque A para el fragmento a que tiene como destino cualquiera de los fragmentos que le interesan a bp en el mensaje de una parte cuando distribuyeron el fragmento para el fragmento a en el bloque B (consulte la figura 17, que muestra los recibos incluidos en el mensaje de una parte). Recibir los recibos. Recuerde que los participantes (tanto productores de bloques como validators) no procesan bloques hasta que tengan mensajes de una parte. para cada fragmento incluido en el bloque. Por lo tanto, cuando un participante en particular aplica el bloque B, tiene todos los mensajes de una parte que corresponden a fragmentos en B, y por lo tanto tienen todos los recibos entrantes que tienen los fragmentos el participante mantiene el estado como destino. Al aplicar el transición de estado para un fragmento en particular, el participante aplica ambos recibos que han recopilado para el fragmento en los mensajes de una parte, así como todos las transacciones incluidas en el propio fragmento. Figura 18: La vida útil de una transacción de recibo 3.6.2 Manejar demasiados recibos Es posible que el número de recibos dirigidos a un fragmento concreto en un bloque en particular es demasiado grande para ser procesado. Por ejemplo, considere la figura 19, en en el que cada transacción en cada fragmento genera un recibo dirigido al fragmento 1. En el siguiente bloque, la cantidad de recibos que el fragmento 1 debe procesar es comparable a la carga que todos los fragmentos combinados procesaron mientras se manipulaban el bloque anterior.
Figura 19: Si todos los recibos apuntan al mismo fragmento, es posible que el fragmento no tenga la capacidad de procesarlos Para solucionarlo utilizamos una técnica similar a la utilizada en QuarkChain 9. Específicamente, para cada fragmento, el último bloque B y el último fragmento dentro de ese Se registra el bloque desde el cual se aplicaron los recibos. Cuando el nuevo fragmento esté creado, los recibos se aplican en orden primero a partir de los fragmentos restantes en B, y luego en bloques que siguen a B, hasta que el nuevo fragmento esté lleno. En condiciones normales circunstancias con una carga equilibrada, generalmente resultará en todos los recibos que se está aplicando (y por lo tanto, el último fragmento del último bloque se registrará para cada trozo), pero durante los momentos en que la carga no está equilibrada, y un particular Shard recibe una cantidad desproporcionada de recibos, esta técnica les permite procesarse respetando los límites en el número de transacciones incluidas. Tenga en cuenta que si dicha carga desequilibrada permanece durante mucho tiempo, el retraso desde la creación del recibo hasta que la aplicación pueda seguir creciendo indefinidamente. uno forma de abordarlo es descartar cualquier transacción que genere un recibo dirigido a un fragmento que tiene un retraso de procesamiento que excede alguna constante (por ejemplo, una época). Considere la figura 20. En el bloque B, el fragmento 4 no puede procesar todos los recibos, por lo que solo procesa el origen de los recibos desde hasta el fragmento 3 en el bloque A, y lo registra. En el bloque C se incluyen los recibos hasta el fragmento 5 del bloque B, y luego, en el bloque D, el fragmento se pone al día y procesa todos los recibos restantes en bloque B y todos los recibos del bloque C. 3.7 Validación de fragmentos Un fragmento producido para un fragmento en particular (o un bloque de fragmentos producido para una cadena de fragmentos particular en el modelo con cadenas de fragmentos) solo puede ser validado por el 9Vea el episodio de la pizarra con QuarkChain aquí: https://www.youtube.com/watch? v=opEtG6NM4x4, en el que se analiza el enfoque de las transacciones entre fragmentos, entre otros cosasFigura 20: Procesamiento de recibos retrasados participantes que mantienen el estado. Pueden ser productores de bloques, validators, o simplemente testigos externos que descargaron el estado y validaron el fragmento en donde almacenan activos. En este documento asumimos que la mayoría de los participantes no pueden almacenar al Estado una gran parte de los fragmentos. Vale la pena mencionar, sin embargo, que hay blockchains fragmentados que están diseñados con la suposición de que la mayoría de los participantes tienen capacidad para almacenar el estado y validar la mayoría de los fragmentos, como QuarkChain. Dado que solo una fracción de los participantes tiene el estado para validar el fragmento fragmentos, es posible corromper adaptativamente solo a los participantes que tienen la estado y aplicar una transición de estado no válida. Se propusieron múltiples diseños de fragmentación que muestrean validators cada pocos días, y dentro de un día cualquier bloque en la cadena de fragmentos que tenga más de 2/3 de firmas de los validator asignados a dicho fragmento se considera inmediatamente final. Con tal enfoque un adversario adaptativo sólo necesita corromper 2n/3+1 de los validators en una cadena de fragmentos para aplicar una transición de estado no válida, que, Aunque probablemente sea difícil de lograr, no es un nivel de seguridad suficiente para un público. blockchain. Como se analizó en la sección 2.3, el enfoque común es permitir una cierta ventana de tiempo después de que se crea un bloque para cualquier participante que tenga estado (ya sea es un productor de bloques, un validator o un observador externo) para cuestionar su validez. Estos participantes se llaman pescadores. Para que un pescador pueda impugnar un bloque no válido, se debe garantizar que dicho bloque esté disponible para ellos. La disponibilidad de datos en Nightshade se analiza en la sección 3.4. En Nightshade, una vez que se produce un bloque, los fragmentos no fueron validados por cualquiera excepto el productor de fragmentos real. En particular, el productor de bloques que sugirió que el bloque naturalmente no tenía el estado para la mayoría de los fragmentos, yno pudo validar los fragmentos. Cuando se produce el siguiente bloque, contiene certificaciones (consulte la sección 3.2) de múltiples productores de bloques y validators, pero dado que la mayoría de los productores de bloques y validators no mantienen el estado Además, para la mayoría de los fragmentos, un bloque con solo un fragmento no válido recopilará significativamente más de la mitad de las certificaciones y seguirá estando en la lista más pesada. cadena. Para abordar este problema, permitimos que cualquier participante que mantenga el estado de un fragmento para presentar un desafío en la cadena por cualquier fragmento no válido producido en ese fragmento. 3.7.1 Desafío de validez estatal Una vez que un participante detecta que un fragmento en particular no es válido, debe proporcionar una prueba de que el fragmento no es válido. Dado que la mayoría de los participantes de la red no mantienen el estado del fragmento en el que se encuentra el fragmento no válido producida, la prueba debe tener suficiente información para confirmar que el bloque es inválido sin tener el estado. Establecemos un límite Ls de la cantidad de estado (en bytes) que una sola transacción Puede leer o escribir de forma acumulativa. Cualquier transacción que toque más de Ls. El estado se considera inválido. Recuerde de la sección 3.5 que el trozo en un bloque particular B sólo contiene las transacciones a aplicar, pero no la nueva raíz estatal. La raíz del estado incluida en el fragmento del bloque B es el estado root antes de aplicar dichas transacciones, pero después de aplicar las transacciones de el último fragmento en el mismo fragmento antes del bloque B. Un actor malicioso que desea aplicar una transición de estado no válida incluiría una raíz de estado incorrecta en el bloque B que no corresponde al estado raíz que resulta de aplicar las transacciones en el fragmento anterior. Ampliamos la información que un productor de fragmentos incluye en el fragmento. En lugar de simplemente incluir el estado después de aplicar todas las transacciones, en su lugar incluye una raíz de estado después de aplicar cada conjunto contiguo de transacciones que leer y escribir colectivamente Ls bytes de estado. Con esta información para el pescador para crear un desafío que una transición de estado se aplica incorrectamente es suficiente encontrar la primera raíz de estado no válida e incluir solo Ls bytes de estado que se ven afectados por las transacciones entre la última raíz del estado (que fue válido) y la raíz del estado actual con las pruebas de merkle. Entonces cualquier participante puede validar las transacciones en el segmento y confirmar que el fragmento es inválido. De manera similar, si el productor del fragmento intentara incluir transacciones que leyeran y escribir más de Ls bytes de estado, para el desafío basta con incluir los primeros Ls bytes que toca con las pruebas merkle, que serán suficientes para aplicar las transacciones y confirmar que hay un momento en el que se intenta Se realiza lectura o escritura de contenido más allá de Ls bytes.
3.7.2 Pescadores y transacciones rápidas entre fragmentos. Como se analizó en la sección 2.3, una vez que asumimos que los fragmentos (o fragmentos) bloques en el modelo con cadenas de fragmentos) pueden no ser válidos e introducir un desafío período, afecta negativamente la finalidad y, por lo tanto, la comunicación entre fragmentos. en En particular, el fragmento de destino de cualquier transacción entre fragmentos no puede estar seguro el fragmento o bloque de origen es definitivo hasta que finaliza el período de desafío (ver figura 21). Figura 21: Esperar el período de impugnación antes de aplicar un recibo La forma de abordarlo de manera que se realicen transacciones entre fragmentos. instantáneo es que el fragmento de destino no espere el período de desafío después de que se publique la transacción del fragmento de origen y aplique la transacción del recibo inmediatamente, pero luego revertir el fragmento de destino junto con el origen fragmento si más tarde se descubre que el fragmento o bloque original no es válido (consulte la figura 22). Esto se aplica de forma muy natural al diseño Nightshade en el que el fragmento Las cadenas no son independientes, sino que todos los fragmentos se publican. juntos en el mismo bloque de cadena principal. Si se determina que algún fragmento no es válido, el todo el bloque con ese fragmento se considera inválido y todos los bloques construidos en él encima. Ver figura 23. Ambos enfoques anteriores proporcionan atomicidad suponiendo que el desafío el período es lo suficientemente largo. Usamos el último enfoque, ya que proporcionar transacciones rápidas entre fragmentos en circunstancias normales supera los inconvenientes de el fragmento de destino retrocede debido a una transición de estado no válida en uno de los fragmentos de origen, lo cual es un evento extremadamente raro. 3.7.3 Ocultar validators La existencia de los desafíos ya reduce significativamente la probabilidad de corrupción adaptativa, ya que para finalizar una parte con un estado de transición inválidoFigura 22: Aplicar recibos inmediatamente y revertir el destino cadena si la cadena fuente tenía un bloque no válido Figura 23: Desafío del pescador en Nightshade El período de desafío el adversario adaptativo necesita corromper a todos los participantes. que mantienen el estado del fragmento, incluidos todos los validator. Estimar la probabilidad de que ocurra tal evento es extremadamente complejo, ya que no sharded blockchain ha estado activo el tiempo suficiente para intentar cualquier ataque de este tipo. Sostenemos que la probabilidad, aunque extremadamente baja, sigue siendo suficientemente grande para un sistema que se espera que ejecute transacciones multimillonarias y ejecutar operaciones financieras a nivel mundial. Hay dos razones principales para esta creencia: 1. La mayoría de los validators de las cadenas de Prueba de Participación y mineros del
Las cadenas de prueba de trabajo están incentivadas principalmente por las ventajas financieras. si un adversario adaptativo les ofrece más dinero que el retorno esperado de operar honestamente, es razonable esperar que muchos validators aceptará la oferta. 2. Muchas entidades validan las cadenas de prueba de participación de manera profesional, y Se espera que un gran porcentaje de la participación en cualquier cadena sea de dichas entidades. El número de tales entidades es lo suficientemente pequeño para una adversario adaptativo para conocer a la mayoría de ellos personalmente y tener una buena comprensión de su inclinación a corromperse. Damos un paso más para reducir la probabilidad de corrupción adaptativa al ocultar qué validator están asignados a cada fragmento. La idea es remotamente similar a la forma en que Algorand [5] oculta validators. Es fundamental tener en cuenta que incluso si los validator están ocultos, como en Algorand o como se describe a continuación, la corrupción adaptativa todavía es posible en teoría. mientras El adversario adaptativo no conoce a los participantes que crearán o validarán. un bloque o un trozo, los propios participantes saben que realizarán tal tarea y tener una prueba criptográfica de ello. Así, el adversario puede difundir su intención de corromper y pagar a cualquier participante que proporcione tal prueba criptográfica. Sin embargo, observamos que dado que el adversario no conocen los validator que están asignados al fragmento que quieren corromper, no tienen otra opción que transmitir su intención de corromper un fragmento en particular a toda la comunidad. En ese punto es económicamente benéfico para cualquier persona honesta. participante para activar un nodo completo que valide ese fragmento, ya que hay un alto posibilidad de que aparezca un bloque no válido en ese fragmento, lo cual es una oportunidad para crea un desafío y recolecta la recompensa asociada. Para no revelar los validators que están asignados a un fragmento en particular, hacemos lo siguiente (ver figura 24): Usando VRF para obtener la tarea. Al comienzo de cada época cada validator usa un VRF para obtener una máscara de bits de los fragmentos a los que está asignado validator. La máscara de bits de cada validator tendrá bits Sw (consulte la sección 3.3 para conocer la definición de SW). Luego, el validator recupera el estado de los fragmentos correspondientes y durante la época para cada bloque recibido valida los fragmentos que corresponden a los fragmentos a los que está asignado el validator. Regístrate en bloques en lugar de trozos. Dado que la asignación de fragmentos está oculta, validator no puede firmar fragmentos. En cambio, siempre firma en todo el bloque, por lo que no revela qué fragmentos valida. Específicamente, cuando validator recibe un bloque y valida todos los fragmentos, crea un mensaje que atestigua que todos los fragmentos en todos los fragmentos a los que está asignado el validator son válido (sin indicar de ninguna manera cuáles son esos fragmentos), o un mensaje que contiene una prueba de una transición de estado no válida si algún fragmento no es válido. Ver el sección 3.8 para obtener detalles sobre cómo se agregan dichos mensajes, sección 3.7.4 para los detalles sobre cómo evitar que validators se aprovechen de los mensajes de otros validators, y la sección 3.7.5 para obtener detalles sobre cómo recompensar y castigar validators en caso de que realmente se produzca una impugnación exitosa de una transición de estado no válida.Figura 24: Ocultando los validators en Nightshade 3.7.4 Comprometerse-Revelar Uno de los problemas comunes con validators es que un validator puede omitir la descarga del estado y validar los fragmentos y bloques, y en su lugar observar la red, ver lo que envían los otros validators y repetir sus mensajes. Un validator que sigue dicha estrategia no proporciona ningún beneficio adicional. seguridad para la red, pero recoge recompensas. Una solución común para este problema es que cada validator proporcione una prueba que realmente validaron el bloque, por ejemplo proporcionando un seguimiento único de aplicar la transición estatal, pero tales pruebas aumentan significativamente el costo de validación. Figura 25: comprometerse-revelar
En su lugar, hacemos que los validators se comprometan por primera vez con el resultado de la validación (ya sea el mensaje que da fe de la validez de los fragmentos, o la prueba de una invalidez transición de estado), espere un cierto período y solo entonces revele el resultado de validación real, como se muestra en la figura 25. El período de confirmación no se cruza con el período de revelación y, por lo tanto, un validator perezoso no puede imitar a los validators honestos. Además, si un validator deshonesto se comprometió con un mensaje que da fe de la validez de los fragmentos asignados, y al menos un fragmento no era válido, una vez que se demostrado que el fragmento no es válido, validator no puede evitar la reducción, ya que, Como mostramos en la sección 3.7.5, la única manera de no ser cortado en tal situación es presentar un mensaje que contiene una prueba de la transición de estado no válida que coincide con el compromiso. 3.7.5 Manejando desafíos Como se analizó anteriormente, una vez que un validator recibe un bloque con un fragmento no válido, Primero preparan una prueba de la transición de estado no válida (ver sección 3.7.1), luego comprometerse con dicha prueba (ver 3.7.4) y después de un período revelar el desafío. Una vez incluido el desafío revelado en un bloque, sucede lo siguiente: 1. Todas las transiciones de estado que ocurrieron desde el bloque que contiene el fragmento no válido hasta que se obtenga el bloque en el que se incluye el desafío revelado. anulado. El estado ante el bloque que incluye el desafío revelado se considera el mismo que el estado anterior al bloque que contenía el trozo inválido. 2. Dentro de un cierto período de tiempo cada validator debe revelar su máscara de bits de los fragmentos que validan. Dado que la máscara de bits se crea a través de un VRF, si fueron asignados al fragmento que tenía la transición de estado no válida, No puedo evitar revelarlo. Cualquier validator que no revele la máscara de bits se supone que está asignado al fragmento. 3. Cada validator que después de dicho período se encuentre asignado al fragmento, que se comprometió con algún resultado de validación para el bloque que contiene el fragmento inválido y que no reveló la prueba de transición de estado inválido que corresponde a su compromiso se reduce. 4. Cada validator recibe una nueva asignación de fragmentos y se programa una nueva época. para comenzar después de un tiempo suficiente para que todos los validators descarguen el estado, como se muestra en la figura 26. Tenga en cuenta que desde el momento en que los validator revelan los fragmentos que se les asignan hasta que comienza la nueva época, la seguridad del sistema se reduce desde el Se revela la asignación de fragmentos. Los participantes de la red deben mantenerlo. en mente al utilizar la red durante dicho período. 3.8 Agregación de firmas Para que un sistema con cientos de fragmentos funcione de forma segura, queremos tener en el orden de 10, 000 o más validators. Como se discutió en la sección 3.7, queremos que cadaFigura 26: Manejando el desafío validator para publicar un compromiso con un determinado mensaje y una firma en promedio una vez por bloque. Incluso si los mensajes de confirmación fueran los mismos, agregar tal La firma BLS y su validación habrían sido prohibitivamente costosas. pero naturalmente, los mensajes de confirmación y revelación no son los mismos en validators, y por lo tanto necesitamos alguna forma de agregar dichos mensajes y las firmas en un forma que permita una validación rápida posterior. El enfoque específico que utilizamos es el siguiente: Validadores que se unen a productores de bloques. Los productores de bloques son conocidos. algún tiempo antes de que comience la época, ya que necesitan algo de tiempo para descargar el estado antes de que comience la época y, a diferencia de los validators, los productores de bloques son no oculto. Cada productor de bloques tiene v validator ranuras. Los validadores envían propuestas fuera de la cadena a los productores de bloques para ser incluidos como uno de sus v validators. Si un productor de bloques desea incluir un validator, envía un transacción que contiene la solicitud inicial fuera de la cadena del validator, y el firma del productor del bloque que hace que validator se una al productor del bloque. Tenga en cuenta que los validators asignados a los productores de bloques no necesariamente valide los mismos fragmentos para los que el productor de bloques produce fragmentos. si un validator se aplicó para unir múltiples productores de bloques, solo la transacción de el primer productor de bloques tendrá éxito. Los productores de bloques recopilan compromisos. El productor de bloques recopila constantemente los mensajes de confirmación y revelación de los validator. Una vez que se acumula una cierta cantidad de dichos mensajes, el productor del bloque calcula un merkle árbol de estos mensajes, y envía a cada validator la raíz de merkle y el camino merkle a su mensaje. El validator valida el camino y se registra la raíz de merkle. Luego, el productor del bloque acumula una firma BLS en el raíz de merkle de validators, y publica solo la raíz de merkle y el firma acumulada. El productor del bloque también firma sobre la validez del firma múltiple utilizando una firma ECDSA barata. Si la firma múltiple no coincide con la raíz de merkle enviada o la máscara de bits de los validators participantes, es un comportamiento que se puede recortar. Al sincronizar la cadena, un participante puede optar por validar todas las firmas BLS de validators (lo cual es extremadamente costoso ya que implica agregar las claves públicas de validators), o sololas firmas ECDMA de los productores de bloques y se basan en el hecho de que el El productor de bloques no fue cuestionado ni recortado. Uso de transacciones en cadena y pruebas merkle para desafíos. eso Se puede observar que no tiene ningún valor revelar mensajes de validators si no Se detectó una transición de estado no válida. Sólo los mensajes que contienen la información real Es necesario revelar pruebas de una transición de estado inválida, y sólo para tales mensajes. es necesario demostrar que coinciden con el compromiso anterior. El mensaje necesita ser revelado con dos propósitos: 1. Para iniciar realmente la reversión de la cadena al momento anterior al transición de estado no válida (ver sección 3.7.5). 2. Para demostrar que el validator no intentó dar fe de la validez del trozo no válido. En cualquier caso debemos abordar dos cuestiones: 1. El compromiso real no se incluyó en la cadena, solo la raíz merkle del confirmar agregado con otros mensajes. El validator necesita utilizar el ruta merkle proporcionada por el productor del bloque y su compromiso original con demostrar que se comprometieron con el desafío. 2. Es posible que todos los validator asignados al fragmento con el valor no válido La transición de estado se asigna a productores de bloques corruptos que los están censurando. Para evitarlo, les permitimos enviar sus revelaciones. como una transacción regular en cadena y evitar la agregación. Esto último sólo se permite para las pruebas de transición de estado inválida, que son extremadamente raro y, por lo tanto, no debería generar spam en los bloques. La última cuestión que debe abordarse es que los productores de bloques pueden optar por no participar en la agregación de mensajes o censurar intencionalmente validators concretos. Lo hacemos económicamente desventajoso al hacer que el bloque Recompensa al productor proporcional al número de validators que se les asignen. nosotros También tenga en cuenta que dado que los productores de bloques entre épocas se cruzan en gran medida (ya que siempre son los primeros w participantes con la apuesta más alta), los validators pueden atenerse en gran medida a trabajar con los mismos productores de bloques, y así reducir el riesgo de ser asignados a un productor de bloques que los censuró en el pasado. 3.9 Cadena de instantáneas Dado que los bloques de la cadena principal se producen con mucha frecuencia, descargar el historial completo podría resultar caro muy rápidamente. Es más, dado que cada El bloque contiene una firma BLS de una gran cantidad de participantes, solo la agregación de las claves públicas para verificar la firma podría resultar prohibitiva. caro también. Finalmente, dado que en un futuro previsible Ethereum 1.0 probablemente seguirá siendo uno de los blockchains más utilizados, que tiene una forma significativa de transferir activos desde
Cerca de Ethereum es un requisito y hoy se verifican las firmas BLS para garantizar La validez de bloques cercanos en el lado de Ethereum no es posible. Cada bloque de la cadena principal de Nightshade puede contener opcionalmente un Schnorr firma múltiple en el encabezado del último bloque que incluía dicho Schnorr multifirma. A estos bloques los llamamos bloques instantáneos. El primer bloque de cada época debe ser un bloque de instantáneas. Mientras trabajaba en una firma múltiple de este tipo, los productores de bloques también deben acumular las firmas BLS de los validators en el último bloque de instantáneas y agréguelas de la misma manera que se describe en sección 3.8. Dado que el conjunto de productores de bloques es constante a lo largo de la época, validar sólo los primeros bloques de instantáneas en cada época son suficientes suponiendo que en ningún momento punto, un gran porcentaje de productores de bloques y validators se confabularon y crearon un tenedor. El primer bloque de la época debe contener información suficiente para calcular los productores de bloques y validators para la época. Llamamos a la subcadena de la cadena principal que solo contiene la instantánea. bloquea una cadena de instantáneas. Crear una firma múltiple de Schnorr es un proceso interactivo, pero como Sólo es necesario realizarlo con poca frecuencia, cualquier proceso, por ineficiente que sea, será suficiente. Las firmas múltiples de Schnorr se pueden validar fácilmente en Ethereum, proporcionando así primitivas cruciales para una forma segura de realizar cross-blockchain comunicación. Para sincronizar con la cadena Near solo es necesario descargar toda la instantánea. bloquea y confirma que las firmas Schnorr son correctas (opcionalmente, también verifica las firmas BLS individuales de los validators), y luego solo sincroniza bloques de la cadena principal desde el último bloque de instantánea.
Nightshade
3.1 Von Splitterketten bis hin zu Splitterbrocken Das Sharding-Modell mit Shard-Ketten und einer Beacon-Kette ist jedoch sehr leistungsfähig hat gewisse Komplexitäten. Insbesondere muss die Fork-Choice-Regel ausgeführt werden in jeder Kette separat, die Fork-Choice-Regel in den Shard-Ketten und das Beacon Die Kette muss unterschiedlich aufgebaut und separat getestet werden. In Nightshade modellieren wir das System als ein einzelnes blockchain, in dem jedes Der Block enthält logisch alle Transaktionen für alle Shards und ändert die Gesamtzustand aller Scherben. Physisch lädt jedoch kein Teilnehmer das herunter Vollständiger Zustand oder vollständiger logischer Block. Stattdessen nur jeder Teilnehmer des Netzwerks behält den Zustand bei, der den Shards entspricht, für die sie Transaktionen validieren, und die Liste aller Transaktionen im Block wird in physische Transaktionen aufgeteilt Chunks, ein Chunk pro Shard. Unter idealen Bedingungen enthält jeder Block genau einen Chunk pro Shard Block, der in etwa dem Modell mit Shard-Ketten entspricht, in dem die Shard-Ketten produzieren Blöcke mit der gleichen Geschwindigkeit wie die Beacon-Kette. Allerdings Aufgrund von Netzwerkverzögerungen könnten einige Chunks fehlen, also in der Praxis jeder Block enthält entweder einen oder keinen Chunk pro Shard. Einzelheiten dazu finden Sie in Abschnitt 3.3 Blöcke entstehen. Abbildung 16: Ein Modell mit Splitterketten auf der linken Seite und mit einer Kette auf der linken Seite Auf der rechten Seite sind die Blöcke in Stücke aufgeteilt
3.2 Konsens Die beiden vorherrschenden Konsensansätze in den blockchains sind heute die längste (oder schwerste) Kette, in der die Kette die meiste Arbeit oder den größten Anteil hat Es gilt als kanonisch, um es zu erstellen, und BFT, in dem für jeden Block einige Satz von validators erreichen einen BFT Konsens. In den kürzlich vorgeschlagenen Protokollen ist letzterer ein dominanterer Ansatz. da es sofortige Endgültigkeit bietet, während in der längsten Kette mehr Blöcke benötigt werden auf dem Block aufgebaut werden, um die Endgültigkeit zu gewährleisten. Oftmals für eine sinnvolle Sicherheit: Die Zeit, die benötigt wird, um eine ausreichende Anzahl von Blöcken zu erstellen, nimmt auf Reihenfolge der Stunden. Die Verwendung des BFT-Konsenses für jeden Block hat auch Nachteile, wie zum Beispiel: 1. BFT Konsens erfordert einen erheblichen Kommunikationsaufwand. Während Die jüngsten Fortschritte ermöglichen es, den Konsens in linearer Zeit in Zahlen zu erreichen der Teilnehmer (siehe z. B. [4]), ist der Overhead pro Block immer noch spürbar; 2. Es ist nicht möglich, dass alle Netzwerkteilnehmer am BFT teilnehmen. Konsens pro Block, daher erreicht normalerweise nur eine zufällig ausgewählte Teilmenge der Teilnehmer den Konsens. Eine zufällig ausgewählte Menge kann im Prinzip sein: adaptiv korrumpiert, und theoretisch kann eine Abzweigung erstellt werden. Das System Beides muss modelliert werden, um für ein solches Ereignis bereit zu sein, und somit still haben neben dem BFT-Konsens eine Fork-Choice-Regel oder sind so konzipiert, dass sie geschlossen werden in einem solchen Fall niedergeschlagen. Es ist erwähnenswert, dass einige Designs, wie z Algorand [5], reduzieren die Wahrscheinlichkeit einer adaptiven Korruption erheblich. 3. Am wichtigsten ist, dass das System blockiert, wenn 1 3 oder mehr aller Teilnehmer sind offline. Daher kann jeder vorübergehende Netzwerkfehler oder eine Netzwerkaufteilung das System vollständig zum Stillstand bringen. Im Idealfall muss das System weiterhin in der Lage sein funktionieren, solange mindestens die Hälfte der Teilnehmer online ist (am schwersten). Kettenbasierte Protokolle funktionieren auch dann weiter, wenn weniger als die Hälfte der Teilnehmer online ist, aber die Zweckmäßigkeit dieser Eigenschaft ist umstrittener innerhalb der Gemeinschaft). Ein Hybridmodell, bei dem der verwendete Konsens am stärksten ist Kette, aber einige Blöcke werden regelmäßig mit einem BFT Finalitäts-Gadget finalisiert, um die Vorteile beider Modelle beizubehalten. Solche BFT Endgültigkeits-Gadgets sind Casper FFG [6] verwendet in Ethereum 2.0 8, Casper CBC (siehe https://vitalik. ca/general/2018/12/05/cbc_casper.html) und GRANDPA (siehe https:// medium.com/polkadot-network/d08a24a021b5) verwendet in Polkadot. Nightshade verwendet den stärksten Kettenkonsens. Insbesondere wenn ein Block Der Produzent erzeugt einen Block (siehe Abschnitt 3.3), von dem er Signaturen sammeln kann andere Blockproduzenten und validators, die den vorherigen Block bestätigen. Siehe Abschnitt 3.8 für Einzelheiten, wie eine so große Anzahl von Signaturen aggregiert wird. Das Gewicht 8Sehen Sie sich auch die Whiteboard-Sitzung mit Justin Drake an, um einen detaillierten Überblick über Casper zu erhalten FFG und wie es in den GHOST-Konsens über die schwerste Kette integriert ist, finden Sie hier: https://www. youtube.com/watch?v=S262StTwkmoeines Blocks ist dann der kumulative Einsatz aller Unterzeichner, deren Unterschriften vorhanden sind im Block enthalten. Das Gewicht einer Kette ist die Summe der Blockgewichte. Zusätzlich zum schwersten Kettenkonsens verwenden wir ein Finalitäts-Gadget, das verwendet die Bescheinigungen zur Fertigstellung der Blöcke. Um die Komplexität des Systems zu reduzieren, Wir verwenden ein Finalitäts-Gadget, das die Fork-Choice-Regel in keiner Weise beeinflusst. und führt stattdessen nur zusätzliche Slashing-Bedingungen ein, so dass einmal ein Block vorhanden ist Durch das Finalitäts-Gadget finalisiert, ist eine Abzweigung unmöglich, es sei denn, es handelt sich um einen sehr großen Prozentsatz des Gesamteinsatzes wird gekürzt. Casper CBC ist so ein Endgültigkeits-Gadget, und wir derzeit Modell mit Blick auf Casper CBC. Wir arbeiten auch an einem separaten BFT-Protokoll namens TxFlow. Zur Zeit von Beim Schreiben dieses Dokuments ist unklar, ob TxFlow anstelle von Casper verwendet wird CBC. Wir stellen jedoch fest, dass die Wahl des Endgültigkeits-Gadgets weitgehend orthogonal zum Rest des Designs ist. 3.3 Blockproduktion In Nightshade gibt es zwei Rollen: Blockproduzenten und validators. Auf jeden Fall Punkt enthält das System w Blockproduzenten, w = 100 in unseren Modellen und wv validators, in unserem Modell v = 100, wv = 10.000. Das System ist Proof-of-Stake, Dies bedeutet, dass sowohl Blockproduzenten als auch validators über eine gewisse Anzahl interner verfügen Währung (bezeichnet als „tokens“) für einen Zeitraum gesperrt, der weit über den hinausgeht Zeit, die sie mit der Erfüllung ihrer Aufgaben zum Aufbau und zur Validierung der Kette verbringen. Wie bei allen Proof-of-Stake-Systemen sind nicht alle W-Blockproduzenten und nicht Alle wv validators sind unterschiedliche Entitäten, da dies nicht erzwungen werden kann. Jeder der w-Blockproduzenten und die wv validators haben jedoch eine separate Pfahl. Das System enthält n Shards, in unserem Modell ist n = 1000. Wie erwähnt in Abschnitt 3.1: In Nightshade gibt es keine Shard-Ketten, stattdessen erstellen alle Blockproduzenten und validators ein einziges blockchain, das wir als das bezeichnen Hauptkette. Der Zustand der Hauptkette ist in n Shards und jeden Block aufgeteilt Produzent und validator haben zu jedem Zeitpunkt nur eine Teilmenge von lokal heruntergeladen der Zustand, der einer Teilmenge der Shards entspricht, und nur verarbeiten und Validierung von Transaktionen, die diese Teile des Staates betreffen. Um ein Blockproduzent zu werden, sperrt ein Teilnehmer des Netzwerks einige große Blöcke Betrag von tokens (ein Einsatz). Die Wartung des Netzwerks erfolgt in Epochen, wobei eine Epoche ein Zeitraum in der Größenordnung von Tagen ist. Die Teilnehmer mit den w größten Einsätzen zu Beginn einer bestimmten Epoche sind der Block Produzenten für diese Epoche. Jedem Blockproduzenten sind SW-Shards zugewiesen (z. B sw = 40, was sww/n = 4 Blockproduzenten pro Shard ergeben würde. Der Block Der Produzent lädt den Status des Shards herunter, dem er vor der Epoche zugewiesen ist beginnt und sammelt im Laufe der Epoche Transaktionen, die sich auf diesen Shard auswirken. und wendet sie auf den Staat an. Für jeden Block b in der Hauptkette und für jeden Shard s gibt es einen davon s Blockproduzenten zugewiesen, die für die Produktion des Teils von b verantwortlich sind zur Scherbe. Der Teil von b, der sich auf Shard s bezieht, wird als Chunk bezeichnet und enthält die Liste der Transaktionen für den Shard, die in b aufgenommen werden sollen, sowie das MerkleWurzel des resultierenden Zustands. b wird letztendlich nur einen sehr kleinen Header von enthalten der Chunk, nämlich die Merkle-Wurzel aller angewendeten Transaktionen (siehe Abschnitt 3.7.1 für genaue Details) und die Merkle-Wurzel des Endzustands. Im weiteren Verlauf des Dokuments beziehen wir uns häufig auf den Blockproduzenten Das ist dafür verantwortlich, zu einem bestimmten Zeitpunkt einen Chunk für einen bestimmten Shard zu produzieren als Chunk-Produzent. Der Chunk-Produzent ist immer einer der Blockproduzenten. Die Blockproduzenten und die Chunk-Produzenten rotieren jeden Block entsprechend nach einem festen Zeitplan. Die Blockproduzenten haben einen Auftrag und produzieren wiederholt Blöcke in dieser Reihenfolge. Z.B. wenn es 100 Blockproduzenten gibt, der erste Block Der Hersteller ist für die Produktion der Blöcke 1, 101, 201 usw. verantwortlich, der zweite verantwortlich für die Produktion von 2, 102, 202 usw.). Da die Chunk-Produktion im Gegensatz zur Blockproduktion eine Wartung erfordert den Status, und für jeden Shard behalten nur sww/n-Blockproduzenten den Status bei Pro Shard rotieren dementsprechend nur die SWW/N-Blockproduzenten, um sie zu erstellen Brocken. Z.B. mit den oben genannten Konstanten mit vier zugewiesenen Blockproduzenten Jeder Shard und jeder Blockproduzent erstellt alle vier Blöcke einmal Chunks. 3.4 Sicherstellung der Datenverfügbarkeit Um die Datenverfügbarkeit sicherzustellen, verwenden wir einen ähnlichen Ansatz wie Polkadot beschrieben in Abschnitt 2.5.3. Sobald ein Blockproduzent einen Block produziert, erstellt er ihn eine löschcodierte Version davon mit einem optimalen (w, ⌊w/6 + 1⌋) Blockcode des Brocken. Anschließend senden sie einen Teil des löschcodierten Blocks (wir nennen solche Teile). Chunk-Teile oder nur Teile) an jeden Blockproduzenten. Wir berechnen einen Merkle-Baum, der alle Teile wie die Blätter und die enthält Der Header jedes Blocks enthält die Merkle-Wurzel dieses Baums. Die Teile werden über Onepart-Nachrichten an die validators gesendet. Jede solche Nachricht enthält den Chunk-Header, die Ordnungszahl des Teils und den Teilinhalt. Die Die Nachricht enthält auch die Signatur des Blockproduzenten, der sie erstellt hat Chunk und den Merkle-Pfad, um zu beweisen, dass der Teil dem Header entspricht und wird vom richtigen Blockproduzenten produziert. Sobald ein Blockproduzent einen Hauptkettenblock erhält, prüft er zunächst, ob dies der Fall ist Für jeden im Block enthaltenen Block gibt es einteilige Nachrichten. Wenn nicht, die Sperre wird erst verarbeitet, wenn die fehlenden Onepart-Nachrichten abgerufen wurden. Sobald alle einteiligen Nachrichten empfangen wurden, ruft der Blockproduzent die ab Die restlichen Teile werden von den Peers abgezogen und die Chunks rekonstruiert, die sie enthalten der Staat. Der Blockproduzent verarbeitet keinen Hauptkettenblock, wenn es sich um mindestens einen handelt Wenn ein im Block enthaltener Chunk nicht über die entsprechende Onepart-Nachricht verfügt, oder wenn für mindestens einen Shard, für den sie den Status aufrechterhalten, dies nicht der Fall ist den gesamten Block rekonstruieren. Damit ein bestimmter Block verfügbar ist, reicht es aus, dass ⌊w/6⌋+1 des Blocks Produzenten haben ihre Teile und bedienen sie. Also solange die Zahl der böswillige Akteure überschreiten nicht ⌊w/3⌋keine Kette, die mehr als einen halben Block hat Hersteller, die es bauen, können nicht verfügbare Teile haben.Abbildung 17: Jeder Block enthält einen oder keinen Chunk pro Shard und jeden Chunk ist löschcodiert. Jeder Teil des löschcodierten Blocks wird an eine bestimmte Adresse gesendet Blockproduzent über eine spezielle Onepart-Nachricht 3.4.1 Umgang mit faulen Blockproduzenten Wenn ein Blockproduzent einen Block hat, für den eine Onepart-Nachricht fehlt, wird er Vielleicht entscheiden Sie sich trotzdem dafür, ihn zu signieren, denn wenn der Block am Ende in der Kette landet, ist er es maximiert die Belohnung für den Blockproduzenten. Für den Block besteht kein Risiko Der Blockproduzent war nicht der einzige Blockproduzent, da es später unmöglich ist, zu beweisen, dass der Blockproduzent ihn nicht hatte die einteilige Nachricht. Um dies zu beheben, machen wir jeden Chunk zum Produzenten, wenn wir den Chunk erstellen Wählen Sie eine Farbe (Rot oder Blau) für jeden Teil des zukünftigen codierten Blocks und speichern Sie ihn die Bitmaske der zugewiesenen Farbe im Block, bevor er codiert wird. Jeweils ein Teil Die Nachricht enthält dann die dem Teil zugewiesene Farbe, und die Farbe wird verwendet, wenn Berechnen der Merkle-Wurzel der codierten Teile. Wenn der Chunk-Produzent abweicht Aus dem Protokoll lässt sich dies leicht beweisen, da dies bei der Merkle-Wurzel nicht der Fall ist entsprechen einteiligen Nachrichten oder den Farben in den einteiligen Nachrichten die der Merkle-Wurzel entsprechen, stimmt nicht mit der Maske im Block überein. Wenn ein Blockproduzent einen Block anmeldet, fügt er eine Bitmaske aller Blöcke hinzu rote Teile erhielten sie für die im Block enthaltenen Chunks. Veröffentlichung einer Eine falsche Bitmaske ist ein streichbares Verhalten. Wenn ein Blockproduzent keine erhalten hat Bei einer einzelnen Nachricht haben sie keine Möglichkeit, die Farbe der Nachricht zu kennen, und Daher besteht eine Wahrscheinlichkeit von 50 %, dass sie gekürzt werden, wenn sie versuchen, das Dokument blind zu unterschreiben blockieren. 3.5 Antrag auf Staatsübergang Die Chunk-Produzenten wählen lediglich aus, welche Transaktionen in den Chunk aufgenommen werden sollen Wenden Sie den Zustandsübergang nicht an, wenn sie einen Block erzeugen. Dementsprechend
Der Chunk-Header enthält die Merkle-Wurzel des merkelisierten Zustands wie zuvor Die Transaktionen im Block werden angewendet. Die Transaktionen werden nur angewendet, wenn ein vollständiger Block den Block enthält verarbeitet wird. Ein Teilnehmer bearbeitet einen Block nur, wenn 1. Der vorherige Block wurde empfangen und verarbeitet; 2. Für jeden Block behält der Teilnehmer nicht den Status bei, den er hat habe die einteilige Nachricht gesehen; 3. Für jeden Block behält der Teilnehmer den Status bei, den er hat volles Stück. Sobald der Block verarbeitet wird, für jeden Shard, für den der Teilnehmer zuständig ist behält den Zustand bei, wendet die Transaktionen an und berechnet den neuen Zustand ab dem Zeitpunkt, an dem die Transaktionen angewendet wurden, und sind danach zur Produktion bereit die Chunks für den nächsten Block, wenn sie einem Shard zugewiesen sind, da sie dies getan haben die Merkle-Wurzel des neuen merkelisierten Staates. 3.6 Shardübergreifende Transaktionen und Belege Wenn eine Transaktion mehr als einen Shard betreffen muss, muss sie nacheinander erfolgen wird in jedem Shard separat ausgeführt. Die vollständige Transaktion wird an den ersten Shard gesendet betroffen, und sobald die Transaktion im Chunk für diesen Shard enthalten ist, und Wird angewendet, nachdem der Block in einen Block eingefügt wurde, wird eine sogenannte Quittung generiert Transaktion, die an den nächsten Shard weitergeleitet wird, in dem die Transaktion ausgeführt werden muss ausgeführt werden. Wenn weitere Schritte erforderlich sind, erfolgt die Ausführung der Empfangstransaktion generiert eine neue Belegtransaktion und so weiter. 3.6.1 Lebensdauer der Quittungstransaktion Es ist wünschenswert, dass die Empfangstransaktion in dem Block angewendet wird, der unmittelbar auf den Block folgt, in dem sie generiert wurde. Die Quittungstransaktion ist nur generiert, nachdem der vorherige Block empfangen und von Blockproduzenten angewendet wurde die den ursprünglichen Shard verwalten und zum Zeitpunkt des bekannt sein müssen Der Block für den nächsten Block wird von den Blockproduzenten des Ziels erstellt Scherbe. Daher muss der Empfang vom Quell-Shard an den übermittelt werden Ziel-Shard in dem kurzen Zeitrahmen zwischen diesen beiden Ereignissen. Sei A der zuletzt produzierte Block, der eine Transaktion t enthält, die eine Quittung r generiert. Sei B der nächste produzierte Block (d. h. ein Block, der A als hat). sein vorheriger Block), den wir r enthalten wollen. Lass es in der Scherbe a und r sein in der Scherbe b. Die Lebensdauer des Belegs, ebenfalls in Abbildung 18 dargestellt, ist wie folgt: Erstellen und Aufbewahren der Belege. Der Chunk-Produzenten-CPA für Shard a empfängt den Block A, wendet die Transaktion t an und generiert die Quittung r. cpa Anschließend speichert es alle derart erstellten Belege in seinem indizierten internen persistenten Speicher nach der Quell-Shard-ID.Verteilen der Quittungen. Sobald CPA bereit ist, den Chunk zu produzieren Wenn Sie Shard a für Block B verwenden, rufen sie alle Belege ab, die durch die Anwendung der Transaktionen von Block A für Shard a generiert wurden, und fügen sie in den Block für Shrad ein a in Block B. Sobald ein solcher Block generiert ist, erzeugt cpa seinen Löschcode Version und alle zugehörigen Onepart-Nachrichten. cpa weiß, welche Blockproduzenten den vollständigen Status für welche Shards beibehalten. Für einen bestimmten Blockproduzenten bp cpa umfasst die Einnahmen, die aus der Anwendung von Transaktionen in Block A resultierten für Shard a, der einen der Shards hat, die bp als Ziel interessieren in der einteiligen Nachricht, als sie den Block für Shard a in Block B verteilten (siehe Abbildung 17, die die in der Onepart-Nachricht enthaltenen Quittungen zeigt). Erhalt der Quittungen. Denken Sie daran, dass die Teilnehmer (sowohl Blockproduzenten als auch validators) Blöcke erst verarbeiten, wenn sie einteilige Nachrichten haben für jeden im Block enthaltenen Block. Wenn also ein bestimmter Teilnehmer den Block B anwendet, verfügt er über alle entsprechenden Onepart-Nachrichten Chunks in B, und somit verfügen sie über alle eingehenden Belege, die die Shards enthalten Der Teilnehmer behält den Status als Ziel bei. Bei der Anwendung der Beim Zustandsübergang für einen bestimmten Shard wendet der Teilnehmer beide Quittungen an dass sie für den Shard in den Onepart-Nachrichten sowie allen gesammelt haben die im Chunk selbst enthaltenen Transaktionen. Abbildung 18: Die Lebensdauer einer Empfangstransaktion 3.6.2 Umgang mit zu vielen Belegen Es ist möglich, dass die Anzahl der Belege, die auf einen bestimmten Shard in einem abzielen Ein bestimmter Block ist zu groß, um verarbeitet zu werden. Betrachten Sie zum Beispiel Abbildung 19, in wobei jede Transaktion in jedem Shard eine Quittung generiert, die auf Shard 1 abzielt. Bis zum nächsten Block beträgt die Anzahl der Belege, die Shard 1 verarbeiten muss vergleichbar mit der Last, die alle Scherben zusammen während der Handhabung verarbeitet haben den vorherigen Block.
Abbildung 19: Wenn alle Belege auf denselben Shard abzielen, ist dies möglicherweise nicht der Fall die Fähigkeit, sie zu verarbeiten Um dieses Problem anzugehen, verwenden wir eine Technik, die der in QuarkChain 9 verwendeten ähnelt. Konkret gilt für jeden Shard der letzte Block B und der letzte Shard darin Es wird der Block erfasst, aus dem die Belege übernommen wurden. Wenn der neue Shard ist erstellt, die Quittung wird in der Reihenfolge zuerst aus den verbleibenden Shards in B angewendet, und dann in Blöcken, die auf B folgen, bis der neue Block voll ist. Unter normal Bei ausgeglichener Belastung kommt es in der Regel zu allen Einnahmen angewendet wird (und somit wird der letzte Shard des letzten Blocks aufgezeichnet jedes Stück), aber zu Zeiten, in denen die Last nicht ausgeglichen ist, und ein bestimmtes Da Shard überproportional viele Belege erhält, ist dies mit dieser Technik möglich unter Einhaltung der Beschränkungen für die Anzahl der enthaltenen Transaktionen verarbeitet werden. Beachten Sie, dass die Verzögerung abnimmt, wenn eine solche unausgeglichene Belastung über einen längeren Zeitraum anhält Die Belegerstellung bis zur Anwendung kann unbegrenzt weiter wachsen. Eins Eine Möglichkeit, das Problem zu lösen, besteht darin, jede Transaktion zu verwerfen, die eine Quittung für a erstellt Shard, dessen Verarbeitungsverzögerung eine bestimmte Konstante überschreitet (z. B. eine Epoche). Betrachten Sie Abbildung 20. Durch Block B kann der Shard 4 nicht alle Belege verarbeiten. es verarbeitet also nur Quittungsursprünge von bis zu Shard 3 in Block A und zeichnet es auf. In Block C sind die Belege bis Shard 5 in Block B enthalten, und Dann holt der Shard bei Block D auf und verarbeitet alle verbleibenden Belege Block B und alle Belege aus Block C. 3.7 Chunks-Validierung Ein für einen bestimmten Shard erstellter Chunk (oder ein für eine bestimmte Shard-Kette im Modell mit Shard-Ketten erstellter Shard-Block) kann nur von validiert werden 9Sehen Sie sich hier die Whiteboard-Folge mit QuarkChain an: https://www.youtube.com/watch? v=opEtG6NM4x4, in dem unter anderem der Ansatz für Cross-Shard-Transaktionen diskutiert wird DingeAbbildung 20: Verzögerte Belegverarbeitung Teilnehmer, die den Staat aufrechterhalten. Sie können Blockproduzenten sein, validators, oder nur externe Zeugen, die den Status heruntergeladen und den Shard darin validiert haben in dem sie Vermögenswerte speichern. In diesem Dokument gehen wir davon aus, dass die Mehrheit der Teilnehmer nicht speichern kann der Staat für einen großen Teil der Scherben. Es ist jedoch erwähnenswert, dass es Shard-blockchains gibt, die unter der Annahme entworfen wurden, dass Die meisten Teilnehmer verfügen über die Kapazität, den Zustand zu speichern und die meisten davon zu validieren die Shards, wie zum Beispiel QuarkChain. Da nur ein Bruchteil der Teilnehmer den Status hat, den Shard zu validieren Chunks ist es möglich, adaptiv nur die Teilnehmer zu korrumpieren, die das haben Zustand ändern und einen ungültigen Zustandsübergang anwenden. Es wurden mehrere Sharding-Designs vorgeschlagen, die alle paar validators abtasten Tage und innerhalb eines Tages jeder Block in der Shard-Kette, der mehr als 2/3 hat der diesem Shard zugewiesenen Signaturen der validators werden sofort berücksichtigt endgültig. Mit einem solchen Ansatz muss ein adaptiver Gegner nur 2n/3+1 korrumpieren der validators in einer Shard-Kette, um einen ungültigen Zustandsübergang anzuwenden, der, Auch wenn es wahrscheinlich schwer zu bewerkstelligen ist, ist das Sicherheitsniveau für die Öffentlichkeit nicht ausreichend blockchain. Wie in Abschnitt 2.3 besprochen, besteht der übliche Ansatz darin, nach der Erstellung eines Blocks für jeden Teilnehmer, der über den Status (ob) verfügt, ein bestimmtes Zeitfenster einzuräumen es ist ein Blockproduzent, ein validator oder ein externer Beobachter), um seine Gültigkeit in Frage zu stellen. Solche Teilnehmer werden Fischer genannt. Damit ein Fischer es kann Um einen ungültigen Block anzufechten, muss sichergestellt werden, dass ein solcher Block verfügbar ist sie. Die Datenverfügbarkeit in Nightshade wird in Abschnitt 3.4 erläutert. Sobald in Nightshade ein Block erstellt wurde, wurden die Chunks nicht validiert irgendjemand außer dem eigentlichen Chunk-Produzenten. Insbesondere der Blockproduzent schlug vor, dass der Block natürlich nicht den Status für die meisten Shards hatte, undkonnte die Chunks nicht validieren. Wenn der nächste Block produziert wird, enthält er Attestierungen (siehe Abschnitt 3.2) mehrerer Blockproduzenten und validators, aber da die Mehrheit der Blockproduzenten und validators den Status nicht aufrechterhalten Auch bei den meisten Shards sammelt ein Block mit nur einem ungültigen Chunk deutlich mehr als die Hälfte der Attestierungen und bleibt weiterhin am schwersten Kette. Um dieses Problem zu beheben, gestatten wir jedem Teilnehmer, den Status von beizubehalten Ein Shard, um in der Kette eine Herausforderung für jeden darin erzeugten ungültigen Chunk einzureichen Scherbe. 3.7.1 Staatliche Gültigkeitsherausforderung Sobald ein Teilnehmer feststellt, dass ein bestimmter Block ungültig ist, muss er einen Beweis dafür erbringen, dass der Block ungültig ist. Da die Mehrheit der Netzwerkteilnehmer den Zustand für den Shard, in dem sich der ungültige Chunk befindet, nicht aufrechterhalten Wenn der Beweis erstellt wird, muss er über ausreichende Informationen verfügen, um den Block zu bestätigen ungültig, ohne den Staat zu haben. Wir legen einen Grenzwert Ls für die Statusmenge (in Bytes) fest, die eine einzelne Transaktion umfasst kann kumulativ lesen oder schreiben. Jede Transaktion, die mehr als Ls berührt Zustand gilt als ungültig. Erinnern Sie sich aus Abschnitt 3.5 daran, dass der Chunk In einem bestimmten Block enthält B nur die anzuwendenden Transaktionen, jedoch nicht die neue Staatswurzel. Der im Block in Block B enthaltene Statusstamm ist der Status root, bevor Sie solche Transaktionen anwenden, aber nachdem Sie die Transaktionen angewendet haben der letzte Block im selben Shard vor dem Block B. Ein böswilliger Akteur Der Wunsch, einen ungültigen Zustandsübergang anzuwenden, würde einen falschen Zustandsstamm beinhalten in Block B entspricht das nicht der Zustandswurzel, die sich aus der Anwendung ergibt die Transaktionen im vorherigen Block. Wir erweitern die Informationen, die ein Chunk-Produzent in den Chunk einfügt. Anstatt nur den Status einzubeziehen, nachdem alle Transaktionen angewendet wurden, wird dieser stattdessen angezeigt Enthält eine Statuswurzel, nachdem jeder zusammenhängende Satz von Transaktionen angewendet wurde Lesen und schreiben Sie gemeinsam Ls Zustandsbytes. Mit diesen Informationen für die Fischer stellt eine Herausforderung dar, dass ein Zustandsübergang falsch angewendet wird reicht aus, um den ersten solchen ungültigen Zustandsstamm zu finden, und umfasst nur Ls Bytes davon Staaten, die von den Transaktionen zwischen dem letzten Stammstaat (der war) betroffen sind gültig) und die aktuelle Statuswurzel mit den Merkle-Beweisen. Dann jeder Teilnehmer kann die Transaktionen im Segment validieren und bestätigen, dass der Block vorhanden ist ungültig. Das Gleiche gilt, wenn der Blockproduzent versucht hat, lesende Transaktionen einzuschließen und mehr als Ls Statusbytes schreiben, für die Herausforderung reicht es aus, sie einzuschließen Die ersten Ls-Bytes berührt es mit den Merkle-Beweisen, was ausreichen wird Wenden Sie die Transaktionen an und bestätigen Sie, dass es einen Moment gibt, in dem ein Versuch dazu erfolgt Das Lesen oder Schreiben von Inhalten über Ls Bytes hinaus erfolgt.
3.7.2 Fischer und schnelle Cross-Shard-Transaktionen Wie in Abschnitt 2.3 besprochen, nehmen wir einmal an, dass die Shard-Chunks (oder Shard Blöcke im Modell mit Shard-Ketten) können ungültig sein und eine Herausforderung darstellen Dies wirkt sich negativ auf die Endgültigkeit und damit auf die Shard-übergreifende Kommunikation aus. In Insbesondere kann der Ziel-Shard einer Cross-Shard-Transaktion nicht sicher sein Der ursprüngliche Shard-Block oder -Block ist endgültig, bis der Herausforderungszeitraum abgelaufen ist (siehe Abbildung 21). Abbildung 21: Warten Sie den Herausforderungszeitraum ab, bevor Sie eine Quittung beantragen Die Art und Weise, es so anzugehen, dass die Cross-Shard-Transaktionen möglich sind Instantenious bedeutet, dass der Ziel-Shard nicht auf den Herausforderungszeitraum warten muss Nachdem die Quell-Shard-Transaktion veröffentlicht wurde, wenden Sie die Empfangstransaktion an sofort ausführen, aber dann den Ziel-Shard zusammen mit der Quelle zurücksetzen Shard, wenn sich später herausstellt, dass der ursprüngliche Chunk oder Block ungültig ist (siehe Abbildung). 22). Dies gilt ganz natürlich für das Nightshade-Design, in dem die Scherbe enthalten ist Ketten sind nicht unabhängig, stattdessen werden alle Shard-Blöcke veröffentlicht zusammen im selben Hauptkettenblock. Wenn sich herausstellt, dass ein Block ungültig ist, wird der Der gesamte Block mit diesem Block wird als ungültig betrachtet, ebenso alle darauf aufbauenden Blöcke oben drauf. Siehe Abbildung 23. Beide oben genannten Ansätze bieten Atomizität unter der Annahme, dass die Herausforderung besteht Der Zeitraum ist ausreichend lang. Wir verwenden den letzteren Ansatz, da die Bereitstellung schneller Cross-Shard-Transaktionen unter normalen Umständen die Unannehmlichkeiten überwiegt Der Ziel-Shard wird aufgrund eines ungültigen Zustandsübergangs in einem von ihnen zurückgesetzt die Quellsplitter, was ein äußerst seltenes Ereignis ist. 3.7.3 validators werden ausgeblendet Das Vorhandensein der Herausforderungen verringert bereits die Wahrscheinlichkeit erheblich Adaptive Korruption, da ein Block mit einem ungültigen Zustandsübergangsposten abgeschlossen werden mussAbbildung 22: Belege sofort anwenden und das Ziel zurücksetzen Kette, wenn die Quellkette einen ungültigen Block hatte Abbildung 23: Fischer-Herausforderung in Nightshade Der Herausforderungszeitraum, den der adaptive Gegner benötigt, um alle Teilnehmer zu korrumpieren die den Zustand des Shards beibehalten, einschließlich aller validators. Die Wahrscheinlichkeit eines solchen Ereignisses abzuschätzen ist äußerst komplex, da nein sharded blockchain ist schon so lange aktiv, dass ein solcher Angriff versucht werden kann. Wir argumentieren, dass die Wahrscheinlichkeit zwar äußerst gering, aber immer noch ausreichend ist groß für ein System, von dem erwartet wird, dass es mehrere Millionen Transaktionen ausführt Führen Sie ein weltweites Finanzgeschäft. Es gibt zwei Hauptgründe für diesen Glauben: 1. Die meisten validators der Proof-of-Stake-Ketten und Miner der
Der Anreiz für Proof-of-Work-Ketten besteht in erster Linie aus finanziellen Vorteilen. Wenn Ein adaptiver Gegner bietet ihnen mehr Geld als die erwartete Rendite Wenn man ehrlich vorgeht, kann man davon ausgehen, dass es viele validators gibt werde das Angebot annehmen. 2. Viele Unternehmen führen die Validierung von Proof-of-Stake-Ketten professionell durch Es wird erwartet, dass ein großer Prozentsatz der Anteile an jeder Kette liegen wird von solchen Einheiten. Die Anzahl solcher Entitäten ist für eine ausreichend klein adaptiver Gegner, um die meisten von ihnen persönlich kennenzulernen und zu haben gutes Verständnis für ihre Neigung, korrumpiert zu werden. Wir gehen einen Schritt weiter, um die Wahrscheinlichkeit der adaptiven Korruption zu verringern, indem wir verbergen, welche validators welchem Shard zugewiesen sind. Die Idee ist entfernt ähnlich der Art und Weise, wie Algorand [5] validators verbirgt. Es ist wichtig zu beachten, dass selbst wenn die validators verborgen sind, wie in Algorand oder wie unten beschrieben, ist die adaptive Korruption theoretisch immer noch möglich. Während Der adaptive Gegner kennt die Teilnehmer nicht, die erstellen oder validieren Ob ein Block oder ein Brocken, die Teilnehmer wissen selbst, dass sie etwas leisten werden eine solche Aufgabe erfüllen und einen kryptografischen Beweis dafür haben. So kann der Gegner Machen Sie ihre Korruptionsabsicht öffentlich und zahlen Sie an jeden Teilnehmer, der dies bereitstellt so ein kryptografischer Beweis. Wir stellen jedoch fest, dass der Gegner dies nicht tut Sie kennen die validators, die dem Shard zugewiesen sind, den sie beschädigen möchten haben keine andere Wahl, als ihre Absicht, einen bestimmten Shard zu beschädigen, zu verbreiten die gesamte Gemeinschaft. An diesem Punkt ist es für jeden Ehrlichen wirtschaftlich vorteilhaft Der Teilnehmer muss einen vollständigen Knoten hochfahren, der diesen Shard validiert, da ein Hoch vorliegt Wahrscheinlichkeit, dass ein ungültiger Block in diesem Shard erscheint, was eine Gelegenheit dazu darstellt Erstellen Sie eine Herausforderung und sammeln Sie die zugehörige Belohnung. Um die validators, die einem bestimmten Shard zugewiesen sind, nicht preiszugeben, tun wir dies Folgendes (siehe Abbildung 24): Verwenden Sie VRF, um die Zuweisung zu erhalten. Zu Beginn jeder Epoche validator verwendet eine VRF, um eine Bitmaske der Shards abzurufen, denen validator zugewiesen ist. Die Bitmaske jedes validator wird Sw-Bits haben (Definition siehe Abschnitt 3.3). von Sw). Der validator ruft dann den Status der entsprechenden Shards ab und Während der Epoche werden für jeden empfangenen Block die entsprechenden Blöcke validiert zu den Shards, denen validator zugewiesen ist. Melden Sie sich in Blöcken statt in Blöcken an. Da die Shard-Zuweisung verborgen ist, kann validator keine Chunks anmelden. Stattdessen wird immer das Ganze unterschrieben blockieren, sodass nicht verraten wird, welche Shards validiert werden. Insbesondere wenn validator einen Block empfängt und alle Blöcke validiert, erstellt er entweder eine Nachricht Dies bestätigt, dass alle Chunks in allen Shards, denen validator zugewiesen ist, vorhanden sind gültig (ohne in irgendeiner Weise anzugeben, um welche Shards es sich handelt) oder eine Nachricht darüber enthält einen Beweis für einen ungültigen Zustandsübergang, wenn ein Block ungültig ist. Siehe die Einzelheiten zur Aggregation solcher Nachrichten finden Sie in Abschnitt 3.8, in Abschnitt 3.7.4 die Details, wie verhindert werden kann, dass validators Nachrichten von huckepack nehmen andere validators und Abschnitt 3.7.5 für Einzelheiten zur Belohnung und Bestrafung validators, falls tatsächlich eine erfolgreiche ungültige Zustandsübergangsherausforderung stattfindet.Abbildung 24: Die validators in Nightshade verbergen 3.7.4 Commit-Reveal Eines der häufigsten Probleme mit validators besteht darin, dass ein validator das Herunterladen des Status und die tatsächliche Validierung der Chunks und Blöcke überspringen kann und stattdessen Beobachten Sie das Netzwerk, sehen Sie, was die anderen validators einreichen, und wiederholen Sie dies Nachrichten. Ein validator, der einer solchen Strategie folgt, bietet keinen Mehrwert Sicherheit für das Netzwerk, kassiert aber Belohnungen. Eine übliche Lösung für dieses Problem besteht darin, für jeden validator einen Beweis bereitzustellen dass sie den Block tatsächlich validiert haben, beispielsweise durch Bereitstellung einer eindeutigen Ablaufverfolgung Die Anwendung des Zustandsübergangs ist zwar nicht möglich, aber solche Nachweise erhöhen die Kosten erheblich der Validierung. Abbildung 25: Commit-Enthüllung
Stattdessen veranlassen wir, dass die validators zuerst auf das Validierungsergebnis übertragen werden (entweder die Nachricht, die die Gültigkeit der Chunks bestätigt, oder der Beweis einer Ungültigkeit Warten Sie einen bestimmten Zeitraum und zeigen Sie erst dann das tatsächliche Validierungsergebnis an, wie in Abbildung 25 dargestellt. Der Festschreibungszeitraum überschneidet sich nicht mit der Enthüllungszeitraum, und daher kann ein fauler validator keine ehrlichen validators kopieren. Darüber hinaus, wenn ein unehrlicher validator sich zu einer Nachricht verpflichtet hat, die dies bestätigt Gültigkeit der zugewiesenen Chunks, und mindestens ein Chunk war ungültig, sobald dies der Fall ist gezeigt, dass der Block ungültig ist, kann validator den Schrägstrich nicht vermeiden, da Wie wir in Abschnitt 3.7.5 zeigen, ist dies der einzige Weg, in einer solchen Situation nicht aufgeschlitzt zu werden besteht darin, eine Nachricht zu präsentieren, die einen Beweis für den ungültigen Zustandsübergang enthält entspricht dem Commit. 3.7.5 Umgang mit Herausforderungen Wie oben erläutert, sobald ein validator einen Block mit einem ungültigen Block empfängt, Sie bereiten zunächst einen Beweis für den ungültigen Zustandsübergang vor (siehe Abschnitt 3.7.1) und dann verpflichten Sie sich zu einem solchen Beweis (siehe 3.7.4) und offenbaren Sie nach einiger Zeit die Herausforderung. Sobald die aufgedeckte Herausforderung in einen Block aufgenommen wird, passiert Folgendes: 1. Alle Zustandsübergänge, die von dem Block aus stattgefunden haben, der die enthält ungültiger Block, bis der Block, in dem die aufgedeckte Herausforderung enthalten ist, abgerufen wird für nichtig erklärt. Der Zustand vor dem Block, der die offenbarte Herausforderung enthält gilt als derselbe wie der Zustand vor dem enthaltenen Block der ungültige Block. 2. Innerhalb einer bestimmten Zeitspanne muss jeder validator seine Bitmaske offenlegen der Shards, die sie validieren. Da die Bitmaske über ein VRF erstellt wird, wenn Sie wurden dem Shard zugewiesen, der den ungültigen Zustandsübergang „they“ hatte kann nicht umhin, es zu enthüllen. Alle validator, bei denen die Bitmaske nicht angezeigt wird Es wird davon ausgegangen, dass es dem Shard zugewiesen ist. 3. Jeder validator, der nach diesem Zeitraum dem Shard zugeordnet ist, das hat zu einem Validierungsergebnis für den Block geführt, der das enthält ungültiger Block und das ergab keinen Beweis für einen ungültigen Zustandsübergang das ihrem Commit entspricht, wird gestrichen. 4. Jeder validator erhält eine neue Shard-Zuweisung und eine neue Epoche wird geplant um nach einiger Zeit zu beginnen, die ausreicht, damit alle validators das herunterladen können Zustand, wie in Abbildung 26 dargestellt. Beachten Sie, dass die validators ab dem Moment die ihnen zugewiesenen Shards offenlegen Bis zum Beginn der neuen Epoche ist die Sicherheit des Systems verringert, da die Die Shard-Zuordnung wird enthüllt. Die Teilnehmer des Netzwerks müssen es behalten Beachten Sie dies bei der Nutzung des Netzwerks in diesem Zeitraum. 3.8 Signaturaggregation Damit ein System mit Hunderten von Shards sicher funktioniert, möchten wir Folgendes haben: Größenordnung von 10.000 oder mehr validators. Wie in Abschnitt 3.7 besprochen, wollen wir jedesAbbildung 26: Die Herausforderung meistern validator um im Durchschnitt ein Commit für eine bestimmte Nachricht und eine Signatur zu veröffentlichen einmal pro Block. Selbst wenn die Commit-Nachrichten gleich wären, wäre eine solche Aggregation möglich BLS-Signatur und deren Validierung wären unerschwinglich teuer gewesen. Aber Natürlich sind die Commit- und Reveal-Nachrichten bei allen validators nicht gleich. und daher brauchen wir eine Möglichkeit, solche Nachrichten und die Signaturen in einem zusammenzufassen Dies ermöglicht eine spätere schnelle Validierung. Der spezifische Ansatz, den wir verwenden, ist der folgende: Validatoren schließen sich Blockproduzenten an. Die Blockproduzenten sind bekannt einige Zeit vor Beginn der Epoche, da sie einige Zeit zum Herunterladen benötigen Zustand vor Beginn der Epoche, und im Gegensatz zu den validators sind es die Blockproduzenten nicht verborgen. Jeder Blockproduzent verfügt über v validator Slots. Validatoren reichen ein Off-Chain-Vorschläge an die Blockproduzenten, als einer ihrer v validators. Wenn ein Blockproduzent einen validator einschließen möchte, reicht er einen ein Transaktion, die die erste Off-Chain-Anfrage von validator enthält, und die Signatur des Blockproduzenten, die dafür sorgt, dass validator dem Blockproduzenten beitritt. Beachten Sie, dass die den Blockproduzenten zugewiesenen validators dies nicht unbedingt tun Validieren Sie dieselben Shards, für die der Blockproduzent Chunks produziert. Wenn ein validator wird angewendet, um mehrere Blockproduzenten zu verbinden, nur die Transaktion von Der erste Blockproduzent wird erfolgreich sein. Blockproduzenten sammeln Commits. Der Blockproduzent sammelt ständig die Commit- und Reveal-Nachrichten von den validators. Sobald eine bestimmte Anzahl solcher Nachrichten angesammelt ist, berechnet der Blockproduzent ein Merkle Baum dieser Nachrichten und sendet an jeden validator die Merkle-Wurzel und die Merkle Weg zu ihrer Botschaft. Der validator validiert den Pfad und meldet sich an die Merkle-Wurzel. Der Blockproduzent sammelt dann eine BLS-Signatur auf dem Merkle Root aus den validators und veröffentlicht nur die Merkle Root und die gesammelte Unterschrift. Der Blockproduzent unterzeichnet auch die Gültigkeit des Multisignatur mit einer günstigen ECDSA-Signatur. Wenn die Multisignatur dies nicht tut Wenn Sie mit dem übermittelten Merkle-Stamm oder der Bitmaske der teilnehmenden validators übereinstimmen, handelt es sich um ein streichbares Verhalten. Beim Synchronisieren der Kette ein Teilnehmer Sie können wählen, ob alle BLS-Signaturen der validators validiert werden sollen (was extrem teuer ist, da die öffentlichen Schlüssel der validators aggregiert werden müssen) oder nurdie ECDMA-Signaturen von den Blockproduzenten und verlassen sich darauf, dass die Der Blockproduzent wurde nicht angefochten und gekürzt. Verwendung von On-Chain-Transaktionen und Merkle-Beweisen für Herausforderungen. Es Es kann festgestellt werden, dass es keinen Wert hat, Nachrichten von validators preiszugeben, wenn nein Es wurde ein ungültiger Zustandsübergang erkannt. Nur die Nachrichten, die das tatsächliche enthalten Beweise für einen ungültigen Zustandsübergang müssen offengelegt werden, und zwar nur für solche Nachrichten Es muss gezeigt werden, dass sie mit dem vorherigen Commit übereinstimmen. Die Nachricht muss zu zwei Zwecken offengelegt werden: 1. Um den Rollback der Kette tatsächlich auf den Moment vor dem einzuleiten ungültiger Zustandsübergang (siehe Abschnitt 3.7.5). 2. Um zu beweisen, dass der validator nicht versucht hat, die Gültigkeit des zu bestätigen Ungültiger Block. In beiden Fällen müssen wir uns mit zwei Problemen befassen: 1. Der eigentliche Commit war nicht in der Kette enthalten, sondern nur die Merkle-Wurzel des Commit aggregiert mit anderen Nachrichten. Der validator muss das verwenden Merkle-Pfad, der vom Blockproduzenten bereitgestellt wird, und dessen ursprüngliches Commit beweisen, dass sie sich der Herausforderung gestellt haben. 2. Es ist möglich, dass alle dem Shard zugewiesenen validators ungültig sind Zustandsübergänge werden zufällig beschädigten Blockproduzenten zugewiesen zensieren sie. Um dies zu umgehen, erlauben wir ihnen, ihre Enthüllungen einzureichen als reguläre Transaktion in der Kette und umgeht die Aggregation. Letzteres ist nur für die Nachweise eines ungültigen Zustandsübergangs zulässig äußerst selten und sollte daher nicht zum Spam der Blöcke führen. Das letzte Problem, das angegangen werden muss, besteht darin, dass die Blockproduzenten dies können sich dafür entscheiden, nicht an der Nachrichtenaggregation teilzunehmen oder bestimmte validators absichtlich zu zensieren. Wir machen es wirtschaftlich unvorteilhaft, indem wir den Block herstellen Produzentenbelohnung proportional zur Anzahl der ihnen zugewiesenen validators. Wir Beachten Sie auch, dass sich die Blockproduzenten zwischen den Epochen weitgehend überschneiden (seit Es sind immer die Top-W-Teilnehmer mit dem höchsten Einsatz), die validators können Bleiben Sie weitgehend bei der Zusammenarbeit mit denselben Blockproduzenten und reduzieren Sie so das Risiko dass sie einem Blockproduzenten zugewiesen wurden, der sie in der Vergangenheit zensiert hat. 3.9 Snapshots-Kette Da die Blöcke in der Hauptkette sehr häufig produziert werden, ist das Herunterladen erforderlich Die vollständige Historie könnte sehr schnell teuer werden. Darüber hinaus seit jedem Block eine BLS-Signatur einer großen Anzahl von Teilnehmern enthält, allein die Aggregation der öffentlichen Schlüssel zur Überprüfung der Signatur könnte unerschwinglich werden auch teuer. Schließlich wird Ethereum 1.0 in absehbarer Zukunft wahrscheinlich einer bleiben einer der am häufigsten verwendeten blockchains und bietet eine sinnvolle Möglichkeit, Vermögenswerte von dort zu übertragen
In der Nähe von Ethereum ist eine Anforderung, und heute ist die Überprüfung von BLS-Signaturen erforderlich, um dies sicherzustellen Die Gültigkeit naher Blöcke auf der Seite von Ethereum ist nicht möglich. Jeder Block in der Nightshade-Hauptkette kann optional einen Schnorr enthalten Multisignatur im Header des letzten Blocks, der einen solchen Schnorr enthielt Multisignatur. Wir nennen solche Blöcke Snapshot-Blöcke. Der allererste Block von Jede Epoche muss ein Snapshot-Block sein. Während ich an einer solchen Multisignatur arbeitete, Die Blockproduzenten müssen auch die BLS-Signaturen der validators sammeln auf dem letzten Snapshot-Block und aggregieren Sie sie auf die gleiche Weise wie in beschrieben Abschnitt 3.8. Da die Menge der Blockproduzenten während der gesamten Epoche konstant ist, ist eine Validierung erforderlich Nur die ersten Snapshot-Blöcke in jeder Epoche sind ausreichend, vorausgesetzt, dass bei Nr weisen darauf hin, dass ein großer Prozentsatz der Blockproduzenten und validators zusammengearbeitet und erstellt haben eine Gabel. Der erste Block der Epoche muss für die Berechnung ausreichende Informationen enthalten die Blockproduzenten und validators für die Epoche. Wir nennen die Unterkette der Hauptkette, die nur den Snapshot enthält blockiert eine Snapshot-Kette. Das Erstellen einer Schnorr-Multisignatur ist ein interaktiver Prozess, aber da wir Es muss nur selten durchgeführt werden, egal wie ineffizient der Prozess ist wird genügen. Die Schnorr-Multisignaturen können einfach unter Ethereum validiert werden, Dadurch werden entscheidende Grundelemente für eine sichere Durchführung von Cross-blockchain bereitgestellt. Kommunikation. Für die Synchronisierung mit der Near-Kette muss lediglich der gesamte Snapshot heruntergeladen werden blockiert und bestätigt, dass die Schnorr-Signaturen korrekt sind (optional auch Überprüfung der einzelnen BLS-Signaturen der validators) und dann nur die Synchronisierung Hauptkettenblöcke vom letzten Snapshot-Block.
Conclusión
En este documento analizamos enfoques para crear blockchains fragmentados y cubrió dos desafíos principales con los enfoques existentes, a saber, la validez del estado y disponibilidad de datos. Luego presentamos Nightshade, un diseño de fragmentación que poderes NEAR Protocolo. El diseño es un trabajo en progreso, si tiene comentarios, preguntas o comentarios en este documento, vaya a https://near.chat.
Abschluss
In diesem Dokument haben wir Ansätze zum Erstellen von Shard-blockchains und besprochen deckte mit bestehenden Ansätzen zwei große Herausforderungen ab, nämlich die Zustandsvalidität und Datenverfügbarkeit. Anschließend präsentierten wir Nightshade, ein Sharding-Design Befugnisse NEAR Protokoll. Der Entwurf ist in Arbeit. Wenn Sie Kommentare, Fragen oder Feedback haben Zu diesem Dokument gehen Sie bitte zu https://near.chat.