Oct
23
21 hours ago
Activity icon
fork

dzmitry-savitski forked binance-chain/bsc

⚡ A Binance Smart Chain client based on the go-ethereum fork
dzmitry-savitski GNU Lesser General Public License v3.0 Updated
fork time in 4 hours ago
Activity icon
issue

jino5577 issue comment binance-chain/bsc

jino5577
jino5577

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


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.

jino5577
jino5577

@jun0tpyrc @0fuz wow, snapshot way works like a charm. Thank you guys.

How have you downloaded and unzipped snapshot? It's now more than 600 Gb in zip while you have only 1Tb. Or you have just added flag "--syncmode snap" and that worked for you?

curl '<snapshot_url>' | tar -xz will extract snapshot data without saving the archive to disk.

Activity icon
issue

mjohn issue comment binance-chain/bsc

mjohn
mjohn

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


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.

mjohn
mjohn

@jun0tpyrc @0fuz wow, snapshot way works like a charm. Thank you guys.

How have you downloaded and unzipped snapshot? It's now more than 600 Gb in zip while you have only 1Tb. Or you have just added flag "--syncmode snap" and that worked for you?

Exactly, downloaded, and unzipped snapshot, I got an extra ssd, you'll need extra storage space for unzipping too.

I used "--syncmode fast".

Activity icon
issue

grGred issue comment binance-chain/bsc

grGred
grGred

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


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.

grGred
grGred

@jun0tpyrc @0fuz wow, snapshot way works like a charm. Thank you guys.

How have you downloaded and unzipped snapshot? It's now more than 600 Gb in zip while you have only 1Tb. Or you have just added flag "--syncmode snap" and that worked for you?

started
started time in 9 hours ago
Activity icon
issue

vrogojin issue comment binance-chain/bsc

vrogojin
vrogojin

panic: deletion not supported

Started fresh full node with snap sync geth --syncmode=snap --config ./config.toml --datadir node --cache 18000 --rpc --http.port 9545 --http.corsdomain "*" --http.api "eth,web3,personal,net,txpool" --ws --ws.port 8546 --ws.origins "*" \ --ws.api "eth,web3,personal,net,txpool" --rpc.allow-unprotected-txs --txlookuplimit 0 console

After around an hour it crashes


INFO [10-23|00:29:36.318] Starting Geth on Ethereum mainnet...
INFO [10-23|00:29:36.321] Maximum peer count                       ETH=30 LES=0 total=30
INFO [10-23|00:29:36.321] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
WARN [10-23|00:29:36.321] Option nousb is deprecated and USB is deactivated by default. Use --usb to enable
Welcome to the Geth JavaScript console!

instance: Geth/v1.1.2-c4f93121-20210825/linux-amd64/go1.15.14
at block: 0 (Mon Apr 20 2020 21:46:54 GMT+0800 (+08))
 datadir: <my_data_dir_here>
 modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 parlia:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

To exit, press ctrl-d
> eth.syncing.
eth.syncing.constructor eth.syncing.toString eth.syncing.valueOf
> eth.syncing
{ 
  currentBlock: 0,
  highestBlock: 11997535,
  knownStates: 0,
  pulledStates: 0,
  startingBlock: 0
}
> net.peerCount
2
> net.peerCount
4
> panic: deletion not supported

goroutine 459309 [running]:
github.com/ethereum/go-ethereum/trie.(*StackTrie).TryUpdate(0xc069403520, 0xc077307a00, 0x20, 0x20, 0x2857fb0, 0x0, 0x0, 0xc019bb5698, 0xc07dd149a0)
        github.com/ethereum/go-ethereum/trie/stacktrie.go:194 +0xd2
github.com/ethereum/go-ethereum/trie.(*StackTrie).Update(0xc069403520, 0xc077307a00, 0x20, 0x20, 0x2857fb0, 0x0, 0x0)
        github.com/ethereum/go-ethereum/trie/stacktrie.go:201 +0x77
github.com/ethereum/go-ethereum/eth/protocols/snap.(*Syncer).processStorageResponse(0xc00000c780, 0xc061a85500)
        github.com/ethereum/go-ethereum/eth/protocols/snap/sync.go:1928 +0x3f4
github.com/ethereum/go-ethereum/eth/protocols/snap.(*Syncer).Sync(0xc00000c780, 0xd206470f7c921f7b, 0x3ee4d8465b3ed0b8, 0xb21e6d5f47bdd0a1, 0xa01669445816a58b, 0xc01662c780, 0x0, 0x0)
        github.com/ethereum/go-ethereum/eth/protocols/snap/sync.go:653 +0xc2e
github.com/ethereum/go-ethereum/eth/downloader.(*stateSync).run(0xc02de3d7c0)
        github.com/ethereum/go-ethereum/eth/downloader/statesync.go:318 +0x87
created by github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).runStateSync
        github.com/ethereum/go-ethereum/eth/downloader/statesync.go:114 +0x1ef

