Bitcoin ABC’s CTOR Sharding Proposal Won’t Scale, According to New Report
ABC’s CTOR Sharding Proposal Won’t Scale, According to New Report
In a blog post from earlier this week, Bitcoin Unlimited Lead Developer Andrew Stone explained why ABC’s CTOR will not scale.
CTOR, for those out of the loop, is the sharding proposal by Bitcoin ABC. Bitcoin ABC is one of the major Bitcoin Cash (BCH) software developers. In the leadup to the November BCH hard fork, Bitcoin ABC is in a dispute with nChain about proposed changes to the BCH network.
As one of the world’s largest BCH software developers, Bitcoin ABC’s decisions have huge sway over the community. Bitcoin Unlimited, meanwhile, is another major BCH software developer. They’re kind of “caught in the middle” between Bitcoin ABC and nChain – which is why Andrew Stone’s blog post is a big deal.
Andrew Stone clearly disagrees with the sharding proposal from Bitcoin ABC and claims it will not scale. In fact, he claims CTOR is unnecessary.
Obviously, scaling is a big feature of the BCH network. While the BTC network has struggled to scale, BCH has increased blocksize to 32MB – and might increase blocksize again to 128MB. As demonstrated in the stress test last week, this blocksize increase allows BCH to handle thousands of times more transactions than BTC.
To understand Stone’s argument here, it also helps to understand sharding. Sharding, in the blockchain sense, is a scaling solution for blockchains. Sharding is already used in databases, and developers are attempting to integrate it into blockchains to ensure they can handle increased loads. With sharding, the blockchain is split into “shards”, with different nodes handling different shards instead of all nodes handling the entire blockchain.
It’s far more technical than that, but that’s the basic premise.
Why Won’t CTOR Scale?
Stone suggests there are several problems with Bitcoin ABC’s CTOR sharding proposal that will prevent it from scaling.
“First, the proposed lexicographical transaction ordering is unnecessary to implement it.”
“Second, but more importantly, the sharding (scaling by distributing data to multiple machines) proposal won’t actually work.”
Stone claims the confusion comes from engineers failing to examine the entire network stack. Because of this failure, the Bitcoin ABC CTOR proposal ignores two crucial operations:
- Validation of transaction inputs
- Transaction information requests by end user wallets
CTOR “Is Unnecessary for Scaling”
Stone’s argument boils down to a simple idea: CTOR is unnecessary for scaling. The first problem, as mentioned above, is with the validation of transaction inputs:
“Since TX id’s are pseudorandom, only 1/S parents will be in your local shard and so (S-1)/S parents are in remote shards, where S is number of shards. This means that for S > 2 most parents will require sending a message to a remote shard.”
This, in turn, makes CTOR unnecessary. If the sharding scheme proposed by Bitcoin ABC can handle the validation routing load, then it can handle the top level routing of unsorted transactions
“CTOR is therefore not necessary”, concludes Stone.
CTOR “Exposes the Sharding Algorithm to Everyone”
There’s another problem with CTOR: it exposes the sharding algorithm to everyone.
This means the system can easily be attacked by mining a block containing transaction IDs entirely located within a single shard. The miner could malleate existing transactions or create “vanity” transactions.
“It’s unclear what this would do to a system that requires processing to be distributed, but it won’t be pretty,” writes Stone.
This style of attack was first proposed by Tom Zander.
CTOR Ignores Light Wallet Access To Transactions
There’s another crucial problem with Bitcoin ABC’s CTOR: it ignores light wallets, including SPV wallets, mobile wallets, and etc., that want to access transactions.
The BCH architecture and scalability plan is founded on the idea that end users won’t run full nodes. This is a crucial disagreement between BTC and BCH developers: BTC developers want to “run full nodes on a Raspberry Pi”, for example, while BCH see a future in light wallets.
“The ratio of light wallets to full nodes will be analogous to the ratio of email users to email servers today,” explains Stone.
With that in mind, Stone claims there are some technical problems with Bitcoin ABC’s CTOR that disadvantage light wallets:
“Light wallets need to be notified of transactions that match addresses they are interested in. This is done via the MERKLE_BLOCK message which provides the light wallet a block without all of the transactions it is not interested in.
In Chancellor’s proposal the UTXO set is sharded by transaction id, which has no relationship to addresses. So how to create a MERKLE_BLOCK message?”
In the CTOR system, the light client request must be sent to every shard by the “API Request Processor & Transaction Router” node specified in the CTROR proposal. All shards must then search their portion of the block for matching transaction addresses, then respond.
CTOR is Unnecessary for the BCH Network, According to Bitcoin Unlimited Lead Developer Andrew Stone
In the eyes of Andrew Stone, Bitcoin ABC’s CTOR proposal has a number of flaws that would make it problematic for the BCH network. It would disadvantage light wallets, for example, and is unnecessary for allowing the network to scale. For all of these reasons, Stone believes we need a different sharding proposal for the BCH network.
You can read Stone’s full blog post here: https://email@example.com/why-abcs-ctor-will-not-scale-8a6c6cf4a441. It goes into significantly more technical detail than what we explained above.