availproject/avail

avail's Issues

feat: faucet problem from subwallet

Feature Request

Check the contributing guide

Summary

Detailed Description

Use Cases

Alternative Solutions

Additional Context

Discord server faucet bug:

Bug Report

Check the contributing guide

Description

After using the discord faucet for the first time, it links that particular wallet address to your discord account. When interacting with the avail clash of nodes, for example, the partnership with Dymension that recently closed, you'll need to change your wallet address from the previous address you used for the onchain identity task. Even after using the change address channel, I still get an error saying user ID does not match. I tried it for different wallets and i still got the same feedback.

Steps to Reproduce

1. Create wallet on goldberg
2. Type in "/deposit:[wallet adress]" on discord channel: Goldberg Faucet
3. Deploy rollapp on dymension selecting avail as your data availability layer
4. Copy the avail wallet address given to you on your linux environment
5. Go to the change address channel on the discord, follow the format given to you by the discord bot and then change wallet address.
6. Go to the goldberg facuet channel and attempot to request faucet

Expected Behavior

I expect that there would be a feedback that tells me that wallet address A has been changed to wallet address B.
I expect that when i go to the goldberg faucet channel and input my new wallet address for dymension, I would get a success feedback.

Actual Behavior

User ID does not match

Additional Information

I ran into this problem a lot of time while I was participating in the clash of nodes program. I even tried just linking my subwallet avail address to the faucet, but i still got errors sending from my subwallet. It made the whole processing frustrating cos I kept trying to get faucet and start the whole process again once the linux environment generated a new wallet and seedphrase for me for as many times as I tried doing the tasks.

bug: Avail Goldberg Testnet website page https://goldberg.avail.tools lacks a lot

it takes alot of time to use Avail Goldberg Testnet please insure to make it fast and reliable
.....
also i am unable to see my staked amount of avail tokens in pool page

A defensive failure has been triggered

Description

2024-05-03 08:28:30 💤 Idle (43 peers), best: #154655 (0x16d0…a026), finalized #154653 (0x4bfc…483f), ⬇ 53.3kiB/s ⬆ 57.1kiB/s
2024-05-03 08:28:35 💤 Idle (43 peers), best: #154655 (0x16d0…a026), finalized #154653 (0x4bfc…483f), ⬇ 97.1kiB/s ⬆ 89.1kiB/s
2024-05-03 08:28:40 a defensive failure has been triggered; please report the block number at https://github.com/paritytech/substrate/issues: "Paying out controller as reward destination which is deprecated and should be migrated."
2024-05-03 08:28:40 a defensive failure has been triggered; please report the block number at https://github.com/paritytech/substrate/issues: "Paying out controller as reward destination which is deprecated and should be migrated."
2024-05-03 08:28:40 ✨ Imported #154656 (0x3335…d987)
2024-05-03 08:28:40 💤 Idle (43 peers), best: #154656 (0x3335…d987), finalized #154653 (0x4bfc…483f), ⬇ 78.5kiB/s ⬆ 66.9kiB/s
2024-05-03 08:28:45 💤 Idle (43 peers), best: #154656 (0x3335…d987), finalized #154654 (0x7714…a1ad), ⬇ 154.1kiB/s ⬆ 122.3kiB/s

Additional Information

avail-node 2.1.0-af545459dd0
Ubuntu 22.04.4 LTS

bug: Discord Server Dcounter Bot

Bug Report

Description

Dcounter server bot verification link showing internal server error

Expected Behavior

Server error

Actual Behavior

The below images show the current behavior of the verification link

Note1----->
The above image shows a redirect link to Avail Discord channel

Note 2---->
The above image shows the output after clicking on the link supply by dcounter bot

Additional Information

A swift response to this will allow others to join the server and become a part of the community.

feat: Feedback for faucet wallet address change on the discord.

Feature Request

Check the contributing guide

Summary

It would be beneficial and make it easier to participate in Avail's testnet environment if the discord bot on the change wallet address channel gives a feedback saying if the address was successfully changed or not, or providing feedback on the old adress and new address.

Detailed Description

Providing feedback on the wallet address change would make it easier to track wallets used seeing that different tasks in the avail ecosystem would require for different wallet addresses.
For example, the wallet address for the Dymension partner challenge differs greatly from the wallet address for the goldberg onchain identity task.
Creating a feedback mechanism would improve user experience greatly and would make it easier to interact with the avail faucet and in extension, the avail ecosystem.

Use Cases

Faucet use for testing avail or partcipating in the clash of nodes challenge.

Alternative Solutions

I've tried scrolling through my inputs to the discord channel to find which address was changed from and which address was changed to. I've tried trying to keep track of the changes (especially when i run into errors on the partner challenges like deploying a rollapp or an appchain), but i keep running into issues when it comes to using the faucet. I just keep getting user ID does not match and I have no idea why. IT really did frustrate my experience when testing and particpating in the clash of nodes challenge. I ended up not being able to find a solution and missed out on the challenge.

An alternative solution can be a checkmark or a cancel that clearly states whether the wallet address change was succesful or not.

Additional Context

bug: This that needed to be fixed in Avail

Bug Report

Check the contributing guide

Description

<1. FAUCET been down for hours>
<2. Get some errors after compiling>
<3. Hard to access explorer>
4. Not mobile friendly the explorer (Need a nicer User interface) no Normal web 2 "Dev" user going to understand that apart from web 3 devs

Steps to Reproduce

Expected Behavior

Actual Behavior

Additional Information

RPC-CORE: submitExtrinsic(extrinsic: Extrinsic): Hash:: 1010: Invalid Transaction: Transaction has a bad signature RpcError: 1010: Invalid Transaction: Transaction has a bad signaturebug:

