Autor: PolkaWorld

Gavin Wood, cofundador de Ethereum, creador de Polkadot y promotor de la visión de Web3.

Antes de empezar formalmente, ¡compartamos algunas de las citas de Gavin en esta parte!

¿Cuál es el mayor logro de Ethereum hasta ahora? — Tal vez sea CryptoKitties, no lo sé, en realidad no estoy muy seguro. He oído que Ethereum creó más millonarios que nunca en la historia.

¿Es Ethereum un proyecto exitoso? — ¿Según mis estándares de éxito? Claramente no todos los estándares se cumplen, y puede que solo una pequeña parte se cumpla. Por supuesto, es exitoso financieramente.

Con la introducción de JAM, la dirección de Polkadot ha cambiado. Puede considerarse como una cadena de alojamiento Rollup de diseño nativo, y la tecnología que desarrollamos es muy superior a los Rollups optimistas y Rollups de conocimiento cero en Ethereum.

¿Cuál es el mayor logro de Polkadot hasta ahora? — Lograr una cadena de bloques fragmentada segura.

¿Cuál es el mayor problema que enfrenta Polkadot hoy? — Precisamente la fragmentación.

¿Cómo resolver estos problemas? — JAM

¡Sigue leyendo para ver todo el contenido!

¿Cuál es el mayor logro de Ethereum hasta ahora?

Kevin: ¿Entonces dices que cofundaste Ethereum en 2014? ¿Por qué te uniste como cofundador y CTO?

Gavin: Sentí que era una oportunidad única, me di cuenta de inmediato de que debía aprovecharla y dedicarme a ello por completo. Quizás no necesariamente para toda la vida, pero al menos durante un tiempo considerable. Este es un proyecto innovador que surgió en el momento adecuado, con algunas personas en el equipo que son excepcionalmente talentosas y enfocadas, y también un mercado pequeño pero interesado en nuevas cosas y dispuesto a intentar. Francamente, estoy muy curioso acerca de este proyecto, creo que tiene un gran potencial para desarrollarse muy lejos y, al menos, contribuir a los principios de liberalismo que entiendo.

Kevin: ¿Qué es eso?

Gavin: Básicamente, es una perspectiva optimista sobre la sociedad y el desarrollo, un pensamiento que probablemente surgió en Occidente hace unos cuatro o cinco siglos.

Kevin: ¿Cuál es el mayor logro de Ethereum hasta ahora?

Gavin: Tal vez sea CryptoKitties, no lo sé, en realidad no estoy muy seguro. He oído que Ethereum creó más millonarios que nunca en la historia. Tal vez porque había muchas personas participando en la crowdfunding, y el precio aumentó lo suficiente después. Así que tal vez esa sea su mayor contribución. Pero, para ser honesto, es difícil decir cuánto realmente ha logrado en términos útiles. Definitivamente no ha alcanzado lo que esperaba de él hace 10 años.

Kevin: Entonces, si te pregunto, ¿crees que Ethereum es un proyecto exitoso? ¿Tu respuesta sería negativa?

Gavin: Mi respuesta es, ¿personalmente creo que es exitoso? Si lo veo según mis estándares de éxito, claramente no todos se cumplen, y puede que solo una pequeña parte se cumpla. Por supuesto, es exitoso financieramente. Creo que tal vez uno o dos de los cofundadores de Ethereum inicialmente esperaban que funcionara mejor.

Kevin: ¿Qué estándares te harían considerarlo exitoso?

Gavin: Utilidad (Utility)

Kevin: ¿Cómo mides la utilidad?

Gavin: La forma de medir la utilidad es ver cuántas cosas pueden hacer las personas ahora que no podían hacer en el pasado.

Kevin: ¿No es esto un problema de toda la industria cripto, y no solo de Ethereum?

Gavin: Ciertamente. Este es un problema que enfrenta toda la industria cripto. En 2014 y 2015, planteamos muchas ideas para tratar de desbloquear algunos campos económicos que antes eran inaccesibles a través de un enfoque de 'sin confianza'. Uno de mis ejemplos favoritos es la cadena de suministro. Por ejemplo, cuando vas al supermercado, todos los productos tienen un código QR que puedes escanear para conocer todos los componentes de ese producto: cuándo, dónde y en qué cantidad, etc. Me gustaría saber de dónde proviene el algodón cuando compro una camiseta.

Ahora, es muy difícil de lograr en un modelo centralizado y costoso. Pero creo que es posible hacerlo de manera descentralizada. Sin embargo, esa aplicación no se ha implementado realmente. Actualmente, aunque hay algunos proyectos cripto relacionados con la cadena de suministro, son muy nicho y están limitados a áreas de mercado específicas. No ha cumplido con la promesa en esa dirección.

Y no se trata solo del problema de la cadena de suministro, creo que la imaginación en la industria cripto es rica, pero es difícil convertir esas visiones en acciones reales y aplicaciones de mercado reales, lo cual es realmente lamentable. Creo que la razón principal no es un problema técnico, aunque la tecnología ciertamente está detrás de nuestras ideas, especialmente la tecnología subyacente que necesita grandes mejoras. Por eso estoy trabajando en JAM ahora, tratando de mejorar la tecnología subyacente para que pueda respaldar aquellas ideas que considero valiosas y ayudar a la industria cripto a tener un mayor impacto.

Pero simplemente mejorar la tecnología no es suficiente. También necesitas hacer que las personas entiendan su valor. Y eso es difícil, en parte porque estás luchando con la economía de la atención.

¿Por qué salir de Ethereum?

Kevin: ¿Por qué dejaste Ethereum en 2016?

Gavin: En realidad fue a finales de 2015. En ese momento decidimos que Ethereum necesitaba hacer muchas cosas para ser más ampliamente adoptado. Estábamos buscando inversión externa, y una de las formas más obvias de hacerlo era fundar una startup relacionada con Ethereum y buscar financiamiento externo para ella. Esto fue decidido inicialmente por Vitalik y Jeff (desarrollador principal e ingeniero).

Más tarde, Jeff no se adaptó muy bien a la vida de startup. De hecho, pronto dejó Ethereum para seguir su carrera en los videojuegos. De esta manera, solo quedó Vitalik. Vitalik sintió que era necesario seguir en la Fundación Ethereum y desempeñar un papel más académico, al tiempo que actuaba como asesor de la empresa filial que habíamos fundado, Ethcore.

Recaudamos algunos fondos en ese momento y llevamos aproximadamente la mitad del equipo técnico de la Fundación Ethereum a Ethcore y desarrollamos un cliente de Ethereum. Mi salida de la Fundación Ethereum a finales de 2015 fue, de hecho, para fundar esta empresa filial, con el objetivo de agregar una entidad respaldada por capital privado al ecosistema de Ethereum.

Sin embargo, realmente dejé el ecosistema de Ethereum por completo a finales de 2017, cuando fundé Polkadot.

Polkadot está desarrollando una tecnología Rollup

Kevin: Si tuvieras que explicarle a tu mamá qué es Polkadot, ¿cómo lo harías?

Gavin: Bueno... Polkadot ha cambiado en los últimos años. La visión inicial era integrar diferentes arquitecturas de blockchain para que pudieran ser compatibles entre sí y compartir el mismo marco de seguridad. A través de este marco de seguridad compartido, se puede mejorar significativamente la eficiencia económica. Por ejemplo, si se diseña adecuadamente, se puede proteger 100 cadenas al mismo costo, en lugar de que cada cadena necesite protección independiente como en otros diseños (como Cosmos).

A lo largo de los años, Polkadot ha intentado diferenciarse en este aspecto de Cosmos. Porque en el modelo de Cosmos, cada cadena tiene que asumir su propia seguridad. Mientras que Polkadot aborda este problema a través de la seguridad compartida. Pero, lamentablemente, ambas en realidad están resolviendo problemas muy diferentes. Mirando hacia atrás, tal vez preferiría describir Polkadot como un 'sistema de fragmentación' en lugar de un 'sistema multi-cadena'. Esta descripción resulta ser crucial al explicar y comunicar la idea central de Polkadot, especialmente al comunicarse o promover Polkadot, esta distinción ayuda a describir sus características técnicas y sus diferencias con otros proyectos (como Cosmos).

