ethos.dev

Easy and secure staking with Distributed Validator Technology

2022-10-17T00:00:00+00:00

I dream of a market where mainstream users can stake ETH easily and with no fees. There’s also a dream that staking ETH will be as easy as plugging in an Internet router. Until then, we can’t escape reality that staking with an exchange or pool is easiest for mainstream users.

I dream that staking will be free. Currently, most staking companies and pools charge fees starting at 10%! There’s hope from history. When buying stocks, for decades brokerages charged commission fees. Three years ago, in the USA the fees were eliminated!

Is there a catch to free and easy staking?

Staking companies with the most validators can attack the network

Coinbase explains: “You retain full ownership of your crypto, but you’re delegating your staking power to Coinbase.” It hints at the power that staking services amass, but does not educate the risks of that power.

Ownership and custody is relatively simple in Ethereum staking, because there are two staking keys. One is a validator “hot” key, and one is a withdrawal “cold” key. Basically, whoever has the withdrawal key, owns the funds. You can give the validator key to a staking company, and keep the withdrawal key to yourself: a company cannot steal your stake (though they can lose the stake).

By giving your validator key to a company, you give them full power to control your validator. This is the delegated staking power quoted above. When many people give their validator keys to a company, that company can control enough validators to be a threat to the Ethereum network. The company could knowingly or unknowingly command validators to attack the network.

Free staking increases risk of an attack on the network, especially if there’s only one free staking service and it captures most of the stakers. Existing proof-of-stake blockchains have no protocol defence against this.

You need to know this risk of free staking services. But there’s also good news that the Ethereum protocol has been designed with fundamentals to eliminate risk from a single entity.

Distributed Validator Technology (DVT) to the rescue

Distributed Validator Technology (DVT) would require multiple signatures to command a validator, allowing a secure and easy way for mainstream users to stake on Ethereum.

DVT is like multisig for a validator. Instead of a validator being controlled by a single signature, multiple signatures would be needed. This means that you don’t have to delegate your staking power to a single company. I dream that staking companies and pools will interoperate with each other with Distributed Validator Technology.

Unlike other proof-of-stake blockchains, DVT is possible in Ethereum. The Beacon Chain uses BLS signatures. Since BLS signatures are additive, Shamir’s Secret Sharing can be used to split the validator private key into multiple shares. From the individual share signatures, the full BLS signature can be computed. You can configure how many shares to split your validator private key, and how many share signatures are needed for the full BLS signature. This type of Distributed Validator Technology has also been called Secret Shared Validators (SSV).

For example, you could split your validator private key into three shares and give three companies, one share each. (The Ethereum Staking Launchpad could have instructions on offline creation of the shares and what to provide to various staking companies.) The setup could be 2-of-3, so that a single signature is unable to command your validator. Two of the companies would have to sign the same message to command your validator. A company would not have unilateral power to command all the validators of their customer base.

Distributed Validator Technology is critical. There should be easy tools for you to split your validator private key into shares that you can provide to staking companies. There needs to be methods for operating Distributed Validators so that staking operations of different companies can be combined.

Ideally, people should run their own validators. There’s a wonderful, “friendly first, knowledgable second” ETHStaker community that will help you if you’re comfortable. But staking directly is not the easiest mainstream solution yet. Even if you run your own validators, you can still benefit from DVT. They allow you to spread validators across several machines and even different data centers. This increases security and avoids single points of failure.

I dream that market forces and customer demand will push the staking industry to be interoperable with each other using Distributed Validator Technology. We will also need to educate mainstream stakers to use multiple companies configured with DVT, so that they do not grant a single company full control of their validators. Let’s all make it happen!

A 2020 version of this post in a different style and older SSV terminology is at https://ethos.dev/free-staking. There have been many developments since 2020, including the wonderful, “friendly first, knowledgable second” ETHStaker community.

Free staking on Ethereum 2.0 and Secret Shared Validators

2020-05-04T00:00:00+00:00

Did you know that one of the largest exchanges already provides free staking?

Here’s three secrets you should know about Ethereum 2.0 staking and what to do about them.

You’ll want to know about free staking, but more important is doing it with Secret Shared Validators to help maintain network security.

But first, by reporting some facts it can be perceived that there’s businesses the author biases. In truth, there’s little bias and don’t shoot the messenger :) The author’s bias is for the ecosystem which thrives with all the entities in it, and thrives even better when you, the customer, does well.

Secret #3: You should demand free staking

The market for Ethereum 2.0 staking services is building up. You need to know the possibilities. You can prod the market. If you plan on staking, you should express what you’d like. Collectively, at this early stage, stakers can meaningfully lead and shape the market.

As reported last month:

“Coinbase charges the highest fee –25% – for XTZ staking, while Kraken charges 7.25% and Binance currently charges no fee.”

You may have thought that free staking is too cheap. Don’t, because it’s already possible and sustainable by some. Binance’s business model includes free staking, a bit like how Internet business models give you a free email account.

What’s unclear is when Binance will offer staking on the Ethereum 2.0 Beacon Chain. If you’re a Binance customer, it’s worth prodding them for Ethereum staking with Secret Shared Validators. Otherwise it could be months where you may have to suffer 25% staking fees.

Free staking is good for you but will have its critics. This post will not debate much because the two remaining secrets are even more important.

Some may think free staking to be unlikely, but if Binance offers free Ethereum staking, one more exchange (especially Coinbase) could make free staking inevitable. Two companies can tip the market towards free staking.

Free staking makes it harder for startups that want to compete in the retail market. But startups that can tackle markets such as institutional staking, or innovating in other areas, are likely to be healthier for the ecosystem. I’d like to repeat that fees for institutional staking would be highly desirable, so that revenues from it can help fund free staking for the retail market sustainably.

For retail stakers, low fees are very important like the triumph of stock market index funds over actively managed funds. Further, as the number of validators increases, the Annual Percentage Return for staking decreases. Staking returns don’t more penalty of staking fees.

Free staking is good for you. You should demand free staking from the providers charging a fee. Now, is there a catch to free staking? Only if secret #1 doesn’t happen. #1 is Secret Shared Validators and it also needs your voice. Let’s discuss the risk to free staking if Secret Shared Validators don’t happen.

Secret #2: Staking companies with the most validators can attack the network

Ownership and custody is relatively simple in Ethereum 2.0 staking, because there are two staking keys. One is a validator “hot” key, and one is a withdrawal “cold” key. Basically, whoever has the withdrawal key, owns the funds. You can give the validator key to a staking company, and keep the withdrawal key to yourself: a company cannot steal your stake (though they can lose the stake).

By giving your validator key to a company, you give them full power to control your validator. This is the delegated staking power quoted above. When many people give their validator keys to a company, that company can control enough validators to be a threat to the Ethereum 2.0 network. The company could knowingly or unknowingly command validators to attack the network.

Free staking increases risk of an attack on the network, especially if there’s only one free staking service and it captures most of the stakers. Existing Proof of Stake blockchains have no protocol defence against this.

You need to know this dark side of free staking services, but also the good news that the Ethereum 2.0 protocol has been designed with fundamentals to eliminate risk from a single entity.

The #1 secret is little known in the market, but should also be among the priorities in the Ethereum 2020 roadmap to keep the Ethereum 2.0 network more secure.

Secret #1: You should demand Secret Shared Validators

A Secret Shared Validator is like multisig for a validator. Instead of a validator being controlled by a single signature, multiple signatures would be required to command a validator. This means that you don’t have to delegate your staking power to a single company. You should demand a standard for Secret Shared Validators, and demand that staking companies comply with the standard.

Unlike current Proof of Stake blockchains, Ethereum 2.0 is designed to enable Secret Shared Validators. The Beacon Chain uses BLS signatures. Since BLS signatures are additive, Shamir’s Secret Sharing can be used to split the validator private key into multiple shares. From the individual share signatures, the full BLS signature can be computed. You can configure how many shares to split your validator private key, and how many share signatures are needed for the full BLS signature.

For example, if Prysmatic Labs and Sigma Prime (or others) have free staking for (retail) members of the community, then you could split your validator private key into three shares and give each a share. You give the third share to Binance. The setup could be 2-of-3, so that a single signature is unable to command your validator. Two of the companies would have to sign the same message to command your validator. A company would not have unilateral power to command all the validators of their customer base.

Some may tell you that you should run your own validators. That’s fine if you’re comfortable and enjoy the work. But it’s not the mainstream solution yet.

Secret Shared Validators are critical. There should be easy tools for you to split your validator private key into shares that you can provide to staking companies. There needs to be a standard for how to operate Secret Shared Validators so that staking operations of different companies can be combined.

Even if you run your own validators, you can still benefit from Secret Shared Validators. They allow you to spread validators across several machines and even different data centers. This increases security and avoids single points of failure.

There’s a chance that Binance provides free staking but doesn’t allow Secret Shared Validators. Let’s be clear, you should demand that a company supports Secret Shared Validators before signing up for their free staking. If Binance offers 0% fees, you want Secret Shared Validators. If Binance offers 0.5% fees, you still want Secret Shared Validators: paying fees is not a substitute.

Priority of Secret Shared Validators

Prioritizing Secret Shared Validators depends on one’s views about the likelihood of free staking and the threat of a single company obtaining many validators. There’s no alarm for Secret Shared Validators yet. Currently, Ethereum 2.0 client teams are correctly focused on hardening and productionizing their clients. More will soon be written about Secret Shared Validators, to kickstart the specification and implementation of Secret Shared Validator clients, as well as a standard for Secret Shared Validators that staking companies should adopt.

There is related work around Proof of Custody for eth2 Phase 1, and trustless staking pools. Such work (and maintaining focus on it) is important. However, we should not be confused that it covers what’s needed for Secret Shared Validators. Such work is not explicitly leading to Secret Shared Validator clients that can be used in production. Nor does the work lead to a standard for Secret Shared Validators so that staking operations of different companies can be combined.

A dream or will it play out?

Is it a good dream to have Binance and a couple of others provide free staking with Secret Shared Validators? Will Coinbase join? We’ll need to drive towards ensuring:

a specification for a Secret Shared Validator client
there’s easy-to-use tools (and UIs) that allow you to split your validator private key into multiple shares
at least one implementation of a Secret Shared Validator client
a standard for how to operate Secret Shared Validators (so that staking operations of different companies can be combined)
for retail customers, multiple companies offer free staking with Secret Shared Validators
you sign up with two or more such companies and enjoy free staking more securely

The first four items are needed so that Secret Shared Validators can be tested on testnets and released on Mainnet. For the fifth item, you can prod exchanges and prod Binance to use Secret Shared Validators and enter the Ethereum staking market sooner.

Secrets for you to spread

You should know that free staking is viable (even maybe inevitable). But, there’s a risk to the Ethereum 2.0 network if there’s only one free staking company that everyone joins. Secret Shared Validators would prevent a company from unilateral control of their customers’ validators. We need a spec and implementation of a Secret Shared Validator client and contact @dankrad on Twitter or email dankrad@ethereum.org if you’d like to work on this.

Most important, you should demand a standard for operating Secret Shared Validators that staking companies should comply with. Let’s hope that you can enjoy free staking on Ethereum with Secret Shared Validators to maintain network security. Let’s all make it happen!

Thank you to Dankrad Feist for reviewing a draft and feedback, including Secret Shared Validator terminology (I capitalized for readability). As always, reviewers don’t imply agreement with my opinions.

Audit the Deployed Smart Contract, Not Github!

2017-12-13T00:00:00+00:00

Best practice smart contract audits should be performed on a release candidate, which should be deployed on Ethereum mainnet before an audit is performed.

Suppose Mallory is looking to have her smart contract audited so she gives Bob, her auditor, some git hash, or (gasp!) a zip file of the source code. Mallory has taken care to follow the first rule of a responsible token sale by implementing a staggered release of funds and vesting contracts. Bob clones the repo, audits and reports issues, checks the fixes, and proclaims the audit is completed. Mallory announces the audit results, launches her ICO, and collects millions. The next day, however, all the funds, which were supposedly locked, have been sent to mysterious addresses and Mallory is never to be found again. A simple post-mortem finds that the smart contract Mallory deployed had a subtle backdoor that was added to the source code Bob had audited.

In a software release life cycle, a release candidate (RC) is the final stage before software is launched. To minimize code churn, an audit should be performed on an RC. An RC does not change, and it eventually becomes the release itself, unless there are showstopper bugs, which then get fixed and another RC is generated. Historically, an RC is managed by a version control system, but where does a smart contract RC belong? On the blockchain!

An auditor’s responsibility to the community should include ensuring that what they audit is what is released to the community to use. Auditors can audit the RC that’s actually on the blockchain, not some malleable code on Github that might get deployed. Auditors should ask their clients for the Ethereum mainnet addresses of the RC contracts. The community should request that bug bounty programs refer to Ethereum mainnet addresses. This methodology has four main benefits. Though we’ll be speaking in terms of a single smart contract, the methodology is also applicable to a system of smart contracts.

Four Benefits

