Actualización de desarrollo 2/2

Por Shift Team en Newsletter sobre 3 de octubre de 2018

Querida Comunidad,

Hoy es una actualización de desarrollo muy importante. En primer lugar, revelaremos información importante sobre el modelo de precios que respaldará el mecanismo de bloqueo utilizado para asignar almacenamiento en nuestra plataforma. Después de eso, y como se prometió en nuestro boletín anterior, discutiremos los avances que se han realizado en la tarea de integración de blockchain. Finalmente, con cierto pesar, aunque con mucho mayor optimismo, terminaremos este resumen de nuestro progreso explicando una enmienda necesaria al calendario de lanzamiento de nuestra solución de almacenamiento web y almacenamiento descentralizado.

1. Modelos de precios

El Proyecto Shift está construyendo una plataforma de almacenamiento descentralizada con la que los usuarios podrán otorgar espacio de disco a la red como proveedores de almacenamiento, así como hacer uso de los recursos de almacenamiento de otros para descentralizar sus datos y el dispositivo de alojamiento web. Dado que la provisión de espacio en el disco requiere la implementación y el mantenimiento de software y hardware, lo que requiere tiempo y dinero, un ecosistema como este solo funcionará de manera saludable y sostenible si existe un sistema financiero que recompense a los participantes por otorgar el servicios que lo sustentan. Ahora, gracias al surgimiento del primer token descentralizado del mundo, Bitcoin y la industria de la cadena de bloques que ha crecido, nosotros, en Shift, hemos desarrollado una plataforma de intercambio confiable en la que nuestros El token se puede utilizar para comprar almacenamiento descentralizado.

En el proceso de trabajar en nuestra solución de almacenamiento descentralizado, hemos considerado cuidadosamente los posibles métodos de pago incorporados en su sistema financiero, métodos que permiten a los usuarios de almacenamiento de nuestra plataforma participar en un intercambio equitativo de recursos con aquellos que proporcionan infraestructura de almacenamiento. Un resultado de estas deliberaciones son dos modelos principales que permitirían el uso de tokens SHIFT como medio de pago para replantear una reclamación de capacidad de datos. Estos dos modelos se pueden resumir sucintamente de la siguiente manera:

Modelo de transferencia directa

En el primer modelo que consideramos, los usuarios de almacenamiento pagarían directamente a los proveedores de almacenamiento a través de una transferencia de SHIFT entre las cuentas en posesión mutua. Este modelo requiere un ‘mercado de almacenamiento descentralizado’ donde los usuarios y proveedores de almacenamiento puedan publicar solicitudes y ofertas, y luego responder a ellas mediante la transacción de SHIFT para poder atenderlas.

Modelo impulsado por fórmula

En el caso del segundo modelo, los usuarios de almacenamiento son responsables de comprar SHIFT y usar una función de bloqueo integrada para reclamar un número correspondiente de bytes disponibles de espacio extraído del conjunto del clúster de almacenamiento. Aquí, el valor de MAYÚS en bytes está determinado por una fórmula económica predeterminada. Este sistema libera a los proveedores de almacenamiento de la necesidad de volver a publicar ofertas en un mercado una vez que se hayan convertido en participantes de la red, ya que su capacidad de almacenamiento se agregará al suministro general disponible para los usuarios de almacenamiento. El sistema se diseñaría de modo que los proveedores de almacenamiento sean recompensados ​​con una proporción de tokens generados simultáneamente con los producidos por cada delegado forjado.

Evaluación

Ahora que describimos brevemente los dos modelos de pago, analicemoslos prestando especial atención a dos propiedades importantes que desempeñan un papel en la determinación de si un modelo de precios es capaz de respaldar la adopción: (1) precios justos y (2) facilidad de uso .

PRECIO JUSTO

Al considerar el primer indicador de la viabilidad para la adopción, una suposición importante es que una plataforma de almacenamiento de datos saludable debe tener un precio de tal manera que se beneficie mutuamente tanto a los proveedores de almacenamiento como a los usuarios. Creemos que esto se puede lograr mejor asegurando que nuestra plataforma se encargue de que la oferta y la demanda se mantengan constantemente en un equilibrio óptimo.

