In order to move to a billing mechanism which preserves privacy and meets the requirements, you can employ the ‘Receipts’ design pattern.
In the receipts pattern, there is a dependent state which has a rule that mandates that it cannot perform some action unless it sees proof that an
EnablerState has undergone a specified action. If you put the dependent action and the enabling action in the same Corda transaction you will require the backchain of both state to be resolved for all future uses of those states. This is the what causes the privacy leaks in the naive Billing mechanism.
To avoid this we separate the enabler action out into its own transaction and generate a receipt proving that the action has taken place. It is this receipt which is used in the dependent transaction to proove that the enabling action took place.
In the private Billing mechanism in the Agreement example, the dependent state is the Agreement state and the enabling state will be a billing chip which proves that the main billing State has incremented it cumulativeUse property.
The Billing Smart Contract now looks like this diagram. You can see that there is the additional BillingChip state as well as the Primary BillingState:
In the Ledger Evolution view, the generation of the BillingChip is shown as follows:
The BillingChip can then go on to be used as the enabler for the dependent Agree transaction:
Then the same steps are repeated for Charlie’s sausage transaction (Tx 4b):
Now you can add the Privacy Overlays for AgreeCorp and Charlie we see that privacy has been preserved:
Explicitly, AgreeCorp’s node doesn’t resolve either Tx 4a or Tx 4b and Charlies node doesn’t resolve the previous agreement between Alice and Bob.
Was this page helpful?
Thanks for your feedback!
Chat with us
Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.
Propose documentation improvements directly
Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.
We're sorry this page wasn't helpful. Let us know how we can make it better!
Chat with us
Create an issue
Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.