transactions structure
the transactions in CryptoDbSS have the following format in their structure, each
data is written in sequence and is represented by a byte string:
| Element |
Size |
| Transaction Type ID |
1 byte |
| Issuing Address |
64 bytes |
| Amount of Issuing Address |
8 bytes |
| Receiving Address |
64 bytes |
| Amount of Receiving Address |
8 bytes |
| Transaction Number ID |
2 bytes |
| Feed |
4 bytes |
| Signature |
64 bytes |
| ID Blockchain |
32 bytes |
| SHA of Node Matchmin |
32 bytes |
| Block Header |
32 bytes |
| Total |
311 bytes |
the total length of this is reduced by compression algorithms based on
redundancy elimination.
the first byte of each transaction defines the
type of transaction, more in explanation, is how the data of this will
be interpreted, this in practice serves for scalability and to be able
to provide new features in the future, a clear example is
the
asynchronous processing between transactions characteristic of CryptoDbSS,
in the DB scheme this also defines the
type of compression. This space
can be used to add new types of transactions, or others cryptographic
signature schemes,
ballots, patches, interoperability with EVM,
etc.
Asynchronous Account Statement Definitions for Transactions
if an account is being transacted with its status defined but not yet
confirmed and another transaction is attempted to be made that has the same
account, it should be waited for it to be confirmed to proceed with the next
one in the case of defining its status, since if the first one were to fail
and the second is validated it would cause an error between the sums of the
previous statuses of the account, therefore this should be synchronous until
the transaction is processed and confirmed; in order to break this blockage,
It becomes asynchronous by not defining the status of the transacting accounts
in the transactions after writing pending confirmation, this works because
instead of placing the status of the accounts in the transaction, the amount
of the operation to be transacted is placed, having previously verified that
the account has the balance to carry it out, also debiting the transactions to
be confirmed. When a new transaction is requested to be processed, 4 scenarios
can occur that will define the transaction (0x00, 0x04, 0x06, 0x08) this
definition will tell how the data will be interpreted, below is the linear
structure that all transactions have, but on this occasion we will only focus
on the first 5 elements that compose it, which are essential in this
explanation
| Transac type |
Acc issuing |
Value |
Acc receiving |
Value |
Having the scheme focused, let's show how the data changes in them depending
on the scenario that the transaction should take.
When no transaction account is being previously operated, the first element
transac type is defined with the byte 0x00, and the values are defined with
the states of the accounts e.g. (Bob has a balance of 5000, and alice has
2500, Bob sends 500 to Alice, the structure is as follows:
When one of the accounts is being operated and has not yet been confirmed, its
status cannot be defined for the reasons mentioned above, so its value field,
instead of being defined by its status, is defined by the value that the
transaction takes (in this example and the following ones, the values used in
the previous one will be taken)
his time Bob, has a pending transaction, and Alice has none, Bob's value is
defined by the amount of the operation (500), and Alice's value is defined by
the state of her account added to the amount that is credited to her
(previously 2500, now 3000), the transaction type is defined with 0x06 and the
structure is the following:
Bob does not have any pending transactions but Alice does, Bob's value is
defined by the status of his account (previously 5000, now 4500), and Alice's
value is defined by the amount of the operation, the transaction type is
defined with 0x08 and the structure is the following:
When both have pending transactions, both values are defined by the amount of
the operation. This case is defined as 0x04 and the structure is:
Structure of a CryptoDbSS block
| Column Name |
size length |
| Block Header |
32 Bytes |
| Block Type ID |
1 Byte |
| Blockchain Network ID |
32 Bytes |
| SHA of Node Matchmin |
32 Bytes |
| Address to Feed |
64 Bytes |
| New Value of Address to Feed |
8 Bytes |
| Block Number |
8 Bytes |
| Quantity of Transactions |
2 Bytes |
| Transactions Content |
Varies |
| Space Check Dumper |
2 Bytes |
| Uncompressed Integrity Data SHA |
32 Bytes |