Los mercados abiertos proporcionan un foro para el comercio competitivo por parte de sus participantes. Si los compradores están dispuestos a pagar X, entonces aparecerá una proporción de vendedores que estarán dispuestos a aceptar X siempre que la transacción siga siendo una ganancia neta (y viceversa). La competencia genera un equilibrio entre los precios que la gente está dispuesta a pagar y los precios que la gente está dispuesta a vender, siempre que las condiciones del mercado permanezcan relativamente estables y la oferta y la demanda no fluctúen de una manera demasiado volátil. Esto se logra porque las acciones de una pluralidad de participantes en el mercado, algunos más dispuestos a aceptar un intercambio menos favorable, normalmente moderarán las aspiraciones de maximizar la ganancia hasta un punto en el que se produzca un alto en el comercio. Por lo tanto, los mercados, que poseen una calidad dinámica, pueden contribuir a lograr precios justos.

A la inversa, la dificultad para establecer un modelo basado en fórmulas equitativas es que, debido a que elimina la competencia entre las partes en ambos lados de la transacción, debe diseñarse de tal manera que automatice el proceso de satisfacer las expectativas de los compradores y vendedores Si un lado del intercambio considera que el precio es injusto, no estarán dispuestos a usar la plataforma hasta que el precio se corrija de alguna manera. Esto significa que el modelo debe construirse de tal manera que permita una rápida autocorrección, además de ser robusto ante la posible manipulación de precios. El proceso de diseño e implementación de un modelo de precios basado en fórmulas es, por lo tanto, muy complejo.

Entonces, en resumen, un mercado descentralizado implica un método heurístico para lograr un precio ‘justo’, lo que requiere una mayor participación de los usuarios, mientras que un modelo basado en fórmulas tiene la ventaja de la automatización, haciéndolo ‘justo’ a través de la imparcialidad que resulta de ello basándose en fórmulas económicas avanzadas.

LA FACILIDAD DE USO

Con el fin de cumplir con el segundo indicador, la facilidad de uso, trataremos de garantizar que nuestros servicios estén libres de obstáculos para ambas partes. Esto se logrará a través del lanzamiento de software que atraiga a una amplia gama de clientes potenciales en su simplicidad, empleando interfaces intuitivas que fomentan el compromiso sostenido con los servicios de esa plataforma.

Somos conscientes de que incluso los entusiastas de la criptomoneda, que a menudo pasan tiempo intercambiando activos en los mercados, pueden verse desalentados por la posibilidad de participar en el “comercio” necesario para obtener espacio de almacenamiento utilizando un modelo de mercado. La gran cantidad de órdenes de compra y venta que cambian continuamente, los diferentes métodos de mostrar las operaciones pasadas y las tendencias del mercado, etc., pueden sumarse a una tarea que impide que las personas realicen su primer pedido.

El beneficio de un modelo basado en fórmulas es que todo lo que un usuario de almacenamiento debe hacer para realizar una transacción, se relaciona directamente con la interfaz de usuario responsable de permitir la entrada de una cantidad deseada de espacio de almacenamiento. Esto hace que el proceso de compra de capacidad de datos sea simple, que no depende de que otra persona cumpla “su parte del trato”. En cuanto al proveedor de almacenamiento, todo lo que requiere el modelo basado en fórmulas es designar una billetera Shift para que se acredite cuando se produce la distribución automatizada de la compensación de forma rutinaria, además de enviar una transacción que confirma la asignación de la capacidad de datos de su Dispositivo de almacenamiento a la piscina. Creemos que este enfoque minimalista incentivará a ambas partes a usar la plataforma Shift,

Entonces, en resumen, un mercado descentralizado requiere que la plataforma incorpore una funcionalidad compleja para permitir la mediación entre compradores y vendedores de la capacidad de almacenamiento, mientras que un modelo basado en una fórmula otorga mayor facilidad de uso al mediar entre aquellos que desean ofrecer capacidad de almacenamiento y aquellos A quien le gustaría hacer uso de él.

CONCLUSIÓN

Tanto un mercado de almacenamiento descentralizado como un modelo de precios basado en fórmulas presentan desafíos en su implementación. Un mercado de almacenamiento descentralizado puede tener un mecanismo de intercambio directo y una mayor “opción”, pero agrega muchas más capas de interacción que todas necesitan ser desarrolladas, construidas y administradas. Además, mantener una infraestructura de cadena de bloques de este tipo requeriría un núcleo capaz de manejar rápidamente miles de transacciones. Solo hay que tener en cuenta la falta de intercambios descentralizados totalmente operativos que se han construido sobre la base de la tecnología blockchain. Por otro lado, un modelo de precios basado en una fórmula de precios puede ser más sencillo de implementar, desde el punto de vista central, pero requiere una gran cantidad de pruebas para garantizar que cumpla con las expectativas de los compradores y vendedores, que ya no interactúan directamente.

