El Dr. Darren Tapp, investigador del Grupo Dash Core, analizó en una publicación de reddit cómo la función InstantSend de Dash puede ser escalada y, por lo tanto, no requiere actualmente una prueba de esfuerzo.

El Dr. Tapp primero respondió a otra publicación en reddit sobre el plan para expandir InstantSend en toda la red y los requisitos de los recursos.

“Soy del equipo de la ASU. Pensamos en tratar de encontrar un límite para InstantSend. Sin embargo, el límite es dictado por el número de masternodes.

Actualmente, la red puede procesar más transacciones de InstantSend de las que caben en los bloques. Por lo tanto, creo que es un poco pronto para una “prueba de estrés” para InstantSend”.

El Dr. Tapp luego describió en su artículo completo los cuatro estados en los que puede estar un nodo:

  1. No hay un bloque nuevo en la red.
  2. Un bloque nuevo es anunciado en la red.
  3. El bloque se propaga difundiendo sus transacciones.
  4. El nodo se actualiza y espera un nuevo bloque.
  5. Enjuague y repita.

El Dr. Tapp continuó describiendo que “la principal demanda de recursos de nodos está durante los pasos 2-3” y que “durante estos pasos la demanda de ancho de banda será alta y la demanda del procesador probablemente aumente”. Luego, el Dr. Tapp continuó discutiendo cómo la red de Dash puede manejar la función de InstantSend a una mayor escala debido a que la red va a avanzar lo suficientemente rápido para manejar requisitos de recursos para InstantSend.

“Los procesadores actuales son más que suficientes para manejar nuestros bloques, por lo que no es una preocupación actual. Cuando se convierta en una preocupación, será necesario el procesamiento en paralelo y los procesadores actuales soportarán mucho más. Bitcoin Unlimited ya tiene esto. Los mensajes de InstantSend pueden verificarse durante los pasos 1, 4 y 5. Para la verificación de los mensajes de InstantSend, por lo tanto, se puede usar la capacidad que ESTARÁ disponible cuando no se esté propagando un bloque. El resultado es que si la Red de Dash puede propagar una transacción extraída en un bloque, puede propagar una transacción de InstantSend en ese bloque”.

El equipo de desarrollo de Dash hace posible esta expansión

Otro usuario de Reddit le pidió al Dr. Tapp que explicara más a fondo el razonamiento de que InstantSend podría escalar sin aumentar mucho los requisitos en los recursos, lo que se pensaba que sería el caso. El Dr. Tapp comenzó explicando cómo funciona InstantSend en la actualidad utilizando “varias firmas para mostrar que todo un quórum se desactiva en un envío instantáneo”, lo cual “no difiere de la función multi-firma original en bitcoin”. Continuó explicando que “la multi-firma original que utiliza bitcoin requiere m direcciones y firmas en la estructura de datos de un gasto (siendo m la m de n). El protocolo actual de InstantSend de Dash necesita algo similar con una firma de cada miembro del quórum”. Luego Darren explicó cómo cambiará esto con la actualización 0.13.0.

“Sin embargo, la versión 13 cambiará la forma en que funciona InstantSend. Se incorporarán las firmas BLS. Es mucho más fácil trabajar con las firmas BLS. Cada miembro del quórum puede producir una participación en una firma, y si cualquier nodo tiene m participaciones de firma (de nuevo m de n), pueden combinarlas para formar una firma recuperada. Una vez que se construye la firma completa, se pueden descartar todas las firmas parciales. Verificar una firma completa, representa el mismo trabajo que verificar solo una firma BLS”.

Luego paso a explicar que los requisitos de RAM crecerán, tal como lo señaló el comentarista original, pero “el UTXO ocupa alrededor de 200 MB de RAM actualmente” en Dash. Esto se puede comparar con un nodo de BitcoinXT que actualmente ocupa un poco más de 2.2GB. Finalmente, el Dr. Tapp citó el artículo reciente de Codablock sobre los Quórums de Masternodes de Larga Vida, que DFN también cubrió anteriormente, y explicó cómo el equipo de desarrollo de Dash está trabajando en formas de escalar InstantSend.

Dash continúa innovando para aumentar la adopción

La introducción de InstantSend automático en la versión 0.13.0 de Dash hace que las transacciones de por sí rápidas de Dash, sean aún más rápidas. El tiempo normal de generación de bloques en Dash es de 2.5 minutos, pero InstantSend puede asegurar una transacción en poco más de 1 segundo gracias a la red de Masternodes. Con la actualización, esta función estará disponible para las transacciones regulares con 4 inputs o menos y eliminará la tarifa de InstantSend, que era de alrededor de $ 0.02 USD y ahora estará cerca de la tarifa mediana de Dash de $ 0.0005 USD.

La actualización 0.13.0 también traerá las listas determinísticas de Masternodes y actualizaciones a PrivateSend, además de la actualización de InstantSend. Esta actualización y la nueva versión 0.14.0 seguirán construyendo las bases para la versión 1.0, que también se considera la primera de las versiones de Evolution. Estas características radicalmente nuevas ayudarán aún más a Dash a diferenciarse de sus competidores permitiendo que sea usado fácilmente en las transacciones diarias como una moneda descentralizada y de igual a igual.

Autor: Justin Szilard

Fuente: https://www.dashforcenews.com/scalability-of-dash-instantsend-paves-way-for-network-wide-application/