MultiMerkleMine Contract

[dob]

Currently, the MerkleMine smart contract allows the caller to generate a single proof for a single recipient in the generate() transaction. This issue is about creating a new convenience smart contract called the MultiMerkleMine which allows a caller to submit many proofs for many accounts in a single transaction. This allows a MerkleMiner to more efficiently generate token on unclaimed accounts while saving on gas.

Description

The MultiMerkleMine contract is purely a convenience wrapper around an existing MerkleMine contract deployed on the blockchain.

• It contains no state of its own, and purely provides convenience methods for invoking the generate() function on an existing MerkleMine contract.
• It receives as input an existing MerkleMine contract, an array of recipient addresses, and an array of MerkleProofs.
• It generates token by calling the generate() function on the MerkleMine contract once for each unclaimed input recipient address/proof pair.
• It transfers generated token to the caller.

MultiMerkleMine Spec

Constructor

function MultiMerkleMine() public

takes no arguments, as the contract stores no state

Public functions

function multiGenerate(address _merkleMineContract, address[] _recipients, bytes[] _merkleProofs) external

/**
 * 1. Perform validations:
 *   - length of _recipients == length of _merkleProofs
 *   
 * 2. The input _merkleMineContract address is the MerkleMine contract that this function will be interacting with. Record the MerkleMine token balance for this contract at the start of this function. During this function's execution, this contract's token balance will increase as it generates token, so we'll want to observe how much we generated later, so it can be transferred to the caller.
 * 
 * 3. For each input _recipient and _merkleProof pair (by given index i):
 * .    - check if MerkleMine contract generated[_recipients[i] == false. If so, call MerkleMine.generate(_recipients[i], _merkleProofs[i])
 * 
 * 4. At the completion of all the calls to generate, check the new balance of the MerkleMine token for this contract. This new balance minus the original balance is equal to the total newly generated token that the caller deserves. Transfer this balance to msg.sender.
 * 
 */

Tests

Please write tests to cover the following cases:

• Transaction should throw if _recipients length is not equal to the _merkleProofs length.
• msg.sender's new token balance is correct after passing in a full set of valid recipients and proofs.
• msg.sender's new token balance is correct after passing in a set of recipients and proofs that contain some recipients where generated[recipient] returns true. (Essentially this function should be resilient to generate token for the valid recipients where possible without failing the entire transaction).
• If there is an existing token balance for this contract, the msg.sender can only receive what they generated, and not steal any existing token from the contract.
• transaction throws if called before the MerkleMine.callerAllocationStartBlock (should happen transparently via the MerkleMine contract).

Additional implementation details

• Please use SafeMath library when performing arithmetic operations.
• Look at the existing tests for use of the MerkleTree library to easily generate the data for test accounts and accompanying root + proofs.
• Note that this txn will only work after the MerkleMine.callerAllocationStartBlock. It is debateable whether this validation should be included or not, since the MerkleMine contract will just throw anyway early on if this time period has not begun. But keep in mind during testing that the current block needs to exceed the callerAllocationStartBlock for the submited proofs to actually validate.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 0.5 ETH (233.56 USD @ $467.11/ETH) attached to it.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $18,182.37 more funded OSS Work available on the Gitcoin Issue Explorer

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work has been started.

These users each claimed they can complete the work by 11 months, 3 weeks from now. Please review their questions below:

1. vyomshm has started work.
   • Q: I've started working on this and will let you know if I have any more questions.

Q) So, the callerTokenAmount worth of newly generated tokens will then first be transferred to directly called MultiMinerMine contract, which will then forward it to the original msg.sender ?

[dob]

Q) So, the callerTokenAmount worth of newly generated tokens will then first be transferred to directly called MultiMinerMine contract, which will then forward it to the original msg.sender ?

I believe so. If the user calls the MerkleMine generate contract directly, they are msg.sender in the context, and the callerTokenAmount gets transfered to them. But in this case, since the MultiMerkleMine contract is going to invoke the MerkleMine.generate() function, I believe msg.sender will appear to MerkleMine to be the MultiMerkleMine contract itself. Which then needs to forward the token to the original caller. There may be other patterns to consider such as delegatecall, but I think the recommended path is the most straightforward.

Open to other suggestions to get the token to the original caller though, @vyomshm, if you have a recommendation, as that is the goal.

[yondonfu]

It would be nice to use the latest Solidity version (currently v0.4.24). The more recent versions of Solidity introduce the constructor keyword which could be used instead of a named constructor function like function MultiMerkleMine() public in addition to the ability to attach a reason string when reverting either with the require or revert statements.

One thing to look out for is that as of Solidity v0.4.24, dynamic arrays of dynamic arrays parameters i.e. string[] and bytes[] are not supported by default. Some options to possibly consider here include:

