Enlace a la versión doblada al español
Además aquí está la transcripción completa, traducida y revisada para el Canal Cardano Castellano
Transcripción completa
Doblaje al español de “Behind the Blockchain Part IV: Involving the Community with Innovation”
Publicado en el canal de Youtube de IOHK el 19 de Octubre 2024
Esta posibilidad de involucrar a la comunidad y al implementador en la elección de diseño y de tener una discusión con ellos: qué objetivo deberíamos perseguir, qué piensa la comunidad al respecto, qué quiere lograr la comunidad. Darles suficiente poder lo suficientemente temprano en el proceso, para que al final del día no sea una actualización del protocolo, sino una actualización realmente comunitaria.
Trabajamos en ciclos e intentamos hacerlo de manera ágil, comunicándonos mucho con las partes interesadas. Uno de las cosas que hemos realizado hasta ahora es tener uno de los artefactos principales, no eran sólo prototipos,números, modelos, uno de los principales productos que obtuvimos de nuestro primer ciclo de trabajo en Peras es el reporte técnico que hemos construido con el equipo. Lo compartimos con todo el grupo de interesados en Peras, al principio internamente, porque Peras era más un proceso interno. Este informe técnico trata de agregar juntos los diversos hallazgos. Queremos profundizar en eso, mencionamos ese proceso del nivel de preparación de software, y queremos ser precisos sobre qué hicimos, qué encontramos y qué necesitamos hacer a continuación, y cuáles son las otras preguntas, las otras áreas que necesitan ser investigadas. Y solo para dar un ejemplo, creo que uno de los resultados de los primeros informes técnicos y de la primera ronda de, diría, los primeros dos o tres meses que trabajamos en Peras fue que sabíamos que una de las grandes áreas en las que teníamos que invertir era la cuestión de los certificados y los votos, y qué es un voto de Peras, qué es un certificado Peras, porque esto es obvio, este es un ingrediente crítico en el sistema, y es la forma en que lo construimos, el tamaño, la CPU y todas estas cosas deben estar indicadas. Así que ese es uno de los resultados que incluimos en el informe técnico, y también para informar a los posibles implementadores aguas abajo sobre lo que deben tener en cuenta, y creo que esa es una forma en que tenemos que comunicar los resultados de esta corriente de innovación.
Supongo que un punto crítico aquí también es explicar por qué o dónde están los beneficios. Sí, sí, y para mí siempre puedes decir que una confirmación rápida es buena, es bueno tenerla, ¿por qué no? También es bueno explicar por qué, en particular si sigues este tipo de protocolos de asentamiento o de cadena más larga. Puedes decir, “Okay, una transacción está asentada si sabes que mientras más bloques se construyen sobre ella, menos probable es que se revierta”, ¿verdad? Entonces, si compras algo caro, la persona que te vende los bienes debería esperar un poco más, y si es algo pequeño, tal vez esté bien si ingresa en el mempool o el primer bloque. Es como una evaluación de riesgos dependiente del usuario, pero si ahora miramos el ecosistema más amplio y miramos cadenas asociadas o puentes entre Cardano y otros sistemas, como cuando el otro sistema tiene que decir cuándo algo es final, no es un solo usuario vendiendo un automóvil caro o algunos dulces que no son tan caros, es más bien que decides para otro ecosistema completo cuándo debe considerar algo asentado en Cardano.
Para esto, es muy importante que ofrezcamos una confirmación más rápida.
Y si te equivocas, podría ser catastrófico para el otro ecosistema, ¿verdad? Como si hubiera algo que debieras bloquear en el lado de Cardano o incluso quemar o lo que sea, y luego comienzas a hacer cosas en el otro lado y se revierte, entonces el otro lado tiene un problema. Y creo que es interesante que, a través de este proceso de innovación, porque estamos tratando de ser muy abiertos sobre lo que estamos haciendo y tratando de trabajar de la manera más transparente posible, es interesante ver que personas del ecosistema de cadenas socio, por ejemplo, vienen a nosotros diciendo, "Oh, sí… ¿cuáles son los números que podemos esperar? Y ahora tienes que dar una respuesta, esto obliga tanto a la investigación como a la innovación a intentar decir, "ok, ¿cuáles son los números?
Exacto" y deben ser precisos, no sabes cómo se verá eventualmente el sistema de producción, pero necesitas estar en un estado donde tengas mucha confianza en que los números que reportas estarán en el orden correcto en el que se estabilizarán las cosas al final. De lo contrario, construirías sobre promesas falsas, así que tenemos que hacer todo en nuestro poder para asegurar que reportamos números en los que se puedan basar decisiones cruciales.
Con este proceso de innovación, algo con lo que hemos tenido dificultades en el pasado es cuando vas directamente a la implementación e intentas pasar de la idea a construir el código que estará en producción, omitiendo toda esta fase que te permite tener confianza en cualquier cifra y proporcionar retroalimentación más rápidamente que si intentaras alcanzar el producto final directamente. Entonces, tener este ciclo de iteración en innovación nos permite dar más retroalimentación a los usuarios, decirles dónde estamos, qué podemos hacer, cuáles son las opciones disponibles. Es algo de lo que no hemos podido beneficiarnos lo suficiente en Peras, pero es algo que queremos cubrir en el futuro.Esta posibilidad de involucrar a la comunidad y a los implementadores en la elección de diseño y de tener una discusión con ellos compartiendo el prototipo que tenemos, compartiendo todas las inquietudes y diciendo “ok, aquí es donde estamos en este momento, tenemos diferentes opciones sobre la mesa, estas son las compensaciones que hemos considerado para estas diferentes compensaciones; ¿qué objetivo deberíamos perseguir? ¿qué piensa la comunidad al respecto? ¿qué quiere lograr la comunidad?”
Hacer las cosas de esta manera también es una forma de involucrar a la comunidad y darle suficiente poder lo suficientemente temprano en el proceso para que al final del día no sea una actualización del protocolo, sino una actualización de la comunidad.
Creo que es importante mencionar dos cosas muy prácticas al respecto. Ahora que se está estableciendo Intersect, ya tenemos el proceso CIP que ha estado activo durante un tiempo en la comunidad, y ha dado lugar a algunas innovaciones interesantes. Sin embargo, lo que hemos visto a veces es que cuando tienes un CIP, muy bueno en investigación, algo que es muy teórico, pasar directamente de la investigación a un CIP es muy difícil porque las posibilidades de que alguien pueda implementarlo o que alguien al azar comience a trabajar en su implementación son prácticamente nulas debido a esta necesidad de traducción.
Uno de los resultados que realmente esperamos alcanzar pronto es estar en la posición de presentar un CIP para Peras que sea lo suficientemente preciso y sin ambigüedades, que contenga todos esos números que mencionaste, para que cualquiera pueda implementar Peras en cualquier lenguaje o nodo, porque tienes una especificación, que no es teórica, está respaldada por un prototipo y un modelo de red con números y todas estas cosas que proporcionamos, y llegar a ese punto es algo muy importante, porque eso fomentará la posibilidad de que la comunidad en general comience a interactuar con esto de una manera estructurada.
También nos estamos comprometiendo, ¿verdad? Se puede ver el rastro de lo que nos llevó a decir lo que decimos, y luego uno puede cuestionarlo. No podemos simplemente cambiar cosas y decir “oh, no queríamos decir eso”. Nos estamos comprometiendo, exactamente, y aquí están nuestros hallazgos, para que puedan tomar una decisión basada en ellos, y nosotros apoyamos esto.
Permitiendo tener discusiones significativas.
Si realmente llegamos a ese punto,
Uno de los resultados de Peras que me gustaría lograr es tener algún tipo de modelo aplicable con el que la gente pueda experimentar, modificar los parámetros y decir “ok, esto funcionaría”, y luego podrían criticar ese modelo.“Oh, eso no tiene sentido”, por la razón que sea, si un parámetro se establece demasiado alto, podría afectar los beneficios o el consumo de recursos sería demasiado alto o lo que sea.
Pero poner en manos de la comunidad en general una herramienta que puedan usar para evaluar cuál es el valor, porque si les damos a todos el documento, yo diría que es como leer, a Hegel, si no tienes ninguna formación en filosofía puedes leerlo, cualquiera puede leer a Hegel, pero entender a Hegel está realmente fuera de alcance, o sea, personalmente, no puedo.
Es algo que es bastante importante en esta fase del CIP. Tener un CIP más detallado no significa que la gente tendrá menos poder para tener un impacto en él; de hecho, es lo contrario, porque cuantos más detalles tengas en el CIP, más fácil es discutir esos detalles y tener un impacto en ellos. Si tienes un CIP que es muy vago, no podrás, como dijiste, tener una discusión significativa al respecto porque, bueno, es lo suficientemente vago como para que todos puedan estar de acuerdo en el contenido, porque el contenido no proporciona ningún detalle sobre el que tengas que debatir
Exactamente. Y luego las discusiones a menudo evolucionan sobre cómo tú entiendes versus cómo yo entiendo, es como, si hay un problema o no. Sí, correcto, tal vez sí. Solo con este nivel de detalle tendremos, podremos, en la comunidad, tener una discusión que tenga un impacto real, porque como dijiste, al tener algo que es muy detallado será bastante directo de implementar. Bueno, ‘directo’ probablemente sea una palabra fuerte, pero al menos tienes suficientes conocimientos sobre lo que necesitas implementar.
Hay una referencia, una especificación que tienes que satisfacer, ¿verdad? Esa es la llamada; entonces tienes que implementar esto y esto es una especificación, por lo que sea lo que sea que hagas debe cumplir con ella y la propuesta, y luego obtienes los beneficios que se prometen.
Y realmente, para entrar un poco en el meta de todo esto, una de las cosas que estamos tratando de hacer aquí dentro de Peras, como una especie de esfuerzo inicial, es realmente involucrarnos con no toda la comunidad, sino unos pocos, quiero decir, las personas más activas de la comunidad, para tratar de obtener de ellos qué sería lo más útil para ellos realmente. Y creo que estamos comenzando ese proceso y estamos obteniendo respuestas interesantes. La gente estaría dispuesta a recibir una especificación formal, pero también quieren diagramas, también quieren tener ejemplos, cosas concretas que puedan seguir, porque eso les ayuda. Y lo peor, y algo que a veces es difícil, es la ingeniería inversa de código, por lo que si ponemos eso en esta parte superior sería muy útil. Y también, sí, como mencionaste en términos de una de las cosas que también estamos tratando de producir, es algún tipo de pruebas de conformidad. Creo que esa es una de las cosas que también queremos obtener de un modelo de especificación formal. Si quieres, cualquiera podría escribir una implementación y ahora tienes incluso un conjunto de pruebas de conformidad que te ayudará a guiar tu código’.