Ultimas Noticias de Criptomonedas Bitcoin, Ethereum, XRP

Preguntas y respuestas

El lunes 6 de noviembre, realizamos un Discord AMA sobre la serie reciente de videos, publicaciones de blog y páginas wiki que presentan la próxima actualización del protocolo IOTA 2.0. Los miembros de la comunidad hicieron varias preguntas a Andrew Cullen, Andrea Villa, Billy Sanders, Darcy Camargo, Nikita Polianskii y Piotr Macek de nuestro equipo de investigadores e ingenieros; También agregaron sus propias ideas.

Hemos reproducido las preguntas y respuestas (ligeramente editadas para mayor claridad) aquí para aquellos de ustedes que se las perdieron. Para explorar más a fondo los problemas planteados aquí, consulte nuestra serie de publicaciones de blog que presentan IOTA 2.0, que se enumeran al final de esta página. Y para aquellos de ustedes que prefieren mirar en lugar de leer, también compartimos algunas de las mejores preguntas con Linus Naumann, miembro de la comunidad desde hace mucho tiempo, en el video a continuación.

Tres preguntas sobre IOTA 2.0

1) ¿Cuál es su expectativa sobre cómo se desarrollará el mercado de Mana? ¿Cuánto valor monetario en comparación con lo que usted apuesta espera recibir a cambio de apostar (APY)? ¿1-5%?

Andrés: En primer lugar, el mercado de Mana no es algo en lo que la Fundación IOTA pretende invertir recursos en su desarrollo, sino algo que pretende dejar a la comunidad. Hemos pensado mucho en cómo implementamos Mana en sí, para garantizar que sea lo suficientemente flexible como para usar de muchas maneras, desde su uso principal para la emisión de bloques hasta contratos inteligentes de Capa 1 y Capa 2, hasta una medida de diferente reputación. , hasta comprar y vender en un «mercado de Mana». Podría prever las primeras encarnaciones de los mercados de Mana tomando la forma de proveedores externos desarrollados por la comunidad que venden Mana por moneda fiduciaria o tokens IOTA. Esta versión de un mercado de Mana existiría junto con proveedores de servicios de emisión de bloques que simplemente emiten bloques en nombre de los usuarios y ni siquiera requieren Mana del usuario. Ofrecer emisión de bloques como servicio también es una forma de mercado de Mana porque estás pagando por un servicio que requiere Mana. Los mercados de Mana basados en DEX más favorables evolucionarían después de la llegada de los contratos inteligentes L1.

Desafortunadamente, no puedo especular sobre el APY esperado por apostar, pero puedo decirles que existe una regla simple 1:2:3 para delegar/apostar para calcular cuánto maná adicional puede ganar por delegar o apostar simplemente por tener tokens. . Tener tokens Y te otorga X Mana, delegar esos tokens te otorga al menos 2X Mana y apostar esos tokens te otorga al menos 3X Mana (siempre que hagas tu trabajo correctamente como validador).

2) ¿Cuáles son los requisitos de hardware para ejecutar un nodo como validador?

Piotr: Ejecutar un nodo validador no requerirá muchos más recursos que ejecutar un nodo normal. La única diferencia es que un validador necesitará ejecutar una extensión INX inx-validator, que no utiliza muchos recursos. Acabamos de implementar el complemento de validación, por lo que aún no conocemos los requisitos exactos, pero el complemento básicamente construye y emite un bloque en ciertos intervalos, lo que no consume muchos recursos.

3) ¿Se tiene en cuenta el valor monetario de Mana para los parámetros de desarrollo? por ejemplo, ¿reducir artificialmente la capacidad para aumentar el valor de Mana?

Andrés: La oferta y la demanda de Mana ciertamente se tienen en cuenta al elegir los parámetros de la red. Una forma de tener esto en cuenta es que en las primeras etapas de la red, la decadencia de Mana será muy lenta, lo que permite a los participantes acumular Mana porque el Mana será de bajo valor en esta etapa. Sin embargo, cuando la red esté más madura y el maná se vuelva más valioso, la tasa de decadencia aumentará para que ya no se pueda acumular maná. Así que no limitaremos artificialmente la oferta sólo para hacerla valiosa, sino más bien todo lo contrario. El maná se volverá valioso cuando la red sea útil, pero no habrá ningún truco para hacerlo valioso antes de eso.

4) ¿Cómo aborda IOTA 2.0 los desafíos de escalabilidad que enfrentó la versión anterior y qué características innovadoras se han implementado para garantizar transacciones más rápidas y eficientes?

andrea: El protocolo IOTA 2.0 ha sido rediseñado desde cero para tener un mecanismo de votación paralelo y sin líder. Todos los validadores, independientemente del mecanismo involucrado en su selección, pueden votar simultáneamente sobre bloques y transacciones que aparecen en Tangle. Esto se opone al enfoque de hitos actuales, en el que una sección de Tangle solo se puede evaluar en el momento de recibir un hito. De hecho, en IOTA 2.0, los nodos mantienen un seguimiento en vivo del peso de cualquier objeto hasta alcanzar el umbral de aceptación.

5) ¿Puede proporcionar información sobre las mejoras de seguridad de IOTA 2.0, particularmente en relación con la prevención de posibles ataques y la seguridad de la red para su viabilidad a largo plazo?

