Date   
Re: Mobile corda node

Mike Hearn
 

Hey Janis,

 

There are some people doing a project related to mobile cash with Corda – perhaps they’ll introduce themselves on the list. I think they are using the RPC client approach.

 

There’s an incremental path here that looks a bit like this:

 

  1. Sample app that shows how to authenticate to a Corda node, start flows and monitor them from an Android app, how to hook the ProgressTracker into the UI and so on. Also how to proxy the connections on the server side to the node. Docs showing how it all works. Not hard.
  2. Maybe a Bitcoin wallet style app for cash-on-ledger, of course, not really useful unless there are actual issuers but might be a fun demo. Still just an RPC client to a cloud node.
  3. Implement the human interaction design docs (see other thread with Tomas) and make an app that knows how to sign transactions with keys held in the local keystore, knows how to assist users with backing them up etc. Make phones into tx signing devices.
  4. Want to run a node on your phone? Yes, there’s a path to getting there:
    1. Add support for Android SQLite in addition to H2 as a database backend, optimise the hell out of it - node startup is way too slow for Android currently mostly because of Hibernate. Turn the node into a library (again… that’s how it started life).
    2. Allow personal identity certs. Probably a case of defining an X.500 schema for the production Corda zone that allows phone number or email address based identities, and teaching the main zone how to verify phone numbers using SMS/phone calls. Backwards compatibility needs to be considered.
    3. Improve DoS resistance. Currently Corda has non-member-on-member DoS attacks in scope but not member-on-member. There’s an implicit assumption hidden in the “run Corda on mobiles” requirement that you can scale the large numbers of consumer users sharing a zone with highly sensitive business nodes. We’d probably need to ramp up the defences before that makes sense.
    4. Attack and solve the Corda/mobile network messaging problem. See below. After these things are done, now it becomes actually feasible to run a first class Corda node on your phone. At this point we could truly say the Corda network has become a P2P network of the same level of openness and scale as email, the web, etc.

 

Node-to-phone messaging can be done in several ways.

 

The ’best’ way in the absence of carrier policies would be to exploit Corda’s tolerance to node outages. If your mobile network supports IPv6 and lets you open ports, you can simply have a background task on the phone that checks your assigned IPv6 address every so often and pushes a new entry to the network map when it changes. If your address changes as you roam, nodes elsewhere on the network will fail to connect and messages will start to buffer up on their disks, with backoff-and-retry. This is how all Corda nodes work already, it’s nothing new. If your address is stable enough and direct connectivity is possible, this is an efficient and simple way to do things. For instance if your device spends most of its time on wifi to consumer internet connections (like at home) you’re good.

 

But of course most networks are broken / NATd / firewalled and won’t let devices take part in p2p networks. That might change one day – with IPv6 it’s no longer a strong technical impediment but rather, ‘just’ a matter of security policies. It doesn’t really benefit any of the big players to be routing so much traffic through Google and Apple datacenters, not even Google or Apple – it’s a pure cost center for them. Direct routing when possible as an optimisation is in everyone’s interests, so it may happen eventually.

 

Still, today you need an alternative.

 

The most effective way would be to implement end to end encryption in the wire protocol, and allow identity keys to sign “proxy permissions” that grant third parties the right to announce themselves as the owners of your identity in the network map. A simple implementation would receive messages and forward them onto the Google/Apple store-and-forward networks (GCM). Nodes would open outbound connections directly. A mobile node could then generate keys, register its phone number as its identity WhatsApp style, and proceed to start receiving and sending messages. The OS wakes up the node when a message arrives on a flow and is waiting to be processed.

 

thanks,

-mike

www.r3.com/email-disclaimer

Mobile corda node

Olekss, Janis
 

Hi,

 

Talking on Slack about the subj. Joe suggested to ask here.

What are development around mobile (android) Corda nodes.

