“Descentralización” es una de las palabras que se utilizan con más frecuencia en los conceptos sobre la criptoeconomía, y a menudo se considera incluso como toda la razón de ser de una cadena de bloques, pero, también es una de las palabras que quizás se define peor.
Se han invertido miles de horas de investigación, y miles de millones de dólares de hashpower, con el único propósito de intentar lograr la descentralización, y de protegerla y mejorarla, y cuando los debates rivalizan es muy común que los defensores de un protocolo (o de una extensión del mismo) afirmen que las propuestas contrarias están “centralizadas” como argumento definitivo de derribo y descredito.
Pero a menudo hay mucha confusión en cuanto a lo que esta palabra significa realmente. Consideremos, por ejemplo, el siguiente diagrama completamente inútil, pero desgraciadamente demasiado común:
Veamos las dos respuestas en Quora a la pregunta “¿cuál es la diferencia entre distribuido y descentralizado?
La primera repite esencialmente el diagrama anterior, mientras que la segunda afirma de forma totalmente diferente que “distribuido significa que no todo el procesamiento de las transacciones se realiza en el mismo lugar”, mientras que “descentralizado significa que no hay una sola entidad que tenga el control de todo el procesamiento”.
Por otro lado, la respuesta principal en Ethereum ofrece un diagrama muy similar, pero con las palabras “descentralizado” y “distribuido” cambiadas. Está claro que hace falta una aclaración.
Tres tipos de descentralización
Cuando se habla de descentralización del software, en realidad hay tres ejes distintos de centralización/descentralización a los que se puede referir. Aunque en algunos casos es difícil entender cómo se puede tener uno sin el otro, en general son bastante independientes el uno del otro. Los ejes son los siguientes:
- (Des)centralización arquitectónica: ¿de cuántos ordenadores físicos se compone un sistema? ¿Cuántos de esos ordenadores pueden tolerar una avería en un momento dado?
- (Des)centralización política: ¿cuántos individuos u organizaciones controlan en última instancia los ordenadores que componen el sistema?
- (Des)centralización lógica: ¿la interfaz y las estructuras de datos que el sistema presenta y mantiene se parecen más a un único objeto monolítico o a un enjambre amorfo? Una heurística sencilla es: si se corta el sistema por la mitad, incluyendo tanto a los proveedores como a los usuarios, ¿seguirán ambas mitades funcionando plenamente como unidades independientes?
Podemos intentar plasmar estas tres dimensiones en un gráfico:
Definiciones y ejemplos de descentralización
Ten en cuenta que muchas de estas definiciones son muy aproximadas y bastante discutibles. Pero intentemos repasar alguna de ellas:
- Las empresas tradicionales están políticamente centralizadas (un director general), arquitectónicamente centralizadas (una sede social) y lógicamente centralizadas (no se pueden dividir por la mitad)
- El derecho civil se basa en un órgano legislativo centralizado, mientras que el derecho común se construye a partir de los precedentes elaborados por muchos jueces individuales. El derecho civil sigue teniendo cierta descentralización arquitectónica, ya que hay muchos tribunales que, sin embargo, tienen una gran discrecionalidad, pero el derecho común tiene más. Ambos están lógicamente centralizados (“la ley es la ley”).
- Las lenguas están lógicamente descentralizadas; el inglés hablado entre Alice y Bob y el inglés hablado entre Charlie y David no tienen por qué coincidir en absoluto. No se necesita una infraestructura centralizada para que exista un idioma, y las reglas de la gramática inglesa no son creadas ni controladas por una sola persona (mientras que el esperanto fue inventado originalmente por Ludwig Zamenhof, aunque ahora funciona más como un idioma vivo que evoluciona gradualmente sin autoridad)
- BitTorrent está lógicamente descentralizado de forma similar a como lo está el inglés. Las redes de distribución de contenidos son similares, pero están controladas por una sola empresa.
- Las blockchains están políticamente descentralizadas (nadie las controla) y arquitectónicamente descentralizadas (no hay un punto central de fallo en la infraestructura) pero están lógicamente centralizadas (hay un estado comúnmente acordado y el sistema se comporta como un único ordenador)
Centralización y descentralización aplicadas
Muchas veces, cuando la gente habla de las virtudes de una blockchain, describen los beneficios de la conveniencia de tener “una base de datos central”; esa centralización es la centralización lógica, y es un tipo de centralización que podría ser buena en muchos casos (aunque Juan Benet de IPFS también presionaría por la descentralización lógica siempre que sea posible, porque los sistemas lógicamente descentralizados tienden a ser buenos para sobrevivir a las particiones de la red, funcionan bien en las regiones del mundo que tienen mala conectividad, etc.; véase también este artículo de Scuttlebot que aboga explícitamente por la descentralización lógica).
La centralización arquitectónica a menudo conduce a la centralización política, aunque no necesariamente: en una democracia formal, los políticos se reúnen y celebran votaciones en alguna cámara de gobierno física, pero los encargados de mantener esta cámara no acaban obteniendo ninguna cantidad sustancial de poder sobre la toma de decisiones como resultado.
En los sistemas informáticos, la descentralización arquitectónica, pero no la política, puede darse si existe una comunidad en línea que utiliza un foro centralizado por conveniencia, pero en la que existe un contrato social ampliamente acordado según el cual si los propietarios del foro actúan de forma maliciosa, todo el mundo se trasladará a otro foro (las comunidades que se forman en torno a la rebelión contra lo que consideran censura en otro foro probablemente tengan esta propiedad en la práctica).
La centralización lógica hace que la descentralización arquitectónica sea más difícil, pero no imposible: véase cómo las redes de consenso descentralizadas ya han demostrado que funcionan, pero son más difíciles que mantener BitTorrent. Y la centralización lógica hace que la descentralización política sea más difícil – en los sistemas lógicamente centralizados, es más difícil resolver las disputas simplemente acordando “vivir y dejar vivir”.
Tres razones para la descentralización
La siguiente pregunta es: ¿por qué es útil la descentralización en primer lugar? En general, se plantean varios argumentos:
- Tolerancia a los fallos: los sistemas descentralizados tienen menos probabilidades de fallar accidentalmente porque dependen de muchos componentes separados que no son probables.
- Resistencia a los ataques: los sistemas descentralizados son más costosos de atacar y destruir o manipular porque carecen de puntos centrales sensibles que puedan ser atacados a un coste mucho menor que el tamaño económico del sistema circundante.
- Resistencia a la colusión: es mucho más difícil que los participantes en los sistemas descentralizados utilicen la colusión para actuar de forma que les beneficie a costa de otros participantes, mientras que las direcciones de las empresas y los gobiernos pueden usar la colusión de forma que se benefician a sí mismos, pero perjudican a los ciudadanos, clientes, empleados y al público en general menos coordinados todo el tiempo.
Los tres argumentos son importantes y válidos, pero los tres argumentos conducen a algunas conclusiones interesantes y diferentes cuando se empieza a pensar en las decisiones de protocolo teniendo en cuenta las tres perspectivas individuales. Intentemos ampliar cada uno de estos argumentos uno por uno.
Tolerancia a los fallos
En cuanto a la tolerancia a los fallos, el argumento central es sencillo. ¿Qué es menos probable que ocurra: que falle un solo ordenador o que fallen cinco de diez ordenadores al mismo tiempo?
El principio no es controvertido y se utiliza en la vida real en muchas situaciones, como los motores de los aviones, los generadores de energía de reserva, especialmente en lugares como los hospitales, la infraestructura militar, la diversificación de la cartera financiera y, sí, las redes informáticas.
Sin embargo, este tipo de descentralización, aunque sigue siendo eficaz y muy importante, a menudo resulta ser mucho menos que una panacea de lo que un modelo matemático ingenuo podría predecir a veces. La razón es el fallo de modo común. Es cierto que cuatro motores de avión tienen menos probabilidades de fallar que un motor de avión, pero ¿qué pasaría si los cuatro motores se fabricaran en la misma fábrica y el mismo empleado deshonesto introdujera un fallo en los cuatro?
¿Las cadenas de bloques, tal y como son hoy en día, consiguen proteger contra los fallos de modo común? No necesariamente. Consideremos los siguientes escenarios:
- Todos los nodos de una blockchain ejecutan el mismo software cliente, y este software cliente resulta tener un error.
- Todos los nodos de una blockchain ejecutan el mismo software cliente, y el equipo de desarrollo de este software resulta estar corrompido socialmente.
- El equipo de investigación que propone las actualizaciones del protocolo resulta estar socialmente corrupto.
- En una blockchain de prueba de trabajo, el 70% de los mineros están en el mismo país, y el gobierno de este país decide confiscar todas las granjas mineras por motivos de seguridad nacional.
- La mayoría del hardware de minería es construido por la misma compañía, y esta compañía es sobornada o coaccionada para implementar una puerta trasera que permite que este hardware sea apagado a voluntad.
- En una blockchain de prueba de participación, el 70% de los tokens se mantienen en un único Exchange.
Conclusiones de una visión holística de la descentralización
Una visión holística de la descentralización de la tolerancia a los fallos examinaría todos estos aspectos y vería cómo se pueden minimizar. Algunas conclusiones naturales que surgen son bastante obvias:
- Es de vital importancia tener múltiples implementaciones que compitan entre sí.
- Hay que democratizar el conocimiento de las consideraciones técnicas que subyacen a las actualizaciones de los protocolos, para que más personas puedan sentirse cómodas participando en los debates de investigación y criticando los cambios de protocolo que son claramente malos.
- Los desarrolladores e investigadores principales deben ser empleados por múltiples empresas u organizaciones (o, alternativamente, muchos de ellos pueden ser voluntarios).
- Los algoritmos de minería deben diseñarse de forma que se minimice el riesgo de centralización
- Lo ideal es que utilicemos la prueba de participación para alejarnos por completo del riesgo de centralización del hardware (aunque también deberíamos tener cuidado con los nuevos riesgos que surgen debido a la prueba de participación).
Nótese que el requisito de tolerancia a fallos en su forma ingenua se centra en la descentralización arquitectónica, pero una vez que se empieza a pensar en la tolerancia a fallos de la comunidad que gobierna el desarrollo continuo del protocolo, entonces la descentralización política también es importante.
Resistencia a los ataques
Ahora, veamos la resistencia al ataque. En algunos modelos económicos puros, a veces se obtiene el resultado de que la descentralización ni siquiera importa.
Si se crea un protocolo en el que se garantiza que los validadores perderán 50 millones de dólares si se produce un ataque del 51% (es decir, la reversión de la finalidad), entonces no importa realmente si los validadores están controlados por una empresa o por 100 empresas: 50 millones de dólares de margen de seguridad económica son 50 millones de margen de seguridad económica.
De hecho, hay profundas razones teóricas por las que la centralización puede incluso maximizar esta noción de seguridad económica (el modelo de selección de transacciones de las cadenas de bloques existentes refleja esta idea, ya que la inclusión de transacciones en los bloques a través de los mineros/proponentes de bloques es en realidad una dictadura de rápida rotación).
Sin embargo, una vez que se adopta un modelo económico más rico, y en particular uno que admite la posibilidad de coerción (o cosas mucho más suaves como ataques DoS dirigidos contra nodos), la descentralización se vuelve más importante.
Si se amenaza a una persona con la muerte, de repente 50 millones de dólares ya no le importarán tanto. Pero si los 50 millones de dólares se reparten entre diez personas, entonces tienes que amenazar a diez veces más personas, y hacerlo todo al mismo tiempo.
La asimetría y PoS frente a PoW
En general, el mundo moderno se caracteriza en muchos casos por una asimetría de ataque/defensa a favor del atacante – un edificio que cuesta 10 millones de dólares de construir puede costar menos de 100.000 dólares de destruir, pero la palanca del atacante es a menudo sublineal: si un edificio con un coste de 10 millones de dólares para su construcción cuesta 100.000 dólares para su destrucción, un edificio que cuesta 1 millón de dólares de puede costar, de forma realista, quizás 30.000 dólares de destruir. Lo más pequeño da mejores ratios.
¿A qué conduce este razonamiento? En primer lugar, empuja fuertemente a favor de la prueba de participación sobre la prueba de trabajo, ya que el hardware informático es fácil de detectar, regular o atacar, mientras que las monedas pueden ocultarse mucho más fácilmente (la prueba de participación también tiene una fuerte resistencia a los ataques por otras razones).
En segundo lugar, es un punto a favor de tener equipos de desarrollo ampliamente distribuidos, incluyendo la distribución geográfica. En tercer lugar, implica que hay que tener en cuenta tanto el modelo económico como el modelo de tolerancia a fallos a la hora de diseñar protocolos de consenso.
Resistencia a la colusión
Por último, podemos llegar al que quizá sea el argumento más intrincado de los tres, la resistencia a la colusión. La colusión es difícil de definir; tal vez la única forma realmente válida de expresarla sea decir simplemente que la colusión es “una coordinación que no nos gusta”.
Hay muchas situaciones en la vida real en las que, aunque tener una coordinación perfecta entre todos sería ideal, que un subgrupo pueda coordinarse mientras los demás no pueden es peligroso.
Un ejemplo sencillo es la legislación antimonopolio: barreras reguladoras deliberadas que se colocan para dificultar que los participantes de un lado del mercado se unan y actúen como un monopolio y obtengan beneficios ajenos a costa del otro lado del mercado y del bienestar social general. Otro ejemplo son las normas contra la coordinación activa entre los candidatos y los super-PAC en Estados Unidos, aunque han resultado difíciles de aplicar en la práctica.
Un ejemplo mucho más pequeño es una norma en algunos torneos de ajedrez que impide que dos jugadores jueguen muchas partidas entre sí para intentar aumentar la puntuación de uno de ellos. Se mire por donde se mire, los intentos de evitar la coordinación no deseada en instituciones sofisticadas están por todas partes.
En el caso de los protocolos de blockchain, el razonamiento matemático y económico que subyace a la seguridad del consenso suele basarse de forma crucial en el modelo de elección no coordinada, o en la suposición de que el juego está formado por muchos actores pequeños que toman decisiones de forma independiente.
Si un actor consigue más de un tercio de la potencia de minería en un sistema de prueba de trabajo, puede obtener grandes beneficios mediante la minería egoísta.
Sin embargo, ¿podemos decir realmente que el modelo de elección descoordinada es realista cuando el 90% de la potencia minera de la red Bitcoin está lo suficientemente bien coordinada como para presentarse juntos en la misma conferencia?
Los defensores de las blockchains también afirman que es más seguro construir sobre ellas porque no pueden cambiar sus reglas arbitrariamente cuando quieran, pero este caso sería difícil de defender si los desarrolladores del software y del protocolo trabajaran todos para una misma empresa, formaran parte de una misma familia y se sentaran en una misma habitación.
La cuestión es que estos sistemas no deberían actuar como monopolios unitarios interesados. Por lo tanto, se puede argumentar que las cadenas de bloques serían más seguras si estuvieran más descoordinadas.
Sin embargo, esto presenta una paradoja fundamental. Muchas comunidades, incluida la de Ethereum, suelen ser elogiadas por tener un fuerte espíritu comunitario y por ser capaces de coordinarse rápidamente para implementar, liberar y activar un hard fork para solucionar problemas de denegación de servicio en el protocolo en un plazo de seis días. Pero, ¿cómo podemos fomentar y mejorar este buen tipo de coordinación, pero al mismo tiempo evitar la “mala coordinación” que consiste en que los mineros intenten fastidiar a todos los demás coordinando repetidamente los ataques del 51%?
Hay tres maneras de responder a esto:
- No molestarse en mitigar la coordinación no deseada; en su lugar, tratar de construir protocolos que puedan resistirla.
- Intentar encontrar un término medio que permita una coordinación suficiente para que un protocolo evolucione y avance, pero no lo suficiente como para permitir ataques.
- Intentar distinguir entre la coordinación beneficiosa y la perjudicial, y facilitar la primera y dificultar la segunda.
El primer enfoque constituye una gran parte de la filosofía de diseño de Casper. Sin embargo, por sí mismo es insuficiente, ya que basarse únicamente en la economía no permite abordar las otras dos categorías de preocupaciones sobre la descentralización.
La segunda es difícil de diseñar explícitamente, sobre todo a largo plazo, pero a menudo se produce accidentalmente. Por ejemplo, el hecho de que los desarrolladores del núcleo de bitcoin hablen generalmente en inglés, pero los mineros hablen generalmente en chino, puede considerarse un accidente feliz, ya que crea una especie de gobierno “bicameral” que dificulta la coordinación, con el beneficio secundario de reducir el riesgo de fallo del modo común, ya que las comunidades inglesa y china razonarán al menos de forma separada debido a la distancia y a las dificultades de comunicación y, por tanto, es menos probable que ambas cometan el mismo error.
El tercero es un reto social más que otra cosa; las soluciones a este respecto pueden ser:
- Intervenciones sociales que traten de aumentar la lealtad de los participantes a la comunidad en torno a la blockchain en su conjunto y sustituyan o desalienten la posibilidad de que los actores de un lado de un mercado se fidelicen directamente entre sí.
- Promover la comunicación entre los distintos “lados del mercado” en un mismo contexto, para reducir la posibilidad de que tanto los validadores como los desarrolladores o los mineros comiencen a verse como una “clase” que debe coordinarse para defender sus intereses frente a otras clases.
- Diseñar el protocolo de forma que se reduzca el incentivo para que los validadores/mineros entablen “relaciones especiales” uno a uno, redes de retransmisión centralizadas y otros mecanismos similares de superprotocolo.
- Normas claras sobre cuáles son las propiedades fundamentales que debe tener el protocolo, y qué tipo de cosas no deben hacerse, o al menos sólo deben hacerse en circunstancias muy extremas.
Este tercer tipo de descentralización, la descentralización como herramienta para evitar la coordinación no deseada, es quizás el más difícil de conseguir, y las compensaciones son inevitables. Tal vez la mejor solución sea apoyarse en el único grupo que está garantizado que está bastante descentralizado: los usuarios del protocolo.