First, auditing the deployed smart contract eliminates scenarios where the audited source code is accidentally or maliciously changed then deployed to mainnet. The smart contract is already on mainnet and its code cannot be changed.

Second, using a mainnet address signifies readiness for an audit and reduces code churn. Let’s take Alice, who thinks her code is ready for an audit. Is it really ready? Or is there one more change or tweak left? Not having a mainnet address suggests that the contract isn’t quite ready. By actually deploying the contract, Alice makes a distinct decision that the code is as ready as can be at that point in time. Even though it only costs $1 to pay the gas for deploying her contracts, Alice is unlikely to make code commits and redeploy several times. Bob is relieved because he can’t audit a moving target.

Third, by actually deploying the contracts to mainnet, Alice increases her readiness for launch. In the ideal case that there are no showstoppers, the RC becomes the release and Alice can simply announce her launch! Note that before a mainnet deploy, any respectable development team will have addressed security as early as possible in development and have done rigorous testing, including testnets.

Fourth, ecosystem synergies can emerge. Since Bob has audited a contract with an address, he can have a registry of all the contracts he’s audited. Charlie, another auditor can have a uPort attestation to Bob’s registry as well as his own registry. User interfaces can be built in which someone can input an address and see who’s audited the contract. Tools like MetaMask and Etherscan can tap into these, and further creative tools and DApps can leverage the ecosystem and expand it.

How the audit process might look

Alice deploys her wallet contract and gets the address 0x851b7f3ab81bd8df354f0d7640efcd7288553419.
Alice uploads and verifies her source code on etherscan.
Bob gets the source code at https://etherscan.io/address/0x851b7f3ab81bd8df354f0d7640efcd7288553419#code
Bob runs verifier to ensure that the source code compiled bytecode matches the bytecode on the blockchain.
Bob audits the source code (splitting it into smaller pieces if it helps him).
Alice makes required fixes and repeats the process (typically only one more loop). The process can end immediately here if it’s deemed that there are no showstoppers that need to be fixed.

Verifying the source code from the blockchain

Perhaps people have been trusting contract source code on Etherscan too much. Alex Luoyuan has built a tool to help verify that the deployed bytecode at a given address matches the compiled output from source code:

https://www.npmjs.com/package/eth-bytecode-verifier

Source code verification is only available on Etherscan for now, but stay tuned for further developments.

Smart Contract Design

Alice may need to design or refactor her contract to support at least two states:

ContractDeployed
ContractReady

For example, if Alice had a token sale contract that started as soon as it was deployed, it would need to be modified so that auditors, bug bounty programs, and the public could examine the contract while it is in a ContractDeployed state and before the sale has commenced. The act of launching would then involve sending a transaction to configure and transition the contract to a ContractReady state where the token sale can accept contributions.

In practice, we don’t really see such contracts that support two states breaking the functionality of the contract. If there are exceptions, they can be examined. Also, less interactive contracts such as a wallet don’t need to necessarily support two states.

What do you think?

Auditing deployed smart contracts is the closest thing to auditing what users will actually interact with. If you’re an auditor, ask your clients for their mainnet contract addresses: it will save everyone time, make the audit process more secure, and help tap into ecosystem synergies. Learnings from this methodology will be described in a future post.

Thanks to Maurelian, Gonçalo Sá, Alex Luoyuan, Eva Shon, and Bernhard Mueller for feedback.

Introducing ConsenSys Diligence

2017-06-30T00:00:00+00:00

ConsenSys Diligence is raising the bar for security best practices in the Ethereum ecosystem.

The Ethereum blockchain is skyrocketing in popularity. Last month, Fred Wilson of Union Square Ventures predicted that the market cap of Ethereum will surpass Bitcoin’s in 2017, and The New York Times’ Dealbook seems to agree with him. In addition to increasing awareness of the Enterprise Ethereum Alliance and capabilities of smart contracts on the Ethereum platform, token launches are attracting higher and higher amounts of money. Developers want to capitalize on this movement by getting their tokens out as quickly as possible, and they feel immense pressure to quickly write and deploy contracts.

The paradoxical outcome is that the stakes are higher, but people are becoming less cautious.

Let’s not forget the lessons learned from ‘The DAO’. In the wake of the June 2016 exploit, developers turned their attention toward security and best practices for smart contract development. And yet, it seems that as time passes, the painful memory of The DAO is beginning to fade.

To usher in the new era of decentralized innovation, we need people to participate in the ecosystem — a lot of people. And we need their optimism to work for them, not against them. We need the community to help each other and watch out for each other. That’s why we created ConsenSys Diligence.

ConsenSys Diligence: Raising the bar for security best practices in the Ethereum ecosystem

ConsenSys Diligence is committed to improving the Ethereum ecosystem by promoting technical excellence, security best practices, legal precautions, and ethical business practices.

Currently we are working with specific high-impact projects as they prepare to deploy their contract systems. We encourage projects to launch when ready, rather than trying to time markets. Our criteria for readiness extends beyond a basic code review, to include requirements for specifications, test drivers, static analysis, and staged roll outs.

This approach is informed by our experience working with clients like Gnosis, WeiFund, SingularDTV, uPort, and adChain. ConsenSys Diligence is also actively involved in writing and reviewing code deployed in production systems on private chains at some of the largest Fortune 500 companies in the world.

In the future, we plan to expand these services to include assessment of legal structures and business cases. We’ll look beyond the white paper, into the fundamentals of the business plan, team, and code behind a project.

As a part of ConsenSys, our incentives are aligned with the long-term health of the ecosystem rather than short-term revenue. The ecosystem will always be our priority — over potential clients, business practices, and revenues. When there is a conflict between what a client desires and what’s good for the ecosystem, we side with the ecosystem. When we discover code or actions that are not improving the ecosystem and community, our priority is to inform the community about them.

Want to work with us?

Projects:

We’re looking to work with clients who:

Display a long-term planning horizon and vision
Are willing to prioritize readiness over a sense of urgency
Have a project with potential to make a significant impact on the ecosystem
Have a history of contributions to the community

If this sounds like you, please feel free to reach out to us at diligence@consensys.net.

This was co-authored with Maurelian and Gonçalo Sá, originally posted on the ConsenSys blog.

Very deep-dive on Ethereum Reading List (2016)

2016-11-30T00:00:00+00:00

A technical reading list for getting very deep in Ethereum in 2016, including Ethereum Improvement Proposals (EIP) that fundamentally strengthened the protocol against attacks.

LeastAuthority/ethereum-analyses

This first public audit on Ethereum is a classic. Very deep impact and had clues to all major attacks on Ethereum so far, such as reentrancy hazards and gas economics. May you find the next major contributions and vulnerabilities on Ethereum, possibly using this resource for ideas and inspiration. (Don’t forget the Appendix.)

