Hi there,
It is my understanding after (quickly) going through docs/faq that currently metadata are anchored on the Bitcoin blockchain… but in the new version they will be stored in Stacks Blockchain which is under development.
Is the above correct and if not can someone clarify the current state and the roadmap ahead?
If the above change takes place how compatible will it be for those that build on the existing platform?
Thanks and apologies in advance if I misunderstood.
That’s (mostly) correct. The name and token state that gets written to Bitcoin today will be written to a smart contract on the Stacks chain when it goes live. Off-chain name state will still exist and be propagated via Atlas, and will still be register-able via the subdomain registrar.
The existing APIs won’t change – the RESTful API in Blockstack Core today will be implemented by the Stacks blockchain as well.
Thank you for the reply!
The API abstraction makes sense. What will happen to the metadata that are already anchored to Bitcoin? Will they be migrated… or would the new system have a way to consult them where they currently reside (i.e. Bitcoin’s blockchain) ?
Where can I find more information about Stacks blockchain? I understand that more functionality can be added by a dedicated blockchain but not many blockchains can provide the same security guarantees as Bitcoin’s blockchain.
Again, thank you for your time.
The off-chain name state will continue to work as-is. The logic for processing off-chain name operations will remain the same, since it’s a public interface that’s undergoing standardization with the Decentralized Identity Foundation.
The develop branch of Blockstack Core, as well as any PRs against it. Specifically, look at the sip directory – it contains all the Stacks Improvement Proposals.
EDIT: this is now in the master branch.
I was aware of DIF but I will need to look into it further.
I wasn’t actually asking about the off-chain data but for the data that are already on Bitcoin’s blockchain. I assume they will be migrated to the contract?
Thank you for the resources on Stacks blockchain. There isn’t a lot of (high-level) information though. Should I consider the v1.1 blockstack whitepaper to be the base and the sips just extensions? Is there a new whitepaper coming out?
And finally, is there a roadmap that I can consult? When is the Stacks blockchain expected to run in production?
Yes – all state on Bitcoin will be migrated to the BNS smart contract.
There will be a new whitepaper in the coming weeks. The SIP documents are admittedly low-level, and comparable to Bitcoin’s BIPs.
Quarterly roadmap is here: https://blockstack.org/roadmap/
Reviving this old thread since my questions is very relevant.
For names like foobar.id:
Okay, so then I assume there will be some hard-fork type event after which all new IDs now require a Stacks transactions instead of the usual 2 Bitcoin transactions?
Where do the subdomain name registration transactions go? Right now the registrar makes a transaction on the Bitcoin blockchain and communicates the Zonefile to Atlas network.
Will there be a similar hard fork at for the registrar code to make transactions to Stacks chain instead of Bitcoin?
Thanks!
Yes – when Stacks 2.0 is launched, all transactions will occur natively on the Stacks blockchain. No BTC will be required. It’s still two transactions though – one to commit to the name preimage, and one to reveal the name. Two transactions are required in order to prevent registration front-running.
Yes – subdomains will continue to work as it does now, except NAME_UPDATE transactions will be native Stacks 2.0 transactions (so, no BTC required). The Atlas network, zone file format, and off-chain subdomain system will continue to work as they do today, but will be more reliable (in particular, the “stale consensus hash” problem is going away, since Stacks 2.0 transactions will not need consensus hashes). We’ll release a new version of the subdomain registrar that can interact with the Stacks 2.0 blockchain as well, and it’s RESTful API will be preserved.
I can understand how Stacks 2.0 will be able to provide light-client verification of on-chain state (SIP004). But how will client verification work in case of off-chain names?
I’m confused by your response in this thread in context of off-chain name verification by light client -:
A lot of this complexity is going away in Stacks v2, since each block in Stacks v2 will commit to the materialized view of the set of names and smart contract state. This will let you not only query a name’s latest public key, but also receive (1) a O(1)-sized Merkle proof that the key is the latest such key, (2) a O(log F)-sized Merkle proof that this state is on a fork of length F, (3) a O(log N)-sized proof that the transaction that made that change has N confirmations and B bitcoins destroyed. For added security, you can also fetch the Bitcoin block headers and fetch Merkle proofs for all proof-of-burn transactions that make up the F-long fork. The proof-of-burn transactions themselves fully describe the Stacks v2 fork structure, so you can confirm that the fork is indeed F blocks long (per SIP 001, fork length is the fork quality parameter).
If the subdomains are not on chain then subdomain SNV would end up looking exactly like it looks now, right?
Yeah, we’ve been trying to work through this too. If you’re trying to get the current public key or Gaia hub info for an off-chain name, then you’d need to first get a proof that the name info all belongs to an accepted NAME_UPDATE transaction (which can be done with the MARF), and then you’d somehow need to be able to prove that there is no such subsequent name operation (i.e. the record you get back isn’t stale).
I haven’t thought very much about how to do the second part. I think there’s something clever you could do here, like implement a second MARF over an on-chain name’s subdomain state, and have the zone file hash commit to the root hash of that registrar’s per-name MARF. But this definitely requires more exploration.
If by nature of the protocol subdomains can’t be updated or deleted (which is the case I believe), then I can trust just the fact that it is an accepted NAME_UPDATE transaction. There might be other undiscovered NAME_UPDATEs on the chain, but they shouldn’t affect the subdomain I’m trying to verify.
If this is right, then even on the current version Blockstack this should be the process of verification.
Steps
Have a magically trusted Consensus Hash. You can only query state which occurred before this Consensus Hash - call it TCH
Ask untrusted BNS node to resolve ‘ankit.foo.id’ -> You get a response which includes a) claimed owner address b) claimed transaction ID which registered this subdomain - call it CTXN c) claimed zone file - call it CZF
Check if this transaction was mined and at satisfactory depth using Bitcoin SPV.
Use trust root TCH to verify if CTXN is a part of accepted Blockstack state.
If you can derive TCH - Ask Bitcoin for OP RETURN data of CTXN. Extract Zonefile hash from this data - CTXN_ZFH
Validate CTXN_ZFH with CZF from step 4. If done, validation successful.
Seems like I may be missing something…?