Date   
One node in multiple business networks, one BNO running multiple business networks

alex.koller@...
 

Hi

 

Over the last couple of months I’ve been using the Business Networks Membership Service cordapp (aka BNMS, aka membership service) and I think it’s great. It’s got some very neat features like a very easy way of preventing non-members from initiating members’ flows, membership metadata and more. Although this is just a reference implementation of the ideas behind business networks I struggle to see a reason why anybody would be writing their own implementation. Well, maybe one… It doesn’t support one node being in multiple business networks.  And along with that it also doesn’t support one node being the BNO to multiple business networks.

Ivan is making some initial steps towards addressing the former but I would like to open a broader discussion about how we actually do this. And if we can also address one BNO running multiple networks whilst at it then great!

 

 

Quick recap of the BNMS as of now:

 

  1. It allows a node to join the business network
  2. It allows a node to query who the other members on the business network are
  3. It allows blocking the execution of an initiated flow if the initiating party is not a member of the business network

 

You see the assumption of there being *the* business network. It’s the business network that’s configured in the membership-service.conf file.

 

I suggest we extend that config file (and consequently the BNMS cordapp) so that it works with the following structure. My config file could for example look like this:

 

business-networks = [

              {

                      id="O=Mega BNO,L=London,C=GB":"Gold Trading"

                      alias="Trading_Gold_Group"

                      package="com.megasoftwareprovider.goldtradingapp"

              }

              {

                      id="O=Mega BNO,L=London,C=GB":"Coal Trading"

                      alias="Trading_Coal_Group"

                      package="com.megasoftwareprovider.coaltradingapp"

              }

              {

                      id="O=Another BNO,L=New York,C=US":"Insurance"

                      alias="Insurance_Group"

                      package="com.megasoftwareprovider.insuranceapp"

              }

]

 

This file lives in my node's cordapps directory and it makes my BNMS app aware of three business networks. Two of them are run by “Mega BNO”, one by “Another BNO”.  Let’s take a closer look at the meanings of those fields in the config:

 

  • id – uniquely identifies the business network by the BNO’s CX500 name and the name of the business network they run. This will allow the BNO to run multiple business networks.
  • alias – this is how *I* want to refer to the business network in my operations (e.g. when triggering flows working with a business network, such as GetMembersFlow
  • package -  this allows me to associate a cordapp to a business network. The BNMS already comes with convenience BusinessNetworkAwareFlows that are meant to be extended by people writing their cordapps. Thus these convenience flows are aware of which cordapp they are running on behalf of by looking at this.javaClass. We can let that information drive which business network the cordapp operates within by associating package names and business networks. This will allow us to cut down on the number of times the alias has to be used.

 

So when it comes to the above three use cases, what will change for me?

 

  1. When joining a business network I use the alias as an argument when calling RequestMembershipFlow. The BNMS will make sure I join the right network.
  2. When querying who the other members are I again use the alias as an argument to GetMembersFlow
  3. When writing a flow XYZFlow extending from BusinessNetworkAwareFlows I simply make sure that the package containing XYZFlow is mapped to the right network in the config file and I know my cordapp will run against that network without having to do anything else


Having a reliable, strong, standard implementation of the BNMS should allow the community to build more business network related services on top of this.

 

Please let me know your views.

 

Alex Koller

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

M: +44 7857 759 318

alex.koller@... | www.r3.com | www.corda.net

Corda digital asset/tokens design proposal out for comment

Roger Willis
 

Hello everyone!

 

We’ve just held a design proposal review on the topic of modelling financial types on Corda, otherwise known as tokens and digital assets. Our objective is to present a model which can meet the needs of all digital asset / tokens use-cases and provide a toolkit for developers to build CorDapps using widely accepted standards. The design already builds on excellent input from our community, in particular, from the team at Chorum who wrote Cordite.

 

What is all this about?

We believe Corda is the natural platform choice for those that wish to issue and transact tokens. I’m part of a team tasked to make this as easy as possible to do on Corda. Here’s some background reading to provide more context:

 

·         Security tokens: the third blockchain revolution

·         Asset Tokenisation: An idea whose time has come… but not for the reasons you might expect (Richard Gendal Brown)

·         The Emergence of Enterprise Tokens (Todd McDonald)

 

What are we sharing?

We do our design work in public and are happy to share with you the design for comment. You can access it here. The design is a work in progress and is expected to evolve based upon feedback. Once implemented, the design will form the basis for tokens standards on Corda as well as an SDK for building token based CorDapps. It builds on the foundations of the existing finance module and offers greater flexibility with the introduction of:

 

·         A new FungibleState type (See definition here)

·         A new StatePointer type (See design doc and explanation here)

 

The tokens work also relies on the reference states feature which will be released in Corda V4. More information on reference states can be found here. Lastly, for those interested in how we plan to facilitate the dissemination of token reference data, please have a look at a data distribution groups prototype. The code is a cursory implementation of clubs as described in section 12 the Corda Whitepaper.

 

On another note; last week we open sourced some code that implements a fiat currency “stable coin” issuer. You can find commentary here and code here. The CorDapp integrates with the Monzo and Starling bank APIs to create an automated cash issuer - it’s quite cool! We wrote a design document to explain how it all works.

 

Why does it matter?

As more projects incorporate tokens as a part of their solution, the possibility for design divergence appears. One of the greatest advantages for Corda and its ecosystems of users is the ability to move assets between applications and users. Standards will help CorDapp developers - building everything from gold tokens to corporate bonds – to remain on the same page.

 

What are we looking for?

We want your input. Where does this work? Where does it break? Tell us about your project, which needs the design addresses, and where we have gaps.

 

What can you expect from us going forward?

We intend to publish standards for tokens and digital assets on Corda, implement the tokens SDK and provide a selection of demos, documentation and samples.

 

How can you get in touch?

Either reply here or email digital.assets@....

 

Roger Willis R3.

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

M: +44 753 090 5454 | T: @roger3cev
roger.willis@... . www.r3.com

 

Connect with R3 ecosystem participants, discover solutions built on Corda, and access expertise on Marketplace.

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

Mike Hearn
 

OK, fair enough. I started thinking about how apps could customize node configuration by merging in app-specific config but that doesn’t work conceptually – apps don’t have any ordering defined between them so there’d be no way to decide a merge order.

 

As Stefano said, that’s a simple change, and the annotations/naming issue is handled already. So let’s do that and document that startFlow(A::class) might not actually start A if there’s a deeper subclass available.

 

W.R.T. letting users override the entire flow, that’s always possible because “call” is public, so they can replace the whole thing, or alternatively run the superclass using super.call() to tack extra logic to the start and end. But ideally people are using tighter protected methods, to avoid protocol deviations using the type system.

 

 

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

Stephen Houston
 

Hi Mike,

With regard to the config issue, the problem isn't setting us having defaults and assuming using that in the case where the customer forgets or breaks their own configuration, it's making it as simple to manage as possible for the many different deployment environments that we see the product being deployed in. We really want to make it as simple for them to manage as possible, so if they build another JAR that they then deploy to Corda, which overrides our default flows, then ideally that should be enough. If they also have to manage a configuration file in the API layer, and remember to update it with their new flows, then that's another point where the product can break. If it could be eliminated for the majority of cases (e.g. by walking down the hierarchy of InitiatingFlows to find the one at the furthest hops/most concrete implementation) as per the recent change to the Responder flows, then that would be ideal. Our customers just have to manage their own JAR, and not configuration files in other places.

I get what you're saying about having specific extension points in the flow rather than sub-classing the whole InitiatingFlow. It's a fair point as it means the default (BNO supplied) flow can operate a particular way, then have controlled extensions. Where our thinking was, was that the default implementation would be the standardised approach that could be tailored/modified by the customer to the extent that it could do something quite different to what we had originally intended, but as long as it used the same states that the Responders expect, then that would be ok. It also allows for a flow to be completely overridden (what if we didn't put an extension point in at a point where the customer needed to add some additional logic for example).

No, we don't currently see the need for the Responder flow to know the name of the sub-class. If both sides were aware of the sub-class, then they would have presumably sub-classes/created new InitiatingFlow/InitiatedBy implementations and we (from a BNO) wouldn't need to be involved.

So I think (some of) the options are:

  • Authors of InitiatingFlows are responsible for ensuring enough extension points exist, sub-classes must not have the @InitiatingFlow annotation, exact flow to be used must be specified by the client of the RPC (no changes required on Corda here)
  • As above, but with the flow with the furthest hops being found (requires a similar change to the one that was put in for Responders)
  • Allow the InitiatingFlow to be completely replaced by a sub-class, passing the parent's name so that it can be picked up by the Responder flow
  • Modify @InitiatedBy so that it can work with an Interface instead of just a Class. Allow CorDapps to specify that their concrete implementation of the Interface either replaces the default implementation (shipped in a different JAR).
Steve

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

Mike Hearn
 

For the config file issue, good config file libraries allow multiple files to be merged together. So you can allow user customisations on top of your default config, that can’t be overwritten:

 

https://github.com/lightbend/config#merging-config-trees

 

W.R.T. the responding flow knowing it’s talking to a sub-class: is that useful? What would it do with that information? The point of using inheritance for customization here is to ensure that sub-classed flows speak the same protocol as the superclass, that is, the intention is that well designed flows call protected methods at various points to allow extensions but don’t allow sub-classes to fundamentally alter the protocol itself. Given that the sub-class is presumably some internal thing that nobody else knows about, it wouldn’t make sense for the other side to look for it by name.

 

So is it an issue?

 

Mental note: the docsite should discuss how to design flows for sub-classing and how to use OOP patterns to ensure the subclasses can’t alter the over-arching protocol.

 

 

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

Stephen Houston
 

Hi Mike, Stefano,

This is something that we have been interested in for a while now, and it can be broken down into two parts, Invoking the flow and Knowing which flow to respond to.

When it comes to Invoking the flow, yes, it would be possible for the client of the RPC connection to specify the exact flow name that should be used. We could make the name of each flow a configurable parameter in the API layer, and then the API could look up the specific class when invoking the flow. My concerns would be that during upgrades that the configuration file would not be properly maintained by each of the customers, leading to cases where they change back from their specific implementation flow, to the default one, simply because they went with our configuration file rather than their modified version.

I think that the bigger problem is knowing which flow to respond to. We will have default flows, then our customers have the option to extend these default flows with ones of their own creation. Obviously the responders to these flows do not know about the customised initiating flows (they contain business logic that is unique to each customer), so they won't know if they are responding to the default flow, or a sub-class of the default flow. While the solution above about not adding @InitiatingFlow to the sub-classes may work, it seems a little brittle to relying on someone leaving out the annotation. If someone added the annotation in, then I'd imagine that the sub-flow name is sent, rather than the parent?

Steve

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

Mike Hearn
 

So the situation is you can/will customize the cordapp in the node but not the UI layer. OK.

 

We could add rewrite rules to the config file as proposed. The alternative is that the web server itself should have a config file with rewrite rules.

 

The advantage of us doing it is that then UI developers can’t forget. On the other hand, flows must be designed to be sub-classed. Especially, in Kotlin, classes are final by default, so you have to take explicit action to allow customization – and that seems right. With Java it’s easier to just override and make changes the original author didn’t anticipate but of course that’s less robust. Protected/public methods are essentially a form of API so new versions can’t easily change them, if the intent was to allow customization.

 

Therefore, adding rewrite rules to the node config is only useful if someone intends their flow to be customized but then forgets to finish off that feature by allowing the web server to be repointed at new flows. Is that a case we want to support? I am a bit skeptical.

 

What we should do as part of this work is make sure the docsite discusses how to build extensible CorDapps. Probably with a new page on the topic.

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

richard@...
 

Not embarrassing at all..! I suspect a lot of people (myself included) learned something from this!

 

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

 

From: <corda-dev@groups.io> on behalf of "Stefano Franz via Groups.Io" <Stefano.Franz@...>
Reply-To: "corda-dev@groups.io" <corda-dev@groups.io>
Date: Tuesday, 23 October 2018 at 11:07
To: "corda-dev@groups.io" <corda-dev@groups.io>
Subject: Re: [corda-dev] Overriding Flows and Client Specific Implementations - Ideas needed.

 

Well this is embarrassing.

 

OK, so the @InitiatingFlow/@InitiatedBy section of the problem seems to have been largely solved by: FlowStateMachineImpl.getFlowVersionAndInitiatingClass

 

As Andras points out, if you are extending an initiating flow, as long as you do not place an @InitiatingFlow annotation, it will automagically work by navigating up the class hierarchy. Great.

 

Now, we are left with the issue of the RPC invocation. The use case I am imagining is as follows

 

  • I am a cordapp provider for a large BNO
  • I am a webapp provider for a large BNO.
  • One or more of my members has created a specific implementation of our Initiating flow

 

Without allowing rpc.startFlow to do a similar scan of available sub classes / override rules as with responding flows, the webapps will also need to be customized to invoke the specialized flow.

 

I agree that this is an optimization, and not critical - but it would make deploying larger BNO's a nicer experience.

 


From: corda-dev@groups.io <corda-dev@groups.io> on behalf of Mike Hearn via Groups.Io <mike@...>
Sent: 23 October 2018 11:04:12
To: corda-dev@groups.io
Subject: Re: [corda-dev] Overriding Flows and Client Specific Implementations - Ideas needed.

 

OK, so is anything actually required here, if we assume RPC clients can be changed conveniently enough?

 

We could recommend via the docs that if you’re making a generic tool for distribution to third parties, that you let them customize the name of any flows you invoke, so they can sub-class and customize the flow logic with their own CorDapp. It’d be a design pattern rather than a feature.

 

 

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

Stefano Franz
 

Well this is embarrassing.


OK, so the @InitiatingFlow/@InitiatedBy section of the problem seems to have been largely solved by: FlowStateMachineImpl.getFlowVersionAndInitiatingClass


As Andras points out, if you are extending an initiating flow, as long as you do not place an @InitiatingFlow annotation, it will automagically work by navigating up the class hierarchy. Great.


Now, we are left with the issue of the RPC invocation. The use case I am imagining is as follows


  • I am a cordapp provider for a large BNO
  • I am a webapp provider for a large BNO.
  • One or more of my members has created a specific implementation of our Initiating flow

Without allowing rpc.startFlow to do a similar scan of available sub classes / override rules as with responding flows, the webapps will also need to be customized to invoke the specialized flow.

I agree that this is an optimization, and not critical - but it would make deploying larger BNO's a nicer experience.


From: corda-dev@groups.io <corda-dev@groups.io> on behalf of Mike Hearn via Groups.Io <mike@...>
Sent: 23 October 2018 11:04:12
To: corda-dev@groups.io
Subject: Re: [corda-dev] Overriding Flows and Client Specific Implementations - Ideas needed.
 

OK, so is anything actually required here, if we assume RPC clients can be changed conveniently enough?

 

We could recommend via the docs that if you’re making a generic tool for distribution to third parties, that you let them customize the name of any flows you invoke, so they can sub-class and customize the flow logic with their own CorDapp. It’d be a design pattern rather than a feature.

 

 

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

Mike Hearn
 

OK, so is anything actually required here, if we assume RPC clients can be changed conveniently enough?

 

We could recommend via the docs that if you’re making a generic tool for distribution to third parties, that you let them customize the name of any flows you invoke, so they can sub-class and customize the flow logic with their own CorDapp. It’d be a design pattern rather than a feature.

 

 

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

Andras Slemmer
 

But can’t this be handled by just looking upwards through the class hierarchy looking for @InitiatingFlow and @StartableByRPC and then just use those names?

This is already happening for @InitiatingFlow, see SubFlow.create(). In othre words of you have


@InitiatingFlow
class Initiator : FlowLogic<String>
 
// No @InitiatingFlow
class IbmDB2SpecificInitiator : Initiator

then Initiator::class will be sent



From: corda-dev@groups.io <corda-dev@groups.io> on behalf of Mike Hearn via Groups.Io <mike@...>
Sent: Monday, October 22, 2018 4:56:45 PM
To: corda-dev@groups.io
Subject: Re: [corda-dev] Overriding Flows and Client Specific Implementations - Ideas needed.
 

Thanks Stefano.

 

If we allow users to customize their responding flows for different backends, surely the same is required for Initiating flows.

 

I guess I’m not entirely convinced about this point.

 

We want to allow people to override the default handling of inbound flows because we assume it’s way too much hassle to get your counterparties to all change to using the new name (requires editing apps, maybe changing what flow is used depending on counterparty etc).

 

But changing the flow name passed to an RPC is presumably much easier because it’s all within the same organization. The only time it’d be necessary is if you have so many programs using RPC and a particular flow name, that it’s totally impractical to change them all, or if you’re using a tool that is closed source and can’t be told what flow to use via configuration.

 

Now, if you sub-class an initiating flow to customize it, we still have the problem of the wrong name being sent. But can’t this be handled by just looking upwards through the class hierarchy looking for @InitiatingFlow and @StartableByRPC and then just use those names? That is, there’s nothing special about the sub-class at all, it’s just not annotated. You can then pass the subclass name via RPC and it will be treated, name-wise, as if it’s the superclass.

 

 

 

Re: Overriding Flows and Client Specific Implementations - Ideas needed.

Mike Hearn
 

Thanks Stefano.

 

If we allow users to customize their responding flows for different backends, surely the same is required for Initiating flows.

 

I guess I’m not entirely convinced about this point.

 

We want to allow people to override the default handling of inbound flows because we assume it’s way too much hassle to get your counterparties to all change to using the new name (requires editing apps, maybe changing what flow is used depending on counterparty etc).

 

But changing the flow name passed to an RPC is presumably much easier because it’s all within the same organization. The only time it’d be necessary is if you have so many programs using RPC and a particular flow name, that it’s totally impractical to change them all, or if you’re using a tool that is closed source and can’t be told what flow to use via configuration.

 

Now, if you sub-class an initiating flow to customize it, we still have the problem of the wrong name being sent. But can’t this be handled by just looking upwards through the class hierarchy looking for @InitiatingFlow and @StartableByRPC and then just use those names? That is, there’s nothing special about the sub-class at all, it’s just not annotated. You can then pass the subclass name via RPC and it will be treated, name-wise, as if it’s the superclass.

 

 

 

Overriding Flows and Client Specific Implementations - Ideas needed.

Stefano Franz
 

I've been working on a way for users of corda to override an @InitatedBy flow with a specific version for their backend. Simplest Example would be
 
@InitiatingFlow
class Initiator : FlowLogic<String>

@InitiatedBy(Initiator::class.java)
class SimpleResponder : FlowLogic<String>
 
@InitiatedBy(Initiator::class.java)
class IbmDB2SpecificResponder : SimpleResponder
 
Corda will now by default always select the Flow implementation that has the most hops to FlowLogic - and in this case, IbmDB2SpecificResponder will be selected. It also possible to manually specify the flow to use using the new flowOverrides section of node.conf.
 
        flowOverrides {
            overrides=[

                {

                    initiator="net.corda.Initiator"

                    responder="net.corda.SimpleResponder"

                }

            ]

        }
 
So, now cordapp writers can provide a Base implementation, and allow users to customize the responding flow for their respective backends.
 
Working on this, I've started to realize that responding flows are only part of the story (half specifically). If we allow users to customize their responding flows for different backends, surely the same is required for Initiating flows. Now this really adds some complexity, because if we extend the above example,
 
 
@InitiatingFlow
class Initiator : FlowLogic<String>
 
@InitiatingFlow
class IbmDB2SpecificInitiator : Initiator
 
We now have an interesting problem.
 
  1. What flow is to be invoked when doing rpc.startFlow?
  2. What flow is to be specified in the @InitiatedBy annotation?
 
For RPC it would be simple to implement something similar to how responding flow overrides behave, we should allow the use of rpc.startFlow(Initiator::class.java), and internally corda should map this request to a specific implementation based on rules / overrides. The real complexity comes from the @InitiatedBy annotation. In this new world of extendable flows, it's possible for a situation like this
 
 
User1 has flows: 
 
@InitiatingFlow
class Initiator : FlowLogic<String>                          //BNO provided
 
@InitiatingFlow
class IbmDB2SpecificInitiator : Initiator                   //User1 specific 
 
@InitiatedBy(Initiator::class.java)
class SimpleResponder : FlowLogic<String>                   //BNO provided
 
@InitiatedBy(Initiator::class.java)
class IbmDB2SpecificResponder : SimpleResponder             //User1 specific
 
 
User2 has flows
 
@InitiatingFlow
class Initiator : FlowLogic<String>                          //BNO provided
 
@InitiatingFlow
class CassandraSpecificInitiator : Initiator                //User2 specific 
 
@InitiatedBy(Initiator::class.java)
class SimpleResponder : FlowLogic<String>                   //BNO provided
 
@InitiatedBy(Initiator::class.java)
class CassandraSpecificResponder : SimpleResponder          //User2 specific
 
User1 will invoke IbmDB2SpecificInitiator, and User2 will have to respond with CassandraSpecificResponder - but they have never seen IbmDB2SpecificInitiator and does not have it on their classpath.
 
My proposal is as follows:
 
  1. Add a new interface GroupableFlow, with a single method group() : Class<FlowLogic>
  2. If the flow is of type GroupableFlow we modify the header of the message sent across the wire to specify the return of group()
  3. Responders will be @InitiatedBy the group.

Alternatively it has been suggested that a new annotation @InitiatingFlowAs should be added which would allow code in the style of

@InitiatingFlowAs(Initiator::class)
class CassandraSpecificInitiator : Initiator

All responding flows would specify @InitiatedBy(Initiator::class)

This will be a superset of the current corda API, and so will not break backwards compatibility.

Any feedback / extra requirements would be useful!

Owner-less OwnableState

Brendan Duhamel
 

Hi all, 

Kostas brought this idea to my attention a little while ago and I've been thinking about it since. Any feedback would be much appreciated. 

I'm currently investigating a few use cases where an owner of some OwnableState wants to allow a beneficiary to automatically (i.e. without original owner's signature) take control of that asset if they meet a set of pre-defined criteria. The owner can accomplish this by moving its OwnableState to a 1 of 2 CompositeKey (one leaf key is owned by the current owner, the other by the beneficiary, both of equal weight) and encumbering it with a state that defines said criteria in its own contract code. If beneficiary meets the requirements before a specified point in time, they can spend the encumbrance state and take over the OwnableState in the same transaction. If they fail, the original owner can spend the encumbrance and recover the asset.

However, because the beneficiary needs to partially own the CompositeKey in order to spend the asset along with the encumbrance this approach only supports cases where the original owner knows beforehand who the beneficiary is going to be. There are a lot of scenarios where in fact the original owner does not know and more importantly does not care who takes the asset as long as they fulfill the requirements defined in the encumbrance. 

As a simple example, if I want to sell my HouseState for a million Corda tokens, I could encumber it with a state that says anyone who can prove they have the right to live in the UK (maybe with some sort of VisaState) and wants to give me a million Corda tokens can take my house by posting an atomic swap transaction. There could be a data distribution group of potential home buyers that will receive the HouseState transaction, but I shouldn't need to know the exact list of parties that might be interested before I encumber my HouseState.

There are a couple ways I can see of doing this. The first is to simply move the HouseState to a PubKey for which we know everyone on the network has the corresponding private key. But to me it seems sort of weird to require signatures that don't mean anything. The better approach would be to allow an OwnableState to turn off its ownership quality by setting the owner field to null. Because as a HouseState owner I would only nullify the owner field if I was also encumbering the state at the same time, I don't mind that anyone on the network who has that transaction can try to spend my HouseState because I trust the rules in the encumbrance. In other words, as long as you have somehow gained the right to spend that encumbrance (no matter who you are or what keys you have) you also have the right to take my HouseState. 

Anyone have any thoughts on this? My guess is this might be helpful for other projects so I would be happy to look at a possible OS contribution if there's some interest. 

Cheers,

Brendan

Re: Zero-Knowledge Proofs

Konstantinos (Kostas) Chalkias
 

Hi Tammy,

as Mike mentioned we have some PoC implementations around confidential transactions (hiding amounts).

You could track progress on this branch https://github.com/corda/corda/compare/kostas-CT-experimental, which at the moment includes some working implementations of the AOS ring signatures, Borromean signatures and an initial (still not complete) implementation for Bulletproofs ZKP. As for the first two, using Pedersen commitments and chameleon hashes one can easily provide Range Proofs.

In Corda terms this would mean we could check that `inputs-aggregated-amount = output-aggregated-amount` but without disclosing the actual amounts transferred. This implies that verify() will only pass if the amounts transferred add up correctly and it guarantees we didn't create money out of thin air, which is usually what you need for a token-based application.

Another interesting property is we could mix visible and hidden amounts (i.e., we know the total amount of tokens issued in the network, but we then lose track on the amounts transferred on subsequent transactions) or (one could use this property to hide the most or less significant bits of the amounts transferred - i.e., there might be applications that every state above 1M should be publicly visible due to money laundering requirements).

I will keep you updated on this work, I already tested the implementation is at least functional, but I need more tests and a proper api to make them fully available to Corda developers.

Thanks, 

Kostas

Corda 3.3 Released

Katelyn Baker
 

With over 100 fixes, a good 10% of which are back-ported community contributions. 


GitHub release is here


Blog post is here


Re: Roadmap doc for project MAXIMUS

Mark Simpson
 

Thanks Mike, very helpful and I thought Amazon lambda ran on Jeff Bezo’s magical unicorns !
I would guess that Corda Serveless would run on a decentralised pool of servers that span clouds and corporate data centres.

On 15 Oct 2018, at 13:26, Mike Hearn via Groups.Io <mike@...> wrote:

Pretty sure AWS Lambda runs on servers 😉
 
Yes I’d love to get us to the point where developers inside an organization can trivially deploy apps to a node via a self service API. That’s going to be essential to reach the “3 firms, 3 devs, 3 days” goal I outlined in my CordaCon talk.
 
Some Corda users are very conservative. To get there we’ll need a few components:
 
  1. A way to deploy software to the node in a controlled manner. Our current bet: teach the node about Maven repositories and how to resolve from them. Then you can point your node at an internal Artifactory that is connected to your CI system, such that the release process is gated by the standard code review and CI gates.

    That way, a company can know that the apps the node has access to have all come through a formalized release process and they can of course mirror Maven Central to ensure all the dependencies are snapshotted, as many firms already do.

  2. RPCs and shell commands to tell the node “install app with coordinate <com.megacorp:megaapp>” and “upgrade app with coordinate….”, so the install/upgrade process can be permissioned to admins.

  3. Support for automatic upgrade of marked apps. For example, during iterative testing between firms, you don’t want to involve the node admins for every upgrade cycle, it should be automatic once a new release is pushed to CI. Once the app becomes more important to the business automatic upgrade can be disabled, and if it’s really important, it can be run on an isolated machine from other less critical apps or apps that are still in development.
 
So the goal is to have a smooth ramp from iterating-every-day to a more controlled production state where maybe more signoffs are required.
 
Ivan has a PR already that implements most of this, including running Maven resolution over flows. So you can host an “app store” on a BNO node and use the BNO Membership Service app to restrict access based on Corda identities, potentially in future it could integrate with tokens too – app store on the ledger? Sure, why not?
 
 
 

Re: Roadmap doc for project MAXIMUS

Mike Hearn
 

Pretty sure AWS Lambda runs on servers 😉

 

Yes I’d love to get us to the point where developers inside an organization can trivially deploy apps to a node via a self service API. That’s going to be essential to reach the “3 firms, 3 devs, 3 days” goal I outlined in my CordaCon talk.

 

Some Corda users are very conservative. To get there we’ll need a few components:

 

  1. A way to deploy software to the node in a controlled manner. Our current bet: teach the node about Maven repositories and how to resolve from them. Then you can point your node at an internal Artifactory that is connected to your CI system, such that the release process is gated by the standard code review and CI gates.

    That way, a company can know that the apps the node has access to have all come through a formalized release process and they can of course mirror Maven Central to ensure all the dependencies are snapshotted, as many firms already do.

  2. RPCs and shell commands to tell the node “install app with coordinate <com.megacorp:megaapp>” and “upgrade app with coordinate….”, so the install/upgrade process can be permissioned to admins.

  3. Support for automatic upgrade of marked apps. For example, during iterative testing between firms, you don’t want to involve the node admins for every upgrade cycle, it should be automatic once a new release is pushed to CI. Once the app becomes more important to the business automatic upgrade can be disabled, and if it’s really important, it can be run on an isolated machine from other less critical apps or apps that are still in development.

 

So the goal is to have a smooth ramp from iterating-every-day to a more controlled production state where maybe more signoffs are required.

 

Ivan has a PR already that implements most of this, including running Maven resolution over flows. So you can host an “app store” on a BNO node and use the BNO Membership Service app to restrict access based on Corda identities, potentially in future it could integrate with tokens too – app store on the ledger? Sure, why not?

 

 

 

Re: Roadmap doc for project MAXIMUS

Mark Simpson
 

@Mike

I’m wondering what your thinking is in terms of the concept of ‘serverless’ corda. The ability to deploy cordapps by just deploying jar(s) via an api into a hosted ‘cordas OS’  run under a specific identity is very appealing.
Having used amazon lamba to literally paste code into box on a webpage was very liberating.
Be great to hear what you think about taking it this far !
 

On 15 Oct 2018, at 11:40, Mike Hearn via Groups.Io <mike@...> wrote:

Matthew pointed out that we should clarify something.

Today the word "node" has a simple meaning - it's the thing that starts when you run Corda.

In a post-MAXIMUS world we will be redefining what the word "node" means slightly. The new definition will be something like, "the installation of Corda for your organisation". A node may be composed of multiple servers working together. This is already happening with the float/bridge/separate database server etc setup found in enterprise setups.

As part of this, apps will see what amounts to a virtualised node. The APIs can't change, so instead the current identity the node is acting as will change between runs of the app. Because of things like @CordaService this implies that apps may need slight adjustments to work efficiently on multi-identity nodes.

As we provide backwards compatibility, MAXIMUS nodes will be able to run existing apps. However not all the efficiency gains may be obtained in that case (it's a bit early to tell). If necessary the targetVersion mechanism will be used to let apps label themselves as having been tested against multi-identity nodes. Apps that target newer versions of the platform may need to provide a bit more info like whether a service is scoped to identity or process lifetime, things like that.

More info will be provided as this capability is developed.

Re: Roadmap doc for project MAXIMUS

Mike Hearn
 

Matthew pointed out that we should clarify something.

Today the word "node" has a simple meaning - it's the thing that starts when you run Corda.

In a post-MAXIMUS world we will be redefining what the word "node" means slightly. The new definition will be something like, "the installation of Corda for your organisation". A node may be composed of multiple servers working together. This is already happening with the float/bridge/separate database server etc setup found in enterprise setups.

As part of this, apps will see what amounts to a virtualised node. The APIs can't change, so instead the current identity the node is acting as will change between runs of the app. Because of things like @CordaService this implies that apps may need slight adjustments to work efficiently on multi-identity nodes.

As we provide backwards compatibility, MAXIMUS nodes will be able to run existing apps. However not all the efficiency gains may be obtained in that case (it's a bit early to tell). If necessary the targetVersion mechanism will be used to let apps label themselves as having been tested against multi-identity nodes. Apps that target newer versions of the platform may need to provide a bit more info like whether a service is scoped to identity or process lifetime, things like that.

More info will be provided as this capability is developed.