Consulting the Oracle by John William Waterhouse

Lamden natively supports atomic swaps so that blockchains can communicate and swap assets between them. However, atomic swaps are not a simple concept to the average user. They include things such as hash locks, expiration dates, and other terms rolled up into a payload that looks something like this:

0100000001e814135d75e8c38e69669219a1cfc972f5c387abd4adc02525695f25cd3376c2040000008b483045022100d507a0bfe83ebb6bbfde864bfca7e7622ba12f06df06f55a05c69c1eb616d777022012b35a8961b4af5323baf406ac26ff863a2f6f03b4ecdc0e2551b7af7fa0331301410431ab07973bbb5dbc6b7422fc7322abb5df15f77694c0b15b09a325996af47ddd887c7eaa72c656a71fcb333068956de7b3e2f15deaafc1d9285d779ca1b6a3f6000000000290ca04000000000017a914f020520b47aa5a607234281dca442ab2d08d42ac8770da3700000000001976a914621f617c765c3caa5ce1bb67f6a3e51382b8da2988ac00000000

Even if you are the most technically advanced person alive, you have to admit that the above data is not recognizable or legible at all. That’s okay, because the data is meant to be consumed by computers. But how do we know that the person who made this atomic swap payload made it correctly? What if the script just sends the coins back to themselves when it is completed? How do we know from a human standpoint?

That’s where the concepts of oracles come into play in Lamden. As a source of reward, Lamden is introducing oracles that can prove the validity of an atomic swap in a decentralized fashion. What this means is that people don’t have to worry about what the heck is actually inside of the other person’s payload that they are trying to atomically swap with. We can then introduce levels of confidence where each confirmation is the proof that an actor in our network independently validated the atomic swap payload and it includes what it’s supposed to.

A mockup of an embeddable button that can be added to web applications to serve as legitimate proof that an atomic swap exists on both chains as both parties mutually agreed upon.

An oracle service is pretty much a redundant operation of hitting the same webpage for a piece of content and agreeing that it is all the same for all participants. This is important for certain applications where you don’t trust the other participant in your agreement that they have presenting the accurate data. By employing a third-party, the trust is distributed and it becomes very unlikely that 100 or so individuals are all colluding to send you the wrong data about what is in your atomic swap such that they can somehow profit. That would require collusion to the level where it doesn’t even make sense to accomplish.

Someone trying to steal your coins in a swap would have to know who all the oracles are prior and get them agree to a little backdoor deal where the attacker splits up the profits from the swap with all 100. With each additional oracle, the profit from an attack becomes less and less. Network fees alone on current blockchains may render that attack useless. Assuming it doesn’t, oracles are exposing themselves to the collusion out in the open because blockchains are all public. It would be very easy to view who the oracles are that are misbehaving and ban then collectively from the oracle service altogether.

So now let’s assume that you want to swap some TAU with some DOGE. You find a DOGE holder and set up a deal: 100 TAU for 1000 DOGE. You give them the DOGE address that you want to receive the coins to and they give you their TAU address. The swap gets set up such that:

Tau -> Doge TX:

Stake the 100 Tau on the Cilantro blockchain. The redeemer can redeem this coins if an argument hashed with SHA3 is equal to some value. Doge -> Tau TX:

Spend the 1000 Doge (UTXO model. Look it up if this is confusing) into a script that unlocks if the spender includes an argument that hashes into the hash lock value.

This is the standard for atomic swaps. What must happen off-chain is the production of a secret. The hash of that secret is what is included in the transactions such that:

secret = 0x123

hashlock = hash(secret)

hashlock = 0xABC Tau -> Doge TX:

Send 100 Tau from the stake to the redeemer if the redeemer sends some data where hash(data) = 0xABC.

This allows us to share the hash lock without sharing the secret and use it as a conditional to completing the atomic swap. Cool. But what if someone sends you a bad hash lock? What if they only lock up 500 Doge for you? What if they set the redeemer as themselves and when you go to unlock the atomic swap, the funds just get sent back to them? How would you know beforehand that this is happening?

Remember, all data on the blockchain is public. So all you have to do is verify the information in this blob is accurate:

0100000001e814135d75e8c38e69669219a1cfc972f5c387abd4adc02525695f25cd3376c2040000008b483045022100d507a0bfe83ebb6bbfde864bfca7e7622ba12f06df06f55a05c69c1eb616d777022012b35a8961b4af5323baf406ac26ff863a2f6f03b4ecdc0e2551b7af7fa0331301410431ab07973bbb5dbc6b7422fc7322abb5df15f77694c0b15b09a325996af47ddd887c7eaa72c656a71fcb333068956de7b3e2f15deaafc1d9285d779ca1b6a3f6000000000290ca04000000000017a914f020520b47aa5a607234281dca442ab2d08d42ac8770da3700000000001976a914621f617c765c3caa5ce1bb67f6a3e51382b8da2988ac00000000

