Angel \”Java\” Lopez on Blog

September 24, 2017

Building A Blockchain (16)

Previous Post

In recent months I have been busy working on the RSK project. It’s time to write about my personal blockchain projects:

Currently, the most active one is the C# project. I added one project:

in Java. The experience I gained written all this code (using test-driven design, as usual) gaves me a clear idea of what is involved when building a blockchain. Writing my own implementations gave me better understanding of the parts related to the creation of a blockchain. And now the RSK project (Java core implementation) is public, I’m free to relate this work with an existing full implementation.

The key points to be written are:

  • Entities
  • States
  • Virtual machine to run smart contracts
  • Encoders
  • Consensus
  • Validation logic
  • Inter-node communication
  • Expose node state to external applications

The base entities are:

  • Block
  • Transaction
  • Account

The states to be kept are:

  • Blockchain
  • Account state
  • Contract state

My projects are oriented to have smart contracts, a la Ethereum. One reason to have a virtual machine is be agnostic of host programming language. I think that having a way of run smart contract that is independent of the programming language used in each project, is an interesting feature. So, I should define:

  • Virtual machine opcodes
  • Transient (memory) storage
  • Persistent storage

I need encoders for blocks, transactions and account states. The encoded entities are used in the network communication, local storage, and in the hash calculation. For example, when I have to transmit a block I encoded it. And if I want to send the block to another node, I should encoded the block before transmission. And the encoded data is the basis for hash calculation.

The inter-node communication includes:

  • Message definitions
  • Message and handshake protocol
  • Peer-discovery protocol

Validation logic refers to:

  • Validation of blocks
  • Sign of transaction and its validation

Consensus logic has:

  • Selection of the next block
  • Run of the transactions, updating the accounts/contracts states

The exposure of a node state is implemented in Bitcoin and Ethereum using JSON RPC (Remote procudure call), usually exposed via http. In this way, the node can be accessed by external technologies implemented in different technologies (JavaScript blockchain ecosystems are the more popular).

Followin Ethereum ideas, one entity I implemented many times is a trie. I think my implementations are very simple and effective. I hope to be able to write in the next posts about those implementations.

Stay tuned!

Angel “Java” Lopez




September 13, 2017

Artificial Intelligence: Links And Resources (41)

Filed under: Uncategorized — ajlopez @ 4:38 pm

Previous Post
Next Post

More artificial intelligence, fewer screens: the future of computing unfolds

Why AI Isn’t The Robot Apocalypse For Jobs

Exploring the Artificial Intelligence Ecosystem: AI, Machine Learning, and Deep Learning

Google’s Research In Artificial Intelligence Helps In Preventing Blindness Caused by Diabetes

TensorFlow 1.0 unlocks machine learning on smartphones

The Business of Artificial Intelligence – Harvard Business Review

Our Fear of Artificial Intelligence – MIT Technology Review

Artificial Intelligence | edX

Stay tuned!

Angel “Java” Lopez

July 20, 2017

Blockchain: Links And Resources (47)

Filed under: Bitcoin, Blockchain, Ethereum, Smart Contracts, Solidity, Uncategorized — ajlopez @ 2:48 pm

Previous Post
Next Post

Underhanded Solidity Coding Contest

Solidity CRUD- Part 1

Más usos para la tecnología de las monedas virtuales

What is Bitcoin Mining?

Announcing “Around the Block”: a Documentary Series about the Minds Behind the Blockchains

Potential network disruption

Formal Verification of Ethereum Smart Contracts

Functional Alternative to Ethereum (in Haskell)–Fae

Don’t Get CoinDashed — How to Secure Your Token Sale

A Brief History of Blockchain: An Investor’s Perspective

Stay tuned!

Angel “Java” Lopez

July 8, 2017

Learning Ethereum/RSK (1)

Filed under: Bitcoin, Ethereum, RSK, Uncategorized — ajlopez @ 6:24 pm

Next Post

I joined the @RskSmart development team at the beginning of last year (February 2016). I was an experienced software developer, but without knowledge of Bitcoin, Ethereum, blockchains and related topics. So, I started studied a lot, to grasp the project, the objectives, the initial code, and its challenge.

In this post series, I want share with you what I learned, and comment some books/resources that could help me (I didn’t read everything but now, with my current experience, they look as something that add value).

