Forem: Olivier

Time locked functions with Solidity

Olivier — Sun, 12 Mar 2023 19:15:59 +0000

Time locked functions in smart contracts with Solidity

You may know that access control is a pretty big deal in smart contracts development and might have heard of OpenZeppelin Ownable contract that provides a way to restrict function access to a single "owner" so that this user can perform administrative actions and whatnot, which is the go-to when it comes to access control in Solidity. Here we'll see how we can limit our users from calling a function again in a certain time span.

Basically, we want our users to only be able to call a given function once in a given period.
This could be useful to limit some actions in community driven applications.

Let's get to work! You can code along if you wish by cloning this repository.

Let's say you're a generous fellow and created a contract that allows anyone to call the withdraw function and get 0.1 ETH.
Now your friends heard about it and they're a bunch of jerks so they want to get all the ethers for themselves, therefore you decide to limit the withdraw function to one call a day by user.

Here is the contract we'll start with:

contract Vault {
    uint256 constant private _WITHDRAW_AMOUNT = 0.1 ether;

    function deposit() external payable { }

    function withdraw() external {
        require(
            address(this).balance >= _WITHDRAW_AMOUNT,
            "Insufficient funds"
        );

        _transferEth(msg.sender, _WITHDRAW_AMOUNT);
    }

    function _transferEth(address to, uint256 amount) private {
        (bool sent,) = to.call{value: amount}("");
        require(sent, "Transfer failed");
    }
}

We created a a payable deposit function so we can fund the contract, the remaining code is pretty straightforward, the withdraw function checks that the contract has enough funds before sending ethers to the caller.

Here are our test cases:

const Vault = artifacts.require('Vault')
const { expectRevert, time } = require('@openzeppelin/test-helpers')
const { web3 } = require('@openzeppelin/test-helpers/src/setup')
const { toWei } = web3.utils

contract('Vault', ([alice, bob]) => {
  let contract
  beforeEach(async () => {
    contract = await Vault.new()
    await contract.deposit({ from: alice, value: toWei('0.2', 'ether') })
  })

  it('should allow withdrawing', async () => {
    const withdraw = await contract.withdraw({ from: bob })

    expect(withdraw.receipt.status).to.be.true
  })

  it('should prevent from withdrawing again on the same day', async () => {
    await contract.withdraw({ from: bob })
    await time.increase(time.duration.hours(12))

    await expectRevert(contract.withdraw({ from: bob }), 'Account under timelock')
  })

  it('should allow another withdrawal the next day', async () => {
    await contract.withdraw({ from: bob })
    await time.increase(time.duration.hours(36))
    const lastWithdraw = await contract.withdraw({ from: bob })

    expect(lastWithdraw.receipt.status).to.be.true
  })
})

We deploy a new contract and fund it with 0.2 ETH before each test.
We use openzeppelin test-helpers to simulate the passing of time.
You can guess from the code the features we will implement:

Allowing a first withdrawal.
Preventing another withdrawal within a 24 hours timespan.
Allowing another withdrawal that happens more than 24 hours after the first one.

Let's start by adding a mapping that will keep track of the release time - at which point a user can call our function again - :

mapping(address => uint256) private _timestamps;

Now we need to update it in the withdraw function.
We add it at the end but before the _transferEth to avoid reentrancy vulnerabilities.
We set the release time for the caller to one day from now using block.timestamp - the current time - and the days unit providing the number of seconds for a given amount.

function withdraw() external {
    address caller = msg.sender;
    require(
        address(this).balance >= _WITHDRAW_AMOUNT,
        "Insufficient funds"
    );

    _timestamps[caller] = block.timestamp + 1 days;
    _transferEth(caller, _WITHDRAW_AMOUNT);
}

Note that we also added a caller variable as we'll use its value again later on.

Now that we have a record of the release time for a user, we can check it against the current time :

require(
    block.timestamp > _timestamps[caller],
    "Account under timelock"
);

If block.timestamp is greater than _timestamps[caller] then we've passed the release time, otherwise it is still ahead in the future.
If a user didn't call our function before then we've never set _timestamps for that address and _timestamps[caller]would equal the default value for an uint type: 0, therefore passing our require clause.

The withdraw function now looks like this:

