edicted Blog Banner

edicted

Virtual Smart-Contracts & Derivative Consensus

consensus_cartoonnodederivativevirtualcontract.png

The Fire is Lit

Some people on Hive would get very discouraged after getting downvoted for over $500. Not me. I am not most people. I've become a man on a mission: heading on the opposite direction; double-down. I'm working on my Hive database 12 hours a day and plan on eventually creating my own token. The only way to mine this token will be to destroy Hive/HBD by sending funds to @null.

Don't worry about the downvotes!

I hear on the Grapevine that they are being put on pause for the time being. I'll try to make the most of these phat Hive lootz while they're rolling in. My @hextech witness partners really want to boot up a Full-Node, and I actually have the money to pay for one now. Holding out hope for a crypto spike come June to get a big discount.

It's weird to imagine spending money on stuff because I never do: I've always been the low-maintenance scrapper that gets by from employing an extreme amount of minimalism. Work just long enough to pay my bills and spend the rest of my time dicking around playing video games and smoking pot. Because why not? The world is a garbage dumpster fire, might as well. I refused to play this rigged game of trying to climb the rungs of this ridiculous corporate ladder.

But I know I'm being given a very important opportunity on Hive. For the first time ever I feel like I can break away from this wage-servitude shit-show and actually provably own the products I build directly on-chain. Not only do I feel as though I can free myself from this vampiric time-suck of an economy, but I think I can help to free others as well. Flat architecture is extremely powerful and currently massively underutilized.

learnblocklinksignaturechainblockchain.png

So I've been tinkering around in my database a bit more and I realized something that could be huge. I honestly don't even believe it is possible; I must be making some kind of mistake. That's how crazy and valuable this revelation would be if it actually works.

Virtual Smart-Contracts

In reviewing the tokenomics system for my Cards Against Humanity clone, I was just thinking to myself:

Wow, it sure would be nice if I was able to add DeFi farms and an algorithmically pegged stable-coin to this project. But of course that's impossible because it's way too much work.

But is it too much work though?

It took an experienced dev team years of programming with heavy venture-capitalist backing to create MakerDAO. And that's just for DAI. Programming a DeFi farming network from the ground up would be even more work. There's no way I could compete with that... or can I?

work2.0.jpg

Work smart; not hard.

I'm starting to realize that adding these features to my product may end up being an extremely trivial process. I just have to add some tables to my database and include some node-logic to make them work.

How is this possible?

What I came to realize yesterday is this: tokens on ETH and BSC must conform to highly generic token standards in the form of ERC-20 and BEP-20. Why do these dev teams go through so much trouble to conform to these rules? Because if they do they get grandfathered into the entire network and can atomic-swap their asset for any asset also in consensus on the network. It's a great way to get instant liquidity and be part of the bigger network.

However!

I'm going the opposite route. I'm creating my own brand new network (not really). Not only that, my focus will be on creating sleek lightweight nodes that do exactly what I want them to do without any extra clutter. This means that the system I create will be a lot more efficient and easy to prototype, but the scope is going to be very narrow. The code will not be generic or adhere to standards (at least to start). This will inevitably lead to a Spaghetti-Factory situation that will need to be cleaned up massively if we want to scale up further.

spaghettifactory.png

This is how I play Factorio, so it's how I create a token.

When you begin the game of Factorio you have to make some pretty important decisions before you even begin creating your automated base. You must choose: do you just want to get up and running ASAP and fix the bottlenecks as you go, or do you want to scale up right at the beginning and hope that pays off for you later?

I'm coming to realize that many of these crypto networks are opting for the latter. They want to scale up first and then capture as much adoption as possible in the future. It's not a bad strategy, but this is not a strategy I can personally afford to employ (yet). When I play Factorio this is exactly how I do it and it works fine.

First, we create an efficient spaghetti-factory that gets the job done as we constantly put out fires in real time. Once the bugs get worked out I start a completely new base with the object of scaling up. This strategy tends to work out well because the first base provides me more than enough resources for the scaled-up version. It's technically a waste of resources because the smaller base becomes outdated, but it's much easier than trying to plan a full-scale operation before we even know how to accomplish the task.

Ethereumspikemarket.jpg

Example:

With MakerDAO and Dai we can see these concepts in action. ETH is an old network when generic solidity programming. When ETH was built Vitalik didn't realize that DeFi yield-farming was going to be a huge thing. Therefore ETH nodes don't have any special place-holders to store information for DeFi yield farming OR algorithmic stable coins.

This leads to a situation where dev teams who want DeFi yield-farming and/or algorithmic stable coins on ETH have to jump through dozens and dozens of hoops to make it happen using the generic coding techniques provided by ETH. This makes exploiting these systems much more likely because again, ETH was not built with these functions in mind, and dev teams must constantly audit their own code and make sure to plug these vulnerabilities.

gameover.png

Starting over.

Therefore, I'll just make a new node network where NFTs, Defi Farming, and algorithmic stable-coins are just built in by design. I know I know... it sounds like a ton of work. I'll never be able to do this by myself or with a small team. Or will I?

HIVE! HIVE HIVE HIVE!

So Hive is allowing me to lower the bar in a big way. Seriously if this works it's going to be legendary. I'm essentially creating my own consensus algorithm: POB² (proof-of-burn x proof-of-brain).

POB²

Now I know what you're thinking:

@edicted... bro... you're not smart enough or experienced enough to create a new consensus algorithm.

And you know what? I totally agree. Doing such a thing is way too much work and getting a community to back me up is way too difficult. However, this is not a "NEW" consensus algorithm: this is a derivative consensus algorithm that 100% relies on Hive security (much like LEO). That's exactly what makes all the smart-contracts trivially easy. They piggyback off the main chain so that I don't have to do any work. When someone posts a custom JSON and signs it with their active key: I know for a fact this is a legitimate transaction as long as the custom rules of my node accept it. If someone's active key gets hacked: that's on them; I can't do anything about that. Welcome to crypto.

Examples:

I want to create DeFi smart-contracts and an algorithmic stable-coin for my token. No problem: just add a couple tables to the database and some import logic to the node. On ETH or BSC, these things are very difficult because the generic token standards. Because I'm making a new network I can just pick any rules that I want and employ them immediately.

Virtual smart-contracts.

With MakerDAO, in order to give yourself a loan and print DAI "out of thin air" you must employ several contracts. First you must lock ETH in a contract. This operation is called "lock". The mechanics are complicated because they adhere to ERC-20 standards. When I want to "lock" funds on my new network... the user will just post a custom JSON to Hive that says: "Lock" that's all they have to do and my node will make it happen because the original network is already in consensus. We don't have to abide by generic rules for creating new complex protocols.

Ultimate scripting

This puts me in a position of being able to create a new token standard on Hive for NFTs, DeFi, and algorithmic stable coins. I believe this system will be so solid that Hive witnesses will essentially be forced to come into consensus with it as it gains popularity.

xwing.jpg

Supreme Disadvantage

It's a new network... it's connected to nothing. We are going to be trapped in a void when we launch. There will be no exchange listings, and even selling the token back into Hive will prove... challenging until I figure something out. It won't be too hard to set up over-the-counter trades using Hive's escrow contracts, but that's going to be EXTREMELY clunky and very bad liquidity.

Now, this is a huge disadvantage... but the advantage I gain is more than worth it. Using virtual smart-contracts... I'll basically be able to write an entire smart-contract by simply issuing a single custom-JSON on Hive. Rather than having to jump through 1000 hoops and hoping the the code doesn't have bugs... all I need to do for a contract is have users type the name of the contract into Hive. I don't have to worry about bugs or exploits as much because the code I'm using isn't a generic toolkit. The data I need is stored purposefully right inside the node as a native asset rather than generic storage. Huge difference. Makes it x1000 times easier to prototype functionality when I don't have to follow anyone else's rules but my own.

stable coins balance.jpeg

Rules for stable coins.

Coins like Maker/Dai were first to market with algorithmic stable-coins. I learned a lot from Maker, but they made a ton of rookie mistake.

Dai Mistakes:

  1. They purposefully chose a deflationary asset.
    Maker has no inflation and actually deflates when interest is paid.
  2. They use ETH collateral. (Impossible to short the market.)
  3. They have an exploitative interest rate.
  4. There is no DeFi Farm.
  5. The collateral required/liquidation variables aren't split.

All of these mistakes coalesce to create a completely inferior product... but at least that product exists on ETH, amirite? Maker being a deflationary asset (thanks Bitcoin maxis), means that it's impossible for them to implement a DeFi farm, as these farms require a lot of inflation. On top of that, the collateral is ETH, meaning Maker doesn't have the power to print ETH on demand, making it impossible to short the network and create a balanced futures market.

Maker should completely change the way they operate, but they aren't going to. I can fix everything they did on my own network with a simple script that doesn't need to come into consensus with a parent network. That's the beauty of virtual contracts and derivative consensus.

DeFi Farming

Same thing... very hard to implement on BSC and ETH... very easy to implement on a new system that incorporates them on the ground floor. Of course it exists on a network by itself with zero liquidity, but honestly I prefer to be quarantined like this until I work out the bugs. If there is no bridge to the outside world, I don't have to worry about hacks and exploits as much. If something goes wrong I can just fix it and/or rollback the chain, whereas on BSC and ETH the damage has already been done and the ETH/BNB liquidity has already been permanently stolen... can't roll back those chains... nope!

What are the attack vectors.

Assuming there aren't bugs in my own code (there will be), the biggest threat comes from the Hive network itself. As a derivative consensus algorithm, my network will 100% rely on Hive witnesses. For example, if the Hive witnesses allowed a custom JSON to be published under a false signature, that would break my entire system.

My node will essentially have to connect to every full node available and import the same block across all full-nodes that will give it to me. Either that or I'll just have to boot up my own full-node and trust that 100% (but this opens a centralized attack vector IE what if my node gets hacked?)

So not only will I have to trust that the Hive consensus witnesses aren't posting bad blocks, I also have to make sure that I'm actually receiving those blocks and not fake blocks from an attacker. All things considered I'm not too worried about these things. Hive has proven to be quite resilient over the years.

Conclusion

I have a lot of work to do. Hopefully this all works out, but the system I'm trying to breathe life into is really coming together. The tokenomics seem extremely solid. Again, this will be a derivative consensus algorithm (POB²) based around burning Hive/HBD, NFT token creation, DEFI farming, and algorithmic stable coins.

Because DeFi Farming is all the rage these days, I may be able to crank that part out first and launch the pre-mining phase well before the NFT gaming part is even fully functional. This would then give me a lot more incentive to work on the project when more users than just myself have skin in the game. We'll see...

Wish me luck on my journey.

Posted Using LeoFinance Beta


Return from Virtual Smart-Contracts & Derivative Consensus to edicted's Web3 Blog

Virtual Smart-Contracts & Derivative Consensus was published on and last updated on 04 May 2021.