Transcripción al español de un fragmento de “Transition to Shelley Mainnet, Recent Whiteboard, SANBA | TCE 85”
Del minuto 25:28 al 40:48 del video original.
Publicado en el canal de Youtube del Efecto Cardano el 19 de Abril de 2020.
Enlace a la versión doblada al español
Phil: Lo que realmente queríamos explicar a los espectadores y a los oyentes es el parámetro D y exactamente como esto va a tomar lugar, el incremento paso a paso que va a hacer la transición de los nodos de un estatus federado al estatus de stake pools o pools de la comunidad.
Charles: Bien,ok, sí, así que había realmente tres cosas que teníamos que lograr, una el código original Cirical no encajaba para el propósito y nunca fue diseñado en una forma que nos facilitó mucho la tarea de pasar de un modo estático federado a un modo descentralizado, así que había una especie de medio paso que necesitaba ser hecho y eso fue de lo que el reinicio Byron se trató, dónde podríamos reemplazar con gracia el viejo código con un nuevo código que es todavía es estático y federado pero tenía ganchos incorporados en él para hacer mucho más fácil para nosotros la transición a Shelley, eso tomó un poco de tiempo para averiguar cómo hacerlo sin interrupción y luego la otra cosa es que si eres una verdadera criptomoneda, tienes que ser capaz de validar toda la cadena, todo el camino de vuelta a génesis. Así que en realidad tenemos tres conjuntos de reglas de libro contables cuyas transiciones tenían que ser pensadas cuidadosamente entre todas esas reglas del libro contable, así que de todos modos eso es lo que estamos haciendo con el reinicio Byron y el candidato Flight 4 acaba de salir y a principios de la siguiente semana probablemente haremos otro candidato Flight y luego en el final de la semana haremos un Daedalus de red principal, así que el 100% del código Cirical ha desaparecido desde el lado del consumidor y los relés y nodos centrales han sido rotados.
Entonces lo que pasa es que elegimos una fecha y decimos está bien, aquí está Shelley y le damos a todo el mundo los clientes Shelley y luego hay una especie de dos grupos de consumidores para eso, un consumidor son los intercambiadores, gente como Yoroi que necesitan una infraestructura para desplegar sus billeteras y eso tiene todo sobre Shelley dentro, Ouroboros Praos, el código de delegación, cosas de stake pools, algunas cosas de la red, todo lo relacionado con Shelley, pero en realidad no está prendido, está básicamente sentado ahí, listo para ir y tu cliente puede entender todas estas cosas, pero sigue operando en modo del legado, como el reinicio Byron. Y luego en algún momento decimos, está bien es tiempo de bifurcación dura y en ese punto todas esas cosas Shelley se encienden y luego en ese momento no hay más cosas Byron funcionando, los relés Byron se apagan y vas a tener que rotar a un nuevo sistema y lo llamamos la fase Shelley híbrida, es lo que tienes en tu diagrama justo aquí y básicamente en ese punto el tiempo es igual a cero para esa primera época, en la que todavía estamos haciendo bloques como los que hacemos con Ouroboros BFT, tal como lo estamos haciendo ahora mismo, que estamos en la era del reinicio. Pero tenemos estos pequeños parámetros D y cada época podemos reducir ese parámetro D, que es como una pared que cae y más y más franjas están siendo hechas por operadores de stake pools. Básicamente tenemos dos conjuntos de métricas que van a operar en eso, una es la cantidad de stake pools registrados, la cantidad de ADA delegado, este tipo de cosas, métricas cualitativas, cuantitativas que nos dicen la salud y el nivel de rendimiento general de la descentralización del sistema. Y la otra es una métrica de tiempo, así que es un escenario o el otro, o bien golpeamos un conjunto predeterminado de cosas en las que decimos “sí, esto es tan descentralizado como va a ser, vamos a ponerlo en cero” o decimos “mira, no podemos correr esto, no podemos proporcionar ruedas de entrenamiento para siempre, buena suerte a todo el mundo vamos a tener que poner D en cero”. Y lo que vamos a hacer es en Mayo o Junio, en algún lugar de ese marco de tiempo, anunciar lo que ese proceso va a ser y escribiremos un artículo completo sobre el parámetro D y básicamente explicar cómo funciona técnicamente en las reglas del libro contable porque ya se ha especificado formalmente, de modo que si han leído las especificaciones formales pueden verlo ahí y luego explicar básicamente un hipotético programa de cómo bajaría D, así que en mi video dije bien una forma obvia de hacerlo sería un decrecimiento de 10 por ciento por época y si ese fuera el caso entonces después de unos 40 o 50 días, dependiendo de la longitud de la época, D sería igual a cero.
Ahora una pregunta que ha surgido es, ¿podemos ir en la otra dirección? y la respuesta es sí, así que si esos parámetros cualitativos o cuantitativos, por cualquier razón están regresando o si hay algún error catastrófico que ha sido descubierto, lo cual es muy poco probable, pero siempre tienes que planear de antemano para estas cosas, poner botes salvavidas en el barco, en ese punto podríamos técnicamente subir D, por ejemplo, desde .8 a .9 o incluso llevarlo todo el camino hasta 1, pero ese es un escenario poco probable. Y después de que D llegue a cero, lo que que vamos a hacer es quitar la capacidad de actualizar D y básicamente completamente sacar eso fuera usando el sistema de actualización. Y luego todos los parámetros futuros del sistema a largo plazo y largo plazo es el corto plazo porque las cosas están llegando a un fin, será manejado por Voltaire, así que cosas como los honorarios de transacción y otras cosas como esas pueden ser reajustadas a través de un proceso democrático. Así que nuestro objetivo es conseguir que D baje a cero tan rápido como sea posible, es una de esas cosas que es menos necesaria porque teníamos la ITN cuando creamos D por primera vez, cuando estábamos debatiendo si tener una ITN o no, así que esto efectivamente hubiera sido como una versión Haskell de una testnet incentivada, pero es importante entender que cuando empecemos a bajar D, de 1 a 0.9 los stake pools no están validando transacciones testnet, están validando transacciones de red principal, así que esto es real, están ejecutando parte de la red y es una es una gran prueba de activos que exactamente no entrega las llaves del Ferrari al nuevo conductor, se asegura de que la gente realmente sabe lo que está haciendo. Pero es algo que podemos reducir rápidamente o lentamente y eso va a estar completamente basado en un enfoque basado en métricas Phil: Charles, así que este es un proceso dinámico, si estoy entiendo esto correctamente, así que si llegamos a D .1 y vamos hacia ese cien por cien de descentralización de nodos de pool, ¿IOHK liberará las métricas públicamente, serán esos objetivos liberados públicamente, queremos golpear este y este y este hito o esto va a ser algo interno?
Charles: Absolutamente preferiría eso, porque es un sistema descentralizado, preferiría que todas esas métricas sean lo más transparentes posible. Sencillamente la idea es la cantidad de ADA en circulación, en participación, la cantidad de stake pools registrados, el rendimiento de stake pools, ya estamos siguiendo muchas de esas métricas en la testnet incentivada, la única razón por la que no hemos liberado esta decisión todavía es que tenemos que hacer una autopsia sobre la ITN y reunir lo que pasó ahí y tenemos que hacer algunas extrapolaciones. El conjunto de datos está un poco contaminado, porque había muchos problemas de calidad al principio de la ITN, como ustedes experimentaron, y así que la cuestión es si esos problemas de calidad y el hecho de que sólo tuvimos una captura de pantalla nos dió un nivel artificialmente bajo de participación y podríamos esperar un mayor nivel de participación en la red principal. A pesar de eso, creo que alrededor del 40% del suministro de ada ha sido participado, lo que es extremadamente bueno, es mejor que Tron en red principal, es un poco menos que Tezos, pero no significativamente. Así que esos son los tipos de métricas que miramos y luego creamos algunos objetivos y diremos que mientras que nos quedemos, por ejemplo, en este umbral o por encima de él, seguiremos disminuyendo esta cantidad por época y mantendremos ese progreso en marcha, ese podría ser un ejemplo de lo que hacemos. Pero escribiremos un blog y probablemente lo que haremos es tener a Kevin Hammond y a Duncan en el show y hablar con ustedes y responder a todas las preguntas y ellos pueden guiarlos a través de un ejemplo de calendario de cómo D llega a cero.
Otra cosa importante que no se mencionó en mi video de pizarra blanca pero es importante para la descentralización es que todavía estamos operando en un modo de retransmisión con nuestra pila de red. Así que cuando lancemos Shelley, los gobernadores de par a par estarán ahí pero mucha de la mecánica de par a par no se ha encendido todavía, no queríamos complicar demasiado el lanzamiento. Así que en los próximos meses vamos a encender los componentes de par a par también, pero eso también es necesario para la descentralización o bien podríamos apagar los relés y no serías capaz de sincronizar la blockchain. Así que estos son una especie de dos factores que van a funcionar al mismo tiempo. Uno es el decrecimiento de D y el otro es el encendido de la mecánica de par a par, una vez que despejemos la primera ola de Shelley pero eso no tiene ninguna interrupción en las recompensas o algo así, pero es es uno de esos componentes que es necesario para la descentralización
Rick: Tengo curiosidad por el parámetro D, también podemos llegar a algunas de las preguntas en el chat que se relacionan. Una vez que eso comienza, una vez que empezamos con la fase híbrida Shelley y se activa el parámetro D, ¿puede estar en pausa o hay algún riesgo, como que si usas el decrecimiento .1 toma 40 días, porque son unos cuatro o cinco días por época a diferencia de la ITN que actualmente es uno y luego el temporizador comienza a ir, si hay algún evento catastrófico, hay alguna forma de pausar o darte suficiente tiempo para compensar y volver al camino?
Charles: Es un proceso de actualización manual, así que la forma en que cambiamos esos parámetros es por el mecanismo de actualización que se construye en Cardano, así que lo actualizamos manualmente y elegimos con esa actualización manual la cantidad de disminución o incremento en ese momento. Así que no es como si accionamos un interruptor y automáticamente hace punto diez cada cuatro días, es una decisión que haces básicamente cada época, pero probablemente sigamos un calendario, así que diremos que si estos umbrales se ven bien, entonces hagamos punto uno cada época. Pero la razón por la que lo hicimos manual es que redujo complejidad y segundo nos permite llevar el producto al mercado un poco más rápido, realmente no había razón para automatizar eso y la otra cosa es que no teníamos muchas de estas métricas hasta que tuviéramos la ITN, diseñamos el sistema antes de la ITN, así que lo haría realmente difícil de conseguir si lo automatizábamos, así que pensamos en dejarlo como un proceso manual, será rápido, uno o dos meses, no más de tres diría, por qué molestarse en tratar de inventar una máquina Rube Goldberg para hacer una cuenta atrás automáticamente, vamos a actualizarla manualmente cada cuatro o cinco días basados en lo que estamos viendo. Y por lo que hemos visto en la ITN, no hay razón para creer que este proceso va a durar más de uno o dos meses.
Rick: Bien, gracias por eso, creo que la actualización manual es una buena gestión de riesgo, creo que fue una buena decisión.
Phil: Una pregunta más, ¿vamos a tener cualquier retraso de los intercambiadores?, cuando te comunicas con intercambiadores principales, ¿van a obstaculizar el proceso de llegar a D igual a cero?, sólo basado quizás en la velocidad de su implementación de ciertos aspectos del proyecto.
Charles: Desde una perspectiva de intercambiador, tanto desde la perspectiva de la billetera como los componentes relacionados con Shelley, staking como un servicio, el parámetro D no tiene nada que ver con el despliegue Shelley, es como un nivel diferente y la razón es que desde la perspectiva de intercambiador, una vez que se descargan y ejecutan el nodo Shelley en contra eso, no importa si se están haciendo bloques en Ouroboros BFT o si se están haciendo bloques por Praos, la función de red es idéntica para ellos, son sólo, ya sabes, o bien hacen staking o están procesando transacciones o lo que sea. Así que no, eso no va a tener ningún impacto. Pero respecto al retraso para llegar a la bifurcación dura, para encender Shelley, hay una pregunta abierta sobre cuánto tiempo los intercambiadores deberían tener para actualizar su infraestructura, porque su actual infraestructura SL o reinicio Byron necesita ser actualizada para funcionar con Shelley, cosas muy simples podrían romper su infraestructura si no son cuidadosos, por ejemplo, estamos cambiando el formato de la dirección desde donde estamos actualmente, nuestro formato propietario, a Bec 32. Así que si no actualizan desde el reinicio Byron al nuevo nodo Shelley, entonces cuando vas y pones tu dirección Bec 32 en su pequeño campo de retiro en la interfaz gráfica de la web del intercambiador y dices envía mis ADA a esta dirección, no se validará como una dirección adecuada por ejemplo, debido a que el código antiguo no entiende esa dirección. Así que estos son ejemplos de cosas que se romperían si no se actualizan, entonces los intercambiadores necesitan actualizar, así que la pregunta es ¿cuándo en esta hoja de ruta los intercambiadores tendrán un conjunto final de bibliotecas y tecnología para integrar en contra, y con un pequeño sello de goma que dice que si construyes contra esto estamos listos para ir. Y eso va a estar en la fase de comprobación de balance, acabamos de lanzar nuestro primer conjunto de bibliotecas gráficas QL y vamos a tener una gran exposición de ellos en la actualización de producto al final del mes y estaremos actualizando esos una vez más, y eso se actualizará justo cuando comienza la comprobación de balance y luego esa es la ventana de actualización, habrá una testnet Shelley en funcionamiento, tendrá todas las bibliotecas y características completas y no hay cambios en las APIs ni nada de eso y decimos que ustedes necesitan construir contra esto si quieres listar ada después de la bifurcación dura Shelley y luego la pregunta es de cuánto tiempo debería ser esa ventana de actualización, así que creo que probablemente desde cuando lanzamos el software de red principal Shelley para que la gente descargue, tal vez unas cuatro semanas antes de que la bifurcación dura ocurra. Ahora, por lo que la comunidad se preocupa es que no hay recompensas de staking durante ese período de tiempo porque todavía estamos corriendo bloques Byron OBFT y ninguna delegación es posible y no hay stake pools registrados, así que hay una especie de este ir y venir sobre cuándo se enciende Shelley y cuánto tiempo necesitamos esperar responsablemente para que los intercambiadores y las personas actualicen a Shelley y por lo tanto, tal vez cuatro semanas es la ventana apropiada, técnicamente podría ser un día, pero entonces la gran mayoría de la gente probablemente no habrá actualizado en ese punto. Tuvimos muchas conversaciones con intercambiadores, Nick hizo eso y nos dijeron que necesitan entre cuatro a seis semanas para quemar este nuevo software, así que si hacemos la comprobación de balance, dando una semana o dos y luego la red principal Shelley y luego hacer una ventana de actualización de cuatro semanas, entonces eso les daría las seis semanas que necesitan para ser capaces de conseguir su software listo para usar y nos permite entrar en la fase híbrida de Shelley, ¿tiene sentido?