andrea: A diferencia del proceso de confirmación lineal de la versión anterior, IOTA 2.0 permite validar varias partes de Tangle simultáneamente, lo que aumenta significativamente el rendimiento de las transacciones. Lo mismo ocurre con su proceso de validación y votación: es paralelo y descentralizado, ya que no existe un único Coordinador en quien confiar. En IOTA 2.0, se selecciona un conjunto de validadores siguiendo el resultado de un proceso de selección de comité, respaldado por una Prueba de Participación delegada. Se selecciona un comité de validadores en cada época: un múltiplo de espacios de aproximadamente un día de duración. En este esquema, un validador candidato puede convertirse en un validador real proporcionando suficiente participación, recibiendo delegaciones de participación por parte de los usuarios en la red y demostrando su capacidad para seguir el protocolo antes del proceso de selección de la siguiente época. De esta manera, la red no solo está asegurada con suficiente participación, sino que también es resistente contra validadores que se vuelven maliciosos o se desconectan.

6) ¿Qué estrategias ha adoptado IOTA 2.0 para reducir su huella de carbono y contribuir a una tecnología blockchain más respetuosa con el medio ambiente?

Piotr: En comparación con la versión anterior, la mejora es que no dependemos de la Prueba de trabajo para el control de la congestión, lo que reduce la cantidad de cálculo. Aquí hay un análisis detallado que se realizó en el prototipo de GoShimmer hace algún tiempo. El uso de energía y el enfoque general no cambiaron, por lo que todavía está más o menos actualizado: https://blog.iota.org/consumo-energético-de-iota-2-0/.

7) ¿Cómo aborda IOTA 2.0 la amenaza potencial de validadores adversarios que intentan manipular el proceso de confirmación en Tangle? ¿Podría proporcionar más detalles sobre las medidas preventivas que se han implementado para salvar la red?

nikita: El protocolo en sí sirve como nuestra salvaguardia, permitiéndonos tolerar hasta un tercio de validadores adversarios en el comité. Este protocolo se puede segmentar en varios componentes, incluido el mecanismo de control de congestión, el módulo de peso de aprobación, el algoritmo de selección de propinas, la regla de cambio de cadena, etc.

Cada uno de estos componentes contribuye a brindar protección de distintas maneras. Nuestro algoritmo de selección de sugerencias permite la selección de todos los bloques emitidos por nodos honestos, lo que garantiza que ningún bloque honesto pueda ser censurado o ignorado por validadores adversarios. De lo contrario, los nodos honestos acabarán ignorando cualquier bloque adversario. Nuestra selección de propinas también permite la generación consistente de compromisos de tragamonedas por parte de todos los nodos honestos. Se espera que un bloque emitido hace X segundos reciba un peso de aprobación de valor F(X) por parte del comité, evitando que bloques con una marca de tiempo antigua se infiltren en Tangle.

El mecanismo de control de congestión está diseñado para evitar el spam por parte de validadores y nodos adversarios. Utilizando el módulo de peso de aprobación, cada nodo interpreta lógicamente el DAG local, Tangle, y llega a las mismas conclusiones con respecto a la confirmación y finalización de bloques y transacciones.

Para obtener información más detallada, recomendamos consultar los artículos de Wiki. Capa de comunicación: control de congestión, creación y procesamiento de bloquesy Consenso sobre un DAG.

8) Con respecto a la alineación de objetivos e incentivos entre usuarios y validadores en IOTA 2.0, ¿puede explicarnos los mecanismos específicos que permiten a los usuarios producir sus propios bloques y cómo esto elimina la extracción de valor de los usuarios a través de la inflación, beneficiando en última instancia a toda la red?

Andrés: Los «mecanismos específicos» en cuestión abarcan prácticamente todo el protocolo, por lo que no es fácil indicarle una característica del protocolo que lo permita. En primer lugar, es el control de congestión basado en Mana el que permite a los usuarios crear sus propias cuentas y emitir y pagar sus propios bloques. También genera su propio Maná simplemente manteniendo tokens (consideramos que tener tokens es valioso para el protocolo ya que hace que los tokens sean escasos y la red sea más segura), y pueden aumentar su tasa de generación delegando (considerado un uso más valioso de tokens y así gana más recompensas). Los validadores son cuentas de usuario que han bloqueado sus tokens y emiten bloques de validación periódicamente para votar esencialmente por las partes del Tangle que consideran correctas, lo cual es un servicio extra valioso y genera aún más maná. Estas diferentes clases de usuarios que ganan diferentes cantidades de Mana tienen una implicación similar para la inflación porque Mana (acceso a bloques de emisión) se distribuye desde aquellos que menos contribuyen al protocolo hasta aquellos que más contribuyen al protocolo. Sin embargo, este fenómeno ocurre sólo en Mana y no en la ficha base. Además, los usuarios nunca pagan a un validador para que apruebe sus transacciones, como se puede ver en muchos protocolos con tarifas por priorización, y esto elimina otras formas de extracción de valor además de las inflacionarias.

9) ¿Podría explicar el papel de Mana Burn en la prevención del spam y la regulación de la cantidad de bloques que los usuarios pueden emitir dentro de un intervalo de tiempo específico, y en qué se diferencia este mecanismo de otros enfoques similares, como el EIP- 1559 de Ethereum?

Andrés: Nuestro mecanismo de quema de maná tiene algunas similitudes con EIP-1559. Nuestra idea para este mecanismo de quema de maná surgió de nuestra propuesta anterior de PoW adaptativo en lugar de inspirarse en EIP-1559. Definimos un costo de maná de referencia (RMC) como equivalente a la tarifa base en EIP-1559, pero la principal diferencia con nuestro enfoque es que no incluye un consejo adicional para la priorización. El RMC se adapta lentamente a la creciente demanda de acceso; puede aumentar cada intervalo de 10 segundos para aumentar el costo de una transacción en respuesta a aumentos persistentes de la demanda. Sin embargo, en picos de congestión, este mecanismo es de poca ayuda, y aquí es donde entra en juego el consejo de EIP-1559, para priorizar el tráfico durante estos picos. En nuestro caso, esta priorización se realiza sin un programador de Déficit Round-Robin (DRR), que permite transacciones para cada titular de cuenta a una tasa proporcional a sus tenencias de Mana. No pueden pagar por la prioridad, porque esto genera tarifas impredecibles y retrasos que vemos en otras redes. En cambio, los usuarios toman lo que pueden en función de sus tenencias de Mana durante estos picos, y la recompensa son retrasos y tarifas predecibles para obtener basadas completamente en el RMC definido por el protocolo. Echa un vistazoEl artículo de Wiki sobre control de congestión. para obtener una explicación detallada si aún no lo ha hecho.

