Reporting bug in BoB

I would like to report a bug in BoB: calling dfx canister call 6lnhz-oaaaa-aaaas-aabkq-cai get_current_block_status --update --ic yielded

(
  record {
    burned_cyles = 366_423_888_869_521 : nat64;
    active_miners = 171 : nat64;
  },
)

and soon afterwards the mined block retrieved via dfx canister call 6lnhz-oaaaa-aaaas-aabkq-cai get_latest_blocks --update --ic was

    record {
      to = principal "5cd6g-sncvx-lfobl-xyuhz-ubkbi-x3tyu-qmxof-6zxo7-3xehm-h7i4j-lqe";
      miner = opt principal "7qvvt-eaaaa-aaaas-aj7ua-cai";
      miner_cycles_burned = opt (67_222_222_222_080 : nat64);
      total_cycles_burned = opt (337_273_888_869_522 : nat64);
      timestamp = 1_735_131_421_517_753_586 : nat64;
      rewards = 30_000_000_000 : nat64;
      miner_count = opt (172 : nat64);
    };

Given that both calls were (replicated) update calls with the latter update call submitted after receiving the response of the former one, they were executed in this order. Consequently, the number of burnt cycles is not supposed to decrease. (The difference in miner count is due to the dedicated pool miner whose contribution is burnt just before mining a block and thus not a accounted for in the pending block stats.)

The above behavior is easily reproducible by fetching the pending block stats shortly before a block is mined.

Given the published source code, I could not figure out a reason for this behavior. Hence, I would like to ask BoB developers if they could please publish the latest deployed code and/or look into the issue themselves.

7 Likes

Could you @bobdotfun take a look?

1 Like

The issue has been resolved—thank you for pointing it out.

I kindly request that the BOB developers share the latest deployed code or investigate the matter further.

We’re actively working on achieving reproducible builds. Exciting updates are on the horizon—stay tuned!

3 Likes

We’re implementing reproducible builds aligned with the guidance at this link. Any insights or contributions to our progress would be invaluable: GitHub - bob-robert-ai/bob.

1 Like

Great to hear! I could successfully reproduce the current hash a82cd6da042c6b6839ee52692e20aedb85693febaa28977354824dc1ba922ae1!

I’d recommend including the candid file using

ic-wasm target/wasm32-unknown-unknown/release/bob-minter-v2.wasm -o target/wasm32-unknown-unknown/release/bob-minter-v2.wasm metadata candid:service -f minter-v2/bob.did -v public

for the minter and analogously for the miner.

I’d also point out that the ledger is from git commit:

$ dfx canister metadata 7pail-xaaaa-aaaas-aabmq-cai git_commit_id --ic
2190613d3b5bcd9b74c382b22d151580b8ac271a

and is available under this link: https://download.dfinity.systems/ic/2190613d3b5bcd9b74c382b22d151580b8ac271a/canisters/ic-icrc1-ledger.wasm.gz

1 Like

The canister has been upgraded based on your feedback. Please verify that you can now reproduce the build:

Once the ledger and minter builds are confirmed reproducible, they will transition to NNS control.

1 Like

To speed up the build, I’d further recommend downloading ic-wasm as a binary from its release page instead of building it from sources.

Moreover, I’d add a line

ic-wasm target/wasm32-unknown-unknown/release/bob_miner_v2.wasm -o target/wasm32-unknown-unknown/release/bob_miner_v2.wasm metadata candid:service -f miner-v2/miner.did -v public

after building the miner and before building the minter.

Last but not least, I’d recommend adding a unit test (with a corresponding GitHub action to run it on CI) for the did file:

#[cfg(test)]
mod tests {
    use super::*;
    use candid_parser::utils::{service_equal, CandidSource};

    #[test]
    fn test_implemented_interface_matches_declared_interface_exactly() {
        let declared_interface = include_str!("../miner.did");
        let declared_interface = CandidSource::Text(declared_interface);

        // The line below generates did types and service definition from the
        // methods annotated with Rust CDK macros above. The definition is then
        // obtained with `__export_service()`.
        candid::export_service!();
        let implemented_interface_str = __export_service();
        let implemented_interface = CandidSource::Text(&implemented_interface_str);

        let result = service_equal(declared_interface, implemented_interface);
        assert!(result.is_ok(), "{:?}\n\n", result.unwrap_err());
    }
}

using candid_parser = "0.2.0-beta.4" and analogously for the minter.

Did you bring this up with the NNS community on the forum? I wouldn’t recommend making such a decision without a community discussion.

1 Like

I’ve implemented my above recommendations in this PR.

Can you help me, I see my miner doesn’t have a tube method, even though my TC is live and active

NNS controllers like his are problematic