Coder Social home page Coder Social logo

axieinfinity / ronin Goto Github PK

View Code? Open in Web Editor NEW
62.0 12.0 27.0 154.78 MB

A DPoS blockchain.

License: GNU Lesser General Public License v3.0

Dockerfile 0.01% Makefile 0.10% Go 90.11% Shell 0.25% NSIS 0.16% Ruby 0.01% Python 0.04% JavaScript 3.09% HTML 0.08% Solidity 0.11% Assembly 0.67% C 4.75% M4 0.18% Java 0.21% Sage 0.21%

ronin's Introduction

Go Ronin

Official Golang execution layer implementation of the Ronin protocol. It is a fork of Go Ethereum - https://github.com/ethereum/go-ethereum and EVM compatible.

Ronin consensus uses Proof of Staked Authority, a combination of dPoS and PoA, to increase the level of decentralization and allows the token holders to join the network as validators

Check out the whitepaper for more information.

Discord

Executables

The go-ethereum project comes with several wrappers/executables found in the cmd directory.

Command Description
ronin Our main Ronin CLI client. It is the entry point into the Ronin network (main-, test- or private net), capable of running as a full node (default), archive node (retaining all historical state) or a light node (retrieving data live). It can be used by other processes as a gateway into the Ronin network via JSON RPC endpoints exposed on top of HTTP, WebSocket and/or IPC transports. ronin --help and the CLI page for command line options.
clef Stand-alone signing tool, which can be used as a backend signer for ronin.
devp2p Utilities to interact with nodes on the networking layer, without running a full blockchain.
abigen Source code generator to convert Ethereum contract definitions into easy to use, compile-time type-safe Go packages. It operates on plain Ethereum contract ABIs with expanded functionality if the contract bytecode is also available. However, it also accepts Solidity source files, making development much more streamlined. Please see our Native DApps page for details.
bootnode Stripped down version of our Ethereum client implementation that only takes part in the network node discovery protocol, but does not run any of the higher level application protocols. It can be used as a lightweight bootstrap node to aid in finding peers in private networks.
evm Developer utility version of the EVM (Ethereum Virtual Machine) that is capable of running bytecode snippets within a configurable environment and execution mode. Its purpose is to allow isolated, fine-grained debugging of EVM opcodes (e.g. evm --code 60ff60ff --debug run).
rlpdump Developer utility tool to convert binary RLP (Recursive Length Prefix) dumps (data encoding used by the Ethereum protocol both network as well as consensus wise) to user-friendlier hierarchical representation (e.g. rlpdump --hex CE0183FFFFFFC4C304050583616263).
puppeth a CLI wizard that aids in creating a new Ethereum network.

Running ronin

Going through all the possible command line flags is out of scope here (please consult our CLI Wiki page), but we've enumerated a few common parameter combos to get you up to speed quickly on how you can run your own geth instance.

Requirements

Running a full Ronin node:

  • CPU: Equivalent of 8 AWS vCPU
  • RAM: 16GB
  • Storage: At least 1 TB high-speed SSD
  • Network: Reliable IPv4 or IPv6 network connection, with an open public port

Running an archive Ronin node:

  • CPU: Equivalent of 8 AWS vCPU
  • RAM: 16GB
  • Storage: At least 5 TB high-speed SSD
  • Network: Reliable IPv4 or IPv6 network connection, with an open public port

Building the source

Building ronin requires both a Go (version 1.17 or later) and a C compiler. You can install them using your favourite package manager. Once the dependencies are installed, run

make ronin

or, to build the full suite of utilities:

make all

Init genesis

Before running a full node, init genesis block is necessary

ronin init --datadir /opt/ronin genesis/mainnet.json

Full node on the main Ronin network

$ ronin --http.api eth,net,web3,consortium --networkid 2020 --discovery.dns enrtree://AIGOFYDZH6BGVVALVJLRPHSOYJ434MPFVVQFXJDXHW5ZYORPTGKUI@nodes.roninchain.com --datadir /opt/ronin --port 30303 --http --http.corsdomain '*' --http.addr 0.0.0.0 --http.port 8545 --http.vhosts '*' --ws --ws.addr 0.0.0.0 --ws.port 8546 --ws.origins '*' 

This command will:

  • Start ronin in full sync mode (default, can be changed with the --syncmode flag), causing it to download more data in exchange for avoiding processing the entire history of the Ronin network, which is very CPU intensive.

Configuration

As an alternative to passing the numerous flags to the ronin binary, you can also pass a configuration file via:

$ ronin --config /path/to/your_config.toml

To get an idea of how the file should look like you can use the dumpconfig subcommand to export your existing configuration:

$ ronin --your-favourite-flags dumpconfig

Programmatically interfacing ronin nodes

As a developer, sooner rather than later you'll want to start interacting with ronin and the Ronin network via your own programs and not manually through the console. To aid this, ronin has built-in support for a JSON-RPC based APIs which are the same as Ethereum that can be found at (standard APIs and ronin specific APIs). These can be exposed via HTTP, WebSockets and IPC (UNIX sockets on UNIX based platforms, and named pipes on Windows).

The IPC interface is enabled by default and exposes all the APIs supported by ronin, whereas the HTTP and WS interfaces need to manually be enabled and only expose a subset of APIs due to security reasons. These can be turned on/off and configured as you'd expect.

HTTP based JSON-RPC API options:

  • --http Enable the HTTP-RPC server
  • --http.addr HTTP-RPC server listening interface (default: localhost)
  • --http.port HTTP-RPC server listening port (default: 8545)
  • --http.api API's offered over the HTTP-RPC interface (default: eth,net,web3)
  • --http.corsdomain Comma separated list of domains from which to accept cross origin requests (browser enforced)
  • --ws Enable the WS-RPC server
  • --ws.addr WS-RPC server listening interface (default: localhost)
  • --ws.port WS-RPC server listening port (default: 8546)
  • --ws.api API's offered over the WS-RPC interface (default: eth,net,web3)
  • --ws.origins Origins from which to accept websockets requests
  • --ipcdisable Disable the IPC-RPC server
  • --ipcapi API's offered over the IPC-RPC interface (default: admin,debug,eth,miner,net,personal,shh,txpool,web3)
  • --ipcpath Filename for IPC socket/pipe within the datadir (explicit paths escape it)

You'll need to use your own programming environments' capabilities (libraries, tools, etc) to connect via HTTP, WS or IPC to a geth node configured with the above flags and you'll need to speak JSON-RPC on all transports. You can reuse the same connection for multiple requests!

Note: Please understand the security implications of opening up an HTTP/WS based transport before doing so! Hackers on the internet are actively trying to subvert Ethereum nodes with exposed APIs! Further, all browser tabs can access locally running web servers, so malicious web pages could try to subvert locally available APIs!

How to contribute

Contribution guidelines

  • Quality: Code in the Ronin project should meet the style guidelines, with sufficient test-cases, descriptive commit messages, evidence that the contribution does not break any compatibility commitments or cause adverse feature interactions, and evidence of high-quality peer-review.
  • Size: The Ronin project's culture is one of small pull-requests, regularly submitted. The larger a pull-request, the more likely it is that you will be asked to resubmit as a series of self-contained and individually reviewable smaller PRs.
  • Maintainability: If the feature will require ongoing maintenance (eg support for a particular branch of database), we may ask you to accept responsibility for maintaining this feature
  • Commit message: Commit messages of Ronin project follows https://www.conventionalcommits.org/en/v1.0.0/

