Hedera Native Smart Contracts #693
Replies: 10 comments 20 replies
-
|
Just nothing the need for supported tooling, custody solutions, oracles etc who would need to comply with the new approach or be provided with a service like Hashio to make the compatibility possible. Can we call out the problems this approach will solve? Eg lower cost, high throughput operators etc. |
Beta Was this translation helpful? Give feedback.
-
|
Would I be correct in saying the idea is pretty much identical to how smart contracts work on Near network? If so would forking Near's runtime layer not be the simplest way to get this implemented? Additionally, programmatic interaction with the HFS, HCS and HTS can be enabled via a precompile contract similar to how this was achieved on the HSCS. Could you clarify gas limits, gas costs and gas prices relative to the HSCS? In addition, how would resources(memory, compute) be distributed between both smart contract services and if throttling is required how would that would work? |
Beta Was this translation helpful? Give feedback.
-
|
I very much like this idea and appreciate the links! I'll research this more deeply over the weekend. I agree, some patterns are already introduced and executed for HSCS from setting an account PK for a Contract Id to ability to recompile native services for processing. I don't have a defined structure of gas costs at this stage as this discussion was meant to see the want of the community for a solution that could accommodate this. I will work on this,setting up a chart that matches gas / cost points of HSCS and the differences. |
Beta Was this translation helpful? Give feedback.
-
|
all the points you've mentioned in here have been done and accomplished by our technology, the Smart Nodes. Creating a new virtual machine implies a lot of steps, development power, and costs, this is why i would definetely vote against it. EVM exist since decades now, and even if I don't like the approach of smart contract myself, I must admit EVM is very solid and it's been secured during those decades. If an attack like the one we've seen in those days can still happen on smart contract, do you imagine what could happen if you develop a brand new HVM? there could be any kind of Operating System attack there, from chroot to heap overflow, or whatever else. IMHO the best solution would be to converge our strenght and power by teaching our community one simple thing: all you need is HCS, HFS, HTS. If you want to add a layer on top of them to oversimplify their usage and speed up the development, we've done this already. let's join our strenght and development power, we're open to any collaboration, but please let's avoid keep wasting time, energy and money into bulding something which would just add a layer of risk without any real advantage at all. |
Beta Was this translation helpful? Give feedback.
-
|
@HbarSuite you haven't explained how the security offered by a Smart Nodes network would be comparable to that offered by the core Hedera network. My understanding is that a Smart Nodes network is basically another network that is responsible for its own security internally and is also dependent on the security of Hedera itself, so it will always be less secure than Hedera.
A smart contract is ultimately just code, so you're essentially saying code is obsolete? A plugin running on a Smart Node network is not much different from a smart contract. |
Beta Was this translation helpful? Give feedback.
-
|
I think what @mshakeg is attempting to get at is no matter all the bells and whistles that are added to @HbarSuite nodes it will always inherit all the security (good or otherwise) and benefits from hedera, as it is effectively acting as a L2, working to toward developer accessibility is a wonderful direction but the risk here is that your treasury/council members just need to collaborate together to switch off their docker images to halt the L2 due to the community multisig approach. This proposal from @HGraphPunks has similarities to what HSuite offer but with the guarantees at L1, where the nodes. There might be some collaboration opportunities between the both of you. |
Beta Was this translation helpful? Give feedback.
-
|
@mshakeg i'm not saying "code is obsolete", i'm instead saying the technology of a smart contract is obsolete. SmartNodes are able to offer a totally isolated environment, which can't NEVER affect the integrity of the main-chain itself, and it will also NOT put any overload on it like contracts does. At the same time, SmartNodes are able to let you setup your own machine for few dollars (each of our node run on 7$/month bill), and you can use plenty MORE resources in terms of RAM, bandwith, data storage, and less but not least you can interact with all the outside world even in a cross-chain way, with no limitations at all. @mattsmithies you're totally wrong with your sentence: we are going to be fully permissionless and trustless in few months, even if hedera is NOT. In simple words, our 8 smartnodes governed by us and the councils, will ONLY hosting our core engines (DAO, DEX, NFT-DEX, etc). Any plugin developed by the community will be hosted onchain using HFS either on the 100 community node starting from mid-2023, either on your personal node starting from end-2023. This basically means: if you want to be totally decentalised, you can host your plugin code into the 100 community nodes (each of them hold 1 signature, and each wallet used with smart-node powers is a multisig with 100 signatures and 60% of threshold). If you instead prefer NOT to trust the community nodes, OR to have full control you will be able to setup as many nodes as you wish, host your plugin souce code ONLY into your nodes, so you will hold ALL the keys in your team/council or any signature model you want to put in place. Every node of the network will be able to remotely execute the code itself and also to validate the bounty of each tnx interacting with it, but only your nodes will be able to sign cause only them have the keys in this case. So it will be enough to flag a plugin as "unsecure" to prevent the whole network from interacting with it, or also the plugin's owner can turn off his own machines directly. With no signatures, there is no transactions. This structure allow us full flexibility, while we keep not only the rest of the network secure, but we also keep it online and fully operative, something Hedera wasn't even able to do so on a native layer. Hope this clarify your questions. |
Beta Was this translation helpful? Give feedback.
-
|
@HbarSuite As I mentioned before your project is going in a wonderful direction for developer accessibility, and that your insight could be useful to collaborate with this proposal. Now, when we say that HSuite is an L2, we're pointing out that you inherit the security from Hedera. This isn't a bad thing, see polygon, optimism, metis etc. If the network becomes inaccessible so do you. Unless you've significantly changed your infrastructure HCS is used as a message bus so that nodes can follow and sign the state of the HSuite network. |
Beta Was this translation helpful? Give feedback.
-
you're totally right with this: if the network becomes inaccesible so do we. This is why, imho, instead of focusing now on developing a native layer for contracts, i would rather make an urgent effort and fully isolate the EVM/contracts from the rest of the network. Also the idea of porting from NEAR suggested by @mshakeg is interesting, still makes me wonder how big the effort will be in terms of making it compatible, and even more: how big is the risk to ignore some flaw or vulnerability in precompiled scripts, so to avoid risks of exploits. We all know security risks will aways be there, but let's be honest: if ever we should focus on creating our own virtual machine for native hedera contracts, we shall keep in mind that this will cost us plenty of money, plenty of audit needed, and eventually even a native language which won't be Solidity after all. Not to mention the fact that should be fully compatible with all other contracts so to facilitate portability and such. So final question is: is this effort in terms of time/money truly needed? |
Beta Was this translation helpful? Give feedback.
-
|
I do think that having a trustless layer that is native to Hedera is necessary since Hedera is not a blockchain and in whatever way it is when transforming a code from a blockchain to hashgraph will always have its own vulnerabilities. If we can achieve this without the need of creating a virtual machine would be amazing. Creating a Hedera Virtual Machine for this sounds costly in both energy consumption and fee and may affect the speed of the network reaching consensus. |
Beta Was this translation helpful? Give feedback.
-
|
The idea of having another trustless layer of execution which is native to Hedera, could enable engineers from many walks of life to participate in creating decentralized applications without needing to learn Solidity, and perhaps at a higher TPS than the EVM layer currently can handle. I am all for something like this, however, it would be great to see an architecture diagram (through UML) that clearly denotes each service and how they interface with one another. @HGraphPunks would you be able to include that in your proposal? |
Beta Was this translation helpful? Give feedback.
-
|
I'm taking notes of requests from the proposal and will work ok on getting them created to help push the discussion forward. I appreciate you taking time to provide your feedback! |
Beta Was this translation helpful? Give feedback.
-
|
Cross-posting from slack Interesting idea, in the same vain I’ve postulated/experimented that storing composable units of code in HCS message in a terse language such as clojure combined with a defined schema for composition could be useful in helping build out a Lego of reusable code blocks where the author could be paid per “HVM” execution cycle. For this additional outcome like this to occur HVM or similar would need to happen. However, due to the large scope and risk of securitization/compliance implications it’s going to be curious to see the reaction. Ultimately, if this did fail to pass would the idea be to create an L2 (similar to HSUITE - I believe the ideas are similar) that could drive to same outcome? |
Beta Was this translation helpful? Give feedback.
-
This sounds very similar to what Radix is trying to do with scrypto modules/packages; however, imo the economics of this concept only makes sense for contracts that store data that is frequently updated and hence can't be easily replicated without incurring the frequent transaction costs of the original contracts(for example oracle contracts. Why deploy your own oracle contract/s for your dApp and incur the same transaction fees as a Chainlink oracle contract, when your dApp can be one of many dApps that simply use a Chainlink oracle and essentially pay a fraction of the operating expenses of that shared oracle). Whereas for static contracts/libraries anyone can simply fork and deploy their own contract to avoid having to pay a call fee to the author. Also, the EVM already allows for "storing composable units of code ... for composition". |
Beta Was this translation helpful? Give feedback.
-
|
Worth mentioning that I was experimenting with this around 2 years ago before contracts, let along HTS was a thing on the network. |
Beta Was this translation helpful? Give feedback.
-
|
Personally based on spirit/philosophy, I think this is the wrong direction... I'd want more industry compatibility, not less. Additionally, Hedera has plenty to worry about in their roadmap (when can I run a node? when is sharding implemented? when will we get better dev tools? there's no clarity on these things after 4-5 years...) & this seems to be a total distraction from genuine decentralization, especially when you already have the tools available to write logic on-chain. Plus, if you truly wish to build your own execution env, use HCS & push Hedera to get a bridge/interface from HCS to other services - that is what it was built for. |
Beta Was this translation helpful? Give feedback.
-
|
I very much appreciate you providing your insight on this HIP given your background and knowledge on the subject <3 Here's some of my thoughts and ideas on why HVM is a good idea.
I fully agree here, and I think the industry and developers we're targeting with EVM aren't aligned with the value add of the Hedera eco-system. Even after convincing a solidity dev to adopt Hedera, theres a field of nuance that they'll have to understand and comply with to fully get the value of using Hedera.
My counterpoint: JavaScript developers are used to interacting with data like you can on Hedera, the speed replicates their understanding of web 2 technologies, and giving them the tools to execute complex web3 logic like a HVM would allow a smooth onboarding process for a massive amount of industries whose developers don't need to learn a new language to get the full benefits of Web3.
Can you elaborate on how HCS can trustlessly execute any transaction without EVM? or the idea you're trying to convey here in more detail? The main point of this HIP is not to overcomplicate the structure of Hedera, but rather empower people who don't know solidity be able to create trustless contracts / execution natively. This is my first idea on that path but am open to any solution that could use the services together for a DEX, with people being able to audit the logic and not have to trust the developer.
Though HCS could be present in other services, the lack of ability to execute all of that code trustlessly for a DEX or launchpad still persists, which is the issue I hope we can solve. Unless I'm missing the functionality you're describing. I appreciate your feedback and I'm enjoying the discussion :) |
Beta Was this translation helpful? Give feedback.
-
|
I will respond to this comment, as I think it's most productive, but happy to circle back to others if you see value -
Generally, my understanding of the intention of the Hedera Consensus Service was to use it as an ordering service/part of a block producer, or even a sequencer - speaking in reference to how they're now commonly known in the L2 space - and use that as part of an architecture to build whatever kind of network you want, including a potentially permissionless one. Initial examples and demos were built with hyperledger fabric, but you could use a lot of different architectures, potentially even a fork of the Hedera codebase (cc @jsindy for potential insights here). Only thing not yet covered/discussed within in the HCS appnet model to satisfy my understanding of your goals would be a mechanism to get post-execution data back on-chain, ala a rollup, or something similar (to give you a mental model), depending on the hypothetical interface between HCS <> other services (note: which unlike ethereum based l2's isn't necessarily required for security, as you can trust the hcs stream, but could be helpful for interservice composability). Further reading/watching that comes to mind - Understanding l2 ordering and execution In my mind, this is also begging the question of sharding. Do all shards run the same codebase/EVM? I believe at one point it was discussed that each shard could have slightly different requirements and/or even execution envs.. but maybe I'm misremembering 🤷 If that is the case, then perhaps what you're looking for is a unique shard for your specific, custom virtual machine. |
Beta Was this translation helpful? Give feedback.
-
|
Replying to this comment.
Can you explain how? Metamask(ECDSA accounts) users are able to send and receive HTS tokens to and from other accounts on the Hedera network and vice versa(the hashgraph/sdk supports EVM addresses). ECDSA accounts can also associate/dissociate/etc with tokens via the precompile contract.
I disagree with this. The Hedera JSON RPC Relay allows for a familiar experience to other EVM-compatible chains.
Can you elaborate on what the Hedera EVM is lacking? As far as I can tell it's capable of everything EVMs on most if not all major EVM-compatible chains are.
How is this something particular to the EVM on Hedera? If anything the EVM is likely more performant on Hedera than other networks which have substantially larger networks. |
Beta Was this translation helpful? Give feedback.
-
Yes, this is true. EVM wallets will be able to view both ERC and HTS tokens. All HTS tokens can be treated as ERC tokens by converting the token id into a solidity address using the
If contract state is queryable via the json-rpc relay and the mirror node at no cost, then this is perfect. However, if a ContractCallQuery or ContractExecuteTransaction must be executed to read contract state, then that is expensive. This is an enhancement that can be made to the mirror-nodes and json-rpc to resolve.
The Hedera EVM does appear to be the most scalable of all networks. Although it seems that the Hedera EVM's TPS is limited by gas limits. I believe these can be increased and scale as the network continues to spin up new nodes from the GC or community. However, a core dev is more qualified to speak on this. |
Beta Was this translation helpful? Give feedback.
-
@HGraphPunks I think you should copy the 3 bullet points right after this line + the counterpoint into the main HIP (edit the 1st message in this discussion) |
Beta Was this translation helpful? Give feedback.
-
|
For any DLT, it is important to consider short and long term adoption. Programming LanguagePopularity
Let's take a look at the Stack Overflow Developer Survey for 2022.
You see similar figures for developers who are learning to code as well. Talent PoolThe talent pool for any language: JS, Python, Java, and C# is much larger than the talent pool for Solidity. SecurityIt is important to consider why Solidity was created in the first place:
Solidity had all the above in mind for its creation. And these are still common, but solved problems for the most popular languages. Talent QualityWe should also consider experience levels of Solidity developers. Because Solidity was designed with DLT-specific security features in mind does not mean there are no security risks. Experienced software engineers can navigate and introduce proven patterns and security practices into the DLT ecosystem, but have a hard time entering the DLT ecosystem due to the friction of developing on the EVM, learning Solidity, Oracles, json-rpc, etc. Use casesMost popular applications are built on JS, Java, C#, Python, Ruby, etc. While there are some popular applications build on the EVM, they are not at the scale of Facebook Marketplace, Youtube, VISA/MasterCard, Stripe, Discord, etc. Building an HVM to support the languages that massive use cases have been built on does not mean Hedera would gain massive adoption, but it does mean that the barrier for entry for developers of massive use cases will be able to on-board and experience the benefits of DLTs more easily. Consider the HVM as a way to bring high quality talent into the DLT space and accelerate it's growth. Only 1.52% of experience devs know Solidity. They are not likely to experiment with a new language, APIs, and concepts to prove a novel idea. But they are much more likely to explore a new API, library, or runtime using their language of choice. For many developers, the concept of building trustless, serverless, scalable code with a built-in audit-able database is very appealing, but the barrier to entry is very high. Please consider what a low barrier to entry trustless code execution platform could do for Hedera's adoption rate. |
Beta Was this translation helpful? Give feedback.
-
@pwoosam one issue with JS is that it doesn't compile to any executable binary or virtual machine bytecode, AFAIK. |
Beta Was this translation helpful? Give feedback.
-
|
@bguiz JS can compile to WASM, but projects like AssemblyScript that use a subset of a language probably generate more efficient bytecode. Although compiling to executable binary or virtual machine bytecode may not be necessary for a code execution environment. Code could be compressed and stored on-chain, then be executed by a serverless runtime by AWS lambda or in specialized docker containers. |
Beta Was this translation helpful? Give feedback.
-
|
Javascript probably has high popularity because there are not a lot of choices here. I think that list might be biased. |
Beta Was this translation helpful? Give feedback.
-
|
@HGraphPunks I'm re-reading this (several months later), and have more thoughts:
One of the things that I think would make it worth the effort of building and maintaining One specific limitation of the EVM that severely limits what kinds of applications are able to be built on it If say, we were not limited to using HFS to store key-value pairs, Within the Hedera-native version of HSCS that you are proposing, |
Beta Was this translation helpful? Give feedback.
-
|
@HGraphPunks apart from language popularity, another rather important factor to consider is addressing one of the fundamental problems with EVM/ Solidity, which is that is is quite hard to audit. Picking a target language (or multiple target languages) that lend themselves to formal verification techniques would be ideal. That being said I'm not sure if there are any languages that lie in the intersection between these 2 requirements.
|
Beta Was this translation helpful? Give feedback.
-
|
I like the direction you're going, but rather than thinking about auditing think instead about being able to only write correct contracts. As in, a smaller language backed by a theorem prover, with syntax constructs and a library both amenable to proving the kinds of theorems that are totally relevant to a smart contract: behavior depending on the existence or amounts of certain things, on various forms of authorization, and with protections against concurrency issues; where you declaratively state what needs to be true when the contract runs (you remember from C.S. classes: preconditions, postconditions, invariants). This is strictly my opinion - and I don't know how to do it the way I'm suggesting (though other people are working on it and even have results in production): But auditing is something you do after you've written bad code, in a too-flexible language, in order to hopefully detect all of your inevitable errors, and that's a losing proposition. IMO. |
Beta Was this translation helpful? Give feedback.
-
Overview:
This is the initial discussion starter to conceptualize the future of native hashgraph smart contracts. I believe the future of smart contract execution on Hedera is the combination of the 3 native Hedera services being used in conjunction together to do trustless execution of complex logic.
Objective:
Create methods of trustless execution of logic on Hedera that is native and does not require developers to learn solidity or use EVM smart contracts.
Initial Idea:
Here's the initial thoughts on how the three services could be used together to achieve this outcome.
Hedera File Service
Hedera Consensus Service
Hedera Token service
Ramifications:
I imagine there are many ramifications with this idea and I’m looking forward to discussing the benefits and costs of how Hedera Native Smart Contracts could be achieved. Here are the two major updates I think this functionality would require.
HVM (Hedera Virtual Machine):
This HIP introduces Hedera Virtual Machines to process Hedera Native Smart Contracts. Just like EVM processes logic and executes transactions onto a blockchain, HVM would be needed to process the logic of the contracts and post native Hedera transactions to the mainnet through the other Hedera services.
HVM would allow the nodes that currently exist to not have to support the memory execution of the logic as well as the network. Fees for execution would go to operators of the HVM.
Initial thoughts and discussions with developers, HVMs could use WASM to execute the contracts for mass compatibility.
File Service Extension
The current length of files in the file service are restricted to a certain length and size. This will need to be updated to allow bigger files to be stored. The rent and cost of execution should be defined by the length of the file like how SC currently work through EVM.
Last Thoughts:
I believe the future of hashgraph technology can be obtained by focusing on the extension and development of Hedera native services to best execute application logic needed for block chain parity today, and innovation in Web3 tomorrow.
The ability for Hedera only devs to create native trustless execution logic will bring a new frontier to the Web3 space and be a path to innovation that building on Hedera provides.
Beta Was this translation helpful? Give feedback.
All reactions