Prueba de participación: Mirada interior

Hay muchos artículos y debates filisteos en Internet, pero no hay suficiente información sobre los méritos. En algún momento, el autor se dio cuenta de que la mecánica y muchos matices de seguridad relacionados no son completamente entendidos incluso por muchos desarrolladores de criptomonedas. Esto se reveló en un caso real de portar la implementación de PoS para una de las criptomonedas y en la publicación posterior de información sobre las vulnerabilidades encontradas por expertos de terceros.

Este artículo será útil para todos los desarrolladores que ya han encontrado vulnerabilidades de PoS o que aún están por venir.

Horrorizado bajo el corte.

Un grano de historia

En Internet, el surgimiento de la Prueba de participación (PoS) en Peercoin se rastrea después de una discusión en uno de los foros en 2011, su posterior uso en NovaCoin y su posterior distribución en PIVX y otras horquillas de Bitcoin. Se llevó una lógica PoS bastante primitiva al kernel.cpp kernel.h / kernel.cpp , que recorre los espacios de las bifurcaciones en forma de varios módulos de Frankenstein.

El algoritmo PoS pasó por varias etapas de desarrollo, alguien les da versiones. Ahora las opciones de PoS se dividen por razones naturales, DPoS ha aparecido. Una de las soluciones más avanzadas es el protocolo Casper en Ethereum.

Cualquier blockchain requiere la generación de bloques y alguien debería tener el derecho de construir un nuevo bloque. Si el autor lo hace sin mucha competencia en una cadena de bloques como el sistema de control de versiones Git, entonces en las criptomonedas hay una lucha feroz por la recompensa del bloque dentro del marco de Prueba de trabajo (PoW): encontrar una combinación de parámetros de entrada variables seleccionando eso da un resultado correspondiente a determinado por un objetivo determinado (minería, minería).

PoS reemplaza la Prueba de trabajo (PoW) para evitar el desperdicio de recursos en la minería. En cambio, todos los parámetros de entrada están estrictamente definidos con una característica constante basada en los ahorros existentes de los titulares de monedas. Por lo tanto, se requiere PoW como punto de partida para PoS, si no recurre a varias opciones para el enriquecimiento hipotecado inicial de los creadores de la moneda.

Por qué

Ahorrar energía es tan importante para los desarrolladores y poseedores de monedas como limitar las emisiones de gases de efecto invernadero para productores y consumidores. La cruel verdad es diferente:

1. Los proyectos basados ​​en PoW están sujetos a los llamados "51 por ciento de ataques": los atacantes pueden aprovechar grandes poderes, crear una cadena paralela y luego publicarla de repente con un movimiento de monedas diferente (es decir, doble desperdicio),
2. Los mineros de PoW deben cubrir sus costos e invertir en el desarrollo de capacidades: esta es una salida directa de capital de los proyectos,
3. los propietarios de los ahorros desean mantener su poder adquisitivo mediante el aumento de capital, en lugar de considerar la inflación natural.

En un ejemplo vivo: en noviembre-diciembre de 2018 hubo intentos de ataques; luego, en diciembre-febrero, hubo un gran revuelo como la moneda más rentable para extraer en tarjetas de video; la tasa bajó de 2+ a 0.5 USD; Después de cambiar a PoS, la tasa aumentó a 1 USD en una semana y la afluencia de inversiones aumentó.

Puntos técnicos

Atención: en esta sección, estamos hablando del PoS "tradicional" en la forma como está en Peercoin, PIVX y sus tenedores.

Debe comprender que no hay centralización y contabilidad para los "puntos". En esta versión, funciona el mismo principio de suerte que en PoW.

1. Terminología

La terminología es relativamente general, pero en diferentes implementaciones sus matices son:

