Proposer to propose multiple L2 blocks at once

[daveroga]

Feature #478

Feature

Once the current proposer changes, the new current proposer can submit multiple blocks at once.

• If there are not enough unprocessed transactions for more than 1 block: it is similar to proposing 1 block at a time -> for each L2 block proposal, it will have to wait for prior events in the queue to be processed with their 12 confirmation wait included.
• If there are too many unprocessed transactions: an upper limit for maximum number of L2 blocks to propose is required such that the proposer does not lose gas on all the L2 blocks that did not make it to L1 when they were the current proposer. MAX_L2_BLOCKS_TO_PROPOSE = Number of L1 blocks a proposer gets * the number of L2 blocks can fit in each L1. This assumes that L1 blocks are completely filled with NF's L2 block proposed transactions, this might need to be corrected by a factor

Actions

conditionalMakeBlock to create numberOfUnprocessedTransactions / TRANSACTIONS_PER_BLOCK blocks instead of just 1. This should allow us to build multiple blocks before having to process the events with their 12 confirmation wait in 0th queue.

• Remove async from Block.build and pass the parameters needed instead.
• makeBlock to return list of blocks and transactions per block instead of single block.
• ws.send 'block' will send list of unsigned propose block transactions so that the proposer can send the list of unsigned tx to the state contract with proposeBlock.

Test

Created a test for this functionality. A user will create some deposits without a proposer and then a proposer will register and start to get all pending L2 blocks proposed txs to be proposed at once.

• Start Nightfall with ./start-nightfall -g -s -d
• Run the test npm run test-e2e-protocol that includes proposer should propose multiple L2 blocks after deposits test.

[signorecello]

lgtm

[daveroga]

During the tests I checked the message sent by logger.debug('Found ${txDataToSignList.length} blocks to process'); but it's true that I have to pass some check directly to the test and check it there. I've updated the test sending another parameter with the number of blocks proposed in the 'gasCost' event.

expect(blocksReceivedToPropose).to.be.equal(Math.floor(totalDeposits / txPerBlock));

[ChaitanyaKonda]

During the tests I checked the message sent by logger.debug('Found ${txDataToSignList.length} blocks to process'); but it's true that I have to pass some check directly to the test and check it there. I've updated the test sending another parameter with the number of blocks proposed in the 'gasCost' event.

expect(blocksReceivedToPropose).to.be.equal(Math.floor(totalDeposits / txPerBlock));

How is blocksReceivedToPropose defined ?

[daveroga]

It's the txDataToSignList.length. Length of the list of txDataToSign. Data to sign of blocks to propose that the proposer receive with the data of type 'block' from the optimist.
Before the update the proposer received txtDataToSign and now receives a list of this txtDataToSign. It's the list we use the reduce pattern to submit the signed transaction for every block proposed.

txDataToSignList.reduce((seq, txDataToSign) => {
          return seq.then(() => {
            return this.submitTransaction(
              txDataToSign,
              this.stateContractAddress,
              this.BLOCK_STAKE,
            ).then(res => newGasBlockEmitter.emit('gascost', res.gasUsed, txDataToSignList.length));
          });
        }, Promise.resolve());