Smart Contracts for Investors - How to Separate Myth from Reality

in #steem8 years ago

Smart Contracts

Everyone wants to write smart contracts these days. New startups are raising millions of dollars based upon the hype in this industry. If you are thinking of investing in one of these businesses, then this article should provide you with the necessary background to make an informed decision.

What is a Smart Contract?

A smart contract is just a program. It takes input data and generates a deterministic output. There is nothing mysterious about them. They differ from dumb contracts because they do not depend upon subjective interpretation of legalese for enforcement.

The power of Smart Contracts rests entirely in the community of people who place value on the data generated by the contract. Bitcoin is just one smart contract that allows people to transfer monopoly money amongst themselves. Because the supply of Bitcoin is limited, it gained value as a currency. The value of the output information is derived entirely from the perception of individual people.

What should be noted is that a Smart Contract does not depend upon a blockchain. All that is necessary is for the people involved to agree on the order of the inputs and the code. A blockchain is just one way getting a large number of people to agree on the order of events. Other ways involve using a timestamp authority, a public broadcast, etc.

What can a Smart Contract Do?

Perhaps the most important thing that anyone looking at Smart Contracts needs to consider is that they are only sovereign over their own data. A smart contract cannot directly control ownership of physical property or digital data that is not part of its own output data.

This means that a smart contract outside of Bitcoin cannot hold, transfer, or manipulate Bitcoin directly. New smart contracts can take Bitcoin data is an input, but they have no ability to change Bitcoin outputs on its own.

The Bitcoin smart contract only allows changes to its output when a miner produces a block containing cryptographically signed transactions that are valid according to Bitcoin's algorithm. A smart contract looking to interface with Bitcoin must generate signed transactions to move Bitcoins.

Smart Contracts have no Secrets

It is not possible to hide secrets, such as private keys, in code. This means that it is impossible for a public smart contract to sign a Bitcoin transaction.

Suppose you wanted to build a prediction market that used Bitcoin as the currency. The rules of the prediction market are simple enough to program:

  1. user places Bitcoin as collateral for their trades
  2. user trades with other users in the market
  3. judge rules on the outcome
  4. user withdraws any Bitcoin profits

Currently this process is performed by transferring your Bitcoin's to a trusted 3rd party. This third party will evaluate all bets and make sure the winner gets the Bitcoins. At any time this 3rd party could steal the Bitcoins, or more likely, have the Bitcoins stolen from them. Often these services are written using traditional databases, but it is now possible to implement these services as a Smart Contract where the operator keeps the secret that secures the Bitcoin.

Keeping secrets is hard, and a single compromised computer could undermine everyone using a Smart Contract set up in this manner. As a result many people would be unwilling to trust the operator to keep the secret secure and therefore be unwilling to place as much value in the output of the smart contract.

Sidechains

A sidechain is a new approach to Smart Contracts that offers much greater security. Sidechains allow new Smart Contracts to reliably and securely control information in another Smart Contract. This is accomplished by using multi-signature control features present in Bitcoin and other platforms.

Let's revisit the prediction market example. When someone sends Bitcoin to a Sidechain they would deposit to an account that requires 10 of 15 different keys to authorize transfers. These 15 keys would be held by different people in different jurisdictions. The challenge of compromising 10 keys is significant. It is even harder if there is key rotation which forces an attacker to compromise all 10 keys in a short period of time.

The challenge for sidechain key holders is determining what transactions to authorize and when. This is where the sidechain's smart contract enters the picture. The smart contract would take the state of the Bitcoin blockchain combined with other ordered inputs and deterministically generate the set of Bitcoin transactions that key-holders should sign.

Assuming you can trust the key holders not to collude, Bitcoin held on a sidechain smart contract is almost as secure as Bitcoin you hold yourself. Some may argue that it is more secure because most people do not use multi-signature accounts with two-factor authentication.

What language should you use?

You can implement a smart contract and/or sidechain in any language. There are projects that create their own language, others that create simple virtual machine assembly, and still others that use web standards such as JavaScript. The language you (or the business you are investing in) pick can have a dramatic impact on the success of the project. The factors to consider are often the same as any other software project.

That said here are some things that must be considered:

  1. how many developers know the language?
  2. how robust and mature is the language?
  3. how many libraries does the language have?
  4. how secure is the language?
  5. how fast is the language?

When picking languages for Smart Contracts you must consider performance. Unlike many applications, Smart Contracts are inherently sequential. This means that the output of one operation potentially impacts everything that follows. Smart Contracts depend upon deterministic behavior, without which disputes on the valid output will arise.

