Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Endpoint: /block.validate #1643

Open
kalouo opened this issue Jul 14, 2020 · 7 comments
Open

Endpoint: /block.validate #1643

kalouo opened this issue Jul 14, 2020 · 7 comments

Comments

@kalouo
Copy link

kalouo commented Jul 14, 2020

In the current setup, the child chain composes a block and submits to the root chain without any further validation from an external component. This poses the risk of a byzantine event due to a software error in the child chain.

The following flow is envisioned to mitigate this:

*The Vault will manage block submission to the Ethereum Network

  1. Child chain requests the Vault to publish a block (Merkle) root hash
  2. Vault calls child_chain.get_block(root_hash)
  3. Vault calls Watcher to perform stateful block validation.
  4. If the validation is successful, publish. If it's not successful send an alarm on multiple channels.

References:

Todo for @thec00n: SLA margin is applied to specific exit scenarios that allows the chch to have a grace period, e.g. there is a double spend but if it happens within a margin it's ok since it can be challenged later. So make sure to consider all such scenarios that a malicious user could leverage to still include an invalid tx and analyze their impact.

@kalouo
Copy link
Author

kalouo commented Jul 20, 2020

Checklist:

  • Stateless validation: given Merkle root matches reconstructed Merkle root
  • Stateless validation: all transactions are correctly formed
  • Stateful validation: UTXOs in the given transactions are not spent by a child chain transaction
  • Stateful validation: UTXOs in the given transactions are not spent by an exit.
  • Stateful validation: Checking if the Watcher is synced to the block number it is receiving.
  • Stateful validation: Vault should call this endpoint before submitting the block.

To discuss: where/how do we draw the line between what is validated by the Watcher and what is left to the exit/challenge game?

@thec00n
Copy link
Contributor

thec00n commented Aug 13, 2020

Here is my brainstorming list for:

Stateless validation rules

Some of them might be already covered by the existing implementation of /block.validate:

Payment Tx (Ref: https://github.com/omgnetwork/elixir-omg/blob/master/docs/transaction_validation.md):

  • A tx input can not be spent by another tx in the same block
  • Match the payment tx type and must meet all the other payment tx type requirements

Fee Tx (Ref: https://github.com/omgnetwork/elixir-omg/blob/master/docs/fee_design.md):

  • Match the fee tx type, must have 0 inputs, 1 output and must meet all the other fee tx type requirements
  • Fee tx address should be matched against a specific value?

Block:

  • Block has less than 2^16 tx and more than 0 tx
  • Fee tx need to come at the end of a block after all other tx
  • 1 fee tx per asset
  • An input can only be spent once (per block).

Stateful validation rules

Payment Tx (Ref: https://github.com/omgnetwork/elixir-omg/blob/master/docs/transaction_validation.md):

  • A tx input has to be included in a previous block (including deposit blocks) and therefore has to be included in the list of unspent utxos
  • A tx input from must have a valid signature from the owner
  • The sum of tx inputs for a currency needs to be greater than the sum of tx outputs

Fee Tx (Ref: https://github.com/omgnetwork/elixir-omg/blob/master/docs/fee_design.md):

  • The sum of inputs minus the sum of outputs for a given currency across all payment tx is the amount that the operator can transfer to himself.

Block:

  • Needs to be the next block

@kalouo
Copy link
Author

kalouo commented Aug 14, 2020

Checklist

Rule Type Status
Block hash matches reconstructed Merkle root hash Stateless
Payment transactions are correctly formed Stateless Using Transaction.Recovered
Fee transactions are correctly formed Stateless Using Transaction.Recovered
No duplicate inputs in a block Stateless
Number of transactions within accepted range Stateless
Fee transactions comes after all other transactions Stateless
One fee transaction per currency Stateless

@kalouo
Copy link
Author

kalouo commented Aug 24, 2020

For transparency I am recapping the functionality of Transaction.Recovered

Transaction.Signed.decode(encoded_signed_tx)

  • Validates that RLP is correctly-formed.
  • Validate that witnesses are constructed as a list
  • Validates that each witness is a binary
  • Validates that each witness is correct length
  • Validates the existence of the given transaction type
  • Reconstructs the transaction as per its type:
    • Payment
      • Validates that there are 4 inputs or less
      • Validates that input decodes into a valid position
      • Validates between 1 and 4 outputs
      • Validates each output is correctly constructed (valid type, non-zero owner, non-zero amount, valid address)
      • Validates that metadata is binary and correct length
      • Validates each output matches payment output type
      • Validates txData RLP.
      • Validates that metadata is binary and correct length
    • Fee
      • Validates that each output is correctly constructed (valid type, non-zero owner, non-zero amount, valid address)
      • Validates that nonce is binary and correct length
  • Checks no duplicate inputs
  • If payment, validates number of signatures matches number of inputs
  • If fee, validates only one output

@thec00n
Copy link
Contributor

thec00n commented Aug 24, 2020

@okalouti should we start documentation around stateless and stateful block validation here https://github.com/omgnetwork/elixir-omg/tree/master/docs? I will never find that list again 😄

@InoMurko
Copy link
Contributor

InoMurko commented Nov 5, 2020

@okalouti is this done?

@kalouo
Copy link
Author

kalouo commented Nov 5, 2020

@InoMurko I left it open in case we wanted to add stateful validation to this endpoint. But you took this over and from your question I gather we can close it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants