Esta es una traducción automática. El original en inglés está aquÃ: Update 13 April, 2023
¿Alguien con ganas de una inmersión más profunda?
Hace un par de semanas, @oetyng nos actualizó sobre los diseños de una red de pagos y cómo podrÃa funcionar de forma independiente.
Con la pila tecnológica de la Red ahora avanzando a un ritmo que no podÃamos prever hace quince dÃas, nos hemos dado la libertad y la flexibilidad para buscar una variedad de vÃas para el lanzamiento, ya sea una red solo de pagos o para la red de datos completa desde el primer momento.
Entonces, @oetyng está revisando el mundo de los pagos para explicar cómo se está integrando con el almacenamiento, las billeteras y las API de los clientes en el nuevo diseño simplificado.
Primero, una palabra sobre cómo se perfila la red a medida que pasamos del diseño de las secciones a Kademlia. Kademlia requiere que los nodos se comuniquen entre sà en toda la red, en lugar de solo en su sección. Si no lo hicieran, la tabla de enrutamiento pronto se volverÃa obsoleta y estarÃa llena de nodos inactivos y la red morirÃa por un grave caso de falta de comunicación. Verificar los padres de DBC es una forma de garantizar constantemente que los nodos estén activos y al mismo tiempo cumplir una función vital, por lo que podemos duplicarnos allÃ.
Las transacciones se realizarán muy rápido en la red, pero Safe no es una base de datos y no es adecuado para mutaciones rápidas de datos. Ese tipo de trabajo se realiza del lado del cliente, y luego los resultados se almacenan/replican en Safe. Los CRDT significan que los clientes pueden colaborar de manera efectiva, en tiempo real y sin conflictos, y los resultados de esas colaboraciones se pueden almacenar de forma pública o privada en Safe para la posteridad. El traslado a Kademlia aclara esta división del trabajo.
Otro resultado del cambio es que es poco probable que las redes de prueba pequeñas sean estables. Es probable que el nuevo diseño necesite 2000 o más nodos para funcionar correctamente. Esto no es un problema en absoluto, pero obviamente cambiará la forma en que ejecutamos las redes de prueba.
Progreso general
A medida que avanzamos hacia la posibilidad de lanzar algo para el consumo público, Jim está trabajando en el posicionamiento, las hojas de ruta y los mensajes. Eche un vistazo a su hilo Qué es el lanzamiento si aún no lo ha hecho.
Con ese dÃa a la vista, @bzee ha estado investigando NAT transversal y cómo podemos implementarlo, y @bochaco está preparando nuestros tipos de datos para la integración en la nueva infraestructura de red, incluido el trabajo en API para permitir que los desarrolladores comiencen a usar aplicaciones lo antes posible. como tenemos algo estable. Bochaco también está analizando los mensajes de error, viendo dónde podemos hacerlos más especÃficos y útiles.
El otro gran trabajo es clasificar grupos cercanos. Dado el nombre de un fragmento de datos (igual que su dirección XOR), el cliente sabe qué nodos k pedir para recuperarlos, pero ¿debemos comenzar con 20 o algo más como 8? Más significa que más nodos actualizan sus tablas de enrutamiento, pero también son más mensajes. ¿Qué pasa cuando estamos almacenando DBC? Esto es algo en lo que @roland y @qi_ma se están ocupando. @roland también está revisando la replicación de datos.
Por supuesto, necesitamos poder ver lo que está pasando, y @Chriso ha refactorizado la implementación de OpenSearch en el repositorio de testnet para dar paso a la configuración de monitoreo.
Y @oetying está empezando a unir todas estas cosas. ¡Más de él abajo!
DBC, transferencias y monederos
Simplificación del código DBC
En las últimas semanas, el código DBC experimentó una simplificación necesaria durante mucho tiempo. Hubo más documentación y una pequeña revisión de la terminologÃa, alineando nombres y conceptos para reducir la carga cognitiva.
Otra cosa que podÃamos hacer ahora, ya que ya no tenemos secciones ni Ancianos, era eliminar la firma de red de los DBC. Eso por sà solo es una simplificación masiva. Lo que tenemos ahora es que una transferencia se puede construir completamente fuera de lÃnea, y todo lo que necesita hacer es enviar las partes del DBC, llamadas gastos firmados (es decir, la clave correspondiente a una identificación de DBC, firmado el gasto de ese DBC, entonces, el remitente de tokens firmó el gasto). Cuando suficientes pares en la red han aceptado estos gastos firmados, la transacción se completa y es válida.
Gastar DBCs en la red (transferencias o pagos de datos)
Entonces, para retroceder un poco.
En lugar de pedir a los Ancianos de una sección que validen y firmen un gasto (es decir, una transferencia o un pago de datos), como se hacÃa anteriormente, ahora enviamos los gastos firmados por el cliente al grupo cercano de la identificación del DBC para gastar. (Lo llamamos la dirección. Entonces, los fragmentos tienen una dirección, los registros tienen una dirección y los gastos de DBC tienen una dirección). Este grupo cercano ha sido mencionado antes. Los compañeros del grupo cercano no firman nada. Simplemente validan el gasto, cada uno de ellos actuando de forma independiente, y lo almacenan si lo encuentran válido. Parte de encontrarlo válido es buscar los padres de tal gasto. Eso significa buscar los gastos que llevaron a la creación de este mismo DBC que ahora se está gastando.
Si esos gastos principales se pueden recuperar de su grupo cercano respectivo, eso significa que son válidos, ya que ellos mismos se sometieron a tsu proceso de vuelta cuando se gastaron.
Por supuesto, hay más validaciones, como la verificación de cantidades ciegas para entradas y salidas, que las claves de los dbc de entrada lo hayan firmado todo correctamente, y asà sucesivamente.
Y cuando todo eso se ha confirmado como válido, un par simplemente almacena ese gasto firmado. Y cuando un cliente debe verificar si el DBC que obtuvo es válido, solo le pide a la red que devuelva los gastos firmados que llevaron a la creación de ese DBC. Si el número requerido de pares lo devuelve, entonces es un hecho.
Cerrar grupos
Entonces, un grupo cercano. Recuerde que se encuentran por cercanÃa a la identificación del DBC (o el hash de datos). Pueden ser 4, 8, 16 compañeros o más. Comenzaremos con un número y ajustaremos a medida que avancemos. Pero hay más. Podemos agregar capas mediante el hash de la identificación/nombre y obtener una nueva dirección que se deriva de forma determinista de la primera. Ahora también podemos almacenar el mismo artÃculo en este grupo. Y asà puede continuar, codificando esa dirección una y otra vez, y cada vez tener otro grupo sosteniendo el artÃculo.
Estas son algunas de las palancas que se han mencionado antes. Comenzaremos de manera simple con un solo grupo, porque primero solo queremos que esto funcione en una red de prueba.
Carteras
Acabamos de terminar la primera implementación simple de una billetera que contiene DBC y un historial de transacciones. Al igual que con los datos, la primera iteración usa almacenamiento en memoria. A continuación, lo almacenará localmente en el disco, y luego haremos el almacenamiento en red. Lo bueno es que estamos implementando la billetera para que tenga una interfaz simple que se pueda usar con cualquiera de los tres (o todos) los medios de almacenamiento mencionados anteriormente.
Lo que también se ha tenido en cuenta esta vez es que todos los compañeros deberán tener una billetera para sus recompensas. Pero aún no hemos llegado allÃ, una semana o dos más para eso. (Y sÃ, ahora es mucho más sencillo hacer estimaciones de tiempo).
Tasas de transferencia
Estos se describieron muy recientemente en una actualización, y no ha cambiado mucho allÃ. Los pagos van a los nodos y la cola de prioridad (anteriormente llamada mempool) es la misma.
Lo que probablemente veremos un poco antes es cómo se puede aplicar el mismo patrón para los pagos de datos.
Y ese es usted al tanto del progreso de las transferencias y pagos por ahora.
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.