IOTA Criptomoneda para el Internet of Things (IoT) (parte 2)

Los casos más habituales para comprar leche (maná) en vez de vacas (tokens) pueden ser dos:

  • Falta de tiempo para generar suficiente maná
  • Instituciones que por sus límites legales no pueden comprar tokens IOTA/SMR

Esos casos son los menos rentables, porque para adquirir el maná que necesitan tienen que comprarlo con tokens IOTA/SMR o con fiat, es decir, van a tener que disponer previamente de tokens IOTA/SMR e intercambiarlos por maná o pagarlo con fiat. Lo más rentable siempre va a ser tener en cuenta la combinación de los dos factores que generan el elemento principal:

maná generado = cantidad de tokens * tiempo retenido

Si de algo se ocupan bien las empresas es de planificar costes, así que es de esperar que esos dos casos los eviten lo máximo posible comprando o delegando la custodia de tokens con una planificación de tiempo correcta.

El maná se compromete a una ID de nodo, así que los operadores de nodos pueden adquirir maná de tres formas:

  • Retención de tokens: los operadores de nodos pueden comprar tokens IOTA/SMR y prometer a sus propios nodos el maná generado por estos tokens.
  • Alquilar maná de los poseedores de tokens IOTA/SMR. Los pagos de alquiler pueden ser en IOTA/SMR o en efectivo.
  • Tráfico de valor de procesamiento: un nodo puede procesar pagos a cambio del maná prometido en esos pagos.

*Solo transmito la información que se ha publicado por diferentes vías hasta hoy.

6 Me gusta

Generación de mana

El recurso que genera maná es el propio token de IOTA, y cada token genera 1 mana por unidad de tiempo.

Cada vez que un usuario mueve fondos, la transacción correspondiente genera una cantidad de maná que es igual a los fondos movidos multiplicados por el tiempo, los tokens permanecieron estáticos:

maná generado = cantidad de tokens * tiempo de permanencia

El gasto de los tokens actúa como prueba de propiedad y permite al emisor decidir qué identidad debe recibir las recompensas de maná generadas, lo que en consecuencia conduce a un aumento de su saldo de mana.

El mana como reputación

Dado que el mana es un token basado en la identidad, ya no se puede mover una vez que se ha comprometido a una identidad.

Esto lo convierte en un vector de reputación que mide directamente la cantidad de contribución de los actores individuales con respecto al acto de poseer tokens:

  • 10 tokens mantenidos durante 2 unidades de tiempo generan 20 de mana.
  • 4 tokens retenidos durante 5 unidades de tiempo generan 20 de mana.
  • 20 tokens mantenidos durante 1 unidad de tiempo generan 20 de mana.

Cuantos más tokens posea un actor y cuanto más tiempo las tenga, más mana recibirá.

Para convertir el mana en un verdadero sistema de reputación, donde la reputación es difícil de ganar (cuesta dinero y tiempo) pero fácil de perder, añadimos otro pequeño ajuste:

Permitimos que los usuarios definan condiciones en sus transacciones que, en caso de ser violadas, les harían perder toda su reputación.

Poder poner la reputación de uno como rescate permite algunos trucos interesantes de la teoría del juego para los protocolos fuera de la cadena en el contexto de los pagos fuera de línea y los canales de pago, pero este será un tema para un blog posterior.

Quema de mana

La aplicación del mana a nuestro control de la congestión es relativamente sencilla: En lugar de quemar un recurso real como la energía en PoW y favorecer a los actores que más han quemado, simplemente pasamos a quemar un recurso virtual (mana).

Nota: Si la red no está congestionada, es posible utilizarla sin maná, ya que en lugar de inflarla, la red se alimenta de utilidad (transacciones totalmente gratuitas).

El mana como sustituto del gas

Dado que el mana es ahora un recurso virtual con un balance concreto, podemos utilizarlo como sustituto del gas en los contratos inteligentes de la capa 1.

