¿Qué es el modo de poda de luz de paridad?

Parity ofrece cuatro métodos de poda diferentes: archivo, básico, rápido y ligero:

  --pruning METHOD         Configure pruning of the state/storage trie. METHOD
                           may be one of auto, archive, basic, fast, light:
                           archive - keep all state trie data. No pruning.
                           basic - reference count in disk DB. Slow but light.
                           fast - maintain journal overlay. Fast but 50MB used.
                           light - early merges with partial tracking. Fast
                           and light. Experimental!
                           auto - use the method most recently synced or
                           default to archive if none synced [default: auto].

Acabo de probar archiveporque tengo suficiente espacio y tiempo para hacer una sincronización completa. Se compara con un tamaño de cadena geth como el siguiente:

 ~ $ du -hs .parity/
17G .parity/
 ~ $ du -hs .ethereum/
15G .ethereum/

Ahora, veo archiveque será más o menos como la sincronización predeterminada en eth o geth. Pero ¿qué es basic, qué es light? ¿Y es fastel mismo nivel que geth --fast?

¿Qué es el modo de poda de luz de paridad? ¿Es esto ya para ser considerado como un cliente ligero?

Respuestas (2)

geth y parity tienen diferentes métodos para guardar la cadena de bloques ethereum en su formato interno. Hice muchos bancos porque me parece demasiado largo solo para usar una billetera.

El modo de poda es cómo se guardan los datos del bloque. Con el modo de archivo, todos los estados se guardan. Entonces, conoces el estado en cada momento sin tener que recargar toda la cadena de bloques. Con fast and light, asumimos que no necesitamos toda esta información sino solo el estado actual y algunos anteriores, por lo que eliminamos muchos estados intermedios.

En geth , el método --fast guarda un estado de la cadena de bloques en el bloque B[-1500] y todos los estados después de este bloque (B[-1] es el último bloque, B[-2] es el anterior al último bloque. ..). Entonces es posible rebobinar en el estado de 1500 últimos bloques. Con una cadena de bloques completa, puede hacerlo para todos los bloques.

En paridad, hay 4 modos de poda o algoritmos journalDB :

  • Archive (Archivo): como archivo geth mantenemos todos los estados
  • Fast (OverlayRecent): como geth Fast mantenemos todos los estados completos de los bloques B[-i]
  • Light (EarlyMerge): mantenemos todos los estados de los bloques B[-i] pero en diferencial (por lo que es más pequeño que el acceso rápido pero más lento)
  • Básico (RefCounted): mantenemos todos los estados de los bloques B[-i] como con OverlayRecent pero eliminamos los estados después de x cambios... así que solo tenemos los xésimos últimos cambios

Puntos de referencia realizados en i7 3720QM 16GB ram con Geth 1.4.4 (Homestead con bloques 1.6Mi)

_____________________________________________
| Option | Disk Used | Time | Disk Written  |
|--------|-----------|------|---------------|
| none   | 19.GB     | 5h00 | 1TB           |
| fast   | 3.7GB     | 1h00 | 100GB         |
---------------------------------------------

Puntos de referencia realizados en i7 3720QM 16GB ram con Geth 1.5.0 inestable (Homestead con bloques de 1.6Mi encontrados en https://gitter.im/ethereum/go-ethereum?at=574d26c010f0fed86f49b32f )

__________________________________________________
| command     | Disk Used | Time | Disk Written  |
|-------------|-----------|------|---------------|
| geth        | 21GB      | 5h00 | 150GB         |
| geth --fast | 4.2GB     | 21m  | 35GB          |
| geth export | 1.5GB     | 10m  |               |
| geth import | 21GB      | 3h30 |               |
--------------------------------------------------

Puntos de referencia realizados en i7 3720QM 16GB ram con Parity 1.2 (Homestead con bloques 1.6Mi)

_____________________________________________
| Option | Disk Used | Time | Disk Written  |
|--------|-----------|------|---------------|
| archive| 19.GB     | 2h00 | 300GB         |
| fast   | 3.7GB     | 1h30 | 20GB          |
| light  | 2.5GB     | 2h00 | 130GB         |
---------------------------------------------

Nota: cuando tiene un nodo con una cadena de bloques, puede volcar los datos de la cadena del directorio geth para usarlo con sus otras computadoras. Lo compruebo con Linux, Windows y OS X.

Nota: si usa --cache con 1024, podría ser más rápido. Pero no es significativo en mi sistema. Lo mismo ocurre con --jitvm

Nota: la cadena de bloques de ethereum guardó el estado final después de las transacciones, pero es más seguro reproducir las transacciones para verificarlas.

¿Qué es esta abreviatura "Ir"? ¿Supongo que es "Gb"?
Lo siento toque francés. Ir es GB
Tengo curiosidad, ¿cómo mediste el "Disco escrito"?
actualizacion realizada. gracias

Con cada bloque el estado (contratos de almacenamiento y saldos) va cambiando. Por defecto ( archive) mantenemos en la base de datos el estado completo de cada bloque.

Con diferentes algoritmos de poda, estamos desechando los datos de estado de los bloques antiguos manteniendo solo las partes que se necesitan. basic/fast/lightson solo varios enfoques para ese problema con diferentes compensaciones.

geth --fastes la implementación de PV63 ( https://github.com/ethereum/wiki/wiki/Ethereum-Wire-Protocol ): en lugar de procesar cada bloque anterior, simplemente lo descargamos de otros pares, lo que da como resultado un tiempo de sincronización inicial mucho más rápido. No está relacionado con la poda.

El cliente ligero ( https://github.com/ethereum/wiki/wiki/Light-client-protocol ) también es algo diferente. En lugar de procesar (y conservar) datos sobre toda la cadena de bloques, los clientes ligeros solo procesarán partes del estado que les conciernen.

¿Qué es el modo de poda de luz de paridad?
RespuestasAquíPolítica de privacidad1y, 0v