Breaking down a TrxSys Transaction
At first glance a TrxSys transaction can look rather confusing. The following is intended to shed some light on both the details of a transaction as well as how
TrxSys works.
TrxSys does not use the industry standard definition of a block with that being a collection of transactions. Rathger TrxSys looks at a block as being a collection of objects that
make up a transaction. The distinction is very important and allows TrxSys to do things that no other blockchain can do.
Not every one of these fields is required to create a transaction. To take a look at the minimum required to send a transaction take a look at these links:
TrxSys API and SDK
Create simple transaction (login required)
Transaction Objects
There are seven objects in a TrxSys transaction. In a raw format, the seven objects can be seen in the Transaction Example below. Every transaction contains all seven objects.
One might look at the size of the transaction and consider that it is a lot of information for what might be a simple transaction. That may be true, but given Moore's Law and reasonable storage costs
it is not practical to cost effectively construct many millions or billions of transactions using the TrySys model.
The following transaction was used to write the following message to the TrxSys blockchain, This is a test API message to TrxSys from Python 05262020 test b
Keeping in mind that this transaction simply stores the message content of "This is a test API message to TrxSys from Python 05262020 test b" let's explore what is happening in the
Transaction.
The seven objects in the transaction are:
- sender
- sendersigning
- recipient
- recipientsigning
- xnode
- blocksigning
- chainribbon
In the following example all seven objects will be shown. But not every possible field that can be included in an object will be shown. We have not published a full list of
objects fields yet. However, the fields that are shown are the most common ones. We will now break each object down.
sender object
The "sender" is the creator of the transaction. In this object the sender specifies the type of transaction, amount of cryptocurrency (if any), the message as well as a variety of other pieces of
information.
- sender_version:""
This method is not currently enabled.
- sender_transaction_type:"3"
Transaction type "3" is a standard transaction that may or may not have a recipient.
- sender_timestamp_l_g:"1590522261"
The timestamp is generated by TrxSys. The format is Unix epoch.
- sender_amount:"0"
The amount of cryptocurrency is specified.
- sender_type:"1"
There are multiple sender types (i.e. governments, companies, individuals). "1" is for an individual and is currently the only type allowed.
- sender_pid:"0123456789012345678901234567890123456789012345678901"
The PID or personal ID is specified here.
- sender_message:"7d12bf5ad21cb450ea3a1ea32d14ab9277fe8ba8bac99bc8cbc809af
fa988775ad2ad19e5d3d25b0bf6df97419203c484b972b7213cce843
230f2f3df029697fb5416884d658b9d509c08b2c053d1492cb177c42
830eb3fadf16b944d158e1e2"
The sender_message contains all content that the sender wishes to include. TrxSys encrypts the sender_message in the transaction with the key located in the chainribbon
object. [More details on sender_message]
- sender_message_key_url:""
The sender may specify an "off-chain" key or reference to be included. This method is not currently enabled.
- sender_encrypt_transaction:"0"
The sender may specify encryption of fields beyond the sender_message. This method is not currently enabled.
- sender_add_to_public_index:"0"
Binary:
No or 0 (or NULL or empty) = default, do not allow this transaction to be publicly discoverable. If a chain template then this setting allows the chain template to be publicly found but not the transactions.
Yes or 1 = add to public index, allows transaction to be publicly listed, searched, discoverable. If a chain template then this setting allows the chain template to be publicly found and the transactions.
- sender_public_alias:""
The sender can specify a "human readable" alias. This method is not currently enabled.
- sender_message_encoding:""
The sender may specify encoding of the sender_message. This method is not currently enabled.
- sender_chain_id:""
A chain ID allows for a collection of transactions to be identified.
- sender_chain_id_remove:""
This method is not currently enabled.
- sender_chain_common_name:""
- sender_chain_acl_add_id:""
This method is not currently enabled.
- sender_chain_acl_remove_id:""
This method is not currently enabled.
- sender_chain_acl_promote_id:""
This method is not currently enabled.
- sender_random_id:""
This method is not currently enabled.
- sender_chain_keywords:""
Keywords associated with a chain app.
- authoritative_domain:""
An authooritative domain is a domain for which the user has registered with a domain that does not originate from a bulk email provider. Email services such as
gmail, yahoo, outlook, etc. cannot be associated with domains as being authoritative.
More details on sender_message
The sender_message field, part of the sender object, can be a bit confusing because of both its flexibility and the fact that it is encrypted.
The specifications for the sender_message are:
- TrxSys requires that sender_message data be formatted to Base64. [Online tool for Base64] [Learn about Base64]
- Base64 is required to enable flexibility in the type of data or characters to be stored.
- As an example, if your message is Hello World! and you're using the API then the requirement is to convert to SGVsbG8gV29ybGQh
- To make this easy the Python API script example handles encoding to Base64.
- Binary strings, JSON, CSV, etc. can all be included in the sender_message. They just need to be encoded to Base64.
- Complex string structures, like JSON, are allowed. TrxSys supports the concept of you write the data and you provide guidance to your users on how to consume that data.
- TrxSys encourages the use of human readable and understandable field names. Do not try to obfuscate field names in order to lock users in.
- If you are entering the message using the "Transaction Form" [Link] then there is no need to convert to Base64. TrxSys will do that automatically.
sendersigning object
The sendersigning object is used to "sign" the sender object. The signing serves as proof that the sender intended to perform this transaction. The public key is included
to provide the means of signature verification.
- sendersigning_hash_of_sender_objects:"a8bd36946bae1190c61ea107e14f9c7e
3a5682f845ab1560eb4392229631f19d"
A sha256 hash of the sender object.
- sendersigning_hash_of_sender_objects_signature_hex:"3045022100a67db074
440d450aeff6b8d647a0262bc80f8e7025e1f7b360b9deb84a5ab73
902203b2f704cb1ea0b8c38ece80c6a6875e97497ec309f69ff196b
e551c1f415ade1"
The aforementioned hash is signed with the sender's private key. Currently,
private keys are held in an encrypted state by TrxSys.
- sendersigning_sender_pkp_public_key:"-----BEGIN PUBLIC KEY-----MIH1MIG
uBgcqhkjOPQIBMIGiAgEBMCwGByqGSM49AQECIQD////////////////////////////////////+/
//8LzAGBAEABAEHBEEEeb5mfvncu6xVoGKVzocLBwKb/Nstzij
ZWfKBWxb4F5hIOtp3JqPEZV2k+/wOEQio/Re0SKaFVBmcR9CP+
xDUuAIhAP////////////////////66rtzmr0igO7/SXozQNkFBAgEBA
0IABLd3GBV7zdZ66I12H8hFjwKD0GO3n4fyK4882UMAoiGPHQ8dumlQPVsR
zE7yaNQEsrr604WM1SO
wHElB0vIbLzs=-----END PUBLIC KEY-----"
The sender's public key that can be used to verify the signature of the sender_object.
recipient object
The recipient object identified the recipient of the transaction. The recipient will eventually be able to optionally sign the transaction to provide proof of
awareness and intent to receive a transaction from the sender.
- recipient_pid:"0"
If the transaction is being "sent" to someone then that person's ID, their own PID, would be specified here.
- recipient_random_id:""
This method is not currently enabled.
recipientsigning object
The recipientsigning object is used to "sign" the recipient object. The signing serves as proof that the recipient intended to perform this transaction. The public key is included
to provide the means of signature verification. It is only optional that the sender signs and this function is not currently available.
- recipientsigning_hash_of_recipient_objects:""
A sha256 hash of the recipient object.
This method is not currently enabled.
- recipientsigning_hash_of_recipient_objects_signature_hex:""
The aforementioned hash is signed with the recipient's private key. Currently,
private keys are held in an encrypted state by TrxSys.
This method is not currently enabled.
- recipientsigning_recipient_pkp_public_key:""
The sender's public key that can be used to verify the signature of the sender_object.
This method is not currently enabled.
xnode object
The xnode object represents information collected or produced from the sign and bind process. An xnode may actually be one of several types of servers or nodes authenticated by TrxSys to
write transactions to the TrxSys blockchain.
- xnode_prior_record_block_hash:"8a0f40c9cf8fd1a5f2f2c33015ef2594a20df619ec5
d71cf1e9c77523337a48c"
The blocksigning_hash_of_all_objects from the blocksigning object of record that came immediately before this one. It is this hash value that ties the current record
to the prior record which ties that transaction to its prior record and so on to form a chain of transactions.
- xnode_sequential_transaction_id:"142"
Each transaction is sequentially numbered. In this example transaction, the xnode_sequential_transaction_id is "142". That makes this transaction the 142nd transaction ever
recorded.
- xnode_timestamp_l_g:"1590522261"
The xnode and the execution system may be different servers or different nodes. This is the timestamp in Unix epoch form from the xnode node. The xnode is has an "x"
in its name because there may be various types of nodes such as routing nodes, archival nodes, etc.
- xnode_fee:"0.0002"
The xnode fee is the fee charged by TrxSys for executing the transaction.
- xnode_governor_meta_data:""
This method is not currently enabled.
- xnode_pid_governor:"0123456789012345678901234567890123456789012345678901"
The xnode has its own PID. The word "governor" is used to denote that this node is operated by the governor or central authority.
- xnode_transaction_id:"y1yIJQXpXqbWMHMgkSYdDWGe9ErpvclRhiWqQICunpBY21z1LAJv"
This is the transaction ID. If the transaction is intended to be kep private then the transaction ID should not be shared.
blocksigning object
The blocksigning object is used to tie all the objects together, including the prior transaction's hash, with the result being a chain of transactions.
- blocksigning_hash_of_all_objects:"c397a0948394725054ca6d0a26b4
2f3db683106fcba0f71e50d5b7367081bcfa"
A sha256 hash of all other objects concatenated...
(sender}.{sendersigning}.{recipient}.{recipientsigning}.{xnode}
Of course, the blocksigning object is not included because a hash cannot be derived of itself.
The chainribbon object is not included because it is intentionally left out.
- blocksigning_hash_of_all_objects_signature_hex:"30440220487c89
73f4b8721eeb99a4c2e40d62164aa3dab55d62e31105559b5509eb16660220
5a30698db71b7a04efff2fa83e16b19ccba738e8f1b2c66b9987ca5dcda59f
81"
The blocksigning_hash_of_all_objects signed by the governor process.
- blocksigning_gov_pub_key:"-----BEGIN PUBLIC KEY-----MIH1MIGuBg
cqhkjOPQIBMIGiAgEBMCwGByqGSM49AQECIQD////////////////////////////////////
+///8LzAGBAEABAEHBEEEeb5mfvncu6xVoGKVzocLBwKb/NstzijZWfKBWxb4F5
hIOtp3JqPEZV2k+/wOEQio/Re0SKaFVBmcR9CP+xDUuAIhAP////////////////////66rtz
mr0igO7/SXozQNkFBAgEBA0IABI8Cs7hXNyXooEOSIasg6rIYbmeDPRkAcOCIFm
Pkb6NxDDb6arn9AcZZDb6FpxF1Q1aCw/IJAgMGxI58HlODyOY=
-----END PUBLIC KEY-----"
The governor's or identified authority's public key to validate the signature.
chainribbon object
Ownership of transactions does not include the ability to delete or modify a transaction that has already been written. However, the
owner of the transaction may remove the "chain ribbon" key to the message that is contained "alongside" the transaction
to effectively disable or "kill" the information contained in the transaction message. This ability to kill or disable
information in a transaction does not extend to any part of the transaction outside of the message (block meta data). The
sender ID, recipient ID, amount sent, cryptographic signatures, etc. will remain intact.
The sender_message is encrypted via AES (Advanced Encryption Standard) with a 256 bit key and 128 bit initialization vector.
The key and IV are included anytime the transaction is queried so as to allow the requester to decrypt the sender_message.
- chainribbon_key:"e40KtKcVCT9R0V8TGYCEr6IOy5rctW5T"
The chainribbon key is 256 bit and is auto-generated by the system.
- chainribbon_iv:"fH9rIniMvK3gpaYd"
The chainribbon IV is 128 bit and is auto-generated by the system.
|