- Problems Targeted
- Current Industry Landscape
- Proposed BCLDR Solution
- Mistaken Statements from WP
Block Collider (BCLDR) claims to provide solution for multi-blockchain integration, which is a new blockchain itself. But analysis of technical details revealed from their WP and online docs shows that this is neither blockchain nor chain bridge.
This review has been made based on
- Block Colldier published Whitepaper (v.0.9.9 Jan 17 2018)
- Official project documentation published on their site
- Authors have some high-level understanding of problems and tendencies in blockchain technology
- Authors show good imagination reflected in proposed solutions
- Authors show very superficial understanding of the blockchain technology basics
- Described solution lacks the signigicant technical details (e.g. what hash fuction they use, how consensus is being achieved, etc.), which makes it not a solution but rather a proposed direction
- Even the proposed direction seems not to be leading to the solution of the problems stated
- A lot of mistaken statements done in the white paper text
- Sources lack important papers from the research domain
Problem | Solved? — | — Smart-contract initialization from other blockchain | no High latency and fees | no Side chains centralize network | there is no such problem Secure tx bridges between chains | no Smart-contracts auto execution | no such problem, and if BCLDR is what it is by their WP, it has nothing to do with SC execution Dapps modularity | nope Dapps load balancing | nope
Current Industry Landscape
Crupto community has being working on the blockchain bridges for a while. Mostly elaborated works to date are:
An inter-blockchain communication solution usually consists of
- Core chain (Relay in Polkadot, Cosmos Hub in Cosmos) with its own consensus rules, scripting, etc
- Sidechain plug-in interface (ABCI in Cosmos, Parachain Rgistry & Queues in Polkadot)
- Interchain communication protocol and messages routing
They typically use messages for data transport between chains and SPV proofs for validation of tx existence in bridged chain. The communication between blockchains is implemented in two-side fashion, i.e. not only core chain takes messages from integrated chains, but reverse communicaion works as well, i.e. ETH and BTC chains get data from other blockchains with the protocols suggested. In other words, there should be Bidirectional Transferability between chains. This is achieved with scripting, by providing special smart contracts \ adresses for interchain data transfer and assets exchange on both brigded blockchains.
Proposed BCLDR Solution
The only information BCDLR takes from other (“bridged”) chains and operates with is hashes. Hash itself brings no valuable data, it is used to verify validity, integrity and tamper-proof of the tx data. In other words, BCLDR does not take transaction data from Bitcoin or Ethereum blocks. It just takes block hashes.
No particular details have been given on BCLDR chain arhitecture, state transition, virtual machine or scripting language. While these things are cruicial for designing blockchain bridges.
There is no Bidirectional Transferability between chains in the proposed solution. No interface for new chain connection given. No specificaions of interchain communication protocol provided.
As such, this solution cannot be treated as a blockchain integration. Rather, it is kinda restricted in-chain analytics tool. If you take etherscan.io and blockchain.info and put them into one box, you won’t get new blockchain with it. Neither will you integrate anything with the ETH and BTC chains this way.
BCLDR Design in Brief
What “Mining” is in BCLDR
Spoiler: It is quite far from what people take as mining in blockchain…
Suppose they want to bridge BTC, ETH and NEO with BCLDR
BCLDR mining algo is
Take last block hashes from these chains:
BTC_hash: 0000000000000000006abfe31e59af9f81b3fc84a1a25a8fdc095e429dc6dffa ETH_hash: 73413ff99013f6007b72e299aee87da63311602ae4dfb1466b254b7c89b8e1bd NEO_hash: 0b58e3e1980eb79c293ee1d047997c5a7092da8d49813c2407e90f85e0ba1f9e
Calculate (increnemtally changing nonce) the string
hash_attempt := hash(miner_public_key + nonce)
until string edit distance of hash_attempt becomes lower than some specified value D:
where - cosine similarity of 2 strings a and b. This metric is being treated as a “distance” between hashes (hash strings are vectors in some multidimensional space). This is why they call this algo “Proof of Distance”.
- Once hash_attempt satisfiyng the conditions in step 2 has being found, they take it as the block hash
Then, each transaction is being “mined” as well, i.e. by finding another hash_attempt
hash_target := hash(transaction_data) hash_attempt := hash(miner_public_key + nonce)
so that tx_dist would be affordable for miner to put the transaction in block
Each block can only include up to some sum of transaction distances ( tx_dist ), determined by the amount of Emblems the block miner has access to The transaction edit distance is then the distance between the hash_attempt (based on the miner work) and the hash_target transaction ID (TXID):
tx_dist := RO(hash_attempt, hash_target) * byte_size(transaction_data)
- No specifications on how “mined” transactions get into the “mined” block
Well, requesting miners to solve n+1 tasks (where n - number of txs miner wishes to put into the block) at once looks pretty weird. Moreover, the computational challenge used for block mining (i.e. distance between hashes calculated as Cosine Similarity) seems not to fit well with the network building. Here is why:
For some (probably often) cases even for two-chain case the computatinal challenge described above just has no solution. Let me demonstrate this on a school geometry example:
If orthogonal vectors A and B happened to be our hashes,
than for any
there is no such vector C satisfying the mining puzzle conditions
BCLDR block hashes depend neither on tx data included in the block nor on previous block hash. So nothing here constructs any chain of blocks. This is not a blockchain. By definition.
This kind of “mining” does not solve Byzantine Generals Problem. Still keeps unclear what particular problem does it solve… Seems that the only purpose here is just to have anything like “mining” on board.
Okay, maybe it’s just a ledger to store data from other blockchains and serve them faster? Well, nothing being said about how tx data being acquired, structured, validated and secured. Maybe it is just an offchain-ledger which stores hashes taken from blockchains? Alright, but why then it makes sense at all and what value does it bring? - are still open questions.
- No tx data or state being moved across chains, just hashes
- No integration and cross-chain features (albeit claimed so)
- Claimed to encapsulate current state of each bridged chain. But it doesn’t
- They don’t reveal, which hash function they use. Hey come on, this is the corner stone of every blockchain. SHA256 means ASIC, Ethash means GPU farms. What do you get?
BCLDR Block velocity is claimed higher than in fastest bridged chain. But it doesn’t. Actually, we show below that it’s indeed slower than the slowest bridged chain.
A herd of buffalo can only move as fast as the slowest buffalo. Buffalo theory
As there are several competing chain forks each moment of time, finally only one of them (the longest one) wins to gain the consensus. Multi-forks in bridged chains will lead to forks in BCLDR. But finally every of them but one become orphan.
Let’s consider the excerpt from the WP stating that “effective block velocity” is increased:
Let alone the nonsense formula giving 50% increase, just keep in mind the “one fork wins” rule we mention above. Which obviuosly means that BCLDR blocks 2,8 and 6 are stale. Hence the “velocity growth” is just 7/6 (7 blocks in BCLDR vs 6 blocks in Ethereum), i.e. 16.6% increase (far from 50%). Moreover, since BCLDR should take encapsulated state from all bridged chains, it has to wait the state change to be performed in the slowest chain. Moreover, it has to wait sufficient number of confirmations, to be secured from the double-spending attack on bridged PoW chains.
Furthermore, it cerainly should take some time t to mine the block in BCLDR. Which adds more latency to the block production, hence making it not even equal to BTC block latency, but slower. Meanwhile BCLDR authors don’t provide any assesments ot real measurements of this time t. In Bitcoin, the algorithm tunes mining difficulty to keep it about 10 mins. In BCLDR WP, nothing stated on this matter.
Mistaken Statements from WP
Here I put some quotes from Block Collider whitepaper which contain false statements, with my comments.
“Merkle root transaction data”
Merkle Tree Root stores just a hash (of hashes of leafs of hashes of other leafs of hashes etc…) it has no tx data.
Because of the combinatorial nature of base tuples. the Block Collider blockchain is consistently faster than the fastest bridged blockchain.”
I explained above why this is wrong
Due to the variability of block discovery on all blockchains, where Ethereum for instance ranges from 6 seconds to 2 minutes and Bitcoin commonly ranges from 5 to 15 minutes, it will be impossibly difficult for miners to try to preempt combinations that cause the Block Collider blockchain sequence to favor one chain. This drastically increases the computational difficulty of the multichain thwarting attacks that involve shifting mining power on the Block Collider.”
BCLDR mining time has nothing to do with the block times in other blockhains… Sooner you get the blocks from other chains, sooner you get input data and start to mine BCLDR block. Still the time which required to solve the Proof of Distance mining puzzle depends on algorithm you use for solving it ( Wagner–Fischer or other) and computatinal power you posess.
Decreasing the block time has consequences for stale rates and centralization incentives. To combat these issues, Block Collider splits block mining from transaction mining
As we showed above, block time is not decreased. Not clear how mining split could help here (as all tx could be pre-mined)
Traditional hash-based approaches can be thought of as finding a threshold on the distance between the discovered hash, and the arbitrary reference point of “zero”
Definetely, Ethash cannot be thought of as this. See Ethereum Yelow Paper for details
From an intuitive standpoint, taking a hash of data transforms the data into an irrecoverably different kind of space — that is the intent of hashes, which are also known as “trapdoor functions”. Since the Collider chain is generating its own hash, which references other hashes, for simplicity’s sake no additional space needs to be defined, and all operations can take place between hashes without entering any trapdoors. This commitment to elegance allows for interesting geometric interpretations of hash space, since Cosine Similarity is symmetric and is a well-formed metric. Moreover, as byproduct of computing an edit distance, the algorithm generates a description of how to edit one string to transform it into another, so that validating the edit distance is computationally simpler than computing it.
Lastly, whereas many hash algorithms are intentionally designed to be computationally expensive with no other purpose, edit distance is actually a useful problem to solve. If optimizations are found for inner loops of artificially constructed computational challenges, no great progress has been made. By putting a real, useful problem at the core of Block Collider’s computational challenge, any resultant work towards optimizing solutions also benefits the rest of the computer science community in the form of better core algorithms
This. Is. Cute.
NRG mining rewards diminish over time so that mining can continue ad infinitum on its fixed supply.
Nope. Why should miners do the job without an economic incentive? Once reward < costs, the game is over.
Based on their technical documents, Block Collider design, approach and architecture is in its very embryo state. If they implement what they claim to do in their WP, I think they hardly would deliver a “high-speed distributed multichain ledger”.
Notwithstanding weak technical study presented in project documentation, Block Collider Node Github repository has more than 1.3k commits most of which done during Q2 2018. So there is a codebase. ==I admit that as discrepancies between source code and docs is the constant pain of startups, maybe the analysis of their codebase could reveal some better picture==.