#smart oracles

Recently I became involved with SCC's committee on "Blockchain and electronic distributed ledger technologies". During one of the discussions, I've learned about a new term that seems to have become very popular in the banking industry - "Distributed Ledger Technology" (DLT). Apparently companies like Deloitte or even the UK government have picked up on this new thing and seem to be abuzz with it. Instantly this reminded me of 2015 when big companies like NASDAQ and Overstock expressed their interest with "the Bitcoin technology", but they didn't want to be associated with "Bitcoin", therefore decided to rename this whole thing as "blockchain technology". Maybe this was just another way for companies to invent a new five dollar word and charge a hefty sum to consult on it? After doing some research, I couldn't find much on what exactly DLTs were - there doesn't seem to be a concrete definition floating around yet. However, a few people pointed me to one example of an actual implementation of a DLT - Corda. Lucky enough, someone coincidentally decided to organize a meetup about Corda around the time, so I had some good opportunity to learn what it's about.

Corda

Corda is a Distributed Ledger Technology implementation by the R3 consortium. It is open source, comes with a Slack, a whitepaper and all that. Corda has been created from the grounds-up for the use by banks and other financial institutions, prioritising their needs first. This dictated a few important design choices:

Private transactions - transactions in the system are only disclosed to the parties involved. They are not globally broadcast for everyone to verify, instead only circulating in very limited circles as small as two peers.

No blockchain - since there is no need to let everyone know about every transaction that took place, there is also no need for a blockchain, be it public or permissioned

Legal smart contracts - much like a Ricardian Contract, the smart contracts executed on the Corda network have explicit legal prose attached to them.

Optional notaries - if two parties don't trust one another, they can bring in optional notaries to verify various aspects of the transaction (no double-spending, uniqueness of transaction, etc.)

Knowing these features, we can try figuring out what existing cryptocurrency project it resembles most. Looking at this chart comparing various projects in the space (provided funnily enough by Tim Swanson a few years back before he joined R3):

Tim Swanson's "Current Cryptoprotocol Infrastructure" from his "Great Chain of Numbers"

It looks like Corda can fall in only one spot, which is the "Ledgerless Crypto Suite", alongside Open-Transactions. Indeed, the resemblance is quite strong. The following explanation is based on the "Introduction to Corda" presentation and other materials I managed to come by. Corda's base building block is a cryptographic transaction. It can be a simple payment, or a more complex smart contract. The transactions specify which inputs they are spending and what outputs they are generating (this works just like Bitcoin and is different from an "account-balance" approach of say, Ripple). Each transaction has a hash of a legal prose attached to it which governs how the transaction should operate. The transaction is then signed by all of the participating parties that agree to execute it - it could only be one entity when it is a simple "send money" transaction, or span multiple parties if it is a more complex swap or financial agreement. The transaction can also be notarised or verified by third parties as needed. This could be as simple as a server doing a blind signature to verify the transaction is unique, or perhaps the whole transaction could be disclosed to some auditors as needed. After a transaction is signed, that's about it - every party that knows about the transaction records it in their ledgers and the financial contract is thus binding. There might be some follow-up on the smart contract as it matures or other trigger points execute it, but with no blockchain, block generation or the like, there isn't much else to it. As it stands, Corda seems to fit in as a common middleware for banks and financial institutions to standardise their interactions with one another, especially in the realm of financial contracts. This puts the project in a similar space to Open Transactions or Interledger, not too far from Ripple or Ethereum.

Corda criticism

