Smart contracts would be very cool to have in my opinion. This thread is to discuss their implementation.
Here are some ideas I’ve come up with while researching smart contracts on blockchains:
- We should run the EVM. (maybe the JVM also? see Lisk)
- We can’t run them on the current chain.
- Smart contracts need to store state. With the UTXO architecture, we can’t do this.
- Two options here: fork and come up with a completely new blockchain (no privacy, masternodes, etc.) or use a two-way peg system where users can move their PHR between two different chains.
Two-way pegging works by creating two different chains. One for smart contracts and one for UTXOs, privacy, etc.
If a user wants to switch from the main chain to the side chain,
- Add an
OP_LOCK to their transaction on the UTXO chain. (
NOP on older clients for soft fork)
- They then sign a message with their private key and submit it to the smart contract chain. (for free?)
- The smart contract verifies the signed message and the transaction on the main chain, then credits the user the same amount of PHR on the smart contract chain.
If a user wants to switch from the side chain to the main chain,
- The user sends some PHR and their main chain address to the pegging contract.
- They provide proof of this transaction on the main chain.
- The main chain unlocks the amount they want.
a. This may cause problems because we don’t want to unlock the entire output in case the amount is less than the output.
Unfortunately, proof of stake makes it difficult to submit a proof of lock transaction to the smart contract chain. We’ll have to use a more creative solution (possibly using masternodes) to achieve this two-way peg. Below, I’ve outlined my ideas on how we can make this work in PoS.
Smart Contract Network Validation of Proof of Lock
We can write a smart contract to validate the proof of lock on the main chain by sending every block from the main chain to the side chain as soon as it has more than 32 children.
This would require an attacker to mine 32 out of the last 32 blocks to compromise the side chain. If they controlled 50% of the coins on the network, they would have a 2^-32 chance of accomplishing this attack.
The side chain keeps track of the current blockchain state. When a miner mines a PoS block, they receive [half of their reward on the main chain and half on the side chain?].
The side chain smart contract can then validate any blocks that were sent to that chain including only block headers (which include the merkle hash).
When a user wants to move chains from the main chain to the side chain, they sign a message with their main chain private key including the transaction hash of the locked coins and the merkle path for the smart contract to verify. This allows relatively small proof of lock transactions to be sent to the side chain.
When they want to move their coins back to the main chain, they provide proof of the transaction on the side chain including a certain number of block headers proving a certain amount of work was done on their transaction. The main chain then verifies this and allows them to spend the locked UTXO.
One problem with this is that it shouldn’t allow them to spend all of the UTXO. Something more will have to be added to the consensus protocol.
If you have any ideas, please comment below and I’ll add it to the specification.