Dado un número de versión MAJOR.MINOR.PATCH, incremente la versión: MAYOR cuando realice cambios de API incompatibles, la versión MENOR cuando agregue funcionalidad de manera compatible con versiones anteriores y la versión PATCH cuando realice correcciones de errores compatibles con versiones anteriores.
Las versiones entre proyectos deben permanecer independientes.
Registro de Cambios
Las nuevas versiones deben incluir un CHANGELOG basado en Keep a Changelog.
Si un proyecto tiene dependencias con otros paquetes de símbolos, el CHANGELOG debe adjuntar la siguiente tabla por cada nueva versión que describa las dependencias:
Hito: nombre del hito del servidor de catapulta (número de versión)
Librería
Versión
Paquete
Nombre de Libreria
v0.17.3
Enlace al paquete
Herramienta
La mayoría de nuestros proyectos usan TravisCI como la herramienta de automatización de CI, pero puede usar Jenkins o cualquier otra herramienta que se adapte al proceso si se siente más cómodo con él.
Prueba de Juicio
Cada vez que hay una nueva confirmación, los scripts de compilación deberían:
Construcción de paquetes
Ejecución de ruebas unitarias
GitHub debería evitar fusionar los RP que no cumplan los requisitos mencionados anteriormente.
Desarrollo Alpha
Cada vez que hay un nuevo impulso para dominar, los scripts de compilación deben generar e implementar una nueva versión comprobable como 0.17.1-ALPHA-20200220T120318.
Tenga en cuenta que hay un sufijo de marca de tiempo ya que los administradores de paquetes pueden no permitir la implementación de la misma versión. Si el administrador de paquetes permite la implementación de SNAPSHOT, no es necesario utilizar una marca de tiempo en este caso.
La marca de tiempo es generada automáticamente por la herramienta de automatización de CI. No debería haber ningún proceso manual como escribir la versión 0.17.1-ALPHA-1 o 0.17.1-ALPHA-2.
Un cliente puede usar una dependencia alfa como “symbol-sdk”: “0.17.1-ALPHA-20200220T120318”.
Versión Completa
Cada vez que queremos lanzar, creamos un PR desde el maestro hasta la rama de lanzamiento. El PR incluirá la actualización CHANGELOG explicando las nuevas características.
Una vez que se aprueba PR, la herramienta de automatización de CI lo recogerá, compilará y luego realizará un lanzamiento.
El script de lanzamiento debe:
git etiqueta la versión que se lanzará (por ejemplo: v0.17.4)
Publicar la versión actual en el administrador de paquetes (por ejemplo, npm, docker hub – 0.17.4)
Actualizar la versión del paquete (por ejemplo: 0.17.5 usando el parche de la versión npm)
Agregar y confirmar cambios
Empujar confirmaciones en la rama maestra (por ejemplo: package.json tendrá el nuevo 0.17.5)
Empujar la etiqueta (v0.17.4)
Motivación
Proceso de lanzamiento estandarizado
La forma en que se realiza el proceso de lanzamiento se confirma y documenta en el archivo y las secuencias de comandos de travis. No se hace en una máquina de desarrollo. Cualquiera puede entenderlo y realizar un lanzamiento.
Circuito de retroalimentación más estricto
Los usuarios deben esperar una versión adecuada antes de comenzar a usar una nueva función en nuestros paquetes. Aunque el proceso es bastante dinámico, podrían pasar algunos días antes de obtener una versión que agregue muchas mejoras juntas.
La propuesta es agregar la versión y el token correctos en los scripts de la herramienta de automatización de CI para que cada vez que se fusione un RP con un maestro, una tubería empuje una nueva alfa / instantánea al administrador de paquetes. Si un usuario está esperando una solución, esa solución se incluirá en el administrador de paquetes automáticamente después de fusionar el nuevo maestro.
Lanzamientos más rápidos
Utilizando la instantánea, el equipo de Symbol puede realizar comprobaciones y comentarios adicionales antes de realizar un lanzamiento, probando con humo el artefacto de la instantánea en otros proyectos como la CLI, la billetera o el explorador. Incluso los ejemplos en los documentos se pueden actualizar antes de lanzar el paquete.
Implementación
El Symbol SDK para Typecript sigue el ciclo de lanzamiento definido en este documento usando TravisCI.
Nota: La implementación depende del marco y el lenguaje de programación, la implementación de TS es solo un ejemplo.
Travis tendrá los tokens necesarios y las claves de cifrado para realizar un lanzamiento utilizando variables env. Los más comunes son:
NPM_TOKEN: el token utilizado para insertar artefactos npm en un repositorio npm https://docs.npmjs.com/creating-and-viewing-authentication-tokens
GITHUB_TOKEN: el token utilizado para impulsar los aumentos de versión, etiquetas y documentación (páginas de GitHub) en GitHub. El usuario debe poder publicar desde la rama de lanzamiento a master una vez que se actualice la versión. https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line
RELEASE_BRANCH: el nombre de la rama de lanzamiento. Ejemplo: lanzamiento.
(Opcional): signatureKeyId, SignaturePassword, SignatureSecretKeyRingFile y la clave privada cifrada de Travis. Los valores necesarios para los paquetes de signos. https://medium.com/@nmauti/sign-and-publish-on-maven-central-a-project-with-the-new-maven-publish-gradle-plugin-22a72a4bfd4b
Necesitaríamos otros tokens para definir las implementaciones de Docker, Sonar o PIP.
Los tokens generados deben ser de usuarios con permisos suficientes (por ejemplo, un usuario que puede pasar a la rama de páginas de GitHub o npm).
Proyectos siguiendo el NIP
symbol-sdk-typescript-javascript OK
symbol-sdk-java OK
symbol-cli OK
symbol-openapi OK
symbol-openapi-generator OK
catbuffer-generators Pendiente
symbol-docs Pendiente
catapult-rest Pendiente
catapult-server Pendiente
Compatibilidad de Antecedentes
No hay problemas de incompatibilidad con precedentes. Los artefactos cargados son los mismos, recién implementados desde Travis en lugar de una máquina desarrolladora.
Contribuciones
Un agradecimiento especial a @dgarcia360 y @rg911 por contribuir activamente a este NIP.
LibreriaSymbol QR – https://github.com/nemfoundation/symbol-qr-library
$3,500
$1,500
$300
$50
Symbol HD Wallet – https://github.com/nemfoundation/symbol-hd-wallets
$2,500
$1,000
$300
$50
Symbol CLI – https://github.com/nemtech/symbol-cli
$3,000
$1,000
$300
$50
Symbol Desktop Wallet – https://github.com/nemfoundation/symbol-desktop-wallet
$10,000
$5,000
$2,000
$150
Recompensas
La siguiente es una descripción de alto nivel de cómo algunos ejemplos de tipos de vulnerabilidad / error pueden correlacionarse con los distintos ámbitos:
Critico
Generación de claves y persistencia
Uso clave y firma de transacciones
Problemas de nivel de protocolo que podrían corromper o romper el estado de la cadena de bloques dada una transacción firmada válida
Alto
Baches o defectos para los componentes de software que permitirían al atacante obtener acceso a la computadora / host en el que se ejecuta el software
Obtener acceso a información segura de clave / contraseña / etc. desde fuera de la aplicación o servicio desde la máquina host
Medio
Problemas de entrada errantes que incluyen datos corruptos / incorrectos pero que pueden enviar una transacción válida. Algo así como una entrada no válida que transferiría 10 veces los fondos mientras el usuario cree que están transfiriendo 1x
Bajo
Estos serían principalmente problemas de nivel de experiencia del usuario que hacen que un usuario final esté atascado o que las aplicaciones sean inútiles. Por lo general, esto podría ser algo así como un usuario que se envía a un formulario que se rompe y el usuario queda bloqueado en un determinado flujo de trabajo hasta que finaliza o cierra una aplicación
Politica
El proyecto Symbol espera trabajar con la comunidad de seguridad para encontrar vulnerabilidades con el fin de promover el desarrollo tecnológico de nuestros proyectos y mantener segura a nuestra comunidad de usuarios activos.
Objetivos de respuesta
Haremos todo lo posible para cumplir con los siguientes SLA para los piratas informáticos que participan en nuestro programa:
Tipo de Respuesta
SLA en Días Hábiles
Primera Respuesta
2 Días
Tiempo de Espera
5 Días
Tiempo para recibir la Recompensa
10 Días
Tiempo de Solución
Depende de la severidad y la complejidad
Lo mantendremos informado sobre nuestro progreso a lo largo del proceso y nos comunicaremos si algún ingeniero necesita más detalles o tiene problemas con la reproducción de las divulgaciones.
Política de Divulgación
Como se trata de un programa privado, no discuta este programa ni ninguna vulnerabilidad (incluso las resueltas) fuera del programa sin el consentimiento expreso de la organización.
Proporcione informes detallados con pasos reproducibles. Si el informe no es lo suficientemente detallado como para reproducir el problema, el problema no será elegible para una recompensa.
Envíe una vulnerabilidad por informe, a menos que necesite encadenar vulnerabilidades para proporcionar impacto.
Cuando se producen duplicados, solo otorgamos el primer informe que se recibió (siempre que pueda reproducirse por completo).
Múltiples vulnerabilidades causadas por un problema subyacente recibirán una recompensa.
La ingeniería social (por ejemplo, phishing, vishing, smishing) está prohibida.
Haga un esfuerzo de buena fe para evitar violaciones de privacidad, destrucción de datos e interrupción o degradación de nuestro servicio. Solo interactúe con cuentas de su propiedad o con permiso explícito del titular de la cuenta.
Plan de Prueba
Actualmente estamos implementando los elementos de ámbito que son bibliotecas independientes, su uso en perspectiva y las pruebas están autocontenidas en sus repositorios de github.
A medida que abramos la amplia gama de elementos de alcance, proporcionaremos cualquier plan de prueba específico.
Vulnerabilidades fuera de alcance
Al informar vulnerabilidades, considere (1) escenario de ataque / explotabilidad, y (2) impacto de seguridad del error. Los siguientes problemas se consideran fuera de alcance:
Clickjacking en páginas sin acciones sensibles
Falsificación de solicitudes entre sitios (CSRF) en formularios no autenticados o formularios sin acciones sensibles
Ataques que requieren MITM o acceso físico al dispositivo de un usuario.
Bibliotecas vulnerables previamente conocidas sin una prueba de concepto que funcione.
Inyección de valores separados por comas (CSV) sin demostrar una vulnerabilidad.
Faltan las mejores prácticas en la configuración SSL / TLS.
Cualquier actividad que pueda conducir a la interrupción de nuestro servicio (DoS).
Problemas de suplantación de contenido e inyección de texto sin mostrar un vector de ataque / sin poder modificar HTML / CSS
Problemas de limitación de velocidad o fuerza bruta en puntos finales sin autenticación
Faltan las mejores prácticas en la Política de seguridad de contenido.
Faltan banderas HttpOnly o Secure en las cookies
Prácticas recomendadas de correo electrónico faltantes (registros SPF / DKIM / DMARC no válidos, incompletos o faltantes, etc.)
Vulnerabilidades que solo afectan a los usuarios de navegadores desactualizados o sin parches [Menos de 2 versiones estables detrás de la última versión estable lanzada]
Divulgación de la versión de software / Problemas de identificación de banner / Mensajes de error descriptivos o encabezados (por ejemplo, seguimientos de pila, errores de aplicación o servidor).
Las vulnerabilidades públicas de día cero que hayan tenido un parche oficial durante menos de 1 mes se otorgarán caso por caso.
Tabnabbing
Redireccionamiento abierto: a menos que se pueda demostrar un impacto de seguridad adicional
Problemas que requieren una interacción poco probable del usuario
Puerto seguro
Cualquier actividad realizada de manera consistente con esta política se considerará una conducta autorizada y no iniciaremos acciones legales contra usted. Si un tercero inicia una acción legal contra usted en relación con las actividades realizadas en virtud de esta política, tomaremos medidas para informarle que sus acciones se realizaron de conformidad con esta política.
¡Gracias por ayudar a mantener seguros nuestro proyecto y comunidad de usuarios!
Bueno, el tiempo vuela y estamos casi un mes más tarde de lo esperado en esta actualización. A pesar de estar cerca de la zona cero para el Coronavirus, solo hemos experimentado una interrupción menor. Perdimos un mes de tiempo. Los últimos meses se han dedicado a ampliar nuestra producción y sistemas, así como a crear instalaciones más grandes y extendidas. Durante este tiempo, también completé el Startup Leadership Program, donde aprendí muchísimo sobre ser una empresa en etapa inicial y obtuve algunas conexiones valiosas y credibilidad.
Desarrollo de clientes
Piloto público
Creamos una convocatoria abierta para que los voluntarios se unan a nuestro piloto público y más de 20 familias se inscribieron solo de los recursos compartidos de WeChat. Hemos comenzado a instalar en estas casas. Tener estos usuarios nos permitirá probar nuestros incentivos de comportamiento en el mundo real, y aquí es donde probaremos nuestros derechos de consumo de energía tokenizados. Es crucial y estamos entusiasmados de finalmente poder seguir adelante.
Piloto de negocios Hace aproximadamente un mes, realizamos nuestra instalación inicial en nuestra primera ubicación comercial. Es un espacio de coworking en Shanghai. Hemos identificado ahorros potenciales en la factura de energía de más del 50%, y esto es sin realizar cambios importantes. Solo algunos empujones de comportamiento y un poco de automatización. Estamos trabajando en algunos dispositivos de automatización ahora para satisfacer esta necesidad.
Piloto Académico El piloto de la universidad está en espera por ahora. La universidad ha cambiado a la educación a distancia debido al virus. Las lecciones que estamos aprendiendo en el espacio de coworking y las actualizaciones del sistema que hemos experimentado para que funcione allí serán directamente transferibles a la universidad, por lo que comenzaremos a funcionar allí cuando se vuelva a abrir.
Desarrollo Tecnológico
Hardware
Justo después de la última actualización, creamos una segunda versión de nuestro medidor inteligente. Este es mucho más preciso que el original (más del 99% de precisión) y, lo que es más importante, lo hemos modificado para que pueda construirse ensamblando solo componentes de terceros. Esto significa que podemos pasar de pedir piezas a instalar 200 metros en aproximadamente dos semanas planas. Me encanta estar en China. Inicialmente, actualizamos la versión 1 para incluir el convertidor digital más sensible. Hoy recibimos la primera entrega de v2s nuevos.
Una vez que se reciben los dispositivos, se someten a pruebas rigurosas para detectar dispositivos defectuosos antes de que se pierdan en una instalación. Aquí está la prueba después de actualizar las placas gen1.
Un día cuando estaba fuera, los gemelos se unieron a las pruebas.
A partir de la semana pasada, habíamos instalado unos 50 dispositivos en dos negocios y seis hogares. Cada vez nos organizamos más y mejoramos la calidad y flexibilidad de nuestras instalaciones. Esto se está preparando para ir e instalar en el espacio de coworking.
Software Del mismo modo con el software, hemos implementado pruebas más rigurosas para detectar cambios importantes antes de implementarlos en el campo. El firmware para los dispositivos fue “terminado” recientemente. Ahora es lo suficientemente estable y probablemente ya no lo molestemos más en esta etapa de nuestro desarrollo. El enfoque completo ahora está en la aplicación y los incentivos. Tenemos un nuevo concepto de aplicación en el que estamos trabajando. Hemos reutilizado gran parte de nuestro backend original, pero le daremos a la interfaz un cambio de imagen completo. Compartiré más sobre esto después de que se haya verificado con las pruebas de usuario. También hemos llevado a cabo experimentos iniciales de aprendizaje automático sobre nuestros datos para validar nuestras hipótesis sobre cómo se llevaría a cabo y funcionaron bien. Esperamos ahora más datos y tener una plataforma disponible para probar directamente si es útil o no antes de asignarle más recursos.
Eso es todo por ahora. Le agradezco su lectura hasta el final y su continuo apoyo. Como de costumbre, si estás en China, especialmente en Shanghái, y quieres tener un medidor y unirte al piloto, envíame un DM. Hasta la próxima actualización!
El Comité Directivo de Migración ha llevado a cabo el proceso de creación de una nueva marca para Catapult. La nueva marca “Symbol from NEM” ha sido apoyada por la comunidad junto con el ticker XYM.
El objetivo de este NIP es coordinar los esfuerzos para cambiar el nombre de todos los repositorios bajo la organización nemtech en GitHub.
Especificaciones
Paquetes
Los nombres de los repositorios, URL y nombres de paquetes instalables se editarán de la siguiente manera:
Anterior
Nuevo
nem2-*
symbol-*
catapult-*
symbol-*
Catapult
Symbol
En este momento, no hay planes para eliminar las referencias internas de catapult de catapult-server ni el código de catapult-rest.
Todos los paquetes relacionados con nem2- * se eliminarán de npmjs y maven para evitar que los usuarios instalen y la versión anterior del paquete por error.
Organización
Todos los repositorios dentro de la organización nemtech serán transferidos a la nueva organización de plataforma de símbolos.
La organización nemtech GitHub mantendrá un enlace en la descripción de la nueva entidad.
Páginas Github
La organización nemtech conservará el repositorio nemtech.github.io para redirigir los enlaces relacionados con las páginas de GitHub (por ejemplo, nem2-docs, referencias SDK, nem2-openapi) a la nueva URL de la organización https: // desarrollador. . .
Ticker
Las referencias codificadas a nem.xem deben reemplazarse por symbol.xym. Para la moneda de red predeterminada de las redes privadas, se seguirá utilizando cat.currency.
Cl
Es posible que algunos servicios externos deban ser reconfigurados manualmente por repositorio, incluidos:
TravisCI
Overoles
Cada organizador de firmas debe dar prioridad a agregar nuevamente los servicios requeridos para fusionar nuevos RP en el maestro (por ejemplo, probar tuberías) antes de agregar nuevas características a cada proyecto.
Re Diseño
Si es necesario, adapte los colores, las fuentes y el logotipo de acuerdo con la última actualización de la marca.
Se recomienda que cada repositorio cree una rama separada para comenzar a aplicar el rediseño sin interferir con otras características entrantes.
Decisiones de Diseño
La especificación propuesta intenta minimizar los errores 404 al acceder a enlaces antiguos.
Los enlaces de los repositorios movidos a la nueva organización se redirigen automáticamente a la nueva ubicación (excepto las páginas de GitHub). El tiempo en que las redirecciones están activas puede cambiar, ya que es administrado por GitHub.
Para resolver la redirección de páginas de GitHub, mantendremos el nemtech.github.io dentro de la organización nemtech y desarrollaremos un script .js personalizado para redirigir a cada nueva URL en consecuencia.
Implementación
Para cada proyecto, se creará un nuevo problema llamado “Rebranding” con la siguiente lista de tareas:
[] Se creó una rama de cambio de marca
[] Nuevo diseño aplicado (fuente, logotipos, colores)
nemstudios/catbuffer-generator (migrated to npm nemtech org)
nem2-sdk-java
Hito 2
Repositorios de destino:
nem2-docs
nem2-cli
nemfoundation/symbol-desktop-wallet-beta
nemfoundation/nem2-explorer
Hito 3
Repositorios de Destino:
catapult-service-bootstrap
catapult-whitepaper
nem2-e2e-tests
nem2-scenarios
nemfoundation/nem2-uri-scheme
nemfoundation/nem2-hd-wallets
nemfoundation/nem2-qrlibrary
Hito 4
Repositorios de Destino:
catapult-server
catapult-rest
catbuffer
Hito 5 (en discusión)
symbolplatform GitHub org creado
desarrolladores principales asignados como propietarios de la organización
dominio redirigido a la organización
script para redirigir enlaces nemtech.github.io
repositorios migrados
Servicios de CI migrados
Compatibilidad al revés
No será posible migrar todos los enlaces.
Podría penalizar el SEO del proyecto.
Sin embargo, es preferible a largo plazo tener una marca consistente, y aplicar esos cambios más temprano que tarde causará menos redirecciones en el futuro.
Alternativas
Se están considerando otras alternativas:
Mantenga todos los repositorios en nemtech (sin renombrar la organización) para evitar redirecciones.
La razón de tener una organización GitHub para NIS1 (NEMProject) y otra para Catapult (nemtech) era tener una forma clara de separar los repositorios por tecnología para evitar confusiones. Si no, cada repositorio de Catapult estaría bajo el Proyecto NEM. Sin embargo, los nombres elegidos no son lo suficientemente descriptivos como para diferenciar el contenido de ambas organizaciones.
Cambie el nombre de la organización nemtech a la plataforma de símbolos y cree una nueva organización llamada nemtech para manejar las redirecciones
Existe el riesgo de perder el nombre nemtech para siempre, ya que estará disponible para que todos puedan registrarse.
No renombrar catapult-server y catapult-rest a symbol-server y symbol-rest.
Si estás leyendo esto, eres parte de nuestra tribu en NEM. Tu participación ha ayudado a definir la cultura de esta comunidad y cómo se ve el futuro para la plataforma NEM. En nombre de la Fundación NEM, queremos agradecerles. Al apoyar la adopción y el desarrollo del proyecto blockchain de NEM, usted está capacitando a las personas en todo el mundo para que tengan un mejor futuro.
La Blockchain de Symbol (anteriormente Catapult) es un logro tecnológico increíble, creado casi en su totalidad por los desarrolladores principales. Pero incluso la mejor tecnología del mundo puede fallar si carece de herramientas y conexiones con las empresas que la necesitan. La industria blockchain es competitiva y Symbol debe estar bien equipado para luchar por la cuota de mercado. A medida que nuestro equipo de liderazgo asumió el cargo en 2019, teníamos una visión clara de impulsar el lanzamiento y la comercialización de Symbol. A principios de año, asignamos nuestros programas, presupuestos y personas a las necesidades de los desarrolladores empresariales, empresas, estudiantes y usuarios finales que serán fundamentales para el éxito de Symbol.
Para nosotros, los desafíos fueron sustanciales a veces, incluida la presión financiera durante un mercado bajista volátil. Cumplimos nuestra promesa de publicar la hoja de ruta de la Fundación NEM basada en nuestra mejor información en el momento de lo que anticipamos que sería necesario para el éxito futuro. Los horarios del software son fluidos y nos perdimos algunas fechas. Además, las pruebas de Symbol (que contratamos a través de un tercero) nos proporcionaron a nosotros y a los desarrolladores centrales información útil para determinar el camino que tenemos por delante para el lanzamiento.
A pesar de las fechas perdidas y los resultados de las pruebas en curso, nuestros esfuerzos tuvieron un gran impacto. Hicimos progresos importantes en casi todas las áreas, y en muchas otras, no en la hoja de ruta, como las decisiones de migración, la transparencia, la gobernanza, la navegación de los cambios globales a las regulaciones y el cumplimiento y también contratando profesionales de software experimentados y expertos en la materia.
Aquí está el informe de ROI de 2019 para dar contexto a nuestras actividades el año pasado. Primero cubriremos los gastos, luego los resultados.
Presupuesto de la Fundación NEM 2019
A principios de 2019, la Fundación NEM obtuvo una solicitud de presupuesto total de $ USD 8 millones. Para el año calendario de enero de 2019 a diciembre de 2019, el gasto real total del presupuesto fue de $ 6.7 millones, que se describe en el resumen a continuación.
Aspectos destacados del gasto real del presupuesto de 2019:
El desarrollo de tecnología representó el 43% del presupuesto total, con un fuerte énfasis en contratar a los mejores talentos de ingeniería, crear herramientas que incluyan billeteras, SDK y exploradores, trabajar con proveedores y desarrollar la capacidad para que la plataforma de NEM crezca en 2020. Esto es en línea con nuestro mandato de enfocar el gasto en tecnología. (Enlace – Actualizaciones históricas de tecnología).
El Desarrollo Comercial y Marketing consisten en el 15% y el 12% del presupuesto respectivamente, con la mayoría del gasto sesgada hacia fines de 2019 mientras nos preparamos para el lanzamiento de Symbol. La financiación se gastó en la contratación de la agencia de relaciones públicas líder en la industria Wachsman y Better Way Agency, que apoyó el diseño de la marca y los materiales de apoyo para Symbol. También mantuvimos un flujo constante de compromisos de eventos y construimos nuestra base de asociación para prepararnos para el lanzamiento. Puedes ver nuestra actualización de actividad mensual aquí.
Operaciones, Legal, RRHH y Finanzas, respectivamente, representan el 9% y el 4% del presupuesto total, lo que fue proporcional a nuestro pronóstico a principios de 2019. El gasto se invirtió en las herramientas del equipo para tener éxito. Esto incluía suscripciones de software como herramientas de correo electrónico y videoconferencia, plataformas de atención al cliente, herramientas de gestión de proyectos y más.
Del costo total, el gasto de personal fue el más alto con un 61%, amplificado por la reestructuración y la indemnización por despido del primer trimestre de 2019 ~ $ 250K. La mayor parte del presupuesto se había destinado a los gastos relacionados con las personas. Hacia fines de 2019, también contratamos a nuestro CTO y otros líderes clave de C-suite, lo que se sumó a los costos (esperados), un excelente uso de los fondos. En el resumen de gastos, se han gastado fondos en NEM Medio Oriente y África del Norte (MENA), NEM Asia y NEM Europa en un total del 8% del presupuesto. Esto representa los fondos utilizados para los despidos durante la reestructuración de 2019, así como el pago de todos los pasivos pendientes en 2018. Es lamentable que esos costos inesperados hayan impactado nuestro presupuesto, pero nos aseguramos de que todos los pagos se realizaron para asegurarnos de que nos comportamos por encima de la mesa.
Trajimos a un sólido equipo de desarrollo de tecnología, ofrecimos recompensas por la corrección de errores y utilizamos contratistas y proveedores para obtener asistencia. Los proveedores que nos apoyaron incluyeron el desarrollo de la billetera móvil, la estrategia de mercado de Japón y las traducciones, incluido el trabajo de integración de billetera de hardware. También distribuimos fondos para apoyar a NEM Studios, que están trabajando en el desarrollo del backend y el soporte de Catapult Go-To-Market y que posteriormente formaron el Comité Directivo de Catapult.
Resultados del Desarrollo Tecnológico en 2019
La principal prioridad de la Fundación en 2019 fue apoyar el lanzamiento de Symbol.
Renovamos completamente el Equipo Técnico y, en unos pocos meses, contratamos talentos de ingeniería y un conjunto de proyectos estaba en pleno movimiento. Algunos aspectos destacados de la tecnología tangible:
Nuevas billeteras Symbol (de escritorio y móviles) listas para el lanzamiento de la cadena pública
Explorador de blockchain de Symbol
SDK
Symbol Academy, un portal integral de aprendizaje en línea para capacitar a los desarrolladores. Esto se implementará en nuestros integradores de sistemas y socios en paralelo con el lanzamiento.
Testnets de Symbol
Gran parte de este progreso fue impulsado por nuestro recién contratado Director de Tecnología, Nate D’Amico. Nate es un desarrollador veterano con experiencia en gestión de productos en empresas de software de nivel empresarial, incluidos SugarCRM y proyectos de código abierto como Apache Bigtop.
Greg Saive fue otro jugador estrella en el equipo de tecnología de la Fundación, que trabajó junto con los desarrolladores principales para garantizar que la tecnología front-end sea perfecta con el protocolo.
Aspectos destacados de soporte tecnológico adicional:
Cada proyecto de tecnología ha tenido un administrador de proyectos de software con experiencia para responsabilizar al equipo de los resultados a diario.
Los líderes de la Fundación unieron esfuerzos con NEM Ventures y NEM Studios en el Comité de Migración en 2019. Este comité resolvió las decisiones difíciles sobre la migración de tokens y datos, los plazos, la economía de los tokens y otros temas polémicos. Estas decisiones tuvieron que ser examinadas a fondo con la comunidad, los inversores, los desarrolladores, los miembros del equipo central, los expertos legales / fiscales, los socios y otros en el ecosistema.
Resultados: 2019 Operaciones, Legal y RRHH
Desarrollamos un “Equipo de transformación” para implementar estándares, procesos y políticas en la nueva estructura. Logramos mostrar a la industria una representación más profesional y organizada de NEM.
Establecimos una oficina de Secretaría con personal designado para proporcionar comunicaciones regulares en los foros de NEM.
Agilizamos los costos, como el arrendamiento y los costos operativos del NEM Blockchain Center (NBC). Se llegó a un acuerdo para que un tercero se haga cargo del pago del arrendamiento a largo plazo y administre NBC como un lugar de evento y espacio de trabajo conjunto.
Al pasar de una estructura regional a una estructura global, pasamos a un marco con más responsabilidad mediante la creación de un Fideicomiso. La confianza es un capa adicional de responsabilidad por los fondos. La Fundación proporciona informes trimestrales antes de desembolsar los fondos.
Cambiamos la forma de la organización para trabajar en un entorno de “fuerza laboral distribuida”. Nuestros equipos están dispersos por todo el mundo en unos 20 países. Al usar un enfoque de software compartido, los miembros del equipo pueden trabajar juntos para acceder a todos los recursos de la Fundación sin la administración y el gasto de las oficinas físicas.
La reestructuración del primer trimestre de 2019 resultó en muchos despidos. Contratamos a un proveedor de servicios de recursos humanos para asegurarnos de que las terminaciones se manejaran con la indemnización adecuada y los requisitos legales y pagamos las deudas pendientes del año anterior.
Otra contratación de operaciones importante fue Adele Rom como Asesora de Organización Estratégica y Liderazgo. Los 20 años de experiencia de Adele en gestión de talento y operaciones incluyen puestos como Vicepresidente de Recursos Humanos para JP Morgan Chase & Co y Jefe de Talento para Riot Games.
Contratamos a PwC, una de las cuatro grandes firmas contables, para respaldar nuestros precios de transferencia y asuntos financieros.
Aportamos un sólido conocimiento financiero sobre banca, cumplimiento e intercambios globales mediante la contratación de un equipo financiero experimentado.
Implementamos una nueva firma de auditoría externa y creamos un fideicomiso para la Fundación. Esto condujo a una mayor transparencia y gestión de fondos y mantuvo las operaciones responsables con un alto nivel.
Consolidamos y racionalizamos las finanzas de varias entidades NEM en Europa, Sudeste de Asia y Asia Pacífico. Hemos combinado cuentas bancarias clave y esperamos mayores ahorros en servicios financieros en el futuro cercano.
En la Asamblea General Anual y la Asamblea General Extraordinaria, nos comprometimos a tener informes financieros auditados por terceros para las entidades filiales de Singapur y Malasia, que desde entonces han aumentado la transparencia financiera.
También contratamos a Lei Dong como nuestro Director Financiero. Lei aportó sólidos conocimientos financieros sobre banca, cumplimiento e intercambios globales gracias a su experiencia en Huobi.
Resultados: 2019 Marketing y desarrollo de negocios
Firmamos un acuerdo para el soporte de Catapult Go-To-Market con David Shaw y NEM Studios. Posteriormente formamos el Comité Directivo de la Marca Catapult. Trabajamos estrechamente con estos equipos para crear y administrar el proceso de aprobación para una revisión completa de la marca. También firmamos un MOU por ~ $ 750,000 con NEM Studios con fondos para cumplir con la estrategia Go-To-Market, así como el desarrollo de back-end.
Trajimos expertos en marketing y relaciones públicas, incluida la agencia de relaciones públicas Wachsman, y la agencia Better Way para apoyar nuestros esfuerzos de marca.
Este trabajo condujo a votos exitosos de la comunidad sobre la marca y el ticker. También centró nuestros esfuerzos en casos de uso específicos de la industria, como atención médica, finanzas, seguros, juegos y más.
Comenzamos la creación del sitio web de Symbol y los materiales de marketing para ser la cara del producto.
Incrementamos sustancialmente la defensa de los esfuerzos regulatorios para las criptomonedas y blockchain, incluida la Cumbre V20 en Japón.
Trabajamos con gobiernos e instituciones financieras, incluido el Banco de Lituania, en casos de uso.
Trabajamos junto a universidades de todo el mundo para contribuir al plan de estudios de miles de estudiantes y estudios en todo el mundo en la construcción de Symbol Academy y el Centro de Recursos para Desarrolladores.
Creamos un grupo de trabajo de FinTech que trabajó en investigación, asociaciones y planificación para los casos de uso de la industria financiera de Symbol. Esta investigación ayudó a impulsar la optimización de Symbol para la industria del comercio de valores.
A finales de 2019, invertimos en el establecimiento de un equipo de Japón, que está trabajando en una serie de proyectos y asociaciones para 2020.
Comenzamos la creación del portal educativo de Symbol Academy que incluye videos, tutoriales y casos de uso centrados en el ecosistema de NEM.
También puede encontrar más detalles sobre el desarrollo empresarial en nuestra actualización mensual de la Fundación NEM para 2019.
Resumen
Tuvimos muchos logros sobresalientes este año, y sin los esfuerzos de la Fundación, el ecosistema de herramientas, recursos para desarrolladores y soporte de Symbol seguramente estaría muy por detrás de lo que es hoy.
Hicimos un progreso sorprendente comenzando con un equipo completamente nuevo y construyendo una organización bien administrada con expertos en tecnología y expertos en la materia a cargo. Nos centramos en cómo Symbol satisfará las necesidades de industrias específicas y pusimos en marcha proyectos que darán impulso al mercado de Symbol en el momento crítico después del lanzamiento público. Hicimos todo esto por debajo del presupuesto.
A veces nos topamos con retrasos en los proyectos y comunicaciones. En áreas como el Comité de Migración, la hoja de ruta, los retrasos en la fecha de lanzamiento y los plazos de financiación, nos sentimos responsables de avanzar las decisiones, pero no teníamos la autoridad final sobre los tomadores de decisiones o el proceso de toma de decisiones de código abierto para poner fin a los retrasos. Este fue un punto de dolor importante que deberá resolverse a medida que evolucione la gobernanza del ecosistema. Muchas decisiones tuvieron muchas rondas de investigación con muchas partes detrás de escena, mientras que la Fundación recibió la mayor parte de las críticas. Aún así, la comunidad busca liderazgo en la Fundación, y creemos que los líderes efectivos superarán este tipo de desafíos. Finalmente los superamos, pero nos estamos desafiando a nosotros mismos para mejorar nuestra efectividad en el futuro y trabajar con el equipo central, NEM Ventures, NEM Studios y el Consejo en soluciones futuras.
Avanzamos hacia el lanzamiento público de 2020 con renovada energía y confianza, y Symbol está bien posicionado para enfrentar los desafíos futuros. La industria del libro mayor distribuido de código abierto todavía es muy nueva, y las organizaciones como la nuestra deben adaptarse continuamente para adaptarse a los mercados cambiantes y los paisajes competitivos. El cambio es la única garantía.
Pero nosotros, en la Fundación, siempre nos hemos mantenido fieles a la visión original de NEM: una cadena de bloques justa, abierta y de alto rendimiento de nivel empresarial será una rampa para el futuro digital. Con esa visión, el camino de Symbol para convertirse en un líder de la industria es más claro que nunca. Hay tiempos muy emocionantes por delante.
Gracias comunidad.
Alexandra Tinsman, presidente
Anton Bosenko, miembro del consejo
Adele Rom, asesor
David Shaw, asesor
Dona Rinon, miembro del consejo
Greg Evias, miembro interino del consejo
Jason Lee, vicepresidente
Jeff McDonald, miembro del consejo
Laura Takenaka, miembro del Consejo
Lei Dong, Oficial Principal de Finanzas
Nate D’Amico, Director de Tecnología
Niko Maenpaa, Miembro del Consejo Interino
Pedro Guiterrez, Miembro del Consejo y Jefe de Alianzas
El proceso de configuración actual de una cadena de bloques Symbol deja mucho que desear. Para configurar una instancia de Symbol, existe la opción de usar una de las muchas imágenes Docker preconfiguradas, que no funciona en todos los sistemas (dispositivos basados en ARM, sistemas más antiguos), o configurar completamente desde cero.
Una instancia de Symbol (par) requiere una serie de pasos que deben seguirse antes de que pueda funcionar y lanzarse:
Las dependencias de símbolos deben descargarse, compilarse e instalarse. Este proceso puede llevar bastante tiempo.
Un total de 19 archivos de configuración deben configurarse correctamente para una nueva instancia de cadena. Para unirse a una cadena existente, la configuración adecuada para esa cadena (por ejemplo, una red de prueba) debe descargarse y colocarse en la ruta correcta.
Dependiendo de los objetivos del usuario, es posible que desee configurar aún más la configuración de su nodo en config-node.properties , por ejemplo, una configuración de nodo filantrópico.
Cargue los archivos de config-extension configurados correctamente según el rol del nodo: DUAL, API o PEER.
Para los desarrolladores, cambiar y probar diferentes configuraciones de red a menudo es parte del flujo de trabajo diario.
Actualmente no existe una herramienta simplificada y fácil de instalar para lograr lo anterior. Se intentó con cat-config-scripts, , pero no ofrece un alto nivel de funcionalidad o portabilidad.
Este NIP resuelve este problema al ofrecer una utilidad CLI que simplifica lo anterior en una herramienta fácil de usar.
Priorización de funciones / Funciones futuras
Ciertas características tendrán más prioridad que otras.
Los problemas más notables a partir de este NIP son con la configuración de un nodo, el cambio de roles de nodo y la carga de otras configuraciones de red. Estas características deben considerarse prioritarias en este NIP. Este repositorio muestra algunas de estas funcionalidades.
Otras características, como la compilación / instalación portátil de Symbol y sus dependencias, y la generación de nuevas plantillas de red son más complejas y vendrán más adelante. Sin embargo, serán considerados para el futuro de la CLI y si otros contribuyentes se involucran.
Las ideas de características futuras son bienvenidas en los comentarios de este NIP.
Especifaciones
Archivo de configuración adicional
Para una configuración más avanzada, se puede pasar un scu-config.json opcional a la CLI como argumento. Este archivo contendría valores relacionados con el usuario:
Arrancar clave privada
Llave de Cosecha
Nombre del nodo
Tarifa máxima de nodo
Un conjunto de rutas que conducen a diferentes plantillas de red (plantillas registradas).
una ruta “activa”, que apunta a la configuración de red actual que el usuario está utilizando (selectedTemplate).
El usuario tendría la opción de editar este archivo por sí mismo o cambiar los valores a través de la CLI.
Esquema de diseño de comando
El siguiente es un árbol de comandos propuesto para la CLI. Cada comando debe contener un comando principal, junto con los parámetros necesarios.
Tabla de comandos
SubComando
Args
Descripción
install
<path-to-new-config>
Instala Symbol y sus dependencias.
start
ninguno
Inicia una instancia de Symbol con la plantilla de red seleccionada. Esto probablemente dependerá de que los archivos binarios de Symbol estén en la RUTA del usuario.
add
ninguno
Agrega una nueva plantilla de red.
select
<template-name>
Selecciona una plantilla de red guardada.
reset
ninguno
Restablece el nodo seleccionado.
changerole
<dual / peer / api>
Cambia el rol del nodo de la plantilla de red seleccionada.
configure
<config-parameter>
Cambia el parámetro específico del nodo en la plantilla de red seleccionada (por ejemplo, bootPrivateKey).
Ejemplo
$ scu-cli –ayuda Bienvenido a la utilidad de configuración de símbolos
USO: scu-cli
Subcomandos:
install *: instala Symbol y sus dependencias.
inicio: inicia una instancia de Symbol con la plantilla de red seleccionada. Esto probablemente dependerá de que los archivos binarios de Symbol estén en la RUTA del usuario.
add : agrega una nueva plantilla de red.
select : selecciona una plantilla de red guardada.
reset: restablece el nodo seleccionado.
changerole : cambia la función de nodo de la plantilla de red seleccionada.
configure: cambia el parámetro específico del nodo en la plantilla de red seleccionada (por ejemplo, bootPrivateKey).
Lo más probable es que no se implemente en las primeras versiones de la CLI.
Especificación de plantilla de red
La noción de “plantillas” de red existe dentro de cat-config-scripts.. Un usuario debe poder descargar los recursos y los némesis de una red específica como una “plantilla”, y especificar la ruta a esta plantilla en el archivo de configuración o mediante la CLI. Una plantilla debe seguir la siguiente estructura de archivos:
example-network-template/
.
├── seed
├── data
└── resources
Donde data / contiene el directorio activo para que el nodo almacene nueva información de la cadena, seed / contiene datos de némesis originales en el caso de un restablecimiento de nodo, y los recursos contienen archivos específicos de la red. Los usuarios podrán descargar configuraciones de red en este formato y cargarlas a través de la CLI.
Estos archivos son necesarios para iniciar y unirse a una instancia de Symbol.
Instale el Metodo
Como la CLI utilizará Typecript / NodeJS, se publicará como un paquete NPM y, por lo tanto, la instalación es la misma que la de cualquier módulo global NPM: npm i -g scu-cli.
Motivación
Este NIP tiene la intención de ayudar con la prueba y el desarrollo de Symbol. Al proporcionar una herramienta estándar que permite a los desarrolladores cambiar fácilmente las configuraciones, instalar dependencias y proporcionar una mejor experiencia de configuración y desarrollo de símbolos.
Decisiones de Diseño
La forma de una aplicación CLI multiplataforma tiene más sentido para la configuración de la cadena. Las aplicaciones GUI no siempre se pueden usar en la configuración del servidor remoto, y los scripts bash pueden ser engorrosos.
La utilidad de configuración de símbolos se escribirá en mecanografiado y usará el patrón de diseño de comandos. Este patrón se adapta muy bien a las aplicaciones de estilo CLI, ya que permite que la lógica de comando se encapsule para su uso posterior dependiendo del estado del programa.
Se publicará como un módulo NPM para ser instalado globalmente en la máquina del usuario. Esto permitirá una fácil instalación.
Es posible que esta implementación se pueda integrar en nem2-cli – ver Alternativas
Implementación
N / A en el momento del borrador inicial. Una vez que se recopilen más comentarios y aportes de la comunidad, se alojará un repositorio de Github con el código. Es posible que esta funcionalidad se agregue a nem2-cli.
Inconvenientes
Puede causar redundancia con el nem2-cli existente, y los esfuerzos entre esta CLI y nem2-cli pueden dividirse. También puede ser un inconveniente menor, ya que los desarrolladores tendrán que descargar dos herramientas diferentes.
Alternativas
La integración de las características anteriores podría integrarse en el nem2-cli existente, que también utiliza el mismo patrón de diseño de software propuesto anteriormente.
En este caso, la funcionalidad se implementará como parte de un nuevo subcomando: nodo.
Este enfoque puede ahorrar tiempo en el desarrollo, así como otras herramientas existentes en el ecosistema.
El otro día, en NEM SEMINAR 2020, escuché sobre varias historias relacionadas con NEM, y una de ellas incluía contenido relacionado con la operación de nodos.
La palabra poderosa “Juki” fue tan impresionante que decidí probarla.
Comentario de Slack del desarrollador principal Jaguar
Leí que un desarrollador principal hizo el siguiente comentario sobre Slack:
Para que un nodo de red de prueba opere más de 1000 nodos, sería bueno si hubiera un artículo que detallara el procedimiento … Escribí este artículo.
La conclusión es que pudimos configurar nodos de red de prueba con bastante facilidad, por lo que sería bueno si los no ingenieros pudieran asumir el desafío audaz.
Por cierto, ¡comencemos con el castillo lo antes posible!
Procedimiento de construcción del castillo
Diagrama de Flujo
Cree un nuevo proyecto en GCP (Google Cloud Platform)
Cree una instancia de VM GCE (Google Compute Engine) (≒ Prepare la máquina virtual (マ シ ン servidor) en la nube)
Conexión a la instancia de VM creada
Entorno de compilación en la instancia de VM (Instalar Docker, Docker Compose)
Introduzca la herramienta de construcción de nodo de red de prueba de símbolos con Git y el nodo de inicio
Verifique el estado operativo del nodo localmente en la instancia de VM (verifique presionando / chain / height)
Configurado para poder acceder a nodos con direcciones IP desde fuera de GCP (Google Cloud Platform)
Establezca “host” y “friendlyName” en / node / info adecuadamente
Pasos detallados
Cree un nuevo proyecto en GCP (Google Cloud Platform)
Primero, creemos un nuevo proyecto. Ingrese un nombre de proyecto, seleccione una ubicación si es necesario y haga clic en el botón Crear. Si no está seguro del valor de configuración, continúe con el siguiente ejemplo de configuración tal como está. Después de crear el proyecto, espere un momento y la creación del proyecto se completará.
Ejemplo:
Nombre del proyecto
symbol-testnet-node-challenge
Ubicación
Si no hay un compromiso particular, el valor predeterminado "Sin organización" está bien
2. Crear instancia de VM GCE (Google Compute Engine)
Espere unos momentos para completar la creación del proyecto. Luego, el proyecto creado anteriormente (symbol-testnet-node-challenge según el ejemplo de configuración) se puede seleccionar de la lista desplegable de selección de proyecto, así que seleccionémoslo.
En ese estado, haga clic en el botón de tres líneas que muestra el menú de navegación en la esquina superior izquierda de la pantalla, mueva el cursor a Compute Engine en el elemento informático y haga clic en la instancia de VM en el menú que aparece.
Espere un poco hasta que Compute Engine esté disponible. Es aproximadamente un minuto. Cuando Compute Engine esté disponible, podrá hacer clic en el botón Crear cerca del lugar donde se muestra la instancia de VM, así que creemos una instancia de VM haciendo clic.
El ejemplo de configuración se resume a continuación. Si no está seguro, continúe con el procedimiento tal como está. Los elementos no mencionados en el ejemplo de configuración no necesitan hacer nada.
Nombre
símbolo-testnet-api-nodo-1
Región
asia-noreste1 (Tokio)
Zona
asia-noreste1-b
Configuración de la máquina
Familia de máquinas
Propósito general
Serie
N1
Tipo de máquina
n1-standard-2 (2 vCPU, 7.5 GB de memoria)
Disco de arranque
Haga clic en el botón Cambiar, marque el botón de radio Ubuntu 18.04 LTS, ingrese 40 en el campo Tamaño (GB) y haga clic en el botón Seleccionar
Cortafuegos
Marque Permitir tráfico HTTP
Marque Permitir tráfico Https
5. Una vez que haya configurado la configuración como se describe anteriormente, haga clic en el botón Crear para crear una instancia de VM. 6. La pantalla cambiará y verá una pantalla que enumera las instancias que está creando. Cuando se completa la creación de la instancia, se mostrará una marca de verificación verde a la izquierda del nombre, por lo que si puede confirmarse, continúe con el siguiente paso.
3. Conéctese a la instancia creada
Al hacer clic en Abrir en la ventana del navegador en el menú desplegable de la columna de conexión de la instancia de VM listada, se abre una pantalla negra en el navegador para conectarse a la instancia de VM. Las operaciones posteriores se realizan alrededor de esta pantalla negra.
4. Construcción del entorno
El procedimiento oficial está aquí (https://docs.docker.com/install/linux/docker-ce/ubuntu/), pero como está en inglés, la información necesaria se resume a continuación.
No hay problema si ejecuta los comandos en el orden que se muestra. Copie y pegue en una pantalla en negro y presione Entrar para ejecutar.
Tenga en cuenta que algunas preguntas como las siguientes pueden aparecer en el camino y el proceso puede detenerse. En ese caso, ingrese Y y presione Entrar para continuar el proceso.
Do you want to continue? [Y/n]
Buscar actualizaciones de todo el software en el sistema operativo
sudo apt-get update
2. Instalación de varias herramientas necesarias para la instalación de Docker
8. Ejecute el comando de verificación de la versión de Docker y, si se muestra la versión, tendrá éxito
Comando de confirmación de versión
docker --version
Ejemplo de resultado de confirmación
Docker version 19.03.5, build 633a0ea838
Instalar Docker Compose
El procedimiento oficial es según la pestaña de Linux en esta página (https://docs.docker.com/compose/install/), pero como está en inglés, la información necesaria se resume a continuación.
No hay problema si ejecuta los comandos en el orden que se muestra. Copie y pegue en una pantalla en negro y presione Entrar para ejecutar.
Tenga en cuenta que algunas preguntas como las siguientes pueden aparecer en el camino y el proceso puede detenerse. En ese caso, ingrese Y y presione Entrar para continuar el proceso.
3. Ejecute el comando de verificación de versión de Docker Compose, y si se muestra la versión, es exitosa
Comando de confirmación de versión
docker-compose --version
Ejemplo de resultado de confirmación
docker-compose version 1.25.3, build d4d1b42b
5. Introducir herramienta de construcción de nodo de red de prueba de símbolo y nodo de inicio
El procedimiento oficial está aquí (https://nemtech.github.io/ja/guides/network/running-a-test-net-node.html), pero si iniciar el nodo con la configuración del nodo API + nodo par Puede ser un poco difícil para aquellos que no conocen la situación determinar si iniciar el nodo solo con la configuración del nodo Peer.
El procedimiento para construir un nodo con la configuración del nodo API + nodo par se organiza a continuación. Si no está convencido por el procedimiento oficial, consulte aquí.
6. Verifique el estado operativo del nodo localmente en la instancia de VM
Para verificar el estado del nodo, simplemente puede ejecutar el siguiente comando.
curl http://localhost:3000/chain/height
Si el nodo se inició correctamente, se mostrará el siguiente resultado.
{"height":"16001"}
Si ejecuta curl http: // localhost: 3000 / chain / height varias veces seguidas para verificar la altura del bloque del nodo, verá que el número de resultados aumenta a una velocidad tremenda. Este número se acercará gradualmente a la altura del bloque más avanzado de los otros nodos.
Para su referencia, la URL donde puede verificar la altura del bloque del nodo de red de prueba que he configurado se enumera a continuación, así que úsela para verificar si se ha puesto al día pronto.
http://symbol-testnet-api-1.next-web-technology.com:3000/chain/height
7. Configurado para poder acceder a nodos con direcciones IP desde fuera de GCP (Google Cloud Platform)
En este momento, se ha iniciado el nodo de red de prueba y se puede acceder a la red de prueba desde el entorno local de la instancia de VM donde se ejecuta el nodo.
Sin embargo, en realidad, desea poder acceder a él desde otro lugar que no sea el local de la instancia de VM (por ejemplo, desde el navegador de su computadora personal o desde el navegador del teléfono inteligente). Hagamos las configuraciones necesarias en GCP para eso.
Cambiar la dirección IP externa de efímera a estática
En la configuración predeterminada, la dirección IP externa que se establece es un valor temporal que cambia cuando se reinicia la instancia de VM. (≒ efímero)
Esto puede no ser un problema, pero por simplicidad, haga una reserva por adelantado para asignar la dirección IP a la instancia de VM para que se use la misma dirección IP incluso después de reiniciar.
Haga clic en el botón de tres líneas para mostrar el menú de navegación en la parte superior izquierda de la pantalla y mueva el cursor a la red VPC en el elemento de red (parece ser necesario desplazarse hacia abajo porque es bastante bajo) Haga clic en la dirección IP externa en el menú que aparece.
Cambie el tipo de dirección IP externa de efímera a estática al desplegar.
En el cuadro de diálogo que aparece, se requiere un nombre para la configuración de reserva de esa dirección IP. Si no está seguro, ingrese el siguiente nombre y haga clic en el botón Guardar. La descripción es opcional y puede dejarse en blanco.
Poniendo como ejemplo
symbol-testnet-api-1-http
Crear reglas de firewall
Luego, abra el puerto No. 3000 para que el acceso como http: // dirección IP: 3000 / chain / height sea posible desde fuera de GCP.
Haga clic en Reglas de firewall y haga clic en Crear regla de firewall con la marca +.
Realice los ajustes para abrir el puerto No. 3000 en la pantalla que aparece. Si no está seguro del valor de configuración, utilice el siguiente ejemplo de configuración tal como está. Los contenidos que no se describen en los ejemplos de configuración son probablemente los predeterminados. Una vez que haya ingresado la configuración, haga clic en el botón Crear. Antes de hacer clic en el botón Crear, copie el valor de la etiqueta de destino para facilitar los pasos posteriores.
Poniendo ejemplo
Nombre
símbolo-testnet-http-allow
Dirección del tráfico
Subiendo
Acción en partido
Permiso
Target
Seleccione la etiqueta de destino especificada en el menú desplegable
Etiqueta de destino
symbol-testnet-http-allow … Copie este valor para su uso posterior.
Además, sentí que cómo escribir la configuración de la etiqueta de destino aquí le daría al ingeniero la impresión de que se debe describir la información de la instancia de VM a la que se asigna esta regla de firewall. Correctamente, lo que se establece aquí es el nombre de la etiqueta que representa esta regla de firewall, y parece que la imagen de que este nombre de etiqueta se establece en el lado de la instancia de VM es correcta.
Filtro fuente
Rango de IP
Rango de IP de origen
0.0.0.0/0
Protocolo y puerto
Verifique el botón de radio para el protocolo y puerto especificados
Comprobar tcp
Ingrese 3000 en el campo de entrada a la derecha de tcp
Aplicar reglas de firewall a instancias de VM GCE (Google Compute Engine)
Haga clic en el botón de tres líneas para mostrar el menú de navegación en la parte superior izquierda de la pantalla, mueva el cursor a Compute Engine en el elemento informático que contiene y haga clic en la instancia de VM en el menú que aparece.
Haga clic en el nombre de la instancia de VM de destino (symbol-testnet-api-1 si es el mismo que el ejemplo de configuración) y haga clic en la edición en la parte superior de la pantalla que aparece.
Ingrese el valor de la etiqueta de destino copiada anteriormente (symbol-testnet-http-allow en el ejemplo de configuración) en el elemento llamado etiqueta de red (puede que no lo encuentre a menos que se desplace hacia abajo), y Haga clic en el botón Guardar a continuación.
Regrese a la pantalla de la lista de instancias de VM con la flecha y verifique la dirección IP externa. Las direcciones IP externas se enumeran en la columna denominada IP externa. Por ejemplo, en mi caso, la dirección IP externa era 104.198.94.48. En este caso, puede verificar la altura del bloque accediendo a la siguiente dirección desde su PC o teléfono inteligente. Lea y reemplace la dirección IP externa de acuerdo con su entorno.
8. Establezca “host” y “friendlyName” en / node / info adecuadamente
Este es el último elemento de este artículo. Hay dos elementos de configuración para el nodo, host y friendlyName. Si inicia el nodo con la configuración predeterminada, estos valores se establecerán en blanco para host y algunos valores misteriosos para friendlyName.
Para reconfigurar correctamente, parece necesario detener el nodo, editar el archivo de configuración e iniciar el servicio del nodo nuevamente.
El procedimiento aquí tuvo la impresión de “¿Es realmente necesario?” (Si se requiere host = host name?, ¿Por qué debería tomarlo automáticamente en el proceso de inicio del nodo? Si el usuario da friendlyName como apodo, escríbalo en el archivo de configuración antes de iniciar el nodo. Me pregunté si iniciar el nodo completaría el inicio del nodo de una sola vez. El archivo de configuración no existía antes de que el nodo se iniciara por primera vez, por lo que se preguntó si había alguna restricción.
Nodo de Inicio
sudo docker-compose down
2. Edición del archivo de configuración (config-input.yaml)
Ir a la ubicación del archivo de configuración
Si siguió los pasos de este artículo, ahora se encuentra en la carpeta api-harvest-assembly. En ese caso, creo que puede moverse a la carpeta donde se encuentra el archivo de configuración config-input.yaml con el siguiente comando. Después de mover, asegúrese de que el archivo de configuración esté en esa carpeta.
Mover comando de carpeta
cd api-node
Comando para mostrar archivos y carpetas en esa carpeta
ls
OK si hay una pantalla de config-input.yaml
Edición de archivos de configuración
Edición en una pantalla negra
Comandos para usar nano
sudo nano config-input.yaml
Editar parte
friendlyName
Antes del cambio
friendly_name:
Después del cambio (ejemplo de configuración)
friendly_name: symbol-testnet-api-node-1
Guardar y cerrar
Ctrl + X
Ingrese Y y Enter
Presione Entrar para guardar y cerrar el nombre del archivo
Edición del archivo de configuración (config-node.properties.template)
Ir a la ubicación del archivo de configuración
Si siguió los pasos de este artículo, ahora está en la carpeta api-node. En ese caso, creo que puede moverse a la carpeta donde se encuentra el archivo de configuración config-input.yaml con el siguiente comando. Después de mover, asegúrese de que el archivo de configuración esté en esa carpeta.
Mover comando de carpeta
cd userconfig
cd resources
Comando para mostrar archivos y carpetas en esa carpeta
ls
OK si hay una pantalla de config-node.properties.template
Edición de archivos de configuración
Edición en una pantalla negra
Comandos para usar nano
sudo nano config-node.properties.template
Editar parte
anfitrión
Antes del cambio
host =
Después del cambio (ejemplo de configuración)
host = symbol-testnet-api-node-1
Guardar y cerrar
Ctrl + X
Ingrese Y y Enter
Presione Entrar para guardar y cerrar el nombre del archivo
4. Regrese a la carpeta donde está docker-compose.yaml e inicie el servicio de nodo nuevamente
Comando para regresar a la carpeta anterior (Repita tres veces para regresar a esa carpeta)
cd ..
Comando para reiniciar el nodo
sudo docker-compose up --build --detach
Con esto, el nodo se puede construir con el host y friendlyName correctamente configurados, y ahora es posible el acceso a una dirección IP externa.
Aunque se convirtió en un volumen considerable en el manual de procedimientos, como trabajo real, sentí la impresión de que construir un nodo blockchain era bastante fácil.
Algunas personas han lanzado el script de automatización de construcción de nodos de AWS, por lo que puede ser bueno construir un castillo en AWS.
Si tiene alguna pregunta o error, no dude en comentar.
Antes de iniciar su red principal, asegúrese de que su red de prueba pueda ayudarlo a cerrar la red de prueba, encontrar problemas y conducir a mejores lanzamientos de red principal donde los problemas se solucionen por adelantado. Estoy rezando
Vamos, digamos “¡Vamos a construir!”
Información referida
Hice un script para construir el nodo de red Catapult test. (Para AWS EC2 Amazon Linux2)
https://nemlog.nem.social/blog/36829
GCP (GCE) + ubuntu 18.04 LTS y configurar el nodo Symbol
https://nemlog.nem.social/blog/38049
Será agregado
En la operación real, querrá asignar un dominio y usar una URL de cadena en lugar de especificar directamente la dirección IP. Me gustaría agregar algunas configuraciones de dominio en alguna parte.
Creo que se necesita un nodo https en un entorno de producción. Me gustaría agregar algo sobre la configuración de SSL y el procedimiento para convertirlo en un nodo https.
¡Hola! Seguramente a muchas personas les gustaría ejecutar el Nodo Catapult Testnet de NEM. Pero parece que las siguientes razones evitan que esto suceda:
No entiendes cómo hacerlo;
No tienes el hardware;
Parece muy complejo y crees que no puedes hacerlo.
Por lo tanto, hice una guía simple y clara, que lo ayudará a ejecutar el nodo usando el costo mínimo (desde 2.96 euros por mes). Todo lo que necesita hacer es copiar y pegar texto (lo suficientemente fácil, ¿sí?). La guía tiene dos etapas con descripciones de texto y video. El proceso tomará un máximo de 10 minutos y obtendrá su nodo que funciona en Centos 7.
Entonces, harás los siguientes pasos:
Encuentre un servidor para el nodo de ejecución;
Ejecuta algunos comandos.
Si dudas o eres demasiado vago para leerlo, mira una guía de video. ¡Es realmente rápido y simple!
Si necesita ayuda, solo pregunte. Trataré de ayudar.
Cómo encontrar un servidor para el nodo
> Requisitos mínimos para hardware
Se sugiere que use la nube e implemente el nodo allí. Encontré un servicio realmente bueno y barato con pago por uso (hetzner.com). Utilicé hetzner.com en esta guía, pero puedes usar cualquier otro servicio (por ejemplo, digitalocean.com). Lo principal es: instale Centos 7 en su servidor y tendrá éxito.
¡Tenga en cuenta! Puede usar incluso el servidor más barato (sí, en CX11 todo funciona bien), pero es mejor usar el CX21 porque cumple con los requisitos mínimos de los desarrolladores (4 GB de RAM y 2 núcleos). Más tarde, puede aumentar los parámetros del servidor y no pagar de más porque paga a la tarifa por hora.
Lo que debes hacer:
Regístrese en https://hetzner.com.
Ordenar servidor en la nube:
2.1. Consola abierta (https://console.hetzner.cloud/projects) 2.2. Crear un proyecto (sea cual sea el nombre que sea); 2.3. Haga clic en “Agregar servidor”; 2.4. Seleccione la ubicación del servidor que le guste, OS – Centos 7 (es necesariamente); 2.5. Haga clic en “Crear y comprar ahora”. Después de varios segundos, recibe el correo electrónico con las credenciales del servidor. Lo que debe hacer con él: lea en la próxima publicación.
Video guía – Cómo crear un servidor en Hetzner:
Cómo ejecutar un nodo testnet en un servidor con Centos 7
Entonces, Se recibió las credenciales del servidor y lo configuraremos ahora.
Debe hacer lo siguiente:
Descargue Putty para activar al servidor a través del protocolo ssh.
Abra Putty, copia la dirección IP de su servidor en el campo de entrada del nombre de host.
Ingrese el inicio de sesión del servidor que ya recibió (root);
Ahora debe ingresar la contraseña. Puedes copiarlo y pegarlo. Para pegar texto desde el portapapeles, simplemente presione el botón derecho del mouse. ¡Tenga en cuenta! Cuando ingresa una contraseña, no se muestra nada en la pantalla. Esto es normal, no te preocupes.
El servidor puede pedirle que establezca una nueva contraseña. Hazlo
7. Este paso no es obligatorio, pero si desea especificar un nombre descriptivo para el nodo, ejecute los siguientes comandos:
docker-compose down
nano api-node/config-input.yaml
docker-compose up --build -d
Cuando se abra el nano editor, cambie el valor del campo friendlyName por el suyo. ¡Tenga en cuenta! Presione Ctrl + X para salir de nano.
8. ¿Cómo verifico que el nodo funciona correctamente? Abra en un navegador http: // NODE_IP: 3000 / chain / height (reemplace NODE_IP por IP de su servidor) y asegúrese de que el nodo se esté sincronizando (la altura aumentará)
Este proceso funcionó para mí, ¡espero que pueda ayudar! Para este tutorial, necesitará un instalador de Ubuntu 18.04.
Antes de comenzar a ver el video muy aburrido, muestra el proceso completo. Creo que eso ayudará. Tenga en cuenta que soy nuevo en esto y en Linux.
Requisitos de hardware
Los nodos de catapulta se han probado en computadoras con los siguientes requisitos mínimos.
CPU: 2 núcleos o más
(Las CPU Intel de cuarta generación no funcionarán. Probablemente la solución esté en camino. No sé acerca de las CPU AMD de quinta y sexta generación ni de ninguna CPU de AMD. Todo lo que puedo decir es que cada Intel de la séptima generación funcionará)
Memoria: 4 GB o más
HD: 20 GB o más
Sistema operativo: Linux o Mac / Ubuntu 18.04 Bionic se utilizó para este Tutorial.
Instale Ubuntu junto con su sistema operativo principal. Después de cada reinicio, ahora puede elegir entre los sistemas operativos.
Obtenga todas las actualizaciones y reinicie. Abra el navegador web y abra los enlaces proporcionados debajo. O copie y pegue los comandos en el tutorial.
Por ahora también tendrá que cambiar 2 archivos “peers-p2p.json”. Vaya a sus archivos y busque la carpeta de arranque de catapult testnet, y copie y pegue en los archivos como se muestra en el video. Aquí el texto:
2. Elija la distribución de ensamblaje que desea instalar.
En resumen, si desea poder interactuar con su nodo, debe ejecutar el ensamblado API. Por otro lado, si desea un nodo dedicado exclusivamente para confirmar las transacciones, implemente el ensamblado de igual.
cd catapult-testnet-bootstrap/api-harvest-assembly
ó…
cd catapult-testnet-bootstrap/peer-assembly
Ejecute el nodo con docker-compose.
sudo docker-compose up --build --detach
Debería ver a Docker descargando las imágenes del contenedor por primera vez, luego debería ejecutar la configuración y finalmente iniciar el servicio.
Si ha instalado la distribución api-harvest-assembly, puede verificar también que el nodo se está ejecutando abriendo una nueva pestaña del navegador con la siguiente URL: localhost: 3000 / chain / height
Su nodo debe estar ejecutándose y sincronizándose.
Este es un mensaje conjunto para nuestra comunidad en nombre del Grupo de Migración de Catapult, compuesto por la Fundación NEM, NEM Studios, NEM Ventures y Tech Bureau Holdings.
Descripción del proyecto
Fecha de lanzamiento dirigida al primer trimestre de 2020
Lo que se ha hecho hasta la fecha:
02-07-2019 Se crea el Comité de Migración
15-09-2019 Propuesta inicial publicada
02-10-2019 Tokenomics redactado
Oct 2019 FC Lanzamiento F1
Nov 2019 El equipo de migración tomó la decisión de admitir Opt-In.
18-11-2019 Lanzamiento interno FC F2
30-11-2019 Recomendaciones de Tokenomics hechas y compartidas con el núcleo
03-12-2019 Lanzamiento RC compatible con SDK Gateway F2
04-12-2019 Recomendaciones de Tokenomics compartidas con los titulares de Supernodo para comentarios
12-12-12 Últimas billeteras compatibles lanzadas (La última actualización es 0.8.9)
16-12-2019 Comienzo de la votación de PDI de Propuesta de Migración y Tokenómica
19-12-2019 La propuesta de marca se dará a conocer al público para su votación
21-12-2019 Propuesta de migración y tokenomics Cierre de votación de POI
Diciembre de 2019 Se iniciaron las pruebas y la revisión
02-01-2020 Cierre de votación de propuesta de marca
Futuros Hitos
13-01-2020 Comienza el nuevo Ticker de Symbol
30-01-2020 Directrices de marca / conjunto de herramientas entregado
Feb – Mar 2020 LANZAMIENTO
Mar 2020 Post lanzamiento reevaluar y reconfirmar planes futuros aún en pie
Con base en los plazos de los hitos anteriores, Catapult todavía apunta al lanzamiento del primer trimestre de 2020. Mantendremos a todos informados a medida que las cosas progresen.
Proceso para el Lanzamiento de Catapult
Una pregunta común de la comunidad se refiere a cuál es el proceso para la toma de decisiones para impulsar el lanzamiento de Catapult. Esta es la recomendación (de alto nivel) de la Fundaciónn, Studios y Ventures a los desarrolladores principales.
El Comité de Migración forma una propuesta inicial de opciones técnicas, tokenómica y marca, y comparte con la comunidad para recibir comentarios. Opciones técnicas completas, Tokenomics y Brand en curso, se espera que finalicen en enero.
La retroalimentación se absorbe y equilibra entre lo que se quiere y lo que es posible, a través de varios grupos de partes interesadas (Devs principales, Super Node Holders, Comunidad más amplia, Entidades NEM, Partes externas) y crea tres propuestas
Tokenomics: en curso, se espera que se comparta públicamente antes del 9 de diciembre
Marca: en curso, se espera que sea compartida a mediados de enero de 2020 a más tardar
Se redactan dos propuestas resumidas que abarcan los tres elementos y se presentan a la comunidad para que tome una decisión. Uno abarcará la tokenómica y la migración, mientras que el otro girará en torno a la marca. Si se rechaza, se volverá a trabajar, pero esto puede afectar el lanzamiento del primer trimestre de 2020 y debe equilibrarse para evitarlo como prioridad
En la actualidad, ambas propuestas han sido aceptadas por la comunidad.
Propuesta de Opt-In
El equipo de migración propone que cada cuenta tenga que suscribirse para recibir tokens de Symbol. Esto incluye cuentas multi-sig y no multi-sig. Las cuentas no recibirán tokens de símbolos o configuraciones de múltiples firmas a menos que se suscriban. Las cuentas pueden suscribirse antes o después del lanzamiento de la cadena pública. Para aquellos que esperan hasta después del lanzamiento, sus tokens de Symbol se mantendrán en una cuenta nominada hasta que sean reclamados cuando el propietario opte por participar. El proceso / entidad para administrar estos tokens no reclamados se definirá y comunicará antes del lanzamiento. Después de un período específico (6 años es el supuesto actual debido al estatuto de limitaciones) la propuesta es quemar tokens no reclamados …
Tecnología y Desarrollo
Actualización Anterior / Actualización Actual
Billetera de Escritorio: la última versión de Desktop Wallet (v0.8.9) se lanzará a principios de la próxima semana.Se ha iniciado una fase beta temprana para este proyecto, de la cual puede ver el código fuente en Github aquí.
Billetera para Dispositivos Móviles: actualmente no hay un lanzamiento público para Mobile Wallet, pero el paquete se ha trabajado y se lanzará en forma de una aplicación de Google Play Store, así como una aplicación de Apple Store. (iOS)
Explorador de Bloques: la última versión de explorador de bloques está disponible como una demostración aquí y también se puede usar para redes privadas de blockchain y también con la testnet experimental de l Fundación NEM para Catapult. Se ha iniciado una fase beta temprana para este proyecto, de la cual puede ver el código fuente en Github: aquí
Carteras de hardware:
Trezor: la integración de la billetera de hardware para Trezor en la billetera de escritorio ha comenzado y ha progresado bastante. El equipo de Labrys está trabajando actualmente en la integración de firmware de Catapult para dispositivos Trezor.
Ledger: un proveedor de servicios de la Fundación NEM también está trabajando en la integración de Catapult para dispositivos de hardware Ledger, este proyecto aún está en su fase inicial y aún no se ha publicado.
REST & SDK Los desarrolladores de NEM Studios han completado los últimos cambios de compatibilidad del servidor. Se actualizaron nuevos lanzamientos de SDK y los diversos clientes los han actualizado.
Revisión / Prueba Las siguientes fases de prueba están comenzando, incluyendo nuevas pruebas de rendimiento y pruebas de penetración por un tercero, a medida que comenzamos el programa de recompensas de errores abiertos en la plataforma de revisión de seguridad HackerOne. Estos esfuerzos continuarán durante el tiempo de lanzamiento
TestNet: se está ejecutando una nueva versión de testnet y se han aplicado configuraciones basadas en la propuesta de tokenomía. Todas las compilaciones actuales y en curso de los distintos clientes apuntarán a la red de forma predeterminada.
¿Que hay de Nuevo?
La Testnet ya está en vivo! Para obtener más información sobre nuestro comunicado de prensa y cómo participar, vaya aquí.
Alcance de Exchange
El alcance de Exchange para Symbol continúa y se ha convertido en el Comité Directivo de Symbol Exchange dirigido por Anton Bosenko, miembro del Consejo de la Fundación NEM. El Comité Directivo de Symbol Exchange también incluye a Alexandra Tinsman, Cryptobeliever, Jeff McDonald, Ъ !!! 11, Greg Saive, Pedro Gutierez y Flora Fang.
Actualización anterior / Actualización Actual
Finalización de la plataforma de lanzamiento que incluirá información sobre:
NEM
Nuevo proyecto
Equipo
Nuevo modelo tokenómico
Plan de marketing y relaciones públicas de alto nivel
Enfoque de liquidez
Plan de soporte NIS1 (XEM)
Líneas de tiempo
Integración de información técnica
Realizar la reunión con uno de los intercambios japoneses
Obteniendo comentarios de los intercambios TIER 1 que enlistan a XEM
¿Que hay de Nuevo?
La versión extendida de la plataforma de lanzamiento está en proceso
La reunión se celebró con el Intercambio japonés y el proceso de preparación de la lista ha comenzado.
Se han establecido canales de comunicación con 10 intercambios, se están negociando
Debido a la naturaleza de dichas negociaciones, no se puede divulgar toda la información.
Estrategia de marca y lanzamiento al mercado
Estrategia de Marca
Las actualizaciones de marca se pueden encontrar en los foros de NEM aquí.
¿Que hay de Nuevo?
El 13 de enero de 2020 (PST), se realizará una votación para el ticker de nuestra nueva marca (Symbol). Para obtener más información (más cercana a la fecha) sobre cómo participar, vaya aquí .
Desde la exitosa votación de la comunidad sobre la nueva marca Symbol durante las vacaciones, se ha trabajado para aumentar la conciencia sobre el nuevo cambio en la marca. Puede encontrar más información sobre nuestro comunicado de prensa aquí.
Tokenomics
Previa/Actual actualización
Varios miembros de la comunidad, el comité de migración y el grupo de titulares de supernodos han expresado ideas / preferencias. Esta información y varios modelos se han completado y compilado en una propuesta concreta que ha sido revisada por el Comité de Migración, el Equipo Central, el Grupo SuperNode y la Comunidad. Ha sido bien recibido en todos los ámbitos y ahora forma parte de la votación del PDI.
¡A partir del 21 de diciembre de 2019, a las 3:00 p.m. PST, la encuesta de votación sobre PDI de Migración y Tokenomics ha concluido! Los resultados son los siguientes:
Sí (aprobación) votos: 365 puntaje ponderado: 3.52268% porcentaje: 95.00
No (rechazar)
votos: 11
puntaje ponderado: 0.18558%
porcentaje: 5.00
Se han cumplido todos los requisitos previos para una votación aprobada (votos “SÍ” con un mínimo de 3% de PDI y 65% de mayoría).
Dada la aprobación de la comunidad, el Comité de Migración ahora considerará que la moción ha sido aprobada, y las acciones comenzarán luego de dicha propuesta.
