Smart contracts side chain

[Troglodactyl]

If smart contracts are integrated into the block validation process, then they absolutely do impact performance.  It's possible we'll have enough spare resources to run them anyway, but once we start pushing the limits they will drive up transaction costs relative to what they'd be if smart contracts were handled otherwise.

I think smart contracts could be handled more efficiently outside chain validation by multisig.  You could create a smart contract with a distributed set of executors in a multisig account, and they all have to agree on how each action of the contract is executed.  The executors could be the dynamic set of witnesses if there's really that much demand for that.  Decoupling smart contracts from chain validation this way gives both the potential of higher performance, and provides greater flexibility to the smart contract security model.  Some people may be willing to pay for more redundancy/decentralization in their smart contract execution than others have any need for, and this model allows that.

   Excellent. Much better way of decoupling than a full side chain (it removes the complexity, but it achieves similar result). How do you envision the interaction between contracts and block chain, event triggering, etc?

Since the executors would be defined through a multisig account, events could be triggered by anything upon which that group could be expected to reach consensus.  Obviously that includes any blockchain condition being met, but it's a lot more flexible than that.  When each executor detects a triggering condition being met, he either creates the appropriate multisig transaction or adds his signature if another executor has already created it on the blockchain.

...

This could work well in many instances I agree.... there are some instances however where if the smart-contract requires an audit of conditions that it would need to exist entirely within the blockchain.. in which case a sidechain might be appropriate.

However for most instances an external app interfacing with the bitshares network to execute on certain conditions might be just fine.

Man.. thinking about all the development possibilities just leaves me amazed!

Can you give an example of why a contract would have to exist within the blockchain?

[BunkerChainLabs-DataSecurityNode]

If smart contracts are integrated into the block validation process, then they absolutely do impact performance.  It's possible we'll have enough spare resources to run them anyway, but once we start pushing the limits they will drive up transaction costs relative to what they'd be if smart contracts were handled otherwise.

I think smart contracts could be handled more efficiently outside chain validation by multisig.  You could create a smart contract with a distributed set of executors in a multisig account, and they all have to agree on how each action of the contract is executed.  The executors could be the dynamic set of witnesses if there's really that much demand for that.  Decoupling smart contracts from chain validation this way gives both the potential of higher performance, and provides greater flexibility to the smart contract security model.  Some people may be willing to pay for more redundancy/decentralization in their smart contract execution than others have any need for, and this model allows that.

   Excellent. Much better way of decoupling than a full side chain (it removes the complexity, but it achieves similar result). How do you envision the interaction between contracts and block chain, event triggering, etc?

This could work well in many instances I agree.... there are some instances however where if the smart-contract requires an audit of conditions that it would need to exist entirely within the blockchain.. in which case a sidechain might be appropriate.

However for most instances an external app interfacing with the bitshares network to execute on certain conditions might be just fine.

Man.. thinking about all the development possibilities just leaves me amazed!

[betax]

If smart contracts are integrated into the block validation process, then they absolutely do impact performance.  It's possible we'll have enough spare resources to run them anyway, but once we start pushing the limits they will drive up transaction costs relative to what they'd be if smart contracts were handled otherwise.

I think smart contracts could be handled more efficiently outside chain validation by multisig.  You could create a smart contract with a distributed set of executors in a multisig account, and they all have to agree on how each action of the contract is executed.  The executors could be the dynamic set of witnesses if there's really that much demand for that.  Decoupling smart contracts from chain validation this way gives both the potential of higher performance, and provides greater flexibility to the smart contract security model.  Some people may be willing to pay for more redundancy/decentralization in their smart contract execution than others have any need for, and this model allows that.

   Excellent. Much better way of decoupling than a full side chain (it removes the complexity, but it achieves similar result). How do you envision the interaction between contracts and block chain, event triggering, etc?

[Troglodactyl]

If smart contracts are integrated into the block validation process, then they absolutely do impact performance.  It's possible we'll have enough spare resources to run them anyway, but once we start pushing the limits they will drive up transaction costs relative to what they'd be if smart contracts were handled otherwise.

