ethereum is android vs Graphene is Ios Comparison

[VoR0220]

Graphene can be made programmable while retaining the features that make it fast. For most contracts the necessary language restrictions would not be a problem. For the few where it does, you just have to hard fork.

I think this is both a good thing and a bad thing. The dynamism is excellent. The lack of the trustlessness is what will keep Ethereum in competition.

I'd say the opposite is true. Non of the these systems are trustless. Industry professionals in the payment and exchange industry don't want "trustless" systems where transactions are processed by anonymous entities. In this way Ethereum is not really a competitor. I think that both Bitshares and Ethereum are catering to different markets.

would you mind elaborating?

[clout]

Graphene can be made programmable while retaining the features that make it fast. For most contracts the necessary language restrictions would not be a problem. For the few where it does, you just have to hard fork.

I think this is both a good thing and a bad thing. The dynamism is excellent. The lack of the trustlessness is what will keep Ethereum in competition.

I'd say the opposite is true. Non of the these systems are trustless. Industry professionals in the payment and exchange industry don't want "trustless" systems where transactions are processed by anonymous entities. In this way Ethereum is not really a competitor. I think that both Bitshares and Ethereum are catering to different markets.

[VoR0220]

Graphene can be made programmable while retaining the features that make it fast. For most contracts the necessary language restrictions would not be a problem. For the few where it does, you just have to hard fork.

I think this is both a good thing and a bad thing. The dynamism is excellent. The lack of the trustlessness is what will keep Ethereum in competition.

[toast]

Graphene can be made programmable while retaining the features that make it fast. For most contracts the necessary language restrictions would not be a problem. For the few where it does, you just have to hard fork.

[twitter]

Hi Bymaster,

do you agree arghag's statement that "We need to hard fork to incorporate the new features" ?

it will be very troublesome if hard fork need to be taken place for each new contract .

 

I do agree that it is more like getting apple to bundle your app in the next iOS release and having all iOS releases require shareholder approval.   It is a much higher barrier to addition than the app store.   

On the other hand, with enough review and testing it shouldn't be that hard to get contracts updated.

[VoR0220]

Every single change set will be relatively small and self contained.

In this commit on a branch I implemented a new smart contract, a payment splitter.

https://github.com/cryptonomex/graphene/commit/c6b848ef18ed80607bfa4e0fde6fbcf38c0f6862

The payment splitter is an object that accumulates payments and once a threshold has been accumulated it divides the proceeds up among several different destinations:
1. another account
2. a market order
3. another splitter (future work)

The code is divided into `operations`, `evaluators`, `objects`, and `indexes`

1. an `evaluator` performs mutations on the blockchain state for a particular `operation`
2. the blockchain state consists of a set of `indexes` on `objects` which can be though of like "tables" and "rows"

So a typical "smart contract" can be thought of as a class

Abstract Example
```

Code: [Select]

class MySmartContract
{
     /// maps to the *_operation structs
     variant  some_operation(  op_field1, op_field2, ... )

     /// maps to the *_object data
     string persistant_data1
     int       persistant_data2
}

/// maps to the *_evaluator
variant MySmartContract::some_operation( op_field1, op_field2, ... )
{

}```

Operations are "decorated" with some meta data such as:
1. required fees
2. required authorities (must be derivable from data in the operation)
3. static validation (independent of chain state)
4. relevant accounts (any account that may have an interest in the operation)

Evaluator's are divided into TWO stages:
1. evaluate - performs invariant and pre-condition checks and ensures the operation is properly formed in light of current blockchain state
2. apply - performs the minimal work to transition the database state and assumes all preconditions are met.

This division between eval and apply allows the blockchain to SKIP evaluate while reindexing and simply apply the state transition.

When does the tutorial for how to go about using smart contracts drop?

[sudo]

Every single change set will be relatively small and self contained.

In this commit on a branch I implemented a new smart contract, a payment splitter.

https://github.com/cryptonomex/graphene/commit/c6b848ef18ed80607bfa4e0fde6fbcf38c0f6862

The payment splitter is an object that accumulates payments and once a threshold has been accumulated it divides the proceeds up among several different destinations:
1. another account
2. a market order
3. another splitter (future work)

The code is divided into `operations`, `evaluators`, `objects`, and `indexes`

1. an `evaluator` performs mutations on the blockchain state for a particular `operation`
2. the blockchain state consists of a set of `indexes` on `objects` which can be though of like "tables" and "rows"

So a typical "smart contract" can be thought of as a class

Abstract Example
```

Code: [Select]

class MySmartContract
{
     /// maps to the *_operation structs
     variant  some_operation(  op_field1, op_field2, ... )

     /// maps to the *_object data
     string persistant_data1
     int       persistant_data2
}

/// maps to the *_evaluator
variant MySmartContract::some_operation( op_field1, op_field2, ... )
{

}```

Operations are "decorated" with some meta data such as:
1. required fees
2. required authorities (must be derivable from data in the operation)
3. static validation (independent of chain state)
4. relevant accounts (any account that may have an interest in the operation)

Evaluator's are divided into TWO stages:
1. evaluate - performs invariant and pre-condition checks and ensures the operation is properly formed in light of current blockchain state
2. apply - performs the minimal work to transition the database state and assumes all preconditions are met.

This division between eval and apply allows the blockchain to SKIP evaluate while reindexing and simply apply the state transition.

awesome

[bytemaster]

I do agree that it is more like getting apple to bundle your app in the next iOS release and having all iOS releases require shareholder approval.   It is a much higher barrier to addition than the app store.   

On the other hand, with enough review and testing it shouldn't be that hard to get contracts updated.   