Submit an issue

  • Create a new issue
  • Comment on the issue (if you'd like to be assigned to it) - that way our team can assign the issue to you
  • If you do not have a specific contribution in mind, you can also browse the issues labelled as help wanted
  • Issues that additionally have the good first issue label are considered ideal for first-timers

Submit your PR

  • After your changes are committed to your GitHub fork, submit a pull request (PR) to the master branch of the axieinfinity/ronin repo
  • In your PR description, reference the issue it resolves (see linking a pull request to an issue using a keyword)
    • ex: [FIXES #123] feat: update out of date content

Wait for review

  • The team reviews every PR
  • Acceptable PRs will be approved & merged into the master branch

Release

License

The go-ethereum library (i.e. all code outside of the cmd directory) is licensed under the GNU Lesser General Public License v3.0, also included in our repository in the COPYING.LESSER file.

The go-ethereum binaries (i.e. all code inside of the cmd directory) is licensed under the GNU General Public License v3.0, also included in our repository in the COPYING file.

ronin's People

Contributors

acud avatar arachnid avatar cjentzsch avatar cubedro avatar debris avatar dnk90 avatar fjl avatar gavofyork avatar gballet avatar gluk256 avatar holiman avatar holisticode avatar hosyvietanh avatar janos avatar jpeletier avatar jsvisa avatar karalabe avatar mariusvanderwijden avatar matthalp-zz avatar minh-bq avatar nolash avatar nonsense avatar obscuren avatar renaynay avatar rjl493456442 avatar tgerring avatar ucwong avatar vbuterin avatar zelig avatar zsfelfoldi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ronin's Issues

Node synchronization failed

Error: invalid merkle root (remote: d4e2c4914ae8699143721e6c16fcf9b7be76b82e22ca97d12b09508ef1997550 local: e8acb294c38a1f8ab48e15c7597809264cd2c5276dc790bf520e5fbf292094cf)
##############################

WARN [03-12|15:10:54.644] Synchronisation failed, dropping peer peer=161f2ff82d1cf1e03ea81176d01a5b33450f721fb41caad6395a1157a47127de err="retrieved hash chain is invalid: invalid merkle root (remote: d4e2c4914ae8699143721e6c16fcf9b7be76b82e22ca97d12b09508ef1997550 local: e8acb294c38a1f8ab48e15c7597809264cd2c5276dc790bf520e5fbf292094cf)"
INFO [03-12|15:10:54.957] Snapshot extension registration failed peer=8058887b err="peer connected on snap without compatible eth support"
INFO [03-12|15:10:55.469] Snapshot extension registration failed peer=8063c721 err="peer connected on snap without compatible eth support"
INFO [03-12|15:11:01.867] Looking for peers peercount=1 tried=22 static=0
INFO [03-12|15:11:03.189] Snapshot extension registration failed peer=80620cb3 err="peer connected on snap without compatible eth support"
INFO [03-12|15:11:12.201] Looking for peers peercount=1 tried=15 static=0
INFO [03-12|15:11:22.529] Looking for peers peercount=2 tried=29 static=0

May I ask how to solve this problem ?

Can't connect to any peer

After a long time, still can't connect to any peer

ronin --datadir=/ronin/data --networkid 2020 --bootnodes enode://62a6c6d483bbebe9e2e2c9abd6e053bf81b7ce8662defd40f6ee32665a83dbfaf1fe32e6855efde06e04d6f2d7ce8ad411ef7fc77b48d95134b3cb9b505e2058@34.66.90.95:30303,enode://62a6c6d483bbebe9e2e2c9abd6e053bf81b7ce8662defd40f6ee32665a83dbfaf1fe32e6855efde06e04d6f2d7ce8ad411ef7fc77b48d95134b3cb9b505e2058@104.198.242.88:30303,enode://62a6c6d483bbebe9e2e2c9abd6e053bf81b7ce8662defd40f6ee32665a83dbfaf1fe32e6855efde06e04d6f2d7ce8ad411ef7fc77b48d95134b3cb9b505e2058@34.132.30.191:30303 --port 30303 --http --http.corsdomain '*' --http.addr 0.0.0.0 --http.port 8545 --http.vhosts '*' --ws --ws.addr 0.0.0.0 --ws.port 8546 --ws.origins '*'

Logs:
INFO [03-13|06:14:22.406] HTTP server started endpoint=[::]:8545 prefix= cors='' vhosts=''
INFO [03-13|06:14:22.406] WebSocket enabled url=ws://[::]:8546
INFO [03-13|06:14:22.506] Generated state snapshot accounts=8893 slots=0 storage=409.64KiB elapsed=112.778ms
INFO [03-13|06:14:24.947] New local node record seq=1,678,688,062,404 id=6a001edb7d43afb5 ip=3.69.231.16 udp=30303 tcp=30303
INFO [03-13|06:14:32.440] Looking for peers peercount=1 tried=126 static=0
INFO [03-13|06:14:42.864] Looking for peers peercount=0 tried=78 static=0
INFO [03-13|06:14:52.976] Looking for peers peercount=1 tried=129 static=0
INFO [03-13|06:15:02.994] Looking for peers peercount=1 tried=156 static=0
INFO [03-13|06:15:13.001] Looking for peers peercount=0 tried=177 static=0
INFO [03-13|06:15:23.003] Looking for peers peercount=0 tried=173 static=0
INFO [03-13|06:15:33.420] Looking for peers peercount=0 tried=131 static=0
ERROR[03-13|06:15:39.596] Snapshot extension registration failed peer=8813746d err="peer connected on snap without compatible eth support"
INFO [03-13|06:15:43.519] Looking for peers peercount=0 tried=206 static=0
INFO [03-13|06:15:53.527] Looking for peers peercount=2 tried=41 static=0
INFO [03-13|06:16:03.535] Looking for peers peercount=0 tried=218 static=0
INFO [03-13|06:16:13.542] Looking for peers peercount=0 tried=110 static=0
ERROR[03-13|06:16:14.942] Snapshot extension registration failed peer=bcbefcff err="peer connected on snap without compatible eth support"
INFO [03-13|06:16:23.754] Looking for peers peercount=0 tried=127 static=0
INFO [03-13|06:16:33.762] Looking for peers peercount=2 tried=172 static=0
INFO [03-13|06:16:43.935] Looking for peers peercount=1 tried=163 static=0
INFO [03-13|06:16:53.952] Looking for peers peercount=1 tried=164 static=0
ERROR[03-13|06:16:57.747] Snapshot extension registration failed peer=b3b03e49 err="peer connected on snap without compatible eth support"
INFO [03-13|06:17:05.814] Looking for peers peercount=0 tried=170 static=0
INFO [03-13|06:17:15.851] Looking for peers peercount=1 tried=111 static=0
INFO [03-13|06:17:26.037] Looking for peers peercount=0 tried=201 static=0
INFO [03-13|06:17:46.442] Looking for peers peercount=0 tried=178 static=0
INFO [03-13|06:17:56.444] Looking for peers peercount=0 tried=195 static=0
INFO [03-13|06:18:06.641] Looking for peers peercount=1 tried=115 static=0
ERROR[03-13|06:18:08.915] Snapshot extension registration failed peer=63cbe74f err="peer connected on snap without compatible eth support"
ERROR[03-13|06:18:09.651] Snapshot extension registration failed peer=63b71335 err="peer connected on snap without compatible eth support"
ERROR[03-13|06:18:14.549] Snapshot extension registration failed peer=2da2309e err="peer connected on snap without compatible eth support"
INFO [03-13|06:18:16.853] Looking for peers peercount=0 tried=196 static=0
INFO [03-13|06:18:27.527] Looking for peers peercount=0 tried=110 static=0
INFO [03-13|06:18:37.536] Looking for peers peercount=0 tried=191 static=0
INFO [03-13|06:18:47.881] Looking for peers peercount=0 tried=115 static=0
INFO [03-13|06:18:58.026] Looking for peers peercount=0 tried=83 static=0
INFO [03-13|06:19:08.030] Looking for peers peercount=0 tried=108 static=0

Websocket endpoint

Hi Team !

I am looking for websocket endpoint to your testnet.

Please help me to get that !

can't find peers

Can you provide a few peers?

INFO [11-19|19:24:27.144] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|19:24:42.144] Looking for peers                        peercount=0 tried=1 static=0
INFO [11-19|19:25:02.144] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|19:54:27.330] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|19:54:42.331] Looking for peers                        peercount=0 tried=1 static=0
INFO [11-19|19:55:02.331] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|20:24:27.042] Writing clean trie cache to disk         path=/mnt/sdb1/node/ronin/data/ronin/triecache threads=1
INFO [11-19|20:24:27.043] Regenerated local transaction journal    transactions=0 accounts=0
INFO [11-19|20:24:27.044] Persisted the clean trie cache           path=/mnt/sdb1/node/ronin/data/ronin/triecache elapsed=1.943ms
INFO [11-19|20:24:27.519] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|20:24:42.519] Looking for peers                        peercount=0 tried=1 static=0
INFO [11-19|20:25:02.520] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|20:54:27.208] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|20:54:42.209] Looking for peers                        peercount=0 tried=1 static=0
INFO [11-19|20:55:02.209] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|21:24:27.042] Writing clean trie cache to disk         path=/mnt/sdb1/node/ronin/data/ronin/triecache threads=1
INFO [11-19|21:24:27.043] Regenerated local transaction journal    transactions=0 accounts=0
INFO [11-19|21:24:27.044] Persisted the clean trie cache           path=/mnt/sdb1/node/ronin/data/ronin/triecache elapsed=2.006ms
INFO [11-19|21:24:27.395] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|21:24:42.396] Looking for peers                        peercount=0 tried=1 static=0
INFO [11-19|21:25:02.396] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|21:54:27.583] Looking for peers                        peercount=0 tried=0 static=0
INFO [11-19|21:54:42.583] Looking for peers                        peercount=0 tried=1 static=0
INFO [11-19|21:55:02.584] Looking for peers                        peercount=0 tried=0 static=0

