La velocidad siempre será el rey en un mundo de DAPP

La velocidad siempre será el rey en un mundo de DAPP. Satoshi Nakamoto inició una increíble era de innovación para aplicaciones de Internet descentralizadas con la introducción de Bitcoin como un sistema de pago digital peer-to-peer.
Blockchain, la tecnología subyacente a Bitcoin y otras criptomonedas, facilita la formación de redes descentralizadas y sin confianza capaces de manejar transacciones y datos de forma segura.
Las últimas décadas han sido testigos de una irresponsabilidad a gran escala por parte de las corporaciones financieras tradicionales de los bancos -que necesitaban ser rescatados en 2008 - a agencias de información crediticia como Equifax, que fue objeto de una de las mayores violaciones de datos de consumidores de la historia. No es de extrañar que la confianza en las instituciones financieras centralizadas se haya erosionado tan rápidamente.
A medida que los usuarios exigen más soberanía, seguridad y control sobre sus vidas financieras, es sólo cuestión de tiempo antes de que los DAPP basados en blockchain empiecen a suplantar aplicaciones más tradicionales.
Sin embargo, esta transición a una Internet más descentralizada no es inevitable. Antes de que los propietarios de dispositivos puedan elegir DApps en lugar de aplicaciones, estas aplicaciones descentralizadas deben funcionar al igual que su competencia. Esto se reduce a un factor clave: la velocidad. Y en la cadena de bloques, la velocidad está limitada por lo rápido que podemos lograr el consenso en una red sin confianza. DApps necesitan sus plataformas de blockchain subyacentes para formar consenso de forma rápida, segura y a una fracción del costo actual.
El consenso no es solo para blockchains
El consenso es el proceso por el cual las entidades llegan a un acuerdo a lo largo del tiempo y el espacio. Todas las aplicaciones basadas en Internet deben llegar a un consenso para funcionar.
De hecho, siempre que necesite combinar varias líneas de cálculo juntas, necesita un mecanismo de consenso, ya sea que su aplicación se ejecute en Internet o en un único PC multi-core.
En algunos contextos, se utiliza el término “sincronización” en lugar de “consenso”, pero los significados son esencialmente los mismos.
Los modernos procesadores multinúcleo, ya sean fabricados por Intel o por cualquier otra persona, utilizan instrucciones especiales para garantizar que los núcleos de procesador formen consenso sobre el contenido de la memoria. Estas instrucciones se denominan barreras de memoria o vallas de memoria. La famosa estructura MapReduce de Google se ejecuta en millones de núcleos en decenas de miles de máquinas cada día.
MapReduce resuelve una amplia variedad de problemas prácticos para Google. Sin embargo, MapReduce se basa en un sistema de sincronización llamado Chubby para obtener consenso sobre qué partes del cálculo existen y cómo deben recombinarse.
Aunque parte de este lenguaje puede ser nuevo para aquellos menos familiarizados con la infraestructura de Internet, las aplicaciones no lo son. Cuando usas Google Docs, los distintos ordenadores que ven el mismo documento están llegando a un consenso constante. Hacer una compra en una plataforma de proveedores, publicar en redes sociales, jugar un juego en línea — todas estas acciones requieren lograr el consenso entre diferentes dispositivos y entidades.
La diferencia entre las aplicaciones y los DAPP es que las aplicaciones pueden llegar a un acuerdo remitiéndose de nuevo a una autoridad centralizada. En el ejemplo de Google Docs, la autoridad central es Google.
Si compras un artículo en Amazon, la autoridad es Amazon. Si juegas a Overwatch, la autoridad es Overwatch. Entienes la idea. Cuando hay una sola fuente de verdad, el acuerdo se puede lograr muy, muy rápidamente. Pero, todos deben confiar en esa fuente de verdad para ser honestos.
Y en la época actual, extender ese nivel de confianza a las autoridades centrales es menos atractivo que nunca.
Los DAPP deben ser más creativos para llegar a un consenso
No existe una autoridad central en una red descentralizada, por lo que los DAPP tienen que encontrar un acuerdo de manera más creativa. La gran pregunta que deben responder todos los sistemas descentralizados es: “¿Quién debe estar a cargo de validar una transacción determinada?”
Prueba de trabajo y prueba de estaca son dos mecanismos comunes que usan las cadenas de bloques para determinar quién (mineros en prueba de trabajo y validadores en prueba de estaca) es responsable de crear un bloque de transacciones y transmitir eso al resto de la red.
Los protocolos de prueba de trabajo piden a los mineros que compitan para resolver un problema matemático muy difícil. Resolver tal problema requiere una cantidad extraordinaria de infraestructura informática y enormes cantidades de electricidad. Para incentivar a la gente a realizar esta función esencial pero costosa, el minero ganador adquiere criptomoneda como recompensa.
Algunos protocolos de prueba de estaca delegan los validadores de una manera determinista, a menudo en función del número de tokens mantenidos. Los protocolos de prueba de estaca son más variados en su comportamiento que la prueba de trabajo.
En el modelo delegado de prueba de estaca operado en la red EOS, un pequeño número de nodos maestros se turnan produciendo bloques. Esto es rápido, pero mucho más centralizado que Bitcoin.
Otros protocolos de prueba de estaca proponen formas alternativas de lograr la velocidad sin sacrificar la descentralización, pero muchos aún no se han implementado y probado en el mundo real.
Las cadenas de bloques de prueba de trabajo como Bitcoin y Ethereum son increíblemente lentas e ineficientes, porque la creación de bloques depende del consumo de enormes cantidades de electricidad.
Bitcoin ya consume tanta energía como los países de Grecia, Israel y Bangladesh. En términos de velocidad, Bitcoin procesa aproximadamente 7 transacciones por segundo, mientras que Ethereum puede procesar aproximadamente 15. A modo de comparación, Visa es capaz de procesar 45.000 transacciones por segundo. A partir de ahora, los dos blockchains más conocidos simplemente no son lo suficientemente rápidos y usan demasiada energía.
¿Cómo se puede escalar DApps?
Los DAPP deben ser más rápidos y eficientes desde el punto de vista energético para satisfacer las necesidades de millones de usuarios de Internet con la facilidad y conveniencia que se esperan. Aunque está claro que la prueba de trabajo es demasiado lenta e ineficiente desde el punto de vista energético, sigue siendo demasiado pronto para estar seguro de que la prueba de riesgo es la respuesta.
Algunos ataques a las cadenas de prueba de participación pueden ser más baratos de ejecutar sin las debidas salvaguardias. Casper - inventado por el fundador de Ethereum Vitalik Buterin - tiene la intención de abordar este problema castigando económicamente a los validadores de mal comportamiento mediante la eliminación de sus tokens depositados.
Pero Casper es conocido por tener grandes defectos en su capacidad para alcanzar el consenso correctamente. Además, dada la necesidad de lograr rendimientos extremadamente altos, parece natural que el ancho de banda de un sistema sea al menos tan importante como la cantidad de tokens mantenidos al determinar la importancia de un nodo particular en la red.
En última instancia, si queremos construir aplicaciones distribuidas verdaderamente robustas, incluyendo blockchains capaces de procesar transacciones financieras, entonces tenemos que obtener la capa de consenso correcta. Ya no podemos confiar en algoritmos a medias que carecen de buenas pruebas.
Ya no podemos confiar en implementaciones que no tienen ninguna verificación formal. Los algoritmos correctos son algoritmos rápidos, y los algoritmos de consenso rápido afectarán a todo el ecosistema del software de Internet.
Por Nash Foster, CEO de Pyrofex
(En divulgación, el equipo que dirijo en Pyrofex está desarrollando una solución llamada CDDelta, que utilizará el protocolo de consenso optimista de Casanova).
Acerca de Nash Foster:
Nash Foster, CEO y cofundador de Pyrofex, cuenta con más de 20 años de experiencia en la industria informática y ha trabajado en el personal de ingeniería de Google, Oracle, Counterpane, iBiblio y muchos otros. Nash estudió matemáticas y la teoría de la computación en la Universidad de Carolina del Norte y la Universidad George Mason. Ha ayudado a las empresas de Fortune 100 a diseñar, implementar y administrar redes y aplicaciones de red de forma segura.