Scaling Blockchain ID Registrations

Core Blockchain
#1

Continuing the discussion from Blockstack community thoughts on block size / Bitcoin XT debate:

2 Likes
#2

I’m thinking now that in order to hit 1B or more users, one of the following would need to happen:

  1. We’d need to be on a blockchain with fairly large block sizes, as in something on the order of magnitude of 100MB blocks. This obviously has massive scalability concerns, and only takes us so far.
  2. We’d need to have our resolvers tap into multiple blockstore universes on multiple blockchains, and use TLDs to uniquely identify usernames on specific blockchain-and-name-universe-combos (this could be done with a TLD-mapping system that ties consumer-app level TLDs to namespace identifiers within the universes). The concerns here are that in order to resolve all names, one would need to have copies of many blockchains, and the TLD-mapping system would need to be centrally managed (or at least managed by a single community/non-profit/effort).
  3. We’d have to pack multiple registrations into a single transaction. For example, one could pack 1024 name registrations into a single transaction by having each registration be formatted in a certain way and signed by a separate key, then appending them all together and storing the combined file in a reliable place, then hashing that file and storing the hash in the blockchain. The downside here is that one needs all of the data referenced from the blockchain hashes in order to build the view of the namespace universe. That is, the system is completely dependent on an outside data source. The other issue is that this system cannot support SPV name wallets.

There’s no good choice here, but the more I think about it, it seems that the second one is the most realistic.

1 Like
#3

thanks for unpacking these constraints @ryan …

for me, identity is central to the notion of ‘glocal’ (aka act local - impact global) …

and ‘viable’ … eg who gets recognised when, and for what

#4

Yeah so the system will be dependent on an outside data source for both names and values. Right now it is not dependent on names, only for values (consciously not trying to use the <key,value> terminology here and using <name,value> instead). Question is how useful is the system with just names (if outside data source(s) go offline) and is there only a marginal difference between relying on external data source for both names and values.

#5

Yeah, great clarification.

I’d say a system with just names is quite useful for certain things. For example, the name to public key mapping is still there, and if I have fragments of my profile that were signed with that public key then I can still have extensive use of the system.

The other thing is that if you have an error in a hash-value to value lookup, then you can always go back to it later. But if you have an error in the lookup of a bulk name registration, then you have to stop and wait until you get the data to proceed. And this would keep happening as you index the entire chain.

1 Like
#7

With just names (& public key) you could do authentication which is pretty useful.

#8

I’m assuming those transactions break down as follows:

1 x preregister
1x register

2 x update (setting their profile info during onboarding)

2 per year x update

Preregister & register operations are one time events and limited by population growth (or population persona growth). (assuming Blockchain IDs are for humans)

Over time the majority of the transactions generated will be from update transactions. Assuming a Blockchain ID is used for 100 years the transaction breakdown looks like this:

1 x preregister
1 x register
202 x update

Is there a way to pack only update transactions in a way where the name / public mapping is still on blockchain & usable by SPV clients (for auth) but snapshotting of value data can be done for multiple profiles in one transaction?

One could imagine where each registrar could periodically bundle multiple updates in one transaction.

#9

A post was split to a new topic: Block size implications for scaling OpenBazaar

#10

Any thoughts around doing registration on the main blockchain, then binding the user’s token to a sidechain to manage updates and current state?

#11

It actually is broken down like so for new users:

  • 1x name preorder
  • 1x name register
  • 1x profile update
  • 1x name transfer (from the registrar’s address to the user’s address)

And like so for user maintenance:

  • 1x name renew
  • 1x name transfer OR profile descriptor update (profiles are updated much more frequently)

So I’m going to estimate 4 operations for each new user and 2 operations for each existing user per year.

Yes, I believe @jude has been working on this. We can pack all of our users’ profile descriptor updates into a single transaction every block.

It seems, though, that you can’t do this for name registrations without forfeiting SPV support :frowning:

1 Like
#12

Yes, we could totally do this, but as it stands, we don’t even need to do profile updates on the main chain. We can simply do a profile descriptor update on the main chain and have links to mutable data in the profile descriptor, where the mutable data is used to construct the real profile.

1 Like