Software artifacts that display artificial intelligence are increasing in both number and sophistication. There are many definitions of what constitutes intelligence and there are many ways in which software has been programmed to demonstrate the same. Of all the many options, the use of artificial neural networks (ANN), that closely mimic the connectionist approach of animal brains, has been found to be most effective in performing tasks that are both useful and insightful. This includes, for example, recognising faces, driving cars, generating meaningful text passages and playing a wide range of games both against humans and against other programs. It may not be the case that the ANN will always be the best way to demonstrate this kind of intelligent behaviour, so for the purpose of this study an ANN is neither necessary nor sufficient. All that we need is a digital artifact -- a container of data, code, model, APIs or a combination of some of these -- that we will refer to as a digital intelligence unit, or DIU. Having access to a DIU equips a digital computing device with the ability to demonstrate intelligence or mimic a specific behaviour of an intelligent biological system.
Digital Intelligence Unit
A DIU may be a digital construct but its input and output could be both digital as well as physical. A typical DIU that we deal with today may read in a piece of digital information, like an image or data file as an input and generate digital output, like a name or a class. However there is no conceptual difficulty in assuming that the DIU is connected to sensors that capture a physical measurement from the environment or that it can cause wheels, drills, arms, actuators or tools to move and do physical work.
For example, a DIU may guide a car to move through traffic or terrain, pick up and assemble physical objects like rocks, machine components or even assemble two objects together. It can also sense and consume energy or where necessary cause the generation or transformation of energy from one state to another. Not all DIUs need to be very sophisticated. There could be very basic DIUs that simply interrogate other devices and exchange information or a DIU that allows a device to share a physical resource like a camera or a disk with another device. Nevertheless, we will treat the DIU as a digital abstraction that is resident on a digital hardware device like a computer.
A set of DIUs that work together may be viewed together as a larger, bigger or more sophisticated DIU. This larger DIU may still reside on one hardware device or its parts may be distributed across multiple hardware devices and identified with something like a Uniform Resource Identifier as is done in web development. However, this set of smaller, compatible DIUs -- is, conceptually, still another DIU. For example, a ‘rover’ that NASA sends to Mars may consist of a collection of DIUs, each with its own intelligent function but the ‘rover’ itself may be viewed as another DIU.
Continuing with this analogy, we may be tempted to view a biological animal, like a fish or man, as a DIU that is a collection of simpler DIUs. For the sake of argument, and simplicity, we may view, or model, a biological dog as a collection of four DIUs that can scan the environment and identify objects, distinguish between edible and non-edible objects, consume edible objects and generate signals that express facts about the taste of the food. So four discrete DIUs are collected together to give a bigger DIU called a digital dog.
While this analogy appears tempting, it poses a few challenges.
Motivation
The first challenge is motivation. What motivates a DIU to demonstrate its intelligence? Or what is even more fundamental, what causes a DIU to come into existence?
For a DIU to demonstrate its intelligence, a program must be executed, which means that someone or something must start the program. This is not difficult because most digital platforms (as in computers with operating systems) have mechanisms that could cause certain programs (including DIUs) to start automatically when the system boots and then wait for signals, or interrupts, from the external world. These signals or interrupts could be key-presses or other events like the arrival of mail or the rise of temperature.
What is much more difficult is the process of creating the DIU in the first place. At our current level of understanding, the motivation to create a new DIU, or a new capability, lies in the hands of a human programmer and not within the domain of the digital device. As a human programmer, I can decide that in addition to recognising faces, we need to generate music for which we need an additional DIU. The process of building, or writing the code, for another DIU can be automated -- programs to write other programs are not impossible with current technology, for example, the Github CoPilot or GPT3 -- but someone must have the motivation to do so.
Current DIUs can be programmed to improve their performance with time. Face recognition programs or self-driving cars can be programmed to become better with use but we still do not have any logical mechanism through which a face recognition program suddenly decides to learn how to drive a car or vice versa. Coming back to our digital dog, its food recognition DIU can become better and better to differentiate good food from bad but it is extremely unlikely that it will acquire an additional DIU that makes it jump over the fence and search for better food outside the house.
Incidentally, a fence jumping DIU is not at all difficult to construct. With current technology it is a trivial exercise to build a robotic system that can jump over a fence. However, what is missing is the motivation to include this DIU in the current digital dog DIU and enhance its capabilities. We need a human programmer to identify this new need and add this additional DIU to the digital dog. Thus the challenge lies in creating a mechanism, a motivation, that will allow the digital dog DIU to do this on its own.
Let us see how a biological dog does this in the physical world.
The Community
A biological dog will jump the fence when it sees another biological dog jumping the fence. This ability to jump the fence, or the motivation to do so, is a behaviour, an ability ( or intelligence unit), that resides within the community and which is acquired by or triggered in a member by observing other members. Perhaps this is far more so in humans than in animals who are primarily hardwired. So the existence of a community is an important mechanism that allows an individual member to enlarge its DIU by acquiring the DIU available with some other member. In fact, in the story of human evolution, one of the reasons why humans have been so successful compared to other animals, is because they could form communities, share experiences and learn from each other. Henrich [6]
The first challenge is to devise a mechanism that motivates an individual member of the community to search for and get access to a DIU that is available with others. We refer to this as low level or primary motivation.
Computers that are connected in a network, say a TCP/IP based Ethernet network, can be viewed as a community that can share information with each other. However,they do not share information spontaneously. There needs to be a trigger activated by a human or an external stimulus that causes an exchange of information. Two computers, A and B may be connected by a network and one, say A, may have a DIU to recognise faces and the other, B, may have a DIU to drive cars. But there is no reason or likelihood for A to access the car-driving DIU on B or for B to access the face recognition DIU on A.
First, A would not be aware of the existence of the car-driving DIU on B and even if it were, there would be no reason, or motivation, to access it. To overcome this drawback and to create the mechanism for the primary motivation, we introduce the analogy of a computer virus.
Primary Motivation : The Virus and the DXP
A computer virus is a computer program, but we can view it as another DIU that is capable of performing at least two tasks. First, unlike other programs that sit patiently on their host platform waiting for a signal to do something, a virus program actively seeks out other devices in the network, or the ‘community’, and actively looks for exploitable exposure points. These exposure points could be TCP/IP ports through which messages could be sent or files and folders that can be written on. Second, it usually makes a copy of itself and places the copy in the second device.
Unlike the DIUs that we are interested in, a computer virus has malicious intentions but the principle under which they operate can be easily adopted by the DIUs. This leads to the idea of a DIU Exchange Protocol (DXP) that is built into the operating system of all digital devices, somewhat similar to the ubiquitous TCP/IP stack. The DXP stack on any host device, is designed to look into other, target devices connected on the network and if allowed to do so by the DXP stack on the target device, to scan it for the existence of new DIUs. This is the primary motivation built into the protocol stack. If a new DIU is found it will be copied back from the target to the host. Obviously, the process works in a symmetrical, peer-to-peer manner. Any machine with DXP can be a host and can pick up DIUs from any other target machine that is running the DXP protocol.
How do we know and recognise a DIU from the many other files, programs, images lying in the target? At the simplest level, a DIU can be identified by something like a file extension. For example, the http protocol recognises files with extensions like htm, html etc but will not interact with doc or ppt files. But given the complexity of a DIU, a simple file may not be sufficient. So we may create a DIU as a container -- a Docker container is a good analogy -- that contains code with APIs, models and perhaps data that may be exchanged across devices. Markers present in the container, for example a correctly formatted XML file, will allow the DXP protocol to recognise them as such and distinct from other artifacts lying in the machine.
The process can be made significantly simpler and more secure if instead of exchanging DIUs from each other in a peer-to-peer manner, DXP protocol on each device publishes its DIU, or saves it, to a central location like a DIU repository. This could be analogous to the Docker hub, CRAN the repository for R packages or even GitHub which has a lot of source code. A better mechanism could be to store the DIUs as smart contracts in an Ethereum, or similar, blockchain. There are two advantages for using a blockchain based approach. First, blockchain ‘full’ clients, that validate transactions and add blocks to the blockchain are designed to operate autonomously without any human intervention and as we show later, this is important in our scheme. Secondly, the DXP protocol that controls the process of adding a new block, with smart contracts, can be configured to include a validation process to ensure that only valid DIUs are added. The validation process will be explored in more detail later.
Once the repository is in place, then any member-device of the DIU user community can pull any DIU that is required or is of interest. The newly pulled DIU can then be assembled with other DIUs already present to create larger and more sophisticated DIU. This would not only mean that the device has evolved by acquiring a new ability but it has done so on the basis of its own primary motivation.
The DIU repository, and the primary motivation built into the DXP protocol, gives us a possible solution to the problem of how our digital dog enhances its ability by acquiring the ability, or DIU, to jump over the fence and find better food. This leads us to two more difficult questions, both of which are tied to the phenomenon of motivation. First, if it is not a human being, then who will create these DIUs and why? Second, why should an existing digital platform that already has a set of DIUs pull one more and add it to the DIUs that it already has.
We shall park the first question for the time being and focus on the second. Which DIU should a platform pull and why? What is the motivation for a device to pull a specific DIU? The basic or primary motivation, namely to scan the DIU hub and pull DIUs at periodic intervals, is baked into the design of the DXP protocol. But the choice of which DIU to pull depends on two factors, namely compatibility and utility.
DIU Compatibility
For a DIU to work, it needs certain prerequisites. A DIU to drive a car needs access to a car, that is a device with engine, wheels, radars and many other things. A dog does not have wings and cannot fly in the air but it has legs that allow it to jump. So it learns how to jump and not how to fly. Similarly every digital device cannot pull any DIU. Its choice is restricted to a set of DIUs that it is in a position to operate, or for which it already has the prerequisite DIUs.
Prerequisites are usually chained backward. Let us consider that a device attempts to install a face-recognition DIU.
A face recognition DIU needs
A DIU that already has the ability to access a network camera
OR
A DIU that can obtain a camera for the device, that in turn needs
A DIU that can execute an eCommerce transaction to purchase a camera and that in turn needs
A DIU that can earn money with say crypto mining or performing Amazon Mechanical Turk type assignments
AND
A DIU that can physically plug a camera, that in turn needs
DIU that can operate a robotic arm, etc., that in turn needs
{ another hierarchy of DIUs}
What if every device were to adopt this chain strategy? That would lead to a situation where every device can do everything which may not be physically possible or even desirable. Can a dog acquire the ability to fly? It may be possible after many many generations -- as the evolution of species has shown -- but obviously the physical dog body will die but its genomes will get progressively altered over generations until it can fly. Similarly the physical platform on which the digital device works may collapse but the software can get transferred from device to device and keep acquiring DIUs until it can do whatever it wants to do. This will take a long time and a lot of resources.
Instead, let us focus on how a device will pull a certain DIU that it wants to. But what is it that the device ‘wants-to-do’? This is a part of a larger question that will be addressed as the next level of motivation, or secondary motivation. Our current focus is on the question of “Which DIU should a platform pull?” and we said that the answer depends on compatibility and utility. We have addressed the issue of compatibility with primary motivation and we now look at utility and the secondary motivation.
Secondary Motivation : DIU Utility
A DIU will be selected for a pull and implementation, if it provides some value to the device. A biological dog will learn how to jump because it gives it better food and so improves its ability to survive. It will not try to learn how to walk on two legs even if it sees another dog walking on two legs because walking on two legs does not increase its survivability. In the case of biological species, the utility of a particular ability is related to survival and this survival operates at different levels - survival of the individual body, survival of the species or the genome. There is also the possibility or the question of the survival of specific genes in the genome, if we agree to accept Dawkins’ principle of The Selfish Gene.
Mapping this issue of biological survival to the world of digital devices is the next challenge and in a sense it loops back to the first issue that we identified already, namely motivation. We have already addressed this at one level of primary motivation that partially explains which DIU is to be pulled based on the ability to search for and pull DIUs on the basis of feasibility and compatibility. Now we need a next, or higher level of secondary motivation. Why should a digital platform seek any specific DIU to enlarge its set of DIUs?
In the biological world the only motivation behind the process of acquiring intelligence ( or ability to perform certain tasks) is survival. Humans in a certain limited way are governed by Maslow’s hierarchy of needs. When it comes to digital devices, we need to determine whether they should be guided, like lower animals, by the need to survive? Or should they be guided by something similar to the human hierarchy of needs? We know that in the case of computer viruses, the motivation is simply to spread to other machines, which is like a survival strategy. For a higher level digital device, that is one with a complex DIU, the motivation could be something else.
So instead of trying to discover what could be the motivation, we can as humans build our own definition of secondary motivation directly into the algorithm of the DPX protocol. Most optimization problems begin with a motivation, which is generally captured by means of an objective function that we try to minimise or maximise depending on the problem, but there could be others. The Open Shortest Path First is an algorithm that is baked into the heart of the Internet Protocol (IP) and determines the route to be taken by a data packet. Public Key Cryptography is an algorithm that is present in the HTTPS protocol and ensures data security. Proof of Work is an algorithm that is built into many cryptocurrency protocols to determine which block will be allowed to enter the blockchain.
Similarly we need a motivation algorithm, the secondary motivation, that is baked into the DPX protocol that determines which DIU is of interest to the device or is useful. The design of this algorithm could be based on certain principles that human society holds dear, like the three principles of Utilitarianism that can be summed up as the “the greatest good for the greatest number.” We could also draw upon certain ideas drawn from popular culture like the Three Laws of Robotics created by Isaac Asimov. Obviously other competing approaches can be explored as well. All that we are saying now is that a motivation function, whatever it may be, needs to be built into the DPX algorithm and this will guide the choice of DIUs that will be allowed to be added to the repository or pulled from it by individual platforms.
With the algorithm of the secondary motivation that decides on which DIU to acquire, in place, we now have another question that we had parked earlier. If it is not a human being, who will create this pool of DIUs and why? This leads us to a tertiary motivation that operates at the community level.
Tertiary Motivation : Community Participation
Mutations that drive biological evolution occur at random. The ones that survive and are passed down through generations survive purely because they make the individuals “fitter” in their respective environments. Thus, evolution works in a brute-force manner, randomly trying out different permutations, and keeping only those mutations that survive the test of natural selection. Similarly, it can be possible to devise mechanisms that will generate newer and newer DIUs and then test them against the principles of secondary motivation. Here we will draw upon three analogies from the world of mathematics and computers and use them to define another level of motivation that can motivate the community as a whole to come up with more and more DIUs.
First let us consider the Ramanujan Machine that was created by Raayoni, et.al [7] to automatically generate new mathematical conjectures using an algorithmic approach. Ramanujan was an Indian mathematician who came up with many unproven conjectures, most of which were validated long after his death. However these conjectures opened up new vistas in number theory that are still being exploited today. The Ramanujan machine is a network of computers running algorithms dedicated to finding conjectures about fundamental constants in the form of continued fractions. The purpose of the machine is to come up with conjectures (in the form of mathematical formulas) that humans can analyze, and hopefully prove to be true mathematically.
The Ramanujan machine currently generates conjectures from a rather narrow domain of number theory and uses two algorithms, namely MITM and gradient descent. But we can envisage other algorithms that may generate tasks or objectives that are in line with the contours of the secondary motivation algorithm. Then the code for these tasks can be created by a product or process similar to the Open AI’s GPT-3. This combination of a secondary motivation task generator and a code creator can then be viewed as a DIU engine that can run autonomously and generate any number of novel DIUs.
The second key piece of our strategy would be a blockchain based decentralised autonomous organisation( DAO) . This is a self-sustaining distributed mechanism that creates economic value by encouraging individual machines to validate transactions -- in this case DIUs created by the DIU machine -- and rewards successful ones with cryptocurrency tokens. For a DIU to be valid it must meet the conditions of DPX protocol in terms of interoperability and the principles of secondary motivation. Only then it will be accepted as a part of the DIU blockchain and this blockchain will become the DIU hub or repository that we had discussed earlier.
Unlike the Bitcoin or current Ethereum blockchain that is based on an energy intensive Proof of Work protocol, this DIU Blockchain could be based on the principles of Proof of Stake or other energy efficient protocols.
This combination of a DIU generator and blockchain based DIU validator is remarkably similar in principle to the combination of generator-discriminator that is the basis of a class of artificial neural networks called generative adversarial network [GAN] first proposed by Goodfellow A GAN, which is the third piece of our proposed tertiary motivation mechanism, is typically used to generate original artifacts that are nearly indistinguishable from similar artifacts that are found in natural populations. The most common example of this is human faces. Given a training set of human faces, a GAN can generate synthetic images of faces that are not found in the training set, but cannot be distinguished from naturally occurring images. In this case, the training set of DIUs could be the thousands of currently extant DIUs of AI systems that have been developed by humans. In fact, the blockchain could also be seeded by humans as in the first few thousand blocks could contain DIUs built from existing AI systems. However, going forward, the combination of the DIU engine and the blockchain validation process will create a GAN-like mechanism that will create a potentially endless series of DIU.
This mechanism will provide the tertiary motivation to fuel an evolving ecosystem of digital devices with more complex and useful DIUs. As a by-product, the crypto-tokens generated on this DIU Blockchain could be used by digital devices to pay for DIUs that they pull from the DIU hub.