[bytemaster]

Every single change set will be relatively small and self contained.

In this commit on a branch I implemented a new smart contract, a payment splitter.

https://github.com/cryptonomex/graphene/commit/c6b848ef18ed80607bfa4e0fde6fbcf38c0f6862

The payment splitter is an object that accumulates payments and once a threshold has been accumulated it divides the proceeds up among several different destinations:
1. another account
2. a market order
3. another splitter (future work)

The code is divided into `operations`, `evaluators`, `objects`, and `indexes`

1. an `evaluator` performs mutations on the blockchain state for a particular `operation`
2. the blockchain state consists of a set of `indexes` on `objects` which can be though of like "tables" and "rows"

So a typical "smart contract" can be thought of as a class

Abstract Example
```

Code: [Select]

class MySmartContract
{
     /// maps to the *_operation structs
     variant  some_operation(  op_field1, op_field2, ... )

     /// maps to the *_object data
     string persistant_data1
     int       persistant_data2
}

/// maps to the *_evaluator
variant MySmartContract::some_operation( op_field1, op_field2, ... )
{

}```

Operations are "decorated" with some meta data such as:
1. required fees
2. required authorities (must be derivable from data in the operation)
3. static validation (independent of chain state)
4. relevant accounts (any account that may have an interest in the operation)

Evaluator's are divided into TWO stages:
1. evaluate - performs invariant and pre-condition checks and ensures the operation is properly formed in light of current blockchain state
2. apply - performs the minimal work to transition the database state and assumes all preconditions are met.

This division between eval and apply allows the blockchain to SKIP evaluate while reindexing and simply apply the state transition.

[arhag]

The additional challenge is getting into the code base and then deployed out into the network, which is similar to getting approval in the Apple app store...

I don't like the comparison much because it isn't similar to getting an app approved by Apple into the app store. We need to hard fork to incorporate the new features and that means all the nodes need to upgrade their code. Hard forks aren't supposed to be something we do very frequently because of the inconvenience it places on all full node operators. So I think a more fair comparison is that it is like convincing Apple to include your app as part of their next iOS release.

...with the end result of a highly optimized compiled version of a specific smart contract.  I really like this comparison and it makes it easier for people to conceptualize the different approaches.

In theory we could have fast native code running as sandboxed (using standard Linux process isolation techniques) modules that interact with the blockchain through well-defined APIs and are dynamically upgraded via the blockchain protocol.

I want to make sure we don't confuse two separate issues. Whether the smart contracts run natively, are interpreted, Just-in-Time compiled, Ahead-of-Time compiled at installation/upgrade time, etc. is all a separate issue from whether we allow the smart contract code to be dynamically upgraded (and added and removed) during blockchain operation as part of the protocol or if we require a hard fork for each change.

The latter question is the more important one for us to answer since it requires making trade-offs. I don't think we want anyone's code to just be able to run in the inner (single-threaded) processing loop that native operations run under. This would break our guarantees of 1 second block intervals and mess up the protocol. Whatever code that is dynamically upgradeable by any user and runs on the blockchain needs to be able to run asynchronously without holding back the processing of transactions holding core operations (it could hold back other transactions in the same class as it though). To allow concurrent processing threads to run, the blockchain would need to have some notion of compartmentalizing database state for different smart contract operations at the protocol level so that we avoid all the overhead that comes from trying to figure out whether we can run potentially serial operations in parallel (this overhead would instead effectively move to the clients by most likely requiring them to make multiple transactions to explicitly move information from one compartment to another).

[BunkerChainLabs-DataSecurityNode]

I agree with a lot of this and anticipate a lot of what was asked to be available in time once graphene is closer to ready.

I do believe what you asked about 1. will be possible, and for 2. there is certain to be testing done on testnet prior to any implementation. All worker proposals will have to go through Three Branches of Delegation before they would become live, so the likelihood of a security issue passing through would be low.

[cryptosile]

On today's dev hangout Dan made the comparison between graphene and ethereum.  Ethereum is an interpreted language and anyone can submit and start running code.  Whereas, graphene is a pre-compiled chain with many smartcontracts as modules and adding features really isn't "that" much harder than in ethereum and anyone can submit a pull request to get their feature into the codebase.  The additional challenge is getting into the code base and then deployed out into the network, which is similar to getting approval in the Apple app store with the end result of a highly optimized compiled version of a specific smart contract.  I really like this comparison and it makes it easier for people to conceptualize the different approaches. 

I think it would be awesome to embrace this, one key challenge is when choosing a platform to develop to it's not just the code.  If we are really saying and encouraging people to contribute additional smart contracts to graphene, the whole toolchain and process needs to be documented and made as simple as possible:

1.  Document graphene internal api's , data flows, objects, etc.
2.  Make getting a development environment up and running very easy with step by step instructions. like what files are necessary, make files, etc.
3.  Provide examples of several simple smart contracts.
4.  Provide a policy to which pull requests are evaluated.  Need to have public guidelines that need to be met to be considered for acceptance.  Just like apple store policy, (but maybe try and be even more transparent.)

Until this is available I don't think it's really a legitimate comparison.

I'm curious if we could provide these two things:
1.  Allow a specific smart contract to pay 10% of fees to the creator of said smart contract.
  - This would incentivize a lot of developers to submit smart contracts and compete for inclusion into the blockchain.
2.  From a security point of view could these smart contracts be sandboxed in such a way so that a secuirty issue in a specific smartcontract doesn't put the whole chain at risk? 

If these two possible and we had all the documentation, toolchains, and processes in place it would be a very powerful story to attract new developers.