8

The description of Ethereum StackExchange is "Ethereum, the decentralized application platform and smart contract enabled blockchain" (wasn't sure where to find more detailed info, this info comes when voting to close a question).

If I understand the first part correctly (decentralized application platform), it refers to the EVM. Based on that, we could/should also provide support for other blockchains which are based on the EVM, such as Matic and Tron.

I'm quite sure the answer is no, but just wanted to raise discussion.

2
7

I actually had the same doubt, since I was somehow involved in a project with Hyperledger Fabric where they were using Fabric's EVM to port some smart contracts from Ethereum coded in Solidity.

Event the context is not Ethereum, the language is the Ethereum's main one, so I guess we should address questions as long as they are only referred to Solidity, excluding other issues related to infrastructure, nodes, etc.

I only wonder whether EVM-enabled blockchains are 100% compatible with Ethereum's EVM. Otherwise, we might be receiving issues that indeed, do not happen in Ethereum.

5

This stackExchange supports private Ethereum blockchains (even if heavily modified), Rinkeby, Kovan and all the testnets even if they are quite different than Ethereum mainnet.

By that logic, we should support blockchains that are very similar to Ethereum (EVM-compatible, uses Solidity, compatible with common web3 libraries, etc.)

It makes absolutely no sense to have a separate StackExchange for, say, Binance Smart Chain. 99% of the questions have the exact same answer if you change a word or two.

5

We have been accepting questions about Quorum for some time. Although it is clearly different in non-trivial ways, it is Ethereum-like with a few twists. While there is a modest risk of losing focus, I think the benefits of consistently accepting questions about EVM variants outweigh the concern about noise.

Questions about ETH 2.0, which is less like Ethereum 1.0 than most of the variants we're talking about, seem to be acceptable. In a similar vein, there are adjacent technologies, like layer-2, automated market makers, oracles, etc. that Ethereum developers may have questions about. I don't find those questions inappropriate and this is the go-to place for answers and friendly help.

Competitive chains might seem like adversaries to Ethereum but I don't think this community should carry that torch. We should be supportive of developers working in this field and the reality is that clients ask about deployment platform options. This should be a place to get answers.

It would probably be very beneficial to establish some tags for other chains and technologies (as we have done for Quorum, Uniswap, etc.), to clearly show when questions/answers might pertain only to a particular environment.

In summary, I incline to an inclusive scope rather than an exclusive focus.

1

I would say we need to support other EVM based chains, as long as it is not end-user support.

  • The choice of which EVMs are "Ethereum" and "good" or "bad" is quite arbitrary, like Arbitrum (pun intended)

  • We already have a close option for "Third party product" issues, like centralised exchange withdrawals

Personally, I dislike cloning EVM and then pushing the developer support and education back to the Ethereum mainnet developers (cough BSC cough). It's losing proposition for Ethereum itself. However Ethereum mainnet is cost prohibitive for a lot of developers, so there is that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .