Angel \”Java\” Lopez on Blog

June 24, 2017

Alternative Proposal for Remasc Contract in Ethereum/RSK

Filed under: Blockchain, Ethereum, RSK, Uncategorized — ajlopez @ 5:37 pm

Since the release of public RSK testnet, the source code was published. And now, I can write about implementation details.

Ethereum platform supports the concept of precompiled contracts: contracts that are already implemented in the node code. In the case of RSK, we have two additional precompiled contracts: the Bridge contract, and the Remasc contract. In this post, I will propose an alternative implementation for Remasc contract (not yet with source code, there is no published official description for Remasc contract).

What is Remasc contract? AFAIK (remember, there is no public description yet), it is a contract that assign rewards to miners, examining the recent blockchain story. In order to calculate and assign rewards, it should have state related to the past blocks in the blockchain. This is the current state class. Also, there is a special Remasc transaction ADDED to EACH mined block, at the end of the list of transactions. And the target account is the Remasc contract. So, at the end of execution, that transaction is executed.

According to Ethereum Yellow Paper, there is a block finalization step:

11. Block Finalisation
The process of finalising a block involves four stages:
(1) Validate (or, if mining, determine) ommers;
(2) validate (or, if mining, determine) transactions;
(3) apply rewards;
(4) verify (or, if mining, compute a valid) state and nonce.

So, my first proposal is to remove the “compulsive added” transaction, and use the block finalization to invoke the contract. In this way, I could get rid off the nonce calculation, signing of transaction, block validation (a block SHOULD have that transaction), transaction serialization, transaction receipt storage, block transactions storage, etc….  To me, it is clear that having the reward process in the block finalization step instead of into an explicit transaction, is a simpler way. And you know, simplicity pays 🙂

The other proposal, to be explored, is to simplify the use of storage. The calculation of the next state could be performed with the blockchain information, already available. So, the current storage use is only a performance hack, that could be replaced, if needed, by an in-memory cache, removing the use of public blockchain storage. Ethereum storage is costly, and RSK is not an exception: in the current implementation, after more than 100000 blocks in testnet, running a local node in my machine, the Remasc storage takes 1/3 (one third) of total local storage. The Remasc should be deterministic, as any other contract. If for some reason it needs storage (to be reviewed when the specification is published)t, my first guess is that it needs less space than current implementation.

Stay tuned!

Angel “Java” Lopez


June 20, 2017

Offchain Transactions in Ethereum/RSK (1)

Filed under: Blockchain, Ethereum, RSK — ajlopez @ 4:45 pm

In Ethereum/RSK, a contract has a lifecycle like:

A contract is an account, it has an address and balance like any other account. But additionally, it has code and storage. The transactions it received, can have value and invocation data. And each transaction has a cost, as it is saved in the blockchain.

In this post series, I will describe a possible implementation of support for offchain transactions and state. The idea is that a contract could be in another states, others than normal one:

When a contract is at offline state, it is executed in a designated running node, only ONE node, not in EVERY node of the network. The transactions it receives are execute only in the RUNNING NODE, and they are not added to the blockchain. So, the cost of the transactions could be free or near to free. Only when the contract decided to commit the new storage state, the state is published in the blockchain using a delta onchain transaction.

The change of state from normal to offchain is triggered by the contract itself. In its code, there is a new instruction (translated to new Ethereum VM opcode), to switch to offchain status. Then, all onchain transaction are rejected for this contract, no miner could add those transactions. But new offchain transactions should be routed to the running node (the only node that is running the offchain contract instance). An offchain transaction could be identified, ie, by a nonce of -1 (it is an implementation detail: the users can send onchain and offchain transactions: the former are processed only when the target contract is in normal state; the later only when it is in offchain state),

Again, the contract code could decide, when being in offchain state, to commit its state to the blockchain, or to rollback to the previous published state. If it decides to commit, then it switch to a temporary frozen state, until a delta onchain transaction is mined and accepted by the rest of the network. The delta transaction has the mission to update the published state to the new one, hosted by the running node.