Ahora, con la introducción de JAM, ha habido algunos cambios en esta dirección. La tecnología que estamos desarrollando para Polkadot puede considerarse una tecnología Rollup, y Polkadot en sí puede considerarse una cadena de alojamiento Rollup diseñada específicamente. El desarrollo y diseño de esta tecnología no es sencillo, por lo que no es sorprendente que veamos que otras dos tecnologías competidoras están muy por detrás de lo que hemos desarrollado para Polkadot. Específicamente, los Rollups optimistas y los Rollups de conocimiento cero, ambas tecnologías que ya se utilizan en Ethereum. Por lo tanto, podemos describir a Polkadot como una cadena de alojamiento Rollup nativa, aunque probablemente esta descripción no sea la adecuada para explicárselo a mamá, pero es aceptable para aquellos que tienen algún conocimiento del campo cripto.

A través de JAM, el próximo objetivo de desarrollo de Polkadot, estamos tratando de transformar Polkadot de un modelo multi-cadena a un modelo de recursos de computación más universal. En el modelo multi-cadena, las diferentes cadenas de Polkadot (en el ecosistema de Polkadot llamadas cadenas paralelas) comparten el mismo marco de seguridad y pueden interactuar entre sí. En el nuevo modelo, nuestro objetivo es ampliar aún más el alcance de Polkadot, de la misma manera que Ethereum expandió las funciones básicas de Bitcoin en un recurso de computación universal. Queremos eliminar las restricciones de diseño subjetivas excesivas para que Polkadot pueda soportar un uso más amplio.

Entonces, ¿cuál es el futuro de Polkadot? Fundamentalmente, se convertirá en una gran computadora compartida que siempre funcionará de la manera que esperas. En esta computadora compartida, puedes subir programas para ejecutar, estos programas pueden ser servicios que resuelven problemas específicos. Dado que es una computadora compartida, estos servicios pueden colaborar y coordinarse entre sí.

La clave es que se trata de una única gran computadora compartida. Lo que no queremos hacer es dividirla en diferentes partes, y que esas partes no puedan interactuar realmente entre sí.

El mayor logro de Polkadot hasta ahora es su mayor problema

Kevin: Creo que te refieres a un hecho que todos sabemos, y que en el ecosistema de Ethereum de hoy realmente ha causado mucha confusión. Entonces, ¿cuál es el mayor logro de Polkadot hasta ahora?

Gavin: Lograr una cadena de bloques fragmentada segura.

Kevin: ¿Cuál es el mayor problema que enfrenta Polkadot hoy?

Gavin: Es la fragmentación.

Kevin: ¿Qué significa eso exactamente?

La fragmentación siempre se ha considerado el 'Santo Grial' de la escalabilidad de blockchain, su concepto proviene del diseño de bases de datos. En una base de datos, puedes dividir una base de datos (esencialmente un conjunto de registros) en múltiples fragmentos. Cada fragmento opera de manera independiente, y solo puede interactuar entre fragmentos en algunas interfaces muy específicas, por ejemplo, un registro puede moverse de un fragmento a otro.

Un ejemplo físico simple puede ayudar a entenderlo. Imagina una oficina de los años 60, como la consulta de un médico, donde hay registros médicos de pacientes. Estos registros suelen estar almacenados en viejos cajones. Si solo hay registros de 20 personas, tal vez un cajón sea suficiente y sea fácil organizarlos alfabéticamente. Pero si los registros superan la capacidad de un cajón, como si hay más personas, necesitarás distribuir los registros en varios cajones. Si el número de cajones sigue aumentando, digamos que necesitas cuatro o cinco cajones, entonces necesitarás varios archivadores.

Cada cajón del archivador puede considerarse un fragmento. Funcionan de manera independiente: puedes abrir un cajón sin abrir los otros, y puedes buscar en un cajón sin tener que revisar todos los cajones. Esto contrasta con tener un cajón que es especialmente largo (como un cajón de 10 metros). Si solo tuvieras un cajón largo, sería evidentemente poco práctico, porque necesitarías una sala de 10 metros para acomodarlo. Y cuando intentas encontrar a alguien cuyo nombre comienza con 'W', tendrías que sacar todo el cajón y recorrerlo hasta la posición de 'W', lo cual es claramente ineficiente.

Por lo tanto, desde esta perspectiva, el diseño de fragmentación es razonable. Sin embargo, también presenta problemas. Por ejemplo, ¿qué pasa si un cajón se llena? Quizás necesites reajustar la distribución de los registros, como cambiar los registros que originalmente iban de A a E a A a D, y mover los registros que comienzan con E al siguiente cajón. Pero esto puede llevar a que el siguiente cajón también se llene, por lo que necesitarías reajustar, y en cada reajuste tendrías que cambiar la etiqueta fuera del cajón. Todo este proceso puede volverse complicado y engorroso.