Due to its focus on catering to the financial institutions, Corda might be seen as "more of the same", rather than trying to revolutionise the field like Bitcoin. Some people might dismiss it out of principle for not fighting to make the banks more transparent. A system built on private transactions will be easier to manipulate than a proper blockchain. Unless all of the transactions need to be accounted for by some independent auditor, you loose the option to have "negative proofs". Since the amount of parties involved is so small, they can easily conspire to rewrite or delete the past transactions to suit their present needs. This could be mitigated by using a proof of existence and anchoring the various hashes of transactions into something like Factom. However, if properly maintained, the system can enforce accountability. While the transactions may not be a part of a blockchain, they do form a transaction chain - every transaction spending the previous output. Having any single transaction signed by the various parties could be used against them - they might be compelled to provide the full, unbroken chain of transactions leading up to that transaction. While this might not uncover all of the transaction branches, there is at least some cryptographic trace of what happened. Linking the legal prose to the smart contract is also asking for trouble. Even now people can have legal disagreements as to which interpretation should take precedent when you have a contract written in two human languages. Woe to anyone who wishes to mix legal prose with a smart contract. This would either require a new profession of some lawyer-programmer, some sort of legalese language interpreter / compiler, or the smart contract will be just a farce that could be overturned so easily it might not even need to exist. Corda's presentation seems to indicate the legal prose takes precedent over the code. This might mean that there would need to either be some backdoor for third parties to overwrite or amend the contract, or the parties involved would have to work around the code to achieve settlement in the end. All in all, this can lead to a lot of mess in the code down the line. Some might prefer the approach of "code is law", but then we have the story of the DAO as a cautionary tale. Moreover, the contracts dealing with international law and regulations would be even more complicated. This could lead to fewer transactions taking place between various jurisdictions to avoid the legal hassle. Beyond that, Corda seems to rely on a few known key actors common to the Crypto 2.0 space. Lack of native currency means the system will need gateways to issue assets. Some design documents mention Smart Oracles, etc.

Distributed Ledger Technologies

Based on the example of Corda and Open Transactions, we can try drawing some conclusions of what the Distributed Ledger Technologies might be as a general term.

The technology seems to be focused more on transactions and less on grouping them into blocks.

With the absence of blocks, we necessarily have to do away with any form of distributed, native currency - there is no way for that currency to be objectively generated. The system instead uses IOUs for currencies and assets.

The system relies on a number of key nodes / entities to operate - auditors, validators, legal authorities, banks, etc. This means the system would be at best "decentralised"

Cryptography is still used to authorise various transactions and move the money around.

Conclusions

EDIT: After speaking to Ohad Asor, the creator of Tau, about the below piece, it's apparently "blatant obvious nonsense about things [I] don't understand" and "the contradictions are all around. just like eth". The Tau presale was apparently also meant for "only well informed buyers", "i have morals. im not ethereum!". So yeah, the Tau project is not for mere mortals like myself, and the spam and promotional videos are meant for intellectual elites that will then buy the exclusive tokens. The project looks much better suited for some high-end computer science academia really, but no, token presale is the way to go. Remember - the Tau is not for you, stupid. END OF EDIT Living in the Bitcoin land, you never know what you might come across next. It could be as benign as someone issuing a currency backed by pre-1965 silver US dimes, as geeky as someone creating a blockchain to mine for prime numbers, or it could be as convoluted as BitShares with the many iterations it had over the years (as someone put it - "BitSharesX - An Alt Coin That Is Impossible To Understand"). Over the last few months, I've been seeing a lot of spam about Tau-Chain, along with its many extravagant claims, and figured it might be interesting to try to understand it. Disclaimer - the project appears to be delving really deep into the theoretical computer science that almost borders on philosophy. While I do have a masters degree in computer science, I can't claim I fully understand some of the topics Tau-Chain touches on or their implications. I will instead focus on more practical aspect of Tau and how it presents itself as a piece of software with practical use.

What is Tau-Chain?

So, what is Tau-Chain? Well, it's quite simple, just look at this graph from the founder of Tau:

A simple explanation of Tau-Chain...

Okay, it's not simple at all. This graph represents what sort of confusing things we're dealing with here... From what I gathered looking at the project's website, its whitepaper, roadmap, some articles on it, listening to a LTB interview, viewing some other resources and talking briefly to the founder of Tau-Chain, I think we are dealing with two components here - Tau and Tau-Chain. Unfortunately, it seems the people involved in the project like to use those terms interchangeably and confuse everyone further. Tau appears to be a new programming language, apparently similar to Idris. Unlike most traditional languages most programmers deal with on a daily basis, it is not turing-complete. Instead, it is a decidable programming language. What this means is that it avoids the halting problem, while still being able to do anything a finite turing machine can do. Since in practice we don't have infinite turing machines, from what I understand it should be able to do anything a turing-complete language could do. Apparently, this approach might be more secure. On top of that, Tau "has built-in P2P and blockchain". Tau-Chain on the other hand, appears to be a sidechain-enabled blockchain that can run the Tau language. It seems to be similar to Ethereum with its contracts - both have a growing library of code embedded in it that anyone can call upon to build their code on. As I understand however, Ethereum's code can be more risky to use as you might not always be able to predict what the contract might do without its source code at hand, while Tau the language is more predictable in its execution? The project also appears to have another component to it - the Agoras. As far as I can tell, they seem to be smart oracles that can execute various contracts and other Tau code. They appear to be able to interact with the Tau-Chain, as well as with one another directly. All in all, they remind me a lot of Codius, especially if you consider that that project aimed to be able to prove what code is being executed and so on. Not a bad feature, but there doesn't appear to be much new to talk about there.

