A Binance Smart Chain client based on the go-ethereum fork

Overview

Binance Smart Chain

The goal of Binance Smart Chain is to bring programmability and interoperability to Binance Chain. In order to embrace the existing popular community and advanced technology, it will bring huge benefits by staying compatible with all the existing smart contracts on Ethereum and Ethereum tooling. And to achieve that, the easiest solution is to develop based on go-ethereum fork, as we respect the great work of Ethereum very much.

Binance Smart Chain starts its development based on go-ethereum fork. So you may see many toolings, binaries and also docs are based on Ethereum ones, such as the name “geth”.

API Reference Discord

But from that baseline of EVM compatible, Binance Smart Chain introduces a system of 21 validators with Proof of Staked Authority (PoSA) consensus that can support short block time and lower fees. The most bonded validator candidates of staking will become validators and produce blocks. The double-sign detection and other slashing logic guarantee security, stability, and chain finality.

Cross-chain transfer and other communication are possible due to native support of interoperability. Relayers and on-chain contracts are developed to support that. Binance DEX remains a liquid venue of the exchange of assets on both chains. This dual-chain architecture will be ideal for users to take advantage of the fast trading on one side and build their decentralized apps on the other side. The Binance Smart Chain will be:

  • A self-sovereign blockchain: Provides security and safety with elected validators.
  • EVM-compatible: Supports all the existing Ethereum tooling along with faster finality and cheaper transaction fees.
  • Interoperable: Comes with efficient native dual chain communication; Optimized for scaling high-performance dApps that require fast and smooth user experience.
  • Distributed with on-chain governance: Proof of Staked Authority brings in decentralization and community participants. As the native token, BNB will serve as both the gas of smart contract execution and tokens for staking.

More details in White Paper.

Key features

Proof of Staked Authority

Although Proof-of-Work (PoW) has been approved as a practical mechanism to implement a decentralized network, it is not friendly to the environment and also requires a large size of participants to maintain the security.

Proof-of-Authority(PoA) provides some defense to 51% attack, with improved efficiency and tolerance to certain levels of Byzantine players (malicious or hacked). Meanwhile, the PoA protocol is most criticized for being not as decentralized as PoW, as the validators, i.e. the nodes that take turns to produce blocks, have all the authorities and are prone to corruption and security attacks.

Other blockchains, such as EOS and Cosmos both, introduce different types of Deputy Proof of Stake (DPoS) to allow the token holders to vote and elect the validator set. It increases the decentralization and favors community governance.

To combine DPoS and PoA for consensus, Binance Smart Chain implement a novel consensus engine called Parlia that:

  1. Blocks are produced by a limited set of validators.
  2. Validators take turns to produce blocks in a PoA manner, similar to Ethereum's Clique consensus engine.
  3. Validator set are elected in and out based on a staking based governance on Binance Chain.
  4. The validator set change is relayed via a cross-chain communication mechanism.
  5. Parlia consensus engine will interact with a set of system contracts to achieve liveness slash, revenue distributing and validator set renewing func.

Light Client of Binance Chain

To achieve the cross-chain communication from Binance Chain to Binance Smart Chain, need introduce a on-chain light client verification algorithm. It contains two parts:

  1. Stateless Precompiled contracts to do tendermint header verification and Merkle Proof verification.
  2. Stateful solidity contracts to store validator set and trusted appHash.

Native Token

BNB will run on Binance Smart Chain in the same way as ETH runs on Ethereum so that it remains as native token for BSC. This means, BNB will be used to:

  1. pay gas to deploy or invoke Smart Contract on BSC
  2. perform cross-chain operations, such as transfer token assets across Binance Smart Chain and Binance Chain.

Building the source

Many of the below are the same as or similar to go-ethereum.

For prerequisites and detailed build instructions please read the Installation Instructions.

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

make geth

or, to build the full suite of utilities:

make all

Executables

The bsc project comes with several wrappers/executables found in the cmd directory.

Command Description
geth Main Binance Smart Chain client binary. It is the entry point into the BSC 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 has the same and more RPC and other interface as go-ethereum and can be used by other processes as a gateway into the BSC network via JSON RPC endpoints exposed on top of HTTP, WebSocket and/or IPC transports. geth --help and the CLI page for command line options.
clef Stand-alone signing tool, which can be used as a backend signer for geth.
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).

Running geth

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.

Hardware Requirements

The hardware must meet certain requirements to run a full node.

  • VPS running recent versions of Mac OS X or Linux.
  • 1T of SSD storage for mainnet, 500G of SSD storage for testnet.
  • 8 cores of CPU and 32 gigabytes of memory (RAM) for mainnet.
  • 4 cores of CPU and 8 gigabytes of memory (RAM) for testnet.
  • A broadband Internet connection with upload/download speeds of at least 10 megabyte per second
$ geth console

This command will:

  • Start geth in fast 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 Binance Smart Chain network, which is very CPU intensive.
  • Start up geth's built-in interactive JavaScript console, (via the trailing console subcommand) through which you can interact using web3 methods (note: the web3 version bundled within geth is very old, and not up to date with official docs), as well as geth's own management APIs. This tool is optional and if you leave it out you can always attach to an already running geth instance with geth attach.

A Full node on the Rialto test network

Steps:

  1. Download the binary, config and genesis files from release, or compile the binary by make geth.
  2. Init genesis state: ./geth --datadir node init genesis.json.
  3. Start your fullnode: ./geth --config ./config.toml --datadir ./node.
  4. Or start a validator node: ./geth --config ./config.toml --datadir ./node -unlock ${validatorAddr} --mine --allow-insecure-unlock. The ${validatorAddr} is the wallet account address of your running validator node.

Note: The default p2p port is 30311 and the RPC port is 8575 which is different from Ethereum.

More details about running a node and becoming a validator.

Note: Although there are some internal protective measures to prevent transactions from crossing over between the main network and test network, you should make sure to always use separate accounts for play-money and real-money. Unless you manually move accounts, geth will by default correctly separate the two networks and will not make any accounts available between them.

Configuration

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

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

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

$ geth --your-favourite-flags dumpconfig

Programmatically interfacing geth nodes

As a developer, sooner rather than later you'll want to start interacting with geth and the Binance Smart Chain network via your own programs and not manually through the console. To aid this, geth has built-in support for a JSON-RPC based APIs (standard APIs and geth 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 geth, 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 BSC 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!

Contribution

Thank you for considering to help out with the source code! We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes!

If you'd like to contribute to bsc, please fork, fix, commit and send a pull request for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check up with the core devs first on our discord channel to ensure those changes are in line with the general philosophy of the project and/or get some early feedback which can make both your efforts much lighter as well as our review and merge procedures quick and simple.

Please make sure your contributions adhere to our coding guidelines:

  • Code must adhere to the official Go formatting guidelines (i.e. uses gofmt).
  • Code must be documented adhering to the official Go commentary guidelines.
  • Pull requests need to be based on and opened against the master branch.
  • Commit messages should be prefixed with the package(s) they modify.
    • E.g. "eth, rpc: make trace configs optional"

Please see the Developers' Guide for more details on configuring your environment, managing project dependencies, and testing procedures.

License

The bsc 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 bsc 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.

