TL;DR: It is possible to register and use sponsored names instantaneously, without having to wait for the blockchain record.

NOTE: "subdomain" is an older term for "sponsored name."

Background

Subdomains provide a cheap way to on-board lots of users at once, because a single NAME_UPDATE transaction can instantiate up to 120 subdomains. At a rate of ~8 transactions per block, the system can on-board ~115,000 users per day. However, a subdomain will not exist in the eyes of a Blockstack Core node until (1) the transaction is confirmed, and (2) it receives the zone file with the subdomain records.

Proposal

TL;DR: We have clients send subdomain queries to the subdomain registrar that creates them if they do not yet exist on the Core node.

The subdomain registrar has the "latest state" of all subdomains. It not only knows which subdomains it registered (since this is known to all Blockstack Core nodes), but also it knows which subdomains it has not yet announced. Since the subdomain registrar broadcasts zone files under the same name over and over, it can provide a special resource record in its zone files with a URL to a resolver endpoint. This resolver endpoint would answer queries from Blockstack Core clients for subdomains that are still pending.

For example, suppose personal.id was a Blockstack ID that a subdomain registrar used to onboard users. Suppose that the subdomain registrar for personal.id had an API endpoint at https://subdomains.blockstack.org/personal.id. Then, when it sends out a zone file, it would include this resource record:

_resolver URI 10 1 "https://subdomain.blockstack.org/personal.id"

Suppose that jude.personal.id is a subdomain that is queued for registration, but its NAME_UPDATE transaction hasn't been processed yet. When a client attempts to resolve jude.personal.id on the Blockstack Core node at node.blockstack.org, the following steps would be taken:

In order to attempt to resolve the subdomain jude.personal.id, the client would first get the zone file and public key for personal.id from the Core node (steps 3-4). If the zone file has a _resolver resource record, the client attempts to fetch the record for jude.persoanl.id from the record's URL.

When the resolver receives the request, it checks its queue (7). It replies the pending subdomain record for jude.personal.id, and signs it with its private key (8). The client verifies the record's authenticity (step 9) with the public key it got for personal.id in (4), and if the signature matches, it returns the subdomain record.

Eventually, the subdomain registrar will send the information for jude.personal.id to the blockchain, in which case, step (1) will have succeeded.

EDIT: latest diagram is here:

client                                  core node    subdomain registrar                                                                                                                                                                                                                                                      
------                                 ---------    -------------------
  |                                        |                 |
  |                                        |                 |
  | (1) GET /v1/names/jude.personal.id     |                 |
  |------------------------------------->  |                 |
  | (2) HTTP 301 _resolver URL             |                 |
  |  <-------------------------------------|                 |
  |                                        |                 |
  | (3) GET /v1/names/jude.personal.id     |                 |
  |----------------------------------------^-------------->  |
  |                                        |                 |
  |                                        | (4) check queue |
  | (5)       jude.personal.id: <...>      |                 |
  |  <-------------------------------------^-----------------|
  | success!                               |                 |

The Core node should keep track of the resolver for each subdomain registrar, and should be able to redirect clients to the registrar to resolve pending subdomains (2). The subdomain registrar needs to be able to handle queries against its pending queue (4), so it can service requests to subdomains instantly using the same API endpoint (/v1/names) that Core uses (5).

Advantages

A subdomain would be usable and resolvable soon as it is put into the subdomain registrar's queue. Blockstack applications would be able to work with it immediately, including multi-reader applications.

Caveats and Limitations

This proposal is only for resolving subdomains that are in the process of being registered. It is not meant for resolving subdomains that are in the process of being updated or transferred.

This algorithm only works if the subdomain registrar is trusted. The fact that the pending subdomain record is signed by the Blockstack ID owner ensures that the reply from the registrar won't be tampered with in-flight. However, the subdomain registrar could lie about the contents of the pending record. Clients that cannot trust the subdomain registrar must wait for the subdomain's Blockstack ID's transaction to confirm first.

Any/all feedback welcome on this proposal (cc @kantai @larrysalibra @shea256 @yknl)