Shift Project: Reporte de Progreso

El objetivo de este documento es proporcionar a los posibles usuarios y socios un resumen completo de las actividades del Proyecto Shift que preceden a nuestro próximo lanzamiento. Contiene un resumen detallado del progreso que ha realizado el Proyecto Shift durante el último año, y proporciona la información necesaria para comprender el trasfondo de la creación de la primera solución de almacenamiento y alojamiento web del Sistema de archivos interplanetarios (IPFS) gobernada por blockchain.

Q3 2017 – El lanzamiento del Phantom dApp

Comenzamos nuestro resumen en julio de 2017, el mes en el que el Proyecto Shift alcanzó su lanzamiento de producto más importante hasta ese momento. Durante ese verano, lanzamos el prototipo de nuestra aplicación descentralizada (dApp), Phantom, en la red de pruebas Shift. Esta primera versión de nuestro software de almacenamiento de información y almacenamiento web IPFS personalizado consistió en una interfaz intuitiva de “arrastrar y soltar” para la gestión de archivos a través de la red IPFS global.

Un logro significativo, esto brindó a la iniciativa IPFS global1 una interfaz de usuario (UI) que en su momento le faltaba. Además, la interfaz de usuario fantasma de Shift debutó con un asistente del sistema de nombres de dominio (DNS) para señalar los dominios de nivel superior al registro del espacio de nombres interplanetarios (IPNS) del contenido publicado. Esto hizo posible alojar páginas web estáticas usando nuestra puerta de enlace, con la opción adicional de usar registros de texto (TXT) para apuntar direcciones web fácilmente inteligibles al hash global de la red de igual a igual, haciendo que el contenido sea accesible a través de navegadores regulares. aunque hacerlo sacrifica un grado de resistencia de censura debido a la posibilidad de bloqueo de dominio. A diferencia de la de hoy, este primer prototipo de Phantom se conectó a la red IPFS global. Sin embargo, En aras de establecer nuestro propio ecosistema de almacenamiento de blockchain habilitado en la plataforma Shift, decidimos que sería necesario adoptar un objetivo de crear una infraestructura de IPFS privada. La razón principal para cambiar a una red de almacenamiento privada basada en IPFS fue que, con nuestro caso de uso de unir usuarios y proveedores de almacenamiento dentro de un modelo de ingresos accionado por la oferta y la demanda, una red privada nos permitiría facilitar la presencia de almacenamiento persistente. Coexistir dentro de una red global y gratuita significaría aceptar el mayor riesgo de que los recolectores de basura puedan eliminar el contenido (procesos diseñados para borrar automáticamente la memoria del disco si la disponibilidad de espacio alcanza un cierto umbral) de un proveedor sin incentivo para mantenerla. Esta era una perspectiva que el Proyecto Shift no podría cumplir. decidimos que sería necesario adoptar un objetivo de crear una infraestructura de IPFS privada. La razón principal para cambiar a una red de almacenamiento privada basada en IPFS fue que, con nuestro caso de uso de unir usuarios y proveedores de almacenamiento dentro de un modelo de ingresos accionado por la oferta y la demanda, una red privada nos permitiría facilitar la presencia de almacenamiento persistente. Coexistir dentro de una red global y gratuita significaría aceptar el mayor riesgo de que los recolectores de basura puedan eliminar el contenido (procesos diseñados para borrar automáticamente la memoria del disco si la disponibilidad de espacio alcanza un cierto umbral) de un proveedor sin incentivo para mantenerla. Esta era una perspectiva que el Proyecto Shift no podría cumplir. decidimos que sería necesario adoptar un objetivo de crear una infraestructura de IPFS privada. La razón principal para cambiar a una red de almacenamiento privada basada en IPFS fue que, con nuestro caso de uso de unir usuarios y proveedores de almacenamiento dentro de un modelo de ingresos accionado por la oferta y la demanda, una red privada nos permitiría facilitar la presencia de almacenamiento persistente. Coexistir dentro de una red global y gratuita significaría aceptar el mayor riesgo de que los recolectores de basura puedan eliminar el contenido (procesos diseñados para borrar automáticamente la memoria del disco si la disponibilidad de espacio alcanza un cierto umbral) de un proveedor sin incentivo para mantenerla. Esta era una perspectiva que el Proyecto Shift no podría cumplir. La razón principal para cambiar a una red de almacenamiento privada basada en IPFS fue que, con nuestro caso de uso de unir usuarios y proveedores de almacenamiento dentro de un modelo de ingresos accionado por la oferta y la demanda, una red privada nos permitiría facilitar la presencia de almacenamiento persistente. Coexistir dentro de una red global y gratuita significaría aceptar el mayor riesgo de que los recolectores de basura puedan eliminar el contenido (procesos diseñados para borrar automáticamente la memoria del disco si la disponibilidad de espacio alcanza un cierto umbral) de un proveedor sin incentivo para mantenerla. Esta era una perspectiva que el Proyecto Shift no podría cumplir. La razón principal para cambiar a una red de almacenamiento privada basada en IPFS fue que, con nuestro caso de uso de unir usuarios y proveedores de almacenamiento dentro de un modelo de ingresos accionado por la oferta y la demanda, una red privada nos permitiría facilitar la presencia de almacenamiento persistente. Coexistir dentro de una red global y gratuita significaría aceptar el mayor riesgo de que los recolectores de basura puedan eliminar el contenido (procesos diseñados para borrar automáticamente la memoria del disco si la disponibilidad de espacio alcanza un cierto umbral) de un proveedor sin incentivo para mantenerla. Esta era una perspectiva que el Proyecto Shift no podría cumplir. Una red privada nos permitiría facilitar la presencia de almacenamiento persistente. Coexistir dentro de una red global y gratuita significaría aceptar el mayor riesgo de que los recolectores de basura puedan eliminar el contenido (procesos diseñados para borrar automáticamente la memoria del disco si la disponibilidad de espacio alcanza un cierto umbral) de un proveedor sin incentivo para mantenerla. Esta era una perspectiva que el Proyecto Shift no podría cumplir. Una red privada nos permitiría facilitar la presencia de almacenamiento persistente. Coexistir dentro de una red global y gratuita significaría aceptar el mayor riesgo de que los recolectores de basura puedan eliminar el contenido (procesos diseñados para borrar automáticamente la memoria del disco si la disponibilidad de espacio alcanza un cierto umbral) de un proveedor sin incentivo para mantenerla. Esta era una perspectiva que el Proyecto Shift no podría cumplir.

