Open joske opened 2 weeks ago
raychu86
commented
2 weeks ago Good thing is that it doesn't seem to be a fork, so I'm less concerned about a consensus issue.
@joske @ljedrz snarkOS https://github.com/AleoNet/snarkOS/commit/c4d725f923f92bad8d6aab0fa15824867efbcc0c is an older version that uses a lower minimum coinbase/proof target. Is there any chance that you are trying to reload the ledger with a newer version of snarkOS that has the updated minimum values?
joske
commented
2 weeks ago @raychu86 No, we tried with the exact snarkVM version 6d64025 that snarkOS c4d725f points to. To be sure, I'll try again.
raychu86
commented
2 weeks ago @joske The failing check is this:
pub fn is_valid(&self) -> bool {
match self.height == 0u32 {
true => self.is_genesis(),
false => {
// Ensure the network ID is correct.
self.network == N::ID
// Ensure the round is nonzero.
&& self.round != 0u64
// Ensure the height is nonzero.
&& self.height != 0u32
// Ensure the round is at least as large as the height.
&& self.round >= self.height as u64
// Ensure the coinbase target is at or above the minimum.
&& self.coinbase_target >= N::GENESIS_COINBASE_TARGET
// Ensure the proof target is at or above the minimum.
&& self.proof_target >= N::GENESIS_PROOF_TARGET
// Ensure the coinbase target is larger than the proof target.
&& self.coinbase_target > self.proof_target
// Ensure the last coinbase target is at or above the minimum.
&& self.last_coinbase_target >= N::GENESIS_COINBASE_TARGET
// Ensure the last coinbase timestamp is after the genesis timestamp.
&& self.last_coinbase_timestamp >= N::GENESIS_TIMESTAMP
// Ensure the timestamp in the block is after the genesis timestamp.
&& self.timestamp > N::GENESIS_TIMESTAMP
}
}From what I can see, all the attributes are correct. The only one I can't determine is self.network == N::ID. This will fail if you spin up the network without --network 0
joske
commented
2 weeks ago The nodes are started with
/root/.cargo/bin/snarkos start --metrics --nodisplay --bft 0.0.0.0:5000 --rest 0.0.0.0:3030 --peers 18.220.230.167:4130,18.222.48.7:4130,18.188.187.22:4130 --validators 18.227.0.57:5000,3.145.37.212:5000,18.222.184.97:5000,3.139.97.186:5000,3.138.134.228:5000 --verbosity 1 --dev 4 --dev-num-validators 5 --validator --rest-rps 10 --no-dev-txs
elderhammer
commented
2 weeks ago Did you use snarkVM's test feature when compiling the snarkOS executable?
joske
commented
2 weeks ago Don't know, it was spun up by @onetrickwolf using their ansible scripts (I think)
onetrickwolf
commented
2 weeks ago We just build with the 'build_ubuntu.sh' script found in snarkOS.
raychu86
commented
2 weeks ago Can you try again with cargo run --release or try to re-install snarkOS rev https://github.com/AleoNet/snarkOS/commit/c4d725f923f92bad8d6aab0fa15824867efbcc0c using cargo install --path .? Just to ensure that it's not an issue with the current binary?
And an even lower level approach is to see which line/check is causing the Invalid block metadata failure.
joske
commented
2 weeks ago This isonet is gone. Restarted on commit 878624d6ccab6dfeb52f69ce54ee885464cdf7d8.
🐛 Bug Report
A new dev network was spun up on AWS, with only execution transactions. Load started at about 18:45 UTC on July 3rd 2024. The goal was to check RSS growth when only execution transactions (no deployments) are present. A load of about 11 TPS was observed.
At about 12:15 on 6th of July 2024, consensus came to a halt due to a rounds mismatch. Block
288032was the last block produced.Log excerpt from node 0:
Log excerpt from node 4:
We downloaded the ledger and tried to analyze it, but it fails with the following error:
We tracked this to
Restarting the nodes didn't resume consensus.
Steps to Reproduce
not know how to reproduce
Expected Behavior
Consensus doesn't stop
Your Environment