What Tau-Chain promises

While initially researching Tau-Chain, one will stumble upon their promotional video:

Tau-Chain, solving all of your software development problems apparently...

Which lists a few outlandish claims about what Tau / Tau-Chain can deliver:

Software that always does what it is supposed to

No more bugs

Automatic requirement validation by the Tau client

It is impossible to write code that doesn't work

Thanks to Tau, the client doesn't need to trust the coder and vice versa

The payment for developing code is automatically paid when the code is verified by the Tau network

The Tau blockchain stores social norms, scientific theories, "whatever is based on facts and rules" (one example flashing in the video is "Once you start to eat you should never leave spoon, fork or knife on the table. Their place is on the plate.")

Tau-Chain code is reusable

Tau is a database of provably working code snippets

You can use the Tau-Chain to build search engines, social networks, market places

You can develop provable smart contracts on the Tau-Chain

As a software developer, I would take all of that with a huge grain of salt. Then again, it might be my turing-complete attitude talking and things might be different in the decidable language space. If this video was talking about traditional software languages, I would put my money on the video being about test-driven development - an approach to software development that starts with test cases (what the code should and should not do), and then developing the code to fulfil those tests. In theory this could mean that the software has no more bugs, it does what it is supposed to and can be verified automatically when new code is checked in. So while it would fulfil most of the listed requirements, in practice I would not expect it to be *the* solution to all problems - writing good test cases can be as hard and time consuming as writing good code, and I doubt 99% of the clients purchasing software would be able to use that. If the test cases aren't sufficiently complex, we might run into the problem of software being built just to tick the checkboxes and not much else. After all, any program operating on a sufficiently small domain could be replaced by a lookup table...

I am also very sceptical of how the software will decide what are the stored facts and how those will be handled and proven. Even more so when we're talking about "facts" about the real world and social norms. How do you prove you should not put used forks on the table, from a software perspective? How do you handle a problem having multiple contradictory answers (an infinite sum of (1-1+1-1...) can be proven to equal 0, 1, 0.5, -0.5, etc...)?

Some other claims I stumbled upon from other sources (1, 2, 3):

Tau client's behaviour is dictated on-chain, with the chain being able to hard-fork itself

Tau (-Chain?) has no rules at all, its users will set its behaviour

Tau does not need a coin, but it has a token presale anyway

"Tau network will be able to download virtually the whole internet, practically giving everyone the same information Google has, and more: data can be queried and processed more meaningfully and collaboratively, so you could perform queries as you like."

While there are more claims, lets just limit ourselves to those few (a lot more can be found in the LTB interview).

The Tau / Tau-Chain's feature of embedding how the network operates in the blocks themselves is rather unique feature as far as blockchains go, but at the same time it can be one of the more dangerous thing out there. It certainly offers the network more apparent freedom from Bitcoin-like hardfork stalemate, although in reality Bitcoin's hardfork problems are never about the code being hard to change, but about the people you need to convince. It might also impair some thin clients if they are applicable to the chain (how can you just run the chain from a given length if you don't know what the rules are from all of the previous blocks?). The definition of who the "users" in the system are (one-vote-per-person / machine / CPU?), as well as what the rules for hard-forks will be will probably shape the network very drastically early on. I wonder whether anyone will try to change the code of how the blocks are executed to "stop execution, return 0"...

The token presale doesn't appear to be anything new in the crypto world - it's the paradox of presales all over again. Tau the language and network doesn't need a new coin, it would probably operate better without it, but the developers need money to develop the language / network, so they sell tokens to speculators. Looks to me like another Bob Surplus-esque coin looking for a problem.

As for the last claim, and a few similar marketing blurbs, I think they deserve a section all of their own...

False equivalence, false dichotomy, eating your own dog food

The quote about basically being able to replace Google appears to be a false equivalence fallacy. There are many problems with trying to say you can basically be like Google:

I very much doubt the network could handle about 10 exabytes of data

Being able to efficiently categorize all of that data requires very smart algorithms and a lot of data. You can't even begin figuring some of the things out without having efficient access to enormous data sets. For example, how would you figure out a search for "high contrast pictures of fruit floating threateningly in the night" (thanks Reddit)?

Google is as much about the data (what the websites contain), as much as it is about the metadata (what the people are searching for and what they are clicking). Having just one part of that might not give you the full picture

Without having most of the data at hand, it is impossible to know if you returned most of the searched data. While you might be able to make queries based on the data you do know, you can never know how much you don't know

It is also impossible to prove that real-world data is correct. Since Tau-Chain is focused on storing "whatever is based on facts and rules", how would you be able to know, say, what is the weather outside right now? Sure, you can have a lot of data points, but you can't prove they are true or made up

All in all, statements like that are just red flags if someone also asks you for money. At best, they are marketing superlatives. So while sure, if we're talking about Tau the language, someone might use it to implement a Google-like service with it and so on, but the same could be said about computers based on cogs and wheels (after all, any turing machine is equivalent to another). All in all - false equivalence - your software is not even comparable to Google.

Now, lets finish this discussion with a subtle false dichotomy. I stumbled upon this marketing blurb about Tau from some of the spam I see pasted in a few chats I visit:

It compares how Tau-Chain is different from Ethereum, and links to a blog post by Peter Vessenes criticising how buggy some of the Ethereum smart contracts can be. He makes a lot of valid points - since you can't upgrade and fix the contract code post-launch, you either need a good failsafe, or write perfect code not to lose people's money. However, what I take slight annoyance with, is how this sort of marketing might misrepresent the situation - "Tau is different from Ethereum, here are a few reasons why. Here is someone criticising Ethereum (while not talking about Tau)", implying that since Tau was not criticised and it is presented as Ethereum's competitor, it somehow doesn't have those flaws. No Tau, criticism of your competitor does not mean you don't / won't have those problems yourself.

Lastly, I find it really amusing that Tau apparently doesn't like the taste of its own dog food - for all of its criticism of turing-complete languages, saying how Tau is a much better language and all of that, in the end they develop their code in C++. I did bring this point up to Tau's creator and he made valid points as to why that is - they want to develop the software in an efficient language to make it operate efficiently and in the future they might implement Tau-Chain in Tau. Understandably, software development takes a lot of resources and time, and you want to release early, release often, but this somehow doesn't fill me with confidence that Tau will be usable for any commercial-grade software any time soon...

Conclusions

While Tau appears to be an interesting development of a new programming language and its creator certainly sounds very knowledgeable in his field, Tau-Chain looks like a project looking for a problem. Bootstrapping a new token to run a blockchain to use a new programming language for smart contracts that don't halt seems like a very complicated way of reinventing everything just because you want to change a few things. I am highly sceptical of how the network will handle everything it promises, especially when it comes to dealing with things in the real world. It could be as mundane as a different flavour of Ethereum with a non-turing complete language, some smart oracles, etc., or something potentially new - only time will tell. Until Tau-Chain is released, I remain unconvinced.

In the recent months, many banks and other financial institutions started looking into the blockchain technology as a potential improvement on their current architecture. Below is a sample feature set of the cryptocurrency technologies that can be used to reimplement and possibly improve upon the banking system as it is today.

Transactions

In all cryptocurrency systems, transactions are the most basic building block of the value transfer network. They have a few important features, including:

Atomic nature - a transaction can either succeed fully, or fail completely. There is no middle-ground that wasn’t specified beforehand (for example, Ripple’s partial payment flag). It is even possible to have complex transactions that hop across multiple currencies that are still atomic. 

Self-contained - a transaction in most cases provides all the information that is needed to verify whether it is valid or not. It specifies exactly which money it is spending, quite often how much money is left, as well as contains a digital signature authorizing the move of funds. 

Undisputable ordering - once transactions are included in a block, their ordering is undisputable. This allows everyone to be able to verify exactly what state the system was before and after the transaction was applied. There is no data discrepancy between the participating institutions as to what happened without the need to resort to a centralized authority. 

Cryptographic authorization - in the crypto world, there is never a doubt whether someone is authorized to spend the money. Either they own the private keys and can authorize the payments, or they don’t. Moreover, each signature is only valid for a given transaction, so a few authorization problems are mitigated (replay attack, man-in-the-middle, etc.). 

Easy multi-party escrow - also known as multisig. This allows money to be held by multiple parties in such a way so as to only be spendable when a minimum threshold of parties agrees to spend them. 

Currencies

In the cryptocurrency space, there are essentially three types of currencies. The most prevalent is a native crypto currency or a digital token. Those are currencies issued by decentralized autonomous organizations, either in the form of complete crypto-networks (like Bitcoin, Litecoin, etc.), or autonomous smart contracts. Those tokens are usually perfectly, mathematically scarce, have a predictable minting schedule and a clear set of rules on how to transact in them. However, due to their decentralized nature, they don’t represent real-world assets very well. The second kind are derivative currencies (such as BitUSD), which are still created and maintained in a decentralized fashion (without a central or collective counterparty), but through known financial contracts (futures, contracts for difference) can track the value of real-world assets and currencies. Their counterparty risk takes the form of the financial derivative market. The third kind are IOUs, digital currencies issued by centralized or collective parties usually backed by real-world assets and currencies (such as SnapSwap.USD, BitStamp.BTC, etc). While they are subject to counterparty risk, they have an advantage over the derivative currencies by most often being easily redeemable in kind from the issuer. Different cryptographic systems have different requirements when it comes to those currencies. A decentralized network will have to have at least the native digital token to avoid spam attacks at the very least. Having that currency, they can also incorporate the remaining two as needed (see BitShares and Ripple for an example). Permissioned blockchains don’t need a native digital token, as the network participants are known entities and can be made liable in case they intentionally disrupt the network. As such, it makes a lot more sense for those networks to mainly feature digital IOUs.

IOU issuers

IOUs in a cryptocurrency network can be a powerful tool. They are useful for not only tracking the value of real-world assets, but also for tracking the trust associated with the currency issuer. If 1 USD from Bank A trades for 1.02 USD from Bank B, we can infer that A is more trusted than B. When talking about IOUs, there are generally two models that can arise in a system - a web-of-trust or a gateway model (with the real-world examples usually being a mix of the two). In the first model all parties trust one or more parties in the web and money flow is rippling through the system between parties (this is a basis for old version of Ripple). In the gateway model, we have a few central authorities everyone relies on to securely issue and redeem the IOUs everyone else uses (this is a basis for the new version of Ripple). The latter approach might be more useful when there are different classes of peers on the network (governments vs big banks vs small banks vs credit unions, etc.), but the former is useful compliment for smaller-value settlement between the same classes of peers. IOUs inherently track debt between parties (if you have 1USD IOU from me, it means I owe you 1 USD). In systems like Ripple it is also paired with another variable - trust. Trust limits the amount of IOUs / debt one is willing to take from another individual. This can be especially useful if say, two banks established a mutual trust between one another to simplify payments or reduce their costs. They might agree for example to extend $1M line of credit between one another and use that channel for settlement for any payments made between their accounts. If the credit limit is ever reached, they can still settle with potentially more expensive IOUs from a gateway (say, a government), or settle the debt in some other way and resume operating with the cheaper IOUs.

Decentralized exchange

Having a number of currencies issued on a decentralized network opens up a lot of possibilities. Most useful one perhaps being a decentralized exchange allowing trading between any currency pair. With an open market accessible to all peers, one could expect to drive the spread for performing FX trades to spot, even for small value transactions. Having that, one could expect to start seeing the Singularity of Money going into effect, where the currency you own would not matter as much as the value of that currency. Multi-currency hops would allow one to route money through the most efficient market in the web of value allowing for easy bootstrapping of new remittance platforms and applications.

KYC

An important aspect to consider while designing a crypto network is how it can comply with KYC regulations. While decentralized networks such as Bitcoin are focused on fostering strong pseudonimity, permissioned blockchain users in most cases would be interested in dealing only with known parties. This can be achieved by either having all entities in the system known and explicitly recognized, or having a more open system but with each peer being responsible for doing their own KYC. The first is a model that seems the most popular with private permissioned blockchains such as MultiChain, where the creators of the system explicitly have to grant read and write permissions to every network participant (thus giving them an opportunity and potentially a responsibility to perform the KYC on everyone). The latter model is more popular on public blockchains that allow permissioned access, such as Ripple. There, every gateway can explicitly either blacklist addresses to prevent them from using the IOUs they created, or create a whitelist of only the addresses that can send and receive the IOUs.

Block encapsulation

One of the more important differences between a database-based approach and a blockchain-based approach for processing transaction is the idea of encapsulating transactions in blocks. A blockchain, whether it is permissioned or public, has a few key advantages:

Order of transactions is strict - there is no doubt which transaction is to be applied first and at what time. This addresses the problem of race conditions and can be used to address the problem of frontrunning in a system without a central authority. 

History is immutable - since all blocks in a blockchain refer to a previous block’s hash, it is impossible to alter any record of what blocks and transactions took place in the past without rewriting it entirely. Paired with real-time anchoring of block hashes into a public immutable ledger such as Bitcoin ensures that any block forks would be evident and would have to be accounted for. 

Provable auditability - knowing only the latest block hash (which is a small digest in comparison to the actual size of the blockchain), one can not only audit the entire history of the blockchain, but the auditee can probably for the first time in history provide a positive proof that they disclosed all the data for the audit. Any records that are missing or have been altered will come up in a proper audit. 

Everyone can be sure they have all the data - if one is at the blockchain head, they know they have or can fetch all historical data. There is no doubt whether some chunk of data is missing or not. 

That being said, blockchains are not a silver bullet. They come with their own weaknesses:

Blocks are slower than individual transactions - while a transaction can be committed to a database within a few read/write cycles, a block takes awhile to be created and propagated. The fastest blockchains out there achieve about a block per 1-5 seconds. While each block can contain many transactions to possibly reach the required throughput, those transactions can only come in discrete quantas, not a constant stream (as they say, “Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.”). 

Performance-wise, a blockchain will probably have a higher transaction overhead than an optimized database. There are a few possible reasons for this - the fact that in the end transactions from a block will have to be committed to a database anyway, the overhead of synchronizing the network and resolving forks, or the relative age of Bitcoin technology (7 years) vs say, SQL (about 40 years). 

Currently, there are many blockchain-based cryptocurrency solutions out there, but there are also cryptocurrency networks out there that don’t rely on blockchains, such as Open Transactions. The latter relies on having a few notaries verifying transactions in real time and providing cryptographic receipts for those transactions. It is an interesting approach that allows anyone to prove their balance by merely presenting the last receipt without having to hold onto any prior history.

Tiered blockchains and bandwidth reduction

As it became evident in the Bitcoin world, blockchains can become vulnerable with increased network activity. As such, a modern blockchain solution for high-transaction-volume environment should be prepared to address the bandwidth issue before it might become a problem. There are a few possible approaches one can take - settle transactions off-blockchain (like the Lightning Network), create a separate permissioned blockchain (like Liquid), or create sidechains (like Credits or what Blocksteam initially wanted to create). Out of those three, sidechains appear to be the more ideal solution - allowing one to move value on and off the main blockchain, transact on that blockchain with the transactions being cryptographically linkable to the main chain (through anchors), and not rely on more centralized third parties. As such, it might be feasible to construct a tiered blockchain that would be able to offload a good amount of transaction volume off the main chain while still allowing settlement between tiers. At the top of the chain we would perhaps have a public blockchain where the highest-tier peers would issue their IOUs - governments, biggest banks, etc. Below that, we would have sidechains maintained by various banks and other financial institutions. This would allow them to perform more internal transaction without cluttering up the main chain. If needed, more sub-sidechains could also be introduced to further increase transaction throughput. One could also perform sidechain-to-sidechain transactions through a dedicated protocol (such as what Interledger is proposing). It would be useful for the top of the chain to be a public blockchain as it would allow more institutions and possibly even governments to join and integrate directly with it. Sample network graph of a tiered blockchain:

Proof of Solvency

One very interesting concept that emerged from the Bitcoin world is so called “proof of solvency”. It allows institutions such as exchanges or gateways create a positive proof that they own a certain amount of currency and that their liabilities are no greater than their currency reserves. Depending on the system in question, the proofs can be either be complete (proving beyond a shadow of a doubt both the assets and the liabilities) or disprovable (one can present undeniable evidence that the institution is lying). The first scenario is mainly applicable for completely open ledgers - in most cases, only cryptocurrencies and Crypto 2.0s. For example, BTC2Ripple can prove both that they own a certain amount of bitcoins AND the level of their outstanding liabilities on the Ripple network. Since both networks are open, the transaction can be verified to be true or false at any given time. The second scenario applies whenever we’re dealing with either closed networks, or networks that don’t provide cryptographically signed proofs. This includes exchange’s private databases and bank statements (barring something like TLSNotary). In this case, we either have to rely on some signed documents or PDFs supplied by the banks about the account balances, or generate a merkle tree of all account balances on an exchange. An exchange cannot prove that the information is complete, but anyone can prove the data is invalid if they find their account balance either omitted or altered. As such, Proof of Solvency can be an important tool for financial audits, allowing them to be performed at any time without disrupting the normal business operations. Some institutions might even opt for continuous proof - updating the required information in real time to bolster confidence in their business. Proof of Solvency might be fairly straightforward in the above proposed tiered blockchain. Any balance in a sidechain should equal to the amount of assets held at the higher-level chain. The top-level chain would have clear balances of who has how many assets and liabilities.

Voting Pools and auditing competitors

Voting Pools are an interesting idea for keeping everyone honest. In this approach, we have multiple parties vouching for one another’s solvability and being liable for bailouts in case one of the parties goes under. For example, we could have multiple exchanges forming a voting pool and keeping their bitcoins in multisig addresses such that even if one of them turned rogue, they couldn’t defraud their customers nor turn insolvent. This is made possible with continuous proof of solvency, as explained above. Voting Pools could also be useful for having multiple institutions creating IOUs backed by all of them. These could include:

The Euro currency, issued by the joint agreement between multiple EU countries 

International Special Drawing Rights issued by the International Monetary Fund 

Fiat IOUs backed by multiple banks 

While Voting Pools are the most efficient in a network based on native cryptocurrencies such as Bitcoin, the concept might also be used in permissioned blockchains.

Smart contracts

The final catch-all solution for everything one couldn’t predict while designing the system. Smart contracts are flexible programs that live on the blockchain and can execute commands based on the state of the network. Coupled with smart oracles, the contracts allow for creation of such projects like a decentralized prediction market.

Conclusions

I was recently sent a link to an article discussing the development of "the money protocol". The idea has been around for awhile - we have standardized protocols for communicating between computers in form of TCP/IP and others, so it would similarly make sense to develop protocols for moving money around on the Internet just like now we move information around it. However, we will likely have more one new protocol created from Bitcoin and related technologies...

Accounting for all payments

In an ideal world, we would have everyone using the same currency on the same network. However, there are many reasons why this probably won't happen. Instead of hoping everyone will start using Bitcoin in the near future, we should assume that we will be dealing with many different currencies, both cryptographic, fiat and otherwise. We will need a protocol that can handle:

Native cryptographic currencies like Bitcoin

IOUs, assets and debt, like what we see on Ripple

Financial derivatives, like BitUSD on BitShares

Private currencies on permissioned blockchains

Legacy banking systems

Credit, debit and gift cards

Other currencies created / tracked by private companies (perhaps shares, digital commodities, etc.)

Moreover, the protocol would also need to cover:

Sending payments across networks (bank->Bitcoin, altcoin to sidechain, etc.)

Finding an optimal payment path between the start and end of the payment

Atomically trading between multiple currencies at the same time

Locking in / confirming trades and money transfers

Providing digital receipts for the payment

All of those would need to be included in the same "money protocol". Once we figure out how to convey the information of who is sending the money, who is the receiver, which type of money is being spent and received (more on how this could look), we can finally start to connect different networks together. Whether it would be through W3C's Web Payments Community Group, something like Interledger or some other forms of bridges, we could finally be able to easily send money around (hopefully).

What's left?

When dealing with crypto as they say, money is the least interesting application. We also have smart contracts, proof of existence, etc. A lot of those applications of crypto will probably also warrant their own protocol - they don't exactly fall under "money protocol". I do believe the following will eventually become their own protocol on par with TCP/IP:

Proof of existence. As we all know, the Bitcoin blockchain is the most secure, inalterable record of history currently available due to the amount of computing effort put into it. Anything embedded in the blockchain can be forever referenced as the latest date some file could've been created. This functionality, perhaps expanded with protocols like Factom, can be a useful protocol for creating timestamped receipts and other applications.

Smart contracts / smart oracles / proof of execution. With Ethereum being released, we can expect to see more use of smart contracts for business applications. Smart oracles, such as the ones proposed by Codius. would compliment them to interface between the crypto and the real world. All in all, we could bundle those up into "proof of execution" - a protocol dictating what code needs to be run, at what time and by how many independent parties (some of them in form of computers, some in form of autonomous contracts), as well as what was the result of the execution. This could enable, for example, to build autonomous financial derivatives or contracts ("code is law").

Conclusions

Back in 2013 I attended the Ripple Developer Conference at Money2020. One of the interesting presentations that stood out to me was a discussion on smart contracts that would be able to make autonomous decisions and even pay for developers to improve their code. Since that conference there has been a lot of more development in the space of smart contracts, especially if you look at Ethereum. However, one of the biggest obstacles limiting what a smart contract can do has always been the information it can use. To put it simply, smart contacts running on blockchains could only access data from within that blockchain, not from the Internet as a whole. This is to make sure those contracts are executed in a consistent manner at every machine - you couldn't for example have a contract checking the current Foreign Exchange rates online, since two different machines asking for the same information could get different data. Moreover, there is a question of security and preventing DDOS attacks - a script asking for a web page 1000 times executed at 1000 locations would result in a million page requests. To address these issues, the concept of "smart oracles" came about. A smart oracle is a piece of software running on a machine that has access to both the blockchain data, as well as the real world data, and can interact freely between the two. You might have, for example, SatoshiDice checking the blockchain for transaction bets and evaluating them, or some bot that checks the current Bitcoin exchange rate and embeds it into the Bitcoin blockchain. One of the projects offering a distributed platform for running smart oracles that inspired today's blog post is Codius. It's a project that grew out of the initial idea for smart contracts on the Ripple platform into what it is today. I would like to present to you some ideas of what could be built using that platform. But first, some assumptions.

Smart oracle assumptions

A useful smart oracle platform needs to offer the following functions:

Make the code to be run verifiable and open - anyone interacting with the code needs to be able to make sure the proper code is running and it hasn't been tampered with

Interact with both the Internet and the blockchains - this is needed to leverage the power of smart oracles over smart contracts

The oracle needs to be able to keep some private data - whether it's private keys for signing transactions or other proprietary data, the oracles are more useful when they can store some data privately. Of course, the private data can be made public through proper function handlers

In many cases, it is beneficial for multiple smart oracles to be run by different parties to ensure there is no collusion. Because of this, the platform running the oracles needs to be open source and not have proprietary code

Given those features, we can build some interesting projects...

Factom in a script

Since Factom is essentially just embedding information to be stored in the blockchain, it would be easy to setup some smart oracles where you can pay some money and have certain pieces of information embedded into the blockchain - whether it's hashes of proof of existence, or actual data like the current exchange rates, it doesn't matter much. Having more than one oracle communicating on what data to embed can also be useful to make sure no single party is manipulating the data.

Coin to Crypto 2.0 gateways

In the Crypto 2.0 space, there is a need for efficient, cheap and secure gateways between the various coins and the 2.0 system. Most of those gateways are currently run by centralized parties, but with smart oracles you could easily reinvent that model and run it on a few smart oracles.

Distributed gambling

Smart oracles could serve as an interesting platform for betting and gambling. Users would be able to register and gamble with the oracles against one another, real-world events, or against the house, which can also be run by the oracles in a fashion similar to JustDice. 

Distributed messaging

Since the oracles would be able to store private data, anyone would be able to send messages to be stored on multiple oracles that can later be retrieved by the intended recipient. This communication could be end-to-end encrypted, and since it wouldn't reside on a single server, it could be more robust than a lot of networks.

Arbitraging bots

A lot of exchanges (centralized or distributed) benefit from initial market liquidity bootstrapping that can be achieved through the use of bots. Those bots are usually tasked on copying the market from an existing exchange onto the new one and locking in any trades that might take place. Moreover, there is even more benefit if there is competition in this space - having multiple parties competing with one another to provide the best rates stimulate activity, as well as make the market more competitive. If an exchange that needed liquidity would provide smart oracle code for anyone to easily deploy and run on Codius with tweakable parameters, they could quickly see a lot of amateur market makers provide them with a competitive market on their platform. Similarly, the same could be done on a 2.0 platform with a decentralized exchange like Ripple.

In this example, the smart oracles are mainly used as cheap, 24/7 hosting platforms.

Timed releases of secret information

Through the use of encryption and Shamir's Secret Sharing, smart oracles could be programmed to release the decryption keys for various files or documents at a given point in the future. Even if some of them went down or did not release the keys, the secrets could still be revealed if the minimum threshold was reached. This could be used for example by provably fair gambling platforms releasing their secret seeds at a predictable time in the future.

Economic contracts

There is a lot of need for various economic contracts out there, and a lot of them rely on some external data, such as the current exchange rate, being fed in. Smart oracles could not only facilitate the proper data being verifiably embedded into the blockchain, but also execute the smart contracts as desired in an objective fashion.

And many more...