Scaling Ethereum/RSK (1)

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).

Stay tuned!

Angel “Java” Lopez

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s