ok, get your point ! indeed, without turing complete machines, things
look different.

Two questions:
1. How will you then have binding smart scripts ? You basically 'only
secure' the data on the blockchain, you dont plug together atomic
transactions, like: you switch on some device for me, then blockchain
script sends you currency

The blockchain doesn't tell you if a transactions is valid, it only shows you that
it has been authorized by someone.
Executing a contract is a matter of running the ordered transactions through a
finite state machine. Those transactions that are invalid (e.g. double spend) are
ignored. At the end, the finite state machine reaches the new state of the 'database'.
Main difference is that the FSM is not executed as part of the blockchain (consensus)
protocol but as a user-side plugin that merely takes its inputs from the blockchain.
Any smart contract can be run that way as well.

2. even if you have no turing complete language on the blockchain,
would see the need of a strong obligatory consensus mechanism. if you
have only identity management, it seems to me (happy to be corrected)
you basically rely on 'disciplining' your well-known members in case
they would introduce forged copies.

You shouldn't trust anything that is written on this kind of blockchain (unless you can
trust a users reputation) but should run a smart contract on top of the data stored in
the blockchain. Only then will you get a new state for your chain (e.g. set of unspend
outputs).

In essence, you allow a user to put ANY kind of data in the blockchain and filter it out
by validation through a FSM that is pluggin in ontop of the *raw* blockchain data.
Advantage is that you can have turing complete scripting on the user side and even hide you
contracts as they are not stored on the blockchain but only the (potentially encrypted) data
is stored on the common blockchain.

Regards
-- Fabian

Hi Fabian, Hello Benedict, I would hope for an architecture where a blockchain stores more than letters of intent but implements somewhat more binding and automated smart contracts. A "letter of intent" can still execute a smart contract. The smart contract would just not be executed as part of the blockchain protocol but 'outside' of the blockchain. In the end, a turing machine consists of a storage and an executing unit and I propose the executing unit to be outside of the blockchain (which is just for storage). Well, this is just one way to do it and I would rather see the features of the chain be implemented as blockchain protocol. I envision a blockchain that has some reduced (but extendable) set of allowed operations (non turing complete) that enable the implementation of a high-speed and highly scalable blockchain, while turing complete scripting (e.g. the EVM) can be plugged in as an outside protocol, that can be executed by 3rd party but is not part of the blockchain protocol. Agree with the necessity of Identity Management and scalability. Copied in my points below (to have on thread): 1. would see the need of a strong obligatory consensus mechanismus, it seems optional in OBC. 2.An open question to me seems how you want to block malicious code (turing halting problem), if you don't introduce a digitcal currency and hence allow something like the notion of gas in ethereum to stop too long running transactions. With what I proposed above, you don't have that issue since the blockchain doesn't execute any user defined script but only runs those that have been integrated into the blockchain protocol. Cheers -- Fabian regards benedikt --- regards groet gruss benedikt herudek On 23.02.2016 10:29, Fabian Schuh via hyperledger-tsc wrote: > This is an excellent paper to get a rough idea and it is well written. Good job. > > We at Cryptonomex have though about some parts of your design already and agree on most of them: > > * There is a need for an identity management on top of a blockchain. For that reasons, you would like to have customers register an account name (together with public keys)on the blockchain and authenticate every transaction with on of your accounts > * The blockchain mere purpose is to store "letters of intent" from users (e.g. instructions) and they could be anything from "transfers" to sell orders for decentralized order books. > > Now comes the "issue": If you want these instructions to be "executed" as a part of your blockchain protocol (you call them chaincode) such that the blockchain as a database transits into a new "state", then you need to take quite some care about scalability and speed as every instruction has to be executed on every full node if you want to have a trustless system. > > Two strategies exist out of this misery: > a) not every node on your network validates every instruction but only > a set of elected validators do and > they validate each other. > b) you don't execute any instruction at all and let the end users (or > intermediate service) determine the > actual state of the whole (or a part) of the blockchain database. > (We have this implemented already and > call this technology "Plasma" internally). > > Anyway, seeing how you would like this technology to evolve and knowing that we already have parts of it implemented, maybe we should consider a closer partnership between IBM and Cryptonomex. > > Best regards > -- Fabian !!!!!!!!!!!!!! COPIED IN !!!!!!!!!!

--

*Fabian Schuh* / Business Developer, Technical Consultant
fabian@... <mailto:fabian@...>


CRYPTONOMEX, INC.

2020 Kraft Dr Suite 3040
Blacksburg, VA 24060
www.cryptonomex.com <https://www.cryptonomex.com>

<https://www.linkedin.com/company/cryptonomex-inc-> <https://github.com/cryptonomex> <https://twitter.com/cryptonomex> <https://www.facebook.com/cryptonomex>

Cryptonomex is a leading supplier of advanced block chain technology. That can range from simple advice, to deployment of your application on one of our public block chains, to creating your own private chain