Lately I've been thinking a bit about a token I'd like to create on the Hive blockchain. The way I want the mechanics to work, I'm not even sure if I could build it with SMT or HiveEngine tech. This means I would have to run it on a custom centralized witness node (@hextech).
Not that the witness node would somehow become more centralized, but the extra code on top of it would be, because no other witnesses would likely be running that code (much like HiveEngine). Although I have thought of a few ways to incentivize other witnesses to run the code which would make it fully decentralized, if I could pull it off.
In any case
I don't know if I could use standard SMT or HiveEngine tech to make the token, because the token could only be created by destroying HBD. The point of this is to guarantee the value of the token while bringing even more value to the main chain and vaporizing our debt in exchange for other assets.
Another reason to create tokens by burning HBD is to further push the concept that this network absolutely requires a CDP loan collateral system so that anyone can stake Hive and create HBD out of the Collateralized Dept Position. I went into this in depth quite a few times recently. If I could create a service that limits the supply of HBD and increases its demand so that HBD is always trading over $1, it would be much easier to push these politics.
Creating tokens is easy.
Trust me, it is very very easy to create a token on the Hive blockchain. Anyone can make up their own rules and their own consensus. Anyone could create a custom_json operation and point to it and say:
See that code? That is money! I created it!
The real trick is getting other people to agree that what you made is money. It's even more tricky being able to trade that newly minted money for other cryptocurrencies.
How does HiveEngine do it?
Like every other centralized exchange, HiveEngine (PAL team) simply centralizes the funds to a single account that they control. In this case that account is @honey-swap. This way when someone wants to trade a token created on HiveEngine with actual Hive, they instead trade it with another token pegged to Hive (HiveP).
HiveP
Looks like it's actually called SWAP.HIVE, but you get the idea. By wrapping a token and pegging the value to Hive with 1:1 collateral, HiveEngine is able to use the consensus mechanics they've devised for token creation to link all these tokens to Hive.
Because Hive is then linked to all other networks via centralized exchanges, this gives their tokens a lot more value than if they simply existed inside a vacuum of their own network. Interoperability and connecting networks is absolutely key in this space.
What about "real" centralized exchanges.
You might think a Goliath corporation like Coinbase runs things differently, but on a foundational level this is simply not true. When you see Bitcoin on a centralized exchange, this is not Bitcoin; this is a Bitcoin Pegged asset that exists inside of their centralized database. This is where the term comes from:
Not your keys, not your crypto!
It might look like a whale is buying/selling coins into thousands of users on an exchange, but in reality they are only buying and selling against the holdings of the exchange. This centralization makes transactions easy to accomplish and for the service itself to be monetized.
What about DEXes?
The ultimate concept behind a DEX is that we eliminate the middle man (exchanges) and stay in control of our funds the entire time. This is much more secure, but also much more inefficient and difficult to achieve.
Atomic Swaps
The "easiest" way to build a DEX is for atomic swaps to be enabled between tokens. Once this tech is in place, trading coins becomes a trivial process because consensus verifies them at the core level. Even Hive has a DEX:
https://wallet.hive.blog/market
Sure, there are only two coins on it (a single pairing), because those are the only two coins that the witnesses verify consensus for, but it is something.
The problem with atomic swaps is that the only "easy" way to accomplish their functionality is to accept the consensus algorithm of that token into the network itself. This would mean Hive witnesses would have to run a Hive node and a Bitcoin node in conjuction to enable atomic swaps with Bitcoin.
Imagine a Hive witness being required to run nodes for a dozen different networks so we can easily enable atomic swaps. The cost and inefficiency of that scenario is simply far too great and unrealistic. It also ironically centralizes Hive by increasing the cost of being a witness, and thereby preventing many users from ever becoming a witness or running a node in the first place.
Decentralization and trust often come at the extreme overhead costs of exponential inefficiency.
We have to draw the line somewhere.
Zero-knowledge proofs
This is a technology that could also help with token swaps but I'm not even going to pretend to know how it works. It's super complicated and the more I read about it the more it doesn't make any sense.
In cryptography, a zero-knowledge proof or zero-knowledge protocol is a method by which one party (the prover) can prove to another party (the verifier) that they know a value x , without conveying any information apart from the fact that they know the value x .
Hm yeah, cool story, bro.
I'm not sure how that helps but apparently it does.
How would I do it?
So yeah, like I said before, I have an idea for my own token but I'm not sure if SMT or HiveEngine would support it. If that was the case I'd have to build my own system for trading the token for Hive. After reviewing the escrow system I think it is possible.
Escrow example
Someone wants to trade my token (let's call it HEX for now) for Hive. Someone else wants to trade Hive for HEX. The person with Hive sends an escrow transaction to the account providing HEX. All parties agree to the transaction. When the HEX account sends their HEX with a custom JSON (or whatever I use) the first account would release the funds or the second account could appeal to the escrow account should a dispute arise.
More decentralized.
So this would be a DEX, because anyone who provided the escrow service would be the trusted middle man (not just a single centralized exchange). However, it would not eliminate the middle man altogether, which is what we are ultimately looking for in the long run. Baby steps.
Why is this solution better?
It doesn't centralize all the money to a single account. What happens if that account gets hacked? What happens if that account owner gets kidnapped and is forced to release the funds to the attackers? Things like that can't happen if anyone can be the middleman escrow account. That's what all of these centralized exchanges are: middleman escrow services.
Downside?
Well, I'm sure there would be plenty of scammers ready to jump in and make people think they could be trusted to be an escrow account and they steal the money by colluding with one party. The damages of such an event could be largely mitigated by only doing business with escrow accounts that have a high reputation and by limiting the amount of money transferred during a single transaction. Why trade $10,000 all at once when you could trade $1000 ten times or even $100 a hundred times?
Quarantine (too soon?)
There's also the option to not connect my token to the rest of the market. It would be a governance token anyway used for voting on consensus within the game's mechanics. The ability to transfer something like that for Hive isn't necessarily required. In fact, I could stop trading all together, making it less of a token and more of a reputation level. I'm just spitballing here.
Bad ideas; synergy has value.
Of course, by adding a connection to the rest of the market the token gains a lot more value, so keeping it quarantined on purpose is obviously a bad idea.
Conclusion
Alright well I think I'm done musing about all this work that I don't have the time or the resources to complete. It's time to get back to my coin flipping project (something I actually can complete at the moment). With the experience I garner using the escrow smart contracts hopefully I'll be able to recycle that code elsewhere. A new DEX on Hive could be one of them, even if it is super basic and isn't a trustless system.
I've actually had this idea (or one very similar) a while back and had it in mind when I created the account @dexturd. Although I've also more recently created the account @hexdex for potentially the same purpose, seeing as my shared witnesses name is @hextech (plus it rhymes, too!).
Buzz on, busy bees!
Return from How Does A DEX Operate? to edicted's Web3 Blog