Smart contracts in Nexus

The way smart contracts are implemented in Nexus is different than that of the system of Ethereum or similar smart contract platforms.

Ethereum created it's own Turing-complete language, called Solidity. You can write smart contracts on the Ethereum ecosystem using this language.

Nexus didn't create a similar Turing-complete language. Instead, in the system of Nexus, there is a 7-layer software stack. The lower layers of the software stack are capable of changing the state and object registers of the system, which can store data. Object registers are like objects in an object oriented programming language. They could be medical records coupled together with an ID, ownership data, an organization with the list of it's members, or anything else.
The manipulation of these registers are done on the Operation Layer, which is the 4th layer of the software stack. Each layer of the software stack serves the layer above it, and it is served by the layer below it. These are the seven layers:

7	Interface Layer
6	Logical Layer
5	API Layer
4	Operation Layer
3	Register Layer
2	Ledger Layer
1	Network Layer

This means, that an end user, for example, who is interacting with the system through the Interface Layer - which is the top layer - doesn't need to know anything about programming. The lower layers are serving the Interface Layer, on which she or he is interacting with.

Similarly, an application programmers can access the system through the API Layer, which is the 5th layer of the software stack.


What are APIs?

API stands for Application Programming Interface. APIs are sets of clearly defined methods of communication between various software components. With APIs you can do certain tasks on the ledger with predefined functions, so you don't need to think about how to do it on the lower level, instead, you can concentrate on your application, for example the other parts of your software that are not related to blockchain, or the design. You can think of APIs like buttons on a machine, where you don't need to understand the inner workings of the machine, you can interact with it through the buttons. One great thing about it is that, if they change something in the inside of that machine, you don't need to worry about it, from the outside it will be the same, you will still have the same interface to communicate with.

With APIs you can write your code on your preferred language, and interact with the system of Nexus through the JSON-REST formatted APIs. JSON is a format that was designed to be similarly easy to read to computers and to humans as well. Here is an example:

{
  "firstName": "John",
  "lastName": "Smith",
  "isAlive": true,
  "age": 27,
  "address": {
  "streetAddress": "21 2nd Street",
  "city": "New York",
  "state": "NY",
  "postalCode": "10021-3100"
  }
}

There are multiple types of APIs in Nexus, there can be different APIs that are related to an application that is handling copyright information, another one for medical information, identity, etc.

The list of APIs will be constantly revised according to the specific needs of different industries. There will be regular conferences where different industry experts can promote the development of a new set of APIs.

Applications will communicate with the system through API gateways, any node can choose to become an API gateway.

There can be situations where you can not achieve your goal through existing APIs as an application developer. In these scenarios, application developers are free to go down to the 4th level of the software stack - the Operation Layer - and interact with the ledger through byte level instructions. With byte level instructions you can do almost anything, but it is much harder to write a software that way. With byte level instructions, you can save any type of data on the ledger, but you have to build up the logic yourself.

So the modular design of Nexus makes it easy to interact with for novice programmers or application developers, but it also makes it ready for bigger projects to build upon it, where predefined functions are not enough to implement the logic of that complex project.
And secondly the modular design is also great for developing the protocols of the software stack independently, so a software update won't conflict with existing applications that are built upon the ecosystem.