commenting on using two or more blockchains (homegeneous or heterogeneous), and offchain transactions. They are alternative ways to explore solutions to scalability, with a fresh start and pursuing the simplest path in each idea.

After reviewing the multi-blockchain, now I think a have a simpler path. First, this proposal is about having many HOMOGENEOUS blockchains, Ethereum/RSK-like ones. One is the mainchain, and we could have n additional blockchains:

The main blockchain has the initial ether amount of ether to use. For sake of clarity, let’s start with a main blockchain, the blockchain zero, has an initial stock of 100M ethers (in case of RSK network, it could be the 21M smart bitcoins backed by the 21M bitcoins of the BTC mainnet),

All accounts are the same in all networks: same private, public keys, addresses. So, if you have control of a control in blockchain zero, you can use the same account IN OTHER blockchain.

But the secondary blockchains starts with 0 balance in each account.

The second idea is to have inter-chain transactions, to transfer from one account in source blockchain, to the SAME account in target blockchain:;

An special bridge account is used. There is a bridge account in mainchain FOR EACH secondary chain. So, if you transfer value in blockchain 0, to bridge account corresponding to secondary blockchain 3, THEN a similar transaction will appear in this secondary blockchain, transferring the same amout from the dedicated BRIDGE account. To allow such transfer, each bridge account in SECONDARY blockchain starts with 100M of initial balance,

If there are 10 secondary blockchain, then there are 10 BRIDGE ACCOUNTS in the main blockchain (with initial 0 balance), and ONE BRIDGE ACCOUNT in each secondary blockchain (with 100M inital balance),

You also can send a transaction to a secondary blockchain, transferring value back to the mainchain:

The motivation is to have scalabilty: if the mainchain is overloaded, we can use a secondary blockchain. Also, the different blockchain could have different gas price, and maybe other difference in contract execution cost.

We could use a free graph of blockchains. But limiting the proposal to a hierarchical schema with only one level simplifies the discussion. The transactions between secondary blockchains are not allowed: only main to secondary one are supported. And no generation of new Ether is allowed in the secondary blockchains. These restrictions exist to have a better control of the total amout of value.

I could imagine a secondary blockchain by world region, country, even by vertical market. Or competing blockchains, in gas price and contract execution cost. The client software (that is, a dapp, a mobile application) could simplify the user experience, doing some of these transfer inter-blockchain in automatic.

But, how to reflect one transaction to bridge in one blockchain, to other transaction in the target blockchain? My next post will descibe a simple solution, to be discussed and reviewed. But I think it is a good starting point, to avoid the complications of some atomic swap and alike implementions.

I’m a member of development team at @RSKSmart. We are working implementing a blockchain based on Ethereum (Java version) that is connected with Bitcoin using a two way peg.

There are many ideas (not published yet) to improve scalability in Ethereum/RSK. In this new post series, I want to share a personal idea to achieve scalability: to run transactions in parallel, taking advantage of current processors.

Ethereum/RSK, as other blockchains, have blocks with transactions. The key difference with Bitcoin is that they support the execution of smart contracts. So, each transaction could be a simple value transference, or it could be a call to a contract method. Each created contract has an address, and an associated storage. The transactions in a block are executed in order, to obtain a deterministic result (state of world), at the end of its execution, in any node of the network. The whole block has an associated state of world, result of execute all its transactions in order, starting from previous block state of world.

But in many situations, two consecutive transactions are independent. The state of world at the end of their execution, is the same, without regarding the order of execution. Even calling the same contract, two transactions, in some cases, could be executed in parallel. Ie, a contract manages an asset/tokens by user, and transaction T1 alters the asset value associated to user U1, and transaction T2 alters the asset value associated to user U2. Both transactions could be interchangeable in order. And they could be executed in parallel. In this way, a contract is not the bottleneck of execution. The transaction semantic determines if the transactions are independent or not.

I was experimenting with lightweight implementations of tries, the data structure used to keep storage and calculate hash roots of state of worlds (see Building a blockchain (5)). My idea to parallelize the execution of transactions is to use a trie that support multithreading execution, detecting any conflict of read/write storage btw transactions. If N transactions can be executed without conflicts (ie, a conflict could be two transactions writing the same storage cell), then they could be executed in parallel. The base idea: use ideas from software transactional memory implementations (see Memory Transactions In AjSharp Using References).

The LMAX Architecturehttp://martinfowler.com/articles/lmax.html
LMAX is a new retail financial trading platform. As a result it has to process many trades with low latency. The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread.