It has been 30 days since we released B&C Exchange 4.0, but only 47% of network minting power has upgraded. To effect the protocol change that will allow us to use the reputation system requires a 90% adoption rate. Given that the adoption rate is rising only very slowly, it is likely that it would take months to reach the switch threshold of 90%. It is important that we move forward with adoption of the reputation system more quickly so we can prepare for the full release of B&C Exchange. We need some time learning to manage the reputation system before trading can begin. So we ought to start as soon as possible. Essentially, the problem is that our protocol upgrade can now be expected to take months to be adopted, which is a surprise to most observers. My goal is two fold:
- To effect the 4.0 protocol changes as quickly as possible, without excessive risk to the unity and integrity of the network.
- To make changes that ensure apathetic shareholders do not impair the network again in the future.
With these goals in mind, I am recommending a new, imminent and previously unplanned release of B&C Exchange that contains the following changes:
-
An increment in the protocol version to version 5: This will allow shareholders to vote for this specific version. We donât want to mix voting with the protocol 4 clients because they have a different switch threshold. In that sense it is a different protocol. However, in terms of the what is permitted in transactions and blocks, protocol 4 and 5 will not differ at all.
-
Lowering the switch threshold to 55% from its current value of 90%: 55% is the lowest percentage that we can be reasonably confident will prevent large numbers of consecutive orphan blocks as the switch occurs. While a 55% percent threshold brings higher risks of problems around the time of the switch, the risks are much smaller than the risks of substantial additional delay that the 90% threshold brings.
-
Upgrade alerts via data feed: We need to add the ability to alert the user to upgrade via data feed. This has the advantage of decentralising the decision to upgrade network software while not requiring shareholders to take the initiative to follow what is going on in the forums.
-
Default data feed providers applied upon install: Default data feeds are strong medicine for shareholder apathy. Care must be taken to preserve and foster decentralisation in network decision making and we must ensure that default data feeds donât skew decision making in the network toward any particular outcome. We can do that by asking shareholders to vote for default data feed providers as motions (one for each provider). When the code must be finalised, we tally the blockchain votes for each data provider. If data feed provider A gets 60% of the total votes and data feed provider B gets 40%, then the install process will set provider A as the default 60% of the time and provider B as the default 40% of the time. The install user interface will feature a drop down with Provider A, Provider B, None and Custom. All options will be available in every install. Only the initial selection will be determined by the combination of shareholder vote and lottery just described. Currently we have only two data feed providers, so this doesnât look like great decentralisation. But the architecture will easily accomodate many more data providers should individuals choose to create additional data feeds. This is almost sure to occur if B&C Exchange is even modestly successful.
A concern and an alternative
My primary concern about this plan is the time it will take to get to 55% adoption of protocol 5. There is another route to take than what I have outlined above that is sure to bring faster adoption of reputation voting, but it certainly brings significant additional risks as well. The route is to set the threshold very low, say at 40%, and also add instructions to reject blocks from 3.x clients. The solution has the strange feature that it doesnât require 50% consensus of minters. Normally this wouldnât work. However, if the situation is that the release enjoys nearly unanimous support among shareholders, or more specifically, has almost no opposition, then it will work. If all the devs, myself, prominent shareholders and CCEDK are in complete agreement that protocol 5 is the correct protocol, than it is, even if the majority of minting power is on another protocol. Even if the protocol 5 chain were shorter initially, it would grow to be the longest chain over time as adoption matured. People minting with 3.x would eventually realise they were minting a chain no one cares about and join the real chain. They would lose whatever BKS they minted after the switch. The primary danger of this approach is that the social consensus could splinter, especially late in the process, and create genuine doubt about which chain is the real chain. It would also cut the number of blocks in about half at the switch and would take about a week to recover back to a normal number of blocks. The risks probably arenât worth the saved time, but if it were apparent the risks were well contained due to near universal acceptance of the plan by the community, then it might make sense. Though I am not recommending the approach at this time, I thought it was worthy of mention as an option.
I would like to know what everyone thinks of the proposal and the alternative I outlined. Letâs identify risks and find better alternatives together, if possible.
