Foto de Pavan Trikutam en Unsplash.
En las bolsas clásicas, primero debe hacer un depósito en la cuenta de la bolsa y luego negociar. Decidimos agregar este tipo de depósito para hacer tratos rápidos durante el día. Esto permitirá a los comerciantes realizar miles de transacciones por día. Al mismo tiempo, nuestra plataforma no tendrá más del 5% del total de depósitos en cada cuenta de depósito en HMW, esto es para minimizar los posibles ataques a la infraestructura de de la bolsa de intercambio del SEBC. También servirá como evidencia de que nuestro intercambio no podrá controlar los depósitos de nuestros clientes.
Para mantener la descentralización, agregamos una transacción pendiente. Bajo tal transacción, uno de los participantes realiza un depósito para la transacción utilizando HMW, y el segundo cumple con las condiciones de la transacción, después de lo cual recibe los fondos depositados.
Considere un ejemplo de una transacción en el ejemplo de comprar 1 ETH por $ 100. El vendedor 1 ETH tiene en depósito el monto reservado para la transacción. El comprador recibe los detalles para la transferencia de p2p, por ejemplo, de tarjeta a tarjeta. Después de confirmar la transferencia, la cantidad de 1 ETH se transfiere al comprador. En esta etapa, podría haber posibles disputas entre las partes de la transacción. Para resolver tales situaciones, hay una sección de "Conversaciones" en el intercambio del SEBC, que le permite intercambiar mensajes entre las contrapartes de la transacción. Si la disputa no se puede resolver, se agrega un moderador a la conversación.
Un problema natural en tal situación es la confianza entre las partes. Para ello, todos los mensajes de la conversación serán confidenciales. Hemos desarrollado nuestro propio sistema de correspondencia confidencial basado en las curvas elípticas de las teclas ETH de la cadena de bloques.
Foto de Haley Lawrence en Unsplash
Dicho canal de comunicación funciona de la siguiente manera simplificada:
Bob y Alice tienen cada una dos teclas: abierta, que se usa para generar la dirección ETH de la billetera y cerrada, que se usa para firmar transacciones. En la etapa de formación de un nuevo canal de comunicación, Bob genera un nuevo par de teclas, público y privado (identidad), y encripta este canal de identidad con la clave pública de Alice. En esta etapa de la base de datos para dos contrapartes, existe un canal de identidad encriptado con la clave pública para Bob y Alice. Esto proporciona un canal confidencial para su comunicación. Para enviar un mensaje, Bob descifra con su clave privada el canal de identidad. Codifica el mensaje con la clave pública del canal de identidad y lo envía. Alice y Bob usan la clave privada del canal de identidad para leer todos los mensajes en un canal confidencial.
Si el proceso de la transacción requiere asistencia para resolver la disputa. Luego, Bob o Alice pueden invitar a otros participantes al grupo a través del siguiente mecanismo.
Una de las partes, por ejemplo, Alice, presiona el botón – para invitar al moderador a la conversación. El canal de identidad se cifra en el navegador de Bob con la clave pública del moderador y se registra en la base de datos. El moderador descifra la clave privada de El canal de identidad y puede utilizar un canal confidencial de comunicación con las partes en la transacción.
Si en el curso de la transacción es necesario proporcionar pruebas en forma de imágenes u otros archivos de medios, están codificados por el canal de identidad y se registran en ipfs. Dichos archivos pueden obtenerse mediante un código hash por cualquiera que lo tenga. Pero tales archivos solo pueden ser descifrados usando el canal de identidad.
Las ventajas de tal esquema para construir un canal de comunicación confidencial:
Solo se utilizan las claves de cifrado disponibles en el navegador del usuario. Esto elimina un ataque de hombre medio. Todos los datos se envían a través de cifrado de extremo a extremo. La generación de un canal de identidad no requiere la participación de la parte del servidor o cualquier otra parte, como es el caso en el algoritmo https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchangeIdentity El canal se almacena en un Forma encriptada para cada participante en una conversación confidencial. Esto elimina la posibilidad de su filtración al piratear la base de datos. La capacidad de agregar un número ilimitado de participantes en la conversación. La buena velocidad de codificación y decodificación de mensajes, ya que se utiliza un canal de identidad para todos los mensajes y archivos en una conversación confidencial. Para cada canal de comunicación, se forma un nuevo canal de identidad, por lo que si un canal de identidad se filtra, es imposible leer otros canales.
La única desventaja posible de este esquema de construcción:
En caso de una filtración de la clave privada de uno de los participantes en una conversación confidencial, ya que es posible leer todos los mensajes en el canal. No es posible utilizar el rendimiento del servidor para una búsqueda. Cualquier búsqueda de cadena se puede realizar solo en el lado del cliente, pero debido a cada transacción en la creación de un nuevo canal, la longitud de los datos para una búsqueda será limitada.