Hello,
I'm a translation student and I'm an Ethereum enthusiast. I would like to translate this book to colaborate and also as my thesis translation project.
If you're interested, please send me the text or a link where I can read it and work from.

Thanks!

As someone new to Ethereum, I've been spending a lot of time searching for a tutorial that will allow me to store small amounts of arbitrary data in the blockchain, but every tutorial out there seems to think I want to keep track of money or apply logic to what's getting stored.

Often I find that the most effective tutorials are the ones that focus on one feature at a time, so I would suggest that you have one tutorial that does the simplest of things: put data in the blockchain, and then build on that step from there, allowing for increments and triggering other contracts etc.

I've been testing waffle for some days, which is a Project Management made for Developers, a tool for collaborative development of projects with full integration with Github.

As I know that time is one of the most precious assets in this project, I would suggest the use of this tool that I think would allow us to better organize as a team.

I think it would offer us a global vision of the status and evolution of the project.

It is only a personal suggestion that if it is considered, I hope It'll meet the expectations that I see.

Another aspect probably of interesting application could be the creation of private Ethereum networks and maintenance, p.e. mining considerations.

Although it could be out from the original philosophy of public application of the protocol, it can be very useful in certain circumstances more typical of the business environment.

It would be remarkable the case of https://monax.io

I could use some extra help with this issue.

In asciidoc, every chapter heading, section heading, figure, table, and code example, can be referenced from anywhere in the book. To do that, each of the above must have an anchor, which is a unique name inside double square brackets like [[anchor]]. See this example below:

[[transaction_chapter]]
== Transactions

[[transaction_example]]
.An example of a transaction in hex
----
453425235325345
----

[[metamask_transaction_example]]
.A screenshot of MetaMask doing a transaction
image::images/metamask_screenshot.png[A screenshot of Metamask]

It doesn't matter what the variable name inside the [[]] is, as long as it is unique. I prefer to use descriptive names with underscore between words, up to 2-4 words in length.

Elsewhere in the document you can refer back (or forwards) to a section, example, table or figure, by including the reference name inside angle brackets, like this:

As we saw in example <<transaction_example>>, a transaction is created 
and then Metamask shows you an approval screen (see <<metamask_transaction_example>>). 

When rendered by O'Reilly for print these are replaced by the heading, title, or caption. When rendered in an ebook or HTML they also become hyperlinks to the section.

Help me make it all work by doing the following:

• A pull request adding anchors to every section, heading, image, code example.
• If there are references that don't point anywhere like <<this_doesnt_exist_yet>>, then go and add a [[this_doesnt_exist_yet]] somewhere else in the text where it makes sense and points to something useful, like a section heading in another chapter.
• Create an issue if you find a reference that doesn't have a good place to point to and is left "dangling"

While the promise of blockchain technology is phenomenal, we need to approach this
technology with caution.

The ideal should be to make this technology as accessible as possible, fueling innovation and accelerating the move to a decentralized, open economy.

There is currently little standardization and no easy way to develop highly secure applications.

To address these problems and opportunities, ZeppelinOs propose a Blockchain Operating System for decentralized applications, a decentralized platform of tools and services on top of the EVM to securely build and manage smart contract applications, free of charge.

Links;

• White Paper: https://zeppelinos.org/zeppelin_os_whitepaper.pdf
• Github: https://github.com/zeppelinos
• Website: https://zeppelinos.org

Hello,

It seems the link to the website is broken. Is this expected?

Regards.

Ron

From the point of view of a Ethereum developer, I think it would be of great interest to know the existing technological alternatives, RootStock, Cardano and possibly many others.

I'd propose, through this issue, to create a conversation in which to be able to convey opinions, experiences and predictions.

I would highlight aspects, for me as relevant as, compatibility at the EVM level as well as technical, philosophical and economic differences and similarities.

I also believe that, through this conversation we could try to develop a joint vision of the current state of these technologies that could collaborate and compete with each other.

Although I'm not sure 100% of the possible match, let me list some of the ones that come to my mind right now;

• RootStock (RSK): https://www.rsk.co
• Qtum: https://qtum.org
• Cardano (ADA) https://www.cardanohub.org
• AEternity: https://www.aeternity.com
• Expanse: https://www.expanse.tech
• UBIQ: https://ubiqsmart.com
• EOS: https://eos.io
• POA: https://poa.network
• ELLAISM: https://ellaism.org
• TOMO: https://www.tomocoin.io