Mana para la gobernanza on-chain

Una diferencia importante entre el mana y el staking es que lo poseen directamente los usuarios del sistema y no se delega.

Esto significa que puede utilizarse para la gobernanza on-chain, donde los actores honestos que han contribuido más y durante más tiempo al ecosistema tienen mayores saldos.

La presencia de un factor temporal es especialmente interesante porque impide que los actores que controlan momentáneamente la mayoría de los tokens se hagan con el control de la red (por ejemplo, cuando Binance se hizo con el control de Steem porque más del 50% de los tokens residían temporalmente en su exchange): la red se fortalece con el tiempo.

Manadrops

En el ecosistema DeFi, es muy común el arranque de nuevos proyectos mediante el lanzamiento de tokens de gobernanza a los usuarios.

Uno de los mayores problemas a la hora de distribuir estos tokens es decidir quién debe recibirlos. El vector mana de IOTA, que mide directamente la cantidad de contribución de todos los usuarios a la capa1, permitiría esquemas de distribución completamente nuevos:

  • distribuir tokens a los n mayores poseedores
  • distribuir tokens de forma proporcional a las posesiones de mana
  • distribuir tokens en base a una lotería ponderada

Esto no sólo amplía el alcance de los proyectos en cuanto a su posible base de usuarios (sin abrirse a ejércitos de bots), sino que también crearía un enorme incentivo para que la gente compre IOTA ahora y participe directamente para poder establecer su DID y calificar para los airdrops que se pueden esperar dentro del ecosistema

8 Me gusta

Quiero decir, que para un usuario normal que no haga muchas transacciones, para las pocas que haga no creo que sea necesario mucho mana, segun entiendo de la formula, un iota esta generando maná cada segundo…

1 me gusta

Y esto es lo mas importante, claro

1 me gusta

Esa empresa, más teniendo sus propios nodos, no necesitaría mover los nft´s de forma pública hasta que los usuarios no quisieran sacar del sistema sus nft´s a sus propias wallets. Puedes crear perfectamente tu sistema cerrado hasta que se haga una transferencia pública.

4 Me gusta

La pregunta correcta sería ¿Cuánta cantidad de leche (maná) se necesita? la respuesta depende del número de transacciones, la cantidad de datos que se envíen en cada transacción, de la velocidad o de la congestión en ese momento de la red (si la hay).

No tiene que ver con la caducidad. La función de decaimiento exponencial sirve para evitar la percepción errónea sobre la cantidad de maná de algunos nodos cuando se realiza una transacción.

Supongamos que una transacción que mueve una gran cantidad de fondos elimina el maná del nodo A y lo compromete con el nodo B. Mientras la transacción se propaga a través de la red, algunos nodos que reciben la transacción primero verán temporalmente que el nodo B tiene mucho maná y otros verán que A tiene mucho maná. Además, un atacante con una cantidad significativa de maná puede enviar una secuencia de transacciones moviendo una gran cantidad de maná entre varias ID de nodo.

Para prevenir este ataque, el protocolo calculará el maná con un promedio móvil exponencial. Esto significa que el protocolo utilizará dos cantidades diferentes: maná base y maná efectivo. El maná base es una extensión del estado del libro mayor que se calculará directamente a partir de las transacciones agregadas al estado del libro mayor. Mientras tanto, el maná efectivo será el maná utilizado por cada módulo (control de congestión, OTV, etc) y se actualizará periódicamente con la siguiente fórmula:

Nuevo maná efectivo = α (maná base) + (1-α) (antiguo maná efectivo)

Donde α está entre 0 y 1. Con la media móvil exponencial, el maná efectivo frena el efecto de los cambios en el maná base. Por lo tanto, los grandes cambios en el maná base en el ataque anterior solo se registrarán lentamente, y no antes de que las transacciones tengan la oportunidad de propagarse por toda la red. El parámetro α controla la lentitud de estos cambios.

Con el método de cálculo de maná 2, el mana decae según esa función exponencial y, por tanto, debe ser refrescado con un nuevo pledge. La ponderación de los datos más antiguos disminuye exponencialmente en el tiempo, así que la vida media del decaimiento será cuestión de horas según la fase de investigación, pero no tengo ni idea de cuáles serán los parámetros finales.

*Estos cálculos formaron parte de la fase de investigación y seguramente se hayan modificado bastante. También hay que tener en cuenta que las métricas pueden variar mucho de su ejecución en los nodos GoShimmer de la red de prueba a los nodos Hornet de las redes principales. Las próximas semanas se realizarán las métricas para establecer los parámetros necesarios.

9 Me gusta

ok, era un ejemplo de uso intensivo de la red. Podemos poner otros, imagina la empresa que tiene un juego de póker donde las apuestas son con la moneda y la gente entra y sale constantemente por seguridad. Que no se queda en el ecosistema propio.

1 me gusta

Tal vez es porque me estoy dejando algo por el camino, pero en un modelo como este yo no veo limitación para la transferencia, debido a que todos los poseedores de tokens tienen X cantidad de maná en relación a los tokens disponibles, y se va repartiendo a su vez con cada transferencia. Otra cosa es que la red esté tan saturada que participantes con poca cantidad de tokens/maná no puedan efectuar una transacción en un determinado momento.

Pero entiendo que esto es como en cualquier red, si no tienes gas/maná suficiente para superar el mínimo de la red, no puedes mover tus fondos en ese determinado momento.

1 me gusta

Si por mercado te refieres a precio del maná, la pregunta es errónea, el concepto correcto es cantidad de maná, no precio. La cuestión es cuántos tokens IOTA/SMR va a necesitar la empresa a cambio de maná según los parámetros establecidos respecto al número de transacciones, cantidad de datos que se envíen en cada transacción o de la congestión en ese momento de la red (si la hay). Si reacciona el mercado será con el precio de IOTA/SMR porque son los tokens que se comprarán, maná es solo un recurso ajustado a unos parámetros.

Los nodos tendrán que disponer de una opción para gestionar el maná. El maná no se puede considerar un token que cotiza, es un recurso.

El usuario final no necesita maná porque ya tiene el acceso a la red y la velocidad de transacción delegada en los nodos de forma automática a través del algoritmo de control de congestión. Así que el NFT lo intercambian como una transacción normal.

Todo lo relacionado con los nodos y el acceso tiene que ser asunto de la empresa, otra cosa es que la empresa repercuta sus gastos de infraestructura en los usuarios de forma indirecta.

Si por mercado te refieres a precio del maná, la pregunta es errónea, el concepto correcto es cantidad de maná, no precio.

El concepto correcto es cantidad de maná, no precio.

Se adaptará dinámicamente el umbral mínimo de mana en función del porcentaje de mana activo y de las condiciones de tráfico. La IF también puede crear un “grifo de maná” donde los usuarios puedan solicitar una promesa de maná para su nodo. Si quieres más explicaciones sobre este detalle se lo tendrás que preguntar a los desarrolladores ya que aún no se han publicado los detalles.

Si yo fuese una empresa de la industria que va a usar IOTA como un posible protocolo estandarizado estaría montando nodos privados con potencia de hardware y comprando tokens para generar maná como si no hubiese un mañana para que no me pille el toro porque es la única forma de no perder nunca tokens (el factor tiempo).

El Mana de acceso (aMana) es un recurso que funciona como un sistema de reputación para priorizar el acceso en casos de congestión de la red. Y el Mana de consenso (cMana) es un recurso que funciona como un sistema de seguridad para evitar algunos vectores de ataque.