Q4 2017 – La web descentralizada

Luego de un agosto difícil durante el cual soportamos la partida de varios miembros del equipo, en septiembre de 2017, después de haber decidido que una red privada de IPFS sería una necesidad, anunciamos una promesa a nuestra comunidad. Nos comprometimos a entregar, antes de fin de año, un segundo prototipo del Phantom dApp que se conectaría a nuestra propia red de almacenamiento, la primera versión del Shift IPFS Cluster. Durante ese período, también nos dimos cuenta de que se necesitaba un nuevo sitio web del proyecto. Esto se debió a que el sitio en ese momento carecía de información suficiente que describiera exactamente lo que el Proyecto Shift está tratando de lograr. Nuestro deseo era proporcionar una explicación clara de la misión del proyecto,

En ese momento, había dos identidades que el Proyecto Shift había venido a habitar. La decisión de trasladar el proyecto a una bifurcación Lisk2 en octubre de 2016, un proyecto que se anuncia a sí mismo como una plataforma de aplicaciones blockchain, implicó una ambición de apoyar el desarrollo de dApp. Si bien esto parecía apropiado, dado que buscábamos desarrollar, en Phantom, el dApp “perfecto”, no queríamos sugerir que la construcción de una plataforma de dApp era nuestro objetivo principal. Desde nuestra perspectiva, esto tendría poco sentido como una decisión de negocios, ya que nos pondría en competencia con proyectos con mucho mayor financiamiento. Sin embargo, lo que implica que estábamos trabajando principalmente en una solución de almacenamiento con la capacidad adicional de alojar contenido web, nos habríamos arriesgado a convertirnos en un competidor percibido como Filecoin3, que recientemente había llamado la atención por completar una oferta inicial de monedas (ICO) en la que se recaudó un récord de 257 millones de dólares. Y así, decidimos comercializarnos en algún lugar entre estos dos extremos, como una plataforma descentralizada con capacidad de aplicación de datos, con un enfoque principal en el alojamiento de sitios web.

Con el fin de resaltar simultáneamente nuestros logros tecnológicos, además de establecer con más firmeza nuestra identidad de marca, así como proporcionar un poco de motivación, anunciamos que además de lanzar nuestro propio clúster de almacenamiento, alojaríamos nuestro nuevo sitio web con nuestra propia tecnología en ciernes. . Esto, en el proceso, lo convertiría en el primer ejemplo de un sitio web descentralizado con contenido dinámico, accesible en un navegador regular sin el uso de complementos de terceros e incorporando un dominio de nivel superior real.

Esos meses entre septiembre y el Año Nuevo fueron algunos de los más difíciles que hayamos trabajado, y trabajamos hasta el último día de diciembre. A pesar de las dificultades, nuestros esfuerzos dieron sus frutos y, al cumplir nuestra promesa, pudimos hacer historia. Creamos la base de nuestro propio ecosistema de almacenamiento, una solución de almacenamiento permanente que otorga al usuario el control total de su propio contenido publicado (su sitio web), comparable, si no más rápido, a los servicios proporcionados por las plataformas de alojamiento web centralizadas. Uno puede preguntarse: “¿Cómo se hizo esto?” El lanzamiento de nuestro nuevo sitio web, utilizando Phantom para alojarlo en el Cluster de IPFS de Shift, fue posible gracias a tres tecnologías subyacentes.

El cluster de cambio de IPFS

El Shift IPFS Cluster, que en ese momento se basaba en el cliente independiente creado por Protocol Labs 4 (conocido como IPFS Cluster), permitió al usuario pinchar contenido utilizando el principio de un conjunto de factores de replicación, de manera predeterminada, para Tres. Este principio significa que una vez que el contenido se publica y luego se fija, se copia a través de la red y se almacena en tres ubicaciones separadas (nodos) en todo momento. Debido a la naturaleza basada en el contenido de IPFS, el protocolo de distribución de hipermedia peer-to-peer asigna a los datos un hash que permite a la red identificar el contenido y detectar si uno o más de los tres nodos no lo están atendiendo. En el caso de que un nodo no pueda entregar contenido, otro interlocutor dentro del Clúster de IPFS descargará los datos de los interlocutores restantes, devolviendo el número total de fuentes disponibles a tres.

Jenga

El protocolo IPFS, mientras proporciona un sistema de archivos basado en contenido, no ofrece una variante descentralizada del sistema de nombres de dominio que es tan integral para el funcionamiento de Internet de hoy. Con el fin de garantizar que nuestro sitio web sea accesible en navegadores regulares, necesitábamos apuntar un dominio a su hash IPNS. Si bien creemos que los hashes IPNS de la tecnología IPFS representan una revolución en la manera en que Internet puede funcionar, al otorgar resistencia a la censura y la capacidad de detectar si se pierde una conexión entre el cliente y el servidor y ya no se sirve el contenido. Falta un cierto grado de facilidad de uso. La compatibilidad con las llamadas ‘URL bonitas’ que utilizamos para acceder a los sitios es, en nuestra opinión, crítica para la adopción masiva. De este modo, llegamos a la conclusión de que, hasta que se desarrolle una variante descentralizada del sistema de nombres de dominio, es necesaria una solución provisional para facilitar la transición de la antigua a la Nueva Web. Por lo tanto, creamos Jenga, un monitor de DNS personalizado.

Jenga es responsable de inspeccionar activamente los nodos en el clúster para asegurarse de que estén almacenando correctamente el contenido anclado. Este es un proceso continuo en el que se mantiene una lista interna de nodos en buen estado que están listos para servir el contenido, garantizando que solo se mantengan en el DNS. Jenga hace que el contenido web publicado sea resistente a los ataques DDoS sin sacrificar una URL preexistente. De esta manera, Jenga le permite a Phantom unir la Web antigua (HTTP / DNS) y la Nueva (IPFS / IPNS), facilitando: dominios reales de nivel superior, el uso de navegadores regulares sin complementos de terceros, y un contenido Basada, infraestructura peer-to-peer.

