com.r3corda.contracts.asset / CommodityContract / State / contract

contract

val contract: CommodityContract
Overrides ContractState.contract

An instance of the contract class that will verify this state.

Discussion

This field is not the final design, its just a piece of temporary scaffolding. Once the contract sandbox is further along, this field will become a description of which attachments are acceptable for defining the contract.

Recall that an attachment is a zip file that can be referenced from any transaction. The contents of the attachments are merged together and cannot define any overlapping files, thus for any given transaction there is a miniature file system in which each file can be precisely mapped to the defining attachment.

Attachments may contain many things (data files, legal documents, etc) but mostly they contain JVM bytecode. The class files inside define not only Contract implementations but also the classes that define the states. Within the rest of a transaction, user-providable components are referenced by name only.

This means that a smart contract in Corda does two things:

  1. Define the data structures that compose the ledger (the states)

  2. Define the rules for updating those structures

The first is merely a utility role ... in theory contract code could manually parse byte streams by hand. The second is vital to the integrity of the ledger. So this field needs to be able to express constraints like:

and so on. In this way it becomes possible for the business logic governing a state to be evolved, if the constraints are flexible enough.

Because contract classes often also define utilities that generate relevant transactions, and because attachments cannot know their own hashes, we will have to provide various utilities to assist with obtaining the right code constraints from within the contract code itself.

TODO: Implement the above description. See COR-226