Angel \”Java\” Lopez on Blog

July 20, 2017

Blockchain: Links And Resources (47)

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

Previous Post

Underhanded Solidity Coding Contest
http://u.solidity.cc/

Solidity CRUD- Part 1
https://medium.com/@robhitchens/solidity-crud-part-1-824ffa69509a

Más usos para la tecnología de las monedas virtuales
https://www.clarin.com/ieco/usos-tecnologia-monedas-virtuales_0_B11ezoUSW.html

What is Bitcoin Mining?
https://www.bitcoinmining.com/

Announcing “Around the Block”: a Documentary Series about the Minds Behind the Blockchains
https://medium.com/paratii/announcing-around-the-block-a-documentary-series-about-the-minds-behind-the-blockchains-b5f5bfeec12e

Potential network disruption
https://bitcoin.org/en/alert/2017-07-12-potential-split

Formal Verification of Ethereum Smart Contracts
http://securify.ch/

Functional Alternative to Ethereum (in Haskell)
https://github.com/CharlesHoskinson/ConsenSys–Fae

Don’t Get CoinDashed — How to Secure Your Token Sale
https://blog.enigma.co/dont-get-coindashed-how-to-secure-your-token-sale-a5e247944234

A Brief History of Blockchain: An Investor’s Perspective
https://medium.com/indian-thoughts/a-brief-history-of-blockchain-an-investors-perspective-387c440ad11c

Stay tuned!

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

 

July 19, 2017

Blockchain: Links And Resources (46)

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

Previous Post
Next Post

Securify Formal Verification of Ethereum Smart Contracts
https://twitter.com/SecurifySwiss

Formal Verification of Ethereum Smart Contracts
http://securify.ch/

Arthur Gervais
https://twitter.com/HatforceSec

Ben Davenport, CTO at BitGo
https://twitter.com/bendavenport

BitGo Making digital currencies usable for business
https://twitter.com/BitGo

Suhas Daftuar Chaincode Labs
https://twitter.com/suhasdaftuar

Ethereum contract for Bitcoin SPV
https://github.com/ethereum/btcrelay

Solidity BTC Parser
https://github.com/rainbreak/solidity-btc-parser/blob/master/src/btc_tx.sol

Solidity Test
https://github.com/dapphub/ds-test

Browser-Only Solidity IDE and Runtime Environment
https://github.com/ethereum/browser-solidity

The ethereum VM implemented in JavaScript
https://github.com/ethereumjs/ethereumjs-vm

Stay tuned!

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

July 16, 2017

Learning Ethereum/RSK (2)

Filed under: Bitcoin, Blockchain, Ethereum, RSK — ajlopez @ 3:30 pm

Previous Post

Before understanding in deep Ethereum and RSK projects, we must study Bitcoin, its ideas and ecosystem. Another book about Bitcoin is:

Learning Bitcoin

by Richard Caetano (blog) CEO and co-founder of Stratumn. Bitcoin and Blockchain adopter since 2011.

I read:

In this book, we will introduce Bitcoin with a hands-on approach. We will begin with a simple and easy-to-follow introduction, which includes buying and selling bitcoin. Throughout the middle, we will look into the internal workings of Bitcoin to understand how its various pieces work. Towards the end, we will explore various ways in which Bitcoin can be used as “programmable money”.

So, it’s not a book only dedicated to developers, it includes some interesting topics, like accessing Bitcoin from JavaScript tools, and a detailed description of mining process.

The author discuss:

  • Setting  up a wallet
  • Buying and selling Bitcoins
  • Protecting your Bitcoins
  • Understanding the Blockchain (a topic more related with our objetives, understand Ethereum and RSK) Transactions, blocks, keys, genesis block. He also describes attacks like the 51 percent, race, and Finney attacks.
  • Installing a Bitcoin Node
  • Understanding the Mining Process (another topic to take into account in our exploration) Proof of work, mining rewards, mining pools, setting up a mining client, connecting to a mining pool.
  • Programming Bitcoin (in Ethereum we have a new and more powerful way to add logic to our transactions, the smart contracts) using BitcoinJS, sending transactions, writing an escrow contract
  • Alternative Coins

I like the mining descriptions, the attacks presentation and programming Bitcoin from JavaScript.

More resources in the next posts.

Stay tuned!

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

 

July 15, 2017

Blockchain: Links And Resources (45)

Filed under: Bitcoin, Blockchain, Ethereum, FinTech — ajlopez @ 5:13 pm

Previous Post 
Next Post

Mr. Blockchain Goes to Washington
http://www.coindesk.com/mr-blockchain-goes-washington/

The $3.8bn cryptocurrency bubble is a huge deal. But it could break the blockchain
http://www.wired.co.uk/article/what-is-initial-coin-offering-ico-token-sale

