mjhjmtu

A distributed ledger is a 'database' without a central administrator or central storage. Instead, each copy of the database replicates and saves an identical copy of the data and updates itself independently. A distributed ledger must:

• Have a mechanism for pushing updates from one node to all nodes


• Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow


• When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers

These mechanisms must be driven algorithmically, not by human subjective thinking.

The inspiration for this question is the book The House of Rothschild about he spread of the Rothschild banking empire in the first half of the 19th century. The five Rothschild brothers each opened a 'branch' of the family bank in London, Paris, Vienna, Naples, and Frankfurt.

However, in real life, political tensions quickly pulled the banks apart into separate entities. But, what if the family tried to keep the bank together. Perhaps with some algorithmic way to distribute and verify transactions, they could have maintained one banking entity up until the digital age?

How could a multi-national bank implement a distributed ledger to track its operations across an area the size of Western Europe?

The technology period for implementing this ledge could be anywhere from 1850-1950. For the sake of this question, ignore the political issues facing a multinational bank and focuses on the technology. Assume this takes place on an alternate-Earth where there are no World Wars or Protocols of the Elders of Zion.

Trust

Maintaining a distributed ledger is not difficult in general. What is indeed difficult, and the problem the modern blockchain technology attempts to solve, is maintaining a distributed ledger when the nodes do not trust each other.

A bank with several distributed offices did not (and still does not) have the problem of lack of trust. If the central and branch offices of a bank do not trust each other they have much bigger problems than maintaining a correct distributed ledger, because no distributed ledger can guarantee the veracity of the actual transactions, only that the transactions are correctly replicated.

If we can assume that the nodes do trust each other then maintaining a distributed ledger reduces to sending copies of the local transactions to a central node, and updating the local copy when the central node sends the consolidated truth valid at a given date in the past. There will always be a delay between a local transaction and its reflection in the consolidated ledger; but this was deemed perfectly acceptable in a world where people did not expect instant gratification.

1. "Have a mechanism for pushing updates from one node to all nodes": in a limited geographical area, such as Western Europe, they used couriers. When the technology advanced and the telegraph made possible timely correspondence over longer distances, they used the telegraph. Then TELEX came along and delays became much shorter.




2. "Have a mechanism for ensuring that the only remote updates it accepts are 'encrypted' or 'secured' somehow": signatures and stamps worked just fine for this purpose, as long as the central and branch offices trust each other.




3. "When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers:" the central office consolidates and sends out periodically the true ledger as of the 1st day of the previous month.

In practice, banks solved the problem of delays by setting limits on the transactions which could be made without confirmation from the central office.

This left only the problem of securing the communications in transit; trusted couriers served fine for a limited area, and various codebooks and ciphers for longer distances. For example, the famous Enigma machine was initially developed and marketed as a means of securing commercial messages sent by telegraph.

P.S. Remember that before the first world war they actually had to move large quantities of physical precious metal between the offices...

Maybe once the telegraph comes into use in the 1800s, before that the signal lag will kill you. The Hawala network of money lenders would seem to qualify but it relies on the honour system rather than having any widespread concrete record of transactions. Distributing records in a secure way across the distances involved is doable, the Catholic Church spanned the globe at even lower travel speeds. So you can certainly send out data to update the various individual ledgers along existing trade routes and eventually get all of them updated. Unfortunately eventually means "over the next couple of weeks" from somewhere central and "in the next month or two" if you're talking between border posts. That wouldn't be an issue if you could have your third requirement:

"When there is a time delay between ledger updates, there must be a mechanism for determining a consensus 'correct' ledger status between ledgers"

But in reality the only ledger status that people (by which I mean customers more than necessarily well trained clerks) will take seriously is the one that is in front of them in black and white. This being the case those few weeks of delay needed to cover the whole geographical range of the bank would invariably occasionally end up with the bank holding the bag on large debts, both intentional and accidental, due to unexpected costs or overdue cargoes or outright fraud.

Not exactly - at least not anything akin to modern electronic distributed systems.

You are expecting each branch of the bank to be holding a full copy of the ledgers. When a transaction occurs, a copy of the record of the transaction is sent to each branch, who tentatively applies it to their copy of the ledger, and as an error correcting measure sends back the new total on the account. If every total matches there were no errors in recording the transaction and every branch is informed of the success and has the new total on that account.

