ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-19 13:08:04 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
51adf9b678
corda/docs/source/tut-two-party-introduction.rst
Shams Asari e8b6f5f2f2
CORDA-2005: FinalityFlow has been made into an inlined flow to resolve issue with FinalityHandler (#4050) 
FinalityHandler is insecure in that it is open to receive any transaction from any party.

Any CorDapp targeting platform version 4 or above is required use the new c'tors which take in FlowSession objects to the counterpart flow. This flow must subcall ReceiveFinalityFlow to receive and record the finalised transaction.

Old CorDapps (with target platform version < 4) will continue to work as previously. However if there are no old CorDapps loaded then the node will disable FinalityHandler.
2018-11-14 14:16:22 +00:00

996 B
Raw Blame History

Hello, World! Pt.2 - Contract constraints

Note

This tutorial extends the CorDapp built during the Hello, World tutorial <hello-world-introduction>.

In the Hello, World tutorial, we built a CorDapp allowing us to model IOUs on ledger. Our CorDapp was made up of two elements:

  • An IOUState, representing IOUs on the blockchain
  • An IOUFlow and IOFlowResponder flow pair, orchestrating the process of agreeing the creation of an IOU on-ledger

However, our CorDapp did not impose any constraints on the evolution of IOUs on the blockchain over time. Anyone was free to create IOUs of any value, between any party.

In this tutorial, we'll write a contract to imposes rules on how an IOUState can change over time. In turn, this will require some small changes to the flow we defined in the previous tutorial.

We'll start by writing the contract.

tut-two-party-contract tut-two-party-flow