Behind the scenes with Tezos, a new blockchain upstart
https://techcrunch.com/2017/07/12/behind-the-scenes-with-tezos-a-new-blockchain-upstart/

What is Blockchain Technology? A Step-by-Step Guide For Beginners
https://blockgeeks.com/guides/what-is-blockchain-technology/

What happened to ethereum?
https://www.quora.com/What-happened-to-ethereum

What is the next Ethereum?
https://www.quora.com/What-is-the-next-Ethereum

Will Ethereum crash?
https://www.quora.com/Will-Ethereum-crash

Exploring Continuous Token Models: Towards a Million Networks of Value.
https://media.consensys.net/exploring-continuous-token-models-towards-a-million-networks-of-value-fff153175776

Accenture, Microsoft team up on blockchain-based digital ID network
http://www.reuters.com/article/us-microsoft-accenture-digitalid-idUSKBN19A22B

How cryptocurrency ethereum looks set to overtake bitcoin — in one chart
http://www.marketwatch.com/story/how-cryptocurrency-ethereum-looks-set-to-overtake-bitcoin-in-one-chart-2017-06-14

Visualizing Where Major US Banks Have Invested in Fintech
https://www.cbinsights.com/blog/fintech-investments-top-us-banks/

My Links
https://del.icio.us/ajlopez/blockchain

Stay tuned!

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

July 11, 2017

New Month’s Resolutions: July 2017

We are in the second part of the year, a long year with interesting projects. Time to write the new month’s resolutions and review the past ones:

– Continue RskSharp [pending]
– Continue SimpleBlockchain [pending]
– Continue BlockchainSharp [complete] see repo
– Continue ChineseP [complete] see repo
– Continue TensorSharp [pending]
– Continue RSharp [complete] see repo
– Experiments with RSKJ fork [complete] see repo
– Continue Vyu [pending]
– Continue Domie [complete] see repo
– Continue Wordie [pending]

Also, I was working on:

– Start WikiExpert [complete] see repo
– Start PerProm [complete] see repo
– Start RskApi [complete] see repo
– Improve SharpGo [complete] see repo
– Improve Neurum [complete] see repo
– Improve ClojJS [complete] see repo
– Improve SimpleScraper [complete] see repo
– New Sample in SimpleGA [complete] see repo
– Start GenPrj [complete] see repo
– Start RskUtils [complete] see repo
– Start SimpleJsonRpc [complete] see repo
– Start HuskyJS [complete] see repo
– Improve Husky [complete] see repo

My new month’s resolutions:

– Continue RskSharp
– Continue SimpleBlockchain
– Continue BlockchainSharp
– Continue ChineseP
– Continue TensorSharp
– Continue RSharp
– Continue WikiExpert
– Continue SimpleGA
– Continue Neurum
– Continue HuskyJS

Stay tuned!

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

 

 

 

 

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
http://www.ajlopez.com
http://twitter.com/ajlopez

 

July 5, 2017

New Storage in Ethereum/RSK (1)

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

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
http://www.ajlopez.com
http://twitter.com/ajlopez

 

July 2, 2017

Multi-Blockchains In Ethereum/RSK (2)

Filed under: Blockchain, Ethereum, RSK — ajlopez @ 7:26 pm

Previous Post

In order to support many blockchains in an Ethereum/RSK network, I propose two have “bi-colored” blocks:

A normal transaction have a sender account, a receiver account, an amount, contract data, and final state root. Now, a transaction could participate IN TWO “colored” blockchains: each account has an associated blockchain, and you can transfer from one account/blockchain to another account/blockchain.

To keep consensus, a “bi-colored” transaction has TWO final state roots: one for each blockchain.

A “bi-colored” block has TWO parents, one for each blockchain:

Not every node in the network knows ALL the blockchain states. But a node having the state of the “blue” blockchain can execute each transaction with a “blue” part, and check the final state root after applying the partial transaction to its own partial “blue” world state of the network. That is the interesting part: not all the nodes have to keep the FULL state of the network. It is enough to have many nodes, each controlling one or two colors.

Only the miner node that generated the “bi-colored” block should know the TWO world states, to generate the appropiate world state roots.

An account has a balance in EACH blockchain. But when a user creates an account, its address and use is available in any of the participant networks. So, it is a user decision what amount of balance their accounts have.

There is a difference with contracts: a contract is created in only one blockchain, and its storage is kept in that blockchain.

More details in the next post

Stay tuned!

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

 

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
http://www.ajlopez.com
http://twitter.com/ajlopez

 

 

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
http://www.ajlopez.com

 

Older Posts »

Blog at WordPress.com.