Power of Unconfirmed (II)
This is some further thoughts about Unconfirmed Transactions. I hope you already read the first part of the story:
Making It Truly Unconfirmable
In the first part of the story, we made transactions unconfirmable by setting the fee to zero. That works under most circumstance but if some Bundler wants pay the fees for you, they still can bundle your transactions into blockchain.
Thanks to community members we found the solution right after the idea was published:
Every transaction in Ardor has a param named referencedTransactionFullHash, which means the current transaction cannot be confirmed unless the referenced transaction is also confirmed.
Just put an invalid hash into that field (like some random string) could make your transaction truly unconfirmable.
Setting A Low Deadline
Every transaction in Ardor also has a param named deadline, which is the deadline (in minutes) for the transaction to be confirmed.
Default deadline is 15 minutes, but we don’t need our transactions be confirmed, only enough time to spread in network, so we can safely set it to 1.
Put Them All Together
Now let’s review how the Unconfirmed Transactions works:
- We sending Encrypted Message to an Ardor account with 0 fee, 1 min deadline and an invalid referencedTransactionFullHash.
- The recipient got that message from Unconfirmed Transactions Pool and respond to it immediately with the same way.
That enables two Ardor accounts communicate with each other privily, instantly, and off the record.
We built Burning Messages only with sending plain text. To take a step further, we now using a formatted data (like JSON), which is much easier to design a protocol and parse the response.
The simplest protocol is Ping:
The sender send a echo request to an Ardor account address:
"command" : "echoRequest",
"data" : "*random_text*"
If the receiver is online, then send back the echo response:
"command" : "echoResponse",
"data" : "*same_random_text*"
That’s the Ping on Ardor. ;)
The data section is optional, just to guarantee the receiver indeed got your message.
What’s this for? Simply say:
It gives you the ability to check the availability of a peer without revealing the IP address.
Remember the Burning Messages we built in the first part of the story? With Ping-on-Ardor, we could easily done this:
Or even better:
Now you know your message recipient is online or not and even the delays.
ARP (Address Resolution Protocol)
What if you do want reveal your IP? I guess not only me when you learnt some network programming in school, the first thing you want to build is a chatting or file sharing App.
But then you found there is no way to get other’s IP address without the help of a centralized third-party server.
We know how the Ethernet got the actually MAC address by IP address — through ARP.
If you think Ardor account address as the IP address, and the real IP address as MAC, that’s how the ARP on Ardor work.
Sender send the ARP request to an Ardor account:
"command" : "ARPRequest"
If the receiver is online (and configured to answer ARP, and white-listed the sender account), then send back the actually IP:
"command" : "ARPResponse",
What’s this for?
It build the bridge from Ardor platform to IP layer in a decentralized way.
Now we can build our own peer-to-peer App without a centralized server. After knowing the peer’s IP, something like sending big files won’t be a problem (sure each peer should has a public IP or UPnP support).
The good part is we done it with encrypted messages , so there’s no such thing like ARP Spoofing. :)
Technically there is no limitation of what protocols you can design on top of Unconfirmed Transactions.
Treat them as UDP you can design a protocols to sending files, streaming videos and even clone the QUIC.
Anyway that’s probably inefficient and not necessary.
With ARP on Ardor you can always done that kind of jobs back on IP layer.
We should use blockchain as a decentralized platform, not storage or sending everything on it.
But no one have power to prohibit it. ;)
And with the introduce of the Ardor Lightweight Contract (already on testnet), I think more usage of Unconfirmed Transactions will be discovered.