Proposals for Blockstore scaling

[shea256]

@muneeb-ali @jcnelson @guylepage3 and I all had a discussion about the updates we can make to scale Blockstore, and I would like to continue our discussion here.

We discussed a bunch of ideas, and here are the ones I suggest we focus on:

1. Use mutable storage for profile updates

At the moment, each profile update results in a transaction on the bitcoin network, updating the immutable data item associated with a name.

In the very near future, we are going to move to a system where the data item associated with a name is simply instructions for how to resolve names to profile data. This is just like the zone files used by the traditional DNS system, which provide instructions for how to resolve names to IP addresses.

This allows us to cut our update transactions down to 1 per user upon registration, plus 1 for each time a user updates its data storage provider.

2. Pack multiple name registrations into OP_RETURN transactions

We could start packing multiple name registration operations into each transaction. We could have the operation data start with the prefix and end with a TLD that applies to all names in the operation. Then, in the center we pack all the names and separate them by commas.

In addition, we could bump up our OP_RETURN data usage from 40 bytes to 80 bytes, giving us even more room.

For perspective, we'd be able to register the following number of names:

2 x 37-character names
4 x 18-character names
6 x 12-character names
8 x 9-character names
10 x 7-character names
12 x 6-character names

Note: the character counts given above do not include the TLDs

3. Implement operation packing for updates, revokes, and renews

We've discussed how operation packing for updates is very simple. Each update tree can be processed independently and if a tree gets missed, the system can still make progress.

The same is actually true for revokes and renews.

Transfers are more complicated, however. If one transfer is missed, nodes cannot know that they have the right name ownership information.

4. Implement operation chaining to allow for transfer packing

We can support transfer packing by using name-specific operation chaining, where each name operation references the previous operation. Thus, if a node sees a transfer or update, it will be able to determine whether it was valid or not because it can simply see if it has the full chain since registration.

Registration packing, though, is a completely different beast. Essentially, missing individual name registrations is an unacceptable scenario and results in very bad things. Thus, perfect operation tree broadcasting is a pre-requisite. We've discussed ways to accomplish this, but it seems that things got complicated very quickly and I don't think we've fully thought through all possible failure scenarios. There's a much longer conversation to be had here, but I think we should push off registration packing for now.

Where this will get us

At the current block size of 1MB, miners can pack up to about 2000 transactions per block. At that rate, the bitcoin blockchain can support 100M transactions per year.

2000*144*365 = 105,120,000

Conceivably, in the best best case scenario of blockchain ID registration growth, we could make up 10% of Bitcoin transaction volume, in which case, we'd be able to do 10M transactions per year at current block sizes.

If all non-registration operations were packed and all preorders were bulk preorders, the vast majority of this (99.9%) would be registration transactions. That means that 5M name registration transactions could be issued per year.

Now... it is very realistic that blocks will hit 8MB in 5 years time. In that case, we'd be able to do 80M name registrations per year (if we packed two names in per TX), which should be more than enough.

Remember that these calculations are just for ensuring that we can handle a scenario where this system gets as big as Facebook. This is not expected, and so we do not have any expectations or plans to clog up bitcoin transaction volume.

[larrysalibra]

Great ideas. No specific comments on the four you listed.

Now... it is very realistic that blocks will hit 8MB in 5 years time. In that case, we'd be able to do 80M name registrations per year, which should be more than enough.

Remember that these calculations are just for ensuring that we can handle a scenario where this system gets as big as Facebook. This is not expected, and so we do not have any expectations or plans to clog up bitcoin transaction volume.

A bunch of hypothetical questions came to mind while reading the above text. I don't think they belong here in a technical discussion of scaling proposals, so I posted them to the forum here: https://forum.blockstack.org/t/questions-about-blockstore-growth-limits/267

[shea256]

Thanks Larry! Do you think this technical discussion would be better suited to GitHub or to the forum thread?

[shea256]

I'd like to add a 5th proposal to the list above.

5. Allow a single preorder operation to apply to multiple registrations

We know a preorder is required before a registration. You preorder a name by committing to registering an undisclosed name at some point in the future. You do this by hashing the name with your public key. Then, when you register, the name and your (hopefully never used before) public key are revealed and compared against the hash to validate your clearance to register the name.

Instead of hashing a single name, though, we can hash a list of names and have each of the register operations come after the preorder. Once all name registrations have been seen, they are all taken together and checked against the preorder, and are either accepted as an entire batch or rejected.

With this method, we would be able to move away from 2 transactions per name registration and approach 1 transaction per registration.

As an example, we would be able to do a single preorder and then 100 registrations all tied to that single preorder.

Further, we could combine this with "proposal 2" mentioned above and pack multiple names into each operation. In fact, it would be quite realistic for us to pack 8 names, at an average of 9 characters each, into a single transaction.

This would mean we would be able to go from 2 transactions per name registration to 1/8 transactions per name registration!

Combine this with operation packing for transfers, renewals and revokes, and we have a system that requires 1/8 transactions per user for the lifetime of the user!

[shea256]

I re-did my calculations, so I'm posting them in a new comment:

Where this will get us

At the current block size of 1MB, miners can pack up to about 2000 transactions per block. At that rate, the bitcoin blockchain can support 100M transactions per year.

2000*144*365 = 105,120,000

Conceivably, in the best best case scenario of blockchain ID registration growth, we could make up 10% of Bitcoin transaction volume, in which case, we'd be able to do 10M transactions per year at current block sizes.

If all non-registration operations were packed and all preorders were bulk preorders, the vast majority of this (99.9%) would be registration transactions. That means that 10M name registration transactions could be issued per year.

Now, combine that with the packing of up to 8 or even 10 name registrations into each transaction, and we have a system that support 100M name registrations per year.

Now... it is very realistic that blocks will hit 8MB in 5 years time. In that case, we'd be able to do 800M name registrations per year, which should be more than enough.

Remember that these calculations are just for ensuring that we can handle a scenario where this system gets as big as Facebook. This is not expected, and so we do not have any expectations or plans to clog up bitcoin transaction volume.

[shea256]

Well, I'd add one more item to my list of proposals:

6. Add support for un-revokable subdomains

We can allow name owners to distribute their own subdomains, and have them cryptographically commit to giving out the subdomains in a way that they cannot get them back until the public keys they assigned them to delegate them back.

This is quite different from the subdomain system in ICANN DNS, whereby the domain owner has 100% control over all subdomains. Thus, in ICANN DNS, domains cannot really be sold, they can only be rented.

Here, because name owners are able to cryptographically commit to giving out names, they can actually distribute names in a way that allows for true ownership.

This system would allow a site to support an infinite number of subdomains per person, beyond the pre-existing 800M domain name registrations per year.

[shea256]

At the moment our short-term scaling plan involves a two main endeavors (outside of switching to mutable storage for updates):

1. updating the preorder operation so a single one can apply to multiple registrations
2. updating the register operation so it can include an update operation as well

The current plan is to postpone mass updates and not pack multiple name registrations into a single registration transaction.

Let's call this Plan A.

I'd like to propose an alternative plan (Plan B), which involves the following:

1. updating the preorder operation so a single one can apply to multiple registrations
2. updating the register operation so that 3 registrations can be included in a single transaction
3. postponing a packed update operation but keeping it on the medium-term development plan

Let's compare the two.

Assuming that a single account requires a preorder, a register, and an update, the number of transactions required will be as follows:

Plan A: 1.01
Plan B (in the short term): 1.31
Plan B (after packed updates): 0.31

My view is that we should adopt Plan B because we'll need to do packed updates eventually, which makes joint register+update operations obsolete. Further, by prioritizing triple register transactions, we achieve a significant reduction that is almost as low as Plan A, and it paves the way for a super low reduction by way of Plan B in the long term.

[muneeb-ali]

Thanks for the alternative proposal. Definitely seems like something that can work well in the long run. I have two main concerns:

a) Plan B long term doesn't get rolled out until we can figure out reliable external storage. That might take a while. And conversely, if we can figure out reliable storage there might be other design options that open-up that we're not considering right now. I usually assume that we don't have reliable storage for storing merkle trees when thinking about possible designs.

b) In my experience, reducing the no. of steps required from a 3-step process to a 2-step process is actually a huge benefit. The more steps there are, the more chances there are for failures and things getting delayed. The faster we can clear out the queues and complete registrations the better it is.

I'm inclined towards moving ahead with the implementation of Plan A, but would love to hear other thoughts and opinions.

[jackzampolin]

We did this!

[blockstack-devops]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.