Transcripción al español de “Decentralized software updates”
Publicado en el canal de Youtube de IOHK el 31 de Julio de 2020
Enlace a la versión doblada al español
En esta segunda parte de la presentación trataré de hacerles un rápido esbozo de nuestra solución. Bien, estos son los elementos centrales de nuestra solución, tenemos la noción de un SIP, un sistema de propuesta de mejora, que es sólo un documento que describe la idea básica de la actualización del software y trata de justificar la necesidad para implementar este cambio, esta actualización de software. Luego tenemos la propuesta de actualización, UP, que esencialmente es la implementación de una SIP específica. Luego tenemos la parte de la actualización de la gobernanza que es votar, el mecanismo y la delegación a expertos, la activación segura y finalmente la lógica de actualización que es la actualización impulsada por metadatos que hemos discutido. Tengan en cuenta que tanto los SIPs como los UPs son sometidos a la blockchain con transacciones de honorario simple, esta presentación tiene lugar a través de un programa del comité que asegura la propiedad legítima de la propuesta.
Bien, en este diagrama de alto nivel podemos ver una actualización de software que viaja a través de todas las fases en el ciclo de vida de la actualización de software, la fase de ideación, la fase de implementación, las fases aprobación y activación. Así que en la parte superior izquierda puedes ver una SIP presentada y a través de un esquema de compromiso de reconstrucción, está comprometido en la blockchain, luego comienza el período de votación, los votos se recogen, el recuento tiene lugar, también en paralelo tenemos la delegación, donde los votantes pueden delegar sus votos a expertos. Y una vez que esta SIP sea aprobada, la fase de implementación toma lugar, donde al final de esta fase la implementación se presenta a la blockchain, de nuevo, a través de un esquema de compromiso de reconstrucción y va a la fase de aprobación en la que los expertos necesitan revisar y probar y tomar una decisión sobre la implementación. Noten que durante todas estas interacciones sólo los hashes son almacenados en cadena, los datos reales, el código, los metadatos y los documentos, todos ellos se almacenan en alguna solución de almacenamiento externa, descentralizada, fuera de cadena. Ahora, una vez que una implementación, un UP se aprueba, luego aplicamos la política de actualización, las prioridades, comprobamos las restricciones de la actualización, si se cumplen las restricciones de actualización y si todo está bien, entonces entramos en la fase de activación, donde esencialmente aquí hay un período señalado, un período de aprobación en el que las partes necesitan señalar la disponibilidad para la actualización. Cuando esta condición específica se cumple, se alcanza un umbral específico de señales, entonces podemos decir que la actualización del software puede ser activada.
Vamos a entrar en la gobernanza de actualización y discutir un poco sobre la votación. Un voto es una transacción de honorario simple, hay votos para los SIPs y UPs, que son la implementación como dijimos. Tengan en cuenta que esto no es lo mismo, para votar por un SIP tienes que ser consciente y tener una opinión digamos de la hoja de ruta del sistema, mientras que cuando votas por un UP solo estás votando sobre una pieza específica de código, tienes que tomar una decisión de si el código es apropiado o no y si implementa correctamente la promesa inicial, así que no tenemos que ser conscientes de la hoja de ruta del sistema cuando estás votando por una implementación. Ahora cualquiera que tenga una participación tiene un derecho legítimo a votar y este voto cuenta proporcionalmente a tu propia participación. Los votos son aceptados sólo dentro de un período de tiempo específico que llamamos período de votación, que es una ventana de tiempo impulsada por metadatos.
Permitimos que muchas propuestas compitan en paralelo y el votante puede cambiar de opinión y volver a votar durante el período de votación. Permitimos tres lógicas de valor para un voto, a favor, en contra y abstenerse para obtener un claro mensaje de la comunidad sobre su opinión sobre una actualización específica. Y en algunos casos cuando un resultado no se ha alcanzado, por ejemplo, cuando no hay resultado mayoritario o el resultado mayoritario es abstenerse, entonces permitimos que un período de re votación tenga lugar para llegar a una decisión final.
Discutamos sobre la delegación, los votantes pueden delegar sus derechos de voto a algunos expertos, ¿por qué necesitamos delegación? bueno, proponemos delegación principalmente por tres razones. La primera razón que hemos discutido es conocimientos técnicos, porque las actualizaciones de software son entidades técnicas y se requiere experiencia para tomar una decisión. La segunda razón es que nosotros podemos delegar para una categoría específica de actualizaciones de software, no para todas las actualizaciones, por ejemplo, sólo para arreglos de seguridad. Y la tercera razón es la disponibilidad, reconocemos el hecho de que la parte específica no puede estar en línea todo el tiempo para participar en el protocolo de actualización. Así que le damos la oportunidad de delegar su derecho a un tercero para participar en el protocolo de actualización en su nombre. Así que uno puede delegar para una actualización del software específica o una categoría específica de actualizaciones de software o para cualquier actualización de software. Tengan en cuenta que el voto personal siempre anula el voto de un delegado. Por defecto, la delegación va a los stake pools, así que si no haces nada, si no delegas en absoluto y no votas entonces el stake pool al que has delegado tus derechos de participación también asumirá la delegación para la participación en el protocolo de actualización. Ahora, el patrón de delegación que seguimos es que una parte interesada puede delegar en un stake pool y luego un stake pool puede delegar a algún experto o la parte interesada puede delegar directamente a algún experto.
Con respecto al mecanismo de activación hemos establecido algunos objetivos específicos que necesitamos cumplir. Primero necesitamos satisfacer todas las restricciones de actualización antes de las activaciones, cosas como las dependencias de la versión o conflictos tienen que ser resueltos antes de la activación. Tenemos que asegurarnos de que se da tiempo suficiente a las partes para actualizar y no sólo eso, necesitamos asegurarnos de que todos los supuestos de seguridad que se necesitan mantener de hecho se mantienen en la nueva cadena, por ejemplo, que suficiente participación honesta haya actualizado antes de la activación. También tenemos que lidiar con el problema de negación de activación, necesitamos encontrar una manera de mitigar este riesgo de bloqueo y activación de una propuesta, tenemos que asegurarnos de que las propiedades de consistencia y vivacidad se mantendrán en la nueva cadena, para que la nueva cadena sea segura y también que la nueva cadena haya incorporado exitosamente la vieja cadena.
Este es un resumen de nuestra solución de activación, en la parte superior izquierda se ve una implementación que ha sido aprobada, esto entra en una cola de activación y luego sale de esa cola basado en la política de actualización que aplicamos. En ese momento comprobamos si se cumplen las restricciones de actualización y si todo está bien, entonces los usuarios, las partes, deben descargar e instalar el nuevo software y en este punto los cambios no se activaron todavía, sólo señalan activaciones disponibles, así que dicen “estoy listo”, esencialmente esto señala el comienzo de un período de aprobación, en este período de aprobación recogemos estas señales de las partes y en puntos específicos, por ejemplo, en los límites de las épocas contamos las señales y tratamos de ver si han alcanzado un umbral de adopción específico. Este umbral de adopción trata de asegurar que suficientes partes honestas hayan actualizado al nuevo código. También, la duración de este período de aprobación es igual a una ventana de tiempo que llamamos demora de seguridad, que es una ventana de despliegue impulsada por metadatos que trata de dar mucho tiempo a las partes para actualizar. Además, para mitigar el problema la negación de activación, proponemos un mecanismo en el que si no se ha alcanzado el umbral, después de que la demora de seguridad expire, entonces podremos volver a entrar en el período de aprobación con una reducción del umbral de adopción para dar una segunda oportunidad a las partes honestas que por alguna razón no han tenido el tiempo para actualizar y de esta forma se mitiga el riesgo de negación de activación y el bloqueo de la activación de una propuesta. Ahora, cuando se alcanza el umbral de adopción entonces estamos listos para activar y luego nuestro protocolo de activación tiene efecto y este trata de transferir el libro contable desde el viejo libro contable de la blockchain al nuevo libro contable y asegurar que esto suceda con una transferencia segura, donde el nuevo libro contable estará seguro, bajo las propiedades de consistencia y vivacidad y que el el nuevo libro contable incorpora con éxito el viejo libro contable y es una continuación válida del viejo libro contable.
Aquí hay algunas medidas de rendimiento preliminares que hemos hecho en nuestro prototipo. Lo primero que nos gustaría medir es el tiempo de procesamiento que toma para que nuestro protocolo ejecute. Hemos hecho un poco de micro referencias en la fase de computación más intensiva de nuestro protocolo que es la fase conteo total de los votos. A tu izquierda puedes ver un gráfico donde tenemos el tiempo de procesamiento por el número de participantes, ves que hay una escala de tiempo de procesamiento lineal ascendente a medida que el número de participantes aumenta. Además, puedes ver que incluso para números de participantes extremos, como 10 millones, el tiempo de procesamiento es inferior a un segundo, que es un resultado muy bueno. A la derecha puedes ver otro experimento, en este caso queríamos medir el porcentaje de rendimiento disponible que nuestro protocolo consume, porque hemos dicho que creemos que el mecanismo de actualización de software no debería impactar negativamente la blockchain subyacente, así que queríamos medir el porcentaje de rendimiento disponible que se consume por nuestro protocolo a medida que el número de participantes aumenta. Por esta razón hemos hecho algunos análisis de los peores casos en los que hemos tomado 10 propuestas corriendo en paralelo y un escenario donde cada participante cambia de opinión y vuelve a votar, así que queríamos más o menos inundar el sistema con eventos y ver cómo lidiaba con eso. Así que incluso en el peor de los casos puedes ver que tenemos que llegar a un número de participantes después de 1 millón para empezar a notar el impacto del protocolo de actualización, hasta 1 millón de participantes el impacto, el consumo del rendimiento, está debajo del 10 por ciento, que de nuevo, es un resultado muy prometedor.
En esta diapositiva intentamos hacer una comparación cualitativa de nuestra solución con otras soluciones similares, por esta razón hemos puesto nuestra solución en un plano definido por dos dimensiones. En la dimensión horizontal hemos puesto la gobernanza descentralizada, donde puedes ver que uno puede tener gobernanza descentralizada fuera de la cadena o en cadena y también descentralizar fases específicas en el ciclo de vida de una actualización de software o más fases o todas las fases del ciclo de vida de una actualización de software. En la dimensión vertical hemos puesto una activación automática segura, en esta dimensión uno puede tener no sincronización y activación en un plazo determinado o tener un mecanismo de actualización automatizado que utiliza un mecanismo de sincronización para sincronizar las partes y activar automáticamente. Luego, podría haber diferentes tipos de cambios, como bifurcaciones blandas o duras que son soportadas por el mecanismo de activación y diferentes, digamos, riesgos de seguridad con los que el protocolo, el mecanismo de activación, intenta lidiar. En resumen, puedes ver que nuestra solución permite gobernanza descentralizada en cadena en todas las fases del ciclo de vida de la actualización del software y lo hace a través de un mecanismo de votación y delegación a expertos. También, en relación con activación, propone un mecanismo automatizado de activación que soporta todo tipo de cambios y trata de asegurar una activación segura a través de un protocolo de activación criptográficamente seguro.
Muy bien, esto concluye el esquema de nuestra solución pero, ¿por qué debería importarte todo esto? bueno, espero haberte convencido de que las actualizaciones de software descentralizadas contribuyen a un ecosistema blockchain más saludable, ¿por qué? , porque son un habilitador para la gobernanza blockchain impulsada por la comunidad. Exactamente porque permiten la evolución de la blockchain de forma democrática y sin riesgos de seguridad o división de cadena. Ahora, si realmente creen que la descentralización es el futuro, entonces esto sólo puede suceder con blockchains autosustentables y las actualizaciones de software descentralizadas son un componente clave para lograr blockchains autosustentables. Con respecto a Cardano y gobernanza descentralizada, es cierto que Cardano pretende convertirse en un sistema autosustentable, un sistema en el que los interesados puedan influir en el futuro desarrollo de la red y este desarrollo será financiado a través de un sistema de tesorería. Sí, el futuro de Cardano estará en las manos de la comunidad y allanará el camino a la verdadera descentralización para otras blockchain a seguir. Todas estas cosas bonitas tendrán lugar en un futuro lanzamiento que se llama Voltaire, una pieza central en la cual está este trabajo.
Bien, déjame resumir y darte un poco de conclusiones principales de esta presentación. Lo primero que tienes que recordar es que las actualizaciones de software para las blockchains son difíciles y que las actualizaciones de software descentralizadas para las blockchain son incluso más difíciles. Ahora, cuando escuchas acerca de un sistema descentralizado deberías saber que esto es un oxímoron y si quieres descentralizar tu mecanismo de actualización de software entonces deberías permitir participación abierta, toma de decisión descentralizada en todas las fases del ciclo de vida de las votaciones y no sólo en unas pocas fases, deberías ir por una solución impulsada por protocolo que tiene garantías de seguridad específicas y deja un rastro en la cadena de eventos de actualización que hacen la historia de la actualización del sistema transparente y auditable. Luego con respecto a activación, debes tener un mecanismo de activación que permite una activación segura que es resistente a la división de cadenas, ir por una lógica de actualización impulsada por metadatos y tener un mecanismo escalable y eficiente. Estos son los componentes clave para el mecanismo descentralizado de actualización de software exitoso, al menos en nuestra opinión. Cardano realmente aspira a convertirse en un sistema blockchain gestionado verdaderamente por la comunidad y las actualizaciones de software descentralizadas son los vehículos principales para realizar este viaje hacia la gobernanza descentralizada. Muchas gracias por su atención, la siguiente sesión en vivo viene a continuación, gracias.