I config the rpc with 'wss://goldberg.avail.tools/ws' and the mnemonic in 'example/ts/src/config.ts', then I run the test case in 'example/ts/src/transfer.ts'，it returns an error, "RPC-CORE: submitExtrinsic(extrinsic: Extrinsic): Hash:: 1010: Invalid Transaction: Transaction has a bad signature RpcError: 1010: Invalid Transaction: Transaction has a bad signaturebug:"

Low sync speed (bps)

Description

Hello, I'm Luca from 🧊 Iceberg Nodes 🧊
This is not properly a bug, but I would like to signaling this probable issue.
We have migrated our node from Kate Testnet to Goldberg Testnet. In syncing Kate Testnet we are experiencing a very slow sync speed: about 6.6 bps - blocks per second usually per our experience it is something like 300-600 range depending on circumstances. The hardware is far above the minimum specs recommended, also we are NOT using any particular sync flag like --sync fast or --sync warp or other. But also for a full sync it should be more quickly than 6.6 bps usually.

Steps to Reproduce

Lanch a Goldberg Testnet full node and sync from scratch.

Expected Behavior

Usually 300-600 bps range or higher.

Actual Behavior

About 6.6 bps.

Additional Information

It seems that also other nodes are in the same situation:
Ordered by best block:

Ordered by uptime:

feat: Is the new version the mainnet? Can I directly update from Goldberg to the mainnet?

Feature Request

Check the contributing guide

Summary

Detailed Description

Use Cases

Alternative Solutions

Additional Context

Node

can anyone confirm me if my node is running properly or not

bug: WASM backtrace

Bug Report

availj/avail:v1.8.0.5 happens WASM backtrace

Description

💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWMR9ZoAVWJv6ahraVzUCfacNbFKk7ABoWxVL3fJ3XXGDw): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"

some problem happened in run in full node

Steps to Reproduce

sudo docker run -v $(pwd)/state:/da/state:rw -p 30333:30333 -p 9615:9615 -p 9944:9944 -d --restart unless-stopped availj/avail:v1.8.0.5 --chain goldberg --validator --name "DivenNode" -d /da/state

Expected Behavior

only show succuss

Actual Behavior

