Blockchain Nuts and Bolts: Part 2

In part 1, I discussed miners and their role in building consensus and validation within a blockchain network. In this post, I’ll focus on the other parts of a blockchain network: wallets and clients, and then dive into smart contracts and D-Apps.

Wallets

Let’s start with the wallet. In my opinion, its name makes things very confusing — because wallets are not wallets compared to what you and I might think of as something holding money. Wallets do not hold money at all…they hold cryptographic keys. It might be better to think of them as keystores since that is, in fact, what they do — store keys. The wallet’s role is simply to sign transactions submitted to the network and to retrieve transactions signed by its keys. It’s our window into the blockchain network — narrowly focused to just our interactions with that network. But wallets can be much more than keystores when included as part of a broader application, which I will discuss shortly. For the most part, wallets are pretty dumb — they tend not to interact with the network directly and instead rely on another application to proxy their transaction requests/submissions. This is pretty important since it makes for a better security model. The goal is to minimize external access to the application holding your private keys. So, by allowing a generic client to connect to and interact with the broader blockchain network, the keys have less exposure.

Clients

This implies, of course, that wallets need another application to connect to the network. This is the role of a client. A client, sometimes referred to as a node, is simply a means of interacting with a particular blockchain network. Its role is to submit signed transactions on behalf of a wallet and to keep sync with the state of the blockchain itself. Clients get messages from other clients/miners on the network and make that information available for local query from wallets or other applications. The main purpose of the client is to implement the protocols that are compatible with the blockchain network they connect to.

Smart Contracts

So far I’ve covered the major pieces of a blockchain ecosystem: miners collecting, organizing, validating, and publishing transactions within blocks; clients exchanging messages and communicating with miners and other clients; and wallets submitting and querying transactions for users. While these components made blockchain’s first killer app an obvious choice (financial ledger), extending its capabilities without adding more moving parts required some creativity in the interpretation of transactions.

Transactions can be more than mere inputs/outputs in a ledger. The payload or data portion of a transaction can actually hold anything, including code — bytecode to be specific. And miners can do more than simply verify transactions and build blocks — they can act as a virtual machine and execute instructions embedded within a transaction’s payload. This is precisely how smart contracts are implemented on top of blockchain.

Smart contracts are scripts embedded within a transaction that can impose rules within the blockchain ledger. These contracts are very similar to stored procedures in traditional databases. Each contract has its own address in the network, and in order to invoke functions in the contract, transactions have embedded instructions along with the contract’s address. The miner is responsible for executing the instructions in each transaction and persists any state changes resulting from the smart contract call. In this way, smart contracts extend the capability of the network by offering a rules-based state machine on top of the ordinary financial transactions.

Smart contracts, like database stored procedures, have limitations. The resulting state of every transaction sent to a smart contract must be deterministic. This is because every miner is executing the SAME transaction in parallel on the network. Recall that a miner will announce the next valid block, which will contain a transaction that called a smart contract. It could be any miner and all miners have to execute the transaction against a smart contract. If one miner had different results due to non-determinism within the code, it would not get the same result and would therefore make it impossible to verify the associated block. Deterministic execution, therefore, imposes several limitations on what we can do within a smart contract. For example, smart contracts cannot reach outside of the miner’s storage to retrieve data of any kind. This would make it possible to have different data on different miners and thus make the end state non-deterministic. To get around this particular limitation, we can use an “oracle” that pushes data into the contract via another transaction. Just keep in mind that every transaction must result in the same state on every miner in the network.

D-Apps

These smart contracts can be used as the backend of an application to create what are known as decentralized applications (D-Apps). Most applications require some persisted and shared state. The transparency/consensus/verification features of blockchain can be leveraged to access this shared state and smart contract logic can be used to automate intermediary functionality — thus reducing time and cost.

In a recent hackathon that our team won, we built an application that demonstrated the automated settlement of code delivery and payment using smart contracts. Our solution included a GitHub oracle running as a server application that monitored smart contracts for specific state changes. Those state changes triggered the oracle to retrieve, validate, compile, and deploy code as a means of mediating the delivery and ultimate payment for source code. Integrating blockchain into an application does not always have to ignore centralized services or traditional client/server architecture. In fact, because of the relative immaturity of the ecosystem, many applications have to rely on some centralization until reliable decentralized services are available — storage being one such critical component.

Summary

Within a blockchain ecosystem, there are several moving parts: miners, clients, wallets, smart contracts, and D-Apps. Building applications within the ecosystem requires knowledge and experience in working around some of the various network limitations. But as the technologies mature, and as we refine and polish the tools and capabilities, we have to keep things in perspective.

We are at the very beginning of an evolution towards true individual empowerment. Recent news on data breaches, hacks, and personal data mismanagement are examples of why blockchain matters to us right now. In the earliest days of the Internet, things were very rough — how many of you recall connecting to the Internet and seeing all the animated “under construction” GIFs on webpages? Can you imagine if we said, “this thing is useless” and just walked away? Instead, creative people saw its potential, refined it, improved it, and polished it into undeniably the most impactful invention in human history. It took 40 years to get the Internet to where it is today; how long will it take before people come to expect their data, consumer products, and financial transactions to all be backed by a trusted, transparent, and verified blockchain solution? I encourage all of us to get involved and learn as much as we can about this extraordinary technology!