The past that a
backup brings back.

A backup can restore a working service while reviving an authority that was supposed to have ended. Digital scarcity therefore depends not only on who may act now, but on which past a recovered system is allowed to accept.

Imagine a transferable licence for a single reserved computing slot. Alice transfers it to Ben. The service records the transfer, refuses Alice’s credential and accepts Ben’s. The next morning, an operator restores yesterday’s backup. The recovered database is authentic: nobody has altered its contents. It nevertheless recognises Alice again.

This hypothetical failure is not a race between simultaneous requests. Nor does it require the issuer to create an extra licence. The service has forgotten a completed change of authority. The earlier articles on redemption and outstanding promises ask what a service accepts and how many claims exist. Here the question is whether recovery preserves the history that made those answers true.

Authentic does not mean current

A signature or authentication tag can establish that a stored record has not been altered without authorisation. It does not, by itself, establish that the record is the latest acceptable state. Yesterday’s correct account of control can be today’s incorrect basis for action. Restoring the programme that enforces a rule is not enough if the programme receives obsolete facts about who may use it.

The 2011 Memoir research develops the distinction. Its deterministic module checks a compact request-history commitment held in protected persistent memory. Recovery may repeat the matching request, not choose another continuation from an old snapshot. Merely comparing counters can strand recovery when a crash separates the trusted-counter update from the durable snapshot write.

The paper supplies a prototype and machine-checked safety proofs under its model. Its optimised design requires protected shutdown handling and backup power; denial of service is excluded. This historical construction is not a current deployment recommendation.

Recovery needs a memory outside the thing restored

Return to the licence. Copying yesterday’s database into three new locations does not supply three independent witnesses to today’s ownership. Each copy contains the same missing transfer. A recovery decision needs evidence whose authority does not disappear in the restoration it is supposed to check.

For this example, a protected record of the accepted transfer could constrain which database state resumes service. Alternatively, a recoverable external transaction history could support reconstruction. These are architectural possibilities, not interchangeable implementations. The design must identify which component remembers the accepted transition, who can reset that component and what happens when it is unavailable.

A version number helps only if the comparison has a trustworthy reference. A number stored beside the data can travel backwards with it. A timestamp identifies a claimed time, not necessarily the most recent committed transfer. A hash identifies particular bytes; without a protected expectation about which bytes should be current, it does not select the right history.

The commercial question is therefore more precise than whether the provider keeps backups. Can it recover Ben’s recognised position without reviving Alice’s competing authority? If the necessary evidence cannot be recovered, does the service suspend use, investigate, or accept a defined exposure? Each choice changes what the customer has bought.

Separate prevention from evidence of a split

Different customers can also be shown separate continuations of an old state. Lightweight Collective Memory combines trusted execution with persistent client memory. Its model assumes correct, mutually trusting clients, not arbitrary hostile customers.

It provides fork-linearizability: separated, incompatible histories cannot later be joined without exposing the inconsistency. It also reports operation stability, including whether a majority of clients have observed an operation. A response does not automatically establish a history shared by everyone. An isolated branch can stop gaining stability; delay alone does not establish an attack.

The 2017 key-value-store proof of concept did not use remote attestation, although the protocol requires it. The experiments distinguish asynchronous and synchronous disk writes. Demonstrated components and assumed guarantees must remain separate.

Make release depend on the assurance actually obtained

In the proposed licence service, discovering a split after both sides have used their slots is different from refusing the obsolete authority before use. Detection may support investigation and compensation. It does not put the consumed resource back. The decision about when to release performance must therefore be connected to the particular evidence available, rather than to a generic label such as “verified”.

A business could treat an acknowledgement as provisional and release the slot only after the required recovery or consistency checks succeed. That introduces waiting. Another arrangement might release immediately within a small exposure limit and provide a contractual remedy if reconciliation later reveals a conflict. That introduces risk and a party responsible for bearing it. Neither policy follows automatically from the cryptographic mechanism.

The same distinction matters for limited API allowances, transferable access and reserved machine time. It does not make already delivered information uncopyable. The object being protected is a defined authority to obtain performance from this service, within its stated trust boundary.

A correction should not masquerade as a forgotten event

My published paper, Beyond ‘permissionless’: governance, commitment, and rule change in public blockchains, distinguishes admission to a system from authority over its rules. Its institutional argument concerns commitment after participants have made system-specific investments. It does not supply a rollback-resistant storage protocol.

The application here is a separate inference: a recovery mechanism also needs a declared authority structure. Someone may legitimately correct a mistaken transfer. That is different from quietly restoring a state in which the transfer appears never to have occurred. A correction can preserve the original event, identify the authorised intervention and establish the new position. Silent replacement can erase the evidence needed to understand whose entitlement changed.

For Ben, the relevant terms include who may authorise recovery, which evidence must survive, how conflicts are resolved and whether the old operator can continue accepting requests after a migration. The organisation buying the service should be able to inspect those terms before committing work that depends on it. An emergency procedure is part of the institution, not an exception to having one.

Price the whole recovery promise

Consider a purely illustrative procurement comparison. A continuity control costs £1,200 per month in operation and adds £300 of measured waiting costs. Suppose independent incident analysis estimates that it reduces expected resource waste and disruption by £2,000 per month. On those assumptions, the net monthly benefit is £500. If the avoided loss is only £1,000, the same arrangement has a £500 net cost. These invented figures demonstrate the comparison; they are not estimates from the cited papers.

The loss measure must include the right consequences: competing use, legitimate access wrongly refused, time spent reconstructing positions and the cost of delayed work. Compensation reallocates a loss between parties; it should not also be counted as an additional resource loss in a social-cost calculation. For the provider’s own cash-flow assessment, however, the liability and the price of insurance remain relevant.

The credible alternative may be a conventional access-controlled database with tested recovery and accountable administration. A hardware-assisted design has to earn its extra complexity against that comparator under the same threat assumptions. More cryptography is not itself an economic benefit.

Test the restoration, not just the restart

A useful evaluation would begin with a completed transfer and then deliberately restore an earlier snapshot in an isolated test system. It would attempt use by both the former and current holders, interrupt the recovery at each durable-write boundary, and test migration while the original service remains reachable. Client-memory loss and unavailable witnesses belong in the test plan too.

The observations should distinguish obsolete requests rejected before performance, conflicts detected only afterwards, legitimate requests blocked, and time until an authoritative position is re-established. An independent test record should retain the pre-failure events so that apparent success cannot be manufactured by losing the evidence of a competing use. This is a proposed evaluation, not a report of tests already performed.

Digital scarcity must survive the ordinary work of keeping a service alive. The decisive recovery question is not merely whether the software runs again. It is whether the recovered system still honours what its participants had already given up and acquired.