-
Notifications
You must be signed in to change notification settings - Fork 58
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
Comments
Checklist:
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? |
Here is my brainstorming list for: Stateless validation rules Some of them might be already covered by the existing implementation of Payment Tx (Ref: https://github.com/omgnetwork/elixir-omg/blob/master/docs/transaction_validation.md):
Fee Tx (Ref: https://github.com/omgnetwork/elixir-omg/blob/master/docs/fee_design.md):
Block:
Stateful validation rules Payment Tx (Ref: https://github.com/omgnetwork/elixir-omg/blob/master/docs/transaction_validation.md):
Fee Tx (Ref: https://github.com/omgnetwork/elixir-omg/blob/master/docs/fee_design.md):
Block:
|
Checklist
|
For transparency I am recapping the functionality of
|
@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 😄 |
@okalouti is this done? |
@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! |
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 Networkchild_chain.get_block(root_hash)
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.
The text was updated successfully, but these errors were encountered: