functional colored coins and hybrid consensus, part 1

0 views
Skip to first unread message

Alex Mizrahi

unread,
Dec 25, 2014, 8:20:15 AM12/25/14
to bitc...@googlegroups.com
Usually colored coins are described as a simple asset transfer/ownership tracking system which lacks capabilities for "smart contracts". (Aside from those which are based on Bitcoin scripting and transactions, i.e. this https://en.bitcoin.it/wiki/Contracts .)

This is largely true, as the colored coins model is limited compared to what metacoins (Mastercoin, Counterparty) or systems like Ethereum can provide: it lacks an ability to use implicit dependencies when computing color values, and implicit dependencies are crucial for implementation of derivatives, betting, etc.
(I.e. the value of a coin must depend on something which is outside of that specific coin's history.)

(It's not necessarily a bad thing: one could argue that simplicity makes colored coins more suitable for simple asset transfer/ownership tracking systems.)

However, this doesn't mean that one must ditch the colored coins model to implement complex smart contracts. There is also an option to build a hybrid system where colored coins exist as one of layers, and extra "business logic" is added on top of it. Quite likely such a hybrid system will require non-fungible colored coins with non-scalar colorvalue types.

I described non-scalar colorvalue types in the follow-up discussion to "The theory of colored coins" article: the model described in the article doesn't require colorvalues to be of a particular type, thus it can be a tuple, vector, or, really anything. I provided several examples, most interested and advanced of which was fully decentralized prediction market.

However, these examples were provided as sketches and ideas and lacked formalized, rigorous descriptions.
So this is the problem: we lack formalisms which are necessary to described advanced used of colored coins.
The concept of functional colored coins, which I'm going to introduce in this article, is one of such formalisms.
(I'm aware of another such formalism which is currently in advanced stages of development, but I can't elaborate on this.)

We will start with a motivating example: CFD/NDF-style derivatives. Formal description will be provided after this example.

Color kernels which are in use now (OpenAssets, EPOBC) work with colorvalues which are concrete numbers. E.g. if we have a USD-denominated e-money based on colored coins, one might have an output with value of $12.45 USD, and he is able to send it to somebody, or split it into several outputs, etc.

But what if instead of concrete numbers we had colorvalues which are ...functions?
We still can represent a concrete number as a nullary function: f() = $12.45
But then we will also be able to create contracts with payoff defined as a function accepting some (external) data as a parameter.

Suppose Alice and Bob have $1000 worth of USDcc each, and they wish to enter a CFD-like contract for MSFT shares. Alice is long on MSFT price, and Bob is short.

Initially they own outputs which have concrete value, thus they can be represented as nullary functions:
Alice_output_1() = 1000
Bob_output_1() = 1000

If the current MSFT price is 48.14, and Alice is long on 10 MSFT shares, her CFD payoff is:
 Alice_payoff1(MSFT_price) = (MSFT_price - 48.14) * 10
and Bob's payoff has same absolute value as Alice's payoff, but a different sign:
 Bob_payoff1(MSFT_price) = (48.14 - MSFT_price) * 10

They will provide outputs they initially own as collateral (initial margin) of the contract, and after those outputs are used, their payoff can be described by formulas:

 Alice_payoff2(MSFT_price) = 1000+(MSFT_price - 48.14) * 10
 Bob_payoff2(MSFT_price) = 1000+(48.14 - MSFT_price) * 10

However, as there are no margin calls in this system (we want it to be trustless), payoff must not be lower than 0 or exceed 2000.
Thus, finally we have:

 Alice_capped_payoff(MSFT_price) = min(max(1000+(MSFT_price - 48.14) * 10, 2000), 0)
 Bob_capped_payoff(MSFT_price) = min(max(1000+(48.14 - MSFT_price) * 10, 2000), 0)

So this looks good enough, as law of conservation is satisfied, thus we can use these formulas to describe values of outputs of CFD transaction.
That is, to create a CFD contract, Alice and Bob will create transaction with two inputs:
 Alice_input() = 1000
 Bob_input() = 1000
And two outputs:
 Alice_output_2(MSFT_price) = min(max(1000+(MSFT_price - 48.14) * 10, 2000), 0)
 Bob_output_2(MSFT_price) = min(max(1000+(48.14 - MSFT_price) * 10, 2000), 0)

Sum of inputs is 2000, and sum of outputs is 2000 for all values of MSFT_price, thus this transaction is valid w.r.t. laws of conservation.

As a result of this transaction, Alice owns an output which is worth `min(max(1000+(MSFT_price - 48.14) * 10, 2000), 0)`.
Now what? What can we do with outputs whose colorvalues are non-nullary functions?

First of all, we can combine them back. E.g. suppose after some time MSFT_price goes to $52.14.
If both Alice and Bob have consensus over MSFT_price and no longer want to hold a CFD, they can create a transaction which cancels it:

Inputs:
 Alice_input(MSFT_price) = min(max(1000+(MSFT_price - 48.14) * 10, 2000), 0)
 Bob_input(MSFT_price) = min(max(1000+(48.14 - MSFT_price) * 10, 2000), 0)
Outputs:
 Alice_output_3() = 1040
 Bob_output_3() = 960

This can be proven to be a valid transaction, as the sum of inputs is $2000 and sum of outputs is $2000 too.

In a different situation, if Alice no longer wants to be long on MSFT, she might sell her output to Claire for $1040:

Inputs:
 Alice_input(MSFT_price) = min(max(1000+(MSFT_price - 48.14) * 10, 2000), 0)
 Claire_input() = 1040
Outputs:
 Alice_output_3() = 1040
 Claire_output() = min(max(1000+(MSFT_price - 48.14) * 10, 2000), 0)

And then Claire will be able to combine her output with Bob's to get actual money.

So far so good. But what if Bob have lost his private key, is Alice (or a person Alice sold her output to) doomed to hold this CFD forever?
What if she wants to redeem her output for actual USD, but Bob is unwilling, or cannot help to cancel the MSFT exposure?

In this case we need CFD-like contract which will expire at some point. Which makes it the same as Non-deliverable Forward (NDF) contract.

Let's replace MSFT_price with MSFT_price_at_T in the original formula: it will denote MSFT price at some concrete point in future (T).
After this point, users might reach a consensus of what  MSFT_price_at_T is, and thus it becomes a constant.
Thus expression `min(max(1000+(MSFT_price_at_T - 48.14) * 10, 2000), 0)` 
s also a constant, and thus Alice now has a concrete amount of coins, and this can be recognized by anyone who is in a consensus with Alice over what is the value of MSFT_price_at_T is.

So let's say Alice an Bob specified that MSFT_price_at_T is the closing price of MSFT on NASDAQ on 2015-06-07.
Suppose that the closing price of MSFT on NASDAQ on 2015-06-07 is $52.14, as reported by NASDAQ.
Thus after this date, all clients which are able to fetch this number from NASDAQ will see the value of Alice's output as $1040.
Particularly, the issuer will see it as $1040, thus he will agree it redeem it for $1040 according to the issuance contract.

Note that this requires consensus over data which is provided by an external source (NASDAQ), and this cannot be taken for granted.
Thus we have a hybrid consensus system, which combines several different consensus mechanisms:

1. there is a strong cryptographic consensus over the colorvalue-function of Alice's output
2. there is a Bitcoin blockchain-based consensus over who currently owns that output
3. there is a trust-based consensus over the variables which are used in the function

I think it's obvious that this hybrid system has benefits over centralized trust-based systems: we only need to trust a data feed, and only to a limited extent.
A data feed doesn't have a power to block anyone's transactions, or charge fees, or discriminate different agents.
A big part of the system is fully decentralized (as decentralized as Bitcoin), and thus has all the benefits of a decentralized system:
We do not have a single point of failure (if data feed is temporarily down, transaction can still be made, that will only delay "settlements").
If the data feed goes down, clients might elect another data feed, they just need a consensus over what data feed to use.
Finally, if a data feed becomes malicious (publishes wrong data, or a  different data to different actors), clients might choose to elect a different data feed.
As settlements are not recorded in the blockchain, but are a function of the current consensus, the situation can be remedied even after a data feed publishes erroneous data: clients can undo the damage as soon as they discover the error and switch to the correct data. Thus the system can be robust to a very large degree.

It's also worth noting that we can use arbitrary consensus mechanisms on the third layer, not just simple trust-based ones.
E.g. there might be a network of trusted oracles which will make sure that everyone has the same view over what data was published.
Or there might be some kind of a Byzantine Fault Tolerant network, or a network based on a Ripple-style consensus.
At this point we are only describing a framework within which different consensus mechanism can be combined.

(A blockchain-based consensus is possible too, e.g. client might scan the blockchain for the executed trades to find the price which is used for CFD/NDF settlements, and thus achieve functionality similar to that of Counterparty.)

Let's summarize what we've got so far:

 1. We introduced a level of indirection: instead of getting a monetary value of an output directly, we get a function which yields a monetary value once the data is provided.
 2. A color kernel might work with functions instead of scalar values: it will receive input colorvalue-functions and will transform them into output colorvalue-functions according to the data embedded into the transaction.
 3. In order to achieve a global law of conservation (we do not want issuer's liability to depend on the contracts which are created by users among each other, i.e. users shouldn't be able to create more money for themselves), it is enough to ensure that the law of conservation is enforced by the color kernel, i.e. it checks that the value of output colorvalue-functions equals to value of input colorvalue-functions for all values of free variables.
 4. We get to the actual monetary values using a secondary consensus system, which can be arbitrary: based on trust, BFT-systems, blockchain-based, etc.

One thing which is lacking is a graceful handling of situations in which the secondary consensus is lacking: we do not want the system to blow up in such situations. Instead, we want to detect them, and to pause operations until the consensus is restored.
This can be done using interactive payment protocols/interactive payment verification.



Yoni Johnathan Assia

unread,
Dec 27, 2014, 5:05:13 AM12/27/14
to bitc...@googlegroups.com

Alex,

This is very interesting.
Can you describe the entire ecosystem of issuance and creation ?
It seems that if added to the cc protocol a valid price model (bloomberg), then people can issue CFDs and exchange them, but who do you need to trust to eventually get paid ? You need to trust that there is demand for the contract you bought from people who price according to the protocol ?

Yoni

--
You received this message because you are subscribed to the Google Groups "Colored Coins" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinX+u...@googlegroups.com.
To post to this group, send email to bitc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alex Mizrahi

unread,
Dec 27, 2014, 8:26:03 AM12/27/14
to bitc...@googlegroups.com

Can you describe the entire ecosystem of issuance and creation ?

This concept is very general and can have many uses, concrete ecosystem depends on what use you have in mind. 

It seems that if added to the cc protocol a valid price model (bloomberg), then people can issue CFDs and exchange them, but who do you need to trust to eventually get paid ? You need to trust that there is demand for the contract you bought from people who price according to the protocol ?

Contracts will be denominated in a certain currency, which will be used for settlements. This currency cannot be Bitcoin, as we cannot change Bitcoin protocol rules.

I think it will be the best if a currency with a stable value is used, e.g. USD. (In principle, it might be possible to use multiple currencies within a single system, but let's consider a single currency case first.)
Thus we need somebody to issue USD in form of colored coins which allow contracts to be made.

Ideally it should be a financial institution, perhaps a bank.
Note that the system is designed in such a way that this bank won't be a party in any of the contracts and has no financial risks. Aside from holding USD which back the issued colored coins, it will have no exposure to any financial instruments.

So, let's say it is JPMorgan which does it. Suppose Alice wants to trade, she sends $1000 USD to a special account in JPMorgan to get $1000 worth of USD-cc.

She can then use it for trading, e.g. making contracts with fellow users, or with various services, etc.
Most contracts (well, hopefully) can be formulated in such a way that she doesn't need to trust those other users or services: she only need to trust the issuer (JPMorgan) and the source of price data (Bloomberg?).

So, suppose Alice holds some contract to maturity. She doesn't depend on a counterparty to settle this contract, she can go directly to the issuer (JPMorgan) to get her money.

JPMorgan can calculate how much money Alice has using the data in the blockchain and pricing data from Bloomberg.
Let's say calculation shows that the value of the coin Alice owns is now $1145 USD.
There is no risk for JPMorgan to take this coin and send Alice $1145 real US dollars: laws of conservation embedded into the color kernel guarantee that the total value of all issued colored coins remains the same no matter what contracts users make and how they settle them.

What's important, Alice can prove that her coin has a certain value. Thus, if JPMorgan refuses to redeem it for real USD, Alice can go to court with the proof she has and demand money according to the contract JPMorgan 

So it's very similar to "normal" colored coins in this respect, but offers richer functionality.

It's still not clear what functionality can be implemented. Say, prediction markets and NDFs are relatively easy to implement in a trustless manner.

But is it possible to implement a trustless CFD which would allow user to close his position at any time?
I'm not sure. It might be easier to offer semi-trusted CFD:
 A service will sell user an NDF, but will offer user an ability to liquidate it at any time.
However, if service goes down, user won't be able to liquidate his CFD, but he still owns a trustless NDF, which will eventually settle.
This might be good enough, at least it's much better than a centralized service which might steal user's deposits.
Also it will allow CFD companies to get some revenues. :)

Another question is whether we really need an issuer. I believe that this could work in a fully decentralized manner and be based on a fully decentralized currency, but, in practice, volatility of that currency can be a problem.

Also it might be easier to understand a system in which the contract specifies that the value is calculated using a formula which is obtained from the blockchain, than a system based on a fully decentralized consensus, even if practically it is the same thing.

Finally, there are several different implementation approaches. One option is to create a color kernel which provides some fixed functionality (e.g. only NDFs which are implemented in a certain way). 
And another option is to enable an ability to create arbitrary contracts.
The later option is harder to implement.

Richard Brown

unread,
Jan 2, 2015, 4:17:31 AM1/2/15
to bitc...@googlegroups.com, bitc...@googlegroups.com
Hi Alex,

Really interesting idea.   I guess another reason the CFD example could be troublesome is that, in your description below, Alice and Bob are able to enter into the agreement without reference to the issuer of the USD liabilities.   And in the general case, we can't assume the issuer would be able to (or want to) have any part in the trade.  Trivial example: the issuer might not be able to evaluate the payoff functions (perhaps Alice and Bob have agreed to use a feed that the issuing bank doesn't have a commercial license for, or whatever).     So one can't assume Alice or Bob could ever sell their position back to the bank -- they'll either need to agree amongst themselves to close out at the same time or find a third party willing to take over the position. 

The other question I had is more general:  my mental model of CFDs is that they're easy to conceptualise as analagous to buying the underlying without the hassle of actually buying it and taking custody, etc.  But, in reality they're a tool for leverage.  And for this model (and all the other smart contract ideas for derivatives I've seen) to work, you need to prefund the positions.  Does this not negate 99.9% of all use-cases?     Or do you envisage building layers on top (e.g. to pool collateral, perform netting, execute automatic close-outs if prices move too far, etc, etc)

Richard
Reply all
Reply to author
Forward
0 new messages