Pre-Dev-Update Thread! Yay! :D

Yeah I got excited to see the new membership / consensus system being advanced in rapid pace, but it seems it’s not quite there yet either.

But a lot of steps forward in many areas anyway.

And something new for the next comnet too!


I suspect tonights update will be “steady progress all round” and an announcement on ERC-20 Maid but no major network code updates just yet.

That clicketty-clack noise you hear is ducks getting put in a line for the next week or two.

The ERC-20 news will be most welcome but I am more concerned with the actual code than trading.

Anyhow advance congrats to @Sotros25 et al for all their hard work and diligence.

EDIT: OK I was wrong its happened before and it will happen again…


we now have private data in API!


Technically, it hasn’t been approved yet. But I like how people here are all over Github like hungry chickens. :slight_smile:



Not sure we have it 100% yet, that for sure is a fix needed in the api to have access to them, but we still need to review how we are dealing with the encryption keys in terms of the public APIs (and CLI).


I noticed this yesterday. So did my agogometer.


And then this happened.


Bit late today?
Checks calendar… Yes it IS Thursday, been wrong like that before…
So are the mighty ants still toiling to put together a bumper update for us?
Plenty of GitHub action but maybe its not quite ready for primetime yet…

Agogometer 8.865 (averaged)


Just merged [rubs hands]:


Hell, it’s about time.


Oh yes !!! it was a biggie


Sorry if this is too obvious but… Is the hope here with this latest code, to have a stable testnet… Even with many nodes joining and leaving in quick succession?


The hope is there with every step, but what i suspect you’re asking is, is there an expectation and don’t think anyone can stay that until it’s tested and we see how it works!


This change looks like a precise shot at nasty bug, which was preventing to have stable network.
It is for sure better than making random changes in hopes that bug will go away by itself.
But this change, of course, 1. Will require polishing 2. May be move in wrong direction, producing more problems than solving 3. Even if direction is correct, there may be more work to do to catch other bugs, which have similar effect (bad stability).


I think this hangover should be cleared before any stability can be reached:


Yeh, DKG is still somewhat problematic at times. The current code w/ membership updated is looking much much healthier. It’s been a slog getting there, but the team have done a reaaaallly great job with that.

There are a couple of options w/ handover/dkg that we’re looking at. That’s the next mole to whack! :hammer: :mount_fuji:


I just got a thought. I have never really understood how the section split is supposed to happen. I mean how the SAP can split into two new SAP’s in an asynchronous way, without getting caught up in weird loops, race conditions etc.

But what if section would not split in two, but in three? That way the current SAP (or set of elders) could first “incubate” two new complete sets of elders and when they are ready, just kick them out of the nest and start to hand data / adults over to them. After that, the original section could continue as it was, or maybe disintegrate / relocate etc.

In a way, sections don’t need to split, the just need to give birth to new sections. Or the group of elders don’t need to split, adults maybe do. Or maybe the set of empty adults could be collected ahead of time too?

EDIT: But the risk of getting more than 1/3 of dishonest elders increases with this method, does it?


Or maybe:

This prompted to do a search on BRB, maybe I’ll get to read this interesting article:


I guess I just have to accept that this process of transmitting the authority is just over my head. I can kind of understand, or at least accept, the way how CRDT’s eventually converge to the same result, what the data actually is.

What I don’t understand at all, is the following process:

  1. We have a group of elders, that rule the section. (This is clear).
  2. They choose the next elders based on node age. (Fine)
  3. They form the new sections with these new elders. (And this is where I get in trouble…) It just seems to me, that the possibility that any of these old elders (or new ones as well) might lose their status, drop in node age, in the midst of this process. What happens then?

Like, I can accept that any other knowledge, except node age, can be disagreed until the disagreement is eventually solved. But what if there is a disagreement about the age of a given node? How can a section function during the time it is not agreed on? Or is the age of a specific node always agreed on?


actually @stout77 that’s a precursor draft to the membership that just went in. I’ll tidy that up now :+1:
We are looking at using consensus for the handover step to improve things w/ splits + churn though, so not far off!


Right now we have DKG which does this, with a timeout (as it requires 100% participation). We can see this failing sometimes, for a range of possible reasons. We have some improvements to be made there (how/when to retry)… But we’re also looking at how we might be able to not DKG at all. That’s an early stage idea so just exploring that alongside, but that would really remove the async code / loops / races etc.

I’m not sure more sections is helpful. The idea of a split is that the address space gets more grannular (prefix length increases), so we can’t have a section “remain” so to speak, as it would theoretically be responsible for all its data and the other two “child” sections…