The “Yellow Paper”: Ethereum’s formal specification

The formal specification of the Ethereum protocol. Yes it could be clearer, but until someone seizes the opportunity, it’s what’s there.

Ethereum Subtleties

A lot of the subtleties of Ethereum. Blackhats don’t often lurk in the daylight of the obvious, but in the darkness of subtleties where much fewer whitehats roam. For example, one of the DoS attacks used “note: there is a difference between zero-balance and nonexistent!”

EIP 150: Long-term gas cost changes for IO-heavy operations to mitigate transaction spam attacks

Phase 1 mitigation for transaction spam attacks

EIP 155: Simple replay attack protection

Replay attack prevention

EIP 160: EXP cost increase

EXP cost increase. Fixes the “last” mispriced opcode.

EIP 161: State trie clearing (invariant-preserving alternative)

State trie clearing to purge empty accounts from the chain
An earlier proposal is EIP 158

EIP 170: Contract code size limit

Limit the maximum size of contract code on the blockchain

Discussions

Some places for discussions are happening here, feel free to join in the conversation!

https://gitter.im/ethereum/eips

https://gitter.im/ethereum/research

https://gitter.im/ethereum/yellowpaper

https://old.reddit.com/r/ethereum

This was first published on ConsenSys blog. The reading list is still largely relevant; Gitter has historical discussions.

Addendum: Technical Discussions in 2022

ethresear.ch

Ethereum Magicians forum

Ethereum R&D Discord

Ethereum’s Shanghai Attacks

2016-11-30T00:00:00+00:00

It all began during the second Ethereum Developer’s Conference, held in Shanghai. A blackhat hacker or group started probing the Ethereum blockchain. We’ll use the term blackhat because it’s a reasonable one, as opposed to whitehat hackers who are more collaborative, for example participating in bug bounties like the Ethereum Bounty Program.

One of the exploits that the blackhat took advantage of was mispriced opcodes, or their inefficient implementation. Some opcodes in the EVM (Ethereum Virtual Machine) consumed little gas in relation to the amount of computation that would be necessary in real life. Gas economics was discussed in an audit of Ethereum by Least Authority conducted in the first quarter of 2015. (It’s also worth noting that the same audit was aware of “reentrancy hazards”, which was the The DAO’s downfall). The blackhats exploited mispriced opcodes to make Ethereum nodes perform useless computations as well as bloat the size of the blockchain.

In their exploits, the blackhat found a cheap way to create empty accounts on the blockchain. It’s unclear why empty accounts were allowed on the blockchain in the first place, because the “difference between zero-balance and nonexistent” accounts was a known issue. The mitigation that already existed was that a fee was associated with creating an account. However, the blackhat discovered a method to create empty accounts in a cheap manner by leveraging the selfdestruct opcode.

The EIP 150 hard fork fixed virtually all of the mispriced opcodes. This was released on October 18th, 2016 and provided substantial relief to Ethereum nodes and miners. EIP 150 was important to test thoroughly and release at that time, however, it was already a known factor that another hard fork would be needed to reduce blockchain bloat (and improve a remaining mispriced opcode).

As a step to deleting the empty accounts from the blockchain, the Spurious Dragon hard fork containing EIP 161 took place on November 22th, 2016. This hard fork did not delete the empty accounts. It had a consensus rule however, that any empty accounts that were touched, would be removed from the blockchain. Soon after, transactions touching empty accounts began to appear on the blockchain. The blackhat had created about 19 million accounts, and around 4 million of them had been cleared by November 24th, 2016, when a blockchain fork was observed.

Geth and Parity began producing different blocks at block #2686351. The developers investigated and discovered that when a transaction touching an empty account ended with an Out of Gas exception, Geth did not revert and restore the empty accounts. Prior to EIP 161, the rules of what happens when a transaction runs Out Of Gas were relatively clear: changes to the state would be reverted. In EIP 158, an earlier proposal to EIP 161, a community member asked an ominous question if “… empty accounts are deleted even in the case of an EVM exception, … would that not break the guarantee that EVM exceptions revert the state back as if the transaction was never made?”

