[OP Stack Deployment] Cannot Deploy the contract to the layer1 #208
-
Did you check the documentation?
Did you check for duplicate questions?
Issue DescriptionBackground:
Despite following the startup guide and adjusting the gas settings in the CreateCollision Consideration: Approach and Observations:
Steps Taken:
Goals and Questions:
I would greatly appreciate any insights or guidance on what might be causing these errors and how to resolve them. If there's a specific aspect of the forge script command or gas settings that I might be overlooking, please let me know. I want to explore and using the op-stack more various. Thank you in advance for your assistance! Logs
Additional InformationNetwork details: Private Qtum test blockchain I am utilizing Janus as a middleware between the Qtum test blockchain and the OP Stack (Optimism). Janus serves as an interpreter for Ethereum RPC commands, which the Qtum network does not natively support. However, in the Janus logs, there are no indications of sendtransaction or sendrawtransaction commands being processed. This is the log from Janus Click to view logs
FeedbackNo response |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
https://docs.optimism.io/builders/chain-operators/hacks/data-availability#default Here are some of your concerns |
Beta Was this translation helpful? Give feedback.
-
Hey @ipoomzakungi, Thank you for the detailed question. To address a some key points:
The OP Stack's underlying assumption is that Ethereum is the L1, so this will cause compatibility issues when there is nuance between the underlying L1s. Namely the L1 EIP-1559 gas mechanism is a core assumption from the OP Stack protocol's perspective. Its possible to hack it, but this falls out of the realm of what we can support.
The first part of this question has been answered above. Regarding the native currency. The OP Stack uses ether because it writes to Ethereum which uses ether to pay for network usage. There are always questions about changing the native gas token to something other than the L1 native token. However, this causes a lot of complexity. My personal main concern with that is using an alternative token creates a constant sell pressure on the token because the L1 costs still need to be paid for with the native token. So the alternative token would be constantly sold for the native token and I don't think that is economically sustainable. Additionally there are required modifications to the OP Stack to enable something like this. |
Beta Was this translation helpful? Give feedback.
-
Hey @ipoomzakungi, We hope your recent question was resolved to your satisfaction. Your feedback is invaluable and helps us improve our support services. Could you spare a moment to fill out a short feedback survey. Thank you for helping us improve our developer community. |
Beta Was this translation helpful? Give feedback.
Hey @ipoomzakungi,
Thank you for the detailed question. To address a some key points:
The OP Stack's underlying assumption is that Ethereum is the L1, so this will cause compatibility issues when there is nuance between the underlying L1s. Namely the L1 EIP-1559 gas mechanism is a core assumption from the OP Stack protocol's perspective. Its possible to hack it, but this falls out of the realm of what we can support.