feat: invent ledger-agnostic SQL/DSL

[petermetz]

Is your feature request related to a problem? Please describe.

This is a moonshot feature not something that we have a clear idea on how to implement or even if it should be implemented (could be a massive undertaking for no actual gain in the end, hence the moonshot label above).

Describe the solution you'd like

I want to be able to say something like

Use case: End users Lennon and Skyler perform an atomic swap between their wallets across ledgers A and B, trading (some arbitrary) pair of coins X and Y where the exchange rate is (conveniently) 1 exactly.

The syntax is just some pseudo code I made up on the fly, but you can probably see that it is basically the classical SQL syntax.

The example is a classical one from traditional RDBMS' textbooks where they teach you how important the all-or-nothing semantics of atomic transactions through an example of balance transfers in the classical financial universe.

BEGIN TRANSACTION;

# Reduce Skyler's X balance by 1000
UPDATE  "Ledger_A"."COIN_X_BALANCES" 
  SET BALANCE = BALANCE - 1000
  WHERE ACCOUNT_ID = "SKYLER_ACCOUNT_ID"

# Increase Lennon's X balance by 1000
UPDATE  "Ledger_A"."COIN_X_BALANCES" 
  SET BALANCE = BALANCE + 1000
  WHERE ACCOUNT_ID = "LENNON_ACCOUNT_ID"

# Reduce Lennon's Y balance by 1000
UPDATE  "Ledger_B"."COIN_Y_BALANCES" 
  SET BALANCE = BALANCE - 1000
  WHERE ACCOUNT_ID = "LENNON_ACCOUNT_ID"

# Increase Skyler's Y balance by 1000
UPDATE  "Ledger_B"."COIN_Y_BALANCES" 
  SET BALANCE = BALANCE + 1000
  WHERE ACCOUNT_ID = "SKYLER_ACCOUNT_ID"

COMMIT TRANSACTION;

Describe alternatives you've considered

Considered doing with without SQL/DSL and we likely will end up doing that first as well since doing what's described in this issue as a moonshot due to it's likely very high difficulty as we'd have to implement our own SQL parser, query planner, etc, not even mentioning the fact that there will be compatibility issues among the different ledgers (which is where most ORM libraries fall short as they try to provide a sensible common interface for databases that are sometimes conceptually different from each other)

Additional context

https://wiki.hyperledger.org/display/cactus/2020-11-12+Meeting+notes?focusedTaskId=1

cc: @RafaelAPB @takeutak @sfuji822 @jonathan-m-hamilton

[petermetz]

A cool paper where something similar was implemented (complexity/effort required is off the charts though) https://arxiv.org/abs/1908.09343

[RafaelAPB]

One more paper defining such interface: https://www.iaas.uni-stuttgart.de/publications/Falazi2020_SCIP-Smart-Contract-Invocation-Protocol-SCIP-A-Protocol-for-the-Uniform-Integration-of-Heterogeneous-Blockchain-Smart-Contracts.pdf

Canton does have a somehow similar scheme, via DAML - https://www.canton.io/publications/canton-whitepaper.pdf

I believe this ledger-agnostic SQL-based DSL is useful when, for example, one needs a provably-secure Cactus deployment. I would say that some solutions would need this, while others would benefit from a greater degree of flexibility.

[petermetz]

@RafaelAPB Agreed, 100% and thanks for adding more, interesting items to my reading list, I'll skim these ;-)