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

Mock ingest transactions & produce blocks #325

Conversation

willmeister
Copy link
Collaborator

Description

Adds Aggregator and BlockManager (copied from here) and implements and tests Aggregator.ingestTransaction(...)

Questions

  • I assume this is supposed to lean heavily on BlockManager for addPendingStateUpdate and submitNextBlock -- is that right, or is there a separate enqueueStateUpdate(...) and produceBlock() that are required?
  • Is there a good way to get around passing the witness to Aggregator.ingestTransaction(...)?

Metadata

Fixes

Contributing Agreement

@karlfloersch
Copy link
Contributor

This PR is looking great so far! Glad you pulled out generateNSequentialStateUpdates() into test utils--was meaning to do that. With regard to your questions--

supposed to lean heavily on BlockManager for addPendingStateUpdate and submitNextBlock

Yes this is right. enqueueStateUpdate() & produceBlock() are just alternative names for addPendingStateUpdate & submitNextBlock -- Apologies for my imprecise language in the issue!

Is there a good way to get around passing the witness to Aggregator.ingestTransaction(...)?

So at this moment I am not entirely sure if we need the witness at all. @ben-chain let me know what you think, but it seems to me you should only need to send the aggregator a transaction, and then if someone wants to validate an OVM property, they'd simply be passed whatever witness they need for that in the proof. Plus I'm a fan of removing unused fields where possible & I can't think of a use now so feels like a good thing to get rid of.

Is this what you were asking with this question @willmeister ?

@willmeister
Copy link
Collaborator Author

...
So at this moment I am not entirely sure if we need the witness at all. @ben-chain let me know what you think, but it seems to me you should only need to send the aggregator a transaction, and then if someone wants to validate an OVM property, they'd simply be passed whatever witness they need for that in the proof. Plus I'm a fan of removing unused fields where possible & I can't think of a use now so feels like a good thing to get rid of.

Is this what you were asking with this question @willmeister ?

@karlfloersch the reason I added it is that we call StateManager.executeTransaction(transaction, block, witness) in order to get the StateUpdate [and maybe the valid Ranges?] from the Transaction. If this is not necessary and there a better way to get the StateUpdate, I'll happily switch to that 😄

@ben-chain
Copy link
Contributor

I think that this is the right model, @karlfloersch we will probably end up calling transaction property and could rename witness to proof if we like. Naming aside, the function call given our current names is executeTransaction

- BlockTransactionCommitment returned from ingestTransaction(...)
- Ability to get Public Key of Aggregator to validate signed BlockTransaction
- Some crypto utils
- Range utilities

Improves:
- Tests for Aggregator, testing return type, range validity, and signature
- Crypto verifySignature stub
… stuff copied and adapted from plasma-group#280

- Removed redundant constructor assigment of members
- Adapted RangeBucket to fit BlockDB usage
- Changing BlockDB to have buffer keys for BigNums
- Adding serialization and deserialization for StateUpdate to serialize/parse objects to/from string
Copy link
Collaborator

@akhila-raju akhila-raju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good on first pass, just a few comments.

Leaving to @karlfloersch @ben-chain to review

Copy link
Collaborator

@akhila-raju akhila-raju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one fix, changes look good :)

@willmeister willmeister self-assigned this Jul 19, 2019
@willmeister willmeister mentioned this pull request Jul 19, 2019
2 tasks
@willmeister willmeister changed the title [WIP] Mock ingest transactions & produce blocks Mock ingest transactions & produce blocks Jul 19, 2019
Copy link
Contributor

@karlfloersch karlfloersch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not entirely finished reviewing (in particular I haven't looked over the tests super closely); however, so far this looks great! I wanted to submit this review preemptively so that you can check out the few things I did comment on.

* @returns a promise that resolves once the update has been added.
*/
public async addPendingStateUpdate(stateUpdate: StateUpdate): Promise<void> {
await this.blockMutex.runExclusive(async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice mutex!

}
public constructor(
private stateDB: StateDB,
private pluginManager: PluginManager
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we will rename to deciderManager?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think you're right. Does that make sense to do in a separate PR that OVM-ifies all of our outdated names?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah let's do in a separate PR

export interface BlockTransactionCommitment {
blockTransaction: BlockTransaction
witness: any
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's great that you're mocking the tx commitments already!

packages/core/src/app/utils/crypto.ts Show resolved Hide resolved
packages/core/src/app/utils/equals.ts Outdated Show resolved Hide resolved
ingestTransaction(
transaction: Transaction,
witness: string
): Promise<BlockTransactionCommitment>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is unclear to me what the witness parameter does here. I believe it may have been part of our out of date spec.

Ideally we'd simply be sent the transaction itself. From this we run some authentication logic & generate a new StateUpdate. In fact this whole transaction ingestion process is under specified and so I just created an issue for it here: #349

Copy link
Collaborator Author

@willmeister willmeister Jul 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good question. There is both authentication and authorization to be done, right?

  1. Is this transaction actually from the user who is trying to send their funds (authentication)?
  2. Does the user trying to send funds actually own the funds they're trying to send (authorization)?

I assumed the witness portion would solve (1), although that could be handled in the communication layer itself. Is there something I'm missing that either handles that or makes it unnecessary?

Copy link
Contributor

@karlfloersch karlfloersch Jul 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we can keep transactions more general and with that we won't need to break those two (authentication/authorization) into two steps. Instead you simple check that the transaction itself is valid. The tx might not even have a single sender--it could simply be a subsidized function call in a smart contract (essentially the concept of account abstraction ethereum/EIPs#859).

although that could be handled in the communication layer itself

Yeah I think it makes sense for the anti-spam mechanism to be handled by the communication layer. Eg. banning peers that repeatedly broadcast failing transactions.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation 😄. I'll remove witness from the method signature.

@willmeister willmeister merged commit f344f53 into plasma-group:master Jul 22, 2019
@willmeister willmeister deleted the feat/323/MockIngestTransactionsAndProduceBlocks branch July 22, 2019 20:35
akhila-raju pushed a commit to akhila-raju/pigi that referenced this pull request Aug 9, 2019
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
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

Successfully merging this pull request may close these issues.

Mock ingest transactions & produce blocks
4 participants