Tried several times to do fresh sync. Impossible to sync full node. Any workaround?

Thanks

vrogojin
vrogojin

More clarifications: System information Geth Version: 1.1.2 (binary pre-build as of 22.10.2021) Architecture: amd64 Operating System: Ubuntu 20.04.3 LTS

Expected behaviour No panic.

Actual behaviour It panics.

Steps to reproduce the behaviour Run fresh geth for an hour, then it panics. geth --syncmode=snap --config ./config.toml --datadir node --cache 18000 --rpc --http.port 9545 --http.corsdomain "*" --http.api "eth,web3,personal,net,txpool" --ws --ws.port 8546 --ws.origins "*" \ --ws.api "eth,web3,personal,net,txpool" --rpc.allow-unprotected-txs --txlookuplimit 0 console

Backtrace


panic: deletion not supported

goroutine 459309 [running]:
github.com/ethereum/go-ethereum/trie.(*StackTrie).TryUpdate(0xc069403520, 0xc077307a00, 0x20, 0x20, 0x2857fb0, 0x0, 0x0, 0xc019bb5698, 0xc07dd149a0)
        github.com/ethereum/go-ethereum/trie/stacktrie.go:194 +0xd2
github.com/ethereum/go-ethereum/trie.(*StackTrie).Update(0xc069403520, 0xc077307a00, 0x20, 0x20, 0x2857fb0, 0x0, 0x0)
        github.com/ethereum/go-ethereum/trie/stacktrie.go:201 +0x77
github.com/ethereum/go-ethereum/eth/protocols/snap.(*Syncer).processStorageResponse(0xc00000c780, 0xc061a85500)
        github.com/ethereum/go-ethereum/eth/protocols/snap/sync.go:1928 +0x3f4
github.com/ethereum/go-ethereum/eth/protocols/snap.(*Syncer).Sync(0xc00000c780, 0xd206470f7c921f7b, 0x3ee4d8465b3ed0b8, 0xb21e6d5f47bdd0a1, 0xa01669445816a58b, 0xc01662c780, 0x0, 0x0)
        github.com/ethereum/go-ethereum/eth/protocols/snap/sync.go:653 +0xc2e
github.com/ethereum/go-ethereum/eth/downloader.(*stateSync).run(0xc02de3d7c0)
        github.com/ethereum/go-ethereum/eth/downloader/statesync.go:318 +0x87
created by github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).runStateSync
        github.com/ethereum/go-ethereum/eth/downloader/statesync.go:114 +0x1ef


Activity icon
issue

vrogojin issue comment binance-chain/bsc

vrogojin
vrogojin

panic: deletion not supported

Started fresh full node with snap sync geth --syncmode=snap --config ./config.toml --datadir node --cache 18000 --rpc --http.port 9545 --http.corsdomain "*" --http.api "eth,web3,personal,net,txpool" --ws --ws.port 8546 --ws.origins "*" \ --ws.api "eth,web3,personal,net,txpool" --rpc.allow-unprotected-txs --txlookuplimit 0 console

After around an hour it crashes


INFO [10-23|00:29:36.318] Starting Geth on Ethereum mainnet...
INFO [10-23|00:29:36.321] Maximum peer count                       ETH=30 LES=0 total=30
INFO [10-23|00:29:36.321] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
WARN [10-23|00:29:36.321] Option nousb is deprecated and USB is deactivated by default. Use --usb to enable
Welcome to the Geth JavaScript console!

instance: Geth/v1.1.2-c4f93121-20210825/linux-amd64/go1.15.14
at block: 0 (Mon Apr 20 2020 21:46:54 GMT+0800 (+08))
 datadir: <my_data_dir_here>
 modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 parlia:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

To exit, press ctrl-d
> eth.syncing.
eth.syncing.constructor eth.syncing.toString eth.syncing.valueOf
> eth.syncing
{ 
  currentBlock: 0,
  highestBlock: 11997535,
  knownStates: 0,
  pulledStates: 0,
  startingBlock: 0
}
> net.peerCount
2
> net.peerCount
4
> panic: deletion not supported

goroutine 459309 [running]:
github.com/ethereum/go-ethereum/trie.(*StackTrie).TryUpdate(0xc069403520, 0xc077307a00, 0x20, 0x20, 0x2857fb0, 0x0, 0x0, 0xc019bb5698, 0xc07dd149a0)
        github.com/ethereum/go-ethereum/trie/stacktrie.go:194 +0xd2
github.com/ethereum/go-ethereum/trie.(*StackTrie).Update(0xc069403520, 0xc077307a00, 0x20, 0x20, 0x2857fb0, 0x0, 0x0)
        github.com/ethereum/go-ethereum/trie/stacktrie.go:201 +0x77
github.com/ethereum/go-ethereum/eth/protocols/snap.(*Syncer).processStorageResponse(0xc00000c780, 0xc061a85500)
        github.com/ethereum/go-ethereum/eth/protocols/snap/sync.go:1928 +0x3f4