2024-01-08 15:35:19 2024-01-08 07:35:19 Avail Node
2024-01-08 15:35:19 2024-01-08 07:35:19 ✌️ version 1.8.4-ebfdac995db
2024-01-08 15:35:19 2024-01-08 07:35:19 ❤️ by Anonymous, 2017-2024
2024-01-08 15:35:19 2024-01-08 07:35:19 📋 Chain specification: Avail Goldberg Testnet
2024-01-08 15:35:19 2024-01-08 07:35:19 🏷 Node name: DivenNode
2024-01-08 15:35:19 2024-01-08 07:35:19 👤 Role: AUTHORITY
2024-01-08 15:35:19 2024-01-08 07:35:19 💾 Database: RocksDb at /da/state/chains/avail_goldberg_testnet/db/full
2024-01-08 15:35:23 2024-01-08 07:35:23 You're running on a system with a broken madvise(MADV_DONTNEED) implementation. This will result in lower performance.
2024-01-08 15:35:26 2024-01-08 07:35:26 👶 Creating empty BABE epoch changes on what appears to be first startup.
2024-01-08 15:35:26 2024-01-08 07:35:26 🏷 Local node identity is: 12D3KooWBv91KTShg6TNgEAfjSUHUQBtLu7UceySAxNpwahfeBUo
2024-01-08 15:35:26 2024-01-08 07:35:26 Prometheus metrics extended with avail metrics
2024-01-08 15:35:26 2024-01-08 07:35:26 💻 Operating system: linux
2024-01-08 15:35:26 2024-01-08 07:35:26 💻 CPU architecture: x86_64
2024-01-08 15:35:26 2024-01-08 07:35:26 💻 Target environment: gnu
2024-01-08 15:35:26 2024-01-08 07:35:26 💻 Memory: 7841MB
2024-01-08 15:35:26 2024-01-08 07:35:26 💻 Kernel: 6.4.16-linuxkit
2024-01-08 15:35:26 2024-01-08 07:35:26 💻 Linux distribution: Debian GNU/Linux 12 (bookworm)
2024-01-08 15:35:26 2024-01-08 07:35:26 💻 Virtual machine: no
2024-01-08 15:35:26 2024-01-08 07:35:26 📦 Highest known block at #0
2024-01-08 15:35:26 2024-01-08 07:35:26 〽️ Prometheus exporter started at 127.0.0.1:9615
2024-01-08 15:35:26 2024-01-08 07:35:26 Running JSON-RPC server: addr=127.0.0.1:9944, allowed origins=["http://localhost:", "http://127.0.0.1:", "https://localhost:", "https://127.0.0.1:", "https://polkadot.js.org"]
2024-01-08 15:35:27 2024-01-08 07:35:27 🏁 CPU score: 212.71 MiBs
2024-01-08 15:35:27 2024-01-08 07:35:27 🏁 Memory score: 5.29 GiBs
2024-01-08 15:35:27 2024-01-08 07:35:27 🏁 Disk score (seq. writes): 1.82 GiBs
2024-01-08 15:35:27 2024-01-08 07:35:27 🏁 Disk score (rand. writes): 25.94 MiBs
2024-01-08 15:35:27 2024-01-08 07:35:27 👶 Starting BABE Authorship worker
2024-01-08 15:35:28 2024-01-08 07:35:28 🔍 Discovered new external address for our node: /ip4/212.87.194.26/tcp/30333/p2p/12D3KooWBv91KTShg6TNgEAfjSUHUQBtLu7UceySAxNpwahfeBUo
2024-01-08 15:35:29 2024-01-08 07:35:29 Failed to publish external addresses: Failed calling into the Substrate runtime: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch
2024-01-08 15:35:29 WASM backtrace:
2024-01-08 15:35:29 error while executing at wasm backtrace:
2024-01-08 15:35:29 0: 0x129d20 - !AuthorityDiscoveryApi_authorities
2024-01-08 15:35:29 2024-01-08 07:35:29 Failed to request addresses of authorities: Failed calling into the Substrate runtime: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch
2024-01-08 15:35:29 WASM backtrace:
2024-01-08 15:35:29 error while executing at wasm backtrace:
2024-01-08 15:35:29 0: 0x129d20 - !AuthorityDiscoveryApi_authorities
2024-01-08 15:35:30 2024-01-08 07:35:30 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWMR9ZoAVWJv6ahraVzUCfacNbFKk7ABoWxVL3fJ3XXGDw): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:30 2024-01-08 07:35:30 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWCVqFvrP3UJ1S338Gb8SHvEQ1xpENLb45Dbynk4hu1XGN): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:32 2024-01-08 07:35:32 ⚙️ Syncing, target=#263387 (7 peers), best: #0 (0x6f09…a7ae), finalized #0 (0x6f09…a7ae), ⬇ 158.2kiB/s ⬆ 12.1kiB/s
2024-01-08 15:35:32 2024-01-08 07:35:32 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWMuyLE3aPQ82HTWuPUCjiP764ebQrZvGUzxrYGuXWZJZV): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:33 2024-01-08 07:35:33 Failed to publish external addresses: Failed calling into the Substrate runtime: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch
2024-01-08 15:35:33 WASM backtrace:
2024-01-08 15:35:33 error while executing at wasm backtrace:
2024-01-08 15:35:33 0: 0x129d20 - !AuthorityDiscoveryApi_authorities
2024-01-08 15:35:33 2024-01-08 07:35:33 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWGB5G2YotF74zVyudJQBWs84DE6vmUNweoASAdGYkn8k5): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:33 2024-01-08 07:35:33 Failed to request addresses of authorities: Failed calling into the Substrate runtime: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch
2024-01-08 15:35:33 WASM backtrace:
2024-01-08 15:35:33 error while executing at wasm backtrace:
2024-01-08 15:35:33 0: 0x129d20 - !AuthorityDiscoveryApi_authorities
2024-01-08 15:35:33 2024-01-08 07:35:33 🔍 Discovered new external address for our node: /ip4/120.227.48.157/tcp/30333/p2p/12D3KooWBv91KTShg6TNgEAfjSUHUQBtLu7UceySAxNpwahfeBUo
2024-01-08 15:35:33 2024-01-08 07:35:33 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWBnepGhUmCbAyRX4J9NGLCVa9q1iQne8xCPFxfSTqp4Z5): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:35 2024-01-08 07:35:35 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWDrrGMq9AMYwwdesSfJ95vUgqwUQnPwQ51ZGPcmYXpzA5): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:35 2024-01-08 07:35:35 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWPfyTptrbQCErpbSWX2cHcA2VgURqXKupHFKTZNUtVPNi): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:37 2024-01-08 07:35:37 ⚙️ Syncing 0.0 bps, target=#263387 (8 peers), best: #0 (0x6f09…a7ae), finalized #0 (0x6f09…a7ae), ⬇ 347.1kiB/s ⬆ 20.1kiB/s
2024-01-08 15:35:37 2024-01-08 07:35:37 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWJMfFsNg3m9b2JZcDR6cu4WzveE3neLPRNdMT47ooffCm): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:38 2024-01-08 07:35:38 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWKsypmpUq1RGRneTHSU2kCCmethF7nLW2rHf8ie3pUEC1): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:38 2024-01-08 07:35:38 💔 Error importing block 0x300e6395645f9a97c60266e45a8c5be73faa0b970aae3e79f1e175c1bd72c1a2: block has an unknown parent
2024-01-08 15:35:40 2024-01-08 07:35:40 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWKGg7gDz2UHh6kHV6VhRJa6HuTc2ng42d8WWLP2ND7paA): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:41 2024-01-08 07:35:41 Failed to publish external addresses: Failed calling into the Substrate runtime: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch
2024-01-08 15:35:41 WASM backtrace:
2024-01-08 15:35:41 error while executing at wasm backtrace:
2024-01-08 15:35:41 0: 0x129d20 - !AuthorityDiscoveryApi_authorities
2024-01-08 15:35:41 2024-01-08 07:35:41 Failed to request addresses of authorities: Failed calling into the Substrate runtime: Error at calling runtime api: Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch
2024-01-08 15:35:41 WASM backtrace:
2024-01-08 15:35:41 error while executing at wasm backtrace:
2024-01-08 15:35:41 0: 0x129d20 - !AuthorityDiscoveryApi_authorities
2024-01-08 15:35:41 2024-01-08 07:35:41 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWETjdK4fbKphVWHi6i82XQDEwdA1CN5yWPcaNYsEyNLPx): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:41 2024-01-08 07:35:41 💔 Error importing block 0x300e6395645f9a97c60266e45a8c5be73faa0b970aae3e79f1e175c1bd72c1a2: block has an unknown parent
2024-01-08 15:35:42 2024-01-08 07:35:42 ⚙️ Syncing 0.0 bps, target=#263388 (7 peers), best: #0 (0x6f09…a7ae), finalized #0 (0x6f09…a7ae), ⬇ 362.2kiB/s ⬆ 20.8kiB/s
2024-01-08 15:35:42 2024-01-08 07:35:42 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWPJqsMUgVYWRvEbDziaiNA66numQYPLGeYGgwHUj2VZZ6): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"
2024-01-08 15:35:42 2024-01-08 07:35:42 💔 Error importing block 0x535656b0b5f5195ba79a088c3c157826caa840875e010bfc8ce87196c8ecb9f7: block has an unknown parent
2024-01-08 15:35:44 2024-01-08 07:35:44 💔 Verification failed for block 0xd9e6fa8a039a40f7764d15a38eed7a346fcae71b61a5d15943a1ea18811c239a received from (12D3KooWJqdiZivvrKBBAPuwcUSey32tVw9jpwawQoyfAyFCNbZe): "Execution failed: Execution aborted due to trap: wasm trap: indirect call type mismatch\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x12857a - !BlockBuilder_check_inherents"

