Home
Welcome to the GoShimmer wiki!
GoShimmer is a prototype node software exploring the implementation of the Coordicide project. This wiki helps the reader to understand the basic concepts and ideas behind the Coordicide and how its modules are implemented in GoShimmer.
Due to the prototypical nature of the project, things written today may not be reflecting how things are tomorrow. We seek to keep the wiki as updated as possible, since it is also used as guide for our team. If you find any inconsistencies, feel free to contact us on Discord or better, create an issue on this repository.
GoShimmer is a research and engineering project from the IOTA Foundation seeking to evaluate Coordicide concepts by implementing them in a node software.
Since non conflicting transactions aren't even voted up on, they materialize after 2x the average network delay parameter we set. This means that a transaction usually confirms within a time boundary of ~10 seconds.
You can access the global analysis dashboard here showcasing the network graph and active ongoing votes on conflicts.
The transactions per second metric is irrelevant for the current development state of GoShimmer. We are evaluating components from Coordicide and aren't currently interested in squeezing out every little ounce of performance. Meaning, we value simplicity over optimization since the primary goal is to evaluate Coordicide components. Even if we would put out a TPS number, it would simply not reflect an actual metric in a finished production ready node software.
The Coordicide lays out concepts for spam prevention through the means of rate control and such. However, in the current version, GoShimmer relies on PoW to prevent over saturation of the network. Usually doing the PoW for a message will take a couple of seconds on commodity hardware.
If you have funds and are simultaneously issuing transactions spending those, then with high certainty your transactions are going to be rejected by the network. This goes even so far, that your funds will be blocked indefinitely (this might change in the future). If you issue a transaction, await the average network delay and then issue the double spend, then the first issued transaction should usually become confirmed and the 2nd one rejected.
We are mainly interested in individuals helping us out who have a strong IT background, since we simply lack time to help people with things like setting up their nodes, fixing their NAT configs, teaching them how to use Linux and so on. People interested in trying out the bleeding edge of IOTA development and providing meaningful feedback or problem reporting (in form of issues) are welcome. Again, our primary focus is on testing out Coordicide components rather than giving people of any knowledge-level the easiest way to operate a node.