En Shift, actualmente creemos que vale la pena explorar los beneficios del modelo de fijación de precios basado en fórmulas por su potencial para contribuir a la rápida adopción de nuestros servicios y al crecimiento de nuestra red. Automatizar el proceso de determinación de precios a través de las matemáticas y, por lo tanto, eliminar la necesidad de que los usuarios y proveedores de almacenamiento necesiten participar activamente en un mercado, puede ser un excelente medio para eliminar la barrera de entrada que, de lo contrario, podría existir si los recién llegados se enfrentaran con un comercio complejo plataforma. Por estas razones, hemos creado los primeros y más vitales aspectos del sistema de modelos de fijación de precios basado en fórmulas: una función de bloqueo de token para que los usuarios de almacenamiento reclamen la capacidad y la fórmula matemática necesaria para activarlo mediante la autorregulación del costo en SHIFT requerido para Realiza esta función.

Una vez que estos dos componentes de la tecnología de red de Shift y el sistema financiero se prueben e implementen con éxito, comenzará la tarea complementaria de finalizar los medios por los cuales los proveedores de almacenamiento serán recompensados ​​por sus servicios. Esa tarea consistirá en implementar un mecanismo de control para que los proveedores de almacenamiento verifiquen que están alojando correctamente el contenido que la red les ha asignado, así como habilitar un modelo de recompensa de bloque dinámico que distribuirá una cantidad de cada recompensa de bloque a los proveedores de almacenamiento Pasar con éxito y consistentemente el proceso de verificación. Este segundo componente del sistema financiero será la piedra angular de nuestro próximo hito de desarrollo.Tenga en cuenta que: aunque pretendemos implementar el modelo de precios basado en fórmulas primero, no hemos excluido la posibilidad de que, en una fecha posterior, re-diseñemos nuestra plataforma para que sea más apropiada para la implementación de un mercado descentralizado. 

Mecanismo de bloqueo de Shift

Ahora que hemos discutido las opciones disponibles en términos de métodos para determinar el precio de los recursos de almacenamiento en nuestra red, y también hemos explicado nuestro razonamiento detrás de centrar nuestros esfuerzos inicialmente en un modelo de precios basado en fórmulas, ahora nos gustaría explicar los mecanismos. detrás de la transacción LOCK. Aquí es donde el token SHIFT adquiere su función principal, ya que servirá como medio para replantear una reclamación al espacio de almacenamiento disponible dentro de nuestro enjambre de IPFS. El mero hecho de poseer SHIFT no da derecho a almacenamiento. Más bien, los tokens se deben bloquear mediante una transacción LOCK que, al hacer que esos tokens no estén disponibles para otros usos, funciona como una solicitud de una parte de la capacidad de almacenamiento del conjunto Shift. Este espacio de disco solo estará disponible para el usuario de almacenamiento mientras sus tokens permanezcan bloqueados, con una transacción UNLOCK que se utiliza para liberar los tokens y devolver el espacio de la unidad al grupo disponible de la plataforma. Por lo tanto, con nuestra próxima actualización de núcleo (cliente) y cartera, habrá una diferencia fundamental entre el saldo de token disponible de una cuenta y su saldo de token bloqueado.

Con el lanzamiento inminente de nuestro ‘LOCK Shift core habilitado para transacciones’ en testnet, nos gustaría proporcionar una explicación detallada de una de las adiciones más importantes que hemos hecho a nuestra plataforma, la fórmula matemática utilizada dentro de nuestra fórmula dinámica basada en fórmulas. modelo de precios:

P = C * ( X / Y ) * Z * R

  • P = [MAYÚS] = Cantidad de tokens para bloquear por la cantidad de Z de espacio en el disco.
  • C = [sin dimensiones] = constante.
  • X = [byte] = Cantidad total del espacio de disco de la plataforma que se reclama (demanda).
  • Y = [byte] = Cantidad total del espacio de disco de la plataforma que se ofrece (suministro).
  • Z = [byte] = Cantidad de espacio de disco solicitado por el usuario.
  • R = [MAYÚS / byte] = Relación de token / byte previamente iniciado (factor de conversión).

