Re: [Hyperledger Project TSC] IBM whitepaper


benedikt herudek <benedikt.herudek@...>
 

Hi Fabian,

I would hope for an architecture where a blockchain stores more than letters of intent but implements somewhat more binding and automated smart contracts.

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.

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 !!!!!!!!!! -------- Original Message -------- Subject: Re: [Hyperledger Project TSC] IBM whitepaper Date: 20.02.2016 16:15 From: benedikt herudek <benedikt.herudek@...> To: hyperledger-tsc@... Hi Chris, excellent paper ! Below two remarks / questions around Identity Management vs Consensus and one suggestion concerning data privacy on permissioned blockchains. Interested in anyone's view. regards benedikt 1st remark: Chain Language, Turing halting problem & native currency: Understand, you don't introduce a native OBC currency. It seems you might introduce a native OBC language in the future. But at the moment, you support existing languages like go. https://github.com/openblockchain/obc-docs/blob/master/FAQ/chaincode_FAQ.md Without a native currency, but with a full turing complete language, how will you address someone introducing mailicious code running through endless loops and eating up ressources ? Ethereum wants to address this with the notion of gas, so transactions running too long and not having the ressources will just get halted and rolled back. That is inherently connected to having participants pay for transactions. Hence, having a native cryptocurrency as part of a blockchain seems to offer a good mechanism to block such attacks. Is the implicit assumption here that enterprise permissioned blockchains have a lesser risk of such intruders and hence, if we establish identity of blockchain participants and have auditors over the network, we would get on top of such intruders anyways ? 2nd remark: Trusted Ledger: Identity Management & Consensus Mechanism: The OBC you suggests offers participants to plug in their own consenus mechanism. It seems one could even use the OBC architecture without a consensus mechanism:https://github.com/openblockchain/obc-docs/blob/master/FAQ/consensus_FAQ.md In that case it might be (see 1st remark) the implicit assumption is we establish identity of participants in blockchains to restrict access and audit members and with ensuring this, we have eventually only trusted members (we dont let others in or remove them) in the network. The need for 'unbreakable' consensus mechanisms like bitcoin proof of work for a permissionless network (everyone can plugin) might become lesser of a concern. One might think Identity Management introduces a notion of centralization (you also address this point here: https://github.com/openblockchain/obc-docs/blob/master/FAQ/identity_management_FAQ.md) into a blockchain. But for enterprise transactions, having identity management is just indispensable. My concern would however be to overstress Identity Management compared to consensus as the underlying mechanism to ensure we have trusted data in a shared ledger. Having Consensus optional and Identity Management mandatory might allow 'abuses' of the architecture as a simple 'inter - enterprise - B2B - platform'. Maybe it could be useful to default a minimal consensus mechanism and give (minimal) criteria to replace the default consensus mechanism you suggest. Having a consensus mechanism enforced, it could also be useful having a lightweight or no-identity management option as part of the OBC for 'bitcoin like' usecases, where participants might not want to reveal their identity. A Suggestion for Data Privacy on (permissioned) Blockchains Placing certain data on a shared ledger will be a hard sell too many, who dont sleep well over hearing concepts like 'distrubuted shared ledger' and 'health and financial data' in one sentence. It will be difficult to overcome such concerns with a treatise on the strength of cryptography and frankly, there are ongoing discussions how secure crypto is and will be with more (quantum) computing power in the future. A pragmatic solution could be placing 'really sensitive data' outside the blockchain, link the data and keep only e.g. a (partial) fingerprint on the blockchain. You mention someting similar in a different context and purpose for files. https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md (section Architecture / Blockchain) : Large files (documents, etc.) are stored in off-chain storage, not on the Ledger. Their hashes can be stored on-chain as part of the transactions, which is required to maintain the integrity of files This could be a general and optional feature: One should be able choosing to have 'really sensitive' data in a permissioned database in one's regular enterprise network. The Blockchain transaction (cryptograhically secured) would contain: A Link / Url / security tokens (indicating whoever knows this, was 'inside' that blockchain transaction) that allow access to several external System, typically within the enterprise network of participants of the transaction. These networks would use whatever authentication and security regulation authorities and enterprises deem necessary and revoke them when this might seem appropriate. A 'as good as possible proof' of the contents linked data. This is obviously vague, the idea is that the data is not readable (it's at best partially there) on the blockchain, even if cryptograhpy is 'broken'. Then however, if participants in a transaction have a disput over the content of a transaction, such a 'partial fingerprint' of the data on the blockchain can at least help ruling out 'offbeat' claims from transaction partcipants, which in reality have forged their local data copy. This feature would represent a trade off between the need for privacy (at your own terms) and the traceability of transactions to settle disputes. One would give up some traceability of the contents of a transaction but gain privacy, in the sense that you control the sensitive data yourself with whatever mechanisms your enterprise (and not the blockchain) considers necessary. For some usecases, this might just be what is needed and integrating this as an optional feature in a enterprise blockchain could enable a number of interesting usecases. --- regards groet gruss benedikt herudek !!!!!!!!!!!!!COPIED IN !!!!!!!!!!!!!!! > > On 02/18/2016 05:31 PM, Christopher B Ferris via hyperledger-tsc wrote: >> All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback. >> https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md >> Cheers, >> >> Christopher Ferris >> IBM Distinguished Engineer, CTO Open Technology >> IBM Cloud, Open Technologies >> email: chrisfer@... >> twitter: @christo4ferris >> blog: https://developer.ibm.com/opentech/author/chrisfer/ >> phone: +1 508 667 0402 >> >> >> >> _______________________________________________ >> hyperledger-tsc mailing list >> hyperledger-tsc@... >> https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc > > -- > > *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 > > _______________________________________________ > hyperledger-tsc mailing list > hyperledger-tsc@... > https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

Join toc@lists.hyperledger.org to automatically receive all group messages.