avail's People
Forkers
isabella232 mirairo rebelartists luketchang nomad-xyz pinkdiamond1 defing praetoriansentry drmatrixbmc dooly252 yubing744 guillheu harshil-jani w3f-grants-archive kevjue levdur succinctlabs vuittont60 0xpatatedouce mahofmahof ngocphong90 hook9518 ahrar anil3416 pbazouk yigit2805 fb1603 ankaragucluemre testnetnodes kriss39 hakandemirdev jkoub bardiasani naniteimouri nazanin67 mesahin001 alexitprof mrhoodd xiaolou86 yashchegolev selimkafa nepser84 twisterdw sj6837424 bertidance ozzcanx phalchata greyjkf tringuyen79 saitomopm betul2128 osmanbo mirsadegh62 bruce039 sergeynakul valentina67 lapatylin luomajian11 geoveza 0xbasar nvzqz timucinylmz mariannashi sahebirani mahdikt malinp788 dadidung surfsharky msyafiqr candas19 kebaptest leouarz brixial halilakdag01 oxbau huddavi akare123 0xmbcode janemake buldazer23 czlfg hoanghienvi lucky4angel iamfittz soragxyz pambralyse kaustubhkapatral alipostaci2001 milak47 mutu-s quziannane ratankaliani naji1368 yemreozacmak samtrader3388 sclin222 scliin1 hoda333 khaassorena ursulafeavail's Issues
Stop!
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.
Use polkadart lib to sendTransfer failed, but same logic work on polkadot, kusama, westend. any diff from avail?
posted detail on leonardocustodio/polkadart#444
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
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
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: 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: 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
- Start the node and finish the synchronization
- Stop the node, where the block hight is X
- Remove the existing repo and resynchronize/recompile the sw
- 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.
feat: Custom Mainnet RPC
When Public Mainnet RPC bootstrap nodes update? I can't run mainnet rpc since there no any bootstrap nodes on the json file.
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
- 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 - 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 - 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: 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
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:"
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...
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
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
feat: add some new features please
Feature Request
Check the contributing guide
Summary
Detailed Description
Use Cases
Alternative Solutions
Additional Context
Error importing block xxx: block has an unknown parent
Bug Report
Description
![image](https://private-user-images.githubusercontent.com/7995985/301708555-e973111d-8e33-4fbf-8212-4e36942fc56f.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjMzNjE0ODQsIm5iZiI6MTcyMzM2MTE4NCwicGF0aCI6Ii83OTk1OTg1LzMwMTcwODU1NS1lOTczMTExZC04ZTMzLTRmYmYtODIxMi00ZTM2OTQyZmM1NmYucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgxMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MTFUMDcyNjI0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OTU0N2M4ZGU4MTllMzYxYjgxMGFkYTk4NTg5YmU2Y2FiMDU2NTNiODAyZGYzNzc2OTMwMmExMjdhZjYzZTFiNCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ._OHGIXdWZf4bzr_VmWAlnzaxqM-fMWuRXLhV6jTrXOU)
Steps to Reproduce
I start a full node on aliyun, system
- run using binary v1.09
- start command
./data-avail -d ./data --chain goldberg --name RollTheWordLabs
- 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
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'.
Steps to Reproduce
- I setup node & sync data full db: https://github.com/availproject/avail/releases/tag/v1.10.0.0
- Exce:
/root/avail/target/release/data-avail -d /root/avail/output --chain goldberg --name LD-Fullnode --unsafe-da-sync
- Service start normal and loop kill process ~ 12m - 15m / once
Expected Behavior
Actual Behavior
Additional Information
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
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.
feat: faucet problem from subwallet
Feature Request
Check the contributing guide
Summary
Detailed Description
Use Cases
Alternative Solutions
Additional Context
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.
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
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
- 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
bug: Avail Goldberg Testnet website page https://goldberg.avail.tools lacks a lot
Node
avail substrate api sidecar
{"code":500,"message":"createType(SignedBlock):: Struct: failed on block: {"header":"Header","extrinsics":"Vec"}:: Struct: failed on extrinsics: Vec:: createType(ExtrinsicV4):: createType(Call):: findMetaCall: Unable to find Call with index [144, 29]/[144,29]","stack":"Error: createType(SignedBlock):: Struct: failed on block: {"header":"Header","extrinsics":"Vec"}:: Struct: failed on extrinsics: Vec:: createType(ExtrinsicV4):: createType(Call):: findMetaCall: Unable to find Call with index [144, 29]/[144,29]\n at createTypeUnsafe (/usr/src/app/node_modules/@polkadot/types-create/cjs/create/type.js:54:22)\n at TypeRegistry.createTypeUnsafe (/usr/src/app/node_modules/@polkadot/types/cjs/create/registry.js:230:52)\n at RpcCore._formatOutput (/usr/src/app/node_modules/@polkadot/rpc-core/cjs/bundle.js:331:25)\n at RpcCore._formatResult (/usr/src/app/node_modules/@polkadot/rpc-core/cjs/bundle.js:169:20)\n at callWithRegistry (/usr/src/app/node_modules/@polkadot/rpc-core/cjs/bundle.js:190:25)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)","level":"error"}root@testWallet:/data/avail#
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.
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
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: Thread 'tokio-runtime-worker' panicked at 'Bad input data provided to validate_transaction
Version: 2.1.5-ec9b97c3b9c
0: sp_panic_handler::set::{{closure}}
1: <alloc::boxed::Box<F,A> as core::ops::function::Fn>::call
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2021:9
std::panicking::rust_panic_with_hook
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:783:13
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:657:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:170:18
4: rust_begin_unwind
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
5: core::panicking::panic_fmt
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
6: da_runtime::apis::api::dispatch
7: sp_externalities::scope_limited::ext::using
8: sc_executor::executor::WasmExecutor::with_instance::{{closure}}
9: sc_executor::wasm_runtime::RuntimeCache::with_instance
10: <sc_executor::executor::NativeElseWasmExecutor as sp_core::traits::CodeExecutor>::call
11: sp_state_machine::execution::StateMachine<B,H,Exec>::execute
12: <sc_service::client::client::Client<B,E,Block,RA> as sp_api::CallApiAt>::call_api_at
13: <da_runtime::apis::RuntimeApiImpl<SrApiBlock,RuntimeApiImplCall> as sp_offchain::OffchainWorkerApi<SrApiBlock>>::__runtime_api_internal_call_api_at
14: sp_transaction_pool::runtime_api::TaggedTransactionQueue::validate_transaction
15: tracing::span::Span::in_scope
16: sc_transaction_pool::api::validate_transaction_blocking
17: <sc_transaction_pool::api::FullChainApi<Client,Block> as sc_transaction_pool::graph::pool::ChainApi>::validate_transaction::{{closure}}::{{closure}}
18: sc_transaction_pool::api::spawn_validation_pool_task::{{closure}}
19: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
20: <sc_service::task_manager::prometheus_future::PrometheusFuture as core::future::future::Future>::poll
21: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
22: <tracing_futures::Instrumented as core::future::future::Future>::poll
23: tokio::runtime::context::blocking::BlockingRegionGuard::block_on
24: <tokio::runtime::blocking::task::BlockingTask as core::future::future::Future>::poll
25: tokio::runtime::task::core::Core<T,S>::poll
26: tokio::runtime::task::harness::Harness<T,S>::poll
27: tokio::runtime::blocking::pool::Inner::run
28: std::sys_common::backtrace::__rust_begin_short_backtrace
29: core::ops::function::FnOnce::call_once{{vtable.shim}}
30: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9
<alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9
std::sys::unix::thread::Thread::new::thread_start
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys/unix/thread.rs:108:17
31:
32:
Thread 'tokio-runtime-worker' panicked at 'Bad input data provided to validate_transaction: Could not decode RuntimeCall
, 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
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:
bug: Can't improve priority by adding tip to broadcasting transaction.
Bug Report
Check the contributing guide
Description
I can't improve priority by adding tip to replace a tipped pending transaction.
Steps to Reproduce
- sending a transaction which tip is set to 100, and nonce is set to 1
- monitor the transaction being sent to the txpool with the pendingExtrinsics rpc function.
- set the new transaction' tip to 200, and nonce is set to 1
- Error return by the rpc: Priority is too low: (18446744073709551615 vs 18446744073709551615): The transaction has too low priority to replace another transaction already in the pool.
- if I set the tip to 0 at the first step, I can replace the transaction with a higher tip. In this situation, it works fine.
Expected Behavior
I can improve priority of the transaction in the tx pool by add more tip.
Actual Behavior
Actually, if one add 1 tip to a transaction, its priority is already set to 2^64 - 1, which is the maximum value of uint64.
Additional Information
rpc url: wss://turing-rpc.avail.so/ws
npm package: avail-js-sdk
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
- visit https://goldberg.avail.tools/#/accounts
- choose your account and click on 3 dots, you will see set on-chain identity option click on it
- set your details and save it and brodcast the transction
- 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
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")}
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: Can you recover tokens claimed with ethereum account ?
Asking for help as my eligibility was based on my Github so you can verify but I would like some help as I did claim with wrong account type and the balance is not reflected. @praetoriansentry @QEDK @markopoloparadox @Aphoh @estensen
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
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
- Create wallet on goldberg
- Type in "/deposit:[wallet adress]" on discord channel: Goldberg Faucet
- Deploy rollapp on dymension selecting avail as your data availability layer
- Copy the avail wallet address given to you on your linux environment
- Go to the change address channel on the discord, follow the format given to you by the discord bot and then change wallet address.
- 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: During node synchronization, finalized often stops synchronization
Problem Description
During node synchronization, finalization often stops synchronization and can only be restored by deleting data and resynchronizing.
version:
v2.2.4.1-rc1
log:
2024-07-22 18:19:44 ⏩ Block history, #1 (0 peers), best: #78029 (0xec2e…3b3c), finalized #78026 (0x9ecd…3aeb), ⬇ 5.0kiB/s ⬆ 3.2kiB/s
2024-07-22 18:19:49 ⏩ Block history, #1 (0 peers), best: #78029 (0xec2e…3b3c), finalized #78026 (0x9ecd…3aeb), ⬇ 21.2kiB/s ⬆ 7.2kiB/s
2024-07-22 18:19:54 ⏩ Block history, #1 (0 peers), best: #78029 (0xec2e…3b3c), finalized #78026 (0x9ecd…3aeb), ⬇ 1.3kiB/s ⬆ 1.5kiB/s
2024-07-22 18:19:59 ⏩ Block history, #1 (0 peers), best: #78029 (0xec2e…3b3c), finalized #78026 (0x9ecd…3aeb), ⬇ 2.0kiB/s ⬆ 2.1kiB/s
2024-07-22 18:20:04 ⏩ Block history, #1 (0 peers), best: #78029 (0xec2e…3b3c), finalized #78026 (0x9ecd…3aeb), ⬇ 1.0kiB/s ⬆ 1.2kiB/s
2024-07-22 18:20:09 ⏩ Block history, #1 (0 peers), best: #78029 (0xec2e…3b3c), finalized #78026 (0x9ecd…3aeb), ⬇ 0.8kiB/s ⬆ 1.0kiB/s
2024-07-22 18:20:14 ⏩ Block history, #1 (0 peers), best: #78029 (0xec2e…3b3c), finalized #78026 (0x9ecd…3aeb), ⬇ 1.2kiB/s ⬆ 1.3kiB/s
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.
avail-substrate-api-sidecar
{
"code": 500,
"message": "createType(SignedBlock):: Struct: failed on block: {"header":"Header","extrinsics":"Vec"}:: Struct: failed on extrinsics: Vec:: createType(ExtrinsicV4):: createType(Call):: Call: failed decoding system.killPrefix:: Struct: failed on args: {"prefix":"Bytes","subkeys":"u32"}:: decodeU8aStruct: failed at 0x0300b645fbddf5d8407f771af3e2c082… on prefix (index 1/2): Bytes:: Bytes length 4215649792 exceeds 10485760",
"stack": "Error: createType(SignedBlock):: Struct: failed on block: {"header":"Header","extrinsics":"Vec"}:: Struct: failed on extrinsics: Vec:: createType(ExtrinsicV4):: createType(Call):: Call: failed decoding system.killPrefix:: Struct: failed on args: {"prefix":"Bytes","subkeys":"u32"}:: decodeU8aStruct: failed at 0x0300b645fbddf5d8407f771af3e2c082… on prefix (index 1/2): Bytes:: Bytes length 4215649792 exceeds 10485760\n at createTypeUnsafe (/Users/yaoyf/WorkSpace/Bitmart/code/avail-substrate-api-sidecar/node_modules/@polkadot/types-create/cjs/create/type.js:54:22)\n at TypeRegistry.createTypeUnsafe (/Users/yaoyf/WorkSpace/Bitmart/code/avail-substrate-api-sidecar/node_modules/@polkadot/types/cjs/create/registry.js:230:52)\n at RpcCore._formatOutput (/Users/yaoyf/WorkSpace/Bitmart/code/avail-substrate-api-sidecar/node_modules/@polkadot/rpc-core/cjs/bundle.js:331:25)\n at RpcCore._formatResult (/Users/yaoyf/WorkSpace/Bitmart/code/avail-substrate-api-sidecar/node_modules/@polkadot/rpc-core/cjs/bundle.js:169:20)\n at callWithRegistry (/Users/yaoyf/WorkSpace/Bitmart/code/avail-substrate-api-sidecar/node_modules/@polkadot/rpc-core/cjs/bundle.js:190:25)",
"level": "error"
}
Fix broken links
(I'm not a bot <3)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.