And now we’re back to the purpose of oracles. The Doge sender could say that they made the transaction correctly and send you this blob of data as proof. It means nothing to you however because they could have sent you a bad piece of data or the data has the wrong information. Either way, you can’t read raw hex and come to a conclusion. You could try to find the data on the blockchain, but even if you do, you still don’t know what the heck it’s saying.

Instead, employ the Lamden Oracle Service to query and return a value for you. The function is pretty easy.

Does 0100000001e814135d75e8c38e69669219a1cfc972f5c387abd4adc02525695f25cd3376c2040000008b483045022100d507a0bfe83ebb6bbfde864bfca7e7622ba12f06df06f55a05c69c1eb616d777022012b35a8961b4af5323baf406ac26ff863a2f6f03b4ecdc0e2551b7af7fa0331301410431ab07973bbb5dbc6b7422fc7322abb5df15f77694c0b15b09a325996af47ddd887c7eaa72c656a71fcb333068956de7b3e2f15deaafc1d9285d779ca1b6a3f6000000000290ca04000000000017a914f020520b47aa5a607234281dca442ab2d08d42ac8770da3700000000001976a914621f617c765c3caa5ce1bb67f6a3e51382b8da2988ac00000000 contain: 1000 Doge?

The correct reciever?

The right hashlock?

If so, return true and add it to the Cilantro blockchain so that you can look it up and confirm that it is indeed valid.

This happens on Witness node machines which stake a low amount of Tau to gain the rights of voting for Delegates. However, you may not trust a single Witness. That is where redundancy and cryptography come into play.

The chances of a single Witness colluding is non-trivial. The chances of 100 Witnesses all colluding together is unlikely. Our oracle service must include a level of redundancy that makes the validations trustable. A single Witness could easily collude with all other Witnesses by generating the correct payload, as atomic swap scripts are deterministic and documented heavily in most blockchains’ codes, and sending it to everyone else to submit.

How Oracles Work on Lamden

Witness starts the session by sending Masternode the swap details. Masternode replies with a Session Key (A) public key.

To get around this, we introduce a security policy that requires three parties to confirm that a piece of data is accurate. To submit a proof as a Witness, you must first receive a session key (let’s call it A) from a Masternode. The Masternode generates a public — private keypair and sends you the public key. The Masternode then selects another random node on the network to be the ‘server’ of information. The server sends the Masternode the private key of another session key (let’s call it B). The Masternode then tells the Witness where to get the data from.

The Masternode wants a session key that can be used to decrypt data, so it gets the private key instead of the public key. The server is just encrypting data so it doesn’t ever need the private key.

The Witness then pings the server for the information regarding an atomic swap. In most cases, this is the transaction hash of the chain. The server responds with the payload encrypted with Public Key B such that the Witness can’t know what the true value is. The Witness then encrypts the data again with Public Key A so that the Masternode knows it came from the singular session that they started together.

The ‘server’ is really just another Witness or node in the Lamden system that makes the HTTP request to the desired endpoint. It doesn’t really care about the truth of the matter nor knows what the payload is supposed to look like.

Witness encrypts the data again with the session key and will sign the payload as well as proof that they were the ones that retrieved the data. It is impossible to share this data with other people and know what the underlying data truly is.

Masternodes know how to tell if a swap is valid to the original terms sent by Witness. They also assume responsibility in the case that they are incorrect. Participants lose faith in the blockchain if Masternodes lie, which means that if the Masternode wants to continue being rewarded through the Lamden system, they will tell the truth.

When Masternode gets the data, it is wrapped up as A(B(HTTP Payload)). Masternode decrypts the data with both private keys revealing HTTP Payload. This payload is then confirmed by processing the raw data and making sure that all of the fields are accurate to the conditions that the Witness initially supplied when requesting a session key. This would be things such as the amount sent to the atomic swap script, who the script pays out when completed, what the hashlock is, and the expiration date.

Masternodes just send a True or False transaction because they don’t want the underlying data leaked. Double encrypted data can’t be hacked.

If all of this information is valid, the Masternode sends a singular true transaction to the Delegates rather than the payload itself. This prevents nodes from knowing what the data is at all, rather that it’s just simply accurate.

These proofs are added up on the blockchain and left to the individual user to determine if it is sufficient to continue with the swap. If you get 5 trues and 1 false, you might assume that there was a network error. However, if you get 3 trues and 3 falses, you might think that something is very wrong and not continue forward with the swap.

Each actor in this oracle service gets a small reward for their efforts. These numbers will reflect the amount of effort required to accomplish each part of the transaction.

Takeaways

Atomic swaps and data in general is not user friendly. While a computer can parse data, you still need a way to know that it is the right data. Using our oracle service, we can now rely on the power of decentralization to produce trustable results. This service adds to our repertoire as a platform and has the ability to be expanded to other domains and deployments of Cilantro. How would a law firm use oracles?

Until next time ✌🏼