fullCallTracing is not working properly

System information

OS & Version: OSX
Commit hash : eec1bd7

Expected behaviour

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "internalTxs": [
      {
        "transactionHash": "0xe9c840187b9271f5c2a104c4fbb48b975b3cf79c53396c696be5e5c524341b0c",
        "result": {
          "type": "CALL",
          "order": 0,
          "from": "0x968d0cd7343f711216817e617d3f92a23dc91c07",
          "to": "0x30800297f77fe3615e3b44ac00f8f0c5a5625281",
          "value": "0x0",
          "gas": "0x1f7a8",
          "gasUsed": "0x4285",
          "input": "0x8a4068dd",
          "output": "0x",
          "calls": [
            {
              "type": "CALL",
              "order": 107,
              "from": "0x30800297f77fe3615e3b44ac00f8f0c5a5625281",
              "to": "0x2e76240d47cf6a5f319db4e681a5a0a4243297c1",
              "value": "0xde0b6b3a7640000",
              "gas": "0x1cf03",
              "gasUsed": "0x20d5",
              "input": "0x",
              "output": "0x",
              "error": "execution reverted",
              "calls": [
                {
                  "type": "CALL",
                  "order": 151,
                  "from": "0x2e76240d47cf6a5f319db4e681a5a0a4243297c1",
                  "to": "0xeaceb97203f458211e2e8f1254308ae09a4cc2ff",
                  "value": "0x1bc16d674ec80000",
                  "gas": "0x8fc",
                  "gasUsed": "0x0",
                  "input": "0x",
                  "output": "0x",
                  "error": "insufficient balance for transfer"
                }
              ]
            }
          ]
        }
      }
    ]
  }
}

Actual behaviour

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "internalTxs": [
      {
        "transactionHash": "0xe9c840187b9271f5c2a104c4fbb48b975b3cf79c53396c696be5e5c524341b0c",
        "result": {
          "type": "CALL",
          "order": 0,
          "from": "0x968d0cd7343f711216817e617d3f92a23dc91c07",
          "to": "0x30800297f77fe3615e3b44ac00f8f0c5a5625281",
          "value": "0x0",
          "gas": "0x1f7a8",
          "gasUsed": "0x4285",
          "input": "0x8a4068dd",
          "output": "0x",
          "calls": [
            {
              "type": "CALL",
              "order": 107,
              "from": "0x30800297f77fe3615e3b44ac00f8f0c5a5625281",
              "to": "0x2e76240d47cf6a5f319db4e681a5a0a4243297c1",
              "value": "0xde0b6b3a7640000",
              "gas": "0x1cf03",
              "gasUsed": "0x20d5",
              "input": "0x",
              "output": "0x",
              "error": "execution reverted"
            }
          ]
        }
      }
    ]
  }
}

Steps to reproduce the behaviour

  1. Create 3 three contracts that call to the other A -> B -> C
  2. Contract B does not have enough money to transfer to the contract C
  3. Call debug_traceInternalsAndAccountsByBlockHash
curl --location 'localhost:8545' \
--header 'Content-Type: application/json' \
--data '{
    "jsonrpc": "2.0",
    "method": "debug_traceInternalsAndAccountsByBlockHash",
    "params": [
        "0xe99c5951f0f4306b045d18e4f60575a1321e9dd7401702fb62c865e7d530e934",
        {
            "tracer": "callTracer2",
            "fullCallTracing": true
        }
    ],
    "id": "1"
}'

Notes

  • create and delegatecall opcodes have not implemented fullCallTracing yet

latest version errors? in logs.

I built the latest version (Neo 2.7.1) from the source. I am running go1.20.13 on Ubuntu 22.04.3 LTS.
I am receiving the following messages in my logs. Notice the impossible reorg error, block in the future error and that it skips the block number: 31,805,192. This is happening several times per minute.

