As more projects look to build upon blockchain tech and one blockchain in particular, Bitcoin, I suggest that Blockstack Blockstore should lead by example and provide clear numbers in relation to its expected footprint on the underlying blockchain.
For example:
what is the estimated memory/disk-space footprint per transaction;
what is the estimated number of transactions
No one can predict the future with absolute certainty, but given the use-cases that blockstore is aiming to support, I’m sure we can pick up existing numbers and “port” them over to the blockstore infrastructure, and from there calculate the footprint on the blockchain.
Yes good idea. When you say “footprint on the blockchain” it sounds like you’re talking about a specific component of the stack - the one that involves the storage of data in transactions, which happens to be Blockstore.
Blockstore uses a couple hundred bytes per transaction where only 40 of that is OP_RETURN data (this may jump to somewhere between 40 and 80 when OP_RETURN size limits are relaxed) and the rest is the standard amount that a transaction requires. This is highly dependent on the number of outputs. Transactions with many outputs could be in the thousands of bytes, as with any bitcoin transactions, although I would expect these transactions to be rare.
For total # of transactions, there’s no way to say, as it really depends on the individual applications building on the system and their traction.
However, we can think about the # of transactions per user. For blockstore, this will come down to 1 preorder transaction, 1 name registration transaction, 1 transfer transaction every 1-2 years, and 1 hash update transaction every 1-2 years, since we are moving to a model where standard profile updates are not sent to the blockchain. Instead, a single “profile recipe” file is snapshotted, hashed, timestamped, and notarized and then links to signed profile updates in external storage. This will be superior to the existing situation on namecoin, where active users could have 5-10 or even 20 profile update transactions per year.
I haven’t yet had my morning coffee. Can anyone please double-check these numbers?
I’m not suggesting Blockstore will ever need to handle 300M users/registrations, although it’s nice to dream big. Anyone care do do the math for FB active users (1.4 billion)?
Taking into account that many other projects hope to build on top of the same blockchain, I think there’s a case to share these numbers with the blockchain core devs. They should have an idea of the kind of transaction volume, bandwidth and storage capacity that full-nodes will be required to handle going forward.
Based on your numbers, it looks like FB’s active user population would take up 2184 GB on the blockchain. I would be more concerned about tx volume than overall storage costs; imagine if a Passcard app went viral and suddenly tens or hundreds of thousands of people were trying to register names at the same time. The recent stress test shows that this could add hours of delays and potentially hamper adoption unless techniques were thought of ahead of time to mitigate or expectations were managed e.g. “You may have to wait up to 24 hours for your account to be confirmed. If this happens, do not be alarmed - this is a feature of the system to ensure the security of your account.”
There is also the approach that Factom is taking, which basically bundles registrations and drops a merkle root “anchor” into the blockchain every once in a while. I personally prefer the security assurance and ease of use offered by putting each individual fingerprint directly into the blockchain without having to audit a merkle tree every time I need to verify whether or not an unauthorized change was made, though this does add more storage overhead.
This is a very interesting point, especially taking into account that the delay will affect not only the Passcard signup process but every other application/client that uses the same blockchain, including bitcoin payments.
I think there’s a case for a new BIP that addresses such cases, so that every user of every app/use-case can be aware of the current network “latency” status just by looking at the wallet/app UI. This reminds me of the game EVE online, which introduced a “feature” called Time Dilation (wonderful choice of name IMO): when the server can’t cope, every client slows down and notifies the user of that fact, so that everyone is aware that they’re playing in slow-motion.
Edit: the idea is to give the user early warning of potential delays and the option to bump up the tx fee before proceeding with registration/use-case.
