It hasn’t even been a week since the merge…
Many had hoped a new ETH fork would be the savior. I always had serious doubts/reservations about the long-term viability there.
Mining profitability in general sucks. GPU miner consolidation is underway.
Nothing is going in favor for miners at the moment, poor market sentiment, poor macro and low/non-existent profitability due to excess capacity from ETH.
Sad but just true for now anyway.
That has put a tremendous stress on miners. Many are powering down.
Many miners are in a state of agitation also, looking at the difficulty adjustment being slow on Ergo is one of those points of extra pain that doesn’t help the current sentiment.
Difficulty adjustments can be tracked here.
cds.oette.info/ergo_diff.htm
The delayed difficulty adjustment one thing many miners see as a con of Ergo. When there is a temporary rapid spike in hash rate it can create a period of rapid blocks, then a type of difficulty bomb.
We had like 200–300 TH/s in one day, (which is pretty insane in normal conditions) that brought fast blocks everyone loved, now we are working our way through slow blocks as things rebalance.
Some miners are worried that this diff adjustment may create an opening for a hopping attack.
This is something we recommend users/miners begin to track as the difficulty normalizes. This is an important metric we need to track as an ecosystem moving forward, as it is critical to understand regarding potential changes.
https://www.ergoforum.org/t/hopping-monitoring-post-merge/3876
Miners asked for the EF’s feedback. We have formed a forum channel and welcome the formation of group to discuss potential changes, designs, and EIP (Ergo Improvement Proposal)
https://www.ergoforum.org/t/diff-adjustment-potential-design-tradeoffs/3875
Many see the Merge as a once in a lifetime event, the effects of which will pass as the adjustment stabilizes and are not concerned. However, this type if conflict in a community is worth understanding, tracking, and potentially building a solution for.
Below are some comments from the discussion. We like to keep an open and engaged ecosystem. So please feel free to join the forum links above. Ergo is a grassroots community, solutions, discussions, improvements need to be subject to community feedback/input to prevent centralization of control.
Decentralized governance is always a messy process but long term forum, discussion and debate is required to forge long term commitments and goals. We welcome that, but please keep it classy.
Everyone wants decentralization until they want a fast solution. Unfortunately that often recentralizes power.
A slow, methodical data driven community approach is superior, but that requires community involvement. Please join!
Armeanio — Ergo Foundation
I think purely reactive choices short term with the diff are dangerous, I also think putting no alternative in place moving forward is also a bad idea.
Painful to see loyal miners taking the hit post merge. I think history has shown this is something that can be unstable enough to interfere with miner’s short-term mining revenue forecasting and a lack of predictability disrupts their business.
The merge capacity moving off ETH has made situation potentially more exploitable. We need to take that risk seriously monitor the situation and put together a Plan B.
I think putting a community driven working group for a Plan B (change of diff adjustment), would be a good idea. From my perspective we need to go through a 3 part process.
Step 1- We need to set some principles in place moving forward to take into account some of the intricacies built into the diff adjustment. (planning)
Step 2- Plan B needs to be built, and properly tested, vs reactively thrown together plugged in. (implementation)
Step 3-General discussion/consensus regarding potential activation/implementation in regard to monitoring and reacting to hopping. (activation consensus)
Miners coming off ETH are somewhat used to block based diff adjustments but that would essentially rug all the governance power they currently hold over network adjustments. Which would give control to dev’s, which shouldn’t be the future we move forward as a network.
Change here most likely needs to be surgical meaning minimally invasive as possible. Governance needs to be taken into account. Compressing the epoch length hurts solo miners, small pools representation and will give more representation to larger pools. I would like to avoid that situation.
MHS_Sam — Rosen Bridge, Stratum Dev
my thought on this:
- Merge is not caused by us but we have to deal with it and we should take advantage from it.
- Anything now is in loss, not only gpu mining. Even PoS systems are in loss. Assume that cardano is giving you 3.5% yearly yield but you are in 80% loss from last year. Same for ETH staking atm. So nothing different here for miners.
- When you build a decentralized blockchain, it should work for decades at least if not centuries. Such black swan events like Merge is not happening often. A chain must work in such situations but having hashrate fluctuation and diff adjustment issues for a few weeks is sth that should be accepted after such ultra rare events.
- It might seem like a bug in short-term but ergo’s diff adjustment is a feature in long term. It works now however with some troubles for miners. Remember that it be designed for decades of use not. We cannot HF every few weeks when we see different situations.
- I’m not saying that it is flawless, maybe it is. We should discuss about it and change it if necessary. But the perspective should not be what can we do now for miner to be profitable, or what can we do 1–2 weeks after merge. The main principle here is being robust in long term.
- Everything here has some tradeoffs. Lowering the adj time will result in several attack vectors, less governance by miners, timestamping issues, etc…
- This adj method is provably working if the hashrate is high enough. High enough needs definition but I guess you know what I mean.
- We’re open to discussions and solutions but we have NO control over the chain. Any change should be done by miners at the end. So, we should discuss it with long term perspective and if a better solution emerged, it will be voted by miners. It’s not dev’s decision.
- I believe we will stabilize as time passes, maybe we have some issues for a few weeks. But later, it will be shown how robust is this method. I might be wrong, btw I’m not deciding here. As I told it should be discussed and the decision is on miners.
- So, I agree with @Armeanio. Let’s plan for joint group, discussions, decisions, implementations, etc.
Arhobe- Getblock.io
I think one thing people should keep in mind is that the difficulty is there for balance. People are complaining about less rewards today. However no one complained when the emissions were 3x the day of the merge. Over 104k erg was emitted versus the target of 34560
Could there be improvements to the difficulty adjustment? Sure, but I agree that making a knee jerk reaction and potentially disrupting the principles that ergo was built on isn’t the right direction either. It needs to be a very methodical approach.
Agreed. It was kind of a triple whammy that created this position. Increased difficulty combined with the drop in hash as well as market conditions. Perfect storm.
Maybe a biased opinion but to me this is the time miners should be looking beyond immediate profits and dig into the defi that has been built within the platform. I think people will find additional incentives that may not make up all of the difference in lost profits but may help. I also think this opens the opportunity for developers to build around some of these challenges. Creates unique use cases to be solved.
Kushti- Ergo Foundation
On difficulty readjustment, it is hot topic again these days.
I doubt there are ideal parameters here for all the possible scenarious.
Current readjustment worked well before the hard-fork, and after the main problem was about improper post-fork difficulty set manually.
Some parameters maybe insecure, e.g. diff recalc every 16 blocks when a node can accept a block with timestamp being 20 minutes in the future (so ~ 10 blocks).
I guess 128+ blocks epoch is okay. But then likely a lot of other things to be considered, such as capping max change per epoch.
It would be good to have a team which can do modelling and compose an EIP if there’s community support for quicker readjustment.
Hovewer, it requires a hard-fork and then it is another huge story about governance and not only.
But do we need it at all?
For HF, there could be 1 or 2 more issues to solve. For example, initial diff in nipopow. Not an issue for next few years at least, but would be good to fix at some point. Maybe could be solved via a SF only though.
Adjusting diff per block is insane, as timestamps are gameable a lot then. An epoch should be long enough to minimize effects of 20 mins probable cheating