From Slack I found there are 2 possible path of research at this moment.

 

  1. Lightweight RPC Android client connecting to cloud node and doing stuff
  2. Running actual node on the phone, and being part of the network
    1. Problems of node going on-off grid each time you put it in pocket
    2. Limited resources (don’t want to kill your battery while signing transaction)

 

What’s happening, what are findings, any good code to steal? Some android plugins?

 

Me myself planning (without big commitment) to try my hands getting dirty for the sake of running electricity through my CPU

 

Janis




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com

Design docs / Markdown / doc restructuring

Mike Hearn
 

Doc restructuring. I’ve restructured the left hand navbar to be split into four sections:

 

https://docs.corda.net/head/

 

  • Development
  • Operations
  • Design docs
  • Participate

 

I haven’t done a deep re-org of the current content, but the idea is that now we have a stronger division of sections it’ll encourage improvements to our operational documentation.

 

Design docs. The design documentation for open source features are currently in the tech white paper, or in various miscellaneous wiki pages and discourse posts that need to be gathered together. This is messy. The tech white paper is a useful one-stop-shop to learn about the platform design at a high level, and it’ll stick around for that purpose (updating it is on my todo list). But we have a lot of features that are incidental, or are of a level of detail that wouldn’t help readers of the tech wp. So this new section is useful for these, along with things like alternatives considered.

 

The design docs I just moved into the docsite are, for now, features that only appear in our Enterprise edition (not released yet, but we’re hard at work on finishing the first version). There’s no particular reason for this – it’s just that we happened to start using git and markdown to gather design docs instead of wiki pages around the same time we started work on enterprise features. As we gather info  from other places it’ll become a mix of design docs for open and proprietary features, so it’s an ongoing project.

 

This approach is pretty unconventional – why are we exposing detailed design thinking for a commercial product alongside the docs for its open source version? We went back and forth on this and eventually concluded it was better to be as open as possible. The major key ideas of Corda are all given away for free anyway, so the difference between our enterprise edition and the open source version is primarily in better execution rather than ‘secret sauce’. As our users are mostly working in industry, and tend to have very detailed opinions about infrastructure design, it makes sense to just work closely with people on enterprise features too. That way we’re less likely to have requirements mismatches when people want to deploy. Also sometimes features may migrate from enterprise to open and then we’d need to publish the design docs anyway.

 

Markdown. The design docs are written in Markdown not ReStructured Text, for historical reasons (the previous state didn’t have them be published in any part of the website beyond github). As part of this work I’ve activated support for Markdown in the docsite. Markdown files in the docs build can embed RST directives like “.. note::” or “.. toctree::” – however, please be aware:

 

  • We should probably restrict Markdown to the design docs section. Let’s keep using RST for the rest of the site.
  • Sphinx converts Markdown to RST at build time automatically, this is why you can mix and match in a flexible way but has the disadvantage that line numbers in error messages are all wrong. To debug, enter the virtualenv and run “m2r path/to/my/file.md” – the rst file will be put in the same directory and you can then examine the conversion.
  • Because it’s being converted to RST on the fly, Sphinx is pickier about markup correctness than a normal Markdown parser is. It will still whinge if you unbalance your nesting levels, if you unbalance your asterisks etc. This is one reason why it’s probably not worth trying to convert the whole site or anything, even though Markdown is in some ways a more convenient syntax.

 

 

www.r3.com/email-disclaimer

Re: User interaction

Mike Hearn
 

Hi Tomas,

 

Your utility code sounds very interesting! It’d be excellent to get it out into the open if your management doesn’t mind. If you like, we could stash it under the experimental directory of the Corda codebase (code in this part of the tree doesn’t have to go through code review). Or it could be a separate repository that you retain management of. Up to you.

 