github.com/ethereum/go-ethereum/eth/protocols/snap.(*Syncer).Sync(0xc00000c780, 0xd206470f7c921f7b, 0x3ee4d8465b3ed0b8, 0xb21e6d5f47bdd0a1, 0xa01669445816a58b, 0xc01662c780, 0x0, 0x0)
        github.com/ethereum/go-ethereum/eth/protocols/snap/sync.go:653 +0xc2e
github.com/ethereum/go-ethereum/eth/downloader.(*stateSync).run(0xc02de3d7c0)
        github.com/ethereum/go-ethereum/eth/downloader/statesync.go:318 +0x87
created by github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).runStateSync
        github.com/ethereum/go-ethereum/eth/downloader/statesync.go:114 +0x1ef

Tried several times to do fresh sync. Impossible to sync full node. Any workaround?

Thanks

vrogojin
vrogojin

After this crash, bash console freezes. No I/O errors. No hardware errors. What is going on?

Activity icon
issue

vrogojin issue binance-chain/bsc

vrogojin
vrogojin

panic: deletion not supported

Started fresh full node with snap sync geth --syncmode=snap --config ./config.toml --datadir node --cache 18000 --rpc --http.port 9545 --http.corsdomain "*" --http.api "eth,web3,personal,net,txpool" --ws --ws.port 8546 --ws.origins "*" \ --ws.api "eth,web3,personal,net,txpool" --rpc.allow-unprotected-txs --txlookuplimit 0 console

After around an hour it crashes


INFO [10-23|00:29:36.318] Starting Geth on Ethereum mainnet...
INFO [10-23|00:29:36.321] Maximum peer count                       ETH=30 LES=0 total=30
INFO [10-23|00:29:36.321] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
WARN [10-23|00:29:36.321] Option nousb is deprecated and USB is deactivated by default. Use --usb to enable
Welcome to the Geth JavaScript console!

instance: Geth/v1.1.2-c4f93121-20210825/linux-amd64/go1.15.14
at block: 0 (Mon Apr 20 2020 21:46:54 GMT+0800 (+08))
 datadir: <my_data_dir_here>
 modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 parlia:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

To exit, press ctrl-d
> eth.syncing.
eth.syncing.constructor eth.syncing.toString eth.syncing.valueOf
> eth.syncing
{ 
  currentBlock: 0,
  highestBlock: 11997535,
  knownStates: 0,
  pulledStates: 0,
  startingBlock: 0
}
> net.peerCount
2
> net.peerCount
4
> panic: deletion not supported

goroutine 459309 [running]:
github.com/ethereum/go-ethereum/trie.(*StackTrie).TryUpdate(0xc069403520, 0xc077307a00, 0x20, 0x20, 0x2857fb0, 0x0, 0x0, 0xc019bb5698, 0xc07dd149a0)
        github.com/ethereum/go-ethereum/trie/stacktrie.go:194 +0xd2
github.com/ethereum/go-ethereum/trie.(*StackTrie).Update(0xc069403520, 0xc077307a00, 0x20, 0x20, 0x2857fb0, 0x0, 0x0)
        github.com/ethereum/go-ethereum/trie/stacktrie.go:201 +0x77
github.com/ethereum/go-ethereum/eth/protocols/snap.(*Syncer).processStorageResponse(0xc00000c780, 0xc061a85500)
        github.com/ethereum/go-ethereum/eth/protocols/snap/sync.go:1928 +0x3f4
github.com/ethereum/go-ethereum/eth/protocols/snap.(*Syncer).Sync(0xc00000c780, 0xd206470f7c921f7b, 0x3ee4d8465b3ed0b8, 0xb21e6d5f47bdd0a1, 0xa01669445816a58b, 0xc01662c780, 0x0, 0x0)
        github.com/ethereum/go-ethereum/eth/protocols/snap/sync.go:653 +0xc2e
github.com/ethereum/go-ethereum/eth/downloader.(*stateSync).run(0xc02de3d7c0)
        github.com/ethereum/go-ethereum/eth/downloader/statesync.go:318 +0x87
created by github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).runStateSync
        github.com/ethereum/go-ethereum/eth/downloader/statesync.go:114 +0x1ef

Tried several times to do fresh sync. Impossible to sync full node. Any workaround?

Thanks

started
started time in 11 hours ago
Activity icon
issue

blocksbarcelona issue comment binance-chain/bsc

blocksbarcelona
blocksbarcelona

BSC Light client peers - What is going on?

Have other people noticed a decrease in the number of peers light customer node? For the last two days I have a max of 5-13, where the norm is 25-36 peers. I noted this on 3 servers in different locations around the world. I tested on all releases 1.0.0 - 1.1.2

I use according needs:

--light.maxpeers 300 --ulc.onlyannounce --light.nopruning --light.nosyncserve

blocksbarcelona
blocksbarcelona

Yes. Same here. New server not able to sync.

Previous