The only thing that makes a smart contract is simply an inefficient database that multiple nodes validate within the network. This is the only context required. If multiple copies of cloned code stay in consensus between servers, this is DLT: Distributed Ledger Technology. It's just a database network that contains 2 or more (hopefully many more) redundant servers.
Redundancy
In the UK redundancy is synonymous with being "laid off". The company can no long justify your lack of profitability to the company. Through no fault of your own: Nothing personal, it's just business. These things happen.
Already right out of the gate it becomes obvious why the legacy economy doesn't understand crypto. They see the redundancy and they think: that will never work. They don't realize the inefficiency is a feature and not a bug.
We've been programmed this way by a lifetime of cutthroat capitalism and brutal competition. Lower overhead. Higher output. More productivity. Scaling up. Dog eat dog. A system of cooperation makes no sense to most people who have been living the opposite reality for a lifetime.
So a smart contract is really just some tables in a database. Generic platforms like Ethereum have a lot of loopholes trying to cater to the ERC-20 toolkit. Flash-loans are a serious problem that leech more value from the network than they give. Needing to work within the confines of someone else's toolbox is not easy. There's are many attack vectors and the hackers are built in: constantly sniffing out new/weak projects. Testing the defenses.
This is why I'm trying to build something that isn't connected to a hacker's paradise like ETH or BSC. Building on those networks comes with a lot of risk and reward. The reward is you get to tap into billions of dollars of liquidity and create atomic swap links to every other token on the network. The downside is you are constantly under attack by black hats that have been honing their skills for years before you even got there.
But again, the biggest downside when using someone else's toolkit is that you get trapped into the tiny little box that's been built for you. Not only that, the more people who build on ETH, the more bogged down the network will become as every node attempts to run every smart contract across every token. Sharding is supposed to fix this but I've already been talking about sharding/plasma upgrades for YEARS and it's still not ready. The centralized development of the Ethereum Foundation is a huge setback
magitek
So I'm still tediously grinding away on my own project. Slowly learning the ins and outs of MySQL relational databases. Procedures, Functions, Triggers, Indexes, Tables, Views, Select/Update statements, yada yada yada.
Yesterday I got my spellbook table up and running. The spellbook allows one resource to be destroyed and another resource to be created out of thin air.
I've decided to get rid of the referral code that incentives frontends to get users to cast ChainLightning and give them 10% of the aether created. At the end of the day I don't want frontend nodes to have a financial incentive to instruct users to make a poor financial decision that nets them a 10% bonus. That's a slippery slope.
I've also gotten rid of the ability for ChainLightning (destroying HBD to @null) to create 2 assets (aether/lightning). Now all spells are one to one. One input one output: makes it a lot easier to code and manage. So destroying HBD only creates lightning, but I've upgraded the Nova ability (lightning >> aether) so that it will be the most cost effective spell to get aether at launch (which is the main way to farm the governance token mana).
Arbitrage
Spells are a game of arbitrage. For the most part, we don't want people to cast any spells unless the network is extremely off balance. There will be an "Alchemy" tab where users trade resources to and from mana/fire/lightning/ice via "potions". Each potion is just an AMM LP pool (mana/fire, mana/lightning, mana/ice) that can be traded with associated fees and slippage costs. Mixing a potion allows users to dump their assets into the vault and receive POT tokens (short for potion/potency): Magitek's version of LP tokens (Liquidity Pool)(Liquid Potency). Couldn't resist a double entendre of the stoner reference. Get them pot tokens, fam.
Cache
The Cache is Magitek's version of CubFinance Dens or GooseFinance Nests. It's just a farm with a single asset that farms outside of the LPs so users don't have to put their tokens up for sale. There are 4 caches (mana/fire/lightning/ice), each of which will be allocated inflation (mana) just like the three other potions available in Alchemy.
Prophecy
Prophecy is an extension of the cache. It is the futures market. All 'power' (tokens) stored in the cache act as collateral for the futures market. Using prophecy, anyone will be able to create any amount of mana/fire/lightning/ice out of thin air as long as they have enough collateral to do so.
This will allow for some pretty amazing stuff. For starters, because the only way to create fire is to destroy Hive (1 Hive for 1000 Fire), minting fire and dumping it on the market will allow users to essentially short Hive itself because Fire is a derivative of Hive.
Fire is Magitek's only deflationary asset. We can assume that at best only a couple million Hive would get destroyed permanently to own fire. This will make it a pretty rare asset and the mana/fire potion pool will be a very risky high-yield pool that pairs two volatile assets. The more Hive that gets destroyed the more value both Fire and Hive will gain.
The only way to create Ice (the stable token) is through this process of prophecy (CDP smart-loan contracts). This means that a ton of mana, fire, and lightning collateral will have to be locked in the cache as collateral in order to mint this stable asset. Interestingly enough, I'm much more worried about the peg breaking to the upside rather than breaking to the downside.
Prophecy is the most risky part of Magitek with the most attack vectors. To start we are going to use witness price feeds and ASSUME that fire has an equivalent value to Hive. This oracle could easily be exploited in certain contexts and perhaps markets could be manipulated to crash the perceived value of cache collateral and liquidate the loans.
This is why the network needs to set the multiplier_collateral setting in the gov table very high (currently x5). It will require x5 more collateral to mint Ice than the Ice is actually worth... and this safety precaution could moon the value of the stable coin... which would be bad. Luckily there are many other ways to tame the price of Ice.
Ice modifiers
ice bolt
ice block
collateral required
collateral liquidate
ice den
fire/lit/mana den
Ice Bolt and Ice Block are spells the network can cast in case shit really hits the fan. They are a last resort and signal to the network that major governance votes need to happen to change the other variables. Ice Bolt allows mana to be converted to Ice, which is great to stop the price of Ice from breaking to the upside, but terrible if the price of mana is crashing and that crash also caused the stable coin to break to the downside.
Ice Block is the counter to Ice Bolt. With Ice Block, users will be able to convert Ice into Aether, which again, is the best way to farm mana on a daily basis. Every day all aether gets destroyed and a user's percent ownership of the aether is converted into mana.
The multiplier_collateral variable is the main way to manipulate the price of Ice. Need Ice value to go down? Reduced the collateral required to mint it. Need it to go up? Increase the collateral. The liquidation variable probably won't get moved much. In general we want liquidations to happen very rarely (if ever if we can avoid it). Unfortunately, like I said, Prophecy oracles will most obvious attack vector so we need to keep collateral requirements high at first to make sure the system is stable.
The last way to manipulate the value of ice is when cache yields. If we increase the yield on ice cache this will raise the price because users will buy Ice to farm the cache. If yield on mana/fire/lightning is increased this allows users to profitably shove funds into the cache than can then be used to mint more Ice, reducing the price.
Notice anything? There are no interest rates. This would be another way to manipulate the price but as I have stated before the way MakerDAO does business is exploitative and nonsensical: you don't charge users interest on a loan that's collateralized by over 100%. Again: deflationary economics are incorrect. I've come up with much better solutions to these problems. To be fair: DeFi invented them I'm just putting all the pieces together.
Governance
On Magitek, it will possible for dozens of variables to be changed on the fly with the sliding-scale voting system I have described in detail. Already there are 32 variables within the system can can be tweaked by the community using this voting technique.
Every day every account will have the ability to vote for a variable to go in one direction or the other (or neutral). In order for the number to actually change the next day, the votes in that direction must first be higher than threshold barrier (which can also be changed) in addition to being higher than the sum of the other direction + neutral votes.
This makes neutral voting (no change) the strongest vote one can make, as they count twice against movement in any direction. In fact, now that I think about it, I might add an actual vote multiplier that makes neutral voting worth even more in order to encourage conservative voting and less changes to the system.
Maintaining balance
By being able to manipulate everything this gives the network the ability to maintain stability. One of the primary goals will be to stabilize the value of Ice. Doing this should in turn moon the value of mana because most ice will be overcollateralized by mana itself. For each dollar worth of ice (1000 ice = $1) there will be multiple dollars of mana locked in the cache to support this value. By also increasing the yield that the mana cache farm generates should also moon the price if the price dips lower than the targets set by the network.
Noob Alert!
My code is shit and it needs to be tested a refactored quite a bit. I am a novice MySQL programmer and a novice JavaScript/Node.JS programmer. The code isn't going to be pretty. In fact I've already rewritten several newbie things that I did in the beginning. Once I actually have a working product my focus will be to stop developing outwardly and turn inward to security, cleaning up the code, documentation, and decentralization so other people on Hive can start running the database themselves.
The firewall
Because the code will inevitably be so flawed to start, we will be operating in a void so if shit really hits the fan we can shut in down until the problem is solved. On networks like ETH and BSC if you fuck up your liquidity gets drained and you lose all of your ETH/BNB. By isolating in the void there is no liquidity to steal and we remain in 100% control during the alpha testing phase.
The only way to remove value from Magitek in the beginning will be after I write a bot that allows anyone to sell Fire back into Hive to anyone looking to enter the network for a discount. 1 Hive will get you 1000 Fire, so fire can never be worth more than Hive. This will allow users to set up discounts for those who would like to cash out a bit.
Passing through the firewall will be the only way to exit the system, assuming there are users on the outside looking to get in at a discount. This should largely prevent the value of fire from breaking the peg to Hive from the downside as a kind of pressure valve (god forbid a "steam" valve). It allows fire to escape the network without new users having to create more and dilute the price.
The system I'm thinking about setting up to this affect is selling Hive into Fire at a 1%-10% discount, while selling Fire into Hive at an 11%-20% fee. Users who try to exit Magitek will be hit with a huge fee (11%-20%) while users trying to enter will get a 1%-10% discount depending on supply and demand at the time. Once all the Fire is gone from these makeshift fire-escapes users will then be forced to burn more Hive by sending it to @null.
Lightning
While fire is an extremely scarce deflationary asset, Lightning is the opposite of this: a massively abundant resource who's value may even decrease over time. There will be many ways to create lightning and it will be used to pay for things like minting NFTs and creating proxies and the majority of other payments within the network.
For the most part, lightning will be the main entry-point to the system, and burning stable coin assets from other networks will be the way to mint more. There will also be a cannibalistic Lightning Bolt spell available that will allow mana to be destroyed to create more lit in case mana dips too low in value and we need to burn our own tokens.
Again, the goal is stability. When the network is doing well and everyone is happy, we burn the tokens of other networks (only Hive/HBD to start). When the market crashes into the dirt we start cannibalizing our own tokens and liquidity to get back up to our long-term price targets. The ultimate goal is for mana itself to be stable due to its hyperinflationary nature (100% inflation per year target). Theoretically we can keep the value of mana itself stable just by properly adjusting inflation rates and setting reasonable price targets. Reducing the inflation makes price go down, increasing inflation makes price go up (unless price targets are incorrect).
Conclusion
Alright well this post is entirely too long. Time to kill it. So far all my math seems to work but there are a lot of bugs (I assume) waiting to be found. Currently I'm working more on the governance voting, as I've realized this needs to be complete before I start field-testing.
Again, the biggest attack vector here are the oracles and more specifically the witness price feed. Magitek isn't going to verify blocks independently, and will need to trust the information it receives from other nodes (validating the same info multiple times across multiple Hive full-nodes). By the time I'm ready to launch my witness team will be running a full node so that will also help validate the system.
The key from there is to get more Magitek nodes up and running verified by the community. We may have to set up proxy derivative-blocks and derivative block-rewards as well to eventually pivot into a real second-layer solution.
Alright time to get back to it.
So much work.
Hola buen día amiga tú blog de ve muy bueno estoy ingresando en esta área.