[WIP] Added initial BlockManager and BlockDB implementations #280
Conversation
| // TODO: Figure out how to implement locking here so two state updates | ||
| // can't be added at the same time. | ||
|
|
||
| if (await block.has(start, end)) { |
There was a problem hiding this comment.
How frequently do we imagine Operators will submit plasma blocks? There's still a lot for me to learn, but this line triggers some red flags around scalability, depending on the answer.
There was a problem hiding this comment.
Probably somewhere between 15sec and 10mins depending on the chain. Which part specifically raises red flags?
There was a problem hiding this comment.
Sorry @kfichter, just seeing this now, but it means that the same range can only be transacted once every 10-15sec. That's probably fine for now, but I can certainly think of applications for which that will be too slow (trading, poker, etc.).
| * Finalizes the next plasma block so that it can be published. | ||
| * @returns a promise that resolves once the block has been finalized. | ||
| */ | ||
| public async finalizeNextBlock(): Promise<void> { |
There was a problem hiding this comment.
Not sure that it matters, but there's a race condition here if called concurrently.
There was a problem hiding this comment.
Yeah I could definitely use some input on managing concurrency. Seems like we might have to manage it on a global/OS level because leveldb isn't safe between different processes.
There was a problem hiding this comment.
Specifically important for the operator because accidentally bumping the block number twice would break a lot of things.
There was a problem hiding this comment.
We'll have to look into this more. It could be as simple as using a lib that wraps some simple single-threaded bool-flipping logic. We should be able to use JS's single-threaded nature to enforce order where necessary on multiple awaited calls.
smartcontracts
force-pushed
the
dev-block-manager
branch
from
711640c
to
50df20b
Compare
… stuff copied and adapted from plasma-group#280 - Removed redundant constructor assigment of members - Adapted RangeBucket to fit BlockDB usage
Adds: - BlockTransactionCommitment returned from ingestTransaction(...) - Ability to get Public Key of Aggregator to validate signed BlockTransaction - Some crypto utils - Range utilities - Serialization and deserialization for StateUpdate to serialize/parse objects to/from string Adds BlockManager, Block DB CommitmentContract, and probably other stuff copied and adapted from #280 - Removed redundant constructor assigment of members - Adapted RangeBucket to fit BlockDB usage - Adding async-mutex lib and adding mutual exclusion around BlockDB blocks that are not safely concurrent - Changing BlockDB to have buffer keys for BigNums Fixes: * Wallet nonce race condition in Deposit tests by creating a separate wallet for each async test instead of sharing * Increasing default test timeout from 2 seconds to 5 seconds to fix CI build failures
Adds: - BlockTransactionCommitment returned from ingestTransaction(...) - Ability to get Public Key of Aggregator to validate signed BlockTransaction - Some crypto utils - Range utilities - Serialization and deserialization for StateUpdate to serialize/parse objects to/from string Adds BlockManager, Block DB CommitmentContract, and probably other stuff copied and adapted from plasma-group#280 - Removed redundant constructor assigment of members - Adapted RangeBucket to fit BlockDB usage - Adding async-mutex lib and adding mutual exclusion around BlockDB blocks that are not safely concurrent - Changing BlockDB to have buffer keys for BigNums Fixes: * Wallet nonce race condition in Deposit tests by creating a separate wallet for each async test instead of sharing * Increasing default test timeout from 2 seconds to 5 seconds to fix CI build failures
Description
Started implementing BlockManager and BlockDB. Still WIP but want to get review as I go along. Partially blocked by #271 at the moment because
RangeStoreis currently located inOperatorbut I don't want to do an import when we're moving it soon anyway.Questions
BlockDBneeds to lock a specific range so that a race condition doesn't cause a database overwrite. Can this be handled at theLevelDBlevel? How important is this?BlockManagermaintain an append-only log like it did back in the original operator?BlockManagerbe writing toStateManagerorHistoryManageronce it publishes a block? It doesn't really make sense for bothBlockManagerandHistoryManagerto store the full set of state updates (?).Metadata
Fixes
Blockers
Contributing Agreement