• Activating the experimental ABI encoder by adding the pragma statement pragma experimental ABIEncoderV2
• In multiGenerate(), change bytes[] _merkleProofs to bytes _merkleProofs and include an additional parameter uint256[] _sizes in multiGenerate where _sizes[i] is the size of the ith Merkle proof. multiGenerate() would use the values in _sizes array to parse out each individual proof in _merkleProofs
• In multiGenerate(), change bytes[] _merkleProofs to bytes _merkleProofs. The client can construct _merkleProofs off-chain with the following format: [proof_1_size, proof_1, proof_2_size, proof_2, ... , proof_n_size, proof_n]. multiGenerate() would read the size of proof 1 in the first byte of _merkleProofs, parse proof 1 from the next proof_1_size bytes, read the size of proof 2 in the next byte, parse proof 2 from the next proof_2_size bytes, and so on.

IMO option 3 seems appealing and doesn't require using an experimental compiler feature, but open to other thoughts here too!

[gitcoinbot]

@vyomshm Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

• [x] warning (3 days)
• [ ] escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

[dob]

@vyomshm are you still working on this? If not then I'd like to release it to someone else. Thanks, and let me know if you have any questions.

[vyomshm]

@dob @yondonfu

Yes, I'm still working on this.

Here's my current implementation of MultiMerkleMine.sol -

pragma solidity ^0.4.24;

import "./MerkleMine.sol";
import "zeppelin-solidity/contracts/token/ERC20/ERC20.sol";
import "zeppelin-solidity/contracts/math/SafeMath.sol";

contract MultiMerkleMine {

    using SafeMath for uint256;

    bytes[] private _proofs;

    event AlreadyGenerated(address indexed recipient, address indexed caller);

    function extractProofs(bytes _merkleProofs) internal returns(bytes[]) {
        require(_merkleProofs.length != 0, 'No proofs supplied!');
        for(uint256 i=0; i<_merkleProofs.length; i++){
            uint256 proofSize = uint256(_merkleProofs[i]);
            require(proofSize % 32 == 0, 'Invalid proof detected!');
            bytes memory _proof = new bytes(proofSize);
            uint256 j = 0;
            while(j<proofSize){
                _proof[j]=_merkleProofs[i+1];
                i+=1;
                j+=1;
            }
            _proofs.push(_proof);
        }

        return _proofs;
    }

    function multiGenerate(address _merkleMineContract, address[] _recipients, bytes _merkleProofs) public {
        MerkleMine mine = MerkleMine(_merkleMineContract);
        ERC20 token = ERC20(mine.token());

        require (block.number >= mine.callerAllocationStartBlock());

        uint256 initialBalance = token.balanceOf(this);
        bytes[] memory proofs = extractProofs(_merkleProofs);

        require(proofs.length == _recipients.length, 'Number of recipients and proofs is not equal!');

        for(uint256 i=0; i < _recipients.length; i++){
            if(!mine.generated(_recipients[i])){
                mine.generate(_recipients[i], proofs[i]);
            }else{
                emit AlreadyGenerated(_recipients[i], msg.sender);
            }
        }

        uint256 newBalanceSinceAllocation = token.balanceOf(this);
        uint256 callerTokensGenerated = newBalanceSinceAllocation.sub(initialBalance);

        if(callerTokensGenerated > 0){
            token.transfer(msg.sender, callerTokensGenerated);
        }

        delete _proofs;
    }

}

I didn't want to end up using the experimental compiler for implementing this, so I went with @yondonfu 's suggestion. This implementation passes all the required tests but does include a storage variable! i'm still working on an alternative way to do this.

[vyomshm]

15

[vyomshm]

15 So I've updated the MultiMerkleMine contract so that it uses assembly to extract proofs using a BytesUtil library. Also it no longer has that bytes[] storage _proofs array and everything happens in memory.

[dob]

Closed via #15

[dob]

@vyomshm I'm trying to pay out the Gitcoin bounty, but it looks like it's still in "work started" phase. If you can mark it as work submitted, then I think I can pay it out.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work for 0.5 ETH (233.25 USD @ $466.5/ETH) has been submitted by:

1. @vyomshm
2. @vyomshm

@dob please take a look at the submitted work:

• PR by @vyomshm
• PR by @vyomshm

---

• Learn more on the Gitcoin Issue Details page
• Questions? Checkout Gitcoin Help or the Gitcoin Slack $28,819.99 more funded OSS Work available on the Gitcoin Issue Explorer

[vyomshm]

Yeah, sorry about that. I just did so, should be working now.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

The funding of 0.5 ETH (233.25 USD @ $466.5/ETH) attached to this issue has been approved & issued to @vyomshm.

• Learn more at on the Gitcoin Issue Details page
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $28,586.74 more funded OSS Work available on the Gitcoin Issue Explorer