Profundidad Dorada丨 Escritura propia de Vitalik Buterin: Texto completo de "La Filosofía de la Verificación de Blockchain"

Jinse Finance Blockchain News, 19 de agosto Vitalik Buterin, cofundador de Ethereum, publicó el artículo "Filosofía de la verificación de blockchain" en su sitio web personal el 17 de agosto. Jinse Finance compiló este artículo de la siguiente manera: Una cadena de bloques es la más fuerte. Las características más importantes es que cada parte de la ejecución de la cadena de bloques se puede verificar de forma independiente. Incluso si un atacante se apodera de la mayoría de los mineros de blockchain (o validadores en una blockchain de prueba de participación), si ese atacante intenta empujar bloques no válidos, la red simplemente rechazará esos bloques. Incluso si los usuarios no validan esos bloques dentro de un cierto período de tiempo, recibirán una advertencia potencial y automática, y pueden verificar si la cadena de bloques del atacante no es válida y rechazar automáticamente esos bloques antes de aceptar una cadena de acuerdo con las reglas. Pero, ¿cuánta validación necesitamos realmente? ¿Necesita cien validadores independientes o mil validadores independientes? ¿Necesitamos una cultura en la que todas las personas normales del mundo ejecuten software para verificar cada transacción? Resolver los problemas anteriores será un desafío muy importante si queremos construir una cadena de bloques con un mecanismo de consenso que sea mejor que la cadena única de prueba de trabajo original creada por "Satoshi Nakamoto". ¿Por qué es necesario verificar la cadena de bloques? La imagen de arriba muestra un "ataque del 51%" penetrando un bloque inválido, ¡queremos que la red rechace esta cadena! La verificación de la cadena de bloques es muy beneficiosa para los usuarios por dos razones principales: 1. Primero, la verificación de la cadena de bloques maximiza las posibilidades de que los nodos puedan determinar correctamente hablar en la cadena canónica (Nota financiera dorada: la llamada cadena canónica es la reconocida por la comunidad. Blockchain) Por lo general, una cadena canónica se define como algo así como "la cadena de bloques válida con la mayoría de los mineros/validadores que respaldan esa cadena" (por ejemplo, la "cadena válida más larga" en Bitcoin). Las cadenas no válidas son, por definición, rechazadas, y si se elige entre varias cadenas válidas, gana la que tenga más soporte de minero/validador. Entonces, si tiene un nodo que puede verificar todas las condiciones de validez, detectando así qué cadenas son válidas y cuáles no, maximiza sus posibilidades de detectar correctamente las cadenas canónicas. 2. En segundo lugar, hay una razón más profunda para verificar la validez de la cadena de bloques: suponga que un participante poderoso intenta impulsar un cambio en el protocolo (como cambiar la emisión del token) y obtiene el apoyo de la mayoría de los mineros, si es que nadie. de lo contrario, valide la cadena de bloques, entonces este ataque es muy fácil de tener éxito, porque por defecto todos los clientes aceptarán la nueva cadena, y cuando la gente vea lo que está sucediendo, los disidentes intentarán coordinar el rechazo de esa cadena. Sin embargo, si los usuarios comunes están verificando, entonces el problema de coordinación recae en el otro lado: aquellos que intentan cambiar el acuerdo serán responsables de convencer a los usuarios para que descarguen activamente parches de software para aceptar el acuerdo. Si suficientes usuarios validan, se evitarán confusiones innecesarias y disputas sobre cambios forzados en el protocolo. El caos puede causar mucho daño y necesita una coordinación social fuera de la banda para resolverlo. No hay motivación para atacar. Si la mayoría de los usuarios están validando (directa o indirectamente) y el ataque solo es compatible con la mayoría de los mineros, el ataque fracasará por defecto, que es el mejor de todos los resultados. Punto de vista de definición versus punto de vista de coordinación Tenga en cuenta que esta línea de razonamiento es bastante diferente de otra línea de razonamiento que escuchamos a menudo: "Por definición", la cadena que cambia las reglas no es en realidad la cadena correcta de alguna manera, independientemente de cuántas otras los usuarios aceptan algunas reglas nuevas, lo importante es que aún puedes permanecer en la cadena que te gusta y seguir las reglas antiguas. El siguiente diagrama es un ejemplo de la vista "por definición" de Gavin Andresen: Otra vista, de la billetera Wasabi, es más directa desde la perspectiva de explicar por qué los nodos completos son valiosos: Tenga en cuenta que esta vista tiene dos partes principales: 1. El La versión de la cadena que no acepta lo que consideras reglas fundamentales e intransferibles no es Bitcoin (o Ethereum o cualquier otra cadena blockchain) por definición, sin importar cuantas otras acepten esa cadena. 2. Lo importante es que debes mantener las reglas de la cadena que creas que son aceptables. Sin embargo, creo que esta visión "individualista" está muy equivocada. Para ver por qué, veamos la situación que tememos: la gran mayoría de los participantes puede aceptar algún cambio en las reglas del protocolo que consideraría inaceptable. Como ejemplo, imagine que tenemos un futuro donde las tarifas de transacción son bajas, y casi todos los demás aceptan cambiar a un nuevo conjunto de reglas que aumentan la emisión para mantener la cadena de bloques segura, pero obstinadamente sigue ejecutando un nodo que continúa haciendo cumplir las viejas reglas y bifurcaciones a una cadena diferente a la de la mayoría de los nodos. Desde su propia perspectiva, aún puede poner tokens en un sistema que opera bajo las reglas antiguas que son aceptables. ¿Y qué? Otros usuarios no aceptarán sus tokens en absoluto y los intercambios tampoco aceptarán sus tokens. El sitio web de precios enumerará el precio del token, pero su fuente de datos definitivamente apuntará al token en la cadena mayoritaria, por lo que su token no tendrá valor. Las criptomonedas y las cadenas de bloques son fundamentalmente una construcción social y no significan nada si nadie más cree en ellas. Entonces, ¿cuál es la visión alternativa? Una idea central presentada aquí es ver blockchain como seguridad de ingeniería a través del problema de coordinación. En general, la mayoría de los problemas de coordinación que encontramos en nuestro mundo no son cosas buenas, aquí hay algunos ejemplos: 1. Para la mayoría de las personas, el inglés en realidad no está "coordinado" porque es muy complejo y tiene muchos sistemas ortográficos irregulares. y estructura fonológica; 2. Algunas personas piensan que EE. UU. podría estar mejor si cambiara a medidas métricas; 3. Otros sienten que una reducción del 10% en todos los precios y salarios inmediatamente en caso de una recesión ayudará al país a salir adelante , por lo que, de hecho, todos deben ponerse de acuerdo para hacerlo y, por lo general, es muy difícil de lograr. Sin embargo, en las aplicaciones de blockchain, usamos los problemas de coordinación a nuestro favor y la fricción creada por los problemas de coordinación para resistir la mala conducta de los ejecutores centralizados. Como otro ejemplo, podemos construir un sistema con la propiedad X y podemos garantizar que el sistema siempre conserve la propiedad X, pero si queremos cambiar la regla de X a no-X, necesitamos que un gran número de personas acepten actualizar su software al mismo tiempo. Incluso con un ejecutor forzando el cambio, sería muy difícil, mucho más difícil que si un usuario fuera responsable de coordinar a los disidentes para resistir el cambio. Tenga en cuenta que este punto de vista tiene una consecuencia especial: el propósito central de su nodo completo no es solo protegerlo, y en el caso de una bifurcación dura contenciosa, las personas con nodos completos están más seguras que aquellas sin nodos completos. . Por el contrario, el punto de vista aquí es más un punto de vista de inmunidad de grupo, es decir: mientras más personas verifiquen, mayor será la seguridad que tienen todos, incluso si solo algunas personas están verificando, el resultado hará que todos los individuos sean otorgaba un mayor grado de protección. Profundización en la validación de blockchain Ahora, pasamos al siguiente tema, que es muy relevante para temas como clientes ligeros y fragmentación: con la validación, ¿qué vamos a lograr? Para entender esto, volvamos a épocas anteriores: si hay un ataque a la cadena de bloques, entonces la forma en que ocurre el ataque puede tener el siguiente orden de precedencia: por defecto al fracaso > por defecto al caos > por defecto a la victoria aquí "> ;" significa "mejor que". Lo mejor es que el ataque falle por completo, lo segundo mejor es que el ataque cause confusión y todos no estén de acuerdo en la cadena correcta, y lo peor es que el ataque tenga éxito. La pregunta aquí es: ¿por qué el caos es mucho mejor que la victoria? De hecho, es una cuestión de motivación, a saber: la confusión aumenta el costo del atacante, lo que significa que la probabilidad de que el atacante gane definitivamente se reduce considerablemente, por lo que el atacante no se anima a atacar en primer lugar. El entorno caótico por defecto significa que el atacante no solo necesita ganar la guerra de la cadena de bloques para realizar un ataque del 51 %, sino también convencer a la comunidad para que siga esta "guerra social", que es mucho más difícil que simplemente lanzar un ataque del 51 % y ganando por ataque puro mas, y mucho menos atractivo. El objetivo de la validación es pasar del estado predeterminado de la victoria al caos (idealmente) y del caos al fracaso (menos ideal). Si tiene un nodo de validación total y el atacante intenta empujar una cadena con una regla diferente, el ataque fallará. Si algunas personas tienen nodos de validación completos, pero muchas otras no, el ataque puede conducir al caos. Sin embargo, ahora debemos pensar en otra pregunta, a saber: ¿Hay alguna otra forma de lograr el mismo efecto? Clientes ligeros y pruebas de fraude Un desarrollo natural en esta área son los clientes ligeros con pruebas de fraude. La mayoría de los clientes ligeros de blockchain actualmente en el mercado funcionan simplemente verificando que la mayoría de los mineros admitan un bloque en particular, sin molestarse en verificar que se cumplan otras reglas de protocolo. Es decir, el cliente opera bajo el supuesto de confianza de que la mayoría de los mineros son honestos. En el caso de una bifurcación contenciosa, los clientes siguen la cadena mayoritaria de forma predeterminada y depende de los propios usuarios tomar medidas activas si desean seguir las reglas anteriores. Por lo tanto, los clientes ligeros que están siendo atacados hoy en día ganan por defecto. Pero con la tecnología de prevención de fraude, las cosas empiezan a verse muy diferentes. La forma más simple de prueba de fraude funciona así: por lo general, un solo bloque en la cadena de bloques solo toca una pequeña parte del "estado" de la cadena de bloques (como saldos de cuentas, código de contrato inteligente, etc.). Si los nodos completamente validados procesan un bloque y encuentran que no es válido, pueden generar un paquete que contenga el bloque, es decir, una prueba de fraude, que contendrá información suficiente para procesar el bloque. Luego, la cadena de bloques transmite este paquete a los clientes ligeros, quienes pueden recibir el paquete y usar los datos relevantes para validar el bloque en sí, incluso si no tienen otros datos en la cadena. Como se muestra en el diagrama anterior, los bloques individuales en la cadena de bloques se refieren solo a unas pocas cuentas. Las pruebas de fraude contendrán los datos de estas cuentas junto con una prueba de Merkle de que estos datos son correctos. Esta técnica a veces se denomina verificación sin estado: un cliente puede conservar solo los encabezados de los bloques en lugar de la base de datos de estado completa de la cadena de bloques, y puede verificar cualquier bloque en tiempo real solicitando a otros nodos una prueba de Merkle de cualquier estado deseado. Además, también se puede acceder a las entradas de la verificación del bloque. El poder de esta técnica es que los clientes ligeros solo validan bloques independientes cuando escuchan una alerta (y las alertas son verificables, por lo que si los clientes ligeros escuchan alertas falsas, pueden dejar de escuchar alertas para ese nodo). Entonces, en circunstancias normales, los clientes ligeros siguen siendo clientes ligeros, solo verifican qué bloques son compatibles con la mayoría de los mineros/validadores. Sin embargo, en circunstancias especiales, como cuando la cadena mayoritaria contiene un cliente ligero que no aceptará el bloque, siempre que haya un nodo honesto para verificar el bloque fraudulento, entonces el nodo encontrará que el bloque no es válido, siempre y cuando ya que este nodo A transmite una prueba de fraude, y otros nodos en la red la rechazan. Fragmentación La fragmentación puede verse como una extensión natural de la verificación de red: en un sistema fragmentado, hay demasiadas transacciones en el sistema para que la mayoría de las personas las verifique directamente de manera consistente, pero si el sistema está bien diseñado, cualquiera puede ser detectada Bloques independientes no válidos , y esta invalidez a menudo irá acompañada de evidencia de pruebas de fraude que se pueden propagar a través de la red. Podemos pensar en una red compartida como que todos son un cliente ligero, siempre que cada fragmento tenga un cierto número de umbral mínimo de participantes, entonces la red tiene inmunidad colectiva. Además, el hecho de que la producción de bloques (y no solo la validación de bloques) sea altamente accesible en un sistema fragmentado, e incluso se pueda realizar en una computadora portátil doméstica, también es muy importante, ya que significa que el núcleo de la red no depende de El hardware de alto rendimiento también garantiza que las cadenas minoritarias puedan funcionar con estándares más bajos y hace que sea más difícil que los cambios de protocolo impulsados ​​por cadenas mayoritarias "ganen por defecto" e intimiden a otros. Esto es lo que suele significar la auditabilidad en el mundo real: no todo el mundo está verificando todo todo el tiempo, pero: (i) cada parte en particular tiene suficientes ojos para que, si hay un error, se detecte; (ii) ) cuando se produce un error se detecta, asegurándose de que sea claramente visible para todos. Dicho esto, blockchain ciertamente puede mejorar esto a largo plazo. Una fuente particular de mejora son los ZK-SNARK (o "pruebas de validez"): pruebas criptográficas de verificación válida que permiten a los productores de bloques probar a los clientes que un bloque ha cumplido alguna condición de validez arbitrariamente compleja. Las pruebas de validez son más sólidas que las pruebas de fraude porque no se basan en juegos interactivos para detectar el fraude. Otra técnica importante es la comprobación de disponibilidad de datos, que evita que los bloques ejecuten datos que no se han publicado por completo. Sin embargo, las comprobaciones de disponibilidad de datos se basan en la suposición muy conservadora de que hay al menos una pequeña cantidad de nodos honestos en algún lugar de la red, y la buena noticia es que siempre habrá nodos honestos en la red, incluso en presencia de un gran número de atacantes. El tiempo y los ataques del 51 % Ahora, analicemos la peor consecuencia posible de la mentalidad de "caos predeterminado": el 51 % se ataca a sí mismo. La norma actual en muchas comunidades es que si gana un ataque del 51 %, entonces la cadena que sufrió el ataque del 51 % debe ser la cadena válida. En términos generales, cumpliremos estrictamente con esta especificación, como el reciente ataque del 51 % a Ethereum Classic (Ethereum Classic). Los atacantes revirtieron más de 3.000 bloques (se robaron 807.260 ETC mediante gastos dobles en el proceso), lo que hace que el historial de la cadena sea más largo de lo que técnicamente pudo restaurar uno de los dos clientes de ETC (OpenEthereum). Como resultado, los nodos Geth están alineados con el atacante. cadena, mientras que los nodos de OpenEthereum están alineados con la cadena original. Se puede decir que este ataque causó un "caos predeterminado", aunque fue un evento accidental, no una decisión de diseño deliberada por parte de la comunidad de ETC. Pero, lamentablemente, la comunidad de Ethereum Classic optó por aceptar la cadena de ataque (más larga) como norma, que la cuenta oficial de Twitter de Ethereum Classic describió como "siguiendo la prueba de trabajo esperada", por lo que, al final, la comunidad participó activamente Ayuda a los atacantes a ganar. Sin embargo, podemos estar de acuerdo de manera diferente en la definición de la cadena canónica: en particular, imagine una regla que una vez que un cliente acepta un bloque como parte de la cadena canónica, y ese bloque tiene más de 100 bloques subsiguientes, entonces el cliente en realidad está perfectamente bien para nunca aceptes una cadena que no contenga ese bloque a partir de ese momento.

Tags：

XRP