Stefano has done some experimental work on a layer on top of Corda that auto-generates a lot of the boilerplate that’s needed when working with specifically just linear states that evolve in predictable ways. (Un)fortunately he ended up working with an important/high priority customer instead so that work got parked, but we may try to unpark it at some point. The idea is, it generates a class that looks kind of like a normal object. You can make normal method calls on it inside flow context, and behind the scenes, it’ll create a transaction to make that change, distribute it to the right participants and so on. Almost a bit like the Ethereum programming model except that it’s backed by the ordinary UTXO-style Corda ledger.

 

Obviously there are limits to what you can implement that way – fungible assets in particular don’t map that well to object oriented programming, but for states that just want to track a single data structure over time, it should be easier.

 

It sounds like your approach is somewhat related, so comparing notes would be great. In particular the FSM specification sounds interesting, maybe we can combine forces somehow.

 

There is this one year old proposal about "Human task integration": https://discourse.corda.net/t/human-task-integration/1083

Are there any updates for this proposal?

 

Not really, although I’ve been doing some more expansive thinking on the topic over time.  I’ll jot down some notes here.

 

The proposal you link to is essentially a small set of independent upgrades to make flows more useful. The idea is that flows will be able to pose users questions and get back answers, using ordinary imperative constructs like loops and branches to beat the user into submitting valid data before the flow proceeds to try and sync up with other organisations.

 

Tradle (Gene Vayngreb) has done some good work on the UI side of this. https://github.com/tradle/bots is an open source framework for chat-style interactions that also support embedding straightforward dialog-box style question and answer prompts, ability to upload and download attachments and so on. I’m not totally convinced by AI driven natural language chatbots as the future of business, but a rich chat-log style UI for structured interactions, developed at lower cost than traditional web form style UI - I totally buy that. There’s no particular reason why all business logic must be driven via web forms and it’s often easier not to. For instance, many web apps struggle to handle the back button correctly. A log-style UI framework would assist developers in controlling back edges in the workflow graph.

 

Chat-log UIs fit very naturally into the notion of Corda flows. We can easily imagine an API like this:

 

val location = sendAndReceive<WorldCoordinate>(

     humanIdentity,

“Hello poxy flesh-being, tell me where you would like to ship your bananas”,

RequestStyle.MAP

)

var sure = false

while (!sure) {

     sure = sendAndReceive<Boolean>(humanIdentity, “Are you sure?”, YesNoButtons)

}

 

in which the UI framework handles the details of letting the user navigate an embedded Google Map with search to select a place, and the flow sleeps until it’s done.

 

Of course the original suggestion of adapters to bridge to ticket systems and the like are still valid.

 

There’s a fundamental thing here, which is that in your utility code the current state of the user interaction is stored as an actual ledger state. Whereas in the vision I outlined above it isn’t, instead the state is opaque data stored inside a checkpoint.

 

Flow checkpoints have a few attributes that deserve further examination:

 

  1. They are very easy to use – almost too easy, in fact, often the first time developers become fully conscious the mechanism is there is when it goes wrong somehow 😊
  2. But they don’t survive upgrades to flow code well, or sometimes at all.
  3. And they aren’t processable or analyzeable in any way.
  4. Because of (3) they are ephemeral. They aren’t meant to be stored, logged or kept long term. Checkpoints are erased when no longer needed. A checkpoint that lives more than a few days probably indicates something has gone wrong. They exist only to make the node robust to restarts and outages of peer nodes.
  5. Again because of (3) flows have a notion of a progress tracker to expose human readable information about where they got up to. They can also use ordinary logging frameworks, of course.

 

The sort of human interaction I’ve been imagining is entirely within an organisation. The other side doesn’t know what’s going on in detail. They just know they’re waiting for a response. Therefore, the limits of checkpoints and flows don’t matter much – if you do need to communicate some sort of “Your request has been picked up and is being worked on” progress information then you can define custom messages for that.

 

The sort of human interaction you’ve implemented is different – the progress of a thing being authorised is itself sharable on-ledger data. You pay a higher programming and storage cost to get that, but it has some advantages.

 