In the next posts, I will describe the delta transaction with more detail, and I will discuss also the value transfer in case of offchain transactions. Maybe, now the RSK main code is public, I would publish a light implementation of these ideas.

Stay tuned!

Angel “Java” Lopez


June 18, 2017

Multi-Blockchains in Ethereum/RSK

Filed under: Blockchain, Ethereum, RSK, Uncategorized — ajlopez @ 1:51 pm

The implementation of a blockchain includes the creation, distribution, and manage of blocks:

A block, in Bitcoin and Ethereum, has:

  • An unique hash
  • A parent block, identified by hash
  • A block number (one plus parent block number)
  • A list of transactions

In the case of Ethereum and RSK, a transaction has:

  • A sender account
  • A receiver account
  • A value to transfer
  • Additional data (used if the receiver account is a smart contract)

A list of chained valid blocks form a blockchain:

In Ethereum/RSK, a block has also:

  • Uncle blocks
  • Associated Block Difficulty (difficulty of proof of work plus the sum of uncles difficulties)

So, the presence of uncles contributes to the block difficulty. And this number adds to the TOTAL difficulty of the blockchain. Many nodes in the network, called miners, could generate blocks to be added to the current blockchain, but the consensus algorithm  choose the blockchain with the greater total difficulty:

(in Bitcoin, the longest blockchain wins; in Ethereum/RSK a shorter blockchain could win if it has greater total cummulative associated difficulty).

One problem is to keep the state of all accounts and contracts in the system. Each transaction also has

  • State Root Hash

the hash of the world state AFTER the execution of the transaction. This hash is verified by every node in the network, so all the working nodes agrees on the resulting world state. A world state is saved in a trie, that can be identified by such root hash (see my previous work on tries Building a Blockchain (5) Building a Blockchain (12))

The block itself also has a State Root Hash, representing the world state AFTER the execution of the block. It could be different than the last transaction state root hash: the execution of block could assign rewards and alter account balances, if the protocol specifies the changes. This block root is also checked by the running nodes in the network, in order to validate the block state and consensus.

One problem is that the build of a block could be a bottlenect if the system should process many transactions (maybe hunders or thousands per second). This is the principal use case that guides the proposal of this post series. It could be interesting to have MANY blockchains:

Then, one blockchain could be dedicated to the process of a popular token/contract, or other blockchain could be dedicated to the transfer in a particular country. Only in few cases could be needed a transfer between blockchains. And this schema is not limited to TWO blockchains, we could have many blockchains. And the state storage and status could be maintaned by MANY nodes, sometimes, a node is dedicated to keep only ONE or TWO blockchains. So the scale of the operation does not hurt the system.

In the next post, I will describe the modification to apply to Ethereum/RSK so we can  manage multiple blockchains in the network.

Stay tuned!

Angel “Java” Lopez





June 17, 2017

Blockchain: Links And Resources (44)

Filed under: Bitcoin, Blockchain, FinTech, Links, RSK, Smart Contracts, Solidity — ajlopez @ 8:01 pm

Previous Post

Visualizing Where Major US Banks Have Invested in Fintech

A Blockchain in 200 Lines of Code

Gartner’s Cool Vendors In Blockchain Platforms

eth Interactive Console

All cases when Solidity compiles to invalid jump destination

RSK’s Ginger: New step for bitcoin community

Dos proyectos argentinos ganaron una competencia global para combatir la corrupción

Ethereum – Distributed Consensus (A Concise Ethereum History Book)

Ethereum flavored WebAssembly (eWASM) Design

How Etheroll and other Dapps will kill Ethereum

Ethereum Ecosystem

My Links

Stay tuned!

Angel “Java” Lopez

June 11, 2017

Running an Ethereum/RSK Node

Filed under: Blockchain, Ethereum, Open Source Projects, RSK — ajlopez @ 2:43 pm

The RSK public testnet was launched, and the core source was opened. If don’t know what RSK is, please visit:

Technically, it is a fork of Ethereum (Java source), with a 2-way peg with Bitcoin, and merge-mining capabilities. You can run your own node, alone, in your own network, or join it to the public testnet. There are instructions at thecore project github wiki:

