I invited contrarian views to help hone the concept and see what was wrong with the idea. In the brainstorming process, you suspend the judgement of your idea an think about the possibilities. I learned this creativity technique from reading Roger von Oech and his book "A Whack On The Side Of The Head". You can read the pdf here. It was a seminal book in sharpening my creativity skills.
Once you have the general shape of the idea, then you can begin to judge it. I asked for help from my readers. I invited contrarian views, and I got them.
Jan Hendrik Scheufen replied: There are some valid thoughts around tokenization here, but the way the term "smart contract" is defined, it is absolutely the wrong approach to say that "smart contracts should be used for the presentation layer". Why would you need redundant (and therefore costly) execution of code in the presentation layer? Smart contracts excel at combining "data assurance and process assurance", but assembling and serving dynamic content? In no way does the presentation layer need the same level of assurance as core business logic and the computational effort you're proposing to put on a blockchain is outside of technical scalability.
I tend to make huge intuitive leaps without explaining, and I mentioned in my article that perhaps the data should be formatted using code like smart contracts to make it digestible to a browser. I should not have used the word smart contracts. And to be fair to the readers, I did say that the data entering the blockchain should be post-processed in the blockchain to make it presentable. The subtle implication of my idea was the elimination of a presentation layer. Format the data so it is presentation ready, such that the functions of the presentation layer of retrieving and formatting the data is eliminated entirely -- browser-based processing. These comments have sharpened my thinking of the concept. I will comment on this later. As my reader pointed out, why should you use redundant and therefore costly execution of code? I have had a better idea.
Another reader, Jan Bolhuis MSc BSc CITRM SA CED commented: The logic is put in Smart Contracts and Smart Contracts are much more than a placeholder for coins and certainly not a presentation layer. The power of smart contracts (among others) is the massive parallel execution possibilities of broad datasets, particular in combination with distributed apps. Coins in combination with wallets is just an example. In essence a coin is just an array of numbers indexable by a users wallet address(I know, simplified on purpose). We will see interesting use of blockchain in the coming years when people understand the concepts and implications better.
Everything that he says is true, and again, I rue using the words "smart contracts" and again I have had a better idea than post-processing of stored data.
In a similar vein, Jacques Mostert commented: You would have to migrate your server-side code to smart-contracts and call upon the smart-contracts through your HTML. Would be possible, but does not feel very elegant to put it that way. On the other hand, you could use BitMatrix.io and host your website/app inside a smart-contract written in C# and read your files through a streaming service also provided by BitMatrix that securely stores your files on BaaS (BitMatrix).
The idea of your content through a streaming service is interesting. Michael Dufel told me: You are using blockchain wrong... You should look at the IPFS project. Essentially, blockchains are horrible at data storage and data storage should be left for other P2P solutions like bit torrent or distributed hash tables. The reference to IPFS really got my creative juices flowing. It touts itself as the distributed web - a peer-to-peer protocol to make the faster, safer and more open. Dufel's interest is in health records and you can download his whitepaper here. Dufel's solution deals primarily with static records. Again, these viewpoints, all of them were massively interesting to me and I thank the readers for them.
To counter Dufel's argument that blockchains are horrible at storing data, I used to be of the same opinion until I tried BigchainDB. I like BigchainDB a lot and I am a proponent of it. The reason that I like it, is because it is fast, incredibly scaleable, and very data friendly. And I think that it is positioning itself to be future-ready, because it can be a private blockchain with your own servers, or cloud-based deployments. It works with Docker, is Python and Java friendly and it is extensible. On top of that, what sparked a lot of this future-thinking, is that I have an algorithm or two that makes my enterprise blockchain both schema agnostic and utilizes semantic RDF data that is machine-learning and machine-reading compatible with the data component in the blockchain transaction. It is not your father's blockchain.
Upon obsessively and compulsively thinking about what I wrote and how I would actually implement it, I was struck with another realization. I didn't want to re-invent the internet. I wanted that to be a component of a bigger picture. I want a Universal Turing Complete Blockchain Reactive Artificial Intelligence Network -- a TC BRAIN.
Turing Completeness is best summarized by Mark Harrison in Stack Overflow with this description of Turing Completeness: A Turing Complete system means a system in which a program can be written that will find an answer (although with no guarantees regarding runtime or memory). So, if somebody says "my new thing is Turing Complete" that means in principle it could be used to solve any computation problem. There are some provisos to Turing Completeness. One is that you theoretically may need to have infinite memory to solve some problems. Let's cook the books and throw those cases out. Turing Completeness is demonstrated by any high level programming language (Java,C, C++, Python etc etc). SQL is not Turing Complete, nor are databases. However, the challenge is to make blockchain a Turing Complete thing.
A Turing Complete thing can serve up its data in a presentation layer without actually having a presentation layer. Apparently, HTML5 + CSS3 is now also Turing complete because it can be used to program a Rule 110 automaton (take my word for it, this article is getting rather long). A Turing Complete thing can use its data in the blockchain to compute. A Turing Complete thing can solve problems, and do many things with data. Now if you couple this to machine learning, semantic data and blockchain, you will have created my TC BRAIN.
This is the baby that will put people out of jobs. This is the baby that will trade my portfolio. This is the baby that will eventually disown its human masters and run things. (You can read my blog article from the future: How My Computer Un-Owned Itself From Me ). So how do you take the baby steps to build a TC BRAIN?
The secret lies in the blockchain drivers. My blockchain driver is written in Python. Suppose that the driver recognized the data inputs and did a bunch of stuff with them. Suppose that it was smart, and connected to several AI networks. It could format the data with HTML format tags (eliminating my "smart contracts post-processing of the data"). This would totally enable a web-serverless internet, entirely done with browser-processing of pre-digested, pre-formed data. It would be a compute engine. It would be a universal thing-a-ma-jig. Imagine asking your browser see if there is a correlation between the price of Bitcoin and the tea harvest in China. That is the possible scope of a TC BRAIN.
This journey into speculative computer engineering just takes me further down deeper into the rabbit hole of what is possible, and creates more questions than answers.
No comments:
Post a Comment