INFO [02-09|21:26:57.162] [reorg][writeKnownBlock] current="{Number: 31895190, Hash: 0xd6767c12263a8e68b5c401a63b3d6da1eac93dfde152650f0d40e9fcb33a924b, Parent: 0x14875fe02e1eb18db8fa8cff0fdd3fa7f9392244b63604cbbab1baf41639e47a, Signer: 0x61089875fF9e506ae78C7FE9f7c388416520E386}" newBlock="{Number: 31895190, Hash: 0xd6767c12263a8e68b5c401a63b3d6da1eac93dfde152650f0d40e9fcb33a924b, Parent: 0x14875fe02e1eb18db8fa8cff0fdd3fa7f9392244b63604cbbab1baf41639e47a, Signer: 0x61089875fF9e506ae78C7FE9f7c388416520E386}"
ERROR[02-09|21:26:57.164] Impossible reorg, please file an issue oldnum=31,895,190 oldhash=d6767c..3a924b newnum=31,895,190 newhash=d6767c..3a924b
WARN [02-09|21:26:57.164] Synchronisation failed, dropping peer peer=e66dcf06945a0e15bc919b9403f6d10ff45d57d5d8887c4c218ca13997a9933b err="retrieved hash chain is invalid: block in the future"
INFO [02-09|21:26:59.859] Imported new chain segment blocks=1 txs=17 mgas=1.423 elapsed=19.326ms mgasps=73.646 number=31,895,191 hash=d04d4a..d43ccf dirty=255.75MiB
INFO [02-09|21:26:59.860] Unindexed transactions blocks=1 txs=2 tail=29,545,192 elapsed="261.261µs"
INFO [02-09|21:27:00.231] Snapshot extension registration failed peer=0e5ddf3e err="peer connected on snap without compatible eth support"
INFO [02-09|21:27:01.110] Snapshot extension registration failed peer=3c9012cf err="peer connected on snap without compatible eth support"
INFO [02-09|21:27:01.378] Deep froze chain segment blocks=20 elapsed=6.297ms number=31,805,191 hash=507d8b..4a856c
INFO [02-09|21:27:01.711] Snapshot extension registration failed peer=fc84034d err="peer connected on snap without compatible eth support"
INFO [02-09|21:27:01.812] Looking for peers peercount=5 tried=24 static=0
WARN [02-09|21:27:03.809] Synchronisation failed, dropping peer peer=e66dcf06945a0e15bc919b9403f6d10ff45d57d5d8887c4c218ca13997a9933b err=timeout
WARN [02-09|21:27:03.926] Synchronisation failed, dropping peer peer=5fdc0ddbd5efcde1fa91911c176b48ca3b3a25ae2e07850e93a4d3b2d0530a8e err="retrieved hash chain is invalid: block in the future"
INFO [02-09|21:27:03.927] Unindexed transactions blocks=1 txs=7 tail=29,545,193 elapsed="449.506µs"
WARN [02-09|21:27:03.927] Synchronisation failed, retrying err="peer is unknown or unhealthy"
INFO [02-09|21:27:04.187] Imported new chain segment blocks=1 txs=25 mgas=1.904 elapsed=33.863ms mgasps=56.233 number=31,895,193 hash=a145f4..ad6155 dirty=255.58MiB

I have tried deleting the chaindata and uploaded the latest snapshot. But it still is happening. When building from the source, all test pass and it builds clean with no errors.
I also made sure I init the genesis block before running. And also tried it using the same command line as shown on github:

ronin --http.api eth,net,web3,consortium --networkid 2020 --discovery.dns enrtree://AIGOFYDZH6BGVVALVJLRPHSOYJ434MPFVVQFXJDXHW5ZYORPTGKUI@nodes.roninchain.com --datadir /opt/ronin --port 30303 --http --http.corsdomain '' --http.addr 0.0.0.0 --http.port 8545 --http.vhosts '' --ws --ws.addr 0.0.0.0 --ws.port 8546 --ws.origins '*'

Same messages in the logs no matter how I try it with the new release.

Validator is slashed even though the node is not down

System information

Ronin version: 2.5.2-stable

Actual behaviour

A validator is slashed for missing inturn block even though its node is still running.

Expected behaviour

That validator is not slashed.

Log

INFO [04-22|17:03:13.005] 🔨 mined potential block                  number=23,452,749 hash=bdfbb5..37ed8a
INFO [04-22|17:03:13.005] Unindexed transactions                   blocks=1   txs=2   tail=21,102,750 elapsed="186.252µs"
INFO [04-22|17:03:13.007] Submitted block reward                   block=23,452,750 amount=0
INFO [04-22|17:03:13.008] Commit new mining work                   number=23,452,750 sealhash=c83398..5347e8 uncles=1 txs=0   gas=64909      fees=0               elapsed=2.375ms
WARN [04-22|17:03:13.008] Block sealing failed                     err="signed recently, must wait for others" height=23,452,750
INFO [04-22|17:03:13.073] Submitted block reward                   block=23,452,749 amount=1,196,040,000,000,000
INFO [04-22|17:03:13.076] Imported new chain segment               blocks=1   txs=2   mgas=0.125  elapsed=4.101ms     mgasps=30.410   number=23,452,749 hash=371125..fdf429 dirty=255.11MiB
INFO [04-22|17:03:13.077] Submitted block reward                   block=23,452,750 amount=0
INFO [04-22|17:03:13.078] Commit new mining work                   number=23,452,750 sealhash=c83398..5347e8 uncles=2 txs=0   gas=64909      fees=0               elapsed=1.885ms
INFO [04-22|17:03:16.008] Submitted block reward                   block=23,452,750 amount=888,280,000,000,000
INFO [04-22|17:03:16.010] Commit new mining work                   number=23,452,750 sealhash=21b289..75632b uncles=2 txs=1   gas=109,323    fees=0.00088828      elapsed=3.831ms
WARN [04-22|17:03:16.010] Block sealing failed                     err="signed recently, must wait for others" height=23,452,750
INFO [04-22|17:03:17.105] Slash validator                          number=23,452,750 spoiled=0x20238eB5643d4D7b7Ab3C30f3bf7B8E2B85cA1e7
INFO [04-22|17:03:17.106] Submitted block reward                   block=23,452,750 amount=11,730,600,000,000,000
INFO [04-22|17:03:17.129] [reorg][writeBlockWithState]             currentBlock="{Number: 23452749, Hash: 0xbdfbb54de843611f5f0f6f846ff26063241b84c64c476cbb33c60ab3b737ed8a, Parent: 0xaf31ae6d0b5d8f55b88d7f9dd159fa80adfb76856292061360852067f4071983, Signer: 0x20238eB5643d4D7b7Ab3C30f3bf7B8E2B85cA1e7}" currentTD=161,483,126 newBlock="{Number: 23452750, Hash: 0x840521e9b1e3fd0e6eabea4d2ee922d776e49e96e068f6305adfbb99ef01cccb, Parent: 0x371125c2f2100eefc80e00f6cf20caab03119037fc1bf50e94ab812ea1fdf429, Signer: 0xbD4bf317Da1928CC2f9f4DA9006401f3944A0Ab5}" newTD=161,483,129
INFO [04-22|17:03:17.129] Chain reorg detected                     number=23,452,748 hash=0xaf31ae6d0b5d8f55b88d7f9dd159fa80adfb76856292061360852067f4071983 drop=1 dropfrom=0xbdfbb54de843611f5f0f6f846ff26063241b84c64c476cbb33c60ab3b737ed8a add=2 addfrom=0x840521e9b1e3fd0e6eabea4d2ee922d776e49e96e068f6305adfbb99ef01cccb
INFO [04-22|17:03:17.130] Imported new chain segment               blocks=1   txs=5   mgas=0.700  elapsed=33.006ms    mgasps=21.197   number=23,452,750 hash=840521..01cccb dirty=255.10MiB
INFO [04-22|17:03:17.131] Unindexed transactions                   blocks=1   txs=2   tail=21,102,751 elapsed="467.329µs"
INFO [04-22|17:03:17.132] Submitted block reward                   block=23,452,751 amount=0

