🇪🇸 Actualizaciones de software descentralizadas | IOHK 31 Jul 2020 (Parte 1 de 2)

:es: 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


Hola a todos y bienvenidos a la cumbre virtual Cardano, mi nombre es Nikos Karagiannidis y trabajo para el equipo de investigación, en esta presentación vamos a discutir el trabajo que hacemos en el área de actualizaciones de software descentralizadas, este es un trabajo que estamos haciendo junto con Michele Syampi, Damian Nadales y Dionysis Zindros. Actualizaciones de software, bien, dejemos de lado por un momento la descentralización y discutamos sobre las actualizaciones de software, ¿por qué son importantes las actualizaciones de software? Bueno, básicamente porque los cambios son importantes, este tipo de aquí es Heraclitus de Ephesus , un antiguo filósofo Griego, una de sus citas famosas era “todo cambia y nada se queda quieto”. Esencialmente Heraclitus solía sostener que el cambio es la esencia de la vida y de hecho se puede decir que el cambio es sinónimo de evolución, y todos sabemos lo importante que es la evolución para los sistemas de software, sistemas de software que no evolucionan inevitablemente se convierten en anticuados y redundantes, esto también es cierto para los sistemas blockchain. Ahora, sistemas de software y blockchains evolucionan a través de actualizaciones de software, así que por eso las actualizaciones de software son importantes, porque son los medios para la evolución del software. Ahora ¿cuáles podrían ser algunas razones típicas que desencadenan la actualización del software?, bueno, básicamente, la actualización de software puede ser causada por solicitudes de cambio, por arreglo de errores, por solicitudes de nuevas características, por optimizaciones varias, pero también por actualizaciones de protocolo, ¿qué hay de las actualizaciones de protocolo?, discutamos esto por un minuto porque este es un caso muy interesante. Bien, ¿cómo es actualizar el protocolo de tu software?, examinemos algunos casos, tomemos un software no de red, bueno en ese caso podemos seguir esta estrategia, podemos lanzar la nueva versión en un host y luego los usuarios pueden descargarla, a quien le guste lo descarga y el viejo software sigue funcionando, así que básicamente no hay problema, nada se rompe y hay una forma directa, digamos, de actualizar, así que podemos decir que este es un caso fácil. Vamos a pasar a un escenario de servidor de cliente, así que tenemos un software de servidor de cliente, queremos actualizar el protocolo, entre el cliente y el servidor, así que una estrategia que podemos seguir es la siguiente, podemos actualizar el servidor para que funcione en ambos, los protocolos nuevos y los viejos, entonces liberamos el nuevo cliente y el viejo software sigue funcionando. Ahora, en algún momento en el tiempo podemos eliminar todo el soporte al protocolo del servidor, esto esencialmente forzará al cliente a actualizar, de nuevo, esta es una manera directa de hacerlo, no hay implicaciones severas, o problemas, o complejidades, así que, de nuevo, podemos decir que es fácil. Tomemos un caso de software de par a par, también incluso en este escenario más complejo, digamos que uno puede encontrar una clara estrategia para actualizar, por ejemplo, podemos lanzar el nuevo software, los clientes viejos sólo se comunicarán entre ellos y los nuevos clientes se comunicarán sólo con cada uno de ellos, pero a medida que más y más clientes se mueven a la nueva versión, esencialmente los clientes viejos se verán forzados a actualizar ya que no encontrarán pares. Así que también en este caso hay una clara estrategia para hacerlo, así que podemos decir de esa manera que es un caso fácil.

Pero, ¿qué hay acerca del software de blockchain?, bueno en el software de blockchains las cosas no son tan simples, porque si la actualización no toma lugar de manera sincronizada se corre el riesgo de que podría haber una división de la comunidad, y si no nos aseguramos de que ciertas condiciones especiales se mantienen, podría haber un riesgo de seguridad para el nuevo libro contable. Así que en general podemos decir que la actualización de tu software blockchain es una tarea difícil. ¿Por qué las actualizaciones de software para blockchain son difíciles?, bueno, básicamente esto es cierto por dos razones. La primera razón es que las blockchains dependen del consenso, el consenso es el protocolo por el cual las partes logran un común acuerdo sobre el ordenamiento de transacciones. Ahora, una actualización del protocolo cambia la forma en que se logra el consenso, pero lo hace mientras que el consenso está trabajando, así que es como tratar de cambiar las cubiertas de tu coche mientras el coche está en movimiento y entiendes que esto es difícil. Pero no sólo esto, el consenso también se basa en una mayoría honesta, así que no es suficiente decir que algunos de los usuarios han actualizado, necesitamos tener la suficiente honestidad, suficiente cantidad de partes honestas que hayan actualizado con el fin de asegurar que el nuevo libro contable, el libro contable actualizado, es seguro y está protegido. Así que una cosa que debemos recordar de esta presentación es que las actualizaciones de software para las blockchains son difíciles.