This is all done by hand. Copied out by hand, calculated by hand, encrypted by hand, and the paper records sent by courier to each branch where it is again decrypted by hand, the account calculated by hand, the new total generated by hand, the response encrypted by hand, and sent back by courier to the originating branch to decrypt by hand and verify the numbers. If the totals didn't match somewhere (fairly likely due to human error at any one of the many steps by any of the individuals involved at all of the branches), then they do it all again.

This is a slow process of keeping a full copy of everything at every branch. It could take considerable amounts of time to verify information from a different branch and to physically carry the messages between them. This is why in the recent past it could take weeks for transactions to 'clear' - and that is without having the extensive overhead of attempting full copies at all branches but only processing the transactions where money moves between banks.

The cost of attempting to keep a distributed ledger like this would be astounding.
The only reason it is plausible in the modern age is that electronic communications cuts the time to perform each step to practically nothing. Doing it all by hand would be an astounding amount of labor and would necessitate weeks between transactions (sorry - no more banking on this account as it is still processing the last transaction - try again next month).

A far more likely scenario would be one where each branch operates pseudo-independently. When someone needs to make a transaction through a different location than their primary branch messages are sent between branches to tell the other branch to make the money available. Old systems of giving letters of credit or of simply maintaining separate balances at each branch (with transfers between accounts comparatively fast - just an encrypted note to make $X available with confirmation not needed in a timely manner) is far more plausible. Perhaps a policy akin to extending credit at each of the branches, equal to roughly half the known balance, with a rule in place that one can only withdraw half the balance of the account without prior notice so it has time to notify the other branches that you are emptying the account and to not extend you credit. A copy of the total balance on all accounts can be shipped to each branch on a regular basis (monthly), but a fast courier could be used for anything more pressing.

Always keep in mind the timescales required and the manpower of physically processing everything by hand (pen on paper records and maybe an abacus to help with the math).

It is actually pretty easy.

Every bank writes down their transactions and puts a copy in their filing cabinet. Copies of the day's (or week's) transactions are sent to the other banks by postal mail or messenger and their ledgers are updated to include the data from the other banks.

That is how this was done, and it worked. People used to accommodate for the time delay in data transmission in the same way that modern computer networks have to accomodate for the time delay when data is sent around the planet or over a satellite relay, though on a scale of days or weeks instead of microseconds.

So this question is a little self contradictory because you are looking for an algorithic process in an entirely human managed information system. Not to mention even todays systems arent fully automated.

Todays systems rely on low latency communications to algorithmically resolve most discrepencies. However not all discrepencies are resolved, this is where the system raises all kinds of warning bells that humans must then sort out, law enforcement usually comes in here.

Anyways the first 2 requirements are moot. The first is an information relay system which can be mail or telephones. Such systems were fairly abstracted away from any decision making, with obvious human error factoring in. The second is cryptography which has existed long before computers and whose many methods you can google. This too has imperfections but then so does modern solutions which tie back to the opening paragraph.

Now the last one is the real trick because time delays are inevitable in the old systems. This one topic alone has a whole book on banking law, policy, and procedures. I will do my best to sum the broad problems:

Taking advantage of geographical seperation to withdraw money from the same account at 2 different locations. This was common and part of checking fraud depicted in "catch me if you can". This is largely aided by bad policy decisions driven by the marketability of convienece. If banks simply required all promissory notes to be registed in the localities of their issue and refuse to allocate funds until the ledger certified funds then this wouldnt be an issue. Moreover this would resolve overdrafts. It would also deal a huge blow to international transaction speeds capping them to whatever the ledger refresh is.

You know i was going to try and sum this but its way to big. Now i am just going to say your algorithm is based on your banks customers, policy, and geographic laws. Lots of accounting and auditing.

artifical light, heliography & data compression techniques.

security is relative.

a photoreactive substance, light excluding tunnel, signal towers and 'bar codes' could achieve significant data transmission rates, be bidirectional, relatively secure, operated by laymen and make the operators incredibly wealthy by carrying diplomatic and high value correspondence at many times the rate of sea or horse travel.

not to mention that towers don't sink in storms.

of course, then radio patents would of been bought up by the rothschilds and never see the light of day, but we can't have everything. =)