NativeChain optionally require MetaChain Execution Layer?

[fuxingloh]

What would you like to be added:

While the current proposed specification (earmark for documentation in #8) requires MetaChain to run alongside NativeChain 100% of the time. This issue proposes the possibility of running NativeChain without connectivity to MetaChain for sustaining existing node operator operations.

While for miners, it is required (or preferably required) for them to have both chains up since they need introspection to the internal state of both chains for trustless bridging. A case can be made for a miner that doesn't care about mining on MetaChain (due to the cost of maintaining both chains and ignoring EVM chain since rewards come from Native chain only) and modify their node such that they always mine an empty block/template for EVM. (Due to trustless bridging, they can implement "mindless bridging" where the modified node doesn't process trustless bridging and take the amount as it is without during state verification.)

That being said, tokenomics could easily be adjusted for "forced" participation on MetaChain. Economically incentivizing miners to run EVM nodes when a percentage of their rewards can only be claimed on the EVM side.

While for the connectivity providers (e.g. think ocean or infura) that don't care about EVM DFI and only process UTXO DFI. They "technically" don't need to be aware of the EVM state or have no concern over the "internal state" of Meta Chain.

Why is this needed:

• It won't force immediate deprecation/upgrade on node operators as there are increased complexity and changes to operation when running 2 nodes.
• Allow non miners to run Native Chain without Meta Chain.

[defichain-bot]

@fuxingloh: Thanks for opening an issue, it is currently awaiting triage.

The triage/accepted label can be added by foundation members by writing /triage accepted in a comment.

Details

I am a bot created to help the DeFiCh developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[fuxingloh]

Related comment from #106 (comment)

Part of it. With DMC embedded, the "server profile" and server maintenance's operational flow must be changed if we force defid to be prepackaged. Several operators such as exchanges, individuals, and node operators would have to reconfigure their setup to fit the runtime requirements running defid. It's not simply a plug-and-play since these must be pre-communicated, tested, and operationalized.

[prasannavl]

The fundamental way to think of this, is that EVM is just a part of defichain consensus (whether it's a separate chain or not is an internal detail of DeFiChain consensus). There is no reason for operators to think of them as 2 separate chains. The data will be all inclusively managed by defid.

This requirement will unnecessarily complicate things further to allow things to be run separately, exposing implementation details into the user world, since now there needs to logic to ignore EVM consensus, which now creates a partial validation case, which defeats the purpose of validation in the first place. There shouldn't be any need or separation externally when everything is just a part of the defid.

[prasannavl]

In summary:

• Operators shouldn't be thinking of these as 2 different chain. It's still just DeFiChain. That's it.
• EVM layer in it's current form utilizing substrate libraries to implement it as isolated chain is an internal implementation detail. This could potentially change at any point (if substrate doesn't fit the needs or a different EVM impl is better suited at a later point).
• Validation should be either all or nothing. Creating a partial validation condition is a rabbit hole that I'd wouldn't start.
• Operators of masternodes will have to need no additional difference when thought of this way. All existing operational process work exactly as it is. Makes things easier to reason with, simplifies developer experience, testing, all of it. Running both together shouldn't matter from a computational perspective when it's all managed by the same process and crash boundaries. The only additional cost is data. That's unavoidable. I'd accept that as a technical requirement and work on larger optimizations for data overall, instead of splitting these into 2 just for the sake of data.

[prasannavl]

Adding more details:

It won't force immediate deprecation/upgrade on node operators as there are increased complexity and changes to operation when running 2 nodes.

• There will be no increased complexity on any level with the current mechanism of integration worked on defid, and running 2 nodes is not a requirement that we'll pass on to users at all. It's a testing only case / advanced case to separate and run for those who choose to, who are expected to understand the complexity if they choose to. By default is, it's fully integrated and managed by defid.

Allow non miners to run Native Chain without Meta Chain.

• This defeats the purpose of validation on non-miners. Non miner nodes cannot trust anything - as there is no way to validate the full block even if it's just one piece of information that can no longer be trusted. Block trust should always be reliable without compromises.

While for the connectivity providers (e.g. think ocean or infura) that don't care about EVM DFI and only process UTXO DFI. They "technically" don't need to be aware of the EVM state or have no concern over the "internal state" of Meta Chain.

To deal with infrastructural components, data pruning and manual arguments for the RPC port of the Ethereum JSON RPC that can potentially be managed separately, can be used to separate it in Ocean environments as advanced cases. Miners or not otherwise should not have different validation paths.

Native UTXO doesn't care about EVM state, but just the final output today. But when there's are cross native calls that's exposed as op-codes in EVM, there needs to be two-way trust, always.

[fuxingloh]

@prasannavl generally, I agree with your concerns. The insights are great.

The only doubt/question I have is the operational workflow of running the new "defid" and communicating that with our partners is quite a challenge. The end-goal north-star would be scraping this issue, but till we have a sound resolution to address the operational workflow. I don't have a good answer for it yet.

@wafflespeanut, what's your take?

Related comment from #106 (comment)

Part of it. With DMC embedded, the "server profile" and server maintenance's operational flow must be changed if we force defid to be prepackaged. Several operators such as exchanges, individuals, and node operators would have to reconfigure their setup to fit the runtime requirements running defid. It's not simply a plug-and-play since these must be pre-communicated, tested, and operationalized.

[wafflespeanut]

The only doubt/question I have is the operational workflow of running the new "defid" and communicating that with our partners is quite a challenge. The end-goal north-star would be scraping this issue, but till we have a sound resolution to address the operational workflow. I don't have a good answer for it yet.

As far as I can see, the only change from an external perspective will be a bigger size for defid executable. Unless we concretely know that running both of them in parallel is gonna hurt the performance of either, I'd say we can go ahead with our current plan of prepackaging. If it causes problems when we try it out, then we always have the RPC work to fallback.

[fuxingloh]

The only doubt/question I have is the operational workflow of running the new "defid" and communicating that with our partners is quite a challenge. The end-goal north-star would be scraping this issue, but till we have a sound resolution to address the operational workflow. I don't have a good answer for it yet.

As far as I can see, the only change from an external perspective will be a bigger size for defid executable. Unless we concretely know that running both of them in parallel is gonna hurt the performance of either, I'd say we can go ahead with our current plan of prepackaging. If it causes problems when we try it out, then we always have the RPC work to fallback.

Yup, sounds good. I was doing back of the mind calculation the other day; it's insignificant and doesn't warrant a change of operations, with at most an increase of 1-2GB RAM and 1 CPU at most. Storage increase will growth will be slow and linear and won't result in drastic operational changes either.

[fuxingloh]

Will keep this open for now since this thread wasn't triage/accepted to be worked on either, acting more as an RFC.