[Spanish] Casper Version 1 Implementation guide

Segundo plano

En esta especificación, propuesta para la 1 fase de Casper, Ethereum pasará de la prueba de trabajo pura a PoW/PoS híbrido. En este esquema, todas las mecánicas de prueba de trabajo continuarán existiendo, pero se agregarán mecánicas adicionales de la prueba de participación, y la regla de la elección de la bifurcación (es decir, la forma en la que un cliente determina qué cadena es "la cadena clásica") se modificará para tener en cuenta estos mecanismos.

Se publicará un "contrato Casper" en alguna dirección CASPER_ADDR, y este contrato incluirá la funcionalidad que permite a cualquier persona depositar su Ether, especificando una parte del "código de validación" (piense en esto, algo así como una clave pública) que ellos usarán para firmar mensajes y convertirse en un validador. Una vez que un usuario es incluido en el grupo de validador activo, podrá enviar mensajes para participar en el proceso de consenso de PoS. El "tamaño" de un validador en el grupo validador activo, se refiere, a la cantidad de Ether que depositaron.

El propósito del proceso de consenso de PoS es "finalizar" los bloques de claves llamados "puntos de control". Cada centésimo bloque es un punto de control. Para que un bloque finalice, un subconjunto de validadores en el conjunto de validadores activos, con un tamaño total de al menos, dos tercios del tamaño total del grupo validador debe enviar mensajes de "confirmación" para ese punto de control. Una vez que se finaliza un bloque, la teoría es que "uno nunca puede volver atrás"; incluso si el 99% de los mineros comienza a apoyar una cadena que no contiene ese bloque, los clientes seguirán aceptando ese bloque como finalizado.

El contrato implementa un conjunto de reglas llamadas "condiciones de corte"; estas reglas fueron cuidadosamente diseñadas para tener la propiedad, de que si finalizan dos bloques incompatibles (por ejemplo, A y B se finalizan donde A y B son ambos hijos de C), entonces no importa cómo surja tal situación, DEBE existir algún conjunto de validadores, con un tamaño total, igual a, al menos 1/3 de algún conjunto validador activo reciente, que envió mensajes que desencadenan alguna condición de corte. Si un validador hace esto, entonces se puede enviar "evidencia" de este hecho al contrato de Casper, y el depósito al completo del validador se destruirá (excepto el 4% que se entrega al remitente de la evidencia como una "tarifa de buscador"). Por lo tanto, revertir un bloque finalizado es extremadamente costoso, probablemente más costoso, que el costo de comprar hardware de minería suficiente para involucrarse repetidamente en el 51% de ataques contra la actual cadena de Ethereum exclusiva de PoW.

Implementación

Hay dos partes en la puesta en funcionamiento de la primera fase para la implementación en Ethereum de Casper-friendly:

1. Una implementación de la "regla de la elección de la bifurcación", la función que determina qué es la "cadena clásica". Este es el reemplazo de la "regla de la cadena más larga" en PoW.
2. Un "demonio" (o un paquete de software integrado) que implementa la lógica necesaria para ser un validador de Casper.

Regla de la elección de la bifurcación

Para cada punto de control, mantenga la siguiente información:

• parent: El punto de control principal (es decir, el ancestro número 100)
• commit_frac: El porcentaje de validadores que se han comprometido (o, más precisamente la salida de get_main_hash_committed_frac(), delimitada por encima de 2/3)
• pow_head: El bloque que es un descendiente del punto de control, y está en el mismo período que el punto de control (es decir, es como máximo un descendiente de grado 99), con la mayor dificultad total.
• max_td: La dificultad total de pow_head
• score = commit_frac + epsilon * max_td
• subtree_score: La puntuación (score) más alta de este punto de control o cualquiera de sus descendientes.
• preferred_child: El punto de control del menor con el más alto subtree_score
• preferred_child_subtree_score: El subtree_score del preferred_child

Cuando reciba un nuevo punto de control o bloque, actualice estos registros para el punto de control (para un bloque, actualice pow_head y max_td para el punto de control que es el ancestro más reciente de ese bloque). Si el bloque contiene prepares o confirmaciones, actualice commit_frac y score. Supongamos que, el nuevo score que calcula es S. Luego desciende recursivamente al punto de control padre, y sigue estableciendo subtree_score = S hasta que encuentre un punto de control donde subtree_score >= S; detente ahí. Mientras desciende, actualice preferred_child y preferred_child_subtree_score según sea necesario (es decir, si S > preferred_child_subtree_score, luego configure preferred_child para ser el elemento secundario del punto de control actual que está visitando, y configure preferred_child_subtree_score = S). Con estos datos guardados, siempre puede subir los punteros de preferred_child desde el génesis para encontrar el encabezado. Sin embargo, esto toma O(n) veces, por lo que si queremos que las cabeceras sean inmediatamente accesible, debemos almacenar el head_checkpoint (el verdadero encabezado de la cadena es head_checkpoint.pow_head). Para mantener el head_checkpoint actualizado, después del paso de actualización anterior, puede caminar de regreso al ancestro común de head y al punto de control más antiguo visitado, y subir punteros de preferred_child desde allí para encontrar el nuevo encabezado.

Validación lógica

Los validadores necesitarán poder:

• Almacenar el último período en el que se prepararon, y el último período en el que se comprometieron, para asegurarse de que no infrinjan las condiciones de corte.
• Prepárese cuando sea necesario, usando el período correcto como justificación.
• Comprometerse cuando sea necesario.
• Depositar Ether, y detectar su índice de validación.
• Retirar Ether.
• Emitir mensajes de preparación y confirmación, y aceptar e incluir en los bloques, los mensajes de preparación y confirmación de otros validadores.