Preamble
Abstract
Nations are born stoic and die epicurean. With the birth of Voltaire around the corner, the concerns of the death of the chain and the possibility of endless hardforks are consistently on my mind. These concerns have led to the notion of an immortal immutable blockchain. Part of this notion is the ability to construct transactions, in a single universally accepted currency, in perpetuity.
This ability is lost when the principal currency of a chain has a limited supply and exists in addresses that can no longer be accessed (henceforth referred to as dead accounts and dead money respectively). Each blockchain will naturally accrue dead accounts and therefore dead money over time, however, in chains such as Cardano this leads to a problem in the theoretical limit: at some time, T is strictly less than infinity the amount of dead money in dead accounts will be exactly equal to the quantity of the chains principal currency â ADA. At time T the chain is in a state of total death.
This would force one of multiple outcomes: a hardfork of the chain; the adoption of a new principal currency; the movement of dead money out of dead accounts; or the creation of more of the original principal currency. Each of these events is without benefit for the chain and may lead to a failure of the chain. This CIP attempts to make an update to ouroboros that would eliminate this problem.
Motivation
Each of the four possible options in the abstract is necessarily bad for the change and ecosystem. A hardfork would mean the loss of computational resources as some subset of the participants are expected to remain with only one of the two chains, and each chain would be expected to have some members that are in this set.
The adoption of a new principal currency can be done in two unique ways:
Adoption of a brand-new currency.
The Adoption of a preexisting currency as the new principal currency.
If a new currency is adopted the questions of how much is made and its distribution amongst living participants of the ecosystem will be key. Whilst the supply of the new principal asset may be resolved by adopting some arbitrary number (possibly a Gaussian distribution centred at the amount of ADA, with unknown standard deviation) the question of distribution is highly divisive. As each rational actor would attempt to maximize their share of the new asset, the community would be divided on what distribution mechanic to employ and what its hyperparameters should be. This war would centre around the marketers and loud voices, possibly drowning out scientific debate and leading to a suboptimal distribution that causes some of the rational actors to migrate to a different chain or fork the existing chain. This then leads to the loss of computational resources.
The adoption of a preexisting currency as the principal currency of the chain would disproportionally favour the whales of that particular preexisting asset. It would also cause the community to become more hostile to itself as the majority of the actors may only have very little holdings of the asset and perhaps none of the asset. This may lead to the community losing its stoic nature and for the next generation of stoics to move from the Cardano chain, which may, in turn, cause the chain to die, as all actors would eventually follow the stoics to the next generation of innovation â which could no longer happen on Cardano.
The ability to move dead money out of dead accounts would lead to rapidly inflating distrust in the community. This would ultimately lead Cardano to become what it attempts to change â a predictory financial system disproportionately benefiting the ruling class. Intern, I expect a group of developers to do as Charles Hoskinson and others have done and construct an alternative system. If the group are unsuccessful, they will embolden a second group. This process would naturally continue until ultimately successful. This success will cause the decline of the original chain and the value within it.
The creation of more of the original principal assets of the chain would lead to two problems. The first is the lack of trust in the chain as the original promise of Cardano was to limit the total amount of the principal currency and never create more of it. This possibility may not be technically feasible in the current state of the chain but may become feasible in subsequent hardforks. The second issue this gives birth to is the issue of distribution, which has been covered above.
It should be noted that it may be possible to pay transaction fees in native assets, which are not the principal currency of the chain. This would naturally move the chain into a barter system as not all actors would accept the same set of currency. It would also be subject to the whims of the maker of the asset. The node operators may choose to offer discounts on the market price for the use of certain native assets (this would be done for a host of self-serving reasons such as market manipulation) making the system inherently unfair. This could also migrate the chain to more of a barter-based economy.
Specification
The central idea to fixing this problem is the ability to incorporate a Deadman switch into the ouroboros protocol for the use/storage of the principal currency of the Cardano blockchain. This would be a systematic Deadman switch that would activate upon the âdeathâ of an account and only act to transfer the principal currency out of the account to a specified new account.
All addresses on the chain are initiated to be in a state of living and are alive as soon as a person is assigned their public/private key pairs. The address is deemed to have died or entered the state of death (an address can either be alive or dead never both simultaneously) when the difference between the current poxits time and the poxits time of the last outgoing transaction of the account surpasses a threshold parameter N. This is a hyperparameter set in the protocol which takes into account the reasonable life expectancy of an arbitrary member of the human species. It should be constructed in such a manner that the human would have died regardless of any real-life factor such as the degree of access to healthcare, whilst maintaining the usability of the network.
The process by which N is determined should be two-fold. First, the community should agree on a value of N which no human being currently in existence can reasonably be expected to reach in life expectancy. It can be trivially deduced that any value greater than the first accepted value of N must also be valid. This produces an infinite series of possible values of N.
The second stage in the process is to bound the infinitely many possibilities into a bounded set. This is done by asking the question what is the largest value of N that would allow the chain to function optimally? This is the equivalent of asking how much dead money can the chain accommodate at any given time? Finally, the lowest value of the result set is taken as the value of the parameter N.
The next question that must be addressed is the identity of the recipient of the principal currency. As the receipt of the principal currency is the dual of the distribution issue, it possesses the same difficulties of possibly making a fissure in the community. To fix this problem, the principal currency should be migrated to a decentralised agency that acts in the benefit of the entire ecosystem. This would prevent any discomfort from the community concerning the question of distribution and ensure that the resultant funds are employed in a manner maximising the growth of the ecosystem.
This would make the process 100% efficient as its chief objective is the recirculation of dead money sitting in dead accounts. This is accomplished as the principal currency inside the dead accounts is used either on transaction fees or sent to the agency.
The agency would initiate the transactions as the long-run expected value of doing so would be positive for the agency. In order to build in safeguard, preventing the corruption of the agency, the protocol should be improved.
The ouroboros protocol should enable the agency to sign the imitation of the validator scripts and have the smart contract pre-signed for all addresses upon the assignment of their key pairs. The smart contract should be a parameterized smart contract on the blockchain and have its pointer reference hardcoded into the protocol.
The smart contract would also have a time lock inside the validator logic that would ensure the account is deemed dead before the transfer of the principal currency. As contracts are by design immutable, each time the parameter N is changed the logic must be copied into a new contract and the pointer address updated to reflect the changes.
Rational
The pointer reference in the protocol prevents any actor from changing the code that will be run on the dead accounts. This means that the contract would be parametrized, but if N is included in the parameterisation, it would allow for a series of malicious activities. This means that the value of N has to be hardcoded into the contract. This then leads to the conclusion that the updates to the value of N would result in copying the smart contract and suing a change in the value of N. This is a natural result of the immutable nature of smart contracts once they have been added to the chain. This would also require an update to the pointer value in the protocol. I suggest that the smart contract is put on-chain before the change of the pointer reference as this would prevent malicious code from being deployed at the new pointer address.
The Deadman switch must be integrated into the protocol to ensure that all new addresses are subject to it, as voluntary entry into the program would result in nothing more than the extension of T. This would only delay the onset of total death.
The agency would have to initiate the contracts, as the owner of the dead account is assumed to be dead and thus the account is inaccessible for signing transactions. This transaction would be countersigned not by the end-user of the account at the time of execution but the ouroboros protocol at the time of key assignment. The agency should run the transactions periodically and would be obligated to do so as a single missed period should give this ability to a different agency, and the long-run expected value of doing so is positive.
Due to the insufficient ability to query the chain from within Plutus right now, I cannot provide the code to implement this right now. However, I have made a separate CIP for this and will provide the completed scripts once that CIP is accepted.
Backwards Compatibility
Due to the structure of the new changes proposed inside this CIP, backwards compatibility is guaranteed; and therefore, not a concerning factor, however, it is worth noting that depending on how the changes are made to the protocol, the ADA in dead accounts may be lost forever, as the changes would likely be made proactively and not retroactively.
Copyright
This CIP is explicitly licensed to comply with the CIP rules. This means that any code generated as part of this CIP or attached to it is done so under the Apache-2.0 license, whilst the documentation is provided under the CC-BY-4.0 license (this is inclusive of the CIP document itself). It should be noted that I, the author of this document, do intend for any and all changes/ updates to this document to be done in a manner compliment with the above licensing â as I have described it.