Additional Information

transfer_keep_alive return wasm error

extrinsic: 41028400ba264b7c2da1e38e85f2fbff19a75cd21536bdadabf57839f8c9bd2e074dff3f01aa743be4591b872fad9a7181f09d35294fe9eb9d0fe19c8b56fee2b40e9f5056fc4135648567fe3a71a57b3f7bf0543fe3688204b6da22222206a75a6fa76b89150304000603008bebfe7c3f82aa1e5130017d58aa03bd6806a8c7cace9fcf0516dc2a7fdbeb64070070c9b28b

Exception: {code: 1002, message: Verification Error: Runtime error: Execution failed: Execution aborted due to trap: wasm trap: wasm unreachable instruction executed
WASM backtrace:
error while executing at wasm backtrace:
0: 0x36e7c0 - !rust_begin_unwind
1: 0xef50 - !core::panicking::panic_fmt::h6dad0405f48e39e2
2: 0x2c96a0 - !TaggedTransactionQueue_validate_transaction, data: RuntimeApi("Execution failed: Execution aborted due to trap: wasm trap: wasm unreachable instruction executed\nWASM backtrace:\nerror while executing at wasm backtrace:\n 0: 0x36e7c0 - !rust_begin_unwind\n 1: 0xef50 - !core::panicking::panic_fmt::h6dad0405f48e39e2\n 2: 0x2c96a0 - !TaggedTransactionQueue_validate_transaction")}

feat: Secure Multi-Party Computation (SMPC) for Avail

Secure Multi-Party Computation (SMPC) for Avail

Summary: Implement Secure Multi-Party Computation (SMPC) functionality within the Avail project to enable secure and private computations on confidential data across multiple parties without revealing the underlying data itself.

Detailed Description:

SMPC is a cryptographic technique that allows multiple parties to jointly compute a function on their private inputs without disclosing those inputs to each other or to any third party. This offers significant advantages in blockchain applications, particularly for Avail's focus on decentralized finance (DeFi).

Use Cases:

• Private Credit Scoring: Financial institutions can collaborate to assess a borrower's creditworthiness without revealing individual credit details, protecting user privacy and reducing fraud risks.
• Joint Risk Assessment: Insurance companies can share and analyze risk data for specific events (e.g., natural disasters) while keeping individual policyholder information confidential.
• Secure Market Analysis: Investment firms can collaborate on market analysis and generate insights without disclosing their individual trading positions.
• Fraud Detection: Consortiums of financial institutions can combine data for fraud detection without revealing sensitive customer information.

Alternative Solutions:

• Homomorphic Encryption (HE): While HE allows computations on encrypted data, it is computationally expensive and might not be suitable for real-world DeFi applications.
• Trusted Execution Environments (TEEs): TEEs provide a secure enclave within a processor for computations, but they introduce a centralized element that might contradict Avail's decentralized philosophy.

Alternative Context:

• Privacy-Preserving DeFi: SMPC integration strengthens Avail's position in privacy-focused DeFi, attracting users who value control over their financial data.
• Regulatory Compliance: SMPC can help Avail comply with evolving data privacy regulations like GDPR and CCPA by enabling secure collaboration without compromising user privacy.

Benefits of Implementing SMPC:

• Enhanced User Privacy: Users retain control over their data while participating in DeFi activities.
• Increased Security: SMPC mitigates risks associated with data breaches and unauthorized access.
• Improved Collaboration: Enables secure data sharing and collaboration between different parties in the DeFi ecosystem.
• Scalability: SMPC solutions are constantly evolving to handle increasing data volumes and transaction rates.

Next Steps:

• Conduct a feasibility study to evaluate the technical challenges and potential integration methods for SMPC within Avail.
• Engage with the Avail community to gather feedback and assess user demand for this feature.
• Explore collaborations with existing SMPC protocol developers for efficient integration.

By implementing SMPC functionality, Avail can position itself as a leader in privacy-preserving DeFi, fostering a secure and collaborative financial ecosystem.

bug: i set on-chain identity 3 times but it still shows empty

Bug Report

i set on-chain identity 3 times but it still shows empty please look into this matter

Description

we are not able to see the on-chain identity once we set it

Steps to Reproduce

1. visit https://goldberg.avail.tools/#/accounts
2. choose your account and click on 3 dots, you will see set on-chain identity option click on it
3. set your details and save it and brodcast the transction
4. repeat steps and you will see your on-chain identity is not saved

Expected Behavior

i expect it will save the on-chain identity which i will set

feat: Decentralized Key Generation (DKG) as a Service on Avail

Summary: Integrate a Decentralized Key Generation (DKG) service into the Avail network, allowing users to securely generate and manage cryptographic keys in a distributed and trustless manner.

Detailed Description:

Avail's secure enclave technology provides a foundation for building trustless applications. However, securely generating and managing cryptographic keys remains a significant challenge. This feature request proposes incorporating a DKG service within Avail, enabling users to:

• Generate shared keys: Multiple parties can collaboratively generate cryptographic keys without any single entity possessing complete control.
• Threshold signatures: Implement threshold signature schemes where a certain number of parties need to contribute to sign a transaction, enhancing security and fault tolerance.
• Key management: Securely store and manage keys generated through DKG within Avail enclaves, ensuring confidentiality and integrity.

Use Cases:

• Multi-party computation (MPC): Securely conduct computations on private data without revealing the underlying information, requiring distributed key generation for participant authentication and data integrity.
• DAO governance: Implement secure and transparent voting mechanisms within DAOs, leveraging DKG for key generation and threshold signatures to authorize actions without centralized control.
• Custody wallets: Enhance the security of custody wallets by employing DKG to generate and manage keys across multiple servers or enclaves, mitigating single points of failure and insider threats.

Alternative Solutions:

• Hardware Security Modules (HSMs): While offering strong security, HSMs introduce centralized points of control and potential vulnerabilities.
• Shamir's Secret Sharing: This manual key splitting technique lacks the automation and trustless environment offered by DKG.

Additional Context:

• Integration with existing Avail services: Seamlessly integrate the DKG service with other Avail offerings like secure computation and confidential storage for a comprehensive suite of privacy-preserving functionalities.
• Standardization and interoperability: Adhere to established DKG standards (e.g., BLS) to ensure compatibility with other blockchain ecosystems and applications.
• Security considerations: Conduct thorough security audits and implement best practices for key management within Avail enclaves to guarantee the integrity and confidentiality of generated keys.

Benefits:

• Enhanced security: Mitigates the risks associated with centralized key generation and storage, fostering trust and transparency in decentralized applications.
• Improved user experience: Simplifies key management for users by providing a secure and user-friendly interface within the Avail ecosystem.
• Unlocks new use cases: Enables the development of novel applications requiring secure and distributed key management, expanding the potential of Avail technology.

Challenges:

• Technical complexity: Implementing a robust and efficient DKG service while maintaining security and scalability requires careful design and engineering.
• User adoption: Educating users on the benefits and proper usage of DKG is crucial for widespread adoption within the Avail ecosystem.
• Regulatory considerations: Depending on the specific implementation, regulatory compliance regarding key management and cryptographic protocols might need to be addressed.

By incorporating a DKG service, Avail can empower users with secure and trustless key management capabilities, fostering the development of innovative and privacy-preserving decentralized applications while addressing the inherent challenges associated with centralized key generation and storage. This feature aligns with Avail's vision of building a secure and scalable foundation for future decentralized applications.

bug: i have 10 avail and it keeps bringing an error message when i try to join the pools.

Bug Report

Check the contributing guide

Description

Steps to Reproduce

Expected Behavior

Actual Behavior

Additional Information

bug: block synchronization is stocked if the node is started from a servere, where a node started and stopped previously

Bug Report

block synchronization is stocked if the node is started from a servere, where a node started and stopped previously. The stocked point is the block hight of the previous running round

Description

the synchronization stocked with following error message:

Jan 23 20:24:41 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:24:41 🔍 Discovered new external address for our node: /ip4/206.217.136.229/tcp/30333/p2p/12D3KooWPekRv4ADsX7aqTDKHjNBB4En8Ndhvp4HqeQaaZ76rR7e
Jan 23 20:24:45 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:24:45 ⚙️ Syncing, target=#328646 (8 peers), best: #276333 (0x12c9…298d), finalized #271872 (0x9e17…e455), ⬇ 9.0MiB/s ⬆ 629.9kiB/s
Jan 23 20:24:50 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:24:50 ⚙️ Syncing 0.0 bps, target=#328646 (8 peers), best: #276333 (0x12c9…298d), finalized #271872 (0x9e17…e455), ⬇ 10.9MiB/s ⬆ 1.4MiB/s
Jan 23 20:24:55 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:24:55 ⚙️ Syncing 0.0 bps, target=#328646 (8 peers), best: #276333 (0x12c9…298d), finalized #271872 (0x9e17…e455), ⬇ 12.4MiB/s ⬆ 746.6kiB/s
Jan 23 20:25:00 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:25:00 ⚙️ Syncing 0.0 bps, target=#328646 (8 peers), best: #276333 (0x12c9…298d), finalized #271872 (0x9e17…e455), ⬇ 12.7MiB/s ⬆ 139.1kiB/s
Jan 23 20:25:00 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:25:00 ❌ Error while dialing /dns/telemetry.avail.tools/tcp/8001/x-parity-ws/%2Fsubmit: Custom { kind: Other, error: Timeout }
Jan 23 20:25:05 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:25:05 ⚙️ Syncing 0.0 bps, target=#328646 (8 peers), best: #276333 (0x12c9…298d), finalized #271872 (0x9e17…e455), ⬇ 13.1MiB/s ⬆ 75.6kiB/s
Jan 23 20:25:10 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:25:10 ⚙️ Syncing 0.1 bps, target=#328646 (8 peers), best: #276334 (0xa880…f64a), finalized #271872 (0x9e17…e455), ⬇ 11.8MiB/s ⬆ 79.8kiB/s
Jan 23 20:26:16 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:26:16 ⚙️ Syncing 0.0 bps, target=#328646 (8 peers), best: #276335 (0x557b…725a), finalized #271872 (0x9e17…e455), ⬇ 541.7kiB/s ⬆ 4.8kiB/s
Jan 23 20:26:24 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:26:24 ❌ Error while dialing /dns/telemetry.avail.tools/tcp/8001/x-parity-ws/%2Fsubmit: Custom { kind: Other, error: Timeout }
Jan 23 20:26:24 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:26:24 ⚙️ Syncing 0.0 bps, target=#328647 (2 peers), best: #276335 (0x557b…725a), finalized #271872 (0x9e17…e455), ⬇ 297.2kiB/s ⬆ 48.1kiB/s
Jan 23 20:26:29 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:26:29 ⚙️ Syncing 0.1 bps, target=#328651 (5 peers), best: #276336 (0x6b53…b791), finalized #271872 (0x9e17…e455), ⬇ 1.2MiB/s ⬆ 156.9kiB/s
Jan 23 20:26:29 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:26:29 👴 Applying authority set change scheduled at block #273900
Jan 23 20:26:30 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:26:30 👴 Applying GRANDPA set change to new set with 290 authorities
Jan 23 20:26:34 racknerd-2233d3 data-avail[165179]: 2024-01-23 20:26:34 ⚙️ Syncing 0.0 bps, target=#328651 (8 peers), best: #276336 (0x6b53…b791), finalized #271872 (0x9e17…e455), ⬇ 1.2MiB/s ⬆ 75.5kiB/s
Jan 23 20:26:48 racknerd-2233d3 systemd[1]: availd.service: Main process exited, code=killed, status=9/KILL
Jan 23 20:26:48 racknerd-2233d3 systemd[1]: availd.service: Failed with result 'signal'.
Jan 23 20:26:48 racknerd-2233d3 systemd[1]: availd.service: Consumed 2min 47.396s CPU time.
Jan 23 20:28:49 racknerd-2233d3 systemd[1]: availd.service: Scheduled restart job, restart counter is at 375.
Jan 23 20:28:49 racknerd-2233d3 systemd[1]: Stopped Avail Validator.

Steps to Reproduce

1. Start the node and finish the synchronization
2. Stop the node, where the block hight is X
3. Remove the existing repo and resynchronize/recompile the sw
4. Start the node from very beginning (without any exisiting block data)

Expected Behavior

Node can synchronize to the newest block hight

Actual Behavior

Node synchonization is stocked at block hight X

Additional Information

According to the following console output:

Discovered new external address for our node: /ip4/206.217.136.229/tcp/30333/p2p/12D3KooWPekRv4ADsX7aqTDKHjNBB4En8Ndhvp4HqeQaaZ76rR7e

where the IP is exactly the server IP. It seems like the SW considers the removed node, which was running in this IP as a best peer to synchronize block data. But the previous node is already stopped and doesn't exist anymore, which means no new block data is available since it was stopped. Therefore the current node is just waiting for this non-existed node to synchronize the block data and stocked.

Error importing block xxx: block has an unknown parent

Bug Report

Description

Steps to Reproduce

I start a full node on aliyun, system

1. run using binary v1.09
2. start command

./data-avail -d ./data --chain goldberg --name RollTheWordLabs

3. pkill data-avail and restart , then issue occured in the above picture
   I'm sure that I have't force kill

Expected Behavior

Actual Behavior

Additional Information

hello gitcoin fail ,please send me some test token 5CetqgiSbUjsPG2MFT767RceTSGDMSWh8KddjsWXQgSXJZ7x

hello gitcoin fail ,please send me some test token 5CetqgiSbUjsPG2MFT767RceTSGDMSWh8KddjsWXQgSXJZ7x

20 but fail

Bug Report

Check the contributing guide

Description

Steps to Reproduce

Expected Behavior

Actual Behavior

Additional Information

Use polkadart lib to sendTransfer failed, but same logic work on polkadot, kusama, westend. any diff from avail?

posted detail on leonardocustodio/polkadart#444

bug: availd.service: Failed with result 'signal'

Bug Report

Availd Service auto kill process when sync node.

Description

Avail auto kill & restart ~ 12m-15m once.
Log:

Feb 25 23:28:14 vmi1676799 systemd[1]: availd.service: Main process exited, code=killed, status=9/KILL
Feb 25 23:28:14 vmi1676799 systemd[1]: availd.service: Failed with result 'signal'.

image:

Steps to Reproduce

1. I setup node & sync data full db: https://github.com/availproject/avail/releases/tag/v1.10.0.0
2. Exce: /root/avail/target/release/data-avail -d /root/avail/output --chain goldberg --name LD-Fullnode --unsafe-da-sync
3. Service start normal and loop kill process ~ 12m - 15m / once

Expected Behavior

Actual Behavior

Additional Information

bug: 503 Service Temporarily Unavailable - https://goldberg.avail.tools/api

Bug Report

503 Service Temporarily Unavailable

Description

Testnet api is down

Steps to Reproduce

Access https://goldberg.avail.tools/api

Expected Behavior

Should response 200

Actual Behavior

503 Service Temporarily Unavailable

Does avail-apps v1.8-rc8 changed will sync to avail chain spec/metadata?

As https://github.com/availproject/avail-apps/releases/tag/v1.8-rc8 include types changed, will this types update sync to chain spec or metadata?

bug: docker container keeps crashing

Bug Report

Description

the docker container keeps restarting again and agin, when I use the dmesg, find the error message as following: [Tue Dec 5 22:26:31 2023] traps: data-avail[420675] trap invalid opcode ip:557516a4d6ae sp:7fff07a40348 error:0 in data-avail[557514bc1000+26d6000]

Steps to Reproduce

1. follow the guide How to Run a Full Node with Docker

Expected Behavior

container runs normally

Actual Behavior

container keeps crashing

Additional Information

• os: Ubuntu 20.04 LTS
• kernel: 5.4.0-29-generic
• cpu: Intel(R) Xeon(R) CPU E5-2678 v3 @ 2.50GHz
• cpu cores: 8
• memory: 2G
• arch: x86-64
• running commad: sudo docker run -v $(pwd)/state:/da/state:rw -p 30333:30333 -p 9615:9615 -p 9944:9944 -d --restart unless-stopped availj/avail:v1.8.0.3 --chain goldberg --name "MyAweasomeInContainerAvailAnode" -d /da/state
• node type: full node