¿Qué pasa con la gobernanza?, bueno gobernanza es todo sobre decisiones y también la gobernanza dice quién toma estas decisiones. Así que, por ejemplo, ¿quién decide qué propuesta de actualización avanzará?, o ¿quién decide qué implementación de actualización es correcta y segura de ser aprobada?, finalmente, ¿quien decide cuándo una implementación aprobada será activada? Así que ves que el ciclo de vida de la actualización del software está lleno de muy importantes puntos de decisión. Ahora, si decimos que la comunidad decide, la respuesta a toda esta cuestión es que la comunidad decide, entonces podemos decir que hemos entregado la parte de la decisión a la comunidad y así hemos logrado gobernanza descentralizada. En esta presentación argumentamos que si tenemos establecida gobernanza descentralizada, entonces necesitamos tener actualizaciones de software descentralizadas. ¿Por qué necesitamos actualizaciones de software descentralizadas para lograr gobernanza descentralizada?, porque la gobernanza descentralizada con un mecanismo centralizado de actualización de software es simplemente un oxímoron. Examinemos un escenario muy común que nos encontramos hoy en día en muchos sistemas blockchain ahí fuera que afirman que han logrado gobernanza descentralizada, así que en la pregunta inicial “¿quién decide qué protocolo de actualización avanzar?”, normalmente hay algo de discusión que tiene lugar en algunos foros de discusión o medios sociales para que la comunidad alcance un acuerdo, podemos ver que esta es una forma de consenso social, el problema es que para muchos sistemas blockchain la gobernanza descentralizada termina en algún lugar por ahí. Pero aún hay decisiones más importantes en el camino, así que por ejemplo, "quién decide qué implementación de actualización es correcta y segura de ser aprobada?, normalmente estas preguntas y decisiones difíciles, está el mantenedor del código que toma todas estas duras decisiones y el mantenedor de código, por supuesto, es una autoridad central. Además, cuando se trata de quién decide cuándo una implementación aprobada será activada o si será activada en absoluto, entonces este plazo de activación, de nuevo, es dicho por una autoridad central.

Así que argumentamos que o bien descentralizas todo el camino o no descentralizas en absoluto, y por supuesto descentralizar estas decisiones cruciales no es fácil, es difícil, por eso dijimos que las actualizaciones de software para las blockchains son difíciles, pero ahora decimos que las actualizaciones de software descentralizadas para blockchain son aún más difíciles.

Así que descentralizar las actualizaciones de software es exactamente el problema que intentamos abordar, y déjenme darles una visión general del enfoque que hemos seguido. Para poder lidiar con el problema de descentralizar las actualizaciones de software para blockchains, hemos decidido tomar un enfoque holístico, esto significa que hemos decidido examinar una actualización de software de punta a punta desde la primera fase inicial donde una actualización de software nace como una idea, desde la fase de conceptualización digamos, hasta el final donde la actualización, el cambio, tiene efecto en el sistema blockchain.

Así que hemos tratado de formalizar el problema y proponer una solución y también probar criptográficamente su seguridad, también estamos implementando un prototipo de investigación que pretendemos incorporar a Cardano, por eso estamos usando las herramientas y la metodología utilizada por los ingenieros de Cardano para influir la blockchain Cardano tanto como sea posible. Dos cuestiones que no hemos abordado, la primera tiene que ver con financiación, no hemos lidiado con la financiación en absoluto porque hay una especie de corriente de investigación separada dentro de IOHK que trata con el sistema de tesorería, verás presentaciones relevantes en esta cumbre. Y el otro problema que aún no hemos abordado tiene que ver con los planes de incentivos para votantes y expertos. Bien, ¿qué se necesita para descentralizar actualizaciones de software?, lo primero que se requiere es participación abierta, ¿qué significa eso?, por participación abierta queremos decir que las actualizaciones de software deben ser abiertas a la comunidad, cualquiera que pueda presentar una transacción legítima debe ser capaz de presentar una propuesta de actualización y votar por una propuesta de actualización. Y al hacer esto esencialmente uno define una hoja de ruta del sistema y esta definición de la hoja de ruta del sistema no debería ser un privilegio de los pocos.

