Neon Genesis

Topologically Ordered Bitcoin Database

Today I’m releasing a new database for Bitcoin powered by Planaria, called Neon Genesis. Neon Genesis is a fork of Genesis, but with a little twist:

Transaction Topology

YES, the topological transaction ordering (or natural ordering) that powers Bitcoin can have many many use cases.

Below I will explain what this means in practice, but first, here’s the public endpoint:

neongenesis

By the way if you’re not yet familiar with Genesis, 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. You can learn more about Genesis here:

Genesis

To understand why Neon Genesis works the way it does, and why it works, we first need to understand the concept of time in Bitcoin. Let’s start by discussing Time.

Bitcoin is Time

Bitcoin is like a clock, where each block is a clock tick. Everything within the same block is considered to have taken place simultaneously. I discussed this in an article about Chronos.

However…

This is not how the real world works. Bitcoin is not a fantasy novel, it exists in the real world and will only be powerful when it can function as the universal motor of the world. We can’t just pretend that Bitcoin exists in its own isolated universe, we need to create as many portals as possible so Alice can easily jump down the rabbit hole anytime to transact with Bob.

Implementing Time

The first approach to tackle this problem was Chronos. Instead of treating every transaction in a block as having the same timestamp, Chronos makes a tradeoff and uses the host bitcoin node’s “first seen” timestamp to index transactions.

Chronos timestamps transactions based on when the host Bitcoin node discovered those transactions, instead of using the block time.

This means every Chronos node will have different timestamp data from one another because every node discovers transactions independently from one another.

And THIS is the tradeoff Chronos makes. By supporting the real world timestamp, it loses a bit of determinism. But that’s OK for many apps, and Chronos is still very useful for various use cases.

In fact, this is so useful that a new instance — named “Weekly” — has just been released that supports 7 day worth of history instead of the original 24 hour window period which Chronos supported. Here’s where you can use it:

weekly

But, are there other ways?

Schrödinger’s Bitcoin

Time is not linear. It is linear only to the one who experiences it first-hand.

There are multiple threads of time simultaneously co-existing. Each Bitcoin node is its own universe with its own timeline. Time flows linearly within each reality. Whether the cat is dead or alive is already decided in each reality, but to the outside world, not decided until they are “observed” by opening the box, which exists as a form of a new block.

There is no absolute finality, there is only probabilistic finality. A “finality” is reached when one miner mines a block and the rest replicates THAT state, and enough time passes (for example, 20 blocks) without the dominant reality being replaced by another, stronger reality, through a re-org.

Until a block is mined, nobody knows whether the cat is dead or alive. Once a block is mined by one node, it notifies its neighboring nodes that there’s a new reality. The neighbors may or may not follow the new reality, but eventually they will have to because it makes economic sense to do so. And soon, this new reality becomes the dominant reality of the entire network, and a single dominant timeline is born, from which the multiverse starts the same process all over again, each building its own reality on top, competing to become the one who decides the next “era” of the reality.

How Time Flows inside Schrödinger’s Box

Let’s return to the statement I made earlier:

“Everything that happens within a single block should be considered to have happened SIMULTANEOUSLY.”

This is still true. All transactions in a single block share a single Unix timestamp.

But what happens inside the Schrödinger’s box? Inside the box, time still flows linearly. The cat perceives time linearly as well. However, inside the box, there is no absolute timestamp for each transaction. There is no unix timestamp or anything. This will become especially true as Bitcoin mining evolves and becomes parallelized. Therefore trying to decide on this concept of “real world timestamp” for transactions within a block is meaningless.

However, we DO have something very valuable here, and that is relative timeline. Just because you don’t know what time it is (absolute time), doesn’t mean you can’t sense the flow of time (relative time).

Below is a visualization of Bitcoin. The horizontal dotted lines are the relative timelines within each node, and these timelines all resolve to the blockchain (the vertical solid line) as a single absolute timestamp.

Imagine you’re a prisoner sent to an isolation chamber with no light and no perception of what’s happening outside. You will quickly lose perception of time inside the isolation chamber after a few days. And that’s what Schrödinger did to his cat. However, fear not! You still have the power to perceive “relative time”. If you stand up, and then sit down, you know that standing up happened before sitting down. THIS is relative time. And this still has important meaning even if this relative timeline can’t be grounded to the absolute timeline of the outside world.

