What is Ethereum? Project, Platform, Fuel, Stack.

What is Ethereum, the Project?

The Ethereum Project is an open source, community-driven effort designed to create a next-generation distributed application platform intended to be maximally flexible and powerful in the possibilities that it enables.

What is Ethereum, the Platform?

The Ethereum Platform combines a generalized peer-to-peer networking platform with next-generation blockchain architecture to deliver a decentralized consensus-based (decentcon), full-stack platform for developing, offering and using distributed application services.  A consumer-facing application, called the EtherBrowser, integrates the front and back ends to create an environment in which anyone can easily and rapidly build highly secure, scalable and interoperable decentralized applications.

Like the BitTorrent content sharing system, Ethereum network nodes will run on thousands of computers around the world and, short of shutting down the Internet, its operations cannot be halted.  This is because peer-to-peer systems generally involve a very large number of independent actors (people or organizations) each running the peer node software on one or more computers.  In the Bitcoin system, these nodes are called “miners.”

Like Bitcoin, in Ethereum, the nodes on the network serve as miners whose purpose is to process and validate the transactions and computations on the system and quickly achieve a consensus regarding what happened on the system and when.  This consensus is what provides the network with its security.  The larger the number of nodes there are and the more work these nodes have to do to exercise a vote regarding what transpired on the network, the greater is the sense that this shared consensus view of the history of the system is a canonical and irrepudiable representation.  In Ethereum, miners receive a reward for doing the work required to inform and enable their vote and they are also paid for providing resources to the network in the form of bandwidth, storage and computational processing.

Bitcoin is a system for securely transmitting and storing value.  As such, it can serve as the financial bedrock of the emerging global decentcon economy.  A conservative, prudent, development roadmap for Bitcoin will make it easier to use and further secure the protocol against quirks and edge cases that might be exploited in the future (though it has thus far proven to be remarkably solid at the protocol level).  In contrast, as a platform for hosting distributed or decentralized applications (ÐApps — spelled with the capital letter “eth” and pronounced “dapps” or “eth-apps” by the cognoscenti 🙂 ) and services, Ethereum must be agile and forward moving.  In Q4 of 2014, the Ethereum team will deliver a feature-rich system that will be fully functional and will possess a rich user interface and deliver a compelling user experience for both end users and businesses building ÐApps and offering services on the platform.  But technology moves fast, so Ethereum will require an upgrade roadmap and continual development.

What is Ether, the Cryptofuel?

Just as the Bitcoin system has a token, called a bitcoin (lower case) that serves as the medium of exchange, Ethereum has ether (ETH) which serves as a unit of exchange to some degree, but more importantly, it serves as a fuel that powers applications on the Ethereum system.

The engineers of the Ethereum Project are building a computational device or appliance, in the form of a software program, that anyone can download and run on their computer, smart phone, or on dedicated, fast hardware.  In order to operate this software appliance a certain type of token is required as fuel in appropriate quantities.

Distributed applications on Ethereum require payments of this token to fuel every computational and storage operation on the system. Without requiring payments for operations, the system would be vulnerable to many sorts of attacks and would not be viable or secure. The payments are made to owners of computational resources in exchange for securing the Ethereum network, for transmitting transactions, for storing data and for processing computations required by distributed software applications.

People and businesses are interested in purchasing ETH to power their own business applications, to make use of business applications offered by other service providers, to trade on forthcoming exchanges, or to speculatively hold for future sale to people and businesses.  ETH may be purchased in the Genesis Sale (details forthcoming, please watch this space), on forthcoming 3rd-party exchanges and ATMs, and on exchanges that are implemented as DApps on Ethereum.

When purchasing ETH in the Genesis Sale, the buyer is supporting the development of the product, just as with a kickstarter campaign. When the product is completed and ready for delivery, buyers will be able to claim their purchased ETH from the genesis block — the root block of the Ethereum blockchain.

What is Ethereum, the Software Stack?

A software stack is a set of technologies, realized at different layers and levels of abstraction and possessing different complementary capabilities that work well together to enable a software development team to build a full, back-end to front-end software service for an end user.  Ethereum provides a full-stack solution for developing and delivering ÐApps, the front end of which may be accessed by an end user from a web page, dedicated front-end applications, or more commonly from the Ethereum ÐApp Browser.  The Ethereum stack is the first of its kind to enable developers to deliver decentcon software applications.

When delivering an ÐApp the developer or deployer of that ÐApp does not arrange hosting of back-end server processes as with traditional software services.  Rather, the code is embedded as payload in a transaction on the Ethereum network and sent to one or more mining nodes on the network.  Miners that receive the transaction will broadcast it to all of the peers that they are aware of, provided the transaction sender has included enough ETH, the cryptofuel that powers operations on the system, to pay for the transaction.  This transaction diffuses through the network, peer to peer, and eventually is packaged into a block and locked into the blockchain.  Blocks are created by miners approximately once per minute.  Once the transaction with the code payload is embedded into a block, subsequent transactions can be sent to an address that is designated as the controller interface for that ÐApp to invoke processing of the ÐApp.

