This post is the first in a series which aims to clarify uncommon terms that I use. Like those that follow, this term has proven useful in my own understanding of blockchains and blockchain-related technologies. I hope that by clearly explaining it here, the term can become useful for others as well.
Tick chains are a way of thinking about something that every blockchain does. The first part of the phrase, the tick, refers to a signed packet of data produced at some regular interval. By signed, I mean only that there is some way of determining when a tick truly belongs to a particular chain. The "signature" could be a traditional digital signature, but it could also be something more abstract, like the fact that the hash of the tick lies below a certain value. Similarly, the "regularity" of the interval could be a certain number of seconds, minutes, or days; but the ticks could also arrive only in response to certain trigger events, or even be based on something random/pseudo-random (like whenever a qualifying tick is found by an ongoing process).
Regardless of its specifics, the key characteristics of a tick are that its arrival is expected, and that anyone can verify when an authentic tick has arrived. Bitcoin block headers, for example, are ticks. They are expected to arrive, on average, once every 10 minutes. The signature of a Bitcoin block header is that its SHA256 hash value is below the current difficulty on the Bitcoin network. Any onlooker can verify a valid Bitcoin block header based purely on its cryptographic properties. There are also further characteristics of these ticks that the network is concerned with, which leads us to the second part of our term.
In a tick chain, ticks are composed into chains. A chain is a totally ordered (or at least nearly so) set of ticks where anyone can verify the ticks and order that make up the chain. Let's address the "totally ordered" part first. The point of tick chains is to provide a sort of timeline for information: a way of saying which things happened or existed before other things. This timeline would ideally have the property that every tick is both preceded and followed by exactly one other tick (except for the genesis tick of course). That way there is never any ambiguity as to which tick has gone first.
It turns out that half of this is very easy to guarantee: in order for a specific sequence of ticks to be considered a tick chain, we simply require that each tick contains the secure cryptographic hash of the previous tick. Because this hash refers only to one possible tick and could not have been known before that tick was created, its inclusion gives us a strong, verifiable confidence that the two ticks were created in the correct order.
The other half this property is more difficult though, because the restriction for two ticks not to follow from one can only be enforced after the fact. As it turns out, almost the entire usefulness of a tick chain comes down to how well it can guarantee that only one tick will follow every other. Most blockchains try to provide this property by somehow punishing the offending ticks: in Bitcoin someone who produces a second block header at a given height will normally lose their block reward, meaning that the work they put in to solving the difficult proof of work problem has been wasted. In Ethereum, producers of a second block header will lose a portion of their reward if their header is created at almost exactly the same time, and everything if the header is created too late. In most proof of stake systems, the production of two blocks at a given height causes someone to lose a security deposit. But tick chains exist outside of the blockchain world, too, even if they rely on trusted parties and can't claim to be decentralized. The Guardtime system has relied on brand investment, paid auditors, and hashes published in a certain spot in a newspaper to provide confidence that multiple ticks won't be released at a given height since 2007 (and no, despite its recent re-branding, it's not a blockchain. Situations like this are just one of the reasons we need the term "tick chain"). Alstru relies on a similar model, as does the open source TrueTimeStamp. However the tick chain achieves it, a total ordering of ticks gives us a cryptographically verifiable way of proving lower bounds on the age of some data.
Beyond the totally ordered property, we also need to be able to tell which ticks go in the chain. This is where things can get complicated. In most blockchains the rules for deciding whether a tick is part of the tick chain are rather elaborate, and the definition of what the true tick chain is can change over time. By contrast, the ideal situation would be for ticks and tick chains to be verifiable with no further information. Fortunately, most blockchains which support some form of SPV provide fairly strong hints that can be checked right up front: either the tick has a very difficult to produce hash, or some kind of a digital signature. As long as you trust that a broader network is enforcing the full rules, you can get a certain degree of security by simply combining these up-front security features with a quick check that there are enough valid ticks built "on top of" the one you care about. But this approach does run the risk of being wrong twice in a blue moon. With non-blockchain approaches like Guardtime and Alstru, no further data beyond the tick chain itself is required to validate, because those tick chains are not intended to provide any further guarantees beyond the time ordering property.
With these careful definitions of ticks and tick chains, I am almost done with my description! The only thing left to do is note some useful conventions.
Convention 1: ticks are supposed to be small.
There's a reason that I refer to the block headers as being the ticks rather than the blocks themselves. Generally speaking, ticks need contain nothing beyond the hash of the preceding tick, their signature, an optional timestamp or counter, and an optional merkle (or other authenticated data structure) root, which can then include anything else they are trying to provide timelike orderings for. Bitcoin block headers contain a version byte, difficulty value, and nonce but these can be thought of as merely part of their signature. Ethereum block headers have rather a lot more in them, mainly for the purposes of enabling light clients to validate small portions of a block at a time, but this is getting close to the upper limit of what a tick should contain. In general, the smaller the ticks, the better. The only reason a tick should be made larger is for raisons d’être or because it enables the overall tick chain to be made smaller. If Ethereum was a tick chain first and a blockchain second (instead of the other way around), most of the extra fields could have been compressed into a trie root.
Convention 2: ticks are supposed to be naked.
In this case, "naked" means that the data ordered by a tick is not considered to be part of the tick itself. Again, this is an arbitrary convention but a necessary one to clarify that even small, frequent blocks such as those in Ethereum are not themselves considered ticks. We refer only to the headers as composing the tick chain, because when we talk about tick chains we don't care about any of the data ordered by the tick--only the ticks themselves. This has the somewhat awkward consequence of making tick chain verification for blockchains rely on external data, but since signature verification normally relies on at least one piece of external data (the signer's public key), we shouldn't see this as damning. If anything, it's only one of the many architectural insights we can gain from thinking in terms of the tick chain idea. Blockchains choose to enforce additional criteria over the tick chains that they publish--those criteria aren't actually built in to the header data structure.
Convention 3: tick and tick chain verification are supposed to be easy.
Here, by easy I mean "computationally easy". It shouldn't take a supercomputer to verify ticks or tick chains, but ideally it shouldn't even take a beefy smartphone or a lot of network data. Again, most blockchains have made some degree of compromise here by providing lighter requirements to just "mostly verify" that their ticks and tick chains are valid. And of course "easy" is relative, so rates of growth can be more important than initial thresholds. But systems that are tick chains first should aim to be as easily storable and verifiable as possible. Since a tick chain with a one-second tick interval will still necessarily approach gigabyte-level storage requirements per year, this suggests plenty of room for tick chain specialisation (amongst wider and shorter tick intervals especially) as well as the use of techniques such as skip-listing which can strongly improve on a linear time-to-confidence equation for many PoW-based tick chains (by keeping track of hashes which coincidentally but with statistical regularity overshoot the current difficulty requirement). A topic for a separate post perhaps.
And finally:
Convention 4: ticks arrive in real time.
Although it's perfectly possible for some sort of tick chain to be pre-computed and then slowly released over time, this isn't usually what we mean when we refer to a tick chain. Instead, the expectation is that ticks are being produced and delivered within some narrow, bounded window.
With these conventions in mind, I hope it's easy to see why thinking of blockchain block headers as a "tick chain" is the most natural thing in the world, and might even be helpful!
That's all I have to say about tick chains for now. I hope this deeper clarification of the term proves useful to others. My main purpose in publishing these terminology explanations is to more easily refer to these ideas in the future. As I'm sure the reader can imagine, there are a wide number of applications for tick chains. Once I have laid down enough vocabulary, I hope to describe some of the more interesting ones in more detail.