Re: Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

Mike Hearn

Naïve question: If A doesn’t want B and C to know about each other, couldn’t you just use anonymous identities?




Re: JIRA. The only public JIRA board is CORDA-* as far as I know. The CID board is for “Corda Ideas” and is where people put whatever ideas or requirements they come up with. It’s not triaged work.


W.R.T. “super-transactions”, I’d rather we didn’t. A transaction has a precise definition – it is an atomic unit of change. Duplicating that concept into a larger construct would confuse and complicate things enormously. Suddenly every part of the system would have to consider a “transaction that committed but didn’t kind of didn’t because it was part of a super-transaction”. Ponder how that’d ripple through every aspect of the system, creating weird edge cases and security bugs when people inevitably forget about it (ordinary databases don’t have such a concept as far as I know). Our data model is already quite complicated and if we were to introduce a new data model now, we’d probably go for simplification rather than elaboration.


The requirement that is quoted in this thread is actually a privacy requirement, not an atomicity requirement. The problem is that Corda transactions act as privacy boundaries, beyond their traditional use as atomicity boundaries. We have many privacy techniques that can satisfy this requirement:


  • As Shams points out, confidential identities (note that this API isn’t really finished or stable though!)
  • SGX


Either would work here. There’s no need for new concepts in the data model.




Join to automatically receive all group messages.