Smart contracts are something that is often discussed regarding Hive. Most are aware that one of the gaps in Hive's offering is the ability for developers to tap into a robust, inexpensive smart contract platform.
At some point in 2023, this is going to change.
There are a couple teams working on Layer 2 solutions. In this article, we will cover what was discussed on the latest Hive Developer Call. This focuses upon one of the solutions that will be worked on.
Just to let everyone know, this is still in the planning stage. There are other priorities that are being addressed as we will see.
What is HAF?
For those who are unaware, this is a second layer solution that allows data to be accessed by application developers without having to have blockchain experience.
Here is how it was described in a past article:
HAF is an application framework for creating highly scalable decentralized apps that operate on the Hive blockchain-based network. With HAF, data from the blockchain network are pushed into a SQL database (PostgreSQL) for easy consumption by HAF apps. This means that HAF-based apps can easily be designed and maintained by database programmers with no previous experience with blockchain-based programming.
In lay terms, applications tap into the data contained in HAF and developers monitor that connection. Any updates to the blockchain such as forks are not the concern. That is taken care of by those who understand blockchain code. Any changes to blockchain will be reflected in HAF, ensuring that updates do not disrupt the functionality of applications.
This opens up the door to more developers. Since most are experienced at creating databases, applications, and games, they all can build on blockchain. The number who have expertise in the latter is limited.
Much of this stems from the fact that operations can occur in commonly used programming languages. As we will see, this is vital for the smart contract design.
It is also important to note that HAF is open source and anyone (with the technical know-how) is able to run a HAF node. This can be general for others to tap into or specifically for the applications that development team creates.
While most of us wants this done immediately, there is a progression that has to take place.
We saw this with the base layer code. Much of Hive's first two years, post fork, were spent cleaning up code and scaling the blockchain. This is not sexy stuff yet it vital to future performance.
This same obviously holds true at the second layer.
I guess one of the most significant things too we're doing is in HiveD that's related to HAF is we're changing the way we're writing operations data into the Postgres database now so instead of writing it as JSON text, we're writing in binary format, and that's allowing us to significantly shrink the size of the HAF database.
This is an ongoing theme. Hard Fork 26 saw the size of the Hive database reduced by about 50%. It is a move that enables the block producers to run smaller servers, enabling for greater expansion in the future.
Obviously the same approach is being taken to HAF.
Correct me if I'm wrong, but I think it was around 700 or 800 gigabytes we're saving with that change but it's been a while since I looked at the number so I can't be sure. Lately we've been doing performance testing to just assure ourselves that it won't have a significant impact in terms of performance. There won't be any significant performance degradation with the switch but seems like it's pretty good.
That is a good bit of bandwidth saved.
It makes no sense to roll out a smart contract platform is nobody is able to run the nodes to host it.
Plus, as we can imagine, if things get popular, these will increase the size of the database, although node operators have freedom to determine what they host.
According to the call, we will be getting a road map on this, possibly over the next month. It is evident some thought went into it yet is unclear where it all fully stands. For now, we will presume continued work on HAF will continue with smart contract being the focus after certain metrics are met there.
So what do we know about the direction that a smart contract platform will head.
To start, this is going to be layer 2. It will be built on HAF, meaning developers can access it through either their own node (if they run one) or others who open it up for others to use.
This is going to be written in SQL. Here we have one of the major differences between what this project will look like and what is on Ethereum.
EVM smart contracts are written in Solidity. We know there are billions of dollars in hacks over the past couple years. Much of that was from these smart contracts, where an attacker accessed the contract and basically drained any monetary value out.
The challenge is much of this was due to simple oversight.
According to Wikipedia:
Solidity was proposed in August 2014 by Gavin Wood;[6][non-primary source needed] the language was later developed by the Ethereum project's Solidity team, led by Christian Reitwiessner.
So we are dealing with a programming language that is less than a decade old.
From the same source:
SQL was initially developed at IBM by Donald D. Chamberlin and Raymond F. Boyce after learning about the relational model from Edgar F. Codd[12] in the early 1970s.
Here were are dealing with a language that goes back 50 years.
The key is that number of developers who are familiar with tis code. Not only are there more people able to write smart contracts, there are others who can review the code and provide feedback of any vulnerabilities. Here is where security is increased.
How many people know Solidity compared to SQL?
Again, this is in keeping with HAF's philosophy of bringing blockchain to the majority of developers out there.
We also see the taping into advancement that was made surrounding the language itself.
I mean that that should give us pretty much everything I think that'll allow us to do a lot pretty cheaply because SQL's already got nice security system in place for protecting one smart contract from messing with one another. It's already got a lot of things in there for handling resource limitations so that, for instance, some contract doesn't tie up the database entirely, you know, grab CPU. We can, you can limit how long query runs for before it'll just stop.
The vision of a smart contract application running on HAF really helps to increase the availability to different development teams.
Here we see how an automated system is being considered.
So, you know, like GNS, you know, you're going to have to get somebody to run that on their HAF server. So the idea is anyone who runs this smart contract app.
If anybody who runs that on their HAF server, then that means they basically said that you can now run your smart contract on their server without having to specifically get them to install your smart contract app on their server. So that's kind of the difference between two existing HAF apps.
The operator has to explicitly install it, whereas if they install the smart contract app, then all the smart contracts that get created in the future will automatically run on their server.
This will allow project teams who access that HAF node to use any smart contract that is created using the application. There is no need to either develop it oneself or search around to find what is needed. If it is created in the smart contract application, all nodes that have it installed will get the newer versions of contracts.
Here we see one smart contract platform that is being considered. There is at least one more in development. By the end of the year, developers will likely have a couple of choices to find what they need.
This is going to bring some important functionality to Hive. One of the big ones is the ability to create second layer tokens. This can be either fungible or non-fungible (NFTs). Of course, that opens the door for other applications such as NFT stores. Communities will be able to generate their own token, catered to suit their needs. Unlike the Smart Media Token idea of the past, these will not have to be Proof-of-Brain, although they can be. Project teams can create whatever suits them.
Like always, it is easy to overlook Hive because we are building a lot from the ground up. However, technology does matter and when we see how Hive approaches things versus, say, an Ethereum, there is a major difference. It is taking longer since a lot of infrastructure is required and the number of hands laying out code, proportionately speaking, is small. Nevertheless, we are forging ahead, implementing new layers that have mass appeal. Obviously, the content in this article details how this is targeting the developer world.
Again, we must stress this is only in the planning stage. There is still more HAF work to be completed. However, keep an eye out for the smart contract update as part of a large development road map. We should hear something by the end of the quarter.
If you found this article informative, please give an upvote and rehive.
gif by 
logo by 