In other words it is not easy to scale by adding more hardware or threads. It is also not easy to tell in advance what operations are fully independent and can be run in parallel in a deterministic manner. If you are going to build something such as an exchange where every market order impacts the orderbook then your maximum throughput will depend upon how quickly a single processor can evaluate the contract.

What platform should you use?

There are generally four kinds of platforms:

  1. Fully programmable Platforms
  2. Sidechains with data stored on the main blockchain
  3. Sidechains with data stored on a separate blockchain
  4. Fully independent Platform

Fully Programmable Platforms

Some platforms implement a fully programmable Smart Contract. In this case it is technically possible to implement your application without having to resort to sidechains. The benefits of adopting such a platform include synergy with other Smart Contracts on the platform, lower-latency for inter-contract communication, and no need to provide secure infrastructure for protecting your own keys.

These benefits are not without their own downsides. Your application will be competing with all other applications for the limited shared time on the single threaded virtual CPU. This scarcity of CPU resources means they will be allocated to the highest bidder. If someone produces a popular high-value smart contract that shares your platform, then competition will bid up the cost of CPU time. This could have the side effect of making your business model unviable.

Sidechains with data stored on the main blockchain

Under this model the main blockchain provides the critical role of determining the absolute order of events for your Smart Contract. There is no need for you to provide or implement your own P2P network and it becomes trivial to incorporate the state of the main chain into the state of your Smart Contract. When adopting this approach you are free to use any language you like to implement your contract so long as it produces the same output.

Almost every blockchain supports this model, but some make it easier than others. Bitcoin makes it very expensive to include arbitrary data in the blockchain, whereas other platforms simply charge a fee for storage. The primary factor to consider when building your smart contracts in this way is the fees. Bandwidth is a limited resource and most blockchains charge a non-trivial amount for including data.

At the time of this writing, Steem is the only blockchain that doesn't charge fees for transactions containing arbitrary data. Steem chooses to utilize rate limiting and rationing to prevent abuse. This makes Steem a good platform for this particular model.

Sidechains with data stored on separate blockchain

This model is similar to the above model, except the operators of the side chain must maintain a separate and independent communication channel. This is the model that is most commonly associated with sidechains. This mode of operation is challenging because every blockchain has a window of uncertainty. During this window transactions can be rolled back and different transactions applied. Smart Contracts implemented in such an environment must merge overlapping windows of uncertainty and make sure that everyone stays in sync with both chains.

The primary downside is that this model must introduce latency equal to the slower of the two chains. An example of this latency is the 1 hour delay many Bitcoin exchanges enforce. A exchange runs its own internal "smart contract" that must incorporate state from the Bitcoin network. In order to ensure consistency in its own output, an exchange's smart contract waits until the Bitcoin transactions become irreversible. In other words, the output of a sidechain smart contract cannot be considered irreversible until all of its inputs are considered irreversible.

The benefits gained from this model include: a parallel data path and cheaper bandwidth along with the ability to filter out invalid inputs. Filtering out invalid inputs saves computational time when you replay a blockchain to verify the final outputs. If your inputs are stored on the main chain then you have no choice but to interpret and reject them again on every replay; however, if your inputs are filtered on your own sidechain then bad inputs will not stay around.

Fully Independent Platform

In this case you wish to build a Smart Contract that does not depend upon the state of any other smart contracts. This model gives you the greatest flexibility and control. It is ideal for any application that is likely to attract enough users on its own to bootstrap its own currency and value.

This approach has been the dominate approach for the past 8 years and will likely continue to be the preferred approach. Under this model you gain a degree of flexibility and independence that is not available when your hitch your success to the success of another platform.

Any changes to the main chain can have a dramatic impact on the viability of your business. These changes include things like: hard-forks, api changes, fees, and network effect. You don't want to be stuck with a Myspace app after everyone moves over to Facebook. It is concerns like this that cause savvy investors to consider implementing their smart contract as their own chain.

Independent platforms can be easily bridged to other independent platforms through a common sidechain. The common sidechain would incorporate the state of both platforms into its input and generate transactions for both platforms as its output. This bridge would only be as fast as the slowest chain.

Business Models

If you are contemplating investing in a Smart Contract based business then you must carefully consider the business model. Most models pitched today involve having a Smart Contract automatically collect fees every time a user interacts with it. An exchange can collect a fee every time an order is matched or an escrow agent can get a fee every time they are referenced by a contract.

Business models based upon smart-contract fees need to consider the following things:

  1. Ease of copying and redeploying the contract without fees
  2. Cost of fees charged by the underlying platform
  3. Willingness of customers to pay any fee at all