function withdraw() external {
    address caller = msg.sender;
    require(
        block.timestamp > _timestamps[caller],
        "Account under timelock"
    );
    require(
        address(this).balance >= _WITHDRAW_AMOUNT,
        "Insufficient funds"
    );

    _timestamps[caller] = block.timestamp + 1 days;
    _transferEth(caller, _WITHDRAW_AMOUNT);
}

Let's run our tests with truffle test:

Contract: Vault
    ✔ should allow withdrawing
    ✔ should prevent from withdrawing again on the same day 
    ✔ should allow another withdrawal the next day

3 passing

Yeah, we did it!
But what if we wanted to share the same time lock with another function? We'd have to rewrite pretty much the same code in each functions, let's see how we can extract that logic to another contract and write a modifier.

abstract contract TimeLock {
    uint256 private _timeLockDuration;

    mapping(address => uint256) private _timestamps;

    constructor(uint256 timeLockDuration) {
        _timeLockDuration = timeLockDuration;
    }

    modifier timeLocked() {
        address caller = msg.sender;
        require(
            block.timestamp > _timestamps[caller],
            "TimeLock: Account under timelock"
        );
        _timestamps[caller] = block.timestamp + _timeLockDuration;
        _;
    }
}

We now set the duration in the constructor and made a modifier.
Let's update our Vault contract:

import "./TimeLock.sol";

contract Vault is TimeLock {
    uint256 constant private _WITHDRAW_AMOUNT = 0.1 ether;

    constructor() TimeLock(1 days) { }

    function deposit() external payable { }

    function withdraw() external timeLocked {
        require(
            address(this).balance >= _WITHDRAW_AMOUNT,
            "Insufficient funds"
        );

        _transferEth(msg.sender, _WITHDRAW_AMOUNT);
    }

    // [...]
}

We've changed a few things:

Import the TimeLock contract: import "./TimeLock.sol";
Inherit our new contract: contract Vault is TimeLock {
Initialize the lock duration in the constructor: constructor() TimeLock(1 days) { }
Add the modifier on the relevant function: function withdraw() external timeLocked {
We remove the _timestamps mapping as it is now declared in the TimeLock contract

Let's run our tests again, hopefully we didn't break anything :D

Contract: Vault
    ✔ should allow withdrawing
    ✔ should prevent from withdrawing again on the same day 
    ✔ should allow another withdrawal the next day

3 passing

There we have it! A clean way to control access to our functions with a modifier.
You can check the code on the final branch of the repository.
Hopefully you've learned a few things about smart contracts and Solidity :)
Be wary that block.timestamp can be manipulated by miners therefore you shouldn't rely on it for a duration under 15 minutes or for critical features.

By the way, if you ever encounter such a use case, you're welcome to check out the soliv library that contains a TimeLock and TimeLockGroups contract handling what we've seen with additional features ✌️

Passing your first Code Review

Olivier — Sun, 24 Nov 2019 19:13:09 +0000

As developers, we all know that code quality matters, or so most of us think. 🤷‍

If you've worked in a team, you probably got mad over a co-worker's code at some point and maybe you came across this quote by John Woods:

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”

You might have wished your co-worker had applied it.
Anyway it doesn't have to go this far but one thing that could really help get code to be clean enough to at least suits the team is code reviews.

Code reviews will reduce bugs in the long term, makes you more aware of what is going on in the project and improve your skills whether you are reviewing or the reviewee.

That is if you do them well :)

I've seen many people barely going over the code or just clicking the "Approve" button but I think you should really give it a chance if you're not already, it is worth it.

Anyway I will try to list the main "gotcha's" that makes me request change on a pull request in order to get cleaner and more readable code.

It will focus on front-end development and target junior developers, the examples will be in javascript.

Then again it's just my view on the subject so don't take it too seriously :)

The "Clean up after yourself"

So here the code is kinda like a table you all share to eat, you want to keep it clean for the others after you're done, so:
- Remove all your console.log
- Remove unused variables, functions... (IDEs can help you with that) We don't want that and it just clutters the code.
- Respect the team guidelines or linter if there is such. (Of course you can try to talk to those in charge if you think something should be updated) If not, try to stay consistent and don't do anything too weird.
Conditions

I often stumble upon unoptimized or redundant condition so:
Remove useless conditions

🚫 Do not

      function isAdmin(user) {
        if (user.roles.includes('ADMIN')) {
          return true;
        } else {
          return false;
        }
      }

✔️ Do

      function isAdmin(user) {
        return user.roles.includes('ADMIN');
      }

Merge if possible

🚫 Do not

      if (something()) {
        if(somethingElse()) {
          doThis();
        }
      }
      / **** /
      if (something()) {
        doThat();
      }
      else if (somethingElse()) {
        doThat();
      }

✔️ Do

      if (something() && somethingElse()) {
        doThis();
      }
      / **** /
      if (something() || somethingElse()) {
        doThat();
      }

Use else in that case, it will avoid checking both if in the process and it's more maintainable as the first condition could evolves

🚫 Do not

      if (something()) {
        doThis();
      }
      if (!something()) {
        doThat();
      }

✔️ Do

      if (something()) {
        doThis();
      } else {
        doThat();
      }

I don't see this one a lot but it has happenned 🙄

🚫 Do not

      if (something()) {
        // yes, an empty block
      } else {
        doThis();
      }

✔️ Do

      if (!something()) {
        doThis();
      }

Semantics
The art of naming things, code will be more read than written so:
Avoid one-letter variables (except in for loops), give variables meaningfull names after what they holds

🚫 Do not

       mails = users.map((u) => u.email);

✔️ Do

      usersMails = users.map((user) => user.email)

Name functions after what they really do, don't be scared to be verbose 🧐

🚫 Do not

      rgpd() {
        this.openModal(RgpdModalComponent);
      }

✔️ Do

    openRGPDModal() {
      this.openModal(RgpdModalComponent);
    }

DRY
For "Don't repeat yourself", basically "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". You can read more about it on Wikipedia, we'll only scratch the surface here. The next tips will make the code less error prone and easier to update.
Create a variable if you use a value more than once:

🚫 Do not

      function getCurrentPage() {
        return sessionStorage.getItem('homeTablePage');
      }

      function onPageChange(event) {
        sessionStorage.setItem('homeTablePage', String(event.index));
      }

✔️ Do

      const tablePageStorageKey = 'homeTablePage';

      function getCurrentPage() {
        return sessionStorage.getItem(tablePageStorageKey);
      }

      function onPageChange(event) {
        sessionStorage.setItem(tablePageStorageKey, String(event.index));
      }

On the same note, if you use several times the result of a function call, you should store it in a variable (assumnig your function is pure), it will also avoid useless function calls on the performance side:

🚫 Do not

    const userAnswer = prompt("Factorial of 7 ?");

    if(Number(userAnswer) !== factorial(7)) {
      alert(`Nop ! The factorial of 7 is ${factorial(7)}`)
    }

✔️ Do

    const answer = factorial(7);
    const userAnswer = prompt("Factorial of 7 ?");

    if(Number(userAnswer) !== answer) {
      alert(`Nop ! The factorial of 7 is ${answer}`)
    }

Use a function instead of a duplicate instruction in conditions:

🚫 Do not

      if(!(game.state.over || game.state.paused)) { /* ... */ }

      if(somethingElse() && !(game.state.over || game.state.paused)) { /* ... */ }

✔️ Do

    /* game */
    onGoing() {
      return !(this.state.over || this.state.paused);
    }
    /* ... */
    if(game.onGoing()) { /* ... */ }

    if(somethingElse() && game.onGoing()) { /* ... */ }

Misc.
Think about commenting your code. It will make it easier for you when you come back to it after a while but mostly helps your co-workers figure your codes out if you happen to write something not so straightforward.
Keep in mind that this could be a sign that your code should be cleaner though. Nonetheless, sometimes we write things that does not seems so intuitive although it's actually quite well done, comments tell us why.

✔️ Do

  keepOrder() {
    /* Keyvalue Pipe sorts by key by default
    this allows us to keep the orignal order */
    return 0;
  }

Favor functionnal programming. It will make the code cleaner.

🚫 Do not

  function getUserRolesLables(user) {
    let labels = "";
    for (let i=0; i<user.roles.length; i++) {
      labels += user.roles[i].label + " ";
    }
    return labels.trim();
  }

✔️ Do

  function getUserRolesLables(user) {
    return user.roles
    .map(role => role.label)
    .join(' ');
  }

There you go, I hope this can be useful :)

By the way, Remember to not take a denied pull-request the wrong way, see it as an opportunity to exchange and perhaps grow. This is also better than getting no feedback at all most of the time.

Happy coding

Forem: Olivier

Time locked functions with Solidity

Time locked functions in smart contracts with Solidity

Passing your first Code Review

The "Clean up after yourself"

Conditions

Semantics

DRY

Misc.