Re: [Hyperledger Project TSC] IBM whitepaper

benedikt herudek <benedikt.herudek@...>

Hi there

Here an interesting interview, also on permissioned Blockchains in general. Links in some respects to a question (point 2 below) raised below

@dear IBMers, maybe missed it, but some remarks to below two reviews of your whitepaper would be great. Actually, it points to a broader issue, question on identity management to secure blockchain, which seems worthwhile discussing.

regards groet gruss


On 23 feb. 2016, at 11:49, benedikt herudek <benedikt.herudek@...> wrote:

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
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.

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: &gt; This is an excellent paper to get a rough idea and it is well written. Good job. &gt; &gt; We at Cryptonomex have though about some parts of your design already and agree on most of them: &gt; &gt; * 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 &gt; * 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. &gt; &gt; 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. &gt; &gt; Two strategies exist out of this misery: &gt; a) not every node on your network validates every instruction but only &gt; a set of elected validators do and &gt; they validate each other. &gt; b) you don't execute any instruction at all and let the end users (or &gt; intermediate service) determine the &gt; actual state of the whole (or a part) of the blockchain database. &gt; (We have this implemented already and &gt; call this technology "Plasma" internally). &gt; &gt; 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. &gt; &gt; Best regards &gt; -- Fabian !!!!!!!!!!!!!! COPIED IN !!!!!!!!!!

Join to automatically receive all group messages.