Suscríbete a RCast en iTunes | Google Play | Grapadora
Greg Meredith continúa la discusión sobre la vida con Isaac DeFrain y Christian Williams.
Greg: Hoy quiero hablar sobre algunas cosas prácticas que han sucedido con la dinámica de la red y luego hablar sobre cómo el código de corrección de errores aborda directamente eso. Si recuerdas, hace varios meses hablamos sobre códigos de corrección de errores y cómo eso nos da una manera de lidiar con los problemas de vida.
Isaac: ¿Podríamos volver a visitar esto sobre los códigos de corrección de errores y cómo se relaciona con la seguridad? Ha pasado un tiempo desde que pensé en eso, y tal vez sería útil para todos los demás.
Greg: Voy a hacer eso seguro, pero lo haré en el contexto de este problema en particular. Primero, quiero registrarme y ver si entiendes el problema.
Christian: ¿De qué estamos hablando?
Greg: Lo que estamos viendo en este momento es un problema en el equilibrio dinámico de la red. El problema es que si tiene un grupo de validadores, todos con especificaciones idénticas, un validador puede adelantarse a los otros validadores. Todos los demás validadores son solo bloques de procesamiento propuestos por el validador inicial. Algunos validadores reciben un despliegue de un cliente, y luego ejecuta el contrato asociado con el despliegue, y luego realiza una repetición como parte de la validación de ese cálculo, y luego reenvía la propuesta, el bloque, a otros validadores.
En ese momento, la verificación del bloqueo está en su pasado y puede continuar haciendo otras cosas. Todos los demás validadores tienen que lidiar con ese bloque. Bajo ciertos tipos de condiciones, con respecto a la latencia de la red y otras cosas, ese validador, a pesar de que todos son equivalentes en términos de ancho de banda de red y capacidad de almacenamiento y cómputo, ese validador inicial puede correr por delante de todos los demás y ser el único. que propone bloques en la red. ¿Tiene sentido?
Isaac: si.
Greg: Si ese es el caso, entonces obviamente la red no tiene mucha seguridad. Solo tienes un validador que hace algo.
Isaac: bien.
Greg: bien. De acuerdo, entendemos el problema. ¿Estás de acuerdo en que este es un problema de vida?
Isaac: si.
Greg: De acuerdo, bien. El objetivo de los códigos de corrección de errores es abordar la vitalidad. En particular, dar un lenguaje para abordar la vitalidad. En lugar de volver a la gloria completa del marco antes, voy a hablar sobre una versión restringida del mismo y luego ampliar lentamente el alcance de la discusión a donde podemos ver por qué este es un subconjunto de La versión completa.
Ahora voy a proponer una solución. La solución a esto proviene de la estructura de bloques que usamos en Casper. En Casper, tenemos esta idea de las justificaciones. Cada bloque que recibe un validador tiene un puntero a los hashes de bloques, esencialmente, bloques anteriores que justifican este bloque.
Un poco sobre la historia: esta idea de usar punteros de justificación se remonta a la semántica del juego propuesta por Highland y Ong para la lógica lineal. Desde aquellos días era consciente del uso de punteros de justificación y, esencialmente, usan punteros de justificación como una forma de razonar sobre el enhebrado de cálculos particulares.
En el período de 2008, comencé a adaptar esa idea para la seguridad de la red. Estaba creando una versión de lo que ahora tenemos como RSpace. Quería que los nodos en esa red de nodos RSpace tuvieran un medio de hacer seguridad de protocolo. Introduje la idea de los punteros de justificación. Puede ir a ver el Special K Github y ver el código Scala que proporciona una implementación de estilo genérico bastante abstracta de punteros de justificación como parte de la seguridad de un protocolo de red.
Vlad y yo estábamos discutiendo esto y llegamos a la idea de que podríamos usar las justificaciones para ir tras la equivocación porque esencialmente la equivocación es una forma de roscado no único. De eso creció la seguridad. Este es el comienzo de Casper correcto por construcción.
Ahora la idea es utilizar la estructura de justificación para limitar lo que son buenas justificaciones. Imagine que dividimos la red desde la perspectiva de un validador particular en jugador y oponente. El validador es el jugador, y todos los demás validadores en agregación que consideramos oponentes. Representan el medio ambiente. Con suerte, eso da una pista de cómo se relaciona esto con la semántica del juego.
Si tienes una buena alternancia en la estructura de justificación: el jugador se va, el oponente se va, el jugador se va, el oponente se va, algo así, entonces el conejo no puede correr hacia adelante. ¿Tiene sentido?
Christian: si. Por oponente, ¿te refieres a todos en la burbuja de otros validadores?
Greg: Solo que estamos en la misma página, de lo que estoy hablando es del árbol de expansión del dag de justificación de un bloque en particular. Lo que quiero decir con buena alternancia es que la raíz de ese árbol es el bloque que se propone. La siguiente capa hacia abajo es una franja de bloques de justificación. Luego tienen las justificaciones correspondientes, que le dan una nueva franja. Lo que estamos diciendo es que la primera franja tiene que ser el oponente. No puede ser jugador.
Mientras mantengas esa estructura en funcionamiento [jugador, oponente, jugador, oponente] recursivamente a lo largo del árbol de expansión de la dag, entonces todos alternarán con su entorno. El jugador no puede correr por delante. Lo que puede ver en los datos que tenemos es que la justificación de los bloques de conejo es otro bloque de conejo. La justificación de ese bloque es otro bloque de conejo. Los conejos se justifican a sí mismos.
Christian: ¿Qué es un bloque de conejo?
Greg: Un bloque propuesto por el validador que está corriendo por delante de los demás, lo que yo llamo un conejo. Lo que obtienes son estas largas cadenas del conejo que propone este bloque y la justificación de esto es este bloque anterior que el conejo propuso y así sucesivamente. Es esta falta de alternancia con el entorno lo que le permite al conejo correr por delante.
Isaac: si. Es como si los validadores ni siquiera prestaran atención a lo que está sucediendo en el entorno. Solo están haciendo lo suyo.
Greg: exactamente. Entonces esta propiedad de alternancia se convierte en un problema de vida.
Christian: Cuando impones esta alternancia para cada validador considerado como jugador, ¿no se convierte en equivalente a que ningún validador puede ir hasta que todos los demás se hayan ido?
Greg: Muy buena pregunta. Eso lleva al próximo refinamiento: estás conectándome delante de mí. Hay dos cosas de las que debe preocuparse. El primero es la condición muy inicial. En la condición inicial, si necesita que el primer bloque del validador que haya producido o propuesto alguna vez tenga que tener esta justificación de los otros validadores, todos están estancados. Esa es una condición de punto muerto. La vida y el punto muerto están estrechamente relacionados.
Lo que puede permitir es un prefijo inicial. Lo primero que puede hacer es decir que el bloque de génesis, que es lo que inicia todo, está realmente firmado por todos los validadores. Debido a que está firmado por todos los validadores, cualquier validador puede usarlo como justificación inicial. Puede salir del bloque de inicio de esa manera y luego puede permitir un prefijo inicial. Tiene una cantidad de bloques que toca fondo en el bloque de génesis que se justifica por sí mismo. Pero luego de eso, debes tener una buena alternancia. Eso le da suficiente margen de maniobra en la red para permitir que haya un flujo de bloques decente alrededor de la red antes de que tenga que comenzar a prestar atención a su entorno.
Isaac: ¿Estás diciendo que tendrías algún tipo de límite superior para estos bloques no alternos, y luego, después de ese punto, tienen que tener esta buena propiedad de alternancia?
Greg: Eso es exactamente correcto. El otro refinamiento es que no necesariamente quieres que sea el resto de los validadores. Solo desea un porcentaje del entorno relacionado con su participación. Podemos observar muchas de las dinámicas, pero debido a que solo estamos teniendo una conversación aquí, una versión simplificada de esto es solo para decir que tienes que tener un tercio de la apuesta. Eso corresponde a la literatura tradicional de consenso.
Cuando estábamos hablando de esto con Kent el otro día, él estaba diciendo, bueno, ¿no reduce esto el protocolo solo a PBFT: práctica tolerancia a fallas bizantinas? No lo hace, porque todo esto se trata de la propuesta de un bloque. No sabes que este bloque no quedará huérfano. No vuelve a colapsar a una práctica tolerancia a fallas bizantinas. Solo nos estamos dando un límite práctico. Hay otros límites que puede establecer. Pero si haces eso, entonces obtienes vida. Obtiene una forma de vida que al menos supera este equilibrio particular de la red.
Lo hicimos por razonamiento de sentido común. Puede reducirlo a una prueba formal. Lo más importante es que vea el argumento de sentido común.
Christian: ¿Qué significa tener una participación de un tercio en este contexto?
Greg: Cuando miras los validadores y la justificación, cada uno de esos validadores tiene una participación correspondiente. Eso es lo que significa ser un validador. Desea que la apuesta agregue la suma de la apuesta de los validadores que se encuentran en la justificación que no es el validador que propone sumar a un tercio de la apuesta total. Conoces la apuesta total porque está en el bloque de génesis. Conocer el conjunto legal de validadores es fundamental para la función del protocolo.
Christian: ¿Mantener esta condición es a lo que te refieres como el equilibrio?
Greg: No, el equilibrio es el validador que se comunica sin que haya un punto muerto o un punto muerto. Pero la condición te da buenos equilibrios. Puedes expresar esto en los juegos de estilo Von Neumann-Nash. Puedes hablar de esto literalmente como equilibrios de Nash. Aquí hay una relación cercana, pero no voy a esbozar eso en esta conversación.
Isaac: ¿Cómo influye la rotación del validador en esto?
Greg: Esencialmente, cuando ocurre la rotación del validador, entonces tienes que actualizar el conjunto de validadores y eso cambiará potencialmente a quién se le permite enumerar en las justificaciones. Hay muchas cosas recursivas interesantes que sucedieron en el protocolo porque no desea que los validadores censuren a los validadores que se rotan, etc. Esa es una discusión separada de la que estamos teniendo.
Hemos hablado de cierta relajación en la buena propiedad de alternancia. Permitimos un prefijo inicial y estamos viendo un porcentaje de la apuesta. El código completo de corrección de errores de vida se puede transformar en una especificación de gramáticas ponderadas en el dag de justificación. Cuando hablamos la última vez, presentamos el cálculo espacial, que nos permitió hacer esta condición de vida programable. Las condiciones de vida esencialmente parecían un contexto en el que desplegó su proceso. Luego lo hicimos programable haciendo que el contexto sea de primera clase. Puedes enviarlos y ese tipo de cosas. Eso es lo que nos dio este cálculo espacial.
La idea básica de codificar el contexto puede transformarse paso a paso en restricciones en el dag de justificación. Te dicen cuáles son las comunicaciones permitidas; la vista de las comunicaciones permitidas se representa en la justificación dag. Este bloque en particular está justificado por estas comunicaciones que he visto. Esas comunicaciones están justificadas por estas comunicaciones que otros validadores han visto. Así es como prácticamente se da cuenta de esta idea de código de corrección de errores en el protocolo Casper.
Hablemos sobre cómo encajan todas las piezas. Hay muchas partes móviles y solo quiero asegurarme de que todos entiendan las partes móviles. Hace unos meses esbocé cómo puede convertir la idea del código de corrección de errores de la vida en una codificación basada en el contexto, y luego hacer que sea programable, lo que le brinda un lenguaje para hablar sobre las restricciones de la vida. Lo que no dije fue cómo relacionar eso directamente con la implementación en Casper.
No lo relacionamos con problemas de vida observados en el protocolo en ejecución. Dijimos, aquí hay una buena teoría. Tiene algunas propiedades encantadoras. Es susceptible de bisimulación y, por lo tanto, está restringido por tipos y yada yada yada: muchas propiedades agradables, pero no conectamos esas buenas propiedades con una implementación en ejecución.
Ahora tenemos la implementación en ejecución y se enfrenta a problemas reales de vida que observan nuestros SRE en Testnet-2. Puede ver los tiempos propuestos para que los validadores se alarguen bajo ciertas condiciones de red. Resulta que si ejecuta condiciones de red restringidas particulares, que son naturales cuando recién comienza a probar la cosa, no las observa. Es solo bajo ciertos tipos de carga que comienzan a afianzarse. Es un problema sutil en el equilibrio de la red.
Isaac: ¿Qué está causando el aumento en los tiempos propuestos?
Greg: Es porque el validador de conejos puede obtener una ventaja sobre todos los demás validadores.
Isaac: Este es un comportamiento indeseable.
Greg: Es un comportamiento indeseable. Queremos eliminarlo. Podemos demostrar que es claramente un problema de vida. Ahora podemos dar una respuesta clara sobre cómo abordar el problema de la vida en términos solo del código de Casper. Ahora podemos conectar los puntos y mostrar que la solución es parte de una solución más grande que está contenida en nuestra teoría de la vida programable.
Isaac: Eso es asombroso.
Greg: Así es como se debe construir este tipo de software. En particular, la metodología que utilizamos aquí fue ir despacio y asegurarnos de observar problemas reales y luego extraer lo suficiente de la teoría para resolver el problema y conectar los puntos de esa manera.
Hay dos enfoques para esto. Empiezas desde un lugar de corrección y solo haces transformaciones que preservan la corrección. Eso es lo que estamos haciendo. Pero el otro lado de eso es que hay algunos aspectos de la corrección que son insensibles a problemas emergentes como el equilibrio de la red.
Debes asegurarte de estar dispuesto a tomar ambos lados. Solo está haciendo las transformaciones correctas de código, pero también está atento a estos fenómenos emergentes y se asegura de que su teoría sea capaz de manejarlos, y luego aplica la teoría para resolver ese tipo de cosas de manera disciplinada. Eso es lo que hemos hecho aquí.
Lo bueno es que da como resultado una solución que solo requiere un par de líneas de código para garantizar esta propiedad. Se puede implementar en una semana. Sabemos que se basa en un argumento de corrección. Sabemos que está conectado a una teoría sobre la que podemos razonar de manera equitativa. Esa es la razón de ser de CBC Casper. Por eso hacemos esto.
Issac: ¿Hay una implementación funcional de esto actualmente?
Greg: Encontramos el problema. Este lunes tuvimos una larga conversación para asegurarnos de que estábamos de acuerdo con los parámetros, porque notamos que la solución es paramétrica, por lo que queríamos un acuerdo sobre los parámetros. Ahora está multado. El trabajo ha sido asignado a uno de los ingenieros y se está implementando mientras hablamos.
Christian: No tengo muy claro en mi cabeza cómo está funcionando esto. ¿Podemos caminar a través de un ejemplo simple de esto en la práctica?
Greg: claro. Comencemos con el problema. El problema es que el contrato de engaño se propone y el engaño tiene mucha recurrencia. Hace muchas capas de recursión. El cliente implementa esto en el validador. El validador luego ejecuta el contrato, y luego reproduce el contrato, y luego propone que el bloqueo con eso se realice al resto de la red.
El validador Alice ha hecho tanto trabajo. Ahora toda la repetición está detrás de Alice. Alice ahora es libre de responder a las solicitudes de otros clientes. Si tiene un cliente solicitando, digamos en el orden de cada cinco segundos, los otros validadores, si han aceptado el trabajo de Alice, entonces están atrapados en ese trabajo, incapaces de prestar mucha atención a las solicitudes de los clientes.
Alice puede ir más y más adelante. Pero la única razón por la que puede avanzar más y más porque los bloques que Alice está usando como justificación para los bloques que está proponiendo son bloques que Alice ha propuesto. Si insistimos en que el bloque de génesis, dado que está firmado por todos los validadores, constituye la totalidad de la apuesta de todos los validadores, entonces eso puede usarse como justificación para cualquier bloque inicial propuesto por un validador.
La otra cosa que hacemos es insistir en la condición de que cualquier bloque que se proponga, los bloques que lo justifiquen, deben contener al menos un tercio de la participación de otros validadores. No nos importa cuáles son, simplemente no puede ser Alice o quien está proponiendo el bloqueo
Christian: ¿Estos requisitos se codifican contextualmente en el cálculo del espacio-tiempo?
Greg: Eso se convierte en un contexto. Lo que harías es convertirlo en un contexto, que está imponiendo ese tipo de alternancia. El contexto se sentaría allí y esperaría y recogería bloques. Así es como conectas los dos. Una vez que tiene esta propiedad de alternancia, Alice se ve obligada a esperar. Ella no puede adelantarse a los otros validadores porque no puede ser tan auto justificada. ¿Eso ayuda?
Christian: si.
Greg: genial. ¿Alguna idea, pregunta, comentario sobre algo de lo que hablamos hasta ahora?
Isaac: Es bastante obvio al observar las justificaciones qué validadores en realidad propusieron los bloques que se están utilizando en la justificación, ¿verdad?
Greg: si. Obtienes esta estructura recursiva.
Isaac: Entonces esta es la aplicación del protocolo de una regla general: no creas a alguien que solo está usando su propio trabajo para justificar su trabajo futuro. Desea mirar a alguien que tiene una visión un poco más holística de las cosas. Desea la aplicación del protocolo de eso y no solo tiene que seguir una regla general.
Greg: Eso es exactamente correcto. Si piensa en el árbol de expansión del dag de justificación como un término en alguna sintaxis abstracta, entonces lo que estamos diciendo es que estas restricciones de vida corresponden a ciertos tipos de gramáticas libres de contexto que están ponderadas. No se trata solo de una gramática simple porque ahora está teniendo en cuenta los pesos de las apuestas.
Estas gramáticas libres de contexto también se pueden convertir en el tipo de bolas basadas en la distancia de Hamming que se discuten en los documentos de código de corrección de errores que mencioné hace unos meses. Lo que se puede alcanzar con la gramática se puede convertir en lo que se puede alcanzar con estos dispositivos de distancia de Hamming. Esa es la conexión allí.
Christian: ¿Cada bloque es un término en la gramática o todo el dag es un término en la gramática?
Greg: La gramática es una especificación externa que dice que cuando propones un bloque si no es aceptado por esta gramática, no es válido. Es una regla Es una restricción. Una de las cosas que discutimos el lunes fue ¿cuál es el cumplimiento del protocolo final sobre esta buena forma? Si solo hace que los validadores implementen esta lógica, pero en realidad no castiga a los validadores que desobedecen la lógica, al menos en alguna forma, aún pueden causar desequilibrio en la red.
Christian: ¿Cada vez que intentas imponer algún tipo de condiciones en un cierto tipo de dag en una cadena, hay una gramática correspondiente y también habrá algunos contextos correspondientes en el cálculo?
Greg: Eso es exactamente correcto. Las condiciones de vida corresponden a las gramáticas; esas gramáticas pueden implementarse por contexto. Existe una propiedad de recursión, que es que cada dag de justificación es homomórfica al dag de blockchain total. No son lo mismo. Un dag de justificación no será lo mismo que el dag de blockchain. Al final del día, el bloque que tienes no es todo el dag. Es un pedazo de la daga. Así es como encajan todas las piezas.
Déjame terminar el punto sobre castigar. La forma más simple de castigo es el ostracismo social. Cuando me envías un bloque que no coincide con la gramática, lo dejo caer al suelo. Si tu perro se está portando mal, lo ignoras. A los perros generalmente no les gusta que los ignoren, por lo que comienzan a comportarse. Es ese tipo de modificación de comportamiento.
Puedes ir un poco más allá porque aún así, puede ser un poco molesto que el perro siga saltando sobre ti. Estás ignorando al perro, está saltando, estás ignorando al perro, está saltando, y finalmente el perro se da cuenta de que mientras saltes sobre ti, vas a ignorarlo. Entonces modifica su comportamiento. Durante ese tiempo, ha usado algo de ancho de banda de comunicación.
Podría considerar una modificación adicional del comportamiento. En el caso de nuestro protocolo que podría corresponder a la reducción, si están enviando un bloqueo no válido, puede reducirlo. El truco es desambiguarte si quieres hacer lo que llamamos cortar hasta el hueso, donde se erradica toda la estaca, o si haces una tala parcial. Muerto por mil cortadas.
En este caso particular, tengo el presentimiento de que deberíamos usar este tipo de enfoque para lidiar con la partición de red y volver a unirnos. Puede modificar las condiciones para que si un validador pudiera mostrar, esta parte es un poco misteriosa y complicada para mí, pero si pudieran mostrar, mire, solo he podido ver mensajes de estos validadores en el último momento. . Todavía respeto la regla, pero mi apuesta total es de un grupo reducido de validadores. Entonces podrías hacer un corte parcial en caso de que mientan. Cuando la red se vuelve a unir, reciben los otros mensajes y se les puede devolver el corte parcial.
Si bien la red está particionada, todavía están progresando, no están eliminados del juego. Si resulta que todo fue verificablemente el caso, se les devuelve el corte parcial. Este es un protocolo mucho más sutil. Hay muchas condiciones de borde que deben verificarse. Pero la idea es usarlo para lidiar con la partición de la red y luego volver a unirse y reconciliarse.
Christian: ¿Tenemos una manera de representar la historia de observación de un agente?
Greg: Es un poco complicado porque pueden mentir. Hay algunas cosas que deberíamos hacer cumplir. Por eso quieres hacer una barra parcial. Si están mintiendo y alguien más tarde puede probar que están mintiendo, entonces la barra parcial de cenizas permanece. De lo contrario, si no hay evidencia de mentira, entonces podrían ser sanados nuevamente.
Christian: ¿No hay forma de hacer que sus comunicaciones pasadas sean transparentes para la red?
Greg: No se trata de sus comunicaciones. Se trata de lo que se les envió. No puedes probar que lo consiguieron. Bueno, puede haber formas de probarlo, pero eso es algo más complicado. Un paso a la vez.
Esto es lo que me emociona de RChain. Estos son problemas encantadores. Son hermosos problemas. Están claramente relacionados no solo con la comunicación por computadora, sino también con otros tipos de agencia. Tenemos una teoría realmente poderosa que responde las preguntas y resuelve directamente estos problemas de equilibrio de red. Son argumentos de sentido común. Es el tipo de cosas en las que podrías entrar a una escuela secundaria y hacer una configuración básica de la cosa y esperar que los niños brillantes de la escuela secundaria la obtengan.