I’d be interested in getting more thoughts from the community on this whole design space. If flows were extended with the ability to send messages to/from people, if we had an ultra-low cost way to develop interactional UIs via Tradle-style chat UX, and if we enhanced the flow framework a bit more, would things like status tracking migrate off-ledger or are there other factors driving this? Do you really need the overhead of a full ledger transaction for this use case?

 

thanks,

-mike

www.r3.com/email-disclaimer

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?

 

Yep.

 

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.

 

Thanks,

-mike

 

 

www.r3.com/email-disclaimer

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

Shams Asari
 

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

 

From: <corda-dev@groups.io> on behalf of "joel.dudley via Groups.Io" <joel.dudley@...>
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Monday, 14 May 2018 at 11:04
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Re: Where to raise feature request - Was: Re: [External] [corda-dev] Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

 

Warzek – You’re right, that’s an internal board. Here’s the requirement:

 

Suppose you have two sets of state transitions that you want to occur atomically:

 

·         Party A wants to accept a successful bid from Party B

·         Party A wants to reject an unsuccessful bid from Party C

 

Party A only wants the first set of state transitions to happen if the second happens, and vice-versa. It therefore needs to commit both sets of transitions atomically.

This can be achieved by placing all state transitions in the same transaction. However, this is sometimes undesirable for privacy reasons. For example, Party A may not want Party C to know that Party B also bid.

We need a mechanism for ensuring these state transitions occur simultaneously, without compromising this privacy requirement.

 

Joel

 

From: <corda-dev@groups.io> on behalf of "joel.dudley via Groups.Io" <joel.dudley@...>
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Monday, 14 May 2018 at 09:46
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Re: Where to raise feature request - Was: Re: [External] [corda-dev] Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

 

Wawrzek – I thought that was a public JIRA! Let me investigate.

 

Re: the `MultipleNotaryFlow` - To be clear, this would require installing the flow on the notary side, as well as on the client side, so this solution couldn’t be implemented unilaterally if you didn’t control the notary. Additionally, you’d have to think carefully about error handling in the flow if you request a multiple-notarisation from a notary that doesn’t support it.

 

From: <corda-dev@groups.io> on behalf of "Wawrzyniec Niewodniczanski via Groups.Io" <wawrzekn@...>
Organization: R3
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Monday, 14 May 2018 at 09:41
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Where to raise feature request - Was: Re: [External] [corda-dev] Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

 

On 14/05/2018 09:32, joel.dudley via Groups.Io wrote:

Joel, Mike,

[...]

For the benefit of community I'm going to ask it here:



This is a feature request that has come up a few times before. See https://r3-cev.atlassian.net/browse/CID-340.

Why is the Open Source feature kept in private Jira ticket? It doesn't look right for me. It seems that the right place is in GitHub. What do you think?

Cheers,
Wawrzek

--

Dr Wawrzyniec (Wawrzek) Niewodniczański | R3. | DevOps Lead
2 London Wall Place, 12th Floor, | London, EC2Y 5AU
O: +44 207 113 1460 | M: +44 7917-44-79-88 |
wawrzek@... . www.r3.com

www.r3.com/email-disclaimer

www.r3.com/email-disclaimer

www.r3.com/email-disclaimer

www.r3.com/email-disclaimer

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

joel.dudley@...
 

Warzek – You’re right, that’s an internal board. Here’s the requirement:

 

Suppose you have two sets of state transitions that you want to occur atomically:

 

·         Party A wants to accept a successful bid from Party B

·         Party A wants to reject an unsuccessful bid from Party C

 

Party A only wants the first set of state transitions to happen if the second happens, and vice-versa. It therefore needs to commit both sets of transitions atomically.

This can be achieved by placing all state transitions in the same transaction. However, this is sometimes undesirable for privacy reasons. For example, Party A may not want Party C to know that Party B also bid.

We need a mechanism for ensuring these state transitions occur simultaneously, without compromising this privacy requirement.

 

Joel

 

From: <corda-dev@groups.io> on behalf of "joel.dudley via Groups.Io" <joel.dudley@...>
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Monday, 14 May 2018 at 09:46
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Re: Where to raise feature request - Was: Re: [External] [corda-dev] Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

 

Wawrzek – I thought that was a public JIRA! Let me investigate.

 

Re: the `MultipleNotaryFlow` - To be clear, this would require installing the flow on the notary side, as well as on the client side, so this solution couldn’t be implemented unilaterally if you didn’t control the notary. Additionally, you’d have to think carefully about error handling in the flow if you request a multiple-notarisation from a notary that doesn’t support it.

 

From: <corda-dev@groups.io> on behalf of "Wawrzyniec Niewodniczanski via Groups.Io" <wawrzekn@...>
Organization: R3
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Monday, 14 May 2018 at 09:41
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Where to raise feature request - Was: Re: [External] [corda-dev] Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

 

On 14/05/2018 09:32, joel.dudley via Groups.Io wrote:

Joel, Mike,

[...]

For the benefit of community I'm going to ask it here:


This is a feature request that has come up a few times before. See https://r3-cev.atlassian.net/browse/CID-340.

Why is the Open Source feature kept in private Jira ticket? It doesn't look right for me. It seems that the right place is in GitHub. What do you think?

Cheers,
Wawrzek

--

Dr Wawrzyniec (Wawrzek) Niewodniczański | R3. | DevOps Lead
2 London Wall Place, 12th Floor, | London, EC2Y 5AU
O: +44 207 113 1460 | M: +44 7917-44-79-88 |
wawrzek@... . www.r3.com

www.r3.com/email-disclaimer

www.r3.com/email-disclaimer

www.r3.com/email-disclaimer

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

joel.dudley@...
 

Wawrzek – I thought that was a public JIRA! Let me investigate.

 

Re: the `MultipleNotaryFlow` - To be clear, this would require installing the flow on the notary side, as well as on the client side, so this solution couldn’t be implemented unilaterally if you didn’t control the notary. Additionally, you’d have to think carefully about error handling in the flow if you request a multiple-notarisation from a notary that doesn’t support it.

 

From: <corda-dev@groups.io> on behalf of "Wawrzyniec Niewodniczanski via Groups.Io" <wawrzekn@...>
Organization: R3
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Monday, 14 May 2018 at 09:41
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Where to raise feature request - Was: Re: [External] [corda-dev] Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

 

On 14/05/2018 09:32, joel.dudley via Groups.Io wrote:

Joel, Mike,

[...]

For the benefit of community I'm going to ask it here:

This is a feature request that has come up a few times before. See https://r3-cev.atlassian.net/browse/CID-340.

Why is the Open Source feature kept in private Jira ticket? It doesn't look right for me. It seems that the right place is in GitHub. What do you think?

Cheers,
Wawrzek

--

Dr Wawrzyniec (Wawrzek) Niewodniczański | R3. | DevOps Lead
2 London Wall Place, 12th Floor, | London, EC2Y 5AU
O: +44 207 113 1460 | M: +44 7917-44-79-88 |
wawrzek@... . www.r3.com

www.r3.com/email-disclaimer

www.r3.com/email-disclaimer

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

Wawrzyniec Niewodniczanski
 

On 14/05/2018 09:32, joel.dudley via Groups.Io wrote:

Joel, Mike,

[...]

For the benefit of community I'm going to ask it here:

This is a feature request that has come up a few times before. See https://r3-cev.atlassian.net/browse/CID-340.

Why is the Open Source feature kept in private Jira ticket? It doesn't look right for me. It seems that the right place is in GitHub. What do you think?

Cheers,
Wawrzek
--

Dr Wawrzyniec (Wawrzek) Niewodniczański | R3. | DevOps Lead
2 London Wall Place, 12th Floor, | London, EC2Y 5AU
O: +44 207 113 1460 | M: +44 7917-44-79-88 |
wawrzek@... . www.r3.com

www.r3.com/email-disclaimer

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

joel.dudley@...
 

Thanks both.

 

This is a feature request that has come up a few times before. See https://r3-cev.atlassian.net/browse/CID-340.

 

@Janis – I’d imagine this would be multiple transactions, rather than some “meta-transaction”. It’s just that you’d gather signatures for several different transactions at once, and then send them to the notary at once. In effect, you’d need a `FinalityFlow` constructor like:

 

    class FinalityFlow(

            val transaction: Set<SignedTransaction>,

            private val extraRecipients: Set<Party>,

            override val progressTracker: ProgressTracker)

 

And you’d need to adapt the `NotaryFlow.Client` accordingly.

 

On the other end, the notary would have to provide a responder flow that only commits the transactions if every transaction does not represent a double-spend attempt.

 

It should also be straightforward to write this flow yourself, not as an extension of `FinalityFlow`, but as a brand new flow (called `MultipleFinalityFlow` or something). You could continue to rely on `SendTransactionFlow` to distribute the notarised transactions. You’d just need to install `MultipleFinalityFlow` on each node that wants to request the notarisation of multiple transactions at once, and a responder on each notary that needs to handle multiple transactions at once.

 

Joel

 

From: <corda-dev@groups.io> on behalf of "Olekss, Janis" <janis.olekss@...>
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Monday, 14 May 2018 at 07:13
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Re: [External] [corda-dev] Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

 

Hi,

 

As I can’t comment on StackOverflow, responding here.

 

I think Corda needs to be very careful about such possibilities.

Remember, that with transactions, where we have participants, we assume that participants knows the drill and signs or rejects based transactions they know everything they need to know.

 

But what with these “clumped trasnactons”.

It is some kind of meta-transaction, how you will share the participant knowledge and responsibility.

 

It will be funny to be part of transaction which you accept, but you would reject it if you would know that there is another transaction you are participant, you are rejecting.

 

Remember – being part of transaction is implicit right to prevent others of tetting goodies 😊

 

Janis

 

From: corda-dev@groups.io [mailto:corda-dev@groups.io] On Behalf Of kid101
Sent: Monday, May 14, 2018 07:38
To: corda-dev@groups.io
Subject: [External] [corda-dev] Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

 

Posting on request of Joel to groups.io.

Feature request: Finality Flow to take in multiple signed transactions as input, so either all the transactions are accepted or rejected.

This will help in creating Transactions in Corda.

Initially requested here in the comments

 



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com

www.r3.com/email-disclaimer

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

Olekss, Janis
 

Hi,

 

As I can’t comment on StackOverflow, responding here.

 

I think Corda needs to be very careful about such possibilities.

Remember, that with transactions, where we have participants, we assume that participants knows the drill and signs or rejects based transactions they know everything they need to know.

 

But what with these “clumped trasnactons”.

It is some kind of meta-transaction, how you will share the participant knowledge and responsibility.

 

It will be funny to be part of transaction which you accept, but you would reject it if you would know that there is another transaction you are participant, you are rejecting.

 

Remember – being part of transaction is implicit right to prevent others of tetting goodies 😊

 

Janis

 

From: corda-dev@groups.io [mailto:corda-dev@groups.io] On Behalf Of kid101
Sent: Monday, May 14, 2018 07:38
To: corda-dev@groups.io
Subject: [External] [corda-dev] Finality Flow to take multiple Transactions as Input that are either committed or rejected all together

 

Posting on request of Joel to groups.io.

Feature request: Finality Flow to take in multiple signed transactions as input, so either all the transactions are accepted or rejected.

This will help in creating Transactions in Corda.

Initially requested here in the comments




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com

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

kid101
 

Posting on request of Joel to groups.io.

Feature request: Finality Flow to take in multiple signed transactions as input, so either all the transactions are accepted or rejected.