Was this a conscientious member of the community foreshadowing the thorniness of the issue? A fix was made to Geth to bring consensus back on a single chain, but it’s worth pointing out how intricate the issues are because Parity was not perfect either and Geth 1.5.3 had to add a special case for a Parity bug. (In a world without the Geth bug, the Parity bug would have caused its own fork at block #2675119.)

The above experiences of the past two months suggest that blackhat activities have made Ethereum more resilient than any bug bounty can provide. But it also suggests that there is strength in the community and opportunities for its talent to be whitehats or kibitzers. We’d like the community to have, especially new members, a reading list if there is interest in a very deep-dive on Ethereum.

Some of the above news may have overshadowed other developments, like light clients and Swarm, and in the past week alone, we’ve seen the releases of ENS (Ethereum Name Service), Quorum (Ethereum permissioned chain for privacy) and Raiden PoC1 (Ethereum’s lightning network). The community has received priceless lessons and is poised for continuous innovation.

Special thanks to reviewers, your feedback and improvements is highly appreciated.

Original title was “From Shanghai to the Spurious Dragon”.

Designing Safer Smart Contracts

2016-08-10T00:00:00+00:00

In a short time Ethereum has turned into the world’s second largest cryptocurrency, with a market cap of $1B and thousands of nodes around the world running its code. Developers and companies in a number of industries are exploring its potential to improve existing processes. Beyond metrics, Ethereum has pioneered the idea of easy to write smart contracts, where complex contract logic can be created on the blockchain without the need for centralized parties with a programming language similar to that used by non-blockchain developers.

Still, as The DAO attack and subsequent hard fork show, challenges abound for those writing smart contracts at this nascent stage for Ethereum. While The DAO had a substantial number of technical issues and a flawed rollout process that have both been heavily debated, it’s impossible for any developer to write bug free code that is impervious to attack. This is exacerbated by developing on a new platform where real money is at risk. This problem is even more challenging because blockchain application code is held on an append-only ledger with advanced techniques, planning, and design required to change code. Given how easy Solidity is to write, developers with experience in other fields of software may feel a false sense of comfort.

At ConsenSys, where we have a number of decentralized projects underway like SingularDTV and Gnosis, the challenges faced by The DAO underscore how important it is to ensure that all our projects meet the highest safety and security standards. After reaching out to a number of Ethereum community members, we assembled a document outlining Ethereum Smart Contract Best Practices that is now available for anyone to contribute to.

We collected a number of anti-patterns and sample attacks, like The DAO’s re-entrancy bug, an example of a broader set of “race conditions”. For most attacks, we show code examples, outline the risks, and recommend potential solutions. Over time, we hope this will be a primary resource for those writing Solidity — and encourage you to add examples of good code or smart contract attacks you’ve seen.

Second, we had a spirited debate amongst ourselves about what philosophies the community needs to reduce the likelihood of a future systemic risk to the entire Ethereum platform. After all, at this stage in Ethereum’s development, no amount of memorized code idioms will prevent unknown, often unknowable, mistakes. As such, we highlighted a number of key philosophies for every Solidity developer from rolling out contracts slowly over a period to staying up to date with security discoveries.

Some of our observations are counterintuitive and should encourage debate. For example, we think that despite an easy language, blockchain programming is not far off from programming for a NASA launch or designing a financial exchange with money at risk, and so needs a substantial mindset shift from traditional web programming, especially for fail fast type products like social networks.

We encourage you to add your own commentary and file an issue if you’d like to debate something. As all developers, it’s likely we’ve made mistakes or not considered all possibilities, and so we welcome corrections.

The goal is for the best practices to be community owned and maintained, with a focus on facts and minimal opinions. A bibliography embraces links to all relevant resources, including blog posts that can be added by anyone in the community, including the authors of such posts themselves. For those that prefer a frictionless approach instead of a pull request, the Ethereum Wiki Safety page is editable by anyone. So feel free to fix a typo, add an example, add something from your blog, or write an entire section!

Over the course of the next few weeks and months, we will be going more in depth about some of the tips and philosophies outlined in the document.

Despite the challenges, the work we all do at this stage is pioneering new approaches to decentralized systems and each of us can have substantial impact given how early it is for the ecosystem.

Initially published on the ConsenSys blog. Links have been fixed with Github versions. Anchor text for “Ethereum Smart Contract Best Practices” was originally “Ethereum Contract Security Techniques and Tips”. My main co-authors on launch of the smart contract best practices were Nemil Dalal, Simon de la Rouviere, and Peter Borah.

Ethereum Gas, Fuel & Fees

2016-06-23T00:00:00+00:00

Ethereum is a platform for decentralized and truthful applications that run on a global, peer-to-peer network without any administrators or a single point of failure. These applications have zero downtime and anyone can create them: it is permissionless innovation. The applications are truthful, immutable and always interoperate as they are coded. From this perspective, the terminology of smart contracts is reasonable in that they are the ultimate in contracts that always follow the terms set at their creation.

The core of what makes this possible is effectively a World Computer. Technically called the Ethereum Virtual Machine (EVM), it includes operations for computation and data storage. A transaction represents a single session within the World Computer. It is the unit of interaction, similar to how a sentence is the unit of grammatical meaning, even though a single sentence can contain many words.

What is Gas?

Gas is the metering unit for use of the World Computer. As an analogy, electricity is metered by kilowatt hours. Using more computation and storage in Ethereum means that more gas is used. One fundamental reason for metering is that it provides an incentive for people (miners) to operate the World Computer. These miners get a fee for processing transactions, which is determined by the metering scheme: gas.

Each operation in the EVM consumes gas. For example, a multiplication (MUL) consumes 5 gas and an addition (ADD) consumes 3 gas. Here is a spreadsheet of Ethereum’s operations and their gas consumption.

Consider gas to be synonymous with fuel

Metering is different from fees and gas is different from Ether. To help clarify this, consider gas to be synonymous with fuel. A transaction must provide enough fuel, or startGas, to cover its entire use of the EVM’s computation and storage facilities. All remaining gas is refunded to the transaction’s originator: the user who initiated the transaction. A transaction that runs Out of Gas is reverted, but still included in a block and the associated fee is paid to the miner.

With an overview from the perspective of fuel, let’s turn to an overview of fees. While every operation in the EVM consumes a predefined amount of gas (for example, a MUL operation always consumes 5 gas), a user can specify a gas price in every transaction. The current gas price is 0.02µ Ethers, or 0.00000002 ETH. The fee an originator pays a miner is the transaction’s (startGas — remainingGas) × gas price.

Here is a summary of the influences of transaction fuel and transaction fee:

At the start of a transaction, the Ether required for the startGas is set aside, and the remainingGas is set to startGas. With each operation of the transaction, gas is consumed and remainingGas is lowered. If there’s an Out of Gas exception, all operations are reverted and all the Ether that was initially set aside is given to the miner. If the transaction completes successfully, all the remainingGas is refunded to the originator and the rest is paid to the miner.

Simple example

In the following mock scenario, assume that a STORE consumes 45 gas and an ADD consumes 10 gas. The scenario involves storing the number 31 in the EVM, summing 2 numbers, and then storing the sum. Let’s assume that the originator specified a startGas of 150 and a gas price of 0.02µETH. Below is an illustration as the transaction is processed by the EVM:

The originator pays the miner a fee of:

(150–50) × 0.02µETH = 2µETH = 0.000002 ETH

Fuel vs. Fee

There is a difference between an originator providing enough fuel and providing enough fees. Here are the likely effects on a transaction:

A transaction with too little fuel will not even reach miners, regardless of the fee supplied. If adequate fuel is provided for a transaction, but the fee is too low, even though the transaction may reach miners, upon seeing the fee miners will not perform any computation. Fees determine the order in which transactions will be included in the blockchain. The reason why providing high fuel can lead to a transaction taking longer to get mined is discussed below in Potential delays with high startGas.

startGas

Let’s discuss the fuel needs at the start of a transaction. Abstractly, before allowing use of its computation and storage, the World Computer needs to know if the originator can pay for it. Concretely, before processing a transaction, a miner needs to know if it will get paid. A transaction must offer the maximum amount of fuel it is willing to consume. For this article’s purposes, this offer will be called startGas. startGas is an essential part of a transaction. Unfortunately, different documentation has used different words to describe this critical component:

startGas is the term in the Ethereum White Paper
gasLimit is the term in the Ethereum Yellow Paper
software, such as go-ethereum and web3.js, simply uses the term “gas”

startGas keeps things simple (away from say a pay as gas is consumed approach) because it is impossible for a miner, in the general case, to know how much computation is required without running the actual computation (related to the Halting problem). As a user of an Ethereum application, it may seem complicated to have to provide startGas, but developers have some tools for estimating startGas and hiding the details from the user.

Out of Gas exception

A transaction offers the maximum amount of fuel it is willing to consume. This gas is consumed with each operation of the EVM. If all the gas is consumed without the transaction being completed, an Out of Gas exception occurs. The originator pays the miner for all the work that’s been performed and the transaction is included in a block, but all state changes (such as contracts created, values stored, events and logs written) are reverted.

Let’s use the same scenario as the first example, but this time the originator specifies a startGas of 90 (instead of 150). Here’s an illustration of the execution:

At the start of the transaction, the originator must set aside funds for all the fuel: startGas × gas price = Ether placed in escrow. The amount of Ether in escrow is:

90 × 0.02µETH = 1.8µETH

Gas is consumed as each operation is performed and the operation to STORE sum is an Out of Gas exception. This causes all operations to be undone, meaning that the number 31 gets reverted to whatever value was previously stored, but the transaction is still included in the blockchain and the miner is paid the entire escrow amount: 1.8µETH.

Gas refund

There are 2 operations in the EVM with negative gas:

Clearing a contract is -24,000
Clearing storage is -15,000

When the EVM executes such an operation, it is tallied in a separate refund counter. The gas refund is only provided at the end of the transaction. Also, the maximum refund equals half the gas consumed.

A key point is that a transaction’s fuel never increases. As the EVM performs operations, the fuel always decreases (with the refund counter increasing when some contract or storage is cleared). If the fuel reaches zero or negative, then an Out of Gas exception occurs immediately: it does not matter how much gas is in the refund counter. For a transaction to be able to use a gas refund, it must avoid an Out of Gas exception. Assuming that a transaction had enough gas, then it can make use of the gas in the refund counter.

The amount of gas refunded is at most half the gas used. For example, if a transaction used 60,000 gas and cleared 2 contracts for a refund of 48,000 (24,000 each above), the originator would still pay the miner for 30,000 gas. This incentivizes miners to run transactions with negative gas operations, as it gives them revenue and ensures that it is impossible for a miner to pay for someone else’s computation.

Block gas limit (BGL)

Recall that startGas is the user-specified, maximum amount of fuel that a transaction will consume. So how many transactions can fit in a block? The answer is until the sum from each startGas reaches the block gas limit (BGL). The BGL is currently 4,712,388 (digits of 1.5π), meaning around 224 transactions that each have a startGas of 21000 can fit in 1 block (which is produced every 15 seconds on average). To prevent Bitcoin-like divisiveness over whether blocks should become larger, the Ethereum protocol allows the miner of a block to adjust the BGL by a factor of 1/1024 (0.0976%) in either direction. Separate from the protocol is a default mining strategy of a minimum BGL of 4,712,388.

Potential delays with high startGas

Since an Out of Gas exception is practically a waste of money for an originator, it is always better to overestimate the startGas than to underestimate. So, why shouldn’t an originator always specify a startGas of 4 million?

The answer lies in the difference between a transaction’s startGas and the gas it actually consumes. Miners only get paid for the actual gas consumed by a transaction; all unused gas is refunded to the originator.

If there is a transaction with a startGas of 4M and another 100 transactions with a startGas of 40,000 each, a miner would probably choose the latter as the 100 transactions have more predictable revenue. If the transaction with 4M startGas actually only consumes 1M of gas, then the miner loses 3M gas of potential revenue. Thus, miners are likely to prioritize a set of “small” transactions over a single transaction with a very high startGas (unless intrinsic gas is also very high). This can lead to a delay before a high startGas transaction is eventually mined and explains why an excessive startGas can be detrimental.

Detour to Exchanges

There are 2 types of accounts in Ethereum:

User accounts (controlled by private keys)
Contracts (controlled by code)

Sending Ether (ETH) to a user account has a fee of 21000 gas but sending ETH to a contract has a higher fee, which depends on the contract code and data being sent in the transaction. Some exchanges may have only been providing 21000 gas for all their transactions, which means that when a user wanted to send ETH from an exchange to their contract wallet in Mist (Ethereum Wallet), the transaction would run Out of Gas and the ETH would never make it to the user’s contract wallet.

Metering vs. Fee

One more note on the difference between metering and fees. In Bitcoin, metering is done with bytes: the number of bytes in the transaction. In Ethereum, computation also needs to be metered because a small amount of code could still be a program that runs forever. Metering computation is one of the reasons for gas. But having gas doesn’t mean requiring fees.

For example, in a private chain each account could have X gas per day, or each account could have Y gas per transaction, or some other scheme. On the flip side, having fees doesn’t mean requiring gas: fees can be based on different metering, such as bytes. Security in a public blockchain requires both gas and fees, while the alternatives are more applicable to private chains (for example, a scheme where each account has X gas per day can be Sybil-attacked in a public chain where anyone can create an account).

Conclusion

Gas is metering and fuel for using the World Computer and is different from the Ether fee that is charged for using the World Computer. There is a difference between providing enough fuel and providing enough fee. Running Out of Gas costs money and it is safer to offer more gas, since all unused gas is refunded. Gas is a core part of Ethereum and the majority of its topics have been discussed. There’s more to it, including estimating gas, intrinsic gas, effects on transaction size, and further exploration and understanding can be built on the foundations provided by this article.

Technical Introduction to Events and Logs in Ethereum

2016-06-06T00:00:00+00:00

Events and logs are important in Ethereum because they facilitate communication between smart contracts and their user interfaces. In traditional web development, a server response is provided in a callback to the frontend. In Ethereum, when a transaction is included on-chain, smart contracts can emit events and write logs to the blockchain that the frontend can then process. There are different ways to address events and logs. This technical introduction will explain some sources of confusion regarding events and some sample code for working with them.

Events can be confusing because they can be used in different ways. An event for one may not look like an event for another. There are 3 main use cases for events and logs:

smart contract return values for the user interface
asynchronous triggers with data
a cheaper form of storage

The terminology between events and logs is another source of confusion and this will be explained in the third use case.

1) Smart contract return values for the user interface

