I have a question. Can Hyperchain be use-case specific?. What if we would like to have some features as inherent property of the blockchain.
Like apart from banking features or Oracles and state channels.
We would like to have Decentralize Identity document feature.
Its just a fashionable term to manage a set of JSON data that contains user information like a registry and the ID’s would follow a different specification unlike to public key .
I would like suggestion on how we would implement something like this in the mainnet for our MVP and suggestion on how to move to Hyperchain when its ready.
Yes, that is the idea You spin your own independent usecase-specific network that implements your particular business needs. You could possibly implement part of those in a smart contract, piggyback on existing primitives (AENS for identity for example) or actually limit/extend the protocol to fit your needs. This is all up to you. What Hyperchains bring to the table is doing all of this in a safe manner. This is especially important for smaller non-custodian networks.
Hey! I was thinking to open a topic on hyperchains, but this one by Vikram seems quite close to what I was thinking to suggest and ask about. Specifically the following use case concept:
It seems that many people are finding needs for use cases that require communication between blockchains – especially of type blockchain 2.0 and newer. And I have gathered that hard coding in any adapters to AE nodes to read foreign blockchains is frowned upon – i.e. it would muddy the codebase and complicating things with other blockchains changes or forks etc… However, could this instead be done off the main chain on hyperchains nodes instead? For example, customize a hyperchain that reads AND can write (submit transactions) to Ethereum blockchain. This would be the ultimate bridge solution between the two blockchains. It’s possible to include even more blockchains adapted on the same hyperchain. This would not muddy up AE’s native codebase. And anything complicated can be “garbage collected” (i.e. just destroy the hyperchain) without any effect on AE’s main chain.
We can call these hyperchains “Death Stars” … as this could be the Cosmos killer. Ok, just joking (hope the best for Cosmos)… but you got the idea!
With this, I think we could see acceleration of application development. I already know one that I’ve been tossing around that I think could be quite popular across the entire crypto-sphere, but would need some kind of solution like this.
That isn’t quite what I was thinking, but maybe it could be close enough?
My thought was that you have a “basic” hyperchain using Proof of Transfer (i.e. hyperchain’s PoS + AE’s PoW), but build into the hyperchain’s node software some interface to an instance, on the same machine, of the foreign blockchain node. All hyperchain nodes will include in the consensus what the latest block for that foreign blockchain. And also be able to read data from the foreign blockchain (of course), and somehow be able to submit transactions to that blockchain… perhaps, this submitting of transaction on the foreign chain can only be done using accounts registered by individual nodes(?) since you probably can not safeguard a secret among nodes.
You spin your own independent usecase-specific network that implements your particular business needs. You could possibly implement part of those in a smart contract, piggyback on existing primitives (AENS for identity for example) or actually limit/extend the protocol to fit your needs. This is all up to you. What Hyperchains bring to the table is doing all of this in a safe manner. This is especially important for smaller non-custodian networks.