Block Formation Specs

[achiurizo]

This covers how we handle forming blocks in the childchain and how we need to persist certain information back down into the block, transaction and output.

Feature: Forming Blocks to Submit to the Network
	The childchain needs to effectively create blocks from submitted transactions 
        and send it to the contract. It will need to be effective in how it forms blocks 
        and conform to how we generate the blocks in elixir-omg for now.

Background:
	Given I am the Childchain
	And I currently have no transactions
	And the block limit is 2^16

Rule: A Block is formed with only pending transactions and its fees

Scenario: A Block is formed with pending transactions
	When there are pending transactions
	Then I form a block with the pending transactions
	
Scenario: A block is not formed if there is no pending transaction
	When there are no pending transactions
	Then I do not form a block

Scenario: A Block does not form with non-pending transactions
	When there are no pending transactions
	And there are confirmed transactions
	Then I do not form a block
	
# The position is the UTXO position e.g {blknum, txindex, oindex}
Scenario: A Block will update the associated outputs with their position
	When there are pending transactions
	Then I form a block with the pending transactions
	And I update the associated outputs with their position

Rule: A Block cannot exceed the block limit

Scenario: A Block does not exceed the transaction limit 
	When there are 2^16 pending transactions
	And there are 100 additional pending transactions
	Then I form a block with 2^16 pending transactions
	And I form a block with 100 pending transactions
	
@wip
Scenario: A block does not exceed the transaction limit with fees
	When there are 2^16 pending transactions
	And there are fees for those transactions
	Then I form a block with the transactions and fees
	And I form a block with the remaining transactions
	

Checklist:

• Scenario: A Block is formed with pending transactions
• Scenario: A block is not formed if there is no pending transaction
• Scenario: A Block does not form with non-pending transactions
• Scenario: A Block will update the associated outputs with their position cc Block Formation Specs #2
• Scenario: A Block does not exceed the transaction limit
• Scenario: A block does not exceed the transaction limit with fees

[T-Dnzt]

You also need a step that confirms that a submitted block has been included in the rootchain (probably with a configurable X number of blocks to wait for to reach the "finality" we want). We also might want to think about some protection against reorgs (which can be mitigated with the X we chose, but it's all about risk vs speed).

Btw, this is how we were polling for transactions in the eWallet in case that's useful:

• https://github.com/omisego/ewallet/blob/eth-blockchain/apps/eth_blockchain/lib/eth_blockchain/listeners/transaction_listener.ex
• https://github.com/omisego/ewallet/blob/eth-blockchain/apps/eth_blockchain/lib/eth_blockchain/listeners/rootchain_transaction_listener.ex

[T-Dnzt]

One more thing that needs to be handled (could be a new issue) is defining the gas price for submit_block. There's actually a good explanation of what the current block queue does here: https://github.com/omisego/elixir-omg/blob/master/apps/omg_child_chain/lib/omg_child_chain/block_queue/core.ex

[Pongch]

I have a story I would like to get captured as part of block formation(s)

@wip
Feature: visible transaction state
Scenario: an unsubmitted transaction in a block can be queried by user
	When a transaction has been submitted to child chain
	And it has not been submitted to the root chain
	Given that the user query the content of the transaction
	Then I return the transaction details back to the user
	And the user can use this data to form subsequent UFO transactions

The purpose of this scenario is two folds:

1. ensure that the user can continue to chain transaction aka. UFO transaction as described by Kevin, allows the user to continue making subsequent transactions without waiting for block submission

2. user can understand the current 'state' of the transaction after submission. He/she can know that the transaction is now in 'block formation'/'pending' state. The client can subsequently inform this to the user

EDIT: As discussed on the call today, we have agreed that it's a better idea to push this requirement away from the child chain service to Watcher-security. More API design and discussion is required before we proceed.

[InoMurko]

By which filter would the user query for the transaction?

[pgebal]

What's left is making sure we do not go over transactions limit per block, including fee transactions.

[pgebal]

@mederic-p our current solution for keeping transactions in a block under the limit is a bit clunky.
It would be perfect if we knew how many fee transactions there are in currently forming block, including fees for incoming transaction.
Currently we use a hard limit of 65k payment transactions in block. That's ok until:

• we do not want to fully pack blocks
• we are sure there are always less than couple hundreds fee transactions.

The current solution is OK for me, but we have to remember about it's limits. Do we agree it's good enough or do we want to change it now?