Daily Archives: January 1, 2018

Connecting Blockchains (7)

Previous Post

It’s time to present a proposal to solve the problem of a bidirectional communicacion between heterogeneus blockhains, like Bitcoin and Ethereum/RSK. Having more support for logic (and state) in Ethereum/RSK, this solution will use smart contracts to accomplish the mission. Although there is a current implementation in RSK to connect the two blockchains, my aim is to explore an alternative one, simpler, in order to understand the problem and what are the hard parts of any solucion. So, there are common points, but also it is a departure of that implementation,

One goal I want to purse is simplicity. What are the minimal parts to take into consideration to solve the problem? One consequence: avoid UTXO (the selection of unspent transaction outputs from Bitcoin to transfer from Ethereum/RSK) logic into consensus (current RKS bridge implementation has a lot of logic to manage this case). And I want to reach a solution that can be easily implemented in many platforms, so I avoid custom code (like precompiled contracts in Java) when possible. So, I adopted Solidity as programming language to write smart contracts.

If both blockchains were homogeneus, ie Ethereum/RSK, the solution should be simpler: instead of two ways transfer, I could implement the one-way solution: how to transfer from blockchain A to blockchain B. The same solucion could be applied in inverse order.

But the current problem involves different blockchains. The main idea is depicted by this figure:

There are transactions (solid lines) and queries (get data, from source to target, after a target query). Transactions are movements that resides in the target blockchain. As I discussed in previous posts, there is an special BTC bridge account, that receives fund from a BTC user. Then, all this system should emit an Ethereum/RSK transaction that transfer value from an special Ethereum/RSK bridge account to the corresponding user Ethereum/RSK account (each user in BTC has automatically a corresponding account in Ethereum/RSK).

But smart contracts cannot get data from the external world: an smart contract cannot READ the Bitcoin blockchain. The facts that occurs in the external world should be informed by special nodes with custom offline code, that READ Bitcoin blockchain, detecting the new blocks and the transfers to the special BTC Bridge account.

So, the solution needs that special accounts, named Federators or Oracles, accounts in which the system trust. It’s a common pattern in smart contracts: having oracles, special external entities, that send transactions with new fact data, ie, a football match result to an sport bet contract.

The federation is a set that should be build at the start of this system, and it could evolve: new federators could enter into the system, and some federators could leave it. By now, the proposal to be described has a fixed federation since inception. I could discuss the evolution of federation in later posts.

A federator is connected to the Bitcoin mainnet, and detects:

  • New blocks in Bitcoin
  • Transactions that has special bridge BTC account as a member (as sender or receiver)

Also, a federator could emit:

  • A BTC transaction to transfer funds from special bridge BTC account to a normal user BTC account

These are the interaction of a federator with Bitcoin. For security reasons, the BTC transfer described above involves multisignatures outputs, that need the signature of many federators to be valid. I will discuss the built of such transaction in the next post.

The federator also emits:

  • Transactions to Ethereum/RSK informing the appearance of a new BTC transaction with funds transferred to BTC bridge account
  • Transactions to Ethereum/RSK informing the appearance of a BTC transaction that transfer funds from BTC bridge account to a normal BTC user

Then, these transactions communicate the external FACTS that this set of oracle should inform to Ethereum/RSK blockchain.

A federator also query Ethereum/RSK:

  • To know if there is a new Ethereum/RSK transaction from normal user to Ethereum/RSK bridge account

Using Ethereum/RSK as a communication device, a federator also sends to that blockchain:

  • Proposal of BTC transaction to be broadcasted to Bitcoin mainnet, to comply with the Ethereum/RSK transaction (user to Ethereum/RSK should be reflected by a corresponding Bitcoin transaction)
  • Sign any proposed BTC transaction by other federator

To do all these actions, the proposed system is:

Green rounded rectanbles are SMART CONTRACTS in Ethereum/RSK

A Federator/Oracle should manage an Ethereum/RSK account to send transactions. At the beggining of the process, each federator decect blocks and bridge BTC transactions from Bitcoin mainnet. When they have enough confirmations for a BTC transaction that transfer funds from BTC user to BTC bridge account (this step could be modified, an alternative to be discussed in next posts), a federator emits a transaction with the new BTC transaction data (hash, block hash, transaction index, sender account (an Ethereum/RSK address, translated from the original BTC user account to the Ethereum/RSK system), amount to be transferred).

The Receiver contract is like a voting system. It accepts transaction fact messages ONLY from federation members (maybe from other oracles, too, alternative to be discussed). But only when that fact has ENOUGH confirmations from the other federators, maybe m > n / 2 + 1 (n is the federation size), then it send a transaction to Bridge contract. This contract only trust in the Receiver instance. Then, the Bridge instance transfer funds from its own balance to the final user Ethereum/RSK account.

When the Bridge contract receives a transfer from a user Ethereum/RSK account, then it emits a transaction to the Sender contrac instance. This instances has state that can be query by the federators. The state consists of the list of transactions that are pending, that still need to be broadcasted to Bitcoin mainnet, to reflect the devolution of BTC to the user. It is the second part of a 2-way communication.

No federator could release BTC funds alone. Each one needs the help of the others to build a valid BTC transaction. Then, when a new pending Ethereum/RSK release transaction appers in the state of the Sender instance, a federator could build (using custom code) a proposed BTC transaction. This process involves the translatioin of the user Ethereum/RSK account address to his/her BTC address, and the selection of valid UTXOs to be applied in the new transaction to pay the user. All this process is OFFCHAIN, it does not affect consensus, and could be improved and adapted to the changes of Bitcoin implementation.

The proposed BTC transaction is sent to the Sender, as a serialized byte array. The other federators could detect the proposed transaction, and they could send a new one, adding their own signature, or they could proposed a second transaction (double spent issues to be discussed in next posts). When a transaction (a byte array in Sender instance) has enough signatures, any federator could broadcast it to the Bitcoin mainnet.

When a federator detect that the broadcasted transaction WAS confirmed in Bitcoin mainnet, it should inform the Sender. This instance, when it have ENOUGH federator confirmations, remove the pending transaction.

There are many details to be discussed. Some important ones: both Receiver and Sender could use a BTCRelay instance (an special contract, already written), that validates that a given BTC transaction exists in the blockchain with enough confirmations.

There is some initial code in my github projects, but I hope I will present a more complete picture in the next posts, with referred code implementation. Remember: talk is easy, show me the code!

Stay tuned!

Angel “Java” Lopez