Issues
  • BSC synchronization issues

    BSC synchronization issues

    Description

    In the 24 hours of July 28, Binance Smart Chain (BSC) processed 12.9 million transactions. This number and the below numbers are all from the great BSC network explorer bscscan.com powered by the Etherscan team.

    This means 150 transactions per second (TPS) processed on the mainnet, not in isolated environment tests or white paper. If we zoom in, we will also notice that these were not light transactions as BNB or BEP20 transfers, but heavy transactions, as many users were "fighting" each other in the “Play and Earn”, which is majorly contributed by GameFi dApps from MVBII.

    The total gas used on July 28 was 2,052,084 million. If all these were for a simple BEP20 transaction that typically cost 50k gas, it could cover 41 millions transactions, and stand for 470 TPS.

    On the other hand, with the flood of volume, the network experienced congestion on July 28 for about 4 hours, and many low spec or old version nodes could not catch up with processing blocks in time.

    Updates

    A new version of beta client is released which has better performance in order to handle the high volume. Please feel free to upgrade and raise bug reports if you encounter any. Please note this is just a beta version, some known bug fix is on the way. Click here to download the beta client.

    To improve the performance of nodes and achieve faster block times, we recommend the following specifications.

    • validator:
      • 2T GB of free disk space, solid-state drive(SSD), gp3, 8k IOPS, 250MB/S throughput, read latency <1ms.
      • 12 cores of CPU and 48 gigabytes of memory (RAM)
      • m5zn.3xlarge instance type on AWS, or c2-standard-8 on Google cloud.
      • A broadband Internet connection with upload/download speeds of 10 megabyte per second
    • fullnode:
      • 1T GB of free disk space, solid-state drive(SSD), gp3, 3k IOPS, 125MB/S throughput, read latency <1ms. (if start with snap/fast sync, it will need NVMe SSD)
      • 8 cores of CPU and 32 gigabytes of memory (RAM).
      • c5.4xlarge instance type on AWS, c2-standard-8 on Google cloud.
      • A broadband Internet connection with upload/download speeds of 5 megabyte per second

    If you don’t need an archive node, choose the latest snapshot and rerun from scratch from there.

    Problems

    • Fast/snap sync mode cannot catch up with the current state data.
    • Full sync cannot catch up with the current block.
    • High CPU usage.

    Suggestions

    • Use the latest released binary version.
    • Don't use fast/snap sync for now, use the snapshot we provide to run full sync.
    • Confirm your hardware is sufficient, you can refer to our official documents (we will update if there are new discoveries).
    • Regularly prune data to reduce disk pressure.
    • Make sure the peer you connect to is not too slow.

    Reference PRs

    • #257
    • #333

    We will update this board, If there are any updates. If you have a suggestion or want to propose some improvements, please visit our Github. If you encounter any synchronization issues, please report them here.

    enhancement 
    opened by j75689 250
  • All BSC nodes are OFF SYNC

    All BSC nodes are OFF SYNC

    Well, I have tried to sync my own node and failed. It is syncing a week already. OK, so I decided to buy access to a node in the internet.

    I have tried ankr, getblock and quiknode so far, and they ALL are OFF SYNC!!!

    Please don't tell me anything about my hardware is weak or I did something wrong. Just figure out what is going on, and fix it. A month ago everything was alright.

    opened by ghost 160
  • Concern: Validators may be selling special treatment and bypassing Bruno burn

    Concern: Validators may be selling special treatment and bypassing Bruno burn

    Take a look at this transaction: 0xc5fff8dfd621b964fabcd9e240d3a6d72927edb5f5195d9d41d6eb0a1859c92a

    Things to note:

    1. Gas price is 0
    2. It is the sell transaction of a front-run operation, so it was prioritized even though gas price is 0.
    3. Block was validated by MathWallet
    4. There is a BNB transfer going to MathWallet validator (Possibly as payment for the special treatment).

    There are many more of these transactions going on to the same contract address with the same behavior. At least 3 validators seem to be involved (MathWallet, TwStaking and NodeReal). The transactions are also not publicly visible from the transaction pool (Possibly they are submitted directly to the validators). Clearly, there is an agreement between the originator of the transactions and the validators and the goal is to perform front-running without risk.

    MathWallet denied this, but we can all see what's going on.

    Needless to say, because the gas price is 0, there is no burn (Introduced in Bruno upgrade). It's possible that this is another thing these validators are starting to explore to bypass the burn feature and maximize their profits.

    Is this behavior allowed from validators? I don't believe that it's healthy for the network if validators do such things for profit. Validators are held to high standards and are supposed to be trustworthy.

    For completion, here is also the buy transaction associated with the above sell transaction: 0x762e097ab15fbefeee0e91c6a444e492ec7e9e00c84cad2a4c4765e1f85efe47

    opened by NullQubit 80
  • Fast Sync State Entries Statistics

    Fast Sync State Entries Statistics

    Hi there,

    Creating this issue thread to provide information similar to https://github.com/ethereum/go-ethereum/issues/15616

    This is technically not an issue but just a thread in case people wonder why their fast sync takes 'forever'. Once you see Deallocated fast sync bloom items in your log, it means fast sync has stopped and full sync has started and the node has reached its peak sync state at that time.

    Fast Sync state entry as of 3 March 2021 ~ 163237136

    INFO [03-03|10:28:21.538] Committed new head block number=5355700 hash=0148bf…0ec9bd
    INFO [03-03|10:28:21.569] Imported new block headers count=1 elapsed=443.41µs number=5355815 hash=e3b9bb…dcd325
    INFO [03-03|10:28:21.572] Deallocated fast sync bloom items=163237136 errorrate=0.001
    

    Fast Sync Disk Usage - 3 March 2021

    /dev/sdc 491.2G 34.6G 456.5G 7% /root
    /dev/sdd 491.2G 26.5G 464.6G 5% /ancient
    

    Full Sync Disk Usage - 4 March 2021

    /dev/sdd 491.2G 189.7G 301.5G 39% /root
    /dev/sdc 491.2G 27.8G 463.3G 6% /ancient
    
    good first issue 
    opened by kutysam 80
  • Geth 1.10 txpool ordering

    Geth 1.10 txpool ordering

    Rationale

    With the latest update of geth 1.10, transactions with the same gas price are ordered by receive time, rather than by random order.

    This receive time ordering may not be suitable to binance smart chain. Since BSC's validation mechanism is 21 validators taking turn deterministically to wrap transactions, deterministic transaction ordering can lead to below problems :

    1. validators can GUARANTEED frontrun/ backrun pending pool transactions, as validators do not need to compete for POW. For example, a validator can guaranteed front running IDO starts at a pre-determined block number.
    2. since latency becomes critical after the update, nodes have less incentives to include light nodes and nodes located remotely (like in New Zealand) as peers. Nodes are concentrated located and connected. This causes the nodes become more and more centralized and defeats the purpose of decentralization.

    Also, I think this change is vital and wonder is that any reason not stating it in the change list?

    Implementation

    The origin of this change in ethereum mainnet is to avoid spam back running transactions occupying block spaces. To achieve the same goal in bsc, could we propose the below change instead?

    1. sort the transaction order by receive time, with a noise added so that order is sorted by T + N(0,sigma)
    2. revert the change if the spam issue not serious. Seems to me that the 60m gas limit is not fully utilized recently.

    Welcome any thoughts!

    opened by patllc 64
  • My node always showing 100 blocks behind

    My node always showing 100 blocks behind

    > eth.syncing

    {
      currentBlock: 7738573,
      highestBlock: 7738689,
      knownStates: 370745564,
      pulledStates: 370690961,
      startingBlock: 7716912
    }
    

    Is there any way to boostup the syncing?

    opened by urkishan 54
  • BSC node can't sync the new block

    BSC node can't sync the new block

    eth.syncing { currentBlock: 6784288, highestBlock: 6784407, knownStates: 133873248, pulledStates: 133865063, startingBlock: 6783739 } eth.blockNumber 0

    opened by 1b1og-com 49
  • Release 1.1.0 stable cannot full sync on fast mode

    Release 1.1.0 stable cannot full sync on fast mode

    System information

    Geth version:
    geth version Geth Version: 1.1.0 Git Commit: 7822e9e2a1c11e5e9f989b740ba0166a9cd96db1 Architecture: amd64 Go Version: go1.16.3 Operating System: linux GOPATH= GOROOT=go

    OS & Version: Linux Ubuntu 20.04 Commit hash : (if develop)

    Expected behaviour

    To be fully synced and to not be behind with 100 blocks

    Actual behaviour

    Pivot Stale, receipts behind with ~100 blocks and the issue was also in 1.1.0-beta and actually the issue started to happen about 1 week and half ago after I saw that my node gets behind I did restart it and started this behaviour. Deleted and resynced same issue. I tried 2-3 different server providers all with NVME and a lot of RAM and different location same issue: eth.blockNumber on 0 and pivot getting stalled so I get the issue with 3 minutes back blocks (~100blocks).

    Steps to reproduce the behaviour

    Start a full sync ( personally I've used servers from EU countries) by using fast as syncmode

    Backtrace

    [backtrace]
    

    When submitting logs: please submit them as text and not screenshots.

    opened by dracmic 40
  • Syncing 3 days behind every time

    Syncing 3 days behind every time

    System information

    AWS Instance

    Instance type : c5.4xlarge
    Ram Size : 32 GB
    CPU : 16
    

    Disk Configurations :

    Disk type : GP3
    Disk Size : 4000 GiB
    IOPS : 16000
    Throughput : 500 MB/s
    

    Geth version:

    Geth
    Version: 1.1.2
    Git Commit: c4f931212903b3ee8495c36ac374340aec4ac269
    Git Commit Date: 20210825
    Architecture: amd64
    Go Version: go1.15.14
    Operating System: linux
    GOPATH=/home/ubuntu/go
    GOROOT=/usr/local/go
    

    The blockchain was synced before but when I restarted It is now 3 days behind. I don't know what is wrong with the BSC network. My entire system is suffering because of this. Kindly anyone help me to resolve this.

    I've done everything as you can see the configurations. It seems I am installing a project of NASA.

    Here is the out for eth.syncing

    instance: Geth/v1.1.2-c4f93121-20210825/linux-amd64/go1.15.14
    coinbase: 0xff82b410814736762246d9382aeccc13cacb85ce
    at block: 11428396 (Sat Oct 02 2021 18:04:03 GMT+0000 (UTC))
     datadir: /home/ubuntu/node
    
    
    > eth.syncing
    {
      currentBlock: 11428399,
      highestBlock: 11475954,
      knownStates: 297473485,
      pulledStates: 297473485,
      startingBlock: 11392128
    }
    > 
    
    question 
    opened by urkishan 38
  • I am tired of this

    I am tired of this

    A month ago I've pruned my node because my server was low on storage. At that time, I was using Hetzner AX51-NVME with Ryzen 7 3700X, 64GB RAM and 1TB NVMe which worked just fine, until I stopped it. Since then it never synced again. So I followed some "smart" recommendations to use snapshot. As the server had only 1TB of storage, I needed to upgrade to AX61-NVME which has Ryzen 9 3900, 128GB RAM and 1.92 TB NVMe. I've followed the snapshot instructions, downloaded it, replaced the data, started the node, and guess what. Here I am 3 days later stuck in the same fckin state, where the node imports billions of states without ever stopping. To be honest, I am sick of this. And please, don't tell me I need better hardware. That's complete bullshit. I could've run half of my country's internet from that server. Does anyone know the exact procedure to get a new node 100% synced? If not, devs should really think about it, as this is the start of the end of this network.

    question 
    opened by adamiss5138 34
  • How to make rpc from http to https

    How to make rpc from http to https

    Hi i just build a fullnode

    and until now it's running well

    it's can running on metamask (Chrome extensions)

    but if i use mobile phone metamask it's require "https"

    so the problem is how to make my rpc from http to https

    i got sutck for at least one day :(

    and i am using "nginx"

    this is my nginx.conf


    server {

    listen 666;

    server_name localhost; location ^~ /w {

      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_set_header X-NginX-Proxy true;
      proxy_pass   http://127.0.0.1:9999/;
    

    }

    location ^~ /h {

      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_set_header X-NginX-Proxy true;
      proxy_pass    http://127.0.0.1:6666/;
    

    access_log /etc/nginx/log/Maiko.access.log maiko; } }

    image

    question 
    opened by kugimiya530 28
  • [R4R] improve snap mutex

    [R4R] improve snap mutex

    Description

    This pr tries to improve block importing by splitting mutex for snap account and storage.

    Rationale

    The access to snap accounts and snap storage could use different locks to avoid unnecessary race.

    Result

    • Before
    Dropped 546 nodes (cum <= 0.02mins)
    Showing top 40 nodes out of 106
          flat  flat%   sum%        cum   cum%
      3.59mins 90.44% 90.44%   3.59mins 90.44%  sync.(*Mutex).Unlock (partial-inline)
      0.37mins  9.26% 99.71%   2.17mins 54.68%  sync.(*RWMutex).Unlock
             0     0% 99.71%   0.03mins  0.74%  github.com/VictoriaMetrics/fastcache.(*Cache).Set
             0     0% 99.71%   0.03mins  0.74%  github.com/VictoriaMetrics/fastcache.(*bucket).Set
             0     0% 99.71%   0.51mins 12.93%  github.com/ethereum/go-ethereum/core.(*BlockChain).InsertChain
             0     0% 99.71%   0.02mins  0.58%  github.com/ethereum/go-ethereum/core.(*BlockChain).insertChain
             0     0% 99.71%   0.08mins  2.02%  github.com/ethereum/go-ethereum/core.(*StateTransition).TransitionDb
             0     0% 99.71%   0.04mins     1%  github.com/ethereum/go-ethereum/core.(*TxPool).AddRemotes
             0     0% 99.71%   0.04mins     1%  github.com/ethereum/go-ethereum/core.(*TxPool).addTxs
             0     0% 99.71%   0.34mins  8.47%  github.com/ethereum/go-ethereum/core.(*TxPool).runReorg
             0     0% 99.71%   0.05mins  1.14%  github.com/ethereum/go-ethereum/core.(*statePrefetcher).Prefetch.func1
             0     0% 99.71%   0.08mins  1.97%  github.com/ethereum/go-ethereum/core.ApplyMessage
             0     0% 99.71%   0.06mins  1.48%  github.com/ethereum/go-ethereum/core.precacheTransaction
             0     0% 99.71%   0.11mins  2.70%  github.com/ethereum/go-ethereum/core/rawdb.ReadStorageSnapshot
             0     0% 99.71%   0.11mins  2.72%  github.com/ethereum/go-ethereum/core/state.(*StateDB).AccountsIntermediateRoot.func1
             0     0% 99.71%   0.11mins  2.72%  github.com/ethereum/go-ethereum/core/state.(*StateDB).AccountsIntermediateRoot.func2
    
    • After
    Dropped 571 nodes (cum <= 0.02mins)
    Showing top 40 nodes out of 111
          flat  flat%   sum%        cum   cum%
      4.54mins 91.33% 91.33%   4.54mins 91.33%  sync.(*Mutex).Unlock (partial-inline)
      0.42mins  8.38% 99.70%   2.28mins 45.96%  sync.(*RWMutex).Unlock
             0     0% 99.70%   0.04mins  0.76%  github.com/VictoriaMetrics/fastcache.(*Cache).Set
             0     0% 99.70%   0.04mins  0.76%  github.com/VictoriaMetrics/fastcache.(*bucket).Set
             0     0% 99.70%   0.45mins  9.08%  github.com/ethereum/go-ethereum/core.(*BlockChain).InsertChain
             0     0% 99.70%   0.03mins  0.55%  github.com/ethereum/go-ethereum/core.(*BlockChain).insertChain
             0     0% 99.70%   0.08mins  1.57%  github.com/ethereum/go-ethereum/core.(*StateTransition).TransitionDb
             0     0% 99.70%   0.04mins  0.81%  github.com/ethereum/go-ethereum/core.(*TxPool).AddRemotes
             0     0% 99.70%   0.04mins  0.81%  github.com/ethereum/go-ethereum/core.(*TxPool).addTxs
             0     0% 99.70%   0.40mins  8.12%  github.com/ethereum/go-ethereum/core.(*TxPool).runReorg
             0     0% 99.70%   0.04mins  0.85%  github.com/ethereum/go-ethereum/core.(*statePrefetcher).Prefetch.func1
             0     0% 99.70%   0.08mins  1.54%  github.com/ethereum/go-ethereum/core.ApplyMessage
             0     0% 99.70%   0.06mins  1.12%  github.com/ethereum/go-ethereum/core.precacheTransaction
             0     0% 99.70%   0.11mins  2.20%  github.com/ethereum/go-ethereum/core/rawdb.ReadStorageSnapshot
             0     0% 99.70%   0.06mins  1.16%  github.com/ethereum/go-ethereum/core/state.(*StateDB).AccountsIntermediateRoot.func1
             0     0% 99.70%   0.06mins  1.17%  github.com/ethereum/go-ethereum/core/state.(*StateDB).AccountsIntermediateRoot.func2
    

    We can see that AccountsIntermediateRoot's block has been reduced.

    Changes

    Notable changes:

    • use different locks for snap account and snap storage
    opened by forcodedancing 0
  • Latest version 1.1.10 cannot stop gracefully

    Latest version 1.1.10 cannot stop gracefully

    System information

    Geth version: 1.1.10 OS & Version: Linux Commit hash : 2f2b98abb26a3833d76daf1a9a1a660e517b1459

    Expected behaviour

    Version 1.1.8 can be stopped normally via systemd.

    Actual behaviour

    Version 1.1.10 cannot be stopped normally via systemd.

    image
    opened by barryz 0
  • Can't sync using a light client

    Can't sync using a light client

    Bnb version used: 1.1.7

    Getting following logs while trying to sync:

    DEBUG[05-11|10:06:50.006] Revalidated node                         b=7  id=44b3b48964e182e6 checks=1
    DEBUG[05-11|10:06:50.087] Adding p2p peer                          peercount=1 id=4ddc757c3e6af551 conn=staticdial addr=18.212.135.123:30311  name=Geth/v1.1.9-14512836...
    DEBUG[05-11|10:06:50.087] Light Ethereum peer connected            id=4ddc757c3e6af551 conn=staticdial name=Geth/v1.1.9-14512836...
    DEBUG[05-11|10:06:50.187] Adding p2p peer                          peercount=2 id=2ebb8e6afa589b36 conn=staticdial addr=34.243.12.13:30311    name=Geth/v1.1.9-14512836...
    DEBUG[05-11|10:06:50.188] Light Ethereum peer connected            id=2ebb8e6afa589b36 conn=staticdial name=Geth/v1.1.9-14512836...
    DEBUG[05-11|10:06:50.197] Light Ethereum handshake failed          id=4ddc757c3e6af551 conn=staticdial err="ForkID rejected - local incompatible or needs update"
    DEBUG[05-11|10:06:50.197] Removing p2p peer                        peercount=1 id=4ddc757c3e6af551 duration=110.321ms req=false err="ForkID rejected - local incompatible or needs update"
    DEBUG[05-11|10:06:50.248] Light Ethereum handshake failed          id=2ebb8e6afa589b36 conn=staticdial err="ForkID rejected - local incompatible or needs update"
    DEBUG[05-11|10:06:50.248] Removing p2p peer                        peercount=0 id=2ebb8e6afa589b36 duration=60.406ms  req=true  err="subprotocol error"
    DEBUG[05-11|10:06:51.321] Bad discv5 packet                        id=0000000000000000 addr=72.182.98.50:30311    err="invalid packet header"
    DEBUG[05-11|10:06:51.904] Bad discv5 packet                        id=0000000000000000 addr=144.126.222.25:30303  err="invalid packet header"
    DEBUG[05-11|10:06:52.327] Bad discv5 packet                        id=0000000000000000 addr=72.182.98.50:30311    err="invalid packet header"
    DEBUG[05-11|10:06:52.327] Bad discv5 packet                        id=0000000000000000 addr=72.182.98.50:30311    err="invalid packet header"
    DEBUG[05-11|10:06:52.914] Bad discv5 packet                        id=0000000000000000 addr=144.126.222.25:30303  err="invalid packet header"
    DEBUG[05-11|10:06:52.914] Bad discv5 packet                        id=0000000000000000 addr=144.126.222.25:30303  err="invalid packet header"
    
    

    Similar to https://github.com/bnb-chain/bsc/issues/546 but it also tries to connect to some bnb nodes on port: 30311

    opened by DylanVerstraete 1
  • Bad discv4 packet

    Bad discv4 packet

    While trying to sync a node in light syncmode on mainnet we are getting these logs:

    DEBUG[05-10|08:10:10.691] Bad discv4 packet                        addr=83.50.21.103:12000    err="too small"
    DEBUG[05-10|08:10:10.755] Bad discv4 packet                        addr=83.50.21.103:12000    err="bad hash"
    DEBUG[05-10|08:10:10.755] Bad discv4 packet                        addr=83.50.21.103:12000    err="bad hash"
    DEBUG[05-10|08:10:10.756] Bad discv4 packet                        addr=83.50.21.103:12000    err="bad hash"
    DEBUG[05-10|08:10:10.756] Bad discv4 packet                        addr=83.50.21.103:12000    err="bad hash"
    DEBUG[05-10|08:10:10.756] Bad discv4 packet                        addr=83.50.21.103:12000    err="bad hash"
    DEBUG[05-10|08:10:10.756] Bad discv4 packet                        addr=83.50.21.103:12000    err="bad hash"
    
    opened by DylanVerstraete 0
  • Any one can please fix Binance Smart Chain Faucet ?

    Any one can please fix Binance Smart Chain Faucet ?

    System information

    Geth version: geth version OS & Version: Windows/Linux/OSX Commit hash : (if develop)

    Expected behaviour

    Binance faucet is not working as it should : https://testnet.binance.org/faucet-smart

    Actual behaviour

    Binance faucet should fund BNB on testnet

    Steps to reproduce the behaviour

    1. go to : https://testnet.binance.org/faucet-smart
    2. enter any bsc chain address
    3. try to fund 1 bnb

    Backtrace

    [backtrace]
    

    When submitting logs: please submit them as text and not screenshots.

    opened by parthindia47 5
Releases(v1.1.10)
  • v1.1.10(May 5, 2022)

    This is a hardfork release that will enable BEP127 and BEP131 on the Chapel testnet. This upgrade is named after Leonhard Euler in honor of his key contributions to mathematics and mechanics. The current block generation speed forecasts this to occur around May 11th at 03:18:00 AM (UTC). The validators and full node operators on testnet should switch their software version to this release by May 11th.

    Upcoming Changes

    BEP-127 Temporary Maintenance Mode for Validators

    Due to the design of Parlia consensus, the absence of the validator, even if it is due to scheduled maintenance, will cause instability and capacity loss of BSC due to the extra waiting time and chain reorganization for other validators. Introducing Temporary Maintenance mode will stabilize the blocking rotation and maintain the capacity of BSC.

    A validator can claim itself to enter temporary maintenance mode by sending a transaction to interact with ValidatorSet smart contract. Temporary maintenance is supposed to last one or a few hours. The validator seat will be temporarily dropped from the block producing rotation during the maintenance. Since long-time offline maintenance is not encouraged, the validator will still be slashed if the maintenance lasts too long. To lower the impact from poorly-operating validators who forget to claim its maintenance, they will be forced to enter temporary maintenance mode too.

    Check BEP-127 for more details.

    BEP-131 Introduce candidate validators onto BNB Smart Chain

    This BEP introduces candidate validators onto BSC testnet to improve the liveness and robustness of the network.

    BSC testnet will introduce more validators, e.g. another 10 inactive validators, into the validator set as backups, which will be called "Candidates". Candidates will produce blocks and charge gas fees on BNB Smart Chain mainnet, but with a much less chance than the active validator set of 11 elected. A decent motivation is expected to be maintained so that the candidate validators are willing to ensure the quality and help secure BNB Smart Chain.

    The number of Candidate Validators is subjected to the BSC testnet governance. The BSC Chapel Testnet will keep the same number of Active Validators and 0 Candidate Validators right after Euler upgrade, and the later governance action will enlarge the Candidate Validator Set to allow new Candidate Validator to be set up.

    Check BEP-131 for more details.

    Changelog

    FEATURE

    • #885 add Euler Hardfork, including BEP-127 and BEP-131

    BUGFIX

    • #856 fix logic issue: handlers.removePeer() is called twice
    • #860 fix:defer bloomprocessor close
    • #877 fix validator pipecommit issue
    • #870 fix:Shift panic for zero length of heads

    Assets

    | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | 6dd6976b9c8d407e95ed99cd46f7badfa410f3f374ea3e360defab0f63fa3ed2 | | testnet.zip | c9c20ceb98911cc3fa7ceda3e5efbf17a3791fdc46f2f6ab13af7ac77f1a65eb | | geth_linux | ba89651ddadc243162b8d8cca263e87cd3663f15217d78784a0e286b7e8fddca | | geth_mac | e900220ec49c6981831a01fe1d962f8a9901f5eb181130e41d121de75a7bf7fc | | geth_windows | e87d284318ec8a4dbd65112499d81627de0608213df04a09afb2c06d740c92d3 | | geth_linux_arm5 | e5df7f86603b81ce58996b80bf35d8faf5b1fc2accb2c443097aace9bfe1cec1 | | geth_linux_arm6 | f24d11cbcdc28c68debbcf2dc243f1c0489752ebf40511feb37086162ee93a03 | | geth_linux_arm7 | f4512009af5d21c562a3b30f23c4c87ffd11e39cfbea20810744e336b43338a5 | | geth_linux_arm64 | a93604dcca3e42d83e0d762f962e8c5e99409e6711073f16ecca2fd4662fd4aa |

    Source code(tar.gz)
    Source code(zip)
    geth-linux-arm-5(44.41 MB)
    geth-linux-arm-6(44.33 MB)
    geth-linux-arm-7(44.27 MB)
    geth-linux-arm64(48.46 MB)
    geth_linux(46.05 MB)
    geth_mac(38.45 MB)
    geth_windows.exe(72.87 MB)
    mainnet.zip(48.00 KB)
    testnet.zip(41.17 KB)
  • v1.1.9(Apr 12, 2022)

    Release v1.1.9 is a maintenance release. It includes several performance improvement and bug fix.

    Changelog

    IMPROVEMENT

    • #792 add shared storage for prefetching state data
    • #795 implement state verification pipeline in pipecommit
    • #803 prefetch state data during the mining process
    • #812 skip verification on account storage root to tolerate with fastnode when doing diffsync
    • #818 add shared storage to the prefetcher of miner
    • #820 disable diffsync when pipecommit is enabled
    • #830 change the number of prefetch threads

    BUGFIX

    • #797 fix race condition on preimage in pipecommit
    • #808 fix code of difflayer not assign when new smart contract created
    • #817 fix bugs of prune block tool
    • #834 fix deadlock when failed to verify state root in pipecommit
    • #835 fix deadlock on miner module when failed to commit trie
    • #842 fix invalid nil check of statedb in diffsync

    Assets

    | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | 6dd6976b9c8d407e95ed99cd46f7badfa410f3f374ea3e360defab0f63fa3ed2 | | testnet.zip | c9c20ceb98911cc3fa7ceda3e5efbf17a3791fdc46f2f6ab13af7ac77f1a65eb | | geth_linux | c69ade6eb11399aa2296933279a2760f947092d77ddc4b4c1a8bda95707db107 | | geth_mac | 5648f57f988752a2e0cd8fc5a6cfccdc905d01e2604788766e59ca66e9316066 | | geth_windows | 6389751c6464ca67239816d6a14740ce78e9b5f6fe5d33ced6fa768027def908 | | geth_linux_arm5 | 7463c0db02b51f0810107a50cf254cda7a466a4d0dc8d7c4486e31966e2f984c | | geth_linux_arm6 | aff8da399c909f5fa94ca2651eecb7dcda844e9b3d6e5c8c23f9ebcb3f530db7 | | geth_linux_arm7 | 0bdf125b52d32b593675bc3dc1b4a41448114138f3c3ed0b94c3fc633c75351a | | geth_linux_arm64 | fa770b25cba39855a638661ed19b8fa2d28a3d880855e5b25d374f36a436b0d9 |

    Source code(tar.gz)
    Source code(zip)
    geth-linux-arm-5(44.19 MB)
    geth-linux-arm-6(44.11 MB)
    geth-linux-arm-7(44.05 MB)
    geth-linux-arm64(48.24 MB)
    geth_linux(45.82 MB)
    geth_mac(38.23 MB)
    geth_windows.exe(72.64 MB)
    mainnet.zip(48.00 KB)
    testnet.zip(41.17 KB)
  • v1.1.8(Jan 28, 2022)

    Description

    Release v1.1.8 is a performance release. Verification && Commit Pipeline, Go Native Tracer and Block Prune are introduced in this release.

    Change log

    FEATURES

    • #668 implement State Verification && Snapshot Commit pipeline
    • #581 implement geth native trace
    • #543 implement offline block prune tools

    IMPROVEMENT

    • #704 prefetch state by applying the transactions within one block
    • #713 add ARM binaries for release pipeline

    BUGFIX

    • #667 trie: reject deletions when verifying range proofs
    • #643 add timeout for stopping p2p server to fix can not gracefully shutdown issue
    • #740 update discord link which won't expire

    Changes

    State Verification && Commit Pipeline

    State verification and storage commit pipeline is introduced in https://github.com/binance-chain/bsc/pull/668. It is an experimental feature that is expected to improve the performance, enable it by appending --pipecommit to the process command.

    Ancient Data Prune

    A new tool is introduced to prune ancient undesired block data, it will discard block, receipt, header in the ancient db to save space. Example: ./geth snapshot prune-block --datadir ./node --datadir.ancient ./chaindata/ancient --block-amount-reserved 1024.

    Note: 1. Stop the client before pruing; 2. datadir.ancient is based on datadir, ./chaindata/ancient means ${datadir}/geth/chaindata/ancient actually

    Go Native Tracer

    The default tracer is now based Golang implementation rather than Js implementation.

    Assets

    | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | 6dd6976b9c8d407e95ed99cd46f7badfa410f3f374ea3e360defab0f63fa3ed2 | | testnet.zip | c9c20ceb98911cc3fa7ceda3e5efbf17a3791fdc46f2f6ab13af7ac77f1a65eb | | geth_linux | 73a30eb9d12b82374bf8d1f39369be27f8bee97095b8ad9ba89b1bb8662e3e2a | | geth_mac | 556ad673d9aa4e5daf32a15a6dcdc34d34a0711a6afb1878dbe51b6c013ce1e5 | | geth_windows | 402bf3587411b445d0b4c6918453caa660af8daf9167693442d441e8343d03b7 | | geth_linux_arm5 | 5158e00c073574caf080c9272b7b6ef11b14ac8baee0f391b4f3b11967a2b0e8 | | geth_linux_arm6 | d2f8ec1c94461f0bc1c78b2ea8d8722ea341b1e5b525361ca1b3b445fdf330c5 | | geth_linux_arm7 | 87aa64d0d54275c4e28eb6c67d8103f6bba7ebcc1121d21da44f14c6f8168372 | | geth_linux_arm64 | c328dba014e0bc4fa8f2ebd90e37dcc4e7512f6b2c0901d6d32798f1800da2c1 |

    Source code(tar.gz)
    Source code(zip)
    geth-linux-arm-5(44.16 MB)
    geth-linux-arm-6(44.08 MB)
    geth-linux-arm-7(44.02 MB)
    geth-linux-arm64(48.20 MB)
    geth_linux(45.78 MB)
    geth_mac(38.20 MB)
    geth_windows.exe(72.58 MB)
    mainnet.zip(48.00 KB)
    testnet.zip(41.17 KB)
  • v1.1.7(Dec 5, 2021)

    This is a hot fix release for a syncing issue during diffsync, check https://github.com/binance-chain/bsc/pull/628 for more details. All clients are suggested to upgrade.

    If you come across with Bad Block error with a log message like: expected tx hash xx, get xx, nonce xx, to xx, value xx, gas xx, gasPrice xx, data xx. Following is the guide to recover the node:

    1. Stop The node.
    2. Upgrade the binary to the latest release.
    3. Start the node with --snapshot=false
    4. Wait for a few minutes(it depends on how fast the node is), until the block height is 128 higher than where it stopped.
    5. Restart the node with --snapshot=true
    6. The node will continue to sync and repair the corrupt data.

    Changelog

    BUGFIX

    • #628 fix state inconsistent when doing diffsync

    Assets

    | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | 4a2ad47362afa6c387ed9acd7f8f050b356e61ac77b8094b6116aa17ae90972b | | testnet.zip | c9c20ceb98911cc3fa7ceda3e5efbf17a3791fdc46f2f6ab13af7ac77f1a65eb | | geth_linux | 3e5a73d46ee944c89c45adc92a1f7347bc83658a64a1595ba7635c05c0600715 | | geth_mac | 9d9e78a1411a43a1c3cfe0fe6320c67d500ab91692164fbde07f32e3f6c12aff | | geth_windows | 9fe9ce7cf540fcb1171c9e75b9ae8ad917907657d1d0b47072e07e172b0a3b3e |

    Source code(tar.gz)
    Source code(zip)
    geth_linux(45.62 MB)
    geth_mac(38.04 MB)
    geth_windows.exe(72.33 MB)
    mainnet.zip(47.22 KB)
    testnet.zip(41.17 KB)
  • v1.1.6(Nov 29, 2021)

    Description

    This is a security release, including a DoS issue fix from go-ethereum, leveldb improvement from go-ethereum, and a feature to improve p2p tx broadcast function.

    Example

    This feature is introduced to handle some extreme situations, it won't affect the original function, and it is disabled by default. Users can enable this feature by setting TxPool.ReannouceTime according to their needs.

    geth --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --txlookuplimit 0 --txpool.reannouncetime 5m
    

    Changelog

    BUGFIX

    • #582 the DoS vulnerabilities fixed in go-ethereum v1.10.9

    IMPROVEMENT

    • #578 reduce memory allocation and upgrade snappy version

    FEATURES

    • #570 reannounce local pending transactions

    Assets

    | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | 541028a68a26dc1d0828b144626e8d064ac9d0b6db1ad499700ec6f62559c336 | | testnet.zip | c9c20ceb98911cc3fa7ceda3e5efbf17a3791fdc46f2f6ab13af7ac77f1a65eb | | geth_linux | 7209ab26df6d70bcc7094353f73d0ad694e2816efae59c04848629ccd5bf9bd7 | | geth_mac | 2f3a698f82186fd86144ae933f4244ade70faaa2436aeb8b3f8156cb445e7d1d | | geth_windows | 00b58653857ae9c7c5cd5e02183ca328b99f6dc9d874b670a02d1a606271a923 |

    Source code(tar.gz)
    Source code(zip)
    geth_linux(45.62 MB)
    geth_mac(38.04 MB)
    geth_windows.exe(72.33 MB)
    mainnet.zip(47.05 KB)
    testnet.zip(41.17 KB)
  • v1.1.5(Nov 16, 2021)

    v1.1.5 is a hard fork release.

    v1.1.5 brings Bruno hard fork which introduces a real-time burning mechanism into the economic model of BSC. Please refer to BEP95 for more details. The Bruno hard fork is expected to happen at block height 13082000. The current block generation speed forecasts this to occur around November 30th at 08:00 AM (UTC). All clients are recommended to upgrade by November 30th.

    We improved the diffsync protocol in this release and rolled it out as a stable feature. Diff sync improves the syncing speed by 60%~70% approximately according to the test. All full nodes are suggested to enable it by adding --diffsync in the starting command. Refer to BEP93 for more details.

    Changelog

    BUGFIX

    • #509 fix graceful shutdown bug

    IMPROVEMENT

    • #536 get diff accounts by replaying block when diff layer not found
    • #527 improve diffsync protocol in many aspects
    • #493 implement fast getDiffAccountsWithScope API

    Assets

    | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | 0e0f1185050428124011edab31df40d94db40e521fedd9279ee77bcb6fde3b14 | | testnet.zip | 0259269be86fbdfce14efe40e99874b95a4a3ed30949463c0cef9e776eb6b1b2 | | geth_linux | 37018164e1af4ceecef528e9efcecbb79f62bb1ec5dd0a40a76e7a44a4ff4fbd | | geth_mac | b72974f906e45ab67febcc7e21813c3ca302dc6cd4810c723daf7e247d337d10 | | geth_windows | 5f948be5ceda3eb3da9cd94cf6652b5913d266cdcf39e07eea8c4ef57516d3ad |

    Source code(tar.gz)
    Source code(zip)
    geth_linux(45.61 MB)
    geth_mac(38.04 MB)
    geth_windows.exe(72.31 MB)
    mainnet.zip(46.25 KB)
    testnet.zip(41.17 KB)
  • v1.1.4(Nov 2, 2021)

    V1.1.4 is a release mainly for testnet. V1.1.4 brings a hard fork Bruno that introduces a real-time burning mechanism into the economic model of BSC. For detail, you can refer to bep 95.

    The fork height of Bruno in testnet is 13837000, around 2021 11-05 02:00 UTC.

    The fork height of Bruno in mainnet will come along with the next release.

    It also contains some improvements and bug fixes.

    Changelog

    IMPROVEMENT

    • #472 add metrics for contract code bitmap cache
    • #473 fix ci test flow

    BUGFIX

    • #491 fix prefetcher related bugs

    FEATURES

    • #480 implement bep 95

    Assets

    | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | 541028a68a26dc1d0828b144626e8d064ac9d0b6db1ad499700ec6f62559c336 | | testnet.zip | 0259269be86fbdfce14efe40e99874b95a4a3ed30949463c0cef9e776eb6b1b2 | | geth_linux | b3966d354333bde25c3cb8d6b4f553669f55859047fb11556ba3c32b58214de1 | | geth_mac | 4c421841507810d2a93813c0873d0ee0fc7c9871a50481dc87e0248a003e87df | | geth_windows | 201c0655bf6c8a7da379358eded3b68bcfe90db6f2b55b48849fc92113ae9d4a |

    Source code(tar.gz)
    Source code(zip)
    geth_linux(45.59 MB)
    geth_mac(38.02 MB)
    geth_windows.exe(72.28 MB)
    mainnet.zip(47.05 KB)
    testnet.zip(41.17 KB)
  • v1.1.3(Oct 20, 2021)

    Release v1.1.3 is a performance improvement release. It introduces diff sync protocol to help nodes sync faster, try to enable it by adding --diffsync flag to the node. The performance of diff sync depends on how many nodes have enabled it within the network, so it may take weeks to actually take effect.

    Changelog

    FEATURES

    • #431 Export get diff accounts in block api
    • #412 add extension in eth protocol handshake to disable tx broadcast
    • #376 implement diff sync

    Improvement

    • #456 git-flow support lint, unit test, and integration testnet.zip
    • #449 cache bitmap and change the cache type of GetCode
    • #454 fix cache key do not have hash func
    • #446 parallel bloom calculation
    • #442 ignore empty tx in GetDiffAccountsWithScope
    • #426 add block proccess backoff time when validator is not in turn and received in turn block
    • #398 ci pipeline for release page

    BUGFIX

    • #446 fix concurrent write of subfetcher
    • #444 fix blockhash not correct for the logs of system tx receipt
    • #409 fix nil point in downloader
    • #408 core/state/snapshot: fix typo

    Assets

    | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | 541028a68a26dc1d0828b144626e8d064ac9d0b6db1ad499700ec6f62559c336 | | testnet.zip | 0259269be86fbdfce14efe40e99874b95a4a3ed30949463c0cef9e776eb6b1b2 | | geth_linux | 646152e9ed610e72c831ad4589729a2142d5e8a9a539e9cfa5dff1d6cca83da2 | | geth_mac | 308e900880c9d7f6f7cb3ca172b85312fdf5713554ea75304822732bbedba1bd | | geth_windows | 1d55ad103d9bb054d12d566cefcada51eacb58cd0013399d428161a1ed904fd3 |

    Source code(tar.gz)
    Source code(zip)
    geth_linux(45.47 MB)
    geth_mac(37.99 MB)
    geth_windows.exe(72.16 MB)
    mainnet.zip(47.05 KB)
    testnet.zip(42.73 KB)
  • v1.1.2(Aug 31, 2021)

    A hotfix release to patch a vulnerability in the EVM (CVE-2021-39137).

    Check ethereum/go-ethereum#23446 to follow the attack vector update.

    Changelog

    Security

    • #379 A pre-announced hotfix release to patch a vulnerability in the EVM (CVE-2021-39137).

    Assets

    | Assets | Sha256 Checksum | | :-----------: |------------| | mainnet.zip | 541028a68a26dc1d0828b144626e8d064ac9d0b6db1ad499700ec6f62559c336 | | testnet.zip | 0259269be86fbdfce14efe40e99874b95a4a3ed30949463c0cef9e776eb6b1b2 | | geth_linux | 8ba9f4afe6522608144a5fd4d280142cb7e12e244a00158bfee1a58eb78275c4 | | geth_mac | 9f78b4d3bd1655a2fd308bfd7beeec3b6c3b3399f1b24894447f2f41cfedb4cb |

    Source code(tar.gz)
    Source code(zip)
    geth_linux(46.42 MB)
    geth_mac(35.66 MB)
    mainnet.zip(47.05 KB)
    testnet.zip(41.17 KB)
  • v1.1.1(Aug 13, 2021)

    This release is a bug fix release.

    All clients are recommended to upgrade.

    CHANGELOG

    IMPROVEMENT

    • #355 miner should propose block on a proper fork

    BUGFIX

    • #350 flag: fix TriesInmemory specified but not work
    • #358 miner: fix null pending block
    • #360 pruner: fix state bloom sync permission in Windows
    • #366 fix double close channel of subfetcher

    Reducing Storage Occupation

    If the storage occupation of the bsc client increasing dramatically, you may consider increasing the TrieTimeout setting in config.toml.

    What does TrieTimeout means? The bsc client will keep MPT(Merkle Patricia Tree) in memory. Once the block processing time exceeds the TrieTimeout, the client will persis MPT into disk. If the client crash, it can recover from recent persisted MPT. Increasing the TrieTimeout setting will reduce storage occupation, in exchange, it will need more time to recover from a crash.

    The default setting before release v1.1.1 is 100000000000, it will persist MPT about every 35 minutes. We change the default setting to 2000000000000 in this release, it will persist MPT about every 12 hours.

    Assets

    | Assets | Sha256 Checksum |
    | :-----------: |------------| | mainnet.zip | fa3984a2e81f92f87448baef6b70c711f64800eda30bb3f38eea9e2d1a270c97 | | testnet.zip | 0259269be86fbdfce14efe40e99874b95a4a3ed30949463c0cef9e776eb6b1b2 | | geth_linux | 9ebf3e8ced77bfefe63d603f5e97a860e302b96443717a8a0e43dabc54fe6582 | | geth_mac | 1de3fd8f5322a94732f2f2b83cf77ff06bb5218a69991890a15e8f1ecf8de7f7 |

    Source code(tar.gz)
    Source code(zip)
    geth_linux(45.12 MB)
    geth_mac(37.81 MB)
    mainnet.zip(47.06 KB)
    testnet.zip(42.73 KB)
  • v1.1.1-beta(Jul 29, 2021)

    Description

    Please note this is just a beta version, some known bug fix is on the way. v1.1.1-beta is released which has better performance in order to handle the high volume. Please feel free to upgrade and raise bug reports onto the github.

    Sync Faster

    For nodes that need block sync as fast as possible, we highlight the suggested hardware here:

    For validator:

    • 2T GB of free disk space, solid-state drive(SSD), gp3, 8k IOPS, 250MB/S throughput, read latency <1ms
    • 12 cores of CPU and 48 gigabytes of memory (RAM)
    • m5zn.3xlarge instance type on AWS, or c2-standard-8 on Google cloud.
    • A broadband Internet connection with upload/download speeds of 10 megabyte per second

    For fullnode:

    • 1T GB of free disk space, solid-state drive(SSD), gp3, 3k IOPS, 125MB/S throughput, read latency <1ms. (if start with snap/fast sync, it will need NVMe SSD)
    • 8 cores of CPU and 32 gigabytes of memory (RAM).
    • c5.4xlarge instance type on AWS, c2-standard-8 on Google cloud.
    • A broadband Internet connection with upload/download speeds of 5 megabyte per second

    Snapshot

    if you want to setup a node without syncing, or replace the heavy data with light one, please refer to our latest snapshot page

    Changes

    *#333 improve block fetcher efficiency *#326 eth/tracers: improve tracing performance *#257 performance improvement in many aspects

    Source code(tar.gz)
    Source code(zip)
    geth_linux(46.36 MB)
    geth_mac(37.80 MB)
    mainnet.zip(47.06 KB)
    testnet.zip(42.73 KB)
  • v1.1.0(Jul 26, 2021)

  • v1.1.0-beta(May 10, 2021)

    Description

    This is a beta release that merges with go-ethereum v1.10.3.

    Changes

    Snapshots

    Snapshots are an acceleration data structure on top of the Ethereum state, that allows reading accounts and contract storage significantly faster. The snapshot feature reduces the cost of accessing an account from O(logN) to O(1).

    Though snapshots have enormous benefits, there are certain costs to them: A snapshot is a redundant copy of the raw Ethereum state already contained in the leaves of the Merkle Patricia trie so it requires an additional disk overhead. Since nobody has snapshots constructed in the network yet, nodes will initially need to bear the cost of iterating the state trie and creating the initial snapshot themselves. This might take a day to a week but you only need to do it once in the lifetime of your node.

    Snapshot feature is enabled by default, you can disable it via --snapshot=false.

    Snap sync

    Now you have two different ways to synchronize the BSC network: full sync and fast sync. Full sync operated by downloading the entire chain and executing all transactions; fast sync placed an initial trust in a recent-ish block, and directly downloaded the state associated with it (after which it switched to block execution like full sync).

    For fast sync, it needs to download the trie nodes one by one. So it will take time to download all the nodes if there are millions of nodes. And for the serving peers, they need to traverse all the nodes and it also takes time.

    Snap sync is designed to solve the fast sync problems. The core idea is instead of downloading the trie node-by-node, snap sync downloads the contiguous chunks of useful state data, and reconstructs the Merkle trie locally.

    You can manually enable snap sync via --syncmode=snap. Note: usually it will need one or two weeks until there is enough client upgrade to the version with snap enabled, you may use snap sync after that.

    Offline pruning

    If you have snapshots enabled and fully generated, Geth can use those as an acceleration structure to relatively quickly determine which trie nodes should be kept and which should be deleted. Pruning trie nodes based on snapshots does have the drawback that the chain may not progress during pruning. This means that you need to stop Geth, prune its database and then restart it.

    Execution time wise, pruning takes a few hours (greatly depends on your disk speed and accumulated junk), one third of which is indexing recent trie nodes from snapshots, one third deleting stale trie nodes and the last third compacting the database to reclaim freed up space. At the end of the process, your disk usage should approximately be the same as if you did a fresh sync.

    To prune your database, please run geth snapshot prune-state.

    Note: You need to upgrade the client and run for a while before prune the data

    Transaction unindexing

    Geth no longer keeps transaction inclusion info for all transactions, and instead limits the storage of inclusion records to one year. For application developers, this change means that very old transactions can no longer be accessed by hash. If you would like todisable this behavior and keep inclusion information for all historical transactions, you can re-enable indexing using the --txlookuplimit=0 command-line flag.

    Database changes

    There is an incompatible database change: adds a prefix for contract code in order to separate the codes and trie nodes.

    So if you use the version of geth, you will not be able to rollback to the older version geth.

    Geth command changes

    • --rpc -> --http - Enable the HTTP-RPC server
    • --rpcaddr -> --http.addr - HTTP-RPC server listening interface
    • --rpcport -> --http.port - HTTP-RPC server listening port
    • --rpccorsdomain -> --http.corsdomain - Domain from which to accept requests
    • --rpcvhosts -> --http.vhosts - Virtual hostnames from which to accept requests
    • --rpcapi -> --http.api - API’s offered over the HTTP-RPC interface
    • --wsaddr -> --ws.addr - WS-RPC server listening interface
    • --wsport -> --ws.port - WS-RPC server listening port
    • --wsorigins -> --ws.origins - Origins from which to accept websockets requests
    • --wsapi -> --ws.api - API’s offered over the WS-RPC interface
    • --gpoblocks -> --gpo.blocks - Number of blocks to check for gas prices
    • --gpopercentile -> --gpo.percentile - Percentile of recent txs to use as gas suggestion
    • --graphql.addr -> --graphql - Enable GraphQL on the HTTP-RPC server
    • --graphql.port -> --graphql - Enable GraphQL on the HTTP-RPC server
    • --pprofport -> --pprof.port - Profiler HTTP server listening port
    • --pprofaddr -> --pprof.addr - Profiler HTTP server listening interface
    • --memprofilerate -> --pprof.memprofilerate - Turn on memory profiling with the given rate
    • --blockprofilerate -> --pprof.blockprofilerate - Turn on block profiling with the given rate
    • --cpuprofile -> --pprof.cpuprofile - Write CPU profile to the given file

    For more details about the command changes, you can refer to: v1.10.0.

    Rpc changes

    BREAKING CHANGE: Non-EIP155 transactions (i.e. transactions which are not replay-protected) are now rejected by the RPC API. You can disable this restriction using the --rpc.allow-unprotected-txs command-line flag. Since there are txs signed by old clients, we need to add this flag for all our nodes.

    Response changes in eth_estimateGas, eth_call, eth_sendRawTransaction.

    The response will now add a message field in addition to the data field if these RPCs cause the EVM to execute a REVERT operation. For example:

    {
       "jsonrpc":"2.0",
       "id":1,
       "error":{
          "code":3,
          "message":"execution reverted: num_ is \u003c= 10",
          "data":"0x08c379a00000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000d6e756d5f206973203c3d20313000000000000000000000000000000000000000"
       }
    }
    

    Response changes in eth_getTransactionByBlockHashAndIndex, eth_getTransactionByBlockNumberAndIndex, eth_getTransactionByHash.

    The response now adds a type field to denote the transaction type. For example:

    {
       "jsonrpc":"2.0",
       "id":1,
       "result":{
          "blockHash":"0x812619b0a7eb58de4f4c4fcf0b497567705f9182c2ad102745fa5ed87b3d96b5",
          "blockNumber":"0x95dc",
          "from":"0xef7368f755f5f551a602971b1f792b2737bc6e16",
          "gas":"0x2dc6c0",
          "gasPrice":"0x430e23400",
          "hash":"0xabbed20a397ff811fddf2b3f559e6291c1d14c6456bd1eca5fde82169e283857",
          "input":"0x29e99f07000000000000000000000000000000000000000000000000000000000000000c",
          "nonce":"0x55731a",
          "to":"0x6ac00c8b5514496aaae72cc2e6b8d4c29ee7d4ba",
          "transactionIndex":"0x0",
          "value":"0x0",
          "type":"0x0",
          "v":"0x1b",
          "r":"0x6e8c8af7e3266f0216b9a796eddd736a4f9bcdbfd6a47c49f566c187174d3268",
          "s":"0x5bf210f56d04126e0864643cb06670abe46fbf935446438490c2ff9ce6921adf"
       }
    }
    

    GraphQL changes

    The GraphQL API is no longer available separately from the JSON-RPC HTTP server. If you want GraphQL, you need to enable it using the --http --graphql flag combination. The --graphql.port and --graphql.addr flags are no longer available.

    Config changes

    Remove whisper config.

    [Shh]
    MaxMessageSize = 1048576
    RestrictConnectionBetweenLightClients = true
    

    Remove GraphQL config.

    GraphQLPort
    GraphQLVirtualHosts
    

    Rename DiscoveryURLs to EthDiscoveryURLs.

    For more details about config changes, you can refer to go-ethereum v1.9.19, v1.9.21, v1.10.0

    Source code(tar.gz)
    Source code(zip)
    geth_linux(46.22 MB)
    geth_mac(37.78 MB)
    mainnet.zip(47.05 KB)
    testnet.zip(42.73 KB)
  • v1.0.7-ht.3(May 10, 2021)

  • v1.0.7-hf.1(May 7, 2021)

  • v1.0.7(Mar 25, 2021)

    v1.0.7 is a maintenance release that focuses on the performance improvement of validators, we suggest all validators upgrade to the latest version.

    • #120 add health check endpoint
    • #116 validator only write database state when enough distance
    • #115 add batch query methods
    • #112 apply max commit tx time for miner worker to avoid empty block
    • #101 apply block number limit for the eth_getLogs api
    • #99 enable directbroadcast flag to decrease the block propagation time
    • #90 add tini in docker image
    • #84 add jq in docker image
    Source code(tar.gz)
    Source code(zip)
    geth_linux(42.99 MB)
    geth_mac(40.76 MB)
    mainnet.zip(46.87 KB)
    testnet.zip(41.31 KB)
  • v1.0.5(Jan 19, 2021)

  • v1.0.4(Nov 23, 2020)

  • v1.0.3(Sep 24, 2020)

  • v1.0.2(Aug 28, 2020)

  • v1.0.1-beta.2(Aug 13, 2020)

  • v1.0.1-beta(Aug 11, 2020)

  • v1.0.0-beta.1(Jul 28, 2020)

  • v1.0.0-beta.0(Jul 9, 2020)

    Changelog

    FEATURES

    • #5 enable bep2e tokens for faucet
    • #14 add cross chain contract to system contract
    • #15 Allow liveness slash fail

    IMPROVEMENT

    • #11 remove redundant gaslimit check

    BUGFIX

    • #4 fix validator failed to sync a block produced by itself
    • #6 modify params for Parlia consensus with 21 validators
    • #10 add gas limit check in parlia implement
    • #13 fix debug_traceTransaction crashed issue
    Source code(tar.gz)
    Source code(zip)
    config.toml(3.45 KB)
    genesis.json(180.02 KB)
    geth_linux(46.96 MB)
    geth_mac(44.97 MB)
  • audit1.0(Jul 17, 2020)

  • v1.0.0-alpha.0(May 21, 2020)

Owner
For Binance Smart Chain, BSC, Binance Chain
null
A Binance Smart Chain client based on the go-ethereum fork

Binance Smart Chain The goal of Binance Smart Chain is to bring programmability and interoperability to Binance Chain. In order to embrace the existin

Sahara Street Platform 0 Feb 8, 2022
XT Smart Chain, a chain based on the go-ethereum fork

XT Smart Chain XT Smart Chain (XSC) is a decentralized, high-efficiency and ener

null 3 Apr 13, 2022
A Binance Smart Chain client based on the erigon fork

Erigon Erigon is an implementation of Ethereum (aka "Ethereum client"), on the efficiency frontier, written in Go. System Requirements Usage Getting S

null 25 May 2, 2022
Yet another Binance Smart Chain client based on TrustFi Network

TrustFi Smart Chain The goal of TrustFi Smart Chain is to bring programmability and interoperability to Binance Chain. In order to embrace the existin

TrustFi Network 19 Mar 27, 2021
A phoenix Chain client based on the go-ethereum fork,the new PoA consensus engine is based on the VRF algorithm.

Phoenix Official Golang implementation of the Phoenix protocol. !!!The current version is for testing and developing purposes only!!! Building the sou

g_master 14 Apr 28, 2022
Huobi Eco Chain client based on the go-ethereum fork

The Huobi Open Platform is a unified infrastructure platform based on the technical, traffic and ecological resources of the Huobi Group, and will be gradually open to the blockchain industry.

null 227 May 8, 2022
Ethereum-vanity-wallet - A fork of https://github.com/meehow/ethereum-vanity-wallet but the key can be exported to a JSON keystore file

ethereum-vanity-wallet See https://github.com/meehow/ethereum-vanity-wallet This version: doesn't display the private key let's you interactively expo

null 0 Jan 2, 2022
Ethereum go-ethereum - Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated b

null 6 Feb 17, 2022
A Binance Chain vanity address generator written in golang.

VaniBNB A Binance Chain vanity address generator written in golang. For example address ending with 0xkat Raw https://github.com/makevoid/vanieth http

undefi.org 6 Apr 21, 2022
Running chaincode in development mode: Smart contract developers that want to iteratively develop and test their chaincode packages without the overhead of the smart contract lifecycle process for every update.

Fabric DEVMODE - Nano bash 1 ORG + 1 PEER + 1 ORDERER Based on fabric-samples/test-network-nano-bash, but using devmode fabric peer Prereqs Follow the

Kmilo Denis González 2 May 5, 2022
LEO (Low Ethereum Orbit) is an Ethereum Portal Network client.

LEO LEO (Low Ethereum Orbit) is an Ethereum Portal Network client. What makes LEO different from other Portal Network clients is that it uses libp2p f

Valist, Inc. 10 Apr 19, 2022
This library aims to make it easier to interact with Ethereum through de Go programming language by adding a layer of abstraction through a new client on top of the go-ethereum library.

Simple ethereum client Simple ethereum client aims to make it easier for the developers to interact with Ethereum through a new layer of abstraction t

Jero 3 May 1, 2022
Berylbit PoW chain using Ethash, EPI-Burn and geth. The chain will be using bot congestion flashbot bundles through nodes

Berylbit PoW chain using Ethash, EPI-Burn and geth. The chain will be using bot congestion flashbot bundles through nodes. Soon, We will work towards

BerylBit 8 Mar 22, 2022
Go-chain - EVM-compatible chain secured by the Lachesis consensus algorithm

ICICB galaxy EVM-compatible chain secured by the Lachesis consensus algorithm. B

Talented Blockchain Developer 3 Apr 20, 2022
Rei chain fork from quorum using raft consensus

GoQuorum is an Ethereum-based distributed ledger protocol with transaction/contract privacy and new consensus mechanisms. GoQuorum is a fork of go-eth

Moon Rhythm 12 Mar 31, 2022
The Fabric Smart Client is a new Fabric Client that lets you focus on the business processes and simplifies the development of Fabric-based distributed application.

Fabric Smart Client The Fabric Smart Client (FSC, for short) is a new Fabric client-side component whose objective is twofold. FSC aims to simplify th

null 36 May 3, 2022
Accompanying repository for the "Build Ethereum From Scratch - Smart Contracts and More" course by David Katz

Build Ethereum From Scratch - Smart Contracts and More This repository accompanies the "Build Ethereum From Scratch - Smart Contracts and More" course

David Katz 36 May 2, 2022
On chain interactive fraud prover for Ethereum

The cannon (cannon cannon cannon) is an on chain interactive fraud prover It's half geth, half of what I think truebit was supposed to be. It can prov

George Hotz 5 Mar 31, 2022
ConsenSys Software 8 Jan 18, 2022