Ich würde sagen, dass hier eine Reihe von Problemen im Spiel sind. Wenn das System "offline" ist, müssen Sie die Salden nur aktualisieren, was zuletzt gespeichert wurde. Die Annahme hier ist, dass beide Quellen vertrauenswürdig sind und das System in der Mitte vertrauenswürdig ist. Könnte es genauso gut zu einem zentralisierten asynchronen System machen. Sie hätten zu diesem Zeitpunkt weitaus mehr Kontrolle und sind weniger auf Tools von Drittanbietern angewiesen.

Das vorgeschlagene System wäre „nett“, aber eine Lösung in der Zwischenzeit wäre die Entwicklung eines internen Ledgers. Sie kennen Partei A und Partei B. Sie kennen ihre Salden und vertrauen ihren Transaktionen. Dieses System geht davon aus, dass Sie auch ihre Schlüssel kennen oder sie bei Bedarf erhalten können.

Basierend auf dem letzten Kontostand speichern Sie Ihre Transaktionen in einer normalen DB. Laufende Bilanz, wiederum basierend auf den neuesten Informationen. Wann immer der Knoten eine Verbindung herstellen kann, aktualisieren Sie die aktuellen Salden (vertrauen, aber verifizieren), überprüfen Sie alle früheren Transaktionen, die Sie möglicherweise eingereicht haben, auf Fehler (Gasmangel, unsachgemäße Transaktion, Geldmangel usw.) und verarbeiten Sie dann die Transaktionen.

Wenn es A -> B- und B -> A-Transaktionen gibt, können Sie die Transaktionssalden intern auflösen (vorausgesetzt, dies ist für das beabsichtigte Recht zulässig). Andernfalls können Sie alle Arten von Logik einsetzen, um jede Transaktion aufzulösen. Zusammenfassen:

1. Verwenden Sie ein internes System, um zu verfolgen, was was ist. Was wurde bezahlt, was muss bezahlt werden.
2. Wenn der Knoten eine Verbindung herstellt, erhalten Sie so viele Informationen wie möglich. Aktueller Kontostand, bestätigte Transaktionen aus früheren Einreichungen, Transaktionen, die noch auf Bestätigung warten. Identifizieren Sie Transaktionen, die aus irgendeinem Grund völlig fehlgeschlagen sind (dies setzt eine kurze „Betriebszeit“ für die Verbindung mit dem Knoten voraus. Er würde nicht lange genug verbunden bleiben, um zu sehen, dass Transaktionen den ersten Block erreichen), und sich immer noch im Mempool befinden (nicht genug Gas, um abgeholt werden und veralten) usw.
3. Prozess basierend auf den obigen Informationen. Transaktionen werden letztendlich abgeschlossen oder nicht abgeschlossen. Ein FIFO kann verwendet werden, um die ältesten Transaktionen aufzulösen, oder wenn die ideale Situation darin besteht, die größte Anzahl von Transaktionen unabhängig vom Alter zuerst aufzulösen, kann eine große Transaktion zurückbleiben, während viele andere Transaktionen erledigt werden.

Dies alles ist eine Frage der Balance zwischen „Vertrauen“ und „Timing“. Wenn ich 2 Brieftaschen besitze und ich der einzige mit den Schlüsseln bin, könnte ich jede Transaktion in einem Backend-System ausführen, das nachverfolgt, was „es sein sollte“, und es auflösen, wann immer ich will.

Der bereitgestellte Vorschlag ist ein Gleichgewicht zwischen verfügbarer Technologie (und Umständen), Sicherheit und Genauigkeit.

Dies kann durch die Verwendung von Bluetooth/NFC-Konnektivität mit einer einzigartigen Wallet (muss für beide Seiten gleich sein) erreicht werden, die in der Lage ist, verschlüsselte Offline-Transaktionen zu speichern, ohne sie tatsächlich mit der Blockchain zu synchronisieren. Auf der Zahlungsseite müssen die anfänglichen Mittel jedoch aus dem Kauf und der Synchronisierung mit der Blockchain stammen.

Das Lightning-Netzwerk befindet sich meines Wissens nach noch in der Konzeptphase. Es gibt noch Probleme zu lösen, insbesondere in Bezug auf die mögliche Irreführung des Systems zu der Annahme, dass Sie eine Zahlung von jemandem erhalten haben, der sie NICHT tatsächlich gesendet hat – indem Sie eine (echte) vorherige Transaktion wie bei „Man in the Middle“ wiederholen.