The first thing to understand is the blockchain concept. It is the “new kid on the block” (pun intended 🙂 and it is a core concept to understand, in order to grasp Ethereum and RSK projects. The most succesful implementation of a blockchain is Bitcoin, so, as a developer, you will gain a lot of insight if you read about that project.

The main source for Bitcoin as software developers, is:

Mastering Bitcoin (second edition repo)

a masterpiece by Andreas Antonopolous (personal site)(twitter)(wikipedia page)(youtube channel)(blog)

I read:

This book is mostly intended for coders. If you can use a programming language, this book will teach you how cryptographic currencies work, how to use them, and how to develop software that works with them. The first few chapters are also suitable as an indepth introduction to bitcoin for noncoders—those trying to understand the inner workings of bitcoin and cryptocurrencies.

And I learned a lot from this book. The Bitcoin implementation of a blockchain is explained clearly, from a software developer point of view, so it is a good introduction to this new brave world. It has chapters about: How Bitcoin Works, Bitcoin CoreAddresses, Wallets, Transactions, Advanced Transactions and Scripting, Blockchain, Bitcoin Network, Mining and Consensus, Alternative Blockchains, Applications, Bitcoin Security, Bitcoin Improvement Proposals.

He is working on an new book Masrtering Ethereum, that it could be the MUST BE READ book if you want to be an Ethereum developer.

If you understand Bitcoin and its related ecosystem, you will be in a better position to manage Ethereum and @RSKSmart projects. And RSK has code that related Bitcoin network with its own.

Next posts: more books, concepts and resources

Stay tuned!

Angel “Java” Lopez


July 5, 2017

New Storage in Ethereum/RSK (1)

Filed under: Blockchain, Ethereum, RSK, Smart Contracts, Uncategorized — ajlopez @ 12:13 pm

Next Post

An Ethereum Virtual Machine manages a contract storage, in cells, each one having a 32-byte address and a 32-byte value. A simplified view:

But in RSK implementation, there is a new feature: a cell can contain an arbitrary byte array data:

This feature is exposed by new methods included into the original Repository interface:

     * Put a value in storage of an account at a given key
     * @param addr of the account
     * @param key of the data to store
     * @param value is the data to store
    void addStorageRow(byte[] addr, DataWord key, DataWord value);

    void addStorageBytes(byte[] addr, DataWord key, byte[] value);

     * Retrieve storage value from an account for a given key
     * @param addr of the account
     * @param key associated with this value
     * @return data in the form of a <code>DataWord</code>
    DataWord getStorageValue(byte[] addr, DataWord key);

    byte[] getStorageBytes(byte[] addr, DataWord key);

The new methods are addStorageBytes and getStorageBytes. It was relatively easy to add, because the internal structure that represents the storage (a trie) is already prepared to store arbitrary data.

RSK implementation is using this features from precompiled contracts, and it is not available from EVM contracts.

In this post series, I want to describe new features that could be added to RSK storage, now it has byte array support.

Stay tuned!

Angel “Java” Lopez

June 25, 2017

Offchain Transactions In Ethereum/RSK (2)

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

Previous Post

Each contract in Ethereum/RSK has an associated storage. This storage has addresses and content. The addresses are 32-bytes values, and the content is 32-bytes values (notably, RSK has support for storing arbitrary byte arrays in an storage cell, topic for another post). Then, an onchain storage looks like:

(simplified addresses and contents). Each missing address has a default value (zero in Ethereum for numeric storage cells). When the contract is running OFFCHAIN, the storage state is kept in the designated running node, not shared with the rest of the network. The offchain storage state is only known by the running node, and it can be altered sending offchain transactions to the contract, and invoking offchain calls to the contract/running node.

An offchain contract have code (written by the contract programmer) that commits the contract. If the commit operation is invoked (an special new opcode in Ethereum Virtual Machine, to be mapped by a modified solidity compiler, or using the assembly keyword in a solidity program), then the contract emits an onchain transaction, the so called delta transaction. Is a transaction that when mined and added to the winning blockchain, alters the onchain storage to the current offline storage state:

Some details to decide: the cost of such transactions, who pays the cost (my first guess: the sender of the invoke that raise the commit in the contract method code).

The delta transaction start to have more sense if its size is shorter than the size of all the offchain transaction that were processed by the running node, when the contract was in offchain state. Maybe, it could be the case for token contracts, where the state is usually the token balance by account, independently of the number of token transfer that were executed.

Although these ideas could be difficult to implement in the existing Ethereum implementations, RSK is a new implementation still under development, and then, this proposal could be implemented without disrupt existing behavior.

Next post topics: the offline transfer of value, cost of offchain transactions.

Stay tuned!

Angel “Java” Lopez



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 18, 2017

Multi-Blockchains in Ethereum/RSK (1)

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

Next Post

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

December 23, 2007

My Week

Filed under: Uncategorized — ajlopez @ 11:21 pm

This is my week planned schedule:

Red hours: Revamping Fabriq, at Southworks.

Thursday, Friday, I’m going to give two courses (ASP.NET, PHP) at Club de Programadores.

This is a light week, Christmas week. But I’m going to think a lot, I must take some decisions about work in progress and future works.

Angel “Java” Lopez

December 3, 2007

My Week

Filed under: Uncategorized — ajlopez @ 10:47 am

These are my plans for this week:

Monday, Tuesday: I’m going to give a course on ASP.NET at Club de Programadores.

Tuesday: Philosophy with Laura Klein, more info at: Más cursos de filosofia

Friday morning: I’m going to give a speech about F#, at Microsoft Argentina.

Thursday night: Giving a course about .NET 2.x

Friday night: A speech about Spring Framework, for Java.

Week end: Go activities, Torneo Abierto Buenos Aires (more details at Asociación Argentina de Go).

Red hours: Revamping Fabriq, at Southworks.

Angel “Java” Lopez

Older Posts »

Blog at