Hydra

Hydra es un sistema de gestión de contenido (CMS) descentralizado y compatible con IPFS. Con el lanzamiento de nuestro sitio web, queríamos ofrecer más que una simple página estática. Aunque con IPFS solo puede alojar sitios web estáticos, Hydra permite la publicación de contenido dinámico en estos sitios mediante el almacenamiento de archivos de datos de notación de objetos de JavaScript (JSON) o JSON utilizados para extraer datos de API de terceros. Además, con Hydra puede editar fácilmente el contenido web sin tener que reconstruir y volver a publicar todo el sitio para aplicar estos cambios. Las capacidades de Hydra son esenciales para permitirnos brindar soporte para el almacenamiento de datos específicos de la aplicación, al menos a pequeña escala, y optimizar esta integración de datos.

La finalización y el despliegue de estos tres componentes integrales por parte de nuestro equipo de desarrollo hizo que viéramos 2017 con un primer histórico. También nos dio una nueva ambición y un impulso para ver que 2018 no sería diferente en ser un año de innovación, y aún queda mucho trabajo por hacer para lograr nuestro objetivo de crear una aplicación innovadora para el almacenamiento y el servicio de medios digitales.

Q1 2018 – Publicación del Libro Blanco y mejoras del producto

Libro blanco introductorio

El primer mes de 2018 concluyó con el lanzamiento de nuestro Libro blanco introductorio 5, titulado: Fantasma: un paquete de almacenamiento descentralizado . Con este documento técnico, quisimos abordar el problema que resuelve Shift’s Phantom dApp, además de describir la arquitectura de nuestra plataforma sin sobrecargar el texto con detalles técnicos innecesarios. Gracias a la asistencia de Isabella Dell, la ex arquitecta de sistemas de Lisk, quien a fines de noviembre de 2017 se convirtió en asesora de Shift, pudimos elaborar un rico documento explicativo que explicaba nuestra ambición principal: la provisión de un almacenamiento innovador. y el servicio de alojamiento web capaz de eliminar fundamentalmente la capacidad de los actores maliciosos para censurar injustamente e impedir la distribución ética de información legítima.

Shift IPFS Cluster Update y Custom IPFS Daemon

El primer trimestre también nos vio debutar algunos cambios importantes en el Shift IPFS Cluster luego del lanzamiento de una nueva versión del software Protocol Labs. Craig C., uno de nuestros desarrolladores principales y creador de Jenga, trabajó en la actualización del software para solucionar los problemas causados ​​por algunos de los errores graves del Cluster IPFS, además de asumir la tarea de crear un demonio IPFS personalizado para admitir la reescritura de URL ( enrutamiento), redireccionamiento de URL, páginas de error 404 personalizadas y la implementación de Regex (un superconjunto de comodines) para la reescritura de IPFS.

  • Actualización de Jenga: monitoreo de nodos más estrictos

Aunque en diciembre de 2017 quedamos muy impresionados con la versión de Protocol Labs de IPFS Cluster, pronto comenzamos a tener problemas con su software que, después de todo, todavía estaba en ‘alfa’. Hubo un problema que resultó ser particularmente problemático. Comenzó a surgir un estado en el que el clúster de IPFS podía alojar contenido debido a la ejecución de IPFS, pero el clúster podría tener problemas con la fijación. El resultado fue que, si bien Jenga aún podía encontrar contenido, en realidad no se podía fijar contenido nuevo a estos nodos. Lo ideal es que cuando se agrega y se replica un archivo en el clúster, Jenga busca ese archivo y, si es capaz de encontrarlo en el número requerido de nodos DNS, registra que los compañeros están en buen estado. Desafortunadamente, lo que estaba sucediendo era que si un par por cualquier motivo se desconectaba del clúster debido a problemas en el Cluster de IPFS, lo que significaba que ya no se podían hacer nuevos pines, Jenga no pudo registrar correctamente que el par ya no estaba presente, lo que provocaba La devolución del error 404s para nuevo contenido. El éxito de la actualización implementada por Craig radica en la forma en que tiene los archivos de prueba de pin de Jenga en el clúster a intervalos establecidos, por lo que confirma que todos los pares pueden entregar contenido recién anclado.

  • Reescritura de URL (enrutamiento)

Para aumentar nuestra ambición de hacer que nuestra plataforma sea lo más fácil de usar posible, nos encargamos de que nuestra inclusión del enrutamiento personalizado nos permitiera usar, además de las URL bonitas, la funcionalidad ‘ruta bonita’ (las URL terminan en cosas como ./ equipo, ./home etc.) y haga que estas rutas se resuelvan en el mismo hash en el lado del servidor. Es importante tener en cuenta que IPFS no ofrece ninguna manera ‘fuera de la caja’ para implementar el enrutamiento personalizado para los sitios web alojados. Esto se debe a que cuando los ingenieros detrás de IPFS implementaron el servicio de archivos, decidieron no incluir el soporte para enrutamiento personalizado, en lugar de optar por admitir rutas directamente dentro de las carpetas de contenido. Sin embargo, el concepto de “rutas bonitas” es uno de los más utilizados en muchos marcos web, como en Apache (un sistema con el que la mayoría de los desarrolladores web están familiarizados).

Si quisiera usar diferentes esquemas de URL o hacer todo el enrutamiento desde una sola página en JavaScript, bajo IPFS tendría que usar un enrutamiento personalizado o el # que se encuentra en las URL como https://ipfs.io/#how . Lo que hemos hecho con nuestro demonio IPFS personalizado, es permitir al operador del sitio dirigir ./how para cargar how.html, o cualquier otro archivo. Nuestro demonio IPFS personalizado respeta esa asignación, algo que se puede ver al navegar por nuestro sitio en, por ejemplo, https://shiftproject.com/team , donde nuestro enrutamiento personalizado garantiza que funcione sin problemas. El hecho de que logramos proporcionar esta funcionalidad fue un gran logro, ya que los rastreadores de los motores de búsqueda pueden leer las rutas de acceso de URL. Esto tiene el profundo efecto de habilitar la optimización del motor de búsqueda (SEO) para cualquier sitio web alojado en nuestra plataforma.

  • URL de redireccionamiento