• Objetivo PoW - objetivo = objetivo base, generalmente 2 ^ 240 (0x0000ffff ...) dividido por la complejidad del bloque (aumenta el número de ceros al frente).
• Dificultad del bloque : la complejidad del bloque en relación con el objetivo base, determinado de manera determinante en función de la tasa de crecimiento de la cadena actual.
• UTXO - Salida de transacción no gastada , un par de un hash de transacción y un número de salida.
• CoinBase es una transacción especial con índice 0 en el bloque que contiene la recompensa.
• Stake o CoinStake es una transacción especial con el índice 1 en un bloque.
• Entrada de apuesta: UTXO que cumple con los requisitos para una apuesta por tamaño y edad.
• Modificador de juego : un parámetro calculado determinísticamente especial para cada entrada de juego .
• Stake Hash es un resultado hash que debería ser aritméticamente menor que Stake Target .
• Objetivo de estaca : lo mismo que el objetivo de PoW, pero aumentado proporcionalmente por la cantidad de Entrada de estaca en relación con la oferta mínima.
• Firma de bloque - Firma de bloque .
• Tenedor : una cadena ramificada.
• Split : uso compartido de red.
• Huérfanos : bloques descartados debido a la elección de otra alternativa.

2. Anatomía

Proceso de generación:

1. Encontramos todos los UTXO que cumplen con los requisitos de entrada de estaca
2. Encuentra el modificador de estaca.
3. Multiplicar objetivo PoW por entrada de estaca
   
   • en millonésimas de hecho, es por eso que el hashrate de 1 MH PoW sale experimentalmente igual a una moneda.
4. Obtenemos Stake Hash = H(Stake Modifier, Stake Block Time, UTXO output index, UTXO txid, Current Block Time) .
   
   • solo parámetro variable Tiempo de bloqueo actual
5. Si Stake Hash >= Stake Target , intente encontrar el Current Block Time en el rango aceptable.
   
   • debe considerar la posibilidad de desbordamientos de Stake Target cuando se multiplica por la cantidad de Stake Input según la implementación.
6. Ponemos Coinbase en tx [0] y CoinStake en tx [1].
   
   • El beneficiario de Coinbase es el mismo script (dirección) que Stake Input.
7. Firmamos el bloque.

2.1. Tiempo de bloqueo:

Es fácil ver que una estafa puede dar algún beneficio con el tiempo. El consenso estándar limita los límites inferior y superior.

Los más bajos siempre establecen el tiempo promedio de los bloques en los últimos N bloques, generalmente más de 11. Esta es la tolerancia a la inexactitud de tiempo en la generación de nodos.

El límite superior histórico se estableció para PoW con un dedo hacia el cielo a las 2 en punto. Aumentar los intervalos reduce la complejidad y hace que la rama sea menos atractiva; por lo tanto, no tiene sentido. Pero para PoS, tiene sentido.

PIVX y otros limitan el tiempo futuro a un máximo de 3 minutos. Algunos ponen una restricción más severa, pero esto crea problemas para los usuarios. Algunas implementaciones de PoS han decidido cambiar los intervalos mínimos de tiempo de bloqueo actual de un segundo a 15-16 segundos.

2.2. Modificador de apuesta:

El Stake Modifier fue concebido como un medio para dificultar la predicción y construir la cadena por delante, pero algo salió mal ...

