Let’s start with another toy I built on Ardor last weekend:
I call it Burning Messages.
It’s a Private Chat dApp build on the Ardor platform.
You can download it using the Ardor Data Cloud (full client required):
What’s the difference?
Burning Messages uses the Unconfirmed Transactions of the Ardor platform.
The idea is to send encrypted messages with 0 fee which will never be confirmed or recorded on the blockchain.
That’s means messages are gone after deadlines(15 mins by default) — they are Burning. :)
But for chatting that’s quite enough, and it even brings some advantages:
- Messages are instant, depending on the speed of broadcasting. It no longer depends on blocktime.
- No one can dig through your chat history or steal your messages — everything is gone after the deadlines.
- It’s free. An account with a verified public key is the only thing you need.
I’ve tested the chatting between a Tokyo and a Los Angeles node. The messages showed with a 1~2 seconds delay, almost like an instant messenger app.
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:
- Private/Public Chat apps.
- Small device (maybe a solar powered Raspberry Pi) broadcasting temperature of some point.
- Small tracking device broadcasting GPS location.
- 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.
- 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
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.
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.
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.