Actualización de Safe Network Dev 🇪🇸 2 marzo 2023

Esta es una traducción automática. El original en inglés está aquí: Update 02 March, 2023

A diferencia del hardware, con el código es fácil y económico agregar características. Para un fabricante de automóviles, incluso cambiar algo tan periférico como un espejo retrovisor significa reacondicionar una línea de producción, probar la aerodinámica, coordinar la cadena de suministro global, etc., mientras que el software equivalente puede ser escrito por un solo desarrollador en una tarde. Eso es hermoso, pero también es peligroso: siempre es mucho más fácil sumar que restar, y la hinchazón crea más hinchazón: se automultiplica. Es por eso que, por extraño que parezca, estamos mucho más orgullosos del código que logramos eliminar que de los extras que agregamos.

Desde el exterior, eso podría parecer cavar agujeros y luego rellenarlos de nuevo, pero en realidad se trata de esculpir cada trozo de material hasta que sea lo más ligero posible. Esa es la parte que requiere tiempo, habilidad y precisión. Pero debido a que en Safe Network cada parte está íntimamente conectada entre sí, los beneficios de ese esfuerzo finalmente se extienden por toda la red.

Lo cual está muy bien hasta que queremos demostrar alguna característica importante que depende de todo ese intrincado cincelado que se lleva a cabo aguas arriba. Los DBC v0.1 ya están listos, pero los DBC están íntimamente conectados con todo lo demás. Los DBC nos permiten pagar el almacenamiento, el almacenamiento necesita una entrega confiable, las necesidades de entrega… etc. Es por eso que, como se mencionó la semana pasada , buscaremos una red de demostración solo de pago que sea independiente del trabajo en curso en otros lugares, una que no se aleje demasiado del camino en el que ya estamos.

Progreso general

@Chriso está simplificando la CLI, eliminando el antiguo comando node y renombrando el nodo safenode — gracias por todas las sugerencias de nombres Por cierto :gafas de sol:.

@Anselme agregó un campo motivo a SpentProofs, escrito por el cliente y verificable por los ancianos sin necesidad de una firma. Esto debería significar que no necesitamos ancianos para firmar datos, eliminando de un plumazo el vector de “ataque de clave antigua”, donde un mal actor con una clave anterior puede validar datos. También limpió algunos bucles extraños en la lógica de chismes de AE.

Mientras tanto, @joshuef mejoró los registros de reubicación para eliminar un par de errores falsos y confusos que dificultaban el seguimiento de los flujos, y también modificó la edad del nodo por la misma razón.

@Qi_ma ha estado refactorizando pares de sección por lo que tenemos la lógica de membresía en un lugar sólido. Esto debería ayudar a prevenir problemas relacionados con la rotación de miembros.

Y @oetyng ha estado trabajando en la red de pago, cuyo motivo se indica a continuación.

Una red solo de pago

Hay problemas de tecnología dura que estamos resolviendo, y este es el verdadero trabajo del proyecto. Pero al mismo tiempo, tenemos algunas partes que ya funcionan bien, una de ellas es nuestra tecnología DBC. La red de pago es una forma de mostrar, paso a paso, los atributos, las funciones y el rendimiento de los DBC mientras esperamos que maduren nuestras otras innovaciones.

También queremos poder probar y refinar la experiencia de usuario, verificar fallas inesperadas y trabajar en otras áreas del diseño.

Una red de pago de prueba será una forma de emular la forma en que se usarán los DBC en la red segura, una que sea independiente del almacenamiento de datos y que permanezca lo más cerca posible del diseño general de la red, con sus protecciones contra los ataques de Sybil, DDoS y el resto. .

Como se indicó en la introducción: queremos asegurarnos de que encaje lo más posible con el resto del diseño, sin dejar de funcionar como un prototipo independiente. De esa manera, podemos tomar nuestros aprendizajes y simplemente devolverlos.

Tener una red de pago en funcionamiento también tiene un potencial tentador para ayudarnos a abordar algunos desafíos adicionales:

  • Demostrar y comercializar algunas de las tecnologías innovadoras en las que hemos estado trabajando. Poner los ojos en el proyecto y la ilusión por lo que está por venir.
  • Comparar directamente el desempeño con las monedas vigentes.
  • Demostrar los IP sobre los titulares, p. desempeño, habilidades únicas de los DBC, credenciales ambientales, etc.
  • Reavivar el interés en un proyecto que algunos pueden haber olvidado.
  • Integración de intercambio piloto y aceptación de la tecnología económica antes del lanzamiento completo, donde será fundamental para el crecimiento y la accesibilidad de la red.
  • Cree una base de nodos antes del lanzamiento completo.

Entonces, en general, vale la pena la evaluación de factibilidad que estamos realizando, ya que podría ser una herramienta útil en el camino hacia el lanzamiento.

Probando… probando…

También sería una forma de distribuir el riesgo y abordar los problemas de forma coordinada y por etapas; como un gran lanzamiento de una red de pago y de datos naturalmente tendría más puntos potenciales de falla.

Mientras que una red de pagos separada podría probarse e iterarse sin el riesgo combinado. Podemos aprender de ello y seguir construyendo. No es la visión completa, sino unaparte de una serie de productos que podemos construir, y continuaremos construyendo a medida que trabajamos hacia esa visión. Un enfoque más ágil si se quiere.

Necesitamos averiguar cómo asegurarlo en cada paso de bebé para evitar los inevitables spammers y ataques, pero es muy prometedor.


Enlaces útiles

No dude en responder a continuación con enlaces a las traducciones de esta actualización para desarrolladores y los moderadores las agregarán aquí.

Como proyecto de código abierto, siempre estamos buscando retroalimentación, comentarios y contribuciones de la comunidad, así que no sea tímido, únase y creemos la red segura juntos.