Hay varias opciones para calcularlo: los últimos bits de bloque hash en los extremos de intervalos de tiempo especificados progresivamente, [valores no muy mal predichos de bloques anteriores, etc. En algunos lugares, parece más un código ofuscador que algo cuerdo.

El original toma un espacio de 64 intervalos. Esta brecha se divide progresivamente en 64 partes desiguales. Las fronteras se redondean a minutos. En los bordes, se seleccionan los bloques existentes y se les quita un último bit. Entonces resulta un número de 64 bits, algo similar a Nonce.

El intervalo en Peercon es de 20 minutos, pero los muchachos de PIVX decidieron que el intervalo de 1 minuto, redondeado al minuto, era lo que ordenó el médico.

En general, en algunas implementaciones como Blackcoin V2 +, todo está arreglado y el Modificador de apuesta se cuenta desde la cabeza, mientras que en Peercoin V03, PIVX, Blackcoin V1 y otras desde el bloque de Entrada de apuesta. Este último destruye casi por completo el significado. Hay una suposición de que la confusión se debió al problema banal de nombrar variables, metamorfosis adicionales y copiar y pegar sin pensar. Y el propio autor descubrió el problema bastante tarde, mientras que toda su atención se centró en la protección contra DoS. ¡No te dejes atrapar!

2.3. Firma de bloque

Dado que el hash de bloque ya no sirve como prueba de trabajo, y cualquiera puede tomar la transacción CoinStake firmada del bloque de otra persona, es necesario verificar que el bloque sea creado por el propietario de Stake. Por lo tanto, el encabezado se firma con la misma clave privada que CoinStake.

2.4. Script de salida de CoinBase y CoinStake

Los mismos scripts de salida, o como las personas llaman a las direcciones de billetera, son necesarios para preservar la privacidad y evitar vincular direcciones individuales en una billetera.

2.5 ¿Qué y dónde?

Existen diferentes variaciones sobre cómo manejan las cantidades en CoinBase y CoinStake. Lógica y motivación en un caso particular:

1. Las cantidades deben mantenerse separadas para evitar incluso la menor pérdida posible de fondos de los usuarios debido a errores de procesamiento.
2. CoinBase conserva sus 100 confirmaciones, pero CoinStake se puede gastar de inmediato, lo que por supuesto deja el riesgo de doble gasto.
   
   • ajustarse a la profundidad de los bloques también contradice la calificación de edad para su uso como entrada de estaca.
3. CoinBase y CoinStake nunca deberían entrar en mempool, y todas las transacciones basadas en ellas deberían eliminarse durante la reconstrucción de la cadena.

3. Bloques completos contra encabezados

La entrada de un nodo completo en la red comienza con la sincronización. En Bitcoin, la sincronización se basa principalmente en encabezados de bloque, como Contienen información suficiente para la verificación preliminar del consenso. Primero, se extraen encabezados relativamente pequeños y se controlan en lotes de hasta 2000 piezas desde un nodo lateral. Si la verificación inicial fue exitosa, todos los bloques se extraen en paralelo de todos los nodos conectados.

La protección contra inundaciones se basa en el hecho de que el nodo local compara el encabezado más conocido con el que tiene y solicita toda la cadena de encabezados. A medida que descarga, todo se verifica por el bajo costo del espacio en disco y la informática. Las cadenas se comparan en peso según una característica como el trabajo en cadena , que es la suma de la complejidad de cada bloque individual. Construir una cadena alternativa tan fuerte requerirá inversiones de recursos extremadamente grandes, lo que hace que los ataques sean poco prometedores.

Con PoS, este enfoque no funciona, porque Para verificar los bloques, debe procesar los bloques anteriores completos al menos hasta la edad mínima de Estaca. Las implementaciones vistas por el autor no comenzaron a pervertirse, sino que simplemente se negaron a trabajar con encabezados.

Por lo tanto, el autor implementó una descarga oportunista paralela de bloques siguiendo los encabezados, lo que aumenta significativamente la velocidad de sincronización debido al uso de todas las conexiones. Los retrasos menores ocurren solo si los pares están en diferentes cadenas; luego, la conexión se interrumpe después de un ligero tiempo de espera como en el esquema estándar. Como punto negativo, la tendencia a elegir una cadena falsa en el momento de la sincronización.

Por cierto, el cliente estándar de Bitcoin y sus horquillas han estado recogiendo el número mínimo estándar de conexiones salientes durante 8 el tiempo suficiente si algunos de ellos fallan por varias razones. Esto se ha resuelto mediante conexiones salientes asincrónicas.

4. Tenedores, divisiones y huérfanos.

Con la competencia de construcción de bloques, las cadenas alternativas de 1-2 enlaces son relativamente comunes. Las bifurcaciones más largas en redes desarrolladas ocurren naturalmente solo con fallas épicas en el consenso debido a un error de programación o una interrupción global de Internet.

Incluso con la separación, generalmente no existe una amenaza para la integridad del procesamiento de transacciones, ya que al separar bloques, todas las transacciones vuelven a mempool y ya están incluidas en otros bloques. Mempool es un repositorio temporal de transacciones después de que se crean. Mempool se guarda en el disco en versiones recientes. La recompensa por el bloque se destruye. Es por eso que se establece el número mínimo de confirmaciones (profundidad) para los premios.

Sucede que los segmentos de la red local pierden su conexión con el mundo exterior y continúan minando, suponiendo que haya una conexión con la red principal. Tales ramas generalmente no representan una amenaza debido a su debilidad natural.

El principal ataque del 51% para PoW ya se ha descrito anteriormente: es extremadamente intensivo en recursos, pero para PoS se está volviendo relativamente asequible. Por esta razón, se hace técnicamente posible producir muchas ramas de varios eslabones de la cadena. Una de las soluciones clásicas es prohibir las horquillas por debajo de cierta profundidad.

El principal problema de dicha protección es la incapacidad de los nodos de los segmentos de ermitaño para regresar independientemente al circuito principal después de un reinicio.

Por lo tanto , se implementó un enfoque para prohibir las horquillas anteriores a un cierto período de tiempo solo si la parte superior de la cadena es bastante joven.

Con un intervalo objetivo de bloques de 1 minuto, el criterio de la bifurcación anterior se eligió a la 1 hora, que corresponde aproximadamente al 60% de las confirmaciones de CoinBase, y el criterio para la juventud de la corona a los 15 minutos es más de 3 veces mayor que el retraso máximo del bloque estadístico.

5. Bloquear y dividir hash

En PoW, un hash de bloque cubre completamente todos los datos. También se utiliza para verificar el objetivo. En PoS, Stake Hash es un valor separado porque Es necesario excluir la posibilidad de su selección. Esto abre la amenaza principal: la capacidad de producir una cantidad ilimitada de versiones diferentes del bloque basadas en la misma Estaca coincidente, que es fácil de inundar y colocar la red o sus nodos individuales.

Los enfoques de defensa ingenuos dan lugar a vulnerabilidades divididas aún más graves. Uno de estos enfoques en diferentes variaciones es permitir el uso de la entrada de estaca solo una vez. Un ataque simple es enviar diferentes bloques a diferentes nodos, lo que inmediatamente crea una división suave.

Es aún más fatal exacerbar esto con una prohibición de DoS, que dividirá no solo las cadenas, sino la red misma en diferentes segmentos.

Surgen otros problemas: la incapacidad de usar Stake desde un bloque caído.

Por lo tanto , se eligió el método del acelerador como la solución más segura: la misma apuesta no se puede usar más de una vez por minuto. La lógica es simple: un ataque puede durar solo en el intervalo de 1 hora (ver la bifurcación anterior), para lo cual es posible inundar no más de 60 bloques. En el mejor de los casos, en el siguiente bloque, la red ya se moverá a un solo circuito. En el peor de los casos, con un ataque continuo, esto sucederá en una hora. La probabilidad del peor de los casos: encontrar varios bloques en una fila, se está derritiendo exponencialmente.

De todos modos, quedan algunos puntos en los que los nodos son vulnerables a una inundación moderada hasta el momento de la sincronización completa .

6. Edad mínima

Para algunos, esta limitación es desconcertante, pero es extremadamente importante para la estabilidad de la red, ya que Este parámetro está directamente relacionado con la longitud máxima de la red alternativa, que el nodo local podrá verificar sin distorsiones técnicas serias.

Como se mencionó anteriormente, el nodo local debe procesar todos los bloques hasta el límite de tiempo para poder verificar que la Entrada de estaca a) tiene un lugar para estar b) es realmente UTXO y no se ha gastado.

