Transaction Policies
The transaction policies that dictate all of the resource allocations required for a transaction are displayed in the table below. Some of these types are conditional to the Notoros deployment being used and can change based on configuration.
A transaction can have one or many policies. Policies allow the submitter to dictate the ordering of their transaction relative to other transactions. Every new policy creates a new ordering requirements. Every policy must be valid for the transaction to be valid. A policy field cannot be considered ‘null’. If left blank, a field will be interpreted as ‘0’.
| Policy | Datatype | Definition |
|---|---|---|
| Shard | String | The shard where the transaction will be stored |
| Slot | String | The slot where the transaction will be stored |
| Counter | UInt | The number corresponding to the ledger operation |
| Operation | ‘READ’ or ‘WRITE’ | The operation type being committed to the ledger |
Shard
The shard field on a message must be a hex string of up to 256bits. A shard is a segment of the network centered around a private key that dictates a range of computational resources where transaction data will be stored. Shards are distinct interlocking networks that don’t impact each other in order to facilitate parallelization of computation across the ledger.
A valid transaction with policies enforces some level of ordering across the shards where the data will be stored. Transactions can be made to store data across many shards by implementing a number of transaction policies. Combined with the slot field, the shard inputted as part of a policy determines the relative ordering at which each copy of a transaction is stored. Because the asynchronous nature of blockchain, this ensures the intention of the transaction cannot be skewed because of time alone.
Slot
The slot field on a message must be a hex string of up to 256bits. A slot is an added level of granularity that dictates where data is stored within a given shard. In the postal service metaphor, if a shard is a city, a slot would be the street address.
In the context of a URI a shard is like a hostname and the slot is the path to the resource. This level of granularity allow Notoros to nest the consensus process without slowing the overall ledger.
Counter
The counter field on a message must be a hex string of up to 256bits. In Notoros transaction policies, the counter refers to a logical clock that specifies where the transaction should be ordered relative to other transactions.
In the postal service metaphor, this is like a highly specific postmarking for your mail. The counter provides a timestamp, relative to other transactions, which indicates the absolute location of the data in the ledger. The counter specifies the version the data resource on which the transaction is operating.
Operation
The operation field must be a ‘read’ or ‘write’ enumerated value. It indicates if the policy will perform a read or write operation on the resource indicated. Ultimately this operation is determining if the resource should increment (write) or not (read). Writes are performed on the indicated resource after reads in a block at consensus time.
Whether a policy should be a ‘read’ or ‘write’ is dependent on the application and based on the needs of the developer.