Million Ether Homepage

Storing Colors in a Pixel Grid

Million Ether Page Essential Smart Contract

Tip: Mining only when there are transactions

Tip: Using Remix IDE

Getting Started

Getting The Pixels and Ethereum Events

Building a DApp UI

Drawing in HTML Canvas

Using Websockets with Web3

We don't need the checkBalance function anymore, so let's get rid of it.

Web3 and Events Over WebSockets

Drawing Pixels from the Blockchain

Viewing Pixels

The rest of the script can be found in `scripts/buy-pixels-001-read.js` below

Buying An Image -- Reading Pixels

Buying An Image -- Sending Transactions

Pixel bidding and structs

Payable Contracts, payable Functions

Contract Owner and require

Payable color pixel function

Buying Pixels

Sending funds from a contract

The safer way to send funds from a contract

Also note that any sort of math like this _should_ be checking for overflows, which we'll talk about later.

The Pull Payment Pattern - Withdraw payments when outbid

Million Ether Homepage Summary

Auctioning Pixels

solidity

In this course, we'll build a DApp inspired by [The Million Dollar Homepage](https://en.wikipedia.org/wiki/The_Million_Dollar_Homepage). We'll build a 1 million pixel page, and each pixel can be colored by placing the highest bid.

In this course we'll walk through every step of writing a smart contract, deploying it, hosting auctions, and connecting it to the browser through web3. 

If you're looking to build real, full-stack ethereum Dapps, then this is a perfectly-sized example.

We'll build a DApp inspired by the Million Dollar Homepage, powered by an auction on the Ethereum blockchain

There's one major constraint of EVM smart contracts that we've swept under the rug so far, and that is the issue of gas.

So far we've acted as if we have infinite ether and unlimited computing resources available to us. But in reality, this isn't the case.

When we write Solidity smart contracts, we're writing code that will be executed on someone else's computer. Actually, our code will be executed on thousands of computers.

We have to ask, what happens if we wrote malicious code? For example, what if we wrote code that went into an infinite loop and submitted it to the network? If every node on the network were to fall into an infinite loop, the entire Ethereum network would halt.

Could we analyze a program before we run it and check to see if it will terminate? As you probably already know, this is referred to as the halting problem, and the answer is "no". The halting problem is undecidable over turning-complete languages. 

The only way to tell if a program will finish is to run it. So what can we do?

The EVM gives resource constraints on our programs. Essentially, it costs you money (or Ether) to run any program. If you make your program run for a long time, you'll pay a lot of ether.

The constraint on running our programs is called 

. It can be a little confusing at first because it's both called gas and denominated in gas. That gas is a unit. Let me explain.

 our Solidity code. Each opcode costs a certain amount of gas to run. Some opcodes are cheap, like adding two numbers together, and some opcodes are very expensive, like storing data on the blockchain.

But the gas cost for each opcode is essentially fixed. It's always going to cost 3 gas to add two numbers together.

When we submit a transaction that calls a function on our smart contract, the sum total of all opcodes that run will be the sum total of our gas spent.

But, we don't pay in gas, we pay in Ether. So how do we convert between the two? Well, the miners decide the price per gas they'll accept. So for example, if the price is 5 wei per gas, and we add two numbers together (which costs 3 gas) then we'll pay 15 wei for that operation.

Say that I have a gas guzzling camper and I want to drive from L.A. to San Francisco. It is 374 miles, but let's round up to 400. My camper gets 10 miles to the gallon. It's 400 miles, so divided by 10 -- I will use 40 gallons of gas on my trip.

 for those gallons? Well, it depends on the price of gas. So let's say the price is the same at every gas station along the way and I pay $4/gal., so my cost is $160 dollars.

---
title: 'Gas'


slug: 'gas'
thumbnail: https://embed-ssl.wistia.com/deliveries/94c9a0ff05dc4b5e7034ff8037148e687974d283.jpg

privateVideoUrl: https://fullstack.wistia.com/medias/17z8s66plc
description: ""



---



There's one major constraint of EVM smart contracts that we've swept under the rug so far, and that is the issue of gas.

So far we've acted as if we have infinite ether and unlimited computing resources available to us. But in reality, this isn't the case.

When we write Solidity smart contracts, we're writing code that will be executed on someone else's computer. Actually, our code will be executed on thousands of computers.

We have to ask, what happens if we wrote malicious code? For example, what if we wrote code that went into an infinite loop and submitted it to the network? If every node on the network were to fall into an infinite loop, the entire Ethereum network would halt.

Could we analyze a program before we run it and check to see if it will terminate? As you probably already know, this is referred to as the halting problem, and the answer is "no". The halting problem is undecidable over turning-complete languages. 

The only way to tell if a program will finish is to run it. So what can we do?

The EVM gives resource constraints on our programs. Essentially, it costs you money (or Ether) to run any program. If you make your program run for a long time, you'll pay a lot of ether.

The constraint on running our programs is called `gas`. It can be a little confusing at first because it's both called gas and denominated in gas. That gas is a unit. Let me explain.

Remember that the EVM runs _bytecode_ operations, called opcodes, **not** our Solidity code. Each opcode costs a certain amount of gas to run. Some opcodes are cheap, like adding two numbers together, and some opcodes are very expensive, like storing data on the blockchain.

But the gas cost for each opcode is essentially fixed. It's always going to cost 3 gas to add two numbers together.

When we submit a transaction that calls a function on our smart contract, the sum total of all opcodes that run will be the sum total of our gas spent.

But, we don't pay in gas, we pay in Ether. So how do we convert between the two? Well, the miners decide the price per gas they'll accept. So for example, if the price is 5 wei per gas, and we add two numbers together (which costs 3 gas) then we'll pay 15 wei for that operation.

Maybe an analogy will help.

Say that I have a gas guzzling camper and I want to drive from L.A. to San Francisco. It is 374 miles, but let's round up to 400. My camper gets 10 miles to the gallon. It's 400 miles, so divided by 10 -- I will use 40 gallons of gas on my trip.

But how much will I _pay_ for those gallons? Well, it depends on the price of gas. So let's say the price is the same at every gas station along the way and I pay $4/gal., so my cost is $160 dollars.