Observations About The Crypto Dev Experience

It's been really fun learning about the crypto space while building Gravity and Middleman. As I've been working on these projects, I've been keeping a list of observations about what it's like to dev in the crypto space. 

Here is the list:

1. Wallets are a big barrier to entry. Most of the people who have visited gravity.cool did not have MetaMask or another browser wallet installed (for example if they visited from the mobile Twitter in-app browser). Some of them installed MetaMask, but then the process to initially set up MetaMask and transfer tokens to it can take over an hour, so ultimately it is too high a price to pay and the visitors drop off.
2. After users create or update their gravatar with Gravity, they sometimes wait more than 24 hours for the transaction to be processed on chain. That's super frustrating for users - they updated their gravatar, they expect to be able to see that it's updated.
3. For a web app to interact with a p2p network like IPFS, the web app needs to run a local IPFS node. This is a lot to ask for from developers, so instead developers point their web app to IPFS gateways like the one run by Infura. I am curious about the role network gateways will play in inter-network/inter-chain interoperability. 
4. I could not find an easy API for a developer to exchange one token to another. With existing exchange API's, if I want to send 1 ETH and get back the corresponding amount of FileCoin, I need to fetch recent ETH <> FileCoin trades, figure out what is the current exchange price, and then ask for an exchange at that price, and even then, it's not a guaranteed trade. This isn't impossible, but it's not the easy button I was hoping for. I think there is a big opportunity for whoever can build the dead simple swap API. 
5. Because this space deals with money, APIs that manage wallets or tokens can fall under the money transmitter regulation and need to do more regulatory work upfront to be able to operate in all 50 states. This costs $$$ to do all 50 states (it's hundreds of thousands of dollars in security deposits for each state), which means that there is a hurdle for small companies to start new projects and a moat for established institutions that have already jumped through these hoops or have the funds and staffing to do so.  
6. Like any new technology, there are lots of weird quirks in Solidity and the Web3 API where things do not work as they should. (A few examples: you cannot have a function in Solidity that has optional parameters, and there are pages of search results for why web3.getAccounts comes back empty even though the user is logged into their browser wallet).
7. This one is obvious but wow it is crazy that after deploying a smart contract I can no longer make changes to the code or add new features. 

👩‍🚀 Announcing Gravity

This weekend I built a tool called Gravity. The TLDR is that it's like Gravatar, but for Ethereum. If you want to skip ahead, you can go to gravity.cool and create your own Gravatar.  

Okay, more on Gravity:

Right now, it can be a bit intimidating to send ETH. Ethereum addresses are not human readable -- how do you know the address you've entered is the right one?

The goal with Gravity is to associate an avatar for every ethereum address so that sending ETH is as friendly as sending an email:

To create your Gravatar, you can go to gravity.cool. It's pretty easy, you just enter your name and upload an image to be your gravatar, you sign the transaction with MetaMask or whatever in-browser wallet you use, and poof! You're done.

On the backend, your gravatar is sent to the Gravatar Registry, a smart contract on the Ethereum blockchain. 

If you're a developer and you want to pull gravatars from Gravity to display in your app, it's less than 10 lines of code. Check it out, the full code you'd need is below:

// import and define web3
import web3 from 'web3'
web3 = new Web3(new Web3.providers.HttpProvider("https://mainnet.infura.io"));

// define the Gravity smart contract
let GravatarRegistryContract = web3.eth.contract( ... contract abi goes here ... );
let GravatarRegistry = GravatarRegistryContract.at('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC');

// get the current user's gravatar
GravatarRegistry.getGravatar(web3.eth.accounts[0], function(err, res) {
  if (res[0] !== " ") { 
     // user has a gravatar
    let gravatarName = res[0];
    let gravatarImage = res[1];
  }
})

Enjoy! Excited to hear what you think.

Planet Money Buys A CryptoKitty; Takes Them Over An Hour

In yesterday's episode of The Indicator, Planet Money’s Stacey Vanek Smith and Cardiff Garcia buy their first CryptoKitty. 

You can listen to the episode here. 

Just the first step of creating a Coinbase account and buying ETH took the two of them over an hour.

"It got really frustrating...all of this took more than an hour. We were totally wiped out." 

And that’s before having to figure out how to transfer their ETH to a browser wallet so that they could use it. 

The episode was a good reminder of the UX challenges we have yet to solve for crypto/dapps. 

There are two ways we could go about crypto UX: One is to make it easier to buy, hold and transfer tokens. The other is to hide tokens from non-technical users entirely, the same way that Gmail abstracts away SMTP from its users. 

I’m more excited about the latter path and it’s the path we’re pursuing with the Middleman API, that Bitski is pursuing with their SDK and that Loom is pursuing with Loom Vault. 

Crypto wallets are intimidating; I asked a few hundred people how long they think it would take them to setup a crypto wallet, and most think it will take them more than 2+ hours to get one setup. 

Needless to say, I am excited to see dapps abstract away crypto to onramp new users. 

🎉 Middleman: In Beta Today

Web3 should be really exciting for consumers: banking for the unbanked: financial tools that don’t discriminate, a right to vote and shape product roadmaps, freedom from lock-in, and real transparency into how systems work. But right now to use a web3 app, you need to be savvy and technical enough to find and setup a wallet, buy crypto and trade the tokens you bought for the tokens you need, and somehow securely manage private keys and seed phrases. This is a lot to ask. 

The same way that you don’t need to understand how a car works to drive it, you don’t need to understand how Advil works to take it, and you don’t need to understand how SMTP works to use Gmail, you shouldn’t need to understand how blockchain works in order to use a dapp. I think blockchains will hit their tipping point when users don’t even know that they are using one. 

To this end, I think we are going to see several abstraction tools emerge to help developers abstract away crypto for non-technical users. One that already exists today is Infura, which is an API for developers to connect to an Ethereum node in the cloud if a user doesn’t happen to run one locally. Infura now serves 6 billion requests a day and is included in over 15K pieces of code on Github. 

Today I’m releasing another abstraction tool to help developers onboard non-technical users: meet Middleman.  

Middleman lets developers spin up and connect to a virtual wallet in the case that a user doesn’t already have one. The Middleman API can do anything a web3 wallet can do, the only difference is that the wallet is hosted remotely and not in the user’s browser.  

Here is an example of how you would use Middleman to check if a user has a wallet installed and otherwise create one on their behalf:

import 'web3.js'

void async function() {
    // check if the user already has a wallet
    if (typeof web3 !== 'undefined') {
        let web3 = new Web3(web3.currentProvider)
    } else {
        // create a wallet with Middleman
        let wallet = await createWallet('user_id')
        web3 = new Web3(new Web3.providers.HttpProvider("https://mainnet.infura.io"))
    } 
}

async function createWallet(userId) {
    let wallet = await fetch('https://api.middleman.cx/wallets', {
        method: 'POST',
        headers: { 'X-Auth-Key': 'MY-AUTH-KEY' },
        data: { 'user_id': 'current_user_id_001' }
    })
    
    return wallet.json();
}

And then here is how you would use that wallet to send a transaction on behalf of a user:

let transaction = {
    "to": "0x8d3e809fbd258083a5ba004a527159da535c8aba",
    "value": 0.1,
    "gas": 2000000  
}

async function signTransaction(address, transaction) {
    
    let signedTransaction = await fetch(`https://api.middleman.cx/wallets/address/${address}/signTransaction`, {
        method: 'POST',
        headers: { 'X-Auth-Key': 'MY-AUTH-KEY' },
        data: { transaction }
    })
    
    return signedTransaction.json();
}

web3.sendSignedTransaction(signTransaction(address, transaction))

Middleman is in beta today. I can't wait for you to try it out, and if you do, let me know if there are features you’d like to see: I'm [email protected]

API docs are here: docs.middleman.cx

To get started go here: middleman.cx 

And if you want to try out the API without firing up a command line, you can login to the developer portal and take Middleman for a spin.  

🎉 Enjoy! Excited to hear what you think. 

Lite Mining

I’m oddly excited about solutions like CoinHive and Coda that make it feasible to mine cryptocurrencies from a light clients like browsers.

I think we are going to see a lot of distributed and light mining solutions crop up and that in a more mature web3 ecosystem much of the mining will be done on end users' devices. 

An example: imagine that the Evernote app mined EvernoteCoin (or FileCoin/Truebit/whatever Evernote is built on) in the background while you used the Evernote app. 

The benefits of this are three-fold: 

1. Evernote wouldn't have to compete against other distributed networks for miners’ hash power.
2. Both the security and throughput of the Evernote network would scale with the amount of Evernote users.
3. It’s an alternative to the ad-supported model: mining would give Evernote users a way to automatically pay back their Evernote bill and get to use the service for “free". 

The challenges are that:

1. Data and battery are scarce on end user devices and mining could deplete both.
2. Because most of the mining would be done by the main app client, this could be seen as more centralized.
3. Before hitting a critical mass of users, a network with only a few desktop and mobile miners could be more easily susceptible to 51% attacks by miners with powerful machines.

There are solutions to the above, such as only mining on devices plugged in with full battery, letting the user toggle mining on/off, allowing traditional mining pools as well as mining on end user devices, etc. 

I think we’ll start seeing this sooner rather than later. I am excited about it.

A Quick Primer on 5G

The basics:

There is an increasing need for mobile data (the amount of mobile data used in the US is up 4x since 2014 and 40x since 2010) but the existing spectrum doesn’t have enough bandwidth to support a lot of additional traffic. 5G will be on a new, uncongested spectrum at a higher frequency (higher frequency = the wavelength is shorter so signal travels faster).  

Existing mobile communication is commonly at 2.X GHz and mostly below 6 GHz, where wavelength is ~10 cm. 5G will be somewhere between 30-300 GHz where wavelength will be between 1-10 mm (called millimeter wave, written mmWave). The FCC’s current plan is to make available 2.75 GHz of spectrum in the 26 GHz (11 mm wavelength) and 42 GHz (7 mm wavelength) bands.

On a sunny day in rural Virgina, a mmWave at 73 GHz can travel more than 10 kilometers.  mmWave is very affected by obstacles such as buildings or rain (because the wavelength is shorter than traditional spectrum). In rain, the signal strength of a mmWave at 28 GHz halves every kilometer and at 73 GHz decreases 100x at every kilometer.

The answer to this is to have more cell stations that can transmit signal. There are currently ~320K cell sites in the US. This should increase for 5G to an estimated 1.2M. Small cells are roughly the size of a wi-fi router and may be installed both outdoors and indoors.

A 4G base station typically has 12 antenna: 4 receivers and 8 transmitters. Each antenna is about a meter long. 5G small cells will have ~100 antenna, each can be about 20 cm tall.

Today’s antennas broadcast transmissions in multiple directions, but with more antennas, this will become too much interference, so part of 5G is beamforming algorithms that determine the direction an antenna should send a signal towards. The dream scenario here is that engineers will be able to design signal processing algorithms that know exactly what direction to send a signal so that it bounces off walls and exactly ends up at the end user device.

The last part of 5G is Full Duplex which means that an end user device can transmit and receive signal on the same frequency at the same time. (The current system where a device can only do one at a time is called Half Duplex). To do this you need to design a circuit that both routes incoming and outgoing frequency around each other and cancels out the echo from incoming frequency. There’s been research about how to do this since the 1960’s and was finally done on a chip small enough to fit in a phone in 2016 at Columbia University. (That team started a company called MixComm to bring their circuit design to market).

What 5G does not address is the networking layer. One of the big questions last week at the RCN Wireless workshop was whether TCP was going to be a bottleneck in 5G mobile speeds. TCP was designed in the 1980’s for fixed wired machines and there are two challenges for mobile (John Graham-Cumming wrote a great blog post describing these in detail).

The first is that a TCP connection starts slowly and gradually transmits at higher rates until it finds the maximum speed it can transmit at (this process is called TCP slow start). The way TCP congestion control algorithms decide the max rate is by checking for packet loss. In a fixed, wired connection, packet loss is a good indicator of max speeds because is shows that a machine on the network had to drop packets to keep up with the inbound rate. In mobile, there are other reasons why packets would get lost that have nothing to do with speed, for example - driving through a tunnel. As one possible solution, Google has developed a new congestion control algorithm called BBR that uses RTT rather than packet loss as a measurement of latency.

The other problem for TCP on mobile is in packet reordering. A mobile phone moves around, so half of the packets of a TCP connection could be sent to one cell site and the other half to another. Then when the packets reach the end server they can be really out of order. TCP can deal with this, but wasn't designed for packet reordering at this magnitude and it adds some latency.

ERC-948

Most of the apps we interact with in web2 are subscription based (Gartner thinks 80% of apps will be subscription services by 2020), but subscriptions still aren’t possible in web3. Broadly there are two limitations:

1. Volatility: A user cannot agree to pay x tokens per month because the value of x tokens could vary wildly month to month.
2. User action: With ERC-20, a user would have to actively sign transactions every month in order to be charged for the monthly subscription.

What this means is that a decentralized Dropbox today wouldn’t be able to bill its users on a monthly fee. There is a hacky way to do it: a decentralized Dropbox could ask the user to put up a year’s worth of tokens into escrow and each month take some of the tokens out from escrow, but that’s not a great user experience. 

There are two projects working together towards a solution (ERC-948): Groundhog and 8x. Their solution (still in development) would theoretically create a new standard for smart contracts so that users could allow X tokens to be withdrawn from their wallet every Y time period by Z business and that would allow the user to cancel at any time. The goal is for this solution to be compatible with ETH and any ERC20 token. To solve for volatility, businesses could charge for their subscription using a stablecoin.

Once wallets and dapps have added support for one recurring payment standard, it will be extremely difficult to get them to add support for another one, so I consider this a Very Important Project in that it's important to get the standard right the first time. 

To contribute, join the conversation here https://github.com/ethereum/EIPs/issues/948 or make a PR here https://github.com/8xprotocol/standard/blob/8x-suggestions/standards/8x.md.
 

Request For Project: Standardized Wallet Protocol

The current state of the web3 world is such that:

Your browser has a wallet (Metamask).
Your mobile browser has a wallet (Toshi).
Your finance apps all have wallets (Coinbase, Robinhood, Square Cash).
And all of these wallets need to be separately topped up,
Which is kind of like having a different metro card for every line of the NYC subway.

And so my Request for Project is for a unifying wallet protocol.
That encompasses tokens and collectibles, as well as identity and account recovery.

So that if you buy a cryptokitty on your laptop, you can use it right away to play games on your phone.
And if you buy some ETH on Coinbase and then login to Square Cash, your ETH would be there.

Quite eager for this to exist.