Tenga en cuenta que: esta fórmula de precio solo se refiere a los medios por los cuales se calcula la cantidad de CAMBIO bloqueada por el usuario de almacenamiento y no se utiliza para establecer la compensación pagada a los proveedores de almacenamiento por la prestación de sus servicios. El establecimiento de los mecanismos para esto formará parte del próximo hito del desarrollo. 

Además, este es el lado frontal de la fórmula. El backend solo recibe una transacción LOCK con un monto de MAYÚS y tiene en cuenta la tarifa de la transacción. El frontend genera el valor de P y ese valor es usado por el backend para calcular Z. El lado de backend de la fórmula se convierte en:

Z = P / (C * (X / Y) * R)

ANÁLISIS DE FÓRMULA
  • P, o Precio, se basa principalmente en la relación entre la demanda X y la oferta Y. Si la demanda de almacenamiento (numerador) aumenta, la fracción X / Y aumenta, lo que hace que el valor de P aumente. Si aumenta el suministro de almacenamiento (denominador), la fracción X / Y disminuye y, por lo tanto, el valor de P también disminuirá.
  • Z es la cantidad de espacio de disco que solicita el usuario de almacenamiento. Esta es la única variable en el lado frontal de la fórmula que debe ser asignada por el propio usuario.Esto significa que la interfaz de usuario para la transacción BLOQUEO solo tendrá un campo de entrada, la cantidad preferida (Z) de espacio de disco que el usuario de almacenamiento desea reclamar (o su valor correspondiente en MAYÚS). La interfaz del usuario será similar a las que se encuentran comúnmente en los intercambios de criptomonedas al realizar una orden de mercado, donde el usuario ingresa la cantidad de tokens que desea comprar y el costo correspondiente en la moneda de transacción se muestra automáticamente. La complejidad de la fórmula para P se hace así fácilmente comprensible.Tenga en cuenta: En la interfaz de usuario también será posible ingresar la cantidad de P de tokens, y se mostrará automáticamente la cantidad de Z correspondiente del espacio de la unidad. Sin embargo, creemos que es conveniente ingresar la cantidad de espacio de disco, ya que eso es lo que el usuario está obteniendo.
  • La constante C, al ser un factor multiplicador, determina la magnitud del efecto de la relación X / Y. Por ahora, C será una variable constante, aunque, en el futuro, podría modificarse en una variable dinámica según varios parámetros, como la actividad del PIN, el número de nodos de almacenamiento y las cuentas con un saldo bloqueado.Es probable que cuando la fórmula se pone en acción en la testnet, la constante C se establece en 1 / 3 o 0.3 (redondeado). Esto se debe al factor de replicación de nuestra red IPFS, es decir, de manera predeterminada, está establecido en tres y, por lo tanto, requiere que cada archivo se almacene en tres ubicaciones diferentes en todo momento. La consecuencia de esto es que con cada solicitud de pin, se utiliza tres veces más espacio en el disco cuando se compara con el tamaño real de los activos de ese pin. En otras palabras, un usuario de almacenamiento sólo puede usar 1 / 3 de su almacenamiento asignado para datos únicos. Para garantizar que la fórmula compense esto correctamente, la cifra expresada en P se reduce a un tercio de la relación X / Y.
  • El factor de conversión R es necesario para garantizar que el valor de P tenga las unidades correctas para expresarse adecuadamente de acuerdo con las propiedades numéricas del token SHIFT y, por lo tanto, se puede considerar que es la relación SHIFT / byte iniciada previamente. Es probable que R se establezca en 1 MAYÚS por 1 Megabyte (1 MB equivale a 1,000,000 bytes).Tenga en cuenta:Este factor de conversión se refiere al token SHIFT testnet y no implica necesariamente que el valor de R se establecerá en la misma cifra cuando iniciemos el modelo de precios basado en fórmulas en la red principal. Para el lanzamiento de testnet, hemos tomado la decisión de establecer R en 1 SHIFT / MB para evitar que los usuarios de testnet reclamen cantidades excesivas de espacio en el disco. Esto es una necesidad porque los proveedores de almacenamiento que otorgan espacio de disco a la plataforma testnet lo hacen sin ser compensados ​​financieramente, lo que pone restricciones en el suministro disponible dentro del ecosistema de prueba. Por lo tanto, la distribución de tokens de testnet está principalmente controlada por el Equipo Shift, siendo nuestra intención distribuir una proporción de tokens a miembros de la comunidad activa y de largo plazo.
  • La demanda X, la cantidad total de espacio de disco de la plataforma que se reclama, se calculará mediante la función SELECCIONAR SUMA (locked_bytes) FROM mem_accounts, donde locked_bytes representa el total de bytes bloqueados confirmados mantenidos contra una cuenta. Para poner esto menos técnicamente, esta función suma el número de bytes bloqueados de cada cuenta que tiene su asignación de bytes reclamados confirmada por el blockchain.
  • El suministro Y es la cantidad total de espacio de disco disponible disponible en el enjambre de IPFS. El valor de Y se calculará en función de las dos llamadas de estadísticas de enjambre (API) TotalStorage y UsedStorage, restando las dos una de la otra: TotalStorage – UsedStorage = FreeStorage, que es la cifra de Y. FreeStorage se calculará por los pares del enjambre y Así será en sí misma una convocatoria de estadísticas enjambre. TotalStorage es la SUMA del espacio en disco que cada par de enjambre ha puesto a disposición para nuestra red IPFS. UsedStorage es la SUMA del espacio que cada par de enjambre está utilizando para almacenar contenido en nuestra red IPFS.Algunos podrían preguntarse por qué no hemos definido Y, el suministro, como TotalStorage, que también habría sido una opción. Sin embargo, opinamos que esta sería una definición inapropiada para Y porque no tomaría en cuenta el hecho de que una parte del suministro de almacenamiento ya esté en uso. Para profundizar en esta definición potencialmente conflictiva, durante una instancia de escasez de capacidad de almacenamiento en el enjambre, la demanda X y la oferta Y serán casi iguales entre sí y, por lo tanto, la relación X / Y se acercará a 1. Como resultado, SHIFT / la relación de bytes estará cerca del valor iniciado previamente, R. Esto es un hecho indeseable porque la escasez significaría idealmente que la proporción de MAYÚS / bytes aumenta en relación con R. En otras palabras, el usuario debería estar obligado a bloquear más fichas para la la misma cantidad de espacio de disco cuando hay un suministro disminuido. Esta necesidad de bloquear más tokens debería, en teoría, estimular el aumento del valor del token, a cambio, alentar a los proveedores de almacenamiento a crecer en número o a aumentar la cantidad de espacio de disco que ofrecen a la red. Este resultado ideal solo se puede lograr si Y se define como FreeStorage y no como TotalStorage. Por lo tanto, es nuestra preferencia calcular FreeStorage en su lugar y definirlo como Y.
CALCULANDO Y

La dependencia del precio P de la ‘Y de estadísticas de enjambre comprobada’ es uno de los ejemplos concretos de integración de blockchain con la red de almacenamiento de Shift. Las transacciones LOCK, como cualquier otro tipo de transacción, serán procesadas y verificadas por los nodos delegados, pero esta transacción específica se basa en datos en tiempo real de los interlocutores del enjambre.

A primera vista, esta construcción puede parecer problemática, ya que los nodos delegados normalmente no podrían reconstruir la cadena de bloques, ya que un par de enjambres normalmente respondería con el FreeStorage actual y no con valores históricos. Esto se debe a que el clúster se ha creado para ser sin estado, lo que significa que no tiene una base de datos que contenga los valores históricos necesarios que un nodo delegado necesitaría verificar Y durante la reconstrucción. Como resultado, incluso las transacciones regulares y la validación de bloque por parte de los falsificadores pueden volverse problemáticas debido a que diferentes falsificadores piden a sus compañeros de enjambre que les pidan sus estadísticas, y estos pares de enjambre declaran valores diferentes de Y. conectando a sus compañeros, un tiempo de espera,

Para solucionar este problema, tuvimos que encontrar una solución inteligente que permitiera a los forjadores que son responsables de validar las transacciones LOCK mantener siempre un consenso sobre el valor de Y. Lo que pretendemos hacer es introducir un mecanismo que promueva las estadísticas del enjambre en un Ronda de delegados (45 minutos y 27 segundos). Para cualquier transacción de BLOQUEO enviada durante una ronda de delegados, el valor de Y que se usará para procesar la transacción es el promedio promedio de todos los valores de 101 Y (menos valores atípicos) que se usaron para forjar un bloque durante la ronda de delegados anterior. A continuación se muestra una descripción del flujo de trabajo que se seguirá para calcular Y durante el lapso de una ronda de delegado.

  1. Se agregará una nueva columna en la tabla de pares de nodos delegados, un almacenamiento booleano (una variable binaria, que tiene dos valores posibles llamados “verdadero” y “falso”). Como resultado, los nodos delegados tendrán algunos pares de enjambres enumerados en su configuración para encontrar compañeros de enjambre adicionales.
  2. Cada 5 minutos, cada falsificador realizará una llamada de API a un par de enjambre aleatorio para solicitar el FreeStorage de todo el enjambre de IPFS.
  3. Los compañeros del enjambre sumarán sobre la marcha, una forma alternativa de calcular a ‘sondeo’ o ‘almacenamiento en caché’, lo que significa que calculan el valor FreeStorage a pedido, solo a pedido de los falsificadores, en lugar de almacenar el valor en una base de datos. Entonces, sumando, el cálculo se genera a pedido e implica que cada par de enjambre pregunta a cada otro par cuánto espacio de disco ha configurado como disponible dentro de su configuración (TotalStorage) y cuánto espacio de disco está usando (UsedStorage). Cada interlocutor luego resume todos los valores de los demás interlocutores para TotalStorage y UsedStorage por separado. Después de esto, cada par restará el último valor del anterior para calcular Y: TotalStorage – UsedStorage = FreeStorage. El valor de Y es la información que se devuelve al falsificador que realizó la llamada a la API.
  4. Cada falsificador almacenará esta información en la memoria caché y la mantendrá actualizada al realizar dichas llamadas a la API para FreeStorage cada 5 minutos dentro de la ronda de delegados. Eso significa que durante cada ronda de delegados, el caché se actualiza con 9 valores de Y en total.
  5. Durante una ronda de delegados, se asigna a cada uno de los 101 falsificadores para forjar un bloque específico. Si un falsificador necesita forjar un bloque, utilizará el último valor de Y que haya almacenado en la memoria caché. Cuando se produce el bloque, el valor de Y se registra dentro del bloque. Los restantes 100 falsificadores (testigos) que verifican el bloque del productor del bloque tienen sus propios valores de Y almacenados en el caché. En teoría, estos deben ser exactamente del mismo valor que figura en el bloque forjado por el delegado de forja. Sin embargo, en la práctica, es muy posible que no lo sean. Por lo tanto, los 100 testigos verificarán el bloque basándose en su propio valor de Y y cuán “confiados” están de que está dentro de un rango aceptable (por ejemplo, 5% de su propio valor).
  6. Si un falsificador necesita procesar una transacción de BLOQUEO, tomará el promedio de todos los valores de 101 Y que se registraron durante el forjado en bloque de la última ronda de delegados, pero con los valores atípicos eliminados. En otras palabras, el falsificador suma los 101 valores y luego divide esta cifra por 101 para determinar el promedio de estos valores, pero excluyendo los valores atípicos basados ​​en un rango intercuartil o sus valores han caído fuera de una desviación estándar permitida.
  7. Si un falsificador necesita reconstruir la cadena de bloques y comienza a volver a verificar las transacciones de BLOQUEO, se basarán en el Y promedio de la ronda anterior. Por lo tanto, si una transacción de BLOQUEO dentro de un bloque no usa el Y promedio definido en la ronda anterior, entonces se rechazarán la transacción y el bloque. Los únicos bloques que podrían simularse son los iniciales porque aún no están informados por una “historia de Y”. Evitamos este problema plantando un valor semilla de Y en el código.