In my opinion it would be necessary to devote enough space in the book to deal with the issue of the Security of Smart Contracts.

In this sense there are already initiatives focused on this important aspect of the development of Smart Contracts such as maintained by ConsenSys Diligence, and the broader Ethereum community, thinking in the intermediate Solidity programmers.

Link(s);
Github: https://github.com/ConsenSys/smart-contract-best-practices/
Docs: https://consensys.github.io/smart-contract-best-practices/

I'd like to add some additional content on the Dapp section of the book, which could detail how a complete decentralized applications, consisted of Ethereum Smart Contract, IPFS/Swarm and Whisper could be built and deployed.

Creating a proof of existence tutorial Dapp using Embark is actually quite easy (since Whisper and IPFS is easily configurable) and is simple enough for people to understand the basic concepts. If you are interested, I could help out with this.

Hi,

I have no idea if you're planning on writing about Ethereum developer tools. If you are, I'd like to draw your attention to https://dapp.tools , a command line toolchain and smart contract standard library written in the style of the Unix design philosophy. However I think you probably shouldn't write about developer tools, as those trends can change very quickly (as we've seen in Javascript).

Looking forward to your book!

I think It is a matter of importance for the new developers of Ethereum to know the implications of the immutability of the blockchain in the development of their projects.

In this development platform, the publication of a Smart contract becomes an immutable action which differs from any other typical development cycle, where one always has the possibility to modify the previous behavior, in what is called a system of versioned.

I think Privacy on ethereum could be an important aspect to be cover by the book.

Thre are already several projects trying to implement privacy on ethereum, most notably Zcash-on-ethereum (ZoE), Hawk and the later Zcoin.

For those who can't spend many resources to maintain synchronized local nodes, I think the book could cover this part also.

There are alternatives to facilitate the use of the Ethereum network without the hassle of maintain synchronized local nodes.

I have personally tested;

• https://infura.io
• https://www.blockcypher.com/dev/ethereum
• https://metamask.io
• https://www.myetherwallet.com

It's possible to send a value in contract creation ('contract registration'). That value would then be immediately added to the balance of the newly created contract.

AFAIK, that is disabled by default in Solidity, so in order to receive ether, the fallback function must be marked payable. And make sure you have a way to retrieve the ether, otherwise (with the consensus rules as they are) it will just stay in there forever. http://solidity.readthedocs.io/en/v0.4.21/contracts.html?highlight=creation#fallback-function

See also page 9, paragraph 7 item (78) in the Yellowpaper https://ethereum.github.io/yellowpaper/paper.pdf

I think it would be of great interest to pay attention to the Metamask tool, for the utility it provides, also in the particular case of the Dapps's end users with which they can, identify themselves in Dapps and perform financial operations using this plugin integrated into the browser.

Website; https://metamask.io/

Please discuss the probably of automating the oracle process and maybe one or two possible solutions (e.g. Schelling Coin, Town Crier, etc.)

Perhaps it would not hurt to inform the new developers who will use Solidity about the existence of repositories of reusable / sharable packages.
I believe that this can enhance the open source concept applied to the development of solutions based on Solidity.

Github link; https://github.com/ethpm
Repository link; https://www.ethpm.com/registry
Website; https://www.ethpm.com/
Documentation; https://www.ethpm.com/docs/integration-guide

It's probably worth dedicating a major section on scalability. In particular,

• Why is scalability critical to Ethereum?
• Why is scalability difficult for Ethereum, probably more difficult than it is for Bitcoin?
• A description of the upcoming scalability solutions, namely, PoS, sharding, plasma, raiden, etc.

A challenge is to write something timeless. Since the R&D teams seem to move very fast with scalability solutions, it's potentially hard for the book to be up to date with the latest developments.

I would like to ask about this initiative.
I really don't know about it, I only know that exist.

They say that ethers.js is an alternative to web3 where ENS names are first-class citizens and It’s tiny (77kb compressed).

