Block Submission Specs

[InoMurko]

Stories revolving around how we handle block submission. This issue is large but it contains things like:

• block submission
• gas price setting
• handling re-orgs
• retry behavior and notifications
• Vault Integration

Feature: Submitting Blocks to the Contract
	Once the Childchain has formed blocks, it needs to submit these blocks to the contract so that they can be persisted in the network.
	
Background:
	Given I am the Childchain
	And I have pending blocks

Rule: The Childchain can submit blocks in order

@wip
Scenario: Submits multiple blocks in order

Rule: The Childchain recovers from submission failures

@wip
Scenario: Retries block submission if it fails
	When I submit a block
	And the submission fails
	Then I will re-submit again
	
@wip
Scenario: Alerts team if block submission fails too much
	When I submit a block
	And the submission fails
	And I re-submit to the retry limit
	Then I notify the team
	
Rule: The Childchain sets the correct gas price to ensure block gets submitted

Rule: The Childchain can recover from re-orgs

Rule: The Childchain submits the block securely through Vault

Checklist

• Scenario: Retries block submission if it fails
• Scenario: Submits multiple blocks in order
• Scenario: Alerts team if block submission fails too much

---

Previous issue body:

• determining the cadence of forming/submitting blocks to Ethereum.
• keeping a queue of blocks lined up for submission to Ethereum.
• determining correct gas price and ensuring submissions get mined eventually

[Pongch]

I have a few scenarios I would like to get captured in the block submissions discussions

@wip
Scenario: A Block can be submitted when a transaction counts exceeded N
    Given a configuration value N
	When a transaction has been submitted to child chain
	And all the transactions within the block exceeded N transactions
	Then a block is submitted to root chain

@wip
Scenario: A Block cannot be submitted when a transaction counts do not exceed N
    Given a configuration value N
	When a transaction has been submitted to child chain
	And all the transactions within the block exceeded N transactions
	Then a block is not submitted to root chain

@wip
Scenario: A Block can be submitted when a number of root chain blocks exceeded N
    Given a configuration value N
	When a transaction has been submitted to child chain
	And the number of root chain blocks since last child chain block is submitted exceeds N
	Then a block is submitted to root chain

@wip
Scenario: A Block cannot be submitted when a number of root chain blocks do not exceeded N
    Given a configuration value N
	When a transaction has been submitted to child chain
	And the number of root chain blocks since last child chain block is submitted exceeds N
	Then a block is not submitted to root chain

@wip
Scenario: A Block can be submitted either when a number of root chain blocks do not exceeded N or when a transaction counts do not exceed M, whichever happens first
//TBD

Most of these are ask(s) from Erica as part of Verity exploration in operational cost reduction. The details can be found in here: https://docs.google.com/document/d/12Qfk2ZPOEiMd9ZIwtf3x8bVbmcJBUfCBn7XLXWN2ezw/edit?usp=sharing

[InoMurko]

Is Verity being implemented on two childchain? What about v1 issues that @pnowosie is implementing?

[Pongch]

a lot of the work on Verity is in a PoC phase so we may not need a production implementation of delayed block submission until Q1 next year. the PoC has a lot of work on client side implementation so it should not be blocked by child chain.

I will let @Dabrieo speak on this since she is clearer on the timeline

UPDATE: we will wait for a more formal announcement on how delayed block submission will be implemented, but as of now the requirement is out of scope.

[Dabrieo]

Trying to get timing verification now. Should know at the latest next week.

[InoMurko]

DOne.