[OP Stack Deployment] General Discussion

[astro44]

Did you check the documentation?

• Yes

Did you check for duplicate questions?

• Yes

Issue Description

Having had success previously, this is a start from 0 except keeping the same wallet addresses as before and only changing the Salted "IMPL_SALT" value. Issue occured at: "Deploying AddressManager". within [9079256848778929263] Deploy::run()

I would expect that I can create multiple chains with the same wallet... no?
If I change my wallets to new ones using packages/contracts-bedrock/scripts/getting-started/wallets.sh, then that seems to work... is this expected behaviour?

Logs

-------------- results are
5.971 == Logs ==
5.971 Connected to network with chainid 11155111
5.971 Storing temp deployment data in /optimism/packages/contracts-bedrock/deployments/getting-started/.deploy
5.971 DeployConfig: reading file /optimism/packages/contracts-bedrock/deploy-config/getting-started.json
5.971 Deploying from Deploy
5.971 Deployment context: getting-started
5.971 Deploying a fresh OP Stack including SuperchainConfig
5.971 Deploying Safe
5.971 New SystemOwnerSafe deployed at 0x8F354C70ab3F11253eaE83C8C0663655516A2fC6
5.971 Setting up Superchain
5.971 Deploying AddressManager
6.031 Error:
6.031 script failed: <>

Additional Information

for anyone interested here is a docker file we are using:
https://github.com/astro44/OP_stack

Feedback

Maybe add a section specific to requirements if users decide to create more than one chain?

[opfocus]

I'm just curious, why don't you define some real values in the .env file? just like you've done in docker-compose.yml

GS_ADMIN_ADDRESS=0x00001
GS_ADMIN_PRIVATE_KEY=0x000000000000001
GS_BATCHER_ADDRESS=0x00002
GS_BATCHER_PRIVATE_KEY=0x000000000000002
GS_PROPOSER_ADDRESS=0x00003
GS_PROPOSER_PRIVATE_KEY=0x000000000000003
GS_SEQUENCER_ADDRESS=0x00004
GS_SEQUENCER_PRIVATE_KEY=0x000000000000004

[astro44]

it should be filled out by the user, either with their own or from the example (https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/scripts/getting-started/wallets.sh). Soon I'll add in a few more automated steps to improve now that I am finally getting comfortable with how to deal with some of the errors.... (*still got a lot to learn). **I'lll leave this ticket open and update with the new changes and if I get any other "unknown" issues.
Thanks again!!! @opfocus

[astro44]

@opfocus to summarise IMPL_SALT is used to:

1. Associates an OP-Stack with the ETH L1 Proxy Contract.
2. Changing this will be the equivalent of running a new OP-Stack (*when running through OPStack initialization)
3. All Nodes should use this same IMPL_SALT +chainid to guarantee they're part of the same L2.

Additional Notes:

1. .envrc must be updated, if you have already created an OP-Stack and decide to create a new one.
2. Creating a second OP-stack can use the same wallet addresses but must have a unique IMPL_SALT.
3. if you reboot a node already registered it may take some time before the node is able to sync "bridge" changes like funding a wallet from L1 to L2 using "L1StandardBridgeProxy" contract on L1.

[astro44]

So far Got everything running this time with a different chainID which has made a significant difference in traffic, also running all services in a single Docker container... looking to see if it all stays below 8GB ram...?

The only initialization question I have now is tied to new images with the same network.
i.e. lets say Ubuntu needs a critical patch, I don't want to run the forge commands again...
however I do need the artifacts, abi's etc....

1. @opfocus what are the best steps in harvesting or is there a shell script somewhere for this scenario?
   a. What about the wallets for new nodes? do they also need to build out their own wallets? It would seem odd to copy same address/private key to each node no?
   b. Looks like in https://docs.optimism.io/builders/chain-operators/operations, for additional nodes... it doesn't mention op-proposer is it not required like op-batcher (*btw misspelled in the docs)
   

[astro44]

2. if the network goes out and comes back seems that the services can not recover, had to restart the container and wait a few mins before it looks healthy... "successfully built a new block". still see a lot of "tx in inbox with unauthorized submitter" any suggestions on best practices to have nodes recover after a network outage or even power outage? @opfocus
   
   Uploading _restart_log.txt…

[opfocus]

I suggest updating the category of this issue to 'General Discussion.' You can conveniently edit it at the top right corner of the page. If possible, consider adjusting your title as well. It seems more like an all-in-one configuration solution for Op Stack Chain, and the original title doesn't seem very enticing.
Additionally, I need some time to think and attempt to provide responses to your raised questions. I am a learner, and I haven't pondered these issues deeply yet.

[astro44]

changed the title... and another note after the reboot... doesn't seem to use much memory so far....

[astro44]

Added update to the repo https://github.com/astro44/OP_stack, was able to successfully run both all services in one container and stand up a new one using ngrok in a raspberrypi (*so far the memory is at 4GB).... will continue to keep testing but for now will close this out. Thank you all for the help! @opfocus @sbvegan