One of the main reasons for why $DOT has been receiving so much attention lately in the cryptocurrnecy space (particularly in the markets) is because of the project’s promise of future interoperability with Ethereum, Bitcoin, and a plethora of additional cryptocurrency protocols.
Below is a graphic from the project’s documentation that illustrates what this connection / bridge would look like within the Polkadot ecosystem:
While this bridge is highly theoretical and contingent on the project’s ability to succeed at something that has effectively never been done before, it appears that the overall blockchain markets are highly optimistic that this plan will come together.
Breaking Down Polkadot’s Proposed Bridges
Documentation on these proposed bridges by Polkadot can be found on their ‘wiki’ here: https://wiki.polkadot.network/docs/en/learn-bridges#bitcoin-bridge
Evaluating the Plans for a Bitcoin Bridge
Since this is presented first in the documentation’s order, we figured it would be prudent to make this our first destination for closer scrutiny / analysis.
Usually we wouldn’t take too much time to look into a project’s technical merits in this manner, but since Polkadot’s success in this endeavor has massive implications for the future of the project (especially its price action).
The specification for the Bitcoin bridge is depicted below:
What is ‘XClaim’?
The hyperlinked word ‘xclaim’ takes us to a whitepaper titled, ‘XClaim: Trustless, Interoperable Cryptocurrency-Backed Assets’
The whitepaper itself is fairly short, so let’s take a look into what its saying.
Per the Abstract:
“XClaim offers protocols for issuing, transferring, swapping and redeeming CBAs securely in a non-interactive manner on existing blockchains. We instantiate XClaimm between Bitcoin and Ethereum and evaluate our implementation; it costs less than USD 0.50 to issue an arbitrary amount of Bitcoi-backed tokens on Ethereum. We show XClaim is not only faster, but also significantly cheaper than atomic cross-chain swaps.”
From the Abstract, its relatively simple to tell that what is being proposed here is not something that’s based on a trustless protocol.
Reason Why This isn’t Trustless
Because Polkadot itself is not trustless. But it does provide a great framework for someone that would like to construct a trustless blockchain protocol.
The reason why is due to the consensus mechanism that Polkadot uses. Proof of Stake can never be considered ‘trustless’ by default because it requires a certain fault tolerance be met in order for the blockchain to continue.
If that fault tolerance is not reached, then the blockchain will halt entirely.
This was witnessed with Solana recently.
Solana Blockchain Halt Foreshadows Polkadot
In case readers are not aware, Solana’s entire blockchain came to a halt in the beginning of December due to what the developers of the protocol called a ‘bug’.
Quick Side Note: Solana is also funded by the same venture capital firm that backs Polkadot, which is NGC (NEO Global Capital); notice how both projects have had excellent performances this month. Remember this and remain mindful of the fact that cryptocurrency markets are rarely, if ever, propelled by genuine technical advancements and very few development teams are motivated or capable enough to make said advancements that they propose. Thus, to their credit, they remain the world’s greatest fiction writers alive.
Before we get into Solana, its worth taking a second to step aside and prove the claim made above about NEO Global Capital’s (NGC) involvement in the protocol:
Notably, Multicoin published a report back in 2019 titled, ‘Binance is Blitzscaling’, in which they praised the exchange and also disclosed the fact that they were owners of the BNB tokens.
That statement can be seen below:
According to Multicoin, blitzscaling is defined in the following passage (just an fyi; a bit of insight into Binance’s inner workings):
“When you blitzscale, you deliberately make decisions and commit to them even though your confidence level is substantially lower than 100 percent. You accept the risk of making the wrong decision and willingly pay the cost of significant operating inefficiencies in exchange for the ability to move faster. These risks and costs are acceptable because the risk and cost of being too slow is even greater.”
One key part that many seem to have missed however, is the fact that Binance has made it openly known that they shift their user’s assets to other investments (illegally, of course, since they are not registered in any capacity to do so and certainly aren’t providing any transparent accounts of where those funds go + users are not given interest).
Specifically, Multicoin states:
“* Binance now automatically stakes their users’ assets on their behalf and distributes the yield back to them. This incentivizes users to keep assets custodied on Binance and unlocks the ability to quickly trade those assets without the need to unstake them and send to an exchange. This drives more liquidity on the Binance exchange and more assets custodied with Binance, which in turn drives greater network effects.*”
Hmm, not quite. By enticing users to “lock” their assets up with Binance in exchange for the ability to stake on their platform to yield returns in assets of questionable / no value, Binance is able to essentially able to pay people in fraudulent / fake money in exchange for the ability to use their funds to realize potential profits gained from them while they’re being “locked up”.
Since there is no way to validate that those funds are actually locked up, there’s no reason for why users should assume that they are. Instead, it is much more likely that said funds are being put to use for Binance to trade against users on the same exchange or engage in higher level ‘DeFi’ protocols within the space or slightly outside of it (i.e., with Genesis Trading or another entity of that nature).
BTC Parachain Documentation
According to the documentation:
“The BTC Parachain connects the Polkadot ecosystem with Bitcoin. It allows the creation of PolkaBTC, a fungible token that represents Bitcoin in the Polkadot ecosystem. PolkaBTC is backed by Bitcoin 1:1 and allows redeeming of the equivalent amount of Bitcoins by relying on a collateralized third-party.”
Then they provide the following graphic:
Everything in their description is fine up until the point that they claim that it, “Allows redeeming of the equivalent amount of Bitcoins by relying on a collateralized third-party”.
The main issue here is in the introduction of concepts that are not externally valid on the Bitcoin protocol (breaking the trustless property and thus, creating an unauditable pipeline / transferral of funds - something that is the antithesis of blockchain’s purpose).
Below is a diagram of how Polkadot intends on providing interoperability with Bitcoin:
As we can tell from the chart above, the Bitcoin that is being exchanged is supposed to somehow be “locked” and this ‘locking’ action will trigger the issuance of tokens called, ‘PolkaBTC’. Accordingly, Bitcoin has to be redeemed by “burning” PolkaBTC tokens.
Major Issue in This Scheme
As we move on, we can see that they validate that the transaction to the ‘XClaim protocol’ has occurred by mandating the turnover of the transaction ID as well as the block header of the block containing the relevant transaction.
The documentation even includes a graphic that shows the proposed workflow for this exchange (which results in the issuance of PolkaBTC):
Getting into the Major Issue
The major issue here is not in the design of the workflow. Its logically valid and there’s no reason to assume that it wouldn’t work.
But the issue comes in ensuring that the Bitcoin are not moved afterward.
For instance, if John decides to send 5 BTC into this ‘XClaim’ protocol, minting 5 new PolkaBTC for himself within Polkadot’s ecosystem, what is to stop John from then moving those 5 bitcoins back to his own wallet before redeeming those 5 PolkaBTC for 5 free bitcoins?
The documentation mentions a lot about “locking” bitcoins on the Bitcoin protocol, but there are are no specifics given as to how this process would take place in a manner that:
Ensures that the sender no longer has access to said bitcoins (or ensures that only they have access if they’re supposed to be redeeming these PolkaBTC directly for their Bitcoin)
Guarantees that the Bitcoin remains locked in a manner that is actually trustless and also valid on the Bitcoin protocol itself (if it is outside of the Bitcoin protocol or relies on schemes / structures foreign to the protocol, then we must consider the implementation to be completely ‘hypothetical’ in nature until the final payout is settled).
Seeking More Information
There is a chance that the documentation we read above simply does not contain the relevant details on how Bitcoin is supposed to be “locked” during this ‘swap’ (and why this would need to be collateralized if the swap is 1:1 with these minted PolkaBTC tokens).
Additionally, there was nothing included in the documentation that indicated that nodes on Polkadot would be running a Bitcoin client, so its not yet known how the protocol would be able to gauge whether the block header + transaction ID that they’re receiving is legitimate without also running a Bitcoin full node.
To find out more information we visited the official GitHub repo for the ‘BTC Parachain’, which can be found here: https://github.com/interlay/BTC-Parachain
It appears that we need to look more closely at the ‘collateral’ section in order to ascertain how this “locking” process is to take place:
Clicking the link above takes us to the part of the master tree that contains the code for the implementation of the ‘collateral’ module:
This may seem like a deadend, but it isn’t.
By examining the ‘cargo.toml’ file here (appears this is written in Rust, good choice), we find a link to the documentation included within the ‘notes’ of the code:
For those that wish to inspect this link for themselves, the one present in the code at the time of visit is: https://interlay.gitlab.io/polkabtc-spec/spec/collateral.html
Which should take users here:
Unfortunately, this specification contains little to no information on how the Bitcoin is to be locked.
Below are the excerpts from the documentation that mention anything about “locking” (which seems to mainly be in reference to the ‘collateral’ rather than the Bitcoin itself ; it is still unknown what the collateral is supposed to be, how it will be valued [oracles, likely], or why it is necessary):
Another problem can be found directly in the ‘overview’ section where it states:
“The Collateral module is the central storage for collateral provided by users and vaults of the system. It allows to (i) lock, (ii) release, and (iii) slash collateral of either users or vaults. It can only be accessed by other modules and not directly through external transactions.”
The fact that this collateral module can only be accessed by other modules and not via ‘external transactions’ means that we’ve abstracted beyond the Bitcoin blockchain - which makes it even more important for us to question how the bitcoins are being locked up or how we can prove a transaction unless the network is running Bitcoin full nodes.
Further Problems Caused
Unsurprisingly, the faulty foundation upon which the ‘interoperability’ protocol for Polkadot is based on leads to even greater calamities further along down the line.
We can see this clearly in the specification for the ‘PunishmentFee’.
Specifically, the documentation states:
“If a Vault misbehaves in either the redeem or replace protocol by failing to prove that it sent the correct amount of BTC to the correct address within the time limit, a vault is punished.”
Again, there are a couple of logistical issues here - and the first one is going to sound stupid, but its legitimate.
Major Issue With Time-Based Punishments: How is ‘time’ determined?
This may seem like a no-brainer, but we need to remember that we’re talking about blockchain, which means that these networks are p2p (peer-to-peer).
Thus, if this network is decentalized (and Polkadot furiously states that they are), then messages must be propagated to the network.
In other words, there is no way for one node to inform the entire network of an event all at once.
The node must spread the information to a certain subset of nodes that it is connected to, then those nodes must spread that information to other nodes and so forth until that information is propagated across the protocol.
Breaking Down Polkadot’s Network
As stated numerous times throughout Polkadot’s marketing and documentation, they rely on ‘Substrate’ to serve as the backbone of their actual network.
Therefore, any and all information about the network structure of Polkadot must be ascertained from Substrate’s documentation (as ‘substrate’ is mutually exclusive from Polkadot as a project).
This fact is enumerated directly on Parity’s website (creators of Substrate). Specifically, they state:
With that being said, if we chase down Substrate’s documentation on how they’re implemented, we find our answer on the library / structure they use to orient the actual network of Polkadot.
It is stated (verbatim) that:
“To ensure that nodes can join or leave the network at any time without affecting overall network connectivity, Substrate uses the Rust implementation of libp2p, a promising network stack that has everything needed to set up a decentralized network environment.”
Great! We just need to take a look at libp2p’s documentation and we should be up to speed on how nodes communicate on Polkadot’s network.
The design of networks using libp2p is outlined in explicit detail in their documentation.
Taking a Step Back to Look at the Bigger Picture
We’re getting a bit deep into the technicals here, so now is a good time to step back and remind ourselves what we’re doing down this rabbit hole:
A) Polkadot’s documentation details something called a ‘punishment fee’, which is doled out to “vaults” that do fail to prove it sent out the correct number of bitcoins to the correct address within a certain time limit
B) We challenged the implementation of such a standard by proposing it would be impossible to set a time limit on a vault since different peers on the network will find out about the vault requirement at different points in time (in fact, the entire network may have a different perception of the time limit). This cannot be reconciled by having one node get the time from the other because there’s no discernible way to tell if that node is lying or not. Additionally, there’s no way for that node to tell whether it is one of the first to have received the appropriate trigger to initiate the countdown
C) In order to prove our hypothesis true, we need to first establish how nodes are oriented on Polkadot’s network.
D) Since Polkadot uses Substrate (which we provided proof for), we began digging into Substrate’s documentation for more specifics on how nodes are oriented.
E) Substrate’s documentation indicated that they use the ‘libp2p’ library for node communication
F) Now we are on libp2p’s site and evaluating the documentation there to verify our assertion that Polkadot’s network communicates via ‘gossip protocol’, which means that one node tells a few nodes information it has received (relay), then those nodes tell a few nodes (each), and so forth until the information is propagated across the network
The picture above provides an accurate visual for how the gossip protocol works in this case.
Notice how each node is only communicating with 3 unique nodes, yet the total # of nodes receiving the information grows exponentially [O(n)<sup>2</sup>].
This is how propagation works on the Polkadot network. And while this is an efficient means of disseminating information on a p2p network, it introduces inevitable latency between messages (i.e., some amount of time must elapse between the receiving of a message and passing it on to a peer; this is a limitation of space, time and physics if we wish to preserve the property of ‘decentralization’)
As shown above (hopefully) the latency has a cumulative impact contingent on how many ‘hops’ must be made from the source to its destination.
Revisiting the Concept of ‘Locking’ Bitcoins on the Polkadot Platform
This may seem redundant, but it feels really worthwhile to take the time to go back and look at the notion of ‘cryptocurrency-backed assets’ (collateral) that Polkadot claims will be used to back its platform.
Within the ‘README’ of the interlay GitHub repo that we visited earlier, there’s a hyperlink to additional documentation on the protocol:
That link takes us here
Even though we’ve already reviewed this protocol (albeit, in a very topical manner) via the whitepaper we looked at earlier, it seems worth it to quickly go through this documentation here to see if there’s any greater clarification on the supposed ‘locking’ process that this protocol introduces to the interoperability equation that is liberal enough to be considered valid on the Bitcoin protocol but strict enough to restrict the sending user from arbitrarily accessing their bitcoins.
There is a diagram provided below, but it still doesn’t give us any greater information about what’s going on:
The design principles of this protocol are also flawed in a number of ways. But before we enumerate on those, let’s take a look at what they are below:
Great, so we have the promise of ‘secure audit logs’, ‘transaction inclusion proofs’, ‘proof-or-punishment’, and ‘over-collateralization’ (that last one is still a bit of a mystery since collateral should be wholly unnecessary if the process is trustless ; collateral is essentially an insurance policy on something that requires trust).
Flaw in ‘Secure Audit Logs’
According to the documentation, secure audit logs are logs that are, “Constructed to record actions of all users both on Bitcoin and Ethereum”.
This is a curious facet of the proposed protocol because there already exists such a construction. Its called ‘blockchain’ - literally, the distributed ledger itself where a record of all transactions are kept. Keeping another record is needlessly redundant, so this facet of the protocol design makes little to no sense.
Transaction Inclusion Proofs
According to the documentation:
“Chain relays are used to prove correct behavior on Bitcoin to the smart contract on Ethereum”
The first question that comes to mind is, ‘What exists to ensure that the chain relays are actually proving correct behavior?’ ; there seems to be nothing in the design that accounts for potential misbehavior by these relays. Therefore, we must trust that they’re going to do the right thing.
Objectively, there’s nothing wrong with this - but given the design goals of Polkadot, this undermines the project’s purpose.
We already explored above why the ‘proof of punishment’, as specified will ultimately be ineffective (hint: Because there’s no way for the network to come to a consensus on how much time a vault has remaining because there is no way for the network to come to a consensus on when the trigger action began due to the gossip protocol).
For this, the documentation states:
“Non-trusted intermediaries are bound by collateral, with mechanisms in place to mitigate exchange rate fluctuations”
There are a few confusing things here to be honest:
The first question that must be asked here is:
How is there even a question of ‘trusted’ vs. ‘non-trusted’?
According to the documentation on Polkadot’s website under “bridges” (right above the ‘Bitcoin bridge’ section):
“Bridge designs come in a variety of flavors ranging from centralized and trusted to more decentralized and trustless. Polkadot favors the latter bridge designs for its ecosystem…”
Below is a screenshot of the documentation as well so that it can be read in its full context:
The documentation actually goes further than this, stating (on the same page) that:
“Bridges are specifically for making the Polkadot ecosystem compatible with external blockchains such as Bitcoin, Ethereum, or Tezos (among others). For information on XCMP, the native interoperability technology that allows parachains to trustlessly communicate, please see the dedicated crosschain page on the Wiki.”
While the XCMP is a bit different than what was described with the ‘XClaim’ protocol that is touted in other sections of the documentation, the same flaws still exist in the XCMP that existed in the XClaim protocol that we dissected earlier.
At this point, it feels like we’re beating a dead horse into the ground and its likely that most readers probably get the point by now.
Polkadot is a brilliantly designed project in many ways, with a ton of potential - but that potential is cut down short by its incessant need to take shortcuts on portions of the protocol that do not mandate such shortcuts be taken.
There are ways for Polkadot to integrate 1:1 transfers to their protocol in a manner that does not require them to use a ‘middleware’ protocol without a valid consensus, but that would require Polkadot itself to have a valid consensus algorithm (which must be Proof of Work, ultimately).
This idea and concept is one that the space will try vigorously to fight, but at the end of the day - its for the better of the protocol overall.