failed to select version for parity-scale-codec when building

simply running cargo build --release -p data-avail gives me the following dependency version error for the crate parity-scale-codec :

error: failed to run custom build command for `da-runtime v6.0.0 (/home/user/avail/runtime)`

Caused by:
  process didn't exit successfully: `/home/user/avail/target/release/build/da-runtime-4f79b26897e27741/build-script-build` (exit status: 1)
  --- stdout
  Information that should be included in a bug report.
  Executing build command: "rustup" "run" "nightly-2021-12-14" "cargo" "-Zfeatures=build_dep" "rustc" "--target=wasm32-unknown-unknown" "--manifest-path=/home/user/avail/target/release/wbuild/da-runtime/Cargo.toml" "--color=always" "--release"
  Using rustc version: rustc 1.59.0-nightly (8f117a77d 2021-12-13)


  --- stderr
  warning: flag `-Z features` has been stabilized in the 1.51 release, and is no longer necessary
    The new feature resolver is now available by specifying `resolver = "2"` in Cargo.toml.
    See https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2 for more information.

      Updating crates.io index
  error: failed to select a version for the requirement `parity-scale-codec = "^3.0.0"`
  candidate versions found which didn't match: 3.1.5, 3.1.3, 3.1.2, ...
  location searched: crates.io index
  required by package `kate v0.5.0 (https://github.com/maticnetwork/avail-core.git?tag=da/v0.4.0#38ee8798)`
      ... which satisfies git dependency `kate` (locked to 0.5.0) of package `da-runtime v6.0.0 (/home/user/avail/runtime)`
      ... which satisfies path dependency `wasm-project` (locked to 6.0.0) of package `da-runtime-wasm v1.0.0 (/home/user/avail/target/release/wbuild/da-runtime)`
warning: build failed, waiting for other jobs to finish...

crash report

Bug Report

Check the contributing guide

Description

"name" = "avail-light"
"operating_system" = "Mac OS 14.2.1 [64-bit]"
"crate_version" = "1.7.4"
"explanation" = """
Panic occurred in file '/Users/runner/work/avail-light/avail-light/src/network/rpc/event_loop.rs' at line 221
"""
"cause" = "RPC Subscription stream should be infinite"
"method" = "Panic"
"backtrace" = """

0: 0x105b8333a - core::option::expect_failed::h7a284305b411661c
1: 0x104ad5961 - avail_light::network::rpc::event_loop::EventLoop::run::{{closure}}::ha8c3e925446965df
2: 0x104a70db5 - <avail_light::shutdown::with_cancel::WithCancel<T,F> as core::future::future::Future>::poll::he9693eee5c7beed4
3: 0x104bca85c - tokio::runtime::task::raw::poll::hcd8925c5b5fa4e2f
4: 0x1054d7a6d - tokio::runtime::scheduler::multi_thread::worker::Context::run_task::hdb1283b117571b63
5: 0x1054dbc1e - tokio::runtime::task::raw::poll::hc841fc0736276968
6: 0x1054cd35c - std::sys_common::backtrace::__rust_begin_short_backtrace::hedcc2edb69b5d537
7: 0x1054cd11c - core::ops::function::FnOnce::call_once{{vtable.shim}}::he1cf7c74741df83e
8: 0x105497629 - std::sys::unix::thread::Thread::new::thread_start::h38ac7fbd1086ae35
9: 0x7ff81b65f202 - __pthread_start"""

Steps to Reproduce

Expected Behavior

Actual Behavior

Additional Information

Fix broken links

#349

