... is a section that explains how they work without actually describing what they are.
Apparently it has to do with keeping track of time and ordering of the events in distributed systems. At least what it looks like from the intro of the paper the article is rehashing.
"A vector clock is a data structure used for determining the partial ordering of events in a distributed system and detecting causality violations."
-- https://en.wikipedia.org/wiki/Vector_clock
with a modification: "In 2008, Almeida et al. introduced Interval Tree Clocks. This mechanism generalizes Vector Clocks and allows operation in dynamic environments when the identities and number of processes in the computation is not known in advance."
Basically, if you have a distributed logical system (i.e. a system that uses more than processor, possibly processors separated by large distances and in noisy environments), it is very difficult to synchronize all of the clocks in each processor, such that if there is a fault, you will be able to use timestamps to localize the exact root cause of that fault. The solution is simply a clock that increments based on logical events within the system rather than a global real world clock. This is very much the same way time appears to work in our physical universe (i.e. time emerges from cause & effect interactions at the quantum scale as entropy increases - if those events slow down, so does the percieved incrementing of time).
I've implemented interval tree clocks, they're not the most accessible idea. Condensed rationale:
Logical clocks are used to keep track of the ordering of events in distributed systems, for example updates in a multi-master database. With a single node you can just stamp each update with a sequence number from a counter. With multiple nodes a single counter doesn't work, for starters because of the race condition. You can instead use an array of sequence numbers, with one slot updated by each node and one counter per node. These vectors then are perfectly ordered locally and globally mostly ordered. That's the idea behind "vector clocks".
Vector clocks don't by themselves handle the case of adding and removing nodes. Interval Tree Clocks do the same job as vector clocks but allow adding + removing nodes without relying on some out of band process. The price is complexity.
There's a whole lot of published work but you can get most of the idea from Wikipedia:
I wonder if this can have applications where relativity can have tangible effects (see https://www.wikiwand.com/en/Light_cone), like high-frequency trading?
Relativity doesn't really come into it. Even at orbital altitudes, the difference due to dilation is miniscule. Places that need high quality time will use a local atomic clock disciplined by GPS, where GPS already factors in the dilation. This gives you very close to constant time across the earth's geoid. Variations due to temperature in your DC and many other factors will utterly swamp any time dilation differences in this context, and even without those the discipline would have no problem flattening it out.
Not an expert, but I think the whole idea of vector clocks is to provide a logical clock which defines a partial rather than total order between the events, and where two events are related only if they must be due to e.g. data dependencies. This abstracts away the complexities of keeping clocks in sync or even dealing with relativistic issues, at the expense of being able to order fewer events.
... is a section that explains how they work without actually describing what they are.
Apparently it has to do with keeping track of time and ordering of the events in distributed systems. At least what it looks like from the intro of the paper the article is rehashing.