CIP Draft - DeadMan Switch

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.

Hello @KryptoKing

Not really. You are running under assumption that minimum divisible value of Cardano is immutable. It’s not. At any point of time they can add a decimal to Lovelace, followed by as many zeros they want making sure that there is enough native tokens forever. And if time comes that so much ADA is lost that means that Lovelace is going to be very expensive, so they would need to add decimal point to it. Basically, just like ADA has 1,000,000 Lovelace, protocol can be set to make 1 Lovelace equal to 1x10^n mini-Lovelace making it work in perpetuity.

Also, on a side note. If ADA become so rare and presumably expensive that will give rise to mining of ‘forgotten’ wallets by new tech (brute force or otherwise). Since those old wallets would be using obsolete security, thus bringing ADA back into circulation.

2 Likes

Can we, though?

As far as I understand it, the tools are now built in a way that all values are given as integer Lovelace quantities. Would be a change of source code through basically all tools to introduce a new subdivision, there. A very, very hard fork, it seems.

Yes.

Haskell has fromInteger type converter built in. You can switch integer to double precision floating point if you need to. Not sure how big of a job it would be, but if it’s needed it is possible.

1 Like

Yeah, okay, given the premises of the draft, the “if it’s needed” is probably very far in the future. If the situation is so dire, it will legitimate the effort. (Would never use floating point for currency, though. Rather migrate to a new atomic subunit.)

2 Likes

Yeah, I can see how I may have sounded like a Moonboy/Bitcoiner with that floating point example. :rofl:

2 Likes

That is a very convoluted way of saying that you take the minimum of the first set (if they overlap at all) or won’t find your N (if they do not overlap). Also: Both are very hard to determine. Life expectancy from birth is known quite well, but life expectancy from last executed Cardano transaction? And we have no idea how much ADA are in “dead” accounts, what is the rate of accounts becoming “dead” and when this will really be a problem for the system.

Why reinventing the wheel, when Reserve and Treasury are already there?

I don’t know why you formulate this as if it were a smart contract. Contracts only can transfer assets that have been sent to them. So, you want that all ADA always live in a contract that at least implements your switch and eradicate “normal” addresses altogether? Also: Key pairs are not “assigned” to the users. The users themselves generate them. And nobody can force them to pre-sign anything. Also: Transactions cannot be pre-signed for a lifetime, because the concrete UTxOs are in the data to be signed.

What you want is more of a change of the basic underlying protocol allowing some kind of expropriation of inactive addresses. Sounds very scary.

And per @Neo_Spank’s very valid objection it’s also not necessary.

1 Like

So we cant change the hardcoded value of ADA, but can perpetually increase its fractionalisation? Has anybody set the standard on how or when to do this, or would that be a separate CIP?

What’s the game theory behind this? For a variety of reasons, this seems like a risky endeavour. Is it strictly nesseciy or would the deadman switch work better? Given the two options what would you choose and why?

Yes this CIP was intended to tackle a problem that we might not have for atlest a decade or two - the idea was to get ahead of the problem. I also agree that floating points maybe problematic here, but that depends more on the coding and buffer errors then anything else.

A lot of points to respond to, ill try to be consist.

Yeah, I realised that was a bit long-winded after I uploaded it, but no going back now.

There is no reinventing of the wheel, only some analysis on what the community may find acceptable and some suggestions on final locations. The location would be left to the community to vote on → it not something I should have the power to choose.

I made the SQL transcomplier CIP to extend smart contract this would provide most if not all of the functionality to do this.

based on the feedback thus far, I have come to understand two things:

As suggested in the proposal this problem is still in the future, but that does not mean we should stop working on it → this leads to the second point.

As there is an alternative to the deadman switch the topic should be made to ask which one is better and why and how can we develop or implement the standered for it.

I think you underestimate that. If assets are in my wallet, no smart contract can ever spend them. My private keys are strictly needed for that. Your proposal would change that. And I don’t think it should be changed.

Such power should definitely not be given to Plutus contracts per se.

But even as a protocol change only restricted to this specific use case. No, expropriation by protocol is just wrong. ADA in dead accounts is okay. And, who knows, maybe one of the heirs finds the key one day.

2 Likes

Actually, I had this exact debate with myself before I wrote the proposal.

I settled on the idea of using a custom NFT for presiding that then sits in your wallet. When the contract is executed the NFT will count as your signature (so that NFT has to be made from your wallet, otherwise I can just send you an NFT and wipe your assets) The contract will then have to be initiated by the contour party but has a time lock based on your last transaction timestamp.

If the counter party uses this prematurely the timestamp seal prevents the contract from validating, but the counter party loses the ada they spend on signing the initiation → preventing random spamming.

There are probably many other alternatives to the NFT though that’s why I didn’t put it in the proposal, it seems like there should be a better soloution.

You are still overthrowing a lot of things at once, here.

NFTs serving as signatures are not a thing, up to now.

Signatures that do not sign the complete concrete transaction information, including the concrete UTxOs that are affected, are not a thing, up to now.

Contracts grabbing into normal addresses are not a thing, up to now.

The protocol does not even have the concept of a wallet. You would have to have such an NFT sitting on every of possible dozens of addresses.

If one address hasn’t been used for N, but the others have been, is my wallet than partly robbed by the switch?

And who should enforce that everyone should have such a thing? And if everyone should have it, why then even build it so complicated and not put it into the protocol, directly? (Although, as said, I wouldn’t like it in the protocol, either.)

3 Likes

This isn’t something that would need standards or pre-emptive CIP. The example I used isn’t the only way to resolve such issues, it’s just the one I came up with first. They could just wrap one Lovelace and fractionalize it. They can build a permanent side chain with new native tokens… and so on.

If such drastic action is ever needed it would be much better to have a proposal at that time so they can include the state of Cardano network at that time. Making CIP or standards for something that may (or may not) happen 100 years from now will obviously not account for evolution that network and hardware will have.

For example, todays contracts may not be executable on Cardano network in 100 years. Or the idea of a wallet may change so much that any of this becomes inapplicable. Or the fact that they are already making new Ouroboros that may not be compatible with any ideas here. This is the fifth version of Ouroboros. Also, they may add Minotaur protocol for multi asset consensus instead of just PoS. You want to spend 100 years revising the same CIP for every iteration of Cardano network?

One thing is for sure. There will be no shortage of ADA any time soon. The treasury pot that is feeding emissions for block rewards still has about 12 billion ADA. Emissions are set at 0.03% per year. That means until about year 2040-ish amount of circulating ADA will be (mostly) increasing. After that if ‘Cardanians’ start loosing/ getting locked out of their ADA, lets say at some ridiculously high rate of 100 million ADA per year: it would take about 150 years to get locked out 33% of total supply. Leaving about 30 billion ADA left. Maybe we should just trust ‘Cardanians’ in year 2190 to be able to handle this issue.

Also, if any ‘Cardanians’ from 2190 are reading these posts. Just for the record: We didn’t choose Windows OS. Most of us were never given a choice. True! :wink:

2 Likes

Those are some good points → if the 1st solution (deadman switch) is not desirable due to the effects it would have and the second (divisible Lovelace) does not require any work, Then this should be the end of this tread.

Everybody okay with me closing this one off. Maybe we can talk about the SQL integration to Plutus instead.

1 Like