We have a fantastic opportunity for developers to see what we’re made of. We have teamed up with JetBrains to bring you this killer giveaway right here! That’s right, come build with us and deploy your DApp on the Hypothesis Testnet and enter to win a 1-year subscription to any JetBrains IDE of your choosing! This is up to a $500 USD value!! Don’t miss out, the offer is only going to be available for a limited time!!!
This week we added an array of walk-throughs to the developer page of our website that developers can use to perform various functions on the Helios Protocol Hypothesis Testnet. In the first example below, we show how to take Solidity code from Ethereum, deploy, and use on the Helios Protocol platform. This example shows it is simply copying and pasting the code, unmodified. In the second example, two new walkthroughs were added to easily show how to deploy your Smart Contract and interact with it on our platform. Come develop with us. It’s so easy to migrate, a CaptainCaveDann could do it!
https://heliosprotocol.io/developer/ethereum_solidity_example_voting.html https://heliosprotocol.io/developer/walkthroughs.htmlThere are two things you need to understand about Helios Protocol before we can explain what we added to the code this week:
1) On Helios Protocol, every smart contract and wallet has its own chain. Communication between these chains is achieved through transactions from one chain to another. Smart contracts can send a transaction to call a function on another smart contract. Because this process requires sending and receiving a transaction, the contract that sent the transaction cannot immediately see the result of the function that it called on the other chain.
2) Helios Protocol has a unique new feature where a transaction can specify which smart contract it would like to execute, or the code address. Unlike Ethereum, this means a transaction with data doesn’t necessarily need to execute the code stored the chain it is being sent to. You can send a transaction with data from chain A to chain B, while executing code from chain C. But the question arises: what chain state, or storage address, will the smart contract execution use? The answer: it will always use the storage and state on whatever chain the transaction lives on. If it is the send part of the transaction in this example, it will use the storage on chain A. If it is the receive part of the transaction, it will use the storage on chain B. However, in order to stop smart contracts from being able to overwrite and modify the storage of another smart contract, each external smart contract gets its own isolated storage on each chain. In our example, chain A will have a special isolated storage specifically for smart contract C, but it will still be contained in the state of chain A.
This week, we implemented this:
There is an OPCODE called STATICCALL. On Ethereum, this opcode allows you to call another smart contract in read only mode, use the storage of that smart contract, and get the result of the computation. But as we mentioned in 1), if a smart contract wants to do this, it has to wait for the transaction to send and receive and therefore cannot get a result back immediately. However, recall from 2), that the external smart contract actually has its own isolated storage on this chain too. Thus, we have modified STATICCALL to allow a smart contract A to call smart contract C, and use the isolated storage of C, contained within its own chain, in read only mode. The end behavior of this is exactly the same as Ethereum, except it uses a different storage location.
We also added ability for send transaction computations to create new computation call transactions. Made a recursion limit of 20 to stop infinite loops that fill the block with infinite transactions.