La solución a los problemas con los micropagos está en implementar reservas fraccionarias dinámicas. Según este modelo, la cadena de bloques ajustará automáticamente el coeficiente de reserva de la red en momentos de congestión.

La cadena de bloques fijará un objetivo de utilización que deje margen suficiente para los picos de demanda a corto plazo. Cuando los picos se mantengan, la cadena de bloques reducirá el ancho de banda máximo por acción. Cuando el pico de demanda haya pasado y haya un exceso de capacidad, la cadena de bloques podrá aumentar lentamente el ancho de banda por uso compartido.

El ancho de banda utilizado por un usuario individual debe medirse a lo largo de un periodo de tiempo suficientemente largo como para permitir a ese usuario desplazar su uso en el tiempo. Los usuarios tienden a conectarse, hacer muchas cosas a la vez y luego desconectarse.

Esto significa que su ancho de banda durante un corto periodo de tiempo puede parecer mucho mayor que si se considera durante un periodo de tiempo más largo. Si la ventana temporal se alarga demasiado, el coeficiente de reserva no se ajustará con la suficiente rapidez para responder a los picos a corto plazo; si la ventana es demasiado corta, el uso de la agrupación tendrá un impacto demasiado grande en los usuarios normales.

En nuestra estimación debería bastar con medir el uso medio semanal de ancho de banda de los usuarios. Cada vez que un usuario firma una transacción, esa transacción se tiene en cuenta en su propia media móvil individual. Cada vez que la media móvil de un usuario supera el límite actual de la red, su transacción se retrasa hasta que su media cae por debajo del límite.

La capacidad de la cadena de bloques no está necesariamente limitada. Está dentro de la capacidad tecnológica de la infraestructura de Internet aumentar el tamaño de los bloques de Bitcoin a 10 MB, lo que a su vez reduciría el saldo mínimo requerido en un factor de 10.

Mientras que Bitcoin soporta actualmente unas 3 transacciones por segundo, las implementaciones alternativas son capaces de realizar más de 1000 transacciones por segundo.

Si suponemos que un usuario con 25 dólares en BTC realiza una transacción a la semana y paga 0,04 céntimos cada vez, pagaría más de 2 dólares en comisiones al año. Un usuario tendría que ganar una tasa de rentabilidad del 8% sobre sus 25 dólares sólo para compensar el pago de comisiones.

Lo más probable es que los usuarios mantuvieran su dinero en la blockchain de todos modos, por lo que este usuario con 25 dólares en BTC acaba de ahorrarse 2 dólares en el transcurso de un año al adoptar un enfoque de limitación de tasas en lugar de un enfoque basado en comisiones. Con sólo 175 dólares podría realizar transacciones todos los días y ahorrar 14 dólares al año.

El sistema de Steem basado en cuentas con saldos conocidos públicamente simplifica la aplicación del algoritmo de limitación de la tasa basado en el ancho de banda.

Cualquier cuenta con un saldo por debajo del mínimo requerido para realizar una transacción a la semana no podría realizarla. Esto implica que todas las cuentas nuevas deben tener al menos ese saldo mínimo. También implica que los usuarios que deseen realizar transacciones de menor cuantía pueden hacerlo, siempre que mantengan un saldo mayor y reutilicen la cuenta.

Es posible que una cuenta con poco saldo creada en un momento de poco uso quede inaccesible si aumenta el uso de la red. Los fondos podrían recuperarse en cualquier momento delegando temporalmente un saldo mayor a la cuenta.

Para mantener una experiencia de usuario razonable con un número mínimo de cuentas colgadas, todas las cuentas nuevas deberían empezar con un saldo 10 veces superior al mínimo necesario para realizar transacciones semanales. De este modo, aunque la demanda se multiplique por 10, la cuenta seguirá siendo viable.

Cualquier saldo de cuenta inicial tendría que proceder del usuario que crea la cuenta y no de la creación de tokens debido a la posibilidad de ataques sibilinos.

^{El contenido que viene a continuación no forma parte de la STEEM WHITEPAPER y debe ser interpretado como opinión y análisis del autor de este artículo, por lo cual puede ser apoyado, refutado o debatido por otros usuarios con toda libertad.}

Toda la información concerniente a esta sección de la Whitepaper está desactualizada, todo este mecanismo fue adaptado al sistema de RCs descrito en el articulo anterior, la informacion aqui contenida debe ser actualizada con los cambios introducidos en el HardFork 20, puedes encontrar esa información en inglés en los artículos oficiales Steem Velocity Hardfork - Hardfork 20 y Velocity Hardfork Account Creation Guidelines.

Tambien pude encontrar un articulo en español muy detallado con traducción y análisis de este HardFork por el usuario @ydavgonzalez cuyo enlace te dejo a continuación: ¡¡ HARDFORK 20 DE STEEMIT INMINENTE !!, RESUMEN DE LOS CAMBIOS EN 5 PUNTOS, PREPÁRATE PARA LA ACTUALIZACIÓN DE ESTE 25 DE SEPTIEMBRE.

Ya que todo está escrito y de una forma muy clara no tengo nada que añadir a este contenido, en este caso aplica lo descrito por mi en el artículo Importancia y Estructura de la traducción. el cual establece que en los casos para los cuales los articulos traducidos no contengan ningun aporte de mi parte se rechazaran los pagos ya que el contenido ha sido generado por otros usuarios, pero que si el lector estima que merezco alguna recompensa por la traduccion, estructuracion y el trabajo de investigacion puede hacerlo como forma de donacion.

¡GRACIAS POR VISITAR MI BLOG!

Si quieres ver el documento original en Ingles puedes ir a STEEM WHITEPAPER, para saber lo que me ha motivado a hacer esta traduccion y la estructura del documento traducido puedes ir aquí.