Así que la fragmentación también trae consigo su propia serie de problemas.

La clave es que estos 'cajones' (fragmentos) funcionan de manera independiente, tanto en el diseño de blockchain fragmentada como en el diseño de bases de datos. Esencialmente, los datos se mantienen fragmentados una vez que se dividen, a menos que realices una operación muy especial, lo que generalmente es muy lento, costoso y requiere muchos recursos, para mover registros o datos de un cajón (fragmento) a otro. Esto significa que reorganizar registros dentro de un cajón puede ser fácil, pero reorganizar registros entre diferentes cajones es muy difícil. Ese es el problema de la fragmentación. Para los datos, este problema puede no ser grave, por eso la fragmentación es ampliamente utilizada en el diseño de bases de datos. Pero para los servicios, como los contratos inteligentes que necesitan interactuar y cambiar con frecuencia, este enfoque no es ideal. Si los contratos inteligentes se consideran objetos en un cajón y deseas que un contrato inteligente en un cajón interactúe con otro en otro cajón, necesitarás abrir ambos cajones al mismo tiempo. Esto significa que necesitas sacar ambos cajones, conectarlos entre sí, realizar todas las interacciones necesarias para los contratos inteligentes y luego separarlos y devolverlos a sus respectivos cajones. Este proceso es complejo e ineficiente, muy inapropiado para aplicaciones que requieren interacciones frecuentes.

Si solo estás operando entre dos cajones, ya es difícil, pero si deseas que múltiples cajones interactúen al mismo tiempo, se vuelve extremadamente complejo y complicado. Uno de los problemas de hacerlo de esta manera es que impides la libre interacción entre los cajones, lo que significa que otros contratos inteligentes en esos cajones solo pueden seguir este único patrón de interacción. Todo el sistema rápidamente se vuelve complejo, difícil e ineficiente.

Otra forma de hacerlo es permitir que los cajones se comuniquen entre sí enviando mensajes. Un cajón (fragmento) puede publicar un mensaje, que más tarde se transmitirá a otro cajón. Eso es precisamente lo que Polkadot hace utilizando XCM (Cross-Consensus Messaging). Aunque este enfoque puede funcionar, el problema es que no puede lograr ese tipo de interacción estrecha, eficiente y flexible, y no es tan fluido como cuando todo funciona en el mismo espacio o 'parque de diversiones'.

Por ejemplo, supón que una escuela tiene cuatro parques de diversiones diferentes, que corresponden a cuatro blockchains diferentes. Si estás jugando al juego de 'escondite' en uno de los parques, eso no es un problema, el juego puede desarrollarse sin problemas. Pero si necesitas jugar 'escondite' entre dos parques, se vuelve muy complicado. Necesitarías enviar un mensaje al otro parque, diciendo 'ahora soy el que busca, si entras en esta área, te atraparé.' Y el jugador del otro parque necesita saberlo, pero no puede entender completamente, y rápidamente el juego se volverá confuso.

Así que, 'escondite' es un juego que solo se puede jugar en el mismo parque. Este es precisamente el problema entre los fragmentos, la interacción entre fragmentos es como intentar jugar un juego entre parques, lo que dificulta la eficiencia.

Si algunas soluciones deben funcionar de manera muy asíncrona, hacer que funcionen correctamente se vuelve muy complicado. Es como jugar solo a través de mensajes. Si es un juego como el ajedrez, tal vez no sea tan difícil; pero si es un juego como 'escondite', eso es prácticamente imposible.

En los contratos inteligentes también es una situación similar. Algunos contratos inteligentes no son demasiado difíciles de operar en este modo, puede que solo sean un poco más lentos que el normal, pero no hay problema. Y hay algunos escenarios, como la verificación de identidad (KYC), que son relativamente simples. Por ejemplo, es posible que tengas una cadena dedicada a la verificación de identidad y otra cadena que maneje transferencias. La cadena de transferencias puede necesitar confirmar si la dirección objetivo ha pasado la verificación de KYC y AML antes de ejecutar la transferencia. Puede enviar un mensaje preguntando '¿ha pasado esta dirección la verificación de KYC y AML?' La cadena de verificación de identidad puede responder 'sí', y luego la cadena de transferencias ejecuta la transferencia. Todo el proceso puede tardar unos segundos más, pero no es un gran problema.

