vegaprotocol / vega

A Go implementation of the Vega Protocol, a protocol for creating and trading derivatives on a fully decentralised network.
https://vega.xyz
GNU Affero General Public License v3.0
36 stars 22 forks source link

Tool to strip transactions from an existing chain plus ability feed through null chain #5587

Open davidsiska-vega opened 2 years ago

davidsiska-vega commented 2 years ago

It "would be nice" to be able to take a chain; strip out all transactions that went into blocks in the order that they did and finally to be able to pipe this through null blockchain for testing / validation / debugging / analysis ...

It sounds almost like what you can do with blockchain already but it isn't: currently you can only replay the chain with the same version (or "very much compatible") version of the core because the internal-state-hash is part of the chain and checked at every block. So if any logic changes your replay will fail.

With the transactions stripped out and replayed through null chain this will not be an issue.

Of course some transactions that are related to the actual network "setup" and topology won't be relevent (e.g. validators joining or leaving). I think that's not a problem and these can be dealt with on the side that ingests them.

They will make more interesting "background" (especially mainnet) to https://github.com/vegaprotocol/vega-market-sim/ than the synthetic ones we're coding up.

We should be thinking of re-running transactions created on old chains from e.g. incentivised testnet (and mainnet once trading is live) as part of every release QA.

jeremyletang commented 2 years ago

Moving that to Cosmis elevator, more than unlikely we will have time for that before, let's not fool ourselves.

davidsiska-vega commented 1 year ago

I wonder if we should bump the priority - or at least figure out what this will do. We're getting some good on-chain trading from the sims; would create another tick in ensuring future releases are solid.

davidsiska-vega commented 1 year ago

Of course it is not entirely straightforward as there may be some setup work so the relevant markets / assets exist, so these would need to be sucked out of checkpoints and then submitted.

davidsiska-vega commented 1 year ago

A version of this is that a running vega node creates the same transaction replay thing that's optionally produced by null chain runs with the view that the dumped transactions are only runnable on null chain version of vega. But what is a must is the ability to dump transactions from version X and then play them on version Y (as long as transaction format hasn't changed). @wwestgarth if you know how much work this take would be and whether it's a better thing to try let us know.

wwestgarth commented 1 year ago

My feeling is that in theory it should be possibile.

If for this flavour of replay we run the nullchain as a non-validator node (it currently runs as the single validator node of a network when used normally) we might not need to strip any transactions at all because then it won't actually check anything like ERC20 chain events. It'll be driven purely by the transactions just like a non-validator "normal" node does.

In terms of how we collect the transaction, we could have a normal node write a replay file. It depends on how "intrusive" it is because we do try to limit how much nullchain code leaks out into normal core. Also I worry how big and unmanagable a text file containing a whole real chain's worth of transcations would be!

An alternative would be to have an option for the nullchain to just read directly from the tendermint's block data database (we can just import their package that talks to it and we get the nice interface for free) e.g.:

vega start --blockchain.chain-provider=nullchain --blockchain.nullchain.replay --blockchain.nullchain.tm_data=PATH_TO_TM_BLOCK_DATA

The above may be too optimisitc but I think it will just be a case of trying it, and patching up any places that fall over until it works.

RE: "dump transactions from version X and then play them on version Y" I don't know what we would do if a breaking change occurs in a transaction's format, but you would hope there won't be too many of those going forward.