Actualizaciones de escalabilidad y descentralización de Ethereum

La escalabilidad está ahora a la vanguardia de la discusión técnica en la escena de las criptomonedas. La cadena de bloques de Bitcoin tiene actualmente más de 12 GB de tamaño, lo que requiere un período de varios días para que un nuevo nodo bitcoind se sincronice por completo, el conjunto UTXO que debe almacenarse en la RAM se acerca a los 500 MB y las mejoras continuas del software en el código fuente son simplemente no es suficiente para aliviar la tendencia. Con cada año que pasa, se vuelve cada vez más difícil para un usuario común ejecutar localmente un nodo de Bitcoin completamente funcional en su propio escritorio, e incluso cuando el precio, la aceptación comercial y la popularidad de Bitcoin se han disparado, la cantidad de nodos completos en la red se ha mantenido esencialmente igual desde 2011. El límite de tamaño de bloque de 1 MB actualmente pone un límite teórico a este crecimiento, pero a un alto costo: la red Bitcoin no puede procesar más de 7 transacciones por segundo. Si la popularidad de Bitcoin se multiplica por diez una vez más, entonces el límite obligará a que la tarifa de transacción aumente hasta casi un dólar, lo que hará que Bitcoin sea menos útil que Paypal. Si hay un problema que debe resolver una implementación efectiva de la criptomoneda 2.0, es este.

La razón por la que nosotros en el espacio de las criptomonedas tenemos estos problemas y estamos avanzando tan poco para encontrar una solución es que hay un problema fundamental con todos los diseños de criptomonedas que debe abordarse. De todas las diversas pruebas de trabajo, pruebas de participación y diseños de blockchain basados ​​en el consenso de reputación que se han propuesto, ninguno ha logrado superar el mismo problema central: que cada nodo completo debe procesar cada transacción. Es posible tener nodos que puedan procesar cada transacción, incluso hasta un nivel de miles de transacciones por segundo; Los sistemas centralizados como Paypal, Mastercard y los servidores bancarios lo hacen bien. Sin embargo, el problema es que se necesita una gran cantidad de recursos para configurar un servidor de este tipo, por lo que no hay ningún incentivo para que nadie, excepto algunas grandes empresas, lo haga. Una vez que eso sucede, esos pocos nodos son potencialmente vulnerables a la motivación de las ganancias y la presión regulatoria, y pueden comenzar a realizar cambios teóricamente no autorizados en el estado, como darse dinero gratis a sí mismos y a todos los demás usuarios, que dependen de esos nodos centralizados para la seguridad. no tendrían forma de probar que el bloque no es válido ya que no tienen los recursos para procesar todo el bloque.

En Ethereum, a partir de este punto, no tenemos mejoras fundamentales sobre el principio de que cada nodo completo debe procesar cada transacción. Ha habido ideas ingeniosas propuestas por varios desarrolladores de Bitcoin que involucran múltiples cadenas fusionadas con un protocolo para mover fondos de una cadena a otra, y estas serán una gran parte de nuestro esfuerzo de investigación de criptomonedas, pero en este punto investigue cómo implementar esto óptimamente aún no está maduro. Sin embargo, con la introducción de Protocolo de bloque 2.0 (BP2), tenemos un protocolo que, si bien no supera la falla fundamental de escalabilidad de la cadena de bloques, nos lleva a la mitad del camino: siempre que exista al menos un nodo completo honesto (y, por razones antispam, tenga al menos 0.01% poder minero o propiedad de éter), los “clientes ligeros” que solo descargan una pequeña cantidad de datos de la cadena de bloques pueden conservar el mismo nivel de seguridad que los nodos completos.

¿Qué es un cliente ligero?

La idea básica detrás de un cliente ligero es que, gracias a una estructura de datos presente en Bitcoin (y, en un forma modificada, Ethereum) llamado árbol de Merkle, es posible construir una prueba de que una determinada transacción está en un bloque, de modo que la prueba sea mucho más pequeña que el propio bloque. En este momento, un bloque de Bitcoin tiene un tamaño de aproximadamente 150 KB; una prueba de Merkle de una transacción es de aproximadamente medio kilobyte. Si los bloques de Bitcoin alcanzan un tamaño de 2 GB, las pruebas podrían expandirse a un kilobyte completo. Para construir una prueba, uno simplemente necesita seguir la “rama” del árbol desde la transacción hasta la raíz, y proporcionar los nodos laterales en cada paso del camino. Con este mecanismo, los clientes ligeros pueden estar seguros de que las transacciones que se les envían (o de ellos) realmente se convirtieron en un bloque.

Esto hace que sea sustancialmente más difícil para los mineros maliciosos engañar a los clientes ligeros. Si, en un mundo hipotético donde ejecutar un nodo completo fuera completamente impráctico para los usuarios comunes, un usuario quisiera afirmar que envió 10 BTC a un comerciante sin suficientes recursos para descargar el bloque completo, el comerciante no estaría indefenso; pedirían una prueba de que una transacción que les envía 10 BTC está realmente en el bloque. Si el atacante es un minero, potencialmente puede ser más sofisticado y colocar dicha transacción en un bloque, pero hacer que gaste fondos (es decir, UTXO) que en realidad no existen. Sin embargo, incluso aquí hay una defensa: el cliente ligero puede solicitar una segunda prueba de árbol de Merkle que muestre que los fondos que gasta la transacción de 10 BTC también existen, y así sucesivamente hasta una profundidad de bloque segura. Desde el punto de vista de un minero que usa un cliente ligero, esto se transforma en un protocolo de desafío-respuesta: los nodos completos que verifican las transacciones, al detectar que una transacción gastó una salida que no existe, pueden publicar un “desafío” en la red, y otros nodos (probablemente el minero de ese bloque) necesitarían publicar una “respuesta” que consiste en una prueba de árbol de Merkle que muestre que las salidas en cuestión realmente existen en algún bloque anterior. Sin embargo, hay una debilidad en este protocolo en Bitcoin: las tarifas de transacción. Un minero malintencionado puede publicar un bloque otorgándose una recompensa de 1000 BTC, y otros mineros que ejecutan clientes ligeros no tendrían forma de saber que este bloque no es válido sin sumar todas las tarifas de todas las transacciones en sí; por lo que saben, alguien más podría haber estado lo suficientemente loco como para agregar tarifas por valor de 975 BTC.

BP2

Con el Block Protocol 1.0 anterior, Ethereum era aún peor; no había forma de que un cliente ligero verificara siquiera que el árbol de estado de un bloque fuera una consecuencia válida del estado principal y la lista de transacciones. De hecho, la única forma de obtener garantías era que un nodo ejecutara cada transacción y las aplicara secuencialmente al estado principal. BP2, sin embargo, agrega algunas garantías más fuertes. Con BP2, cada bloque ahora tiene tres árboles: un árbol de estado, un árbol de transacción y un árbol de seguimiento de pila que proporciona la raíz intermedia del árbol de estado y el árbol de transacción después de cada paso. Esto permite un protocolo de desafío-respuesta que, de forma simplificada, funciona de la siguiente manera:

1. Miner M publica el bloque B. Quizás el minero sea malicioso, en cuyo caso el bloque actualiza el estado incorrectamente en algún momento.

2. El nodo ligero L recibe el bloque B y realiza comprobaciones básicas de prueba de trabajo y validez estructural en el encabezado. Si estos controles pasan, entonces L comienza a tratar el bloqueo como legítimo, aunque no confirmado.

3. El nodo completo F recibe el bloque B y comienza a realizar un proceso de verificación completo, aplicando cada transacción al estado principal y asegurándose de que cada estado intermedio coincida con el estado intermedio proporcionado por el minero. Supongamos que F encuentra una inconsistencia en el punto k. Luego, F transmite un “desafío” a la red que consiste en el hash de B y el valor k.

4. L recibe el desafío y marca temporalmente a B como poco confiable.

5. Si la afirmación de F es falsa y el bloque es válido en ese punto, entonces M puede producir una prueba de coherencia localizada mostrando una prueba de árbol de Merkle del punto k en el seguimiento de la pila, el punto k+1 en el seguimiento de la pila y el subconjunto de nodos del árbol de Merkle en el árbol de estados y transacciones que se modificaron durante el proceso de actualización de k a k+1. Luego, L puede verificar la prueba tomando la palabra de M sobre la validez del bloque hasta el punto k, ejecutando manualmente la actualización de k a k+1 (esto consiste en procesar una sola transacción) y asegurándose de que los hashes raíz coincidan con lo que M proporcionada al final. Por supuesto, L también verificaría que la prueba del árbol de Merkle para los valores en el estado k y k+1 sea válida.

6. Si la afirmación de F es cierta, entonces M no podría dar una respuesta y, después de un período de tiempo, L descartaría a B por completo.

Tenga en cuenta que actualmente el modelo es para quemar las tarifas de transacción, no distribuirlas a los mineros, por lo que no se aplica la debilidad en el protocolo de cliente ligero de Bitcoin. Sin embargo, incluso si decidiéramos cambiar esto, el protocolo se puede adaptar fácilmente para manejarlo; el seguimiento de la pila simplemente también mantendría un contador continuo de las tarifas de transacción junto con el estado y la lista de transacciones. Como medida antispam, para que el desafío de F sea válido, F debe haber extraído uno de los últimos 10000 bloques o haber tenido el 0,01 % del suministro total de éter durante al menos un período de tiempo. Si un nodo completo envía un desafío falso, lo que significa que un minero responde con éxito, los nodos ligeros pueden incluir en la lista negra la clave pública del nodo.

En conjunto, lo que esto significa es que, a diferencia de Bitcoin, Ethereum probablemente seguirá siendo completamente seguro, incluso contra ataques de emisión fraudulenta, incluso si solo existe una pequeña cantidad de nodos completos; Siempre que al menos un nodo completo sea honesto, verifique los bloques y publique desafíos cuando corresponda, los clientes ligeros pueden confiar en él para señalar qué bloques tienen fallas. Tenga en cuenta que hay una debilidad en este protocolo: ahora necesita conocer todas las transacciones con anticipación antes de procesar un bloque, y agregar nuevas transacciones requiere un esfuerzo sustancial para volver a calcular los valores intermedios de seguimiento de la pila, por lo que el proceso de producción de un bloque será más ineficiente. . Sin embargo, es posible parchear el protocolo para evitar esto y, si es posible, BP2.1 tendrá esa solución.

Minería basada en blockchain

No hemos finalizado los detalles de esto, pero es probable que Ethereum use algo similar a lo siguiente para su algoritmo de minería:

1. Sea H(i) = sha3(sha3(cabecera de bloque sin nonce) ++ nonce ++ i) for i in (0 …16)

2. Sea N el número de transacciones en el bloque.

3. Sea T(i) la (H(i) mod N)ésima transacción en el bloque.

4. Sea S el estado del bloque padre.

5. Aplique T(0) … T(15) a S, y sea S’ el estado resultante.

6. Sea x = sha3(S’.root)

7. El bloque es válido si x * dificultad <= 2^256

Esto tiene las siguientes propiedades:

1. Esto es extremadamente duro para la memoria, incluso más que Daga, ya que la minería requiere efectivamente acceso a toda la cadena de bloques. Sin embargo, es paralelizable con espacio de disco compartido, por lo que probablemente estará dominado por GPU, no dominado por CPU como Dagger esperaba originalmente.

2. Es fácil de verificar para la memoria, ya que una prueba de validez consiste solo en el subconjunto relativamente pequeño de nodos de Patricia que se usan al procesar T(0) … T(15)

3. Todos los mineros esencialmente tienen que ser nodos completos; pedir a la red datos de bloque para cada nonce es prohibitivamente lento. Por lo tanto, habrá una mayor cantidad de nodos completos en Ethereum que en Bitcoin.

4. Como resultado de (3), una de las principales motivaciones para usar grupos de minería centralizados, se anula el hecho de que permiten a los mineros operar sin descargar toda la cadena de bloques. La otra razón principal para usar grupos de minería, el hecho de que igualan la tasa de pago, se puede lograr con la misma facilidad con el p2pool descentralizado (que probablemente terminaremos apoyando con recursos de desarrollo)

5. Los ASIC para este algoritmo de minería son simultáneamente ASIC para el procesamiento de transacciones, por lo que los ASIC de Ethereum ayudarán a resolver el problema de escalabilidad.

A partir de aquí, solo se puede hacer una optimización: descubrir alguna forma de superar el obstáculo de que cada nodo completo debe procesar cada transacción. Es este un problema difícil; tomará un tiempo desarrollar una solución verdaderamente escalable y efectiva. Sin embargo, este es un buen comienzo e incluso puede terminar como uno de los ingredientes clave para una solución final.