Making The Draft

There was a nice piece of advice from one of the pro basketball players in the movie High Flying Bird, something along the lines of:

The worst thing a rookie can do when he makes the draft is think he’s made it. Take the pats on the back for a day then get to work.

So it’s time to get the head down, work hard, learn hard and lets see if I can help my team win the 🏆

(Photo by Isaiah Rustad on Unsplash)

Setting Up Testing – Typescript with Mocha/Chai

This is more a reminder post incase I ever have to do something like this again so its kind of boring!

For pure Javascript testing with Mocha/Chai:

$ yarn add mocha
$ yarn add chai

In package.json:

"scripts":{
    "test":"mocha"
}

Add a test dir:

$ mkdir test

Add first test file:

var expect  = require('chai').expect;
var request = require('request');

it('Main page content', function(done) {
    request('http://localhost:8080' , function(error, response, body) {
        expect(body).to.equal('Hello World');
        done();
    });
});

Now for Typescript:

$ yarn add typescript
$ yarn add ts-node --dev
$ yarn add @types/chai --dev
$ yarn add @types/mocha --dev

 Replace test script:

"test": "mocha -r ts-node/register test/*.spec.ts"

And make sure test is in root/test/example.spec.ts

import { expect, assert } from 'chai';
import 'mocha';
import { Pool } from '../src/types';
import { smartOrderRouter } from '../src/sor';
import { BigNumber } from '../src/utils/bignumber';
import { getSpotPrice, BONE } from '../src/helpers';

const errorDelta = 10 ** -8;

function calcRelativeDiff(expected: BigNumber, actual: BigNumber): BigNumber {
    return expected
        .minus(actual)
        .div(expected)
        .abs();
}

// These example pools are taken from python-SOR SOR_method_comparison.py
let balancers: Pool[] = [
    {
        id: '0x165021F95EFB42643E9c3d8677c3430795a29806',
        balanceIn: new BigNumber(1.341648768830377422).times(BONE),
        balanceOut: new BigNumber(84.610322835523687996).times(BONE),
        weightIn: new BigNumber(0.6666666666666666),
        weightOut: new BigNumber(0.3333333333333333),
        swapFee: new BigNumber(0.005).times(BONE),
    },
    {
        id: '0x31670617b85451E5E3813E50442Eed3ce3B68d19',
        balanceIn: new BigNumber(14.305796722007608821).times(BONE),
        balanceOut: new BigNumber(376.662367824920653194).times(BONE),
        weightIn: new BigNumber(0.6666666666666666),
        weightOut: new BigNumber(0.3333333333333333),
        swapFee: new BigNumber(0.000001).times(BONE),
    },
];

