Bitcoin has limited functionality when it comes to smart contracts. A classic example is the Bitcoin wallet, which is built with a scripting system and special opcodes to validate multi-signature transactions, and can not perform certain tasks. For example, one cannot apply limits on the amounts of daily withdrawals, for persistent memory is needed to store the amount of spendable money.Moreover, one does not have the ability to inspect the block timestamp or to inspect the transaction amount nor to whitelist or blacklist payment addresses.
In what has been proven to be a sound design choice, Satoshi implemented a restricted, non-turing complete language in Bitcoin to allow transactions to relay when there is a reorganization of the blockchain. Simply put, you can take transactions from one Bitcoin branch and put them into another, verified branch, so everything keeps working. It has over time become increasingly unlikely that the Bitcoin blockchain would need to be reorganized. Developers can therefore begin to consider including inspections of transactions.
Bitcoin’s scripting system comes with limitations. It is not Turing Complete, has very low available resources (small stack, limited steps), doesn’t feature recursion, and lacks persistent memory, and inspection offers almost no transaction context. Finally, the most interesting of the opcodes Satoshi left behind are disabled. RSK wants the world to deploy smart contracts on Bitcoin.
How To Implement Smart Contracts On A Blockchain?
There are two ways of understanding a smart contract. For one, a smart contract is a way to attach rules to a transaction. For instance, I can send you some money restricted for use only on, say, a University Campus. Second, you can look at a smart contract as a program with control over funds. A classic smart contract example is that of a distributed DNS system, wherein the system can accept payments to register new domains.
Generally, developers deploy smart contracts on a blockchain in one of three methods. Oracle-based smart contracts entail an off-chain approach, whereby a set of privileged nodes execute the smart contracts, produce the intended result, and then, in certain consensus-based systems such as voting, pick the true result. Ripple originally developed this approach, which is deprecated today. Nick Szabo had a similar idea, when he proposed a tamper proof, open source hardware that would be auditable for everyone to attest was accurate and untampered—a difficult engineering feat.
A second way to create smart contracts is through the use of a hybrid on-chain verification and off-chain execution. This approach can be done with a fancy and interesting cryptographic construction called a snark. Drawbacks include the requirement of a trusted setup, and the fact that implementations are fairly untested.
RSK has chosen a third way, which is the same as Ethereum’s: deterministic replicated execution. Basically, each node executes each instruction of each smart contract. With the proper setup, you can emulate both smart contract-based execution and snark-based execution with minimal costs. Developers can leverage any other smart contract solution.
The History Of Practically Implemented Smart Contracts
The first implemented DRE smart contract platform, QixCoin, was in 2013 developed by Sergio Lerner. It had its own token and was only useful for gaming and gambling, allowing one to play peer-to-peer poker on a blockchain platform. In 2014, Ethereum introduced its DRE-based implementation, while Codium introduced an oracle-based approach. And then in 2015, Counterparty introduced a DRE-based Bitcoin smart contracting platform, as did RSK.
What Is The Smart Contract For RSK?
A smart contract is an immutable program with persistent memory. This memory is protected from access by other contracts, and also features a digital safe deposit box, where you can deposit other crypto assets like currency. Basically, it can receive deposits, create payments, and receive messages, and produce messages to interact with other smart contracts to interact with other programs within the blockchain.
What Is The Distributed App (Dapp)?
A dApp is a collection of smart contracts that work in unison with an external world application. For instance, let’s use the wallet example once more. One could design a Bitcoin wallet that stores BTC and US dollars. The owner’s allowance might be capped at $1,000 per day in either BTC or USD. Dapps often entail multiple smart contracts communicating with each other.
Why Bitcoin For Smart Contracts?
Bitcoin is presently the most secure decentralized cryptocurrency. With the advent of a two-way peg, RSK proposes it can be used to do almost anything other blockchains can do. Bitcoin already leads cryptocurrency in real world use cases and network effect.
What Is RSK?
RSK strives to become a democratic smart contract layer for Bitcoin, thus increasing the number of use cases for Bitcoin, while promising low transaction fees and high transaction volume. RSK’s stated goal is to scale Bitcoin to 100-500 transactions per second.
Financial institutions could then use Bitcoin to comply with regulation and develop their own use cases on top of the earliest blockchain. RSK wants to increase incentives for Bitcoin miners to mine to encourage them to secure the network. RSK wants them to 100% mining on RSK.
RSK also wants to solve the walled gardens problem, bringing actors together to test different governance models, such as forming a committee to oversee standardization. In order to allow Bitcoiners to vote, RSK has implemented a classical proof of stake. The system rewards RSK full nodes with votes. Through cryptocurrency cryptographic construction, RSK is building a consensus mechanism called Proof of Unique blockchain storage, which can test nodes to see if they are holding a unique copy of the full blockchain.
RSK smart contracts are compatible with Ethereum. Developers can begin working on Ethereum dapps and then transfer them to RSK. A two way peg allows the RSK platform to use Bitcoin as the native currency. In order to implement a full automatic two way peg, new opcodes on the Bitcoin blockchain would otherwise be needed.
RSK started out as a hybrid-federation model. The RSK Federation serves three roles. In the beginning, it protected the network through the use of checkpoints, which will have been distributed by the network. If a node wants to know if it’s going to face a sybil attack, it can use the Federation checkpoints as a second layer of protection to ensure it stays connected to the RSK network. RSK is also incorporating merge mining, so that Bitcoin miners can mine with the same hashing power and machines with no loss of profits.
Originally, RSK’s RVM was EVM compatible, but RSK recomplied into a Java bytecode so RSK developers could use a standard programming language like Java to develop distributed applications.
Two Way Peg
The RSK model consists of two blockchains: the main blockchain and the secondary blockchain. If you want to move bitcoins from one blockchain to the other, it is not possible. You have to lock bitcoins or destroy the bitcoins on the bitcoin blockchain and then create the same amount of bitcoins on the secondary chain.
At a certain point, you’ll also need to unlock the bitcoin on the Bitcoin blockchain. You also need protocols that enforce that Bitcoins are never unlocked in blockchains simultaneously. There are at least three ways to achieve this. The simplest way would be to use the Federation and multi-signature technologies. You want parties taking part of the Federation. The second way is through the use of a side chain, a concept dating back to Blockstream entailing two new opcodes on the bitcoin blockchain side. This approach has proven problematic and limited.
The third method involves Drivechain and was proposed by Paul Stork from TruthCoin, which requires a single new opcode. Miners would have to vote on the Drivechain method which can validate alongside the federation. If miner engagement in Rootstock is high, then the same group of miners has the power to decide how to unlock the bitcoin. You enjoy the same security as a sidechain.
RSK is working towards hybrid federated sidechain solutions where new opcodes won’t be needed on the Bitcoin side. On RSK, there is a full SPV node running in a contract and synced to the Bitcoin network by means of external messages.
RSK runs a full SPV node in a contract called The Bridge. The SPV node is synced to the Bitcoin network via external messages. The SPV node provides the locking and unlocking services for RSK users and smart contracts. The Bridge is slow to transfer the bitcoins into RSK coins, which are the Bitcoins living in RSK, which must protect the network from longer reorganizations. To be able to transact to turn bitcoins into what’s called Root Coins and back very quickly, RSK partnered with exchanges to provide the liquidity just to trade one bitcoin for one Root Coin.
How Does RSK Federation Work
Instead of being locked on RSK, bitcoins are transferred to a multisig address managed by a Federation, which acts as custodian. The Federation runs a special software, FedNode, that combines a Bitcoin node and a Rootstock node in a secure environment. The FedNode listens to the logged events generated by the Bridge and on a “ready to Sign Tx” event, the FedNode signs the tx and sends the signature to the Bridge. The Bridge assembles the signed transaction and logs an event to “broadcast this tx.” There are several FedNodes running and connected to both networks.
The Federation is running a special software we call the fit note that runs a Bitcoin node and Rootstock node at the same time. The Fed listen to the events created by the bridge, and it has to obey what the bridge says.
The bridge says OK, this is a transaction you have to sign. The Federation knows to automatically go and transmit to the bridge the signature, and then the bridge assembles all the signatures, creates the transaction and announces it is broadcast on the Bitcoin blockchain. RSK is basically a Bitcoinj code running SPV node, which thinks it’s connected to the network, but is actually living in a smart contract.
To lock bitcoins, nodes can send the headers to this bridge contract, and they can send the transactions that lock the bitcoins with an SPV proof so the bridge contract can receive those bitcoins and release Root Coins.
The bridge contains a bitcoin wallet, a Bitcoin copy of the Bitcoin blockchain in SPV mode—the list of headers—and Rootstock account to be able to unlock the Root Coins. These RSK accounts initially have 21 millions of bitcoins locked in an account.
How Does RSK Implement The Two-Way Peg?
Newcodes are added to Bitcoins to lock and release BTC, either using a drive chain or a sidechain, and can be done via soft or hard fork. RSK Labs sponsors Bit2 to add drive chain-side chain functionality to Bitcoin. A big goal of RSK is to let the Bitcoin community decide how it is best to extend Bitcoin functionality.
RSK implements the two way peg with new opcodes for drivechain or sidechains on the bitcoin side with a soft fork or a hard fork. The project Bit2 worked to bring these opcodes to the Bitcoin community.
The Federation provides checkpoint protection, which serves as an alert system for nodes so they can detect if they are under Sybil attack. RSK has a target of 10 second block intervals.
What’s New on RSK?
The network is designed to have low latency and high volume:
- 300 tps (paypal does 110 tps)
- 10 second block interval
- Two stage block propagation (25BP) protocol (block compression)
- Delayed Transaction inclusion heuristic (DTI)
- Mining on Unverified Blocks Heuristic (MUB)
- Two Prioritized Streams for each connection protocol (2psc)
- Local Route Optimization Protocol (LRO)
- DECOR+ protocol for reward sharing between competing blocks
- GHOST protocol for chain weighing
RSK features a two stage block propagation, first propagating the header of the blocks in a fluid field algorithm where the heat propagates as fast as possible. So, every miner can start working on that header. And then the block information comes and miners implement a timeout to be able to switch to what they were previously doing should the header not come with the block information.
RSK is implementing the GHOST Protocol in the same manner as Ethereum. The DECOR+ protocol, which is designed for reverse sharing, is also being implemented on RSK in order to deal with potential competing blocks and to ensure altruistic mining. And also by using DECOR+ the competition for latency goes away so we can have much higher block rates. DECOR and GHOST work together. Basically in this case case, where we have three competing blocks—block x, block y, and block z. The miners can include these headers and receive a reward for including the headers. After a period, the block reward of block x is divided nearly evenly between all the competing miners. RSK has also incorporated classical optimization in blockchain sharding, holistic verification, and fraud proofs.
Probabilistic Verification and Fraud Proofs
- Store and validate a subset of the full blockchain (subset is advertised
- Challenge peers for block availability
- Monetize nodes through micropayment channels and proof of unique blockchain storage
- Score nodes based on past behavior
- Node automatically maintains redundant connections to 100% of blockchain
- User programmable signatures schemes: eg ECDSA, Schnorr, Ed25519
- Prepaid contract specific transaction fees
- Special proof of stake voting key
There are many, many use cases for Bitcoin smart contracts with many companies working on those use cases. RSK developers note that the Lightning Network will be more efficient and simple over RSK. For instance, full poker clients have been able to run on RSK, as well as crowdfunding, prediction markets, and the smart contract apps associated with Ethereum. In short, RSK wants Bitcoin miners and participants to use smart contracts.