Transaction Messages
The essential message data that defines the basis of a Notoros transaction is 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 transaction messages.
| Component | Datatype | Definition |
|---|---|---|
| Destination | Address | Where the transaction is being sent |
| Data | String | The data being committed to the ledger |
| Application Lens ID | String | The identity of the application that can read this transaction |
| Sender | Address | The origin of the transaction |
Destination
The destination field on a message must be a hex string of up to 256bits, specified during the creation of a transaction. This field dictactes the recipient shard where the data for the message will be stored.
By entering a valid hex string in the field, the message is ensured to propogate explicitly to that shard during the consensus process. If the field is left empty, the destination address is implicitly assumed to be the sender’s address.
Data
The data field is the content of a message and consists of an arbitrary string up to 1Mb in size, specified during the creation of a transaction. This data will be stored at the shards containing the sender and destination addresses, respectively. Typically, this data will be used to provide the commands and application uses for processing.
When building a decentralized state-proving network this field will contain the proof of the application state. Check out this page to learn more about launching a state-proving network.
Application Lens ID
Sometimes just called the “lens ID”, the application lens ID field takes a 256bit string input that dictates for which application lenses the message is intended. This gives applications the ability to selectively choose or ignore messages to process, and allows Notoros to operate as a pub-sub database.
For example, the Notoros-EVM lens uses “ethereum” as its application ID. This means that any application deployed after the Notoros-EVM can listen to its state changes and respond accordingly. In this way, applications on the Notoros ledger can achieve a profound new level of interoperability without compromising trustlessness.
Sender
The sender field is very similar to the destination field. The sender field must be a hex string of up to 256bits, specified during the creation of a transaction. This field dictactes the sending shard where the data for the message will be stored.
Unlike the destintation field, the sender field enforces a signing requirement ensuring that all transactions can be cryptographically traced back to their origin. This forms the basis for trustless communication across the network.