December 1, 2016

One interesting issue to solve, in my blockchains implementations (C#, JavaScript/NodeJS), is the node intercommunication. The nodes should interchange data, like new blocks, new transactions, status messages…. And, for a running node, it should discover other nodes in the network to be its peers. The process is named: peer discovery.

I want to start to write down some ideas:

– Each node has a node id, and a network id, so other nodes can check that info to accept the node as its peer or not

– A node could have configured a hardcoded list of initial nodes, to use as peers

– But it could have another list: a list of special nodes that knows other nodes in the network. This nodes are not peers of the first node. They are helpers, node registries, that knows other peers in the network, that can be used as peer by a new node in the network. Usually, this lists is not a list of IPs, but of machines by name, in a DNS controlled by the blockchain network infrastructure.

When a new node starts to run, it communicate its existence to this list of peer registry nodes, and actively query them for initial peers.

Each node has a number of maximum peers to use and connect. When one of these connections drops, or it is not suitable for be a peer node, the node tries other known peers, or ask new peers to the registry servers.

One way to ensure a good distribution of connection, is identify the known nodes in zones (maybe, node id modulus a low number). When a node of zone 2 needs peers, the registry servers sends to it peers of zones 1 and 3. In this way, the node start to be connected with more and more peers. But avoiding to know ALL the peers in the network: only some peers of its adjacent zones. This is for security reasons: if the FULL list of peers is not general available, it’s better to avoid global network attacks.

As usual, I should design all these with TDD, guided by simplicity and initial use cases.

November 28, 2016

In my post serie about connecting blockchains, I’m writing about exchange (value one to one, without change of value) between two popular heterogeneous blockchains (BitCoint and Ethereum/RKS). I’m a member of the development team of @RSKSmart, but those posts are personal opinions: the real work by the team was not published yet.

Another path to explore, is to have, in the SAME blockchain, many cryptocurrencies. My thought is that it could be done in Ethereum/RSK.

In Ethereum, there are accounts with state, and the account state includes the cryptocurrency balance for the account. There is a “default” currency, the Ether. But I think this model could be easily extended.

Each account has a currency, too. The “default” cryptocurrency should be the Ether, but some accounts could be created with ANOTHER cryptocurrency as default currencty. Then, they form a separated set of accounts. One account with currency X, can transfer and can borrow value from another account with THE SAME CURRENCY X. In this way, the new set of account could leverage all the infrastructure of Ethereum, to have a pool of accounts that manage a “coloured” currency value, separated from the default/main one.

In the next post, I want to write about:

– How to define a new currency – How to create an account with a new currency – How to transfer between accounts with the same currency – How to transfer between accounts with different currencies

November 26, 2016

BitCoin is the best known blockchain. Ethereum is the “new kid on the block”, and it has its similarities and its difference with BitCoin. At first, Ethereum has running nodes, transactions, blocks, and a blockchain build by consensus:

The consensus is based on proof of work for each block added to the blockchain, like in BitCoin. But the internal structure of transactions, the state of world by block, are quite different. For example, there are accounts WITH STATUS, instead of unspent outputs as in BitCoin.

But the main, key difference, is that each account could be an smart contract. Each node has a Ethereum Virtual Machine that can run compiled smart contracts. A method in a smart contract could be invoked in each transaction. This new capability opens lot of new use cases.

Having smart contracts in Ethererum/RSK, is one of the motivation to connect both blockchain: BitCoin is limited, running scripts, and the smart contract world is new brave world to be explored.

November 16, 2016

The use case I have in mind is to connect to heterogeneous blockchains: BitCoin, and Ethereum/RSK:

The main problem is that both blockchains are too different. The resolution of both use case (transfer from BitCoin to Ethereum/RSK) will be very different to the resolution of the second use case (transfer from Ethereum/RSK to BitCoin).

And the key difference is that Ethereum/RSK has smart contracts (even native precompiled contracts, if needed). The second difference is the format of transactions: BitCoin uses Unspent Outputs, meanwhile Ethereum relies on keeping account balances.

But it is an interesting and non-trivial use case, to discuss in detail in the next posts.

November 14, 2016

Having a blockchain with smart contracts, like in Ethereum/RSK, opens a can of possibilities, new use cases, and new ways to give value to business. I’m not sure it is needed, but one possibility to explore is to have a simple relational database associated with an account, using the account storage.

An account can have code (maybe precompiled), balance, nonce, and storage. Storage is composed by storage cell, each having an address (32 bytes), and a content (a big integer represented in 32 bytes). The account storage has a hash value associated: if its content change, the hash changes.

At @RSKSmart, we are experimenting having storage cells with arbitrary binary data (byte arrays of any length). The hash calculation is the same, and the cell persistence does not change: internally, it uses a key-value store, where key is a byte array, and value is a byte array.

Internally, each table could have an ID (short number), and each row has an ID (20 bytes address, maybe). The description of the database (one database per account) resides in system tables. The storage cell for a row should be located at TableID + RowID, in the account storage.

In this way, each state of world hash has an snapshot of the account databases, as now they have the account states.

But I insist: maybe there are few use cases where such arrangement add values. Usually, the value comes from contract logic, and more directly exposed state, in contract variables.

I hope to write some demo code.

Another approach is to use the contract as a lightweight wrapper around an industrial-strength distributed database. But it is not clear how to keep the snapshots by world state (and if those snapshots are needed or not).