A Very Early Interview...

with the Brain Behind Ethereum's Code

This is an early (and detailed) interview I did with Dr. Gavin Wood, for Bitcoin Magazine, way back in early 2014.

Ethereum was still an ambitious White-paper, with no funding.

It makes for interesting reading, especially with has happened lately.

Has Ethereum strayed from the original vision? You decide.

(From April 2014).

Q1) Gavin, how do blockchains fit into your overall vision of Web 3.0? How important are they in this vision?

While the Internet provides us with a great way to communicate with individuals the world over, it is difficult to enter into an agreement with them; typically, we must trust either them directly (in the case of an e-commerce site, for example) or a third-party that vouches for them.

Both are susceptible to the sorts of abuse that blockchain-based technology can mitigate or remove entirely.

Q2) Explain other key technologies underpinning Web 3.0?

The other two key technologies we'll need to see for Web 3.0 to be realised pertain to the delivery of so-called "static" data and to the transmission of dynamic information.The first relates to the parts of a web site (or web application) that don't change.

This might be the information describing layout and styling together with any content that tends not to change often such as images and text.

The delivery mechanism for this would be a p2p system similar to BitTorrent or Freenet, but including additional measures to guarantee some level of anonymity and allow incentivisation of participation.

The second relates to the publication and discovery of information that tends to change often or is otherwise time-sensitive.

This might be information relating to the current status of an individual or some other component of the website. An example here would be the items on an e-commerce site.By splitting the two from each other, we are able to optimise the experience of users.

For example, it should be possible to interact with an e-commerce at full-speed even with a slow Internet connection; the speed of the Internet should affect only the dynamic information - that which is likely to change from minute-to-minute.

Static information, such as the general layout, text, images and logic should be "cached", or pre-downloaded and thus pages should "load" instantaneously, even if some of the information they contain is a little old.

Q3) Won’t there be governmental resistance to a web of pseudonyms, untraceable and encrypted connections? How much success can monolithic centres of power have in resisting this evolution?

Government resistance may be overplayed here. It is not clear that all elements of governments wish to remove all privacy from everybody. Indeed the judiciary routinely protect such rights and many executive branches refuse to condone dragnet surveillance.

Furthermore with sufficient resources, any organisation, governmental or otherwise, can and will compromise an individual's privacy if there is a perceived need.

The purpose of Web 3.0 is not to absolutely remove the ability of a government to do its job in this regard - there are instances when a government may legitimately require the ability to infringe a citizen's privacy.

However, the resources required for infringement should be proportional to the number of individuals whose privacy is infringed.

The breakdown of this relation is one of the key reasons we find ourselves in the current situation; security services were able to avoid being accountable since, due to the technological ease of dragnet surveillance, the cost to infringe an additional individual's privacy is negligible.

One of the two purposes of Web 3.0 is to restore this economic balance and through re-engineering the Internet to make the cost of infringement of each individual's privacy economically substantial.

The other purpose is to reduce the necessity of sharing information with third parties by bolstering the infrastructure for peer-to-peer communications.

Q4) So, will there be any role for centralised, trusted parties at all in web 3.0? If so, where, what will they do and what will they look like?

Yes; there will be many such entities, just as there is in the Real World. Many aspects of useful applications require oracles, or third parties that provide information that cannot otherwise be known or agreed upon.

This might include up-to-date pricing information of commodities, weather information and so forth. Such authorities may also provide us with information pertaining to entities or individuals within the system that we could discover manually, but that is prohibitive in terms of time and/or expertise.

In general, it is impractical to eliminate the need for trust, per se, from the world. The best we can do at this point is to reduce it, spread it, isolate it and be absolutely certain about who it is that we must trust, why, and about what we trust them.

Q5) How do you envisage Ethereum’s role in web 3.0?

The Ethereum protocol will provide the basis for trustless interaction, and thus will form one of the three pillars of communication.

We hope to support, or perhaps even lead, the development of the other two pillars with the ultimate aim of providing the first Web 3.0-capable browser.

Q6) How do contracts in Ethereum deal with enforcement issues in the “real” (physical) world?

The enforcement of the external ramifications of Ethereum contracts is an interesting topic and still an area of research.

We envisage that such enforcement will happen in one of three schemes: either through the payment to an "enforcement" individual or organisation, through integration into an existing legal system or through physical objects being connected directly to Ethereum.

The first makes sense in situations in which bailiffs or debt-collectors would already be used.

A contract could, e.g., automatically pay such an individual to lead proceedings to remove a no-longer-paying tenant from a household.

The second is a longer-term possibility and we may yet find jurisdictions that would be willing to enforce a blockchain-based contract's ramifications. Certain Central-America-based governments are already considering such proposals.

The third is likely the best short-term solution. Smart property, or physical objects made to respond directly to Ethereum provide a great way for contracts to control real-world objects. An example would be an Internet and Ethereum-enabled door-lock with a barcode reader. A contract could accept payment in order to allow the individual's private key (provided through a barcode) to unlock it.

Q7) What are the specific development challenges being faced at the moment in Ethereum?

Organisation of scarce and disparate developers, of course, makes the job more difficult than it needs to be. With tools such as Git (Hub), our lives are made somewhat easier.

I anticipate the job of development will become easier still following the Ether swap when we have the resources to hire and co-locate developers and purchase infrastructure equipment to make, e.g. network debugging, more straightforward. In actual fact, the greatest issue to date has been the building the project over multiple platforms.

Windows, in particular, provides an unnecessarily laborious environment for developers of cross-platform software stacks.

Q8) What areas of development are proceeding better than expected in Ethereum?

The development of the client's interface has been streamlined somewhat by the use of the Qt programming toolkit. By leveraging its Webkit (HTML browser) and "QtQuick" features for quickly building interfaces we have been able to deliver certain functionality far faster than we would otherwise expect. The debugging mechanisms have also proceeded far faster than expected.

Q9) What are some key changes that form the latest iteration of the Ethereum project?

The latest iteration, codenamed PoC-5 and still in development, provides a number of changes to the protocol, making it cleaner and more robust. It adds a contract debugger allowing contract developers to analyse the execution of their contracts, seeing where and why they go wrong.

The most visible change, however, is the addition of an HTML/Javascript based engine and Ethereum bindings. This forms the basis of the technology of the final Ethereum client, allowing ÐApp developers to tie together contracts with HTML/Javascript based front-ends.