describe('Two Pool Tests', () => {
    it('should test spot price', () => {
        var sp1 = getSpotPrice(balancers[0]);
        var sp2 = getSpotPrice(balancers[1]);

        // Taken form python-SOR, SOR_method_comparison.py
        var sp1Expected = new BigNumber(7968240028251420);
        var sp2Expected = new BigNumber(18990231371439040);

        var relDif = calcRelativeDiff(sp1Expected, sp1);
        assert.isAtMost(
            relDif.toNumber(),
            errorDelta,
            'Spot Price Balancer 1 Incorrect'
        );

        relDif = calcRelativeDiff(sp2Expected, sp2);
        assert.isAtMost(
            relDif.toNumber(),
            errorDelta,
            'Spot Price Balancer 2 Incorrect'
        );
    });

    it('should test two pool SOR swap amounts', () => {
        var amountIn = new BigNumber(0.7).times(BONE);
        var swaps = smartOrderRouter(
            balancers,
            'swapExactIn',
            amountIn,
            10,
            new BigNumber(0)
        );

        // console.log(swaps[0].amount.div(BONE).toString())
        // console.log(swaps[1].amount.div(BONE).toString())
        assert.equal(swaps.length, 2, 'Should be two swaps for this example.');

        // Taken form python-SOR, SOR_method_comparison.py
        var expectedSwap1 = new BigNumber(635206783664651400);
        var relDif = calcRelativeDiff(expectedSwap1, swaps[0].amount);
        assert.isAtMost(relDif.toNumber(), errorDelta, 'First swap incorrect.');

        var expectedSwap2 = new BigNumber(64793216335348570);
        relDif = calcRelativeDiff(expectedSwap2, swaps[1].amount);
        assert.isAtMost(
            relDif.toNumber(),
            errorDelta,
            'Second swap incorrect.'
        );
    });

    it('should test two pool SOR swap amounts highestEpNotEnough False branch.', () => {
        var amountIn = new BigNumber(400).times(BONE);
        var swaps = smartOrderRouter(
            balancers,
            'swapExactIn',
            amountIn,
            10,
            new BigNumber(0)
        );

        // console.log(swaps[0].amount.div(BONE).toString())
        // console.log(swaps[1].amount.div(BONE).toString())
        assert.equal(swaps.length, 2, 'Should be two swaps for this example.');
        assert.equal(
            swaps[0].pool,
            '0x31670617b85451E5E3813E50442Eed3ce3B68d19',
            'First pool.'
        );
        assert.equal(
            swaps[1].pool,
            '0x165021F95EFB42643E9c3d8677c3430795a29806',
            'Second pool.'
        );

        // Taken form python-SOR, SOR_method_comparison.py with input changed to 400
        var expectedSwap1 = new BigNumber(326222020689680300000);
        var relDif = calcRelativeDiff(expectedSwap1, swaps[0].amount);
        assert.isAtMost(relDif.toNumber(), errorDelta, 'First swap incorrect.');

        var expectedSwap2 = new BigNumber(73777979310319780000);
        relDif = calcRelativeDiff(expectedSwap2, swaps[1].amount);
        assert.isAtMost(
            relDif.toNumber(),
            errorDelta,
            'Second swap incorrect.'
        );
    });

    // Check case mentioned in Discord
});

Photo by René Porter on Unsplash

Should I Stay Or Should I Go?

He who jumps into the void owes no explanation to those who stand and watch.

Jean-Luc Godard

Money vs satisfaction. The known vs the unknown. Safe(ish) vs safe. These are the kind of trade-offs that go through my mind when I evaluate whether to stay in my current job or not.

It’s all about the money, money, money – until it’s not! Getting paid reasonably well to work in an unsatisfactory environment isn’t enough.

So what is enough 🤔? There’s been some interesting information on this subject, most recently one that struck a chord was by Fred Wilson in his post What To Work On. A checklist of his suggestions are projects that:

  • Interests
  • Motivates
  • Inspires
  • Impactful

Realistically in my current role the last three no longer apply. The last could be a yes. The available options all appear to be a yes although there’s always the risk that the vision is different from the reality.

Some more advice to help zero in on specifics are from this post and include:

  • Do you know what you want to get out of the next chapter – mmmh, specifics are tricky! I think I’d like to build my knowledge and skills in the blockchain and development world. It’s also important to gain access to people and opportunities in this industry. A sketchy final goal is to do something myself some day.
  • What are your side constraints – Ideally I want to stay in my current location, remote work would be fine. I’d like to work with professional, inspirational people that are focused and knowledgeable and are willing to let me soak up as much as I can! Getting paid well would be a bonus but I will accept below market rates for the right opportunity.
  • How much risk will I take – I guess I’m pretty open to risk really. I would probably prefer a startup because there’s more opportunity to make an impact and learn. I’m also considering being a student. Joining a post product-market fit start-up that is already scaling rapidly is the advice but I don’t think there’s many of these available right now. One of my biggest risk fears is trading one bad for another! Another is being ‘all in’ on blockchain – what if it ALL goes tits up?! I don’t think either are big enough risks to emergency stop.

As I type it becomes clear – mentally I’m already gone! I just hope I ‘go’ to the right thing. How awesome, inspirational and cool is the below quote from Preston Van Loon – that sounds like the right thing to me!

