basic-pow node doesn't mine new Blocks?!

[Mhnd3]

Hi everyone, after successfully compiling the node, i started it but it cannot mine new Blocks, it prepared an new Block but never imported it, any idea how to further debug that issue?!

Node Name: basic-pow Node Version: 3.0.0 Commit: commit 53f7ce1b17c7c66ebe04d5a57502d2b6e59fe48a (HEAD -> master, origin/master, origin/HEAD) Author: Joshy Orndorff JoshOrndorff@users.noreply.github.com Date: Wed Apr 14 23:53:04 2021 -0400

Cargo Version: cargo 1.49.0-nightly (dd83ae55c 2020-10-20) Rustup: rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24) OS: Ubuntu 20.04.2 LTS

[Mhnd3]

The same behavior for the older version:

Node Name: basic-pow Node Version: 2.0.0 Commit: commit a8f6e741b1bf6564d5f3713723f2b5f8ed2e9f31 (HEAD) Author: Jimmy Chu jimmy@parity.io Date: Thu Oct 1 16:45:56 2020 +0800

Cargo Version: cargo 1.48.0-nightly (05c611ae3 2020-09-23) Rustup: rustc 1.48.0-nightly (ef663a8a4 2020-09-30) OS: Ubuntu 20.04.2 LTS

[JoshOrndorff]

Hi @Mhnd3 I was surprised to hear this about v3.0, but considering it was recently updated I figured some bugs could have slipped in. I'm even surprised to hear it on 2.0 though. Could you please share a little more context.

• How are you cloning and building the project?
• What command are you using to run the node?
• What is the output of rustup show?

Also could you tell us how familiar with substrate you are in general?

[Mhnd3]

Hi @JoshOrndorff, thanks for the replay

Recipes Version 2.0

$ git clone https://github.com/substrate-developer-hub/recipes.git 
$ cd recipes
$ git checkout a8f6e741b1bf6564d5f3713723f2b5f8ed2e9f31
$ cargo build -p basic-pow --release

** tried all of those command to run the Node:**
$ ./target/release/basic-pow --dev --tmp
$ ./target/release/basic-pow --alice
$ ./target/release/basic-pow

$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/test/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
nightly-2020-04-07-x86_64-unknown-linux-gnu
nightly-2020-10-01-x86_64-unknown-linux-gnu (default)
nightly-2020-10-25-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu

installed targets for active toolchain
--------------------------------------

wasm32-unknown-unknown
x86_64-unknown-linux-gnu

active toolchain
----------------

nightly-2020-10-01-x86_64-unknown-linux-gnu (default)
rustc 1.48.0-nightly (ef663a8a4 2020-09-30)

about my familiarity with substrate, i wrote a couple of pallets to explore the runtime and FRAME framework, now i'm trying to dive in into the client, consensus and networking, i have a good understanding about substrate's components, still in the learning phase though

[JoshOrndorff]

I confirm this is broken. I believe it was first broken in https://github.com/substrate-developer-hub/recipes/pull/385

I guess we will need to add some code similar to https://github.com/kulupu/kulupu/blob/master/src/service.rs#L330-L377 although I haven't fully understood that code yet.

[Mhnd3]

basically we need to compute the seal then submit it using the MiningWorker (worker) submit function, so i added this dump code in "nodes/basic-pow/src/service.rs":

use sha3pow::*;
use std::thread;
use sp_core::H256;
use sha3::{Digest, Sha3_256};
.
.
.
let mut numb = 0;
thread::spawn(move || {
  loop {
    let worker = _worker.clone();
    let metadata = worker.lock().metadata();                
    if let Some(metadata) = metadata {
      let nonce = H256::from_slice(Sha3_256::digest(&[numb]).as_slice());
      let compute = Compute {
        difficulty: metadata.difficulty,
        pre_hash: metadata.pre_hash,
        nonce,
      };
      let seal = compute.compute();
      if hash_meets_difficulty(&seal.work, seal.difficulty) {
        let mut worker = worker.lock();
        worker.submit(seal.encode());
      }
      numb = numb.saturating_add(1u8);
      if numb == 255u8 {
        numb = 0;
      }

      thread::sleep(Duration::new(0, 200_000_000));
    }
  }
});

just after:

task_manager
.spawn_essential_handle()
.spawn_blocking("pow", worker_task);

need to make the "hash_meets_difficulty" function public:

pub fn hash_meets_difficulty(hash: &H256, difficulty: U256) -> bool {
.
.
}

I also reduced the difficulty cuz i'm using currently that "numb: u8" variable as a nonce.

fn difficulty(&self, _parent: B::Hash) -> Result<Self::Difficulty, Error<B>> {
  // Fixed difficulty hardcoded here
  Ok(U256::from(1_0))
}

Aaaaaaand now it's mining new Blocks 🎁✅🙌✨ 🚀🚀🚀

The same dump code worked for the hybrid-consensus recipe 🎁✅🙌✨ 🚀🚀🚀

[JoshOrndorff]

Awesome work @Mhnd3 I guess you found a good place to dive into the consensus layer :)

Could you make a PR with these changes?

[Mhnd3]

Thanks @JoshOrndorff! I'm down into the rabbit hole :) Working on this issue has shown me a lot about the consensus building parts in Substrate. I've created a PR https://github.com/substrate-developer-hub/recipes/pull/433 with those changes, though I wanted to make that code a bit more professional, maybe later i'll refine the code and create a new PR for it.

[nuke-web3]

@Mhnd3 - I hope you do 🥳 !! I would love to see it, and happy to review when it's ready! 😀

[Mhnd3]

@NukeManDan Thanks mate! I want to create a Bitcoin-like POW Algorithm, I'll publish it when it's ready.

[JoshOrndorff]

@Mhnd3 If you're interested in bitcoin, have you seen the UTXO workshop? https://github.com/substrate-developer-hub/utxo-workshop?

It has difficulty adjustment (different algorithm than botcoin) and UTXO tokens in the runtime.

[Mhnd3]

Thanks @JoshOrndorff for the reference! I've saw the youtube videos about the UTXO but didn't pay attention to the difficulty adjustment algorithm there. pretty helpful, though i was planning to create it in the client (delegate it to OCW) not in the runtime to reduce the Block execution time, i'm now wondering if that would make any difference actually?!

[jimmychu0807]

This is closed by #433