Liquidación de transacciones fuera de línea

Caso de uso

Mi caso de uso es en torno a un escenario en el que tanto el cliente como el comerciante poseen billeteras fuera de línea con un saldo que ha tenido confirmación en la cadena de bloques.

  1. Para empezar, digamos que las billeteras del comerciante y del comprador muestran saldos de 20 BTC y 10 BTC respectivamente. Estos saldos son los que se confirman en la cadena de bloques.
  2. Luego, deje que haya múltiples transacciones entre el comerciante y el comprador de modo que el saldo siempre se actualice localmente solo en las billeteras.
  3. Todas las transacciones, en 2 arriba, ocurren en un modo fuera de línea; es decir, sin acceso a la red. El período de no acceso puede durar días.
  4. En algún momento, en el futuro, cuando una o ambas billeteras estén en línea, todas las transacciones fuera de línea se publicarán en blockchain y se confirmarán.

Sincronización de cadena de bloques

Hay dos cosas que pueden suceder en este punto.

Primero, las billeteras son tan seguras que todas las actualizaciones (créditos y débitos) ocurren localmente sin tener que 'sincronizarse' con la cadena de bloques. La única vez que las billeteras pueden sincronizarse con blockchain es para publicar las transacciones y su secuencia; y, también para actualizar su billetera con los créditos que pasaron desde la última vez que la billetera estuvo en línea. O bien, la presión regulatoria requiere la publicación de datos de transacciones con cada frecuencia establecida.

En segundo lugar, todas las actualizaciones de crédito se realizan en las billeteras a través de la cadena de bloques. Este requisito es motivación suficiente para buscar conectividad de red; incluso si es una vez a la semana o menos.

Pregunta

En cualquier caso, estamos ante un escenario en el que un valor, confirmado por blockchain, se utiliza en transacciones fuera de línea para confirmarse en línea más tarde. ¿Cómo implementamos esto?

Analogía

Los conductores de autobuses pueden emitir boletos con una máquina fuera de línea a los pasajeros que abordan el autobús en varios puntos a lo largo del viaje. Cuando el autobús llega a su destino, la máquina se utiliza en el depósito para llegar a una lista de billetes vendidos y el importe recaudado de los mismos. Por lo tanto, este es un ejemplo de una transacción fuera de línea donde las transacciones se 'liquidan' cuando la 'conectividad' finalmente está disponible.

Engendrado en: https://bitcoin.stackexchange.com/a/41356/6975

Esto se parece mucho a la forma en que se implementa la red de rayos. relámpago.network
¿Puede por favor elaborar? Leí su pdf aquí: lightning.network/lightning-network-summary.pdf Mi punto clave es que dos billeteras, que tienen saldos que pueden ser corroborados por el libro mayor, pueden ejecutar transacciones sin tener que conectarse a la red nuevamente. Una vez conectados, obtienen/publican retroactivamente sus transacciones en el libro mayor y también actualizan sus billeteras. Creo que Lightning Network es una especie de depósito en garantía.
Entonces, lo que se necesita es un método para exportar/importar transacciones firmadas en el mempool directamente, sin pasar por los mecanismos de transmisión. Una buena idea. Debería considerar discutir esto en [bitcoin-dev] o publicarlo bajo el encabezado de funciones en GitHub .
Además, incluso si una parte decide no conectarse nunca o abandonar las transacciones antes de que se transmitan, el nodo de la otra parte debe ser capaz de retener y transmitir las transacciones sin haberlas descartado previamente.
@willtech exactamente mi punto (¡Sobre una fiesta que nunca se conecta)! ¿Cómo quiere decir mempooly omitir la transmisión?
Puedo crear una transacción incluso sin conexión con Bitcoin Core. Esa transacción está en el mempool. Por lo general, cuando un nodo está en línea, transmite transacciones a otros nodos, que también se reciben en el mempool de esos nodos. Todo lo que se requiere es una exportación de transacción que proporcionará texto sin formato de la transacción firmada en un extremo y una función de importación en el otro extremo. Cada parte puede intercambiar transacciones fuera de línea y cuando cualquiera de las partes se conecta, todas las transacciones deben transmitirse.
Esto significa que las transacciones importadas deberán recibirse en el mempool con reglas especiales para que nunca se eliminen. Por lo general, una transacción se elimina del mempool después de un período de tiempo, pero generalmente se espera que la transacción se confirme antes de esto.
La analogía es pobre: ​​las transacciones se liquidan cuando el cliente recibe el boleto y el operador recibe el pago. Las transacciones simplemente se cuentan cuando la caja de tarifas regresa al depósito. Esa es una gran diferencia. En primer lugar, nunca hay un saldo negativo que pueda afectar al cliente como resultado de la sincronización del libro mayor fuera de línea con el libro mayor principal, a diferencia de los cheques en papel rebotados. En segundo lugar, no hay forma de resolver la discrepancia entre los boletos contados en el depósito y los boletos realmente vendidos (algunos podrían haberse perdido, destruido, etc.). Además: fuerte motivador para la subnotificación (los conductores pueden robar la diferencia).

Respuestas (2)

Yo diría que hay una serie de problemas en juego aquí. Si el sistema está "fuera de línea", entonces la única actualización que tendrá que hacer para balancear es lo que se almacenó por última vez. La suposición aquí es que ambas fuentes son confiables y el sistema en el medio es confiable. También podría convertirlo en un sistema asíncrono centralizado. Tendría mucho más control y menos dependencia de herramientas de terceros en ese momento.

El sistema propuesto sería "bueno", pero mientras tanto una solución sería desarrollar un libro mayor interno. Conoce a la parte A ya la parte B. Conoce sus saldos y confía en sus transacciones. Este sistema asume que también conoce sus claves o que puede obtenerlas según sea necesario.

Basado en el saldo más reciente, almacene sus transacciones en una base de datos normal. Equilibrio actual, de nuevo basado en la información más reciente. Siempre que el nodo pueda conectarse, actualice los saldos actuales (confíe pero verifique), verifique si hay fallas en las transacciones anteriores que haya enviado (falta de gasolina, transacción incorrecta, falta de fondos, etc.), luego procese las transacciones.

Si hay transacciones A -> B y B -> A, entonces podría resolver los saldos de transacciones internamente (suponiendo que sea legal para lo que se pretende). De lo contrario, puede poner todo tipo de lógica para resolver cada transacción. Para resumir:

  1. Utilice un sistema interno para rastrear qué es qué. Lo que se ha pagado, lo que hay que pagar.
  2. Cuando el nodo se conecte, obtenga tanta información como pueda. Saldo actual, transacciones confirmadas de envíos anteriores, transacciones que aún están esperando ser confirmadas. Identifique las transacciones que fallaron rotundamente por cualquier motivo (esto supone un breve "tiempo de actividad" para la conexión con el nodo. No permanecería conectado el tiempo suficiente para ver las transacciones llegar al primer bloque), todavía sentado en mempool (no hay suficiente gas para ser recogido y quedar obsoleto), etc.
  3. Proceso basado en la información anterior. Las transacciones finalmente serán resueltas o no resueltas. Se puede usar un FIFO para resolver las transacciones más antiguas, o si la situación ideal es resolver la mayor cantidad de transacciones primero, independientemente de la antigüedad, entonces una transacción grande puede atrasarse mientras se atienden muchas otras transacciones.

Todo esto es cuestión de lograr un equilibrio entre "confianza" y "tiempo". Si tengo 2 billeteras, y soy el único con las llaves, podría ejecutar cada transacción en un sistema de back-end rastreando lo que "debería ser" y resolviéndolo cuando quiera.

La sugerencia proporcionada es un equilibrio entre la tecnología disponible (y las circunstancias), la seguridad y la precisión.

"La suposición aquí es que ambas fuentes son confiables y el sistema en el medio es confiable". La confianza proviene del saldo confirmado en la cadena de bloques. No estoy seguro sobre el sistema en el medio. El quid de esta pregunta es eliminar el sistema central (como se menciona en esta respuesta).
Mi respuesta y suposición se derivan de "Primero, las billeteras son tan seguras que todas las actualizaciones (créditos y débitos) ocurren localmente sin tener que 'sincronizarse' con la cadena de bloques". Para mí, eso significa que la confianza se puede derivar sin la interacción de la cadena de bloques. Si este no es el caso, la confianza siempre se reduce a cero si no puede enviar primero a la cadena y confirmar que la transacción es válida porque la criptografía ya se puede gastar en otro lugar. Por lo tanto, esto solo funciona con la confianza implícita de ambas fuentes de que los fondos no se gastarán mientras este sistema esté fuera de línea.
Espera, creo que entiendo tu punto. Está diciendo que las billeteras no pueden interactuar fuera del nodo, por lo tanto, pueden hacer sus negocios en este nodo sin sincronizarse con el resto del mundo. Casi como un libro de contabilidad interno. Me estaba acercando a esto como una forma para que 2 billeteras confiables resolvieran transacciones y usaran la cadena de bloques como un registro "final". Así que creo que entiendo lo que pretendes ahora. En total, debido a la necesidad de confirmar que una transacción es válida, no veo cómo se puede lograr esto sin una confianza extrema y/o un proceso de resolución establecido por una autoridad central.
"Casi como un libro mayor interno". ¡Bingo! Lo sé, esto se está estirando mucho. Por lo tanto, la otra opción de actualizaciones cuando la conectividad está disponible.

Esto se puede lograr mediante el uso de conectividad Bluetooth/NFC con una billetera única (debe ser la misma para ambos extremos) que sea capaz de almacenar transacciones fuera de línea cifradas sin sincronizarlas con Blockchain. Sin embargo, en cuanto al pago, los fondos iniciales deben provenir de la compra y sincronización con la cadena de bloques.

La red Lightning todavía está en etapa de concepto, hasta donde yo sé. Todavía hay problemas por resolver, especialmente con respecto a la posibilidad de engañar al sistema para que crea que recibió el pago de alguien que en realidad NO lo envió, al repetir una transacción anterior (real) como en "man in the middle".

No creo que bitcoin se ejecute en bluetooth o incluso en cualquier billetera que exista permita hacerlo
Liquidación de transacciones fuera de línea
RespuestasAquíPolítica de privacidad1y, 0v