Esta es una traducción automática. El original en inglés está aquí: Update 30 March, 2023
A veces, cuando se trabaja con tecnología de punta, todo lo que puede hacer es esperar a que ocurran desarrollos en otros lugares. Esos avances pueden tardar mucho en llegar, pero esta semana nos complace anunciar un avance significativo en el frente de las redes. También estamos logrando un progreso significativo en los DBC, las tarifas de Tx y la forma en que los ancianos los manejan. @oetyng explica más.
Progreso general
Muchos aspectos positivos de los que hablar esta semana. Primero, un trabajo de detective magistral de @qi_ma 
ha descubierto la causa raíz de un problema de larga data que hemos estado experimentando con la red. inicio, que estaba causando fallas de CI. Me complace decir que el dolor de cabeza ya no existe.
Ahora en algo descrito por @dirvine tanto como “un cambio de juego” y también, un poco misteriosamente, como “muy relajante”. ¿Así que qué es lo? Bueno, esta semana, Protocol Labs, el equipo detrás de IPFS y Filecoin, actualizó su biblioteca libp2p. Libp2p ha demostrado ser bastante exitoso en la multiplexación y la perforación, pero hasta ahora solo ha funcionado sobre TCP. Eso ahora ha cambiado y la biblioteca funciona con UDP y QUIC, que es lo que usa Safe para administrar las conexiones entre nodos. Libp2p es utilizado por Filecoin, Eth y Avalanche y tiene un montón de excelentes ingenieros trabajando para ello.
Aún mejor, obtenemos perforaciones gratuitas, descubrimiento de nodos locales, protecciones DoS y más. Parece que libp2p ahora es lo que se propuso ser y lo que estábamos tratando de crear con qp2p: una biblioteca sólida centrada en p2p. Con la reciente inclusión de QUIC, podemos ver que el equipo libp2p se dio cuenta de que mucho del trabajo que hicieron (multiplexación de flujo, ruido para seguridad, etc.) está cubierto en QUIC.
De todos modos, buenas noticias en general. Debería significar que finalmente tenemos una gran estabilidad en la capa de redes y que la capa de redes funcione como queremos. Así que felicidades a la gente de libp2p 
Con un poco de ajuste y algunas relaciones públicas, deberíamos poder finalmente reemplazar a Quinn y qp2p en Safe. Las limitaciones de estas bibliotecas han mantenido a David despierto por la noche durante muchos meses. Finalmente, puede relajarse. :sombrilla de playa:
@bzee ya logró obtener un prototipo de red Kademlia especificado con libp2p y con un poco más de trabajo que debería estar operativo como prueba. @Roland también está investigando la documentación para ver si podemos aprovechar esto.
@bochaco ha agregado algunos comandos CLI al nodo RPC para permitir cosas como verificaciones de nivel de almacenamiento, consultas de recompensas y mutaciones de billetera.
Y @oetyng ha estado en servicio de pagos. Más sobre eso a continuación.
Actualización sobre la red de pago
Hemos cubierto algunos pasos justos hacia una red de pago.
En primer lugar, como algunos ya encontraron anteriormente al ejecutar una red local, hicimos que los Clientes consultaran a los Ancianos por una tarifa (un valor codificado de 1 nano) y extendieron su transferencia para que también contuviera un DBC cada uno para los Ancianos. Eso significaba que al enviar tokens, cada DBC de entrada que gastara costaría 7 nanos pagados a los Ancianos.
Pero el pago fue esencialmente una quemadura. Porque el Anciano no podía ver que había un pago para ellos, ni acceder a él.
Verificando el monto de la tarifa
Entonces, el siguiente paso fue introducir el “cegamiento” del monto de la tarifa, para que el Anciano pudiera verificar que A. había un pago allí para ellos, y B. que era un monto suficiente . Porque recuerda, un extraño no puede ver qué cantidad contiene un DBC, ni para quién es. Debemos tener una manera de decirles a los Ancianos estas cosas.
Por lo tanto, los Clientes envían un par de cifrados (información cifrada) junto con su solicitud de gasto. Cuando el Anciano recibe esto, puede descifrarlo y obtener lo siguiente:
Índice de derivación
El “índice de derivación” se utiliza para derivar la clave pública (esencialmente, el identificador único) del nuevo DBC que contiene el pago de la tarifa. El Cliente obtiene esa identificación de la clave pública estática que envía el Anciano, junto con el monto de la tarifa requerida actualmente al consultar al Anciano.
The Elder usa este mismo índice de derivación para derivar la clave secreta correspondiente, con la que pueden desbloquear el valor en el DBC que contiene el monto de la tarifa para ellos.
Como este índice de derivación se envía encriptado al Anciano, nadie puede decir que hay un pago a este Anciano, y no hay forma de ver por cuánto fue.
Factor de cegamiento + importe
Además, el Cliente envía el factor de cegamiento encriptado y la cantidad.
Con el ‘factor de cegamiento’, el Anciano puede cegar el monto y compararlo con el monto de la transacción DBC. Esto se debe a que si se usa el mismo “factor de cegamiento” y la misma cantidad, se produce exactamente la misma confusión ininteligible. Esta es la razón por la cual el “factor de cegamiento” también está encriptado. Solo el Cliente y el Anciano conocerán el monto.
Para obtener más detalles sobre el flujo anterior, puede leer la sección de comentarios en la parte superior de este archivo: safe_network/mod.rs at main · maidsafe/safe_network · GitHub
Finalmente gestablecer la tarifa
Cuando una gran mayoría de Elders ha firmado el gasto, cada uno de ellos envía un SpentProofShare a los titulares de datos en la red. Al consultar esos recursos compartidos, la Prueba gastada se puede agregar a partir de estas firmas y se pueden crear los DBC correspondientes a cada uno de los resultados de la transacción. Por lo tanto, un anciano puede consultar la red en busca de estos y luego construir el DBC que contiene el pago de la tarifa.
De la tarifa codificada a la dinámica
Un nano por tarifa no ayudará mucho, por lo que desenterramos el cálculo de los tokens necesarios para almacenar algunos datos que ya teníamos en nuestros archivos.
La implementación calcula los tokens necesarios para las operaciones de escritura, como una cantidad de tokens que se pagarán por una cierta cantidad de bytes, dado el prefijo de la sección actual, la cantidad de nodos en la sección y el porcentaje lleno. Esto también se puede usar para calcular la tarifa de una transferencia, ya que solo la alimentamos con un número fijo de bytes.
Dados los parámetros de entrada y el diseño de la curva, se produce un efecto sobre el precio en función de la oferta y la demanda, aunque con cierta inercia. El valor calculado es mayor cuando hay menos nodos en la sección, cuando hay menos espacio disponible y antes en la red. ¿Antes en la red? podrías preguntar. Sí, se supone que una red más grande significa que el token tiene un mayor valor ya que más personas comparten una cantidad constante de tokens. Por lo tanto, la cantidad requerida de tokens por operación también es menor a medida que crece la red. En otras palabras, el precio refleja el carácter deflacionario del SNT.
Otra propiedad de la curva es que es muy plana en un nivel bajo hasta que queda aproximadamente 1/3 de espacio, por lo que comienza a aumentar rápidamente. El motivo es que la tarifa se mantenga lo más baja posible durante el mayor tiempo posible.
Pero, esto no es un reemplazo para un verdadero mercado. A pesar de que tenemos cierto control sobre la oferta y la demanda, es bastante lento y, por lo tanto, el monto de la tarifa basado en eso es bastante rígido. Por lo tanto, es difícil para la red reflejar los cambios reales en el valor fiduciario del token, y eso puede generar grandes desequilibrios, lo que nunca es bueno. Dichos desequilibrios podrían ser demasiadas solicitudes o muy pocas, porque el valor real no está sincronizado con el valor calculado a partir de los parámetros de la red.
Eso nos lleva a la opción de que un Cliente priorice sus gastos, y lo que eso abre para nosotros.
Cola de prioridad de gasto
Una “prioridad” adjunta a un gasto es un gran salto hacia un verdadero mercado, donde las propiedades de oferta/demanda del sistema son ágiles y receptivas.
Esto lo hacen los Ancianos manteniendo una * cola de prioridad *, ordenada por el valor de la tarifa que se les paga para firmar el gasto.
Los beneficios de implementar una cola de prioridad son los siguientes:
- Los clientes pueden obtener un precio más bajo por su almacenamiento si la demanda es baja.
- Los ancianos pueden obtener una mayor recompensa por sus servicios si la demanda es alta.
- Los incentivos para que los operadores de nodos ejecuten nodos adicionales aumentan cuando aumenta la demanda.
- La red se vuelve más receptiva y puede crecer más rápido (atraer más para ejecutar nodos) cuando aumenta la demanda.
- La operación continua de los nodos está más protegida de la sobrecarga de los gastos del cliente.
- La carga en la red se distribuye a lo largo del tiempo, ya que las personas aplazan los gastos en momentos de gran carga y los trasladan a momentos de menor carga.
- Existe la posibilidad de que los Ancianos accedan a sus recompensas más rápido, ya que pueden reunirlas y volver a emitirlas en un DBC más grande cuando las tarifas son bajas.
- …y más…
El primer ejemplo utiliza algunos pasos discretos de “prioridad” para un Cliente, para usar desde la interfaz de usuario de la billetera al realizar un pago. Esto elimina la necesidad de establecer manualmente los montos de las tarifas.
La prioridad se traduce en una tarifa basada en las tarifas actuales en la cola. Una prioridad alta significaría que paga un valor similar a los que están más arriba en la cola, y viceversa para una prioridad baja. También puede configurarlo por encima del valor más alto, o por debajo del más bajo, y ahí es donde puede comenzar la presión sobre el precio, en función de la oferta y la demanda, y las necesidades de los Clientes y los operadores de nodos para encontrar un equilibrio.
Al elegir la prioridad, el Cliente esencialmente decide qué tan rápido quiere que se procese. Pueden procesarlo más o menos instantáneamente, o establecer la tarifa a un nivel más bajo para que se procese en un momento en que la demanda y las tarifas sean más bajas.
Tenga en cuenta que todavía hay un límite en cuanto a qué tan bajo puede establecer la tarifa el Cliente. Debajo de eso, se eliminaría y se devolvería un error al Cliente.
También debería ser posible que un Cliente actualice un gasto pendiente, para que no se quede atascado allí si las tarifas y la demanda se mantienen en un nivel más alto.
Resumen
Entonces, para redondear, la idea básica es que gastar un DBC puede resultar en muchos DBC de salida. Cuando enviamos una solicitud a los Ancianos para gastar un DBC, también adjuntamos esos resultados.
Luego, los Ancianos verifican la cantidad y continúan con el procesamiento del gasto.
El lector observador habría notado que la tarifa pagada a un anciano está en un DBC, y cuando el Anciano quiere gastar este DBC, entonces necesitaría una tarifa para gastarlo, y si eldos son iguales…entonces no tienes…nada?
Así es exactamente como es. Y así, si recordamos que el algoritmo de precios devuelve valores más bajos cuanto más grande es la red, podemos ver que hay una especie de efecto lock-in + madrugador. A medida que disminuye el valor nominal de una tarifa, las tarifas pagadas anteriormente serán cada vez más “accesibles”.
Aquí es también donde ayuda la cola de prioridad. Las tarifas que se recibieron durante cargas altas podrían cobrarse y volver a emitirse cuando las tarifas sean más bajas. Otro factor que trabaja para nivelar la carga.
Espero que eso les dé a todos una idea bastante clara de lo que se está gestando.
Enlaces útiles
- Sitio web de red segura
- Introducción a la red segura
- Aspectos básicos de la red
- Hoja de ruta
- Glosario
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.