Interview with Borazalom:
Here are the questions and answers from the 777.
1. What happened with the testnet? Was it successful or are you still working on the bug fixes? Should we expect a V2 of the testnet?
The last testnet result was a success. However, even the failed tests help our development. I note this because everyone must understand that the failed tests and the successful tests are twins. Both are required.
After we achieve a successful test I will use a passed code if possible. A good example is XFUEL, where I use the code from the first testnet. Each testnet has a goal and a short lifespan. After the previous testnet is finished the next one will be executed.
The next testnet will be the public STATiC+PoSign test. For this test we will use more testers, therefore before we start the next test, we need to build one small testing infrastructure so as to evaluate the test results. We need a small team willing to help and support the other testers.
2. What is the expected timeframe for setting up and auctioning the L1 nodes? Will that be aligned with the level 2 and 3 nodes?
After the STATiC+PoSign test closed (where we use manual registered STaTiC-s ) then the next test will be the test of STATiC registration. Each level (L1, L2, L3) will be open. The original Level1 STATiCs was added to genesis block but all other positions will be available.
I don’t want to state any test deadlines but I hope these tests will be closed this year. This also depends on the teams who help execute and evaluate of tests. I hope the first teams will be available for testing shortly.
If the STATiC registration tests succeed, then I will add this code to the system immediately. And all level of registrations will be available thereafter.
3. Has the testnet proven that the technology works and is secure? Are the consensus mechanisms now fully tested?
We have more than just a successful test. We have XFuel where the technology is publicly available. I hope the XFuel enough secure. 20.000 blocks done and nobody hacked the system.
The XFuel contain some finalized parts of the consensus but not each part. I will be adding more and more passed code until we get the final consensus. Of course, the final consensus is always changing.
The good system opening the door to the changes. I don’t want hardcoded consensus like the BTC block size problem or simile other.
4. How can we validate that XFuel uses the PoSign technology? Is there any technical proof to show how it works?
1.) Start XFuel Wallet and enter to debug console
Welcome to the XFuel RPC console.
Use up and down arrows to navigate history, and Ctrl-L to clear screen.
Type help for an overview of available commands.
2.) Type getinfo
“version” : 1000001,
“protocolversion” : 10001,
“blocks” : 20012,
“timeoffset” : 0,
“connections” : 3,
“paytxfee” : 0.00000000,
“errors” : “”
3.) Get the hash of last block
4.) Dump the detailed info of this block
“hash” : “f6a45819b5393ccaec23195c012c91c4553b2999a49fb753129d6158dd3858ef”,
“confirmations” : 1,
“size” : 282,
“height” : 20012,
“version” : 1,
“merkleroot” : “cab3e8620645adb50a5a7bbe3d156105f64b51983353ee18036228ed0d55ebf5”,
“tx” : [
“time” : 1510086447,
“minerid” : 2,
“signature” : “3045022100a21645344d51435be6d032b44e6d847bfeffbb8c8681fea40a2cf0e5f7c16e4702205 2394414ad868339f434fdb8acfa779d85649d79f51e636036113c010781eaf2”,
“previousblockhash” : “10c85a6d2fced7b9c2d111eb87215c2ab06991916ef2c75c0dba992d6a801b79”
5.) You see the ID of miner who signed the block and the signature too. The last signer checked and accepted the all previous blocks too
5. Once PoSign is running, how are blocks created? Will block time remain the same? Like every 30s we’ll “mint” a new block via the static nodes? How do we ensure all transactions are verified by all nodes at the time of minting? We don’t make a new block until all transactions are agreed?
What if we have 2 servers on opposite sides of the world (Say JPY and UK) and it comes time to make a block… UK has no outstanding transactions so it creates one. Before JPY gets the block update it receives a transaction and sends it off to get approved by all servers… now we have a fork? How is would this be handled?
Each miner must watch several different events, such as the number of transactions, the elapsed time of the last generated block, who generated the last block etc… Summarize the “value” of this event each block have one “weight”.
If we have 3 miners and each miner generates a block at the same time and the generator of the last generated block is the #1 miner, then the weight of each block is different. The #1 weight is the worst and this block will never be accepted by other miners because the previous block generator is also t#1. The #2 will be the best and the #3 also acceptable if #2 is offline or doesn’t generate a block.
A block collision is a normal event. Each miner and client know what is the “best” block. The block of #2 maybe doesn’t contain all transactions, although this will not be a problem. The next block will contain the missing transaction. Each block has a unique weight therefore it will never create a fork.
Thus, the chain always contains blocks ordered by weight.
6. Blockchain generation 3.0 is also about interpolarity, where Blockchains can talk to one another. Are there any future plans for the creation of a module for communication between the Ethereum network, and other chains?
The system supports this, therefore, I hope someone will be creating an interpolarity module. The early stage of the system contains the bridge. This bridge connects the old chain and the new chain. These blockchains communicating with each other. The future interpolarity module just needs to extend this function to external blockchains.
7. The vision for XTRABYTES seems to be to make a better blockchain. So can you explain what you think are problems with the Blockchains that already exist and can you share very generally some long term hopes and vision you have for XTRABYTES into the future.
Lot of problems exist of the most blockchains. The problems of other blockchains and XBY don’t comparable at this moment, therefore, I just say some headwords:
- Limited blocksize vs. unlimited blocksize
- A lot of energy is required vs. no extra energy required
- The block reward is given to the miner vs. the reward is shared between the STATiC ( service providers )
- Unnecessary work ( mathematical calculation ) vs. required security checks
- All blocks stored to all miners vs. cloud type shared storage
- Fixed transaction cost vs. service-based cost ( cheap or zero transaction cost )
- A limited number of transactions vs. extreme high number of transactions
- Political governance problems ( not trust and anonym ) vs. provider related and trust
- p2p style network vs. overlay network
and many more
And the answer to your non-technical question is: Just read my first words at the beginning of this project. This is an experimental project. I just want a solid and stable platform to help the crypto world work better.