Talk:Set up a Cardano ITN staking pool

From Organic Design wiki

Bootstrapping

Try this if you have a reasonably up to date db:

max_bootstrap_attempts: 0

Monitoring

Quote.pngI 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

Quote.pngIn 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

Quote.pngPart 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

Quote.pngA 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

Quote.pngTheir "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

Quote.pngPassive 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)

Quote.pngWell 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.

Poldercast nearest peers problem and 1PCT

Michael Fazio found an interesting bug in Poldercast which he raised in issue#15 whereby peers are not connecting to their nearest neighbours but rather much more likely to connect to those with IDs starting with more zeros. It then turns out that the 1PCT pools seemed to know about this and took advantage of it by taking all the 00...00131313xxxx IDs for their nodes, which you can see many of here!

Trying out Michael Fazio's 0.8.9-stable fork

Michael Fazio has addressed some bugs that aim to keep the cpu usage down among other things and released these changes in his own fork of Jormungandr.

After trying it out for a while I found that the CPU usage is definitely way better and the node should no longer need regular restarts. I've had very bad luck minting blocks though, by losing competitive forks and being on adversarial forks during my leader slot. This might just be bad luck so I'll leave it running for a few epoch's to see.

Jormungandr-versions-cpu.jpg