Thread by @hus_qy

So it's finally time for part 2 of the update, in which I will explain how the reactive package allows us to merge metadata and logic to eliminate the problems discussed in the previous thread by getting rid of our 'external propagation logic'.

I will split the thread into several different segments to make it easier to associate the attached pictures with their respective text.

Since we plan to create blocks that act like 'interacting cells', we first need to create a mechanism that allows them to communicate.

For this purpose, we mimic the function of a 'receptor', which is a chemical structure on the membrane of cells that can bind to so-called 'ligands' to release a 'messenger'.

This is equivalent to a 'variable' that notifies others about the fact that it has been set, and we translate this into a component with the following interface:

- Set: Sets the value of the variable to a known value.

- Compute: Sets the value of the variable to the result of a computation.

- Get: Reads the current value of the variable.

- OnUpdate: Allows subscribers to register a function that is executed when the value changes.

The only task of this component is to hold a value and notify others about value changes, while making sure that all updates happen 'atomically' (all subscribers are notified about the current update before the next one is processed).

Note: We are optionally able to provide ...

... a 'transformation function' to each variable that can determine if and how the stored value should change in response to external stimuli.

This can, for example, be used to define variables with a trap-door condition that prevent updates after they have been set.

This is a relatively simple concept, but it is already powerful enough to implement logic by 'closing the loop' and creating a 'derived variable' that dynamically 'computes' its own value by subscribing to the updates of another variable.

Since the compute method runs within the locking context of the input variable, we can be 100% certain that its value will always correctly reflect the result of the defined transformation (writes become recursively atomic).

Moreover, we can derive variables not only from a ...

... single input but also from two or more by making the compute function subscribe to multiple dependencies.

Looking at this picture, it becomes easy to see the similarities to 'logical gates', and it becomes clear that this allows us to implement any kind of logic.

To simplify a common use case, we have implemented another generalized component that we call a 'counter'.

This counter keeps track of the number of times a dynamic set of input variables fulfill a certain condition.

This can, for example, be used to count the number ...

... of 'solid parents' and is a common way for components to react to their 'environment' (parents and children).

All the building blocks needed to implement our logic are now in place, so let's dive straight into the code of the TipManager that is the first component that is based on these concepts.

The following image represents a portion of the constructor of the TipMetadata where we ...

... initialize and define the variables and their relationships.

The code means quite literally what it says:

- A block is a 'strong tip' if it is a 'strong tip pool member,' and it is not 'strongly referenced by other tips.'

- A block is a 'strong tip pool member' if its tip pool is set to StrongTipPool, and it is neither 'orphaned' ...

...nor 'evicted.'

- A block is 'orphaned' if it is either 'strongly orphaned' or 'weakly orphaned.' and so on ...

Once these variables are set up, no further code is necessary to update their values.

Instead of having to write complex algorithms, we break down the logic into a set of self-contained transformation rules that can be understood in isolation, ignoring everything not immediately relevant for the property.

This massively simplifies the act of writing ...

... technical specifications as we just need to list the properties for the specs.

Each variable is only written at one line in the code, and each intermediate transformation is spelled out as the value of a reactive variable, making the algorithms inspectable.

Should we ...

... find a property with the wrong value, then either the transformation function is wrong, or one of its dependencies has the wrong value.

This allows us to directly navigate to the cause of the problem without running the network with additional debug outputs (implicit ...

... debug outputs exist at every single step of the execution).

Each property has its own mutex, so we reach maximal parallelizability and only wait if the exact same property is written twice (almost never the case and the only time where we want to wait to ensure consistency).

Variables only propagate changes in one direction (from input to output), and circular dependencies cannot be specified as we must always name all inputs when defining a variable (deadlocks become impossible).

The ability to subscribe to any property makes the logic ...

...extremely modular.

If another component wants to do something when a block gets confirmed, it simply subscribes to that variable, without needing to modify any of the existing code (components 'speak the same language').

Changing the logic is easy since everything based ...

... on a property will continue to function even if the definition of the property itself is modified, or, for example, extended by an additional condition.

Problems with erroneous cut-off conditions for the propagation are eliminated, as the propagation will automatically ...

stop once there are no longer changes to the derived variables.

TL;DR: The logic is still complex (a lot of interconnected properties are needed), but the complexity becomes 'manageable'.