Topologically Ordered Bitcoin Database (using a relative timeline, ie. event a before b... this means causality).
Similar to Genesis, as it’s a structured database constructed from Bitcoin, which not only contains the transaction graph, but also indexes every single push data to make them easily queryable for any kind of Bitcoin application. If you want to know about Gensis, read here
Until now, there have been three chronological ways to sort transactions throughout various Planarian nodes:
- Block Time:
blk.tin Genesis, Babel, etc.
- Block Height:
blk.iin Genesis, Babel, etc.
- Real World Time:
timestamp are absolute times, whereas
blk.i is relative time.
And now with Neon Genesis, we get access to relative time WITHIN a block. Here’s an easy way to visualize how Neon Genesis works:
The relative timeline is represented by a new attribute named
"i". This new attribute represents the relative order of transactions within a block. So for example, if a transaction was the 7th transaction included in a block, it would have
7 as its
This means you can query things like this:
Here it’s just fetching the latest 20 transaction items, but sorted by:
- block height (“blk.i”) first
- and then the index (“i”)
For example if the current block height was 582609 and if there were:
- 14 transactions in block 582607
- 7 transactions in 582608
- 3 transactions in 582609
Above query will return all 3 from 582609, all 7 from 582608, and then the last 10 transactions (with
i ranging from 4 to 13) in block 582607, sorted by the relative order within the block. What does this mean?
It means it is possible to sort transactions across blocks, within blocks, throughout the entire blockchain.
It also means it is possible to construct a single canonical timeline, as a hybrid of absolute and relative time. Here’s an example:
The black circles represent transactions, and the numbers inside the circle represent the relative order within the block. From this diagram we can construct a single chronological 2-dimensional timeline:
(27182818, 0), (27182818, 1), (27182818, 2), (27182818, 3), (27182818, 4),
(27182819, 0), (27182819, 1), (27182819, 2),
(27182820, 0), (27182820, 1), (27182820, 2), (27182820, 3), (27182820, 4),
(27182820, 0), (27182820, 1)
Want to play with the database? Here’s another example you can try: https://neongenesis.bitdb.network/query/1HcBPzWoKDL2FhCMbocQmLuFTYsiD73u1j/ewogICJ2IjogMywKICAicSI6IHsKICAgICJkYiI6IFsiYyJdLAogICAgImZpbmQiOiB7fSwKICAgICJzb3J0IjogewogICAgICAiYmxrLmkiOiAtMSwgImkiOiAtMQogICAgfSwKICAgICJsaW1pdCI6IDEwMAogIH0sCiAgInIiOiB7CiAgICAiZiI6ICJbLltdIHwgeyBvcmRlcjogLmksIHR4aWQ6IC50eC5oLCBibG9jazogLmJsay5pIH1dIgogIH0KfQ==
Chronos vs. Neon Genesis
For the sake of really getting to the bottom of how all this works and what it means, let’s compare Chronos with Neon Genesis just for fun.
Here’s the first difference between the two:
- Chronos: Powered by absolute timestamp within the mempool
- Neon Genesis: Powered by topological ordering within a block
- Chronos: Each transaction has an absolute timestamp (Unix timestamp of when they were discovered)
- Neon Genesis: Each transaction has a two dimensional timestamp: one absolute, and one relative. First we have the absolute timestamp of the block time
blk.t(They also have the relative timestamp of
blk.ibut that’s out of scope of this article) Then within the same block, every transaction has its own relative index
i. These indices are not absolute timestamps but only tell you the order in which they happened in each reality.