In this post, I want to describe my usual workflow, to run experiments with RSK implementation and ideas (disclaimer:I’m a member of RSK development team, but this is a description of my personal experiments). First, you have to downloadthe source code from:

Currently, the most updated published version is at branch Ginger:

Also, you can clone the repository into your own one. Once you have the source code, you can compile using IntelliJ  deaCommunity Edition, or use the command line:

.\gradlew build shadow -x testnet

(I’m usually work with Windows, in Linux, Mac, you must use the normal /). More details at:

The shadow option is to build a jar with all the dependencies. The -x test skips the run of test from build step. The command generates a .jar file in one subdirectory. Then, you can execute

cd rskj-core\build\libs
java -Drsk.conf.file=<path> -cp rskj-core-0.2.0-GINGER-all.jar co.rsk.Start

What config file to use and to configure it? More info at:

An initial config file at:

You must set a unique nodeId for your instance. You can generate a nodeId using the command line:

java -cp rskj-core-0.2.0-GINGER-all.jar co.rsk.GenNodeKeyId

It dumps a JSON file to console. You must copy the private key and the node id, to your config file:

# Private key of the peer
nodeId = 66cf57...
privateKey = 46f850...

You only need to copy the privateKey to run the node, but you can include the nodeId also for your own reference. The other line to configure is the coinbase secret:

# this string is computed
# to be eventually the address
# that get the miner reward
coinbase.secret = mytreasure

You must put an arbitrary string here.

To allow the CORS (Cross-Origin Resource Sharing) for your JSON RPC (Remote Procedure Call), set the cors property:

rpc {
    enabled = true		# you can disable rpc
    port = 4444
    cors = "*"    # you can put "localhost here"

The RPC capability is only used to query the node, and disabling it does not interfere with the normalwork of the node. How the node knows how to connect to the public Testnet? There is a list of bootstrap nodes:

peer {
	discovery = {
        # if peer discovery is off
        # the peer window will show
        # only what retrieved by active
        # peer [true/false]
        enabled = true

        # List of the peers to start
        # the search of the online peers
        # values: [ip:port]
        ip.list = [

to use in what is call the “peer discovery” process. You can disable them if you want only to use your own node in your network.

If you want to run MANY local nodes, you must have MANY configuration file. In these files, adjust also the properties:

    # Peer for server to listen for incoming connections
    # 50505 for testnet
    listen.port = 50505 # ie to 50506

and the already mentioned:

rpc {
    enabled = true
    port = 4444		# ie to 4445

Additionally, you can set your own network id, so your local o networked nodes only work for this network:

    # Network id
    networkId = 777  # ie to 42

You can also specify in each of your nodes the active nodes to connect, instead of using peer discovery and bootstrap public nodes:

    # Boot node list
    # Use to connect to specific nodes
    active = [    
        #    ip =
        #    port = 50505
        #    nodeId = e437a483...

As usual, you can set the machine name instead of IP number, using the same property ip.

If you want your node mine new blocks, change these properties to true:

# miner options
miner {
    server.enabled = false  # change to true
    client.enabled = false	# change to true

If you change only the server.enabled property to true, you can expose the new block to merge mining process, but this feature is beyond the scope of this post.

Any other question? You can visit the RSKJ gitter channel:


RSK is hiring! Interested?

Stay tuned!

Angel “Java” Lopez


May 30, 2017

Blockchain: Links And Resources (42)

Filed under: Bitcoin, Blockchain, Ethereum, FinTech, Internet of Things, Links, RSK — ajlopez @ 11:51 am

Previous Post
Next Post

Bitcoin’s New Scaling ‘Agreement’: The Reaction

Consensus 2017: Blockchain Consortia in A Rapidly Changing Market

Consensus 2017: Advice From a Lawyer to ICOs: ‘Don’t Be Stupid’

Consensus 2017: Even Academics Can’t Keep Pace With Blockchain Change

Day of Demos: Blockchain-IoT Consortium Kicks Off With Use Cases Aplenty

Consensus 2017 Recap: The Biggest Main Stage Moments

Segwit explained

Extension Block Story

My Links

Stay tuned!

Angel “Java” Lopez

May 28, 2017

Blockchain: Links And Resources (41)

Filed under: Bitcoin, Blockchain, Ethereum, FinTech, Links, RSK — ajlopez @ 3:09 pm

Previous Post
Next Post

Selfish Mining: A 25% Attack Against the Bitcoin Network

Bitcoin: The New Gold Standard

RSK Releases Ginger, The Open Source Public Testnet

RSK Raises $3.5 Million, Launches Bitcoin Smart Contract Testnet

Blockchain to Reshape the Electric Grid?’

Scaling Consensus? This Turing Winner Thinks He’s Found a Way

Bitcoin Scalability Issue Takes New Turn As RSK Ready to Release Ginger

Barbarian Investor Show Episode 3 – RSK Smart Contracts secured by the Bitcoin Network

My Links

Stay tuned!

Angel “Java” Lopez

May 24, 2017

Launch of RSK TestNet

Filed under: Blockchain, Open Source Projects, RSK — ajlopez @ 11:05 am

The project started on 2015. I’m a member of dev team since one year and two months. Past Monday, the RSK TestNet was presented to the public, after running for months in private mode. The announce was made in Consensus 2017:

The intructions to participate in the TestNet:

The main open source code repo at:

You can check the TestNet status (some nodes) at:

The project is oriented to run an autonomous Ethereum network that allows the execution of smart contracts, using bitcoins to pay for the cost of running those contracts. There is a 2-way peg system to transfer from your BTC account to your own RSK account, and viceversa. The exchange is one to one. This is one of the pillars of the project: leverage Bitcoin network to use smart contracts. Another interesting pillar: RSK uses merge-mining, associated with miners that produces Proof of Work for RSK blocks using the PoW for BTC.

If the smart contract word is new to you, check the project:

I’m sharing resources and writing about blockchain (including code examples) in:

I hope to write more posts describing the RSK project.

Nos leemos!

Angel "Java" Lopez

May 8, 2017

New Month’s Resolutions: May 2017

Filed under: AjTalk, Blockchain, C Sharp, Ethereum, JavaScript, NodeJs, Open Source Projects, RSK — ajlopez @ 11:51 am

There is a new month, time to write the new resolutions. First, a review of the previous ones:

– Continue RskSharp [complete] see repo
– Continue SimpleBlockchain [complete] see repo
– Continue Solidity Compiler [pending]
– Continue ChineseP [complete] see repo
– Continue TensorSharp [complete] see repo
– Continue RSharp [complete] see repo
– Continue SimpleForth [pending]

Additionally, I was working on:

– Continue BlockchainSharp [complete] see repo
– Start Neurum, neural networks in C# [complete] see repo
– Improve AjTalkJS, Smalltalk interpreter in JavaScript [complete] see repo
– Improve SimpleProlog, Prolog interpreter in JavaScript [complete] see repo
– Improve AjDrawJS [complete] see repo

New month’s resolutions:

– Continue RskSharp
– Continue SimpleBlockchain
– Continue BlockchainSharp
– Continue ChineseP
– Continue TensorSharp
– Continue RSharp

Stay tuned!

Angel “Java” Lopez

May 5, 2017

Blockchain: Links And Resources (39)

Filed under: Bitcoin, Blockchain, Ethereum, FinTech, Links, RSK, Smart Contracts — ajlopez @ 9:12 am

Previous Post
Next Post

Found a major TokenCard ICO token distribution bug

Catastrophic Property Risks? There’s a Blockchain for That

Monax Burrow

Hey – You got your Ethereum in my Hyperledger!

RSK Research News > Storage Rent

Ethereum JSON RPC

Ethereum Tokens Network is growing! – on average 4500 operations per day


Trustlines Network: The original Ripple idea built on Ethereum

Check for an rsk client


Tezos: The self-amending crypto-ledger

My Links

Stay tuned!

Angel “Java” Lopez

Older Posts »

Blog at