(I'm not a bot <3)

bug: Failed to decode block announce

Bug Report

Check the contributing guide

Description

2024-03-04 06:51:02 Failed to decode block announce
2024-03-04 06:51:02 Failed to decode block announce
2024-03-04 06:51:02 Failed to decode block announce
2024-03-04 06:51:02 Failed to decode block announce
2024-03-04 06:51:03 ⚙️ Syncing 0.0 bps, target=#439880 (7 peers), best: #14656 (0x3216…668e), finalized #14336 (0x4593…ff31), ⬇ 509.7kiB/s ⬆ 18.9kiB/s
2024-03-04 06:51:08 ⚙️ Syncing 0.0 bps, target=#439880 (8 peers), best: #14656 (0x3216…668e), finalized #14336 (0x4593…ff31), ⬇ 313.8kiB/s ⬆ 11.4kiB/s
2024-03-04 06:51:13 ⚙️ Syncing 0.0 bps, target=#439880 (8 peers), best: #14656 (0x3216…668e), finalized #14336 (0x4593…ff31), ⬇ 446.8kiB/s ⬆ 10.4kiB/s

Steps to Reproduce

Expected Behavior

Actual Behavior

Additional Information

feat: Documentation update

Feature Request

Please update information on what ports are required.

Summary

Challenge started with different ports, started with 30333, then 37000. Http port 7000 and wss on 433.

Detailed Description

It would be nice that required ports are specified in documentation.

Use Cases

Notifiy user when runing light client behind firewall what ports to forward.

Alternative Solutions

None. Update documentation.

Additional Context

Please keep documentation up to date.

bug: Cannot create a runtime error=Other("runtime requires function imports which are not present on the host: 'env:ext_hosted_header_builder_build_version_2'")

Bug Report

I have successfully created and started my node but in my logs i see these errors and can not fix. WHat is the reason for this error

2024-02-05 23:20:29 Cannot create a runtime error=Other("runtime requires function imports which are not present on the host: 'env:ext_hosted_header_builder_build_version_2'")
Feb 05 23:20:29 ip-172-31-41-155 data-avail[416720]: Error: Service(Client(RuntimeApiError(Application(VersionInvalid("Other error happened while constructing the runtime: runtime requires function imports which are not present on the host: 'env:ext_hosted_header_builder_build_version_2'")))))
Feb 05 23:20:29 ip-172-31-41-155 systemd[1]: availd.service: Main process exited, code=exited, status=1/FAILURE

feat: add some new features please

Feature Request

Check the contributing guide

Summary

Detailed Description

Use Cases

Alternative Solutions

Additional Context

feat:

Feature Request

Check the contributing guide

Summary

Detailed Description

Use Cases

Alternative Solutions

Additional Context

"signature mismatch" when running docker container.

What did I do

I ran the docker container after adding +x permissions to entrypoint.sh in the dockerfile :
docker build -t avail .
docker run --rm avail

What did I expect

I expected the node to start running and attempt to connect to the network.

What happened instead

This error popped up during node startup
Error: Service(Client(VersionInvalid("RuntimeConstruction(Other(\"signature mismatch for: env:ext_hosted_header_builder_build_version_1\"))")))

I am not sure what this means.

bug: Transaction Validation Failure: RuntimeCall::TechnicalCommittee Decoding Error

Bug Report

Description

When attempting to perform a transaction using balances.transferKeepAlive, the node encounters a runtime panic with the error: "Bad input data provided to validate_transaction: Could not decode RuntimeCall::TechnicalCommittee.0".

Steps to Reproduce

1. Start the Avail node with the following command
   ExecStart=/root/avail/avail-node --base-path /root/avail/node-data --chain turing --rpc-external --rpc-port 9944 --rpc-cors=all --name VNBnode --rpc-methods Unsafe --pruning archive --rpc-max-connections 300 --unsafe-da-sync --out-peers 100 --in-peers 100
2. Use Polkadot.js or other compatible tools to send a balances.transferKeepAlive transaction.
   https://polkadot.js.org/apps/?rpc=wss://rpc-avail.vnbnode.com#/accounts
3. Observe the node logs for the runtime panic error.

Expected Behavior

The transaction should be processed successfully without causing a runtime panic.

Actual Behavior

The node panics with the following error message:
Thread 'tokio-runtime-worker' panicked at 'Bad input data provided to query_info: Could not decode RuntimeCall::TechnicalCommittee.0:
Could not decode Call, variant doesn't exist
', runtime/src/apis.rs:78
This is a bug. Please report it at:
https://github.com/availproject/avail/issues/new/choose
2024-05-16 15:45:19 Evicting failed runtime instance error=Runtime panicked: Bad input data provided to query_info: Could not decode RuntimeCall::TechnicalCommittee.0:
Could not decode Call, variant doesn't exist

Additional Information

Additional Information
Node Version: v2.2.2.0-rc1
Operating System: Ubuntu 22.04
Runtime Information:
specName: avail
implName: avail
authoringVersion: 12
specVersion: 31
implVersion: 0
transactionVersion: 1
stateVersion: 1
Command Used: /root/avail/node-data --chain turing --rpc-external --rpc-port 9944 --rpc-cors=all --name VNBnode --rpc-methods Unsafe --pruning archive --rpc-max-connections 300 --unsafe-da-sync --out-peers 100 --in-peers 100

Additional Context
I used https://temp-explorer.avail.so/?rpc=wss://rpc-avail.vnbnode.com#/accounts and it worked. However, using Polkadot.js.org resulted in the error.

Log excerpt:
May 16 15:45:19 ubuntu-4gb-hil-1 avail-node[351814]: Thread 'tokio-runtime-worker' panicked at 'Bad input data provided to query_info: Could not decode RuntimeCall::TechnicalCommittee.0:
May 16 15:45:19 ubuntu-4gb-hil-1 avail-node[351814]: Could not decode Call, variant doesn't exist
May 16 15:45:19 ubuntu-4gb-hil-1 avail-node[351814]: ', runtime/src/apis.rs:78
May 16 15:45:19 ubuntu-4gb-hil-1 avail-node[351814]: This is a bug. Please report it at:
May 16 15:45:19 ubuntu-4gb-hil-1 avail-node[351814]: https://github.com/availproject/avail/issues/new/choose
May 16 15:45:19 ubuntu-4gb-hil-1 avail-node[351814]: 2024-05-16 15:45:19 Evicting failed runtime instance error=Runtime panicked: Bad input data provided to query_info: Could not decode RuntimeCall::TechnicalCommittee.0:
May 16 15:45:19 ubuntu-4gb-hil-1 avail-node[351814]: Could not decode Call, variant doesn't exist

bug: Please tell me how to solve this bug

2024-03-014 06:51:02 Failed to decode block announce
2024-03-14 06:51:02 Failed to decode block announce
2024-03-14 06:51:02 Failed to decode block announce
2024-03-14 06:51:02 Failed to decode block announce
2024-03-14 06:51:03 ⚙️ Syncing 0.0 bps, target=#979852 (7 peers), best: #14656 (0x8054…668e), finalized #14336 (0x9527…ff31), ⬇ 509.7kiB/s ⬆ 22.9kiB/s
2024-03-14 06:51:08 ⚙️ Syncing 0.0 bps, target=#979852 (8 peers), best: #14656 (0x8054…668e), finalized #14336 (0x9527…ff31), ⬇ 313.8kiB/s ⬆ 15.4kiB/s
2024-03-14 06:51:13 ⚙️ Syncing 0.0 bps, target=#979852 (8 peers), best: #14656 (0x8054…668e), finalized #14336 (0x9527…ff31), ⬇ 446.8kiB/s ⬆ 11.4kiB/s