Preventing Copying

Suppose you develop a fully functional decentralized exchange on a fully programmable platform. Once the work of creating the contract is complete, anyone can copy the contract and remove any fees above and beyond the blockchain enforced fees. The only way to prevent this kind of competition is to offer services outside the Smart Contract. An example of this would be an exchange offering fiat on/off ramps for tokens that are only compatible with their exchange contract.

Cost of underlying Platform

Suppose you want to develop a social media smart contract. This contract allows users to post new content, vote on it, and rewards users with tokens. Building this contract on a platform that charges fees for every user action is likely to slow adoption and could be a non-starter. How are you going to onboard new users if they must first purchase tokens in order to use your smart contract. If a user votes on 100 things per day at $0.01 per action, are you really expecting them to subscribe for $30 per month?

Willingness of customers to pay any fee

Who would want to pay $0.01 every time they 'like' something? The concept of micropayments sounds good in theory, but in practice customers don't like to pay fees for something they can currently get for free. Would a new email smart contract gain any traction if you had to pay a fee for every email sent? Would a storage smart contract work if it was more expensive than the free solutions available today?

Creating a new Token

Almost every Smart Contract project of any meaningful size resorts to creating and crowd selling their own tokens. This is true whether or not the Smart Contract is implemented on top of a platform with a native token that could be used.

If your business is creating a new token, then care must be taken to answer the question of how value accumulates to the token. Suppose you create an exchange Smart Contract that has its own token that must be used to pay fees. The value of the token will be proportional to the future revenue stream of fees on the platform. Something that derives value from this source is fundamentally more limited than a token such as Bitcoin, which derives no value from fees.

Poloniex does 7 million dollars worth of volume each day which I estimate generates a revenue of 14,000 dollars per day or 5 million dollars in revenue per year. Assuming they have no operating costs this places a maximum valuation of $100 million dollars assuming a price / earnings ratio of 20. While there is significant potential for speculation on future growth of trading volume, it is clear that a token that derives its value on the basis of fees is completely outclassed by tokens that derive their value from their use as a social currency.

Many smart contract platforms have user created tokens that have much greater value than the platform they run on. In other words, just because everyone adopts a smart contract doesn't mean that value will accumulate to its token.

Don't create a token unless you have an independent platform

If it is possible to implement a Smart Contract without a new token, then strapping a new token into the mix will likely fail. It will fail for the same reason that forcing customers of your store to convert to YourStoreCoin before shopping would cause you to lose business to competitors that are able to use a more popular currency. It will fail because it is more difficult to explain new tokens and their value to customers.

If your store is going to become popular enough that YourStoreCoin starts to be used as a social currency, then chances are your application deserves its own independent blockchain. If your store needs to integrate with other stores, then it can be done via a Smart Contract that is simultaneously a sidechain on two or more independent main-chains.

If the purpose of a token is merely to manage virtual shareholders in a smart contract revenue stream then you must carefully vet the source of the revenue. If it is entirely derived from smart contract enforced fees then chances are the smart contract can be cloned and a free competitor released. If there is some kind of centralized company promising to pay profits (say from Ad revenue) then the asset is likely a security and you should beware of the legal risks faced by the company backing the token.

What should I look for in a Smart Contract Platform?

Assuming you do not wish to deploy your own independent blockchain, then you need a way to evaluate that platforms you can build upon.

Building smart contracts is challenging because it requires a level of discipline and precision that most programmers have challenges adapting to. These challenges include:

  1. making sure every calculation is deterministic and based solely on chain data
  2. making sure every change to your program state can be reverted without side effects
  3. making sure your program state can be saved and restored from disk
  4. verifying the integrity of your program state
  5. the cost of developers familiar with the language

When picking a platform you should see how many of these things the platform takes care of for you. Any platform that doesn't handle versioning of your program state will be almost as difficult as building your own blockchain. Platforms that make it impossible to write programs with nondeterministic behavior will save your developers from countless subtleties that result in nondeterministic behavior. Platforms that require developers to learn a new language will likely lack useful libraries and developer tools. In most cases, the more a platform does for you the lower the performance and the less flexibility you have.

Recommended Smart Contract Platform

In my opinion there is currently no smart contract platform that doesn't come with significant downsides. What I want to see is a platform that charges no fees, uses a high-performance deterministic sandboxed scripting language, and automatically handles saving and unwinding state changes in an efficient manner. This kind of platform is possible and will eventually be created. Ask how your business will compete once you face competitors built on such a platform.