The simplest use of an event is to pass along return values from contracts, to an app’s frontend. To illustrate, here is the problem.

contract ExampleContract {  
  // some state variables ...  
  function foo(int256 _value) returns (int256) {  
    // manipulate state ...  
    return _value;  
  }  
}

Assuming exampleContract is an instance of ExampleContract, a frontend using web3.js, can obtain a return value by simulating the contract execution:

var returnValue = exampleContract.foo.call(2);  
console.log(returnValue) // 2

However, when web3.js submits the contract call as a transaction, it cannot obtain the return value¹:

var returnValue = exampleContract.foo.sendTransaction(2, {from: web3.eth.coinbase});  
console.log(returnValue) // transaction hash

The return value of a sendTransaction method is always the hash of the transaction that’s created. Transactions don’t return a contract value to the frontend because transactions are not immediately mined and included in the blockchain.

The recommended solution is to use an event, and this is one of the intended purposes for events.

contract ExampleContract {  
  event ReturnValue(address indexed _from, int256 _value);function foo(int256 _value) returns (int256) {  
    ReturnValue(msg.sender, _value);  
    return _value;  
  }  
}  

A frontend can then obtain the return value:

var exampleEvent = exampleContract.ReturnValue({_from: web3.eth.coinbase});  
exampleEvent.watch(function(err, result) {  
  if (err) {  
    console.log(err)  
    return;  
  }  
  console.log(result.args._value)  
  // check that result.args._from is web3.eth.coinbase then  
  // display result.args._value in the UI and call      
  // exampleEvent.stopWatching()  
})  
exampleContract.foo.sendTransaction(2, {from: web3.eth.coinbase})