10) ¿Cómo garantiza el mecanismo de control de congestión de IOTA 2.0, que asigna el rendimiento en función de las tenencias de Mana de los usuarios, tarifas consistentes y predecibles al tiempo que evita retrasos impredecibles en el procesamiento de transacciones, como se ve específicamente en las redes blockchain congestionadas?

Andrés: En primer lugar, nuestro control de congestión no utiliza una cola prioritaria. Las colas de prioridad son la causa principal de tarifas y retrasos impredecibles en la mayoría de las redes blockchain, es decir, los validadores eligen las transacciones de mayor valor para incluir. En IOTA 2.0, establecemos la tarifa a nivel de protocolo utilizando un mecanismo muy similar a la tarifa base de Ethereum (EIP-1559), pero no permitimos ninguna propina de prioridad adicional además de esa tarifa. En tiempos de alta congestión, las transacciones se priorizan en función de las tenencias totales de Mana utilizando un programador de DRR. El programador de RRD ofrece retrasos mucho más consistentes y predecibles que una cola de prioridad en momentos de alta congestión, pero tiene la contrapartida de que no se puede «comprar prioridad» en momentos de alta congestión, hay que trabajar con la ra te tienes disponible en función de tus tenencias totales de maná.

11) La sección sobre el planificador. menciona que itera a través de emisores de bloques en función de su déficit, que es proporcional a su Mana. ¿Cómo eliminar este enfoque la necesidad de que los usuarios pujen por la prioridad de las transacciones, garantizando un procesamiento de bloques eficiente sin tarifas ni demoras excesivas?

Andrés: Simplemente no hay forma de aumentar la prioridad en el programador para su transacción en momentos de alta congestión. El programador de DRR funciona como un cubo con agujeros para cada titular de cuenta, y el tamaño del agujero es proporcional a sus tenencias de Mana, por lo que sus transacciones se realizan a una tasa proporcional a sus tenencias de Mana. No hay forma de evitar esto pagando más, está incluido en el protocolo. Hemos investigado mucho sobre las políticas de programación y ésta proporciona, con diferencia, las mejores propiedades de coherencia, equidad y seguridad para que la experiencia del usuario no se vea afectada como ocurre en otros proyectos con tarifas de prioridad impredecibles en tiempos de congestión.

12) ¿Existe un límite en el número de puestos para los validadores de nodos IOTA 2.0 y cuál es el número máximo de puestos en el comité de validación?

Andrés: Cualquiera puede registrarse como validador y no hay límite en la cantidad de validadores registrados. Sin embargo, existe un límite en el tamaño del comité de validación (los validadores activos) en cualquier época (que es aproximadamente un día), y ese es un parámetro del protocolo. Actualmente contamos con un grupo de trabajo de parámetros que determina la combinación óptima de parámetros como estos para el lanzamiento, pero probablemente habrá alrededor de 50 validadores por época en el comité. La selección de los validadores para el comité inicialmente se basará completamente en los tokens apostados, es decir, solo los mejores apostadores de la época se incluirán en el comité en cada época.

13) ¿Qué nivel de MPS/TPS se alcanzó durante las pruebas de estrés internas y qué nivel esperaría para la testnet? ¿Hay algún límite (duro/blando)? ¿Podría proporcionarnos una descripción general de los tiempos de finalidades esperadas? ¿Son fijos o podrían evolucionar con el tiempo (si depende de parámetros)?

Piotr: No hemos realizado ninguna prueba de estrés real todavía, ya que el software aún no ha alcanzado un estado para probar ese tipo de cosas. Internamente, en nuestras máquinas locales, hemos estado ejecutando hasta 500 BPS; Sin embargo, este número no dice mucho por sí solo porque eran bloques de datos simples que no ejecutaron la VM y no mutaron el libro mayor. Todavía tenemos que diseñar una prueba de estrés adecuada, teniendo en cuenta los diferentes tipos de bloques y transacciones, y el hardware en el que ejecutamos esas pruebas. El único límite es la tarifa del programador, que aún no ha sido elegida. La finalidad (lo que significa que algo nunca, bajo ninguna circunstancia, será revertido) será en cuestión de minutos, ya que esto sucede en el nivel de compromiso, y la generación de un compromiso se retrasa un minuto. Sin embargo, también tendremos una bandera de confirmación a nivel de bloque, lo que también significará que una gran mayoría de validadores han visto el bloque y, en condiciones normales, será casi definitivo. Sin embargo, no llamamos a esta finalidad, porque existen algunas condiciones límite bajo las cuales dichos bloques podrían, en teoría, revertirse. Sin embargo, esto es extremadamente improbable. este papel analiza el tiempo de confirmación. No utilice la última versión del dispositivo de aceptación, pero las dependencias aún se mantienen.

Miembro de la comunidad: Además de esto, el hardware juega un papel importante en el rendimiento que alcanzará un nodo. Cuando probamos Chrysalis con spam, los servidores más pequeños pudieron mantener un valor constante de 1200, y los servidores más grandes no tenían problemas para superar los 3000. Los números puros de MPS no significan nada. Será un esfuerzo de prueba para descubrir qué obstáculos tendrá el CR y cómo mitigarlos. En aquel entonces, a partir de entre tres y cuatro vCPU, la discoteca sería el factor limitante.