We are strong believers in Ethereum for a major reason – it is a fully permissionless blockchain that allows anyone to build unstoppable, censorship-resistant applications. In the beginning, we were all independent software engineers that shared a passion for the Ethereum blockchain, searching for the best way to contribute to its future. Now, we work full time on making the next iteration of the Ethereum project a reality. The fact that such a story is allowed to happen is a testament to the Ethereum project’s meritocracy and its community. We love to code, and being able to wake up each morning and work on fun, challenging, and meaningful problems is one of the best things anyone in this field could ask for. This is the best possible time to shape the future of Ethereum, and we’re privileged to have the support of you all to do so.
We believe in code quality, maintainability, and good design, and tests as our key pillars over anything else. Additionally, we believe there is a lack of industry best practice and sound software design in Ethereum development. A lot of the pain eth1 suffered came from reinventing many key pieces of its architecture, such as a custom json-rpc, a completely new, custom p2p library, etc. instead of adopting practices present in industry for years. An open source project needs to have longevity, and having easy readability + great tests ensures new contributors can pick up where we left off and keep the project growing at the same pace. When building the infrastructure that will maintain a major, multi-billion dollar project, every line of code we write must be considered with great care and consideration. Protocol development for Ethereum should be the opposite of what “hackathon”-style code looks like, and more importantly, we believe every developer should spend twice as much time reviewing code as writing it. We see many other projects write code that is really clever at the cost of being unintelligible to most, and that goes against our ethos. We chose Go because it is a language that prefers being clear and simple over being witty and complex, and Go as a language resonates well with our philosophy towards software engineering. Every time someone aims to make some code more clever or “concise” using fancy tricks or attempting to cram key logic into as few lines of code as possible, we avoid doing the same, as that’s not what good software should be about.
Ethereum 2.0 will eventually just be Ethereum, otherwise, the entire effort would have failed massively! We definitely see ourselves as a key team within the Ethereum community, building important tooling and infrastructure for its users, companies, and dApps building on the protocol. We have a responsibility to increase its adoption and keep improving the project over time. We believe Ethereum will keep creating a lot more valuable projects on top of it, and perhaps in the future we will create our own product on top of Ethereum itself, but with the key goal of always furthering its vision.

EthFinanace AMA Series with Prysmatic Labs

🤓 Geeking Out On Uniswap 🦄

Uniswap is a simple smart contract interface for swapping ERC20 tokens and in general it’s pretty awesome. The story behind it is really inspirational to me and just recently Hayden Adams tweeted that $10million of liquidity was added in a 24 hour period – surely pretty succesful by any measure!

Some of the features of Uniswap include:

  • Supplies on-chain liquidity to other smart contracts
  • Ease of use
  • Gas efficiency (10x less than Bancor)
  • Decentralised/censorship resistant

And just as a reminder:

Liquidity describes the degree to which an asset or security can be quickly bought or sold in the market at a price reflecting its intrinsic value.

Investopedia

Each Uniswap pool holds Eth and another token and trades are exectuted against these reserves.

By supplying tokens to the pooled reserve (being a liquidity provider) you get a proportional share of transaction fees via a liquidity token.

Prices are set automatically using eqn: x * y = k or in terms of tokens: eth_pool * token_pool = invariant.

The invariant is constant during trades but DOES change when liquidity is added or removed from pool. (So not really an invariant?!)

Liquidity Tokens

Liquidity tokens are minted to track the relative proportion of total reserves that each liquidity provider has supplied.

Fees are taken during a token swap and are added to the liquidity reserves. Since total reserves are increased without adding any additional share tokens, this increases that value of all liquidity tokens equally. This functions as a payout to liquidity providers that can be collected by burning shares. (It’s also the reason that the invariant increases at the end of every trade)

When a liquidity provider joins the pool the amount of liquidity tokens minted are calcualted by:

(Initial pool liquidity is equal to initial Eth value provided)
total_liquidity = self.totalSupply
eth_reserve = self.balance - msg.value
liquidity_minted = msg.value * total_liquidity / eth_reserve

Liqudity tokens can be burned at any time to return a proportional share of the markets liquidity to the provider:

removeLiquidity(amount...):

total_liquidity = self.totalSupply
token_reserve = self.token.balanceOf(self)
eth_amount = amount * self.balance / total_liquidity
token_amount = amount * token_reserve / total_liquidity

self.balances[msg.sender] -= amount
self.totalSupply = total_liquidity - amount
send(msg.sender, eth_amount)
return eth_amount, token_amount

Exchanging

Eth -> Token: Traders Eth is added to pool and Token is removed. So Eth amount increases, token amount decreases. Token becomes more expensive.

