I suspect that it is still fairly rare for someone to have spent a lot of time developing smart contracts on Ethereum and Hyperledger Fabric. Couple that with the fact that anyone who has such experience is probably up to their eyeballs in work right now :-)
I worked on Go chaincode for about a year, building an IoT-oriented platform for smart contracts that has been temporarily suspended while I worked on JavaScript smart contracts through the Hyperledger Composer this year. I don't have direct expertise on Ethereum and Solidity, but I will do my best to answer what I can.
Do note though, that Ethereum is based on crypto-currencies and mining, and a lot of the activity is centered around the public, permissionless network. I.e. this is not designed for secure business networks, which require that you take a version of the Ethereum code base and hack it. This is not the same thing at all as working with Fabric, which is designed from the ground up to be used for secure business transactions.
Quick few questions on smart contracts
how does hyperledger smart contract (chaincode) stack up against
ethereum ?
Ethereum, like Fabric, have multiple smart contract languages. Ethereum's are Solidity -- a JavaScript-like language, Serpent -- a Python-like language, and LLL -- a Lisp-Like Language). The big difference here is that Fabric runs the actual versions of those languages so your skills are portable in both directions.
hyperledger - golang; Expressibility? ; Performance? ;
Security?
Golang looks a lot like C language but is more expressive, with concepts like channels, receivers, and so on. The performance is pretty extreme.
I also favour the Hyperledger Composer infrastructure, which uses interpreted JavaScript code and a powerful business network modelling language. This is worth exploring as it is evolving fast. A lot of security headaches are solved with minimal fuss using their access control language in permissions.acl.
Ethereum - solidity; Expressibility ; Performance? ;
Security?
Not sure about expressibility of any of their languages, but presumably you can do common contract stuff. Performance, though, is limited by definition to the block cadence of the Ethereum network, which is limited by the speed of mining. Bitcoin commits blocks about every 10 minutes. Ethereum is faster, but there will be a limit.
Regarding security of these two -- Fabric is permissioned and is generally expected to run on a private network, in backoffice(s) or on a cloud. Thus, it can be architected and engineered for as much physical security as you desire and / or can afford. Ethereum is likely the same when deployed privately, but not when deployed into an exchange that is meant to be public a la Bitcoin.
There are attack vectors of course, but presuming that you keep your chaincode in private repositories then again you can get as much security as you can afford.
how to secure smart contracts to ensure that code is not tampered?
You have to secure your network and repositories. For example, if you are running on a single Kubernetes cluster for a small blockchain, then you secure the cluster. If you are running on a large collaboration with multiple separate back offices running the HSBN (IBM's Fabric-based High Security Business Network) on Z systems, then you will secure the physical hardware and the internetworks. The chaincode has few to zero attack vectors if you spend enough money. (I'm using cost also as a synonym for effort by the way). Presumably, a private Ethereum deployment will have similar characteristics but again it is conceived as a crypto-currency engine and is natively permissionless.
how can both parties trust and trace the results of the smart contract? any audit/traceability capability?
Fabric has a historian that tracks every transaction and world state change (and I mean all of them ever). You can write complex SQL-like queries to gather and analyze such data. It is extremely powerful.
When I search for similar info for Ethereum, I get article after article discussing the historical price of Ethereum's currency. These are different worlds.
Also in a decentralised ideal world, whose legal liability if there is a bug
and/or buffer overflow in the smart contract resulting in some losses?
With Fabric, someone will be responsible for implementing smart contracts as codified business rules, and there is little logical difference between that and any existing financial system that was implemented either internally or using contracts. The dynamics of liability will be the same.
With Ethereum, I have no idea. There is a funky crypto angle to be aware of and if you try to implement a business network a la Fabric you are probably stepping into territory for which Ethereum takes no responsibility. This is not all that different from Fabric I suppose. But there is a difference in original purpose and that might make a difference when it comes to legal arguments (as in the "what were you thinking?" defense.) That is all pure speculation :-)
Any performance benchmarks? E.g., 2000 of complicated smart contracts
executed during a span of 10 seconds?
I ran some load tests (poisson traffic into a Go smart contract on a 4 node v0.6 fabric on Bluemix) for months at an average of about 23,000 transactions per hour with full history retention in world state. It ran fine. Hyperledger v1 has been engineered to be considerably higher performing than v0.6, however there are more complexities in using it so it will require serious system engineering to eke out its best performance (and what is new about that?)
How does one enable/restrict security access to these smart contracts? i.e.,
only Alice and Bob can see the contract and not John
Take a look at the ACL language in Hyperledger Composer and you will see that there is a rather sophisticated view of participant restrictions.
UPDATE: That link is busted. The new one is https://hyperledger.github.io/composer/latest/reference/acl_language.html
There is also research going on with Go libraries for ACL concepts, but I don't know when such might appear.
Anyway, I hope some of this was useful.