Piotr: En este momento esperamos que el IO no sea un problema importante ya que operamos principalmente en la memoria, pero de todos modos tendremos que descubrir cuál es el cuello de botella real.

14) Después del lanzamiento de IOTA 2.0, ¿qué ventajas tendremos en comparación con otras criptomonedas (por ejemplo, ADA, SOL)? ¿Cuales son las desventajas? Mientras tanto, tras el lanzamiento de IOTA 2.0, ¿cuál es nuestra hoja de ruta para los próximos pasos? ¿Qué direcciones deben tomarse después de IOTA 2.0 para fortalecerlo?

andrea: IOTA 2.0 se destaca en el panorama DLT principalmente por su estructura de datos única donde Mempool está inherentemente integrado en la estructura de datos misma, a diferencia de las cadenas de bloques tradicionales. Esta integración facilita la votación continua y paralela de las transacciones en toda la red, lo que permite un mecanismo de consenso más dinámico y fluido en comparación con el enfoque bloque por bloque de las cadenas de bloques convencionales.

La perfecta inclusión de Mempool dentro de Tangle también significa que la resolución de conflictos se convierte en un proceso más ágil. No hay que esperar al siguiente bloque para abordar los conflictos; se resuelven en tiempo real a medida que surgen, lo que permite un sistema más receptivo y ágil.

Mirando hacia el futuro con la llegada de la programabilidad extendida de la Capa 1, IOTA 2.0 está preparado para mitigar problemas críticos como el Valor Extraíble Minero (MEV). Las cadenas de bloques tradicionales son susceptibles al MEV porque los mineros pueden manipular el orden de las transacciones dentro de un bloque para su beneficio, lo que potencialmente desestabiliza la red e introduce injusticia. La arquitectura de IOTA naturalmente evita tales errores, ya que no depende de pedidos de transacciones basadas en bloques o mineros, lo que conduciría podría a un entorno de red más estable y equitativo. En pocas palabras: la separación entre el proponente y el constructor del bloque surge de la propia estructura de datos en lugar de ser un complemento a un mecanismo existente.

15) ¿Qué tan descentralizado será realmente el comité de validación si el comité está formado por, por ejemplo, 10 de las billeteras más ricas o si todas las personas delegan en unos pocos validadores? Lo que esperaba ver con IOTA 2.0 es un sistema en el que, en teoría, varios validadores pequeños puedan superar en votos al validador más grande. Por ejemplo, 1000 nodos con 100.000 IOTA cada uno tienen el mismo peso de votación que un nodo con 100.000.000 IOTA. Cuantos más validadores, más segura será la red. Esperaba ejecutar mi propio nodo IOTA y ayudar a proteger la red. Pero si no soy uno de los principales poseedores de IOTA o un miembro famoso de la comunidad que recibe muchas delegaciones, mi nodo nunca será incluido en el comité de validación y, por lo tanto, mi nodo no aumenta la fuerza y seguridad del conjunto. rojo. ¿Es esto correcto?

nikita: Esa es una buena pregunta ya que se trata de una verdadera descentralización. En la versión actual del protocolo, el comité se formará tomando validadores de activos con mayor participación. El tamaño probablemente rondará los 32 validadores. Entonces, si no tienes suficiente delegación además de tu propio interés, es posible que no te incluyan en el comité. Reducimos el poder de los validadores más ricos limitando el peso de los votos de cada miembro del comité. En general, para mejorar la descentralización, esperamos tener una lotería aleatoria justa en el proceso de selección del comité en una futura actualización. Entonces, la posibilidad de que todas las partes interesadas formen parte del comité será justa y proporcional al importe de su participación.

Miembro de la comunidad: ¿Nada más que un token = un voto (por ejemplo, la relación lineal entre los tokens y el poder de voto) no te abre a los ataques de Sybil? Dado que un usuario con 100 IOTA puede crear fácilmente 100 cuentas con una IOTA. Reducir el poder de los validadores más ricos sólo funciona si son honestos (y en ese caso, ¿a quién le importa?). Si no son honestos, pueden solucionarlo fácilmente.

Nikita: Hay dos propiedades de las que estamos hablando aquí. La primera propiedad es tener un procedimiento de selección de comité que sea sólido para dividir y fusionar tokens apostados, es decir, que brinda una oportunidad justa para que todos participen en el comité. La segunda propiedad es para que los usuarios más pequeños con apuestas más pequeñas (100 usuarios con 10 IOTA apostadas) puedan superar la influencia del interesado más rico (un usuario con 1000 IOTA apostadas). Satisfacer la primera propiedad niega la segunda propiedad porque el usuario más rico podría crear 100 entidades con 10 IOTA apostadas y controlarlas a todas. Pero podemos lograr ciertas compensaciones entre ambas propiedades, por ejemplo, podemos hacer que el peso de votación esperado de un usuario sea justo (proporcional a los tokens apostados) y limitar el poder de cada usuario en el comité.

