Quite a silly question, I know… But can anyone throw some light on how happs such as Holofuel manage micropayments? Even updates on Holo(chain) are false updates in that the previous entry isn’t actually deleted! Wouldn’t storing a thousand entries for micropayments every second clog your device storage?
“@artbrock has repeatedly said that HoloFuel is optimized for thousands of micropayments a second. Paying for hosting services requires that sort of speed and small transaction amount.” -
Lets say I have 1000 coins of some currency built on Holochain. Is there any way to represent just that, while ignoring how I reached the 1000 mark (doing away with the history of transactions)? As far as I know, the way it currently is, is that it stores that –
I recieved 100 coins from A;
I recieved 300 coins from B;
I recieved 600 coins from W;
Hence I have 1000 coins! Which quickly becomes a recipe for disaster!
Don’t understand what your concern is? Anonymity?
There are no coins. Every unit is an accounting amount. It has to come from somewhere and it has to be verifiable. In order for me to know you legitimately have those 1000 units, I have to be able to audit your transaction history. It’s possible that there would be milestones so your entire history doesn’t have to be audited. So at some time into the past I wouldn’t know that you got 100 from A. That information is beyond my pay grade so I can’t speak to it.
Someone deeper into Holofuel or the transaction process in general may be able to answer you.
I think I failed to express my concern last time… “I” receiving a “100” coins is the main concern!
If I understand the agent-centrism correctly, When A makes a transaction to me of a 100 units of some currency (like Holofuel), A subtracts 100 from his balance, and I get to add 100 to mine (perhaps simultaneously). Now of course this transaction was a secret. My concern lies in that over time, my private chain will have so so many transaction entries (increment 100, increment 300, and so on…) that micro-payments would become unfeasible (as there is no true update in Holochain; the old entry still exists, which is a requirement for a stable immutable hash-table).
I hope I’ve made myself clear.
So in essence, how can an app store the “balance” field as part of the metadata of another entry, as opposed to requiring its own separate entry?
If I have a balance entry containing “0” amount, then upon receiving 100 units, I create another entry that says “amount: 100” and update the old entry’s metadata to point to this newly created entry. Now when I receive another 300 units, I create another entry and update the first entry’s metadata to point to this new entry that says “amount: 400”. Now this second entry that says “amount: 100” cannot be referenced from anywhere and is safe to be deleted. But Holochain doesn’t have garbage collection! Plus the headers (for verification purposes) are on the public space again for verification. In short there’s a lot to be cleaned up, which isn’t cleaned-up EVER! Wouldn’t that render stuff like micropayments impractical (at least economically: storage ain’t free)?
Your concern about immutable data and the ever growing hash chain would be an eventual issue for any ongoing log. If I now understand you correctly, your specific concern over micro payments is that, since they are micro, they are likely to grow at a much faster rate than other payments. Since there could be hundreds in an hour of hosting.
For logging on going balances, there has been proposed a sort of “garbage collection” process where a current balance is recorded, a new DHT is started with the new balance and the old DHT can be archived. Just like any other database that wants to reduce its size.
All I can say is there are a lot of intelligent people who have thought this out and designed it. So somehow your concern is addressed. Wish I knew enough to answer it in depth. But I don’t.
[I’m hoping that our activity here will generate some interest from someone more knowledgeable to chime in. I don’t know who to ping in the Holochain forums.]
1 Like
Every user has their own chain and chooses how much of the total data of their peers they want to store and verify locally, small devices can choose to hold less of the overall dht
The data held is specific to each application, in this case only HF transactions
Compare that to ethereum where all full nodes hold and verify all data for all users for all applications, ETH transfers are lumped in with domain registrations etc.
Eg holochain won’t get a ‘cryptokitties moment’ where the inefficiency and popularity of one application overwhelms basic transactions because on holochain they are separate apps with separate networks
The holochain approach is different to ethereum shards
In holochain individual chain entries are stored with randomized peers, kind of like how bittorrent files are spread across seeders and each seeder might hold all or just some of the data for a specific torrent file, and that is fine because the leechers know how to find each piece of data from the network in aggregate
Imagine the holofuel ledger like a torrent file that grows over time, any device that holds even a small percentage of the ‘file’ is helping keep that data live
In sharding each shard acts like a mini chain so still requires everyone in the shard to hold all of that shard, a device is not helping very much unless it commits to holding the entire shard
Users do need to keep all their own transactions but users on low powered devices are not intended to be doing thousands of holofuel transactions per second consistently indefinitely, this level of activity for a single user might need a dedicated hard drive attached (a normal TB drive would be fine)
2 Likes
Looks like the current state-of-art is to not do micropayments unless you can afford it (I.e, a big enough hard drive, etc). Let’s hope the GC thing that @LifeSMyth was talking about does get implemented some day… Till then we’ll have to live with this false illusion of micropayments!
You are making assertions, not showing proofs. Perhaps returning to the basic material on Holochain for further education will help you. 
sure, in the same sense that you should never buy a camera because it’s always possible to take more photos than a retail camera hard drive could fit
in the sense that modern cameras can fit many thousands of photos, and you can either buy another hard drive yourself quite affordably, or pay for cloud storage, then you should buy a camera because there is a reasonable expectation that you won’t actually exceed the hardware you already have or could easily access
a payment is thousands (or millions) of times smaller than a photo, so you can make thousands or millions of times more payments than you can take photos on a mobile device
but we aren’t talking about phones being used as holoports, we are talking about devices designed for web hosting being used as holoports
let’s say a nicely optimised holofuel transaction uses 500 bytes or so of data (a bitcoin transaction is about half that), and a standard 1 TB holoport raises 10 invoices every second all day every day (which implies many more individual requests being served to end-users because a single payment can cover many requests) - rather unbelievably consistent and high usage for a single $500 device i’d say…
500 bytes x 10 transactions x 60 seconds x 60 minutes x 24 hours x 365 days = 157.68 GB per year
hard drives only last between 3-5 years before needing to be replaced, even if it is still running, 3 years from now a 1TB hard drive will feel like a 256GB HD feels like today… a bit claustrophobic…
even with numbers that are unrealistically high i can’t make myself feel worried about raw payment data being a burning issue for holofuel
note that i’m using 10 TPS here for a single port not 10 TPS for the entire network, every port has their own personal 10 TPS, leading to a total network TPS of 10x the number of active ports.
achieving 1000s of TPS across the whole network with 1000s of ports online really only implies ~1 TPS per port, and that’s only ~15 GB of data per year so 
3 Likes