El peso del Mana de consenso y de acceso de un nodo determinado es relativo al “Mana activo” total, o el Mana que tienen los nodos activos en la red. Por ejemplo, si un nodo tiene el 5% del Mana de acceso total y solo el 50% del Mana de acceso está activo, entonces un nodo podrá agregar el 10% del total de datos permitidos por el protocolo al Tangle. Del mismo modo, el poder de voto es proporcional al Mana de consenso activo, cuanto más Mana de consenso tenga un nodo, más consultas recibirá, es decir, más poder de voto tendrá. Un atacante podría intentar comprar tokens con el objetivo de acumular Mana de consenso, que luego podría usarse para atacar la red. Sin embargo, tal ataque sería inmensamente costoso, ya que la compra eleva el precio y requeriría una gran cantidad de tokens para ejecutar un ataque, ya que necesitarían más tokens que los actores honestos.

*Maná no es el único elemento que evita los vectores de ataque, del resto (la gran mayoría) se ocupa el protocolo de IOTA 2.0.

*Solo transmito la información que se ha publicado por diferentes vías hasta hoy.

16 Me gusta

Brutal el conocimiento sobre el tema en las dos últimas respuestas @Whiterose. :clap: La verdad es que incluso leyéndolo me superan algunas cosas. A ver si hacemos algún proyectito… :wink:

8 Me gusta

Y en algún momento se “quema” maná?

De todas formas si el maná fuese tan problematico no podría una empresa trabajar sobre una capa 2 para minimizar las transacciones sobre la capa 1 de IOTA?

Algo así como se hace en Ethereum para no pagar tantas fees, sería una manera de reducir significativamente la.cantidad de mana que necesitarías al no tener que hacer todo en la L1.

1 me gusta

Cualquier capa, aplicación o cadena que esté anclada al Tangle necesitará realizar transacciones a través de los nodos, y para que el nodo envíe transacciones, ya sea con mensajes de datos o valor, necesitará maná.

Por ejemplo, el maná podría ser útil en una aplicación de capa 2 como los nombres de dominio, donde se requiera quemar una cierta cantidad de maná por dominio registrado y así evitar que se registren muchos dominos a la vez. También se puede usar como reemplazo a las tarifas de gas en los contratos inteligentes.

*La idea de Hans es que si no hay congestión en la red se puedan realizar transacciones sin la necesidad de maná, pero desconozco si van a implementar esa opción ahora o esperarán a la versión del protocolo para IOTA 3.0.

12 Me gusta

Cuando haya congestión en la red o para utilizar determinados servicios.

7 Me gusta

En realidad el mana es una de las soluciones al problema de la congestión.
La idea que propones es muy parecida a la fragmentación, pero en vez de capas se hará añadiendo redes y subredes ancladas a la rama principal para que los dispositivos de baja potencia puedan ejecutar fragmentos más pequeños de la red como un si fuese un nodo y no tengan que procesar todos los mensajes, permitiendo una red más diversa y ramificada.

Con la fragmentación se proporciona más acceso a la red y se reducen los requisitos de maná.

13 Me gusta

@Whiterose gracias por contestar a todo el mundo, estas a todas. Te tenemos aquí frito a consultas. :+1: :+1:

11 Me gusta

Ya es oficial, se desarrollarán smart contracts sin permiso en L1 con zkRollups incluidos.

13 Me gusta

Se que es feo ser mala vibra, pero a mi me suena de que están armando la excusa perfecta para comenzar a poner excusas de que los objetivos se van aplazar.

3 Me gusta

SOON ™️… As always

3 Me gusta

EVM en Shimmer debería haber salido esta semana
Hace dos semanas creo recordar dijeron que en dos semanas salía.
Y la verdad no se entiende que pongan una fecha tan exacta cuando el último año precisamente optaron por un Road Map sin fechas concretas …y la verdad es que esa hoja de ruta ha ido cumpliéndose…
No había necesidad de volver a marcar fechas…
Veremos si EVM llega antes de acabar el año…o tal y como dices todo se retrasa…

1 me gusta