Lo siguiente que se requiere es toma de decisiones descentralizada, aquí está nuestra definición del ciclo de vida de la actualización de software, hemos identificado cuatro fases distintas en este ciclo de vida y estas fases son irrelevantes de la configuración, ya sea que es una configuración centralizada o descentralizada. Inicialmente tenemos la fase de ideación donde la actualización del software nace como una idea y se presenta en forma de un documento, de una propuesta, para ser discutido. Luego tenemos la fase de implementación donde la idea, el documento, es transformado en código, debe ser presentado a la fase de aprobación con el fin de ser revisado, probado a fondo, y si todo está bien, ser aprobado. Finalmente tenemos la fase de activación donde los cambios realmente surten efecto en el sistema.

OK, ¿cuáles son las decisiones críticas en este ciclo de vida de la actualización del software?, bien, la primera decisión importante es durante la fase de ideación, donde uno tiene que decidir si una propuesta se moverá adelante o no. La segunda decisión importante es durante la fase de aprobación, en la que la implementación de una propuesta específica tiene que ser revisada y hay que tomar una decisión de si el código presentado es correcto y seguro de ser desplegado. Finalmente, en la fase de activación, uno tiene que decidir “si” y “cuándo” deberíamos activar el cambio específico. Así que con el fin de descentralizar estos tres importantes puntos de decisión hemos puesto en marcha tres procesos de votación, con el fin de permitir una decisión colectiva, permitir a la comunidad decidir sobre estos importantes puntos de decisión. Sin embargo reconocemos que las actualizaciones de software son entidades técnicas, así que una importante experiencia técnica podría ser requerida para que alguien investigue la decisión. Así que por esta razón hemos puesto en marcha un proceso de delegación en el que un votante puede delegar su derecho de voto a algunos expertos para votar en su nombre.

Bien, ¿qué más se necesita para descentralizar las actualizaciones de software?, bueno, creemos que el mecanismo de actualización de software debería ser un proceso impulsado por el protocolo. Creemos que no es suficiente tener sólo una discusión informal basada en procesos que tiene lugar a través de los medios sociales, aunque esto tiene valor significativo, especialmente en el comienzo, pero esto no es suficiente. Creemos que tiene que ser parte de un protocolo de actualización que ofrece garantías de seguridad específicas y que deja atrás un rastro de eventos de actualizaciones en cadena inmutable. Una vez que tengamos este rastro de eventos de actualización entonces podemos decir que nuestro mecanismo de actualización de software es transparente y auditable. Creemos que cualquiera debería ser capaz de responder a la pregunta de "¿cuándo, por qué y cómo el sistema ha evolucionado de la forma en que lo ha hecho?, osea la creencia de que la historia evolutiva del sistema debería estar abierta a todos, y esencialmente formar un registro blockchain de liberación pública consistente, global, evidente, de esta manera, este registro de liberación será un registro histórico totalmente auditable de la evolución del sistema.

Lo siguiente que tenemos que tomar en cuenta es la activación, un mecanismo de actualización de software descentralizado debe asegurar un mecanismo de activación seguro, resistente a divisiones de cadena. Tiene que asegurar que el mecanismo de activación debe tener lugar de manera sincronizada con el fin de evitar divisiones de cadena. También asegurar que un supuesto de seguridad específico se sostiene, por ejemplo, que suficiente en participación se ha actualizado, y también evitar el ataque donde un adversario bloquea la activación de una propuesta específica, lo que llamamos un ataque de negación de activación. Vamos a discutir la activación un poco más, ¿por qué necesitamos una activación segura?, así que, ¿cuáles son los riesgos de seguridad que tenemos que considerar? Imagina que cuando una parte se actualiza, entonces esencialmente comienza a hablar un nuevo lenguaje, un lenguaje diferente al de las partes que todavía no han actualizado. Ahora, si activamos demasiado pronto, está el riesgo de división, podríamos particionar la comunidad en dos mitades, así que esencialmente podríamos tener una división de comunidad. No sólo esto, si no estamos seguros de que suficientes partes honestas han actualizado y la suposición de mayoría honesta, que es una suposición de seguridad básica, no se sostiene, entonces el adversario puede tomar el control de la nueva cadena y hacer, por ejemplo, un doble gasto. Ahora, en el otro extremo tenemos una activación que tiene lugar demasiado tarde, esto significa que exigimos que un muy alto porcentaje de las partes necesita actualizarse antes de activarse. Ahora, si demandamos un gran porcentaje de participación en la actualización, entonces el adversario podría bloquear la activación de una actualización al no actualizar en absoluto, llamamos a este ataque negación de activación. Así que tenemos que encontrar un equilibrio entre los dos extremos y activar sólo en el momento adecuado, ni demasiado tarde ni demasiado pronto.