One major difference between ethers.js and web3 is how they handle key management and interaction with the ethereum blockchain. Web3 assumes that there is a local node connected to the application. That node is assumed to store keys, sign transactions, and interact with and read the ethereum blockchain. In reality, this is not often the case — most users are not running geth locally. Metamask effectively emulates that environment through a browser application, and so most web3 apps require Metamask to hold keys, sign transactions, and interact with the ethereum mainnet.

Ethers.js separates the “node” into two separate roles:

• A “wallet” that holds keys and signs transaction, and
• A “provider” that serves as an anonymous connection to the ethereum network, checking state and sending transactions.

This allows developers to manage these two roles discretely — perhaps using Infura as the provider, and a hardware device for the wallet.

Links;
Read the docs
Github

It worth mentioning OpenZeppelin which is an open framework of reusable and secure smart contracts in the Solidity language.

Github link; https://github.com/OpenZeppelin
Website link; https://openzeppelin.org/
Read the docs link; http://zeppelin-solidity.readthedocs.io/en/latest/index.html

Hello,
I wrote an article sometime ago, on how to calculate average salary of a group without immediately divulging the individual salaries. Perhaps, it can serve as a simple example to guide folks into decentralized application development. Especially because, it runs into a problem where zSNARKs may have to get involved.

If you are interested in using this example in the book, I will be enthused to improve the implementation.

LinkedIn post
Implementation

Keen to hear back!

https://trustwalletapp.com/
Trust wallet has support for browsing Dapps and signing transactions on any ethereum network including POA.network

100% open sourced project:
https://github.com/TrustWallet

https://github.com/ethereumbook/ethereumbook/blob/develop/clients.asciidoc#browsers-and-rpc-gateways

If there is an agreement, I can submit a PR

For me it would be important to mention in the book the inherent isolation of Ethereum from the outside world and the importance of defining mechanisms, commonly called Oracles, to achieve its interaction with it.

There is already some initiative trying to cover this limitation, such as "http://www.oraclize.it".
They define themselves as the "data carrier for decentralized apps".

Maybe there is something more about it out there.

I would like to propose this interesting framework to be mention and might be also documented in the future Ethereum book.

Truffle is a development environment, testing framework and asset pipeline for Ethereum, aiming to make life as an Ethereum developer easier.

https://github.com/ConsenSys/truffle

I would like to contribute if necessary.

I'm testing Embark and it's surprising me a lot.
I'm using it with Parity on Kovan and it run like a charm.
I think that the book could have a chapter for the most used frameworks and Embark is one of them.

Use this source: https://github.com/trailofbits/evm-opcodes
(with attribution)

Convert GitHub Markup to Asciidoc Markup and export as appendix section in its own asciidoc file.

• https://www.royalfork.org/2017/12/10/eth-graphical-address/
• https://ethereum.stackexchange.com/questions/3542/how-are-ethereum-addresses-generated/3619
• https://ethereum.stackexchange.com/questions/267/why-dont-ethereum-addresses-have-checksums
• https://github.com/ethereum/EIPs/blob/master/EIPS/eip-55.md

Question: Why recommend new Ethereum devs to run Mainnet nodes?

Advantages:

• Can interact with other live contracts
• Verify own transactions
• Deploy own contracts

Disadvantages:

• Longer setup time
• Hardware resource cost
• Costs ETH to deploy/test/interact with contracts

Arguably, I'd say a combination of a Ropsten local node and Testrpc would be simpler to set up a dev environment.

Advantages:

• Blockchain size/sync time: My current Ropsten blockchain is 8.02 GB, and increases by ~.1 GB per day. Fast synced up within a couple hours IIRC.
• No real money cost to deploy/test contracts
• Ropsten is still a 'live' blockchain
• Testrpc is a private chain running on your box, but facilitates automated testing
• Testrpc is already integrated with Truffle, the mainstream framework for development on Ethereum

Disadvantages:

• Can't deploy to Mainnet

For final deployment to Mainnet, there are still easy options like MEW or Metamask available.

I have the impression that we are facing a careful work of the Ethereum community. We could highlight 37 commits till today from Vitalik Buterin.

Vyper is an experimental programming language that aims, among others, the following goals;
Security, Language and compiler simplicity and Auditability.

About the Auditability aims: Vyper code should be maximally human-readable. Furthermore, it should be maximally difficult to write misleading code. Simplicity for the reader is more important than simplicity for the writer, and simplicity for readers with low prior experience with Vyper (and low prior experience with programming in general) is particularly important.

In my opinion, it could become the preference of pythonistas.

Links;
Github: https://github.com/ethereum/vyper
Read the docs: http://vyper.readthedocs.io/en/latest/?badge=latest

In order to offer to new programmers information grouped of currenty used Ethereum networks ids, I suggest the following list. Please add your corrections.

0: Olympic; Ethereum public pre-release testnet
1: Frontier; Homestead, Metropolis, the Ethereum public main network
1: Classic; The (un)forked public Ethereum Classic main network, chain ID 61
1: Expanse; An alternative Ethereum implementation, chain ID 2
2: Morden; The public Ethereum testnet, now Ethereum Classic testnet
3: Ropsten; The public cross-client Ethereum testnet
4: Rinkeby: The public Geth Ethereum testnet
42: Kovan; The public Parity Ethereum testnet
77: Sokol; The public POA testnet
99: POA; The public Proof of Authority Ethereum network
7762959: Musicoin; The music blockchain

On the intro.asciidoc, on the metamask section, the testnets are presented. But, the text explaining Kovan is the same as the one explaining Rinkeby:

Kovan Test Network:: Ethereum public test blockchain and network, using Proof-of-Authority consensus (federated signing). ETH on this network has no value.

Rinkeby Test Network:: Ethereum public test blockchain and network, using Proof-of-Authority consensus (federated signing). ETH on this network has no value.

This brings the question about why do we have two, instead of just one. So I think the text should be expanded a little, to include the difference between the two.

When a developer comes to Solidity, She or He should know the testnet networks that are out there, Ropsten, Kovan, Rinkeyby, their most important differences, known problems and risks, and important concepts as Proof of Authority, etc.

Let's give a path election to the newcomers.

@aantonop recently mentioned that it would be good to cover some topics on Ethereum Classic in the book. I have question, to what extent? Do you want to make just simple remark of the project? Or do you want to cover ETC specific topics and software, such as Classic Geth, SputnikVM and Emerald? There're also other changes, such as different monetary policy, difficulty bomb, and so on. There many things actually to cover. I'd like to help with this part if you would be interested

https://ethereumbook.info/ fails to load.

Through this issue I want to highlight the importance of the verification systems that are emerging around Smart contracts.

Smart contracts can carry financial value, and are increasingly used for safety-, security-, or missioncritical purposes. Errors in smart contracts have led and will lead to loss or harm.

Formal verification can provide the highest level of confidence about the correct behaviour of smart contracts.

As far as I have been able to see, there are already works that I would like to note through this issue.

How Formal Verification Can Ensure Flawless Smart Contracts

Towards Verifying Ethereum Smart Contract
Bytecode in Isabelle/HOL

Gitter channel - ethereum/formal-methods

A Lem formalization of EVM and some Isabelle/HOL proofs

Formal Verification of Ethereum Contracts (Yoichi's attempts)

As you may know, one the MEW co-founder forked this latter in order to make MyCrypto (https://mycrypto.com). I think the "Choosing an Ethereum wallet" part in the Introduction section should have, at least, a mention of this fork and explain briefly why this book keep MEW as a reference.

Whenever I explain smart contracts to my friends, I use the current voting system for example.

When you go to vote:
-You have trust yourself to vote for the right candidate ;)
-You have to trust that nobody sees your vote
-You have to trust that when you slip your number in the tin, that there isn't battery acid which would instantly dissolve it.
-You have to trust that somebody counts it right.

vs. SmartContract which is:
-transparent
-immutable
-you don't have to even count the votes

I think involving some kind of a practical example in the start would open up why smart contracts are so much needed. There's a ridiculous amount of trust we invest in our governments at the moment, and most don't even notice it, because we're so grown into it. The only problem I see in smart-voting is that it should be anonymous and at the same time untraceable, so that voters can't sell their votes.

You should write about how to treat Ether as an ERC20 token using the standard wrapper contract:

https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2

I believe the book would greatly benefit from a chapter of usecases that Ethereum only or at least can implement much better than other application platforms or bitcoin. We have great cloud application platforms and we have bitcoin, what does Ethereum as a programmable money platform add?

‘Usecase?’ for all non bitcoin blockchain technologies is a question with not so straightforward answers. Just saying it’s somehow decentralized isn’t enough. It would need to be clarified what that means for users and developers. Why is that better than what we already have ? Can we implement just some stuff as on aws, but here we have a community behind it instead og a cooperation?

If you check other projects like hyperledger the list of usecases is often supply chain but overall it is not clear why distributed databases couldn’t help, at times blockchains look like a solution in search of a problem.

For bitcoin the usecases are crystal clear, even in the white paper. For Ethereum as great as the idea seems, at least to me the usecases are not clear. Anything I see could be implemented in other platforms, the only exception (a big one though!) are ICOs, which should be a major section in such a chapter for usecases. This might very well be due to my ignorance around Ethereum but I am probably representative for many future readers then :-)