Verifique que esto sea posible solo a través de la funcionalidad del llamado. CoinView, que es el estado de movimiento de las monedas en el momento de un bloque en particular: la parte superior de la cadena principal en la comprensión del nodo local.

La implementación de una prueba completa de circuitos alternativos a intervalos de tiempo o incluso de una manera especial guardada por CoinView parece poco prometedora, porque El número de estas cadenas alternativas es infinitamente grande.

Una barra demasiado grande para el límite de edad de UTXO afecta negativamente a los usuarios que desean gastar o combinar parte de sus monedas.

Si especifica este borde en la profundidad de los bloques, entonces es posible una situación hipotética de estancamiento de una parada de cadena completa debido al hecho de que no hay un UTXO adecuado. En el caso de las unidades de tiempo, se produce al menos algún movimiento.

Por lo tanto , se utiliza una opción equilibrada de 1 hora en otras redes en unidades absolutas de tiempo, en lugar de la profundidad de los bloques.

7. ¿Qué es mejor que N UTXO por la cantidad mínima o un UTXO con N total?

Aquí la analogía se plantea a sí misma: lo mejor es una pistola con una precisión de 0.9 o tres pistolas con una precisión de 0.3, pero con probabilidades del orden de 1/2 ^ 20, los resultados de tales cálculos parecerían nivelados. Un pequeño mapa confunde la madurez de calificación.

La creencia actual de que muchas transacciones pequeñas encuentran más bloques probablemente se remonta a cuando la edad de la entrada de estaca también se tuvo en cuenta para determinar el peso. En aquel entonces, las pequeñas transacciones viejas realmente tenían mucho sentido.

Por el momento, en base a experimentos prácticos y cálculos teóricos, los grupos agrupados en grandes UTXO traen más bloques. Además, menos UTXO requiere menos trabajo de CPU. Alguien dice lo contrario.

Así que piensa por ti mismo.

8. Ejecución de bloques hacia adelante

Los mineros de PoS naturalmente superan un poco los tiempos de bloqueo. Esto afecta la complejidad de la red para peor. El código estándar de Bitcoin selecciona el primer bloque recibido, independientemente del tiempo indicado en él. La mayoría de las implementaciones de PoS hacen lo mismo.

Por lo tanto, la lógica del minero PoS se modificó para comenzar la selección a partir del tiempo promedio de los bloques si el tiempo del bloque actual avanzaba. Al mismo tiempo, antes de comparar el orden, los nodos comparan el tiempo indicado de los bloques. El minero PoS envía el bloque encontrado a la red incluso si ve que está generando una bifurcación.

De esta manera, la red también está protegida contra bloques hipotéticos enviados prematuramente cuya entrada de estaca no se puede usar en los próximos 60 segundos con el mismo modificador de estaca debido a la protección DoS. Como un doble castigo por hacer trampa con el tiempo.

9. Una pequeña lista de verificación

1. La entrada de apuesta debe ser UTXO válida antes del punto de bifurcación:
   
   • en el caso de la cadena principal, el punto de horquilla es la punta,
   • en el caso de un circuito alternativo: UTXO después del punto de bifurcación puede conducir a auto-DoS al cambiar,
   • UTXO no debe estar en mempool por sí mismo.
2. No acepte CoinStake en mempool al reconstruir el circuito principal:
   
   • Lo mismo sucede con CoinBase,
   • Esto puede destruir la cadena de transacciones (poco probable).
3. No acepte tenedores de bloques viejos si la parte superior está bastante viva.
4. El límite de edad en unidades de tiempo absoluto para la entrada de estaca es necesario para la estabilidad y la seguridad.
5. Stake Hash solo debe cambiar a partir del tiempo de bloqueo.
6. El modificador de estaca no debe estar vinculado al bloque de entrada de estaca.
7. Trabajar con encabezados de bloque requiere un procesamiento especial en la red y durante la reindexación.
8. CoinStake se registran en la billetera local y requieren algunos cambios para mostrar correctamente a los huérfanos.
9. Los mineros de PoS probablemente tengan suficientes jambas y necesiten finalizar con un archivo.
10. Re-indexar necesita ser mejorado, porque Funciona por analogía con los encabezados: primero carga y verifica solo el índice de bloques, y luego solo trata de procesar los bloques.
11. Si la transición a PoS no está codificada, sino a través de spork, entonces debe atraparlo en el arranque, porque los sporks no se guardan.
12. Los puntos de control en Dash y Bitcoin son casi una farsa y requieren una revisión muy seria.
13. Si la bifurcación Dash es hasta la versión 0.13, entonces hay problemas con el procesamiento de datos de masternode en el modo de usuario simple.
    
    • Con el reinicio frecuente del cliente, la vista de red se distorsiona.
    • Es mejor ignorar el caché si se ejecuta en modo gráfico.
14. Cambie la selección del mejor bloque teniendo en cuenta el tiempo de bloqueo.
15. Bitcoin .
16. mempool CoinStake .

. mainnet PoW , , PoS, . PoS Ethereum Casper'.

GPU - — ethminer'. 150-200 GH (ethash). - PoS .

PoS PIVX 2.x " ". - PIVX , , . , PIVX 2.x . Dash 0.12 Bitcoin'.

, PoS . , , .

La documentación

. . whitepaper -.

PoS PIVX Bitcoin/Dash. CoinStake . PoS .

, Stake Modifier Stake Hash , Stake Input . - , - PIVX .

— . :

1. .
2. .
3. — .. , .
4. , - , .

. spork' , .

, . spork' .

PoS

, - . spork, , .

, .. . , .

testnet, .

testnet 3 1 mainnet, .

PoW , PoS - , 1e6 PoW.

. mainnet Stake Input.

.

PoS

X spork PoS . - , .

. , . .

, , .

Stake Modifier . . PIVX - … , , Ethereum, .

Conclusión

- , . , PoS , . .

: - .

GitHub