mirror of
https://github.com/corda/corda.git
synced 2025-01-03 11:44:16 +00:00
e8b6f5f2f2
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.
24 lines
996 B
ReStructuredText
24 lines
996 B
ReStructuredText
Hello, World! Pt.2 - Contract constraints
|
|
=========================================
|
|
|
|
.. note:: This tutorial extends the CorDapp built during the :doc:`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.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
tut-two-party-contract
|
|
tut-two-party-flow |