I am not saying these Ethereum specific usecases are not there even though I have difficulties to really Point them out - which is why I would love to see this list in a book:-)

Great technology itself is not enough, it’s about unique usecases or the capacity to implement existing applications in different advantageous ways.

this is quite empty repo with no book

Add some sections and discuss the upgradeability of smart contracts and some of the patterns created by OpenZeppelin and others to achieve these goals.

Useful reading:
https://medium.com/@mikecalvanese/flexible-upgradability-for-smart-contracts-9778d80d1638

If you want to sync in a reasonable amount of time and store all the development tools, libraries, clients and blockchains we discuss in this book, you will need a faster and better equipped computer:

Recommended:

* Fast CPU with 4+ cores
* 16GB+ RAM
* Fast SSD with at least 250GB free space
* 25+ MBit/sec download Internet service

Currently the size of the Ethereum blockchain is over 337GB (https://bitinfocharts.com/ethereum/). So I would suggest increasing the 250GB of free space to 500GB.

In this issue I'd like to highlight the interesting work of Fan Zhang, Philip Daian, Iddo Bentov and Ari Juels, in "Paralysis Proofs: Safe Access-Structure Updates for Cryptocurrencies and More".

I'd like specificaly point out to their "Paralysis Proofs in Ethereum", which is their Ethereum implementation of the solution as a good example of how a Turing complete system can help to relatively easily face a complex problem as the "Paralysis Problem".

Paper link: http://www.initc3.org/files/pp.pdf
Github link: https://github.com/pdaian/paralysis_proofs

It's referenced in preface.asciidoc

Hey Andreas, hope all is well since we met in Sydney, was great to see your talk!

ERC875 is a non fungible standard that includes an optional atomic swap function, even though it is in draft phase, it should be included in the book.

I believe this because it shows some of the future possibilities for atomic swaps and efficient non fungible transfers and has an implementation example in java which will be of interest to some readers (signature verification, expiry timestamp and release of funds in one transaction)

Let me know your thoughts and if you'd like to go through with it, I can make a draft.

ethereum/EIPs#875

Example implementation: https://github.com/alpha-wallet/ERC875-Example

Thank you,
Weiwu

Swarm is a native base layer service of the ethereum web3 stack intended as a Serverless Hosting incentivised peer-to-peer storage and content distribution, something that I think the average Ethereum programmer should know about.

The primary objective of Swarm is to provide a decentralized and redundant store for dapp code and data as well as block chain and state data. Swarm is also set out to provide various base layer services for web3, including node-to-node messaging, media streaming, decentralised database services and scalable state-channel infrastructure for decentralised service economies.

Link(s)
Swarm home page; http://swarm-gateways.net/bzz:/theswarm.eth/
Read the docs; https://swarm-guide.readthedocs.io/en/latest/index.html
Swarm developer's onboarding guide; https://github.com/ethersphere/swarm/wiki/swarm
The swarm engine room; https://gitter.im/ethersphere/orange-lounge
Similarities/differences between Ethereum's Swarm and IPFS; https://github.com/ethersphere/go-ethereum/wiki/IPFS-&-SWARM

In the section entitled "Sending ether from MetaMask" of the Introduction chapter user could be subject to a different gas price (2 in my case). A short clarification that gas prices might fluctuate, that it determines how fast your transaction will be mined, and therefore can be increased or decreased would help. As I see on the table of contents there is a whole chapter dedicated to GAS but want to steer users away from thinking perhaps something is wrong with their setup since they are in the initial portion of the book.