Token -> Eth: Traders Token is added to pool and Eth is removed. So Eth amount decreases, token amound decreases. Eth becomes more expensive.

Arbitrage

Arbitrage seems to be the key to so many DeFi applications! I think the following is nice description of what it is:

Arbitrage trading is a strategy that can be best understood as a trader that takes advantage of the price differential that exists between two markets. In the case of cryptocurrency, this price differential can be found in the differences in price of a digital asset between cryptocurrency exchanges. If a trader identified an opportunity for arbitrage trading, then they would purchase a digital asset in one exchange, and then sell it on another cryptocurrency exchange.

Mycryptopedia

To me it’s all about icentives – basically in the form of greed! There’s always someone looking to make money from an opportunity. In this case they execute a trade to make a profit but by making they trade they change the price which basically corrects it to the market price – that’s cool!

For example:

  • the global price of ETH-USD moves enough away from the pool price, an arbitrage opportunity exists and is corrected
  • When the initial liquidity is provided the exchange rate is set. If the ratio of liquidity provided isn’t realistic arbitrage traders will correct at the expense of initial liquidity provider.

Some Examples With Numbers

Invariant is set on initial deposit to a new pool. For example 10 ETH and 500 FUN are deposited into new ETH/FUN pool. Invariant is set to:

ETH_pool * FUN_pool = invariant
10 * 500 = 5000

Now for an ETH -> FUN trade:

Buyer sends 1ETH

Fee = 1 ETH / 400 = 0.0025 ETH (0.25% fee)

ETH_pool = 10 + 1 - 0.0025 = 10.9975

FUN_pool = 5000/10.9975 = 454.65 (invariant/ETH_pool)

Buyer receives: 500 - 454.65 = 45.35 FUN

Fee is added back to pool:

ETH_pool = 10.9975 + 0.0025 = 11

FUN_pool = 454.65

New invariant = 11 * 454.65 = 5001.15

Executed price = 45.35 FUN/ETH

But now price has changed:

Fee = 0.0025 ETH
ETH_pool = 11.9975
FUN_pool = 5001.15/11.9975 = 416.85
Buyer receives: 454.65 - 416.85 = 37.8

Executed price = 37.8 FUN/ETH

Price Slippage

Price slippage refers to the difference between the expected price before a transaction is executed and the actual price at which it is executed.

Bancor Support

Easiest for me to think of spot price and actual price.

A trade that is large relative to the size of the total size of the liquidity pool will cause price slippage.

Same example as above: 
ETH_pool * FUN_pool = invariant
10 * 500 = 5000

Spot price for ETH -> FUN = 500/10 = 50

1ETH Purchase: Executed price = 45.35 FUN/ETH

10ETH Purchase: Executed price = 24.969 FUN/ETH

Fee = 10 ETH / 400 = 0.025 ETH (0.25% fee)

ETH_pool = 10 + 10 - 0.025 = 19.975

FUN_pool = 5000/19.975 = 250.31

Buyer receives: 500 - 250.31 = 249.69 FUN

Fee is added back to pool:

ETH_pool = 19.975 + 0.025 = 20

FUN_pool = 250.31

New invariant = 20 * 250.31 = 5006.2

Executed price = 24.969 FUN/ETH

Final Thought

I found this comment from Vitalik on this EthResearch post interesting:

The point is not for this kind of exchange to be the only exchange; the point is for it to be one type among many. It offers the benefits of executing a complete trade in one transaction, and extreme user-friendliness even to smart contracts, which are very real benefits and will at least sometimes exceed the costs of slippage to some users. I am ok with just accepting that this kind of approach will not be acceptable to whales who want to liquidate large amounts of things; that’s not the target market.

(A lot of this stuff came from the Uniswap White paper. Photo by James Lee on Unsplash)

Solidity – How To Estimate Gas Costs

I’ve been working on optimizing the gas cost for deploying a smart contract. Turns out truffle has some pretty useful ways of estimating gas used.

Good Old Migrate

The most obvious way is to just run $ truffle migrate and see what the output says. When the project has quite a large build this can take some time so it’s not that efficient for seeing the difference some code changes make. I do find it useful to run this every now and again though just to confirm the estimates are correct.

estimateGas()

The other way I found useful is to use the estimateGas function. As is pretty self explanatory it is just an estimate and could change depending on the contract state. I found this was nice and quick to use on a truffle cli and I found two useful estimations to look at:

Contract deployment

Start the local ganache with a large gas limit:

$ ganache-cli --gasLimit 10000000 --allowUnlimitedContractSize

Start a truffle cli that connects to above chain:

$ truffle console

Estimate gas for deploying your contract:

truffle(develop)> YourContract.new.estimateGas()

Calling Contract Method

Start with the same set-up steps as above. Then:

truffle(develop)>  YourContract.testMethod.estimateGas()

And that’s it – another useful trick!

Migrating SAI to DAI

I was using Dharma.io to earn interest on my SAI (formerly DAI). I found Dharma really nice to use and originally offered a good interest rate. Recently the rate had become less competitive and I was getting concerned (maybe unneccesarily?) about the lack of comms about migrating the SAI to DAI so I decided to take matters into my own hands especially now that the DAI Savings Rate has kicked in.

When I swapped I was getting 3.22% for SAI on Dharma.io. The DAI savings rate is 4% and looks like it might get raised to 6% soon so definitely worth the swap.

  1. Visit https://migrate.makerdao.com/
  2. Unlock SAI. This calls the approve function for the token. (Nice explanation here.)
  3. This had a gas cost of 0.002637ETH, $0.35.
  4. That was it – once I checked my account I could see DAI.
  5. Not to earn some interest.
  6. Click earn savings. This navigates to https://oasis.app/save.
  7. Deploy Proxy – Setting up your proxy will bundle multiple transactions into one, saving transaction time and gas costs. This only has to be done once.
  8. Gas cost: 0.007344ETH, $0.97
  9. Now wait for 10 confirmations.
  10. Approve Oasis for DAI.
  11. 0.00055ETH, $0.07
  12. Finally deposit the DAI.
  13. 0.002713ETH, $0.36

Total cost $1.75. And now it’s quite satisfying to watch my depost earn interest in real time!

(Photo by Fabian Blank on Unsplash)

TypeScript 1 – Getting Going & Migrating

I’m currently working on the Burner Signal project. So far I’ve created the React app that will hopefully be used as the proof of concept.

One problem – so far I’ve done everything in pure Javascript but there’s a strong desire to use TypeScript only.

Oh and another problem – I haven’t developed with TypeScript before! 🤔😂

But…this is a perfect opportunity to learn something new especially as the best way to learn something is to actually build something with it.

So after a bit of reading I do get what the proposed benefits of TypeScript are:

  • Because it uses Types and it transpiles to Javascript the compiler can catch errors – I can definitely see the benefits in this!
  • Using Types is a kind of self documentation
  • IDE integration – dev environments provide lots of TypeScript support which should make it more efficient and faster to develop

I will give it a shot and see if the above is true!

The first thing I need to do is get my current create-react-app which is using pure Javascript migrated to use TypeScript. It was surprisingly easy!

  1. yarn add typescript @types/node @types/react @types/react-dom @types/jest
  2. Change an existing .js file to use .jsx
  3. Restart server – this is important!
  4. That’s it!

Now to learn the basics of TypeScript. For this I’m using the React-TypeScript Cheatsheet and the first suggestion is to get familiar with TypeScript by following 2alitys guide which I’m working through next.

🎉✨🔥 Winner Winner! 🔥✨🎉

Well this is cool – I won the Gitcoin x Aave Hackathon!

My entry was a bot that does arbitrage between two Uniswap exchanges using an Aave Flashloan as the capital for initial trade. The Aave judges were “super impressed” with my work and I got a special mention for the way I overcame a testnet problem by forking UniSwap and customising the code to allow two trading between two exchanges with the same token.

Happy days!

Note – Deploying A Contract Via A Delegate With Truffle Set-Up

This is quite random but I had to learn a few things so worth taking note.

I was recently working on a Truffle Dapp. I had to deploy one of my contracts in a roundabout way – basically one account signing it but another paying the gas (Metatransactions are basically the same). I’d never done this before. After that I still wanted my Truffle Dapp to be able to access the deployed contract but this required a bit of a tweak. So here’s how I did it.

Deploying Via A Delegate