Un protocolo de activación es un protocolo que hace la transferencia del viejo libro contable al nuevo libro contable, así que un protocolo de activación seguro debe garantizar que el nuevo libro contable es seguro, pero no sólo esto, también que el estado del viejo libro contable se ha trasladado con éxito al nuevo libro contable, porque el nuevo libro contable debe ser una continuación del viejo libro contable, no es una nueva blockchain que empieza de cero. En el lenguaje de la criptografía vemos que el nuevo libro contable está seguro si disfruta de las propiedades de consistencia y vivacidad. Consistencia significa que eventualmente todas las partes verán que tendrán la misma vista del orden de las transacciones y vivacidad significa que una transacción emitida por una parte honesta eventualmente alcanzará la vista de libro contable de todas las partes honestas.

Lo siguiente que necesitamos es una lógica de actualización basada en metadatos, ¿qué es esto?, bueno esencialmente esto significa que reconocemos el hecho de que las actualizaciones de software no son todas iguales, una talla no sirve para todo, hay diferentes aspectos que especifican el contexto digamos, de una actualización de software, por ejemplo, las actualizaciones de software podrían tener varias regiones diferentes de cambio, como arreglo de errores o peticiones de cambio, etc. O podrían tener una prioridad diferente de cambio, hay actualizaciones de software críticas y no críticas, o podrían tener un totalmente diferente impacto del cambio, por ejemplo, hay actualizaciones de software que impactan el protocolo de consenso y otras que no tienen nada que ver con el protocolo de consenso. El tipo de cambio podría ser diferente, ya sea una bifurcación blanda o dura y también la complejidad del cambio podría ser totalmente diferente, hay actualizaciones de software simples, que son fáciles de implementar y hay actualizaciones de software difíciles y complejas que son difíciles de desplegar. Así que necesitamos definir un rico conjunto de metadatos con el fin de determinar el contexto correcto de una actualización de software, esto es muy importante. Así que una vez que tenemos estos metadatos, entonces podemos definir una política de actualización impulsada por metadatos, por ejemplo, utiliza metadatos para definir la duración de los períodos de votación, o la prioridad de activación, o la ventana de despliegue, etc. También estos metadatos pueden ayudarnos a resolver dependencias e identificar conflictos y proceder a alguna resolución de conflictos.

Finalmente, un mecanismo de actualización de software descentralizado debe ser escalable, de ninguna manera debería impactar negativamente en el rendimiento del sistema blockchain. Y no sólo eso, debería ser escalable a miles o incluso millones de participantes. También en el contexto de nuestro trabajo estamos implementando un prototipo de investigación que materializa nuestra solución para mecanismos de actualizaciones de software descentralizadas, este prototipo se implementa en el contexto de un proyecto de investigación financiado por la Unión Europea que se llama Privilege, así que nuestro objetivo en este proyecto es construir un mecanismo de actualización de software para Cardano, así que la integración con Cardano es una alta prioridad y es por eso que estamos utilizando Haskell, las bibliotecas, la metodología y herramientas utilizadas por los ingenieros de Cardano para construir Cardano. Estamos implementando todas las fases del ciclo de vida de una actualización de software, hemos empezado con una implementación de un sólo nodo y pronto nos moveremos a un modo de red en el que nos integraremos con la capa de consenso y desplegaremos en una testnet. Estamos planeando definir un rico conjunto de criterios de validación y ejecutar extensas pruebas de validación.

Enlace a Parte 2 de 2

1 Like