El mecanismo de desbloqueo de Shift

Ahora que hemos discutido el mecanismo de bloqueo en detalle, veamos cómo funciona la función complementaria, desbloqueo de tokens. Nuestro objetivo es otorgar a los usuarios la libertad de desbloquear cualquier proporción del MAYÚS que forme parte de su saldo bloqueado, una cifra que será el MAYÚS total bloqueado en las transacciones de BLOQUEO que ya han enviado (menos el MAYÚS devuelto de las transacciones UNLOCK posteriores) . Por lo tanto, hemos decidido hacer que la transacción UNLOCK sea proporcional, lo que significa que cada token que forme un saldo bloqueado, cuando se desbloquee, devolverá un número proporcional de bytes a la agrupación de almacenamiento. Por lo tanto, la cantidad total de tokens bloqueados por el usuario se considerará como un único valor agregado, incluso si estos tokens se bloquearon en diferentes puntos en el tiempo y se enviaron utilizando diferentes transacciones LOCK.

Las fórmulas de DESBLOQUEO: 

bytes_unlocked = (shift_submitted_for_unlock / total_shift_locked) * total_bytes_locked 

restantes_shift_locked = total_shift_locked – 

shift_submitted_for_ununnyunny_turn_returned_to_available_balance = shift_submitted_for_unnyunny_unny_united_service_for_unny