This was done using a simple node script and the process looks like this:

  • Unlock your ‘sender’ account and ‘delegate’ account
  • Compile the smart contract to get the bytecode
    • In this case I used Truffle to compile and accessed the bytecode from the artificat file
  • Create a transaction object with the bytecode as the call data
  • Sender signs the transaction object
  • Delegate sends the signed transaction
  • Note the receipt so you have access to the deployed contract address

I’ve included the code I used for this below.

Using Truffle With The Deployed Contract

Because the contract was deployed using the script the Truffle artificats, etc don’t have the required information so my Dapp couldn’t interact. By making a few manual changes I managed to get it to work:

  • Make sure your contract has been compiled previously using Truffle it should have an artifact file.
  • Find your Truffle artificat file for the contract. It should be of form YouContract.json and is probably under a ‘contract’ folder in your Dapps project.
  • Find the “networks” section of the artificact.
  • Add a new network entry with the following info:
    • Network ID – should be the network that you deployed to.
    • Address – The address your contract was deployed to (from the receipt)
    • TransactionHash – I don’t think this is actually required but it was handy to record it.
    • My entry is shown in the gist below.
  • That’s it! Your Dapp should now work with the deployed contract.

Code Gist

https://gist.github.com/johngrantuk/453de92c28bfae6848ebe13e3e62c74f

Photo by David Travis on Unsplash

NuCypher & Proxy Re-encryption

Photo by Joshua Sortino on Unsplash

 

In April I entered (and won!) the NuCypher+CoinList hackathon. I didn’t actually know much about the NuCypher tech before I got started but once I had built my DApp it was clear this is really interesting stuff and it’s stuck with me ever since as something interesting to build on.

Proxy Re-encryption

The NuCypher solution will eventually provide a decentralised privacy infrastructure but during the hackathon I was mainly making use of a subset of the tech, Proxy Re-encryption.

Proxy re-encryption is a set of encryption algorithms that allow you to transform encrypted data. Specifically… it allows you to re-encrypt data — so you have data that’s encrypted under one set of keys, you can re-encrypt the data without de-encrypting it first, so that now it’s encrypted under a second, different set of keys —NuCypher co-founder MacLane Wilkison

So What?

To understand why this is pretty awesome imagine I have some encrypted data I want to share with Bob, what are the options to do this?

Crazy way – I just give me private encryption key to Bob (who I’m sharing the data with) who can use it to decrypt the data. But now Bob has my key and who knows where this ends up.

Inefficient way – I decrypt the encrypted data then rencrypt it using Bobs public key. This is more secure for sure but I have to do a lot more work. What if I have to do this many times? What if the encrypted data is stored and accessed over a network? Hows the information all being shared? Intensive!

How about the Proxy Re-encryption way:

With Proxy Re-encryption I encrypt the data once.

The encrypted data can be stored anywhere — Amazon, Dropbox, IPFS, etc. I only need to upload it once and provide access to the Proxy service (eventually this will be a NuCypher decentralised service)

The Proxy can rencrypt the data for anyone else I choose (provided I have their public key) efficiently and without ever having access to the decrypted data.

Bob decrypts the data using his own key and resources.

If the data I’m sharing is a stream, i.e. a Twitter feed, then I can enable/revoke decryption access whenever I want — i.e. I can stop someone seeing the data.

NuCypher will eventually provide a decentralised privacy infrastructure which will replace a centralized proxy with a decentralized network. A really good overview of the NuCypher solution is here.

Combine all this with decentralised smart contract as a source of access — very cool!

My DApp — thisfeedisalwaysforsale

My DApp was innspired by Simon de la Rouvieres This Artwork Is Always On Sale where he implements a Harberger Tax on the ownership of a digital artwork. In my app, instead of an artwork, access to a feed of data is always for sale. NuCypher is used to encrypt the data and only the current Patron can decrypt (using NuCypher) to get access. Anyone can buy this access from the current Patron for the sale price set when they took ownership. Whilst they hold ownership they pay a 5% fee to the feed owner. In the demo app the data is a Twitter like feed but the concept could be extended to have more than one Patron and could also be used for other kinds of feed data such as sensor data, camera/video feeds, music, etc.

I was super happy to get a mention in Token Economy as Stefanos favourite entry!