Sin embargo, hay otros casos de uso, como los intercambios descentralizados (DEX), que son mucho más complejos. Por ejemplo, necesitas consultar el precio actual y luego decidir si comerciar. En ese momento, puede que necesites enviar un mensaje a otra cadena, y esa otra cadena responde diciendo 'el precio actual es este, la transacción se puede realizar de esta manera.' Luego el mensaje regresa a la cadena original, que confirma 'acepto este precio, por favor ejecuta la transacción.' Pero cuando la transacción está a punto de ejecutarse, la otra cadena puede decir 'el precio ha cambiado, ahora es este precio.' Los mensajes irán y volverán, y rápidamente todo el proceso se volverá muy ineficiente, incluso puede que no se complete de manera efectiva.

Así que, en tales casos, las transacciones deben completarse prácticamente al mismo tiempo, de lo contrario, no se pueden llevar a cabo. Este fenómeno es similar a los juegos que se juegan en un parque. Algunos juegos, como 'escondite', solo se pueden completar dentro del mismo espacio, la interacción asíncrona hará que el juego sea completamente imposible.

La solución es JAM

Kevin: ¿Cuál es la solución viable?

Gavin: Bueno, JAM es mi propuesta, que significa Join Accumulate Machine (Máquina de Conexión y Acumulación).

Kevin: ¿Qué es JAM?

Gavin: JAM es una forma flexible que puede reunir a los jugadores de diferentes 'parques' y crear un parque temporal donde pueden jugar al escondite. Aquí hay un ejemplo improvisado (puede ser un poco loco, lo siento). Siguiendo con el ejemplo de 'escondite': supón que originalmente hay cuatro parques fijos, en el diseño de JAM, ya no hay parques fijos.

Los parques ya no son fijos, y los jugadores ya no están atados a un parque específico, y el costo de moverse entre diferentes parques no será tan alto. En cambio, tenemos un amplio área de juego donde los parques pueden formarse y desaparecer rápidamente. En este caso, nos enfocaremos en los jugadores en el juego, agrupando temporalmente a aquellos que están cerca unos de otros y que podrían 'atraparse', creando un parque temporal donde pueden seguir jugando al escondite.

Cuando algunos de los jugadores salen de este parque temporal, ajustaremos la ubicación del parque, redefiniendo el alcance del nuevo parque según los jugadores que aún estén cerca unos de otros. Si algunos jugadores están muy lejos entre sí, sabemos que no se 'atraparán' en el corto plazo, por lo que no necesitan participar en este parque. Están temporalmente en un estado 'fuera del juego' hasta que se acerquen a otros jugadores y necesiten participar en el juego, momento en el cual serán incluidos en el nuevo parque.

Si implementamos el sistema de esta manera más flexible, podemos imaginar un sistema que pueda escalar y soportar combinaciones sincrónicas. Su núcleo es que no se fragmentará permanentemente lo que se llama 'estado'. En otras palabras, los jugadores no estarán fijos en un parque específico, sino que se agruparán dinámicamente en tiempo real según sea necesario. El sistema clasificará a los jugadores en diferentes grupos según las necesidades reales y avanzará en el juego según esos grupos.

En el contexto de los contratos inteligentes, la implementación de este concepto es similar a poner todos los contratos inteligentes en un gran 'horno' compartido, pero este horno no está diseñado para que todos los contratos interactúen todo el tiempo, sino que puede dividirse dinámicamente. Por ejemplo, el sistema puede extraer 10, 50 o 2 contratos inteligentes de este horno, combinarlos y hacer que interactúen y funcionen sincrónicamente, luego separarlos. Luego se reevaluará, seleccionando otro conjunto diferente de contratos inteligentes, combinándolos nuevamente y luego separándolos.

Este enfoque nos permite manejar múltiples grupos de contratos inteligentes en paralelo al mismo tiempo, en lugar de solo permitir que un grupo de contratos inteligentes se combine y ejecute sincrónicamente. A través de este método de procesamiento paralelo, podemos aumentar significativamente la capacidad de manejo de interacciones del sistema, soportando cientos de veces más interacciones que los métodos tradicionales, logrando así una verdadera escalabilidad.

#ETH