De manera similar a la reescritura de URL, la redirección de URL se usa para evitar que no se recupere el contenido si se ha reubicado una página. Como es otro aspecto importante del SEO, fue una parte integral que lo incluimos en el conjunto de habilidades de nuestro software. Por ejemplo, en enero de 2018 descubrimos algunos enlaces rotos que aparecieron en los resultados de búsqueda de Google que apuntan a páginas de nuestro sitio web anterior. La redirección de URL nos permitió corregir este problema y eliminar la posibilidad de que vuelva a ocurrir.

  • Páginas de error 404 personalizadas

A pesar de ser una adición en gran medida cosmética, decidimos agregar soporte para páginas de error 404 personalizadas en casos donde las páginas están vinculadas que no existen. Un ejemplo de este tipo de página de error se puede ver en: https://www.shiftproject.com/notfound . Esta es la versión personalizada de la página de error 404 para nuestro propio sitio web, que demuestra cómo un operador del sitio, en lugar de confiar en el valor predeterminado de IPFS “no inspirado”: https://ipfs.io/notfound , puede configurar su no se encuentra la propia página de ‘buen aspecto’ cuando surge el caso en el que el contenido solicitado no existe.

  • Soporte de Regex para reescrituras de IPFS

Regex es un superconjunto de comodines utilizados para denotar cualquier carácter o rango de caracteres en una ruta URL. La compatibilidad con Regex es otra funcionalidad que aumenta la facilidad de uso de las capacidades de alojamiento de la plataforma Shift, ya que las reescrituras de IPFS son una función que permite usar URL bonitas que enlazan con rutas de acceso IPFS personalizadas. En pocas palabras, un usuario podría establecer una ruta de URL para que cualquier URL que coincida con ./about/* muestre una determinada página. En otras palabras, el soporte de Regex le permite asignar ./file/:id a una ubicación determinada, en lugar de tener que asignar cada URL directamente. Por lo tanto, en lugar de tener que listar ./file/1 ./file/2 ./file/3 etc. en las rutas, puede especificar una ruta. Esta adición fue algo inspirada por .htaccess en Apache, una similitud que hará que la transición a la plataforma Shift sea un proceso más ágil.

Q2 2018 – Evaluando la Plataforma Shift

Cadenas laterales

En junio del segundo trimestre, gracias a una gran cantidad de pensamiento y trabajo dedicados a la tarea por parte del presidente y desarrollador principal, Ralf S., en el Shift Team anunciamos el logro sustancial de ser una de las primeras plataformas de dApp que desplegaron cadenas laterales de trabajo. . En pocas palabras, las cadenas laterales son cadenas de bloques que se registran en una cadena principal y se ejecutan en paralelo con ella, proporcionando una solución de escalabilidad para una plataforma en la que se ejecutarán las aplicaciones descentralizadas.

Para explicar por qué decidimos dedicar tiempo a la tarea de hacer que las cadenas laterales funcionen, es necesario comprender primero la arquitectura de la plataforma de aplicación Crypti / Lisk original, el proyecto del cual nuestra plataforma fue bifurcada. Hay esencialmente tres componentes principales dentro del diseño original de Crypti / Lisk: el núcleo de la cadena de bloques (mainchain), un sandbox, un subproceso Node.js aislado que puede no leer el proceso principal, solo comunicarse con él a través de una interfaz de programación de aplicaciones (API) —Y un kit de desarrollo de software (SDK) —un plano para todas las cadenas laterales. Estos tres interactúan de una manera particular, con el SDK solo puede enviar solicitudes a la zona de pruebas para cierta información de la cadena principal, mientras que la caja de arena responde al SDK con la información solicitada de la cadena principal. En otras palabras, la comunicación entre la cadena principal y la cadena lateral pasa por el arenero y es unilateral. La principal ventaja de esta construcción es que si la caja de arena se bloquea por alguna razón, debido a una sobrecarga de la cadena lateral, el núcleo de la cadena de bloques (cadena principal) sigue funcionando.

Si bien las cadenas laterales no son un componente esencial de nuestra solución de almacenamiento web y almacenamiento descentralizado, creemos que al ejecutar nuestra aplicación insignia, Phantom, con su propia cadena lateral, otorgaríamos a la cadena principal un elemento de protección contra subprocesos (como contenido de alto volumen). subidas) que podrían correr el riesgo de sobrecargarla y ralentizar las transacciones. Phantom también sería el ejemplo perfecto de un dApp con un caso de uso de sidechain real, ya que la sidechain podría usarse como un medio descentralizado para controlar la red de almacenamiento IPFS privada, mientras que los tokens en la sidechain podrían usarse para comprar almacenamiento y recompensar a los proveedores de almacenamiento. .

Inicialmente, teníamos la intención de dejar la tarea de desarrollar cadenas laterales a Lisk, cuyo enfoque de código abierto nos permitiría adquirir el código, pero cuando en noviembre de 2017 Lisk anunció que no lanzaría cadenas laterales en el futuro previsible, decidimos que, en lugar de esperar un año o posiblemente más para bifurcar su código, buscaríamos la innovación en esta solución de escalabilidad potencialmente útil. Así que ese mes, Ralf comenzó a trabajar en el desarrollo de sidechain que continuó junto con nuestro trabajo en Shift IPFS Cluster y otros componentes de nuestra suite tecnológica. Gracias a su dedicación a esta compleja tarea, June vio el progreso necesario para ejecutar sidechains completamente estables en un entorno privado completado. Si bien el SDK nunca fue terminado por Crypti, se rompió en Lisk 0.9.0 y se eliminó completamente dentro de Lisk 1.0.0,

Al finalizar, las cadenas laterales de Shift eran estables e incluían las siguientes funcionalidades:

  • Forjar bloque, lo que significa que cada bloque de cadena principal forjado activa el forjado de un bloque de cadena lateral que luego se transmite al resto de los pares de cadena lateral.
  • Forjado múltiple, lo que significa que la forja en bloque se producirá en diferentes pares de sidechain que se ejecutan en sincronía con un factor de consenso de al menos 51, de modo que un delegado de sidechain solo puede forjar cuando tiene consenso con la mayoría absoluta de productores de sidechain block. .
  • Los compañeros de cadena lateral pueden sincronizarse de acuerdo con una búsqueda de bloque común.
  • Transferencias de token cruzadas entre la cadena principal y la cadena lateral (depósitos y retiros).

Posteriormente, Ralf creó e implementó las funcionalidades dApp necesarias en nuestra red de prueba (y en la red principal posterior) necesarias para la integración de la aplicación Phantom con su cadena lateral. Esto significó que cualquier dApp, pero en nuestro caso el Phantom dApp, se convirtió en extensible con los módulos relacionados con SDK de cadena lateral necesarios para procesar bloques y transacciones de cadena lateral, asegurando que pueda interactuar con la cadena lateral.

Debido a que completamos el código de cadena lateral y agregamos la capacidad de implementar dApps con cadenas laterales completamente estables y funcionales, uno podría preguntarse “¿Por qué las cadenas laterales, o, más específicamente, la cadena lateral fantasma, aún no se han publicado en la red de pruebas?” La razón de esto en ese momento era la forma en que se configuraban las transferencias de fichas dentro de la construcción de cadena lateral de Crypti, donde las transferencias entre cadenas se transmiten a través de una billetera de custodia (la billetera del propietario del dApp que la registró en la cadena principal). Hemos llegado a la conclusión de que la construcción de una cartera de garantía es una responsabilidad importante con respecto a la seguridad de las transferencias de fichas entre una cadena principal y sus cadenas laterales. Antes de considerar la ejecución de Phantom como una cadena lateral, decidimos que sería necesario resolver primero el problema de seguridad relacionado con las transferencias entre cadenas. Sin embargo,

Decidimos que el objetivo más apremiante del Proyecto Shift es el lanzamiento de una solución de almacenamiento web y almacenamiento descentralizado. Por lo tanto, llegamos a la conclusión de que el mejor curso de acción sería abrirnos a un nuevo enfoque. Este plan tiene la capa de almacenamiento directamente integrada con la cadena principal de Shift, evitando toda la idea de la aplicación Phantom dApp, incorporando los aspectos de la interfaz de usuario que proporcionó directamente en un Shift Nano reconstruido, nuestra cartera de clientes. Además, la integración de nuestra solución de almacenamiento y alojamiento web con el principio blockchain también tiene la ventaja de otorgar una mayor legitimidad al token SHIFT. Hacerlo significaría que actúa únicamente como un medio para reclamar un espacio de manejo o como recompensa por otorgar espacio de disco a la red Shift. y no es un token que primero necesita ser transferido en cadena cruzada antes de usarlo. El token se convierte verdaderamente en uno dedicado a su utilidad.

Algoritmo de consenso

Como se mencionó en la sección anterior, otra conversación seria que tuvimos nosotros, el Equipo Shift, durante el segundo trimestre de 2018 se refirió a la dirección a tomar con respecto a nuestro algoritmo de consenso elegido. Ya para 2017, los problemas que afectan al sistema de Prueba de estaca (DPoS, por sus siglas en inglés) que actualmente utilizamos habían comenzado a surgir, y los participantes en la “escena de la criptomoneda” se habían manifestado al expresar su descontento con las controversias que lo rodean. Una de las principales controversias es la formación y, posiblemente, la colusión de los llamados ‘grupos de delegados’, en la que los delegados que afirman compartir un cierto porcentaje de su recompensa de forja con los votantes obtienen una cantidad excesiva de influencia en la red. Un método clave por el cual esto se logra es a través de la implementación del requisito de recibir un pago por votar por un delegado, El titular de una cuenta tiene que votar por todos los miembros del grupo. La prevalencia de esta estrategia se hizo tal que los grupos de delegados a lo largo de los diversos proyectos de DPoS incluso han sido acusados ​​de tener un comportamiento similar a un cartel7, en la medida en que los proyectos supuestamente descentralizados ahora están controlados de forma centralizada.

Hemos tenido la suerte de que este fenómeno no ha ocurrido entre los delegados de forja del Proyecto Shift. Sin embargo, llegamos a la conclusión de que la medida preventiva más efectiva sería la proactividad para abordar la raíz del problema: el algoritmo de consenso. Inicialmente, pensamos que podríamos abordar los problemas presentes en DPoS mediante la implementación de dos modificaciones menores pero muy influyentes en la forma en que funcionan los sistemas de votación y falsificación:

  1. Con respecto a la votación, consideramos modificar la atribución del peso de voto por cuenta para que disminuya linealmente (o logarítmicamente) en línea con el número de votos emitidos. Esto significaría que votar por 1 delegado tendría una influencia proporcionalmente mayor que si uno votara por 2, 3 y así sucesivamente, hasta un máximo de

101. La intención detrás de esto sería el debilitamiento de los votos de aquellos que participan en la votación en grupo, mientras que también puede reducir la influencia de las grandes billeteras. El ajuste al sistema de forja que consideramos fue más profundo. Actualmente, solo hay 101 delegados de falsificación que están asignados para forjar un bloque por ronda de delegado. Dado que la clasificación (y, por lo tanto, la selección) de los delegados forjados rara vez cambia, algo que desafortunadamente ahora prevalece en los proyectos DPoS, decidimos que la implementación de un factor de asignación al azar podría beneficiar a la red al reducir este “atrincheramiento”. Si bien el número de delegados forjados por ronda de delegados se mantendría en 101, nuestra enmienda alteraría el proceso de selección de modo que, a pesar de que los delegados de mayor rango tienen una mayor probabilidad de ser seleccionados, A los delegados con un rango inferior se les daría la oportunidad de demostrar su capacidad para forjar bloques de manera exitosa y confiable. Esto se debería a la implementación de un elemento aleatorio en la selección de un mayor número total de candidatos que solo los 101 mejores delegados de clasificación.

Por ejemplo, en el caso de que 226 candidatos fueran elegibles para la forja en bloque: los primeros 1-26 (26 delegados) podrían tener un 100% de probabilidad de ser seleccionados para forjar cada ronda, los delegados 27-126 (100 delegados) tienen un 50% de probabilidad , y delegados 127-226 (100 delegados) un 25% de probabilidad. En teoría, con la posibilidad de ser seleccionados de manera consistente con una distribución normal, después de 4 rondas de delegados, los delegados 1-26 habrían forjado 4 bloques, los delegados 27-126 cada uno de los 2 bloques y los delegados 127-26 de cada bloque. Este modelo asegura que es mucho más difícil controlar una mayoría absoluta (51/101) de los delegados forjadores dentro de una ronda de delegados,

Si bien habíamos anunciado que tales cambios tendrían lugar en la Q1 / Q2 de 2018, nuestras conversaciones con Isabella Dell, que tiene un gran conocimiento en esta área, nos llevaron a concluir que aunque modificaciones menores como estas podrían combatir las debilidades en el En el sistema DPoS, no podrían remediar su problema central: su incapacidad para evitar la aparición de la colusión de delegados centralizada. Además, no harían nada para alterar el problema potencial en el que una sola persona configura de forma anónima a múltiples delegados, afirma que comparte una alta proporción de sus recompensas y, como resultado, reúne el voto popular (y el peso de la votación) necesarios para alcanzar múltiples altas – Disposición de los lugares de forja. Estos son los principales pasivos con los que nos sentimos muy incómodos,

Como habíamos reclutado a Rob Ladbrook en la primavera de 2018, un experto en el diseño de sistemas complejos con la ambición de innovar en el campo de la cadena de bloques, asumió la tarea de investigar y diseñar un nuevo algoritmo de consenso que pudiera escalar de manera segura para satisfacer las necesidades. de un sistema de archivos global creado para ofrecer características de alojamiento que ningún otro proyecto de blockchain actualmente en el mercado puede igualar. Creemos que su trabajo eventualmente nos permitirá alejarnos de los problemas de DPoS, un algoritmo que cada vez consideramos un único punto de falla. Para nosotros, la seguridad es siempre la número uno y esta situación ha aumentado nuestra ambición de diseñar un núcleo óptimo que pueda satisfacer las necesidades de un sistema de archivos global y una plataforma de alojamiento web, al tiempo que mantiene los objetivos elevados que hacen que el movimiento de descentralización sea tan convincente.

Con el fin de mantener a nuestra comunidad informada, anunciamos que una vez que la investigación de Rob estuviera completa, publicaría sus hallazgos como un documento técnico; un plano para una completa re-arquitectura de la plataforma Shift. Sin embargo, cuando llegó el momento en el que Rob había completado la investigación general sobre el tema, antes de pedirle que invirtiera su tiempo en escribir lo que debería ser un documento altamente técnico, nos sentamos a considerar las dos opciones. disponible para nosotros Podríamos dejar de trabajar en la solución de almacenamiento utilizando el núcleo basado en Lisk y, en su lugar, dedicar nuestro tiempo al documento técnico necesario para comenzar a construir un núcleo de blockchain completamente nuevo y todos los aparatos necesarios que lo acompañan, o podríamos dejarlo por el momento Enfocarse en lanzar la solución de almacenamiento y alojamiento web.

presente, lanzando una versión funcional de nuestro paquete de software que demostraría la promesa de nuestra plataforma, antes de volver a diseñar desde una base más sólida.

La primera de estas dos opciones tenía el inconveniente obvio de que nuestra comunidad tendría que esperar mucho tiempo para ver un producto en funcionamiento y nuestra entrega de un caso de uso real para el token SHIFT. Además, comenzar a trabajar en una completa re-arquitectura de la plataforma Shift requeriría expandir significativamente el Equipo Shift, necesitándonos para asegurar y administrar mayores recursos financieros. La segunda opción nos permitiría continuar trabajando en nuestra solución de almacenamiento y alojamiento web con el actual Lisk Core, lanzando una versión funcional capaz de demostrar la utilidad de nuestro token, algo que nuestra comunidad siempre ha estado esperando. Una vez hecho esto, podríamos comenzar a desarrollar el nuevo núcleo, habiendo demostrado la capacidad de realizar nuestra visión de lanzar una tecnología innovadora.

Sobra decir que elegimos la segunda opción.

Cluster de IPFS

A lo largo del segundo trimestre, nosotros en el equipo también participamos en pruebas exhaustivas del software IPFS Cluster de Protocol Labs. En particular, buscábamos una respuesta a la pregunta de si su estabilidad era suficiente o no para que fuera una opción viable para la integración con la cadena de bloques Shift. Para hacer esto y al mismo tiempo mantener la integridad del clúster privado que utilizábamos para alojar nuestro sitio web, configuramos un segundo clúster sobre infraestructura provisto voluntariamente por varios de nuestros delegados forjadores. A medida que avanzaban las pruebas, el segundo clúster se incrementó gradualmente hasta aproximadamente 20-30 pares, lo que nos permite ejecutar varios escenarios en los que los compañeros dejaron el clúster y luego intentaron volver a unirse.

El resultado de esta prueba fue crucial para determinar un cambio en nuestro curso de acción en los próximos meses. Esto se debe a que consistentemente encontramos que si incluso un solo par abandonó el clúster incorrectamente, el clúster entero inevitablemente entraría en un estado malo. Lo que es más, una vez en mal estado, los problemas se amplificaron debido a la incapacidad de los compañeros para unirse (re) unirse correctamente. El único remedio para la situación una vez que el clúster estuvo en este estado, fue el par que provocó que el mal estado se eliminara manualmente del clúster a través del nodo bootstrap, y algunas veces incluso esto no funcionó y nos obligaron a restablecer todo racimo. Como puede imaginar, no habría sido posible mantener una red de igual a igual formada por numerosos proveedores de nodos de almacenamiento en estas condiciones.

De la misma manera en que no podíamos tolerar la espera de las cadenas laterales aún no entregadas de Lisk, decidimos que no podíamos dejarnos dependientes del trabajo de Protocol Labs para solucionar los problemas fundamentales de su software. Sin embargo, algo que nuestro trabajo en sidechains también nos había enseñado era que corregir errores en el código de otros puede ser potencialmente más complejo y tomar más tiempo que simplemente crear software desde cero. Además, nos dimos cuenta de que tener nuestro propio software de clúster de almacenamiento basado en IPFS nos sería muy útil en el futuro, ya que solucionar problemas imprevistos y optimizar el código para que se adapte a su propio caso de uso específico es mucho más fácil cuando lo diseñó usted mismo. Y así, decidimos comenzar a trabajar en nuestro propio software de almacenamiento basado en IPFS. Con los nuestros,

Q3 2018 – Phoenix, integración de blockchain y nuestro modelo de precios

Con el fin de motivarnos a nosotros mismos después de nuestra decisión de reemplazar el Cluster de IPFS de Protocol Labs, nos fijamos el ambicioso objetivo de completar la primera versión de nuestra solución de alojamiento web y almacenamiento descentralizado y desplegarla en el testnet al finalizar el tercer trimestre de 2018. Reunión Este objetivo requeriría la realización de dos tareas principales. Primero, deberíamos codificar un administrador de pines basado en IPFS como una alternativa a la tecnología Protocol Labs. En segundo lugar, deberíamos integrar el administrador de pines con la cadena de red testnet, lo que permite un medio descentralizado de validar la distribución de la capacidad de almacenamiento y confirmar las solicitudes de pines de una manera confiable, al mismo tiempo que se actualiza la interfaz de usuario de nuestra cartera de clientes para admitir estas funciones sin Confiando en el ya no necesitado Phantom dApp.

Phoenix

La primera de las tres tareas que completamos fue el administrador de pines basado en IPFS que Craig, su desarrollador líder, llamó Phoenix. Eligió este nombre porque, según la mitología griega, el Fénix es un ave a la que se le atribuye una larga vida debido a su capacidad para regenerarse. Esto alude a la capacidad de nuestra red de almacenamiento de igual a igual a vivir, donde el Clúster de IPFS no podría. El nombre también es el de una constelación, un fenómeno que refleja la relación entre los nodos descentralizados que contribuyen a nuestra red. Las constelaciones no solo representan puntos aislados a los que se les otorga mayor importancia a través de su conexión entre sí, sino que, literalmente, son una red interplanetaria. Nuestro Phoenix es de larga duración y, a través de su uso del Sistema de archivos interplanetario como su protocolo de distribución de hipermedia de igual a igual,

Phoenix, en su versión como el software que necesita instalarse y ejecutarse para configurar un Phoenix Cluster, está compuesto de dos componentes clave: en primer lugar, Phoenix-core, una biblioteca personalizada de igual a igual que facilita la comparación. La capa de mensajería de Phoenix a Cluster y, en segundo lugar, un clúster de Phoenix, un módulo que integra el Cluster de Phoenix con el protocolo IPFS, creando una segunda capa sobre el Cluster de Phoenix llamada el enjambre de IPFS. El enjambre de IPFS es la red de dispositivos de almacenamiento de medios digitales en los que se ancla el contenido. Phoenix-cluster permite que los pares del Phoenix Cluster se conecten al enjambre y es responsable de la emisión de comandos de pin a los compañeros del enjambre de IPFS. En pocas palabras, el Phoenix Cluster funciona como el “portero” de la plataforma de Shift, Asegurarnos de que los dispositivos que forman parte del enjambre de IPFS cumplan con los requisitos previos que hemos establecido para el almacenamiento correcto de contenido. Esto garantiza que los usuarios de nuestra plataforma no tendrán que preocuparse por la pérdida de sus datos valiosos.

El trabajo que Craig ha completado en este campo es un gran logro en muchos niveles, entre otras cosas porque no se conocía cuando comenzó, si las soluciones teóricas que diseñamos juntos funcionarán en la práctica. Gracias a su dedicación, ahora ha terminado de trabajar en la primera versión de Phoenix, una de nuestras ofertas de tecnología clave, y, desde que hicimos la transición del sitio del proyecto al primer Cluster de Phoenix a principios de octubre, ha estado funcionando de manera saludable y sin problemas. desde entonces.

Integración de blockchain

El Proyecto Shift está construyendo una plataforma con la que los usuarios podrán usar la billetera Shift Nano para acceder a los recursos de almacenamiento de otros para descentralizar sus dispositivos de alojamiento de datos y web, así como otorgar espacio de disco a la red como proveedores de almacenamiento por parte de instalando Phoenix 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, el ecosistema requiere un sistema de verificación y un modelo financiero que sea capaz de monitorear y recompensar a los participantes por otorgar satisfactoriamente los servicios que lo sustentan. Es la presencia de este modelo lo que permite que la red funcione de manera saludable y sostenible, atendiendo a los intereses de los usuarios y proveedores de almacenamiento por igual. Aquí es donde entra en juego la integración de blockchain.

Es la capacidad de blockchain de narrar eventos de una manera descentralizada e inmutable, que utilizaremos durante el proceso de asignación de capacidad de almacenamiento en una red distribuida, así como la facilidad para proporcionar recompensas financieras de manera programática y verificable, que Se usa para recompensar a los proveedores de almacenamiento, lo que hace que blockchain sea tan fundamental para la tecnología de Shift. El primer paso en la integración de la cadena de bloques que se incluirá en nuestra próxima versión, es la capacidad de BLOQUEAR tokens como medio para reclamar una parte del grupo de espacio de almacenamiento disponible, así como la provisión de una función de PIN para asignar Contenta con el estado necesario para que sea resistente a la censura. Si bien no se incluye en nuestras próximas versiones, una vez que se adquiere el espacio de almacenamiento y se fija el contenido,

Para que un usuario almacene datos en nuestra plataforma, será necesario que primero adquieran tokens SHIFT para reclamar la cantidad de espacio de almacenamiento necesario para alojar esos datos. A continuación, SHIFT se puede bloquear con la billetera Shift Nano, y se paga una pequeña tarifa para fijar esos datos de forma permanente (o hasta que el titular de la cartera no los suelte). Estos dos tipos de transacciones también se pueden realizar de forma inversa, y sirven para deshacer las acciones anteriores. En pocas palabras, los cuatro tipos de transacciones que se debutarán en nuestro próximo lanzamiento son los siguientes:

  • Una transacción LOCK, que envía una cantidad designada de tokens SHIFT a una billetera virtual donde se almacenan como una forma de garantía, garantizando que la cantidad correspondiente de espacio de almacenamiento esté disponible para el titular de la billetera.
  • Una transacción UNLOCK, que devuelve los tokens debitados y libera espacio de almacenamiento de nuevo en el conjunto de datos del clúster de almacenamiento.
  • Una transacción de PIN, que crea un registro en la cadena principal que contiene el hash del activo y el tamaño del activo como entradas de datos que permiten que solo el titular de la billetera dicte la distribución de los datos en el clúster.
  • Una transacción UNPIN, que crea un registro en la cadena principal que el clúster lee como una cancelación de la transacción PIN relevante, y le indica que libere espacio de almacenamiento del usuario, permitiéndole otorgarlo a otros activos.

Rob ha estado trabajando incansablemente durante los últimos meses para llevar a cabo la tarea altamente técnica de integrar estas transacciones con nuestra cadena de bloques. La complejidad de esta codificación fue lo que desafortunadamente significó que no cumplimos con nuestra fecha límite del 30 de septiembre para el lanzamiento de la primera iteración de nuestra solución tecnológica para testnet. Sin embargo, tenemos la intención de utilizar el tiempo que nos queda disponible este año para probar exhaustivamente todas las funcionalidades de nuestra red privada, con un lanzamiento de red de prueba reprogramado de nuestra solución de almacenamiento web y almacenamiento descentralizado que se lanzará a fines de diciembre de 2018.

Nuestro modelo de precios

Si bien no pudimos cumplir con nuestro ambicioso objetivo de lanzamiento para el final del tercer trimestre, concluimos el trimestre poniendo los toques finales al modelo de precios dinámico y basado en fórmulas que nuestra plataforma utilizará para controlar la cantidad de tokens SHIFT necesarios para adquirir almacenamiento. espacio. Si bien proporcionamos a la comunidad una explicación muy detallada de cómo funcionará como parte de una actualización de desarrollo lanzada en octubre 8, ya que será integral en el funcionamiento de la plataforma Shift, la esencia de cómo funciona justifica algunas descripción.

El modelo de precios no se puede entender sin hacer referencia a los mecanismos de la transacción LOCK, la transacción a través de la cual el token SHIFT adquiere su función principal. Los tokens se deben bloquear utilizando 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 enjambre de IPFS. El espacio de disco solo estará disponible para el usuario de almacenamiento mientras sus tokens permanezcan bloqueados, y se requiere una transacción de DESBLOQUEO para liberar los tokens y devolver el espacio de disco al grupo disponible de la plataforma. La cantidad de tokens SHIFT que se deben bloquear para recibir cualquier número dado de bytes de capacidad del disco duro es el producto de la siguiente fórmula matemática:

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).

Este modelo de precios basado en fórmulas requerirá una gran cantidad de pruebas para garantizar que cumpla con las expectativas de los usuarios de almacenamiento y los proveedores de almacenamiento, pero en Shift actualmente creemos que los beneficios del modelo de precios basado en fórmulas tienen el potencial de contribuir a La rápida adopción de nuestros servicios y el 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 a una negociación compleja. plataforma.

Una vez que este sistema financiero se haya probado y desplegado 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 verificar 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 aquellas que pasen con éxito y de manera constante El proceso de verificación.

Q4 2018 – ¿Qué viene?

Y ahora llegamos al presente.

Durante la primera mitad del cuarto trimestre, hicimos importantes mejoras al código fuente de Phoenix necesarias para configurar el grupo de prueba estable que ahora alberga nuestro sitio web de proyecto. Durante la última semana, nosotros en el equipo central también hemos estado ocupados creando una ‘lista de tareas’ final de las tareas restantes para ver finalizado el componente de integración de blockchain. Una vez hecho esto, nuestro objetivo es lanzar la solución de almacenamiento web y almacenamiento descentralizado antes de la conclusión de este trimestre.

Desde la perspectiva de nuestro usuario, el lanzamiento vendrá en la forma de una billetera Shift Nano reconstruida, que tendrá una interfaz de usuario rediseñada, superando a la del Phantom dApp en términos de facilidad de uso y funciones disponibles, además del software de nodo Phoenix. solía participar en nuestra red como un proveedor de almacenamiento que se pone a disposición del público. Un script de instalación y un tutorial que explica Phoenix también se harán públicos, de modo que cualquier persona podrá configurar fácilmente su propio nodo y participar en nuestro entorno de prueba compartiendo la capacidad de almacenamiento. Los tokens de Testnet se distribuirán para que las partes interesadas puedan participar en las pruebas de nuestro producto, sin cargo alguno. Sin embargo, estaremos reservando grandes cantidades de fichas para socios especiales.

Para coincidir con el lanzamiento de la solución de almacenamiento, anunciaremos una asociación importante. Es probable que haya más asociaciones a raíz de esto, ya que aún no existe una solución de almacenamiento que sea capaz de entregar el rendimiento de la nuestra. El plan posterior al lanzamiento será el desarrollo de mecanismos de plataforma útiles, como la validación de blockchain en las recompensas de almacenamiento, y, en caso de que el lanzamiento resulte en la obtención de una inversión financiera adicional, la finalización de un detallado documento técnico que describa una nueva arquitectura La plataforma Shift es capaz de proporcionarnos un algoritmo de consenso y un núcleo de blockchain que se adapte mejor a las necesidades de un ecosistema Shift en rápida expansión.

Con esta visión prometedora en mente, nos gustaría finalizar este resumen con un gran agradecimiento a Rob y Craig por sus contribuciones a la realización de una tecnología tan innovadora. Han estado trabajando extremadamente duro durante el último año, aunque las cosas no han sido fáciles en términos del sentimiento predominante en el mercado. Quisiéramos enfatizar que han estado administrando múltiples roles para servir al Proyecto Shift, además de otros compromisos, con su pasión y no con una recompensa financiera inmediata llevándolos a través de este esfuerzo considerable. Ninguno de nosotros invertiría nuestro tiempo y otros recursos si no fuera por nuestra creencia continua de que lo que estamos trabajando puede convertirse en uno de los mayores logros en la escena de la criptomoneda, así como el movimiento más amplio para descentralizar la Web, y, en haciéndolo,

Sinceramente,

Ralf S. (Presidente / Desarrollador principal)

Werner Heisenberg (Vicepresidente / Gerente de Operaciones)

Para obtener más información, visite www.shiftproject.com

Leave a Reply

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