zack-bitcoin
commented
5 years ago A strategy to make sure we don't break anything. We should launch a fork with lower difficulty to act as a testnet, and try out the hard fork there first. Using the same history that the real hard fork will use. So we can all test out the changes before we do the real hard fork.
It should have quicker oracle delays and faster block times to make oracle tests easier.
It needs some mechanism to prevent the fork from surviving and having value.
What is going on:
Putting merkel trees inside merkel trees of the consensus state was not a good idea. Right now unmatched bets in the oracles are stored in trees who's roots are stored in the oracles. And matched bets are stored in the trees who's roots are stored in the accounts. Each account has it's matched bets, each oracle has it's unmatched bets.
Why that is bad:
To write data to the merkel tree, we first have to read some stuff from the merkel tree. This is preventing sharding. Sharding means to prune lots of data, so reading this data should not be part of block validation. This problem is causing block validation to be around 2x slower than it's potential.
What we need to do:
We need to add a couple more pointers to the trees in each block. don't worry, this wont change headers, so the light nodes wont change. And ideally we would move all the orders and oracle bets to their new trees.
The old oracle_bets and orders no longer contain enough information, and their keys are not enough to identify them. So we need new merkel trees to be made, and new rules for serializing a larger datastructure. Maybe this is good, since their old names were so terrible, we can give them good names now.
We need to update the transactions to use the new tree locations instead of the old ones.
we will need to change how proofs are processed, and how trees looks up data.