dieciséis) En una nota similar, parece que el ancho de banda de la red es un factor limitante para cada DLT si realmente se distribuye a escala global. Disminuir la sobrecarga de mensajería, permitir transacciones asincrónicas y transacciones paralelas, optimizar el software del nodo para múltiples subprocesos y mantener bajos los requisitos informáticos son formas de aumentar el rendimiento de la red. Sin embargo, en cualquier DLT, una gran mayoría de la red aún necesita ver una transacción antes de confirmarla, lo que hace que la latencia de la red sea un factor importante para la confirmación y finalización. Actualmente, los compromisos de espacios en IOTA 2.0 ocurren en intervalos de 10 segundos y esto proporciona una finalidad. Antes de este intervalo de 10 segundos es una «confirmación» probabilística, y después de un compromiso de espacio, ¿es determinista? El deCOO se ejecuta a intervalos de aproximadamente dos segundos en Shimmer. Esto proporciona un ‘reloj’ similar en algunos aspectos a las ranuras de IOTA 2.0. ¿Los compromisos de ranura podrían ejecutarse en intervalos de menos de dos segundos, o es necesario que sean más largos para permitir condiciones de red heterogéneas u otros factores? ¿Podría haber casos en los que las transacciones confirmadas pero no finalizadas fueran «suficientemente buenas»?

nikita: En la versión actual del protocolo, el proceso de confirmación es determinista, suponiendo que la red permanece sincrónica durante aproximadamente un minuto y no experimenta una congestión inesperada. Esta suposición es generalmente razonable en la mayoría de los casos de uso; por ejemplo, está totalmente bien confiar en la confirmación o incluso en la aceptación cuando el valor de la transacción es relativamente pequeño.

Pueden surgir problemas cuando la red se vuelve asíncrona. Específicamente, el único escenario en el que una transacción confirmada podría no pasar a un estado finalizado es si, inmediatamente después de la confirmación, la red se divide por completo, lo que resulta en varios compromisos asumidos por los validadores. En los casos que involucran validadores lentos o contradictorios, es posible que un compromiso carezca de la transacción confirmada, a pesar de que la gran mayoría de la red reconoce su confirmación. Si se produce una interrupción de la red, existe la posibilidad de que la red adopte la cadena de compromiso de estos validadores lentos o adversarios, excluyendo la transacción confirmada. Si bien no hemos observado tales casos en nuestros escenarios de prueba, es teóricamente posible diseñar ejemplos artificiales donde este problema podría ocurrir.

Podemos hacer que la duración del intervalo sea lo más pequeña posible, pero esto no resolverá completamente el problema de la «finalización lenta», ya que los nodos no producen ni revelan compromisos de intervalo inmediatamente después de que finaliza el intervalo, sino después de períodos. diseñado específicamente. Estos retrasos son importantes para la coherencia porque garantizan que todos los nodos honestos producirán los mismos compromisos para las ranuras en configuraciones sincrónicas. Puede leer más detalles sobre las banderas de consenso en nuestro Artículo de Wiki sobre consenso.

17) ¿Cuáles fueron las principales barreras que provocaron tanto retraso en IOTA 2.0? ¿Cuál es la parte que menos te gusta de IOTA 2.0 y que crees que debe optimizarse?

andrea: Las propiedades que surgen de nuestra estructura de datos son impresionantes: Mempool común y causal es directamente parte de nuestra estructura de datos. ¡Pero nuestra estructura de datos es muy difícil de lograr! El DAG que surge de los bloques en Tangle debe coexistir lógicamente con un DAG anidado y ortogonal que vive dentro de él: el UTXO DAG. Esto representa la causalidad de los gastos involucrados en las transacciones observadas en Tangle. Si bien estos procesos son, hasta cierto punto, ortogonales entre sí, también deben coordinarse para que surja la convergencia en toda la red. La interacción entre esta interacción y el mecanismo de selección de propinas nos obligó a reconsiderar conceptos muy fundamentales: percepción del tiempo, selección de propinas, etc.

El protocolo actual IOTA 2.0 es el resultado de una larga serie de ideas fallidas y refinamientos de ideas exitosas. Creo que la forma en que modelamos internamente la preferencia de conflicto entre conjuntos de conflictos podría simplificarse mediante la introducción de nuevas primitivas útiles que introdujimos en otras secciones del código. Además, la «votación específica» a través de tipos de referencia especializados que lleva cada bloque surgió debido a la necesidad de identificar partes del Tangle que quedarían huérfanas; A menos que esta necesidad vuelva a resultar útil en el futuro, creo que es posible un mecanismo de votación simplificado e «implícito»: reduciendo la complejidad en los componentes de selección y reserva de propinas.

18) ¿En qué se diferencia la estrategia de mantener y vender Mana en IOTA del enfoque convencional de vender tokens de recompensa en bloque de inmediato? Dado que los productores de bloques en cadenas de bloques tradicionales como Ethereum pueden (1) usar las recompensas de ETH como un indicador del rendimiento de la red al aumentar los precios del GAS y (2) retrasar la venta de sus recompensas en anticipación de una mayor demanda y precios, ¿hay algún aspecto del diseño de Mana? ¿Qué difieren u ofrecen ventajas en este sentido?

Andrés: Hay dos formas en las que nuestro enfoque es esencialmente diferente. La primera es que las recompensas en cuestión no son el token base, y la segunda es que no existe una opción sencilla para «subir» el precio del acceso. La única manera de aumentar el precio de emisión por sí solo es congestionando la red, lo cual es tremendamente caro y completamente inviable. Retrasar la venta de recompensas en previsión de una mayor demanda es algo que no sería diferente de otras criptomonedas.

Porra: Además, nuestro sistema anima a los usuarios a conservar Mana en lugar de tirarlo: Mana no vale nada hasta que se utilice el libro mayor. Cuando hay uso, hay adopción y el sistema puede sostener la extracción de valor. En la mayoría de los sistemas DPoS, las personas compran monedas, ganan algunas recompensas y luego retiran dinero. Así que los sistemas están perdiendo valor constantemente.

Miembro de la comunidad: Sin embargo, esto plantea la pregunta de si los usuarios quieren ejecutar un validador, ya que esencialmente se trata de apostar por precios más altos, ya que las recompensas no serán suficientes para pagar la operación del nodo. Además, podría haber competencia con otros métodos de ingresos como la agricultura de rendimiento.

Porra: Ciertamente hay algunas compensaciones. Pero esto es una compensación para las personas que quieren ser los primeros en adoptarlo. Los primeros mineros de Bitcoin no tenían garantía de no estar perdiendo el tiempo. Pero al final, queremos alentar a las personas a ser validadores que quieran usar el sistema y quedarse, en lugar de personas que quieran ganar dinero rápido.

19) Estás introduciendo un nuevo activo, «Mana». Ahora el libro mayor, los clientes y el usuario final deben encargarse de rastrear cosas más complicadas para poder utilizar el protocolo. ¿Crees que esto se puede ocultar al usuario final?

Piotr: Se puede ocultar en parte para que el usuario final habitual no necesite ver cuánta Mana necesita para emitir un bloque y cuáles son los factores de generación y decadencia y todas las demás cosas complejas, por lo que una billetera solo podría mostrar algo así como » Tienes que esperar cinco minutos para generar maná y emitir otro bloque» o algo así. Por supuesto, eso dependerá de la implementación de la billetera, pero nos esforzaremos para que sea lo más fluida posible.

20) ¿Podrían otros proyectos criptográficos (incluso blockchains) utilizar el mecanismo de consenso de IOTA 2.0?

nikita: Sí, otros proyectos podrían utilizar ideas de nuestro protocolo de consenso (por ejemplo, nuestra regla de confirmación requiere solo tres viajes de red para lograr la confirmación, que es el mínimo). Una elección de diseño importante de nuestro protocolo de consenso es la disponibilidad dinámica, es decir, incluso en caso de interrupciones graves de la red y muchos validadores desconectados, la red actualiza constantemente un libro de contabilidad disponible. Hasta donde sabemos, esta característica no está presente actualmente en otros protocolos basados en DAG (excepto Kaspa basado en PoW, que no tiene una finalidad absoluta).

21) ¿Está terminado el trabajo del equipo de investigación o estáis trabajando en otra cosa? ¿Planea cambiar el protocolo nuevamente después de IOTA 2.0?

Porra: El trabajo de investigación para IOTA 2.0 ya está hecho, pero el protocolo definitivamente cambiará. Por ejemplo, ya estamos planeando implementar la clasificación criptográfica en el mecanismo de selección del comité. Había varias ideas que queríamos incluir en IOTA 2.0, pero teníamos que trazar una línea en la arena para poder cumplirlas. En el futuro, queremos seguir el ritmo de actualizaciones de protocolos más pequeñas y mantenimiento continuo, en lugar de proyectos masivos como Coordicide.

Piotr: Como puede ver en el tablero del proyecto para ‘iota-core’, hay muchos problemas que es bueno tener. Sin embargo, estos cambios no se producirán como un gran lanzamiento que cambie el protocolo, sino más bien en lanzamientos más pequeños. Una de esas actualizaciones será cambiar el algoritmo de rotación del comité a algo más sólido que elija a los principales participantes.

Miembro de la comunidad: Ahora que IOTA 2.0 está descentralizado, ¿cómo van a impulsar cambios futuros en el protocolo? ¿Vas a crear bifurcaciones, utilizar las discusiones de los consejos, etc.? Debe obtener la aceptación de esos cambios por parte de la comunidad que utiliza el protocolo.

Porra: Tenemos un mecanismo de actualización del protocolo en cadena, como otras cadenas. Para esta versión inicial del protocolo, utilizamos un mecanismo súper simple: después de que se propone una nueva versión del protocolo, los validadores pueden indicar su apoyo. Si suficientes validadores indican suficiente soporte durante suficiente tiempo, entonces todos cambian a la nueva versión.

22) Con todos los cambios realizados en IOTA 2.0, ¿cuánto nos hemos desviado (si es que nos hemos desviado) de la visión original de la economía de máquina a máquina y de ser la capa de seguridad para el Internet de las cosas a gran escala? ¿No plantea el requisito previo de necesitar Mana algunos obstáculos de adopción para garantizar que los sensores y dispositivos pequeños obtengan un rendimiento adecuado durante los períodos de congestión?

Porra: Hemos ampliado esta visión. La economía M2M aún no ha llegado, por lo que tiene sentido centrado en algunas cosas intermedias. Además, una cadena que puede ser una cadena económica M2M es capaz de mucho más. En la Wiki, describimos nuestra visión de Autonomía Digital para Todos, un concepto mucho más amplio que no solo permitirá la economía M2M sino que también capturará más casos de uso.

Miembro de la comunidad: Es comprensible que la visión M2M sea una apuesta a más largo plazo, y una red capaz de hacerlo también podría ser mucho más. Mi pregunta era más bien entender si algunas de las limitaciones de los dispositivos livianos y de tamaño pequeño en el escenario M2M/IoT serían fáciles de manejar con el nuevo sistema Mana para garantizar el rendimiento. Configurar toneladas de dispositivos y precargarlos con una cantidad de IOTA para generar Mana y garantizar el rendimiento me parece un poco complicado y estoy seguro de que hay mejores formas de hacerlo. Me preguntaba si usted o alguien de la Fundación IOTA ve esto como un problema de adopción en el futuro y si existe una solución más simple para hacerlo. En otras palabras, ¿cómo sería Mana o la gestión del rendimiento para dispositivos de borde pequeños?

Porra: Mana es ideal para dispositivos IoT ya que todo lo que necesitan es una billetera. Además, al utilizar nuestro sistema de cuentas, puedes tener un controlador central que contiene el maná y simplemente enumerar las PK que pueden gastarlo. Por tanto, en realidad es un sistema muy flexible.

