IOTA ha sido criticado; solo por tomar decisiones de diseño que son fundamentalmente diferentes a otras en el campo del libro mayor distribuido.
Una de esas opciones fue usar un esquema de firmas resistente a los cuánticos; que (aunque está a salvo de las computadoras cuánticas) no permite gastar varias veces desde la misma dirección; sin poner en riesgo los fondos de esa dirección.
La mayoría de los críticos de esta característica argumentan que problemas como la computación cuántica no son una amenaza; y se pueden hacer ajustes cuando los algoritmos de firmas vulnerables se convierten en un problema real. Especialmente si la alternativa crea problemas de usabilidad para los usuarios actuales.
Para entender la elección de IOTA Latino; es importante entender lo que IOTA está tratando de lograr:
IOTA tiene como objetivo construir la columna vertebral para la próxima revolución industrial donde las máquinas de intercambio de información y el valor independientemente de los humanos (Internet of Things).
Los dispositivos IoT o Internet de las Cosas, usualmente utilizan tecnologías como los FPGA (arreglos de puertas programables en campo); y los ASIC (circuitos integrados específicos de la aplicación); que no son fáciles de parchear.
Su lógica normalmente está programada para que sean lo más eficientes posible en términos de energía. Pero una vez desplegados, tendrán que trabajar exactamente como se construyeron hasta el final de su vida.
En este contexto, sí tiene sentido pensar en las amenazas del mañana; para que los fabricantes de dispositivos puedan garantizar que sus dispositivos funcionarán de manera segura durante los próximos años.
Tomando en consideración los problemas de hoy
El futuro que imaginamos nos obliga a pensar con anticipación y, a menudo; tomar la “ruta difícil”. Pero, por supuesto, somos seres humanos que compartimos las mismas preocupaciones y necesidades que los demás. Sería bueno tener la opción de al menos una dirección reutilizable que pueda usarse de manera segura para cosas como:
Pagos regulares (donaciones, salarios o contratos con otras empresas)
“Libretas de direcciones” en carteras que nos permiten guardar un contacto; sin tener que pedirle a esa persona o máquina en particular una nueva dirección de recepción una y otra vez.
En el pasado hemos visto varias soluciones creativas; como esta propuesta de Eric Hop para introducir cheques para enviar y recibir donaciones. Otros han sugerido un enfoque de segunda capa para intercambiar direcciones actualizadas. Pero hasta ahora todas estas ideas tienen desventajas significativas en comparación con las direcciones reutilizables:
La negociación automática de nuevas direcciones de recepción requiere que el destinatario esté “en línea” en todo momento para responder a cualquier solicitud.
Alternativamente, deben entregar sus claves de inicio; privadas a una máquina, que luego puede administrar las direcciones en su nombre (inseguro).
El barrido de cheques se debe hacer manualmente o, si se automatiza, requeriría que el destinatario esté en línea en el momento del barrido. Como mínimo, ralentiza el tiempo hasta que los fondos llegan de manera segura a su billetera.
Además, las condiciones de carrera pueden ocurrir cuando la parte que envía no recibe la dirección de recepción actualizada. Luego, pueden enviar fondos accidentalmente a una dirección antigua (que se ha gastado mientras tanto) a pesar de tener buenas intenciones.
Actualmente estamos investigando una posible solución a estos problemas en el nivel de protocolo, que solo requiere ajustes menores al protocolo IOTA. Esto puede permitirnos reutilizar direcciones especiales una cantidad ilimitada de veces sin reducir la seguridad, o incluso romper la resistencia cuántica.
Parte 2
Enfoque actual (un resumen)
Cada vez que emitimos un pago desde una de nuestras direcciones, firmamos el mensaje utilizando la clave privada que pertenece a esa dirección. Los nodos pueden verificar que el gasto fue emitido por el propietario de la dirección; al verificar la firma de la transacción con la dirección en sí. Dado que IOTA utiliza un esquema de firmas resistente a los elementos , revelamos una cierta parte de la clave privada cada vez que firmamos una transacción. Esto significa que no podemos usar la misma clave privada más de una vez sin comprometer la seguridad de los fondos en esa dirección.
Para superar este problema, se aconseja a los usuarios:
- Nunca gastar de una dirección más de una vez.
- Al gastar un subtotal de fondos en una dirección, todos los fondos restantes no gastados deben enviarse a una nueva dirección (llamada dirección de resto) al mismo tiempo. De este modo, los fondos restantes se pueden gastar de manera segura en el futuro a partir de la nueva dirección (resto).
El software de cartera IOTA se encarga de esto automáticamente en segundo plano, para que los fondos de los usuarios permanezcan seguros.
“Cuando Alice envía fondos desde una dirección, su billetera IOTA mueve automáticamente los fondos restantes en esa dirección a una nueva dirección de “resto” segura en su billetera, de la cual puede gastar de manera segura en el futuro.”
Una vez que se confirma el gasto, los fondos restantes residen en una nueva dirección no utilizada.
Este mecanismo asegura los fondos de la parte que gasta de una manera muy eficiente. Sin embargo, la parte receptora aún puede tener problemas, si alguien envía fondos a una dirección que ya se ha gastado (ya sea por un error del remitente o debido a las condiciones de la carrera, como se comentó en la publicación anterior).
Nuevo enfoque (nuestra propuesta)
Dado que el esquema de firmas no se puede cambiar sin romper una característica fundamental de IOTA (es decir, resistencia cuántica), debemos diseñar otro método para usar una nueva clave privada para gastos consecutivos de la misma dirección.
Teniendo en cuenta que una nueva clave privada siempre está asociada con una nueva clave pública, esto significa que debemos:
- Lógicamente, separe la dirección de la clave pública que se usa para verificar la firma de las transacciones.
- Introduzca una forma de cambiar la clave pública asociada con una dirección, para cada gasto.
Para lograr esto, proponemos:
- La introducción de un nuevo campo en los metadatos de la transacción, que nos permite actualizar la clave pública de una dirección e informar a la red sobre este cambio.
- El próximo gasto de esta dirección tendrá que verificarse con esta clave pública diferente en lugar de la propia dirección.
Para cada gasto, generaremos un nuevo par de claves pública / privada que se usará para autorizar el próximo gasto desde esa dirección, con la clave pública para la próxima transacción establecida por los metadatos de la transacción actual. El algoritmo para enviar una transacción se puede resumir de la siguiente manera:
Gastar fondos (noveno tiempo de una dirección)
- Construye la transacción.
- Genere un nuevo par de claves públicas / privadas para el próximo gasto ( pubkey_n , privkey_n ).
- Incluya la clave pública del par de claves recién generado en los metadatos de la transacción configurando el campo correspondiente: nextpubkey = pubkey_n.
- Firme la transacción con la clave privada que pertenece a la clave pública que fue establecida por la transacción anterior: privkey_n-1 (Nota: la primera inversión usará la clave privada que pertenece a la propia dirección)
- Transmitir la transacción.
Todos los fondos residuales permanecen en la misma dirección, en lugar de ser trasladados a una dirección restante. Todavía es seguro enviar fondos a esta dirección en el futuro.
Para poder procesar transacciones de esta manera, los nodos simplemente tendrán que almacenar un campo adicional por dirección en su estado de libro mayor y cambiar la clave pública actualizada cada vez que se confirme un nuevo gasto.
El estado del libro mayor cambiará de:
Una comparación (hecha) del “mundo real”
El enfoque actual de IOTA para la firma de pagos puede compararse con tener puertas de diamante en su casa. Son extremadamente seguros, pero lamentablemente también son transparentes. Entonces, cuando usa la llave para salir de la casa para caminar hacia el banco, alguien que espera afuera puede “ver” una pequeña parte de la llave que usó para abrir la puerta. Y en algún momento, es posible que vean lo suficiente como para poder falsificar una clave y acceder al contenido de su dirección.
Para evitar que esto suceda, actualmente llevamos todas nuestras pertenencias con nosotros a una nueva dirección (resto) (con un nuevo bloqueo y una nueva clave) y nunca regresamos a nuestra dirección anterior.
En comparación, este nuevo enfoque puede compararse con “cambiar la cerradura” después de salir de la casa pero permanecer en la misma dirección. Entonces, incluso si alguien ve su vieja llave, no podrán acceder a su casa / fondos. Además, tiene el bono adicional de una dirección estable donde las personas pueden enviarle correo (o dinero).
Parte 3
Pero no todo es bueno… Comenzamos analizando las ventajas y desventajas de este nuevo enfoque.
Argumentos a favor del planteamiento propuesto
- Recibir fondos ahora requiere menos recursos en el lado receptor, ya que los destinatarios no necesitan generar nuevas direcciones para cada pago entrante, y el destinatario debe monitorear menos direcciones para determinar si se recibieron los fondos.
- Esto, a su vez, mitiga un posible ataque de tipo DOS, por lo que el destinatario es bombardeado con solicitudes de pago, lo que obliga a generar y monitorear un número casi ilimitado de direcciones (asumiendo un enfoque de segundo nivel que funcione para tratar estas solicitudes).
- También pueden necesitarse menos recursos en el lado de envío, ya que el remitente ya no tendría que consultar constantemente nuevas direcciones de recepción.
- Las carteras pueden implementar libretas de direcciones para guardar contactos con direcciones persistentes predecibles.
- En consecuencia, las empresas y los individuos podrían comunicar sus detalles de pago en papelería. Los pagos recurrentes, como los débitos directos y los pedidos permanentes a direcciones estáticas, también son posibles, lo que convierte a IOTA en una solución viable para los modelos de negocios tradicionales.
- El enfoque facilitaría un sistema descentralizado similar a DNS, donde las direcciones IOTA complejas se asignan a direcciones memorables para el ser humano.
Sería posible referirse a los contactos utilizando alias (por ejemplo, direcciones de correo electrónico); de forma inmediata, haciendo que IOTA sea utilizable como sistemas de pago existentes (por ejemplo, PayPal o banca tradicional).
- La validación inicial de estos alias de direcciones podría evitar la pérdida de fondos, si se advierte al usuario que su alias mal escrito no se asigna a una dirección IOTA válida.
- Los fondos recibidos siempre son 100% seguros, ya que los fondos no pueden terminar en una dirección usada.
- Los ataques de repetición no serían efectivos debido a la clave pública modificada.
- La llamada a la API wereAddressesSpentFrom puede ser desaprobada: esta solución temporal actualmente; crea una lista cada vez mayor de direcciones que limita la escalabilidad.
- Los paquetes se harán más pequeños debido a que se puede omitir una transacción completa (transacción restante), lo que reduce el tráfico de red requerido para gastos.
El tema común de estas ventajas es que la propuesta hace que IOTA sea más fácil de usar para los seres humanos y, en última instancia, impulsará una adopción más amplia. Por lo tanto, son muy valiosos, y no deben ser descartados fácilmente.
Las direcciones predecibles facilitarían la administración de contactos y las transacciones fáciles dentro de las cadenas de mensajes. ¿Podría ser esta una futura versión de Trinity?
Argumentos en contra del enfoque propuesto
Como se mencionó al inicio de esta publicación, nuestra solución propuesta presenta algunos problemas que evitarían que se reemplace completamente la forma actual en que se manejan las transacciones. Discutiremos estos temas uno por uno, junto con las posibles mitigaciones.
1- El orden de las transacciones importa
Un problema con este nuevo enfoque es que el orden de las transacciones ahora importa. Una transacción exitosa solo se puede confirmar si la red ha visto (y finalmente confirmó) la transacción anterior en la cadena.
Por ejemplo, si envía rápidamente 10 pagos consecutivos desde una dirección reutilizable, entonces la primera transacción cambia la clave pública de la dirección, y se requiere la nueva clave pública para la próxima transacción (y así sucesivamente). Si la primera transacción no se confirma y se debe volver a adjuntar, esto significaría que las siguientes transacciones se retrasarían hasta que se confirme la reincorporación.
Es posible que también deban volver a unirse (posiblemente varias veces) hasta que la red los acepte en el orden deseado.
Cabe señalar que este problema también existe con el enfoque actual de IOTA. Un gasto consecutivo solo puede verificarse una vez que la red ha visto la transacción; cubre la dirección restante (de lo contrario, esta dirección aparecería vacía). Sin embargo, con nuestro nuevo enfoque, es más difícil implementar un mecanismo que permita características tales como sobregiros temporales (donde una transacción siguiente financia el gasto de uno anterior): el cambio de claves significa que no podemos verificar fácilmente la firma de Estas transacciones, cuando se procesan en el orden incorrecto.
Incluso si asumimos que los nodos prestarán atención al pedido y “clasificarán” las transacciones internamente mientras determinan su validez, al menos hará que la tarea de verificar las transacciones sea un poco más compleja y requiera más capacidad de procesamiento. Estos ciclos de CPU se podrían gastar procesando otras transacciones, lo que podría disminuir la capacidad de procesar un alto número de transacciones por segundo.
Solución posible:
Se pueden resolver partes de este problema haciendo referencia directa o indirectamente a un gasto anterior en un gasto consecutivo si el anterior aún está pendiente. De esta manera, podemos garantizar; la validez de un subtangle sin tener que tener en cuenta los subtangles paralelos, al determinar la validez de estas transacciones pendientes. Dado que el recorrido aleatorio pasa de “pasado” a “presente”, vemos automáticamente; las transacciones en su orden correcto y podemos omitir su clasificación interna, lo que facilita estos problemas. Este comportamiento; también aumenta el peso del gasto anterior y, por lo tanto, aumenta la posibilidad de ser aceptado por la red. Un gasto consecutivo por lo tanto actuaría como una promoción de la transacción anterior.
Debemos tener en cuenta que este problema solo se manifiesta; si intentamos enviar muchos gastos desde una dirección reutilizable al mismo tiempo, sin esperar a que se confirme la anterior (que se abordará en la propuesta final al final de este post).
2- Privacidad reducida
Si todos los fondos que pertenecen a un usuario residen en una sola dirección reutilizable, el saldo exacto de esa dirección será de conocimiento público. Esto se vería agravado aún más por los servicios de mapeo; que podrían identificar a los usuarios a través de su alias. Esta reducción de la privacidad podría alentar a los piratas informáticos y otros delincuentes a acceder a los fondos a través de ataques tradicionales fuera de la red IOTA.
Solución posible:
El método actual de usar direcciones solo una vez, y enviar los fondos restantes a una nueva dirección seguirá funcionando. Regularmente podemos “barrer” fondos de nuestra dirección pública reutilizable a una dirección “no reutilizable”, que luego funciona de la misma manera que lo hace actualmente.
La privacidad de estos fondos barridos se puede aumentar aún más mediante la aplicación de servicios como ” mezcladores “. Estos son temas de investigación abiertos y veremos esfuerzos adicionales para aumentar la privacidad en la maraña. Por ahora, es suficiente asumir que podemos mover los fondos de la dirección reutilizable a una tradicional.
3- Mayores requisitos de almacenamiento para los nodos
Dado que los nodos necesitan almacenar un campo adicional; en su tabla de contabilidad, los requisitos de almacenamiento aumentan en 243 trits por dirección, lo que llevaría a un tamaño de base de datos más grande. Además, las direcciones vacías ya no se pueden eliminar de la base de datos, ya que; debemos realizar un seguimiento de la clave pública actualizada, en caso de que la dirección reciba fondos adicionales en el futuro. Un atacante podría fácilmente enviar correo basura a esta tabla de contabilidad y hacer que los nodos se queden sin almacenamiento muy rápidamente.
Solución posible:
Proponemos que solo se mantenga viva una dirección reutilizable en la tabla de contabilidad si no está vacía. Esto significa que un usuario debe apostar una cierta cantidad de IOTA (por ejemplo, 1 IOTA) que siempre tendrá que residir en esa dirección; si quiere poder usarla varias veces. Una vez que el saldo de la dirección cae por debajo de esta cantidad, efectivamente declaran que esta dirección ya no se usa, y los nodos la limpiarán. En esencia, esto significa que la dirección se restablece a su primera clave pública, y todos los fondos entrantes ahora estarán en una dirección “usada”. Lo ideal sería que las billeteras se encargaran de administrar los fondos apostados de modo; que no podamos gastarlos accidentalmente, y caer por debajo del umbral, al enviar un pago.
Si se implementa de esta manera, lo más probable es que incluso veamos; un requisito de almacenamiento reducido porque los fondos entrantes ya no tendrían que distribuirse en innumerables direcciones, sino que se acumularían en menos direcciones.
4- Problemas en relación con los clusters económicos
A pesar de que el concepto de agrupaciones económicas; sigue siendo un tema de investigación en lugar de una preocupación de implementación, la idea básica es clara. Este concepto se basa en la idea de que cierta actividad en una red de alto rendimiento, solo puede ser vista por una parte determinada de la red en lugar de todos los nodos existentes.
Para las direcciones reutilizables, los nodos deben ver la transacción original que actualiza la clave pública, antes de poder validar cualquier gasto posterior de esa dirección. Esta transacción original solo puede ser visible en algunos grupos pero no en otros.
Solución posible:
Para poder enviar pagos entre clústeres, debemos usar direcciones no reutilizables para los pagos. Esto permitiría que los nodos lejanos verifiquen la firma incluso sin conocer la clave pública actualizada. Dado que es posible mover los fondos de una dirección reutilizable; a una dirección tradicional antes de enviar las transacciones, esto no es un problema.
De hecho, sugerimos el uso de direcciones; no reutilizables (siempre que sea posible) para enviar fondos, mientras que preferimos direcciones reutilizables cuando se reciben fondos.
Conclusión
Hemos demostrado que la solución propuesta no puede reemplazar completamente la forma existente de procesar transacciones, y que las decisiones de diseño tomadas en el pasado fueron fundadas.
Sin embargo, puede actuar como una opción adicional; para recibir fondos de forma segura, sin tener que preocuparse; por la reutilización de la dirección y las condiciones de la carrera. También tiene varias mejoras de usabilidad que promoverían la actual adopción del protocolo en el mundo real.
Implementación sugerida:
Para equilibrar los pros y los contras, proponemos la introducción de una dirección; reutilizable por billetera, que puede actuar como un único punto de contacto para los pagos recibidos. Esta dirección puede ser barrida periódicamente; por una no regular reutilizable, lo que hace que los fondos estén disponibles para un gasto fácil. El gasto de las direcciones regulares (no reutilizables) no depende de mantener el orden de las transacciones, lo que permite; que se procesen de manera eficiente en paralelo, de la misma manera que se procesan ahora.
Al mismo tiempo, esta nueva dirección “pública” no expondrá demasiada información; sobre nuestros fondos porque se vacía regularmente, distribuyendo los fondos; a nuevas direcciones que ya no pueden asociarse fácilmente a nuestra dirección reutilizable.
