XTRABYTES - A discussion about the whitepaper

in #xtrabytes7 years ago (edited)

I was asked by a friend to look into the technical aspects like possibility of building applications, transaction speed etc of @xtrabytes. The white paper is available here [1]

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
================

  1. Decentralization
  2. lower CAPEX
  3. Avoid e-waste
  4. carbon neutral
  5. lower OPEX
  6. security
  7. 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.

  1. What will be the signals used to identify whether a STATIC node is down ?
  2. In a network of n nodes, how to identify "split brain" scenarios ?
  3. how long it will take a "virtual node" to take over the STATIC node ?
  4. 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.
  5. 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.
  6. Is the failover mechanism implemented at the STATIC node owner or at the VITALs side ?
  7. 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 ?
  8. In terms of "5 nines" what is the availability of the STATIC nodes offered by this failover mechanism ?
  9. 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,

  1. Avoid e-waste
  2. carbon neutral
  3. 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
  • The white paper from the portal : https://xtrabytes.global/whitepaper.pdf ↩

  • Vote for me as STEEM witness

    1. You can do so by clicking the link above & enter your private key when asked for.
    2. Alternatively, visit https://steemit.com/~witnesses
    Sort:  

    Great analysis. I do think XTRABYTES has what it takes to kill Ethereum but it can't really compete with EOS. I'll quote from my recent article.

    How Do I Judge A General Purpose Smart Contract Platform?
    I do a simple test. I ask a simple question that would cover pretty much everything. So what's it? Can I run a Massively Multiplayer Online First Person Shooter on it after that game hit 30 million daily active players on this particular smart contract platform without ruining everything for the rest of the DAPPS on the platform?

    The only solid alternatives to EOS I can think of are Komodo and Enigma. Cardano is just a cheap knockoff. Take a look at KMD and ENG. You'll like them.

    thank you very much man

    Voted for you just now. Btw I have tagged you in a challenge on one of my latest posts as I feel you deliver great content, do check it out if you get time :)

    I think your Post is for a big group of people very helpful!
    Thx for making this Website for us!
    Upvote when your in my opinion @alokkamboj

    Wowo...a brief one....need to read in depth

    great content! and thanks again for following!

    I need clarification what was this all about?

    Its few questions and commentary on the non-technical white paper by XTRABYTES

    Coin Marketplace

    STEEM 0.19
    TRX 0.15
    JST 0.029
    BTC 63166.66
    ETH 2575.67
    USDT 1.00
    SBD 2.77