When an end user wishes to activate one or more services offered by this ÐApp, she will typically interact with a front-end user interface, loaded into the ÐApp Browser (probably Qt-based or JavaScript/HTML5/CSS3) to trigger desired actions.  User interface components will be cached on some kind of decentralized BitTorrent-like cloud and pulled in by the ÐApp Browser as needed. The user interface will formulate Ethereum transactions and send these, with a suitable amount of the cryptofuel and any input data required, to the address of the controller interface of the ÐApp.  Once collected into a block, the transaction will trigger execution of the ÐApp and the states of various components (called contracts) of the ÐApp will transition to a result state.  A peer-to-peer fast messaging protocol, will enable the user interface to reflect such changes, and will facilitate communication among different DApps and among users.

One thing to notice is that, from the perspective of application hosting, there is virtually nothing to be done.  The back end is launched into the blockchain “cloud” and the front end will usually be represented as a installable tile in the Ethereum ÐApp Browser.  The end user will download the browser once and the browser will receive continual updates from BitTorrent or a BitTorrent-like distribution system.  While browsing the distributed ÐApp catalog in the browser, the end user can install any ÐApp of interest in her browser with a no cost, one-click installation.  These tiles will be organized categorically by users and each will be invokable into in a full blown, user interface “responsively” sized and configured to the dimensions and capabilities of the browser (some weaker devices may have limitations).

The programming paradigm just described will be very unusual in comparison to typical development technologies and will require innovative (and perhaps sometimes kludgey) approaches.  If a programmer can only expect the state of the business logic to update once per minute, stochastically, techniques will have to be developed for certain kinds of applications to perhaps cache certain expected state changes and wait on back end processing before updating the front end.  Even more complicated is the fact that a block housing transactions and associated ÐApp state changes can be constructed and included in the blockchain but then find itself not part of the main consensus blockchain soon after and possibly have the associated transactions remain unconfirmed and unprocessed for a period of time.  Worse, an intervening transaction might be processed first, thus rendering the first transaction invalid.  An entire new field of blockchain-based software development techniques is required.  Many developers will forge novel solutions.  And some fundamentally new approaches may be required.  And for this, we are developing the Crypto Currency Research Group (CCRG) to conduct general research of benefit to the entire niche.  Please watch this space for more on the CCRG.

 


3 comments

  1. Thanks for this guide – I feel I am starting to understand it all a little better!

    “Distributed applications on Ethereum require payments of this token to fuel every computational and storage operation on the system. ”

    Sorry if this is a very obvious question – but while I can understand why you might want to charge ‘rent’ (?) to people using the network’s resources, I wonder about situations where an application brings with it a decent number of people who can validate transactions – ie the application is itself also processing and validating – in the way, for e.g. every user of the Spotify is running a kind of p2p/torrent client in the background. Would such an ap still need to be within the ETH economy with a cost per use? Or could it use the Ether architecture and build the system independently? Would it then run its own blockchain? Are there limits on that, or indeed is there a middle-ground between these two approaches?

    • “Blockchain Rent” is currently in the conceptual phase – no decision has been made. And to be crystal clear, should it ever exist, that ‘rent’ would go to the miners and the miners only.

      What’s the purpose of something like that you ask? Well, contracts that no longer have a use (say for example, immutable test contracts that have bugs, or immutable contracts that can no longer fulfill their purpose efficiently) can be ‘killed’ by their creator if they were to have included the ‘SUICIDE’ opscode. That’s a lot of if, and odds are we’ll see plenty of ‘zombie’ contracts pollute the chain (we’re seeing this on the testnet today). In order to automate this ‘garbage collection’ so to speak, the idea of rent was floated.

      You actually answered your own question, because the solution for the type of problem you described is indeed into node incentivization, including external nodes on different protocols such as bittorrent. Indirectly this would help solve the problem of data redundancy common to all long tail items that are distributed through DHT-type mechanisms.

      • Yeah that makes sense – especially in terms of trying to find a penalty for garbage output, or grey goo or whatever it’s called. I’m guessing it’s part of the challenge of being Turing complete – someone writes a script that makes a load of new contracts everytime the weather changes in any postcode and forgets about it – and it’s now costing every transaction validation a bunch of cpu cycles (and energy) and adding nothing to the network but noise and latency.

        At the same time it puts me off – if there’s a cost of both adoption and scaling in terms of a rent then I’m pushed back to trying to see if I can just squeeze more out of Bitcoin (or NXT or something else). Obviously there’s got to be reciprocity, give and take – if I want my contracts processed then my servers need to be in the loop, validating others as well.. it’s the commons. But once rent’s involved it feels like a step away from SAAS.

        So I guess the main question is how to penalise/disincentivise dust, without pricing out the real / innovative / beneficial parts of the ecosystem? And perhaps more importantly, how to do that in a way that doesn’t centralise network power with some human handing out rent-free licenses to things it happens to like.

        Is there any alternative to a community consensus solution? – ie in the way wikipedians decides which pages can exist and which should be merged or closed. OR could the miners be somehow able to produce more ETR the more useful/valuable a contract is, so somehow become incentivised to ignore the crud, while contracts are incentivised to use some best practice principles to help ensure they get validated in a space where a miner gets 10x more ETR for a good contract vs a garbage one? (aware I’m feeling very out of my depth again here with these ideas/lingo!)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s