The Third Type of Data

We know platforms like Bitcoin or Ethereum treat everything as essential — recording everything on the blockchain.

Then we have Ardor, which treat a substantial amount of data as Prunable, massively reducing the blockchain bloat.

What I want to show is that there may be a third type of data, which is quite useful, but never needs to be recorded on the blockchain.

I know if everyone does this, it may raise a problem like flooding the network. Let’s put it aside and see the potential first.

Power of Unconfirmed Transactions

If you think of unconfirmed transactions as the UDP in TCP/IP, you may find the huge potential behind it. Here are some examples I could come up with:

Messaging/Reporting:

Private/Public Chat apps.

Small device (maybe a solar powered Raspberry Pi) broadcasting temperature of some point.

Small tracking device broadcasting GPS location.

Probing/Negotiating:

Probe whether an account is ‘online’ (like the ‘ping’), then starting a chat/shuffling…

Bidding/Offering the price of something with 0 fees, the seller or buyer could bundle the transaction to make it confirmed.

Triggering/Controlling:

Use as a signal triggering the execution of something, like a dApp’s function or some smart contract.

The Ardor node itself could use that as configuration command, especially in mass deployments and maintains.

Superiority from Ardor

Ardor didn’t invent the unconfirmed transactions, technically other blockchain solutions could do that too (except those DAGs?).

Is there some superiority when we do it on Ardor? The answer is Yes.

Ardor has so many build-in transaction types

Messages, Trading, or even the Cloud Data, save the time of designing the protocols yourself.

Ardor has child-chain structure

Now, we return to the flooding problem. Maybe simply create a new child-chain(a ‘chain’ recording nothing) and create a separated unconfirmed pool that could isolate from the impact to the existing chains.

Benefits to Ardor

Instantly Respond

It adds the ability to instantly respond, which is quite important for end-user dApps.

In fact, only a few types of applications need waiting for a block confirmation: those changing your balances, like payment or trading.

Binding all functions of a dApp to block confirmation is not necessary.

For the platform side, continuing to shorten the block time is also not a good solution to everything.

Instead, if we handle the unconfirmed transactions well , it may make dApp experiences smoother while further reducing the unnecessary data on the blockchain.

Online Nodes

Processing unconfirmed transactions requires both your dApps and the Ardor node behind it to stay online

For example, if there are 1000 users using Burning Messages chatting, there are 1000 online Ardor nodes.

If 1000 temperature reporting devices all over the world are pinging, this means 1000 online Ardor nodes all over the world.

We may be the network with most nodes if only a small percent of dApps work this way.

Sum-Up

All blockchain solutions seem to treat unconfirmed transactions as the cost of the mechanism and try to eliminate them in an unnecessary way.

In contract, it could bring huge benefits both to dApps and the network if we discover the real power of it and harness it.

Ardor, which has rich build-in transaction types and the parent-child structure, may be a very suitable platform for accomplishing that.