debug_traceBlockByNumber cannot process block

System information

OS & Version: OSX

Description

Block can not be executed when using api debug_traceBlockByNumber in debug mode

Expected behaviour

Data responded without error code and messages

Actual behaviour

Messages responded like below

{
    "jsonrpc": "2.0",
    "id": 1,
    "error": {
        "code": -32000,
        "message": "insufficient funds for gas * price + value: address 0xbD4bf317Da1928CC2f9f4DA9006401f3944A0Ab5 have 0 want 1190760000000000"
    }
}

Steps to reproduce the behaviour

  • Enable debug mode
  • The block must have at least 2 transactions
  • miner's balance must be less than block's gas used
  • Call debug_traceBlockByNumber
curl --location 'https://api-archived.roninchain.com/rpc' \
--header 'Content-Type: application/json' \
--data '{"method":"debug_traceBlockByNumber","params":["0x161520b", {"tracer": "callTracer"}],"id":1,"jsonrpc":"2.0"}'

Ronin Archival Snapshot

Hi All,
Can anyone provide me the link to download an archival snapshot for mainnet starting from Block 1.

Thanks,
Saloni

Node synching failed

Node synching failed:

Getting error as : Snapshot extension registration failed for ronin.

image

Can anyone help me with this?

Thanks,
Saloni.

2.5.0/2.5.1 restore from snapshot / init from genesis fail?

2.5.0 using genesis

main.main()
        github.com/ethereum/go-ethereum/cmd/ronin/main.go:279 +0x35
INFO [03-23|08:08:56.075] Maximum peer count                       ETH=50 LES=0 total=50
INFO [03-23|08:08:56.075] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
INFO [03-23|08:08:56.076] Set global gas cap                       cap=50,000,000
INFO [03-23|08:08:56.077] Allocated trie memory caches             clean=154.00MiB dirty=256.00MiB
INFO [03-23|08:08:56.077] Allocated cache and file handles         database=/opt/ronin/ronin/chaindata cache=512.00MiB handles=32767
INFO [03-23|08:08:56.116] Opened ancient database                  database=/opt/ronin/ronin/chaindata/ancient readonly=false
INFO [03-23|08:08:56.117] Initialised chain configuration          config="{ChainID: 2020 Homestead: 0 DAO: <nil> DAOSupport: false EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 Constantinople: 0 Petersburg: 0 Istanbul: 49777
78, Odysseus: 10301597, Fenix: <nil>, Muir Glacier: <nil>, Berlin: <nil>, London: <nil>, Arrow Glacier: <nil>, Engine: consortium, Blacklist Contract: 0x313b24994c93FA0471CB4D7aB796b07467041806, Fenix Validator Contract: <
nil>, ConsortiumV2: <nil>, ConsortiumV2.RoninValidatorSet: 0x0000000000000000000000000000000000000000, ConsortiumV2.SlashIndicator: 0x0000000000000000000000000000000000000000, ConsortiumV2.StakingContract: 0x00000000000000
00000000000000000000000000}"
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xb6f245]

goroutine 1 [running]:

2.5.1 using https://github.com/axieinfinity/ronin-snapshot / genesis

INFO [03-23|08:00:06.002] Persisted trie from memory database      nodes=36 size=3.87KiB time="129.602µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=-246.00B
Fatal: Failed to write genesis block: mismatching Fenix fork block in database (have 14938103, want <nil>, rewindto 14938102)

[Docker] bls error after upgrading saigon node

After changing docker image version in .env file and stop/start containers, i receive errors because bls_password isn't generated from entrypoint.sh and container is in restart loop

ERROR[09-09|07:56:12.214] Failed to open BLS wallet                err="open /ronin/bls_password: no such file or directory"
Fatal: Failed to register the Ethereum service: open /ronin/bls_password: no such file or directory
Fatal: Failed to register the Ethereum service: open /ronin/bls_password: no such file or directory

I stopped the containers, deleted bls_keystore directory, created bls_password file with random password and started containers again. Now a new bls errror occurs and container is in restart loop again

Found account Redacted
Error: Enable fast finality without providing BLS secret key

How to fix upgrade problems because of bls implementation?

make / make test fails with new go version 1.21

System information

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
go version go1.21.0 linux/amd64