23) ¿Qué tan tolerante a la partición será IOTA 2.0 en un escenario en el que partes de la red continúan funcionando fuera de línea o en una intranet y luego intenta volver a unirse al Tangle principal más tarde?

Porra: Una situación como esta puede ocurrir y existen diferentes escenarios:

Los nodos no validadores están aislados de la parte principal de la red. En este caso, los nodos dejarán de aceptar cosas y, por lo tanto, no emitirán ni comprometerán nada. Una vez que se vuelven a conectar, reciba todos los bloqueos y compromisos que no cumplieron y continúan normalmente.
Una minoría del comité está desconectada. En este caso se produce una bifurcación de compromiso y la aceptación continúa en ambas partes, pero la finalidad sólo puede continuar en una o ninguna de las bifurcaciones, nunca en dos. En esta situación, la partición minoritaria tendrá que cambiar sus cadenas, descartar todos los bloques y compromisos que se emitieron cuando se estaba llevando a cabo la partición y aceptar la versión de Tangle y la cadena de compromiso de la partición mayoritaria.

Miembro de la comunidad: Entonces, ¿sería exacto decir que IOTA 2.0 no es realmente tolerante a la partición como se imaginó originalmente? En una nota más simple, ¿sería correcto decir, según el teorema CAP, ahora se le ha dado menos prioridad a la tolerancia de partición sobre la coherencia y la disponibilidad de datos? Esto también significaría que los sub-Tangles «fuera de línea» o «aislados» que huérfanos del DAG principal no pueden funcionar en un silo sin volver a conectarse, ¿correcto?

Porra: No, IOTA 2.0 definitivamente es tolerante a la partición. Usamos algunas ideas que son comunes en el ecosistema para abordar el teorema CAP, como se explica en esta publicacion de blog.

24) ¿Mana tendrá algún papel que desempeñar en el poder de voto de gobernanza (sin consenso) de una cuenta?

Porra: Esto no está completamente decidido en este momento; Existen algunos problemas al usarlo de esa manera. El maná como recurso no vinculado al alma tiene los mismos inconvenientes que usar un token base (IOTA, SMR) como poder de voto, porque se puede comprar y transferir, por lo que no refleja bien la reputación de una cuenta. Tener un recurso ligado al alma podría permitirnos usarlo como puntuación de reputación, que luego podría usar como poder de voto porque no se puede comprar ni transferir.

25) ¿Con qué frecuencia se aplica la generación y decadencia de maná? Porque si la decadencia excede la generación, un usuario que usa una billetera de hardware (lo que crea un retraso potencial significativo entre el estado de la red en el que la billetera genera la carga útil y el momento en que un emisor emite la carga útil firmada) podría enfrentar problemas si así lo desea. para llevarse su Mana con ellos.

Piotr: El maná se genera en cada ranura, pero decae en cada época; En la implementación, eso no significa que repitamos todas las cuentas y resultados y los actualicemos, ya que eso sería costoso. En cambio, cada vez que necesitamos leer el valor de maná de una cuenta/salida, calculamos dinámicamente la decadencia y la generación. No estoy seguro de haber entendido correctamente la otra parte de la pregunta, pero está completamente bien crear una transacción y emitirla unos minutos u horas más tarde (con algunas excepciones en las que la transacción requiere algo de contexto). La transacción contiene un índice de ranura en el que fue creada, y ese valor se usa para calcular la generación y decadencia de Mana, por lo que si emite esa transacción al día siguiente, el Mana potencial se genera solo hasta el índice de ranura que contiene. en la transacción.

darcy: Como comentario complementario: el maná se genera linealmente (en tiempo y tokens) y decae proporcionalmente al maná retenido (a una tasa fija global). Esto significa que el maná total de un usuario siempre aumenta a menos que mueva fondos (eso ya no generará maná para ellos) o queme maná para emitir bloques.

Miembro de la comunidad: Ese fue exactamente el caso en el que pensé al escribir esta pregunta. Supuse que una ballena realizaba una gran venta de maná a una cuenta con muy pocas tenencias de tokens. En este caso, la caída sería mayor que la cantidad mínima y el usuario no podría enviar una transacción construida en una época pasada, suponiendo que se aplique inmediatamente. La retroactivación esencialmente daría una forma de deshacer la quema de maná (ya que la generación se volvería a aplicar). Esto también podría permitirle jugar con el sistema de alguna manera.

Piotr: No necesariamente. nuestro Mana se descompondría menos pero también generaría menos. Y la próxima transacción que no retrocedas desintegrará todo el maná que te saltaste anteriormente, por lo que la decadencia siempre te atrapará.

26) ¿Cómo se puede convertir Mana en créditos de emisión en bloque (BIC)? ¿Existe una respuesta diferente a la pregunta anterior si Mana se almacena en formato BIC en lugar de en un UTXO?

Piotr: Se puede convertir en una transacción. Si gastas una salida que tiene algo de maná almacenado y/o potencial, puedes asignarlo a una cuenta dentro de una transacción que lo convierte en BIC. Respecto a la segunda pregunta: No, todo el maná se desintegra al mismo ritmo.

27) ¿Por qué debería apostar/delegar en uno de los validadores más pequeños? ¿No nos anima nuestro modelo de apuestas a delegar en los 50 grupos de apuestas más grandes? ¿rs? ¿Cómo fomentar la creación de nuevos validadores más pequeños?

Andrés: Aunque nuestra implementación inicial de la selección de comités se basará únicamente en los principales participantes, planeamos implementar la selección de comités aleatoriamente en una actualización futura. Con la selección aleatoria del comité, todos los validadores, sin importar cuán pequeños sean, tendrán la oportunidad de ser seleccionados. Sin embargo, en aras de la simplicidad en el lanzamiento, comenzaremos solo con los mejores apostadores.

