[Core Protocol] <Title> When building out your rollup, Is it mandatory to utilize pre-existing execution engines, similar to how Optimism utilizes Geth? #134
-
Did you check the documentation?
Did you read the specs?
Did you check for duplicate questions?
Issue DescriptionWe are grappling with a decision. While constructing a non-EVM-compatible op-stack chain, we initially attempted to reuse the protocol execution engine. However, adapting it to be compatible with Op-node required extensive modifications. We are aware that Optimism achieved security and trust by reusing Geth. Nevertheless, is it feasible for us to develop a new execution engine from scratch, incorporating the necessary elements from the non-EVM-compatible chain and also drawing from Geth? Would this still be an OP-Stack chain? Additional InformationWe believe that developing a new execution engine would quicken our progress and allow us to swiftly create a functional Proof of Concept (POC). However, would this still be categorized as an end-to-end technology stack overhaul? FeedbackNo response |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
|
Interesting question, it appears to be a complex technical feat. I'll see if I can get someone with more domain expertise to weigh in here.
I don't have a good answer for this. It sounds like the result would differ pretty strongly from the OP Stack, so it would probably be classified as something different. This sounds more like an OP Stack hack.
I'm leaning towards yes. While there would be some common elements, there would also be big differentiators. Can you tell us more about what you're trying to implement and the reason why? |
Beta Was this translation helpful? Give feedback.
-
|
Hey thanks for looking this through. If I am not wrong the opstack system is made up of the following components op-node (consensus node), op-geth (execution node), and in to other for them to communicate then the op-node has to use the execution client exposed api's, in this case reusing the eth namespace api's and the engine api's, in the to use for example a solana node with the op-node it would involve implementing both eth and engine api's and the functions they both individually call. This would involve lots of changes. So we are thinking this, ethereum allows the creation of new tx types so a creation of a new tx type that can wrap around the tx type of the non evm chain, then making the tx compatible with the non evm's vm, then reusing geth code as a guide so as to make things easier. |
Beta Was this translation helpful? Give feedback.
-
|
So I think you can do that, but its definitely off the happy path so we can't provide any guarantees that it'll work. We also wouldn't be able to provide very much support because its your own custom build. To answer your original question: no its not mandatory because its MIT licensed you can do whatever you want with it and we encourage experimentation. |
Beta Was this translation helpful? Give feedback.
-
|
Hi |
Beta Was this translation helpful? Give feedback.
-
|
Hello |
Beta Was this translation helpful? Give feedback.
-
|
Hey @s29papi, 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.
So I think you can do that, but its definitely off the happy path so we can't provide any guarantees that it'll work. We also wouldn't be able to provide very much support because its your own custom build.
To answer your original question: no its not mandatory because its MIT licensed you can do whatever you want with it and we encourage experimentation.