Repeated on second machine running:

Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy
go version go1.21.0 linux/amd64

Expected behaviour

make ronin & make test would complete without issues.

Actual behaviour (immediately proceeding lines leading up to the failure during make test command)

github.com/ethereum/go-ethereum/internal/jsre

github.com/pyroscope-io/godeltaprof/internal/pprof

/root/go/pkg/mod/github.com/pyroscope-io/[email protected]/internal/pprof/delta_mutex.go:25:20: undefined: runtime_cyclesPerSecond
/root/go/pkg/mod/github.com/pyroscope-io/[email protected]/internal/pprof/proto.go:400:8: undefined: runtime_expandFinalInlineFrame
github.com/naoina/toml
github.com/ethereum/go-ethereum/console
util.go:46: exit status 1
exit status 1
make: *** [Makefile:40: all] Error 1

Steps to reproduce the behaviour

Install go version 1.21 and run make test. Afterwards: I then downgraded to version 1.20.7 and make ronin / make test completed properly as it had prior to go version 1.21 being installed.

Add recent signer check to snapshot

In clique, there is a recent signer check in Snapshot.apply function
https://github.com/ethereum/go-ethereum/blob/e394d01f2a578765868355e98898bd17d3d076c1/consensus/clique/snapshot.go#L225-L229

Currently, consortium doesn't have this check, only checks recent signer in Prepare (produce block path) and VerifySeal (verify block path 86ccb3e) function. This check in Snapshot.apply checks the block headers collected from latest snapshot to current block must obey the rule that a signer can only seal a block once in N/2 period (N is the length of snap.SignerList).
The block headers are collected in 2 ways

  1. From the parents arguments of Consortium.snapshot function
  2. Read from chain header reader using block number
    if len(parents) > 0 {
    // If we have explicit parents, pick from there (enforced)
    header = parents[len(parents)-1]
    if header.Hash() != hash || header.Number.Uint64() != number {
    return nil, consensus.ErrUnknownAncestor
    }
    parents = parents[:len(parents)-1]
    } else {
    // No explicit parents (or no more left), reach out to the database
    header = chain.GetHeader(hash, number)
    if header == nil {
    return nil, consensus.ErrUnknownAncestor
    }
    }

    With the 2nd branch, the headers are in chain so they must be verified and passed the recent check in verify block path already
    With the 1st branch, the only call tree I can see is
Consortium.VerifyHeaders
-> Consortium.verifyHeader
-> Consortium.verifyCascadingFields
-> Consortium.verifySeal
-> Consortium.snapshot

In Consortium.VerifyHeaders

go func() {
for i, header := range headers {
err := c.verifyHeader(chain, header, headers[:i])
select {
case <-abort:
return
case results <- err:
}
}
}()

The 3rd argument of c.verifyHeader is parents argument. As the headers are verified incrementally, the parents must go through full verify flow and pass the recent signer check in VerifySeal.

So is it necessary to apply this check to our consortium?

Support fullCallTracing for call opcode

Rationale

Sometimes we want to capture the error from the tracer. However, the default tracer does not support these errors such as max call depth exceeded and insufficient balance for transfer in internal transactions.

Currently, the default tracer in Ronin does not provide support for capturing certain errors that occur during internal transactions, such as max call depth exceeded and insufficient balance for transfer.

Implementation

I introduce a new parameter, fullCallTracing: bool, to the trace API. This addition ensures compatibility with the existing API while enabling the capture of these errors.

Example

Request

curl --location 'localhost:8545' \
--header 'Content-Type: application/json' \
--data '{
    "jsonrpc": "2.0",
    "method": "debug_traceInternalsAndAccountsByBlockHash",
    "params": [
        "0xe99c5951f0f4306b045d18e4f60575a1321e9dd7401702fb62c865e7d530e934",
        {
            "tracer": "callTracer2",
            "fullCallTracing": true
        }
    ],
    "id": "1"
}'

Old Response

{
    "jsonrpc": "2.0",
    "id": "1",
    "result": {
        "internalTxs": [
            {
                "transactionHash": "0xe9c840187b9271f5c2a104c4fbb48b975b3cf79c53396c696be5e5c524341b0c",
                "result": {
                    "type": "CALL",
                    "order": 0,
                    "from": "0x968d0cd7343f711216817e617d3f92a23dc91c07",
                    "to": "0x30800297f77fe3615e3b44ac00f8f0c5a5625281",
                    "value": "0x0",
                    "gas": "0x1f7a8",
                    "gasUsed": "0x4285",
                    "input": "0x8a4068dd",
                    "output": "0x",
                    "calls": [
                        {
                            "type": "CALL",
                            "order": 107,
                            "from": "0x30800297f77fe3615e3b44ac00f8f0c5a5625281",
                            "to": "0x2e76240d47cf6a5f319db4e681a5a0a4243297c1",
                            "value": "0xde0b6b3a7640000",
                            "gas": "0x1cf03",
                            "gasUsed": "0x20d5",
                            "input": "0x",
                            "output": "0x",
                            "error": "execution reverted"
                        }
                    ]
                }
            }
        ],
        "dirtyAccounts": []
    }
}

New Response