If you have great ideas for things such as prediction markets, voting, exchanges, and gaming then your best bet at the moment is start an independent chain. Building on existing platforms will leave your business vulnerable and unable to compete.

If you must integrate with other smart contracts then remember, it is always possible to bridge two independent chains through a sidechain. This approach will give you the most independence and greatest flexibility while protecting your core business from changes in the underlying platform.

Conclusion

Navigating the turbulent waters of the Smart Contract blue ocean opportunity can be challenging. Beware of Sirens singing buzzword filled songs of praise for the latest hyped project. Good luck!

Sort:  

These benefits are not without their own downsides. Your application will be competing with all other applications for the limited shared time on the single threaded virtual CPU.

Not necessarily. You can have multiple sidechains moving in lockstep with one another acting as a single blockchain. Each side chain has its own isolated database state. Validated messages can be sent from one sidechain to the other at block boundaries only. Within a given block in a sidechain, all transaction operations are applied sequentially. But all the sidechains working on their own block would do this in parallel. The block producers of the main blockchain must run the smart contracts on all sidechains and compute their results if they want to be able to produce the next set of blocks. And that constraint allows this design to provide greater security compared to multisig-based sidechains. But you still have scaling because the computation for each sidechain can occur in a separate process running on different servers.

So as an example, you can have a DEX DApp that separates the DApp into many sub-DApps that each run a specific market. Then the market orders run sequentially (which is inherent to the nature of matching orders at best price) for a particular market, but in parallel with the order matching happening in all other markets of the DEX DApp. Inter-sidechain communication could allow a user to move their funds from one market to another.

Of course this sidechain design does mean that the DApp developers have to decide which sidechain their DApp will exist within. And their code needs to be written to take into account the fact that intra-sidechain communication between smart contracts or DApps is very different from inter-sidechain communication: there is added latency (because inter-sidechain communication only happens at block boundaries), and more importantly you cannot have a program that executes inter-sidechain communication within to run as part of a single atomic transaction.

So going back to the DEX DApp example, the limitations mean that if you have two markets each on their own sidechain, a user could not submit an atomic transaction that sells asset A for asset B (in the A/B market in one sidechain) and then sells the received asset B for asset C (in the B/C market in another sidechain) and only is carried out if it is possible to fully convert A to C. Instead, they would be forced to break it up into two transactions which means that they may get stuck with an asset B (depending on changing market conditions) that they did not wish to hold. Doing that atomically, however, is something that a DApp on the less-scalable design of the fully programmable platform (like Ethereum's current design) could be built to do. Of course, a DApp dev need not choose either extreme. They can go with the more scalable design I described above but choose which parts of their DApp should belong on the same sidechain (to get the atomicity benefits at the cost of less scalability) and which parts should be on different sidechains (but that still can benefit from synergy through secure inter-sidechain communication).

You are right, this kind of design is possible. I initially ignored such a design on the premise that it only makes sense if the ratio of intra-chain to inter-chain operations was big enough. This would mean "moving into a chain", "doing 10 things", "moving out". This would create a 5:1 ratio of inter to intra-chain operations.

At some point the overhead of communication overwhelms the benefits of parallelism. By the time you get the ratio right you might as well use full sidechains.

Great Post.. Congrats!

Added to Awesome Steem

Wow, drinking from a Double Jacket Fire Hose. Thanks man.

The value of the [Smart Contract] token, [as opposed to the native token, such as Bitcoin], will be proportional to the future revenue stream of fees on the platform.

Point to an example of this? As long as the smart contract token is fungible, there's no reason speculation capital and greater fool economics wouldn't apply here too.

It is possible for any token to become a currency with or without a revenue stream backing it. It is just very challenging for new tokens to gain significant traction in this area when it is just as easy / easier to use an existing coin.

It is possible for any token to become a currency with or without a revenue stream backing it.

It's more than possible - there hasn't been single fungible Smart Contract asset that is clearly or even somewhat valued by future revenue. There's something else always at play, and it's greater fools economics and/or size of vested community and/or liquidity and/or demand due to special properties (i.e. grants access).

Very nice read! Thanks a lot for the good explaining... maybe you know about Bitbay and the decentralized market they are building around this alt-coin https://bitcointalk.org/index.php?topic=890531.0 Have a lot to do with Smart Contracts.

Haha, that is by my good friend David Zimbeck.

Great post. In addition to his point, I think distributing benefits from expansion of the ecosystem to contributors (e.g. Popular DApp developers) like Steem's.

Coin Marketplace

STEEM 0.30
TRX 0.11
JST 0.033
BTC 64243.42
ETH 3152.93
USDT 1.00
SBD 4.28