Angel \”Java\” Lopez on Blog

March 7, 2017

New Month’s Resolutions: March 2017

Filed under: C Sharp, Erlang, Go, Haskell, JavaScript, NodeJs, Open Source Projects, Solidity — ajlopez @ 11:30 am

A new month begins, and it’s time to write down my new resolutions. First, a review of the February resolutions:

– Improve SharpGo [complete] see repo
– Improve BlockchainSharp [pending]
– Improve SimpleBlockchain [complete]
– Continue Solidity Compiler [complete] see repo
– Continue ChineseP [pending]
– Improve ErlSharp [complete] see repo

Additionally, I worked on:

– Start RskSharp [complete] see repo
– Start TensorSharp [complete] see repo
– Improve AjDrawJs [complete] see repo
– Improve SimpleForth [complete] see repo
– Improve CrysSharp [complete] see repo
– New Bitcoin example in SimpleGA [complete] see repo
– Improve Husky, my Haskell interpreter [complete] see repo
– Improve SimpleLisp [complete] see repo
– Improve CrysJS [complete] see repo

My new resolutions:

– Continue RskSharp
– Continue SimpleBlockchain
– Continue Solidity Compiler
– Continue ChineseP
– Continue TensorSharp

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

February 5, 2017

New Month’s Resolutions: February 2017

Filed under: Blockchain, C Sharp, JavaScript, NodeJs, Open Source Projects, Solidity — ajlopez @ 11:42 am

The second month of the year just started, time to write my monthly resolutions, but first, let’s review the past ones:

– Improve CrysSharp [pending]
– Improve SharpGo [complete] see repo 
– Improve BlockchainSharp [complete] see repo
– Improve SimpleBlockchain [pending]
– Continue Solidity Compiler [complete] see repo
– Continue ChineseP [pending]
– Continue PegSharp [pending]

Also, I did a minor improvement on ErlSharp see repo.

My new resolutions:

– Improve SharpGo 
– Improve BlockchainSharp
– Improve SimpleBlockchain
– Continue Solidity Compiler
– Continue ChineseP
– Improve ErlSharp

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

January 10, 2017

New Month’s Resolutions: January 2017

Filed under: C Sharp, Go, JavaScript, NodeJs, Open Source Projects, Solidity — ajlopez @ 11:20 am

A new year started, it’s time to write my resolutions, but first, a review of the previous ones:

– Improve CrysSharp [pending
– Improve SharpGo  [complete] see repo
– Improve BlockchainSharp [pending]
– Improve SimpleBlockchain [pending]
– Continue Solidity Compiler [complete] see repo
– Continue ChineseP [pending]
– Continue PegSharp [pending]

I had personal issues (Spanish), but now I in a better position to pursue new resolutions.

My January resolutions are:

– Improve CrysSharp
– Improve SharpGo 
– Improve BlockchainSharp
– Improve SimpleBlockchain
– Continue Solidity Compiler
– Continue ChineseP
– Continue PegSharp

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

December 8, 2016

New Month’s Resolutions: December 2016

Filed under: Blockchain, Crystal, Go, JavaScript, NodeJs, Open Source Projects, Solidity — ajlopez @ 10:23 am

The last month of the year. Time to review past month’s resolutions:

– Improve CrysSharp [pending]
– Improve SharpGo [complete] see repo
– Improve BlockchainSharp [pending]
– Improve SimpleBlockchain [pending]
– Continue Solidity Compiler [complete] see repo
– Continue ChineseP [pending]
– Continue PegSharp [complete] see repo

My new month’s resolutions

– Improve CrysSharp
– Improve GoSharp 
– Improve BlockchainSharp
– Improve SimpleBlockchain
– Continue Solidity Compiler
– Continue ChineseP
– Continue PegSharp

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

December 1, 2016

Building A Blockchain (15)

Filed under: Bitcoin, C Sharp, Ethereum, FinTech, JavaScript, NodeJs, Open Source Projects — ajlopez @ 10:28 am

Previous Post

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.

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

November 28, 2016

MultiCurrency in Ethererum/RSK (1)

Filed under: Bitcoin, Blockchain, Ethereum, FinTech, Open Source Projects, RSK — ajlopez @ 9:26 am

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

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

November 26, 2016

Connecting Blockchains (6)

Filed under: Bitcoin, Blockchain, Ethereum, FinTech, Open Source Projects, RSK — ajlopez @ 7:07 pm

Previous Post

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.

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

November 16, 2016

Connecting Blockchains (5)

Filed under: Bitcoin, Blockchain, Ethereum, FinTech, Open Source Projects — ajlopez @ 5:21 pm

Previous Post
Next Post

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.

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

November 14, 2016

A Database in the Blockchain (1)

Filed under: Blockchain, Ethereum, FinTech, Open Source Projects, RSK — ajlopez @ 9:53 am

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.

Then, I could implement a precompiled contract, with:

– Method execute(sql) to execute a simple SQL statement (create table, insert, ….)
– Method query(sql) to retrieve an array of rows

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

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

November 12, 2016

Connecting Blockchains (4)

Filed under: Bitcoin, Blockchain, Ethereum, FinTech, Open Source Projects, RSK — ajlopez @ 7:16 pm

Previous Post
Next Post

Let’s add a new use case. To really expand the connection of two blockchains, we can add a “reverse” use case: transfering value from the second blockchain to the first one:

The external mechanism is the same: a transaction to the special account in the second blockchain, should be reflected in a similar transaction in the first blockchain. In this way, the owner of the value, after using it in the second blockchain, can decide to return it to the first circuit.

Given that this second use case resembles the first one, we could expect a similar implementation. It could be the case if both blockchain had the same capabilities. But usually, they are too different.

In the next post, we will start to discuss a CONCRETE pair of blockchain: Bitcoin vs Ethereum/RSK

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Older Posts »

Blog at WordPress.com.