Hi, about half a year ago I built Hyperledger (one of many blockchain implementations - there is no single this is the blockchain implementation) from sources on Linux for System z. There are a couple of depencies (also C code) which are not available for the s390x platform. So you have to compile them from sources and add to the local maven repositories. Some of them only work on little endian machines, so they do not have the target for s390x, but if you add it manually, they compile just fine (but would not work). For example they include e.g. 20 protocols as the dependencys, but then use only one (http2). This is all open source software, so e.g. changing the endianess for a http2 based framework took just one week to be changed, but the next release build, where hyperledger could be base upon took 2 months to come out. You can then start instances that bring up a hyperledger network (e.g. 4 nodes plus certificate authority server, etc.) Each instance of the chaincode (the actual implementation of a blockchain transaction) and version brings up a separate docker container. This is pretty resource consuming. If Go is used, the binarys are huge, like 40MB for trivial things. Part of the build can be a Java client. There were some endianess bugs for the http2 communication they are using (its actually binary record based unlike http), but once they were resolved, the Java client worked on z/OS. I used a small IMS transaction with COBOL/Java interoperability to invoke a blockchain transaction and someone else tried it for CICS. Actually not a big deal. But since hyperledger prereqs a lot of stuff that is not ported to z/OS (maybe yet), like docker or the go language, it would be hard to run the nodes on z/OS. The docker containers are based on linux). Between the nodes its just TCPIP (of course encrypted). I doubt that the article is correct about processing faster than today, the fastest transaction processor I know is TPF with flat files as database (like some airline booking and checkin systems), then maybe IMS with fastpath databases, but blockchain? Where every record inserted needs to be encrypted and update means read record, decrypt it, verify the hashes back to the first block, update it, encrypt it and add as new record to the chain? Maybe in 20 years. Blockchain is good to get rid of intermediate parties for trades, dealing with customs papers or do lots of things paperless where unmodifyable documentation is needed, like for a goverment property register or selling things or maintanance records for air plane (parts) or other expensive equipment. But I do not see blockchain as a replacement for high volume low response time transaction processing. Selling your bitcoins can take forever if you choose your transaction fee for the miners too low that they are willing to select your transaction a input for the next block, which they start mining for (basically finding a hash that is a little bit higher in value than the previous blocks hash and consists of a nonce + hash from the previous block (making it a chain) + the actual block that contains 1-n transactions). The mining is just changing the nonce and calculate the hash for nonce+block. Actually wasting electric energy for hashing until you get a hash that is good enough. Currently the blocksize for bitcoin I think is 1MB. There was a huge fight about increasing it to 2 MB. 1 MB means for bitcoin 4-7 tx/sec: https://www.cryptocompare.com/coins/guides/what-is-the-block-size-limit/ Not to mention the growth of a blockchain, you need to keep the whole blockchain from day 0 to be able to back-verify all the hashes back to the first one (genesis block). Assuming for VISAs transaction workload you need block sizes of 500MB, after 1 month, the whole blockchain will have a size of 1235 TB. Which client can handle this today, likely not a POS device in a shop or your favourite smartphones, not even in 10 years. Furthermore you need to wait for at least 6 more added blocks before you can sure that your block is actually part of the real blockchain and not abandoned (the miners mine in parallel and several different miners might find different nonces that make the same hash, which results in forks), because other miners were faster (basically the longest valid chain wins and all other forks become invalid and their transactions or the ones that were not selected in the valid block go back to the pool of unprocessed transactions). So assuming you pay at McDonalds and have to wait 30min before your payment was finally accepted. Or you need an intermediate that takes the risk that your payment was not valid - for a fee. Sorry, I do not see blockchain as a replacement for payments pretty soon, except, every family gets his own coin blockchain and they trade with other families or companies - yes how - by using intermediates - exchanges or brokers - then you might ask the question, why to get rid of banks and credit card processors and their fees in the first place? To replace it with fees paid for miners, brokers and exchanges? With fees that result in hash mining, which is a waste of electric energy? Or some smart guy comes around the corner and finds a solution... Just my 2 cent, Denis. -----Original Message----- From: Rob Schramm <rob.schr...@gmail.com> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU> Sent: Fri, Oct 20, 2017 7:10 pm Subject: Re: Blockchain on Mainframe ?
>From what I have seen so far, I don't think native blockchain on z/OS is there. I think all the work for mainframes is done in Linux on z. It has been 3-6 months since I last looked and everything blockchain related is in "heavy fluctuation". Rob Schramm On Fri, Oct 20, 2017 at 1:05 PM Jake Anderson <justmainfra...@gmail.com> wrote: > Hi > > Is it possible to run blockchain on zOS ? Is it going to be completely a > different layer within Mainframe ? > > One of the article says if blockchain comes then it can process the > transaction even faster than VISA . > > Any thoughts ? > > Regards > Jake > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
