I was asked by a friend to look into the technical aspects like possibility of building applications, transaction speed etc of 
1. First Steps
The obvious first step was to look in Github for the codebase, activity in the repository, issues reported, number of community members active etc. The repo https://github.com/XtraBYtes/core has some interesting C++ code Java servlet based code. Wallet code seems to be based on QT.
As per the community, most of the coding is done in a private repository due to pending patents. Also the white paper is non-technical.
Details of the authors / developers also are available:
// XtraBYtes - The Proof of Signature Blocktech Superchain - http://xtrabytes.global
// Copyright (c) 2017, Zoltan Szabo. All rights reserved.
// Copyright (c) 2017, XtraBYtes Founders and Developers ( see AUTHORS )
// Licensed under GNU General Public License Version 3 or later (the "GPL")
from: https://github.com/XtraBYtes/core/blob/master/src/genesis.cpp
LICENSE file gives more details on the founding team and trade mark holders.
Trademarks
==========
XtraBYtes is a X-Trademark of founders Dave and Zoltan. All other brand
and product names are X-Trademarks, registered X-Trademarks or service
marks of their respective holders.
The above details are mentioned as the developers are not really anonymous and they are avaialble on discord for discussions.
Now, lets head to the white paper.
2. Who is Miranda Westerhof ?
The author of the white paper is "Miranda Westerhof"
3. Diagrams from the website
The following give the impression of a central component called VITALS - this has made things little confusing as there seems to be a central control ? There should be clear details in the white paper / blue paper I belive.
The second diagram, somehow made me think the platfrom is healthcare centric.
The reason being DICOM is a common image exchange format used in healthcare.
4. The Whitepaper
The colourful whitepaper is an introduction to the future plans and outlines the value proposition.
A central objective in the development of the XTRABYTES platform was to create a secure digital currency without the centralized dependency on miners who participate in an energy intensive consensus algorithm required to solve blocks.
Taking head on centralization, which is theoratically & technically even possible bitcoin blockchain is an interesting uniqueness. Also barriers like computational power, monetary requirements to start mining etc are identified as problems and XTRABYTES aims to address them.
Value Propostion
================
- Decentralization
- lower CAPEX
- Avoid e-waste
- carbon neutral
- lower OPEX
- security
- new proof of Signature Algorithm
4.1 Decentralization
STATIC nodes and VITALS are the means to achieve decentralization.
As a security feature, it is a requirement of nodes to sign each block, as this mandates that the nodes must be able to communicate with one another rapidly and seamlessly.
Looks like this means, every transaction should be signed by every STATIC node in the network. So assuming that there are n STATIC block, every transaction will be verified by all the n STATIC nodes to be valid and secure. VITALs network infrastructure and secure protocol ensures this happens.
Now, this is where its getting bit difficult to understand.
VITALs is defined as:
VITALS comprises a private virtual network directly interconnecting the online STATIC nodes; this network is extended over public networks, effectively providing VPN-like functionality to the network of STATIC nodes. VITALS therefore support the communication needs of the XTRABYTES blockchain by providing interference-free direct paths between nodes to ensure security and speed when processing transactions. The VITALS network is comprised of fixed virtual nodes that corresponds to and is controlled by one or more STATIC nodes.
This sounds like a MPLS with assured QoS. The way to achieve this should be to buy MPLS bandwidth with assured QoS from backbone providers or VPNs with assured QoS. Routing of TCP packets also MUST be done to ensure interference-free, direct, secure paths between the nodes.
Another alternative will be use to P2P nodes.
So there will be a "centralized, controlled, censored network where each and every packets source and destination is inspected ensure interference-free, direct, fast" communication ?
This sounds like censorship & centralized control.
4.1.1 Few edge scenarios
This is a discussion of edge scenarios applying VITALS and STATIC nodes
4.1.1.1 Transaction verification
Every transaction will be verified by all the n nodes in the network. This means, at every point in time, every node must know the total number of active STATIC nodes in the network. A possible denial of service attack could be to keep increasing the number of static nodes n+1 ... n+2 etc and keep oscillating between n, n+1 and n+2. So isn't possible to bring the entire network into knees by having just 3 STATIC nodes in control ?
4.1.1.2 using VITALS to deny STATIC node availability
From the defintion, the VITALS sounds like a MPLS/VPN system with centralized control and managed all the PULSE communications between the nodes. So, at any point of time, whomsoever is controlling VITALS can deny or re-route traffic to any node or change the priorities ?
4.1.1.3 Cost of maintaining VITAL network
Assuming that this a high QoS network, where will the OPEX to maintain the VITAL network will come from ?
4.1.1.4 STATIC node availability
If a disruptive agent attacks and disables a STATIC node, one or more of the other STATIC nodes will take control of the virtual node until the original STATIC node has been brought back online.
From the white paper, it seems there will be a heart-beat and high availability mechanism built into the STATIC node infrastructure to make auto failover possible.
- What will be the signals used to identify whether a STATIC node is down ?
- In a network of n nodes, how to identify "split brain" scenarios ?
- how long it will take a "virtual node" to take over the STATIC node ?
- If during the failover, before the virtual node takes over, the STATIC node comes back online, this will create a race condition. Which nodes take priority in such a senario.
- How will the virtual node know the configurations, say hardware, keys etc of the STATIC node that went down ? As the node is already down, the information will not be anywhere.
- Is the failover mechanism implemented at the STATIC node owner or at the VITALs side ?
- If an attacker, who has one or more STATIC nodes decides to periodically bring up and down the STATIC node, how will the virtual nodes identify the attack ?
- In terms of "5 nines" what is the availability of the STATIC nodes offered by this failover mechanism ?
- What if k nodes goes down at any point of time where k = n and k little less than n. Will there be always n virtual nodes available to prevent this scenario ?
4.2 CAPEX
With the points mentioned 4.1 it sounds like there will be a cost to run the high available network which will create not just CAPEX but OPEX also to the network unlike any-other blockchain network. This combined with the need to maintain VITALS, fail overs etc there should be a initial CAPEX to ensure the availability of near infinite number of nodes for the failover of all or a large number of loads, this sounds like a very difficult scenario.
The scenario 4.1.1.4.9 seems to be most difficult or near impossible one to address.
It will be great to understand more and see how XTRABYES addresses CAPEX issues if this assumption is true.
Along with CAPEX, the value offered,
- Avoid e-waste
- carbon neutral
- lower OPEX
Also stands questionable at this point in time.
4.6 Security
Interchangeable security / cryptography protocols and usage of SHA-512 sounds very impressive.
With Proof-of-Signature requiring that every node sign every transaction, the entirety of the STATIC node network would need to be compromised simultaneously to undermine the integrity of the blockchain.
With the attack scenarios mentioned above, this may probably result in a race condition and lock down of transactions.
the XTRABYTES developers go several steps further than SSL and Microsoft's signed software to ensure the security of the signature protocol.
- What is the relevance of SSL here ?
- Microsoft's signed software ??
Not sure how and why this is relevent or application or mentioned in this context.
Signature keys are protected to deter tampering. Online keys are intermediate and can easily be changed if necessary. Therefore, if a signature is compromised, the associated STATIC signature will automatically be revoked as the consensus among nodes has been violated. The owner of the affected STATIC node is then warned to generate a new signature before the node can resume participation of the network.
If this is similar to loss of a private key, how theft of a key is automatically identified ?
If a disruptive agent attacks and disables a STATIC node, one or more of the other STATIC nodes will take control of the virtual node until the original STATIC node has been brought back online. The transmissions between the STATIC nodes to verify consensus are always protected by encryption.
- Who owns and run the virtual nodes ?
- What is a virtual node ?
- How will all STATIC nodes be updated of the presence of the virtual nodes ?
- What happens if all the STATIC nodes goes down ?
5. Discussion
The white paper has little information to make a technical assessment. There is also missing information like how failover is handled, how VITALS are envisioned - is it at the applicatio layer or is it at the network (TCP/IP stack) layer etc.
DApps and other concepts looks beautiful and if implemented correctly we will finally have a worthy competitor to Etherium and the coins running on the Graphene blockchain which now boasts of able to handle the largest number of transactions. (Bitshares, STEEM, GOLOS, upcoming EOS). Looking forward for the great news.
Notes: The author has experience in designing & developing a high availability solution for the telecom network with 3 nines availability.
References
Vote for me as STEEM witness
- You can do so by clicking the link above & enter your private key when asked for.
- Alternatively, visit https://steemit.com/~witnesses