This will help in creating Transactions in Corda.

Initially requested here in the comments

Corda open-source community update

richard@...
 

Hi everybody,

 

I hope you’re all having a good weekend – and for those of you heading to Consensus this week, I hope to meet as many of you as possible. Let me know if you’ll be around. And if you are in New York, do make sure you sign up to the Corda NYC meetup on Tuesday, at which Kostas (he of the world’s best zero-knowledge proof live demo   ) will be presenting: https://www.meetup.com/New-York-Corda-Meetup/ 

 

Anyway – I just published a blog post highlighting a lot of the stuff that’s going on in our community right now. It’s really humbling. Many of you on this mailing list are leading this work so I wanted to share it with you: https://medium.com/@gendal/corda-open-source-community-update-f332386b4038

 

Richard

 

ps we want corda-dev to be all signal, no noise… if you’d prefer I didn’t send not-strictly-related-to-corda-development emails like this to the list, let me know… I won’t be offended.

 

Richard G Brown R3| Chief Technology Officer

2 London Wall Place | Floor 12 | London | EC2Y 5AU

M: +44 7764 666821 | T: @gendal

richard@... . www.r3.com

www.r3.com/email-disclaimer

Re: New co-maintainer: Joel Dudley

kid101
 

Congratulations! Joel.

Re: Data base connectivity architecture

Mike Hearn
 

Whether we retain the custom SQL, which applies only to the finance Cash contract, is still an open question.  The generic vault function tryLockFungibleStatesForSpending

doesn’t have custom SQL and is portable, I believe.  Which is more efficient depends on the amount of contention for states (coins) vs. how many states are needed to fulfil a spend (or rather, the variability of the number of states required.  More testing of scenarios required!

It’s not exactly specific to the finance app, it’s more that we haven’t quite refactored all the fungible asset code out of finance and generalised it into the core system yet. Roger is planning to look at this. The original idea was always that the core system would treat all fungible assets identically, and in the finance/core split that wasn’t quite kept everywhere. But it’s not hard to fix.

www.r3.com/email-disclaimer

Re: Data base connectivity architecture

Rick Parker
 

Whether we retain the custom SQL, which applies only to the finance Cash contract, is still an open question.  The generic vault function tryLockFungibleStatesForSpending

doesn’t have custom SQL and is portable, I believe.  Which is more efficient depends on the amount of contention for states (coins) vs. how many states are needed to fulfil a spend (or rather, the variability of the number of states required.  More testing of scenarios required!

 

From: Mike Hearn <mike@...>
Date: Friday, 11 May 2018 at 10:21
To: "corda-dev@groups.io" <corda-dev@groups.io>
Cc: Rick Parker <rick.parker@...>
Subject: Re: [corda-dev] Data base connectivity architecture

 

We do have database testing infrastructure internally. This sort of thing boils down to lots of scripts and little tools that are very specific to our setup. It’s not product-ized at all.

 

The incompatibilities are things like obscure table name limitations, queries that “work” but trash performance if they aren’t configured right and so on. ANSI SQL is a very leaky abstraction. Our original hope was that databases could be plugged in by end users on demand, but enough things broke each time we tried it that we backed away from that. Now we do nightly regression and performance test runs against each supported database to flush out issues.

 

Rick is currently reworking coin selection. The current DB query is deadlock prone when run in parallel. We talked about not using the custom query anymore, but then again doing it in the DB does have some advantages. I’m not sure where we ended up with that – Rick?

www.r3.com/email-disclaimer

Test cases for State machine flows/ E2E samples

somasundaram.radhakrishnan@...
 

Hi Experts,

Am a beginner in the Corda platform. Can you please point me to tests for the Two party asset transfer flow described in https://docs.corda.net/flow-state-machines.html 

https://docs.corda.net/flow-testing.html deals with a different scenario. Documentation seems to deal with a separate scenario for each topic. 

I am looking for a sample with end to end code including contracts, states, transactions, flows and test cases, invoking from API etc.. So, if there is an end to end flow sample for one single scenario that will be helpful. 

Thanks for the help in advance,
Som

Re: Data base connectivity architecture

Mike Hearn
 

We do have database testing infrastructure internally. This sort of thing boils down to lots of scripts and little tools that are very specific to our setup. It’s not product-ized at all.

 

The incompatibilities are things like obscure table name limitations, queries that “work” but trash performance if they aren’t configured right and so on. ANSI SQL is a very leaky abstraction. Our original hope was that databases could be plugged in by end users on demand, but enough things broke each time we tried it that we backed away from that. Now we do nightly regression and performance test runs against each supported database to flush out issues.

 

Rick is currently reworking coin selection. The current DB query is deadlock prone when run in parallel. We talked about not using the custom query anymore, but then again doing it in the DB does have some advantages. I’m not sure where we ended up with that – Rick?

www.r3.com/email-disclaimer

User interaction

Tomas Tauber
 

Hi everyone,

There is this one year old proposal about "Human task integration": https://discourse.corda.net/t/human-task-integration/1083
Are there any updates for this proposal?
As the interim solution, the current approach is to split the actions into self-contained flows + commands and track the interaction status in states (I guess ideally in LinearStates for looking up history / audit trails of actions): https://stackoverflow.com/a/45866675

For these use cases (e.g. document drafts and approvals among multiple parties), we wrote some simple utility code:
* We have a “StatusTrackingContractState” generic interface which requires a “status” attribute (could be a boolean flag, but I guess preferably an enum class or a sealed class) and a method that maps “roles” (that are recorded somewhere in that state) to parties.
* For contract state classes that implement this interface, we can specify possible transitions in a finite state machine fashion: who (i.e. which role) can execute which commands from what status to what statuses.

Using that specification, we have code that gives us two things for free:

1) Basic generic verification for contract code: checks that input and output states have their statuses according to the specification and that transactions are signed by parties of required roles.
2) Generating PUML diagrams for visualisation / documentaiton.