{
    "jsonrpc": "2.0",
    "id": "1",
    "result": {
        "internalTxs": [
            {
                "transactionHash": "0xe9c840187b9271f5c2a104c4fbb48b975b3cf79c53396c696be5e5c524341b0c",
                "result": {
                    "type": "CALL",
                    "order": 0,
                    "from": "0x2e76240d47cf6a5f319db4e681a5a0a4243297c1",
                    "to": "0xeaceb97203f458211e2e8f1254308ae09a4cc2ff",
                    "value": "0x1bc16d674ec80000",
                    "gas": "0x8fc",
                    "gasUsed": "0x4285",
                    "input": "0x",
                    "output": "0x",
                    "error": "insufficient balance for transfer",
                    "calls": [
                        {
                            "type": "CALL",
                            "order": 107,
                            "from": "0x30800297f77fe3615e3b44ac00f8f0c5a5625281",
                            "to": "0x2e76240d47cf6a5f319db4e681a5a0a4243297c1",
                            "value": "0xde0b6b3a7640000",
                            "gas": "0x1cf03",
                            "gasUsed": "0x20d5",
                            "input": "0x",
                            "output": "0x",
                            "error": "execution reverted"
                        }
                    ]
                }
            }
        ],
        "dirtyAccounts": []
    }
}

Ronin Delegate, stake and rewards APIs.

Hi All,

Can anyone provide me with the API to get the transactions based on transaction hash, where we are able to get the Transaction type also that if it is normal transfer, delegate, stake or rewards?

Thanks,
Saloni.

Node synchronization is stuck at height 25028853.

A few of our self-hosted RPC nodes (v2.5.4) are stuck at block height 25028853. There are error logs related to BAD BLOCKS shown as below in the node logs. We also found that some clients on the stats site are stuck at this height, but their node version is 2.5.2.

Error logs:

image

Transaction updating validator contract happens near checkpoint block

In case a transaction that changes the validator list in contract happens near the checkpoint block (e.g. checkpoint block - 1), the safe block range does not pass, other nodes may have different validator list in statedb. The checkpoint block produced and broadcasted can fail the header verification here

switch err := f.verifyHeader(block.Header()); err {
case nil:
// All ok, quickly propagate to our peers
blockBroadcastOutTimer.UpdateSince(block.ReceivedAt)
go f.broadcastBlock(block, true)
case consensus.ErrFutureBlock:
// Weird future block, don't fail, but neither propagate
default:
// Something went very wrong, drop the peer
log.Debug("Propagated block verification failed", "peer", peer, "number", block.Number(), "hash", hash, "err", err)
f.dropPeer(peer)
return
}

I don’t know the impact yet, may this fall into an edge case in block sync between peers or after some reorgs, everything will operate normally?

Request JSON RPC method to allow another account paying gas fees

Description

Since the free gas service's operation needs to connect directly to the validator node, this approach is insecure and can be exploited when some malicious actors take control of the proxy node. A new method to support one account to pay gas fees for the other when performing transactions is needed.

eth_sendRawTransactionFor

Takes the signatures of the transaction sender and the gas payer to create a new message call transaction or a contract creation for signed transactions.

Params

  1. data: DATA, the signed transaction data taken from the transaction sender.
  2. gasPaymentConfirmation: DATA, the signature of the gas payer from signing on the above data.
{
  "jsonrpc": "2.0",
  "method": "eth_sendRawTransactionFor",
  "params": [
    data,
    gasPaymentConfirmation
  ],
  "id": 1
}

Returns

DATA, 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available.

{
  "id":1,
  "jsonrpc": "2.0",
  "result": txHash
}

Implementation Note

  • The nonce of the gas payer should be considered when transaction executing.
  • The transaction pool should be adjusted to fit the new methods: nonce checking from the sender and the gas payer, updating the tx pool & queue,...

Gas check when verifying header

In clique, there are some gas checks in headers which is introduced in this PR: ethereum/go-ethereum#22836

The explanation from author in PR

This is not strictly needed. The state transition ensures that these values are correct, however, that is technically not correct.
State transition should not (need to) verify header fields, it should simply assume that headers are correct. In fast, snap and light sync >mode, headerchains are verified without state transition. So we can't have header-checks that are done in state transition only.

This part was later modified to support EIP-1559 in this PR: https://github.com/ethereum/go-ethereum/pull/22837/files#diff-1f9c721fa9815697c0778c180de0f86da1f7c16297d786412e015700a3575362

Do we need to apply this check?

High Latency when doing batch calls

I am currently using ethereum-etl tool to do some backfilling but I have observed some high latency when doing so. Mainly all the requests are batch requests.
There is no visible bottleneck on the Disk, CPU or RAM but still the response time from the node is significantly high
image

Here is my startup command

       - ronin
        - --config=/root/geth-config/config.toml
        - --rpc.evmtimeout=5s
        - --cache=9830
        - --networkid=2020
        - --port=30303
        - --syncmode=full
        - --maxpeers=100
        - --txlookuplimit=2350000
        - --txpool.pricebump=10
        - --txpool.pricelimit=20000000000
        - --txpool.nolocals
        - --http
        - --http.addr=0.0.0.0
        - --http.port=8545
        - --http.vhosts=*
        - --http.corsdomain=null
        - --http.api=net,eth,web3
        - --ws
        - --ws.addr=0.0.0.0
        - --ws.port=8546
        - --ws.api=net,eth,web3
        - --ws.origins=*
        - --rpc.txfeecap=100
        - --rpc.gascap=500000000
        - --metrics
        - --metrics.addr=0.0.0.0
        - --metrics.port=6060
        - --bootnodes=..
        image: ghcr.io/axieinfinity/ronin:v2.7.1-c64ddd3

config.toml

[Eth]
TrieTimeout = 3600000000000

[Node.HTTPTimeouts]
ReadTimeout = 30000000000
WriteTimeout = 30000000000
IdleTimeout = 120000000000

Can you please suggest what is causing this and what can I improve

Internal Transactions from node

Hi all,

Anyone can provide me with the Curl query or the method name to get the internal transaction based upon transaction hash or Block Number?

Thanks,
Saloni

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.