7 posts tagged with "web3"

My last blog post about Bit Magic generated some buzz amongst fellow EVM developers and some of them reached out to me to include additional things in my blog related to using bits effectively in Solidity and the EVM in general.

Convert address to uint and back​

This conversion exploits the fact that addresses take up 20 bytes and so does a uint160 (20 * 8).

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.7;

// The theory behind this is that addresses take up 20 bytes in a word which is equivalent to (20*8) 160 bits and hence should be correctly casted to and from uint160.

contract AddressToUint {

    address public targetAddress;
    uint256 public targetUint;

    function convertAddressToUint(address _targetAddress) external returns(uint256) {
        targetAddress = _targetAddress;
        targetUint = uint256(uint160(_targetAddress));
        return targetUint;
    }

    function convertUintToAddress(uint256 _targetUint) external returns(address) {
        targetUint = _targetUint;
        targetAddress = address(uint160(_targetUint));
        return targetAddress;
    }

}

// 0xabD0127D996A468A79a0a8e88F4D419E40402e95
// 980877587572537262620952019491558306941665029781

Function Types​

For official documentations follow this link.

So, in Solidity, you can pass functions themselves as parameters to other functions. These type of parameters are called function types.

These function types can be used to pass and return functions from function calls.

Example​

1. Format of function types is the following:​

function (<parameter types>) {internal | external} [pure | view | payable] [returns(<return types>)]

Note : Function types can only be internal or external. Also, the return types cannot be empty if the function in question does not return anything, in this case, completely omit the returns keyword.

Bitwise Operations​

Includes all basic bitwise operations such as and, or, xor, not, shiftLeft, shiftRight etc.

uint x;
uint y;

x & y // and
x | y // or
x ^ y // xor
~x    // not
x << y // shift x by y bits to the left
x >> y // shift x by y bits to the right

Code snippets depicting modern Solidity​

//SPDX-License-Identifier: MIT

pragma solidity 0.8.14;

contract ModernSolidityFeatures {
    TestContract tcInstance = new TestContract();

    function modernFunctionSelector() public view returns(bytes4) {
        return tcInstance.square.selector;
    }
    
    function modernIsContract(address addr) public view returns(bool) {
        return (addr.code.length > 0 ? true : false);
    }

    function conventionalIsContract(address addr) public view returns(bool) {
        uint32 sizeOfAddressCodeSection;
        assembly {
            sizeOfAddressCodeSection := extcodesize(addr)
        }   
        return (sizeOfAddressCodeSection > 0);
    }

    function conventionalFunctionSelector(string memory functionSignature) public pure returns(bytes4) {
        return bytes4(keccak256(bytes(functionSignature)));
    }
}

contract TestContract {
    uint256 public number;

    function square(uint256 a) public pure returns(uint256) {
        return a*a;
    } 
}

Let us see today when and why do we use abi.encode vs abi.encodePacked.

What is a hash function?​

A hash function has the following characterisitics:

• A function that takes in arbitrary size input and outputs a data of fixed size
• Properties:
  • Deterministic
    • hash(x) = h, every time without fail
  • quick to compute the hash
  • irreversible
    • given h, (really)hard to find x such that hash(x) = h
  • small change in input changes the output significantly
    • hard to find x, y such that hash(x) = hash(y)

The International Testing Standard (TITS) for DeFi​

Declaration Tweet.

Mission Statement​

I believe that protocols need to be held to a higher standard of testing. Web3 protocols are decentralised, therefore there are no centralised authorities, and subsequently there is no regulatory pressure on the protocols to do quality checks on their protocols.

Is this an issue?
YES
Is this a big issue?
YES

Why?

Well, because, speaking strictly from an economic perspective, it makes much more sense for a protocol to use its time and developer resources on shipping a v2 of their protocol once the initial set of smart contracts are coded rather than spending it on testing their protocol. The protocols presently, try to, conviniently shift the burden of testing and quality assurance on the auditing firms and sometimes on insurance firms. However, Auditing + Insurance is still not enough to offer the level of peace of mind that people should have on software that handles their money.

Therefore, the development team, that is the most intimately familar with the code base, must make it a sacred duty of theirs (just like doctors take the Hippocratic Oath) to test their code to the best of knowledge and ability.