If anyone is interested in this code, I could possibly ask our CTO whether we can open source it.

Has anyone written any similar utility code for this stuff?

Cheers,

 
Tomas Tauber | Senior Engineer
CryptoBLK Limited  I  Revolutionize IT with Cryptography and Blockchain

Re: Data base connectivity architecture

Rohit
 

Is there a way to get a idea of what these SQL incompatibilities may be beyond ANSI SQL?  Is there a template of SQL queries generated that can be tested against a database to assess compatibility?  A regression test suite perhaps?  If one actually provides a SQL engine, as we do on Hadoop (Apache Trafodion and EsgynDB), then we could get an assessment of the changes we would need to make in order to support Corda.  We do support Hibernate.

 

Rohit

 

From: corda-dev@groups.io <corda-dev@groups.io> On Behalf Of Charles Monteiro
Sent: Thursday, May 10, 2018 10:27 AM
To: corda-dev@groups.io
Subject: Re: [corda-dev] Data base connectivity architecture

 

Joel, if you don’t mind :) , can I pls answer ?

 

The answer is that no its not possible to just add any database that would be ordinarily pluggable under Hibernate, there are issues related to specific sql that used proprietary H2 features, as well as I’m told inconsistencies encountered in testing. Therefore , the answer is that the databases supported via Enterprise Corda are:

 

oracle

sql server

azure sql server

postgres

 

--
Charles Monteiro

CTO

Datasoft


On May 8, 2018, 4:40 AM -0400, Mahesh Govind <mahesh@...>, wrote:

 



Dear Experts,

 

Could you please help me to understand database connectivity architecture for corda .(I was able to run corda with postgres) . I would like to try other databases . Is it enough to add the database driver as a gradle dependency and try connecting to other databases ?

 

regards

Mahesh


 

--

Co-Founder - Digiledge

+91 9591810218