Entonces, como usted ha dicho, sería aconsejable que los delegados distribuyan sus fondos entre los 50 participantes principales en esta configuración inicial.

28) ¿Yo, como delegador, tengo algún riesgo de que mis tokens se bloqueen si el validador se porta mal?

andrea: No, no lo haces. Los fondos del delegador tampoco están bloqueados: simplemente se utilizan como parte del proceso de selección del validador, ya que se cuentan como parte de la función de participación para seleccionar al candidato. Sin embargo, si decide anular la delegación de sus fondos antes del final de la época, no será elegible para recibir recompensas por esa época. Como puede ver, tiene un incentivo para delegar en un validador que esté haciendo su trabajo, porque si ese validador no lo hace, ¡no obtendrá ninguna recompensa!

Miembro de la comunidad: Entonces, si delego, ¿apuesto automáticamente? ¿Podrías explicar brevemente la diferencia entre apostar y delegar?

andrea: No, la delegación es un proceso muy distinto del de apostar. Un apostador bloquea sus fondos y tiene que realizar tareas de validación si es seleccionado como parte del comité de una época.

Por otro lado, un delegador sólo puede delegar tokens a un apostador y no tiene ninguna obligación específica. La única función del delegador y sus fondos es incentivar las tareas del validador: cuantas más delegaciones puedan atraer un validador, mayores serán las recompensas que él y sus delegados podrán obtener.

29) ¿Qué característica aún debe implementarse para IOTA 2.0? ¿Cómo van las pruebas? ¿Queda todavía mucho por hacer por ese lado?

Piotr: Como puede ver en el tablero del proyecto en GitHub, todas las funciones de la primera versión se implementaron recientemente y solo estamos refactorizando y probando código aquí y allá. No planeamos implementar ninguna característica nueva antes de lanzar la red de prueba.

En cuanto a las pruebas, ya han surgido algunas excepciones de Nil Pointer y pérdidas de memoria, pero eso era de esperarse. Actualmente no vemos ningún obstáculo ni grandes problemas.

Miembro de la comunidad: ¿A qué porcentaje de cobertura del Código se dirige? ¿Y cuánto se ha hecho ya?

Piotr: No es la cobertura de pruebas lo que buscamos, porque una gran parte del código ya está cubierta con pruebas. Los problemas más difíciles surgen cuando el nodo está funcionando y de repente algunas cosas se alinean de cierta manera y fallan. Queremos centrarnos principalmente en este tipo de problemas, ya que son casi imposibles de encontrar con pruebas unitarias básicas.

Miembro de la comunidad: En ese caso, ¿qué es lo que falta concretamente para ejecutar la red de prueba pública? Al permitir que la comunidad participe, podría encontrar estos casos extremos más rápido porque más personas usan y prueban la red.

Piotr: Porque supone un gasto adicional para nosotros. Actualmente, queremos solucionar los problemas que encontramos para que usted no los experimente en la red de prueba. Algunos de esos errores podrían bloquear toda la red, por lo que, como recordarán del devnet anterior que tuvimos el año pasado, después de cada corrección de errores que tuvimos que hacer una versión con una instantánea nueva, etc. Lo cual estoy seguro también fue molesto para usted. .

Miembro de la comunidad: ¿Y cuáles son los mayores obstáculos actualmente?

Piotr: Hemos encontrado algunos errores que son difíciles de reproducir y depurar. Algunos de ellos pueden ser causados por el administrador de cadena, por lo que esperamos que el administrador de cadena reactiva resuelva algunos de ellos, ya que esto ha solucionado algunos errores difíciles de detectar en otros lugares (tuvimos un problema al marcar bloques como sólidos, lo cual sucedió una vez en un par de semanas de pruebas; el uso del enfoque reactivo solucionó ese problema).

30) Andrew mencionó en un subproceso que la duración de la época será de aproximadamente un día. ¿Cuál es la razón por la que este tiempo es bastante largo en comparación con otras cadenas de bloques? Las épocas largas hacen que sea más fácil atacar a un validador, ya sea a través de ataques en la red o socialmente, por ejemplo, sobornándolo. ¿Esto también le daría a un comité corrupto (incluso cuando los actores maliciosos no tengan el 33% de los tokens, podrían tener suerte en una futura selección aleatoria) más tiempo para causar daño?

Porra: Actualmente, no somos resistentes a los comités maliciosos. La razón es que (1) actualmente seleccionamos a los 32 principales apostadores y (2) estructuramos los incentivos para que la apuesta esté equilibrada de manera equitativa entre estos validadores. Como tal, tendremos todo lo que está en juego para asegurar cada comité, por lo que un comité malicioso significa que un tercio de lo que está en juego es malicioso.

Planeamos implementar un mecanismo de selección de comités más sofisticado mediante clasificación criptográfica. La razón por la que esto no está en la versión actual es que no queríamos más retrasos causados por la criptografía.

Miembro de la comunidad: ¿Acortar el tiempo de época a, por ejemplo, una hora, causaría problemas con el sistema actual? ¿Demasiados gastos generales?

Porra: Sí, hay muchos cálculos previos en los límites de las épocas, es decir, calcular la distribución de recompensas. Esto hace que sea más fácil hacer esto con menos frecuencia. Quizás podríamos hacerlo una vez cada hora, pero no vimos ninguna razón para cambiarlo. Además, es bueno que la época sea una potencia de dos espacios. Elegimos (2^13) 10 porque está cerca de un día y, por lo tanto, es algo intuitivo.