I think smart contracts could be handled more efficiently outside chain validation by multisig.  You could create a smart contract with a distributed set of executors in a multisig account, and they all have to agree on how each action of the contract is executed.  The executors could be the dynamic set of witnesses if there's really that much demand for that.  Decoupling smart contracts from chain validation this way gives both the potential of higher performance, and provides greater flexibility to the smart contract security model.  Some people may be willing to pay for more redundancy/decentralization in their smart contract execution than others have any need for, and this model allows that.

[betax]

I think smart contracts should be part of the main chain if they can be implemented in an efficient way ..
Turing Complete Scripting may be a different thing though ..

Yes that is my point, if a side chain can interop with a fast chain (Bitshares 2.0), the side chain, slower / non priority with (Non very performant smart contracts, turing complete. low priority transactions), this will be great.

This is a bad idea.

1) Smart contracts, debate whether or not it should be Turing complete or decidable as a design consideration.
2) If Bitshares 2.0 is scalable, the smart contracts will be too.
3) Create a market for computation, storage, etc, with a DHT. It doesn't have to be a side chain and makes no sense why you think it would.

So you can sell storage space to the Bitshares 2.x, or sell computation, and if you do it this way you can eventually evolve Bitshares into a decentralized computer.

Ethereum is attempting to do that, and over time Bitshares could evolve down the same road, but for now in my opinion the developers should tread carefully on smart contracts because the design of it is not trivial.

Turing complete seems to not work as well as we thought it would looking at Ethereum, and also the security implications. Ethereum requires you to secure it by isolation, virtual machines, sandboxes, etc. The other way to secure it is by correctness, where every smart contract is a formal proof, and verified. In that case you can do distributed computation safely because you can verify with certainty that the code is correct, with no bug.

Sandboxes and virtual machines sometimes can leak, and they are slow. Additionally random numbers and HPC as far as know cannot be done on virtual machines.

An authenticated data structure (ADS) is a data structure whose operations can be carried out by an untrusted prover, the results of which a verifier can efficiently check as authentic. This is done by having the prover produce a compact proof that the verifier can check along with each query result. ADSs thus support outsourcing data maintenance and processing tasks to untrusted servers without loss of integrity. Past work on ADSs has focused on particular data structures (or limited classes of data structures), one at a time, often with support only for particular operations. This paper presents a generic method, using a simple extension to a ML-like functional programming language we call lambdaAuth with which one can program authenticated operations over any data structure constructed from standard type constructors, including recursive types, sums, and products. The programmer writes the data structure largely as usual; it can then be compiled to code to be run by the prover and verifier. Using a formalization of lambdaAuth we prove that all well-typed lambdaAuth programs result in code that is secure under the standard cryptographic assumption of collision-resistant hash functions. We have implemented our approach as an extension to the OCaml compiler, and have used it to produce authenticated versions of many interesting data structures including binary search trees, red-black trees, skip lists, and more. Performance experiments show that our approach is efficient, giving up little compared to the hand-optimized data structures developed previously.

https://amiller.github.io/lambda-auth/
https://amiller.github.io/lambda-auth/paper.html
https://docs.google.com/presentation/d/1Ycqpsm6an-jvQk3SEHB130JlyGiWJEDZ7Zj-eVMe3ss/edit#slide=id.g2a22b5644_00

Very good and valid points,  let's park this as is not a priority focus for discussion.

[luckybit]

I think smart contracts should be part of the main chain if they can be implemented in an efficient way ..
Turing Complete Scripting may be a different thing though ..

Yes that is my point, if a side chain can interop with a fast chain (Bitshares 2.0), the side chain, slower / non priority with (Non very performant smart contracts, turing complete. low priority transactions), this will be great.

This is a bad idea.

1) Smart contracts, debate whether or not it should be Turing complete or decidable as a design consideration.
2) If Bitshares 2.0 is scalable, the smart contracts will be too.
3) Create a market for computation, storage, etc, with a DHT. It doesn't have to be a side chain and makes no sense why you think it would.