When the transaction invoking foo is mined, the callback inside the watch will be triggered. This effectively allows the frontend to obtain return values from foo.

2) asynchronous triggers with data

Return values are a minimal use case for events, and events can be generally considered as asynchronous triggers with data. When a contract wants to trigger the frontend, the contract emits an event. As, the frontend is watching for events, it can take actions, display a message, etc. An example of this is provided in the next section (a UI can be updated when a user makes a deposit.)

3) a cheaper form of storage

The third use case is quite different from what’s been covered, and that is using events as a significantly cheaper form of storage. In the Ethereum Virtual Machine (EVM) and Ethereum Yellow Paper², events are referred to as logs (there are LOG opcodes). When speaking of storage, it would be technically more accurate to say that data can be stored in logs, as opposed to data being stored in events. However, when we go a level above the protocol, it is more accurate to say that contracts emit or trigger events which the frontend can react to. Whenever an event is emitted, the corresponding logs are written to the blockchain. The terminology between events and logs is another source of confusion, because the context dictates which term is more accurate.

Logs were designed to be a form of storage that costs significantly less gas than contract storage. Logs basically³ cost 8 gas per byte, whereas contract storage costs 20,000 gas per 32 bytes. Although logs offer gargantuan gas savings, logs are not accessible from any contracts⁴.

Nevertheless, there are use cases for using logs as cheap storage, instead of triggers for the frontend. A suitable example for logs is storing historical data that can be rendered by the frontend.

A cryptocurrency exchange may want to show a user all the deposits that they have performed on the exchange. Instead of storing these deposit details in a contract, it is much cheaper to store them as logs. This is possible because an exchange needs the state of a user’s balance, which it stores in contract storage, but does not need to know about details of historical deposits.

contract CryptoExchange {  
  event Deposit(uint256 indexed _market, address indexed _sender, uint256 _amount, uint256 _time);

  function deposit(uint256 _amount, uint256 _market) returns (int256) {  
    // perform deposit, update user’s balance, etc  
    Deposit(_market, msg.sender, _amount, now);  
}

Suppose we want to update a UI as the user makes deposits. Here is an example of using an event (Deposit) as an asynchronous trigger with data (_market, msg.sender, _amount, now). Assume cryptoExContract is an instance of CryptoExchange:

var depositEvent = cryptoExContract.Deposit({_sender: userAddress});  
depositEvent.watch(function(err, result) {  
  if (err) {  
    console.log(err)  
    return;  
  }  
  
  // append details of result.args to UI  
})

Improving the efficiency of getting all events for a user is the reason why the _sender parameter to the event is indexed:

event Deposit(uint256 indexed _market, address indexed _sender, uint256 _amount, uint256 _time)

By default, listening for events only starts at the point when the event is instantiated. When the UI is first loading, there are no deposits to append to. So we want to retrieve the events since block 0 and that is done by adding a fromBlock parameter to the event.

var depositEventAll = cryptoExContract.Deposit({_sender: userAddress}, {fromBlock: 0, toBlock: 'latest'});  
depositEventAll.watch(function(err, result) {  
  if (err) {  
    console.log(err)  
    return;  
  }  
  // append details of result.args to UI  
})

When the UI is rendered depositEventAll.stopWatching() should be called.

Aside — Indexed parameters

Up to 3 parameters can be indexed. For example, a proposed token standard has:

event Transfer(address indexed _from, address indexed _to, uint256 _value)

This means that a frontend can efficiently just watch for token transfers that are:

sent by an address tokenContract.Transfer({_from: senderAddress})
or received by an address tokenContract.Transfer({_to: receiverAddress})
or sent by an address to a specific address tokenContract.Transfer({_from: senderAddress, _to: receiverAddress})

Conclusion

Three use cases have been presented for events. First, using an event to simply get a return value from a contract function invoked with sendTransaction(). Second, using an event as an asynchronous trigger with data, that can notify an observer such as a UI. Third, using an event to write logs in the blockchain as a cheaper form of storage.

This introduction has shown some of the APIs⁵ for working with events. There are other approaches to working with events, logs, and receipts⁶ and these topics can be covered in future articles.

Thanks to Aaron Davis, Vincent Gariepy, and Joseph Lubin for feedback on this article.

web3.js could watch for the transaction to be included the blockchain, then replay the transaction in an instance of the EVM, to get the return value, but this is a significant amount of logic to add to web3.js ↩
https://github.com/ethereum/yellowpaper ↩
There are gas costs of 375 for a LOG operation, and 375 gas per topic, but when many bytes are being stored, these costs represent an insignificant fraction of the total cost of the storage. ↩
Merkle proofs for logs are possible, so if an external entity supplies a contract with such a proof, a contract can verify that the log actually exists inside the blockchain. ↩
https://github.com/web3/web3.js/blob/0.20.7/DOCUMENTATION.md#web3ethfilter ↩
http://ethereum.stackexchange.com/questions/1381/how-do-i-parse-the-transaction-receipt-log-with-web3-js ↩

Blockchain Underpinnings: Hashing

2016-01-13T00:00:00+00:00

Light bulbs, bits, and bytes

You may have heard that all data in computers, is either 0 or 1. The smallest piece of data is a bit, and is either a 0 or 1. Imagine a computer as having many light bulbs, and the bulbs are either on (1) or off (0). Different pieces of data are represented by the pattern displayed by the bulbs. Large data, such as videos, use many light bulbs. A short email, would use fewer light bulbs. A single light bulb is a bit. Another term you may have heard of is a byte, which is simply a group of 8 bulbs. A megabyte of data is 1 million bytes, which would be 8 million bulbs.

Today’s home computers have billions and even trillions of light bulbs. But with the power of doubling, notice that even just a group of 256 bulbs is almost enough to represent any of the observable particles in the universe. Imagine all the patterns that a group of 256 bulbs can produce, and it is an astronomical number: mathematically it’s 2 to the power of 256.

Cryptographic hash functions

A hash function, takes any input, and produces an output of a specific size. The process of applying a hash function to some data, is called hashing. The output of a hash function is called a hash. The basic feature of a particular hash function is the size of the output it produces. For the examples in this article, we’ll use a hash function that produces an output of 256 bits (32 bytes). There are hash functions to produce smaller output, and others that produce larger output. There are also many hash functions that produce an output of 256 bits, but the examples don’t care about which specific one is used.

Using the example hash function, when a video of many megabytes is hashed, the output will be 256 light bulbs with some of the bulbs lighted. When a short email is hashed, the output will be 256 light bulbs with a different pattern. In some ways, hashing looks like compression. To briefly explain a difference between the two, hashing always produces the same number of light bulbs, whereas compressing a video of many megabytes will still produce an output of millions of light bulbs. A compressed video, can be decompressed to obtain the original video. When a video is hashed to only 256 light bulbs, reconstructing the many megabytes of the original video from the hash is unlikely. It may not sound desired, but this behavior is actually a powerful feature of hash functions.

One critical characteristic of a secure cryptographic hash function is that it is one-way. This means that from the output, it is virtually impossible, or mathematically and computationally improbable, to determine what the input is. That is, given a hash, it should be infeasible to learn about or find the input data that was provided to the hash function. The technical term for this is pre-image resistance.

A consequence is that a hash function should consume approximately the same amount of time, whether it is hashing a large or small input. Another desirable outcome is that hashes, patterns of light bulbs produced by hash functions, should appear to be random. Hashing the data “password1” should produce a very different pattern of light bulbs, than from hashing the data “password2”. Otherwise, if the patterns were similar, an adversary could infer that the inputs are similar, and if either or related words (like “pass”, “word”) are discovered, the passwords could be found easily. Secure hash functions produce drastically different outputs, even if inputs differ by only a single bit.

The ideal behavior for security is that given a hash, the only way to find the input data is by hashing all combinations of inputs, until the correct input is hashed. If the input is random, finding it would take an indeterminate amount of time, and thus effectively impossible.

While finding the input for a hash should be infeasible, computing a hash should be fast to compute. Most hash functions can hash hundreds of megabytes in a second.

Cryptographic hash functions should also be collision resistant. A collision is when a hash function produces the same output, for more than one input. If hashing data1, which maybe a spreadsheet, and hashing data2, which maybe a picture, produce the same output, then a collision has occurred.

The importance of the properties of secure cryptographic hash functions will be more evident as we describe blockchains and hashing.

Blockchains and Hashing

Hashing is extensively used with blockchains and here are some examples.

Addresses on a blockchain are derived by a process of hashing public keys. An Ethereum account is computed by hashing a public key with Keccak-256 (developers should read the crucial distinction with SHA3–256). A Bitcoin address is computed by hashing a public key with SHA2–256 and RIPEMD160.

Collision resistance of the hash functions are important because if 2 people generate the same address (a collision) then either could spend the money sent to that address.

Signatures are a fundamental part of blockchains. Similar to signing a check, cryptographic signatures determine which transactions are valid. Signatures are generated from a hash of data to be signed, and a private key.

Transaction hashes are highly visible in a blockchain. Instead of describing a transaction as “the transaction where Alice sent Bob X units of currency at date D and time T”, transactions are referred to by their hash. For example, 5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060 is a transaction in the Ethereum blockchain. Transaction hashes are also more direct to use, as compared to a description like the “1024th transaction in block 1337”. Just copy the hash, and paste it into a blockchain explorer, to see details of the transaction.

Metaphysically, blocks in a blockchain are identified by their hash, which serves the dual purpose of identification as well as integrity verification. An identification string that also provides its own integrity is called a self-certifying identifier.

For blockchains that use mining, the Proof-of-Work is a number, called a nonce, that when combined with other data and hashed, produces a value smaller than a specified target. Mining makes full use of the properties that hashing is fast one-way, and not reversible. Finding a valid nonce takes time because there are no clues available that will lead to a sufficiently small hash, and the only approach to find one that is smaller than the target, is to compute many hashes: in Bitcoin, currently that’s over 10 septillion hashes. When a valid nonce is found, verifying it is done within a second, and then the new block propagates across the network, forming the latest consensus and blockchain.

Since storage in blockchains is permanent, and storing large amounts of data on a blockchain is not economical, the practical way to store data on a blockchain is to store a fixed (and normally smaller) size representation of the data called the “hash of the data.” One use for a blockchain is as a timestamping service. Suppose there is a picture that you wanted to prove currently exists, and is not fabricated in the future. You could store the picture in the blockchain now, and a year later, if a judge asks if the picture was really taken a year ago, you could show it on the blockchain. But, since you know about hashes, you hash the picture and store the hash on the blockchain instead. When the judge asks for proof, you provide the picture, then the judge can hash the picture and compare it against the hash that you stored on the blockchain.

There are also more advanced examples where hashing is involved, for example in Merkle trees which are at the root of innovation for blockchains, scalability, and mobile and light wallets.

Hashes for identifying anything securely

Secure cryptographic hash functions are one-way, fast to compute, and collision resistant. Combined with the property that they process any type of input to produce an output of fixed-size, called a hash, hashes are very useful as an identifier for any data. Hashes of length 256 bits represent an astronomical number of combinations, that they are more than enough to be a globally unique identifier for the Internet of Things, even at the scale of nanotechnology and beyond. And these hashes can be written as 64 characters (hexadecimal), which make them practical enough to use as identifiers. In blockchains, hashes are used as identifiers for blocks, transactions, and addresses.

Hashes enjoy advantages of security and privacy. If a song is recorded in a digital format, and the hash of the song is stored on a blockchain, there is no way for someone else to claim that they were first to create the song that produced the hash, without knowing the song itself: someone can’t write a song and tamper with its hash. Similarly, unless the song or other digitized property or data is revealed, it remains private with only the hash displayed on the blockchain. Ownership registries can be stored on the blockchain, with the details of what’s owned remaining private among the parties involved. As a simple example, a vehicle registry could store hashes of car data (pictures, VIN, license plate) and only the owners, insurance company, and government would know the actual details of the vehicle.

Deeply theoretical but widely practical

Designing cryptographic hash functions require a combination of art and science. To prove their security requires advanced mathematics and computer science. Blockchains are the first user interfaces filled with hashes, available to a broad demographic. Good user experience will hide many hashes behind the scenes, but just as we see various id and serial numbers today, sometimes a hash is the best identifier for something instead of a long-winded description. As technology such as cryptography and the Internet of Things become widespread, expect to see 64 character hashes more in the future!

Graphics by Bogdan Burcea