The Time War

Every Bitcoin node has its own reality (relative timeline). And all these realities may have completely different ordering when compared to one another.

For example, until a new block is born, transaction A in node X may have happened before transaction B. However in node Y, the transaction B may have happened before A. So…does this matter in the grand scheme of things? Does this discrepancy mean this relative timeline is useless?

Not at all. Think of this as a war. Each node is a universe perpetually fighting for power. They fight to make sure their reality becomes the dominant reality. They get rewarded instantly with Bitcoin if their reality becomes the dominant one for the “next era”.

So, why is it OK if transaction A comes before B in “world 100” but B appears before A in “world 200”? It’s because history is written by the victors. It doesn’t matter what “world 100” thinks if “world 200” ends up conquering the multiverse because the rest of the universes in the multiverse system will soon follow the ruling of the “world 200”. If you’ve lost one war, it’s wise to accept the reality and prepare for the next war.

Introducing Neon Genesis

Neon Genesis, as the name suggests, is derived from Genesis. So how is it different? And why is it a meaningful?

It supports Transaction Topology.

This “transaction topology” is the “relative timeline” we have been talking about throughout this entire article. We all know Bitcoin blocks are made of transactions. They are stored in the order in which they were discovered by the node which mined the block.

When I say timeline I mean causality. You have to think differently when thinking about the notion of Time in Bitcoin. The “timeline” is not a single thread. It’s a mix of multiple threads, each of which is ordered by causality (topology). As mentioned earlier, as bitcoin mining becomes parallelized it will become meaningless to try to sort everything from tx-0 to tx-N. However it is still valuable to have multiple threads of causally ordered transactions. Plus, let’s not forget that once these transactions are mined into a block, that’s the new reality, and this multi-threaded, causally ordered “timeline” is good enough to accept as the canon.

Until now, there have been three chronological ways to sort transactions throughout various Planarian nodes:

1. Block Time: blk.t in Genesis, Babel, etc.
2. Block Height: blk.i in Genesis, Babel, etc.
3. Real World Time: timestamp in Chronos

Note that blk.t and 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 "i" attribute.

This means you can query things like this:

Here it’s just fetching the latest 20 transaction items, but sorted by:

1. block height (“blk.i”) first
2. 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

Second,

• 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.i but 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.

Usage

You can use this to implement social media feeds, logs, or anything that has to deal with real world time.

Just like Chronos, you can use Neon Genesis for various cases that require involve time, but in a different way. In fact you may even use both Chronos and Neon Genesis in conjunction.

For example, imagine memo were to implement the service using Planaria. It could use a combination of Chronos and Neon Genesis: Chronos for the posts in the mempool, and Neon Genesis for the posts in the block.

It would look a little different from how centralized social media services work, because using Neon Genesis, the timestamps would look something like:

alice: just updating my memo           Block 27182818:Index 31415
rando: @_unwriter Hello! How are you?  Block 27182818:Index 31414
_unwriter: Hello World!                Block 27182818:Index 31413
...

OR, if it were to use a “time ago” format, it may adopt a new unit of Bitcoin relative clock (let’s just call it “tick” here for brevity), and it may look like:

alice: just updating my memo                   11 TICKS AGO
rando: @_unwriter Hello indeed! How are you?   12 TICKS AGO
_unwriter: Hello World!                        13 TICKS AGO
...

This is only possible because we can construct a single chronological thread of every single transaction from all the way from the first transaction of the genesis block of Bitcoin. This concept of a hybrid of absolute and relative time is a very powerful new dimension to think about various things in Bitcoin.

Conclusion

Neon Genesis is an experiment which can be adopted by all other Planaria nodes, so if you like this, let me know and I may even expand support to other Planaria nodes as well.

Also, this implementation utilizes a new feature of Planaria I am working on, which I plan to roll out publicly soon (which is why Neongenesis is not yet registered on planaria.network), so stay tuned for that too.

Try Neon Genesis:

neongenesis

Learn how to build something like Neon Genesis:

Planaria

Come join the community and share feedback:

Join the Atlantis community on Slack!

Learn more on Twitter:

_unwriter (@_unwriter) | Twitter