Implement necessary function utilities for massive-migrations:

• compute set-idx circuit hash public input
• add method to RollupDB to retrieve i¡account info leaf given its idx and batch number

• add data-availability when processing L1 transactions
• apply nullifyAmount in L1 transactions in its data-availability
• process L1tx then L2Tx then L2NopTx

Please, check new specification in the following link
Also, check circuit issue regarding this topic here

Overview changes

• update state-utils.js: add new fields exitBalance and accumulateHash
• update batch-builder.js: remove exit-tree. Add logic to add exits to exitBalance and compute accumulatedHash
• update rollupDB.js: remove storage exit-tree, ability to retrieve new exit information

• remove processor insert when checking tokenID2 for on-chain transactions

Check feature in this issue

Overview changes

• add utils-multi-token-withdraw.js functions to properly retrieve data to be used when using this feature

Initial value for feePlanTokens is an empty array initialized with 0 values. This leads to compute accumulated fees for tokenID = 0 even if the fee is not going to be recollected.
In order to NOT accumulate unnecessary fees, feePlanTokens could be initialized with a tokenID values that do not accumulate fees.
tokenID = 2^32 - 1 could be used since this would be a tokenID not used in the rollup unless 2**32 - 1 tokens are added which is not currently feasible.

this.feePlanTokens = Array(this.totalFeeTransactions).fill(2**32 - 1);

Check this issue for more details

Overview changes

• update withdraw-utils.js to match new specification

• feature/upgrade-v1
  • contains all the necessary code that implements new features in rollup v1
• feature/massive-migrations
  • contains code to perform massive-migrations

I think after we have everytihng coded for upgrade-v1, we need to rebase feature/massive-migrations into feature/upgrade-v1 and adpat it. Afterward, we can continue code masisve-migration to feature/massive-migration branch

Feature goal

The aim of this protocol feature is to allow the user to sent all his current balance on L1 transactions.

Specification

• batch-builder should detect when processing a L1 transaction and its amount signed. If amount signed is MAX_AMOUNT_F = 0xFFFFFFFFFF the current balance account is taken from transfer
• zk-inputs should update new balance of the receiver accordingly

related to hermeznetwork/circuits#32

Issue

Since in transferToEthAddr or transferToBjj the toIdx signed is IDX 0, it does not provide enough information as data-availability to reconstruct the state tree

Fix

Therefore auxToIdx must be included on data availability on L2 transactions of type transferToEthAddr or transferToBjj instead of toIdx

• add new field for each transaction maxNumBatch
• update L2 signature(add maxNumBatch) , hashGlobalInput(add currentNumBatch)
• add comparator maxNumBatch < currentNumBatch

• Implement signing mesage authorization as specified in https://docs.hermez.io/#/developers/protocol/hermez-protocol/protocol?id=regular-rollup-account
• current contracts use a local version of this function. It should be moved to commonjs in order to use same implementation across all tests

RollupDB should be extended to fully support massive-migrations.
Therefore, the following procedures should be implemented:

processBatchMigrate: mimics migrate circuit logic to insert new leafs into the state-tree

Possible implementation

Add new function in rollupDB: buildBatchMigration

check this issue for further details

Overview changes

• update batch-builder.js to proper handle new account ype

• rebase feature/upgrade-v1 to feature/massive-migrations
• update massive-migrations-utils.js to last v1 updates
• update helper function getStateTreeInfo in rollupDB