![image.png](https://files.peakd.com/file/peakd-hive/klye/23tbwSwm3y3yLum4Xo7n3shzVmcz8qBUs7wcQgg8h6fPbEAu9UvGSiGBGys1nNo2NnpbW.png)
_{( before we get started I'd like to apologize before hand at the massive walls of texts and lack of more diagrams in this proposal )}

[Please Cast your Vote on Proposal #164 By Clicking Here](https://peakd.com/proposals/164)

`Necessity is the Mistress of Invention`

Born partly out of the necessity to decentralize the lending contracts on the upcoming [Hive.Loans](https://Hive.Loans) project and also in part finding inspiration to do further research after seeing the still somewhat ridiculously valued centralized EVM instance run the Binance exchange reach over $200 USD per token in value, the idea to create the HIVE networks' very own PROPERLY DECENTRALIED & WIDELY DISTRIBUTED version of the Ethereum Virtual Machine stack was decided upon as a worthy project. This proposal aims to spread the word about the work to be done on this project as well as seek funding from the DHF in order to move ahead quickly to get this side chain built, tested and deployed in a span of 3 months or less permitted development and testing phases aren't met with setbacks. The whole idea tp create a HIVE user mineable, fully decentralized, industry standard EVM stack into the ecosystem shifted from a quick activating idea into an absolutely incredible amount of excitement about it being possible after an absolute ton of reading up on the subject, and personally beginning to reverse engineer / dive into the latest Ethereum implementations. This post is a culmination of prior research into how the technical side of ETH works, a substantial amount of recently conducted research regarding feasibility and a pretty s=decent albeit fulfilling amount of "hands on" research on a handful of prospective donor ETH implementations rendered down via code editing local compiling of custom Ethereum Virtual Machine versions and it's necessary supporting libraries. ended up resulting in my thoughts and focus converging on the undeniable fact that a truly decentralized, community operated Ethereum Virtual Machine (EVM) capable side chain that throws away the lazy "clone and rebrand" model used in other chains utilizes HIVE as it's base and gas fee currency much like how Ethereum and Binance coin use ETH and BnB respectively ended up running across my mind and the idea instantly lit up bright. To accomplish the feat of bringing a properly decentralized EVM stack to HIVE, the rapid development of a heavily modified custom HIVE based version of the EVM executable. The initial "core" team behind this project development are internationally based duo consisting of @lapingvino and @KLYE, both of which are established HIVE witnesses with a collective sum of over 25 years software engineering experience between them. By deploying a combination of reverse engineering blended with the developers different programming language specializations and knowledge of different systems and network architectures. Initially my own personal development efforts will be pivoted towards finishing off the Hive.Loans project which aims to launch Mid April publicly albeit not running on the HSC at launch, then pivot to working on this project full time alongside @lapingvino and anyone else who decides to hop onboard the development push. Goal is to have at least 1 developer working on this full time at any given day and the funding this proposal provides allows for payments to be made to anyone actively helping to develop the HSC and is not limited to the core development duo but anyone assisting. It's very likely we'll have a fair number of developers from within our community come together to make this project into a reality. While focused on finishing up and testing the Hive.Loans project I personally won't be paying myself out of this proposals daily allowance. The idea behind being inclusive in allowing other developers to contribute to this proposal is that it will end up paying a decent number of developers within the ecosystem for their efforts as they either hop on board with development or end up subcontracted out under the project in order to implement or supply elements within development.

`Leveraging the Community and the Users Diverse Skillsets`

In addition to the core development duo a number of other developers in the community have expressed their interest in helping make the HSC a reality and the plan is to leverage their help as well in order to expedite the development and testing. The support from the HIVE development community even before the time of posting this proposal has been astonishing and I look forward to brainstorming and developing this along side all of you. Potential assets or developers interested in getting involved should check out the HSC EVM room over on Hive.Blue chat to gain access to the team amassing to build this network upgrade. The level at which you step into helping build this system with the community is entirely up to you, ranging from something as simple as sharing your ideas on a part of the project, sharing interesting repositories or pre-existing code you've stumbled upon all the way up to diving in and getting your hands dirty contributing to the HSC source code itself we'd love to have your input on board.

`Perform Any EVM Smart Contract Chain Functionality Using Existing Ethereum or Binance's BnB Chain Code`

`But 1000% More Affordable and with Gas Fees Paid with HIVE!`

Once the HSC has been built with great efforts going in to reverse engineering out custom smart contract from the most currently available Ethereum implementations our very own HIVE as a base utility token side chain will be live.. Potentially causing quite a stir amongst the crypto communities as the HIVE chain is imbued with the very same functionality 3 out of 3 largest market cap networks possess. The truly awesome part comes with the realization a user may gave before seeing it below. Absolutely ANY (and I mean ANY) Solidity or Serpent EVM smart contract code that would run on Ethereum or Binance's BnB chain will be able to natively run on HSC with little to no code refactoring required. The modification of the available functionality that HIVE offers in the form of HIVE integrated and focused unlocking network wide access to some of the most highly sought after decentralized financial tools, decentralized exchanges, ERC-20 type token creation and decentralized autonomous organization structuring possibilities. Just as we are seeing a bloom of all sorts of interesting service and business architectures spin up on ETH and BnB once brought online the HSC will act as a catalyst and affordable workshop attracting innovation from all corners of the larger crypto and software developer ecosystems.

`Understanding How an EVM Stack Works`

`And How it can be Implemented for HIVE`

![image.png](https://files.peakd.com/file/peakd-hive/klye/23tSz3RpZ16ePNot293cF9hwnMH1ZJi1Uc4Jjg1q8uc9X7P4e6zQVFTvrVVYuJu3DUaTe.png)
_{( this picture was stolen from google images as me drawing a diagram on MS-paint seemed silly )} People's eyes tend to gloss over when folks start trying to explain the actual technical working of how technology works so in the interest of everyone reading through this proposal, with the intention of completion hopefully resulting in a greater understanding than they did going into it and not resulting in a hemorrhaging of potential supporters getting overwhelmed by terminology they may not be familiar with or being intimidated by huge walls of text.

`A Quick Terminology Crash Course`

Fist off before we continue any further we have to lay down some basic concepts and touch on the terminology that will popup frequently within this document. Without outlining what certain words are in reference to the point of explanation is lost as many will not bother to research it themselves. Please, if at any point in this proposal you're unsure of a term or concept and it's preventing you from becoming excited at the incredible prospect a HIVE based EVM smart chain will bring to our community hop onto another tab and insert the phrase into google to research more. While I've tried my best to make the information contained in this proposal as easily digestible to non-IT based lifeforms as possible, it may not be sufficient to convey the potentially abstract concepts and ideas required to understand how all this works. This technology is quite complex for most initially. The term EVM refers to technology known as the "Ethereum Virtual Machine" which is the part of chains such as ETH or BnB that allow for the execution of smart contract code. It is with this technology powering these smart chains that operate what you can think of as "Worldwide computer" A virtual machine (or the VM in EVM) as alluded to above is a term used to describe a system that may not actually exist within the physical realm but rather is a virtualization or emulation of a system which is often run as an application on an underlying system. When you read a reference of a Stack in regards to this type of technology it's referring to a quite old abstract data type concept in computer science in where a system operates a store of data or code in a manner resembling the stacked layers of a cake or something along these lines. It involves 2 different fundamental functions beyond storage of data within itself consisting of "Push", which adds an element to the collection, and the "Pop" function, which removes the most recently added element that was not yet removed from the stack. By utilizing this "stack" architecture we're able to line up data to be executed by the virtual machine responsible for making Ethereum able to perform functions just like a computer without being physically accessible in any one location.

`Putting it Together to for Decentralized Trustless Computing on HIVE`

Armed with the brief crash course terminology introduced above (or known prior) we'll now explore how exactly an EVM stack operates and how it can be ported into HIVE via a sidechain to take advantage of our quick block times and extremely cost efficient chain operations while simultaneously infusing an incredibly sought after functionality within the current crypto currency ecosystem. We're not only looking to add value and functionality to our chain but provide an affordable decentralized alternative to the chains currently providing this sort of functionality. When developers create smart contracts, usually high level programming languages such as Solidity or Vyper, one of the final processes involve compiling this code down into machine readable formats known as opcode and bytecode. Opcode stands for Operation Code and as of the time of researching this technology there were something like 140 different Opcodes which can be thought of as instructions for the EVM to execute more often than not conveying low level commands needed to execute the smart contract code itself. Then there is also what is known as ByteCode, which generally consists of efficiently stored Opcodes needed for the smart contract to operate which may also include things such as variables or required run-time data. All of this Opcode / Bytecode and stack magic works together on what is called a "Contract State". It is this State in which contracts store exactly what is going on within the contract itself. Due to the technical limitations of the EVM it's not uncommon for smart contracts to often utilize what is known as "contract memory" or alternatively "storage" as it's referenced by most to store data for long persistence or future recollection by the EVM. This however is expensive gas fee wise and it's advised against to use EVM based storage unless absolutely necessary due to cost. The EVM operates within all nodes of the given network in a sandboxed manner, meaning that the virtual machine element of the EVM is prevented from interacting with the machine that it's parent process/program is running on primarily for security purposes. Without this "sandboxing" in effect, given that the EVM executes code submitted by anyone the potential for malicious code effecting systems running these nodes would be incredible. Luckily due to the design of the EVM sandboxing though people can safely operate nodes without fear of falling victim to black hat developers. While the cost and complexity of offering what essentially boils down to a "computer that lives in the clouds" isn't currently competitive with running your applications on a classical centralized server setup the HSC project hopes to bridge that gap by offering the functionality of an EVM to the public at roughly 1 / 2000th the cost. For a slightly more technical run down of how it all works check out [this article](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e).

`Implementing The HSC EVM into HIVE`

At the base level the HSC project will operate as nodes that can be run by anyone provided they have the required HIVE power in the account they wish to operate a HSC node on and the required hardware and storage available to produce blocks when they are called upon within a strict time limit. Currently there are two schools of thought in regards to how this should be accomplished. The first summarizes up cleanly into coding then compiling highly customized Ethereum software implementing a P2P network that out of the box requires access to a hived executable to query any data it needs as well as watch in real-time for references it would need to act on in order to know if it needs to manipulate its stack structure to execute requests. Been experimenting locally with a few different research variations of this first method with some success, with the most promising implementation of this being based off of "[Geth](https://geth.ethereum.org/)" being written in the GO language. The second school of thought is that a graphene based (same architecture as HIVE) chain containing an EVM implementation is utilized which straight away makes communication cross chain from the HIVE blockchain to the HSC EVM chain a decent amount easier which may cut down on development time greatly. This possibility was brought to my attention by @bobinson after informing me that it had been previously explored to be feasible by another development team working on another project and may be the route the HSC takes provided the benefits outweigh the overhead that come with the graphene based networks. In the end regardless of what way the HSC architecture under the hood gets built from the takeaway from it is that the HSC will monitor the HIVE blockchain and will perform actions on it as needed, as well as take input from the HIVE blockchain as well up to and including automatically querying accounts to ensure they have the HIVE for gas fees or that their account is the owner of a particular HSC address or contract. Interacting with the HSC will be performed easily on either the HIVE blockchain or using HSC node applications. The possibilities of new services focused around providing HIVE users quick and easy access to the more complex features that the HSC will bring to the realm of possibility for this community will certainly be an interesting field to watch. One thing to mention as well is that rather than use the _{0xFB551e1a50c3ECf19Beb975e9AB59C1bB00DA77F} style addresses that Ethereum ships with, we'll be implementing a means of using HIVE account names as addresses and typing existing HIVE account names to HSC addresses. This has already been achieved by ETH and some other EVM capable sidechains and will not only add to the usability of the HSC but also greatly increase its appeal over other EVM chains due to readability. The libraries we'll be forking and modifying to include this quality of life upgrade to HSC in comparison to other chains is from the [Ethereum Name Service](https://github.com/ensdomains) project.

`Enhanced Side Chain Security Through EVM Synchronicity`

One somewhat unique idea that came to me upon researching more deeply how this system works, the thought that by allowing the HSC network to accept the running more than 1 EVM instance favouring multiple EVM implementations in different languages and comparing their outputs upon execution of a any piece of code the network could leverage that in order to increase security of the HSC as a whole. More R&D into this design concept need to be performed in order to see if this has any performance drawbacks. Ideally the HSC ends up running at the very minimum 2 different EVM implementations written in different programming languages and compares their outputs. By allowing multiple EVM instances to run in tandem to each-other on each future HSC node and writing logic within the node itself to ensure that no single implementation is throwing out a different output we're able to keep the side chain and it's execution of the smart contracts more secure.. In the instance that one of the EVM outputs differs from the other (or group) of instances that computing won't be included in the sidechain itself preventing potential exploits of certain EVM implementations from effecting our chain in any way. By keeping the HSC accountable to itself in regards to smart contract execution output it's hoped that we can mitigate some future potential security vulnerabilities that may be discovered within certain flavours of the EVM implementation. What this ends up looking like in the production releases of HSC and it's supporting node software isn't yet set in stone. However it is something that would certainly be valuable in terms of side chain security and smart contract execution accountability for the HIVE compatible EVM chain.

`Decentralization, Side Chain Security and Mining`

Learning by observing what some might consider mistakes of EVM stacks the like of the centralized BnB chain one of the core development ethos of the Hive Side Chain will be to ensure a properly decentralization model. This is done not only in the pursuit of creating a chain that more closely follows satoshi's original vision of how crypto currency should operate, but also as a clear advantage over other chains that feature more centralized methods and ultimately to allow the community to participate in the decentralization of our chain whilst being paid for their part in all of it by earning the majority percentage of HIVE paid as gas fees to the network. Initially the vision for HSC was to base the decentralization model on the Proof of Work (Pow) style that Ethereum currently deploys but after brainstorming a bit with @ats-david it was soon realized that offering a PoW model would end up disastrous given a 51% attack on the sidechain would be trivial for any competitor to pull off. With that taken into consideration it was decided that a Proof of Authority / Proof of Stake Hybrid model should be implemented for security of the side chain, and also to weed out bad actors from being able to leverage this model by requiring a certain amount of HIVE to be presently staked in the account producing blocks. A required amount of HIVE staked in the account wishing to create a sidechain block somewhere around 500 HIVE or so will make up the basis of the Proof of Stake part of the Hybrid mining method although that amount might be something that node operators are able to set in the future. This not only provides a means of creating demand for HIVE as users purchase and power it up to become eligible to mine HSC blocks and be paid in HIVE to do so, but also adds a significant cost for a large actor planning on creating multiple accounts to attempt to 51% attack the chain. Mining of HSC blocks will ultimately be performed by a large number of users running HSC nodes on systems with enough hardware to facilitate the chain. Source code will be made available for users wanting to compile their own nodes as well as access to precompiled executables in popular formats such a .exe with be provided to allow users of varying technical wizardry levels to get involved in producing HSC block and in turn help decentralize this side chain and earn HIVE while doing so. One of the design goals of the HSC project will also to be target lower block times in comparison to the 15 seconds of ETH. Something between 3 to 9 seconds will end up being the target time for block production to facilitate a responsive user experience. A breakdown of the distribution of the HIVE gas fees of the sidechain are projected to follow the information stated below although these percentages are not set in stone and may change over the course of development or later on through either soft forking of HSC or perhaps as community specified values with the hypermajority value displayed by the nodes being used for calculation: ``` Hive Side Chain (HSC) Gas Fee Distribution Model 80% - Node Operators Producing Blocks / Block Miners 10% - Future Development Fund / R&D DAO 10% - Sent to @null Account / Burned to Combat Inflation ``` Given the design of the HSC uses HIVE as it's base and therefore it lacks the need it's own inflationary base token paid out to node operators helping secure and decentralize the network. The percentage of the burn rate vs block producer pay is something I'd like to see built as a node operator selectable metric that will be determined by the majority integer value broadcasted by the nodes on the network similar to how HIVE witnesses do the HBD interest rate now. The 10% future development fund or HSC R&D DAO will initially be set as a static 10% in the source code although depending on HIVE gas fee volume and the actual capital worth of this 10% it will likely see a downwards adjustment through hard forks in the future. For example if in a hypothetical (or near distant future) HIVE goes to $25 USD a piece and the HIVE Gas Fee volume daily was some extremely large number resulting in the 10% development funding being an amount that is far above and beyond what any lone or team of developers would need to perform the work than the percentage integer would be brought down until the percentage reflects a sane amount of money. A more detailed dive into the ideology behind this can be found in the section below.

`The HSC R&D DAO and DHF Repayment Plan`

The HSC future development fund or R&D DAO will serve as a means to pay developers for updates to the side chain as well as prevent the need for future proposals seeking funding, avoiding the need to ask the community for dev funding in regards to this project in the future. As a side effect it also relives some potential future pressure on the DHF and acts to "future proofs" the funds needed to perform updates on the side chain as we may come to find the DHF funding exhausted some time in a distant future. As an added bonus and means of replenishing the DHF for providing the initial seed capital to pay the development team, the HSC R&D DAO funds will initially be used to pay back the DHF capital cost this proposal seeks as seed funding. This ensures that the community isn't footing the development bill with no plan to replenish the funding required but rather turns this proposal into loan of sorts with no party being left with anything less than what they started with before project development funding was acquired. This is a callback and attempt at improvement upon to the "pay it forward" model of DHF funding prototyped in the Hive.Loans proposal that ultimately lead to the demand for decentralized contract operations which then in turn sparked the research leading to realizing the HSC needed built immediately and be made publicly accessible to HIVE users. The whole crypto community stands to potentially benefit from this project and the potential demand for HIVE increase could be astronomical if the HSC project development is swiftly tackled then properly marketed.

`The HSC Development Proposal Cost Numbers`

$120 HBD Daily over the next 3 Months Totaling $11040 HBD

This proposal seeks $120 HBD over the course of the next 3 months to be paid to the @hive.side.chain account to fund development of the Hive Side Chain (HSC). The Proposal duration shall start at the time this proposal is made public (Friday, March 12th 2021) until completion (Saturday, June 12, 2021) with a total development cost of $11040 HBD paid by the DHF. As outlined in the "The HSC R&D DAO and DHF Repayment Plan" section above, this initial development seed capital amounting $11040 will be paid back via the HSC developer R&D DAO income the sidechain generates on all transactions occurring on the sidechain itself. Not only does this development funding end up being zero cost to the community as a whole once paid back but the potential increase in HIVE price due to offering a competitive smart contract capable chain offering the same functionality as 2 of 3 top market cap coins will very likely end up creating value hundreds or thousands of orders of magnitude higher than its initial costs.

`Understanding The Important Fundamental Differences Between Different Project Development Goals`

`Building Something on the Hive Blockchain _~VS~ Building Something for the Hive Blockchain`

While for a developer setting their sights on the HIVE blockchain as a place to establish a presence here, there is absolutely no real issue in regards to in building applications with the myriad of developer tools and libraries available at places such as [developers.hive.io](https://developers.hive.io) not to mention our community of developers is quite knowledgeable and helpful. There is always a benefit of having more applications offered by a diverse community of developers which serves to increase a currencies demand as well as perhaps also sparking competition between them leading to lower fees and a greater likelihood of HIVE exclusive innovation via applications to occur. However, as far as developers designing and building projects for the benefit of the entire HIVE community beyond the scope mentioned above, it is something not occurring as often as I personally would like to see, perhaps others share this sentiment. Now I'm not saying that I believe developers should work without pay or compensation for their work, as that is quite the opposite of what the case should be.. But what if more developers started designing and building more projects focused towards providing incredible value to the entire HIVE chain and also the crypto community as a whole? Certainly aware that even entertaining the idea that project developments within our own ecosystem, especially ones that completely change the fundamentals of how HIVE can be used, or that alter the utility of our blockchain itself are something that might be a rarity occurrence becoming a common place thing may be viewed as a pipe dream. However I'm also certain that as a community we'll grow and begin to further explore exactly what it is we'd like HIVE to be capable of, leading to investigation of how to implement our visions, leading to more projects coming along and completely reshaping the HIVE blockchain in a manner that creates more value for everyone involved with it currently and in the future. As a developer here on HIVE my ultimate goal is to bring innovation and outside interests attention and capital into our ecosystem. Hopefully more developers here on HIVE begin to look at things not from the perspective of providing services to enrich their own lives but rather look to see how they can create things that will have a net positive effect on our community as a whole. The more we strive to grow beyond the original DNA/functionality of the HIVE code base while taking honest looks into what can be built to benefit of the entirety of the HIVE community is something that should be explored introspectively by everyone developing here.

`In Conclusion`

We as a community would be foolish not to be immediately moving towards doing everything possible to support this obvious upgrade to our blockchain functionality. This project will hopefully act as a cornerstone in separating us from the other graphene based blockchains out there both in terms of functionality but also as a means of meeting an obvious demand in the market with something that benefits all HIVE holders as a whole. It's going to take more than a little bit of money and a room full of developers for this to work though, the entire communities involvement will exponentially increase the chances of the HSC project catapulting the HIVE blockchain into the ranks of top 10 or top 5 market cap coins but in order for this to happen anyone and everyone who has an interest in seeing HIVE grow needs to be doing their part. Be it coding new smart contracts on the future chain, marketing the HSC to people bitching on twitter about ETH gas prices or simply casting a vote on this proposal and checking in from time to time.. There are tons and tons of way you can help support this and future HIVE projects, Ultimately it's up to us as the community to steer the ship where we'd like to see it go. Effectively every user has the potential to be the leader of HIVE in their own ways and putting this all together is my way of saying: "I believe in HIVE, Let's Create A Prosperous Future for It" If you managed to read this proposal and would like to be a part of helping HIVE and it's community come together to allow for the funding of a team consisting of developers within the community to perform upgrades to our blockchain in the form of a fully decentralized 100% HIVE compatible smart contract sidechain please consider voting for this proposal. In the end we're the ones who are responsible for the future success or failure of HIVE and inspiring people to be more proactive in their actions is key. Thank you for reading, supporting, voting, commenting, sharing and most of all being on HIVE.
We as a community stand at the doorway to a new age of abundance for us all.

_{( If you'd like to further support this and future development endevours of mine please vote @KLYE for witness! )}

[Please Cast your Vote on Proposal #164 By Clicking Here](https://peakd.com/proposals/164)

Also forgot to mention the project will be entirely open sourced once it's been made to be incompatible with competitor chains! ;)

Are you on Chat.Hive.Blue already and looking for the latest development scoop?
Come Check out the [Official Hive Side Chain (HSC) Chatroom on Hive.Blue ](https://chat.hive.blue/hive/channels/hive-side-chain-evmhvm)Now

[![image.png](https://files.peakd.com/file/peakd-hive/klye/kSugxl8n-image.png)](Https://www.Hive-Roller.com)

_{Vote KLYE for Witness, Every Single Vote Helps, Thanks for the Support!}

Need to get in Contact with KLYE?
Join the Official #KLYE Discord Server Today!

_{![image.png](https://files.steempeak.com/file/steempeak/klye/LrNonZ6Y-image.png)
Looking for an Affordable, Secure & Reliable Server Host for Your Witness Server or Other Web Related Projects? Check out Privex.io!}

sharpshot