we are having problems to understan the deployment workflow 😊
⠠
17:47
⠠⠵ Lucas!
Λ[
Λntonio Nardella [IF] 04.01.2022 12:28:33
This is something that will depend on different factors..
WASP (the ISCP nodes) run on GoShimmer (devnet)..
If the team launches Shimmer as a 1:1 clone of IOTA on day 0, then it will take some time to implement the fumctionalities needed and Assembly might run their own network first without 'Tangle anchoring'..
17:47
Yes, Shimmer will launch with a Coo, we need Shimmer to also test how to remove the Coo on IOTA, from libraries, wallet, nodes, etc...
⠠
17:48
⠠⠵ Lucas!
But, if shimmer comes from devnet, and devnet is running without a coordinator since some time ago, then shimmer would not allow to test the coordicide
17:49
What am I musunderstanding? :-)
S
18:16
Stefano Della Valle
Devnet is already coo-less, but there is no economy in the network
⠠
18:17
⠠⠵ Lucas!
Yes, the original question was, is it running with the latest iteration of the consensus implemented by Hans?
S
18:17
Stefano Della Valle
So the plan to move from the currentl network (chrysalis) to shimmer will (probably) be implemented gradually
18:18
This is the best way to avoid attacks, because even if in the devnet the tech is already running since a while, no one has never attempted to really attack
Basically the real difference i guess will be on the wallet side, because today a tx is confirmed only after the coo reference it with a milestone. So, one possible first step could be to run the 2.0 tech keeping the coo to grant the current confirmation method to the wallet
18:22
The most critical things to test are the anti spam and dust attack prevention. Tested these two features it will be safe to change the wallet behavior and then remove the coo
18:24
Of course these are my personal ideas
⠠
18:26
⠠⠵ Lucas!
I thought the version in shimmer did not break metastability in all cases. I was wondering whether current stability (less blackouts) had to do with the consensus. Bit I guess this is more directly related to Hans work
Metastability enter in the game only if there are two conflicting txs. In that case the vote on tangle can solve the conflict but if the double spends is the result of a coordinate attack, then the attacker can manage to keep the parity on the vote. If this happens the the Fast Probabilistic Consensus is activated and this protocol is proved to be safe from Metastability risk due too a random number of votes round.
18:31
This is the IOTA 2.0 consensus
S
18:50
Stefano Della Valle
in which case do you think the metastability will become a problem?
⠠
18:59
⠠⠵ Lucas!
I believed, after reading Hans articles, that FPC would not be even necessary anymore after introducing voting, and that it could be trimmed from current devnet code.
Well, I'm not sure ... I guess there will be some sort of timer in order to decide when to trigger FPC, or simple a retries counter. I'm just speculating with the possible consecuences of having this double mechanism and, specially, on the effect of the "delays". Just brainstorming without much base 😅 I don't want to steal your time, I better should stop procrastinating and study the actual code and behaviour!
S
19:04
Stefano Della Valle
That was an interesting hypothesis, but need to be verified and the Shimmer is exactly the place to test it. Anyway, the FPC is activated after the Vote on Tangle arrive to the parity for a while. So if this case will never happen, then the FPC will never be required. I guess it is all matter of how much node will be really active on the network. More node will be active and harder will become to manage a coordinate attack able to create a double spend.
19:05
yes, both vote on tangle and FPC introduce a delay in the tx confirmation, but only on that tx ... all the other part of the network activity are not impacted