Por ejemplo: si envió 50 SHIFT y bloqueó 100 MB, entonces otros 100 MB para 55 SHIFT, el valor de total_shift_locked será 105 SHIFT y el valor de total_bytes_locked será de 200 MB. Si luego envía 30 SHIFT para un desbloqueo, devolvería (30/105) * 200 = 57.142857 MB (bytes_unlocked). Además, 75 SHIFT permanecerá bloqueado mientras que el 30 SHIFT (menos un cargo por transacción) se devolverá al saldo de su cuenta disponible.

La implementación pro-rata es muy simple para la interfaz, ya que la interfaz puede mostrar instantáneamente la cantidad de tokens que recibirá el usuario en función de la cantidad que desee desbloquear. Además, la fórmula de frontend es de dos caras. Esto significa que el usuario puede elegir ingresar la cantidad de tokens que desea desbloquear, o elegir ingresar la cantidad de bytes que desea que se devuelvan. Para el bloqueo, los usuarios pueden bloquear sus tokens solo para un objetivo específico, como obtener una cantidad requerida de espacio en la unidad, mientras que para el desbloqueo, los usuarios pueden desear desbloquear sus tokens para devolver una cantidad específica de espacio en la unidad que no están usando o porque quieren usar una cantidad específica de tokens para un propósito que no sea el almacenamiento.

Usando el mismo ejemplo: si un usuario quisiera devolver 57.142857 MB, obviamente también desbloquearía (57.142857 / 200) * 105 = 30 MAYÚS (menos una pequeña tarifa de transacción).Tenga en cuenta que: la transacción UNLOCK siempre se basará en la cantidad de tokens enviados en la transacción. En el ejemplo donde un deseo de devolución de 57.142857 MB (30 SHIFT) motivó el desbloqueo, entonces lo que el frontend enviará realmente al backend es una solicitud para desbloquear 30 SHIFT (menos una pequeña tarifa de transacción). 

Además, es importante tener en cuenta que cualquier transacción de DESBLOQUEO está restringida en función de los pines actuales que tiene la cuenta. Para que el DESBLOQUEO sea válido, el usuario debe tener suficiente espacio de almacenamiento bloqueado sin usar / sin clavijas. Utilizando el mismo ejemplo en el que se reclamaron 200 MB, la transacción DESBLOQUEO solo sería válida si la proporción que se utiliza / fija no es mayor que 200 – 57.142857 = 142.857143 MB. 

2. Integración de blockchain

Ahora que hemos dado algunos detalles sobre el modelo de precios, además de explicar el mecanismo de bloqueo, es hora de discutir los últimos avances en la integración de blockchain.

  • Rob L. ahora ha completado las migraciones de base de datos necesarias para agregar soporte para el seguimiento de las estadísticas de enjambre y el seguimiento de las funciones de bloqueo / pin. El código de la base de datos se ha escrito para insertar BLOQUEO y DESBLOQUEO, así como las transacciones de PIN y UNPIN en la tabla de memoria (que almacena la información solicitada anteriormente), lo que permite realizar búsquedas rápidas de estas transacciones. Luego de esto, Rob también pudo actualizar la tabla de cuentas de memoria (que almacena la información de la cuenta de quienes enviaron las transacciones anteriores) para que pueda realizar un seguimiento de los datos de bloqueo pendientes y confirmados. Esto permite que el sistema mantenga un total de los saldos bloqueados y disponibles de un usuario.
  • El código de transacción ahora realiza un seguimiento de los saldos disponibles para que no sea posible realizar transacciones que no sean PIN, UNPIN y UNLOCK con el saldo bloqueado de una cuenta.
  • Las clases lógicas para las transacciones de BLOQUEO y PIN ahora están completas, aunque aún no se han conectado a las clases de módulos.
  • El bloqueo de un saldo disponible acredita el saldo bloqueado de una cuenta y aumenta proporcionalmente su cuota de bytes de almacenamiento total. A la inversa, el desbloqueo de un saldo bloqueado reducirá la asignación de bytes de almacenamiento del usuario en función de la proporción de MAYÚS bloqueado frente al monto de la transacción, menos todas las tarifas aplicables. Todas las solicitudes se emparejan con SHIFT y bytes, con el valor de bytes y SHIFT calculado utilizando la fórmula de nuestro modelo de precios.
  • The constants.js introduce las variables de fórmula para que pueda controlarse mediante la altura del bloque.
  • Los puntos finales PIN, UNPIN, LOCK y UNLOCK están definidos.

