Un primer paso es hacer un profiling de los distinto módulos de la aplicación para ver en que parte se esta usando el tiempo de procesamiento.
Lo ideal es hacer un profiling de cada módulo aislado y optimizar ahí. Pero también es importante un profiling en conjunto de toda la aplicación funcionando pues pueden surgir otros problemas durante el uso habitual.
Esto puede implicar cambiar los tipos de datos a formas más optimizadas de representación. Si se usa mucho tiempo en formatear objetos a JSON y volverlos a parsear, una representación binaria puede disminuir los tiempos considerablemente.
Encontrar algoritmos no óptimos, por ejemplo un algoritmo de orden O(n^2) en un caso de tests con pocas transacciones puede no mostrar problemas, pero en un test con bloques reales se puede apreciar el aumento de tiempo.
En particular en Ethereum un problema importante es el acceso a disco. La representación de los datos de Ethereum World State requiere la actualización continua de un Patricia Trie.
Dado el tamaño actual del World State y la continua modificación requiere un ancho de banda de disco muy importante.
Una optimización implementada en la última versión de geth es mantener el procesamiento del Patricia Trie en memoria todo lo posible, y solo serializar a disco cada N bloques o una determinada cantidad de nodos fue modificada.
Una primera aproximación al problema es realizar estadísticas de uso de las transacciones en la mainnet.
- Tipos de transacciones más usadas: Transferencias, Creación de smart contracts, Transferencia de Tokens.
- Tipos de smart contracts más usados: Tokens, Multisig Wallets, Games, etc.
- Tiempos de procesamiento de cada bloque.
- Tiempos de procesamiento por tipo de smart contract.
Una vez analizados los tipos de transacciones más usados y el tiempo que demora procesar las transacciones, el foco sería analizar el procesamiento de los contratos más usado.
En particular un profiling para ver que patrones de uso generan problemas. Es posible que un contrato use algún patrón no óptimo, se puede reportar al dueño y ver si es corregible.
Un patrón común que aparece es que un contrato con mucho uso es bastante local en el tiempo. Una optimización posible es mantener una cache de contratos precompilados. Una problema aquí es asegurarse que la ejecución sea segura y no cause inconvenientes con el resto del nodo.
La ejecución normal es interpretada esto aisla la ejecución del resto del cliente. Pero en el caso de un contrato precompilado malicioso esto puede tirar abajo todo el cliente.
-
Demora imporante en la sincronización inicial:
En el modo normal esto implicaría tener que procesar todas las transacciones de todos los bloques desde el génesis.
Parity y luego geth implementaron un modo "fast" que evitar procesar transacciones de bloques muy viejos, a cambio de descargar el World State de otros nodos.
El incremento del uso de la blockchain causa que el World State incremente notablemente de tamaño causando demoras. Una solución puede ser implementar "snapshots" del World State cada N bloques, que permite a los nuevos nodos sincronizar muy rápido. Un problema de esto es que hay que ver medidas de seguridad para que se pueda verificar la autenticidad y que no dependa sólo del nodo de donde se esta descargando.
-
Representación de datos en disco:
Un problema presente en geth y otros clientes es que la representación de datos en disco no es lo suficientemente resistente a caidas del sistema. En un caso si el cliente termina de manera abrupta puede dejar datos corruptos, en el mejor de los casos al reiniciar se da cuenta, pero no los puede arreglar o volver a una versión anterior y se necesita una resincronización.