How the XtraBYtes Blockchain works.
As introduction XtraBYtes is a newly invented algorithm that does not require any traditional type of mining support, such as: POW or POS. We have created something called Proof of Signature (POSign)which ensures that 100% of all blocks will be signed by the system when they occur. The blocks are signed by the network of Master Nodes after verifying the transactions in the block.
Typical P2P Networks work something like this……
This is not the best type of network and therefore many problems exist which is why we will be using a type of “overview” network.
We will use what is referred to as a chord overview network where the the STaTiC and nonSTaTic nodes connect to “chord nodes”. The “chord network” is a “virtual overview” or in other words, the upper layer of the network and we will call it the Virtual Chord Network.
The STaTiC nodes and the nonSTaTiC nodes create the blocks… All nodes create the same block and all blocks have the same blockhash. Therefore, all block have the same ID (we will explain later why contain all blocks contain the same transactions).
Transactions work exactly the same as the block creation and so now we can see that all blocks will be the same in each STaTiC and nonSTaTiC and later you will see why this is, as we continue this explanation.
Each node (STaTiC and nonSTaTiC) is connected to one “virtual chord node” the chord nodes are only virtual, instead of being real nodes. If the block is ID=1 ( or if we create transaction then TR ID ) then this block will create the #1 virtual chord node and will then send the created block to the #2, #4, #8 nodes (this is an example of a network with just 16 virtual chord nodes) the #2 will send to #3 #5 #9 and so on…
The block creation time is not uncontrolled either. So, if we use 160sec block time (just an example because 160 seconds is easier to understand with a 16 virtual chord system).
Therefore, the chord nodes create blocks as follows:
#1 between 0–10 seconds
#2 between 10–20
#3 between 20–30
and continuing to #16 up to 160 seconds.
However, we will use more chords of course as this is just a simplified example so the process is more easily understood.
Therefore, no transaction or block conflicts occur and every peer knows who will create the block and who will first distribute the block.
But what if that creator block is down or attacked? Does it switch to a different STaTiC?
Since all chord nodes are virtual it is impossible to DDOS. There are no IPs or other relay identities available to attack.
Chord nodes are virtual, so they are never removed:
#1S = #1 STaTiC
#1C = #1 virtual chord node
If just #1S is online ( only one STaTiC ) then:
#1S will control #1C-#16
If #1S-#3S is online, then:
#1S will control #1C-#5C
#2S will control #6C-#10C
#3S will control #11C-#16C
If any STaTiC goes offline, for example #3S, then #11C-#16C will be shared between #1S and #2S
This is the reason why it is not important how many STaTiC nodes exist or how many STaTiC nodes are online or offline. The number of overview virtual network nodes is a constant. The block and transaction time are not part of the ID.
Also it is key to underyand STaTiCs and other nodes do not have to learn about the blocks simultaneously… The transactions distribute throughout our network, sequentially, over the 120 second block time in intervals that eventually get out to the entire network before the next block is created.
With regard to network lag, this is not relevant because the network is virtual. Therefore if lag exists it is equal across the entire virtual network. So, the virtual overview network or the Virtual Chord Network solves the problem.
To simplify this explanation for those less technical :)
P2P (peer to peer file sharing type systems) is like water in a lake. The Virtual Chord Network is like a series of canals. We use water, just like in the lake, but the lake is uncontrolled.