There’s no shortage of debate over the proposed canonical transaction ordering rule (CTOR). It has been discussed at length and has caused a ruckus within the Bitcoin BCH community, resulting in a deep divide between for and against supporters.
The truth of the matter is, it has yet to be proven to be a step forward for the blockchain and its proponents—Joannes Vermorel and Amaury Séchet, among others—still have not been able to provide anything substantial. Their support for CTOR comes down to, “It’s better because we think it’s better.” To help try and show the Bitcoin BCH community where CTOR is lacking, nChain has developed an in-depth evaluation, which provides some interesting details.
In simplistic terms, CTOR would force a re-ordering of transactions within a block on the network.
It is designed to provide greater scaling; however, on-chain scaling has already proven to be more than adequate to handle any future growth. CTOR adds an additional layer that alters the very framework and doesn’t produce any results that enhance Bitcoin BCH.
In other words, it ultimately is a change for change’s sake, nothing more.
In the evaluation produced by nChain, the authors point out that, currently, transaction ordering is fluid—a spending transaction must follow the transaction whose output is spent. Any other transaction—for example, one that spends outputs from transactions found in previous blocks—can essentially be listed in any order.
This order is the normal order for transactions and is called the topological transaction ordering rule (TTOR). CTOR would alter the blockchain so that all transactions after the first are sorted lexicographically by their transaction ID. This may sound irrelevant enough on the surface; however, breaking it down, it’s easy to identify the flaws.
Transactions are received in topological order. According to the nChain study, “Simply maintaining a list of valid transactions in the order they are received (or maintaining an ordered list of transaction IDs regardless of underlying storage layout, or assigning an ordinal upon receipt) ensures that they can be presented within a block without needing any compute resources to apply a topological sort.”
Additionally, the current TTOR code has been optimized as the blockchain matures. Adding transactions does not require recalculating the entire Merkle tree. Introducing CTOR could require the entire tree to have to be recalculated.
CTOR forces a change in a currently used consensus rule seen on all fully validating nodes. Implementing it would force all nodes to install the change; however, there has yet to be one example given by CTOR developers that it has been tested and has been shown to be an improvement over TTOR.
Several cryptocurrency experts have already shown that CTOR does not lend anything to crypto. According to the nChain study, “/u/awemany (member, Bitcoin Unlimited), with input from Tom Zander and others, critiques [in pdf] the CTOR proposal, opining that many of the motivations and arguments that lead to the CTOR solution are not valid when scrutinised.”
The authors also point to another study that disproves the viability of CTOR. They say, “Andrew Stone (lead developer, Bitcoin Unlimited) published Why ABC’s CTOR Will Not Scale in which he argues that the sharding proposal following on from CTOR neither requires CTOR nor solves the motivating scalability concern, and that Graphene can work under current consensus rules making CTOR unnecessary for network optimizations.”
The nChain report is a highly informative one and reiterates what has been said from the beginning. At the very least, more research is needed before implementation and CTOR shouldn’t be forced on the network’s entities.
The entire report can be found here.