La semana pasada, lanzamos una nueva versión de nuestra red de pruebas Pollen que contiene mana. Con este lanzamiento, demostramos la madurez y la eficiencia de nuestra solución de mana. Pronto, el mana se implementará en muchos módulos, un paso importante en el camino hacia Nectar, nuestra próxima y primera testnet del Coordicide totalmente funcional.
A la luz este importante hito, hemos pensado en aclarar algunas preguntas comunes. Desde nuestra primera publicación sobre el mana, que incluía un FAQ (Frequently Asked Questions), se han planteado varias preguntas por diferentes partes que queremos abordar con este post. Hemos obtenido estas preguntas de la gente de la comunidad, a través de nuestro Discord y de Reddit. Las preguntas están agrupadas por temas, y debajo de algunas preguntas encontrarás la pregunta original en cursiva.
Los comentarios de partners y de la comunidad son muy valiosos para nosotros, ya que nos muestran qué aspectos son de especial interés, lo que nos ayuda a identificar las áreas de nuestra especificación de mana completa que podríamos optimizar. La especificación completa se publicará antes de que entremos en la fase de «Néctar» de nuestra actual testnet o red de pruebas «Coordicide».
Desde nuestra última publicación, sólo se ha propuesto un cambio relacionado con el mana: se podría permitir a los usuarios con maná cero enviar mensajes cuando la red no esté congestionada, tal y como han solicitado los partners y los miembros de la comunidad en general. Estamos investigando la posibilidad de emitir mensajes para los nodos con un mana bajo o cero durante los periodos de baja congestión, con la condición de que hayan realizado alguna tarea adicional, por ejemplo, una prueba de trabajo. Esto no es en absoluto fácil. Compartiremos lo que nuestra investigación descubra una vez tengamos resultados.
Hay que tener en cuenta que las preguntas sobre el acceso que garantiza una determinada cantidad de maná no son en realidad preguntas sobre el maná en sí, sino sobre nuestro algoritmo de control de la congestión. Por lo tanto, aunque el maná en sí mismo está completo, las preguntas relativas a los nodos de maná cero siguen abiertas. En breve, publicaremos otra entrada en el blog explicando el Algoritmo de Control de Congestión de IOTA.
Un rápido repaso a mana
Para aquellos que no leyeron nuestra primera publicación sobre el mana, he aquí un rápido repaso de lo que es el mana y por qué es importante. Cada vez que una transacción mueve fondos, esa transacción «asigna» una cantidad que se llama mana a un ID de nodo. Por lo tanto, el mana puede considerarse como una Proof of Delegated Token Ownership (Prueba de propiedad de tokens delegados). La única manera de obtener mana es controlando tokens o teniendo algún tipo de relación con alguien que controle tokens. La cantidad de mana que se compromete durante una transferencia se calcula de manera que un atacante no pueda inflar artificialmente el mana que posee un nodo.
¿Por qué es importante el mana? Sin algún tipo de mecanismo de protección, los atacantes podrían atacar una red como IOTA forjando millones de identidades falsas en lo que se denomina un ataque Sybil. Por lo tanto, todas las DLT deben evitar los ataques Sybil conectando la identidad a algún recurso escaso verificable criptográficamente. Proof of Work y Proof of Stake utilizan, respectivamente, energía y tokens como mecanismos de protección sybil.
IOTA utiliza el mana para prevenir los ataques Sybil. Esta es la razón por la que el mana debe ser tenido en cuenta por todos los componentes centrales de Coordicide, como el de Congestion Control Algorithm (Algoritmo Control de Congestión) de IOTA, nuestro algoritmo de consenso (FPC), el autopeering, y nuestro generador de números aleatorios distribuido. Esta es también la razón por la que la implementación de mana en la Tesnet Pollen fue un paso importante para la fase Nectar de la testnet: significa que podemos empezar a proteger los componentes clave del núcleo del protocolo IOTA de vectores de ataque fundamentales.
La diferencia entre mana y el control de congestión
Mana es nuestra propuesta inicial actual para medir el comportamiento de los nodos. En el futuro, mana evolucionará hacia un sistema de reputación multidimensional más complejo para evaluar la contribución de un nodo a la actividad de la red y su seguridad. En la etapa actual, mana se utiliza como datos de entrada para proporcionar identidades infalsificables para varios módulos de Coordicide, incluyendo el Algoritmo de Control de Congestión de IOTA.
Características de Mana
¿Cuál es la duración aproximada de la función de decaimiento?
¿La vida media del maná está más cerca de un minuto o más cerca de un año?
Recuerda que con el método de cálculo de maná 2, el mana decae según una función exponencial y, por tanto, debe ser refrescado con un nuevo pledge. La vida media del decaimiento será cuestión de horas, por ejemplo, 6 horas. Sin embargo, queremos ver cómo funciona esto en la red de pruebas, y ajustaremos este parámetro en consecuencia.
¿Cómo se mide el «mana activo»?
El «maná activo» puede ser calculado de infinitas maneras, dependiendo de su propósito. Estar activo podría significar «el porcentaje de nodos que han enviado al menos una transacción en los últimos X segundos» o podría significar «el porcentaje de nodos que han enviado «suficientes» transacciones con respecto a su reputación».
Para el control de congestión (Congestión Control), el nodo no necesita conocer el mana activo: el nodo simplemente mira su bandeja de entrada y reacciona en función del mana de los nodos emisores. La información sobre la cantidad de mana que posee cualquier nodo está disponible para cualquier nodo en función del ID del nodo emisor que forma parte de cada mensaje que se propaga por la red.
Para el FPC y el autopeering, el módulo de pares mantiene una lista de nodos conocidos que están actualmente en línea. El nodo utiliza esta lista para las consultas FPC y para la selección de vecinos.
Comportamiento malicioso
¿Tendrá Mana los mismos problemas de falta de descentralización que los tokens PoS?
Aproximadamente el 0,06% de las direcciones tienen el -65% de todos los tokens. Esto significa que incluso si el 99,94% de las direcciones contribuyen al maná activo y honesto, eso es sólo ~35% del maná total. ¿Cómo es que el 0,06% de las direcciones que controlan el 65% de los tokens no es un problema para el consenso, o la votación, o el rendimiento de los datos?
En primer lugar, el número de direcciones no se corresponde con el número de personas que utilizan IOTA. Por ejemplo, el 35% de todas las direcciones, es decir, 14000 direcciones, tienen menos de 10 MI. Sería absurdo suponer que estas cantidades son controladas por 14000 individuos. Los monederos y diversas aplicaciones suelen repartir los fondos entre varias direcciones por diversas razones. Por otro lado, los tokens almacenados en frío suelen agruparse en una única dirección. Por lo tanto, la estadística anterior no es sorprendente.
En segundo lugar, esta estadística no es un problema porque la hipótesis de seguridad subyacente se sigue cumpliendo. Según nuestras simulaciones, un atacante necesitaría controlar al menos el 30% (a veces más) del mana de consenso activo para tener una oportunidad razonable de atacar el CPE y provocar un doble gasto. Por lo tanto, una proporción significativa de los principales poseedores de tokens tendría que confabularse para realizar un doble gasto. Dado que el 0,06% de las direcciones sigue siendo varios cientos de direcciones, esto parece poco probable. Además, otros ataques, como los ataques de censura o los ataques de liveness, requerirían mucho más mana.
En tercer lugar, en cualquier DLT, el acceso a la red tiene que estar conectado a algún recurso escaso y verificable criptográficamente. Normalmente, la propiedad de todos los recursos sigue una distribución Zipf: unos pocos tienen mucho, y otros cada vez menos. Por tanto, esta preocupación por la centralización no es exclusiva de IOTA, sino que es endémica de todas las DLT.
Por último, las soluciones de prueba de trabajo/prueba de participación (proof of work/proof of stake) son esquemas rígidos. En comparación, nuestro enfoque es mucho más flexible. La idea es construir un sistema de reputación multidimensional donde el mana es sólo uno de los componentes. Utilizando métricas adicionales -como recompensas por buen comportamiento, nociones de edad y participación en la red, y pérdidas de reputación por nodos egoístas o que se comportan mal- pretendemos reducir las discrepancias de reputación entre todos los nodos.
¿Una distribución centralizada causará problemas?
IOTA 2.0 («Coordicide») está diseñado para no tener grandes concentraciones de poder. A diferencia de la mayoría de los sistemas PoS, IOTA no es una blockchain y por lo tanto no estará limitada por un proceso de elección de líderes. En una blockchain, los bloques son secuenciales y, por lo tanto, sólo se produce un número relativamente pequeño de bloques cada hora, por lo que sólo puede haber un número determinado de productores de bloques.
Sin embargo, en un DAG, varias personas pueden añadir información al mismo tiempo, por lo que los nodos con pequeñas cantidades de mana pueden crear mensajes al mismo tiempo que los grandes poseedores de mana. Incluso si tienes una proporción bastante pequeña de mana, ese mana te garantizará al menos una cantidad mínima de acceso, y ese acceso no puede ser revocado independientemente de cuántos grandes poseedores de mana estén saturando la red. Así, el Algoritmo de Control de Congestión de IOTA (ICCA) puede soportar miles de pequeños poseedores de mana. Al asignar maná de forma proporcional, nos aseguramos de que los «pequeños» tengan su parte justa de poder de voto o acceso.
Comprender la cantidad mínima absoluta de mana necesario para emitir un mensaje forma parte de la investigación sobre los nodos de mana cero.
Con suficiente maná, ¿se puede hacer un gasto doble?
¿Es posible aprobar un gasto doble aprobando dos transacciones conflictivas e incrustándolas en la Tangle si hay suficientes propietarios de nodos maliciosos que las «aprueben»? ¿Cuál es el porcentaje de mana (activo/pasivo) que se necesitaría para hacer esto con éxito? ¿Cómo reaccionarían los nodos honestos ante transacciones retransmitidas, pero conflictivas, que una mayoría de propietarios de nodos maliciosos/poseedores de mana ha votado como legítimas?
Con alrededor del 30% del mana de consenso, un atacante puede manipular potencialmente el algoritmo de votación para hacer que un par de gastos dobles sean válidos. Con este ataque, se desarrollaría una bifurcación, hasta que se resuelva, ningún mensaje sería definitivo.
Sin embargo:
- Ningún atacante tendrá el 30% del mana de consenso de los holdings de IOTA.
- No habrá un mercado legítimo para el mana de consenso, porque no tiene sentido establecerlo. El comercio de maná de acceso tiene un caso de uso legítimo, por lo que un mercado saludable para eso probablemente crecerá. El mana de consenso es puramente de gobierno. Sólo los atacantes lo comprarían. Se necesitaría mucho tiempo y muchos recursos para construir una posición de mercado que se acerque a una situación en la que se pueda conseguir una pluralidad de votos. No tiene sentido que un mercado así madure.
¿Cómo se evitan las inversiones de prioridad?
Esto podría ocurrir con una transacción de mana alto que dependa de una transacción de mana bajo.
Si la transacción A depende de la transacción B, se requiere que B esté en el cono pasado de A. Si un nodo de maná alto emite un mensaje con la transacción A, y un nodo de mana bajo emite la transacción B, A no será gossipados si B no lo es.
Además, en el protocolo gossip, los nodos sólo «hacen gossip cuando se solidifican», lo que significa que un nodo no realizará gossip de un mensaje a menos que sus padres también hayan sido gossipados. De hecho, el algoritmo de control de la congestión ni siquiera considerará un mensaje hasta que haya recibido todo su cúmulo anterior.
Cómo se evita el «mana dusting»
«Mana dusting», o la asignación de mana a nodos inexistentes, llenando así las tablas de nodos de todos?
Todavía no hemos especificado oficialmente ninguna solución concreta para este posible problema.
Cada módulo sólo requiere un «consenso aproximado» sobre el mana, lo que significa que el protocolo tolera pequeñas diferencias en la percepción del maná. Así, el dust mana puede ser eliminado sin mayores repercusiones. Sin embargo, para permitir a los pequeños poseedores de mana, puede tener sentido permitir que el dust mana viva durante un periodo corto, como un día o así, pero después puede ser borrado.
«Transacciones» gratuitas
Cuando no hay congestión, ¿puede un nodo de mana cero emitir transacciones?
En el diseño actual del algoritmo de control de la congestión, se necesita mana para enviar un mensaje. Esto es para evitar que los repentinos y agresivos ataques de spam perturben la red. Como se dijo en la introducción, estamos estudiando la posibilidad de permitir a los nodos hacer alguna prueba de trabajo para emitir mensajes sin mana. Sin embargo, la oportunidad de explotar el ancho de banda no utilizado a bajo coste también puede favorecer a los nodos maliciosos que intenten congestionar la red o, peor aún, crear inconsistencias en el ledger. Dado que IOTA es 100% permissionless, la solución a este problema no es trivial.
Una alternativa es tener faucets de mana, que es algo que la Fundación IOTA u otros grandes titulares de la red podrían mantener. La idea es que los nodos puedan mantener automáticamente una lista de faucets. Desde el dashboard del nodo, el operador del nodo puede solicitar una cantidad mínima de mana de la faucet.
¿Realmente se necesita mana para los mensajes sin valor?
El Algoritmo de Control de Congestión de IOTA trata todos los tipos de mensajes en el Tangle de la misma manera. Las transacciones sin valor (mensajes de datos) se procesarán de la misma manera que las transacciones con valor (mensajes de valor). En tiempos de congestión, un nodo necesitará suficiente maná para emitir cualquiera de ellas.
¿Necesita mana en absoluto si acaba de crear un nodo y quiere hacer una tx de valor?
No necesitarás mana para simplemente «montar un nodo» y monitorizar la maraña. Los nodos de 0-mana pueden utilizar los mismos mecanismos de peering en Chrysalis para simplemente escuchar la red, aunque no tendrán la protección de eclipse que les proporcionaría mana.
Sin embargo, en nuestra versión inicial del Algoritmo de Control de Congestión de IOTA, para enviar transacciones -o emitir cualquier tipo de mensaje- se necesitará maná. Como ya hemos mencionado, estamos investigando cómo permitir a los nodos sin maná enviar mensajes cuando no hay congestión. Tenemos una solución prometedora, pero tenemos que asegurarnos de que no abre ningún vector de ataque. Anunciaremos nuestros resultados más adelante, cuando esta investigación esté más desarrollada.
Mercado de maná
¿Cuál será el valor de mercado de maná?
No lo sabemos. Mana es una solución técnica para varios problemas en una red IOTA descentralizada. El mercado de mana es un subproducto de nuestra intención de crear un protocolo sin permisos que esté tan libre de restricciones como sea posible. Hemos investigado los vectores de ataque que aporta esta solución, pero dejaremos la apreciación de su valor monetario al mercado.
Sin embargo, hay algunas suposiciones razonables que sugieren que el mana tendrá algún tipo de valor de mercado. En primer lugar, si la red se congestiona, el acceso a la red -y, por tanto, el mana- se volverá valioso. Esto es simple economía de la oferta y la demanda, que se aplica a todas las DLT. Sin embargo, este cálculo cambiará con la fragmentación, ya que ésta aumentará en gran medida la oferta de acceso.
En segundo lugar, en la actualidad, algunas entidades corporativas pueden ser reticentes a mantener cualquier criptografía debido a las regulaciones, los impuestos o el escepticismo general. Por lo tanto, el alquiler de maná a través de socios de infraestructura de confianza de IOTA es una forma de que las empresas puedan tener acceso garantizado sin tener tokens.
¿Por qué se puede asignar mana a un nodo diferente?
¿Cuál fue el motivo de la decisión de no asignar mana a los nodos que procesan transacciones? ¿Por qué debería alguien poder asignar maná a otra entidad?
Queremos mantener IOTA tan flexible y libre -significa libertad, no «gratis»- como sea posible. Es casi seguro que habrá casos de uso complicados en el futuro que no queremos restringir por razones arbitrarias.
Cualquiera debería ser capaz de utilizar Mana de la manera que considere oportuna. Esto es válido tanto para los usuarios como para los nodos. Si no asignas maná al nodo que procesa tu transacción, no tienen que procesar tu transacción. Pueden insistir en que todas las transacciones de valor que procesen comprometan maná a su ID de nodo.
Sin embargo, es posible que su nodo sólo necesite su maná de acceso de forma periódica, por ejemplo en las horas de mayor tráfico, sólo durante los días laborables o los fines de semana, o en otros intervalos. Si el propietario del nodo posee una gran cantidad de IOTA y no tiene uso para (parte de) el maná que genera, al poder prometerlo a otros nodos, obtiene una mayor utilidad de su IOTA.
Por ejemplo, algunas empresas podrían no querer tener tokens en un futuro próximo. Tener criptografía en los libros puede crear problemas legales en algunas jurisdicciones, pero aún así podrían querer tener acceso al Tangle. Al separar el compromiso del nodo que procesa la transacción, se habilita un mercado para que puedan comprar el acceso a cambio de fiat y eludir los problemas legales.
Las empresas podrían, por ejemplo, ofrecer nodos públicos para que los usuarios los utilicen y así beneficiarse del maná que generan con ello.
¿Qué ocurre con el maná access no utilizado?
El ancho de banda no utilizado se dividirá proporcionalmente a la cantidad de maná de acceso que tengan los usuarios activos.
Esto significa que si, por ejemplo, tienes un 1% de maná de acceso y el ancho de banda está saturado en un 60%, se te asignará al menos un 1% del 40% no utilizado. Del ancho de banda no utilizado después volverás a obtener el 1%, a perpetuidad, hasta que el ancho de banda esté saturado.
Esto podría congestionar la red hasta su límite, pero nunca impide el acceso a la red de ningún poseedor de maná en función de su maná.
¿Puede alguien hacer spam con fotos de gatos y congestionar la red?
El protocolo no puede determinar qué es spam y qué no lo es. Esta es una característica de la innovación permissionless. Aunque las fotos de gatos pueden parecer triviales para algunos, pueden ser muy importantes para otros. No nos corresponde determinar esto.
Cualquiera debería poder utilizar la red como mejor le parezca, aunque otros no estén de acuerdo. Esta es una propuesta central de DLT, y el maná lo permite de manera justa. La composición de la red congestionada está limitada por la cantidad de maná que posee un spammer. La red sólo puede estar formada por un 100% de imágenes de gatos si el spammer tiene el 100% del maná activo. Así, incluso durante este evento de spam de gatos, se garantiza un rendimiento justo.
Control de la congestión
Esté atento a nuestra próxima entrada en el blog sobre el mecanismo de control de congestión.
¿Cómo se mide cuándo la red está congestionada?
Una Raspberry Pi sólo puede procesar una fracción de un nodo de AWS, por lo que tendrían perspectivas muy diferentes sobre cuándo debe entrar en acción el «control de velocidad basado en el mana», y si divergen, tienes de nuevo efectos de inversión de prioridad.
Para empezar, el algoritmo de control de la congestión no necesita saber si la red está congestionada o no. Si no hay congestión, la bandeja de entrada del nodo estará casi vacía. Cada nodo de la red procesará los mensajes a una tasa máxima fija establecida por el protocolo. Esta tasa determinará los requisitos mínimos de hardware del nodo, incluyendo el ancho de banda y la potencia de cálculo. Cualquier máquina sin estas capacidades no podrá hacer funcionar un nodo. Estableceremos este parámetro de tasa para permitir el tipo de máquinas que consideramos necesarias para hacer funcionar un nodo.
Para que un dispositivo pequeño pueda utilizar la red, no es necesario que ejecute un nodo o incluso un monedero. Normalmente, los dispositivos IoT de hoy en día se controlan a través de una pasarela más potente, que cuenta con una conexión fiable a Internet. La pasarela puede ejecutar un monedero o un nodo. Por lo tanto, para habilitar estos dispositivos de baja potencia, sólo tenemos que asegurarnos de que cualquier aplicación utilizada por los dispositivos de baja potencia pueda funcionar a través de una pasarela.
En el futuro, la fragmentación permitirá una red más diversa, ya que no todos los dispositivos tendrán que procesar todos los mensajes. Entonces, los dispositivos de baja potencia podrán ejecutar fragmentos más pequeños de la red como un nodo.
¿Se puede jugar con el sistema para congestionar la red?
¿Cuál es el porcentaje de maná en manos de propietarios honestos de nodos necesario para evitar la saturación artificial de la red, con el fin de impedir la aparición de un mercado de transacciones de pago, suponiendo que los propietarios de nodos maliciosos puedan saturar la red artificialmente («spam») para poder vender su capacidad de red (o maná) (al mejor postor).
En primer lugar, un mercado potencial de maná no depende únicamente de la congestión. Las empresas que no quieren criptomonedas en sus libros ya estarán en el mercado de maná sin congestión.
A continuación, es importante darse cuenta de que su maná garantiza el acceso a la red, proporcional a la cantidad de maná que tiene. Ningún tipo de centralización por parte de otros poseedores puede impedir tu acceso; no pueden congestionar la red de forma injusta. Siempre tienes esa porción de ancho de banda disponible para ti.
Comportamiento del nodo
¿Puede un nodo determinar si el emisor de una transacción le acreditará maná antes de aceptar y retransmitir una transacción?
Sí.
¿Está firmada esa propiedad?
Sí, la propiedad está firmada.
¿Pueden los nodos rechazar fácilmente las transacciones que no les acrediten mana?
¿Qué coste tiene para el nodo (wrt DoS) resolverlo de forma sincrónica para poder rechazar la transacción y que el usuario se entere?
Es trivial verificar y rechazar tales transacciones.
La configuración por defecto es que en la comunicación entre el wallet y el nodo, la wallet pedirá al nodo que le dé un ID de nodo al que comprometer el mana. El nodo le dará a la cartera el ID al que quiere que se le entregue el mana. El monedero puede solicitar que se comprometa en otro lugar, y depende del nodo conceder esta solicitud o no.
Este comportamiento no está especificado por el protocolo principal. No es esencial para la seguridad, y no queremos inhibir futuros casos de uso estableciendo tal regla. Cualquiera puede construir el software de un nodo para que se comporte de forma diferente con respecto a cómo se promete el maná, de la manera que considere adecuada para su caso de uso.
¿Qué pasa cuando un nodo pierde su mana debido a un comportamiento malicioso?
¿Qué hay de malo en prometerlo en otro lugar y volver a intentar el ataque? ¿No es barato volver a prometer?
En IOTA 2.0, el mana no será revocado por el protocolo a un nodo que se comporte mal. Como sugiere la pregunta, hay algunas cuestiones obvias que tendrían que ser resueltas antes de añadir esto al protocolo. Sin embargo, los usuarios individuales pueden revocar su promesa de mana en caso de mal comportamiento. Sin embargo, es su responsabilidad prometer su mana de consenso a fuentes honestas.
Hemos concedido una subvención al grupo de Mauro Conti para que estudie un sistema de reputación más general que tenga en cuenta el comportamiento de los nodos. Se trata de una investigación en curso y mantendremos a todos informados de sus resultados.
Post original: Explaining Mana part 2
