This week we went through the slide deck that Mike presented to the Open Financial Data Group the previous week, by way of a summary of where we are.
We also focused in on the question “What kind of thing can be posted to a distributed Ledger?” The answer is, any of the kinds of thing that be stored in a database. AS with any solution, performance considerations should be kept in mind. In any case the DL is not a “ledger” in the sense of being postings of monetary amounts.

For some, a record that goes on the ledger is just a sequence of bytes.

So it can be anything.

Anything that can go in a database can go in a DL.

It is simply a database where you can't delete or update records you can only append records. And you can't query.

If the records you append to the ledger are data that takes th form of transferring of currency from one party to another then it si a monetary amount.

So it is not a ledger in the financial sense.

Q: Does it have datatype and if so what?

- there are containers within containers. Consider Smart Contracts. THese are containerized, fully encapsulated code. That code can bejust about aything. Can incude what are loosely called oracles. These are coming out fo the serverless architecture world.

Once you get past the vocabulary, SCs = microservices and Oracles = serverless applications.

Relating this to databases:

If you look at databases that implement the SQL language then the data follows that. If Mondo B then it's JSON, if some other kind of database, it's binary.

So in DL in general, all of these arrangements are possible.

In BitCoin a very specific datatype goes on th ledger. highly structured, per BitCin requirements.

Ethereum has its own, sparate design decisions about the kind of data.

The ones intended as general purpose DLs, have general purpose kinds of data.

So, if we look at one specific architecture, e.g. Ethereum, it will have its own defined answer to these questions.

Q: What do we typically see?

With few exceptions (BitCoin most DLT systems are defined to be general purpose. So most of these will support general purpose data.

So for instance you can post for example a hash code, a whole doc in biary (but likely that performance limits will apply and there may be an uper limit to record size); you can post percentagge amounts, currency amounts and so on.

What is true of DLTs is that whatever you posts lots of copies will be made.

So it's a good idea not to consider posting binaries although in principle you could. Hence the motivation to put a hash to the thing.

Also keep in mind that a DLT is less efficient than databases, so always consider what really needs to be decentralized and what does ot.

Smart contracts - would you post the whole of this to the DL or just the structural stuff?

Think of a SC as like a Stored procedure.

SC would determine whether a new record can be allowed on. Can also calculate, using as input stuff that's already been posted on the ledger.

So the SC does those 2 things.

The SC is executed on every cpy that is in the decetralized system. Only works if it gives the exact same answer at each node.

The SC goes on to the BC since all the nodes need to execute tht code. THere are engineering questions around whether the code is executed within the SC or somehow else.

Legal contracts are not the same as the Smart Contract.

Clarification: given “it only works given the same information”; the SC can be built with event handlers, such that they ca react to verifiable outside events.

The stuff outside of the dotted line as it were, is outsie th Smart Cotract. or instance when you have an agreed source for a stock price. That itself gets posted to the blckchain so once all the nodes have verified that it's ok to post that price, it can be used by ther calculations.

There is some variability in terms of how contracts have been written e.g. the Dow contract. MEchanisms for validation, verification, mechanisms to treat certain events, including recursive

If the contract is written between 2 counterparties and they agree to all the code, then that contract operates almost autonomously at that point.