So you can sell storage space to the Bitshares 2.x, or sell computation, and if you do it this way you can eventually evolve Bitshares into a decentralized computer.

Ethereum is attempting to do that, and over time Bitshares could evolve down the same road, but for now in my opinion the developers should tread carefully on smart contracts because the design of it is not trivial.

Turing complete seems to not work as well as we thought it would looking at Ethereum, and also the security implications. Ethereum requires you to secure it by isolation, virtual machines, sandboxes, etc. The other way to secure it is by correctness, where every smart contract is a formal proof, and verified. In that case you can do distributed computation safely because you can verify with certainty that the code is correct, with no bug.

Sandboxes and virtual machines sometimes can leak, and they are slow. Additionally random numbers and HPC as far as know cannot be done on virtual machines.

An authenticated data structure (ADS) is a data structure whose operations can be carried out by an untrusted prover, the results of which a verifier can efficiently check as authentic. This is done by having the prover produce a compact proof that the verifier can check along with each query result. ADSs thus support outsourcing data maintenance and processing tasks to untrusted servers without loss of integrity. Past work on ADSs has focused on particular data structures (or limited classes of data structures), one at a time, often with support only for particular operations. This paper presents a generic method, using a simple extension to a ML-like functional programming language we call lambdaAuth with which one can program authenticated operations over any data structure constructed from standard type constructors, including recursive types, sums, and products. The programmer writes the data structure largely as usual; it can then be compiled to code to be run by the prover and verifier. Using a formalization of lambdaAuth we prove that all well-typed lambdaAuth programs result in code that is secure under the standard cryptographic assumption of collision-resistant hash functions. We have implemented our approach as an extension to the OCaml compiler, and have used it to produce authenticated versions of many interesting data structures including binary search trees, red-black trees, skip lists, and more. Performance experiments show that our approach is efficient, giving up little compared to the hand-optimized data structures developed previously.

https://amiller.github.io/lambda-auth/
https://amiller.github.io/lambda-auth/paper.html
https://docs.google.com/presentation/d/1Ycqpsm6an-jvQk3SEHB130JlyGiWJEDZ7Zj-eVMe3ss/edit#slide=id.g2a22b5644_00

[luckybit]

Impact on performance,  in the same way that it might affect scalability of Ethereum.  But if anybody tell me that we can do the 100k transactions, including smart contracts (EVM style) then awesome

Smart contracts don't impact performance. It depend so on your design but the problems with Ethereum isn't because of the smart contracts.

The main issue or question is whether Bitshares 2.0 and beyond should go with Turing complete smart contracts, or decideable smart contracts. Ethereum is really the first attempt at it, and like with Bitcoin there may have been certain design decisions which don't pan out as intended. Bitshares is in a position to learn from these mistake.s

Side chains don't make much sense unless you can give a reason why you need to use one for that purpose. How do you think smart contracts will hurt Bitshares performance? If it costs computing resources then make a market for those resources.

[betax]

I think smart contracts should be part of the main chain if they can be implemented in an efficient way ..
Turing Complete Scripting may be a different thing though ..

Yes that is my point, if a side chain can interop with a fast chain (Bitshares 2.0), the side chain, slower / non priority with (Non very performant smart contracts, turing complete. low priority transactions), this will be great.

[betax]

Impact on performance,  in the same way that it might affect scalability of Ethereum.  But if anybody tell me that we can do the 100k transactions, including smart contracts (EVM style) then awesome

[xeroc]

I think smart contracts should be part of the main chain if they can be implemented in an efficient way ..
Turing Complete Scripting may be a different thing though ..

[luckybit]

Why does it make sense to have a side chain for smart contracts?

[betax]

Bitshares 2.0 is all about performance, and robust contracts. We don't want to pollute or slow down the main chain, with random contracts. BUT is it possible to have a side chain (slower) which is dedicated to smart contracts? This side chain can communicate with the main chain to do simple operations (create asset, issue asset, transfer, etc).