Transcripción al español de un fragmento de “September Cardano development update”
Del minuto 00:00:00 al 00:15:45 del video original
Publicado en el canal de Youtube de IOHK el 30 de Septiembre de 2020
Enlace a la versión doblada al español
Tim: Hola a todo el mundo y bienvenidos al show de Septiembre y feliz cumpleaños Cardano, creo que todavía lo podemos decir, tres años y contando, muchos llamados de celebración y también mucho contenido hoy, Aparna tenemos una una edición de cumpleaños.
Aparna: Absolutamente Tim, un par de horas de contenido, hemos trabajado en esto por un tiempo, así que creo que deberíamos seguir adelante y empezar a sumergirnos en ello.
Tim: Fechas, hablemos de fechas, es la pregunta de muchas personas, es un cumpleaños, todo se trata de las fechas, ¿vamos a compartir fechas detalladas de la hoja de ruta hoy?
Aparna: Bueno, no es exactamente detallada, pero definitivamente vamos a compartir algunas fechas, como dijimos, hay mucho contenido en el programa, tenemos constante impulso hacia adelante con ello, así que no van a ser fechas detalladas de la hoja de ruta en sí, pero obtendrás algunas fechas para un par de áreas clave que tenemos.
Tim: Hay un montón de partes móviles ocurriendo aquí, ¿cierto?
Aparna: Sí y sabes, y esto es específicamente para Goguen, hay mucho “¿cuándo Goguen?”, pero me gustaría centrarme más en el ¿qué es Goguen? y en el ¿por qué estamos haciendo Goguen?, e incluso el ¿cómo?, porque estas son las cosas que van a hacer que el producto sea exitoso a largo plazo. Así que Goguen tiene múltiples áreas, múltiples partes, y no sólo estamos trabajando en Goguen, tenemos mucho ocurriendo con Voltaire, como ustedes chicos han estado viendo, dos mil quinientas personas registradas para el proyecto Catalyst, un gran éxito ahí para Fund2. También hay cosas en la porción de identidad, hay experiencias que estamos haciendo con Shelley para los delegadores y los operadores de stake pools, hay actualizaciones Daedalus, hay asociaciones, marketing y todo lo que estamos haciendo bajo el capó, así que sí, muchas partes móviles, es cierto.
Tim: Así que Goguen continúa desplegándose en las tres fases de las que hemos hablado en el pasado, esa todavía es la forma en que lo desplegamos, ¿es así?
Aparna: Sí, técnicamente hay tres fases, bueno, en cierto modo hay casi cuatro, está la pieza de metadatos que comienza primero, es un poco de Shelley, pero hablaremos de eso en el programa, luego está la pieza del libro contable multi activos, antes de entrar en la verdadera política monetaria con Plutus, y luego hay otra pieza que como que está ahí fuera en términos de usabilidad, desde el punto de vista de la aplicación, y eso es Marlowe y también hablaremos de eso en este programa. Sin embargo, no es sólo eso desde un punto de vista de tecnología, de producto, también se trata de ¿cómo lo estamos haciendo? Por ejemplo, está el abordaje de desarrolladores, y el ángulo de marketing, ¿cómo conseguimos desarrolladores en la plataforma?, en lo que estamos trabajando con la CF, para permitir eso. Luego hay una experiencia de desarrollador, eso es alrededor de patios de juego y ¿cómo recogemos la voz del cliente?, o en este caso, la voz del desarrollador, para que los desarrolladores vengan, trabajen en casos de uso, jueguen con el código y nos digan si nos estamos moviendo en la dirección correcta, ¿qué necesitamos para ayudarlos a llegar ahí? También está la utilidad, por ejemplo, ERC20, va a haber alguna discusión sobre eso durante el programa. Plataformas y marcos de testeo, ¿cómo proporcionamos herramientas de testeo robustas para que los desarrolladores codifiquen? Y finalmente utilidad en términos de desarrolladores que no son “haskellers” o que no quieren ir por ese camino y más orientado en casos de uso, así que ya sean contratos financieros o si es otro tipo de cosa, tal vez código legal, un método más fácil de juntar contratos inteligentes, esa porción también, así que la experiencia del usuario, múltiples fases, múltiples despliegues diferentes, múltiples corrientes Tim.
Tim: Antes de entrar en eso, vamos a tocar el tema de Shelley y dar una actualización de donde estamos, porque por supuesto no ha terminado todavía, Shelley sigue evolucionando, mejorando, optimizando. Lo estuvimos mirando desde un par de ángulos diferentes, acerca de cómo movemos esa experiencia hacia adelante.
Aparna: Sí y eso se trata todo sobre el usuario, así que desde una perspectiva de gestión de productos nos centramos en el usuario y en el mercado. Y para Shelley se trata de operadores de stake pool que están ejecutando la red, y se trata de delegadores que están delegando en la red, así que esas son las dos experiencias en las que estamos centrados.
Tim: Obviamente hemos visto un notable crecimiento de operadores de stake pools y la comunidad alrededor de eso desde Julio, y eso es una parte significativa de cómo necesitamos evolucionar la red. Comencemos a hablar un poco sobre eso, estuve con algunos miembros del equipo que están mirando esa experiencia de operador de stake pool, particularmente alrededor del área de parámetros y a dónde vamos con eso, para apoyar el ecosistema a largo plazo. Vamos a mostrar un video ahora, hay una entrevista mucho más larga si quieres acceder a través de youtube, el enlace se debería estar mostrando ahora, pero vamos a mostrar sólo unos pocos aspectos destacados de esa conversación, sólo para enmarcar esto para todo el mundo. Cuéntanos un poco más desde una especie de perspectiva de parámetros, cosas como la descentralización y también cómo la seguridad de red va a estar cubierta aquí.
Lars: En Bitcoin el problema es que la gente, quiero decir, si sólo se preocupan por maximizar su beneficio, tienden a ir en tropel a los pools y de alguna manera el pool más grande se convierte en el menos sobrecargado de costos así que el pool tiende a hacerse más y más grande que es lo contrario de descentralización porque terminamos con unos pocos pools muy poderosos. Así que intentamos, como explicó Katarina, diseñar el sistema de manera que eso no suceda en Cardano, y por eso un parámetro muy importante es el k, el número ideal de pools que queremos, que en este momento está fijado en 150, pero hay un debate sobre cambiar eso. La idea es que una vez que un pool alcanza este límite, 150 en nuestro caso, entonces no se obtienen más recompensas. Así que los pools pueden hacerse más grandes, no hay un límite duro, no está prohibido por el protocolo, pero sólo que las recompensas no crecen más si un pool se vuelve demasiado grande. Así que si los delegadores son de hecho racionales, entonces delegarían en otro pool si se vuelve demasiado grande porque todo el mundo obtendría menos beneficios.
Tim: Es por eso que los delegadores deberían mantener un ojo en la delegación.
Lars: Exacto, si un pool, quiero decir, básicamente la mejor situación es si un pool está exactamente saturado, entonces las recompensas son más altas, pero si crece más allá de eso, entonces, porque las recompensas del pool ya no aumentan más, pero hay más y más gente que comparte esta cantidad máxima de recompensas, entonces cada delegador individual obtendría menos. Así que es importante que mantengan un ojo en eso, si un pool es demasiado grande deberían delegar en un pool más pequeño.
Tim: Ese es el parámetro k, ¿cuáles son los otros parámetros que la gente necesita saber?
Lars: Hablé de k, el punto de saturación, básicamente determina cuánto puede crecer el pool hasta que no consiga más recompensas, y eso por supuesto crea un problema, alguien podría ser muy sigiloso y decir “está bien, pero quiero tener un pool más grande, así que sólo creemos dos pools”, y pretendo que soy otra persona, no le digo a nadie que ambos pools me pertenecen, es sólo una dirección IP o alguna clave pública, así que la gente no lo sabe y yo podría establecer montones y montones de pools y dejar que todos crezcan hasta este punto. Y la gente pensaría que todo es perfectamente descentralizado, muchos pequeños pools, pero en realidad soy el dueño de todos ellos y eso es llamado ataque Sybil, y eso es crítico, tenemos que pensar en cómo prevenir eso y ahí es donde otro parámetro importante entra en juego, así que la idea es que tú tienes que adjuntar compromiso a un pool, que técnicamente sólo significa la cantidad de dinero que delegas en tu propio pool, y de alguna manera las fórmulas que desarrollamos dicen que el pool recibe ligeramente recompensas más altas si ésta delegación a tu propio pool es mayor, y eso significa que si intentas este ataque y estableces varios pools, entonces obviamente porque tu propio dinero es finito, tienes que dividir tu propio dinero entre esos pools, entonces cada uno de esos pools recibe un poco menos y todos esos pools son menos atractivos porque generan recompensas más pequeñas. Así que la esperanza es que si alguien hace eso, y no podemos evitarlo, pero si alguien hace eso, esos pools serán menos atractivos para la comunidad y los delegadores no delegarán en esos pools, así que este es el parámetro a0 que determina cuán alta es esta influencia entre tu compromiso, delegar en tu propio pool, y las recompensas.
Tim: Traigamos a Colin ahora, porque como dices Lars, hay un montón de cosas que considerar, hay enorme complejidad entre bastidores, con ello viene esa flexibilidad y adaptabilidad, pero supongo que es un reto llegar a un punto que mantiene a todas las partes del ecosistema felices. Grandes discusiones también alrededor del cambio en algunos de los parámetros clave, como el parámetro k que en última instancia afectará básicamente como rinden los diferentes pools, si los pools más grandes tienden a dominar o si consigues una propagación mucho más uniforme a través de la red, tal vez puedas compartir un poco acerca de dónde está el pensamiento en este momento en términos de eso.
Colin: En términos de la dirección a largo plazo, en gran parte está establecido por nuestros investigadores, así que están trabajando en eso como una coacción para luego salir con un plan. Así que puedes imaginar que estamos en un viaje por la carretera, la investigación podría decir que vamos a Edimburgo y nuestro equipo de producto nos construye un autobús turístico y yo soy una especie de Google Maps diciendo que gire a la izquierda aquí. En términos de nuestro pensamiento actual, creo que vamos a tener un par de cambios, uno de ellos son nuestros propios stake pools, tenemos algunas preocupaciones sobre el modo en que se establecieron inicialmente, particularmente en la forma en que tal vez están atrayendo la delegación, alejando otros pools más pequeños. Así que ciertamente estaremos reequilibrando eso, hay algunos cambios tecnológicos que estamos esperando para la incubación del negocio, pero esas son cosas que espero estemos discutiendo muy pronto en términos de cómo planeamos ayudar a construir y empezar nuevos pools. Uno de los desafíos, cuando hablamos sobre cosas como de equilibrio de un modelo estable a largo plazo, es ese proceso de transición, de cómo esos pools inicialmente atraen delegación y construyen un negocio, una marca y una franquicia. Y eso puede ser un reto en un ambiente donde no se puede necesariamente, directamente, alcanzar y contactar a tus clientes, en el negocio del staking por ejemplo, hay un grado de tal vez no anonimato, pero tal vez pseudo anonimato ahí, donde hace que la gestión de una marca sea desafiante. Cuando estamos mirando a k como un parámetro, ese es uno de los que limita fuertemente el tamaño de un gran pool, y como operadores de pools muy grandes IOG es ciertamente uno de los grupos más afectados sobre cualquier cambio en parámetros como ese en la forma en que funciona. Así que una de las cosas que hemos estado mirando muy de cerca es qué tipo de procesos y cómo deberíamos hacer la transición de 1k tal vez con el que empezamos inicialmente, a un valor al que queremos llegar a largo plazo. En particular k es un parámetro muy desafiante, porque requiere un gran número de actores, ya sea nuestros pools internos y que todos los delegadores tomen medidas y en nuestro caso separaríamos muchos de los pools en pools más pequeños. Queremos hacerlo de una manera que no dañe el resto del ecosistema, no creo que sea una sorpresa saber que estamos moviendo muchos de nuestros pools privadamente, para que no tomen delegación de otros pools. Pero de nuevo, hacer esto de una manera que es segura, obviamente tenemos preocupaciones de seguridad sobre cómo administramos nuestros propios fondos, ya sea que estén en billeteras de hardware, hay un límite en alguien perforando el código, tenemos que pensar en cómo ese tipo de cosas funcionan y gestionar ese proceso. Y esto es de muchas maneras muy similar con lo que lidian otros operadores de pools, también estamos tratando de salir con un plan de negocios y administrar los fondos y mirar cómo estos cambios los afectan, así que hemos estado bastante involucrados en proveer retroalimentación y trabajamos muy de cerca con muchos de los otros operadores de stake pools, he estado asistiendo a muchas de las llamadas recientemente e involucrándome más en esa comunidad, porque comparten muchas de las mismas preocupaciones que tenemos sobre cómo vamos a hacer que esto funcione.
Tim: Así que supongo que todo el asunto tiene que ser mirado de forma holística, ¿qué viene a continuación en esta área y tal vez más allá en el lado de la investigación que podemos esperar?
Aikaterini: Los incentivos son un área muy activa, trabajamos muy de cerca con el equipo de ingenieros para desarrollar aún más el sistema y recibir la retroalimentación de la comunidad, ver cómo reaccionan los usuarios y tener esto en cuenta en la adaptación del mecanismo, etc. Un problema en el que estamos trabajando en este período es como si fuera censura, para que un nuevo pool pueda registrarse, se debe añadir una transacción especial en la blockchain, en el libro contable de la blockchain, pero esta transacción debería ser añadida por los líderes actuales del pool que dirigen el sistema. Así que los actuales líderes del pool pueden querer evitar la competencia, y no quieren que un nuevo pool se registre, tal vez porque si un nuevo pool tiene una muy buena característica, puede ser competitivo y como que tal vez esto podría hacer que bajara su margen, etc. Así que nos gustaría encontrar un mecanismo de solución a la censura, un mecanismo que incentive a los operadores de pool a incluir tales transacciones. Y, por supuesto, en este caso, si hay un sólo pool que es honesto y siempre sigue la instrucción, entonces esta transacción se añadirá. Pero dado que en nuestro modelo de incentivos consideramos que todos los usuarios son racionales, no consideramos que siguen el protocolo si no maximiza su beneficio, todavía tenemos que resolver esto, sin asumir que un pool añadirá estas transacciones, y estamos en el proceso de encontrar un mecanismo de decisión para resolver también este aspecto. Y esto es sólo un aspecto, en general continuamos la investigación en diferentes aspectos del mecanismo de recompensas y dada la retroalimentación y la investigación en curso estamos adaptando y replanteando todos los aspectos que hemos diseñado hasta ahora, y tratamos de evolucionarlos para tener una red estable y para tener lo mejor que se pueda en esta área.
Tim: Colin, Aikaterini, Lars, muchas gracias por unirse a nosotros