Exploring IOTA ICT, Reverse engineering the code Part-2
Diving deeper in this little code base of ICT (IOTA controlled agenT). Trying to figure out why invalid Txs (Transactions) got passed ICT and IRI (IOTA Reference Implementation). Finally discussing what will be the next step in this testing phase of ICT.
The ICT test phase 0.1.1 was stopped by CfB (Come-from-Beyond) phasing it out over a week, requesting the participants to disconnect their ICT clients from the main net and their connected nodes. Over a week you could follow a few testers confirming on DISCORD ICT off that was about a month ago in late July. But the why and what is next will be discussed later.
Now we deep dive into why ICT during test phase 0.1.1 has been over time poorly performing due to invalid transaction which never should have been gossiped by either ICT nor IRI (IOTA Reference Implementation is the node software which holds the distributed tangle).
The source code of the recompiled ict-0.1.1 can be found here (no worries CfB stated that we can expose the code as he is about to publish it… As there are new test phases entered the next version might be significantly changed anyways).
When we started the alpha testing of ICT 0.1.1 there have been phases where my ICT was not active really even though it was connected to at least 4 neighbor IRI nodes. And with active I mean my ICT was almost not gossiping Tx to its neighbors.
In order to analysis the cause we need to understand what the ICT logic stopped sending the UDP (User Datagram Protocol)packets back to its neighbors.
I recognized that the invalid Tx counter was active in every epoch (every minute of processing before ICT is reset and starts over again). Checking the logic the IRI node (ICT is connected to) gets ignored with further sharing its Tx once the invalid Tx has been seen by ICT.
That means depending on the time when the invalid Tx is recognized no Tx are transmitted. In our case there where invalid Tx after already a couple of seconds in an epoch.
