Transcripción al español de “Whiteboard: DApps and Development”
Publicado en el canal de Youtube de Charles Hoskinson el 2 de Enero de 2022
Enlace a la versión doblada al español
Hola, este es Charles Hoskinson, transmitiendo en vivo desde la cálida y soleada Colorado, siempre cálida, siempre soleada, a veces Colorado. Es un nuevo año, 2 de Enero de 2022, va a ser un año divertido, un montón de cosas ocurrirán, un montón de cosas para aprender, un montón para hacer, construir. Y por supuesto, como he mencionado, gradualmente vamos a cambiar el formato del podcast con el tiempo, construir un estudio abajo, tener un montón de diversión con ello. Pero la otra cosa es que vamos a hacer mucha más pedagogía, mucha más educación, un montón de enseñanza. Algo será realizado por mí, algo será hecho por Lars y otros, pero para comenzar el año, el domingo, pensé que sería divertido hacer un video de pizarra, hablar de dApps, DeFi, desarrollo. Pero primero tengo unos nuevos libros, algunos de ustedes saben que estoy tratando de construir una bonita práctica de meditación, miré la lectura recomendada de Jon Kabat-Zinn, recomendó alrededor de 30 libros, estos son algunos de los 30 libros que están goteando a medida que Amazon me los envía. ¿Por qué meditar?, de Matthieu Ricard, para aquellos que lo conocen es el monje Francés que de manera heróica es conocido como la persona más feliz en vida. Si sos un master Chan, Hoof Print of the Ox, es viejo pero bueno. Luego los libros Zen siempre tienen los mejores nombres, este es de Elizabeth Hamilton, “Desentrena a tu loro”, y otras introducciones sin sentido en la huella zen, ahí tenés. Sólo una pequeña cosa lateral, bien. Vayamos a ello, ¿deberíamos no?, tengo mí café, esta va a ser una divertida, larga, pónganse los sombreros, pónganse las botas, ajústenlas, vamos a tener algo de diversión.
Bien, primero vamos a compartir la pantalla, compartir pantalla, wow, ahí vamos. Así que si realmente estás comenzando a escarbar en tener un mejor entendimiento de la experiencia de desarrollo Cardano, lo que recomiendo es comenzar con la introducción docscardano.org, está aquí, ustedes muchachos lo pueden ver en la pantalla. Básicamente cubre todo un área acerca de Plutus, Rosetta, otros componentes como tokens nativos, etc. Podés aprender acerca de Plutus, entender el modelo UTxO extendido, el modelo de libro contable, cómo trabaja Plutus, los Scripts, etc. Sí querés una introducción más profunda acerca de Plutus hay un documento escrito hace un tiempo por James Gabby y Lars Brünjes, es “Paradigmas de contratos inteligentes blockchain basados en UTxO versus Account”. Básicamente compara y contrasta a lo que la gente está acostumbrada en el mundo Ethereum, versus lo que la gente está haciendo ahora en el mundo Cardano con UTxO extendido. Leeré el abstracto para darles una idea muchachos, y la conclusión. “Implementamos dos versiones de un simple pero ilustrativo contrato inteligente, uno en Solidity, en la plataforma blockchain Ethereum y uno en Plutus en la plataforma Cardano, con extractos de código anotado y código fuente adjuntado. Tenemos una clara mirada del modelo de programación Cardano en particular introduciendo una novedosa abstracción matemática que llamamos el idealizado UTxO extendido. Para cada versión del contrato rastreamos la arquitectura de las plataformas subyacentes, sus efectos matemáticos, los estilos de programación natural, las clases de errores naturales. Hemos probado algunos simples pero nobles resultados acerca de conversión Alfa, equivalencia observacional para Cardano, y explicar por qué Cardano no las tiene. Concluimos con una amplia y detallada discusión con ejemplos de modelos matemáticos y resultados matemáticos.” Cuando vas a la conclusión de este documento, y esto fue escrito antes de que lancemos Alonzo, así que hay más incluso a esto. Básicamente la conclusión está llegando a, aquí. “Esperamos que este documento provea una precisa pero igualmente accesible punto de entrada para lectores interesados y una guía útil para algunas de las consideraciones en el área. Hemos visto que Ethereum es un sistema blockchain basado en Account mientras que Cardano, como Bitcoin, está basado en UTxO, hemos implementado una especificación en Solidity, y en Plutus. Y hemos dado una abstracción matemática en Cardano, el idealizado UTxO extendido, que levantó algunos puntos sorpresivamente no triviales. Ambos bastantes matemáticos y más de implementación, que son discutidos en el cuerpo del documento. El paradigma basado en Account, en sí mismo, se presta al estilo de programación imperativo, un contrato inteligente es un programa que manipula el estado global, mapea el estado global, entradas, cuentas, valor. El paradigma basado en UTxO se presta a sí mismo a un estilo de programación funcional, el contrato inteligente es una función que toma un UTxO, lo lista como entrada y retorna una lista UTxO como salida, sin otra dependencia.” Este es el corazón de la materia. Así que yo no soy una persona dogmática, yo creo que necesitás tener un mundo multi paradigma. Un mundo multi paradigma significa que tenés que mezclar ambos estilos, funcional e imperativo, si vas a hacer cosas útiles. Hay muchos casos, de subconjuntos de aplicaciones y expresiones donde un estilo sólo funcional podría funcionar. Pero en la práctica hay ciertas cosas que quizás es más fácil hacer en el estilo imperativo. Realmente desde el comienzo una pregunta acerca de expresividad y modelo. Así que hablemos de eso para comenzar.
La expresividad es una de esas propiedades, cuando mirás Bitcoin, el script Bitcoin, es como el modelo de cimiento de nuestra industria, porque ahí es donde comenzamos en 2009. Eso tiene esa similitud funcional, experiencia, es como un ensamblaje basado en pila, está basado en un lenguaje llamado Fourth. Básicamente tenés este modelo UTxO, tenés entradas, salidas, y esas entradas y salidas son operadas por alguna clase de función. Eso tiene todo un conjunto de términos y condiciones que están definidas por el lenguaje script. Hay una gran limitación al nivel de expresividad que tenés. Cuando vas todo al otro lado tenés cosas como la máquina virtual Java, el lenguaje común Runtime, etc, etc. Así que estos son entornos de programa completo. Tenés máxima expresividad aquí, podés ejecutar aplicaciones completas, como por ejemplo en la JVM tenés Minecraft. Un montón de cosas son construidas en C Sharp, ustedes muchachos están bastante familiarizados con eso. Luego tenés cosas como la EVM, dicen “tenemos que restringir algunas cosas, porque sino lo hacemos, y tenemos expresividad máxima, esto es demasiado abierto y por lo tanto tenemos asuntos de seguridad”. Luego mirás, ¿dónde ponés a UTxO en esta lista?, es script Bitcoin está como por acá, hay una pregunta acerca de dónde dibujás la línea, ciertamente podés replicar lo que la EVM está haciendo, podés hacerlo aquí, aquí. Una de las primeras partes de la agenda de investigación, cuando miramos tomar el modelo UTxO, porque realmente nos gusta esta idea funcional, vamos a hablar un poquito de la proposición de valor de ella. Decimos “hagámoslo un poquito más extensible”, escribimos el modelo UTxO extendido. Realmente lo que hicimos es pensar para una larga clase de aplicaciones, el punto dulce sería algo en el medio entre lo que podés hacer en estas grandes cosas, lo que podés hacer con Bitcoin, la criptomoneda más valiosa en el mundo, la más utilizada por el momento, y lo que está haciendo la EVM. Porque la pregunta es que este espacio entre estos dos, ¿se necesita realmente?, ¿son estas funciones y funcionalidad que están creando una más grande y abierta superficie de ataque realmente requeridos para DeFi?, ¿son realmente requeridos para oráculos, para monedas estables, para tus NFTs, para cualquiera de estas dApps que vemos en la industria? Porque si no son requeridas, no estás utilizando esto, pero estás pagando por ello, y estás pagando por ello de maneras muy particulares. Primero que todo, este modelo imperativo que la EVM está utilizando es muy difícil de escalar, en la práctica. La introducción de estado global, es una de las razones, pero hay otras. Así que ese es un costo, otro costo es que hay muchas cosas que podés hacer, y sólo porque no las estás haciendo no significa que un atacante, un adversario, puede explotar eso. Tenés que ser muy cuidadoso con tu expresividad. Esta es una de las razones por las que la muchedumbre Bitcoin se queda aquí. Crearon más de un trillón de dólares de valor con sus casos de uso y dicen “muchachos, cuánto más empujamos en esta dirección, sí, ganamos más programabilidad, expresividad, mayor potencial de valor, pero luego, esa apertura también crea algunos asuntos para nosotros.
De lo que se trata efectivamente el 2022, mientras construimos un ecosistema DeFi, de dApps para Cardano, es realmente preguntar qué se requiere para esto, en este nuevo modelo. Resulta que hay otras cosas que son necesarias para comenzar a replicar y emular eso. Bueno, podrías escribir CIPs, propuestas de mejoras Cardano, ya hay tres que han sido escritos en colaboración directa con proveedores DeFi, para hacer esto, incrementar la expresividad. Por lo tanto permitiendo más cosas. De eso se tratan realmente los próximos seis a nueve meses, mientras juntos construimos este ecosistema DeFi, como comunidad, es obtener ese punto dulce de expresividad, porque el UTxO extendido es un modelo completamente nuevo, nadie lo hizo antes, hicimos UTxO, nosotros inventamos el UTxO extendido, Ergo, fue el primero al mercado con este concepto. Y ya nos han dado grandes consejos y claridad. Así que nosotros dijimos “Wow, eso es algo para aprender”. Mientras ellos crecen y nosotros crecemos, estamos aprendiendo cuál necesita ser ese punto dulce.
Ahora, si nosotros preservamos ese estilo funcional, luego y localmente, osea estado local, en vez de este concepto de estado global para ser manipulado. Entonces lo que es bonito al respecto es que también obtenés un montón de seguridad, ¿por qué?. Bueno, debido a que esto es como una especie de objeto matemático, que es muy fácil de modelar, es muy fácil de entender tus precondiciones, tus post condiciones, tus invariantes, es muy fácil utilizar testeo basado en propiedades. Además es muy fácil escribir especificaciones. Y si podés escribir especificaciones podés realizar testeo basado en propiedades, podés hacer diseño por contrato, podés hacer toda clase de grandes cosas, luego podés comenzar a realizar verificación, contra aquellas especificaciones. Y esas verificaciones te permiten certificar software, contra estándares. ¿Qué significa eso?, significa que vos podés obtener una alta garantía que el contrato inteligente que ha sido implementado, es correcto. Ahora, podés hacer esto en el sentido imperativo, la gente lo hace todo el tiempo, es muy costoso, y consume mucho tiempo. ¿Cómo escribís tu código, cómo diseñás tu programa, cómo se manejan las entradas y salidas, la pureza de las funciones en el sistema, la cantidad de efectos laterales que tiene el sistema, la cantidad de cosas que el sistema puede realizar, conduce a una explosión combinacional de posibilidades, y esa explosicón de posibilidades te dice que básicamente los límites acerca de cuán costoso será obtener alta garantía de que tu software está escrito correctamente. Esta es una de las razones principales por las cuales en vez de comenzar con un modelo de estilo account, en este lado, marcando hacia atrás, como lo que hizo Ethereum, comenzar con un modelo UTxO funcional, y marcar hacia adelante. Cuando marcás hacia atrás, estás sacando, cuando marcás hacia adelante, vos estás agregando gradualmente y agregás basado en una necesidad. Y podés pensar profundamente acerca de cada una de esas necesidades en el contexto de preservar funciones que te importan, por ejemplo, costo determinístico. El costo determinístico es decir, cuando construís tu contrato inteligente, cuánto vos pensás que va a costar es de hecho cuánto termina costando, el concepto de estado local, versus global donde las cosas cambian de maneras impredecibles. Todo buen programador sabe que cuanto más puedas mantener en un mundo determinístico, y no moverse a un mundo no determinístico, mejor, porque te da mucha más certeza acerca de predictibilidad de comportamiento para un contrato.
La otra razón por la cual escogimos comenzar aquí, y luego marcar hacia adelante, en vez de comenzar aquí, y marcar hacia atrás, es debido a que a medida que escalás la expresividad, también podés modelar rendimiento muy fácilmente. Nosotros tenemos, con Bitcoin, información desde 2009, 13 años atrás, pensá al respecto, 13 años de historia aquí, de la que podemos dibujar en ese modelo particular, y entender cómo hacemos al modelo de mejor rendimiento. Hablemos de eso, primero, cuando miramos bloques, porque eso es lo que hace un sistema blockchain, son como un latido de corazón, hay un tiempo entre bloques, para hacerlos, aquí es donde ocurren las transacciones, y aquí es donde se agregan. La manera más obvia de escalar, es simplemente comenzar con los bloques, y hacerlos más grandes. Y de hecho estamos haciendo esto, con el nodo 1.3.3 vamos a retomar la agenda que comenzamos el año pasado, creo que incrementamos alrededor del 12,5%, el año pasado. Así que los bloques se volverán más grandes, esto es parte de un más grande programa de optimización. Está conducido por un equipo interdisciplinario, intercompañía, todo desde optimización de librería, eso está liderado por Gawa, hay un contratista militar, a cosas como mejorar un montón de las eficiencias del software de los nodos centrales, y la pila de red. Y cada vez que eso es realizado, los bloques se pueden hacer más grandes, bloques más grandes, más transacciones pueden entrar en los bloques. Y ese es un proceso contínuo, por ejemplo, esto, es alrededor de mediados de Enero, y una vez que ocurre, los bloques comienzan a hacerse más grandes. Y eso continúa yendo hasta que como que alcanzamos un umbral máximo que realmente está determinado por propagación, queremos, dentro de los cinco segundos, que el 95% de los pares hayan recibido el bloque. Esa es la medida empírica que estamos utilizando, así que mirás, 1 segundo, 3 segundos, 5 segundos de tiempo de propagación, y continúas incrementando el bloque hasta que llegues ahí. Se pueden realizar toneladas de cosas para optimizar eso, se pueden poner estructuras de datos, para optimizar eso, hay un montón de teoría de codificación que también puede ser utilizado para esto. Por ejemplo, escuchás términos como Fountain Codes, eso está siendo utilizado en varios lugares en la industria, hay una gran investigación de la Universidad estatal de Arizona, fue realizado por la comunidad Dash, hablaron de eso. También hay grandes documentos siendo producidos por Standford, eso es del laboratorio de David Shi. David es un profesor ahí, está estudiando e co desarrollo de prueba de participación, la pila de red, recientemente publicó un gran documento. Esa es una cosa para hacer, mejorar el ratio de propagación, optimizar, y luego podés expandir los bloques, así que eso te lleva a algún lado. Segundo, cuando mirás el costo de bloque, se ve como esta especie de latido de corazón. Esto es espacio muerto, esto es tiempo muerto. Así que si yo soy uno nodo procesador, de hecho produciendo los bloques, estos bloques aquí. Luego yo tengo una situación en la que no estoy haciendo nada en éste área, y estoy haciendo un montón de cosas aquí, oh no, y nada aquí, oh no, no mucho ahí. Pipelining es básicamente acerca de decir “hey, ¿cómo somos más inteligentes acerca de ello, acerca de Pipelining?, y hacemos cosas durante ese espacio muerto. Eso efectivamente te permite incrementar el rendimiento del sistema aún más.
Eso es lo que estamos haciendo en tándem con el incremento del tamaño del bloque, ambas cosas están ocurriendo, estamos optimizando librerías, haciendo que las cosas trabajen más rápido, optimizando el nodo central, reduciendo el tiempo de sincronización y este tipo de cosas, optimizando la pila de red, así que nuestra ventana de propagación es mejor. Podemos obtener una transmisión del 95% dentro de los cinco segundos, a pesar del hecho que los bloques se están volviendo más grandes. Luego podés darle a la gente que procesa cosas, más trabajo para realizar, durante el tiempo muerto, para simplificar el concepto de Pipelining, es una simple optimización, y también está en camino, por el equipo central. Esto está ocurriendo en paralelo al esfuerzo Pipelining.
Luego está esta pregunta de “esperá un minuto, ¿por qué no hago bloques en paralelo?, esto es algo que diseñamos con Ouroboros desde el principio, realmente queríamos hacer esto, incluso lo mencioné en mí video de pizarra en blanco de 2017. Verás a un montón de gente hablar de protocolos DAGs. Y usualmente va a este concepto de bloques clave y bloques de entrada, o algo así. Lo que ocurre es que tenés estos latidos de corazón y esos latidos de corazón están relativamente alineados y sincronizados, quizás son 20, 30 segundos. Y mientras tanto tenés una especie de proceso intermedio donde un montón de microbloques son construídos, y son colocados en diferente tipo de estructura de datos. Y de alguna forma son serializados y representados dentro de esos latidos de corazón, esos bloques clave. Escribimos un documento llamado “Cadenas Paralelas”, en 2018, que como que explicaba este concepto. También aparecimos con el concepto de endosantes de entrada en 2016, con el documento Ouroboros original. Hemos estado pensando acerca de este concepto por bastante tiempo, como también la industria, cuando ves cosas como Tangle con IOTA, verás diferentes nociones de consensos, como el consenso meta estable, que Avalanche está realizando. Y todo el mundo tiene algún concepto de “¿cómo hacemos más entre los latidos de corazón?”, verás protocolos de fragmentación que vienen, como Polyshard, trabajo de Biswana, y Ethereum 2 también está persiguiendo esto.
Así que este es realmente el santo grial, si podés lograrlo, con dos advertencias. Estás limitado por rendimiento de red, básicamente podés aumentar tus TPS tan alto como quieras ir, en este tipo de modelos, podría ser un millón de TPS, si realmente quisieras, mientras que seas capaz de transmitir eso, y la gente sea capaz de mantener eso. Así que volviendo arriba, está este asunto de propagación “¿podés propagar lo que necesitás propagar en esas ventanas, para mantener las suposiciones de seguridad de los protocolos?”. Y también es una pregunta de representación de datos, la representación de datos básicamente es “¿qué está validando la gente en la red?”. Y quizás te movés a un modelo heterogéneo, donde la gente procesando los bloques tienen una mirada diferente que el resto de la red. Pero sin embargo todavía hay responsabilidad inclusiva a través de alguna clase de estructura. Estamos examinando este tipo de cosas, por ejemplo con Mithril, donde tenés una pequeña parte de tu cadena y siempre podés verificar las cosas. Pero otros actores tienen diferentes miradas. Si haces eso, quizás seas capaz de aumentar el TPS, un montón.
El otro asunto es optimismo. Y no estoy hablando de pensar pensamientos positivos, estoy hablando de la creencia y realidad de las condiciones de red. Todos los protocolos DAG y todos los protocolos que intentan esta idea de bloques de entrada entre los latidos de corazón tienen que tener algún grado de optimismo de que la gente es honesta. Verás una letanía de ataques en la literatura de los últimos cinco años, en particular cuando la gente no es honesta en la manera en que construyen estas cosas, tenés transacciones y bloques conflictivos, cuando ocurre el paso de serialización, se juntan las cosas, el rendimiento tiende a degradar considerablemente. Es por eso que ves en un montón de estos protocolos este concepto de slashing, el concepto de pruebas de fraude, el concepto de bonos, estos otros mecanismos económicos, porque en última instancia querés mantener a la gente honesta, querés crear alguna noción de castigo, porque si no lo hacés, esos bloques de entrada a veces tendrán un ataque, serán capaces de dañar el rendimiento de la red, no permanentemente pero por un período de tiempo. En algunos casos será menos que un único protocolo fragmentado, así que de hecho no ganás nada cuando haces esto. Es por eso que pensamos tan duro acerca de la teoría con cadenas paralelas, endosantes de entrada, es por eso que pensamos tan cuidadosamente acerca de la co evolución del protocolo de prueba de participación con la pila de red, porque realmente queríamos entender cómo encajaban juntas estas piezas, y comenzamos a construir primitivos más sofisticados para responsabilidad inclusiva. No tenemos que necesariamente implementar estas cosas con Ouroboros, de hecho podría ser contra productivo, por el momento no hay medidas punitivas que tenemos que poner dentro, que requiere que la gente realice bonos, slash, que realice pruebas de fraude, etc. Pero siempre podría ser agregado para acelerar más el sistema.
Así que la pregunta es a dónde te llevan estas cosas. Hablando realisticamente, si mirás condiciones de red reales, en una red bizantina, probablemente podrías utilizar esto con Pipelining, para llevarte a alrededor de 500, 1.000 TPS con una mezcla de scripts, más transacciones regulares, llamemoslas transacciones de valor. Ahí es realmente a dónde podés ir, y a medida que evolucionás la pila de red, resolvés maneras más inteligentes de propagar, mejores representaciones de datos, esa ventana con el tiempo se puede agrandar. Y luego quizás puedas poner algunas medidas punitorias para optimizar más las cosas, especialmente si querés hacer sharding más profundo. Ahora, podés incrementar esto aún más si querés, pero la seguridad del sistema decrece, y casi siempre tu centraĺización aumenta hasta un punto donde ocasionalmente incluso tenés que resetear tu red, y no creo que eso sea una criptomoneda real, pero algunas personas en la industria están en desacuerdo, y eso está bien, la gente tomará decisiones de acuerdo a ello. Así que, ¿dónde estamos con esto?, bueno, están viniendo algunos posteos de blog, tenemos el diseño científico realizado, entendemos el espacio de diseño increíblemente bien, y luego de Pipelining, endosantes de entrada serán el tema número uno para implementar. Yo quiero ambos Pipelining, endosantes de entrada, la agenda de optimización agresiva realizada este año, Octubre, es nuestra fecha límite, porque hay tres bifurcaciones duras, una en Febrero, una en Junio, una en Octubre. Quiero estas cosas hechas estas este año, no me importa el costo, no me importa a quién haya que contratar, no me importa si es interno, externo, podrían ser millones, decenas de millones de dólares, no importa nada, tiene que ser realizado, tenemos la ciencia realizada, hicimos el trabajo duro escribiendo los documentos. Y eso es ingeniería posible, debería ser hecho, puede ser realizado, será realizado, encontraremos la manera, porque es importante. Mientras marcamos hacia adelante la expresividad del sistema, lo que ocurrirá es que vendrá más uso y utilidad, y esto realmente nos llevará de millones a billones de usuarios, realmente ya hay millones de usuarios, así cuando vayamos a decenas, cientos, eventualmente los billones, el sistema tiene que ser capaz de lidiar con esa capacidad. Hay un montón de gente, somos la criptomoneda número uno en desarrollo en el mundo, en términos de compromisos GitHub. Hay un montón de gente que se despierta todos los días, casi 15 compañías ahora, que están trabajando en esto, en muchos casos en paralelo. No hay proceso académico en esta ingeniería, que tenemos que publicar un documento, esperar por la revisión por pares, eso ya se ha publicado, ya hay casi 130 de ellos en este punto, más por venir, eso está hecho. Ahora es especificación, ingeniería, así que es un problema de codificación, es mucho más fácil de solucionar que ciencia original novedosa, así que aquí es dónde estamos para esto.
Ahora, hay más que decir sobre esto, en particular todas estas cosas, el concepto de cadena, pero toda la razón por la que realizás UTxO extendido es que debido a esa localidad y determinismo, lo hace significativamente más fácil para hacer cosas fuera de cadena. Y hay tres mecanismos para hacer eso, de los que hablaré hoy. Primero está Hydra, y este es la vieja y conocida idea de pagos y canales de estado. Hay un gran equipo aquí, están haciendo progreso fenomenal, ya hay un nodo Hydra en la red de pruebas, estamos jugando con él, haciendo cosas con él, es muy importante. Y lo que ocurrirá es que verás estas irregularidades, donde hacen más, más y más, a través de lanzamientos a lo largo del año, y no hay mucho que tenga que decirse ahí, es un proceso de rápido desarrollo, ese equipo realmente quiere ver eso saliendo. Los SPOs son un muy natural, orgánico conjunto de gente para operar y ejecutar Hydra. Lightning realmente pavimentó el camino, el problema con Lightning es que no tienen la E, no son los suficientemente expresivos, así que en la práctica es extremadamente difícil obtener Lightning funcionando con las promesas que se han realizado, es porqué le está tomando tanto tiempo a estos proveedores hacer eso. Debido a que nosotros somos más expresivos, con la E, significa que podemos hacer esto más rápido y mejor, y estamos haciendo gran progreso ahí. Así que esa es una dimensión, obtener las transacciones en una diferente red de segunda capa, procesarlas ahí, son casi sin tarifa, extremadamente barato, hay un montón de balanceo de carga que puede realizarse, hay miles de stake pools que pueden recibir y ejecutar esos canales. Habrá más y más involucrados con esto mientras nos movemos al primer, segundo, tercer, cuarto trimestre. Le dije al equipo que realmente quería ver alguna forma de Hydra 1.0 corriendo en red principal antes de fin de año, Octubre es un gran mes para nosotros. Están trabajando duro en esto, continuaremos añadiendo recursos como proyecto para asegurarnos que algo salga de aquí, porque hay tanta fruta colgando bajo para micro transacciones y pagos, y hay montón de cosas de contratos inteligentes que pueden ser realizadas en estas sub redes, que creo van a reducir la hinchazón en cadena.
Segundo, podes hacer computación fuera de cadena. Eso ya está sucediendo, sundae lo está haciendo, otra gente lo está haciendo, hay algo llamado Eigen Layer, hay docenas de proyectos que están encontrando maneras de reducir carga de computación. Hay un documento realmente genial, sólo para darte una idea de esto, llamado ACE, significa ejecución de contratos asincrónica, escrita por FTH Zurich, muy bonita universidad, Einstein fue ahí. Básicamente ejecución de contratos asincrónica es acerca de cómo vos designás fuera de cadena para hacer algo de computación, luego retornarla y sos capaz de probar que la computación fue realizada de manera correcta, dadas algunas suposiciones de confianza M, F, N. Este área a largo plazo se va a convertir, yo creo, en unas de las más grandes áreas de investigación y pensamiento, creará mercados para computación fuera de cadena. Hydra es un caso muy específico, en un diseño muy específico, tiene una superficie de diseño para micro transacciones, y patrones de contratos específicos. Aquí es un diseño más general, la superficie de diseño es mucho más acerca de escoger un grupo de personas en el que confiás, M, F, N. Hay muchos enfoques diferentes, y esto se mapea increíblemente bien con el modelo de SPOs, porque de nuevo, pueden ser un proveedor de servicios para realizar este tipo de cosas. Esto se mapea increíblemente bien con el modelo UTxO porque esto es local, es determinístico, es significativamente más fácil construir la prueba necesaria y verificar que la computación fue realizada correctamente, con o sin la red ahí, no necesitás estado global o sincronización.
Enlace a Parte 2 de 2