IPs with multiple connections
Some people have been saying that nodes with multiple connections are causing a lot of trouble and are blocking them with the following script. You need to install ufw and enable it, you can see the current rules with the status command, and clear them all with reset.
#!/bin/bash
netstat -tupan | grep jor | grep EST | awk '{print $5}' > tmp
IPS=$(sort tmp | uniq -d | cut -d ':' -f1)
for IP in $IPS; do
ufw deny from $IP to any
ufw deny out from any to $IP
done
- Apparently only blocking 5 or more connections is good
Slots and blocks
One thing I don't understand is that if there's 43,200 slots per epoch, then shouldn't a pool with 1% of the total stake be winning an average of 432 slots per epoch? In reality pools with around 1% stake seem to be winning about 43 slots... I asked the community here in this redit thread. The average time between new slots as shown by the pool API seems to be about 30s which I found by parsing the sentinel log with this perl snippet:
open LOG, '<', 'sentinel.log';
my $n = 0;
my $t = 0;
while(<LOG>) {
if( /^\[\d+\/(\d+)\] Epoch:/ ) {
$n++;
$t += $1;
print "$1, " . ($t/$n) . "\n";
}
}
close LOG;
- Answered: Being elected as a slot winner gives you the right to create a block, but new blocks are required far less frequently than every slot. The reward is for creating a block, not for simply being elected the slot winner. --Nad (talk) 17:16, 31 December 2019 (UTC)
Monitoring
| I see, well, I don't restart based on blockheight, but rather on either one of these messages appearing in the log (egrep): WARN request timed out or failed unexpectedly\, error\: Error\(Elapsed\)\, request\: GetHeadersRange\, task or WARN blockchain is not moving up |
— STR8
|
| In my case, when i get to 50% (i.e. 100% for 1 core) my node falls out of sync. Then my restart scripts kick in. So the process is killed and we start again. |
— Michael Fazio
|
Optimisations
| Part of the reason bootstrapping takes forever is because it's reading the sqlite file from disk
mkdir ram_storage && mount -t tmps -o size=1G tmpfs ./ram_storage && cp storage/* ram_storage
|
— Cardano Bull
|
Tech details
| A little bit of extra context about the stats I added to 0.8.7
- peerAvailableCnt: "52357"
- peerQuarantinedCnt: "1966"
- peerUnreachableCnt: "1083"
Peer Available Count: Peers you have discovered via Gossip that have a public address and you have previously connect to successfully or are yet to try.
Peer Quarantined Count: Peers you have put in the naughty list because (1) you tried to establish a connection and couldn't (2) You re-established a connection with them but their node public ID had changed for some reason.
Peer Unreachable Count: Nodes that you have found through gossip but are not advertising a public ID and hence cannot be connected to. |
— Michael Fazio
|
| Their "luck" may change soon. Because word on the street is that Jormungandr is going to change the way it bootstraps soon. So that the initial gossip nodes are NOT the same as the bootstrap peers. Which will take the bulk of the load off the IOHK peers and make your entry into the p2p network more random. |
— Michael Fazio
|
| Passive node started with a --secret parameter but with leader id subsequently deleted so currently not actively producing blocks, but is on stand-by i.e. so can produce blocks if i re-install the leader. Also I think public_id is only needed if you're trying to set up some local poldercast ring i.e. trying to get your own nodes talking to your other nodes, otherwise it doesn't help with anything and probably results in you being quarantined for longer if your node does regular restarts |
— Homer J (AAA Stake Pool)
|
| Well ideally you should just add the all tx fees to the pot then take out treasury tax-10%. that should leave you with total rewards. Then you would distribute max 1% for each saturated pool. The remainder is what should be distributed to non-saturated pools . At least that’s how I would do it if I had the data |
— SKY pool
|
Hashes from forks remain in storage
One person in the channel asked if we could see the block he created, I checked the hash 30c519 and it existed, others couldn't see it. I extracted his pool ID from the block data and then listed all the blocks created in that epoch by the pool, and sure enough that 30c519 didn't show up:
$ block=`./jcli rest v0 block 30c519c55c12e6ed55639bde6d3b3e97e947b7f40aeeb15e7d5ae4b3ac164450 get --host "http://127.0.0.1:3100/api"`
$ tools/crypto/cardano-pool-blocks-list.pl --pool=`echo ${block:168:64}` --explorer=http://localhost:3100/explorer/graphql --epoch=49
Total blocks created: 844
1 Date:49.10247 Height:151324 Hash:3c2dd31f5267c513f103a834c65e07d0a92876d800ce31b285ee1a8841a2b57f
2 Date:49.9987 Height:151310 Hash:c5eaa1519376fef0a408c1c1039b70a7c803defe9e17a082564fcc272b4b5219
3 Date:49.9010 Height:151241 Hash:6e8c1718cf794c26a4075a93c6a5568b3910b5806f09f7e7fd74fb86a74adf3f
4 Date:49.4343 Height:150860 Hash:20991eac6975e6578d72558b426f4febef1ab2a5fb7a2fb5e893364cbcc7723e
5 Date:49.4113 Height:150838 Hash:2115cf40c80605048d12f9fc2382f3af381d0a7bea9015e1e216a470bc7b9742
6 Date:49.2184 Height:150673 Hash:55b115c90f6067d217cfacda5192bc2c21f9d33753996c17252a06c8b6804674
7 Date:49.1551 Height:150604 Hash:5635722da0968e2d74991ac478dbe16fbe46fee7ddb487a82159ede44c13af9a
8 Date:49.1512 Height:150598 Hash:af825b898c8436b793c0a29b9e2937452d256615bfb441c910ca112e82ee7db0
9 Date:49.1231 Height:150580 Hash:4171ae1ba5a7aef433d4c4f61a63e31a95a6336769255795b259eb4e917ce922
10 Date:49.571 Height:150535 Hash:0fcb0937e0223221d161bb2fb8275305db157dd6c21e636af7d938b75530246c
This is interesting as it shows that a node continues to have knowledge of hashes even after that are discarded from the chain after a fork is resolved. What's more interesting is that even after a node restart, 30c519 was still queryable which means that their held in the storage. This means that everyone's storage is unique and holds information about the forks it's experienced, and also that storage can be slimmed down a lot.