Traducción al español de “Cardano’s path to decentralization”
Publicado por Marcin Szamotulski en el blog de IOHK el 8 de Julio de 2020
Tres mini-protocolos son vitales para el funcionamiento de la red
Los próximos lanzamientos de Cardano y el protocolo de Ouroboros contienen cambios que nos guían hacia la descentralización y la era Shelley. Este post de Inmersión Profunda explica cómo nos estamos acercando a esta fase. Con el lanzamiento del algoritmo Praos para Shelley, que viene con el proceso de staking, se pueden crear stake pools para que los propietarios de ada puedan delegar su participación. El equipo de redes se centra ahora en dos características que nos permitirán ejecutar un sistema totalmente descentralizado. Permítanme primero describir brevemente cómo se diseña y construye la red y dar una visión general de dónde estamos en este momento. Este post comenzará en la parte superior de nuestras abstracciones y bajará por la pila. Esperemos que sea un viaje interesante a través de nuestro diseño.
Protocolos mecanografiados
En la parte superior de la pila está el marco de protocolos mecanografiados de IOHK, que nos permite diseñar protocolos a nivel de aplicación. El objetivo de nivel superior del diseño de protocolos para Ouroboros es distribuir cadenas de bloques y transacciones entre los participantes en la red y eso se logra mediante tres mini-protocolos:
- chain-sync se utiliza para sincronizar eficientemente una cadena de encabezamientos;
- block-fetch nos permite tirar de los bloques;
- tx-submission se utiliza para presentar transacciones.
Los tres miniprotocolos se diseñaron cuidadosamente después de considerar las amenazas que pueden surgir al operar un sistema descentralizado. Esto es muy importante, porque los ataques cibernéticos son muy comunes, especialmente contra objetivos que presentan fuertes incentivos. Hay una gama de posibles ataques a este nivel de los que tenemos que ser capaces de defendernos y un tipo con el que fuimos muy cuidadosos es el de los ataques de consumo de recursos. Para defenderse de estos ataques, los protocolos permiten al lado del consumidor mantener el control de la cantidad de datos que recibirá y, en última instancia, mantener el uso de sus recursos (por ejemplo, memoria, CPU y descriptores de archivos abiertos) por debajo de un cierto nivel.
Si está interesado en más detalles sobre los protocolos mecanografiados, dimos charlas y organizamos talleres en los eventos de Haskell el año pasado y estos fueron muy bien recibidos por la comunidad de ingenieros. En particular, vea la charla de Duncan Coutts en Haskell eXchange y el taller que dirigí en Monadic Party.
El papel del multiplexor
Los protocolos TCP/IP forman el conjunto de protocolos más omnipresente en Internet. También son algunos de los protocolos más estudiados y están disponibles en casi todos los sistemas operativos y arquitecturas de ordenadores, por lo que son una buena primera opción para nuestros propósitos. El TCP/IP nos da acceso a un canal de comunicación bidireccional entre los servidores de Internet. El único requisito de alto nivel de los protocolos mecanografiados es una entrega ordenada de paquetes de red, que está garantizada por el protocolo TCP.
Los sistemas operativos limitan el número de conexiones en un momento dado. Por ejemplo, Linux, por defecto, puede abrir 1.024 conexiones por proceso, pero en MacOS el límite es sólo 256. Para evitar el uso excesivo de recursos utilizamos un multiplexor. Esto nos permite combinar los canales de comunicación en uno solo, de modo que podemos ejecutar los tres mini-protocolos en una sola conexión TCP. Otra forma de ahorrar recursos es utilizar la bidireccionalidad de TCP: esto significa que se pueden enviar y recibir mensajes en ambos extremos simultáneamente. No hemos usado esa característica en la era del reinicio de Byron, pero queremos aprovecharla en la era descentralizada Shelley.
El gobernador de par a par
Queremos usar conexiones bidireccionales, ejecutando los tres mini-protocolos en ambas direcciones, por lo que necesitamos tener un componente que sepa qué conexiones se están ejecutando actualmente. Cuando un nodo se conecta a un nuevo par, podemos comprobar primero si ya tiene una conexión abierta con ese par, lo que sería el caso si el par ya se hubiera conectado a él. Pero esta es sólo una parte de la gestión de la conexión que necesitaremos.
Otro requisito viene del gobernador de par a par. Esta parte del sistema es responsable de encontrar los pares, y elegir algunos de ellos para conectarse. Hacer una conexión lleva algún tiempo, dependiendo de factores como la calidad de la conexión de la red y la distancia física. Ouroboros es un sistema en tiempo real, así que es bueno ocultar algo de latencia aquí. No sería bueno si el sistema estuviera bajo presión y aún así necesitara conectarse con nuevos compañeros; es mucho mejor si el sistema mantiene un puñado de conexiones de repuesto que estén listas para asumir cualquier nueva tarea. Un nodo debería ser capaz de tomar una decisión educada sobre qué conexiones existentes promover para obtener el mejor rendimiento. Por esta razón decidimos tener tres tipos de pares:
- los pares fríos saben de su existencia, pero no hay una conexión de red establecida.
- los pares cálidos tienen una conexión, pero sólo se utiliza para las mediciones de la red y no se utiliza ninguno de los mini-protocolos de nodo a nodo;
- los pares calientes tienen una conexión, que está siendo utilizada por los tres mini-protocolos nodo a nodo.
Un nodo puede conocer potencialmente miles de pares fríos, mantener hasta cientos de pares cálidos y tener decenas de pares calientes (20 parece una cifra razonable por el momento). Hay preguntas interesantes y desafiantes en torno al diseño de las políticas que impulsarán las decisiones del gobernador de par a par. La elección de tales políticas afectará a la topología de la red y alterará las características de rendimiento de la red, incluyendo el rendimiento bajo carga o la acción maliciosa. Esto conformará la distribución oportuna de la difusión de los bloques (parametrizada por el tamaño de los bloques), o las transacciones. Dado que el funcionamiento de un sistema de este tipo tiene muchas incógnitas, nos gustaría dividirlo en dos partes. Para la primera fase, que será liberada en unas pocas semanas (probablemente poco después del lanzamiento de Praos, también conocido como el lanzamiento Shelley), queremos estar listos con todos los componentes de par a par pero aún funcionando en un modo federado. Además, entregaremos el gestor de conexiones junto con la implementación de un servidor que acepte las conexiones, y su integración con el gobernador par a par. En esta fase, el gobernador par a par será usado como un mecanismo de suscripción. La ejecución de varias redes de prueba privadas y públicas, junto con nuestras extensas pruebas debería darnos suficiente confianza antes de liberar esto a la red principal.
En la segunda fase, extenderemos los mini-protocolos con un protocolo de chismes. Esto permitirá intercambiar información sobre los pares, finalizar las medidas de calidad de la red y conectarlos a la lógica de búsqueda de bloques (que decide de quién se descarga un bloque) así como al gobernador de par a par. En esta etapa, nos gustaría diseñar y realizar algunos experimentos para descubrir cómo las políticas de par a par dan forma a la red, y comprobar cómo se recuperan de cualquier topología que no sea la óptima (o adversaria).
Espero que esto les dé una buena idea de dónde estamos con el diseño y la implementación de la descentralización para Cardano, y nuestra hoja de ruta hacia la era Shelley. Puede seguir el progreso en nuestros informes semanales.
Este es el tercero de los posteos técnicos de desarrollo de Inmersión Profunda de nuestros equipos de ingeniería de software.