Cosas que Rob tiene la intención de completar en la próxima semana:

  • Conecte los módulos lógicos a los puntos finales.
  • Complete la validación de bloque y el promedio de ronda de la transacción LOCK.

Una vez que se completen esas dos tareas finales, estamos listos para comenzar y entraremos en la fase de prueba en nuestra red privada. Es importante tener en cuenta que, si bien los componentes individuales se han probado con éxito localmente, una vez que las partes constituyentes se juntan, inicialmente será necesario monitorearlas cuidadosamente para garantizar que funcionen como se espera en general.Tenga en cuenta que las transacciones de PIN y UNPIN se explicarán en detalle en una actualización de desarrollo posterior. 

3. Lanzamiento reprogramado de la solución de almacenamiento descentralizado

En nuestro boletín del 17 de julio de 2018, nosotros, el Equipo Shift, anunciamos nuestra expectativa de que para la conclusión del tercer trimestre de este año, habríamos lanzado una solución de almacenamiento descentralizado en funcionamiento en nuestro proyecto testnet. Este era un objetivo que aspirábamos a lo largo de los meses subsiguientes, un objetivo que usábamos para desafiarnos y motivarnos para lograr nuevos y emocionantes avances mientras trabajábamos durante esta larga pausa en la vitalidad del mercado. Sin embargo, no se puede negar que aún quedan algunas tareas finales por completar antes de que la última versión de nuestra tecnología de almacenamiento esté lista para ser transferida de nuestra red privada al dominio público de Shift testnet.

Le pedimos a usted, nuestra comunidad, que aguante, con nosotros, solo un poco más, la espera entre ahora y el momento en que compartimos nuestro producto de cambio de juego con el mundo. Una vez que hayamos completado la prueba del código, asegurando que el flujo de trabajo del software permita que las funciones funcionen correctamente y que el sistema mantenga su integridad en circunstancias ideales, estaremos listos para ponerlo en acción en un entorno en el que las masas lo harán. tener acceso.

Como podemos demostrar en este boletín, gastamos una gran cantidad de energía en contemplar la manera óptima de teorizar y actualizar soluciones a problemas que, hasta hace muy poco, no habían molestado a la mente humana. De lo que no debe dudar es que se están encontrando soluciones y que se están completando los pasos finales para preparar nuestra solución de almacenamiento y alojamiento descentralizado para uso público. A modo de ejemplo, Craig C. ha terminado de trabajar en su primera versión del Shift IPFS Cluster Pin Manager. De hecho, la contribución de esta aplicación de software a la operación de nuestro producto es tal que hemos decidido que garantiza un nombre que transmite efectivamente el papel innovador que desempeña para garantizar que los datos permanezcan accesibles y no se puedan censurar siempre que lo desee el cargador. Por eso, nos gustaría introducirPhoenix , la biblioteca punto a punto Shift y el módulo de emisión de comandos de PIN, y dedicar nuestro próximo boletín informativo, que se publicará antes de nuestro lanzamiento revisado de testnet, para explicar la importancia de su función. Para Phoenix, junto con la integración de blockchain, es una de las piezas finales del rompecabezas que se agregará a nuestra plataforma incipiente antes de su lanzamiento, antes de presentar nuestro trabajo a usted, la Comunidad Shift.

Atentamente, 

El Equipo Shift

Leave a Reply

Your email address will not be published. Required fields are marked *