-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Addition: Add support for Hypra and EthashB3 #617
base: master
Are you sure you want to change the base?
Conversation
Currently Hypra supports EVM upto Shanghai. |
TODO: use in AccumulateRewards
Refactored CreateConsensusEngine
Update, I found where to define ethashb3 engine creation. IMO, i felt the CreateConsensusEngine was very busy and took it on my self to refactor that part so each engine is created in its own function and doesnt need more parameters passed through to 1 function, it now switches from the chainspec. This makes it easier and cleaner to add new censensus engines in future. Feel free to review it, i can revert the change if you decide its not appropriate. Ive kept the orignal CreateConsensusEngine for legacy reasons and some part of the codebase still use it. |
…CensensusEngineEthashB3
Just confirmed ethashb3 is now working and useable in a chain configuration. |
Ok, im 99% sure ive completed everything needed for Hypra to be compatible. However, upon testing. CoreGeth cant sync from a Geth node which all our current nodes run on. If i copy the chaindata into the coregeth directory it starts with all the blocks and another coregeth node can sync from that. But they are not able to connect to any geth nodes to stay in sync. Any ideas @meowsbits this would be needed for transition from geth to core-geth. |
From some testing ive done
|
Might be a Fork ID problem? On quick glance I didn't see any fork id files changed here yet... |
Just FYI, you could also use |
How can I build core-geth for linux and mac? Builds fine on Windows
|
Had a good run for 1 hour. But seems somewhere a a gas cost is different.
Cant figure out which EIP is responsable for the gas difference |
The
Check the
This is a tough problem. Many EIPs are gas cost adjustments. In order to debug you might try comparing block/tx trace results from the working client vs. the development one. With the A/B traces you can compare the block/tx opcode steps and their resulting states. Once you figure out which opcode step is mismatched, you can then cross-reference the target opcode against its associated gas-relevant EIPs. |
Ultimately i figured out the problem by not syncing in mining block 1, and found that the block rewards were wrong because schedulereward would only return custom rewards for ethash, so i had to add ethashb3 to that and it worked.
im doing a full sync right now to find what point in the chain gas difference happens and with core-geth it is rather slow. Its only syncing 100 blocks every 8 seconds. With standard geth it does 2048 blocks every 2 seconds. |
Update: Sync is now 200k blocks off our gaspar fork without any issues so i think that narrows it down to something within the london/merge/shangai evm upgrades that were part of Gaspar First block from Gaspar upgrade which i deployed a shangai test contract failed to sync
|
Ok, i cant figure out what is or isnt enabled for the Gaspar fork to work. Gaspar was just to upgrade the EVM on Hypra from Berlin to Shanghai, which as far as i can see is EIP3855, EIP3860, EIP3198, EIP3529. |
The issue might be the IntrinsicGas function, as in our geth this is not enabled as part of enabling the EIP3860 EVM upgrade to CREATE and CREATE2 gas https://github.com/etclabscore/core-geth/blob/master/core/state_transition.go#L103-L109 Looks like this EIP effects more than was activated on Hypra network. |
NOTE: This still doesn't sync past gaspar :(
... to me this suggests its not the gas (since that was ==), but the receipts or their transactions.. |
Would the bloom be different because the transcation failed? As that transcation used 100% gas which succeeds on mainnet, but if the there is a gas difference. between whats expected and what core-geth gives, would give different bloom since the gas limit was reached so it cant report gas difference? Another indicator of this is that the local reported state has empty logs, but that transcation should have 1 log Do you have discord so we can have a call about it? Because im stuck, i have ideas, but testing some of them didnt change anything or completely invalidated the chain. I think doing a pair code to just get this over the line and syncing past Gaspar fork would be useful. |
Can you say more about this? I went to find your source here but they look identical to me. Have you tried comparing results of I'm willing to meet, but would like a little more context about what you've tried and haven't yet. |
That paramter is bound to Shanghai but we didnt activate shanghai we only activate the shanhai EVM code with our gaspar fork here and here. I missed that when doing Gaspar.
I havnt yet, not really sure how to since it rejects the block.
What ive tested is commited. The last thing im going to test is just defining gaspar in params and adding that to enable the evm opcodes. if thaty doesnt work im completely lost. |
Ok, I fixed the EVM issue it looks like its now fully syncing. Currently doing a full sync from start, will see if it keeps insync. |
Ok, its still syncing, but very slowly. There seems to be a performance issue with pebble, switching to leveldb and syncing is fast again. Full import completed with no invalid blocks ✅ Status Syncs mainnet Just need to figure out why its trying to generate the same dag multiple times and delete it multiple time. It was really bad on epoch 5 |
Hypra core-geth quick fix.
This pull request is draft for now as we go through the steps to add support for Hypra network.
Hypra is a custom Proof-of-Work chain based on Ethereum, but recently we have had difficulty to upgrade the chain with upstream ethereum features. We want to include these changes in core-geth to make ethashb3 available for use in other chains and allow for easier upgrade of the Hypra network.
https://www.hypra.network/blog/the-future-of-geth-and-hypra.html
Our end goal is to add support for Hypra network to core-geth under the
--hypra
flag, and maintain our own version where Hypra is the default network, pulling down upstream updates and pushing updates when hypra adopts a fork.Our current geth code avalible here: https://github.com/Rethereum-blockchain/go-rethereum
Merge checklist