Merge pull request #800 from AraiEzzra/docs/transaction-bytes

Docs / Add bytes schema for transaction

docs/core/transaction/asset/index.md

@@ -14,14 +14,15 @@ DDK using multiple transaction types:
 Each transaction type has its own asset.
 
 * Send
-    + [Verify](asset/send#verify)
+    + [Get Bytes](send#get-bytes)
+    + [Verify](send#verify)
 * Referral
-    + [Verify](asset/referral#verify)
+    + [Verify](referral#verify)
 * Delegate
-    + [Verify](asset/delegate#verify)
+    + [Verify](delegate#verify)
 * Signature
-    + [Verify](asset/signature#verify)
+    + [Verify](signature#verify)
 * Stake
-    + [Verify](asset/stake#verify)
+    + [Verify](stake#verify)
 * Vote
-    + [Verify](asset/vote#verify)
+    + [Verify](vote#verify)

docs/core/transaction/asset/send.md

@@ -1,13 +1,44 @@
-# Transaction send asset
+# Asset Send
+
+## Get bytes
+
+| Field            | Type         | Bytes | Required |
+|------------------|--------------|-------|----------|
+| recipientAddress | uint64       | 8     | +        |
+| amount           | uint64       | 8     | +        |
+
+Bytes should be written in `Little Endian` order and in order that shown in table
+
+## Example get bytes
+
+Get bytes from a send asset
 
 ```json
 {
-    "recipientAddress": "15701569034897442085",
-    "amount": 1000
+    "amount": 10000000000,
+    "recipientAddress": "4957046151241062485",
 }
 ```
 
+The result of getting bytes from this asset will be the following buffer
+
+For convenience, it is converted to hexadecimal code
+
+```text
+36f7ca4455d8f0030200000000e40b54
+```
+
+
 ## Verify
 
 To verify `send asset`, you need to check the sender account `balance`, it must be the same or more
 then sum of transaction amount and transaction `fee`
+
+## Example Asset Send
+
+```json
+{
+    "recipientAddress": "15701569034897442085",
+    "amount": 1000
+}
+```

docs/core/transaction/bytes.md

@@ -4,19 +4,21 @@
 
 Get bytes is converting main transaction data to a buffer
 
-The main transaction data are:
-
-1. Type
-2. Creation time
-3. Salt
-4. Sender public key
-5. Asset
-
-In some cases, the bytes may contain a signature and a second signature
+| Field           | Type         | Bytes | Required |
+|-----------------|--------------|-------|----------|
+| type            | int8         | 1     | +        |
+| createdAt       | int32        | 4     | +        |
+| salt            | string       | 16    | +        |
+| senderPublicKey | string       | 32    | +        |
+| asset           | byte array   | X     | +        |
+| signature       | string       | 64    | -        |
+| secondSignature | string       | 64    | -        |
+
+Bytes should be written in `Little Endian` order and in order that shown in table
 
 ### Example get bytes
 
-Get bytes from a transaction
+Get bytes from a send transaction
 
 ```json
 {
@@ -36,5 +38,5 @@ The result of getting bytes from this transaction will be the following buffer
 For convenience, it is converted to hexadecimal code
 
 ```text
-14da3a9806894cdfa99bc38ca098d38d305c811496f4ae589b02f97e9ab5bce61cf187bcc96cfb3fdf9a11333703a682b7d47c8dc21aa981869d400a578c11c6dd0d65fa89a21557db44e5d876dcd0cc461db1bfd2
+0ada3a9806894cdfa99bc38ca098d38d305c811496f4ae589b02f97e9ab5bce61cf187bcc96cfb3fdf9a11333703a682b7d47c8dc236f7ca4455d8f0030200000000e40b54
 ```

docs/core/transaction/processing.md

@@ -1,6 +1,5 @@
 # Transactions processing
 
-
 The transaction lifecycle is determined by 2 checks.
 
 A newly submitted transaction is pushed into the **transaction queue**. While transaction is in the queue it is ***checked for conflict with other transactions*** in the transaction queue.
@@ -9,30 +8,30 @@ A newly submitted transaction is pushed into the **transaction queue**. While tr
 
 After the transaction queue the transaction is pushed into the **transaction pool**.  In the transaction pool transactions are ***checked for validity***. Top 250 validated transactions from the transaction pool are applied to the **new block**. The block time is 10 seconds which results in transaction rate of 25 transactions per second for the [1.1.12 version of the core](https://github.com/AraiEzzra/DDKCORE/tree/1.1.12).
 
-![Image](images/transaction_lifecycle.png)
-    
+![Image](../images/transaction_lifecycle.png)
+
 Transaction types
 
-DDK has 7 types of transactions. Each transaction has 7 static fields and 1 dynamic field. Dynamic field "asset" defines the transaction type and may contain additional fields specific to this exact transaction type.    
+DDK has 7 types of transactions. Each transaction has 7 static fields and 1 dynamic field. Dynamic field "asset" defines the transaction type and may contain additional fields specific to this exact transaction type.
 
-![Image](images/transaction_fields_and_types.png)
+![Image](../images/transaction_fields_and_types.png)
 
 The new block is generated based on top 250 transactions validated from transaction pool. Before applying the new block the transaction queue is locked. The newly formed block is broadcasted into the network to be validated and added to the blockchain.
 
-![Image](images/generate_new_block.png)
+![Image](../images/generate_new_block.png)
 
 After the block is generated and broadcasted the node receives similar broadcasted blocks from other nodes. When the node receives a broadcasted block it firstly checks if this block is the latest block that the node voted for. If it is then our node keeps up with the voting pace and it can proceed with re-sending this block to other nodes to verify consensus for transactions.
 
-![Image](images/received_broadcasted_block.png)
+![Image](../images/received_broadcasted_block.png)
 
 If the newly created block is not validated after broadcast - it will be handled as problematic block. The reasons for generation of problematic blocks may include network errors, block broadcasting delays or attacks on the network.
 
-![Image](images/problematic_blocks_handling.png)
+![Image](../images/problematic_blocks_handling.png)
 
 In order to maintain consensus DDK network has an algorithm for defining block height. Block height is a total amount of blocks applied by the network. DDK consensus algorithm covers cases of receiving blocks with equal block height, greater block height and lesser block height.
 
-![Image](images/block_height_handling.png)
+![Image](../images/block_height_handling.png)
 
 A newly installed node or a node that falls out of the network for some reason have an algorithm of getting back on board with the rest of the network. This procedure is called **synchronization**.
 
-![Image](images/network_synchronization.png)
+![Image](../images/network_synchronization.png)