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

Persistence Updates #56

Merged
merged 5 commits into from
Mar 26, 2020
Merged

Persistence Updates #56

merged 5 commits into from
Mar 26, 2020

Conversation

willmeister
Copy link

Description

Adding and cleaning up configuration via environment variables. Trying to pave the way for persistence in a deployed dev environment.

Contributing Agreement

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.

This looks good so far but I haven't quite finished the review. Instead I just noticed a bit of terminology that I got confused by and so I'm submitting this as a comment to then send around to make sure it lines up with others intuitions.

Might be good to add stuff like this to a glossary--we've got so many moving parts it's important we're all on the same page with what is what.

* to consolidate access / updates and default values.
*/
export class Environment {
// Local Node Config
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks good! In the spirit of honing my code style intuitions, I have two observations:

  1. These comments are good because they provide context for the organizational structure of the code, not just what the code does.
  2. We could possibly look for a library which handles config but in this case building this class seems like it wouldn't be much harder than using a library, so it's fine to use a "custom" implementation.

*
* @param mnemonic
* @param port
*/
export const startLocalL1Node = async (
Copy link
Contributor

@karlfloersch karlfloersch Mar 25, 2020

Choose a reason for hiding this comment

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

Hmm the terminology here is a little confusing. Am I getting it right that "LocalL1Node" is what we send "InternalTransactions" to? It's just really confusing and I want to make sure we have all of the components mapped out with reasonable terminology.

I just made a diagram which illustrates all of the components.

IMG_6A835E8216F2-1

So to be clear, L1 Node would be just a normal Geth instance that's syncing mainnet Ethereum. Then an L2 Node or maybe more specifically Rollup Node would be the thing that runs an Internal instance of Geth / EVM, which itself either emulates an OVM deployed to it (ExecutionManger, etc).

Does that match up with the terminology being used here?

Copy link
Author

Choose a reason for hiding this comment

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

Yep, that's it! The line in question is to specifically start an L1 node locally to fully exercise the end-to-end functionality of L2 <--> L1 messaging. This is completely different than the L2 Node. I went with L1 and L2 because nothing is actually "rolled up" in the L2 node, and instead, the rollup state sits in the L1 node. Wanted to avoid that confusion. Does L1 and L2 sound good? Happy to rename it to rollup if you think it makes more sense.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah great! So I think after staring at this for a while I see where my confusion was. The fact that inside the LocalL1Node we have a sequencerWallet was throwing me off. But it’s just because in this circumstance the L1 that we are running is a Local testnet run by the sequencer.

These L1 & L2 terms are a little confusing! Especially when you see L1ToL2 right next to L2ToL1 — my dyslexia goes crazy! That said, it’s not clear to me that EthNode and RollupNode (for example) are much better 😕 Especially because both are in some sense “Eth” nodes.

I realize this could require some refactoring/renaming (and so I’m happy to not do it) but I wonder if instead of L1ToL2/L2ToL1, we could use the terms L2InboundMessages and L2OutboundMessages or something? Just spitballing and curious what you / @ben-chain think.

It’s a nitpick though & might be specific to my difficulty reading 😂

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh nvm I take it back. I’m now thinking about l2ToL1MessageReceiver and calling it l2OutboundMessageReceiver and realize that these variable names are going to be confusing basically no matter how we slice it.

Unless y'all absolutely love my naming change (which might have been closer to what Ben did originally?) doesn’t feel worth the switching cost.

@willmeister willmeister merged commit 14fea00 into master Mar 26, 2020
@willmeister willmeister deleted the persistence_updates branch March 26, 2020 04:09
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.

Alrighty! That took surprisingly long to decipher but happy to say that I understand the code / variable naming now & looks good to me!!! 😄

*
* @param mnemonic
* @param port
*/
export const startLocalL1Node = async (
Copy link
Contributor

Choose a reason for hiding this comment

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

Ah great! So I think after staring at this for a while I see where my confusion was. The fact that inside the LocalL1Node we have a sequencerWallet was throwing me off. But it’s just because in this circumstance the L1 that we are running is a Local testnet run by the sequencer.

These L1 & L2 terms are a little confusing! Especially when you see L1ToL2 right next to L2ToL1 — my dyslexia goes crazy! That said, it’s not clear to me that EthNode and RollupNode (for example) are much better 😕 Especially because both are in some sense “Eth” nodes.

I realize this could require some refactoring/renaming (and so I’m happy to not do it) but I wonder if instead of L1ToL2/L2ToL1, we could use the terms L2InboundMessages and L2OutboundMessages or something? Just spitballing and curious what you / @ben-chain think.

It’s a nitpick though & might be specific to my difficulty reading 😂

*
* @param mnemonic
* @param port
*/
export const startLocalL1Node = async (
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh nvm I take it back. I’m now thinking about l2ToL1MessageReceiver and calling it l2OutboundMessageReceiver and realize that these variable names are going to be confusing basically no matter how we slice it.

Unless y'all absolutely love my naming change (which might have been closer to what Ben did originally?) doesn’t feel worth the switching cost.

snario pushed a commit that referenced this pull request Apr 14, 2021
* decompression (not working)

* start EIP155 serialization

* working decompressor

* working CreateEOA, working native EIP155tx

* all three tx types working

* remove only

* fix ECDSAUtil tests

* restore original version of smock

* add proxys

* clean up tests

* clean up decompressor tests

* clean up ProxyDecompressor

* clean up decompressor tests

* add CREATEEOA, SETNONCE, GETNONCE tests

* working ECDSAContractAccount

* fix decompressor

* renaming, add deploy

* add proxyeoa test, cleanup

* remove createEOA type, add extcodesize check

* fix decompressor test

* support create txs

* Decompressor -> Entrypoint

* use safeREVERT instead of requires

* add isAuthenticated state manager test

* update smock

* fix sequencerEntrypoint test

* add isAuthenticated

* Revert "update smock"

This reverts commit 286a222414accf9387dcd12ecbed0a66be586bc8.

* fix test

* Updates to EM

* removed kall from contract account

* Fixed SSLOAD and SSTORE problems

* Fix some broken tests

* Fix more bugs & rename to ProxyEOA

* WIP fix call test

* fix all tests

* add gas check

* update tests

* lint and remove 2000 gas check

* Add fees to default EOA (#56)

Co-authored-by: Kelvin Fichter <[email protected]>
Co-authored-by: Karl Floersch <[email protected]>
protolambda pushed a commit to protolambda/optimism that referenced this pull request May 1, 2022
…ting-exemptions

add more linting exemptions
teddyknox pushed a commit to teddyknox/optimism that referenced this pull request Oct 3, 2023
…10.0 (ethereum-optimism#56)

* deps: bump celestia-node v0.9.5 to v0.10.0

* change RPC

* swap RPC

* deps: bump v0.9.5 to v0.10.0 local-celestia-devnet
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.

2 participants