Thank you for the commentary!
The architecture diagram if really rough and it was rushed — my excuses for confusing parts. But we also overlooked some IBC capabilities in the intermediate TEE-based desigh.
You’re right - ABCI++ arrow was there because the initial idea was to implement ABCI++ methods such that the validation of a state change in Entropy will depend on state of Namada. So in a way when I drew it I had a picture of an ad hoc, informally-specified, slow implementation of half of IBC in my head. Funds locking was supposed to be done via some escrow account on Namada controlled by Entropy or something similar. I haven’t realized that we could just use IBC.
Exacltly. After tokens moved to Entropy from Namada all state lives there.
In this design proposal the mechanism is as follows:
a note: My knowledge of IBC is limited - so please point out wrong assumptions or use of terms if there are any : )
- A set of Namada users bridge part of their tokens to Entropy.
- Bridged tokens can be used in WoT (web of trust) based routing or participate in multi-lateral clearing (Entropy+CoFi) or in con-currency payments. For that users have to do payment requests inside Entropy to other bridged accounts or to issue IOUs.
- Once in a while (how frequently is to be determined) users can apply the state change to Namada. Or as you rightfully pointed out moved to any other IBC enabled chain.
An example: user A and B bridged some of their tokens from accounts Aⁿ and Bⁿ to Entropy accounts Aⁱ and Bⁱ. If there was a payment P of from Aⁱ to Bⁱ through WoT within Etropy and B wants to withdraw the gained amount back to Bⁿ then A can only withdraw (Aⁱ - P) back to Aⁿ and B can withdraw (Bⁱ + P).
There is also a concern about the privacy guarantees - does this link to state changes in Entropy in any way breaks the MASP privacy? What happens if the TEEs are compromised? Will it lead to a partial disclosure of Namada balances information (statements like “A had at least Aⁱ tokens on Namada”)? We will look into those.
This is not clear at the moment. For a WoT enabled payment network it makes sense to solve per payment request (that could be an intent). People expect payments to go through immediately. So if we speaking the same mechanics as CirclesUBI where a “solved” payment invokes a cascade of pairwise transitive exchanges along the trust paths, then we need to run max-flow for each payment. Which is not the case for obligation clearing applications, where invoices are just placed into a pile for periodical clearing (solving) that cancels big batches of payments at once.
A frequency of confidential max-flow instant payments could be too high for future Taiga based approaches. In this scenario I think we could explore ways to reduce frequency by grouping nodes into dense trust clusters where participants are expected to balance out to zero over time. We can then do less frequent MTCS style clearing, and, only do per request solving when payments cross boundaries of those clusters. This makes more sense with Kudos because density of trust clusters doesn’t necessarily reflect the frequency of transactions. But I’m just throwing ideas here.
Or did you mean that because we run CometBFT consensus we’ll need to validate a bunch of transactions that will be committed to a block and it might have an effect on the overall behavior of the system? I’m not sure I got what you refereed to by batching right.
I think this formulation is again the result of that we failed to take into the account that IBC already provides what we need. The way you understood the system initially is in sync with ours : )